In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Secure Proxy is another communication scheme in Texas Instrument's
devices intended to provide an unique communication path from various
processors in the System on Chip(SoC) to a central System Controller.
Secure proxy is, in effect, an evolution of current generation Message
Manager hardware block found in K2G devices. However the following
changes have taken place:
Secure Proxy instance exposes "threads" or "proxies" which is
primary representation of "a" communication channel. Each thread is
preconfigured by System controller configuration based on SoC usage
requirements. Secure proxy by itself represents a single "queue" of
communication but allows the proxies to be independently operated.
Each Secure proxy thread can uniquely have their own error and threshold
interrupts allowing for more fine control of IRQ handling.
Provide the driver support for Secure Proxy and thread instances.
NOTE: Secure proxy configuration is only done by System Controller,
hence these are assumed to be pre-configured instances.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
For newer generation of the hardware, the naming of the region is
decided at integration level and there could be additional regions
as well. Hence move the region naming to be described from compatible
descriptor.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Change mask used to extract the message count to be descriptor based.
This is to support changes for count location for various SoC
solutions.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
In a much bigger system SoCs, the number of Rx channels can be
many and mostly unused based on the system of choice, and not all
Rx channels need IRQs and allocating all memory at probe will be
inefficient. Some SoCs could have total threads in the 100s and usage
would be just 1 Rx thread.
Thus, request and map the IRQs and allocate memory only when needed.
Since these channels are requested by client drivers on need, our
utilization will be optimal.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Though q_proxies and q_slices do describe the hardware configuration,
they are not necessary for operation given that the values are
always default. Hence drop the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
message->len is of type size_t and %d is incorrect format usage.
Instead use %zu for handling size_t correctly.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Switch to SPDX licensing and drop the GPL text which comes redundant.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Support for TI Message Manager Module. This hardware block manages a
bunch of hardware queues meant for communication between processor
entities.
Clients sitting on top of this would manage the required protocol
for communicating with the counterpart entities.
For more details on TI Message Manager hardware block, see documentation
that will is available here: http://www.ti.com/lit/ug/spruhy8/spruhy8.pdf
Chapter 8.1(Message Manager)
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Rob Herring