CPU may not see most up-to-date and correct copy of DMA buffer, when
internal DMA controller is in use.
Problem appears on The Altera SoC FPGA (uses integrated DMA controller),
during higher CPU and system memory load
Signed-off-by: Jan Jablonsky
---
drivers/mmc/host/dw_mmc.c | 3 +--
1 file
CPU may not see most up-to-date and correct copy of DMA buffer, when
internal DMA controller is in use.
Problem appears on The Altera SoC FPGA (uses integrated DMA controller),
during higher CPU and system memory load
Signed-off-by: Jan Jablonsky
---
drivers/mmc/host/dw_mmc.c | 3 +--
1 file
Hi,
I found perf-record --tail-synthesize without --overwrite breaks symbols
for perf-script, perf-report, etc. For example:
[root@]# ~/perf record -ag --tail-synthesize -- sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.129 MB perf.data (3531 samples)
Hi,
I found perf-record --tail-synthesize without --overwrite breaks symbols
for perf-script, perf-report, etc. For example:
[root@]# ~/perf record -ag --tail-synthesize -- sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.129 MB perf.data (3531 samples)
This patch fixes a possible null pointer dereference in
intel_bts_process_auxtrace_info, detected by the semantic patch
deref_null.cocci, with the following warning:
./tools/perf/util/intel-bts.c:921:32-49: ERROR: session -> itrace_synth_opts is
NULL but dereferenced.
Signed-off-by: Wen Yang
This patch fixes a possible null pointer dereference in
intel_bts_process_auxtrace_info, detected by the semantic patch
deref_null.cocci, with the following warning:
./tools/perf/util/intel-bts.c:921:32-49: ERROR: session -> itrace_synth_opts is
NULL but dereferenced.
Signed-off-by: Wen Yang
This patch fixes a possible null pointer dereference in
intel_pt_process_auxtrace_info, detected by the semantic patch
deref_null.cocci, with the following warning:
./tools/perf/util/intel-pt.c:2579:32-49: ERROR: session -> itrace_synth_opts is
NULL but dereferenced.
Signed-off-by: Wen Yang
This patch fixes a possible null pointer dereference in
intel_pt_process_auxtrace_info, detected by the semantic patch
deref_null.cocci, with the following warning:
./tools/perf/util/intel-pt.c:2579:32-49: ERROR: session -> itrace_synth_opts is
NULL but dereferenced.
Signed-off-by: Wen Yang
Hi Victor,
On Tue, Sep 11, 2018 at 06:09:02PM +0900, Victor Chong wrote:
> When dynamic shared memory support is enabled in the OP-TEE Trusted
> OS, it doesn't mean that the driver supports it, which can confuse
> users during debugging. Log a message when dynamic shared memory is
> enabled in
Hi Victor,
On Tue, Sep 11, 2018 at 06:09:02PM +0900, Victor Chong wrote:
> When dynamic shared memory support is enabled in the OP-TEE Trusted
> OS, it doesn't mean that the driver supports it, which can confuse
> users during debugging. Log a message when dynamic shared memory is
> enabled in
On Wed, Nov 21, 2018 at 11:04:32AM +1100, Stephen Rothwell wrote:
> Hi Leon,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> drivers/infiniband/hw/mlx5/main.c
>
> between commit:
>
> 9afc97c29b03 ("mlx5: remove support for ib_get_vector_affinity")
>
> from the rdma
On Wed, Nov 21, 2018 at 11:04:32AM +1100, Stephen Rothwell wrote:
> Hi Leon,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> drivers/infiniband/hw/mlx5/main.c
>
> between commit:
>
> 9afc97c29b03 ("mlx5: remove support for ib_get_vector_affinity")
>
> from the rdma
On Tue 20-11-18 17:47:21, Hugh Dickins wrote:
> On Tue, 20 Nov 2018, Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > filemap_map_pages takes a speculative reference to each page in the
> > range before it tries to lock that page. While this is correct it
> > also can influence page
On Tue 20-11-18 17:47:21, Hugh Dickins wrote:
> On Tue, 20 Nov 2018, Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > filemap_map_pages takes a speculative reference to each page in the
> > range before it tries to lock that page. While this is correct it
> > also can influence page
On Tue 20-11-18 21:51:39, William Kucharski wrote:
>
>
> > On Nov 20, 2018, at 7:12 AM, Michal Hocko wrote:
> >
> > + /*
> > +* Check the locked pages before taking a reference to not
> > +* go in the way of migration.
> > +*/
>
> Could you make
On Tue 20-11-18 21:51:39, William Kucharski wrote:
>
>
> > On Nov 20, 2018, at 7:12 AM, Michal Hocko wrote:
> >
> > + /*
> > +* Check the locked pages before taking a reference to not
> > +* go in the way of migration.
> > +*/
>
> Could you make
On Tue 20-11-18 10:32:07, Dan Williams wrote:
> On Tue, Nov 20, 2018 at 2:35 AM Michal Hocko wrote:
> >
> > From: Michal Hocko
> >
> > Even though vma flags exported via /proc//smaps are explicitly
> > documented to be not guaranteed for future compatibility the warning
> > doesn't go far enough
On Tue 20-11-18 10:32:07, Dan Williams wrote:
> On Tue, Nov 20, 2018 at 2:35 AM Michal Hocko wrote:
> >
> > From: Michal Hocko
> >
> > Even though vma flags exported via /proc//smaps are explicitly
> > documented to be not guaranteed for future compatibility the warning
> > doesn't go far enough
On i.MX6SLL EVK board, there is a debug LED controlled
by MX6SLL_PAD_EPDC_VCOM1__GPIO2_IO04 pin, add support
for it.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sll-evk.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sll-evk.dts
On i.MX6SLL EVK board, there is a debug LED controlled
by MX6SLL_PAD_EPDC_VCOM1__GPIO2_IO04 pin, add support
for it.
Signed-off-by: Anson Huang
---
arch/arm/boot/dts/imx6sll-evk.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sll-evk.dts
Hi Jean,
On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare wrote:
>
> Hi Masahiro, Michal,
>
> When I run "make install", if a kernel by the same version number +
> flavor string already exists, a backup is created with ".old" appended.
> Over time, this adds many entries to my boot menu, makes
Hi Jean,
On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare wrote:
>
> Hi Masahiro, Michal,
>
> When I run "make install", if a kernel by the same version number +
> flavor string already exists, a backup is created with ".old" appended.
> Over time, this adds many entries to my boot menu, makes
On Tue 20-11-18 16:01:47, David Rientjes wrote:
> On Tue, 20 Nov 2018, Jan Kara wrote:
>
> > > Even though vma flags exported via /proc//smaps are explicitly
> > > documented to be not guaranteed for future compatibility the warning
> > > doesn't go far enough because it doesn't mention semantic
On Tue 20-11-18 16:01:47, David Rientjes wrote:
> On Tue, 20 Nov 2018, Jan Kara wrote:
>
> > > Even though vma flags exported via /proc//smaps are explicitly
> > > documented to be not guaranteed for future compatibility the warning
> > > doesn't go far enough because it doesn't mention semantic
On 11/21/2018 12:06 PM, Viresh Kumar wrote:
On 21-11-18, 11:12, Rajendra Nayak wrote:
And the reason for that seems to be that we update the genpd status to
GPD_STATE_ACTIVE
*after* we try to set the performance state, so we always hit this check which
bails out
thinking the genpd is not
On 11/21/2018 12:06 PM, Viresh Kumar wrote:
On 21-11-18, 11:12, Rajendra Nayak wrote:
And the reason for that seems to be that we update the genpd status to
GPD_STATE_ACTIVE
*after* we try to set the performance state, so we always hit this check which
bails out
thinking the genpd is not
On Tue, Nov 20, 2018 at 03:13:59PM -0800, Tadeusz Struk wrote:
> On 11/20/18 3:07 PM, Jarkko Sakkinen wrote:
> +/* Holds the resul of the last successful call to
> tpm_transmit() */
> >>> This comment is cruft.
> >> Do you want me to remove it? This is the comment you proposed.
On Tue, Nov 20, 2018 at 03:13:59PM -0800, Tadeusz Struk wrote:
> On 11/20/18 3:07 PM, Jarkko Sakkinen wrote:
> +/* Holds the resul of the last successful call to
> tpm_transmit() */
> >>> This comment is cruft.
> >> Do you want me to remove it? This is the comment you proposed.
On 21-11-18, 11:12, Rajendra Nayak wrote:
> And the reason for that seems to be that we update the genpd status to
> GPD_STATE_ACTIVE
> *after* we try to set the performance state, so we always hit this check
> which bails out
> thinking the genpd is not ON.
Thanks for looking at it. Here is
On 21-11-18, 11:12, Rajendra Nayak wrote:
> And the reason for that seems to be that we update the genpd status to
> GPD_STATE_ACTIVE
> *after* we try to set the performance state, so we always hit this check
> which bails out
> thinking the genpd is not ON.
Thanks for looking at it. Here is
[ Cc:-ed a few other gents and lkml. ]
* Jens Axboe wrote:
> Hi,
>
> So this is a fun one... While I was doing the aio polled work, I noticed
> that the submitting process spent a substantial amount of time copying
> data to/from userspace. For aio, that's iocb and io_event, which are 64
>
[ Cc:-ed a few other gents and lkml. ]
* Jens Axboe wrote:
> Hi,
>
> So this is a fun one... While I was doing the aio polled work, I noticed
> that the submitting process spent a substantial amount of time copying
> data to/from userspace. For aio, that's iocb and io_event, which are 64
>
On 20/11/2018 11:38 PM, Thierry Reding wrote:
> On Tue, Nov 20, 2018 at 05:11:17PM +0800, Wei Ni wrote:
>> Add support for get_trend ops that allows soctherm
>> sensors to be used with the step-wise governor.
>>
>> Signed-off-by: Wei Ni
>> ---
>> drivers/thermal/tegra/soctherm.c | 34
On 20/11/2018 11:38 PM, Thierry Reding wrote:
> On Tue, Nov 20, 2018 at 05:11:17PM +0800, Wei Ni wrote:
>> Add support for get_trend ops that allows soctherm
>> sensors to be used with the step-wise governor.
>>
>> Signed-off-by: Wei Ni
>> ---
>> drivers/thermal/tegra/soctherm.c | 34
On Wed, Oct 24, 2018 at 7:15 AM Sami Tolvanen wrote:
>
> If an ARM mapping symbol shares an address with a valid symbol,
> find_elf_symbol can currently return the mapping symbol instead, as the
> symbol is not validated. This can result in confusing warnings:
>
> WARNING:
On Wed, Oct 24, 2018 at 7:15 AM Sami Tolvanen wrote:
>
> If an ARM mapping symbol shares an address with a valid symbol,
> find_elf_symbol can currently return the mapping symbol instead, as the
> symbol is not validated. This can result in confusing warnings:
>
> WARNING:
There's plenty of places around __get_user_pages() that has a parameter
"nonblocking" which does not really mean that "it won't block" (because
it can really block) but instead it shows whether the mmap_sem is
released by up_read() during the page fault handling mostly when
VM_FAULT_RETRY is
There was a special path in handle_userfault() in the past that we'll
return a VM_FAULT_NOPAGE when we detected non-fatal signals when waiting
for userfault handling. We did that by reacquiring the mmap_sem before
returning. However that brings a risk in that the vmas might have
changed when we
There's plenty of places around __get_user_pages() that has a parameter
"nonblocking" which does not really mean that "it won't block" (because
it can really block) but instead it shows whether the mmap_sem is
released by up_read() during the page fault handling mostly when
VM_FAULT_RETRY is
There was a special path in handle_userfault() in the past that we'll
return a VM_FAULT_NOPAGE when we detected non-fatal signals when waiting
for userfault handling. We did that by reacquiring the mmap_sem before
returning. However that brings a risk in that the vmas might have
changed when we
The idea comes from a discussion between Linus and Andrea [1].
Before this patch we only allow a page fault to retry once. We achieved
this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing
handle_mm_fault() the second time. This was majorly used to avoid
unexpected starvation of the
This is the gup counterpart of the change that allows the VM_FAULT_RETRY
to happen for more than once.
Signed-off-by: Peter Xu
---
mm/gup.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index a40111c742ba..7c3b3ab6be88 100644
---
The idea comes from a discussion between Linus and Andrea [1].
Before this patch we only allow a page fault to retry once. We achieved
this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing
handle_mm_fault() the second time. This was majorly used to avoid
unexpected starvation of the
This is the gup counterpart of the change that allows the VM_FAULT_RETRY
to happen for more than once.
Signed-off-by: Peter Xu
---
mm/gup.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index a40111c742ba..7c3b3ab6be88 100644
---
v3:
- fix up issues that krobot reported, rebase
This is an RFC series as cleanup and enhancements to current page
fault logic. The whole idea comes from the discussion between Andrea
and Linus on the bug reported by syzbot here:
https://lkml.org/lkml/2017/11/2/833
Basically it does two
v3:
- fix up issues that krobot reported, rebase
This is an RFC series as cleanup and enhancements to current page
fault logic. The whole idea comes from the discussion between Andrea
and Linus on the bug reported by syzbot here:
https://lkml.org/lkml/2017/11/2/833
Basically it does two
On 11/21/2018 11:36 AM, Viresh Kumar wrote:
On 21-11-18, 10:47, Viresh Kumar wrote:
On 21-11-18, 10:34, Rajendra Nayak wrote:
On 11/5/2018 12:06 PM, Viresh Kumar wrote:
Introduce a new helper dev_pm_opp_xlate_performance_state() which will
be used to translate from pstate of a device to
On 11/21/2018 11:36 AM, Viresh Kumar wrote:
On 21-11-18, 10:47, Viresh Kumar wrote:
On 21-11-18, 10:34, Rajendra Nayak wrote:
On 11/5/2018 12:06 PM, Viresh Kumar wrote:
Introduce a new helper dev_pm_opp_xlate_performance_state() which will
be used to translate from pstate of a device to
On Tue, 20 Nov 2018, Linus Torvalds wrote:
> > Implements arch_update_spec_restriction() for x86. Use STIBP to
> > restrict speculative execution when running a task set to non-dumpable,
> > or clear the restriction if the task is set to dumpable.
>
> I don't think this necessarily makes sense.
On Tue, 20 Nov 2018, Linus Torvalds wrote:
> > Implements arch_update_spec_restriction() for x86. Use STIBP to
> > restrict speculative execution when running a task set to non-dumpable,
> > or clear the restriction if the task is set to dumpable.
>
> I don't think this necessarily makes sense.
On Thu, Nov 15, 2018 at 9:56 AM Paul Walmsley wrote:
>
> Drop modpost command line switches that are no longer used by
> makefile.modpost, upon request from Sam Ravnborg ,
> who wrote:
>
> modpost is not supposed to be used outside the kernel build. [...]
> I checked if there were any
On Thu, Nov 15, 2018 at 9:56 AM Paul Walmsley wrote:
>
> Drop modpost command line switches that are no longer used by
> makefile.modpost, upon request from Sam Ravnborg ,
> who wrote:
>
> modpost is not supposed to be used outside the kernel build. [...]
> I checked if there were any
Hi Paul,
On Thu, Nov 15, 2018 at 9:57 AM Paul Walmsley wrote:
>
> During development of a serial console driver with a gcc 8.2.0
> toolchain for RISC-V, the following modpost warning appeared:
>
>
> WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the
> variable
Hi Paul,
On Thu, Nov 15, 2018 at 9:57 AM Paul Walmsley wrote:
>
> During development of a serial console driver with a gcc 8.2.0
> toolchain for RISC-V, the following modpost warning appeared:
>
>
> WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the
> variable
On Tue, Nov 20, 2018 at 11:42:05PM +0100, Cristian Sicilia wrote:
> Thanks for note
>
> Can make sense do the patch for function that stay in the line but is not
> aligned, or is better doesn't change anything?
> Like this:
>
> static ssize_t gb_camera_debugfs_capabilities(struct gb_camera
On Tue, Nov 20, 2018 at 11:42:05PM +0100, Cristian Sicilia wrote:
> Thanks for note
>
> Can make sense do the patch for function that stay in the line but is not
> aligned, or is better doesn't change anything?
> Like this:
>
> static ssize_t gb_camera_debugfs_capabilities(struct gb_camera
On 11/19/18 10:57 AM, Tom Talpey wrote:
> John, thanks for the discussion at LPC. One of the concerns we
> raised however was the performance test. The numbers below are
> rather obviously tainted. I think we need to get a better baseline
> before concluding anything...
>
> Here's my main
On 11/19/18 10:57 AM, Tom Talpey wrote:
> John, thanks for the discussion at LPC. One of the concerns we
> raised however was the performance test. The numbers below are
> rather obviously tainted. I think we need to get a better baseline
> before concluding anything...
>
> Here's my main
On 21-11-18, 10:47, Viresh Kumar wrote:
> On 21-11-18, 10:34, Rajendra Nayak wrote:
> >
> >
> > On 11/5/2018 12:06 PM, Viresh Kumar wrote:
> > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will
> > > be used to translate from pstate of a device to another one.
> > >
> > >
On 21-11-18, 10:47, Viresh Kumar wrote:
> On 21-11-18, 10:34, Rajendra Nayak wrote:
> >
> >
> > On 11/5/2018 12:06 PM, Viresh Kumar wrote:
> > > Introduce a new helper dev_pm_opp_xlate_performance_state() which will
> > > be used to translate from pstate of a device to another one.
> > >
> > >
On Mon, Nov 19, 2018 at 08:29:39PM -0700, Jason Gunthorpe wrote:
> Date: Mon, 19 Nov 2018 20:29:39 -0700
> From: Jason Gunthorpe
> To: Kenneth Lee
> CC: Leon Romanovsky , Kenneth Lee ,
> Tim Sell , linux-...@vger.kernel.org, Alexander
> Shishkin , Zaibo Xu
> , zhangfei@foxmail.com,
On Mon, Nov 19, 2018 at 08:29:39PM -0700, Jason Gunthorpe wrote:
> Date: Mon, 19 Nov 2018 20:29:39 -0700
> From: Jason Gunthorpe
> To: Kenneth Lee
> CC: Leon Romanovsky , Kenneth Lee ,
> Tim Sell , linux-...@vger.kernel.org, Alexander
> Shishkin , Zaibo Xu
> , zhangfei@foxmail.com,
Hi Anson,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on soc-thermal/next]
[also build test WARNING on v4.20-rc3 next-20181120]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Anson,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on soc-thermal/next]
[also build test WARNING on v4.20-rc3 next-20181120]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
On 21-11-18, 05:49, Anson Huang wrote:
> The thermal driver is a standalone driver for monitoring SoC temperature
> by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
> is NOT set. So remove the dependency with CPU_THERMAL.
>
> Introduce dummy function of legacy cooling
On 21-11-18, 05:49, Anson Huang wrote:
> Put return value checks of calling imx_init_from_nvmem_cells()
> into one block to save one condition block for normal case.
>
> Signed-off-by: Anson Huang
> ---
> drivers/thermal/imx_thermal.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
On 21-11-18, 05:49, Anson Huang wrote:
> The thermal driver is a standalone driver for monitoring SoC temperature
> by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
> is NOT set. So remove the dependency with CPU_THERMAL.
>
> Introduce dummy function of legacy cooling
On 21-11-18, 05:49, Anson Huang wrote:
> Put return value checks of calling imx_init_from_nvmem_cells()
> into one block to save one condition block for normal case.
>
> Signed-off-by: Anson Huang
> ---
> drivers/thermal/imx_thermal.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Put return value checks of calling imx_init_from_nvmem_cells()
into one block to save one condition block for normal case.
Signed-off-by: Anson Huang
---
drivers/thermal/imx_thermal.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c
The thermal driver is a standalone driver for monitoring SoC temperature
by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
is NOT set. So remove the dependency with CPU_THERMAL.
Introduce dummy function of legacy cooling register/unregister to make
thermal driver probe
Put return value checks of calling imx_init_from_nvmem_cells()
into one block to save one condition block for normal case.
Signed-off-by: Anson Huang
---
drivers/thermal/imx_thermal.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/imx_thermal.c
The thermal driver is a standalone driver for monitoring SoC temperature
by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
is NOT set. So remove the dependency with CPU_THERMAL.
Introduce dummy function of legacy cooling register/unregister to make
thermal driver probe
On Thu, 2018-11-08 at 10:56 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> DT parser.
>
> Signed-off-by: Honghui Zhang
> ---
> drivers/pci/controller/pcie-mediatek.c | 98
>
On Thu, 2018-11-08 at 10:56 +0800, honghui.zh...@mediatek.com wrote:
> From: Honghui Zhang
>
> Use the devm_of_pci_get_host_bridge_resources() API in place of the PCI OF
> DT parser.
>
> Signed-off-by: Honghui Zhang
> ---
> drivers/pci/controller/pcie-mediatek.c | 98
>
On 11/21/2018 11:01 AM, Rajendra Nayak wrote:
On 11/21/2018 10:46 AM, Viresh Kumar wrote:
On 21-11-18, 10:33, Rajendra Nayak wrote:
Hi Viresh,
On 11/5/2018 12:06 PM, Viresh Kumar wrote:
This commit updates genpd core to start propagating performance state
updates to master domains that
On 11/21/2018 11:01 AM, Rajendra Nayak wrote:
On 11/21/2018 10:46 AM, Viresh Kumar wrote:
On 21-11-18, 10:33, Rajendra Nayak wrote:
Hi Viresh,
On 11/5/2018 12:06 PM, Viresh Kumar wrote:
This commit updates genpd core to start propagating performance state
updates to master domains that
On 21-11-18, 11:01, Rajendra Nayak wrote:
> I would think this is analogous to a driver calling clk_set_rate() first and
> then a clk_enable(), which is certainly valid.
> So my question is, if calling a dev_pm_genpd_set_performance_state()
> and then runtime enabling the device would work (and
On 21-11-18, 11:01, Rajendra Nayak wrote:
> I would think this is analogous to a driver calling clk_set_rate() first and
> then a clk_enable(), which is certainly valid.
> So my question is, if calling a dev_pm_genpd_set_performance_state()
> and then runtime enabling the device would work (and
On 11/21/2018 10:46 AM, Viresh Kumar wrote:
On 21-11-18, 10:33, Rajendra Nayak wrote:
Hi Viresh,
On 11/5/2018 12:06 PM, Viresh Kumar wrote:
This commit updates genpd core to start propagating performance state
updates to master domains that have their set_performance_state()
callback set.
On 11/21/2018 10:46 AM, Viresh Kumar wrote:
On 21-11-18, 10:33, Rajendra Nayak wrote:
Hi Viresh,
On 11/5/2018 12:06 PM, Viresh Kumar wrote:
This commit updates genpd core to start propagating performance state
updates to master domains that have their set_performance_state()
callback set.
On 21-11-18, 05:28, Anson Huang wrote:
> Since there is similar case of DEFER PROBE for the case of
> imx_init_from_nvmem_cells
> check, should I create another patch of same fix for it in V5 patch set?
Send that as a separate patch please. Thanks.
--
viresh
On 21-11-18, 05:28, Anson Huang wrote:
> Since there is similar case of DEFER PROBE for the case of
> imx_init_from_nvmem_cells
> check, should I create another patch of same fix for it in V5 patch set?
Send that as a separate patch please. Thanks.
--
viresh
Best Regards!
Anson Huang
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: 2018年11月21日 13:21
> To: Anson Huang
> Cc: rui.zh...@intel.com; edubez...@gmail.com; daniel.lezc...@linaro.org;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
Best Regards!
Anson Huang
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: 2018年11月21日 13:21
> To: Anson Huang
> Cc: rui.zh...@intel.com; edubez...@gmail.com; daniel.lezc...@linaro.org;
> linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
On 21-11-18, 05:08, Anson Huang wrote:
> +static void imx_thermal_unregister_legacy_cooling(struct imx_thermal_data
> *data)
> +{
> + cpufreq_cooling_unregister(data->cdev);
> + cpufreq_cpu_put(data->policy);
> +}
> +#else
> +static inline int imx_thermal_register_legacy_cooling(struct
>
On 21-11-18, 05:08, Anson Huang wrote:
> +static void imx_thermal_unregister_legacy_cooling(struct imx_thermal_data
> *data)
> +{
> + cpufreq_cooling_unregister(data->cdev);
> + cpufreq_cpu_put(data->policy);
> +}
> +#else
> +static inline int imx_thermal_register_legacy_cooling(struct
>
On 21-11-18, 05:08, Anson Huang wrote:
> The thermal driver is a standalone driver for monitoring SoC temperature
> by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
> is NOT set. So remove the dependency with CPU_THERMAL.
>
> Introduce dummy function of legacy cooling
On 21-11-18, 05:08, Anson Huang wrote:
> The thermal driver is a standalone driver for monitoring SoC temperature
> by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
> is NOT set. So remove the dependency with CPU_THERMAL.
>
> Introduce dummy function of legacy cooling
On 2018-11-21 04:25, Jarkko Sakkinen wrote:
On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote:
general by mucking with some regs and retrying -- that will infinite
loop and confuse everyone. I'm not even 100% convinced that decoding
the insn stream is useful -- AEP can point to
On 2018-11-21 04:25, Jarkko Sakkinen wrote:
On Tue, Nov 20, 2018 at 07:19:37AM -0800, Andy Lutomirski wrote:
general by mucking with some regs and retrying -- that will infinite
loop and confuse everyone. I'm not even 100% convinced that decoding
the insn stream is useful -- AEP can point to
On 21-11-18, 10:34, Rajendra Nayak wrote:
>
>
> On 11/5/2018 12:06 PM, Viresh Kumar wrote:
> > Introduce a new helper dev_pm_opp_xlate_performance_state() which will
> > be used to translate from pstate of a device to another one.
> >
> > Initially this will be used by genpd to find pstate of a
On 21-11-18, 10:34, Rajendra Nayak wrote:
>
>
> On 11/5/2018 12:06 PM, Viresh Kumar wrote:
> > Introduce a new helper dev_pm_opp_xlate_performance_state() which will
> > be used to translate from pstate of a device to another one.
> >
> > Initially this will be used by genpd to find pstate of a
On 21-11-18, 10:33, Rajendra Nayak wrote:
> Hi Viresh,
>
> On 11/5/2018 12:06 PM, Viresh Kumar wrote:
> > This commit updates genpd core to start propagating performance state
> > updates to master domains that have their set_performance_state()
> > callback set.
> >
> > A genpd handles two type
On 21-11-18, 10:33, Rajendra Nayak wrote:
> Hi Viresh,
>
> On 11/5/2018 12:06 PM, Viresh Kumar wrote:
> > This commit updates genpd core to start propagating performance state
> > updates to master domains that have their set_performance_state()
> > callback set.
> >
> > A genpd handles two type
Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道：
>
> Hi Jian,
>
> Not clear to me why should be + instead of *.
>
> ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling
> time) [s]
> 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms]
> n * 1000 * (1/Hz) = n times
Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道：
>
> Hi Jian,
>
> Not clear to me why should be + instead of *.
>
> ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling
> time) [s]
> 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms]
> n * 1000 * (1/Hz) = n times
Best Regards!
Anson Huang
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: 2018年11月21日 11:54
> To: Anson Huang
> Cc: Zhang Rui ; Eduardo Valentin
> ; Daniel Lezcano ; Linux
> PM list ; Linux Kernel Mailing List
> ; l.st...@pengutronix.de; dl-linux-imx
Best Regards!
Anson Huang
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: 2018年11月21日 11:54
> To: Anson Huang
> Cc: Zhang Rui ; Eduardo Valentin
> ; Daniel Lezcano ; Linux
> PM list ; Linux Kernel Mailing List
> ; l.st...@pengutronix.de; dl-linux-imx
The thermal driver is a standalone driver for monitoring SoC temperature
by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
is NOT set. So remove the dependency with CPU_THERMAL.
Introduce dummy function of legacy cooling register/unregister to make
thermal driver probe
The thermal driver is a standalone driver for monitoring SoC temperature
by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
is NOT set. So remove the dependency with CPU_THERMAL.
Introduce dummy function of legacy cooling register/unregister to make
thermal driver probe
1 - 100 of 1736 matches
Mail list logo
