Hi Lukasz,
On Mon, Feb 11, 2019 at 04:30:04PM +0100, Lukasz Luba wrote:
> There is no need for creating another workqueue in the system,
> the existing one should meet the requirements.
> This patch removes devfreq's custom workqueue and uses system one.
> It switches from queue_delayed_work() to
Sorry for the late reply, your message got buried in my inbox :(
On Mon, Jan 21, 2019 at 08:05:10PM +0530, msava...@codeaurora.org wrote:
> On 2019-01-19 05:53, Matthias Kaehlcke wrote:
> > The geni set/get_mctrl() functions currently do nothing unless
> > hardware flow control is
brary.
Include the kernel version of __lshrdi3 in the 32-bit vDSO build.
Signed-off-by: Matthias Kaehlcke
---
arch/x86/entry/vdso/Makefile | 7 ++-
lib/lshrdi3.c| 4 +++-
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry
gcc v4.9.2).
Include the function for x86 builds with clang, which is the
environment where the above error was observed.
Signed-off-by: Matthias Kaehlcke
---
arch/x86/Kconfig | 1 +
include/linux/libgcc.h | 16
lib/Kconfig| 3 +++
lib/Makefile | 1 +
l
Hi Nick,
On Fri, Mar 15, 2019 at 02:31:09PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Fri, Mar 15, 2019 at 12:54 PM Matthias Kaehlcke wrote:
> >
> > Building the 32-bit vDSO with a recent clang version fails due
> > to undefined symbols:
>
On Fri, Mar 15, 2019 at 03:06:37PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke wrote:
> >
> > The compiler may emit calls to __lshrti3 from the compiler runtime
> > library, which results in undefined r
Hi Peter,
On Fri, Mar 15, 2019 at 03:08:57PM -0700, h...@zytor.com wrote:
> On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
> wrote:
> >On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke
> >wrote:
> >>
> >> The compiler may emit calls to __lshrti3 fr
On Fri, Mar 15, 2019 at 03:12:08PM -0700, h...@zytor.com wrote:
> On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
> wrote:
> >On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke
> >wrote:
> >>
> >> The compiler may emit calls to __lshrti3 from the compiler
On Fri, Mar 15, 2019 at 04:53:40PM -0700, h...@zytor.com wrote:
> On March 15, 2019 4:47:01 PM PDT, Matthias Kaehlcke wrote:
> >On Fri, Mar 15, 2019 at 03:12:08PM -0700, h...@zytor.com wrote:
> >> On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
> > wrote:
> >>
Hi Peter,
On Mon, Mar 18, 2019 at 06:16:04PM +0100, Peter Zijlstra wrote:
> On Mon, Mar 18, 2019 at 10:09:37AM -0700, Nick Desaulniers wrote:
> > On Fri, Mar 15, 2019 at 3:29 PM Matthias Kaehlcke wrote:
> > > On Fri, Mar 15, 2019 at 02:31:09PM -0700, 'Nick Desaulniers&
lstra
Signed-off-by: Matthias Kaehlcke
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 9ef547fc7ffe..191f3ce3cb5e 100644
--- a/Makefile
+++ b/Makefile
@@ -667,7 +667,7 @@ KBUILD_CFLAGS += $(call cc-disable-warning,
format-ove
On Fri, Mar 15, 2019 at 01:54:50PM -0700, Matthias Kaehlcke wrote:
> The compiler may emit calls to __lshrti3 from the compiler runtime
> library, which results in undefined references:
>
> arch/x86/kvm/x86.o: In function `mul_u64_u64_shr':
> include/linux/math64.h:186: un
On Mon, Mar 18, 2019 at 02:47:13PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Mon, Mar 18, 2019 at 2:10 PM Matthias Kaehlcke wrote:
> >
> > The clang option -Oz enables *aggressive* optimization for size,
> > which doesn't necessarily re
On Mon, Mar 18, 2019 at 02:50:44PM -0700, h...@zytor.com wrote:
> On March 18, 2019 2:31:13 PM PDT, Matthias Kaehlcke wrote:
> >On Fri, Mar 15, 2019 at 01:54:50PM -0700, Matthias Kaehlcke wrote:
> >> The compiler may emit calls to __lshrti3 from the compiler runtime
> >>
On Mon, Mar 18, 2019 at 04:44:03PM -0700, h...@zytor.com wrote:
> On March 18, 2019 3:16:39 PM PDT, Matthias Kaehlcke wrote:
> >On Mon, Mar 18, 2019 at 02:50:44PM -0700, h...@zytor.com wrote:
> >> On March 18, 2019 2:31:13 PM PDT, Matthias Kaehlcke
> > wrote:
> >&g
On Mon, Mar 18, 2019 at 04:55:38PM -0700, h...@zytor.com wrote:
> On March 18, 2019 4:52:19 PM PDT, Matthias Kaehlcke wrote:
> >On Mon, Mar 18, 2019 at 04:44:03PM -0700, h...@zytor.com wrote:
> >> On March 18, 2019 3:16:39 PM PDT, Matthias Kaehlcke
> > wrote:
> >&g
Hi Gaël,
On Tue, Mar 19, 2019 at 02:13:21PM -0400, Gaël PORTAY wrote:
> From: Enric Balletbo i Serra
>
> Trusted Firmware-A (TF-A) for rk3399 implements a SiP call to get the
> on-die termination (ODT) and auto power down parameters from kernel,
> this patch adds the functionality to do this. Al
On Wed, Mar 20, 2019 at 10:55:06PM +0900, Masahiro Yamada wrote:
> On Sat, Mar 16, 2019 at 4:55 AM Matthias Kaehlcke wrote:
> >
> > Building the 32-bit vDSO with a recent clang version fails due
> > to undefined symbols:
> >
> > arch/x86/entry/vdso/vdso3
Hi Ravi,
On Wed, Jul 24, 2019 at 10:43:54AM -0700, Ravi Chandra Sadineni wrote:
> https://patchwork.kernel.org/patch/11045069/ creates a virtual
> device
To refer to unsubmitted patches in the commit message it is
probably better to use the subject ("PM / wakeup: show wakeup
sources stats in sysf
er ;-)
> It seems the controller needs a short time after downloading the
> firmware before it is ready for the NVM. A delay as short as 1 ms
> seems sufficient, make it 10 ms just in case. No event is received
> during the delay, hence we don't just silently drop an extra event
On Wed, Aug 28, 2019 at 11:26:35PM -0700, Nathan Chancellor wrote:
> Currently, multi_v7_defconfig + CONFIG_FUNCTION_TRACER fails to build
> with clang:
>
> arm-linux-gnueabi-ld: kernel/softirq.o: in function `_local_bh_enable':
> softirq.c:(.text+0x504): undefined reference to `mcount'
> arm-linu
Hi Ulf,
On Thu, Aug 29, 2019 at 10:48:58AM +0200, Ulf Hansson wrote:
> On Wed, 28 Aug 2019 at 23:46, Matthias Kaehlcke wrote:
> >
> > With commit 83293386bc95 ("mmc: core: Prevent processing SDIO IRQs
> > when the card is suspended") SDIO interrupts are dropped i
On Thu, Aug 29, 2019 at 10:29:26AM +0200, Ulf Hansson wrote:
> On Wed, 28 Aug 2019 at 23:46, Matthias Kaehlcke wrote:
> >
> > Move the code to get pending SDIO interrupts from
> > process_sdio_pending_irqs() to a dedicated function.
> >
> > Signed-off-by: Matthi
nnot be added with it unless this is fixed (which means using
> clang 10.0.0 and newer).
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/35
> Link: https://bugs.llvm.org/show_bug.cgi?id=33845
> Link:
> https://github.com/llvm/llvm-project/commit/16fa8b09702378bacfa3d07081afe6b353b99e60
> Reviewed-by: Nick Desaulniers
> Reviewed-by: Stefan Agner
> Signed-off-by: Nathan Chancellor
Reviewed-by: Matthias Kaehlcke
On Fri, Aug 16, 2019 at 10:13:42PM +0200, Pavel Machek wrote:
> On Tue 2019-08-13 12:11:47, Matthias Kaehlcke wrote:
> > Add a .config_led hook which is called by the PHY core when
> > configuration data for a PHY LED is available. Each LED can be
> > configured to be solid
On Fri, Aug 16, 2019 at 10:13:38PM +0200, Pavel Machek wrote:
> Hi!
>
> Please Cc led mailing lists on led issues.
sorry for missing this
> On Tue 2019-08-13 12:11:44, Matthias Kaehlcke wrote:
> > The LED behavior of some Ethernet PHYs is configurable. Add an
> > option
On Fri, Aug 16, 2019 at 03:12:47PM -0700, Florian Fainelli wrote:
> On 8/16/19 2:27 PM, Matthias Kaehlcke wrote:
> > On Fri, Aug 16, 2019 at 10:13:42PM +0200, Pavel Machek wrote:
> >> On Tue 2019-08-13 12:11:47, Matthias Kaehlcke wrote:
> >>> Add a .config_led hook w
pped.
For cards that remained powered during suspend check on resume if
SDIO interrupts are pending, and trigger interrupt processing if
needed.
Fixes: 83293386bc95 ("mmc: core: Prevent processing SDIO IRQs when the card is
suspended")
Signed-off-by: Matthias Kaehlcke
---
drivers
Move the code to get pending SDIO interrupts from
process_sdio_pending_irqs() to a dedicated function.
Signed-off-by: Matthias Kaehlcke
---
drivers/mmc/core/sdio_irq.c | 47 -
include/linux/mmc/host.h| 1 +
2 files changed, 32 insertions(+), 16 deletions
On Fri, Aug 23, 2019 at 12:58:09PM -0700, Florian Fainelli wrote:
> On 8/16/19 3:39 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Aug 16, 2019 at 3:12 PM Florian Fainelli
> > wrote:
> >>
> >> On 8/16/19 2:27 PM, Matthias Kaehlcke wrote:
> >
Hi Ulf,
On Tue, Sep 03, 2019 at 04:21:57PM +0200, Ulf Hansson wrote:
> To avoid each host driver supporting SDIO IRQs, from keeping track
> internally about if SDIO IRQs has been enabled, let's introduce a common
> helper function, sdio_irq_enabled().
>
> The function returns true if SDIO IRQs ar
On Tue, Sep 03, 2019 at 04:21:58PM +0200, Ulf Hansson wrote:
> In cases when SDIO IRQs have been enabled, runtime suspend is prevented by
> the driver. However, this still means dw_mci_runtime_suspend|resume() gets
> called during system suspend/resume, via pm_runtime_force_suspend|resume().
> This
d sdio_signal_irq(struct mmc_host *host)
> {
> + host->sdio_irq_pending = true;
> queue_delayed_work(system_wq, &host->sdio_irq_work, 0);
> }
> EXPORT_SYMBOL_GPL(sdio_signal_irq);
> @@ -173,7 +177,6 @@ static int sdio_irq_thread(void *_host)
> if (ret)
> break;
> ret = process_sdio_pending_irqs(host);
> - host->sdio_irq_pending = false;
> mmc_release_host(host);
>
> /*
Reviewed-by: Matthias Kaehlcke
On Thu, Sep 05, 2019 at 09:29:04AM +0200, Ulf Hansson wrote:
> On Thu, 5 Sep 2019 at 02:14, Matthias Kaehlcke wrote:
> >
> > On Tue, Sep 03, 2019 at 04:21:58PM +0200, Ulf Hansson wrote:
> > > In cases when SDIO IRQs have been enabled, runtime suspend is prevented by
&
nux/mmc/host.h
> @@ -128,6 +128,7 @@ struct mmc_host_ops {
> int (*get_cd)(struct mmc_host *host);
>
> void(*enable_sdio_irq)(struct mmc_host *host, int enable);
> + /* Mandatory callback when using MMC_CAP2_SDIO_IRQ_NOTHREAD. */
> void(*ack_sdio_irq)(struct mmc_host *host);
>
> /* optional callback for HC quirks */
Reviewed-by: Matthias Kaehlcke
mmc_card_set_suspended(host->card);
> cancel_delayed_work_sync(&host->sdio_irq_work);
Reviewed-by: Matthias Kaehlcke
t);
> - host->ops->ack_sdio_irq(host);
> + if (!host->sdio_irq_pending)
> + host->ops->ack_sdio_irq(host);
> }
> mmc_release_host(host);
> }
I'm by no means a SDIO expert, but as far as I can tell this looks
good. I verified that this patch fixes a problem with SDIO interrupts
that are ignored while suspending.
Reviewed-by: Matthias Kaehlcke
sdio_irq_nolock(host, true);
> + sdhci_enable_sdio_irq_nolock(host, true);
> spin_unlock_irqrestore(&host->lock, flags);
> }
FWIW:
Reviewed-by: Matthias Kaehlcke
D12 (1<<6) /* Auto CMD12 support */
> #define SDHCI_AUTO_CMD23 (1<<7) /* Auto CMD23 support */
> #define SDHCI_PV_ENABLED (1<<8) /* Preset value enabled */
> -#define SDHCI_SDIO_IRQ_ENABLED (1<<9) /* SDIO irq enabled */
> #define SDHCI_USE_
Tracking the performance state can be useful for
debugging/understanding power domain behavior.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- split original patch in two, one for genpd_set_performance_state
one for genpd_power_on/off
- updated commit message (original subject was &qu
The events can be useful for power analysis/optimization, e.g.
to track the state of power domains during suspend/resume on
battery powered devices.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- split original patch in two, one for genpd_power_on/off and
one for
On Wed, Oct 02, 2019 at 03:23:54PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Oct 1, 2019 at 4:07 PM Matthias Kaehlcke wrote:
> > --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> > @@ -39,39 +
rves.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- added 0 as first step for devices/panels that require a minimum
PWM duty cycle
- increased 'num-interpolated-steps' values by one, it's not the
number of steps between levels, but that number +1
arch/arm/boo
On Fri, Sep 27, 2019 at 04:42:39AM -0400, Steven Rostedt wrote:
> On Thu, 26 Sep 2019 15:04:38 -0700
> Matthias Kaehlcke wrote:
>
> > Define genpd_power_on/off and genpd_set_performance_state
> > tracepoints and use them.
>
> I agree with Greg about adding a "
On Tue, Oct 01, 2019 at 01:03:43PM -0400, Steven Rostedt wrote:
> On Tue, 1 Oct 2019 09:35:42 -0700
> Matthias Kaehlcke wrote:
>
> > How about this instead:
> >
> > Add tracepoints for genpd_power_on, genpd_power_off and
> > genpd_set_performance_sta
On Tue, Oct 01, 2019 at 02:08:46PM -0400, Steven Rostedt wrote:
> On Tue, 1 Oct 2019 10:42:35 -0700
> Matthias Kaehlcke wrote:
>
> > On Tue, Oct 01, 2019 at 01:03:43PM -0400, Steven Rostedt wrote:
> > > On Tue, 1 Oct 2019 09:35:42 -0700
> > > Matthias Kaehlcke
t it would change the behavior of
the backlight. Also the concept of a minimum brightness level is
currently not supported for CIE 1931 curves.
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288-veyron-edp.dtsi | 35 ++
arch/arm/boot/dts/rk3288-veyron-jaq.d
Hi Taniya,
not a full review, just a couple of things I noticed, comments inline.
On Wed, Sep 18, 2019 at 03:20:17PM +0530, Taniya Das wrote:
> The GCC clock provider have a bunch of generic properties that
> are needed in a device tree. Add a YAML schemas for those. Also update
> the compatible
Add a tracepoint for frequency changes of devfreq devices and
use it.
Signed-off-by: Matthias Kaehlcke
---
drivers/devfreq/devfreq.c | 3 +++
include/trace/events/devfreq.h | 18 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq
ke it a bit more explicit.
Signed-off-by: Matthias Kaehlcke
---
drivers/devfreq/devfreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index ab22bf8a12d6..0e2dd734ab58 100644
--- a/drivers/devfreq/devfreq.c
+++ b/dr
On Thu, Sep 19, 2019 at 12:35:59PM -0400, Steven Rostedt wrote:
> On Wed, 18 Sep 2019 12:15:37 -0700
> Matthias Kaehlcke wrote:
>
> > Add a tracepoint for frequency changes of devfreq devices and
> > use it.
> >
> > Signed-off-by: Matthias Kaehlcke
>
Add a tracepoint for frequency changes of devfreq devices and
use it.
Signed-off-by: Matthias Kaehlcke
---
(sending v2 without much delay wrt v1, since the change in devfreq
probably isn't controversial, and I'll be offline a few days)
Changes in v2:
- included trace_devfreq_frequen
On Fri, Sep 20, 2019 at 10:15:57AM +0900, Chanwoo Choi wrote:
> Hi,
sorry for the delayed response, you message got buried in my
mailbox.
> On 19. 9. 20. 오전 2:44, Matthias Kaehlcke wrote:
> > Add a tracepoint for frequency changes of devfreq devices and
> > use it.
>
On Wed, Sep 25, 2019 at 10:56:15AM +0900, Chanwoo Choi wrote:
> On 19. 9. 25. 오전 4:37, Matthias Kaehlcke wrote:
> > On Fri, Sep 20, 2019 at 10:15:57AM +0900, Chanwoo Choi wrote:
> >> Hi,
> >
> > sorry for the delayed response, you message got buried in my
> > m
ctions are actually doing, rename devfreq_update_status() to
devfreq_update_stats() and viceversa.
Signed-off-by: Matthias Kaehlcke
---
We could also rename the current devfreq_update_stats() to
devfreq_refresh_status() to make it easier to distinguish it from
devfreq_update_stats().
---
drive
in the context of a
frequency transition.
Signed-off-by: Matthias Kaehlcke
---
drivers/devfreq/devfreq.c| 28
drivers/devfreq/governor_passive.c | 6 +++---
drivers/devfreq/governor_userspace.c | 2 +-
drivers/devfreq/tegra20-devfreq.c| 2 +-
drivers/d
ttached
to them. Fortunately internal kernel APIs can be changed, and the ones in
question aren't widely used.
> On 19. 9. 26. 오전 3:43, Matthias Kaehlcke wrote:
> > devfreq has two functions with very similar names, devfreq_update_status()
> > and devfreq_update_stats(). _update
On Thu, Sep 26, 2019 at 08:21:51AM +0100, Ben Dooks wrote:
> /
>
> On 2019-09-25 19:43, Matthias Kaehlcke wrote:
> > devfreq has two functions with very similar names,
> > devfreq_update_status()
> > and devfreq_update_stats(). _update_status() currently update
On Thu, Sep 26, 2019 at 10:11:00AM -0700, Matthias Kaehlcke wrote:
> On Thu, Sep 26, 2019 at 08:21:51AM +0100, Ben Dooks wrote:
> > /
> >
> > On 2019-09-25 19:43, Matthias Kaehlcke wrote:
> > > devfreq has two functions with very similar names,
> >
lf explanatory as possible, misleading variable
don't help with that.
> I leave the final decision of this patch to Myungjoo.
> If he like this patch, I have no any objection.
Myungjoo, what do you think about the patch?
> On 19. 9. 26. 오전 3:43, Matthias Kaehlcke wrote:
> >
Define genpd_power_on/off and genpd_set_performance_state
tracepoints and use them.
Signed-off-by: Matthias Kaehlcke
---
drivers/base/power/domain.c | 27 +---
include/trace/events/power.h | 49
2 files changed, 72 insertions(+), 4
Hi Daniel,
On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote:
> On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote:
> > On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote:
> > > On 07/08/2019 21:15, Matthias Kaehlcke wrote:
> > >
cit return statement use the common return path, which
releases the lock.
Fixes: 11b86c7004ef1 ("platform/chrome: Add cros_ec_accel_legacy driver")
Signed-off-by: Matthias Kaehlcke
---
drivers/iio/accel/cros_ec_accel_legacy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
On Mon, Jul 15, 2019 at 12:40:42PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Jul 15, 2019 at 12:10 PM Matthias Kaehlcke wrote:
> >
> > Before doing any actual work cros_ec_accel_legacy_read() acquires
> > a mutex, which is released at the end of the function.
Hi Benson,
On Mon, Jul 15, 2019 at 12:55:57PM -0700, Benson Leung wrote:
> Hi Matthias,
>
> On Mon, Jul 15, 2019 at 12:10:17PM -0700, Matthias Kaehlcke wrote:
> > Before doing any actual work cros_ec_accel_legacy_read() acquires
> > a mutex, which is released at the end of
On Mon, Oct 21, 2019 at 04:49:48PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, Oct 21, 2019 at 11:47 AM Matthias Kaehlcke wrote:
> >
> > On Sat, Oct 19, 2019 at 11:12:26AM -0700, Douglas Anderson wrote:
> > > This is commit fdfeff0f9e3d ("arm64: hw_breakpoi
On Tue, Oct 22, 2019 at 11:35:43AM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias, Bjorn andresson,
>
> On 2019-10-21 12:07, Harish Bandi wrote:
> > + Bala
> >
> > On 2019-10-18 23:52, Matthias Kaehlcke wrote:
> > > On Thu, Oct 17, 2019 at 10:
Hi Georgi,
On Tue, Apr 28, 2020 at 12:16:50PM +0300, Georgi Djakov wrote:
> There is a repeated pattern in multiple drivers where they want to switch
> the bandwidth between zero and some other value. This is happening often
> in the suspend/resume callbacks. Let's add helper functions to enable a
clock frequency input to serial engine clock
> + * @opp_table: Pointer to the OPP table
> + * @has_opp_table: Specifies if the SE has an OPP table
> */
> struct geni_se {
> void __iomem *base;
> @@ -41,6 +43,8 @@ struct geni_se {
> struct clk *clk;
> unsigned int num_clk_levels;
> unsigned long *clk_perf_tbl;
> + struct opp_table *opp_table;
> + bool has_opp_table;
> };
>
> /* Common SE registers */
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
Reviewed-by: Matthias Kaehlcke
if (mas->se.has_opp_table)
> + dev_pm_opp_of_remove_table(&pdev->dev);
> + dev_pm_opp_put_clkname(mas->se.opp_table);
> /* Unregister _before_ disabling pm_runtime() so we stop transfers */
> spi_unregister_master(spi);
>
> @@ -617,6 +634,9 @@ static int __maybe_unused spi_geni_runtime_suspend(struct
> device *dev)
> struct spi_master *spi = dev_get_drvdata(dev);
> struct spi_geni_master *mas = spi_master_get_devdata(spi);
>
> + /* Drop the performance state vote */
> + dev_pm_opp_set_rate(dev, 0);
> +
> return geni_se_resources_off(&mas->se);
> }
Reviewed-by: Matthias Kaehlcke
Hi Rajendra,
On Tue, Apr 28, 2020 at 07:02:51PM +0530, Rajendra Nayak wrote:
> qup has a requirement to vote on the performance state of the CX domain
> in sdm845 devices. Add OPP tables for these and also add power-domains
> property for all qup instances.
>
> Signed-off-by: Rajendra Nayak
> Si
te(dev, 0);
> rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
> if (rc)
> DPU_ERROR("clock disable failed rc:%d\n", rc);
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index 211f5de9..2a52e4e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -128,6 +128,10 @@ struct dpu_kms {
>
> struct platform_device *pdev;
> bool rpm_enabled;
> +
> + struct opp_table *opp_table;
> + bool has_opp_table;
> +
> struct dss_module_power mp;
>
> /* reference count bandwidth requests, so we know when we can
Reviewed-by: Matthias Kaehlcke
On Tue, Apr 28, 2020 at 07:02:55PM +0530, Rajendra Nayak wrote:
> Add the OPP tables for DSI and MDP based on the perf state/clk
> requirements, and add the power-domains property to specify the
> scalable power domain.
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/sdm845.dt
On Tue, Apr 28, 2020 at 07:03:00PM +0530, Rajendra Nayak wrote:
> Add support to add OPP tables and perf voting on the OPP powerdomain.
> This is needed so venus votes on the corresponding performance state
> for the OPP powerdomain along with setting the core clock rate.
>
> Signed-off-by: Rajend
On Tue, Apr 28, 2020 at 07:03:01PM +0530, Rajendra Nayak wrote:
> Add the OPP tables in order to be able to vote on the performance state of
> a power-domain.
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 40
> ++--
> 1 file cha
Hi,
On Tue, Apr 28, 2020 at 07:03:03PM +0530, Rajendra Nayak wrote:
> QSPI needs to vote on a performance state of a power domain depending on
> the clock rate. Add support for it by specifying the perf state/clock rate
> as an OPP table in device tree.
>
> Signed-off-by: Rajendra Nayak
> Cc: Ma
Hi,
On Tue, Apr 28, 2020 at 07:03:04PM +0530, Rajendra Nayak wrote:
> Add the power domain supporting performance state and the corresponding
> OPP tables for the qspi device on sdm845
>
> Signed-off-by: Rajendra Nayak
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 26 ++
On Wed, Apr 29, 2020 at 08:23:30PM +0530, Rajendra Nayak wrote:
>
> On 4/29/2020 7:45 PM, Rajendra Nayak wrote:
> >
> > On 4/29/2020 5:32 AM, Matthias Kaehlcke wrote:
> > > Hi Rajendra,
> > >
> > > On Tue, Apr 28, 2020 at 07:02:51PM +0530, Rajendra
Hi Felipe,
all patches of this series have been reviewed and there are no outstanding
comments, so I guess it should be ready to land?
Thanks
Matthias
On Wed, Apr 01, 2020 at 10:45:41AM +0530, Sandeep Maheswaram wrote:
> This path series aims to add interconnect support in
> dwc3-qcom driver on
Hi Sandeep,
This is a bit misleading/confusing. Patch "1/4] dt-bindings: phy: qcom,qmp:
Convert QMP PHY bindings to yaml" does the conversion to yaml AND removes
the binding for USB3 DP PHY, then this patch adds it again. Patches should
be self-contained and their commit messages shouldn't omit im
On Tue, Apr 28, 2020 at 07:36:12PM +0530, Sandeep Maheswaram wrote:
> Convert QMP PHY bindings to DT schema format using json-schema.
NACK (not sure if that carries any weight ;-)
v6 of this patch removes the binding of USB3 DP PHY during the conversion,
which is then added again as .yaml by "[2/
Hi Sandeep,
On Thu, Apr 23, 2020 at 10:14:36AM -0700, Matthias Kaehlcke wrote:
> Hi Sandeep,
>
> On Tue, Apr 14, 2020 at 02:21:17PM -0700, Stephen Boyd wrote:
> > Quoting Sandeep Maheswaram (2020-04-01 23:38:52)
> > > Convert QMP PHY bindings to DT schema
Hi Ulf,
On Tue, Oct 15, 2019 at 02:37:42PM +0200, Ulf Hansson wrote:
> On Tue, 1 Oct 2019 at 18:35, Matthias Kaehlcke wrote:
> >
> > On Fri, Sep 27, 2019 at 04:42:39AM -0400, Steven Rostedt wrote:
> > > On Thu, 26 Sep 2019 15:04:38 -0700
> > > Matthias Kaeh
On Wed, Oct 16, 2019 at 03:47:44PM +0200, Ulf Hansson wrote:
> On Tue, 15 Oct 2019 at 19:19, Matthias Kaehlcke wrote:
> >
> > Hi Ulf,
> >
> > On Tue, Oct 15, 2019 at 02:37:42PM +0200, Ulf Hansson wrote:
> > > On Tue, 1 Oct 2019 at 18:35, Matthias Kaehlcke w
On Thu, Oct 17, 2019 at 02:29:55PM -0700, Jeffrey Hugo wrote:
> On the msm8998 mtp, the response to the baudrate change command is never
> received. On the Lenovo Miix 630, the response to the baudrate change
> command is corrupted - "Frame reassembly failed (-84)".
>
> Adding a 50ms delay before
vregs.max_uV);
> - if (ret)
> - return ret;
> -
> return regulator_enable(regulator);
>
> }
> @@ -1401,7 +1392,6 @@ static void qca_disable_regulator(struct qca_vreg vregs,
> struct regulator *regulator)
> {
> regulator_disable(regulator);
> - regulator_set_voltage(regulator, 0, vregs.max_uV);
>
> }
This was brought up multiple times during the initial review, but
wasn't addressed.
Reviewed-by: Matthias Kaehlcke
On Fri, Oct 18, 2019 at 12:30:09PM -0600, Jeffrey Hugo wrote:
> On Fri, Oct 18, 2019 at 12:03 PM Matthias Kaehlcke wrote:
> >
> > On Thu, Oct 17, 2019 at 02:29:55PM -0700, Jeffrey Hugo wrote:
> > > On the msm8998 mtp, the response to the baudrate change command is never
On Fri, Oct 18, 2019 at 01:51:39PM -0600, Jeffrey Hugo wrote:
> On Fri, Oct 18, 2019 at 1:40 PM Matthias Kaehlcke wrote:
> >
> > On Fri, Oct 18, 2019 at 12:30:09PM -0600, Jeffrey Hugo wrote:
> > > On Fri, Oct 18, 2019 at 12:03 PM Matthias Kaehlcke
> > > wrot
On Fri, Oct 18, 2019 at 04:36:23PM -0600, Jeffrey Hugo wrote:
> On Fri, Oct 18, 2019 at 3:33 PM Matthias Kaehlcke wrote:
> >
> > On Fri, Oct 18, 2019 at 01:51:39PM -0600, Jeffrey Hugo wrote:
> > > On Fri, Oct 18, 2019 at 1:40 PM Matthias Kaehlcke
> > > wrot
On Sat, Oct 19, 2019 at 11:12:26AM -0700, Douglas Anderson wrote:
> This is commit fdfeff0f9e3d ("arm64: hw_breakpoint: Handle inexact
> watchpoint addresses") but ported to arm32, which has the same
> problem.
>
> This problem was found by Android CTS tests, notably the
> "watchpoint_imprecise" t
Hi Jeffrey,
On Sat, Oct 19, 2019 at 02:31:18PM -0600, Jeffrey Hugo wrote:
> On Fri, Oct 18, 2019 at 5:15 PM Matthias Kaehlcke wrote:
> >
> > On Fri, Oct 18, 2019 at 04:36:23PM -0600, Jeffrey Hugo wrote:
> > > On Fri, Oct 18, 2019 at 3:33 PM Matthias Kaehlcke
> > &
On Mon, Oct 21, 2019 at 09:19:21AM -0700, Jeffrey Hugo wrote:
> It turns out that the wcn3990 can float the gpio lines during bootup, etc
> which will result in the uart core thinking there is incoming data. This
> results in the bluetooth stack getting garbage. By applying a bias to
> match what
On Mon, Oct 21, 2019 at 02:28:46PM -0600, Jeffrey Hugo wrote:
> On Mon, Oct 21, 2019 at 1:58 PM Matthias Kaehlcke wrote:
> >
> > On Mon, Oct 21, 2019 at 09:19:21AM -0700, Jeffrey Hugo wrote:
> > > It turns out that the wcn3990 can float the gpio lines during bootup, etc
&g
Hi Rajendra,
I don't have all the hardware documentation for a full review, but
find a few comments inline.
On Mon, Oct 21, 2019 at 12:25:11PM +0530, Rajendra Nayak wrote:
> Add skeletal sc7180 SoC dtsi and idp board dts files.
>
> Co-developed-by: Taniya Das
> Signed-off-by: Taniya Das
> Sign
Hi Chanwoo,
On Thu, Feb 14, 2019 at 11:25:52PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> 2019년 2월 14일 (목) 오후 7:16, Matthias Kaehlcke 님이 작성:
> >
> > The field ->stop_polling indicates whether load monitoring should be/is
> > stopped, it is set in devfreq_monitor_
Hi Chanwoo,
On Thu, Feb 14, 2019 at 11:10:00PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> 2019년 2월 14일 (목) 오후 7:16, Matthias Kaehlcke 님이 작성:
> >
> > devfreq expects governors to call devfreq_monitor_suspend/resume()
> > in response to DEVFREQ_GOV_SUSPEND/RESUM
On Thu, Feb 14, 2019 at 11:12:55PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> Looks good to me for making the function to remove the duplicate code.
> But, When I just tested the kernel build, following warnings occur
> about devfreq_governor_stop().
>
> In file included from ./include/linux/
Hi Chanwoo,
On Thu, Feb 14, 2019 at 11:32:40PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> When I contributed the something to devfreq.c, if the newly added functions
> are internal/static, just added the function without 'devfreq_' prefix
> in order to distinguish them from the exported functi
Hi Lukasz,
On Thu, Feb 14, 2019 at 07:01:36PM +0100, Lukasz Luba wrote:
> Hi Matthias,
>
> I have compiled and run your changes on Odroid xu3 and v5.0-rc6.
> There are kernel warnings because of mutex not held in function
> devfreq_monitor_[start|stop]() in use cases:
> 1) a few times during re
Hi Chanwoo,
On Thu, Feb 14, 2019 at 11:17:36PM +0900, Chanwoo Choi wrote:
> Hi Matthias,
>
> As I commented on the first patch, it is not possible to call some codes
> according to the intention of each governor between 'devfreq_moniotr_*()'
> and some codes which are executed before or after 'de
801 - 900 of 1855 matches
Mail list logo