e are any
blocking issues, rather then making the effort to get a limited
version of the driver merged, and then learn that I wasted my own and
the reviewers time because it is a dead end.
> On 2018년 05월 26일 05:30, Matthias Kaehlcke wrote:
> > The purpose of the throttler is to provide supp
On Mon, May 28, 2018 at 10:08:26AM +0200, Greg Kroah-Hartman wrote:
> On Fri, May 25, 2018 at 01:30:41PM -0700, Matthias Kaehlcke wrote:
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index 20be70c3f118..01a1714dd2ad 100644
> > --- a/drivers/misc/Makefile
&
limitation is that devfreq currently doesn't have an
actual policy for frequencies and OPPs > freq might be disabled by a
devfreq cooling device (see drivers/thermal/devfreq_cooling.c).
Signed-off-by: Matthias Kaehlcke
---
Marked as RFC since I'm aware that this isn't quite a
nor->get_target_freq().
Signed-off-by: Matthias Kaehlcke
---
drivers/devfreq/governor_performance.c| 10 ++
drivers/devfreq/governor_powersave.c | 5 -
drivers/devfreq/governor_simpleondemand.c | 7 +--
drivers/devfreq/governor_userspace.c | 16
4
th the
OPP freqs and then the user limts min/max_freq with scaling_min/
max_freq.
Needless to say that this change is a NOP, intended to improve
readability.
Signed-off-by: Matthias Kaehlcke
---
Additional context: I'm considering to introduce the concept of
a devfreq policy, which would p
On Tue, Apr 24, 2018 at 01:54:29PM +0200, Sedat Dilek wrote:
> Hi Matthias,
>
> a big thank you for giving all the informations!
>
> I used your mka/llvm/v4.14_ext Git tree...
>
> https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/sandbox/mka/llvm/v4.14_ext
>
> ...and was able
On Thu, Apr 19, 2018 at 04:16:30PM -0600, Lina Iyer wrote:
> Sleep and wake requests are sent when the application processor
> subsystem of the SoC is entering deep sleep states like in suspend.
> These requests help lower the system power requirements when the
> resources are not in use.
>
> Slee
On Thu, Apr 19, 2018 at 04:16:31PM -0600, Lina Iyer wrote:
> Allow sleep and wake commands to be cleared from the respective TCSes,
> so that they can be re-populated.
>
> Signed-off-by: Lina Iyer
> ---
>
> Changes in v6:
> - remove unnecessary locks around __tcs_invalidate
> - renam
On Thu, Apr 19, 2018 at 04:16:34PM -0600, Lina Iyer wrote:
> Platform drivers need make a lot of resource state requests at the same
> time, say, at the start or end of an usecase. It can be quite
> inefficient to send each request separately. Instead they can give the
> RPMH library a batch of req
active state requests.
>
> The requirement for this is that the driver is aware that the wake TCS
> is being repurposed to send active request, hence the sleep and wake
> TCSes be invalidated before the active request is sent.
>
> Signed-off-by: Lina Iyer
Reviewed-by: Matthias Kaehlcke
The current 300ms delay after a baudrate change is extremely long.
For WCN3990 it is sufficient to wait 10ms after the baudrate change
request has been sent over the wire.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- moved wait for the request to be sent into the common code path
- s
On Wed, Apr 24, 2019 at 09:25:31AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the qcom tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> arch/arm/boot/dts/qcom-apq8064.dtsi:1297.29-1309.5: ERROR
> (phandle_references): /soc/dsi-phy@4700200: Reference
8064: Set 'xo_board' as ref clock of
the DSI PHY")
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 2f
The Mali GPU of the rk3288 can be used as cooling device, add
a #cooling-cells entry for it.
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index ca7d52daa8fb
e.
> > > Changed driver code to support WCN3998
> > >
> > > Signed-off-by: Harish Bandi
> > > Reviewed-by: Matthias Kaehlcke
> > > ---
> > > Changes in V7:
> > > - Initialized rom_ver to 0 to fix compiler warning
> > > ---
&g
Hi Rocky,
On Tue, Mar 12, 2019 at 05:01:59PM +0800, rjl...@codeaurora.org wrote:
> 在 2019-03-09 02:52，Matthias Kaehlcke 写道：
> > On Fri, Mar 08, 2019 at 10:43:14AM +0530, Balakrishna Godavarthi wrote:
> > > Hi Matthias,
> > >
> > > On 2019-03-08 02:12,
Hi Harish,
On Tue, Mar 12, 2019 at 05:52:58PM +0530, Harish Bandi wrote:
> Added new compatible for wcn3998 and corresponding voltage
> and current values to wcn3998 compatible.
> Changed driver code to support wcn3998
>
> Signed-off-by: Harish Bandi
> ---
> changes in v3:
> - updated to latest
+DT folks
Please add them in future versions (script/scripts/get_maintainer.pl
should have listed them)
On Tue, Mar 12, 2019 at 05:52:59PM +0530, Harish Bandi wrote:
> This patch enables regulators for the Qualcomm Bluetooth wcn3998
> controller.
No, it doesn't.
The next version should probabl
t or if data is lost by the UART.
This problem can be investigated separately, I'll send an updated
version of this patch soon.
Thanks
Matthias
On Wed, Mar 06, 2019 at 04:40:41PM -0800, Matthias Kaehlcke wrote:
> Firmware download to the WCN3990 often fails with a 'TL
Bluetooth: hci0: QCA TLV response size mismatch
[ 133.513265] Bluetooth: hci0: QCA Failed to download patch (-84)
This is caused by a vendor event 'without command' that is misinterpreted.
Drop the event.
Matthias Kaehlcke (2):
Bluetooth: hci_qca: Rename STATE_ to QCA_
Bluetooth: hc
another patch).
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- don't use BIT()
- change to enum type
- updated commit message
---
drivers/bluetooth/hci_qca.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/blue
the controller sends the corresponding
vendor event with the new baudrate. The event is received and decoded
after the baudrate change of the host port.
Identify the 'unused' event when it is received and don't add it to
the queue of RX frames.
Signed-off-by: Matthias
Rename the misspelled struct 'qca_bardrate' to 'qca_baudrate'
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/btqca.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
index c72c56ea7480..6fdc2
ky Liao
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/hci_qca.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4ea995d610d2..714a6a16f9d5 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/blue
On Wed, Mar 13, 2019 at 05:43:14PM +0800, rjl...@codeaurora.org wrote:
> 在 2019-03-12 23:52，Matthias Kaehlcke 写道：
> > Hi Rocky,
> >
> > On Tue, Mar 12, 2019 at 05:01:59PM +0800, rjl...@codeaurora.org wrote:
> > > 在 2019-03-09 02:52，Matthias Kaehlcke 写道：
> > &g
Hi Harish,
On Wed, Mar 13, 2019 at 12:00:06PM +0530, c-hba...@codeaurora.org wrote:
> Hi Matthias,
>
>
> On 2019-03-12 22:29, Matthias Kaehlcke wrote:
> > +DT folks
> >
> > Please add them in future versions (script/scripts/get_maintainer.pl
> > should hav
Hi Pi-Hsun,
On Thu, Jan 31, 2019 at 05:31:28PM +0800, Pi-Hsun Shih wrote:
> Add a simple rpmsg support for mt8183 SCP, that use IPI / IPC directly.
>
> Signed-off-by: Pi-Hsun Shih
> ---
> Changes from v3:
> - Change from unprepare to stop, to stop the rpmsg driver before the
>rproc is stopp
ld_index == new_index)
> return;
>
> + spin_lock(&cpufreq_stats_lock);
> cpufreq_stats_update(stats);
>
> stats->last_index = new_index;
> stats->trans_table[old_index * stats->max_state + new_index]++;
> stats->total_trans++;
> + spin_unlock(&cpufreq_stats_lock);
> }
Reviewed-by: Matthias Kaehlcke
Hi Lukasz,
On Fri, Feb 01, 2019 at 07:38:03PM +0100, Lukasz Luba wrote:
> This patch removes devfreq's custom workqueue and uses system one.
> It switches from queue_delayed_work() to schedule_delayed_work().
> It also changes deferred work to delayed work, which is now not missed
> when timer is
Try and register an Energy Model from qcom-cpufreq-hw to allow
interested sub-systems like the task scheduler to use the provided
information.
Signed-off-by: Matthias Kaehlcke
---
drivers/cpufreq/qcom-cpufreq-hw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/qcom
Try and register an Energy Model from mediatek-cpufreq to allow
interested subsystems like the task scheduler to use the provided
information.
Signed-off-by: Matthias Kaehlcke
---
drivers/cpufreq/mediatek-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/mediatek
Hi Quentin,
On Wed, Feb 06, 2019 at 10:13:18AM +, Quentin Perret wrote:
> Hi Matthias,
>
> On Tuesday 05 Feb 2019 at 09:52:25 (-0800), Matthias Kaehlcke wrote:
> > Try and register an Energy Model from mediatek-cpufreq to allow
> > interested subsystems like the task
Try and register an Energy Model from mediatek-cpufreq to allow
interested subsystems like the task scheduler to use the provided
information.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- register the EM after setting the cpumask
---
drivers/cpufreq/mediatek-cpufreq.c | 2 ++
1 file
On Wed, Feb 06, 2019 at 04:05:41PM +0530, Amit Kucheria wrote:
> On Sat, Jan 26, 2019 at 3:50 AM Matthias Kaehlcke wrote:
> > > > > trips {
> > > > > - cpu_alert0: trip0 {
> > > > > +
On Wed, Feb 06, 2019 at 11:34:41AM -0800, Matthias Kaehlcke wrote:
> On Wed, Feb 06, 2019 at 04:05:41PM +0530, Amit Kucheria wrote:
> > On Sat, Jan 26, 2019 at 3:50 AM Matthias Kaehlcke wrote:
> > > > > > trips {
> > > > > >
PU6
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU7
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + map1 {
> + trip = <&cpu6_alert1>;
> + cooling-device = <&CPU4
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU5
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU6
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU7
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> };
>
> cpu7-thermal {
> @@ -1838,18 +2008,41 @@
> thermal-sensors = <&tsens0 10>;
>
> trips {
> - cpu_alert7: trip0 {
> - temperature = <75000>;
> + cpu7_alert0: trip-point@0 {
> + temperature = <9>;
> hysteresis = <2000>;
> type = "passive";
> };
>
> - cpu_crit7: trip1 {
> + cpu7_alert1: trip-point@1 {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu7_crit: cpu_crit {
> temperature = <11>;
> hysteresis = <1000>;
> type = "critical";
> };
> };
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu7_alert0>;
> + cooling-device = <&CPU4
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU5
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU6
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU7
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + map1 {
> + trip = <&cpu7_alert1>;
> + cooling-device = <&CPU4
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU5
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU6
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
> + <&CPU7
> THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> };
> };
> };
Reviewed-by: Matthias Kaehlcke
Tested-by: Matthias Kaehlcke
Thanks
Matthias
On Thu, Jan 24, 2019 at 03:35:28PM -0800, Matthias Kaehlcke wrote:
> On Tue, Jan 22, 2019 at 06:12:51PM -0800, Matthias Kaehlcke wrote:
> > Hi Amit,
> >
> > On Mon, Jan 21, 2019 at 11:38:34PM +0530, Amit Kucheria wrote:
> > > Since all cpus in the big and little clus
On Mon, Jan 28, 2019 at 07:19:56PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-01-25 06:44, Matthias Kaehlcke wrote:
> > On Thu, Jan 24, 2019 at 05:38:06PM +0530, Balakrishna Godavarthi wrote:
> > > wcn3990 requires a power pulse to turn ON/OFF alo
ndex == new_index)
> return;
>
> - spin_lock(&cpufreq_stats_lock);
> + spin_lock(&stats->lock);
> cpufreq_stats_update(stats);
>
> stats->last_index = new_index;
> stats->trans_table[old_index * stats->max_state + new_index]++;
> stats->total_trans++;
> - spin_unlock(&cpufreq_stats_lock);
> + spin_unlock(&stats->lock);
> }
Reviewed-by: Matthias Kaehlcke
sizeof(struct qca_power),
> GFP_KERNEL);
> @@ -1489,7 +1500,7 @@ static void qca_serdev_remove(struct serdev_device
> *serdev)
> {
> struct qca_serdev *qcadev = serdev_device_get_drvdata(serdev);
>
> - if (qcadev->btsoc_type == QCA_WCN3990)
> + if (qca_is_wcn399x(qcadev->btsoc_type))
> qca_power_shutdown(&qcadev->serdev_hu);
> else
> clk_disable_unprepare(qcadev->susclk);
> @@ -1499,7 +1510,8 @@ static void qca_serdev_remove(struct serdev_device
> *serdev)
>
> static const struct of_device_id qca_bluetooth_of_match[] = {
> { .compatible = "qcom,qca6174-bt" },
> - { .compatible = "qcom,wcn3990-bt", .data = &qca_soc_data},
> + { .compatible = "qcom,wcn3990-bt", .data = &qca_soc_data_wcn3990},
> + { .compatible = "qcom,wcn3998-bt", .data = &qca_soc_data_wcn3998},
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, qca_bluetooth_of_match);
Besides the return value in the qca_is_wcn399x() stub:
Reviewed-by: Matthias Kaehlcke
On Mon, Mar 25, 2019 at 05:00:31PM +0530, c-hba...@codeaurora.org wrote:
> Hi Matthias,
>
> On 2019-03-15 00:26, Matthias Kaehlcke wrote:
> > Hi Harish,
> >
> > On Wed, Mar 13, 2019 at 12:00:06PM +0530, c-hba...@codeaurora.org wrote:
> > > Hi Matthias,
>
On Fri, Mar 22, 2019 at 08:45:26AM -0400, Gaël PORTAY wrote:
> Hi Matthias,
>
> On Thu, Mar 21, 2019 at 05:01:07PM -0700, Matthias Kaehlcke wrote:
> > > ...
> > >
> > > So, for a reason that I ignore, if we try to save unecessary calls to
> > > ROCKCH
->bt_power = devm_kzalloc(&serdev->dev,
> sizeof(struct qca_power),
> GFP_KERNEL);
> @@ -1489,7 +1500,7 @@ static void qca_serdev_remove(struct serdev_device
> *serdev)
> {
> struc
On Wed, Mar 27, 2019 at 03:53:58PM +0530, Harish Bandi wrote:
> Hi Matthias,
>
> > > > > > You mentioned in an earlier version of the series that there are
> > > > > > multiple WCN3998 variants with different requirements for
> > > > > > voltage/current. This seems to suggests that multiple compat
On Wed, Mar 27, 2019 at 05:58:43PM +0530, Harish Bandi wrote:
> This patch enables regulators for the Qualcomm Bluetooth WCN3998
> controller.
I commented on this on v3, but you didn't update it:
No, it doesn't.
The next version should probably say something like "Add compatible
string for
On Mon, Apr 01, 2019 at 01:48:23PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-04-01 13:29, Balakrishna Godavarthi wrote:
> > Hi Matthias,
> >
> > Sorry for the late reply i was on vacation.
> >
> > On 2019-03-08 05:00, Matthias Kaehlc
On Mon, Apr 01, 2019 at 01:16:07PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-03-13 02:12, Matthias Kaehlcke wrote:
> > Rename STATE_IN_BAND_SLEEP_ENABLED to QCA_IN_BAND_SLEEP_ENABLED.
> > The constant represents a flag (multiple flags can be set at on
Hi Marcel,
do you have any comments or can this fix be landed?
Thanks
Matthias
On Wed, Mar 13, 2019 at 04:52:19PM -0700, Matthias Kaehlcke wrote:
> qca_set_baudrate() calls serdev_device_wait_until_sent() assuming that
> the HCI is always associated with a serdev device. This isn'
On Tue, Apr 02, 2019 at 05:32:54PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-04-01 22:42, Matthias Kaehlcke wrote:
> > On Mon, Apr 01, 2019 at 01:48:23PM +0530, Balakrishna Godavarthi wrote:
> > > Hi Matthias,
> > >
> > > On 2019
Hi Doug,
On Tue, Apr 02, 2019 at 03:44:44PM -0700, Douglas Anderson wrote:
> The software running on the Chrome OS Embedded Controller (cros_ec)
> handles SPI transfers in a bit of a wonky way. Specifically if the EC
> sees too long of a delay in a SPI transfer it will give up and the
> transfer
On Tue, Apr 02, 2019 at 04:38:29PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Apr 2, 2019 at 4:19 PM Matthias Kaehlcke wrote:
> >
> > Hi Doug,
> >
> > On Tue, Apr 02, 2019 at 03:44:44PM -0700, Douglas Anderson wrote:
> > > The software running on
ds/chromeos-4.19
I found some problems during initialization easier to reproduce
when binding and unbinding the device through sysfs, instead of
doing hciconfig up/down, this resembles more the initialization at
boot time.
> On 2019-04-02 23:35, Matthias Kaehlcke wrote:
> > On Tue, Apr 02
On Tue, Apr 02, 2019 at 11:05:01AM -0700, Matthias Kaehlcke wrote:
> On Tue, Apr 02, 2019 at 05:32:54PM +0530, Balakrishna Godavarthi wrote:
> > Hi Matthias,
> >
> > On 2019-04-01 22:42, Matthias Kaehlcke wrote:
> > > On Mon, Apr 01, 2019 at 01:48:23PM +0530
On Tue, Apr 02, 2019 at 08:17:03PM -0700, Guenter Roeck wrote:
> On Tue, Apr 2, 2019 at 4:38 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Apr 2, 2019 at 4:19 PM Matthias Kaehlcke wrote:
> > >
> > > Hi Doug,
> > >
> > > O
On Wed, Apr 03, 2019 at 10:04:16AM -0700, Brian Norris wrote:
> I know some of this was hashed out last night, but I wasn't reading my
> email then to interject ;)
>
> On Wed, Apr 3, 2019 at 9:05 AM Douglas Anderson wrote:
> > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> > +
On Wed, Apr 03, 2019 at 11:17:27AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 3, 2019 at 11:14 AM Matthias Kaehlcke wrote:
> > Each transfer has it's own work struct (allocated on the stack), hence
> > a) does not occur. b) is still true, but shouldn
* the transfer.
> + */
> + queue_work(system_highpri_wq, ¶ms.work);
> + flush_work(¶ms.work);
> +
> + return params.ret;
> +}
> +
> +static int cros_ec_pkt_xfer_spi(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *ec_msg)
> +{
> + return cros_ec_xfer_high_pri(ec_dev, ec_msg, do_cros_ec_pkt_xfer_spi);
> +}
> +
> +static int cros_ec_cmd_xfer_spi(struct cros_ec_device *ec_dev,
> + struct cros_ec_command *ec_msg)
> +{
> + return cros_ec_xfer_high_pri(ec_dev, ec_msg, do_cros_ec_cmd_xfer_spi);
> +}
> +
> static void cros_ec_spi_dt_probe(struct cros_ec_spi *ec_spi, struct device
> *dev)
> {
> struct device_node *np = dev->of_node;
Reviewed-by: Matthias Kaehlcke
On Wed, Apr 03, 2019 at 02:08:40PM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 3, 2019 at 2:04 PM Matthias Kaehlcke wrote:
> > > +static int cros_ec_xfer_high_pri(struct cros_ec_device *ec_dev,
> >
> > nit: the fact that a high priority workqueue is used i
On Thu, Apr 04, 2019 at 08:22:15PM +0530, Balakrishna Godavarthi wrote:
> Hi Matthias,
>
> On 2019-04-03 21:44, Matthias Kaehlcke wrote:
> > On Wed, Apr 03, 2019 at 11:53:26AM +0530, Balakrishna Godavarthi wrote:
> > > + Harish to update his findings on wcn3998.
> >
Add GPIO D5 (BT_ENABLE_L) as reset-GPIO to the power sequence for the
Bluetooth/WiFi module. On devices with a Broadcom module the signal
needs to be asserted to use Bluetooth.
Note that BT_ENABLE_L is a misnomer in the schematics, the signal
actually is active-high.
Signed-off-by: Matthias
. After a successful initiatalization the clk
is running at the desired speed (48MHz).
Remove the unnecessary clock rate configuration from the DT.
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts
There are only two types of power pulses 'on' or 'off', pass a boolean
instead of the power pulse 'command'.
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/hci_qca.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers
initialization failed
[ 25.337740] Bluetooth: hci0: Reading QCA version information failed (-110)
After a power-off pulse wait 10ms to give the controller time to power
off.
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/hci_qca.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a
After sending a power on pulse the driver has a delay of 100ms
to allow the host controller to boot. Move the delay into
qca_send_power_pulse(), since it is directly related with the
power-on pulse.
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/hci_qca.c | 6 +++---
1 file changed, 3
instead of a power pulse
command, this improves readability of the function with the delays
added.
Matthias Kaehlcke (3):
Bluetooth: hci_qca: Pass boolean 'on/off' to qca_send_power_pulse()
Bluetooth: hci_qca: Move boot delay to qca_send_power_pulse()
Bluetooth: hci_qca: Add d
Hi,
On Wed, Feb 20, 2019 at 03:43:02PM -0800, Matthias Kaehlcke wrote:
> Hi Balakrishna,
>
> On Wed, Feb 20, 2019 at 04:55:16PM +0530, Balakrishna Godavarthi wrote:
> > This patch will update the baudrate change request wait time from
> > 300 ms to 100 ms. When host send
Hi Balakrishna,
Thanks for the reviews!
On Tue, Feb 26, 2019 at 05:54:24PM +0530, Balakrishna Godavarthi wrote:
> hi Matthias,
>
> On 2019-02-26 17:48, Balakrishna Godavarthi wrote:
> > On 2019-02-26 05:19, Matthias Kaehlcke wrote:
> > > After sending a power on pulse t
After sending a power on pulse the driver has a delay of 100ms
to allow the host controller to boot. Move the delay into
qca_send_power_pulse(), since it is directly related with the
power-on pulse.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
---
Changes in v2:
- added
There are only two types of power pulses 'on' or 'off', pass a boolean
instead of the power pulse 'command'.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Balakrishna Godavarthi
---
Changes in v2:
- added 'Reviewed-by: Balakrishna Godavarthi '
instead of a power pulse
command, this improves readability of the function with the delays
added.
Matthias Kaehlcke (3):
Bluetooth: hci_qca: Pass boolean 'on/off' to qca_send_power_pulse()
Bluetooth: hci_qca: Move boot delay to qca_send_power_pulse()
Bluetooth: hci_qca: Add d
initialization failed
[ 25.337740] Bluetooth: hci0: Reading QCA version information failed (-110)
After a power-off pulse wait 10ms to give the controller time to power
off. Remove the previous short settling delay, it isn't needed anymore.
Signed-off-by: Matthias Kaehlcke
Review
The current 300ms delay after a baudrate change is extremely long.
For WCM3990 it is sufficient to wait 10ms after the baudrate change
request has been sent over the wire.
Also use msleep() instead of a set_current_state() / schedule_timeout()
combo.
Matthias Kaehlcke (2):
hci_qca: Use msleep
Call msleep() in qca_set_baudrate() instead of reimplementing it.
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/hci_qca.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 26efc2ef98d9a..703e099515f24
The current 300ms delay after a baudrate change is extremely long.
For WCM3990 it is sufficient to wait 10ms after the baudrate change
request has been sent over the wire.
Signed-off-by: Matthias Kaehlcke
---
drivers/bluetooth/hci_qca.c | 28 +---
1 file changed, 21
On Tue, Feb 26, 2019 at 12:08:48PM -0800, Matthias Kaehlcke wrote:
> The current 300ms delay after a baudrate change is extremely long.
> For WCM3990 it is sufficient to wait 10ms after the baudrate change
> request has been sent over the wire.
>
> Signed-off-by: Ma
wire.
> >
> > Also use msleep() instead of a set_current_state() / schedule_timeout()
> > combo.
> >
> > Matthias Kaehlcke (2):
> > hci_qca: Use msleep() instead of open coding it
> > hci_qca: Reduce delay after sending baud
Hi Greg,
On Thu, Feb 11, 2021 at 08:03:01AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2021 at 09:10:37AM -0800, Matthias Kaehlcke wrote:
> > +static int onboard_hub_add_usbdev(struct onboard_hub *hub, struct
> > usb_device *udev)
> > +{
> > + struct ud
Hi Greg,
On Thu, Feb 11, 2021 at 07:58:23AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > Check during probe() if a hub supported by the onboard_usb_hub
> > driver is connected to the controller. If such a hub is found
On Thu, Feb 11, 2021 at 10:45:48AM -0800, Matthias Kaehlcke wrote:
> Hi Greg,
>
> On Thu, Feb 11, 2021 at 07:58:23AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > > Check during probe() if a hub supporte
Hi Stephen,
On Thu, Feb 11, 2021 at 11:14:39AM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2021-02-10 14:20:18)
> >
> > On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> > >
> > > This looks hackish... what if later we have somet
On Mon, Feb 22, 2021 at 12:20:04PM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2021-02-19 18:10:59)
> > Lazor rev3 and older are stuffed with a 47k NTC as thermistor for
> > the charger temperature which currently isn't supported by the
> > PM6150 ADC driver.
On Mon, Feb 22, 2021 at 03:20:53PM -0800, Doug Anderson wrote:
> Hi,
>
> On Fri, Feb 19, 2021 at 6:11 PM Matthias Kaehlcke wrote:
> >
> > Lazor rev3 and older are stuffed with a 47k NTC thermistor for the
> > charger temperature which currently isn't supported
ping
I noticed this was never picked up, can it be landed or are there any
concerns with this patch?
On Tue, Sep 15, 2020 at 06:50:32PM -0500, Bjorn Andersson wrote:
> On Tue 15 Sep 14:31 CDT 2020, Matthias Kaehlcke wrote:
>
> > The dwc3-qcom currently enables wakeup interrupts unc
On Tue, Feb 23, 2021 at 02:12:30PM +0300, Dmitry Baryshkov wrote:
> Hi,
>
> On Sat, 20 Feb 2021 at 05:13, Matthias Kaehlcke wrote:
> >
> > Lazor rev3 and older are stuffed with a 47k NTC as thermistor for
> > the charger temperature which currently isn't suppor
On Mon, Feb 22, 2021 at 12:45:23PM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2021-02-22 12:38:46)
> > On Mon, Feb 22, 2021 at 12:20:04PM -0800, Stephen Boyd wrote:
> > > Quoting Matthias Kaehlcke (2021-02-19 18:10:59)
> > > > Lazor rev3 and older
d to leave the hub powered when a wakeup capable USB device
is connected when suspending, and power it off otherwise.
(no changes since v1)
Matthias Kaehlcke (4):
dt-bindings: usb: Add binding for discrete onboard USB hubs
USB: misc: Add onboard_usb_hub driver
usb: host: xhci-plat: Creat
Discrete onboard USB hubs (an example for such a hub is the Realtek
RTS5411) need to be powered and may require initialization of other
resources (like GPIOs or clocks) to work properly. This adds a device
tree binding for these hubs.
Signed-off-by: Matthias Kaehlcke
---
Changes in v5
evice is
needed. The relationship could be established through a phandle
in the node of the USB device(s).
Co-developed-by: Ravi Chandra Sadineni
Signed-off-by: Ravi Chandra Sadineni
Signed-off-by: Matthias Kaehlcke
---
Changes in v5:
- the platform device is now instantiated from the same DT node
). Further the
platform device is only created when CONFIG_USB_ONBOARD_HUB=y/m.
Signed-off-by: Matthias Kaehlcke
---
Changes in v5:
- patch added to the series
drivers/usb/host/xhci-plat.c | 16
include/linux/usb/hcd.h | 2 ++
2 files changed, 18 insertions(+)
diff --git a
Add nodes for the onboard USB hub on trogdor devices. Remove the
'always-on' and 'boot-on' properties from the hub regulator, since
the regulator is now managed by the onboard_usb_hub driver.
Signed-off-by: Matthias Kaehlcke
---
Changes in v5:
- patch added to the series
Hi Krzysztof,
On Wed, Feb 10, 2021 at 10:06:45PM +0100, Krzysztof Kozlowski wrote:
> On Wed, Feb 10, 2021 at 09:10:38AM -0800, Matthias Kaehlcke wrote:
> > Check during probe() if a hub supported by the onboard_usb_hub
> > driver is connected to the controller. If such a hub is f
Hi Krzysztof,
On Wed, Feb 10, 2021 at 10:04:51PM +0100, Krzysztof Kozlowski wrote:
> On Wed, Feb 10, 2021 at 09:10:35AM -0800, Matthias Kaehlcke wrote:
> > This series adds the onboard_usb_hub_driver, the corresponding
> > device tree bindings and creation of onboard_usb_hub plat
Hi Rob,
thanks for your review!
On Wed, Feb 17, 2021 at 03:04:41PM -0600, Rob Herring wrote:
> On Wed, Feb 10, 2021 at 09:10:36AM -0800, Matthias Kaehlcke wrote:
> > Discrete onboard USB hubs (an example for such a hub is the Realtek
> > RTS5411) need to be powered and may require
Lazor is stuffed with a 47k NTC as thermistor for the charger
temperature which currently isn't supported by the PM6150 ADC
driver. Disable the charger thermal zone to avoid the use of
bogus temperature values.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- disable the thermal
The trip point configuration of the charger thermal zone for trogdor
is missing a node for the critical trip point. Add the missing node.
Fixes: bb06eb3607e9 ("arm64: qcom: sc7180: trogdor: Add ADC nodes and thermal
zone for charger thermistor")
Signed-off-by: Matthias Kaehlcke
---
ff-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v2:
- only add a label to the thermal zone
- updated subject and commit message
arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/s
that all trogdor boards have
the charger thermistor it makes more sense to use channel 0,
and then let boards with other thermistors use channels 1, 2, 3,
rather than 0, 2, 3.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- patch added to the series
arch/arm64/boot/dts/qcom/sc7180
> Subject: [PATCH v2 2/4] arm64: dts: qcom: sc7180: Disable charger thermal for
> lazor
Should be 'Disable charger thermal *zone* for lazor'
Maybe Bjorn can fix this when applying if no respin is needed.
On Thu, Feb 25, 2021 at 10:33:35AM -0800, Matthias Kaehlcke wrote:
> La
..@codeaurora.org
>
> arch/arm64/boot/dts/qcom/sc7180-trogdor.dtsi | 24
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 18 ---
> 2 files changed, 24 insertions(+), 18 deletions(-)
Reviewed-by: Matthias Kaehlcke
e new boards have device trees yet, this change
> looks silly on its own but it will make sense after more boards are
> supported.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
601 - 700 of 1855 matches
Mail list logo
