Skip to content

L
linux
Switch branch/tag
  1. 05 Aug, 2014 29 commits
  3. 31 Jul, 2014 2 commits
    • Shengzhou Liu's avatar
      powerpc/t2080rdb: Add T2080RDB board support · 78eb9094
      Shengzhou Liu authored 
      T2080PCIe-RDB is a Freescale Reference Design Board that hosts T2080 SoC.
The board feature overview:
Processor:
 - T2080 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz
DDR Memory:
 - Single memory controller capable of supporting DDR3 and DDR3-LP devices
 - 72bit 4GB DDR3-LP SODIMM in slot
Ethernet interfaces:
 - Two 1Gbps RGMII ports on-board
 - Two 10Gbps SFP+ ports on-board
 - Two 10Gbps Base-T ports on-board
Accelerator:
 - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC
IFC/Local Bus
 - NOR:  128MB 16-bit NOR flash
 - NAND: 1GB 8-bit NAND flash
 - CPLD: for system controlling with programable header on-board
eSPI:
 - 64MB N25Q512 SPI flash
USB:
 - Two USB2.0 ports with internal PHY (both Type-A)
PCIe:
 - One PCIe x4 goldfinger(support SR-IOV)
 - One PCIe x4 slot
 - One PCIe x2 end-point device (C293 crypto co-processor)
SATA:
 - Two SATA 2.0 ports on-board
SDHC:
 - support a MicroSD/TF card on-board
I2C:
 - Four I2C controllers.
UART:
 - Dual 4-pins UART serial ports
Signed-off-by: default avatarShengzhou Liu <Shengzhou.Liu@freescale.com>
Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      78eb9094
    • Priyanka Jain's avatar
      powerpc/85xx: Add binding for CPLD · dd2b04fc
      Priyanka Jain authored 
      Some Freescale boards like T1040RDB have an on board CPLD connected on
the IFC bus. Add binding for cpld in board.txt file
Signed-off-by: default avatarPriyanka Jain <Priyanka.Jain@freescale.com>
Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      dd2b04fc
  5. 30 Jul, 2014 6 commits
  7. 28 Jul, 2014 3 commits
    • Benjamin Herrenschmidt's avatar
      Add Michael Ellerman as powerpc co-maintainer · ea668936
      Benjamin Herrenschmidt authored 
      Michael has been backing me up and helping will all aspects of
maintainership for a while now, let's make it official.
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      ea668936
    • Michael Ellerman's avatar
      powerpc/perf: Add per-event excludes on Power8 · 9de5cb0f
      Michael Ellerman authored 
      Power8 has a new register (MMCR2), which contains individual freeze bits
for each counter. This is an improvement on previous chips as it means
we can have multiple events on the PMU at the same time with different
exclude_{user,kernel,hv} settings. Previously we had to ensure all
events on the PMU had the same exclude settings.

The core of the patch is fairly simple. We use the 207S feature flag to
indicate that the PMU backend supports per-event excludes, if it's set
we skip the generic logic that enforces the equality of excludes between
events. We also use that flag to skip setting the freeze bits in MMCR0,
the PMU backend is expected to have handled setting them in MMCR2.

The complication arises with EBB. The FCxP bits in MMCR2 are accessible
R/W to a task using EBB. Which means a task using EBB will be able to
see that we are using MMCR2 for freezing, whereas the old logic which
used MMCR0 is not user visible.

The task can not see or affect exclude_kernel & exclude_hv, so we only
need to consider exclude_user.

The table below summarises the behaviour both before and after this
commit is applied:

 exclude_user           true  false
 ------------------------------------
        | User visible |  N    N
 Before | Can freeze   |  Y    Y
        | Can unfreeze |  N    Y
 ------------------------------------
        | User visible |  Y    Y
  After | Can freeze   |  Y    Y
        | Can unfreeze |  Y/N  Y
 ------------------------------------

So firstly I assert that the simple visibility of the exclude_user
setting in MMCR2 is a non-issue. The event belongs to the task, and
was most likely created by the task. So the exclude_user setting is not
privileged information in any way.

Secondly, the behaviour in the exclude_user = false case is unchanged.
This is important as it is the case that is actually useful, ie. the
event is created with no exclude setting and the task uses MMCR2 to
implement exclusion manually.

For exclude_user = true there is no meaningful change to freezing the
event. Previously the task could use MMCR2 to freeze the event, though
it was already frozen with MMCR0. With the new code the task can use
MMCR2 to freeze the event, though it was already frozen with MMCR2.

The only real change is when exclude_user = true and the task tries to
use MMCR2 to unfreeze the event. Previously this had no effect, because
the event was already frozen in MMCR0. With the new code the task can
unfreeze the event in MMCR2, but at some indeterminate time in the
future the kernel will overwrite its setting and refreeze the event.

Therefore my final assertion is that any task using exclude_user = true
and also fiddling with MMCR2 was deeply confused before this change, and
remains so after it.
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      9de5cb0f
    • Michael Ellerman's avatar
      powerpc/perf: Pass the struct perf_events down to compute_mmcr() · 8abd818f
      Michael Ellerman authored 
      To support per-event exclude settings on Power8 we need access to the
struct perf_events in compute_mmcr().
Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      8abd818f
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7