[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqJA6MEtnF35ThPDgVmEZHyui39-HLsefWPQ1tzzfLAW3w@mail.gmail.com>
Date: Sun, 23 Aug 2015 17:43:03 -0500
From: Rob Herring <robherring2@...il.com>
To: Chen-Yu Tsai <wens@...e.org>
Cc: Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Mark Brown <broonie@...nel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-sunxi <linux-sunxi@...glegroups.com>,
Hans de Goede <hdegoede@...hat.com>,
Meng Zhang <kevin@...winnertech.com>,
Shuge <shuge@...winnertech.com>, kevin.z.m.zh@...il.com
Subject: Re: [PATCH v3 1/8] rsb: Add generic Reduced Serial Bus (RSB)
controller binding documentation
On Tue, Aug 18, 2015 at 11:20 PM, Chen-Yu Tsai <wens@...e.org> wrote:
> Reduced Serial Bus is a proprietary 2-line push-pull serial bus
> supporting multiple slave devices.
>
> It was developed by Allwinner, Inc. and used by Allwinner and X-Powers,
> Inc. for their line of PMICs and other peripheral ICs.
>
> Signed-off-by: Chen-Yu Tsai <wens@...e.org>
> ---
> Documentation/devicetree/bindings/rsb/rsb.txt | 50 +++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rsb/rsb.txt
>
> diff --git a/Documentation/devicetree/bindings/rsb/rsb.txt b/Documentation/devicetree/bindings/rsb/rsb.txt
> new file mode 100644
> index 000000000000..0b027948ca9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rsb/rsb.txt
> @@ -0,0 +1,50 @@
> +Reduced Serial Bus (RSB) Controller
> +
> +This document defines a generic set of bindings for use by RSB controllers.
> +A controller is modelled in device tree as a node with zero or more child
> +nodes, each representing a unique slave device on the bus.
> +
> +Required properties:
> +
> + - #address-cells : must be 2
> + - #size-cells : must be 0
> +
> +Optional properties:
> +
> + - clock-frequency : Desired bus clock frequency in Hz. Maximum is 20 MHz.
> +
> +Child nodes:
> +
> +An RSB controller node can contain zero or more child nodes representing
> +slave devices on the bus. Child 'reg' properties are specified as a
> +runtime address, hardware address pair. The hardware address is hardwired
> +in the device, which can normally be found in the datasheet. The runtime
> +address is set by software. No 2 devices on the same bus shall have the
> +same runtime address.
> +
> +Valid runtime addresses - There are only 15 valid runtime addresses:
> +
> + 0x17, 0x2d, 0x3a, 0x4e, 0x59, 0x63, 0x74, 0x8b,
> + 0x9c, 0xa6, 0xb1, 0xc5, 0xd2, 0xe8, 0xff
> +
> +It is highly recommended that one choose the same runtime addresses as
> +vendor BSPs use so that a) the addresses remain the same across different
> +software systems, and b) addresses of supported and listed slave devices
> +don't conflict with unsupported or not yet listed devices.
I fail to understand why the run-time address belongs in DT or why
alignment to vendor BSP matters? I can see the desire to align DTs if
the vendor OS was dependent on having this information. Having to
access the vendor OS to determine what address to pick does not seem
like the right way to write a DTS. It seems to me that the RSB bus
driver should allocate run-time addresses dynamically.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists