* Re: [PATCH v4 2/9] doc: DT: venus: binding document for Qualcomm video driver
From: Rob Herring @ 2016-12-06 0:22 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <1480583001-32236-3-git-send-email-stanimir.varbanov@linaro.org>
On Thu, Dec 01, 2016 at 11:03:14AM +0200, Stanimir Varbanov wrote:
> Add binding document for Venus video encoder/decoder driver
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
> ---
> Rob, I have removed vmem clocks, interrupts and reg properties
> for vmem thing. Probably I will come with a separate platform
> driver fro that and pass the video memory DT node as phandle.
Looks good, a couple of minor things below.
>
> .../devicetree/bindings/media/qcom,venus.txt | 82 ++++++++++++++++++++++
> 1 file changed, 82 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
> new file mode 100644
> index 000000000000..a64b4ea1ebba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
> @@ -0,0 +1,82 @@
> +* Qualcomm Venus video encode/decode accelerator
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Value should contain one of:
> + - "qcom,msm8916-venus"
> + - "qcom,msm8996-venus"
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "base" Venus register base
-names is kind of pointless with only one.
> +- interrupts:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Should contain interrupts as listed in the interrupt-names
> + property.
> +- interrupt-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain following entries:
> + - "venus" Venus interrupt line
ditto
> +- clocks:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A List of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "core" Core video accelerator clock
> + - "iface" Video accelerator AHB clock
> + - "bus" Video accelerator AXI clock
> +- clock-names:
> + Usage: required for msm8996
It's not clear if this is in addition to the above list. I'd guess not
and you should make it clear the above applies to the 8916 only.
> + Value type: <stringlist>
> + Definition: Should contain the following entries:
> + - "subcore0" Subcore0 video accelerator clock
> + - "subcore1" Subcore1 video accelerator clock
> + - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
> + - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
> + - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
> + - "mmagic_video_bus" MMAGIC video AXI clock
> + - "video_mbus" Video MAXI clock
> +- power-domains:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- rproc:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A phandle to remote processor responsible for
> + firmware loading and processor booting.
> +
> +- iommus:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* An Example
> + video-codec@1d00000 {
> + compatible = "qcom,msm8916-venus";
> + reg = <0x01d00000 0xff000>;
> + reg-names = "base";
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "venus";
> + clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
> + <&gcc GCC_VENUS0_AHB_CLK>,
> + <&gcc GCC_VENUS0_AXI_CLK>;
> + clock-names = "core", "iface", "bus";
> + power-domains = <&gcc VENUS_GDSC>;
> + rproc = <&venus_rproc>;
> + iommus = <&apps_iommu 5>;
> + };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] dt: bindings: zx: Add header for PM domains specifiers
From: Baoyou Xie @ 2016-12-06 0:21 UTC (permalink / raw)
To: jun.nie-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A,
baoyou.xie-QSEj5FYQhm4dnm+yROfE0A,
xie.baoyou-Th6q7B73Y6EnDS1+zs4M5A,
chen.chaokai-Th6q7B73Y6EnDS1+zs4M5A,
wang.qiang01-Th6q7B73Y6EnDS1+zs4M5A
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
include/dt-bindings/arm/zte_pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/arm/zte_pm_domains.h
diff --git a/include/dt-bindings/arm/zte_pm_domains.h b/include/dt-bindings/arm/zte_pm_domains.h
new file mode 100644
index 0000000..1485e8d
--- /dev/null
+++ b/include/dt-bindings/arm/zte_pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /*g1v6*/
+#define DM_ZX296718_VCE 2 /*h1v6*/
+#define DM_ZX296718_HDE 3 /*g2v2*/
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H */
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Dmitry Torokhov @ 2016-12-06 0:16 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
Jiri Kosina, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Doug Anderson,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Benjamin Tissoires, linux-input-u79uwXL29TY76Z2rM5mHXA,
Caesar Wang
In-Reply-To: <20161205235908.rmiyd7io4kddple6@rob-hp-laptop>
On Mon, Dec 05, 2016 at 05:59:08PM -0600, Rob Herring wrote:
> On Thu, Dec 01, 2016 at 09:24:50AM -0800, Brian Norris wrote:
> > Hi Benjamin and Rob,
> >
> > On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
> > > On Nov 30 2016 or thereabouts, Brian Norris wrote:
> > > > From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > >
> > > > Add a compatible string and regulator property for Wacom W9103
> > > > digitizer. Its VDD supply may need to be enabled before using it.
> > > >
> > > > Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > > > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > > > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > > > ---
> > > > v1 was a few months back. I finally got around to rewriting it based on
> > > > DT binding feedback.
> > > >
> > > > v2:
> > > > * add compatible property for wacom
> > > > * name the regulator property specifically (VDD)
> > > >
> > > > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > > index 488edcb264c4..eb98054e60c9 100644
> > > > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid will handle the communication
> > > > with the device and the generic hid core layer will handle the protocol.
> > > >
> > > > Required properties:
> > > > -- compatible: must be "hid-over-i2c"
> > > > +- compatible: must be "hid-over-i2c", or a device-specific string like:
> > > > + * "wacom,w9013"
> > >
> > > NACK on this one.
> > >
> > > After re-reading the v1 submission I realized Rob asked for this change,
> > > but I strongly disagree.
> > >
> > > HID over I2C is a generic protocol, in the same way HID over USB is. We
> > > can not start adding device specifics here, this is opening the can of
> > > worms. If the device is a HID one, nothing else should matter. The rest
> > > (description of the device, name, etc...) is all provided by the
> > > protocol.
> >
> > I should have spoken up when Rob made the suggestion, because I more or
> > less agree with Benjamin here. I don't really see why this needs to have
> > a specialized compatible string, as the property is still fairly
> > generic, and the entire device handling is via a generic protocol. The
> > fact that we manage its power via a regulator is not very
> > device-specific.
>
> It doesn't matter that the protocol is generic. The device attached and
> the implementation is not. Implementations have been known to have
> bugs/quirks (generally speaking, not HID over I2C in particular). There
> are also things outside the scope of what is 'hid-over-i2c' like what's
> needed to power-on the device which this patch clearly show.
>
> This is no different than a panel attached via LVDS, eDP, etc., or
> USB/PCIe device hard-wired on a board. They all use standard protocols
> and all need additional data to describe them. Of course, adding a
> single property for a delay would not be a big deal, but it's never
> ending. Next you need multiple supplies, GPIO controls, mutiple
> delays... This has been discussed to death already. As Thierry Reding
> said, you're not special[1].
>
> Now if you want to make 'hid-over-i2c' a fallback to 'wacom,w9013', I'm
> fine with that.
So if I understand it correctly the only change is to have DTS specify
compatible = "wacom,w9013", "hid-over-i2c";
and no actual changes to the driver itself with regard to the new
compatible string, correct?
I wonder what, besides breaking module autoload, this really buys us?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-05 23:59 UTC (permalink / raw)
To: Brian Norris, Benjamin Tissoires
Cc: Jiri Kosina, Caesar Wang, linux-rockchip, linux-input, devicetree,
linux-kernel, Dmitry Torokhov, Mark Rutland, Doug Anderson
In-Reply-To: <20161201172448.GA46688@google.com>
On Thu, Dec 01, 2016 at 09:24:50AM -0800, Brian Norris wrote:
> Hi Benjamin and Rob,
>
> On Thu, Dec 01, 2016 at 03:34:34PM +0100, Benjamin Tissoires wrote:
> > On Nov 30 2016 or thereabouts, Brian Norris wrote:
> > > From: Caesar Wang <wxt@rock-chips.com>
> > >
> > > Add a compatible string and regulator property for Wacom W9103
> > > digitizer. Its VDD supply may need to be enabled before using it.
> > >
> > > Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > Cc: Jiri Kosina <jikos@kernel.org>
> > > Cc: linux-input@vger.kernel.org
> > > Signed-off-by: Brian Norris <briannorris@chromium.org>
> > > ---
> > > v1 was a few months back. I finally got around to rewriting it based on
> > > DT binding feedback.
> > >
> > > v2:
> > > * add compatible property for wacom
> > > * name the regulator property specifically (VDD)
> > >
> > > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > index 488edcb264c4..eb98054e60c9 100644
> > > --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> > > @@ -11,12 +11,16 @@ If this binding is used, the kernel module i2c-hid will handle the communication
> > > with the device and the generic hid core layer will handle the protocol.
> > >
> > > Required properties:
> > > -- compatible: must be "hid-over-i2c"
> > > +- compatible: must be "hid-over-i2c", or a device-specific string like:
> > > + * "wacom,w9013"
> >
> > NACK on this one.
> >
> > After re-reading the v1 submission I realized Rob asked for this change,
> > but I strongly disagree.
> >
> > HID over I2C is a generic protocol, in the same way HID over USB is. We
> > can not start adding device specifics here, this is opening the can of
> > worms. If the device is a HID one, nothing else should matter. The rest
> > (description of the device, name, etc...) is all provided by the
> > protocol.
>
> I should have spoken up when Rob made the suggestion, because I more or
> less agree with Benjamin here. I don't really see why this needs to have
> a specialized compatible string, as the property is still fairly
> generic, and the entire device handling is via a generic protocol. The
> fact that we manage its power via a regulator is not very
> device-specific.
It doesn't matter that the protocol is generic. The device attached and
the implementation is not. Implementations have been known to have
bugs/quirks (generally speaking, not HID over I2C in particular). There
are also things outside the scope of what is 'hid-over-i2c' like what's
needed to power-on the device which this patch clearly show.
This is no different than a panel attached via LVDS, eDP, etc., or
USB/PCIe device hard-wired on a board. They all use standard protocols
and all need additional data to describe them. Of course, adding a
single property for a delay would not be a big deal, but it's never
ending. Next you need multiple supplies, GPIO controls, mutiple
delays... This has been discussed to death already. As Thierry Reding
said, you're not special[1].
Now if you want to make 'hid-over-i2c' a fallback to 'wacom,w9013', I'm
fine with that.
Rob
[1] https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Brian Norris @ 2016-12-05 23:54 UTC (permalink / raw)
To: Rob Herring
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <20161205234248.tqnpruk442n4lgs5@rob-hp-laptop>
Hi Rob,
On Mon, Dec 05, 2016 at 05:42:48PM -0600, Rob Herring wrote:
> On Wed, Nov 30, 2016 at 05:21:27PM -0800, Brian Norris wrote:
> > From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > Add a compatible string and regulator property for Wacom W9103
> > digitizer. Its VDD supply may need to be enabled before using it.
> >
> > Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> > ---
> > v1 was a few months back. I finally got around to rewriting it based on
> > DT binding feedback.
> >
> > v2:
> > * add compatible property for wacom
> > * name the regulator property specifically (VDD)
> >
> > Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Thanks but (unfortunately) there've been 2 new versions since then.
Specifically, Benjamin NACK'ed this patch and requested we NOT include
device/manufacturer-specific compatible properties here. In fact, the
binding is still rather generic and IMO (and in Benjamin's opinion)
doesn't really need to be restricted to a specific device.
Please consider reviewing Benjamin's requests and my recent changes.
Benjamin has one small remaining comment on v4, and I plan to send the
5th (and final?) version once I'm confident you and Benjamin agree :)
Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/2] devicetree: i2c-hid: Add Wacom digitizer + regulator support
From: Rob Herring @ 2016-12-05 23:42 UTC (permalink / raw)
To: Brian Norris
Cc: Jiri Kosina, Benjamin Tissoires, Caesar Wang,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <1480555288-142791-1-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
On Wed, Nov 30, 2016 at 05:21:27PM -0800, Brian Norris wrote:
> From: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Add a compatible string and regulator property for Wacom W9103
> digitizer. Its VDD supply may need to be enabled before using it.
>
> Signed-off-by: Caesar Wang <wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Jiri Kosina <jikos-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> v1 was a few months back. I finally got around to rewriting it based on
> DT binding feedback.
>
> v2:
> * add compatible property for wacom
> * name the regulator property specifically (VDD)
>
> Documentation/devicetree/bindings/input/hid-over-i2c.txt | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Rob Herring @ 2016-12-05 23:40 UTC (permalink / raw)
To: Philipp Zabel
Cc: Arnd Bergmann, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
zhangfei, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480687813.2460.19.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Dec 02, 2016 at 03:10:13PM +0100, Philipp Zabel wrote:
> Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > Hi, Arnd
> > >
> > > On 2016年12月01日 20:05, Arnd Bergmann wrote:
> > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > >> + 0x20 0x10 /* 1: i2c1 */
> > > >> + 0x20 0x20 /* 2: i2c2 */
> > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > >> + };
> > > >> +
> > > >> +Specifying reset lines connected to IP modules
> > > >> +==============================================
> > > >> +example:
> > > >> +
> > > >> + i2c0: i2c@..... {
> > > >> + ...
> > > >> + resets = <&iomcu_rst 0>;
> > > >> + ...
> > > >> + };
> > > > I don't really like this approach, since now the information is
> > > > in two places. Why not put the data into the reset specifier
> > > > directly when it is used?
>
> From my point of view, with the binding above, all reset controller
> register/bit layout information is in a single place and can be easily
> compared to a list in the reference manual, whereas with your suggestion
> the description of the reset controller register layout is spread
> throughout one or even several dtsi files.
Which can be solved by tools.
> Also, since no two reset controllers are exactly the same, we get a
> proliferation of different slightly phandle argument meanings.
phandle args are supposed to be specific to the phandle it points to.
Otherwise, we'd never need more than 1 cell and everything could be a
lookup table.
>
> > > Any example, still not understand.
> > > They are consumer and provider.
> >
> > I mean in the i2c node, have
> >
> > i2c0: i2c@..... {
> > ...
> > resets = <&iomcu_rst 0x20 0x8>;
> > ...
> > }
>
> There already are a few drivers that use this, and I fear people having
> to change their bindings because new flags are needed that have not been
> previously thought of.
>
Drivers that use what?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] Documentation: dt: iio: add st_lsm6dsx sensor device binding
From: Rob Herring @ 2016-12-05 23:30 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, lorenzo.bianconi-qxv4g6HH51o
In-Reply-To: <20161130200559.29910-3-lorenzo.bianconi-qxv4g6HH51o@public.gmane.org>
On Wed, Nov 30, 2016 at 09:05:59PM +0100, Lorenzo Bianconi wrote:
> Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/iio/imu/st_lsm6dsx.txt | 24 ++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: spi: Add documentation for the Armada 3700 SPI Controller
From: Rob Herring @ 2016-12-05 23:27 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Brown, linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Ian Campbell, Pawel Moll,
Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161130094351.2748-4-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Nov 30, 2016 at 10:43:49AM +0100, Romain Perier wrote:
> This adds the devicetree bindings documentation for the SPI controller
> present in the Marvell Armada 3700 SoCs.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> .../devicetree/bindings/spi/spi-armada-3700.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-armada-3700.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 4/9] dt-bindings: iio: iio-mux: document iio-mux bindings
From: Rob Herring @ 2016-12-05 23:26 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Wolfram Sang, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, Arnd Bergmann, Greg Kroah-Hartman, linux-i2c,
devicetree, linux-iio, linux-doc
In-Reply-To: <1480493823-21462-5-git-send-email-peda@axentia.se>
On Wed, Nov 30, 2016 at 09:16:58AM +0100, Peter Rosin wrote:
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> .../bindings/iio/multiplexer/iio-mux.txt | 40 ++++++++++++++++++++++
> MAINTAINERS | 6 ++++
> 2 files changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
I'm still not convinced about this binding, but don't really have more
comments ATM. Sending 6 versions in 2 weeks or so doesn't really help
either.
> diff --git a/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
> new file mode 100644
> index 000000000000..8080cf790d82
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/multiplexer/iio-mux.txt
> @@ -0,0 +1,40 @@
> +IIO multiplexer bindings
> +
> +If a multiplexer is used to select which hardware signal is fed to
> +e.g. an ADC channel, these bindings describe that situation.
> +
> +Required properties:
> +- compatible : "iio-mux"
This is a Linuxism. perhaps "adc-mux".
> +- io-channels : Channel node of the parent channel that has multiplexed
> + input.
> +- io-channel-names : Should be "parent".
> +- #address-cells = <1>;
> +- #size-cells = <0>;
> +- mux-controls : Mux controller node to use for operating the mux
> +- channels : List of strings, labeling the mux controller states.
> +
> +The multiplexer state as described in ../misc/mux-controller.txt
> +
> +For each non-empty string in the channels property, an iio channel will
> +be created. The number of this iio channel is the same as the index into
> +the list of strings in the channels property, and also matches the mux
> +controller state.
> +
> +Example:
> + mux: mux-controller {
> + compatible = "mux-gpio";
> + #mux-control-cells = <0>;
> +
> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> + <&pioA 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + mux-controls = <&mux>;
> +
> + channels = "sync", "in", system-regulator";
> + };
^ permalink raw reply
* [PATCH 2/2] arm64: dts: NS2: add support for XMC form factor
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
In-Reply-To: <1480979542-26871-1-git-send-email-jon.mason@broadcom.com>
The BCM958712DxXMC board is a smaller form factor typically used as
controller boards for switches. This smaller board has less devices
pinned out, so only a few need be populated in the device tree.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
2 files changed, 192 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index 05faf2a..f1caece 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,5 +1,5 @@
dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
-dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
new file mode 100644
index 0000000..99a2723
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
@@ -0,0 +1,191 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Broadcom. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "ns2.dtsi"
+
+/ {
+ model = "Broadcom NS2 XMC";
+ compatible = "brcm,ns2-xmc", "brcm,ns2";
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "earlycon=uart8250,mmio32,0x66130000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x000000000 0x80000000 0x00000001 0x00000000>;
+ };
+};
+
+&enet {
+ status = "ok";
+};
+
+&i2c0 {
+ status = "ok";
+};
+
+&i2c1 {
+ status = "ok";
+};
+
+&mdio_mux_iproc {
+ mdio@10 {
+ gphy0: eth-phy@10 {
+ reg = <0x10>;
+ };
+ };
+};
+
+&nand {
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-bus-width = <16>;
+ brcm,nand-oob-sector-size = <16>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "nboot";
+ reg = <0x00000000 0x00280000>; /* 2.5MB */
+ read-only;
+ };
+
+ partition@280000 {
+ label = "nenv";
+ reg = <0x00280000 0x00040000>; /* 0.25MB */
+ read-only;
+ };
+
+ partition@2c0000 {
+ label = "ndtb";
+ reg = <0x002c0000 0x00040000>; /* 0.25MB */
+ read-only;
+ };
+
+ partition@300000 {
+ label = "nsystem";
+ reg = <0x00300000 0x03d00000>; /* 61MB */
+ read-only;
+ };
+
+ partition@4000000 {
+ label = "nrootfs";
+ reg = <0x04000000 0x06400000>; /* 100MB */
+ };
+
+ partition@0a400000{
+ label = "ncustfs";
+ reg = <0x0a400000 0x35c00000>; /* 860MB */
+ };
+ };
+};
+
+&pci_phy0 {
+ status = "ok";
+};
+
+&pcie0 {
+ status = "ok";
+};
+
+&pcie8 {
+ status = "ok";
+};
+
+&sata_phy0 {
+ status = "ok";
+};
+
+&sata_phy1 {
+ status = "ok";
+};
+
+&sata {
+ status = "ok";
+};
+
+&qspi {
+ flash: m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p80";
+ spi-max-frequency = <62500000>;
+ m25p,default-addr-width = <3>;
+ reg = <0x0 0x0>;
+
+ partition@0 {
+ label = "bl0";
+ reg = <0x00000000 0x00080000>; /* 512KB */
+ };
+
+ partition@80000 {
+ label = "fip";
+ reg = <0x00080000 0x00150000>; /* 1344KB */
+ };
+
+ partition@1e0000 {
+ label = "env";
+ reg = <0x001e0000 0x00010000>;/* 64KB */
+ };
+
+ partition@1f0000 {
+ label = "dtb";
+ reg = <0x001f0000 0x00010000>; /* 64KB */
+ };
+
+ partition@200000 {
+ label = "kernel";
+ reg = <0x00200000 0x00e00000>; /* 14MB */
+ };
+
+ partition@1000000 {
+ label = "rootfs";
+ reg = <0x01000000 0x01000000>; /* 16MB */
+ };
+ };
+};
+
+&uart3 {
+ status = "ok";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: NS2: reserve memory for Nitro firmware
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
In-Reply-To: <1480979542-26871-1-git-send-email-jon.mason@broadcom.com>
Nitro firmware is loaded into memory by the bootloader at a specific
location. Set this memory range aside to prevent the kernel from using
it.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 96ed47b..9f9e203 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -30,6 +30,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+/memreserve/ 0x81000000 0x00200000;
+
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/bcm-ns2.h>
--
2.7.4
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: NS2: XMC support and Nitro memreserve
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Florian Fainelli
Cc: devicetree, bcm-kernel-feedback-list, linux-arm-kernel,
linux-kernel
Add support for the NS2 XMC formfactor via a new DTS file. Also, set
aside memory for Nitro firmware in the NS2 DTSI file.
Jon Mason (2):
arm64: dts: NS2: reserve memory for Nitro firmware
arm64: dts: NS2: add support for XMC form factor
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 +
3 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
--
2.7.4
^ permalink raw reply
* Re: [PATCH 1/3] Add DT bindings documentation for NS2 USB DRD phy
From: Rob Herring @ 2016-12-05 23:09 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, Kishon Vijay Abraham I, Ray Jui, Scott Branden,
Jon Mason, Catalin Marinas, Will Deacon,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1480485338-23451-2-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 30, 2016 at 11:25:36AM +0530, Raviteja Garimella wrote:
> This patch adds documentation for NS2 DRD Phy driver DT bindings
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 40 ++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
> new file mode 100644
> index 0000000..5857f99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
> @@ -0,0 +1,40 @@
> +BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
> +
> +Required properties:
> + - compatible: brcm,ns2-drd-phy
> + - reg: offset and length of the NS2 PHY related registers.
> + - reg-names
> + The below registers must be provided.
> + icfg - for DRD ICFG configurations
> + rst-ctrl - for DRD IDM reset
> + crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
> + usb2-strap - for port over current polarity reversal
> + - #phy-cells: Must be 0. No args required.
> + - vbus-gpios: vbus gpio binding
> + - id-gpios: id gpio binding
> +
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> +
> +Example:
> + gpio_g: gpio@660a0000 {
You don't really need to show gpio node for the example. Otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] Add DT bindings documentation for Synopsys UDC driver
From: Rob Herring @ 2016-12-05 23:04 UTC (permalink / raw)
To: Raviteja Garimella
Cc: Mark Rutland, Greg Kroah-Hartman, Felipe Balbi,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480485910-7797-2-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Nov 30, 2016 at 11:35:09AM +0530, Raviteja Garimella wrote:
> This patch adds documentation for Synopsis Designware Cores AHB
> Subsystem Device Controller (UDC).
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/usb/snps,dw-ahb-udc.txt | 29 ++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> new file mode 100644
> index 0000000..64e1fbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/snps,dw-ahb-udc.txt
> @@ -0,0 +1,29 @@
> +Synopsys USB Device controller.
> +
> +The device node is used for Synopsys Designware Cores AHB
> +Subsystem Device Controller (UDC).
> +
> +Required properties:
> + - compatible: should be "snps,dw-ahbudc"
Needs an SoC specific compatible string.
> + - reg: Offset and length of UDC register set
> + - interrupts: description of interrupt line
> + - phys: phandle to phy node.
> + - phy-names: name of phy node. Must be usb2drd.
A name is pointless when there's only 1 phy. Is this a device or dual
role device(DRD)?
> + - extcon: phandle to the extcon device
I don't think extcon should be required. If this is UDC only, I'm not
sure why you'd need it.
> +
> +Example:
> +
> + usbdrd_phy: phy@6501c000 {
> + #phy-cells = <0>;
> + compatible = "brcm,ns2-drd-phy";
> + reg = <0x66000000 0x1000>,
> + }
> +
> + udc_dwc: usb@664e0000 {
> + compatible = "snps,dw-ahb-udc";
Doesn't match above.
> + reg = <0x664e0000 0x2000>;
> + interrupts = <GIC_SPI 424 IRQ_TYPE_LEVEL_HIGH>;
> + phys = <&usbdrd_phy>;
> + phy-names = "usb2drd";
> + extcon = <&usbdrd_phy>";
You are already describing the phy connection, you shouldn't need both.
> + };
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 11/14] ASoC: add simple-graph-card document
From: Rob Herring @ 2016-12-05 22:58 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <87lgvvw92p.wl%kuninori.morimoto.gx@renesas.com>
On Sun, Dec 04, 2016 at 11:48:49PM +0000, Kuninori Morimoto wrote:
>
> Hi Rob, Mark
>
> > > +++ b/Documentation/devicetree/bindings/sound/simple-graph-card.txt
> > > @@ -0,0 +1,67 @@
> > > +Simple-Graph-Card:
> >
> > There's nothing simple about this. graph-audio-card or audio-card-graph.
>
> I have no objection about naming, but this is one of simple-xxx-card series.
> And, this is very simple from ALSA SoC point of view...
>
> > > +rcar_sound {
> > > + ...
> > > + port {
> > > + compatible = "asoc-simple-graph-card";
> >
> > Do you have an example where you'd have multiple ports? If not, this
> > should go up a level.
>
> ALSA SoC needs 3 type of driver, CPU/Codec/Card. But HW is SoC <-> Codec.
> Thus, "CPU" side DT needs to call "Card" portion, and ALSA SoC needs to
> select Card type (graph-audio-card, graph-scu-card, etc, etc....).
> Above it for it.
>
> SoC {
> compatible = "cpu_driver_compatible_name";
> ...
> port {
> compatible = "card_driver_compatible_name";
> ...
> };
> };
>
> Here, SoC driver "cpu_driver_compatible_name" will handle CPU and its
> each port settings. And it will probes "card_driver_compatible_name".
> "card_driver_compatible_name" will connect CPU <-> Codec via ALSA SoC.
Don't design bindings around what ASoC wants and don't explain it in
terms of how ALSA works. Design bindings in a way that reflects the h/w.
This explanation seems completely wrong to me. It seems like you are
abusing OF graph to just create 2 instances of a simple-card which would
be working around some ASoC limitation.
I'd expect the top level node to be the card node that knows how to find
all the components. The graph should reflect the data flow. For example,
the data goes to audio DSP to I2S host to codec to amp.
Rob
^ permalink raw reply
* Re: [PATCH v5 13/14] ASoC: add simple-graph-scu-card document
From: Rob Herring @ 2016-12-05 22:40 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Mark Brown, Linux-ALSA, Liam Girdwood, Simon, Laurent, Guennadi,
Grant Likely, Frank Rowand, Linux-DT, Linux-Kernel
In-Reply-To: <871sxwwcas.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On Mon, Nov 28, 2016 at 02:48:37AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
> ---
> .../bindings/sound/simple-graph-scu-card.txt | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt b/Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
> new file mode 100644
> index 0000000..b0e46ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/simple-graph-scu-card.txt
> @@ -0,0 +1,69 @@
> +Simple-Graph-SCU-Card:
> +
> +Simple-Graph-SCU-Card specifies audio DAI connections of SoC <-> codec.
> +It is based on common bindings for device graphs.
> +see ${LINUX}/Documentation/devicetree/bindings/graph.txt
> +
> +Basically, Simple-Graph-SCU-Card property is same as Simple-Card / Simple-Graph-Card.
> +see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.txt
> + ${LINUX}/Documentation/devicetree/bindings/sound/simple-graph-card.txt
> +
> +Main difference between Simple-Graph-Card and Simple-Graph-SCU-Card is that
> +Simple-Graph-SCU-Card can use multi CPU.
So it can have more that 1 port? At least for the bindings, I think you
should combine these 2 bindings. Whether the driver should be combined
is separate question. I imagine you have 2 compatible strings because
you have 2 drivers, but that isn't really a reason to have 2.
I still have no idea what SCU is.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
From: Dinh Nguyen @ 2016-12-05 22:31 UTC (permalink / raw)
To: Marek Vasut, Dinh Nguyen
Cc: Masahiro Yamada, Rob Herring,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Boris Brezillon, Brian Norris,
Richard Weinberger, David Woodhouse, Cyrille Pitchen,
Mark Rutland, Dinh Nguyen, Alan Tull, Chin Liang See
In-Reply-To: <9f9750d6-206d-1e8e-88db-ffe6e95e5dbb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 12/05/2016 03:29 PM, Marek Vasut wrote:
> On 12/05/2016 09:51 PM, Dinh Nguyen wrote:
>> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote:
>>>> Hi Marek,
>>>>
>>>>
>>>> 2016-12-05 12:44 GMT+09:00 Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote:
>>>>>> Hi Dinh,
>>>>>>
>>>>>>
>>>>>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>>>>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
>>>>>>>>> Hi Rob,
>>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>:
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (Plan A)
>>>>>>>>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant)
>>>>>>>>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant)
>>>>>>>>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant)
>>>>>>>>>>>
>>>>>>>>>>> (Plan B)
>>>>>>>>>>> "altera,denali-nand" (for Altera SOCFPGA variant)
>>>>>>>>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant)
>>>>>>>>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant)
>>>>>>>>>
>>>>>>>>>> Let the Altera folks worry about their stuff. At least for soft IP in
>>>>>>>>>> FPGA, it's a bit of a special case. The old string can remain as bad
>>>>>>>>>> as it is.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hmm, I am not sure if this IP would fit in FPGA
>>>>>>>>> (to use it along with NIOS-II?)
>>>>>>>>>
>>>>>>>>> (even if it happened, nothing of this IP would be customizable on users' side.
>>>>>>>>> When buying the IP, SoC vendors submit a list of desired features.
>>>>>>>>> Denali (now Cadence) generates the RTL according to the configuration sheet.
>>>>>>>>> The function is fixed at this point. So, generic compatible would be
>>>>>>>>> useless anyway.)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If we are talking about SOCFPGA,
>>>>>>>>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
>>>>>>>>> It consists of two parts:
>>>>>>>>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART,
>>>>>>>>> USB, SD, NAND, ...)
>>>>>>>>> [2] FPGA part (User design logic)
>>>>>>>>>
>>>>>>>>> The Denali NAND controller is included in [1].
>>>>>>>>> So, as far as we talk about the Denali on SOCFPGA,
>>>>>>>>> it is as hard-wired as Intel, Socionext's ones.
>>>>>>>>
>>>>>>>> That's correct, the Denali NAND IP in altera socfpga is a hardware
>>>>>>>> block. You can make it available to the fabric too, but by default
>>>>>>>> it's used by the ARM part of the chip, so for this discussion, you
>>>>>>>> can forget that the FPGA part exists altogether.
>>>>>>>>
>>>>>>>> I would be in favor of plan B, since it seems to be the more often
>>>>>>>> taken approach. A nice example is ci-hdrc:
>>>>>>>>
>>>>>>>> $ git grep compatible drivers/usb/chipidea/
>>>>>>>>
>>>>>>>>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
>>>>>>>>>> The fact that it is denali is part of the documentation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Let me think about this.
>>>>>>>>>
>>>>>>>>> Socionext bought two version of Denali IP,
>>>>>>>>> and we are now re-using the newer one (v5b) for several SoCs.
>>>>>>>>> Socionext has some more product lines other than Uniphier SoC family,
>>>>>>>>> perhaps wider re-use might happen in the future.
>>>>>>>>>
>>>>>>>>> At first, I included "uniphier" in compatible, but I am still wondering
>>>>>>>>> if such a specific string is good or not.
>>>>>>>>>
>>>>>>>>> Also, comments from Altera engineers are appreciated.
>>>>>>>
>>>>>>> Sorry, it's taken me a while to add comments. My altera email is very spotty now
>>>>>>> that the Intel merge is completed. Please use dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org for any future
>>>>>>> communications.
>>>>>>>
>>>>>>> Yes, everything that is said so far for the NAND controller on the
>>>>>>> SoCFPGA is correct. I added the binding for the controller a while
>>>>>>> back, but unfortunately, we never added the NAND interface to the
>>>>>>> devkit, so we did not do much in terms of enabling it.
>>>>>>>
>>>>>>> I think the only SoCFPGA board I know that has the NAND interface active is
>>>>>>> the TRCom board, but I have never seen that board.
>>>>>>>
>>>>>>> I don't have any strong opinions on this matter, just as long as the
>>>>>>> original binding
>>>>>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping
>>>>>>> that binding.
>>>>>>>
>>>>>>
>>>>>> I am proposing to add "altera,denali-nand" for Altera.
>>>>>> For what, do you need the generic compatible?
>>>>>> This IP has no default for it to fallback to.
>>>>>
>>>>> IMO just for compatibility reasons with old DTs .
>>>>
>>>> We generally contribute for
>>>> a "working driver" (at least, should be functional to some extent)
>>>> and "DT binding" bundled together.
>>>>
>>>> However, Altera upstreamed the DT binding first
>>>> (then some parts of the DT binding turned out wrong),
>>>> but they did not upstream needed driver changes in the end.
>>>>
>>>> So, the mainline driver has never worked on SOCFPGA, right?
>>>
>>> Most likely it never worked, yes.
>>>
>>
>> Right, looking through our downstream support, we may need to upstream a
>> few changes to make upstream driver work on SoCFPGA.
>>
>>>> Removing "denali,denali-nand-dt" is not breakage at all,
>>>> so I do not owe anything to them, right?
>>>
>>> I don't think I'm really qualified to answer this one. But, there is
>>> drivers/mtd/nand/denali_dt.c , which handles this compatible string
>>> and it's documented in
>>> Documentation/devicetree/bindings/mtd/denali-nand.txt, so doesn't that
>>> make it part of the ABI ? I think we should
>>> at least keep it as a fallback, that should be pretty harmless.
>>>
>>
>> I would like to propose "altr,denali-nand" as the binding we use to support the
>> driver going forward on SoCFPGA hardware. It's pretty much the same as
>> "altera,denali-nand", just with the correct vendor prefix.
>
> Ah right, altr is the right prefix, thanks for pointing that out.
> Still, wouldn't altr,socfpga-denali-nand be better ? I know it's
> long, but it encodes the chip type , like ie. fsl,imx6q-usb .
>
Yes, that's fine.
Dinh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 2/2] i2c: aspeed: added documentation for Aspeed I2C driver
From: Rob Herring @ 2016-12-05 22:28 UTC (permalink / raw)
To: Brendan Higgins
Cc: wsa, vz, clg, mouse, mark.rutland, linux-i2c, devicetree, joel,
openbmc
In-Reply-To: <1480467618-7497-3-git-send-email-brendanhiggins@google.com>
On Tue, Nov 29, 2016 at 05:00:18PM -0800, Brendan Higgins wrote:
> Added device tree binding documentation for Aspeed I2C controller and
> busses.
>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Removed reference to "bus" device tree param
> Changes for v4:
> - None
> Changes for v5:
> - None
> ---
> .../devicetree/bindings/i2c/i2c-aspeed.txt | 61 ++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/i2c-aspeed.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 4/4] [media] dt-bindings: add TI VPIF documentation
From: Rob Herring @ 2016-12-05 22:27 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Laurent Pinchart, Sakari Ailus,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sekhar Nori,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161129235712.29846-5-khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Tue, Nov 29, 2016 at 03:57:12PM -0800, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/ti,da850-vpif.txt | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCHv2] mfd: cpcap: Add minimal support
From: Rob Herring @ 2016-12-05 22:25 UTC (permalink / raw)
To: Tony Lindgren
Cc: Lee Jones, Samuel Ortiz, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcel Partap, Mark Rutland,
Michael Scott
In-Reply-To: <20161129164702.5334-1-tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On Tue, Nov 29, 2016 at 08:47:02AM -0800, Tony Lindgren wrote:
> Many Motorola phones like droid 4 are using a custom PMIC called CPCAP
> or 6556002. We can support it's core features quite easily with regmap_spi
> and regmap_irq.
>
> The children of cpcap, such as regulators, ADC and USB, can be just regular
> device drivers and defined in the dts file. They get probed as we call
> of_platform_populate() at the end of our probe, and then the children
> can just call dev_get_regmap(dev.parent, NULL) to get the regmap.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Marcel Partap <mpartap-hi6Y0CQ0nG0@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Michael Scott <michael.scott-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Changes from v1:
>
> - Addressed comments from Lee Jones except did not start
> generalizing bulk adding of IRQ chips. That can be done
> later as needed.
>
> - Dropped the ranges translation based on comments from
> Lee Jones and Rob Herring. We are using regmap anyways.
>
> - Changed naming to use motorola-cpcap as this is Motorola
> custom PMIC manufactured by STE and TI.
>
> - Moved the revision and vendor check to motorola-cpcap.h.
> This keeps the undocumented register bits limited to
> these functions and the child device drivers can use
> them for the related workarounds.
>
> - Checked that motorola-cpcap.h is really aligned despite
> how the patch looks for some of the lines.
>
> ---
> .../devicetree/bindings/mfd/motorola-cpcap.txt | 31 +++
> drivers/mfd/Kconfig | 11 +
> drivers/mfd/Makefile | 1 +
> drivers/mfd/motorola-cpcap.c | 244 +++++++++++++++++
> include/linux/mfd/motorola-cpcap.h | 289 +++++++++++++++++++++
> 5 files changed, 576 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> create mode 100644 drivers/mfd/motorola-cpcap.c
> create mode 100644 include/linux/mfd/motorola-cpcap.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt
> @@ -0,0 +1,31 @@
> +Motorola CPCAP PMIC device tree binding
> +
> +Required properties:
> +- compatible : One or both of "motorola,cpcap" or "ste,6556002"
> +- reg : SPI chip select
> +- interrupt-parent : The parent interrupt controller
> +- interrupts : The interrupt line the device is connected to
> +- interrupt-controller : Marks the device node as an interrupt controller
> +- #interrupt-cells : The number of cells to describe an IRQ, should be 2
> +- #address-cells : Child device offset number of cells, typically 1
> +- #size-cells : Child device size number of cells, typically 1
> +- spi-max-frequency : Typically set to 3000000
> +- spi-cs_high : SPI chip select direction
Should be spi-cs-high.
With that:
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: clarify compatible property for rockchip timers
From: Rob Herring @ 2016-12-05 22:22 UTC (permalink / raw)
To: Alexander Kochetkov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Thomas Gleixner,
Heiko Stuebner, Mark Rutland, Russell King, Caesar Wang,
Huang Tao, Daniel Lezcano
In-Reply-To: <1480436092-10728-2-git-send-email-al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Nov 29, 2016 at 07:14:44PM +0300, Alexander Kochetkov wrote:
> Make all properties description in form '"rockchip,<chip>-timer",
> "rockchip,rk3288-timer"' for all chips found in linux kernel.
>
> Suggested-by: Heiko Stübner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
> Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> .../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 39/39] mtd: nand: denali_dt: add compatible strings for UniPhier SoC variants
From: Marek Vasut @ 2016-12-05 21:29 UTC (permalink / raw)
To: Dinh Nguyen
Cc: Mark Rutland, devicetree@vger.kernel.org, Boris Brezillon,
Alan Tull, Richard Weinberger, Dinh Nguyen,
Linux Kernel Mailing List, Chin Liang See, Masahiro Yamada,
linux-mtd@lists.infradead.org, Cyrille Pitchen, Brian Norris,
David Woodhouse, Rob Herring, Dinh Nguyen
In-Reply-To: <CADhT+wdpvpODDuHiX--je8+CiyuZnDrD1HETDC3tLEsrz4ZbRw@mail.gmail.com>
On 12/05/2016 09:51 PM, Dinh Nguyen wrote:
> On Sun, Dec 4, 2016 at 10:22 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> On 12/05/2016 05:10 AM, Masahiro Yamada wrote:
>>> Hi Marek,
>>>
>>>
>>> 2016-12-05 12:44 GMT+09:00 Marek Vasut <marek.vasut@gmail.com>:
>>>> On 12/05/2016 04:30 AM, Masahiro Yamada wrote:
>>>>> Hi Dinh,
>>>>>
>>>>>
>>>>> 2016-12-04 7:08 GMT+09:00 Dinh Nguyen <dinh.linux@gmail.com>:
>>>>>> Hi,
>>>>>>
>>>>>> On Fri, Dec 2, 2016 at 8:49 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>>>>>>> On 12/03/2016 03:41 AM, Masahiro Yamada wrote:
>>>>>>>> Hi Rob,
>>>>>>>
>>>>>>> Hi!
>>>>>>>
>>>>>>>> 2016-12-03 1:26 GMT+09:00 Rob Herring <robh@kernel.org>:
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> (Plan A)
>>>>>>>>>> "denali,socfpga-nand" (for Altera SOCFPGA variant)
>>>>>>>>>> "denali,uniphier-nand-v1" (for old Socionext UniPhier family variant)
>>>>>>>>>> "denali,uniphier-nand-v2" (for new Socionext UniPhier family variant)
>>>>>>>>>>
>>>>>>>>>> (Plan B)
>>>>>>>>>> "altera,denali-nand" (for Altera SOCFPGA variant)
>>>>>>>>>> "socionext,denali-nand-v5a" (for old Socionext UniPhier family variant)
>>>>>>>>>> "socionext,denali-nand-v5b" (for new Socionext UniPhier family variant)
>>>>>>>>
>>>>>>>>> Let the Altera folks worry about their stuff. At least for soft IP in
>>>>>>>>> FPGA, it's a bit of a special case. The old string can remain as bad
>>>>>>>>> as it is.
>>>>>>>>
>>>>>>>>
>>>>>>>> Hmm, I am not sure if this IP would fit in FPGA
>>>>>>>> (to use it along with NIOS-II?)
>>>>>>>>
>>>>>>>> (even if it happened, nothing of this IP would be customizable on users' side.
>>>>>>>> When buying the IP, SoC vendors submit a list of desired features.
>>>>>>>> Denali (now Cadence) generates the RTL according to the configuration sheet.
>>>>>>>> The function is fixed at this point. So, generic compatible would be
>>>>>>>> useless anyway.)
>>>>>>>>
>>>>>>>>
>>>>>>>> If we are talking about SOCFPGA,
>>>>>>>> SOCFPGA is not only FPGA. Rather "SOC" + "FPGA".
>>>>>>>> It consists of two parts:
>>>>>>>> [1] SOC part (Cortex-A9 + various hard-wired peripherals such UART,
>>>>>>>> USB, SD, NAND, ...)
>>>>>>>> [2] FPGA part (User design logic)
>>>>>>>>
>>>>>>>> The Denali NAND controller is included in [1].
>>>>>>>> So, as far as we talk about the Denali on SOCFPGA,
>>>>>>>> it is as hard-wired as Intel, Socionext's ones.
>>>>>>>
>>>>>>> That's correct, the Denali NAND IP in altera socfpga is a hardware
>>>>>>> block. You can make it available to the fabric too, but by default
>>>>>>> it's used by the ARM part of the chip, so for this discussion, you
>>>>>>> can forget that the FPGA part exists altogether.
>>>>>>>
>>>>>>> I would be in favor of plan B, since it seems to be the more often
>>>>>>> taken approach. A nice example is ci-hdrc:
>>>>>>>
>>>>>>> $ git grep compatible drivers/usb/chipidea/
>>>>>>>
>>>>>>>>> I simply would do "socionext,uniphier-v5b-nand" (and v5a).
>>>>>>>>> The fact that it is denali is part of the documentation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Let me think about this.
>>>>>>>>
>>>>>>>> Socionext bought two version of Denali IP,
>>>>>>>> and we are now re-using the newer one (v5b) for several SoCs.
>>>>>>>> Socionext has some more product lines other than Uniphier SoC family,
>>>>>>>> perhaps wider re-use might happen in the future.
>>>>>>>>
>>>>>>>> At first, I included "uniphier" in compatible, but I am still wondering
>>>>>>>> if such a specific string is good or not.
>>>>>>>>
>>>>>>>> Also, comments from Altera engineers are appreciated.
>>>>>>
>>>>>> Sorry, it's taken me a while to add comments. My altera email is very spotty now
>>>>>> that the Intel merge is completed. Please use dinguyen@kernel.org for any future
>>>>>> communications.
>>>>>>
>>>>>> Yes, everything that is said so far for the NAND controller on the
>>>>>> SoCFPGA is correct. I added the binding for the controller a while
>>>>>> back, but unfortunately, we never added the NAND interface to the
>>>>>> devkit, so we did not do much in terms of enabling it.
>>>>>>
>>>>>> I think the only SoCFPGA board I know that has the NAND interface active is
>>>>>> the TRCom board, but I have never seen that board.
>>>>>>
>>>>>> I don't have any strong opinions on this matter, just as long as the
>>>>>> original binding
>>>>>> "denali,denali-nand-dt" is kept, and I think Rob was ok with keeping
>>>>>> that binding.
>>>>>>
>>>>>
>>>>> I am proposing to add "altera,denali-nand" for Altera.
>>>>> For what, do you need the generic compatible?
>>>>> This IP has no default for it to fallback to.
>>>>
>>>> IMO just for compatibility reasons with old DTs .
>>>
>>> We generally contribute for
>>> a "working driver" (at least, should be functional to some extent)
>>> and "DT binding" bundled together.
>>>
>>> However, Altera upstreamed the DT binding first
>>> (then some parts of the DT binding turned out wrong),
>>> but they did not upstream needed driver changes in the end.
>>>
>>> So, the mainline driver has never worked on SOCFPGA, right?
>>
>> Most likely it never worked, yes.
>>
>
> Right, looking through our downstream support, we may need to upstream a
> few changes to make upstream driver work on SoCFPGA.
>
>>> Removing "denali,denali-nand-dt" is not breakage at all,
>>> so I do not owe anything to them, right?
>>
>> I don't think I'm really qualified to answer this one. But, there is
>> drivers/mtd/nand/denali_dt.c , which handles this compatible string
>> and it's documented in
>> Documentation/devicetree/bindings/mtd/denali-nand.txt, so doesn't that
>> make it part of the ABI ? I think we should
>> at least keep it as a fallback, that should be pretty harmless.
>>
>
> I would like to propose "altr,denali-nand" as the binding we use to support the
> driver going forward on SoCFPGA hardware. It's pretty much the same as
> "altera,denali-nand", just with the correct vendor prefix.
Ah right, altr is the right prefix, thanks for pointing that out.
Still, wouldn't altr,socfpga-denali-nand be better ? I know it's
long, but it encodes the chip type , like ie. fsl,imx6q-usb .
> If we can please keep, "denali,denali-nand-dt" only because SoCFPGA is using
> this binding downstream, but I know that is a weak argument.
--
Best regards,
Marek Vasut
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [RESEND/PATCH v6 3/3] clk: qcom: Add A53 clock driver
From: Bjorn Andersson @ 2016-12-05 21:26 UTC (permalink / raw)
To: Stephen Boyd
Cc: Georgi Djakov, mturquette, linux-clk, linux-kernel, linux-arm-msm,
devicetree, Rob Herring
In-Reply-To: <20161114203426.GN5177@codeaurora.org>
On Mon 14 Nov 14:21 PST 2016, Stephen Boyd wrote:
> On 11/11, Georgi Djakov wrote:
> > On 11/03/2016 08:28 PM, Bjorn Andersson wrote:
[..]
> > >I'm in favour of us inventing a kicker API and it's found outside out
> > >use cases as well (e.g. virtio/rpmsg).
> > >
>
> I'd rather we did this kicker API as well. That way we don't need
> to make a syscon and a simple-mfd to get software to work
> properly. Don't other silicon vendors need a kicker API as well?
> How are they kicking remote processors in other places? GPIOs?
>
In remoteproc I have two of these:
1) da8xx_remoteproc ioremaps a register and writes a bit in it (looks
similar to the downstream Qualcomm way)
2) omap_remoteproc acquires a mbox channel, in which it writes a
virtqueue id to kick the remote.
So one of the two cases could have used such mechanism.
We could write up a Qualcomm specific "kicker" and probe the mailing
list regarding the interest in making that generic (i.e. changing the
names in the API and DT binding).
The sucky part is that I believe we have most of our kickers in place
already so rpm, smd, smp2p, smsm etc would all need to support both
mechanisms.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
From: Laurent Pinchart @ 2016-12-05 21:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Archit Taneja, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
robh-DgEjT+Ai2ygdnm+yROfE0A,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown
In-Reply-To: <20161205211151.GA30492@tuxbot>
Hi Bjorn,
On Monday 05 Dec 2016 13:11:51 Bjorn Andersson wrote:
> On Tue 29 Nov 01:11 PST 2016, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote:
> >> On 11/29/2016 12:03 PM, Laurent Pinchart wrote:
> >>> On Tuesday 29 Nov 2016 11:37:41 Archit Taneja wrote:
> >>>> Add the regulator supply properties needed by ADV7511 and ADV7533.
> >>>>
> >>>> The regulators are specified as optional properties since there can
> >>>> be boards which have a fixed supply directly routed to the pins, and
> >>>> these may not be modelled as regulator supplies.
> >>>
> >>> That's why we have support for dummy supplies in the kernel, isn't it
> >>> ? Isn't it better to make the supplies mandatory in the bindings (and
> >>> obviously handling them as optional in the driver for
> >>> backward-compatibility) ?
> >>
> >> I'm a bit unclear on this.
> >>
> >> I thought we couldn't add mandatory properties once the device is
> >> already present in DT for one or more platforms.
> >
> > You can, as long as you treat them as optional in the driver to retain
> > backward compatibility. The DT bindings should document the properties
> > expected from a new platform (older versions of the bindings will always
> > be available in the git history).
>
> If you document them as required and don't do anything special in the
> implementation (i.e. just call devm_regulator_get() as usual) it will
> just work, in the absence of the property you will get a dummy regulator
> from the framework.
>
> And then add the fixed-voltage regulators to the new DT to make that
> properly describe the hardware.
>
> >> Say, if we do make it mandatory for future additions, we would need to
> >> have DT property for the supplies for the new platforms. If the
> >> regulators on these boards are fixed supplies, they would be need to be
> >> modeled using "regulator-fixed", possibly without any input supply. Is
> >> that what you're suggesting?
> >
> > That's the idea, yes. Clock maintainers have a similar opinion regarding
> > the clock bindings, where a clock that is not optional at the hardware
> > level should be specified in DT even if it's always present.
>
> Further more, a DT binding for a particular block should describe that
> block; so if we have three different 1.8V pins then the DT binding
> should reflect this - even if our current platform have them wired to
> the same regulator.
This has been discussed previously, and Rob agreed that if the datasheet
recommends to power all supplies from the same regulator we can take that as a
good hint that a single supply should be enough. In the very unlikely event
that a board would require control of more regulators we can always extend the
DT bindings later without breaking backward compatibility.
> (And the supply names would preferably be based on the pin names in the
> component data sheet)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox