- 14 2月, 2018 4 次提交
-
-
由 Gregory CLEMENT 提交于
Follow the recent trend for the license description, and also fix the wrongly stated X11 to MIT. As already pointed on the DT ML, the X11 license text [1] is explicitly for the X Consortium and has a couple of extra clauses. The MIT license text [2] is actually what the current DT files claim. [1] https://spdx.org/licenses/X11.html [2] https://spdx.org/licenses/MIT.htmlSigned-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
-
由 Baruch Siach 提交于
The CP110 component has 4 uart peripherals. All of them use the same clock gate for slow peripherals that is shared with the i2c and spi peripherals. Signed-off-by: NBaruch Siach <baruch@tkos.co.il> Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
-
由 Gregory CLEMENT 提交于
This extra clock is needed to access the registers of the I2C controller used on the Armada 7K/8K SoCs. This follows the changes already made in the binding documentation (as well as in the driver) in: commit 1534156e ("i2c: mv64xxx: Fix clock resource by adding an optional bus clock") Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
-
由 Gregory CLEMENT 提交于
This extra clock is needed to access the registers of the SPI controller used on Armada 7K/8K SoCs. This follows the changes already made in the binding documentation (as well as in the driver) in: 'commit 92ae112e ("spi: orion: Fix clock resource by adding an optional bus clock")'. Signed-off-by: NGregory CLEMENT <gregory.clement@bootlin.com>
-
- 06 1月, 2018 1 次提交
-
-
由 Thomas Petazzoni 提交于
One concept of Marvell Armada 7K/8K SoCs is that they are made of HW blocks composed of a variety of IPs (network, PCIe, SATA, XOR, SPI, I2C, etc.), and those HW blocks can be duplicated several times within a given SoC. The Armada 7K SoC has a single CP110 (so no duplication), while the Armada 8K SoC has two CP110. In the future, SoCs with more than 2 CP110s will be introduced. In current kernel versions, the master CP110 is described in armada-cp110-master.dtsi and the slave CP110 is described in armada-cp110-slave.dtsi. Those files are basically exactly the same, since they describe the same hardware. They only have a few differences: - Base address of the registers is different for the "config-space" - Base address of the PCIe registers, MEM, CONF and IO areas were different - Labels (and phandles pointing to them) of the nodes were different ("cpm" prefix in the master CP, "cps" prefix in the slave CP) This duplication issue has been discussed at the DT workshop [1] in Prague last October, and we presented on this topic [2]. The solution of using the C pre-processor to avoid this duplication has been validated by the people present in this DT workshop, and this patch simply implements what has been presented. We handle differences between the master CP and slave CP description using the C pre-processor, by defining a set of macros with different values armada-cp110.dtsi is included to instantiate one of the master or slave CP110. There are a few aspects that deserve additional explanations: - PCIe needs to be handled separately because it is not part of the config-space {...} node, since it has registers outside of the range covered by config-space {...}. - We need to defined CP110_BASE, CP110_PCIEx_BASE without 0x, because they are used for the unit address part of some DT nodes. But since they are also used for the "reg" property of the same nodes, we have an ADDRESSIFY() macro that prepends 0x to those values. We compared the resulting .dtb for armada-8040-db.dtb before and after this patch is applied, and the result is exactly the same, except for a few differences: - the SDHCI controller that was only described in the master CP110 is now also described in the slave CP110. Even though the SDHCI controller from the slave CP110 is indeed not usable (as it isn't wired to the outside world) it is technically part of the silicon, and therefore it is reasonable to also describe it to be part of the slave CP110. In addition, if we wanted to get this correct for the SDHCI controller, we should also do it for the NAND controller, for which the situation is even more complicated: in a single CP110 configuration (Armada 7K), the usable NAND controller is in the master CP110, while in a dual CP110 configuration (Armada 8K), the usable NAND controller is in the slave CP110. Since that would add a lot of additional complexity for no good reason, and since the IP blocks are in fact really present in both CPs, we simply describe them in both CPs at the DT level. - the cp110-master and cp110-slave nodes are now named cpm and cps. We could have kept cp110-master and cp110-slave, but that would have required adding another CP110_xyz define, which didn't seem very useful. Note that this commit also gets rid of the armada-cp110-master.dtsi and armada-cp110-slave.dtsi files, as future SoCs will have more than 2 CPs. Instead, we instantiate the CPs directly from the SoC-specific .dtsi files, i.e armada-70x0.dtsi and armada-80x0.dtsi. [1] https://elinux.org/Device_tree_kernel_summit_2017_etherpad [2] https://elinux.org/images/1/14/DTWorkshop2017-duplicate-data.pdf [gregory.clement@free-electrons.com: add back the "ARM64: dts: marvell: Fix clock resources for various node" commit] Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
-