Re: Adding new ARC platforms (was Re: Handling stub code for new platforms)
On 08/13/2017 10:34 AM, Vineet Gupta wrote: On 08/11/2017 10:55 PM, Alexandru Gagniuc wrote: I was hoping to avoid the addition of extra source files for zero code gain, though your proposal does work. However, since the platform would be added unconditionally, would it make more sense to add the .compatible = "adaptrum,anarion" Actual Abilis TB10x is similar in terms of need for special platform callbacks, but they do need Kconfig glue to pull in bunch of drivers, your platform doesn't ? I was planning to pull in optional drivers via '_defconfig' rather than Kconfig rules. I might need it to pull in the reset drivers, depending on how simple-reset turns out. I'll submit v3, and then we can look if it's a good idea or not to add to -nsim. Alex -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Adding new ARC platforms (was Re: Handling stub code for new platforms)
On 08/11/2017 10:55 PM, Alexandru Gagniuc wrote: I was hoping to avoid the addition of extra source files for zero code gain, though your proposal does work. However, since the platform would be added unconditionally, would it make more sense to add the .compatible = "adaptrum,anarion" Actual Abilis TB10x is similar in terms of need for special platform callbacks, but they do need Kconfig glue to pull in bunch of drivers, your platform doesn't ? -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Adding new ARC platforms (was Re: Handling stub code for new platforms)
On 08/11/2017 10:55 PM, Alexandru Gagniuc wrote: Does that work for you ? I was hoping to avoid the addition of extra source files for zero code gain, though your proposal does work. However, since the platform would be added unconditionally, would it make more sense to add the .compatible = "adaptrum,anarion" binding to plat-nsim instead of creating new files? Yeah that is indeed better. But we have a convention to name SoC binding starting with arc-*. Look at other ARC SoC bindings. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Adding new ARC platforms (was Re: Handling stub code for new platforms)
Hi Vineet,
On 08/10/2017 06:07 PM, Vineet Gupta wrote:
Hi Alexandru,
On 08/11/2017 12:58 AM, Alexandru Gagniuc wrote:
Hi,
Looking under arch/arc, I see the current way is to add a
plat-[socname] for each new SoC. However, it seems that plat-sim, and
plat-tb10x are just place-holders for the compatible bindings.
I was going to do the same for plat-anarion, which required an early
boot workaround. However, with Alexey's INTC patch, this workaround is
no longer required, so plat-anarion would become just another stub.
I don't like the idea of adding dead code whenever a new platform
arrives. My thought is to merge these into a plat-generic, and add the
following two compatible bindings:
* "snps,arccompact-generic"
* "snps,arcv2-generic"
Keep the existing bindings for compatibility reasons, but require all
new platforms that don't need boot stubs to use one of the generic
.compatible bindings. Do you agree with the plan?
Your proposal is reasonable but I'd still prefer the explicit
platform/soC binding for calling out the various arc based platforms if
nothing else !
However the boilerplate code can be pretty minimal ! If the platform is
simple enough, no need for any new Kconfig entries. I've already
eliminated CONFIG_ARC_PLAT_SIM (look at my #for-curr in kernel.org repo
/ linux-next)
So you just need to
1. create plat-xxx/{Makefile, platform.c} and a simple board
description in latter.
2. And add this platform unconditionally to arch/arc/Makefile
Does that work for you ?
I was hoping to avoid the addition of extra source files for zero code
gain, though your proposal does work. However, since the platform would
be added unconditionally, would it make more sense to add the
.compatible = "adaptrum,anarion"
binding to plat-nsim instead of creating new files?
Alex
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Adding new ARC platforms (was Re: Handling stub code for new platforms)
Hi Alexandru,
On 08/11/2017 12:58 AM, Alexandru Gagniuc wrote:
Hi,
Looking under arch/arc, I see the current way is to add a plat-[socname] for each
new SoC. However, it seems that plat-sim, and plat-tb10x are just place-holders
for the compatible bindings.
I was going to do the same for plat-anarion, which required an early boot
workaround. However, with Alexey's INTC patch, this workaround is no longer
required, so plat-anarion would become just another stub.
I don't like the idea of adding dead code whenever a new platform arrives. My
thought is to merge these into a plat-generic, and add the following two
compatible bindings:
* "snps,arccompact-generic"
* "snps,arcv2-generic"
Keep the existing bindings for compatibility reasons, but require all new
platforms that don't need boot stubs to use one of the generic .compatible
bindings. Do you agree with the plan?
Your proposal is reasonable but I'd still prefer the explicit platform/soC binding
for calling out the various arc based platforms if nothing else !
However the boilerplate code can be pretty minimal ! If the platform is simple
enough, no need for any new Kconfig entries. I've already eliminated
CONFIG_ARC_PLAT_SIM (look at my #for-curr in kernel.org repo / linux-next)
So you just need to
1. create plat-xxx/{Makefile, platform.c} and a simple board description in
latter.
2. And add this platform unconditionally to arch/arc/Makefile
Does that work for you ?
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
