* Re: [PATCH v3] ASoC: dt-bindings: ak4613: switch to yaml base Documentation
From: Mark Brown @ 2020-07-16 23:56 UTC (permalink / raw)
To: Kuninori Morimoto, Rob Herring; +Cc: devicetree, alsa-devel
In-Reply-To: <87y2nk2tfd.wl-kuninori.morimoto.gx@renesas.com>
On 16 Jul 2020 09:31:01 +0900, Kuninori Morimoto wrote:
> This patch switches from .txt base to .yaml base Document.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: ak4613: switch to yaml base Documentation
commit: 5b235b5522bf38f65cc76a9a008f179c37e0eb81
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
^ permalink raw reply
* Re: [PATCH v2 1/2] spi: omap-uwire: Use clk_prepare_enable and clk_disable_unprepare
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: Qing Zhang; +Cc: linux-kernel, linux-spi
In-Reply-To: <1594790807-32319-1-git-send-email-zhangqing@loongson.cn>
On Wed, 15 Jul 2020 13:26:46 +0800, Qing Zhang wrote:
> Convert clk_enable() to clk_prepare_enable() and clk_disable() to
> clk_disable_unprepare() respectively in the spi-omap-uwire.c.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: coldfire-qspi: Use clk_prepare_enable and clk_disable_unprepare
commit: 499de01c5c0b813cc94dbfc722ec12487044ac4a
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
^ permalink raw reply
* Re: [PATCH] spi: Only defer to thread for cleanup when needed
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: Mark Brown, linux-spi
In-Reply-To: <20200715163610.9475-1-broonie@kernel.org>
On Wed, 15 Jul 2020 17:36:10 +0100, Mark Brown wrote:
> Currently we always defer idling of controllers to the SPI thread, the goal
> being to ensure that we're doing teardown that's not suitable for atomic
> context in an appropriate context and to try to batch up more expensive
> teardown operations when the system is under higher load, allowing more
> work to be started before the SPI thread is scheduled. However when the
> controller does not require any substantial work to idle there is no need
> to do this, we can instead save the context switch and immediately mark
> the controller as idle. This is particularly useful for systems where there
> is frequent but not constant activity.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: Only defer to thread for cleanup when needed
commit: e126859729ed4a5143e5690186b8bec1c1157113
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
^ permalink raw reply
* Re: [PATCH] spi: atmel-quadspi: Use optimezed memcpy_fromio()/memcpy_toio()
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: Tudor Ambarus
Cc: linux-spi, linux-kernel, linux-arm-kernel, ludovic.desroches,
alexandre.belloni
In-Reply-To: <20200716043139.565734-1-tudor.ambarus@microchip.com>
On Thu, 16 Jul 2020 07:31:39 +0300, Tudor Ambarus wrote:
> Optimezed mem*io operations are defined for LE platforms, use them.
>
> The ARM and !ARCH_EBSA110 dependencies for COMPILE_TEST were added
> only for the _memcpy_fromio()/_memcpy_toio() functions. Drop these
> dependencies.
>
> Tested unaligned accesses on both sama5d2 and sam9x60 QSPI controllers
> using SPI NOR flashes, everything works ok. The following performance
> improvement can be seen when running mtd_speedtest:
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: atmel-quadspi: Use optimezed memcpy_fromio()/memcpy_toio()
commit: b780c3f38812bce7d7baebe2108738a043d6c4c3
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
^ permalink raw reply
* Re: [PATCH] spi: fix duplicated word in <linux/spi/spi.h>
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: linux-spi, Randy Dunlap, LKML
In-Reply-To: <40354d64-be71-3952-a980-63a76a278145@infradead.org>
On Wed, 15 Jul 2020 18:30:48 -0700, Randy Dunlap wrote:
> Change doubled word "as" to "as a".
>
> Change "Return: Return:" in kernel-doc notation to have only one
> "Return:".
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: fix duplicated word in <linux/spi/spi.h>
commit: 2ae3de10abfe0be40c9d93ebc2f429b969abf008
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
^ permalink raw reply
* Re: [PATCH trivial] spi: Fix SPI NOR and SPI NAND acronyms
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: Tudor Ambarus; +Cc: han.xu, trivial, linux-kernel, linux-spi
In-Reply-To: <20200716051144.568606-1-tudor.ambarus@microchip.com>
On Thu, 16 Jul 2020 08:11:44 +0300, Tudor Ambarus wrote:
> The industry refers to these flash types as "SPI NOR" and
> "SPI NAND". Be consistent and use the same acronyms.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/1] spi: Fix SPI NOR and SPI NAND acronyms
commit: 3e84cdd427b24b40d3670a7d61be31514bea1864
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
^ permalink raw reply
* Re: [PATCH 0/2] spi: bcm2835/bcm2835aux: support effective_speed_hz
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Florian Fainelli, linux-spi, Scott Branden,
Nicolas Saenz Julienne, Ray Jui, linux-arm-kernel, kernel,
bcm-kernel-feedback-list, linux-rpi-kernel
In-Reply-To: <20200709074120.110069-1-mkl@pengutronix.de>
On Thu, 9 Jul 2020 09:41:18 +0200, Marc Kleine-Budde wrote:
> I've picked up and forward ported Martin Sperl's patches which add support for
> effective_speed_hz to the SPI controllers found on all raspberry pi models.
>
> See the following patch, which adds this feature to the SPI core, for more
> information:
>
> 5d7e2b5ed585 spi: core: allow reporting the effectivly used speed_hz for a transfer
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/2] spi: bcm2835: support effective_speed_hz
commit: 9df2003df79a0f763dbf76891fcc7d4a5141861d
[2/2] spi: bcm2835aux: support effective_speed_hz
commit: 5e94c3cdaa29e28f6739c91a74d9ddd96f4ba6b6
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
^ permalink raw reply
* Re: [PATCH v2 1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
From: Mark Brown @ 2020-07-16 23:56 UTC (permalink / raw)
To: Lee Jones, lgirdwood
Cc: alsa-devel, Timur Tabi, Xiubo Li, Fabio Estevam, linux-kernel,
Nicolin Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200715150009.407442-1-lee.jones@linaro.org>
On Wed, 15 Jul 2020 16:00:09 +0100, Lee Jones wrote:
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
commit: 1b58214113481616b74ee4d196e5b1cb683758ee
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] regulator: Correct kernel-doc inconsistency
From: Mark Brown @ 2020-07-16 23:58 UTC (permalink / raw)
To: lgirdwood, Colton Lewis; +Cc: linux-kernel
In-Reply-To: <20200715191438.29312-1-colton.w.lewis@protonmail.com>
On Wed, 15 Jul 2020 19:15:00 +0000, Colton Lewis wrote:
> Silence documentation build warning by correcting kernel-doc comments.
>
> ./include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints'
> ./include/linux/regulator/driver.h:206: warning: Function parameter or member 'resume' not described in 'regulator_ops'
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next
Thanks!
[1/1] regulator: Correct kernel-doc inconsistency
commit: a98bcaa92d3d7a7753e23b3363d90ffdb82e8edb
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
^ permalink raw reply
* Re: [PATCH] regmap: debugfs: Don't sleep while atomic for fast_io regmaps
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: Douglas Anderson
Cc: Richard Fitzgerald, Greg Kroah-Hartman, linux-kernel,
Rafael J. Wysocki, Rohit Kumar
In-Reply-To: <20200715164611.1.I35b3533e8a80efde0cec1cc70f71e1e74b2fa0da@changeid>
On Wed, 15 Jul 2020 16:46:15 -0700, Douglas Anderson wrote:
> If a regmap has "fast_io" set then its lock function uses a spinlock.
> That doesn't work so well with the functions:
> * regmap_cache_only_write_file()
> * regmap_cache_bypass_write_file()
>
> Both of the above functions have the pattern:
> 1. Lock the regmap.
> 2. Call:
> debugfs_write_file_bool()
> copy_from_user()
> __might_fault()
> __might_sleep()
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap: debugfs: Don't sleep while atomic for fast_io regmaps
commit: 299632e54b2e692d2830af84be51172480dc1e26
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
^ permalink raw reply
* Re: [PATCH] regmap: fix duplicated word in <linux/regmap.h>
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: LKML, Randy Dunlap
In-Reply-To: <7ef41bfc-de3e-073a-8746-0b3fdf7628c0@infradead.org>
On Wed, 15 Jul 2020 18:30:12 -0700, Randy Dunlap wrote:
> Change doubled word "be" to "to be".
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap: fix duplicated word in <linux/regmap.h>
commit: 6611561a7a7ef925294353a4c2124bdb66eb831c
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
^ permalink raw reply
* Re: [PATCH v2 1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
From: Mark Brown @ 2020-07-16 23:56 UTC (permalink / raw)
To: Lee Jones, lgirdwood
Cc: alsa-devel, Timur Tabi, Xiubo Li, Fabio Estevam, linux-kernel,
Nicolin Chen, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200715150009.407442-1-lee.jones@linaro.org>
On Wed, 15 Jul 2020 16:00:09 +0100, Lee Jones wrote:
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
commit: 1b58214113481616b74ee4d196e5b1cb683758ee
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
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: ak4642: switch to yaml base Documentation
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: Kuninori Morimoto, Rob Herring; +Cc: alsa-devel, devicetree
In-Reply-To: <87wo342tds.wl-kuninori.morimoto.gx@renesas.com>
On 16 Jul 2020 09:31:57 +0900, Kuninori Morimoto wrote:
> This patch switches from .txt base to .yaml base Document.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: ak4642: switch to yaml base Documentation
commit: 0cee81b4fa402d31a5cbefaedba4973ba3f2aced
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
^ permalink raw reply
* Re: [resend] ASoC: dt-bindings: ak4642: switch to yaml base Documentation
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: Kuninori Morimoto, Rob Herring; +Cc: alsa-devel, devicetree
In-Reply-To: <87lfjwxlna.wl-kuninori.morimoto.gx@renesas.com>
On 07 Jul 2020 08:35:38 +0900, Kuninori Morimoto wrote:
> This patch switches from .txt base to .yaml base Document.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: ak4642: switch to yaml base Documentation
commit: 0cee81b4fa402d31a5cbefaedba4973ba3f2aced
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
^ permalink raw reply
* Re: [PATCH 1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: Lee Jones, lgirdwood
Cc: alsa-devel, Fabio Estevam, linuxppc-dev, Xiubo Li, linux-kernel,
linux-arm-kernel, Timur Tabi, Nicolin Chen
In-Reply-To: <20200715094447.3170843-1-lee.jones@linaro.org>
On Wed, 15 Jul 2020 10:44:47 +0100, Lee Jones wrote:
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
commit: 1b58214113481616b74ee4d196e5b1cb683758ee
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
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: renesas, fsi: use patternProperties for FSI-A/B
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: Kuninori Morimoto, Rob Herring; +Cc: alsa-devel, devicetree
In-Reply-To: <87zh802tif.wl-kuninori.morimoto.gx@renesas.com>
On 16 Jul 2020 09:29:10 +0900, Kuninori Morimoto wrote:
> FSI has FSI-A and FSI-B, and has fsia-xxx/fsib-xxx properties.
> This patch uses patternProperties, and reduce verbose settings.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: renesas, fsi: use patternProperties for FSI-A/B
commit: d235b282369813c53fdd512d61402b6a7cda1603
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
^ permalink raw reply
* Re: [PATCH 06/11] xfs: always use xfs_dquot_type when extracting type from a dquot
From: Dave Chinner @ 2020-07-16 23:57 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <159488195772.3813063.4337415651120546350.stgit@magnolia>
On Wed, Jul 15, 2020 at 11:45:57PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@oracle.com>
>
> Always use the xfs_dquot_type helper to extract the quota type from an
> incore dquot. This moves responsibility for filtering internal state
> information and whatnot to anybody passing around a dquot.
>
> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
> ---
> fs/xfs/xfs_dquot.c | 15 ++++++++-------
> fs/xfs/xfs_dquot.h | 2 +-
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
looks ok, minor nit below
Reviewed-by: Dave Chinner <dchinner@redhat.com>
> diff --git a/fs/xfs/xfs_dquot.c b/fs/xfs/xfs_dquot.c
> index ce946d53bb61..b46a9e63b286 100644
> --- a/fs/xfs/xfs_dquot.c
> +++ b/fs/xfs/xfs_dquot.c
> @@ -273,14 +273,15 @@ xfs_dquot_disk_alloc(
> struct xfs_trans *tp = *tpp;
> struct xfs_mount *mp = tp->t_mountp;
> struct xfs_buf *bp;
> - struct xfs_inode *quotip = xfs_quota_inode(mp, dqp->dq_flags);
> + uint qtype = xfs_dquot_type(dqp);
> + struct xfs_inode *quotip = xfs_quota_inode(mp, qtype);
> int nmaps = 1;
> int error;
>
> trace_xfs_dqalloc(dqp);
>
> xfs_ilock(quotip, XFS_ILOCK_EXCL);
> - if (!xfs_this_quota_on(dqp->q_mount, dqp->dq_flags)) {
> + if (!xfs_this_quota_on(dqp->q_mount, qtype)) {
> /*
> * Return if this type of quotas is turned off while we didn't
> * have an inode lock
> @@ -317,8 +318,7 @@ xfs_dquot_disk_alloc(
> * Make a chunk of dquots out of this buffer and log
> * the entire thing.
> */
> - xfs_qm_init_dquot_blk(tp, mp, dqp->q_id,
> - dqp->dq_flags & XFS_DQTYPE_REC_MASK, bp);
> + xfs_qm_init_dquot_blk(tp, mp, dqp->q_id, xfs_dquot_type(dqp), bp);
This should use 'qtype' rather than call xfs_dquot_type() again.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [resend] ASoC: dt-bindings: renesas, fsi: use patternProperties for FSI-A/B
From: Mark Brown @ 2020-07-16 23:57 UTC (permalink / raw)
To: Kuninori Morimoto, Rob Herring; +Cc: alsa-devel, devicetree
In-Reply-To: <87o8osxlow.wl-kuninori.morimoto.gx@renesas.com>
On 07 Jul 2020 08:34:40 +0900, Kuninori Morimoto wrote:
> FSI has FSI-A and FSI-B, and has fsia-xxx/fsib-xxx properties.
> This patch uses patternProperties, and reduce verbose settings.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: renesas, fsi: use patternProperties for FSI-A/B
commit: d235b282369813c53fdd512d61402b6a7cda1603
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
^ permalink raw reply
* Re: [PATCH v3] ASoC: dt-bindings: ak4613: switch to yaml base Documentation
From: Mark Brown @ 2020-07-16 23:56 UTC (permalink / raw)
To: Kuninori Morimoto, Rob Herring; +Cc: alsa-devel, devicetree
In-Reply-To: <87y2nk2tfd.wl-kuninori.morimoto.gx@renesas.com>
On 16 Jul 2020 09:31:01 +0900, Kuninori Morimoto wrote:
> This patch switches from .txt base to .yaml base Document.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: dt-bindings: ak4613: switch to yaml base Documentation
commit: 5b235b5522bf38f65cc76a9a008f179c37e0eb81
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
^ permalink raw reply
* Re: [PATCH v2 1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
From: Mark Brown @ 2020-07-16 23:56 UTC (permalink / raw)
To: Lee Jones, lgirdwood
Cc: alsa-devel, Fabio Estevam, linuxppc-dev, Xiubo Li, linux-kernel,
linux-arm-kernel, Timur Tabi, Nicolin Chen
In-Reply-To: <20200715150009.407442-1-lee.jones@linaro.org>
On Wed, 15 Jul 2020 16:00:09 +0100, Lee Jones wrote:
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: fsl-asoc-card: Trivial: Fix misspelling of 'exists'
commit: 1b58214113481616b74ee4d196e5b1cb683758ee
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
^ permalink raw reply
* Re: [PATCH net-next 1/3] ptp: add ability to configure duty cycle for periodic output
From: Jacob Keller @ 2020-07-16 23:56 UTC (permalink / raw)
To: Vladimir Oltean
Cc: kuba, davem, netdev, richardcochran, yangbo.lu, xiaoliang.yang_1,
po.liu, UNGLinuxDriver
In-Reply-To: <20200716220923.k6vwsjdk2os4rlrp@skbuf>
On 7/16/2020 3:09 PM, Vladimir Oltean wrote:
> On Fri, Jul 17, 2020 at 12:49:27AM +0300, Vladimir Oltean wrote:
>> On Thu, Jul 16, 2020 at 02:36:45PM -0700, Jacob Keller wrote:
>>>
>>>
>>> On 7/16/2020 2:20 PM, Vladimir Oltean wrote:
>>>> There are external event timestampers (PHCs with support for
>>>> PTP_EXTTS_REQUEST) that timestamp both event edges.
>>>>
>>>> When those edges are very close (such as in the case of a short pulse),
>>>> there is a chance that the collected timestamp might be of the rising,
>>>> or of the falling edge, we never know.
>>>>
>>>> There are also PHCs capable of generating periodic output with a
>>>> configurable duty cycle. This is good news, because we can space the
>>>> rising and falling edge out enough in time, that the risks to overrun
>>>> the 1-entry timestamp FIFO of the extts PHC are lower (example: the
>>>> perout PHC can be configured for a period of 1 second, and an "on" time
>>>> of 0.5 seconds, resulting in a duty cycle of 50%).
>>>>
>>>> A flag is introduced for signaling that an on time is present in the
>>>> perout request structure, for preserving compatibility. Logically
>>>> speaking, the duty cycle cannot exceed 100% and the PTP core checks for
>>>> this.
>>>
>>> I was thinking whether it made sense to support over 50% since in theory
>>> you could change start time and the duty cycle to specify the shifted
>>> wave over? but I guess it doesn't really make much of a difference to
>>> support all the way up to 100%.
>>>
>>
>> Only if you also support polarity, and we don't support polarity. It's
>> always high first, then low.
>>
>
> Sorry for the imprecise statement.
> If you look at things from the perspective of the signal itself, the
> statement is correct.
> If you look at them from the perspective of the imaginary grid drawn by
> the integer multiples of the period, in the PHC's time (a digital
> counter), the correct statement would be that "it's always rising edge
> first, then falling edge". And then the phase is just the delta between
> these 2 points of reference.
>
> Let me annotate this:
>
> t_on
> <------>
> t_period
> <--------->
> phase
> <->
>> +------+ +------+ +------+ +------+ +------+ +------+ +------+
>> | | | | | | | | | | | | | |
>> --+ +--+ +--+ +--+ +--+ +--+ +--+ +
>>
>> +---------+---------+---------+---------+---------+---------+--------->
> t=1000 t=1010 t=1020 t=1030 t=1040 t=1050 t=1060
>> period=10 time
>> phase=2
>> on = 7
>>
>> There's no other way to obtain this signal which has a duty cycle > 50%
>> by specifying a duty cycle < 50%.
>>
>
> Thanks,
> -Vladimir
>
Right this makes sense now, thanks for the detailed explanation!
Regards,
Jake
^ permalink raw reply
* Re: [net-next PATCH v2 0/9] Add PRP driver and bug fixes
From: Jakub Kicinski @ 2020-07-16 23:56 UTC (permalink / raw)
To: Murali Karicheri
Cc: davem, netdev, linux-kernel, linux-api, nsekhar,
grygorii.strashko, vinicius.gomes
In-Reply-To: <20200715164012.1222-1-m-karicheri2@ti.com>
Hi Murali,
thanks for the patches.
It seems like at least the first patch addresses a problem which exist
in Linus's tree, i.e. Linux 5.8-rc.
Could you please separate bug fixes like that out to a new series
addressed to the net tree, and add appropriate Fixes tags?
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
From: Patchwork @ 2020-07-16 23:56 UTC (permalink / raw)
To: Manasi Navare; +Cc: intel-gfx
In-Reply-To: <20200716232900.28414-1-manasi.d.navare@intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 9143 bytes --]
== Series Details ==
Series: series starting with [1/2] drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
URL : https://patchwork.freedesktop.org/series/79569/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8759 -> Patchwork_18198
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_18198 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18198, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/index.html
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_18198:
### IGT changes ###
#### Possible regressions ####
* igt@i915_pm_backlight@basic-brightness:
- fi-icl-u2: [PASS][1] -> [SKIP][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-u2/igt@i915_pm_backlight@basic-brightness.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-icl-u2/igt@i915_pm_backlight@basic-brightness.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-tgl-y: [PASS][3] -> [SKIP][4] +19 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-y/igt@kms_cursor_legacy@basic-flip-after-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank:
- fi-tgl-y: NOTRUN -> [SKIP][5] +3 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-y/igt@kms_flip@basic-flip-vs-wf_vblank.html
* igt@kms_psr@cursor_plane_move:
- fi-kbl-r: [PASS][6] -> [CRASH][7] +3 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-r/igt@kms_psr@cursor_plane_move.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-r/igt@kms_psr@cursor_plane_move.html
* igt@kms_psr@primary_page_flip:
- fi-icl-u2: [PASS][8] -> [CRASH][9] +3 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-u2/igt@kms_psr@primary_page_flip.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-icl-u2/igt@kms_psr@primary_page_flip.html
* igt@kms_psr@sprite_plane_onoff:
- fi-tgl-y: [PASS][10] -> [CRASH][11] +3 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@kms_psr@sprite_plane_onoff.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-y/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: [PASS][12] -> [WARN][13]
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-icl-u2/igt@kms_setmode@basic-clone-single-crtc.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-icl-u2/igt@kms_setmode@basic-clone-single-crtc.html
- fi-tgl-y: [PASS][14] -> [WARN][15]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@kms_setmode@basic-clone-single-crtc.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-y/igt@kms_setmode@basic-clone-single-crtc.html
#### Warnings ####
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-y: [DMESG-WARN][16] ([i915#1982]) -> [SKIP][17] +1 similar issue
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-y/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
Known issues
------------
Here are the changes found in Patchwork_18198 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_module_load@reload:
- fi-tgl-u2: [PASS][18] -> [DMESG-WARN][19] ([i915#402])
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-u2/igt@i915_module_load@reload.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-u2/igt@i915_module_load@reload.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-kbl-r: [PASS][20] -> [SKIP][21] ([fdo#109271]) +21 similar issues
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-r/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-r/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-kbl-r: [PASS][22] -> [WARN][23] ([i915#2100])
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-r/igt@kms_setmode@basic-clone-single-crtc.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-r/igt@kms_setmode@basic-clone-single-crtc.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][24] ([i915#1982] / [i915#62] / [i915#92] / [i915#95]) -> [PASS][25]
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-x1275/igt@gem_exec_suspend@basic-s0.html
- fi-tgl-u2: [FAIL][26] ([i915#1888]) -> [PASS][27]
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-u2/igt@gem_exec_suspend@basic-s0.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [SKIP][28] ([fdo#109271]) -> [PASS][29]
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
* igt@kms_flip@basic-flip-vs-modeset@b-dp1:
- fi-kbl-x1275: [DMESG-WARN][30] ([i915#62] / [i915#92]) -> [PASS][31] +29 similar issues
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-modeset@b-dp1.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-x1275/igt@kms_flip@basic-flip-vs-modeset@b-dp1.html
* igt@kms_force_connector_basic@force-edid:
- fi-kbl-x1275: [DMESG-WARN][32] ([i915#62] / [i915#92] / [i915#95]) -> [PASS][33] +8 similar issues
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-kbl-x1275/igt@kms_force_connector_basic@force-edid.html
* igt@kms_psr@cursor_plane_move:
- fi-whl-u: [SKIP][34] ([fdo#109271] / [i915#668]) -> [PASS][35] +3 similar issues
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-whl-u/igt@kms_psr@cursor_plane_move.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-whl-u/igt@kms_psr@cursor_plane_move.html
* igt@prime_vgem@basic-write:
- fi-tgl-y: [DMESG-WARN][36] ([i915#402]) -> [PASS][37]
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8759/fi-tgl-y/igt@prime_vgem@basic-write.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/fi-tgl-y/igt@prime_vgem@basic-write.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2100]: https://gitlab.freedesktop.org/drm/intel/issues/2100
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (45 -> 40)
------------------------------
Missing (5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper
Build changes
-------------
* Linux: CI_DRM_8759 -> Patchwork_18198
CI-20190529: 20190529
CI_DRM_8759: 9136d875406863759c4c7939f4b32edf7d76b007 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5738: bc8b56fe177af34fbde7b96f1f66614a0014c6ef @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18198: 745bd4981bd6e99938d3d5e540d98637e161a755 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
745bd4981bd6 drm/i915/display/dp: Hacks for testing link training fail errors
7e44cd55cc41 drm/i915/dp: HAX Try the bspec value for CLKTOP2_CORECLKCTL
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18198/index.html
[-- Attachment #1.2: Type: text/html, Size: 10843 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
From: Bjorn Helgaas @ 2020-07-16 23:54 UTC (permalink / raw)
To: Karol Herbst
Cc: Sasha Levin, Patrick Volkerding, Linux PCI, linux-kernel,
dri-devel, Kai-Heng Feng, Ben Skeggs, nouveau, Bjorn Helgaas,
Mika Westerberg
In-Reply-To: <CACO55tuA+XMgv=GREf178NzTLTHri4kyD5mJjKuDpKxExauvVg@mail.gmail.com>
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst@redhat.com> wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on one of my systems here. Even though the issue doesn't always
> > happen I am quite confident this is the commit breaking it.
> >
> > I am still digging into the issue and trying to figure out what
> > exactly breaks, but it shows up in different ways. Either we are not
> > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > Btw, this is also a system where our runtime power management issue
> > shows up, so maybe there is indeed something funky with the bridge
> > controller.
> >
> > Just pinging you in case you have an idea on how this could break Nouveau
> >
> > most of the times it shows up like this:
> > nouveau 0000:01:00.0: acr: AHESASC binary failed
> >
> > Sometimes it works at boot and fails at runtime resuming with random
> > faults. So I will be investigating a bit more, but yeah... I am super
> > sure the commit triggered this issue, no idea if it actually causes
> > it.
>
> so yeah.. I reverted that locally and never ran into issues again.
> Still valid on latest 5.7. So can we get this reverted or properly
> fixed? This breaks runtime pm for us on at least some hardware.
Yeah, that stinks. We had another similar report from Patrick:
https://lore.kernel.org/r/CAErSpo5sTeK_my1dEhWp7aHD0xOp87+oHYWkTjbL7ALgDbXo-Q@mail.gmail.com
Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
DLL Link Active train links in 100 ms"), which Patrick found was
backported to v5.4.49 as 828b192c57e8, and you found was backported to
v5.7.6 as afaff825e3a4.
Oddly, Patrick reported that v5.7.7 worked correctly, even though it
still contains afaff825e3a4.
I guess in the absence of any other clues we'll have to revert it.
I hate to do that because that means we'll have slow resume of
Thunderbolt-connected devices again, but that's better than having
GPUs completely broken.
Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
and to this thread?
There must be a way to fix the slow resume problem without breaking
the GPUs.
Bjorn
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"
From: Bjorn Helgaas @ 2020-07-16 23:54 UTC (permalink / raw)
To: Karol Herbst
Cc: Linux PCI, Mika Westerberg, Ben Skeggs, Bjorn Helgaas, Lyude Paul,
nouveau, dri-devel, Patrick Volkerding, linux-kernel,
Kai-Heng Feng, Sasha Levin
In-Reply-To: <CACO55tuA+XMgv=GREf178NzTLTHri4kyD5mJjKuDpKxExauvVg@mail.gmail.com>
[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst <kherbst@redhat.com> wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on one of my systems here. Even though the issue doesn't always
> > happen I am quite confident this is the commit breaking it.
> >
> > I am still digging into the issue and trying to figure out what
> > exactly breaks, but it shows up in different ways. Either we are not
> > able to boot the engines on the GPU or the GPU becomes unresponsive.
> > Btw, this is also a system where our runtime power management issue
> > shows up, so maybe there is indeed something funky with the bridge
> > controller.
> >
> > Just pinging you in case you have an idea on how this could break Nouveau
> >
> > most of the times it shows up like this:
> > nouveau 0000:01:00.0: acr: AHESASC binary failed
> >
> > Sometimes it works at boot and fails at runtime resuming with random
> > faults. So I will be investigating a bit more, but yeah... I am super
> > sure the commit triggered this issue, no idea if it actually causes
> > it.
>
> so yeah.. I reverted that locally and never ran into issues again.
> Still valid on latest 5.7. So can we get this reverted or properly
> fixed? This breaks runtime pm for us on at least some hardware.
Yeah, that stinks. We had another similar report from Patrick:
https://lore.kernel.org/r/CAErSpo5sTeK_my1dEhWp7aHD0xOp87+oHYWkTjbL7ALgDbXo-Q@mail.gmail.com
Apparently the problem is ec411e02b7a2 ("PCI/PM: Assume ports without
DLL Link Active train links in 100 ms"), which Patrick found was
backported to v5.4.49 as 828b192c57e8, and you found was backported to
v5.7.6 as afaff825e3a4.
Oddly, Patrick reported that v5.7.7 worked correctly, even though it
still contains afaff825e3a4.
I guess in the absence of any other clues we'll have to revert it.
I hate to do that because that means we'll have slow resume of
Thunderbolt-connected devices again, but that's better than having
GPUs completely broken.
Could you and Patrick open bugzilla.kernel.org reports, attach dmesg
logs and "sudo lspci -vv" output, and add the URLs to Kai-Heng's
original report at https://bugzilla.kernel.org/show_bug.cgi?id=206837
and to this thread?
There must be a way to fix the slow resume problem without breaking
the GPUs.
Bjorn
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.