* [PATCH 1/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-29 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229084211.20442-2-andi.shyti@samsung.com>
On Thu, Dec 29, 2016 at 05:42:08PM +0900, Andi Shyti wrote:
> Commit 5db7e3bb87df ("pinctrl: dt-bindings: samsung: Add header with
> values used for configuration") has added a header file for defining the
> pinctrl values in order to avoid hardcoded settings in the Exynos
> DTS related files.
>
> Extend samsung.h to the Exynos5433 for drive strength values
> which are strictly related to the particular SoC and may defer
> from others.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> include/dt-bindings/pinctrl/samsung.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/dt-bindings/pinctrl/samsung.h b/include/dt-bindings/pinctrl/samsung.h
> index 6276eb785e2b..58868313d64b 100644
> --- a/include/dt-bindings/pinctrl/samsung.h
> +++ b/include/dt-bindings/pinctrl/samsung.h
> @@ -45,6 +45,12 @@
> #define EXYNOS5420_PIN_DRV_LV3 2
> #define EXYNOS5420_PIN_DRV_LV4 3
>
> +/* Drive strengths for Exynos5433 */
> +#define EXYNOS5433_PIN_DRV_LV1 0
> +#define EXYNOS5433_PIN_DRV_LV2 1
> +#define EXYNOS5433_PIN_DRV_LV3 2
> +#define EXYNOS5433_PIN_DRV_LV4 3
Same values as existing. No need to re-define these.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/4] ARM64: dts: exynos5433: remove unused code
From: Krzysztof Kozlowski @ 2016-12-29 11:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229084211.20442-5-andi.shyti@samsung.com>
On Thu, Dec 29, 2016 at 05:42:11PM +0900, Andi Shyti wrote:
> Because the pinctrl DTS is using the samsung.h macros, the
> previously pin defines are anused. Remove them.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 13 -------------
> 1 file changed, 13 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> index 9afed9fcf7e1..3c821e5c241e 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> @@ -14,19 +14,6 @@
>
> #include <dt-bindings/pinctrl/samsung.h>
>
> -#define PIN_PULL_NONE 0
> -#define PIN_PULL_DOWN 1
> -#define PIN_PULL_UP 3
> -
> -#define PIN_DRV_LV1 0
> -#define PIN_DRV_LV2 2
> -#define PIN_DRV_LV3 1
> -#define PIN_DRV_LV4 3
> -
> -#define PIN_IN 0
> -#define PIN_OUT 1
> -#define PIN_FUNC1 2
> -
This should be squashed with 3/4 because logically it is strictly
related to it and splitting it does not bring any benefits. Actually
while looking at 3/4 I was surprised to see them not removed.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ARM: dts: qcom: apq8064: Add missing scm clock
From: Bjorn Andersson @ 2016-12-29 12:06 UTC (permalink / raw)
To: linux-arm-kernel
As per the device tree binding the apq8064 scm node requires the core
clock to be specified, so add this.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v1:
- Changed clock to Daytona Fabric
arch/arm/boot/dts/qcom-apq8064.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 1dbe697b2e90..a27cc96ac069 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/clock/qcom,gcc-msm8960.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include <dt-bindings/clock/qcom,mmcc-msm8960.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/soc/qcom,gsbi.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -303,6 +304,9 @@
firmware {
scm {
compatible = "qcom,scm-apq8064";
+
+ clocks = <&rpmcc RPM_DAYTONA_FABRIC_CLK>;
+ clock-names = "core";
};
};
--
2.11.0
^ permalink raw reply related
* Linux fails to start secondary cores when system resumes from Suspend-to-RAM
From: Mason @ 2016-12-29 12:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c3c6592-1e9a-10d3-2a89-c22a2a23cf4b@free.fr>
On 16/12/2016 08:25, Mason wrote:
> On 16/12/2016 06:14, Yu Chen wrote:
>
>> On Thu, Dec 15, 2016 at 11:18 PM, Mason wrote:
>>
>>> I'm playing with suspend-to-RAM on the tango platform:
>>>
>>> http://lxr.free-electrons.com/source/arch/arm/mach-tango/platsmp.c
>>>
>>> When the system is suspended, the CPU is completely powered down
>>> (receives no power whatsoever). When the system receives a wake-up
>>> event, the CPU is powered up, and starts up exactly the same way
>>> as for a cold boot (I think).
>>>
>>> However, while Linux successfully starts the secondary cores when
>>> the system first boots, it fails when the system resumes from "S3".
>>>
>>> I added printascii() calls inside secondary_start_kernel() and I can
>>> see that the following instruction are "properly" run:
>>>
>>> cpu_switch_mm(mm->pgd, mm);
>>> local_flush_bp_all();
>>> enter_lazy_tlb(mm, current);
>>>
>>> but it seems local_flush_tlb_all(); never returns... :-(
>>>
>>> http://lxr.free-electrons.com/source/arch/arm/include/asm/tlbflush.h#L332
>>>
>>>
>>> Looking more closely at that function, it seems to be failing in:
>>>
>>> tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
>>>
>>> (meaning: I get a log before, but not after)
>>>
>>> On my system, tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
>>> resolves to:
>>>
>>> c010ce18: e3170602 tst r7, #2097152 ; 0x200000
>>> c010ce1c: 1e086f17 mcrne 15, 0, r6, cr8, cr7, {0}
>>>
>>> What could be happening?
>>> Can a core "hang" on this instruction?
>>> Can a core "crash" on this instruction (meaning, an exception
>>> is raised, and the core loops inside the exception code without
>>> Linux noticing... that seems unlikely)
>>
>> try online/offline the nonboot CPUs via
>> /sys/devices/system/cpu/cpuX/online
>
> offline + online secondary core works.
>
> Note: all cores are in the same power domain, so even if all
> secondary cores are offline, the CPU block remains powered up
> (secondary cores are just held in reset, or spinning in WFI,
> depending on the firmware version).
>
> When the system is suspended, the CPU block (as well as 99%
> of the system) is powered down. Thus, upon resume, all cores
> will run the boot sequence (again).
>
> I'm guessing that something goes wrong during this second
> boot sequence. Could there be a race condition between the
> primary core and one of the secondary cores?
>
> What is different in the Linux boot sequence between cold
> boot and resume? I'm thinking that the state stored in RAM
> is in fact incompatible with what Linux expects when it resumes...
I've taken a closer look at the MCR instruction.
tlb_op(TLB_V7_UIS_FULL, "c8, c7, 0", zero);
#define tlb_op(f, regs, arg) __tlb_op(f, "p15, 0, %0, " regs, arg)
#define __tlb_op(f, insnarg, arg) \
do { \
if (always_tlb_flags & (f)) \
asm("mcr " insnarg \
: : "r" (arg) : "cc"); \
else if (possible_tlb_flags & (f)) \
asm("tst %1, %2\n\t" \
"mcrne " insnarg \
: : "r" (arg), "r" (__tlb_flag), "Ir" (f) \
: "cc"); \
} while (0)
c010dd64: e3130c12 tst r3, #4608 ; 0x1200
c010dd68: 1e081f17 mcrne 15, 0, r1, cr8, cr7, {0}
c010dd6c: e3120602 tst r2, #2097152 ; 0x200000
c010dd70: 1e081f17 mcrne 15, 0, r1, cr8, cr7, {0}
c010dd74: f57ff047 dsb un
c010dd78: f57ff06f isb sy
A8.6.92 MCR, MCR2
Move to Coprocessor from ARM core register passes the value of an ARM core register to a coprocessor.
If no coprocessor can execute the instruction, an Undefined Instruction exception is generated.
This is a generic coprocessor instruction. Some of the fields have no functionality defined by the architecture
and are free for use by the coprocessor instruction set designer. These fields are the opc1, opc2, CRn, and
CRm fields.
Operation
if ConditionPassed() then
EncodingSpecificOperations();
if !Coproc_Accepted(cp, ThisInstr()) then
GenerateCoprocessorException();
else
Coproc_SendOneWord(R[t], cp, ThisInstr());
I.7.5 Coproc_Accepted()
This function determines, for a coprocessor and one of its coprocessor instructions:
- Whether access to the coprocessor is permitted by the CPACR and, if the Security Extensions are
implemented, the NSACR.
- If access is permitted, whether the instruction is accepted by the coprocessor. The coprocessor
architecture definition specifies which instructions it accepts and in what circumstances.
It returns TRUE if access is permitted and the coprocessor accepts the instruction, and FALSE otherwise.
boolean Coproc_Accepted(integer cp_num, bits(32) instr)
I.7.17 GenerateCoprocessorException()
This procedure generates the appropriate exception for a rejected coprocessor instruction.
In all architecture variants and profiles described in this manual, GenerateCoprocessorException() generates
an Undefined Instruction exception.
Assuming I'm hitting this, I would expect the kernel to print something
if the secondary cores trigger an exception. Am I mistaken?
mov r1, #0
mcrne 15, 0, r1, cr8, cr7, {0}
B3.12.34 CP15 c8, TLB maintenance operations
On ARMv7-A implementations, CP15 c8 operations are used for TLB maintenance functions. Figure B3-20
shows the CP15 c8 encodings.
TLBIALL*, invalidate unified TLB
* See text for more information about these mnemonics
Invalidate entire unified TLB
(When separate instruction and data TLBs are implemented,
these operations are performed on both TLBs.)
Rt data = Ignore
Invalidate entire TLB
The Invalidate entire TLB operations invalidate all unlocked entries in the TLB. The value in the register Rt
specified by the MCR instruction used to perform the operation is ignored. You do not have to write a value
to the register before issuing the MCR instruction.
Maybe this is a red herring... I don't see why the TLBIALL would
raise an exception when the system resumes... I first suspected
TrustZone shenanigans, but it looks like TLBIALL just flushes
what it can, so TrustZone seems to be a non-issue.
I'm stumped... Still looking for a clue :-(
Maybe I should instrument the exception handler...
if I only knew where it was.
Regards.
^ permalink raw reply
* [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-29 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229022348.GA13402@gondor.apana.org.au>
On 29 December 2016 at 02:23, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Dec 28, 2016 at 07:50:44PM +0000, Ard Biesheuvel wrote:
>>
>> So about this chunksize, is it ever expected to assume other values
>> than 1 (for stream ciphers) or the block size (for block ciphers)?
>> Having block size, IV size *and* chunk size fields may be confusing to
>> some already, so if the purpose of chunk size can be fulfilled by a
>> single 'stream cipher' flag, perhaps we should change that first.
>
> For users (such as algif) it's much more convenient to have a size
> rather than a flag because that's what they need to determine the
> minimum size for partial updates.
>
> For implementors you don't need to specify the chunksize at all
> unless you're a stream cipher (or some other case in future where
> the minimum partial update size is not equal to your block size).
>
OK, fair enough. So I will add a field 'walksize' to the skcipher_alg
struct in my proposal. I think the walk logic itself needs to change
very little, though: we can simply set the walk's chunksize to the
skcipher's walksize if it exceeds its chunksize (and walksize %
chunksize should be 0 in any case, and walksize should default to the
chunksize if not supplied)
If this sounds reasonable to you, I will hack something up next week.
^ permalink raw reply
* [PATCH] ARM: s3c2410_defconfig: Fix invalid values for NF_CT_PROTO_*
From: Krzysztof Kozlowski @ 2016-12-29 12:41 UTC (permalink / raw)
To: linux-arm-kernel
NF_CT_PROTO_DCCP/SCTP/UDPLITE were switched from tristate to boolean so
defconfig needs to be adjusted to silence warnings:
warning: symbol value 'm' invalid for NF_CT_PROTO_DCCP
warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
arch/arm/configs/s3c2410_defconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/configs/s3c2410_defconfig b/arch/arm/configs/s3c2410_defconfig
index 4364040ed696..1e6c48dd7b11 100644
--- a/arch/arm/configs/s3c2410_defconfig
+++ b/arch/arm/configs/s3c2410_defconfig
@@ -86,9 +86,9 @@ CONFIG_IPV6_TUNNEL=m
CONFIG_NETFILTER=y
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CONNTRACK_EVENTS=y
-CONFIG_NF_CT_PROTO_DCCP=m
-CONFIG_NF_CT_PROTO_SCTP=m
-CONFIG_NF_CT_PROTO_UDPLITE=m
+CONFIG_NF_CT_PROTO_DCCP=y
+CONFIG_NF_CT_PROTO_SCTP=y
+CONFIG_NF_CT_PROTO_UDPLITE=y
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
--
2.9.3
^ permalink raw reply related
* [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
From: ayaka @ 2016-12-29 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04b667d9-2591-51ff-e024-047bbb6e17c3@rock-chips.com>
[ 5.849733] rk_gmac-dwmac ff290000.ethernet (unnamed net_device)
(uninitialized): Enable RX Mitigation via HW Watchdog Timer
[ 5.944512] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req
50000000Hz, actual 50000000HZ div = 0)
[ 5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001
[ 6.294548] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase
to 177
[ 6.301591] mmc2: new HS200 MMC card at address 0001
[ 6.306758] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
[ 6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB
[ 6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB
[ 6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB
[ 6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7
[ 6.469892] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
[ 6.917883] libphy: stmmac: probed
[ 6.921319] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at
0 IRQ POLL (stmmac-0:00) active
[ 6.930476] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at
2 IRQ POLL (stmmac-0:02)
[ 6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0
[ 6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available
[ 6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware
clock
[ 6.961262] vcc_sd: disabling
[ 6.964275] dovdd_1v8: disabling
[ 6.967527] dvdd_1v2: disabling
[ 6.971006] vdd10_lcd: disabling
[ 6.974701] vcc18_lcd: disabling
[ 6.978467] ttyS2 - failed to request DMA
[ 7.101883] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[ 7.253874] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 7.405883] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
[ 8.037872] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[ 8.189877] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 8.341881] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
[ 8.973871] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req
400000Hz, actual 400000HZ div = 0)
[ 9.125876] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req
300000Hz, actual 300000HZ div = 0)
[ 9.277884] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req
200000Hz, actual 200000HZ div = 0)
[ 9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req
100000Hz, actual 93750HZ div = 1)
looping here
If I revert that patch, there are still lots of Bus speed messages, but
finally would enter into system.
On 12/29/2016 06:25 PM, Randy Li wrote:
>
>
> On 12/29/2016 03:25 PM, Shawn Lin wrote:
>> On 2016/12/29 15:13, Jaehoon Chung wrote:
>>> On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
>>>> Hi Randy,
>>>>
>>>> On 12/29/2016 12:34 AM, Randy Li wrote:
>>>>> This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
>>>>> It is reported that making RK3288 can't boot from eMMC/MMC.
>>>>
>>>> Could you explain in more detail?
>>>> As you mentioned, this patch is making that RK3288 can't boot..then
>>>> why?
>>>> Good way should be that finds the main reason and fixes it.
>>>> Not just revert.
>>>
>>> To Shawn,
>>>
>>> Could you check this? If you have rk3288..
>>> If it's not working fine, it needs to revert this patch until finding
>>> the problem.
>>>
>>
>> Hrmm.....as that patchset was tested based on rk3288 and rk3368, so I
>> need to know which board Randy are using now and could you share some
> Sorry, XZY has asked me about this in the morning and I answer him
> that I would give a feedback at home, so I didn't notice this mail.
> The board is Firefly reload. but the reporter told me that Firefly
> release also have the same problem.
>> log?
>>
>> I will have a look at it.
>>
>>
>>> Best Regards,
>>> Jaehoon Chung
>>>
>>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>>>
>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>> ---
>>>>> drivers/mmc/host/dw_mmc-rockchip.c | 41
>>>>> +++-----------------------------------
>>>>> 1 file changed, 3 insertions(+), 38 deletions(-)
>>>>>
>>>>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> index 9a46e46..3189234 100644
>>>>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>> @@ -14,7 +14,6 @@
>>>>> #include <linux/mmc/dw_mmc.h>
>>>>> #include <linux/of_address.h>
>>>>> #include <linux/mmc/slot-gpio.h>
>>>>> -#include <linux/pm_runtime.h>
>>>>> #include <linux/slab.h>
>>>>>
>>>>> #include "dw_mmc.h"
>>>>> @@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
>>>>> platform_device *pdev)
>>>>> {
>>>>> const struct dw_mci_drv_data *drv_data;
>>>>> const struct of_device_id *match;
>>>>> - int ret;
>>>>>
>>>>> if (!pdev->dev.of_node)
>>>>> return -ENODEV;
>>>>> @@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
>>>>> platform_device *pdev)
>>>>> match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
>>>>> drv_data = match->data;
>>>>>
>>>>> - pm_runtime_get_noresume(&pdev->dev);
>>>>> - pm_runtime_set_active(&pdev->dev);
>>>>> - pm_runtime_enable(&pdev->dev);
>>>>> - pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>>>>> - pm_runtime_use_autosuspend(&pdev->dev);
>>>>> -
>>>>> - ret = dw_mci_pltfm_register(pdev, drv_data);
>>>>> - if (ret) {
>>>>> - pm_runtime_disable(&pdev->dev);
>>>>> - pm_runtime_set_suspended(&pdev->dev);
>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>> - return ret;
>>>>> - }
>>>>> -
>>>>> - pm_runtime_put_autosuspend(&pdev->dev);
>>>>> -
>>>>> - return 0;
>>>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>>>> }
>>>>>
>>>>> -static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>>>> -{
>>>>> - pm_runtime_get_sync(&pdev->dev);
>>>>> - pm_runtime_disable(&pdev->dev);
>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>> -
>>>>> - return dw_mci_pltfm_remove(pdev);
>>>>> -}
>>>>> -
>>>>> -static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
>>>>> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>> - pm_runtime_force_resume)
>>>>> - SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
>>>>> - dw_mci_runtime_resume,
>>>>> - NULL)
>>>>> -};
>>>>> -
>>>>> static struct platform_driver dw_mci_rockchip_pltfm_driver = {
>>>>> .probe = dw_mci_rockchip_probe,
>>>>> - .remove = dw_mci_rockchip_remove,
>>>>> + .remove = dw_mci_pltfm_remove,
>>>>> .driver = {
>>>>> .name = "dwmmc_rockchip",
>>>>> .of_match_table = dw_mci_rockchip_match,
>>>>> - .pm = &dw_mci_rockchip_dev_pm_ops,
>>>>> + .pm = &dw_mci_pltfm_pmops,
>>>>> },
>>>>> };
>>>>>
>>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe
>>>> linux-mmc" in
>>>> the body of a message to majordomo at vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>> .
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
^ permalink raw reply
* [PATCH 0/2] ARM: add Exynos4412 Prime SoC support
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161229133722epcas5p1e138af585fea93a42962f3a7414a081f@epcas5p1.samsung.com>
Hi,
This patchset adds support for Exynos4412 Prime SoC (it supports
additional 1704MHz & 1600MHz CPU OPPs and 1500MHz CPU OPP is just
a regular non-turbo OPP on this SoC).
ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so their
board files are updated accordingly.
This patchset brings 21% CPU performance increase on affected
boards (as tested on ODROID-U3 board).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz (2):
clk: samsung: exynos4412: add cpu clock configuration data for
Exynos4412 Prime
ARM: dts: Add CPU OPPs for Exynos4412 Prime
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
drivers/clk/samsung/clk-exynos4.c | 4 +++
6 files changed, 52 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
--
1.9.1
^ permalink raw reply
* [PATCH 1/2] clk: samsung: exynos4412: add cpu clock configuration data for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483018611-27998-1-git-send-email-b.zolnierkie@samsung.com>
Add cpu clock configuration data for Exynos4412 Prime SoC
(it supports additional PLL rates & CPU frequencies).
Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
drivers/clk/samsung/clk-exynos4.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index faab9b3..e40b775 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -1298,6 +1298,8 @@ static void __init exynos4_clk_register_finpll(struct samsung_clk_provider *ctx)
};
static const struct samsung_pll_rate_table exynos4x12_apll_rates[] __initconst = {
+ PLL_35XX_RATE(1704000000, 213, 3, 0),
+ PLL_35XX_RATE(1600000000, 200, 3, 0),
PLL_35XX_RATE(1500000000, 250, 4, 0),
PLL_35XX_RATE(1400000000, 175, 3, 0),
PLL_35XX_RATE(1300000000, 325, 6, 0),
@@ -1421,6 +1423,8 @@ static void __init exynos4x12_core_down_clock(void)
(((cores) << 8) | ((hpm) << 4) | ((copy) << 0))
static const struct exynos_cpuclk_cfg_data e4412_armclk_d[] __initconst = {
+ { 1704000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(7, 0, 7), },
+ { 1600000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(7, 0, 6), },
{ 1500000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(7, 0, 6), },
{ 1400000, E4210_CPU_DIV0(2, 1, 6, 0, 7, 3), E4412_CPU_DIV1(6, 0, 6), },
{ 1300000, E4210_CPU_DIV0(2, 1, 5, 0, 7, 3), E4412_CPU_DIV1(6, 0, 5), },
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483018611-27998-1-git-send-email-b.zolnierkie@samsung.com>
Add CPU operating points for Exynos4412 Prime (it supports
additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
a regular non-turbo OPP on this SoC). Also update relevant
cooling maps to account for new OPPs.
ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
update their board files accordingly.
Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
Cc: Doug Anderson <dianders@chromium.org>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Cc: Ben Gamari <ben@smart-cactus.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
arch/arm/boot/dts/exynos4412.dtsi | 2 +-
5 files changed, 48 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 8aa19ba..5282d69e 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -97,11 +97,11 @@
thermal-zones {
cpu_thermal: cpu-thermal {
cooling-maps {
- map0 {
+ cooling_map0: map0 {
/* Corresponds to 800MHz at freq_table */
cooling-device = <&cpu0 7 7>;
};
- map1 {
+ cooling_map1: map1 {
/* Corresponds to 200MHz at freq_table */
cooling-device = <&cpu0 13 13>;
};
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 99634c5..7504a5a 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -13,6 +13,7 @@
/dts-v1/;
#include "exynos4412-odroid-common.dtsi"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
@@ -47,11 +48,11 @@
cooling-maps {
map0 {
trip = <&cpu_alert1>;
- cooling-device = <&cpu0 7 7>;
+ cooling-device = <&cpu0 9 9>;
};
map1 {
trip = <&cpu_alert2>;
- cooling-device = <&cpu0 13 13>;
+ cooling-device = <&cpu0 15 15>;
};
map2 {
trip = <&cpu_alert0>;
diff --git a/arch/arm/boot/dts/exynos4412-odroidx2.dts b/arch/arm/boot/dts/exynos4412-odroidx2.dts
index 4d22885..d6e92ebc 100644
--- a/arch/arm/boot/dts/exynos4412-odroidx2.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidx2.dts
@@ -12,6 +12,7 @@
*/
#include "exynos4412-odroidx.dts"
+#include "exynos4412-prime.dtsi"
/ {
model = "Hardkernel ODROID-X2 board based on Exynos4412";
diff --git a/arch/arm/boot/dts/exynos4412-prime.dtsi b/arch/arm/boot/dts/exynos4412-prime.dtsi
new file mode 100644
index 0000000..e75bc17
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-prime.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Samsung's Exynos4412 Prime SoC device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Exynos4412 Prime SoC revision supports higher CPU frequencies than
+ * non-Prime version. Therefore we need to update OPPs table and
+ * thermal maps accordingly.
+ */
+
+&cpu0_opp_1500 {
+ /delete-property/turbo-mode;
+};
+
+&cpu0_opp_table {
+ opp at 1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+ opp at 1704000000 {
+ opp-hz = /bits/ 64 <1704000000>;
+ opp-microvolt = <1350000>;
+ clock-latency-ns = <200000>;
+ };
+};
+
+&cooling_map0 {
+ cooling-device = <&cpu0 9 9>;
+};
+
+&cooling_map1 {
+ cooling-device = <&cpu0 15 15>;
+};
diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
index 40beede..3ebdf01 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -130,7 +130,7 @@
opp-microvolt = <1287500>;
clock-latency-ns = <200000>;
};
- opp at 1500000000 {
+ cpu0_opp_1500: opp at 1500000000 {
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1350000>;
clock-latency-ns = <200000>;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] pinctrl: dt-bindings: samsung: add drive strength macros for Exynos5433
From: Andi Shyti @ 2016-12-29 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229115059.ncvtakz32vhcfsij@kozik-lap>
Hi Krzysztof,
> > #define EXYNOS5420_PIN_DRV_LV3 2
> > #define EXYNOS5420_PIN_DRV_LV4 3
> >
> > +/* Drive strengths for Exynos5433 */
> > +#define EXYNOS5433_PIN_DRV_LV1 0
> > +#define EXYNOS5433_PIN_DRV_LV2 1
> > +#define EXYNOS5433_PIN_DRV_LV3 2
> > +#define EXYNOS5433_PIN_DRV_LV4 3
>
> Same values as existing. No need to re-define these.
Yes, I was in doubt when I prepared this patch as on one hand it
didn't look right to use EXYNOS5420_* for exynos5433, on the other
hand it didn't look right to duplicate the macros.
In anycase this values need to be fixed as Chanwoo wrote in the
other mail.
Thanks,
Andi
^ permalink raw reply
* [PATCH 4/4] ARM64: dts: exynos5433: remove unused code
From: Andi Shyti @ 2016-12-29 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229115421.pq52ab57e53xntoz@kozik-lap>
> > #include <dt-bindings/pinctrl/samsung.h>
> >
> > -#define PIN_PULL_NONE 0
> > -#define PIN_PULL_DOWN 1
> > -#define PIN_PULL_UP 3
> > -
> > -#define PIN_DRV_LV1 0
> > -#define PIN_DRV_LV2 2
> > -#define PIN_DRV_LV3 1
> > -#define PIN_DRV_LV4 3
> > -
> > -#define PIN_IN 0
> > -#define PIN_OUT 1
> > -#define PIN_FUNC1 2
> > -
>
> This should be squashed with 3/4 because logically it is strictly
> related to it and splitting it does not bring any benefits. Actually
> while looking at 3/4 I was surprised to see them not removed.
Yes, right :)
Thanks,
Andi
^ permalink raw reply
* [PATCH 0/4] video/exynos/cec: add HDMI state notifier & use in s5p-cec
From: Marek Szyprowski @ 2016-12-29 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161213150813.37966-1-hverkuil@xs4all.nl>
Hi Hans,
On 2016-12-13 16:08, Hans Verkuil wrote:
> From: Hans Verkuil <hans.verkuil@cisco.com>
>
> This patch series adds the HDMI notifier code, based on Russell's code:
>
> https://patchwork.kernel.org/patch/9277043/
>
> It adds support for it to the exynos_hdmi drm driver, adds support for
> it to the CEC framework and finally adds support to the s5p-cec driver,
> which now can be moved out of staging.
>
> Tested with my Odroid U3 exynos4 devboard.
>
> Comments are welcome. I'd like to get this in for the 4.11 kernel as
> this is a missing piece needed to integrate CEC drivers.
>
> Benjamin, can you look at doing the same notifier integration for your
> st-cec driver as is done for s5p-cec? It would be good to be able to
> move st-cec out of staging at the same time.
Thanks for working on this and taking it from by TODO list! :)
Please add:
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
If you plan to send an updated version, please send it also to
linux-samsung-soc at vger.kernel.org, Krzysztof and Inki to get their acks
for the bindings, dtsi and drm parts.
This HDMI notifier framework will probably be also useful for integrating
HDMI audio support for Samsung ASoC driver.
> Regards,
>
> Hans
>
> Hans Verkuil (4):
> video: add HDMI state notifier support
> exynos_hdmi: add HDMI notifier support
> cec: integrate HDMI notifier support
> s5p-cec: add hdmi-notifier support, move out of staging
>
> .../devicetree/bindings/media/s5p-cec.txt | 2 +
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> drivers/gpu/drm/exynos/Kconfig | 1 +
> drivers/gpu/drm/exynos/exynos_hdmi.c | 24 +++-
> drivers/media/cec/cec-core.c | 50 ++++++++
> drivers/media/platform/Kconfig | 18 +++
> drivers/media/platform/Makefile | 1 +
> .../media => media/platform}/s5p-cec/Makefile | 0
> .../platform}/s5p-cec/exynos_hdmi_cec.h | 0
> .../platform}/s5p-cec/exynos_hdmi_cecctrl.c | 0
> .../media => media/platform}/s5p-cec/regs-cec.h | 0
> .../media => media/platform}/s5p-cec/s5p_cec.c | 35 +++++-
> .../media => media/platform}/s5p-cec/s5p_cec.h | 3 +
> drivers/staging/media/Kconfig | 2 -
> drivers/staging/media/Makefile | 1 -
> drivers/staging/media/s5p-cec/Kconfig | 9 --
> drivers/staging/media/s5p-cec/TODO | 7 --
> drivers/video/Kconfig | 3 +
> drivers/video/Makefile | 1 +
> drivers/video/hdmi-notifier.c | 134 +++++++++++++++++++++
> include/linux/hdmi-notifier.h | 109 +++++++++++++++++
> include/media/cec.h | 15 +++
> 22 files changed, 389 insertions(+), 27 deletions(-)
> rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
> rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
> delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
> delete mode 100644 drivers/staging/media/s5p-cec/TODO
> create mode 100644 drivers/video/hdmi-notifier.c
> create mode 100644 include/linux/hdmi-notifier.h
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
From: Jaehoon Chung @ 2016-12-29 14:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6ccade72-ae20-2ffa-1504-2536b9f03adf@soulik.info>
Hi,
On 12/29/2016 09:55 PM, ayaka wrote:
> [ 5.849733] rk_gmac-dwmac ff290000.ethernet (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer
> [ 5.944512] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
> [ 5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001
> [ 6.294548] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 177
> [ 6.301591] mmc2: new HS200 MMC card at address 0001
> [ 6.306758] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
> [ 6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB
> [ 6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB
> [ 6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB
> [ 6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7
> [ 6.469892] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
> [ 6.917883] libphy: stmmac: probed
> [ 6.921319] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
> [ 6.930476] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 2 IRQ POLL (stmmac-0:02)
> [ 6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0
> [ 6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available
> [ 6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
> [ 6.961262] vcc_sd: disabling
> [ 6.964275] dovdd_1v8: disabling
> [ 6.967527] dvdd_1v2: disabling
> [ 6.971006] vdd10_lcd: disabling
> [ 6.974701] vcc18_lcd: disabling
> [ 6.978467] ttyS2 - failed to request DMA
> [ 7.101883] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> [ 7.253874] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 7.405883] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
> [ 8.037872] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> [ 8.189877] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 8.341881] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
> [ 8.973871] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> [ 9.125876] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
> [ 9.277884] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
> [ 9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>
> looping here
>
> If I revert that patch, there are still lots of Bus speed messages, but finally would enter into system.
>
Plz..Don't put the comment on the top.
Which kernel did you use?
>
> On 12/29/2016 06:25 PM, Randy Li wrote:
>>
>>
>> On 12/29/2016 03:25 PM, Shawn Lin wrote:
>>> On 2016/12/29 15:13, Jaehoon Chung wrote:
>>>> On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
>>>>> Hi Randy,
>>>>>
>>>>> On 12/29/2016 12:34 AM, Randy Li wrote:
>>>>>> This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
>>>>>> It is reported that making RK3288 can't boot from eMMC/MMC.
>>>>>
>>>>> Could you explain in more detail?
>>>>> As you mentioned, this patch is making that RK3288 can't boot..then why?
>>>>> Good way should be that finds the main reason and fixes it.
>>>>> Not just revert.
>>>>
>>>> To Shawn,
>>>>
>>>> Could you check this? If you have rk3288..
>>>> If it's not working fine, it needs to revert this patch until finding
>>>> the problem.
>>>>
>>>
>>> Hrmm.....as that patchset was tested based on rk3288 and rk3368, so I
>>> need to know which board Randy are using now and could you share some
>> Sorry, XZY has asked me about this in the morning and I answer him that I would give a feedback at home, so I didn't notice this mail.
>> The board is Firefly reload. but the reporter told me that Firefly release also have the same problem.
>>> log?
>>>
>>> I will have a look at it.
>>>
>>>
>>>> Best Regards,
>>>> Jaehoon Chung
>>>>
>>>>>
>>>>> Best Regards,
>>>>> Jaehoon Chung
>>>>>
>>>>>>
>>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>>> ---
>>>>>> drivers/mmc/host/dw_mmc-rockchip.c | 41
>>>>>> +++-----------------------------------
>>>>>> 1 file changed, 3 insertions(+), 38 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> index 9a46e46..3189234 100644
>>>>>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>> @@ -14,7 +14,6 @@
>>>>>> #include <linux/mmc/dw_mmc.h>
>>>>>> #include <linux/of_address.h>
>>>>>> #include <linux/mmc/slot-gpio.h>
>>>>>> -#include <linux/pm_runtime.h>
>>>>>> #include <linux/slab.h>
>>>>>>
>>>>>> #include "dw_mmc.h"
>>>>>> @@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
>>>>>> platform_device *pdev)
>>>>>> {
>>>>>> const struct dw_mci_drv_data *drv_data;
>>>>>> const struct of_device_id *match;
>>>>>> - int ret;
>>>>>>
>>>>>> if (!pdev->dev.of_node)
>>>>>> return -ENODEV;
>>>>>> @@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
>>>>>> platform_device *pdev)
>>>>>> match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
>>>>>> drv_data = match->data;
>>>>>>
>>>>>> - pm_runtime_get_noresume(&pdev->dev);
>>>>>> - pm_runtime_set_active(&pdev->dev);
>>>>>> - pm_runtime_enable(&pdev->dev);
>>>>>> - pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>>>>>> - pm_runtime_use_autosuspend(&pdev->dev);
>>>>>> -
>>>>>> - ret = dw_mci_pltfm_register(pdev, drv_data);
>>>>>> - if (ret) {
>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>> - pm_runtime_set_suspended(&pdev->dev);
>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>> - return ret;
>>>>>> - }
>>>>>> -
>>>>>> - pm_runtime_put_autosuspend(&pdev->dev);
>>>>>> -
>>>>>> - return 0;
>>>>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>>>>> }
>>>>>>
>>>>>> -static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>>>>> -{
>>>>>> - pm_runtime_get_sync(&pdev->dev);
>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>> -
>>>>>> - return dw_mci_pltfm_remove(pdev);
>>>>>> -}
>>>>>> -
>>>>>> -static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
>>>>>> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>>> - pm_runtime_force_resume)
>>>>>> - SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
>>>>>> - dw_mci_runtime_resume,
>>>>>> - NULL)
>>>>>> -};
>>>>>> -
>>>>>> static struct platform_driver dw_mci_rockchip_pltfm_driver = {
>>>>>> .probe = dw_mci_rockchip_probe,
>>>>>> - .remove = dw_mci_rockchip_remove,
>>>>>> + .remove = dw_mci_pltfm_remove,
>>>>>> .driver = {
>>>>>> .name = "dwmmc_rockchip",
>>>>>> .of_match_table = dw_mci_rockchip_match,
>>>>>> - .pm = &dw_mci_rockchip_dev_pm_ops,
>>>>>> + .pm = &dw_mci_pltfm_pmops,
>>>>>> },
>>>>>> };
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>> the body of a message to majordomo at vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
^ permalink raw reply
* [PATCH v2] ARM: dts: Add missing CPU frequencies for Exynos5422/5800
From: Krzysztof Kozlowski @ 2016-12-29 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAD=FV=Wo273T20fe8D2v5Pn1HYR==7PHtr7WZGwzFPRspAYPzg@mail.gmail.com>
On Thu, Dec 15, 2016 at 04:54:30PM -0800, Doug Anderson wrote:
> > Index: b/arch/arm/boot/dts/exynos5800.dtsi
> > ===================================================================
> > --- a/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.365955950 +0100
> > +++ b/arch/arm/boot/dts/exynos5800.dtsi 2016-12-15 12:43:54.361955949 +0100
> > @@ -24,6 +24,16 @@
> > };
> >
> > &cluster_a15_opp_table {
> > + opp at 2000000000 {
> > + opp-hz = /bits/ 64 <2000000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
> > + opp at 1900000000 {
> > + opp-hz = /bits/ 64 <1900000000>;
> > + opp-microvolt = <1250000>;
> > + clock-latency-ns = <140000>;
> > + };
>
> I don't think the voltages you listed are high enough for all peach pi
> boards for A15 at 1.9 GHz and 2.0 GHz, at least based on the research
> I did. See my response to v1.
I wanted to apply this but saw this remaining issue. Javier tested it
on Peach Pi so is this concern still valid?
Bartlomiej,
When sending dts patches please stick to the common subsystem prefix
(git log --oneline arch/arm/boot/dts/exynos*).
Best regards,
Krzysztof
^ permalink raw reply
* Linux fails to start secondary cores when system resumes from Suspend-to-RAM
From: Mason @ 2016-12-29 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9134f2dd-73f6-73d5-30a0-3129d5440d0a@free.fr>
On Thu, Dec 15, 2016 at 11:18 PM, Mason wrote:
> However, while Linux successfully starts the secondary cores when
> the system first boots, it fails when the system resumes from "S3".
Oh boy...
Turns out the firmware was, in fact, (upon resume) stomping over parts
of the Linux memory image in RAM, triggering all kinds of "interesting"
nasal demons when Linux ran (or, more accurately, limped).
The guilty party will be properly dealt with. (Where's my foam bat?)
Regards.
^ permalink raw reply
* [PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device
From: Sinan Kaya @ 2016-12-29 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <586072E9.3060609@huawei.com>
On 12/25/2016 8:31 PM, Hanjun Guo wrote:
>> A type->setup() would be somewhat cleaner I think, but then it's more
>> code. Whichever works better I guess. :-)
> Agree, I will demo the type->setup() way and send out the patch for review,
> also I find one minor issue for the IORT code, will update that also for next
> version.
Can you provide details on what the minor issue is with the IORT code?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Krzysztof Kozlowski @ 2016-12-29 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483018611-27998-3-git-send-email-b.zolnierkie@samsung.com>
On Thu, Dec 29, 2016 at 02:36:51PM +0100, Bartlomiej Zolnierkiewicz wrote:
> Add CPU operating points for Exynos4412 Prime (it supports
> additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
> a regular non-turbo OPP on this SoC). Also update relevant
> cooling maps to account for new OPPs.
>
> ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
> update their board files accordingly.
>
> Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Andreas Faerber <afaerber@suse.de>
> Cc: Thomas Abraham <thomas.ab@samsung.com>
> Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> Cc: Ben Gamari <ben@smart-cactus.org>
> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
> arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
> arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
> arch/arm/boot/dts/exynos4412.dtsi | 2 +-
> 5 files changed, 48 insertions(+), 5 deletions(-)
> create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
>
Looks okay. Is the clock patch needed for this?
BR,
Krzysztof
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Bartlomiej Zolnierkiewicz @ 2016-12-29 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161229144908.6gkvjpso7ikdmfp7@kozik-lap>
Hi,
On Thursday, December 29, 2016 04:49:08 PM Krzysztof Kozlowski wrote:
> On Thu, Dec 29, 2016 at 02:36:51PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > Add CPU operating points for Exynos4412 Prime (it supports
> > additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
> > a regular non-turbo OPP on this SoC). Also update relevant
> > cooling maps to account for new OPPs.
> >
> > ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
> > update their board files accordingly.
> >
> > Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
> >
> > Cc: Doug Anderson <dianders@chromium.org>
> > Cc: Andreas Faerber <afaerber@suse.de>
> > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> > Cc: Ben Gamari <ben@smart-cactus.org>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > ---
> > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
> > arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
> > arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
> > arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
> > arch/arm/boot/dts/exynos4412.dtsi | 2 +-
> > 5 files changed, 48 insertions(+), 5 deletions(-)
> > create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
> >
>
> Looks okay. Is the clock patch needed for this?
Yep.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH] Revert "mmc: dw_mmc-rockchip: add runtime PM support"
From: ayaka @ 2016-12-29 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95648282-38f5-42c2-fd8b-ab603eb3a168@gmail.com>
On 12/29/2016 10:04 PM, Jaehoon Chung wrote:
> Hi,
>
> On 12/29/2016 09:55 PM, ayaka wrote:
>> [ 5.849733] rk_gmac-dwmac ff290000.ethernet (unnamed net_device) (uninitialized): Enable RX Mitigation via HW Watchdog Timer
>> [ 5.944512] mmc_host mmc1: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ div = 0)
>> [ 5.958249] mmc1: new ultra high speed DDR50 SDIO card at address 0001
>> [ 6.294548] dwmmc_rockchip ff0f0000.dwmmc: Successfully tuned phase to 177
>> [ 6.301591] mmc2: new HS200 MMC card at address 0001
>> [ 6.306758] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 6.316830] mmcblk2: mmc2:0001 AGND3R 14.6 GiB
>> [ 6.321881] mmcblk2boot0: mmc2:0001 AGND3R partition 1 4.00 MiB
>> [ 6.328331] mmcblk2boot1: mmc2:0001 AGND3R partition 2 4.00 MiB
>> [ 6.334792] mmcblk2rpmb: mmc2:0001 AGND3R partition 3 4.00 MiB
>> [ 6.344295] mmcblk2: p1 p2 p3 p4 p5 p6 p7
>> [ 6.469892] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 6.621888] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>> [ 6.917883] libphy: stmmac: probed
>> [ 6.921319] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 0 IRQ POLL (stmmac-0:00) active
>> [ 6.930476] rk_gmac-dwmac ff290000.ethernet eth0: PHY ID 001cc915 at 2 IRQ POLL (stmmac-0:02)
>> [ 6.939757] input: gpio-keys as /devices/platform/gpio-keys/input/input0
>> [ 6.946937] rtc-hym8563 0-0051: no valid clock/calendar values available
>> [ 6.953694] rtc-hym8563 0-0051: hctosys: unable to read the hardware clock
>> [ 6.961262] vcc_sd: disabling
>> [ 6.964275] dovdd_1v8: disabling
>> [ 6.967527] dvdd_1v2: disabling
>> [ 6.971006] vdd10_lcd: disabling
>> [ 6.974701] vcc18_lcd: disabling
>> [ 6.978467] ttyS2 - failed to request DMA
>> [ 7.101883] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>> [ 7.253874] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 7.405883] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 7.557885] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>> [ 8.037872] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>> [ 8.189877] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 8.341881] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 8.493884] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>> [ 8.973871] mmc_host mmc0: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>> [ 9.125876] mmc_host mmc0: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
>> [ 9.277884] mmc_host mmc0: Bus speed (slot 0) = 200000Hz (slot req 200000Hz, actual 200000HZ div = 0)
>> [ 9.429882] mmc_host mmc0: Bus speed (slot 0) = 187500Hz (slot req 100000Hz, actual 93750HZ div = 1)
>>
>> looping here
>>
>> If I revert that patch, there are still lots of Bus speed messages, but finally would enter into system.
>>
> Plz..Don't put the comment on the top.
>
> Which kernel did you use?
Add linux-next specific files for 20161224
>
>> On 12/29/2016 06:25 PM, Randy Li wrote:
>>>
>>> On 12/29/2016 03:25 PM, Shawn Lin wrote:
>>>> On 2016/12/29 15:13, Jaehoon Chung wrote:
>>>>> On 12/29/2016 12:02 PM, Jaehoon Chung wrote:
>>>>>> Hi Randy,
>>>>>>
>>>>>> On 12/29/2016 12:34 AM, Randy Li wrote:
>>>>>>> This reverts commit f90142683f04bcb0729bf0df67a5e29562b725b9.
>>>>>>> It is reported that making RK3288 can't boot from eMMC/MMC.
>>>>>> Could you explain in more detail?
>>>>>> As you mentioned, this patch is making that RK3288 can't boot..then why?
>>>>>> Good way should be that finds the main reason and fixes it.
>>>>>> Not just revert.
>>>>> To Shawn,
>>>>>
>>>>> Could you check this? If you have rk3288..
>>>>> If it's not working fine, it needs to revert this patch until finding
>>>>> the problem.
>>>>>
>>>> Hrmm.....as that patchset was tested based on rk3288 and rk3368, so I
>>>> need to know which board Randy are using now and could you share some
>>> Sorry, XZY has asked me about this in the morning and I answer him that I would give a feedback at home, so I didn't notice this mail.
>>> The board is Firefly reload. but the reporter told me that Firefly release also have the same problem.
>>>> log?
>>>>
>>>> I will have a look at it.
>>>>
>>>>
>>>>> Best Regards,
>>>>> Jaehoon Chung
>>>>>
>>>>>> Best Regards,
>>>>>> Jaehoon Chung
>>>>>>
>>>>>>> Signed-off-by: Randy Li <ayaka@soulik.info>
>>>>>>> ---
>>>>>>> drivers/mmc/host/dw_mmc-rockchip.c | 41
>>>>>>> +++-----------------------------------
>>>>>>> 1 file changed, 3 insertions(+), 38 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> index 9a46e46..3189234 100644
>>>>>>> --- a/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> +++ b/drivers/mmc/host/dw_mmc-rockchip.c
>>>>>>> @@ -14,7 +14,6 @@
>>>>>>> #include <linux/mmc/dw_mmc.h>
>>>>>>> #include <linux/of_address.h>
>>>>>>> #include <linux/mmc/slot-gpio.h>
>>>>>>> -#include <linux/pm_runtime.h>
>>>>>>> #include <linux/slab.h>
>>>>>>>
>>>>>>> #include "dw_mmc.h"
>>>>>>> @@ -327,7 +326,6 @@ static int dw_mci_rockchip_probe(struct
>>>>>>> platform_device *pdev)
>>>>>>> {
>>>>>>> const struct dw_mci_drv_data *drv_data;
>>>>>>> const struct of_device_id *match;
>>>>>>> - int ret;
>>>>>>>
>>>>>>> if (!pdev->dev.of_node)
>>>>>>> return -ENODEV;
>>>>>>> @@ -335,49 +333,16 @@ static int dw_mci_rockchip_probe(struct
>>>>>>> platform_device *pdev)
>>>>>>> match = of_match_node(dw_mci_rockchip_match, pdev->dev.of_node);
>>>>>>> drv_data = match->data;
>>>>>>>
>>>>>>> - pm_runtime_get_noresume(&pdev->dev);
>>>>>>> - pm_runtime_set_active(&pdev->dev);
>>>>>>> - pm_runtime_enable(&pdev->dev);
>>>>>>> - pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
>>>>>>> - pm_runtime_use_autosuspend(&pdev->dev);
>>>>>>> -
>>>>>>> - ret = dw_mci_pltfm_register(pdev, drv_data);
>>>>>>> - if (ret) {
>>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>>> - pm_runtime_set_suspended(&pdev->dev);
>>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>>> - return ret;
>>>>>>> - }
>>>>>>> -
>>>>>>> - pm_runtime_put_autosuspend(&pdev->dev);
>>>>>>> -
>>>>>>> - return 0;
>>>>>>> + return dw_mci_pltfm_register(pdev, drv_data);
>>>>>>> }
>>>>>>>
>>>>>>> -static int dw_mci_rockchip_remove(struct platform_device *pdev)
>>>>>>> -{
>>>>>>> - pm_runtime_get_sync(&pdev->dev);
>>>>>>> - pm_runtime_disable(&pdev->dev);
>>>>>>> - pm_runtime_put_noidle(&pdev->dev);
>>>>>>> -
>>>>>>> - return dw_mci_pltfm_remove(pdev);
>>>>>>> -}
>>>>>>> -
>>>>>>> -static const struct dev_pm_ops dw_mci_rockchip_dev_pm_ops = {
>>>>>>> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>>>>>>> - pm_runtime_force_resume)
>>>>>>> - SET_RUNTIME_PM_OPS(dw_mci_runtime_suspend,
>>>>>>> - dw_mci_runtime_resume,
>>>>>>> - NULL)
>>>>>>> -};
>>>>>>> -
>>>>>>> static struct platform_driver dw_mci_rockchip_pltfm_driver = {
>>>>>>> .probe = dw_mci_rockchip_probe,
>>>>>>> - .remove = dw_mci_rockchip_remove,
>>>>>>> + .remove = dw_mci_pltfm_remove,
>>>>>>> .driver = {
>>>>>>> .name = "dwmmc_rockchip",
>>>>>>> .of_match_table = dw_mci_rockchip_match,
>>>>>>> - .pm = &dw_mci_rockchip_dev_pm_ops,
>>>>>>> + .pm = &dw_mci_pltfm_pmops,
>>>>>>> },
>>>>>>> };
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>>>>> the body of a message to majordomo at vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>> .
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Sylwester Nawrocki @ 2016-12-29 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1840714.lHhVv9oNko@amdc3058>
On 12/29/2016 04:06 PM, Bartlomiej Zolnierkiewicz wrote:
>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>> ---
>>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 4 +--
>>> arch/arm/boot/dts/exynos4412-odroidu3.dts | 5 +--
>>> arch/arm/boot/dts/exynos4412-odroidx2.dts | 1 +
>>> arch/arm/boot/dts/exynos4412-prime.dtsi | 41 +++++++++++++++++++++++++
>>> arch/arm/boot/dts/exynos4412.dtsi | 2 +-
>>> 5 files changed, 48 insertions(+), 5 deletions(-)
>>> create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
>>>
>> Looks okay. Is the clock patch needed for this?
> Yep.
I applied the clock patch and here is a stable tag if it needs
to be pulled as a dependency.
The following changes since commit 7ce7d89f48834cefece7804d38fc5d85382edf77:
Linux 4.10-rc1 (2016-12-25 16:13:08 -0800)
are available in the git repository at:
git://linuxtv.org/snawrocki/samsung.git tags/clk-v4.11-exynos4-pll
for you to fetch changes up to c369596f895be88d09f4165b223fa31c64aaefd4:
clk: samsung: Add CPU clk configuration data for Exynos4412 Prime (2016-12-29
16:34:06 +0100)
----------------------------------------------------------------
Addition of the CPU clock configuration data for Exynos4412
Prime SoC variant.
----------------------------------------------------------------
Bartlomiej Zolnierkiewicz (1):
clk: samsung: Add CPU clk configuration data for Exynos4412 Prime
drivers/clk/samsung/clk-exynos4.c | 4 ++++
1 file changed, 4 insertions(+)
--
Regards,
Sylwester
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Bas van Tiel @ 2016-12-29 16:38 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
when using a signal handler as a way to context switch between
different usercontexts a reproducible exception occurs on my rpi3 in
64-bit mode. (https://gist.github.com/DanGe42/7148946)
Running the context_demo program as a 32-bit ARM executable on a
64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
kernel is OK.
In the first exception the PC doesn?t look correct, and the *pmd is 0.
The 2nd exception happens after running the program again, the PC is 0x0.
A successful function trace was not possible -> complete kernel hangup
when enabling.
Is there another way to gather more information about what is happening?
Linux (none) 4.10.0-rc1-v8+ #3 SMP PREEMPT Thu Dec 29 12:10:12 CET
2016 aarch64 GNU/Linux
[ 46.350738] a.out[196]: unhandled level 2 translation fault (11) at
0x000000b8, esr 0x92000046
[ 46.360516] pgd = ffffffc0392cb000
[ 46.365377] [000000b8] *pgd=00000000392ec003
[ 46.365381] , *pud=00000000392ec003
[ 46.370878] , *pmd=0000000000000000
[ 46.375907]
[ 46.383974]
[ 46.389107] CPU: 0 PID: 196 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
[ 46.397949] Hardware name: Raspberry Pi 3 Model B (DT)
[ 46.406218] task: ffffffc039ad6580 task.stack: ffffffc039bfc000
[ 46.413892] PC is at 0x7fb4e34810
[ 46.418230] LR is at 0x400b84
[ 46.422956] pc : [<0000007fb4e34810>] lr : [<0000000000400b84>]
pstate: 60000000
[ 46.431522] sp : 0000000000413350
[ 46.436480] x29: 0000000000413350 x28: 0000000000000016
[ 46.443142] x27: 0000000000000000 x26: 0000000000000020
[ 46.451908] x25: 0000007fb4f35488 x24: 0000000000415f00
[ 46.459641] x23: 0000000000000016 x22: 0000000000400b84
[ 46.469198] x21: 0000000000413670 x20: 0000000000417030
[ 46.476970] x19: 0000000000001000 x18: 0000000000000000
[ 46.484744] x17: 0000007fb4e34810 x16: 0000000000411270
[ 46.492175] x15: 00000000000005f1 x14: 0000000000000000
[ 46.498884] x13: 0000000000000000 x12: 0000000000000000
[ 46.506013] x11: 0000000000000020 x10: 0101010101010101
[ 46.517164] x9 : 0000000000413670 x8 : 00000000ffffffe0
[ 46.525541] x7 : 0000000000413350 x6 : 0000000000413350
[ 46.533495] x5 : 00000000ffffffe0 x4 : 0000000000413730
[ 46.544052] x3 : 0000000000000008 x2 : 0000000000000000
[ 46.552211] x1 : 0000000000413670 x0 : 0000000000000000
[ 46.558668]
2nd time startup of the executable
[ 262.565147] a.out[201]: unhandled level 2 translation fault (11) at
0x00000000, esr 0x82000006
[ 262.575243] pgd = ffffffc03939a000
[ 262.579948] [00000000] *pgd=000000003938f003
[ 262.579951] , *pud=000000003938f003
[ 262.586040] , *pmd=0000000000000000
[ 262.590479]
[ 262.598234]
[ 262.601108] CPU: 0 PID: 201 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
[ 262.609086] Hardware name: Raspberry Pi 3 Model B (DT)
[ 262.615731] task: ffffffc03904a600 task.stack: ffffffc039bfc000
[ 262.621768] PC is at 0x0
[ 262.624300] LR is at 0x0
[ 262.626835] pc : [<0000000000000000>] lr : [<0000000000000000>]
pstate: 60000000
[ 262.634437] sp : 00000000004159c0
[ 262.637753] x29: 0000000000000000 x28: 0000000000000000
[ 262.643242] x27: 0000000000000000 x26: 0000000000000000
[ 262.648554] x25: 0000000000000000 x24: 0000000000000000
[ 262.654033] x23: 0000000000000000 x22: 0000000000000000
[ 262.659349] x21: 00000000004008f0 x20: 0000000000000000
[ 262.664825] x19: 0000000000000000 x18: 0000000000000000
[ 262.670145] x17: 0000007fb065b620 x16: 0000000000400b84
[ 262.675622] x15: 00000000000003d1 x14: 0000000000000000
[ 262.680938] x13: 0000000000000000 x12: 0000000000000000
[ 262.686413] x11: 0000000000000020 x10: 0101010101010101
[ 262.691835] x9 : 00000000004112c0 x8 : 0000000000000087
[ 262.697159] x7 : 0000000000000000 x6 : 0000000000000000
[ 262.702634] x5 : 0000000000000000 x4 : 0000000000000000
[ 262.707949] x3 : 0000000000000000 x2 : 0000000000000000
[ 262.713424] x1 : 0000000000000000 x0 : 0000000000000000
[ 262.718739]
rpi3:
minimal kernel (64-bit, cortex-a53, little endian, 4Kb page,
initramfs), different kernels tried 4.8/4.9/4.10.0-rc1-v8+ the same
result occurs, also with different compilers.
kernel, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
application, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
The only item I found by reading through the different source-files was the
structure definition of struct kernel_rt_sigframe
(http://osxr.org:8080/glibc/source/ports/sysdeps/unix/sysv/linux/aarch64/kernel_rt_sigframe.h?v=glibc-2.18)
compared to the struct rt_sigframe (linux/arch/arm64/signal.c).
Any help or pointers to solve this issue are welcome,
regards
Bas
^ permalink raw reply
* Unhandled level 2 translation fault (11) at 0x000000b8, esr 0x92000046, rpi3 (aarch64)
From: Neil Armstrong @ 2016-12-29 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGDbNAD7-TM6+x0A3FebTOPYmqQqbm1w29ZwH+9qePaAvhxTKw@mail.gmail.com>
On 12/29/2016 05:38 PM, Bas van Tiel wrote:
> Hi,
>
> when using a signal handler as a way to context switch between
> different usercontexts a reproducible exception occurs on my rpi3 in
> 64-bit mode. (https://gist.github.com/DanGe42/7148946)
>
> Running the context_demo program as a 32-bit ARM executable on a
> 64-bit kernel is OK, running as a 32 || 64 bit executable on an x86
> kernel is OK.
>
> In the first exception the PC doesn?t look correct, and the *pmd is 0.
> The 2nd exception happens after running the program again, the PC is 0x0.
>
> A successful function trace was not possible -> complete kernel hangup
> when enabling.
>
> Is there another way to gather more information about what is happening?
>
> Linux (none) 4.10.0-rc1-v8+ #3 SMP PREEMPT Thu Dec 29 12:10:12 CET
> 2016 aarch64 GNU/Linux
>
> [ 46.350738] a.out[196]: unhandled level 2 translation fault (11) at
> 0x000000b8, esr 0x92000046
> [ 46.360516] pgd = ffffffc0392cb000
> [ 46.365377] [000000b8] *pgd=00000000392ec003
> [ 46.365381] , *pud=00000000392ec003
> [ 46.370878] , *pmd=0000000000000000
> [ 46.375907]
> [ 46.383974]
> [ 46.389107] CPU: 0 PID: 196 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
> [ 46.397949] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 46.406218] task: ffffffc039ad6580 task.stack: ffffffc039bfc000
> [ 46.413892] PC is at 0x7fb4e34810
> [ 46.418230] LR is at 0x400b84
> [ 46.422956] pc : [<0000007fb4e34810>] lr : [<0000000000400b84>]
> pstate: 60000000
> [ 46.431522] sp : 0000000000413350
> [ 46.436480] x29: 0000000000413350 x28: 0000000000000016
> [ 46.443142] x27: 0000000000000000 x26: 0000000000000020
> [ 46.451908] x25: 0000007fb4f35488 x24: 0000000000415f00
> [ 46.459641] x23: 0000000000000016 x22: 0000000000400b84
> [ 46.469198] x21: 0000000000413670 x20: 0000000000417030
> [ 46.476970] x19: 0000000000001000 x18: 0000000000000000
> [ 46.484744] x17: 0000007fb4e34810 x16: 0000000000411270
> [ 46.492175] x15: 00000000000005f1 x14: 0000000000000000
> [ 46.498884] x13: 0000000000000000 x12: 0000000000000000
> [ 46.506013] x11: 0000000000000020 x10: 0101010101010101
> [ 46.517164] x9 : 0000000000413670 x8 : 00000000ffffffe0
> [ 46.525541] x7 : 0000000000413350 x6 : 0000000000413350
> [ 46.533495] x5 : 00000000ffffffe0 x4 : 0000000000413730
> [ 46.544052] x3 : 0000000000000008 x2 : 0000000000000000
> [ 46.552211] x1 : 0000000000413670 x0 : 0000000000000000
> [ 46.558668]
>
> 2nd time startup of the executable
>
> [ 262.565147] a.out[201]: unhandled level 2 translation fault (11) at
> 0x00000000, esr 0x82000006
> [ 262.575243] pgd = ffffffc03939a000
> [ 262.579948] [00000000] *pgd=000000003938f003
> [ 262.579951] , *pud=000000003938f003
> [ 262.586040] , *pmd=0000000000000000
> [ 262.590479]
> [ 262.598234]
> [ 262.601108] CPU: 0 PID: 201 Comm: a.out Not tainted 4.10.0-rc1-v8+ #3
> [ 262.609086] Hardware name: Raspberry Pi 3 Model B (DT)
> [ 262.615731] task: ffffffc03904a600 task.stack: ffffffc039bfc000
> [ 262.621768] PC is at 0x0
> [ 262.624300] LR is at 0x0
> [ 262.626835] pc : [<0000000000000000>] lr : [<0000000000000000>]
> pstate: 60000000
> [ 262.634437] sp : 00000000004159c0
> [ 262.637753] x29: 0000000000000000 x28: 0000000000000000
> [ 262.643242] x27: 0000000000000000 x26: 0000000000000000
> [ 262.648554] x25: 0000000000000000 x24: 0000000000000000
> [ 262.654033] x23: 0000000000000000 x22: 0000000000000000
> [ 262.659349] x21: 00000000004008f0 x20: 0000000000000000
> [ 262.664825] x19: 0000000000000000 x18: 0000000000000000
> [ 262.670145] x17: 0000007fb065b620 x16: 0000000000400b84
> [ 262.675622] x15: 00000000000003d1 x14: 0000000000000000
> [ 262.680938] x13: 0000000000000000 x12: 0000000000000000
> [ 262.686413] x11: 0000000000000020 x10: 0101010101010101
> [ 262.691835] x9 : 00000000004112c0 x8 : 0000000000000087
> [ 262.697159] x7 : 0000000000000000 x6 : 0000000000000000
> [ 262.702634] x5 : 0000000000000000 x4 : 0000000000000000
> [ 262.707949] x3 : 0000000000000000 x2 : 0000000000000000
> [ 262.713424] x1 : 0000000000000000 x0 : 0000000000000000
> [ 262.718739]
>
> rpi3:
> minimal kernel (64-bit, cortex-a53, little endian, 4Kb page,
> initramfs), different kernels tried 4.8/4.9/4.10.0-rc1-v8+ the same
> result occurs, also with different compilers.
>
> kernel, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
> application, aarch64-linux-gnu-gcc (Linaro GCC 6.2-2016.11) 6.2.1 20161016
>
> The only item I found by reading through the different source-files was the
> structure definition of struct kernel_rt_sigframe
> (http://osxr.org:8080/glibc/source/ports/sysdeps/unix/sysv/linux/aarch64/kernel_rt_sigframe.h?v=glibc-2.18)
> compared to the struct rt_sigframe (linux/arch/arm64/signal.c).
>
> Any help or pointers to solve this issue are welcome,
>
> regards
> Bas
>
Hi,
The same issue was reported on Amlogic 64bit aswell : https://www.spinics.net/lists/arm-kernel/msg550204.html
Neil
^ permalink raw reply
* [PATCHv2 net-next 00/11] net: mvpp2: misc improvements and preparation patches
From: David Miller @ 2016-12-29 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943567-12483-1-git-send-email-thomas.petazzoni@free-electrons.com>
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Wed, 28 Dec 2016 17:45:56 +0100
> This series contains a number of misc improvements and preparation
> patches for an upcoming series that adds support for the new PPv2.2
> network controller to the mvpp2 driver.
>
> The most significant improvements are:
>
> - Switching to using build_skb(), which is necessary for the upcoming
> PPv2.2 support, but anyway a good improvement to the current mvpp2
> driver (supporting PPv2.1).
>
> - Making the driver build on 64-bit platforms.
>
> Changes since v1:
>
> - This series is split as a separate series from the larger patch set
> adding support for PPv2.2 in the mvpp2 driver, as requested by
> David Miller.
>
> - Rebased on top of v4.10-rc1.
You still have warnings to fix for the 64-bit build:
drivers/net/ethernet/marvell/mvpp2.c: In function ?mvpp2_rx?:
drivers/net/ethernet/marvell/mvpp2.c:5125:10: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
data = (void *)rx_desc->buf_cookie;
^
^ permalink raw reply
* [PATCH v1] mtd: nand: tango: Update DT binding description
From: Boris Brezillon @ 2016-12-29 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ba47f2f1-bcdc-91e8-ed79-153931ccdad8@sigmadesigns.com>
On Mon, 19 Dec 2016 15:30:12 +0100
Marc Gonzalez <marc_gonzalez@sigmadesigns.com> wrote:
> Visually separate register ranges (address/size pairs) in reg prop.
> Change DMA channel name, for consistency with other drivers.
>
> Signed-off-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
> ---
> Documentation/devicetree/bindings/mtd/tango-nand.txt | 6 +++---
> drivers/mtd/nand/tango_nand.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/tango-nand.txt b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> index ad5a02f2ac8c..cd1bf2ac9055 100644
> --- a/Documentation/devicetree/bindings/mtd/tango-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/tango-nand.txt
> @@ -5,7 +5,7 @@ Required properties:
> - compatible: "sigma,smp8758-nand"
> - reg: address/size of nfc_reg, nfc_mem, and pbus_reg
> - dmas: reference to the DMA channel used by the controller
> -- dma-names: "nfc_sbox"
> +- dma-names: "rxtx"
You probably want to fix the driver accordingly ;-).
> - clocks: reference to the system clock
> - #address-cells: <1>
> - #size-cells: <0>
> @@ -17,9 +17,9 @@ Example:
>
> nandc: nand-controller at 2c000 {
> compatible = "sigma,smp8758-nand";
> - reg = <0x2c000 0x30 0x2d000 0x800 0x20000 0x1000>;
> + reg = <0x2c000 0x30>, <0x2d000 0x800>, <0x20000 0x1000>;
> dmas = <&dma0 3>;
> - dma-names = "nfc_sbox";
> + dma-names = "rxtx";
> clocks = <&clkgen SYS_CLK>;
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/drivers/mtd/nand/tango_nand.c b/drivers/mtd/nand/tango_nand.c
> index cc23db64f0ca..51dc88d6b8da 100644
> --- a/drivers/mtd/nand/tango_nand.c
> +++ b/drivers/mtd/nand/tango_nand.c
> @@ -629,7 +629,7 @@ static int tango_nand_probe(struct platform_device *pdev)
> if (IS_ERR(clk))
> return PTR_ERR(clk);
>
> - nfc->chan = dma_request_chan(&pdev->dev, "nfc_sbox");
> + nfc->chan = dma_request_chan(&pdev->dev, "rxtx");
> if (IS_ERR(nfc->chan))
> return PTR_ERR(nfc->chan);
>
^ 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