pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
Subsystems (2)
PATCH 1/1 pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
---
Found this build issue whilst browsing kautobuild logs. There may well be a better fix but until someone with a board in ARCH_MMP can test it, lets just not build pmu.c. Can't find equivalent fix in Eric's tree so I think this is still a live problem.
arch/arm/plat-pxa/Makefile | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
arch/arm/plat-pxa/Makefile +2 -1
@@ -2,8 +2,9 @@ # Makefile for code common across different PXA processor families # -obj-y := dma.o pmu.o +obj-y := dma.o +obj-$(CONFIG_ARCH_PXA) += pmu.o obj-$(CONFIG_GENERIC_GPIO) += gpio.o obj-$(CONFIG_PXA3xx) += mfp.o obj-$(CONFIG_ARCH_MMP) += mfp.o
Signature · 1 line
1.6.4.4
PATCH 1/1 pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
2010/6/8 Jonathan Cameron <[email protected]>:
Quoted 8 lines
Signed-off-by Jonathan Cameron <[email protected]>---
?Found this build issue whilst browsing kautobuild logs. ?There may well be a better fix but until someone with ?a board inARCH_MMPcan test it, lets just not build ?pmu.c. ?Can't find equivalent fix in Eric's tree so I ?think this is still a live problem.
When building pxa168 platform, IRQ_PMU cannot be find and error occurs. Eric, before delete it from MMP, should not we check whether the performance counter function
is necessary for MMP or not?
If necessary , we should fix this issue by define IRQ_PMU to IRQ_PXA168_PMU, or we can delete it.
Quoted 27 lines
?arch/arm/plat-pxa/Makefile | ? ?3 ++-
?1 files changed, 2 insertions(+), 1 deletions(-)arch/arm/plat-pxa/Makefile +0
-0@@ -2,8 +2,9 @@?#
Makefilefor code common across different PXA processor families ?#arch/arm/plat-pxa/Makefile +2
-1-obj-y ?:= dma.o pmu.o +obj-y ?:= dma.o +obj-$(CONFIG_ARCH_PXA) ? ? ? ? += pmu.o?obj-$(CONFIG_GENERIC_GPIO) ? ? += gpio.o
?obj-$(CONFIG_PXA3xx) ? ? ? ? ? += mfp.o
?obj-$(CONFIG_ARCH_MMP) ? ? ? ? += mfp.o
--
1.6.4.4_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Signature · 10 lines
*linux-arm-kernel mailing list mail addr:linux-arm-kernel at lists.infradead.org you can subscribe by: http://lists.infradead.org/mailman/listinfo/linux-arm-kernel * linux-arm-NUC900 mailing list mail addr:NUC900 at googlegroups.com main web: https://groups.google.com/group/NUC900 you can subscribe it by sending me mail: mcuos.com at gmail.com
PATCH 1/1 pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
Quoted 10 lines · Wan ZongShun
2010/6/8 Jonathan Cameron <[email protected]>:
Quoted 8 lines
Signed-off-by Jonathan Cameron <[email protected]>---
?Found this build issue whilst browsing kautobuild logs. ?There may well be a better fix but until someone with ?a board inARCH_MMPcan test it, lets just not build ?pmu.c. ?Can't find equivalent fix in Eric's tree so I ?think this is still a live problem.
Quoted 8 lines
When building pxa168 platform,
IRQ_PMUcannot be find and error occurs. Eric, before delete it from MMP, should not we check whether the performance counter function
is necessary for MMP or not?If necessary , we should fix this issue by define
IRQ_PMUtoIRQ_PXA168_PMU, or we can delete it.
We have different ways to handle this:
1. register different platform devices with different IRQs for pxa[23]xx, pxa168
2. modify the IRQ at run-time to a correct one
3. move the platform device registration back into arch/arm/mach-pxa/<soc>.c (or arch/arm/mach-pxa/common.c) and arch/arm/mach-mmp/<soc>.c
We need to figure out if there are some other differences between these PMUs (or in the future), which will make solution 3) stand out.
Quoted 42 lines
Quoted 22 lines
?arch/arm/plat-pxa/Makefile | ? ?3 ++-
?1 files changed, 2 insertions(+), 1 deletions(-)arch/arm/plat-pxa/Makefile +0
-0@@ -2,8 +2,9 @@?#
Makefilefor code common across different PXA processor families ?#arch/arm/plat-pxa/Makefile +2
-1-obj-y ?:= dma.o pmu.o +obj-y ?:= dma.o +obj-$(CONFIG_ARCH_PXA) ? ? ? ? += pmu.o?obj-$(CONFIG_GENERIC_GPIO) ? ? += gpio.o
?obj-$(CONFIG_PXA3xx) ? ? ? ? ? += mfp.o
?obj-$(CONFIG_ARCH_MMP) ? ? ? ? += mfp.o
--
1.6.4.4Quoted 5 lines
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel--
*linux-arm-kernel mailing list
mail addr:linux-arm-kernel at lists.infradead.org
you can subscribe by:
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel* linux-arm-NUC900 mailing list
mail addr:NUC900 at googlegroups.com
main web: https://groups.google.com/group/NUC900
you can subscribe it by sending me mail:
mcuos.com at gmail.com
PATCH 1/1 pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
Hi Eric,
Quoted 6 lines
We have different ways to handle this:
1. register different platform devices with different IRQs for pxa[23]xx, pxa168
2. modify the IRQ at run-time to a correct one
3. move the platform device registration back into arch/arm/mach-pxa/<soc>.c (orarch/arm/mach-pxa/common.c) and arch/arm/mach-mmp/<soc>.c
For the RealView boards, we take approach number (1). This is largely for two reasons:
1.) The PMU IRQ doesn't have a consistent naming scheme 2.) SMP RealView platforms need to have an extra resource in the
platform_device for each CPU.
However, looking at the PXA168 description and the perf-events code, I don't think we support the PMU anyway [see init_hw_perf_events in arch/arm/kernel/perf_event.c]. If the PMU present is accessible in the same way as one of the other supported PMUs, then it would be easy to add it to the perf-events code. Otherwise, a new PMU driver will need to be written if people want to use it.
Without access to a TRM, I can't tell whether or not supporting the PMU is trivial, so I guess we go with option (3) for the time being.
Quoted 2 lines
We need to figure out if there are some other differences between these PMUs (or in the future), which will make solution 3) stand out.
In the future I reckon PMU devices will be memory-mapped and live inside components other than the CPU. PMU registration will then be highly SoC-specific. Perf events doesn't yet support any of this, so it depends how future-proof you want to be!
Will
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
arch/arm/plat-pxa/Makefile | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)arch/arm/plat-pxa/Makefile +2
-2@@ -2,8 +2,9 @@ # Makefile for code common across different PXA processor families # -obj-y := dma.o pmu.o +obj-y := dma.o +obj-$(CONFIG_ARCH_PXA) += pmu.o obj-$(CONFIG_GENERIC_GPIO) += gpio.o obj-$(CONFIG_PXA3xx) += mfp.o obj-$(CONFIG_ARCH_MMP) += mfp.o --1.6.4.4
A message that is not in the archive (sent off-list or not yet received): 3623778261485640027@unknownmsgid
PATCH 1/1 pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
Quoted 26 lines · Will Deacon
Hi Eric,
Quoted 6 lines
We have different ways to handle this:
1. register different platform devices with different IRQs for pxa[23]xx, pxa168
2. modify the IRQ at run-time to a correct one
3. move the platform device registration back into arch/arm/mach-pxa/<soc>.c (orarch/arm/mach-pxa/common.c) and arch/arm/mach-mmp/<soc>.cFor the RealView boards, we take approach number (1). This is largely for two reasons:
1.) The PMU IRQ doesn't have a consistent naming scheme 2.) SMP RealView platforms need to have an extra resource in the ? ?platform_device for each CPU.
However, looking at the PXA168 description and the perf-events code, I don't think we support the PMU anyway [see
init_hw_perf_eventsinarch/arm/kernel/perf_event.c]. If the PMU present is accessible in the same way as one of the other supported PMUs, then it would be easy to add it to the perf-events code. Otherwise, a new PMU driver will need to be written if people want to use it.Without access to a TRM, I can't tell whether or not supporting the PMU is trivial, so I guess we go with option (3) for the time being.
Quoted 8 lines
Quoted 2 lines
We need to figure out if there are some other differences between these PMUs (or in the future), which will make solution 3) stand out.
In the future I reckon PMU devices will be memory-mapped and live inside components other than the CPU. PMU registration will then be highly SoC-specific. Perf events doesn't yet support any of this, so it depends how future-proof you want to be!
For a quick solution of the build error, I decided to pick Jonathan's patch first. At least PMU is not tested and ever used on pxa168/910/mmp2 series at this moment. I'll work on a proper fix later, possibly a patch merged through -devel branch instead of -fix.
Quoted 24 lines
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
?arch/arm/plat-pxa/Makefile | ? ?3 ++-
?1 files changed, 2 insertions(+), 1 deletions(-)arch/arm/plat-pxa/Makefile +0
-0@@ -2,8 +2,9 @@?#
Makefilefor code common across different PXA processor families ?#arch/arm/plat-pxa/Makefile +2
-1-obj-y ?:= dma.o pmu.o +obj-y ?:= dma.o +obj-$(CONFIG_ARCH_PXA) ? ? ? ? += pmu.o?obj-$(CONFIG_GENERIC_GPIO) ? ? += gpio.o
?obj-$(CONFIG_PXA3xx) ? ? ? ? ? += mfp.o
?obj-$(CONFIG_ARCH_MMP) ? ? ? ? += mfp.o
--
1.6.4.4
PATCH 1/1 pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU
2010/6/14 Eric Miao <[email protected]>:
Quoted 36 lines · Will Deacon
Quoted 26 lines
Hi Eric,
Quoted 6 lines
We have different ways to handle this:
1. register different platform devices with different IRQs for pxa[23]xx, pxa168
2. modify the IRQ at run-time to a correct one
3. move the platform device registration back into arch/arm/mach-pxa/<soc>.c (orarch/arm/mach-pxa/common.c) and arch/arm/mach-mmp/<soc>.cFor the RealView boards, we take approach number (1). This is largely for two reasons:
1.) The PMU IRQ doesn't have a consistent naming scheme 2.) SMP RealView platforms need to have an extra resource in the ? ?platform_device for each CPU.
However, looking at the PXA168 description and the perf-events code, I don't think we support the PMU anyway [see
init_hw_perf_eventsinarch/arm/kernel/perf_event.c]. If the PMU present is accessible in the same way as one of the other supported PMUs, then it would be easy to add it to the perf-events code. Otherwise, a new PMU driver will need to be written if people want to use it.Without access to a TRM, I can't tell whether or not supporting the PMU is trivial, so I guess we go with option (3) for the time being.
Quoted 8 lines
Quoted 2 lines
We need to figure out if there are some other differences between these PMUs (or in the future), which will make solution 3) stand out.
In the future I reckon PMU devices will be memory-mapped and live inside components other than the CPU. PMU registration will then be highly SoC-specific. Perf events doesn't yet support any of this, so it depends how future-proof you want to be!
Quoted 5 lines
For a quick solution of the build error, I decided to pick Jonathan's patch first. At least PMU is not tested and ever used on pxa168/910/mmp2 series at this moment. I'll work on a proper fix later, possibly a patch merged through -devel branch instead of -fix.
Good idea. thanks!
Quoted 25 lines
Quoted 24 lines
Quoted 21 lines
Quoted 21 lines
Quoted 21 lines
?arch/arm/plat-pxa/Makefile | ? ?3 ++-
?1 files changed, 2 insertions(+), 1 deletions(-)arch/arm/plat-pxa/Makefile +0
-0@@ -2,8 +2,9 @@?#
Makefilefor code common across different PXA processor families ?#arch/arm/plat-pxa/Makefile +2
-1-obj-y ?:= dma.o pmu.o +obj-y ?:= dma.o +obj-$(CONFIG_ARCH_PXA) ? ? ? ? += pmu.o?obj-$(CONFIG_GENERIC_GPIO) ? ? += gpio.o
?obj-$(CONFIG_PXA3xx) ? ? ? ? ? += mfp.o
?obj-$(CONFIG_ARCH_MMP) ? ? ? ? += mfp.o
--
1.6.4.4
Signature · 10 lines
*linux-arm-kernel mailing list mail addr:linux-arm-kernel at lists.infradead.org you can subscribe by: http://lists.infradead.org/mailman/listinfo/linux-arm-kernel * linux-arm-NUC900 mailing list mail addr:NUC900 at googlegroups.com main web: https://groups.google.com/group/NUC900 you can subscribe it by sending me mail: mcuos.com at gmail.com