* Re: [PATCH v4 11/26] arm64: mte: Add PROT_MTE support to mmap() and mprotect()
From: Peter Collingbourne @ 2020-05-27 18:57 UTC (permalink / raw)
To: Catalin Marinas
Cc: linux-arch, Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky,
linux-mm, Evgenii Stepanov, Vincenzo Frascino, Will Deacon,
Dave P Martin, Linux ARM
In-Reply-To: <20200515171612.1020-12-catalin.marinas@arm.com>
On Fri, May 15, 2020 at 10:16 AM Catalin Marinas
<catalin.marinas@arm.com> wrote:
>
> To enable tagging on a memory range, the user must explicitly opt in via
> a new PROT_MTE flag passed to mmap() or mprotect(). Since this is a new
> memory type in the AttrIndx field of a pte, simplify the or'ing of these
> bits over the protection_map[] attributes by making MT_NORMAL index 0.
Should the userspace stack always be mapped as if with PROT_MTE if the
hardware supports it? Such a change would be invisible to non-MTE
aware userspace since it would already need to opt in to tag checking
via prctl. This would let userspace avoid a complex stack
initialization sequence when running with stack tagging enabled on the
main thread.
Peter
_______________________________________________
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 070/105] drm/vc4: hdmi: rework connectors and encoders
From: Eric Anholt @ 2020-05-27 18:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, DRI Development,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <020de18840a1075b2671736c6cc2e451030fad74.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 8:51 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> the vc4_hdmi driver has some custom structures to hold the data it needs to
> associate with the drm_encoder and drm_connector structures.
>
> However, it allocates them separately from the vc4_hdmi structure which
> makes it more complicated than it needs to be.
>
> Move those structures to be contained by vc4_hdmi and update the code
> accordingly.
> @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
> struct drm_device *drm = dev_get_drvdata(master);
> struct vc4_dev *vc4 = drm->dev_private;
> struct vc4_hdmi *hdmi;
> - struct vc4_hdmi_encoder *vc4_hdmi_encoder;
> + struct drm_encoder *encoder;
> struct device_node *ddc_node;
> u32 value;
> int ret;
> @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct device *master, void *data)
> if (!hdmi)
> return -ENOMEM;
>
> - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder),
> - GFP_KERNEL);
> - if (!vc4_hdmi_encoder)
> - return -ENOMEM;
> - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
> - hdmi->encoder = &vc4_hdmi_encoder->base.base;
> -
> hdmi->pdev = pdev;
> + encoder = &hdmi->encoder.base.base;
> + encoder->base.type = VC4_ENCODER_TYPE_HDMI0;
Wait, does this patch build? setting struct drm_encoder->base.type =
VC4_* seems very wrong, when previously we were setting struct
vc4_hdmi_encoder->base.type (struct vc4_encoder->type).
Other than this, patch 68-78 r-b.
_______________________________________________
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] arm64: disable -fsanitize=shadow-call-stack for big-endian
From: Arnd Bergmann @ 2020-05-27 18:28 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Mark Rutland, Kees Cook, Fangrui Song, Catalin Marinas, LKML,
clang-built-linux, Sami Tolvanen, Will Deacon, Linux ARM
In-Reply-To: <CAKwvOdn637hSboMnMV=S5f1wbiEnc6qtnrn=fpeCGtvr2W_Daw@mail.gmail.com>
On Wed, May 27, 2020 at 7:28 PM 'Nick Desaulniers' via Clang Built
Linux <clang-built-linux@googlegroups.com> wrote:
>
> On Wed, May 27, 2020 at 8:24 AM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
> > > clang-11 and earlier do not support -fsanitize=shadow-call-stack
> > > in combination with -mbig-endian, but the Kconfig check does not
> > > pass the endianess flag, so building a big-endian kernel with
> > > this fails at build time:
> > >
> > > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
> > >
> > > Change the Kconfig check to let Kconfig figure this out earlier
> > > and prevent the broken configuration. I assume this is a bug
> > > in clang that needs to be fixed, but we also have to work
> > > around existing releases.
> > >
> > > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
> > > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > I suspect this is similar to the patchable-function-entry issue, and
> > this is an oversight that we'd rather fix toolchain side.
> >
> > Nick, Fangrui, thoughts?
>
> Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
> Thanks Fangrui!
Ok, great! I had opened the bug first so I could reference it in the
commit changelog, it seems the fix came fast than I managed to
send out the kernel workaround.
Do we still want the kernel workaround anyway to make it work
with older clang versions, or do we expect to fall back to not
use the integrated assembler for the moment?
Arnd
_______________________________________________
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] arm64: disable -fsanitize=shadow-call-stack for big-endian
From: Fangrui Song @ 2020-05-27 18:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, Kees Cook, Tom Stellard, Catalin Marinas,
Nick Desaulniers, LKML, clang-built-linux, Sami Tolvanen,
Will Deacon, Linux ARM
In-Reply-To: <CAK8P3a3-L-AQomvTcBv-KH1cVVu6uYNT_-2Ofir3UgwzGjcSug@mail.gmail.com>
On 2020-05-27, Arnd Bergmann wrote:
>On Wed, May 27, 2020 at 7:28 PM 'Nick Desaulniers' via Clang Built
>Linux <clang-built-linux@googlegroups.com> wrote:
>>
>> On Wed, May 27, 2020 at 8:24 AM Mark Rutland <mark.rutland@arm.com> wrote:
>> >
>> > On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
>> > > clang-11 and earlier do not support -fsanitize=shadow-call-stack
>> > > in combination with -mbig-endian, but the Kconfig check does not
>> > > pass the endianess flag, so building a big-endian kernel with
>> > > this fails at build time:
>> > >
>> > > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
>> > >
>> > > Change the Kconfig check to let Kconfig figure this out earlier
>> > > and prevent the broken configuration. I assume this is a bug
>> > > in clang that needs to be fixed, but we also have to work
>> > > around existing releases.
>> > >
>> > > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
>> > > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
>> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> >
>> > I suspect this is similar to the patchable-function-entry issue, and
>> > this is an oversight that we'd rather fix toolchain side.
>> >
>> > Nick, Fangrui, thoughts?
>>
>> Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
>> Thanks Fangrui!
>
>Ok, great! I had opened the bug first so I could reference it in the
>commit changelog, it seems the fix came fast than I managed to
>send out the kernel workaround.
>
>Do we still want the kernel workaround anyway to make it work
>with older clang versions, or do we expect to fall back to not
>use the integrated assembler for the moment?
>
> Arnd
We can condition it on `CLANG_VERSION >= 100001` (assuming Tom (CCed)
is happy (and there is still time) cherrying pick the two commits https://bugs.llvm.org/show_bug.cgi?id=46076 to clang 10.0.1)
_______________________________________________
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] [net-next] mtk-star-emac: mark PM functions as __maybe_unused
From: David Miller @ 2020-05-27 18:33 UTC (permalink / raw)
To: arnd
Cc: nbd, netdev, sean.wang, linux-kernel, bgolaszewski,
linux-mediatek, john, matthias.bgg, kuba, Mark-MC.Lee,
linux-arm-kernel
In-Reply-To: <20200527133513.579367-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 27 May 2020 15:34:45 +0200
> Without CONFIG_PM, the compiler warns about two unused functions:
>
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1472:12: error: unused function 'mtk_star_suspend' [-Werror,-Wunused-function]
> drivers/net/ethernet/mediatek/mtk_star_emac.c:1488:12: error: unused function 'mtk_star_resume' [-Werror,-Wunused-function]
>
> Mark these as __maybe_unused.
>
> Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied, thank you.
_______________________________________________
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] arm64: fix clang integrated assembler build
From: Fangrui Song @ 2020-05-27 18:28 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Arnd Bergmann, Will Deacon, clang-built-linux, Catalin Marinas,
LKML, # 3.4.x, Jian Cai, Alexios Zavras, Bill Wendling,
Enrico Weigelt, Linux ARM
In-Reply-To: <CAKwvOdnNxj-MdKj3aWoefF2W9PPG-TSeNU4Ym-N8NODJB5Yw_w@mail.gmail.com>
On 2020-05-27, 'Nick Desaulniers' via Clang Built Linux wrote:
>On Wed, May 27, 2020 at 7:14 AM Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> clang and gas seem to interpret the symbols in memmove.S and
>> memset.S differently, such that clang does not make them
>> 'weak' as expected, which leads to a linker error, with both
>> ld.bfd and ld.lld:
>>
>> ld.lld: error: duplicate symbol: memmove
>> >>> defined at common.c
>> >>> kasan/common.o:(memmove) in archive mm/built-in.a
>> >>> defined at memmove.o:(__memmove) in archive arch/arm64/lib/lib.a
>>
>> ld.lld: error: duplicate symbol: memset
>> >>> defined at common.c
>> >>> kasan/common.o:(memset) in archive mm/built-in.a
>> >>> defined at memset.o:(__memset) in archive arch/arm64/lib/lib.a
>>
>> Copy the exact way these are written in memcpy_64.S, which does
>> not have the same problem.
>>
>> I don't know why this makes a difference, and it would be good
>> to have someone with a better understanding of assembler internals
>> review it.
>>
>> It might be either a bug in the kernel or a bug in the assembler,
>> no idea which one. My patch makes it work with all versions of
>> clang and gcc, which is probably helpful even if it's a workaround
>> for a clang bug.
>
>+ Bill, Fangrui, Jian
>I think we saw this bug or a very similar bug internally around the
>ordering of .weak to .global.
This may be another instance of
https://sourceware.org/pipermail/binutils/2020-March/000299.html
https://lore.kernel.org/linuxppc-dev/20200325164257.170229-1-maskray@google.com/
I haven't checked but there may be both a .globl directive and a .weak
directive
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> ---
>> arch/arm64/lib/memcpy.S | 3 +--
>> arch/arm64/lib/memmove.S | 3 +--
>> arch/arm64/lib/memset.S | 3 +--
>> 3 files changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
>> index e0bf83d556f2..dc8d2a216a6e 100644
>> --- a/arch/arm64/lib/memcpy.S
>> +++ b/arch/arm64/lib/memcpy.S
>> @@ -56,9 +56,8 @@
>> stp \reg1, \reg2, [\ptr], \val
>> .endm
>>
>> - .weak memcpy
>> SYM_FUNC_START_ALIAS(__memcpy)
>> -SYM_FUNC_START_PI(memcpy)
>> +SYM_FUNC_START_WEAK_PI(memcpy)
>> #include "copy_template.S"
>> ret
>> SYM_FUNC_END_PI(memcpy)
>> diff --git a/arch/arm64/lib/memmove.S b/arch/arm64/lib/memmove.S
>> index 02cda2e33bde..1035dce4bdaf 100644
>> --- a/arch/arm64/lib/memmove.S
>> +++ b/arch/arm64/lib/memmove.S
>> @@ -45,9 +45,8 @@ C_h .req x12
>> D_l .req x13
>> D_h .req x14
>>
>> - .weak memmove
>> SYM_FUNC_START_ALIAS(__memmove)
>> -SYM_FUNC_START_PI(memmove)
>> +SYM_FUNC_START_WEAK_PI(memmove)
>> cmp dstin, src
>> b.lo __memcpy
>> add tmp1, src, count
>> diff --git a/arch/arm64/lib/memset.S b/arch/arm64/lib/memset.S
>> index 77c3c7ba0084..a9c1c9a01ea9 100644
>> --- a/arch/arm64/lib/memset.S
>> +++ b/arch/arm64/lib/memset.S
>> @@ -42,9 +42,8 @@ dst .req x8
>> tmp3w .req w9
>> tmp3 .req x9
>>
>> - .weak memset
>> SYM_FUNC_START_ALIAS(__memset)
>> -SYM_FUNC_START_PI(memset)
>> +SYM_FUNC_START_WEAK_PI(memset)
>> mov dst, dstin /* Preserve return value. */
>> and A_lw, val, #255
>> orr A_lw, A_lw, A_lw, lsl #8
>> --
>> 2.26.2
>
>--
>Thanks,
>~Nick Desaulniers
>
>--
>You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CAKwvOdnNxj-MdKj3aWoefF2W9PPG-TSeNU4Ym-N8NODJB5Yw_w%40mail.gmail.com.
_______________________________________________
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 041/105] drm/vc4: crtc: Move HVS mode config to HVS file
From: Eric Anholt @ 2020-05-27 18:26 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, DRI Development,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <afcc607bdcaf9ad38480f49cc1fa186ebe6f2d5a.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 272 +-------------------------------
> drivers/gpu/drm/vc4/vc4_drv.h | 5 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 298 ++++++++++++++++++++++++++++++++++-
> 3 files changed, 309 insertions(+), 266 deletions(-)
> static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> {
> - struct drm_device *dev = crtc->dev;
> - struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> - struct drm_display_mode *mode = &crtc->state->adjusted_mode;
> - bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
> bool debug_dump_regs = false;
>
> if (debug_dump_regs) {
> @@ -418,42 +372,10 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> drm_print_regset32(&p, &vc4_crtc->regset);
> }
>
> - if (vc4_crtc->data->hvs_output == 2) {
> - u32 dispctrl;
> - u32 dsp3_mux;
> -
> - /*
> - * SCALER_DISPCTRL_DSP3 = X, where X < 2 means 'connect DSP3 to
> - * FIFO X'.
> - * SCALER_DISPCTRL_DSP3 = 3 means 'disable DSP 3'.
> - *
> - * DSP3 is connected to FIFO2 unless the transposer is
> - * enabled. In this case, FIFO 2 is directly accessed by the
> - * TXP IP, and we need to disable the FIFO2 -> pixelvalve1
> - * route.
> - */
> - if (vc4_state->feed_txp)
> - dsp3_mux = VC4_SET_FIELD(3, SCALER_DISPCTRL_DSP3_MUX);
> - else
> - dsp3_mux = VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX);
> -
> - dispctrl = HVS_READ(SCALER_DISPCTRL) &
> - ~SCALER_DISPCTRL_DSP3_MUX_MASK;
> - HVS_WRITE(SCALER_DISPCTRL, dispctrl | dsp3_mux);
> - }
I just noticed, this block being moved looks like it should probably
have been removed as part of patch #33. Cleaning this up I think will
impact the following patches.
_______________________________________________
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] net: ethernet: mtk-star-emac: fix error path in RX handling
From: David Miller @ 2020-05-27 18:25 UTC (permalink / raw)
To: brgl
Cc: stephane.leprovost, bgolaszewski, netdev, sean.wang, linux-kernel,
fparent, pedro.tsai, linux-mediatek, andrew.perepech, john,
matthias.bgg, kuba, natechancellor, Mark-MC.Lee, linux-arm-kernel
In-Reply-To: <20200527092404.3567-1-brgl@bgdev.pl>
From: Bartosz Golaszewski <brgl@bgdev.pl>
Date: Wed, 27 May 2020 11:24:04 +0200
> From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>
> The dma_addr field in desc_data must not be overwritten until after the
> new skb is mapped. Currently we do replace it with uninitialized value
> in error path. This change fixes it by moving the assignment before the
> label to which we jump after mapping or allocation errors.
>
> Fixes: 8c7bd5a454ff ("net: ethernet: mtk-star-emac: new driver")
> Reported-by: Nathan Chancellor <natechancellor@gmail.com>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied, please use "[PATCH net-next]" to clearly indicate the target
GIT tree next time.
Thank you.
_______________________________________________
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 0/2] Introduce PCI_FIXUP_IOMMU
From: Bjorn Helgaas @ 2020-05-27 18:18 UTC (permalink / raw)
To: Zhangfei Gao
Cc: jean-philippe, Lorenzo Pieralisi, Herbert Xu, Arnd Bergmann,
linux-pci, Greg Kroah-Hartman, Joerg Roedel, Hanjun Guo,
Rafael J. Wysocki, linux-kernel, iommu, linux-acpi, Wangzhou,
linux-crypto, Sudeep Holla, Bjorn Helgaas, kenneth-lee-2012,
linux-arm-kernel, Len Brown
In-Reply-To: <1590493749-13823-1-git-send-email-zhangfei.gao@linaro.org>
On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
> Some platform devices appear as PCI but are actually on the AMBA bus,
> and they need fixup in drivers/pci/quirks.c handling iommu_fwnode.
> Here introducing PCI_FIXUP_IOMMU, which is called after iommu_fwnode
> is allocated, instead of reusing PCI_FIXUP_FINAL since it will slow
> down iommu probing as all devices in fixup final list will be
> reprocessed, suggested by Joerg, [1]
Is this slowdown significant? We already iterate over every device
when applying PCI_FIXUP_FINAL quirks, so if we used the existing
PCI_FIXUP_FINAL, we wouldn't be adding a new loop. We would only be
adding two more iterations to the loop in pci_do_fixups() that tries
to match quirks against the current device. I doubt that would be a
measurable slowdown.
> For example:
> Hisilicon platform device need fixup in
> drivers/pci/quirks.c handling fwspec->can_stall, which is introduced in [2]
>
> +static void quirk_huawei_pcie_sva(struct pci_dev *pdev)
> +{
> + struct iommu_fwspec *fwspec;
> +
> + pdev->eetlp_prefix_path = 1;
> + fwspec = dev_iommu_fwspec_get(&pdev->dev);
> + if (fwspec)
> + fwspec->can_stall = 1;
> +}
> +
> +DECLARE_PCI_FIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa250, quirk_huawei_pcie_sva);
> +DECLARE_PCI_iFIXUP_IOMMU(PCI_VENDOR_ID_HUAWEI, 0xa251, quirk_huawei_pcie_sva);
>
> [1] https://www.spinics.net/lists/iommu/msg44591.html
> [2] https://www.spinics.net/lists/linux-pci/msg94559.html
If you reference these in the commit logs, please use lore.kernel.org
links instead of spinics.
> Zhangfei Gao (2):
> PCI: Introduce PCI_FIXUP_IOMMU
> iommu: calling pci_fixup_iommu in iommu_fwspec_init
>
> drivers/iommu/iommu.c | 4 ++++
> drivers/pci/quirks.c | 7 +++++++
> include/asm-generic/vmlinux.lds.h | 3 +++
> include/linux/pci.h | 8 ++++++++
> 4 files changed, 22 insertions(+)
>
> --
> 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
* Re: [PATCH v2 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
From: Geert Uytterhoeven @ 2020-05-27 18:18 UTC (permalink / raw)
To: Rob Herring
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Laurent Pinchart, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
In-Reply-To: <CAL_JsqJgQajnKdQ1Bt6YFX04fX0VGz44Q3kBdLLR04OzhWrH5A@mail.gmail.com>
Hi Rob,
On Wed, May 27, 2020 at 7:30 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > > If we want to be more strict and require the definition of all the
> > > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > > at them and it's not always clear which regulators to use or if they are
> > > > > > even defined.
> > > > >
> > > > > We can decouple the two though (I think). The bindings should reflect
> > > > > what we consider right, and the dts files could be fixed on top.
> > > >
> > > > Do you have a suggestion on how to do this? If we decouple the two
> > > > tasks most of the work would be searching for DTs to fix and finding a
> > > > way to fix each one of them, and unless I do this _before_ the binding
> > > > conversion I'll get a lot of dtbs_check errors.
> > >
> > > Rob should answer this question as it will be his decision, but I've
> > > personally never considered non-compliant DT sources to be an obstacle
> > > to bindings conversion to YAML. The DT sources should be fixed, but I
> > > don't see it as a prerequisite (although it's a good practice).
>
> There's currently no requirement that binding schema don't introduce
> warnings in dts files. That should change when/if we get to a warning
> free state (probably per platform/family). I don't think we're close
> on any platform? (If we are, I'd like to start tracking that). It is
> good to pay attention to the warnings you get though as the schema may
> not be doing what you expect or the binding really doesn't match
> reality.
OK.
> > I do my best to avoid introducing regressions when the binding conversions
> > go upstream.
>
> Meaning you fix the dts files or massage the schema to match? If we
> just adjust schema to match, what's the point in this effort? We
> should find things wrong or ill defined.
I fix up DTS files, and fast-track those fixes, so they appear upstream before
the DT binding conversion, where possible.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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] arm64: vdso32: force vdso32 to be compiled as -marm
From: Nick Desaulniers @ 2020-05-27 18:17 UTC (permalink / raw)
To: Will Deacon
Cc: Naohiro Aota, Stephen Boyd, Catalin Marinas, Masahiro Yamada,
LKML, Manoj Gupta, Luis Lozano, Nathan Chancellor,
Vincenzo Frascino, Robin Murphy, Linux ARM
In-Reply-To: <20200527180839.GA16411@willie-the-truck>
On Wed, May 27, 2020 at 11:08 AM Will Deacon <will@kernel.org> wrote:
>
> On Wed, May 27, 2020 at 10:55:24AM -0700, Nick Desaulniers wrote:
> > On Wed, May 27, 2020 at 6:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > >
> > > On 2020-05-26 18:31, Nick Desaulniers wrote:
> > > > Custom toolchains that modify the default target to -mthumb cannot
> > > > compile the arm64 compat vdso32, as
> > > > arch/arm64/include/asm/vdso/compat_gettimeofday.h
> > > > contains assembly that's invalid in -mthumb. Force the use of -marm,
> > > > always.
> > >
> > > FWIW, this seems suspicious - the only assembly instructions I see there
> > > are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the
> > > -march=armv7a baseline that we set.
> > >
> > > On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and
> > > built a Thumb VDSO quite happily with Ubuntu 19.04's
> > > gcc-arm-linux-gnueabihf. What was the actual failure you saw?
> >
> > From the link in the commit message: `write to reserved register 'R7'`
> > https://godbolt.org/z/zwr7iZ
> > IIUC r7 is reserved for the frame pointer in THUMB?
> >
> > What is the implicit default of your gcc-arm-linux-gnueabihf at -O2?
> > -mthumb, or -marm?
>
> Hmm, but this *is* weird because if I build a 32-bit kernel then I get
> either an ARM or a Thumb-2 VDSO depending on CONFIG_THUMB2_KERNEL. I'm
> not sure if that's deliberate, but both build and appear to work.
That's because there's 3 VDSO's when it comes to ARM:
arm64's 64b vdso: arch/arm64/kernel/vdso
arm64's 32b vdso: arch/arm64/kernel/vdso32/
arm's 32b vdso: arch/arm/kernel/vdso.c
When you build a 32b kernel, you're only making use of the last of
those three; the arm64 vdso and vdso32 code is irrelevant.
This patch is specific to the second case, which is the 32b compat
vdso for a 64b kernel.
>
> I'll drop this patch for now, while we figure it out a bit more.
>
> Cheers,
>
> Will
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] clk: versatile: Fix kconfig dependency on COMMON_CLK_VERSATILE
From: Rob Herring @ 2020-05-27 18:13 UTC (permalink / raw)
To: soc
Cc: anders.roxell, Stephen Boyd, Linus Walleij, linux-clk,
Michael Turquette, linux-arm-kernel
If COMPILE_TEST is enabled, then COMMON_CLK_VERSATILE can be disabled
when dependent options like ICST are selected resulting in kconfig
warnings:
WARNING: unmet direct dependencies detected for ICST
Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_VERSATILE [=n]
Selected by [y]:
- ARCH_REALVIEW [=y] && (ARCH_MULTI_V5 [=n] || ARCH_MULTI_V6 [=n] || ARCH_MULTI_V7 [=y])
- ARCH_VEXPRESS [=y] && ARCH_MULTI_V7 [=y]
- ARCH_ZYNQ [=y] && ARCH_MULTI_V7 [=y]
WARNING: unmet direct dependencies detected for CLK_SP810
Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_VERSATILE [=n]
Selected by [y]:
- ARCH_REALVIEW [=y] && (ARCH_MULTI_V5 [=n] || ARCH_MULTI_V6 [=n] || ARCH_MULTI_V7 [=y])
Fix this by dropping COMMON_CLK_VERSATILE and just using 'menu' instead
of 'menuconfig'.
Fixes: 81134fb541d4 ("clk: versatile: Rework kconfig structure")
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-clk@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
Please apply this along with Ander's fixes to the SoC tree.
Note that this patch[1] is also need to resolve the kconfig issues.
Michal said he would apply it.
Rob
[1] https://lore.kernel.org/linux-arm-kernel/20200409221829.29421-1-robh@kernel.org/
drivers/clk/versatile/Kconfig | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/versatile/Kconfig b/drivers/clk/versatile/Kconfig
index a0ed412e8396..8c1b0e8e8d32 100644
--- a/drivers/clk/versatile/Kconfig
+++ b/drivers/clk/versatile/Kconfig
@@ -1,11 +1,8 @@
# SPDX-License-Identifier: GPL-2.0-only
-menuconfig COMMON_CLK_VERSATILE
- bool "Clock driver for ARM Reference designs" if COMPILE_TEST
- default y if ARCH_INTEGRATOR || ARCH_REALVIEW || \
- ARCH_VERSATILE || ARCH_VEXPRESS
-
-if COMMON_CLK_VERSATILE
+menu "Clock driver for ARM Reference designs"
+ depends on ARCH_INTEGRATOR || ARCH_REALVIEW || \
+ ARCH_VERSATILE || ARCH_VEXPRESS || COMPILE_TEST
config ICST
bool "Clock driver for ARM Reference designs ICST"
@@ -32,4 +29,4 @@ config CLK_VEXPRESS_OSC
Express platforms hidden behind its configuration infrastructure,
commonly known as OSCs.
-endif
+endmenu
--
2.25.1
_______________________________________________
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] arm64: vdso32: force vdso32 to be compiled as -marm
From: Will Deacon @ 2020-05-27 18:08 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Naohiro Aota, Stephen Boyd, Catalin Marinas, Masahiro Yamada,
LKML, Manoj Gupta, Luis Lozano, Nathan Chancellor,
Vincenzo Frascino, Robin Murphy, Linux ARM
In-Reply-To: <CAKwvOd=Oy_OfRbL6-q-3CAHxWBNBKE+HkfNfgCiP726u+4dU1Q@mail.gmail.com>
On Wed, May 27, 2020 at 10:55:24AM -0700, Nick Desaulniers wrote:
> On Wed, May 27, 2020 at 6:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >
> > On 2020-05-26 18:31, Nick Desaulniers wrote:
> > > Custom toolchains that modify the default target to -mthumb cannot
> > > compile the arm64 compat vdso32, as
> > > arch/arm64/include/asm/vdso/compat_gettimeofday.h
> > > contains assembly that's invalid in -mthumb. Force the use of -marm,
> > > always.
> >
> > FWIW, this seems suspicious - the only assembly instructions I see there
> > are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the
> > -march=armv7a baseline that we set.
> >
> > On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and
> > built a Thumb VDSO quite happily with Ubuntu 19.04's
> > gcc-arm-linux-gnueabihf. What was the actual failure you saw?
>
> From the link in the commit message: `write to reserved register 'R7'`
> https://godbolt.org/z/zwr7iZ
> IIUC r7 is reserved for the frame pointer in THUMB?
>
> What is the implicit default of your gcc-arm-linux-gnueabihf at -O2?
> -mthumb, or -marm?
Hmm, but this *is* weird because if I build a 32-bit kernel then I get
either an ARM or a Thumb-2 VDSO depending on CONFIG_THUMB2_KERNEL. I'm
not sure if that's deliberate, but both build and appear to work.
I'll drop this patch for now, while we figure it out a bit more.
Cheers,
Will
_______________________________________________
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] arm64: fix clang integrated assembler build
From: Nick Desaulniers @ 2020-05-27 18:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Fangrui Song, Will Deacon, clang-built-linux, Catalin Marinas,
LKML, # 3.4.x, Jian Cai, Alexios Zavras, Bill Wendling,
Enrico Weigelt, Linux ARM
In-Reply-To: <20200527141435.1716510-1-arnd@arndb.de>
On Wed, May 27, 2020 at 7:14 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> clang and gas seem to interpret the symbols in memmove.S and
> memset.S differently, such that clang does not make them
> 'weak' as expected, which leads to a linker error, with both
> ld.bfd and ld.lld:
>
> ld.lld: error: duplicate symbol: memmove
> >>> defined at common.c
> >>> kasan/common.o:(memmove) in archive mm/built-in.a
> >>> defined at memmove.o:(__memmove) in archive arch/arm64/lib/lib.a
>
> ld.lld: error: duplicate symbol: memset
> >>> defined at common.c
> >>> kasan/common.o:(memset) in archive mm/built-in.a
> >>> defined at memset.o:(__memset) in archive arch/arm64/lib/lib.a
>
> Copy the exact way these are written in memcpy_64.S, which does
> not have the same problem.
>
> I don't know why this makes a difference, and it would be good
> to have someone with a better understanding of assembler internals
> review it.
>
> It might be either a bug in the kernel or a bug in the assembler,
> no idea which one. My patch makes it work with all versions of
> clang and gcc, which is probably helpful even if it's a workaround
> for a clang bug.
+ Bill, Fangrui, Jian
I think we saw this bug or a very similar bug internally around the
ordering of .weak to .global.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> ---
> arch/arm64/lib/memcpy.S | 3 +--
> arch/arm64/lib/memmove.S | 3 +--
> arch/arm64/lib/memset.S | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/lib/memcpy.S b/arch/arm64/lib/memcpy.S
> index e0bf83d556f2..dc8d2a216a6e 100644
> --- a/arch/arm64/lib/memcpy.S
> +++ b/arch/arm64/lib/memcpy.S
> @@ -56,9 +56,8 @@
> stp \reg1, \reg2, [\ptr], \val
> .endm
>
> - .weak memcpy
> SYM_FUNC_START_ALIAS(__memcpy)
> -SYM_FUNC_START_PI(memcpy)
> +SYM_FUNC_START_WEAK_PI(memcpy)
> #include "copy_template.S"
> ret
> SYM_FUNC_END_PI(memcpy)
> diff --git a/arch/arm64/lib/memmove.S b/arch/arm64/lib/memmove.S
> index 02cda2e33bde..1035dce4bdaf 100644
> --- a/arch/arm64/lib/memmove.S
> +++ b/arch/arm64/lib/memmove.S
> @@ -45,9 +45,8 @@ C_h .req x12
> D_l .req x13
> D_h .req x14
>
> - .weak memmove
> SYM_FUNC_START_ALIAS(__memmove)
> -SYM_FUNC_START_PI(memmove)
> +SYM_FUNC_START_WEAK_PI(memmove)
> cmp dstin, src
> b.lo __memcpy
> add tmp1, src, count
> diff --git a/arch/arm64/lib/memset.S b/arch/arm64/lib/memset.S
> index 77c3c7ba0084..a9c1c9a01ea9 100644
> --- a/arch/arm64/lib/memset.S
> +++ b/arch/arm64/lib/memset.S
> @@ -42,9 +42,8 @@ dst .req x8
> tmp3w .req w9
> tmp3 .req x9
>
> - .weak memset
> SYM_FUNC_START_ALIAS(__memset)
> -SYM_FUNC_START_PI(memset)
> +SYM_FUNC_START_WEAK_PI(memset)
> mov dst, dstin /* Preserve return value. */
> and A_lw, val, #255
> orr A_lw, A_lw, A_lw, lsl #8
> --
> 2.26.2
--
Thanks,
~Nick Desaulniers
_______________________________________________
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] arm64: vdso32: force vdso32 to be compiled as -marm
From: Nick Desaulniers @ 2020-05-27 17:58 UTC (permalink / raw)
To: Dave Martin
Cc: Naohiro Aota, Stephen Boyd, Catalin Marinas, Masahiro Yamada,
LKML, Manoj Gupta, Luis Lozano, Nathan Chancellor,
Vincenzo Frascino, Will Deacon, Linux ARM
In-Reply-To: <20200527135322.GU5031@arm.com>
On Wed, May 27, 2020 at 6:53 AM Dave Martin <Dave.Martin@arm.com> wrote:
>
> On Tue, May 26, 2020 at 09:45:05PM +0100, Will Deacon wrote:
> > On Tue, 26 May 2020 10:31:14 -0700, Nick Desaulniers wrote:
> > > Custom toolchains that modify the default target to -mthumb cannot
>
> It's probably too late to water this down, but it's unfortunate to have
> this comment in the upstream commit history.
>
> It's not constructive to call the native compiler configuration of
> major distros for many years a "custom" toolchain. Unmodified GCC has
I don't think you know which toolchain or distro I'm referring to. ;)
> had a clean configure option for this for a very long time; it's not
> someone's dirty hack. (The wisdom of armhf's choice of -mthumb might
> be debated, but it is well established.)
>
> Ignoring the triplet and passing random options to a compiler in the
> hopes that it will do the right thing for an irregular usecase has never
> been reliable. Usecases don't get much more irregular than building
> vdso32.
>
> arch/arm has the proper options in its Makefiles.
>
> This patch is a kernel bugfix, plain and simple.
Borrowing from the Zen of Python: Explicit is better than Implicit.
Better not to rely on implicit defaults that may be changed at configure time.
> Does this need to go to stable?
Oh, probably. Need to wait until it hits mainline now. I don't think
the compat vdso series was backported to 5.4, but IIUC stable
maintains a branch for the latest release, which would have that
series.
--
Thanks,
~Nick Desaulniers
_______________________________________________
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] arm64: vdso32: force vdso32 to be compiled as -marm
From: Nick Desaulniers @ 2020-05-27 17:55 UTC (permalink / raw)
To: Robin Murphy
Cc: Naohiro Aota, Stephen Boyd, Catalin Marinas, Masahiro Yamada,
LKML, Manoj Gupta, Luis Lozano, Nathan Chancellor,
Vincenzo Frascino, Will Deacon, Linux ARM
In-Reply-To: <2f58c2a4-0f37-d507-7767-00161c6b5d98@arm.com>
On Wed, May 27, 2020 at 6:45 AM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2020-05-26 18:31, Nick Desaulniers wrote:
> > Custom toolchains that modify the default target to -mthumb cannot
> > compile the arm64 compat vdso32, as
> > arch/arm64/include/asm/vdso/compat_gettimeofday.h
> > contains assembly that's invalid in -mthumb. Force the use of -marm,
> > always.
>
> FWIW, this seems suspicious - the only assembly instructions I see there
> are SWI(SVC), MRRC, and a MOV, all of which exist in Thumb for the
> -march=armv7a baseline that we set.
>
> On a hunch, I've just bodged "VDSO_CFLAGS += -mthumb" into my tree and
> built a Thumb VDSO quite happily with Ubuntu 19.04's
> gcc-arm-linux-gnueabihf. What was the actual failure you saw?
From the link in the commit message: `write to reserved register 'R7'`
https://godbolt.org/z/zwr7iZ
IIUC r7 is reserved for the frame pointer in THUMB?
What is the implicit default of your gcc-arm-linux-gnueabihf at -O2?
-mthumb, or -marm?
--
Thanks,
~Nick Desaulniers
_______________________________________________
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 RFCv2 0/9] kvm/arm64: Support Async Page Fault
From: Paolo Bonzini @ 2020-05-27 16:10 UTC (permalink / raw)
To: Marc Zyngier, Gavin Shan
Cc: Mark Rutland, aarcange, drjones, suzuki.poulose, catalin.marinas,
linux-kernel, eric.auger, james.morse, shan.gavin, will, kvmarm,
linux-arm-kernel
In-Reply-To: <ae0f32fa338969d25dc3da56292e35ed@kernel.org>
On 27/05/20 09:48, Marc Zyngier wrote:
>
> My own question is whether this even makes any sense 10 years later.
> The HW has massively changed, and this adds a whole lot of complexity
> to both the hypervisor and the guest.
It still makes sense, but indeed it's for different reasons. One
example is host page cache sharing, where (parts of) the host page cache
are visible to the guest. In this context, async page faults are used
for any kind of host page faults, not just paging out memory due to
overcommit.
But I agree that it is very very important to design the exception model
first, as we're witnessing in x86 land the problems with a poor design.
Nothing major, but just pain all around.
Paolo
> It also plays very ugly games
> with the exception model, which doesn't give me the warm fuzzy feeling
> that it's going to be great.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5] Add virtio SCMI device specification
From: Peter Hilber @ 2020-05-27 17:43 UTC (permalink / raw)
To: virtio-comment
Cc: virtio-dev, Souvik.Chakravarty, jean-philippe, Peter Hilber,
Sudeep.Holla, alex.bennee, linux-arm-kernel
This patch proposes a new virtio device for the Arm SCMI protocol.
The device provides a simple transport for the Arm SCMI protocol[1]. The
*S*ystem *C*ontrol and *M*anagement *I*nterface protocol allows speaking
to system controllers that allow orchestrating things like power
management, system state management and sensor access. The SCMI protocol
is used on SoCs where multiple cores and co-processors need access to
these resources.
The virtio transport allows making use of this protocol in virtualized
systems.
[1] https://developer.arm.com/docs/den0056/b
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
---
Notes:
Changes for v5:
- Remove requirements on shared memory added in v4, since an upcoming
new version of the Arm SCMI spec[1] will provide a generic, more
powerful way to handle concurrent access to shared memory.
Changes for v4:
- Add more requirements on shared memory regions after feedback from
Alex Bennée.
Changes for v3:
- Add tentative device ID 32 in device section.
- Remove redundant 'len' fields. The length of the payload fields can
already be deduced from the generic virtqueue 'len' fields. Therefore,
remove the redundant device-specific 'len' fields.
- Reword requirement that driver must not put too small buffers into
eventq.
Changes for v2:
- CC virtio-dev list.
- Define size of erroneous delayed/not delayed responses.
- Use correct long name for SCMI.
- Remove restriction to `embedded' in commit message.
- Add motivation for conceptual per-message-channels.
- Device may now just drop notification if no buffers are available.
OpenSynergy has a prototype implementation (without the
VIRTIO_SCMI_F_SHARED_MEMORY feature so far), and plans to upstream the
Linux kernel driver.
The PDF output is available at [2].
[2] https://share.mailbox.org/ajax/share/056076e70571144f50c4ca7571144b319a1d7236dda1cd3b/1/8/MzQ/MzQvMQ
Interdiff against v4:
diff --git a/conformance.tex b/conformance.tex
index 1b9f57a..99f037a 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -228,7 +228,6 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\begin{itemize}
\item \ref{drivernormative:Device Types / SCMI Device / Device Operation / cmdq Operation}
\item \ref{drivernormative:Device Types / SCMI Device / Device Operation / Setting Up eventq Buffers}
-\item \ref{drivernormative:Device Types / SCMI Device / Device Operation / Shared Memory Operation}
\end{itemize}
\conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
diff --git a/virtio-scmi.tex b/virtio-scmi.tex
index d66b818..c4b8dd0 100644
--- a/virtio-scmi.tex
+++ b/virtio-scmi.tex
@@ -269,13 +269,3 @@ \subsubsection{Shared Memory Operation}
Reserved for future use & 0x100 and greater \\
\hline
\end{tabular}
-
-The device MUST align all scalar elements of a shared memory region.
-
-The device MUST perform all accesses to scalar elements of a shared
-memory region atomically.
-
-\drivernormative{\paragraph}{Shared Memory Operation}{Device Types / SCMI Device / Device Operation / Shared Memory Operation}
-
-The driver MUST perform all accesses to scalar elements of a shared
-memory region atomically.
conformance.tex | 27 ++++-
content.tex | 1 +
introduction.tex | 3 +
virtio-scmi.tex | 271 +++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 299 insertions(+), 3 deletions(-)
create mode 100644 virtio-scmi.tex
diff --git a/conformance.tex b/conformance.tex
index b6fdec0..99f037a 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -15,7 +15,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\begin{itemize}
\item Clause \ref{sec:Conformance / Driver Conformance}.
\item One of clauses \ref{sec:Conformance / Driver Conformance / PCI Driver Conformance}, \ref{sec:Conformance / Driver Conformance / MMIO Driver Conformance} or \ref{sec:Conformance / Driver Conformance / Channel I/O Driver Conformance}.
- \item One of clauses \ref{sec:Conformance / Driver Conformance / Network Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Block Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Console Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Entropy Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Traditional Memory Balloon Driver Conformance}, \ref{sec:Conformance / Driver Conformance / SCSI Host Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Input Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Crypto Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Socket Driver Conformance} or \ref{sec:Conformance / Driver Conformance / IOMMU Driver Conformance}.
+ \item One of clauses \ref{sec:Conformance / Driver Conformance / Network Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Block Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Console Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Entropy Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Traditional Memory Balloon Driver Conformance}, \ref{sec:Conformance / Driver Conformance / SCSI Host Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Input Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Crypto Driver Conformance}, \ref{sec:Conformance / Driver Conformance / Socket Driver Conformance}, \ref{sec:Conformance / Driver Conformance / IOMMU Driver Conformance} or \ref{sec:Conformance / Driver Conformance / SCMI Driver Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
\end{itemize}
\item[Device] A device MUST conform to four conformance clauses:
@@ -32,8 +32,9 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\ref{sec:Conformance / Device Conformance / Input Device Conformance},
\ref{sec:Conformance / Device Conformance / Crypto Device Conformance},
\ref{sec:Conformance / Device Conformance / Socket Device Conformance},
-\ref{sec:Conformance / Device Conformance / RPMB Device Conformance} or
-\ref{sec:Conformance / Device Conformance / IOMMU Device Conformance}.
+\ref{sec:Conformance / Device Conformance / RPMB Device Conformance},
+\ref{sec:Conformance / Device Conformance / IOMMU Device Conformance} or
+\ref{sec:Conformance / Device Conformance / SCMI Device Conformance}.
\item Clause \ref{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}.
\end{itemize}
\end{description}
@@ -220,6 +221,15 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item \ref{drivernormative:Device Types / IOMMU Device / Device operations / Fault reporting}
\end{itemize}
+\conformance{\subsection}{SCMI Driver Conformance}\label{sec:Conformance / Driver Conformance / SCMI Driver Conformance}
+
+An SCMI driver MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{drivernormative:Device Types / SCMI Device / Device Operation / cmdq Operation}
+\item \ref{drivernormative:Device Types / SCMI Device / Device Operation / Setting Up eventq Buffers}
+\end{itemize}
+
\conformance{\section}{Device Conformance}\label{sec:Conformance / Device Conformance}
A device MUST conform to the following normative statements:
@@ -408,6 +418,17 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
\item \ref{devicenormative:Device Types / IOMMU Device / Device operations / Fault reporting}
\end{itemize}
+\conformance{\subsection}{SCMI Device Conformance}\label{sec:Conformance / Device Conformance / SCMI Device Conformance}
+
+An SCMI device MUST conform to the following normative statements:
+
+\begin{itemize}
+\item \ref{devicenormative:Device Types / SCMI Device / Feature bits}
+\item \ref{devicenormative:Device Types / SCMI Device / Device Operation / cmdq Operation}
+\item \ref{devicenormative:Device Types / SCMI Device / Device Operation / eventq Operation}
+\item \ref{devicenormative:Device Types / SCMI Device / Device Operation / Shared Memory Operation}
+\end{itemize}
+
\conformance{\section}{Legacy Interface: Transitional Device and Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance}
A conformant implementation MUST be either transitional or
non-transitional, see \ref{intro:Legacy
diff --git a/content.tex b/content.tex
index 91735e3..1e871e2 100644
--- a/content.tex
+++ b/content.tex
@@ -6062,6 +6062,7 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
\input{virtio-fs.tex}
\input{virtio-rpmb.tex}
\input{virtio-iommu.tex}
+\input{virtio-scmi.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
diff --git a/introduction.tex b/introduction.tex
index 33da3ec..3a2ee80 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -66,6 +66,9 @@ \section{Normative References}\label{sec:Normative References}
\phantomsection\label{intro:eMMC}\textbf{[eMMC]} &
eMMC Electrical Standard (5.1), JESD84-B51,
\newline\url{http://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf}\\
+ \phantomsection\label{intro:SCMI}\textbf{[SCMI]} &
+ Arm System Control and Management Interface, DEN0056,
+ \newline\url{https://developer.arm.com/docs/den0056/b}, version B and any future revisions\\
\end{longtable}
diff --git a/virtio-scmi.tex b/virtio-scmi.tex
new file mode 100644
index 0000000..c4b8dd0
--- /dev/null
+++ b/virtio-scmi.tex
@@ -0,0 +1,271 @@
+\section{SCMI Device}\label{sec:Device Types / SCMI Device}
+
+An SCMI device implements the Arm System Control and Management
+Interface (SCMI). SCMI can be used for sensors, power state management,
+clock management and performance management among other things.
+
+This section relies on definitions from the \hyperref[intro:SCMI]{SCMI
+specification}.
+
+Virtio SCMI device and driver are mapped to SCMI platform and agent
+respectively. The device is visible to a particular SCMI agent. The
+device allows a guest to communicate as an SCMI agent using one or more
+SCMI protocols. The default SCMI protocols are defined in the
+\hyperref[intro:SCMI]{SCMI specification}. Virtio provides a transport
+medium for exchanging SCMI messages between the SCMI agent and platform.
+The virtio SCMI transport allows the queueing of multiple messages and
+responses.
+
+SCMI FastChannels are not supported.
+
+\subsection{Device ID}\label{sec:Device Types / SCMI Device / Device ID}
+
+32
+
+\subsection{Virtqueues}\label{sec:Device Types / SCMI Device / Virtqueues}
+
+\begin{description}
+\item[0] cmdq
+\item[1] eventq
+\end{description}
+
+The cmdq is used by the driver to send commands to the device. The
+device replies with responses (not delayed responses) over the cmdq.
+
+The eventq is used by the device to send notifications and delayed
+responses. The eventq only exists if VIRTIO_SCMI_F_P2A_CHANNELS was
+negotiated.
+
+\subsection{Feature bits}\label{sec:Device Types / SCMI Device / Feature bits}
+
+\begin{description}
+\item[VIRTIO_SCMI_F_P2A_CHANNELS (0)] Device implements some SCMI
+notifications, or delayed responses.
+\item[VIRTIO_SCMI_F_SHARED_MEMORY (1)] Device implements any SCMI
+statistics shared memory region.
+\end{description}
+
+VIRTIO_SCMI_F_P2A_CHANNELS is used to determine the existence of the
+eventq. The eventq is required for SCMI notifications and delayed
+responses.
+
+VIRTIO_SCMI_F_SHARED_MEMORY is used to determine whether the device
+provides any SCMI statistics shared memory region. SCMI statistics
+shared memory regions are defined by some SCMI protocols.
+
+The SCMI protocols provide the PROTOCOL_MESSAGE_ATTRIBUTES commands to
+inquire about the particular SCMI notifications and delayed responses
+implemented by the device. The SCMI protocols provide additional
+commands to detect other features implemented by the device.
+
+\devicenormative{\subsubsection}{Feature bits}{Device Types / SCMI Device / Feature bits}
+
+The device MUST offer VIRTIO_SCMI_F_P2A_CHANNELS if the device can
+implement at least one SCMI notification, or delayed response.
+
+The device MUST offer VIRTIO_SCMI_F_SHARED_MEMORY if the device can
+implement at least one SCMI statistics shared memory region.
+
+\subsection{Device configuration layout}\label{sec:Device Types / SCMI Device / Device configuration layout}
+
+There is no configuration data for the device.
+
+\subsection{Device Initialization}\label{sec:Device Types / SCMI Device / Device Initialization}
+
+The
+\hyperref[sec:General Initialization And Device Operation / Device Initialization]{general
+requirements on device initialization} apply.
+
+\subsection{Device Operation}\label{sec:Device Types / SCMI Device / Device Operation}
+
+The SCMI transport used for the device puts each SCMI message into a
+dedicated virtio buffer. The driver uses the cmdq for transmitting SCMI
+commands and receiving the corresponding SCMI responses. The device uses
+the eventq for transmitting SCMI notifications and delayed responses.
+Each message includes an SCMI protocol header and payload, as defined by
+the \hyperref[intro:SCMI]{SCMI specification}.
+
+\subsubsection{cmdq Operation}\label{sec:Device Types / SCMI Device / Device Operation / cmdq Operation}
+
+Each buffer in the cmdq holds a single SCMI command once the buffer has
+been made available. When the buffer has been marked as used, it
+contains the SCMI response. An arbitrary number of such SCMI messages
+can be in transit at the same time. Conceptually, each SCMI message in
+the cmdq uses its own SCMI A2P (agent to platform) channel.
+
+The SCMI response is in the same virtio buffer as the corresponding SCMI
+command. The response contains the return values which SCMI specifies
+for each command, whether synchronous or asynchronous. Delayed responses
+are distinct SCMI messages transmitted over the eventq.
+
+Buffers in the cmdq contain both the request and the response. A request
+has the following layout:
+
+\begin{lstlisting}
+struct virtio_scmi_request {
+ le32 hdr;
+ u8 params[<actual parameters size>];
+};
+\end{lstlisting}
+
+The virtio_scmi_request fields are interpreted as follows:
+
+\begin{description}
+\item[\field{hdr}] (device-readable) contains the SCMI message header
+\item[\field{params}] (device-readable) comprises the SCMI message
+parameters
+\end{description}
+
+A cmdq response has the following layout:
+
+\begin{lstlisting}
+struct virtio_scmi_response {
+ le32 hdr;
+ u8 ret_values[<actual return values size>];
+};
+\end{lstlisting}
+
+The virtio_scmi_response fields are interpreted as follows:
+
+\begin{description}
+\item[\field{hdr}] (device-writable) contains the SCMI message header
+\item[\field{ret_values}] (device-writable) comprises the SCMI message
+return values
+\end{description}
+
+If VIRTIO_SCMI_F_P2A_CHANNELS was not negotiated, the device responds to
+SCMI commands as if no SCMI notifications or delayed responses were
+implemented.
+
+\devicenormative{\paragraph}{cmdq Operation}{Device Types / SCMI Device / Device Operation / cmdq Operation}
+
+The device MAY process available commands out of order and in parallel.
+
+The device MUST process all available commands eventually, even in the
+case of bursts of multiple command messages.
+
+If the \field{status} field in the \field{virtio_scmi_response}
+\field{ret_values} has a value other than SUCCESS, the device MUST set
+the size of \field{ret_values} to the size of the \field{status} field.
+
+If the driver requests an SCMI notification or a delayed response and
+there are currently NOT enough available buffers in the eventq, the
+device SHOULD still return SCMI status code SUCCESS.
+
+If VIRTIO_SCMI_F_P2A_CHANNELS was not negotiated, the device MUST deny
+any request for an SCMI notification or a delayed response by returning
+SCMI status code NOT_SUPPORTED.
+
+If VIRTIO_SCMI_F_P2A_CHANNELS was not negotiated, the device MUST NOT
+indicate in the PROTOCOL_MESSAGE_ATTRIBUTES return values that any SCMI
+notification, or delayed response, is implemented.
+
+\drivernormative{\paragraph}{cmdq Operation}{Device Types / SCMI Device / Device Operation / cmdq Operation}
+
+Before sending a command, the driver MUST wait for responses to all
+commands whose completion the driver considers prerequisites to
+executing the command.
+
+With every command message, the driver MUST provide enough
+device-writable memory to enable the device to return corresponding
+return values.
+
+If VIRTIO_SCMI_F_P2A_CHANNELS was not negotiated, the driver MUST NOT
+request any SCMI notification, nor any delayed response.
+
+\subsubsection{Setting Up eventq Buffers}
+
+The driver has to populate the eventq before the device can use it.
+
+\drivernormative{\paragraph}{Setting Up eventq Buffers}{Device Types / SCMI Device / Device Operation / Setting Up eventq Buffers}
+
+If VIRTIO_SCMI_F_P2A_CHANNELS was negotiated, the driver SHOULD populate
+the eventq with buffers.
+
+The driver MUST NOT put device-readable descriptors into the eventq.
+
+The driver MUST NOT put into the eventq any buffer which is smaller than
+the largest SCMI P2A (platform to agent) message which the driver will
+request.
+
+\subsubsection{eventq Operation}
+
+Each buffer in the eventq holds (once the buffer is marked as used)
+either a single SCMI notification, or a single SCMI delayed response. An
+arbitrary number of such SCMI messages can be in transit at the same
+time. Conceptually, each SCMI message transmitted over the eventq uses
+its own SCMI P2A (platform to agent) channel. Buffers in the eventq have
+the following layout:
+
+\begin{lstlisting}
+struct virtio_scmi_event_msg {
+ /* start of device-writable data */
+ le32 hdr;
+ u8 payload[<actual payload size>];
+};
+\end{lstlisting}
+
+\begin{description}
+\item[\field{hdr}] (device-writable) contains the SCMI message header
+\item[\field{payload}] (device-writable) comprises the SCMI message
+payload
+\end{description}
+
+\devicenormative{\paragraph}{eventq Operation}{Device Types / SCMI Device / Device Operation / eventq Operation}
+
+If the device intends to send a notification and there are no available
+buffers in the eventq, the device MAY drop the notification, or send a
+corresponding notification later, once enough buffers become available.
+
+The device MAY send the notification later if the events which cause the
+notification take place in quick succession.
+
+If the device sends the notification later, the device MAY send the
+notification with updated data, unless the specific SCMI protocol
+disallows this.
+
+If the device intends to send a notification and there are available
+buffers, but one of the buffers is too small to fit the notification,
+the device MAY omit the notification.
+
+If the device intends to send a delayed response and there are no
+available buffers in the eventq, the device MUST send the corresponding
+delayed response once enough buffers become available.
+
+If the \field{status} field in a delayed response \field{payload} has a
+value other than SUCCESS, the device MUST set the size of
+\field{payload} to the size of the \field{status} field.
+
+\subsubsection{Shared Memory Operation}
+
+Various SCMI protocols define statistics shared memory regions (for
+statistics and sensor values).
+
+\devicenormative{\paragraph}{Shared Memory Operation}{Device Types / SCMI Device / Device Operation / Shared Memory Operation}
+
+If VIRTIO_SCMI_F_SHARED_MEMORY was negotiated, the device MAY implement
+an SCMI statistics shared memory region using a virtio shared memory
+region.
+
+If the device implements a shared memory region, the device MUST assign
+the corresponding shmid as per the following table:
+
+\begin{tabular}{|l|l|}
+\hline
+SCMI statistics shared memory region & Virtio shmid \\
+\hline \hline
+Reserved (invalid) & 0 \\
+\hline
+Power state statistics shared memory region & 1 \\
+\hline
+Performance domain statistics shared memory region & 2 \\
+\hline
+Sensor Values Shared Memory & 3 \\
+\hline
+Reserved for future use & 4 to 0x7F \\
+\hline
+Vendor-specific statistics shared memory regions & 0x80 to 0xFF \\
+\hline
+Reserved for future use & 0x100 and greater \\
+\hline
+\end{tabular}
base-commit: 089bc5911dea953aa80c71d17caefa2fc9cc745b
--
2.20.1
_______________________________________________
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 v3 040/105] drm/vc4: crtc: Turn pixelvalve reset into a function
From: Eric Anholt @ 2020-05-27 17:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, DRI Development,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <2c6a651cac6359cb0244a40d3b7a14e72918f169.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> The driver resets the pixelvalve FIFO in a number of occurences without
> always using the same sequence.
>
> Since this will be critical for BCM2711, let's move that sequence to a
> function so that we are consistent.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Patch 34-40 also r-b.
Going to take a little break, this is a lot to try to process at once.
Hopefully you can merge reviewed stuff to drm-misc and shorten the
series.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] iommu/arm-smmu: Add module parameter to set msi iova address
From: Robin Murphy @ 2020-05-27 17:30 UTC (permalink / raw)
To: Srinath Mannam, Will Deacon, Joerg Roedel
Cc: Jean-Philippe Brucker, iommu, linux-kernel, Eric Auger,
Alex Williamson, bcm-kernel-feedback-list, linux-arm-kernel
In-Reply-To: <1590595398-4217-1-git-send-email-srinath.mannam@broadcom.com>
On 2020-05-27 17:03, Srinath Mannam wrote:
> This patch gives the provision to change default value of MSI IOVA base
> to platform's suitable IOVA using module parameter. The present
> hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
That in itself doesn't seem entirely unreasonable; IIRC the current
address is just an arbitrary choice to fit nicely into Qemu's memory
map, and there was always the possibility that it wouldn't suit everything.
> Since commit aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe inaccessible
> DMA address"), inaccessible IOVA address ranges parsed from dma-ranges
> property are reserved.
That, however, doesn't seem to fit here; iommu-dma maps MSI doorbells
dynamically, so they aren't affected by reserved regions any more than
regular DMA pages are. In fact, it explicitly ignores the software MSI
region, since as the comment says, it *is* the software that manages those.
The MSI_IOVA_BASE region exists for VFIO, precisely because in that case
the kernel *doesn't* control the address space, but still needs some way
to steal a bit of it for MSIs that the guest doesn't necessarily know
about, and give userspace a fighting chance of knowing what it's taken.
I think at the time we discussed the idea of adding something to the
VFIO uapi such that userspace could move this around if it wanted or
needed to, but decided we could live without that initially. Perhaps now
the time has come?
Robin.
> If any platform has the limitaion to access default MSI IOVA, then it can
> be changed using "arm-smmu.msi_iova_base=0xa0000000" command line argument.
>
> Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
> ---
> drivers/iommu/arm-smmu.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 4f1a350..5e59c9d 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -72,6 +72,9 @@ static bool disable_bypass =
> module_param(disable_bypass, bool, S_IRUGO);
> MODULE_PARM_DESC(disable_bypass,
> "Disable bypass streams such that incoming transactions from devices that are not attached to an iommu domain will report an abort back to the device and will not be allowed to pass through the SMMU.");
> +static unsigned long msi_iova_base = MSI_IOVA_BASE;
> +module_param(msi_iova_base, ulong, S_IRUGO);
> +MODULE_PARM_DESC(msi_iova_base, "msi iova base address.");
>
> struct arm_smmu_s2cr {
> struct iommu_group *group;
> @@ -1566,7 +1569,7 @@ static void arm_smmu_get_resv_regions(struct device *dev,
> struct iommu_resv_region *region;
> int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
>
> - region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
> + region = iommu_alloc_resv_region(msi_iova_base, MSI_IOVA_LENGTH,
> prot, IOMMU_RESV_SW_MSI);
> if (!region)
> return;
>
_______________________________________________
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 6/6] dt-bindings: drm: bridge: adi, adv7511.txt: convert to yaml
From: Rob Herring @ 2020-05-27 17:29 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wei Xu, Laurent Pinchart, Collabora Kernel ML,
Ricardo Cañuelo, Linux ARM
In-Reply-To: <CAMuHMdXinhY13us9rt9h7EvrT_8zhnQg6tmOBtA0nEQ=1G1O7Q@mail.gmail.com>
On Tue, May 26, 2020 at 1:03 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Laurent,
>
> On Tue, May 26, 2020 at 3:44 AM Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > On Mon, May 25, 2020 at 09:43:35AM +0200, Ricardo Cañuelo wrote:
> > > On jue 14-05-2020 18:22:39, Laurent Pinchart wrote:
> > > > > If we want to be more strict and require the definition of all the
> > > > > supplies, there will be many more DTs changes in the series, and I'm not
> > > > > sure I'll be able to do that in a reasonable amount of time. I'm looking
> > > > > at them and it's not always clear which regulators to use or if they are
> > > > > even defined.
> > > >
> > > > We can decouple the two though (I think). The bindings should reflect
> > > > what we consider right, and the dts files could be fixed on top.
> > >
> > > Do you have a suggestion on how to do this? If we decouple the two
> > > tasks most of the work would be searching for DTs to fix and finding a
> > > way to fix each one of them, and unless I do this _before_ the binding
> > > conversion I'll get a lot of dtbs_check errors.
> >
> > Rob should answer this question as it will be his decision, but I've
> > personally never considered non-compliant DT sources to be an obstacle
> > to bindings conversion to YAML. The DT sources should be fixed, but I
> > don't see it as a prerequisite (although it's a good practice).
There's currently no requirement that binding schema don't introduce
warnings in dts files. That should change when/if we get to a warning
free state (probably per platform/family). I don't think we're close
on any platform? (If we are, I'd like to start tracking that). It is
good to pay attention to the warnings you get though as the schema may
not be doing what you expect or the binding really doesn't match
reality.
> I do my best to avoid introducing regressions when the binding conversions
> go upstream.
Meaning you fix the dts files or massage the schema to match? If we
just adjust schema to match, what's the point in this effort? We
should find things wrong or ill defined.
Rob
_______________________________________________
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] arm64: disable -fsanitize=shadow-call-stack for big-endian
From: Nick Desaulniers @ 2020-05-27 17:28 UTC (permalink / raw)
To: Mark Rutland
Cc: Arnd Bergmann, Fangrui Song, Catalin Marinas, LKML,
clang-built-linux, Sami Tolvanen, Will Deacon, Linux ARM,
Kees Cook
In-Reply-To: <20200527152406.GD59947@C02TD0UTHF1T.local>
On Wed, May 27, 2020 at 8:24 AM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Wed, May 27, 2020 at 03:39:46PM +0200, Arnd Bergmann wrote:
> > clang-11 and earlier do not support -fsanitize=shadow-call-stack
> > in combination with -mbig-endian, but the Kconfig check does not
> > pass the endianess flag, so building a big-endian kernel with
> > this fails at build time:
> >
> > clang: error: unsupported option '-fsanitize=shadow-call-stack' for target 'aarch64_be-unknown-linux'
> >
> > Change the Kconfig check to let Kconfig figure this out earlier
> > and prevent the broken configuration. I assume this is a bug
> > in clang that needs to be fixed, but we also have to work
> > around existing releases.
> >
> > Fixes: 5287569a790d ("arm64: Implement Shadow Call Stack")
> > Link: https://bugs.llvm.org/show_bug.cgi?id=46076
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> I suspect this is similar to the patchable-function-entry issue, and
> this is an oversight that we'd rather fix toolchain side.
>
> Nick, Fangrui, thoughts?
Exactly, Fangrui already has a fix: https://reviews.llvm.org/D80647.
Thanks Fangrui!
It seems it's easy in the codebase to check the specific ABI, which
isn't explicitly LE, rather than use a method that checks the ISA
regardless of endianness.
--
Thanks,
~Nick Desaulniers
_______________________________________________
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 033/105] drm/vc4: crtc: Assign output to channel automatically
From: Eric Anholt @ 2020-05-27 17:23 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, DRI Development,
bcm-kernel-feedback-list, Nicolas Saenz Julienne, Phil Elwell,
linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <5186409a2b5d290b78f6b518a2eb8e407bf1e83e.1590594512.git-series.maxime@cerno.tech>
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output
> being connected to a pixelvalve, and some muxing between the FIFOs and
> outputs.
>
> Any output cannot feed from any FIFO though, and they all have a bunch of
> constraints.
>
> In order to support this, let's store the possible FIFOs each output can be
> assigned to in the vc4_crtc_data, and use that information at atomic_check
> time to iterate over all the CRTCs enabled and assign them FIFOs.
>
> The channel assigned is then set in the vc4_crtc_state so that the rest of
> the driver can use it.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 37 +++++----
> drivers/gpu/drm/vc4/vc4_drv.h | 7 +-
> drivers/gpu/drm/vc4/vc4_kms.c | 142 ++++++++++++++++++++++++++++++++--
> drivers/gpu/drm/vc4/vc4_regs.h | 10 ++-
> 4 files changed, 172 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 580b37ad514d..a6c3f2f907bd 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -88,6 +88,7 @@ static bool vc4_crtc_get_scanout_position(struct drm_crtc *crtc,
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct vc4_crtc_state *vc4_crtc_state = to_vc4_crtc_state(crtc->state);
> unsigned int cob_size;
> u32 val;
> int fifo_lines;
> @@ -104,7 +105,7 @@ static bool vc4_crtc_get_scanout_position(struct drm_crtc *crtc,
> * Read vertical scanline which is currently composed for our
> * pixelvalve by the HVS, and also the scaler status.
> */
> - val = HVS_READ(SCALER_DISPSTATX(vc4_crtc->channel));
> + val = HVS_READ(SCALER_DISPSTATX(vc4_crtc_state->assigned_channel));
>
> /* Get optional system timestamp after query. */
> if (etime)
> @@ -124,7 +125,7 @@ static bool vc4_crtc_get_scanout_position(struct drm_crtc *crtc,
> *hpos += mode->crtc_htotal / 2;
> }
>
> - cob_size = vc4_crtc_get_cob_allocation(vc4, vc4_crtc->channel);
> + cob_size = vc4_crtc_get_cob_allocation(vc4, vc4_crtc_state->assigned_channel);
> /* This is the offset we need for translating hvs -> pv scanout pos. */
> fifo_lines = cob_size / mode->crtc_hdisplay;
>
> @@ -211,6 +212,7 @@ vc4_crtc_lut_load(struct drm_crtc *crtc)
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct vc4_crtc_state *vc4_crtc_state = to_vc4_crtc_state(crtc->state);
> u32 i;
>
> /* The LUT memory is laid out with each HVS channel in order,
> @@ -219,7 +221,7 @@ vc4_crtc_lut_load(struct drm_crtc *crtc)
> */
> HVS_WRITE(SCALER_GAMADDR,
> SCALER_GAMADDR_AUTOINC |
> - (vc4_crtc->channel * 3 * crtc->gamma_size));
> + (vc4_crtc_state->assigned_channel * 3 * crtc->gamma_size));
>
> for (i = 0; i < crtc->gamma_size; i++)
> HVS_WRITE(SCALER_GAMDATA, vc4_crtc->lut_r[i]);
> @@ -392,7 +394,7 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> drm_print_regset32(&p, &vc4_crtc->regset);
> }
>
> - if (vc4_crtc->channel == 2) {
> + if (vc4_crtc->data->hvs_output == 2) {
> u32 dispctrl;
> u32 dsp3_mux;
Looks like this hunk is maybe supposed to be in the hvs_output rename patch?
> @@ -419,7 +421,7 @@ static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> if (!vc4_state->feed_txp)
> vc4_crtc_config_pv(crtc);
>
> - HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
> + HVS_WRITE(SCALER_DISPBKGNDX(vc4_state->assigned_channel),
> SCALER_DISPBKGND_AUTOHS |
> SCALER_DISPBKGND_GAMMA |
> (interlace ? SCALER_DISPBKGND_INTERLACE : 0));
> @@ -451,7 +453,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> - u32 chan = vc4_crtc->channel;
> + struct vc4_crtc_state *vc4_crtc_state = to_vc4_crtc_state(old_state);
> + u32 chan = vc4_crtc_state->assigned_channel;
> int ret;
> require_hvs_enabled(dev);
>
> @@ -530,12 +533,12 @@ static void vc4_crtc_update_dlist(struct drm_crtc *crtc)
> crtc->state->event = NULL;
> }
>
> - HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> + HVS_WRITE(SCALER_DISPLISTX(vc4_state->assigned_channel),
> vc4_state->mm.start);
>
> spin_unlock_irqrestore(&dev->event_lock, flags);
> } else {
> - HVS_WRITE(SCALER_DISPLISTX(vc4_crtc->channel),
> + HVS_WRITE(SCALER_DISPLISTX(vc4_state->assigned_channel),
> vc4_state->mm.start);
> }
> }
> @@ -584,7 +587,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> (vc4_state->feed_txp ?
> SCALER5_DISPCTRLX_ONESHOT : 0);
>
> - HVS_WRITE(SCALER_DISPCTRLX(vc4_crtc->channel), dispctrl);
> + HVS_WRITE(SCALER_DISPCTRLX(vc4_state->assigned_channel), dispctrl);
>
> /* When feeding the transposer block the pixelvalve is unneeded and
> * should not be enabled.
> @@ -700,7 +703,6 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
> {
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> - struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> struct drm_plane *plane;
> struct vc4_plane_state *vc4_plane_state;
> @@ -742,8 +744,8 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
> /* This sets a black background color fill, as is the case
> * with other DRM drivers.
> */
> - HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel),
> - HVS_READ(SCALER_DISPBKGNDX(vc4_crtc->channel)) |
> + HVS_WRITE(SCALER_DISPBKGNDX(vc4_state->assigned_channel),
> + HVS_READ(SCALER_DISPBKGNDX(vc4_state->assigned_channel)) |
> SCALER_DISPBKGND_FILL);
>
> /* Only update DISPLIST if the CRTC was already running and is not
> @@ -757,7 +759,7 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
> vc4_crtc_update_dlist(crtc);
>
> if (crtc->state->color_mgmt_changed) {
> - u32 dispbkgndx = HVS_READ(SCALER_DISPBKGNDX(vc4_crtc->channel));
> + u32 dispbkgndx = HVS_READ(SCALER_DISPBKGNDX(vc4_state->assigned_channel));
>
> if (crtc->state->gamma_lut) {
> vc4_crtc_update_gamma_lut(crtc);
> @@ -769,7 +771,7 @@ static void vc4_crtc_atomic_flush(struct drm_crtc *crtc,
> */
> dispbkgndx &= ~SCALER_DISPBKGND_GAMMA;
> }
> - HVS_WRITE(SCALER_DISPBKGNDX(vc4_crtc->channel), dispbkgndx);
> + HVS_WRITE(SCALER_DISPBKGNDX(vc4_state->assigned_channel), dispbkgndx);
> }
>
> if (debug_dump_regs) {
> @@ -800,7 +802,7 @@ static void vc4_crtc_handle_page_flip(struct vc4_crtc *vc4_crtc)
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> - u32 chan = vc4_crtc->channel;
> + u32 chan = vc4_state->assigned_channel;
> unsigned long flags;
>
> spin_lock_irqsave(&dev->event_lock, flags);
> @@ -999,6 +1001,7 @@ static struct drm_crtc_state *vc4_crtc_duplicate_state(struct drm_crtc *crtc)
> old_vc4_state = to_vc4_crtc_state(crtc->state);
> vc4_state->feed_txp = old_vc4_state->feed_txp;
> vc4_state->margins = old_vc4_state->margins;
> + vc4_state->assigned_channel = old_vc4_state->assigned_channel;
>
> __drm_atomic_helper_crtc_duplicate_state(crtc, &vc4_state->base);
> return &vc4_state->base;
> @@ -1060,6 +1063,7 @@ static const struct drm_crtc_helper_funcs vc4_crtc_helper_funcs = {
> };
>
> static const struct vc4_crtc_data bcm2835_pv0_data = {
> + .hvs_available_channels = BIT(0),
> .hvs_output = 0,
> .debugfs_name = "crtc0_regs",
> .pixels_per_clock = 1,
> @@ -1070,6 +1074,7 @@ static const struct vc4_crtc_data bcm2835_pv0_data = {
> };
>
> static const struct vc4_crtc_data bcm2835_pv1_data = {
> + .hvs_available_channels = BIT(2),
> .hvs_output = 2,
> .debugfs_name = "crtc1_regs",
> .pixels_per_clock = 1,
> @@ -1080,6 +1085,7 @@ static const struct vc4_crtc_data bcm2835_pv1_data = {
> };
>
> static const struct vc4_crtc_data bcm2835_pv2_data = {
> + .hvs_available_channels = BIT(1),
> .hvs_output = 1,
> .debugfs_name = "crtc2_regs",
> .pixels_per_clock = 1,
> @@ -1171,7 +1177,6 @@ static int vc4_crtc_bind(struct device *dev, struct device *master, void *data)
> drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
> &vc4_crtc_funcs, NULL);
> drm_crtc_helper_add(crtc, &vc4_crtc_helper_funcs);
> - vc4_crtc->channel = vc4_crtc->data->hvs_output;
> drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
> drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 9d120aae4af9..73156a53822f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -450,6 +450,9 @@ to_vc4_encoder(struct drm_encoder *encoder)
> }
>
> struct vc4_crtc_data {
> + /* Which channels of the HVS can the output source from */
> + unsigned int hvs_available_channels;
Maybe /* Bitmask of channels (FIFOs) of the HVS that the output can
source from */
> /* Which output of the HVS this pixelvalve sources from. */
> int hvs_output;
>
> @@ -469,9 +472,6 @@ struct vc4_crtc {
> /* Timestamp at start of vblank irq - unaffected by lock delays. */
> ktime_t t_vblank;
>
> - /* Which HVS channel we're using for our CRTC. */
> - int channel;
> -
> u8 lut_r[256];
> u8 lut_g[256];
> u8 lut_b[256];
> @@ -493,6 +493,7 @@ struct vc4_crtc_state {
> struct drm_mm_node mm;
> bool feed_txp;
> bool txp_armed;
> + unsigned int assigned_channel;
>
> struct {
> unsigned int left;
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 29b75b60d858..db00625c61dd 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -11,6 +11,8 @@
> * crtc, HDMI encoder).
> */
>
> +#include <linux/bitfield.h>
> +#include <linux/bitops.h>
> #include <linux/clk.h>
>
> #include <drm/drm_atomic.h>
> @@ -146,6 +148,72 @@ vc4_ctm_commit(struct vc4_dev *vc4, struct drm_atomic_state *state)
> VC4_SET_FIELD(ctm_state->fifo, SCALER_OLEDOFFS_DISPFIFO));
> }
>
> +static void vc4_hvs_pv_muxing_commit(struct vc4_dev *vc4,
> + struct drm_atomic_state *state)
> +{
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + unsigned char dsp2_mux = 0;
> + unsigned char dsp3_mux = 3;
> + unsigned char dsp4_mux = 3;
> + unsigned char dsp5_mux = 3;
> + unsigned int i;
> + u32 reg;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc_state);
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +
> + if (!crtc_state->active)
> + continue;
> +
> + switch (vc4_crtc->data->hvs_output) {
> + case 2:
> + dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
> + break;
> +
> + case 3:
> + dsp3_mux = vc4_state->assigned_channel;
> + break;
> +
> + case 4:
> + dsp4_mux = vc4_state->assigned_channel;
> + break;
> +
> + case 5:
> + dsp5_mux = vc4_state->assigned_channel;
> + break;
> +
> + default:
> + break;
> + }
> + }
> +
> + reg = HVS_READ(SCALER_DISPECTRL);
> + if (FIELD_GET(SCALER_DISPECTRL_DSP2_MUX_MASK, reg) != dsp2_mux)
> + HVS_WRITE(SCALER_DISPECTRL,
> + (reg & ~SCALER_DISPECTRL_DSP2_MUX_MASK) |
> + VC4_SET_FIELD(dsp2_mux, SCALER_DISPECTRL_DSP2_MUX));
> +
> + reg = HVS_READ(SCALER_DISPCTRL);
> + if (FIELD_GET(SCALER_DISPCTRL_DSP3_MUX_MASK, reg) != dsp3_mux)
> + HVS_WRITE(SCALER_DISPCTRL,
> + (reg & ~SCALER_DISPCTRL_DSP3_MUX_MASK) |
> + VC4_SET_FIELD(dsp3_mux, SCALER_DISPCTRL_DSP3_MUX));
> +
> + reg = HVS_READ(SCALER_DISPEOLN);
> + if (FIELD_GET(SCALER_DISPEOLN_DSP4_MUX_MASK, reg) != dsp4_mux)
> + HVS_WRITE(SCALER_DISPEOLN,
> + (reg & ~SCALER_DISPEOLN_DSP4_MUX_MASK) |
> + VC4_SET_FIELD(dsp4_mux, SCALER_DISPEOLN_DSP4_MUX));
> +
> + reg = HVS_READ(SCALER_DISPDITHER);
> + if (FIELD_GET(SCALER_DISPDITHER_DSP5_MUX_MASK, reg) != dsp5_mux)
> + HVS_WRITE(SCALER_DISPDITHER,
> + (reg & ~SCALER_DISPDITHER_DSP5_MUX_MASK) |
> + VC4_SET_FIELD(dsp5_mux, SCALER_DISPDITHER_DSP5_MUX));
Looks like you're writing vc5 bitfields on vc4 where those fields are
marked "write zero".
I don't see why you're going to this extra effort to avoid the reg
writes for no change -- you've already done a read, which is the
expensive part.
> +}
> +
> static void
> vc4_atomic_complete_commit(struct drm_atomic_state *state)
> {
> @@ -156,11 +224,15 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
> int i;
>
> for (i = 0; i < dev->mode_config.num_crtc; i++) {
> - if (!state->crtcs[i].ptr || !state->crtcs[i].commit)
> + struct __drm_crtcs_state *_state = &state->crtcs[i];
> + struct vc4_crtc_state *vc4_crtc_state;
> +
> + if (!_state->ptr || !_state->commit)
> continue;
>
> - vc4_crtc = to_vc4_crtc(state->crtcs[i].ptr);
> - vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
> + vc4_crtc = to_vc4_crtc(_state->ptr);
> + vc4_crtc_state = to_vc4_crtc_state(_state->state);
> + vc4_hvs_mask_underrun(dev, vc4_crtc_state->assigned_channel);
> }
Looks like this loop could really stand to be for_each_new_crtc_in_state()
> clk_set_rate(hvs->core_clk, 500000000);
> @@ -172,6 +244,7 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
> drm_atomic_helper_commit_modeset_disables(dev, state);
>
> vc4_ctm_commit(vc4, state);
> + vc4_hvs_pv_muxing_commit(vc4, state);
>
> drm_atomic_helper_commit_planes(dev, state, 0);
>
> @@ -381,8 +454,11 @@ vc4_ctm_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
>
> /* CTM is being enabled or the matrix changed. */
> if (new_crtc_state->ctm) {
> + struct vc4_crtc_state *vc4_crtc_state =
> + to_vc4_crtc_state(new_crtc_state);
> +
> /* fifo is 1-based since 0 disables CTM. */
> - int fifo = to_vc4_crtc(crtc)->channel + 1;
> + int fifo = vc4_crtc_state->assigned_channel + 1;
>
> /* Check userland isn't trying to turn on CTM for more
> * than one CRTC at a time.
> @@ -495,10 +571,66 @@ static const struct drm_private_state_funcs vc4_load_tracker_state_funcs = {
> .atomic_destroy_state = vc4_load_tracker_destroy_state,
> };
>
> +#define NUM_OUTPUTS 6
> +#define NUM_CHANNELS 3
> +
> static int
> vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> {
> - int ret;
> + unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i, ret;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + struct vc4_crtc_state *vc4_crtc_state =
> + to_vc4_crtc_state(crtc_state);
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + bool is_assigned = false;
> + unsigned int channel;
> +
> + if (!crtc_state->active)
> + continue;
> +
> + /*
> + * The problem we have to solve here is that we have
> + * up to 7 encoders, connected to up to 6 CRTCs.
> + *
> + * Those CRTCs, depending on the instance, can be
> + * routed to 1, 2 or 3 HVS FIFOs, and we need to set
> + * the change the muxing between FIFOs and outputs in
> + * the HVS accordingly.
> + *
> + * It would be pretty hard to come up with an
> + * algorithm that would generically solve
> + * this. However, the current routing trees we support
> + * allow us to simplify a bit the problem.
> + *
> + * Indeed, with the current supported layouts, if we
> + * try to assign in the ascending crtc index order the
> + * FIFOs, we can't fall into the situation where an
> + * earlier CRTC that had multiple routes is assigned
> + * one that was the only option for a later CRTC.
> + *
> + * If the layout changes and doesn't give us that in
> + * the future, we will need to have something smarter,
> + * but it works so far.
> + */
> + for_each_set_bit(channel, &unassigned_channels,
> + sizeof(unassigned_channels)) {
> +
> + if (!(BIT(channel) & vc4_crtc->data->hvs_available_channels))
> + continue;
> +
> + vc4_crtc_state->assigned_channel = channel;
> + unassigned_channels &= ~BIT(channel);
> + is_assigned = true;
> + break;
> + }
> +
> + if (!is_assigned)
> + return -EINVAL;
I think this logic is just
int matching_channels = unassigned_channels &
vc4_crtc->data->hvs_available_channels;
if (matching_channels) {
vc4_crtc_state->assigned_channel = ffs(matching_channels) - 1;
unassigned_channels &= ~BIT(channel);
} else {
return -EINVAL;
}
If you're changing the assignment of a channel, I think you're going
to need to set state->mode_changed or something to trigger a full
modeset, so we don't try to just rewrite the channel of an existing
CRTC while scanning out.
_______________________________________________
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 v14 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
From: Rob Herring @ 2020-05-27 17:14 UTC (permalink / raw)
To: Vishal Sagar
Cc: mark.rutland, devicetree, Jacopo Mondi, mchehab, Hyun Kwon,
Sandip Kothari, linux-kernel, robh+dt, Michal Simek,
laurent.pinchart, Luca Ceresoli, hans.verkuil, Dinesh Kumar,
linux-arm-kernel, linux-media
In-Reply-To: <1590587839-129558-2-git-send-email-vishal.sagar@xilinx.com>
On Wed, 27 May 2020 19:27:18 +0530, Vishal Sagar wrote:
> Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
>
> The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx controller, a
> D-PHY in Rx mode and a Video Format Bridge.
>
> Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> v14
> - Removed xlnx,csi-pxl-format from required properties
> - Added dependency of xlnx,csi-pxl-format on xlnx,vfb
> - End the yaml file with ...
> - Added Reviewed by Laurent
>
> v13
> - Based on Laurent's suggestions
> - Fixed the datatypes values as minimum and maximum
> - condition added for en-vcx property
>
> v12
> - Moved to yaml format
> - Update CSI-2 and D-PHY
> - Mention that bindings for D-PHY not here
> - reset -> video-reset
>
> v11
> - Modify compatible string from 4.0 to 5.0
>
> v10
> - No changes
>
> v9
> - Fix xlnx,vfb description.
> - s/Optional/Required endpoint property.
> - Move data-lanes description from Ports to endpoint property section.
>
> v8
> - Added reset-gpios optional property to assert video_aresetn
>
> v7
> - Removed the control name from dt bindings
> - Updated the example dt node name to csi2rx
>
> v6
> - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as suggested by Luca
> - Added reviewed by Rob Herring
>
> v5
> - Incorporated comments by Luca Cersoli
> - Removed DPHY clock from description and example
> - Removed bayer pattern from device tree MIPI CSI IP
> doesn't deal with bayer pattern.
>
> v4
> - Added reviewed by Hyun Kwon
>
> v3
> - removed interrupt parent as suggested by Rob
> - removed dphy clock
> - moved vfb to optional properties
> - Added required and optional port properties section
> - Added endpoint property section
>
> v2
> - updated the compatible string to latest version supported
> - removed DPHY related parameters
> - added CSI v2.0 related property (including VCX for supporting upto 16
> virtual channels).
> - modified csi-pxl-format from string to unsigned int type where the value
> is as per the CSI specification
> - Defined port 0 and port 1 as sink and source ports.
> - Removed max-lanes property as suggested by Rob and Sakari
>
> .../bindings/media/xilinx/xlnx,csi2rxss.yaml | 237 +++++++++++++++++++++
> 1 file changed, 237 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:0:if: None is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:1:if: None is not of type 'object', 'boolean'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:0: 'required' is not one of ['$ref', 'if', 'then', 'else']
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: allOf:1: 'not' is not one of ['$ref', 'if', 'then', 'else']
Documentation/devicetree/bindings/Makefile:12: recipe for target 'Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.example.dts' failed
make[1]: *** [Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.example.dts] Error 1
make[1]: *** Waiting for unfinished jobs....
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: ignoring, error in schema: allOf: 0: if
warning: no schema found in file: ./Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml: ignoring, error in schema: allOf: 0: if
warning: no schema found in file: ./Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
Makefile:1300: recipe for target 'dt_binding_check' failed
make: *** [dt_binding_check] Error 2
See https://patchwork.ozlabs.org/patch/1298945
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
_______________________________________________
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] irqchip/irq-mtk-sysirq: drop unnecessary spinlock
From: Bartosz Golaszewski @ 2020-05-27 17:06 UTC (permalink / raw)
To: Marc Zyngier
Cc: Jason Cooper, Stephane Le Provost, Pedro Tsai,
Bartosz Golaszewski, LKML, Fabien Parent, linux-mediatek,
Andrew Perepech, Matthias Brugger, Thomas Gleixner, arm-soc
In-Reply-To: <58fca7418c8d18392562aaad2c3a6634@kernel.org>
śr., 27 maj 2020 o 18:38 Marc Zyngier <maz@kernel.org> napisał(a):
>
> Sight... Do you realize that these two locks do not protect the same
> thing at all? One protects the interrupt data, and the other protects
> the MMIO register which is shared between multiple interrupts, and
> on which the driver performs a RMW.
>
> Thanks to the removal of this spinlock, two irq_set_type() can execute
> in parallel and silently corrupt the register. Not exactly an
> improvement.
>
Eek I missed the fact that the internal lock is tied to the chip, not
the interrupt. In that case I'll convert this spinlock to a raw one.
Bart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox