On 01/11/2016 04:27 PM, Bruce Ashfield wrote:
On 16-01-08 10:51 AM, Daniel Dragomir wrote:
Hi Bruce,
Please apply this series of fixes to Axxia platform drivers on
the standard/axxia/base branch from linux-yocto-4.1.
This series of patches brings various improvements and warning fixes
to the Intel Axxia drivers including MISC, PCI, FEMAC, SPI/PL022, GPDMA
and device trees.
Bruce, I also have 2 questions:
Why there is no preempt-rt branch for axxia? There is somethimg else we
(axxia team) need to provide?
There is a preempt-rt branch for axxia. I created it in December
when I heard that the axxia had been tested against -rt and all
was well.
I just applied these changes to both standard and -rt:
To ssh://g...@git.yoctoproject.org/linux-yocto-4.1.git
43eb4b9e7be4..b7ab684f37ea standard/axxia/base -> standard/axxia/base
1ab6bfefd66f..606adeec8d66 standard/preempt-rt/axxia/base ->
standard/preempt-rt/axxia/base
Thank you, Bruce!
And sorry, I missed the preempt-rt branch. Everything is ok.
Axxia team keep in their Github repos some defconfig files in
arch/<ARCH>/configs,
not full configs, only fragments that are just like the ones that are
already in
the yocto repo in the same location. Those are used when the kernel
is built
standalone with make. When the kernel is built with bitbake,
fragments from meta-axxia
layer and from meta branch (or yocto-kernel-cache repo) are used.
At each rebase, we need to save and (re)add those files to our repo
to be able to
keep and maintain those.
There is a posibility to have those defconfig files in the yocto repo
also? It will
be easier to maintain and keep them. At least some of them, the
standard and debug
defconfigs. We have, for 4.1 the folowing defconfigs:
That set of defconfigs, shows some of the most significant issue
with defconfigs. The number of them, and the churn to keep them
updated.
And by fragments, not defconfigs, do you mean that they are not
full configs, but are otherwise single file configs for the kernel
(that are largely just not tracking default values for options ?
aka savedefconfig ?).
Yes, exactly.
Our configs are created using "make savedefconfig".
The problem with maintaining the defconfigs in the linux-yocto
tree, is ensuring that they are kept in sync, the risk of divergence
from standard features shared by the other BSPs .. and that they'll
be used "out of habit".
We can easily construct configs from fragments without involving
bitbake or the rest of the build system.
How can I generate a final config from fragments without bitbake? I
guess there will be used only the fragments from meta branch. What about
the fragments from the meta-axxia layer? Those can be used without bitbake?
So out of curiosity, is it
end users, or developers that are the main consumer of the defconfigs ?
*//*Intel uses them internally for test builds based on our
private/public Linux repositories (from Github, not the Yocto
repository). Our customers either use their own repositories/builds or
WindRiver Linux. (John Jacques)
So, the main consumers of those defconfigs are the Axxia developers.
Daniel
Bruce
arch/arm/configs/axxia_5500_dbg_defconfig
arch/arm/configs/axxia_5500_defconfig
arch/arm/configs/axxia_5500_nosmp_dbg_defconfig
arch/arm/configs/axxia_5500_nosmp_defconfig
arch/arm/configs/axxia_5500_rt_dbg_defconfig
arch/arm/configs/axxia_5500_rt_defconfig
arch/arm/configs/axxia_5500_rt_nosmp_dbg_defconfig
arch/arm/configs/axxia_5500_rt_nosmp_defconfig
arch/arm64/configs/axxia_x9_dbg_defconfig
arch/arm64/configs/axxia_x9_defconfig
arch/arm64/configs/axxia_x9_nosmp_dbg_defconfig
arch/arm64/configs/axxia_x9_nosmp_defconfig
arch/arm64/configs/axxia_x9_rt_dbg_defconfig
arch/arm64/configs/axxia_x9_rt_defconfig
arch/arm64/configs/axxia_x9_rt_nosmp_dbg_defconfig
arch/arm64/configs/axxia_x9_rt_nosmp_defconfig
arch/arm64/configs/axxia_xlf_dbg_defconfig
arch/arm64/configs/axxia_xlf_defconfig
arch/arm64/configs/axxia_xlf_nosmp_dbg_defconfig
arch/arm64/configs/axxia_xlf_nosmp_defconfig
arch/arm64/configs/axxia_xlf_rt_dbg_defconfig
arch/arm64/configs/axxia_xlf_rt_defconfig
arch/arm64/configs/axxia_xlf_rt_nosmp_dbg_defconfig
arch/arm64/configs/axxia_xlf_nosmp_defconfig
arch/arm64/configs/axxia_xlf_rt_dbg_defconfig
arch/arm64/configs/axxia_xlf_rt_defconfig
arch/arm64/configs/axxia_xlf_rt_nosmp_dbg_defconfig
arch/arm64/configs/axxia_xlf_rt_nosmp_defconfig
Thank you,
Daniel
John Jacques (15):
drivers/dma: Remove Unused Code in the LSI GPDMA Driver
drivers/clk: Remove Warnings in Axxia Clock Driver
drivers/power: Cleanup Warnings in Axxia Reset Code
drivers/spi: Cleanup Warnings in PL022 Driver
drivers/net: Fix Compiler Warnings in the Axxia FEMAC Driver
pmu: Fix Compiler Warnings
arch/arm: Fix Compiler Warnings
drivers/misc: Fix Compile Warnings in the Axxia MTC Driver
arch/arm/mach-axxia: Fix Compile Warnings
arch/arm: Backport a Change to Fix Compiler Warnings
include/linux: Resolve Compile Warning
drivers/pci: Fix Error in Axxia PCIe Code
arch/arm: Fix Build Failure When CONFIG_SMP=n
drivers/misc: Fix Compile Warning in Axxia MTC Driver
axxia: Device Tree Updates
arch/arm/include/asm/cmpxchg.h | 18 +-
arch/arm/include/asm/kmap_types.h | 6 +-
arch/arm/mach-axxia/axxia.c | 2 +-
arch/arm64/boot/dts/intel/axc67xx-sim.dtsi | 566
-----------------------------
arch/arm64/boot/dts/intel/axm5604-sim.dts | 8 -
arch/arm64/boot/dts/intel/axm56xx-sim.dtsi | 393 --------------------
drivers/clk/clk-axm5516.c | 2 +-
drivers/dma/lsi-dma32.c | 44 ---
drivers/misc/lsi-mtc.c | 4 +-
drivers/net/ethernet/lsi/lsi-femac.c | 53 +--
drivers/pci/host/axxia_pci.c | 5 +-
drivers/power/reset/axxia-reset.c | 2 +-
drivers/spi/spi-pl022.c | 51 ---
include/linux/blkdev.h | 2 +-
include/linux/pmu.h | 1 +
15 files changed, 35 insertions(+), 1122 deletions(-)
delete mode 100644 arch/arm64/boot/dts/intel/axc67xx-sim.dtsi
delete mode 100644 arch/arm64/boot/dts/intel/axm56xx-sim.dtsi
--
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
