Re: [linux-sunxi] Re: [PATCH v4 3/7] clk: sunxi: add generic multi-parent bus clock gates driver

2016-08-09 Thread Jean-Francois Moine 
On Tue, 9 Aug 2016 18:02:47 +0800
Chen-Yu Tsai  wrote:

> > The 'parent's of the bus gates are of no interest.
> > They are supposed to be (no clear documentation) apb1, apb2, ahb1 and
> > ahb2, but, as you well noticed in the patch 5/7, these clocks are fixed
> > and have no gate. Some of them are parents of real clocks, but they
> > don't bring anything to the bus gates of the other clocks.
> 
> Yes they are. Some devices, such as UARTs and I2C controllers, need
> to get the clock rate of the gate and calculate the proper internal
> divider.

You are right, the clocks of some subsystems have only a gate, but
these are exceptions.

Look at an ordinary clock, say the mmc0 of the H3.
There is a "bus" gate (see below) in the CCU register 0x60, bit 8, and
the "clock" gate in the CCU register 0x88, bit 31.

The 'simple-gates' says that the "bus gate" is child of ahb1 (in all
sunxi versions, the one prior to 'simple-gate', in the 'simple-gate',
in 'sunxi-ng', and now in André's patch).

But, where do you see a hardware relation between the mmc0 clock and
the ahb1 clock?

> > As I wrote previously, the simplest is to ungate/gate the clocks in
> > both the bus and clock registers on clk_prepare/unprepare.
> > Then, your 'multi-bus-gates' would be simply a generic 'multi-gates'.
> 
> This is somewhat misleading. What "clock" registers are you referring
> to? There are no "bus" registers. The reason we call them "bus clock
> gates" is because they are mashed together, instead of having clearly
> separated registers for each AHB/APB bus.
> 
> And if you want just a generic clock gates driver, we already have
> the "simple-gates" driver.

Maybe I used the wrong words.

The "clock" register is the one which defines the parameters of the
clock (parents, mul/div factors, gate). For the H3 mmc0, it is the
CCU register 0x60.

The "bus" register is one of the so-called "Bus Clock Gating Register"s.
For the H3 mmc0, it is the CCU register 0x88.   

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: Problems with Orange Pi mini

2016-08-09 Thread Stefan Monnier 
> Can you try if that works:
> echo b > /proc/sysrq-trigger
> That's the hardcore version of "reboot" which does wait any process to
> nicely terminate, including filesystems.

I just tried it, but it doesn't work either: the machine just hangs there.


Stefan


PS: FWIW, in this "frozen state", the network interface is off
(according to the little "lan" light on my modem).

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [RFC PATCH 3/5] arm64: dts: sunxi: add SCPI node to sun50i-a64.dtsi

2016-08-09 Thread Andre Przywara 
Support for variable frequency clocks is implemented in ARM Trusted
Firmware, which sits in SRAM and waits for SCPI requests.
Add the respective SMC mailbox node and a 512-byte chunk of SRAM to
allow SCPI calls to be handled by the firmware.

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 70d0382..9fc540e 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -131,8 +131,34 @@
(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
 
+   mailbox: mbox@0 {
+   compatible = "arm,smc-mbox";
+   #mbox-cells = <1>;
+   identifiers = <0x8201>;
+   };
+
+   sram: sram@18000{
+   compatible = "mmio-sram";
+   reg = <0x1 0x8000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x1 0x8000>;
+
+   cpu_scp_mem: scp-shmem@7e00 {
+   compatible = "mmio-sram";
+   reg = <0x7e00 0x200>;
+   };
+   };
+
/include/ "sun50i-a64-clocks.dtsi"
 
+   scpi {
+   compatible = "arm,scpi";
+   mboxes = < 0>;
+   shmem = <_scp_mem>;
+   };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
-- 
2.9.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [RFC PATCH 4/5] arm64: dts: sunxi: add SCPI driven clocks and nodes for A64 MMC

2016-08-09 Thread Andre Przywara 
The MMC controllers in the Allwinner A64 SoC are somewhat compatible
with the versions used in other Allwinner SoCs.
Tell Linux about the three MMC clocks that the firmware implements and
add nodes to represent the MMC controllers.
The actual hardware is capable of new transfer modes, which the driver
does not fully support yet, also the clock part has changed, but it
works like this at least for SD card accesses.

Signed-off-by: Andre Przywara 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 61 +++
 1 file changed, 61 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 9fc540e..0f6044b 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -157,6 +157,19 @@
compatible = "arm,scpi";
mboxes = < 0>;
shmem = <_scp_mem>;
+
+   clocks {
+   compatible = "arm,scpi-clocks";
+
+   scpi_clk: scpi_clocks {
+   compatible = "arm,scpi-variable-clocks";
+   #clock-cells = <1>;
+   clock-indices = <0>, <1>,
+   <2>;
+   clock-output-names = "mmc0_clk", "mmc1_clk",
+"mmc2_clk";
+   };
+   };
};
 
soc {
@@ -165,6 +178,54 @@
#size-cells = <1>;
ranges;
 
+   mmc0: mmc@1c0f000 {
+   compatible = "allwinner,sun50i-a64-mmc",
+"allwinner,sun5i-a13-mmc";
+   reg = <0x01c0f000 0x1000>;
+   clocks = <_gates 8>, <_clk 0>,
+<_clk 0>, <_clk 0>;
+   clock-names = "ahb", "mmc",
+ "output", "sample";
+   resets = <_rst 8>;
+   reset-names = "ahb";
+   interrupts = ;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mmc1: mmc@1c1 {
+   compatible = "allwinner,sun50i-a64-mmc",
+"allwinner,sun5i-a13-mmc";
+   reg = <0x01c1 0x1000>;
+   clocks = <_gates 9>, <_clk 1>,
+<_clk 1>, <_clk 1>;
+   clock-names = "ahb", "mmc",
+ "output", "sample";
+   resets = <_rst 9>;
+   reset-names = "ahb";
+   interrupts = ;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   mmc2: mmc@1c11000 {
+   compatible = "allwinner,sun50i-a64-mmc",
+"allwinner,sun5i-a13-mmc";
+   reg = <0x01c11000 0x1000>;
+   clocks = <_gates 10>, <_clk 2>,
+<_clk 2>, <_clk 2>;
+   clock-names = "ahb", "mmc",
+ "output", "sample";
+   resets = <_rst 10>;
+   reset-names = "ahb";
+   interrupts = ;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
pio: pinctrl@1c20800 {
compatible = "allwinner,sun50i-a64-pinctrl";
reg = <0x01c20800 0x400>;
-- 
2.9.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [RFC PATCH 5/5] arm64: dts: sunxi: add MMC nodes to Pine64 and BPi-M64 .dts

2016-08-09 Thread Andre Przywara 
Those two boards connect a microSD card slot to the MMC0 controller.
Add the dummy regulator and enable MMC0 to allow accessing the SD card.

The BananaPi M64 has an on-board eMMC chip connected to the MMC2
controller, but the existing MMC driver does not support this properly
yet, so keep this one disabled for now.

Signed-off-by: Andre Przywara 
---
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 29 ++
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 20 +++
 2 files changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
index bc0ed4c..f98c351 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
@@ -59,6 +59,35 @@
aliases {
serial0 = 
};
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>, <_default_cd_pin>;
+   bus-width = <4>;
+   vmmc-supply = <_vcc3v3>;
+   cd-gpios = < 5 6 0>;
+   cd-inverted;
+   disable-wp;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   bus-width = <8>;
+   vmmc-supply = <_vcc3v3>;
+   non-removable;
+   status = "disabled";
 };
 
  {
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index 077a56f..a3957ca 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -59,6 +59,26 @@
aliases {
serial0 = 
};
+
+   soc {
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>, <_default_cd_pin>;
+   bus-width = <4>;
+   vmmc-supply = <_vcc3v3>;
+   cd-gpios = < 5 6 0>;
+   cd-inverted;
+   disable-wp;
+   status = "okay";
 };
 
  {
-- 
2.9.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [RFC PATCH 0/5] Allwinner MMC firmware clocks implementation

2016-08-09 Thread Andre Przywara 
Hi,

this is a proof-of-concept series to demonstrate the usage of firmware
driven clocks using the SCPI protocol for Allwinner SoCs.
This aims to replace the tricky and highly SoC specific clocks drivers
that every new Allwinner SoC seems to require.
The idea is to abstract the internal clock specific code by the rather
generic SCPI interface, which support programming and reading clock
frequencies in an SoC agnostic manner. The actual clock access can be
put in firmware, which is by definition SoC specific and thus can
be easier and much quicker adapted to support a new SoC.
The SCPI interface requires a mailbox and a shared memory region to
send commands and receive results.

This series introduces a new mailbox driver, which uses smc instructions
to trigger a mailbox. This allows the SCPI handlers to live as a runtime
service component in the existing ARM Trusted Firmware port. Beside
being able to easily add those handlers to the existing firmware code
this approach has the advantage of avoiding building, maintaining and
loading yet another firmware component. The management processor on the
A64 uses an OpenRISC core, which requires a not fully upstream supported
toolchain. Also this core can remain free to other tasks, like offloading
of realtime-sensitive tasks.
A future implementation may later revisit this decision, adding a proper
mailbox driver and implement the SCPI handler on the OpenRISC core, the
only change needed would be to swap the mailbox node in the DT then.

Another added value is that SCPI brings us sensors and regulators
support, using this very same interface. All that's needed is to add
some firmware code to read the THS register or poke the AXP, for
instance (which ATF does already anyway) and advertise those via a DT
node. There would be no Linux changes needed for that.

As an example this series adds MMC support on top of the basic support
bit posted recently [1].
We use the existing sunxi MMC driver for the purpose of this series,
although it is known to not fully support the new MMC controller in the
A64 chip. I found the support sufficient enough to drive SD cards, though.

Patch 1/5 introduces the SMC mailbox driver, while patch 2/5 adds the
associated DT binding documentation. Patch 3/5 adds the basic SCPI nodes
to the SoC .dtsi, which patch 4/5 complements with the MMC nodes,
referencing the new firmware clocks.
The final patch 5/5 enables the SD card for the two boards which we
currently support.

This series goes on top of the v4 A64 support series [1], which itself
is based on v4.8-rc1.
It allows booting and running a userland from a micro SD card on both
the Pine64 and the BananaPi M64 board.
The matching firmware implementation can be found in the allwinner-scpi
branch here [2]. The clock code in there is probably pretty stupid, but
works and is good enough to at least serve as a proof-of-concept for this
new clock approach.

Please have a look and give comments, I am particularily interested in
how you like this idea. One motiviation is to save the kernel from
endless variations of clock driver code, also to be able to support
newer SoCs much easier without having to submit and maintain tedious
clock patches.

Cheers,
Andre.

[1]: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447512.html
[2]: https://github.com/apritzel/arm-trusted-firmware/commits/allwinner-scpi

Andre Przywara (5):
  mailbox: introduce ARM SMC based mailbox
  DT: mailbox: add binding doc for the ARM SMC mailbox
  arm64: dts: sunxi: add SCPI node to sun50i-a64.dtsi
  arm64: dts: sunxi: add SCPI driven clocks and nodes for A64 MMC
  arm64: dts: sunxi: add MMC nodes to Pine64 and BPi-M64 .dts

 .../devicetree/bindings/mailbox/arm-smc.txt|  53 
 .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts |  29 +
 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  20 +++
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  |  87 +
 drivers/mailbox/Kconfig|   8 ++
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/smc-mailbox.c  | 135 +
 7 files changed, 334 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt
 create mode 100644 drivers/mailbox/smc-mailbox.c

-- 
2.9.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [RFC PATCH 1/5] mailbox: introduce ARM SMC based mailbox

2016-08-09 Thread Andre Przywara 
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure OS again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.

Signed-off-by: Andre Przywara 
---
 drivers/mailbox/Kconfig   |   8 +++
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/smc-mailbox.c | 135 ++
 3 files changed, 145 insertions(+)
 create mode 100644 drivers/mailbox/smc-mailbox.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 97c3729..7ffaef6 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -132,4 +132,12 @@ config BCM_PDC_MBOX
  Mailbox implementation for the Broadcom PDC ring manager,
  which provides access to various offload engines on Broadcom
  SoCs. Say Y here if you want to use the Broadcom PDC.
+
+config SMC_MBOX
+   tristate "Generic ARM SMC mailbox"
+   depends on HAVE_ARM_SMCCC
+   depends on OF
+   help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 66c38e3..8488afd 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -27,3 +27,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
 obj-$(CONFIG_HI6220_MBOX)  += hi6220-mailbox.o
 
 obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
+
+obj-$(CONFIG_SMC_MBOX) += smc-mailbox.o
diff --git a/drivers/mailbox/smc-mailbox.c b/drivers/mailbox/smc-mailbox.c
new file mode 100644
index 000..63f09bd
--- /dev/null
+++ b/drivers/mailbox/smc-mailbox.c
@@ -0,0 +1,135 @@
+/*
+ *  Copyright (C) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This device provides a mechanism for emulating a mailbox by using
+ * smc calls, allowing a "mailbox" consumer to sit in firmware running
+ * on the same core.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int smc_send_data(struct mbox_chan *link, void *data)
+{
+   u32 function_id = (unsigned long)link->con_priv;
+   u32 msg = *(u32 *)data;
+   struct arm_smccc_res res;
+
+   arm_smccc_smc(function_id, msg, 0, 0, 0, 0, 0, 0, );
+
+   mbox_chan_received_data(link, (void *)res.a0);
+
+   return 0;
+}
+
+static int smc_startup(struct mbox_chan *link)
+{
+   return 0;
+}
+
+static void smc_shutdown(struct mbox_chan *link)
+{
+}
+
+/* This mailbox is synchronous, so we are always done. */
+static bool smc_last_tx_done(struct mbox_chan *link)
+{
+   return true;
+}
+
+static const struct mbox_chan_ops smc_mbox_chan_ops = {
+   .send_data  = smc_send_data,
+   .startup= smc_startup,
+   .shutdown   = smc_shutdown,
+   .last_tx_done   = smc_last_tx_done
+};
+
+static int smc_mbox_probe(struct platform_device *pdev)
+{
+   struct device *dev = >dev;
+   struct mbox_controller *mbox;
+   int ret = 0;
+   int i;
+
+   ret = of_property_count_elems_of_size(dev->of_node, "identifiers",
+ sizeof(u32));
+   if (ret < 0)
+   return ret;
+
+   mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
+   if (mbox == NULL)
+   return -ENOMEM;
+
+   mbox->num_chans = ret;
+   mbox->chans = devm_kmalloc_array(dev, mbox->num_chans,
+sizeof(*mbox->chans),
+GFP_KERNEL | __GFP_ZERO);
+   if (!mbox->chans)
+   return -ENOMEM;
+
+   for (i = 0; i < mbox->num_chans; i++) {
+   u32 function_id;
+
+   ret = of_property_read_u32_index(dev->of_node, "identifiers", i,
+_id);
+   if (ret)
+   return ret;
+   mbox->chans[i].con_priv = (void *)(unsigned long)function_id;
+   }
+
+   mbox->txdone_poll = true;
+   mbox->txdone_irq = false;
+   mbox->txpoll_period = 1;
+   mbox->ops = _mbox_chan_ops;
+   mbox->dev = dev;
+
+   ret = mbox_controller_register(mbox);
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, mbox);
+   dev_info(dev, "ARM SMC mailbox enabled with %d chans.\n",
+mbox->num_chans);
+
+   return ret;
+}
+
+static int

[linux-sunxi] [RFC PATCH 2/5] DT: mailbox: add binding doc for the ARM SMC mailbox

2016-08-09 Thread Andre Przywara 
Signed-off-by: Andre Przywara 
---
 .../devicetree/bindings/mailbox/arm-smc.txt| 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.txt

diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.txt 
b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
new file mode 100644
index 000..9919a12
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.txt
@@ -0,0 +1,53 @@
+ARM SMC Mailbox Driver
+==
+
+This mailbox driver uses the ARM smc (secure monitor call) instruction to
+trigger a mailbox-connected activity in firmware running on the very same
+core as the caller. By nature this operation is synchronous and this
+driver provides no way for asynchronous messages to be delivered the other
+way round, from firmware to the OS. However the value of r0/w0 the firmware
+returns after the smc call is delivered as a received message to the
+mailbox framework, so a synchronous communication can be established.
+
+One usecase of this mailbox is the SCP interface, which uses shared memory
+to transfer commands and parameters and mailboxes to trigger a function
+call. This driver allows SoC without a separate management processor (or
+when such a processor is not available or used) to use this standardized
+interface anyway.
+
+The driver requires no special hardware, any core which supports the SMC
+instruction can be used. This requires firmware in monitor mode/EL3 to
+handle the mailbox message.
+
+Mailbox Device Node:
+
+
+Required properties:
+
+- compatible:  Shall be "arm,smc-mbox"
+- #mbox-cells  Shall be 1 - the index of the channel needed.
+- identifiers  An array of 32-bit values specifying the function
+   IDs used by each mailbox channel. Those function IDs
+   follow the ARM SMC calling convention standard [1].
+   There is one identifier per channel and the number
+   of supported channels is determined by the length
+   of this array.
+
+Example:
+
+
+   mailbox: smc_mbox {
+   #mbox-cells = <1>;
+   compatible = "arm,smc-mbox";
+   identifiers = <0x8201 0x8202>;
+   };
+
+   scpi {
+   compatible = "arm,scpi";
+   mboxes = < 0>;
+   shmem = <_scp_shmem>;
+   };
+
+
+[1]
+http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0028a/index.html
-- 
2.9.0

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH v4 3/7] clk: sunxi: add generic multi-parent bus clock gates driver

2016-08-09 Thread Chen-Yu Tsai 
On Tue, Aug 9, 2016 at 2:15 AM, Jean-Francois Moine  wrote:
> On Mon,  8 Aug 2016 18:21:45 +0100
> Andre Przywara  wrote:
>
>> The Allwinner H3 SoC introduced bus clock gates with potentially
>> different parents per clock gate register. The H3 driver chose to
>> hardcode the actual parent clock relation in the code.
>> Add a new driver (which has the potential to drive the H3 and also
>> the simple clock gates as well) which uses the power of DT to describe
>> this relationship in an elegant and flexible way.
>> Using one subnode for every parent clock we get away with a single
>> DT compatible match, which can be used as a fallback value in the
>> actual DTs without the need to add specific compatible strings to the
>> code.  This avoids adding a new driver or function for every new SoC.
>
> The 'parent's of the bus gates are of no interest.
> They are supposed to be (no clear documentation) apb1, apb2, ahb1 and
> ahb2, but, as you well noticed in the patch 5/7, these clocks are fixed
> and have no gate. Some of them are parents of real clocks, but they
> don't bring anything to the bus gates of the other clocks.

Yes they are. Some devices, such as UARTs and I2C controllers, need
to get the clock rate of the gate and calculate the proper internal
divider.

> As I wrote previously, the simplest is to ungate/gate the clocks in
> both the bus and clock registers on clk_prepare/unprepare.
> Then, your 'multi-bus-gates' would be simply a generic 'multi-gates'.

This is somewhat misleading. What "clock" registers are you referring
to? There are no "bus" registers. The reason we call them "bus clock
gates" is because they are mashed together, instead of having clearly
separated registers for each AHB/APB bus.

And if you want just a generic clock gates driver, we already have
the "simple-gates" driver.

Regards
ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Problems with Orange Pi mini

2016-08-09 Thread Benjamin Henrion 
On Tue, Aug 9, 2016 at 4:55 AM, Stefan Monnier  wrote:
> I recently noticed two problems with my Orange Pi mini running Debian's
> stock 4.6.0-1-armmp kernel:
>
> - Reboot doesn't work.  I think this has been the case "for ever", but
>   I just noticed that it's still the same (in the last few months
>   I never rebooted this machine, so I didn't notice the problem very
>   much): if I do "reboot" the machine does most of the shutdown
>   procedure (at least, according to the sound of the HDD), but it
>   then gets stuck there waiting for something.
>   The same works fine with the same rootfs on a BananaPi.

Can you try if that works:

echo b > /proc/sysrq-trigger

That's the hardcore version of "reboot" which does wait any process to
nicely terminate, including filesystems.

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.