Skip to contentSkip to conversation

pxa168 and pxa930 build fix - plat-pxa/pmu.c dependent on ARCH_PXA for IRQ_PMU

PATCH New Jonathan Cameron 4 participants 6 messages Jun 7, 2010 – Jun 13, 2010 1 message not in the archive

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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
index 6187edf..a17cc0c 100644
@@ -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
#1 lore raw

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

---
?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.

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
index 6187edf..a17cc0c 100644
@@ -2,8 +2,9 @@

?# Makefile for 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
#2 lore raw

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

---
?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.

Quoted 8 lines

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.

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
index 6187edf..a17cc0c 100644
@@ -2,8 +2,9 @@

?# Makefile for 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

Quoted 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

#3 lore raw

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 (or arch/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
index 6187edf..a17cc0c 100644
@@ -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

#5 lore raw

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 (or arch/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 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
index 6187edf..a17cc0c 100644
@@ -2,8 +2,9 @@

?# Makefile for 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

#6 lore raw

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 (or arch/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 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
index 6187edf..a17cc0c 100644
@@ -2,8 +2,9 @@

?# Makefile for 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