("Bluetooth: hci_qca: add PM support")
> Signed-off-by: Zijun Hu
Reviewed-by: Matthias Kaehlcke
On Fri, May 29, 2020 at 03:42:54AM +0800, Zijun Hu wrote:
>
>
> On 5/28/2020 11:17 PM, Matthias Kaehlcke wrote:
> > On Thu, May 28, 2020 at 07:03:17PM +0800, Zijun Hu wrote:
> >> Controller ID info got by VSC EDL_PATCH_GETVER is very
> >> important, so improve
Hi Zijun,
On Thu, May 28, 2020 at 06:38:22PM +0800, Zijun Hu wrote:
> @dev parameter of qca_suspend()/qca_resume() represents
> serdev_device, but it is mistook for hci_dev and causes
> succedent unexpected memory access.
>
> Fix by taking @dev as serdev_device.
>
> Signed-off-by: Zijun Hu
Ple
On Thu, May 28, 2020 at 01:04:25PM +0800, Zijun Hu wrote:
>
>
> On 5/28/2020 12:48 AM, Matthias Kaehlcke wrote:
> > Hi Zijun,
> >
> > On Wed, May 27, 2020 at 10:32:39AM +0800, Zijun Hu wrote:
> >> Warm reboot can not restore qca6390 controller bau
tial changes.
Reviewed-by: Matthias Kaehlcke
Hi Zijun,
On Wed, May 27, 2020 at 10:32:39AM +0800, Zijun Hu wrote:
> Warm reboot can not restore qca6390 controller baudrate
> to default due to lack of controllable BT_EN pin or power
> supply, so fails to download firmware after warm reboot.
>
> Fixed by sending EDL_SOC_RESET VSC to reset cont
rsion:0x%08x",
> + le16_to_cpu(ver->patch_ver));
>
> /* QCA chipset version can be decided by patch and SoC
>* version, combination with upper 2 bytes from SoC
Reviewed-by: Matthias Kaehlcke
// assuming this is a variant of the SoC
ROM version
Patch version // assuming this is a patch of the ROM firmware (?)
Sorry if I got any of the concepts wrong, from the names they are not entirely
clear to me.
In any case it's just a suggestion, feel free to ignore.
Reviewed-by: Matthias Kaehlcke
On Tue, May 26, 2020 at 10:57:30AM +0800, Zijun Hu wrote:
> Warm reboot can not restore qca6390 controller baudrate
> to default due to lack of controllable BT_EN pin or power
> supply, so fails to download firmware after warm reboot.
>
> Fixed by sending EDL_SOC_RESET VSC to reset controller
> wi
On Fri, May 15, 2020 at 08:09:16AM +0530, Sandeep Maheswaram wrote:
> Subject: dt-bindings: phy: qcom,qmp-usb3-dp: Add dt bindings for USB3 DP PHY
The subject is misleading, this patch doesn't add the binding for the USB3 DP
PHY, but factors it out.
On Fri, May 15, 2020 at 08:09:15AM +0530, Sandeep Maheswaram wrote:
> Convert QMP PHY bindings to DT schema format using json-schema.
>
> Signed-off-by: Sandeep Maheswaram
This is essentially the same as v5, for which got a 'Reviewed-by' tag
from Rob:
diff --git a/Documentation/devicetree/bindi
On Thu, May 14, 2020 at 04:24:18PM +0530, Sharat Masetty wrote:
> This patches replaces the previously used static DDR vote and uses
> dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
> GPU frequency.
>
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu
On Thu, May 14, 2020 at 05:39:57PM -0700, Matthias Kaehlcke wrote:
> On Thu, May 14, 2020 at 04:24:17PM +0530, Sharat Masetty wrote:
> > This patch changes the plumbing to send the devfreq recommended opp rather
> > than the frequency. Also consolidate and rearrange the code in a6xx
On Thu, May 14, 2020 at 04:24:17PM +0530, Sharat Masetty wrote:
> This patch changes the plumbing to send the devfreq recommended opp rather
> than the frequency. Also consolidate and rearrange the code in a6xx to set
> the GPU frequency and the icc vote in preparation for the upcoming
> changes fo
On Thu, May 14, 2020 at 04:24:16PM +0530, Sharat Masetty wrote:
> From: Sibi Sankar
>
> Add and export 'dev_pm_opp_set_bw' to set the bandwidth
> levels associated with an OPP for a given frequency.
Wait, this looks very much like Sibi's patch from v4 of the "DDR/L3
Scaling support on SDM845 and
On Thu, May 14, 2020 at 04:24:13PM +0530, Sharat Masetty wrote:
> Subject: [PATCH 0/6] Add support for GPU DDR BW scaling
For anything but the first version the subject (for all patches) should
include the version (i.e. [v2, 0/6], etc for this series).
> This is a rework of my previous series [1
p-level =
> ;
> + opp-peak-kBps = <3072000>;
> };
ditto
> opp-18000 {
> opp-hz = /bits/ 64 <18000>;
> opp-level =
> ;
> + opp-peak-kBps = <1804000>;
> };
> };
> };
assuming the repeated bandwidths are indeed intentional:
Reviewed-by: Matthias Kaehlcke
Hi Sharat,
On Thu, May 14, 2020 at 04:24:14PM +0530, Sharat Masetty wrote:
> Subject: arm64: dts: qcom: sc7180: Add interconnect bindings for GPU
>
> This patch adds the interconnect bindings to the GPU node. This enables
> the GPU->DDR path bandwidth voting.
This patch doesn't add any bindings,
2 @@ static int qca_serdev_probe(struct serdev_device
> *serdev)
> hdev->shutdown = qca_power_off;
> }
>
> + /* Wideband speech support must be set per driver since it can't be
> + * queried via hci.
> + */
> + if (data && (data->capabilities & QCA_CAP_WIDEBAND_SPEECH_SUPPORTED))
> + set_bit(HCI_QUIRK_WIDEBAND_SPEECH_SUPPORTED, &hdev->quirks);
> +
> return 0;
> }
Reviewed-by: Matthias Kaehlcke
On Thu, May 14, 2020 at 02:30:28PM +0300, Felipe Balbi wrote:
> Felipe Balbi writes:
>
> > Hi,
> >
> > Sandeep Maheswaram writes:
> >> +static int dwc3_qcom_interconnect_init(struct dwc3_qcom *qcom)
> >> +{
> >> + struct device *dev = qcom->dev;
> >> + int ret;
> >> +
> >> + if (!device_is_bo
Hi Abhishek,
On Wed, May 13, 2020 at 08:41:25PM -0700, Abhishek Pandit-Subedi wrote:
> WCN3991 supports transparent WBS (host encoded mSBC). Add a flag to the
> device match data to show WBS is supported.
In general this looks good to me, a few nits inside.
> This requires the matching firmware
m_get_drvdata(pdev);
> + struct qcom_qspi *ctrl = spi_master_get_devdata(master);
>
> /* Unregister _before_ disabling pm_runtime() so we stop transfers */
> spi_unregister_master(master);
>
> pm_runtime_disable(&pdev->dev);
> + if (ctrl->has_opp_table)
> + dev_pm_opp_of_remove_table(&pdev->dev);
> + dev_pm_opp_put_clkname(ctrl->opp_table);
> +
>
remove 2nd empty line.
Maybe this can be done when the patch is applied if there are no other reasons
to respin the series?
Reviewed-by: Matthias Kaehlcke
_link_del(core->pd_dl_venus);
> + for (i = 0; i < res->vcodec_pmdomains_num; i++) {
> + if (IS_ERR_OR_NULL(core->pmdomains[i]))
> + continue;
> + dev_pm_domain_detach(core->pmdomains[i], true);
> + }
> + }
> + return ret;
> }
>
> static void vcodec_domains_put(struct device *dev)
> @@ -773,7 +810,7 @@ static void vcodec_domains_put(struct device *dev)
> unsigned int i;
>
> if (!res->vcodec_pmdomains_num)
> - return;
> + goto skip_pmdomains;
>
> if (core->pd_dl_venus)
> device_link_del(core->pd_dl_venus);
> @@ -783,6 +820,15 @@ static void vcodec_domains_put(struct device *dev)
> continue;
> dev_pm_domain_detach(core->pmdomains[i], true);
> }
> +
> +skip_pmdomains:
> + if (!res->opp_pmdomain)
> + return;
> +
> + if (core->opp_dl_venus)
> + device_link_del(core->opp_dl_venus);
> +
> + dev_pm_domain_detach(core->opp_pmdomain, true);
> }
>
> static int core_get_v4(struct device *dev)
Reviewed-by: Matthias Kaehlcke
escription
or help to resolve the constraints issue.
Regards
Matthias
On Fri, May 08, 2020 at 11:52:52AM +0530, Sandeep Maheswaram (Temp) wrote:
> Hi Rob,
>
> Any suggestions to solve this error in assigned-clock-rates
>
>
> Regards
> Sandeep
>
> On 4/24/2020 1:0
Hi Georgi,
On Tue, May 12, 2020 at 03:53:25PM +0300, Georgi Djakov wrote:
> Currently when we check for the available resources, we assume that there
> is only one interconnect path, but in fact it could be more than one. Do
> some validation to determine the number of paths and verify if each one
_find_icc_paths(struct opp_table *opp_table, struct device *dev);
> #else
> static inline void _of_init_opp_table(struct opp_table *opp_table, struct
> device *dev, int index) {}
> static inline void _of_clear_opp_table(struct opp_table *opp_table) {}
> static inline struct opp_table *_managed_opp(struct device *dev, int index)
> { return NULL; }
> static inline void _of_opp_free_required_opps(struct opp_table *opp_table,
> struct dev_pm_opp *opp) {}
> +static inline int _of_find_icc_paths(struct opp_table *opp_table, struct
> device *dev) { return 0; }
> #endif
>
> #ifdef CONFIG_DEBUG_FS
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index 747861816f4f..cfceb0290401 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -41,6 +41,18 @@ struct dev_pm_opp_supply {
> unsigned long u_amp;
> };
>
> +/**
> + * struct dev_pm_opp_icc_bw - Interconnect bandwidth values
> + * @avg: Average bandwidth corresponding to this OPP (in icc units)
> + * @peak:Peak bandwidth corresponding to this OPP (in icc units)
> + *
> + * This structure stores the bandwidth values for a single interconnect path.
> + */
> +struct dev_pm_opp_icc_bw {
> + u32 avg;
> + u32 peak;
> +};
> +
> /**
> * struct dev_pm_opp_info - OPP freq/voltage/current values
> * @rate:Target clk rate in hz
Reviewed-by: Matthias Kaehlcke
uct device *dev, const char *name);
> void icc_put(struct icc_path *path);
> +int icc_disable(struct icc_path *path);
> +int icc_enable(struct icc_path *path);
> int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw);
> void icc_set_tag(struct icc_path *path, u32 tag);
>
> @@ -57,6 +59,16 @@ static inline void icc_put(struct icc_path *path)
> {
> }
>
> +static inline int icc_disable(struct icc_path *path)
> +{
> + return 0;
> +}
> +
> +static inline int icc_enable(struct icc_path *path)
> +{
> + return 0;
> +}
> +
> static inline int icc_set_bw(struct icc_path *path, u32 avg_bw, u32 peak_bw)
> {
> return 0;
Reviewed-by: Matthias Kaehlcke
On Fri, Feb 14, 2020 at 10:49:37AM -0800, Matthias Kaehlcke wrote:
> On Tue, Feb 11, 2020 at 05:07:35PM +0530, Harigovindan P wrote:
>
> > subject: arm64: dts: sc7180: add dsi controller and phy entries for idp dts
>
> nit: 'dts' at the end is redundant, the prefixes
Hi Rajendra,
On Sun, May 03, 2020 at 05:34:28PM +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-
Hi Rajendra,
On Sun, May 03, 2020 at 05:34:29PM +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
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
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,
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
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
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,
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 ++
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
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
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: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
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
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
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
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
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
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:
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
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
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
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
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 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
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 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 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
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 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
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
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
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 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 +
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
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
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
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 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 "
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
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:
> >
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,
> >
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
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
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
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
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
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.
>
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 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
>
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
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
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
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
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
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_
sdio_irq_nolock(host, true);
> + sdhci_enable_sdio_irq_nolock(host, true);
> spin_unlock_irqrestore(&host->lock, flags);
> }
FWIW:
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
mmc_card_set_suspended(host->card);
> cancel_delayed_work_sync(&host->sdio_irq_work);
Reviewed-by: Matthias Kaehlcke
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
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
&
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 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
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
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 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
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 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
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 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:
> > >
301 - 400 of 1310 matches
Mail list logo
