On 05/23/2016 02:22 PM, Neil Leeder wrote:
>
> On 5/23/2016 01:25 PM, Mark Rutland wrote:
>> On Fri, May 20, 2016 at 03:13:07PM -0400, Neil Leeder wrote:
>>> L2 registers are accessed using a select register and data
>>> register pair. To prevent multiple concurrent writes to the
>>> select
On 05/23/2016 02:22 PM, Neil Leeder wrote:
>
> On 5/23/2016 01:25 PM, Mark Rutland wrote:
>> On Fri, May 20, 2016 at 03:13:07PM -0400, Neil Leeder wrote:
>>> L2 registers are accessed using a select register and data
>>> register pair. To prevent multiple concurrent writes to the
>>> select
-type
> d) -type f) >> "$objtree/debian/hdrsrcfiles"
> (cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts
> -type f) >> "$objtree/debian/hdrobjfiles"
Any feedback on this? Michal, do you think this would be appropriate to
include in 4.7?
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
"$objtree/debian/hdrsrcfiles"
> (cd $objtree; find arch/$SRCARCH/include Module.symvers include scripts
> -type f) >> "$objtree/debian/hdrobjfiles"
Any feedback on this? Michal, do you think this would be appropriate to
include in 4.7?
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi Balbir,
On 05/01/2016 09:05 PM, Balbir Singh wrote:
> On 29/04/16 01:18, Christopher Covington wrote:
>> In order to share remap and unmap support for the VDSO with other
>> architectures without duplicating the code, we need a common name and type
>> for the address of
Hi Balbir,
On 05/01/2016 09:05 PM, Balbir Singh wrote:
> On 29/04/16 01:18, Christopher Covington wrote:
>> In order to share remap and unmap support for the VDSO with other
>> architectures without duplicating the code, we need a common name and type
>> for the address of
On 04/29/2016 09:55 AM, Dmitry Safonov wrote:
> On 04/29/2016 04:22 PM, Christopher Covington wrote:
>> On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
>>> Also, at some point, possibly quite soon, x86 will want a way for
>>> user code to ask the kernel to map a specific
On 04/29/2016 09:55 AM, Dmitry Safonov wrote:
> On 04/29/2016 04:22 PM, Christopher Covington wrote:
>> On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
>>> Also, at some point, possibly quite soon, x86 will want a way for
>>> user code to ask the kernel to map a specific
Hi Andy,
On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
> On 04/28/2016 08:18 AM, Christopher Covington wrote:
>> Please take a look at the following prototype of sharing the PowerPC
>> VDSO unmap and remap code with other architectures. I've only hooked
>> up arm64 to begin
Hi Andy,
On 04/28/2016 02:53 PM, Andy Lutomirski wrote:
> On 04/28/2016 08:18 AM, Christopher Covington wrote:
>> Please take a look at the following prototype of sharing the PowerPC
>> VDSO unmap and remap code with other architectures. I've only hooked
>> up arm64 to begin
Qualcomm Technologies QDF2432 SoCs require 32 bit accessors to be used
for the PCI configuration space. Register the appropriate quirk.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
Depends on Tomasz Nowicki's latest series:
[PATCH V6 00/13] Support for generic ACPI bas
Qualcomm Technologies QDF2432 SoCs require 32 bit accessors to be used
for the PCI configuration space. Register the appropriate quirk.
Signed-off-by: Christopher Covington
---
Depends on Tomasz Nowicki's latest series:
[PATCH V6 00/13] Support for generic ACPI based PCI host controller
/criu/attachments/20150318/f02ed9ea/attachment.bin
Thanks,
Christopher Covington
/criu/attachments/20150318/f02ed9ea/attachment.bin
Thanks,
Christopher Covington
ack to using
the generic MM hooks, instead of carrying its own.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/mmu_context.h | 35 +-
include/asm-generic/mm_hooks.h |
ows PowerPC to use mm-arch-hooks.h from include/asm-generic.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
arch/powerpc/include/asm/Kbuild | 1 +
arch/powerpc/include/asm/mm-arch-hooks.h | 28
mm/mremap.c
ack to using
the generic MM hooks, instead of carrying its own.
Signed-off-by: Christopher Covington
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/mmu_context.h | 35 +-
include/asm-generic/mm_hooks.h | 4
3 files changed
ows PowerPC to use mm-arch-hooks.h from include/asm-generic.
Signed-off-by: Christopher Covington
---
arch/powerpc/include/asm/Kbuild | 1 +
arch/powerpc/include/asm/mm-arch-hooks.h | 28
mm/mremap.c | 10 --
3 files chan
location and arm64 has adopted unsigned long for the type of mm->context.vdso,
simply opt-in to VDSO unmap and remap support.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/a
location and arm64 has adopted unsigned long for the type of mm->context.vdso,
simply opt-in to VDSO unmap and remap support.
Signed-off-by: Christopher Covington
---
arch/arm64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 4f43
->context.vdso_base to simply mm->context.vdso.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2 +-
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +-
arch/powerpc/include/asm/mm-arch-hooks.h | 6 +++---
arch/pow
to be
unsigned long, which has the added benefit of dropping a few typecasts.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/vdso.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm
->context.vdso_base to simply mm->context.vdso.
Signed-off-by: Christopher Covington
---
arch/powerpc/include/asm/book3s/32/mmu-hash.h | 2 +-
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +-
arch/powerpc/include/asm/mm-arch-hooks.h | 6 +++---
arch/powerpc/include/asm/mmu
to be
unsigned long, which has the added benefit of dropping a few typecasts.
Signed-off-by: Christopher Covington
---
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/vdso.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include
ang...@redhat.com>
Tested-by: Andre Przywara <andre.przyw...@arm.com>
Acked-by: Andre Przywara <andre.przyw...@arm.com>
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
Changes since v2:
* Updated commit message
* Added Andre's Acked-by and Tested-by.
---
drivers/tty/seri
-by: Andre Przywara
Acked-by: Andre Przywara
Signed-off-by: Christopher Covington
---
Changes since v2:
* Updated commit message
* Added Andre's Acked-by and Tested-by.
---
drivers/tty/serial/amba-pl011.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty
Hi Greg,
On 03/15/2016 06:08 AM, Andre Przywara wrote:
> Hi Christopher,
>
> On 11/03/16 06:35, Christopher Covington wrote:
>> Version 2 of the Server Base System Architecture (SBSAv2) describes the
>> Generic UART registers as 32 bits wide. At least one implementation, fou
Hi Greg,
On 03/15/2016 06:08 AM, Andre Przywara wrote:
> Hi Christopher,
>
> On 11/03/16 06:35, Christopher Covington wrote:
>> Version 2 of the Server Base System Architecture (SBSAv2) describes the
>> Generic UART registers as 32 bits wide. At least one implementation, fou
On 03/13/2016 03:50 PM, Andrew Pinski wrote:
> On many cores, udiv with a large value is slow, expand instead
> the division out to be what GCC would have generated for the
> divide by 1000.
This like checking object code into version control. Why not write in C
and let GCC perform the
On 03/13/2016 03:50 PM, Andrew Pinski wrote:
> On many cores, udiv with a large value is slow, expand instead
> the division out to be what GCC would have generated for the
> divide by 1000.
This like checking object code into version control. Why not write in C
and let GCC perform the
having the
>> interrupt only to fetch the reply descriptor.
>>
>
> Can you go into the detail about which part of the _base_interrupt
> function needs to be executed in ISR context and which part can be
> queued up to worker thread?
>
> I'm not familiar with the hardware o
having the
>> interrupt only to fetch the reply descriptor.
>>
>
> Can you go into the detail about which part of the _base_interrupt
> function needs to be executed in ISR context and which part can be
> queued up to worker thread?
>
> I'm not familiar with the hardware o
On March 11, 2016 10:02:14 PM GMT+07:00, Peter Hurley
<pe...@hurleysoftware.com> wrote:
>Hi Christopher,
>
>On 03/10/2016 10:35 PM, Christopher Covington wrote:
>> Version 2 of the Server Base System Architecture (SBSAv2) describes
>the
>> Generic UART registers
On March 11, 2016 10:02:14 PM GMT+07:00, Peter Hurley
wrote:
>Hi Christopher,
>
>On 03/10/2016 10:35 PM, Christopher Covington wrote:
>> Version 2 of the Server Base System Architecture (SBSAv2) describes
>the
>> Generic UART registers as 32 bits wide. At least on
requires support for both 16 and 32 bit accesses to all
registers (and 8 bit accesses to some but not all). Therefore, for broad
compatibility, simply use 32 bit accessors for the SBSA UART.
Tested-by: Mark Langsdorf <mlang...@redhat.com>
Signed-off-by: Christopher Covington <c...@codea
requires support for both 16 and 32 bit accesses to all
registers (and 8 bit accesses to some but not all). Therefore, for broad
compatibility, simply use 32 bit accessors for the SBSA UART.
Tested-by: Mark Langsdorf
Signed-off-by: Christopher Covington
---
Changes new in v2:
* Fixed from address
From: Christopher Covington <christopher.coving...@linaro.org>
Version 2 of the Server Base System Architecture (SBSA) describes the
Generic UART registers as 32 bits wide. At least one implementation, found
of the Qualcomm Technologies QDF2432, only supports 32 bit accesses. While
From: Christopher Covington
Version 2 of the Server Base System Architecture (SBSA) describes the
Generic UART registers as 32 bits wide. At least one implementation, found
of the Qualcomm Technologies QDF2432, only supports 32 bit accesses. While
other implementations may also support smaller
nyone advise on how to get started with that?
1. http://www.spinics.net/lists/linux-arm-msm/msg18441.html
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
nyone advise on how to get started with that?
1. http://www.spinics.net/lists/linux-arm-msm/msg18441.html
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
> One more thing is:
>>>>>> If you can't switch your driver to use acpi_os_unmap_memory()
>instead of
>>>>> early_acpi_os_unmap_memory(),
>>>>>> then it implies that your driver does have a defect.
>>>>>
>>>>> I sti
t;>>> If you can't switch your driver to use acpi_os_unmap_memory()
>instead of
>>>>> early_acpi_os_unmap_memory(),
>>>>>> then it implies that your driver does have a defect.
>>>>>
>>>>> I still don't understand what defect, sorry.
>>>> [Lv Zheng]
>>>> If you can't ensure this sequence for using the data tables:
>>>> 1. map the table
>>>> 2. parse the table and convert it to OS specific structure
>>>> 3. unmap the table
>>>> It implies there is a bug in the driver or a bug in the ACPI
>subsystem core.
>>>
>>> Exactly.
>>>
>>> The central problem here is the way Aleksey is trying to hookup a
>console.
>>>
>>> What should be happening in this series is:
>>> 1. early map SPCR
>>> 2. parse the SPCR table
>>> 3. call add_preferred_console() to add the SPCR console to the
>console table
>>> 4. unmap SPCR
>>
>> This does not work.
>>
>> SPCR specifies address of the console, but add_preferred_console()
>accepts
>> name of console and its index. There are no general method to
>translate address
>> to name at such an early stage.
>
>
> add_preferred_console(uart, 0, "io,0x3f8,115200");
>
>This will start a console with the 8250 driver. I've already pointed
>this out to you in an earlier review. This is what existing firmware
>already does.
>
>This is also the method you will use to start an earlycon from the
>DBG2 table, by additionally calling setup_earlycon().
Can the device specified in DBG2 be used for both earlycon and KGDB? If it can
only be used for one, let's make sure the choice of earlycon vs KGDB is
intentional rather than accidental.
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Sent from my Snapdragon powered Android device with K-9 Mail. Please excuse my
brevity.
f type struct uart_port to be a console
>and if so calls add_preferred_console().
>
>Use SPCR to tell if SBSA serial driver should use 32-bit access to
>registers.
On QDF2432:
Tested-by: Christopher Covington <c...@codeaurora.org>
--
Qualcomm Innovation Center, Inc.
Qualcomm
to be a console
>and if so calls add_preferred_console().
>
>Use SPCR to tell if SBSA serial driver should use 32-bit access to
>registers.
On QDF2432:
Tested-by: Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linu
Qualcomm Technologies QDF2432 SoCs require 32 bit accessors to be used
for the PCI configuration space. Register the appropriate quirk.
Signed-off-by: Christopher Covington
---
Dependent on Tomasz Nowicki's ACPI support for PCI:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February
Qualcomm Technologies QDF2432 SoCs require 32 bit accessors to be used
for the PCI configuration space. Register the appropriate quirk.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
Dependent on Tomasz Nowicki's ACPI support for PCI:
http://lists.infradead.org/pipermail/lin
support).
> https://github.com/semihalf-nowicki-tomasz/linux.git (gicv3-its-acpi-v3)
>
> Series has been tested on Cavium ThunderX server.
Thanks Tomasz. Looks good on my Qualcomm Technologies QDF2xxx server.
Tested-by: Christopher Covington
--
Qualcomm Innovation Center, Inc.
Qual
support).
> https://github.com/semihalf-nowicki-tomasz/linux.git (gicv3-its-acpi-v3)
>
> Series has been tested on Cavium ThunderX server.
Thanks Tomasz. Looks good on my Qualcomm Technologies QDF2xxx server.
Tested-by: Christopher Covington <c...@codeaurora.org>
--
Qualcomm Innovation
Since Real Time Clock (RTC) configuration options were first enabled in the
arm64 defconfig (commit 2d39ad6 "arm64: defconfig: update defconfig for
3.18"), QEMU's device tree based virt machine has grown to include a PL031
RTC. Update the defconfig accordingly.
Signed-off-by: C
Since Real Time Clock (RTC) configuration options were first enabled in the
arm64 defconfig (commit 2d39ad6 "arm64: defconfig: update defconfig for
3.18"), QEMU's device tree based virt machine has grown to include a PL031
RTC. Update the defconfig accordingly.
Signed-off-by: C
> your platform, period.
Based on your previous comment, I'm guessing you're suggesting using
readl() and writel() here instead of *_relaxed and an explicit wmb().
Again it's not clear to me why swapping the barrier-access ordering and
adding an additional barrier would result in more correct
> your platform, period.
Based on your previous comment, I'm guessing you're suggesting using
readl() and writel() here instead of *_relaxed and an explicit wmb().
Again it's not clear to me why swapping the barrier-access ordering and
adding an additional barrier would result in more correct
nklist.
>
>> - acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
>> + acpi_irq_add_penalty(irq, PIRQ_PENALTY_PCI_USING);
I think Andy was suggesting that you make the change without introducing
the penalty variable.
Christopher Covington
--
Qualcomm
nklist.
>
>> - acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING;
>> + acpi_irq_add_penalty(irq, PIRQ_PENALTY_PCI_USING);
I think Andy was suggesting that you make the change without introducing
the penalty variable.
Christopher Covington
--
Qualcomm
On 12/02/2015 07:19 AM, Will Deacon wrote:
> Hi Christopher,
>
> On Wed, Nov 25, 2015 at 07:49:29AM -0500, Christopher Covington wrote:
>> Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
>> unmap the VDSO. Add support for this to the AArc
On 12/02/2015 07:19 AM, Will Deacon wrote:
> Hi Christopher,
>
> On Wed, Nov 25, 2015 at 07:49:29AM -0500, Christopher Covington wrote:
>> Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
>> unmap the VDSO. Add support for this to the AArc
On 12/01/2015 01:51 PM, Bjorn Helgaas wrote:
> [+cc Taku]
It looks to me like Bjorn intended to add Taku to the distribution list,
but accidentally left him off, so I'm adding him to the To field in this
reply.
Regards,
Christopher Covington
> Hi Sinan,
>
> On Mon, Oct 26, 2015 a
On 12/01/2015 01:51 PM, Bjorn Helgaas wrote:
> [+cc Taku]
It looks to me like Bjorn intended to add Taku to the distribution list,
but accidentally left him off, so I'm adding him to the To field in this
reply.
Regards,
Christopher Covington
> Hi Sinan,
>
> On Mon, Oct 26, 2015 a
Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
unmap the VDSO. Add support for this to the AArch64 kernel by copying in
the PowerPC code with slight modifications.
Signed-off-by: Christopher Covington
---
arch/arm64/include/asm/Kbuild | 1 -
arch/arm64
Some applications such as Checkpoint/Restore In Userspace (CRIU) remap and
unmap the VDSO. Add support for this to the AArch64 kernel by copying in
the PowerPC code with slight modifications.
Signed-off-by: Christopher Covington <c...@codeaurora.org>
---
arch/arm64/include/asm/
ems to use THUMB2_KERNEL
> in practice.
>
> PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
> which leaves the question whether Scorpion or Krait do the same as
> well, or whether they are outliers and need a special configuration.
LPAE is only supported in the
ems to use THUMB2_KERNEL
> in practice.
>
> PJ4-MP is like Cortex-A15/A7/A12/A17 and supports both IDIV and LPAE,
> which leaves the question whether Scorpion or Krait do the same as
> well, or whether they are outliers and need a special configuration.
LPAE is only supported in the
he only paravirt interface supported is pv_time_ops.steal_clock, so no
>>> runtime pvops patching needed.
>>>
>>> This allows us to make use of steal_account_process_tick for stolen
>>> ticks accounting.
>>>
>>> Signed-off-by: Stefano Stabellini
>>> Acked-by:
he only paravirt interface supported is pv_time_ops.steal_clock, so no
>>> runtime pvops patching needed.
>>>
>>> This allows us to make use of steal_account_process_tick for stolen
>>> ticks accounting.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabell.
On 10/27/2015 12:04 PM, Mark Rutland wrote:
> On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
>> On 10/07/2015 07:20 AM, Will Deacon wrote:
>>> Hi again, Drew,
>>>
>>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>>&
On 10/27/2015 12:04 PM, Mark Rutland wrote:
> On Tue, Oct 27, 2015 at 11:46:12AM -0400, Christopher Covington wrote:
>> On 10/07/2015 07:20 AM, Will Deacon wrote:
>>> Hi again, Drew,
>>>
>>> On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote:
>>&
o the code in drivers/perf/. Hopefully these
> will appear on the arm64 for-next/core branch shortly.
Have you considered using OF/ACPI to describe this aspect of the hardware?
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member
o the code in drivers/perf/. Hopefully these
> will appear on the arm64 for-next/core branch shortly.
Have you considered using OF/ACPI to describe this aspect of the hardware?
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member
now points to /mnt/a/foo107
(which is correct).
The inode accessed, however, is the lower layer. The union layer is on
device
25h/37d and the upper layer on 24h/36d.
Signed-off-by: David Howells
Signed-off-by: Al Viro
Thanks,
Christopher Covington
--
Qualcomm Innovat
-by: Al Viro <v...@zeniv.linux.org.uk>
Thanks,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On 08/27/2015 11:12 AM, Mathieu Poirier wrote:
> On 26 August 2015 at 11:57, Christopher Covington wrote:
>> On 07/07/2015 04:41 AM, Chunyan Zhang wrote:
>>> 'ctxid_val' array was used to store the value of ETM context ID comparator
>>> which actually stores the proces
irtio-vsock be interesting for your purposes?
http://events.linuxfoundation.org/sites/events/files/slides/stefanha-kvm-forum-2015.pdf
(Video doesn't seem to be up yet, but should probably be available eventually
at the following link)
https://www.youtube.com/playlist?list=PLW3ep1uCIRfyLNSu708
?
http://events.linuxfoundation.org/sites/events/files/slides/stefanha-kvm-forum-2015.pdf
(Video doesn't seem to be up yet, but should probably be available eventually
at the following link)
https://www.youtube.com/playlist?list=PLW3ep1uCIRfyLNSu708gWG7uvqlolk0ep
Regards,
Christopher Covington
On 08/27/2015 11:12 AM, Mathieu Poirier wrote:
On 26 August 2015 at 11:57, Christopher Covington c...@codeaurora.org wrote:
On 07/07/2015 04:41 AM, Chunyan Zhang wrote:
'ctxid_val' array was used to store the value of ETM context ID comparator
which actually stores the process ID to be traced
]+).*/\1/ /proc/cmdline`
KEY2=`sed -nr s/.*KEY2=([^ ]+).*/\1/ /proc/cmdline`
do_something_with $KEY1 $KEY2
In practice it's just script=hostfile, where hostfile is available to the
guest via a 9P passthrough filesystem mount.
While quite architecture specific, I've also previously used an
"ange
On 07/07/2015 04:41 AM, Chunyan Zhang wrote:
> 'ctxid_val' array was used to store the value of ETM context ID comparator
> which actually stores the process ID to be traced, so using 'ctxid_pid' as
> its name instead make it easier to understand.
Previous discussion with some ARM folks has led
Hi,
Thank you for the feedback.
On 08/26/2015 06:48 AM, Russell King - ARM Linux wrote:
> On Wed, Aug 26, 2015 at 11:39:42AM +0100, Dave Martin wrote:
>> On Mon, Aug 24, 2015 at 09:55:26AM -0400, Christopher Covington wrote:
>>> ARM Linux appears to have never been made
such a tool for AArch64. (On AArch32 upstream QEMU disallows
semihosting from userspace.)
Before I had 9P on all the simulators I regularly ran, I used a semihosting
based angel-load tool.
Regards,
Christopher Covington
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc
On 07/07/2015 04:41 AM, Chunyan Zhang wrote:
'ctxid_val' array was used to store the value of ETM context ID comparator
which actually stores the process ID to be traced, so using 'ctxid_pid' as
its name instead make it easier to understand.
Previous discussion with some ARM folks has led me
Hi,
Thank you for the feedback.
On 08/26/2015 06:48 AM, Russell King - ARM Linux wrote:
On Wed, Aug 26, 2015 at 11:39:42AM +0100, Dave Martin wrote:
On Mon, Aug 24, 2015 at 09:55:26AM -0400, Christopher Covington wrote:
ARM Linux appears to have never been made aware of the ARMv7 security
) mode, so switch to it possible. Failing that,
prefer non-secure supervisor (SVC) mode to secure supervisor mode.
Signed-off-by: Christopher Covington
---
arch/arm/include/asm/sec.h | 27 +++
arch/arm/include/uapi/asm/ptrace.h | 1 +
arch/arm/kernel/Makefile | 1
) mode, so switch to it possible. Failing that,
prefer non-secure supervisor (SVC) mode to secure supervisor mode.
Signed-off-by: Christopher Covington c...@codeaurora.org
---
arch/arm/include/asm/sec.h | 27 +++
arch/arm/include/uapi/asm/ptrace.h | 1 +
arch/arm/kernel/Makefile
Hi Kumar,
On 04/27/2015 05:23 PM, Kumar Gala wrote:
> --- /dev/null
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -0,0 +1,465 @@
> +/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under
Hi Kumar,
On 04/27/2015 05:23 PM, Kumar Gala wrote:
--- /dev/null
+++ b/drivers/firmware/qcom_scm-64.c
@@ -0,0 +1,465 @@
+/* Copyright (c) 2014-2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the
On 04/23/2015 11:16 AM, Mathieu Poirier wrote:
> On 23 April 2015 at 09:08, Christopher Covington wrote:
>> Hi Mathieu,
>>
>> On 04/22/2015 06:40 PM, Mathieu Poirier wrote:
>>> From: Pratik Patel
>>>
>>> Adding sysfs entries to access and configu
On 04/22/2015 06:40 PM, Mathieu Poirier wrote:
> From: Pratik Patel
>
> This driver manages the CoreSight ETMv4 (Embedded Trace Macrocell) IP block
> to support HW assisted tracing on ARMv7 and ARMv8 architectures.
>
> Signed-off-by: Pratik Patel
> Signed-off-by: Kaixu Xia
> Signed-off-by:
Hi Mathieu,
On 04/22/2015 06:40 PM, Mathieu Poirier wrote:
> From: Pratik Patel
>
> Adding sysfs entries to access and configure specifics about the
> context ID comparator functions.
>
> Signed-off-by: Pratik Patel
> Signed-off-by: Mathieu Poirier
> ---
>
On 04/22/2015 06:40 PM, Mathieu Poirier wrote:
From: Pratik Patel prat...@codeaurora.org
This driver manages the CoreSight ETMv4 (Embedded Trace Macrocell) IP block
to support HW assisted tracing on ARMv7 and ARMv8 architectures.
Signed-off-by: Pratik Patel prat...@codeaurora.org
Hi Mathieu,
On 04/22/2015 06:40 PM, Mathieu Poirier wrote:
From: Pratik Patel prat...@codeaurora.org
Adding sysfs entries to access and configure specifics about the
context ID comparator functions.
Signed-off-by: Pratik Patel prat...@codeaurora.org
Signed-off-by: Mathieu Poirier
On 04/23/2015 11:16 AM, Mathieu Poirier wrote:
On 23 April 2015 at 09:08, Christopher Covington c...@codeaurora.org wrote:
Hi Mathieu,
On 04/22/2015 06:40 PM, Mathieu Poirier wrote:
From: Pratik Patel prat...@codeaurora.org
Adding sysfs entries to access and configure specifics about
Hi,
On 03/11/2015 08:47 AM, Arnd Bergmann wrote:
> On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
>> So after recompiling all of the distribution with newer binutils we now
>> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
>>
>> Unfortunately however, the 32bit
Hi,
On 03/11/2015 08:47 AM, Arnd Bergmann wrote:
On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
So after recompiling all of the distribution with newer binutils we now
have an openSUSE Factory tree that has 64k aligned 32bit binaries.
Unfortunately however, the 32bit glibc has a
On 03/05/2015 09:28 PM, Rob Clark wrote:
> On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson wrote:
>> On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala wrote:
>>>
>>> On Mar 5, 2015, at 1:42 PM, Kevin Hilman wrote:
>>>
Kumar Gala writes:
> The top level qcom,msm-id and qcom,board-id are
On 03/05/2015 09:28 PM, Rob Clark wrote:
On Thu, Mar 5, 2015 at 8:59 PM, Olof Johansson o...@lixom.net wrote:
On Thu, Mar 5, 2015 at 12:23 PM, Kumar Gala ga...@codeaurora.org wrote:
On Mar 5, 2015, at 1:42 PM, Kevin Hilman khil...@kernel.org wrote:
Kumar Gala ga...@codeaurora.org writes:
On 12/05/2014 06:05 AM, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 10:39:40AM +, Arnd Bergmann wrote:
>> On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
>>> On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf wrote:
On 04.12.14 22:15, Olof Johansson wrote:
> On Thu, Dec
On 12/05/2014 06:05 AM, Catalin Marinas wrote:
On Fri, Dec 05, 2014 at 10:39:40AM +, Arnd Bergmann wrote:
On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf ag...@suse.de wrote:
On 04.12.14 22:15, Olof Johansson wrote:
On Thu, Dec 4,
Hi,
Please consider adding subsystem specific mailing list(s) in the MAINTAINERS
file for the performance events and tracing subsystems. I am interested in
following (and contributing to when the opportunity arises) the development of
these subsystems; filtering and archiving the whole of LKML in
Hi,
Commit c6e5e9fbc3ea1c1a5648a3498d085fc3978df2d4 breaks the following make
invocation (-j, -C, O=, LDFLAGS=, and build directory prefix stripped to
simplify report):
make ARCH=x86_64 CROSS_COMPILE= EXTRA_CFLAGS=
config/Makefile:128: The path 'python-config' is not executable.
Hi,
Commit c6e5e9fbc3ea1c1a5648a3498d085fc3978df2d4 breaks the following make
invocation (-j, -C, O=, LDFLAGS=, and build directory prefix stripped to
simplify report):
make ARCH=x86_64 CROSS_COMPILE= EXTRA_CFLAGS=
config/Makefile:128: The path 'python-config' is not executable.
Hi,
Please consider adding subsystem specific mailing list(s) in the MAINTAINERS
file for the performance events and tracing subsystems. I am interested in
following (and contributing to when the opportunity arises) the development of
these subsystems; filtering and archiving the whole of LKML in
201 - 300 of 560 matches
Mail list logo
