On Thu, Jan 14, 2016 at 10:26 PM, Mark Brown broonie@linaro.org wrote:
On 14 January 2016 at 13:27, Chunyan Zhang zhang.chunyan@linaro.org wrote:
On Thu, Jan 14, 2016 at 9:20 PM, Mike Leach Mike.Leach@arm.com wrote:
If I have understood this correctly then there is a significant issue here - for the ARM STM hardware in the recommended configuration (i.e. on something like Juno) the masters are hardware allocated to sources -that is cores + S/NS security state. Therefore there is no concept of software applications being able to poll available masters - there is only one master and the number is fixed for a source core+S/NS state. If the application is later scheduled on a different core, then the hardware master number will change - and the high level decoder is likely to lose track of the application.
Right, right, if we only consider ARM STM. But this documentation is describing Intel STM as well :)
I guess it's worth explicitly separating the application visible model from the hardware model, saying that we may do things like simplify the view the application has of the system in order to handle hardware requirements like this?
From the user view, how to show master to the users do you think is
more clear and more easier to understand this kind of hardware requirements (i.e. users are not able to choose master) for users? Would it be better if hiding "master" ABI from users for this kind of hardware configuration?
Thanks, Chunyan