mbox series

[RFC,0/3] firmware: Add K3 Support for TISCI driver

Message ID 20180605062640.3356-1-nm@ti.com
Headers show
Series firmware: Add K3 Support for TISCI driver | expand

Message

Nishanth Menon June 5, 2018, 6:26 a.m. UTC
Hi,

The following series enables TI System Control Interface(TISCI) support for
the newest addition in TI's SoC portfolio - AM654 SoC.

The series is an RFC based off next-20180604 and will post formally once
v4.18-rc1 is available.

The series (part 4 of 4) is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/next-20180604/k3-4-am6-tisci

Full Boot log is available here: https://pastebin.ubuntu.com/p/vWCzMKtBCW/

The Linux development follows closely the 66AK2G SoC model in aarch64 with a
few additions to handle the flexibility of firmware.

The architecture and dts support depends on part 1 of the series:
https://marc.info/?l=linux-arm-kernel&m=152817866312732&w=2

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

Nishanth Menon (3):
  Documentation: dt: keystone: ti-sci: Add optional host-id parameter
  firmware: ti_sci: Provide host-id as an optional dt parameter
  arm64: dts: ti: k3-am6: Add Device Management Security Controller
    support

 .../devicetree/bindings/arm/keystone/ti,sci.txt    |  4 +++
 arch/arm64/boot/dts/ti/k3-am6.dtsi                 | 32 ++++++++++++++++++++++
 drivers/firmware/ti_sci.c                          | 24 +++++++++++++---
 3 files changed, 56 insertions(+), 4 deletions(-)

-- 
2.15.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Nishanth Menon June 12, 2018, 10:09 p.m. UTC | #1
On 21:39-20180612, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:26:38AM -0500, Nishanth Menon wrote:

> > Texas Instrument's System Control Interface (TISCI) permits the

> > ability for Operating Systems to running in virtual machines to be

> 

> ...for OSs running in virtual...


Ack. thanks.

> 

> > able to independently communicate with the firmware without the need

> > going through an hypervisor.

> > 

> > The "host-id" in effect is the hardware representation of the

> > host (example: VMs locked to a core) as identified to the System

> > Controller.

> 

> So the hypervisor will fill in host-id's for each VM instance?


Yes OR have it's own device tree blobs representation of it's own host
IDs assigned by system firmware. This provides complete independence of
VMs to communicate with the system controller (once the host-id is
provided) without switching to hyp for arbitration (and yes, verified
ability with jailhouse hypervisor and multiple linux instances operating
simultaneously). This also has the added benefit of:
1. The burden of hypervisor from being involved in PM functionality as each
of the VMs can operate autonomously.
2. In TI SoCs which are heterogeneous, the system firmware plays the role
of system master communicating with multiple firmware(running on various
uCs) and OSes running on bigger cores.

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html