Add the Performance Monitoring Unit to the Trimslice device tree
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 24 lines · William Cohen
The tegra processor has a performance monitoring unit. However, this was not listed on the
board-trimslice.cdevices. This patch adds it to the list of devices and allows one to use hardware performance monitoring events on the trimslice machine.Signed-off-by William Cohen <[email protected]>--- arch/arm/mach-tegra/board-trimslice.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)arch/arm/mach-tegra/board-trimslice.c +1
-0@@ -82,6 +82,7 @@ static struct platform_device trimslice_audio_device = {static struct platform_device *trimslice_devices[]__initdata = { &debug_uart, + &tegra_pmu_device, &tegra_sdhci_device1, &tegra_sdhci_device4, &tegra_i2s_device1,Signature · 1 line
1.7.5.2
Olof - would you be able to pick this up please? I've not been able to test it, but since the device is already defined I'm assuming the IRQ numbers are correct.
Cheers,
Will
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 30 lines · Will Deacon
Quoted 24 lines · William Cohen
The tegra processor has a performance monitoring unit. However, this was not listed on the
board-trimslice.cdevices. This patch adds it to the list of devices and allows one to use hardware performance monitoring events on the trimslice machine.Signed-off-by William Cohen <[email protected]>--- arch/arm/mach-tegra/board-trimslice.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)arch/arm/mach-tegra/board-trimslice.c +1
-0@@ -82,6 +82,7 @@ static struct platform_device trimslice_audio_device = {static struct platform_device *trimslice_devices[]__initdata = { &debug_uart, + &tegra_pmu_device, &tegra_sdhci_device1, &tegra_sdhci_device4, &tegra_i2s_device1,Signature · 1 line
1.7.5.2Olof - would you be able to pick this up please? I've not been able to test it, but since the device is already defined I'm assuming the IRQ numbers are correct.
Quoted 3 lines
Cheers,
Will
Hi Will and Olof,
Has this patch been pulled into the git tree? -Will (Cohen)
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 31 lines · William Cohen
Quoted 30 lines · Will Deacon
Quoted 24 lines · William Cohen
The tegra processor has a performance monitoring unit. However, this was not listed on the
board-trimslice.cdevices. This patch adds it to the list of devices and allows one to use hardware performance monitoring events on the trimslice machine.Signed-off-by William Cohen <[email protected]>--- arch/arm/mach-tegra/board-trimslice.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)arch/arm/mach-tegra/board-trimslice.c +1
-0@@ -82,6 +82,7 @@ static struct platform_device trimslice_audio_device = {static struct platform_device *trimslice_devices[]__initdata = { &debug_uart, + &tegra_pmu_device, &tegra_sdhci_device1, &tegra_sdhci_device4, &tegra_i2s_device1,Signature · 1 line
1.7.5.2Olof - would you be able to pick this up please? I've not been able to test it, but since the device is already defined I'm assuming the IRQ numbers are correct.
Quoted 7 lines
Quoted 3 lines
Cheers,
Will
Hi Will and Olof,
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in board-seaboard.c:
http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
-Will
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 9 lines · William Cohen
Quoted 1 line · William Cohen
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in
board-seaboard.c:http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
Right, that sounds good to me. This should go via the tegra/arm-soc tree. For some reason, I can't find the original patch in the list archives so perhaps you could repost it to linux-arm-kernel and CC Olof and Arnd?
Cheers,
Will
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 7 lines · Will Deacon
Quoted 6 lines · William Cohen
Quoted 1 line · William Cohen
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in
board-seaboard.c:
Quoted 7 lines
Quoted 3 lines
http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
Right, that sounds good to me. This should go via the tegra/arm-soc tree. For some reason, I can't find the original patch in the list archives so perhaps you could repost it to linux-arm-kernel and CC Olof and Arnd?
Is there actually any reason to proceed with this patch? When booting Tegra using device tree (i.e. CONFIG_OF rather than the way the phrase is used in the email subject), the ARM PMU is enabled on all boards. So, I'd recommend switching to DT rather than continuing to patch up the board files, which will hopefully be removed in the nearish future.
(BTW, best to cc linux-tegra at vger.kernel.org too)
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 16 lines · Stephen Warren
Quoted 7 lines · Will Deacon
Quoted 6 lines · William Cohen
Quoted 1 line · William Cohen
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in
board-seaboard.c:Quoted 7 lines
Quoted 3 lines
http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
Right, that sounds good to me. This should go via the tegra/arm-soc tree. For some reason, I can't find the original patch in the list archives so perhaps you could repost it to linux-arm-kernel and CC Olof and Arnd?
Quoted 7 lines
Is there actually any reason to proceed with this patch? When booting Tegra using device tree (i.e.
CONFIG_OFrather than the way the phrase is used in the email subject), the ARM PMU is enabled on all boards. So, I'd recommend switching to DT rather than continuing to patch up the board files, which will hopefully be removed in the nearish future.(BTW, best to cc linux-tegra at vger.kernel.org too)
Hi Stephen,
The fedora 17 arm kernels are not yet using the DT. That is the motivations to get this fix into the upstream kernel so that people could use performance monitoring hardware.
Has the pmu support been verified to work on Nvidia Tegra when using the DT? In the past I was not successful in getting the trimslice to boot up using device tree. Are there some clear instructions somewhere on how to do this?
-Will
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 23 lines · William Cohen
Quoted 22 lines · Stephen Warren
Quoted 7 lines · Will Deacon
Quoted 6 lines · William Cohen
Quoted 1 line · William Cohen
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in
board-seaboard.c:Quoted 7 lines
Quoted 3 lines
http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
Right, that sounds good to me. This should go via the tegra/arm-soc tree. For some reason, I can't find the original patch in the list archives so perhaps you could repost it to linux-arm-kernel and CC Olof and Arnd?
Is there actually any reason to proceed with this patch? When booting Tegra using device tree (i.e.
CONFIG_OFrather than the way the phrase is used in the email subject), the ARM PMU is enabled on all boards. So, I'd recommend switching to DT rather than continuing to patch up the board files, which will hopefully be removed in the nearish future.
Quoted 5 lines
Quoted 1 line
(BTW, best to cc linux-tegra at vger.kernel.org too)
Hi Stephen,
The fedora 17 arm kernels are not yet using the DT. That is the motivations to get this fix into the upstream kernel so that people could use performance monitoring hardware.
Are people using the mainline kernel for Fedora on Tegra then?
Quoted 1 line
Has the pmu support been verified to work on Nvidia Tegra when using the DT? In the past I was not successful in getting the trimslice to boot up using device tree. Are there some clear instructions somewhere on how to do this?
I believe I validated the PMU functionality when booting using DT when I created the patch to add it to the device tree files.
Booting with DT is very simple. You can do either:
a) Grab arch/arm/boot/tegra-trimslice.dtb from the kernel build tree, load it into memory from U-Boot just like the kernel and initrd, and pass the address as the third parameter to "bootm". This is the preferred option.
b) Enable CONFIG_ARM_APPENDED_DTB, then concatenate zImage and tegra-trimslice.dtb into a single file, and use that as the kernel image. this is probably marginally easier to get working the first time around, since the only difference is you package a slightly different kernel file onto the boot media.
Either way, I'd recommend passing root=UUID=xxx to the kernel instead of an explicit block device name, since it's possible the naming is different between booting with board files and device tree.
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 24 lines · Stephen Warren
Quoted 23 lines · William Cohen
Quoted 22 lines · Stephen Warren
Quoted 7 lines · Will Deacon
Quoted 6 lines · William Cohen
Quoted 1 line · William Cohen
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in
board-seaboard.c:Quoted 7 lines
Quoted 3 lines
http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
Right, that sounds good to me. This should go via the tegra/arm-soc tree. For some reason, I can't find the original patch in the list archives so perhaps you could repost it to linux-arm-kernel and CC Olof and Arnd?
Is there actually any reason to proceed with this patch? When booting Tegra using device tree (i.e.
CONFIG_OFrather than the way the phrase is used in the email subject), the ARM PMU is enabled on all boards. So, I'd recommend switching to DT rather than continuing to patch up the board files, which will hopefully be removed in the nearish future.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
(BTW, best to cc linux-tegra at vger.kernel.org too)
Hi Stephen,
The fedora 17 arm kernels are not yet using the DT. That is the motivations to get this fix into the upstream kernel so that people could use performance monitoring hardware.
Are people using the mainline kernel for Fedora on Tegra then?
Hi Stephen,
The Fedora 17 Arm kernel is currently based on 3.3.2 with patches. Right now the Fedora arm kernels enable device tree support, but do not use the device trees.
board-trimslice.c is eventually going to be pruned away. However, in the meantime it would be nice if the arm kernel performance monitoring support worked on trimslice regardless whether one was using device trees or not.
In the past I unsuccesfully tried method b below. There may be issues with the particular version of uboot on trimslice, but I am not sure.
-Will
Quoted 21 lines
Quoted 1 line
Has the pmu support been verified to work on Nvidia Tegra when using the DT? In the past I was not successful in getting the trimslice to boot up using device tree. Are there some clear instructions somewhere on how to do this?
I believe I validated the PMU functionality when booting using DT when I created the patch to add it to the device tree files.
Booting with DT is very simple. You can do either:
a) Grab
arch/arm/boot/tegra-trimslice.dtbfrom the kernel build tree, load it into memory from U-Boot just like the kernel and initrd, and pass the address as the third parameter to "bootm". This is the preferred option.b) Enable
CONFIG_ARM_APPENDED_DTB, then concatenate zImage and tegra-trimslice.dtb into a single file, and use that as the kernel image. this is probably marginally easier to get working the first time around, since the only difference is you package a slightly different kernel file onto the boot media.Either way, I'd recommend passing root=UUID=xxx to the kernel instead of an explicit block device name, since it's possible the naming is different between booting with board files and device tree.
PATCH 1/1 Add the Performance Monitoring Unit to the Trimslice device tree
Quoted 33 lines · William Cohen
Quoted 24 lines · Stephen Warren
Quoted 23 lines · William Cohen
Quoted 22 lines · Stephen Warren
Quoted 7 lines · Will Deacon
Quoted 6 lines · William Cohen
Quoted 1 line · William Cohen
Has this patch been pulled into the git tree? -Will (Cohen)
This patch pretty much duplicates what is already done for in
board-seaboard.c:Quoted 7 lines
Quoted 3 lines
http://lxr.linux.no/#linux+v3.3.3/arch/arm/mach-tegra/board-seaboard.c#L147
I have tested the patch out with oprofile, papi, and perf. Things seem to function properly with the patch on a trimslice.
Right, that sounds good to me. This should go via the tegra/arm-soc tree. For some reason, I can't find the original patch in the list archives so perhaps you could repost it to linux-arm-kernel and CC Olof and Arnd?
Is there actually any reason to proceed with this patch? When booting Tegra using device tree (i.e.
CONFIG_OFrather than the way the phrase is used in the email subject), the ARM PMU is enabled on all boards. So, I'd recommend switching to DT rather than continuing to patch up the board files, which will hopefully be removed in the nearish future.Quoted 7 lines
Quoted 5 lines
Quoted 1 line
(BTW, best to cc linux-tegra at vger.kernel.org too)
Hi Stephen,
The fedora 17 arm kernels are not yet using the DT. That is the motivations to get this fix into the upstream kernel so that people could use performance monitoring hardware.
Are people using the mainline kernel for Fedora on Tegra then?
Quoted 7 lines
Hi Stephen,
The Fedora 17 Arm kernel is currently based on 3.3.2 with patches. Right now the Fedora arm kernels enable device tree support, but do not use the device trees.
board-trimslice.cis eventually going to be pruned away. However, in the meantime it would be nice if the arm kernel performance monitoring support worked on trimslice regardless whether one was using device trees or not.In the past I unsuccesfully tried method b below. There may be issues with the particular version of uboot on trimslice, but I am not sure.
FYI, I just did some work on TrimSlice. Method (a) won't work because the U-Boot they ship doesn't have DT support. However, method (b) worked fine, and the U-Boot version shouldn't affect it at all (and I have a very old U-Boot, since I have one of the early developer boards anyway).
Quoted 25 lines
-Will
Quoted 21 lines
Quoted 1 line
Has the pmu support been verified to work on Nvidia Tegra when using the DT? In the past I was not successful in getting the trimslice to boot up using device tree. Are there some clear instructions somewhere on how to do this?
I believe I validated the PMU functionality when booting using DT when I created the patch to add it to the device tree files.
Booting with DT is very simple. You can do either:
a) Grab
arch/arm/boot/tegra-trimslice.dtbfrom the kernel build tree, load it into memory from U-Boot just like the kernel and initrd, and pass the address as the third parameter to "bootm". This is the preferred option.b) Enable
CONFIG_ARM_APPENDED_DTB, then concatenate zImage and tegra-trimslice.dtb into a single file, and use that as the kernel image. this is probably marginally easier to get working the first time around, since the only difference is you package a slightly different kernel file onto the boot media.Either way, I'd recommend passing root=UUID=xxx to the kernel instead of an explicit block device name, since it's possible the naming is different between booting with board files and device tree.