| 34b3eb14 | 11-Feb-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: common: Do not release processor control on startup
ATF should be the only host needing to control a processor that it has started. ATF will need this control to stop the core later. Do not
ti: k3: common: Do not release processor control on startup
ATF should be the only host needing to control a processor that it has started. ATF will need this control to stop the core later. Do not relinquish control of a core after starting the core.
Signed-off-by: Andrew F. Davis <afd@ti.com>
show more ...
|
| a9ae424e | 11-Feb-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: drivers: ti_sci: Use non-blocking TI-SCI messages for power down
Now that we have non-blocking TI-SCI functions we can initiate the shutdown sequence from the PSCI handler without needing th
ti: k3: drivers: ti_sci: Use non-blocking TI-SCI messages for power down
Now that we have non-blocking TI-SCI functions we can initiate the shutdown sequence from the PSCI handler without needing the ti_sci_proc_shutdown helper function, which is removed. This gives us the greater control and flexibility that will be needed when cluster power down sequences are added.
Signed-off-by: Andrew F. Davis <afd@ti.com>
show more ...
|
| e9152c13 | 11-Feb-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: drivers: ti_sci: Add non-blocking TI-SCI messages
Most TI-SCI functions request an ACK and wait until it is received. For some power sequence tasks we cannot wait but instead queue messages
ti: k3: drivers: ti_sci: Add non-blocking TI-SCI messages
Most TI-SCI functions request an ACK and wait until it is received. For some power sequence tasks we cannot wait but instead queue messages asynchronously. Three messages have been identified that will need to be used in this way. Add non-waiting versions of these functions.
Signed-off-by: Andrew F. Davis <afd@ti.com>
show more ...
|
| 60d23323 | 11-Feb-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: drivers: ti_sci: Request and check for ACK by default
Currently almost all TI-SCI messages request and check for an ACK from the system firmware. Move this into a common place to remove the
ti: k3: drivers: ti_sci: Request and check for ACK by default
Currently almost all TI-SCI messages request and check for an ACK from the system firmware. Move this into a common place to remove the same from each function.
Signed-off-by: Andrew F. Davis <afd@ti.com>
show more ...
|
| b3ca8aab | 11-Feb-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: drivers: ti_sci: Add exclusive device accessors
When a device is requested with TI-SCI its control can be made exclusive to the requesting host. This was currently the default but is not wha
ti: k3: drivers: ti_sci: Add exclusive device accessors
When a device is requested with TI-SCI its control can be made exclusive to the requesting host. This was currently the default but is not what is needed most of the time. Add _exclusive versions of the request functions and remove the exclusive flag from the default version.
Signed-off-by: Andrew F. Davis <afd@ti.com>
show more ...
|
| b5443284 | 22-Jan-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: common: Add support for runtime detection of GICR base address
Valid addresses for GICR base are always a set calculable distance from the GICD and is based on the number of cores a given in
ti: k3: common: Add support for runtime detection of GICR base address
Valid addresses for GICR base are always a set calculable distance from the GICD and is based on the number of cores a given instance of GICv3 IP can support. The formula for the number of address bits is given by the ARM GIC-500 TRM section 3.2 as 2^(18+log2(cores)) with the MSB set to one for GICR instances. Holes in the GIC address space are also guaranteed to safely return 0 on reads. This allows us to support runtime detection of the GICR base address by starting from GIC base address plus BIT(18) and walking until the GICR ID register (IIDR) is detected. We stop searching after BIT(20) to prevent searching out into space if something goes wrong. This can be extended out if we ever have a device with 16 or more cores.
Signed-off-by: Andrew F. Davis <afd@ti.com>
show more ...
|
| 73522f00 | 04-Jan-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: drivers: ti_sci: Clear receive queue before transmitting
Send and receive currently must be be serialized, any message already in the receive queue when a new message is to be sent will caus
ti: k3: drivers: ti_sci: Clear receive queue before transmitting
Send and receive currently must be be serialized, any message already in the receive queue when a new message is to be sent will cause a mismatch with the expected response from this new message. Clear out all messages from the response queue before sending a new request.
Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Nishanth Menon <nm@ti.com>
show more ...
|
| ca3d3414 | 03-Jan-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: common: Use shutdown API for PSCI core poweroff
To ensure WFI is reached before the PSC is trigger to power-down a processor, the shutdonw API must be used.
Signed-off-by: Andrew F. Davis <
ti: k3: common: Use shutdown API for PSCI core poweroff
To ensure WFI is reached before the PSC is trigger to power-down a processor, the shutdonw API must be used.
Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Nishanth Menon <nm@ti.com>
show more ...
|
| 72f418e0 | 03-Jan-2019 |
Andrew F. Davis <afd@ti.com> |
ti: k3: drivers: ti_sci: Add processor shutdown API
This is a pseudo-API command consisting of a wait processor status command and a set device state command queued back-to-back without waiting for
ti: k3: drivers: ti_sci: Add processor shutdown API
This is a pseudo-API command consisting of a wait processor status command and a set device state command queued back-to-back without waiting for the System Firmware to ACK either message.
This is needed as the K3 power down specification states the System Firmware must wait for a processor to be in WFI/WFE before powering it down. The current implementation of System Firmware does not provide such a command. Also given that with PSCI the core to be shutdown is the core that is processing the shutdown request, the core cannot itself wait for its own WFI/WFE status. To workaround this limitation, we submit a wait processor status command followed by the actual shutdown command. The shutdown command will not be processed until the wait command has finished. In this way we can continue to WFI before the wait command status has been met or timed-out and the shutdown command is processed.
Signed-off-by: Andrew F. Davis <afd@ti.com> Acked-by: Nishanth Menon <nm@ti.com>
show more ...
|