On Wed, Jun 24, 2020 at 01:41:26PM +0200, Andrzej Hajda wrote:
> In case of error during resource acquisition driver should print error
> message only in case it is not deferred probe, using probe_err helper
> solves the issue. Moreover it records defer probe reason for debugging.
If we silently i
On Tue, 9 Jun 2020 13:45:53 +0100, Kieran Bingham wrote:
> I wouldn't normally go through spelling fixes, but I caught sight of
> this typo twice, and then foolishly grepped the tree for it, and saw how
> pervasive it was.
>
> so here I am ... fixing a typo globally... but with an addition in
> sc
On Mon, Jun 15, 2020 at 01:57:39PM +0200, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > On Mon, Jun 15, 2020 at 08:46:52AM +0200, Mauro Carvalho Chehab wrote:
> > > There are some new broken doc links due to yaml renames
> > > at DT. Developers shoul
On Mon, Jun 15, 2020 at 08:46:52AM +0200, Mauro Carvalho Chehab wrote:
> There are some new broken doc links due to yaml renames
> at DT. Developers should really run:
I also previously acked this one in 20200504100822.ga5...@sirena.org.uk.
Has anything changed here to cause the ack to be dropped?
On Mon, Jun 15, 2020 at 08:46:53AM +0200, Mauro Carvalho Chehab wrote:
> Some files got renamed. Those were all fixed automatically by
>
> ./scripts/documentation-file-ref-check --fix
Acked-by: Mark Brown
signature.asc
Description: PGP
On Wed, May 27, 2020 at 06:45:53PM +0800, dillon min wrote:
> sorry, forget to remove these two patch from this submits, will not
> include it in later submits
> which ack other's review result.
Ah, OK - no problem.
signature.asc
Description: PGP signature
__
On Wed, May 27, 2020 at 03:27:32PM +0800, dillon.min...@gmail.com wrote:
> From: dillon min
>
> in l3gd20 driver startup, there is a setup failed error return from
> stm32 spi driver
Please do not submit new versions of already applied patches, please
submit incremental updates to the existing c
On Mon, 25 May 2020 11:45:40 +0800, dillon.min...@gmail.com wrote:
> V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> for SPI_SIMPLEX_RX mode on stm32 spi controller.
>
> V5:
> 1 instead of add send dummy data out under SIMPLEX_RX mode,
>add flags 'SPI_CONTROLLER_MUST_T
On Sat, May 23, 2020 at 09:35:06AM +0800, dillon min wrote:
> - if (ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) {
> + if ((ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX))
> &&
> + !(msg->spi->mode & SPI_3WIRE)) {
> ma
On Fri, May 22, 2020 at 11:59:25PM +0800, dillon min wrote:
> but, after spi-core create a dummy tx_buf or rx_buf, then i can't get
> the correct spi_3wire direction.
> actually, this dummy tx_buf is useless for SPI_3WIRE. it's has meaning
> for SPI_SIMPLE_RX mode,
> simulate SPI_FULL_DUMPLEX
Oh,
On Thu, May 21, 2020 at 07:30:04PM +0800, Shengjiu Wang wrote:
> On Wed, May 20, 2020 at 8:38 PM Mark Brown wrote:
> > Other drivers having problems means those drivers should be fixed, not
> > that we should copy the problems. In the case of the PXA driver that's
>
On Mon, May 18, 2020 at 07:09:20PM +0800, dillon.min...@gmail.com wrote:
> 2, use stm32 spi's "In full-duplex (BIDIMODE=0 and RXONLY=0)", as tx_buf is
> null, we must add dummy data sent out before read data.
> so, add stm32f4_spi_tx_dummy() to handle this situation.
There are flags SPI_CONTROLLE
On Wed, May 20, 2020 at 07:22:19PM +0800, Shengjiu Wang wrote:
> I see some driver also request dma channel in open() or hw_params().
> how can they avoid the defer probe issue?
> for example：
> sound/arm/pxa2xx-pcm-lib.c
> sound/soc/sprd/sprd-pcm-dma.c
Other drivers having problems means those d
On Mon, May 04, 2020 at 11:30:20AM +0200, Mauro Carvalho Chehab wrote:
> There are some new broken doc links due to yaml renames
> at DT. Developers should really run:
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri
On Sun, Apr 19, 2020 at 11:25:08AM +0200, Clément Péron wrote:
> Just saw that a Lima devfreq[0] has been also introduced with I think
> exactly the same logic.
> Is this something that hasn't been triggered by Maintainer or I am
> missing something?
My understanding is that there is very little
On Thu, 16 Apr 2020 12:30:52 +0200, Geert Uytterhoeven wrote:
> Hi all,
>
> In several files the company also known as ADI is spelled as "Analog
> Device". However, according to https://www.analog.com/, the company
> name is spelled "Analog Devices".
>
> Hence this patch series, one per su
company name is spelled
"Analog Devices".
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Alexandru Ardelean
Link: https://lore.kernel.org/r/20200416103058.15269-7-geert+rene...@glider.be
Signed-off-by: Mark Brown
---
sound/soc/codecs/ad1980.c | 2 +-
sound/soc/codecs/ad73311.c | 2 +
On Thu, Apr 16, 2020 at 02:42:13PM +0100, Steven Price wrote:
> On 14/04/2020 20:16, Clément Péron wrote:
> > That's can be reworked and Panfrost can only probe regulator if there
> > is no opp-table.
> This is what I was thinking about looking at. But it may make sense instead
> to extend the re
On Tue, Apr 14, 2020 at 09:16:39PM +0200, Clément Péron wrote:
> But if multiple regulator is not an issue and as each request is logic.
> The first in device_init assure to enable the regulator and the second
> in OPP assure the voltage level.
> Maybe we can just fix this warning?
Well, if you
On Wed, Apr 15, 2020 at 07:55:49PM -0500, Rob Herring wrote:
> json-schema versions draft7 and earlier have a weird behavior in that
> any keywords combined with a '$ref' are ignored (silently). The correct
> form was to put a '$ref' under an 'allOf'. This
scripts which do transforms on the schema files.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Apr 14, 2020 at 08:20:23PM +0200, Clément Péron wrote:
> Hi Liam and Mark,
You might want to flag stuff like this in the subject line, I very
nearly deleted this without opening it since most of the email I get
about panfrost appears to be coming from me having sent patches rather
than bei
t; are bus specific properties such as 'spi-max-frequency' that go into
> bus child nodes, but aren't defined in the child node's schema.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Mon, Mar 16, 2020 at 10:43:46PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 16, 2020 at 09:48:50PM +0100, Maxime Ripard wrote:
> > All the SPI devices will be declared under a spi controller node that
> > will validate its child nodes (and thus the devices) already.
> This was the missing piece -
On Mon, Mar 16, 2020 at 07:57:33PM +0100, Sam Ravnborg wrote:
> It was the best I could come up with - and this patch was called out
> for review in the hope there is a better way than this patch.
It definitely seems like a useful thing, just a bit surprised it's not
already there and if this is
On Mon, Mar 16, 2020 at 02:28:44PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 16, 2020 at 12:02:41PM +0000, Mark Brown wrote:
> > On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote:
> > > Independent bindings can be SPI slaves which for example is
> > > the case
On Sun, Mar 15, 2020 at 02:43:42PM +0100, Sam Ravnborg wrote:
> Independent bindings can be SPI slaves which for example is
> the case for several panel bindings.
What is an "independent binding"?
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it eas
0, fsynr=0x3f0022, cbfrsynra=0x828, cb=8
This was tested on a custom board with a LS1028A SoC.
Signed-off-by: Michael Walle
Link: https://lore.kernel.org/r/20200310073313.21277-1-mich...@walle.cc
Signed-off-by: Mark Brown
---
drivers/spi/spi-fsl-dspi.c | 17 ++---
1 file cha
On Tue, Mar 10, 2020 at 03:12:45PM +0100, Michael Walle wrote:
> Am 2020-03-10 14:02, schrieb Vladimir Oltean:
> > I'm testing LS1028A with IOMMU_DEFAULT_PASSTHROUGH=y and I didn't have
> > time to change my setup now. I've also sent a v3 to my patch series
> > which is going to conflict with this
On Mon, Feb 17, 2020 at 11:15:37PM +0100, Noralf Trønnes wrote:
> Den 17.02.2020 22.39, skrev Mark Brown:
> > Out of interest why are 8 bit registers going to be a problem?
> I have written 3 drivers so far and they all have some registers that
> need to deal with values larger
hen component removing to notify its consumers
: no further plugged status report is required.
Signed-off-by: Tzung-Bi Shih
Link:
https://lore.kernel.org/r/20200217105513.1.Icc323daaf71ad02f191fd8d91136b01b61eca5e3@changeid
Signed-off-by: Mark Brown
---
sound/soc/codecs/hdmi-codec.c |
0e6fc6323b@changeid
Signed-off-by: Mark Brown
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 03aeb73005ef..d80017e3d84a 100644
--- a/drive
On Mon, Feb 17, 2020 at 10:33:58PM +0100, Noralf Trønnes wrote:
> Den 17.02.2020 13.11, skrev Mark Brown:
> > This looks like you just don't support a straight write operation, if
> > you need to do this emulation push it up the stack.
> After going through the stack
On Sun, Feb 16, 2020 at 06:21:14PM +0100, Noralf Trønnes wrote:
> When writing a 3MB buffer the unwritable check in _regmap_raw_write_impl()
> adds a ~20ms overhead on a Raspberry Pi 4.
> Amend this by avoiding the check if it's not necessary.
This is a generic optimization, why is it mixed in wi
On Sun, Feb 16, 2020 at 06:21:09PM +0100, Noralf Trønnes wrote:
> Add support for regmap over USB for use with the Multifunction USB Device.
> Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
> interface. The register index width is always 32-bit, but the register
> value
if register_audio_driver() returns errors.
Signed-off-by: Tzung-Bi Shih
Acked-by: CK Hu
Link:
https://lore.kernel.org/r/20200206102509.1.Ieba8d422486264eb7aaa3aa257620a1b0c74c6db@changeid
Signed-off-by: Mark Brown
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 11 ---
1 file changed, 8 insertions(+)
DMI jack reporting.
Signed-off-by: Tzung-Bi Shih
Link:
https://lore.kernel.org/r/20200206102509.3.I253f51edff62df1d88005de12ba601aa029b1e99@changeid
Signed-off-by: Mark Brown
---
sound/soc/mediatek/mt8173/mt8173-rt5650.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
d
| hdmi-codec | -> snd_soc_jack_report()
+--+ codec_dev ++
connector_status
Signed-off-by: Tzung-Bi Shih
Link:
https://lore.kernel.org/r/20200206102509.2.I230fd59de28e73934a91cb01424e25b9e84727f4@changeid
Signed-off-by: Mark Brown
---
drivers/gpu/drm/mediatek/
On Fri, Feb 07, 2020 at 01:26:24PM +0800, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
Reviwed-by: Mark Brown
signature.asc
Description: PG
On Tue, Jan 21, 2020 at 07:29:37PM +0100, Maxime Ripard wrote:
> > Mark, our issue here is that we have a driver tied to a device that is
> > an HDMI encoder. Obviously, we'll want to register into DRM, which is
> > what we were doing so far, with the usual case where at remove /
> > unbind time,
On Mon, Jan 20, 2020 at 02:43:10PM +, Steven Price wrote:
> From discussions offline, I think I've come round to the view that
> having a "soft PDC" in device tree isn't the right solution. Device tree
> should be describing the hardware and that isn't actually a hardware
> component.
You can
the thread on v2 [1].
You'd need to enumerate all the properties of the device and look
for things matching *-supply.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists
On Thu, Jan 09, 2020 at 04:53:02PM +, Steven Price wrote:
> On 09/01/2020 16:28, Mark Brown wrote:
> > On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
> > > I'm not sure if it's better, but could we just encode the list of
> > > regulator
On Thu, Jan 09, 2020 at 02:14:42PM +, Steven Price wrote:
> On 08/01/2020 22:52, Nicolas Boichat wrote:
> > That'd be a bit awkward to match, though... Currently all bifrost
> > share the same compatible "arm,mali-bifrost", and it'd seem
> > weird/wrong to match "mediatek,mt8183-mali" in this
On Wed, Jan 08, 2020 at 01:23:34PM +0800, Nicolas Boichat wrote:
> Some GPUs, namely, the bifrost/g72 part on MT8183, have a second
> regulator for their SRAM, let's add support for that.
> + pfdev->regulator_sram = devm_regulator_get_optional(pfdev->dev, "sram");
> + if (IS_ERR(pfdev->re
On Sat, Nov 30, 2019 at 04:09:58PM +0100, Torsten Duwe wrote:
> of_get_regulator() will unconditionally add "-supply" to form the
> property name. This is documented in commit 69511a452e6dc ("map consumer
> regulator based on device tree").
Sorry, I meant to also
On Sat, Nov 30, 2019 at 04:09:58PM +0100, Torsten Duwe wrote:
> IMHO that commit message should have ended up somewhere under Documentation/.
This is documented already in the generic regulator bindings and
has been since they were added, they specify that supplies should
always have the suffix -
. Such regulators should use the vanilla regulator_get()
interface, it will ensure that even if a supply is not described in the
system integration one will be provided in software.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/thc63lvd1024.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Tue, Nov 05, 2019 at 02:15:11PM +0100, Thierry Reding wrote:
> It is in fact optional in this case. This code remains solely for
> backwards compatibility with old DTBs because back at the time the VDD
> supply was associated with the DPAUX block where it should've really
> been associated with
regulators should use the vanilla regulator_get()
interface, it will ensure that even if a supply is not described in the
system integration one will be provided in software.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/tegra/dpaux.c | 32
1 file changed, 12
off-by: Mark Brown
---
.../drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 11 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 41 ++-
include/drm/bridge/dw_hdmi.h | 4 ++
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/synop
://lore.kernel.org/r/20191028071930.145899-4-cychi...@chromium.org
Signed-off-by: Mark Brown
---
sound/soc/rockchip/rockchip_max98090.c | 291 +++--
1 file changed, 226 insertions(+), 65 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_max98090.c
b/sound/soc/rockchip
report jack status.
Signed-off-by: Cheng-Yi Chiang
Link: https://lore.kernel.org/r/20191028071930.145899-5-cychi...@chromium.org
Signed-off-by: Mark Brown
---
sound/soc/rockchip/Kconfig | 3 ++-
sound/soc/rockchip/rockchip_max98090.c | 22 ++
2 files changed, 24
odec": The phandle of Ext chip for jack detection
Signed-off-by: Cheng-Yi Chiang
Link: https://lore.kernel.org/r/20191028071930.145899-3-cychi...@chromium.org
Signed-off-by: Mark Brown
---
.../bindings/sound/rockchip-max98090.txt | 27 +--
1 file changed, 25 insertions(+)
On Fri, Oct 18, 2019 at 05:41:20PM +0200, Arnd Bergmann wrote:
> The mach/hardware.h is included in lots of places, and it provides
> three different things on pxa:
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel m
On Mon, Oct 21, 2019 at 02:08:57PM +0300, Andy Shevchenko wrote:
> Mark, can be this applied?
b2662a164f9dc48d
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holiday, attend conferences and so
on so unless there is some reason for urg
On Wed, Oct 16, 2019 at 11:30:51PM +0200, Noralf Trønnes wrote:
> As Andy mentioned, ->max_transfer_size is a callback:
> struct spi_controller {
> /*
>* on some hardware transfer / message size may be constrained
>* the limit may depend on device transfer settings
>
On Wed, Oct 16, 2019 at 07:44:51PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2019 at 6:13 PM Andy Shevchenko
> > On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> > > Something like this, as a test patch.
> > max_transfer_size should be a function. In that case it works.
> Why
On Fri, Oct 04, 2019 at 06:12:52PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 17:58, Mark Brown wrote:
> > Regulator supplies are supposed to be defined at the chip level rather
> > than subfunctions with names corresponding to the names on the chip.
...
> > good cha
On Fri, Oct 04, 2019 at 05:13:13PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 16:40, Mark Brown wrote:
> > Why is the LED core populating anything? Is the LED core copying bits
> > out of the struct device for the actual device into a synthetic device
> > rather th
On Fri, Oct 04, 2019 at 03:33:13PM +0200, Jean-Jacques Hiblot wrote:
> On 04/10/2019 13:39, Mark Brown wrote:
> > Consumers should just be able to request a regulator without having to
> > worry about how that's being provided - they should have no knowledge at
> > a
On Thu, Oct 03, 2019 at 10:27:26PM +0200, Jacek Anaszewski wrote:
> On 10/3/19 9:41 PM, Mark Brown wrote:
> > Why would we want to do that? We'd continue to support only DT systems,
> > just with code that's less obviously DT only and would need to put
> > check
On Thu, Oct 03, 2019 at 09:21:06PM +0200, Jacek Anaszewski wrote:
> On 10/3/19 8:35 PM, Mark Brown wrote:
> > On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
> >> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
> >>> On 03/10/2019 12:42, Sebastian Rei
On Thu, Oct 03, 2019 at 07:43:17PM +0200, Jacek Anaszewski wrote:
> On 10/3/19 2:47 PM, Jean-Jacques Hiblot wrote:
> > On 03/10/2019 12:42, Sebastian Reichel wrote:
> >> On Thu, Oct 03, 2019 at 10:28:09AM +0200, Jean-Jacques Hiblot wrote:
This mail has nothing relevant in the subject line and page
On Tue, Sep 17, 2019 at 02:46:48AM +0900, Masahiro Yamada wrote:
> On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote:
> > gcc throws compile error with below message:
> GNU Make throws ...
Xinpeng Liu via Nick Desaulniers sent a description of the problem and a
patch so I think I'll be able to f
On Mon, Sep 16, 2019 at 02:06:46PM -0700, Nick Desaulniers wrote:
> On Sun, Sep 15, 2019 at 2:47 PM Mark Brown wrote:
> > 0f0727d971f6fdf ("drm/amd/display: readd -msse2 to prevent Clang from
> > emitting libcalls to undefined SW FP routines")
> ^ this patch
On Tue, Sep 17, 2019 at 02:46:48AM +0900, Masahiro Yamada wrote:
> (+CC Stephen Rothwell, Mark Brown)
>
> On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote:
> >
> > gcc throws compile error with below message:
>
> GNU Make throws ...
>
>
I don't have t
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/display/dc/dml/Makefile
between commit:
54b8ae66ae1a345 ("kbuild: change *FLAGS_.o to take the path
relative to $(obj)")
from the kbuild tree and commits:
0f0727d971f6fdf ("drm/amd/display: readd -m
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h
between commit:
03dce35deb8575 ("drm/amd/powerplay: remove duplicate macro
smu_get_uclk_dpm_states in amdgpu_smu.h")
from the amdgpu tree and commit:
eee3258e8f8be8 ("drm/
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/lima/lima_gem.c
between commit:
21670bd78a25001cf8e ("drm/lima: fix lima_gem_wait() return value")
from the drm-misc-fixes tree and commit:
52791eeec1d9f4a7e7f ("dma-buf: rename reservation_object to dma
On Thu, Sep 12, 2019 at 12:28:03PM +0100, Steven Price wrote:
> Use dev_pm_opp_set_rate() instead of open coding the devfreq
> integration, simplifying the code.
Reviewed-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel m
On Mon, Sep 09, 2019 at 09:37:14AM +0200, Neil Armstrong wrote:
> I'd like some review from ASoC people and other drm bridge reviewers,
> Jernej, Jonas & Andrzej.
> Jonas could have some comments on the overall patchset.
The ASoC bits look basically fine, I've gone ahead and applied
patch 1 as i
On Fri, Sep 06, 2019 at 11:00:53AM +0100, Steven Price wrote:
> On 05/09/2019 17:34, Mark Brown wrote:
> > that information, I'd recommend eliminating individual OPPs if some are
> > supported or just never doing any regulator configuration if none can be
> > set.
>
On Thu, Sep 05, 2019 at 02:02:38PM +0100, Steven Price wrote:
> On 05/09/2019 13:40, Mark Brown wrote:
> > Is that safe? You can't rely on being able to change voltages even if
> > there's a physical regulator available, system constraints or the
> > results of s
On Thu, Sep 05, 2019 at 10:37:53AM +0100, Steven Price wrote:
> Ah, I didn't realise that regulator_get() will return a dummy regulator
> if none is provided in the DT. In theory that seems like a nicer
> solution to my two commits. However there's still a problem - the dummy
> regulator returned
regulators should use the vanilla regulator_get()
interface, it will ensure that even if a supply is not described in the
system integration one will be provided in software.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/lima/lima_device.c | 8 ++--
1 file changed, 2 insertions(+), 6
. Such regulators should use the vanilla regulator_get()
interface, it will ensure that even if a supply is not described in the
system integration one will be provided in software.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/panfrost/panfrost_device.c | 8 ++--
1 file changed, 2 insertions
On Fri, Aug 02, 2019 at 05:13:30AM -0700, kernelci.org bot wrote:
Today's -next still fails to boot on CM-QS600 with qcom_defconfig:
> qcom_defconfig:
> gcc-8:
> qcom-apq8064-cm-qs600: 1 failed lab
This has been going on since June. It crashes initializing the GPU:
[
On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote:
Today's -next fails to build an arm allmodconfig due to:
> allmodconfig (arm, gcc-8) — FAIL, 2 errors, 16 warnings, 0 section mismatches
>
> Errors:
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:279:9: error: implicit
> declar
On Tue, Jul 30, 2019 at 05:17:56AM -0700, kernelci.org bot wrote:
The previously reported issues with booting -next on
meson-gxm-khadas-vim2 are still present today, though seemingly only
manifesting with CONFIG_RANDOMIZE_BASE and not defconfig (there are
failures with big endian too but they don'
On Tue, Jul 23, 2019 at 11:18:33PM +0100, Suzuki K Poulose wrote:
> Introduce wrappers for {bus/driver/class}_find_device() to
> locate devices by its of_node.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Jul 25, 2019 at 06:02:08PM -0400, Paul Cercueil wrote:
> The board now uses the simple-audio-card driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
Acked-by: Mark Brown
signature.asc
Description: PGP signature
_
On Wed, Jul 17, 2019 at 04:27:56AM -0700, kernelci.org bot wrote:
Today's -next fails to boot on a couple of apq8064 boards:
> arm:
> qcom_defconfig:
> gcc-8:
> qcom-apq8064-cm-qs600: 1 failed lab
> qcom-apq8064-ifc6410: 1 failed lab
In both cases it looks lik
On Wed, Jul 17, 2019 at 04:27:56AM -0700, kernelci.org bot wrote:
Today's -next fails to boot on meson-gxm-khadas-vim2 in a variety
of configurations:
> defconfig:
> gcc-8:
> meson-gxm-khadas-vim2:
> lab-baylibre: new failure (last pass: next-20190705)
> d
On Thu, Jul 11, 2019 at 03:11:56PM +0200, Andrzej Hajda wrote:
> 1. DSI protocol defines actually more than 30 types of transactions[1],
> but this patchset implements only few of them (dsi generic write/read
> family). Is it possible to implement multiple types of transactions in
> regmap?
You c
On Wed, Jul 10, 2019 at 12:08:34PM -0600, Jeffrey Hugo wrote:
> On Fri, Jul 5, 2019 at 7:06 PM Mark Brown wrote:
> The addresses for these spec defined messages are 8-bit wide, so 256
> valid "destinations". However, the payload is variable. Most of the
> defined op
On Wed, Jul 03, 2019 at 02:45:12PM -0700, Jeffrey Hugo wrote:
> Add basic support with a simple implementation that utilizes the generic
> read/write commands to allow device registers to be configured.
This looks good to me but I really don't know anything about DSI,
I'd appreciate some review fr
On Fri, Jul 05, 2019 at 03:31:24PM +0800, Cheng-yi Chiang wrote:
> It was a long discussion.
> I think the conclusion was that if we are only talking about
> hdmi-codec, then we just need to extend the ops exposed in hdmi-codec
> and don't need to use
> hdmi-notifier or drm_audio_component.
What
On Fri, Jul 05, 2019 at 03:08:37PM +0800, Tzung-Bi Shih wrote:
> On Fri, Jul 5, 2019 at 12:26 PM Cheng-Yi Chiang wrote:
> > +typedef void (*hdmi_codec_plugged_cb)(struct platform_device *dev,
> > + bool plugged);
> > +
> The callback prototype is "weird" by st
On Tue, Jun 11, 2019 at 04:37:16PM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build an arm allmodconfig due to:
> arm-allmodconfig
> ../drivers/gpu/drm/arm/display/komeda/d71/d71_component.c:206:30: error:
> passing argument 3 of 'd71_layer_update_fb
On Thu, Jun 06, 2019 at 11:47:36AM +0200, Anders Roxell wrote:
> obj-$(CONFIG_REGULATOR_88PG86X) += 88pg86x.o
> -obj-$(CONFIG_REGULATOR_88PM800) += 88pm800.o
> +obj-$(CONFIG_REGULATOR_88PM800) += 88pm800-regulator.o
> +88pm800-regulator-objs := 88pm800.o
Don't do this, no need for
On Thu, May 09, 2019 at 05:50:36PM +0200, Noralf Trønnes wrote:
> I can't see this in for-5.2 or linux-next. You also gave me a topic
> branch for this, but I wasn't able to get an r-b on the drm patch in the
> few days left before the -rc5 cutoff in the drm subsystem. This means
> that the patch
On Fri, Apr 26, 2019 at 06:46:09AM -0300, Mauro Carvalho Chehab wrote:
> Mark Brown escreveu:
> > This is massively CCed covering a large range of subsystems and is patch
> > 25 of a 79 patch series so I've no context for what's going on here or
> > why...
>
On Mon, Apr 22, 2019 at 10:27:14AM -0300, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
This is massively CCed covering a large range of subsystems and is patch
25 of a 79 patch series so I've no context for what's going on here or
Signed-off-by: Noralf Trønnes
Signed-off-by: Mark Brown
---
include/linux/spi/spi.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 662b336aa2e4..b30e3d13a5ac 100644
--- a/include/linux/spi/spi.h
+++ b/include/l
be called after finalizing.
Signed-off-by: Noralf Trønnes
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 3c6c6101b611..2195fa265aef 100644
--- a/drivers/spi/spi.c
+++ b/drivers/
Signed-off-by: Noralf Trønnes
Signed-off-by: Mark Brown
---
include/linux/spi/spi.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 662b336aa2e4..b30e3d13a5ac 100644
--- a/include/linux/spi/spi.h
+++ b/include/l
ype: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Don't warn about splitting transfers, the info is available in the
statistics if needed.
Signed-off-by: Noralf Trønnes
Signed-off-by: Mark Brown
---
drivers/spi/spi.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/dri
On Fri, Apr 12, 2019 at 12:46:44PM +0200, Lukas Wunner wrote:
> On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote:
> > Den 11.04.2019 20.18, skrev Lukas Wunner:
> > > Note that spi_map_buf() already splits every transfer's sglist into
> > > segments that are smaller than ctlr->max_dma
On Fri, Apr 12, 2019 at 01:16:15PM +0200, Lukas Wunner wrote:
> On Fri, Apr 12, 2019 at 12:09:34PM +0100, Mark Brown wrote:
> > On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote:
> > > My point was that the call to spi_split_transfers_maxsize() shouldn't
>
301 - 400 of 816 matches
Mail list logo
