Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Chen-Yu Tsai @ 2016-12-19  8:53 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Icenowy Zheng, Chen-Yu Tsai, Hans de Goede, Quentin Schulz,
	devicetree, linux-arm-kernel, linux-kernel, linux-clk,
	linux-sunxi
In-Reply-To: <20161219084652.kiqdkiewu5tujlyd@lukather>

On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>> An operating point table is needed for the cpu frequency adjusting to
>> work.
>>
>> The operating point table is converted from the common value in
>> extracted script.fex from many A33 board/tablets.
>>
>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> ---
>> Changes since v1:
>> - Fix format problem (blank lines).
>> - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>
>> This patch depends on the following patchset:
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>
>> It's the v2 of the [PATCH 4/6] in this patchset.
>>
>> I think this operating point table may also apply to A23, as there's no
>> difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>
>> But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>> now.
>>
>> Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>> then test this operating points table?
>>
>> If it's necessary, you can send out the CCU fixes and add one more patch that
>> moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>
>>  arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>> index 504996cbee29..0f5b2af72981 100644
>> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>> @@ -46,7 +46,42 @@
>>  #include <dt-bindings/dma/sun4i-a10.h>
>>
>>  / {
>> +     cpu0_opp_table: opp_table0 {
>> +             compatible = "operating-points-v2";
>> +             opp-shared;
>> +
>> +             opp@648000000 {
>> +                     opp-hz = /bits/ 64 <648000000>;
>> +                     opp-microvolt = <1040000>;
>> +                     clock-latency-ns = <244144>; /* 8 32k periods */
>> +             };
>> +
>> +             opp@816000000 {
>> +                     opp-hz = /bits/ 64 <816000000>;
>> +                     opp-microvolt = <1100000>;
>> +                     clock-latency-ns = <244144>; /* 8 32k periods */
>> +             };
>> +
>> +             opp@1008000000 {
>> +                     opp-hz = /bits/ 64 <1008000000>;
>> +                     opp-microvolt = <1200000>;
>> +                     clock-latency-ns = <244144>; /* 8 32k periods */
>> +             };
>> +
>> +             opp@1200000000 {
>> +                     opp-hz = /bits/ 64 <1200000000>;
>> +                     opp-microvolt = <1320000>;
>> +                     clock-latency-ns = <244144>; /* 8 32k periods */
>> +             };
>> +     };
>> +
>>       cpus {
>> +             cpu0: cpu@0 {
>
> There's no need to duplicate the label here. I removed it and applied.

I think using the label to directly reference cpu0 would be better,
instead of duplicating the cpu@0 block.

ChenYu

^ permalink raw reply

* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Markus Reichl @ 2016-12-19  9:14 UTC (permalink / raw)
  To: Javier Martinez Canillas, Krzysztof Kozlowski, Doug Anderson
  Cc: Mark Rutland, devicetree@vger.kernel.org, linux-samsung-soc,
	Bartlomiej Zolnierkiewicz, Ben Gamari, linux-pm@vger.kernel.org,
	Russell King, Rob Herring, linux-kernel@vger.kernel.org,
	Kukjin Kim, Thomas Abraham, Alim, Arjun K V, Andreas Faerber,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <f4f0dd96-abf1-d1ba-86a6-99f216b5175b@osg.samsung.com>

Hi Javier,

Am 16.12.2016 um 17:22 schrieb Javier Martinez Canillas:
> Hello Markus,
> 
> On 12/16/2016 06:08 AM, Markus Reichl wrote:
>> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>>>   (unfortunately Inderpal's email is no longer working). ]
>>>>>
>>>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>>>> IOW if the problem exists it is already present in the mainline
>>>>> kernel.
>>>>
>>>> Interesting.  In the ChromeOS tree I see significantly higher voltages
>>>> needed...  Note that one might naively look at
>>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>>>
>>>> 1362500, /* L0  2100 */
>>>> 1312500, /* L1  2000 */
>>>>
>>>> ..but, amazingly enough those voltages aren't used at all.  Surprise!
>>>>
>>>> I believe that the above numbers are actually not used and the ASV
>>>> numbers are used instead.  See
>>>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>>>
>>>> { 2100000,
>>>> 1350000, 1350000, 1350000, 1350000, 1350000,
>>>> 1337500, 1325000, 1312500, 1300000, 1287500,
>>>> 1275000, 1262500, 1250000, 1237500 },
>>>>
>>>> I believe that interpretation there is: some bins of the CPU can run
>>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>>
>>> That is definitely the case. One could just look at vendors ASV table
>>> (for 1.9 GHz):
>>> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>>>                     1200000, 1187500, 1175000, 1162500, 1150000,
>>> 		             1137500, 1125000, 1112500, 1112500},
>>>
>>> The theoretical difference is up to 1.875V! From my experiments I saw
>>> BIN1 chips which should be the same... but some working on 1.2V, some on
>>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>>> does not mean that there aren't such...
>>>
>>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>>> running on a CPU from a nice bin?
>>
>> I've been running the proposed frequency/voltage combinations without any
>> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
>> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
>> The chips are poorly cooled, especially the XU4 and quickly step down.
>>
>>>
>>> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
>>> along with name of tested board. Because the "Tested on XU3" is not
>>> sufficient.
>>
>> If you point me to how to read these values out, I will publish them.
>>
> 
> You can use the exynos-chipid driver posted by Pankaj. Apply patches 1 and
> 2 from this series (http://www.spinics.net/lists/arm-kernel/msg548384.html)
> and then this diff to get the values of the registers that Krzysztof asked:
> 
Thanks for the code.

XU4:	 [    0.080039] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x1c04832a] AUX_INFO[0x43] 
XU3:	 [    0.080034] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x1604832a] AUX_INFO[0x43] 
XU3-lite:[    0.080033] Exynos: CPU[EXYNOS5800] CPU_REV[0x1] PKG_ID[0x5a12832a] AUX_INFO[0x13000054] 

Servus,
--
Markus Reichl

> diff --git a/drivers/soc/samsung/exynos-chipid.c b/drivers/soc/samsung/exynos-chipid.c
> index cf0128b18ee2..49fa76ec6d49 100644
> --- a/drivers/soc/samsung/exynos-chipid.c
> +++ b/drivers/soc/samsung/exynos-chipid.c
> @@ -22,6 +22,9 @@
>  #define EXYNOS_MAINREV_MASK	(0xF << 0)
>  #define EXYNOS_REV_MASK		(EXYNOS_SUBREV_MASK | EXYNOS_MAINREV_MASK)
>  
> +#define EXYNOS_PKG_ID		0x04
> +#define EXYNOS_AUX_INFO		0x1C
> +
>  static const struct exynos_soc_id {
>  	const char *name;
>  	unsigned int id;
> @@ -71,6 +74,8 @@ int __init exynos_chipid_early_init(void)
>  	const struct of_device_id *match;
>  	u32 product_id;
>  	u32 revision;
> +	u32 pkg_id;
> +	u32 aux_info;
>  
>  	np = of_find_matching_node_and_match(NULL,
>  			of_exynos_chipid_ids, &match);
> @@ -84,6 +89,8 @@ int __init exynos_chipid_early_init(void)
>  
>  	product_id  = readl_relaxed(exynos_chipid_base);
>  	revision = product_id & EXYNOS_REV_MASK;
> +	pkg_id = readl_relaxed(exynos_chipid_base + EXYNOS_PKG_ID);
> +	aux_info = readl_relaxed(exynos_chipid_base + EXYNOS_AUX_INFO);
>  	iounmap(exynos_chipid_base);
>  
>  	soc_dev_attr = kzalloc(sizeof(*soc_dev_attr), GFP_KERNEL);
> @@ -100,8 +107,8 @@ int __init exynos_chipid_early_init(void)
>  	soc_dev_attr->soc_id = product_id_to_soc_id(product_id);
>  
>  
> -	pr_info("Exynos: CPU[%s] CPU_REV[0x%x] Detected\n",
> -			product_id_to_soc_id(product_id), revision);
> +	pr_info("Exynos: CPU[%s] CPU_REV[0x%x] PKG_ID[0x%x] AUX_INFO[0x%x] \n",
> +		product_id_to_soc_id(product_id), revision, pkg_id, aux_info);
>  
>  	soc_dev = soc_device_register(soc_dev_attr);
>  	if (IS_ERR(soc_dev)) {
> 
> Best regards,
> 

^ permalink raw reply

* [PATCH v3 1/3] USB3/DWC3: Add definition for global soc bus configuration register
From: Changming Huang @ 2016-12-19  9:25 UTC (permalink / raw)
  To: balbi, mark.rutland, catalin.marinas, will.deacon, robh+dt, linux
  Cc: devicetree, linux-usb, linux-kernel, linux-arm-kernel,
	Changming Huang

Add the macro definition for global soc bus configuration register 0/1

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
Changes in v3:
  - no change
Changes in v2:
  - split the patch
  - add more macro definition for soc bus configuration register

 drivers/usb/dwc3/core.h |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index de5a857..065aa6f 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -161,6 +161,32 @@
 
 /* Bit fields */
 
+/* Global SoC Bus Configuration Register 0 */
+#define AXI3_CACHE_TYPE_AW		0x8 /* write allocate */
+#define AXI3_CACHE_TYPE_AR		0x4 /* read allocate */
+#define AXI3_CACHE_TYPE_SNP		0x2 /* cacheable */
+#define AXI3_CACHE_TYPE_BUF		0x1 /* bufferable */
+#define DWC3_GSBUSCFG0_DATARD_SHIFT	28
+#define DWC3_GSBUSCFG0_DESCRD_SHIFT	24
+#define DWC3_GSBUSCFG0_DATAWR_SHIFT	20
+#define DWC3_GSBUSCFG0_DESCWR_SHIFT	16
+#define DWC3_GSBUSCFG0_SNP_MASK		0xffff0000
+#define DWC3_GSBUSCFG0_DATABIGEND	(1 << 11)
+#define DWC3_GSBUSCFG0_DESCBIGEND	(1 << 10)
+#define DWC3_GSBUSCFG0_INCR256BRSTENA	(1 << 7) /* INCR256 burst */
+#define DWC3_GSBUSCFG0_INCR128BRSTENA	(1 << 6) /* INCR128 burst */
+#define DWC3_GSBUSCFG0_INCR64BRSTENA	(1 << 5) /* INCR64 burst */
+#define DWC3_GSBUSCFG0_INCR32BRSTENA	(1 << 4) /* INCR32 burst */
+#define DWC3_GSBUSCFG0_INCR16BRSTENA	(1 << 3) /* INCR16 burst */
+#define DWC3_GSBUSCFG0_INCR8BRSTENA	(1 << 2) /* INCR8 burst */
+#define DWC3_GSBUSCFG0_INCR4BRSTENA	(1 << 1) /* INCR4 burst */
+#define DWC3_GSBUSCFG0_INCRBRSTENA	(1 << 0) /* undefined length enable */
+#define DWC3_GSBUSCFG0_INCRBRST_MASK	0xff
+
+/* Global SoC Bus Configuration Register 1 */
+#define DWC3_GSBUSCFG1_1KPAGEENA	(1 << 12) /* 1K page boundary enable */
+#define DWC3_GSBUSCFG1_PTRANSLIMIT_MASK	0xf00
+
 /* Global Debug Queue/FIFO Space Available Register */
 #define DWC3_GDBGFIFOSPACE_NUM(n)	((n) & 0x1f)
 #define DWC3_GDBGFIFOSPACE_TYPE(n)	(((n) << 5) & 0x1e0)
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Changming Huang @ 2016-12-19  9:25 UTC (permalink / raw)
  To: balbi, mark.rutland, catalin.marinas, will.deacon, robh+dt, linux
  Cc: devicetree, linux-usb, linux-kernel, linux-arm-kernel,
	Changming Huang
In-Reply-To: <1482139554-13618-1-git-send-email-jerry.huang@nxp.com>

New property "snps,incr-burst-type-adjustment = <x>, <y>" for USB3.0 DWC3.
Field "x": 1/0 - undefined length INCR burst type enable or not;
Field "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst type.

While enabling undefined length INCR burst type and INCR16 burst type,
get better write performance on NXP Layerscape platform:
around 3% improvement (from 364MB/s to 375MB/s).

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
---
Changes in v3:
  - add new property for INCR burst in usb node.

 Documentation/devicetree/bindings/usb/dwc3.txt |    5 +++++
 arch/arm/boot/dts/ls1021a.dtsi                 |    1 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |    3 +++
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |    2 ++
 4 files changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index e3e6983..8c405a3 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -55,6 +55,10 @@ Optional properties:
 	fladj_30mhz_sdbnd signal is invalid or incorrect.
 
  - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
+	register, undefined length INCR burst type enable and INCRx type.
+	First field is for undefined length INCR burst type enable or not.
+	Second field is for largest INCRx type enabled.
 
 This is usually a subnode to DWC3 glue to which it is connected.
 
@@ -63,4 +67,5 @@ dwc3@4a030000 {
 	reg = <0x4a030000 0xcfff>;
 	interrupts = <0 92 4>
 	usb-phy = <&usb2_phy>, <&usb3,phy>;
+	snps,incr-burst-type-adjustment = <0x1>, <16>;
 };
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..2999edb 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -627,6 +627,7 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 			snps,dis_rxdet_inp3_quirk;
+			snps,incr-burst-type-adjustment = <0x1>, <16>;
 		};
 
 		pcie@3400000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
index 97d331e..64828ce 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi
@@ -482,6 +482,7 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 			snps,dis_rxdet_inp3_quirk;
+			snps,incr-burst-type-adjustment = <0x1>, <16>;
 		};
 
 		usb1: usb3@3000000 {
@@ -491,6 +492,7 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 			snps,dis_rxdet_inp3_quirk;
+			snps,incr-burst-type-adjustment = <0x1>, <16>;
 		};
 
 		usb2: usb3@3100000 {
@@ -500,6 +502,7 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 			snps,dis_rxdet_inp3_quirk;
+			snps,incr-burst-type-adjustment = <0x1>, <16>;
 		};
 
 		sata: sata@3200000 {
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index d058e56..414af27 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -710,6 +710,7 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 			snps,dis_rxdet_inp3_quirk;
+			snps,incr-burst-type-adjustment = <0x1>, <16>;
 		};
 
 		usb1: usb3@3110000 {
@@ -720,6 +721,7 @@
 			dr_mode = "host";
 			snps,quirk-frame-length-adjustment = <0x20>;
 			snps,dis_rxdet_inp3_quirk;
+			snps,incr-burst-type-adjustment = <0x1>, <16>;
 		};
 
 		ccn@4000000 {
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v3 3/3] USB3/DWC3: Enable undefined length INCR burst type
From: Changming Huang @ 2016-12-19  9:25 UTC (permalink / raw)
  To: balbi, mark.rutland, catalin.marinas, will.deacon, robh+dt, linux
  Cc: linux-usb, linux-kernel, devicetree, linux-arm-kernel,
	Changming Huang, Rajesh Bhagat
In-Reply-To: <1482139554-13618-1-git-send-email-jerry.huang@nxp.com>

Enable the undefined length INCR burst type and set INCRx.
Different platform may has the different burst size type.
In order to get best performance, we need to tune the burst size to
one special value, instead of the default value.

Signed-off-by: Changming Huang <jerry.huang@nxp.com>
Signed-off-by: Rajesh Bhagat <rajesh.bhagat@nxp.com>
---
Changes in v3:
  - add new property for INCR burst in usb node to reset GSBUSCFG0.
Changes in v2:
  - split patch
  - create one new function to handle soc bus configuration register.

 drivers/usb/dwc3/core.c |   51 +++++++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/dwc3/core.h |    7 +++++++
 2 files changed, 58 insertions(+)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 369bab1..404d7e9 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -650,6 +650,55 @@ static void dwc3_core_setup_global_control(struct dwc3 *dwc)
 	dwc3_writel(dwc->regs, DWC3_GCTL, reg);
 }
 
+/* set global soc bus configuration registers */
+static void dwc3_set_soc_bus_cfg(struct dwc3 *dwc)
+{
+	struct device *dev = dwc->dev;
+	u32 cfg;
+	int ret;
+
+	cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
+
+	/* Get INCR burst type, if return !NULL, not to change this type */
+	ret = device_property_read_u32_array(dev,
+			"snps,incr-burst-type-adjustment",
+			dwc->incr_burst_type, 2);
+	if (!ret) {
+		/* Enable Undefined Length INCR Burst and Enable INCRx Burst */
+		cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
+		if (*dwc->incr_burst_type)
+			cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
+		switch (*(dwc->incr_burst_type + 1)) {
+		case 256:
+			cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
+			break;
+		case 128:
+			cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
+			break;
+		case 64:
+			cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
+			break;
+		case 32:
+			cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
+			break;
+		case 16:
+			cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
+			break;
+		case 8:
+			cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
+			break;
+		case 4:
+			cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
+			break;
+		default:
+			dev_err(dev, "Invalid property\n");
+			break;
+		}
+	}
+
+	dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
+}
+
 /**
  * dwc3_core_init - Low-level initialization of DWC3 Core
  * @dwc: Pointer to our controller context structure
@@ -698,6 +747,8 @@ static int dwc3_core_init(struct dwc3 *dwc)
 	/* Adjust Frame Length */
 	dwc3_frame_length_adjustment(dwc);
 
+	dwc3_set_soc_bus_cfg(dwc);
+
 	usb_phy_set_suspend(dwc->usb2_phy, 0);
 	usb_phy_set_suspend(dwc->usb3_phy, 0);
 	ret = phy_power_on(dwc->usb2_generic_phy);
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 065aa6f..cfe389b 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -805,6 +805,7 @@ struct dwc3_scratchpad_array {
  * @regs: base address for our registers
  * @regs_size: address space size
  * @fladj: frame length adjustment
+ * @incr_burst_type: INCR burst type adjustment
  * @irq_gadget: peripheral controller's IRQ number
  * @nr_scratch: number of scratch buffers
  * @u1u2: only used on revisions <1.83a for workaround
@@ -928,6 +929,12 @@ struct dwc3 {
 	enum usb_phy_interface	hsphy_mode;
 
 	u32			fladj;
+	/*
+	 * For INCR burst type.
+	 * First field: for undefined length INCR burst type enable.
+	 * Second field: for INCRx burst type enable
+	 */
+	u32			incr_burst_type[2];
 	u32			irq_gadget;
 	u32			nr_scratch;
 	u32			u1u2;
-- 
1.7.9.5

^ permalink raw reply related

* Re: [PATCH 2/2] iio: adc: hx711: Add IIO driver for AVIA HX711
From: Andreas Klinger @ 2016-12-19  9:26 UTC (permalink / raw)
  To: Matt Ranostay
  Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
	mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
	galak-sgV2jX0FEOL9JmXXK+q4OQ, jic23-DgEjT+Ai2ygdnm+yROfE0A,
	knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
	pmeerw-jW+XmwGofnusTnJN9+BGXg
In-Reply-To: <CAJCx=g=--vuGHRi1HUjJgzV_Hwj0-6bO+oakCNN_LZQVbwn5_A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hello Matt,

thank you for your suggestions. See below.


Matt Ranostay <matt.ranostay-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> schrieb am Sat, 17. Dec 00:53:
> On Tue, Dec 13, 2016 at 10:02 AM, Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org> wrote:
> > This is the IIO driver for AVIA HX711 ADC which ist mostly used in weighting
> > cells.
> 
> First off cool that this is finally getting a driver... I'll have to
> get the SparkFun breakout and really cheap scale to test :).
> 
> >
> > The protocol is quite simple and using GPIO's:
> > One GPIO is used as clock (SCK) while another GPIO is read (DOUT)
> >
> > Signed-off-by: Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> > ---
> >  drivers/iio/adc/Kconfig  |  13 +++
> >  drivers/iio/adc/Makefile |   1 +
> >  drivers/iio/adc/hx711.c  | 269 +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 283 insertions(+)
> >  create mode 100644 drivers/iio/adc/hx711.c
> >
> > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> > index 932de1f9d1e7..7902b50fcf32 100644
> > --- a/drivers/iio/adc/Kconfig
> > +++ b/drivers/iio/adc/Kconfig
> > @@ -205,6 +205,19 @@ config HI8435
> >           This driver can also be built as a module. If so, the module will be
> >           called hi8435.
> >
> > +config HX711
> > +       tristate "AVIA HX711 ADC for weight cells"
> > +       depends on GPIOLIB
> > +       help
> > +         If you say yes here you get support for AVIA HX711 ADC which is used
> > +         for weight cells
> > +
> > +         This driver uses two GPIO's, one for setting the clock and the other
> > +         one for getting the data
> > +
> > +         This driver can also be built as a module. If so, the module will be
> > +         called hx711.
> > +
> >  config INA2XX_ADC
> >         tristate "Texas Instruments INA2xx Power Monitors IIO driver"
> >         depends on I2C && !SENSORS_INA2XX
> > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> > index b1aa456e6af3..d46e289900ef 100644
> > --- a/drivers/iio/adc/Makefile
> > +++ b/drivers/iio/adc/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_CC10001_ADC) += cc10001_adc.o
> >  obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
> >  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
> >  obj-$(CONFIG_HI8435) += hi8435.o
> > +obj-$(CONFIG_HX711) += hx711.o
> >  obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
> >  obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
> >  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> > diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> > new file mode 100644
> > index 000000000000..cbc89e467985
> > --- /dev/null
> > +++ b/drivers/iio/adc/hx711.c
> > @@ -0,0 +1,269 @@
> > +/*
> > + * HX711: analog to digital converter for weight sensor module
> > + *
> > + * Copyright (c) Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>
> > + *
> > + * This program 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 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.
> > + *
> > + */
> > +#include <linux/err.h>
> > +#include <linux/gpio.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +#include <linux/slab.h>
> > +#include <linux/sched.h>
> > +#include <linux/delay.h>
> > +#include <linux/iio/iio.h>
> > +
> > +#define HX711_GAIN_32          2       /* gain = 32 for channel B  */
> > +#define HX711_GAIN_64          3       /* gain = 64 for channel A  */
> > +#define HX711_GAIN_128         1       /* gain = 128 for channel A */
> > +
> > +
> > +struct hx711_data {
> > +       struct device           *dev;
> > +       dev_t                   devt;
> > +       struct gpio_desc        *gpiod_sck;
> > +       struct gpio_desc        *gpiod_dout;
> > +       int                     gain_pulse;
> > +       struct mutex            lock;
> > +};
> > +
> > +static void hx711_reset(struct hx711_data *hx711_data)
> > +{
> > +       int val;
> > +       int i;
> > +
> > +       val = gpiod_get_value(hx711_data->gpiod_dout);
> 
> could move the val assignment here to the initialization don't think
> it will hit 80 chars
> 

I'll change this.

> > +       if (val) {
> 
> move "int i" here to avoid compiler initialization warnings
> 
> > +               dev_warn(hx711_data->dev, "RESET-HX711\n");
> > +
> > +               gpiod_set_value(hx711_data->gpiod_sck, 1);
> > +               udelay(80);
> 
> IIRC this chip has quite a bit of latency thresholds, can't use
> usleep_range? Single core embedded systems could have an issue with
> continuous  polling.
>

That's a good suggestion. We don't need udelay so i'll change to usleep_range
for the next version

> > +               gpiod_set_value(hx711_data->gpiod_sck, 0);
> > +
> > +               for (i = 0; i < 1000; i++) {
> > +                       val = gpiod_get_value(hx711_data->gpiod_dout);
> > +                       if (!val)
> > +                               break;
> > +                       /* sleep at least 1 ms*/
> > +                       msleep(1);
> > +               }
> > +       }
> > +}
> > +
> > +static int hx711_cycle(struct hx711_data *hx711_data)
> > +{
> > +       int val;
> > +
> > +       /* if preempted for more then 60us while SCK is high:
> > +        * hx711 is going in reset
> > +        * ==> measuring is false
> > +        */
> > +       preempt_disable();
> > +       gpiod_set_value(hx711_data->gpiod_sck, 1);
> > +       val = gpiod_get_value(hx711_data->gpiod_dout);
> > +       gpiod_set_value(hx711_data->gpiod_sck, 0);
> > +       preempt_enable();
> > +
> > +       return val;
> > +}
> > +
> > +static unsigned int hx711_read(struct hx711_data *hx711_data)
> > +{
> > +       int i;
> > +       int ret;
> > +       int wert = 0;
> > +
> > +       hx711_reset(hx711_data);
> > +
> > +       for (i = 0; i < 24; i++) {
> > +               wert <<= 1;
> > +               ret = hx711_cycle(hx711_data);
> > +               if (ret)
> > +                       wert++;
> > +       }
> > +
> > +       wert ^= 0x800000;
> > +
> > +       for (i = 0; i < hx711_data->gain_pulse; i++)
> > +               ret = hx711_cycle(hx711_data);
> 
> What is ret used for here?
> > +
> > +       return wert;
> > +}
> > +
> > +
> > +static int hx711_read_raw(struct iio_dev *iio_dev,
> > +                               const struct iio_chan_spec *chan,
> > +                               int *val, int *val2, long mask)
> > +{
> > +       struct hx711_data *hx711_data = iio_priv(iio_dev);
> > +       int ret;
> > +
> > +       switch (mask) {
> > +       case IIO_CHAN_INFO_RAW:
> > +               switch (chan->type) {
> > +               case IIO_VOLTAGE:
> > +                       mutex_lock(&hx711_data->lock);
> > +                       *val = (int)hx711_read(hx711_data);
> > +                       mutex_unlock(&hx711_data->lock);
> > +                       ret = IIO_VAL_INT;
> > +                       break;
> > +               default:
> > +                       return -EINVAL;
> > +               }
> > +               return ret;
> > +       default:
> > +               return -EINVAL;
> > +       }
> > +
> > +       return ret;
> > +}
> > +
> > +static const struct iio_info hx711_iio_info = {
> > +       .driver_module          = THIS_MODULE,
> > +       .read_raw               = hx711_read_raw,
> > +};
> > +
> > +static const struct iio_chan_spec hx711_chan_spec[] = {
> > +       { .type = IIO_VOLTAGE,
> > +               .channel = 0,
> > +               .info_mask_separate =
> > +                       BIT(IIO_CHAN_INFO_RAW),
> > +               .scan_type = {
> > +                       .sign = 'u',
> > +                       .realbits = 24,
> > +                       .storagebits = 32,
> > +                       .shift = 0,
> > +               }
> > +       },
> > +};
> > +
> > +static int hx711_probe(struct platform_device *pdev)
> > +{
> > +       struct device *dev = &pdev->dev;
> > +       struct device_node *node = dev->of_node;
> > +       struct hx711_data *hx711_data = NULL;
> > +       struct iio_dev *iio;
> > +       int ret = 0, ival;
> > +
> > +       iio = devm_iio_device_alloc(dev, sizeof(struct hx711_data));
> > +       if (!iio) {
> > +               dev_err(dev, "failed to allocate IIO device\n");
> > +               return -ENOMEM;
> > +       }
> > +
> > +       hx711_data = iio_priv(iio);
> > +       hx711_data->dev = dev;
> > +
> > +       mutex_init(&hx711_data->lock);
> > +
> > +       hx711_data->gpiod_sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_HIGH);
> > +       if (IS_ERR(hx711_data->gpiod_sck)) {
> > +               ret = PTR_ERR(hx711_data->gpiod_sck);
> > +               goto err;
> > +       }
> > +
> > +       hx711_data->gpiod_dout = devm_gpiod_get(dev, "dout", GPIOD_OUT_HIGH);
> > +       if (IS_ERR(hx711_data->gpiod_dout)) {
> > +               ret = PTR_ERR(hx711_data->gpiod_dout);
> > +               goto err;
> > +       }
> > +
> > +       ret = of_property_read_u32 (node, "gain", &ival);
> > +       if (!ret) {
> > +               switch (ival) {
> > +               case 32:
> > +                       hx711_data->gain_pulse = HX711_GAIN_32;
> > +                       break;
> > +               case 64:
> > +                       hx711_data->gain_pulse = HX711_GAIN_64;
> > +                       break;
> > +               case 128:
> > +                       hx711_data->gain_pulse = HX711_GAIN_128;
> > +                       break;
> > +               default:
> > +                       hx711_data->gain_pulse = HX711_GAIN_128;
> > +               }
> > +       } else
> > +               hx711_data->gain_pulse = HX711_GAIN_128;
> > +       dev_dbg(hx711_data->dev, "gain: %d\n", hx711_data->gain_pulse);
> > +
> > +       ret = gpiod_direction_input(hx711_data->gpiod_dout);
> > +       if (ret < 0) {
> > +               dev_err(hx711_data->dev, "gpiod_direction_input: %d\n", ret);
> > +               goto err;
> > +       }
> > +
> > +       ret = gpiod_direction_output(hx711_data->gpiod_sck, 0);
> > +       if (ret < 0) {
> > +               dev_err(hx711_data->dev, "gpiod_direction_output: %d\n", ret);
> > +               goto err;
> > +       }
> > +
> > +       platform_set_drvdata(pdev, iio);
> > +
> > +       iio->name = pdev->name;
> > +       iio->dev.parent = &pdev->dev;
> > +       iio->info = &hx711_iio_info;
> > +       iio->modes = INDIO_DIRECT_MODE;
> > +       iio->channels = hx711_chan_spec;
> > +       iio->num_channels = ARRAY_SIZE(hx711_chan_spec);
> > +
> > +       dev_err(hx711_data->dev, "initialized\n");
> > +
> > +       return devm_iio_device_register(dev, iio);
> > +
> > +err:
> > +       return ret;
> > +}
> > +
> > +
> > +static int hx711_suspend(struct device *dev)
> > +{
> > +       return 0;
> > +}
> > +
> > +static int hx711_resume(struct device *dev)
> > +{
> > +       return 0;
> > +}
> > +
> > +static SIMPLE_DEV_PM_OPS(hx711_pm_ops, hx711_suspend, hx711_resume);
> > +
> > +
> > +static const struct of_device_id of_hx711_match[] = {
> > +       { .compatible = "avia,hx711", },
> > +       {},
> > +};
> > +
> > +MODULE_DEVICE_TABLE(of, of_hx711_match);
> > +
> > +static struct platform_driver hx711_driver = {
> > +       .probe          = hx711_probe,
> > +       .driver         = {
> > +               .name           = "hx711-gpio",
> > +               .pm             = &hx711_pm_ops,
> > +               .of_match_table = of_hx711_match,
> > +       },
> > +};
> > +
> > +module_platform_driver(hx711_driver);
> > +
> > +MODULE_AUTHOR("Andreas Klinger <ak-n176/SwNRljddJNmlsFzeA@public.gmane.org>");
> > +MODULE_DESCRIPTION("HX711 bitbanging driver - ADC for weight cells");
> > +MODULE_LICENSE("GPL");
> > +MODULE_ALIAS("platform:hx711-gpio");
> > +
> > --
> > 2.1.4
> >
> > --
> > 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 pci/next] PCI: rcar: Add compatible string for r8a7796
From: Geert Uytterhoeven @ 2016-12-19  9:49 UTC (permalink / raw)
  To: Yoshihiro Kaneko
  Cc: linux-pci, Bjorn Helgaas, Simon Horman, Magnus Damm,
	Linux-Renesas, devicetree@vger.kernel.org
In-Reply-To: <1482064022-8998-1-git-send-email-ykaneko0929@gmail.com>

Hi Kaneko-san,

On Sun, Dec 18, 2016 at 1:27 PM, Yoshihiro Kaneko <ykaneko0929@gmail.com> wrote:
> From: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
>
> This patch adds support for r8a7796.
>
> Signed-off-by: Harunobu Kurokawa <harunobu.kurokawa.dn@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> ---
>
> This patch is based on the next branch of the pci tree.
>
>  Documentation/devicetree/bindings/pci/rcar-pci.txt | 1 +
>  drivers/pci/host/pcie-rcar.c                       | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> index eee518d..34712d6 100644
> --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
> @@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC;
>             "renesas,pcie-r8a7791" for the R8A7791 SoC;
>             "renesas,pcie-r8a7793" for the R8A7793 SoC;
>             "renesas,pcie-r8a7795" for the R8A7795 SoC;
> +           "renesas,pcie-r8a7796" for the R8A7796 SoC;
>             "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device.
>             "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device.
>
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index aca85be..02e5777 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1078,6 +1078,7 @@ static int rcar_pcie_parse_map_dma_ranges(struct rcar_pcie *pcie,
>         { .compatible = "renesas,pcie-rcar-gen2",
>           .data = rcar_pcie_hw_init_gen2 },
>         { .compatible = "renesas,pcie-r8a7795", .data = rcar_pcie_hw_init },
> +       { .compatible = "renesas,pcie-r8a7796", .data = rcar_pcie_hw_init },
>         { .compatible = "renesas,pcie-rcar-gen3", .data = rcar_pcie_hw_init },
>         {},

Given the driver already matches against "renesas,pcie-rcar-gen3",
and mainline arch/arm64/boot/dts/renesas/r8a7796.dtsi doesn't have pcie
nodes yet, I think there's no need to update the driver, only the bindings.

Hence if you drop the last chunk, you can add my
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* [PATCH] ARM: dts: da850-lcdk: add gpio-keys
From: Bartosz Golaszewski @ 2016-12-19  9:53 UTC (permalink / raw)
  To: Sekhar Nori, Kevin Hilman, Michael Turquette, Rob Herring,
	Frank Rowand, Mark Rutland, Russell King
  Cc: arm-soc, linux-devicetree, LKML, Bartosz Golaszewski

Add a gpio-keys node for two user buttons present on the board.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
 arch/arm/boot/dts/da850-lcdk.dts | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 397c77a..628f4de 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -6,6 +6,7 @@
 /dts-v1/;
 #include "da850.dtsi"
 #include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
 
 / {
 	model = "DA850/AM1808/OMAP-L138 LCDK";
@@ -90,6 +91,23 @@
 			};
 		};
 	};
+
+	gpio-keys {
+		compatible = "gpio-keys";
+		autorepeat;
+
+		user1 {
+			label = "GPIO Key USER1";
+			linux,code = <BTN_0>;
+			gpios = <&gpio 36 GPIO_ACTIVE_LOW>;
+		};
+
+		user2 {
+			label = "GPIO Key USER2";
+			linux,code = <BTN_1>;
+			gpios = <&gpio 37 GPIO_ACTIVE_LOW>;
+		};
+	};
 };
 
 &pmx_core {
-- 
2.9.3

^ permalink raw reply related

* Re: [PATCH/RFC v2 3/7] spi: core: Add support for registering SPI slave controllers
From: Geert Uytterhoeven @ 2016-12-19 10:02 UTC (permalink / raw)
  To: Mark Brown
  Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Magnus Damm,
	Wolfram Sang, Hisashi Nakamura, Hiromitsu Yamasaki, linux-spi,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161215175326.tbblqe7kto2qgxwz-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>

Hi Mark,

On Thu, Dec 15, 2016 at 6:53 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Sep 12, 2016 at 10:50:42PM +0200, Geert Uytterhoeven wrote:
>> TBD:
>>   - s/spi_master/spi_controller/ where appropriate,
>>   - Provide wrappers (e.g. "#define spi_master spi_controller" until all
>>     SPI drivers have been converted),
>>   - Do we want a separate spi_register_slave() instead?
>
> This basically looks fine to me - there's these TBDs so I might be
> missing things and we probably need some GPIO chip select handling but

Given the hard real-time requirements of SPI slave, supporting GPIO chip
select may not be feasible.

> that's a separate thing.  Sorry it took me so long to review this.

Thanks for the review!

As I managed to fix the issue with spi_slave_abort() on MSIOF, I think
the remaining
obstacle is the DT binding.  Do you have any feedback or other
suggestions in that area?

IMHO having the ability to bind to an SPI slave handler either from DT or
by using the sysfs virtual file is useful to have.

Thanks again!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH v6 2/5] lib: implement __arch_bitrev8x4()
From: Will Deacon @ 2016-12-19 10:06 UTC (permalink / raw)
  To: Joshua Clayton
  Cc: Alan Tull, Moritz Fischer, Russell King, Catalin Marinas,
	Shawn Guo, Sascha Hauer, Fabio Estevam, Mark Rutland, Rob Herring,
	Anatolij Gustschin, devicetree, linux-kernel, linux-arm-kernel,
	linux-fpga
In-Reply-To: <6c1c052d3c1d0c02a791aaaf8e114360ab1cb4e7.1481918884.git.stillcompiling@gmail.com>

On Fri, Dec 16, 2016 at 03:17:51PM -0800, Joshua Clayton wrote:
> Implement faster bitrev8x4() for arm, arm64 and mips, all the platforms
> with CONFIG_HAVE_ARCH_BITREVERSE.
> ARM platforms just need a byteswap added to the existing __arch_bitrev32()
> Amusingly, the mips implementation is exactly the opposite, requiring
> removal of the byteswap from its __arch_bitrev32()
> 
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
>  arch/arm/include/asm/bitrev.h   | 6 ++++++
>  arch/arm64/include/asm/bitrev.h | 6 ++++++
>  arch/mips/include/asm/bitrev.h  | 6 ++++++
>  include/linux/bitrev.h          | 1 +
>  4 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
> index ec291c3..9482f78 100644
> --- a/arch/arm/include/asm/bitrev.h
> +++ b/arch/arm/include/asm/bitrev.h
> @@ -17,4 +17,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
>  	return __arch_bitrev32((u32)x) >> 24;
>  }
>  
> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
> +{
> +	__asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
> +	return x;
> +}
> +
>  #endif
> diff --git a/arch/arm64/include/asm/bitrev.h b/arch/arm64/include/asm/bitrev.h
> index a5a0c36..1801078 100644
> --- a/arch/arm64/include/asm/bitrev.h
> +++ b/arch/arm64/include/asm/bitrev.h
> @@ -16,4 +16,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
>  	return __arch_bitrev32((u32)x) >> 24;
>  }
>  
> +static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
> +{
> +	__asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));

This is broken -- you're operating on 64-bit registers. I only noticed
because if you write:

  swab32(bitrev32(x))

then GCC generates:

  rbit	w0, w0
  rev	w0, w0

so perhaps we should just implement the asm-generic version like that
and not bother with the arch-specific stuff?

Will

^ permalink raw reply

* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Maxime Ripard @ 2016-12-19 10:09 UTC (permalink / raw)
  To: Icenowy Zheng
  Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <4720181481899200@web7g.yandex.ru>


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

On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
> >>  > >  &r_pio {
> >>  > >  wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
> >>  > > - pins = "PL6", "PL7", "PL11";
> >>  > > + pins = "PL6", "PL7", "PL8", "PL11";
> >>  > >  function = "gpio_in";
> >>  > >  bias-pull-up;
> >>  > >  };
> >>  >
> >>  > There's several things wrong here. The first one is that you rely
> >>  > solely on the pinctrl state to maintain a reset line. This is very
> >>  > fragile (especially since the GPIO pinctrl state are likely to go away
> >>  > at some point), but it also means that if your driver wants to recover
> >>  > from that situation at some point, it won't work.
> >>  >
> >>  > The other one is that the bluetooth and wifi chips are two devices in
> >>  > linux, and you assign that pin to the wrong device (wifi).
> >>  >
> >>  > rfkill-gpio is made just for that, so please use it.
> >>
> >>  The GPIO is not for the radio, but for the full Bluetooth part.
> >
> > I know.
> >
> >>  If it's set to 0, then the bluetooth part will reset, and the
> >>  hciattach will fail.
> >
> > Both rfkill-gpio and rfkill-regulator will shutdown when called
> > (either by poking the reset pin or shutting down the regulator), so
> > that definitely seems like an expected behavior to put the device in
> > reset.
> >
> >>  The BSP uses this as a rfkill, and the result is that the bluetooth
> >>  on/off switch do not work properly.
> >
> > Then rfkill needs fixing, but working around it by hoping that the
> > core will probe an entirely different device, and enforcing a default
> > that the rest of the kernel might or might not change is both fragile
> > and wrong.
> 
> I think a rfkill-gpio here works just like the BSP rfkill...
> 
> The real problem is that the Realtek UART bluetooth driver is a userspace
> program (a modified hciattach), which is not capable of the GPIO reset...

Can't you run rfkill before attaching? What is the problem exactly?
It's not in reset for long enough?

This seems more and more like an issue in the BT stack you're
using. We might consider workarounds in the kernel, but they have to
be correct.

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 v10 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Geert Uytterhoeven @ 2016-12-19 11:16 UTC (permalink / raw)
  To: Joel Holdsworth
  Cc: atull, Moritz Fischer, Rob Herring, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-spi, Marek Vasut, linux-fpga
In-Reply-To: <1482039234-21335-2-git-send-email-joel@airwebreathe.org.uk>

Hi Joel,

On Sun, Dec 18, 2016 at 6:33 AM, Joel Holdsworth
<joel@airwebreathe.org.uk> wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel@airwebreathe.org.uk>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Alan Tull <atull@opensource.altera.com>
> Acked-by: Moritz Fischer <moritz.fischer@ettus.com>
> Acked-by: Marek Vasut <marex@denx.de>

> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> @@ -0,0 +1,21 @@
> +Lattice iCE40 FPGA Manager
> +
> +Required properties:
> +- compatible:          Should contain "lattice,ice40-fpga-mgr"
> +- reg:                 SPI chip select
> +- spi-max-frequency:   Maximum SPI frequency (>=1000000, <=25000000)
> +- cdone-gpios:         GPIO input connected to CDONE pin
> +- reset-gpios:         Active-low GPIO output connected to CRESET_B pin. Note
> +                       that unless the GPIO is held low during startup, the
> +                       FPGA will enter Master SPI mode and drive SCK with a
> +                       clock signal potentially jamming other devices on the
> +                       bus until the firmware is loaded.
> +
> +Example:
> +       ice40: ice40@0 {

As per ePAPR, node names should be generic names, e.g. "fpga@0".
Sorry for not noticing before.

> +               compatible = "lattice,ice40-fpga-mgr";
> +               reg = <0>;
> +               spi-max-frequency = <1000000>;
> +               cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> +               reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
> +       };

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Matt Redfearn @ 2016-12-19 12:04 UTC (permalink / raw)
  To: Serge Semin, ralf, paul.burton, rabinv, james.hogan,
	alexander.sverdlin, robh+dt, frowand.list
  Cc: Sergey.Semin, linux-mips, devicetree, linux-kernel
In-Reply-To: <1482113266-13207-20-git-send-email-fancer.lancer@gmail.com>

Hi Serge,


On 19/12/16 02:07, Serge Semin wrote:
> It's useful to have some printed map of the kernel virtual memory,
> at least for debugging purpose.
>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
>   arch/mips/mm/init.c | 47 +++++++++++++++++++++++++++++++++++
>   1 file changed, 47 insertions(+)
>
> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> index 13a032f..35e7ba8 100644
> --- a/arch/mips/mm/init.c
> +++ b/arch/mips/mm/init.c
> @@ -32,6 +32,7 @@
>   #include <linux/hardirq.h>
>   #include <linux/gfp.h>
>   #include <linux/kcore.h>
> +#include <linux/sizes.h>
>   
>   #include <asm/asm-offsets.h>
>   #include <asm/bootinfo.h>
> @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
>   }
>   
>   /*
> + * Print out kernel memory layout
> + */
> +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> +static void __init mem_print_kmap_info(void)
> +{
> +	pr_notice("Virtual kernel memory layout:\n"
> +		  "    lowmem  : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> +		  "    vmalloc : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> +#ifdef CONFIG_HIGHMEM
> +		  "    pkmap   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> +#endif
> +		  "    fixmap  : 0x%08lx - 0x%08lx   (%4ld kB)\n"
> +		  "      .text : 0x%p" " - 0x%p" "   (%4td kB)\n"
> +		  "      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
> +		  "      .init : 0x%p" " - 0x%p" "   (%4td kB)\n",
> +		MLM(PAGE_OFFSET, (unsigned long)high_memory),
> +		MLM(VMALLOC_START, VMALLOC_END),
> +#ifdef CONFIG_HIGHMEM
> +		MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> +#endif
> +		MLK(FIXADDR_START, FIXADDR_TOP),
> +		MLK_ROUNDUP(_text, _etext),
> +		MLK_ROUNDUP(_sdata, _edata),
> +		MLK_ROUNDUP(__init_begin, __init_end));

Please drop printing the kernel addresses, or at least only do it if 
KASLR is not turned on, otherwise you're removing the advantage of 
KASLR, that critical kernel addresses cannot be determined easily from 
userspace.

It may be better to merge the functionality of show_kernel_relocation
http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
into this function, but only print it under the same conditions as 
currently, i.e.
#if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530

Thanks,
Matt

> +
> +	/* Check some fundamental inconsistencies. May add something else? */
> +#ifdef CONFIG_HIGHMEM
> +	BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
> +	BUG_ON(VMALLOC_END < (unsigned long)high_memory);
> +#endif
> +	BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
> +	BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
> +					(unsigned long)high_memory);
> +	BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
> +	BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
> +}
> +#undef MLK
> +#undef MLM
> +#undef MLK_ROUNDUP
> +
> +/*
>    * Not static inline because used by IP27 special magic initialization code
>    */
>   void setup_zero_pages(void)
> @@ -492,6 +536,9 @@ void __init mem_init(void)
>   	/* Free highmemory registered in memblocks */
>   	mem_init_free_highmem();
>   
> +	/* Print out kernel memory layout */
> +	mem_print_kmap_info();
> +
>   	/* Print out memory areas statistics */
>   	mem_init_print_info(NULL);
>   

^ permalink raw reply

* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 12:09 UTC (permalink / raw)
  To: Matt Redfearn
  Cc: ralf, paul.burton, rabinv, james.hogan, alexander.sverdlin,
	robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
	linux-kernel
In-Reply-To: <db27f41e-4121-bb83-6533-6727c26b9c5b@imgtec.com>

On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn <matt.redfearn@imgtec.com> wrote:
Hello Matt.

> Hi Serge,
> 
> 
> On 19/12/16 02:07, Serge Semin wrote:
> >It's useful to have some printed map of the kernel virtual memory,
> >at least for debugging purpose.
> >
> >Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> >---
> >  arch/mips/mm/init.c | 47 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 47 insertions(+)
> >
> >diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
> >index 13a032f..35e7ba8 100644
> >--- a/arch/mips/mm/init.c
> >+++ b/arch/mips/mm/init.c
> >@@ -32,6 +32,7 @@
> >  #include <linux/hardirq.h>
> >  #include <linux/gfp.h>
> >  #include <linux/kcore.h>
> >+#include <linux/sizes.h>
> >  #include <asm/asm-offsets.h>
> >  #include <asm/bootinfo.h>
> >@@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> >  }
> >  /*
> >+ * Print out kernel memory layout
> >+ */
> >+#define MLK(b, t) b, t, ((t) - (b)) >> 10
> >+#define MLM(b, t) b, t, ((t) - (b)) >> 20
> >+#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> >+static void __init mem_print_kmap_info(void)
> >+{
> >+	pr_notice("Virtual kernel memory layout:\n"
> >+		  "    lowmem  : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> >+		  "    vmalloc : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> >+#ifdef CONFIG_HIGHMEM
> >+		  "    pkmap   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> >+#endif
> >+		  "    fixmap  : 0x%08lx - 0x%08lx   (%4ld kB)\n"
> >+		  "      .text : 0x%p" " - 0x%p" "   (%4td kB)\n"
> >+		  "      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
> >+		  "      .init : 0x%p" " - 0x%p" "   (%4td kB)\n",
> >+		MLM(PAGE_OFFSET, (unsigned long)high_memory),
> >+		MLM(VMALLOC_START, VMALLOC_END),
> >+#ifdef CONFIG_HIGHMEM
> >+		MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> >+#endif
> >+		MLK(FIXADDR_START, FIXADDR_TOP),
> >+		MLK_ROUNDUP(_text, _etext),
> >+		MLK_ROUNDUP(_sdata, _edata),
> >+		MLK_ROUNDUP(__init_begin, __init_end));
> 
> Please drop printing the kernel addresses, or at least only do it if KASLR
> is not turned on, otherwise you're removing the advantage of KASLR, that
> critical kernel addresses cannot be determined easily from userspace.
> 
> It may be better to merge the functionality of show_kernel_relocation
> http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> into this function, but only print it under the same conditions as
> currently, i.e.
> #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
> 
> Thanks,
> Matt
> 

Understood. Will be fixed within the next patchset.

> >+
> >+	/* Check some fundamental inconsistencies. May add something else? */
> >+#ifdef CONFIG_HIGHMEM
> >+	BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
> >+	BUG_ON(VMALLOC_END < (unsigned long)high_memory);
> >+#endif
> >+	BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
> >+	BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
> >+					(unsigned long)high_memory);
> >+	BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
> >+	BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
> >+}
> >+#undef MLK
> >+#undef MLM
> >+#undef MLK_ROUNDUP
> >+
> >+/*
> >   * Not static inline because used by IP27 special magic initialization code
> >   */
> >  void setup_zero_pages(void)
> >@@ -492,6 +536,9 @@ void __init mem_init(void)
> >  	/* Free highmemory registered in memblocks */
> >  	mem_init_free_highmem();
> >+	/* Print out kernel memory layout */
> >+	mem_print_kmap_info();
> >+
> >  	/* Print out memory areas statistics */
> >  	mem_init_print_info(NULL);
> 

^ permalink raw reply

* [PATCH v10 8/8] dt-bindings: mmc: Add Cavium SOCs MMC bindings
From: Jan Glauber @ 2016-12-19 12:15 UTC (permalink / raw)
  To: Ulf Hansson
  Cc: linux-mmc, linux-kernel, David Daney, Steven J . Hill,
	Jan Glauber, Rob Herring, Mark Rutland, devicetree
In-Reply-To: <20161219121552.18316-1-jglauber@cavium.com>

Add description of Cavium Octeon and ThunderX SOC device tree bindings.

CC: Ulf Hansson <ulf.hansson@linaro.org>
CC: Rob Herring <robh+dt@kernel.org>
CC: Mark Rutland <mark.rutland@arm.com>
CC: devicetree@vger.kernel.org

Signed-off-by: Jan Glauber <jglauber@cavium.com>
---
 .../devicetree/bindings/mmc/octeon-mmc.txt         | 59 ++++++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mmc/octeon-mmc.txt

diff --git a/Documentation/devicetree/bindings/mmc/octeon-mmc.txt b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
new file mode 100644
index 0000000..aad02eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/octeon-mmc.txt
@@ -0,0 +1,59 @@
+* Cavium Octeon & ThunderX MMC controller
+
+The highspeed MMC host controller on Caviums SoCs provides an interface
+for MMC and SD types of memory cards.
+
+Supported maximum speeds are the ones of the eMMC standard 4.41 as well
+as the speed of SD standard 4.0. Only 3.3 Volt is supported.
+
+Required properties:
+ - compatible : should be one of:
+   * "cavium,octeon-6130-mmc"
+   * "cavium,octeon-6130-mmc-slot"
+   * "cavium,octeon-7890-mmc"
+   * "cavium,octeon-7890-mmc-slot"
+   * "cavium,thunder-8190-mmc"
+   * "cavium,thunder-8190-mmc-slot"
+   * "cavium,thunder-8390-mmc"
+   * "cavium,thunder-8390-mmc-slot"
+ - reg : mmc controller base registers
+ - clocks : phandle
+
+Optional properties:
+ - for cd, bus-width and additional generic mmc parameters
+   please refer to mmc.txt within this directory
+ - "cavium,cmd-clk-skew" : number of coprocessor clocks before sampling command
+ - "cavium,dat-clk-skew" : number of coprocessor clocks before sampling data
+
+Deprecated properties:
+- spi-max-frequency : use max-frequency instead
+- "cavium,bus-max-width" : use bus-width instead
+
+Examples:
+	- Within .dtsi:
+	mmc_1_4: mmc@1,4 {
+		compatible = "cavium,thunder-8390-mmc";
+		reg = <0x0c00 0 0 0 0>;	/* DEVFN = 0x0c (1:4) */
+		#address-cells = <1>;
+		#size-cells = <0>;
+		clocks = <&sclk>;
+	};
+
+	- Within dts:
+	mmc-slot@0 {
+		compatible = "cavium,thunder-8390-mmc-slot";
+		reg = <0>;
+		voltage-ranges = <3300 3300>;
+		max-frequency = <42000000>;
+		bus-width = <4>;
+		cap-sd-highspeed;
+	};
+	mmc-slot@1 {
+		compatible = "cavium,thunder-8390-mmc-slot";
+		reg = <1>;
+		voltage-ranges = <3300 3300>;
+		max-frequency = <42000000>;
+		bus-width = <8>;
+		cap-mmc-highspeed;
+		non-removable;
+	};
-- 
2.9.0.rc0.21.g7777322

^ permalink raw reply related

* Re: [PATCH v2 02/11] mfd: axp20x: add volatile and writeable reg ranges for VBUS power supply driver
From: Quentin Schulz @ 2016-12-19 12:28 UTC (permalink / raw)
  To: Chen-Yu Tsai
  Cc: Sebastian Reichel, Rob Herring, Mark Rutland, Russell King,
	Maxime Ripard, Lee Jones, open list:THERMAL, devicetree,
	linux-kernel, linux-arm-kernel, Thomas Petazzoni
In-Reply-To: <CAGb2v66jDsU2rt4d-0ydWR926y-hHTfOBJQmyYVdKd7rcm1WWQ@mail.gmail.com>

Hi Chen-Yu,

On 14/12/2016 16:43, Chen-Yu Tsai wrote:
> On Fri, Dec 9, 2016 at 7:04 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>> The X-Powers AXP20X and AXP22X PMICs allow to choose the maximum voltage
>> and minimum current delivered by the VBUS power supply.
>>
>> This adds the register used by the VBUS power supply driver to the range
>> of volatile and writeable regs ranges.
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> ---
>>
>> added in v2
>>
>>  drivers/mfd/axp20x.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
>> index ba130be..6ee2cc6 100644
>> --- a/drivers/mfd/axp20x.c
>> +++ b/drivers/mfd/axp20x.c
>> @@ -65,12 +65,14 @@ static const struct regmap_access_table axp152_volatile_table = {
>>
>>  static const struct regmap_range axp20x_writeable_ranges[] = {
>>         regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>> +       regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> 
> This is already covered by the previous entry.
> 
>>         regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
>>         regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),
>>  };
>>
>>  static const struct regmap_range axp20x_volatile_ranges[] = {
>>         regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
>> +       regmap_reg_range(AXP20X_VBUS_IPSOUT_MGMT, AXP20X_VBUS_IPSOUT_MGMT),
> 
> And I'm not sure why you specify it as volatile? The PMIC doesn't change any
> of the bits in this register on its own.
> 

I got things mixed up between the work on the battery driver I'll soon
send (which actually needs updated reg ranges) and this VBUS driver.
Sorry for that.

> Same for the AXP22x bits. So basically I think you don't need this patch.
> 

Indeed. Should I send a v3 to remove this patch or is it fine for you to
ignore this one?

Thanks!
Quentin

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

^ permalink raw reply

* Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings
From: Lee Jones @ 2016-12-19 12:55 UTC (permalink / raw)
  To: Rob Herring
  Cc: Benjamin Gaignard, Mark Rutland, Alexandre Torgue,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Thierry Reding, Linux PWM List, Jonathan Cameron, Hartmut Knaack,
	Lars-Peter Clausen, Peter Meerwald,
	linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Fabrice Gasnier, Gerald Baeza, Arnaud POULIQUEN
In-Reply-To: <CAL_JsqL8pJSFb8LbABAYJOQ0URaMpyupbFryk_mS2ToN1kStdA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, 13 Dec 2016, Rob Herring wrote:
> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, 12 Dec 2016, Rob Herring wrote:
> >
> >> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote:
> >> > Define bindings for pwm-stm32
> >> >
> >> > version 6:
> >> > - change st,breakinput parameter format to make it usuable on stm32f7 too.
> >> >
> >> > version 2:
> >> > - use parameters instead of compatible of handle the hardware configuration
> >> >
> >> > Signed-off-by: Benjamin Gaignard <benjamin.gaignard-qxv4g6HH51o@public.gmane.org>
> >> > ---
> >> >  .../devicetree/bindings/pwm/pwm-stm32.txt          | 33 ++++++++++++++++++++++
> >> >  1 file changed, 33 insertions(+)
> >> >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> > new file mode 100644
> >> > index 0000000..866f222
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
> >> > @@ -0,0 +1,33 @@
> >> > +STMicroelectronics STM32 Timers PWM bindings
> >> > +
> >> > +Must be a sub-node of an STM32 Timers device tree node.
> >> > +See ../mfd/stm32-timers.txt for details about the parent node.
> >> > +
> >> > +Required parameters:
> >> > +- compatible:              Must be "st,stm32-pwm".
> >> > +- pinctrl-names:   Set to "default".
> >> > +- pinctrl-0:               List of phandles pointing to pin configuration nodes for PWM module.
> >> > +                   For Pinctrl properties see ../pinctrl/pinctrl-bindings.txt
> >> > +
> >> > +Optional parameters:
> >> > +- st,breakinput:   Arrays of three u32 <index level filter> to describe break input configurations.
> >> > +                   "index" indicates on which break input the configuration should be applied.
> >> > +                   "level" gives the active level (0=low or 1=high) for this configuration.
> >> > +                   "filter" gives the filtering value to be applied.
> >> > +
> >> > +Example:
> >> > +   timers@40010000 {
> >>
> >> timer@...
> >
> > No, it should be timers.
> 
> Read the spec. "timer" is a generic node name. "timers" is not. How
> many is not relevant.

It's not the amount of timers that there are, it's the different types
of timers which this one IP contains.

In MFD we usually list the part number or IP name, however in this
case its difficult because the same IP doesn't have a specific name
listed, and provides; advanced, general purpose and basic timers, as
well as PWM functionality.

This IP is not a timer (although one of its children is one).  It's
the parent device of many different types of timer.

timer {
      timer {
      };

      pwm {
      };
};

... looks weird.

"timer" is not right for the parent IP.  Happy for you to provide an
alternative to "timers" though?

> > The 's' is intentional, since this parent (MFD) device houses 3
> > different types of timers.  The "timer" node is a child of this one.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* Re: [PATCH v7 1/2] mtd: nand: add tango NFC dt bindings doc
From: Boris Brezillon @ 2016-12-19 12:59 UTC (permalink / raw)
  To: Marc Gonzalez
  Cc: Arnd Bergmann, linux-mtd, Richard Weinberger, DT, Rob Herring,
	Mark Rutland, Mason, Sebastian Frias
In-Reply-To: <d3cbfda6-23bf-4ad1-b1ce-c179b765272f-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>

On Fri, 16 Dec 2016 11:56:38 +0100
Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org> wrote:

> On 07/11/2016 10:18, Arnd Bergmann wrote:
> > On Tuesday, October 25, 2016 3:15:50 PM CET Marc Gonzalez wrote:  
> >> Add the tango NAND Flash Controller dt bindings documentation.
> >>
> >> Signed-off-by: Marc Gonzalez <marc_gonzalez-y1yR0Z3OICC7zZZRDBGcUA@public.gmane.org>
> >> ---
> >>  Documentation/devicetree/bindings/mtd/tango-nand.txt | 38 ++++++++++++++++++++++++++++++
> >>  1 file changed, 38 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> new file mode 100644
> >> index 000000000000..3cbf95d6595a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> >> @@ -0,0 +1,38 @@
> >> +Sigma Designs Tango4 NAND Flash Controller (NFC)
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: "sigma,smp8758-nand"
> >> +- reg: address/size of nfc_reg, nfc_mem, and pbus_reg
> >> +- dmas: reference to the DMA channel used by the controller
> >> +- dma-names: "nfc_sbox"  
> > 
> > Drop the "nfc_" prefix here, it seems redundant.  
> 
> I took a closer look at Documentation/devicetree/bindings and
> arch/arm/boot/dts and it seems the overwhelming nomenclature
> is "rx", "tx" (with variants around these two).
> 
> Should I just use "rxtx" for my driver?
> 
> >> +- clocks: reference to the system clock
> >> +- #address-cells: <1>
> >> +- #size-cells: <0>
> >> +
> >> +Children nodes represent the available NAND chips.
> >> +See Documentation/devicetree/bindings/mtd/nand.txt for generic bindings.
> >> +
> >> +Example:
> >> +
> >> +	nand: nand@2c000 {
> >> +		compatible = "sigma,smp8758-nand";
> >> +		reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;  
> > 
> > It would be nicer to write this as
> > 
> > 	reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
> > 
> > which is identical in binary format.  
> 
> This is indeed a marked improvement. Boris, if I fix these two nits,
> can I submit a single patch, or do you want them split?

Sure, just describe the different binding changes in your commit
message.
--
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 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: James Hogan @ 2016-12-19 13:02 UTC (permalink / raw)
  To: Matt Redfearn
  Cc: Serge Semin, ralf, paul.burton, rabinv, alexander.sverdlin,
	robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
	linux-kernel
In-Reply-To: <db27f41e-4121-bb83-6533-6727c26b9c5b@imgtec.com>

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

Hi Matt,

On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> On 19/12/16 02:07, Serge Semin wrote:
> > It's useful to have some printed map of the kernel virtual memory,
> > at least for debugging purpose.
> >
> > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > ---

> > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> >   }
> >   
> >   /*
> > + * Print out kernel memory layout
> > + */
> > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > +static void __init mem_print_kmap_info(void)
> > +{
> > +	pr_notice("Virtual kernel memory layout:\n"
> > +		  "    lowmem  : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > +		  "    vmalloc : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > +#ifdef CONFIG_HIGHMEM
> > +		  "    pkmap   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > +#endif
> > +		  "    fixmap  : 0x%08lx - 0x%08lx   (%4ld kB)\n"
> > +		  "      .text : 0x%p" " - 0x%p" "   (%4td kB)\n"
> > +		  "      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
> > +		  "      .init : 0x%p" " - 0x%p" "   (%4td kB)\n",
> > +		MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > +		MLM(VMALLOC_START, VMALLOC_END),
> > +#ifdef CONFIG_HIGHMEM
> > +		MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > +#endif
> > +		MLK(FIXADDR_START, FIXADDR_TOP),
> > +		MLK_ROUNDUP(_text, _etext),
> > +		MLK_ROUNDUP(_sdata, _edata),
> > +		MLK_ROUNDUP(__init_begin, __init_end));
> 
> Please drop printing the kernel addresses, or at least only do it if 
> KASLR is not turned on, otherwise you're removing the advantage of 
> KASLR, that critical kernel addresses cannot be determined easily from 
> userspace.

According to Documentation/printk-formats.txt, this is what %pK is for.
Better to use that instead?

Cheers
James

> 
> It may be better to merge the functionality of show_kernel_relocation
> http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> into this function, but only print it under the same conditions as 
> currently, i.e.
> #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
> 
> Thanks,
> Matt

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

^ permalink raw reply

* Re: [PATCH 19/21] MIPS memblock: Add print out method of kernel virtual memory layout
From: Serge Semin @ 2016-12-19 13:15 UTC (permalink / raw)
  To: James Hogan
  Cc: Matt Redfearn, ralf, paul.burton, rabinv, alexander.sverdlin,
	robh+dt, frowand.list, Sergey.Semin, linux-mips, devicetree,
	linux-kernel
In-Reply-To: <20161219130236.GJ27950@jhogan-linux.le.imgtec.org>

On Mon, Dec 19, 2016 at 01:02:37PM +0000, James Hogan <james.hogan@imgtec.com> wrote:
> Hi Matt,
> 
> On Mon, Dec 19, 2016 at 12:04:54PM +0000, Matt Redfearn wrote:
> > On 19/12/16 02:07, Serge Semin wrote:
> > > It's useful to have some printed map of the kernel virtual memory,
> > > at least for debugging purpose.
> > >
> > > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > > ---
> 
> > > @@ -106,6 +107,49 @@ static void __init zone_sizes_init(void)
> > >   }
> > >   
> > >   /*
> > > + * Print out kernel memory layout
> > > + */
> > > +#define MLK(b, t) b, t, ((t) - (b)) >> 10
> > > +#define MLM(b, t) b, t, ((t) - (b)) >> 20
> > > +#define MLK_ROUNDUP(b, t) b, t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
> > > +static void __init mem_print_kmap_info(void)
> > > +{
> > > +	pr_notice("Virtual kernel memory layout:\n"
> > > +		  "    lowmem  : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > +		  "    vmalloc : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > +#ifdef CONFIG_HIGHMEM
> > > +		  "    pkmap   : 0x%08lx - 0x%08lx   (%4ld MB)\n"
> > > +#endif
> > > +		  "    fixmap  : 0x%08lx - 0x%08lx   (%4ld kB)\n"
> > > +		  "      .text : 0x%p" " - 0x%p" "   (%4td kB)\n"
> > > +		  "      .data : 0x%p" " - 0x%p" "   (%4td kB)\n"
> > > +		  "      .init : 0x%p" " - 0x%p" "   (%4td kB)\n",
> > > +		MLM(PAGE_OFFSET, (unsigned long)high_memory),
> > > +		MLM(VMALLOC_START, VMALLOC_END),
> > > +#ifdef CONFIG_HIGHMEM
> > > +		MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
> > > +#endif
> > > +		MLK(FIXADDR_START, FIXADDR_TOP),
> > > +		MLK_ROUNDUP(_text, _etext),
> > > +		MLK_ROUNDUP(_sdata, _edata),
> > > +		MLK_ROUNDUP(__init_begin, __init_end));
> > 
> > Please drop printing the kernel addresses, or at least only do it if 
> > KASLR is not turned on, otherwise you're removing the advantage of 
> > KASLR, that critical kernel addresses cannot be determined easily from 
> > userspace.
> 
> According to Documentation/printk-formats.txt, this is what %pK is for.
> Better to use that instead?
> 
> Cheers
> James
> 

The function is called from the kernel directly, which is privileged
enough to do the printing. So I suppose Matt is right, to hide this
prints out unless debug is enabled.

Thanks,
-Sergey

> > 
> > It may be better to merge the functionality of show_kernel_relocation
> > http://lxr.free-electrons.com/source/arch/mips/kernel/relocate.c#L354
> > into this function, but only print it under the same conditions as 
> > currently, i.e.
> > #if defined(CONFIG_DEBUG_KERNEL) && defined(CONFIG_DEBUG_INFO)
> > http://lxr.free-electrons.com/source/arch/mips/kernel/setup.c#L530
> > 
> > Thanks,
> > Matt

^ permalink raw reply

* Re: [PATCH/RFC v2 3/7] spi: core: Add support for registering SPI slave controllers
From: Mark Brown @ 2016-12-19 13:28 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Geert Uytterhoeven, Rob Herring, Mark Rutland, Magnus Damm,
	Wolfram Sang, Hisashi Nakamura, Hiromitsu Yamasaki, linux-spi,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-Renesas,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdXJu0-iTFu3KMWXbbgidB63Mxy0oAWmTKKt0UUKuPbprA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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

On Mon, Dec 19, 2016 at 11:02:07AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 15, 2016 at 6:53 PM, Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > On Mon, Sep 12, 2016 at 10:50:42PM +0200, Geert Uytterhoeven wrote:
> >> TBD:
> >>   - s/spi_master/spi_controller/ where appropriate,
> >>   - Provide wrappers (e.g. "#define spi_master spi_controller" until all
> >>     SPI drivers have been converted),
> >>   - Do we want a separate spi_register_slave() instead?

> > This basically looks fine to me - there's these TBDs so I might be
> > missing things and we probably need some GPIO chip select handling but

> Given the hard real-time requirements of SPI slave, supporting GPIO chip
> select may not be feasible.

It's not unknown for SPI devices to have some minimum time requirement
from chip select to first clock so it's workable and probably something
people will want at some point.  It can always be done later though.

> As I managed to fix the issue with spi_slave_abort() on MSIOF, I think
> the remaining
> obstacle is the DT binding.  Do you have any feedback or other
> suggestions in that area?

> IMHO having the ability to bind to an SPI slave handler either from DT or
> by using the sysfs virtual file is useful to have.

I think it'd be useful to have DT support but really I think the DT
maintainers are going to have more opinions on this than me.

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

^ permalink raw reply

* Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Alim Akhtar @ 2016-12-19 13:35 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Doug Anderson
  Cc: Bartlomiej Zolnierkiewicz, Javier Martinez Canillas, Arjun K V,
	Kukjin Kim, Rob Herring, Mark Rutland, Russell King,
	Andreas Faerber, Thomas Abraham, Ben Gamari, linux-samsung-soc,
	linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161216073720.GA3489@kozik-lap>

Hi,

On 12/16/2016 01:07 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
>>> [ I added Arjun to Cc:, maybe he can help in explaining this issue
>>>    (unfortunately Inderpal's email is no longer working). ]
>>>
>>> Please also note that on Exynos5422/5800 SoCs the same ARM rail
>>> voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
>>> IOW if the problem exists it is already present in the mainline
>>> kernel.
>>
>> Interesting.  In the ChromeOS tree I see significantly higher voltages
>> needed...  Note that one might naively look at
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/drivers/cpufreq/exynos5420-cpufreq.c#178>.
>>
>> 1362500, /* L0  2100 */
>> 1312500, /* L1  2000 */
>>
>> ..but, amazingly enough those voltages aren't used at all.  Surprise!
>>
>> I believe that the above numbers are actually not used and the ASV
>> numbers are used instead.  See
>> <https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/include/mach/asv-exynos542x.h#452>
>>
>> { 2100000,
>> 1350000, 1350000, 1350000, 1350000, 1350000,
>> 1337500, 1325000, 1312500, 1300000, 1287500,
>> 1275000, 1262500, 1250000, 1237500 },
>>
>> I believe that interpretation there is: some bins of the CPU can run
>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>
> That is definitely the case. One could just look at vendors ASV table
> (for 1.9 GHz):
> { 1900000, 1300000, 1287500, 1262500, 1237500, 1225000, 1212500,
>                      1200000, 1187500, 1175000, 1162500, 1150000,
> 		             1137500, 1125000, 1112500, 1112500},
>
> The theoretical difference is up to 1.875V! From my experiments I saw
> BIN1 chips which should be the same... but some working on 1.2V, some on
> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
> does not mean that there aren't such...
>
>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>> running on a CPU from a nice bin?
>
> Would be nice to see a dump of PKG_ID and AUX_INFO chipid registers
> along with name of tested board. Because the "Tested on XU3" is not
> sufficient.
>
I agree, we should be dumping PKG_ID and other chip info to know on 
which BIN sample this patch is tested on...
As far as Peach-{pit/pi} boards are concerns, this is what I can remember:
1> 5420 (PIT) -> max recommended target frequency is 1800 MHz for A15
2> 5800 (PI)-> max recommended target frequency can go upto 2000 MHz, 
with INT rail locking.
INT rail locking schemes never made to mainline, so to be safer side 
instead of bumping the clock and voltages better to keep it at safer 
range for pit and pi, probably thats why it was kept at 1800MHz.
I am not sure if the same limitation applies to Odroid-XU3 samples.


> Best regards,
> Krzysztof
>
>
>

^ permalink raw reply

* Re: [PATCH v2] ARM: dts: sun8i: add opp-v2 table for A33
From: Icenowy Zheng @ 2016-12-19 14:06 UTC (permalink / raw)
  To: Chen-Yu Tsai, Maxime Ripard
  Cc: Hans de Goede, Quentin Schulz, devicetree, linux-arm-kernel,
	linux-kernel, linux-clk, linux-sunxi
In-Reply-To: <CAGb2v65YWntCrFHtSbxhtTWkt+UwkW3xoY-ae26MpH+-ULLXSQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>



19.12.2016, 16:54, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
> On Mon, Dec 19, 2016 at 4:46 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>>  On Fri, Dec 16, 2016 at 02:27:54AM +0800, Icenowy Zheng wrote:
>>>  An operating point table is needed for the cpu frequency adjusting to
>>>  work.
>>>
>>>  The operating point table is converted from the common value in
>>>  extracted script.fex from many A33 board/tablets.
>>>
>>>  Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>>  ---
>>>  Changes since v1:
>>>  - Fix format problem (blank lines).
>>>  - Removed the 1.344GHz operating point, as it's overvoltage and overclocked.
>>>
>>>  This patch depends on the following patchset:
>>>
>>>  http://lists.infradead.org/pipermail/linux-arm-kernel/2016-December/473962.html
>>>
>>>  It's the v2 of the [PATCH 4/6] in this patchset.
>>>
>>>  I think this operating point table may also apply to A23, as there's no
>>>  difference except the points over 1.2GHz between A23 and A33's stock dvfs table.
>>>
>>>  But as A23 CCU may not have the necessary fixes, I won't add the table to A23
>>>  now.
>>>
>>>  Chen-Yu, could you test the CCU fixes I described in the patchset above on A23,
>>>  then test this operating points table?
>>>
>>>  If it's necessary, you can send out the CCU fixes and add one more patch that
>>>  moves this opp-v2 table to sun8i-a23-a33.dtsi .
>>>
>>>   arch/arm/boot/dts/sun8i-a33.dtsi | 35 +++++++++++++++++++++++++++++++++++
>>>   1 file changed, 35 insertions(+)
>>>
>>>  diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>  index 504996cbee29..0f5b2af72981 100644
>>>  --- a/arch/arm/boot/dts/sun8i-a33.dtsi
>>>  +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
>>>  @@ -46,7 +46,42 @@
>>>   #include <dt-bindings/dma/sun4i-a10.h>
>>>
>>>   / {
>>>  + cpu0_opp_table: opp_table0 {
>>>  + compatible = "operating-points-v2";
>>>  + opp-shared;
>>>  +
>>>  + opp@648000000 {
>>>  + opp-hz = /bits/ 64 <648000000>;
>>>  + opp-microvolt = <1040000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  +
>>>  + opp@816000000 {
>>>  + opp-hz = /bits/ 64 <816000000>;
>>>  + opp-microvolt = <1100000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  +
>>>  + opp@1008000000 {
>>>  + opp-hz = /bits/ 64 <1008000000>;
>>>  + opp-microvolt = <1200000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  +
>>>  + opp@1200000000 {
>>>  + opp-hz = /bits/ 64 <1200000000>;
>>>  + opp-microvolt = <1320000>;
>>>  + clock-latency-ns = <244144>; /* 8 32k periods */
>>>  + };
>>>  + };
>>>  +
>>>        cpus {
>>>  + cpu0: cpu@0 {
>>
>>  There's no need to duplicate the label here. I removed it and applied.
>
> I think using the label to directly reference cpu0 would be better,
> instead of duplicating the cpu@0 block.

After proper testing of A23 ccu, the operating points can also apply to A23.
(According to A23 devices' fex)

>
> ChenYu

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

^ permalink raw reply

* Re: [PATCH] ARM: dts: sun8i-q8-common: enable bluetooth on SDIO Wi-Fi
From: Icenowy Zheng @ 2016-12-19 14:08 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Hans de Goede, Chen-Yu Tsai, linux-kernel,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <20161219100952.bspym36nsehda3za@lukather>



19.12.2016, 18:09, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Dec 16, 2016 at 10:40:00PM +0800, Icenowy Zheng wrote:
>>  >>  > >  &r_pio {
>>  >>  > >  wifi_pwrseq_pin_q8: wifi_pwrseq_pin@0 {
>>  >>  > > - pins = "PL6", "PL7", "PL11";
>>  >>  > > + pins = "PL6", "PL7", "PL8", "PL11";
>>  >>  > >  function = "gpio_in";
>>  >>  > >  bias-pull-up;
>>  >>  > >  };
>>  >>  >
>>  >>  > There's several things wrong here. The first one is that you rely
>>  >>  > solely on the pinctrl state to maintain a reset line. This is very
>>  >>  > fragile (especially since the GPIO pinctrl state are likely to go away
>>  >>  > at some point), but it also means that if your driver wants to recover
>>  >>  > from that situation at some point, it won't work.
>>  >>  >
>>  >>  > The other one is that the bluetooth and wifi chips are two devices in
>>  >>  > linux, and you assign that pin to the wrong device (wifi).
>>  >>  >
>>  >>  > rfkill-gpio is made just for that, so please use it.
>>  >>
>>  >>  The GPIO is not for the radio, but for the full Bluetooth part.
>>  >
>>  > I know.
>>  >
>>  >>  If it's set to 0, then the bluetooth part will reset, and the
>>  >>  hciattach will fail.
>>  >
>>  > Both rfkill-gpio and rfkill-regulator will shutdown when called
>>  > (either by poking the reset pin or shutting down the regulator), so
>>  > that definitely seems like an expected behavior to put the device in
>>  > reset.
>>  >
>>  >>  The BSP uses this as a rfkill, and the result is that the bluetooth
>>  >>  on/off switch do not work properly.
>>  >
>>  > Then rfkill needs fixing, but working around it by hoping that the
>>  > core will probe an entirely different device, and enforcing a default
>>  > that the rest of the kernel might or might not change is both fragile
>>  > and wrong.
>>
>>  I think a rfkill-gpio here works just like the BSP rfkill...
>>
>>  The real problem is that the Realtek UART bluetooth driver is a userspace
>>  program (a modified hciattach), which is not capable of the GPIO reset...
>
> Can't you run rfkill before attaching? What is the problem exactly?
> It's not in reset for long enough?
>
> This seems more and more like an issue in the BT stack you're
> using. We might consider workarounds in the kernel, but they have to
> be correct.

One more rfkill interface will be generated for hci0 after hciattach, which can
be safely toggled block and unblock.

However, if the GPIO is toggled down, the hciattach program will die.

The bluetooth stack I used is fd.o's BlueZ.

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

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

^ permalink raw reply

* [PATCH 0/4] Add support for the ethernet switch on the EXPRESSObin
From: Romain Perier @ 2016-12-19 14:16 UTC (permalink / raw)
  To: Andrew Lunn, Vivien Didelot, Florian Fainelli, Jason Cooper,
	Sebastian Hesselbarth, Gregory Clement
  Cc: Mark Rutland, devicetree, Romain Perier, Pawel Moll, Ian Campbell,
	netdev, Nadav Haklai, Rob Herring, Kumar Gala, Thomas Petazzoni,
	linux-arm-kernel

This set of patches adds support for the Marvell ethernet switch 88E6341.
It also add the devicetree definition of thid switch to the DT board.

Romain Perier (4):
  net: dsa: mv88e6xxx: Allow mv88e6xxx_smi_init() to be used at address
    0x1
  net: dsa: mv88e6xxx: Don't forbid MDIO I/Os for PHY addr >=
    num_of_ports
  net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341/88E6141
  arm64: dts: marvell: Add ethernet switch definition for the
    EXPRESSObin

 .../boot/dts/marvell/armada-3720-espressobin.dts   | 67 ++++++++++++++++++++++
 drivers/net/dsa/mv88e6xxx/chip.c                   | 24 ++++----
 drivers/net/dsa/mv88e6xxx/mv88e6xxx.h              |  4 +-
 3 files changed, 84 insertions(+), 11 deletions(-)

-- 
2.9.3

^ 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