Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v4 1/6] arm64: arch_timer: Add device tree binding for hisilicon-161601 erratum
From: Hanjun Guo @ 2016-11-25  1:57 UTC (permalink / raw)
  To: John Garry, Ding Tianhong, catalin.marinas-5wv7dgnIgG8,
	will.deacon-5wv7dgnIgG8, marc.zyngier-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, oss-fOR+EgIDQEHk1uMJSBkQmQ,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linuxarm-hv44wF8Li93QT0dZR+AlfA
In-Reply-To: <624c1751-9b66-1d10-78ae-8cb4edea6109-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>

Hi John,

On 11/24/2016 08:12 PM, John Garry wrote:
> On 21/11/2016 12:49, Ding Tianhong wrote:
>> Ping....
>
> Hi,
>
> was there a cover letter for 0/6? I never saw it.

There isn't a cover letter, do we need to add it and
resend (to make thing clear)?

Thanks
Hanjun
--
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: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2016-11-25  0:41 UTC (permalink / raw)
  To: Florian Fainelli
  Cc: Jerome Brunet, Sebastian Frias, linux-amlogic, devicetree, netdev,
	davem, khilman, mark.rutland, robh+dt, linux-arm-kernel,
	alexandre.torgue, peppe.cavallaro, carlo, Mans Rullgard,
	Andrew Lunn
In-Reply-To: <e6ca0941-e2e3-dd93-d4d3-8fbd76b60e17@gmail.com>

On Thu, Nov 24, 2016 at 7:55 PM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 24/11/2016 à 09:05, Martin Blumenstingl a écrit :
>> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
>>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>>> cycle TX clock delay. This seems to work fine for many boards (for
>>>> example Odroid-C2 or Amlogic's reference boards) but there are some
>>>> others where TX traffic is simply broken.
>>>> There are probably multiple reasons why it's working on some boards
>>>> while it's broken on others:
>>>> - some of Amlogic's reference boards are using a Micrel PHY
>>>> - hardware circuit design
>>>> - maybe more...
>>>>
>>>> This raises a question though:
>>>> Which device is supposed to enable the TX delay when both MAC and PHY
>>>> support it? And should we implement it for each PHY / MAC separately
>>>> or should we think about a more generic solution (currently it's not
>>>> possible to disable the TX delay generated by the RTL8211F PHY via
>>>> devicetree when using phy-mode "rgmii")?
>>>
>>> Actually you can skip the part which activate the Tx-delay on the phy
>>> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>>>
>>> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
>>> but PHY_INTERFACE_MODE_RGMII_ID.
>> unfortunately this is not true for RTL8211F (I did my previous tests
>> with the same expectation in mind)!
>> the code seems to suggest that TX-delay is disabled whenever mode !=
>> PHY_INTERFACE_MODE_RGMII.
>> BUT: on my device RTL8211F_TX_DELAY is set even before
>> "phy_write(phydev, 0x11, reg);"!
>
> (Adding Sebastian (and Mans, and Andrew) since he raised the same
> question a while ago. I think I now understand a bit better what
> Sebastian was after a couple of weeks ago)
>
>>
>> Based on what I found it seems that rgmii-id, rgmii-txid and
>> rgmii-rxid are supposed to be handled by the PHY.
>
> Correct, the meaning of PHY_INTERFACE_MODE should be from the
> perspective of the PHY device:
>
> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
and PHY_INTERFACE_MODE_RGMII_ID is basically _TXID and _RXID combined
(meaning that the PHY is responsible for the TX and RX delays)

>> That would mean that we have two problems here:
>> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
>> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
>> enable the TX-delay in that case - otherwise explicitly disable it
>
> Agreed.
(on a side-not: it seems that the RTL8211F's TX-delay setting is
either untouched by a hardware reset via GPIO or enabled automatically
during hardware reset via GPIO)

>> 2) dwmac-meson8b.c should only use the configured TX-delay for
>> PHY_INTERFACE_MODE_RGMII
>> @Florian: could you please share your thoughts on this (who handles
>> the TX delay in which case)?
>
> This also seems reasonable to do, provided that the PHY is also properly
> configured not to add delays in both directions, and therefore assumes
> that the MAC does it.
on Amlogic Meson systems (at least on the ARM64 ones) all customer
devices with Gbit ethernet are using the RTL8211F PHY. The only
exception are some development/reference boards from Amlogic
themselves, which seem to be using a Micrel RGMII PHY.

> We have a fairly large problem with how RGMII delays are done in PHYLIB
> and Ethernet MAC drivers (or just in general), where we can't really
> intersect properly what a PHY is supporting (in terms of internal
> delays), and what the MAC supports either. One possible approach could
> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
> support (ideally, even with normalized nanosecond delay values), and
> then intersect that with the requested phy_interface_t during
> phy_{attach,connect} time, and feed this back to the MAC with a special
> error code/callback, so we could gracefully try to choose another
> PHY_INTERFACE_MODE_* value that the MAC supports....
>
> A larger problem is that a number of drivers have been deployed, and
> Device Trees, possibly with the meaning of "phy-mode" and
> "phy-connection-type" being from the MAC perspective, and not the PHY
> perspective *sigh*, good luck auditing those.
>
> So from there, here is possibly what we could do
>
> - submit a series of patches that update the PHYLIB documentation (there
> are other things missing here) and make it clear from which entity (PHY
> or MAC) does the delay apply to, document the "intersection" problem here
sounds like a good idea, maybe we should move this to a separate thread (I guess
this is the part which is especially interesting for Sebastian, Mans
and Andrew)?

> - have you document the configured behavior for dwmac-meson8b that we
> just discussed here in v2 of this patch series
I would add something like "...using the phy-modes rgmii-id or
rgmii-txid means that the TX-delay will be added by the PHY, thus no
TX-delay should be configured for the MAC/dwmac-meson8b glue" (I'll
improve this, I just want a quick confirmation that I get your idea
right)

Thanks for the quick and helpful answer Florian!


Regards,
Martin

^ permalink raw reply

* [PATCH v2] ARM: dts: imx6qdl-nitrogen6x: remove duplicate iomux entry
From: Gary Bisson @ 2016-11-24 23:42 UTC (permalink / raw)
  To: shawnguo; +Cc: Gary Bisson, devicetree, robh+dt, linux-arm-kernel, kernel
In-Reply-To: <20161124231638.12840-1-gary.bisson@boundarydevices.com>

The NANDF_CS2 pad is also part of the wlan-vmmcgrp iomux group.

Removing is from the usdhc2grp group avoids the following error:
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_NANDF_CS2 already requested
by regulators:regulator@4; cannot claim for 2194000.usdhc
imx6q-pinctrl 20e0000.iomuxc: pin-187 (2194000.usdhc) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 187
(MX6Q_PAD_NANDF_CS2) from group usdhc2grp on device 20e0000.iomuxc

Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
---
Hi all,

Changelog v1->v2:
- fix typo in patch title

Regards,
Gary
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..26d0604 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -533,7 +533,6 @@
 				MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17071
 				MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17071
 				MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17071
-				MX6QDL_PAD_NANDF_CS2__GPIO6_IO15	0x000b0
 			>;
 		};
 
-- 
2.9.3

^ permalink raw reply related

* Re: Question regarding clocks in the DW-HDMI DT bindings
From: Laurent Pinchart @ 2016-11-24 23:26 UTC (permalink / raw)
  To: Vladimir Zapolskiy
  Cc: devicetree, Mike Turquette, Stephen Boyd, DRI mailing list,
	Andy Yan
In-Reply-To: <831329ae-1c16-07ba-3eca-95f6ff8dbae2@mentor.com>

Hello Fabio and Vladimir,

Thank you for your quick responses.

On Friday 25 Nov 2016 00:16:00 Vladimir Zapolskiy wrote:
> On 11/25/2016 12:07 AM, Fabio Estevam wrote:
> > On Thu, Nov 24, 2016 at 7:16 PM, Laurent Pinchart wrote:
> >> Hi Andy,
> >> 
> >> As the author of the DW-HDMI DT bindings this question is addressed to
> >> you, but information from anyone is more than welcome.
> >> 
> >> The DT bindings specify two clocks named "iahb" and "isfr" but don't
> >> describe them. While I assume that the "isfr" clock corresponds to the
> >> "isfrclk" input signal of the DW HDMI, there is no "iahb" clock
> >> described in the IP core datasheet.
> > 
> > i.MX6Q has a DW-HDMI IP block.
> > 
> > The names in the devicetree binding matches the ones listed at the
> > i.MX6Q Reference Manual - Table 33-1. HDMI Clocks
>
> correct, for your convenience the table is copied below:
> 
> Clock name |     Clock Root     | Description
> -----------+--------------------+---------------------------------------
>    iahbclk  | ahb_clk_root       | Bus clock
>    icecclk  | ckil_sync_clk_root | CEC low-frequency clock (32kHZ)
>    ihclk    | ahb_clk_root       | Module clock
>    isfrclk  | video_27m_clk_root | Internal SFR clock (video clock 27MHz)
> 
> Here AHB stands for ARM Advanced High-performance Bus.

That's what I suspected. I believe the "iahb" name is wrong, as the DW HDMI TX 
IP core clearly documents the bus clock as being called "iapbclk". We could 
rename that in the DT bindings (with compatibility code in the driver to keep 
supporting the old name) but it might not be worth it. The bindings should 
however document that the "iahb" clock is the IP core's "iapbclk" bus clock.

Another question I have about the bus clock (CC'ing the devicetree mailing 
list as well as the clock maintainers) is whether it should be made optional. 
The clock is obviously mandatory from a hardware point of view (given that APB 
is a synchronous bus and thus requires a clock), but in some SoCs 
(specifically for the Renesas SoCs) that clock is always on and can't be 
controlled. We already omit bus clocks in DT for most IP cores when the clock 
can never be controlled (and we also omit a bunch of other clocks that we 
don't even know exist), so it could make sense to make the clock optional. 
Otherwise there would be runtime overhead trying to handle a clock that can't 
be controlled.

> By the way while we're discussing DW HDMI bindings specific to iMX,
> I would recommend to remove utterly hackish and iMX only "gpr"
> property from the example in bindings/display/bridge/dw_hdmi.txt

-- 
Regards,

Laurent Pinchart

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* [PATCH] ARM: dts: imx6qdl-ntirogen6x: remove duplicate iomux entry
From: Gary Bisson @ 2016-11-24 23:16 UTC (permalink / raw)
  To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
  Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Gary Bisson

The NANDF_CS2 pad is also part of the wlan-vmmcgrp iomux group.

Removing is from the usdhc2grp group avoids the following error:
imx6q-pinctrl 20e0000.iomuxc: pin MX6Q_PAD_NANDF_CS2 already requested
by regulators:regulator@4; cannot claim for 2194000.usdhc
imx6q-pinctrl 20e0000.iomuxc: pin-187 (2194000.usdhc) status -22
imx6q-pinctrl 20e0000.iomuxc: could not request pin 187
(MX6Q_PAD_NANDF_CS2) from group usdhc2grp on device 20e0000.iomuxc

Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
---
 arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index e476d01..26d0604 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -533,7 +533,6 @@
 				MX6QDL_PAD_SD2_DAT1__SD2_DATA1		0x17071
 				MX6QDL_PAD_SD2_DAT2__SD2_DATA2		0x17071
 				MX6QDL_PAD_SD2_DAT3__SD2_DATA3		0x17071
-				MX6QDL_PAD_NANDF_CS2__GPIO6_IO15	0x000b0
 			>;
 		};
 
-- 
2.9.3

--
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 v9 1/4] checks: Pass boot_info to the check methods
From: David Gibson @ 2016-11-24 22:58 UTC (permalink / raw)
  To: Pantelis Antoniou
  Cc: Jon Loeliger, Grant Likely, Frank Rowand, Rob Herring, Jan Luebbe,
	Sascha Hauer, Phil Elwell, Simon Glass, Maxime Ripard,
	Thomas Petazzoni, Boris Brezillon, Antoine Tenart, Stephen Boyd,
	Devicetree Compiler, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479990693-14260-2-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 13552 bytes --]

On Thu, Nov 24, 2016 at 02:31:30PM +0200, Pantelis Antoniou wrote:
> As preparation for overlay support we need to pass boot info
> as an extra boot_info parameter to each check method.
> 
> No other functional changes are made.
> 
> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>

You don't really need to pass both bi and dt, since bi->dt will get
you the same thing.

> ---
>  checks.c | 113 +++++++++++++++++++++++++++++++++------------------------------
>  1 file changed, 59 insertions(+), 54 deletions(-)
> 
> diff --git a/checks.c b/checks.c
> index 0381c98..609975a 100644
> --- a/checks.c
> +++ b/checks.c
> @@ -40,7 +40,8 @@ enum checkstatus {
>  
>  struct check;
>  
> -typedef void (*check_fn)(struct check *c, struct node *dt, struct node *node);
> +typedef void (*check_fn)(struct check *c, struct boot_info *bi,
> +			 struct node *dt, struct node *node);
>  
>  struct check {
>  	const char *name;
> @@ -97,19 +98,20 @@ static inline void check_msg(struct check *c, const char *fmt, ...)
>  		check_msg((c), __VA_ARGS__); \
>  	} while (0)
>  
> -static void check_nodes_props(struct check *c, struct node *dt, struct node *node)
> +static void check_nodes_props(struct check *c, struct boot_info *bi,
> +			      struct node *dt, struct node *node)
>  {
>  	struct node *child;
>  
>  	TRACE(c, "%s", node->fullpath);
>  	if (c->fn)
> -		c->fn(c, dt, node);
> +		c->fn(c, bi, dt, node);
>  
>  	for_each_child(node, child)
> -		check_nodes_props(c, dt, child);
> +		check_nodes_props(c, bi, dt, child);
>  }
>  
> -static bool run_check(struct check *c, struct node *dt)
> +static bool run_check(struct check *c, struct boot_info *bi, struct node *dt)
>  {
>  	bool error = false;
>  	int i;
> @@ -123,7 +125,7 @@ static bool run_check(struct check *c, struct node *dt)
>  
>  	for (i = 0; i < c->num_prereqs; i++) {
>  		struct check *prq = c->prereq[i];
> -		error = error || run_check(prq, dt);
> +		error = error || run_check(prq, bi, dt);
>  		if (prq->status != PASSED) {
>  			c->status = PREREQ;
>  			check_msg(c, "Failed prerequisite '%s'",
> @@ -134,7 +136,7 @@ static bool run_check(struct check *c, struct node *dt)
>  	if (c->status != UNCHECKED)
>  		goto out;
>  
> -	check_nodes_props(c, dt, dt);
> +	check_nodes_props(c, bi, dt, dt);
>  
>  	if (c->status == UNCHECKED)
>  		c->status = PASSED;
> @@ -153,15 +155,15 @@ out:
>   */
>  
>  /* A check which always fails, for testing purposes only */
> -static inline void check_always_fail(struct check *c, struct node *dt,
> -				     struct node *node)
> +static inline void check_always_fail(struct check *c, struct boot_info *bi,
> +				     struct node *dt, struct node *node)
>  {
>  	FAIL(c, "always_fail check");
>  }
>  CHECK(always_fail, check_always_fail, NULL);
>  
> -static void check_is_string(struct check *c, struct node *root,
> -			    struct node *node)
> +static void check_is_string(struct check *c, struct boot_info *bi,
> +			    struct node *root, struct node *node)
>  {
>  	struct property *prop;
>  	char *propname = c->data;
> @@ -179,8 +181,8 @@ static void check_is_string(struct check *c, struct node *root,
>  #define ERROR_IF_NOT_STRING(nm, propname) \
>  	ERROR(nm, check_is_string, (propname))
>  
> -static void check_is_cell(struct check *c, struct node *root,
> -			  struct node *node)
> +static void check_is_cell(struct check *c, struct boot_info *bi,
> +			  struct node *root, struct node *node)
>  {
>  	struct property *prop;
>  	char *propname = c->data;
> @@ -202,8 +204,8 @@ static void check_is_cell(struct check *c, struct node *root,
>   * Structural check functions
>   */
>  
> -static void check_duplicate_node_names(struct check *c, struct node *dt,
> -				       struct node *node)
> +static void check_duplicate_node_names(struct check *c, struct boot_info *bi,
> +				       struct node *dt, struct node *node)
>  {
>  	struct node *child, *child2;
>  
> @@ -217,8 +219,8 @@ static void check_duplicate_node_names(struct check *c, struct node *dt,
>  }
>  ERROR(duplicate_node_names, check_duplicate_node_names, NULL);
>  
> -static void check_duplicate_property_names(struct check *c, struct node *dt,
> -					   struct node *node)
> +static void check_duplicate_property_names(struct check *c, struct boot_info *bi,
> +					   struct node *dt, struct node *node)
>  {
>  	struct property *prop, *prop2;
>  
> @@ -239,8 +241,8 @@ ERROR(duplicate_property_names, check_duplicate_property_names, NULL);
>  #define DIGITS		"0123456789"
>  #define PROPNODECHARS	LOWERCASE UPPERCASE DIGITS ",._+*#?-"
>  
> -static void check_node_name_chars(struct check *c, struct node *dt,
> -				  struct node *node)
> +static void check_node_name_chars(struct check *c, struct boot_info *bi,
> +				  struct node *dt, struct node *node)
>  {
>  	int n = strspn(node->name, c->data);
>  
> @@ -250,8 +252,8 @@ static void check_node_name_chars(struct check *c, struct node *dt,
>  }
>  ERROR(node_name_chars, check_node_name_chars, PROPNODECHARS "@");
>  
> -static void check_node_name_format(struct check *c, struct node *dt,
> -				   struct node *node)
> +static void check_node_name_format(struct check *c, struct boot_info *bi,
> +				   struct node *dt, struct node *node)
>  {
>  	if (strchr(get_unitname(node), '@'))
>  		FAIL(c, "Node %s has multiple '@' characters in name",
> @@ -259,8 +261,8 @@ static void check_node_name_format(struct check *c, struct node *dt,
>  }
>  ERROR(node_name_format, check_node_name_format, NULL, &node_name_chars);
>  
> -static void check_unit_address_vs_reg(struct check *c, struct node *dt,
> -			     struct node *node)
> +static void check_unit_address_vs_reg(struct check *c, struct boot_info *bi,
> +				      struct node *dt, struct node *node)
>  {
>  	const char *unitname = get_unitname(node);
>  	struct property *prop = get_property(node, "reg");
> @@ -283,8 +285,8 @@ static void check_unit_address_vs_reg(struct check *c, struct node *dt,
>  }
>  WARNING(unit_address_vs_reg, check_unit_address_vs_reg, NULL);
>  
> -static void check_property_name_chars(struct check *c, struct node *dt,
> -				      struct node *node)
> +static void check_property_name_chars(struct check *c, struct boot_info *bi,
> +				      struct node *dt, struct node *node)
>  {
>  	struct property *prop;
>  
> @@ -305,9 +307,10 @@ ERROR(property_name_chars, check_property_name_chars, PROPNODECHARS);
>  	((prop) ? (prop)->name : ""), \
>  	((prop) ? "' in " : ""), (node)->fullpath
>  
> -static void check_duplicate_label(struct check *c, struct node *dt,
> -				  const char *label, struct node *node,
> -				  struct property *prop, struct marker *mark)
> +static void check_duplicate_label(struct check *c, struct boot_info *bi,
> +				  struct node *dt, const char *label,
> +				  struct node *node, struct property *prop,
> +				  struct marker *mark)
>  {
>  	struct node *othernode = NULL;
>  	struct property *otherprop = NULL;
> @@ -331,29 +334,30 @@ static void check_duplicate_label(struct check *c, struct node *dt,
>  		     DESCLABEL_ARGS(othernode, otherprop, othermark));
>  }
>  
> -static void check_duplicate_label_node(struct check *c, struct node *dt,
> -				       struct node *node)
> +static void check_duplicate_label_node(struct check *c, struct boot_info *bi,
> +				       struct node *dt, struct node *node)
>  {
>  	struct label *l;
>  	struct property *prop;
>  
>  	for_each_label(node->labels, l)
> -		check_duplicate_label(c, dt, l->label, node, NULL, NULL);
> +		check_duplicate_label(c, bi, dt, l->label, node, NULL, NULL);
>  
>  	for_each_property(node, prop) {
>  		struct marker *m = prop->val.markers;
>  
>  		for_each_label(prop->labels, l)
> -			check_duplicate_label(c, dt, l->label, node, prop, NULL);
> +			check_duplicate_label(c, bi, dt, l->label, node, prop, NULL);
>  
>  		for_each_marker_of_type(m, LABEL)
> -			check_duplicate_label(c, dt, m->ref, node, prop, m);
> +			check_duplicate_label(c, bi, dt, m->ref, node, prop, m);
>  	}
>  }
>  ERROR(duplicate_label, check_duplicate_label_node, NULL);
>  
> -static cell_t check_phandle_prop(struct check *c, struct node *root,
> -				 struct node *node, const char *propname)
> +static cell_t check_phandle_prop(struct check *c, struct boot_info *bi,
> +				 struct node *root, struct node *node,
> +				 const char *propname)
>  {
>  	struct property *prop;
>  	struct marker *m;
> @@ -398,8 +402,8 @@ static cell_t check_phandle_prop(struct check *c, struct node *root,
>  	return phandle;
>  }
>  
> -static void check_explicit_phandles(struct check *c, struct node *root,
> -				    struct node *node)
> +static void check_explicit_phandles(struct check *c, struct boot_info *bi,
> +				    struct node *root, struct node *node)
>  {
>  	struct node *other;
>  	cell_t phandle, linux_phandle;
> @@ -407,9 +411,9 @@ static void check_explicit_phandles(struct check *c, struct node *root,
>  	/* Nothing should have assigned phandles yet */
>  	assert(!node->phandle);
>  
> -	phandle = check_phandle_prop(c, root, node, "phandle");
> +	phandle = check_phandle_prop(c, bi, root, node, "phandle");
>  
> -	linux_phandle = check_phandle_prop(c, root, node, "linux,phandle");
> +	linux_phandle = check_phandle_prop(c, bi, root, node, "linux,phandle");
>  
>  	if (!phandle && !linux_phandle)
>  		/* No valid phandles; nothing further to check */
> @@ -433,8 +437,8 @@ static void check_explicit_phandles(struct check *c, struct node *root,
>  }
>  ERROR(explicit_phandles, check_explicit_phandles, NULL);
>  
> -static void check_name_properties(struct check *c, struct node *root,
> -				  struct node *node)
> +static void check_name_properties(struct check *c, struct boot_info *bi,
> +				  struct node *root, struct node *node)
>  {
>  	struct property **pp, *prop = NULL;
>  
> @@ -467,8 +471,8 @@ ERROR(name_properties, check_name_properties, NULL, &name_is_string);
>   * Reference fixup functions
>   */
>  
> -static void fixup_phandle_references(struct check *c, struct node *dt,
> -				     struct node *node)
> +static void fixup_phandle_references(struct check *c, struct boot_info *bi,
> +				     struct node *dt, struct node *node)
>  {
>  	struct property *prop;
>  
> @@ -495,8 +499,8 @@ static void fixup_phandle_references(struct check *c, struct node *dt,
>  ERROR(phandle_references, fixup_phandle_references, NULL,
>        &duplicate_node_names, &explicit_phandles);
>  
> -static void fixup_path_references(struct check *c, struct node *dt,
> -				  struct node *node)
> +static void fixup_path_references(struct check *c, struct boot_info *bi,
> +				  struct node *dt, struct node *node)
>  {
>  	struct property *prop;
>  
> @@ -534,8 +538,8 @@ WARNING_IF_NOT_STRING(device_type_is_string, "device_type");
>  WARNING_IF_NOT_STRING(model_is_string, "model");
>  WARNING_IF_NOT_STRING(status_is_string, "status");
>  
> -static void fixup_addr_size_cells(struct check *c, struct node *dt,
> -				  struct node *node)
> +static void fixup_addr_size_cells(struct check *c, struct boot_info *bi,
> +				  struct node *dt, struct node *node)
>  {
>  	struct property *prop;
>  
> @@ -558,8 +562,8 @@ WARNING(addr_size_cells, fixup_addr_size_cells, NULL,
>  #define node_size_cells(n) \
>  	(((n)->size_cells == -1) ? 1 : (n)->size_cells)
>  
> -static void check_reg_format(struct check *c, struct node *dt,
> -			     struct node *node)
> +static void check_reg_format(struct check *c, struct boot_info *bi,
> +			     struct node *dt, struct node *node)
>  {
>  	struct property *prop;
>  	int addr_cells, size_cells, entrylen;
> @@ -587,8 +591,8 @@ static void check_reg_format(struct check *c, struct node *dt,
>  }
>  WARNING(reg_format, check_reg_format, NULL, &addr_size_cells);
>  
> -static void check_ranges_format(struct check *c, struct node *dt,
> -				struct node *node)
> +static void check_ranges_format(struct check *c, struct boot_info *bi,
> +				struct node *dt, struct node *node)
>  {
>  	struct property *prop;
>  	int c_addr_cells, p_addr_cells, c_size_cells, p_size_cells, entrylen;
> @@ -631,8 +635,8 @@ WARNING(ranges_format, check_ranges_format, NULL, &addr_size_cells);
>  /*
>   * Style checks
>   */
> -static void check_avoid_default_addr_size(struct check *c, struct node *dt,
> -					  struct node *node)
> +static void check_avoid_default_addr_size(struct check *c, struct boot_info *bi,
> +					  struct node *dt, struct node *node)
>  {
>  	struct property *reg, *ranges;
>  
> @@ -657,6 +661,7 @@ WARNING(avoid_default_addr_size, check_avoid_default_addr_size, NULL,
>  	&addr_size_cells);
>  
>  static void check_obsolete_chosen_interrupt_controller(struct check *c,
> +						       struct boot_info *bi,
>  						       struct node *dt,
>  						       struct node *node)
>  {
> @@ -773,7 +778,7 @@ void process_checks(bool force, struct boot_info *bi)
>  		struct check *c = check_table[i];
>  
>  		if (c->warn || c->error)
> -			error = error || run_check(c, dt);
> +			error = error || run_check(c, bi, dt);
>  	}
>  
>  	if (error) {

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* [PATCH] dt-bindings: document how to setup rockchip timers as clocksource
From: Alexander Kochetkov @ 2016-11-24 22:12 UTC (permalink / raw)
  To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	wxt-TNX95d0MmH7DzftRWevZcw, daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A,
	huangtao-TNX95d0MmH7DzftRWevZcw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Alexander Kochetkov

The patch describes how to setup rockchip timers in device tree
so they can be used as clocksource.

I'm going to implement this feature.

Signed-off-by: Alexander Kochetkov <al.kochet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 .../bindings/timer/rockchip,rk-timer.txt           |   35 +++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index 7bc9691..15f8fed 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -16,7 +16,18 @@ Required properties:
 - clock-names : must include the following entries:
   "timer", "pclk"
 
-Example:
+Note:
+If device tree contain only one timer, than the timer will be intialized
+as clockevent provider. If device tree contain two timers, than first timer
+will be initialized as clockevent provider and second one as clocksource.
+
+If you want to bind specific timer as clockevent (i.e. one from alive subsystem)
+and specific timer as clocksource, you can number the timers in "aliases" node.
+
+If device tree contain only one timer and the timer is named as timer1 in
+"aliases" node, then the timer will be initialized as clocksource.
+
+Example (clockevent only):
 	timer: timer@ff810000 {
 		compatible = "rockchip,rk3288-timer";
 		reg = <0xff810000 0x20>;
@@ -24,3 +35,25 @@ Example:
 		clocks = <&xin24m>, <&cru PCLK_TIMER>;
 		clock-names = "timer", "pclk";
 	};
+
+Example (clockevent and clocksource with explicit numbering):
+	aliases {
+		timer0 = &timer6;
+		timer1 = &timer5;
+	};
+
+	timer5: timer@20038080 {
+		compatible = "rockchip,rk3188-timer", "rockchip,rk3288-timer";
+		reg = <0x20038080 0x20>;
+		interrupts = <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_TIMER5>, <&cru PCLK_TIMER0>;
+		clock-names = "timer", "pclk";
+	};
+
+	timer6: timer@200380A0 {
+		compatible = ""rockchip,rk3188-timer", rockchip,rk3288-timer";
+		reg = <0x200380A0 0x20>;
+		interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&cru SCLK_TIMER6>, <&cru PCLK_TIMER0>;
+		clock-names = "timer", "pclk";
+	};
-- 
1.7.9.5

--
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

* [PATCH] dt-bindings: clarify compatible field usage for rockchip timers
From: Alexander Kochetkov @ 2016-11-24 22:10 UTC (permalink / raw)
  To: robh+dt, mark.rutland, wxt, daniel.lezcano, huangtao, devicetree,
	linux-arm-kernel, linux-rockchip, linux-kernel
  Cc: Alexander Kochetkov

rk3036 dtsi file already use compatible field as
"rockchip,rk3036-timer", "rockchip,rk3288-timer".

The patch clearly shows how that filed should be used on other chips.

Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
---
 .../bindings/timer/rockchip,rk-timer.txt           |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
index a41b184..7bc9691 100644
--- a/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/rockchip,rk-timer.txt
@@ -1,9 +1,15 @@
 Rockchip rk timer
 
 Required properties:
-- compatible: shall be one of:
-  "rockchip,rk3288-timer" - for rk3066, rk3036, rk3188, rk322x, rk3288, rk3368
-  "rockchip,rk3399-timer" - for rk3399
+- compatible: should be:
+  "rockchip,rk3036-timer", "rockchip,rk3288-timer": for Rockchip RK3036
+  "rockchip,rk3066-timer", "rockchip,rk3288-timer": for Rockchip RK3066
+  "rockchip,rk3188-timer", "rockchip,rk3288-timer": for Rockchip RK3188
+  "rockchip,rk322x-timer", "rockchip,rk3288-timer": for Rockchip RK322X
+   (please replace rk322x with exact device name and update this file)
+  "rockchip,rk3288-timer": for Rockchip RK3288
+  "rockchip,rk3368-timer", "rockchip,rk3288-timer": for Rockchip RK3368
+  "rockchip,rk3399-timer": for Rockchip RK3399
 - reg: base address of the timer register starting with TIMERS CONTROL register
 - interrupts: should contain the interrupts for Timer0
 - clocks : must contain an entry for each entry in clock-names
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
From: Maxime Ripard @ 2016-11-24 21:30 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Mark Rutland, devicetree, Vishnu Patekar, Arnd Bergmann,
	Jonathan Corbet, Andre Przywara, linux-doc@vger.kernel.org,
	Russell King, linux-kernel, Hans de Goede, Icenowy Zheng,
	linux-arm-kernel
In-Reply-To: <CAGb2v64taF9x9MDYW+KUEEUUoSx0bF68QNc7uZXQoNrsozMGtg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 645 bytes --]

On Wed, Nov 23, 2016 at 10:25:57PM +0800, Chen-Yu Tsai wrote:
> >>  &r_pio {
> >> @@ -111,6 +148,11 @@
> >>               pins = "PL10";
> >>               function = "gpio_out";
> >>       };
> >> +
> >> +     wifi_pwrseq_pin_opi0: wifi_pwrseq_pin@0 {
> >> +             allwinner,pins = "PL7";
> >> +             allwinner,function = "gpio_out";
> >
> > And same thing here.
> 
> Might we do away with the pinmux for gpio pins tradition?
> Recent patches I've sent all omit them.

Oh, yes, that's true.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Maxime Ripard @ 2016-11-24 21:29 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Icenowy Zheng, Jonathan Corbet, Chen-Yu Tsai, Mark Rutland,
	Russell King, Hans de Goede, Vishnu Patekar, Arnd Bergmann,
	linux-doc-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a4393a37-5008-ec76-9886-05f8686dadd5-5wv7dgnIgG8@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 7753 bytes --]

On Wed, Nov 23, 2016 at 09:23:49AM +0000, Andre Przywara wrote:
> Hi Maxime,
> 
> On 23/11/16 07:57, Maxime Ripard wrote:
> > On Tue, Nov 22, 2016 at 12:24:20AM +0800, Icenowy Zheng wrote:
> >> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
> >>
> >> Add a device tree file for it.
> >>
> >> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >> ---
> >> Changes since v2:
> >> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
> >> - removed uart3, which is not accessible on Orange Pi Zero.
> >> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
> >>   sun8i-h3.dtsi.
> >> - Removed allwinner,sun8i-h3 compatible.
> >>
> >>  arch/arm/boot/dts/Makefile                       |   1 +
> >>  arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
> > 
> > Ditto, h2-plus-orangepi-zero.
> > 
> >>  2 files changed, 138 insertions(+)
> >>  create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 802a10d..51a1dd7 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> >>  	sun8i-a33-sinlinx-sina33.dtb \
> >>  	sun8i-a83t-allwinner-h8homlet-v2.dtb \
> >>  	sun8i-a83t-cubietruck-plus.dtb \
> >> +	sun8i-h2plus-orangepi-zero.dtb \
> >>  	sun8i-h3-bananapi-m2-plus.dtb \
> >>  	sun8i-h3-nanopi-neo.dtb \
> >>  	sun8i-h3-orangepi-2.dtb \
> >> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> new file mode 100644
> >> index 0000000..b428e47
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
> >> @@ -0,0 +1,137 @@
> >> +/*
> >> + * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >> + *
> >> + * Based on sun8i-h3-orangepi-one.dts, which is:
> >> + *   Copyright (C) 2016 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> + *
> >> + * This file is dual-licensed: you can use it either under the terms
> >> + * of the GPL or the X11 license, at your option. Note that this dual
> >> + * licensing only applies to this file, and not this project as a
> >> + * whole.
> >> + *
> >> + *  a) This file is free software; you can redistribute it and/or
> >> + *     modify it under the terms of the GNU General Public License as
> >> + *     published by the Free Software Foundation; either version 2 of the
> >> + *     License, or (at your option) any later version.
> >> + *
> >> + *     This file is distributed in the hope that it will be useful,
> >> + *     but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + *     GNU General Public License for more details.
> >> + *
> >> + * Or, alternatively,
> >> + *
> >> + *  b) Permission is hereby granted, free of charge, to any person
> >> + *     obtaining a copy of this software and associated documentation
> >> + *     files (the "Software"), to deal in the Software without
> >> + *     restriction, including without limitation the rights to use,
> >> + *     copy, modify, merge, publish, distribute, sublicense, and/or
> >> + *     sell copies of the Software, and to permit persons to whom the
> >> + *     Software is furnished to do so, subject to the following
> >> + *     conditions:
> >> + *
> >> + *     The above copyright notice and this permission notice shall be
> >> + *     included in all copies or substantial portions of the Software.
> >> + *
> >> + *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> >> + *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> >> + *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> >> + *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> >> + *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> >> + *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> >> + *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> >> + *     OTHER DEALINGS IN THE SOFTWARE.
> >> + */
> >> +
> >> +/dts-v1/;
> >> +#include "sun8i-h3.dtsi"
> >> +#include "sunxi-common-regulators.dtsi"
> >> +
> >> +#include <dt-bindings/gpio/gpio.h>
> >> +#include <dt-bindings/input/input.h>
> >> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> >> +
> >> +/ {
> >> +	model = "Xunlong Orange Pi Zero";
> >> +	compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
> >> +
> >> +	aliases {
> >> +		serial0 = &uart0;
> >> +	};
> >> +
> >> +	chosen {
> >> +		stdout-path = "serial0:115200n8";
> >> +	};
> >> +
> >> +	leds {
> >> +		compatible = "gpio-leds";
> >> +		pinctrl-names = "default";
> >> +		pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
> >> +
> >> +		pwr_led {
> >> +			label = "orangepi:green:pwr";
> >> +			gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> >> +			default-state = "on";
> >> +		};
> >> +
> >> +		status_led {
> >> +			label = "orangepi:red:status";
> >> +			gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
> >> +		};
> >> +	};
> >> +};
> >> +
> >> +&ehci1 {
> >> +	status = "okay";
> >> +};
> >> +
> >> +&mmc0 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
> >> +	vmmc-supply = <&reg_vcc3v3>;
> >> +	bus-width = <4>;
> >> +	cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> >> +	cd-inverted;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&ohci1 {
> >> +	status = "okay";
> >> +};
> >> +
> >> +&pio {
> >> +	leds_opi0: led_pins@0 {
> >> +		pins = "PA17";
> >> +		function = "gpio_out";
> >> +	};
> >> +};
> >> +
> >> +&r_pio {
> >> +	leds_r_opi0: led_pins@0 {
> >> +		pins = "PL10";
> >> +		function = "gpio_out";
> >> +	};
> >> +};
> >> +
> >> +&uart0 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart0_pins_a>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&uart1 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart1_pins>;
> >> +	status = "disabled";
> >> +};
> >> +
> >> +&uart2 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart2_pins>;
> >> +	status = "disabled";
> >> +};
> > 
> > I'm not sure you answered me on this one. Are those exposed on the
> > headers? why did you put them as disabled here?
> 
> So they are on headers, though you have to solder the actual header pins
> yourself [1]. But also these are the normal pins multiplexed with GPIOs
> and other peripherals, so keeping them disabled is in line with the
> existing policy, if I got this correctly.
> 
> I agree that the status="disabled" is redundant, since we have that
> exact line already in the .dtsi. But I saw it in other DTs as well, most
> prominently in the sun8i-h3-orangepi-one.dts.
> 
> So I think we should remove the "status=" lines here, dtc will generate
> an identical dtb out of it. But we should keep the uart descriptions in
> to make it easier for users to see which SoC pins are used for these
> pins labeled UART[012] in the board description and schematic. Also all
> it takes to enable those is to overwrite the status property, which can
> easily be done inline (without resizing the dtb).

I'd rather have the status still in the DTS. It's true that it's
redundant, but it's also explicit. A node without any status would
give the impression that it is actually enabled, especially since a
node without a status is going to be probed.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [PATCH 3/3] pinctrl: sx150x: add support for sx1501, sx1504, sx1505 and sx1507
From: Peter Rosin @ 2016-11-24 21:02 UTC (permalink / raw)
  To: linux-kernel
  Cc: Linus Walleij, Rob Herring, Mark Rutland, Andrey Smirnov,
	Neil Armstrong, linux-gpio, devicetree
In-Reply-To: <1480020320-28354-4-git-send-email-peda@axentia.se>

On 2016-11-24 21:45, Peter Rosin wrote:
> Untested, register offsets carefully copied from datasheets.
> 
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
>  .../devicetree/bindings/pinctrl/pinctrl-sx150x.txt |  8 +-
>  drivers/pinctrl/pinctrl-sx150x.c                   | 98 ++++++++++++++++++++++
>  2 files changed, 104 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> index 83f8d5c449ba..bf76867168e9 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
> @@ -6,9 +6,13 @@ pin controller, GPIO, and interrupt bindings.
>  
>  Required properties:
>  - compatible: should be one of :
> +			"semtech,sx1501q",
>  			"semtech,sx1502q",
>  			"semtech,sx1503q",
> +			"semtech,sx1504q",
> +			"semtech,sx1505q",
>  			"semtech,sx1506q",
> +			"semtech,sx1507q",
>  			"semtech,sx1508q",
>  			"semtech,sx1509q".
>  
> @@ -28,7 +32,7 @@ Optional properties :
>  - interrupt-controller: Marks the device as a interrupt controller.
>  
>  - semtech,probe-reset: Will trigger a reset of the GPIO expander on probe,
> -		only for sx1508q and sx1509q
> +		only for sx1507q, sx1508q and sx1509q
>  
>  The GPIO expander can optionally be used as an interrupt controller, in
>  which case it uses the default two cell specifier.
> @@ -43,7 +47,7 @@ Optional properties for pin configuration sub-nodes:
>   - bias-pull-down: pull down the pin, except the OSCIO pin
>   - bias-pull-pin-default: use pin-default pull state, except the OSCIO pin
>   - drive-push-pull: drive actively high and low
> - - drive-open-drain: drive with open drain only for sx1508q and sx1509q and except the OSCIO pin
> + - drive-open-drain: drive with open drain only for sx1507q, sx1508q and sx1509q and except the OSCIO pin
>   - output-low: set the pin to output mode with low level
>   - output-high: set the pin to output mode with high level
>  
> diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
> index 97df9302e84b..eb6adbbd33f0 100644
> --- a/drivers/pinctrl/pinctrl-sx150x.c
> +++ b/drivers/pinctrl/pinctrl-sx150x.c
> @@ -116,6 +116,14 @@ struct sx150x_pinctrl {
>  	const struct sx150x_device_data *data;
>  };
>  
> +static const struct pinctrl_pin_desc sx150x_4_pins[] = {
> +	PINCTRL_PIN(0, "gpio0"),
> +	PINCTRL_PIN(1, "gpio1"),
> +	PINCTRL_PIN(2, "gpio2"),
> +	PINCTRL_PIN(3, "gpio3"),
> +	PINCTRL_PIN(8, "oscio"),

Should of course be:
+	PINCTRL_PIN(4, "oscio"),

If you want an updated patch, just ask...

Cheers,
Peter

> +};
> +
>  static const struct pinctrl_pin_desc sx150x_8_pins[] = {
>  	PINCTRL_PIN(0, "gpio0"),
>  	PINCTRL_PIN(1, "gpio1"),
> @@ -148,6 +156,26 @@ static const struct pinctrl_pin_desc sx150x_16_pins[] = {
>  	PINCTRL_PIN(16, "oscio"),
>  };
>  
> +static const struct sx150x_device_data sx1501q_device_data = {
> +	.model = SX150X_123,
> +	.reg_pullup	= 0x02,
> +	.reg_pulldn	= 0x03,
> +	.reg_dir	= 0x01,
> +	.reg_data	= 0x00,
> +	.reg_irq_mask	= 0x05,
> +	.reg_irq_src	= 0x08,
> +	.reg_sense	= 0x07,
> +	.pri.x123 = {
> +		.reg_pld_mode	= 0x10,
> +		.reg_pld_table0	= 0x11,
> +		.reg_pld_table2	= 0x13,
> +		.reg_advance	= 0xad,
> +	},
> +	.ngpios	= 4,
> +	.pins = sx150x_4_pins,
> +	.npins = 4, /* oscio not available */
> +};
> +
>  static const struct sx150x_device_data sx1502q_device_data = {
>  	.model = SX150X_123,
>  	.reg_pullup	= 0x02,
> @@ -194,6 +222,47 @@ static const struct sx150x_device_data sx1503q_device_data = {
>  	.npins  = 16, /* oscio not available */
>  };
>  
> +static const struct sx150x_device_data sx1504q_device_data = {
> +	.model = SX150X_456,
> +	.reg_pullup	= 0x02,
> +	.reg_pulldn	= 0x03,
> +	.reg_dir	= 0x01,
> +	.reg_data	= 0x00,
> +	.reg_irq_mask	= 0x05,
> +	.reg_irq_src	= 0x08,
> +	.reg_sense	= 0x07,
> +	.pri.x456 = {
> +		.reg_pld_mode	= 0x10,
> +		.reg_pld_table0	= 0x11,
> +		.reg_pld_table2	= 0x13,
> +	},
> +	.ngpios	= 4,
> +	.pins = sx150x_4_pins,
> +	.npins = 4, /* oscio not available */
> +};
> +
> +static const struct sx150x_device_data sx1505q_device_data = {
> +	.model = SX150X_456,
> +	.reg_pullup	= 0x02,
> +	.reg_pulldn	= 0x03,
> +	.reg_dir	= 0x01,
> +	.reg_data	= 0x00,
> +	.reg_irq_mask	= 0x05,
> +	.reg_irq_src	= 0x08,
> +	.reg_sense	= 0x06,
> +	.pri.x456 = {
> +		.reg_pld_mode	= 0x10,
> +		.reg_pld_table0	= 0x11,
> +		.reg_pld_table1	= 0x12,
> +		.reg_pld_table2	= 0x13,
> +		.reg_pld_table3	= 0x14,
> +		.reg_pld_table4	= 0x15,
> +	},
> +	.ngpios	= 8,
> +	.pins = sx150x_8_pins,
> +	.npins = 8, /* oscio not available */
> +};
> +
>  static const struct sx150x_device_data sx1506q_device_data = {
>  	.model = SX150X_456,
>  	.reg_pullup	= 0x04,
> @@ -217,6 +286,27 @@ static const struct sx150x_device_data sx1506q_device_data = {
>  	.npins = 16, /* oscio not available */
>  };
>  
> +static const struct sx150x_device_data sx1507q_device_data = {
> +	.model = SX150X_789,
> +	.reg_pullup	= 0x03,
> +	.reg_pulldn	= 0x04,
> +	.reg_dir	= 0x07,
> +	.reg_data	= 0x08,
> +	.reg_irq_mask	= 0x09,
> +	.reg_irq_src	= 0x0b,
> +	.reg_sense	= 0x0a,
> +	.pri.x789 = {
> +		.reg_drain	= 0x05,
> +		.reg_polarity	= 0x06,
> +		.reg_clock	= 0x0d,
> +		.reg_misc	= 0x0e,
> +		.reg_reset	= 0x7d,
> +	},
> +	.ngpios = 4,
> +	.pins = sx150x_4_pins,
> +	.npins = ARRAY_SIZE(sx150x_4_pins),
> +};
> +
>  static const struct sx150x_device_data sx1508q_device_data = {
>  	.model = SX150X_789,
>  	.reg_pullup	= 0x03,
> @@ -758,18 +848,26 @@ static const struct pinconf_ops sx150x_pinconf_ops = {
>  };
>  
>  static const struct i2c_device_id sx150x_id[] = {
> +	{"sx1501q", (kernel_ulong_t) &sx1501q_device_data },
>  	{"sx1502q", (kernel_ulong_t) &sx1502q_device_data },
>  	{"sx1503q", (kernel_ulong_t) &sx1503q_device_data },
> +	{"sx1504q", (kernel_ulong_t) &sx1504q_device_data },
> +	{"sx1505q", (kernel_ulong_t) &sx1505q_device_data },
>  	{"sx1506q", (kernel_ulong_t) &sx1506q_device_data },
> +	{"sx1507q", (kernel_ulong_t) &sx1507q_device_data },
>  	{"sx1508q", (kernel_ulong_t) &sx1508q_device_data },
>  	{"sx1509q", (kernel_ulong_t) &sx1509q_device_data },
>  	{}
>  };
>  
>  static const struct of_device_id sx150x_of_match[] = {
> +	{ .compatible = "semtech,sx1501q", .data = &sx1501q_device_data },
>  	{ .compatible = "semtech,sx1502q", .data = &sx1502q_device_data },
>  	{ .compatible = "semtech,sx1503q", .data = &sx1503q_device_data },
> +	{ .compatible = "semtech,sx1504q", .data = &sx1504q_device_data },
> +	{ .compatible = "semtech,sx1505q", .data = &sx1505q_device_data },
>  	{ .compatible = "semtech,sx1506q", .data = &sx1506q_device_data },
> +	{ .compatible = "semtech,sx1507q", .data = &sx1507q_device_data },
>  	{ .compatible = "semtech,sx1508q", .data = &sx1508q_device_data },
>  	{ .compatible = "semtech,sx1509q", .data = &sx1509q_device_data },
>  	{},
> 


^ permalink raw reply

* [PATCH 3/3] pinctrl: sx150x: add support for sx1501, sx1504, sx1505 and sx1507
From: Peter Rosin @ 2016-11-24 20:45 UTC (permalink / raw)
  To: linux-kernel
  Cc: Peter Rosin, Linus Walleij, Rob Herring, Mark Rutland,
	Andrey Smirnov, Neil Armstrong, linux-gpio, devicetree
In-Reply-To: <1480020320-28354-1-git-send-email-peda@axentia.se>

Untested, register offsets carefully copied from datasheets.

Signed-off-by: Peter Rosin <peda@axentia.se>
---
 .../devicetree/bindings/pinctrl/pinctrl-sx150x.txt |  8 +-
 drivers/pinctrl/pinctrl-sx150x.c                   | 98 ++++++++++++++++++++++
 2 files changed, 104 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
index 83f8d5c449ba..bf76867168e9 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
@@ -6,9 +6,13 @@ pin controller, GPIO, and interrupt bindings.
 
 Required properties:
 - compatible: should be one of :
+			"semtech,sx1501q",
 			"semtech,sx1502q",
 			"semtech,sx1503q",
+			"semtech,sx1504q",
+			"semtech,sx1505q",
 			"semtech,sx1506q",
+			"semtech,sx1507q",
 			"semtech,sx1508q",
 			"semtech,sx1509q".
 
@@ -28,7 +32,7 @@ Optional properties :
 - interrupt-controller: Marks the device as a interrupt controller.
 
 - semtech,probe-reset: Will trigger a reset of the GPIO expander on probe,
-		only for sx1508q and sx1509q
+		only for sx1507q, sx1508q and sx1509q
 
 The GPIO expander can optionally be used as an interrupt controller, in
 which case it uses the default two cell specifier.
@@ -43,7 +47,7 @@ Optional properties for pin configuration sub-nodes:
  - bias-pull-down: pull down the pin, except the OSCIO pin
  - bias-pull-pin-default: use pin-default pull state, except the OSCIO pin
  - drive-push-pull: drive actively high and low
- - drive-open-drain: drive with open drain only for sx1508q and sx1509q and except the OSCIO pin
+ - drive-open-drain: drive with open drain only for sx1507q, sx1508q and sx1509q and except the OSCIO pin
  - output-low: set the pin to output mode with low level
  - output-high: set the pin to output mode with high level
 
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index 97df9302e84b..eb6adbbd33f0 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -116,6 +116,14 @@ struct sx150x_pinctrl {
 	const struct sx150x_device_data *data;
 };
 
+static const struct pinctrl_pin_desc sx150x_4_pins[] = {
+	PINCTRL_PIN(0, "gpio0"),
+	PINCTRL_PIN(1, "gpio1"),
+	PINCTRL_PIN(2, "gpio2"),
+	PINCTRL_PIN(3, "gpio3"),
+	PINCTRL_PIN(8, "oscio"),
+};
+
 static const struct pinctrl_pin_desc sx150x_8_pins[] = {
 	PINCTRL_PIN(0, "gpio0"),
 	PINCTRL_PIN(1, "gpio1"),
@@ -148,6 +156,26 @@ static const struct pinctrl_pin_desc sx150x_16_pins[] = {
 	PINCTRL_PIN(16, "oscio"),
 };
 
+static const struct sx150x_device_data sx1501q_device_data = {
+	.model = SX150X_123,
+	.reg_pullup	= 0x02,
+	.reg_pulldn	= 0x03,
+	.reg_dir	= 0x01,
+	.reg_data	= 0x00,
+	.reg_irq_mask	= 0x05,
+	.reg_irq_src	= 0x08,
+	.reg_sense	= 0x07,
+	.pri.x123 = {
+		.reg_pld_mode	= 0x10,
+		.reg_pld_table0	= 0x11,
+		.reg_pld_table2	= 0x13,
+		.reg_advance	= 0xad,
+	},
+	.ngpios	= 4,
+	.pins = sx150x_4_pins,
+	.npins = 4, /* oscio not available */
+};
+
 static const struct sx150x_device_data sx1502q_device_data = {
 	.model = SX150X_123,
 	.reg_pullup	= 0x02,
@@ -194,6 +222,47 @@ static const struct sx150x_device_data sx1503q_device_data = {
 	.npins  = 16, /* oscio not available */
 };
 
+static const struct sx150x_device_data sx1504q_device_data = {
+	.model = SX150X_456,
+	.reg_pullup	= 0x02,
+	.reg_pulldn	= 0x03,
+	.reg_dir	= 0x01,
+	.reg_data	= 0x00,
+	.reg_irq_mask	= 0x05,
+	.reg_irq_src	= 0x08,
+	.reg_sense	= 0x07,
+	.pri.x456 = {
+		.reg_pld_mode	= 0x10,
+		.reg_pld_table0	= 0x11,
+		.reg_pld_table2	= 0x13,
+	},
+	.ngpios	= 4,
+	.pins = sx150x_4_pins,
+	.npins = 4, /* oscio not available */
+};
+
+static const struct sx150x_device_data sx1505q_device_data = {
+	.model = SX150X_456,
+	.reg_pullup	= 0x02,
+	.reg_pulldn	= 0x03,
+	.reg_dir	= 0x01,
+	.reg_data	= 0x00,
+	.reg_irq_mask	= 0x05,
+	.reg_irq_src	= 0x08,
+	.reg_sense	= 0x06,
+	.pri.x456 = {
+		.reg_pld_mode	= 0x10,
+		.reg_pld_table0	= 0x11,
+		.reg_pld_table1	= 0x12,
+		.reg_pld_table2	= 0x13,
+		.reg_pld_table3	= 0x14,
+		.reg_pld_table4	= 0x15,
+	},
+	.ngpios	= 8,
+	.pins = sx150x_8_pins,
+	.npins = 8, /* oscio not available */
+};
+
 static const struct sx150x_device_data sx1506q_device_data = {
 	.model = SX150X_456,
 	.reg_pullup	= 0x04,
@@ -217,6 +286,27 @@ static const struct sx150x_device_data sx1506q_device_data = {
 	.npins = 16, /* oscio not available */
 };
 
+static const struct sx150x_device_data sx1507q_device_data = {
+	.model = SX150X_789,
+	.reg_pullup	= 0x03,
+	.reg_pulldn	= 0x04,
+	.reg_dir	= 0x07,
+	.reg_data	= 0x08,
+	.reg_irq_mask	= 0x09,
+	.reg_irq_src	= 0x0b,
+	.reg_sense	= 0x0a,
+	.pri.x789 = {
+		.reg_drain	= 0x05,
+		.reg_polarity	= 0x06,
+		.reg_clock	= 0x0d,
+		.reg_misc	= 0x0e,
+		.reg_reset	= 0x7d,
+	},
+	.ngpios = 4,
+	.pins = sx150x_4_pins,
+	.npins = ARRAY_SIZE(sx150x_4_pins),
+};
+
 static const struct sx150x_device_data sx1508q_device_data = {
 	.model = SX150X_789,
 	.reg_pullup	= 0x03,
@@ -758,18 +848,26 @@ static const struct pinconf_ops sx150x_pinconf_ops = {
 };
 
 static const struct i2c_device_id sx150x_id[] = {
+	{"sx1501q", (kernel_ulong_t) &sx1501q_device_data },
 	{"sx1502q", (kernel_ulong_t) &sx1502q_device_data },
 	{"sx1503q", (kernel_ulong_t) &sx1503q_device_data },
+	{"sx1504q", (kernel_ulong_t) &sx1504q_device_data },
+	{"sx1505q", (kernel_ulong_t) &sx1505q_device_data },
 	{"sx1506q", (kernel_ulong_t) &sx1506q_device_data },
+	{"sx1507q", (kernel_ulong_t) &sx1507q_device_data },
 	{"sx1508q", (kernel_ulong_t) &sx1508q_device_data },
 	{"sx1509q", (kernel_ulong_t) &sx1509q_device_data },
 	{}
 };
 
 static const struct of_device_id sx150x_of_match[] = {
+	{ .compatible = "semtech,sx1501q", .data = &sx1501q_device_data },
 	{ .compatible = "semtech,sx1502q", .data = &sx1502q_device_data },
 	{ .compatible = "semtech,sx1503q", .data = &sx1503q_device_data },
+	{ .compatible = "semtech,sx1504q", .data = &sx1504q_device_data },
+	{ .compatible = "semtech,sx1505q", .data = &sx1505q_device_data },
 	{ .compatible = "semtech,sx1506q", .data = &sx1506q_device_data },
+	{ .compatible = "semtech,sx1507q", .data = &sx1507q_device_data },
 	{ .compatible = "semtech,sx1508q", .data = &sx1508q_device_data },
 	{ .compatible = "semtech,sx1509q", .data = &sx1509q_device_data },
 	{},
-- 
2.1.4

^ permalink raw reply related

* [PATCH 2/3] pinctrl: sx150x: sort chips by part number
From: Peter Rosin @ 2016-11-24 20:45 UTC (permalink / raw)
  To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: Peter Rosin, Linus Walleij, Rob Herring, Mark Rutland,
	Andrey Smirnov, Neil Armstrong, linux-gpio-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480020320-28354-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>

Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
 .../devicetree/bindings/pinctrl/pinctrl-sx150x.txt |   6 +-
 drivers/pinctrl/pinctrl-sx150x.c                   | 142 ++++++++++-----------
 2 files changed, 74 insertions(+), 74 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
index 25b4ec80c759..83f8d5c449ba 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sx150x.txt
@@ -6,11 +6,11 @@ pin controller, GPIO, and interrupt bindings.
 
 Required properties:
 - compatible: should be one of :
+			"semtech,sx1502q",
+			"semtech,sx1503q",
 			"semtech,sx1506q",
 			"semtech,sx1508q",
-			"semtech,sx1509q",
-			"semtech,sx1502q",
-			"semtech,sx1503q".
+			"semtech,sx1509q".
 
 - reg: The I2C slave address for this device.
 
diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index a19c814843aa..97df9302e84b 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -148,71 +148,6 @@ static const struct pinctrl_pin_desc sx150x_16_pins[] = {
 	PINCTRL_PIN(16, "oscio"),
 };
 
-static const struct sx150x_device_data sx1508q_device_data = {
-	.model = SX150X_789,
-	.reg_pullup	= 0x03,
-	.reg_pulldn	= 0x04,
-	.reg_dir	= 0x07,
-	.reg_data	= 0x08,
-	.reg_irq_mask	= 0x09,
-	.reg_irq_src	= 0x0c,
-	.reg_sense	= 0x0a,
-	.pri.x789 = {
-		.reg_drain	= 0x05,
-		.reg_polarity	= 0x06,
-		.reg_clock	= 0x0f,
-		.reg_misc	= 0x10,
-		.reg_reset	= 0x7d,
-	},
-	.ngpios = 8,
-	.pins = sx150x_8_pins,
-	.npins = ARRAY_SIZE(sx150x_8_pins),
-};
-
-static const struct sx150x_device_data sx1509q_device_data = {
-	.model = SX150X_789,
-	.reg_pullup	= 0x06,
-	.reg_pulldn	= 0x08,
-	.reg_dir	= 0x0e,
-	.reg_data	= 0x10,
-	.reg_irq_mask	= 0x12,
-	.reg_irq_src	= 0x18,
-	.reg_sense	= 0x14,
-	.pri.x789 = {
-		.reg_drain	= 0x0a,
-		.reg_polarity	= 0x0c,
-		.reg_clock	= 0x1e,
-		.reg_misc	= 0x1f,
-		.reg_reset	= 0x7d,
-	},
-	.ngpios	= 16,
-	.pins = sx150x_16_pins,
-	.npins = ARRAY_SIZE(sx150x_16_pins),
-};
-
-static const struct sx150x_device_data sx1506q_device_data = {
-	.model = SX150X_456,
-	.reg_pullup	= 0x04,
-	.reg_pulldn	= 0x06,
-	.reg_dir	= 0x02,
-	.reg_data	= 0x00,
-	.reg_irq_mask	= 0x08,
-	.reg_irq_src	= 0x0e,
-	.reg_sense	= 0x0a,
-	.pri.x456 = {
-		.reg_pld_mode	= 0x20,
-		.reg_pld_table0	= 0x22,
-		.reg_pld_table1	= 0x24,
-		.reg_pld_table2	= 0x26,
-		.reg_pld_table3	= 0x28,
-		.reg_pld_table4	= 0x2a,
-		.reg_advance	= 0xad,
-	},
-	.ngpios	= 16,
-	.pins = sx150x_16_pins,
-	.npins = 16, /* oscio not available */
-};
-
 static const struct sx150x_device_data sx1502q_device_data = {
 	.model = SX150X_123,
 	.reg_pullup	= 0x02,
@@ -259,6 +194,71 @@ static const struct sx150x_device_data sx1503q_device_data = {
 	.npins  = 16, /* oscio not available */
 };
 
+static const struct sx150x_device_data sx1506q_device_data = {
+	.model = SX150X_456,
+	.reg_pullup	= 0x04,
+	.reg_pulldn	= 0x06,
+	.reg_dir	= 0x02,
+	.reg_data	= 0x00,
+	.reg_irq_mask	= 0x08,
+	.reg_irq_src	= 0x0e,
+	.reg_sense	= 0x0a,
+	.pri.x456 = {
+		.reg_pld_mode	= 0x20,
+		.reg_pld_table0	= 0x22,
+		.reg_pld_table1	= 0x24,
+		.reg_pld_table2	= 0x26,
+		.reg_pld_table3	= 0x28,
+		.reg_pld_table4	= 0x2a,
+		.reg_advance	= 0xad,
+	},
+	.ngpios	= 16,
+	.pins = sx150x_16_pins,
+	.npins = 16, /* oscio not available */
+};
+
+static const struct sx150x_device_data sx1508q_device_data = {
+	.model = SX150X_789,
+	.reg_pullup	= 0x03,
+	.reg_pulldn	= 0x04,
+	.reg_dir	= 0x07,
+	.reg_data	= 0x08,
+	.reg_irq_mask	= 0x09,
+	.reg_irq_src	= 0x0c,
+	.reg_sense	= 0x0a,
+	.pri.x789 = {
+		.reg_drain	= 0x05,
+		.reg_polarity	= 0x06,
+		.reg_clock	= 0x0f,
+		.reg_misc	= 0x10,
+		.reg_reset	= 0x7d,
+	},
+	.ngpios = 8,
+	.pins = sx150x_8_pins,
+	.npins = ARRAY_SIZE(sx150x_8_pins),
+};
+
+static const struct sx150x_device_data sx1509q_device_data = {
+	.model = SX150X_789,
+	.reg_pullup	= 0x06,
+	.reg_pulldn	= 0x08,
+	.reg_dir	= 0x0e,
+	.reg_data	= 0x10,
+	.reg_irq_mask	= 0x12,
+	.reg_irq_src	= 0x18,
+	.reg_sense	= 0x14,
+	.pri.x789 = {
+		.reg_drain	= 0x0a,
+		.reg_polarity	= 0x0c,
+		.reg_clock	= 0x1e,
+		.reg_misc	= 0x1f,
+		.reg_reset	= 0x7d,
+	},
+	.ngpios	= 16,
+	.pins = sx150x_16_pins,
+	.npins = ARRAY_SIZE(sx150x_16_pins),
+};
+
 static int sx150x_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
 {
 	return 0;
@@ -758,20 +758,20 @@ static const struct pinconf_ops sx150x_pinconf_ops = {
 };
 
 static const struct i2c_device_id sx150x_id[] = {
-	{"sx1508q", (kernel_ulong_t) &sx1508q_device_data },
-	{"sx1509q", (kernel_ulong_t) &sx1509q_device_data },
-	{"sx1506q", (kernel_ulong_t) &sx1506q_device_data },
 	{"sx1502q", (kernel_ulong_t) &sx1502q_device_data },
 	{"sx1503q", (kernel_ulong_t) &sx1503q_device_data },
+	{"sx1506q", (kernel_ulong_t) &sx1506q_device_data },
+	{"sx1508q", (kernel_ulong_t) &sx1508q_device_data },
+	{"sx1509q", (kernel_ulong_t) &sx1509q_device_data },
 	{}
 };
 
 static const struct of_device_id sx150x_of_match[] = {
-	{ .compatible = "semtech,sx1508q", .data = &sx1508q_device_data },
-	{ .compatible = "semtech,sx1509q", .data = &sx1509q_device_data },
-	{ .compatible = "semtech,sx1506q", .data = &sx1506q_device_data },
 	{ .compatible = "semtech,sx1502q", .data = &sx1502q_device_data },
 	{ .compatible = "semtech,sx1503q", .data = &sx1503q_device_data },
+	{ .compatible = "semtech,sx1506q", .data = &sx1506q_device_data },
+	{ .compatible = "semtech,sx1508q", .data = &sx1508q_device_data },
+	{ .compatible = "semtech,sx1509q", .data = &sx1509q_device_data },
 	{},
 };
 
-- 
2.1.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

* [PATCH 1/3] pinctrl: sx150x: use correct registers for reg_sense (sx1502 and sx1508)
From: Peter Rosin @ 2016-11-24 20:45 UTC (permalink / raw)
  To: linux-kernel
  Cc: Peter Rosin, Linus Walleij, Rob Herring, Mark Rutland,
	Andrey Smirnov, Neil Armstrong, linux-gpio, devicetree
In-Reply-To: <1480020320-28354-1-git-send-email-peda@axentia.se>

All other registers on these chips are 8-bit, but reg_sense is 16-bits
and therefore needs to be moved down one notch.
This was apparently overlooked in the conversion to regmap, which only
updated the register locations for the 16-bit chips.

Fixes: 6489677f86c3 ("pinctrl-sx150x: Replace sx150x_*_cfg by means of regmap API")
Signed-off-by: Peter Rosin <peda@axentia.se>
---
 drivers/pinctrl/pinctrl-sx150x.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-sx150x.c b/drivers/pinctrl/pinctrl-sx150x.c
index f9e559e22537..a19c814843aa 100644
--- a/drivers/pinctrl/pinctrl-sx150x.c
+++ b/drivers/pinctrl/pinctrl-sx150x.c
@@ -156,7 +156,7 @@ static const struct sx150x_device_data sx1508q_device_data = {
 	.reg_data	= 0x08,
 	.reg_irq_mask	= 0x09,
 	.reg_irq_src	= 0x0c,
-	.reg_sense	= 0x0b,
+	.reg_sense	= 0x0a,
 	.pri.x789 = {
 		.reg_drain	= 0x05,
 		.reg_polarity	= 0x06,
@@ -221,7 +221,7 @@ static const struct sx150x_device_data sx1502q_device_data = {
 	.reg_data	= 0x00,
 	.reg_irq_mask	= 0x05,
 	.reg_irq_src	= 0x08,
-	.reg_sense	= 0x07,
+	.reg_sense	= 0x06,
 	.pri.x123 = {
 		.reg_pld_mode	= 0x10,
 		.reg_pld_table0	= 0x11,
-- 
2.1.4

^ permalink raw reply related

* [PATCH 0/3] sx150x update - bugfix, cleanup, last 4 chips
From: Peter Rosin @ 2016-11-24 20:45 UTC (permalink / raw)
  To: linux-kernel
  Cc: Peter Rosin, Linus Walleij, Rob Herring, Mark Rutland,
	Andrey Smirnov, Neil Armstrong, linux-gpio, devicetree

Hi!

Yet another sx150x update, only the first is critical.

Cheers,
Peter

Peter Rosin (3):
  pinctrl: sx150x: use correct registers for reg_sense (sx1502 and
    sx1508)
  pinctrl: sx150x: sort chips by part number
  pinctrl: sx150x: add support for sx1501, sx1504, sx1505 and sx1507

 .../devicetree/bindings/pinctrl/pinctrl-sx150x.txt |  14 +-
 drivers/pinctrl/pinctrl-sx150x.c                   | 206 +++++++++++++++------
 2 files changed, 161 insertions(+), 59 deletions(-)

-- 
2.1.4

^ permalink raw reply

* Re: [RFC PATCH 2/5] dmaengine: allow sun6i-dma for more SoCs
From: Maxime Ripard @ 2016-11-24 20:44 UTC (permalink / raw)
  To: Andre Przywara
  Cc: Chen-Yu Tsai, Icenowy Zheng, linux-sunxi, linux-arm-kernel,
	Mark Rutland, Rob Herring, devicetree
In-Reply-To: <606230fd-37f6-e1ed-adc3-72f606fa944c-5wv7dgnIgG8@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

On Thu, Nov 24, 2016 at 11:15:42AM +0000, Andre Przywara wrote:
> On 24/11/16 10:55, Maxime Ripard wrote:
> > On Thu, Nov 24, 2016 at 05:30:45PM +0800, Chen-Yu Tsai wrote:
> >> On Thu, Nov 24, 2016 at 5:16 PM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> >>> Hi,
> >>>
> >>> On 24/11/16 04:16, Chen-Yu Tsai wrote:
> >>>> Hi,
> >>>>
> >>>> On Thu, Nov 24, 2016 at 9:17 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> >>>>> The sun6i DMA driver is used in the Allwinner A64 and H5 SoC, which
> >>>>> have arm64 capable cores. Add the generic sunxi config symbol to allow
> >>>>> the driver to be selected by arm64 Kconfigs, which don't feature
> >>>>> SoC specific MACH_xxxx configs.
> >>>>>
> >>>>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> >>>>> ---
> >>>>>  drivers/dma/Kconfig | 2 +-
> >>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> >>>>> index af63a6b..003c284 100644
> >>>>> --- a/drivers/dma/Kconfig
> >>>>> +++ b/drivers/dma/Kconfig
> >>>>> @@ -157,7 +157,7 @@ config DMA_SUN4I
> >>>>>
> >>>>>  config DMA_SUN6I
> >>>>>         tristate "Allwinner A31 SoCs DMA support"
> >>>>> -       depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST
> >>>>> +       depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST || ARCH_SUNXI
> >>>>
> >>>> AFAIK ARCH_SUNXI encompasses/supersedes MACH_SUN*I.
> >>>> (And I don't have to add MACH_SUN9I later :) )
> >>>
> >>> Sure, admittedly it was just a quick hack to get things going.
> >>> Actually I don't know why we had a *depend* on those MACH_s before. I
> >>> think technically it does not depend on a certain SoC (having the
> >>> COMPILE_TEST in there hints on that). So what about:
> >>
> >> It was really because this DMA engine only comes with the later
> >> SoCs. We have dma-sun4i for the older one.
> > 
> > Indeed.
> > 
> >> But yes, there's no reason why you can't build it for the earlier
> >> SoC. It just doesn't get used.
> > 
> > I'm still in favor of keeping the depends on. There's no point of
> > compiling something we know have zero chance of running.
> > 
> > (But that would be (ARCH_SUNXI && ARM64))
> 
> I am OK with that, just wondering if there is a definition of what
> "depends" really means. My impression what that it's a about code
> dependencies (requires a certain subsystem, for instance), not really if
> it's useful in a particular configuration.

My understanding is that it's a hard dependency that prevents
configuration that make no sense, ie being able to compile a driver
that has no chance of being useful in the system, or a driver missing
its framework of choice.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH v3 2/6] iio: adc: Add support for STM32 ADC core
From: Jonathan Cameron @ 2016-11-24 20:40 UTC (permalink / raw)
  To: Fabrice Gasnier, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
  Cc: linux-I+IVW8TIWO2tmTQ+vhA3Yw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	mark.rutland-5wv7dgnIgG8, mcoquelin.stm32-Re5JQEeQqe8AvxtiuMwx3w,
	alexandre.torgue-qxv4g6HH51o, lars-Qo5EllUWu/uELgA04lAiVw,
	knaack.h-Mmb7MZpHnFY, pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <3775e118-ec41-8b09-6be3-6bde579f046d-qxv4g6HH51o@public.gmane.org>

On 21/11/16 08:54, Fabrice Gasnier wrote:
> On 11/19/2016 01:17 PM, Jonathan Cameron wrote:
>> On 15/11/16 15:30, Fabrice Gasnier wrote:
>>> Add core driver for STMicroelectronics STM32 ADC (Analog to Digital
>>> Converter). STM32 ADC can be composed of up to 3 ADCs with shared
>>> resources like clock prescaler, common interrupt line and analog
>>> reference voltage.
>>> This core driver basically manages shared resources.
>>>
>>> Signed-off-by: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>
>> There is nothing in here that demands selecting a fixed regulator.
>> I've also switched the select regulator over to depends on inline with
>> other drivers in IIO that have a hard dependency on regulators.
>> Other than that which showed up during build tests, looks good to me.
>> Shout if I've broken anything with this change.
> 
> Hi Jonathan, All,
> 
> First many thanks.
> This is not a big deal. Only thing is: I think patch 4 of this series (on stm32_defconfig) need to be updated
> to accommodate this change. E.g. :
> +CONFIG_REGULATOR=y
> +CONFIG_REGULATOR_FIXED_VOLTAGE=y
> 
> Shall I send a new version of this series (all patches), including your changes, with updated defconfig as well ?
> Or only updated patch on defconfig is enough ?
Just update those that haven't already been applied.

Thanks,

Jonathan
> 
> Please advise,
> Fabrice
>>
>> Applied to the togreg branch of iio.git and pushed out as testing for
>> the autobuilders to play with it.
>>
>> Thanks,
>>
>> Jonathan
>>> ---
>>>   drivers/iio/adc/Kconfig          |  13 ++
>>>   drivers/iio/adc/Makefile         |   1 +
>>>   drivers/iio/adc/stm32-adc-core.c | 303 +++++++++++++++++++++++++++++++++++++++
>>>   drivers/iio/adc/stm32-adc-core.h |  52 +++++++
>>>   4 files changed, 369 insertions(+)
>>>   create mode 100644 drivers/iio/adc/stm32-adc-core.c
>>>   create mode 100644 drivers/iio/adc/stm32-adc-core.h
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 7edcf32..ff30239 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -419,6 +419,19 @@ config ROCKCHIP_SARADC
>>>         To compile this driver as a module, choose M here: the
>>>         module will be called rockchip_saradc.
>>>   +config STM32_ADC_CORE
>>> +    tristate "STMicroelectronics STM32 adc core"
>>> +    depends on ARCH_STM32 || COMPILE_TEST
>>> +    depends on OF
>>> +    select REGULATOR
>>> +    select REGULATOR_FIXED_VOLTAGE
>>> +    help
>>> +      Select this option to enable the core driver for STMicroelectronics
>>> +      STM32 analog-to-digital converter (ADC).
>>> +
>>> +      This driver can also be built as a module.  If so, the module
>>> +      will be called stm32-adc-core.
>>> +
>>>   config STX104
>>>       tristate "Apex Embedded Systems STX104 driver"
>>>       depends on X86 && ISA_BUS_API
>>> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
>>> index 7a40c04..a1e8f44 100644
>>> --- a/drivers/iio/adc/Makefile
>>> +++ b/drivers/iio/adc/Makefile
>>> @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>>>   obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>>>   obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>>>   obj-$(CONFIG_STX104) += stx104.o
>>> +obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o
>>>   obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>>>   obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>>>   obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
>>> diff --git a/drivers/iio/adc/stm32-adc-core.c b/drivers/iio/adc/stm32-adc-core.c
>>> new file mode 100644
>>> index 0000000..4214b0c
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/stm32-adc-core.c
>>> @@ -0,0 +1,303 @@
>>> +/*
>>> + * This file is part of STM32 ADC driver
>>> + *
>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>> + * Author: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>.
>>> + *
>>> + * Inspired from: fsl-imx25-tsadc
>>> + *
>>> + * License type: GPLv2
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License version 2 as published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>>> + * See the GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License along with
>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include <linux/clk.h>
>>> +#include <linux/interrupt.h>
>>> +#include <linux/irqchip/chained_irq.h>
>>> +#include <linux/irqdesc.h>
>>> +#include <linux/irqdomain.h>
>>> +#include <linux/module.h>
>>> +#include <linux/of_device.h>
>>> +#include <linux/regulator/consumer.h>
>>> +#include <linux/slab.h>
>>> +
>>> +#include "stm32-adc-core.h"
>>> +
>>> +/* STM32F4 - common registers for all ADC instances: 1, 2 & 3 */
>>> +#define STM32F4_ADC_CSR            (STM32_ADCX_COMN_OFFSET + 0x00)
>>> +#define STM32F4_ADC_CCR            (STM32_ADCX_COMN_OFFSET + 0x04)
>>> +
>>> +/* STM32F4_ADC_CSR - bit fields */
>>> +#define STM32F4_EOC3            BIT(17)
>>> +#define STM32F4_EOC2            BIT(9)
>>> +#define STM32F4_EOC1            BIT(1)
>>> +
>>> +/* STM32F4_ADC_CCR - bit fields */
>>> +#define STM32F4_ADC_ADCPRE_SHIFT    16
>>> +#define STM32F4_ADC_ADCPRE_MASK        GENMASK(17, 16)
>>> +
>>> +/* STM32 F4 maximum analog clock rate (from datasheet) */
>>> +#define STM32F4_ADC_MAX_CLK_RATE    36000000
>>> +
>>> +/**
>>> + * struct stm32_adc_priv - stm32 ADC core private data
>>> + * @irq:        irq for ADC block
>>> + * @domain:        irq domain reference
>>> + * @aclk:        clock reference for the analog circuitry
>>> + * @vref:        regulator reference
>>> + * @common:        common data for all ADC instances
>>> + */
>>> +struct stm32_adc_priv {
>>> +    int                irq;
>>> +    struct irq_domain        *domain;
>>> +    struct clk            *aclk;
>>> +    struct regulator        *vref;
>>> +    struct stm32_adc_common        common;
>>> +};
>>> +
>>> +static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
>>> +{
>>> +    return container_of(com, struct stm32_adc_priv, common);
>>> +}
>>> +
>>> +/* STM32F4 ADC internal common clock prescaler division ratios */
>>> +static int stm32f4_pclk_div[] = {2, 4, 6, 8};
>>> +
>>> +/**
>>> + * stm32f4_adc_clk_sel() - Select stm32f4 ADC common clock prescaler
>>> + * @priv: stm32 ADC core private data
>>> + * Select clock prescaler used for analog conversions, before using ADC.
>>> + */
>>> +static int stm32f4_adc_clk_sel(struct platform_device *pdev,
>>> +                   struct stm32_adc_priv *priv)
>>> +{
>>> +    unsigned long rate;
>>> +    u32 val;
>>> +    int i;
>>> +
>>> +    rate = clk_get_rate(priv->aclk);
>>> +    for (i = 0; i < ARRAY_SIZE(stm32f4_pclk_div); i++) {
>>> +        if ((rate / stm32f4_pclk_div[i]) <= STM32F4_ADC_MAX_CLK_RATE)
>>> +            break;
>>> +    }
>>> +    if (i >= ARRAY_SIZE(stm32f4_pclk_div))
>>> +        return -EINVAL;
>>> +
>>> +    val = readl_relaxed(priv->common.base + STM32F4_ADC_CCR);
>>> +    val &= ~STM32F4_ADC_ADCPRE_MASK;
>>> +    val |= i << STM32F4_ADC_ADCPRE_SHIFT;
>>> +    writel_relaxed(val, priv->common.base + STM32F4_ADC_CCR);
>>> +
>>> +    dev_dbg(&pdev->dev, "Using analog clock source at %ld kHz\n",
>>> +        rate / (stm32f4_pclk_div[i] * 1000));
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +/* ADC common interrupt for all instances */
>>> +static void stm32_adc_irq_handler(struct irq_desc *desc)
>>> +{
>>> +    struct stm32_adc_priv *priv = irq_desc_get_handler_data(desc);
>>> +    struct irq_chip *chip = irq_desc_get_chip(desc);
>>> +    u32 status;
>>> +
>>> +    chained_irq_enter(chip, desc);
>>> +    status = readl_relaxed(priv->common.base + STM32F4_ADC_CSR);
>>> +
>>> +    if (status & STM32F4_EOC1)
>>> +        generic_handle_irq(irq_find_mapping(priv->domain, 0));
>>> +
>>> +    if (status & STM32F4_EOC2)
>>> +        generic_handle_irq(irq_find_mapping(priv->domain, 1));
>>> +
>>> +    if (status & STM32F4_EOC3)
>>> +        generic_handle_irq(irq_find_mapping(priv->domain, 2));
>>> +
>>> +    chained_irq_exit(chip, desc);
>>> +};
>>> +
>>> +static int stm32_adc_domain_map(struct irq_domain *d, unsigned int irq,
>>> +                irq_hw_number_t hwirq)
>>> +{
>>> +    irq_set_chip_data(irq, d->host_data);
>>> +    irq_set_chip_and_handler(irq, &dummy_irq_chip, handle_level_irq);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static void stm32_adc_domain_unmap(struct irq_domain *d, unsigned int irq)
>>> +{
>>> +    irq_set_chip_and_handler(irq, NULL, NULL);
>>> +    irq_set_chip_data(irq, NULL);
>>> +}
>>> +
>>> +static const struct irq_domain_ops stm32_adc_domain_ops = {
>>> +    .map = stm32_adc_domain_map,
>>> +    .unmap  = stm32_adc_domain_unmap,
>>> +    .xlate = irq_domain_xlate_onecell,
>>> +};
>>> +
>>> +static int stm32_adc_irq_probe(struct platform_device *pdev,
>>> +                   struct stm32_adc_priv *priv)
>>> +{
>>> +    struct device_node *np = pdev->dev.of_node;
>>> +
>>> +    priv->irq = platform_get_irq(pdev, 0);
>>> +    if (priv->irq < 0) {
>>> +        dev_err(&pdev->dev, "failed to get irq\n");
>>> +        return priv->irq;
>>> +    }
>>> +
>>> +    priv->domain = irq_domain_add_simple(np, STM32_ADC_MAX_ADCS, 0,
>>> +                         &stm32_adc_domain_ops,
>>> +                         priv);
>>> +    if (!priv->domain) {
>>> +        dev_err(&pdev->dev, "Failed to add irq domain\n");
>>> +        return -ENOMEM;
>>> +    }
>>> +
>>> +    irq_set_chained_handler(priv->irq, stm32_adc_irq_handler);
>>> +    irq_set_handler_data(priv->irq, priv);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static void stm32_adc_irq_remove(struct platform_device *pdev,
>>> +                 struct stm32_adc_priv *priv)
>>> +{
>>> +    int hwirq;
>>> +
>>> +    for (hwirq = 0; hwirq < STM32_ADC_MAX_ADCS; hwirq++)
>>> +        irq_dispose_mapping(irq_find_mapping(priv->domain, hwirq));
>>> +    irq_domain_remove(priv->domain);
>>> +    irq_set_chained_handler(priv->irq, NULL);
>>> +}
>>> +
>>> +static int stm32_adc_probe(struct platform_device *pdev)
>>> +{
>>> +    struct stm32_adc_priv *priv;
>>> +    struct device_node *np = pdev->dev.of_node;
>>> +    struct resource *res;
>>> +    int ret;
>>> +
>>> +    if (!pdev->dev.of_node)
>>> +        return -ENODEV;
>>> +
>>> +    priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>>> +    if (!priv)
>>> +        return -ENOMEM;
>>> +
>>> +    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +    priv->common.base = devm_ioremap_resource(&pdev->dev, res);
>>> +    if (IS_ERR(priv->common.base))
>>> +        return PTR_ERR(priv->common.base);
>>> +
>>> +    priv->vref = devm_regulator_get(&pdev->dev, "vref");
>>> +    if (IS_ERR(priv->vref)) {
>>> +        ret = PTR_ERR(priv->vref);
>>> +        dev_err(&pdev->dev, "vref get failed, %d\n", ret);
>>> +        return ret;
>>> +    }
>>> +
>>> +    ret = regulator_enable(priv->vref);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "vref enable failed\n");
>>> +        return ret;
>>> +    }
>>> +
>>> +    ret = regulator_get_voltage(priv->vref);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "vref get voltage failed, %d\n", ret);
>>> +        goto err_regulator_disable;
>>> +    }
>>> +    priv->common.vref_mv = ret / 1000;
>>> +    dev_dbg(&pdev->dev, "vref+=%dmV\n", priv->common.vref_mv);
>>> +
>>> +    priv->aclk = devm_clk_get(&pdev->dev, "adc");
>>> +    if (IS_ERR(priv->aclk)) {
>>> +        ret = PTR_ERR(priv->aclk);
>>> +        dev_err(&pdev->dev, "Can't get 'adc' clock\n");
>>> +        goto err_regulator_disable;
>>> +    }
>>> +
>>> +    ret = clk_prepare_enable(priv->aclk);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "adc clk enable failed\n");
>>> +        goto err_regulator_disable;
>>> +    }
>>> +
>>> +    ret = stm32f4_adc_clk_sel(pdev, priv);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "adc clk selection failed\n");
>>> +        goto err_clk_disable;
>>> +    }
>>> +
>>> +    ret = stm32_adc_irq_probe(pdev, priv);
>>> +    if (ret < 0)
>>> +        goto err_clk_disable;
>>> +
>>> +    platform_set_drvdata(pdev, &priv->common);
>>> +
>>> +    ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
>>> +    if (ret < 0) {
>>> +        dev_err(&pdev->dev, "failed to populate DT children\n");
>>> +        goto err_irq_remove;
>>> +    }
>>> +
>>> +    return 0;
>>> +
>>> +err_irq_remove:
>>> +    stm32_adc_irq_remove(pdev, priv);
>>> +
>>> +err_clk_disable:
>>> +    clk_disable_unprepare(priv->aclk);
>>> +
>>> +err_regulator_disable:
>>> +    regulator_disable(priv->vref);
>>> +
>>> +    return ret;
>>> +}
>>> +
>>> +static int stm32_adc_remove(struct platform_device *pdev)
>>> +{
>>> +    struct stm32_adc_common *common = platform_get_drvdata(pdev);
>>> +    struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
>>> +
>>> +    of_platform_depopulate(&pdev->dev);
>>> +    stm32_adc_irq_remove(pdev, priv);
>>> +    clk_disable_unprepare(priv->aclk);
>>> +    regulator_disable(priv->vref);
>>> +
>>> +    return 0;
>>> +}
>>> +
>>> +static const struct of_device_id stm32_adc_of_match[] = {
>>> +    { .compatible = "st,stm32f4-adc-core" },
>>> +    {},
>>> +};
>>> +MODULE_DEVICE_TABLE(of, stm32_adc_of_match);
>>> +
>>> +static struct platform_driver stm32_adc_driver = {
>>> +    .probe = stm32_adc_probe,
>>> +    .remove = stm32_adc_remove,
>>> +    .driver = {
>>> +        .name = "stm32-adc-core",
>>> +        .of_match_table = stm32_adc_of_match,
>>> +    },
>>> +};
>>> +module_platform_driver(stm32_adc_driver);
>>> +
>>> +MODULE_AUTHOR("Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>");
>>> +MODULE_DESCRIPTION("STMicroelectronics STM32 ADC core driver");
>>> +MODULE_LICENSE("GPL v2");
>>> +MODULE_ALIAS("platform:stm32-adc-core");
>>> diff --git a/drivers/iio/adc/stm32-adc-core.h b/drivers/iio/adc/stm32-adc-core.h
>>> new file mode 100644
>>> index 0000000..081fa5f
>>> --- /dev/null
>>> +++ b/drivers/iio/adc/stm32-adc-core.h
>>> @@ -0,0 +1,52 @@
>>> +/*
>>> + * This file is part of STM32 ADC driver
>>> + *
>>> + * Copyright (C) 2016, STMicroelectronics - All Rights Reserved
>>> + * Author: Fabrice Gasnier <fabrice.gasnier-qxv4g6HH51o@public.gmane.org>.
>>> + *
>>> + * License type: GPLv2
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify it
>>> + * under the terms of the GNU General Public License version 2 as published by
>>> + * the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful, but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>>> + * or FITNESS FOR A PARTICULAR PURPOSE.
>>> + * See the GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License along with
>>> + * this program. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#ifndef __STM32_ADC_H
>>> +#define __STM32_ADC_H
>>> +
>>> +/*
>>> + * STM32 - ADC global register map
>>> + * ________________________________________________________
>>> + * | Offset |                 Register                    |
>>> + * --------------------------------------------------------
>>> + * | 0x000  |                Master ADC1                  |
>>> + * --------------------------------------------------------
>>> + * | 0x100  |                Slave ADC2                   |
>>> + * --------------------------------------------------------
>>> + * | 0x200  |                Slave ADC3                   |
>>> + * --------------------------------------------------------
>>> + * | 0x300  |         Master & Slave common regs          |
>>> + * --------------------------------------------------------
>>> + */
>>> +#define STM32_ADC_MAX_ADCS        3
>>> +#define STM32_ADCX_COMN_OFFSET        0x300
>>> +
>>> +/**
>>> + * struct stm32_adc_common - stm32 ADC driver common data (for all instances)
>>> + * @base:        control registers base cpu addr
>>> + * @vref_mv:        vref voltage (mv)
>>> + */
>>> +struct stm32_adc_common {
>>> +    void __iomem            *base;
>>> +    int                vref_mv;
>>> +};
>>> +
>>> +#endif
>>>
> 
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-iio" 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] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-24 20:08 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: mark.rutland, devicetree, linux, linux-kernel, wens, robh+dt,
	linux-arm-kernel
In-Reply-To: <20161123181610.cae67ad53f5f69246d341b30@bidouilliste.com>

On Wed, 23 Nov 2016 18:16:10 +0100
Emmanuel Vadot <manu@bidouilliste.com> wrote:

> On Wed, 23 Nov 2016 09:03:50 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> 
> > On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > > and uart pins along power in one connector and are found on most,
> > > if not all, Olimex boards.
> > > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > > those two connectors.
> > > 
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > 
> > Fixed the indentation of the spi pinctrl cells, and applied.
> > 
> > Please note that I'm note planning to send any new pull request, so
> > this will likely end up in 4.11.
> > 
> > Thanks!
> > Maxime
> > 
> > -- 
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
> 
>  Sorry about the indentation, I'll be more carefull next time.
> 
>  Thank you.
> 
> -- 
> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
> 

 Hi Maxime,

 Re-reading the patch I've seen that I've not enabled the SPI nodes, I
guess it's easier if you revert my patch and that I send a new one ?

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

^ permalink raw reply

* Re: [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-24 20:05 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: mark.rutland, devicetree, linux, linux-kernel, wens, robh+dt,
	linux-arm-kernel
In-Reply-To: <20161124195517.qrq7briu3pwjnp4n@lukather>

On Thu, 24 Nov 2016 20:55:17 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:

> On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > others three only have 1.
> > Add the num-cs property to each node.
> > 
> > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> 
> I don't think we have any code that uses it at the moment. What is the
> rationale behind this patch?
> 
> Thanks!
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

 Hi Maxime,

 If num-cs isn't present nothing prevent to start a transfer with a
non-valid CS pin, resulting in an error.
 num-cs are default property especially made for this and a SPI driver
should try to get the property at probe/attach time.

 Cheers,

-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

^ permalink raw reply

* Re: [PATCH] ARM: dts: sun6i: hummingbird: Enable USB OTG
From: Maxime Ripard @ 2016-11-24 20:04 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161124112908.4796-1-wens-jdAy2FN1RRM@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

On Thu, Nov 24, 2016 at 07:29:08PM +0800, Chen-Yu Tsai wrote:
> The A31 Hummingbird has a mini USB OTG port, and uses GPIO pins from the
> SoC for ID pin and VBUS detection and VBUS control. The PMIC can also do
> VBUS detection and control.
> 
> Here we prefer to use the PMIC's DRIVEVBUS function to control VBUS for
> USB OTG, as that is the hardware default.
> 
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH 0/2] ARM: dts: sun6i: Disable display pipeline by default
From: Maxime Ripard @ 2016-11-24 20:00 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161124064339.12615-1-wens-jdAy2FN1RRM@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Thu, Nov 24, 2016 at 02:43:37PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> While we now support the internal display pipeline found on sun6i, it
> is possible that we are unable to enable the display for some boards,
> due to a lack of drivers for the panels or bridges found on them. If
> the display pipeline is enabled, the driver will try to enable, and
> possibly screw up the simple framebuffer U-boot had configured.
> 
> This series disables the display pipeline by default, and re-enables
> it for the A31 Hummingbird, which already had its display pipeline
> enabled.
> 
> The series can go in after 4.10-rc1, as a fix, but should not be delayed
> till the next release.

Applied both, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Maxime Ripard @ 2016-11-24 19:55 UTC (permalink / raw)
  To: Emmanuel Vadot
  Cc: mark.rutland, devicetree, linux, linux-kernel, wens, robh+dt,
	linux-arm-kernel
In-Reply-To: <20161122170616.29557-1-manu@bidouilliste.com>


[-- Attachment #1.1: Type: text/plain, Size: 497 bytes --]

On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> others three only have 1.
> Add the num-cs property to each node.
> 
> Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>

I don't think we have any code that uses it at the moment. What is the
rationale behind this patch?

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC PATCH 2/2] arm64: dts: enable the MUSB controller of Pine64 in host-only mode
From: Maxime Ripard @ 2016-11-24 19:53 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Chen-Yu Tsai, Hans de Goede,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161122165902.62543-2-icenowy-ymACFijhrKM@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

On Wed, Nov 23, 2016 at 12:59:02AM +0800, Icenowy Zheng wrote:
> A64 has a MUSB controller wired to the USB PHY 0, which is connected
> to the upper USB Type-A port of Pine64.
> 
> As the port is a Type-A female port, enable it in host-only mode in the
> device tree, which makes devices with USB Type-A male port can work on
> this port (which is originally designed by Pine64 team).
> 
> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>

Applied both, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Florian Fainelli @ 2016-11-24 18:55 UTC (permalink / raw)
  To: Martin Blumenstingl, Jerome Brunet, Sebastian Frias
  Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
	davem-fT/PcQaiUtIeIZ0/mPfg9Q, khilman-rdvid1DuHRBWk0Htik3J/w,
	mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	alexandre.torgue-qxv4g6HH51o, peppe.cavallaro-qxv4g6HH51o,
	carlo-KA+7E9HrN00dnm+yROfE0A, Mans Rullgard, Andrew Lunn
In-Reply-To: <CAFBinCB7sXjXor++W+PW0-j_VxATRzhexjqHgXj2jD10tBpZFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Le 24/11/2016 à 09:05, Martin Blumenstingl a écrit :
> On Thu, Nov 24, 2016 at 4:56 PM, Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> wrote:
>> On Thu, 2016-11-24 at 15:34 +0100, Martin Blumenstingl wrote:
>>> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
>>> cycle TX clock delay. This seems to work fine for many boards (for
>>> example Odroid-C2 or Amlogic's reference boards) but there are some
>>> others where TX traffic is simply broken.
>>> There are probably multiple reasons why it's working on some boards
>>> while it's broken on others:
>>> - some of Amlogic's reference boards are using a Micrel PHY
>>> - hardware circuit design
>>> - maybe more...
>>>
>>> This raises a question though:
>>> Which device is supposed to enable the TX delay when both MAC and PHY
>>> support it? And should we implement it for each PHY / MAC separately
>>> or should we think about a more generic solution (currently it's not
>>> possible to disable the TX delay generated by the RTL8211F PHY via
>>> devicetree when using phy-mode "rgmii")?
>>
>> Actually you can skip the part which activate the Tx-delay on the phy
>> by setting "phy-mode = "rgmii-id" instead of "rgmii"
>>
>> phy->interface will no longer be PHY_INTERFACE_MODE_RGMII
>> but PHY_INTERFACE_MODE_RGMII_ID.
> unfortunately this is not true for RTL8211F (I did my previous tests
> with the same expectation in mind)!
> the code seems to suggest that TX-delay is disabled whenever mode !=
> PHY_INTERFACE_MODE_RGMII.
> BUT: on my device RTL8211F_TX_DELAY is set even before
> "phy_write(phydev, 0x11, reg);"!

(Adding Sebastian (and Mans, and Andrew) since he raised the same
question a while ago. I think I now understand a bit better what
Sebastian was after a couple of weeks ago)

> 
> Based on what I found it seems that rgmii-id, rgmii-txid and
> rgmii-rxid are supposed to be handled by the PHY.

Correct, the meaning of PHY_INTERFACE_MODE should be from the
perspective of the PHY device:

- PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
- PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)

> That would mean that we have two problems here:
> 1) drivers/net/phy/realtek.c:rtl8211f_config_init should check for
> PHY_INTERFACE_MODE_RGMII_ID or PHY_INTERFACE_MODE_RGMII_TXID and
> enable the TX-delay in that case - otherwise explicitly disable it

Agreed.

> 2) dwmac-meson8b.c should only use the configured TX-delay for
> PHY_INTERFACE_MODE_RGMII
> @Florian: could you please share your thoughts on this (who handles
> the TX delay in which case)?

This also seems reasonable to do, provided that the PHY is also properly
configured not to add delays in both directions, and therefore assumes
that the MAC does it.

We have a fairly large problem with how RGMII delays are done in PHYLIB
and Ethernet MAC drivers (or just in general), where we can't really
intersect properly what a PHY is supporting (in terms of internal
delays), and what the MAC supports either. One possible approach could
be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
support (ideally, even with normalized nanosecond delay values), and
then intersect that with the requested phy_interface_t during
phy_{attach,connect} time, and feed this back to the MAC with a special
error code/callback, so we could gracefully try to choose another
PHY_INTERFACE_MODE_* value that the MAC supports....

A larger problem is that a number of drivers have been deployed, and
Device Trees, possibly with the meaning of "phy-mode" and
"phy-connection-type" being from the MAC perspective, and not the PHY
perspective *sigh*, good luck auditing those.

So from there, here is possibly what we could do

- submit a series of patches that update the PHYLIB documentation (there
are other things missing here) and make it clear from which entity (PHY
or MAC) does the delay apply to, document the "intersection" problem here

- have you document the configured behavior for dwmac-meson8b that we
just discussed here in v2 of this patch series

Sorry for the long post, here is a virtual potato: 0
-- 
Florian
--
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 mmc/next] mmc: sh_mmcif: Document r8a73a4, r8a7779 and sh73a0 DT bindings
From: Sergei Shtylyov @ 2016-11-24 18:50 UTC (permalink / raw)
  To: Simon Horman, Ulf Hansson
  Cc: linux-mmc, devicetree, Magnus Damm, linux-renesas-soc
In-Reply-To: <1480011435-22125-1-git-send-email-horms+renesas@verge.net.au>

Hello.

On 11/24/2016 09:17 PM, Simon Horman wrote:

> Simply document new compatibility strings as the driver is already
> activated using a fallback compatibility string.
>
> These compat strings are in keeping with those for all other
> Renesas ARM based SoCs with sh_mmcif enabled in mainline.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> I plan to follow-up with patches to use these new compat strings
> to bring the DT files of the SoCs in question in-line with those
> for other Renesas ARM based SoCs with sh_mmcif enabled in mainline.
> ---
>  Documentation/devicetree/bindings/mmc/renesas,mmcif.txt | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> index ff611fa66871..e4ba92aa035e 100644
> --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> @@ -8,11 +8,14 @@ Required properties:
>
>  - compatible: should be "renesas,mmcif-<soctype>", "renesas,sh-mmcif" as a
>    fallback. Examples with <soctype> are:
> +	- "renesas,mmcif-r8a73a4" for the MMCIF found in r8a73a4 SoCs
>  	- "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> +	- "renesas,mmcif-r8a7778" for the MMCIF found in r8a7778 SoCs

    7779 in the subject, 7778 here.

[...]

MBR, Sergei


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox