* Re: [PATCH 4/8] dt-bindings: power: supply: axp20x: add AXP813 battery DT binding
From: Rob Herring @ 2017-12-06 21:16 UTC (permalink / raw)
To: Quentin Schulz
Cc: sre-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
jic23-DgEjT+Ai2ygdnm+yROfE0A, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA, icenowy-h8G6r0blFSE,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
In-Reply-To: <bf3682e87c75532884881d7b08840c61678cbce1.1512396054.git-series.quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Mon, Dec 04, 2017 at 03:12:50PM +0100, Quentin Schulz wrote:
> The AXP813 can have a battery as power supply, so let's add it to the
> list of compatibles.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/power/supply/axp20x_battery.txt | 8 +++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
^ permalink raw reply
* Re: [PATCH v4] usb: xhci: allow imod-interval to be configurable
From: Rob Herring @ 2017-12-06 21:21 UTC (permalink / raw)
To: Adam Wallis
Cc: Greg Kroah-Hartman, Mark Rutland, Matthias Brugger, Mathias Nyman,
Chunfeng Yun, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
timur-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1512397671-28733-1-git-send-email-awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Mon, Dec 04, 2017 at 09:27:51AM -0500, Adam Wallis wrote:
> The xHCI driver currently has the IMOD set to 160, which
> translates to an IMOD interval of 40,000ns (160 * 250)ns
>
> Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
> introduced a QUIRK for the MTK platform to adjust this interval to 20,
> which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
> due to the fact that the MTK controller IMOD interval is 8 times
> as much as defined in xHCI spec.
>
> Instead of adding more quirk bits for additional platforms, this patch
> introduces the ability for vendors to set the IMOD_INTERVAL as is
> optimal for their platform. By using device_property_read_u32() on
> "imod-interval-ns", the IMOD INTERVAL can be specified in nano seconds.
> If no interval is specified, the default of 40,000ns (IMOD=160) will be
> used.
>
> No bounds checking has been implemented due to the fact that a vendor
> may have violated the spec and would need to specify a value outside of
> the max 8,000 IRQs/second limit specified in the xHCI spec.
>
> Tested-by: Chunfeng Yun <chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> changes from v3:
> * Changed imod-interval to imod-interval-ns [Rob Herring/Chunfeng]
> * Changed "modulation" to "moderation" throughout patch [Mathias]
> changes from v2:
> * Added PCI default value [Mathias]
> * Removed xhci-mtk.h from xhci-plat.c [Chunfeng Yun]
> * Removed MTK quirk from xhci-plat and moved logic to xhci-mtk [Chunfeng]
> * Updated bindings Documentation to use proper units [Rob Herring]
> * Added imod-interval description and example to MTK binding documentation
> changes from v1:
> * Removed device_property_read_u32() per suggestion from greg k-h
> * Used ER_IRQ_INTERVAL_MASK in place of (u16) cast
>
> Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 2 ++
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
> drivers/usb/host/xhci-mtk.c | 9 +++++++++
> drivers/usb/host/xhci-pci.c | 3 +++
> drivers/usb/host/xhci-plat.c | 5 +++++
> drivers/usb/host/xhci.c | 7 ++-----
> drivers/usb/host/xhci.h | 2 ++
> 7 files changed, 24 insertions(+), 5 deletions(-)
Reviewed-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 1/5] PCI: Add vendor ID for Cadence
From: Bjorn Helgaas @ 2017-12-06 21:27 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, kishon-l0cyMroinI0,
lorenzo.pieralisi-5wv7dgnIgG8, linux-pci-u79uwXL29TY76Z2rM5mHXA,
adouglas-vna1KIf7WgpBDgjK7y7TUQ, stelford-vna1KIf7WgpBDgjK7y7TUQ,
dgary-vna1KIf7WgpBDgjK7y7TUQ, kgopi-vna1KIf7WgpBDgjK7y7TUQ,
eandrews-vna1KIf7WgpBDgjK7y7TUQ,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
sureshp-vna1KIf7WgpBDgjK7y7TUQ, nsekhar-l0cyMroinI0,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a93032cbbe02dc9efef8536a4b2a851d1b08ab6f.1511439189.git.cyrille.pitchen-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Thu, Nov 23, 2017 at 04:01:46PM +0100, Cyrille Pitchen wrote:
> This patch adds a new PCI vendor ID for Cadence.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
I assume Lorenzo will merge this along with the rest of the Cadence
support.
> ---
> include/linux/pci_ids.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index ab20dc5db423..eb13e84e1fef 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2381,6 +2381,8 @@
>
> #define PCI_VENDOR_ID_LENOVO 0x17aa
>
> +#define PCI_VENDOR_ID_CDNS 0x17cd
> +
> #define PCI_VENDOR_ID_ARECA 0x17d3
> #define PCI_DEVICE_ID_ARECA_1110 0x1110
> #define PCI_DEVICE_ID_ARECA_1120 0x1120
> --
> 2.11.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 v3 1/1] at24: support eeproms that do not auto-rollover reads.
From: Rob Herring @ 2017-12-06 21:29 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Sakari Ailus, Sven Van Asbroeck, Sven Van Asbroeck, Mark Rutland,
Wolfram Sang, nsekhar, David Lechner, javier, divagar.mohandass,
devicetree, linux-kernel, linux-i2c, Sven Van Asbroeck
In-Reply-To: <CAMRc=MdeEcJ=hH42725S3u3ncVeNdyk-VBs2TvV1D8_kTR3nOw@mail.gmail.com>
On Tue, Dec 05, 2017 at 09:14:22AM +0100, Bartosz Golaszewski wrote:
> 2017-12-05 8:44 GMT+01:00 Sakari Ailus <sakari.ailus@linux.intel.com>:
> > On Mon, Dec 04, 2017 at 05:24:33PM -0500, Sven Van Asbroeck wrote:
> >> > If this is truly specific to at24, then vendor prefix would be appropriate,
> >> > plus it'd go to an at24 specific binding file. However if it isn't I'd just
> >> > remove the above sentence. I guess the latter?
> >>
> >> Yes, no-read-rollover is truly specific to at24.c, because it applies only
> >> to i2c multi-address chips. The at25 is spi based so cannot have multiple
> >> addresses.
> >>
> >> So yes, "at24,no-read-rollover" would perhaps be a better name.
> >>
> >> Regarding an at24 specific binding file. You're saying I should create
> >> Documentation/devicetree/bindings/eeprom/at24.txt ? Should I indicate
> >> that at24.txt "inherits from" eeprom.txt? Note that at25.txt does not
> >> currently do this.
> >
> > Hmm. I actually missed we didn't have one to begin with. at25.txt exists
> > and it documents a number of properties specific to at25, so if at24 will
> > have an at24-specific property, then I think it should go to a separate
> > file.
>
> The eeprom.txt file in the bindings directory actually describes the
> bindings for at24. There's a patch[1] from Wolfram waiting for Rob's
> ack that renames it to at24.txt. I hope that clears any confusion.
It's going to wait forever until it is sent to the DT list so
patchwork picks it up and is in my queue.
> @Sven: please split the patch into two: one for bindings and one for code.
>
> As for the name: I would change it to at24,no-read-rollover and remove
at24 is not a vendor.
> the fragment saying it's only supported in at24 - as I said: this file
> only concerns at24 and will be renamed.
>
> >
> > Aren't there really other chips which need this? It'd be (a little bit)
> > easier to just remove the sentence. :-)
> >
> > --
> > Regards,
> >
> > Sakari Ailus
> > sakari.ailus@linux.intel.com
>
> Thanks,
> Bartosz
>
> [1] http://patchwork.ozlabs.org/patch/842500/
^ permalink raw reply
* Re: [RFC 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus
From: Rob Herring @ 2017-12-06 21:39 UTC (permalink / raw)
To: Archit Taneja
Cc: tomi.valkeinen, eric, philippe.cornu, laurent.pinchart,
thierry.reding, nickey.yang, dri-devel, p.zabel, devicetree,
linux-arm-msm, seanpaul, briannorris, maxime.ripard,
boris.brezillon, a.hajda
In-Reply-To: <20171205103356.9917-2-architt@codeaurora.org>
On Tue, Dec 05, 2017 at 04:03:55PM +0530, Archit Taneja wrote:
> Add a section that describes dt-bindings for peripherals that support
> MIPI DSI, but have a different bus as the primary control bus. Add an
> example for such peripherals.
>
> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> ---
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 75 ++++++++++++++++++++--
> 1 file changed, 68 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 973c27273772..77a7cec15f5b 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -16,7 +16,7 @@ The following assumes that only a single peripheral is connected to a DSI
> host. Experience shows that this is true for the large majority of setups.
>
> DSI host
> ---------
> +========
>
> In addition to the standard properties and those defined by the parent bus of
> a DSI host, the following properties apply to a node representing a DSI host.
> @@ -30,11 +30,15 @@ Required properties:
> different value here. See below.
>
> DSI peripheral
> ---------------
> +==============
>
> -Peripherals are represented as child nodes of the DSI host's node. Properties
> -described here apply to all DSI peripherals, but individual bindings may want
> -to define additional, device-specific properties.
> +Peripherals with DSI as control bus
> +------------------------------------
> +
> +Peripherals with the DSI bus as the primary control path are represented as
> +child nodes of the DSI host's node. Properties described here apply to all DSI
> +peripherals, but individual bindings may want to define additional,
> +device-specific properties.
Are there any panels with no control bus? I've never seen one, but it
should be possible if LVDS panels can power on without commands.
> Required properties:
> - reg: The virtual channel number of a DSI peripheral. Must be in the range
> @@ -49,9 +53,25 @@ case two alternative representations can be chosen:
> property is the number of the first virtual channel and the second cell is
> the number of consecutive virtual channels.
>
> -Example
> --------
> +Peripherals with a different control bus
> +----------------------------------------
> +
> +There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
> +primary control bus, but are also connected to a DSI bus (mostly for the data
> +path). Connections between such peripherals and a DSI host can be represented
> +using the graph bindings [1], [2].
> +
> +[1] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> +Examples
> +========
> +- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
> + with different virtual channel configurations.
> +- (4) is an example of a peripheral on a I2C control bus connected with to
> + a DSI host using of-graph bindings.
> +
> +1)
> dsi-host {
> ...
>
> @@ -67,6 +87,7 @@ Example
> ...
> };
>
> +2)
> dsi-host {
> ...
>
> @@ -82,6 +103,7 @@ Example
> ...
> };
>
> +3)
> dsi-host {
> ...
>
> @@ -96,3 +118,42 @@ Example
>
> ...
> };
> +
> +4)
> + i2c-host {
> + ...
> +
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ...
> +
> + port@0 {
Drop unit-address and #*-cells.
> + bridge_mipi_in: endpoint {
> + remote-endpoint = <&host_mipi_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi-host {
> + ...
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ...
> +
> + port@0 {
Drop unit-address and #*-cells.
> + host_mipi_out: endpoint {
> + remote-endpoint = <&bridge_mipi_in>;
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* Re: [RFC 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
From: Rob Herring @ 2017-12-06 21:42 UTC (permalink / raw)
To: Archit Taneja
Cc: tomi.valkeinen-l0cyMroinI0, eric-WhKQ6XTQaPysTnJN9+BGXg,
philippe.cornu-qxv4g6HH51o,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
nickey.yang-TNX95d0MmH7DzftRWevZcw,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
seanpaul-F7+t8E8rja9g9hUCZPvPmw,
briannorris-F7+t8E8rja9g9hUCZPvPmw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
a.hajda-Sze3O3UU22JBDgjK7y7TUQ
In-Reply-To: <20171205103356.9917-3-architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Dec 05, 2017 at 04:03:56PM +0530, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode.
>
> Signed-off-by: Archit Taneja <architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 77 ++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 77a7cec15f5b..f556aaafdf22 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,12 @@ Required properties:
> - #size-cells: Should be 0. There are cases where it makes sense to use a
> different value here. See below.
>
> +Optional properties:
> +- clock-master: A DSI host controller may be used in conjunction with another DSI
> + host to drive the same peripheral. Hardware supporting such a configuration
> + generally requires the data on both the busses to be driven by the same clock.
> + The DSI host instance controlling this clock should contain this property.
Be explicit this is a boolean.
> +
> DSI peripheral
> ==============
>
> @@ -61,6 +67,17 @@ primary control bus, but are also connected to a DSI bus (mostly for the data
> path). Connections between such peripherals and a DSI host can be represented
> using the graph bindings [1], [2].
>
> +Peripherals that support dual channel DSI
> +-----------------------------------------
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the display).
> +The graph bindings should be used to represent the multiple DSI busses that are
> +connected to this peripheral. Each DSI host's output endpoint can be linked to
> +an input endpoint of the DSI peripheral.
> +
> +
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -70,6 +87,8 @@ Examples
> with different virtual channel configurations.
> - (4) is an example of a peripheral on a I2C control bus connected with to
> a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> + which uses I2C as its primary control bus.
>
> 1)
> dsi-host {
> @@ -157,3 +176,61 @@ Examples
> };
> };
> };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + ...
> +
> + port@0 {
Need reg property and #{address,size}-cells.
> + dsi0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + dsi1_in: endpoint {
> + remote-endpoint = <&dsi1_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> + * this DSI instance drives the clock for both the host
> + * controllers
> + */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port@0 {
Drop unit-address.
> + dsi0_out: endpoint {
> + remote-endpoint = <&dsi0_in>;
> + };
> + };
> + };
> + };
> +
> + dsi1-host {
> + ...
> +
> + ports {
> + ...
> +
> + port@0 {
Drop unit-address.
> + dsi1_out: endpoint {
> + remote-endpoint = <&dsi1_in>;
> + };
> + };
> + };
> + };
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
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] [linux][master][v1] devicetree: misc: Add binding for logicoreIP xlnx,vcu
From: Rob Herring @ 2017-12-06 21:49 UTC (permalink / raw)
To: Dhaval Shah
Cc: mark.rutland, devicetree, linux-kernel, michal.simek, hyunk,
Dhaval Shah
In-Reply-To: <1512472023-3957-1-git-send-email-dshah@xilinx.com>
On Tue, Dec 05, 2017 at 03:07:03AM -0800, Dhaval Shah wrote:
> From: Dhaval Shah <dhaval.shah@xilinx.com>
>
> Added the txt file which contain the xlnx,vcu DT node
> properties information. This also provides the information
> of it's child node as well.
>
> Signed-off-by: Dhaval Shah <dshah@xilinx.com>
> ---
> .../devicetree/bindings/misc/xlnx,vcu.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/xlnx,vcu.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/xlnx,vcu.txt b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
> new file mode 100644
> index 0000000..e722ff3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/xlnx,vcu.txt
> @@ -0,0 +1,59 @@
> +Xilinx VCU init Driver
Bindings don't describe drivers. Describe the h/w.
> +-----------------------------
> +
> +General concept
> +---------------
> +
> +Xilinx VCU init driver is developed to handle the LogiCore related
> +new implementation. In this directory, The DT node of the Xilinx
> +VCU init driver represents as a top level node.
> +
> +Required properties:
> +- compatible: Must be "xlnx,vcu".
Needs to be more specific.
> +- reg, reg-names: There are two sets of registers need to provide.
> + 1. vcu slcr
> + 2. Logicore
> + reg-names should contain name for the each register sequence.
> +- clocks: phandle for aclk and pll_ref clocksource
> +- clock-names: The identification string, "aclk", is always required for
> + the axi clock. "pll_ref" is required for pll.
> +- ranges
> +- VCU Init driver node define the following child nodes:
> + * Allegro encoder driver node
encoder of what?
> + - compatible: Must be "al,al5e"
> + - reg: There is a one set of register.
> + - interrupts: interrupt number to the cpu.
> + - interrupt-parent: the phandle for the interrupt controller
> + that services interrupts for this device.
> + * Allegro decoder driver node
> + - compatible: Must be "al,al5d"
> + - reg: There is a one set of register.
> + - interrupts: interrupt number to the cpu.
> + - interrupt-parent: the phandle for the interrupt controller
> + that services interrupts for this device.
> +Example:
> +
> + xlnx_vcu: vcu@a0040000 {
> + compatible = "xlnx,vcu";
> + #address-cells = <2>;
> + #size-cells = <2>;
There's no reason the child nodes need 64 bits of address or size. Use
ranges.
> + reg = <0x0 0xa0040000 0x0 0x1000>,
> + <0x0 0xa0041000 0x0 0x1000>;
> + reg-names = "vcu_slcr", "logicore";
> + clocks = <&si570_1>, <&clkc 71>;
> + clock-names = "pll_ref", "aclk";
> + ranges;
> + encoder: al5e@a0000000 {
> + compatible = "al,al5e";
> + reg = <0x0 0xa0000000 0x0 0x10000>;
> + interrupts = <0 89 4>;
> + interrupt-parent = <&gic>;
> + };
> +
> + decoder: al5d@a0020000 {
> + compatible = "al,al5d";
> + reg = <0x0 0xa0020000 0x0 0x10000>;
> + interrupts = <0 89 4>;
A shared interrupt? Are these really separate blocks? Seems like this
could all be a single node.
> + interrupt-parent = <&gic>;
> + };
> + };
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] dt: bindings: as3645a: Fix the example node
From: Rob Herring @ 2017-12-06 21:52 UTC (permalink / raw)
To: Dan Murphy
Cc: mark.rutland, rpurdie, jacek.anaszewski, pavel, devicetree,
linux-kernel, linux-leds
In-Reply-To: <20171205133637.30022-1-dmurphy@ti.com>
On Tue, Dec 05, 2017 at 07:36:37AM -0600, Dan Murphy wrote:
> Fix the address-cells and size-cells example node
> to reflect to the correct representation.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> index fdc40e354a64..8a49ccfec29b 100644
> --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
> @@ -59,8 +59,8 @@ Example
> =======
>
> as3645a@30 {
> - #address-cells: 1
> - #size-cells: 0
> + #address-cells = <1>;
> + #size-cells = <0>;
> reg = <0x30>;
> compatible = "ams,as3645a";
Convention is also we put compatible first.
> flash@0 {
> --
> 2.15.0.124.g7668cbc60
>
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: rtc: add bindings for i.MX53 SRTC
From: Rob Herring @ 2017-12-06 21:54 UTC (permalink / raw)
To: linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w
Cc: Shawn Guo, Sascha Hauer, Alessandro Zummo, Alexandre Belloni,
Patrick Bruenn, Patrick Bruenn, Mark Rutland,
open list:REAL TIME CLOCK (RTC) SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, Fabio Estevam, Juergen Borleis, Noel Vellemans,
Russell King,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20171205140646.30367-2-linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
On Tue, Dec 05, 2017 at 03:06:42PM +0100, linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org wrote:
> From: Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>
>
> Document the binding for i.MX53 SRTC implemented by rtc-mxc_v2
>
> Signed-off-by: Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org><Paste>
>
> ---
>
> To: Alessandro Zummo <a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>
> To: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Cc: linux-rtc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:REAL TIME CLOCK (RTC) SUBSYSTEM)
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS)
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org (open list)
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Cc: Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Noel Vellemans <Noel.Vellemans-8UENEgx6w+makBO8gow8eQ@public.gmane.org>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> (maintainer:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
> Cc: Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> (maintainer:ARM PORT)
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE)
>
> Cc: Philippe Ombredanne <pombredanne-od1rfyK75/E@public.gmane.org>
> Cc: Lothar Waßmann <LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org>
> ---
> Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
> new file mode 100644
> index 000000000000..796e7f4995db
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-mxc_v2.txt
> @@ -0,0 +1,17 @@
> +* i.MX53 Real Time Clock controller
> +
> +Required properties:
> +- compatible: should be: "fsl,imx53-rtc"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- clocks: should contain the phandle for the rtc clock
Shouldn't there be more than 1 here. From what I remember, the ipg clock
and the 32k clock?
> +- interrupts: rtc alarm interrupt
> +
> +Example:
> +
> +srtc@53fa4000 {
rtc@...
> + compatible = "fsl,imx53-rtc";
> + reg = <0x53fa4000 0x4000>;
> + interrupts = <24>;
> + clocks = <&clks IMX5_CLK_SRTC_GATE>;
> +};
> --
> 2.11.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 v3 01/15] dt-bindings: panel: lvds: Document power-supply property
From: Rob Herring @ 2017-12-06 21:56 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
plaes-q/aMd4JkU83YtjvyW6yDsg, icenowy-h8G6r0blFSE,
Thomas Petazzoni, jernej.skrabec-gGgVlfcn5nU,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <97ebf0615821d79e8d7718594fe3a542a743a05f.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 05, 2017 at 04:10:13PM +0100, Maxime Ripard wrote:
> The power-supply property is used by a vast majority of panels, including
> panel-simple. Let's document it as a common property
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/panel/panel-common.txt | 6 ++++++
> Documentation/devicetree/bindings/display/panel/panel-lvds.txt | 1 +
> Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
> 3 files changed, 8 insertions(+), 1 deletion(-)
Reviewed-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 v3 03/15] dt-bindings: display: sun4i-drm: Add LVDS properties
From: Rob Herring @ 2017-12-06 21:57 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
plaes-q/aMd4JkU83YtjvyW6yDsg, icenowy-h8G6r0blFSE,
Thomas Petazzoni, jernej.skrabec-gGgVlfcn5nU,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <17851ba6277b69aa9cd81de5eead62bfed271661.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 05, 2017 at 04:10:15PM +0100, Maxime Ripard wrote:
> Some clocks and resets supposed to drive the LVDS logic in the display
> engine have been overlooked when the driver was first introduced.
>
> Add those additional resources to the binding, and we'll deal with the ABI
> stability in the code.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 8 +++++++-
> 1 file changed, 8 insertions(+)
Reviewed-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 v3 04/15] dt-bindings: display: sun4i-drm: Add A83T pipeline
From: Rob Herring @ 2017-12-06 21:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
plaes-q/aMd4JkU83YtjvyW6yDsg, icenowy-h8G6r0blFSE,
Thomas Petazzoni, jernej.skrabec-gGgVlfcn5nU,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3762a8428aaf207e80ae86d4db2e50473576bb6d.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 05, 2017 at 04:10:16PM +0100, Maxime Ripard wrote:
> The A83T has two video pipelines in parallel that looks quite similar to
> the other SoCs.
>
> The video planes are handled through a controller called the mixer, and the
> video signal is then passed to the timing controller (TCON).
>
> And while there is two instances of the mixers and TCONs, they have a
> significant number of differences. The TCONs are quite easy to deal with,
> one is supposed to generate TV (in the broader term, so including things
> like HDMI) signals, the other one LCD (so RGB, LVDS, DSI) signals. And
> while they are called TCON0 and TCON1 in the A83t datasheet, newer SoCs
> call them TCON-TV and TCON-LCD, which seems more appropriate.
>
> However, the mixers differ mostly by their capabilities, with some features
> being available only in the first one, or the number of planes they expose,
> but also through their register layout. And while the capabilities could be
> represented as properties, the register layout differences would need to
> express all the registers offsets as properties, which is usually quite
> bad. Especially since documentation on that hardware block is close to
> non-existant and we don't even have the list of all those registers in the
> first place.
>
> So let's call them mixer 0 and 1 in our compatibles, even though the name
> is pretty bad...
>
> At the moment, we only have tested the code on a board that has a single
> display output, so we're leaving the tcon-tv and mixer1 out.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-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 2/2] dt-bindings: add eeprom "at24,no-read-rollover" property
From: Rob Herring @ 2017-12-06 22:04 UTC (permalink / raw)
To: Sven Van Asbroeck
Cc: mark.rutland, wsa, brgl, nsekhar, sakari.ailus, david, javier,
divagar.mohandass, devicetree, linux-kernel, linux-i2c
In-Reply-To: <1512487422-6284-3-git-send-email-svendev@arcx.com>
On Tue, Dec 05, 2017 at 10:23:42AM -0500, Sven Van Asbroeck wrote:
> Adds an optional property for at24 eeproms.
> This parameterless property indicates that the multi-address eeprom
> does not automatically roll over reads to the next slave address.
>
> Signed-off-by: Sven Van Asbroeck <svendev@arcx.com>
> ---
> Documentation/devicetree/bindings/eeprom/eeprom.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> index 27f2bc1..5bfc0ac 100644
> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
> @@ -38,6 +38,11 @@ Optional properties:
>
> - size: total eeprom size in bytes
>
> + - at24,no-read-rollover:
at24 is not a vendor prefix. Either this is atmel specific and you want
atmel,no-read-rollover or it is for all vendors at24 compatible eeproms
and you want at24-no-read-rollover. Or just drop the at24 if this
binding is in fact for just at24 eeproms as none of the other properties
has at24 in them.
> + This parameterless property indicates that the multi-address
> + eeprom does not automatically roll over reads to the next
> + slave address. Please consult the manual of your device.
> +
> Example:
>
> eeprom@52 {
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3 0/2] of: overlay: Fix of_overlay_apply() error path
From: Rob Herring @ 2017-12-06 22:07 UTC (permalink / raw)
To: Frank Rowand
Cc: Geert Uytterhoeven, Pantelis Antoniou, Colin King, Dan Carpenter,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <48dd6ac2-6481-4164-6051-ec9fd98490fb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Dec 05, 2017 at 09:40:33PM -0500, Frank Rowand wrote:
> On 12/05/17 10:27, Geert Uytterhoeven wrote:
> > Hi Pantelis, Rob, Frank,
> >
> > Here's a replacement for commit bd80e2555c5c9d45 ("of: overlay: Fix
> > cleanup order in of_overlay_apply()"), which was applied by Rob, and
> > dropped later.
> >
> > The first patch fixes the memory leak reported by Colin.
> > The second patch is a replacement for the bad dropped commit, and
> > depends on the first patch for proper cleanup.
> >
> > All OF unittests pass.
> >
> > Thanks!
> >
> > Geert Uytterhoeven (2):
> > of: overlay: Fix memory leak in of_overlay_apply() error path
> > of: overlay: Fix (un)locking in of_overlay_apply()
> >
> > drivers/of/overlay.c | 31 +++++++++++++------------------
> > 1 file changed, 13 insertions(+), 18 deletions(-)
> >
>
> Thank you, the code is much improved by these patches.
>
> Reviewed-by: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
Applied.
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] dt: bindings: as3645a: Fix the example node
From: Dan Murphy @ 2017-12-06 22:32 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland-5wv7dgnIgG8, rpurdie-Fm38FmjxZ/leoWH0uzbU5w,
jacek.anaszewski-Re5JQEeQqe8AvxtiuMwx3w, pavel-+ZI9xUNit7I,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171206215204.7qyjjd2oue7n7l37@rob-hp-laptop>
Rob
On 12/06/2017 03:52 PM, Rob Herring wrote:
> On Tue, Dec 05, 2017 at 07:36:37AM -0600, Dan Murphy wrote:
>> Fix the address-cells and size-cells example node
>> to reflect to the correct representation.
>>
>> Signed-off-by: Dan Murphy <dmurphy-l0cyMroinI0@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/leds/ams,as3645a.txt | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/ams,as3645a.txt b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
>> index fdc40e354a64..8a49ccfec29b 100644
>> --- a/Documentation/devicetree/bindings/leds/ams,as3645a.txt
>> +++ b/Documentation/devicetree/bindings/leds/ams,as3645a.txt
>> @@ -59,8 +59,8 @@ Example
>> =======
>>
>> as3645a@30 {
>> - #address-cells: 1
>> - #size-cells: 0
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> reg = <0x30>;
>> compatible = "ams,as3645a";
>
> Convention is also we put compatible first.
>
OK I will move that too for v2.
Can that be in the same patch or do you want a separate patch?
Dan
>> flash@0 {
>> --
>> 2.15.0.124.g7668cbc60
>>
--
------------------
Dan Murphy
--
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
* [PATCH] of: irq: Fix function description comment
From: Vasyl Gomonovych @ 2017-12-06 22:43 UTC (permalink / raw)
To: devicetree, robh+dt, frowand.list, gomonovych; +Cc: linux-kernel
Make small cleanup in function description for
of_irq_parse_raw
Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
---
drivers/of/irq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index ec00ae7..7dcea86 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -83,9 +83,8 @@ struct device_node *of_irq_find_parent(struct device_node *child)
/**
* of_irq_parse_raw - Low level interrupt tree parsing
- * @parent: the device interrupt parent
* @addr: address specifier (start of "reg" property of the device) in be32 format
- * @out_irq: structure of_irq updated by this function
+ * @out_irq: structure of_phandle_args updated by this function
*
* Returns 0 on success and a negative number on error
*
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v6 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Christoph Hellwig @ 2017-12-06 23:11 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Mark Rutland, devicetree, Liam Girdwood, Shawn Guo,
Michael Turquette, Stephen Boyd, Russell King, linux-kernel,
Rob Herring, Mark Brown, kernel, Fabio Estevam, Andrew Morton,
Leonard Crestez, Linus Torvalds, linux-clk, linux-arm-kernel
In-Reply-To: <20171206072402.11694-4-o.rempel@pengutronix.de>
> void (*pm_power_off_prepare)(void);
> +EXPORT_SYMBOL(pm_power_off_prepare);
EXPORT_SYMBOL_GPL for something this deeply internal, please.
^ permalink raw reply
* Re: [PATCH 3/3] ARM64: dts: meson-axg: add the SPICC controller
From: Kevin Hilman @ 2017-12-06 23:57 UTC (permalink / raw)
To: Yixun Lan
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
linux-spi-u79uwXL29TY76Z2rM5mHXA, Neil Armstrong, Jerome Brunet,
Rob Herring, Mark Rutland, Carlo Caione, Sunny Luo,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128132926.19051-4-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org> writes:
> From: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> Add DT info for the SPICC controller which found in
> the Amlogic's Meson-AXG SoC.
>
> Signed-off-by: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
This patch looks OK but it doesn't apply cleanly.
A quick glance suggests that it's becuase it has a dependency on the PWM
series, but that dependency was not described here (or in the cover
letter.)
If the series does not apply directly on mainline, the cover letter
should describe the dependencies clearly.
In your case, I understand it's difficult because you have many series
in parallel at the same time. I would suggest that locally, you keep
each series as independent branches based on the latest -rc tag. It's
pretty easy for me to resolve simple add-add conflicts when there are
two different series adding to the DT, but it can be more time consuming
when I have to figure out the dependencies myself, so I generally don't
do that and just reject the patches instead so the submitter can work
out (and document) the dependencies.
Also some questions...
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 92 ++++++++++++++++++++++++++++++
> 1 file changed, 92 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index fe3878f7718c..021b929d8d6e 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -208,6 +208,28 @@
> interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_RISING>;
> status = "disabled";
> };
> +
> + spicc_a: spi@13000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x13000 0x0 0x3c>;
> + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC0>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + spicc_b: spi@15000 {
> + compatible = "amlogic,meson-axg-spicc";
> + reg = <0x0 0x15000 0x0 0x3c>;
> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc CLKID_SPICC1>;
> + clock-names = "core";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
Here you use the labels spicc_a and spicc_b, but the datasheet
uses 0 and 1. Why the difference?
Hmm, but after looking at the pin definitions those are using A and B.
Confusing.
Can you clarify which is the right one, and also work with the datasheet
team on consistency? Thanks!
Kevin
> };
>
> gic: interrupt-controller@ffc01000 {
> @@ -470,6 +492,76 @@
> function = "pwm_d";
> };
> };
> +
> + spi_a_pins: spi_a {
> + mux {
> + groups = "spi_miso_a",
> + "spi_mosi_a",
> + "spi_clk_a";
> + function = "spi_a";
> + };
> + };
> +
> + spi_ss0_a_pins: spi_ss0_a {
> + mux {
> + groups = "spi_ss0_a";
> + function = "spi_a";
> + };
> + };
> +
> + spi_ss1_a_pins: spi_ss1_a {
> + mux {
> + groups = "spi_ss1_a";
> + function = "spi_a";
> + };
> + };
> +
> + spi_ss2_a_pins: spi_ss2_a {
> + mux {
> + groups = "spi_ss2_a";
> + function = "spi_a";
> + };
> + };
> +
> +
> + spi_b_a_pins: spi_b_a {
> + mux {
> + groups = "spi_miso_b_a",
> + "spi_mosi_b_a",
> + "spi_clk_b_a";
> + function = "spi_b";
> + };
> + };
> +
> + spi_ss0_b_a_pins: spi_ss0_b_a {
> + mux {
> + groups = "spi_ss0_b_a";
> + function = "spi_b";
> + };
> + };
> +
> + spi_ss1_b_pins: spi_ss1_b {
> + mux {
> + groups = "spi_ss1_b";
> + function = "spi_b";
> + };
> + };
> +
> + spi_b_x_pins: spi_b_x {
> + mux {
> + groups = "spi_miso_b_x",
> + "spi_mosi_b_x",
> + "spi_clk_b_x";
> + function = "spi_b";
> + };
> + };
> +
> + spi_ss0_b_x_pins: spi_ss0_b_x {
> + mux {
> + groups = "spi_ss0_b_x";
> + function = "spi_b";
> + };
> + };
> };
> };
--
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 3/3] ARM64: dts: meson-axg: add the SPICC controller
From: Kevin Hilman @ 2017-12-07 0:04 UTC (permalink / raw)
To: Yixun Lan
Cc: devicetree, Mark Brown, open list:SPI SUBSYSTEM, Neil Armstrong,
Jerome Brunet, Rob Herring, Mark Rutland, Carlo Caione, Sunny Luo,
linux-amlogic, linux-arm-kernel, lkml
In-Reply-To: <7hy3mfmmtd.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On Wed, Dec 6, 2017 at 3:57 PM, Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
> Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org> writes:
>
>> From: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>>
>> Add DT info for the SPICC controller which found in
>> the Amlogic's Meson-AXG SoC.
>>
>> Signed-off-by: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> This patch looks OK but it doesn't apply cleanly.
>
> A quick glance suggests that it's becuase it has a dependency on the PWM
> series, but that dependency was not described here (or in the cover
> letter.)
>
> If the series does not apply directly on mainline, the cover letter
> should describe the dependencies clearly.
>
> In your case, I understand it's difficult because you have many series
> in parallel at the same time. I would suggest that locally, you keep
> each series as independent branches based on the latest -rc tag.
Correction: while in general it's best to keep things based on the
latest -rc tag, for DT patches, it's even better if you base things on
my current <version>/dt64 branch (currently v4.16/dt64)
Kevin
--
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 v4 4/4] arm64: dts: meson-axg: add clock DT info for Meson AXG SoC
From: Kevin Hilman @ 2017-12-07 0:50 UTC (permalink / raw)
To: Yixun Lan
Cc: Neil Armstrong, Jerome Brunet, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd, Carlo Caione, Qiufang Dai,
linux-amlogic, devicetree, linux-clk, linux-arm-kernel,
linux-kernel
In-Reply-To: <20171201012452.27086-5-yixun.lan@amlogic.com>
Yixun Lan <yixun.lan@amlogic.com> writes:
> From: Qiufang Dai <qiufang.dai@amlogic.com>
>
> Try to add Hiubus DT info, and also enable clock DT info
> for the Amlogic's Meson-AXG SoC.
>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Qiufang Dai <qiufang.dai@amlogic.com>
> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> index b932a784b02a..36a2e98338a8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> @@ -7,6 +7,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/axg-clkc.h>
This #include will cause an unnessary dependency from the amlogic tree
to the clock tree even though this patch is not currently using any of
the #defines from that header. It will simplify the dependencies if you
drop this #include from this patch.
In my comment on the cover letter, I suggested adding a patch that also
switches the UART over to the new clock provider. That is the patch
that should add this #include, since it will actually need #defines from
the header.
Doing it in that order means that we could merge this patch
independently of the clock driver, and then merge the UART switch-over
patch only after the driver (and headers) are merged.
Kevin
^ permalink raw reply
* Re: [PATCH v2 0/2] add Meson8/Meson8b serial core clock handling
From: Kevin Hilman @ 2017-12-07 1:05 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
carlo-KA+7E9HrN00dnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
narmstrong-rdvid1DuHRBWk0Htik3J/w,
hgkr.klein-Re5JQEeQqe8AvxtiuMwx3w, jbrunet-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <20171117225857.9571-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> writes:
> This patchset adds the tty/serial core clock handling to the UARTs
> on Meson8 and Meson8b.
>
> Basically this is the Meson8 and Meson8b version of a patchset from
> Helmut Klein and Neil Armstrong, who implemented this for Meson GX
> (see [0]). Back then I asked Neil to drop Meson8b from his patchset
> because I was working on the Meson8 clock controller at that time.
>
> This also removes the last users that rely on the "amlogic,meson-uart"
> binding. Removing that binding from the meson_uart driver is not part
> of this series though.
I mistakenly replied to the v1 of this series. It's this version (v2)
that I applied to v4.16/dt.
Sorry for the confusion, and thanks for the patches!
Kevin
--
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 PATCH v3 2/2] ARM64: dts: meson-axg: add pinctrl DT info for Meson-AXG SoC
From: Yixun Lan @ 2017-12-07 1:44 UTC (permalink / raw)
To: Kevin Hilman
Cc: yixun.lan, Rob Herring, Mark Rutland, Linus Walleij,
Neil Armstrong, Jerome Brunet, Carlo Caione, Xingyu Chen,
devicetree, linux-gpio, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <7htvx3r4o7.fsf@baylibre.com>
Hi Kevin
On 12/07/17 04:18, Kevin Hilman wrote:
> Yixun Lan <yixun.lan@amlogic.com> writes:
>
>> From: Xingyu Chen <xingyu.chen@amlogic.com>
>>
>> Add new pinctrl DT info for the Amlogic's Meson-AXG SoC.
>>
>> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
>> Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
>> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 44 ++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> index 5fc33b76b91c..e0fb860e12c5 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
>> @@ -9,6 +9,7 @@
>> #include <dt-bindings/interrupt-controller/arm-gic.h>
>> #include <dt-bindings/clock/axg-clkc.h>
>> #include <dt-bindings/clock/axg-aoclkc.h>
>
> This doesn't apply because this aoclkc.h header does not exist in
> mainline.
>
> Kevin
>
this is due to I create the patch in serial sequence (first clk, then
pinctrl), I probably will fix my work flow next time - to rebase all the
patch separately on the -rc version
but here, the pinctrl DT part has no dependency on DT clk patch..
you could drop the above two #include and just apply the reset
could you amend & apply this? or do you want me to send another updated
version?
>> +#include <dt-bindings/gpio/meson-axg-gpio.h>
>>
>> / {
>> compatible = "amlogic,meson-axg";
>> @@ -173,6 +174,32 @@
>> #mbox-cells = <1>;
>> };
>>
>> + periphs: periphs@ff634000 {
>> + compatible = "simple-bus";
>> + reg = <0x0 0xff634000 0x0 0x2000>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges = <0x0 0x0 0x0 0xff634000 0x0 0x2000>;
>> +
>> + pinctrl_periphs: pinctrl@480 {
>> + compatible = "amlogic,meson-axg-periphs-pinctrl";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + gpio: bank@480 {
>> + reg = <0x0 0x00480 0x0 0x40>,
>> + <0x0 0x004e8 0x0 0x14>,
>> + <0x0 0x00520 0x0 0x14>,
>> + <0x0 0x00430 0x0 0x3c>;
>> + reg-names = "mux", "pull", "pull-enable", "gpio";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + gpio-ranges = <&pinctrl_periphs 0 0 86>;
>> + };
>> + };
>> + };
>> +
>> sram: sram@fffc0000 {
>> compatible = "amlogic,meson-axg-sram", "mmio-sram";
>> reg = <0x0 0xfffc0000 0x0 0x20000>;
>> @@ -209,6 +236,23 @@
>> };
>> };
>>
>> + pinctrl_aobus: pinctrl@14 {
>> + compatible = "amlogic,meson-axg-aobus-pinctrl";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + gpio_ao: bank@14 {
>> + reg = <0x0 0x00014 0x0 0x8>,
>> + <0x0 0x0002c 0x0 0x4>,
>> + <0x0 0x00024 0x0 0x8>;
>> + reg-names = "mux", "pull", "gpio";
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + gpio-ranges = <&pinctrl_aobus 0 0 15>;
>> + };
>> + };
>> +
>> uart_AO: serial@3000 {
>> compatible = "amlogic,meson-gx-uart", "amlogic,meson-ao-uart";
>> reg = <0x0 0x3000 0x0 0x18>;
>
> .
>
^ permalink raw reply
* Re: [PATCH 1/3] extcon: usbc-cros-ec: add support to notify USB type cables.
From: Chanwoo Choi @ 2017-12-07 2:12 UTC (permalink / raw)
To: Enric Balletbo i Serra, MyungJoo Ham, Lee Jones, Rob Herring,
Heiko Stuebner
Cc: groeck-F7+t8E8rja9g9hUCZPvPmw, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Benson Leung
In-Reply-To: <20171206111008.3079-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Hi Enric,
On 2017년 12월 06일 20:10, Enric Balletbo i Serra wrote:
> From: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>
> Extend the driver to notify host and device type cables and the presence
> of power.
>
> Signed-off-by: Benson Leung <bleung-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> drivers/extcon/extcon-usbc-cros-ec.c | 142 ++++++++++++++++++++++++++++++++++-
> include/linux/mfd/cros_ec_commands.h | 17 +++++
> 2 files changed, 155 insertions(+), 4 deletions(-)
Looks good to me.
After you uses the BIT() macro as the Lee's comment on v2,
I'll merge this patch.
Reviewed-by: Chanwoo Choi <cw00.choi-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> diff --git a/drivers/extcon/extcon-usbc-cros-ec.c b/drivers/extcon/extcon-usbc-cros-ec.c
> index 6187f73..6721ab0 100644
> --- a/drivers/extcon/extcon-usbc-cros-ec.c
> +++ b/drivers/extcon/extcon-usbc-cros-ec.c
> @@ -34,16 +34,26 @@ struct cros_ec_extcon_info {
>
> struct notifier_block notifier;
>
> + unsigned int dr; /* data role */
> + bool pr; /* power role (true if VBUS enabled) */
> bool dp; /* DisplayPort enabled */
> bool mux; /* SuperSpeed (usb3) enabled */
> unsigned int power_type;
> };
>
> static const unsigned int usb_type_c_cable[] = {
> + EXTCON_USB,
> + EXTCON_USB_HOST,
> EXTCON_DISP_DP,
> EXTCON_NONE,
> };
>
> +enum usb_data_roles {
> + DR_NONE,
> + DR_HOST,
> + DR_DEVICE,
> +};
> +
> /**
> * cros_ec_pd_command() - Send a command to the EC.
> * @info: pointer to struct cros_ec_extcon_info
> @@ -150,6 +160,7 @@ static int cros_ec_usb_get_role(struct cros_ec_extcon_info *info,
> pd_control.port = info->port_id;
> pd_control.role = USB_PD_CTRL_ROLE_NO_CHANGE;
> pd_control.mux = USB_PD_CTRL_MUX_NO_CHANGE;
> + pd_control.swap = USB_PD_CTRL_SWAP_NONE;
> ret = cros_ec_pd_command(info, EC_CMD_USB_PD_CONTROL, 1,
> &pd_control, sizeof(pd_control),
> &resp, sizeof(resp));
> @@ -183,11 +194,72 @@ static int cros_ec_pd_get_num_ports(struct cros_ec_extcon_info *info)
> return resp.num_ports;
> }
>
> +static const char *cros_ec_usb_role_string(unsigned int role)
> +{
> + return role == DR_NONE ? "DISCONNECTED" :
> + (role == DR_HOST ? "DFP" : "UFP");
> +}
> +
> +static const char *cros_ec_usb_power_type_string(unsigned int type)
> +{
> + switch (type) {
> + case USB_CHG_TYPE_NONE:
> + return "USB_CHG_TYPE_NONE";
> + case USB_CHG_TYPE_PD:
> + return "USB_CHG_TYPE_PD";
> + case USB_CHG_TYPE_PROPRIETARY:
> + return "USB_CHG_TYPE_PROPRIETARY";
> + case USB_CHG_TYPE_C:
> + return "USB_CHG_TYPE_C";
> + case USB_CHG_TYPE_BC12_DCP:
> + return "USB_CHG_TYPE_BC12_DCP";
> + case USB_CHG_TYPE_BC12_CDP:
> + return "USB_CHG_TYPE_BC12_CDP";
> + case USB_CHG_TYPE_BC12_SDP:
> + return "USB_CHG_TYPE_BC12_SDP";
> + case USB_CHG_TYPE_OTHER:
> + return "USB_CHG_TYPE_OTHER";
> + case USB_CHG_TYPE_VBUS:
> + return "USB_CHG_TYPE_VBUS";
> + case USB_CHG_TYPE_UNKNOWN:
> + return "USB_CHG_TYPE_UNKNOWN";
> + default:
> + return "USB_CHG_TYPE_UNKNOWN";
> + }
> +}
> +
> +static bool cros_ec_usb_power_type_is_wall_wart(unsigned int type,
> + unsigned int role)
> +{
> + switch (type) {
> + /* FIXME : Guppy, Donnettes, and other chargers will be miscategorized
> + * because they identify with USB_CHG_TYPE_C, but we can't return true
> + * here from that code because that breaks Suzy-Q and other kinds of
> + * USB Type-C cables and peripherals.
> + */
> + case USB_CHG_TYPE_PROPRIETARY:
> + case USB_CHG_TYPE_BC12_DCP:
> + return true;
> + case USB_CHG_TYPE_PD:
> + case USB_CHG_TYPE_C:
> + case USB_CHG_TYPE_BC12_CDP:
> + case USB_CHG_TYPE_BC12_SDP:
> + case USB_CHG_TYPE_OTHER:
> + case USB_CHG_TYPE_VBUS:
> + case USB_CHG_TYPE_UNKNOWN:
> + case USB_CHG_TYPE_NONE:
> + default:
> + return false;
> + }
> +}
> +
> static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> bool force)
> {
> struct device *dev = info->dev;
> int role, power_type;
> + unsigned int dr = DR_NONE;
> + bool pr = false;
> bool polarity = false;
> bool dp = false;
> bool mux = false;
> @@ -206,9 +278,12 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> dev_err(dev, "failed getting role err = %d\n", role);
> return role;
> }
> + dev_dbg(dev, "disconnected\n");
> } else {
> int pd_mux_state;
>
> + dr = (role & PD_CTRL_RESP_ROLE_DATA) ? DR_HOST : DR_DEVICE;
> + pr = (role & PD_CTRL_RESP_ROLE_POWER);
> pd_mux_state = cros_ec_usb_get_pd_mux_state(info);
> if (pd_mux_state < 0)
> pd_mux_state = USB_PD_MUX_USB_ENABLED;
> @@ -216,20 +291,62 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> dp = pd_mux_state & USB_PD_MUX_DP_ENABLED;
> mux = pd_mux_state & USB_PD_MUX_USB_ENABLED;
> hpd = pd_mux_state & USB_PD_MUX_HPD_IRQ;
> - }
>
> - if (force || info->dp != dp || info->mux != mux ||
> - info->power_type != power_type) {
> + dev_dbg(dev,
> + "connected role 0x%x pwr type %d dr %d pr %d pol %d mux %d dp %d hpd %d\n",
> + role, power_type, dr, pr, polarity, mux, dp, hpd);
> + }
>
> + /*
> + * When there is no USB host (e.g. USB PD charger),
> + * we are not really a UFP for the AP.
> + */
> + if (dr == DR_DEVICE &&
> + cros_ec_usb_power_type_is_wall_wart(power_type, role))
> + dr = DR_NONE;
> +
> + if (force || info->dr != dr || info->pr != pr || info->dp != dp ||
> + info->mux != mux || info->power_type != power_type) {
> + bool host_connected = false, device_connected = false;
> +
> + dev_dbg(dev, "Type/Role switch! type = %s role = %s\n",
> + cros_ec_usb_power_type_string(power_type),
> + cros_ec_usb_role_string(dr));
> + info->dr = dr;
> + info->pr = pr;
> info->dp = dp;
> info->mux = mux;
> info->power_type = power_type;
>
> - extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
> + if (dr == DR_DEVICE)
> + device_connected = true;
> + else if (dr == DR_HOST)
> + host_connected = true;
>
> + extcon_set_state(info->edev, EXTCON_USB, device_connected);
> + extcon_set_state(info->edev, EXTCON_USB_HOST, host_connected);
> + extcon_set_state(info->edev, EXTCON_DISP_DP, dp);
> + extcon_set_property(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_VBUS,
> + (union extcon_property_value)(int)pr);
> + extcon_set_property(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_VBUS,
> + (union extcon_property_value)(int)pr);
> + extcon_set_property(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_TYPEC_POLARITY,
> + (union extcon_property_value)(int)polarity);
> + extcon_set_property(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_TYPEC_POLARITY,
> + (union extcon_property_value)(int)polarity);
> extcon_set_property(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_TYPEC_POLARITY,
> (union extcon_property_value)(int)polarity);
> + extcon_set_property(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_SS,
> + (union extcon_property_value)(int)mux);
> + extcon_set_property(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_SS,
> + (union extcon_property_value)(int)mux);
> extcon_set_property(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_SS,
> (union extcon_property_value)(int)mux);
> @@ -237,6 +354,8 @@ static int extcon_cros_ec_detect_cable(struct cros_ec_extcon_info *info,
> EXTCON_PROP_DISP_HPD,
> (union extcon_property_value)(int)hpd);
>
> + extcon_sync(info->edev, EXTCON_USB);
> + extcon_sync(info->edev, EXTCON_USB_HOST);
> extcon_sync(info->edev, EXTCON_DISP_DP);
>
> } else if (hpd) {
> @@ -322,13 +441,28 @@ static int extcon_cros_ec_probe(struct platform_device *pdev)
> return ret;
> }
>
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_VBUS);
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_TYPEC_POLARITY);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_TYPEC_POLARITY);
> extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_TYPEC_POLARITY);
> + extcon_set_property_capability(info->edev, EXTCON_USB,
> + EXTCON_PROP_USB_SS);
> + extcon_set_property_capability(info->edev, EXTCON_USB_HOST,
> + EXTCON_PROP_USB_SS);
> extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_USB_SS);
> extcon_set_property_capability(info->edev, EXTCON_DISP_DP,
> EXTCON_PROP_DISP_HPD);
>
> + info->dr = DR_NONE;
> + info->pr = false;
> +
> platform_set_drvdata(pdev, info);
>
> /* Get PD events from the EC */
> diff --git a/include/linux/mfd/cros_ec_commands.h b/include/linux/mfd/cros_ec_commands.h
> index 2b16e95..c907353 100644
> --- a/include/linux/mfd/cros_ec_commands.h
> +++ b/include/linux/mfd/cros_ec_commands.h
> @@ -2904,16 +2904,33 @@ enum usb_pd_control_mux {
> USB_PD_CTRL_MUX_AUTO = 5,
> };
>
> +enum usb_pd_control_swap {
> + USB_PD_CTRL_SWAP_NONE = 0,
> + USB_PD_CTRL_SWAP_DATA = 1,
> + USB_PD_CTRL_SWAP_POWER = 2,
> + USB_PD_CTRL_SWAP_VCONN = 3,
> + USB_PD_CTRL_SWAP_COUNT
> +};
> +
> struct ec_params_usb_pd_control {
> uint8_t port;
> uint8_t role;
> uint8_t mux;
> + uint8_t swap;
> } __packed;
>
> #define PD_CTRL_RESP_ENABLED_COMMS (1 << 0) /* Communication enabled */
> #define PD_CTRL_RESP_ENABLED_CONNECTED (1 << 1) /* Device connected */
> #define PD_CTRL_RESP_ENABLED_PD_CAPABLE (1 << 2) /* Partner is PD capable */
>
> +#define PD_CTRL_RESP_ROLE_POWER (1 << 0) /* 0=SNK/1=SRC */
> +#define PD_CTRL_RESP_ROLE_DATA (1 << 1) /* 0=UFP/1=DFP */
> +#define PD_CTRL_RESP_ROLE_VCONN (1 << 2) /* Vconn status */
> +#define PD_CTRL_RESP_ROLE_DR_POWER (1 << 3) /* Partner is dualrole power */
> +#define PD_CTRL_RESP_ROLE_DR_DATA (1 << 4) /* Partner is dualrole data */
> +#define PD_CTRL_RESP_ROLE_USB_COMM (1 << 5) /* Partner USB comm capable */
> +#define PD_CTRL_RESP_ROLE_EXT_POWERED (1 << 6) /* Partner externally powerd */
> +
> struct ec_response_usb_pd_control_v1 {
> uint8_t enabled;
> uint8_t role;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
--
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 2/2] arm64: allwinner: a64: bananapi-m64: add usb otg
From: Chen-Yu Tsai @ 2017-12-07 3:24 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Chen-Yu Tsai, Icenowy Zheng, Rob Herring,
Mark Rutland, Catalin Marinas, Will Deacon, Michael Trimarchi,
linux-arm-kernel, devicetree, linux-kernel, linux-sunxi,
Jagan Teki
In-Reply-To: <1512582664-24936-1-git-send-email-jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
On Thu, Dec 7, 2017 at 1:51 AM, Jagan Teki <jagannadh.teki-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> usb otg on bananapi-m64 has configured with USB-ID with PH9
> and USB-DRVVBUS attached with dcdc1 regulatort.
That is not how you read the schematic...
Intersecting lines that are tied together will have a dot representing
the connection. The DCDC1 line is a pull-up for the ID pin. This is very
clear because it has a resistor connected in series.
VBUS for OTG is controlled by the IC displayed to the right in the
schematic, which is powered from 5V, and controlled by the DRVVBUS
pin from the PMIC. Please take a look at how the A31/A33/A83T board
dts files represent this.
ChenYu
^ permalink raw reply
* Re: [PATCH v3 14/15] ARM: dts: sun8i: a711: Reinstate the PMIC compatible
From: Chen-Yu Tsai @ 2017-12-07 3:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, David Airlie, Chen-Yu Tsai, dri-devel,
linux-kernel, Mark Rutland, Rob Herring, linux-arm-kernel,
Priit Laes, Icenowy Zheng, Thomas Petazzoni, Jernej Skrabec,
devicetree
In-Reply-To: <25b482f19587ff195582995c11ee9d07f5bf42d2.1512486553.git-series.maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Dec 5, 2017 at 11:10 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> When we added the regulator support in commit 90c5d7cdae64 ("ARM: dts:
> sun8i: a711: Add regulator support"), we also dropped the PMIC's
> compatible. Since it's not in the PMIC DTSI, unlike most other PMIC
> DTSI, it obviously wasn't probing anymore.
>
> Re-add it so that everything works again.
>
> Fixes: 90c5d7cdae64 ("ARM: dts: sun8i: a711: Add regulator support")
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@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
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