1. 22 Nov, 2012 5 commits
    • Thomas Petazzoni's avatar
      dma: mv_xor: use request_irq() instead of devm_request_irq() · 2d0a0745
      Thomas Petazzoni authored
      Even through the usage of devm_*() functions is generally recommended
      over their classic variants, in the case of devm_request_irq()
      combined with irq_of_parse_and_map(), it doesn't work nicely.
      
      We have the following scenario:
      
       irq_of_parse_and_map(...)
       devm_request_irq(...)
      
      For some reason, the driver initialization fails at a later
      point. Since irq_of_parse_and_map() is no device-managed, we do a:
      
       irq_dispose_mapping(...)
      
      Unfortunately, this doesn't work, because the free_irq() must be done
      prior to calling irq_dispose_mapping(). But with the devm mechanism,
      the automatic free_irq() would happen only after we get out of the
      ->probe() function.
      
      So basically, we revert to using request_irq() with traditional error
      handling, so that in case of error, free_irq() gets called before
      irq_dispose_mapping().
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      2d0a0745
    • Thomas Petazzoni's avatar
      dma: mv_xor: clear the window override control registers · c4b4b732
      Thomas Petazzoni authored
      The XOR channels on Marvell SoCs have a Window Override Control
      register that allow to do some fancy things with addresses. Those
      features are not used by the driver, but some U-Boot versions anyway
      modify those registers.
      
      For some reason, the U-Boot on OpenBlocks AX3-4 was setting an invalid
      value in those registers when the addition 2 GB DRAM chip was plugged
      into the board, causing the XOR driver to fail in using the XOR
      engines.
      
      By setting those registers to 0 during the driver initialization, we
      ensure that the registers are configured according with the driver
      operation model.
      
      Thanks to Lior Amsalem <alior@marvell.com> for his help in debugging
      this problem.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      c4b4b732
    • Thomas Petazzoni's avatar
      arm: mvebu: fix address decoding armada_cfg_base() function · 9f3410ff
      Thomas Petazzoni authored
      The armada_cfg_base() function returns the base address of the
      registers that allow to configure the decoding for a particular
      address window. On Armada 370/XP, the lower windows have more
      configuration registers (4 registers) than the higher windows (2
      registers). This armada_cfg_base() takes this into account by doing a
      different offset calculation depending on the window number, but this
      offset calculation was wrong for the higher windows.
      
      Even though we were not using high window numbers until now (only
      window 0 is used to map the BootROM, needed for SMP), we use this
      function at boot time to disable all windows to ensure that nothing
      remains intialized from what the bootloader has done.
      
      Unfortunately, the U-Boot on the OpenBlocks AX3-4 uses a window with a
      high number (above 8) to remap the BootROM. And then when the kernel
      boots, it remaps the BootROM in window 0. Normally, this is not a
      problem, because all windows have previously been disabled. Except
      that due to our wrong offset calculation, the windows with high
      numbers were not properly disabled, leading to the BootROM being
      mapped twice. The visible result of this bug was that the kernel was
      unable to get the second CPU started on the OpenBlocks AX3-4
      platform. With this fix, all windows are properly cleared at boot
      time, the BootROM is remapped only once in window 0, and the second
      CPU boots fine.
      
      Thanks a lot to Lior Amsamlen <alior@marvell.com> for his help in
      debugging this problem.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      ---
      Strictly speaking, this bug was introduced in 3.7, but since the only
      platforms supported in 3.7 were Armada 370 and Armada XP, and there
      was anyway no SMP support at this time, it isn't really worth the
      effort to push this patch in 3.7.
      9f3410ff
    • Thomas Petazzoni's avatar
      Merge tag 'marvell-armadaxp-smp-for-3.8' of... · 1112b360
      Thomas Petazzoni authored
      Merge tag 'marvell-armadaxp-smp-for-3.8' of github.com:MISL-EBU-System-SW/mainline-public into mevbu-dt-additions
      
      SMP support for Armada XP
      
      The purpose of this series is to add the SMP support for the Armada XP
      SoCs. Beside the SMP support itself brought by the last 3 commits,
      this series also adds the support for the coherency fabric unit and
      the power management service unit.
      
      The coherency fabric is responsible for ensuring hardware coherency
      between all CPUs and between CPUs and I/O masters. This unit is also
      available for Armada 370 and will be used in an incoming patch set
      for hardware I/O cache coherency.
      
      The power management service unit is responsible for powering down and
      waking up CPUs and other SOC units.
      
      Conflicts:
      	arch/arm/mach-mvebu/armada-370-xp.c
      1112b360
    • Thomas Petazzoni's avatar
  2. 21 Nov, 2012 10 commits
  3. 20 Nov, 2012 25 commits