Skip to content
  1. Oct 13, 2016
  2. Oct 12, 2016
  3. Oct 11, 2016
  4. Oct 10, 2016
  5. Oct 07, 2016
    • Paul Burton's avatar
      MIPS: generic: Convert SEAD-3 to a generic board · 3f5f0a44
      Paul Burton authored
      
      
      Convert the MIPS SEAD-3 board support to be a generic board, supported
      by generic kernels.
      
      Because the SEAD-3 boot protocol was defined long ago and we don't want
      to force a switch to the UHI protocol, SEAD-3 is added as a legacy board
      which is detected by reading the REVISION register. This may technically
      not be a valid memory read & future work will include attempting to
      handle that gracefully. In practice since SEAD-3 is the only legacy
      board supported by the generic kernel so far the read will only happen
      on SEAD-3 boards, and even once Malta is converted the same REVISION
      register exists there too. Other boards such as Boston, Ci20 & Ci40 will
      use the UHI boot protocol & thus not run any of the legacy board detect
      functions.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14354/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      3f5f0a44
    • Paul Burton's avatar
      MIPS: generic: Introduce generic DT-based board support · eed0eabd
      Paul Burton authored
      
      
      Introduce a "generic" platform, which aims to be board-agnostic by
      making use of device trees passed by the boot protocol defined in the
      MIPS UHI (Universal Hosting Interface) specification. Provision is made
      for supporting boards which use a legacy boot protocol that can't be
      changed, but adding support for such boards or any others is left to
      followon patches.
      
      Right now the built kernels expect to be loaded to 0x80100000, ie. in
      kseg0. This is fine for the vast majority of MIPS platforms, but
      nevertheless it would be good to remove this limitation in the future by
      mapping the kernel via the TLB such that it can be loaded anywhere & map
      itself appropriately.
      
      Configuration is handled by dynamically generating configs using
      scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc
      makes use of it. This allows for variations upon the configuration, eg.
      differing architecture revisions or subsets of driver support for
      differing boards, to be handled without having a large number of
      defconfig files.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14353/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      eed0eabd
    • Paul Burton's avatar
      MIPS: Support generating Flattened Image Trees (.itb) · cf2a5e0b
      Paul Burton authored
      
      
      Add support for generating kernel images in the Flattened Image Tree
      (.itb) format as supported by U-Boot. This format is essentially a
      Flattened Device Tree binary containing images (kernels, DTBs, ramdisks)
      and configurations which link those images together. The big advantages
      of FIT images over the uImage format are:
      
        - We can include FDTs in the kernel image in a way that the bootloader
          can extract it & manipulate it before providing it to the kernel.
          Thus we can ship FDTs as part of the kernel giving us the advantages
          of being able to develop & maintain the DT within the kernel tree,
          but also have the benefits of the bootloader being able to
          manipulate the FDT. Example uses for this would be to inject the
          kernel command line into the chosen node, or to fill in the correct
          memory size.
      
        - We can include multiple configurations in a single kernel image.
          This means that a single FIT image can, given appropriate
          bootloaders, be booted on different boards with the bootloader
          selecting an appropriate configuration & providing the correct FDT
          to the kernel.
      
        - We can support a multitude of hashes over the data.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14352/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      cf2a5e0b
    • Paul Burton's avatar
      MIPS: Adjust MIPS64 CAC_BASE to reflect Config.K0 · 3ffc17d8
      Paul Burton authored
      
      
      On MIPS64 we define the default CAC_BASE as one of the xkphys regions of
      the virtual address space. Since the CCA is encoded in bits 61:59 of
      xkphys addresses, fixing CAC_BASE to any particular one prevents us from
      dynamically changing the CCA as we do for MIPS32 where CAC_BASE is
      placed within kseg0. In order to make the kernel more generic, drop the
      current kludge that gives CAC_BASE CCA=3 if CONFIG_DMA_NONCOHERENT is
      selected (disregarding CONFIG_DMA_MAYBE_COHERENT) & CCA=5 (which is not
      standardised by the architecture) otherwise. Instead read Config.K0 and
      generate the appropriate offset into xkphys, presuming that either the
      bootloader or early kernel code will have configured Config.K0
      appropriately. This seems like the best option for a generic
      implementation.
      
      The ip27 spaces.h is adjusted to set its former value of CAC_BASE, since
      it's the only user of CAC_BASE from assembly (in its smp_slave_setup
      macro). This allows the generic case to focus solely on C code without
      breaking ip27.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14351/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      3ffc17d8
    • Paul Burton's avatar
      MIPS: Print CM error reports upon bus errors · dabdc185
      Paul Burton authored
      
      
      If a bus error occurs on a system with a MIPS Coherence Manager (CM)
      then the CM may hold useful diagnostic information. Printing this out
      has so far been left up to boards, with the requirement that they
      register a board_be_handler function & call mips_cm_error_decode() from
      there.
      
      In order to avoid boards other than Malta needing to duplicate this
      code, call mips_cm_error_decode() automatically if the board registers
      no board_be_handler, and remove the Malta implementation of that.
      
      This patch results in no functional change, but removes a further piece
      of platform-specific code.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14350/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      dabdc185
    • Paul Burton's avatar
      MIPS: Support per-device DMA coherence · 20d33064
      Paul Burton authored
      
      
      On some MIPS systems, a subset of devices may have DMA coherent with CPU
      caches. For example in systems including a MIPS I/O Coherence Unit
      (IOCU), some devices may be connected to that IOCU whilst others are
      not.
      
      Prior to this patch, we have a plat_device_is_coherent() function but no
      implementation which does anything besides return a global true or
      false, optionally chosen at runtime. For devices such as those described
      above this is insufficient.
      
      Fix this by tracking DMA coherence on a per-device basis with a
      dma_coherent field in struct dev_archdata. Setting this from
      arch_setup_dma_ops() takes care of devices which set the dma-coherent
      property via device tree, and any PCI devices beneath a bridge described
      in DT, automatically.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14349/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      20d33064
    • Paul Burton's avatar
      MIPS: dma-default: Don't check hw_coherentio if device is non-coherent · cfa93fb9
      Paul Burton authored
      
      
      There are no cases where plat_device_is_coherent() will return zero
      whilst hw_coherentio is non-zero, and acting any differently in such a
      case doesn't make much sense - if a device is non-coherent with the CPU
      caches then access to memory "coherent" with DMA must be uncached. Clean
      up the nonsensical case.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14348/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      cfa93fb9
    • Paul Burton's avatar
      MIPS: Sanitise coherentio semantics · f2302023
      Paul Burton authored
      
      
      The coherentio variable has previously been used as a boolean value,
      indicating whether the user specified that coherent I/O should be
      enabled or disabled. It failed to take into account the case where the
      user does not specify any preference, in which case it makes sense that
      we should default to coherent I/O if the hardware supports it
      (hw_coherentio is non-zero).
      
      Introduce an enum to clarify the 3 different values of coherentio & use
      it throughout the code, modifying plat_device_is_coherent() &
      r4k_cache_init() to take into account the default case.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Paul Burton <paul.burton@imgtec.com>
      Patchwork: https://patchwork.linux-mips.org/patch/14347/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      f2302023
    • Paul Burton's avatar
      MIPS: PCI: Support generic drivers · 87dd9a4d
      Paul Burton authored
      
      
      Introduce support for PCI drivers using only functionality provided
      generically by the PCI subsystem, by adding the minimum arch-provided
      functions required.
      
      The driver this has been developed for & tested with the xilinx-pcie on
      a MIPS Boston development board.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14346/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      87dd9a4d
    • Paul Burton's avatar
      MIPS: PCI: Introduce CONFIG_PCI_DRIVERS_LEGACY · c5611df9
      Paul Burton authored
      
      
      Introduce 2 Kconfig symbols, CONFIG_PCI_DRIVERS_GENERIC &
      CONFIG_PCI_DRIVERS_LEGACY, which indicate whether the system should be
      built to for PCI drivers using the MIPS-specific struct pci_controller
      API (hereafter "legacy" drivers) or more generic drivers using only
      functionality provided by the PCI core (hereafter "generic" drivers).
      
      The Kconfig entries are created such that platforms have to select
      CONFIG_PCI_DRIVERS_GENERIC if they wish to use it - that is, the default
      is CONFIG_PCI_DRIVERS_LEGACY so that existing platforms need no
      modification.
      
      The functions declared in pci.h are rearranged with those provided only
      by pci-legacy.c being guarded by an #ifdef CONFIG_PCI_DRIVERS_LEGACY to
      ensure they are only used in configurations where they are implemented.
      
      Signed-off-by: default avatarPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14345/
      
      
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      c5611df9
  6. Oct 06, 2016