[PATCH] crypto: ecdh_helper - Ensure 'len >= secret.len' in decode_key()
From: Daniele Alessandrelli
The length ('len' parameter) passed to crypto_ecdh_decode_key() is never
checked against the length encoded in the passed buffer ('buf'
parameter). This could lead to an out-of-bounds access when the passed
length is less than the encoded length.
Add a check to prevent that.
Signed-off-by: Daniele Alessandrelli
---
crypto/ecdh_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/ecdh_helper.c b/crypto/ecdh_helper.c
index 66fcb2ea8154..fca63b559f65 100644
--- a/crypto/ecdh_helper.c
+++ b/crypto/ecdh_helper.c
@@ -67,6 +67,9 @@ int crypto_ecdh_decode_key(const char *buf, unsigned int len,
if (secret.type != CRYPTO_KPP_SECRET_TYPE_ECDH)
return -EINVAL;
+ if (unlikely(len < secret.len))
+ return -EINVAL;
+
ptr = ecdh_unpack_data(¶ms->curve_id, ptr,
sizeof(params->curve_id));
ptr = ecdh_unpack_data(¶ms->key_size, ptr,
sizeof(params->key_size));
if (secret.len != crypto_ecdh_key_len(params))
--
2.26.2
[PATCH] crypto: keembay-ocs-aes - Fix 'q' assignment during CCM B0 generation
From: Daniele Alessandrelli
In ocs_aes_ccm_write_b0(), 'q' (the octet length of the binary
representation of the octet length of the payload) is set to 'iv[0]',
while it should be set to 'iv[0] & 0x7' (i.e., only the last 3
bits of iv[0] should be used), as documented in NIST Special Publication
800-38C:
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
In practice, this is not an issue, since 'iv[0]' is checked to be in the
range [1-7] by ocs_aes_validate_inputs(), but let's fix the assignment
anyway, in order to make the code more robust.
Signed-off-by: Daniele Alessandrelli
---
drivers/crypto/keembay/ocs-aes.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/keembay/ocs-aes.c b/drivers/crypto/keembay/ocs-aes.c
index b85c89477afa..be9f32fc8f42 100644
--- a/drivers/crypto/keembay/ocs-aes.c
+++ b/drivers/crypto/keembay/ocs-aes.c
@@ -1080,15 +1080,15 @@ static int ocs_aes_ccm_write_b0(const struct
ocs_aes_dev *aes_dev,
/*
* q is the octet length of Q.
* q can only be an element of {2, 3, 4, 5, 6, 7, 8} and is encoded as
-* q - 1 == iv[0]
+* q - 1 == iv[0] & 0x7;
*/
b0[0] |= iv[0] & 0x7;
/*
* Copy the Nonce N from IV to B0; N is located in iv[1]..iv[15 - q]
* and must be copied to b0[1]..b0[15-q].
-* q == iv[0] + 1
+* q == (iv[0] & 0x7) + 1
*/
- q = iv[0] + 1;
+ q = (iv[0] & 0x7) + 1;
for (i = 1; i <= 15 - q; i++)
b0[i] = iv[i];
/*
--
2.26.2
Re: [PATCH v7 4/7] crypto: add ecc curve and expose them
On Thu, 2021-01-28 at 21:39 +1100, Herbert Xu wrote: > Once they're distinct algorithms, we can then make sure that only > the ones that are used in the kernel is added, even if some hardware > may support more curves. I like the idea of having different algorithms names (ecdh-nist- pXXX) for different curves, but I'm not fully convinced by the above statement. What's the downside of letting device drivers enable all the curves supported by the HW (with the exception of obsolete curves / algorithms), even if there is (currently) no user of such curves in the kernel? Code size and maintainability? I think that once there is support for certain curves, it's more likely that drivers / modules using them will appear. Also, even if there are no in-tree users, there might be a few out-of- tree ones.
Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
On Tue, 2020-12-08 at 20:48 +0100, Greg KH wrote: > On Tue, Dec 08, 2020 at 06:59:09PM +0000, Daniele Alessandrelli wrote: > > Hi Greg, > > > > Thanks for your feedback. > > > > On Wed, 2020-12-02 at 07:19 +0100, Greg KH wrote: > > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote: > > > > From: Daniele Alessandrelli > > > > > > > > On the Intel Movidius SoC code named Keem Bay, communication between the > > > > Computing Sub-System (CSS), i.e., the CPU, and the Multimedia Sub-System > > > > (MSS), i.e., the VPU is enabled by the Keem Bay Inter-Processor > > > > Communication (IPC) mechanism. > > > > > > > > Add the driver for using Keem Bay IPC from within the Linux Kernel. > > > > > > > > Keem Bay IPC uses the following terminology: > > > > > > > > - Node:A processing entity that can use the IPC to communicate; > > > >currently, we just have two nodes, CPU (CSS) and VPU (MSS). > > > > > > > > - Link:Two nodes that can communicate over IPC form an IPC link > > > >(currently, we just have one link, the one between the CPU > > > >and VPU). > > > > > > > > - Channel: An IPC link can provide multiple IPC channels. IPC channels > > > >allow communication multiplexing, i.e., the same IPC link can > > > >be used by different applications for different > > > >communications. Each channel is identified by a channel ID, > > > >which must be unique within a single IPC link. Channels are > > > >divided in two categories, High-Speed (HS) channels and > > > >General-Purpose (GP) channels. HS channels have higher > > > >priority over GP channels. > > > > > > > > Keem Bay IPC mechanism is based on shared memory and hardware FIFOs. > > > > Both the CPU and the VPU have their own hardware FIFO. When the CPU > > > > wants to send an IPC message to the VPU, it writes to the VPU FIFO (MSS > > > > FIFO); similarly, when MSS wants to send an IPC message to the CPU, it > > > > writes to the CPU FIFO (CSS FIFO). > > > > > > > > A FIFO entry is simply a pointer to an IPC buffer (aka IPC header) > > > > stored in a portion of memory shared between the CPU and the VPU. > > > > Specifically, the FIFO entry contains the (VPU) physical address of the > > > > IPC buffer being transferred. > > > > > > > > In turn, the IPC buffer contains the (VPU) physical address of the > > > > payload (which must be located in shared memory too) as well as other > > > > information (payload size, IPC channel ID, etc.). > > > > > > > > Each IPC node instantiates a pool of IPC buffers from its own IPC buffer > > > > memory region. When instantiated, IPC buffers are marked as free. When > > > > the node needs to send an IPC message, it gets the first free buffer it > > > > finds (from its own pool), marks it as allocated (used), and puts its > > > > physical address into the IPC FIFO of the destination node. The > > > > destination node (which is notified by an interrupt when there are > > > > entries pending in its FIFO) extract the physical address from the FIFO > > > > and process the IPC buffer, marking it as free once done (so that the > > > > sender can reuse the buffer). > > > > > > Any reason you can't use the dmabuf interface for these memory buffers > > > you are creating and having to manage "by hand"? I thought that was > > > what the kernel was wanting to unify on such that individual > > > drivers/subsystems didn't have to do this on their own. > > > > My understanding is that the dmabuf interface is used to share DMA > > buffers across different drivers, while these buffers are used only > > internally to the IPC driver (and exchanged only with the VPU > > firmware). They basically are packet headers that are sent to the VPU. > > There's no reason you couldn't use these to share your buffers > "internally" as well, because you have the same lifetime rules and > accounting and all other sorts of things you have to handle, right? Why > rewrite something like this when you should take advantage of common > code instead? I looked at dma-buf again, but I'm still failing to see how we can use it i
Re: [PATCH 02/22] dt-bindings: Add bindings for Keem Bay IPC driver
Hi Rob, Thanks for the feedback. On Mon, 2020-12-07 at 10:01 -0600, Rob Herring wrote: > On Tue, Dec 01, 2020 at 02:34:51PM -0800, mgr...@linux.intel.com wrote: > > From: Daniele Alessandrelli > > > > Add DT binding documentation for the Intel Keem Bay IPC driver, which > > enables communication between the Computing Sub-System (CSS) and the > > Multimedia Sub-System (MSS) of the Intel Movidius SoC code named Keem > > Bay. > > [cut] > > + > > +description: > > + The Keem Bay IPC driver enables Inter-Processor Communication (IPC) with > > the > > + Visual Processor Unit (VPU) embedded in the Intel Movidius SoC code named > > + Keem Bay. > > Sounds like a mailbox. We did consider using the mailbox framework, but eventually decided against it; mainly because of the following two reasons: 1. The channel concept in the Mailbox framework is different than the channel concept in Keem Bay IPC: a. My understanding is that Mailbox channels are meant to be SW representation of physical HW channels, while in Keem Bay IPC channels are software abstractions to achieve communication multiplexing over a single HW link b. Additionally, Keem Bay IPC has two different classes of channels (high-speed channels and general-purpose channels) that need to access the same HW link with different priorities. 2. The blocking / non-blocking TX behavior of mailbox channels is defined at channel creation time (by the tx_block value of the mailbox client passed to mbox_request_channel(); my understanding is that the tx_block value cannot be modified after the channel is created), while in Keem Bay IPC the same channel can be used for both blocking and non-blocking TX (behavior is controlled by the timeout argument passed to keembay_ipc_send()). Having said that, I guess that it could be possible to create a Mailbox driver implementing the core communication mechanism used by the Keem Bay IPC and then build our API around it (basically having two drivers). But I'm not sure that would make the code simpler or easier to maintain. Any thoughts on this? > > > What's the relationship between this and the xlink thing? > xLink internally uses Keem Bay IPC to communicate with the VPU. Basically, Keem Bay IPC is the lowest layer of the xLink stack.
Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
Hi Greg, Thanks for your feedback. On Wed, 2020-12-02 at 07:19 +0100, Greg KH wrote: > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote: > > From: Daniele Alessandrelli > > > > On the Intel Movidius SoC code named Keem Bay, communication between the > > Computing Sub-System (CSS), i.e., the CPU, and the Multimedia Sub-System > > (MSS), i.e., the VPU is enabled by the Keem Bay Inter-Processor > > Communication (IPC) mechanism. > > > > Add the driver for using Keem Bay IPC from within the Linux Kernel. > > > > Keem Bay IPC uses the following terminology: > > > > - Node:A processing entity that can use the IPC to communicate; > >currently, we just have two nodes, CPU (CSS) and VPU (MSS). > > > > - Link:Two nodes that can communicate over IPC form an IPC link > >(currently, we just have one link, the one between the CPU > >and VPU). > > > > - Channel: An IPC link can provide multiple IPC channels. IPC channels > >allow communication multiplexing, i.e., the same IPC link can > >be used by different applications for different > >communications. Each channel is identified by a channel ID, > >which must be unique within a single IPC link. Channels are > >divided in two categories, High-Speed (HS) channels and > >General-Purpose (GP) channels. HS channels have higher > >priority over GP channels. > > > > Keem Bay IPC mechanism is based on shared memory and hardware FIFOs. > > Both the CPU and the VPU have their own hardware FIFO. When the CPU > > wants to send an IPC message to the VPU, it writes to the VPU FIFO (MSS > > FIFO); similarly, when MSS wants to send an IPC message to the CPU, it > > writes to the CPU FIFO (CSS FIFO). > > > > A FIFO entry is simply a pointer to an IPC buffer (aka IPC header) > > stored in a portion of memory shared between the CPU and the VPU. > > Specifically, the FIFO entry contains the (VPU) physical address of the > > IPC buffer being transferred. > > > > In turn, the IPC buffer contains the (VPU) physical address of the > > payload (which must be located in shared memory too) as well as other > > information (payload size, IPC channel ID, etc.). > > > > Each IPC node instantiates a pool of IPC buffers from its own IPC buffer > > memory region. When instantiated, IPC buffers are marked as free. When > > the node needs to send an IPC message, it gets the first free buffer it > > finds (from its own pool), marks it as allocated (used), and puts its > > physical address into the IPC FIFO of the destination node. The > > destination node (which is notified by an interrupt when there are > > entries pending in its FIFO) extract the physical address from the FIFO > > and process the IPC buffer, marking it as free once done (so that the > > sender can reuse the buffer). > > Any reason you can't use the dmabuf interface for these memory buffers > you are creating and having to manage "by hand"? I thought that was > what the kernel was wanting to unify on such that individual > drivers/subsystems didn't have to do this on their own. My understanding is that the dmabuf interface is used to share DMA buffers across different drivers, while these buffers are used only internally to the IPC driver (and exchanged only with the VPU firmware). They basically are packet headers that are sent to the VPU. So, unless I'm missing something, dmabuf is probably not a good fit here. However, it could make sense to use dmabuf to share buffers across the drivers in the xLink stack. We'll look into that.
[PATCH] crypto: keembay-ocs-aes - Add dependency on HAS_IOMEM
From: Daniele Alessandrelli
Add dependency for CRYPTO_DEV_KEEMBAY_OCS_AES_SM4 on HAS_IOMEM to
prevent build failures.
Fixes: 88574332451380f4 ("crypto: keembay - Add support for Keem Bay OCS
AES/SM4")
Reported-by: kernel test robot
Signed-off-by: Daniele Alessandrelli
---
drivers/crypto/keembay/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/keembay/Kconfig b/drivers/crypto/keembay/Kconfig
index 3c16797b25b9..8eb5200d2f60 100644
--- a/drivers/crypto/keembay/Kconfig
+++ b/drivers/crypto/keembay/Kconfig
@@ -1,5 +1,6 @@
config CRYPTO_DEV_KEEMBAY_OCS_AES_SM4
tristate "Support for Intel Keem Bay OCS AES/SM4 HW acceleration"
+ depends on HAS_IOMEM
depends on OF || COMPILE_TEST
select CRYPTO_SKCIPHER
select CRYPTO_AEAD
base-commit: 90cc8cf2d1ab87d708ebc311ac104ccbbefad9fc
--
2.26.2
Re: [PATCH 0/1] Add IMR driver for Keem Bay
On Fri, 2020-05-01 at 09:09 +0200, gre...@linuxfoundation.org wrote: > On Thu, Apr 30, 2020 at 07:49:36PM +, Alessandrelli, Daniele > wrote: > > This e-mail and any attachments may contain confidential material > > for the sole > > use of the intended recipient(s). Any review or distribution by > > others is > > strictly prohibited. If you are not the intended recipient, please > > contact the > > sender and delete all copies. > > This footer means I delete all of your emails... My bad, I replied using the wrong email address (i.e., the one that adds the footer automatically). Sorry about that :/ I'll be more careful the next time. The original emails (the ones with the cover letter and the patch) were fine though (unless I did something else wrong). Any advice on how to have the patch reviewed and eventually merged?
Re: [PATCH 1/1] soc: keembay: Add Keem Bay IMR driver
Thanks for your feedback. > > First off, there is a "proper" way to send patches to the kernel > community that Intel has that I do not think you are > following. Please > work with the Intel "Linux group" to do that first, as odds are they > would have caught all of these issues beforehand (hint, which is why > that process is in place...) > I actually followed that process and got the OK to try to upstream. I think the issues you identified went uncaught mainly due to the limited Linux ARM expertise within that group (and Intel in general). Anyway, I'll keep working with our Linux Kernel people to try to reduce the burden on you and the other kernel maintainers. > > diff --git a/drivers/soc/keembay/Kconfig > > b/drivers/soc/keembay/Kconfig > > new file mode 100644 > > index ..2161bce131b3 > > --- /dev/null > > +++ b/drivers/soc/keembay/Kconfig > > @@ -0,0 +1,22 @@ > > +# SPDX-License-Identifier: GPL-2.0-only > > +# > > +# Keem Bay SoC drivers. > > +# > > + > > +menu "Keem Bay SoC drivers" > > + > > +config KEEMBAY_IMR > > + bool "Clean-up Keem Bay bootloader IMR at boot" > > + depends on ARM64 > > + help > > + This option makes the Kernel clean up the Isolated Memory > > Region > > + (IMR) set up by Keem Bay bootloader (U-boot) to protect > > itself during > > + early boot. > > + > > + The IMR number to be cleaned up is taken from the device tree > > + (property 'u-boot-imr' of the 'chosen' node). > > + > > + If you are compiling the Kernel for a Keem Bay SoC select Y, > > + otherwise select N. > > No module support? > > What about kernels that support more than one ARM device in the same > kernel, you just broke that :( > > > > +} > > +early_initcall(kmb_imr_init); > > Like I said above, you just broke multi-system kernels by always > trying > to do this. Trigger off of a hardware device that only your platform > has in order to properly load and run. As-is, you don't want to do > this. My bad, I didn't consider the issue of multi-platform ARM kernels. The problem is that I need this code to be run early at boot, so I don't think I can make this a module. But I'm sure there is a proper way to achieve what I need without breaking multi-system kernels. I'll do my homework and try to find it. > > Anyway, Intel owes me more liquor for this review as the resources > you > had to get review of this were obviously not taken advantage of. > > greg k-h
Re: [PATCH 1/1] soc: keembay: Add Keem Bay IMR driver
On Wed, 2020-05-27 at 16:33 +0200, Arnd Bergmann wrote: > On Wed, May 27, 2020 at 3:31 PM Alessandrelli, Daniele > wrote: > > > > Alternatively, take that memory off the "memory available" > > > > maps, > > > > and only re-add it once > > > > it is usable. > > > > > > > > Anything else is dangerous. > > > > That sounds like an interesting solution, thanks! > > > > Do you know any code that I can use as a reference? > > > > Since, the protected memory is just a few megabytes large, I guess > > that > > in theory we could just have U-Boot mark it as reserved memory and > > forget about it; but if there's a way to re-add it back once in > > Linux > > that would be great. > > Adding it back later on with a loadable device driver should > not be a problem, as this is not a violation of the boot protocol. Cool, I'll try to do that then, thanks! I see two ways to do that though: 1. Create a device driver that gets a reference to the memory region from its DT node and then re-adds the memory to the pool of available memory. 2. Use a special "compatible" string for my memory region and create a driver to handle it. However, I think that in the second case the driver must be builtin. Would that be okay? Also, from a quick look, it seems that I can re-add that memory back by calling memblock_free() (or a similar memblock_* function). Am I on the right track? > > > > Agreed, this sounds like an incompatible extension of the boot > > > protocol that we should otherwise not merge. > > > > > > However, there is also a lot of missing information here, and it > > > is > > > always possible they are trying to something for a good reason. > > > As long as the problem that the bootloader is trying to solve is > > > explained well enough in the changelog, we can discuss it to see > > > how it should be done properly. > > > > Apologies, I should have provided more information. Here it is :) > > > > Basically, at boot time U-Boot code and core memory (.text, .data, > > .bss, etc.) is protected by this Isolated Memory Region (IMR) which > > prevents any device or processing units other than the ARM CPU to > > access/modify the memory. > > > > This is done for security reasons, to reduce the risks that a > > potential > > attacker can use "hijacked" HW devices to interfere with the boot > > process (and break the secure boot flow in place). > > > > Before booting the Kernel, U-Boot sets up a new IMR to protect the > > Kernel image (so that the kernel can benefit of a similar > > protection) > > and then starts the kernel, delegating to the kernel the task of > > switching off the U-Boot IMR. > > > > U-Boot doesn't turn off its own IMR because doing so would leave a > > (tiny) window in which the boot execution flow is not protected. > > > > If you have any additional questions or feedback, just let me know. > > Thank you for the detailed explanation. I've never seen this done > in the Linux boot flow, but I can see how it helps prevent certain > kinds of attacks. > > It seems that just reserving the u-boot area and optionally > freeing it later from a driver solves most of your problem. > I have one related question though: if the kernel itself is > protected, does that mean that any driver that does a DMA > to statically allocated memory inside of the kernel is broken > as well? I think this is something that a couple of USB drivers > do, though it is fairly rare. Does u-boot protect both only > the executable sections of the kernel or also data, and does > the hardware block both read and write on the IMR, or just > writes? Yes, you're very right. Drivers that do DMA transfers to statically allocated memory inside the kernel will be broken. We are currently seeing this with our eMMC driver. Current solution is to add the eMMC controller to the list of allowed "agents" for the IMR. This will reduce the level of protection, but since we expect to have only a few of these exceptions (since, as you pointed out, drivers that do DMA to static kernel memory seem to be quite rare), we think that there is still value in having the Kernel IMR. Do you see any issue with this? Regards, Daniele
Re: [PATCH 0/7] Add initial Keem Bay SoC / Board support
On Tue, 2020-06-16 at 16:56 +0100, Daniele Alessandrelli wrote: > Hi, > > This patch-set adds initial support for a new Intel Movidius SoC > code-named > Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel > Movidius VPU. > > This initial patch-set enables only the minimal set of components > required to > make the Keem Bay EVM board boot into initramfs. > > Brief summary of the patch-set: > * Patches 1-2 add the Keem Bay SCMI Mailbox driver (needed to enable > SCMI in > Keem Bay) > * Patch 3 adds the ARCH_KEEMBAY config option > * Patches 4-7 add minimal device tree for Keem Bay SoC and Keem Bay > EVM > (together with information about the SoC maintainers) > > Regards, > Daniele > > > Daniele Alessandrelli (5): > arm64: Add config for Keem Bay SoC > dt-bindings: arm: Add Keem Bay bindings > MAINTAINERS: Add maintainers for Keem Bay SoC > arm64: dts: keembay: Add device tree for Keem Bay SoC > arm64: dts: keembay: Add device tree for Keem Bay EVM board > > Paul Murphy (2): > dt-bindings: mailbox: Add Keem Bay SCMI mailbox bindings > mailbox: keembay-scmi-mailbox: Add support for Keem Bay mailbox > > .../devicetree/bindings/arm/keembay.yaml | 19 ++ > .../mailbox/intel,keembay-scmi-mailbox.yaml | 44 > MAINTAINERS | 16 ++ > arch/arm64/Kconfig.platforms | 5 + > arch/arm64/boot/dts/intel/Makefile| 1 + > arch/arm64/boot/dts/intel/keembay-evm.dts | 55 + > arch/arm64/boot/dts/intel/keembay-soc.dtsi| 172 +++ > drivers/mailbox/Kconfig | 9 + > drivers/mailbox/Makefile | 2 + > drivers/mailbox/keembay-scmi-mailbox.c| 203 > ++ > include/dt-bindings/clock/keembay-clocks.h| 188 > include/dt-bindings/power/keembay-power.h | 19 ++ > 12 files changed, 733 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/arm/keembay.yaml > create mode 100644 > Documentation/devicetree/bindings/mailbox/intel,keembay-scmi- > mailbox.yaml > create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts > create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi > create mode 100644 drivers/mailbox/keembay-scmi-mailbox.c > create mode 100644 include/dt-bindings/clock/keembay-clocks.h > create mode 100644 include/dt-bindings/power/keembay-power.h > Ping
Re: [PATCH 0/7] Add initial Keem Bay SoC / Board support
On Sun, 2020-07-05 at 23:36 -0500, Jassi Brar wrote: > On Tue, Jun 16, 2020 at 10:56 AM Daniele Alessandrelli > wrote: > > Hi, > > > > This patch-set adds initial support for a new Intel Movidius SoC > > code-named > > Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel > > Movidius VPU. > > > > This initial patch-set enables only the minimal set of components > > required to > > make the Keem Bay EVM board boot into initramfs. > > > > Brief summary of the patch-set: > > * Patches 1-2 add the Keem Bay SCMI Mailbox driver (needed to > > enable SCMI in > > Keem Bay) > > * Patch 3 adds the ARCH_KEEMBAY config option > > * Patches 4-7 add minimal device tree for Keem Bay SoC and Keem Bay > > EVM > > (together with information about the SoC maintainers) > > > Please break this into two patchsets - first enabling platform > support > and second adding mailbox support. Thanks for your feedback Jassi. I will split the patcheset into two different patchsets. Just one question: should I remove the mailbox and scmi nodes from the soc DT or can I keep them there even if the mailbox driver is not available yet? > > thanks.
Re: [PATCH v2 2/5] dt-bindings: arm: Add Keem Bay bindings
On Mon, 2020-07-13 at 21:12 -0600, Rob Herring wrote: > On Wed, Jul 08, 2020 at 06:50:17PM +0100, Daniele Alessandrelli > wrote: > > From: Daniele Alessandrelli > > > > Document Intel Movidius SoC code-named Keem Bay, along with the > > Keem Bay > > EVM board. > > > > Reviewed-by: Dinh Nguyen > > Signed-off-by: Daniele Alessandrelli < > > daniele.alessandre...@intel.com> > > --- > > .../devicetree/bindings/arm/keembay.yaml | 19 ++ > > include/dt-bindings/clock/keembay-clocks.h| 188 > > ++ > > include/dt-bindings/power/keembay-power.h | 19 ++ > > These belong with the clock and power bindings. Thanks for the feedback. I'll split this patch in three (SoC/Board bindings, clock bindings, and power bindings) and re-submit. > > > 3 files changed, 226 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/arm/keembay.yaml > > create mode 100644 include/dt-bindings/clock/keembay-clocks.h > > create mode 100644 include/dt-bindings/power/keembay-power.h > > > > diff --git a/Documentation/devicetree/bindings/arm/keembay.yaml > > b/Documentation/devicetree/bindings/arm/keembay.yaml > > new file mode 100644 > > index ..f81b110046ca > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/keembay.yaml > > @@ -0,0 +1,19 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/keembay.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Keem Bay platform device tree bindings > > + > > +maintainers: > > + - Paul J. Murphy > > + - Daniele Alessandrelli > > + > > +properties: > > + compatible: > > +items: > > + - enum: > > +- intel,keembay-evm > > + - const: intel,keembay > > +... > > diff --git a/include/dt-bindings/clock/keembay-clocks.h > > b/include/dt-bindings/clock/keembay-clocks.h > > new file mode 100644 > > index ..a68e986dd565 > > --- /dev/null > > +++ b/include/dt-bindings/clock/keembay-clocks.h > > @@ -0,0 +1,188 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * Copyright (c) 2020 Intel Corporation. > > + * > > + * Device tree defines for clocks in Keem Bay. > > + */ > > + > > +#ifndef __DT_BINDINGS_KEEMBAY_CLOCKS_H > > +#define __DT_BINDINGS_KEEMBAY_CLOCKS_H > > + > > +/* CPR_PLL region. CLK_ID: 0 - 11 */ > > +#define KEEM_BAY_A53_PLL_START_ID (0) > > +#define KEEM_BAY_A53_PLL_0_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 0) > > +#define KEEM_BAY_A53_PLL_0_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 1) > > +#define KEEM_BAY_A53_PLL_0_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 2) > > +#define KEEM_BAY_A53_PLL_0_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 3) > > +#define KEEM_BAY_A53_PLL_1_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 4) > > +#define KEEM_BAY_A53_PLL_1_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 5) > > +#define KEEM_BAY_A53_PLL_1_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 6) > > +#define KEEM_BAY_A53_PLL_1_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 7) > > +#define KEEM_BAY_A53_PLL_2_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 8) > > +#define KEEM_BAY_A53_PLL_2_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 9) > > +#define KEEM_BAY_A53_PLL_2_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 10) > > +#define KEEM_BAY_A53_PLL_2_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 11) > > +#define KEEM_BAY_A53_PLL_MAX_ID (KEEM_BAY_A53_PLL_2_OUT_3) > > + > > +/* A53_CPR region. CLK_ID: 12 - 30 */ > > +#define KEEM_BAY_A53_START_ID (KEEM_BAY_A53_PLL_MAX_ID + 1) > > +#define KEEM_BAY_A53_AON (KEEM_BAY_A53_START_ID + 0) > > +#define KEEM_BAY_A53_NOC (KEEM_BAY_A53_START_ID + 1) > > +#define KEEM_BAY_A53_FUSE (KEEM_BAY_A53_START_ID + 2) > > +#define KEEM_BAY_A53_ROM (KEEM_BAY_A53_START_ID + 3) > > +#define KEEM_BAY_A53_ICB (KEEM_BAY_A53_START_ID + 4) > > +#define KEEM_BAY_A53_GIC (KEEM_BAY_A53_START_ID + 5) > > +#define KEEM_BAY_A53_TIM (KEEM_BAY_A53_START_ID + 6) > > +#define KEEM_BAY_A53_GPIO (KEEM_BAY_A53_START_ID + 7) > > +#define KEEM_BAY_A53_JTAG (KEEM_BAY_A53_START_ID + 8) > > +#define KEEM_BAY_A53_MBIST_0 (KEEM_BAY_A53_START_ID + 9) > > +#define KEEM_BAY_A53_DSS (KEEM_BAY_A53_START_ID + 10) > > +#define KEEM_BAY_A53_MSS (KEEM_BAY_A53_START_ID + 11) > > +#define KEEM_BAY_A53_PSS (KEEM_BAY_A53_START_ID + 12) > > +#define KEEM_BAY_A53_PCIE (KEEM_BAY_A53_START_ID + 13) > > +#define KEEM_BAY_A53_VENC (KEEM_BAY_A53_START_ID + 14) > > +#define KEEM_BAY_A53_VDEC (KEEM_BAY_A53_START_I
Re: [PATCH v2 0/5] Add initial Keem Bay SoC / Board support
On Tue, 2020-07-14 at 14:40 +0200, Arnd Bergmann wrote: > On Wed, Jul 8, 2020 at 7:50 PM Daniele Alessandrelli > wrote: > > Hi, > > > > This patch-set adds initial support for a new Intel Movidius SoC > > code-named > > Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel > > Movidius VPU. > > > > This initial patch-set enables only the minimal set of components > > required > > to make the Keem Bay EVM board boot into initramfs. > > > > Changes from v1 to v2: > > * Moved keembay-scmi-mailbox driver to a separate patchset > > * Removed Keem Bay SCMI mailbox and SCMI node from Keem Bay SoC > > device tree > > This all looks basically ok, but I noticed that the DT bindings ands > DTS files all have a > "GPL-2.0-only" tag. Usually we make those dual-licensed in order to > make it easier > to distribute them with a non-GPL bootloader and synchronize them > between > projects. > > Do you know if the GPL-2.0-only part was picked intentionally, or if > it can > be changed to dual-licensed? Thanks for reviewing the patchset. I'll change those files to dual- licensed and re-submit.
[PATCH v3 0/7] Add initial Keem Bay SoC / Board support
Hi, This patch-set adds initial support for a new Intel Movidius SoC code-named Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This initial patch-set enables only the minimal set of components required to make the Keem Bay EVM board boot into initramfs. Changes from v2 to v3: * Split dt-bindings patch into 3 different patches (SoC/board bindings, clock bindings, and power domains bindings). * Added dual license (GPL-2.0-only or BSD-3-Clause) to dt-bindings header files and DTS files. Changes from v1 to v2: * Moved keembay-scmi-mailbox driver to a separate patchset * Removed Keem Bay SCMI mailbox and SCMI node from Keem Bay SoC device tree Regards, Daniele Daniele Alessandrelli (7): arm64: Add config for Keem Bay SoC dt-bindings: arm: Add Keem Bay bindings dt-bindings: clock: Add Keem Bay clock IDs dt-bindings: power: Add Keem Bay power domains MAINTAINERS: Add maintainers for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay EVM board .../devicetree/bindings/arm/keembay.yaml | 19 ++ MAINTAINERS | 10 + arch/arm64/Kconfig.platforms | 5 + arch/arm64/boot/dts/intel/Makefile| 1 + arch/arm64/boot/dts/intel/keembay-evm.dts | 39 arch/arm64/boot/dts/intel/keembay-soc.dtsi| 125 include/dt-bindings/clock/keembay-clocks.h| 188 ++ include/dt-bindings/power/keembay-power.h | 19 ++ 8 files changed, 406 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi create mode 100644 include/dt-bindings/clock/keembay-clocks.h create mode 100644 include/dt-bindings/power/keembay-power.h -- 2.26.2
[PATCH v3 4/7] dt-bindings: power: Add Keem Bay power domains
From: Daniele Alessandrelli Add power domain dt-bindings for Keem Bay SoC. Signed-off-by: Daniele Alessandrelli --- include/dt-bindings/power/keembay-power.h | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 include/dt-bindings/power/keembay-power.h diff --git a/include/dt-bindings/power/keembay-power.h b/include/dt-bindings/power/keembay-power.h new file mode 100644 index ..1385c42f897d --- /dev/null +++ b/include/dt-bindings/power/keembay-power.h @@ -0,0 +1,19 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */ +/* + * Copyright (c) 2020 Intel Corporation. + * + * Device tree defines for power domains in Keem Bay. + */ + +#ifndef __DT_BINDINGS_KEEMBAY_POWER_H +#define __DT_BINDINGS_KEEMBAY_POWER_H + +#define KEEM_BAY_PSS_POWER_DOMAIN 0 +#define KEEM_BAY_MSS_CPU_POWER_DOMAIN 1 +#define KEEM_BAY_VDEC_POWER_DOMAIN 2 +#define KEEM_BAY_VENC_POWER_DOMAIN 3 +#define KEEM_BAY_PCIE_POWER_DOMAIN 4 +#define KEEM_BAY_USS_POWER_DOMAIN 5 +#define KEEM_BAY_MSS_CAM_POWER_DOMAIN 6 + +#endif /* __DT_BINDINGS_KEEMBAY_POWER_H */ -- 2.26.2
[PATCH v3 6/7] arm64: dts: keembay: Add device tree for Keem Bay SoC
From: Daniele Alessandrelli
Add initial device tree for Intel Movidius SoC code-named Keem Bay.
This initial DT includes nodes for Cortex-A53 cores, UARTs, GIC, PSCI,
and PMU.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS| 1 +
arch/arm64/boot/dts/intel/keembay-soc.dtsi | 125 +
2 files changed, 126 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index b151d0fc0588..e5019c8487c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
F: include/dt-bindings/clock/keembay-clocks.h
F: include/dt-bindings/power/keembay-power.h
diff --git a/arch/arm64/boot/dts/intel/keembay-soc.dtsi
b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
new file mode 100644
index ..57c67621ed63
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * Copyright (C) 2020, Intel Corporation.
+ *
+ * Device tree describing Keem Bay SoC.
+ */
+
+#include
+#include
+#include
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ gic: interrupt-controller@2050 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0 0x2050 0x0 0x2>, /* GICD */
+ <0x0 0x2058 0x0 0x8>; /* GICR */
+ /* VGIC maintenance interrupt */
+ interrupts = ;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ /* Secure, non-secure, virtual, and hypervisor */
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart0: serial@2015 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2015 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart1: serial@2016 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2016 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart2: serial@2017 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2017 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4&g
[PATCH v3 5/7] MAINTAINERS: Add maintainers for Keem Bay SoC
From: Daniele Alessandrelli Add maintainers for the new Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b4a43a9e7fbc..b151d0fc0588 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1954,6 +1954,14 @@ F: drivers/irqchip/irq-ixp4xx.c F: include/linux/irqchip/irq-ixp4xx.h F: include/linux/platform_data/timer-ixp4xx.h +ARM/INTEL KEEMBAY ARCHITECTURE +M: Paul J. Murphy +M: Daniele Alessandrelli +S: Maintained +F: Documentation/devicetree/bindings/arm/keembay.yaml +F: include/dt-bindings/clock/keembay-clocks.h +F: include/dt-bindings/power/keembay-power.h + ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT M: Jonathan Cameron L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.26.2
[PATCH v3 7/7] arm64: dts: keembay: Add device tree for Keem Bay EVM board
From: Daniele Alessandrelli
Add initial device tree for Keem Bay EVM board. With this minimal device
tree the board boots fine using an initramfs image.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/intel/Makefile| 1 +
arch/arm64/boot/dts/intel/keembay-evm.dts | 39 +++
3 files changed, 41 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index e5019c8487c8..bcda93691026 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
F: include/dt-bindings/clock/keembay-clocks.h
F: include/dt-bindings/power/keembay-power.h
diff --git a/arch/arm64/boot/dts/intel/Makefile
b/arch/arm64/boot/dts/intel/Makefile
index 40cb16e8c814..296eceec4276 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
dtb-$(CONFIG_ARCH_AGILEX) += socfpga_agilex_socdk.dtb \
socfpga_agilex_socdk_nand.dtb
+dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/keembay-evm.dts
b/arch/arm64/boot/dts/intel/keembay-evm.dts
new file mode 100644
index ..347debb9c269
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-evm.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * Copyright (C) 2020, Intel Corporation
+ *
+ * Device tree describing Keem Bay EVM board.
+ */
+
+/dts-v1/;
+
+#include "keembay-soc.dtsi"
+#include
+#include
+
+/ {
+ model = "Keem Bay EVM";
+ compatible = "intel,keembay-evm", "intel,keembay";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 2GB of DDR memory. */
+ reg = <0x0 0x8000 0x0 0x8000>;
+ };
+
+};
+
+&uart3 {
+ status = "okay";
+};
--
2.26.2
[PATCH v3 1/7] arm64: Add config for Keem Bay SoC
From: Daniele Alessandrelli Add ARCH_KEEMBAY configuration option to support Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- arch/arm64/Kconfig.platforms | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 8dd05b2a925c..95c1b9042009 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -121,6 +121,11 @@ config ARCH_HISI help This enables support for Hisilicon ARMv8 SoC family +config ARCH_KEEMBAY + bool "Keem Bay SoC" + help + This enables support for Intel Movidius SoC code-named Keem Bay. + config ARCH_MEDIATEK bool "MediaTek SoC Family" select ARM_GIC -- 2.26.2
[PATCH v3 2/7] dt-bindings: arm: Add Keem Bay bindings
From: Daniele Alessandrelli Document Intel Movidius SoC code-named Keem Bay, along with the Keem Bay EVM board. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- .../devicetree/bindings/arm/keembay.yaml | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml diff --git a/Documentation/devicetree/bindings/arm/keembay.yaml b/Documentation/devicetree/bindings/arm/keembay.yaml new file mode 100644 index ..f81b110046ca --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keembay.yaml @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Keem Bay platform device tree bindings + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +properties: + compatible: +items: + - enum: +- intel,keembay-evm + - const: intel,keembay +... -- 2.26.2
[PATCH v3 3/7] dt-bindings: clock: Add Keem Bay clock IDs
From: Daniele Alessandrelli Add clock dt-bindings for Keem Bay SoC. Signed-off-by: Daniele Alessandrelli --- include/dt-bindings/clock/keembay-clocks.h | 188 + 1 file changed, 188 insertions(+) create mode 100644 include/dt-bindings/clock/keembay-clocks.h diff --git a/include/dt-bindings/clock/keembay-clocks.h b/include/dt-bindings/clock/keembay-clocks.h new file mode 100644 index ..4ad6616ee8e0 --- /dev/null +++ b/include/dt-bindings/clock/keembay-clocks.h @@ -0,0 +1,188 @@ +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */ +/* + * Copyright (c) 2020 Intel Corporation. + * + * Device tree defines for clocks in Keem Bay. + */ + +#ifndef __DT_BINDINGS_KEEMBAY_CLOCKS_H +#define __DT_BINDINGS_KEEMBAY_CLOCKS_H + +/* CPR_PLL region. CLK_ID: 0 - 11 */ +#define KEEM_BAY_A53_PLL_START_ID (0) +#define KEEM_BAY_A53_PLL_0_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 0) +#define KEEM_BAY_A53_PLL_0_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 1) +#define KEEM_BAY_A53_PLL_0_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 2) +#define KEEM_BAY_A53_PLL_0_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 3) +#define KEEM_BAY_A53_PLL_1_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 4) +#define KEEM_BAY_A53_PLL_1_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 5) +#define KEEM_BAY_A53_PLL_1_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 6) +#define KEEM_BAY_A53_PLL_1_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 7) +#define KEEM_BAY_A53_PLL_2_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 8) +#define KEEM_BAY_A53_PLL_2_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 9) +#define KEEM_BAY_A53_PLL_2_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 10) +#define KEEM_BAY_A53_PLL_2_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 11) +#define KEEM_BAY_A53_PLL_MAX_ID (KEEM_BAY_A53_PLL_2_OUT_3) + +/* A53_CPR region. CLK_ID: 12 - 30 */ +#define KEEM_BAY_A53_START_ID (KEEM_BAY_A53_PLL_MAX_ID + 1) +#define KEEM_BAY_A53_AON (KEEM_BAY_A53_START_ID + 0) +#define KEEM_BAY_A53_NOC (KEEM_BAY_A53_START_ID + 1) +#define KEEM_BAY_A53_FUSE (KEEM_BAY_A53_START_ID + 2) +#define KEEM_BAY_A53_ROM (KEEM_BAY_A53_START_ID + 3) +#define KEEM_BAY_A53_ICB (KEEM_BAY_A53_START_ID + 4) +#define KEEM_BAY_A53_GIC (KEEM_BAY_A53_START_ID + 5) +#define KEEM_BAY_A53_TIM (KEEM_BAY_A53_START_ID + 6) +#define KEEM_BAY_A53_GPIO (KEEM_BAY_A53_START_ID + 7) +#define KEEM_BAY_A53_JTAG (KEEM_BAY_A53_START_ID + 8) +#define KEEM_BAY_A53_MBIST_0 (KEEM_BAY_A53_START_ID + 9) +#define KEEM_BAY_A53_DSS (KEEM_BAY_A53_START_ID + 10) +#define KEEM_BAY_A53_MSS (KEEM_BAY_A53_START_ID + 11) +#define KEEM_BAY_A53_PSS (KEEM_BAY_A53_START_ID + 12) +#define KEEM_BAY_A53_PCIE (KEEM_BAY_A53_START_ID + 13) +#define KEEM_BAY_A53_VENC (KEEM_BAY_A53_START_ID + 14) +#define KEEM_BAY_A53_VDEC (KEEM_BAY_A53_START_ID + 15) +#define KEEM_BAY_A53_MBIST_1 (KEEM_BAY_A53_START_ID + 16) +#define KEEM_BAY_A53_MBIST_2 (KEEM_BAY_A53_START_ID + 17) +#define KEEM_BAY_A53_MBIST_3 (KEEM_BAY_A53_START_ID + 18) +#define KEEM_BAY_A53_MAX_ID (KEEM_BAY_A53_MBIST_3) + +/* A53_CPR_AUX region. CLK_ID: 31 - 57 */ +#define KEEM_BAY_A53_AUX_START_ID (KEEM_BAY_A53_MAX_ID + 1) +#define KEEM_BAY_A53_AUX_32KHZ (KEEM_BAY_A53_AUX_START_ID + 0) +#define KEEM_BAY_A53_AUX_CPR (KEEM_BAY_A53_AUX_START_ID + 1) +#define KEEM_BAY_A53_AUX_TSENS (KEEM_BAY_A53_AUX_START_ID + 2) +#define KEEM_BAY_A53_AUX_GPIO0 (KEEM_BAY_A53_AUX_START_ID + 3) +#define KEEM_BAY_A53_AUX_GPIO1 (KEEM_BAY_A53_AUX_START_ID + 4) +#define KEEM_BAY_A53_AUX_GPIO2 (KEEM_BAY_A53_AUX_START_ID + 5) +#define KEEM_BAY_A53_AUX_GPIO3 (KEEM_BAY_A53_AUX_START_ID + 6) +#define KEEM_BAY_A53_AUX_DDR_REF (KEEM_BAY_A53_AUX_START_ID + 7) +#define KEEM_BAY_A53_AUX_DDR_REF_BYPASS (KEEM_BAY_A53_AUX_START_ID + 8) +#define KEEM_BAY_A53_AUX_RESERVED1 (KEEM_BAY_A53_AUX_START_ID + 9) +#define KEEM_BAY_A53_AUX_VENC (KEEM_BAY_A53_AUX_START_ID + 10) +#define KEEM_BAY_A53_AUX_VDEC (KEEM_BAY_A53_AUX_START_ID + 11) +#define KEEM_BAY_A53_AUX_USOC_USB_CTRL (KEEM_BAY_A53_AUX_START_ID + 12) +#define KEEM_BAY_A53_AUX_USB (KEEM_BAY_A53_AUX_START_ID + 13) +#define KEEM_BAY_A53_AUX_USB_REF (KEEM_BAY_A53_AUX_START_ID + 14) +#define KEEM_BAY_A53_AUX_USB_ALT_REF (KEEM_BAY_A53_AUX_START_ID + 15) +#define KEEM_BAY_A53_AUX_USB_SUSPEND (KEEM_BAY_A53_AUX_START_ID + 16) +#define KEEM_BAY_A53_AUX_RESERVED2 (KEEM_BAY_A53_AUX_START_ID + 17) +#define KEEM_BAY_A53_AUX_PCIE (KEEM_BAY_A53_AUX_START_ID + 18) +#define KEEM_BAY_A53_AUX_DBG_CLK (KEEM_BAY_A53_AUX_START_ID + 19) +#define KEEM_BAY_A53_AUX_DBG_TRACE (KEEM_BAY_A53_AUX_START_ID + 20) +#define KEEM_BAY_A53_AUX_DBG_DAP (KEEM_BAY_A53_AUX_START_ID + 21) +#define KEEM_BAY_A53_AUX_ARM_CLKIN (KEEM_BAY_A53_AUX_START_ID + 22) +#define KEEM_BAY_A53_AUX_ARM_AXI (KEEM_BAY_A53_AUX_START_ID + 23) +#define KEEM_BAY_A53_AUX_USOC (KEEM_BAY_A53_AUX_START_ID + 24) +#define KEEM_BAY_A53_AUX_USOC_REF (KEEM_BAY_A53_AUX_START_ID + 25) +#define KEEM_BAY_A53_AUX_USOC_ALT_REF (KEEM_BAY_A53_AUX_START_ID + 26) +#define KEEM_BAY_A53_AUX_MAX_ID (KEEM_BAY_A53_AUX_USOC_ALT_REF) + +/* PSS_CPR region CLK_ID: CLK_ID: 58 - 82 */ +#define KEEM_BAY_PSS_START_ID (KEEM_BAY_A53_AUX_MAX_ID + 1
Re: [PATCH 1/1] soc: keembay: Add Keem Bay IMR driver
On Wed, 2020-05-27 at 20:59 +0200, Arnd Bergmann wrote: > On Wed, May 27, 2020 at 7:43 PM Daniele Alessandrelli > wrote: > > On Wed, 2020-05-27 at 16:33 +0200, Arnd Bergmann wrote: > > > On Wed, May 27, 2020 at 3:31 PM Alessandrelli, Daniele < > > > daniele.alessandre...@intel.com> wrote: > > > > > > Adding it back later on with a loadable device driver should > > > not be a problem, as this is not a violation of the boot > > > protocol. > > > > Cool, I'll try to do that then, thanks! > > > > I see two ways to do that though: > > > > 1. Create a device driver that gets a reference to the memory > > region > > from its DT node and then re-adds the memory to the pool of > > available > > memory. > > > > 2. Use a special "compatible" string for my memory region and > > create a > > driver to handle it. > > I think the first approach is more common. > > > However, I think that in the second case the driver must be > > builtin. > > Would that be okay? > > It's better to avoid that. > > > Also, from a quick look, it seems that I can re-add that memory > > back by > > calling memblock_free() (or a similar memblock_* function). Am I on > > the > > right track? > > I'm not sure if memblock_free() works after early memory > initialization > is complete, but I think there is some way to do it later. Maybe try > memblock_free() first, and then look for something else if it doesn't > work. > Brilliant. I will create a new patch using the 1st approach and see if memblock_free() works; if not, I will look for something else. Thanks a lot for your valuable feedback and advice. > > > It seems that just reserving the u-boot area and optionally > > > freeing it later from a driver solves most of your problem. > > > I have one related question though: if the kernel itself is > > > protected, does that mean that any driver that does a DMA > > > to statically allocated memory inside of the kernel is broken > > > as well? I think this is something that a couple of USB drivers > > > do, though it is fairly rare. Does u-boot protect both only > > > the executable sections of the kernel or also data, and does > > > the hardware block both read and write on the IMR, or just > > > writes? > > > > Yes, you're very right. Drivers that do DMA transfers to statically > > allocated memory inside the kernel will be broken. > > > > We are currently seeing this with our eMMC driver. > > > > Current solution is to add the eMMC controller to the list of > > allowed > > "agents" for the IMR. This will reduce the level of protection, but > > since we expect to have only a few of these exceptions (since, as > > you > > pointed out, drivers that do DMA to static kernel memory seem to be > > quite rare), we think that there is still value in having the > > Kernel > > IMR. > > > > Do you see any issue with this? > > I think you should try to fix the driver rather than making an > exception for it. Yes, we'll look into that. > Hot-pluggable drivers are a much more interesting > case I think, because on the one hand you have no idea what > users might want to plug in legitimately, but on the other hand > those are also the most likely attack vectors (driver bugs for > random USB drivers overwriting kernel memory when faced with > malicious hardware) that this feature is trying to prevent. > > I also wonder whether we should do something in the normal > iommu code that prevents one from mapping a page that the > kernel would consider as protected (kernel .text, freed memory, > ...) into the iommu in the first place. Sounds like an iteresting security feature; expecially because it would apply to any hardware. > > Arnd
Re: [PATCH 1/1] soc: keembay: Add Keem Bay IMR driver
On Thu, 2020-05-28 at 13:22 +0200, Pavel Machek wrote: > Hi! > > > > Agreed, this sounds like an incompatible extension of the boot > > > protocol > > > that we should otherwise not merge. > > > > > > However, there is also a lot of missing information here, and it > > > is > > > always > > > possible they are trying to something for a good reason. As long > > > as > > > the > > > problem that the bootloader is trying to solve is explained well > > > enough > > > in the changelog, we can discuss it to see how it should be done > > > properly. > > > > Apologies, I should have provided more information. Here it is :) > > > > Basically, at boot time U-Boot code and core memory (.text, .data, > > .bss, etc.) is protected by this Isolated Memory Region (IMR) which > > prevents any device or processing units other than the ARM CPU to > > access/modify the memory. > > > > This is done for security reasons, to reduce the risks that a > > potential > > attacker can use "hijacked" HW devices to interfere with the boot > > process (and break the secure boot flow in place). > > Dunno. You disable that after boot anyway. Whether it is disabled > just before starting kernel or just after it makes very little > difference. Not sure I get your point. Disabling it while U-Boot is still running poses a security risk (even if arguably tiny), while doing it once the the Kernel is running is totally safe. So, I'd prefer to do it in the Kernel, unless practical reasons prevent it. > > Plus, I'm not sure if this has much security value at all. If I can > corrupt data u-boot works _with_ (such as kernel, dtb), I'll take > over the system anyway. True, U-Boot data needs to be protected too and, in fact, we're trying to do that as well. Other IMRs are used to protect the kernel, dtb, and other critical memory sections. > > IOW I believe the best/simplest way is to simply disable this in > u-boot before jumping to kernel entrypoint. Yes, that's definitely the simplest solution, but, IMO, not the safest one. So, I'd prefer to build on your initial suggestion and Arnd's advice and create a new device driver to disable the IMR once Linux is running. But, yes, if that eventually proves unfeasible, I might just have the bootloader disable the protection right before booting the OS. > > Best regards, > > Pavel >
[PATCH v2 1/5] arm64: Add config for Keem Bay SoC
From: Daniele Alessandrelli Add ARCH_KEEMBAY configuration option to support Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- arch/arm64/Kconfig.platforms | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 8dd05b2a925c..95c1b9042009 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -121,6 +121,11 @@ config ARCH_HISI help This enables support for Hisilicon ARMv8 SoC family +config ARCH_KEEMBAY + bool "Keem Bay SoC" + help + This enables support for Intel Movidius SoC code-named Keem Bay. + config ARCH_MEDIATEK bool "MediaTek SoC Family" select ARM_GIC -- 2.26.2
[PATCH v2 4/5] arm64: dts: keembay: Add device tree for Keem Bay SoC
From: Daniele Alessandrelli
Add initial device tree for Intel Movidius SoC code-named Keem Bay.
This initial DT includes nodes for Cortex-A53 cores, UARTs, GIC, PSCI,
and PMU.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS| 1 +
arch/arm64/boot/dts/intel/keembay-soc.dtsi | 125 +
2 files changed, 126 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index ceb833fa04dd..53d2f8d0976a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
F: include/dt-bindings/clock/keembay-clocks.h
F: include/dt-bindings/power/keembay-power.h
diff --git a/arch/arm64/boot/dts/intel/keembay-soc.dtsi
b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
new file mode 100644
index ..4aaf543f3ad1
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
@@ -0,0 +1,125 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020, Intel Corporation.
+ *
+ * Device tree describing Keem Bay SoC.
+ */
+
+#include
+#include
+#include
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ gic: interrupt-controller@2050 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0 0x2050 0x0 0x2>, /* GICD */
+ <0x0 0x2058 0x0 0x8>; /* GICR */
+ /* VGIC maintenance interrupt */
+ interrupts = ;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ /* Secure, non-secure, virtual, and hypervisor */
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart0: serial@2015 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2015 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart1: serial@2016 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2016 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart2: serial@2017 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2017 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+
[PATCH v2 0/5] Add initial Keem Bay SoC / Board support
Hi, This patch-set adds initial support for a new Intel Movidius SoC code-named Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This initial patch-set enables only the minimal set of components required to make the Keem Bay EVM board boot into initramfs. Changes from v1 to v2: * Moved keembay-scmi-mailbox driver to a separate patchset * Removed Keem Bay SCMI mailbox and SCMI node from Keem Bay SoC device tree Regards, Daniele Daniele Alessandrelli (5): arm64: Add config for Keem Bay SoC dt-bindings: arm: Add Keem Bay bindings MAINTAINERS: Add maintainers for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay EVM board .../devicetree/bindings/arm/keembay.yaml | 19 ++ MAINTAINERS | 10 + arch/arm64/Kconfig.platforms | 5 + arch/arm64/boot/dts/intel/Makefile| 1 + arch/arm64/boot/dts/intel/keembay-evm.dts | 39 arch/arm64/boot/dts/intel/keembay-soc.dtsi| 125 include/dt-bindings/clock/keembay-clocks.h| 188 ++ include/dt-bindings/power/keembay-power.h | 19 ++ 8 files changed, 406 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi create mode 100644 include/dt-bindings/clock/keembay-clocks.h create mode 100644 include/dt-bindings/power/keembay-power.h -- 2.26.2
[PATCH v2 3/5] MAINTAINERS: Add maintainers for Keem Bay SoC
From: Daniele Alessandrelli Add maintainers for the new Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1d4aa7f942de..ceb833fa04dd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1954,6 +1954,14 @@ F: drivers/irqchip/irq-ixp4xx.c F: include/linux/irqchip/irq-ixp4xx.h F: include/linux/platform_data/timer-ixp4xx.h +ARM/INTEL KEEMBAY ARCHITECTURE +M: Paul J. Murphy +M: Daniele Alessandrelli +S: Maintained +F: Documentation/devicetree/bindings/arm/keembay.yaml +F: include/dt-bindings/clock/keembay-clocks.h +F: include/dt-bindings/power/keembay-power.h + ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT M: Jonathan Cameron L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.26.2
[PATCH v2 5/5] arm64: dts: keembay: Add device tree for Keem Bay EVM board
From: Daniele Alessandrelli
Add initial device tree for Keem Bay EVM board. With this minimal device
tree the board boots fine using an initramfs image.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/intel/Makefile| 1 +
arch/arm64/boot/dts/intel/keembay-evm.dts | 39 +++
3 files changed, 41 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 53d2f8d0976a..d7dcb3a86201 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
F: include/dt-bindings/clock/keembay-clocks.h
F: include/dt-bindings/power/keembay-power.h
diff --git a/arch/arm64/boot/dts/intel/Makefile
b/arch/arm64/boot/dts/intel/Makefile
index 40cb16e8c814..296eceec4276 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
dtb-$(CONFIG_ARCH_AGILEX) += socfpga_agilex_socdk.dtb \
socfpga_agilex_socdk_nand.dtb
+dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/keembay-evm.dts
b/arch/arm64/boot/dts/intel/keembay-evm.dts
new file mode 100644
index ..92a7500efc61
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-evm.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020, Intel Corporation
+ *
+ * Device tree describing Keem Bay EVM board.
+ */
+
+/dts-v1/;
+
+#include "keembay-soc.dtsi"
+#include
+#include
+
+/ {
+ model = "Keem Bay EVM";
+ compatible = "intel,keembay-evm", "intel,keembay";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 2GB of DDR memory. */
+ reg = <0x0 0x8000 0x0 0x8000>;
+ };
+
+};
+
+&uart3 {
+ status = "okay";
+};
--
2.26.2
[PATCH v2 2/5] dt-bindings: arm: Add Keem Bay bindings
From: Daniele Alessandrelli Document Intel Movidius SoC code-named Keem Bay, along with the Keem Bay EVM board. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- .../devicetree/bindings/arm/keembay.yaml | 19 ++ include/dt-bindings/clock/keembay-clocks.h| 188 ++ include/dt-bindings/power/keembay-power.h | 19 ++ 3 files changed, 226 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml create mode 100644 include/dt-bindings/clock/keembay-clocks.h create mode 100644 include/dt-bindings/power/keembay-power.h diff --git a/Documentation/devicetree/bindings/arm/keembay.yaml b/Documentation/devicetree/bindings/arm/keembay.yaml new file mode 100644 index ..f81b110046ca --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keembay.yaml @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Keem Bay platform device tree bindings + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +properties: + compatible: +items: + - enum: +- intel,keembay-evm + - const: intel,keembay +... diff --git a/include/dt-bindings/clock/keembay-clocks.h b/include/dt-bindings/clock/keembay-clocks.h new file mode 100644 index ..a68e986dd565 --- /dev/null +++ b/include/dt-bindings/clock/keembay-clocks.h @@ -0,0 +1,188 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 Intel Corporation. + * + * Device tree defines for clocks in Keem Bay. + */ + +#ifndef __DT_BINDINGS_KEEMBAY_CLOCKS_H +#define __DT_BINDINGS_KEEMBAY_CLOCKS_H + +/* CPR_PLL region. CLK_ID: 0 - 11 */ +#define KEEM_BAY_A53_PLL_START_ID (0) +#define KEEM_BAY_A53_PLL_0_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 0) +#define KEEM_BAY_A53_PLL_0_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 1) +#define KEEM_BAY_A53_PLL_0_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 2) +#define KEEM_BAY_A53_PLL_0_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 3) +#define KEEM_BAY_A53_PLL_1_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 4) +#define KEEM_BAY_A53_PLL_1_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 5) +#define KEEM_BAY_A53_PLL_1_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 6) +#define KEEM_BAY_A53_PLL_1_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 7) +#define KEEM_BAY_A53_PLL_2_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 8) +#define KEEM_BAY_A53_PLL_2_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 9) +#define KEEM_BAY_A53_PLL_2_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 10) +#define KEEM_BAY_A53_PLL_2_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 11) +#define KEEM_BAY_A53_PLL_MAX_ID (KEEM_BAY_A53_PLL_2_OUT_3) + +/* A53_CPR region. CLK_ID: 12 - 30 */ +#define KEEM_BAY_A53_START_ID (KEEM_BAY_A53_PLL_MAX_ID + 1) +#define KEEM_BAY_A53_AON (KEEM_BAY_A53_START_ID + 0) +#define KEEM_BAY_A53_NOC (KEEM_BAY_A53_START_ID + 1) +#define KEEM_BAY_A53_FUSE (KEEM_BAY_A53_START_ID + 2) +#define KEEM_BAY_A53_ROM (KEEM_BAY_A53_START_ID + 3) +#define KEEM_BAY_A53_ICB (KEEM_BAY_A53_START_ID + 4) +#define KEEM_BAY_A53_GIC (KEEM_BAY_A53_START_ID + 5) +#define KEEM_BAY_A53_TIM (KEEM_BAY_A53_START_ID + 6) +#define KEEM_BAY_A53_GPIO (KEEM_BAY_A53_START_ID + 7) +#define KEEM_BAY_A53_JTAG (KEEM_BAY_A53_START_ID + 8) +#define KEEM_BAY_A53_MBIST_0 (KEEM_BAY_A53_START_ID + 9) +#define KEEM_BAY_A53_DSS (KEEM_BAY_A53_START_ID + 10) +#define KEEM_BAY_A53_MSS (KEEM_BAY_A53_START_ID + 11) +#define KEEM_BAY_A53_PSS (KEEM_BAY_A53_START_ID + 12) +#define KEEM_BAY_A53_PCIE (KEEM_BAY_A53_START_ID + 13) +#define KEEM_BAY_A53_VENC (KEEM_BAY_A53_START_ID + 14) +#define KEEM_BAY_A53_VDEC (KEEM_BAY_A53_START_ID + 15) +#define KEEM_BAY_A53_MBIST_1 (KEEM_BAY_A53_START_ID + 16) +#define KEEM_BAY_A53_MBIST_2 (KEEM_BAY_A53_START_ID + 17) +#define KEEM_BAY_A53_MBIST_3 (KEEM_BAY_A53_START_ID + 18) +#define KEEM_BAY_A53_MAX_ID (KEEM_BAY_A53_MBIST_3) + +/* A53_CPR_AUX region. CLK_ID: 31 - 57 */ +#define KEEM_BAY_A53_AUX_START_ID (KEEM_BAY_A53_MAX_ID + 1) +#define KEEM_BAY_A53_AUX_32KHZ (KEEM_BAY_A53_AUX_START_ID + 0) +#define KEEM_BAY_A53_AUX_CPR (KEEM_BAY_A53_AUX_START_ID + 1) +#define KEEM_BAY_A53_AUX_TSENS (KEEM_BAY_A53_AUX_START_ID + 2) +#define KEEM_BAY_A53_AUX_GPIO0 (KEEM_BAY_A53_AUX_START_ID + 3) +#define KEEM_BAY_A53_AUX_GPIO1 (KEEM_BAY_A53_AUX_START_ID + 4) +#define KEEM_BAY_A53_AUX_GPIO2 (KEEM_BAY_A53_AUX_START_ID + 5) +#define KEEM_BAY_A53_AUX_GPIO3 (KEEM_BAY_A53_AUX_START_ID + 6) +#define KEEM_BAY_A53_AUX_DDR_REF (KEEM_BAY_A53_AUX_START_ID + 7) +#define KEEM_BAY_A53_AUX_DDR_REF_BYPASS (KEEM_BAY_A53_AUX_START_ID + 8) +#define KEEM_BAY_A53_AUX_RESERVED1 (KEEM_BAY_A53_AUX_START_ID + 9) +#define KEEM_BAY_A53_AUX_VENC (KEEM_BAY_A53_AUX_START_ID + 10) +#define KEEM_BAY_A53_AUX_VDEC (KEEM_BAY_A53_AUX_START_ID + 11) +#define KEEM_BAY_A53_AUX_USOC_USB_CTRL (KEEM_BAY_A53_AUX_START_ID + 12) +#define KEEM_BAY_A53_AUX_USB (KEEM_BAY_A53_AUX_START_ID + 13) +#define KEEM_BAY_A53_AUX_USB_REF (KEEM_BAY_A53_AUX_START_ID + 14) +#define
Re: [PATCH 2/7] mailbox: keembay-scmi-mailbox: Add support for Keem Bay mailbox
Hi Sudeep, Thanks for your review. On Wed, 2020-07-08 at 21:34 +0100, Sudeep Holla wrote: > On Tue, Jun 16, 2020 at 04:56:08PM +0100, Daniele Alessandrelli > wrote: > > From: Paul Murphy > > > > Keem Bay SoC has a ARM trusted firmware-based secure monitor which > > acts > > as the SCP for the purposes of power management over SCMI. > > > > This driver implements the transport layer for SCMI to function. > > > > Please use the smc transport support in > driver/firmware/arm_scmi/smc.c > for this. You don't need mailbox support for SMC/HVC. Basically you > don't need this driver at all and you have everything you need to > support > what you want. > > Let me know if you face issues. > Sorry, we didn't know about the SMC transport support for SCMI. Looks like it was added only recently, while our driver was already developed and waiting to be upstreamed. I agree that we can drop this driver and switch to the SMC transport as you suggested, but I think we'll have to modify our bootloader SiP service slightly. Paul, can you elaborate? Regards, Daniele
Re: [PATCH v3 2/7] dt-bindings: arm: Add Keem Bay bindings
On Tue, 2020-07-14 at 15:11 -0600, Rob Herring wrote: > On Tue, Jul 14, 2020 at 05:13:00PM +0100, Daniele Alessandrelli > wrote: > > From: Daniele Alessandrelli > > > > Document Intel Movidius SoC code-named Keem Bay, along with the > > Keem Bay > > EVM board. > > > > Reviewed-by: Dinh Nguyen > > Signed-off-by: Daniele Alessandrelli < > > daniele.alessandre...@intel.com> > > --- > > .../devicetree/bindings/arm/keembay.yaml | 19 > > +++ > > /intel,keembay.yaml > > With that, > > Reviewed-by: Rob Herring Thanks. I fixed the file name and the "$id:" field below and will re- submit with your "Reviewed-by" tag. > > > 1 file changed, 19 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/arm/keembay.yaml > > > > diff --git a/Documentation/devicetree/bindings/arm/keembay.yaml > > b/Documentation/devicetree/bindings/arm/keembay.yaml > > new file mode 100644 > > index ..f81b110046ca > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/arm/keembay.yaml > > @@ -0,0 +1,19 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/arm/keembay.yaml# > > And don't forget this update. > > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Keem Bay platform device tree bindings > > + > > +maintainers: > > + - Paul J. Murphy > > + - Daniele Alessandrelli > > + > > +properties: > > + compatible: > > +items: > > + - enum: > > +- intel,keembay-evm > > + - const: intel,keembay > > +... > > -- > > 2.26.2 > >
Re: [PATCH v3 3/7] dt-bindings: clock: Add Keem Bay clock IDs
On Tue, 2020-07-14 at 15:12 -0600, Rob Herring wrote: > On Tue, Jul 14, 2020 at 05:13:01PM +0100, Daniele Alessandrelli > wrote: > > From: Daniele Alessandrelli > > > > Add clock dt-bindings for Keem Bay SoC. > > Where's the binding schema? I should have specified that they are SCMI clocks. Anyway, when I split the original patchset (change done in v2) I had to remove SCMI support from the DT, so these bindings (and the power domain ones) are currently unused. So, probably, the right thing to do is to drop them for now. I'll do that in v4. > > > Signed-off-by: Daniele Alessandrelli < > > daniele.alessandre...@intel.com> > > --- > > include/dt-bindings/clock/keembay-clocks.h | 188 > > + > > 1 file changed, 188 insertions(+) > > create mode 100644 include/dt-bindings/clock/keembay-clocks.h > > > > diff --git a/include/dt-bindings/clock/keembay-clocks.h > > b/include/dt-bindings/clock/keembay-clocks.h > > new file mode 100644 > > index ..4ad6616ee8e0 > > --- /dev/null > > +++ b/include/dt-bindings/clock/keembay-clocks.h > > @@ -0,0 +1,188 @@ > > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause) */ > > +/* > > + * Copyright (c) 2020 Intel Corporation. > > + * > > + * Device tree defines for clocks in Keem Bay. > > + */ > > + > > +#ifndef __DT_BINDINGS_KEEMBAY_CLOCKS_H > > +#define __DT_BINDINGS_KEEMBAY_CLOCKS_H > > + > > +/* CPR_PLL region. CLK_ID: 0 - 11 */ > > +#define KEEM_BAY_A53_PLL_START_ID (0) > > +#define KEEM_BAY_A53_PLL_0_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 0) > > +#define KEEM_BAY_A53_PLL_0_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 1) > > +#define KEEM_BAY_A53_PLL_0_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 2) > > +#define KEEM_BAY_A53_PLL_0_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 3) > > +#define KEEM_BAY_A53_PLL_1_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 4) > > +#define KEEM_BAY_A53_PLL_1_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 5) > > +#define KEEM_BAY_A53_PLL_1_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 6) > > +#define KEEM_BAY_A53_PLL_1_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 7) > > +#define KEEM_BAY_A53_PLL_2_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 8) > > +#define KEEM_BAY_A53_PLL_2_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 9) > > +#define KEEM_BAY_A53_PLL_2_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 10) > > +#define KEEM_BAY_A53_PLL_2_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 11) > > +#define KEEM_BAY_A53_PLL_MAX_ID (KEEM_BAY_A53_PLL_2_OUT_3) > > + > > +/* A53_CPR region. CLK_ID: 12 - 30 */ > > +#define KEEM_BAY_A53_START_ID (KEEM_BAY_A53_PLL_MAX_ID + 1) > > +#define KEEM_BAY_A53_AON (KEEM_BAY_A53_START_ID + 0) > > +#define KEEM_BAY_A53_NOC (KEEM_BAY_A53_START_ID + 1) > > +#define KEEM_BAY_A53_FUSE (KEEM_BAY_A53_START_ID + 2) > > +#define KEEM_BAY_A53_ROM (KEEM_BAY_A53_START_ID + 3) > > +#define KEEM_BAY_A53_ICB (KEEM_BAY_A53_START_ID + 4) > > +#define KEEM_BAY_A53_GIC (KEEM_BAY_A53_START_ID + 5) > > +#define KEEM_BAY_A53_TIM (KEEM_BAY_A53_START_ID + 6) > > +#define KEEM_BAY_A53_GPIO (KEEM_BAY_A53_START_ID + 7) > > +#define KEEM_BAY_A53_JTAG (KEEM_BAY_A53_START_ID + 8) > > +#define KEEM_BAY_A53_MBIST_0 (KEEM_BAY_A53_START_ID + 9) > > +#define KEEM_BAY_A53_DSS (KEEM_BAY_A53_START_ID + 10) > > +#define KEEM_BAY_A53_MSS (KEEM_BAY_A53_START_ID + 11) > > +#define KEEM_BAY_A53_PSS (KEEM_BAY_A53_START_ID + 12) > > +#define KEEM_BAY_A53_PCIE (KEEM_BAY_A53_START_ID + 13) > > +#define KEEM_BAY_A53_VENC (KEEM_BAY_A53_START_ID + 14) > > +#define KEEM_BAY_A53_VDEC (KEEM_BAY_A53_START_ID + 15) > > +#define KEEM_BAY_A53_MBIST_1 (KEEM_BAY_A53_START_ID + 16) > > +#define KEEM_BAY_A53_MBIST_2 (KEEM_BAY_A53_START_ID + 17) > > +#define KEEM_BAY_A53_MBIST_3 (KEEM_BAY_A53_START_ID + 18) > > +#define KEEM_BAY_A53_MAX_ID (KEEM_BAY_A53_MBIST_3) > > + > > +/* A53_CPR_AUX region. CLK_ID: 31 - 57 */ > > +#define KEEM_BAY_A53_AUX_START_ID (KEEM_BAY_A53_MAX_ID + 1) > > +#define KEEM_BAY_A53_AUX_32KHZ (KEEM_BAY_A53_AUX_START_ID + 0) > > +#define KEEM_BAY_A53_AUX_CPR (KEEM_BAY_A53_AUX_START_ID + 1) > > +#define KEEM_BAY_A53_AUX_TSENS (KEEM_BAY_A53_AUX_START_ID + 2) > > +#define KEEM_BAY_A53_AUX_GPIO0 (KEEM_BAY_A53_AUX_START_ID + 3) > > +#define KEEM_BAY_A53_AUX_GPIO1 (KEEM_BAY_A53_AUX_START_ID + 4) > > +#define KEEM_BAY_A53_AUX_GPIO2 (KEEM_BAY_A53_AUX_START_ID + 5) > > +#define KEEM_BAY_A53_AUX_GPIO3 (KEEM_BAY_A53_AUX_START_ID + 6) > > +#define KEEM_BAY_A53_AUX_DDR_REF (KEEM_BAY_A53_AUX_START_ID + 7) > > +#define KEEM_BAY_A53_AUX_DDR_REF_BYPASS (KEEM_BAY_A53_AUX_START_ID > > + 8) > > +#define KEEM_BAY_A53_AUX_RESERV
[PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call
From: Daniele Alessandrelli
Currently, when SMC/HVC is used as transport, the base address of the
shared memory used for communication is not passed to the SMCCC call.
This means that such an address must be hard-coded into the bootloader.
In order to increase flexibility and allow the memory layout to be
changed without modifying the bootloader, this patch adds the shared
memory base address to the a1 argument of the SMCCC call.
On the Secure Monitor side, the service call implementation can
therefore read the a1 argument in order to know the location of the
shared memory to use. This change is backward compatible to existing
service call implementations as long as they don't check for a1 to be
zero.
Signed-off-by: Daniele Alessandrelli
Signed-off-by: Paul J. Murphy
---
drivers/firmware/arm_scmi/smc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/smc.c
index 49bc4b0e8428..aef3a58f8266 100644
--- a/drivers/firmware/arm_scmi/smc.c
+++ b/drivers/firmware/arm_scmi/smc.c
@@ -21,12 +21,14 @@
*
* @cinfo: SCMI channel info
* @shmem: Transmit/Receive shared memory area
+ * @shmem_paddr: Physical address of shmem
* @func_id: smc/hvc call function id
*/
struct scmi_smc {
struct scmi_chan_info *cinfo;
struct scmi_shared_mem __iomem *shmem;
+ resource_size_t shmem_paddr;
struct mutex shmem_lock;
u32 func_id;
};
@@ -73,6 +75,7 @@ static int smc_chan_setup(struct scmi_chan_info *cinfo,
struct device *dev,
dev_err(dev, "failed to ioremap SCMI Tx shared memory\n");
return -EADDRNOTAVAIL;
}
+ scmi_info->shmem_paddr = res.start;
ret = of_property_read_u32(dev->of_node, "arm,smc-id", &func_id);
if (ret < 0)
@@ -109,7 +112,8 @@ static int smc_send_message(struct scmi_chan_info *cinfo,
shmem_tx_prepare(scmi_info->shmem, xfer);
- arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
+ arm_smccc_1_1_invoke(scmi_info->func_id, scmi_info->shmem_paddr, 0, 0,
+0, 0, 0, 0, &res);
scmi_rx_callback(scmi_info->cinfo, shmem_read_header(scmi_info->shmem));
mutex_unlock(&scmi_info->shmem_lock);
--
2.26.2
Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call
Hi Florian, Thanks for you feedback. On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote: > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote: > > From: Daniele Alessandrelli > > > > Currently, when SMC/HVC is used as transport, the base address of > > the > > shared memory used for communication is not passed to the SMCCC > > call. > > This means that such an address must be hard-coded into the > > bootloader. > > > > In order to increase flexibility and allow the memory layout to be > > changed without modifying the bootloader, this patch adds the > > shared > > memory base address to the a1 argument of the SMCCC call. > > > > On the Secure Monitor side, the service call implementation can > > therefore read the a1 argument in order to know the location of the > > shared memory to use. This change is backward compatible to > > existing > > service call implementations as long as they don't check for a1 to > > be > > zero. > > resource_size_t being defined after phys_addr_t, its size is > different > between 32-bit, 32-bit with PAE and 64-bit so it would probably make > more sense to define an physical address alignment, or maybe an > address > that is in multiple of 4KBytes so you can address up to 36-bits of > physical address even on a 32-bit only system? I see your point. After a quick look, I think that, practically, the issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. So, basically, for AArch32 systems with LPAE the 64-bit shmem_paddr gets truncated to 32-bit when it's passed to the SMC32/HVC32 call. To solve that, I would prefer splitting the address between two SMC parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an arbitrary alignment. Would that be reasonable? > > What discovery mechanism does the OS have that the specified address > within the SMCCC call has been accepted by the firmware given the > return > value of that SMCCC call does not appear to be used or checked? Do we > just expect a timeout initializing the SCMI subsystem? The return code is actually checked at the end of the function: https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118 But in the meantime scmi_rx_callback() has already been called. Not sure if that's intentional or a possible bug. > > Given that the kernel must somehow reserve this memory as a shared > memory area for obvious reasons, and the trusted firmware must also > ensure it treats this memory region with specific permissions in its > translation regime, does it really make sense to give that much > flexibility? Well, the trusted firmware might reserve a bigger region to be used for other service as well. In other words, the MMU of TF-A is not necessary specifically set up for this region, but, possibly, for a bigger general shared region. Passing the SCMI shmem to the SMC call allows the shmem to be moved within such bigger shared memory without modifying the trusted firmware. > > If your boot loader has FDT patching capability, maybe it can also do > a > SMC call to provide the address to your trusted firmware, prior to > loading the Linux kernel, and then they both agree, prior to boot > about > the shared memory address? Yes, that's a possible solution, but it looks more complicated to me, since it adds an additional component (the boot loader) to the equation, while the goal of this patch was to reduce the coupling between components (namely the DT/kernel and the trusted firmware). I guess my question is: if we fix the handling of LPAE addresses and the SMC return code, what is the drawback of having the shmem address passed to the SMC? Anyway, I should have mentioned this in the commit message (sorry for not doing so), but I submitted this patch because initial feedback from Sudeep was positive [1]; but if there is no consensus around it I'm fine with dropping it. [1] https://lore.kernel.org/lkml/20200710075931.GB1189@bogus/ > > > Signed-off-by: Daniele Alessandrelli < > > daniele.alessandre...@intel.com> > > Signed-off-by: Paul J. Murphy > > --- > > drivers/firmware/arm_scmi/smc.c | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/arm_scmi/smc.c > > b/drivers/firmware/arm_scmi/smc.c > > index 49bc4b0e8428..aef3a58f8266 100644 > > --- a/drivers/firmware/arm_scmi/smc.c > > +++ b/drivers/firmware/arm_scmi/smc.c > > @@ -21,12 +21,14 @@ > > * > > * @cinfo: SCMI channel info > > * @shmem: Transmit/Receive shared memory area > > + * @shmem_paddr: Physical address of shmem > > * @func_id: smc/hvc call function id > > */ > > > > stru
[PATCH v4 0/5] Add initial Keem Bay SoC / Board support
Hi, This patch-set adds initial support for a new Intel Movidius SoC code-named Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This initial patch-set enables only the minimal set of components required to make the Keem Bay EVM board boot into initramfs. Changes from v3 to v4: * Renamed SoC dt-bindings file to intel,keembay.yaml * Dropped clock and power domain dt-binding header files (because currently unused) Changes from v2 to v3: * Split dt-bindings patch into 3 different patches (SoC/board bindings, clock bindings, and power domains bindings). * Added dual license (GPL-2.0-only or BSD-3-Clause) to dt-bindings header files and DTS files. Changes from v1 to v2: * Moved keembay-scmi-mailbox driver to a separate patchset * Removed Keem Bay SCMI mailbox and SCMI node from Keem Bay SoC device tree Regards, Daniele Daniele Alessandrelli (5): arm64: Add config for Keem Bay SoC dt-bindings: arm: Add Keem Bay bindings MAINTAINERS: Add maintainers for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay EVM board .../bindings/arm/intel,keembay.yaml | 19 +++ MAINTAINERS | 8 ++ arch/arm64/Kconfig.platforms | 5 + arch/arm64/boot/dts/intel/Makefile| 1 + arch/arm64/boot/dts/intel/keembay-evm.dts | 37 ++ arch/arm64/boot/dts/intel/keembay-soc.dtsi| 123 ++ 6 files changed, 193 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/intel,keembay.yaml create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi -- 2.26.2
[PATCH v4 5/5] arm64: dts: keembay: Add device tree for Keem Bay EVM board
From: Daniele Alessandrelli
Add initial device tree for Keem Bay EVM board. With this minimal device
tree the board boots fine using an initramfs image.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/intel/Makefile| 1 +
arch/arm64/boot/dts/intel/keembay-evm.dts | 37 +++
3 files changed, 39 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 82ca9748fb70..aa86a74ea5d7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/intel,keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT
diff --git a/arch/arm64/boot/dts/intel/Makefile
b/arch/arm64/boot/dts/intel/Makefile
index 40cb16e8c814..296eceec4276 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
dtb-$(CONFIG_ARCH_AGILEX) += socfpga_agilex_socdk.dtb \
socfpga_agilex_socdk_nand.dtb
+dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/keembay-evm.dts
b/arch/arm64/boot/dts/intel/keembay-evm.dts
new file mode 100644
index ..466c85363a29
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-evm.dts
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * Copyright (C) 2020, Intel Corporation
+ *
+ * Device tree describing Keem Bay EVM board.
+ */
+
+/dts-v1/;
+
+#include "keembay-soc.dtsi"
+
+/ {
+ model = "Keem Bay EVM";
+ compatible = "intel,keembay-evm", "intel,keembay";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 2GB of DDR memory. */
+ reg = <0x0 0x8000 0x0 0x8000>;
+ };
+
+};
+
+&uart3 {
+ status = "okay";
+};
--
2.26.2
[PATCH v4 1/5] arm64: Add config for Keem Bay SoC
From: Daniele Alessandrelli Add ARCH_KEEMBAY configuration option to support Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- arch/arm64/Kconfig.platforms | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 8dd05b2a925c..95c1b9042009 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -121,6 +121,11 @@ config ARCH_HISI help This enables support for Hisilicon ARMv8 SoC family +config ARCH_KEEMBAY + bool "Keem Bay SoC" + help + This enables support for Intel Movidius SoC code-named Keem Bay. + config ARCH_MEDIATEK bool "MediaTek SoC Family" select ARM_GIC -- 2.26.2
[PATCH v4 4/5] arm64: dts: keembay: Add device tree for Keem Bay SoC
From: Daniele Alessandrelli
Add initial device tree for Intel Movidius SoC code-named Keem Bay.
This initial DT includes nodes for Cortex-A53 cores, UARTs, GIC, PSCI,
and PMU.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS| 1 +
arch/arm64/boot/dts/intel/keembay-soc.dtsi | 123 +
2 files changed, 124 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 3babb333b556..82ca9748fb70 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/intel,keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT
M: Jonathan Cameron
diff --git a/arch/arm64/boot/dts/intel/keembay-soc.dtsi
b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
new file mode 100644
index ..781761d2942b
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * Copyright (C) 2020, Intel Corporation.
+ *
+ * Device tree describing Keem Bay SoC.
+ */
+
+#include
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ gic: interrupt-controller@2050 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0 0x2050 0x0 0x2>, /* GICD */
+ <0x0 0x2058 0x0 0x8>; /* GICR */
+ /* VGIC maintenance interrupt */
+ interrupts = ;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ /* Secure, non-secure, virtual, and hypervisor */
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart0: serial@2015 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2015 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart1: serial@2016 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2016 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ status = "disabled";
+ };
+
+ uart2: serial@2017 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x2017 0x0 0x100>;
+ interrupts = ;
+ clock-frequency = <2400>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+
[PATCH v4 3/5] MAINTAINERS: Add maintainers for Keem Bay SoC
From: Daniele Alessandrelli Add maintainers for the new Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- MAINTAINERS | 6 ++ 1 file changed, 6 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index b4a43a9e7fbc..3babb333b556 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1954,6 +1954,12 @@ F: drivers/irqchip/irq-ixp4xx.c F: include/linux/irqchip/irq-ixp4xx.h F: include/linux/platform_data/timer-ixp4xx.h +ARM/INTEL KEEMBAY ARCHITECTURE +M: Paul J. Murphy +M: Daniele Alessandrelli +S: Maintained +F: Documentation/devicetree/bindings/arm/intel,keembay.yaml + ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT M: Jonathan Cameron L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.26.2
[PATCH v4 2/5] dt-bindings: arm: Add Keem Bay bindings
From: Daniele Alessandrelli Document Intel Movidius SoC code-named Keem Bay, along with the Keem Bay EVM board. Reviewed-by: Dinh Nguyen Reviewed-by: Rob Herring Signed-off-by: Daniele Alessandrelli --- .../bindings/arm/intel,keembay.yaml | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/intel,keembay.yaml diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml new file mode 100644 index ..4d925785f504 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/intel,keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Keem Bay platform device tree bindings + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +properties: + compatible: +items: + - enum: +- intel,keembay-evm + - const: intel,keembay +... -- 2.26.2
Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call
On Thu, 2020-07-16 at 12:57 -0700, Florian Fainelli wrote: > > On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote: > > Hi Florian, > > > > Thanks for you feedback. > > > > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote: > > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote: > > > > From: Daniele Alessandrelli > > > > > > > > Currently, when SMC/HVC is used as transport, the base address > > > > of > > > > the > > > > shared memory used for communication is not passed to the SMCCC > > > > call. > > > > This means that such an address must be hard-coded into the > > > > bootloader. > > > > > > > > In order to increase flexibility and allow the memory layout to > > > > be > > > > changed without modifying the bootloader, this patch adds the > > > > shared > > > > memory base address to the a1 argument of the SMCCC call. > > > > > > > > On the Secure Monitor side, the service call implementation can > > > > therefore read the a1 argument in order to know the location of > > > > the > > > > shared memory to use. This change is backward compatible to > > > > existing > > > > service call implementations as long as they don't check for a1 > > > > to > > > > be > > > > zero. > > > > > > resource_size_t being defined after phys_addr_t, its size is > > > different > > > between 32-bit, 32-bit with PAE and 64-bit so it would probably > > > make > > > more sense to define an physical address alignment, or maybe an > > > address > > > that is in multiple of 4KBytes so you can address up to 36-bits > > > of > > > physical address even on a 32-bit only system? > > > > I see your point. After a quick look, I think that, practically, > > the > > issue is with ARM32 LPAE addresses, for which phys_addr_t is a u64. > > So, > > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr > > gets > > truncated to 32-bit when it's passed to the SMC32/HVC32 call. > > > > To solve that, I would prefer splitting the address between two SMC > > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an > > arbitrary alignment. Would that be reasonable? > > The low/high part would only be relevant on a 32-bit LPAE platform > which > is probably a corner case, I would just pass the shmem_paddr / 4096 > since that is the smallest granule size and alignment possible and it > still allows you to map up to 36-bits of physical address, which is > the > maximum that the long descriptor in LPAE can support. For 64-bit we > have > no such problems since we have the full register width. > > > > What discovery mechanism does the OS have that the specified > > > address > > > within the SMCCC call has been accepted by the firmware given the > > > return > > > value of that SMCCC call does not appear to be used or checked? > > > Do we > > > just expect a timeout initializing the SCMI subsystem? > > > > The return code is actually checked at the end of the function: > > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118 > > > > But in the meantime scmi_rx_callback() has already been called. Not > > sure if that's intentional or a possible bug. > > > > > Given that the kernel must somehow reserve this memory as a > > > shared > > > memory area for obvious reasons, and the trusted firmware must > > > also > > > ensure it treats this memory region with specific permissions in > > > its > > > translation regime, does it really make sense to give that much > > > flexibility? > > > > Well, the trusted firmware might reserve a bigger region to be used > > for > > other service as well. In other words, the MMU of TF-A is not > > necessary > > specifically set up for this region, but, possibly, for a bigger > > general shared region. > > But presumably the Linux shared memory area should be mapped in a > slightly different way than > > > Passing the SCMI shmem to the SMC call allows the shmem to be moved > > within such bigger shared memory without modifying the trusted > > firmware. > > > > > If your boot loader has FDT patching capability, maybe it can > > > also do > > > a > > > SMC call to provide the address to your trusted firmware, prior > &
Re: [PATCH] firmware: arm_scmi: Pass shmem address to SMCCC call
On Fri, 2020-07-17 at 11:31 +0100, Sudeep Holla wrote: > On Thu, Jul 16, 2020 at 12:57:23PM -0700, Florian Fainelli wrote: > > > > On 7/16/2020 7:13 AM, Daniele Alessandrelli wrote: > > > Hi Florian, > > > > > > Thanks for you feedback. > > > > > > On Wed, 2020-07-15 at 15:43 -0700, Florian Fainelli wrote: > > > > On 7/15/2020 9:55 AM, Daniele Alessandrelli wrote: > > > > > From: Daniele Alessandrelli > > > > > > > > > > Currently, when SMC/HVC is used as transport, the base > > > > > address of > > > > > the > > > > > shared memory used for communication is not passed to the > > > > > SMCCC > > > > > call. > > > > > This means that such an address must be hard-coded into the > > > > > bootloader. > > > > > > > > > > In order to increase flexibility and allow the memory layout > > > > > to be > > > > > changed without modifying the bootloader, this patch adds the > > > > > shared > > > > > memory base address to the a1 argument of the SMCCC call. > > > > > > > > > > On the Secure Monitor side, the service call implementation > > > > > can > > > > > therefore read the a1 argument in order to know the location > > > > > of the > > > > > shared memory to use. This change is backward compatible to > > > > > existing > > > > > service call implementations as long as they don't check for > > > > > a1 to > > > > > be > > > > > zero. > > > > > > > > resource_size_t being defined after phys_addr_t, its size is > > > > different > > > > between 32-bit, 32-bit with PAE and 64-bit so it would probably > > > > make > > > > more sense to define an physical address alignment, or maybe an > > > > address > > > > that is in multiple of 4KBytes so you can address up to 36-bits > > > > of > > > > physical address even on a 32-bit only system? > > > > > > I see your point. After a quick look, I think that, practically, > > > the > > > issue is with ARM32 LPAE addresses, for which phys_addr_t is a > > > u64. So, > > > basically, for AArch32 systems with LPAE the 64-bit shmem_paddr > > > gets > > > truncated to 32-bit when it's passed to the SMC32/HVC32 call. > > > > > > To solve that, I would prefer splitting the address between two > > > SMC > > > parameters (a1 = addr_lo, a2 = addr_hi), instead of imposing an > > > arbitrary alignment. Would that be reasonable? > > > > The low/high part would only be relevant on a 32-bit LPAE platform > > which > > is probably a corner case, I would just pass the shmem_paddr / 4096 > > since that is the smallest granule size and alignment possible and > > it > > still allows you to map up to 36-bits of physical address, which is > > the > > maximum that the long descriptor in LPAE can support. For 64-bit we > > have > > no such problems since we have the full register width. > > > > OK, I will check if 32-bit identifier can be relaxed in the spec in > which > case we can avoid having DT binding for the identifier. If that is > possible > we could use addr/4k page size. > > > > > What discovery mechanism does the OS have that the specified > > > > address > > > > within the SMCCC call has been accepted by the firmware given > > > > the > > > > return value of that SMCCC call does not appear to be used or > > > > checked? Do > > > > we just expect a timeout initializing the SCMI subsystem? > > > > > > The return code is actually checked at the end of the function: > > > https://elixir.bootlin.com/linux/v5.8-rc4/source/drivers/firmware/arm_scmi/smc.c#L118 > > > > > > But in the meantime scmi_rx_callback() has already been called. > > > Not > > > sure if that's intentional or a possible bug. > > > > > > > Given that the kernel must somehow reserve this memory as a > > > > shared > > > > memory area for obvious reasons, and the trusted firmware must > > > > also > > > > ensure it treats this memory region with specific permissions > > > > in its > > > > translation regime, does it really make sense to give that much > > > >
[PATCH 2/7] mailbox: keembay-scmi-mailbox: Add support for Keem Bay mailbox
From: Paul Murphy
Keem Bay SoC has a ARM trusted firmware-based secure monitor which acts
as the SCP for the purposes of power management over SCMI.
This driver implements the transport layer for SCMI to function.
Doclink:
http://infocenter.arm.com/help/topic/com.arm.doc.den0056b/DEN0056B_System_Control_and_Management_Interface_v2_0.pdf
Reviewed-by: Dinh Nguyen
Signed-off-by: Paul Murphy
---
MAINTAINERS| 6 +
drivers/mailbox/Kconfig| 9 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/keembay-scmi-mailbox.c | 203 +
4 files changed, 220 insertions(+)
create mode 100644 drivers/mailbox/keembay-scmi-mailbox.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 5ddad1d70f5f..4887e004cd26 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9330,6 +9330,12 @@ F: include/linux/crash_dump.h
F: include/uapi/linux/vmcore.h
F: kernel/crash_*.c
+KEEMBAY SCMI MAILBOX DRIVER
+M: Paul Murphy
+S: Maintained
+F:
Documentation/devicetree/bindings/mailbox/intel,keembay-scmi-mailbox.yaml
+F: drivers/mailbox/keembay-scmi-mailbox.c
+
KEENE FM RADIO TRANSMITTER DRIVER
M: Hans Verkuil
L: linux-me...@vger.kernel.org
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 05b1009e2820..064d4c4794a2 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,15 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config KEEMBAY_SCMI_MBOX
+ tristate "Keem Bay SoC SCMI Mailbox"
+ depends on HAVE_ARM_SMCCC
+ help
+ An implementation of a mailbox implemented using 'smc' calls to the
+ ARM secure world monitor. This enables communication with an 'SCP'
+ running in the secure world on Keem Bay SoCs.
+ Say Y here if you want to build the Keem Bay SoC SCMI Mailbox.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 60d224b723a1..7aba6edc8d44 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -54,3 +54,5 @@ obj-$(CONFIG_SUN6I_MSGBOX)+= sun6i-msgbox.o
obj-$(CONFIG_SPRD_MBOX)+= sprd-mailbox.o
obj-$(CONFIG_QCOM_IPCC)+= qcom-ipcc.o
+
+obj-$(CONFIG_KEEMBAY_SCMI_MBOX)+= keembay-scmi-mailbox.o
diff --git a/drivers/mailbox/keembay-scmi-mailbox.c
b/drivers/mailbox/keembay-scmi-mailbox.c
new file mode 100644
index ..6f13b21f4f80
--- /dev/null
+++ b/drivers/mailbox/keembay-scmi-mailbox.c
@@ -0,0 +1,203 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Keem Bay SCMI mailbox driver.
+ *
+ * Copyright (c) 2019-2020 Intel Corporation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Function id of SiP service */
+#define KMB_SIP_SVC_SCMI 0xFF19
+
+/*
+ * Number of channels this mailbox supports: 1 channel,
+ * between AP and SCP.
+ */
+#define NUM_CHANNELS 1
+
+/* How long to wait before triggering the mailbox receive event */
+#define NOTIFY_WAIT_TIME_NS 50
+
+/**
+ * struct keembay_scmi_mbox
+ * @mbox: Mailbox controller struct
+ * @dev: Platform device
+ * @shmem_res: Resource describing memory region shared between secure and
+ * non-secure world
+ * @notify_hrt:Timer to asynchronously trigger a mbox received data
event
+ */
+struct keembay_scmi_mbox {
+ struct mbox_controller mbox;
+ struct device *dev;
+ struct resource shmem_res;
+ struct hrtimer notify_hrt;
+};
+
+static int keembay_scmi_request(u32 base_address)
+{
+ struct arm_smccc_res res;
+ u64 function_id;
+ u16 function_number = KMB_SIP_SVC_SCMI;
+
+ function_id = ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32,
+ARM_SMCCC_OWNER_SIP, function_number);
+
+ arm_smccc_smc(function_id, base_address, 0, 0, 0, 0, 0, 0, &res);
+
+ return res.a0;
+}
+
+static enum hrtimer_restart keembay_scmi_async_notify(struct hrtimer *hrtimer)
+{
+ struct keembay_scmi_mbox *mbox =
+ container_of(hrtimer, struct keembay_scmi_mbox, notify_hrt);
+ struct mbox_chan *chan = &mbox->mbox.chans[0];
+
+ mbox_chan_received_data(chan, NULL);
+
+ return HRTIMER_NORESTART;
+}
+
+static int keembay_scmi_mailbox_send_data(struct mbox_chan *chan, void *data)
+{
+ struct keembay_scmi_mbox *mbox = chan->con_priv;
+ struct device *dev = mbox->dev;
+ int rc;
+
+ /*
+* Handle case where timer is still on and a new message arrives.
+* We only have one timer, if it were to happen that a second
+* request came in and we failed to respond as expected to the
+* first, the caller's state machine may end up in an unexpected
+* state.
+*/
+ if (hrtimer_active(
[PATCH 4/7] dt-bindings: arm: Add Keem Bay bindings
From: Daniele Alessandrelli Document Intel Movidius SoC code-named Keem Bay, along with the Keem Bay EVM board. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- .../devicetree/bindings/arm/keembay.yaml | 19 ++ include/dt-bindings/clock/keembay-clocks.h| 188 ++ include/dt-bindings/power/keembay-power.h | 19 ++ 3 files changed, 226 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml create mode 100644 include/dt-bindings/clock/keembay-clocks.h create mode 100644 include/dt-bindings/power/keembay-power.h diff --git a/Documentation/devicetree/bindings/arm/keembay.yaml b/Documentation/devicetree/bindings/arm/keembay.yaml new file mode 100644 index ..f81b110046ca --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keembay.yaml @@ -0,0 +1,19 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/keembay.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Keem Bay platform device tree bindings + +maintainers: + - Paul J. Murphy + - Daniele Alessandrelli + +properties: + compatible: +items: + - enum: +- intel,keembay-evm + - const: intel,keembay +... diff --git a/include/dt-bindings/clock/keembay-clocks.h b/include/dt-bindings/clock/keembay-clocks.h new file mode 100644 index ..a68e986dd565 --- /dev/null +++ b/include/dt-bindings/clock/keembay-clocks.h @@ -0,0 +1,188 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2020 Intel Corporation. + * + * Device tree defines for clocks in Keem Bay. + */ + +#ifndef __DT_BINDINGS_KEEMBAY_CLOCKS_H +#define __DT_BINDINGS_KEEMBAY_CLOCKS_H + +/* CPR_PLL region. CLK_ID: 0 - 11 */ +#define KEEM_BAY_A53_PLL_START_ID (0) +#define KEEM_BAY_A53_PLL_0_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 0) +#define KEEM_BAY_A53_PLL_0_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 1) +#define KEEM_BAY_A53_PLL_0_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 2) +#define KEEM_BAY_A53_PLL_0_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 3) +#define KEEM_BAY_A53_PLL_1_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 4) +#define KEEM_BAY_A53_PLL_1_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 5) +#define KEEM_BAY_A53_PLL_1_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 6) +#define KEEM_BAY_A53_PLL_1_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 7) +#define KEEM_BAY_A53_PLL_2_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 8) +#define KEEM_BAY_A53_PLL_2_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 9) +#define KEEM_BAY_A53_PLL_2_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 10) +#define KEEM_BAY_A53_PLL_2_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 11) +#define KEEM_BAY_A53_PLL_MAX_ID (KEEM_BAY_A53_PLL_2_OUT_3) + +/* A53_CPR region. CLK_ID: 12 - 30 */ +#define KEEM_BAY_A53_START_ID (KEEM_BAY_A53_PLL_MAX_ID + 1) +#define KEEM_BAY_A53_AON (KEEM_BAY_A53_START_ID + 0) +#define KEEM_BAY_A53_NOC (KEEM_BAY_A53_START_ID + 1) +#define KEEM_BAY_A53_FUSE (KEEM_BAY_A53_START_ID + 2) +#define KEEM_BAY_A53_ROM (KEEM_BAY_A53_START_ID + 3) +#define KEEM_BAY_A53_ICB (KEEM_BAY_A53_START_ID + 4) +#define KEEM_BAY_A53_GIC (KEEM_BAY_A53_START_ID + 5) +#define KEEM_BAY_A53_TIM (KEEM_BAY_A53_START_ID + 6) +#define KEEM_BAY_A53_GPIO (KEEM_BAY_A53_START_ID + 7) +#define KEEM_BAY_A53_JTAG (KEEM_BAY_A53_START_ID + 8) +#define KEEM_BAY_A53_MBIST_0 (KEEM_BAY_A53_START_ID + 9) +#define KEEM_BAY_A53_DSS (KEEM_BAY_A53_START_ID + 10) +#define KEEM_BAY_A53_MSS (KEEM_BAY_A53_START_ID + 11) +#define KEEM_BAY_A53_PSS (KEEM_BAY_A53_START_ID + 12) +#define KEEM_BAY_A53_PCIE (KEEM_BAY_A53_START_ID + 13) +#define KEEM_BAY_A53_VENC (KEEM_BAY_A53_START_ID + 14) +#define KEEM_BAY_A53_VDEC (KEEM_BAY_A53_START_ID + 15) +#define KEEM_BAY_A53_MBIST_1 (KEEM_BAY_A53_START_ID + 16) +#define KEEM_BAY_A53_MBIST_2 (KEEM_BAY_A53_START_ID + 17) +#define KEEM_BAY_A53_MBIST_3 (KEEM_BAY_A53_START_ID + 18) +#define KEEM_BAY_A53_MAX_ID (KEEM_BAY_A53_MBIST_3) + +/* A53_CPR_AUX region. CLK_ID: 31 - 57 */ +#define KEEM_BAY_A53_AUX_START_ID (KEEM_BAY_A53_MAX_ID + 1) +#define KEEM_BAY_A53_AUX_32KHZ (KEEM_BAY_A53_AUX_START_ID + 0) +#define KEEM_BAY_A53_AUX_CPR (KEEM_BAY_A53_AUX_START_ID + 1) +#define KEEM_BAY_A53_AUX_TSENS (KEEM_BAY_A53_AUX_START_ID + 2) +#define KEEM_BAY_A53_AUX_GPIO0 (KEEM_BAY_A53_AUX_START_ID + 3) +#define KEEM_BAY_A53_AUX_GPIO1 (KEEM_BAY_A53_AUX_START_ID + 4) +#define KEEM_BAY_A53_AUX_GPIO2 (KEEM_BAY_A53_AUX_START_ID + 5) +#define KEEM_BAY_A53_AUX_GPIO3 (KEEM_BAY_A53_AUX_START_ID + 6) +#define KEEM_BAY_A53_AUX_DDR_REF (KEEM_BAY_A53_AUX_START_ID + 7) +#define KEEM_BAY_A53_AUX_DDR_REF_BYPASS (KEEM_BAY_A53_AUX_START_ID + 8) +#define KEEM_BAY_A53_AUX_RESERVED1 (KEEM_BAY_A53_AUX_START_ID + 9) +#define KEEM_BAY_A53_AUX_VENC (KEEM_BAY_A53_AUX_START_ID + 10) +#define KEEM_BAY_A53_AUX_VDEC (KEEM_BAY_A53_AUX_START_ID + 11) +#define KEEM_BAY_A53_AUX_USOC_USB_CTRL (KEEM_BAY_A53_AUX_START_ID + 12) +#define KEEM_BAY_A53_AUX_USB (KEEM_BAY_A53_AUX_START_ID + 13) +#define KEEM_BAY_A53_AUX_USB_REF (KEEM_BAY_A53_AUX_START_ID + 14) +#define
[PATCH 0/7] Add initial Keem Bay SoC / Board support
Hi, This patch-set adds initial support for a new Intel Movidius SoC code-named Keem Bay. The SoC couples an ARM Cortex A53 CPU with an Intel Movidius VPU. This initial patch-set enables only the minimal set of components required to make the Keem Bay EVM board boot into initramfs. Brief summary of the patch-set: * Patches 1-2 add the Keem Bay SCMI Mailbox driver (needed to enable SCMI in Keem Bay) * Patch 3 adds the ARCH_KEEMBAY config option * Patches 4-7 add minimal device tree for Keem Bay SoC and Keem Bay EVM (together with information about the SoC maintainers) Regards, Daniele Daniele Alessandrelli (5): arm64: Add config for Keem Bay SoC dt-bindings: arm: Add Keem Bay bindings MAINTAINERS: Add maintainers for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay SoC arm64: dts: keembay: Add device tree for Keem Bay EVM board Paul Murphy (2): dt-bindings: mailbox: Add Keem Bay SCMI mailbox bindings mailbox: keembay-scmi-mailbox: Add support for Keem Bay mailbox .../devicetree/bindings/arm/keembay.yaml | 19 ++ .../mailbox/intel,keembay-scmi-mailbox.yaml | 44 MAINTAINERS | 16 ++ arch/arm64/Kconfig.platforms | 5 + arch/arm64/boot/dts/intel/Makefile| 1 + arch/arm64/boot/dts/intel/keembay-evm.dts | 55 + arch/arm64/boot/dts/intel/keembay-soc.dtsi| 172 +++ drivers/mailbox/Kconfig | 9 + drivers/mailbox/Makefile | 2 + drivers/mailbox/keembay-scmi-mailbox.c| 203 ++ include/dt-bindings/clock/keembay-clocks.h| 188 include/dt-bindings/power/keembay-power.h | 19 ++ 12 files changed, 733 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml create mode 100644 Documentation/devicetree/bindings/mailbox/intel,keembay-scmi-mailbox.yaml create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi create mode 100644 drivers/mailbox/keembay-scmi-mailbox.c create mode 100644 include/dt-bindings/clock/keembay-clocks.h create mode 100644 include/dt-bindings/power/keembay-power.h -- 2.26.2
[PATCH 6/7] arm64: dts: keembay: Add device tree for Keem Bay SoC
From: Daniele Alessandrelli
Add initial device tree for Intel Movidius SoC code-named Keem Bay.
This initial DT includes nodes for Cortex-A53 cores, UARTs, timers, GIC,
PSCI, PMU, and Keem Bay SCMI mailbox.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS| 1 +
arch/arm64/boot/dts/intel/keembay-soc.dtsi | 172 +
2 files changed, 173 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-soc.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 3b919aa8b1bd..610907bf391b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
F: include/dt-bindings/clock/keembay-clocks.h
F: include/dt-bindings/power/keembay-power.h
diff --git a/arch/arm64/boot/dts/intel/keembay-soc.dtsi
b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
new file mode 100644
index ..bd0a48f24e09
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-soc.dtsi
@@ -0,0 +1,172 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020, Intel Corporation.
+ *
+ * Device tree describing Keem Bay SoC.
+ */
+
+#include
+#include
+#include
+
+/ {
+ compatible = "intel,keembay";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x0>;
+ enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x1>;
+ enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x2>;
+ enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53";
+ device_type = "cpu";
+ reg = <0x3>;
+ enable-method = "psci";
+ clocks = <&scmi_dvfs 0>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ firmware: firmware {
+
+ scmi: scmi {
+ compatible = "arm,scmi";
+ mboxes = <&scmi_mailbox 0>;
+ shmem = <&scmi_sec_shmem>;
+ mbox-names = "tx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ scmi_devpd: protocol@11 {
+ reg = <0x11>;
+ #power-domain-cells = <1>;
+ };
+
+ scmi_dvfs: protocol@13 {
+ reg = <0x13>;
+ #clock-cells = <1>;
+ };
+
+ scmi_clk: protocol@14 {
+ reg = <0x14>;
+ #clock-cells = <1>;
+ };
+ };
+ };
+
+ scmi_mailbox: scmi_mailbox {
+ compatible = "intel,keembay-scmi-mailbox";
+ #mbox-cells = <1>;
+ memory-region = <&scmi_sec_shmem>;
+ u-boot,dm-pre-reloc;
+ };
+
+ gic: interrupt-controller@2050 {
+ compatible = "arm,gic-v3";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0 0x2050 0x0 0x2>, /* GICD */
+ <0x0 0x2058 0x0 0x8>; /* GICR */
+ /* VGIC maintenance interrupt */
+ interrupts = ;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ /* Secure, non-secure, virtual, and hypervisor */
+ interrupts = ,
+,
+,
+;
+
[PATCH 1/7] dt-bindings: mailbox: Add Keem Bay SCMI mailbox bindings
From: Paul Murphy
These are the bindings required for the Intel Keem Bay SCMI mailbox
driver.
Reviewed-by: Dinh Nguyen
Signed-off-by: Paul Murphy
---
.../mailbox/intel,keembay-scmi-mailbox.yaml | 44 +++
1 file changed, 44 insertions(+)
create mode 100644
Documentation/devicetree/bindings/mailbox/intel,keembay-scmi-mailbox.yaml
diff --git
a/Documentation/devicetree/bindings/mailbox/intel,keembay-scmi-mailbox.yaml
b/Documentation/devicetree/bindings/mailbox/intel,keembay-scmi-mailbox.yaml
new file mode 100644
index ..149294dd8141
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/intel,keembay-scmi-mailbox.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2020 Intel Corporation
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/mailbox/intel,keembay-scmi-mailbox.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Intel Keem Bay SCMI mailbox
+
+maintainers:
+ - Paul Murphy
+
+description: |
+ The Intel Keem Bay SCMI mailbox is used to communicate SCMI messages to the
+ runtime service in BL31 behaving as the SCMI 'SCP'.
+ Refer to ./mailbox.txt for generic information about mailbox device-tree
+ bindings.
+ For more information about SCMI, refer to the bindings described in
+ Documentation/devicetree/bindings/arm/arm,scmi.txt
+
+properties:
+ compatible:
+enum:
+ - intel,keembay-scmi-mailbox
+
+ "#mbox-cells":
+const: 1
+
+ memory-region:
+description:
+ Memory region describing the SCMI shared memory
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - memory-region
+
+examples:
+ - |
+scmi_mailbox: scmi_mailbox {
+compatible = "intel,keembay-scmi-mailbox";
+#mbox-cells = <1>;
+memory-region = <&scmi_sec_shmem>;
+};
--
2.26.2
[PATCH 5/7] MAINTAINERS: Add maintainers for Keem Bay SoC
From: Daniele Alessandrelli Add maintainers for the new Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- MAINTAINERS | 8 1 file changed, 8 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4887e004cd26..3b919aa8b1bd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1954,6 +1954,14 @@ F: drivers/irqchip/irq-ixp4xx.c F: include/linux/irqchip/irq-ixp4xx.h F: include/linux/platform_data/timer-ixp4xx.h +ARM/INTEL KEEMBAY ARCHITECTURE +M: Paul J. Murphy +M: Daniele Alessandrelli +S: Maintained +F: Documentation/devicetree/bindings/arm/keembay.yaml +F: include/dt-bindings/clock/keembay-clocks.h +F: include/dt-bindings/power/keembay-power.h + ARM/INTEL RESEARCH IMOTE/STARGATE 2 MACHINE SUPPORT M: Jonathan Cameron L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) -- 2.26.2
[PATCH 7/7] arm64: dts: keembay: Add device tree for Keem Bay EVM board
From: Daniele Alessandrelli
Add initial device tree for Keem Bay EVM board. With this minimal device
tree the board boots fine using an initramfs image.
Reviewed-by: Dinh Nguyen
Signed-off-by: Daniele Alessandrelli
---
MAINTAINERS | 1 +
arch/arm64/boot/dts/intel/Makefile| 1 +
arch/arm64/boot/dts/intel/keembay-evm.dts | 55 +++
3 files changed, 57 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/keembay-evm.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 610907bf391b..d714762e805c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1959,6 +1959,7 @@ M:Paul J. Murphy
M: Daniele Alessandrelli
S: Maintained
F: Documentation/devicetree/bindings/arm/keembay.yaml
+F: arch/arm64/boot/dts/intel/keembay-evm.dts
F: arch/arm64/boot/dts/intel/keembay-soc.dtsi
F: include/dt-bindings/clock/keembay-clocks.h
F: include/dt-bindings/power/keembay-power.h
diff --git a/arch/arm64/boot/dts/intel/Makefile
b/arch/arm64/boot/dts/intel/Makefile
index 40cb16e8c814..296eceec4276 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
dtb-$(CONFIG_ARCH_AGILEX) += socfpga_agilex_socdk.dtb \
socfpga_agilex_socdk_nand.dtb
+dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/keembay-evm.dts
b/arch/arm64/boot/dts/intel/keembay-evm.dts
new file mode 100644
index ..46859763cb03
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/keembay-evm.dts
@@ -0,0 +1,55 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020, Intel Corporation
+ *
+ * Device tree describing Keem Bay EVM board.
+ */
+
+/dts-v1/;
+
+#include "keembay-soc.dtsi"
+#include
+#include
+
+/ {
+ model = "Keem Bay EVM";
+ compatible = "intel,keembay-evm";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 2GB of DDR memory. */
+ reg = <0x0 0x8000 0x0 0x8000>;
+ };
+
+ sysmem@8400 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x8400 0x0 0x80>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges = <0 0x0 0x0 0x8400 0x0 0x80>;
+ /*
+* Allocate 1MB at fixed location for shared memory between
+* non-secure world and BL31 to be used for SCMI.
+*/
+ scmi_sec_shmem: scmi_sec_shmem@0 {
+ compatible = "arm,scmi-shmem";
+ reg = <0x0 0x0 0x0 0x10>;
+ pool;
+ };
+ };
+};
+
+&uart3 {
+ status = "okay";
+};
--
2.26.2
[PATCH 3/7] arm64: Add config for Keem Bay SoC
From: Daniele Alessandrelli Add ARCH_KEEMBAY configuration option to support Intel Movidius SoC code-named Keem Bay. Reviewed-by: Dinh Nguyen Signed-off-by: Daniele Alessandrelli --- arch/arm64/Kconfig.platforms | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 8dd05b2a925c..95c1b9042009 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -121,6 +121,11 @@ config ARCH_HISI help This enables support for Hisilicon ARMv8 SoC family +config ARCH_KEEMBAY + bool "Keem Bay SoC" + help + This enables support for Intel Movidius SoC code-named Keem Bay. + config ARCH_MEDIATEK bool "MediaTek SoC Family" select ARM_GIC -- 2.26.2
