* Re: [Intel-gfx] [PATCH 00/12] drm: Put drm_display_mode on diet
From: Ville Syrjälä @ 2020-02-20 15:34 UTC (permalink / raw)
To: Emil Velikov; +Cc: Intel Graphics Development, ML dri-devel
In-Reply-To: <20200220142759.GA13686@intel.com>
On Thu, Feb 20, 2020 at 04:27:59PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2020 at 01:21:03PM +0000, Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 20:35, Ville Syrjala
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > struct drm_display_mode is extremely fat. Put it on diet.
> > >
> > > Some stats for the whole series:
> > >
> > > 64bit sizeof(struct drm_display_mode):
> > > 200 -> 136 bytes (-32%)
> > >
> > > 64bit bloat-o-meter -c drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
> > > Function old new delta
> > > ...
> > > Total: Before=189430, After=188779, chg -0.34%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=11667, After=11667, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 1000 680 -320
> > > edid_est_modes 3400 2312 -1088
> > > edid_cea_modes_193 5400 3672 -1728
> > > drm_dmt_modes 17600 11968 -5632
> > > edid_cea_modes_1 25400 17272 -8128
> > > Total: Before=71239, After=54343, chg -23.72%
> > >
> > >
> > > 64bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 29/52 up/down: 893/-18440 (-17547)
> > > ...
> > > Total: Before=272336, After=254789, chg -6.44%
> > >
> > >
> > > 32bit sizeof(struct drm_display_mode):
> > > 184 -> 120 bytes (-34%)
> > >
> > > 32bit bloat-o-meter -c drm.ko
> > > add/remove: 1/0 grow/shrink: 19/21 up/down: 743/-1368 (-625)
> > > Function old new delta
> > > ...
> > > Total: Before=172359, After=171734, chg -0.36%
> > > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > > Data old new delta
> > > Total: Before=4227, After=4227, chg +0.00%
> > > add/remove: 0/0 grow/shrink: 0/5 up/down: 0/-16896 (-16896)
> > > RO Data old new delta
> > > edid_4k_modes 920 600 -320
> > > edid_est_modes 3128 2040 -1088
> > > edid_cea_modes_193 4968 3240 -1728
> > > drm_dmt_modes 16192 10560 -5632
> > > edid_cea_modes_1 23368 15240 -8128
> > > Total: Before=59230, After=42334, chg -28.53%
> > >
> > > 32bit bloat-o-meter drm.ko:
> > > add/remove: 1/0 grow/shrink: 19/26 up/down: 743/-18264 (-17521)
> > > ...
> > > Total: Before=235816, After=218295, chg -7.43%
> > >
> > >
> > > Some ideas for further reduction:
> > > - Convert mode->name to a pointer (saves 24/28 bytes in the
> > > struct but would often require a heap alloc for the name (though
> > > typical mode name is <10 bytes so still overall win perhaps)
> > > - Get rid of mode->name entirely? I guess setcrtc & co. is the only
> > > place where we have to preserve the user provided name, elsewhere
> > > could pehaps just generate on demand? Not sure how tricky this
> > > would get.
> >
> > The series does some great work, with future work reaching the cache
> > line for 64bit.
> > Doing much more than that might be an overkill IMHO.
> >
> > In particular, if we change DRM_DISPLAY_MODE_LEN to 24 we get there,
> > avoiding the heap alloc/calc on demand fun.
> > While also ensuring the name is sufficiently large for the next decade or so.
>
> Unfortunately it's part of the uabi. So can't change it without some
> risk of userspace breakage.
>
> The least demanding option is probably to nuke export_head. We need
> one bit to replace it, which we can get by either:
> - stealing from eg. mode->type, or perhaps mode->private_flags
> - nuke private_flags outright and replace it with a bool for this
> purpose
Looks like getting rid of private_flags is going to be pretty
straightforward. I'll post patches for that once this first series
lands.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] arm64: dts: meson: fix gxm-khadas-vim2 wifi
From: Christian Hewitt @ 2020-02-20 15:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Art Nikpal, Christian Hewitt
Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies")
before
[6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000
[6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
after
[6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c
Suggested-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index f82f25c..d5dc128 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -327,7 +327,7 @@
#size-cells = <0>;
bus-width = <4>;
- max-frequency = <50000000>;
+ max-frequency = <60000000>;
non-removable;
disable-wp;
--
2.7.4
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
^ permalink raw reply related
* [PATCH] arm64: dts: meson: fix gxm-khadas-vim2 wifi
From: Christian Hewitt @ 2020-02-20 15:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Art Nikpal, Christian Hewitt
Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies")
before
[6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000
[6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
after
[6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c
Suggested-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index f82f25c..d5dc128 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -327,7 +327,7 @@
#size-cells = <0>;
bus-width = <4>;
- max-frequency = <50000000>;
+ max-frequency = <60000000>;
non-removable;
disable-wp;
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] btrfs: add test case for newly supported cases of cloning inline extents
From: Josef Bacik @ 2020-02-20 15:34 UTC (permalink / raw)
To: fdmanana, fstests; +Cc: linux-btrfs, Filipe Manana
In-Reply-To: <20200219140641.1642570-1-fdmanana@kernel.org>
On 2/19/20 9:06 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> Test several scenarios of cloning operations where the source range includes
> inline extents. They used to not be supported on btrfs because their
> implementation was not straightforward, and therefore these operations used
> to fail with errno EOPNOTSUPP on older kernels.
>
> This currently fails on any released kernel. It passes only when the patch
> with the following subject is applied:
>
> "Btrfs: implement full reflink support for inline extents"
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: mvneta: comphy regression with SolidRun ClearFog
From: Joel Johnson @ 2020-02-20 15:34 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: David S. Miller, Baruch Siach, Gregory Clement, Thomas Petazzoni,
Rob Herring, netdev
In-Reply-To: <20200220101232.GU25745@shell.armlinux.org.uk>
On 2020-02-20 03:12, Russell King - ARM Linux admin wrote:
> On Wed, Feb 19, 2020 at 06:49:51AM -0700, Joel Johnson wrote:
>> On 2020-02-19 02:22, Russell King - ARM Linux admin wrote:
>> > On Tue, Feb 18, 2020 at 10:14:48PM -0700, Joel Johnson wrote:
>> > Does debian have support for the comphy enabled in their kernel,
>> > which is controlled by CONFIG_PHY_MVEBU_A38X_COMPHY ?
>>
>> Well, doh! I stared at the patch series for way to long, but the added
>> Kconfig symbol failed to register mentally somehow. I had been using
>> the
>> last known good Debian config with make olddefconfig, but it obviously
>> wasn't included in earlier configs and not enabled by default.
>>
>> Many thanks to you and Willy Tarreau for pointing out my glaring
>> omission!
>
> Thanks for letting us know that you've fixed it now.
Sure thing, I've submitted a Debian patch, and was pointed to an
existing Debian bug with the same issue and patch, so hopefully that
will get incorporated soon. I'll also keep an eye on OpenWRT when they
move to an affected kernel version to make sure it's included.
One lingering question that wasn't clear to me is the apparent
inconsistency in default enablement for PHYs in
drivers/phy/marvell/Kconfig. Is there a technical reason why
PHY_MVEBU_A3700_COMPHY defaults to 'y' but PHY_MVEBU_A38X_COMPHY (and
PHY_MVEBU_CP110_COMPHY) default to 'n', or is it just an artifact of
being added at different times? Similarly, is there a reason that
PHY_MVEBU_A3700_COMPHY and PHY_MVEBU_A3700_UTMI default to 'y' instead
of 'm' for all ARCH_MVEBU builds? In my testing, building with
PHY_MVEBU_A38X_COMPHY as a module still seemed to autoload the module as
needed on boot, so modules for different platforms seems off-hand more
lightweight that building the driver in for all MVEBU boards which don't
use all drivers.
With the current defaults, it seems like PHY_MVEBU_CP110_COMPHY may be
affected in Debian the same way as PHY_MVEBU_A38X_COMPHY, but I don't
have available Armada 7K/8K hardware yet to confirm.
Joel
^ permalink raw reply
* [PATCH] arm64: dts: meson: fix gxm-khadas-vim2 wifi
From: Christian Hewitt @ 2020-02-20 15:33 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Kevin Hilman, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
Cc: Christian Hewitt, Art Nikpal
Fixes: adc52bf7ef16 ("arm64: dts: meson: fix mmc v2 chips max frequencies")
before
[6.418252] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.435663] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.551259] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[6.551275] brcmfmac: brcmf_sdio_verifymemory: error -84 on reading 2048 membytes at 0x00184000
[6.551352] brcmfmac: brcmf_sdio_download_firmware: dongle image file download failed
after
[6.657165] brcmfmac: F1 signature read @0x18000000=0x17224356
[6.660807] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918643] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4356-sdio for chip BCM4356/2
[6.918734] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[6.922724] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4356/2 wl0: Jun 16 2015 14:25:06 version 7.35.184.r1 (TOB) (r559293) FWID 01-b22ae69c
Suggested-by: Art Nikpal <email2tema@gmail.com>
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
index f82f25c..d5dc128 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts
@@ -327,7 +327,7 @@
#size-cells = <0>;
bus-width = <4>;
- max-frequency = <50000000>;
+ max-frequency = <60000000>;
non-removable;
disable-wp;
--
2.7.4
^ permalink raw reply related
* Re: [Intel-gfx] [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä @ 2020-02-20 15:33 UTC (permalink / raw)
To: Emil Velikov
Cc: linux-arm-msm, Intel Graphics Development, freedreno,
ML dri-devel
In-Reply-To: <CACvgo50oWkF8vjpGmOYSwaK+khZuAE0yW_npf2UEMQoRTokLBA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:24:20AM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags from the tracepoint.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Perhaps the msm team has a WIP which makes use of it ?
Maybe if it's one of them five year projects. But anyways,
with an atomic driver there are certainly better ways to
handle this.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä @ 2020-02-20 15:33 UTC (permalink / raw)
To: Emil Velikov
Cc: Sean Paul, linux-arm-msm, Intel Graphics Development, freedreno,
ML dri-devel
In-Reply-To: <CACvgo50oWkF8vjpGmOYSwaK+khZuAE0yW_npf2UEMQoRTokLBA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:24:20AM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags from the tracepoint.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Perhaps the msm team has a WIP which makes use of it ?
Maybe if it's one of them five year projects. But anyways,
with an atomic driver there are certainly better ways to
handle this.
--
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: NVMe/IB support
From: Christoph Hellwig @ 2020-02-20 15:33 UTC (permalink / raw)
To: Max Gurtovoy; +Cc: Christoph Hellwig, Talker Alex, linux-nvme
In-Reply-To: <cd2f6306-1c4e-848c-9075-f89ce5f3a9ac@mellanox.com>
On Thu, Feb 20, 2020 at 05:16:35PM +0200, Max Gurtovoy wrote:
> Are you saying that if one would like to use ADRFAM == AF_IB, he must have
> RDMA/CM stack that support IB addressing ?
Yes.
> seems little bit weird requirement...
NVMeoF/RDMA is specified to use RDMA/CM for connection management.
There is no reason we could not also specify it on raw IB, but someone
would have to do the work and specify a binding for it.
_______________________________________________
linux-nvme mailing list
linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply
* Re: [PATCH 05/12] drm/msm/dpu: Stop copying around mode->private_flags
From: Ville Syrjälä @ 2020-02-20 15:33 UTC (permalink / raw)
To: Emil Velikov
Cc: ML dri-devel, linux-arm-msm, Intel Graphics Development,
freedreno, Sean Paul
In-Reply-To: <CACvgo50oWkF8vjpGmOYSwaK+khZuAE0yW_npf2UEMQoRTokLBA@mail.gmail.com>
On Thu, Feb 20, 2020 at 11:24:20AM +0000, Emil Velikov wrote:
> On Wed, 19 Feb 2020 at 20:36, Ville Syrjala
> <ville.syrjala@linux.intel.com> wrote:
> >
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > The driver never sets mode->private_flags so copying
> > it back and forth is entirely pointless. Stop doing it.
> >
> > Also drop private_flags from the tracepoint.
> >
> > Cc: Rob Clark <robdclark@gmail.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: linux-arm-msm@vger.kernel.org
> > Cc: freedreno@lists.freedesktop.org
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Perhaps the msm team has a WIP which makes use of it ?
Maybe if it's one of them five year projects. But anyways,
with an atomic driver there are certainly better ways to
handle this.
--
Ville Syrjälä
Intel
^ permalink raw reply
* [igt-dev] [PATCH i-g-t] intel-ci: add a pre-merge blacklist to reduce the testing queue
From: Martin Peres @ 2020-02-20 15:32 UTC (permalink / raw)
To: igt-dev
When arriving at the office on Monday morning, the reported queue
size was ~100 hours. This defeats the point of pre-merge testing and
vastly exceeds our target of ~6 hours.
We have a lot of work needed to reduce testing time, but this patches
reduces the reported run time by 15-30% depending on the platforms:
- shard-skl: 23.9 -> 18.2 minutes (18.5%)
- shard-kbl: 21.2 -> 16.2 minutes (20%)
- shard-apl: 25.9 -> 18.5 minutes (24.3%)
- shard-glk: 24.7 -> 17.6 minutes (24.8%)
- shard-icl: 25.1 -> 16.7 minutes (28.7%)
- shard-tgl: 28.2 -> 19.6 minutes (26.4%)
The reason why the reported runtime is so low compared to the
actual time is due to:
- Unaccounted time spent outside of the IGT subtests (exec(), fixtures)
- Unaccounted time spent in suspend (monotonic clock, 20s / suspend)
- Boot time / extra reboots between shards to workaround kernel failures
- Intel GFX CI shard scheduling overhead
- More?
Tomi and Petri are working on reducing these overheads by detecting the
bad conditions and rebooting the machine only at this point rather than
between every single shard, and increasing the size of the shard test
lists to reduce the per-shard CI overhead.
Because of this, the actual savings are way smaller in percentage
but still compound over the tens of executions we do per week:
- shard-skl: ~58 -> ~52 minutes
- shard-kbl: ~50 -> ~45 minutes
- shard-apl: ~53 -> ~46 minutes
- shard-glk: ~38 -> ~31 minutes
- shard-icl: ~47 -> ~39 minutes
- shard-tgl: ~60 -> ~51 minutes
More work needed, but we'll get there :)
Signed-off-by: Martin Peres <martin.peres@linux.intel.com>
---
tests/intel-ci/README | 7 +
tests/intel-ci/blacklist-pre-merge.txt | 221 +++++++++++++++++++++++++
2 files changed, 228 insertions(+)
create mode 100644 tests/intel-ci/blacklist-pre-merge.txt
diff --git a/tests/intel-ci/README b/tests/intel-ci/README
index e3289933..07b32b54 100644
--- a/tests/intel-ci/README
+++ b/tests/intel-ci/README
@@ -37,6 +37,13 @@ blacklist.txt
This file contains regular expressions (one per line) for tests that
are not to be executed in full suite test rounds.
+=======================
+blacklist-pre-merge.txt
+=======================
+
+This file contains regular expressions (one per line) for tests that
+are not to be executed in pre-merge full suite test rounds.
+
=============
meta.testlist
=============
diff --git a/tests/intel-ci/blacklist-pre-merge.txt b/tests/intel-ci/blacklist-pre-merge.txt
new file mode 100644
index 00000000..45fded33
--- /dev/null
+++ b/tests/intel-ci/blacklist-pre-merge.txt
@@ -0,0 +1,221 @@
+###############################################################################
+# This test has caught regressions in the past, but the feature is rarely used
+# by our users, yet it is responsible a significant portion of our execution
+# time:
+#
+# - shard-skl: 10.2% (~22 minutes)
+# - shard-kbl: 6% (~8 minutes)
+# - shard-apl: 3.9% (~7 minutes)
+# - shard-glk: 8% (~18 minutes)
+# - shard-icl: 11% (~22 minutes)
+# - shard-tgl: 7.1% (~14 minutes)
+#
+# Data acquired on 2020-02-19 by Martin Peres
+###############################################################################
+igt@kms_rotation_crc@.*
+
+
+###############################################################################
+# These 4 tests catching a lot of unrelated issues and are responsible for a
+# significant portion of our execution time:
+#
+# - shard-skl: 1.6% (~4 minutes)
+# - shard-kbl: 0.4% (30 seconds)
+# - shard-apl: 0.2% (20 seconds)
+# - shard-glk: 0.2% (30 seconds)
+# - shard-icl: 6% (~12 minutes)
+# - shard-tgl: 6% (~12 minutes)
+#
+# Data acquired on 2020-02-19 by Martin Peres
+###############################################################################
+igt@i915_pm_rpm@(legacy|universal)-planes(-dpms)?
+
+
+###############################################################################
+# These 8 tests are responsible for a significant portion of our execution time
+# despite them testing a feature which is only found in older userspaces:
+#
+# - shard-skl: 0.1% (~15 seconds)
+# - shard-kbl: 3.5% (~4.5 minutes)
+# - shard-apl: 10% (~18 minutes)
+# - shard-glk: 6.3% (~14 minutes)
+# - shard-icl: 1.7% (~3.5 minutes)
+# - shard-tgl: 1.6% (~3 minutes)
+#
+# Data acquired on 2020-02-19 by Martin Peres
+###############################################################################
+igt@gem_pwrite@big-.*
+
+
+###############################################################################
+# These 4 tests are covering an edge case which should never be hit by users
+# unless we already are in a bad situation, yet they are responsible for a
+# significant portion of our execution time:
+#
+# - shard-skl: 2% (~5 minutes)
+# - shard-kbl: 4% (~5 minutes)
+# - shard-apl: 2.7% (~5 minutes)
+# - shard-glk: 4.5% (~10 minutes)
+# - shard-icl: 2.5% (~5 minutes)
+# - shard-tgl: 3.5% (~7 minutes)
+#
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@kms_flip@flip-vs-(modeset|panning)-vs-hang(-interruptible)?
+
+
+###############################################################################
+# These 28 tests are covering an edge case which should never be hit by users
+# unless we already are in a bad situation, yet they are responsible for a
+# significant portion of our execution time:
+#
+# - shard-skl: 1.7% (~4 minutes)
+# - shard-kbl: 2.8% (~3.5 minutes)
+# - shard-apl: 2.2% (~4 minutes)
+# - shard-glk: 1.8% (~4 minutes)
+# - shard-icl: 1.9% (~4 minutes)
+# - shard-tgl: 2.8% (~5.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@kms_busy@.*hang.*
+
+
+###############################################################################
+# This test is reading one file at a time while being suspended, which makes
+# testing extremelly slow. This is somewhat of an edge case that is unlikely
+# to be hit, hence why it could be dropped from pre-merge testing. Here are the
+# execution time statistics:
+#
+# - shard-skl: 0.5% (~1 minute)
+# - shard-kbl: 0.1% (~2 seconds)
+# - shard-apl: 0.1% (~2 seconds)
+# - shard-glk: 0.1% (~2 seconds)
+# - shard-icl: 0.6% (~1.5 minutes)
+# - shard-tgl: 0.7% (~1.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@i915_pm_rpm@debugfs-read
+
+
+###############################################################################
+# Perf tests are for people using performance counters to get details about
+# how the execution is performed (Observability Architecture). As such, the
+# audience is very limited (game developers, driver developers), and it does
+# not justify the overall execution time:
+#
+# - shard-skl: 0%
+# - shard-kbl: 0%
+# - shard-apl: 0%
+# - shard-glk: 0%
+# - shard-icl: 0%
+# - shard-tgl: 1.7% (~3.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@perf@gen12-mi-rpc
+
+
+###############################################################################
+# Modern userspace does not depend on the GTT anymore, so let's drop the
+# slowest tests from pre-merge testing:
+#
+# - shard-skl: 2.7% (~6.5 minutes)
+# - shard-kbl: 2% (~2.5 minutes)
+# - shard-apl: 4.7% (~8.5 minutes)
+# - shard-glk: 3.5% (~8 minutes)
+# - shard-icl: 4.2% (~8.5 minutes)
+# - shard-tgl: 2.5% (~4.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@gem_fence_thrash@bo-write-verify-threaded-[xy]
+igt@gem_tiled_(wc|(|blits|fence_blits)@(normal|interruptible))
+
+
+###############################################################################
+# This tests modesetting-vs-wedged which is a useful thing to check, but it
+# seems like it mostly catches unrelated issues which are better caught by
+# other tests.
+#
+# - shard-skl: 0.5% (~1 minute)
+# - shard-kbl: 1% (~1 minute)
+# - shard-apl: 0.6% (~1 minute)
+# - shard-glk: 0.5% (~1 minute)
+# - shard-icl: 0.6% (~1.5 minutes)
+# - shard-tgl: 0.7% (~1.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@gem_eio@kms
+
+
+###############################################################################
+# This is a useful test, but it mostly tests the HW rather than the driver.
+# Very few regressions should be caught by this test as the driver code should
+# be relatively left untouched. Hopefully, it will get optimized to be made
+# useful in pre-merge as well:
+#
+# - shard-skl: 1% (~2.5 minutes)
+# - shard-kbl: 1.5% (~2 minutes)
+# - shard-apl: 1.4% (~2.5 minutes)
+# - shard-glk: 2% (~4.5 minutes)
+# - shard-icl: 2.7% (~5.5 minutes)
+# - shard-tgl: 2.3% (~4.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@kms_plane@pixel-format-pipe-[a-d]-planes(-source-clamping)?
+
+
+###############################################################################
+# This test is doing nothing more than waiting for the driver to be suspended
+# before issueing a modeset. However, it never failed while testing for this
+# in the past year, so we probably just want to drop the amount of rounds to
+# reduce the runtime, but let's just blacklist it in pre-merge for now:
+#
+# - shard-skl: 1% (~2.5 minute)
+# - shard-kbl: 0.9% (~1 minute)
+# - shard-apl: 0.6% (~1 minute)
+# - shard-glk: 0.5% (~1 minute)
+# - shard-icl: 1.1% (~2.5 minutes)
+# - shard-tgl: 1.4% (~2.5 minutes)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@i915_pm_rpm@modeset-stress-extra-wait
+
+
+###############################################################################
+# This test virtually never failed, yet is responsible for a relatively big
+# execution time on some platforms:
+#
+# - shard-skl: 1.3% (~3 minutes)
+# - shard-kbl: 0.3% (~0.3 minutes)
+# - shard-apl: 0.6% (~1 minute)
+# - shard-glk: 0.4% (50 seconds)
+# - shard-icl: 0.1% (15 seconds)
+# - shard-tgl: 0.1% (15 seconds)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@sw_sync@sync_expired_merge
+
+
+###############################################################################
+# These 2 tests are stressing the re-usability of objects. It does not look
+# like we have had issues with this outside of the gen7 ppgtt issue, which
+# does not counterbalance its overall execution time.
+#
+# - shard-skl: 2% (~5 minutes)
+# - shard-kbl: 1% (~1.5 minutes)
+# - shard-apl: 1.7% (~3 minutes)
+# - shard-glk: 1% (2.5 minutes)
+# - shard-icl: 0.5% (1 minute)
+# - shard-tgl: 0.5% (1 minute)
+#
+# Data acquired on 2020-02-20 by Martin Peres
+###############################################################################
+igt@gem_exec_reuse@(baggage|contexts)
--
2.25.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [Intel-gfx] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
From: Janusz Krzysztofik @ 2020-02-20 15:32 UTC (permalink / raw)
To: igt-dev; +Cc: intel-gfx
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
lib/i915/gem_mman.h | 5 +++--
tests/i915/gem_ctx_sseu.c | 2 +-
tests/i915/gem_exec_params.c | 2 +-
tests/i915/gem_madvise.c | 18 ++++++++++++++----
tests/i915/gem_mmap_offset.c | 10 +++++-----
tests/i915/i915_pm_rpm.c | 2 +-
6 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index 4fc6a0186..491767023 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -101,9 +101,10 @@ extern const struct mmap_offset {
unsigned int domain;
} mmap_offset_types[];
-#define for_each_mmap_offset_type(__t) \
+#define for_each_mmap_offset_type(fd, __t) \
for (const struct mmap_offset *__t = mmap_offset_types; \
- (__t)->name; \
+ (__t)->name && (gem_has_mmap_offset(fd) || \
+ (__t)->type == I915_MMAP_OFFSET_GTT); \
(__t)++)
#endif /* GEM_MMAN_H */
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
index d558c8baa..3bef11b51 100644
--- a/tests/i915/gem_ctx_sseu.c
+++ b/tests/i915/gem_ctx_sseu.c
@@ -531,7 +531,7 @@ igt_main
test_invalid_sseu(fd);
igt_subtest_with_dynamic("mmap-args") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(fd, t) {
igt_dynamic_f("%s", t->name)
test_mmapped_args(fd, t);
}
diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index e2912685b..cf7ea3065 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -244,7 +244,7 @@ static void mmapped(int i915)
buf = gem_create(i915, 4096);
handle = batch_create(i915);
- for_each_mmap_offset_type(t) { /* repetitive! */
+ for_each_mmap_offset_type(i915, t) { /* repetitive! */
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *exec;
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index e8716a891..54c9befff 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -62,12 +62,13 @@ dontneed_before_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
gem_madvise(fd, handle, I915_MADV_DONTNEED);
@@ -93,7 +94,11 @@ dontneed_before_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigsegv);
signal(SIGSEGV, old_sigbus);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
@@ -103,12 +108,13 @@ dontneed_after_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
ptr = __gem_mmap_offset(fd, handle, 0, OBJECT_SIZE,
@@ -134,7 +140,11 @@ dontneed_after_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigbus);
signal(SIGSEGV, old_sigsegv);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
diff --git a/tests/i915/gem_mmap_offset.c b/tests/i915/gem_mmap_offset.c
index f49d18e63..1ec963b25 100644
--- a/tests/i915/gem_mmap_offset.c
+++ b/tests/i915/gem_mmap_offset.c
@@ -128,7 +128,7 @@ static void basic_uaf(int i915)
{
const uint32_t obj_size = 4096;
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
uint32_t handle = gem_create(i915, obj_size);
uint8_t *expected, *buf, *addr;
@@ -176,7 +176,7 @@ static void basic_uaf(int i915)
static void isolation(int i915)
{
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
struct drm_i915_gem_mmap_offset mmap_arg = {
.flags = t->type
};
@@ -245,7 +245,7 @@ static void pf_nonblock(int i915)
{
igt_spin_t *spin = igt_spin_new(i915);
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
uint32_t *ptr;
ptr = __mmap_offset(i915, spin->handle, 0, 4096,
@@ -324,7 +324,7 @@ static void open_flood(int i915, int timeout)
handle = gem_create(i915, 4096);
dmabuf = prime_handle_to_fd(i915, handle);
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
struct drm_i915_gem_mmap_offset arg = {
.handle = handle,
.flags = t->type,
@@ -351,7 +351,7 @@ static void open_flood(int i915, int timeout)
tmp = gem_reopen_driver(i915);
handle = prime_fd_to_handle(i915, dmabuf);
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
struct drm_i915_gem_mmap_offset arg = {
.handle = handle,
.flags = t->type,
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index 0c2821122..1bec80db7 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -2006,7 +2006,7 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
/* GEM */
igt_subtest_with_dynamic("gem-mmap-type") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(drm_fd, t) {
igt_dynamic_f("%s", t->name)
gem_mmap_args(t);
}
--
2.21.0
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* ✗ patchtest: failure for alsa-utils: upgrade 1.2.1 -> 1.2.2
From: Patchwork @ 2020-02-20 15:32 UTC (permalink / raw)
To: praveen; +Cc: openembedded-core
In-Reply-To: <dcd4c2c866d3c5bf5d5c8c76ae6fd455@linumiz.com>
== Series Details ==
Series: alsa-utils: upgrade 1.2.1 -> 1.2.2
Revision: 1
URL : https://patchwork.openembedded.org/series/22793/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on the proposed
series by patchtest resulting in the following failures:
* Issue Series cannot be parsed correctly due to malformed diff lines [test_mbox_format]
Suggested fix Create the series again using git-format-patch and ensure it can be applied using git am
Diff line "https://www.alsa-project.org/files/pub/utils/alsa-utils-${PV}.tar.bz2"
* Issue Series does not apply on top of target branch [test_series_merge_on_head]
Suggested fix Rebase your series on top of targeted branch
Targeted branch master (currently at 10c2216cb6)
If you believe any of these test results are incorrect, please reply to the
mailing list (openembedded-core@lists.openembedded.org) raising your concerns.
Otherwise we would appreciate you correcting the issues and submitting a new
version of the patchset if applicable. Please ensure you add/increment the
version number when sending the new version (i.e. [PATCH] -> [PATCH v2] ->
[PATCH v3] -> ...).
---
Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest
Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
^ permalink raw reply
* Re: [PATCH v2 12/14] torture: Replace cpu_up/down with device_online/offline
From: Qais Yousef @ 2020-02-20 15:31 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Thomas Gleixner, Greg Kroah-Hartman, Davidlohr Bueso,
Josh Triplett, linux-kernel
In-Reply-To: <20191129203856.GN2889@paulmck-ThinkPad-P72>
On 11/29/19 12:38, Paul E. McKenney wrote:
> On Fri, Nov 29, 2019 at 09:13:45AM +0000, Qais Yousef wrote:
> > On 11/28/19 13:02, Paul E. McKenney wrote:
> > > On Thu, Nov 28, 2019 at 05:00:26PM +0000, Qais Yousef wrote:
> > > > On 11/28/19 16:56, Qais Yousef wrote:
> > > > > On 11/27/19 13:47, Paul E. McKenney wrote:
> > > > > > On Mon, Nov 25, 2019 at 11:27:52AM +0000, Qais Yousef wrote:
> > > > > > > The core device API performs extra housekeeping bits that are missing
> > > > > > > from directly calling cpu_up/down.
> > > > > > >
> > > > > > > See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and
> > > > > > > serialization during LPM") for an example description of what might go
> > > > > > > wrong.
> > > > > > >
> > > > > > > This also prepares to make cpu_up/down a private interface for anything
> > > > > > > but the cpu subsystem.
> > > > > > >
> > > > > > > Signed-off-by: Qais Yousef <qais.yousef@arm.com>
> > > > > > > CC: Davidlohr Bueso <dave@stgolabs.net>
> > > > > > > CC: "Paul E. McKenney" <paulmck@kernel.org>
> > > > > > > CC: Josh Triplett <josh@joshtriplett.org>
> > > > > > > CC: linux-kernel@vger.kernel.org
> > > > > >
> > > > > > Looks fine from an rcutorture viewpoint, but why not provide an API
> > > > > > that pulled lock_device_hotplug() and unlock_device_hotplug() into the
> > > > > > online/offline calls?
> > > > >
> > > > > I *think* the right way to do what you say is by doing lock_device_hotplug()
> > > > > inside device_{online, offline}() - which affects all drivers not just the CPU.
> > >
> > > Or there could be a CPU-specific wrapper function that did the needed
> > > locking. (Whether this is worth it or not of course depends on the
> > > number of invocations.)
> >
> > Okay I see what you mean now. driver/base/memory.c have {add,remove}_memory()
> > that does what you say. I think we can replicate this in driver/base/cpu.c too.
> >
> > I can certainly do that, better as an improvement on top as I need to audit the
> > code to make sure the critical sections weren't relying on this lock to protect
> > something else beside the online/offline operation.
>
> Works for me!
I'm taking that as reviewed-by, which I'll add to v3. Please shout if you still
need to have a look further.
Once this is taken I'll add the suggested API!
Thanks
--
Qais Yousef
^ permalink raw reply
* [igt-dev] [RFC PATCH i-g-t] lib/i915: Restrict mmap types to GTT if no MMAP_OFFSET support
From: Janusz Krzysztofik @ 2020-02-20 15:32 UTC (permalink / raw)
To: igt-dev; +Cc: intel-gfx
Commit b0da8bb705c0 ("lib/i915: for_each_mmap_offset_type()")
introduced a macro that makes it easy to repeat a test body within a
loop for each mmap-offset mapping type supported by v4 of i915 MMAP_GTT
API. However, when run on an older version of the driver, those
subtests are believed to be still repeated for each known mmap-offset
mapping type while effectively exercising GTT mapping type only. As
that may be confusing, fix it.
It has been assumed that the modified macro is still suitable for use
inside gem_mmap_offset test itself. Would that not be case,
gem_mmap_offset could redefine the macro back to its initial form for
internal use.
Suggested-by: Michał Winiarski <michal.winiarski@intel.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
---
lib/i915/gem_mman.h | 5 +++--
tests/i915/gem_ctx_sseu.c | 2 +-
tests/i915/gem_exec_params.c | 2 +-
tests/i915/gem_madvise.c | 18 ++++++++++++++----
tests/i915/gem_mmap_offset.c | 10 +++++-----
tests/i915/i915_pm_rpm.c | 2 +-
6 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/lib/i915/gem_mman.h b/lib/i915/gem_mman.h
index 4fc6a0186..491767023 100644
--- a/lib/i915/gem_mman.h
+++ b/lib/i915/gem_mman.h
@@ -101,9 +101,10 @@ extern const struct mmap_offset {
unsigned int domain;
} mmap_offset_types[];
-#define for_each_mmap_offset_type(__t) \
+#define for_each_mmap_offset_type(fd, __t) \
for (const struct mmap_offset *__t = mmap_offset_types; \
- (__t)->name; \
+ (__t)->name && (gem_has_mmap_offset(fd) || \
+ (__t)->type == I915_MMAP_OFFSET_GTT); \
(__t)++)
#endif /* GEM_MMAN_H */
diff --git a/tests/i915/gem_ctx_sseu.c b/tests/i915/gem_ctx_sseu.c
index d558c8baa..3bef11b51 100644
--- a/tests/i915/gem_ctx_sseu.c
+++ b/tests/i915/gem_ctx_sseu.c
@@ -531,7 +531,7 @@ igt_main
test_invalid_sseu(fd);
igt_subtest_with_dynamic("mmap-args") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(fd, t) {
igt_dynamic_f("%s", t->name)
test_mmapped_args(fd, t);
}
diff --git a/tests/i915/gem_exec_params.c b/tests/i915/gem_exec_params.c
index e2912685b..cf7ea3065 100644
--- a/tests/i915/gem_exec_params.c
+++ b/tests/i915/gem_exec_params.c
@@ -244,7 +244,7 @@ static void mmapped(int i915)
buf = gem_create(i915, 4096);
handle = batch_create(i915);
- for_each_mmap_offset_type(t) { /* repetitive! */
+ for_each_mmap_offset_type(i915, t) { /* repetitive! */
struct drm_i915_gem_execbuffer2 *execbuf;
struct drm_i915_gem_exec_object2 *exec;
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index e8716a891..54c9befff 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -62,12 +62,13 @@ dontneed_before_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
gem_madvise(fd, handle, I915_MADV_DONTNEED);
@@ -93,7 +94,11 @@ dontneed_before_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigsegv);
signal(SIGSEGV, old_sigbus);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
@@ -103,12 +108,13 @@ dontneed_after_mmap(void)
char *ptr;
int fd;
- for_each_mmap_offset_type(t) {
+ fd = drm_open_driver(DRIVER_INTEL);
+
+ for_each_mmap_offset_type(fd, t) {
sighandler_t old_sigsegv, old_sigbus;
igt_debug("Mapping mode: %s\n", t->name);
- fd = drm_open_driver(DRIVER_INTEL);
handle = gem_create(fd, OBJECT_SIZE);
ptr = __gem_mmap_offset(fd, handle, 0, OBJECT_SIZE,
@@ -134,7 +140,11 @@ dontneed_after_mmap(void)
munmap(ptr, OBJECT_SIZE);
signal(SIGBUS, old_sigbus);
signal(SIGSEGV, old_sigsegv);
+
+ fd = drm_open_driver(DRIVER_INTEL);
}
+
+ close(fd);
}
static void
diff --git a/tests/i915/gem_mmap_offset.c b/tests/i915/gem_mmap_offset.c
index f49d18e63..1ec963b25 100644
--- a/tests/i915/gem_mmap_offset.c
+++ b/tests/i915/gem_mmap_offset.c
@@ -128,7 +128,7 @@ static void basic_uaf(int i915)
{
const uint32_t obj_size = 4096;
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
uint32_t handle = gem_create(i915, obj_size);
uint8_t *expected, *buf, *addr;
@@ -176,7 +176,7 @@ static void basic_uaf(int i915)
static void isolation(int i915)
{
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
struct drm_i915_gem_mmap_offset mmap_arg = {
.flags = t->type
};
@@ -245,7 +245,7 @@ static void pf_nonblock(int i915)
{
igt_spin_t *spin = igt_spin_new(i915);
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
uint32_t *ptr;
ptr = __mmap_offset(i915, spin->handle, 0, 4096,
@@ -324,7 +324,7 @@ static void open_flood(int i915, int timeout)
handle = gem_create(i915, 4096);
dmabuf = prime_handle_to_fd(i915, handle);
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
struct drm_i915_gem_mmap_offset arg = {
.handle = handle,
.flags = t->type,
@@ -351,7 +351,7 @@ static void open_flood(int i915, int timeout)
tmp = gem_reopen_driver(i915);
handle = prime_fd_to_handle(i915, dmabuf);
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(i915, t) {
struct drm_i915_gem_mmap_offset arg = {
.handle = handle,
.flags = t->type,
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index 0c2821122..1bec80db7 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -2006,7 +2006,7 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
/* GEM */
igt_subtest_with_dynamic("gem-mmap-type") {
- for_each_mmap_offset_type(t) {
+ for_each_mmap_offset_type(drm_fd, t) {
igt_dynamic_f("%s", t->name)
gem_mmap_args(t);
}
--
2.21.0
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* Re: [PATCH 01/19] vfs: syscall: Add fsinfo() to query filesystem information [ver #16]
From: Darrick J. Wong @ 2020-02-20 15:31 UTC (permalink / raw)
To: Jann Horn
Cc: David Howells, Al Viro, raven, Miklos Szeredi, Christian Brauner,
Linux API, linux-fsdevel, kernel list
In-Reply-To: <CAG48ez00KA3tjeccDCeqmgHyppTLEr+UkrB=QaQ-FX-cTY3aCA@mail.gmail.com>
On Thu, Feb 20, 2020 at 03:54:25PM +0100, Jann Horn wrote:
> On Thu, Feb 20, 2020 at 12:04 PM David Howells <dhowells@redhat.com> wrote:
> > Jann Horn <jannh@google.com> wrote:
> >
> > > > +int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> > > ...
> > > Please add a check here to ensure that "ret" actually fits into the
> > > buffer (and use WARN_ON() if you think the check should never fire).
> > > Otherwise I think this is too fragile.
> >
> > How about:
> >
> > int fsinfo_string(const char *s, struct fsinfo_context *ctx)
> > {
> > unsigned int len;
> > char *p = ctx->buffer;
> > int ret = 0;
> > if (s) {
> > len = strlen(s);
> > if (len > ctx->buf_size - 1)
> > len = ctx->buf_size;
> > if (!ctx->want_size_only) {
> > memcpy(p, s, len);
> > p[len] = 0;
>
> I think this is off-by-one? If len was too big, it is set to
> ctx->buf_size, so in that case this effectively becomes
> `ctx->buffer[ctx->buf_size] = 0`, which is one byte out of bounds,
> right?
>
> Maybe use something like `len = min_t(size_t, strlen(s), ctx->buf_size-1)` ?
>
> Looks good apart from that, I think.
>
> > }
> > ret = len;
> > }
> > return ret;
> > }
> [...]
> > > > + return ctx->usage;
> > >
> > > It is kind of weird that you have to return the ctx->usage everywhere
> > > even though the caller already has ctx...
> >
> > At this point, it's only used and returned by fsinfo_attributes() and really
> > is only for the use of the attribute getter function.
> >
> > I could, I suppose, return the amount of data in ctx->usage and then preset it
> > for VSTRUCT-type objects. Unfortunately, I can't make the getter return void
> > since it might have to return an error.
>
> Yeah, then you'd be passing around the error separately from the
> length... I don't know whether that'd make things better or worse.
>
> [...]
> > > > +struct fsinfo_attribute {
> > > > + unsigned int attr_id; /* The ID of the attribute */
> > > > + enum fsinfo_value_type type:8; /* The type of the attribute's value(s) */
> > > > + unsigned int flags:8;
> > > > + unsigned int size:16; /* - Value size (FSINFO_STRUCT) */
> > > > + unsigned int element_size:16; /* - Element size (FSINFO_LIST) */
> > > > + int (*get)(struct path *path, struct fsinfo_context *params);
> > > > +};
> > >
> > > Why the bitfields? It doesn't look like that's going to help you much,
> > > you'll just end up with 6 bytes of holes on x86-64:
> >
> > Expanding them to non-bitfields will require an extra 10 bytes, making the
> > struct 8 bytes bigger with 4 bytes of padding. I can do that if you'd rather.
>
> Wouldn't this still have the same total size?
>
> struct fsinfo_attribute {
> unsigned int attr_id; /* 0x0-0x3 */
> enum fsinfo_value_type type; /* 0x4-0x7 */
> u8 flags; /* 0x8-0x8 */
> /* 1-byte hole */
> u16 size; /* 0xa-0xb */
> u16 element_size; /* 0xc-0xd */
> /* 2-byte hole */
> int (*get)(...); /* 0x10-0x18 */
> };
>
> But it's not like I really care about this detail all that much, feel
> free to leave it as-is.
I was thinking, why not just have unsigned int flags from the start?
That replaces the padding holes with usable flag space, though I guess
this is in-core only so I'm not that passionate. I doubt we're going to
have millions of fsinfo attributes. :)
--D
^ permalink raw reply
* Re: [PATCH 1/2] btrfs/112: remove some tests for cloning inline extents
From: Josef Bacik @ 2020-02-20 15:31 UTC (permalink / raw)
To: fdmanana, fstests; +Cc: linux-btrfs, Filipe Manana
In-Reply-To: <20200219140627.1641733-1-fdmanana@kernel.org>
On 2/19/20 9:06 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> This test case, btrfs/112, tests that some clone operations that have a
> range covering inline extents fail with either -EOPNOTSUPP or -EINVAL.
> These cases were unsupported on btrfs because they used to lead to file
> corruptions and were not trivial to implement.
>
> But there's now a patchset that adds support for them, and the relevant
> patch of that patchset has the following subject:
>
> "Btrfs: implement full reflink support for inline extents"
>
> So just remove these tests from test case btrfs/112, since this test
> case is about testing only the unsupported reflink operations. A new
> test case that verifies that these cases now work, as long as some other
> new cases, will follow in another patch.
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply
* Re: [PATCH 4/4] Btrfs: implement full reflink support for inline extents
From: Josef Bacik @ 2020-02-20 15:30 UTC (permalink / raw)
To: fdmanana, linux-btrfs
In-Reply-To: <20200219140615.1641680-1-fdmanana@kernel.org>
On 2/19/20 9:06 AM, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> There are a few cases where we don't allow cloning an inline extent into
> the destination inode, returning -EOPNOTSUPP to user space. This was done
> to prevent several types of file corruption and because it's not very
> straightforward to deal with these cases, as they can't rely on simply
> copying the inline extent between leaves. Such cases require copying the
> inline extent's data into the respective page of the destination inode.
>
> Not supporting these cases makes it harder and more cumbersome to write
> applications/libraries that work on any filesystem with reflink support,
> since all these cases for which btrfs fails with -EOPNOTSUPP work just
> fine on xfs for example. These unsupported cases are also not documented
> anywhere and explaining which exact cases fail require a bit of too
> technical understanding of btrfs's internal (inline extents and when and
> where can they exist in a file), so it's not really user friendly.
>
> Also some test cases from fstests that use fsx, such as generic/522 for
> example, can sporadically fail because they trigger one of these cases,
> and fsx expects all operations to succeed.
>
> This change adds supports for cloning all these cases by copying the
> inline extent's data into the respective page of the destination inode.
>
> With this change test case btrfs/112 from fstests fails because it
> expects some clone operations to fail, so it will be updated. Also a
> new test case that exercises all these previously unsupported cases
> will be added to fstests.
>
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ---
> fs/btrfs/reflink.c | 212 ++++++++++++++++++++++++++++++++-------------
> 1 file changed, 152 insertions(+), 60 deletions(-)
>
> diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
> index 7e7f46116db3..c19c87de6d4a 100644
> --- a/fs/btrfs/reflink.c
> +++ b/fs/btrfs/reflink.c
> @@ -1,8 +1,12 @@
> // SPDX-License-Identifier: GPL-2.0
>
> #include <linux/iversion.h>
> +#include <linux/blkdev.h>
> #include "misc.h"
> #include "ctree.h"
> +#include "btrfs_inode.h"
> +#include "compression.h"
> +#include "delalloc-space.h"
> #include "transaction.h"
>
> #define BTRFS_MAX_DEDUPE_LEN SZ_16M
> @@ -43,30 +47,121 @@ static int clone_finish_inode_update(struct btrfs_trans_handle *trans,
> return ret;
> }
>
> +static int copy_inline_to_page(struct inode *inode,
> + const u64 file_offset,
> + char *inline_data,
> + const u64 size,
> + const u64 datal,
> + const u8 comp_type)
> +{
> + const u64 block_size = btrfs_inode_sectorsize(inode);
> + const u64 range_end = file_offset + block_size - 1;
> + const size_t inline_size = size - btrfs_file_extent_calc_inline_size(0);
> + char *data_start = inline_data + btrfs_file_extent_calc_inline_size(0);
> + struct extent_changeset *data_reserved = NULL;
> + struct page *page = NULL;
> + bool page_locked = false;
> + int ret;
> +
> + ASSERT(IS_ALIGNED(file_offset, block_size));
> +
> + ret = btrfs_delalloc_reserve_space(inode, &data_reserved, file_offset,
> + block_size);
This could potentially deadlock, as we could need to flush delalloc for this
inode that we've dirtied pages for and not be able to make progress because we
have this range locked.
Josef
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] app/testpmd: fix wrong return value in parse_port_list
From: Iremonger, Bernard @ 2020-02-20 15:29 UTC (permalink / raw)
To: Govindharajan, Hariprasad, Lu, Wenzhuo, Wu, Jingjing
Cc: dev@dpdk.org, Yigit, Ferruh, stephen@networkplumber.org,
david.marchand@redhat.com
In-Reply-To: <1582205191-14105-1-git-send-email-hariprasad.govindharajan@intel.com>
Hi Hariprasad,
> -----Original Message-----
> From: Govindharajan, Hariprasad <hariprasad.govindharajan@intel.com>
> Sent: Thursday, February 20, 2020 1:27 PM
> To: Lu, Wenzhuo <wenzhuo.lu@intel.com>; Wu, Jingjing
> <jingjing.wu@intel.com>; Iremonger, Bernard
> <bernard.iremonger@intel.com>
> Cc: dev@dpdk.org; Yigit, Ferruh <ferruh.yigit@intel.com>;
> stephen@networkplumber.org; david.marchand@redhat.com;
> Govindharajan, Hariprasad <hariprasad.govindharajan@intel.com>
> Subject: [PATCH] app/testpmd: fix wrong return value in parse_port_list
>
> The function parse_port_list() is designed to return unsigned int value. After
> sanitizing the inputs, it is returning -1. Changed it to return 0.
>
> Fixes: 2df00d562d20 ("app/testpmd: add --portlist option")
> Cc: hariprasad.govindharajan@intel.com
>
> Signed-off-by: Hariprasad Govindharajan
> <hariprasad.govindharajan@intel.com>
> ---
> app/test-pmd/config.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c index
> 9d95202..91db508 100644
> --- a/app/test-pmd/config.c
> +++ b/app/test-pmd/config.c
> @@ -2642,7 +2642,7 @@ parse_port_list(const char *list, unsigned int
> *values, unsigned int maxsize)
> unsigned int marked[maxsize];
>
> if (list == NULL || values == NULL)
> - return -1;
> + return 0;
>
> for (i = 0; i < (int)maxsize; i++)
> marked[i] = 0;
> --
> 2.7.4
./devtools/check-git-log.sh -1
Wrong headline format:
app/testpmd: fix wrong return value in parse_port_list
Line too long:
Signed-off-by: Hariprasad Govindharajan <hariprasad.govindharajan@intel.com>
Otherwise:
Acked-by: Bernard Iremonger <bernard.iremonger@intel.com>
^ permalink raw reply
* [PATCH v3] dt-bindings: mfd: Convert stpmic1 bindings to json-schema
From: Benjamin Gaignard @ 2020-02-20 15:28 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt, mark.rutland, lee.jones, lgirdwood,
broonie, wim, linux, p.paillet
Cc: linux-input, devicetree, linux-kernel, linux-watchdog,
Benjamin Gaignard
Convert stpmic1 bindings to json-schema.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
version 3:
- put $erf under allOf keyword
- for each regulator node add the list of supported regulator properties
.../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 --
.../devicetree/bindings/mfd/st,stpmic1.txt | 61 ----
.../devicetree/bindings/mfd/st,stpmic1.yaml | 354 +++++++++++++++++++++
.../bindings/regulator/st,stpmic1-regulator.txt | 64 ----
.../bindings/watchdog/st,stpmic1-wdt.txt | 11 -
5 files changed, 354 insertions(+), 164 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
delete mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
delete mode 100644 Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
diff --git a/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt b/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
deleted file mode 100644
index eb8e83736c02..000000000000
--- a/Documentation/devicetree/bindings/input/st,stpmic1-onkey.txt
+++ /dev/null
@@ -1,28 +0,0 @@
-STMicroelectronics STPMIC1 Onkey
-
-Required properties:
-
-- compatible = "st,stpmic1-onkey";
-- interrupts: interrupt line to use
-- interrupt-names = "onkey-falling", "onkey-rising"
- onkey-falling: happens when onkey is pressed; IT_PONKEY_F of pmic
- onkey-rising: happens when onkey is released; IT_PONKEY_R of pmic
-
-Optional properties:
-
-- st,onkey-clear-cc-flag: onkey is able power on after an
- over-current shutdown event.
-- st,onkey-pu-inactive: onkey pull up is not active
-- power-off-time-sec: Duration in seconds which the key should be kept
- pressed for device to power off automatically (from 1 to 16 seconds).
- see See Documentation/devicetree/bindings/input/input.yaml
-
-Example:
-
-onkey {
- compatible = "st,stpmic1-onkey";
- interrupt-parent = <&pmic>;
- interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
- interrupt-names = "onkey-falling", "onkey-rising";
- power-off-time-sec = <10>;
-};
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.txt b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
deleted file mode 100644
index afd45c089585..000000000000
--- a/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-* STMicroelectronics STPMIC1 Power Management IC
-
-Required properties:
-- compatible: : "st,stpmic1"
-- reg: : The I2C slave address for the STPMIC1 chip.
-- interrupts: : The interrupt line the device is connected to.
-- #interrupt-cells: : Should be 1.
-- interrupt-controller: : Marks the device node as an interrupt controller.
- Interrupt numbers are defined at
- dt-bindings/mfd/st,stpmic1.h.
-
-STPMIC1 consists in a varied group of sub-devices.
-Each sub-device binding is be described in own documentation file.
-
-Device Description
------- ------------
-st,stpmic1-onkey : Power on key, see ../input/st,stpmic1-onkey.txt
-st,stpmic1-regulators : Regulators, see ../regulator/st,stpmic1-regulator.txt
-st,stpmic1-wdt : Watchdog, see ../watchdog/st,stpmic1-wdt.txt
-
-Example:
-
-#include <dt-bindings/mfd/st,stpmic1.h>
-
-pmic: pmic@33 {
- compatible = "st,stpmic1";
- reg = <0x33>;
- interrupt-parent = <&gpioa>;
- interrupts = <0 2>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- onkey {
- compatible = "st,stpmic1-onkey";
- interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
- interrupt-names = "onkey-falling", "onkey-rising";
- power-off-time-sec = <10>;
- };
-
- watchdog {
- compatible = "st,stpmic1-wdt";
- };
-
- regulators {
- compatible = "st,stpmic1-regulators";
-
- vdd_core: buck1 {
- regulator-name = "vdd_core";
- regulator-boot-on;
- regulator-min-microvolt = <700000>;
- regulator-max-microvolt = <1200000>;
- };
- vdd: buck3 {
- regulator-name = "vdd";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- regulator-pull-down;
- };
- };
diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
new file mode 100644
index 000000000000..92b0ac8ddfde
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.yaml
@@ -0,0 +1,354 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/st,stpmic1.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectonics STPMIC1 Power Management IC bindings
+
+description: STMicroelectronics STPMIC1 Power Management IC
+
+maintainers:
+ - pascal Paillet <p.paillet@st.com>
+
+properties:
+ compatible:
+ const: st,stpmic1
+
+ reg:
+ const: 0x33
+
+ interrupts:
+ maxItems: 1
+
+ "#interrupt-cells":
+ const: 2
+
+ interrupt-controller: true
+
+ onkey:
+ type: object
+
+ allOf:
+ - $ref: ../input/input.yaml
+
+ properties:
+ compatible:
+ const: st,stpmic1-onkey
+
+ interrupts:
+ items:
+ - description: onkey-falling, happens when onkey is pressed. IT_PONKEY_F of pmic
+ - description: onkey-rising, happens when onkey is released. IT_PONKEY_R of pmic
+
+ interrupt-names:
+ items:
+ - const: onkey-falling
+ - const: onkey-rising
+
+ st,onkey-clear-cc-flag:
+ description: onkey is able power on after an over-current shutdown event.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ st,onkey-pu-inactive:
+ description: onkey pull up is not active
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ power-off-time-sec:
+ minimum: 1
+ maximum: 16
+
+ required:
+ - compatible
+ - interrupts
+ - interrupt-names
+
+ additionalProperties: false
+
+ watchdog:
+ type: object
+
+ allOf:
+ - $ref: ../watchdog/watchdog.yaml
+
+ properties:
+ compatible:
+ const: st,stpmic1-wdt
+
+ timeout-sec: true
+
+ required:
+ - compatible
+
+ additionalProperties: false
+
+ regulators:
+ type: object
+
+ description: |
+ Available Regulators in STPMIC1 device are:
+ - buck1 for Buck BUCK1
+ - buck2 for Buck BUCK2
+ - buck3 for Buck BUCK3
+ - buck4 for Buck BUCK4
+ - ldo1 for LDO LDO1
+ - ldo2 for LDO LDO2
+ - ldo3 for LDO LDO3
+ - ldo4 for LDO LDO4
+ - ldo5 for LDO LDO5
+ - ldo6 for LDO LDO6
+ - vref_ddr for LDO Vref DDR
+ - boost for Buck BOOST
+ - pwr_sw1 for VBUS_OTG switch
+ - pwr_sw2 for SW_OUT switch
+ Switches are fixed voltage regulators with only enable/disable capability.
+
+ properties:
+ compatible:
+ const: st,stpmic1-regulators
+
+ patternProperties:
+ "^(buck[1-4]|ldo[1-6]|boost|pwr_sw[1-2])-supply$":
+ description: STPMIC1 voltage regulators supplies
+
+ "^(ldo[1-2,5-6])$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ st,mask-reset:
+ description: mask reset for this regulator,
+ the regulator configuration is maintained during pmic reset.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+ regulator-min-microvolt: true
+ regulator-max-microvolt: true
+ regulator-over-current-protection: true
+ regulator-enable-ramp-delay: true
+
+ additionalProperties: false
+
+ "^(ldo3)$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ st,mask-reset:
+ description: mask reset for this regulator,
+ the regulator configuration is maintained during pmic reset.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+ regulator-min-microvolt: true
+ regulator-max-microvolt: true
+ regulator-allow-bypass: true
+ regulator-over-current-protection: true
+
+ additionalProperties: false
+
+ "^(ldo4)$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ st,mask-reset:
+ description: mask reset for this regulator,
+ the regulator configuration is maintained during pmic reset.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+ regulator-over-current-protection: true
+
+ additionalProperties: false
+
+ "^(buck[1-4])$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ st,mask-reset:
+ description: mask reset for this regulator,
+ the regulator configuration is maintained during pmic reset.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+ regulator-min-microvolt: true
+ regulator-max-microvolt: true
+ regulator-initial-mode: true
+ regulator-pull-down: true
+ regulator-over-current-protection: true
+ regulator-enable-ramp-delay: true
+
+ additionalProperties: false
+
+ "^(vref_ddr)$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ st,mask-reset:
+ description: mask reset for this regulator,
+ the regulator configuration is maintained during pmic reset.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+
+ additionalProperties: false
+
+ "^(boost)$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ st,mask-reset:
+ description: mask reset for this regulator,
+ the regulator configuration is maintained during pmic reset.
+ $ref: /schemas/types.yaml#/definitions/flag
+
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+ regulator-over-current-protection: true
+
+ additionalProperties: false
+
+ "^(pwr_sw[1-2])$":
+ type: object
+
+ allOf:
+ - $ref: ../regulator/regulator.yaml
+
+ properties:
+ interrupts:
+ maxItems: 1
+
+ regulator-name: true
+ regulator-boot-on: true
+ regulator-always-on: true
+ regulator-over-current-protection: true
+ regulator-active-discharge: true
+
+ additionalProperties: false
+
+ required:
+ - compatible
+
+ additionalProperties: false
+
+additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#interrupt-cells"
+ - interrupt-controller
+
+examples:
+ - |
+ #include <dt-bindings/mfd/st,stpmic1.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pmic@33 {
+ compatible = "st,stpmic1";
+ reg = <0x33>;
+ interrupt-parent = <&gpioa>;
+ interrupts = <0 2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ onkey {
+ compatible = "st,stpmic1-onkey";
+ interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
+ interrupt-names = "onkey-falling", "onkey-rising";
+ power-off-time-sec = <10>;
+ };
+
+ watchdog {
+ compatible = "st,stpmic1-wdt";
+ };
+
+ regulators {
+ compatible = "st,stpmic1-regulators";
+
+ ldo6-supply = <&v3v3>;
+
+ buck1 {
+ regulator-name = "vdd_core";
+ interrupts = <IT_CURLIM_BUCK1 0>;
+ st,mask-reset;
+ regulator-boot-on;
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1200000>;
+ };
+
+ buck3 {
+ regulator-name = "vdd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-pull-down;
+ };
+
+ buck4 {
+ regulator-name = "v3v3";
+ interrupts = <IT_CURLIM_BUCK4 0>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo6 {
+ regulator-name = "v1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-over-current-protection;
+ };
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt b/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
deleted file mode 100644
index 6189df71ea98..000000000000
--- a/Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
+++ /dev/null
@@ -1,64 +0,0 @@
-STMicroelectronics STPMIC1 Voltage regulators
-
-Regulator Nodes are optional depending on needs.
-
-Available Regulators in STPMIC1 device are:
- - buck1 for Buck BUCK1
- - buck2 for Buck BUCK2
- - buck3 for Buck BUCK3
- - buck4 for Buck BUCK4
- - ldo1 for LDO LDO1
- - ldo2 for LDO LDO2
- - ldo3 for LDO LDO3
- - ldo4 for LDO LDO4
- - ldo5 for LDO LDO5
- - ldo6 for LDO LDO6
- - vref_ddr for LDO Vref DDR
- - boost for Buck BOOST
- - pwr_sw1 for VBUS_OTG switch
- - pwr_sw2 for SW_OUT switch
-
-Switches are fixed voltage regulators with only enable/disable capability.
-
-Optional properties:
-- st,mask-reset: mask reset for this regulator: the regulator configuration
- is maintained during pmic reset.
-- regulator-over-current-protection:
- if set, all regulators are switched off in case of over-current detection
- on this regulator,
- if not set, the driver only sends an over-current event.
-- interrupts: index of current limit detection interrupt
-- <regulator>-supply: phandle to the parent supply/regulator node
- each regulator supply can be described except vref_ddr.
-- regulator-active-discharge: can be used on pwr_sw1 and pwr_sw2.
-
-Example:
-regulators {
- compatible = "st,stpmic1-regulators";
-
- ldo6-supply = <&v3v3>;
-
- vdd_core: buck1 {
- regulator-name = "vdd_core";
- interrupts = <IT_CURLIM_BUCK1 0>;
- st,mask-reset;
- regulator-pull-down;
- regulator-min-microvolt = <700000>;
- regulator-max-microvolt = <1200000>;
- };
-
- v3v3: buck4 {
- regulator-name = "v3v3";
- interrupts = <IT_CURLIM_BUCK4 0>;
-
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- v1v8: ldo6 {
- regulator-name = "v1v8";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-over-current-protection;
- };
-};
diff --git a/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt b/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
deleted file mode 100644
index 7cc1407f15cb..000000000000
--- a/Documentation/devicetree/bindings/watchdog/st,stpmic1-wdt.txt
+++ /dev/null
@@ -1,11 +0,0 @@
-STMicroelectronics STPMIC1 Watchdog
-
-Required properties:
-
-- compatible : should be "st,stpmic1-wdt"
-
-Example:
-
-watchdog {
- compatible = "st,stpmic1-wdt";
-};
--
2.15.0
^ permalink raw reply related
* Re: [RFC PATCH v3 07/27] qcow2: Add subcluster-related fields to BDRVQcow2State
From: Eric Blake @ 2020-02-20 15:28 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <b04e7e26cea16892a7f209b37d931c489ef17bd9.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> This patch adds the following new fields to BDRVQcow2State:
>
> - subclusters_per_cluster: Number of subclusters in a cluster
> - subcluster_size: The size of each subcluster, in bytes
> - subcluster_bits: No. of bits so 1 << subcluster_bits = subcluster_size
>
> Images without subclusters are treated as if they had exactly one,
> with subcluster_size = cluster_size.
The qcow2 spec changes earlier in the series made it sound like your
choices are exactly 1 or 32,
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2.c | 5 +++++
> block/qcow2.h | 5 +++++
> 2 files changed, 10 insertions(+)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 3866b47946..cbd857e9c7 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -1378,6 +1378,11 @@ static int coroutine_fn qcow2_do_open(BlockDriverState *bs, QDict *options,
> }
> }
>
> + s->subclusters_per_cluster =
> + has_subclusters(s) ? QCOW_MAX_SUBCLUSTERS_PER_CLUSTER : 1;
which matches your code here (other than the name of the constant)...
> + s->subcluster_size = s->cluster_size / s->subclusters_per_cluster;
> + s->subcluster_bits = ctz32(s->subcluster_size);
> +
> /* Check support for various header values */
> if (header.refcount_order > 6) {
> error_setg(errp, "Reference count entry width too large; may not "
> diff --git a/block/qcow2.h b/block/qcow2.h
> index 1db3fc5dbc..941330cfc9 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -78,6 +78,8 @@
> /* The cluster reads as all zeros */
> #define QCOW_OFLAG_ZERO (1ULL << 0)
>
> +#define QCOW_MAX_SUBCLUSTERS_PER_CLUSTER 32
> +
...but this name sounds like other values (2, 4, 8, 16) might be
possible? Is this just leftovers from earlier spins of the series
before we decided to mandate that clusters must be at least 16k if
subclusters are enabled (so that subclusters are at least 512 bytes)?
Once we get the right name for the constant, the rest of the patch makes
sense.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH] Set default CONNECTIVITY_CHECK_URIS to https://www.yoctoproject.org/
From: Richard Purdie @ 2020-02-20 15:27 UTC (permalink / raw)
To: Nataliya Korovkina, openembedded-core
In-Reply-To: <20200220150318.20003-1-malus.brandywine@gmail.com>
On Thu, 2020-02-20 at 10:03 -0500, Nataliya Korovkina wrote:
> Signed-off-by: Nataliya Korovkina <malus.brandywine@gmail.com>
> ---
> meta/conf/distro/include/default-distrovars.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/default-distrovars.inc
> b/meta/conf/distro/include/default-distrovars.inc
> index 433d4b6651..6c9155b2ae 100644
> --- a/meta/conf/distro/include/default-distrovars.inc
> +++ b/meta/conf/distro/include/default-distrovars.inc
> @@ -48,4 +48,4 @@ KERNEL_IMAGETYPES ??= "${KERNEL_IMAGETYPE}"
> # fetch from the network (and warn you if not). To disable the test
> set
> # the variable to be empty.
> # Git example url: git://git.yoctoproject.org/yocto-firewall-
> test;protocol=git;rev=master
> -CONNECTIVITY_CHECK_URIS ?= "https://www.example.com/"
> +CONNECTIVITY_CHECK_URIS ?= "https://www.yoctoproject.org/"
Why would that be better?
There have been several requests to change this however I'm not sure we
can find one perfect url we can use :(
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH 1/2] net: mdio: add ipq8064 mdio driver
From: Russell King - ARM Linux admin @ 2020-02-20 15:27 UTC (permalink / raw)
To: Ansuel Smith
Cc: Andy Gross, Bjorn Andersson, David S. Miller, Rob Herring,
Mark Rutland, Andrew Lunn, Florian Fainelli, Heiner Kallweit,
linux-arm-msm, netdev, devicetree, linux-kernel
In-Reply-To: <20200220151301.10564-1-ansuelsmth@gmail.com>
On Thu, Feb 20, 2020 at 04:12:55PM +0100, Ansuel Smith wrote:
> Currently ipq806x soc use generi bitbang driver to
> comunicate with the gmac ethernet interface.
> Add a dedicated driver created by chunkeey to fix this.
>
> Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
> ---
> drivers/net/phy/Kconfig | 8 ++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/mdio-ipq8064.c | 163 +++++++++++++++++++++++++++++++++
> 3 files changed, 172 insertions(+)
> create mode 100644 drivers/net/phy/mdio-ipq8064.c
>
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 9dabe03a668c..ec2a5493a7e8 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -157,6 +157,14 @@ config MDIO_I2C
>
> This is library mode.
>
> +config MDIO_IPQ8064
> + tristate "Qualcomm IPQ8064 MDIO interface support"
> + depends on HAS_IOMEM && OF_MDIO
> + depends on MFD_SYSCON
> + help
> + This driver supports the MDIO interface found in the network
> + interface units of the IPQ8064 SoC
> +
> config MDIO_MOXART
> tristate "MOXA ART MDIO interface support"
> depends on ARCH_MOXART || COMPILE_TEST
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index fe5badf13b65..8f02bd2089f3 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_MDIO_CAVIUM) += mdio-cavium.o
> obj-$(CONFIG_MDIO_GPIO) += mdio-gpio.o
> obj-$(CONFIG_MDIO_HISI_FEMAC) += mdio-hisi-femac.o
> obj-$(CONFIG_MDIO_I2C) += mdio-i2c.o
> +obj-$(CONFIG_MDIO_IPQ8064) += mdio-ipq8064.o
> obj-$(CONFIG_MDIO_MOXART) += mdio-moxart.o
> obj-$(CONFIG_MDIO_MSCC_MIIM) += mdio-mscc-miim.o
> obj-$(CONFIG_MDIO_OCTEON) += mdio-octeon.o
> diff --git a/drivers/net/phy/mdio-ipq8064.c b/drivers/net/phy/mdio-ipq8064.c
> new file mode 100644
> index 000000000000..c76e6a647787
> --- /dev/null
> +++ b/drivers/net/phy/mdio-ipq8064.c
> @@ -0,0 +1,163 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Qualcomm IPQ8064 MDIO interface driver
> +//
> +// Copyright (C) 2019 Christian Lamparter <chunkeey@gmail.com>
> +
> +#include <linux/delay.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/regmap.h>
> +#include <linux/of_mdio.h>
> +#include <linux/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/syscon.h>
> +
> +/* MII address register definitions */
> +#define MII_ADDR_REG_ADDR 0x10
> +#define MII_BUSY BIT(0)
> +#define MII_WRITE BIT(1)
> +#define MII_CLKRANGE_60_100M (0 << 2)
> +#define MII_CLKRANGE_100_150M (1 << 2)
> +#define MII_CLKRANGE_20_35M (2 << 2)
> +#define MII_CLKRANGE_35_60M (3 << 2)
> +#define MII_CLKRANGE_150_250M (4 << 2)
> +#define MII_CLKRANGE_250_300M (5 << 2)
> +#define MII_CLKRANGE_MASK GENMASK(4, 2)
> +#define MII_REG_SHIFT 6
> +#define MII_REG_MASK GENMASK(10, 6)
> +#define MII_ADDR_SHIFT 11
> +#define MII_ADDR_MASK GENMASK(15, 11)
> +
> +#define MII_DATA_REG_ADDR 0x14
> +
> +#define MII_MDIO_DELAY (1000)
> +#define MII_MDIO_RETRY (10)
> +
> +struct ipq8064_mdio {
> + struct regmap *base; /* NSS_GMAC0_BASE */
> +};
> +
> +static int
> +ipq8064_mdio_wait_busy(struct ipq8064_mdio *priv)
> +{
> + int i;
> +
> + for (i = 0; i < MII_MDIO_RETRY; i++) {
> + unsigned int busy;
> +
> + regmap_read(priv->base, MII_ADDR_REG_ADDR, &busy);
> + if (!(busy & MII_BUSY))
> + return 0;
> +
> + udelay(MII_MDIO_DELAY);
> + }
On the last loop, this will delay MII_MDIO_DELAY and then return
-ETIMEDOUT, which is not nice behaviour. Have you considered using
regmap_read_poll_timeout() here?
> +
> + return -ETIMEDOUT;
> +}
> +
> +static int
> +ipq8064_mdio_read(struct mii_bus *bus, int phy_addr, int reg_offset)
> +{
> + struct ipq8064_mdio *priv = bus->priv;
> + u32 miiaddr = MII_BUSY | MII_CLKRANGE_250_300M;
> + u32 ret_val;
> + int err;
> +
> + miiaddr |= ((phy_addr << MII_ADDR_SHIFT) & MII_ADDR_MASK) |
> + ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK);
This looks like it only supports Clause 22 accesses, so shouldn't it
reject Clause 45 accesses (signified by reg_offset & MII_ADDR_C45) ?
> + regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr);
> + usleep_range(10, 20);
> +
> + err = ipq8064_mdio_wait_busy(priv);
> + if (err)
> + return err;
> +
> + regmap_read(priv->base, MII_DATA_REG_ADDR, &ret_val);
> + return (int)ret_val;
> +}
> +
> +static int
> +ipq8064_mdio_write(struct mii_bus *bus, int phy_addr, int reg_offset, u16 data)
> +{
> + struct ipq8064_mdio *priv = bus->priv;
> + u32 miiaddr = MII_WRITE | MII_BUSY | MII_CLKRANGE_250_300M;
> +
> + regmap_write(priv->base, MII_DATA_REG_ADDR, data);
> +
> + miiaddr |= ((phy_addr << MII_ADDR_SHIFT) & MII_ADDR_MASK) |
> + ((reg_offset << MII_REG_SHIFT) & MII_REG_MASK);
Same here as for ipq8064_mdio_read().
> +
> + regmap_write(priv->base, MII_ADDR_REG_ADDR, miiaddr);
> + usleep_range(10, 20);
> +
> + return ipq8064_mdio_wait_busy(priv);
> +}
> +
> +static int
> +ipq8064_mdio_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct ipq8064_mdio *priv;
> + struct mii_bus *bus;
> + int ret;
> +
> + bus = devm_mdiobus_alloc_size(&pdev->dev, sizeof(*priv));
> + if (!bus)
> + return -ENOMEM;
> +
> + bus->name = "ipq8064_mdio_bus";
> + bus->read = ipq8064_mdio_read;
> + bus->write = ipq8064_mdio_write;
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(&pdev->dev));
> + bus->parent = &pdev->dev;
> +
> + priv = bus->priv;
> + priv->base = syscon_node_to_regmap(np);
> + if (IS_ERR_OR_NULL(priv->base)) {
> + priv->base = syscon_regmap_lookup_by_phandle(np, "master");
> + if (IS_ERR_OR_NULL(priv->base)) {
> + pr_err("master phandle not found\n");
> + return -EINVAL;
> + }
> + }
Does syscon_node_to_regmap() return NULL? From what I can see in
drivers/mfd/syscon.c, both that and syscon_regmap_lookup_by_phandle()
returns an error pointer, and if there's an error code, it should be
propagated.
Using dev_err(&pdev->dev, ...) for that error print is also nice -
imagine a kernel log where you have a line appear that only says
"master phandle not found" - you don't know where in the kernel it
came from, or even what device it's referring to.
> +
> + ret = of_mdiobus_register(bus, np);
> + if (ret)
> + return ret;
> +
> + platform_set_drvdata(pdev, bus);
> + return 0;
> +}
> +
> +static int
> +ipq8064_mdio_remove(struct platform_device *pdev)
> +{
> + struct mii_bus *bus = platform_get_drvdata(pdev);
> +
> + mdiobus_unregister(bus);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ipq8064_mdio_dt_ids[] = {
> + { .compatible = "qcom,ipq8064-mdio" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, ipq8064_mdio_dt_ids);
> +
> +static struct platform_driver ipq8064_mdio_driver = {
> + .probe = ipq8064_mdio_probe,
> + .remove = ipq8064_mdio_remove,
> + .driver = {
> + .name = "ipq8064-mdio",
> + .of_match_table = ipq8064_mdio_dt_ids,
> + },
> +};
> +
> +module_platform_driver(ipq8064_mdio_driver);
> +
> +MODULE_DESCRIPTION("Qualcomm IPQ8064 MDIO interface driver");
> +MODULE_AUTHOR("Christian Lamparter <chunkeey@gmail.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.25.0
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* [Intel-gfx] [PATCH v1] drm/i915: Use intel_plane_data_rate for min_cdclk calculation
From: Stanislav Lisovskiy @ 2020-02-20 15:23 UTC (permalink / raw)
To: intel-gfx; +Cc: jani.nikula
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate and which is also used in bandwidth
calculations. However for calculating min_cdclk we have another
piece of code, doing almost same calculation, but a bit differently
and in a different place. However as both are actually part of same
formula, probably would be wise to use plane data rate calculations
as a basis anyway, thus avoiding code duplication and possible bugs
related to this.
Another thing is that I've noticed that during min_cdclk calculations
we account for plane scaling, while for plane data rate, we don't.
crtc->pixel_rate seems to account only for pipe ratio, however it is
clearly stated in BSpec that plane data rate also need to account
plane ratio as well.
So what this commit does is:
- Adds a plane ratio calculation to intel_plane_data_rate
- Removes redundant calculations from skl_plane_min_cdclk which is
used for gen9+ and now uses intel_plane_data_rate as a basis from
there as well.
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 16 ++++++-
drivers/gpu/drm/i915/display/intel_sprite.c | 46 +++++++++++--------
2 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index c86d7a35c816..702dfa14d112 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -133,15 +133,27 @@ intel_plane_destroy_state(struct drm_plane *plane,
kfree(plane_state);
}
+
+
unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
const struct drm_framebuffer *fb = plane_state->hw.fb;
unsigned int cpp;
+ unsigned int src_w, src_h, dst_w, dst_h;
if (!plane_state->uapi.visible)
return 0;
+ src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
+ src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
+ dst_w = drm_rect_width(&plane_state->uapi.dst);
+ dst_h = drm_rect_height(&plane_state->uapi.dst);
+
+ /* Downscaling limits the maximum pixel rate */
+ dst_w = min(src_w, dst_w);
+ dst_h = min(src_h, dst_h);
+
cpp = fb->format->cpp[0];
/*
@@ -153,7 +165,9 @@ unsigned int intel_plane_data_rate(const struct intel_crtc_state *crtc_state,
if (fb->format->is_yuv && fb->format->num_planes > 1)
cpp *= 4;
- return cpp * crtc_state->pixel_rate;
+ return DIV64_U64_ROUND_UP(mul_u32_u32(cpp * crtc_state->pixel_rate,
+ src_w * src_h),
+ mul_u32_u32(dst_w, dst_h));
}
int intel_plane_calc_min_cdclk(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c
index 7abeefe8dce5..75afb78ff1b0 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -330,24 +330,34 @@ bool icl_is_hdr_plane(struct drm_i915_private *dev_priv, enum plane_id plane_id)
}
static void
-skl_plane_ratio(const struct intel_crtc_state *crtc_state,
- const struct intel_plane_state *plane_state,
- unsigned int *num, unsigned int *den)
+skl_plane_bpp_constraints(const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state,
+ unsigned int *num, unsigned int *den)
{
struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev);
const struct drm_framebuffer *fb = plane_state->hw.fb;
+ unsigned int cpp = fb->format->cpp[0];
+
+ /*
+ * Based on HSD#:1408715493
+ * NV12 cpp == 4, P010 cpp == 8
+ *
+ * FIXME what is the logic behind this?
+ */
+ if (fb->format->is_yuv && fb->format->num_planes > 1)
+ cpp *= 4;
if (fb->format->cpp[0] == 8) {
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
*num = 10;
- *den = 8;
+ *den = 8 * cpp;
} else {
*num = 9;
- *den = 8;
+ *den = 8 * cpp;
}
} else {
*num = 1;
- *den = 1;
+ *den = cpp;
}
}
@@ -355,27 +365,23 @@ static int skl_plane_min_cdclk(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
struct drm_i915_private *dev_priv = to_i915(plane_state->uapi.plane->dev);
- unsigned int pixel_rate = crtc_state->pixel_rate;
- unsigned int src_w, src_h, dst_w, dst_h;
unsigned int num, den;
+ struct intel_plane *plane = to_intel_plane(plane_state->uapi.plane);
- skl_plane_ratio(crtc_state, plane_state, &num, &den);
+ skl_plane_bpp_constraints(crtc_state, plane_state, &num, &den);
/* two pixels per clock on glk+ */
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
den *= 2;
- src_w = drm_rect_width(&plane_state->uapi.src) >> 16;
- src_h = drm_rect_height(&plane_state->uapi.src) >> 16;
- dst_w = drm_rect_width(&plane_state->uapi.dst);
- dst_h = drm_rect_height(&plane_state->uapi.dst);
-
- /* Downscaling limits the maximum pixel rate */
- dst_w = min(src_w, dst_w);
- dst_h = min(src_h, dst_h);
-
- return DIV64_U64_ROUND_UP(mul_u32_u32(pixel_rate * num, src_w * src_h),
- mul_u32_u32(den, dst_w * dst_h));
+ /*
+ * intel_atomic_check_planes has already been called by this
+ * time in intel_atomic_check, so use calculated plane
+ * data rate as a basis, in order not to have duplicate code.
+ * According to BSpec, plane data rate is anyway used as
+ * a basis for this calculation.
+ */
+ return DIV64_U64_ROUND_UP(crtc_state->data_rate[plane->id] * num, den);
}
static unsigned int
--
2.24.1.485.gad05a3d8e5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* Re: functionfs gadget with multiple endpoints
From: Alan Stern @ 2020-02-20 15:26 UTC (permalink / raw)
To: Belisko Marek; +Cc: Linux USB Mailing List
In-Reply-To: <CAAfyv36n=--KiHmdyS7hOGzF8fVtq8y=uZx0cxARgp7fUta4ng@mail.gmail.com>
On Thu, 20 Feb 2020, Belisko Marek wrote:
> Hi,
>
> I'm playing with functionfs and use configfs + functionfs + ffs-test
> from kernel to test connection between my device and host. ffs-test
> example provide 1 configuration with 1 interface and with 2 bulk
> endpoints.
>
> I'm writing application which will write/read data to usb device but
> can be accessed from other multiple application. I'm planning to write
> kind of gatekeeper which will serialize data to endpoint and notify
> reader about received data.
>
> I was thinking about other possibility to extend gadget to provide
> more endpoints (like 2). I was able to extend ffs-test and also I can
> send/receive data (using libusb) over original endpoints but not over
> new created one (I've run 2 instances of same application which
> basically create transfers for 2 different endpoints) but when running
> second application I got this error:
>
> libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=16
> libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=16
Only one program at a time can claim an interface, and submitting an
URB to an endpoint automatically claims the endpoint's interface.
> I'm not USB expert but multiple endpoint should be possible (maybe I
> need to put them to other interface?-> tried that also but got same
> error as above with errno=2). Thanks for any pointers and advice.
errno=16 and errno=2 are different errors, not the same error.
Putting the endpoints in different interfaces should work; you probably
have a bug somewhere in your code.
Alan Stern
^ 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.