Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

Hi, On 13 July 2017 at 07:20, gustavo panizzo wrote: > Hello Wang > > thanks for your response > > > On Wed, Jul 12, 2017 at 02:08:04PM +0800, Baolin Wang wrote: >> >> Hi, >> >> On 12 July 2017 at 11:52, gustavo panizzo wrote: >>> >>> The dwc3 could not

Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

Hi, On 13 July 2017 at 07:20, gustavo panizzo wrote: > Hello Wang > > thanks for your response > > > On Wed, Jul 12, 2017 at 02:08:04PM +0800, Baolin Wang wrote: >> >> Hi, >> >> On 12 July 2017 at 11:52, gustavo panizzo wrote: >>> >>> The dwc3 could not release resources when the module is

Re: [PATCH V1 3/3] pinctrl: qcom: spmi-gpio: Correct power_source range check

On 7/13/2017 5:33 AM, Bjorn Andersson wrote: On Mon 12 Jun 23:16 PDT 2017, fengl...@codeaurora.org wrote: From: Fenglin Wu Power source selection in DIG_VIN_CTL is indexed from 0, in the range check it shouldn't be equal to the total number of power sources.

Re: [PATCH V1 3/3] pinctrl: qcom: spmi-gpio: Correct power_source range check

On 7/13/2017 5:33 AM, Bjorn Andersson wrote: On Mon 12 Jun 23:16 PDT 2017, fengl...@codeaurora.org wrote: From: Fenglin Wu Power source selection in DIG_VIN_CTL is indexed from 0, in the range check it shouldn't be equal to the total number of power sources. Signed-off-by: Fenglin Wu

Re: [PATCH V4] PCI: Add Extended Tags quirk for Broadcom HT2100 Root Port

On Thu, Jul 13, 2017 at 3:34 AM, Bjorn Helgaas wrote: > On Wed, Jul 12, 2017 at 08:15:43AM -0400, Sinan Kaya wrote: >> On 7/12/2017 5:44 AM, Ethan Zhao wrote: >> > The dmesg yelled "...Tag handling is broken" , but didn't say how it >> > was handled, that is weird and

Re: [PATCH v6 1/4] firmware: scm: Add new SCM call API for switching memory ownership

On 07/12, Dwivedi, Avaneesh Kumar (avani) wrote: > > > On 7/8/2017 4:19 AM, Stephen Boyd wrote: > >On 06/22, Avaneesh Kumar Dwivedi wrote: > >>diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c > >>index 6e6d561..cdfe986 100644 > >>--- a/drivers/firmware/qcom_scm-64.c >

Re: [PATCH V4] PCI: Add Extended Tags quirk for Broadcom HT2100 Root Port

On Thu, Jul 13, 2017 at 3:34 AM, Bjorn Helgaas wrote: > On Wed, Jul 12, 2017 at 08:15:43AM -0400, Sinan Kaya wrote: >> On 7/12/2017 5:44 AM, Ethan Zhao wrote: >> > The dmesg yelled "...Tag handling is broken" , but didn't say how it >> > was handled, that is weird and confusing, just because

Re: [PATCH v6 1/4] firmware: scm: Add new SCM call API for switching memory ownership

On 07/12, Dwivedi, Avaneesh Kumar (avani) wrote: > > > On 7/8/2017 4:19 AM, Stephen Boyd wrote: > >On 06/22, Avaneesh Kumar Dwivedi wrote: > >>diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c > >>index 6e6d561..cdfe986 100644 > >>--- a/drivers/firmware/qcom_scm-64.c >

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

Hi, Rafael At 07/11/2017 09:26 PM, Dou Liyang wrote: Hi, Rafael Recently, I worked for unify the interrupt delivery mode and do its setup earlier[1]. And I met a bug about ACPI[2]. When I investigated it, I got your *commit c4e1acbb35e4 (ACPI / init: Invoke early ACPI initialization later).*

Re: A question about acpi_early_init(), and want to invoke acpi_early_init() earlier

Hi, Rafael At 07/11/2017 09:26 PM, Dou Liyang wrote: Hi, Rafael Recently, I worked for unify the interrupt delivery mode and do its setup earlier[1]. And I met a bug about ACPI[2]. When I investigated it, I got your *commit c4e1acbb35e4 (ACPI / init: Invoke early ACPI initialization later).*

[PATCH] ASoC: sun8i-codec: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/sunxi/sun8i-codec.c | 2

[PATCH] ASoC: sun8i-codec: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/sunxi/sun8i-codec.c | 2 +- 1 file changed, 1

[PATCH] ASoC: tegra: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/tegra/tegra30_i2s.c | 2

[PATCH] ASoC: tegra: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/tegra/tegra30_i2s.c | 2 +- 1 file changed, 1

[PATCH] ASoC: zx-tdm: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/zte/zx-tdm.c | 2 +- 1

[PATCH] ASoC: zx-tdm: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/zte/zx-tdm.c | 2 +- 1 file changed, 1

[RFC V2 4/6] cpufreq: Use transition_delay_us for legacy governors as well

The policy->transition_delay_us field is used only by the schedutil governor currently, and this field describes how fast the driver wants the cpufreq governor to change CPUs frequency. It should rather be a common thing across all governors, as it doesn't have any schedutil dependency here.

[RFC V2 4/6] cpufreq: Use transition_delay_us for legacy governors as well

The policy->transition_delay_us field is used only by the schedutil governor currently, and this field describes how fast the driver wants the cpufreq governor to change CPUs frequency. It should rather be a common thing across all governors, as it doesn't have any schedutil dependency here.

[RFC V2 0/6] cpufreq: transition-latency cleanups

Hi Rafael, Here is the V2 and sending it as RFC this time. This series tries to cleanup the code around transition-latency and its users. Some of the old legacy code, which may not make much sense now, is dropped as well. Some code consolidation also done across governors. Based of:

[RFC V2 3/6] cpufreq: governor: Drop min_sampling_rate

The cpufreq core and governors aren't supposed to set a limit on how fast we want to try changing the frequency. This is currently done for the legacy governors with help of min_sampling_rate. At worst, we may end up setting the sampling rate to a value lower than the rate at which frequency can

[RFC V2 3/6] cpufreq: governor: Drop min_sampling_rate

The cpufreq core and governors aren't supposed to set a limit on how fast we want to try changing the frequency. This is currently done for the legacy governors with help of min_sampling_rate. At worst, we may end up setting the sampling rate to a value lower than the rate at which frequency can

[RFC V2 0/6] cpufreq: transition-latency cleanups

Hi Rafael, Here is the V2 and sending it as RFC this time. This series tries to cleanup the code around transition-latency and its users. Some of the old legacy code, which may not make much sense now, is dropped as well. Some code consolidation also done across governors. Based of:

[RFC V2 6/6] cpufreq: arm_big_little: Make ->get_transition_latency() mandatory

All users of arm_big_little driver are defining it and there is no need to keep it optional. Make it mandatory to remove the always true conditional statement. Signed-off-by: Viresh Kumar --- drivers/cpufreq/arm_big_little.c | 10 -- 1 file changed, 4

[RFC V2 6/6] cpufreq: arm_big_little: Make ->get_transition_latency() mandatory

All users of arm_big_little driver are defining it and there is no need to keep it optional. Make it mandatory to remove the always true conditional statement. Signed-off-by: Viresh Kumar --- drivers/cpufreq/arm_big_little.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-)

[RFC V2 2/6] cpufreq: schedutil: Set dynamic_switching to true

Set dynamic_switching to 'true' to disallow use of schedutil governor for platforms with transition_latency set to CPUFREQ_ETERNAL, as they may not want to do automatic dynamic frequency switching. Signed-off-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 1 +

[RFC V2 1/6] cpufreq: Replace "max_transition_latency" with "dynamic_switching"

There is no limitation in the ondemand or conservative governors which disallow the transition_latency to be greater than 10 ms. The max_transition_latency field is rather used to disallow automatic dynamic frequency switching for platforms which didn't wanted these governors to run. Replace

[RFC V2 5/6] cpufreq: Cap the default transition delay value to 10 ms

If transition_delay_us isn't defined by the cpufreq driver, the default value of transition delay (time after which the cpufreq governor will try updating the frequency again) is currently calculated by multiplying transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then converting this

[RFC V2 1/6] cpufreq: Replace "max_transition_latency" with "dynamic_switching"

There is no limitation in the ondemand or conservative governors which disallow the transition_latency to be greater than 10 ms. The max_transition_latency field is rather used to disallow automatic dynamic frequency switching for platforms which didn't wanted these governors to run. Replace

[RFC V2 5/6] cpufreq: Cap the default transition delay value to 10 ms

If transition_delay_us isn't defined by the cpufreq driver, the default value of transition delay (time after which the cpufreq governor will try updating the frequency again) is currently calculated by multiplying transition_latency (nsec) with LATENCY_MULTIPLIER (1000) and then converting this

[RFC V2 2/6] cpufreq: schedutil: Set dynamic_switching to true

Set dynamic_switching to 'true' to disallow use of schedutil governor for platforms with transition_latency set to CPUFREQ_ETERNAL, as they may not want to do automatic dynamic frequency switching. Signed-off-by: Viresh Kumar --- kernel/sched/cpufreq_schedutil.c | 1 + 1 file changed, 1

[PATCH] ASoC: zte: spdif: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/zte/zx-spdif.c | 2 +- 1

[PATCH] ASoC: zte: spdif: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/zte/zx-spdif.c | 2 +- 1 file changed, 1

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

Hi Vivek, On 7/13/2017 10:43 AM, Vivek Gautam wrote: > Hi Stephen, > > > On 07/13/2017 04:24 AM, Stephen Boyd wrote: >> On 07/06, Vivek Gautam wrote: >>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain >>> *domain, unsigned long iova, >>> static size_t

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

Hi Vivek, On 7/13/2017 10:43 AM, Vivek Gautam wrote: > Hi Stephen, > > > On 07/13/2017 04:24 AM, Stephen Boyd wrote: >> On 07/06, Vivek Gautam wrote: >>> @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain >>> *domain, unsigned long iova, >>> static size_t

Re: [PATCH V1 2/3] pinctrl: qcom: spmi-gpio: Add dtest route for digital input

On 7/13/2017 5:24 AM, Bjorn Andersson wrote: On Mon 12 Jun 23:16 PDT 2017, fengl...@codeaurora.org wrote: From: Fenglin Wu Add property "qcom,dtest-buffer" to specify which dtest rail to feed when the pin is configured as a digital input. Signed-off-by: Fenglin Wu

Re: [PATCH V1 2/3] pinctrl: qcom: spmi-gpio: Add dtest route for digital input

On 7/13/2017 5:24 AM, Bjorn Andersson wrote: On Mon 12 Jun 23:16 PDT 2017, fengl...@codeaurora.org wrote: From: Fenglin Wu Add property "qcom,dtest-buffer" to specify which dtest rail to feed when the pin is configured as a digital input. Signed-off-by: Fenglin Wu ---

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Wed, 2017-07-12 at 21:40 -0700, Andi Kleen wrote: > On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > > > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > > > On Wed, 2017-07-12 at 15:30 -0700, Andi

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Wed, 2017-07-12 at 21:40 -0700, Andi Kleen wrote: > On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > > > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > > > On Wed, 2017-07-12 at 15:30 -0700, Andi

[PATCH] ASoC: zx-i2s: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/zte/zx-i2s.c | 2 +- 1

[PATCH] ASoC: zx-i2s: constify snd_soc_dai_ops structure

This structure is only stored in the ops field of a snd_soc_dai_driver structure. That field is declared const, so snd_soc_dai_ops structures that have this property can be declared as const also. Signed-off-by: Gustavo A. R. Silva --- sound/soc/zte/zx-i2s.c | 2 +- 1 file changed, 1

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

Hi Stephen, On 07/13/2017 04:24 AM, Stephen Boyd wrote: On 07/06, Vivek Gautam wrote: @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,

Re: [PATCH V4 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

Hi Stephen, On 07/13/2017 04:24 AM, Stephen Boyd wrote: On 07/06, Vivek Gautam wrote: @@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova,

Re: [PATCH v5 3/5] x86, apic: Add freeze event support

On Fri, 7 Jul 2017, Derek Basehore wrote: > This adds support to the clock event devices created by apic to use > freeze events. The apic is able to run a timer during freeze with near > zero power impact on modern CPUs such as skylake. This will allow > S0ix, suspend-to-idle, to be validated on

Re: [PATCH v5 3/5] x86, apic: Add freeze event support

On Fri, 7 Jul 2017, Derek Basehore wrote: > This adds support to the clock event devices created by apic to use > freeze events. The apic is able to run a timer during freeze with near > zero power impact on modern CPUs such as skylake. This will allow > S0ix, suspend-to-idle, to be validated on

Re: [PATCH v5 5/5] intel_idle: Add S0ix validation

On Wed, 12 Jul 2017, dbasehore . wrote: > On Wed, Jul 12, 2017 at 3:16 PM, Thomas Gleixner wrote: > > There are more issues with this: If there is a hrtimer scheduled on that > > last CPU which enters the idle freeze state and that timer is 10 minutes > > away, then the check

Re: [PATCH v5 5/5] intel_idle: Add S0ix validation

On Wed, 12 Jul 2017, dbasehore . wrote: > On Wed, Jul 12, 2017 at 3:16 PM, Thomas Gleixner wrote: > > There are more issues with this: If there is a hrtimer scheduled on that > > last CPU which enters the idle freeze state and that timer is 10 minutes > > away, then the check timer can't be

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

On 13-07-17, 10:52, Chen-Yu Tsai wrote: > I'm afraid the regulator case still doesn't make sense. The voltage > constraints should be set within each supplies device node. This was > explained in the discussion in v1 [1]. I thought we were discussing about something I mentioned in one of my

Re: [RFC v2 5/6] drivers: boot_constraint: Add initial DT bindings

On 13-07-17, 10:52, Chen-Yu Tsai wrote: > I'm afraid the regulator case still doesn't make sense. The voltage > constraints should be set within each supplies device node. This was > explained in the discussion in v1 [1]. I thought we were discussing about something I mentioned in one of my

Re: [PATCH v5 2/5] tick: Add freeze timer events

Derek, On Wed, 12 Jul 2017, dbasehore . wrote: > On Wed, Jul 12, 2017 at 2:25 PM, Thomas Gleixner wrote: > > On Fri, 7 Jul 2017, Derek Basehore wrote: > >> +/* > >> + * Clockevent device may run during freeze > >> + */ > >> +# define CLOCK_EVT_FEAT_FREEZE_NONSTOP

Re: [PATCH v1] spi: loopback-test: provide loop request option.

On 12.07.2017 15:40, Oleksij Rempel wrote: From: Oleksij Rempel Provide a module parameter to request internal loop by the SPI master controller. This should make loop testing easier without extra HW modification. Signed-off-by: Oleksij Rempel

Re: [PATCH v5 2/5] tick: Add freeze timer events

Derek, On Wed, 12 Jul 2017, dbasehore . wrote: > On Wed, Jul 12, 2017 at 2:25 PM, Thomas Gleixner wrote: > > On Fri, 7 Jul 2017, Derek Basehore wrote: > >> +/* > >> + * Clockevent device may run during freeze > >> + */ > >> +# define CLOCK_EVT_FEAT_FREEZE_NONSTOP 0x000100 > > > > Is that

Re: [PATCH v1] spi: loopback-test: provide loop request option.

On 12.07.2017 15:40, Oleksij Rempel wrote: From: Oleksij Rempel Provide a module parameter to request internal loop by the SPI master controller. This should make loop testing easier without extra HW modification. Signed-off-by: Oleksij Rempel --- drivers/spi/spi-loopback-test.c | 18

Re: [PATCH] clk: Provide bulk prepare_enable disable_unprepare variants

On Wed 12 Jul 16:04 PDT 2017, Stephen Boyd wrote: > On 07/12, Bjorn Andersson wrote: > > This extends the existing set of bulk helpers with prepare_enable and > > disable_unprepare variants. > > > > Signed-off-by: Bjorn Andersson > > --- > > Looks good. I can stick

Re: [PATCH] clk: Provide bulk prepare_enable disable_unprepare variants

On Wed 12 Jul 16:04 PDT 2017, Stephen Boyd wrote: > On 07/12, Bjorn Andersson wrote: > > This extends the existing set of bulk helpers with prepare_enable and > > disable_unprepare variants. > > > > Signed-off-by: Bjorn Andersson > > --- > > Looks good. I can stick this under a tag in clk tree

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote: > On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > > > Josh Poimboeuf writes:

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Thu, Jul 13, 2017 at 06:28:43AM +0200, Mike Galbraith wrote: > On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > > > Josh Poimboeuf writes: > > > > > > > > > >

Re: [PATCH v2 01/22] docs: fpga: add a document for Intel FPGA driver overview

On Wed, Jul 12, 2017 at 09:51:32AM -0500, Alan Tull wrote: > On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao wrote: > > Hi Hao, > > > Add a document for Intel FPGA driver overview. > > > > Signed-off-by: Enno Luebbers > > Signed-off-by: Xiao Guangrong

Re: [PATCH v2 01/22] docs: fpga: add a document for Intel FPGA driver overview

On Wed, Jul 12, 2017 at 09:51:32AM -0500, Alan Tull wrote: > On Sun, Jun 25, 2017 at 8:51 PM, Wu Hao wrote: > > Hi Hao, > > > Add a document for Intel FPGA driver overview. > > > > Signed-off-by: Enno Luebbers > > Signed-off-by: Xiao Guangrong > > Signed-off-by: Wu Hao > > > > v2: added

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > > Josh Poimboeuf writes: > > > > > > > > The ORC data format does have a few downsides compared

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Wed, 2017-07-12 at 21:15 -0700, Andi Kleen wrote: > On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > > Josh Poimboeuf writes: > > > > > > > > The ORC data format does have a few downsides compared to DWARF. The > > >

Re: [PATCH] stating: lustre: fix sparse error: incompatible types in comparison expression

On Jul 12, 2017, at 10:10 PM, Rui Teng wrote: > Comparing two user space addresses to avoid sparse error: > > drivers/staging//lustre/lnet/selftest/conrpc.c:490:30: error: > incompatible types in comparison expression (different address spaces) > > Signed-off-by: Rui Teng

Re: [PATCH] stating: lustre: fix sparse error: incompatible types in comparison expression

On Jul 12, 2017, at 10:10 PM, Rui Teng wrote: > Comparing two user space addresses to avoid sparse error: > > drivers/staging//lustre/lnet/selftest/conrpc.c:490:30: error: > incompatible types in comparison expression (different address spaces) > > Signed-off-by: Rui Teng > --- >

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Wed, Jul 12, 2017 at 05:47:59PM -0500, Josh Poimboeuf wrote: > On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote: > > Josh Poimboeuf writes: > > > > > > The ORC data format does have a few downsides compared to DWARF. The > > > ORC unwind tables take up ~1MB more

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Wed, Jul 12, 2017 at 05:47:59PM -0500, Josh Poimboeuf wrote: > On Wed, Jul 12, 2017 at 03:30:31PM -0700, Andi Kleen wrote: > > Josh Poimboeuf writes: > > > > > > The ORC data format does have a few downsides compared to DWARF. The > > > ORC unwind tables take up ~1MB more memory than DWARF

[git pull] drm fixes (and mediatek) for 4.13-rc1

Hi Linus, Some fixes tree came in since the main pull request for rc1, primarily i915 and drm-misc and one amd fix. The drm core vblank regression fix is probably the most important thing. I've also added the mediatek feature pull, it wasn't that big and didn't look like it would have any impact

[git pull] drm fixes (and mediatek) for 4.13-rc1

Hi Linus, Some fixes tree came in since the main pull request for rc1, primarily i915 and drm-misc and one amd fix. The drm core vblank regression fix is probably the most important thing. I've also added the mediatek feature pull, it wasn't that big and didn't look like it would have any impact

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

Hi Wei, [auto build test ERROR on linus/master] [also build test ERROR on v4.12 next-20170712] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Wei-Wang/Virtio-balloon-Enhancement/20170713-074956

Re: [PATCH v12 5/8] virtio-balloon: VIRTIO_BALLOON_F_SG

Hi Wei, [auto build test ERROR on linus/master] [also build test ERROR on v4.12 next-20170712] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Wei-Wang/Virtio-balloon-Enhancement/20170713-074956

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

On Wed, Jul 12, 2017 at 9:14 PM, Viresh Kumar wrote: > On 12-07-17, 20:52, Joel Fernandes wrote: >> Yes, that makes sense, its a bit subtle but I get what you're doing >> now and I agree with it. Its also cleaner than my original patch :-) >> and yeah definitely needs a

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

On Wed, Jul 12, 2017 at 9:14 PM, Viresh Kumar wrote: > On 12-07-17, 20:52, Joel Fernandes wrote: >> Yes, that makes sense, its a bit subtle but I get what you're doing >> now and I agree with it. Its also cleaner than my original patch :-) >> and yeah definitely needs a comment ;-) > > And I have

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > Josh Poimboeuf writes: > > > > > > The ORC data format does have a few downsides compared to DWARF. The > > > ORC unwind tables take up ~1MB more memory

Re: [PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

On Thu, Jul 13, 2017 at 05:03:00AM +0200, Mike Galbraith wrote: > On Wed, 2017-07-12 at 15:30 -0700, Andi Kleen wrote: > > Josh Poimboeuf writes: > > > > > > The ORC data format does have a few downsides compared to DWARF. The > > > ORC unwind tables take up ~1MB more memory than DWARF eh_frame

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

On 12-07-17, 20:52, Joel Fernandes wrote: > Yes, that makes sense, its a bit subtle but I get what you're doing > now and I agree with it. Its also cleaner than my original patch :-) > and yeah definitely needs a comment ;-) And I have full trust on you to include that comment in you V5 :) --

Re: [PATCH RFC v4] cpufreq: schedutil: Make iowait boost more energy efficient

On 12-07-17, 20:52, Joel Fernandes wrote: > Yes, that makes sense, its a bit subtle but I get what you're doing > now and I agree with it. Its also cleaner than my original patch :-) > and yeah definitely needs a comment ;-) And I have full trust on you to include that comment in you V5 :) --

Re: [f2fs-dev] [PATCH v2] f2fs: Don't clear SGID when inheriting ACLs

On 2017/7/12 7:31, Jaegeuk Kim wrote: > This patch copies commit b7f8a09f80: > "btrfs: Don't clear SGID when inheriting ACLs" written by Jan. > > Fixes: 073931017b49d9458aa351605b43a7e34598caef > CC: sta...@vger.kernel.org > Signed-off-by: Jan Kara > Signed-off-by: Jaegeuk Kim

[PATCH v8 0/7] perf report: Show branch type

v8: --- Change PERF_BR_NONE to PERF_BR_UNKNOWN according to Peter's comments. No other functional changes. v7: --- Redefine the common branch types according to review comments from Michael Ellerman Now the patch series just defines a minimum but more common

Re: [f2fs-dev] [PATCH v2] f2fs: Don't clear SGID when inheriting ACLs

On 2017/7/12 7:31, Jaegeuk Kim wrote: > This patch copies commit b7f8a09f80: > "btrfs: Don't clear SGID when inheriting ACLs" written by Jan. > > Fixes: 073931017b49d9458aa351605b43a7e34598caef > CC: sta...@vger.kernel.org > Signed-off-by: Jan Kara > Signed-off-by: Jaegeuk Kim Reviewed-by:

[PATCH v8 0/7] perf report: Show branch type

v8: --- Change PERF_BR_NONE to PERF_BR_UNKNOWN according to Peter's comments. No other functional changes. v7: --- Redefine the common branch types according to review comments from Michael Ellerman Now the patch series just defines a minimum but more common set of branch

[PATCH v8 5/7] perf util: Create branch.c/.h for common branch functions

Create new util/branch.c and util/branch.h to contain the common branch functions. Such as: branch_type_count(): Count the numbers of branch types branch_type_name() : Return the name of branch type branch_type_stat_display(): Display branch type statistics info branch_type_str(): Construct the

[PATCH v8 5/7] perf util: Create branch.c/.h for common branch functions

Create new util/branch.c and util/branch.h to contain the common branch functions. Such as: branch_type_count(): Count the numbers of branch types branch_type_name() : Return the name of branch type branch_type_stat_display(): Display branch type statistics info branch_type_str(): Construct the

[PATCH v8 7/7] perf report: Show branch type in callchain entry

Show branch type in callchain entry. The branch type is printed with other LBR information (such as cycles/abort/...). For example: perf record -g -j any,save_type perf report --branch-history --stdio --no-children 38.50% div.c:45[.] maindiv |

[PATCH v8 7/7] perf report: Show branch type in callchain entry

Show branch type in callchain entry. The branch type is printed with other LBR information (such as cycles/abort/...). For example: perf record -g -j any,save_type perf report --branch-history --stdio --no-children 38.50% div.c:45[.] maindiv |

[PATCH v8 4/7] perf report: Refactor the branch info printing code

The branch info such as predicted/cycles/... are printed at the callchain entries. For example: perf report --branch-history --no-children --stdio --1.07%--main div.c:39 (predicted:52.4% cycles:1 iterations:17) main div.c:44 (predicted:52.4% cycles:1) main

[PATCH v8 2/7] perf/x86/intel: Record branch type

Perf already has support for disassembling the branch instruction and using the branch type for filtering. The patch just records the branch type in perf_branch_entry. Before recording, the patch converts the x86 branch type to common branch type. Change log -- v8: Change PERF_BR_NONE to

[PATCH v8 4/7] perf report: Refactor the branch info printing code

The branch info such as predicted/cycles/... are printed at the callchain entries. For example: perf report --branch-history --no-children --stdio --1.07%--main div.c:39 (predicted:52.4% cycles:1 iterations:17) main div.c:44 (predicted:52.4% cycles:1) main

[PATCH v8 2/7] perf/x86/intel: Record branch type

Perf already has support for disassembling the branch instruction and using the branch type for filtering. The patch just records the branch type in perf_branch_entry. Before recording, the patch converts the x86 branch type to common branch type. Change log -- v8: Change PERF_BR_NONE to

[PATCH v8 1/7] perf/core: Define the common branch type classification

It is often useful to know the branch types while analyzing branch data. For example, a call is very different from a conditional branch. Currently we have to look it up in binary while the binary may later not be available and even the binary is available but user has to take some time. It is

[PATCH v8 3/7] perf record: Create a new option save_type in --branch-filter

The option indicates the kernel to save branch type during sampling. One example: perf record -g --branch-filter any,save_type Change log -- v8: Not changed. v7: Not changed. v6: Not changed. v5: Not changed. Signed-off-by: Jin Yao ---

[PATCH v8 6/7] perf report: Show branch type statistics for stdio mode

Show the branch type statistics at the end of perf report --stdio. For example: perf report --stdio COND_FWD: 28.5% COND_BWD: 9.4% CROSS_4K: 0.7% CROSS_2M: 14.1% COND: 37.9% UNCOND: 0.2% IND: 6.7% CALL: 26.5% RET: 28.7% SYSRET: 0.0% The branch types are:

[PATCH v8 3/7] perf record: Create a new option save_type in --branch-filter

The option indicates the kernel to save branch type during sampling. One example: perf record -g --branch-filter any,save_type Change log -- v8: Not changed. v7: Not changed. v6: Not changed. v5: Not changed. Signed-off-by: Jin Yao --- tools/perf/Documentation/perf-record.txt | 1

[PATCH v8 6/7] perf report: Show branch type statistics for stdio mode

Show the branch type statistics at the end of perf report --stdio. For example: perf report --stdio COND_FWD: 28.5% COND_BWD: 9.4% CROSS_4K: 0.7% CROSS_2M: 14.1% COND: 37.9% UNCOND: 0.2% IND: 6.7% CALL: 26.5% RET: 28.7% SYSRET: 0.0% The branch types are:

[PATCH v8 1/7] perf/core: Define the common branch type classification

It is often useful to know the branch types while analyzing branch data. For example, a call is very different from a conditional branch. Currently we have to look it up in binary while the binary may later not be available and even the binary is available but user has to take some time. It is

Re: [PATCH] mm: Mark create_huge_pmd() inline to prevent build failure

On Wed, Jul 12, 2017 at 5:29 PM, Dan Williams wrote: > On Tue, Jul 11, 2017 at 11:57 PM, Geert Uytterhoeven > wrote: >> With gcc 4.1.2: >> >> mm/memory.o: In function `create_huge_pmd': >> memory.c:(.text+0x93e): undefined reference to >>

Re: [PATCH] mm: Mark create_huge_pmd() inline to prevent build failure

On Wed, Jul 12, 2017 at 5:29 PM, Dan Williams wrote: > On Tue, Jul 11, 2017 at 11:57 PM, Geert Uytterhoeven > wrote: >> With gcc 4.1.2: >> >> mm/memory.o: In function `create_huge_pmd': >> memory.c:(.text+0x93e): undefined reference to >> `do_huge_pmd_anonymous_page' >> >> Converting

Re: [PATCH V4 4/6] iommu/arm-smmu: Add the device_link between masters and smmu

On 07/13/2017 04:25 AM, Stephen Boyd wrote: On 07/06, Vivek Gautam wrote: diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index ddbfa8ab69e6..75567d9698ab 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -1348,6 +1348,7 @@ static int

Re: [PATCH V4 4/6] iommu/arm-smmu: Add the device_link between masters and smmu

On 07/13/2017 04:25 AM, Stephen Boyd wrote: On 07/06, Vivek Gautam wrote: diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index ddbfa8ab69e6..75567d9698ab 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -1348,6 +1348,7 @@ static int

Re: [PATCH V4 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

On 07/13/2017 04:31 AM, Stephen Boyd wrote: On 07/12, Stephen Boyd wrote: On 07/06, Vivek Gautam wrote: From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional

Re: [PATCH V4 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops

On 07/13/2017 04:31 AM, Stephen Boyd wrote: On 07/12, Stephen Boyd wrote: On 07/06, Vivek Gautam wrote: From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional dependencies, so that the

Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC

On Thu, 2017-07-13 at 08:46 +0530, Viresh Kumar wrote: > On 12-07-17, 16:50, Matthias Brugger wrote: > > Hi Eddie, > > > > On 07/11/2017 04:49 AM, Eddie Huang wrote: > > >Hi Sean, > > > > > >On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote: > > >>From: Sean Wang

Re: [PATCH v4 1/3] cpufreq: mediatek: Add support of cpufreq to MT2701/MT7623 SoC

On Thu, 2017-07-13 at 08:46 +0530, Viresh Kumar wrote: > On 12-07-17, 16:50, Matthias Brugger wrote: > > Hi Eddie, > > > > On 07/11/2017 04:49 AM, Eddie Huang wrote: > > >Hi Sean, > > > > > >On Mon, 2017-07-10 at 22:23 +0800, sean.w...@mediatek.com wrote: > > >>From: Sean Wang > > >> > >

  1   2   3   4   5   6   7   8   9   10   >