Re: [PATCH] of/platform: export of_default_bus_match_table
Hi Arnd,
2016-01-05 19:13 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
> On Tuesday 05 January 2016 11:17:53 Masahiro Yamada wrote:
>> Currently, drivers/bus/uniphier-system-bus.c is kept from being a
>> module due to the unresolved reference to of_default_bus_match_table.
>>
>> Refer to commit 326ea45aa827 ("bus: uniphier: allow only built-in
>> driver").
>>
>> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
>> ---
>>
>> drivers/of/platform.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>> index af98343..8d103e4 100644
>> --- a/drivers/of/platform.c
>> +++ b/drivers/of/platform.c
>> @@ -31,6 +31,7 @@ const struct of_device_id of_default_bus_match_table[] = {
>> #endif /* CONFIG_ARM_AMBA */
>> {} /* Empty terminated list */
>> };
>> +EXPORT_SYMBOL(of_default_bus_match_table);
>
> I wonder if the uniphier bus should actually use the default
> match table at all. Sorry for not having thought of that when
> I did my patch.
>
> What kinds of devices do you see below this bus? Do you have multiple
> levels of devices? Are they all platform devices or could they
> be AMBA?
This bus is used to connect external (on-board) devices with the SoC.
So, no possibility for AMBA, but
I want "simple-bus" for grouping some device nodes.
Also, "simple-mfd" would be useful because an external device could be an MFD.
Please see arch/arm/boot/dts/uniphier-support-card.dtsi
It describes an add-on card (expansion board)
which has ETHER, UART, etc. on it.
I implemented it as "simple-bus".
This card is connected to the chip select 1
of the UniPhier System Bus.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of/platform: export of_default_bus_match_table
Currently, drivers/bus/uniphier-system-bus.c is kept from being a
module due to the unresolved reference to of_default_bus_match_table.
Refer to commit 326ea45aa827 ("bus: uniphier: allow only built-in
driver").
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
drivers/of/platform.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index af98343..8d103e4 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -31,6 +31,7 @@ const struct of_device_id of_default_bus_match_table[] = {
#endif /* CONFIG_ARM_AMBA */
{} /* Empty terminated list */
};
+EXPORT_SYMBOL(of_default_bus_match_table);
static int of_dev_node_match(struct device *dev, void *data)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: uniphier: fix a typo in comment block
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
index c6499ee..5321152 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
@@ -53,7 +53,7 @@
compatible = "socionext,ph1-ld6b";
};
-/* UART3 unavilable: the pads are not wired to the package balls */
+/* UART3 unavailable: the pads are not wired to the package balls */
{
status = "disabled";
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] arm,arm64: uniphier: add a new driver, device tree updates
Hi Arnd,
Sorry for confusing you.
2015-12-12 9:12 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
> On Tuesday 24 November 2015 18:39:18 Masahiro Yamada wrote:
>>
>> Here is another series for UniPhier SoC family:
>>
>> - 1/4: add a new driver. The UniPhier System Bus is an external bus
>> where on-board devices are connected to the SoC.
>> (please check if the binding specification is OK.)
>>
>> - 2/4: device tree updates to use the driver added by 1/4
>>
>> - 3/4: trivial rename of device node names
>>
>> - 4/4: initial commit for ARMv8 SoC/Board device trees
>>
>> Please apply 2/4, 3/4/, 4/4 into the same branch because 4/4 depends on 2/4
>> and 3/4.
>> (4/4 creates symbolic links to ARM device trees.)
>
> I'm a bit confused how this relates to the newer version ("[PATCH v5] bus:
> uniphier-system-bus: add UniPhier System Bus driver"). The new version
> only has one patch instead of four, so I'm not sure if the patches 2, 3
> and 4 of this series still apply.
>
> Can you clarify, or send the entire series again?
>
> Arnd
I'd like to retract this series.
Please just disregard it.
Instead, please review this one:
https://patchwork.kernel.org/patch/7714151/
Thanks!
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is an external that connects on-board devices
to the UniPhier SoC. Each bank (chip select) is dynamically mapped
to the CPU-viewed address base via the bus controller. The bus
controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the dynamic
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Acked-by: Rob Herring <r...@kernel.org>
---
Changes in v3:
- Minor fix of git-log
- Add Rob's Acked-by
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 65 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 283 +
5 files changed, 358 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..5ec47c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,65 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the address translation from the
+the System Bus to the parent bus. The needed setup includes the base address,
+the size, and some timing parameters of each bank.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ ethernet@1,01f0 {
+ compatible = "smsc,lan9115";
+ reg = <1 0x01f0 0x1000>;
+ interrupts = <0 48 4>
+ phy-mode = "mii";
+ };
+
+ uart@5,0020 {
+ compatible = "ns1655
[PATCH v2] of/address: replace printk() with pr_debug() / pr_err()
Trivial changes suggested by checkpatch.pl.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v2:
- Fix printk(KERN_DEBUG ...) too
drivers/of/address.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 9582c57..65fafbb 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -23,7 +23,7 @@ static int __of_address_to_resource(struct device_node *dev,
#ifdef DEBUG
static void of_dump_addr(const char *s, const __be32 *addr, int na)
{
- printk(KERN_DEBUG "%s", s);
+ pr_debug("%s", s);
while (na--)
printk(" %08x", be32_to_cpu(*(addr++)));
printk("\n");
@@ -597,7 +597,7 @@ static u64 __of_translate_address(struct device_node *dev,
pbus = of_match_bus(parent);
pbus->count_cells(dev, , );
if (!OF_CHECK_COUNTS(pna, pns)) {
- printk(KERN_ERR "prom_parse: Bad cell count for %s\n",
+ pr_err("prom_parse: Bad cell count for %s\n",
of_node_full_name(dev));
break;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of/address: replace printk(KERN_ERR ...) with pr_err(...)
Hi Rob, 2015-12-07 5:40 GMT+09:00 Rob Herring <robh...@kernel.org>: > On Mon, Nov 30, 2015 at 12:14 AM, Masahiro Yamada > <yamada.masah...@socionext.com> wrote: >> A trivial change suggested by checkpatch.pl. > > You might as well all levels while you are at it. Looks like that is > only one more: > > drivers/of/address.c: printk(KERN_DEBUG "%s", s); > OK, I have just posted v2. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is an external bus that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the dynamic
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Arnd Bergmann <a...@arndb.de>
---
Changes in v4:
- Simplify uniphier_system_bus_check_overlap() function
by not using the sort library
- Add some comments to uniphier_system_bus_check_boot_swap()
for clarification
- Add Arnd's Acked-by
Changes in v3:
- Minor fix of git-log
- Add Rob's Acked-by
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 66 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 281 +
5 files changed, 357 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..68ef80a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,66 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the translation from the offset
+within each bank to the CPU-viewed address. The needed setup includes the base
+address, the size of each bank. Optionally, some timing parameters can be
+optimized for faster bus access.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ ethernet@1,01f0 {
+ comp
[PATCH v5] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is an external bus that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the dynamic
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Acked-by: Rob Herring <r...@kernel.org>
Acked-by: Arnd Bergmann <a...@arndb.de>
---
Changes in v5:
- Fix the conflict in MAINTAINERS
Changes in v4:
- Simplify uniphier_system_bus_check_overlap() function
by not using the sort library
- Add some comments to uniphier_system_bus_check_boot_swap()
for clarification
- Add Arnd's Acked-by
Changes in v3:
- Minor fix of git-log
- Add Rob's Acked-by
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 66 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 281 +
5 files changed, 357 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..68ef80a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,66 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the translation from the offset
+within each bank to the CPU-viewed address. The needed setup includes the base
+address, the size of each bank. Optionally, some timing parameters can be
+optimized for faster bus access.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ eth
Re: [PATCH v3] bus: uniphier-system-bus: add UniPhier System Bus driver
Hi Arnd,
2015-12-09 1:59 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
>
> Just a little thought about one thing I found odd:
>
>> +static int uniphier_system_bus_check_overlap(
>> + struct uniphier_system_bus_priv tmp)
>> +{
>
> Did you intentionally pass this by value?
Yes, I did not want to disturb the original one.
It is copied to a temporary storage, and sorted by the base address,
and discarded after the overlap checking.
But, you are right. It is possible (and simpler)
to check the region overlap without sorting.
> Maybe do it explicitly using a pointer
> and memcpy to a local variable, which has a similar effect. Alternatively
> just check each newly probed child node for conflicts with any of the
> previous children. That is slightly more expensive at O(n^2) instead of O(n)
> but n is always small here and you can avoid sorting first.
Good idea. I simplified this function in v4.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] bus: uniphier-system-bus: add UniPhier System Bus driver
The UniPhier System Bus is a simple external that connects on-board
devices to the UniPhier SoC. Each bank (chip select) is dynamically
mapped to the CPU-viewed address base via the bus controller. The
bus controller must be configured before any access to the bus.
This driver parses the "ranges" property of the System Bus node and
initialized the bus controller. After the bus becomes ready, devices
below it are populated.
Note:
Each bank can be mapped anywhere in the supported address space;
there is nothing preventing us from assigning bank 0 on 0x4200,
0x4300, or anywhere as long as such region is not used by others.
So, the "ranges" is just one possible software configuration, which
does not seem to fit in device tree because device tree is a hardware
description language. However, of_translate_address() requires
"ranges" in every bus node between CPUs and device mapped on the CPU
address space. In other words, "ranges" properties must be statically
defined in device tree. After some discussion, I decided the self
address reassignment by the driver is too bothersome. Instead, the
device tree should provide a reasonable translation setup that the OS
can rely on.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v2:
- Re-design the binding, driver implementation
Switch to a single node, populate children after the bus is setup
.../bindings/bus/uniphier-system-bus.txt | 65 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 8 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 283 +
5 files changed, 358 insertions(+)
create mode 100644
Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git a/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
new file mode 100644
index 000..5ec47c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/uniphier-system-bus.txt
@@ -0,0 +1,65 @@
+UniPhier System Bus
+
+The UniPhier System Bus is an external bus that connects on-board devices to
+the UniPhier SoC. It is a simple (semi-)parallel bus with address, data, and
+some control signals. It supports up to 8 banks (chip selects).
+
+Before any access to the bus, the bus controller must be configured; the bus
+controller registers provide the control for the address translation from the
+the System Bus to the parent bus. The needed setup includes the base address,
+the size, and some timing parameters of each bank.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-bus".
+- reg: offset and length of the register set for the bus controller device.
+- #address-cells: should be 2. The first cell is the bank number (chip
select).
+ The second cell is the address offset within the bank.
+- #size-cells: should be 1.
+- ranges: should provide a proper address translation from the System Bus to
+ the parent bus.
+
+Note:
+The address region(s) that can be assigned for the System Bus is implementation
+defined. Some SoCs can use 0x-0x0fff and 0x4000-0x4fff,
+while other SoCs can only use 0x4000-0x4fff. There might be additional
+limitations depending on SoCs and the boot mode. The address translation is
+arbitrary as long as the banks are assigned in the supported address space with
+the required alignment and they do not overlap one another.
+For example, it is possible to map:
+ bank 0 to 0x4200-0x43ff, bank 5 to 0x4600-0x46ff
+It is also possible to map:
+ bank 0 to 0x4800-0x49ff, bank 5 to 0x4400-0x44ff
+There is no reason to stick to a particular translation mapping, but the
+"ranges" property should provide a "reasonable" default that is known to work.
+The software should initialize the bus controller according to it.
+
+Example:
+
+ system-bus {
+ compatible = "socionext,uniphier-system-bus";
+ reg = <0x58c0 0x400>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4600 0x0100>;
+
+ ethernet@1,01f0 {
+ compatible = "smsc,lan9115";
+ reg = <1 0x01f0 0x1000>;
+ interrupts = <0 48 4>
+ phy-mode = "mii";
+ };
+
+ uart@5,0020 {
+ compatible = "ns16550a";
+ reg = <5 0x0020 0x20>;
+ interrupts = <0 49 4>
+
Re: [Question] DT-Bindings for run-time configurable bus?
Hi Arnd,
2015-12-01 20:29 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
> On Tuesday 01 December 2015 13:30:25 Masahiro Yamada wrote:
>> Hello experts,
>>
>> I am tackling on a new bus driver, but I am worndering
>> what the DT-binding specification should be.
>>
>> Here is my hardware situation:
>>
>> My SoC has an external bus (it is called UniPhier System Bus).
>> This is a simple parallel bus with address, data,
>> chip-selects, and some other control signals.
>> It supports up to 8 chip-selects.
>>
>> Each CS address space can be mapped onto the CPU view,
>> and it must be configured run-time via the bus controller registers.
>>
>> Let's assume this situation:
>>
>> - An ethernet device is connected at the offset address 0x01f0 of CS1
>> - A UART device is connected at the offset address 0x0020 of CS5
>>
>>
>> A quick draft of device tree would be as follows:
>>
>>
>> amba {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges;
>>
>> extbus {
>>compatible = "socionext,uniphier-system-bus";
>>reg = <0x58c0 0x400>; /* registers of bus controller */
>>#address-cells = <2>;
>>#size-cells = <1>;
>>
>>ethernet@1,01f0 {
>> compatible = "smsc,lan9115";
>> reg = <1 0x01f0 0x1000>;
>> interrupts = <0 48 4>
>> phy-mode = "mii";
>>};
>>
>>uart@5,0020 {
>> compatible = "ns16550a";
>> reg = <5 0x0020 0x20>;
>> interrupts = <0 49 4>
>> clock-frequency = <12288000>;
>>};
>> };
>> };
>>
>
> That looks reasonable.
>
>> Please note "ranges" property is missing from the extbus node.
>>
>> As mentioned above, the address translation from the external bus
>> to the parent bus is run-time configurable.
>>
>>
>> It is possible to map
>> CS1 of extbus to 0x4000-0x41ff of CPU view
>> CS5 of extbus to 0x4200-0x43ff of CPU view
>>
>> It is also possible to map
>> CS1 of extbus to 0x4600-0x47ff of CPU view
>> CS5 of extbus to 0x4400-0x45ff of CPU view
>>
>> There is nothing preventing us from a particular
>> address mapping.
>> It is completely up to the software (driver)
>> to choose one mapping from another.
>
> Ok.
>
>> And I notice a conflict between the followings.
>>
>> [1] Device Tree is a hardware description language.
>> It should not describe the software configuration.
>>
>> So, ranges such as
>>ranges = <1 0 0x4000 0x0200
>> 5 0 0x4200 0x0200>;
>>
>>or
>>
>>ranges = <1 0 0x4600 0x0200
>> 5 0 0x4400 0x0200>;
>>
>> are configuration information, which should not be
>> included in the device tree.
>>
>> Any address mapping is OK as long as no region overlap occurs.
>> No point to specify "ranges" from the device tree.
>>
>>
>> [2] of_translate_address() expects "ranges" in every bus node
>>
>> When we need to translate the "reg" property into the CPU-viewed address,
>> we call of_translate_address(). It translates addresses,
>> parsing "ranges" property when crossing buses.
>> It potentially means, "ranges" properties are statically defined
>> in the device tree.
>>
>>
>> I have not been able to find a good way
>> to solve the conflict between [1] and [2].
>>
>>
>> To sum up, what I want is:
>>
>> - Let the driver to configure the address translation on run-time
>> - Once the bus is configured, I want the sub nodes to be accessed
>>from the CPU, like the other statically instantiated devices.
>>
>>
>> Any comment is welcome!
>>
>>
>> BTW, perhaps Marvell Mbus has a similar situation (run-time configurable)?
>> (Documentation/devicetree/bindings/bus/mvebu-mbus.txt)
>> I am not familiar with such SoCs, though.
>
> Yes, this is the example I was thinking of. For mbus, we decided that
> doing the full dynamic reassignment of addresses is too bothersome
> for the OS, so the D
[PATCH 2/2] ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi
UniPhier SoCs (except PH1-sLD3) have several nodes in common.
Factor out them into uniphier-common32.dtsi. This improves the code
maintainability.
PH1-sLD3 is so old that it has more or less different register maps
than the others. So, it cannot be included in this refactoring.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-common32.dtsi| 135 +
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 265 +
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 288 ++--
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 274 +-
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 266 +
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 269 +-
6 files changed, 605 insertions(+), 892 deletions(-)
create mode 100644 arch/arm/boot/dts/uniphier-common32.dtsi
diff --git a/arch/arm/boot/dts/uniphier-common32.dtsi
b/arch/arm/boot/dts/uniphier-common32.dtsi
new file mode 100644
index 000..ea9301a
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-common32.dtsi
@@ -0,0 +1,135 @@
+/*
+ * Device Tree Source commonly used by UniPhier ARM SoCs
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ soc: soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ interrupt-parent = <>;
+
+ extbus: extbus {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ };
+
+ serial0: serial@54006800 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006800 0x40>;
+ interrupts = <0 33 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart0>;
+ clocks = <_clk>;
+ };
+
+ serial1: serial@54006900 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006900 0x40>;
+ interrupts = <0 35 4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_uart1>;
+ clocks = <_clk>;
+ };
+
+ serial2: serial@54006a00 {
+ compatible = "socionext,uniphier-uart";
+ status = "disabled";
+ reg = <0x54006a00 0x40>;
+ interrupts = <0 37 4>;
+
[PATCH 0/2] ARM: dts: uniphier: clean up DTSIs by factoring the common parts out
Masahiro Yamada (2): ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC ARM: dts: uniphier: factor out common nodes to uniphier-common32.dtsi arch/arm/boot/dts/uniphier-common32.dtsi| 135 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 265 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 288 ++-- arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 274 +- arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 266 + arch/arm/boot/dts/uniphier-proxstream2.dtsi | 269 +- 6 files changed, 605 insertions(+), 892 deletions(-) create mode 100644 arch/arm/boot/dts/uniphier-common32.dtsi -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: uniphier: change IRQ number of UART3 of PH1-Pro4 SoC
The UART3 is assigned with IRQ 29 for old SoCs, IRQ 177 for new ones, and PH1-Pro4 is on the boundary. PH1-sLD3: UART3 is unavailable PH1-LD4, PH1-sLD8: only IRQ 29 is supported PH1-Pro4: both IRQ 29 and 177 are supported PH1-Pro5, ProXstream2, PH1-LD6b: only IRQ 177 is supported This SoC can choose either IRQ 29 or IRQ 177, but the former is shared with another hardware (low speed serial0). The latter is dedicated for this hardware and more recommended. Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi index 254642f..bbf3727 100644 --- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi +++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi @@ -151,7 +151,7 @@ reg = <0x54006b00 0x40>; pinctrl-names = "default"; pinctrl-0 = <_uart3>; - interrupts = <0 29 4>; + interrupts = <0 177 4>; clocks = <_clk>; fifo-size = <64>; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Question] DT-Bindings for run-time configurable bus?
Hello experts,
I am tackling on a new bus driver, but I am worndering
what the DT-binding specification should be.
Here is my hardware situation:
My SoC has an external bus (it is called UniPhier System Bus).
This is a simple parallel bus with address, data,
chip-selects, and some other control signals.
It supports up to 8 chip-selects.
Each CS address space can be mapped onto the CPU view,
and it must be configured run-time via the bus controller registers.
Let's assume this situation:
- An ethernet device is connected at the offset address 0x01f0 of CS1
- A UART device is connected at the offset address 0x0020 of CS5
A quick draft of device tree would be as follows:
amba {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
ranges;
extbus {
compatible = "socionext,uniphier-system-bus";
reg = <0x58c0 0x400>; /* registers of bus controller */
#address-cells = <2>;
#size-cells = <1>;
ethernet@1,01f0 {
compatible = "smsc,lan9115";
reg = <1 0x01f0 0x1000>;
interrupts = <0 48 4>
phy-mode = "mii";
};
uart@5,0020 {
compatible = "ns16550a";
reg = <5 0x0020 0x20>;
interrupts = <0 49 4>
clock-frequency = <12288000>;
};
};
};
Please note "ranges" property is missing from the extbus node.
As mentioned above, the address translation from the external bus
to the parent bus is run-time configurable.
It is possible to map
CS1 of extbus to 0x4000-0x41ff of CPU view
CS5 of extbus to 0x4200-0x43ff of CPU view
It is also possible to map
CS1 of extbus to 0x4600-0x47ff of CPU view
CS5 of extbus to 0x4400-0x45ff of CPU view
There is nothing preventing us from a particular
address mapping.
It is completely up to the software (driver)
to choose one mapping from another.
And I notice a conflict between the followings.
[1] Device Tree is a hardware description language.
It should not describe the software configuration.
So, ranges such as
ranges = <1 0 0x4000 0x0200
5 0 0x4200 0x0200>;
or
ranges = <1 0 0x4600 0x0200
5 0 0x4400 0x0200>;
are configuration information, which should not be
included in the device tree.
Any address mapping is OK as long as no region overlap occurs.
No point to specify "ranges" from the device tree.
[2] of_translate_address() expects "ranges" in every bus node
When we need to translate the "reg" property into the CPU-viewed address,
we call of_translate_address(). It translates addresses,
parsing "ranges" property when crossing buses.
It potentially means, "ranges" properties are statically defined
in the device tree.
I have not been able to find a good way
to solve the conflict between [1] and [2].
To sum up, what I want is:
- Let the driver to configure the address translation on run-time
- Once the bus is configured, I want the sub nodes to be accessed
from the CPU, like the other statically instantiated devices.
Any comment is welcome!
BTW, perhaps Marvell Mbus has a similar situation (run-time configurable)?
(Documentation/devicetree/bindings/bus/mvebu-mbus.txt)
I am not familiar with such SoCs, though.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of/address: fix typo in comment block of of_translate_one()
Remove the "not" before "cannot". I am fixing the comment block style while I am here. Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- drivers/of/address.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/of/address.c b/drivers/of/address.c index 5289c80..91a469d 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -485,9 +485,10 @@ static int of_translate_one(struct device_node *parent, struct of_bus *bus, int rone; u64 offset = OF_BAD_ADDR; - /* Normally, an absence of a "ranges" property means we are + /* +* Normally, an absence of a "ranges" property means we are * crossing a non-translatable boundary, and thus the addresses -* below the current not cannot be converted to CPU physical ones. +* below the current cannot be converted to CPU physical ones. * Unfortunately, while this is very clear in the spec, it's not * what Apple understood, and they do have things like /uni-n or * /ht nodes with no "ranges" property and a lot of perfectly -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of/address: replace printk(KERN_ERR ...) with pr_err(...)
A trivial change suggested by checkpatch.pl.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
drivers/of/address.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index cd53fe4..5289c80 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -596,7 +596,7 @@ static u64 __of_translate_address(struct device_node *dev,
pbus = of_match_bus(parent);
pbus->count_cells(dev, , );
if (!OF_CHECK_COUNTS(pna, pns)) {
- printk(KERN_ERR "prom_parse: Bad cell count for %s\n",
+ pr_err("prom_parse: Bad cell count for %s\n",
of_node_full_name(dev));
break;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] arm64: dts: uniphier: add PH1-LD10 SoC/board support
This is the first ARMv8 SoC from Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v3:
- Fix phandle to cpu nodes in cluster1
Changes in v2:
- Split into a single patch
MAINTAINERS| 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/socionext/Makefile | 4 +
.../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 95 +++
.../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 280 +
.../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi | 1 +
.../boot/dts/socionext/uniphier-support-card.dtsi | 1 +
7 files changed, 383 insertions(+)
create mode 100644 arch/arm64/boot/dts/socionext/Makefile
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi
create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 3f92804..99a1424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
F: arch/arm/mm/cache-uniphier.c
+F: arch/arm64/boot/dts/socionext/
F: drivers/i2c/busses/i2c-uniphier*
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index eb3c42d..6672a96 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -11,6 +11,7 @@ dts-dirs += marvell
dts-dirs += mediatek
dts-dirs += qcom
dts-dirs += rockchip
+dts-dirs += socionext
dts-dirs += sprd
dts-dirs += xilinx
diff --git a/arch/arm64/boot/dts/socionext/Makefile
b/arch/arm64/boot/dts/socionext/Makefile
new file mode 100644
index 000..8d72771
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -0,0 +1,4 @@
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+
+always := $(dtb-y)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
new file mode 100644
index 000..3e53317
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
@@ -0,0 +1,95 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-support-card.dtsi"
+
+/ {
+ model = "UniPhier PH1-LD10 Reference Board";
+ compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000 0 0xc000>;
+ };
Re: [PATCH v2] arm64: dts: uniphier: add PH1-LD10 SoC/board support
I found a bug in the DTSI. I will send v3. 2015-11-26 11:33 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>: > This is the first ARMv8 SoC from Socionext Inc. > > Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> > --- > > Changes in v2: > - Split into a single patch > > MAINTAINERS| 1 + > arch/arm64/boot/dts/Makefile | 1 + > arch/arm64/boot/dts/socionext/Makefile | 4 + > .../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 95 +++ > .../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 280 > + > .../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi | 1 + > .../boot/dts/socionext/uniphier-support-card.dtsi | 1 + > 7 files changed, 383 insertions(+) > create mode 100644 arch/arm64/boot/dts/socionext/Makefile > create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts > create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi > create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi > create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi > > diff --git a/MAINTAINERS b/MAINTAINERS > index 3f92804..99a1424 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier* > F: arch/arm/include/asm/hardware/cache-uniphier.h > F: arch/arm/mach-uniphier/ > F: arch/arm/mm/cache-uniphier.c > +F: arch/arm64/boot/dts/socionext/ > F: drivers/i2c/busses/i2c-uniphier* > F: drivers/pinctrl/uniphier/ > F: drivers/tty/serial/8250/8250_uniphier.c > diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile > index eb3c42d..6672a96 100644 > --- a/arch/arm64/boot/dts/Makefile > +++ b/arch/arm64/boot/dts/Makefile > @@ -11,6 +11,7 @@ dts-dirs += marvell > dts-dirs += mediatek > dts-dirs += qcom > dts-dirs += rockchip > +dts-dirs += socionext > dts-dirs += sprd > dts-dirs += xilinx > > diff --git a/arch/arm64/boot/dts/socionext/Makefile > b/arch/arm64/boot/dts/socionext/Makefile > new file mode 100644 > index 000..8d72771 > --- /dev/null > +++ b/arch/arm64/boot/dts/socionext/Makefile > @@ -0,0 +1,4 @@ > +dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb > + > +always := $(dtb-y) > +clean-files:= *.dtb > diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts > b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts > new file mode 100644 > index 000..3e53317 > --- /dev/null > +++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts > @@ -0,0 +1,95 @@ > +/* > + * Device Tree Source for UniPhier PH1-LD10 Reference Board > + * > + * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com> > + * > + * This file is dual-licensed: you can use it either under the terms > + * of the GPL or the X11 license, at your option. Note that this dual > + * licensing only applies to this file, and not this project as a > + * whole. > + * > + * a) This file is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of the > + * License, or (at your option) any later version. > + * > + * This file is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * Or, alternatively, > + * > + * b) Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, > + * copy, modify, merge, publish, distribute, sublicense, and/or > + * sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following > + * conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, &g
Re: [PATCH 0/4] arm, arm64: uniphier: add a new driver, device tree updates
2015-11-24 18:39 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>: > Hi Arnd, Olof, > > Here is another series for UniPhier SoC family: > > - 1/4: add a new driver. The UniPhier System Bus is an external bus > where on-board devices are connected to the SoC. > (please check if the binding specification is OK.) > > - 2/4: device tree updates to use the driver added by 1/4 > > - 3/4: trivial rename of device node names > > - 4/4: initial commit for ARMv8 SoC/Board device trees > > Please apply 2/4, 3/4/, 4/4 into the same branch because 4/4 depends on 2/4 > and 3/4. > (4/4 creates symbolic links to ARM device trees.) It looks like 1/4 will take longer, so want to postpone it for now. I will resend 4/4 as a single patch. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] arm64: dts: uniphier: add PH1-LD10 SoC/board support
This is the first ARMv8 SoC from Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v2:
- Split into a single patch
MAINTAINERS| 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/socionext/Makefile | 4 +
.../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 95 +++
.../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 280 +
.../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi | 1 +
.../boot/dts/socionext/uniphier-support-card.dtsi | 1 +
7 files changed, 383 insertions(+)
create mode 100644 arch/arm64/boot/dts/socionext/Makefile
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi
create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index 3f92804..99a1424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
F: arch/arm/mm/cache-uniphier.c
+F: arch/arm64/boot/dts/socionext/
F: drivers/i2c/busses/i2c-uniphier*
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index eb3c42d..6672a96 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -11,6 +11,7 @@ dts-dirs += marvell
dts-dirs += mediatek
dts-dirs += qcom
dts-dirs += rockchip
+dts-dirs += socionext
dts-dirs += sprd
dts-dirs += xilinx
diff --git a/arch/arm64/boot/dts/socionext/Makefile
b/arch/arm64/boot/dts/socionext/Makefile
new file mode 100644
index 000..8d72771
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -0,0 +1,4 @@
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+
+always := $(dtb-y)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
new file mode 100644
index 000..3e53317
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
@@ -0,0 +1,95 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-support-card.dtsi"
+
+/ {
+ model = "UniPhier PH1-LD10 Reference Board";
+ compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000 0 0xc000>;
+ };
+
+ chosen {
+ stdout-path = &qu
Re: [PATCH 1/4] bus: uniphier-system-bus: add UniPhier System Bus Controller driver
Hi Mark,
2015-11-25 2:38 GMT+09:00 Mark Rutland <mark.rutl...@arm.com>:
> Hi,
>
>> >> +UniPhier System Bus Controller
>> >> +--
>> >> +
>> >> +The UniPhier System Bus Controller is a hardware block with registers
>> >> that
>> >> +controls the System Bus accessing; how each bank is mapped onto the
>> >> parent bus,
>> >> +various timing parameters of the bus access, etc.
>> >> +
>> >> +Required properties for System Bus Controller:
>> >> +- compatible: should be "socionext,uniphier-system-bus-controller".
>> >> +- reg: offsets and lengths of the register sets for the device. It
>> >> should
>> >> + contain 2 regions: base & control register, misc register, in this
>> >> order.
>> >
>> > The example also has a system-bus phandle.
>>
>> Actually, I was wondering which is better to describe the relation between
>> the bus and the controller, phandle or compatible string..
>
> To describe relationships between nodes, use phandles.
>
> Compatible strings alone cannot define relationships -- you cannot
> encode how multiple instances are related.
>
>> > Is the "misc register" part of the bus controller, or is it a shared
>> > system controller?
>>
>> It is a part of the bus controller, but used for another purpose.
>> (i.e. partly this is syscon. I know this is strange, but it is
>> what the hardware developers designed.)
>
> Ok. What else is going to need to use this in future?
>
>> > Assuming that the controller and bus are 1-1 related, make this a single
>> > node. e.g.
>> >
>> > system-bus {
>> > compatible = "socionext,uniphier-system-bus";
>> > reg = <0x58c0 0x400>, <0x5980 0x2000>;
>> > #address-cells = <2>;
>> > #size-cells = <1>;
>> > ranges = <1 0x 0x4200 0x0200>,
>> > <5 0x 0x4800 0x0100>;
>> >
>> > ...
>> > child nodes here
>> > ...
>> >
>> > };
>>
>> Hmm, make sense. But, I prefer to reflect the hardware structure.
>>
>> The range of System Bus is <0x4000 0x1000>.
>>
>> The register of the System Bus Controller is
>> <0x58c0 0x400> (and <0x5980 0x2000>)
>>
>>
>> The bus and its controller is different.
>
> So? We always describe the programming interface (i.e. the slave
> interface of the device that responds to the CPU).
>
> There's no need for separate nodes. It only makes the driver more
> complicated.
>
>> >> +static int uniphier_sbc_probe(struct platform_device *pdev)
>> >> +{
>> >> + struct device *dev = >dev;
>> >> + struct uniphier_sbc_priv *priv;
>> >> + struct resource *regs;
>> >> + struct device_node *bus_np;
>> >> + int child_addrc, addrc, sizec, bank;
>> >> + u64 child_addr, addr, size;
>> >> + const __be32 *ranges;
>> >> + int rlen, rone, ret;
>> >> +
>> >> + bus_np = of_find_compatible_node(NULL, NULL,
>> >> + "socionext,uniphier-system-bus");
>> >
>> > This is broken if you ever have multiple instances.
>> >
>> > Either use a single node, or if there is a more complex relationship
>> > between busses and their controllers, describe that explicitly with
>> > phandles.
>>
>>
>> Probably, I will stick to phandle in v2.
>
> I would prefer a single node unless there's some other complication
> regarding the relationship of the controller and the bus itself.
OK, i will try the single node way.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] bus: uniphier-system-bus: add UniPhier System Bus Controller driver
Hi Mark,
2015-11-24 20:50 GMT+09:00 Mark Rutland <mark.rutl...@arm.com>:
> On Tue, Nov 24, 2015 at 06:39:19PM +0900, Masahiro Yamada wrote:
>> The UniPhier System Bus is an external bus where on-board devices are
>> connected to the UniPhier SoC. This driver parses the "ranges"
>> property of the System Bus and set up the registers of the System Bus
>> Controller for the correct bus routing.
>
> Could you elaborate on why you need to do that?
In order to have access to the System Bus (external bus),
the System Bus Controller must be set up.
> What needs to be configured specifically?
The base address and the size of each bank (each chip select)
must be set to the registers of the controller.
> [...]
>
>> +The UniPhier System Bus is an external bus where on-board devices are
>> connected
>> +to the UniPhier SoC. It it a simple parallel bus with address, data, and
>> some
>> +control signals. It supports up to 8 banks (chip selects).
>> +
>> +Required properties for System Bus:
>> +- compatible: should be "socionext,uniphier-system-bus", "simple-bus".
>
> If the kernel has to perform setup of the bus, then it is not a
> "simple-bus".
>
> Configure the bus, then probe children. Don't use simple-bus jsut to get
> probing.
OK, I will fix in v2.
>> +- #address-cells: should be equal to or grater than 2. The first cell is
>> the
>
> s/grater/greater/
OK, thanks.
>> + bank number (chip select). The rest is the base address within the bank
>> that
>> + should be mapped onto the parent bus (usually AMBA).
>> +
>> +Optional properties for System Bus:
>> +- #size-cells: should be the same as that of the parent bus, if exists. The
>> + value of the parent bus is assumed, if not specified.
>
> This should be just as required as #address-cells, for consistency.
Will fix.
>> +
>> +
>> +UniPhier System Bus Controller
>> +--
>> +
>> +The UniPhier System Bus Controller is a hardware block with registers that
>> +controls the System Bus accessing; how each bank is mapped onto the parent
>> bus,
>> +various timing parameters of the bus access, etc.
>> +
>> +Required properties for System Bus Controller:
>> +- compatible: should be "socionext,uniphier-system-bus-controller".
>> +- reg: offsets and lengths of the register sets for the device. It should
>> + contain 2 regions: base & control register, misc register, in this order.
>
> The example also has a system-bus phandle.
Actually, I was wondering which is better to describe the relation between
the bus and the controller, phandle or compatible string..
> Is the "misc register" part of the bus controller, or is it a shared
> system controller?
It is a part of the bus controller, but used for another purpose.
(i.e. partly this is syscon. I know this is strange, but it is
what the hardware developers designed.)
>> +Example
>> +---
>> + system_bus: system-bus {
>> + compatible = "socionext,uniphier-system-bus", "simple-bus";
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + ranges = <1 0x 0x4200 0x0200
>> + 5 0x 0x4800 0x0100>;
>> +
>> + eth: ethernet@1,01f0 {
>> + compatible = "smsc,lan9115";
>> + reg = <1 0x01f0 0x1000>;
>> + phy-mode = "mii";
>> + reg-io-width = <4>;
>> + };
>> +
>> + serial: uart@5,0020 {
>> + compatible = "ns16550a";
>> + reg = <5 0x0020 0x20>;
>> + clock-frequency = <12288000>;
>> + reg-shift = <1>;
>> + };
>> + };
>> +
>> + system-bus-controller@58c0 {
>> + compatible = "socionext,uniphier-system-bus-controller";
>> + reg = <0x58c0 0x400>, <0x5980 0x2000>;
>> + system-bus = <_bus>;
>> + };
>
> Assuming that the controller and bus are 1-1 related, make this a single
> node. e.g.
>
> system-bus {
> compatible = "socionext,uniphier-system-bus";
> reg = <0x58c0 0x400>, <0x5980 0x2000>;
> #address-cells = <2>;
> #size-cells = <1>;
> ranges = <1 0x00
[PATCH 4/4] arm64: dts: uniphier: add PH1-LD10 SoC/board support
This is the first ARMv8 SoC from Socionext Inc.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
MAINTAINERS| 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/socionext/Makefile | 4 +
.../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 95 +++
.../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 286 +
.../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi | 1 +
.../boot/dts/socionext/uniphier-support-card.dtsi | 1 +
7 files changed, 389 insertions(+)
create mode 100644 arch/arm64/boot/dts/socionext/Makefile
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi
create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi
create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index e849a38..096b2b0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
F: arch/arm/mm/cache-uniphier.c
+F: arch/arm64/boot/dts/socionext/
F: drivers/bus/uniphier-system-bus.c
F: drivers/i2c/busses/i2c-uniphier*
F: drivers/pinctrl/uniphier/
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index eb3c42d..6672a96 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -11,6 +11,7 @@ dts-dirs += marvell
dts-dirs += mediatek
dts-dirs += qcom
dts-dirs += rockchip
+dts-dirs += socionext
dts-dirs += sprd
dts-dirs += xilinx
diff --git a/arch/arm64/boot/dts/socionext/Makefile
b/arch/arm64/boot/dts/socionext/Makefile
new file mode 100644
index 000..8d72771
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/Makefile
@@ -0,0 +1,4 @@
+dtb-$(CONFIG_ARCH_UNIPHIER) += uniphier-ph1-ld10-ref.dtb
+
+always := $(dtb-y)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
new file mode 100644
index 000..7b36be4
--- /dev/null
+++ b/arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts
@@ -0,0 +1,95 @@
+/*
+ * Device Tree Source for UniPhier PH1-LD10 Reference Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-ph1-ld10.dtsi"
+/include/ "uniphier-support-card.dtsi"
+
+/ {
+ model = "UniPhier PH1-LD10 Reference Board";
+ compatible = "socionext,ph1-ld10-ref", "socionext,ph1-ld10";
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x8000 0 0xc000>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ aliase
[PATCH 0/4] arm,arm64: uniphier: add a new driver, device tree updates
Hi Arnd, Olof, Here is another series for UniPhier SoC family: - 1/4: add a new driver. The UniPhier System Bus is an external bus where on-board devices are connected to the SoC. (please check if the binding specification is OK.) - 2/4: device tree updates to use the driver added by 1/4 - 3/4: trivial rename of device node names - 4/4: initial commit for ARMv8 SoC/Board device trees Please apply 2/4, 3/4/, 4/4 into the same branch because 4/4 depends on 2/4 and 3/4. (4/4 creates symbolic links to ARM device trees.) Masahiro Yamada (4): bus: uniphier-system-bus: add UniPhier System Bus Controller driver ARM: dts: uniphier: add better-matching compatible string to extbus nodes ARM: dts: uniphier: rename nodes from extbus to system-bus arm64: dts: uniphier: add PH1-LD10 SoC/board support .../bindings/arm/uniphier/uniphier-system-bus.txt | 70 + MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 2 +- arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 5 +- arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts| 2 +- arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts| 2 +- arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 5 +- arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 5 +- arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts| 2 +- arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 5 +- arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts| 2 +- arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 5 +- arch/arm/boot/dts/uniphier-proxstream2.dtsi| 5 +- arch/arm/boot/dts/uniphier-support-card.dtsi | 2 +- arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/socionext/Makefile | 4 + .../boot/dts/socionext/uniphier-ph1-ld10-ref.dts | 95 +++ .../boot/dts/socionext/uniphier-ph1-ld10.dtsi | 286 + .../arm64/boot/dts/socionext/uniphier-pinctrl.dtsi | 1 + .../boot/dts/socionext/uniphier-support-card.dtsi | 1 + drivers/bus/Kconfig| 9 + drivers/bus/Makefile | 1 + drivers/bus/uniphier-system-bus.c | 284 23 files changed, 778 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/uniphier-system-bus.txt create mode 100644 arch/arm64/boot/dts/socionext/Makefile create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10-ref.dts create mode 100644 arch/arm64/boot/dts/socionext/uniphier-ph1-ld10.dtsi create mode 12 arch/arm64/boot/dts/socionext/uniphier-pinctrl.dtsi create mode 12 arch/arm64/boot/dts/socionext/uniphier-support-card.dtsi create mode 100644 drivers/bus/uniphier-system-bus.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: uniphier: add better-matching compatible string to extbus nodes
This is needed to use the UniPhier System Controller driver.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 3 ++-
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 3 ++-
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 3 ++-
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 3 ++-
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 3 ++-
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 3 ++-
6 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index af49381..c2913fe 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -87,7 +87,8 @@
interrupt-parent = <>;
extbus: extbus {
- compatible = "simple-bus";
+ compatible = "socionext,uniphier-system-bus",
+"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 254642f..d110df7 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -95,7 +95,8 @@
interrupt-parent = <>;
extbus: extbus {
- compatible = "simple-bus";
+ compatible = "socionext,uniphier-system-bus",
+"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 11eb762..0f1db60 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -95,7 +95,8 @@
interrupt-parent = <>;
extbus: extbus {
- compatible = "simple-bus";
+ compatible = "socionext,uniphier-system-bus",
+"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 691a17d..888bb2e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -95,7 +95,8 @@
interrupt-parent = <>;
extbus: extbus {
- compatible = "simple-bus";
+ compatible = "socionext,uniphier-system-bus",
+"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index e88559b..b10c4bd 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -87,7 +87,8 @@
interrupt-parent = <>;
extbus: extbus {
- compatible = "simple-bus";
+ compatible = "socionext,uniphier-system-bus",
+"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
};
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index 259f1a9..9186f8c9 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -109,7 +109,8 @@
interrupt-parent = <>;
extbus: extbus {
- compatible = "simple-bus";
+ compatible = "socionext,uniphier-system-bus",
+"simple-bus";
#address-cells = <2>;
#size-cells = <1>;
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] bus: uniphier-system-bus: add UniPhier System Bus Controller driver
The UniPhier System Bus is an external bus where on-board devices are
connected to the UniPhier SoC. This driver parses the "ranges"
property of the System Bus and set up the registers of the System Bus
Controller for the correct bus routing.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
.../bindings/arm/uniphier/uniphier-system-bus.txt | 70 +
MAINTAINERS| 1 +
drivers/bus/Kconfig| 9 +
drivers/bus/Makefile | 1 +
drivers/bus/uniphier-system-bus.c | 284 +
5 files changed, 365 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/uniphier-system-bus.txt
create mode 100644 drivers/bus/uniphier-system-bus.c
diff --git
a/Documentation/devicetree/bindings/arm/uniphier/uniphier-system-bus.txt
b/Documentation/devicetree/bindings/arm/uniphier/uniphier-system-bus.txt
new file mode 100644
index 000..a50db0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/uniphier-system-bus.txt
@@ -0,0 +1,70 @@
+UniPhier System Bus
+---
+
+The UniPhier System Bus is an external bus where on-board devices are connected
+to the UniPhier SoC. It it a simple parallel bus with address, data, and some
+control signals. It supports up to 8 banks (chip selects).
+
+Required properties for System Bus:
+- compatible: should be "socionext,uniphier-system-bus", "simple-bus".
+- #address-cells: should be equal to or grater than 2. The first cell is the
+ bank number (chip select). The rest is the base address within the bank that
+ should be mapped onto the parent bus (usually AMBA).
+
+Optional properties for System Bus:
+- #size-cells: should be the same as that of the parent bus, if exists. The
+ value of the parent bus is assumed, if not specified.
+
+
+UniPhier System Bus Controller
+--
+
+The UniPhier System Bus Controller is a hardware block with registers that
+controls the System Bus accessing; how each bank is mapped onto the parent bus,
+various timing parameters of the bus access, etc.
+
+Required properties for System Bus Controller:
+- compatible: should be "socionext,uniphier-system-bus-controller".
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 2 regions: base & control register, misc register, in this order.
+
+
+Example
+---
+ system_bus: system-bus {
+ compatible = "socionext,uniphier-system-bus", "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <1 0x 0x4200 0x0200
+ 5 0x 0x4800 0x0100>;
+
+ eth: ethernet@1,01f0 {
+ compatible = "smsc,lan9115";
+ reg = <1 0x01f0 0x1000>;
+ phy-mode = "mii";
+ reg-io-width = <4>;
+ };
+
+ serial: uart@5,0020 {
+ compatible = "ns16550a";
+ reg = <5 0x0020 0x20>;
+ clock-frequency = <12288000>;
+ reg-shift = <1>;
+ };
+ };
+
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
+ system-bus = <_bus>;
+ };
+
+In this example, the range 0x-0x0200 of bank 1 (CS1) is mapped to
+the range 0x4200-0x4400 of the parent bus.
+Likewise, the range 0x-0x0100 of bank 5 (CS5) is mapped to the
+range 0x4800-0x4900 of the parent bus.
+
+The Ethernet device is connected at the address 0x01f0 of CS1, and visible
+at the address 0x43f0 in the parent bus. The UART device is connected at
+the address 0x0020 of CS5, and visible at the address 0x4820 in the
+parent bus.
diff --git a/MAINTAINERS b/MAINTAINERS
index 050d0e7..e849a38 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1642,6 +1642,7 @@ F:arch/arm/boot/dts/uniphier*
F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
F: arch/arm/mm/cache-uniphier.c
+F: drivers/bus/uniphier-system-bus.c
F: drivers/i2c/busses/i2c-uniphier*
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 116b363..5a772fc 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -131,6 +131,15 @@ config SUNXI_RSB
with various RSB based devices, such as AXP223, AXP8XX PMICs,
and AC100/AC200 ICs.
+config UNIPHIER_SYSTEM_BUS
+
[PATCH 3/4] ARM: dts: uniphier: rename nodes from extbus to system-bus
The officially documented name for this hardware is System Bus, so
follow that naming. It also corresponds to the compatible string.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 2 +-
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 2 +-
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 2 +-
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 2 +-
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 2 +-
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 2 +-
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 2 +-
arch/arm/boot/dts/uniphier-support-card.dtsi | 2 +-
12 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index f1e9d40..c625b4d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -72,7 +72,7 @@
};
};
- {
+_bus {
ranges = <1 0x 0x4200 0x0200>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index c2913fe..0e2ba55 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -86,7 +86,7 @@
ranges;
interrupt-parent = <>;
- extbus: extbus {
+ system_bus: system-bus {
compatible = "socionext,uniphier-system-bus",
"simple-bus";
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 5baa9fc..3ac89fb 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -74,7 +74,7 @@
};
};
- {
+_bus {
ranges = <1 0x 0x4200 0x0200>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 2462668..0c82353 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -74,7 +74,7 @@
};
};
- {
+_bus {
ranges = <1 0x 0x4200 0x0200>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index d110df7..09f78fa 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -94,7 +94,7 @@
ranges;
interrupt-parent = <>;
- extbus: extbus {
+ system_bus: system-bus {
compatible = "socionext,uniphier-system-bus",
"simple-bus";
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 0f1db60..f5aa24c 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -94,7 +94,7 @@
ranges;
interrupt-parent = <>;
- extbus: extbus {
+ system_bus: system-bus {
compatible = "socionext,uniphier-system-bus",
"simple-bus";
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index b7a03215..29e8123 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -73,7 +73,7 @@
};
};
- {
+_bus {
ranges = <1 0x 0x4200 0x0200>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 888bb2e..d830ea9 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -94,7 +94,7 @@
ranges;
interrupt-parent = <>;
- extbus: extbus {
+ system_bus: system-bus {
compatible = "socionext,uniphier-system-bus",
"simple-bus";
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index fc7250c..eb605d6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -72,7 +72,7 @@
};
};
- {
+_bus {
ranges = <1 0x 0x4200 0x0200>;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dts
[PATCH] dt-bindings: ARM: add arm,cortex-a72 compatible string
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- Documentation/devicetree/bindings/arm/cpus.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 3a07a87..58e240d 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -157,6 +157,7 @@ nodes to be present and contain the properties described below. "arm,cortex-a17" "arm,cortex-a53" "arm,cortex-a57" + "arm,cortex-a72" "arm,cortex-m0" "arm,cortex-m0+" "arm,cortex-m1" -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of/irq: optimize device node matching loop in of_irq_init()
Currently, of_irq_init() iterates over interrupt controller nodes
with for_each_matching_node(), and then gets each init function with
of_match_node() later.
This routine can be optimized with for_each_matching_node_and_match().
It allows to get the interrupt controller node and its init function
at the same time, saving __of_match_node() callings.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
drivers/of/irq.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 902b89b..4c0da87 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -472,6 +472,7 @@ EXPORT_SYMBOL_GPL(of_irq_to_resource_table);
struct of_intc_desc {
struct list_headlist;
+ of_irq_init_cb_tirq_init_cb;
struct device_node *dev;
struct device_node *interrupt_parent;
};
@@ -485,6 +486,7 @@ struct of_intc_desc {
*/
void __init of_irq_init(const struct of_device_id *matches)
{
+ const struct of_device_id *match;
struct device_node *np, *parent = NULL;
struct of_intc_desc *desc, *temp_desc;
struct list_head intc_desc_list, intc_parent_list;
@@ -492,10 +494,15 @@ void __init of_irq_init(const struct of_device_id
*matches)
INIT_LIST_HEAD(_desc_list);
INIT_LIST_HEAD(_parent_list);
- for_each_matching_node(np, matches) {
+ for_each_matching_node_and_match(np, matches, ) {
if (!of_find_property(np, "interrupt-controller", NULL) ||
!of_device_is_available(np))
continue;
+
+ if (WARN(!match->data, "of_irq_init: no init function for %s\n",
+match->compatible))
+ continue;
+
/*
* Here, we allocate and populate an of_intc_desc with the node
* pointer, interrupt-parent device_node etc.
@@ -506,6 +513,7 @@ void __init of_irq_init(const struct of_device_id *matches)
goto err;
}
+ desc->irq_init_cb = match->data;
desc->dev = of_node_get(np);
desc->interrupt_parent = of_irq_find_parent(np);
if (desc->interrupt_parent == np)
@@ -525,27 +533,18 @@ void __init of_irq_init(const struct of_device_id
*matches)
* The assumption is that NULL parent means a root controller.
*/
list_for_each_entry_safe(desc, temp_desc, _desc_list,
list) {
- const struct of_device_id *match;
int ret;
- of_irq_init_cb_t irq_init_cb;
if (desc->interrupt_parent != parent)
continue;
list_del(>list);
- match = of_match_node(matches, desc->dev);
- if (WARN(!match->data,
- "of_irq_init: no init function for %s\n",
- match->compatible)) {
- kfree(desc);
- continue;
- }
- pr_debug("of_irq_init: init %s @ %p, parent %p\n",
-match->compatible,
+ pr_debug("of_irq_init: init %s (%p), parent %p\n",
+desc->dev->full_name,
desc->dev, desc->interrupt_parent);
- irq_init_cb = (of_irq_init_cb_t)match->data;
- ret = irq_init_cb(desc->dev, desc->interrupt_parent);
+ ret = desc->irq_init_cb(desc->dev,
+ desc->interrupt_parent);
if (ret) {
kfree(desc);
continue;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: zynq: describe SLCR as simple-mfd rather than simple-bus
The SLCR (System-Level Control Registers) block is an MFD (Multi
Function Device) rather than a bus.
"simple-mfd" seems a more suitable compatible string than "simple-bus".
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/zynq-7000.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 1a5220e..64ddd4d 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -238,7 +238,7 @@
slcr: slcr@f800 {
#address-cells = <1>;
#size-cells = <1>;
- compatible = "xlnx,zynq-slcr", "syscon", "simple-bus";
+ compatible = "xlnx,zynq-slcr", "syscon", "simple-mfd";
reg = <0xF800 0x1000>;
ranges;
clkc: clkc@100 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of: simplify arch_find_n_match_cpu_physical_id() function
This commit does not change the function behavior. Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- drivers/of/base.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/of/base.c b/drivers/of/base.c index 8b5a187..017dd94 100644 --- a/drivers/of/base.c +++ b/drivers/of/base.c @@ -375,10 +375,7 @@ bool __weak arch_find_n_match_cpu_physical_id(struct device_node *cpun, cpu, thread)) return true; - if (__of_find_n_match_cpu_property(cpun, "reg", cpu, thread)) - return true; - - return false; + return __of_find_n_match_cpu_property(cpun, "reg", cpu, thread); } /** -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform
Hi Lee, 2015-10-26 17:17 GMT+09:00 Lee Jones <lee.jo...@linaro.org>: >> This series adds two I2C controller drivers. >> (they are completely different IPs.) >> >> The first one is a very simple FIFO-less I2C controller, >> which is used on some older UniPhier SoCs. >> >> The other one is higher-performance I2C controller with TX/RX FIFO, >> used on newer UniPhier SoCs. > > And you have sent this to me because ... ? No special reason. I sent this series to linux-...@vger.kernel.org. I guess you were automatically CC'ed by scripts/get_maintainer.pl. Using get_maintainer.pl is a normal process when sending patches, I think. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: uniphier: add system-bus-controller nodes
The System Bus Controller block has two register regions,
but having only the second one in a separate node was not nice.
Replace it with a new node with two register regions in it.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 7 +++
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 7 +++
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 7 +++
6 files changed, 18 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index ae13469..af49381 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index 85377b2..254642f 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -232,10 +232,9 @@
clock-frequency = <40>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb2: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 96da01e..11eb762 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -241,10 +241,9 @@
clock-frequency = <40>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
pinctrl: pinctrl@5f801000 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 945b37f..691a17d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -216,10 +216,9 @@
clock-frequency = <40>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index c98428c..e88559b 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -200,10 +200,9 @@
clock-frequency = <10>;
};
- system-bus-controller-misc@5980 {
- compatible =
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
- reg = <0x5980 0x2000>;
+ system-bus-controller@58c0 {
+ compatible = "socionext,uniphier-system-bus-controller";
+ reg = <0x58c0 0x400>, <0x5980 0x2000>;
};
Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Arnd, 2015-10-10 15:59 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>: > Hi Arnd, > > > 2015-10-06 15:22 GMT+01:00 Arnd Bergmann <a...@arndb.de>: >> On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote: >>> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote: >>> > Hi Olof, >>> > >>> > Now Linux 4.3-rc1 is out, so I am back to this. >>> > >>> > 1/3: add outer cache support >>> > 2/3: rework SMP operations >>> > 3/3: add device tree nodes >>> > >>> > Because 2/3 highly depends on 1/3, I hope whole of this series >>> > is applied through ARM-SOC tree. >>> >>> Sorry for the long delay here. Is this the latest version of these >>> patches? >>> >>> Did Russell King review the first patch? >>> Is he ok with merging this through arm-soc? >>> >> >> I found an answer to the first question, as I see you posted >> v5 of the patchset in the meantime. > > > Yes, v5 is my latest version. > > > For the second question, Russell gave me some comments on the 1/3 > and I answered. > > He mentioned nothing about merging the whole series thru arm-soc. > (At least, he was not opposed to it, I guess) > Is it difficult to apply this series for the next merge window? V5 is the latest. No comment, but not applied. Is there anything I can do but wait? -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] i2c: uniphier: add UniPhier FIFO-less I2C driver
Add support for on-chip I2C controller used on old UniPhier SoCs
such as PH1-LD4, PH1-sLD8, etc. This adapter is so simple that
it has no FIFO in it.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v2:
- Delete if-block after platform_get_resource()
- Add I2C_FUNC_SMBUS_EMUL to functionality
- Add bindings document
- Add entry to MAINTAINERS
.../devicetree/bindings/i2c/i2c-uniphier.txt | 25 ++
MAINTAINERS| 1 +
drivers/i2c/busses/Kconfig | 8 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-uniphier.c | 441 +
5 files changed, 476 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
create mode 100644 drivers/i2c/busses/i2c-uniphier.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
new file mode 100644
index 000..26f9d95
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt
@@ -0,0 +1,25 @@
+UniPhier I2C controller (FIFO-less)
+
+Required properties:
+- compatible: should be "socionext,uniphier-i2c".
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- reg: offset and length of the register set for the device.
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+- clock-frequency: desired I2C bus frequency in Hz. The maximum supported
+ value is 40. Defaults to 10 if not specified.
+
+Examples:
+
+ i2c0: i2c@5840 {
+ compatible = "socionext,uniphier-i2c";
+ reg = <0x5840 0x40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 41 1>;
+ clocks = <_clk>;
+ clock-frequency = <10>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index fb7d2e4..b21c456 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1607,6 +1607,7 @@ L:linux-arm-ker...@lists.infradead.org (moderated
for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
F: arch/arm/mach-uniphier/
+F: drivers/i2c/busses/i2c-uniphier*
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 08b8617..2a176b0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -902,6 +902,14 @@ config I2C_TEGRA
If you say yes to this option, support will be included for the
I2C controller embedded in NVIDIA Tegra SOCs
+config I2C_UNIPHIER
+ tristate "UniPhier FIFO-less I2C controller"
+ depends on ARCH_UNIPHIER
+ help
+ If you say yes to this option, support will be included for
+ the UniPhier FIFO-less I2C interface embedded in PH1-LD4, PH1-sLD8,
+ or older UniPhier SoCs.
+
config I2C_VERSATILE
tristate "ARM Versatile/Realview I2C bus support"
depends on ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 6df3b30..f9f0902 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_I2C_ST) += i2c-st.o
obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
+obj-$(CONFIG_I2C_UNIPHIER) += i2c-uniphier.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
obj-$(CONFIG_I2C_WMT) += i2c-wmt.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
diff --git a/drivers/i2c/busses/i2c-uniphier.c
b/drivers/i2c/busses/i2c-uniphier.c
new file mode 100644
index 000..e3c3861
--- /dev/null
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -0,0 +1,441 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UNIPHIER_I2C_DTRM 0x00/* TX register */
+#define UNIPHIER_I2C_DTRM_IRQENBIT(11) /* enable interrupt */
+#define UNIPHIER_I2C_DTRM_STA BIT(10) /* start condition */
+#define UNIPHIER_I2C_DTRM_STO BIT(9) /* stop condition */
+#define UNIPHIER_I2C_D
Re: [PATCH 3/3] i2c: uniphier: add bindings for UniPhier I2C controllers
2015-10-23 6:00 GMT+09:00 Wolfram Sang <w...@the-dreams.de>: > On Thu, Jul 30, 2015 at 05:12:22PM +0900, Masahiro Yamada wrote: >> Device Tree bindings for two I2C controllers embedded in >> UniPhier SoCs. >> >> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> > > Please split this into two files with filenames matching those of the > drivers. I know they will be very similar but I'd like to keep > consistent. > OK, I splited it in v2. Each document was merged into the corresponding driver patch. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver
Add support for on-chip I2C controller used on newer UniPhier SoCs
such as PH1-Pro4, PH1-Pro5, etc. This adapter is equipped with
8-depth TX/RX FIFOs.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v2:
- Delete if-block after platform_get_resource()
- Add I2C_FUNC_SMBUS_EMUL to functionality
- Add bindings document
- Fix a typo in a comment block
.../devicetree/bindings/i2c/i2c-uniphier-f.txt | 25 +
drivers/i2c/busses/Kconfig | 8 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-uniphier-f.c| 584 +
4 files changed, 618 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
new file mode 100644
index 000..27fc6f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt
@@ -0,0 +1,25 @@
+UniPhier I2C controller (FIFO-builtin)
+
+Required properties:
+- compatible: should be "socionext,uniphier-fi2c".
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+- reg: offset and length of the register set for the device.
+- interrupts: a single interrupt specifier.
+- clocks: phandle to the input clock.
+
+Optional properties:
+- clock-frequency: desired I2C bus frequency in Hz. The maximum supported
+ value is 40. Defaults to 10 if not specified.
+
+Examples:
+
+ i2c0: i2c@5878 {
+ compatible = "socionext,uniphier-fi2c";
+ reg = <0x5878 0x80>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 41 4>;
+ clocks = <_clk>;
+ clock-frequency = <10>;
+ };
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2a176b0..0111219 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -910,6 +910,14 @@ config I2C_UNIPHIER
the UniPhier FIFO-less I2C interface embedded in PH1-LD4, PH1-sLD8,
or older UniPhier SoCs.
+config I2C_UNIPHIER_F
+ tristate "UniPhier FIFO-builtin I2C controller"
+ depends on ARCH_UNIPHIER
+ help
+ If you say yes to this option, support will be included for
+ the UniPhier FIFO-builtin I2C interface embedded in PH1-Pro4,
+ PH1-Pro5, or newer UniPhier SoCs.
+
config I2C_VERSATILE
tristate "ARM Versatile/Realview I2C bus support"
depends on ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index f9f0902..37f2819 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_I2C_STU300) += i2c-stu300.o
obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o
obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o
obj-$(CONFIG_I2C_UNIPHIER) += i2c-uniphier.o
+obj-$(CONFIG_I2C_UNIPHIER_F) += i2c-uniphier-f.o
obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o
obj-$(CONFIG_I2C_WMT) += i2c-wmt.o
obj-$(CONFIG_I2C_OCTEON) += i2c-octeon.o
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c
b/drivers/i2c/busses/i2c-uniphier-f.c
new file mode 100644
index 000..e8d03bc
--- /dev/null
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -0,0 +1,584 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UNIPHIER_FI2C_CR 0x00/* control register */
+#define UNIPHIER_FI2C_CR_MST BIT(3) /* master mode */
+#define UNIPHIER_FI2C_CR_STA BIT(2) /* start condition */
+#define UNIPHIER_FI2C_CR_STO BIT(1) /* stop condition */
+#define UNIPHIER_FI2C_CR_NACK BIT(0) /* do not return ACK */
+#define UNIPHIER_FI2C_DTTX 0x04/* TX FIFO */
+#define UNIPHIER_FI2C_DTTX_CMD BIT(8) /* send command (slave addr) */
+#define UNIPHIER_FI2C_DTTX_RD BIT(0) /* read transaction */
+#define UNIPHIER_FI2C_DTRX 0x04/* RX FIFO */
+#define UNIPHIER_FI2C_SLAD 0x0c/* slave address */
+#define UNIPHIER_FI2C_CYC 0x10/* clock cycle control */
+#define UNIPHIER_FI2C_LCTL 0
[PATCH v2 0/2] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform
This series adds two I2C controller drivers. (they are completely different IPs.) The first one is a very simple FIFO-less I2C controller, which is used on some older UniPhier SoCs. The other one is higher-performance I2C controller with TX/RX FIFO, used on newer UniPhier SoCs. Changes in v2: - Delete if-block after platform_get_resource() - Add I2C_FUNC_SMBUS_EMUL to functionality - Add bindings document - Add entry to MAINTAINERS - Delete if-block after platform_get_resource() - Add I2C_FUNC_SMBUS_EMUL to functionality - Add bindings document - Fix a typo in a comment block Masahiro Yamada (2): i2c: uniphier: add UniPhier FIFO-less I2C driver i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver .../devicetree/bindings/i2c/i2c-uniphier-f.txt | 25 + .../devicetree/bindings/i2c/i2c-uniphier.txt | 25 + MAINTAINERS| 1 + drivers/i2c/busses/Kconfig | 16 + drivers/i2c/busses/Makefile| 2 + drivers/i2c/busses/i2c-uniphier-f.c| 584 + drivers/i2c/busses/i2c-uniphier.c | 441 7 files changed, 1094 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c create mode 100644 drivers/i2c/busses/i2c-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] of/fdt: fix error checking for earlycon address
fdt_translate_address() returns OF_BAD_ADDR on error. It is defined as
a u64 value, so the variable "addr" should be defined as u64 as well.
Fixes: fb11ffe74c79 ("of/fdt: add FDT serial scanning for earlycon")
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
drivers/of/fdt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9fc3568..196e449 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -822,14 +822,15 @@ static int __init early_init_dt_scan_chosen_serial(void)
return -ENODEV;
while (match->compatible[0]) {
- unsigned long addr;
+ u64 addr;
+
if (fdt_node_check_compatible(fdt, offset, match->compatible)) {
match++;
continue;
}
addr = fdt_translate_address(fdt, offset);
- if (!addr)
+ if (addr == OF_BAD_ADDR)
return -ENXIO;
of_setup_earlycon(addr, match->data);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: dts: uniphier: delete i2c aliases
2015-10-24 5:16 GMT+09:00 Arnd Bergmann <a...@arndb.de>: > On Wednesday 21 October 2015 20:36:28 Masahiro Yamada wrote: >> The user space should not expect that a particular I2C channel is >> always visible through the same character device. >> No reason to fix the I2C indexes with aliases. >> >> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> >> > > As I said in my reply to the earlier mail, I didn't really like the > idea of having holes in the numbering for the i2c controllers, but > this new approach also doesn't look ideal. > > We should have stable bus numbers on any given board, and the aliases > work well for that. I just don't think the aliases need to be stable > between different boards just because they are based on the same > SoC. > > I'd suggest staying with the current slightly awkward approach though, > to avoid regressions. Please send a follow-up patch to add the same > aliases on the new boards and drop this patch, unless someone else > can come up with a better idea. > OK, will do. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: uniphier: add I2C aliases for ProXstream2 boards
Add aliases to fix the I2C indexes like the other UniPhier boards. Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 4 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 4 2 files changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts index 5cb58b6..9d7ec5c 100644 --- a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts +++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts @@ -62,6 +62,10 @@ serial0 = serial1 = serial2 = + i2c0 = + i2c4 = + i2c5 = + i2c6 = }; }; diff --git a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts index 76040bb..498acac 100644 --- a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts +++ b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts @@ -62,6 +62,10 @@ serial0 = serial1 = serial2 = + i2c0 = + i2c4 = + i2c5 = + i2c6 = }; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which is better to specify console, "console= " or "stdout-path" ?
Hi Peter,
2015-10-22 1:26 GMT+09:00 Peter Hurley <pe...@hurleysoftware.com>:
> On 10/21/2015 11:38 AM, Masahiro Yamada wrote:
>> Hi Peter.
>>
>> 2015-10-21 21:46 GMT+09:00 Peter Hurley <pe...@hurleysoftware.com>:
>>> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>>>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>>>> I think there exist two ways to specify the console port and baudrate.
>>>>>
>>>>>
>>>>> [1] Specify console in bootargs
>>>>>
>>>>>chosen {
>>>>> bootargs = "console=ttyS0,115200";
>>>>>};
>>>>>
>>>>>
>>>>> [2] Specify stdout-path
>>>>>
>>>>> chosen {
>>>>> stdout-path = "serial0:115200n8";
>>>>
>>>> This will work for even early/boot console, so this is better than
>>>> option [1]
>>>
>>> Be aware that options specified via /chosen/stdout-path are
>>> currently ignored by earlycon. There were some hiccups getting the
>>> initial support upstream; when 4.4 hits mainline, I'll resubmit
>>> my series that implements the of_serial i/o properties and
>>> options passthrough to earlycon setup.
>>
>>
>> As I said in another thread ("serial: earlycon: allow to specify
>> uartclk in earlycon kernel-parameter"),
>> stdout-path can pass dev->baud, but not port->uartclk.
>
> That's true but I'm not seeing in that thread where you wrote that?
Sorry, I made you confused. I was talking about the kernel parameter (console=)
in the thread.
> My replies there were specific to uartclk on the kernel command line,
> which isn't necessary if the bootloader has already initialized the
> uart.
>
>> It is usually specified "clocks" phandle, but
>> clk is not ready at the point of earlycon.
>>
>> It seems impossible to set up the baudrate even if the options are passed.
>
> It's difficult to understand what you're trying to do when I can't
> see the code you're referring to. For example, I only recently
> understood that you're talking about a earlycon implementation
> that you're working on and not the 8250 earlycon itself.
Sorry again for making you confused.
I was talking both.
Now I am tackling on some ARM board porting.
The board has a pure 8250 family device (compatible = "ns16550a") on it.
In addition, there exist 8250-variant IPs inside the SoC.
(this is similar to 8250, but slightly different.
drivers/tty/serial/8250/8250_uniphier.c)
What I want to do is:
[1] To use drivers/tty/serial/8250/8250_early.c for the on-board ns16550a.
[2] To implement my own EARLYCON_DECLARE() in
drivers/tty/serial/8250/8250_uniphier.c
> If you look at other non-8250 earlycons, you'll see they all ignore
> the baud rate, on the assumption the bootloader already set it up.
OK, I will do so for [2].
> The 8250 earlycon is a little different because legacy platforms
> do not initialize the uart.
Make sense.
For legacy platforms, earlycon initializes the uart,
assuming the hard-coded "port->uartclk = BASE_BAUD * 16"
is the value.
For embedded boards such as ARM, the boot-loader should initialize the UART
and the earlycon should preserve it because port->uartclk varies from
board to board.
(For example, the ns16550a on my board expects BASE_BAUD is 1228000,
but it does not match the one in include/asm-generic/serial.h )
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Which is better to specify console, "console= " or "stdout-path" ?
Hi Peter.
2015-10-21 21:46 GMT+09:00 Peter Hurley <pe...@hurleysoftware.com>:
> On 10/21/2015 04:58 AM, Sudeep Holla wrote:
>> On 21/10/15 06:09, Masahiro Yamada wrote:
>>> I think there exist two ways to specify the console port and baudrate.
>>>
>>>
>>> [1] Specify console in bootargs
>>>
>>>chosen {
>>> bootargs = "console=ttyS0,115200";
>>>};
>>>
>>>
>>> [2] Specify stdout-path
>>>
>>> chosen {
>>> stdout-path = "serial0:115200n8";
>>
>> This will work for even early/boot console, so this is better than
>> option [1]
>
> Be aware that options specified via /chosen/stdout-path are
> currently ignored by earlycon. There were some hiccups getting the
> initial support upstream; when 4.4 hits mainline, I'll resubmit
> my series that implements the of_serial i/o properties and
> options passthrough to earlycon setup.
As I said in another thread ("serial: earlycon: allow to specify
uartclk in earlycon kernel-parameter"),
stdout-path can pass dev->baud, but not port->uartclk.
It is usually specified "clocks" phandle, but
clk is not ready at the point of earlycon.
It seems impossible to set up the baudrate even if the options are passed.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1 (2nd try)
The subject should be "ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.4-rc1" I cannot wait until Linux 4.14-rc1 :) -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: uniphier: delete i2c aliases
The user space should not expect that a particular I2C channel is always visible through the same character device. No reason to fix the I2C indexes with aliases. Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> --- arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 4 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 7 --- arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 6 -- arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 5 - arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 4 5 files changed, 26 deletions(-) diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts index f1e9d40..052fcc0 100644 --- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts +++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts @@ -65,10 +65,6 @@ serial1 = serial2 = serial3 = - i2c0 = - i2c1 = - i2c2 = - i2c3 = }; }; diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts index 5baa9fc..90563fd 100644 --- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts +++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts @@ -64,13 +64,6 @@ serial0 = serial1 = serial2 = - i2c0 = - i2c1 = - i2c2 = - i2c3 = - i2c4 = - i2c5 = - i2c6 = }; }; diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts index 2462668..0c52847 100644 --- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts +++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts @@ -65,12 +65,6 @@ serial1 = serial2 = serial3 = - i2c0 = - i2c1 = - i2c2 = - i2c3 = - i2c5 = - i2c6 = }; }; diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts index b7a03215..5b12f5a 100644 --- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts +++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts @@ -65,11 +65,6 @@ serial0 = serial1 = serial2 = - i2c0 = - i2c1 = - i2c2 = - i2c3 = - i2c4 = }; }; diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts index fc7250c..6d788f0 100644 --- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts +++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts @@ -65,10 +65,6 @@ serial1 = serial2 = serial3 = - i2c0 = - i2c1 = - i2c2 = - i2c3 = }; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: uniphier: add ProXstream2 Gentil board support
Initial version of DTS for ProXstream2 Gentil board.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/Makefile| 3 +-
arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 74 +++
2 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..d7eefec 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -672,7 +672,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-ld6b-ref.dtb \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-sld3-ref.dtb \
- uniphier-ph1-sld8-ref.dtb
+ uniphier-ph1-sld8-ref.dtb \
+ uniphier-proxstream2-gentil.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
new file mode 100644
index 000..5cb58b6
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -0,0 +1,74 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Gentil Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-proxstream2.dtsi"
+
+/ {
+ model = "UniPhier ProXstream2 Gentil Board";
+ compatible = "socionext,proxstream2-gentil", "socionext,proxstream2";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: uniphier: add ProXstream2 Vodka board support
Initial version of DTS for ProXstream2 Vodka board.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 74
2 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d7eefec..2e1bc82 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -673,7 +673,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-sld3-ref.dtb \
uniphier-ph1-sld8-ref.dtb \
- uniphier-proxstream2-gentil.dtb
+ uniphier-proxstream2-gentil.dtb \
+ uniphier-proxstream2-vodka.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
new file mode 100644
index 000..76040bb
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
@@ -0,0 +1,74 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Vodka Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-proxstream2.dtsi"
+
+/ {
+ model = "UniPhier ProXstream2 Vodka Board";
+ compatible = "socionext,proxstream2-vodka", "socionext,proxstream2";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x8000>;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1 (2nd try)
Hi Arnd, I dropped I2C aliases. (I want this policy to be consistent for all the uniphier DTS files. 2/4 deletes them from existing DTS files too.) Please pull this series for the next merge window. Thanks, Masahiro Masahiro Yamada (4): ARM: dts: uniphier: use stdout-path instead of console ARM: dts: uniphier: delete i2c aliases ARM: dts: uniphier: add ProXstream2 Gentil board support ARM: dts: uniphier: add ProXstream2 Vodka board support arch/arm/boot/dts/Makefile| 4 +- arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts| 7 +-- arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 10 +-- arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 9 +-- arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 8 +-- arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 7 +-- arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 74 +++ arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 74 +++ 8 files changed, 156 insertions(+), 37 deletions(-) create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: dts: uniphier: use stdout-path instead of console
Specifying both console and stdout-path is redundant. Add options
":115200n8" to stdout-path and drop "console=ttyS0,115200".
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 3 +--
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 3 +--
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 3 +--
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 3 +--
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 3 +--
5 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index e9722a5..f1e9d40 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -57,8 +57,7 @@
};
chosen {
- bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path = "serial0:115200n8";
};
aliases {
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index da2d564..5baa9fc 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -57,8 +57,7 @@
};
chosen {
- bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path = "serial0:115200n8";
};
aliases {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 47e2edb..2462668 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -57,8 +57,7 @@
};
chosen {
- bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path = "serial0:115200n8";
};
aliases {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index adcbbc6..b7a03215 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -58,8 +58,7 @@
};
chosen {
- bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path = "serial0:115200n8";
};
aliases {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index bcf2e7c..fc7250c 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -57,8 +57,7 @@
};
chosen {
- bootargs = "console=ttyS0,115200";
- stdout-path =
+ stdout-path = "serial0:115200n8";
};
aliases {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support
Hi Arnd,
2015-10-16 18:50 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>:
> Hi Arnd,
>
> 2015-10-16 18:18 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
>> On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
>>>
>>> No, it is not a typo, but intentional.
>>>
>>>
>>> i2c0 - i2c3 are connected to the pads of the SoC package.
>>> On the other hand, i2c-4 - i2c-6 are connected to
>>> internal devices inside the SoC package.
>>>
>>> i2c-4 - i2c-6 are always connected to the same hardware
>>> devices and always used for the same purpose.
>>>
>>>
>>> My expected scenario is:
>>>
>>> [1] i2c0 - i2c3 are connected to the on-board devices
>>> depending on board variants.
>>> On some boards, their status is "okay" and
>>> on some boards, their status is "disabled".
>>>
>>> [2] i2c4 - i2c6 are always used to communicate
>>> with in-package devices. The status is always "okay".
>>
>> I think you are getting confused because the data sheet uses
>> the same names as the kernel, but they are really different
>> things.
>>
>> How about boards that have i2c connectors that are labeled
>> differently?
>
>
> I guess it would rarely happen as it is confusing.
>
> The board connectors are generally named
> correspondingly to the hardware block ID in the SoC.
>
>
>
>> We want the aliases to match whatever is written on the
>> board normally, to make it easier for users.
>>
>>> [3] Some user-land applications may want to have access
>>> through the same character devices,
>>> /dev/i2c4, /dev/i2c5, /dev/i2c6
>>
>> That user space would however only work on boards with the
>> same SoC, which is not a safe assumption to make.
>
> Right.
>
>> Either
>> it should be specific to just one board which has a known
>> set of buses, or it should be done in a way that works
>> across SoC generations of families.
>>
>> Ideally the devices on the internal buses would have an
>> in-kernel driver that exports a high-level API to avoid this
>> problem. What devices are these?
>
> HDMI transmitter, TV signal demodulator, etc.
>
>
>
>>> If your way is adopted,
>>> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
>>> and /dev/i2c2 on others, etc.
>>
>> Right, I think that is how it should be. You could also make
>> the chip's i2c4 always link to user space /dev/i2c0 if you
>> want to keep those stable, but as I said that is still not
>> a good (software) system design.
>>
>
> Right. In-kernel drivers can handle it nicely.
>
> Also, we can write a device tree that specifies device connection
> hierarchy like follows.
> The device names will appear under /sys/ directory and user-land
> applications can check them.
>
> {
> demodulator {
> compatible = "...";
>
> };
> };
>
> {
> hdmi_tx {
>
>compatible = "...";
> };
> }
>
>
> I understand that I2C bus number assumption is avoidable,
> but I am still not fully convinced.
>
> Matching /dev/i2c* and the real hardware block ID (this is written in
> the SoC spec book)
> makes things clearer, I think.
>
Anyway, this version is unacceptable, right?
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Which is better to specify console, "console= " or "stdout-path" ?
Hi.
I think there exist two ways to specify the console port and baudrate.
[1] Specify console in bootargs
chosen {
bootargs = "console=ttyS0,115200";
};
[2] Specify stdout-path
chosen {
stdout-path = "serial0:115200n8";
};
Now I have both in my DTS, but it is redundant.
So, I want to select either [1] or [2].
Which is a preferable way?
Thanks,
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support
Hi Arnd,
2015-10-16 18:18 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
> On Friday 16 October 2015 14:24:30 Masahiro Yamada wrote:
>>
>> No, it is not a typo, but intentional.
>>
>>
>> i2c0 - i2c3 are connected to the pads of the SoC package.
>> On the other hand, i2c-4 - i2c-6 are connected to
>> internal devices inside the SoC package.
>>
>> i2c-4 - i2c-6 are always connected to the same hardware
>> devices and always used for the same purpose.
>>
>>
>> My expected scenario is:
>>
>> [1] i2c0 - i2c3 are connected to the on-board devices
>> depending on board variants.
>> On some boards, their status is "okay" and
>> on some boards, their status is "disabled".
>>
>> [2] i2c4 - i2c6 are always used to communicate
>> with in-package devices. The status is always "okay".
>
> I think you are getting confused because the data sheet uses
> the same names as the kernel, but they are really different
> things.
>
> How about boards that have i2c connectors that are labeled
> differently?
I guess it would rarely happen as it is confusing.
The board connectors are generally named
correspondingly to the hardware block ID in the SoC.
> We want the aliases to match whatever is written on the
> board normally, to make it easier for users.
>
>> [3] Some user-land applications may want to have access
>> through the same character devices,
>> /dev/i2c4, /dev/i2c5, /dev/i2c6
>
> That user space would however only work on boards with the
> same SoC, which is not a safe assumption to make.
Right.
> Either
> it should be specific to just one board which has a known
> set of buses, or it should be done in a way that works
> across SoC generations of families.
>
> Ideally the devices on the internal buses would have an
> in-kernel driver that exports a high-level API to avoid this
> problem. What devices are these?
HDMI transmitter, TV signal demodulator, etc.
>> If your way is adopted,
>> the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
>> and /dev/i2c2 on others, etc.
>
> Right, I think that is how it should be. You could also make
> the chip's i2c4 always link to user space /dev/i2c0 if you
> want to keep those stable, but as I said that is still not
> a good (software) system design.
>
Right. In-kernel drivers can handle it nicely.
Also, we can write a device tree that specifies device connection
hierarchy like follows.
The device names will appear under /sys/ directory and user-land
applications can check them.
{
demodulator {
compatible = "...";
};
};
{
hdmi_tx {
compatible = "...";
};
}
I understand that I2C bus number assumption is avoidable,
but I am still not fully convinced.
Matching /dev/i2c* and the real hardware block ID (this is written in
the SoC spec book)
makes things clearer, I think.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board
2015-10-15 17:58 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>:
> The IRQ signal from external devices on this board is connected to
> the XIRQ1 pin of the SoC. The IRQ number should be 51, not 50.
>
> Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b
> SoC/board support")
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> ---
>
> Hi Olof and Arnd,
>
> Could you apply this simple fix for Linux 4.13, please?
> (if it is troublesome, I can wait until Linux 4.14-rc1.)
>
> Thanks
>
This patch turned out wrong.
I retract this one and will send v2 later.
Sorry.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board
The IRQ signal from external devices on this board is connected to
the XIRQ4 pin of the SoC. The IRQ number should be 52, not 50.
Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b
SoC/board support")
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Changes in v2:
- change IRQ to 52
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 33963ac..f80f772 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -85,7 +85,7 @@
};
{
- interrupts = <0 50 4>;
+ interrupts = <0 52 4>;
};
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board
The IRQ signal from external devices on this board is connected to
the XIRQ1 pin of the SoC. The IRQ number should be 51, not 50.
Fixes: a5e921b4771f ("ARM: dts: uniphier: add ProXstream2 and PH1-LD6b
SoC/board support")
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
Hi Olof and Arnd,
Could you apply this simple fix for Linux 4.13, please?
(if it is troublesome, I can wait until Linux 4.14-rc1.)
Thanks
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 33963ac..3a6f1f6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -85,7 +85,7 @@
};
{
- interrupts = <0 50 4>;
+ interrupts = <0 51 4>;
};
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: uniphier: change the external bus address mapping
In UniPhier SoCs before ProXstream2 and PH1-LD6b, two address spaces
0x - 0x0fff
0x4000 - 0x4fff
are both mapped to the external bus (also called system bus),
so either was OK.
In the newest two SoCs, the former (0x - 0x0fff) is
assigned for the serial NOR interface.
For the consistency, use the latter for all the SoCs.
Also, fix the range properties to reflect the real address mapping,
where the support card is located at the offset address 0x01f0
of CS1 of the external bus.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 5 ++---
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 5 ++---
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 5 ++---
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 5 ++---
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 5 ++---
5 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index bfd3bb8..e9722a5 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -74,12 +74,11 @@
};
{
- ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+ ranges = <1 0x 0x4200 0x0200>;
};
_card {
- ranges = <0x 1 0x03f0 0x0010>;
+ ranges = <0x 1 0x01f0 0x0010>;
};
{
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
index 3a6f1f6..1a402ed 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
@@ -76,12 +76,11 @@
};
{
- ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+ ranges = <1 0x 0x4200 0x0200>;
};
_card {
- ranges = <0x 1 0x03f0 0x0010>;
+ ranges = <0x 1 0x01f0 0x0010>;
};
{
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 69a5b7d..47e2edb 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -76,12 +76,11 @@
};
{
- ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+ ranges = <1 0x 0x4200 0x0200>;
};
_card {
- ranges = <0x 1 0x03f0 0x0010>;
+ ranges = <0x 1 0x01f0 0x0010>;
};
{
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index 1a440f8..adcbbc6 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -75,12 +75,11 @@
};
{
- ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+ ranges = <1 0x 0x4200 0x0200>;
};
_card {
- ranges = <0x 1 0x03f0 0x0010>;
+ ranges = <0x 1 0x01f0 0x0010>;
};
{
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index 955d417..bcf2e7c 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -74,12 +74,11 @@
};
{
- ranges = <0 0x 0x0f00 0x0100
- 1 0x 0x 0x0800>;
+ ranges = <1 0x 0x4200 0x0200>;
};
_card {
- ranges = <0x 1 0x03f0 0x0010>;
+ ranges = <0x 1 0x01f0 0x0010>;
};
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support
Initial version of DTS for ProXstream2 Vodka board.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 79
2 files changed, 81 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..9232018 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -672,7 +672,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-ld6b-ref.dtb \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-sld3-ref.dtb \
- uniphier-ph1-sld8-ref.dtb
+ uniphier-ph1-sld8-ref.dtb \
+ uniphier-proxstream2-vodka.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
versatile-pb.dtb
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
new file mode 100644
index 000..27691f9
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-vodka.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Vodka Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-proxstream2.dtsi"
+
+/ {
+ model = "UniPhier ProXstream2 Vodka Board";
+ compatible = "socionext,proxstream2-vodka", "socionext,proxstream2";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS2,115200";
+ stdout-path =
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ i2c0 =
+ i2c4 =
+ i2c5 =
+ i2c6 =
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: dts: uniphier: DTS updates for UniPhier SoCs for Linux 4.14-rc1
Hi Olof and Arnd, Please apply this series to ARM-SOC for the next merge window. Thanks Masahiro Yamada Masahiro Yamada (3): ARM: dts: uniphier: change the external bus address mapping ARM: dts: uniphier: add ProXstream2 Vodka board support ARM: dts: uniphier: add ProXstream2 Gentil board support arch/arm/boot/dts/Makefile| 4 +- arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts| 5 +- arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 5 +- arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 5 +- arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 5 +- arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 5 +- arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 79 +++ arch/arm/boot/dts/uniphier-proxstream2-vodka.dts | 79 +++ 8 files changed, 171 insertions(+), 16 deletions(-) create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-vodka.dts -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: uniphier: add ProXstream2 Gentil board support
Initial version of DTS for ProXstream2 Gentil board.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/uniphier-proxstream2-gentil.dts | 79 +++
2 files changed, 80 insertions(+)
create mode 100644 arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9232018..2e1bc82 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -673,6 +673,7 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-pro4-ref.dtb \
uniphier-ph1-sld3-ref.dtb \
uniphier-ph1-sld8-ref.dtb \
+ uniphier-proxstream2-gentil.dtb \
uniphier-proxstream2-vodka.dtb
dtb-$(CONFIG_ARCH_VERSATILE) += \
versatile-ab.dtb \
diff --git a/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
new file mode 100644
index 000..3ea2a87
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-proxstream2-gentil.dts
@@ -0,0 +1,79 @@
+/*
+ * Device Tree Source for UniPhier ProXstream2 Gentil Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+/include/ "uniphier-proxstream2.dtsi"
+
+/ {
+ model = "UniPhier ProXstream2 Gentil Board";
+ compatible = "socionext,proxstream2-gentil", "socionext,proxstream2";
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x8000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS2,115200";
+ stdout-path =
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ serial2 =
+ i2c0 =
+ i2c4 =
+ i2c5 =
+ i2c6 =
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support
Hi Arnd,
2015-10-16 0:17 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
> On Thursday 15 October 2015 18:05:33 Masahiro Yamada wrote:
>> + aliases {
>> + serial0 =
>> + serial1 =
>> + serial2 =
>> + i2c0 =
>> + i2c4 =
>> + i2c5 =
>> + i2c6 =
>>
>
> This looks like a typo, you probably mean
>
>i2c0 =
>i2c1 =
>i2c2 =
>i2c3 =
>
> Can you re-send this?
>
No, it is not a typo, but intentional.
i2c0 - i2c3 are connected to the pads of the SoC package.
On the other hand, i2c-4 - i2c-6 are connected to
internal devices inside the SoC package.
i2c-4 - i2c-6 are always connected to the same hardware
devices and always used for the same purpose.
My expected scenario is:
[1] i2c0 - i2c3 are connected to the on-board devices
depending on board variants.
On some boards, their status is "okay" and
on some boards, their status is "disabled".
[2] i2c4 - i2c6 are always used to communicate
with in-package devices. The status is always "okay".
[3] Some user-land applications may want to have access
through the same character devices,
/dev/i2c4, /dev/i2c5, /dev/i2c6
If your way is adopted,
the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
and /dev/i2c2 on others, etc.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm
Hello Ian, Rob, Olof, 2015-10-13 0:37 GMT+09:00 Mark Rutland <mark.rutl...@arm.com>: > On Mon, Oct 05, 2015 at 12:53:52PM +0100, Ian Campbell wrote: >> Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on >> LogicTile Express 20MG" added a new dts file to arch/arm64 which >> included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a >> .dtsi supplied by arch/arm. >> >> Unfortunately this causes some issues for the split device tree >> repository[0], since things get moved around there. In that context >> the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts >> while the include is at src/arm/vexpress-v2m-rs1.dtsi. >> >> The sharing of the .dtsi is legitimate since the baseboard is the same >> for various vexpress systems whatever processor they use. >> >> Previously I attempted to resolve this by creating a shared location >> for such things but we have been unable to come to a consensus on >> where that should be. >> >> Instead this patch simply replaces the use of ../../ in the dts >> /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the >> file arch/arm/boot/dts. >> >> Since the split device tree repo will shortly be required to flatten >> symlinks for other reasons this will cause the dtsi file to appear in >> both src/arm and src/arm64 in the split repo, which is an improvement >> on not building for arm64 now. >> >> [0] >> https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/ >> >> Signed-off-by: Ian Campbell <ian.campb...@citrix.com> >> Cc: Rob Herring <robh...@kernel.org> >> Cc: Pawel Moll <pawel.m...@arm.com> >> Cc: Mark Rutland <mark.rutl...@arm.com> >> Cc: Kumar Gala <ga...@codeaurora.org> >> Cc: Liviu Dudau <liviu.du...@arm.com> >> Cc: Sudeep Holla <sudeep.ho...@arm.com> >> Cc: Lorenzo Pieralisi <lorenzo.pieral...@arm.com> >> Cc: Russell King <li...@arm.linux.org.uk> >> Cc: Catalin Marinas <catalin.mari...@arm.com> >> Cc: Will Deacon <will.dea...@arm.com> >> Cc: Kristina Martsenko <kristina.martse...@arm.com> >> Cc: Kevin Hilman <khil...@linaro.org> >> Cc: Frank Rowand <frank.row...@sonymobile.com> >> Cc: Olof Johansson <o...@lixom.net> >> Cc: devicetree@vger.kernel.org >> Cc: linux-ker...@vger.kernel.org >> Cc: linux-arm-ker...@lists.infradead.org >> Cc: a...@kernel.org >> Cc: linux-kbu...@vger.kernel.org I have a similar issue to vexpress, so I want to consult experts. I am trying to support a new ARM64 SoC and want to share some DTSI files between arch/arm/boot/dts and arch/arm64/boot/dts. I think Ian's "dtb: Create a common home for cross-architecture dtsi files" is under way (or rejected?). I can live with the symbolic link. Is it OK (at least for now)? -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Arnd, 2015-10-06 15:22 GMT+01:00 Arnd Bergmann <a...@arndb.de>: > On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote: >> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote: >> > Hi Olof, >> > >> > Now Linux 4.3-rc1 is out, so I am back to this. >> > >> > 1/3: add outer cache support >> > 2/3: rework SMP operations >> > 3/3: add device tree nodes >> > >> > Because 2/3 highly depends on 1/3, I hope whole of this series >> > is applied through ARM-SOC tree. >> >> Sorry for the long delay here. Is this the latest version of these >> patches? >> >> Did Russell King review the first patch? >> Is he ok with merging this through arm-soc? >> > > I found an answer to the first question, as I see you posted > v5 of the patchset in the meantime. Yes, v5 is my latest version. For the second question, Russell gave me some comments on the 1/3 and I answered. He mentioned nothing about merging the whole series thru arm-soc. (At least, he was not opposed to it, I guess) -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] ARM: uniphier: add outer cache support and rework SMP operations
2015-09-30 20:01 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>: > Hi Olof, > > Now Linux 4.3-rc1 is out, so I am back to this. > > 1/3: add outer cache support > 2/3: rework SMP operations > 3/3: add device tree nodes > > Because 2/3 highly depends on 1/3, I hope whole of this series > is applied through ARM-SOC tree. > > > Changes in v4: > - Add more detailed comments to explain why no spin lock is needed > - Add two examples to the binding document > > Changes in v3: > - Drop bogus includes > > Changes in v2: > - Use pr_fmt() to have pr_ are automatically prefixed > - Re-design to initialize the outer cache earlier in init_IRQ() > - Require DT properties such as "cacne-unified", "cache-size", > "cache-sets", "cache-size", "cache-line-size". > - Follow "next-level-cache" property to search further outer caches > I found something to be fixed. I will send v5. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Acked-by: Rob Herring <r...@kernel.org>
---
.../bindings/arm/uniphier/cache-uniphier.txt | 60 +++
MAINTAINERS| 2 +
arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++
arch/arm/kernel/irq.c | 3 +
arch/arm/mm/Kconfig| 10 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-uniphier.c | 555 +
7 files changed, 677 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
create mode 100644 arch/arm/mm/cache-uniphier.c
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..d27a646
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,60 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a full-custom outer cache controller system.
+All of them have a level 2 cache controller, and some have a level 3 cache
+controller as well.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-cache"
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 3 regions: control register, revision register, operation register,
+ in this order.
+- cache-unified: specifies the cache is a unified cache.
+- cache-size: specifies the size in bytes of the cache
+- cache-sets: specifies the number of associativity sets of the cache
+- cache-line-size: specifies the line size in bytes
+- cache-level: specifies the level in the cache hierarchy. The value should
+ be 2 for L2 cache, 3 for L3 cache, etc.
+
+Optional properties:
+- next-level-cache: phandle to the next level cache if present. The next level
+ cache should be also compatible with "socionext,uniphier-system-cache".
+
+The L2 cache must exist to use the L3 cache; the cache hierarchy must be
+indicated correctly with "next-level-cache" properties.
+
+Example 1 (system with L2):
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x8>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
+Example 2 (system with L2 and L3):
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x20>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ next-level-cache = <>;
+ };
+
+ l3: l3-cache@500c8000 {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+ cache-unified;
+ cache-size = <0x40>;
+ cache-sets = <512>;
+ cache-line-size = <256>;
+ cache-level = <3>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..bced05f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1606,7 +1606,9 @@ M:Masahiro Yamada <yamada.masah...@socionext.com>
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..102e3fb
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at yo
[PATCH v5 3/3] ARM: dts: uniphier: add outer cache controller nodes
Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 13 +
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 27 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 13 +
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 16
6 files changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..ae13469 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -55,6 +55,7 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
};
@@ -91,6 +92,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(512 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..85377b2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(768 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..96da01e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,31 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ interrupts = <0 190 4>, <0 191 4>;
+ cache-unified;
+ cache-size = <(2 * 1024 * 1024)>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cach
[PATCH v5 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, Now Linux 4.3-rc1 is out, so I am back to this. 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Because 2/3 highly depends on 1/3, I hope whole of this series is applied through ARM-SOC tree. Changes in v5: - Add __init to __uniphier_cache_set_locked_ways() function Changes in v4: - Add more detailed comments to explain why no spin lock is needed - Add two examples to the binding document Changes in v3: - Drop bogus includes Changes in v2: - Use pr_fmt() to have pr_ are automatically prefixed - Re-design to initialize the outer cache earlier in init_IRQ() - Require DT properties such as "cacne-unified", "cache-size", "cache-sets", "cache-size", "cache-line-size". - Follow "next-level-cache" property to search further outer caches Masahiro Yamada (3): ARM: uniphier: add outer cache support ARM: uniphier: rework SMP operations to use trampoline code ARM: dts: uniphier: add outer cache controller nodes .../bindings/arm/uniphier/cache-uniphier.txt | 60 +++ MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 13 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 27 + arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 13 + arch/arm/boot/dts/uniphier-proxstream2.dtsi| 16 + arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++ arch/arm/kernel/irq.c | 3 + arch/arm/mach-uniphier/Makefile| 2 +- arch/arm/mach-uniphier/headsmp.S | 43 ++ arch/arm/mach-uniphier/platsmp.c | 185 +-- arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 555 + 16 files changed, 973 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/headsmp.S create mode 100644 arch/arm/mm/cache-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, Now Linux 4.3-rc1 is out, so I am back to this. 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Because 2/3 highly depends on 1/3, I hope whole of this series is applied through ARM-SOC tree. Changes in v4: - Add more detailed comments to explain why no spin lock is needed - Add two examples to the binding document Changes in v3: - Drop bogus includes Changes in v2: - Use pr_fmt() to have pr_ are automatically prefixed - Re-design to initialize the outer cache earlier in init_IRQ() - Require DT properties such as "cacne-unified", "cache-size", "cache-sets", "cache-size", "cache-line-size". - Follow "next-level-cache" property to search further outer caches Masahiro Yamada (3): ARM: uniphier: add outer cache support ARM: uniphier: rework SMP operations to use trampoline code ARM: dts: uniphier: add outer cache controller nodes .../bindings/arm/uniphier/cache-uniphier.txt | 60 +++ MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 13 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 27 + arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 13 + arch/arm/boot/dts/uniphier-proxstream2.dtsi| 16 + arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++ arch/arm/kernel/irq.c | 3 + arch/arm/mach-uniphier/Makefile| 2 +- arch/arm/mach-uniphier/headsmp.S | 43 ++ arch/arm/mach-uniphier/platsmp.c | 185 +-- arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 554 + 16 files changed, 972 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/headsmp.S create mode 100644 arch/arm/mm/cache-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Acked-by: Rob Herring <r...@kernel.org>
---
.../bindings/arm/uniphier/cache-uniphier.txt | 60 +++
MAINTAINERS| 2 +
arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++
arch/arm/kernel/irq.c | 3 +
arch/arm/mm/Kconfig| 10 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-uniphier.c | 554 +
7 files changed, 676 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
create mode 100644 arch/arm/mm/cache-uniphier.c
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..668a18f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,60 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a full-custom outer cache controller system.
+All of them have a level 2 cache controller, and some have a level 3 cache
+controller as well.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-cache"
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 3 regions: control register, revision register, operation register,
+ in this order.
+- cache-unified: specifies the cache is a unified cache.
+- cache-size: specifies the size in bytes of the cache
+- cache-sets: specifies the number of associativity sets of the cache
+- cache-line-size: specifies the line size in bytes
+- cache-level: specifies the level in the cache hierarchy. The value should
+ be 2 for L2 cache, 3 for L3 cache, etc.
+
+Optional properties:
+- next-level-cache: phandle to the next level cache if present. The next level
+ cache should be also compatible with "socionext,uniphier-system-cache".
+
+The L2 cache must exist to use the L3 cache; the cache hierarchy must be
+indicated correctly with "next-level-cache" properties.
+
+Example 1 (L2 for outer cache):
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x20>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
+Example 2 (L2 and L3 for outer cache):
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x20>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ next-level-cache = <>;
+ };
+
+ l3: l3-cache@500c8000 {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+ cache-unified;
+ cache-size = <0x40>;
+ cache-sets = <512>;
+ cache-line-size = <256>;
+ cache-level = <3>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..bced05f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1606,7 +1606,9 @@ M:Masahiro Yamada <yamada.masah...@socionext.com>
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..102e3fb
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the Licen
[PATCH v4 3/3] ARM: dts: uniphier: add outer cache controller nodes
Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 13 +
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 27 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 13 +
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 16
6 files changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..ae13469 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -55,6 +55,7 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
};
@@ -91,6 +92,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(512 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..85377b2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(768 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..96da01e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,31 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ interrupts = <0 190 4>, <0 191 4>;
+ cache-unified;
+ cache-size = <(2 * 1024 * 1024)>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cach
Re: [PATCH v3 1/3] ARM: uniphier: add outer cache support
2015-09-22 14:27 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>:
> Hi Russell,
>
>
> 2015-09-22 4:38 GMT+09:00 Russell King - ARM Linux <li...@arm.linux.org.uk>:
>> On Fri, Sep 18, 2015 at 01:37:32PM +0900, Masahiro Yamada wrote:
>>> +/**
>>> + * __uniphier_cache_maint_common - run a queue operation for a particular
>>> level
>>> + *
>>> + * @data: cache controller specific data
>>> + * @start: start address of range operation (don't care for "all"
>>> operation)
>>> + * @size: data size of range operation (don't care for "all" operation)
>>> + * @operation: flags to specify the desired cache operation
>>> + */
>>> +static void __uniphier_cache_maint_common(struct uniphier_cache_data *data,
>>> + unsigned long start,
>>> + unsigned long size,
>>> + u32 operation)
>>> +{
>>> + unsigned long flags;
>>> +
>>> + /*
>>> + * The IRQ must be disable during this sequence because the accessor
>>> + * holds the access right of the operation queue registers. The IRQ
>>> + * should be restored after releasing the register access right.
>>> + */
>>> + local_irq_save(flags);
>>> +
>>> + /* clear the complete notification flag */
>>> + writel_relaxed(UNIPHIER_SSCOLPQS_EF, data->op_base +
>>> UNIPHIER_SSCOLPQS);
>>> +
>>> + /*
>>> + * We do not need a spin lock here because the hardware guarantees
>>> + * this sequence is atomic, i.e. the write access is arbitrated
>>> + * and only the winner's write accesses take effect.
>>> + * After register settings, we need to check the UNIPHIER_SSCOPPQSEF
>>> to
>>> + * see if we won the arbitration or not.
>>> + * If the command was not successfully set, just try again.
>>> + */
>>> + do {
>>> + /* set cache operation */
>>> + writel_relaxed(UNIPHIER_SSCOQM_CE | operation,
>>> +data->op_base + UNIPHIER_SSCOQM);
>>> +
>>> + /* set address range if needed */
>>> + if (likely(UNIPHIER_SSCOQM_S_IS_RANGE(operation))) {
>>> + writel_relaxed(start, data->op_base +
>>> UNIPHIER_SSCOQAD);
>>> + writel_relaxed(size, data->op_base +
>>> UNIPHIER_SSCOQSZ);
>>> + }
>>> +
>>> + /* set target ways if needed */
>>> + if (unlikely(UNIPHIER_SSCOQM_TID_IS_WAY(operation)))
>>> + writel_relaxed(data->way_locked_mask,
>>> +data->op_base + UNIPHIER_SSCOQWN);
>>> + } while (unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
>>> + (UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE)));
>>> +
>>> + /* wait until the operation is completed */
>>> + while (likely(readl_relaxed(data->op_base + UNIPHIER_SSCOLPQS) !=
>>> + UNIPHIER_SSCOLPQS_EF))
>>> + cpu_relax();
>>> +
>>> + local_irq_restore(flags);
>>
>> I'm concerned about this. We've had caches like this (ARM L220) which
>> require only one operation to be performed at a time. In a SMP system,
>> that requires a spinlock to prevent one CPU triggering a L2 maintanence
>> operation while another CPU tries to operate on the L2 cache.
>>
>> From the overall series diffstat, I see that you are adding SMP support
>> too. So I have to ask the obvious question: if you need to disable
>> local IRQs around the L2 cache operations, what happens if two CPUs
>> both try to perform a L2 cache operation concurrently?
>
>
> This cache controller is able to accept operations from multiple CPUs
> at the same time.
>
> Let's assume the following scenario:
>
> CPU0 issues some operation.
> Before the cache controller finishes the operation,
> CPU1 issues another operation; this is OK.
> The operation is stored in the queue of the cache controller
> until the operation under way is completed.
> When the operation from CPU0 is finished, the controller starts
> the operation from CPU1.
>
> If the queue is full (this unlikely happens though),
> the CPU can know by checking UNIPHIER_SSCOPPQSEF register.
> This is checked by the c
Re: [PATCH 0/3] i2c: uniphier: add two I2C controller drivers for UniPhier SoC platform
Hi Wolfram, Could you have some time for reviewing this series? Perhaps, after ELCE? 2015-07-30 17:12 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>: > > This series adds two I2C controller drivers. > (they are completely different IPs.) > > The first one is a very simple FIFO-less I2C controller, > which is used on some older UniPhier SoCs. > > The other one is higher-performance I2C controller with TX/RX FIFO, > used on newer UniPhier SoCs. > > > > Masahiro Yamada (3): > i2c: uniphier: add UniPhier FIFO-less I2C driver > i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver > i2c: uniphier: add bindings for UniPhier I2C controllers > > .../devicetree/bindings/i2c/i2c-uniphier.txt | 46 ++ > drivers/i2c/busses/Kconfig | 16 + > drivers/i2c/busses/Makefile| 2 + > drivers/i2c/busses/i2c-uniphier-f.c| 589 > + > drivers/i2c/busses/i2c-uniphier.c | 446 > 5 files changed, 1099 insertions(+) > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt > create mode 100644 drivers/i2c/busses/i2c-uniphier-f.c > create mode 100644 drivers/i2c/busses/i2c-uniphier.c > > -- > 1.9.1 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] ARM: uniphier: add outer cache support
Hi Russell,
2015-09-22 4:38 GMT+09:00 Russell King - ARM Linux <li...@arm.linux.org.uk>:
> On Fri, Sep 18, 2015 at 01:37:32PM +0900, Masahiro Yamada wrote:
>> +/**
>> + * __uniphier_cache_maint_common - run a queue operation for a particular
>> level
>> + *
>> + * @data: cache controller specific data
>> + * @start: start address of range operation (don't care for "all" operation)
>> + * @size: data size of range operation (don't care for "all" operation)
>> + * @operation: flags to specify the desired cache operation
>> + */
>> +static void __uniphier_cache_maint_common(struct uniphier_cache_data *data,
>> + unsigned long start,
>> + unsigned long size,
>> + u32 operation)
>> +{
>> + unsigned long flags;
>> +
>> + /*
>> + * The IRQ must be disable during this sequence because the accessor
>> + * holds the access right of the operation queue registers. The IRQ
>> + * should be restored after releasing the register access right.
>> + */
>> + local_irq_save(flags);
>> +
>> + /* clear the complete notification flag */
>> + writel_relaxed(UNIPHIER_SSCOLPQS_EF, data->op_base +
>> UNIPHIER_SSCOLPQS);
>> +
>> + /*
>> + * We do not need a spin lock here because the hardware guarantees
>> + * this sequence is atomic, i.e. the write access is arbitrated
>> + * and only the winner's write accesses take effect.
>> + * After register settings, we need to check the UNIPHIER_SSCOPPQSEF to
>> + * see if we won the arbitration or not.
>> + * If the command was not successfully set, just try again.
>> + */
>> + do {
>> + /* set cache operation */
>> + writel_relaxed(UNIPHIER_SSCOQM_CE | operation,
>> +data->op_base + UNIPHIER_SSCOQM);
>> +
>> + /* set address range if needed */
>> + if (likely(UNIPHIER_SSCOQM_S_IS_RANGE(operation))) {
>> + writel_relaxed(start, data->op_base +
>> UNIPHIER_SSCOQAD);
>> + writel_relaxed(size, data->op_base + UNIPHIER_SSCOQSZ);
>> + }
>> +
>> + /* set target ways if needed */
>> + if (unlikely(UNIPHIER_SSCOQM_TID_IS_WAY(operation)))
>> + writel_relaxed(data->way_locked_mask,
>> +data->op_base + UNIPHIER_SSCOQWN);
>> + } while (unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
>> + (UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE)));
>> +
>> + /* wait until the operation is completed */
>> + while (likely(readl_relaxed(data->op_base + UNIPHIER_SSCOLPQS) !=
>> + UNIPHIER_SSCOLPQS_EF))
>> + cpu_relax();
>> +
>> + local_irq_restore(flags);
>
> I'm concerned about this. We've had caches like this (ARM L220) which
> require only one operation to be performed at a time. In a SMP system,
> that requires a spinlock to prevent one CPU triggering a L2 maintanence
> operation while another CPU tries to operate on the L2 cache.
>
> From the overall series diffstat, I see that you are adding SMP support
> too. So I have to ask the obvious question: if you need to disable
> local IRQs around the L2 cache operations, what happens if two CPUs
> both try to perform a L2 cache operation concurrently?
This cache controller is able to accept operations from multiple CPUs
at the same time.
Let's assume the following scenario:
CPU0 issues some operation.
Before the cache controller finishes the operation,
CPU1 issues another operation; this is OK.
The operation is stored in the queue of the cache controller
until the operation under way is completed.
When the operation from CPU0 is finished, the controller starts
the operation from CPU1.
If the queue is full (this unlikely happens though),
the CPU can know by checking UNIPHIER_SSCOPPQSEF register.
This is checked by the code:
unlikely(readl_relaxed(data->op_base + UNIPHIER_SSCOPPQSEF) &
(UNIPHIER_SSCOPPQSEF_FE | UNIPHIER_SSCOPPQSEF_OE))
The status register (UNIPHIER_SSCOLPQS) has each instance for each CPU.
That means, CPU0 can know if the operation issued by itself is finished or not.
Likewise for CPU1, CPU2, ...
To sum up, the cache controller can nicely handles cache operations in SMP.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] ARM: dts: uniphier: add outer cache controller nodes
Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 13 +
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 27 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 13 +
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 16
6 files changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..ae13469 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -55,6 +55,7 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
};
@@ -91,6 +92,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(512 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..85377b2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(768 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..96da01e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,31 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ interrupts = <0 190 4>, <0 191 4>;
+ cache-unified;
+ cache-size = <(2 * 1024 * 1024)>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cach
[PATCH v3 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
.../bindings/arm/uniphier/cache-uniphier.txt | 48 ++
MAINTAINERS| 2 +
arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++
arch/arm/kernel/irq.c | 3 +
arch/arm/mm/Kconfig| 10 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-uniphier.c | 544 +
7 files changed, 654 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
create mode 100644 arch/arm/mm/cache-uniphier.c
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..ce6eddd
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,48 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a full-custom outer cache controller system.
+All of them have a level 2 cache controller, and some have a level 3 cache
+controller as well.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-cache"
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 3 regions: control register, revision register, operation register,
+ in this order.
+- cache-unified: specifies the cache is a unified cache.
+- cache-size: specifies the size in bytes of the cache
+- cache-sets: specifies the number of associativity sets of the cache
+- cache-line-size: specifies the line size in bytes
+- cache-level: specifies the level in the cache hierarchy. The value should
+ be 2 for L2 cache, 3 for L3 cache, etc.
+
+Optional properties:
+- next-level-cache: phandle to the next level cache if present. The next level
+ cache should be also compatible with "socionext,uniphier-system-cache".
+
+The L2 cache must exist to use the L3 cache; the cache hierarchy must be
+indicated correctly with "next-level-cache" properties.
+
+Example:
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x20>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ next-level-cache = <>;
+ };
+
+ l3: l3-cache@500c8000 {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+ cache-unified;
+ cache-size = <0x40>;
+ cache-sets = <512>;
+ cache-line-size = <256>;
+ cache-level = <3>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..e9c5dd9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1600,7 +1600,9 @@ M:Masahiro Yamada <yamada.masah...@socionext.com>
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..102e3fb
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CACHE_UNIPHIER_H
+#define __CACHE_UNIPHIER_H
+
+#include
+
+#ifdef CONFIG_CACHE_UNIPHIER
+int uniphier_cache_init(void);
+int uniphier_cache_l2_is_enabled(void);
+void uniphier_cache_l2_touch_range(unsigned long start, unsigned long end);
[PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, Now Linux 4.3-rc1 is out, so I am back to this. 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Because 2/3 highly depends on 1/3, I hope whole of this series is applied through ARM-SOC tree. Changes in v3: - Drop bogus includes Changes in v2: - Use pr_fmt() to have pr_ are automatically prefixed - Re-design to initialize the outer cache earlier in init_IRQ() - Require DT properties such as "cacne-unified", "cache-size", "cache-sets", "cache-size", "cache-line-size". - Follow "next-level-cache" property to search further outer caches Masahiro Yamada (3): ARM: uniphier: add outer cache support ARM: uniphier: rework SMP operations to use trampoline code ARM: dts: uniphier: add outer cache controller nodes .../bindings/arm/uniphier/cache-uniphier.txt | 48 ++ MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 13 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 27 + arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 13 + arch/arm/boot/dts/uniphier-proxstream2.dtsi| 16 + arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++ arch/arm/kernel/irq.c | 3 + arch/arm/mach-uniphier/Makefile| 2 +- arch/arm/mach-uniphier/headsmp.S | 43 ++ arch/arm/mach-uniphier/platsmp.c | 185 +-- arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 544 + 16 files changed, 950 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/headsmp.S create mode 100644 arch/arm/mm/cache-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] ARM: uniphier: add outer cache support
2015-09-14 15:26 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>:
> diff --git a/arch/arm/mach-uniphier/uniphier.c
> b/arch/arm/mach-uniphier/uniphier.c
> index 9be10ef..26042e3 100644
> --- a/arch/arm/mach-uniphier/uniphier.c
> +++ b/arch/arm/mach-uniphier/uniphier.c
> @@ -12,6 +12,10 @@
> * GNU General Public License for more details.
> */
>
> +#define pr_fmt(fmt)"uniphier: " fmt
> +
> +#include
> +#include
> #include
>
> static const char * const uniphier_dt_compat[] __initconst = {
This change is unnecessary. I will fix it in v3.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] ARM: uniphier: add outer cache support and rework SMP operations
2015-09-14 15:26 GMT+09:00 Masahiro Yamada <yamada.masah...@socionext.com>: > Hi Olof, > > Now Linux 4.3-rc1 is out, so I am back to this. > > 1/3: add outer cache support > 2/3: rework SMP operations > 3/3: add device tree nodes > > Because 2/3 highly depends on 1/3, I hope whole of this series > is applied through ARM-SOC tree. > > > Changes in v2: > - Use pr_fmt() to have pr_ are automatically prefixed > - Re-design to initialize the outer cache earlier in init_IRQ() > - Require DT properties such as "cacne-unified", "cache-size", > "cache-sets", "cache-size", "cache-line-size". > - Follow "next-level-cache" property to search further outer caches > This series will be replaced with v3. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
.../bindings/arm/uniphier/cache-uniphier.txt | 48 ++
MAINTAINERS| 2 +
arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++
arch/arm/kernel/irq.c | 3 +
arch/arm/mach-uniphier/uniphier.c | 4 +
arch/arm/mm/Kconfig| 10 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-uniphier.c | 544 +
8 files changed, 658 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
create mode 100644 arch/arm/mm/cache-uniphier.c
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..e0bfc91
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,48 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a full-custom outer cache controller system.
+All of them have a level 2 cache controller, and some have a level 3 cache
+controller as well.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-cache"
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 3 regions: control registers, revision registers, operation
+ registers, in this order.
+- cache-unified: specifies the cache is a unified cache.
+- cache-size: specifies the size in bytes of the cache
+- cache-sets: specifies the number of associativity sets of the cache
+- cache-line-size: specifies the line size in bytes
+- cache-level: specifies the level in the cache hierarchy. The value should
+ be 2 for L2 cache, 3 for L3 cache, etc.
+
+Optional properties:
+- next-level-cache: phandle to the next level cache if present. The next level
+ cache should be also compatible with "socionext,uniphier-system-cache".
+
+The L2 cache must exist to use the L3 cache; the cache hierarchy must be
+indicated correctly with "next-level-cache" properties.
+
+Example:
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x20>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ next-level-cache = <>;
+ };
+
+ l3: l3-cache@500c8000 {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+ cache-unified;
+ cache-size = <0x40>;
+ cache-sets = <512>;
+ cache-line-size = <256>;
+ cache-level = <3>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..e9c5dd9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1600,7 +1600,9 @@ M:Masahiro Yamada <yamada.masah...@socionext.com>
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..102e3fb
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada <yamada.masah...@socionext.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CACHE_UNIPHIER_H
+#define __CACHE_UNIPHIER_H
+
+#include
+
+#ifdef CONFIG_CACHE_UNIPHIER
+int uniphier_cache_init(void);
+int uniphier_cache_l2_is_enabled(void);
+void uniphier_cach
[PATCH v2 3/3] ARM: dts: uniphier: add outer cache controller nodes
Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 13 +
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 27 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 13 +
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 16
6 files changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..ae13469 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -55,6 +55,7 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
};
@@ -91,6 +92,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(512 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..85377b2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(768 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..96da01e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <>;
};
};
@@ -98,6 +100,31 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ interrupts = <0 190 4>, <0 191 4>;
+ cache-unified;
+ cache-size = <(2 * 1024 * 1024)>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cach
[PATCH v2 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, Now Linux 4.3-rc1 is out, so I am back to this. 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Because 2/3 highly depends on 1/3, I hope whole of this series is applied through ARM-SOC tree. Changes in v2: - Use pr_fmt() to have pr_ are automatically prefixed - Re-design to initialize the outer cache earlier in init_IRQ() - Require DT properties such as "cacne-unified", "cache-size", "cache-sets", "cache-size", "cache-line-size". - Follow "next-level-cache" property to search further outer caches Masahiro Yamada (3): ARM: uniphier: add outer cache support ARM: uniphier: rework SMP operations to use trampoline code ARM: dts: uniphier: add outer cache controller nodes .../bindings/arm/uniphier/cache-uniphier.txt | 48 ++ MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 13 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 27 + arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 13 + arch/arm/boot/dts/uniphier-proxstream2.dtsi| 16 + arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++ arch/arm/kernel/irq.c | 3 + arch/arm/mach-uniphier/Makefile| 2 +- arch/arm/mach-uniphier/headsmp.S | 43 ++ arch/arm/mach-uniphier/platsmp.c | 185 +-- arch/arm/mach-uniphier/uniphier.c | 4 + arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 544 + 17 files changed, 954 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/headsmp.S create mode 100644 arch/arm/mm/cache-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: add vendor prefix for Socionext Inc.
Hi Lee, Rob, 2015-08-25 0:11 GMT+09:00 Rob Herring <robherri...@gmail.com>: > On Mon, Aug 24, 2015 at 1:57 AM, Lee Jones <lee.jo...@linaro.org> wrote: >> On Wed, 29 Jul 2015, Masahiro Yamada wrote: >> >>> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com> >>> --- >>> >>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + >>> 1 file changed, 1 insertion(+) >> >> Patch has been around for nearly a month and is pretty trivial, so I'm >> just going to go ahead an apply it. > > Okay. I just added it now going thru my backlog, but will drop it. > > Rob > So, where has this patch gone? I've not seen it anywhere. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Arnd, Russell, 2015-08-26 21:52 GMT+09:00 Arnd Bergmann a...@arndb.de: On Wednesday 26 August 2015 10:38:59 Masahiro Yamada wrote: 2015-08-25 4:59 GMT+09:00 Arnd Bergmann a...@arndb.de: On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: Nothing. This outer cache is not a variant of l2x0/pl310. It was designed only for our SoCs from scratch. Ok, I see. Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? I do not think so. l2x0_of_init() checks L2X0_AUX_CTRL register, but the cache-uniphier does not have such register, so the boot code crashes. BTW, what makes l2x0_of_init() so special? Only L2x0/L310 and variants can be initialized directly from init_IRQ(). The only thing that is special about it is that almost everyone uses it because it is often licensed together with the Cortex-A cores from ARM. There are a few variants that are closely related (tauros3 and aurora, both from Marvell. All other outer_cache implementations (feroceon, xscale, tauros2) are for older Marvell (or Intel) cores that have since been replaced with Cortex-A cores in newer products. Moreover, outer-cache init seems to be unrelated to IRQ init. Agreed, this is also just a historic artifact, as we don't really have a place to put cache controller initialization, and the irq init callback was already there at the time when people added code to init their outer caches. It often does not matter much where you call it, but doing it early speeds up the boot time. It would be nice to unify the cache initialization a bit further, apparently only a few older platforms still call the l2x0 init manually and we can probably all convert them to the implicit configuration in one way or another. As we now have three kinds of cache controllers (l2x0, tauros2 and uniphier) that we need to support using DT, it would be nice for generalize that init sequence a bit more. A first step would be to add the tauros2 and uniphier outer cache init to the init_IRQ() function, and then have another patch that moves all the outercache initialization into a new place like arch/arm/mm/outercache.c so we don't clutter up irq.c with unrelated stuff. Russell probably also has some ideas on this topic, in doubt just do what he suggests. In my v1 patch, the outer cache init is called from .init_machine as some other SoCs do, but if moving my cache_init to init_IRQ() is acceptable, that would be better for faster boot. I will follow Arnd's suggestion in v2 unless Russell is opposed to it. Thanks! -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Linus,
2015-08-26 22:39 GMT+09:00 Linus Walleij linus.wall...@linaro.org:
On Mon, Aug 24, 2015 at 4:18 AM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
Wow it is really a custom L2$ controller. Wow. Just wow. That's
really brave, given all the problems we've seen in l2x0.
Looks like my company is crazy...
ARM Ltd. people said we are the only vendor that still uses
a custom outer cache.
+UniPhier SoCs are integrated with a level 2 cache controller that resides
+outside of the ARM cores, some of them also have a level 3 cache controller.
+
+Required properties:
+- compatible: should be one of the followings:
+ socionext,uniphier-l2-cache (L2 cache)
+ socionext,uniphier-l3-cache (L3 cache)
Refer to and use the 3.7.3 ePAPR v1.1 specification too:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
I've checked it out.
Thanks, but I had some doubts.
cache-unified and cache-level are *not* optional and should be required.
cache-unified is mentioned in 3.7.3 Internal (L1) Cache Properties
(Table 3-8),
but it is not in 3.8 Multi-level and Shared Caches (Table 3-9)
Are the rules in Table 3-8 also applied for L2?
So:
+The L2 cache must exist to use the L3 cache; adding only an L3 cache device
+node to the device tree causes the initialization failure of the whole outer
+cache system.
+
+Example:
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x8,
+ 0x506c 0x400;
cache-unified;
cache-level = 2;
+ /* Not all of UniPhier SoCs have L3 cache */
+ l3-cache@500c8000 {
+ compatible = socionext,uniphier-l3-cache;
+ reg = 0x500c8000 0x2000, 0x503c8100 0x8,
+ 0x506c8000 0x400;
cache-unified;
cache-level = 3;
(I'm just assuming this cache is unified, anything else would be baffling.)
In fact, unified/harvard is configurable thru a register of this cache
controller.
It is usually used as a unified cached, though.
Further the ePAPR spec optionally supports specifying things like the
cache size, number of sets, block size and line size, unless this can
be hard coded.
Yours,
Linus Walleij
Given that cache-level specifies the level and next-level-cache
specifies the topology,
I think socionext,uniphier-l*-cache gives redundant information.
The L2 and L3 cache controller look the same; they have the same register maps.
The differences between them are register-base, cache-size,
cache-sets, line-size,
which are specified by properties.
So,I am planning to use the same compatible for L2 and L3, like this:
l2-cache@500c {
compatible = socionext,uniphier-cache;
reg = 0x500c 0x2000, 0x503c0100 0x8,
0x506c 0x400;
cache-unified;
cache-level = 2;
next-level-cache = L2;
cache-size = 0x20;
cache-sets = 256;
cache-line-size = 128;
};
/* Not all of UniPhier SoCs have L3 cache */
l3-cache@500c8000 {
compatible = socionext,uniphier-cache;
reg = 0x500c8000 0x2000, 0x503c8100 0x8,
0x506c8000 0x400;
cache-unified;
cache-level = 3;
cache-size = 0x40;
cache-sets = 256;
cache-line-size = 256;
};
The Table 3-9 in ePAPR v1.1 says
the compatible should be cache, but I do not think it makes sense here.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Arnd, 2015-08-25 4:59 GMT+09:00 Arnd Bergmann a...@arndb.de: On Monday 24 August 2015 11:18:10 Masahiro Yamada wrote: diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000..6428289 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,30 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a level 2 cache controller that resides +outside of the ARM cores, some of them also have a level 3 cache controller. + +Required properties: +- compatible: should be one of the followings: + socionext,uniphier-l2-cache (L2 cache) + socionext,uniphier-l3-cache (L3 cache) +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control registers, revision registers, operation + registers, in this order. + +The L2 cache must exist to use the L3 cache; adding only an L3 cache device +node to the device tree causes the initialization failure of the whole outer +cache system. How much does this outer cache have in common with the l2x0/pl310 cache controller model? Nothing. This outer cache is not a variant of l2x0/pl310. It was designed only for our SoCs from scratch. Would it make sense to at least share the common entry point at l2x0_of_init() so you don't need to call it from the platform file? I do not think so. l2x0_of_init() checks L2X0_AUX_CTRL register, but the cache-uniphier does not have such register, so the boot code crashes. BTW, what makes l2x0_of_init() so special? Only L2x0/L310 and variants can be initialized directly from init_IRQ(). Moreover, outer-cache init seems to be unrelated to IRQ init. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, 2015-08-25 6:47 GMT+09:00 Olof Johansson o...@lixom.net: Hi, On Sun, Aug 23, 2015 at 7:18 PM, Masahiro Yamada yamada.masah...@socionext.com wrote: 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Timing of this is unfortunate, please resend after 4.3-rc1 is out and we can queue it up. Given that rc8 is out and the merge window has been delayed, is it still too late for 4.3-rc1? Because 2/3 highly depends on 1/3, I hope whole of this series is applied to ARM-SOC tree. Review or acked-by from Russell would be appreciated in that case. Olof, From this series, I am using ARM: uniphier: rather than ARM: UniPhier: for the subject prefixes because I noticed you often rephased so when you applied my patches. Are sub-arch names in lower cases preferable in subject prefixes? If you look at git log --no-merges --oneline arch/arm/mach-* you'll see that most platforms use either all-caps or all-lowercase. I see. But, we use UniPhier (with only U and P capitalized) in our official documents. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: uniphier: add outer cache controller nodes
Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 7 +++
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 7 +++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 7 +++
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 7 +++
6 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..2d60960 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -91,6 +91,13 @@
#size-cells = 1;
};
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x4,
+ 0x506c 0x400;
+ interrupts = 0 174 4, 0 175 4;
+ };
+
serial0: serial@54006800 {
compatible = socionext,uniphier-uart;
status = disabled;
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..02acc07 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -98,6 +98,13 @@
#size-cells = 1;
};
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x4,
+ 0x506c 0x400;
+ interrupts = 0 174 4, 0 175 4;
+ };
+
serial0: serial@54006800 {
compatible = socionext,uniphier-uart;
status = disabled;
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..084bc47 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -98,6 +98,20 @@
#size-cells = 1;
};
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x8,
+ 0x506c 0x400;
+ interrupts = 0 190 4, 0 191 4;
+ };
+
+ l3-cache@500c8000 {
+ compatible = socionext,uniphier-l3-cache;
+ reg = 0x500c8000 0x2000, 0x503c8100 0x8,
+ 0x506c8000 0x400;
+ interrupts = 0 174 4, 0 175 4;
+ };
+
serial0: serial@54006800 {
compatible = socionext,uniphier-uart;
status = disabled;
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
index 3cc90cd..e989281 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3.dtsi
@@ -120,6 +120,13 @@
0x2100 0x100;
};
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x4,
+ 0x506c 0x400;
+ interrupts = 0 174 4, 0 175 4;
+ };
+
serial0: serial@54006800 {
compatible = socionext,uniphier-uart;
status = disabled;
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
index 58067df..3ff897c 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8.dtsi
@@ -91,6 +91,13 @@
#size-cells = 1;
};
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x4,
+ 0x506c 0x400;
+ interrupts = 0 174 4, 0 175 4;
+ };
+
serial0: serial@54006800 {
compatible = socionext,uniphier-uart;
status = disabled;
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index 4c7b246..f318548 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -110,6 +110,13 @@
#size-cells = 1;
};
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2
[PATCH 0/3] ARM: uniphier: add outer cache support and rework SMP operations
1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Because 2/3 highly depends on 1/3, I hope whole of this series is applied to ARM-SOC tree. Olof, From this series, I am using ARM: uniphier: rather than ARM: UniPhier: for the subject prefixes because I noticed you often rephased so when you applied my patches. Are sub-arch names in lower cases preferable in subject prefixes? Masahiro Yamada (3): ARM: uniphier: add outer cache support ARM: uniphier: rework SMP operations to use trampoline code ARM: dts: uniphier: add outer cache controller nodes .../bindings/arm/uniphier/cache-uniphier.txt | 30 ++ MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 7 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 7 + arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 7 + arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 7 + arch/arm/boot/dts/uniphier-proxstream2.dtsi| 7 + arch/arm/include/asm/hardware/cache-uniphier.h | 40 ++ arch/arm/mach-uniphier/Makefile| 2 +- arch/arm/mach-uniphier/headsmp.S | 43 ++ arch/arm/mach-uniphier/platsmp.c | 183 ++-- arch/arm/mach-uniphier/uniphier.c | 11 + arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 518 + 16 files changed, 857 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/headsmp.S create mode 100644 arch/arm/mm/cache-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
.../bindings/arm/uniphier/cache-uniphier.txt | 30 ++
MAINTAINERS| 2 +
arch/arm/include/asm/hardware/cache-uniphier.h | 40 ++
arch/arm/mach-uniphier/uniphier.c | 11 +
arch/arm/mm/Kconfig| 10 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-uniphier.c | 518 +
7 files changed, 612 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
create mode 100644 arch/arm/mm/cache-uniphier.c
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..6428289
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,30 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a level 2 cache controller that resides
+outside of the ARM cores, some of them also have a level 3 cache controller.
+
+Required properties:
+- compatible: should be one of the followings:
+ socionext,uniphier-l2-cache (L2 cache)
+ socionext,uniphier-l3-cache (L3 cache)
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 3 regions: control registers, revision registers, operation
+ registers, in this order.
+
+The L2 cache must exist to use the L3 cache; adding only an L3 cache device
+node to the device tree causes the initialization failure of the whole outer
+cache system.
+
+Example:
+ l2-cache@500c {
+ compatible = socionext,uniphier-l2-cache;
+ reg = 0x500c 0x2000, 0x503c0100 0x8,
+ 0x506c 0x400;
+ };
+
+ /* Not all of UniPhier SoCs have L3 cache */
+ l3-cache@500c8000 {
+ compatible = socionext,uniphier-l3-cache;
+ reg = 0x500c8000 0x2000, 0x503c8100 0x8,
+ 0x506c8000 0x400;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a4fbfc8..62e0784 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1578,7 +1578,9 @@ M:Masahiro Yamada yamada.masah...@socionext.com
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..641d32f
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada yamada.masah...@socionext.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __CACHE_UNIPHIER_H
+#define __CACHE_UNIPHIER_H
+
+#ifdef CONFIG_CACHE_UNIPHIER
+int uniphier_cache_init(void);
+int uniphier_cache_init_locked(void);
+void uniphier_cache_touch_range(unsigned long start, unsigned long end);
+#else
+static inline int uniphier_cache_init(void)
+{
+ return -ENODEV;
+}
+
+static inline int uniphier_cache_init_locked(void)
+{
+ return -ENODEV;
+}
+
+static inline void uniphier_cache_touch_range(unsigned long start,
+ unsigned long end)
+{
+}
+
+#endif
+
+#endif /* __CACHE_UNIPHIER_H */
diff --git a/arch/arm/mach-uniphier/uniphier.c
b/arch/arm/mach-uniphier/uniphier.c
index 9be10ef..6aed136 100644
--- a/arch/arm/mach-uniphier/uniphier.c
+++ b/arch/arm/mach-uniphier/uniphier.c
@@ -12,6 +12,8 @@
* GNU General Public License for more details.
*/
+#include linux/of_platform.h
+#include asm/hardware/cache-uniphier.h
#include asm/mach/arch.h
static const char * const uniphier_dt_compat[] __initconst = {
@@ -25,6 +27,15 @@ static const char * const uniphier_dt_compat[] __initconst =
{
NULL,
};
+static void __init uniphier_init_machine(void)
+{
+ if (uniphier_cache_init())
+ pr_warn(outer cache
Re: [PATCH 1/3] ARM: uniphier: add outer cache support
Hi Joe, 2015-08-24 11:29 GMT+09:00 Joe Perches j...@perches.com: On Mon, 2015-08-24 at 11:18 +0900, Masahiro Yamada wrote: This commit adds support for UniPhier outer cache controller. All the UniPhier SoCs are equipped with the L2 cache, while the L3 cache is currently only integrated on PH1-Pro5 SoC. style trivia: You might add and use #define pr_fmt(fmt) uniphier: fmt before any other #include so all of the pr_level uses are automatically prefixed. I did not know that. Thanks! I will do so for the whole series in v2. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: add vendor prefix for Socionext Inc.
Hi Grant, I guess this patch should go in thru the devicetree subsystem. (or ARM-SOC?) It is really trivial, so could you apply it for 4.3-rc1, please? 2015-07-29 18:45 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com: Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index d444757..5ab8f6b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -192,6 +192,7 @@ sitronixSitronix Technology Corporation skyworks Skyworks Solutions, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. +socionext Socionext Inc. solidrun SolidRun solomonSolomon Systech Limited sony Sony Corporation -- 1.9.1 -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes
This SoC is integrated with 4 Cortex-A9 cores. The GIC bindings
says that the bits[15:8] of the 3rd cell of the interrupts property
represents PPI interrupt CPU mask. Because the timer interrupts are
wired to all of the 4 cores, bits[15:8] should be set to 0xf.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ccf795a..4c7b246 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -249,14 +249,14 @@
timer@6200 {
compatible = arm,cortex-a9-global-timer;
reg = 0x6200 0x20;
- interrupts = 1 11 0x304;
+ interrupts = 1 11 0xf04;
clocks = arm_timer_clk;
};
timer@6600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x6600 0x20;
- interrupts = 1 13 0x304;
+ interrupts = 1 13 0xf04;
clocks = arm_timer_clk;
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes
This SoC is integrated with 4 Cortex-A9 cores. The GIC bindings
document says that the bits[15:8] of the 3rd cell of the interrupts
property represents PPI interrupt CPU mask. Because the timer
interrupts are wired to all of the 4 cores, bits[15:8] should be set
to 0xf.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
Changes in v2:
- Fix git-description
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
index ccf795a..4c7b246 100644
--- a/arch/arm/boot/dts/uniphier-proxstream2.dtsi
+++ b/arch/arm/boot/dts/uniphier-proxstream2.dtsi
@@ -249,14 +249,14 @@
timer@6200 {
compatible = arm,cortex-a9-global-timer;
reg = 0x6200 0x20;
- interrupts = 1 11 0x304;
+ interrupts = 1 11 0xf04;
clocks = arm_timer_clk;
};
timer@6600 {
compatible = arm,cortex-a9-twd-timer;
reg = 0x6600 0x20;
- interrupts = 1 13 0x304;
+ interrupts = 1 13 0xf04;
clocks = arm_timer_clk;
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: UniPhier: fix PPI interrupt CPU mask of timer nodes
2015-08-19 14:45 GMT+09:00 Masahiro Yamada yamada.masah...@socionext.com: This SoC is integrated with 4 Cortex-A9 cores. The GIC bindings says that the bits[15:8] of the 3rd cell of the interrupts property represents PPI interrupt CPU mask. Because the timer interrupts are wired to all of the 4 cores, bits[15:8] should be set to 0xf. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com This has been superseded by v2. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: UniPhier: add ProXstream2 and PH1-LD6b SoC/board support
Hi Olof,
2015-08-13 18:09 GMT+09:00 Olof Johansson o...@lixom.net:
On Wed, Aug 12, 2015 at 3:14 PM, Masahiro Yamada
yamada.masah...@socionext.com wrote:
Hi Olof,
2015-08-11 22:07 GMT+09:00 Olof Johansson o...@lixom.net:
Hi,
On Tue, Aug 04, 2015 at 08:21:04PM +0900, Masahiro Yamada wrote:
Initial version of DTSI for ProXstream2 and PH1-LD6b and DTS for
PH1-LD6b reference board.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 105 +++
arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi| 67 +++
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 273
4 files changed, 447 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts
create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi
create mode 100644 arch/arm/boot/dts/uniphier-proxstream2.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 246473a..6eb3f2f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -645,7 +645,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \
uniphier-ph1-sld3-ref.dtb \
uniphier-ph1-ld4-ref.dtb \
uniphier-ph1-pro4-ref.dtb \
- uniphier-ph1-sld8-ref.dtb
+ uniphier-ph1-sld8-ref.dtb \
+ uniphier-ph1-ld6b-ref.dtb
Please always add entries here sorted, don't just append. I've fixed it
up for you this time.
Please do not do that (without my ack).
I'm not going to go get your ack for something as trivial as this. We
do make sure subplatform maintainers are in the loop and get to review
code that touches their platform, but in this case this was a shared
makefile and there were no functional changes.
It was already sorted from old SoC to new SoC.
Sorting chronologically (in other words, in the order of chip ID)
makes more sense than sorting alphabetically.
No, it doesn't. All entries in these files should be sorted
alphabetically. Sometimes we miss out on it, but it's the goal.
I did not know that, my apology.
If you sort chronologically it's impossible for anyone but people
intimately familiar with UniPhier's product history to add any new
entries in the right location. Also, since it's likely that newer
chips will be introduced over time, new entries are likely to just be
appends instead of inserted at more varied locations in the files.
Append-only additions are more likely to have add/add conflicts, which
is why we're preferring alphabetical sort order in the first place.
This is true for various entries as well as arch/arm/boot/dts/Makefile.
I am wondering how far we should stick to alphabetical sorting.
For example, do you recommend OF compatible tables should be sorted
alphabetically?
arch/arm/mach-uniphier/uniphier.c:
static const char * const uniphier_dt_compat[] __initconst = {
socionext,ph1-sld3,
socionext,ph1-ld4,
socionext,ph1-pro4,
socionext,ph1-sld8,
socionext,ph1-pro5,
socionext,proxstream2,
socionext,ph1-ld6b,
NULL,
};
This table (only containing SoC names) is currently sorted
chronologically, and the logic
is the same as arch/arm/boot/dts/Makefile.
This file belongs to my maintainer-ship, but I just wonder
which sorting rule, chronologically or alphabetically, is better in general.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: UniPhier: add ProXstream2 and PH1-LD6b SoC/board support
Hi Olof, 2015-08-11 22:07 GMT+09:00 Olof Johansson o...@lixom.net: Hi, On Tue, Aug 04, 2015 at 08:21:04PM +0900, Masahiro Yamada wrote: Initial version of DTSI for ProXstream2 and PH1-LD6b and DTS for PH1-LD6b reference board. Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com --- arch/arm/boot/dts/Makefile | 3 +- arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts | 105 +++ arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi| 67 +++ arch/arm/boot/dts/uniphier-proxstream2.dtsi | 273 4 files changed, 447 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b-ref.dts create mode 100644 arch/arm/boot/dts/uniphier-ph1-ld6b.dtsi create mode 100644 arch/arm/boot/dts/uniphier-proxstream2.dtsi diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 246473a..6eb3f2f 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -645,7 +645,8 @@ dtb-$(CONFIG_ARCH_UNIPHIER) += \ uniphier-ph1-sld3-ref.dtb \ uniphier-ph1-ld4-ref.dtb \ uniphier-ph1-pro4-ref.dtb \ - uniphier-ph1-sld8-ref.dtb + uniphier-ph1-sld8-ref.dtb \ + uniphier-ph1-ld6b-ref.dtb Please always add entries here sorted, don't just append. I've fixed it up for you this time. Please do not do that (without my ack). It was already sorted from old SoC to new SoC. Sorting chronologically (in other words, in the order of chip ID) makes more sense than sorting alphabetically. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] dtb: Create a common home for cross-architecture dtsi files.
Hi 2015-08-04 1:06 GMT+09:00 Ian Campbell ian.campb...@citrix.com: Commit 9ccd608070b6 (arm64: dts: add device tree for ARM SMM-A53x2 on LogicTile Express 20MG) added a new dts file to arch/arm64 which included ../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi, i.e. a .dtsi supplied by arch/arm. Unfortunately this causes some issues for the split device tree repository[0], since things get moved around there. In that context the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts while the include is at src/arm/vexpress-v2m-rs1.dtsi. The sharing of the .dtsi is legitimate since the baseboard is the same for various vexpress systems whatever processor they use. Rather than using ../../ tricks to pickup .dtsi files from another arch this patch creates a new directory kernel/dts as a home for such cross-arch .dtsi files and arranges for it to be in the include path for both dtc and cpp. The dtsi file itself is moved into a vendor subdir in this case arm (the vendor, not the ARCH=). Question: If this patch is applied, which directory will be created in device-tree-rebasing? src/kernel/, src/common/, or something else? Either will do, of course. Another nit: I just noticed a period at the end of the commit subject. Re-post would not be needed only for such a minor thing, but please try best to remember to drop it when this patch is applied. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] ARM: dts: UniPhier: add reference daughter board
This is used as a base board for reference core modules.
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 1 +
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 1 +
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 1 +
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 1 +
arch/arm/boot/dts/uniphier-ref-daughter.dtsi | 50
5 files changed, 54 insertions(+)
create mode 100644 arch/arm/boot/dts/uniphier-ref-daughter.dtsi
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index 5d24c57..bfd3bb8 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -44,6 +44,7 @@
/dts-v1/;
/include/ uniphier-ph1-ld4.dtsi
+/include/ uniphier-ref-daughter.dtsi
/include/ uniphier-support-card.dtsi
/ {
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index 26c18ac..69a5b7d 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -44,6 +44,7 @@
/dts-v1/;
/include/ uniphier-ph1-pro4.dtsi
+/include/ uniphier-ref-daughter.dtsi
/include/ uniphier-support-card.dtsi
/ {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
index cb6e9aa..1a440f8 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts
@@ -44,6 +44,7 @@
/dts-v1/;
/include/ uniphier-ph1-sld3.dtsi
+/include/ uniphier-ref-daughter.dtsi
/include/ uniphier-support-card.dtsi
/ {
diff --git a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
index a40a0fb..955d417 100644
--- a/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts
@@ -44,6 +44,7 @@
/dts-v1/;
/include/ uniphier-ph1-sld8.dtsi
+/include/ uniphier-ref-daughter.dtsi
/include/ uniphier-support-card.dtsi
/ {
diff --git a/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
b/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
new file mode 100644
index 000..3d29d28
--- /dev/null
+++ b/arch/arm/boot/dts/uniphier-ref-daughter.dtsi
@@ -0,0 +1,50 @@
+/*
+ * Device Tree Source for UniPhier Reference Daughter Board
+ *
+ * Copyright (C) 2015 Masahiro Yamada yamada.masah...@socionext.com
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+i2c0 {
+ eeprom {
+ compatible = microchip,24lc128;
+ reg = 0x50;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ARM: dts: UniPhier: add I2C controller device nodes
Add I2C controller device nodes for PH1-sLD3, PH1-LD4, PH1-sLD8
(FIFO-less I2C) and PH1-Pro4 (FIFO-builtin I2C).
Signed-off-by: Masahiro Yamada yamada.masah...@socionext.com
---
arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts | 8 +++
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 58
arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts | 10
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 82 +
arch/arm/boot/dts/uniphier-ph1-sld3-ref.dts | 9
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 61 +
arch/arm/boot/dts/uniphier-ph1-sld8-ref.dts | 8 +++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 58
arch/arm/boot/dts/uniphier-pinctrl.dtsi | 20 +++
9 files changed, 314 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
index 7ac053d..5d24c57 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4-ref.dts
@@ -65,6 +65,10 @@
serial1 = serial1;
serial2 = serial2;
serial3 = serial3;
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
};
};
@@ -93,6 +97,10 @@
status = okay;
};
+i2c0 {
+ status = okay;
+};
+
usb0 {
status = okay;
};
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index 4add90b..a6a185f 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -70,6 +70,12 @@
compatible = fixed-clock;
clock-frequency = 36864000;
};
+
+ iobus_clk: iobus_clk {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1;
+ };
};
soc {
@@ -129,6 +135,58 @@
fifo-size = 64;
};
+ i2c0: i2c@5840 {
+ compatible = socionext,uniphier-i2c;
+ status = disabled;
+ reg = 0x5840 0x40;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c0;
+ interrupts = 0 41 1;
+ clocks = iobus_clk;
+ clock-frequency = 10;
+ };
+
+ i2c1: i2c@5848 {
+ compatible = socionext,uniphier-i2c;
+ status = disabled;
+ reg = 0x5848 0x40;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c1;
+ interrupts = 0 42 1;
+ clocks = iobus_clk;
+ clock-frequency = 10;
+ };
+
+ /* chip-internal connection for DMD */
+ i2c2: i2c@5850 {
+ compatible = socionext,uniphier-i2c;
+ reg = 0x5850 0x40;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c2;
+ interrupts = 0 43 1;
+ clocks = iobus_clk;
+ clock-frequency = 40;
+ };
+
+ i2c3: i2c@5858 {
+ compatible = socionext,uniphier-i2c;
+ status = disabled;
+ reg = 0x5858 0x40;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c3;
+ interrupts = 0 44 1;
+ clocks = iobus_clk;
+ clock-frequency = 10;
+ };
+
system-bus-controller-misc@5980 {
compatible =
socionext,uniphier-system-bus-controller-misc,
syscon;
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
index b669d32..26c18ac 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4-ref.dts
@@ -65,6 +65,12 @@
serial1 = serial1;
serial2 = serial2;
serial3 = serial3;
+ i2c0 = i2c0;
+ i2c1 = i2c1;
+ i2c2 = i2c2;
+ i2c3 = i2c3;
+ i2c5 = i2c5;
+ i2c6 = i2c6;
};
};
@@ -93,6 +99,10 @@
status = okay;
};
+i2c0
