Skip to contentSkip to conversation

MIPS Boston Development Board Support

PATCH New Paul Burton 6 participants 27 messages Sep 8, 2016 – Oct 4, 2016

Subsystems (8)
lore
Share & tools
lore
#0 lore raw

v7 cover MIPS Boston Development Board Support

This series introduces initial support for the MIPS Boston, an FPGA based development board & successor to the older Malta board. Further peripheral work is needed but this introduces the basics.

This can be tested in a currently out-of-tree QEMU port if desired. Please see the included doc/README.boston for details about how to do so.

Paul Burton (12):
clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled
serial: ns16550: Support clocks via phandle
dt-bindings: Add interrupt-controller/mips-gic.h header
pci: xilinx: Add a driver for Xilinx AXI to PCIe bridge
pci: Flip condition for detecting non-PCI parent devices
net: pch_gbe: Use dm_pci_map_bar to discover MMIO base
net: pch_gbe: Make 64 bit safe
dm: regmap: Implement simple regmap_read & regmap_write
dm: core: Match compatible strings in order of priority
dm: syscon: Provide a generic syscon driver
clk: boston: Providea simple driver for Boston board clocks
boston: Introduce support for the MIPS Boston development board

 arch/mips/Kconfig                                  |  18 ++
 arch/mips/dts/Makefile                             |   1 +
 arch/mips/dts/img,boston.dts                       | 222 +++++++++++++++++++++
 board/imgtec/boston/Kconfig                        |  16 ++
 board/imgtec/boston/MAINTAINERS                    |   6 +
 board/imgtec/boston/Makefile                       |   9 +
 board/imgtec/boston/boston-lcd.h                   |  21 ++
 board/imgtec/boston/boston-regs.h                  |  26 +++
 board/imgtec/boston/checkboard.c                   |  30 +++
 board/imgtec/boston/ddr.c                          |  30 +++
 board/imgtec/boston/lowlevel_init.S                |  56 ++++++
 configs/boston32r2_defconfig                       |  41 ++++
 configs/boston32r2el_defconfig                     |  42 ++++
 configs/boston64r2_defconfig                       |  41 ++++
 configs/boston64r2el_defconfig                     |  42 ++++
 doc/README.boston                                  |  58 ++++++
 drivers/clk/Kconfig                                |   8 +
 drivers/clk/Makefile                               |   1 +
 drivers/clk/clk_boston.c                           |  97 +++++++++
 drivers/core/lists.c                               |  78 ++++----
 drivers/core/regmap.c                              |  20 ++
 drivers/core/syscon-uclass.c                       |  11 +
 drivers/net/pch_gbe.c                              |  28 ++-
 drivers/pci/Kconfig                                |   7 +
 drivers/pci/Makefile                               |   1 +
 drivers/pci/pci-uclass.c                           |   2 +-
 drivers/pci/pcie_xilinx.c                          | 220 ++++++++++++++++++++
 drivers/serial/ns16550.c                           |  21 +-
 include/clk.h                                      |   2 +-
 include/configs/boston.h                           |  81 ++++++++
 include/dt-bindings/clock/boston-clock.h           |  13 ++
 .../dt-bindings/interrupt-controller/mips-gic.h    |   9 +
 32 files changed, 1201 insertions(+), 57 deletions(-)
 create mode 100644 arch/mips/dts/img,boston.dts
 create mode 100644 board/imgtec/boston/Kconfig
 create mode 100644 board/imgtec/boston/MAINTAINERS
 create mode 100644 board/imgtec/boston/Makefile
 create mode 100644 board/imgtec/boston/boston-lcd.h
 create mode 100644 board/imgtec/boston/boston-regs.h
 create mode 100644 board/imgtec/boston/checkboard.c
 create mode 100644 board/imgtec/boston/ddr.c
 create mode 100644 board/imgtec/boston/lowlevel_init.S
 create mode 100644 configs/boston32r2_defconfig
 create mode 100644 configs/boston32r2el_defconfig
 create mode 100644 configs/boston64r2_defconfig
 create mode 100644 configs/boston64r2el_defconfig
 create mode 100644 doc/README.boston
 create mode 100644 drivers/clk/clk_boston.c
 create mode 100644 drivers/pci/pcie_xilinx.c
 create mode 100644 include/configs/boston.h
 create mode 100644 include/dt-bindings/clock/boston-clock.h
 create mode 100644 include/dt-bindings/interrupt-controller/mips-gic.h
Signature · 1 line
2.9.3
#1 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled. Provide the dummies when this is not the case in order to avoid build failures.

---

Changes in v7: None
Changes in v6:
- New patch

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/clk.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/clk.h +1 -1
index dc18b03..9b24522 100644
@@ -59,7 +59,7 @@ struct clk {
 	unsigned long id;
 };
 
-#if CONFIG_IS_ENABLED(OF_CONTROL)
+#if CONFIG_IS_ENABLED(OF_CONTROL) && CONFIG_IS_ENABLED(CLK)
 struct phandle_2_cell;
 int clk_get_by_index_platdata(struct udevice *dev, int index,
 			      struct phandle_2_cell *cells, struct clk *clk);
Signature · 1 line
2.9.3
#2 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

2016-09-08 15:47 GMT+09:00 Paul Burton <[email protected]>:

Quoted 2 lines

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc.

Quoted 2 lines

Provide the dummies when this is
not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?

Signature · 2 lines
Best Regards
Masahiro Yamada
#3 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

Quoted 7 lines · Masahiro Yamada

2016-09-08 15:47 GMT+09:00 Paul Burton <[email protected]>:

Quoted 2 lines

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc.

Hi Masahiro,

Yes, I agree. To be clear though, this patch doesn't add any new stub functions it simply makes the conditions for the existing ones being provided match the conditions for the real implementations not being provided.

Quoted 4 lines
Quoted 2 lines

Provide the dummies when this is
not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?

In general, I presume because they aren't used.

In the specific case I'm using clk_get_by_index for (drivers/serial/ns16550.c in patch 2 of this series) the fact that the dummy clk_get_by_index always returns an error will cause the compiler to optimise out a call to clk_get_rate so any dummy implementation provided for it wouldn't really get used.

Thanks,
Paul

#4 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

Hi Paul,

2016-09-09 17:01 GMT+09:00 Paul Burton <[email protected]>:

Quoted 21 lines · Masahiro Yamada
Quoted 7 lines

2016-09-08 15:47 GMT+09:00 Paul Burton <[email protected]>:

Quoted 2 lines

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc.

Hi Masahiro,

Yes, I agree. To be clear though, this patch doesn't add any new stub functions it simply makes the conditions for the existing ones being provided match the conditions for the real implementations not being provided.

Quoted 4 lines
Quoted 2 lines

Provide the dummies when this is
not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?

Quoted 7 lines

In general, I presume because they aren't used.

In the specific case I'm using clk_get_by_index for (drivers/serial/ns16550.c in patch 2 of this series) the fact that the dummy clk_get_by_index always returns an error will cause the compiler to optimise out a call to clk_get_rate so any dummy implementation provided for it wouldn't really get used.

I see, but I do not think it is a good idea to rely on the optimization by compiler in this case.

Could you add stubs for other APIs, please?

Signature · 2 lines
Best Regards
Masahiro Yamada
#5 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

Quoted 32 lines · Masahiro Yamada

Hi Paul,

2016-09-09 17:01 GMT+09:00 Paul Burton <[email protected]>:

Quoted 21 lines · Masahiro Yamada
Quoted 7 lines

2016-09-08 15:47 GMT+09:00 Paul Burton <[email protected]>:

Quoted 2 lines

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc.

Hi Masahiro,

Yes, I agree. To be clear though, this patch doesn't add any new stub functions it simply makes the conditions for the existing ones being provided match the conditions for the real implementations not being provided.

Quoted 4 lines
Quoted 2 lines

Provide the dummies when this is
not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?

Quoted 7 lines

In general, I presume because they aren't used.

In the specific case I'm using clk_get_by_index for (drivers/serial/ns16550.c in patch 2 of this series) the fact that the dummy clk_get_by_index always returns an error will cause the compiler to optimise out a call to clk_get_rate so any dummy implementation provided for it wouldn't really get used.

Quoted 4 lines

I see, but I do not think it is a good idea to rely on the optimization by compiler in this case.

Could you add stubs for other APIs, please?

Hi Masahiro,

I don't mind doing that if it's deemed the right approach, but I see it as very much a separate change to this patch which fixes the condition for providing the existing stubs so would like if we can consider it separately.

As to whether providing stubs for the other functions is correct - I'm not so sure. Right now, code that makes use of the clock functions but can also function without CONFIG_CLK will either:

- Correctly check for errors from the clk_get_* functions and see
calls to the other clock functions get optimised out. This is what happens in the ns16550 code after my patch 2 of this series, and it is also the case for other code already in U-Boot (eg. drivers/usb/host/ehci-generic.c).

- Get it wrong, not check for errors from clk_get_* properly & get a
fairly easy to track down link error when building U-Boot.

If we add stub functions for the rest of the clk_* functions then that second case would become a runtime error rather than a link time one, and could be missed or overlooked much more easily. If we were to make the stubs do something like the Linux BUILD_BUG_ON macro then that would solve that problem, but would require all users of clk_ functions to #ifdef on CONFIG_CLK. So I actually think the current situation isn't so bad.

Simon: as author of this clock code, what was your intent here?

Thanks,
Paul

#6 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

Hi Paul,

2016-09-12 0:14 GMT+09:00 Paul Burton <[email protected]>:

Quoted 58 lines · Masahiro Yamada
Quoted 32 lines

Hi Paul,

2016-09-09 17:01 GMT+09:00 Paul Burton <[email protected]>:

Quoted 21 lines · Masahiro Yamada
Quoted 7 lines

2016-09-08 15:47 GMT+09:00 Paul Burton <[email protected]>:

Quoted 2 lines

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc.

Hi Masahiro,

Yes, I agree. To be clear though, this patch doesn't add any new stub functions it simply makes the conditions for the existing ones being provided match the conditions for the real implementations not being provided.

Quoted 4 lines
Quoted 2 lines

Provide the dummies when this is
not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?

Quoted 7 lines

In general, I presume because they aren't used.

In the specific case I'm using clk_get_by_index for (drivers/serial/ns16550.c in patch 2 of this series) the fact that the dummy clk_get_by_index always returns an error will cause the compiler to optimise out a call to clk_get_rate so any dummy implementation provided for it wouldn't really get used.

Quoted 4 lines

I see, but I do not think it is a good idea to rely on the optimization by compiler in this case.

Could you add stubs for other APIs, please?

Hi Masahiro,

I don't mind doing that if it's deemed the right approach, but I see it as very much a separate change to this patch which fixes the condition for providing the existing stubs so would like if we can consider it separately.

As to whether providing stubs for the other functions is correct - I'm not so sure. Right now, code that makes use of the clock functions but can also function without CONFIG_CLK will either:

- Correctly check for errors from the clk_get_* functions and see
calls to the other clock functions get optimised out. This is what happens in the ns16550 code after my patch 2 of this series, and it is also the case for other code already in U-Boot (eg. drivers/usb/host/ehci-generic.c).

- Get it wrong, not check for errors from clk_get_* properly & get a
fairly easy to track down link error when building U-Boot.

Quoted 7 lines

If we add stub functions for the rest of the clk_* functions then that second case would become a runtime error rather than a link time one, and could be missed or overlooked much more easily. If we were to make the stubs do something like the Linux BUILD_BUG_ON macro then that would solve that problem, but would require all users of clk_ functions to #ifdef on CONFIG_CLK. So I actually think the current situation isn't so bad.

OK, thanks for explaining this.
(For the case, perhaps drivers that need clk can have
"depends on CLK" in Kconfig. Anyway, this should be considered separately.)

So, let's go this series as it is.

Signature · 2 lines
Best Regards
Masahiro Yamada
#7 lore raw

PATCH v7 1/12 clk: Use dummy clk_get_by_* functions when CONFIG_CLK is disabled

In reply to Masahiro Yamada
Quoted 26 lines · Masahiro Yamada

Hi Paul,

2016-09-09 17:01 GMT+09:00 Paul Burton <[email protected]>:

Quoted 23 lines · Masahiro Yamada
Quoted 7 lines

2016-09-08 15:47 GMT+09:00 Paul Burton <[email protected]>:

Quoted 2 lines

The implementations of clk_get_by_index & clk_get_by_name are only available when CONFIG_CLK is enabled.

Unless I am missing something,
I think this statement also applies to other clk API functions such as clk_request(), clk_free(), clk_get_rate(), etc.

Hi Masahiro,

Yes, I agree. To be clear though, this patch doesn't add any new stub functions it simply makes the conditions for the existing ones being provided match the conditions for the real implementations not being provided.

Quoted 4 lines
Quoted 2 lines

Provide the dummies when this is
not the case in order to avoid build failures.

Why are other functions OK without dummy stubs?

In general, I presume because they aren't used.

Quoted 8 lines
Quoted 5 lines

In the specific case I'm using clk_get_by_index for (drivers/serial/ns16550.c in patch 2 of this series) the fact that the dummy clk_get_by_index always returns an error will cause the compiler to optimise out a call to clk_get_rate so any dummy implementation provided for it wouldn't really get used.

I see, but I do not think it is a good idea to rely on the optimization by compiler in this case.

FWIW, I'm pretty sure that the Linux kernel relies on exactly the same technique with success.

#8 lore raw

PATCH v7 2/12 serial: ns16550: Support clocks via phandle

In reply to Paul Burton

Previously ns16550 compatible UARTs probed via device tree have needed their device tree nodes to contain a clock-frequency property. An alternative to this commonly used with Linux is to reference a clock via a phandle. This patch allows U-Boot to support that, retrieving the clock frequency by probing the appropriate clock device.

For example, a system might choose to provide the UART base clock as a reference to a clock common to multiple devices:

  sys_clk: clock {
    compatible = "fixed-clock";
    #clock-cells = <0>;
    clock-frequency = <10000000>;
  };

  uart0: uart at 10000000 {
    compatible = "ns16550a";
    reg = <0x10000000 0x1000>;
    clocks = <&sys_clk>;
  };

  uart1: uart at 10000000 {
    compatible = "ns16550a";
    reg = <0x10001000 0x1000>;
    clocks = <&sys_clk>;
  };

This removes the need for the frequency information to be duplicated in multiple nodes and allows the device tree to be more descriptive of the system.

---

Changes in v7:
- Check clk_get_rate return for error values

Changes in v6:
- Ignore -ENOSYS from clk_get_by_index too, for systems with CONFIG_CLK=n

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Propogate non-ENODEV errors from clk_get_by_index

 drivers/serial/ns16550.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)
drivers/serial/ns16550.c +18 -3
index 88fca15..3f6ea4d 100644
@@ -5,6 +5,7 @@
  */
 
 #include <common.h>
+#include <clk.h>
 #include <dm.h>
 #include <errno.h>
 #include <fdtdec.h>
@@ -352,6 +353,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 {
 	struct ns16550_platdata *plat = dev->platdata;
 	fdt_addr_t addr;
+	struct clk clk;
+	int err;
 
 	/* try Processor Local Bus device first */
 	addr = dev_get_addr(dev);
@@ -397,9 +400,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 				     "reg-offset", 0);
 	plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
 					 "reg-shift", 0);
-	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
-				     "clock-frequency",
-				     CONFIG_SYS_NS16550_CLK);
+
+	err = clk_get_by_index(dev, 0, &clk);
+	if (!err) {
+		err = clk_get_rate(&clk);
+		if (!IS_ERR_VALUE(err))
+			plat->clock = err;
+	} else if (err != -ENODEV && err != -ENOSYS) {
+		debug("ns16550 failed to get clock\n");
+		return err;
+	}
+
+	if (!plat->clock)
+		plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+					     "clock-frequency",
+					     CONFIG_SYS_NS16550_CLK);
 	if (!plat->clock) {
 		debug("ns16550 clock not defined\n");
 		return -EINVAL;
Signature · 1 line
2.9.3
#9 lore raw

PATCH v7 2/12 serial: ns16550: Support clocks via phandle

Hello,

I found that this commit breaks serial?ns16550 driver on ARC.
I have investigated the issue and found that it is because ARC timer node in device tree doesn't refer to any clock devices.?

In such case clk_get_by_index() returns -ENOENT error, but neither -ENODEV nor -ENOSYS (as CONFIG_CLK is enabled for ARC). So the error is not ignored and we exit with error instead of trying to get "clock-frequency" property from the device tree.

Thus I wonder why we ignore only ENOSYS and ENODEV errors and exit if any other error code appears? As shown in my example such behavior can lead to breakages.?
What should we do if ENOENT occurs??

Thanks.

Quoted 97 lines · Paul Burton

Previously ns16550 compatible UARTs probed via device tree have needed their device tree nodes to contain a clock-frequency property. An alternative to this commonly used with Linux is to reference a clock via a phandle. This patch allows U-Boot to support that, retrieving the clock frequency by probing the appropriate clock device.

For example, a system might choose to provide the UART base clock as a reference to a clock common to multiple devices:

? sys_clk: clock {
????compatible = "fixed-clock";
????#clock-cells = <0>;
????clock-frequency = <10000000>;
? };

? uart0: uart at 10000000 {
????compatible = "ns16550a";
????reg = <0x10000000 0x1000>;
????clocks = <&sys_clk>;
? };

? uart1: uart at 10000000 {
????compatible = "ns16550a";
????reg = <0x10001000 0x1000>;
????clocks = <&sys_clk>;
? };

This removes the need for the frequency information to be duplicated in multiple nodes and allows the device tree to be more descriptive of the system.

---

Changes in v7:
- Check clk_get_rate return for error values

Changes in v6:
- Ignore -ENOSYS from clk_get_by_index too, for systems with CONFIG_CLK=n

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Propogate non-ENODEV errors from clk_get_by_index

?drivers/serial/ns16550.c | 21 ++++++++++++++++++--- ?1 file changed, 18 insertions(+), 3 deletions(-)

drivers/serial/ns16550.c +0 -0
index 88fca15..3f6ea4d 100644
@@ -5,6 +5,7 @@

? */
?
?#include <common.h>
+#include <clk.h>
?#include <dm.h>
?#include <errno.h>
?#include <fdtdec.h>

drivers/serial/ns16550.c +2 -0
@@ -352,6 +353,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 ?{
 ?	struct ns16550_platdata *plat = dev->platdata;
 ?	fdt_addr_t addr;
+	struct clk clk;
+	int err;

?
? /* try Processor Local Bus device first */
? addr = dev_get_addr(dev);

drivers/serial/ns16550.c +15 -3
@@ -397,9 +400,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 ?				?????"reg-offset", 0);
 ?	plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
 ?					?"reg-shift", 0);
-	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
-				?????"clock-frequency",
-				?????CONFIG_SYS_NS16550_CLK);
+
+	err = clk_get_by_index(dev, 0, &clk);
+	if (!err) {
+		err = clk_get_rate(&clk);
+		if (!IS_ERR_VALUE(err))
+			plat->clock = err;
+	} else if (err != -ENODEV && err != -ENOSYS) {
+		debug("ns16550 failed to get clock\n");
+		return err;
+	}
+
+	if (!plat->clock)
+		plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+					?????"clock-frequency",
+					?????CONFIG_SYS_NS16550_CLK);
 ?	if (!plat->clock) {
 ?		debug("ns16550 clock not defined\n");
 ?		return -EINVAL;
Signature · 2 lines
Best regards,
Vlad Zakharov <[email protected]>
#10 lore raw

PATCH v7 2/12 serial: ns16550: Support clocks via phandle

In reply to Paul Burton

Hello,

I found that this commit breaks serial ns16550 driver on ARC.
I have investigated the issue and found that it is because ARC timer node in device tree doesn't refer to any clock devices.?

In such case clk_get_by_index() returns -ENOENT error, but neither -ENODEV nor -ENOSYS (as CONFIG_CLK is enabled for ARC). So the error is not ignored and we exit with error instead of trying to get "clock-frequency" property from the device tree.

Thus I wonder why we ignore only ENOSYS and ENODEV errors and exit if any other error code appears? As shown in my example such behavior can lead to breakages.?
What should we do if ENOENT occurs??

Thanks.

Quoted 97 lines · Paul Burton

Previously ns16550 compatible UARTs probed via device tree have needed their device tree nodes to contain a clock-frequency property. An alternative to this commonly used with Linux is to reference a clock via a phandle. This patch allows U-Boot to support that, retrieving the clock frequency by probing the appropriate clock device.

For example, a system might choose to provide the UART base clock as a reference to a clock common to multiple devices:

? sys_clk: clock {
????compatible = "fixed-clock";
????#clock-cells = <0>;
????clock-frequency = <10000000>;
? };

? uart0: uart at 10000000 {
????compatible = "ns16550a";
????reg = <0x10000000 0x1000>;
????clocks = <&sys_clk>;
? };

? uart1: uart at 10000000 {
????compatible = "ns16550a";
????reg = <0x10001000 0x1000>;
????clocks = <&sys_clk>;
? };

This removes the need for the frequency information to be duplicated in multiple nodes and allows the device tree to be more descriptive of the system.

---

Changes in v7:
- Check clk_get_rate return for error values

Changes in v6:
- Ignore -ENOSYS from clk_get_by_index too, for systems with CONFIG_CLK=n

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Propogate non-ENODEV errors from clk_get_by_index

?drivers/serial/ns16550.c | 21 ++++++++++++++++++--- ?1 file changed, 18 insertions(+), 3 deletions(-)

drivers/serial/ns16550.c +0 -0
index 88fca15..3f6ea4d 100644
@@ -5,6 +5,7 @@

? */
?
?#include <common.h>
+#include <clk.h>
?#include <dm.h>
?#include <errno.h>
?#include <fdtdec.h>

drivers/serial/ns16550.c +2 -0
@@ -352,6 +353,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 ?{
 ?	struct ns16550_platdata *plat = dev->platdata;
 ?	fdt_addr_t addr;
+	struct clk clk;
+	int err;

?
? /* try Processor Local Bus device first */
? addr = dev_get_addr(dev);

drivers/serial/ns16550.c +15 -3
@@ -397,9 +400,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 ?				?????"reg-offset", 0);
 ?	plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
 ?					?"reg-shift", 0);
-	plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
-				?????"clock-frequency",
-				?????CONFIG_SYS_NS16550_CLK);
+
+	err = clk_get_by_index(dev, 0, &clk);
+	if (!err) {
+		err = clk_get_rate(&clk);
+		if (!IS_ERR_VALUE(err))
+			plat->clock = err;
+	} else if (err != -ENODEV && err != -ENOSYS) {
+		debug("ns16550 failed to get clock\n");
+		return err;
+	}
+
+	if (!plat->clock)
+		plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+					?????"clock-frequency",
+					?????CONFIG_SYS_NS16550_CLK);
 ?	if (!plat->clock) {
 ?		debug("ns16550 clock not defined\n");
 ?		return -EINVAL;
Signature · 2 lines
Best regards,
Vlad Zakharov <[email protected]>
#11 lore raw

PATCH v7 3/12 dt-bindings: Add interrupt-controller/mips-gic.h header

In reply to Paul Burton

Import a copy of the dt-bindings/interrupt-controller/mips-gic.h header from Linux, such that we can use device trees which include it without modification.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/dt-bindings/interrupt-controller/mips-gic.h | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 include/dt-bindings/interrupt-controller/mips-gic.h
include/dt-bindings/interrupt-controller/mips-gic.h new file +9 -0
new file mode 100644
index 0000000..cf35a57
@@ -0,0 +1,9 @@
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_MIPS_GIC_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_MIPS_GIC_H
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+#define GIC_SHARED 0
+#define GIC_LOCAL 1
+
+#endif
Signature · 1 line
2.9.3
#12 lore raw

PATCH v7 4/12 pci: xilinx: Add a driver for Xilinx AXI to PCIe bridge

In reply to Paul Burton

This patch adds a driver for the Xilinx AXI bridge for PCI express, an IP block which can be used on some generations of Xilinx FPGAs. This is mostly a case of implementing PCIe ECAM specification, but with some quirks about what devices are valid to access.

---

Changes in v7: None
Changes in v6:
- Use map_physmem instead of ioremap_nocache

Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Clean up error returns & documentation

 drivers/pci/Kconfig       |   7 ++
 drivers/pci/Makefile      |   1 +
 drivers/pci/pcie_xilinx.c | 220 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 228 insertions(+)
 create mode 100644 drivers/pci/pcie_xilinx.c
drivers/pci/Kconfig +7 -0
index 669e37b..9a7c187 100644
@@ -39,4 +39,11 @@ config PCI_TEGRA
 	  with a total of 5 lanes. Some boards require this for Ethernet
 	  support to work (e.g. beaver, jetson-tk1).
 
+config PCI_XILINX
+	bool "Xilinx AXI Bridge for PCI Express"
+	depends on DM_PCI
+	help
+	  Enable support for the Xilinx AXI bridge for PCI express, an IP block
+	  which can be used on some generations of Xilinx FPGAs.
+
 endmenu
drivers/pci/Makefile +1 -0
index f8be9bf..9583e91 100644
@@ -31,3 +31,4 @@ obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
 obj-$(CONFIG_TSI108_PCI) += tsi108_pci.o
 obj-$(CONFIG_WINBOND_83C553) += w83c553f.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
+obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
drivers/pci/pcie_xilinx.c new file +220 -0

220 lines not on this page · raw message

Signature · 1 line
2.9.3
#13 lore raw

PATCH v7 5/12 pci: Flip condition for detecting non-PCI parent devices

In reply to Paul Burton

In pci_uclass_pre_probe an attempt is made to detect whether the parent of a device is a PCI device and that the device is thus a bridge. This was being done by checking whether the parent of the device is of the UCLASS_ROOT class. This causes problems if the PCI controller is a child of some other non-PCI node, for example a simple-bus node.

For example, if the device tree contains something like the following then pci_uclass_pre_probe would incorrectly believe that the PCI controller is a bridge, with a PCI parent:

  / {
    some_child {
      compatible = "simple-bus";
      #address-cells = <1>;
      #size-cells = <1>;
      ranges = <>;
      pci_controller: pci at 10000000 {
        compatible = "my-pci-controller";
        device_type = "pci";
        reg = <0x10000000 0x2000000>;
      };
    };

};

Avoid this incorrect detection of bridges by instead checking whether the parent devices class is UCLASS_PCI and treating a device as a bridge when this is true, making use of device_is_on_pci_bus to perform this test.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Use device_is_on_pci_bus instead of effectively open-coding it

 drivers/pci/pci-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/pci-uclass.c +1 -1
index 342b78c..3b00e6a 100644
@@ -837,7 +837,7 @@ static int pci_uclass_pre_probe(struct udevice *bus)
 	hose = bus->uclass_priv;
 
 	/* For bridges, use the top-level PCI controller */
-	if (device_get_uclass_id(bus->parent) == UCLASS_ROOT) {
+	if (!device_is_on_pci_bus(bus)) {
 		hose->ctlr = bus;
 		ret = decode_regions(hose, gd->fdt_blob, bus->parent->of_offset,
 				bus->of_offset);
Signature · 1 line
2.9.3
#14 lore raw

PATCH v7 6/12 net: pch_gbe: Use dm_pci_map_bar to discover MMIO base

In reply to Paul Burton

Reading the PCI BAR & converting the result to a physical address is not safe across all architectures. For example on MIPS the virtual:physical mapping is not 1:1, so we cannot directly make use of the physical address.

Use the more generic BAR-mapping function dm_pci_map_bar to discover the MMIO base address, which should work across architectures.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/net/pch_gbe.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/net/pch_gbe.c +3 -5
index 137818b..2d0a700 100644
@@ -421,7 +421,7 @@ int pch_gbe_probe(struct udevice *dev)
 {
 	struct pch_gbe_priv *priv;
 	struct eth_pdata *plat = dev_get_platdata(dev);
-	u32 iobase;
+	void *iobase;
 
 	/*
 	 * The priv structure contains the descriptors and frame buffers which
@@ -432,11 +432,9 @@ int pch_gbe_probe(struct udevice *dev)
 
 	priv->dev = dev;
 
-	dm_pci_read_config32(dev, PCI_BASE_ADDRESS_1, &iobase);
-	iobase &= PCI_BASE_ADDRESS_MEM_MASK;
-	iobase = dm_pci_mem_to_phys(dev, iobase);
+	iobase = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_1, PCI_REGION_MEM);
 
-	plat->iobase = iobase;
+	plat->iobase = (ulong)iobase;
 	priv->mac_regs = (struct pch_gbe_regs *)iobase;
 
 	/* Read MAC address from SROM and initialize dev->enetaddr with it */
Signature · 1 line
2.9.3
#15 lore raw

PATCH v7 7/12 net: pch_gbe: Make 64 bit safe

In reply to Paul Burton

The pch_gbe driver previously casted pointers to & from unsigned 32 bit integers in many locations. This breaks the driver on 64 bit systems, producing streams of compiler warnings about mismatched pointer & integer sizes and then failing to keep track of addresses correctly at runtime.

Fix the driver for 64 bit systems by using unsigned longs in place of the previously used 32 bit integers.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/net/pch_gbe.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
drivers/net/pch_gbe.c +10 -10
index 2d0a700..d40fff0 100644
@@ -118,14 +118,14 @@ static void pch_gbe_rx_descs_init(struct udevice *dev)
 	memset(rx_desc, 0, sizeof(struct pch_gbe_rx_desc) * PCH_GBE_DESC_NUM);
 	for (i = 0; i < PCH_GBE_DESC_NUM; i++)
 		rx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev,
-			(u32)(priv->rx_buff[i]));
+			(ulong)(priv->rx_buff[i]));
 
-	writel(dm_pci_phys_to_mem(priv->dev, (u32)rx_desc),
+	writel(dm_pci_phys_to_mem(priv->dev, (ulong)rx_desc),
 	       &mac_regs->rx_dsc_base);
 	writel(sizeof(struct pch_gbe_rx_desc) * (PCH_GBE_DESC_NUM - 1),
 	       &mac_regs->rx_dsc_size);
 
-	writel(dm_pci_phys_to_mem(priv->dev, (u32)(rx_desc + 1)),
+	writel(dm_pci_phys_to_mem(priv->dev, (ulong)(rx_desc + 1)),
 	       &mac_regs->rx_dsc_sw_p);
 }
 
@@ -137,11 +137,11 @@ static void pch_gbe_tx_descs_init(struct udevice *dev)
 
 	memset(tx_desc, 0, sizeof(struct pch_gbe_tx_desc) * PCH_GBE_DESC_NUM);
 
-	writel(dm_pci_phys_to_mem(priv->dev, (u32)tx_desc),
+	writel(dm_pci_phys_to_mem(priv->dev, (ulong)tx_desc),
 	       &mac_regs->tx_dsc_base);
 	writel(sizeof(struct pch_gbe_tx_desc) * (PCH_GBE_DESC_NUM - 1),
 	       &mac_regs->tx_dsc_size);
-	writel(dm_pci_phys_to_mem(priv->dev, (u32)(tx_desc + 1)),
+	writel(dm_pci_phys_to_mem(priv->dev, (ulong)(tx_desc + 1)),
 	       &mac_regs->tx_dsc_sw_p);
 }
 
@@ -251,7 +251,7 @@ static int pch_gbe_send(struct udevice *dev, void *packet, int length)
 	if (length < 64)
 		frame_ctrl |= PCH_GBE_TXD_CTRL_APAD;
 
-	tx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev, (u32)packet);
+	tx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev, (ulong)packet);
 	tx_desc->length = length;
 	tx_desc->tx_words_eob = length + 3;
 	tx_desc->tx_frame_ctrl = frame_ctrl;
@@ -262,7 +262,7 @@ static int pch_gbe_send(struct udevice *dev, void *packet, int length)
 	if (++priv->tx_idx >= PCH_GBE_DESC_NUM)
 		priv->tx_idx = 0;
 
-	writel(dm_pci_phys_to_mem(priv->dev, (u32)(tx_head + priv->tx_idx)),
+	writel(dm_pci_phys_to_mem(priv->dev, (ulong)(tx_head + priv->tx_idx)),
 	       &mac_regs->tx_dsc_sw_p);
 
 	start = get_timer(0);
@@ -283,7 +283,7 @@ static int pch_gbe_recv(struct udevice *dev, int flags, uchar **packetp)
 	struct pch_gbe_priv *priv = dev_get_priv(dev);
 	struct pch_gbe_regs *mac_regs = priv->mac_regs;
 	struct pch_gbe_rx_desc *rx_desc;
-	u32 hw_desc, buffer_addr, length;
+	ulong hw_desc, buffer_addr, length;
 
 	rx_desc = &priv->rx_desc[priv->rx_idx];
 
@@ -291,7 +291,7 @@ static int pch_gbe_recv(struct udevice *dev, int flags, uchar **packetp)
 	hw_desc = readl(&mac_regs->rx_dsc_hw_p_hld);
 
 	/* Just return if not receiving any packet */
-	if ((u32)rx_desc == hw_desc)
+	if ((ulong)rx_desc == hw_desc)
 		return -EAGAIN;
 
 	buffer_addr = dm_pci_mem_to_phys(priv->dev, rx_desc->buffer_addr);
@@ -315,7 +315,7 @@ static int pch_gbe_free_pkt(struct udevice *dev, uchar *packet, int length)
 	if (++rx_swp >= PCH_GBE_DESC_NUM)
 		rx_swp = 0;
 
-	writel(dm_pci_phys_to_mem(priv->dev, (u32)(rx_head + rx_swp)),
+	writel(dm_pci_phys_to_mem(priv->dev, (ulong)(rx_head + rx_swp)),
 	       &mac_regs->rx_dsc_sw_p);
 
 	return 0;
Signature · 1 line
2.9.3
#16 lore raw

PATCH v7 8/12 dm: regmap: Implement simple regmap_read & regmap_write

In reply to Paul Burton

The regmap_read & regmap_write functions were previously declared in regmap.h but not implemented anywhere. The regmap implementation & commit message of 6f98b7504f70 ("dm: Add support for register maps (regmap)") indicate that only memory mapped accesses are supported for now, so providing simple implementations of regmap_read & regmap_write is trivial. The access size is presumed to be 4 bytes & endianness is presumed native, which are the defaults for the regmap code in Linux.

---

Changes in v7:
- Use map_physmem instead of ioremap, as it's more generic
- Use plain readl & writel, not __raw_ variants

Changes in v6: None
Changes in v5: None
Changes in v4:
- Tweak whitespace

Changes in v3: None
Changes in v2:
- New patch

 drivers/core/regmap.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
drivers/core/regmap.c +20 -0
index 0299ff0..c68bcba 100644
@@ -13,6 +13,8 @@
 #include <mapmem.h>
 #include <regmap.h>
 
+#include <asm/io.h>
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct regmap *regmap_alloc_count(int count)
@@ -117,3 +119,21 @@ int regmap_uninit(struct regmap *map)
 
 	return 0;
 }
+
+int regmap_read(struct regmap *map, uint offset, uint *valp)
+{
+	uint32_t *ptr = map_physmem(map->base + offset, 4, MAP_NOCACHE);
+
+	*valp = le32_to_cpu(readl(ptr));
+
+	return 0;
+}
+
+int regmap_write(struct regmap *map, uint offset, uint val)
+{
+	uint32_t *ptr = map_physmem(map->base + offset, 4, MAP_NOCACHE);
+
+	writel(cpu_to_le32(val), ptr);
+
+	return 0;
+}
Signature · 1 line
2.9.3
#17 lore raw

PATCH v7 9/12 dm: core: Match compatible strings in order of priority

In reply to Paul Burton

Device model drivers have previously been matched to FDT nodes by virtue of being the first driver in the driver list to be compatible with the node. This ignores the fact that compatible strings in the device tree are listed in order of priority - that is, if we have a node with 2 compatible strings & a driver that matches each then we should always probe the driver that matches the first compatible string.

Fix this by looping through the compatible strings for a node when attempting to bind it in lists_bind_fdt and checking each driver for a match of the first string, then each driver for a match of the second string etc. Effectively this inverts the loops over compatible strings & drivers.

---

Changes in v7:
- Pass the correct match data to device_bind_with_driver_data

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/core/lists.c | 78 +++++++++++++++++++++++++++-------------------------
 1 file changed, 41 insertions(+), 37 deletions(-)
drivers/core/lists.c +41 -37
index 6a634e6..23b6ba7 100644
@@ -101,36 +101,24 @@ int device_bind_driver_to_node(struct udevice *parent, const char *drv_name,
 
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
 /**
- * driver_check_compatible() - Check if a driver is compatible with this node
+ * driver_check_compatible() - Check if a driver matches a compatible string
  *
- * @param blob:		Device tree pointer
- * @param offset:	Offset of node in device tree
  * @param of_match:	List of compatible strings to match
  * @param of_idp:	Returns the match that was found
- * @return 0 if there is a match, -ENOENT if no match, -ENODEV if the node
- * does not have a compatible string, other error <0 if there is a device
- * tree error
+ * @param compat:	The compatible string to search for
+ * @return 0 if there is a match, -ENOENT if no match
  */
-static int driver_check_compatible(const void *blob, int offset,
-				   const struct udevice_id *of_match,
-				   const struct udevice_id **of_idp)
+static int driver_check_compatible(const struct udevice_id *of_match,
+				   const struct udevice_id **of_idp,
+				   const char *compat)
 {
-	int ret;
-
-	*of_idp = NULL;
 	if (!of_match)
 		return -ENOENT;
 
 	while (of_match->compatible) {
-		ret = fdt_node_check_compatible(blob, offset,
-						of_match->compatible);
-		if (!ret) {
+		if (!strcmp(of_match->compatible, compat)) {
 			*of_idp = of_match;
 			return 0;
-		} else if (ret == -FDT_ERR_NOTFOUND) {
-			return -ENODEV;
-		} else if (ret < 0) {
-			return -EINVAL;
 		}
 		of_match++;
 	}
@@ -147,28 +135,46 @@ int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
 	struct driver *entry;
 	struct udevice *dev;
 	bool found = false;
-	const char *name;
+	const char *name, *compat_list, *compat;
+	int compat_length, i;
 	int result = 0;
 	int ret = 0;
 
-	dm_dbg("bind node %s\n", fdt_get_name(blob, offset, NULL));
+	name = fdt_get_name(blob, offset, NULL);
+	dm_dbg("bind node %s\n", name);
 	if (devp)
 		*devp = NULL;
-	for (entry = driver; entry != driver + n_ents; entry++) {
-		ret = driver_check_compatible(blob, offset, entry->of_match,
-					      &id);
-		name = fdt_get_name(blob, offset, NULL);
-		if (ret == -ENOENT) {
-			continue;
-		} else if (ret == -ENODEV) {
+
+	compat_list = fdt_getprop(blob, offset, "compatible", &compat_length);
+	if (!compat_list) {
+		if (compat_length == -FDT_ERR_NOTFOUND) {
 			dm_dbg("Device '%s' has no compatible string\n", name);
-			break;
-		} else if (ret) {
-			dm_warn("Device tree error at offset %d\n", offset);
-			result = ret;
-			break;
+			return 0;
 		}
 
+		dm_warn("Device tree error at offset %d\n", offset);
+		return compat_length;
+	}
+
+	/*
+	 * Walk through the compatible string list, attempting to match each
+	 * compatible string in order such that we match in order of priority
+	 * from the first string to the last.
+	 */
+	for (i = 0; i < compat_length; i += strlen(compat) + 1) {
+		compat = compat_list + i;
+		dm_dbg("   - attempt to match compatible string '%s'\n",
+		       compat);
+
+		for (entry = driver; entry != driver + n_ents; entry++) {
+			ret = driver_check_compatible(entry->of_match, &id,
+						      compat);
+			if (!ret)
+				break;
+		}
+		if (entry == driver + n_ents)
+			continue;
+
 		dm_dbg("   - found match at '%s'\n", entry->name);
 		ret = device_bind_with_driver_data(parent, entry, name,
 						   id->data, offset, &dev);
@@ -188,10 +194,8 @@ int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
 		break;
 	}
 
-	if (!found && !result && ret != -ENODEV) {
-		dm_dbg("No match for node '%s'\n",
-		       fdt_get_name(blob, offset, NULL));
-	}
+	if (!found && !result && ret != -ENODEV)
+		dm_dbg("No match for node '%s'\n", name);
 
 	return result;
 }
Signature · 1 line
2.9.3
#18 lore raw

PATCH v7 9/12 dm: core: Match compatible strings in order of priority

Hi,

Quoted 20 lines · Paul Burton

Device model drivers have previously been matched to FDT nodes by virtue of being the first driver in the driver list to be compatible with the node. This ignores the fact that compatible strings in the device tree are listed in order of priority - that is, if we have a node with 2 compatible strings & a driver that matches each then we should always probe the driver that matches the first compatible string.

Fix this by looping through the compatible strings for a node when attempting to bind it in lists_bind_fdt and checking each driver for a match of the first string, then each driver for a match of the second string etc. Effectively this inverts the loops over compatible strings & drivers.

---

Changes in v7:
- Pass the correct match data to device_bind_with_driver_data

Quoted 9 lines

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/core/lists.c | 78 +++++++++++++++++++++++++++-------------------------
 1 file changed, 41 insertions(+), 37 deletions(-)

It looks like this has been applied, right?

Regards,
Simon

#19 lore raw

PATCH v7 10/12 dm: syscon: Provide a generic syscon driver

In reply to Paul Burton

Provide a trivial syscon driver matching the generic "syscon" compatible string, allowing for simple system controllers to be used without a custom driver just as in Linux.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch

 drivers/core/syscon-uclass.c | 11 +++++++++++
 1 file changed, 11 insertions(+)
drivers/core/syscon-uclass.c +11 -0
index 01bd968..2148469 100644
@@ -95,3 +95,14 @@ UCLASS_DRIVER(syscon) = {
 	.per_device_auto_alloc_size = sizeof(struct syscon_uc_info),
 	.pre_probe = syscon_pre_probe,
 };
+
+static const struct udevice_id generic_syscon_ids[] = {
+	{ .compatible = "syscon" },
+	{ }
+};
+
+U_BOOT_DRIVER(generic_syscon) = {
+	.name	= "syscon",
+	.id	= UCLASS_SYSCON,
+	.of_match = generic_syscon_ids,
+};
Signature · 1 line
2.9.3
#20 lore raw

PATCH v7 10/12 dm: syscon: Provide a generic syscon driver

Hi,

Quoted 16 lines · Paul Burton

Provide a trivial syscon driver matching the generic "syscon" compatible string, allowing for simple system controllers to be used without a custom driver just as in Linux.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch

Quoted 2 lines
 drivers/core/syscon-uclass.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

It looks like this has been applied, right?

Regards,
Simon

#21 lore raw

PATCH v7 10/12 dm: syscon: Provide a generic syscon driver

Quoted 19 lines · On Thursday, 22 September 2016 22:15:48 BST Simon Glass wrote:

Hi,

Quoted 16 lines · Paul Burton

Provide a trivial syscon driver matching the generic "syscon" compatible string, allowing for simple system controllers to be used without a custom driver just as in Linux.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch

Quoted 7 lines
Quoted 2 lines
 drivers/core/syscon-uclass.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

It looks like this has been applied, right?

Regards,
Simon

Hi Simon,

This patch & patch 9 of the series which you asked the same question of were both included in the MIPS pull that was merged on Wednesday:

http://lists.denx.de/pipermail/u-boot/2016-September/267439.html[1]

Thanks,
Paul

--------
[1] http://lists.denx.de/pipermail/u-boot/2016-September/267439.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160923/c098ec88/attachment.sig>

#22 lore raw

PATCH v7 10/12 dm: syscon: Provide a generic syscon driver

Hi Paul,

Quoted 60 lines · Paul Burton
Quoted 44 lines · On Thursday, 22 September 2016 22:15:48 BST Simon Glass wrote:

Hi,

Quoted 28 lines · Paul Burton

Provide a trivial syscon driver matching the generic "syscon" compatible

string, allowing for simple system controllers to be used without a

custom driver just as in Linux.

---

Changes in v7: None

Changes in v6: None

Changes in v5: None

Changes in v4: None

Changes in v3: None

Changes in v2:

Quoted 7 lines

- New patch

drivers/core/syscon-uclass.c | 11 +++++++++++

1 file changed, 11 insertions(+)
Quoted 7 lines

It looks like this has been applied, right?

Regards,

Simon

Hi Simon,

Quoted 6 lines

This patch & patch 9 of the series which you asked the same question of were both included in the MIPS pull that was merged on Wednesday:

http://lists.denx.de/pipermail/u-boot/2016-September/267439.html

OK thanks. It is helpful to send a message on each patch when it is applied, so that we know its change in status.

Regards,
Simon

#23 lore raw

PATCH v7 11/12 clk: boston: Providea simple driver for Boston board clocks

In reply to Paul Burton

Add a simple driver for the clocks provided by the MIPS Boston development board. The system provides information about 2 clocks whose rates are fixed by the bitfile flashed in the boards FPGA, and this driver simply reads the rates of these 2 clocks.

---

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Replace EXT macro with ext_field function

Changes in v3: None
Changes in v2:
- New patch

 drivers/clk/Kconfig                      |  8 +++
 drivers/clk/Makefile                     |  1 +
 drivers/clk/clk_boston.c                 | 97 ++++++++++++++++++++++++++++++++
 include/dt-bindings/clock/boston-clock.h | 13 +++++
 4 files changed, 119 insertions(+)
 create mode 100644 drivers/clk/clk_boston.c
 create mode 100644 include/dt-bindings/clock/boston-clock.h
drivers/clk/Kconfig +8 -0
index 8f3b96a..c05ce2a 100644
@@ -20,6 +20,14 @@ config SPL_CLK
 	  setting up clocks within SPL, and allows the same drivers to be
 	  used as U-Boot proper.
 
+config CLK_BOSTON
+	def_bool y if TARGET_BOSTON
+	depends on CLK
+	select REGMAP
+	select SYSCON
+	help
+	  Enable this to support the clocks
+
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/exynos/Kconfig"
drivers/clk/Makefile +1 -0
index 778d748..40a5e8c 100644
@@ -15,3 +15,4 @@ obj-y += tegra/
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
 obj-$(CONFIG_CLK_AT91) += at91/
+obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
drivers/clk/clk_boston.c new file +97 -0

97 lines not on this page · raw message

include/dt-bindings/clock/boston-clock.h new file +13 -0
new file mode 100644
index 0000000..25f9cd2
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_BOSTON_CLOCK_H__
+#define __DT_BINDINGS_CLOCK_BOSTON_CLOCK_H__
+
+#define BOSTON_CLK_SYS 0
+#define BOSTON_CLK_CPU 1
+
+#endif /* __DT_BINDINGS_CLOCK_BOSTON_CLOCK_H__ */
Signature · 1 line
2.9.3
#24 lore raw

PATCH v7 12/12 boston: Introduce support for the MIPS Boston development board

In reply to Paul Burton

This patch introduces support for building U-Boot to run on the MIPS Boston development board. This is a board built around an FPGA & an Intel EG20T Platform Controller Hub, used largely as part of the development of new CPUs and their software support. It is essentially the successor to the older MIPS Malta board.

---

Changes in v7:
- Enable CM & L2 support
- Enable flash & environment save support

Changes in v6:
- Correct 32 bit text base address in defconfigs

Changes in v5:
- Mention arch revision & toolchain in README.boston
- Drop platform register access now only 2 are used since clock changes

Changes in v4:
- Add README.boston

Changes in v3:
- Add defconfigs for 32b & 64b, big & little endian, switch to MIPSr2

Changes in v2:
- Use AT instead of $1
- Use a clock driver instead of patching the DT

 arch/mips/Kconfig                   |  18 +++
 arch/mips/dts/Makefile              |   1 +
 arch/mips/dts/img,boston.dts        | 222 ++++++++++++++++++++++++++++++++++++
 board/imgtec/boston/Kconfig         |  16 +++
 board/imgtec/boston/MAINTAINERS     |   6 +
 board/imgtec/boston/Makefile        |   9 ++
 board/imgtec/boston/boston-lcd.h    |  21 ++++
 board/imgtec/boston/boston-regs.h   |  26 +++++
 board/imgtec/boston/checkboard.c    |  30 +++++
 board/imgtec/boston/ddr.c           |  30 +++++
 board/imgtec/boston/lowlevel_init.S |  56 +++++++++
 configs/boston32r2_defconfig        |  41 +++++++
 configs/boston32r2el_defconfig      |  42 +++++++
 configs/boston64r2_defconfig        |  41 +++++++
 configs/boston64r2el_defconfig      |  42 +++++++
 doc/README.boston                   |  58 ++++++++++
 include/configs/boston.h            |  81 +++++++++++++
 17 files changed, 740 insertions(+)
 create mode 100644 arch/mips/dts/img,boston.dts
 create mode 100644 board/imgtec/boston/Kconfig
 create mode 100644 board/imgtec/boston/MAINTAINERS
 create mode 100644 board/imgtec/boston/Makefile
 create mode 100644 board/imgtec/boston/boston-lcd.h
 create mode 100644 board/imgtec/boston/boston-regs.h
 create mode 100644 board/imgtec/boston/checkboard.c
 create mode 100644 board/imgtec/boston/ddr.c
 create mode 100644 board/imgtec/boston/lowlevel_init.S
 create mode 100644 configs/boston32r2_defconfig
 create mode 100644 configs/boston32r2el_defconfig
 create mode 100644 configs/boston64r2_defconfig
 create mode 100644 configs/boston64r2el_defconfig
 create mode 100644 doc/README.boston
 create mode 100644 include/configs/boston.h
arch/mips/Kconfig +18 -0
index 21066f0..dc61550 100644
@@ -73,9 +73,27 @@ config MACH_PIC32
 	select OF_CONTROL
 	select DM
 
+config TARGET_BOSTON
+	bool "Support Boston"
+	select DM
+	select DM_SERIAL
+	select OF_CONTROL
+	select MIPS_CM
+	select MIPS_L1_CACHE_SHIFT_6
+	select MIPS_L2
+	select SUPPORTS_BIG_ENDIAN
+	select SUPPORTS_LITTLE_ENDIAN
+	select SUPPORTS_CPU_MIPS32_R1
+	select SUPPORTS_CPU_MIPS32_R2
+	select SUPPORTS_CPU_MIPS32_R6
+	select SUPPORTS_CPU_MIPS64_R1
+	select SUPPORTS_CPU_MIPS64_R2
+	select SUPPORTS_CPU_MIPS64_R6
+
 endchoice
 
 source "board/dbau1x00/Kconfig"
+source "board/imgtec/boston/Kconfig"
 source "board/imgtec/malta/Kconfig"
 source "board/micronas/vct/Kconfig"
 source "board/pb1x00/Kconfig"
arch/mips/dts/Makefile +1 -0
index 2f04d73..6a5e43e 100644
@@ -4,6 +4,7 @@
 
 dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
 dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
+dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
 dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
 dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
arch/mips/dts/img,boston.dts new file +222 -0

222 lines not on this page · raw message

board/imgtec/boston/Kconfig new file +16 -0
new file mode 100644
index 0000000..ab76a3c
@@ -0,0 +1,16 @@
+if TARGET_BOSTON
+
+config SYS_BOARD
+	default "boston"
+
+config SYS_VENDOR
+	default "imgtec"
+
+config SYS_CONFIG_NAME
+	default "boston"
+
+config SYS_TEXT_BASE
+	default 0x9fc00000 if 32BIT
+	default 0xffffffff9fc00000 if 64BIT
+
+endif
board/imgtec/boston/MAINTAINERS new file +6 -0
new file mode 100644
index 0000000..30dd481
@@ -0,0 +1,6 @@
+BOSTON BOARD
+M:	Paul Burton <[email protected]>
+S:	Maintained
+F:	board/imgtec/boston/
+F:	include/configs/boston.h
+F:	configs/boston_defconfig
board/imgtec/boston/Makefile new file +9 -0
new file mode 100644
index 0000000..deda457
@@ -0,0 +1,9 @@
+#
+# Copyright (C) 2016 Imagination Technologies
+#
+# SPDX-License-Identifier:	GPL-2.0
+#
+
+obj-y += checkboard.o
+obj-y += ddr.o
+obj-y += lowlevel_init.o
board/imgtec/boston/boston-lcd.h new file +21 -0
new file mode 100644
index 0000000..9f5c1b9
@@ -0,0 +1,21 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ */
+
+#ifndef __BOARD_BOSTON_LCD_H__
+#define __BOARD_BOSTON_LCD_H__
+
+/**
+ * lowlevel_display() - Display a message on Boston's LCD
+ * @msg: The string to display
+ *
+ * Display the string @msg on the 7 character LCD display of the Boston board.
+ * This is typically used for debug or to present some form of status
+ * indication to the user, allowing faults to be identified when things go
+ * wrong early enough that the UART isn't up.
+ */
+void lowlevel_display(const char msg[static 8]);
+
+#endif /* __BOARD_BOSTON_LCD_H__ */
board/imgtec/boston/boston-regs.h new file +26 -0
new file mode 100644
index 0000000..b9dfbb4
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ */
+
+#ifndef __BOARD_BOSTON_REGS_H__
+#define __BOARD_BOSTON_REGS_H__
+
+#include <asm/addrspace.h>
+
+#define BOSTON_PLAT_BASE		CKSEG1ADDR(0x17ffd000)
+#define BOSTON_LCD_BASE			CKSEG1ADDR(0x17fff000)
+
+/*
+ * Platform Register Definitions
+ */
+#define BOSTON_PLAT_CORE_CL		(BOSTON_PLAT_BASE + 0x04)
+
+#define BOSTON_PLAT_DDR3STAT		(BOSTON_PLAT_BASE + 0x14)
+# define BOSTON_PLAT_DDR3STAT_CALIB	(1 << 2)
+
+#define BOSTON_PLAT_DDRCONF0		(BOSTON_PLAT_BASE + 0x38)
+# define BOSTON_PLAT_DDRCONF0_SIZE	(0xf << 0)
+
+#endif /* __BOARD_BOSTON_REGS_H__ */
board/imgtec/boston/checkboard.c new file +30 -0
new file mode 100644
index 0000000..93eae7f
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ */
+
+#include <common.h>
+
+#include <asm/io.h>
+#include <asm/mipsregs.h>
+
+#include "boston-lcd.h"
+#include "boston-regs.h"
+
+int checkboard(void)
+{
+	u32 changelist;
+
+	lowlevel_display("U-boot  ");
+
+	printf("Board: MIPS Boston\n");
+
+	printf("CPU:   0x%08x", read_c0_prid());
+	changelist = __raw_readl((uint32_t *)BOSTON_PLAT_CORE_CL);
+	if (changelist > 1)
+		printf(" cl%x", changelist);
+	putc('\n');
+
+	return 0;
+}
board/imgtec/boston/ddr.c new file +30 -0
new file mode 100644
index 0000000..ceffef6
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:	GPL-2.0
+ */
+
+#include <common.h>
+
+#include <asm/io.h>
+
+#include "boston-regs.h"
+
+phys_size_t initdram(int board_type)
+{
+	u32 ddrconf0 = __raw_readl((uint32_t *)BOSTON_PLAT_DDRCONF0);
+
+	return (phys_size_t)(ddrconf0 & BOSTON_PLAT_DDRCONF0_SIZE) << 30;
+}
+
+ulong board_get_usable_ram_top(ulong total_size)
+{
+	DECLARE_GLOBAL_DATA_PTR;
+
+	if (gd->ram_top < CONFIG_SYS_SDRAM_BASE) {
+		/* 2GB wrapped around to 0 */
+		return CKSEG0ADDR(256 << 20);
+	}
+
+	return min_t(unsigned long, gd->ram_top, CKSEG0ADDR(256 << 20));
+}
board/imgtec/boston/lowlevel_init.S new file +56 -0

56 lines not on this page · raw message

configs/boston32r2_defconfig new file +41 -0

41 lines not on this page · raw message

configs/boston32r2el_defconfig new file +42 -0

42 lines not on this page · raw message

configs/boston64r2_defconfig new file +41 -0

41 lines not on this page · raw message

configs/boston64r2el_defconfig new file +42 -0

42 lines not on this page · raw message

doc/README.boston new file +58 -0

58 lines not on this page · raw message

include/configs/boston.h new file +81 -0

81 lines not on this page · raw message

Signature · 1 line
2.9.3
#25 lore raw

PATCH v7 12/12 boston: Introduce support for the MIPS Boston development board

Am 08.09.2016 um 08:47 schrieb Paul Burton:

Quoted 6 lines

This patch introduces support for building U-Boot to run on the MIPS Boston development board. This is a board built around an FPGA & an Intel EG20T Platform Controller Hub, used largely as part of the development of new CPUs and their software support. It is essentially the successor to the older MIPS Malta board.

Quoted 7 lines

---

Changes in v7:
- Enable CM & L2 support
- Enable flash & environment save support

can we enable CM and L2 support with an additional patch in your L2 cache series? I'd like to apply this series first. I can adapt this patch when applying so you don't have to send a new one.

Quoted 18 lines

Changes in v6:
- Correct 32 bit text base address in defconfigs

Changes in v5:
- Mention arch revision & toolchain in README.boston
- Drop platform register access now only 2 are used since clock changes

Changes in v4:
- Add README.boston

Changes in v3:
- Add defconfigs for 32b & 64b, big & little endian, switch to MIPSr2

Changes in v2:
- Use AT instead of $1
- Use a clock driver instead of patching the DT

Signature · 9 lines
- Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160910/dc61ad03/attachment.sig>
#26 lore raw

PATCH v7 12/12 boston: Introduce support for the MIPS Boston development board

Quoted 13 lines · Daniel Schwierzeck

Am 08.09.2016 um 08:47 schrieb Paul Burton:

Quoted 10 lines

This patch introduces support for building U-Boot to run on the MIPS Boston development board. This is a board built around an FPGA & an Intel EG20T Platform Controller Hub, used largely as part of the development of new CPUs and their software support. It is essentially the successor to the older MIPS Malta board.

---

Quoted 7 lines
Quoted 3 lines

Changes in v7:
- Enable CM & L2 support
- Enable flash & environment save support

can we enable CM and L2 support with an additional patch in your L2 cache series? I'd like to apply this series first. I can adapt this patch when applying so you don't have to send a new one.

Hi Daniel,

Yeah that's fine with me :)

Thanks,
Paul

Quoted 20 lines
Quoted 19 lines

Changes in v6:
- Correct 32 bit text base address in defconfigs

Changes in v5:
- Mention arch revision & toolchain in README.boston
- Drop platform register access now only 2 are used since clock changes

Changes in v4:
- Add README.boston

Changes in v3:
- Add defconfigs for 32b & 64b, big & little endian, switch to MIPSr2

Changes in v2:
- Use AT instead of $1
- Use a clock driver instead of patching the DT