*[RFC 0/3] Unify CPU topology across ARM64 & RISC-V @ 2018-11-09 1:50 atish.patra
2018-11-09 1:50 ` Atish Patra
` (4 more replies)0 siblings, 5 replies; 20+ messages in thread
From: atish.patra @ 2018-11-09 1:50 UTC (permalink / raw)
To: linux-riscv
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT binding and topology parsing code can be
moved to a common location so that RISC-V or any other
architecture can leverage that.
The relevant discussion regarding unifying cpu topology can be
found in [1].
arch_topology seems to be a perfect place to move the common
code. I have not introduced any functional changes in the moved
to code. The only downside in this approach is that the capacity
code will be executed for RISC-V as well. But, it will exit
immediately after not able to find the appropriate DT node. If
the overhead is considered too much, we can always compile out
capacity related functions under a different config for the
architectures that do not support them.
The patches have been tested for RISC-V and compile tested for
ARM64.
The socket changes[2] can be merged on top of this series or vice
versa.
[1] https://lkml.org/lkml/2018/11/6/19
[2] https://lkml.org/lkml/2018/11/7/918
Atish Patra (3):
dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-topology: Move cpu topology code to common code.
RISC-V: Parse cpu topology during boot.
Documentation/devicetree/bindings/arm/topology.txt | 475 -------------------
.../devicetree/bindings/cpu/cpu-topology.txt | 526 +++++++++++++++++++++
arch/arm64/include/asm/topology.h | 23 +-
arch/arm64/kernel/topology.c | 305 +-----------
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/smpboot.c | 6 +-
drivers/base/arch_topology.c | 303 ++++++++++++
include/linux/arch_topology.h | 23 +
include/linux/topology.h | 1 +
9 files changed, 864 insertions(+), 799 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/topology.txt
create mode 100644 Documentation/devicetree/bindings/cpu/cpu-topology.txt
--
2.7.4
^permalinkrawreply [flat|nested] 20+ messages in thread

*[RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-09 1:50 [RFC 0/3] Unify CPU topology across ARM64 & RISC-V atish.patra
@ 2018-11-09 1:50 ` Atish Patra
2018-11-09 1:50 ` [RFC 1/3] dt-binding: cpu-topology: Move cpu-map to a common binding atish.patra
` (3 subsequent siblings)4 siblings, 0 replies; 20+ messages in thread
From: Atish Patra @ 2018-11-09 1:50 UTC (permalink / raw)
To: linux-kernel
Cc: mark.rutland, devicetree, Damien.LeMoal, juri.lelli, anup,
palmer, jeremy.linton, atish.patra, robh+dt, sudeep.holla, mick,
linux-riscv, linux-arm-kernel
The cpu-map DT entry in ARM64 can describe the CPU topology in
much better way compared to other existing approaches. RISC-V can
easily adopt this binding to represent it's own CPU topology.
Thus, both cpu-map DT binding and topology parsing code can be
moved to a common location so that RISC-V or any other
architecture can leverage that.
The relevant discussion regarding unifying cpu topology can be
found in [1].
arch_topology seems to be a perfect place to move the common
code. I have not introduced any functional changes in the moved
to code. The only downside in this approach is that the capacity
code will be executed for RISC-V as well. But, it will exit
immediately after not able to find the appropriate DT node. If
the overhead is considered too much, we can always compile out
capacity related functions under a different config for the
architectures that do not support them.
The patches have been tested for RISC-V and compile tested for
ARM64.
The socket changes[2] can be merged on top of this series or vice
versa.
[1] https://lkml.org/lkml/2018/11/6/19
[2] https://lkml.org/lkml/2018/11/7/918
Atish Patra (3):
dt-binding: cpu-topology: Move cpu-map to a common binding.
cpu-topology: Move cpu topology code to common code.
RISC-V: Parse cpu topology during boot.
Documentation/devicetree/bindings/arm/topology.txt | 475 -------------------
.../devicetree/bindings/cpu/cpu-topology.txt | 526 +++++++++++++++++++++
arch/arm64/include/asm/topology.h | 23 +-
arch/arm64/kernel/topology.c | 305 +-----------
arch/riscv/Kconfig | 1 +
arch/riscv/kernel/smpboot.c | 6 +-
drivers/base/arch_topology.c | 303 ++++++++++++
include/linux/arch_topology.h | 23 +
include/linux/topology.h | 1 +
9 files changed, 864 insertions(+), 799 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/topology.txt
create mode 100644 Documentation/devicetree/bindings/cpu/cpu-topology.txt
--
2.7.4
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv^permalinkrawreply [flat|nested] 20+ messages in thread

*[RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-09 1:50 [RFC 0/3] Unify CPU topology across ARM64 & RISC-V atish.patra
` (3 preceding siblings ...)
2018-11-09 1:50 ` [RFC 3/3] RISC-V: Parse cpu topology during boot atish.patra
@ 2018-11-15 18:31 ` jhugo
2018-11-15 18:31 ` Jeffrey Hugo
` (2 more replies)4 siblings, 3 replies; 20+ messages in thread
From: jhugo @ 2018-11-15 18:31 UTC (permalink / raw)
To: linux-riscv
On 11/8/2018 6:50 PM, Atish Patra wrote:
> The cpu-map DT entry in ARM64 can describe the CPU topology in
> much better way compared to other existing approaches. RISC-V can
> easily adopt this binding to represent it's own CPU topology.
> Thus, both cpu-map DT binding and topology parsing code can be
> moved to a common location so that RISC-V or any other
> architecture can leverage that.
>
> The relevant discussion regarding unifying cpu topology can be
> found in [1].
>
> arch_topology seems to be a perfect place to move the common
> code. I have not introduced any functional changes in the moved
> to code. The only downside in this approach is that the capacity
> code will be executed for RISC-V as well. But, it will exit
> immediately after not able to find the appropriate DT node. If
> the overhead is considered too much, we can always compile out
> capacity related functions under a different config for the
> architectures that do not support them.
>
> The patches have been tested for RISC-V and compile tested for
> ARM64.
>
> The socket changes[2] can be merged on top of this series or vice
> versa.
>
> [1] https://lkml.org/lkml/2018/11/6/19
> [2] https://lkml.org/lkml/2018/11/7/918
>
> Atish Patra (3):
> dt-binding: cpu-topology: Move cpu-map to a common binding.
> cpu-topology: Move cpu topology code to common code.
> RISC-V: Parse cpu topology during boot.
>
> Documentation/devicetree/bindings/arm/topology.txt | 475 -------------------
> .../devicetree/bindings/cpu/cpu-topology.txt | 526 +++++++++++++++++++++
> arch/arm64/include/asm/topology.h | 23 +-
> arch/arm64/kernel/topology.c | 305 +-----------
> arch/riscv/Kconfig | 1 +
> arch/riscv/kernel/smpboot.c | 6 +-
> drivers/base/arch_topology.c | 303 ++++++++++++
> include/linux/arch_topology.h | 23 +
> include/linux/topology.h | 1 +
> 9 files changed, 864 insertions(+), 799 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/topology.txt
> create mode 100644 Documentation/devicetree/bindings/cpu/cpu-topology.txt
>
I was interested in testing these on QDF2400, an ARM64 platform, since
this series touches core ARM64 code and I'd hate to see a regression.
However, I can't figure out what baseline to use to apply these.
Different patches cause different conflicts of a variety of baselines I
attempted.
What are these intended to apply to?
Also, you might want to run them through checkpatch next time. There
are several whitespace errors.
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^permalinkrawreply [flat|nested] 20+ messages in thread

*Re: [RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-15 18:31 ` [RFC 0/3] Unify CPU topology across ARM64 & RISC-V jhugo
@ 2018-11-15 18:31 ` Jeffrey Hugo
2018-11-19 17:46 ` atish.patra
2018-11-20 11:11 ` sudeep.holla2 siblings, 0 replies; 20+ messages in thread
From: Jeffrey Hugo @ 2018-11-15 18:31 UTC (permalink / raw)
To: Atish Patra, linux-kernel
Cc: mark.rutland, devicetree, Damien.LeMoal, juri.lelli, anup,
palmer, jeremy.linton, robh+dt, sudeep.holla, mick, linux-riscv,
linux-arm-kernel
On 11/8/2018 6:50 PM, Atish Patra wrote:
> The cpu-map DT entry in ARM64 can describe the CPU topology in
> much better way compared to other existing approaches. RISC-V can
> easily adopt this binding to represent it's own CPU topology.
> Thus, both cpu-map DT binding and topology parsing code can be
> moved to a common location so that RISC-V or any other
> architecture can leverage that.
>
> The relevant discussion regarding unifying cpu topology can be
> found in [1].
>
> arch_topology seems to be a perfect place to move the common
> code. I have not introduced any functional changes in the moved
> to code. The only downside in this approach is that the capacity
> code will be executed for RISC-V as well. But, it will exit
> immediately after not able to find the appropriate DT node. If
> the overhead is considered too much, we can always compile out
> capacity related functions under a different config for the
> architectures that do not support them.
>
> The patches have been tested for RISC-V and compile tested for
> ARM64.
>
> The socket changes[2] can be merged on top of this series or vice
> versa.
>
> [1] https://lkml.org/lkml/2018/11/6/19
> [2] https://lkml.org/lkml/2018/11/7/918
>
> Atish Patra (3):
> dt-binding: cpu-topology: Move cpu-map to a common binding.
> cpu-topology: Move cpu topology code to common code.
> RISC-V: Parse cpu topology during boot.
>
> Documentation/devicetree/bindings/arm/topology.txt | 475 -------------------
> .../devicetree/bindings/cpu/cpu-topology.txt | 526 +++++++++++++++++++++
> arch/arm64/include/asm/topology.h | 23 +-
> arch/arm64/kernel/topology.c | 305 +-----------
> arch/riscv/Kconfig | 1 +
> arch/riscv/kernel/smpboot.c | 6 +-
> drivers/base/arch_topology.c | 303 ++++++++++++
> include/linux/arch_topology.h | 23 +
> include/linux/topology.h | 1 +
> 9 files changed, 864 insertions(+), 799 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/arm/topology.txt
> create mode 100644 Documentation/devicetree/bindings/cpu/cpu-topology.txt
>
I was interested in testing these on QDF2400, an ARM64 platform, since
this series touches core ARM64 code and I'd hate to see a regression.
However, I can't figure out what baseline to use to apply these.
Different patches cause different conflicts of a variety of baselines I
attempted.
What are these intended to apply to?
Also, you might want to run them through checkpatch next time. There
are several whitespace errors.
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv^permalinkrawreply [flat|nested] 20+ messages in thread

*[RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-15 18:31 ` [RFC 0/3] Unify CPU topology across ARM64 & RISC-V jhugo
2018-11-15 18:31 ` Jeffrey Hugo@ 2018-11-19 17:46 ` atish.patra
2018-11-19 17:46 ` Atish Patra
2018-11-20 11:11 ` sudeep.holla2 siblings, 1 reply; 20+ messages in thread
From: atish.patra @ 2018-11-19 17:46 UTC (permalink / raw)
To: linux-riscv
On 11/15/18 10:31 AM, Jeffrey Hugo wrote:
> On 11/8/2018 6:50 PM, Atish Patra wrote:
>> The cpu-map DT entry in ARM64 can describe the CPU topology in
>> much better way compared to other existing approaches. RISC-V can
>> easily adopt this binding to represent it's own CPU topology.
>> Thus, both cpu-map DT binding and topology parsing code can be
>> moved to a common location so that RISC-V or any other
>> architecture can leverage that.
>>
>> The relevant discussion regarding unifying cpu topology can be
>> found in [1].
>>
>> arch_topology seems to be a perfect place to move the common
>> code. I have not introduced any functional changes in the moved
>> to code. The only downside in this approach is that the capacity
>> code will be executed for RISC-V as well. But, it will exit
>> immediately after not able to find the appropriate DT node. If
>> the overhead is considered too much, we can always compile out
>> capacity related functions under a different config for the
>> architectures that do not support them.
>>
>> The patches have been tested for RISC-V and compile tested for
>> ARM64.
>>
>> The socket changes[2] can be merged on top of this series or vice
>> versa.
>>
>> [1] https://lkml.org/lkml/2018/11/6/19
>> [2] https://lkml.org/lkml/2018/11/7/918
>>
>> Atish Patra (3):
>> dt-binding: cpu-topology: Move cpu-map to a common binding.
>> cpu-topology: Move cpu topology code to common code.
>> RISC-V: Parse cpu topology during boot.
>>
>> Documentation/devicetree/bindings/arm/topology.txt | 475 -------------------
>> .../devicetree/bindings/cpu/cpu-topology.txt | 526 +++++++++++++++++++++
>> arch/arm64/include/asm/topology.h | 23 +-
>> arch/arm64/kernel/topology.c | 305 +-----------
>> arch/riscv/Kconfig | 1 +
>> arch/riscv/kernel/smpboot.c | 6 +-
>> drivers/base/arch_topology.c | 303 ++++++++++++
>> include/linux/arch_topology.h | 23 +
>> include/linux/topology.h | 1 +
>> 9 files changed, 864 insertions(+), 799 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/arm/topology.txt
>> create mode 100644 Documentation/devicetree/bindings/cpu/cpu-topology.txt
>>
>
> I was interested in testing these on QDF2400, an ARM64 platform, since
> this series touches core ARM64 code and I'd hate to see a regression.
> However, I can't figure out what baseline to use to apply these.
> Different patches cause different conflicts of a variety of baselines I
> attempted.
>
> What are these intended to apply to?
>
I had rebased them on top of 4.20-rc1.
> Also, you might want to run them through checkpatch next time. There
> are several whitespace errors.
>
Sorry I missed couple of them.
Thanks for trying to test the patches. I will send a next version as Rob
suggested. Please test that.
Regards,
Atish
^permalinkrawreply [flat|nested] 20+ messages in thread

*Re: [RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-19 17:46 ` atish.patra@ 2018-11-19 17:46 ` Atish Patra0 siblings, 0 replies; 20+ messages in thread
From: Atish Patra @ 2018-11-19 17:46 UTC (permalink / raw)
To: Jeffrey Hugo, linux-kernel
Cc: mark.rutland, devicetree, Damien Le Moal, juri.lelli, anup,
palmer, jeremy.linton, robh+dt, sudeep.holla, mick, linux-riscv,
linux-arm-kernel
On 11/15/18 10:31 AM, Jeffrey Hugo wrote:
> On 11/8/2018 6:50 PM, Atish Patra wrote:
>> The cpu-map DT entry in ARM64 can describe the CPU topology in
>> much better way compared to other existing approaches. RISC-V can
>> easily adopt this binding to represent it's own CPU topology.
>> Thus, both cpu-map DT binding and topology parsing code can be
>> moved to a common location so that RISC-V or any other
>> architecture can leverage that.
>>
>> The relevant discussion regarding unifying cpu topology can be
>> found in [1].
>>
>> arch_topology seems to be a perfect place to move the common
>> code. I have not introduced any functional changes in the moved
>> to code. The only downside in this approach is that the capacity
>> code will be executed for RISC-V as well. But, it will exit
>> immediately after not able to find the appropriate DT node. If
>> the overhead is considered too much, we can always compile out
>> capacity related functions under a different config for the
>> architectures that do not support them.
>>
>> The patches have been tested for RISC-V and compile tested for
>> ARM64.
>>
>> The socket changes[2] can be merged on top of this series or vice
>> versa.
>>
>> [1] https://lkml.org/lkml/2018/11/6/19
>> [2] https://lkml.org/lkml/2018/11/7/918
>>
>> Atish Patra (3):
>> dt-binding: cpu-topology: Move cpu-map to a common binding.
>> cpu-topology: Move cpu topology code to common code.
>> RISC-V: Parse cpu topology during boot.
>>
>> Documentation/devicetree/bindings/arm/topology.txt | 475 -------------------
>> .../devicetree/bindings/cpu/cpu-topology.txt | 526 +++++++++++++++++++++
>> arch/arm64/include/asm/topology.h | 23 +-
>> arch/arm64/kernel/topology.c | 305 +-----------
>> arch/riscv/Kconfig | 1 +
>> arch/riscv/kernel/smpboot.c | 6 +-
>> drivers/base/arch_topology.c | 303 ++++++++++++
>> include/linux/arch_topology.h | 23 +
>> include/linux/topology.h | 1 +
>> 9 files changed, 864 insertions(+), 799 deletions(-)
>> delete mode 100644 Documentation/devicetree/bindings/arm/topology.txt
>> create mode 100644 Documentation/devicetree/bindings/cpu/cpu-topology.txt
>>
>
> I was interested in testing these on QDF2400, an ARM64 platform, since
> this series touches core ARM64 code and I'd hate to see a regression.
> However, I can't figure out what baseline to use to apply these.
> Different patches cause different conflicts of a variety of baselines I
> attempted.
>
> What are these intended to apply to?
>
I had rebased them on top of 4.20-rc1.
> Also, you might want to run them through checkpatch next time. There
> are several whitespace errors.
>
Sorry I missed couple of them.
Thanks for trying to test the patches. I will send a next version as Rob
suggested. Please test that.
Regards,
Atish
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv^permalinkrawreply [flat|nested] 20+ messages in thread

*[RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-15 18:31 ` [RFC 0/3] Unify CPU topology across ARM64 & RISC-V jhugo
2018-11-15 18:31 ` Jeffrey Hugo
2018-11-19 17:46 ` atish.patra@ 2018-11-20 11:11 ` sudeep.holla
2018-11-20 11:11 ` Sudeep Holla
2018-11-20 15:28 ` jhugo2 siblings, 2 replies; 20+ messages in thread
From: sudeep.holla @ 2018-11-20 11:11 UTC (permalink / raw)
To: linux-riscv
On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote:
[...]
>
> I was interested in testing these on QDF2400, an ARM64 platform, since this
> series touches core ARM64 code and I'd hate to see a regression. However, I
> can't figure out what baseline to use to apply these. Different patches
> cause different conflicts of a variety of baselines I attempted.
>
Good to know that we can test DT configuration on QDF2400. I always assumed
it's ACPI only.
> What are these intended to apply to?
>
The series alone may not get the package/socket ids correct on QDF2400.
I have not yet added support for the same as I wanted to get the initial
feedback on DT bindings. The movement of DT binding and corresponding
code should not regress and you should be able to validate only that
part.
--
Regards,
Sudeep
^permalinkrawreply [flat|nested] 20+ messages in thread

*Re: [RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-20 11:11 ` sudeep.holla@ 2018-11-20 11:11 ` Sudeep Holla
2018-11-20 15:28 ` jhugo1 sibling, 0 replies; 20+ messages in thread
From: Sudeep Holla @ 2018-11-20 11:11 UTC (permalink / raw)
To: Jeffrey Hugo
Cc: mark.rutland, devicetree, Damien.LeMoal, juri.lelli, anup,
palmer, linux-kernel, jeremy.linton, Atish Patra, robh+dt, mick,
linux-riscv, linux-arm-kernel
On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote:
[...]
>
> I was interested in testing these on QDF2400, an ARM64 platform, since this
> series touches core ARM64 code and I'd hate to see a regression. However, I
> can't figure out what baseline to use to apply these. Different patches
> cause different conflicts of a variety of baselines I attempted.
>
Good to know that we can test DT configuration on QDF2400. I always assumed
it's ACPI only.
> What are these intended to apply to?
>
The series alone may not get the package/socket ids correct on QDF2400.
I have not yet added support for the same as I wanted to get the initial
feedback on DT bindings. The movement of DT binding and corresponding
code should not regress and you should be able to validate only that
part.
--
Regards,
Sudeep
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv^permalinkrawreply [flat|nested] 20+ messages in thread

*[RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-20 11:11 ` sudeep.holla
2018-11-20 11:11 ` Sudeep Holla@ 2018-11-20 15:28 ` jhugo
2018-11-20 15:28 ` Jeffrey Hugo1 sibling, 1 reply; 20+ messages in thread
From: jhugo @ 2018-11-20 15:28 UTC (permalink / raw)
To: linux-riscv
On 11/20/2018 4:11 AM, Sudeep Holla wrote:
> On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote:
>
> [...]
>
>>
>> I was interested in testing these on QDF2400, an ARM64 platform, since this
>> series touches core ARM64 code and I'd hate to see a regression. However, I
>> can't figure out what baseline to use to apply these. Different patches
>> cause different conflicts of a variety of baselines I attempted.
>>
>
> Good to know that we can test DT configuration on QDF2400. I always assumed
> it's ACPI only.
It is ACPI only in the production configuration. I suppose we could
hack things up to do basic DT sanity, but I expect it would be nasty and
non-trivial.
>
>> What are these intended to apply to?
>>
>
> The series alone may not get the package/socket ids correct on QDF2400.
> I have not yet added support for the same as I wanted to get the initial
> feedback on DT bindings. The movement of DT binding and corresponding
> code should not regress and you should be able to validate only that
> part.
>
On a cursory glance, it looks like some of the reorganized code would
also be used in the ACPI path (things that are common between DT and
ACPI). I do not expect problems, but I still feel its prudent to do a
sanity check on actual hardware.
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^permalinkrawreply [flat|nested] 20+ messages in thread

*Re: [RFC 0/3] Unify CPU topology across ARM64 & RISC-V
2018-11-20 15:28 ` jhugo@ 2018-11-20 15:28 ` Jeffrey Hugo0 siblings, 0 replies; 20+ messages in thread
From: Jeffrey Hugo @ 2018-11-20 15:28 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland, devicetree, Damien.LeMoal, juri.lelli, anup,
palmer, linux-kernel, jeremy.linton, Atish Patra, robh+dt, mick,
linux-riscv, linux-arm-kernel
On 11/20/2018 4:11 AM, Sudeep Holla wrote:
> On Thu, Nov 15, 2018 at 11:31:33AM -0700, Jeffrey Hugo wrote:
>
> [...]
>
>>
>> I was interested in testing these on QDF2400, an ARM64 platform, since this
>> series touches core ARM64 code and I'd hate to see a regression. However, I
>> can't figure out what baseline to use to apply these. Different patches
>> cause different conflicts of a variety of baselines I attempted.
>>
>
> Good to know that we can test DT configuration on QDF2400. I always assumed
> it's ACPI only.
It is ACPI only in the production configuration. I suppose we could
hack things up to do basic DT sanity, but I expect it would be nasty and
non-trivial.
>
>> What are these intended to apply to?
>>
>
> The series alone may not get the package/socket ids correct on QDF2400.
> I have not yet added support for the same as I wanted to get the initial
> feedback on DT bindings. The movement of DT binding and corresponding
> code should not regress and you should be able to validate only that
> part.
>
On a cursory glance, it looks like some of the reorganized code would
also be used in the ACPI path (things that are common between DT and
ACPI). I do not expect problems, but I still feel its prudent to do a
sanity check on actual hardware.
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv^permalinkrawreply [flat|nested] 20+ messages in thread