1. 23 4月, 2015 1 次提交
  2. 22 4月, 2015 1 次提交
  3. 20 4月, 2015 2 次提交
  4. 17 4月, 2015 3 次提交
  5. 16 4月, 2015 1 次提交
    • M
      Doc: dt: arch_timer: discourage clock-frequency use · 4155fc07
      Mark Rutland 提交于
      The ARM Generic Timer (AKA the architected timer, arm_arch_timer)
      features a CPU register (CNTFRQ) which firmware is intended to
      initialize, and non-secure software can read to determine the frequency
      of the timer. On CPUs with secure state, this register cannot be written
      from non-secure states.
      
      The firmware of early SoCs featuring the timer did not correctly
      initialize CNTFRQ correctly on all CPUs, requiring the frequency to be
      described in DT as a workaround. This workaround is not complete however
      as it is exposed to all software in a privileged non-secure mode
      (including guests running under a hypervisor). The firmware and DTs for
      recent SoCs have followed the example set by these early SoCs.
      
      This patch updates the arch timer binding documentation to make it
      clearer that the use of the clock-frequency property is a poor
      work-around. The MMIO generic timer binding is similarly updated, though
      this is less of a concern as there is generally no need to expose the
      MMIO timers to guest OSs.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Acked-by: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NRob Herring <robh@kernel.org>
      4155fc07
  6. 15 4月, 2015 2 次提交
  7. 13 4月, 2015 1 次提交
  8. 11 4月, 2015 4 次提交
  9. 10 4月, 2015 2 次提交
  10. 09 4月, 2015 6 次提交
  11. 08 4月, 2015 2 次提交
  12. 07 4月, 2015 7 次提交
  13. 06 4月, 2015 1 次提交
    • B
      Documentation: devicetree: m25p80: add "nor-jedec" binding · 8ff16cf7
      Brian Norris 提交于
      Almost all flash that are "compatible" with m25p80 support the JEDEC
      READ ID opcode (0x9F), and in fact, that is often the only thing that is
      used to differentiate them. Let's add a compatible string that
      represents this lowest common denominator of compatibility.
      
      Device trees can still specify manufacturer/device names in addition,
      but (until some reason is found to differentiate between them through
      device tree) software will likely want to bind just against the generic
      name, and avoid unnecessarily growing its device ID binding tables.
      
      This is related to the work of commit a5b7616c ("mtd:
      m25p80,spi-nor: Fix module aliases for m25p80"), which showed that
      maintaining these device tables as stable device-tree/modalias binding
      tables is not a worthwhile burden for mostly-comptatible flash.
      
      At the same time, let's update the binding doc to point to the
      m25p_ids[] ID list instead of spi_nor_ids[]. The former can be used for
      device tree bindings, but the latter cannot. In the future, we should
      pare down the m25p_ids[] list to only those IDs which are actually used
      in device trees.
      Signed-off-by: NBrian Norris <computersforpeace@gmail.com>
      Cc: Rafał Miłecki <zajec5@gmail.com>
      Reviewed-by: NMarek Vasut <marex@denx.de>
      8ff16cf7
  14. 04 4月, 2015 6 次提交
  15. 03 4月, 2015 1 次提交