Re: [BUGFIX PATCH V2 0/3] kprobes/arm: Improve kprobes implementation on arm

On Sat, 2017-02-18 at 06:43 +0900, Masami Hiramatsu wrote: > On Fri, 17 Feb 2017 11:01:10 + > "Jon Medhurst (Tixy)" <t...@linaro.org> wrote: [...] > > Meantime > > I'll investigate the kprobes test failures I see (which actually looks > > like cache/TLB

Re: [BUGFIX PATCH V2 0/3] kprobes/arm: Improve kprobes implementation on arm

On Sat, 2017-02-18 at 06:43 +0900, Masami Hiramatsu wrote: > On Fri, 17 Feb 2017 11:01:10 + > "Jon Medhurst (Tixy)" wrote: [...] > > Meantime > > I'll investigate the kprobes test failures I see (which actually looks > > like cache/TLB issues and not test

Re: [BUGFIX PATCH V2 0/3] kprobes/arm: Improve kprobes implementation on arm

On Wed, 2017-02-15 at 09:27 +0900, Masami Hiramatsu wrote: > Hi, > > Here is the 2nd version of the patches which improve kprobe > on arm implementation (a kind of bugfix). Version 1 is here; > > https://lkml.org/lkml/2017/2/13/538 > > In this version I didn't update the code, just update the >

Re: [BUGFIX PATCH V2 0/3] kprobes/arm: Improve kprobes implementation on arm

On Wed, 2017-02-15 at 09:27 +0900, Masami Hiramatsu wrote: > Hi, > > Here is the 2nd version of the patches which improve kprobe > on arm implementation (a kind of bugfix). Version 1 is here; > > https://lkml.org/lkml/2017/2/13/538 > > In this version I didn't update the code, just update the >

Re: [BUGFIX PATCH 3/3] kprobes/arm: Fix the return address of multiple kretprobes

On Wed, 2017-02-15 at 01:01 +0900, Masami Hiramatsu wrote: > On Tue, 14 Feb 2017 13:47:07 + > "Jon Medhurst (Tixy)" <t...@linaro.org> wrote: > > > On Tue, 2017-02-14 at 10:32 +, Jon Medhurst (Tixy) wrote: > > > On Tue, 2017-02-14 at 00:05 +0900, Mas

Re: [BUGFIX PATCH 3/3] kprobes/arm: Fix the return address of multiple kretprobes

On Wed, 2017-02-15 at 01:01 +0900, Masami Hiramatsu wrote: > On Tue, 14 Feb 2017 13:47:07 + > "Jon Medhurst (Tixy)" wrote: > > > On Tue, 2017-02-14 at 10:32 +, Jon Medhurst (Tixy) wrote: > > > On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote:

Re: [BUGFIX PATCH 3/3] kprobes/arm: Fix the return address of multiple kretprobes

On Tue, 2017-02-14 at 10:32 +, Jon Medhurst (Tixy) wrote: > On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote: > > This is arm port of commit 737480a0d525 ("kprobes/x86: > > Fix the return address of multiple kretprobes"). > > > > Fix the return

Re: [BUGFIX PATCH 3/3] kprobes/arm: Fix the return address of multiple kretprobes

On Tue, 2017-02-14 at 10:32 +, Jon Medhurst (Tixy) wrote: > On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote: > > This is arm port of commit 737480a0d525 ("kprobes/x86: > > Fix the return address of multiple kretprobes"). > > > > Fix the return

Re: [BUGFIX PATCH 3/3] kprobes/arm: Fix the return address of multiple kretprobes

On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote: > This is arm port of commit 737480a0d525 ("kprobes/x86: > Fix the return address of multiple kretprobes"). > > Fix the return address of subsequent kretprobes when multiple > kretprobes are set on the same function. > > For example: >

Re: [BUGFIX PATCH 3/3] kprobes/arm: Fix the return address of multiple kretprobes

On Tue, 2017-02-14 at 00:05 +0900, Masami Hiramatsu wrote: > This is arm port of commit 737480a0d525 ("kprobes/x86: > Fix the return address of multiple kretprobes"). > > Fix the return address of subsequent kretprobes when multiple > kretprobes are set on the same function. > > For example: >

Re: [BUGFIX PATCH 1/3] kprobes/arm: Allow to handle reentered kprobe on single-stepping

On Tue, 2017-02-14 at 00:03 +0900, Masami Hiramatsu wrote: > This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to > handle reentered kprobe on single-stepping") > > Since the FIQ handlers can interrupt in the single stepping > (or preparing the single stepping, do_debug etc.), we

Re: [BUGFIX PATCH 1/3] kprobes/arm: Allow to handle reentered kprobe on single-stepping

On Tue, 2017-02-14 at 00:03 +0900, Masami Hiramatsu wrote: > This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to > handle reentered kprobe on single-stepping") > > Since the FIQ handlers can interrupt in the single stepping > (or preparing the single stepping, do_debug etc.), we

Re: [BUGFIX PATCH 2/3] kprobes/arm: Skip single-stepping in recursing path if possible

On Tue, 2017-02-14 at 00:04 +0900, Masami Hiramatsu wrote: > Kprobes/arm skips single-stepping (moreover handling the event) > if the conditional instruction must not be executed. This > also apply the rule when we hit the recursing kprobe, so > that kprobe does not count nmissed up in that case.

Re: [BUGFIX PATCH 2/3] kprobes/arm: Skip single-stepping in recursing path if possible

On Tue, 2017-02-14 at 00:04 +0900, Masami Hiramatsu wrote: > Kprobes/arm skips single-stepping (moreover handling the event) > if the conditional instruction must not be executed. This > also apply the rule when we hit the recursing kprobe, so > that kprobe does not count nmissed up in that case.

[PATCH v2] ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>

If a DAI specifies "#sound-dai-cells = <0>" in device-tree then hdmi_of_xlate_dai_name() will be called with zero args, which it isn't implemented to cope with. The resulting use of an uninitialised variable for the id will usually result in an error like: asoc-simple-card sound: parse error

[PATCH v2] ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>

If a DAI specifies "#sound-dai-cells = <0>" in device-tree then hdmi_of_xlate_dai_name() will be called with zero args, which it isn't implemented to cope with. The resulting use of an uninitialised variable for the id will usually result in an error like: asoc-simple-card sound: parse error

[PATCH] ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>

If a DAI specifies "#sound-dai-cells = <0>" in device-tree then hdmi_of_xlate_dai_name() will be called with zero args, which it isn't implemented to cope with. The resulting use of an uninitialised variable for the id will usually result in an error like: asoc-simple-card sound: parse error

[PATCH] ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>

If a DAI specifies "#sound-dai-cells = <0>" in device-tree then hdmi_of_xlate_dai_name() will be called with zero args, which it isn't implemented to cope with. The resulting use of an uninitialised variable for the id will usually result in an error like: asoc-simple-card sound: parse error

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote: > > On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: > > On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: > > [...] > >> +enum scpi_power_domain_state { > >> + SCPI_PD_STATE_ON = 0, > >> + SCP

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On Thu, 2016-06-16 at 18:59 +0100, Sudeep Holla wrote: > > On 16/06/16 18:47, Jon Medhurst (Tixy) wrote: > > On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: > > [...] > >> +enum scpi_power_domain_state { > >> + SCPI_PD_STATE_ON = 0, > >> + SCP

Re: [PATCH v2 1/3] firmware: arm_scpi: add support for device power state management

On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote: > SCPI protocol supports device power state management. This deals with > power states of various peripheral devices in the system other than the > core compute subsystem. > > This patch adds support for the power state management of those >

Re: [PATCH v2 1/3] firmware: arm_scpi: add support for device power state management

On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote: > SCPI protocol supports device power state management. This deals with > power states of various peripheral devices in the system other than the > core compute subsystem. > > This patch adds support for the power state management of those >

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] > +enum scpi_power_domain_state { > + SCPI_PD_STATE_ON = 0, > + SCPI_PD_STATE_OFF = 3, > +}; The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno specifics' chapter. So does these values need to come from

Re: [PATCH v2 3/3] firmware: scpi: add device power domain support using genpd

On Thu, 2016-06-16 at 11:38 +0100, Sudeep Holla wrote: [...] > +enum scpi_power_domain_state { > + SCPI_PD_STATE_ON = 0, > + SCPI_PD_STATE_OFF = 3, > +}; The SCPI doc defines the meaning of these numbers (0 and 3) in the 'Juno specifics' chapter. So does these values need to come from

Re: [PATCH v2 0/3] firmware: scpi: add device power domain support

On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote: > This series add support for SCPI based device device power state > management using genpd. > > Regards, > Sudeep > > v1[1]->v2: > - Fixed the endianness handling in scpi_device_get_power_state > as spotted by Tixy > -

Re: [PATCH v2 0/3] firmware: scpi: add device power domain support

On Thu, 2016-06-16 at 11:37 +0100, Sudeep Holla wrote: > This series add support for SCPI based device device power state > management using genpd. > > Regards, > Sudeep > > v1[1]->v2: > - Fixed the endianness handling in scpi_device_get_power_state > as spotted by Tixy > -

Re: [PATCH 3/3] firmware: scpi: add device power domain support using genpd

On Mon, 2016-06-06 at 16:53 +0100, Sudeep Holla wrote: > This patch hooks up the support for device power domain provided by > SCPI using the Linux generic power domain infrastructure. > > Cc: "Rafael J. Wysocki" > Cc: Kevin Hilman > Cc: Ulf Hansson

Re: [PATCH 3/3] firmware: scpi: add device power domain support using genpd

On Mon, 2016-06-06 at 16:53 +0100, Sudeep Holla wrote: > This patch hooks up the support for device power domain provided by > SCPI using the Linux generic power domain infrastructure. > > Cc: "Rafael J. Wysocki" > Cc: Kevin Hilman > Cc: Ulf Hansson > Cc: linux...@vger.kernel.org >

Re: [PATCH 1/3] firmware: arm_scpi: add support for device power state management

On Mon, 2016-06-06 at 16:53 +0100, Sudeep Holla wrote: > SCPI protocol supports device power state management. This deals with > power states of various peripheral devices in the system other than the > core compute subsystem. > > This patch adds support for the power state management of those >

Re: [PATCH 1/3] firmware: arm_scpi: add support for device power state management

On Mon, 2016-06-06 at 16:53 +0100, Sudeep Holla wrote: > SCPI protocol supports device power state management. This deals with > power states of various peripheral devices in the system other than the > core compute subsystem. > > This patch adds support for the power state management of those >

Re: [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

On Mon, 2016-05-16 at 18:14 -0700, Greg Kroah-Hartman wrote: > 3.14-stable review patch. If anyone has any objections, please let me know. As reported by Guenter Roeck, this patch doesn't compile on 3.14 because it deleted randomize_base which is still used by the macro ELF_ET_DYN_BASE. That use

Re: [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

On Mon, 2016-05-16 at 18:14 -0700, Greg Kroah-Hartman wrote: > 3.14-stable review patch. If anyone has any objections, please let me know. As reported by Guenter Roeck, this patch doesn't compile on 3.14 because it deleted randomize_base which is still used by the macro ELF_ET_DYN_BASE. That use

Re: [PATCH] arm64: kernel: Fix incorrect brk randomization

On Tue, 2016-05-10 at 10:55 -0700, Kees Cook wrote: > This fixes two issues with the arm64 brk randomziation. First, the > STACK_RND_MASK was being used incorrectly. The original code was: > > unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1; > > STACK_RND_MASK is 0x7ff

Re: [PATCH] arm64: kernel: Fix incorrect brk randomization

On Tue, 2016-05-10 at 10:55 -0700, Kees Cook wrote: > This fixes two issues with the arm64 brk randomziation. First, the > STACK_RND_MASK was being used incorrectly. The original code was: > > unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1; > > STACK_RND_MASK is 0x7ff

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

On Fri, 2016-03-11 at 13:13 +0530, Vinod Koul wrote: > On Tue, Mar 08, 2016 at 03:50:41PM +0000, Jon Medhurst (Tixy) wrote: > > > > The reside is requested for "a descriptor". For example if you have > > > prepared > > > two descriptors A and B and

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

On Fri, 2016-03-11 at 13:13 +0530, Vinod Koul wrote: > On Tue, Mar 08, 2016 at 03:50:41PM +0000, Jon Medhurst (Tixy) wrote: > > > > The reside is requested for "a descriptor". For example if you have > > > prepared > > > two descriptors A and B and

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

On Tue, 2016-03-08 at 19:45 +0530, Vinod Koul wrote: > On Tue, Mar 08, 2016 at 10:40:11AM +0000, Jon Medhurst (Tixy) wrote: > > On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote: > > > On Wed, Feb 24, 2016 at 01:14:34PM +0000, Jon Medhurst (Tixy) wrote: > > >

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

On Tue, 2016-03-08 at 19:45 +0530, Vinod Koul wrote: > On Tue, Mar 08, 2016 at 10:40:11AM +0000, Jon Medhurst (Tixy) wrote: > > On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote: > > > On Wed, Feb 24, 2016 at 01:14:34PM +0000, Jon Medhurst (Tixy) wrote: > > >

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote: > On Wed, Feb 24, 2016 at 01:14:34PM +0000, Jon Medhurst (Tixy) wrote: > > The residue calculation in pl330_tx_status doesn't handle transitional > > states that occur at the time one descriptor (A) is completed and the > >

Re: [PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

On Tue, 2016-03-08 at 09:42 +0530, Vinod Koul wrote: > On Wed, Feb 24, 2016 at 01:14:34PM +0000, Jon Medhurst (Tixy) wrote: > > The residue calculation in pl330_tx_status doesn't handle transitional > > states that occur at the time one descriptor (A) is completed and the > >

Re: [PATCH] ARM: dts: add "simple-bus" to "arm, amba-bus" compatible nodes

On Thu, 2016-03-03 at 12:07 +0900, Masahiro Yamada wrote: [...] > This patch is derived from Rob Herring' comment > "BTW, we should also kill off "amba-bus" which is an ambiguous term" > in the following thread: > http://lkml.iu.edu/hypermail/linux/kernel/1601.0/01822.html > > > So, the plan

Re: [PATCH] ARM: dts: add "simple-bus" to "arm, amba-bus" compatible nodes

On Thu, 2016-03-03 at 12:07 +0900, Masahiro Yamada wrote: [...] > This patch is derived from Rob Herring' comment > "BTW, we should also kill off "amba-bus" which is an ambiguous term" > in the following thread: > http://lkml.iu.edu/hypermail/linux/kernel/1601.0/01822.html > > > So, the plan

[PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

The residue calculation in pl330_tx_status doesn't handle transitional states that occur at the time one descriptor (A) is completed and the next (B) is started. Specifically, both A and B can simultaneously be in the BUSY state and at this time the thread's 'req_running' may (or may not) be -1.

[PATCH] dmaengine: pl330: Fix some race conditions in residue calculation

The residue calculation in pl330_tx_status doesn't handle transitional states that occur at the time one descriptor (A) is completed and the next (B) is started. Specifically, both A and B can simultaneously be in the BUSY state and at this time the thread's 'req_running' may (or may not) be -1.

Re: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline assembly offsets

On Thu, 2016-02-18 at 18:59 +, Robin Murphy wrote: > On 18/02/16 18:12, Jon Medhurst (Tixy) wrote: > > On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote: > >> build-testing with clang showed that the "J" constraint does not take > >> positive argument

Re: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline assembly offsets

On Thu, 2016-02-18 at 18:59 +, Robin Murphy wrote: > On 18/02/16 18:12, Jon Medhurst (Tixy) wrote: > > On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote: > >> build-testing with clang showed that the "J" constraint does not take > >> positive argument

Re: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline assembly offsets

On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote: > build-testing with clang showed that the "J" constraint does not take > positive arguments on clang when building in for Thumb-2: > > core.c:540:3: error: invalid operand for inline asm constraint 'J' > > This has been reported as llvm

Re: [PATCH 3/3] [RESEND] ARM: kprobes: use "I" constraint for inline assembly offsets

On Thu, 2016-02-18 at 18:05 +0100, Arnd Bergmann wrote: > build-testing with clang showed that the "J" constraint does not take > positive arguments on clang when building in for Thumb-2: > > core.c:540:3: error: invalid operand for inline asm constraint 'J' > > This has been reported as llvm

Re: [PATCH 9/9] ARM: fix kprobe test with CONFIG_CPU_32v3

On Thu, 2016-02-18 at 15:02 +0100, Arnd Bergmann wrote: > ARMv3 did not have 16-bit load/store or 32-bit multiply instructions, > so building the kprobe test code fails with lots of warnings about > these: > > /tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode > `umull

Re: [PATCH 9/9] ARM: fix kprobe test with CONFIG_CPU_32v3

On Thu, 2016-02-18 at 15:02 +0100, Arnd Bergmann wrote: > ARMv3 did not have 16-bit load/store or 32-bit multiply instructions, > so building the kprobe test code fails with lots of warnings about > these: > > /tmp/ccI4SKHx.s:19585: Error: selected processor does not support ARM mode > `umull

Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails

On Thu, 2016-02-11 at 15:05 +0530, Archit Taneja wrote: > component_master_add_with_match can fail if the master's bind op doesn't > go through successfully. In such a scenario, all the components in the > master's match array have their 'master' pointer set to the given master. > These pointers

Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails

On Thu, 2016-02-11 at 15:05 +0530, Archit Taneja wrote: > component_master_add_with_match can fail if the master's bind op doesn't > go through successfully. In such a scenario, all the components in the > master's match array have their 'master' pointer set to the given master. > These pointers

[PATCH] ASoC: dwc: Ensure i2s_reg_comp{1,2} is always initialised

In the case that the driver is configured from device-tree i2s_reg_comp1 and i2s_reg_comp2 aren't initialised, breaking the driver. Fix this by unconditionally setting these values before checking for quirks. Fixes: a242cac1d3aa ("ASoC: dwc: add quirk to override COMP_PARAM_1 register")

[PATCH] ASoC: dwc: Ensure i2s_reg_comp{1,2} is always initialised

In the case that the driver is configured from device-tree i2s_reg_comp1 and i2s_reg_comp2 aren't initialised, breaking the driver. Fix this by unconditionally setting these values before checking for quirks. Fixes: a242cac1d3aa ("ASoC: dwc: add quirk to override COMP_PARAM_1 register")

Re: [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer

On Thu, 2016-01-21 at 16:58 -0800, Laura Abbott wrote: > On 01/21/2016 12:19 PM, Jon Medhurst (Tixy) wrote: [...] > > If sg_dma_len() is correct or acceptable then it seems to me that the > > ION code should set that length. Especially as the comment in the code > > impli

Re: [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer

On Thu, 2016-01-21 at 16:58 -0800, Laura Abbott wrote: > On 01/21/2016 12:19 PM, Jon Medhurst (Tixy) wrote: [...] > > If sg_dma_len() is correct or acceptable then it seems to me that the > > ION code should set that length. Especially as the comment in the code > > impli

Re: [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer

On Thu, 2016-01-21 at 09:39 -0800, Laura Abbott wrote: > On 01/21/2016 03:57 AM, Jon Medhurst (Tixy) wrote: > > From: Liviu Dudau > > > > ion_buffer_create() will allocate a buffer and then create a DMA > > mapping for it, but it forgot to set the length of the page

Problem with commit 924eb47512 ("ASoC: dwc: fix dma stop transferring issue")

Hi In trying to work out why audio stopped working on ARM's Juno board I bisected the problem to $subject commit and reverting this fixed things. The symptoms of broken audio was that alsa-utils' speaker-test produced very short duration 'churps' rather than the voice sample naming each speaker

[PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer

From: Liviu Dudau ion_buffer_create() will allocate a buffer and then create a DMA mapping for it, but it forgot to set the length of the page entries. Signed-off-by: Liviu Dudau Signed-off-by: Jon Medhurst --- drivers/staging/android/ion/ion.c | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer

From: Liviu Dudau ion_buffer_create() will allocate a buffer and then create a DMA mapping for it, but it forgot to set the length of the page entries. Signed-off-by: Liviu Dudau Signed-off-by: Jon Medhurst ---

Problem with commit 924eb47512 ("ASoC: dwc: fix dma stop transferring issue")

Hi In trying to work out why audio stopped working on ARM's Juno board I bisected the problem to $subject commit and reverting this fixed things. The symptoms of broken audio was that alsa-utils' speaker-test produced very short duration 'churps' rather than the voice sample naming each speaker

Re: [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer

On Thu, 2016-01-21 at 09:39 -0800, Laura Abbott wrote: > On 01/21/2016 03:57 AM, Jon Medhurst (Tixy) wrote: > > From: Liviu Dudau <liviu.du...@arm.com> > > > > ion_buffer_create() will allocate a buffer and then create a DMA > > mapping for it, but it forgot to s

Re: [PATCH] iommu/arm-smmu: add a shortcut when the @dev_node is NULL

On Wed, 2016-01-20 at 14:46 +, Robin Murphy wrote: > > Of course, the 0.004014s maybe not accurate enough, it is just an > > approximate number. > > A mean and standard deviation of at least, say, 5 runs each with and > without the patch would be considerably more meaningful (even if > still

Re: [PATCH] iommu/arm-smmu: add a shortcut when the @dev_node is NULL

On Wed, 2016-01-20 at 14:46 +, Robin Murphy wrote: > > Of course, the 0.004014s maybe not accurate enough, it is just an > > approximate number. > > A mean and standard deviation of at least, say, 5 runs each with and > without the patch would be considerably more meaningful (even if > still

Re: [RFC] kprobe'ing conditionally executed instructions

On Fri, 2015-12-11 at 10:34 +, Russell King - ARM Linux wrote: > On Fri, Dec 11, 2015 at 10:27:13AM +0000, Jon Medhurst (Tixy) wrote: > > On Fri, 2015-12-11 at 00:05 -0500, David Long wrote: > > > There is a moderate amount of code already in kprobes on ARM and the > &g

Re: [RFC] kprobe'ing conditionally executed instructions

On Fri, 2015-12-11 at 00:05 -0500, David Long wrote: > There is a moderate amount of code already in kprobes on ARM and the > current ARMv8 patch to deal with conditional execution of instructions. > One aspect of how this is handled is that instructions that fail their > predicate and are not

Re: [RFC] kprobe'ing conditionally executed instructions

On Fri, 2015-12-11 at 10:34 +, Russell King - ARM Linux wrote: > On Fri, Dec 11, 2015 at 10:27:13AM +0000, Jon Medhurst (Tixy) wrote: > > On Fri, 2015-12-11 at 00:05 -0500, David Long wrote: > > > There is a moderate amount of code already in kprobes on ARM and the > &g

Re: [RFC] kprobe'ing conditionally executed instructions

On Fri, 2015-12-11 at 00:05 -0500, David Long wrote: > There is a moderate amount of code already in kprobes on ARM and the > current ARMv8 patch to deal with conditional execution of instructions. > One aspect of how this is handled is that instructions that fail their > predicate and are not

Re: [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units

On Wed, 2015-12-02 at 22:19 +0100, Ben Gamari wrote: > The frequency units are very confusing in this area as OPPs use Hz > whereas cpufreq uses kHz. Be explicit about this in variable naming. > > Cc: Javier Martinez Canillas > Signed-off-by: Ben Gamari > --- > drivers/cpufreq/arm_big_little.c

Re: [PATCH 11/12] cpufreq: arm-big-little: clarify frequency units

On Wed, 2015-12-02 at 22:19 +0100, Ben Gamari wrote: > The frequency units are very confusing in this area as OPPs use Hz > whereas cpufreq uses kHz. Be explicit about this in variable naming. > > Cc: Javier Martinez Canillas > Signed-off-by: Ben Gamari

Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo

On Wed, 2015-11-25 at 13:09 -0500, Nicolas Pitre wrote: > But CPU MHz, when available, has the merit of not being open to > interpretation. Current MHz, maximum MHz or 'turbo' MHz? ;-) -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo

On Wed, 2015-11-25 at 13:09 -0500, Nicolas Pitre wrote: > But CPU MHz, when available, has the merit of not being open to > interpretation. Current MHz, maximum MHz or 'turbo' MHz? ;-) -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote: > > This is on-chip RAM or nornal system RAM? We already have bindings > for > > both. > > Juno has a set of TLX (ThinLinks) connectors on the board where an > FPGA can be attached. On r1 > the code running on FPGA can even participate as an

Re: [PATCH v2 1/4] drm: arm: Add DT bindings documentation for HDLCD driver.

On Thu, 2015-11-12 at 10:42 +, Liviu Dudau wrote: > > This is on-chip RAM or nornal system RAM? We already have bindings > for > > both. > > Juno has a set of TLX (ThinLinks) connectors on the board where an > FPGA can be attached. On r1 > the code running on FPGA can even participate as an

Re: [PATCH v2] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Wed, 2015-10-21 at 15:27 +0530, Viresh Kumar wrote: > On 21-10-15, 10:55, Jon Medhurst (Tixy) wrote: > > The check for correct frequency being set in bL_cpufreq_set_rate is > > broken when the big.LITTLE switcher is active, for two reasons. > > > > 1. The 'new_rate

Re: [PATCH v2] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Wed, 2015-10-21 at 15:27 +0530, Viresh Kumar wrote: > On 21-10-15, 10:55, Jon Medhurst (Tixy) wrote: > > The check for correct frequency being set in bL_cpufreq_set_rate is > > broken when the big.LITTLE switcher is active, for two reasons. > > > > 1. The 'new_rate

[PATCH v2] cpufreq: arm_big_little: fix frequency check when bL switcher is active

The check for correct frequency being set in bL_cpufreq_set_rate is broken when the big.LITTLE switcher is active, for two reasons. 1. The 'new_rate' variable gets overwritten before the test by the code calculating the frequency of the old cluster. 2. The frequency returned by

[PATCH v2] cpufreq: arm_big_little: fix frequency check when bL switcher is active

The check for correct frequency being set in bL_cpufreq_set_rate is broken when the big.LITTLE switcher is active, for two reasons. 1. The 'new_rate' variable gets overwritten before the test by the code calculating the frequency of the old cluster. 2. The frequency returned by

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote: > > On 14/10/15 08:12, Jon Medhurst (Tixy) wrote: > > On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote: > >> > >> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote: > > [...] > >>> But then

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote: > > On 14/10/15 08:12, Jon Medhurst (Tixy) wrote: > > On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote: > >> > >> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote: > > [...] > >>> But then

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote: > > On 13/10/15 08:19, Jon Medhurst (Tixy) wrote: [...] > > But then we wouldn't get the WARN_ON and pr_err triggered when we detect > > the clock rate isn't set, which surely is half the reason for the check >

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote: > > On 13/10/15 08:19, Jon Medhurst (Tixy) wrote: [...] > > But then we wouldn't get the WARN_ON and pr_err triggered when we detect > > the clock rate isn't set, which surely is half the reason for the check >

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote: > > On 08/10/15 10:23, Jon Medhurst (Tixy) wrote: > [...] > > > diff --git a/drivers/cpufreq/arm_big_little.c > > b/drivers/cpufreq/arm_big_little.c > > index f1e42f8..59115a4 100644 > > --- a/driver

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote: > > On 08/10/15 10:23, Jon Medhurst (Tixy) wrote: > [...] > > > diff --git a/drivers/cpufreq/arm_big_little.c > > b/drivers/cpufreq/arm_big_little.c > > index f1e42f8..59115a4 100644 > > --- a/driver

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote: > On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote: > > On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote: [...] > > > @@ -140,9 +140,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 > >

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote: [...] > And why not fix it properly by doing this: > > diff --git a/drivers/cpufreq/arm_big_little.c > b/drivers/cpufreq/arm_big_little.c > index f1e42f8ce0fc..5b36657a76d6 100644 > --- a/drivers/cpufreq/arm_big_little.c > +++

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote: [...] > And why not fix it properly by doing this: > > diff --git a/drivers/cpufreq/arm_big_little.c > b/drivers/cpufreq/arm_big_little.c > index f1e42f8ce0fc..5b36657a76d6 100644 > --- a/drivers/cpufreq/arm_big_little.c > +++

Re: [PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

On Thu, 2015-10-08 at 16:54 +0530, Viresh Kumar wrote: > On 08-10-15, 10:23, Jon Medhurst (Tixy) wrote: > > On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote: [...] > > > @@ -140,9 +140,11 @@ bL_cpufreq_set_rate(u32 cpu, u32 old_cluster, u32 > >

[PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

The check for correct frequency being set in bL_cpufreq_set_rate is broken when the big.LITTLE switcher is active, for two reasons. 1. The 'new_rate' variable gets overwritten before the test by the code calculating the frequency of the old cluster. 2. The frequency returned by

[PATCH] cpufreq: arm_big_little: fix frequency check when bL switcher is active

The check for correct frequency being set in bL_cpufreq_set_rate is broken when the big.LITTLE switcher is active, for two reasons. 1. The 'new_rate' variable gets overwritten before the test by the code calculating the frequency of the old cluster. 2. The frequency returned by

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Tue, 2015-09-15 at 17:04 +0100, Punit Agrawal wrote: > "Jon Medhurst (Tixy)" writes: > > > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote: > >> "Jon Medhurst (Tixy)" writes: > >> > >> > On Mon, 2015-09-14 at

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Tue, 2015-09-15 at 12:03 +0100, Mark Rutland wrote: > On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote: > > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote: > > > "Jon Medhurst (Tixy)" writes: > > > > > > > On Mo

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote: > "Jon Medhurst (Tixy)" writes: > > > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote: > >> Mark Rutland writes: > >> [...] > >> The way the SCP interface is defined, the sensor iden

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Tue, 2015-09-15 at 17:04 +0100, Punit Agrawal wrote: > "Jon Medhurst (Tixy)" <t...@linaro.org> writes: > > > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote: > >> "Jon Medhurst (Tixy)" <t...@linaro.org> writes: > >>

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote: > "Jon Medhurst (Tixy)" <t...@linaro.org> writes: > > > On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote: > >> Mark Rutland <mark.rutl...@arm.com> writes: > >> [...] > >>

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Tue, 2015-09-15 at 12:03 +0100, Mark Rutland wrote: > On Tue, Sep 15, 2015 at 11:46:02AM +0100, Jon Medhurst (Tixy) wrote: > > On Tue, 2015-09-15 at 10:37 +0100, Punit Agrawal wrote: > > > "Jon Medhurst (Tixy)" <t...@linaro.org> writes: > > > >

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote: > Mark Rutland writes: > > >> >> +Sensor bindings for the sensors based on SCPI Message Protocol > >> >> +-- > >> >> +SCPI provides an API to access the various sensors on the SoC.

Re: [PATCH v3 1/5] Documentation: add DT bindings for ARM SCPI sensors

On Mon, 2015-09-14 at 15:38 +0100, Punit Agrawal wrote: > Mark Rutland writes: > > >> >> +Sensor bindings for the sensors based on SCPI Message Protocol > >> >> +-- > >> >> +SCPI provides an API to access the

Re: [PATCH 2/4] drm: Add support for ARM's HDLCD controller.

I haven't reviewed the code in detail, just had one comment I alluded to in a private email the other day... On Wed, 2015-08-05 at 15:28 +0100, Liviu Dudau wrote: > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c > b/drivers/gpu/drm/arm/hdlcd_crtc.c [...] > +void hdlcd_set_scanout(struct

Re: [PATCH 2/4] drm: Add support for ARM's HDLCD controller.

I haven't reviewed the code in detail, just had one comment I alluded to in a private email the other day... On Wed, 2015-08-05 at 15:28 +0100, Liviu Dudau wrote: diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c [...] +void hdlcd_set_scanout(struct

  1   2   3   4   5   >