Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
[...] > Do CPUs enter the kernel at EL2 or at EL1? > >>> > >>> Could you give me a tip how to check the kernel at EL2 or EL1? > >> > >> Hmm... I thought we logged this but it looks like we don't. > >> > >> You could hack in a check of is_hyp_mode_available() and > >> is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, > >> and whether all CPUs enter at the same mode (mandatory per the boot > >> protocol). > > > > OK, I'll try it. > > I check the return value of is_hyp_mode_available() to catch whether EL1 or > EL2. > > The is_hyp_mode_available() returns 'false' during kernel booting. > - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) > - __boot_cpu_mode[1]: 0x0 Thanks for taking a look. It's unfortunate that CPUs aren't booted at EL2 (especially given that booting them at EL1N means the FW is doing more work to be less helpful to the OS), but at least they seem to be booted in consistent modes. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
[...] Do CPUs enter the kernel at EL2 or at EL1? Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Thanks for taking a look. It's unfortunate that CPUs aren't booted at EL2 (especially given that booting them at EL1N means the FW is doing more work to be less helpful to the OS), but at least they seem to be booted in consistent modes. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark, On 03/06/2015 09:18 PM, Chanwoo Choi wrote: > Hi, > > On 03/06/2015 08:40 PM, Mark Rutland wrote: [snip] >> I take it CPUs boot at EL2? >> >> Do the CPUs boot at EL1 or EL2? > > Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. > I think that a few SoC provider probably would know it. I guess I asked the wrong question. Do CPUs enter the kernel at EL2 or at EL1? >>> >>> Could you give me a tip how to check the kernel at EL2 or EL1? >> >> Hmm... I thought we logged this but it looks like we don't. >> >> You could hack in a check of is_hyp_mode_available() and >> is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, >> and whether all CPUs enter at the same mode (mandatory per the boot >> protocol). > > OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark, On 03/06/2015 09:18 PM, Chanwoo Choi wrote: Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: [snip] I take it CPUs boot at EL2? Do the CPUs boot at EL1 or EL2? Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. I think that a few SoC provider probably would know it. I guess I asked the wrong question. Do CPUs enter the kernel at EL2 or at EL1? Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). OK, I'll try it. I check the return value of is_hyp_mode_available() to catch whether EL1 or EL2. The is_hyp_mode_available() returns 'false' during kernel booting. - __boot_cpu_mode[0]: 0xe11 (BOOT_CPU_MODE_EL1) - __boot_cpu_mode[1]: 0x0 Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: >> CPU0 (boot CPU) is only well working for CPU_OFF. >> But when I try to turn on the CPU0 after CPU_OFF, I failed it. > > That's rather worrying. Can you look into what's going on here? I'd > rather not have dts describing things which are known to be broken. The board dts don't include any node for CPU_ON/OFF. >>> >>> I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node >>> quoted above, and all the CPUs had enable-method = "psci". >> >> I mean that there are not additional dt node except for 'cpu' and 'psci' >> node. > > The psci node and cpu enable-method are sufficient. No other nodes > should be relevant. You're right. > >>> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen. After lockup happen, I cannot use the console. >>> >>> That sounds like a pretty major bug. >>> >>> Are you able to investigate with a hardware debugger? >> >> I can't do because there are not any jtag connector. > > That is very unfortunate. Which PSCI implementation are you using? > Surely whoever developed it has access to debug. Surely they should have > tested this? I just used the lateset Linux 4.0-rc2 for PSCI (arch/arm64/kernel/psci.c) without any modification. Unfortunately, I don't know who is the h/w developer of Exynos5433 SoC. > >>> Do other CPUs eventually log errors regarding the lockup? Or is the >>> machine completely dead from this point on? >> >> I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just >> show the error log without lockup. >> I gave you wrong infromation about CPU0 off. > > Ok. However that's still a major bug. > > [...] > >>> I take it CPUs boot at EL2? > > Do the CPUs boot at EL1 or EL2? Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. I think that a few SoC provider probably would know it. >>> >>> I guess I asked the wrong question. >>> >>> Do CPUs enter the kernel at EL2 or at EL1? >> >> Could you give me a tip how to check the kernel at EL2 or EL1? > > Hmm... I thought we logged this but it looks like we don't. > > You could hack in a check of is_hyp_mode_available() and > is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, > and whether all CPUs enter at the same mode (mandatory per the boot > protocol). OK, I'll try it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
> CPU0 (boot CPU) is only well working for CPU_OFF. > But when I try to turn on the CPU0 after CPU_OFF, I failed it. > >>> > >>> That's rather worrying. Can you look into what's going on here? I'd > >>> rather not have dts describing things which are known to be broken. > >> > >> The board dts don't include any node for CPU_ON/OFF. > > > > I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node > > quoted above, and all the CPUs had enable-method = "psci". > > I mean that there are not additional dt node except for 'cpu' and 'psci' node. The psci node and cpu enable-method are sufficient. No other nodes should be relevant. > > > >> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup > >> happen. > >> After lockup happen, I cannot use the console. > > > > That sounds like a pretty major bug. > > > > Are you able to investigate with a hardware debugger? > > I can't do because there are not any jtag connector. That is very unfortunate. Which PSCI implementation are you using? Surely whoever developed it has access to debug. Surely they should have tested this? > > Do other CPUs eventually log errors regarding the lockup? Or is the > > machine completely dead from this point on? > > I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just > show the error log without lockup. > I gave you wrong infromation about CPU0 off. Ok. However that's still a major bug. [...] > > I take it CPUs boot at EL2? > >>> > >>> Do the CPUs boot at EL1 or EL2? > >> > >> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. > >> I think that a few SoC provider probably would know it. > > > > I guess I asked the wrong question. > > > > Do CPUs enter the kernel at EL2 or at EL1? > > Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: CPU0 (boot CPU) is only well working for CPU_OFF. But when I try to turn on the CPU0 after CPU_OFF, I failed it. That's rather worrying. Can you look into what's going on here? I'd rather not have dts describing things which are known to be broken. The board dts don't include any node for CPU_ON/OFF. I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node quoted above, and all the CPUs had enable-method = psci. I mean that there are not additional dt node except for 'cpu' and 'psci' node. The psci node and cpu enable-method are sufficient. No other nodes should be relevant. You're right. When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen. After lockup happen, I cannot use the console. That sounds like a pretty major bug. Are you able to investigate with a hardware debugger? I can't do because there are not any jtag connector. That is very unfortunate. Which PSCI implementation are you using? Surely whoever developed it has access to debug. Surely they should have tested this? I just used the lateset Linux 4.0-rc2 for PSCI (arch/arm64/kernel/psci.c) without any modification. Unfortunately, I don't know who is the h/w developer of Exynos5433 SoC. Do other CPUs eventually log errors regarding the lockup? Or is the machine completely dead from this point on? I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show the error log without lockup. I gave you wrong infromation about CPU0 off. Ok. However that's still a major bug. [...] I take it CPUs boot at EL2? Do the CPUs boot at EL1 or EL2? Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. I think that a few SoC provider probably would know it. I guess I asked the wrong question. Do CPUs enter the kernel at EL2 or at EL1? Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). OK, I'll try it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
CPU0 (boot CPU) is only well working for CPU_OFF. But when I try to turn on the CPU0 after CPU_OFF, I failed it. That's rather worrying. Can you look into what's going on here? I'd rather not have dts describing things which are known to be broken. The board dts don't include any node for CPU_ON/OFF. I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node quoted above, and all the CPUs had enable-method = psci. I mean that there are not additional dt node except for 'cpu' and 'psci' node. The psci node and cpu enable-method are sufficient. No other nodes should be relevant. When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen. After lockup happen, I cannot use the console. That sounds like a pretty major bug. Are you able to investigate with a hardware debugger? I can't do because there are not any jtag connector. That is very unfortunate. Which PSCI implementation are you using? Surely whoever developed it has access to debug. Surely they should have tested this? Do other CPUs eventually log errors regarding the lockup? Or is the machine completely dead from this point on? I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show the error log without lockup. I gave you wrong infromation about CPU0 off. Ok. However that's still a major bug. [...] I take it CPUs boot at EL2? Do the CPUs boot at EL1 or EL2? Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. I think that a few SoC provider probably would know it. I guess I asked the wrong question. Do CPUs enter the kernel at EL2 or at EL1? Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On 03/06/2015 03:54 AM, Mark Rutland wrote:
> Hi,
>
>> + psci {
>> + compatible = "arm,psci";
>> + method = "smc";
>> + cpu_off = <0x8402>;
>> + cpu_on = <0xC403>;
>> + };
>
> Back at v2 you mentioned that CPU_OFF wasn't working [1].
>
> Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
>>>
>>> That's rather worrying. Can you look into what's going on here? I'd
>>> rather not have dts describing things which are known to be broken.
>>
>> The board dts don't include any node for CPU_ON/OFF.
>
> I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node
> quoted above, and all the CPUs had enable-method = "psci".
I mean that there are not additional dt node except for 'cpu' and 'psci' node.
>
>> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
>> After lockup happen, I cannot use the console.
>
> That sounds like a pretty major bug.
>
> Are you able to investigate with a hardware debugger?
I can't do because there are not any jtag connector.
>
> Do other CPUs eventually log errors regarding the lockup? Or is the
> machine completely dead from this point on?
I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show
the error log without lockup.
I gave you wrong infromation about CPU0 off.
[test result of CPU0 on/off on Linux 4.0-rc2]
root@localhost:~# echo 0 > /sys/devices/system/cpu/cpu0/online
[ 420.965435] IRQ1 no longer affine to CPU0
[ 420.965439] IRQ2 no longer affine to CPU0
[ 4631.194227] CPU0: shutdown
root@localhost:~# echo 1 > /sys/devices/system/cpu/cpu0/online
[ 1164.601644] CPU0: failed to come online
-bash: echo: write error: Input/output error
As I experienced, Exynos SoC could not turn off the CPU0 (boot cpu).
I think that we may need the hidden information of Exynos5433 from Exynos5433
architector.
>
> I take it CPUs boot at EL2?
>>>
>>> Do the CPUs boot at EL1 or EL2?
>>
>> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
>> I think that a few SoC provider probably would know it.
>
> I guess I asked the wrong question.
>
> Do CPUs enter the kernel at EL2 or at EL1?
Could you give me a tip how to check the kernel at EL2 or EL1?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
> >> >> + psci {
> >> >> + compatible = "arm,psci";
> >> >> + method = "smc";
> >> >> + cpu_off = <0x8402>;
> >> >> + cpu_on = <0xC403>;
> >> >> + };
> >> >
> >> > Back at v2 you mentioned that CPU_OFF wasn't working [1].
> >> >
> >> > Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
> >>
> >> The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
> >> CPU0 (boot CPU) is only well working for CPU_OFF.
> >> But when I try to turn on the CPU0 after CPU_OFF, I failed it.
> >
> > That's rather worrying. Can you look into what's going on here? I'd
> > rather not have dts describing things which are known to be broken.
>
> The board dts don't include any node for CPU_ON/OFF.
I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node
quoted above, and all the CPUs had enable-method = "psci".
> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
> After lockup happen, I cannot use the console.
That sounds like a pretty major bug.
Are you able to investigate with a hardware debugger?
Do other CPUs eventually log errors regarding the lockup? Or is the
machine completely dead from this point on?
> >> > I take it CPUs boot at EL2?
> >
> > Do the CPUs boot at EL1 or EL2?
>
> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
> I think that a few SoC provider probably would know it.
I guess I asked the wrong question.
Do CPUs enter the kernel at EL2 or at EL1?
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On Fri, Mar 6, 2015 at 2:04 AM, Mark Rutland wrote:
> Hi,
>
> [...]
>
>> >> + psci {
>> >> + compatible = "arm,psci";
>> >> + method = "smc";
>> >> + cpu_off = <0x8402>;
>> >> + cpu_on = <0xC403>;
>> >> + };
>> >
>> > Back at v2 you mentioned that CPU_OFF wasn't working [1].
>> >
>> > Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
>>
>> The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
>> CPU0 (boot CPU) is only well working for CPU_OFF.
>> But when I try to turn on the CPU0 after CPU_OFF, I failed it.
>
> That's rather worrying. Can you look into what's going on here? I'd
> rather not have dts describing things which are known to be broken.
The board dts don't include any node for CPU_ON/OFF.
When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
After lockup happen, I cannot use the console.
>
>> > I take it CPUs boot at EL2?
>
> Do the CPUs boot at EL1 or EL2?
Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
I think that a few SoC provider probably would know it.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
[...]
> >> + psci {
> >> + compatible = "arm,psci";
> >> + method = "smc";
> >> + cpu_off = <0x8402>;
> >> + cpu_on = <0xC403>;
> >> + };
> >
> > Back at v2 you mentioned that CPU_OFF wasn't working [1].
> >
> > Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
>
> The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
> CPU0 (boot CPU) is only well working for CPU_OFF.
> But when I try to turn on the CPU0 after CPU_OFF, I failed it.
That's rather worrying. Can you look into what's going on here? I'd
rather not have dts describing things which are known to be broken.
> > I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
[...]
> > The timer node should be moved under the root node. It doesn't live on
> > the bus; it's a component of the CPU.
>
> OK. I'll move it according to your comment.
Thanks.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark,
On Thu, Mar 5, 2015 at 9:24 PM, Mark Rutland wrote:
> On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
>> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
>> Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433
>> supports
>> PSCI (Power State Coordination Interface) v0.1.
>>
>> This patch includes following dt node to support Exynos5433 SoC:
>> 1. Octa core for big.LITTLE architecture
>> - Cortex-A53 LITTLE Quad-core
>> - Cortex-A57 big Quad-core
>> - Support PSCI v0.1
>
> [...]
>
>> + psci {
>> + compatible = "arm,psci";
>> + method = "smc";
>> + cpu_off = <0x8402>;
>> + cpu_on = <0xC403>;
>> + };
>
> Back at v2 you mentioned that CPU_OFF wasn't working [1].
>
> Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
>
> I take it CPUs boot at EL2?
>
> [...]
>
>> + timer {
>> + compatible = "arm,armv8-timer";
>> + interrupts = <1 13 0xff04>,
>> +<1 14 0xff04>,
>> +<1 11 0xff04>,
>> +<1 10 0xff04>;
>> + };
>
> The timer node should be moved under the root node. It doesn't live on
> the bus; it's a component of the CPU.
OK. I'll move it according to your comment.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
> Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
> PSCI (Power State Coordination Interface) v0.1.
>
> This patch includes following dt node to support Exynos5433 SoC:
> 1. Octa core for big.LITTLE architecture
> - Cortex-A53 LITTLE Quad-core
> - Cortex-A57 big Quad-core
> - Support PSCI v0.1
[...]
> + psci {
> + compatible = "arm,psci";
> + method = "smc";
> + cpu_off = <0x8402>;
> + cpu_on = <0xC403>;
> + };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
I take it CPUs boot at EL2?
[...]
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xff04>,
> +<1 14 0xff04>,
> +<1 11 0xff04>,
> +<1 10 0xff04>;
> + };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
Thanks,
Mark.
[1] https://lkml.org/lkml/2014/12/2/413
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On 03/06/2015 03:54 AM, Mark Rutland wrote:
Hi,
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
That's rather worrying. Can you look into what's going on here? I'd
rather not have dts describing things which are known to be broken.
The board dts don't include any node for CPU_ON/OFF.
I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node
quoted above, and all the CPUs had enable-method = psci.
I mean that there are not additional dt node except for 'cpu' and 'psci' node.
When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
After lockup happen, I cannot use the console.
That sounds like a pretty major bug.
Are you able to investigate with a hardware debugger?
I can't do because there are not any jtag connector.
Do other CPUs eventually log errors regarding the lockup? Or is the
machine completely dead from this point on?
I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just show
the error log without lockup.
I gave you wrong infromation about CPU0 off.
[test result of CPU0 on/off on Linux 4.0-rc2]
root@localhost:~# echo 0 /sys/devices/system/cpu/cpu0/online
[ 420.965435] IRQ1 no longer affine to CPU0
[ 420.965439] IRQ2 no longer affine to CPU0
[ 4631.194227] CPU0: shutdown
root@localhost:~# echo 1 /sys/devices/system/cpu/cpu0/online
[ 1164.601644] CPU0: failed to come online
-bash: echo: write error: Input/output error
As I experienced, Exynos SoC could not turn off the CPU0 (boot cpu).
I think that we may need the hidden information of Exynos5433 from Exynos5433
architector.
I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
I think that a few SoC provider probably would know it.
I guess I asked the wrong question.
Do CPUs enter the kernel at EL2 or at EL1?
Could you give me a tip how to check the kernel at EL2 or EL1?
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
On Fri, Mar 6, 2015 at 2:04 AM, Mark Rutland mark.rutl...@arm.com wrote:
Hi,
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
That's rather worrying. Can you look into what's going on here? I'd
rather not have dts describing things which are known to be broken.
The board dts don't include any node for CPU_ON/OFF.
When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
After lockup happen, I cannot use the console.
I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
I think that a few SoC provider probably would know it.
[snip]
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
That's rather worrying. Can you look into what's going on here? I'd
rather not have dts describing things which are known to be broken.
I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
[...]
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
OK. I'll move it according to your comment.
Thanks.
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi Mark,
On Thu, Mar 5, 2015 at 9:24 PM, Mark Rutland mark.rutl...@arm.com wrote:
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433
supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
I take it CPUs boot at EL2?
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff04,
+1 14 0xff04,
+1 11 0xff04,
+1 10 0xff04;
+ };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
OK. I'll move it according to your comment.
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi,
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
The CPU1 ~ CPU7 are well woking about CPU_ON/OFF.
CPU0 (boot CPU) is only well working for CPU_OFF.
But when I try to turn on the CPU0 after CPU_OFF, I failed it.
That's rather worrying. Can you look into what's going on here? I'd
rather not have dts describing things which are known to be broken.
The board dts don't include any node for CPU_ON/OFF.
I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node
quoted above, and all the CPUs had enable-method = psci.
When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen.
After lockup happen, I cannot use the console.
That sounds like a pretty major bug.
Are you able to investigate with a hardware debugger?
Do other CPUs eventually log errors regarding the lockup? Or is the
machine completely dead from this point on?
I take it CPUs boot at EL2?
Do the CPUs boot at EL1 or EL2?
Unfortunately, I cannot check the secure firmware for Exynos5433 SoC.
I think that a few SoC provider probably would know it.
I guess I asked the wrong question.
Do CPUs enter the kernel at EL2 or at EL1?
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Thu, Mar 05, 2015 at 05:38:23AM +, Chanwoo Choi wrote:
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
[...]
+ psci {
+ compatible = arm,psci;
+ method = smc;
+ cpu_off = 0x8402;
+ cpu_on = 0xC403;
+ };
Back at v2 you mentioned that CPU_OFF wasn't working [1].
Do both CPU_ON and CPU_OFF work for all CPUs, including the boot CPU?
I take it CPUs boot at EL2?
[...]
+ timer {
+ compatible = arm,armv8-timer;
+ interrupts = 1 13 0xff04,
+1 14 0xff04,
+1 11 0xff04,
+1 10 0xff04;
+ };
The timer node should be moved under the root node. It doesn't live on
the bus; it's a component of the CPU.
Thanks,
Mark.
[1] https://lkml.org/lkml/2014/12/2/413
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
2. clock controller node:
- CMU_TOP : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF : clocks for LLI (Low Latency Interface)
- CMU_MIF : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D : clocks for G2D/MDMA
- CMU_DISP : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D : clocks for 3D Graphics Engine
- CMU_GSCL : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
CoreSight and L2 cache controller.
- CMU_MSCL : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0 : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1 : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.
3. pinctrl node for GPIO:
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad
4. HS (High-Speed) I2C device
5. Serial device
6. ARCH timer (arm,armv8-timer)
7. Interrupt controller (arm,gic-400)
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 668
2 files changed, 1366 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index 000..c56bbf8
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,698 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <>;
+ interrupts = <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+_aud {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ i2s0_bus: i2s0-bus {
+ samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
+ "gpz0-4", "gpz0-5", "gpz0-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
+ pcm0_bus: pcm0-bus {
+ samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
+ samsung,pin-function = <3>;
+ samsung,pin-pud =
[PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
2. clock controller node:
- CMU_TOP : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF : clocks for LLI (Low Latency Interface)
- CMU_MIF : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D : clocks for G2D/MDMA
- CMU_DISP : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D : clocks for 3D Graphics Engine
- CMU_GSCL : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
CoreSight and L2 cache controller.
- CMU_MSCL : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0 : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1 : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.
3. pinctrl node for GPIO:
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad
4. HS (High-Speed) I2C device
5. Serial device
6. ARCH timer (arm,armv8-timer)
7. Interrupt controller (arm,gic-400)
Cc: Kukjin Kim kg...@kernel.org
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Marc Zyngier marc.zyng...@arm.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Olof Johansson o...@lixom.net
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Inki Dae inki@samsung.com
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 668
2 files changed, 1366 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index 000..c56bbf8
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,698 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * 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.
+*/
+
+pinctrl_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ interrupt-parent = gic;
+ interrupts = 0 0 0, 0 1 0, 0 2 0, 0 3 0,
+0 4 0, 0 5 0, 0 6 0, 0 7 0;
+ #interrupt-cells = 2;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ interrupt-parent = gic;
+ interrupts = 0 8 0, 0 9 0, 0 10 0, 0 11 0,
+0 12 0, 0 13 0, 0 14 0, 0 15 0;
+ #interrupt-cells = 2;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
+
+pinctrl_aud {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ i2s0_bus: i2s0-bus {
+ samsung,pins = gpz0-0, gpz0-1, gpz0-2, gpz0-3,
+ gpz0-4, gpz0-5, gpz0-6;
+ samsung,pin-function = 2;
+ samsung,pin-pud = 1;
+ samsung,pin-drv = 0;
+ };
+
+ pcm0_bus: pcm0-bus {
+ samsung,pins = gpz1-0,
