* [PATCH 0/5] Reset Controller Nodes for TI Keystone platforms
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
This patch adds the reset controller nodes and the corresponding
reset data for TI Keystone 66AK2H, 66AK2L and 66AK2E SoCs. These
resets are for the DSPs on these SoCs, and are the last dependencies
before the keystone remoteproc driver can be added.
All these SoCs will use the ti-syscon-reset driver which is already
part of mainline kernel. The bindings for the same can be found in
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt file.
Note that the other Keystone 66AK2G SoC will use a different TI-SCI
based reset driver, so will be submitted separately once the TI-SCI
dependencies make it into mainline.
Patches are based on top of 4.10-rc1 plus the MSM-RAM DT node series
that you have already picked up. Patch 1 enable the Reset Framework
for Keystone platforms, and remaining patches add the required DT
nodes.
regards
Suman
Suman Anna (5):
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC node
ARM: dts: keystone-k2hk: Add PSC reset controller node
ARM: dts: keystone-k2l: Add PSC reset controller node
ARM: dts: keystone-k2e: Add PSC reset controller node
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 5 +++++
arch/arm/mach-keystone/Kconfig | 1 +
5 files changed, 55 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH 4/4] watchdog: coh901327_wdt: Use dev variable instead of pdev->dev
From: Linus Walleij @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-4-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Use a local dev variable instead of dereferencing pdev->dev several
> times in the probe function to make the code easier to read.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109193328.GO2630@atomide.com>
On 01/09/2017 11:33 AM, Tony Lindgren wrote:
> * Sarangdhar Joshi <spjoshi@codeaurora.org> [170105 14:01]:
>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>> firmware loading to parse the resource table before calling
>> rproc_boot(). However, as the resource table parsing has been
>> moved to rproc_boot(), there's no need to wait for the
>> asynchronous firmware loading completion. So, drop this.
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Tested-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>> ---
>>
>> This patch seems to be doing an independent clean up now. Hence
>> removing it from the series.
>>
>> Changes from v2:
>>
>> * Updated the subject line as per Suman's comment
>
> FYI, I already have v2 applied with subject:
>
> "soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread"
Oh great. Thanks a lot Tony.
Regards,
Sarang
>
> Tony
>
>
>> drivers/soc/ti/wkup_m3_ipc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
>> index 8823cc8..8bfa44b 100644
>> --- a/drivers/soc/ti/wkup_m3_ipc.c
>> +++ b/drivers/soc/ti/wkup_m3_ipc.c
>> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>> struct device *dev = m3_ipc->dev;
>> int ret;
>>
>> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
>> -
>> init_completion(&m3_ipc->sync_complete);
>>
>> ret = rproc_boot(m3_ipc->rproc);
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/6] arm64: dts: apq8016-sbc: add support to hdmi audio via adv7533
From: Stephen Boyd @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483536902-21450-3-git-send-email-srinivas.kandagatla@linaro.org>
On 01/04, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 08bd5eb..5ab277f 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -85,6 +85,7 @@
> pinctrl-names = "default","sleep";
> pinctrl-0 = <&adv7533_int_active &adv7533_switch_active>;
> pinctrl-1 = <&adv7533_int_suspend &adv7533_switch_suspend>;
> + #sound-dai-cells = <1>;
>
> ports {
> #address-cells = <1>;
> @@ -285,6 +286,15 @@
> qcom,audio-routing =
> "AMIC2", "MIC BIAS Internal2",
> "AMIC3", "MIC BIAS External1";
> + external-dai-link at 0 {
> + link-name = "ADV7533";
> + cpu { /* QUAT */
> + sound-dai = <&lpass MI2S_QUATERNARY>;
> + };
> + codec {
> + sound-dai = <&adv_bridge 0>;
> + };
> + };
>
> internal-codec-playback-dai-link at 0 { /* I2S - Internal codec */
> link-name = "WCD";
The spacing is weird here. Did the internal-codec get added
without tabs before?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/4] watchdog: coh901327_wdt: Use devm_ioremap_resource to map resources
From: Linus Walleij @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-3-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Map resources using devm_ioremap_resource() to simplify error handling.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/4] watchdog: coh901327_wdt: Keep clock enabled after loading driver
From: Linus Walleij @ 2017-01-09 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-2-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Enabling the clock before accessing chip registers and disabling it
> afterwards does not really make sense and only adds complexity to
> the driver. In addition to that, a comment int the driver suggests
> that it does not serve a useful purpose either.
>
> "The watchdog block is of course always clocked, the
> clk_enable()/clk_disable() calls are mainly for performing reference
> counting higher up in the clock hierarchy."
>
> Just keep the clock enabled instead.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/4] watchdog: coh901327_wdt: Simplify error handling in probe function
From: Linus Walleij @ 2017-01-09 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-1-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Checking if there is no error followed by a goto if there is one is
> confusing. Reverse the logic.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Tony Lindgren @ 2017-01-09 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483653615-24378-1-git-send-email-spjoshi@codeaurora.org>
* Sarangdhar Joshi <spjoshi@codeaurora.org> [170105 14:01]:
> The function wkup_m3_rproc_boot_thread waits for asynchronous
> firmware loading to parse the resource table before calling
> rproc_boot(). However, as the resource table parsing has been
> moved to rproc_boot(), there's no need to wait for the
> asynchronous firmware loading completion. So, drop this.
>
> CC: Dave Gerlach <d-gerlach@ti.com>
> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> Tested-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
>
> This patch seems to be doing an independent clean up now. Hence
> removing it from the series.
>
> Changes from v2:
>
> * Updated the subject line as per Suman's comment
FYI, I already have v2 applied with subject:
"soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread"
Tony
> drivers/soc/ti/wkup_m3_ipc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
> index 8823cc8..8bfa44b 100644
> --- a/drivers/soc/ti/wkup_m3_ipc.c
> +++ b/drivers/soc/ti/wkup_m3_ipc.c
> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
> struct device *dev = m3_ipc->dev;
> int ret;
>
> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
> -
> init_completion(&m3_ipc->sync_complete);
>
> ret = rproc_boot(m3_ipc->rproc);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> 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 v4 1/9] clk: stm32f4: Update DT bindings documentation
From: Stephen Boyd @ 2017-01-09 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ccd14adb-9d10-ae9e-de6d-565418421968@st.com>
On 01/09, Alexandre Torgue wrote:
> Hi Stephen,
>
> On 12/22/2016 01:10 AM, Stephen Boyd wrote:
> >On 12/13, gabriel.fernandez at st.com wrote:
> >>From: Gabriel Fernandez <gabriel.fernandez@st.com>
> >>
> >>Creation of dt include file for specific stm32f4 clocks.
> >>These specific clocks are not derived from system clock (SYSCLOCK)
> >>We should use index 1 to use these clocks in DT.
> >>e.g. <&rcc 1 CLK_LSI>
> >>
> >>Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> >>Acked-by: Rob Herring <robh@kernel.org>
> >>---
> >
> >Applied to clk-stm32f4 and merged into clk-next.
> >
>
> I'm preparing pull request branch for STM32 DT part. This patch is
> also requested to build correctly DT patches. Do you know how could
> we synchronize our pull request ?
>
clk-stm32f4 is stable and not going to be rebased, so you're good
to base patches on it and send it off to arm-soc if the arm-soc
maintainers agree to it. You can also base off an earlier part of
the branch if you only need this first patch for example.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2.1 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Kevin Hilman @ 2017-01-09 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f3cdadf0-b0e9-9956-145a-9cc22024f6f9@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> Hi Kevin,
>
> On Thursday 08 December 2016 05:44 AM, Kevin Hilman wrote:
>> Add VPIF node an pins to da850 and enable on boards. VPIF has two input
>> channels described using the standard DT ports and enpoints.
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> ---
>> v2 -> v2.1: moved ports from SoC .dtsi to board .dts files.
>>
>> arch/arm/boot/dts/da850-evm.dts | 20 ++++++++++++++++++++
>> arch/arm/boot/dts/da850-lcdk.dts | 13 +++++++++++++
>> arch/arm/boot/dts/da850.dtsi | 27 ++++++++++++++++++++++++++-
>> 3 files changed, 59 insertions(+), 1 deletion(-)
>
> Can you split this patch to keep the SoC addition separate from board
> updates. Separating support addition for EVM and LCDK will be good also.
I don't understand why that matters, but OK.
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b91c680..5f0b40510b2b 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>
>> @@ -399,7 +410,21 @@
>> <&edma0 0 1>;
>> dma-names = "tx", "rx";
>> };
>> +
>> + vpif: video at 217000 {
>> + compatible = "ti,da850-vpif";
>> + reg = <0x217000 0x1000>;
>> + interrupts = <92>;
>> + status = "disabled";
>> +
>> + /* VPIF capture port */
>> + port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> + };
>
> Can you add this node just above mmc1? I am trying to keep the nodes
> sorted in the order of unit address instead of new ones getting added at
> the end. Unfortunately, it was not strictly enforced and we have many
> breakages. But lets add the new ones where they will eventually end up.
OK.
Kevin
^ permalink raw reply
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-09 19:28 UTC (permalink / raw)
To: linux-arm-kernel
Fix couple of typos in the example given in the TI syscon reset
binding. The ti,reset-bits used for DSP0 are corrected to match
the values that will be used in the actual DT node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
Hi Philipp,
This is the Documentation part fix that goes along with
the ti-syscon-reset fix that you have on your next branch.
I will be submitting the DT nodes very soon
regards
Suman
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 164c7f34c451..21ba739b162e 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -63,7 +63,7 @@ Example:
--------
The following example demonstrates a syscon node, the reset controller node
using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
-Edison SoC.
+66AK2E SoC.
/ {
soc {
@@ -71,13 +71,13 @@ Edison SoC.
compatible = "syscon", "simple-mfd";
reg = <0x02350000 0x1000>;
- pscrst: psc-reset {
+ pscrst: psc-reset-controller {
compatible = "ti,k2e-pscrst", "ti,syscon-reset";
#reset-cells = <1>;
ti,reset-bits = <
- 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_SET|DEASSERT_CLEAR|STATUS_SET) /* 0: pcrst-dsp0 */
- 0xa40 5 0xa44 3 0 0 (ASSERT_SET|DEASSERT_CLEAR|STATUS_NONE) /* 1: pcrst-example */
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 5 0xa44 3 0 0 (ASSERT_SET | DEASSERT_CLEAR | STATUS_NONE) /* 1: example */
>;
};
};
--
2.10.2
^ permalink raw reply related
* [RFC PATCH 1/5] regulator: Extend the power-management APIs
From: Mark Brown @ 2017-01-09 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480687036-5037-2-git-send-email-boris.brezillon@free-electrons.com>
On Fri, Dec 02, 2016 at 02:57:12PM +0100, Boris Brezillon wrote:
> The idea to solve #2 is to allow runtime changes. Since this kind of
> change is likely to have an impact on the whole system, we require the
> board to explicitly state that runtime changes are allowed (using a DT
> property).
> Allowing runtime changes, may also be a problem if devices are not
> suspended in the correct order: a device using a regulator should be
> suspended before the regulator itself, otherwise we may change the
> regulator state while it's still being used.
> Hopefully, this problem will be solved with the work done on device
> dependency description.
I'm not sure that adding an extra property is going to help with the
problems here - the system already has to provide explicit support for
setting the suspend configuration so that should be enough. However it
*is* a bit more than just making sure that the device suspend ordering
is good (though that's definitely part of it), there will be things
kicked off by hardware signalling without software knowing about it.
Anything that doesn't affect a hardware supported runtime state probably
needs to be split off and handled separately as that's the much more
risky bit, moving changing of suspend mode earlier isn't going to cause
too much grief, that patch should just be split out and can probably
just go straight in.
> + * This function should be called from the regulator driver ->suspend() hook
> + * and after the platform has called regulator_suspend_begin() to properly set
> + * the rdev->suspend.target field.
Requring these functions to be called from every single driver seems
like we're doing something wrong - if we're going to do this we should
find some way to loop over all regulators and apply any unapplied
changes. Batching things up at the end of suspend would also mean that
we'd be able to minimise the chances that we get the ordering wrong.
For the target bit... we should be able to find some way to figure out
what kind of suspend we're doing without the platform being involved, a
callback from the PM core would be helpful here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170109/6ac2c655/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-09 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483945344-3125-1-git-send-email-zhengxing@rock-chips.com>
Hi,
On Sun, Jan 8, 2017 at 11:02 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
This looks sane to me, but before you land it you need to first send
up a (separate) patch that adjusts:
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
...it would also be sorta nice if you included an a patch in your
series that actually uses this new functionality.
-Doug
^ permalink raw reply
* [PATCH v2 4/4] dmaengine: pl330: Don't require irq-safe runtime PM
From: Krzysztof Kozlowski @ 2017-01-09 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483970598-6191-5-git-send-email-m.szyprowski@samsung.com>
On Mon, Jan 09, 2017 at 03:03:18PM +0100, Marek Szyprowski wrote:
> This patch replaces irq-safe runtime PM with non-irq-safe version based on
> the new approach. Existing, irq-safe runtime PM implementation for PL330 was
> not bringing much benefits of its own - only clocks were enabled/disabled.
>
> Till now non-irq-safe runtime PM implementation was only possible by calling
> pm_runtime_get/put functions from alloc/free_chan_resources. All other DMA
> engine API functions cannot be called from a context, which permits sleeping.
> Such implementation, in practice would result in keeping DMA controller's
> device active almost all the time, because most of the slave device drivers
> (DMA engine clients) acquire DMA channel in their probe() function and
> released it during driver removal.
>
> This patch provides a new, different approach. It is based on an observation
> that there can be only one slave device using each DMA channel. PL330 hardware
> always has dedicated channels for each peripheral device. Using recently
> introduced device dependencies (links) infrastructure one can ensure proper
> runtime PM state of PL330 DMA controller basing on the runtime PM state of
> the slave device.
>
> In this approach in pl330_alloc_chan_resources() function a new dependency
> is being created between PL330 DMA controller device (as a supplier) and
> given slave device (as a consumer). This way PL330 DMA controller device
> runtime active counter is increased when the slave device is resumed and
> decreased the same time when given slave device is put to suspend. This way
> it has been ensured to keep PL330 DMA controller runtime active if there is
> an active used of any of its DMA channels. Slave device pointer is initially
> stored in per-channel data in of_dma_xlate callback. This is similar to what
> has been already implemented in Exynos IOMMU driver in commit 2f5f44f205cc95
> ("iommu/exynos: Use device dependency links to control runtime pm").
>
> If slave device doesn't implement runtime PM or keeps device runtime active
> all the time, then PL330 DMA controller will be runtime active all the time
> when channel is being allocated. The goal is however to have runtime PM
> added to all devices in the system, because it lets respective power
> domains to be turned off, what gives the best results in terms of power
> saving.
>
> If one requests memory-to-memory channel, runtime active counter is
> increased unconditionally. This might be a drawback of this approach, but
> PL330 is not really used for memory-to-memory operations due to poor
> performance in such operations compared to the CPU.
>
> Introducing non-irq-safe runtime power management finally allows to turn off
> audio power domain on Exynos5 SoCs.
>
> Removal of irq-safe runtime PM is based on the revert of the following
> commits:
> 1. "dmaengine: pl330: fix runtime pm support" commit
> 5c9e6c2b2ba3ec3a442e2fb5b4286498f8b4dcb7
> 2. "dmaengine: pl330: Fix hang on dmaengine_terminate_all on certain boards"
> commit 81cc6edc08705ac0146fe6ac14a0982a31ce6f3d
> 3. "ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12"
> commit ae43b3289186480f81c78bb63d788a85a3631f47
Checkpatch will complain here. I think following standard pattern of
'commit XYZ ("abc")' makes sense.
Beside that, one not important remark below.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/dma/pl330.c | 124 ++++++++++++++++++++++++++--------------------------
> 1 file changed, 61 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 9c72f535739c..2cffbb44b09e 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -268,9 +268,6 @@ enum pl330_byteswap {
>
> #define NR_DEFAULT_DESC 16
>
> -/* Delay for runtime PM autosuspend, ms */
> -#define PL330_AUTOSUSPEND_DELAY 20
> -
> /* Populated by the PL330 core driver for DMA API driver's info */
> struct pl330_config {
> u32 periph_id;
> @@ -449,8 +446,8 @@ struct dma_pl330_chan {
> bool cyclic;
>
> /* for runtime pm tracking */
> - bool active;
> struct device *slave;
> + struct device_link *slave_link;
> };
>
> struct pl330_dmac {
> @@ -2016,7 +2013,6 @@ static void pl330_tasklet(unsigned long data)
> struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
> struct dma_pl330_desc *desc, *_dt;
> unsigned long flags;
> - bool power_down = false;
>
> spin_lock_irqsave(&pch->lock, flags);
>
> @@ -2031,18 +2027,10 @@ static void pl330_tasklet(unsigned long data)
> /* Try to submit a req imm. next to the last completed cookie */
> fill_queue(pch);
>
> - if (list_empty(&pch->work_list)) {
> - spin_lock(&pch->thread->dmac->lock);
> - _stop(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - power_down = true;
> - pch->active = false;
> - } else {
> - /* Make sure the PL330 Channel thread is active */
> - spin_lock(&pch->thread->dmac->lock);
> - _start(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - }
> + /* Make sure the PL330 Channel thread is active */
> + spin_lock(&pch->thread->dmac->lock);
> + _start(pch->thread);
> + spin_unlock(&pch->thread->dmac->lock);
>
> while (!list_empty(&pch->completed_list)) {
> struct dmaengine_desc_callback cb;
> @@ -2055,13 +2043,6 @@ static void pl330_tasklet(unsigned long data)
> if (pch->cyclic) {
> desc->status = PREP;
> list_move_tail(&desc->node, &pch->work_list);
> - if (power_down) {
> - pch->active = true;
> - spin_lock(&pch->thread->dmac->lock);
> - _start(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - power_down = false;
> - }
> } else {
> desc->status = FREE;
> list_move_tail(&desc->node, &pch->dmac->desc_pool);
> @@ -2076,12 +2057,6 @@ static void pl330_tasklet(unsigned long data)
> }
> }
> spin_unlock_irqrestore(&pch->lock, flags);
> -
> - /* If work list empty, power down */
> - if (power_down) {
> - pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
> - pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
> - }
> }
>
> bool pl330_filter(struct dma_chan *chan, void *param)
> @@ -2125,11 +2100,52 @@ static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
> return dma_get_slave_channel(&pl330->peripherals[chan_id].chan);
> }
>
> +static int pl330_add_slave_link(struct pl330_dmac *pl330,
> + struct dma_pl330_chan *pch)
> +{
> + struct device_link *link;
> + int i;
> +
> + if (pch->slave_link)
> + return 0;
> +
> + link = device_link_add(pch->slave, pl330->ddma.dev,
> + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
Align the arguments with open parenthesis?
Anyway, nice job!
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c35bd06d-f012-1289-e765-02dc26b87e27@gmail.com>
On 09/01/17 19:45, Matthias Brugger wrote:
>
>
> On 09/01/17 12:29, Hans Verkuil wrote:
>> Hi Rick,
>>
>> On 01/06/2017 03:34 AM, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you
>>> have
>>> any idea about this patch series? Should we wait for [2] or we could
>>> merge
>>> the source code and dt-binding first?
>>
>> Looking at [2] I noticed that the last comment was July 4th. What is
>> the reason
>> it hasn't been merged yet?
>>
>> If I know [2] will be merged for 4.11, then I am fine with merging
>> this media
>> patch series. The dependency of this patch on [2] is something Mauro
>> can handle.
>>
>> If [2] is not merged for 4.11, then I think it is better to wait until
>> it is
>> merged.
>>
>
> I can't take [2] because there is no scpsys in the dts present. It seems
> that it got never posted.
>
> Rick can you please follow-up with James and provide a patch which adds
> a scpsys node to the mt2701.dtsi?
>
Ah I forgot, dts patches should go through my tree, so Hans please don't
merge this patch. Bindings should go through your branch though.
Thanks,
Matthias
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <974d20f3-5133-0869-2a35-c1617bec5d6e@xs4all.nl>
On 09/01/17 12:29, Hans Verkuil wrote:
> Hi Rick,
>
> On 01/06/2017 03:34 AM, Rick Chang wrote:
>> Hi Hans,
>>
>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>> any idea about this patch series? Should we wait for [2] or we could merge
>> the source code and dt-binding first?
>
> Looking at [2] I noticed that the last comment was July 4th. What is the reason
> it hasn't been merged yet?
>
> If I know [2] will be merged for 4.11, then I am fine with merging this media
> patch series. The dependency of this patch on [2] is something Mauro can handle.
>
> If [2] is not merged for 4.11, then I think it is better to wait until it is
> merged.
>
I can't take [2] because there is no scpsys in the dts present. It seems
that it got never posted.
Rick can you please follow-up with James and provide a patch which adds
a scpsys node to the mt2701.dtsi?
Thanks,
Matthias
^ permalink raw reply
* [PATCH 2/3] doc: binding: add new compatible for SDRAM/DDR Controller
From: Rob Herring @ 2017-01-09 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106065947.30631-3-wenyou.yang@atmel.com>
On Fri, Jan 06, 2017 at 02:59:46PM +0800, Wenyou Yang wrote:
> Add the new compatible "atmel,sama5d4-ddramc" for the SDRAM/DDR
> Controller.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> ---
>
> Documentation/devicetree/bindings/arm/atmel-at91.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCHv3 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Rob Herring @ 2017-01-09 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106041517.9589-5-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 06, 2017 at 05:15:01PM +1300, Chris Packham wrote:
> The Marvell 98DX3236, 98DX3336, 98DX4521 and variants are switch ASICs
> with integrated CPUs. They are similar to the Armada XP SoCs but have
> different I/O interfaces.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - Update devicetree binding documentation to reflect that 98DX3336 and
> 984251 are supersets of 98DX3236.
> - disable crypto block
> - disable sdio for 98DX3236, enable for 98DX4251
> Changes in v3:
> - fix typo 4521 -> 4251
> - document prestera bindings
> - rework corediv-clock binding
> - add label to packet processor node
> - add new compativle string for DFX server
>
> .../devicetree/bindings/arm/marvell/98dx3236.txt | 23 ++
> .../devicetree/bindings/net/marvell,prestera.txt | 50 ++++
> arch/arm/boot/dts/armada-xp-98dx3236.dtsi | 254 +++++++++++++++++++++
> arch/arm/boot/dts/armada-xp-98dx3336.dtsi | 76 ++++++
> arch/arm/boot/dts/armada-xp-98dx4251.dtsi | 90 ++++++++
> 5 files changed, 493 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236.txt
> create mode 100644 Documentation/devicetree/bindings/net/marvell,prestera.txt
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3236.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx3336.dtsi
> create mode 100644 arch/arm/boot/dts/armada-xp-98dx4251.dtsi
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCHv3 3/5] pinctrl: mvebu: pinctrl driver for 98DX3236 SoC
From: Rob Herring @ 2017-01-09 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106041517.9589-4-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 06, 2017 at 05:15:00PM +1300, Chris Packham wrote:
> From: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
>
> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
> from Marvell.
>
> Signed-off-by: Kalyan Kinthada <kalyan.kinthada@alliedtelesis.co.nz>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - include sdio support for the 98DX4251
> Changes in v3:
> - None
>
> .../pinctrl/marvell,armada-98dx3236-pinctrl.txt | 46 ++++++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/mvebu/pinctrl-armada-xp.c | 155 +++++++++++++++++++++
> 2 files changed, 201 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/marvell,armada-98dx3236-pinctrl.txt
^ permalink raw reply
* [PATCHv3 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Rob Herring @ 2017-01-09 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106041517.9589-3-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 06, 2017 at 05:14:59PM +1300, Chris Packham wrote:
> Compared to the armada-xp the 98DX3336 uses different registers to set
> the boot address for the secondary CPU so a new enable-method is needed.
> This will only work if the machine definition doesn't define an overall
> smp_ops because there is not currently a way of overriding this from the
> device tree if it is set in the machine definition.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - Document new enable-method value
> - Correct some references from 98DX4521 to 98DX3236
>
> Changes in v3:
> - Simplify mv98dx3236_resume_init by using of_io_request_and_map()
>
> Documentation/devicetree/bindings/arm/cpus.txt | 1 +
> .../bindings/arm/marvell/98dx3236-resume-ctrl.txt | 18 ++++++++
Acked-by: Rob Herring <robh@kernel.org>
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/mach-mvebu/common.h | 1 +
> arch/arm/mach-mvebu/platsmp.c | 43 ++++++++++++++++++
> arch/arm/mach-mvebu/pmsu-98dx3236.c | 52 ++++++++++++++++++++++
> 6 files changed, 116 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt
> create mode 100644 arch/arm/mach-mvebu/pmsu-98dx3236.c
^ permalink raw reply
* [PATCHv3 1/5] clk: mvebu: support for 98DX3236 SoC
From: Rob Herring @ 2017-01-09 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106041517.9589-2-chris.packham@alliedtelesis.co.nz>
On Fri, Jan 06, 2017 at 05:14:58PM +1300, Chris Packham wrote:
> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>
> The clock gating options are a subset of those on the Armada XP.
>
> The core clock divider is different to the Armada XP also.
>
> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - Update devicetree binding documentation for new compatible string
>
> Changes in v3:
> - Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
> driver.
> - Document mv98dx3236-corediv-clock binding
>
> .../bindings/clock/mvebu-corediv-clock.txt | 1 +
> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
Acked-by: Rob Herring <robh@kernel.org>
> drivers/clk/mvebu/armada-xp.c | 42 ++++++++++++++++++++++
> drivers/clk/mvebu/clk-corediv.c | 23 ++++++++++++
> drivers/clk/mvebu/clk-cpu.c | 31 ++++++++++++++--
> 5 files changed, 96 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Krzysztof Kozlowski @ 2017-01-09 18:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgR7=cELNK9of5ngFTdhcxWn2KXL=R8tMsTKD7gecBcMYw@mail.gmail.com>
On Mon, Jan 09, 2017 at 11:56:41PM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 9 January 2017 at 23:47, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
> >> Hi Krzysztof,
> >>
> >> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> > Hi,
> >> >
> >> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
> >> > Chen, we got a power sequence generic library which solves my long
> >> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
> >> >
> >> > My previous attempts for this can be found here [0].
> >> >
> >> > This patchset is based on Peter's v11 of power sequence [1].
> >> > Patchset is available also on my Github [2].
> >> >
> >> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
> >> > LAN9730 on Odroid U3 after tftpboot").
> >> >
> >> >
> >>
> >> [snip]
> >>
> >> On which u-boot should this be tested.
> >>
> >> On HK u-boot tftp boot is not supported.
> >
> > ... so you gave an answer: you cannot test it on HK. How many other
> > U-Boot flavors you know? :)
> >
>
> u-boot mainline have tftp support enable, so I will try to test on this u-boot.
Yes, please try it. Some time ago I was using v2016.03-rc3 and now
recent (~40 commits after v2017.01-rc2). Both are working fine however
the configuration (partitions, default env settings etc) differs from HK
so migration was not straightforward.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 11/12] crypto: atmel-authenc: add support to authenc(hmac(shaX), Y(aes)) modes
From: Stephan Müller @ 2017-01-09 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6301d79c-f1c5-d86c-823c-dfdbb5100e74@atmel.com>
Am Montag, 9. Januar 2017, 19:24:12 CET schrieb Cyrille Pitchen:
Hi Cyrille,
> >> +static int atmel_aes_authenc_copy_assoc(struct aead_request *req)
> >> +{
> >> + size_t buflen, assoclen = req->assoclen;
> >> + off_t skip = 0;
> >> + u8 buf[256];
> >> +
> >> + while (assoclen) {
> >> + buflen = min_t(size_t, assoclen, sizeof(buf));
> >> +
> >> + if (sg_pcopy_to_buffer(req->src, sg_nents(req->src),
> >> + buf, buflen, skip) != buflen)
> >> + return -EINVAL;
> >> +
> >> + if (sg_pcopy_from_buffer(req->dst, sg_nents(req->dst),
> >> + buf, buflen, skip) != buflen)
> >> + return -EINVAL;
> >> +
> >> + skip += buflen;
> >> + assoclen -= buflen;
> >> + }
> >
> > This seems to be a very expansive operation. Wouldn't it be easier, leaner
> > and with one less memcpy to use the approach of
> > crypto_authenc_copy_assoc?
> >
> > Instead of copying crypto_authenc_copy_assoc, what about carving the logic
> > in crypto/authenc.c out into a generic aead helper code as we need to add
> > that to other AEAD implementations?
>
> Before writing this function, I checked how the crypto/authenc.c driver
> handles the copy of the associated data, hence crypto_authenc_copy_assoc().
>
> I have to admit I didn't perform any benchmark to compare the two
> implementation but I just tried to understand how
> crypto_authenc_copy_assoc() works. At the first look, this function seems
> very simple but I guess all the black magic is hidden by the call of
> crypto_skcipher_encrypt() on the default null transform, which is
> implemented using the ecb(cipher_null) algorithm.
The magic in the null cipher is that it not only performs a memcpy, but
iterates through the SGL and performs a memcpy on each part of the source/
destination SGL.
I will release a patch set later today -- the coding is completed, but testing
is yet under way. That patch now allows you to make only one function call
without special init/deinit code.
>
> When I wrote my function I thought that this ecb(cipher_null) algorithm was
> implemented by combining crypto_ecb_crypt() from crypto/ecb.c with
> null_crypt() from crypto/crypto_null.c. Hence I thought there would be much
> function call overhead to copy only few bytes but now checking again I
> realize that the ecb(cipher_null) algorithm is directly implemented by
> skcipher_null_crypt() still from crypto/crypto_null.c. So yes, maybe you're
> right: it could be better to reuse what was done in
> crypto_authenc_copy_assoc() from crypto/authenc.c.
>
> This way we could need twice less memcpy() hence I agree with you.
In addition to the additional memcpy, the patch I want to air shortly (and
which I hope is going to be accepted) should reduce the complexity of your
code in this corner.
...
> >> +static int atmel_aes_authenc_crypt(struct aead_request *req,
> >> + unsigned long mode)
> >> +{
> >> + struct atmel_aes_authenc_reqctx *rctx = aead_request_ctx(req);
> >> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> >> + struct atmel_aes_base_ctx *ctx = crypto_aead_ctx(tfm);
> >> + u32 authsize = crypto_aead_authsize(tfm);
> >> + bool enc = (mode & AES_FLAGS_ENCRYPT);
> >> + struct atmel_aes_dev *dd;
> >> +
> >> + /* Compute text length. */
> >> + rctx->textlen = req->cryptlen - (enc ? 0 : authsize);
> >
> > Is there somewhere a check that authsize is always < req->cryptlen (at
> > least it escaped me)? Note, this logic will be exposed to user space
> > which may do funky things.
>
> I thought those 2 sizes were always set by the kernel only but I admit I
> didn't check my assumption. If you tell me they could be set directly from
> the userspace, yes I agree with you, I need to add a test.
Then I would like to ask you adding that check -- as this check is cheap, it
should not affect performance.
Ciao
Stephan
^ permalink raw reply
* [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-09 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483632384-8107-2-git-send-email-sean.wang@mediatek.com>
On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> This patch adds documentation for devicetree bindings for
> Mediatek IR controller.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> .../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
> new file mode 100644
> index 0000000..bbedd71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
> @@ -0,0 +1,23 @@
> +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
> +
> +Required properties:
> +- compatible : "mediatek,mt7623-ir"
> +- clocks : list of clock specifiers, corresponding to
> + entries in clock-names property;
> +- clock-names : should contain "clk" entries;
> +- interrupts : should contain IR IRQ number;
> +- reg : should contain IO map address for IR.
> +
> +Optional properties:
> +- linux,rc-map-name : Remote control map name.
Would 'label' be appropriate here instead? If not, this needs to be
documented in a common location and explained better.
> +
> +Example:
> +
> +cir: cir at 0x10013000 {
Drop the '0x'.
> + compatible = "mediatek,mt7623-ir";
> + reg = <0 0x10013000 0 0x1000>;
> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_IRRX>;
> + clock-names = "clk";
> + linux,rc-map-name = "rc-rc6-mce";
> +};
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH 0/4] ARM: exynos: Fix Odroid U3 USB/LAN when TFTP booting (power sequence)
From: Anand Moon @ 2017-01-09 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109181703.436gv7bq76xuv35q@kozik-lap>
Hi Krzysztof,
On 9 January 2017 at 23:47, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Mon, Jan 09, 2017 at 11:34:48PM +0530, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 7 January 2017 at 14:21, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > Hi,
>> >
>> > Thanks to Markus Reichl, I got an Odroid U3 to work with. Thanks to Peter
>> > Chen, we got a power sequence generic library which solves my long
>> > standing Odroid U3 problem - no LAN9730 if it was enabled by bootloader.
>> >
>> > My previous attempts for this can be found here [0].
>> >
>> > This patchset is based on Peter's v11 of power sequence [1].
>> > Patchset is available also on my Github [2].
>> >
>> > More detailed analysis is described in patch 2/4 ("ARM: dts: exynos: Fix
>> > LAN9730 on Odroid U3 after tftpboot").
>> >
>> >
>>
>> [snip]
>>
>> On which u-boot should this be tested.
>>
>> On HK u-boot tftp boot is not supported.
>
> ... so you gave an answer: you cannot test it on HK. How many other
> U-Boot flavors you know? :)
>
u-boot mainline have tftp support enable, so I will try to test on this u-boot.
Best Regards
-Anand
> Best regards,
> Krzysztof
>
>
>> ----------------------------------------------------------
>> U-Boot 2010.12-00000-g9777ca6-dirty (Nov 26 2015 - 10:10:11) for Exynox4412
>>
>>
>> CPU: S5PC220 [Samsung SOC on SMP Platform Base on ARM CortexA9]
>> APLL = 1000MHz, MPLL = 800MHz
>> DRAM: 2 GiB
>>
>> PMIC VERSION : 0x00, CHIP REV : 2
>> TrustZone Enabled BSP
>> BL1 version: 20121128
>>
>>
>> Checking Boot Mode ... SDMMC
>> MMC Device 0: 14804 MB
>> MMC Device 1 not found
>> *** Warning - using default environment
>>
>> USB3503 NINT = OUTPUT LOW!
>> ModeKey Check... run normal_boot
>> No ethernet found.
>> Hit any key to stop autoboot: 0
>> Exynos4412 #
>> Exynos4412 #
>> Exynos4412 #
>> Exynos4412 # usb start
>> (Re)start USB...
>> USB0: Exynos4412-ehci: init hccr 12580000 and hcor 12580010 hc_length 16
>> usb: usb_refclk_enable is active low: NO
>> ProTIP: If usb doesn't work - try playing with 'usb_invert_clken' environment
>> USB EHCI 1.00
>> scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80
>> EHCI fail timeout STS_ASS set
>>
>> USB device not accepting new address (error=80000000)
>> EHCI fail timeout STS_ASS set
>> 1 USB Device(s) found
>> scanning usb for storage devices... 0 Storage Device(s) found
>> scanning usb for ethernet devices... 0 Ethernet Device(s) found
>> Exynos4412 #
>>
>> Best Regards
>> -Anand
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox