(Resending: forgot to add Russell to To: list; subject change to avoid it getting lost in
code review thread, was Re: [PATCH v4 2/3] [ARM] perfevents: Add support for Scorpion
performance monitors)
Russell,
On 3/16/2011 5:13 AM, Jean Pihet wrote:
> On Tue, Mar 15, 2011 at 4:58 PM, Sheetal Sahasrabudhe
> <[email protected]> wrote:
>> Hi Will/Jean,
>>
>> On Mon, March 14, 2011 6:35 pm, Bryan Huntsman wrote:
>>> On 03/09/2011 09:16 AM, Sheetal Sahasrabudhe wrote:
>>>> This commit adds support for performance monitors provided by
>>>> Qualcomm Scorpion and ScorpionMP processor to perfevents.
>>>>
>>>> Signed-off-by: Sheetal Sahasrabudhe<[email protected]>
>>>> Reviewed-by: Jean Pihet<[email protected]>
>>>> Reviewed-by: Will Deacon<[email protected]>
>>>> ---
>>>> arch/arm/include/asm/perf_event.h | 2 +
>>>> arch/arm/kernel/perf_event.c | 11 +
>>>> arch/arm/kernel/perf_event_msm.c | 679 +++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 692 insertions(+), 0 deletions(-)
>>>> create mode 100644 arch/arm/kernel/perf_event_msm.c
>>>>
>>>
>>> ...
>>>
>>>> diff --git a/arch/arm/kernel/perf_event_msm.c b/arch/arm/kernel/perf_event_msm.c
>>>> new file mode 100644
>>>> index 0000000..4e42f27
>>>> --- /dev/null
>>>> +++ b/arch/arm/kernel/perf_event_msm.c
>> [...]
>>
>>>> +#include<asm/vfp.h>
>>>> +#include<asm/system.h>
>>>> +#include "../vfp/vfpinstr.h"
>>>
>>> Sorry I didn't see this earlier. Is there another way to get the info
>>> you need that wouldn't use a relative include path? If the info from
>>> vfpinstr.h is now needed outside of the vfp directory, can it be moved
>>> to a common header instead? Thanks.
> Good catch! Sorry I did not catch this one while reviewing the code.
>
>>>
>>> - Bryan
>>
>> I see other files under vfp that include this header.
>> So if we were to implement Bryan's suggestion, I think a separate patch that moves the
header and updates all the depdendencies would be more appropriate.
>> Are you okay with the relative include path for vfpinstr.h in this patch for now or
would you want to see an update to move vfpinstr.h to include/asm?.
>
> Adding Russell and Nicolas for the VFP question.
> Only fmrx and fmxr are used from "../vfp/vfpinstr.h". Can those be
> moved to arch/arm/include/asm/vfp.h?
>
> What is the best solution to this?
>
> Regards,
> Jean
>
Any opinions on what would be the best thing to do here? Choices appear to be:
1) allow the relative include path of ../vfp/vfpinstr.h
2) move the definitions of fmrx, fmxr from vfp/vfpinstr.h to include/asm/vfp.h
3) move vfp/vfpinstr.h to include/asm
4) other...?
If it helps, I can create a patch for whichever is considered the preferred solution.
Thanks,
Neil (Standing in temporarily for Sheetal while she is on leave of absence)
>>
>> Thanks,
>> Sheetal
>>
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum
Neil,
On Tue, 2011-03-29 at 22:04 +0100, Neil Leeder wrote:
> Any opinions on what would be the best thing to do here? Choices appear to be:
>
> 1) allow the relative include path of ../vfp/vfpinstr.h
> 2) move the definitions of fmrx, fmxr from vfp/vfpinstr.h to include/asm/vfp.h
> 3) move vfp/vfpinstr.h to include/asm
> 4) other...?
>
> If it helps, I can create a patch for whichever is considered the preferred solution.
>
I personally don't find option (1) that offensive - Bryan seemed to
differ though so perhaps option (2) would keep him happy?
I don't think option (3) is sensible given that the majority of the
header file is private to /vfp.
Will
On 04/01/11 10:27, Will Deacon wrote:
> Neil,
>
> On Tue, 2011-03-29 at 22:04 +0100, Neil Leeder wrote:
>> Any opinions on what would be the best thing to do here? Choices appear to be:
>>
>> 1) allow the relative include path of ../vfp/vfpinstr.h
>> 2) move the definitions of fmrx, fmxr from vfp/vfpinstr.h to include/asm/vfp.h
>> 3) move vfp/vfpinstr.h to include/asm
>> 4) other...?
>>
>> If it helps, I can create a patch for whichever is considered the preferred solution.
>>
>
> I personally don't find option (1) that offensive - Bryan seemed to
> differ though so perhaps option (2) would keep him happy?
>
> I don't think option (3) is sensible given that the majority of the
> header file is private to /vfp.
>
> Will
I raised it as a question. If that's the only sane thing to do here,
then do it. Since no one else seems to have chimed in on (2) or (3),
I'm fine with the patch as-is.
- Bryan
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
Hi Bryan,
On Fri, 2011-04-01 at 22:54 +0100, Bryan Huntsman wrote:
> On 04/01/11 10:27, Will Deacon wrote:
> > Neil,
> >
> > On Tue, 2011-03-29 at 22:04 +0100, Neil Leeder wrote:
> >> Any opinions on what would be the best thing to do here? Choices
> appear to be:
> >>
> >> 1) allow the relative include path of ../vfp/vfpinstr.h
> >> 2) move the definitions of fmrx, fmxr from vfp/vfpinstr.h to
> include/asm/vfp.h
> >> 3) move vfp/vfpinstr.h to include/asm
> >> 4) other...?
> >>
> >> If it helps, I can create a patch for whichever is considered the
> preferred solution.
> >>
> >
> > I personally don't find option (1) that offensive - Bryan seemed to
> > differ though so perhaps option (2) would keep him happy?
> >
> > I don't think option (3) is sensible given that the majority of the
> > header file is private to /vfp.
> >
> > Will
>
> I raised it as a question. If that's the only sane thing to do here,
> then do it. Since no one else seems to have chimed in on (2) or (3),
> I'm fine with the patch as-is.
Ok, great. Let's leave it like it is for the time-being and if other
people start using things from the vfp headers then we should consider
refactoring some of that code (currently I think it's restricted to this
patch series and some files under vfp/).
Cheers,
Will
Will and Bryan,
On 4/3/2011 8:24 AM, Will Deacon wrote:
> Hi Bryan,
>
> On Fri, 2011-04-01 at 22:54 +0100, Bryan Huntsman wrote:
>> On 04/01/11 10:27, Will Deacon wrote:
>>> Neil,
>>>
>>> On Tue, 2011-03-29 at 22:04 +0100, Neil Leeder wrote:
>>>> Any opinions on what would be the best thing to do here? Choices
>> appear to be:
>>>>
>>>> 1) allow the relative include path of ../vfp/vfpinstr.h
>>>> 2) move the definitions of fmrx, fmxr from vfp/vfpinstr.h to
>> include/asm/vfp.h
>>>> 3) move vfp/vfpinstr.h to include/asm
>>>> 4) other...?
>>>>
>>>> If it helps, I can create a patch for whichever is considered the
>> preferred solution.
>>>>
>>>
>>> I personally don't find option (1) that offensive - Bryan seemed to
>>> differ though so perhaps option (2) would keep him happy?
>>>
>>> I don't think option (3) is sensible given that the majority of the
>>> header file is private to /vfp.
>>>
>>> Will
>>
>> I raised it as a question. If that's the only sane thing to do here,
>> then do it. Since no one else seems to have chimed in on (2) or (3),
>> I'm fine with the patch as-is.
>
> Ok, great. Let's leave it like it is for the time-being and if other
> people start using things from the vfp headers then we should consider
> refactoring some of that code (currently I think it's restricted to this
> patch series and some files under vfp/).
Sounds good to me - thank you both for the comments.
Neil
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum