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. However for
> 'calibbias' channels the function returns directly, without releasing
> the lock. The next
Hi,
On Fri, Jul 12, 2019 at 4:50 AM Greg KH wrote:
>
> On Thu, Jul 11, 2019 at 10:28:01AM -0700, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Jul 11, 2019 at 10:26 AM Greg KH wrote:
> > >
> > > On Thu, Jul 11, 2019 at 02:17:26PM -0300, Jason Gunthorpe
Hi,
On Thu, Jul 11, 2019 at 12:43 PM Jarkko Sakkinen
wrote:
>
> On Thu, Jul 11, 2019 at 09:35:33PM +0300, Jarkko Sakkinen wrote:
> > > Careful with this, you can't backport this to any kernels that don't
> > > have the sysfs ops locking changes or they will crash in sysfs code.
> >
> > Oops, I
Hi,
On Thu, Jul 11, 2019 at 10:26 AM Greg KH wrote:
>
> On Thu, Jul 11, 2019 at 02:17:26PM -0300, Jason Gunthorpe wrote:
> > On Thu, Jul 11, 2019 at 07:04:37PM +0200, Greg KH wrote:
> > > On Thu, Jul 11, 2019 at 01:39:15PM -0300, Jason Gunthorpe wrote:
> > > > On Thu, Jul 11, 2019 at 09:29:19AM
Hi,
On Thu, Jul 11, 2019 at 9:39 AM Jason Gunthorpe wrote:
>
> On Thu, Jul 11, 2019 at 09:29:19AM -0700, Douglas Anderson wrote:
> > From: Vadim Sukhomlinov
> >
> > commit db4d8cb9c9f2af71c4d087817160d866ed572cc9 upstream.
> >
> > TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM chip and
Hi,
On Tue, Jul 9, 2019 at 3:02 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jul 9, 2019 at 9:38 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Jul 9, 2019 at 2:07 AM Krzysztof Kozlowski wrote:
> > >
> > > On Tu
Hi,
On Tue, Jul 9, 2019 at 9:38 AM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Jul 9, 2019 at 2:07 AM Krzysztof Kozlowski wrote:
> >
> > On Tue, 9 Jul 2019 at 00:48, Douglas Anderson wrote:
> > >
> > > In commit 46d179525a1f ("mmc: dw_mmc: Wait for
Hi,
On Tue, Jul 9, 2019 at 2:07 AM Krzysztof Kozlowski wrote:
>
> On Tue, 9 Jul 2019 at 00:48, Douglas Anderson wrote:
> >
> > In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after
> > response errors.") we fixed a tuning-induced hang that I saw when
> > stress testing tuning on
Hi,
On Thu, Jun 20, 2019 at 1:31 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Jun 20, 2019 at 11:21 AM Douglas Anderson
> wrote:
> >
> > This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
> >
> > This 100 ms mystery delay is not on downstream
Hi,
On Mon, Jun 24, 2019 at 3:53 PM Gwendal Grignou wrote:
>
> -static int read_ec_accel_data(struct cros_ec_accel_legacy_state *st,
> - unsigned long scan_mask, s16 *data)
> +int cros_ec_accel_legacy_read_cmd(struct iio_dev *indio_dev,
> +
Hi,
On Wed, Jun 26, 2019 at 6:00 AM Sam Ravnborg wrote:
>
> Hi Douglas.
>
> On Mon, Apr 01, 2019 at 10:17:17AM -0700, Douglas Anderson wrote:
> > I'm reviving Sean Paul's old patchset to get mode support in device
> > tree. The cover letter for his v3 is at:
> >
Hi,
On Thu, Jun 20, 2019 at 7:41 PM Gwendal Grignou wrote:
>
> To allow cros_ec iio core library to be used with legacy device, add a
> vector to rotate sensor data if necessary: legacy devices are not
> reporting data in HTML5/Android sensor referential.
>
> On veyron minnie, check chrome
Hi,
On Thu, Jun 13, 2019 at 8:28 AM Marc Gonzalez wrote:
>
> readl_poll_timeout() calls usleep_range() to sleep between reads.
> usleep_range() doesn't work efficiently for tiny values.
>
> Raise the polling delay in qcom_qmp_phy_enable() to bring it in line
> with the delay in
Hi,
On Thu, Jun 20, 2019 at 11:53 AM Gwendal Grignou wrote:
>
> To allow cros_ec iio core library to be used with legacy device, add a
> vector to rotate sensor data if necessary: legacy devices are not
> reporting data in HTML5/Android sensor referential.
>
> TEST=On veyron minnie, check chrome
Hi,
On Thu, Jun 20, 2019 at 8:37 AM Ulf Hansson wrote:
>
> + Doug
>
> On Thu, 20 Jun 2019 at 17:24, Lubomir Rintel wrote:
> >
> > If there's a mmc* alias in the device tree, take the device number from
> > it, so that we end up with a device name that matches the alias.
>
> Lots of people would
Hi,
On Thu, Jun 20, 2019 at 1:25 PM Nick Desaulniers
wrote:
>
> On Thu, Jun 20, 2019 at 1:13 PM Doug Anderson wrote:
> > On Thu, Jun 20, 2019 at 12:53 PM Nick Desaulniers
> > wrote:
> > >
> > > I do miss Doug's Kbuild caching patches' speedup.
Hi,
On Thu, Jun 20, 2019 at 11:21 AM Douglas Anderson wrote:
>
> This reverts commit 1f45e8c6d0161f044d679f242fe7514e2625af4a.
>
> This 100 ms mystery delay is not on downstream kernels and no longer
> seems needed on upstream kernels either [1]. Presumably something in the
> meantime has made
Hi,
On Thu, Jun 20, 2019 at 12:53 PM Nick Desaulniers
wrote:
>
> I do miss Doug's Kbuild caching patches' speedup.
You actually get quite a bit of this by grabbing a new version of
ccache (assuming you use ccache). :-P You still have to pay the
penalty (twice) for all the options that are
Hi,
On Wed, Fri, 18 Mar 2016 Heiko Stuebner wrote:
>
> The panels need a bit of time to actually turn on. If this isn't
> observed, this results in problems when trying talk to the panels
> and thus produces detection errors. 100ms seem to be a safe value
> for the time being.
>
> Signed-off-by:
Hi,
On Tue, Jun 18, 2019 at 2:14 PM Matthias Kaehlcke wrote:
>
> empty_child_inc/dec() use the ternary operator for conditional
> operations. The conditions involve the post/pre in/decrement
> operator and the operation is only performed when the condition
> is *not* true. This is hard to parse
Hi,
On Mon, Jun 17, 2019 at 11:39 AM Ulf Hansson wrote:
>
> On Mon, 17 Jun 2019 at 19:57, Douglas Anderson wrote:
> >
> > This series attempts to deal better with the expected transmission
> > errors related to the idle states (handled by the Always-On-Subsystem
> > or AOS) on the SDIO-based
Hi,
On Fri, Jun 14, 2019 at 5:04 AM Ulf Hansson wrote:
>
> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson wrote:
> >
> > Normally when the MMC core sees an "-EILSEQ" error returned by a host
> > controller then it will trigger a retuning of the card. This is
> > generally a good idea.
> >
> >
Hi,
On Fri, Jun 14, 2019 at 5:10 AM Ulf Hansson wrote:
>
> On Fri, 14 Jun 2019 at 01:42, Douglas Anderson wrote:
> >
> > We want SDIO drivers to be able to temporarily stop retuning when the
> > driver knows that the SDIO card is not in a state where retuning will
> > work (maybe because the
Hi,
On Thu, Jun 13, 2019 at 9:37 AM Marc Gonzalez wrote:
>
> On 13/06/2019 18:11, Doug Anderson wrote:
>
> > On Thu, Jun 13, 2019 at 9:04 AM Marc Gonzalez wrote:
> >
> >> Hmmm, I expect the typical use-case to be:
> >> "HW manual states oper
Hi,
On Thu, Jun 13, 2019 at 9:04 AM Marc Gonzalez wrote:
>
> On 13/06/2019 14:42, Arnd Bergmann wrote:
>
> > On Thu, Jun 13, 2019 at 2:16 PM Marc Gonzalez wrote:
> >
> >> Chopping max delay in 4 seems excessive. Let's just cut it in half.
> >>
> >> Signed-off-by: Marc Gonzalez
> >> ---
> >>
Hi,
On Thu, Jun 13, 2019 at 6:59 AM Jarkko Sakkinen
wrote:
>
> On Wed, Jun 12, 2019 at 10:16:18PM +0300, Jarkko Sakkinen wrote:
> > On Mon, Jun 10, 2019 at 03:01:18PM -0700, Douglas Anderson wrote:
> > > From: Vadim Sukhomlinov
> > >
> > > TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM
Hi,
On Mon, Jun 10, 2019 at 1:56 AM Hunter, Adrian wrote:
>
> > --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
>
> SDIO function
Hi,
On Fri, Jun 7, 2019 at 6:32 AM Arend Van Spriel
wrote:
>
> On June 7, 2019 2:40:04 PM Adrian Hunter wrote:
>
> > On 7/06/19 8:12 AM, Arend Van Spriel wrote:
> >> On June 6, 2019 11:37:22 PM Doug Anderson wrote:
> >>>
> >>> In the case of dw_
Hi,
On Fri, Jun 7, 2019 at 5:29 AM Adrian Hunter wrote:
>
> >> @@ -711,8 +720,16 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool
> >> on)
> >> err_cnt = 0;
> >> }
> >> /* bail out upon subsequent access errors */
> >> -
Hi,
On Sun, Feb 3, 2019 at 5:50 AM Ben Hutchings wrote:
>
> 3.16.63-rc1 review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Nadav Amit
>
> commit 89dd34caf73e28018c58cd193751e41b1f8bdc56 upstream.
>
> The use of ALIGN() in uvc_alloc_entity() is
Hi,
On Thu, Jun 6, 2019 at 10:56 AM Matthias Kaehlcke wrote:
>
> 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,
Hi,
On Wed, Jun 5, 2019 at 1:43 PM Matthias Kaehlcke wrote:
>
> 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:
Hi,
On Thu, Jun 6, 2019 at 7:00 AM Adrian Hunter wrote:
>
> On 3/06/19 9:37 PM, Douglas Anderson wrote:
> > There are certain cases, notably when transitioning between sleep and
> > active state, when Broadcom SDIO WiFi cards will produce errors on the
> > SDIO bus. This is evident from the
Hi,
On Wed, Jun 5, 2019 at 12:54 AM Arend Van Spriel
wrote:
>
> On 6/3/2019 8:37 PM, Douglas Anderson wrote:
> > Normally when the MMC core sees an "-EILSEQ" error returned by a host
> > controller then it will trigger a retuning of the card. This is
> > generally a good idea.
> >
> > However,
Hi,
On Tue, Jun 4, 2019 at 3:37 PM Bjorn Andersson
wrote:
>
> On Tue 04 Jun 15:29 PDT 2019, Stephen Boyd wrote:
>
> > The SMMU that sits in front of the QUP needs to be programmed properly
> > so that the i2c geni driver can allocate DMA descriptors. Failure to do
> > this leads to faults when
Hi,
On Mon, Jun 3, 2019 at 8:20 PM Wright Feng wrote:
>
> On 2019/5/29 上午 12:11, Arend Van Spriel wrote:
> > On May 28, 2019 6:09:21 PM Arend Van Spriel
> > wrote:
> >
> >> On May 28, 2019 5:52:10 PM Doug Anderson wrote:
> >>
> >>> Hi,
Ulf,
On Tue, May 28, 2019 at 3:49 PM Doug Anderson wrote:
>
> > 1) As kind of stated above, did you consider a solution where the core
> > simply disables the SDIO IRQ in case it isn't enabled for system
> > wakeup? In this way all host drivers would benefit.
>
> I ca
Hi,
On Mon, Jun 3, 2019 at 8:22 AM Doug Anderson wrote:
> > Can someone in Rockchip try to find the root-cause of the issue? Keeping the
> > PHY off shouldn't increase power draw.
>
> It sounded like Chris already answered this, though? Basically things
Doh! Don't know why
Kishon,
On Mon, Jun 3, 2019 at 4:22 AM Kishon Vijay Abraham I wrote:
>
> Hi,
>
> On 20/05/19 1:34 PM, Caesar Wang wrote:
> > Hi Doug,
> >
> > For now, nobody of rockchip is responsible for this driver.
> > Cc: Nickey, Zain, Hjc
> >
> >
> > On 5/8/19 7:48 AM, Douglas Anderson wrote:
> >> While
Hi,
On Fri, May 31, 2019 at 5:09 PM Bjorn Andersson
wrote:
>
> On Fri 31 May 15:24 PDT 2019, Doug Anderson wrote:
>
> > Hi,
> >
> > On Thu, May 30, 2019 at 8:01 PM Bjorn Andersson
> > wrote:
> > >
> > > +/**
> > > + * qmp_sen
Hi,
On Thu, May 30, 2019 at 8:01 PM Bjorn Andersson
wrote:
>
> +/**
> + * qmp_send() - send a message to the AOSS
> + * @qmp: qmp context
> + * @data: message to be sent
> + * @len: length of the message
> + *
> + * Transmit @data to AOSS and wait for the AOSS to acknowledge the message.
> + *
Hi,
On Fri, May 31, 2019 at 1:59 PM Evan Green wrote:
>
> The manpage for modprobe mentions that dashes and underscores are
> treated interchangeably in module names. The stack trace dumps seem
> to print module names with underscores. Use bash to replace _ with
> the pattern [-_] so that file
Hi,
On Wed, May 29, 2019 at 1:54 PM Guenter Roeck wrote:
>
> This reverts commit b0d659022e5c96ee5c4bd62d22d3da2d66de306b.
>
> The reverted commit does nothing but adding two unnecessary lines
> of code. It sets a local variable to NULL in two functions, but
> that variable is not used anywhere
Hi,
On Sun, Feb 17, 2019 at 10:37 PM Martin Schiller wrote:
>
> Insert a padding between data and the stored_xfer_buffer pointer to
> ensure they are not on the same cache line.
>
> Otherwise, the stored_xfer_buffer gets corrupted for IN URBs on
> non-cache-coherent systems. (In my case: Lantiq
Hi,
On Tue, May 28, 2019 at 12:22 PM Ulf Hansson wrote:
>
> On Mon, 29 Apr 2019 at 22:41, Douglas Anderson wrote:
> >
> > Processing SDIO interrupts while dw_mmc is suspended (or partly
> > suspended) seems like a bad idea. We really don't want to be
> > processing them until we've gotten
Hi,
On Tue, May 28, 2019 at 5:18 AM Kalle Valo wrote:
>
> Douglas Anderson wrote:
>
> > In commit 29f6589140a1 ("brcmfmac: disable command decode in
> > sdio_aos") we disabled something called "command decode in sdio_aos"
> > for a whole bunch of Broadcom SDIO WiFi parts.
> >
> > After that
Hi,
On Tue, May 28, 2019 at 4:45 AM Adrian Hunter wrote:
>
> On 28/05/19 2:21 PM, Arend Van Spriel wrote:
> >
> >
> > On 5/28/2019 12:04 PM, Adrian Hunter wrote:
> >> On 26/05/19 9:42 PM, Arend Van Spriel wrote:
> >>> On 5/18/2019 12:54 AM, Douglas Anderson wrote:
> Normally when the MMC
Hi,
On Tue, May 28, 2019 at 6:12 AM Ulf Hansson wrote:
>
> On Mon, 20 May 2019 at 20:41, Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, Apr 29, 2019 at 1:41 PM Douglas Anderson
> > wrote:
> > >
> > > Processing SDIO interrupts while dw_m
Hi,
On Thu, May 23, 2019 at 11:05 AM Stephen Boyd wrote:
>
> Quoting Doug Anderson (2019-05-23 09:38:13)
> > Hi,
> >
> > On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
> > wrote:
> >
> > > +static int qmp_qdss_clk_add(struct qmp *qmp)
> >
Hi,
On Tue, Apr 30, 2019 at 9:38 PM Bjorn Andersson
wrote:
>
> +static int qmp_qdss_clk_prepare(struct clk_hw *hw)
> +{
> + struct qmp *qmp = container_of(hw, struct qmp, qdss_clk);
> + char buf[QMP_MSG_LEN] = "{class: clock, res: qdss, val: 1}";
nit: "static const" the buf? No
Hi,
On Tue, Apr 30, 2019 at 9:37 PM Bjorn Andersson
wrote:
>
> The AOSS QMP provides a number of power domains, used for QDSS and
> PIL, add the node for this.
>
> Tested-by: Sibi Sankar
> Reviewed-by: Sibi Sankar
> Signed-off-by: Bjorn Andersson
> ---
>
> Changes since v6:
> - Added
Hi,
On Wed, May 22, 2019 at 2:14 AM Heiko Stuebner wrote:
>
> Am Dienstag, 21. Mai 2019, 00:00:49 CEST schrieb Matthias Kaehlcke:
> > The NPLL is the only safe way to generate 500 MHz for the GPU. The
> > downstream Chrome OS 3.14 kernel ('official' kernel for veyron
> > devices) re-purposes
Hi,
On Wed, May 22, 2019 at 7:12 AM Heiko Stuebner wrote:
>
> This reverts commit 28694e009e512451ead5519dd801f9869acb1f60.
>
> The commit causes multiple issues in that:
> - the added call to ->control does potentially run unclocked
> causing a hang of the machine
> - the added pinctrl-states
Hi,
On Mon, May 20, 2019 at 3:01 PM Matthias Kaehlcke wrote:
>
> mickey crams a lot of hardware into a tiny package, which requires
> more aggressive thermal throttling than for devices with a larger
> footprint. Configure the GPU thermal zone to throttle the GPU
> progressively at temperatures
Hi,
On Mon, May 20, 2019 at 3:01 PM Matthias Kaehlcke wrote:
>
> On rk3288 the CPU and GPU temperatures are correlated. Limit the GPU
> frequency on veyron mickey to 400 MHz for CPU temperatures >= 65°C
> and to 300 MHz for CPU temperatures >= 85°C.
>
> This matches the configuration of the
Hi,
On Mon, May 20, 2019 at 3:01 PM Matthias Kaehlcke wrote:
>
> The NPLL is the only safe way to generate 500 MHz for the GPU. The
> downstream Chrome OS 3.14 kernel ('official' kernel for veyron
> devices) re-purposes NPLL to HDMI and hence disables the OPP for
> the GPU (see
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 with a larger
> footprint. Configure the GPU thermal zone to throttle the GPU
> progressively at temperatures
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 for CPU temperatures >= 85°C.
>
> This matches the configuration of the downstream Chrome OS 3.14 kernel,
> the
Hi,
On Mon, Apr 29, 2019 at 1:41 PM Douglas Anderson wrote:
>
> Processing SDIO interrupts while dw_mmc is suspended (or partly
> suspended) seems like a bad idea. We really don't want to be
> processing them until we've gotten ourselves fully powered up.
>
> You might be wondering how it's
Hi,
On Mon, May 20, 2019 at 1:09 AM Arend Van Spriel
wrote:
>
> On 5/18/2019 12:54 AM, Douglas Anderson wrote:
> > In commit 29f6589140a1 ("brcmfmac: disable command decode in
> > sdio_aos") we disabled something called "command decode in sdio_aos"
> > for a whole bunch of Broadcom SDIO WiFi
Hi,
On Sun, May 19, 2019 at 7:08 PM kbuild test robot wrote:
>
> Hi Douglas,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on v5.2-rc1 next-20190517]
> [if your patch is applied to the wrong git tree, please drop us
Hi,
On Sat, May 18, 2019 at 12:51 AM Heiko Stuebner wrote:
>
> Hi,
>
> Am Samstag, 18. Mai 2019, 01:57:47 CEST schrieb Doug Anderson:
> > Elaine and Caesar,
> >
> > On Tue, May 7, 2019 at 4:50 PM Douglas Anderson
> > wrote:
> > >
> > > Whil
Elaine and Caesar,
On Tue, May 7, 2019 at 4:50 PM Douglas Anderson wrote:
>
> While testing a newer kernel on rk3288-based Chromebooks I found that
> the power draw in suspend was higher on newer kernels compared to the
> downstream Chrome OS 3.14 kernel. Specifically the power of an
>
Hi,
On Thu, May 16, 2019 at 6:53 PM Rob Clark wrote:
>
> From: Rob Clark
>
> This is essentialy a squash of a bunch of history of cheza dt updates
> from chromium kernel, some of which were themselves squashes of history
> from older chromium kernels.
>
> I don't claim any credit other than
Hi,
From: kernelci.org bot
Date: Tue, May 14, 2019 at 9:06 AM
To: , ,
, ,
, ,
, Elaine Zhang, Eduardo Valentin, Daniel
Lezcano
Cc: Heiko Stuebner, ,
, ,
Zhang Rui,
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the
Hi,
On Thu, May 16, 2019 at 9:29 AM Matthias Kaehlcke wrote:
> 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
Hi,
On Thu, May 16, 2019 at 9:29 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
> kernel, the 'official' kernel for speedy.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in
Hi,
On Thu, May 16, 2019 at 9:29 AM Matthias Kaehlcke wrote:
> This value matches what is used by the downstream Chrome OS 3.14
> kernel, the 'official' kernel for veyron devices. Keep the temperature
> for 'speedy' at 90°C, as in the downstream kernel.
>
> Increase the temperature for a
Hi,
On Tue, May 14, 2019 at 9:10 PM Rob Clark wrote:
> On Mon, May 13, 2019 at 3:48 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, May 9, 2019 at 11:44 AM Rob Clark wrote:
> >
> > > From: Douglas Anderson
> > >
> > > Let
Hi,
On Thu, May 9, 2019 at 12:08 PM Rob Clark wrote:
> From: Rob Clark
>
> This is unused on cheza. Delete the node to get rid of the reserved-
> memory section, and to avoid the driver from attempting to load a zap
> shader that doesn't exist every time it powers up the GPU.
>
>
Hi,
On Wed, May 15, 2019 at 10:59 AM Doug Anderson wrote:
> Hi,
>
> On Wed, Apr 24, 2019 at 9:28 AM Matthias Kaehlcke wrote:
>
> > The Mali GPU of the rk3288 can be used as cooling device, add
> > a #cooling-cells entry for it.
> >
> > Signed-off-by: Matt
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' kernel for veyron devices.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> arch/arm/boot/dts/rk3288-veyron.dtsi | 8
> 1 file changed,
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
> kernel, the 'official' kernel for speedy.
>
> Signed-off-by: Matthias Kaehlcke
> ---
>
Hi,
On Wed, Apr 24, 2019 at 9:28 AM Matthias Kaehlcke wrote:
> 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
Hi,
On Tue, May 14, 2019 at 12:34 PM Guenter Roeck wrote:
> On Tue, May 14, 2019 at 11:40 AM Douglas Anderson
> wrote:
> > +static void cros_ec_spi_high_pri_release(struct device *dev, void *res)
> > +{
> > + struct cros_ec_spi *ec_spi = *(struct cros_ec_spi **)res;
> > +
> > +
Hi,
On Tue, May 14, 2019 at 2:30 AM Mark Brown wrote:
> On Mon, May 13, 2019 at 01:24:57PM -0700, Doug Anderson wrote:
> > On Sun, May 12, 2019 at 10:05 AM Mark Brown wrote:
>
> > In my case performance is 2nd place to a transfer not getting
> > interrupted once st
Hi,
On Thu, May 9, 2019 at 11:44 AM Rob Clark wrote:
> From: Douglas Anderson
>
> Let's fixup the reserved memory to re-add the things we deleted in
> ("CHROMIUM: arm64: dts: qcom: sdm845-cheza: Temporarily delete
> reserved-mem changes") in a way that plays nicely with the new
> upstream
Hi,
On Thu, May 9, 2019 at 11:44 AM Rob Clark wrote:
> From: Rob Clark
>
> This is essentialy a squash of a bunch of history of cheza dt updates
> from chromium kernel, some of which were themselves squashes of history
> from older chromium kernels.
>
> I don't claim any credit other than
Hi,
On Sun, May 12, 2019 at 10:05 AM Mark Brown wrote:
> On Fri, May 10, 2019 at 03:34:34PM -0700, Douglas Anderson wrote:
> > If a controller specifies that it needs high priority for sending
> > messages we should always schedule our transfers on the thread. If we
> > don't do this we'll do
Hi,
On Mon, May 13, 2019 at 9:47 AM, Mark Brown wrote:
> On Mon, May 13, 2019 at 09:03:28AM -0700, Doug Anderson wrote:
> > On Mon, May 13, 2019 at 9:02 AM Mark Brown wrote:
>
> > > I'm not saying the other changes aren't helping, I'm saying that it's
> > &
Hi,
On Mon, May 13, 2019 at 9:02 AM Mark Brown wrote:
>
> On Mon, May 13, 2019 at 08:57:12AM -0700, Doug Anderson wrote:
> > On Sun, May 12, 2019 at 10:05 AM Mark Brown wrote:
>
> > > It isn't clear to me that it's a bad thing to have this even with the
> > &g
Hi,
On Sun, May 12, 2019 at 10:05 AM Mark Brown wrote:
>
> On Fri, May 10, 2019 at 03:34:37PM -0700, Douglas Anderson wrote:
> > This reverts commit 37a186225a0c020516bafad2727fdcdfc039a1e4.
> >
> > We have a better solution in the patch ("platform/chrome: cros_ec_spi:
> > Set ourselves as
Hi,
> Use gen_rtx_set instead of gen_rtx_SET. The former is a wrapper macro
> that handles the difference between GCC versions implementing
> the latter.
>
> This fixes the following error on my system with g++ 5.4.0 as the host
> compiler
>
>HOSTCXX -fPIC
Hi,
On Tue, May 7, 2019 at 3:17 PM Frank Rowand wrote:
>
> On 5/7/19 10:59 AM, Doug Anderson wrote:
> > Hi,
> >
> >
> > On Tue, May 7, 2019 at 10:52 AM Frank Rowand wrote:
> >>
> >> On 5/6/19 9:48 PM, Douglas Anderson wrote:
> >>&
Hi,
On Tue, May 7, 2019 at 3:17 PM Frank Rowand wrote:
>
> On 5/6/19 4:58 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote:
> >>
> >> From: Douglas Anderson
> >> Date: Fri, May 3, 2019 at 1
Hi,
On Tue, May 7, 2019 at 10:52 AM Frank Rowand wrote:
>
> On 5/6/19 9:48 PM, Douglas Anderson wrote:
> > We'll add a dummy to just return false.
>
> A more complete explanation of why this is needed please.
>
> My one guess would be compile testing of arch/sparc/kernel/prom_64.c
> fails???
Hi,
On Mon, May 6, 2019 at 2:40 PM Brian Norris wrote:
>
> On Fri, May 3, 2019 at 10:48 AM Douglas Anderson
> wrote:
> > When you try to run an upstream kernel on an old ARM-based Chromebook
> > you'll find that console-ramoops doesn't work.
>
> Ooh, nice! I still get annoyed by old
Hi,
On Mon, May 6, 2019 at 4:58 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote:
> >
> > From: Douglas Anderson
> > Date: Fri, May 3, 2019 at 10:48 AM
> > To: Kees Cook, Anton Vorontsov
> > Cc: , ,
> > ,
Hi,
On Mon, May 6, 2019 at 2:10 PM Kees Cook wrote:
>
> From: Douglas Anderson
> Date: Fri, May 3, 2019 at 10:48 AM
> To: Kees Cook, Anton Vorontsov
> Cc: , ,
> , , ,
> Douglas Anderson, Colin Cross, Tony Luck,
>
>
> > When you try to run an upstream kernel on an old ARM-based Chromebook
> >
Hi,
On Sun, May 5, 2019 at 6:16 AM Greg KH wrote:
>
> On Fri, May 03, 2019 at 11:37:51AM -0700, Douglas Anderson wrote:
> > Hi,
> >
> > On Thu, Oct 18, 2018 at 11:56 AM Kees Cook wrote:
> > >
> > > From: "Joel Fernandes (Google)"
> > >
> > > ramoops's call of pstore_register() was recently
Hi,
On Tue, Apr 23, 2019 at 4:00 PM Douglas Anderson wrote:
>
> This adds support for working around errata A12 857271 / A17 857272.
> These errata were causing hangs on rk3288-based Chromebooks and it was
> confirmed that this workaround fixed the problems. In the Chrome OS
> 3.14 kernel this
Hi,
On Sep 10, 2018 at 4:39 PM Katsuhiro Suzuki wrote:
>
> This patch adds SNDRV_PCM_INFO_INTERLEAVED into PCM hardware info.
>
> Signed-off-by: Katsuhiro Suzuki
> ---
> sound/soc/rockchip/rockchip_pcm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
I just tracked down that audio
Hi,
On Tue, Apr 23, 2019 at 3:19 AM Robin Murphy wrote:
>
> Hi Doug,
>
> On 19/04/2019 23:18, Douglas Anderson wrote:
> > This adds a code for turning on chicken bit 11, which appears to avoid
> > a potential CPU deadlock that could occur. The exact set of
> > instruction needed to trigger this
Elaine,
On Fri, Apr 12, 2019 at 9:18 AM Douglas Anderson wrote:
>
> This is mostly a revert of commit 55bb6a633c33 ("clk: rockchip: mark
> noc and some special clk as critical on rk3288") except that we're
> keeping "pmu_hclk_otg0" as critical still.
>
> NOTE: turning these clocks off doesn't
Hi,
On Fri, Apr 12, 2019 at 5:16 AM Heiko Stübner wrote:
>
> Hi Elaine,
>
> Am Mittwoch, 3. April 2019, 11:44:09 CEST schrieb Elaine Zhang:
> > set pll sequence:
> > ->set pll to slow mode or other plls
> > ->set pll down
> > ->set pll params
> > ->set pll up
> >
Hi,
On Thu, Apr 11, 2019 at 6:43 PM elaine.zhang wrote:
> >>> - "pmu_hclk_otg0",
> >>>
> >>> It's a soc bug, pmu_hclk_otg0 must always on.
> >>>
> >>> So you said in your previous commit message. However we've shipped
> >>> lots and lots of Chromebooks with this clock off. Can you explain
Hi,
On Wed, Apr 10, 2019 at 8:27 PM elaine.zhang wrote:
>
> hi,
>
> 在 2019/4/10 下午11:34, Doug Anderson 写道:
>
> Hi,
>
> On Tue, Apr 9, 2019 at 11:23 PM elaine.zhang wrote:
>
> hi,
>
> 在 2019/4/10 上午4:47, Douglas Anderson 写道:
>
> This reverts commi
Hi,
On Wed, Apr 10, 2019 at 8:42 PM elaine.zhang wrote:
>
> hi,
>
> 在 2019/4/10 下午11:25, Doug Anderson 写道:
> > Hi,
> >
> > On Tue, Apr 9, 2019 at 11:42 PM elaine.zhang
> > wrote:
> >> hi,
> >>
> >> 在 2019/4/10 上午4:47, Douglas Ander
Hi,
On Wed, Apr 10, 2019 at 11:30 AM Matthias Kaehlcke wrote:
>
> Some veyron devices have a Bluetooth controller connected on UART0.
> The UART needs to operate at a high speed, however setting the clock
> rate at initialization has no practical effect. During initialization
> user space
Hi,
On Wed, Apr 10, 2019 at 11:38 AM Jonas Karlman wrote:
>
> On 2019-04-10 17:45, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Mar 29, 2019 at 2:55 PM Douglas Anderson
> > wrote:
> >> It appears that there is a typo in the rk3288 TRM. For
> >
701 - 800 of 5427 matches
Mail list logo
