On Tue, Jul 20, 2021 at 11:20:25AM -0600, Rob Herring wrote:
> There's no reason to have "status" properties in examples. "okay" is the
> default, and "disabled" turns off some schema checks ('required'
> specifically).
Acked-by: Mark Brown
signature.asc
Description: PGP signature
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/firmware/Makefile
between commit:
b42000e4b874 ("firmware: qcom_scm: Allow qcom_scm driver to be loadable as a
permenent module")
from the qcom/for-next tree and commits:
8633ef82f101 ("drivers/firmware: consol
Hi all,
Today's -next fails to build an arm64 allnoconfig:
aarch64-none-linux-gnu-ld: drivers/firmware/sysfb.o: in function `sysfb_init':
sysfb.c:(.init.text+0xc): undefined reference to `screen_info'
aarch64-none-linux-gnu-ld: drivers/firmware/sysfb.o: relocation
R_AARCH64_ADR_PREL_PG_HI21 agai
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
between commit:
ebc9ac7c3dfe ("drm/vmwgfx: Update device headers")
from the drm-next tree and commit:
be4f77ac6884 ("drm/vmwgfx: Cleanup fifo mmio handling")
from the drm-misc t
On Tue, Jul 27, 2021 at 01:32:29PM +0200, Javier Martinez Canillas wrote:
> On 7/27/21 1:17 PM, Geert Uytterhoeven wrote:
> > Do all (embedded) EFI systems have a frame buffer?
> That's a good question. I don't know if all EFI firmwares are expected
> to provide a GOP or not. But even the u-boot
On Tue, Jul 27, 2021 at 01:41:30PM +0200, Daniel Vetter wrote:
> On Tue, Jul 27, 2021 at 1:15 PM Mark Brown wrote:
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > between commit:
> > ebc9ac7c
Hi all,
After merging the amdgpu tree, today's linux-next build (x86
allmodconfig) failed like this:
ERROR: modpost: "dc_dsc_stream_bandwidth_in_kbps"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
Probably caused by commit
b6b76b0315ed7b ("drm/amd/display: Fixed EdidUtility build errors"
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_device_info.c
between commit:
0f9ed3b2c9ec ("drm/i915/display/cnl+: Handle fused off DSC")
from the drm-intel-fixes tree and commit:
a4d082fc194a ("drm/i915: rename/remove CNL registers"
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_display.c
between commit:
b4bde5554f70 ("drm/i915/display: split DISPLAY_VER 9 and 10 in
intel_setup_outputs()")
from Linus' tree and commits:
cad83b405fe4 ("drm/i915/display: r
On Fri, Apr 23, 2021 at 11:42:47AM +0800, Artem Lapkin wrote:
> Problem: rmmod meson_gx_mmc - not stable without spi_master_suspend call
> and we can get stuck when try unload this module
> +++ b/drivers/spi/spi-meson-spifc.c
> @@ -359,6 +359,7 @@ static int meson_spifc_remove(struct platform_devi
On Sat, Apr 24, 2021 at 07:57:19AM +0800, Art Nikpal wrote:
> > I would expect the driver to unregister the controller at the start of
> > the remove function, suspend doesn't really make sense here
> It's strange - But without spi_master_suspend i have randomly stucks when i
> try unload this mo
On Fri, Apr 30, 2021 at 04:49:35PM +0800, Art Nikpal wrote:
> Yep! but
Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is bei
On Mon, 26 Jul 2021 16:59:48 +0300, Nikita Shubin wrote:
> This series series of patches converts ep93xx to Common Clock Framework.
>
> It consists of preparation patches to use clk_prepare_enable where it is
> needed, instead of clk_enable used in ep93xx drivers prior to CCF and
> a patch convert
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
between commit:
e00f543d3596 ("drm/amdgpu: add DID for beige goby")
from the drm-fixes tree and commit:
a8f706966b92 ("drm/amdgpu: add pci device id for cyan_skillfish")
from the
API takes care
> of reconfiguring the domain's performance state in accordance to the
> rate. Add OPP support to the driver.
Acked-by: Mark Brown
Is there a concrete dependency here or can I merge this separately?
signature.asc
Description: PGP signature
On Thu, Aug 19, 2021 at 12:10:20PM +0200, Krzysztof Kozlowski wrote:
> Use common enum instead of oneOf and correct indentation warning:
> realtek,rt1015p.yaml:18:7: [warning] wrong indentation: expected 4 but
> found 6 (indentation)
For stuff like this where there's no relationship between the
On Thu, 19 Aug 2021 12:10:19 +0200, Krzysztof Kozlowski wrote:
> Correct indentation warning:
> ilitek,ili9341.yaml:25:9: [warning] wrong indentation: expected 10 but
> found 8 (indentation)
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
On Mon, Aug 23, 2021 at 09:38:56PM +0200, Sam Ravnborg wrote:
> On Mon, Aug 23, 2021 at 06:37:55PM +0100, Mark Brown wrote:
> > [2/2] dt-bindings: sound: rt1015p: correct indentation
> > commit: 0aeb17d1728257f29131a290f0cc8e281cc7274c
> I am confused here.
> Did you
On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote:
> Given that lowlevel drivers usually cannot implement exactly what a
> consumer requests with pwm_apply_state() there is some rounding involved.
Acked-by: Mark Brown
signature.asc
Description: PGP sig
On Fri, Jan 15, 2021 at 07:14:37PM +0100, Maxime Ripard wrote:
> On Wed, Jan 13, 2021 at 11:42:23AM +0000, Mark Brown wrote:
> > On Wed, Jan 13, 2021 at 10:19:57AM +0100, Maxime Ripard wrote:
> > > I'd like to get Mark's opinion before merging though
> > I
On Thu, Mar 11, 2021 at 10:20:58PM +0300, Dmitry Osipenko wrote:
> Acked-by: Mark brown
Typo there.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listi
On Wed, 19 May 2021 10:15:35 +0200, Mauro Carvalho Chehab wrote:
> There are some places at drm that ended receiving a
> REPLACEMENT CHARACTER U+fffd ('�'), probably because of
> some bad charset conversion.
>
> Fix them by using what it seems to be the proper
> character.
Applied to
ht
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple break/goto/return/fall
On Thu, 5 Nov 2020 02:43:57 +0300, Dmitry Osipenko wrote:
> Introduce core voltage scaling for NVIDIA Tegra20/30 SoCs, which reduces
> power consumption and heating of the Tegra chips. Tegra SoC has multiple
> hardware units which belong to a core power domain of the SoC and share
> the core voltag
On Tue, Dec 01, 2020 at 05:17:20PM +0300, Dmitry Osipenko wrote:
> 01.12.2020 16:57, Mark Brown пишет:
> > [1/1] regulator: Allow skipping disabled regulators in
> > regulator_check_consumers()
> > (no commit info)
> Could you please hold on this patch? It won
On Fri, Dec 04, 2020 at 10:42:26AM +0800, Zhen Lei wrote:
> All warnings are related only to "wrong indentation", except one:
> Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml:4:1: \
> [error] missing document start "---" (document-start)
It would make life easier (and be more normal pra
backlight driver,
> - TI LP8727 charger driver,
> - TI LP8788 MFD (ADC, LEDs, charger and regulator) drivers.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
> > + /*
> > +* Voltage scaling is optional and trying to set voltage for a dummy
> > +* regulator will error out.
> > +*/
> > + if (!device_property_p
On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> 10.11.2020 23:32, Mark Brown пишет:
> >>> + if (!device_property_present(dc->dev, "core-supply"))
> >>> + return;
> >> This is a potentially heavy operation, so I think
On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> 11.11.2020 14:55, Mark Brown пишет:
> > On Wed, Nov 11, 2020 at 12:23:41AM +0300, Dmitry Osipenko wrote:
> >> I already changed that code to use regulator_get_optional() for v2.
> > That doesn't lo
On Thu, Nov 12, 2020 at 10:16:14PM +0300, Dmitry Osipenko wrote:
> 12.11.2020 20:16, Mark Brown пишет:
> > On Thu, Nov 12, 2020 at 07:59:36PM +0300, Dmitry Osipenko wrote:
> >> Also, some device-trees won't have that regulator anyways because board
> >> schemati
On Fri, Nov 13, 2020 at 01:37:01AM +0300, Dmitry Osipenko wrote:
> 12.11.2020 23:01, Mark Brown пишет:
> >> But it's not allowed to change voltage of a dummy regulator, is it
> >> intentional?
> > Of course not, we can't know if the requested new voltage is
On Fri, Nov 13, 2020 at 06:55:27PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 17:29, Mark Brown пишет:
> > It's not clear if it matters - it's more a policy decision on the part
> > of the driver about what it thinks safe error handling is. If it's not
> I
On Fri, Nov 13, 2020 at 08:13:49PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 19:15, Mark Brown пишет:
> > My point here is that the driver shouldn't be checking for a dummy
> > regulator, the driver should be checking the features that are provided
> > to it by the re
On Sun, Nov 15, 2020 at 08:42:10PM +0300, Dmitry Osipenko wrote:
> 13.11.2020 20:28, Mark Brown пишет:
> >> What should we do?
> > As I keep saying the consumer driver should be enumerating the voltages
> > it can set, if it can't find any and wants to continue then
On Thu, Nov 19, 2020 at 05:22:43PM +0300, Dmitry Osipenko wrote:
> 16.11.2020 16:33, Mark Brown пишет:
> > No, you are failing to understand the purpose of this code. To
> > reiterate unless the device supports operating with the supply
> > physically absent then the
On Mon, 14 Mar 2022 12:53:24 +0100, Julia Lawall wrote:
> Various spelling mistakes in comments.
> Detected with the help of Coccinelle.
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[21/30] spi: sun4i: fix typos in comments
commit: 20
silently). The correct
> form was to put a '$ref' under an 'allOf'. This behavior is now changed
> in the 2019-09 json-schema spec and '$ref' can be mixed with other
> keywords.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Tue, 1 Mar 2022 11:11:04 +0300, Dan Carpenter wrote:
> The copy_to/from_user() functions return the number of bytes remaining
> to be copied. This function needs to return negative error codes
> because snd_soc_pcm_component_copy_user() treats positive returns as
> success in soc_component_ret(
On Fri, Sep 10, 2021 at 11:51:53AM -0500, Rob Herring wrote:
> 'enum' is equivalent to 'oneOf' with a list of 'const' entries, but 'enum'
> is more concise and yields better error messages.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote:
> This is also useful in regulator_lock_nested, which may avoid dropping
> regulator_nesting_mutex in the uncontended path, so use it there.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
hardware and will crash instantiating the driver. Add an IS_ENABLED()
check so we compile out the device registration if we don't have the Kconfig
option for the machine enabled.
Fixes: 552ccf6b259d290c0c ("video: fbdev: gbefb: add COMPILE_TEST support")
Signed-off-by: Mark Brown
: 96c8395e2166 ("spi: Revert modalias changes")
Signed-off-by: Mark Brown
---
drivers/video/backlight/hx8357.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 9b50bc96e00f..c64b1fbe027f 10
On Mon, Sep 27, 2021 at 10:42:00AM +0100, Daniel Thompson wrote:
> Based on this I had expected to find spi_get_device_id() and a ->driver_data
> somewhere in this patch.
> Where will this .driver_data be consumed?
It will never be consumed unless someone writes a board file - the
runtime match
On Mon, Sep 27, 2021 at 02:24:17PM +0100, Daniel Thompson wrote:
> In that case what is the point of including unconsumed driver data? Most
> DT centric drivers that included this for modalias reasons leave it
> NULL.
It's mainly there because it's generated fairly mechanically from the OF
ID tab
On Wed, Oct 06, 2021 at 12:38:16PM -0700, Stephen Boyd wrote:
> Use an aggregate driver instead of component ops so that we can get
> proper driver probe ordering of the aggregate device with respect to all
> the component devices that make up the aggregate device.
Acked-by: M
ase applies
> though the description usually describes it.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Tue, Jan 18, 2022 at 07:53:25PM -0600, Rob Herring wrote:
> For a single pinctrl mode, it is not necessary to define pinctrl
> properties as the tools always allow pinctrl properties.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Fri, 14 Jan 2022 15:02:06 -0800, Brian Norris wrote:
> This series fixes DP/HDMI audio for RK3399 Gru systems.
>
> First, there was a regression with the switch to SPDIF. Patch 1 can be
> taken separately as a regression fix if desired. But it's not quite so
> useful (at least on Chrome OS syst
On Mon, Nov 15, 2021 at 09:53:54AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Setting slave_id makes no sense with DT based probing, and
> should eventually get removed entirely. Address this driver
> by no longer setting the field here.
Acked-by: Mark Brown
tale references and
> two drivers that abuse the field as a side-channel between the
> dmaengine driver and its client.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Wed, Dec 01, 2021 at 01:02:45PM +, Paul Cercueil wrote:
> Le mar., nov. 30 2021 at 22:26:37 +0100, H. Nikolaus Schaller
> > + regulator = devm_regulator_get_optional(&pdev->dev, "hdmi-5v");
> > + if (IS_ERR(regulator)) {
> > + ret = PTR_ERR(regulator);
Why is this using _opti
On Wed, Dec 01, 2021 at 03:33:24PM +0100, H. Nikolaus Schaller wrote:
> > Am 01.12.2021 um 15:03 schrieb Paul Cercueil :
> > Please make it mandatory in DTS then, and use devm_regulator_get() in the
> > driver.
> Well, I just wonder why the elegant devm_regulator_get_optional() exists at
> all
On Wed, Dec 01, 2021 at 05:53:03PM +0100, H. Nikolaus Schaller wrote:
> > Am 01.12.2021 um 16:10 schrieb Mark Brown :
> > Again, if the supply can be physically absent that is a sensible use
> > case but that means completely absent, not just not software
> > controllable.
On Mon, Dec 21, 2020 at 09:06:45PM -0700, Rob Herring wrote:
> 'maxItems' equal to the 'items' list length is redundant. 'maxItems' is
> preferred for a single entry while greater than 1 should have an 'items'
> list.
Acked-by: Mark
On Mon, Dec 21, 2020 at 04:46:59PM -0700, Rob Herring wrote:
> *-supply properties are always a single phandle, so binding schemas
> don't need a type $ref nor 'maxItems'.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
On Thu, 17 Dec 2020 23:00:39 +0800, cy_huang wrote:
> This adds support Richtek RT4831 core. It includes four channel WLED driver
> and Display Bias Voltage outputs.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
Thanks!
[3/6] regulator: rt4831: Ad
On Fri, Jan 01, 2021 at 04:54:44PM +, Yangtao Li wrote:
> We should use dev_pm_opp_put_clkname() to free opp table each time
> dev_pm_opp_of_add_table() got error.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri
On Fri, Jan 01, 2021 at 04:54:45PM +, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and we don't need
> to make opp_table glabal.
Acked-by: Mark brown
signature.asc
Description: PGP signature
___
dri-devel mailing lis
On Fri, Jan 01, 2021 at 04:54:49PM +, Yangtao Li wrote:
> We should use dev_pm_opp_put_clkname() to free opp table each time
> dev_pm_opp_of_add_table() got error.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri
On Fri, Jan 01, 2021 at 04:54:50PM +, Yangtao Li wrote:
> Use devm_pm_opp_* API to simplify code, and remove opp_table
> from qcom_qspi.
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri
On Mon, Jan 11, 2021 at 10:40:46PM +0100, Linus Walleij wrote:
> Mark, can I have your ACK for deleting
> include/linux/spi/lms283gf05.h
> As part of this patch sets?
Acked-by: Mark Brown
signature.asc
Description: PGP signature
___
On Wed, Jan 13, 2021 at 10:19:57AM +0100, Maxime Ripard wrote:
> I'd like to get Mark's opinion before merging though
I'm not sure what the question is here? I get CCed on a bunch of not
obviously relevant DRM patches so there's a good chance I've just
deleted some relevnat discussion.
signatu
On Sat, Dec 04, 2021 at 05:37:03PM +0300, Dmitry Osipenko wrote:
> I based S/PDIF patches on Arnd's Bergmann patch from a separate series [1]
> that removes obsolete slave_id. This eases merging of the patches by
> removing the merge conflict. This is a note for Mark Brown.
That
On Wed, Dec 15, 2021 at 10:19:07PM +0300, Dmitry Osipenko wrote:
> 15.12.2021 21:57, Mark Brown пишет:
> > Please include human readable descriptions of things like commits and
> > issues being discussed in e-mail in your mails, this makes them much
> > easier for humans to
On Thu, Dec 16, 2021 at 03:20:21PM +0100, Thierry Reding wrote:
> On Sat, Dec 04, 2021 at 05:37:07PM +0300, Dmitry Osipenko wrote:
> > Document new optional sound-dai-cells property of HDMI node. This node will
> > be used as endpoint of HDMI sound DAI graph.
> It's probably best for this to go th
On Sat, 4 Dec 2021 17:37:03 +0300, Dmitry Osipenko wrote:
> This series revives Tegra20 S/PDIF driver which was upstreamed long time
> ago, but never was used. It also turns Tegra DRM HDMI driver into HDMI
> audio CODEC provider. Finally, HDMI audio is enabled in device-trees.
> For now the audio i
On Thu, 23 Dec 2021 13:24:31 +0100, Alexander Stein wrote:
> Following up [1] here are more fix for missing sound-name-prefix properties in
> the arch/arm64/boot/dts/amlogic/ subtree.
>
> [1] https://www.spinics.net/lists/devicetree/msg466125.html
>
> Alexander Stein (3):
> dt-bindings: display
On Mon, Aug 01, 2016 at 04:57:07AM +, Kuninori Morimoto wrote:
> Mark, Thierry, Daniel
> I wonder who can be maintainer for this patch ??
It's a DRM patch so I'd expect someone in the DRM subsystem.
-- next part --
A non-text attachment was scrubbed...
Name: signature.
On Tue, Aug 02, 2016 at 05:25:38AM +, Kuninori Morimoto wrote:
> I understand that 1) patch will be handled by drm side maintainer.
> And 2) was already accepted by you.
> I believe maintainer of 3) patch is you ??
Yes.
-- next part --
A non-text attachment was scrubbe
On Tue, Aug 02, 2016 at 03:14:57PM +0200, Daniel Vetter wrote:
> Archit Tajena is the maintainer of last resort for anything related to
> drm_bridge.
That's Archit Taneja (note spelling of surname)
for anyone else who's confused. Can we get him listed in MAINTAINERS
please so it's easier for pe
i_name().
Signed-off-by: Kuninori Morimoto
Signed-off-by: Mark Brown
---
sound/soc/codecs/hdmi-codec.c | 67 +--
1 file changed, 64 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index f27d115626db.
On Fri, Aug 05, 2016 at 05:48:45PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote:
> > That may be a problem. The ASoC card device tree binding current looks
> > for the ASoC DAI's parent's of-node if it can not find the node for the
> > DAI-dev
On Fri, Aug 05, 2016 at 06:04:50PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote:
> > We do have some stuff in there in order to handle MFDs - they'll
> > instantiate a Linux-internal virtual platform device as a child
On Wed, Aug 17, 2016 at 08:28:17AM +0100, Build bot for Mark Brown wrote:
Today's -next fails to build an arm64 allmodconfig due to:
> arm64-allmodconfig
> ../drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c:140:18: error: passing
> argument 1 of 'dc_ops->cleanup'
On Wed, Aug 17, 2016 at 12:14:53PM +0200, Daniel Vetter wrote:
> On Wed, Aug 17, 2016 at 10:26:44AM +0100, Mark Brown wrote:
> > caused by d25bcfb8c2 (drm/hisilicon: Don't set drm_device->platformdev)
> > which does a a partial conversion to new APIs.
> Yeah I screwed
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 Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote:
> Den 11.04.2019 20.18, skrev Lukas Wunner:
> > On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote:
> >> @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct
> >> spi_controller *ctlr, bool in_kthread)
> >>tr
On Thu, Apr 11, 2019 at 06:42:33PM +0200, Noralf Trønnes wrote:
> +++ b/drivers/spi/spi.c
> @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct spi_controller
> *ctlr, bool in_kthread)
>
> trace_spi_message_start(ctlr->cur_msg);
>
> + ret = spi_split_transfers_maxsize(ctlr
On Fri, Apr 12, 2019 at 11:41:30AM +0200, Noralf Trønnes wrote:
> This let SPI clients check if the controller supports a particular word
> width. drivers/gpu/drm/tinydrm/mipi-dbi.c will use this to determine if
> the controller supports 16-bit for RGB565 pixels. If it doesn't it will
> swap the by
On Fri, Apr 12, 2019 at 12:03:35PM +0200, ker...@martin.sperl.org wrote:
> > On 12.04.2019, at 11:47, Mark Brown wrote:
> >> In a previous version of this I suggested to Meghana to put this in the
> >> driver, but Mark wanted it in the core.
> > If we want to do
On Fri, Apr 12, 2019 at 12:54:48PM +0200, Lukas Wunner wrote:
> On Fri, Apr 12, 2019 at 10:47:21AM +0100, Mark Brown wrote:
> > I *think* we managed to fix all the architectures to at least stub out
> > the DMA interfaces, it's such a pointless thing to have conditional -
>
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
>
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
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
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
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
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 Tue, Feb 26, 2019 at 09:53:22AM -0500, Sven Van Asbroeck wrote:
> On Tue, Feb 26, 2019 at 4:11 AM Russell King - ARM Linux admin
> > If the signal continues toggling, what does it do for the inactive
> > channel - is that just one BCLK period long or does it assume there
> > is still the second
On Tue, Feb 26, 2019 at 03:45:19PM +, Russell King - ARM Linux admin wrote:
> Adding more WS signals makes the bus deviate from the I2S standard,
> thereby making it impossible to connect a set of standard DACs to
> such a source, whereas adding more I2S data lines, you just connect
> each DAC
On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> That's a very good point too. In light of this, I struggle to understand how
> the ssl_ssi can specify this:
> static struct snd_soc_dai_driver fsl_ssi_dai_template = {
> .playback = {
> .stream_name = "C
On Tue, Feb 26, 2019 at 05:03:49PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 26, 2019 at 11:31:15AM -0500, Sven Van Asbroeck wrote:
> > There is talk in the manual about "network mode", which could work by
> > changing
> > the LRCLK only at the first slot - thereby allowing clien
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 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 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 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 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 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
1 - 100 of 857 matches
Mail list logo