Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] char: hw_random: atmel-rng: disable TRNG during suspend
From: Wenyou Yang @ 2016-10-25  0:56 UTC (permalink / raw)
  To: linux-arm-kernel

To fix the over consumption on the VDDCore due to the TRNG enabled,
disable the TRNG during suspend, not only disable the user interface
clock (which is controlled by PMC). Because the user interface clock
is independent from any clock that may be used in the entropy source
logic circuitry.

Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---

Changes in v2:
 - Enable the user interface first, then enable the internal clock
   when resume.

 drivers/char/hw_random/atmel-rng.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
index 0fcc9e6..ae7cae5 100644
--- a/drivers/char/hw_random/atmel-rng.c
+++ b/drivers/char/hw_random/atmel-rng.c
@@ -48,6 +48,16 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
 		return 0;
 }
 
+static void atmel_trng_enable(struct atmel_trng *trng)
+{
+	writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+}
+
+static void atmel_trng_disable(struct atmel_trng *trng)
+{
+	writel(TRNG_KEY, trng->base + TRNG_CR);
+}
+
 static int atmel_trng_probe(struct platform_device *pdev)
 {
 	struct atmel_trng *trng;
@@ -71,7 +81,7 @@ static int atmel_trng_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
-	writel(TRNG_KEY | 1, trng->base + TRNG_CR);
+	atmel_trng_enable(trng);
 	trng->rng.name = pdev->name;
 	trng->rng.read = atmel_trng_read;
 
@@ -94,7 +104,7 @@ static int atmel_trng_remove(struct platform_device *pdev)
 
 	hwrng_unregister(&trng->rng);
 
-	writel(TRNG_KEY, trng->base + TRNG_CR);
+	atmel_trng_disable(trng);
 	clk_disable_unprepare(trng->clk);
 
 	return 0;
@@ -105,6 +115,7 @@ static int atmel_trng_suspend(struct device *dev)
 {
 	struct atmel_trng *trng = dev_get_drvdata(dev);
 
+	atmel_trng_disable(trng);
 	clk_disable_unprepare(trng->clk);
 
 	return 0;
@@ -113,8 +124,15 @@ static int atmel_trng_suspend(struct device *dev)
 static int atmel_trng_resume(struct device *dev)
 {
 	struct atmel_trng *trng = dev_get_drvdata(dev);
+	int ret;
+
+	ret = clk_prepare_enable(trng->clk);
+	if (ret)
+		return ret;
 
-	return clk_prepare_enable(trng->clk);
+	atmel_trng_enable(trng);
+
+	return 0;
 }
 
 static const struct dev_pm_ops atmel_trng_pm_ops = {
-- 
2.7.4

^ permalink raw reply related

* [PATCH/RFT v2 15/17] usb: host: ohci-da8xx: Add devicetree bindings documentation
From: David Lechner @ 2016-10-25  1:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-16-ahaslam@baylibre.com>

On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> This patch documents the device tree bindings required for
> the ohci controller found in TI da8xx family of SoC's
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
>  .../devicetree/bindings/usb/ohci-da8xx.txt         | 39 ++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/ohci-da8xx.txt
>
> diff --git a/Documentation/devicetree/bindings/usb/ohci-da8xx.txt b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
> new file mode 100644
> index 0000000..4251c84
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/ohci-da8xx.txt
> @@ -0,0 +1,39 @@
> +DA8XX USB OHCI controller
> +
> +Required properties:
> +
> + - compatible: Should be "ti,da830-ohci"
> + - reg:        Should contain one register range i.e. start and length
> + - interrupts: Description of the interrupt line
> + - phys:       Phandle for the PHY device
> + - phy-names:  Should be "usb-phy"
> +
> +Optional properties:
> + - vbus-supply: Regulator that controls vbus power


Isn't vbus-supply property required?

If it is really supposed to be optional, the ohci driver needs to use 
devm_regulator_get_optional() and handle the case when there is no 
regulator.

I don't see a problem with making it required though since one can just 
use a dummy supply if there is not a real one.

> +
> +Example for omap138-lck:
> +
> +vbus_fixed: fixed-regulator-vbus {
> +        compatible = "regulator-fixed";
> +        gpio = <&gpio 109 0>;
> +        oc-gpio = <&gpio 36 0>;
> +        regulator-boot-on;
> +        enable-active-high;
> +        regulator-name = "vbus";
> +        regulator-min-microvolt = <5000000>;
> +        regulator-max-microvolt = <5000000>;
> +};
> +
> +usb_phy: usb-phy {
> +        compatible = "ti,da830-usb-phy";
> +        #phy-cells = <1>;
> +        status = "disabled";

why disabled?

> +};
> +usb: usb at 0225000 {
> +        compatible = "ti,da830-ohci";
> +        reg = <0x225000 0x1000>;
> +        interrupts = <59>;
> +        phys = <&usb_phy 1>;
> +        phy-names = "usb-phy";

missing vbus-supply property

> +        status = "disabled";

why disabled?

> +};
>

^ permalink raw reply

* [PATCH/RFT v2 13/17] USB: da8xx: use ohci priv data instead of globals
From: David Lechner @ 2016-10-25  1:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-14-ahaslam@baylibre.com>

On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
> >  static const struct ohci_driver_overrides da8xx_overrides __initconst = {
> -	.reset		= ohci_da8xx_reset
> +	.reset		= ohci_da8xx_reset,
> +	.extra_priv_size = sizeof(struct da8xx_ohci_hcd),

nit: since you are changing both lines anyway, you might as well make 
the ='s line up.

>  };
>
>  /*
>

^ permalink raw reply

* [PATCH v5 02/23] of: device: Export of_device_{get_modalias, uvent_modalias} to modules
From: Peter Chen @ 2016-10-25  1:16 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <147733850401.29612.2343965740004706258@sboyd-linaro>

On Mon, Oct 24, 2016 at 12:48:24PM -0700, Stephen Boyd wrote:
> Quoting Chen-Yu Tsai (2016-10-24 05:19:05)
> > Hi,
> > 
> > On Tue, Oct 18, 2016 at 9:56 AM, Stephen Boyd <stephen.boyd@linaro.org> wrote:
> > > The ULPI bus can be built as a module, and it will soon be
> > > calling these functions when it supports probing devices from DT.
> > > Export them so they can be used by the ULPI module.
> > >
> > > Acked-by: Rob Herring <robh@kernel.org>
> > > Cc: <devicetree@vger.kernel.org>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > ---
> > >  drivers/of/device.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/of/device.c b/drivers/of/device.c
> > > index 8a22a253a830..6719ab35b62e 100644
> > > --- a/drivers/of/device.c
> > > +++ b/drivers/of/device.c
> > > @@ -225,6 +225,7 @@ ssize_t of_device_get_modalias(struct device *dev, char *str, ssize_t len)
> > >
> > >         return tsize;
> > >  }
> > > +EXPORT_SYMBOL_GPL(of_device_get_modalias);
> > >
> > >  int of_device_request_module(struct device *dev)
> > >  {
> > > @@ -290,6 +291,7 @@ void of_device_uevent(struct device *dev, struct kobj_uevent_env *env)
> > >         }
> > >         mutex_unlock(&of_mutex);
> > >  }
> > > +EXPORT_SYMBOL_GPL(of_device_uevent_modalias);
> > 
> > This is trailing the wrong function.
> > 
> 
> Good catch. Must have been some bad rebase.
> 
> Peter, can you fix it while applying or should I resend this patch?
> 

But, this is device tree patch. I can only get chipidea part and other
USB patches if Greg agrees.

-- 

Best Regards,
Peter Chen

^ permalink raw reply

* [PATCH/RFT v2 12/17] USB: ochi-da8xx: Use a regulator for vbus/overcurrent
From: David Lechner @ 2016-10-25  1:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-13-ahaslam@baylibre.com>

On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> Currently, the da8xx ohci driver uses a set of gpios and callbacks in
> board files to handle vbus and overcurrent irqs form the power supply.
> However, this does not play nice when moving to a DT based boot were
> we wont have board files.
>
> Instead of requesting and handling the gpio, use the regulator framework
> to take care of enabling and disabling vbus power.
> This has the benefit
> that we dont need to pass any more platform data to the driver:
>
> These will be handled by the regulator framework:
> set_power   ->  regulator_enable/regulator_disable
> get_power   ->  regulator_is_enabled
> get_oci     ->  regulator_get_mode
> ocic_notify ->  regulator notification
>
> We can keep the default potpgt and use the regulator start delay instead:
> potpgt      -> regulator startup delay time
>
> The hawk board does not have a GPIO/OVERCURRENT gpio to control vbus,
> (they should not have been decleared/reserved) so, just remove those
> definitions from the hwk board file.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---


How do you recover after an overcurrent event?

I have configured a fixed-regulator using device-tree, but similar to 
the configuration in the board files here. However, when I shorted out 
the VBUS and caused an overcurrent event, I see nothing in the kernel 
log saying that there was an overcurrent event and after I remove the 
short, the regulator is never turned back on.



> @@ -163,7 +198,6 @@ static int ohci_da8xx_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
>  				  u16 wIndex, char *buf, u16 wLength)
>  {
>  	struct device *dev		= hcd->self.controller;
> -	struct da8xx_ohci_root_hub *hub	= dev_get_platdata(dev);

nit: unnecessary whitespace change

>  	int temp;
>
>  	switch (typeReq) {

^ permalink raw reply

* [PATCH V3 1/2] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042
From: Jia Hongtao @ 2016-10-25  2:15 UTC (permalink / raw)
  To: linux-arm-kernel

From: Hongtao Jia <hongtao.jia@nxp.com>

Update #thermal-sensor-cells from 0 to 1 according to the new binding. The
sensor specifier added is the monitoring site ID, and represents the "n" in
TRITSRn and TRATSRn.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V3:
* Update the commit log to a better description.

Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
index 44e399b..145c7f4 100644
--- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
@@ -526,7 +526,7 @@
 
 				       0x00030000 0x00000012
 				       0x00030001 0x0000001d>;
-		#thermal-sensor-cells = <0>;
+		#thermal-sensor-cells = <1>;
 	};
 
 	thermal-zones {
@@ -534,7 +534,7 @@
 			polling-delay-passive = <1000>;
 			polling-delay = <5000>;
 
-			thermal-sensors = <&tmu>;
+			thermal-sensors = <&tmu 2>;
 
 			trips {
 				cpu_alert: cpu-alert {
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH V3 2/2] powerpc/mpc85xx: Update TMU device tree node for T1023/T1024
From: Jia Hongtao @ 2016-10-25  2:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477361742-589-1-git-send-email-hongtao.jia@nxp.com>

From: Hongtao Jia <hongtao.jia@nxp.com>

Update #thermal-sensor-cells from 0 to 1 according to the new binding. The
sensor specifier added is the monitoring site ID, and represents the "n" in
TRITSRn and TRATSRn.

Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
---
Changes for V3:
* Update the commit log to a better description.

Changes for V2:
* Rebase on latest linux-next tree (next-20161006).

 arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 6e0b489..bce762a 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -321,7 +321,7 @@
 				       0x00030001 0x0000000d
 				       0x00030002 0x00000019
 				       0x00030003 0x00000024>;
-		#thermal-sensor-cells = <0>;
+		#thermal-sensor-cells = <1>;
 	};
 
 	thermal-zones {
@@ -329,7 +329,7 @@
 			polling-delay-passive = <1000>;
 			polling-delay = <5000>;
 
-			thermal-sensors = <&tmu>;
+			thermal-sensors = <&tmu 0>;
 
 			trips {
 				cpu_alert: cpu-alert {
-- 
2.1.0.27.g96db324

^ permalink raw reply related

* [PATCH V2 1/5] powerpc/mpc85xx: Update TMU device tree node for T1040/T1042
From: Troy Jia @ 2016-10-25  2:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024083654.GB30578@tiger>


> -----Original Message-----
> From: Shawn Guo [mailto:shawnguo at kernel.org]
> Sent: Monday, October 24, 2016 4:37 PM
> To: Troy Jia <hongtao.jia@nxp.com>
> Cc: rui.zhang at intel.com; edubezval at gmail.com; robh+dt at kernel.org; Scott Wood
> <scott.wood@nxp.com>; devicetree at vger.kernel.org; linuxppc-
> dev at lists.ozlabs.org; linux-kernel at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org
> Subject: Re: [PATCH V2 1/5] powerpc/mpc85xx: Update TMU device tree node for
> T1040/T1042
> 
> On Sun, Oct 09, 2016 at 02:47:02PM +0800, Jia Hongtao wrote:
> > From: Hongtao Jia <hongtao.jia@nxp.com>
> >
> > SoC compatible string and endianness property are added according to
> > the new bindings.
> 
> The commit log doesn't seem to match the actual changes.  Same for patch 2/5.

Right. I just revise the log and sent a new version. Please help to review.
Thanks.

-Hongtao.

> 
> >
> > Signed-off-by: Jia Hongtao <hongtao.jia@nxp.com>
> > ---
> > Changes for V2:
> > * Rebase on latest linux-next tree (next-20161006).
> >
> >  arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> > b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> > index 44e399b..145c7f4 100644
> > --- a/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> > +++ b/arch/powerpc/boot/dts/fsl/t1040si-post.dtsi
> > @@ -526,7 +526,7 @@
> >
> >  				       0x00030000 0x00000012
> >  				       0x00030001 0x0000001d>;
> > -		#thermal-sensor-cells = <0>;
> > +		#thermal-sensor-cells = <1>;
> >  	};
> >
> >  	thermal-zones {
> > @@ -534,7 +534,7 @@
> >  			polling-delay-passive = <1000>;
> >  			polling-delay = <5000>;
> >
> > -			thermal-sensors = <&tmu>;
> > +			thermal-sensors = <&tmu 2>;
> >
> >  			trips {
> >  				cpu_alert: cpu-alert {
> > --
> > 2.1.0.27.g96db324
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH V7 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Zhang Rui @ 2016-10-25  2:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1190898538.120930.02d69662-0b1a-447d-9c29-782aec7a1189.open-xchange@email.1und1.de>

On Mon, 2016-10-24 at 20:25 +0200, Stefan Wahren wrote:
> > 
> > Eric Anholt <eric@anholt.net> hat am 24. Oktober 2016 um 18:38
> > geschrieben:
> > 
> > 
> > Stefan Wahren <stefan.wahren@i2se.com> writes:
> > 
> > > 
> > > Hi Martin,
> > > 
> > > Am 28.09.2016 um 23:10 schrieb Eric Anholt:
> > > > 
> > > > kernel at martin.sperl.org writes:
> > > > 
> > > > > 
> > > > > From: Martin Sperl <kernel@martin.sperl.org>
> > > > > 
> > > > > Add basic thermal driver for bcm2835 SOC.
> > > > > 
> > > > > This driver currently relies on the firmware setting up the
> > > > > tsense HW block and does not set it up itself.
> > > > > 
> > > > > Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
> > > > > Acked-by: Eric Anholt <eric@anholt.net>
> > > > > Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
> > > > What's the status of merging this one???I'd like to merge the
> > > > other
> > > > patches.
> > > i think it's necessary to rebase the whole series. Maybe we could
> > > get it
> > > into 4.10.
> > Why would it need to be rebased???The status, as far as I know, is
> > that
> > we're still waiting for the subsystem maintainer to respond.
> Since at least this patch won't apply anymore, but feedback from
> maintainer is
> still good :-)
> 
> Sorry for this impatience, but i'm afraid that we possibly miss 4.10.

Eduardo,

any comments on this patchset?

thanks,
rui

^ permalink raw reply

* [PATCH/RFT v2 07/17] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable
From: David Lechner @ 2016-10-25  2:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-8-ahaslam@baylibre.com>

On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> While probing ochi phy with usb20 phy as a parent clock for usb11_phy,
> the usb20_phy clock enable would time out. This is because the usb20
> module clock needs to enabled while trying to lock the usb20_phy PLL.
>
> Call clk enable and get for the usb20 peripheral before trying to
> enable the phy PLL.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---


This patch can be combined with "ARM: davinci: da8xx: add usb phy 
clocks" since that patch has not been merged yet.

If you like, I can resubmit my patches from this series along with the 
changes from this patch.

^ permalink raw reply

* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-25  2:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1593441f-d147-4c91-8aab-8622dd8ced19@lechnology.com>

On 10/24/2016 10:50 AM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> +};
>>> +
>>> +&spi1 {
>>> +    status = "okay";
>>> +    pinctrl-names = "default";
>>> +    pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
>>> +
>>> +    /* TODO: LCD Display goes here */
>>
>> Add this node when you actually have display working.
>
> What if we set this up as a spidev node instead? This way the display
> could be used from userspace without a driver.
>

To answer my own question, it seems that specifying "spidev" in 
devicetree is frowned upon since it does not "describe the hardware".

^ permalink raw reply

* [PATCH 0/2] to support memblock near alloc and memoryless on arm64
From: Zhen Lei @ 2016-10-25  2:59 UTC (permalink / raw)
  To: linux-arm-kernel

If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
actually exist. The percpu variable areas and numa control blocks of that
memoryless numa nodes need to be allocated from the nearest available
node to improve performance.

In the beginning, I added a new function:
phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size, phys_addr_t align, int nid);

But it can not replace memblock_virt_alloc_try_nid, because the latter can specify a min_addr,
it usually be assigned as __pa(MAX_DMA_ADDRESS), to prevent memory be allocated from DMA area.
It's bad to add another function, because the code will be duplicated in these two functions.

So I make memblock_alloc_near_nid to be called in the subfunctions of memblock_alloc_try_nid
and memblock_virt_alloc_try_nid. Add a macro node_distance_ready to distinguish different
situations:
1) By default, the value of node_distance_ready is zero, memblock_*_try_nid work as normal as before.
2) ARCH platforms set the value of node_distance_ready to be true when numa node distances are ready, (please refer patch 2)
   memblock_*_try_nid allocate memory from the nearest node relative to the specified node.

Zhen Lei (2):
  mm/memblock: prepare a capability to support memblock near alloc
  arm64/numa: support HAVE_MEMORYLESS_NODES

 arch/arm64/Kconfig            |  4 +++
 arch/arm64/include/asm/numa.h |  3 ++
 arch/arm64/mm/numa.c          |  6 +++-
 mm/memblock.c                 | 76 ++++++++++++++++++++++++++++++++++++-------
 4 files changed, 77 insertions(+), 12 deletions(-)

-- 
2.5.0

^ permalink raw reply

* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Zhen Lei @ 2016-10-25  2:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477364358-10620-1-git-send-email-thunder.leizhen@huawei.com>

If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
actually exist. The percpu variable areas and numa control blocks of that
memoryless numa nodes need to be allocated from the nearest available
node to improve performance.

Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
specified nid at the first time, but if that allocation failed it will
directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
the second time.

To compatible the above old scene, I use a marco node_distance_ready to
control it. By default, the marco node_distance_ready is not defined in
any platforms, the above mentioned functions will work as normal as
before. Otherwise, they will try the nearest node first.

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 mm/memblock.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 65 insertions(+), 11 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..556bbd2 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1213,9 +1213,71 @@ phys_addr_t __init memblock_alloc(phys_addr_t size, phys_addr_t align)
 	return memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
 }

+#ifndef node_distance_ready
+#define node_distance_ready()		0
+#endif
+
+static phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size,
+					phys_addr_t align, phys_addr_t start,
+					phys_addr_t end, int nid, ulong flags,
+					int alloc_func_type)
+{
+	int nnid, round = 0;
+	u64 pa;
+	DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
+
+	bitmap_zero(nodes_map, MAX_NUMNODES);
+
+again:
+	/*
+	 * There are total 4 cases:
+	 * <nid == NUMA_NO_NODE>
+	 *   1)2) node_distance_ready || !node_distance_ready
+	 *	Round 1, nnid = nid = NUMA_NO_NODE;
+	 * <nid != NUMA_NO_NODE>
+	 *   3) !node_distance_ready
+	 *	Round 1, nnid = nid;
+	 *    ::Round 2, currently only applicable for alloc_func_type = <0>
+	 *	Round 2, nnid = NUMA_NO_NODE;
+	 *   4) node_distance_ready
+	 *	Round 1, LOCAL_DISTANCE, nnid = nid;
+	 *	Round ?, nnid = nearest nid;
+	 */
+	if (!node_distance_ready() || (nid == NUMA_NO_NODE)) {
+		nnid = (++round == 1) ? nid : NUMA_NO_NODE;
+	} else {
+		int i, distance = INT_MAX;
+
+		for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
+			if (node_distance(nid, i) < distance) {
+				nnid = i;
+				distance = node_distance(nid, i);
+			}
+	}
+
+	switch (alloc_func_type) {
+	case 0:
+		pa = memblock_find_in_range_node(size, align, start, end, nnid, flags);
+		break;
+
+	case 1:
+	default:
+		pa = memblock_alloc_nid(size, align, nnid);
+		if (!node_distance_ready())
+			return pa;
+	}
+
+	if (!pa && (nnid != NUMA_NO_NODE)) {
+		bitmap_set(nodes_map, nnid, 1);
+		goto again;
+	}
+
+	return pa;
+}
+
 phys_addr_t __init memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid)
 {
-	phys_addr_t res = memblock_alloc_nid(size, align, nid);
+	phys_addr_t res = memblock_alloc_near_nid(size, align, 0, 0, nid, 0, 1);

 	if (res)
 		return res;
@@ -1276,19 +1338,11 @@ static void * __init memblock_virt_alloc_internal(
 		max_addr = memblock.current_limit;

 again:
-	alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
-					    nid, flags);
+	alloc = memblock_alloc_near_nid(size, align, min_addr, max_addr,
+					    nid, flags, 0);
 	if (alloc)
 		goto done;

-	if (nid != NUMA_NO_NODE) {
-		alloc = memblock_find_in_range_node(size, align, min_addr,
-						    max_addr, NUMA_NO_NODE,
-						    flags);
-		if (alloc)
-			goto done;
-	}
-
 	if (min_addr) {
 		min_addr = 0;
 		goto again;
--
2.5.0

^ permalink raw reply related

* [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES
From: Zhen Lei @ 2016-10-25  2:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477364358-10620-1-git-send-email-thunder.leizhen@huawei.com>

Some numa nodes may have no memory. For example:
1) a node has no memory bank plugged.
2) a node has no memory bank slots.

To ensure percpu variable areas and numa control blocks of the
memoryless numa nodes to be allocated from the nearest available node to
improve performance, defined node_distance_ready. And make its value to be
true immediately after node distances have been initialized.

Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
 arch/arm64/Kconfig            | 4 ++++
 arch/arm64/include/asm/numa.h | 3 +++
 arch/arm64/mm/numa.c          | 6 +++++-
 3 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 30398db..648dd13 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
 	def_bool y
 	depends on NUMA

+config HAVE_MEMORYLESS_NODES
+	def_bool y
+	depends on NUMA
+
 source kernel/Kconfig.preempt
 source kernel/Kconfig.hz

diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..9d068bf 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -13,6 +13,9 @@
 int __node_distance(int from, int to);
 #define node_distance(a, b) __node_distance(a, b)

+extern int __initdata arch_node_distance_ready;
+#define node_distance_ready()	arch_node_distance_ready
+
 extern nodemask_t numa_nodes_parsed __initdata;

 /* Mappings between node number and cpus on that node. */
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9a71d06..5db9765 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -36,6 +36,7 @@ static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
 static int numa_distance_cnt;
 static u8 *numa_distance;
 static bool numa_off;
+int __initdata arch_node_distance_ready;

 static __init int numa_parse_early_param(char *opt)
 {
@@ -395,9 +396,12 @@ static int __init numa_init(int (*init_func)(void))
 		return -EINVAL;
 	}

+	arch_node_distance_ready = 1;
 	ret = numa_register_nodes();
-	if (ret < 0)
+	if (ret < 0) {
+		arch_node_distance_ready = 0;
 		return ret;
+	}

 	setup_node_to_cpumask_map();

--
2.5.0

^ permalink raw reply related

* [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu
From: Icenowy Zheng @ 2016-10-25  3:32 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024082802.ev72szwmuqba5ll4@lukather>



> On Mon, Oct 24, 2016 at 11:59:30AM +0800, Icenowy Zheng wrote:
> 
>> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
>> The code that poke some unknown bit of PMU for H3/A64 didn't check
>> the PHY, and will cause kernel oops when PHY 0 is used.
>>
>> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> 
> Cc'ing stable would be nice.

Yes... As it's also used by H3...

> 
> Apart from that, Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>

If I change it to check whether phy->pmu is null, will you keep the ACK?

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

^ permalink raw reply

* [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Herbert Xu @ 2016-10-25  3:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>

On Mon, Oct 17, 2016 at 04:51:17PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
> 
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
> 
> Before this patch:
> 
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias:          platform:meson-rng
> 
> After this patch:
> 
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias:          platform:meson-rng
> alias:          of:N*T*Camlogic,meson-rngC*
> alias:          of:N*T*Camlogic,meson-rng
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Herbert Xu @ 2016-10-25  3:43 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476906618-14455-1-git-send-email-javier@osg.samsung.com>

On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
> 
> So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
> the reported uevent MODALIAS to user-space will always be the OF one.
> 
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH] ARM64: dts: bcm2835: Fix bcm2837 compatible string
From: Eric Anholt @ 2016-10-25  3:59 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477321791-7896-1-git-send-email-afaerber@suse.de>

e<#secure method=pgpmime mode=sign>
Andreas F?rber <afaerber@suse.de> writes:

> bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as
> "brcm,bcm2837" already.

Pulled to bcm2835-dt-64-next.  Thanks!

^ permalink raw reply

* [PATCH 5/8] ARM: gr8: Add missing pwm channel 1 pin
From: Chen-Yu Tsai @ 2016-10-25  4:10 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161020170739.lgt2ywm346vm47zd@lukather>

On Fri, Oct 21, 2016 at 1:07 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Oct 20, 2016 at 10:10:03PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > The PWM controller has two different channels, but only the first pin was
>> > exposed in the DTSI. Add the other one.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>>
>> > ---
>> >  arch/arm/boot/dts/ntc-gr8.dtsi | 7 +++++++
>> >  1 file changed, 7 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/ntc-gr8.dtsi b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > index 74aff795e723..fad7381630f3 100644
>> > --- a/arch/arm/boot/dts/ntc-gr8.dtsi
>> > +++ b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > @@ -854,6 +854,13 @@
>> >                                 allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> >                         };
>> >
>> > +                       pwm1_pins_a: pwm1 at 0 {
>>
>> Nit: really don't need "_a" and "@0" here.
>
> Fixed and applied.

Oops, you forgot to fix the label in the chip-pro dts:

  DTC     arch/arm/boot/dts/ntc-gr8-chip-pro.dtb
ERROR (phandle_references): Reference to non-existent node or label
"pwm1_pins_a"

ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:313: recipe for target
'arch/arm/boot/dts/ntc-gr8-chip-pro.dtb' failed

ChenYu

^ permalink raw reply

* [PATCH RESEND 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-10-25  4:11 UTC (permalink / raw)
  To: linux-arm-kernel

On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
(which is a Host-only controller, but more stable and easy to implement).

This property marks whether on a certain board which controller should be
attached to the PHY.

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 287150d..a63c766 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -36,6 +36,12 @@ Optional properties:
 - usb1_vbus-supply : regulator phandle for controller usb1 vbus
 - usb2_vbus-supply : regulator phandle for controller usb2 vbus
 
+Optional properties for H3 or A64 SoCs:
+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
+			 MUSB. (boolean, if this property is set, the OHCI/EHCI
+			 controllers at PHY0 should be enabled and the MUSB
+			 controller must *NOT* be enabled)
+
 Example:
 	usbphy: phy at 0x01c13400 {
 		#phy-cells = <1>;
-- 
2.10.1

^ permalink raw reply related

* [PATCH RESEND 2/2] phy-sun4i-usb: add support for host mode of phy0 on A64 SoC
From: Icenowy Zheng @ 2016-10-25  4:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161025041139.46454-1-icenowy@aosc.xyz>

The OTG phy of A64 can be put into the host mode with an OHCI/EHCI pair,
just like the H3 SoC.

Some A64 boards (such as Pine64 series) use the USB OTG port as a generic
USB-A port, and thus can be fully support by the driver now.

The register's name is changed to PHY_OTG_CFG, as it's described in the
A64 downstream BSP kernel source, at drivers/usb/host/sunxi_hci.h .

Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
 drivers/phy/phy-sun4i-usb.c | 46 +++++++++++++++++++++++++++++++++------------
 1 file changed, 34 insertions(+), 12 deletions(-)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a4db658..9287247 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -47,7 +47,7 @@
 #define REG_PHYBIST			0x08
 #define REG_PHYTUNE			0x0c
 #define REG_PHYCTL_A33			0x10
-#define REG_PHY_UNK_H3			0x20
+#define REG_PHY_OTG_CFG			0x20
 
 #define REG_PMU_UNK1			0x10
 
@@ -107,6 +107,7 @@ struct sun4i_usb_phy_cfg {
 	u8 phyctl_offset;
 	bool dedicated_clocks;
 	bool enable_pmu_unk1;
+	bool route_otg;
 };
 
 struct sun4i_usb_phy_data {
@@ -135,6 +136,7 @@ struct sun4i_usb_phy_data {
 	int id_det;
 	int vbus_det;
 	struct delayed_work detect;
+	bool otg_routed;
 };
 
 #define to_sun4i_usb_phy_data(phy) \
@@ -263,10 +265,11 @@ static int sun4i_usb_phy_init(struct phy *_phy)
 		writel(val & ~2, phy->pmu + REG_PMU_UNK1);
 	}
 
-	if (data->cfg->type == sun8i_h3_phy) {
-		if (phy->index == 0) {
-			val = readl(data->base + REG_PHY_UNK_H3);
-			writel(val & ~1, data->base + REG_PHY_UNK_H3);
+	if (data->cfg->route_otg) {
+		if (phy->index == 0 && data->otg_routed) {
+			/* Route the OTG PHY to HCI */
+			val = readl(data->base + REG_PHY_OTG_CFG);
+			writel(val & ~1, data->base + REG_PHY_OTG_CFG);
 		}
 	} else {
 		/* Enable USB 45 Ohm resistor calibration */
@@ -283,7 +286,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
 
 	sun4i_usb_phy_passby(phy, 1);
 
-	if (phy->index == 0) {
+	if (phy->index == 0 && !data->otg_routed) {
 		data->phy0_init = true;
 
 		/* Enable pull-ups */
@@ -310,7 +313,7 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
 	struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
 	struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
 
-	if (phy->index == 0) {
+	if (phy->index == 0 && !data->otg_routed) {
 		/* Disable pull-ups */
 		sun4i_usb_phy0_update_iscr(_phy, ISCR_DPDM_PULLUP_EN, 0);
 		sun4i_usb_phy0_update_iscr(_phy, ISCR_ID_PULLUP_EN, 0);
@@ -377,7 +380,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
 
 	/* For phy0 only turn on Vbus if we don't have an ext. Vbus */
 	if (phy->index == 0 && sun4i_usb_phy0_have_vbus_det(data) &&
-				data->vbus_det)
+				data->vbus_det && !data->otg_routed)
 		return 0;
 
 	ret = regulator_enable(phy->vbus);
@@ -387,7 +390,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
 	phy->regulator_on = true;
 
 	/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
-	if (phy->index == 0 && sun4i_usb_phy0_poll(data))
+	if (phy->index == 0 && sun4i_usb_phy0_poll(data) && !data->otg_routed)
 		mod_delayed_work(system_wq, &data->detect, DEBOUNCE_TIME);
 
 	return 0;
@@ -408,7 +411,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
 	 * phy0 vbus typically slowly discharges, sometimes this causes the
 	 * Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
 	 */
-	if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
+	if (phy->index == 0 && !sun4i_usb_phy0_poll(data) && !data->otg_routed)
 		mod_delayed_work(system_wq, &data->detect, POLL_TIME);
 
 	return 0;
@@ -567,7 +570,17 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
 		return -ENOMEM;
 
 	mutex_init(&data->mutex);
-	INIT_DELAYED_WORK(&data->detect, sun4i_usb_phy0_id_vbus_det_scan);
+	if (device_property_read_bool(dev, "allwinner,otg-routed")) {
+		/*
+		 * PHY0 is routed to HCI rather than OTG Controller.
+		 * In this situation, the port can only be used as a host port.
+		 */
+		data->otg_routed = true;
+	} else {
+		/* ID/Vbus detection is only meaningful when it's really OTG */
+		INIT_DELAYED_WORK(&data->detect,
+				  sun4i_usb_phy0_id_vbus_det_scan);
+	}
 	dev_set_drvdata(dev, data);
 	data->cfg = of_device_get_match_data(dev);
 	if (!data->cfg)
@@ -647,7 +660,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
 			return PTR_ERR(phy->reset);
 		}
 
-		if (i) { /* No pmu for usbc0 */
+		/* PMU is only valid on PHYs in HCI mode */
+		if (i || data->otg_routed) {
 			snprintf(name, sizeof(name), "pmu%d", i);
 			res = platform_get_resource_byname(pdev,
 							IORESOURCE_MEM, name);
@@ -719,6 +733,7 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = false,
 	.enable_pmu_unk1 = false,
+	.route_otg = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -728,6 +743,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = false,
 	.enable_pmu_unk1 = false,
+	.route_otg = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -737,6 +753,7 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = true,
 	.enable_pmu_unk1 = false,
+	.route_otg = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -746,6 +763,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = false,
 	.enable_pmu_unk1 = false,
+	.route_otg = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -755,6 +773,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
 	.phyctl_offset = REG_PHYCTL_A10,
 	.dedicated_clocks = true,
 	.enable_pmu_unk1 = false,
+	.route_otg = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -764,6 +783,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
 	.enable_pmu_unk1 = false,
+	.route_otg = false,
 };
 
 static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
@@ -772,6 +792,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
 	.disc_thresh = 3,
 	.dedicated_clocks = true,
 	.enable_pmu_unk1 = true,
+	.route_otg = true,
 };
 
 static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
@@ -781,6 +802,7 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
 	.phyctl_offset = REG_PHYCTL_A33,
 	.dedicated_clocks = true,
 	.enable_pmu_unk1 = true,
+	.route_otg = true,
 };
 
 static const struct of_device_id sun4i_usb_phy_of_match[] = {
-- 
2.10.1

^ permalink raw reply related

* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-25  5:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161024201020.h6akyqad2o42xkhq@lukather>

On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > Since SID's content is constant over reboot,
> 
> That's not true, at least not across all the Allwinner SoCs, and
> especially not on the A10 and A20 that this driver supports.
> 

On my cubieboard2 (A20)
hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
cubiedev ~ # reboot
cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem 
00000000  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  16 51 66 83 80 48 50 72  56 54 48 48 03 c2 75 72  |.Qf..HPrVTHH..ur|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

So clearly for me its constant.

> > it must not be used as source of randomness.
> 
> And I don't think that's true either. A constant entropy provider will
> not add any entropy, but will not remove any, would it?

I cced linux-crypto at the begining for confirmation on that.
But the problem is increased as a part of the content is predicatable over same type of device (at least the thirst bytes and all the zeros).

^ permalink raw reply

* [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-25  5:40 UTC (permalink / raw)
  To: linux-arm-kernel

Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
                Ths_exit)/(htotal*bpp/lane_number))

Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v1:
 - phy_timing2 and phy_timing3 refer clock cycle time.
 - define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
 drivers/gpu/drm/mediatek/mtk_dsi.c |  103 +++++++++++++++++++++++-------------
 1 file changed, 67 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..ade6f46 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
 #define LD0_WAKEUP_EN			BIT(2)
 
 #define DSI_PHY_TIMECON0	0x110
-#define LPX				(0xff << 0)
-#define HS_PRPR				(0xff << 8)
-#define HS_ZERO				(0xff << 16)
-#define HS_TRAIL			(0xff << 24)
+#define LPX				(5 << 0)
+#define HS_PRPR				(6 << 8)
+#define HS_ZERO				(10 << 16)
+#define HS_TRAIL			(8 << 24)
 
 #define DSI_PHY_TIMECON1	0x114
-#define TA_GO				(0xff << 0)
-#define TA_SURE				(0xff << 8)
-#define TA_GET				(0xff << 16)
-#define DA_HS_EXIT			(0xff << 24)
+#define TA_GO				(20 << 0)
+#define TA_SURE				(7 << 8)
+#define TA_GET				(25 << 16)
+#define DA_HS_EXIT			(7 << 24)
 
 #define DSI_PHY_TIMECON2	0x118
 #define CONT_DET			(0xff << 0)
@@ -158,28 +158,14 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
 	writel((temp & ~mask) | (data & mask), dsi->regs + offset);
 }
 
-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
+			      u32 phy_timing1, u32 phy_timing2,
+			      u32 phy_timing3)
 {
-	u32 timcon0, timcon1, timcon2, timcon3;
-	unsigned int ui, cycle_time;
-	unsigned int lpx;
-
-	ui = 1000 / dsi->data_rate + 0x01;
-	cycle_time = 8000 / dsi->data_rate + 0x01;
-	lpx = 5;
-
-	timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
-	timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
-		  (4 * lpx);
-	timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
-		  (NS_TO_CYCLE(0x150, cycle_time) << 16);
-	timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
-		   NS_TO_CYCLE(0x40, cycle_time);
-
-	writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
-	writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
-	writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
-	writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
+	writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
+	writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
+	writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
+	writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
 }
 
 static void mtk_dsi_enable(struct mtk_dsi *dsi)
@@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 {
 	struct device *dev = dsi->dev;
 	int ret;
+	u64 bit_clock, total_bits;
+	u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+	u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
+	u32 ui, cycle_time;
 
 	if (++dsi->refcount != 1)
 		return 0;
 
+	switch (dsi->format) {
+	case MIPI_DSI_FMT_RGB565:
+		bit_per_pixel = 16;
+		break;
+	case MIPI_DSI_FMT_RGB666_PACKED:
+		bit_per_pixel = 18;
+		break;
+	case MIPI_DSI_FMT_RGB666:
+	case MIPI_DSI_FMT_RGB888:
+	default:
+		bit_per_pixel = 24;
+		break;
+	}
+	/**
+	 * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+	 * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+	 * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+	 *		  + Thstrail + Ths_exit + Ths_zero) /
+	 *		 (htotal * byte_per_pixel /lane_number)
+	 */
+	bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+	htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+		 dsi->vm.hsync_len;
+	htotal_bits = htotal * bit_per_pixel;
+
 	/**
-	 * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
-	 * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
-	 * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
-	 * we set mipi_ratio is 1.05.
+	 * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
 	 */
-	dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+	overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+			  (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+	overhead_bits = overhead_cycles * dsi->lanes * 8;
+	total_bits = htotal_bits + overhead_bits;
 
-	ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+	dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+					  htotal_bits * dsi->lanes);
+
+	ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
 	if (ret < 0) {
 		dev_err(dev, "Failed to set data rate: %d\n", ret);
 		goto err_refcount;
@@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
 
 	mtk_dsi_enable(dsi);
 	mtk_dsi_reset(dsi);
-	dsi_phy_timconfig(dsi);
+
+	ui = 1000 / dsi->data_rate + 0x01;
+	cycle_time = 8000 / dsi->data_rate + 0x01;
+
+	phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+	phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
+	phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
+		      (NS_TO_CYCLE(0x150, cycle_time) << 16);
+	phy_timing3 = (2 * LPX) << 16 |
+		      NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
+		      NS_TO_CYCLE(0x40, cycle_time);
+
+	dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
+			  phy_timing3);
 
 	return 0;
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Mugunthan V N @ 2016-10-25  5:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <038C6B01-8443-4321-9C65-BAC4095237D3@gmail.com>

On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>> > On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> > 
>> > Increase ADC reference clock from 3MHz to 24MHz so that the
>> > sampling rates goes up from 100K samples per second to 800K
>> > samples per second on AM335x and AM437x SoC.
>> > 
>> > Also increase opendelay for touchscreen configuration to
>> > equalize the increase in ADC reference clock frequency,
>> > which results in the same amount touch events reported via
>> > evtest on AM335x GP EVM.
>> > 
>> > Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> > ---
>> > 
>> > This patch depends on ADC DMA patch series [1]
>> > 
>> > Without DMA support, when ADC ref clock is set at 24MHz, I am
>> > seeing fifo overflow as CPU is not able to pull the ADC samples.
>> > This answers that DMA support is must for ADC to consume the
>> > samples generated at 24MHz with no open, step delay or
>> > averaging with patch [2].
>> > 
>> > Measured the performance with the iio_generic_buffer with the
>> > patch [3] applied
>> > 
>> > [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>> > [2] - http://pastebin.ubuntu.com/23357935/
>> > [3] - http://pastebin.ubuntu.com/23357939/
>> > 
>> > ---
>> > include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> > 
>> > diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> > index b9a53e0..96c4207 100644
>> > --- a/include/linux/mfd/ti_am335x_tscadc.h
>> > +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> > @@ -90,7 +90,7 @@
>> > /* Delay register */
>> > #define STEPDELAY_OPEN_MASK	(0x3FFFF << 0)
>> > #define STEPDELAY_OPEN(val)	((val) << 0)
>> > -#define STEPCONFIG_OPENDLY	STEPDELAY_OPEN(0x098)
> Wouldn?t this be better to add this to the devicetree?
> 
> 	ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> 	ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> 	ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;

For a touch screen, there is not need to change in these parameter
settings, so my opinion is to keep it as is. Or am I missing something?

Regards
Mugunthan V N

^ permalink raw reply

* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-25  6:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <086ab2fa-63ee-c5ab-2715-b2efd78270d7@ti.com>


> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> 
> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>> 
>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
>>>> sampling rates goes up from 100K samples per second to 800K
>>>> samples per second on AM335x and AM437x SoC.
>>>> 
>>>> Also increase opendelay for touchscreen configuration to
>>>> equalize the increase in ADC reference clock frequency,
>>>> which results in the same amount touch events reported via
>>>> evtest on AM335x GP EVM.
>>>> 
>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>> ---
>>>> 
>>>> This patch depends on ADC DMA patch series [1]
>>>> 
>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
>>>> This answers that DMA support is must for ADC to consume the
>>>> samples generated at 24MHz with no open, step delay or
>>>> averaging with patch [2].
>>>> 
>>>> Measured the performance with the iio_generic_buffer with the
>>>> patch [3] applied
>>>> 
>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>>>> [2] - http://pastebin.ubuntu.com/23357935/
>>>> [3] - http://pastebin.ubuntu.com/23357939/
>>>> 
>>>> ---
>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>> index b9a53e0..96c4207 100644
>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>> @@ -90,7 +90,7 @@
>>>> /* Delay register */
>>>> #define STEPDELAY_OPEN_MASK	(0x3FFFF << 0)
>>>> #define STEPDELAY_OPEN(val)	((val) << 0)
>>>> -#define STEPCONFIG_OPENDLY	STEPDELAY_OPEN(0x098)
>> Wouldn?t this be better to add this to the devicetree?
>> 
>> 	ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>> 	ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>> 	ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> 
> For a touch screen, there is not need to change in these parameter
> settings, so my opinion is to keep it as is. Or am I missing something?
I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen. 

Regards,
John
> 
> Regards
> Mugunthan V N

^ 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