Broken device trees for exynos in linux-next

Broken device trees for exynos in linux-next

[Olof Johansson]

Kukjin,

On Thu, Aug 15, 2013 at 12:34 AM,  <build@lixom.net> wrote:

>         exynos5440_defconfig:
> ERROR: Input tree has errors, aborting (use -f to force output)
>
>         exynos_defconfig:
> ERROR: Input tree has errors, aborting (use -f to force output)

Full error is:

  DTC     arch/arm/boot/dts/exynos5420-smdk5420.dtb
ERROR (phandle_references): Reference to non-existent node or label "pdma1"
ERROR (phandle_references): Reference to non-existent node or label "pdma1"
ERROR (phandle_references): Reference to non-existent node or label "pdma0"
ERROR (phandle_references): Reference to non-existent node or label "pdma0"

Looks like you have broken device trees in linux next. Also, what is
exynos5440_defconfig? Don't add contents (which includes defconfigs)
to linux-next branches that won't make it all the way upstream.


Thanks,

-Olof

Broken device trees for exynos in linux-next

[Olof Johansson]

Kukjin,

On Thu, Aug 15, 2013 at 12:34 AM,  <build@lixom.net> wrote:

>         exynos5440_defconfig:
> ERROR: Input tree has errors, aborting (use -f to force output)
>
>         exynos_defconfig:
> ERROR: Input tree has errors, aborting (use -f to force output)

Full error is:

  DTC     arch/arm/boot/dts/exynos5420-smdk5420.dtb
ERROR (phandle_references): Reference to non-existent node or label "pdma1"
ERROR (phandle_references): Reference to non-existent node or label "pdma1"
ERROR (phandle_references): Reference to non-existent node or label "pdma0"
ERROR (phandle_references): Reference to non-existent node or label "pdma0"

Looks like you have broken device trees in linux next. Also, what is
exynos5440_defconfig? Don't add contents (which includes defconfigs)
to linux-next branches that won't make it all the way upstream.


Thanks,

-Olof

RE: Broken device trees for exynos in linux-next

[Kukjin Kim]

Olof Johansson wrote:
> 
> Kukjin,
> 
Hi, Olof,

> On Thu, Aug 15, 2013 at 12:34 AM,  <build@lixom.net> wrote:
> 
> >         exynos5440_defconfig:
> > ERROR: Input tree has errors, aborting (use -f to force output)
> >
> >         exynos_defconfig:
> > ERROR: Input tree has errors, aborting (use -f to force output)
> 
> Full error is:
> 
>   DTC     arch/arm/boot/dts/exynos5420-smdk5420.dtb
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma1"
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma1"
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma0"
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma0"
> 
> Looks like you have broken device trees in linux next.

(+ Mark)

NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.

Mark, pleaser revert it in your tree...

> Also, what is exynos5440_defconfig?

(+ Arnd)

I think, maybe we discussed about that? :) current exynos_defconfig cannot
support exynos5440 because of LPAE and I remember we decided LPAE and
non-LPAE should be separated. So as I commented before, exynos5440_defconfig
is needed. If you have any concerns, please let me know.

> Don't add contents (which includes defconfigs)
> to linux-next branches that won't make it all the way upstream.
> 
Sure :)

Thanks,
Kukjin

Broken device trees for exynos in linux-next

[Kukjin Kim]

Olof Johansson wrote:
> 
> Kukjin,
> 
Hi, Olof,

> On Thu, Aug 15, 2013 at 12:34 AM,  <build@lixom.net> wrote:
> 
> >         exynos5440_defconfig:
> > ERROR: Input tree has errors, aborting (use -f to force output)
> >
> >         exynos_defconfig:
> > ERROR: Input tree has errors, aborting (use -f to force output)
> 
> Full error is:
> 
>   DTC     arch/arm/boot/dts/exynos5420-smdk5420.dtb
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma1"
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma1"
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma0"
> ERROR (phandle_references): Reference to non-existent node or label
> "pdma0"
> 
> Looks like you have broken device trees in linux next.

(+ Mark)

NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.

Mark, pleaser revert it in your tree...

> Also, what is exynos5440_defconfig?

(+ Arnd)

I think, maybe we discussed about that? :) current exynos_defconfig cannot
support exynos5440 because of LPAE and I remember we decided LPAE and
non-LPAE should be separated. So as I commented before, exynos5440_defconfig
is needed. If you have any concerns, please let me know.

> Don't add contents (which includes defconfigs)
> to linux-next branches that won't make it all the way upstream.
> 
Sure :)

Thanks,
Kukjin

Re: Broken device trees for exynos in linux-next

[Mark Brown]

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

On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:

> NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
> move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.

> Mark, pleaser revert it in your tree...

I'll do that but I don't know if that's then going to break anything
else.  This sort of bisection/cross tree issue does come up a lot with
the Samsung SoCs - it'd be good if you could remind the people working
on them about the need to make sure that when there are dependencies
they're handled when things are merged.

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

Broken device trees for exynos in linux-next

[Mark Brown]

On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:

> NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
> move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.

> Mark, pleaser revert it in your tree...

I'll do that but I don't know if that's then going to break anything
else.  This sort of bisection/cross tree issue does come up a lot with
the Samsung SoCs - it'd be good if you could remind the people working
on them about the need to make sure that when there are dependencies
they're handled when things are merged.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130816/846e6eb2/attachment.sig>

Re: Broken device trees for exynos in linux-next

[Mark Brown]

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

On Fri, Aug 16, 2013 at 01:35:57AM +0100, Mark Brown wrote:
> On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:

> > NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
> > move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.

> > Mark, pleaser revert it in your tree...

> I'll do that but I don't know if that's then going to break anything
> else.  This sort of bisection/cross tree issue does come up a lot with
> the Samsung SoCs - it'd be good if you could remind the people working
> on them about the need to make sure that when there are dependencies
> they're handled when things are merged.

I also had to revert "ARM: dts: Change i2s compatible string on
exynos5250" from my tree since it depended on the above commit.  I
suspect this may leave the driver broken and we'll need a new version
before the merge window...

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

Broken device trees for exynos in linux-next

[Mark Brown]

On Fri, Aug 16, 2013 at 01:35:57AM +0100, Mark Brown wrote:
> On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:

> > NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
> > move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.

> > Mark, pleaser revert it in your tree...

> I'll do that but I don't know if that's then going to break anything
> else.  This sort of bisection/cross tree issue does come up a lot with
> the Samsung SoCs - it'd be good if you could remind the people working
> on them about the need to make sure that when there are dependencies
> they're handled when things are merged.

I also had to revert "ARM: dts: Change i2s compatible string on
exynos5250" from my tree since it depended on the above commit.  I
suspect this may leave the driver broken and we'll need a new version
before the merge window...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130816/507d9a72/attachment-0001.sig>

Re: Broken device trees for exynos in linux-next

[Padma Venkat]

Hi,

On Fri, Aug 16, 2013 at 6:12 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Aug 16, 2013 at 01:35:57AM +0100, Mark Brown wrote:
>> On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:
>
>> > NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
>> > move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.
>
>> > Mark, pleaser revert it in your tree...
>
>> I'll do that but I don't know if that's then going to break anything
>> else.  This sort of bisection/cross tree issue does come up a lot with
>> the Samsung SoCs - it'd be good if you could remind the people working
>> on them about the need to make sure that when there are dependencies
>> they're handled when things are merged.
>
> I also had to revert "ARM: dts: Change i2s compatible string on
> exynos5250" from my tree since it depended on the above commit.  I
> suspect this may leave the driver broken and we'll need a new version
> before the merge window...

I apologize for this bisection. Soon I will post a new patch for this.

Thanks
Padma

Broken device trees for exynos in linux-next

[Padma Venkat]

Hi,

On Fri, Aug 16, 2013 at 6:12 AM, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Aug 16, 2013 at 01:35:57AM +0100, Mark Brown wrote:
>> On Fri, Aug 16, 2013 at 09:04:28AM +0900, Kukjin Kim wrote:
>
>> > NO, the build breakage is due to commit 6187288f15bc ("ARM: dts: exynos5250:
>> > move common i2s properties to exynos5 dtsi" which is in Mark Brown's tree.
>
>> > Mark, pleaser revert it in your tree...
>
>> I'll do that but I don't know if that's then going to break anything
>> else.  This sort of bisection/cross tree issue does come up a lot with
>> the Samsung SoCs - it'd be good if you could remind the people working
>> on them about the need to make sure that when there are dependencies
>> they're handled when things are merged.
>
> I also had to revert "ARM: dts: Change i2s compatible string on
> exynos5250" from my tree since it depended on the above commit.  I
> suspect this may leave the driver broken and we'll need a new version
> before the merge window...

I apologize for this bisection. Soon I will post a new patch for this.

Thanks
Padma

Re: Broken device trees for exynos in linux-next

[Olof Johansson]

On Thu, Aug 15, 2013 at 5:04 PM, Kukjin Kim <kgene@kernel.org> wrote:
> I think, maybe we discussed about that? :) current exynos_defconfig cannot
> support exynos5440 because of LPAE and I remember we decided LPAE and
> non-LPAE should be separated. So as I commented before, exynos5440_defconfig
> is needed. If you have any concerns, please let me know.

Having a SoC-specific defconfig makes no sense. You can run with LPAE
enabled on A15 and A7-based systems even if they don't have enough
memory to need it.

Really, what we want is to just turn on the LPAE functionality and
keep everything else common. Forking into two defconfigs seems like
the wrong idea, even if we did discuss it before. Having something
like a config fragment to include would make more sense, since that
could be shared across all platforms (and apply with
multi_v7_defconfig for those who want to run that on LPAE as well).

Or, you know, just have your build script enable it without having an
in-tree config fragment. That'd work too.

The main case where this isn't sufficient is on platforms where _all_
memory sits above 4G, since you can't boot a non-LPAE kernel on those
at all. It seems like 5440 has memory starting at 2GB so it's not one
of those.


-Olof

Broken device trees for exynos in linux-next

[Olof Johansson]

On Thu, Aug 15, 2013 at 5:04 PM, Kukjin Kim <kgene@kernel.org> wrote:
> I think, maybe we discussed about that? :) current exynos_defconfig cannot
> support exynos5440 because of LPAE and I remember we decided LPAE and
> non-LPAE should be separated. So as I commented before, exynos5440_defconfig
> is needed. If you have any concerns, please let me know.

Having a SoC-specific defconfig makes no sense. You can run with LPAE
enabled on A15 and A7-based systems even if they don't have enough
memory to need it.

Really, what we want is to just turn on the LPAE functionality and
keep everything else common. Forking into two defconfigs seems like
the wrong idea, even if we did discuss it before. Having something
like a config fragment to include would make more sense, since that
could be shared across all platforms (and apply with
multi_v7_defconfig for those who want to run that on LPAE as well).

Or, you know, just have your build script enable it without having an
in-tree config fragment. That'd work too.

The main case where this isn't sufficient is on platforms where _all_
memory sits above 4G, since you can't boot a non-LPAE kernel on those
at all. It seems like 5440 has memory starting at 2GB so it's not one
of those.


-Olof

Re: Broken device trees for exynos in linux-next

[Mark Brown]

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

On Fri, Aug 16, 2013 at 09:04:41AM -0700, Olof Johansson wrote:

> Really, what we want is to just turn on the LPAE functionality and
> keep everything else common. Forking into two defconfigs seems like

There's issues with that at the minute due to the DMA mask fun breaking
stuff, though Russell's work has resolved that it should work fine.

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

Broken device trees for exynos in linux-next

[Mark Brown]

On Fri, Aug 16, 2013 at 09:04:41AM -0700, Olof Johansson wrote:

> Really, what we want is to just turn on the LPAE functionality and
> keep everything else common. Forking into two defconfigs seems like

There's issues with that at the minute due to the DMA mask fun breaking
stuff, though Russell's work has resolved that it should work fine.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130816/4b7151cc/attachment.sig>

RE: Broken device trees for exynos in linux-next

[Kukjin Kim]

Olof Johansson wrote:
> 
> On Thu, Aug 15, 2013 at 5:04 PM, Kukjin Kim <kgene@kernel.org> wrote:
> > I think, maybe we discussed about that? :) current exynos_defconfig
> cannot
> > support exynos5440 because of LPAE and I remember we decided LPAE and
> > non-LPAE should be separated. So as I commented before,
> exynos5440_defconfig
> > is needed. If you have any concerns, please let me know.
> 
> Having a SoC-specific defconfig makes no sense. You can run with LPAE
> enabled on A15 and A7-based systems even if they don't have enough
> memory to need it.
> 
Hmm, I'm not sure. If so, I'm wondering why LPAE is implemented with 'ifdef'
and why Red Hat and Canonical provide PAE enabled kernel separately in
x86...

> Really, what we want is to just turn on the LPAE functionality and
> keep everything else common. Forking into two defconfigs seems like
> the wrong idea, even if we did discuss it before. Having something
> like a config fragment to include would make more sense, since that
> could be shared across all platforms (and apply with
> multi_v7_defconfig for those who want to run that on LPAE as well).
> 
If we could make LPAE enabled defconfig for all ARM platforms, I'm fine. I
think your concern is creating SoC specific defconfig and I agree with you.
But I'm not sure how we can support LPAE enabled defconfig for ARM
platforms.

> Or, you know, just have your build script enable it without having an
> in-tree config fragment. That'd work too.
> 
I don't think so because the defconfig will be used by customer for their
product so I should provide some defconfig for exynos5440 in mainline...

> The main case where this isn't sufficient is on platforms where _all_
> memory sits above 4G, since you can't boot a non-LPAE kernel on those
> at all. It seems like 5440 has memory starting at 2GB so it's not one
> of those.
> 
5440 has 8GB memory by default.

So let me know which way is fine to us?

- Kukjin

Broken device trees for exynos in linux-next

[Kukjin Kim]

Olof Johansson wrote:
> 
> On Thu, Aug 15, 2013 at 5:04 PM, Kukjin Kim <kgene@kernel.org> wrote:
> > I think, maybe we discussed about that? :) current exynos_defconfig
> cannot
> > support exynos5440 because of LPAE and I remember we decided LPAE and
> > non-LPAE should be separated. So as I commented before,
> exynos5440_defconfig
> > is needed. If you have any concerns, please let me know.
> 
> Having a SoC-specific defconfig makes no sense. You can run with LPAE
> enabled on A15 and A7-based systems even if they don't have enough
> memory to need it.
> 
Hmm, I'm not sure. If so, I'm wondering why LPAE is implemented with 'ifdef'
and why Red Hat and Canonical provide PAE enabled kernel separately in
x86...

> Really, what we want is to just turn on the LPAE functionality and
> keep everything else common. Forking into two defconfigs seems like
> the wrong idea, even if we did discuss it before. Having something
> like a config fragment to include would make more sense, since that
> could be shared across all platforms (and apply with
> multi_v7_defconfig for those who want to run that on LPAE as well).
> 
If we could make LPAE enabled defconfig for all ARM platforms, I'm fine. I
think your concern is creating SoC specific defconfig and I agree with you.
But I'm not sure how we can support LPAE enabled defconfig for ARM
platforms.

> Or, you know, just have your build script enable it without having an
> in-tree config fragment. That'd work too.
> 
I don't think so because the defconfig will be used by customer for their
product so I should provide some defconfig for exynos5440 in mainline...

> The main case where this isn't sufficient is on platforms where _all_
> memory sits above 4G, since you can't boot a non-LPAE kernel on those
> at all. It seems like 5440 has memory starting at 2GB so it's not one
> of those.
> 
5440 has 8GB memory by default.

So let me know which way is fine to us?

- Kukjin

Re: Broken device trees for exynos in linux-next

[Kevin Hilman]

Kukjin Kim <kgene@kernel.org> writes:

[...]

> If we could make LPAE enabled defconfig for all ARM platforms, I'm fine. I
> think your concern is creating SoC specific defconfig and I agree with you.
> But I'm not sure how we can support LPAE enabled defconfig for ARM
> platforms.

Here's a simple way to keep a single base defconfig, and enable LPAE:

$ echo CONFIG_ARM_LPAE=y > /tmp/lpae.config
$ ./scripts/kconfig/merge_config.sh arch/arm/config/exynos_defconfig /tmp/lpae.config

Kevin

Broken device trees for exynos in linux-next

[Kevin Hilman]

Kukjin Kim <kgene@kernel.org> writes:

[...]

> If we could make LPAE enabled defconfig for all ARM platforms, I'm fine. I
> think your concern is creating SoC specific defconfig and I agree with you.
> But I'm not sure how we can support LPAE enabled defconfig for ARM
> platforms.

Here's a simple way to keep a single base defconfig, and enable LPAE:

$ echo CONFIG_ARM_LPAE=y > /tmp/lpae.config
$ ./scripts/kconfig/merge_config.sh arch/arm/config/exynos_defconfig /tmp/lpae.config

Kevin

RE: Broken device trees for exynos in linux-next

[Kukjin Kim]

Kevin Hilman wrote:
> 
> Kukjin Kim <kgene@kernel.org> writes:
> 
> [...]
> 
> > If we could make LPAE enabled defconfig for all ARM platforms, I'm fine.
> I
> > think your concern is creating SoC specific defconfig and I agree with
> you.
> > But I'm not sure how we can support LPAE enabled defconfig for ARM
> > platforms.
> 
> Here's a simple way to keep a single base defconfig, and enable LPAE:
> 
> $ echo CONFIG_ARM_LPAE=y > /tmp/lpae.config
> $ ./scripts/kconfig/merge_config.sh arch/arm/config/exynos_defconfig
> /tmp/lpae.config
> 
Yeah, it can be used for test. But there are many differences between
exynos_defconfig and exynos5440_defconfig...PCIe, GbE, HugeTLB and KVM...so
I'm still wondering how to handle it without other defconfig.

Olof, do you still having objection for exynos5440_defconfig? If so, OK I
will revert exynos5440_defconfig for now so that I could pull out the
'defconfig' branch to arm-soc for upcoming merge window. Then, let's discuss
again :)

Thanks,
Kukjin

Broken device trees for exynos in linux-next

[Kukjin Kim]

Kevin Hilman wrote:
> 
> Kukjin Kim <kgene@kernel.org> writes:
> 
> [...]
> 
> > If we could make LPAE enabled defconfig for all ARM platforms, I'm fine.
> I
> > think your concern is creating SoC specific defconfig and I agree with
> you.
> > But I'm not sure how we can support LPAE enabled defconfig for ARM
> > platforms.
> 
> Here's a simple way to keep a single base defconfig, and enable LPAE:
> 
> $ echo CONFIG_ARM_LPAE=y > /tmp/lpae.config
> $ ./scripts/kconfig/merge_config.sh arch/arm/config/exynos_defconfig
> /tmp/lpae.config
> 
Yeah, it can be used for test. But there are many differences between
exynos_defconfig and exynos5440_defconfig...PCIe, GbE, HugeTLB and KVM...so
I'm still wondering how to handle it without other defconfig.

Olof, do you still having objection for exynos5440_defconfig? If so, OK I
will revert exynos5440_defconfig for now so that I could pull out the
'defconfig' branch to arm-soc for upcoming merge window. Then, let's discuss
again :)

Thanks,
Kukjin

Re: Broken device trees for exynos in linux-next

[Olof Johansson]

Kukjin,

On Thu, Aug 22, 2013 at 2:55 AM, Kukjin Kim <kgene@kernel.org> wrote:
> Yeah, it can be used for test. But there are many differences between
> exynos_defconfig and exynos5440_defconfig...PCIe, GbE, HugeTLB and KVM...so
> I'm still wondering how to handle it without other defconfig.
>
> Olof, do you still having objection for exynos5440_defconfig? If so, OK I
> will revert exynos5440_defconfig for now so that I could pull out the
> 'defconfig' branch to arm-soc for upcoming merge window. Then, let's discuss
> again :)

As far as I see it, you have two options:

1. Add the needed drivers to multi_v7_defconfig and use that for your platform.
2. Add them to both multi_v7_defconfig and exynos_defconfig.

Enabling the new drivers on exynos_defconfig does no harm.

I don't want to see a new defconfig for this.


-Olof

Broken device trees for exynos in linux-next

[Olof Johansson]

Kukjin,

On Thu, Aug 22, 2013 at 2:55 AM, Kukjin Kim <kgene@kernel.org> wrote:
> Yeah, it can be used for test. But there are many differences between
> exynos_defconfig and exynos5440_defconfig...PCIe, GbE, HugeTLB and KVM...so
> I'm still wondering how to handle it without other defconfig.
>
> Olof, do you still having objection for exynos5440_defconfig? If so, OK I
> will revert exynos5440_defconfig for now so that I could pull out the
> 'defconfig' branch to arm-soc for upcoming merge window. Then, let's discuss
> again :)

As far as I see it, you have two options:

1. Add the needed drivers to multi_v7_defconfig and use that for your platform.
2. Add them to both multi_v7_defconfig and exynos_defconfig.

Enabling the new drivers on exynos_defconfig does no harm.

I don't want to see a new defconfig for this.


-Olof