video generation") and T3
("delay from LCDVDD to HPD high"), which aren't related to the
PWM. The backlight power sequence does not specify min/max
constraints for T15 (time from PWM on to BL enable) or T16
(time from BL disable to PWM off).
Signed-off-by: Matthias Kaehlcke
---
E
\
> - return ret ? ret : count; \
> + ret = dev_pm_qos_update_request(policy->object##_freq_req, val);\
> + return ret && ret != 1 ? ret : count; \
nit: I wonder if
return (ret >= 0) ? count : ret;
would be clearer.
Other than that:
Reviewed-by: Matthias Kaehlcke
Hi Viresh,
On Mon, Jun 10, 2019 at 04:21:35PM +0530, Viresh Kumar wrote:
> This registers the notifiers for min/max frequency constraints with the
> PM QoS framework. The constraints are also taken into consideration in
> cpufreq_set_policy().
>
> This also relocates cpufreq_policy_put_kobj() as
For backlight curves calculated with the CIE 1931 algorithm set
the brightness scale type property accordingly. This makes the
scale type available to userspace via the 'scale' sysfs attribute.
Signed-off-by: Matthias Kaehlcke
---
drivers/video/backlight/pwm_bl.c | 5 -
1 file changed, 4
r.
Export the type of the brightness curve via a new sysfs attribute.
Matthias Kaehlcke (4):
MAINTAINERS: Add entry for stable backlight sysfs ABI documentation
backlight: Expose brightness curve type through sysfs
backlight: pwm_bl: Set scale type for CIE 1931 curves
backlight: pwm_bl: Set
of the
emitted light. If userspace doesn't know about 'cie-1931' or
'perceptual' it should at least be able to interpret the 'non-linear'
part.
For devices that don't provide information about the scale of their
brightness curve the value of the 'scale' attribute is 'unknown'.
Signed-off-by: Matthias Ka
Add an entry for the stable backlight sysfs ABI to the MAINTAINERS
file.
Signed-off-by: Matthias Kaehlcke
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 57f496cff999..d51e74340870 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2857,6 +2857,7
On Wed, Jun 12, 2019 at 08:47:57PM +0100, Daniel Thompson wrote:
> On Wed, Jun 12, 2019 at 12:26:42PM -0700, Matthias Kaehlcke wrote:
> > Hi Daniel,
> >
> > On Wed, Jun 12, 2019 at 12:03:25PM +0100, Daniel Thompson wrote:
> > > On Tue, Jun 11, 2019 at 03:30:19PM
the context of the
existing code (particularly looking at DEV_PM_QOS_RESUME_LATENCY)
this looks reasonable to me. FWIW:
Reviewed-by: Matthias Kaehlcke
Hi Daniel,
On Wed, Jun 12, 2019 at 12:03:25PM +0100, Daniel Thompson wrote:
> On Tue, Jun 11, 2019 at 03:30:19PM -0700, Matthias Kaehlcke wrote:
> > On Tue, Jun 11, 2019 at 09:55:30AM -0700, Brian Norris wrote:
> > > On Tue, Jun 11, 2019 at 3:49 AM Daniel Tho
me.c | 2 +-
> drivers/cpuidle/governor.c | 2 +-
> include/linux/pm_qos.h | 41 +---
> 6 files changed, 40 insertions(+), 21 deletions(-)
looks good to me, however I'm just a QoS n00b:
Reviewed-by: Matthias Kaehlcke
--
> include/linux/pm_qos.h | 12
> 4 files changed, 31 insertions(+), 13 deletions(-)
My QoS background is nil, but this looks reasonable to me:
Reviewed-by: Matthias Kaehlcke
On Tue, Jun 11, 2019 at 09:55:30AM -0700, Brian Norris wrote:
> On Tue, Jun 11, 2019 at 3:49 AM Daniel Thompson
> wrote:
> > This is a long standing flaw in the backlight interfaces. AFAIK generic
> > userspaces end up with a (flawed) heuristic.
>
> Bingo! Would be nice if we could start to fix
Hi Daniel,
On Tue, Jun 11, 2019 at 04:33:14PM +0100, Daniel Thompson wrote:
> On Mon, Jun 10, 2019 at 04:37:39PM -0700, Matthias Kaehlcke wrote:
> > Commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> > linearly to human eye") uses pwm_peri
From: Doug Anderson
This enables wake up on Bluetooth activity when the device is
suspended. The BT_HOST_WAKE signal is only connected on devices
with BT module that are connected through UART.
Signed-off-by: Douglas Anderson
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- attributed
On Mon, Jun 10, 2019 at 11:02:27PM +0200, Enric Balletbo i Serra wrote:
> Hi Matthias,
>
> On 10/6/19 22:39, Matthias Kaehlcke wrote:
> > Hi Enric
> >
> > On Mon, Jun 10, 2019 at 12:00:02PM +0200, Enric Balletbo i Serra wrote:
> >> Hi Matthias,
> >
Hi Pavel,
On Sat, Jun 08, 2019 at 11:02:26PM +0200, Pavel Machek wrote:
> Hi!
>
> > > + * Note that this method is based on empirical testing on different
> > > + * devices with PWM of 8 and 16 bits of resolution.
> > > + */
> > > + n = period;
> > > + while (n) {
> > > + counter += n
Hi Enric
On Mon, Jun 10, 2019 at 12:00:02PM +0200, Enric Balletbo i Serra wrote:
> Hi Matthias,
>
> On 8/6/19 23:02, Pavel Machek wrote:
> > Hi!
> >
> >>> + * Note that this method is based on empirical testing on different
> >>> + * devices with PWM of 8 and 16 bits of resolution.
> >>> +
Hi Enric,
some comments inline, a bit late, but I just tested this on veyron
minnie.
On Thu, Feb 08, 2018 at 12:30:31PM +0100, Enric Balletbo i Serra wrote:
> When you want to change the brightness using a PWM signal, one thing you
> need to consider is how human perceive the brightness. Human
On Thu, Jun 06, 2019 at 12:46:03PM +0200, Heiko Stuebner wrote:
> Am Mittwoch, 5. Juni 2019, 23:52:00 CEST schrieb Heiko Stübner:
> > Am Mittwoch, 5. Juni 2019, 23:24:27 CEST schrieb Matthias Kaehlcke:
> > > On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
>
On Wed, Jun 05, 2019 at 11:11:12PM +0200, Heiko Stübner wrote:
> Am Mittwoch, 5. Juni 2019, 22:43:20 CEST schrieb Matthias Kaehlcke:
> > This enables wake up on Bluetooth activity when the device is
> > suspended. The BT_HOST_WAKE signal is only connected on devices
>
With a single device DT overrides can become messy, especially when
keys are added or removed. Multiple devices also allow to
enable/disable wakeup per key/group.
Signed-off-by: Matthias Kaehlcke
---
.../boot/dts/rk3288-veyron-chromebook.dtsi| 26 +++--
arch/arm/boot/dts/rk3288
This enables wake up on Bluetooth activity when the device is
suspended. The BT_HOST_WAKE signal is only connected on devices
with BT module that are connected through UART.
Signed-off-by: Douglas Anderson
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 29
_maxpacket() which in turn called usb_endpoint_maxp().
>
> Let's update dwc2 to work properly with the new API.
>
> Fixes: abb621844f6a ("usb: ch9: make usb_endpoint_maxp() return only packet
> size")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Douglas Anderson
On Thu, May 30, 2019 at 02:27:28PM +0800, Hsin-Yi Wang wrote:
> On Fri, May 10, 2019 at 9:27 PM michael.kao wrote:
>
> > +
> > + tzts1: tzts1 {
> > + polling-delay-passive = <0>;
> > + polling-delay = <0>;
> > +
error
message logs on the console during firmware download. Now we are
injecting a command complete event once we receive an vendor specific
event for the last RAM firmware packet.
Signed-off-by: Balakrishna Godavarthi
Tested-by: Matthias Kaehlcke
Reviewed-by: Matthias Kaehlcke
Signed-off
t recent schematics?) and dealing with the fact that one of
> the two boards has full sized SD.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
The comment of trace_filter_add_remove_task() refers to the function as
'trace_pid_filter_add_remove_task', use the correct name.
Signed-off-by: Matthias Kaehlcke
---
kernel/trace/trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/trace.c b/kernel/trace
On Tue, May 21, 2019 at 01:32:15PM -0700, Douglas Anderson wrote:
> This is like the same change for rk3288-veyron-minnie. See that patch
> for more details.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
gt; It's expected that other rk3288-veyron boards will get similar patches
> shortly.
>
> NOTE: I have sorted the "gpio" section to be next to the "pinctrl"
> section since it seems to logically make the most sense there.
>
> Signed-off-by: Douglas Anderson
Reviewed-by: Matthias Kaehlcke
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 Kaehlcke
---
Changes in v4:
- limit the fix
On Mon, Apr 29, 2019 at 04:21:31PM -0700, Matthias Kaehlcke wrote:
> Firmware download to the WCN3990 often fails with a 'TLV response size
> mismatch' error:
>
> [ 133.064659] Bluetooth: hci0: setting up wcn3990
> [ 133.489150] Bluetooth: hci0: QCA controller version 0x02140201
ure, hence we cap the CPU
frequency to 1.4 GHz for temperatures above 65°C. Further throttling
of the CPUs may be performed by the CPU thermal zone.
The configuration matches that of the downstream Chrome OS 3.14
kernel, the 'official' kernel for mickey.
Signed-off-by: Matthias Kaehlcke
---
Chan
in case someone decides to
re-purpose NPLL.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- patch added to the series
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch/arm/boot/dts/rk3288
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- added 'cpu_warm_limit_gpu' to throttle GPU for T.cpu >= 65°C
- removed comment saying that GPU isn't throttled beyond 400 MHz
based on CPU temperature
- updated commit message
Note: this patch depends on "ARM: dts: rockchip: Add #cooli
On Mon, May 20, 2019 at 01:21:33PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, May 20, 2019 at 10:01 AM Matthias Kaehlcke wrote:
> >
> > mickey crams a lot of hardware into a tiny package, which requires
> > more aggressive thermal throttling than for devices
On Mon, May 20, 2019 at 01:16:46PM -0700, Doug Anderson wrote:
> Hi,
>
> On Mon, May 20, 2019 at 10:01 AM Matthias Kaehlcke wrote:
> >
> > On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU
> > frequency on veyron mickey to 300 MHz f
On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU
frequency on veyron mickey to 300 MHz for CPU temperatures >= 85°C.
This matches the configuration of the downstream Chrome OS 3.14 kernel,
the 'official' kernel for mickey.
Signed-off-by: Matthias Kaehlcke
---
N
ure, hence we cap the CPU
frequency to 1.4 GHz for temperatures above 65°C. Further throttling
of the CPUs may be performed by the CPU thermal zone.
The configuration matches that of the downstram Chrome OS 3.14
kernel, the 'official' kernel for mickey.
Signed-off-by: Matthias Kaehlcke
---
N
Midgard GPU as cooling device for the GPU
thermal zone instead of the CPUs.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- patch added to the series
---
arch/arm/boot/dts/rk3288.dtsi | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b
The Mali GPU of the rk3288 can be used as cooling device, add
a #cooling-cells entry for it.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v2:
- added Doug's 'Reviewed-by' tag
---
arch/arm/boot/dts/rk3288.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git
Raise the temperature of the GPU thermal trip point for speedy
to 80°C. This is the value used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for speedy.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- add entry at position in alphabetical order
---
arch/arm/boot/dts
The values match thorse used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for veyron devices. Keep the critical
trip point for speedy at 90°C as in the downstream configuration.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- also raise temperature of critical trip point
and gives the system a chance
to shut down orderly at the criticial trip point.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- patch added to the series
---
arch/arm/boot/dts/rk3288-veyron-speedy.dts | 4
arch/arm/boot/dts/rk3288-veyron.dtsi | 5 +
2 files changed, 9 insertions
On Wed, May 15, 2019 at 11:30:12AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 15, 2019 at 8:31 AM Matthias Kaehlcke wrote:
>
> > Raise the temperature of the GPU thermal trip point for speedy
> > to 80°C. This is the value used by the downstream Chrome OS 3.14
&
Hi Doug,
thanks for the review!
On Wed, May 15, 2019 at 11:30:24AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 15, 2019 at 8:31 AM Matthias Kaehlcke wrote:
>
> > This value matches what is used by the downstream Chrome OS 3.14
> > kernel, the 'official' k
This value matches what is used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for veyron devices.
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288-veyron.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-veyron.dtsi
b/arch
Raise the temperature of the GPU thermal trip point for speedy
to 80°C. This is the value used by the downstream Chrome OS 3.14
kernel, the 'official' kernel for speedy.
Signed-off-by: Matthias Kaehlcke
---
arch/arm/boot/dts/rk3288-veyron-speedy.dts | 4
1 file changed, 4 insertions
quot;;
> - clocks = < HCLK_I2S0>, < SCLK_I2S0>, < SCLK_I2S0_OUT>;
> };
>
> {
effectively, 'i2s_clk_out' is not use in the upstream kernel.
Reviewed-by: Matthias Kaehlcke
ers/mmc/core/queue.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
> index 7c364a9c4eeb..09071e13282e 100644
> --- a/drivers/mmc/core/queue.c
> +++ b/drivers/mmc/core/queue.c
> @@ -480,6 +480,8 @@ void mmc_cleanup_queue(struct mmc_queue *mq)
>*/
> flush_work(>complete_work);
>
> + blk_mq_free_tag_set(>tag_set);
> +
> mq->card = NULL;
> }
>
FWIW:
Reviewed-by: Matthias Kaehlcke
Hi,
On Fri, May 03, 2019 at 04:03:58PM +0800, Hsin-Yi Wang wrote:
> On Thu, May 2, 2019 at 10:43 AM michael.kao wrote:
> >
> > Add thermal zone node to Mediatek MT8183 dts file.
> >
> > Signed-off-by: Michael Kao
> > ---
> > arch/arm64/boot/dts/mediatek/mt8183.dtsi | 64
> >
cpufreq_get_requested_power() was entered, there seems little gain
from omitting the assignment if the tracepoint was just disabled, so
just remove the check.
Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator
governor")
Signed-off-by: Matthias Kaehlcke
---
drive
if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Matthias-Kaehlcke/Bluetooth-btqca-inject-command-complete-event-during-fw-download/20190430-125407
> base:
> https://git.ker
On Mon, Apr 29, 2019 at 05:10:24PM -0700, Matthias Kaehlcke wrote:
> From: Balakrishna Godavarthi
>
> From: Balakrishna Godavarthi
>
> Latest qualcomm chips are not sending an command complete event for
> every firmware packet sent to chip. They only respond with a vendo
to this we are seeing a timeout error
message logs on the console during firmware download. Now we are
injecting a command complete event once we receive an vendor specific
event for the last RAM firmware packet.
Signed-off-by: Balakrishna Godavarthi
Tested-by: Matthias Kaehlcke
Reviewed
On Mon, Apr 29, 2019 at 04:21:31PM -0700, Matthias Kaehlcke wrote:
> Firmware download to the WCN3990 often fails with a 'TLV response size
> mismatch' error:
>
> [ 133.064659] Bluetooth: hci0: setting up wcn3990
> [ 133.489150] Bluetooth: hci0: QCA controller version 0x02140201
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 Kaehlcke
---
Changes in v3:
- rebased on latest
patch).
Signed-off-by: Matthias Kaehlcke
---
Changes in v3:
- rename STATE_IN_BAND_SLEEP_ENABLED to QCA_IBS_ENABLED
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
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
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
ock 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 2fff5074f2d7..65975df6a8c3 100644
--- a/ar
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:
ao
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Rocky Liao
Tested-by: Rocky Liao
Reviewed-by: Balakrishna Godavarthi
---
Changes in v2:
- first version got corrupted for some reason, this should apply
- added 'Reviewed-by' tags from Rocky abd Balakrishna
- added 'Tested-by' tag from Rocky
--
gt; >
> > Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm
> > Bluetooth chip wcn3990")
> > Reported-by: Balakrishna Godavarthi
> > Reported-by: Rocky Liao
> > Signed-off-by: Matthias Kaehlcke
> > ---
> > drivers/bluetooth/hc
On Fri, Apr 12, 2019 at 11:30:37AM +0200, Heiko Stübner wrote:
> Am Freitag, 12. April 2019, 02:16:57 CEST schrieb Matthias Kaehlcke:
> > Hi Heiko,
> >
> > On Thu, Apr 11, 2019 at 09:03:07PM +0200, Heiko Stübner wrote:
> > > Hi Matthias,
> > >
> > &
Hi Heiko,
On Thu, Apr 11, 2019 at 09:03:07PM +0200, Heiko Stübner wrote:
> Hi Matthias,
>
> Am Donnerstag, 11. April 2019, 19:59:17 CEST schrieb Matthias Kaehlcke:
> > The USB PHY clock can be configured as (grand) parent of uart0_sclk and
> > sclk_gpu. It has been observ
85
1608000 13501156394
Signed-off-by: Matthias Kaehlcke
---
I couldn't find any really comprehensive information on determining
the dynamic-power-coefficient, the method used is my understanding
mostly derived from the sources mentioned above, the resulting value
of the PHY clock with a '.' in the non-USB muxes to
effectively remove the clock as input from these muxes.
Signed-off-by: Matthias Kaehlcke
---
drivers/clk/rockchip/clk-rk3288.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk
. 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
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
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.
> &
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
arams.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 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't be a p
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 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 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
romeos-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, 201
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
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 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 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 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
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 Kae
rdesc->n_voltages--;
> - continue;
> - }
indeed, the 'continue' is pointless here. I guess at some stage of
development something else was done in the loop and this is a
leftover.
Reviewed-by: Matthias Kaehlcke
On Fri, Mar 29, 2019 at 05:05:49AM +0800, kbuild test robot wrote:
> Hi Harish,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on bluetooth-next/master]
> [also build test WARNING on next-20190328]
> [cannot apply to v5.1-rc2]
> [if your patch is applied
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
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
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
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
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,
>
truct 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(>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 = _soc_data},
> + { .compatible = "qcom,wcn3990-bt", .data = _soc_data_wcn3990},
> + { .compatible = "qcom,wcn3998-bt", .data = _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
, _attr_group);
> @@ -242,11 +243,11 @@ void cpufreq_stats_record_transition(struct
> cpufreq_policy *policy,
> if (old_index == -1 || new_index == -1 || old_index == new_index)
> return;
>
> - spin_lock(_stats_lock);
> + spin_lock(>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(_stats_lock);
> + spin_unlock(>lock);
> }
Reviewed-by: Matthias Kaehlcke
Hi Marcel,
do you have any comments on this change?
Without this firmware download on wcn3990 (and probably also wcn3998)
is broken, unfortunately fixing the ROM firmware is not an option :(
Thanks
Matthias
On Wed, Mar 06, 2019 at 04:40:41PM -0800, Matthias Kaehlcke wrote:
> Firmware downl
On Mon, Mar 25, 2019 at 05:06:40PM +0530, Harish Bandi wrote:
> This patch enables regulators for the Qualcomm Bluetooth WCN3998
> controller.
>
> Signed-off-by: Harish Bandi
> ---
> Changes in V4:
> - Removed new compatible WCN3998
> - changed wcn3990 to wcn399* to represent wcn399* family
>
On Mon, Mar 25, 2019 at 05:06:39PM +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 V4:
> - Added
Hi Gaël,
On Thu, Mar 21, 2019 at 07:10:55PM -0400, Gaël PORTAY wrote:
> Matthias,
>
> On Wed, Mar 20, 2019 at 03:02:23PM -0700, Matthias Kaehlcke wrote:
> > Hi Gaël,
> >
> > On Wed, Mar 20, 2019 at 05:50:13PM -0400, Gaël PORTAY wrote:
> > > Hi Matthias,
>
#size-cells = <0>;
>
> pinctrl-names = "default";
> pinctrl-0 = <_key_l>;
Reviewed-by: Matthias Kaehlcke
#address-cells = <1>;
> - #size-cells = <0>;
> status = "disabled";
>
> ports {
Reviewed-by: Matthias Kaehlcke
= /bits/ 64 <5>;
> opp-microvolt = <120>;
> };
> - opp@6 {
> + opp-6 {
> opp-hz = /bits/ 64 <6>;
> opp-microvolt = <125>;
> };
Reviewed-by: Matthias Kaehlcke
501 - 600 of 2887 matches
Mail list logo
