1. 29 Aug, 2013 2 commits
    • Barry Song's avatar
      arm: prima2: drop nr_irqs in mach as we moved to linear irqdomain · f8ab658b
      Barry Song authored
      we don't need nr_irqs in machine any more after we move to
      linear irqdomain for sirfsoc irqchip, so drop them.
      Signed-off-by: default avatarBarry Song <Baohua.Song@csr.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      f8ab658b
    • Barry Song's avatar
      irqchip: sirf: move from legacy mode to linear irqdomain · 29eb51a7
      Barry Song authored
      the series of patches for irqdomain core in 3.11 has broken sirf
      irq which uses legacy mapping. all users fail in the new kernel
      while setupping irq.
      
      this patch moves to linear irqdomain and drop old legacy irqdomain
      codes since we don't need it any more, and at the same time, it
      also fixes the broken interrupts of sirfsoc in 3.11.
      
      on the other hand, we actually only have 64 interrupt sources for
      prima2 and atlas6, but there are 128 interrupt souces for marco
      which uses GIC. in the legacy codes, sirf gpio also uses legacy
      irqdomain, so to make gpio interrupt mapping not depend on the
      prima2/atlas6/marco an use unified marco,we enlarge prima2/atlas6
      interrupt number to 128. here we don't need this workaround any
      more as sirf gpio also moved to linear mode before. so we move
      SIRFSOC_NUM_IRQS back to 64 too.
      Signed-off-by: default avatarBarry Song <Baohua.Song@csr.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      29eb51a7
  2. 22 Aug, 2013 1 commit
    • Stephen Warren's avatar
      ARM: tegra: always enable USB VBUS regulators · 30ca2226
      Stephen Warren authored
      This fixes a regression exposed during the merge window by commit
      9f310ded "ARM: tegra: fix VBUS regulator GPIO polarity in DT"; namely that
      USB VBUS doesn't get turned on, so USB devices are not detected. This
      affects the internal USB port on TrimSlice (i.e. the USB->SATA bridge, to
      which the SSD is connected) and the external port(s) on Seaboard/
      Springbank and Whistler.
      
      The Tegra DT as written in v3.11 allows two paths to enable USB VBUS:
      
      1) Via the legacy DT binding for the USB controller; it can directly
         acquire a VBUS GPIO and activate it.
      
      2) Via a regulator for VBUS, which is referenced by the new DT binding
         for the USB controller.
      
      Those two methods both use the same GPIO, and hence whichever of the
      USB controller and regulator gets probed first ends up owning the GPIO.
      In practice, the USB driver only supports path (1) above, since the
      patches to support the new USB binding are not present until v3.12:-(
      
      In practice, the regulator ends up being probed first and owning the
      GPIO. Since nothing enables the regulator (the USB driver code is not
      yet present), the regulator ends up being turned off. This originally
      caused no problem, because the polarity in the regulator definition was
      incorrect, so attempting to turn off the regulator actually turned it
      on, and everything worked:-(
      
      However, when testing the new USB driver code in v3.12, I noticed the
      incorrect polarity and fixed it in commit 9f310ded "ARM: tegra: fix VBUS
      regulator GPIO polarity in DT". In the context of v3.11, this patch then
      caused the USB VBUS to actually turn off, which broke USB ports with VBUS
      control. I got this patch included in v3.11-rc1 since it fixed a bug in
      device tree (incorrect polarity specification), and hence was suitable to
      be included early in the rc series. I evidently did not test the patch at
      all, or correctly, in the context of v3.11, and hence did not notice the
      issue that I have explained above:-(
      
      Fix this by making the USB VBUS regulators always enabled. This way, if
      the regulator owns the GPIO, it will always be turned on, even if there
      is no USB driver code to request the regulator be turned on. Even
      ignoring this bug, this is a reasonable way to configure the HW anyway.
      
      If this patch is applied to v3.11, it will cause a couple pretty trivial
      conflicts in tegra20-{trimslice,seaboard}.dts when creating v3.12, since
      the context right above the added lines changed in patches destined for
      v3.12.
      Reported-by: default avatarKyle McMartin <kmcmarti@redhat.com>
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      30ca2226
  3. 19 Aug, 2013 1 commit
  4. 16 Aug, 2013 4 commits
  5. 14 Aug, 2013 2 commits
  6. 11 Aug, 2013 1 commit
  7. 07 Aug, 2013 2 commits
  8. 04 Aug, 2013 7 commits
  9. 31 Jul, 2013 3 commits
  10. 30 Jul, 2013 9 commits
    • Afzal Mohammed's avatar
      ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space · 50c2a3a1
      Afzal Mohammed authored
      Register target address to be used for cpgmac is the second device
      address space. By default, hwmod picks first address space (0th index)
      for register target.
      
      With removal of address space from hwmod and using DT instead, cpgmac
      is getting wrong address space for register target.
      
      Fix it by indicating the address space to be used for register target.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
      Tested-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      50c2a3a1
    • Afzal Mohammed's avatar
      ARM: OMAP2+: hwmod: rt address space index for DT · 130142d9
      Afzal Mohammed authored
      Address space is being removed from hwmod database and DT information
      in <reg> property is being used. Currently the 0th index of device
      address space is used to map for register target address. This is not
      always true, eg. cpgmac has it's sysconfig in second address space.
      
      Handle it by specifying index of device address space to be used for
      register target. As default value of this field would be zero with
      static initialization, existing behaviour of using first address space
      for register target while using DT would be kept as such.
      Signed-off-by: default avatarAfzal Mohammed <afzal@ti.com>
      Tested-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      [paul@pwsan.com: use u8 rather than int to save memory]
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      130142d9
    • Rajendra Nayak's avatar
      ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state · 7268032d
      Rajendra Nayak authored
      Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
      state post setup(). When a omap_device gets created for such hwmods
      make sure the omap_device and pm_runtime states are also in sync for such
      hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
      device.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarMark Jackson <mpfj-list@newflow.co.uk>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      7268032d
    • Rajendra Nayak's avatar
      ARM: OMAP2+: Avoid idling memory controllers with no drivers · f66e329d
      Rajendra Nayak authored
      Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
      HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.
      
      Even if they have drivers missing, avoid idling them as part of
      omap_device_late_idle()
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Tested-by: default avatarMark Jackson <mpfj-list@newflow.co.uk>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      f66e329d
    • Rajendra Nayak's avatar
      ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL · 7dedd346
      Rajendra Nayak authored
      With commit '82702ea1' "ARM: OMAP2+:
      Fix serial init for device tree based booting" stubbing out
      omap_serial_early_init() for Device tree based booting, there was a
      crash observed on AM335x based devices when hwmod does a
      _setup_reset() early at boot.
      
      This was rootcaused to hwmod trying to reset console uart while
      earlycon was using it.  The way to tell hwmod not to do this is to
      specify the HWMOD_INIT_NO_RESET flag, which were infact set by the
      omap_serial_early_init() function by parsing the cmdline to identify
      the console device.
      
      Parsing the cmdline to identify the uart used by earlycon itself seems
      broken as there is nothing preventing earlycon to use a different one.
      
      This patch, instead, attempts to populate the requiste flags for hwmod
      based on the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need
      for cmdline parsing in the DT as well as non-DT cases to identify the
      uart used by earlycon.
      Signed-off-by: default avatarRajendra Nayak <rnayak@ti.com>
      Reported-by: default avatarMark Jackson <mpfj-list@newflow.co.uk>
      Reported-by: default avatarVaibhav Bedia <vaibhav.bedia@ti.com>
      Tested-by: default avatarMark Jackson <mpfj-list@newflow.co.uk>
      Signed-off-by: default avatarPaul Walmsley <paul@pwsan.com>
      7dedd346
    • Nishanth Menon's avatar
      ARM: dts: omap5-uevm: update optional/unused regulator configurations · bd3c5544
      Nishanth Menon authored
      commit e00c27ef
      (ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
      introduced regulator entries for OMAP5uEVM.
      
      However, The regulator information is based on an older temporary
      pre-production board variant and does not reflect production board
      750-2628-XXX boards.
      
      The following optional/unused regulators can be updated:
      
      - SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be
      enabled only when audio is active. Since it does not come active by
      default, it does not require "always-on" or "boot-on".
      
      - LDO2 and LDO8 do not go to any peripheral or connector on the board.
      Further, these unused regulators should have been 2.8V for LDO2 and
      3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
      Reported-by: default avatarMarc Jüttner <m-juettner@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarJ Keerthy <j-keerthy@ti.com>
      Acked-by: default avatarBenoit Cousson <benoit.cousson@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      bd3c5544
    • Nishanth Menon's avatar
      ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC · e18235a6
      Nishanth Menon authored
      commit e00c27ef
      (ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
      introduced regulator entries for OMAP5uEVM.
      
      However, The regulator information is based on an older temporary
      pre-production board variant and does not reflect production board
      750-2628-XXX boards.
      
      The following fixes are hence mandatory to ensure right voltage is
      supplied to key OMAP5 SoC voltage rails:
      
      - LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
      can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.
      
      To prevent any potential device damage risk, use the specified
      1.5V-1.8V supply.
      
      Remove 'always-on' and 'boot-on' settings here as it is
      a 'on need' supply to SoC IP and is not enabled by PMIC by
      default at boot.
      
      - LDO3 supplies Low Latency Interface(LLI) hardware module which is a
      special hardware to communicate with Modem. However since uEVM is
      not setup by default for this communication, this should be disabled
      by default.
      
      Further, vdda_lli is supposed to be 1.5V and not 3V.
      
      - LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi
      
      This can only be supplied at 1.5V or 1.8V and we currently
      supply 2.2V.
      
      To prevent any potential device damage risk, use the specified
      1.5V-1.8V supply.
      
      Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
      supply to SoC IP and is not enabled by PMIC by default at boot.
      
      - LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
      ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
      1.2V instead of 1.5V.
      
      - LDO7 supplies VDD_VPP which is vpp1. This is currently configured for
      1.5V which as per data manual "A pulse width of 1000 ns and an amplitude
      of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
      be supplied".
      
      So, fix the voltage to 2V. and disable the supply since we have no plans
      of programming efuse bits - it can only be done once - in factory.
      
      Further it is not enabled by default by PMIC so, 'boot-on' must be
      removed, and the 'always-on' needs to be removed to achieve pulsing
      if efuse needs to be programmed.
      
      - LDO9 supplies the board specified vdds_sdcard supply going within SoC
      specification of 1.8V or 3.0V. Further the supply is controlled by
      switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
      be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
      on need basis.
      Reported-by: default avatarMarc Jüttner <m-juettner@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarJ Keerthy <j-keerthy@ti.com>
      Acked-by: default avatarBenoit Cousson <benoit.cousson@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e18235a6
    • Nishanth Menon's avatar
      ARM: dts: omap5-uevm: document regulator signals used on the actual board · 3709d323
      Nishanth Menon authored
      commit e00c27ef
      (ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
      introduced regulator entries for OMAP5uEVM.
      
      However, currently we use the Palmas regulator names which is used for
      different purposes on uEVM. Document the same based on 750-2628-XXX
      boards - which is meant to be supported by this dts.
      Reported-by: default avatarMarc Jüttner <m-juettner@ti.com>
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Acked-by: default avatarJ Keerthy <j-keerthy@ti.com>
      Acked-by: default avatarBenoit Cousson <benoit.cousson@gmail.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      3709d323
    • Kukjin Kim's avatar
      ARM: SAMSUNG: fix to support for missing cpu specific map_io · 35f8550c
      Kukjin Kim authored
      Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
      map_io() is not needed for exynos5440 so need to fix to lookup
      cpu which using map_io(). Without this, kernel boot log complains
      'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
      Signed-off-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      35f8550c
  11. 29 Jul, 2013 4 commits
    • Linus Torvalds's avatar
      Linux 3.11-rc3 · 5ae90d8e
      Linus Torvalds authored
      5ae90d8e
    • Linus Torvalds's avatar
      Merge tag 'pinctrl-for-v3.11-2' of... · 76d25a5f
      Linus Torvalds authored
      Merge tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
      
      Pull pin control fixes from Linus Walleij:
       - Driver fixes for AM33xx, SIRF and PFC pin controllers
       - Fix a compile warning from the pinctrl single-register driver
       - Fix a little nasty memory leak
      
      * tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
        pinctrl: fix a memleak when freeing maps
        pinctrl: pinctrl-single: fix compile warning when no CONFIG_PM
        pinctrl: sh-pfc: fix SDHI0 VccQ regulator on sh73a0 with DT
        arm/dts: sirf: fix the pingroup name mismatch between drivers and dts
        pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart without flowctrl
        pinctrl: sirf: fix the pin number and mux bit for usp0
        pinctrl: am33xx dt binding: correct include path
      76d25a5f
    • Linus Torvalds's avatar
      Merge tag 'trace-fixes-3.11-rc2' of... · 6803f37e
      Linus Torvalds authored
      Merge tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
      
      Pull tracing fixes from Steven Rostedt:
       "Oleg is working on fixing a very tight race between opening a event
        file and deleting that event at the same time (both must be done as
        root).
      
        I also found a bug while testing Oleg's patches which has to do with a
        race with kprobes using the function tracer.
      
        There's also a deadlock fix that was introduced with the previous
        fixes"
      
      * tag 'trace-fixes-3.11-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()
        ftrace: Add check for NULL regs if ops has SAVE_REGS set
        tracing: Kill trace_cpu struct/members
        tracing: Change tracing_fops/snapshot_fops to rely on tracing_get_cpu()
        tracing: Change tracing_entries_fops to rely on tracing_get_cpu()
        tracing: Change tracing_stats_fops to rely on tracing_get_cpu()
        tracing: Change tracing_buffers_fops to rely on tracing_get_cpu()
        tracing: Change tracing_pipe_fops() to rely on tracing_get_cpu()
        tracing: Introduce trace_create_cpu_file() and tracing_get_cpu()
      6803f37e
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 561d9e81
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This is five bug fixes, two of which fix long standing problems
        causing crashes (sd and mvsas).  The remaining three are hung (isci
        race) or lost (qla2xxx, isci) devices"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        [SCSI] isci: fix breakage caused by >16byte CDB patch
        [SCSI] mvsas: Fix kernel panic on tile due to unaligned data access
        [SCSI] sd: fix crash when UA received on DIF enabled device
        [SCSI] qla2xxx: Properly set the tagging for commands.
        [SCSI] isci: Fix a race condition in the SSP task management path
      561d9e81
  12. 26 Jul, 2013 4 commits
    • Rohit Vaswani's avatar
      ARM: msm: Consolidate gpiomux for older architectures · 8fd62389
      Rohit Vaswani authored
      Msm gpiomux can be used only for 7x30 and 8x50.
      Prevent compilation and fix build issues on 7X00, 8X60 and 8960.
      Signed-off-by: default avatarRohit Vaswani <rvaswani@codeaurora.org>
      Signed-off-by: default avatarDavid Brown <davidb@codeaurora.org>
      8fd62389
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 6c504ecf
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "This is just a regular fixes pull apart from the qxl one, it has
        radeon and intel bits in it,
      
        The intel fixes are for a regression with the RC6 fix and a 3.10 hdmi
        regression, whereas radeon is more DPM fixes, a few lockup fixes and
        some rn50/r100 DAC fixes"
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/radeon/dpm: fix r600_enable_sclk_control()
        drm/radeon/dpm: implement force performance levels for rv6xx
        drm/radeon/dpm: fix displaygap programming on rv6xx
        drm/radeon/dpm: fix a typo in the rv6xx mclk setup
        drm/i915: initialize gt_lock early with other spin locks
        drm/i915: fix hdmi portclock limits
        drm/radeon: fix combios tables on older cards
        drm/radeon: improve dac adjust heuristics for legacy pdac
        drm/radeon: Another card with wrong primary dac adj
        drm/radeon: fix endian issues with DP handling (v3)
        drm/radeon/vm: only align the pt base to 32k
        drm/radeon: wait for 3D idle before using CP DMA
      6c504ecf
    • Linus Torvalds's avatar
      Merge branch 'qxl-fixes' of git://people.freedesktop.org/~airlied/linux · 2408c2e5
      Linus Torvalds authored
      Pull qxl drm fixes from Dave Airlie:
       "Okay as I warned, the qxl driver was running a bit free and loose with
        its ttm object reservations and the new lockdep enabled reservation
        tracking shone a bright light into it, it also with the new
        reservations mutexes hits a possible deadlock during boot.
      
        The first patch is a real fix to render the console correctly as the
        driver used to just drop irq renderering as too hard, this also fixes
        a sleeping while atomic warning.
      
        The other two patches are the big ugly ones that redo how the driver
        allocates objects and reserves them and makes things all work
        properly, I've tested this in a VM, and compared to the current code
        which hits a lockdep warning and the sleep while atomic warning before
        failing.
      
        So sorry this is coming in late, I should have tested qxl before
        merging the mutex code, but I'd rather just fix qxl with this than
        revert the reservations code at this point"
      
      * 'qxl-fixes' of git://people.freedesktop.org/~airlied/linux:
        qxl: convert qxl driver to proper use for reservations
        qxl: allow creation of pre-pinned objects and use for releases.
        drm/qxl: add delayed fb operations
      2408c2e5
    • Linus Torvalds's avatar
      Merge tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm · 0f746650
      Linus Torvalds authored
      Pull ACPI and power management fixes from Rafael Wysocki:
       "These are just two fixes, a revert of the would-be backlight fix that
        didn't work and an intel_pstate fix for two problems related to
        maximum P-state selection.
      
        Specifics:
      
         - Revert of the ACPI video commit that I hoped would help fix
           backlight problems related to Windows 8 compatibility on some
           systems.  Unfortunately, it turned out to cause problems to happen
           too.
      
         - Fix for two problems in intel_pstate, a possible failure to respond
           to a load change on a quiet system and a possible failure to select
           the highest available P-state on some systems.  From Dirk
           Brandewie"
      
      * tag 'pm+acpi-3.11-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
        Revert "ACPI / video / i915: No ACPI backlight if firmware expects Windows 8"
        cpufreq / intel_pstate: Change to scale off of max P-state
      0f746650