Re: [PATCH v4 05/16] SoC: mediatek: mt8365: support audio clock control
On Fri, Apr 26, 2024 at 07:22:34PM +0200, Alexandre Mergnat wrote: > Add audio clock wrapper and audio tuner control. Please submit patches using subject lines reflecting the style for the subsystem, this makes it easier for people to identify relevant patches. Look at what existing commits in the area you're changing are doing and make sure your subject lines visually resemble what they're doing. There's no need to resubmit to fix this alone. signature.asc Description: PGP signature
Re: [PATCH v3 07/13] drm: Make drivers depends on DRM_DW_HDMI
On Tue, Apr 02, 2024 at 04:43:46PM +0100, Mark Brown wrote: > On Wed, Mar 27, 2024 at 11:57:02AM +0100, Maxime Ripard wrote: > > > DRM_DW_HDMI has a number of dependencies that might not be enabled. > > However, drivers were used to selecting it while not enforcing the > > DRM_DW_HDMI dependencies. > > > > This could result in Kconfig warnings (and further build breakages) such > > as: > > > > Kconfig warnings: (for reference only) > > WARNING: unmet direct dependencies detected for DRM_DW_HDMI > > Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && > > DRM_DISPLAY_HELPER [=n] > > Selected by [m]: > > - DRM_SUN8I_DW_HDMI [=m] && HAS_IOMEM [=y] && DRM_SUN4I [=m] > This has landed in -next and appears to be causing breakage for several > platforms using these devices. For example I'm seeing the HDMI fail to > probe on sun50i-a64-pin64-plus with arm64 defconfig, the DT kselftest > result isn't terribly informative but it can be seen here: It has now been *three* weeks that this breakage has sat unaddressed in -next, this has been making my CI for -next unusable. Given that getting the defconfig bits of this merged appears somwhow unreasonably difficult can we please drop these changes from the DRM tree until some strategy for getting everything merged is put into place? signature.asc Description: PGP signature
Re: [PATCH 0/7] drm/display: Fix display helpers depends on fallouts
On Mon, Apr 15, 2024 at 01:21:47PM +0200, Maxime Ripard wrote: > On Wed, Apr 10, 2024 at 07:06:39PM +0100, Mark Brown wrote: > > Is there any news on getting the rest of this merged? It's been more > > than a week now and the Designware display controllers are all still > > broken in -next, causing widespread breakage in CI. For bisection > > purposes it probably makes sense for the defconfig updates to go along > > with the changes to the Kconfig for the driver... > I was on holidays so I've admittedly hoped that it would be picked up / > reviewed by the relevant maintainers. > Aside from the changes on sunxi_defconfig, I haven't seen any review > from the relevant maintainers so I'm not sure how to merge this. Should > we get an Acked-by from Arnd, Olof, Catalin or Will and merge everything > through drm-misc? Sounds like a reasonable plan to me - usually it'd be the SoC maintainers for stuff like this but they're not on the CC, though TBH it seems sufficiently obvious that I doubt anyone would mind if you just merged things without waiting. signature.asc Description: PGP signature
Re: [PATCH 0/7] drm/display: Fix display helpers depends on fallouts
On Wed, Apr 03, 2024 at 12:56:18PM +0200, Maxime Ripard wrote: > Hi, > > Here's a series addressing the various regressions that were reported > after the Kconfig rework for the DRM display helpers. > > Let me know what you think, > Maxime Is there any news on getting the rest of this merged? It's been more than a week now and the Designware display controllers are all still broken in -next, causing widespread breakage in CI. For bisection purposes it probably makes sense for the defconfig updates to go along with the changes to the Kconfig for the driver... signature.asc Description: PGP signature
Re: [PATCH 0/7] drm/display: Fix display helpers depends on fallouts
On Wed, Apr 03, 2024 at 12:56:18PM +0200, Maxime Ripard wrote: > Hi, > > Here's a series addressing the various regressions that were reported > after the Kconfig rework for the DRM display helpers. This makes sense to me and looks like it does the right thing for multi_v7_defconfig so Reviewed-by: Mark Brown Between the arm64 defconfig update not applying on -next and unrelated breakage on arm I didn't actually do a proper test. signature.asc Description: PGP signature
Re: [PATCH v3 07/13] drm: Make drivers depends on DRM_DW_HDMI
On Wed, Mar 27, 2024 at 11:57:02AM +0100, Maxime Ripard wrote: > DRM_DW_HDMI has a number of dependencies that might not be enabled. > However, drivers were used to selecting it while not enforcing the > DRM_DW_HDMI dependencies. > > This could result in Kconfig warnings (and further build breakages) such > as: > > Kconfig warnings: (for reference only) > WARNING: unmet direct dependencies detected for DRM_DW_HDMI > Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && > DRM_DISPLAY_HELPER [=n] > Selected by [m]: > - DRM_SUN8I_DW_HDMI [=m] && HAS_IOMEM [=y] && DRM_SUN4I [=m] This has landed in -next and appears to be causing breakage for several platforms using these devices. For example I'm seeing the HDMI fail to probe on sun50i-a64-pin64-plus with arm64 defconfig, the DT kselftest result isn't terribly informative but it can be seen here: https://lava.sirena.org.uk/scheduler/job/78288#L6007 which I bisected to this change: # bad: [c0b832517f627ead3388c6f0c74e8ac10ad5774b] Add linux-next specific files for 20240402 # good: [0fc83069bcaee78f60b8511d9453a9441963a072] Merge branch 'for-linux-next-fixes' of https://gitlab.freedesktop.org/drm/misc/kernel.git # good: [ba5206881843e16b74a07c37970dcc44d22f8f6f] spi: spi.h: add missing kernel-doc for @last_cs_index_mask # good: [64fe73d10323e399b2e8eb5407390bcb302a046c] spi: fsl: remove is_dma_mapped checks # good: [bb77c99ee6d3d704086acf141d3ec92601747809] spi: pxa2xx: Skip SSP initialization if it's done elsewhere # good: [e64d3b6fc9a388d7dc516668651cf4404bffec9b] spi: omap2-mcpsi: Enable MULTI-mode in more situations # good: [57ad033ce09d4d0c866ac558fc3c4cf53cfb2599] ASoC: Intel: sof_cs42l42: add mtl_cs42l42_def for mtl boards # good: [7b5f2072657a9041cbaf4ba139f672be11694ca3] ASoC: dt-bindings: fsl-sai: allow only one dma-names # good: [a5bef84422eb066ee8fa5c13960657a79b3cc1e7] spi: fsl-dspi: drop driver owner assignment # good: [29580cd7b9c6f975e88597ca66a001b16b97bae9] ASoC: sdw-mockup: drop driver owner assignment # good: [ea60ab95723f5738e7737b56dda95e6feefa5b50] ASoC: kirkwood: Fix potential NULL dereference # good: [c0a3873b9938bfaa77bd337cad33266a50a6583f] ASoC: nau8325: new driver # good: [559aebe45a054a479fdbd2a3dfba999ffd73cc9d] ASoC: sun8i-codec: Fix build with CONFIG_SND_JACK_INPUT_DEV disabled # good: [d5449432f794e75cd4f5e46bc33bfe6ce20b657d] spi: pxa2xx: Switch to use dev_err_probe() # good: [7b95ee0db7e0a7f99077f1b926323c7bf0d2e8f8] ASoC: soc-jack: Get rid of legacy GPIO support # good: [ea5fee227ff3dae209062ac9544906debe1e9ac1] ASoC: hdac_hda: improve error logs # good: [4ed0915f5bc4bcc81bca783a5b984f3d81e9764e] ASoC: codecs: Add RK3308 internal audio codec driver # good: [59ffeb15b2f7b44cf934fd778dc0d98a35aa6a84] ASoC: Intel: sof_sdw: Add support for cs42l43 optional speaker output # good: [1e90a846493c716e3e6b4d901fc0844e9eea6430] ASoC: soc-dai: Note valid values of sysclock direction # good: [61cafaeab5bca2d3e6a68ee8fa92b5c10b8610ca] ASoC: Intel: sof_rt5682: board id cleanup for cml boards # good: [9b163e0d330debbf7dcc14b2c3e2dc19a3b50a1d] spi: remove struct spi_message::is_dma_mapped # good: [b340f56a74b62d8ce8617650c8ab4a26c87ba5c5] ASoC: dt-bindings: wm8974: Convert to dtschema # good: [bdeef5dcea6b164f4bd614655821b1ef12ebec9a] spi: rspi: Get rid of unused struct rspi_plat_data # good: [885dd75f41f9fff5b277bc6ab28ad798f98a37b4] ASoC: dt-bindings: fsl-esai: Convert fsl,esai.txt to yaml # good: [10402419f2d60890525f590b54d0eaec3de0d87a] spi: spi-mt65xx: Rename a variable in interrupt handler # good: [9855f05e553637f05494cf47a3154cbf9a5cfc67] ASoC: fsl: imx-es8328: Switch to using gpiod API # good: [5f39231888c63f0a7708abc86b51b847476379d8] ASoC: mediatek: Assign dummy when codec not specified for a DAI link # good: [5edeb7d312628961046eec9b26a7e72f44baf846] regulator: pca9450: add pca9451a support # good: [c14445bdcb98feddf9afaeb05e6193cc1f8eec1a] ASoC: fsl: imx-rpmsg: Update to correct DT node # good: [a39111b1cf0864b1782f30f9a1fa65260d057327] spi: xilinx: Make num_chipselect 8-bit in the struct xspi_platform_data # good: [b5867a5c0d7a6bf36f59f3d472c7aed33ca4d02c] spi: pxa2xx: Use proper SSP header in soc/pxa/ssp.c # good: [60c10c678b582d41532fefa12667d8adca75811b] ASoC: Intel: avs: i2s_test: Remove redundant dapm routes # good: [21fa98f4197bb3365dda1417708b318f403c13c1] ASoC: sun8i-codec: Implement jack and accessory detection # good: [cee28113db17f0de58df0eaea4e2756c404ee01f] ASoC: dmaengine_pcm: Allow passing component name via config # good: [aad6b35290f52639d3601063d33d9621c0948a04] regmap: maple: Remove second semicolon # good: [e6913c6ef83c80aa7569c9e0820454fbf542] ASoC: codecs: ES8326: Delete unused REG_SUPPLY # good: [0c5f77f4eaef8ed9fe752d21f40ac471dd511cfc] dt-bindings: regulator: qcom,usb-vbus-regulator: Add PM7250B compatible # good: [ab470abe58c09b2fbe2c1478e67a904fd803e84f] regulator: rpi-panel-attiny: convert to use maple tree register
Re: (subset) [PATCH v2 0/4] drm: xlnx: zynqmp: Add DP audio support
On Tue, 19 Mar 2024 10:22:35 +0200, Tomi Valkeinen wrote: > Add DisplayPort audio support for Xilinx ZynqMP platforms. > > This depends on patch adding cyclic DMA mode for DPDMA driver: > > https://lore.kernel.org/all/20240228042124.3074044-3-vishal.sa...@amd.com/ > > If that patch is missing, starting an audio playback will fail with an > ASoC error. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/4] ASoC: dmaengine_pcm: Allow passing component name via config commit: cee28113db17f0de58df0eaea4e2756c404ee01f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: (subset) [PATCH 0/4] drm: xlnx: zynqmp: Add DP audio support
On Tue, 12 Mar 2024 11:41:01 +0200, Tomi Valkeinen wrote: > Add DisplayPort audio support for Xilinx ZynqMP platforms. > > This depends on patch adding cyclic DMA mode for DPDMA driver: > > https://lore.kernel.org/all/20240228042124.3074044-3-vishal.sa...@amd.com/ > > If that patch is missing, starting an audio playback will fail with an > ASoC error. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/4] ASoC: dmaengine_pcm: Allow passing component name via config commit: cee28113db17f0de58df0eaea4e2756c404ee01f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec
On Fri, Mar 15, 2024 at 06:36:19PM +0100, Alexandre Mergnat wrote: > On 15/03/2024 16:15, Mark Brown wrote: > > On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote: > > > > In the register. You only need to reset the gain to -40dB at the start > > > > of the ramp. > > > Sorry but I don't understand your logic, I'm not able to implement it... > > > If I'm at -10dB and doing a ramp to reach -40dB, next time I will read the > > > register the value will be -40dB. > > After we've done the ramp and turned the amplifier off we can just > > restore the desired value? The hardware is not going to care what the > > volume is while it's not enabled. > If you do that, HP will be enabled at the saved gain, and after that you > will do the ramp. To avoid pop, the driver should be rewrite to: So reset the volume to -40dB prior to turning the amplifier on... > Read gain in the reg and save it locally > Set -40dB in the reg > Enable HP > Do ramp ...as you yourself suggest? > > > AFAII from the comment in the code, it's done to avoid the "pop noises". > > Yes, that's the usual reason to ramp gains. Though if you've just > > copied the code without checking that it's needed it's possible that > > this is something that's been fixed in current hardware. > I did the test at 24dB with and without the "pop filter". Isn't big but I > ear the pop at the start of the record without the "pop filter". OK, it probably is still doing something then. > To be clear, the algo/behavior of this code is an implementation based on > the 6k+ lines downstream code for this specific audio codec. But the > shape/style is based on upstreamed drivers like mt6358.c. The Mediatek code has a bunch of issues, I wouldn't read too much into something being present in the code. signature.asc Description: PGP signature
Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec
On Fri, Mar 15, 2024 at 04:05:21PM +0100, Alexandre Mergnat wrote: > On 15/03/2024 15:30, Mark Brown wrote: > > > Let me know, when you change de gain to do a ramp down (start from user > > > gain > > > to gain=-40db), next time for the ramp up, how/where do you find the user > > > gain ? > > In the register. You only need to reset the gain to -40dB at the start > > of the ramp. > Sorry but I don't understand your logic, I'm not able to implement it... > If I'm at -10dB and doing a ramp to reach -40dB, next time I will read the > register the value will be -40dB. After we've done the ramp and turned the amplifier off we can just restore the desired value? The hardware is not going to care what the volume is while it's not enabled. > This implementation is also done in other MTK audio codec drivers. Perhaps they should be updated too? > > > When microphone isn't capturing, the gain read back from the register is > > > 0dB. I've put some logs in my code and do capture to show how it works: > > Is this a property of the hardware or a property of your driver? > At the end of the capture, the gain is set to 0dB by the driver. > At the start of the capture, the gain is set to the setup gain. So that's a property of the driver then? > AFAII from the comment in the code, it's done to avoid the "pop noises". Yes, that's the usual reason to ramp gains. Though if you've just copied the code without checking that it's needed it's possible that this is something that's been fixed in current hardware. signature.asc Description: PGP signature
Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board
On Tue, Mar 12, 2024 at 09:58:05AM +0100, Alexandre Mergnat wrote: > I'm a bit lost for mixer-test and pcm-test. > Currently, I cross-compile the alsa lib project to be able to build the > tests and put it on my board. > I can execute it, but I still have 2 issues: > 1) I've a lot of missing module in my environment (Encode.so, Encode.pm, > Symbol.pm, IO/Handle.pm, ...). AFAII, I've to cross compile the missing perl > modules and install them in the rootfs These tests are both simple C programs... > 2) I don't know how to configure pcm-test.conf & > Lenovo_ThinkPad_P1_Gen2.conf (or new file to match with my board). The configuration is optional. > My test cmd: > ./run_kselftest.sh -c alsa Just run the programs directly. I'm only asking for the output from two of them anyway. signature.asc Description: PGP signature
Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec
On Fri, Mar 15, 2024 at 12:01:12PM +0100, Alexandre Mergnat wrote:
> On 13/03/2024 18:23, Mark Brown wrote:
> > On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote:
> > > Actually you must save the values because the gain selected by the user
> > > will
> > > be override to do a ramp => volume_ramp(.):
> > > - When you switch on the HP, you start from gain=-40db to final_gain
> > > (selected by user).
> > > - When you switch off the HP, you start from final_gain (selected by user)
> > > to gain=-40db.
> > You can just read the value back when you need to do a ramp?
> You can't. Because you will read -40db when HP isn't playing sound. That is
> why the gain is saved into the struct.
> Let me know, when you change de gain to do a ramp down (start from user gain
> to gain=-40db), next time for the ramp up, how/where do you find the user
> gain ?
In the register. You only need to reset the gain to -40dB at the start
of the ramp.
> > > Also, the microphone's gain change when it's enabled/disabled.
> > I don't understand what this means?
> When microphone isn't capturing, the gain read back from the register is
> 0dB. I've put some logs in my code and do capture to show how it works:
Is this a property of the hardware or a property of your driver?
> > > > > + /* ul channel swap */
> > > > > + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0,
> > > > > AFE_UL_LR_SWAP_SFT, 1, 0),
> > > > On/off controls should end in Switch.
> > > Sorry, I don't understand your comment. Can you reword it please ?
> > See control-names.rst. Run mixer-test on a card with this driver and
> > fix all the issues it reports.
> Ok the name is the issue for you AFAII.
> This control isn't for on/off but swap Left and Right.
> From the codec documentation:
> "Swaps audio UL L/R channel before UL SRC"
> This control is overkill, I will remove it
This is turning the swapping on and off.
signature.asc
Description: PGP signature
Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec
On Wed, Mar 13, 2024 at 06:11:50PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > index ..13e95c227114 > > > --- /dev/null > > > +++ b/sound/soc/codecs/mt6357.c > > > @@ -0,0 +1,1805 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * MT6357 ALSA SoC audio codec driver > > Please use a C++ comment for the whole comment to make it clearer that > > this is intentional. > If I do that, the checkpatch raise a warning: > WARNING: Improper SPDX comment style for > 'sound/soc/mediatek/mt8365/mt8365-afe-clk.c', please use '//' instead > #22: FILE: sound/soc/mediatek/mt8365/mt8365-afe-clk.c:1: > +/* SPDX-License-Identifier: GPL-2.0 That's not a C++ comment so checkpatch is correctly warning? signature.asc Description: PGP signature
Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec
On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote:
> On 26/02/2024 17:09, Mark Brown wrote:
> > > + case MT6357_ZCD_CON2:
> > > + regmap_read(priv->regmap, MT6357_ZCD_CON2, );
> > > + priv->ana_gain[ANALOG_VOLUME_HPOUTL] =
> > > + (reg & AUD_HPL_GAIN_MASK) >> AUD_HPL_GAIN_SFT;
> > > + priv->ana_gain[ANALOG_VOLUME_HPOUTR] =
> > > + (reg & AUD_HPR_GAIN_MASK) >> AUD_HPR_GAIN_SFT;
> > > + break;
> > It would probably be less code and would definitely be clearer and
> > simpler to just read the values when we need them rather than constatly
> > keeping a cache separate to the register cache.
> Actually you must save the values because the gain selected by the user will
> be override to do a ramp => volume_ramp(.):
> - When you switch on the HP, you start from gain=-40db to final_gain
> (selected by user).
> - When you switch off the HP, you start from final_gain (selected by user)
> to gain=-40db.
You can just read the value back when you need to do a ramp?
> Also, the microphone's gain change when it's enabled/disabled.
I don't understand what this means?
> > > + /* ul channel swap */
> > > + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1,
> > > 0),
> > On/off controls should end in Switch.
> Sorry, I don't understand your comment. Can you reword it please ?
See control-names.rst. Run mixer-test on a card with this driver and
fix all the issues it reports.
> > > +static int hslo_mux_map_value[] = {
> > > + 0x0, 0x1, 0x2, 0x3,
> > > +};
> > Why not just use a normal mux here, there's no missing values or
> > reordering? Similarly for other muxes.
> I've dug into some other codecs and it's done like that, but I've probably
> misunderstood something.
> The only bad thing I see is enum is missing currently:
>
> enum {
> PGA_MUX_OPEN = 0,
> PGA_MUX_DACR,
> PGA_MUX_PB,
> PGA_MUX_TM,
> PGA_MUX_MASK = 0x3,
> };
The whole thing with explicitly specfying the mapping is just completely
redundant, you may as well remove it.
signature.asc
Description: PGP signature
Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote: > On 2/29/24 10:21 PM, Linus Torvalds wrote: > > We already have the situation that the drm people have their own ci > > model. II'm ok with that, partly because then at least the maintainers > > of that subsystem can agree on the rules for that one subsystem. > > I'm not at all interested in having something that people will then > > either fight about, or - more likely - ignore, at the top level > > because there isn't some global agreement about what the rules are. > > For example, even just running checkpatch is often a stylistic thing, > > and not everybody agrees about all the checkpatch warnings. ... > > I would suggest the CI project be separate from the kernel. > It is possible to have a GitLab CI setup with the YAML files in a separate > repository. And we can start with that. However, ultimately I think it's > better to have it in the same repo with the code being tested. This way you > could submit code changes together with the required tweaks to the CI to keep > it passing, making development smoother and faster. > With that in mind, and if you agree, where else would you say we could put it? > Under "scripts"? Or "Documentation"? And where it would be best for the > various subsystems to put theirs? Or could we have the top-level "ci" dir and > pile all the different setups there? Or would you like to wait and see how > adoption goes, and then decide? If we were going to put bits of this in tree how about something like tools/testing/forges? I'd hope that things could be shared by multiple services, if not we could always have subdirs I guess. We could put glue bits like defining how to run kunit, checkpatch or whatever with these systems in there so people can share figuring that bit out. Individual trees or CI systems using these forge based systems could then reference these files when defining what specific tests they want to run when which seems more like where the differences will be. I'm not super familiar with this stuff, the above is based on it looking like there's an OK degree of separation between the "what to run" and "how to run" bits. I might be misreading things, and it's not clear to me how often it'll be useful to be able to update things in tree. signature.asc Description: PGP signature
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 01:19:19PM +0200, Laurent Pinchart wrote: > On Thu, Feb 29, 2024 at 01:10:16PM +0200, Nikolai Kondrashov wrote: > > Of course. You're also welcome to join the #kernelci channel on libera.chat. > Isn't that a bit pointless if it's no the main IM channel ? It *was* the original channel and still gets some usage (mostly started by me admittedly since I've never joined slack for a bunch of reasons that make it hassle), IIRC the Slack was started because there were some interns who had trouble figuring out IRC and intermittent connectivity but people seem to have migrated. signature.asc Description: PGP signature
Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
On Thu, Feb 29, 2024 at 09:39:01AM +, Sakari Ailus wrote: > On Thu, Feb 29, 2024 at 01:07:25AM +0200, Laurent Pinchart wrote: > > > We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance > > > https://kernelci.slack.com/ . > > > Feel free to join and contribute to the conversation. The KernelCI team > > > has > > > weekly calls where we also discuss the GitLab-CI pipeline. > > Could we communicate using free software please ? Furthermore, it's not > > possible to create an account on that slack instance unless you have an > > e-mail address affiliated with a small number of companies > > (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go > > for me. > I agree. There is no shortage of good alternatives either: we have IRC, > Matrix and XMPP for instance. Just pick one of them. And indeed KernelCI does actually already have #kernelci on libera.chat. signature.asc Description: PGP signature
Re: [PATCH v5 7/8] ASoC: dt-bindings: xmos, xvf3500: add XMOS XVF3500 voice processor
On Wed, Feb 28, 2024 at 02:51:34PM +0100, Javier Carrasco wrote: > The XMOS XVF3500 VocalFusion Voice Processor[1] is a low-latency, 32-bit > multicore controller for voice processing. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH 00/18] Add audio support for the MediaTek Genio 350-evk board
On Mon, Feb 26, 2024 at 03:01:38PM +0100, Alexandre Mergnat wrote: > This serie aim to add the following audio support for the Genio 350-evk: > - Playback > - 2ch Headset Jack (Earphone) > - 1ch Line-out Jack (Speaker) > - 8ch HDMI Tx > - Capture > - 1ch DMIC (On-board Digital Microphone) > - 1ch AMIC (On-board Analogic Microphone) > - 1ch Headset Jack (External Analogic Microphone) > > Of course, HDMI playback need the MT8365 display patches [1] and a DTS > change documented in "mediatek,mt8365-mt6357.yaml". Given the number of custom controls here could you please post the output of mixer-test and pcm-test from a system with this driver running next time you post, this will help with review since it checks a bunch of things around the new controls. signature.asc Description: PGP signature
Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec
On Mon, Feb 26, 2024 at 03:01:50PM +0100, amerg...@baylibre.com wrote:
> index ..13e95c227114
> --- /dev/null
> +++ b/sound/soc/codecs/mt6357.c
> @@ -0,0 +1,1805 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MT6357 ALSA SoC audio codec driver
> + *
Please use a C++ comment for the whole comment to make it clearer that
this is intentional.
> +static void set_playback_gpio(struct mt6357_priv *priv, bool enable)
> +{
> + if (enable) {
> + /* set gpio mosi mode */
> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_CLR,
> GPIO_MODE2_CLEAR_ALL);
> + regmap_write(priv->regmap, MT6357_GPIO_MODE2_SET,
> GPIO8_MODE_SET_AUD_CLK_MOSI |
> +
> GPIO9_MODE_SET_AUD_DAT_MOSI0 |
> +
> GPIO10_MODE_SET_AUD_DAT_MOSI1 |
> +
> GPIO11_MODE_SET_AUD_SYNC_MOSI);
This would be a lot more legible if you worked out the values to set and
then had a single set of writes, currently the indentation makes it very
hard to read. Similarly for other similar functions.
> +static int mt6357_put_volsw(struct snd_kcontrol *kcontrol, struct
> snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_component *component =
> snd_soc_kcontrol_component(kcontrol);
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(component);
> + struct soc_mixer_control *mc = (struct soc_mixer_control
> *)kcontrol->private_value;
> + unsigned int reg;
> + int ret;
> +
> + ret = snd_soc_put_volsw(kcontrol, ucontrol);
> + if (ret < 0)
> + return ret;
> +
> + switch (mc->reg) {
> + case MT6357_ZCD_CON2:
> + regmap_read(priv->regmap, MT6357_ZCD_CON2, );
> + priv->ana_gain[ANALOG_VOLUME_HPOUTL] =
> + (reg & AUD_HPL_GAIN_MASK) >> AUD_HPL_GAIN_SFT;
> + priv->ana_gain[ANALOG_VOLUME_HPOUTR] =
> + (reg & AUD_HPR_GAIN_MASK) >> AUD_HPR_GAIN_SFT;
> + break;
It would probably be less code and would definitely be clearer and
simpler to just read the values when we need them rather than constatly
keeping a cache separate to the register cache.
> + /* ul channel swap */
> + SOC_SINGLE("UL LR Swap", MT6357_AFE_UL_DL_CON0, AFE_UL_LR_SWAP_SFT, 1,
> 0),
On/off controls should end in Switch.
> +static const char * const hslo_mux_map[] = {
> + "Open", "DACR", "Playback", "Test mode"
> +};
> +
> +static int hslo_mux_map_value[] = {
> + 0x0, 0x1, 0x2, 0x3,
> +};
Why not just use a normal mux here, there's no missing values or
reordering? Similarly for other muxes.
> +static unsigned int mt6357_read(struct snd_soc_component *codec, unsigned
> int reg)
> +{
> + struct mt6357_priv *priv = snd_soc_component_get_drvdata(codec);
> + unsigned int val;
> +
> + pr_debug("%s() reg = 0x%x", __func__, reg);
> + regmap_read(priv->regmap, reg, );
> + return val;
> +}
Remove these, there are vastly more logging facilities as standard in
the regmap core.
> +/* Reg bit defines */
> +/* MT6357_GPIO_DIR0 */
> +#define GPIO8_DIR_MASK BIT(8)
> +#define GPIO8_DIR_INPUT 0
Please namespace your defines, these look very generic.
signature.asc
Description: PGP signature
Re: (subset) [PATCH v2 00/33] spi: get rid of some legacy macros
On Mon, 22 Jan 2024 19:06:55 +0100, Uwe Kleine-König wrote: > this is v2 of this patch set. > > Changes since (implicit) v1, sent with Message-Id: > cover.1705348269.git.u.kleine-koe...@pengutronix.de: > > - Rebase to v6.8-rc1 > - Fix a build failure on sh > - Added the tags received in (implicit) v1. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [01/33] fpga: ice40-spi: Follow renaming of SPI "master" to "controller" commit: 227ab73b89d66e3064b3c2bcb5fe382b1815763d [02/33] ieee802154: ca8210: Follow renaming of SPI "master" to "controller" commit: 167b78446706bb4d19f7dd93ca320aed25ae1bbd [03/33] iio: adc: ad_sigma_delta: Follow renaming of SPI "master" to "controller" commit: 2780e7b716a605781dbee753ef4983d775a65427 [04/33] Input: pxspad - follow renaming of SPI "master" to "controller" commit: a78acec53b8524593afeed7258a442adc3450818 [05/33] Input: synaptics-rmi4 - follow renaming of SPI "master" to "controller" commit: 1245633c61baf159fcc1303d7f0855f49831b9c1 [06/33] media: mgb4: Follow renaming of SPI "master" to "controller" commit: 2c2f93fbfba7186cc081e23120f169eac3b5b62a [07/33] media: netup_unidvb: Follow renaming of SPI "master" to "controller" commit: cfa13a64bd631d8f04a1c385923706fcef9a63ed [08/33] media: usb/msi2500: Follow renaming of SPI "master" to "controller" commit: dd868ae646d5770f80f90dc056d06eb2e6d39c62 [09/33] media: v4l2-subdev: Follow renaming of SPI "master" to "controller" commit: d920b3a672b7f79cd13b341234aebd49233f836c [10/33] misc: gehc-achc: Follow renaming of SPI "master" to "controller" commit: 26dcf09ee5d9ceba2c627ae3ba174a229f25638f [11/33] mmc: mmc_spi: Follow renaming of SPI "master" to "controller" commit: b0a6776e53403aa380411f2a43cdefb9f00ff50a [12/33] mtd: dataflash: Follow renaming of SPI "master" to "controller" commit: 44ee998db9eef84bf005c39486566a67cb018354 [14/33] net: ks8851: Follow renaming of SPI "master" to "controller" commit: 1cc711a72ae7fd44e90839f0c8d3226664de55a2 [15/33] net: vertexcom: mse102x: Follow renaming of SPI "master" to "controller" commit: 7969b98b80c0332f940c547f84650a20aab33841 [16/33] platform/chrome: cros_ec_spi: Follow renaming of SPI "master" to "controller" commit: 85ad0ec049a771c4910c8aebb2d0bd9ce9311fd9 [17/33] spi: bitbang: Follow renaming of SPI "master" to "controller" commit: 2259233110d90059187c5ba75537eb93eba8417b [18/33] spi: cadence-quadspi: Don't emit error message on allocation error commit: e71011dacc3413bed4118d2c42f10736ffcd762c [19/33] spi: cadence-quadspi: Follow renaming of SPI "master" to "controller" commit: 28e59d8bf1ace0ddf05f989a48d6824d75731267 [20/33] spi: cavium: Follow renaming of SPI "master" to "controller" commit: 1747fbdedba8b6b3fd459895ed5d57e534549884 [21/33] spi: geni-qcom: Follow renaming of SPI "master" to "controller" commit: 14cea92338a0776c1615994150e738ac0f5fbb2c [22/33] spi: loopback-test: Follow renaming of SPI "master" to "controller" commit: 2c2310c17fac13aa7e78756d7f3780c7891f9397 [23/33] spi: slave-mt27xx: Follow renaming of SPI "master" to "controller" commit: 8197b136bbbe64a7cab1020a4b067020e5977d98 [24/33] spi: spidev: Follow renaming of SPI "master" to "controller" commit: d934cd6f0e5d0052772612db4b07df60cb9da387 [25/33] staging: fbtft: Follow renaming of SPI "master" to "controller" commit: bbd25d7260eeeaef89f7371cbadcd33dd7f7bff9 [26/33] staging: greybus: spi: Follow renaming of SPI "master" to "controller" commit: ee3c668dda3d2783b0fff4091461356fe000e4d8 [27/33] tpm_tis_spi: Follow renaming of SPI "master" to "controller" commit: b6af14eacc8814b0986e20507df423cebe9fd859 [28/33] usb: gadget: max3420_udc: Follow renaming of SPI "master" to "controller" commit: 8c716f4a3d4fcbec976247e3443d36cbc24c0512 [29/33] video: fbdev: mmp: Follow renaming of SPI "master" to "controller" commit: b23031e730e72ec9067b7c38c25e776c5e27e116 [30/33] wifi: libertas: Follow renaming of SPI "master" to "controller" commit: 30060d57cee194d6b70283f2faf787e2fdc61b6e [31/33] spi: fsl-lib: Follow renaming of SPI "master" to "controller" commit: 801185efa2402dce57828930e9684884fc8d62da [32/33] spi: Drop compat layer from renaming "master" to "controller" commit: 620d269f29a569ba37419cc03cf1da2d55f6252a [33/33] Documentation: spi: Update documentation for renaming "master" to "controller" commit: 76b31eb4c2da3ddb3195cc14f6aad24908adf524 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review
Re: [PATCH v3 00/32] spi: get rid of some legacy macros
On Wed, 07 Feb 2024 19:40:14 +0100, Uwe Kleine-König wrote: > Changes since v2 > (https://lore.kernel.org/linux-spi/cover.1705944943.git.u.kleine-koe...@pengutronix.de): > > - Drop patch "mtd: rawnand: fsl_elbc: Let .probe retry if local bus is >missing" which doesn't belong into this series. > - Fix a build failure noticed by the kernel build bot in >drivers/spi/spi-au1550.c. (I failed to catch this because this driver >is mips only, but not enabled in a mips allmodconfig. That's a bit >unfortunate, but not easily fixable.) > - Add the Reviewed-by: and Acked-by: tags I received for v2. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [01/32] fpga: ice40-spi: Follow renaming of SPI "master" to "controller" commit: 227ab73b89d66e3064b3c2bcb5fe382b1815763d [02/32] ieee802154: ca8210: Follow renaming of SPI "master" to "controller" commit: 167b78446706bb4d19f7dd93ca320aed25ae1bbd [03/32] iio: adc: ad_sigma_delta: Follow renaming of SPI "master" to "controller" commit: 2780e7b716a605781dbee753ef4983d775a65427 [04/32] Input: pxspad - follow renaming of SPI "master" to "controller" commit: a78acec53b8524593afeed7258a442adc3450818 [05/32] Input: synaptics-rmi4 - follow renaming of SPI "master" to "controller" commit: 1245633c61baf159fcc1303d7f0855f49831b9c1 [06/32] media: mgb4: Follow renaming of SPI "master" to "controller" commit: 2c2f93fbfba7186cc081e23120f169eac3b5b62a [07/32] media: netup_unidvb: Follow renaming of SPI "master" to "controller" commit: cfa13a64bd631d8f04a1c385923706fcef9a63ed [08/32] media: usb/msi2500: Follow renaming of SPI "master" to "controller" commit: dd868ae646d5770f80f90dc056d06eb2e6d39c62 [09/32] media: v4l2-subdev: Follow renaming of SPI "master" to "controller" commit: d920b3a672b7f79cd13b341234aebd49233f836c [10/32] misc: gehc-achc: Follow renaming of SPI "master" to "controller" commit: 26dcf09ee5d9ceba2c627ae3ba174a229f25638f [11/32] mmc: mmc_spi: Follow renaming of SPI "master" to "controller" commit: b0a6776e53403aa380411f2a43cdefb9f00ff50a [12/32] mtd: dataflash: Follow renaming of SPI "master" to "controller" commit: 44ee998db9eef84bf005c39486566a67cb018354 [13/32] net: ks8851: Follow renaming of SPI "master" to "controller" commit: 1cc711a72ae7fd44e90839f0c8d3226664de55a2 [14/32] net: vertexcom: mse102x: Follow renaming of SPI "master" to "controller" commit: 7969b98b80c0332f940c547f84650a20aab33841 [15/32] platform/chrome: cros_ec_spi: Follow renaming of SPI "master" to "controller" commit: 85ad0ec049a771c4910c8aebb2d0bd9ce9311fd9 [16/32] spi: bitbang: Follow renaming of SPI "master" to "controller" commit: 2259233110d90059187c5ba75537eb93eba8417b [17/32] spi: cadence-quadspi: Don't emit error message on allocation error commit: e71011dacc3413bed4118d2c42f10736ffcd762c [18/32] spi: cadence-quadspi: Follow renaming of SPI "master" to "controller" commit: 28e59d8bf1ace0ddf05f989a48d6824d75731267 [19/32] spi: cavium: Follow renaming of SPI "master" to "controller" commit: 1747fbdedba8b6b3fd459895ed5d57e534549884 [20/32] spi: geni-qcom: Follow renaming of SPI "master" to "controller" commit: 14cea92338a0776c1615994150e738ac0f5fbb2c [21/32] spi: loopback-test: Follow renaming of SPI "master" to "controller" commit: 2c2310c17fac13aa7e78756d7f3780c7891f9397 [22/32] spi: slave-mt27xx: Follow renaming of SPI "master" to "controller" commit: 8197b136bbbe64a7cab1020a4b067020e5977d98 [23/32] spi: spidev: Follow renaming of SPI "master" to "controller" commit: d934cd6f0e5d0052772612db4b07df60cb9da387 [24/32] staging: fbtft: Follow renaming of SPI "master" to "controller" commit: bbd25d7260eeeaef89f7371cbadcd33dd7f7bff9 [25/32] staging: greybus: spi: Follow renaming of SPI "master" to "controller" commit: ee3c668dda3d2783b0fff4091461356fe000e4d8 [26/32] tpm_tis_spi: Follow renaming of SPI "master" to "controller" commit: b6af14eacc8814b0986e20507df423cebe9fd859 [27/32] usb: gadget: max3420_udc: Follow renaming of SPI "master" to "controller" commit: 8c716f4a3d4fcbec976247e3443d36cbc24c0512 [28/32] video: fbdev: mmp: Follow renaming of SPI "master" to "controller" commit: b23031e730e72ec9067b7c38c25e776c5e27e116 [29/32] wifi: libertas: Follow renaming of SPI "master" to "controller" commit: 30060d57cee194d6b70283f2faf787e2fdc61b6e [30/32] spi: fsl-lib: Follow renaming of SPI "master" to "controller" commit: 801185efa2402dce57828930e9684884fc8d62da [31/32] spi: Drop compat layer from renaming "master" to "controller" commit: 620d269f29a569ba37419cc03cf1da2d55f6252a [32/32] Documentation: spi: Update documentation for renaming "master" to "controller" commit: 76b31eb4c2da3ddb3195cc14f6aad24908adf524 All being well this means that it will be integrated
Re: [PATCH v2 00/33] spi: get rid of some legacy macros
On Wed, Jan 24, 2024 at 09:13:49AM -0800, Greg Kroah-Hartman wrote: > On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote: > > Note that Jonathan Cameron has already applied patch 3 to his tree, it > > didn't appear in a public tree though yet. I still included it here to > > make the kernel build bots happy. > Are we supposed to take the individual changes in our different > subsystem trees, or do you want them all to go through the spi tree? Given that the final patch removes the legacy interfaces I'm expecting to take them via SPI. signature.asc Description: PGP signature
Re: [PATCH v2 00/33] spi: get rid of some legacy macros
On Mon, Jan 22, 2024 at 07:06:55PM +0100, Uwe Kleine-König wrote: > Note that Jonathan Cameron has already applied patch 3 to his tree, it > didn't appear in a public tree though yet. I still included it here to > make the kernel build bots happy. It's also going to be needed for buildability of the end of the series. signature.asc Description: PGP signature
Re: [PATCH 00/33] spi: get rid of some legacy macros
On Mon, Jan 15, 2024 at 09:12:46PM +0100, Uwe Kleine-König wrote:
> In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"")
> some functions were renamed. Further some compat defines were introduced
> to map the old names to the new ones.
> Patch #18 and #19 touch the same driver, otherwise the patches #1 - #31
> are pairwise independent and could be applied by their respective
> maintainers. The alternative is to let all patches go via the spi tree.
> Mark, what's your preference here?
I don't have a strong preference here, I'm happy to take all the patches
if the maintainers for the other subsystem are OK with that - ideally
I'd apply things at -rc1 but the timeline is a bit tight there. I think
my plan here unless anyone objects (or I notice something myself) will
be to queue things at -rc3, please shout if that doesn't seem
reasonable.
signature.asc
Description: PGP signature
Re: [PATCH v8 1/6] pwm: Rename pwm_apply_state() to pwm_apply_might_sleep()
On Tue, Dec 12, 2023 at 07:22:18AM -0800, Guenter Roeck wrote: > On 12/12/23 03:41, Uwe Kleine-König wrote: > > Several affected maintainers already acked, so I guess it's fine to take > > this via the pwm tree. An Ack from the remaining maintainers would be > > very welcome, an alternative would be to split the patch. > > Missing Acks so far: > > - Jean Delvare / Guenter Roeck for drivers/hwmon/pwm-fan.c > > - Javier Martinez Canillas for drivers/gpu/drm/solomon/ssd130x.c > > - Liam Girdwood / Mark Brown for drivers/regulator/pwm-regulator.c > > - Helge Deller for drivers/video/fbdev/ssd1307fb.c > Personally I find the change unnecessary and pointless, which is why I > didn't ack it. Even if function names were deemed important enough, keeping > pwm_apply_state() for the time being and just adding pwm_apply_might_sleep() > as duplicate would have done it, all the changes could have gone in long > ago, and per-subsystem cleanup could have been orthogonal. > I refrained from commenting because it might be considered bike shedding, > but I don't want to ack something I deem unnecessary and pointless without > comment. But then don't want to keep arguing either, so I haven't been reading this series because I couldn't tell why I was copied on it, it's only chance that made me open Guenter's mail here... Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH RESEND v2 1/3] drm/encoder: register per-encoder debugfs dir
On Sun, Dec 03, 2023 at 02:53:13PM +0300, Dmitry Baryshkov wrote: > Each of connectors and CRTCs used by the DRM device provides debugfs > directory, which is used by several standard debugfs files and can > further be extended by the driver. Add such generic debugfs directories > for encoder. Today's -next fails to boot an imx_v6_v7_defconfig on at least the UDOO dual and quad platforms, based on i.MX6DL and i.MX6Q respectively. multi_v7_defconfig looks fine on the same boards, it's just the i.MX specific config that's failing. Nothing else in my CI appears impacted. We get a NULL pointer defererence while bringing up the display subsystem: [1.392715] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops 0xc0f9a490) [1.400013] imx-drm display-subsystem: bound 12.hdmi (ops 0xc0f9af80) [1.407193] 8<--- cut here --- [1.410256] Unable to handle kernel NULL pointer dereference at virtual address 0010 when read ... [1.891882] drm_debugfs_encoder_add from drm_encoder_register_all+0x20/0x60 [1.898954] drm_encoder_register_all from drm_modeset_register_all+0x34/0x70 [1.906116] drm_modeset_register_all from drm_dev_register+0x140/0x288 [1.912765] drm_dev_register from imx_drm_bind+0xd0/0x128 [1.918284] imx_drm_bind from try_to_bring_up_aggregate_device+0x164/0x1c4 [1.925275] try_to_bring_up_aggregate_device from __component_add+0x90/0x13c Full log at: https://lava.sirena.org.uk/scheduler/job/308781 A bisect identfied this patch (in -next as caf525ed45b4960b4) as being the commit that introduced the issue, bisect log below. I've not done any other investigation but the commit does seem plausibly related to the backtrace in the oops. git bisect start # good: [cc1b39317a57120651840e79b535594ee09f5768] Merge branch 'for-linux-next-fixes' of git://anongit.freedesktop.org/drm/drm-misc git bisect good cc1b39317a57120651840e79b535594ee09f5768 # bad: [0f5f12ac05f36f117e793656c3f560625e927f1b] Add linux-next specific files for 20231205 git bisect bad 0f5f12ac05f36f117e793656c3f560625e927f1b # good: [8390406ed4d9d360bc404a5a3e9b82f335a8d417] Merge branch 'main' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git git bisect good 8390406ed4d9d360bc404a5a3e9b82f335a8d417 # bad: [b948f47bf8abdaf87f74c553b589c50567090aa2] Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git git bisect bad b948f47bf8abdaf87f74c553b589c50567090aa2 # bad: [dce94061f0d02f5ab355390a6e63d3dbea938b72] drm/v3d: Fix missing error code in v3d_submit_cpu_ioctl() git bisect bad dce94061f0d02f5ab355390a6e63d3dbea938b72 # good: [0d3abd456be45369235dd75793ce26f07900044c] drm/imagination: vm: fix drm_gpuvm reference count git bisect good 0d3abd456be45369235dd75793ce26f07900044c # good: [f52ffea0745943bb6af674f30f4243b3721b7cd6] drm/i915/iosf: Drop unused APIs git bisect good f52ffea0745943bb6af674f30f4243b3721b7cd6 # good: [b101d08451de6eaebd1a840e4885ce7ce73656ad] drm/nouveau: Removes unnecessary args check in nouveau_uvmm_sm_prepare git bisect good b101d08451de6eaebd1a840e4885ce7ce73656ad # good: [63ee44540205d993854f143a5ab1d7d9e63ffcf1] dma-buf/sync_file: Add SET_DEADLINE ioctl git bisect good 63ee44540205d993854f143a5ab1d7d9e63ffcf1 # good: [e4256751df4a0a3860f181588ee730dd19cb0c30] drm/display/dp: Add the remaining Square PHY patterns DPCD register definitions git bisect good e4256751df4a0a3860f181588ee730dd19cb0c30 # good: [2bcca96abfbf89d26fc10fc92e40532bb2ae8891] soc: qcom: pmic-glink: switch to DRM_AUX_HPD_BRIDGE git bisect good 2bcca96abfbf89d26fc10fc92e40532bb2ae8891 # bad: [b881ba8faa5c7689eb1cb487ad891c46dbbed0e8] Revert "drm/atomic: Move framebuffer checks to helper" git bisect bad b881ba8faa5c7689eb1cb487ad891c46dbbed0e8 # bad: [caf525ed45b4960b450cbd4e811d9b247bc2586c] drm/encoder: register per-encoder debugfs dir git bisect bad caf525ed45b4960b450cbd4e811d9b247bc2586c # good: [7d9f1b72b29698e3030c2b163522cf4aa91b47e9] usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE git bisect good 7d9f1b72b29698e3030c2b163522cf4aa91b47e9 # first bad commit: [caf525ed45b4960b450cbd4e811d9b247bc2586c] drm/encoder: register per-encoder debugfs dir signature.asc Description: PGP signature
Re: [PATCH 15/22] arch: vdso: consolidate gettime prototypes
On Wed, Nov 08, 2023 at 01:58:36PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The VDSO functions are defined as globals in the kernel sources but intended
> to be called from userspace, so there is no need to declare them in a kernel
> side header.
This is in -next as commit 42874e4eb35bdfc54f8514685e50434098ba4f6c and
breaks an arm64 defconfig build, the 32 bit vDSO build is broken:
/build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.c:10:5: error: conflic
ting types for ‘__vdso_clock_gettime’; have ‘int(clockid_t, struct old_timespec
32 *)’ {aka ‘int(int, struct old_timespec32 *)’}
10 | int __vdso_clock_gettime(clockid_t clock,
| ^~~~
In file included from /build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.
c:8:
/build/stage/linux/include/vdso/gettime.h:16:5: note: previous declaration of
‘__vdso_clock_gettime’ with type ‘int(clockid_t, struct __kernel_timespec *)’
{aka ‘int(int, struct __kernel_timespec *)’}
16 | int __vdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts);
| ^~~~
/build/stage/linux/arch/arm64/kernel/vdso32/vgettimeofday.c:28:5: error:
conflicting types for ‘__vdso_clock_getres’; have ‘int(clockid_t, struct
old_timespec32 *)’ {aka ‘int(int, struct old_timespec32 *)’}
28 | int __vdso_clock_getres(clockid_t clock_id,
| ^~~
/build/stage/linux/include/vdso/gettime.h:15:5: note: previous declaration of
‘__vdso_clock_getres’ with type ‘int(clockid_t, struct __kernel_timespec *)’
{aka ‘int(int, struct __kernel_timespec *)’}
15 | int __vdso_clock_getres(clockid_t clock, struct __kernel_timespec *res);
| ^~~
signature.asc
Description: PGP signature
Re: [PATCH 11/17] ASoC: dt-bindings: samsung-i2s: add specific compatibles for existing SoC
On Wed, Nov 08, 2023 at 11:43:37AM +0100, Krzysztof Kozlowski wrote: > Samsung Exynos SoC reuses several devices from older designs, thus > historically we kept the old (block's) compatible only. This works fine > and there is no bug here, however guidelines expressed in > Documentation/devicetree/bindings/writing-bindings.rst state that: Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH] drm/bridge: adv7511: Convert to use maple tree register cache
On Sat, Sep 30, 2023 at 12:38:17AM +0300, Laurent Pinchart wrote: > Out of curiosity, is this part of an effort to drop the rbtree cache ? Probably, yes - there's probably some drivers where it will make sense. signature.asc Description: PGP signature
[PATCH] drm/bridge: sn65dsi83: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 061e8bd5915d..4814b7b6d1fd 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -233,7 +233,7 @@ static const struct regmap_config sn65dsi83_regmap_config =
{
.rd_table = _readable_table,
.wr_table = _writeable_table,
.volatile_table = _volatile_table,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = REG_IRQ_STAT,
};
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-sn65dsi83-maple-f15042b93dcd
Best regards,
--
Mark Brown
[PATCH] drm/bridge: lt9211: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/lontium-lt9211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9211.c
b/drivers/gpu/drm/bridge/lontium-lt9211.c
index 4d404f5ef87e..c8881796fba4 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9211.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9211.c
@@ -89,7 +89,7 @@ static const struct regmap_config lt9211_regmap_config = {
.volatile_table = _rw_table,
.ranges = _range,
.num_ranges = 1,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = 0xda00,
};
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-lt9211-maple-f2b0807acd53
Best regards,
--
Mark Brown
[PATCH 2/2] drm/panel: ili9322: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index 15b81e5228b5..4a6dcfd781e8 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -337,7 +337,7 @@ static const struct regmap_config ili9322_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
.max_register = 0x44,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.writeable_reg = ili9322_writeable_reg,
};
--
2.39.2
[PATCH 0/2] drm/panel: ili9322: Minor regmap improvements
These two patches provide some minor improvements to the ili9322 regmap API usage. Signed-off-by: Mark Brown --- Mark Brown (2): drm/panel: ili9322: Remove redundant volatle_reg() operation drm/panel: ili9322: Convert to use maple tree register cache drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) --- base-commit: 6465e260f48790807eef06b583b38ca9789b6072 change-id: 20230929-drm-sn65dsi83-maple-f15042b93dcd Best regards, -- Mark Brown
[PATCH 1/2] drm/panel: ili9322: Remove redundant volatle_reg() operation
The ili9322 driver has a volatile_reg() operation in it's regmap which
always returns false. This is redundant since it is the default in the
regmap core, remove the operation for a trivial code size and performance
improvement.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
index 61c872f0f7ca..15b81e5228b5 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9322.c
@@ -325,11 +325,6 @@ static struct regmap_bus ili9322_regmap_bus = {
.val_format_endian_default = REGMAP_ENDIAN_BIG,
};
-static bool ili9322_volatile_reg(struct device *dev, unsigned int reg)
-{
- return false;
-}
-
static bool ili9322_writeable_reg(struct device *dev, unsigned int reg)
{
/* Just register 0 is read-only */
@@ -343,7 +338,6 @@ static const struct regmap_config ili9322_regmap_config = {
.val_bits = 8,
.max_register = 0x44,
.cache_type = REGCACHE_RBTREE,
- .volatile_reg = ili9322_volatile_reg,
.writeable_reg = ili9322_writeable_reg,
};
--
2.39.2
[PATCH] drm/bridge: icn6211: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/chipone-icn6211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c
b/drivers/gpu/drm/bridge/chipone-icn6211.c
index d205e755e524..82d23e4df09e 100644
--- a/drivers/gpu/drm/bridge/chipone-icn6211.c
+++ b/drivers/gpu/drm/bridge/chipone-icn6211.c
@@ -197,7 +197,7 @@ static const struct regmap_config chipone_regmap_config = {
.val_bits = 8,
.rd_table = _dsi_readable_table,
.wr_table = _dsi_writeable_table,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.max_register = MIPI_ATE_STATUS(1),
};
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-chipone-maple-1d5e37ce5ed0
Best regards,
--
Mark Brown
[PATCH] drm/bridge: tc358767: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/tc358767.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index b45bffab7c81..ef2e373606ba 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -2005,7 +2005,7 @@ static const struct regmap_config tc_regmap_config = {
.val_bits = 32,
.reg_stride = 4,
.max_register = PLL_DBG,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.readable_reg = tc_readable_reg,
.volatile_table = _volatile_table,
.writeable_reg = tc_writeable_reg,
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-tc358767-maple-db143f667958
Best regards,
--
Mark Brown
[PATCH] drm/rockchip: vop2: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 583df4d22f7e..9f4470171cf4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -2641,7 +2641,7 @@ static const struct regmap_config vop2_regmap_config = {
.max_register = 0x3000,
.name = "vop2",
.volatile_table = _volatile_table,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
};
static int vop2_bind(struct device *dev, struct device *master, void *data)
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-rockchip-maple-f6253d6a422e
Best regards,
--
Mark Brown
[PATCH] drm/bridge: dpc3433: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/ti-dlpc3433.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-dlpc3433.c
b/drivers/gpu/drm/bridge/ti-dlpc3433.c
index b65632ec7e7d..ca3348109bcd 100644
--- a/drivers/gpu/drm/bridge/ti-dlpc3433.c
+++ b/drivers/gpu/drm/bridge/ti-dlpc3433.c
@@ -100,7 +100,7 @@ static struct regmap_config dlpc_regmap_config = {
.max_register = WR_DSI_PORT_EN,
.writeable_noinc_reg= dlpc_writeable_noinc_reg,
.volatile_table = _volatile_table,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.name = "dlpc3433",
};
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-dlpc3433-maple-7e76ba8e59be
Best regards,
--
Mark Brown
[PATCH] drm/bridge: adv7511: Convert to use maple tree register cache
The maple tree register cache is based on a much more modern data structure
than the rbtree cache and makes optimisation choices which are probably
more appropriate for modern systems than those made by the rbtree cache.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 2611afd2c1c1..d518de88b5c3 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -121,7 +121,7 @@ static const struct regmap_config adv7511_regmap_config = {
.val_bits = 8,
.max_register = 0xff,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.reg_defaults_raw = adv7511_register_defaults,
.num_reg_defaults_raw = ARRAY_SIZE(adv7511_register_defaults),
@@ -1068,7 +1068,7 @@ static const struct regmap_config
adv7511_cec_regmap_config = {
.val_bits = 8,
.max_register = 0xff,
- .cache_type = REGCACHE_RBTREE,
+ .cache_type = REGCACHE_MAPLE,
.volatile_reg = adv7511_cec_register_volatile,
};
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230929-drm-adv7511-2d592921f8a2
Best regards,
--
Mark Brown
Re: (subset) [PATCH 00/31] Fix and improve Rockchip RK3128 support
On Tue, 29 Aug 2023 19:16:16 +0200, Alex Bee wrote: > this series fixes some issues I found when testing my "new" RK3128 board > with the mainline kernel and adds some core functionality like SMP bringup, > usb and networking. > > The propably most distinctive change is the split up of the DTs for the > different SoCs of this platform: RK3126 and RK3128. Even if I'm not adding > a RK3126 board in this series: I think this change should be done as early > as possible in order to avoid issues in future. > Actually it should have been done like that in the first place. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [03/31] dt-bindings: ASoC: rockchip: Add compatible for RK3128 spdif commit: 5c8a033f5674ae62d5aa2ebbdb9980b89380c34f All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] spi: tegra: Fix missing IRQ check in tegra_slink_probe()
On Sat, 26 Aug 2023 18:02:54 +0800, Zhang Shurong wrote: > This func misses checking for platform_get_irq()'s call and may passes the > negative error codes to request_irq(), which takes unsigned IRQ #, > causing it to fail with -EINVAL, overriding an original error code. > > Fix this by stop calling request_irq() with invalid IRQ #s. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: tegra: Fix missing IRQ check in tegra_slink_probe() commit: eb9913b511f10968a02cfa5329a896855dd152a3 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: (subset) [PATCH 00/11] add missing of_node_put
On Thu, 07 Sep 2023 11:55:10 +0200, Julia Lawall wrote: > Add of_node_put on a break out of an of_node loop. > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [10/11] ASoC: rsnd: add missing of_node_put commit: 28115b1c4f2bb76e786436bf6597c5eb27638a5c All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] iommu: Remove the device_lock_assert() from __iommu_probe_device()
On Fri, Aug 18, 2023 at 06:32:28PM -0300, Jason Gunthorpe wrote: > It turns out several drivers are calling of_dma_configure() outside the > expected bus_type.dma_configure op. This ends up being mis-locked and > triggers a lockdep assertion, or instance: Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [v3 2/3] ASoC: mediatek: mt8186: correct the HDMI widgets
On Thu, Aug 03, 2023 at 07:20:15AM +, Jiaxin Yu (俞家鑫) wrote: > I agree with you, in fact the speaker is indeed doing this way. But > about the hdmi that on the board, I did not find a defination link > snd_soc_dapm_hdmi, so I use snd_soc_dapm_line to replace. The purpose > is to control it link speaker. Or what do you suggest I should do? I think the sensible thing here is to define a DIGITAL_OUTPUT() which can be used for HDMI, S/PDIF and anything else that comes up and isn't clearly wrong like reusing one of the analog descriptions is. signature.asc Description: PGP signature
Re: [v3 2/3] ASoC: mediatek: mt8186: correct the HDMI widgets
On Wed, Aug 02, 2023 at 02:52:57PM +, Jiaxin Yu (俞家鑫) wrote:
> On Mon, 2023-07-31 at 12:50 +0100, Mark Brown wrote:
> > On Mon, Jul 31, 2023 at 02:08:02AM +0800, Jiaxin Yu wrote:
> > > Use SND_SOC_DAPM_LINE instead of SND_SOC_DAPM_OUTPUT to trigger
> > > DAPM events to hdmi-codec when userspace control the DPAM pin.
> > Why?
> I have defined an SOC_DAPM_PIN_SWITCH that named as "HDMI1", if I use
> SND_SOC_DAPM_OUTPUT, it can't be controlled by HDMI1's PIN_SWITCH.
...
> 2762 if (w->dapm->card->fully_routed)
> 2763 return;
> 2764 ep = SND_SOC_DAPM_EP_SINK;
> 2765 snd_soc_dapm_widget_for_each_sink_path(w, p) {
> 2766 if (p->sink->id == snd_soc_dapm_spk ||
> 2767 p->sink->id == snd_soc_dapm_hp ||
> 2768 p->sink->id == snd_soc_dapm_line
> ||
> 2769 p->sink->id == snd_soc_dapm_input)
> {
> 2770 ep = 0;
The expectation here is that you'll connect the output to a widget that
corresponds to the physical output on your board and put the pin switch
on that, ideally with a label that corresponds to case markings or what
the physical output is called on the board.
signature.asc
Description: PGP signature
Re: [v3 2/3] ASoC: mediatek: mt8186: correct the HDMI widgets
On Mon, Jul 31, 2023 at 02:08:02AM +0800, Jiaxin Yu wrote: > Use SND_SOC_DAPM_LINE instead of SND_SOC_DAPM_OUTPUT to trigger > DAPM events to hdmi-codec when userspace control the DPAM pin. Why? signature.asc Description: PGP signature
Re: (subset) [PATCH v3 0/4] Qualcomm REFGEN regulator
On Mon, 03 Jul 2023 20:15:53 +0200, Konrad Dybcio wrote: > Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator > responsible for providing a reference voltage to some on-SoC IPs (like DSI > or PHYs). It can be turned off when unused to save power. > > This series introduces the driver for it and lets the DSI driver > consume it. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [1/4] dt-bindings: regulator: Describe Qualcomm REFGEN regulator commit: d16db38c2a66060ee25c6b86ee7b6d66d40fc8e0 [2/4] regulator: Introduce Qualcomm REFGEN regulator driver commit: 7cbfbe23796086fdb72b681e2c182b02acd36a04 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v3 0/4] Qualcomm REFGEN regulator
On Mon, Jul 03, 2023 at 08:15:53PM +0200, Konrad Dybcio wrote: > Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator > responsible for providing a reference voltage to some on-SoC IPs (like DSI > or PHYs). It can be turned off when unused to save power. > > This series introduces the driver for it and lets the DSI driver > consume it. What's the expected plan for merging this - should I be applying the DRM patch? signature.asc Description: PGP signature
Re: [PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator driver
On Thu, Jun 29, 2023 at 10:44:34PM +0200, Konrad Dybcio wrote: > On 29.06.2023 22:35, Konrad Dybcio wrote: > > Modern Qualcomm SoCs have a REFGEN (reference voltage generator) > > regulator, providing reference voltage to on-chip IP, like PHYs. > > > > Add a driver to support toggling that regulator. > > > > Signed-off-by: Konrad Dybcio > > --- > Ugh. Missed the 'const' here and below. LMK if that warrants a resend > (or.. perhaps you just have other comments) Please, there was a build error anyway. signature.asc Description: PGP signature
Re: [PATCH 2/4] regulator: Introduce Qualcomm REFGEN regulator driver
On Wed, Jun 28, 2023 at 06:29:46PM +0200, Konrad Dybcio wrote:
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2017, 2019-2020, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2023, Linaro Limited
> + */
Please use a C++ comment for the whole thing for consistency.
> +static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
> +{
> + struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
> +
> + regmap_update_bits(vreg->base, REFGEN_REG_BG_CTRL,
> +REFGEN_BG_CTRL_MASK, REFGEN_BG_CTRL_ENABLE);
> + regmap_write(vreg->base, REFGEN_REG_BIAS_EN, REFGEN_BIAS_EN_ENABLE);
For the enable and disable operations we use a mix of _update_bits() and
absolute writes with no FIELD_PREP()...
> +static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
> +{
> + struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
> + u32 val;
> +
> + regmap_read(vreg->base, REFGEN_REG_BG_CTRL, );
> + if (FIELD_GET(REFGEN_BG_CTRL_MASK, val) != REFGEN_BG_CTRL_ENABLE)
> + return 0;
> +
> + regmap_read(vreg->base, REFGEN_REG_BIAS_EN, );
> + if (FIELD_GET(REFGEN_BIAS_EN_MASK, val) != REFGEN_BIAS_EN_ENABLE)
> + return 0;
...but when we read back the status we use FIELD_GET(). This looks like
a bug, and given that one of the fields starts at bit 1 it presumably is
one - FIELD_GET() will do shifting.
> +static int qcom_sm8250_refgen_enable(struct regulator_dev *rdev)
> +{
> + struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
> +
> + regmap_update_bits(vreg->base, REFGEN_REG_PWRDWN_CTRL5,
> +REFGEN_PWRDWN_CTRL5_MASK,
> REFGEN_PWRDWN_CTRL5_ENABLE);
This is a single bit in a single register so could use the standard
helpers rather than open coding, the sdm845 does need custom operations
due to having two fields to manage.
signature.asc
Description: PGP signature
Re: linux-next: manual merge of the drm-misc tree with the mm-stable tree
On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > Note there was a ppc compile fail, which is why we pushed the ttm revert. > That /should/ be fixed now, but would be good if you can confirm? According to Nathan (CCed) there's still issues with the interaction with the PowerPC tree. signature.asc Description: PGP signature
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Tue, Apr 18, 2023 at 11:21:45AM -0700, Nathan Chancellor wrote: > On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote: > > Done. > Thanks a lot, sorry for not saying it sooner! It looks like this > regressed in next-20230417 and next-20230418 though. Someone sent a mail saying they thought they'd fixed the DRM tree - is that not the case? signature.asc Description: PGP signature
Re: linux-next: manual merge of the drm-misc tree with the mm-stable tree
On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > Note there was a ppc compile fail, which is why we pushed the ttm revert. > That /should/ be fixed now, but would be good if you can confirm? I don't have any PowerPC toolchains set up - I guess one of the community builders might have checked? signature.asc Description: PGP signature
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Thu, Apr 13, 2023 at 11:47:25AM -0700, Nathan Chancellor wrote: > On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote: > select SND_HDA_COMPONENT if SND_HDA_CORE > # !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752 > - select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > KERNEL_MODE_NEON && !CC_IS_CLANG)) > + select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > KERNEL_MODE_NEON && !CC_IS_CLANG)) > help > Choose this option if you want to use the new display engine > support for AMDGPU. This adds required support for Vega and > Please consider resolving this in a future -next update, I was rather > surprised that my AMD test machine's graphical output was not working > until I noticed the configuration difference :) Done. signature.asc Description: PGP signature
Re: [PATCH v3 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
On Wed, Apr 05, 2023 at 05:17:21PM +0200, Maxime Ripard wrote: > On Tue, Apr 04, 2023 at 04:26:18PM +0100, Mark Brown wrote: > > To be honest it's surprising that we'd have to manually specify this, I > > would expect to be able to reparent. I suspect it'd be better to go the > > other way here and allow reparenting. > Yeah, I think I'd prefer to allow reparenting too, but as can be seen > from the other reviewers in that thread, it seems like we have a very > split community here, so that doesn't sound very realistic without some > major pushback :) For these ASoC drivers I think we should just do the reparenting, they're very much at the leaf of the tree so the considerations that make it a problem sometimes are unlikely to apply. signature.asc Description: PGP signature
Re: [PATCH v3 64/65] ASoC: tlv320aic32x4: div: Switch to determine_rate
On Tue, Apr 04, 2023 at 12:11:54PM +0200, Maxime Ripard wrote: > The driver does implement round_rate() though, which means that we can > change the rate of the clock, but we will never get to change the > parent. > However, It's hard to tell whether it's been done on purpose or not. > Since we'll start mandating a determine_rate() implementation, let's > convert the round_rate() implementation to a determine_rate(), which > will also make the current behavior explicit. And if it was an > oversight, the clock behaviour can be adjusted later on. Similar comments to the other patch, I'm pretty sure this is just surprising design on the part of the clock API and we should just allow reparenting. signature.asc Description: PGP signature
Re: [PATCH v3 63/65] ASoC: tlv320aic32x4: pll: Switch to determine_rate
On Tue, Apr 04, 2023 at 12:11:53PM +0200, Maxime Ripard wrote: > The driver does implement round_rate() though, which means that we can > change the rate of the clock, but we will never get to change the > parent. > However, It's hard to tell whether it's been done on purpose or not. > Since we'll start mandating a determine_rate() implementation, let's > convert the round_rate() implementation to a determine_rate(), which > will also make the current behavior explicit. And if it was an > oversight, the clock behaviour can be adjusted later on. Similar comments to the other patch, I'm pretty sure this is just surprising design on the part of the clock API and we should just allow reparenting. signature.asc Description: PGP signature
Re: [PATCH v3 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
On Tue, Apr 04, 2023 at 12:11:33PM +0200, Maxime Ripard wrote: > The tlv320aic32x4 clkin clock implements a mux with a set_parent hook, > but doesn't provide a determine_rate implementation. > This is a bit odd, since set_parent() is there to, as its name implies, > change the parent of a clock. However, the most likely candidate to > trigger that parent change is a call to clk_set_rate(), with > determine_rate() figuring out which parent is the best suited for a > given rate. > The other trigger would be a call to clk_set_parent(), but it's far less > used, and it doesn't look like there's any obvious user for that clock. It could be configured from device tree as well couldn't it? > So, the set_parent hook is effectively unused, possibly because of an > oversight. However, it could also be an explicit decision by the > original author to avoid any reparenting but through an explicit call to > clk_set_parent(). Historically clk_set_rate() wouldn't reparent IIRC. > The latter case would be equivalent to setting the flag > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > to __clk_mux_determine_rate(). Indeed, if no determine_rate > implementation is provided, clk_round_rate() (through > clk_core_round_rate_nolock()) will call itself on the parent if > CLK_SET_RATE_PARENT is set, and will not change the clock rate > otherwise. __clk_mux_determine_rate() has the exact same behavior when > CLK_SET_RATE_NO_REPARENT is set. > And if it was an oversight, then we are at least explicit about our > behavior now and it can be further refined down the line. To be honest it's surprising that we'd have to manually specify this, I would expect to be able to reparent. I suspect it'd be better to go the other way here and allow reparenting. signature.asc Description: PGP signature
Re: [PATCH v3] ASoC: dt-bindings: maxim,max98371: Convert to DT schema
On Sat, 01 Apr 2023 15:19:29 -0300, André Morishita wrote: > Convert the Maxim Integrated MAX98371 audio codec bindings to DT schema. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: dt-bindings: maxim,max98371: Convert to DT schema commit: 5781c22ea87700cd1da8f8de8a82fc10ef2f14d2 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: stable-rc/linux-5.10.y bisection: baseline.login on hp-x360-14-G1-sona
On Tue, Mar 21, 2023 at 05:18:03AM -0700, KernelCI bot wrote:
The KernelCI bisection bot found a boot bisection on one of the HP
ChromeBooks in v5.10.175 triggered by b5005605013d ("drm/i915: Don't use
BAR mappings for ring buffers with LLC"). The system appears to die
very early in boot with no output.
I've left the full report from the bot below, including links to full
boot logs such as they are and a tag for the bot, and the full web
dashboard for the test case fail is at:
https://linux.kernelci.org/test/plan/id/64147346939869e04b8c8694/
including details of the successful test on v5.10.174.
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> stable-rc/linux-5.10.y bisection: baseline.login on hp-x360-14-G1-sona
>
> Summary:
> Start: de26e1b2103b Linux 5.10.175
> Plain log:
> https://storage.kernelci.org/stable-rc/linux-5.10.y/v5.10.175/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.txt
> HTML log:
> https://storage.kernelci.org/stable-rc/linux-5.10.y/v5.10.175/x86_64/x86_64_defconfig+x86-chromebook/gcc-10/lab-collabora/baseline-hp-x360-14-G1-sona.html
> Result: b5005605013d drm/i915: Don't use BAR mappings for ring buffers
> with LLC
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: stable-rc
> URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Branch: linux-5.10.y
> Target: hp-x360-14-G1-sona
> CPU arch: x86_64
> Lab:lab-collabora
> Compiler: gcc-10
> Config: x86_64_defconfig+x86-chromebook
> Test case: baseline.login
>
> Breaking commit found:
>
> ---
> commit b5005605013d30ab27c303cbaeff60b7872234a3
> Author: John Harrison
> Date: Wed Feb 15 17:11:01 2023 -0800
>
> drm/i915: Don't use BAR mappings for ring buffers with LLC
>
> commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
>
> Direction from hardware is that ring buffers should never be mapped
> via the BAR on systems with LLC. There are too many caching pitfalls
> due to the way BAR accesses are routed. So it is safest to just not
> use it.
>
> Signed-off-by: John Harrison
> Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: intel-...@lists.freedesktop.org
> Cc: # v4.9+
> Tested-by: Jouni Högander
> Reviewed-by: Daniele Ceraolo Spurio
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
> (cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
> Signed-off-by: Jani Nikula
> Signed-off-by: John Harrison
> Signed-off-by: Greg Kroah-Hartman
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c
> b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 4034a4bac7f0..69b2e5509d67 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -49,7 +49,7 @@ int intel_ring_pin(struct intel_ring *ring, struct
> i915_gem_ww_ctx *ww)
> if (unlikely(ret))
> goto err_unpin;
>
> - if (i915_vma_is_map_and_fenceable(vma))
> + if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
> addr = (void __force *)i915_vma_pin_iomap(vma);
> else
> addr = i915_gem_object_pin_map(vma->obj,
> @@ -91,7 +91,7 @@ void intel_ring_unpin(struct intel_ring *ring)
> return;
>
> i915_vma_unset_ggtt_write(vma);
> - if (i915_vma_is_map_and_fenceable(vma))
> + if (i915_vma_is_map_and_fenceable(vma) && !HAS_LLC(vma->vm->i915))
> i915_vma_unpin_iomap(vma);
> else
> i915_gem_object_unpin_map(vma->obj);
> ---
>
>
> Git bisection log:
>
> ---
> git bisect start
> # good: [955623617f2f505ac08d0efda2bb50c1a52e2c96] Linux 5.10.174
> git bisect good 955623617f2f505ac08d0efda2bb50c1a52e2c96
> # bad:
Re: [PATCH] dt-bindings: yamllint: Require a space after a comment '#'
On Fri, Mar 03, 2023 at 03:42:23PM -0600, Rob Herring wrote: > Enable yamllint to check the prefered commenting style of requiring a > space after a comment character '#'. Fix the cases in the tree which > have a warning with this enabled. Most cases just need a space after the > '#'. A couple of cases with comments which were not intended to be > comments are revealed. Those were in ti,sa2ul.yaml, ti,cal.yaml, and > brcm,bcmgenet.yaml. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: Fix SPI and I2C bus node names in examples
On Tue, Feb 28, 2023 at 03:54:33PM -0600, Rob Herring wrote: > SPI and I2C bus node names are expected to be "spi" or "i2c", > respectively, with nothing else, a unit-address, or a '-N' index. A > pattern of 'spi0' or 'i2c0' or similar has crept in. Fix all these > cases. Mostly scripted with the following commands: Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH] tree-wide: trivial: s/ a SPI/ an SPI/
On Fri, Feb 03, 2023 at 11:28:03AM +0100, Geert Uytterhoeven wrote: > On Fri, Feb 3, 2023 at 11:17 AM Tudor Ambarus > wrote: > > The deciding factor for when a/an should be used is the sound > > that begins the word which follows these indefinite articles, > > rather than the letter which does. Use "an SPI" (SPI begins > > with the consonant letter S, but the S is pronounced with its > > letter name, "es."). > While I agree with your pronunciation, I believe the SPI maintainer > (which you forgot to CC) pronounces it in James Bond-style, i.e. rhymes > with "spy" ;-) Yes, I do. To the best of my knowledge most people just say "spy" rather than pronouncing the letters or anything. In any case as I said in reply to one of the individual patches English isn't regular enough to go with hard and fast rules on anything, and the letter rule is much more commonly used where something is needed. Using an here looks wrong to me, and the fact that a is so widely used does suggest that usage has escaped whatever rule there is. signature.asc Description: PGP signature
Re: (subset) [PATCH v2 00/13] spi: Add support for stacked/parallel memories
On Fri, 20 Jan 2023 00:23:29 +0530, Amit Kumar Mahapatra wrote:
> This patch is in the continuation to the discussions which happened on
> 'commit f89504300e94 ("spi: Stacked/parallel memories bindings")' for
> adding dt-binding support for stacked/parallel memories.
>
> This patch series updated the spi-nor, spi core and the spi drivers
> to add stacked and parallel memories support.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[01/13] spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod
commit: 303feb3cc06ac0665d0ee9c1414941200e60e8a3
[02/13] spi: Replace all spi->chip_select and spi->cs_gpiod references with
function call
(no commit info)
[03/13] net: Replace all spi->chip_select and spi->cs_gpiod references with
function call
(no commit info)
[04/13] iio: imu: Replace all spi->chip_select and spi->cs_gpiod references
with function call
(no commit info)
[05/13] mtd: devices: Replace all spi->chip_select and spi->cs_gpiod references
with function call
(no commit info)
[06/13] staging: Replace all spi->chip_select and spi->cs_gpiod references with
function call
(no commit info)
[07/13] platform/x86: serial-multi-instantiate: Replace all spi->chip_select
and spi->cs_gpiod references with function call
(no commit info)
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
Re: [PATCH v2 02/13] spi: Replace all spi->chip_select and spi->cs_gpiod references with function call
On Fri, Jan 20, 2023 at 12:23:31AM +0530, Amit Kumar Mahapatra wrote: > Supporting multi-cs in spi drivers would require the chip_select & cs_gpiod > members of struct spi_device to be an array. But changing the type of these > members to array would break the spi driver functionality. To make the > transition smoother introduced four new APIs to get/set the > spi->chip_select & spi->cs_gpiod and replaced all spi->chip_select and > spi->cs_gpiod references with get or set API calls. > While adding multi-cs support in further patches the chip_select & cs_gpiod > members of the spi_device structure would be converted to arrays & the > "idx" parameter of the APIs would be used as array index i.e., > spi->chip_select[idx] & spi->cs_gpiod[idx] respectively. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature
Re: (subset) [PATCH 00/35] Documentation: correct lots of spelling errors (series 1)
On Thu, 26 Jan 2023 22:39:30 -0800, Randy Dunlap wrote: > Correct many spelling errors in Documentation/ as reported by codespell. > > Maintainers of specific kernel subsystems are only Cc-ed on their > respective patches, not the entire series. [if all goes well] > > These patches are based on linux-next-20230125. > > [...] Applied to broonie/spi.git for-next Thanks! [27/35] Documentation: spi: correct spelling commit: 0f6d2cee58f1ff2ebf66f0bceb113d79f66ecb07 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH] dt-bindings: Add missing (unevaluated|additional)Properties on child node schemas
On Tue, Jan 24, 2023 at 05:02:28PM -0600, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present. > > Add unevaluatedProperties or additionalProperties as appropriate, and > then add any missing properties flagged by the addition. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: [PATCH] dt-bindings: Add missing (unevaluated|additional)Properties on child node schemas
On Tue, Jan 24, 2023 at 05:00:48PM -0600, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present. > > Add unevaluatedProperties or additionalProperties as appropriate, and > then add any missing properties flagged by the addition. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: (subset) [PATCH v2 00/27] ARM: pxa: remove all unused boards
On Thu, 05 Jan 2023 14:45:55 +0100, Arnd Bergmann wrote: > Most of the legacy PXA board files were marked as unused in linux-5.19 and > can get removed in linux-6.3. There is support for pxa250/pxa270/pxa300 > using devicetree already, which supports a number of boards, but progress > on converting the remaining ones has stalled over the past few years. > > The two boards that are left in the tree for now are the three 'sharpsl' > variants (spitz/akita/borzoi) and the 'gumstix' family of machines. > Both of these are supported by qemu, which can be helpful for completing > the DT conversion. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [14/27] ASoC: PXA: make SND_PXA2XX_SOC_AC97 user-selectable commit: 5eab9265759e2fb042aa452931c3d06ab7ab8dae [15/27] ASoC: pxa: remove unused board support (no commit info) All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: next-20230110: arm64: defconfig+kselftest config boot failed - Unable to handle kernel paging request at virtual address fffffffffffffff8
On Wed, Jan 11, 2023 at 12:29:04PM +, Mark Brown wrote:
> We're seeing issues in all configs on meson-gxl-s905x-libretech-cc
> today, not just with the kselftest fragment. The initial failuire seems
> to be:
> [ 17.337253] WARNING: CPU: 3 PID: 123 at drivers/gpu/drm/drm_bridge.c:1257
> drm_bridge_hpd_enable+0x8c/0x94 [drm]
> full log at:
>
> https://storage.kernelci.org/next/master/next-20230111/arm64/defconfig/gcc-10/lab-broonie/baseline-meson-gxl-s905x-libretech-cc.txt
> and links to other logs at:
>
> https://linux.kernelci.org/test/job/next/branch/master/kernel/next-20230111/plan/baseline/
> Today's -next does have that fix in it so it's not fixing whatever the
> original issue was, I suspect it might even be exposing other issues.
> We are however still seeing the stack filling up, even with a GCC 10
> defconfig build.
A bisect landed on 0e4dcffd331fa7d ("drm/panel: raspberrypi-touchscreen:
Convert to i2c's .probe_new()") which is obviously not credible. I
suspect that what's happening here is that the fix you applied is making
an issue somewhere else visible in defconfig and is as a result
confusing the bisect. Ard mentioned an issue with non-EFI biits
introduced by EFI changes here:
https://lore.kernel.org/linux-arm-kernel/CAMj1kXGFa=zriyp_ms7bbqr0wiwikt0objokusngpjtfvlm...@mail.gmail.com/
which seems like a plausible culprit,
bisect log:
git bisect start
# bad: [c9e9cdd8bdcc3e1ea330d49ea587ec71884dd0f5] Add linux-next specific files
for 20230111
git bisect bad c9e9cdd8bdcc3e1ea330d49ea587ec71884dd0f5
# good: [7dd4b804e08041ff56c88bdd8da742d14b17ed25] Merge tag 'nfsd-6.2-3' of
git://git.kernel.org/pub/scm/linux/kernel/git/cel/linux
git bisect good 7dd4b804e08041ff56c88bdd8da742d14b17ed25
# good: [ecf8827ab7dd5731813f90146d9936165b170f32] Merge branch 'drm-next' of
git://git.freedesktop.org/git/drm/drm.git
git bisect good ecf8827ab7dd5731813f90146d9936165b170f32
# bad: [64208e4940ede76709f1ff5b01d1b78efc2951cf] Merge branch 'rcu/next' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
git bisect bad 64208e4940ede76709f1ff5b01d1b78efc2951cf
# bad: [1077dd31ba60b39a231560beec24b97eadf8bd8f] Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
git bisect bad 1077dd31ba60b39a231560beec24b97eadf8bd8f
# bad: [1577a2c2aad943fbc6a5e959ae83c4ef8bc3d4de] Merge branch 'drm-next' of
https://gitlab.freedesktop.org/agd5f/linux
git bisect bad 1577a2c2aad943fbc6a5e959ae83c4ef8bc3d4de
# good: [ec787deb2ddffc6cd6afe0e2fbbbd490ddc383ed] drm/amd: Use
`amdgpu_ucode_*` helpers for GFX9
git bisect good ec787deb2ddffc6cd6afe0e2fbbbd490ddc383ed
# bad: [0e4dcffd331fa7d2a6ae628b51a7f418dfa90367] drm/panel:
raspberrypi-touchscreen: Convert to i2c's .probe_new()
git bisect bad 0e4dcffd331fa7d2a6ae628b51a7f418dfa90367
# good: [c702545e19ebb6113d607f2a30ba2ee6cf881a3a] drm/gud: use new debugfs
device-centered functions
git bisect good c702545e19ebb6113d607f2a30ba2ee6cf881a3a
# good: [977374cf481d3bea916b2775e6ecc682b9689550] drm/vc4: plane: Add 3:3:2
and 4:4:4:4 RGB/RGBX/RGBA formats
git bisect good 977374cf481d3bea916b2775e6ecc682b9689550
# good: [67d0a30128c9f644595dfe67ac0fb941a716a6c9] drm/meson: dw-hdmi: Fix
devm_regulator_*get_enable*() conversion
git bisect good 67d0a30128c9f644595dfe67ac0fb941a716a6c9
# good: [29ef7605e2fd44038a70df0f46b7821464081b22] drm/i2c/sil164: Convert to
i2c's .probe_new()
git bisect good 29ef7605e2fd44038a70df0f46b7821464081b22
# good: [307259952625798fbea89b04aebbc5106ff18c68] drm/i2c/tda998x: Convert to
i2c's .probe_new()
git bisect good 307259952625798fbea89b04aebbc5106ff18c68
# good: [446757576a646eba6fae085396bdfbd74245ff28] drm/panel:
olimex-lcd-olinuxino: Convert to i2c's .probe_new()
git bisect good 446757576a646eba6fae085396bdfbd74245ff28
# first bad commit: [0e4dcffd331fa7d2a6ae628b51a7f418dfa90367] drm/panel:
raspberrypi-touchscreen: Convert to i2c's .probe_new()
signature.asc
Description: PGP signature
Re: next-20230110: arm64: defconfig+kselftest config boot failed - Unable to handle kernel paging request at virtual address fffffffffffffff8
On Wed, Jan 11, 2023 at 11:34:41AM +0100, Neil Armstrong wrote: > I merged a fix that could be related: > https://lore.kernel.org/all/20230109220033.31202-1-m.szyprow...@samsung.com/ > This could make the driver to return from probe while not totally probed, and > explain such error. We're seeing issues in all configs on meson-gxl-s905x-libretech-cc today, not just with the kselftest fragment. The initial failuire seems to be: [ 17.337253] WARNING: CPU: 3 PID: 123 at drivers/gpu/drm/drm_bridge.c:1257 drm_bridge_hpd_enable+0x8c/0x94 [drm] full log at: https://storage.kernelci.org/next/master/next-20230111/arm64/defconfig/gcc-10/lab-broonie/baseline-meson-gxl-s905x-libretech-cc.txt and links to other logs at: https://linux.kernelci.org/test/job/next/branch/master/kernel/next-20230111/plan/baseline/ Today's -next does have that fix in it so it's not fixing whatever the original issue was, I suspect it might even be exposing other issues. We are however still seeing the stack filling up, even with a GCC 10 defconfig build. signature.asc Description: PGP signature
Re: next-20230110: arm64: defconfig+kselftest config boot failed - Unable to handle kernel paging request at virtual address fffffffffffffff8
On Tue, Jan 10, 2023 at 04:32:59PM +, Will Deacon wrote:
> On Tue, Jan 10, 2023 at 09:44:40PM +0530, Naresh Kamboju wrote:
> > GOOD: next-20230109 (defconfig + kselftests configs)
> > BAD: next-20230110 (defconfig + kselftests configs)
> I couldn't find a kselftests .config in the tree (assumedly I'm just ont
> looking hard enough), but does that happen to enable CONFIG_STACK_TRACER=y?
It's adding on all the config fragments in
tools/testing/selftests/*/config
which includes ftrace, which does set STACK_TRACER>
> If so, since you're using clang, I wonder if this is an issue with
> 68a63a412d18 ("arm64: Fix build with CC=clang, CONFIG_FTRACE=y and
> CONFIG_STACK_TRACER=y")?
ftrace also enables FTRACE.
> Please let us know how the bisection goes...
Not sure that Naresh has a bisection going, I don't think he's got
direct access to such a board.
signature.asc
Description: PGP signature
Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin
On Wed, Dec 14, 2022 at 03:27:56PM +0100, Guillaume Tucker wrote: > On 14/12/2022 14:50, Mark Brown wrote: > > As a developer I tend to find this unhelpful, it makes it much more > > likely that the mail will get missed. As a reporter it means there's > > more information to copy into the report. > Well it's up to you or anyone reporting the bisection result. > Base on my personal experience, I always got very quick replies > when doing this. For me on the recipient side it's more a question of if you get any at all. > I don't see your point about copying more information though, I > would just open the mbox in my mail client to reply and paste the > content of the bisection report. With a bit more work this could > be fully automated but that should be part of the bisection > rework using the new API & pipeline so sometime later in 2023... If I'm manually pasing stuff I either have to quote it by hand or feel like I need to edit the automatically generated bits. > > I do notice that the Renesas tree tends to get a *lot* of the bisection > > reports generated for some reason (vastly more than any other tree > > including mainline or -next), however this wasn't sent based on the tree > > at all - I just looked at the people involved with the commit. > In the past month, there were 15 bisection reports on renesas, 7 > on linux-next and 28 on mainline for a total of 79 so 29 in other > trees. So it's true renesas is getting quite a lot of them, it's > not entirely clear to me why that's the case but it's worth > investigating a bit. Yeah, that's vastly more than I'd expect and the overwhelming majority of them are quite clearly not specific to the Renesas tree (things like bootrr failures for non-Renesas boards). signature.asc Description: PGP signature
Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin
On Wed, Dec 14, 2022 at 03:16:33PM +0100, Guillaume Tucker wrote: > Mark, how did you get the list of recipients? > There's a command for this btw, which was used when the reports > were automatically sent to the recipients before we reverted to > manual filtering to reduce the noise: My standard thing is to look at who touched the commit, possibly also adding seemingly relevant maintainers depending on how good the list from the commit was (IIRC in this case the commit went entirely through ChromeOS people so I added relevant DRM submaintainers which turned out to be a surprisingly large number of people), and relevant lists. > As you can see, Geert is not listed there. I didn't send the report to Geert as far as I can see, I imagine he saw it as a result of it going to one of the lists and noticed the mention of Renesas as the tree, possibly he's got some filter set up to find things that mention it. The recipient list I have is: | To: kernelci-resu...@groups.io, b...@kernelci.org, Brian Norris | , Sean Paul , Douglas | Anderson | Cc: gtuc...@collabora.com, dri-devel@lists.freedesktop.org, | linux-arm-ker...@lists.infradead.org, Andrzej Hajda | , Neil Armstrong , | Robert Foss , Laurent Pinchart | , Jonas Karlman , | Jernej Skrabec which doesn't mention him at all. > >> Yes it would be good to have 2nd order regressions based on a > >> reference branch (e.g. mainline in this case) in KernelCI but > > > > Sorry, I don't know what is a "2nd order regression". > > Regressions are basically a delta between results in a given > revision and the previous one on the same branch (new failures). > What I call "2nd order" regressions are a delta of these > regressions compared to another reference branch. For example, > regressions that are in a particular tree and aren't also in > mainline such as the one at hand which isn't specific to renesas. Like I said in the other mail there is something going on which means that a *very* lerge proportion of our bisection results are found in the Renesas tree. > >> that's for next year. Regardless, it found a commit and the > >> bisection looks legit. > > Good. So please report it to the relevant parties. That's what I did... > > While bisecting, as soon as you happen to arrive at a commit > > that is already upstream... > > 'ata-6.0-rc2' of > > git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata > > > git bisect bad 044610f8e4155ec0374f7c8307b725b7d01d750c > > (which happens here ) > > ... there is no point in "blaming" any of the bisection points before. I'm not sure I understand the logic here? The goal with a bisection is to identify which commit caused an issue to aid in resolving whatever the problem is. It doesn't really matter if this happens before or after the commit lands in Linus' tree. I do agree that the tree mentioned becomes a bit misleading though. signature.asc Description: PGP signature
Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin
On Wed, Dec 14, 2022 at 01:55:03PM +0100, Guillaume Tucker wrote: > Maybe you could retrieve the original thread and rely to it with > the report? That's the ideal way of following up on a patch I > think. You can get the mbox file this way: > ./kci_bisect get_mbox \ > --commit ca871659ec1606d33b1e76de8d4cf924cf627e34 \ > --kdir ~/src/linux As a developer I tend to find this unhelpful, it makes it much more likely that the mail will get missed. As a reporter it means there's more information to copy into the report. > > ... which is an old commit, added in v5.19-rc2, and which did not > > enter through the renesas tree at all? > Do you mean this report shouldn't have been sent to you? I do notice that the Renesas tree tends to get a *lot* of the bisection reports generated for some reason (vastly more than any other tree including mainline or -next), however this wasn't sent based on the tree at all - I just looked at the people involved with the commit. signature.asc Description: PGP signature
Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin
On Tue, Dec 13, 2022 at 05:56:30AM -0800, KernelCI bot wrote:
The KernelCI bisection bot found regressions in at least two KMS tests
in the Renesas tree on rk3399-gru-kevin just after the Renesas tree
merged up mainline:
igt-kms-rockchip.kms_vblank.pipe-A-wait-forked
igt-kms-rockchip.kms_vblank.pipe-A-query-busy
which it bisected to ca871659ec16 ("drm/bridge: analogix_dp: Support
PSR-exit to disable transition"). I'm not *100%* sure I trust the
bisection but it sure is suspicous that two separate bisects for related
issues landed on the same commit.
Below is the full report for the bisect for the first test, the bisect
for the latter looks identical. It's got links to full logs for the
test run and a Reported-by for the bot - I do see some backtraces from
userspace in the output, the first is:
| IGT-Version: 1.26-gf8a4a0b (aarch64) (Linux: 6.1.0 aarch64)
| <14>[ 35.48] [IGT] drm_read: starting subtest short-buffer-wakeup
| Starting subtest: short-buffer-wakeup
|
| (| drm_read:350) CRITICAL: Test assertion failure function generate_event,
file ../tests/drm_read.c:65:
| (drm_read:350) CRITICAL: <14>[ 36.155642] [IGT] drm_read: exiting, ret=98
| Failed assertion: kmstest_get_vblank(fd, pipe, DRM_VBLANK_EVENT)
|
| (drm_read:350) CRITICAL: Last errno: 22, Invalid argument
| Stack trace:
|
| #0 ../lib/igt_core.c:1933 __igt_fail_assert()
| #1 [+0xd5362770]
| #2 [+0xd536193c]
| #3 [__libc_start_main+0xe8]
| #4 [+0xd5361974]
| #5 [[ 36.162851] Console: switching to colour frame buffer
device 300x100>+0xd5361974]
| Subtest short-buffer-wakeup failed.
Unfortunately we don't have current results from mainline or -next.
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer:*
> * Reported-by: "kernelci.org bot" *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on
> rk3399-gru-kevin
>
> Summary:
> Start: 710ce3a8a6fbfc Merge tag 'v6.1' into renesas-devel
> Plain log:
> https://storage.kernelci.org/renesas/master/renesas-devel-2022-12-12-v6.1/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/igt-kms-rockchip-rk3399-gru-kevin.txt
> HTML log:
> https://storage.kernelci.org/renesas/master/renesas-devel-2022-12-12-v6.1/arm64/defconfig+arm64-chromebook/gcc-10/lab-collabora/igt-kms-rockchip-rk3399-gru-kevin.html
> Result: ca871659ec1606 drm/bridge: analogix_dp: Support PSR-exit to
> disable transition
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: renesas
> URL:
> https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel.git
> Branch: master
> Target: rk3399-gru-kevin
> CPU arch: arm64
> Lab:lab-collabora
> Compiler: gcc-10
> Config: defconfig+arm64-chromebook
> Test case: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked
>
> Breaking commit found:
>
> ---
> commit ca871659ec1606d33b1e76de8d4cf924cf627e34
> Author: Brian Norris
> Date: Mon Feb 28 12:25:31 2022 -0800
>
> drm/bridge: analogix_dp: Support PSR-exit to disable transition
>
> Most eDP panel functions only work correctly when the panel is not in
> self-refresh. In particular, analogix_dp_bridge_disable() tends to hit
> AUX channel errors if the panel is in self-refresh.
>
> Given the above, it appears that so far, this driver assumes that we are
> never in self-refresh when it comes time to fully disable the bridge.
> Prior to commit 846c7dfc1193 ("drm/atomic: Try to preserve the crtc
> enabled state in drm_atomic_remove_fb, v2."), this tended to be true,
> because we would automatically disable the pipe when framebuffers were
> removed, and so we'd typically disable the bridge shortly after the last
> display activity.
>
> However, that is not guaranteed: an idle (self-refresh) display pipe may
> be disabled, e.g., when switching CRTCs. We need to exit PSR first.
>
> Stable notes: this is definitely a bugfix, and the bug has likely
> existed in some form for quite a while. It may predate the "PSR helpers"
> refactor, but the code looked very different before that, and it's
> probably not worth rewriting the fix.
>
> Cc:
> Fixes: 6c836d965bad ("drm/rockchip: Use the
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Tue, Dec 13, 2022 at 02:23:32PM +, Jiaxin Yu (俞家鑫) wrote:
> On Mon, 2022-12-05 at 12:07 +0000, Mark Brown wrote:
> > On Mon, Dec 05, 2022 at 09:34:17AM +, Jiaxin Yu (俞家鑫) wrote:
> > No, I mean that if you want to control the enable and disable of the
> > output path you should implement a DAPM widget.
> May I ask which driver file to add a new DAPM widget? Is it the bridge
> ic driver like it6505.c? Or is it linke the "SDB" added in this patch?
I would expect this to follow a similar pattern to everything else with
hdmi-codec.c and have the actual ASoC stuff in there with a callback
exposed to the rest of the world.
> Yes, I should add a new set of events, such as:
> enum {
> HDMI_CODEC_TRIGGER_EVENT_STOP,
> HDMI_CODEC_TRIGGER_EVENT_START,
> HDMI_CODEC_TRIGGER_EVENT_SUSPEND,
> HDMI_CODEC_TRIGGER_EVENT_RESUME,
> }
> Then provide handles for these events in the it6505 driver. Am I right?
I'd expect more like on/off for a DAPM widget (the DAPM callbacks are
pre/post on/off) but yes.
signature.asc
Description: PGP signature
Re: [PATCH 1/3] ASoC: dt-bindings: Extend name-prefix.yaml into common DAI properties
On Sat, 3 Dec 2022 17:04:40 +0100, Krzysztof Kozlowski wrote: > Rename name-prefix.yaml into common DAI schema and document > '#sound-dai-cells' for completeness. The '#sound-dai-cells' cannot be > really constrained, as there are users with value of 0, 1 and 2, but at > least it brings definition to one common place. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/3] ASoC: dt-bindings: Extend name-prefix.yaml into common DAI properties commit: 3fda85324b8d7aa01ccfa1bb82c46befc6af518f [2/3] ASoC: dt-bindings: Reference common DAI properties commit: 58ae9a2aca6f883dd6fd7b8bfc2e1b1b21a2f03e [3/3] ASoC: dt-bindings: maxim,max98357a: Convert to DT schema commit: 8a5a05583a04fcfa094072147eb8f6c9bb2af852 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Mon, Dec 05, 2022 at 09:34:17AM +, Jiaxin Yu (俞家鑫) wrote: > 1. I have added a DAPM widget that is "SDB", when we open or close HDMI > PIN_SWITCH, the callback 'hdmi_tx_event' registered in the widget will > be triggered. Maybe you mean I shouldn't use SNDRV_PCM_TRIGGER_START > and SNDRV_PCM_TRIGGER_STOP? No, I mean that if you want to control the enable and disable of the output path you should implement a DAPM widget. > 2. If I don't use hcd.ops->trigger notifies the bridge ic driver to > switch the audio, which ops should I use? > I actually want to know hdmi-codec.c and it6505.c except > hdmi_codec_ops, is there any other way to communicate? Like I said you should use the event on the DAPM widget. This will require providing operations for the events to the drivers. signature.asc Description: PGP signature
Re: [PATCH v1 0/2] ASoC/tda998x: Fix reporting of nonexistent capture streams
On Wed, 30 Nov 2022 18:46:42 +, Mark Brown wrote: > The recently added pcm-test selftest has pointed out that systems with > the tda998x driver end up advertising that they support capture when in > reality as far as I can see the tda998x devices are transmit only. The > DAIs registered through hdmi-codec are bidirectional, meaning that for > I2S systems when combined with a typical bidrectional CPU DAI the > overall capability of the PCM is bidirectional. In most cases the I2S > links will clock OK but no useful audio will be returned which isn't so > bad but we should still not advertise the useless capability, and some > systems may notice problems for example due to pinmux management. > > [...] Applied to broonie/sound.git for-next Thanks! [1/2] ASoC: hdmi-codec: Allow playback and capture to be disabled commit: f77a066f4ed307db93aafee621e2683c3bda98ce [2/2] drm: tda99x: Don't advertise non-existent capture support commit: a04f1c81316d27e140c3df5561e5ef87794cd4bc All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Thu, Dec 01, 2022 at 03:06:04PM +, Jiaxin Yu (俞家鑫) wrote:
> On Tue, 2022-11-29 at 17:22 +0000, Mark Brown wrote:
> > static const struct snd_kcontrol_new
> > mt8186_mt6366_rt1019_rt5682s_controls[] = {
> > SOC_DAPM_PIN_SWITCH("Speakers"),
> > SOC_DAPM_PIN_SWITCH("Headphone"),
> > SOC_DAPM_PIN_SWITCH("Headset Mic"),
> > SOC_DAPM_PIN_SWITCH("HDMI1"),
> > };
> Which operation should I use to inform bridge driver to control audio
> on or off? I'm curious why I don't see .trigger in the structure
> hdmi_codec_ops compared to the structure snd_soc_dai_ops?
You'd need to add a callback that the user of hdmi-codec passes in which
would be triggered by an event on a DAPM widget added in the audio path
rather than trying to shoehorn this into a PCM operation - a big part of
the problem here is that you're trying to add something that doesn't fit
into a PCM operation.
signature.asc
Description: PGP signature
Re: [PATCH v2 0/6] drm/gud: Use the shadow plane helper
On Thu, Dec 01, 2022 at 03:27:32PM +0100, Vlastimil Babka wrote: > I usually do that with git send-email and a custom --cc-cmd script, but > additionally it sends the cover letter also to everyone that's on any > individual patch's Cc, so everyone gets at least the cover letter + their > specific patch(es). > But that extra logic could be optional. Yeah, without the cover letter if you've just got an individual patch it can be unclear what's going on with dependencies and so on for getting the patches merged. signature.asc Description: PGP signature
[PATCH v1 2/2] drm: tda99x: Don't advertise non-existent capture support
As far as I can tell none of the tda998x devices support audio capture so
don't advertise support for it, ensuring that we don't confuse userspace.
Signed-off-by: Mark Brown
---
drivers/gpu/drm/i2c/tda998x_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index d444e7fffb54..a14d2896aebb 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1174,6 +1174,8 @@ static int tda998x_audio_codec_init(struct tda998x_priv
*priv,
struct hdmi_codec_pdata codec_data = {
.ops = _codec_ops,
.max_i2s_channels = 2,
+ .no_i2s_capture = 1,
+ .no_spdif_capture = 1,
};
if (priv->audio_port_enable[AUDIO_ROUTE_I2S])
--
2.30.2
[PATCH v1 1/2] ASoC: hdmi-codec: Allow playback and capture to be disabled
Currently the hdmi-codec driver always registers both playback and capture
capabilities but for most systems there's no actual capture capability,
usually HDMI is transmit only. Provide platform data which allows the users
to indicate what is supported so that we don't end up advertising things
to userspace that we can't actually support.
In order to avoid breaking existing users the flags in platform data are
a bit awkward and specify what should be disabled rather than doing the
perhaps more expected thing and defaulting to not supporting capture.
Signed-off-by: Mark Brown
---
include/sound/hdmi-codec.h| 4
sound/soc/codecs/hdmi-codec.c | 30 +-
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 48ad33aba393..9b162ac1e08e 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -124,7 +124,11 @@ struct hdmi_codec_ops {
struct hdmi_codec_pdata {
const struct hdmi_codec_ops *ops;
uint i2s:1;
+ uint no_i2s_playback:1;
+ uint no_i2s_capture:1;
uint spdif:1;
+ uint no_spdif_playback:1;
+ uint no_spdif_capture:1;
int max_i2s_channels;
void *data;
};
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
index 0b1cdb2d6049..74cbbe16f9ae 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -816,12 +816,19 @@ static int hdmi_dai_probe(struct snd_soc_dai *dai)
.source = "RX",
},
};
- int ret;
+ int ret, i;
dapm = snd_soc_component_get_dapm(dai->component);
- ret = snd_soc_dapm_add_routes(dapm, route, 2);
- if (ret)
- return ret;
+
+ /* One of the directions might be omitted for unidirectional DAIs */
+ for (i = 0; i < ARRAY_SIZE(route); i++) {
+ if (!route[i].source || !route[i].sink)
+ continue;
+
+ ret = snd_soc_dapm_add_routes(dapm, [i], 1);
+ if (ret)
+ return ret;
+ }
daifmt = devm_kzalloc(dai->dev, sizeof(*daifmt), GFP_KERNEL);
if (!daifmt)
@@ -1009,11 +1016,24 @@ static int hdmi_codec_probe(struct platform_device
*pdev)
if (hcd->i2s) {
daidrv[i] = hdmi_i2s_dai;
daidrv[i].playback.channels_max = hcd->max_i2s_channels;
+ if (hcd->no_i2s_playback)
+ memset([i].playback, 0,
+ sizeof(daidrv[i].playback));
+ if (hcd->no_i2s_capture)
+ memset([i].capture, 0,
+ sizeof(daidrv[i].capture));
i++;
}
- if (hcd->spdif)
+ if (hcd->spdif) {
daidrv[i] = hdmi_spdif_dai;
+ if (hcd->no_spdif_playback)
+ memset([i].playback, 0,
+ sizeof(daidrv[i].playback));
+ if (hcd->no_spdif_capture)
+ memset([i].capture, 0,
+ sizeof(daidrv[i].capture));
+ }
dev_set_drvdata(dev, hcp);
--
2.30.2
[PATCH v1 0/2] ASoC/tda998x: Fix reporting of nonexistent capture streams
The recently added pcm-test selftest has pointed out that systems with the tda998x driver end up advertising that they support capture when in reality as far as I can see the tda998x devices are transmit only. The DAIs registered through hdmi-codec are bidirectional, meaning that for I2S systems when combined with a typical bidrectional CPU DAI the overall capability of the PCM is bidirectional. In most cases the I2S links will clock OK but no useful audio will be returned which isn't so bad but we should still not advertise the useless capability, and some systems may notice problems for example due to pinmux management. This is happening due to the hdmi-codec helpers not providing any mechanism for indicating unidirectional audio so add one and use it in the tda998x driver. It is likely other hdmi-codec users are also affected but I don't have those systems to hand. Mark Brown (2): ASoC: hdmi-codec: Allow playback and capture to be disabled drm: tda99x: Don't advertise non-existent capture support drivers/gpu/drm/i2c/tda998x_drv.c | 2 ++ include/sound/hdmi-codec.h| 4 sound/soc/codecs/hdmi-codec.c | 30 +- 3 files changed, 31 insertions(+), 5 deletions(-) base-commit: f0c4d9fc9cc9462659728d168387191387e903cc -- 2.30.2
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Mon, Nov 28, 2022 at 03:07:22PM +, Jiaxin Yu (俞家鑫) wrote: > On Fri, 2022-11-25 at 12:18 +0000, Mark Brown wrote: > > On Fri, Nov 25, 2022 at 05:44:11PM +0800, Jiaxin Yu wrote: > > I'm a little unclear why this is being implemented as a DAPM > > operation > > rather than having the driver forward the PCM trigger op if it's > > needed? > > Or alternatively if a DAPM callback is needed why not provide one > > directly rather than hooking into the trigger function - that's going > > to > > be called out of sequence with the rest of DAPM and be potentially > > confusing given the very different environments that trigger and DAPM > > operations run in. A quick glance at the it6505 driver suggests it'd > > be > > happier with a DAPM callback. > Let me describe the hardware connection about mt8186 with it6505(hdmi) > and rt1015p(speakers). >==>it6505 > = > DL1(FE) ==>I2S3(BE) = > = >==>rt1015p > They shared the same one i2s port, but we'd like to control them > separately. So if hdmi-codec use the PCM trigger op, whne we turn on > the speaker, hdmi-codec's PCM trigger op is also executed, resulting in > sound on both devices. > Is there another way to control them separately? Thank you. If you just need power control for one or both devices then the machine driver can add a _PIN_SWITCH() on the output of the device, that'll cause DAPM to keep the device powered down when not in use. That should work well with the suggestion to provide a DAPM callback instead of a a trigger operation. signature.asc Description: PGP signature
Re: [PATCH v2 1/3] ASoC: hdmi-codec: Add event handler for hdmi TX
On Fri, Nov 25, 2022 at 05:44:11PM +0800, Jiaxin Yu wrote:
> + /*
> + * PCM trigger callback.
> + * Mandatory
> + */
> + int (*trigger)(struct device *dev, int cmd);
> +
Making this mandatory would break all existing users, though...
> + switch (event) {
> + case SND_SOC_DAPM_PRE_PMU:
> + if (hcp->hcd.ops->trigger)
> + hcp->hcd.ops->trigger(component->dev->parent,
> SNDRV_PCM_TRIGGER_START);
...it's not actually mandatory so it's just the comment that's wrong.
I'm a little unclear why this is being implemented as a DAPM operation
rather than having the driver forward the PCM trigger op if it's needed?
Or alternatively if a DAPM callback is needed why not provide one
directly rather than hooking into the trigger function - that's going to
be called out of sequence with the rest of DAPM and be potentially
confusing given the very different environments that trigger and DAPM
operations run in. A quick glance at the it6505 driver suggests it'd be
happier with a DAPM callback.
signature.asc
Description: PGP signature
Re: [PATCH 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
On Fri, Nov 18, 2022 at 11:36:27AM +0100, Carlo Caione wrote: > On 17/11/2022 15:59, Mark Brown wrote: > > So this is an issue in the MIPI DBI code where the interpretation of the > > buffer passed in depends on both the a caller parameter and the > > capabilities of the underlying SPI controller, meaning that a driver can > > suddenly become buggy when used with a new controller? > The MIPI DBI code is fine, in fact it is doing the correct thing in the > mipi_dbi_typec3_command() function. The problem is that the ILI9486 > driver is hijacking that function installing its own hook that is wrong. Ah, I see - it's causing confusion because it peers into the internals of the underlying code. > The problem arrives when your controller does support 16-bits, so your > data is not swapped, but you still put the data on the bus with 8-bit > transfers. Why would you need to use 8 bit transfers if the controller supports 16 bits? signature.asc Description: PGP signature
Re: [PATCH 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
On Thu, Nov 17, 2022 at 02:40:05PM +0100, Carlo Caione wrote: > On 17/11/2022 12:09, Mark Brown wrote: > > I don't understand what the commit log is saying here. The meson-spicc > > driver advertises support for 8 bit words, if the driver is sending data > > formatted as a byte stream everything should be fine. > > It may be that there is some optimisation available from taking > > advantage of the hardware's ability to handle larger word sizes but > > there should be no data corruption issue. > There is no data corruption but the 16-bit pixel data have per-pixel > bytes swapped: for example 0x55AD is sent instead of 0xAD55 and this is > causing the wrong color to be displayed on the panel. If the data is being unexpectedly byte swapped then clearly it is being corrupted. How is this byte swapping happening? SPI devices should default to doing 8 bit transfers, if things randomly get put into anything other than 8 bit mode without the client device explicitly asking for it then that seems really bad. > The problem is that the current code is sending data with an hardcoded > bpw == 8 whether the data is swapped or not before the sending. > For 8-bit only controllers the data is swapped by the MIPI DBI code but > this is not true for controllers supporting 16-bit as well, but in both > cases we are sending the data out the same way with an 8 bpw. > So the same image is basically displayed differently whether the SPI > controller supports 16 bpw or not. I'm trying to fix this by sending > data with 16-bit bpw when the controller is supporting that. So this is an issue in the MIPI DBI code where the interpretation of the buffer passed in depends on both the a caller parameter and the capabilities of the underlying SPI controller, meaning that a driver can suddenly become buggy when used with a new controller? I can't really tell what the bits per word being passed in along with the buffer is supposed to mean, I'd have expected it to correspond to the format of the buffer but it seems like perhaps the buffer is always formatted for 16 bits and the callers are needing to pass in the capabilities of the controller which is then also checked by the underlying code? This all seems extremely confusing, I'm not surprised there's bugs. At the very least your changelog needs to express clearly what is going on, the description doesn't appear to correspond to what you're changing. > Please note that this is what it is done also by mipi_dbi_typec3_command(). The core code does appear to have some checks for controller capabilities... signature.asc Description: PGP signature
Re: [PATCH 2/3] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers
On Thu, Nov 17, 2022 at 09:47:40AM +0100, Carlo Caione wrote: > The ILI9486 driver is wrongly assuming that the SPI panel is interfaced > only with 8-bit SPI controllers and consequently that the pixel data > passed by the MIPI DBI subsystem are already swapped before being sent > over SPI using 8 bits-per-word. > > This is not always true for all the SPI controllers. > > Make the command function more general to not only support 8-bit only > SPI controllers and support sending un-swapped data over SPI using 16 > bits-per-word when dealing with pixel data. I don't understand what the commit log is saying here. The meson-spicc driver advertises support for 8 bit words, if the driver is sending data formatted as a byte stream everything should be fine. It may be that there is some optimisation available from taking advantage of the hardware's ability to handle larger word sizes but there should be no data corruption issue. > + /* > + * Check whether pixel data bytes needs to be swapped or not > + */ > + if (*cmd == MIPI_DCS_WRITE_MEMORY_START && !mipi->swap_bytes) > + bpw = 16; > + You should check the SPI controller compatibility here. signature.asc Description: PGP signature
Re: [PATCH 3/3] spi: meson-spicc: Lower CS between bursts
On Thu, Nov 17, 2022 at 09:47:41AM +0100, Carlo Caione wrote: > On some hardware (reproduced on S905X) when a large payload is > transmitted over SPI in bursts at the end of each burst, the clock line > briefly fluctuates creating spurious clock transitions that are being > recognised by the connected device as a genuine pulses, creating an > offset in the data being transmitted. > Lower the GPIO CS between bursts to avoid the clock being interpreted as > valid. This is just plain broken, *many* SPI devices attach meaning to chip select edges - for example register writes will typically have the register address followed by one or more register values for sequential registers. Bouncing chip select in the middle of transfer will corrupt data. If the device can't handle larger transfers it needs to advertise this limit and refuse to handle them. signature.asc Description: PGP signature
Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
On Mon, Nov 07, 2022 at 04:26:03PM +0100, Maxime Ripard wrote: > On Mon, Nov 07, 2022 at 12:06:07PM +0000, Mark Brown wrote: > > On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote: > > The series does fill in __clk_mux_determine_rate for everything though - > > if it was just assumed by default the only thing that'd be needed would > > be adding the flag. > The behavior assumed by default was equivalent to > __clk_mux_determine_rate + CLK_SET_RATE_NO_REPARENT. We could indeed set > both if determine_rate is missing in the core, but that's unprecedented > in the clock framework so I think we'll want Stephen to comment here :) > It's also replacing one implicit behavior by another. The point of this > series was to raise awareness on that particular point, so I'm not sure > it actually fixes things. We'll see what Stephen thinks about it. We could also just set the operation and still require the flag to be specified. I'm a little surprised to learn that it's something you might want to override, never mind that the API didn't have a default - it feels like a bit of a landmine that this is the case and is probably why there's so many cases to fix up. signature.asc Description: PGP signature
Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
On Mon, Nov 07, 2022 at 09:43:22AM +0100, Maxime Ripard wrote: > On Fri, Nov 04, 2022 at 03:59:53PM +0000, Mark Brown wrote: > > Well, hopefully everyone for whom it's an issue currently will be > > objecting to this version of the change anyway so we'll either know > > where to set the flag or we'll get the whack-a-mole with the series > > being merged? > I'm sorry, I'm not sure what you mean here. The only issue to fix at the > moment is that determine_rate and set_parent aren't coupled, and it led > to issues due to oversight. > I initially added a warning but Stephen wanted to fix all users in that > case and make that an error instead. My suggestion is that instead of doing either of these things it'd be quicker and less error prone to just fix the core to provide the default implementation if nothing more specific is provided. Any issues that causes would already be present with your current series. > If I filled __clk_mux_determine_rate into clocks that weren't using it > before, I would change their behavior. With that flag set, on all users > I add __clk_mux_determine_rate to, the behavior is the same than what we > previously had, so the risk of regressions is minimal, and everything > should keep going like it was? The series does fill in __clk_mux_determine_rate for everything though - if it was just assumed by default the only thing that'd be needed would be adding the flag. signature.asc Description: PGP signature
Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
On Fri, Nov 04, 2022 at 04:51:23PM +0100, Maxime Ripard wrote: > Just filling determine_rate if it's missing with > __clk_mux_determine_rate will possibly pick different parents, and I'm > fairly certain that this have never been tested on most platforms, and > will be completely broken. And I don't really want to play a game of > whack-a-mole adding that flag everywhere it turns out it's broken. Well, hopefully everyone for whom it's an issue currently will be objecting to this version of the change anyway so we'll either know where to set the flag or we'll get the whack-a-mole with the series being merged? signature.asc Description: PGP signature
Re: [PATCH v2 43/65] ASoC: tlv320aic32x4: Add a determine_rate hook
On Fri, Nov 04, 2022 at 02:18:00PM +0100, Maxime Ripard wrote: > So, the set_parent hook is effectively unused, possibly because of an > oversight. However, it could also be an explicit decision by the > original author to avoid any reparenting but through an explicit call to > clk_set_parent(). > The latter case would be equivalent to setting the flag > CLK_SET_RATE_NO_REPARENT, together with setting our determine_rate hook > to __clk_mux_determine_rate(). Indeed, if no determine_rate > implementation is provided, clk_round_rate() (through > clk_core_round_rate_nolock()) will call itself on the parent if > CLK_SET_RATE_PARENT is set, and will not change the clock rate > otherwise. __clk_mux_determine_rate() has the exact same behavior when > CLK_SET_RATE_NO_REPARENT is set. > And if it was an oversight, then we are at least explicit about our > behavior now and it can be further refined down the line. Given that the current approach involves patching every single user to set a default implementation it feels like it might be more straightforward to just have the clock API use that implementation if none is defined - as you say there's already a flag to indicate the unusual case where there's a solid reason to prevent reparenting. It feels like the resulting API is more straightforward. signature.asc Description: PGP signature
Re: [PATCH 1/2] component: Add helper for device nodes
On Thu, Nov 03, 2022 at 02:22:21PM -0400, Sean Anderson wrote: > There is a common case where component_patch_add_release is called with > component_release_of/component_compare_of and a device node. Add a > helper and convert existing users. The usual pattern here would be to split adding the helper from updating to use the helper - it makes things easier to merge. Acked-by: Mark Brown signature.asc Description: PGP signature
Re: linux-next: build failure after merge of the drm tree
On Tue, Oct 04, 2022 at 02:05:58PM +1100, Stephen Rothwell wrote: > On Tue, 4 Oct 2022 12:24:37 +1000 David Airlie wrote: > > On Tue, Oct 4, 2022 at 12:21 PM Stephen Rothwell > > wrote: > > I'm not seeing it here, what gcc is this with? > I am using an x86_64 cross compiler hosted on ppc64le - gcc v11.2.0 (on > Debian). I was seeing this with an x86_64 cross compiler hosted on arm64 - Ubuntu 11.2.0-17ubuntu1 from the looks of it. signature.asc Description: PGP signature
Re: (subset) [PATCH v1 00/11] Get rid of [devm_]gpiod_get_from_of_node() public APIs
On Sun, 4 Sep 2022 23:30:52 -0700, Dmitry Torokhov wrote: > I would like to stop exporting OF-specific [devm_]gpiod_get_from_of_node() > so that gpiolib can be cleaned a bit. We can do that by switching drivers > to use generic fwnode API ([devm_]fwnode_gpiod_get()). By doing so we open > the door to augmenting device tree and ACPI information through secondary > software properties (once we teach gpiolib how to handle those). > > I hope that relevant maintainers will take patches through their trees and > then we could merge the last one some time after -rc1. > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [08/11] regulator: bd71815: switch to using devm_fwnode_gpiod_get() commit: 97c9278ec624a0d5d7c56aa20e16afc8aaa96557 [09/11] regulator: bd9576: switch to using devm_fwnode_gpiod_get() commit: 587bfe3f7a270f0a4076e624d318292324bdead8 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: (subset) [PATCH v2 0/7] Devm helpers for regulator get and enable
On Fri, 12 Aug 2022 13:08:17 +0300, Matti Vaittinen wrote: > Devm helpers for regulator get and enable > > First patch in the series is actually just a simple documentation fix > which could be taken in as it is now. > > A few* drivers seem to use pattern demonstrated by pseudocode: > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next Thanks! [2/7] regulator: Add devm helpers for get and enable commit: da279e6965b3838e99e5c0ab8f76b87bf86b31a5 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
