* [igt-dev] ✓ Fi.CI.BAT: success for tools/i915-perf: workaround overzelous compiler warnings (rev2)
From: Patchwork @ 2020-02-20 15:10 UTC (permalink / raw)
To: Lionel Landwerlin; +Cc: igt-dev
In-Reply-To: <20200220133416.1194071-1-lionel.g.landwerlin@intel.com>
== Series Details ==
Series: tools/i915-perf: workaround overzelous compiler warnings (rev2)
URL : https://patchwork.freedesktop.org/series/73709/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7973 -> IGTPW_4196
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
New tests
---------
New tests have been introduced between CI_DRM_7973 and IGTPW_4196:
### New IGT tests (4) ###
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 1 dmesg-warn(s) 17 pass(s) 23 skip(s)
- Exec time: [0.0, 0.24] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 1 dmesg-warn(s) 29 pass(s) 11 skip(s)
- Exec time: [0.0, 6.85] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 1 dmesg-warn(s) 29 pass(s) 11 skip(s)
- Exec time: [0.44, 11.31] s
* igt@i915_pm_rps@basic-api:
- Statuses : 36 pass(s) 5 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in IGTPW_4196 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_close_race@basic-threads:
- fi-hsw-peppy: [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
- fi-byt-n2820: [PASS][3] -> [INCOMPLETE][4] ([i915#45])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-byt-n2820/igt@gem_close_race@basic-threads.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-byt-n2820/igt@gem_close_race@basic-threads.html
* igt@gem_flink_basic@bad-flink:
- fi-tgl-y: [PASS][5] -> [DMESG-WARN][6] ([CI#94] / [i915#402])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_flink_basic@bad-flink.html
* igt@i915_selftest@live_gtt:
- fi-bdw-5557u: [PASS][7] -> [TIMEOUT][8] ([fdo#112271])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-bdw-5557u/igt@i915_selftest@live_gtt.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s4-devices:
- fi-tgl-y: [FAIL][9] ([CI#94]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_exec_suspend@basic-s4-devices.html
* igt@gem_mmap@basic:
- fi-tgl-y: [DMESG-WARN][11] ([CI#94] / [i915#402]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-tgl-y/igt@gem_mmap@basic.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-tgl-y/igt@gem_mmap@basic.html
* igt@i915_selftest@live_gem_contexts:
- fi-cml-s: [DMESG-FAIL][13] ([i915#877]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-cml-s/igt@i915_selftest@live_gem_contexts.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][15] ([i915#217]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-icl-u2/igt@kms_chamelium@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][17] ([fdo#111407]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7973/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/fi-kbl-7500u/igt@kms_chamelium@hdmi-hpd-fast.html
[CI#94]: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/94
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#217]: https://gitlab.freedesktop.org/drm/intel/issues/217
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#45]: https://gitlab.freedesktop.org/drm/intel/issues/45
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816
[i915#877]: https://gitlab.freedesktop.org/drm/intel/issues/877
Participating hosts (49 -> 47)
------------------------------
Additional (5): fi-kbl-soraka fi-ivb-3770 fi-pnv-d510 fi-skl-lmem fi-kbl-7560u
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus
Build changes
-------------
* CI: CI-20190529 -> None
* IGT: IGT_5453 -> IGTPW_4196
CI-20190529: 20190529
CI_DRM_7973: 07350317e4b2be54b1de7f1e73f77875df5e43f3 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_4196: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
IGT_5453: cae9a5881ed2c5be2c2518a255740b612a927f9a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4196/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-7-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 06/10] ASoC: tegra: add Tegra186 based DSPK driver
From: Jon Hunter @ 2020-02-20 15:10 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-7-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Digital Speaker Controller (DSPK) converts the multi-bit Pulse Code
> Modulation (PCM) audio input to oversampled 1-bit Pulse Density Modulation
> (PDM) output. From the signal flow perpsective, the DSPK can be viewed as
> a PDM transmitter that up-samples the input to the desired sampling rate
> by interpolation then converts the oversampled PCM input to the desired
> 1-bit output via Delta Sigma Modulation (DSM).
>
> This patch registers DSPK component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes DSPK interfaces, which can be used to connect different
> components in the ASoC layer. Makefile and Kconfig support is added to
> allow to build the driver. The DSPK devices can be enabled in the DT via
> "nvidia,tegra186-dspk" compatible binding. This driver can be used
> on Tegra194 chip as well.
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/Kconfig | 13 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra186_dspk.c | 510 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra186_dspk.h | 73 ++++++
> 4 files changed, 598 insertions(+)
> create mode 100644 sound/soc/tegra/tegra186_dspk.c
> create mode 100644 sound/soc/tegra/tegra186_dspk.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* [PATCH] Remove meta-arm-iota
From: Jon Mason @ 2020-02-20 15:09 UTC (permalink / raw)
To: meta-arm; +Cc: nd
Feedback received that it is not acceptable to have a distro layer
inside (https://lists.yoctoproject.org/g/meta-arm/message/6). Removing
from meta-arm and will create a separate git repository once that code
is ready.
Change-Id: I74d1083341d90caa038c1bd8c1d53aa565d28460
Signed-off-by: Jon Mason <jon.mason@arm.com>
---
meta-arm-iota/conf/layer.conf | 13 -------------
1 file changed, 13 deletions(-)
delete mode 100644 meta-arm-iota/conf/layer.conf
diff --git a/meta-arm-iota/conf/layer.conf b/meta-arm-iota/conf/layer.conf
deleted file mode 100644
index 392ed9b..0000000
--- a/meta-arm-iota/conf/layer.conf
+++ /dev/null
@@ -1,13 +0,0 @@
-# We have a conf and classes directory, add to BBPATH
-BBPATH .= ":${LAYERDIR}"
-
-# We have recipes-* directories, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
- ${LAYERDIR}/recipes-*/*/*.bbappend"
-
-BBFILE_COLLECTIONS += "meta-arm-iota"
-BBFILE_PATTERN_meta-arm-iota = "^${LAYERDIR}/"
-BBFILE_PRIORITY_meta-arm-iota = "6"
-
-LAYERDEPENDS_meta-arm-iota = "core"
-LAYERSERIES_COMPAT_meta-arm-iota = "warrior zeus"
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v5 3/3] btrfs: relocation: Use btrfs_backref_iter infrastructure
From: Josef Bacik @ 2020-02-20 15:09 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218090129.134450-4-wqu@suse.com>
On 2/18/20 4:01 AM, Qu Wenruo wrote:
> In the core function of relocation, build_backref_tree, it needs to
> iterate all backref items of one tree block.
>
> We don't really want to spend our code and reviewers' time to going
> through tons of supportive code just for the backref walk.
>
> Use btrfs_backref_iter infrastructure to do the loop.
>
> The backref items look would be much more easier to read:
>
> ret = btrfs_backref_iter_start(iter, cur->bytenr);
> for (; ret == 0; ret = btrfs_backref_iter_next(iter)) {
> /* The really important work */
> }
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* [MODERATED] Re: [PATCH 0/2] more sampling fun 0
From: mark gross @ 2020-02-20 15:09 UTC (permalink / raw)
To: speck
In-Reply-To: <20200220081420.GA3328448@kroah.com>
On Thu, Feb 20, 2020 at 09:14:20AM +0100, speck for Greg KH wrote:
> On Wed, Feb 19, 2020 at 02:45:22PM -0800, speck for mark gross wrote:
> > From: mark gross <mgross@linux.intel.com>
> > Subject: [PATCH 0/2] Special Register Buffer Data Sampling patch set
> >
> > Special Register Buffer Data Sampling is a sampling type of vulnerability that
> > leaks data across cores sharing the HW-RNG for vulnerable processors.
> >
> > This leak is fixed by a microcode update and is enabled by default.
> >
> > This new microcode serializes processor access during execution of RDRAND
> > or RDSEED. It ensures that the shared buffer is overwritten before it
> > is released for reuse.
> >
> > The mitigation impacts the throughput of the RDRAND and RDSEED instructions
> > and latency of RT processing running on the socket while executing RDRAND or
> > RDSEED. The micro bechmark of calling RDRAND many times shows a 10x slowdown.
>
> Then we need to stop using RDRAND internally for our "give me a random
> number api" which has spread to more and more parts of the kernel.
FWIW even if the opcodes are slowed by 10x there is no human noticable impact
on boot times. IMO its more a risk to RT applications than anything else.
--mark
> Here's a patch that does so:
> https://lore.kernel.org/lkml/20200216161836.1976-1-Jason@zx2c4.com/
> which I'm going to advise get merged now and backported to the stable
> branches.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 15:09 UTC (permalink / raw)
To: Lee Jones
Cc: daniel.thompson, mpartap, jingoohan1, merlijn, martin_rysavy,
kernel list, dri-devel, sre, nekit1000, tomi.valkeinen,
Pavel Machek, jjhiblot, linux-omap, agx, linux-arm-kernel
In-Reply-To: <20200220074849.GF3494@dell>
* Lee Jones <lee.jones@linaro.org> [200220 07:49]:
> On Wed, 19 Feb 2020, Tony Lindgren wrote:
>
> > * Pavel Machek <pavel@ucw.cz> [200219 19:15]:
> > > From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single backlight.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > Acked-by: Lee Jones <lee.jones@linaro.org>
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > > ---
> > > drivers/video/backlight/Kconfig | 7 ++
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/led_bl.c | 260 +++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 268 insertions(+)
> > > create mode 100644 drivers/video/backlight/led_bl.c
> > >
> > > Hi!
> > >
> > > Here's the version of the driver I have. AFAICT
> > > default-brightness-level handling is ok, so does not need to be
> > > changed.
> > >
> > > Lee, it would be easiest for me if you could apply it to your tree and
> > > push, but given enough time I can push it to Linus, too.
> >
> > Oh you're using quoted-printable for patches.. Got it applied now,
> > and it still works. Below is also the related dts change that
> > I tested with.
> >
> > Feel free to pick the dts change too, naturally that should
> > not be applied before the driver.
> >
> > If you guys instead want me to pick these both into my fixes
> > branch, just let me know and I'll do the explaining why these
> > are needed as fixes. Basically we no longer have a way to enable
> > the LCD backlight for droid4 manually starting with v5.6-rc1
> > unlike earlier.
>
> Please do. You already have my Ack.
OK pushed out these two patches in omap-for-v5.6/droid4-lcd-fix.
Thanks,
Tony
_______________________________________________
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 v3 05/10] ASoC: tegra: add Tegra210 based AHUB driver
From: Jon Hunter @ 2020-02-20 15:08 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: devicetree, alsa-devel, atalambedu, lgirdwood, linux-kernel,
viswanathl, sharadg, broonie, thierry.reding, linux-tegra, digetx,
rlokhande, mkumard, dramesh
In-Reply-To: <1582180492-25297-6-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Audio Hub (AHUB) comprises a collection of hardware accelerators for
> audio pre/post-processing and a programmable full crossbar (XBAR) for
> routing audio data across these accelerators in time and in parallel.
> AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a
> switch used to configure or modify audio routing between HW accelerators
> present inside AHUB.
>
> This patch registers AHUB component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes AHUB interfaces, which can be used to connect different
> components in the ASoC layer. Currently the driver takes care of XBAR
> programming to allow audio data flow through various clients of the AHUB.
> Makefile and Kconfig support is added to allow to build the driver. The
> AHUB component can be enabled in the DT via below compatible bindings.
> - "nvidia,tegra210-ahub" for Tegra210
> - "nvidia,tegra186-ahub" for Tegra186 and Tegra194
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_ahub.c | 651 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_ahub.h | 125 ++++++++
> 4 files changed, 788 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_ahub.c
> create mode 100644 sound/soc/tegra/tegra210_ahub.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 15:09 UTC (permalink / raw)
To: Lee Jones
Cc: Pavel Machek, kernel list, linux-arm-kernel, linux-omap, sre,
nekit1000, mpartap, merlijn, martin_rysavy, agx, daniel.thompson,
jingoohan1, dri-devel, tomi.valkeinen, jjhiblot
In-Reply-To: <20200220074849.GF3494@dell>
* Lee Jones <lee.jones@linaro.org> [200220 07:49]:
> On Wed, 19 Feb 2020, Tony Lindgren wrote:
>
> > * Pavel Machek <pavel@ucw.cz> [200219 19:15]:
> > > From: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > >
> > > This patch adds a led-backlight driver (led_bl), which is similar to
> > > pwm_bl except the driver uses a LED class driver to adjust the
> > > brightness in the HW. Multiple LEDs can be used for a single backlight.
> > >
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > > Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
> > > Acked-by: Lee Jones <lee.jones@linaro.org>
> > > Acked-by: Tony Lindgren <tony@atomide.com>
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> > > Signed-off-by: Pavel Machek <pavel@ucw.cz>
> > > ---
> > > drivers/video/backlight/Kconfig | 7 ++
> > > drivers/video/backlight/Makefile | 1 +
> > > drivers/video/backlight/led_bl.c | 260 +++++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 268 insertions(+)
> > > create mode 100644 drivers/video/backlight/led_bl.c
> > >
> > > Hi!
> > >
> > > Here's the version of the driver I have. AFAICT
> > > default-brightness-level handling is ok, so does not need to be
> > > changed.
> > >
> > > Lee, it would be easiest for me if you could apply it to your tree and
> > > push, but given enough time I can push it to Linus, too.
> >
> > Oh you're using quoted-printable for patches.. Got it applied now,
> > and it still works. Below is also the related dts change that
> > I tested with.
> >
> > Feel free to pick the dts change too, naturally that should
> > not be applied before the driver.
> >
> > If you guys instead want me to pick these both into my fixes
> > branch, just let me know and I'll do the explaining why these
> > are needed as fixes. Basically we no longer have a way to enable
> > the LCD backlight for droid4 manually starting with v5.6-rc1
> > unlike earlier.
>
> Please do. You already have my Ack.
OK pushed out these two patches in omap-for-v5.6/droid4-lcd-fix.
Thanks,
Tony
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v3 0/2] net/mlx5: copy the item flags from prefix flow
From: Raslan Darawsheh @ 2020-02-20 15:09 UTC (permalink / raw)
To: Suanming Mou, Matan Azrad, Slava Ovsiienko; +Cc: dev@dpdk.org
In-Reply-To: <1582206824-103222-1-git-send-email-suanmingm@mellanox.com>
Hi,
Series applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
> -----Original Message-----
> From: Suanming Mou <suanmingm@mellanox.com>
> Sent: Thursday, February 20, 2020 3:54 PM
> To: Matan Azrad <matan@mellanox.com>; Slava Ovsiienko
> <viacheslavo@mellanox.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@mellanox.com>
> Subject: [PATCH v3 0/2] net/mlx5: copy the item flags from prefix flow
>
> For flow split to several subflows, the match items maybe in the prefix
> flow, and the actions are split to the suffix flow.
>
> In this case, for the actions need the user defined match item will not
> create correctly.
>
> Copy the item layers flags to the suffix flow from prefix flow to fix
> the issue.
>
> This patch series should be applied after:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> es.dpdk.org%2Fproject%2Fdpdk%2Flist%2F%3Fseries%3D8613&data=0
> 2%7C01%7Crasland%40mellanox.com%7Cf520b39d2d0548ae5d2808d7b60c50
> 1d%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C637178036316184
> 939&sdata=8ZXhPrT27gbXwseF3TAwVbAslh7nOnt3%2FuzilxJblGE%3D&
> amp;reserved=0
>
> v2:
> Remove the actions flag inherit. Get the layer flags accordingly
> based on the actions in prefix flow.
>
> v3:
> Fix NULL pointer issue.
>
> Suanming Mou (2):
> net/mlx5: fix layer flags missing in metadata
> net/mlx5: fix lack of match information in meter
>
> drivers/net/mlx5/mlx5_flow.c | 74
> +++++++++++++++++++++++++++++++++++------
> drivers/net/mlx5/mlx5_flow_dv.c | 59 +++++++++++++++++++++++---------
> 2 files changed, 107 insertions(+), 26 deletions(-)
>
> --
> 1.8.3.1
^ permalink raw reply
* [PATCH 2/2 v3] leds: ns2: Convert to GPIO descriptors
From: Linus Walleij @ 2020-02-20 15:08 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy
Cc: linux-leds, Linus Walleij, Vincent Donnefort, Simon Guinot
In-Reply-To: <20200220150833.56542-1-linus.walleij@linaro.org>
This converts the NS2 LED driver to use GPIO descriptors.
We take care to request the GPIOs "as is" which is what
the current driver goes to lengths to achieve, then we use
GPIOs throughout.
As the nodes for each LED does not have any corresponding
device, we need to use the DT-specific accessors to get these
GPIO descriptors from the device tree.
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Move the header inclusion changes from patch 1/2 into
this patch.
ChangeLog v1->v2:
- Collected Simon's Tested-by tag.
---
drivers/leds/leds-ns2.c | 76 +++++++++++++++++------------------------
1 file changed, 32 insertions(+), 44 deletions(-)
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index aefac3461138..538ca5755602 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -12,11 +12,10 @@
#include <linux/kernel.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
-#include <linux/gpio.h>
+#include <linux/gpio/consumer.h>
#include <linux/leds.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_gpio.h>
#include "leds.h"
enum ns2_led_modes {
@@ -34,8 +33,8 @@ struct ns2_led_modval {
struct ns2_led {
const char *name;
const char *default_trigger;
- unsigned cmd;
- unsigned slow;
+ struct gpio_desc *cmd;
+ struct gpio_desc *slow;
int num_modes;
struct ns2_led_modval *modval;
};
@@ -54,8 +53,8 @@ struct ns2_led_platform_data {
struct ns2_led_data {
struct led_classdev cdev;
- unsigned int cmd;
- unsigned int slow;
+ struct gpio_desc *cmd;
+ struct gpio_desc *slow;
bool can_sleep;
unsigned char sata; /* True when SATA mode active. */
rwlock_t rw_lock; /* Lock GPIOs. */
@@ -71,8 +70,8 @@ static int ns2_led_get_mode(struct ns2_led_data *led_dat,
int cmd_level;
int slow_level;
- cmd_level = gpio_get_value_cansleep(led_dat->cmd);
- slow_level = gpio_get_value_cansleep(led_dat->slow);
+ cmd_level = gpiod_get_value_cansleep(led_dat->cmd);
+ slow_level = gpiod_get_value_cansleep(led_dat->slow);
for (i = 0; i < led_dat->num_modes; i++) {
if (cmd_level == led_dat->modval[i].cmd_level &&
@@ -105,15 +104,15 @@ static void ns2_led_set_mode(struct ns2_led_data *led_dat,
write_lock_irqsave(&led_dat->rw_lock, flags);
if (!led_dat->can_sleep) {
- gpio_set_value(led_dat->cmd,
- led_dat->modval[i].cmd_level);
- gpio_set_value(led_dat->slow,
- led_dat->modval[i].slow_level);
+ gpiod_set_value(led_dat->cmd,
+ led_dat->modval[i].cmd_level);
+ gpiod_set_value(led_dat->slow,
+ led_dat->modval[i].slow_level);
goto exit_unlock;
}
- gpio_set_value_cansleep(led_dat->cmd, led_dat->modval[i].cmd_level);
- gpio_set_value_cansleep(led_dat->slow, led_dat->modval[i].slow_level);
+ gpiod_set_value_cansleep(led_dat->cmd, led_dat->modval[i].cmd_level);
+ gpiod_set_value_cansleep(led_dat->slow, led_dat->modval[i].slow_level);
exit_unlock:
write_unlock_irqrestore(&led_dat->rw_lock, flags);
@@ -201,26 +200,6 @@ create_ns2_led(struct platform_device *pdev, struct ns2_led_data *led_dat,
int ret;
enum ns2_led_modes mode;
- ret = devm_gpio_request_one(&pdev->dev, template->cmd,
- gpio_get_value_cansleep(template->cmd) ?
- GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- template->name);
- if (ret) {
- dev_err(&pdev->dev, "%s: failed to setup command GPIO\n",
- template->name);
- return ret;
- }
-
- ret = devm_gpio_request_one(&pdev->dev, template->slow,
- gpio_get_value_cansleep(template->slow) ?
- GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW,
- template->name);
- if (ret) {
- dev_err(&pdev->dev, "%s: failed to setup slow GPIO\n",
- template->name);
- return ret;
- }
-
rwlock_init(&led_dat->rw_lock);
led_dat->cdev.name = template->name;
@@ -230,8 +209,8 @@ create_ns2_led(struct platform_device *pdev, struct ns2_led_data *led_dat,
led_dat->cdev.groups = ns2_led_groups;
led_dat->cmd = template->cmd;
led_dat->slow = template->slow;
- led_dat->can_sleep = gpio_cansleep(led_dat->cmd) |
- gpio_cansleep(led_dat->slow);
+ led_dat->can_sleep = gpiod_cansleep(led_dat->cmd) |
+ gpiod_cansleep(led_dat->slow);
if (led_dat->can_sleep)
led_dat->cdev.brightness_set_blocking = ns2_led_set_blocking;
else
@@ -286,17 +265,26 @@ ns2_leds_get_of_pdata(struct device *dev, struct ns2_led_platform_data *pdata)
const char *string;
int i, num_modes;
struct ns2_led_modval *modval;
+ struct gpio_desc *gd;
- ret = of_get_named_gpio(child, "cmd-gpio", 0);
- if (ret < 0)
- goto err_node_put;
- led->cmd = ret;
- ret = of_get_named_gpio(child, "slow-gpio", 0);
- if (ret < 0)
- goto err_node_put;
- led->slow = ret;
ret = of_property_read_string(child, "label", &string);
led->name = (ret == 0) ? string : child->name;
+
+ gd = gpiod_get_from_of_node(child, "cmd-gpio", 0,
+ GPIOD_ASIS, led->name);
+ if (IS_ERR(gd)) {
+ ret = PTR_ERR(gd);
+ goto err_node_put;
+ }
+ led->cmd = gd;
+ gd = gpiod_get_from_of_node(child, "slow-gpio", 0,
+ GPIOD_ASIS, led->name);
+ if (IS_ERR(gd)) {
+ ret = PTR_ERR(gd);
+ goto err_node_put;
+ }
+ led->slow = gd;
+
ret = of_property_read_string(child, "linux,default-trigger",
&string);
if (ret == 0)
--
2.24.1
^ permalink raw reply related
* [PATCH 1/2 v3] leds: ns2: Absorb platform data
From: Linus Walleij @ 2020-02-20 15:08 UTC (permalink / raw)
To: Jacek Anaszewski, Pavel Machek, Dan Murphy
Cc: linux-leds, Linus Walleij, Vincent Donnefort, Simon Guinot
Nothing in the kernel includes the external header
<linux/platform_data/leds-kirkwood-ns2.h> so just push the
contents into the ns2 leds driver. If someone wants to use
platform data or board files to describe this device they
should be able to do so using GPIO machine descriptors but
in any case device tree should be the way forward for these
systems in all cases I can think of, and the driver already
supports that.
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v2->v3:
- Move header inclusion changes over to patch 2/2
ChangeLog v1->v2:
- Collect Simon's Tested-by tag
---
drivers/leds/leds-ns2.c | 27 ++++++++++++-
.../linux/platform_data/leds-kirkwood-ns2.h | 38 -------------------
2 files changed, 26 insertions(+), 39 deletions(-)
delete mode 100644 include/linux/platform_data/leds-kirkwood-ns2.h
diff --git a/drivers/leds/leds-ns2.c b/drivers/leds/leds-ns2.c
index 7c500dfdcfa3..aefac3461138 100644
--- a/drivers/leds/leds-ns2.c
+++ b/drivers/leds/leds-ns2.c
@@ -15,11 +15,36 @@
#include <linux/gpio.h>
#include <linux/leds.h>
#include <linux/module.h>
-#include <linux/platform_data/leds-kirkwood-ns2.h>
#include <linux/of.h>
#include <linux/of_gpio.h>
#include "leds.h"
+enum ns2_led_modes {
+ NS_V2_LED_OFF,
+ NS_V2_LED_ON,
+ NS_V2_LED_SATA,
+};
+
+struct ns2_led_modval {
+ enum ns2_led_modes mode;
+ int cmd_level;
+ int slow_level;
+};
+
+struct ns2_led {
+ const char *name;
+ const char *default_trigger;
+ unsigned cmd;
+ unsigned slow;
+ int num_modes;
+ struct ns2_led_modval *modval;
+};
+
+struct ns2_led_platform_data {
+ int num_leds;
+ struct ns2_led *leds;
+};
+
/*
* The Network Space v2 dual-GPIO LED is wired to a CPLD. Three different LED
* modes are available: off, on and SATA activity blinking. The LED modes are
diff --git a/include/linux/platform_data/leds-kirkwood-ns2.h b/include/linux/platform_data/leds-kirkwood-ns2.h
deleted file mode 100644
index eb8a6860e816..000000000000
--- a/include/linux/platform_data/leds-kirkwood-ns2.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Platform data structure for Network Space v2 LED driver
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#ifndef __LEDS_KIRKWOOD_NS2_H
-#define __LEDS_KIRKWOOD_NS2_H
-
-enum ns2_led_modes {
- NS_V2_LED_OFF,
- NS_V2_LED_ON,
- NS_V2_LED_SATA,
-};
-
-struct ns2_led_modval {
- enum ns2_led_modes mode;
- int cmd_level;
- int slow_level;
-};
-
-struct ns2_led {
- const char *name;
- const char *default_trigger;
- unsigned cmd;
- unsigned slow;
- int num_modes;
- struct ns2_led_modval *modval;
-};
-
-struct ns2_led_platform_data {
- int num_leds;
- struct ns2_led *leds;
-};
-
-#endif /* __LEDS_KIRKWOOD_NS2_H */
--
2.24.1
^ permalink raw reply related
* Re: [PATCH] gpio: Switch timestamps to ktime_get_ns()
From: Bartosz Golaszewski @ 2020-02-20 15:08 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-gpio, Arnd Bergmann
In-Reply-To: <20200220150250.46226-1-linus.walleij@linaro.org>
czw., 20 lut 2020 o 16:03 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> The existing use of ktime_get_real_ns() in the timestamps from
> the GPIO events is dubious.
>
> We have had several discussions about this timestamp, and it is
> unclear whether userspace has ever taken into account that a
> timestamp from ktime_get_real_ns() can actually move backwards
> in time relative the previous timetamp, and userspace is more
> likely to expect a monotonic counter.
>
> Background:
> https://lore.kernel.org/linux-gpio/CAK8P3a1Skvm48sje8FNDPLYqyz9Lf8q0qX1QETWtyZTxuX4k1g@mail.gmail.com/
> https://marc.info/?l=linux-gpio&m=151661955709074&w=2
>
> The change is ABI incompatible, but incompatible in a way that
> is IMO more likely to fix future bugs rather than break current
> userspace. To the best of my knowledge all userspace expects
> a monotonic timestamp and users are just lucky that they very
> seldom move backwards in time.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
I too am in favor of this change.
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
^ permalink raw reply
* Re: [PATCH v5 2/3] btrfs: backref: Implement btrfs_backref_iter_next()
From: Josef Bacik @ 2020-02-20 15:08 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218090129.134450-3-wqu@suse.com>
On 2/18/20 4:01 AM, Qu Wenruo wrote:
> This function will go next inline/keyed backref for
> btrfs_backref_iter infrastructure.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: [PATCH v3 05/10] ASoC: tegra: add Tegra210 based AHUB driver
From: Jon Hunter @ 2020-02-20 15:08 UTC (permalink / raw)
To: Sameer Pujar, perex, tiwai, robh+dt
Cc: broonie, lgirdwood, thierry.reding, digetx, alsa-devel,
devicetree, linux-tegra, linux-kernel, sharadg, mkumard,
viswanathl, rlokhande, dramesh, atalambedu
In-Reply-To: <1582180492-25297-6-git-send-email-spujar@nvidia.com>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Audio Hub (AHUB) comprises a collection of hardware accelerators for
> audio pre/post-processing and a programmable full crossbar (XBAR) for
> routing audio data across these accelerators in time and in parallel.
> AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a
> switch used to configure or modify audio routing between HW accelerators
> present inside AHUB.
>
> This patch registers AHUB component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes AHUB interfaces, which can be used to connect different
> components in the ASoC layer. Currently the driver takes care of XBAR
> programming to allow audio data flow through various clients of the AHUB.
> Makefile and Kconfig support is added to allow to build the driver. The
> AHUB component can be enabled in the DT via below compatible bindings.
> - "nvidia,tegra210-ahub" for Tegra210
> - "nvidia,tegra186-ahub" for Tegra186 and Tegra194
>
> Signed-off-by: Sameer Pujar <spujar@nvidia.com>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_ahub.c | 651 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_ahub.h | 125 ++++++++
> 4 files changed, 788 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_ahub.c
> create mode 100644 sound/soc/tegra/tegra210_ahub.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v3 05/10] ASoC: tegra: add Tegra210 based AHUB driver
From: Jon Hunter @ 2020-02-20 15:08 UTC (permalink / raw)
To: Sameer Pujar, perex-/Fr2/VpizcU, tiwai-IBi9RG/b67k,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: broonie-DgEjT+Ai2ygdnm+yROfE0A, lgirdwood-Re5JQEeQqe8AvxtiuMwx3w,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
digetx-Re5JQEeQqe8AvxtiuMwx3w, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
sharadg-DDmLM1+adcrQT0dZR+AlfA, mkumard-DDmLM1+adcrQT0dZR+AlfA,
viswanathl-DDmLM1+adcrQT0dZR+AlfA,
rlokhande-DDmLM1+adcrQT0dZR+AlfA, dramesh-DDmLM1+adcrQT0dZR+AlfA,
atalambedu-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1582180492-25297-6-git-send-email-spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 20/02/2020 06:34, Sameer Pujar wrote:
> The Audio Hub (AHUB) comprises a collection of hardware accelerators for
> audio pre/post-processing and a programmable full crossbar (XBAR) for
> routing audio data across these accelerators in time and in parallel.
> AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a
> switch used to configure or modify audio routing between HW accelerators
> present inside AHUB.
>
> This patch registers AHUB component with ASoC framework. The component
> driver exposes DAPM widgets, routes and kcontrols for the device. The DAI
> driver exposes AHUB interfaces, which can be used to connect different
> components in the ASoC layer. Currently the driver takes care of XBAR
> programming to allow audio data flow through various clients of the AHUB.
> Makefile and Kconfig support is added to allow to build the driver. The
> AHUB component can be enabled in the DT via below compatible bindings.
> - "nvidia,tegra210-ahub" for Tegra210
> - "nvidia,tegra186-ahub" for Tegra186 and Tegra194
>
> Signed-off-by: Sameer Pujar <spujar-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> sound/soc/tegra/Kconfig | 10 +
> sound/soc/tegra/Makefile | 2 +
> sound/soc/tegra/tegra210_ahub.c | 651 ++++++++++++++++++++++++++++++++++++++++
> sound/soc/tegra/tegra210_ahub.h | 125 ++++++++
> 4 files changed, 788 insertions(+)
> create mode 100644 sound/soc/tegra/tegra210_ahub.c
> create mode 100644 sound/soc/tegra/tegra210_ahub.h
Aside from Randy's comment ...
Reviewed-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cheers
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Corey Minyard @ 2020-02-20 14:52 UTC (permalink / raw)
To: Daniel Thompson
Cc: Catalin Marinas, Will Deacon, linux-kernel, linux-arm-kernel,
Corey Minyard
In-Reply-To: <20200220140650.tryvv3ishkxduujk@holly.lan>
On Thu, Feb 20, 2020 at 02:06:50PM +0000, Daniel Thompson wrote:
> On Wed, Feb 19, 2020 at 09:24:03AM -0600, minyard@acm.org wrote:
> > From: Corey Minyard <cminyard@mvista.com>
> >
> > I was working on a single-step bug on kgdb on an ARM64 system, and I saw
> > this scenario:
> >
> > * A single step is setup to return to el1
> > * The ERET return to el1
> > * An interrupt is pending and runs before the instruction
> > * As soon as PSTATE.D (the debug disable bit) is cleared, the single
> > step happens in that location, not where it should have.
> >
> > This appears to be due to PSTATE.SS not being cleared when the exception
> > happens. Per section D.2.12.5 of the ARMv8 reference manual, that
> > appears to be incorrect, it says "As part of exception entry, the PE
> > does all of the following: ... Sets PSTATE.SS to 0."
> >
> > However, I appear to not be the first person who has noticed this. In
> > the el0-only portion of the kernel_entry macro in entry.S, I found the
> > following comment: "Ensure MDSCR_EL1.SS is clear, since we can unmask
> > debug exceptions when scheduling." Exactly the same scenario, except
> > coming from a userland single step, not a kernel one.
> >
> > As I was studying this, though, I realized that the following scenario
> > had an issue:
> >
> > * Kernel enables MDSCR.SS, MDSCR.KDE, MDSCR.MDE (unnecessary), and
> > PSTATE.SS to enable a single step in el1, for kgdb or kprobes,
> > on the current CPU's MDSCR register and the process' PSTATE.SS
> > register.
> > * Kernel returns from the exception with ERET.
> > * An interrupt or page fault happens on the instruction, causing the
> > instruction to not be run, but the exception handler runs.
> > * The exception causes the task to migrate to a new core.
> > * The return from the exception runs on a different processor now,
> > where the MDSCR values are not set up for a single step.
> > * The single step fails to happen.
> >
> > This is bad for kgdb, of course, but it seems really bad for kprobes if
> > this happens.
> >
> > To fix both these problems, rework the handling of single steps to clear
> > things out upon entry to the kernel from el1, and then to set up single
> > step when returning to el1, and not do the setup in debug-monitors.c.
> > This means that single stepping does not use
> > enable/disable_debug_monitors(); it is no longer necessary to track
> > those flags for single stepping. This is much like single stepping is
> > handled for el0. A new flag is added in pt_regs to enable single
> > stepping from el1. Unfortunately, the old value of PSTATE.SS cannot be
> > used for this because of the hardware bug mentioned earlier.
> >
> > As part of this, there is an interaction between single stepping and the
> > other users of debug monitors with the MDSCR.KDE bit. That bit has to
> > be set for both hardware breakpoints at el1 and single stepping at el1.
> > A new variable was created to store the cpu-wide value of MDSCR.KDE; the
> > single stepping code makes sure not to clear that bit on kernel entry if
> > it's set in the per-cpu variable.
> >
> > After fixing this and doing some more testing, I ran into another issue:
> >
> > * Kernel enables the pt_regs single step
> > * Kernel returns from the exception with ERET.
> > * An interrupt or page fault happens on the instruction, causing the
> > instruction to not be run, but the exception handler runs.
> > * The exception handling hits a breakpoint and stops.
> > * The user continues from the breakpoint, so the kernel is no longer
> > expecting a single step.
> > * On the return from the first exception, the single step flag in
> > pt_regs is still set, so a single step trap happens.
> > * The kernel keels over from an unexpected single step.
> >
> > There's no easy way to find the pt_regs that has the single step flag
> > set. So a thread info flag was added so that the single step could be
> > disabled in this case. Both that flag and the flag in pt_regs must be
> > set to enable a single step.
> >
> > Signed-off-by: Corey Minyard <cminyard@mvista.com>
>
> I've pointed the kgdbtest suite at this patch (and run one of the
> historically unstable test cases an extra 100 times just in case).
>
> kgdbtest hasn't got great coverage, runs the code in qemu and some
> of the strongest tests are still marked XFAIL on arm64 (for reasons
> unrelated to stepping).
>
> So the best I can say based on the above is that the test suite does not
> observe any regression (but equally no improvement). Nevertheless FWIW:
Thanks for testing this. This is not a surprise, you would either have
to have a broken processor like the one I'm using, or you would have to
have a migration occur on the instruction being single-stepped, which
would be extremely unlikely.
Since I've already gained some experience here, I'll try to look at
fixing things here for ARM64.
-corey
>
>
> Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
>
>
> Daniel.
_______________________________________________
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 v2] sh4: Fix PCI ISA IO memory subregion
From: Peter Maydell @ 2020-02-20 15:06 UTC (permalink / raw)
To: Guenter Roeck; +Cc: QEMU Developers, Aurelien Jarno
In-Reply-To: <20200218201050.15273-1-linux@roeck-us.net>
On Tue, 18 Feb 2020 at 20:10, Guenter Roeck <linux@roeck-us.net> wrote:
>
> Booting the r2d machine from flash fails because flash is not discovered.
> Looking at the flattened memory tree, we see the following.
>
> FlatView #1
> AS "memory", root: system
> AS "cpu-memory-0", root: system
> AS "sh_pci_host", root: bus master container
> Root memory region: system
> 0000000000000000-000000000000ffff (prio 0, i/o): io
> 0000000000010000-0000000000ffffff (prio 0, i/o): r2d.flash @0000000000010000
>
> The overlapping memory region is sh_pci.isa, ie the ISA I/O region bridge.
> This region is initially assigned to address 0xfe240000, but overwritten
> with a write into the PCIIOBR register. This write is expected to adjust
> the PCI memory window, but not to change the region's base adddress.
>
> Peter Maydell provided the following detailed explanation.
>
> "Section 22.3.7 and in particular figure 22.3 (of "SSH7751R user's manual:
> hardware") are clear about how this is supposed to work: there is a window
> at 0xfe240000 in the system register space for PCI I/O space. When the CPU
> makes an access into that area, the PCI controller calculates the PCI
> address to use by combining bits 0..17 of the system address with the
> bits 31..18 value that the guest has put into the PCIIOBR. That is, writing
> to the PCIIOBR changes which section of the IO address space is visible in
> the 0xfe240000 window. Instead what QEMU's implementation does is move the
> window to whatever value the guest writes to the PCIIOBR register -- so if
> the guest writes 0 we put the window at 0 in system address space."
>
> Fix the problem by calling memory_region_set_alias_offset() instead of
> removing and re-adding the PCI ISA subregion on writes into PCIIOBR.
> At the same time, in sh_pci_device_realize(), don't set iobr since
> it is overwritten later anyway. Instead, pass the base address to
> memory_region_add_subregion() directly.
>
> Many thanks to Peter Maydell for the detailed problem analysis, and for
> providing suggestions on how to fix the problem.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
I'll put this in via target-arm.next, since we don't really
have a more active sh4-specific tree to send it via.
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH] backlight: add led-backlight driver
From: Tony Lindgren @ 2020-02-20 14:54 UTC (permalink / raw)
To: Sebastian Reichel
Cc: daniel.thompson, mpartap, jingoohan1, merlijn, kernel list,
dri-devel, martin_rysavy, nekit1000, tomi.valkeinen, Pavel Machek,
jjhiblot, linux-omap, Lee Jones, agx, linux-arm-kernel
In-Reply-To: <20200219234437.l6ac7usebu7rnzsy@earth.universe>
* Sebastian Reichel <sre@kernel.org> [200219 23:45]:
> Finally :)
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Yeah thanks for your persistent effort on getting this working :)
Regards,
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: drm_dp_mst_topology.c and old compilers
From: Christoph Hellwig @ 2020-02-20 15:07 UTC (permalink / raw)
To: Paul E. McKenney
Cc: maarten.lankhorst, mripard, airlied, daniel, dri-devel,
linux-kernel
In-Reply-To: <20200220004232.GA28048@paulmck-ThinkPad-P72>
On Wed, Feb 19, 2020 at 04:42:33PM -0800, Paul E. McKenney wrote:
> - struct drm_dp_desc desc = { 0 };
> + struct drm_dp_desc desc = {{{ 0 }}};
Does:
struct drm_dp_desc desc = { };
work for your geriatric compiler?
^ permalink raw reply
* Re: [PATCH v5 1/3] btrfs: backref: Introduce the skeleton of btrfs_backref_iter
From: Josef Bacik @ 2020-02-20 15:07 UTC (permalink / raw)
To: Qu Wenruo, linux-btrfs; +Cc: Johannes Thumshirn
In-Reply-To: <20200218090129.134450-2-wqu@suse.com>
On 2/18/20 4:01 AM, Qu Wenruo wrote:
> Due to the complex nature of btrfs extent tree, when we want to iterate
> all backrefs of one extent, it involves quite a lot of work, like
> searching the EXTENT_ITEM/METADATA_ITEM, iteration through inline and keyed
> backrefs.
>
> Normally this would result pretty complex code, something like:
> btrfs_search_slot()
> /* Ensure we are at EXTENT_ITEM/METADATA_ITEM */
> while (1) { /* Loop for extent tree items */
> while (ptr < end) { /* Loop for inlined items */
> /* REAL WORK HERE */
> }
> next:
> ret = btrfs_next_item()
> /* Ensure we're still at keyed item for specified bytenr */
> }
>
> The idea of btrfs_backref_iter is to avoid such complex and hard to
> read code structure, but something like the following:
>
> iter = btrfs_backref_iter_alloc();
> ret = btrfs_backref_iter_start(iter, bytenr);
> if (ret < 0)
> goto out;
> for (; ; ret = btrfs_backref_iter_next(iter)) {
> /* REAL WORK HERE */
> }
> out:
> btrfs_backref_iter_free(iter);
>
> This patch is just the skeleton + btrfs_backref_iter_start() code.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: [RESEND PATCH v6 6/7] gpiolib: add new ioctl() for monitoring changes in line info
From: Bartosz Golaszewski @ 2020-02-20 15:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Arnd Bergmann, Kent Gibson, Andy Shevchenko,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org,
Bartosz Golaszewski
In-Reply-To: <CACRpkdZE0F_E1o-psXdOh93j1JAS8uqT=ZOf4-mrj5WKoKcD6A@mail.gmail.com>
czw., 20 lut 2020 o 16:03 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> On Wed, Feb 12, 2020 at 12:00 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > On Tue, Feb 11, 2020 at 10:19 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > > > From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> > > A question:
> > >
> > > Bartosz, since you know about possible impacts on userspace,
> > > since this code use the preferred ktime_get_ns() rather than
> > > ktime_get_ns_real(), what happens if we just patch the other
> > > event timestamp to use ktime_get_ns() instead, so we use the
> > > same everywhere?
> > >
> > > If it's fine I'd like to just toss in a patch for that as well.
> > >
> >
> > Arnd pointed out it would be an incompatible ABI change[1].
>
> Yeah, I was thinking more about this specific answer from Arnd:
>
> > "It is an incompatible ABI change, the question here is whether anyone
> > actually cares. If nothing relies on the timestamps being in
> > CLOCK_REALTIME domain, then it can be changed, the question
> > is just how you want to prove that this is the case."
>
> So the question is if userspace really cares.
>
> What happens with libgpiod or users of it? Are they assuming
> the weirdness of CLOCK_REALTIME, or are they simply assuming
> something that is monotonic increasing and just lucky that they
> didn't run into anything jumping backwards in time even though
> they *could*.
>
> I think I'll propose a change and see what people say.
>
Libgpiod doesn't care about the value really - it just forwards
whatever it reads.
Bart
> > However - I asked Khouloud who's working on v2 of the line event
> > interface to use ktime_get_ns().
>
> That's great!
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Marc Zyngier @ 2020-02-20 15:06 UTC (permalink / raw)
To: minyard
Cc: Corey Minyard, Catalin Marinas, linux-kernel, Will Deacon,
Corey Minyard, linux-arm-kernel
In-Reply-To: <20200220145048.GH3704@minyard.net>
On 2020-02-20 14:50, Corey Minyard wrote:
> On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
>> On 2020-02-19 15:24, minyard@acm.org wrote:
>> > From: Corey Minyard <cminyard@mvista.com>
>>
>> [...]
>>
>> > After studying the EL0 handling for this, I realized an issue with using
>> > MDSCR to check if single step is enabled: it can be expensive on a VM.
>> > So check the task flag first to see if single step is enabled. Then
>> > check MDSCR if the task flag is set.
>>
>> Very tangential remark: I'd really like people *not* to try and
>> optimize
>> Linux based on the behaviour of a hypervisor. In general, reading a
>> system register is fast, and the fact that it traps on a given
>> hypervisor
>> at some point may not be true in the future, nor be a valid assumption
>> across hypervisors.
>
> Normally I would agree, but I based this upon git commit
> https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
> which seemed to say that it was a significant enough factor to do in
> the
> EL0 case.
And that's a blast from a distant past. Hypervisors have changed
drastically
over these 6 years, and I'm still sitting on a bunch of patches that
*could*
change the way MDSCR_EL1 is handled.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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 v2 0/2] hw/arm/xilinx_zynq: Fix USB port instantiation
From: Peter Maydell @ 2020-02-20 15:05 UTC (permalink / raw)
To: Guenter Roeck
Cc: Edgar E . Iglesias, Alistair Francis, Gerd Hoffmann, qemu-arm,
QEMU Developers
In-Reply-To: <20200215122354.13706-1-linux@roeck-us.net>
On Sat, 15 Feb 2020 at 12:23, Guenter Roeck <linux@roeck-us.net> wrote:
>
> USB ports on Xilinx Zync must be instantiated as TYPE_CHIPIDEA to work.
> Linux expects and checks various chipidea registers, which do not exist
> with the basic ehci emulation. This patch series fixes the problem.
>
> The first patch in the series fixes the actual problem.
>
> The second patch removes the now obsolete explicit Xilinx
> support from the EHCI code.
>
> v2: Introduced summary
>
> ----------------------------------------------------------------
> Guenter Roeck (2):
> hw/arm/xilinx_zynq: Fix USB port instantiation
> hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx,ps7-usb class
Xilinx folks -- could you provide a reviewed-by or acked-by
for this series, please?
thanks
-- PMM
^ permalink raw reply
* Re: [PATCH v2] arm64:kgdb: Fix kernel single-stepping
From: Marc Zyngier @ 2020-02-20 15:06 UTC (permalink / raw)
To: minyard
Cc: Will Deacon, Catalin Marinas, linux-arm-kernel, Corey Minyard,
linux-kernel, Corey Minyard
In-Reply-To: <20200220145048.GH3704@minyard.net>
On 2020-02-20 14:50, Corey Minyard wrote:
> On Thu, Feb 20, 2020 at 02:21:36PM +0000, Marc Zyngier wrote:
>> On 2020-02-19 15:24, minyard@acm.org wrote:
>> > From: Corey Minyard <cminyard@mvista.com>
>>
>> [...]
>>
>> > After studying the EL0 handling for this, I realized an issue with using
>> > MDSCR to check if single step is enabled: it can be expensive on a VM.
>> > So check the task flag first to see if single step is enabled. Then
>> > check MDSCR if the task flag is set.
>>
>> Very tangential remark: I'd really like people *not* to try and
>> optimize
>> Linux based on the behaviour of a hypervisor. In general, reading a
>> system register is fast, and the fact that it traps on a given
>> hypervisor
>> at some point may not be true in the future, nor be a valid assumption
>> across hypervisors.
>
> Normally I would agree, but I based this upon git commit
> https://github.com/torvalds/linux/commit/2a2830703a2371b47f7b50b1d35cb15dc0e2b717
> which seemed to say that it was a significant enough factor to do in
> the
> EL0 case.
And that's a blast from a distant past. Hypervisors have changed
drastically
over these 6 years, and I'm still sitting on a bunch of patches that
*could*
change the way MDSCR_EL1 is handled.
M.
--
Jazz is not dead. It just smells funny...
^ 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.