* Re: [PATCH v3 12/25] media: i2c: imx258: Allow configuration of clock lane behaviour
From: Luigi311 @ 2024-04-04 22:29 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel, phone-devel
In-Reply-To: <Zg2kcI/1Gdgt0ilB@duo.ucw.cz>
On 4/3/24 12:48, Pavel Machek wrote:
> Hi!
>
>> The sensor supports the clock lane either remaining in HS mode
>> during frame blanking, or dropping to LP11.
>>
>> Add configuration of the mode via V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK.
>
>> + ret = imx258_write_reg(imx258, IMX258_CLK_BLANK_STOP,
>> + IMX258_REG_VALUE_08BIT,
>> + imx258->csi2_flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK ?
>> + 1 : 0);
>
> !! can be used to turn value into 1/0. I find it easier to read than ?
> 1 : 0 combination, but possibly that's fine, too.
>
> Best regards,
> Pavel
>
I assume you mean by using
!!(imx258->csi2_flags & V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK)
I can go ahead and use that instead
_______________________________________________
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 00/12] mm/gup: Unify hugetlb, part 2
From: Peter Xu @ 2024-04-04 21:48 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Andrew Morton, Muchun Song, Christoph Hellwig, linux-riscv,
James Houghton, David Hildenbrand, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240326140252.GH6245@nvidia.com>
On Tue, Mar 26, 2024 at 11:02:52AM -0300, Jason Gunthorpe wrote:
> The more I look at this the more I think we need to get to Matthew's
> idea of having some kind of generic page table API that is not tightly
> tied to level. Replacing the hugetlb trick of 'everything is a PTE'
> with 5 special cases in every place seems just horrible.
>
> struct mm_walk_ops {
> int (*leaf_entry)(struct mm_walk_state *state, struct mm_walk *walk);
> }
>
> And many cases really want something like:
> struct mm_walk_state state;
>
> if (!mm_walk_seek_leaf(state, mm, address))
> goto no_present
> if (mm_walk_is_write(state)) ..
>
> And detailed walking:
> for_each_pt_leaf(state, mm, address) {
> if (mm_walk_is_write(state)) ..
> }
>
> Replacing it with a mm_walk_state that retains the level or otherwise
> to allow decoding any entry composes a lot better. Forced Loop
> unrolling can get back to the current code gen in alot of places.
>
> It also makes the power stuff a bit nicer as the mm_walk_state could
> automatically retain back pointers to the higher levels in the state
> struct too...
>
> The puzzle is how to do it and still get reasonable efficient codegen,
> many operations are going to end up switching on some state->level to
> know how to decode the entry.
These discussions are definitely constructive, thanks Jason. Very helpful.
I thought about this last week but got interrupted. It does make sense to
me; it looks pretty generic and it is flexible enough as a top design. At
least that's what I thought.
However now when I rethink about it, and look more into the code when I got
the chance, it turns out this will be a major rewrite of mostly every
walkers.. it doesn't mean that this is a bad idea, but then I'll need to
compare the other approach, because there can be a huge difference on when
we can get that code ready, I think. :)
Consider that what we (or.. I) want to teach the pXd layers are two things
right now: (1) hugetlb mappings (2) MMIO (PFN) mappings. That mostly
shares the generic concept when working on the mm walkers no matter which
way to go, just different treatment on different type of mem. (2) is on
top of current code and new stuff, while (1) is a refactoring to drop
hugetlb_entry() hook point as the goal.
Taking a simplest mm walker (smaps) as example, I think most codes are
ready thanks to THP's existance, and also like vm_normal_page[_pmd]() which
should even already work for pfnmaps; pud layer is missing but that should
be trivial. It means we may have chance to drop hugetlb_entry() without an
huge overhaul yet.
Now the important question I'm asking myself is: do we really need huge p4d
or even bigger? It's 512GB on x86, and we said "No 512 GiB pages yet"
(commit fe1e8c3e963) since 2017 - that is 7 years without chaning this
fact. While on non-x86 p4d_leaf() never defined. Then it's also
interesting to see how many codes are "ready" to handle p4d entries (by
looking at p4d_leaf() calls; much easier to see with the removal of the
rest huge apis..) even if none existed.
So, can we over-engineer too much if we go the generic route now?
Considering that we already have most of pmd/pud entries around in the mm
walker ops. So far it sounds better we leave it for later, until further
justifed to be useful. And that won't block it if it ever justified to be
needed, I'd say it can also be seen as a step forward if I can make it to
remove hugetlb_entry() first.
Comments welcomed (before I start to work on anything..).
Thanks,
--
Peter Xu
_______________________________________________
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] KVM: arm64: Limit stage2_apply_range() batch size to smallest block
From: Krister Johansen @ 2024-04-04 21:41 UTC (permalink / raw)
To: Ali Saidi
Cc: catalin.marinas, james.morse, kvmarm, linux-arm-kernel,
linux-kernel, maz, me, oliver.upton, suzuki.poulose, will,
yuzenghui
In-Reply-To: <20240404212742.11248-1-alisaidi@amazon.com>
On Thu, Apr 04, 2024 at 09:27:42PM +0000, Ali Saidi wrote:
> > Just a quick followup that I did test Will's patches and didn't find
> > that it changed the performance of the workload that I'd been testing.
> > IOW, I wasn't able to discern a network performance difference between
> > the baseline and those changes.
>
> That is a bit unexpected that the performance wasn't worse with the patch Will
> sent because it should have disabled the range invalidates since they these
> invalidates will be getting rid of blocks? Which Graviton were you testing
> this on?
Sorry I didn't mention it earlier. This was on a Graviton 4 with
FEAT_TLBIRANGE. Due to the placement of the test machine and the client
the max single flow rate was 5Gbps, and with both the baseline and
Will's patches I wasn't able to discern any slowdown there, at least in
terms of impact to the adjacent networking traffic. I saw an approx 1%
slowdown with multiple flows at 10Gbps, but didn't have a baseline for
that test case so was hesitant to offer it as conclusive. I should be
clear that I _wasn't_ measuring the the teardown times in this test
-- just how the teardown itself impacted the networking performance.
-K
_______________________________________________
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] KVM: arm64: Limit stage2_apply_range() batch size to smallest block
From: Ali Saidi @ 2024-04-04 21:27 UTC (permalink / raw)
To: kjlx
Cc: alisaidi, catalin.marinas, james.morse, kvmarm, linux-arm-kernel,
linux-kernel, maz, me, oliver.upton, suzuki.poulose, will,
yuzenghui
In-Reply-To: <20240404044028.GA1976@templeofstupid.com>
I measured the time it takes to unmap a VM by changing the kvm_page_table_test
to report it. It's and on Graviton3 it's about 300ms per 1GB of flushing
with 4KB pages. Unmapping 128GB takes around 39.5s and with a single call to
__kvm_tlb_flush_vmid() instead of the 32M calls to __kvm_tlb_flush_vmid_ipa()
reduces this to around 5.9s (~7x). This means each iteration of the
stage2_apply_range() is reduced to 46ms. So we're certainly calling
cond_resched() a whole lot more.
> Just a quick followup that I did test Will's patches and didn't find
> that it changed the performance of the workload that I'd been testing.
> IOW, I wasn't able to discern a network performance difference between
> the baseline and those changes.
That is a bit unexpected that the performance wasn't worse with the patch Will
sent because it should have disabled the range invalidates since they these
invalidates will be getting rid of blocks? Which Graviton were you testing
this on?
Ali
_______________________________________________
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 v4 0/8] CFI for ARM32 using LLVM
From: Kees Cook @ 2024-04-04 21:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Sami Tolvanen, Nathan Chancellor, Nick Desaulniers,
Ard Biesheuvel, Arnd Bergmann, linux-arm-kernel, llvm
In-Reply-To: <20240328-arm32-cfi-v4-0-a11046139125@linaro.org>
On Thu, Mar 28, 2024 at 09:19:23AM +0100, Linus Walleij wrote:
> This is a first patch set to support CLANG CFI (Control Flow
> Integrity) on ARM32.
>
> For information about what CFI is, see:
> https://clang.llvm.org/docs/ControlFlowIntegrity.html
>
> For the kernel KCFI flavor, see:
> https://lwn.net/Articles/898040/
>
> The base changes required to bring up KCFI on ARM32 was mostly
> related to the use of custom vtables in the kernel, combined
> with defines to call into these vtable members directly from
> sites where they are used.
>
> We annotate all assembly calls that are called directly from
> C with SYM_TYPED_FUNC_START()/SYM_FUNC_END() so it is easy
> to see while reading the assembly that these functions are
> called from C and can have CFI prototype information prefixed
> to them.
>
> As protype prefix information is just some random bytes, it is
> not possible to "fall through" into an assembly function that
> is tagged with SYM_TYPED_FUNC_START(): there will be some
> binary noise in front of the function so this design pattern
> needs to be explicitly avoided at each site where it occurred.
>
> The approach to binding the calls to C is two-fold:
>
> - Either convert the affected vtable struct to C and provide
> per-CPU prototypes for all the calls (done for TLB, cache)
> or:
>
> - Provide prototypes in a special files just for CFI and tag
> all these functions addressable.
>
> The permissive mode handles the new breakpoint type (0x03) that
> LLVM CLANG is emitting.
>
> To runtime-test the patches:
> - Enable CONFIG_LKDTM
> - echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT
>
> The patch set has been booted to userspace on the following
> test platforms:
>
> - Arm Versatile (QEMU)
> - Arm Versatile Express (QEMU)
> - multi_v7 booted on Versatile Express (QEMU)
> - Footbridge Netwinder (SA110 ARMv4)
> - Ux500 (ARMv7 SMP)
> - Gemini (FA526)
>
> I am not saying there will not be corner cases that we need
> to fix in addition to this, but it is enough to get started.
> Looking at what was fixed for arm64 I am a bit weary that
> e.g. BPF might need something to trampoline properly.
>
> But hopefullt people can get to testing it and help me fix
> remaining issues before the final version, or we can fix it
> in-tree.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For the series:
Tested-by: Kees Cook <keescook@chromium.org>
Thanks for making this work!
--
Kees Cook
_______________________________________________
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 v4 7/8] ARM: hw_breakpoint: Handle CFI breakpoints
From: Kees Cook @ 2024-04-04 21:26 UTC (permalink / raw)
To: Linus Walleij
Cc: Russell King, Sami Tolvanen, Nathan Chancellor, Nick Desaulniers,
Ard Biesheuvel, Arnd Bergmann, linux-arm-kernel, llvm
In-Reply-To: <20240328-arm32-cfi-v4-7-a11046139125@linaro.org>
On Thu, Mar 28, 2024 at 09:19:30AM +0100, Linus Walleij wrote:
> This registers a breakpoint handler for the new breakpoint type
> (0x03) inserted by LLVM CLANG for CFI breakpoints.
>
> If we are in permissive mode, just print a backtrace and continue.
>
> Example with CONFIG_CFI_PERMISSIVE enabled:
>
> > echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT
> lkdtm: Performing direct entry CFI_FORWARD_PROTO
> lkdtm: Calling matched prototype ...
> lkdtm: Calling mismatched prototype ...
> CFI failure at lkdtm_indirect_call+0x40/0x4c (target: 0x0; expected type: 0x00000000)
> WARNING: CPU: 1 PID: 112 at lkdtm_indirect_call+0x40/0x4c
> CPU: 1 PID: 112 Comm: sh Not tainted 6.8.0-rc1+ #150
> Hardware name: ARM-Versatile Express
> (...)
> lkdtm: FAIL: survived mismatched prototype function call!
> lkdtm: Unexpected! This kernel (6.8.0-rc1+ armv7l) was built with CONFIG_CFI_CLANG=y
>
> As you can see the LKDTM test fails, but I expect that this would be
> expected behaviour in the permissive mode.
>
> We are currently not implementing target and type for the CFI
> breakpoint as this requires additional operand bundling compiler
> extensions.
>
> CPUs without breakpoint support cannot handle breakpoints naturally,
> in these cases the permissive mode will not work, CFI will fall over
> on an undefined instruction:
>
> Internal error: Oops - undefined instruction: 0 [#1] PREEMPT ARM
> CPU: 0 PID: 186 Comm: ash Tainted: G W 6.9.0-rc1+ #7
> Hardware name: Gemini (Device Tree)
> PC is at lkdtm_indirect_call+0x38/0x4c
> LR is at lkdtm_CFI_FORWARD_PROTO+0x30/0x6c
>
> This is reasonable I think: it's the best CFI can do to ascertain
> the the control flow is not broken on these CPUs.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Thanks for making this "fail closed". Looks good!
Reviewed-by: Kees Cook <keescook@chromium.org>
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH v2 0/6] arm64: dts: qcom: qcs6490-rb3gen2: Enable two displays
From: Bjorn Andersson @ 2024-04-04 21:23 UTC (permalink / raw)
To: cros-qcom-dts-watchers, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Catalin Marinas, Will Deacon,
Dmitry Baryshkov, Bjorn Andersson
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
Douglas Anderson, Abhinav Kumar, Neil Armstrong,
Krishna Kurapati PSSNV
In-Reply-To: <20240326-rb3gen2-dp-connector-v2-0-a9f1bc32ecaf@quicinc.com>
On Tue, 26 Mar 2024 19:04:17 -0700, Bjorn Andersson wrote:
> RB3Gen2 is capable of producing DisplayPort output on a dedicated
> mini-DP connector and USB Type-C.
>
> Utilize Abel's work for DP vs eDP selection to allow configuring both
> controllers in DP-mode, then enable the two output paths.
>
> Tested by driving fbcon to 4k@60 + 4k@30 concurrently.
>
> [...]
Applied, thanks!
[6/6] arm64: defconfig: Enable sc7280 display and gpu clock controllers
commit: a97b6c42a7b823c429fac562a02d291b47b98d7e
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RESEND PATCH] arm64: defconfig: build ath12k as a module
From: Bjorn Andersson @ 2024-04-04 21:22 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Bjorn Andersson,
Krzysztof Kozlowski, Konrad Dybcio, Arnd Bergmann,
Geert Uytterhoeven, Neil Armstrong, Marek Szyprowski,
Nícolas F . R . A . Prado, Udit Kumar, Andrew Halaney,
Maximilian Luz, Alex Elder, Srini Kandagatla, Bartosz Golaszewski
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm,
Bartosz Golaszewski, Jeff Johnson
In-Reply-To: <20240325085756.13843-1-brgl@bgdev.pl>
On Mon, 25 Mar 2024 09:57:56 +0100, Bartosz Golaszewski wrote:
> Qualcomm sm8550-qrd and sm8650-qrd boards have ath12k modules as part of
> their on-board WCN7850 WLAN/BT packages. Enable the relevant driver in
> defconfig.
>
>
Applied, thanks!
[1/1] arm64: defconfig: build ath12k as a module
commit: 7b3ecb64f9ae7ceb0fe0a0cafc3eb2a91326c054
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
_______________________________________________
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] ath9k: use unmanaged PCI functions in ath9k_pci_owl_loader
From: Heiner Kallweit @ 2024-04-04 21:07 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Kalle Valo, Andreas Färber,
Manivannan Sadhasivam, Martin Blumenstingl
Cc: linux-wireless, linux-arm-kernel@lists.infradead.org,
linux-actions, linux-pci@vger.kernel.org
In-Reply-To: <87y19ukuo3.fsf@toke.dk>
On 03.04.2024 23:23, Toke Høiland-Jørgensen wrote:
> Heiner Kallweit <hkallweit1@gmail.com> writes:
>
>> Using the device-managed versions has no benefit here, because
>> resources are released as part of the asynchronous fw loading.
>>
>> Actual reason why I got here is that I was looking for places with
>> dubious use of pcim_pin_device().
>
> Could you please expand the commit message to explain what this means in
> a bit more detail? That will be helpful to someone who wants to
> understand what the difference between these versions is and why this
> change makes sense, but who is not that familiar with how these internal
> bits are really supposed to work. Someone like myself, in other words :)
>
Sure. I'll add some more context in a v2.
> -Toke
Heiner
_______________________________________________
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] perf: arm_cspmu: Don't touch interrupt registers if no interrupt was assigned
From: Ilkka Koskinen @ 2024-04-04 20:35 UTC (permalink / raw)
To: Ilkka Koskinen
Cc: Besar Wicaksono, Robin Murphy, Suzuki K Poulose, Will Deacon,
Mark Rutland, Raag Jadav, linux-arm-kernel, linux-kernel
In-Reply-To: <20240307193104.58302-1-ilkka@os.amperecomputing.com>
Hi,
Could someone take a look at this patch and give some feedback?
Cheers, Ilkka
On Thu, 7 Mar 2024, Ilkka Koskinen wrote:
> The driver enabled and disabled interrupts even if no interrupt was
> assigned to the device.
>
> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
> ---
> drivers/perf/arm_cspmu/arm_cspmu.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/perf/arm_cspmu/arm_cspmu.c b/drivers/perf/arm_cspmu/arm_cspmu.c
> index 50b89b989ce7..2cbdb5dcb6ff 100644
> --- a/drivers/perf/arm_cspmu/arm_cspmu.c
> +++ b/drivers/perf/arm_cspmu/arm_cspmu.c
> @@ -795,7 +795,8 @@ static void arm_cspmu_enable_counter(struct arm_cspmu *cspmu, int idx)
> inten_off = PMINTENSET + (4 * reg_id);
> cnten_off = PMCNTENSET + (4 * reg_id);
>
> - writel(BIT(reg_bit), cspmu->base0 + inten_off);
> + if (cspmu->irq)
> + writel(BIT(reg_bit), cspmu->base0 + inten_off);
> writel(BIT(reg_bit), cspmu->base0 + cnten_off);
> }
>
> @@ -810,7 +811,8 @@ static void arm_cspmu_disable_counter(struct arm_cspmu *cspmu, int idx)
> cnten_off = PMCNTENCLR + (4 * reg_id);
>
> writel(BIT(reg_bit), cspmu->base0 + cnten_off);
> - writel(BIT(reg_bit), cspmu->base0 + inten_off);
> + if (cspmu->irq)
> + writel(BIT(reg_bit), cspmu->base0 + inten_off);
> }
>
> static void arm_cspmu_event_update(struct perf_event *event)
> --
> 2.40.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 v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: kernel test robot @ 2024-04-04 19:21 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, chunkuang.hu
Cc: oe-kbuild-all, robh, krzysztof.kozlowski+dt, conor+dt, p.zabel,
airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
matthias.bgg, angelogioacchino.delregno, shawn.sung, yu-chang.lee,
ck.hu, jitao.shi, devicetree, linux-kernel, dri-devel,
linux-mediatek, linux-arm-kernel, wenst, kernel
In-Reply-To: <20240404081635.91412-3-angelogioacchino.delregno@collabora.com>
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on robh/for-next pza/reset/next linus/master v6.9-rc2 next-20240404]
[cannot apply to pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/AngeloGioacchino-Del-Regno/dt-bindings-display-mediatek-Add-OF-graph-support-for-board-path/20240404-161930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240404081635.91412-3-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240405/202404050315.7WBDW2E8-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404050315.7WBDW2E8-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties: 'required' should not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
--
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
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] remoteproc: zynqmp: Add coredump support
From: Tanmay Shah @ 2024-04-04 20:14 UTC (permalink / raw)
To: Leonard Crestez, Mathieu Poirier
Cc: Bjorn Andersson, Michal Simek, Sarangdhar Joshi, Siddharth Gupta,
Rishabh Bhatnagar, linux-remoteproc, linux-arm-kernel
In-Reply-To: <d4556268-8274-4089-949f-3b97d67793c7@gmail.com>
Hello,
Thanks for your patch. Patch looks good to me.
Please find some comments below.
On 3/16/24 1:16 PM, Leonard Crestez wrote:
> Supporting remoteproc coredump requires the platform-specific driver to
> register coredump segments to be dumped. Do this by calling
> rproc_coredump_add_segment for every carveout.
>
> Also call rproc_coredump_set_elf_info when then rproc is created. If the
> ELFCLASS parameter is not provided then coredump fails with an error.
> Other drivers seem to pass EM_NONE for the machine argument but for me
> this shows a warning in gdb. Pass EM_ARM because this is an ARM R5.
>
> Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
> ---
>
> Tests were done by triggering an deliberate crash using remoteproc
> debugfs: echo 2 > /sys/kernel/debug/remoteproc/remoteproc0/crash
>
> This was tested using RPU apps which use RAM for everything so TCM dump
> was not verified. The freertos-gdb script package showed credible data:
>
> https://github.com/espressif/freertos-gdb
Thanks for this testing.
>
> The R5 cache is not flushed so RAM might be out of date which is
> actually very bad because information most relevant to determining the
> cause of a crash is lost. Possible workaround would be to flush caches
> in some sort of R5 crash handler? I don't think Linux can do anything
> about this limitation.
>
Correct Linux can't. One workaround is that R5 firmware can mark
required memory regions as non-cachable in MPU setting. This way information
loss can be avoided.
> The generated coredump doesn't contain registers, this seems to be a
> limitation shared with other rproc coredumps. It's not clear how the apu
> could access rpu registers on zynqmp, my only idea would be to use the
> coresight dap but that sounds difficult.
Linux doesn't really have access to R5 control registers due to security.
Instead EEMI calls to platform management controller are used to control R5.
So R5 control register dump shouldn't needed.
Mathieu,
I am okay to merge this patch.
>
> ---
> drivers/remoteproc/xlnx_r5_remoteproc.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 4395edea9a64..cfbd97b89c26 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -484,10 +484,11 @@ static int add_mem_regions_carveout(struct rproc *rproc)
> of_node_put(it.node);
> return -ENOMEM;
> }
>
> rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, rmem->base, rmem->size);
>
> dev_dbg(&rproc->dev, "reserved mem carveout %s addr=%llx, size=0x%llx",
> it.node->name, rmem->base, rmem->size);
> i++;
> }
> @@ -595,10 +596,11 @@ static int add_tcm_carveout_split_mode(struct rproc *rproc)
> zynqmp_pm_release_node(pm_domain_id);
> goto release_tcm_split;
> }
>
> rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, bank_size);
> }
>
> return 0;
>
> release_tcm_split:
> @@ -674,10 +676,11 @@ static int add_tcm_carveout_lockstep_mode(struct rproc *rproc)
> goto release_tcm_lockstep;
> }
>
> /* If registration is success, add carveouts */
> rproc_add_carveout(rproc, rproc_mem);
> + rproc_coredump_add_segment(rproc, da, bank_size);
>
> dev_dbg(dev, "TCM carveout lockstep mode %s addr=0x%llx, da=0x%x, size=0x%lx",
> bank_name, bank_addr, da, bank_size);
> }
>
> @@ -851,10 +854,12 @@ static struct zynqmp_r5_core *zynqmp_r5_add_rproc_core(struct device *cdev)
> if (!r5_rproc) {
> dev_err(cdev, "failed to allocate memory for rproc instance\n");
> return ERR_PTR(-ENOMEM);
> }
>
> + rproc_coredump_set_elf_info(r5_rproc, ELFCLASS32, EM_ARM);
> +
> r5_rproc->auto_boot = false;
> r5_core = r5_rproc->priv;
> r5_core->dev = cdev;
> r5_core->np = dev_of_node(cdev);
> if (!r5_core->np) {
_______________________________________________
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 v9 0/4] PCI: brcmstb: Configure appropriate HW CLKREQ# mode
From: Cyril Brulebois @ 2024-04-04 20:01 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-pci, Nicolas Saenz Julienne, Bjorn Helgaas,
Lorenzo Pieralisi, Phil Elwell, bcm-kernel-feedback-list,
Conor Dooley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Jim Quinlan, Krzysztof Kozlowski,
Krzysztof Wilczyński,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Lorenzo Pieralisi, Rob Herring
In-Reply-To: <20240403213902.26391-1-james.quinlan@broadcom.com>
[-- Attachment #1.1: Type: text/plain, Size: 3351 bytes --]
Hi Jim,
Jim Quinlan <james.quinlan@broadcom.com> (2024-04-03):
> v9 -- v8 was setting an internal bus timeout to accomodate large L1 exit
> latencies. After meeting the PCIe HW team it was revealed that the
> HW default timeout value was set low for the purposes of HW debugging
> convenience; for nominal operation it needs to be set to a higher
> value independent of this submission's purpose. This is now a
> separate commit.
>
> -- With v8, Bjorne asked what was preventing a device from exceeding the
> time required for the above internal bus timeout. The answer to this
> is for us to set the endpoints' max latency {no-,}snoop value to
> something below this internal timeout value. If the endpoint
> respects this value as it should, it will not send an LTR request
> with a larger latency value and not put itself in a situation
> that requires more latency than is possible for the platform.
>
> Typically, ACPI or FW sets these max latency values. In most of our
> systems we do not have this happening so it is up to the RC driver to
> set these values in the endpoint devices. If the endpoints already
> have non-zero values that are lower than what we are setting, we let
> them be, as it is possible ACPI or FW set them and knows something
> that we do not.
>
> -- The "clkreq" commit has only been changed to remove the code that was
> setting the timeout value, as this code is now its own commit.
Given the bot's feedback, I took the liberty of running tests on your
patch series except with an extra “static” keyword. On my build system,
gcc 12 wasn't complaining about it but I didn't spend time trying to
find the right options, or trying a switch to clang to confirm the
before/after situation:
-void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
+static void brcm_set_downstream_devs_ltr_max(struct brcm_pcie *pcie)
Anyway, this is still:
Tested-by: Cyril Brulebois <cyril@debamax.com>
Test setup:
-----------
- using a $CM with the 20230111 EEPROM
- on the same CM4 IO Board
- with a $PCIE board (PCIe to multiple USB ports)
- and the same Samsung USB flash drive + Logitech keyboard.
where $CM is one of:
- CM4 Lite Rev 1.0
- CM4 8/32 Rev 1.0
- CM4 4/32 Rev 1.1
and $PCIE is one of:
- SupaHub PCE6U1C-R02, VER 006
- SupaHub PCE6U1C-R02, VER 006S
- Waveshare VIA VL805/806-based
Results:
--------
1. Given this is already v9, and given I don't see how this could have
possibly changed, I didn't build or tested an unpatched kernel,
which I would still expect to produce either a successful boot
*without* seeing the devices plugged on the PCIe-to-USB board or the
dreaded SError in most cases.
2. With a patched kernel (v6.7-562-g9f8413c4a66f2 + this series +
“static” in front of brcm_set_downstream_devs_ltr_max()), for all
$CM/$PCIE combinations, I'm getting a system that boots, sees the
flash drive, and gives decent read/write performance on it (plus a
functional keyboard).
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] clk: rockchip: clk-rk3568.c: Add missing USB480M_PHY mux
From: Heiko Stuebner @ 2024-04-04 19:43 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sascha Hauer
Cc: linux-clk, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, David Jander, Sascha Hauer
In-Reply-To: <20240404-clk-rockchip-rk3568-add-usb480m-phy-mux-v1-1-e8542afd58b9@pengutronix.de>
Hi Sascha,
Am Donnerstag, 4. April 2024, 09:27:01 CEST schrieb Sascha Hauer:
> From: David Jander <david@protonic.nl>
>
> The USB480M clock can source from a MUX that selects the clock to come
> from either of the USB-phy internal 480MHz PLLs. These clocks are
> provided by the USB phy driver.
>
> Signed-off-by: David Jander <david@protonic.nl>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/clk/rockchip/clk-rk3568.c | 4 ++++
> include/dt-bindings/clock/rk3568-cru.h | 1 +
> 2 files changed, 5 insertions(+)
>
> diff --git a/drivers/clk/rockchip/clk-rk3568.c b/drivers/clk/rockchip/clk-rk3568.c
> index 8cb21d10beca2..2d44bcaef046b 100644
> --- a/drivers/clk/rockchip/clk-rk3568.c
> +++ b/drivers/clk/rockchip/clk-rk3568.c
> @@ -215,6 +215,7 @@ static const struct rockchip_cpuclk_reg_data rk3568_cpuclk_data = {
>
> PNAME(mux_pll_p) = { "xin24m" };
> PNAME(mux_usb480m_p) = { "xin24m", "usb480m_phy", "clk_rtc_32k" };
> +PNAME(mux_usb480m_phy_p) = { "clk_usbphy0_480m", "clk_usbphy1_480m"};
> PNAME(mux_armclk_p) = { "apll", "gpll" };
> PNAME(clk_i2s0_8ch_tx_p) = { "clk_i2s0_8ch_tx_src", "clk_i2s0_8ch_tx_frac", "i2s0_mclkin", "xin_osc0_half" };
> PNAME(clk_i2s0_8ch_rx_p) = { "clk_i2s0_8ch_rx_src", "clk_i2s0_8ch_rx_frac", "i2s0_mclkin", "xin_osc0_half" };
> @@ -485,6 +486,9 @@ static struct rockchip_clk_branch rk3568_clk_branches[] __initdata = {
> MUX(USB480M, "usb480m", mux_usb480m_p, CLK_SET_RATE_PARENT,
> RK3568_MODE_CON0, 14, 2, MFLAGS),
>
> + MUX(USB480M_PHY, "usb480m_phy", mux_usb480m_phy_p, CLK_SET_RATE_PARENT,
> + RK3568_MISC_CON2, 15, 1, MFLAGS),
> +
> /* PD_CORE */
> COMPOSITE(0, "sclk_core_src", apll_gpll_npll_p, CLK_IGNORE_UNUSED,
> RK3568_CLKSEL_CON(2), 8, 2, MFLAGS, 0, 4, DFLAGS | CLK_DIVIDER_READ_ONLY,
> diff --git a/include/dt-bindings/clock/rk3568-cru.h b/include/dt-bindings/clock/rk3568-cru.h
> index d29890865150d..5263085c5b238 100644
> --- a/include/dt-bindings/clock/rk3568-cru.h
> +++ b/include/dt-bindings/clock/rk3568-cru.h
> @@ -78,6 +78,7 @@
> #define CPLL_333M 9
> #define ARMCLK 10
> #define USB480M 11
> +#define USB480M_PHY 12
> #define ACLK_CORE_NIU2BUS 18
> #define CLK_CORE_PVTM 19
> #define CLK_CORE_PVTM_CORE 20
>
Please separate the code change and clock-id addition into separate
patches. That way dt-maintainers will more easily see that there are
changes to the dt-binding inside.
Other than that, the change looks fine :-)
Thanks
Heiko
_______________________________________________
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 v3 1/5] net: create a dummy net_device allocator
From: Breno Leitao @ 2024-04-04 19:03 UTC (permalink / raw)
To: Alexander Lobakin
Cc: kuba, davem, pabeni, edumazet, elder, linux-arm-kernel,
linux-mediatek, nbd, sean.wang, Mark-MC.Lee, lorenzo,
taras.chornyi, quic_jjohnson, kvalo, leon, dennis.dalessandro,
linux-kernel, netdev, bpf, Jiri Pirko, Simon Horman,
Daniel Borkmann, Sebastian Andrzej Siewior
In-Reply-To: <1b1dfe1f-57ed-416d-a9c0-408aafa69583@intel.com>
Hello Alexander,
On Thu, Apr 04, 2024 at 06:40:33PM +0200, Alexander Lobakin wrote:
> > @@ -11063,6 +11070,17 @@ void free_netdev(struct net_device *dev)
> > }
> > EXPORT_SYMBOL(free_netdev);
> >
> > +/**
> > + * alloc_netdev_dummy - Allocate and initialize a dummy net device.
> > + * @sizeof_priv: size of private data to allocate space for
> > + */
> > +struct net_device *alloc_netdev_dummy(int sizeof_priv)
>
> Repeating my question from the previous thread: I see that in your
> series you always pass 0 as @sizeof_priv, does it make sense to have
> this argument or we can just pass 0 here to alloc_netdev() unconditionally?
> Drivers that have &net_device embedded can't have any private data there
> anyway.
Sorry, I answered you this question in the previous thread, and gave you an
example why we need the @sizeof_priv.
https://lore.kernel.org/all/ZgWrcvKyAzDvl%2Fjn@gmail.com/
I didn't see any reply from you, so, I suppose you were OK with it, but
maybe you missed it?!
Anyway, let me paste what I've sent there here, so, we can continue the
discussion in this thread, which might make the reviewing process here.
This is what I wrote in the thread/message above:
We need to have this private size for cases where we need to get the
pointer to their private structure given the dummy device. In the
embedded case you can use container_of(), but, with a pointer to
net_device, that is not the case anymore, and we should use the dummy private
data pointer back to the private data.
For instance, see the example of iwlwifi:
https://lore.kernel.org/all/20240307174843.1719130-1-leitao@debian.org/
_______________________________________________
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 1/7] mm: Add a bitmap into mmu_notifier_{clear,test}_young
From: David Hildenbrand @ 2024-04-04 18:52 UTC (permalink / raw)
To: James Houghton, Andrew Morton, Paolo Bonzini
Cc: Yu Zhao, David Matlack, Marc Zyngier, Oliver Upton,
Sean Christopherson, Jonathan Corbet, James Morse,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Steven Rostedt, Masami Hiramatsu,
Mathieu Desnoyers, Shaoqin Huang, Gavin Shan, Ricardo Koller,
Raghavendra Rao Ananta, Ryan Roberts, David Rientjes,
Axel Rasmussen, linux-kernel, linux-arm-kernel, kvmarm, kvm,
linux-mm, linux-trace-kernel
In-Reply-To: <20240401232946.1837665-2-jthoughton@google.com>
On 02.04.24 01:29, James Houghton wrote:
> The bitmap is provided for secondary MMUs to use if they support it. For
> test_young(), after it returns, the bitmap represents the pages that
> were young in the interval [start, end). For clear_young, it represents
> the pages that we wish the secondary MMU to clear the accessed/young bit
> for.
>
> If a bitmap is not provided, the mmu_notifier_{test,clear}_young() API
> should be unchanged except that if young PTEs are found and the
> architecture supports passing in a bitmap, instead of returning 1,
> MMU_NOTIFIER_YOUNG_FAST is returned.
>
> This allows MGLRU's look-around logic to work faster, resulting in a 4%
> improvement in real workloads[1]. Also introduce MMU_NOTIFIER_YOUNG_FAST
> to indicate to main mm that doing look-around is likely to be
> beneficial.
>
> If the secondary MMU doesn't support the bitmap, it must return
> an int that contains MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE.
>
> [1]: https://lore.kernel.org/all/20230609005935.42390-1-yuzhao@google.com/
>
> Suggested-by: Yu Zhao <yuzhao@google.com>
> Signed-off-by: James Houghton <jthoughton@google.com>
> ---
> include/linux/mmu_notifier.h | 93 +++++++++++++++++++++++++++++++++---
> include/trace/events/kvm.h | 13 +++--
> mm/mmu_notifier.c | 20 +++++---
> virt/kvm/kvm_main.c | 19 ++++++--
> 4 files changed, 123 insertions(+), 22 deletions(-)
>
> diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> index f349e08a9dfe..daaa9db625d3 100644
> --- a/include/linux/mmu_notifier.h
> +++ b/include/linux/mmu_notifier.h
> @@ -61,6 +61,10 @@ enum mmu_notifier_event {
>
> #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
>
> +#define MMU_NOTIFIER_YOUNG (1 << 0)
> +#define MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE (1 << 1)
Especially this one really deserves some documentation :)
> +#define MMU_NOTIFIER_YOUNG_FAST (1 << 2)
And that one as well.
Likely best to briefly document all of them, and how they are
supposed to be used (return value for X).
> +
> struct mmu_notifier_ops {
> /*
> * Called either by mmu_notifier_unregister or when the mm is
> @@ -106,21 +110,36 @@ struct mmu_notifier_ops {
> * clear_young is a lightweight version of clear_flush_young. Like the
> * latter, it is supposed to test-and-clear the young/accessed bitflag
> * in the secondary pte, but it may omit flushing the secondary tlb.
> + *
> + * If @bitmap is given but is not supported, return
> + * MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE.
> + *
> + * If the walk is done "quickly" and there were young PTEs,
> + * MMU_NOTIFIER_YOUNG_FAST is returned.
> */
> int (*clear_young)(struct mmu_notifier *subscription,
> struct mm_struct *mm,
> unsigned long start,
> - unsigned long end);
> + unsigned long end,
> + unsigned long *bitmap);
>
> /*
> * test_young is called to check the young/accessed bitflag in
> * the secondary pte. This is used to know if the page is
> * frequently used without actually clearing the flag or tearing
> * down the secondary mapping on the page.
> + *
> + * If @bitmap is given but is not supported, return
> + * MMU_NOTIFIER_YOUNG_BITMAP_UNRELIABLE.
> + *
> + * If the walk is done "quickly" and there were young PTEs,
> + * MMU_NOTIFIER_YOUNG_FAST is returned.
> */
> int (*test_young)(struct mmu_notifier *subscription,
> struct mm_struct *mm,
> - unsigned long address);
> + unsigned long start,
> + unsigned long end,
> + unsigned long *bitmap);
What does "quickly" mean (why not use "fast")? What are the semantics, I
don't find any existing usage of that in this file.
Further, what is MMU_NOTIFIER_YOUNG you introduce used for?
--
Cheers,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add Audio Codec
From: Garrett Giordano @ 2024-04-04 18:42 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzysztof.kozlowski+dt, conor+dt,
w.egorov
Cc: linux-arm-kernel, devicetree, linux-kernel, upstream
The Audio Codec runs over the MCASP (Multichannel Audio Serial Port).
Add pinmux for the Audio Reference Clock and MCASP2.
Add DT nodes for Audio Codec, MCASP2, VCC 1v8 and VCC 3v3 regulators.
Additionally, create a sound node that connects our sound card and the
MCASP2.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
---
.../dts/ti/k3-am625-phyboard-lyra-rdk.dts | 99 +++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
index a83a90497857..dfc78995d30a 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
@@ -66,6 +66,35 @@ key-menu {
};
};
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "phyBOARD-Lyra";
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC3R", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "External Speaker", "SPOP",
+ "External Speaker", "SPOM";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp2>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&audio_codec>;
+ clocks = <&audio_refclk1>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -82,6 +111,15 @@ led-2 {
};
};
+ vcc_1v8: regulator-vcc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vcc_3v3_mmc: regulator-vcc-3v3-mmc {
compatible = "regulator-fixed";
regulator-name = "VCC_3V3_MMC";
@@ -90,9 +128,24 @@ vcc_3v3_mmc: regulator-vcc-3v3-mmc {
regulator-always-on;
regulator-boot-on;
};
+
+ vcc_3v3_sw: regulator-vcc-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_SW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&main_pmx0 {
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (K25) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+
gpio_keys_pins_default: gpio-keys-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x1d4, PIN_INPUT, 7) /* (B15) UART0_RTSn.GPIO1_23 */
@@ -150,6 +203,15 @@ AM62X_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (C15) MCAN0_TX */
>;
};
+ main_mcasp2_pins_default: main-mcasp2-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x070, PIN_INPUT, 3) /* (T24) GPMC0_AD13.MCASP2_ACLKX */
+ AM62X_IOPAD(0x06c, PIN_INPUT, 3) /* (T22) GPMC0_AD12.MCASP2_AFSX */
+ AM62X_IOPAD(0x064, PIN_OUTPUT, 3) /* (T25) GPMC0_AD10.MCASP2_AXR2 */
+ AM62X_IOPAD(0x068, PIN_INPUT, 3) /* (R21) GPMC0_AD11.MCASP2_AXR3 */
+ >;
+ };
+
main_mmc1_pins_default: main-mmc1-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x23c, PIN_INPUT_PULLUP, 0) /* (A21) MMC1_CMD */
@@ -254,6 +316,21 @@ &main_i2c1 {
clock-frequency = <100000>;
status = "okay";
+ audio_codec: audio-codec@18 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3007";
+ reg = <0x18>;
+ ai3x-micbias-vg = <2>;
+
+ AVDD-supply = <&vcc_3v3_sw>;
+ IOVDD-supply = <&vcc_3v3_sw>;
+ DRVDD-supply = <&vcc_3v3_sw>;
+ DVDD-supply = <&vcc_1v8>;
+ };
+
gpio_exp: gpio-expander@21 {
pinctrl-names = "default";
pinctrl-0 = <&gpio_exp_int_pins_default>;
@@ -329,6 +406,28 @@ &main_uart1 {
status = "okay";
};
+&mcasp2 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp2_pins_default>;
+
+ /* MCASP_IIS_MODE */
+ op-mode = <0>;
+ tdm-slots = <2>;
+
+ /* 0: INACTIVE, 1: TX, 2: RX */
+ serial-dir = <
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+};
+
&sdhci1 {
vmmc-supply = <&vcc_3v3_mmc>;
vqmmc-supply = <&vddshv5_sdio>;
--
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 v9 00/13] firmware: qcom: qseecom: convert to using the TZ allocator
From: Maximilian Luz @ 2024-04-04 18:37 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Elliot Berman,
Krzysztof Kozlowski, Guru Das Srinagesh, Andrew Halaney,
Alex Elder, Srini Kandagatla, Arnd Bergmann, linux-arm-msm,
linux-kernel, linux-arm-kernel, kernel, Bartosz Golaszewski
In-Reply-To: <CAMRc=McZ9dpD7Ws0vq-eYCN3smA6dHOLu_i1BL=x+CAaYr9S2w@mail.gmail.com>
On 4/3/24 9:47 AM, Bartosz Golaszewski wrote:
> On Tue, Apr 2, 2024 at 10:44 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Sat, Mar 30, 2024 at 8:16 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>>
>>> On Fri, 29 Mar 2024 20:57:52 +0100, Maximilian Luz <luzmaximilian@gmail.com> said:
>>>> On 3/29/24 8:46 PM, Bartosz Golaszewski wrote:
>>>>> On Fri, 29 Mar 2024 at 20:39, Maximilian Luz <luzmaximilian@gmail.com> wrote:
>>>>>>
>>>>>> On 3/29/24 8:26 PM, Bartosz Golaszewski wrote:
>>>>>>> On Fri, 29 Mar 2024 at 20:22, Maximilian Luz <luzmaximilian@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On 3/29/24 8:07 PM, Bartosz Golaszewski wrote:
>>>>>>>>>
>>>>>>>>> Both with and without SHM bridge?
>>>>>>>>
>>>>>>>> With CONFIG_QCOM_TZMEM_MODE_GENERIC=y (and the upcoming fix) everything
>>>>>>>> works. With CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y things unfortunately
>>>>>>>> still get stuck at boot (regardless of the fix). I think that's
>>>>>>>> happening even before anything efivar related should come up.
>>>>>>>>
>>>>>>>
>>>>>>> This is on X13s? I will get one in 3 weeks. Can you get the bootlog
>>>>>>> somehow? Does the laptop have any serial console?
>>>>>>
>>>>>> Surface Pro X (sc8180x), but it should be similar enough to the X13s in
>>>>>> that regard. At least from what people with access to the X13s told me,
>>>>>> the qseecom stuff seems to behave the same.
>>>>>>
>>>>>> Unfortunately I don't have a direct serial console. Best I have is
>>>>>> USB-serial, but it's not even getting there. I'll have to try and see if
>>>>>> I can get some more info on the screen.
>>>>>>
>>>>>
>>>>> I have access to a sc8180x-primus board, does it make sense to test
>>>>> with this one? If so, could you give me instructions on how to do it?
>>>>
>>>> I guess it's worth a shot.
>>>>
>>>> From what I can tell, there shouldn't be any patches in my tree that
>>>> would conflict with it. So I guess it should just be building it with
>>>> CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y and booting.
>>>>
>>>> I am currently testing it on top of a patched v6.8 tree though (but that
>>>> should just contain patches to get the Pro X running). You can find the
>>>> full tree at
>>>>
>>>> https://github.com/linux-surface/kernel/tree/spx/v6.8
>>>>
>>>> The last commit is the fix I mentioned, so you might want to revert
>>>> that, since the shmem issue triggers regardless of that and it prevents
>>>> your series from applying cleanly.
>>>>
>>>> Best regards,
>>>> Max
>>>>
>>>
>>> sc8180x-primus' support upstream is quite flaky. The board boots 50% of time.
>>> However it's true that with SHM bridge it gets to:
>>>
>>> mount: mounting efivarfs on /sys/firmware/efi/efivars failed: Operation not supported
>>>
>>> and stops 100% of the time. Without SHM bridge I cannot boot it either because
>>> I suppose I need the patch you sent yesterday. I haven't had the time to
>>> rebase it yet, it's quite intrusive to my series.
>>>
>>> I can confirm that with that patch the board still boots but still 50% of the
>>> time.
>>>
>>> Bart
>>
>> Hi!
>>
>> I was under the impression that until v8, the series worked on sc8180x
>> but I'm seeing that even v7 has the same issue with SHM Bridge on
>> sc8180x-primus. Could you confirm? Because I'm not sure if I should
>> track the differences or the whole thing was broken for this platform
>> from the beginning.
>>
>> Bart
>
> Interestingly, it doesn't seem like a problem with qseecom - even if I
> disable the driver, the board still freezes after the first SCM call
> using SHM bridge. I suspect - and am trying to clarify that with qcom
> - that this architecture doesn't support SHM bridge but doesn't report
> it either unlike other older platforms. Or maybe there's some quirk
> somewhere. Anyway, I'm on it.
Awesome, thanks!
Best regards,
Max
_______________________________________________
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 v9 00/13] firmware: qcom: qseecom: convert to using the TZ allocator
From: Maximilian Luz @ 2024-04-04 18:36 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andy Gross, Bjorn Andersson, Konrad Dybcio, Elliot Berman,
Krzysztof Kozlowski, Guru Das Srinagesh, Andrew Halaney,
Alex Elder, Srini Kandagatla, Arnd Bergmann, linux-arm-msm,
linux-kernel, linux-arm-kernel, kernel, Bartosz Golaszewski
In-Reply-To: <CAMRc=Me0MamtJoPtQnucKyZx9pfkEPDAAZqWFWRU0CBcj+P50A@mail.gmail.com>
On 4/2/24 10:44 AM, Bartosz Golaszewski wrote:
> On Sat, Mar 30, 2024 at 8:16 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>>
>> On Fri, 29 Mar 2024 20:57:52 +0100, Maximilian Luz <luzmaximilian@gmail.com> said:
>>> On 3/29/24 8:46 PM, Bartosz Golaszewski wrote:
>>>> On Fri, 29 Mar 2024 at 20:39, Maximilian Luz <luzmaximilian@gmail.com> wrote:
>>>>>
>>>>> On 3/29/24 8:26 PM, Bartosz Golaszewski wrote:
>>>>>> On Fri, 29 Mar 2024 at 20:22, Maximilian Luz <luzmaximilian@gmail.com> wrote:
>>>>>>>
>>>>>>> On 3/29/24 8:07 PM, Bartosz Golaszewski wrote:
>>>>>>>>
>>>>>>>> Both with and without SHM bridge?
>>>>>>>
>>>>>>> With CONFIG_QCOM_TZMEM_MODE_GENERIC=y (and the upcoming fix) everything
>>>>>>> works. With CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y things unfortunately
>>>>>>> still get stuck at boot (regardless of the fix). I think that's
>>>>>>> happening even before anything efivar related should come up.
>>>>>>>
>>>>>>
>>>>>> This is on X13s? I will get one in 3 weeks. Can you get the bootlog
>>>>>> somehow? Does the laptop have any serial console?
>>>>>
>>>>> Surface Pro X (sc8180x), but it should be similar enough to the X13s in
>>>>> that regard. At least from what people with access to the X13s told me,
>>>>> the qseecom stuff seems to behave the same.
>>>>>
>>>>> Unfortunately I don't have a direct serial console. Best I have is
>>>>> USB-serial, but it's not even getting there. I'll have to try and see if
>>>>> I can get some more info on the screen.
>>>>>
>>>>
>>>> I have access to a sc8180x-primus board, does it make sense to test
>>>> with this one? If so, could you give me instructions on how to do it?
>>>
>>> I guess it's worth a shot.
>>>
>>> From what I can tell, there shouldn't be any patches in my tree that
>>> would conflict with it. So I guess it should just be building it with
>>> CONFIG_QCOM_TZMEM_MODE_SHMBRIDGE=y and booting.
>>>
>>> I am currently testing it on top of a patched v6.8 tree though (but that
>>> should just contain patches to get the Pro X running). You can find the
>>> full tree at
>>>
>>> https://github.com/linux-surface/kernel/tree/spx/v6.8
>>>
>>> The last commit is the fix I mentioned, so you might want to revert
>>> that, since the shmem issue triggers regardless of that and it prevents
>>> your series from applying cleanly.
>>>
>>> Best regards,
>>> Max
>>>
>>
>> sc8180x-primus' support upstream is quite flaky. The board boots 50% of time.
>> However it's true that with SHM bridge it gets to:
>>
>> mount: mounting efivarfs on /sys/firmware/efi/efivars failed: Operation not supported
>>
>> and stops 100% of the time. Without SHM bridge I cannot boot it either because
>> I suppose I need the patch you sent yesterday. I haven't had the time to
>> rebase it yet, it's quite intrusive to my series.
>>
>> I can confirm that with that patch the board still boots but still 50% of the
>> time.
>>
>> Bart
>
> Hi!
>
> I was under the impression that until v8, the series worked on sc8180x
> but I'm seeing that even v7 has the same issue with SHM Bridge on
> sc8180x-primus. Could you confirm? Because I'm not sure if I should
> track the differences or the whole thing was broken for this platform
> from the beginning.
Hi, sorry for the delay.
Unfortunately I haven't had the time to test anything since v3. I don't
remember all the details, but based on what I wrote back then, enabling
the SHM bridge option did not lead to this result.
I can try to test v7 (and others) on the weekend.
Best regards,
Max
_______________________________________________
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] media: mediatek: vcodec: fix the error sizeimage for 10bit bitstream
From: Nicolas Dufresne @ 2024-04-04 18:28 UTC (permalink / raw)
To: Yunfei Dong, Nícolas F . R . A . Prado, Sebastian Fricke,
Hans Verkuil, AngeloGioacchino Del Regno, Benjamin Gaignard,
Nathan Hebert
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240403093018.13168-1-yunfei.dong@mediatek.com>
Hi,
Le mercredi 03 avril 2024 à 17:30 +0800, Yunfei Dong a écrit :
> The sizeimage of each plane are calculated the same way for 8bit and
> 10bit bitstream. Need to enlarge the sizeimage with simeimage*5/4 for
> 10bit bitstream when try and set fmt.
Can we stop adding more layers of custom code and port to v4l2-common helpers
please.
regards,
Nicolas
>
> Fixes: 9d86be9bda6c ("media: mediatek: vcodec: Add driver to support 10bit")
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
> .../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 47 ++++++++++++++-----
> 1 file changed, 34 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> index 9107707de6c4..45209894f1fe 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> @@ -259,6 +259,7 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
> pix_fmt_mp->num_planes = 1;
> pix_fmt_mp->plane_fmt[0].bytesperline = 0;
> } else if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + unsigned int dram_y, dram_c, dram_y_10bit, dram_c_10bit;
> int tmp_w, tmp_h;
>
> /*
> @@ -280,22 +281,42 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
> (pix_fmt_mp->height + 64) <= frmsize->max_height)
> pix_fmt_mp->height += 64;
>
> - mtk_v4l2_vdec_dbg(0, ctx,
> - "before resize wxh=%dx%d, after resize wxh=%dx%d, sizeimage=%d",
> - tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
> - pix_fmt_mp->width * pix_fmt_mp->height);
> + dram_y = pix_fmt_mp->width * pix_fmt_mp->height;
> + dram_c = dram_y / 2;
> +
> + dram_y_10bit = dram_y * 5 / 4;
> + dram_c_10bit = dram_y_10bit / 2;
>
> pix_fmt_mp->num_planes = fmt->num_planes;
> - pix_fmt_mp->plane_fmt[0].sizeimage =
> - pix_fmt_mp->width * pix_fmt_mp->height;
> - pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> -
> - if (pix_fmt_mp->num_planes == 2) {
> - pix_fmt_mp->plane_fmt[1].sizeimage =
> - (pix_fmt_mp->width * pix_fmt_mp->height) / 2;
> - pix_fmt_mp->plane_fmt[1].bytesperline =
> - pix_fmt_mp->width;
> + if (pix_fmt_mp->num_planes == 1) {
> + if (ctx->is_10bit_bitstream) {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit + dram_c_10bit;
> + } else {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y + dram_c;
> + }
> + } else {
> + if (ctx->is_10bit_bitstream) {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
> + pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width * 5 / 4;
> +
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit;
> + pix_fmt_mp->plane_fmt[1].sizeimage = dram_c_10bit;
> + } else {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> + pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width;
> +
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y;
> + pix_fmt_mp->plane_fmt[1].sizeimage = dram_c;
> + }
> }
> +
> + mtk_v4l2_vdec_dbg(0, ctx,
> + "before resize:%dx%d, after resize:%dx%d, sizeimage=0x%x_0x%x",
> + tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
> + pix_fmt_mp->plane_fmt[0].sizeimage,
> + pix_fmt_mp->plane_fmt[1].sizeimage);
> }
>
> pix_fmt_mp->flags = 0;
_______________________________________________
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 4/6] usb: ohci-exynos: Switch from CONFIG_PM guards to pm_ptr()
From: Alan Stern @ 2024-04-04 18:27 UTC (permalink / raw)
To: Anand Moon
Cc: Greg Kroah-Hartman, Krzysztof Kozlowski, Alim Akhtar,
Christophe JAILLET, Johan Hovold, linux-usb, linux-arm-kernel,
linux-samsung-soc, linux-kernel
In-Reply-To: <20240404071350.4242-5-linux.amoon@gmail.com>
On Thu, Apr 04, 2024 at 12:43:20PM +0530, Anand Moon wrote:
> Use the new PM macros for the suspend and resume functions to be
> automatically dropped by the compiler when CONFIG_PM are disabled,
> without having to use #ifdef guards. If CONFIG_PM unused,
> they will simply be discarded by the compiler.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> v2: new changes in this series.
> ---
Acked-by: Alan Stern <stern@rowland.harvard.edu>
> drivers/usb/host/ohci-exynos.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 85d04ae0ae40..3e647e0b341d 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -212,8 +212,7 @@ static void exynos_ohci_shutdown(struct platform_device *pdev)
> hcd->driver->shutdown(hcd);
> }
>
> -#ifdef CONFIG_PM
> -static int exynos_ohci_suspend(struct device *dev)
> +static int __maybe_unused exynos_ohci_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> @@ -230,7 +229,7 @@ static int exynos_ohci_suspend(struct device *dev)
> return 0;
> }
>
> -static int exynos_ohci_resume(struct device *dev)
> +static int __maybe_unused exynos_ohci_resume(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> struct exynos_ohci_hcd *exynos_ohci = to_exynos_ohci(hcd);
> @@ -249,10 +248,6 @@ static int exynos_ohci_resume(struct device *dev)
>
> return 0;
> }
> -#else
> -#define exynos_ohci_suspend NULL
> -#define exynos_ohci_resume NULL
> -#endif
>
> static const struct ohci_driver_overrides exynos_overrides __initconst = {
> .extra_priv_size = sizeof(struct exynos_ohci_hcd),
> @@ -277,7 +272,7 @@ static struct platform_driver exynos_ohci_driver = {
> .shutdown = exynos_ohci_shutdown,
> .driver = {
> .name = "exynos-ohci",
> - .pm = &exynos_ohci_pm_ops,
> + .pm = pm_ptr(&exynos_ohci_pm_ops),
> .of_match_table = of_match_ptr(exynos_ohci_match),
> }
> };
> --
> 2.44.0
>
_______________________________________________
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 2/6] usb: ehci-exynos: Switch from CONFIG_PM guards to pm_ptr()
From: Alan Stern @ 2024-04-04 18:26 UTC (permalink / raw)
To: Anand Moon
Cc: Greg Kroah-Hartman, Krzysztof Kozlowski, Alim Akhtar,
Christophe JAILLET, Johan Hovold, linux-usb, linux-arm-kernel,
linux-samsung-soc, linux-kernel
In-Reply-To: <20240404071350.4242-3-linux.amoon@gmail.com>
On Thu, Apr 04, 2024 at 12:43:18PM +0530, Anand Moon wrote:
> Use the new PM macros for the suspend and resume functions to be
> automatically dropped by the compiler when CONFIG_PM are disabled,
> without having to use #ifdef guards. If CONFIG_PM unused,
> they will simply be discarded by the compiler.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> v2: add __maybe_unused to suspend/resume functions in case CONFIG_PM is
> disabled.
> dropped RUNTIME_PM_OPS
> ---
Acked-by: Alan Stern <stern@rowland.harvard.edu>
> drivers/usb/host/ehci-exynos.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index f00bfd0b13dc..4cfde1af32be 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -236,8 +236,7 @@ static void exynos_ehci_remove(struct platform_device *pdev)
> usb_put_hcd(hcd);
> }
>
> -#ifdef CONFIG_PM
> -static int exynos_ehci_suspend(struct device *dev)
> +static int __maybe_unused exynos_ehci_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
> @@ -256,7 +255,7 @@ static int exynos_ehci_suspend(struct device *dev)
> return rc;
> }
>
> -static int exynos_ehci_resume(struct device *dev)
> +static int __maybe_unused exynos_ehci_resume(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> struct exynos_ehci_hcd *exynos_ehci = to_exynos_ehci(hcd);
> @@ -279,10 +278,6 @@ static int exynos_ehci_resume(struct device *dev)
> ehci_resume(hcd, false);
> return 0;
> }
> -#else
> -#define exynos_ehci_suspend NULL
> -#define exynos_ehci_resume NULL
> -#endif
>
> static const struct dev_pm_ops exynos_ehci_pm_ops = {
> .suspend = exynos_ehci_suspend,
> @@ -303,7 +298,7 @@ static struct platform_driver exynos_ehci_driver = {
> .shutdown = usb_hcd_platform_shutdown,
> .driver = {
> .name = "exynos-ehci",
> - .pm = &exynos_ehci_pm_ops,
> + .pm = pm_ptr(&exynos_ehci_pm_ops),
> .of_match_table = of_match_ptr(exynos_ehci_match),
> }
> };
> --
> 2.44.0
>
_______________________________________________
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 1/2] media: v4l2-ctrls: Add average qp control
From: Nicolas Dufresne @ 2024-04-04 18:14 UTC (permalink / raw)
To: Ming Qian, mchehab, hverkuil-cisco
Cc: shawnguo, robh+dt, s.hauer, kernel, festevam, linux-imx,
xiahong.bao, eagle.zhou, tao.jiang_2, ming.qian, imx, linux-media,
linux-kernel, linux-arm-kernel
In-Reply-To: <20240329092352.2648837-1-ming.qian@nxp.com>
Hi,
Le vendredi 29 mars 2024 à 18:23 +0900, Ming Qian a écrit :
> Add a control V4L2_CID_MPEG_VIDEO_AVERAGE_QP to report the average qp
> value of current encoded frame.
>
> Signed-off-by: Ming Qian <ming.qian@nxp.com>
> ---
> Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst | 4 ++++
> drivers/media/v4l2-core/v4l2-ctrls-defs.c | 5 +++++
> include/uapi/linux/v4l2-controls.h | 2 ++
> 3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> index 2a165ae063fb..cef20b3f54ca 100644
> --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst
> @@ -1653,6 +1653,10 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> Quantization parameter for a P frame for FWHT. Valid range: from 1
> to 31.
>
> +``V4L2_CID_MPEG_VIDEO_AVERAGE_QP (integer)``
> + This read-only control returns the average qp value of the currently
> + encoded frame. Applicable to the H264 and HEVC encoders.
That seems ambiguous at best. What does it mean the "currently encoded frame" ?
The OUTPUT and CAPTURE queue can be holding multiple frames. For "per frame"
accurate reporting, I feel like we'd need something like Hans' read-only
requests proposal [0]. Its basically a mechanism that let you attach request FD
to capture buffer, so that supported controls can be saved per v4l2-buffer and
read later on.
https://patches.linaro.org/project/linux-media/patch/20210610113615.785359-12-hverkuil-cisco@xs4all.nl/
If this isn't what you wanted, we'll need a better definition. It might be
helpful to explain what this is used for.
Nicolas
> +
> .. raw:: latex
>
> \normalsize
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls-defs.c b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> index 8696eb1cdd61..88e86e4e539d 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls-defs.c
> @@ -972,6 +972,7 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_USE_LTR_FRAMES: return "Use LTR Frames";
> case V4L2_CID_FWHT_I_FRAME_QP: return "FWHT I-Frame QP Value";
> case V4L2_CID_FWHT_P_FRAME_QP: return "FWHT P-Frame QP Value";
> + case V4L2_CID_MPEG_VIDEO_AVERAGE_QP: return "Average QP value";
>
> /* VPX controls */
> case V4L2_CID_MPEG_VIDEO_VPX_NUM_PARTITIONS: return "VPX Number of Partitions";
> @@ -1507,6 +1508,10 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> *max = 0xffffffffffffLL;
> *step = 1;
> break;
> + case V4L2_CID_MPEG_VIDEO_AVERAGE_QP:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *flags |= V4L2_CTRL_FLAG_VOLATILE | V4L2_CTRL_FLAG_READ_ONLY;
> + break;
> case V4L2_CID_PIXEL_RATE:
> *type = V4L2_CTRL_TYPE_INTEGER64;
> *flags |= V4L2_CTRL_FLAG_READ_ONLY;
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 99c3f5e99da7..974fd254e573 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -898,6 +898,8 @@ enum v4l2_mpeg_video_av1_level {
> V4L2_MPEG_VIDEO_AV1_LEVEL_7_3 = 23
> };
>
> +#define V4L2_CID_MPEG_VIDEO_AVERAGE_QP (V4L2_CID_CODEC_BASE + 657)
> +
> /* MPEG-class control IDs specific to the CX2341x driver as defined by V4L2 */
> #define V4L2_CID_CODEC_CX2341X_BASE (V4L2_CTRL_CLASS_CODEC | 0x1000)
> #define V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE (V4L2_CID_CODEC_CX2341X_BASE+0)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2 2/2] perf: cs-etm: Store previous timestamp in packet queue
From: Tanmay Jagdale @ 2024-04-04 18:07 UTC (permalink / raw)
To: john.g.garry, will, james.clark, mike.leach, leo.yan,
suzuki.poulose, peterz, mingo, alexander.shishkin, jolsa, irogers,
adrian.hunter
Cc: linux-arm-kernel, coresight, linux-perf-users, linux-kernel,
sgoutham, gcherian, lcherian, Tanmay Jagdale
In-Reply-To: <20240404180731.7006-1-tanmay@marvell.com>
Since logic in cs_etm__sample is changed to synthesizing the previous
packet (tidq->prev_packet) instead of current packet (tidq->packet),
the first time this function is called, tidq->prev_packet is NULL
and we return without processing anything.
This is as expected but, in the first call, we would have a valid
timestamp (stored in tidq->packet_queue.cs_timestamp) which belongs
to tidq->packet. This would be lost due to no processing.
Losing this timestamp results in all the synthesized packets being
associated with the next timestamp and not their corresponding one.
To fix this, introduce a new variable (prev_cs_timestamp) to store the
queue's timestamp in cs_etm__sample(). When we start synthesizing the
prev_packet, use this cached value instead of the current timestamp
(cs_timestamp).
Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
---
tools/perf/util/cs-etm.c | 17 +++++++++++++----
tools/perf/util/cs-etm.h | 1 +
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 55db1932f785..d5072c16fcd8 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1459,13 +1459,15 @@ u64 cs_etm__convert_sample_time(struct cs_etm_queue *etmq, u64 cs_timestamp)
}
static inline u64 cs_etm__resolve_sample_time(struct cs_etm_queue *etmq,
- struct cs_etm_traceid_queue *tidq)
+ struct cs_etm_traceid_queue *tidq,
+ bool instruction_sample)
{
struct cs_etm_auxtrace *etm = etmq->etm;
struct cs_etm_packet_queue *packet_queue = &tidq->packet_queue;
if (!etm->timeless_decoding && etm->has_virtual_ts)
- return packet_queue->cs_timestamp;
+ return instruction_sample ? packet_queue->prev_cs_timestamp :
+ packet_queue->cs_timestamp;
else
return etm->latest_kernel_timestamp;
}
@@ -1484,7 +1486,7 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
event->sample.header.size = sizeof(struct perf_event_header);
/* Set time field based on etm auxtrace config. */
- sample.time = cs_etm__resolve_sample_time(etmq, tidq);
+ sample.time = cs_etm__resolve_sample_time(etmq, tidq, true);
sample.ip = addr;
sample.pid = thread__pid(tidq->thread);
@@ -1560,7 +1562,7 @@ static int cs_etm__synth_branch_sample(struct cs_etm_queue *etmq,
event->sample.header.size = sizeof(struct perf_event_header);
/* Set time field based on etm auxtrace config. */
- sample.time = cs_etm__resolve_sample_time(etmq, tidq);
+ sample.time = cs_etm__resolve_sample_time(etmq, tidq, false);
sample.ip = ip;
sample.pid = thread__pid(tidq->prev_packet_thread);
@@ -1849,6 +1851,13 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
}
}
+ /*
+ * Since we synthesize the prev_packet, store the current timestamp
+ * here in prev_cs_timestamp so that when we *actually* synthesize
+ * the prev_packet, we use this timestamp and not the future one.
+ */
+ tidq->packet_queue.prev_cs_timestamp = tidq->packet_queue.cs_timestamp;
+
cs_etm__packet_swap(etm, tidq);
return 0;
diff --git a/tools/perf/util/cs-etm.h b/tools/perf/util/cs-etm.h
index 4696267a32f0..333eeb2c06a0 100644
--- a/tools/perf/util/cs-etm.h
+++ b/tools/perf/util/cs-etm.h
@@ -205,6 +205,7 @@ struct cs_etm_packet_queue {
u32 instr_count;
u64 cs_timestamp; /* Timestamp from trace data, converted to ns if possible */
u64 next_cs_timestamp;
+ u64 prev_cs_timestamp;
struct cs_etm_packet packet_buffer[CS_ETM_PACKET_MAX_BUFFER];
};
--
2.34.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
* [PATCH V2 1/2] perf: cs-etm: Fixes in instruction sample synthesis
From: Tanmay Jagdale @ 2024-04-04 18:07 UTC (permalink / raw)
To: john.g.garry, will, james.clark, mike.leach, leo.yan,
suzuki.poulose, peterz, mingo, alexander.shishkin, jolsa, irogers,
adrian.hunter
Cc: linux-arm-kernel, coresight, linux-perf-users, linux-kernel,
sgoutham, gcherian, lcherian, Tanmay Jagdale
In-Reply-To: <20240404180731.7006-1-tanmay@marvell.com>
The existing method of synthesizing instruction samples has the
following issues:
1. Branch target address is missing.
2. Non-branch instructions have mnemonics of branch instructions.
To fix issue 1), start synthesizing the instructions from the
previous packet (tidq->prev_packet) instead of current packet
(tidq->packet). This way, it is easy to figure out the target
address of the branch instruction in tidq->prev_packet which
is the current packet's (tidq->packet) first executed instruction.
After the switch to processing the previous packet first, we no
longer need to swap the packets during cs_etm__flush()
Fix for issue 2) is to set the sample flags only when we reach the
last instruction in the tidq (which would be a branch instruction).
Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
---
tools/perf/util/cs-etm.c | 32 +++++++++++++++++++++++++-------
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index d65d7485886c..55db1932f785 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -1493,10 +1493,26 @@ static int cs_etm__synth_instruction_sample(struct cs_etm_queue *etmq,
sample.stream_id = etmq->etm->instructions_id;
sample.period = period;
sample.cpu = tidq->packet->cpu;
- sample.flags = tidq->prev_packet->flags;
sample.cpumode = event->sample.header.misc;
- cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->packet, &sample);
+ cs_etm__copy_insn(etmq, tidq->trace_chan_id, tidq->prev_packet, &sample);
+
+ /* Populate branch target information only when we encounter
+ * branch instruction, which is at the end of tidq->prev_packet.
+ */
+ if (addr == (tidq->prev_packet->end_addr - 4)) {
+ /* Update the perf_sample flags using the prev_packet
+ * since that is the queue we are synthesizing.
+ */
+ sample.flags = tidq->prev_packet->flags;
+
+ /* The last instruction of the previous queue would be a
+ * branch operation. Get the target of that branch by looking
+ * into the first executed instruction of the current packet
+ * queue.
+ */
+ sample.addr = cs_etm__first_executed_instr(tidq->packet);
+ }
if (etm->synth_opts.last_branch)
sample.branch_stack = tidq->last_branch;
@@ -1717,7 +1733,7 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
/* Get instructions remainder from previous packet */
instrs_prev = tidq->period_instructions;
- tidq->period_instructions += tidq->packet->instr_count;
+ tidq->period_instructions += tidq->prev_packet->instr_count;
/*
* Record a branch when the last instruction in
@@ -1797,8 +1813,11 @@ static int cs_etm__sample(struct cs_etm_queue *etmq,
* been executed, but PC has not advanced to next
* instruction)
*/
+ /* Get address from prev_packet since we are synthesizing
+ * that in cs_etm__synth_instruction_sample()
+ */
addr = cs_etm__instr_addr(etmq, trace_chan_id,
- tidq->packet, offset - 1);
+ tidq->prev_packet, offset - 1);
ret = cs_etm__synth_instruction_sample(
etmq, tidq, addr,
etm->instructions_sample_period);
@@ -1862,7 +1881,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq,
/* Handle start tracing packet */
if (tidq->prev_packet->sample_type == CS_ETM_EMPTY)
- goto swap_packet;
+ goto reset_last_br;
if (etmq->etm->synth_opts.last_branch &&
etmq->etm->synth_opts.instructions &&
@@ -1898,8 +1917,7 @@ static int cs_etm__flush(struct cs_etm_queue *etmq,
return err;
}
-swap_packet:
- cs_etm__packet_swap(etm, tidq);
+reset_last_br:
/* Reset last branches after flush the trace */
if (etm->synth_opts.last_branch)
--
2.34.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
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