* Re: [PATCH v2 0/3] KVM: arm64: Floating point documentation updates and code tweaks
From: Marc Zyngier @ 2023-04-21 12:54 UTC (permalink / raw)
To: Will Deacon, Oliver Upton, Alexandru Elisei, James Morse,
Suzuki K Poulose, Mark Brown, Catalin Marinas
Cc: linux-arm-kernel, kvmarm
In-Reply-To: <20221214-kvm-arm64-sme-context-switch-v2-0-57ba0082e9ff@kernel.org>
On Tue, 07 Mar 2023 17:37:13 +0000, Mark Brown wrote:
> This series has some improvements to the documentation and code for the
> KVM floating point code, the main one being that it documents that the
> current behaviour where we disable streaming mode and ZA prior to
> running guests as being the intended behaviour. There's a more detailed
> discussion of that change in the patch commit log, but briefly we need
> to disable streaming mode in order to avoid EL1 triggering SME traps to
> itself due to executing instructions which should be valid.
>
> [...]
Applied to next, thanks!
[1/3] KVM: arm64: Document check for TIF_FOREIGN_FPSTATE
commit: 4c181e3d352e9280c84fb4b4c7a8940ce005374e
[2/3] KVM: arm64: Restructure check for SVE support in FP trap handler
commit: d071cefdcca39fdbcdd4bf36868448820dbac34b
[3/3] KVM: arm64: Clarify host SME state management
commit: aaa2f14e6f3f34de8edfb13566110a0fe0d88785
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: fix repeated words in comments
From: Marc Zyngier @ 2023-04-21 12:53 UTC (permalink / raw)
To: catalin.marinas, Jingyu Wang, will, yuzenghui, suzuki.poulose,
james.morse, oliver.upton
Cc: linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20230309075919.169518-1-jingyuwang_vip@163.com>
On Thu, 9 Mar 2023 15:59:19 +0800, Jingyu Wang wrote:
> Delete the redundant word 'to'.
Applied to next, thanks!
[1/1] KVM: arm64: fix repeated words in comments
commit: 3d1793562858f2bc42cc722fe00ec9b2ff0618e1
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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] KVM: arm64: Slightly optimize flush_context()
From: Marc Zyngier @ 2023-04-21 12:53 UTC (permalink / raw)
To: Will Deacon, Oliver Upton, James Morse, Suzuki K Poulose,
Catalin Marinas, Christophe JAILLET, Zenghui Yu
Cc: linux-arm-kernel, linux-kernel, kernel-janitors, kvmarm
In-Reply-To: <97bf2743f3a302b3066aced02218b9da60690dd3.1681854412.git.christophe.jaillet@wanadoo.fr>
On Tue, 18 Apr 2023 23:47:37 +0200, Christophe JAILLET wrote:
> bitmap_zero() is faster than bitmap_clear(), so use it to save a few
> cycles.
Applied to next, thanks!
[1/2] KVM: arm64: Slightly optimize flush_context()
commit: 4be8ddb48b1b6c6067fb59c846b9c6e19d6efe14
[2/2] KVM: arm64: Use the bitmap API to allocate bitmaps
commit: a00e9e4319c2a8a8b166da028292de83190e39a4
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: dts: rockchip: fix nEXTRST on SOQuartz
From: Heiko Stuebner @ 2023-04-21 12:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Peter Geis, Nicolas Frattaroli
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <12191318.O9o76ZdvQC@archbox>
Am Freitag, 21. April 2023, 14:38:48 CEST schrieb Nicolas Frattaroli:
> Hello,
>
> On Friday, 21 April 2023 13:58:58 CEST Heiko Stuebner wrote:
> > Hi,
> >
> > Am Mittwoch, 19. April 2023, 19:17:31 CEST schrieb Nicolas Frattaroli:
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> > > b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi index
> > > ce7165d7f1a1..f589a4fdaccb 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> > > @@ -65,6 +65,17 @@ led_work: led-work {
> > >
> > > };
> > >
> > > };
> > >
> > > + nextrst_pin: nextrst-pin-regulator {
> > > + compatible = "regulator-fixed";
> > > + enable-active-high;
> > > + gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&nextrst_h>;
> > > + regulator-always-on;
> > > + regulator-boot-on;
> > > + regulator-name = "nextrst";
> > > + };
> > > +
> >
> > I agree with the sentiment and of course the rationale of the change,
> > but not necessarily with the implementation ;-) .
> >
> > Why is this done as a regulator?
> >
> > If you want the nextrst line to be high, you could just use a gpio-hog
> > for the line instead of doing a (fake?-)regulator.
>
> Simply put: because I didn't know gpio hogs were a thing. I'll send a V2
> to correct this. Thanks for pointing it out!
great, 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] arm64: dts: rockchip: fix nEXTRST on SOQuartz
From: Nicolas Frattaroli @ 2023-04-21 12:38 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Peter Geis, Heiko Stuebner
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <8914603.GXAFRqVoOG@phil>
Hello,
On Friday, 21 April 2023 13:58:58 CEST Heiko Stuebner wrote:
> Hi,
>
> Am Mittwoch, 19. April 2023, 19:17:31 CEST schrieb Nicolas Frattaroli:
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> > b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi index
> > ce7165d7f1a1..f589a4fdaccb 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> > @@ -65,6 +65,17 @@ led_work: led-work {
> >
> > };
> >
> > };
> >
> > + nextrst_pin: nextrst-pin-regulator {
> > + compatible = "regulator-fixed";
> > + enable-active-high;
> > + gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&nextrst_h>;
> > + regulator-always-on;
> > + regulator-boot-on;
> > + regulator-name = "nextrst";
> > + };
> > +
>
> I agree with the sentiment and of course the rationale of the change,
> but not necessarily with the implementation ;-) .
>
> Why is this done as a regulator?
>
> If you want the nextrst line to be high, you could just use a gpio-hog
> for the line instead of doing a (fake?-)regulator.
Simply put: because I didn't know gpio hogs were a thing. I'll send a V2
to correct this. Thanks for pointing it out!
>
> For example the px30-ringneck.dtsi does something similar:
>
> &gpio2 {
> /*
> * The Qseven BIOS_DISABLE signal on the PX30-µQ7 keeps the
> on-module * eMMC powered-down initially (in fact it keeps the reset signal
> * asserted). BIOS_DISABLE_OVERRIDE pin allows to re-enable eMMC after * the
> SPL has been booted from SD Card.
> */
> bios-disable-override-hog {
> gpios = <RK_PB5 GPIO_ACTIVE_LOW>;
> output-high;
> line-name = "bios_disable_override";
> gpio-hog;
> };
> ...
> };
>
>
> Thanks
> Heiko
Kind regards,
Nicolas Frattaroli
_______________________________________________
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: mte: Do not set PG_mte_tagged if tags were not initialized
From: Catalin Marinas @ 2023-04-21 12:37 UTC (permalink / raw)
To: Peter Collingbourne
Cc: linux-arm-kernel, vincenzo.frascino, will, eugenis, stable
In-Reply-To: <20230420214327.2357985-1-pcc@google.com>
On Thu, Apr 20, 2023 at 02:43:27PM -0700, Peter Collingbourne wrote:
> The mte_sync_page_tags() function sets PG_mte_tagged if it initializes
> page tags. Then we return to mte_sync_tags(), which sets PG_mte_tagged
> again. At best, this is redundant. However, it is possible for
> mte_sync_page_tags() to return without having initialized tags for the
> page, i.e. in the case where check_swap is true (non-compound page),
> is_swap_pte(old_pte) is false and pte_is_tagged is false. So at worst,
> we set PG_mte_tagged on a page with uninitialized tags. This can happen
> if, for example, page migration causes a PTE for an untagged page to
> be replaced. If the userspace program subsequently uses mprotect() to
> enable PROT_MTE for that page, the uninitialized tags will be exposed
> to userspace.
>
> Fix it by removing the redundant call to set_page_mte_tagged().
>
> Fixes: e059853d14ca ("arm64: mte: Fix/clarify the PG_mte_tagged semantics")
> Signed-off-by: Peter Collingbourne <pcc@google.com>
> Cc: <stable@vger.kernel.org> # 6.1
> Link: https://linux-review.googlesource.com/id/Ib02d004d435b2ed87603b858ef7480f7b1463052
> ---
> arch/arm64/kernel/mte.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index f5bcb0dc6267..7e89968bd282 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -66,13 +66,10 @@ void mte_sync_tags(pte_t old_pte, pte_t pte)
> return;
>
> /* if PG_mte_tagged is set, tags have already been initialised */
> - for (i = 0; i < nr_pages; i++, page++) {
> - if (!page_mte_tagged(page)) {
> + for (i = 0; i < nr_pages; i++, page++)
> + if (!page_mte_tagged(page))
> mte_sync_page_tags(page, old_pte, check_swap,
> pte_is_tagged);
> - set_page_mte_tagged(page);
> - }
> - }
It makes sense, not sure why I added it here when mte_sync_page_tags()
was already setting the flag if needed.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.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] arm64: Also reset KASAN tag if page is not PG_mte_tagged
From: Catalin Marinas @ 2023-04-21 12:24 UTC (permalink / raw)
To: Peter Collingbourne
Cc: andreyknvl, Qun-wei Lin (林群崴),
Guangye Yang (杨光业), linux-mm,
Chinwen Chang (張錦文), kasan-dev, ryabinin.a.a,
linux-arm-kernel, vincenzo.frascino, will, eugenis, stable
In-Reply-To: <20230420210945.2313627-1-pcc@google.com>
On Thu, Apr 20, 2023 at 02:09:45PM -0700, Peter Collingbourne wrote:
> Consider the following sequence of events:
>
> 1) A page in a PROT_READ|PROT_WRITE VMA is faulted.
> 2) Page migration allocates a page with the KASAN allocator,
> causing it to receive a non-match-all tag, and uses it
> to replace the page faulted in 1.
> 3) The program uses mprotect() to enable PROT_MTE on the page faulted in 1.
Ah, so there is no race here, it's simply because the page allocation
for migration has a non-match-all kasan tag in page->flags.
How do we handle the non-migration case with mprotect()? IIRC
post_alloc_hook() always resets the page->flags since
GFP_HIGHUSER_MOVABLE has the __GFP_SKIP_KASAN_UNPOISON flag.
> As a result of step 3, we are left with a non-match-all tag for a page
> with tags accessible to userspace, which can lead to the same kind of
> tag check faults that commit e74a68468062 ("arm64: Reset KASAN tag in
> copy_highpage with HW tags only") intended to fix.
>
> The general invariant that we have for pages in a VMA with VM_MTE_ALLOWED
> is that they cannot have a non-match-all tag. As a result of step 2, the
> invariant is broken. This means that the fix in the referenced commit
> was incomplete and we also need to reset the tag for pages without
> PG_mte_tagged.
>
> Fixes: e5b8d9218951 ("arm64: mte: reset the page tag in page->flags")
This commit was reverted in 20794545c146 (arm64: kasan: Revert "arm64:
mte: reset the page tag in page->flags"). It looks a bit strange to fix
it up.
> diff --git a/arch/arm64/mm/copypage.c b/arch/arm64/mm/copypage.c
> index 4aadcfb01754..a7bb20055ce0 100644
> --- a/arch/arm64/mm/copypage.c
> +++ b/arch/arm64/mm/copypage.c
> @@ -21,9 +21,10 @@ void copy_highpage(struct page *to, struct page *from)
>
> copy_page(kto, kfrom);
>
> + if (kasan_hw_tags_enabled())
> + page_kasan_tag_reset(to);
> +
> if (system_supports_mte() && page_mte_tagged(from)) {
> - if (kasan_hw_tags_enabled())
> - page_kasan_tag_reset(to);
This should work but can we not do this at allocation time like we do
for the source page and remove any page_kasan_tag_reset() here
altogether?
--
Catalin
_______________________________________________
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/1] ufs: core: fix &hwq->cq_lock deadlock issue
From: Can Guo @ 2023-04-21 11:05 UTC (permalink / raw)
To: Alice Chao, alim.akhtar, avri.altman, bvanassche, jejb,
martin.petersen, matthias.bgg, angelogioacchino.delregno,
quic_asutoshd, mani, linux-scsi, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: stanley.chu, peter.wang, chun-hung.wu, powen.kao, naomi.chu,
cc.chou, chaotian.jing, jiajie.hao, tun-yu.yu, eddie.huang,
wsd_upstream
In-Reply-To: <20230421075636.24946-1-alice.chao@mediatek.com>
On 4/21/2023 3:56 PM, Alice Chao wrote:
> [name:lockdep&]WARNING: inconsistent lock state
> [name:lockdep&]--------------------------------
> [name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes:
> ffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}, at:
> ufshcd_mcq_poll_cqe_lock+0x30/0xe0
> [name:lockdep&]{IN-HARDIRQ-W} state was registered at:
> lock_acquire+0x17c/0x33c
> _raw_spin_lock+0x5c/0x7c
> ufshcd_mcq_poll_cqe_lock+0x30/0xe0
> ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod]
> __handle_irq_event_percpu+0x140/0x3ec
> handle_irq_event+0x50/0xd8
> handle_fasteoi_irq+0x148/0x2b0
> generic_handle_domain_irq+0x4c/0x6c
> gic_handle_irq+0x58/0x134
> call_on_irq_stack+0x40/0x74
> do_interrupt_handler+0x84/0xe4
> el1_interrupt+0x3c/0x78
> <snip>
>
> Possible unsafe locking scenario:
> CPU0
> ----
> lock(&hwq->cq_lock);
> <Interrupt>
> lock(&hwq->cq_lock);
> *** DEADLOCK ***
> 2 locks held by kworker/u16:4/260:
>
> [name:lockdep&]
> stack backtrace:
> CPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S W OE
> 6.1.17-mainline-android14-2-g277223301adb #1
> Workqueue: ufs_eh_wq_0 ufshcd_err_handler
>
> Call trace:
> dump_backtrace+0x10c/0x160
> show_stack+0x20/0x30
> dump_stack_lvl+0x98/0xd8
> dump_stack+0x20/0x60
> print_usage_bug+0x584/0x76c
> mark_lock_irq+0x488/0x510
> mark_lock+0x1ec/0x25c
> __lock_acquire+0x4d8/0xffc
> lock_acquire+0x17c/0x33c
> _raw_spin_lock+0x5c/0x7c
> ufshcd_mcq_poll_cqe_lock+0x30/0xe0
> ufshcd_poll+0x68/0x1b0
> ufshcd_transfer_req_compl+0x9c/0xc8
> ufshcd_err_handler+0x3bc/0xea0
> process_one_work+0x2f4/0x7e8
> worker_thread+0x234/0x450
> kthread+0x110/0x134
> ret_from_fork+0x10/0x20
>
> ufs_mtk_mcq_intr() could refer to
> https://lore.kernel.org/all/20230328103423.10970-3-powen.kao@mediatek.com/
>
> When ufshcd_err_handler() is executed, CQ event interrupt can enter
> waiting for the same lock. It could happened in upstream code path
> ufshcd_handle_mcq_cq_events() and also in ufs_mtk_mcq_intr(). This
> warning message will be generated when &hwq->cq_lock is used in IRQ
> context with IRQ enabled. Use ufshcd_mcq_poll_cqe_lock() with
> spin_lock_irqsave instead of spin_lock to resolve the deadlock issue.
>
> Signed-off-by: Alice Chao <alice.chao@mediatek.com>
> ---
> drivers/ufs/core/ufs-mcq.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/ufs/core/ufs-mcq.c b/drivers/ufs/core/ufs-mcq.c
> index 31df052fbc41..202ff71e1b58 100644
> --- a/drivers/ufs/core/ufs-mcq.c
> +++ b/drivers/ufs/core/ufs-mcq.c
> @@ -299,11 +299,11 @@ EXPORT_SYMBOL_GPL(ufshcd_mcq_poll_cqe_nolock);
> unsigned long ufshcd_mcq_poll_cqe_lock(struct ufs_hba *hba,
> struct ufs_hw_queue *hwq)
> {
> - unsigned long completed_reqs;
> + unsigned long completed_reqs, flags;
>
> - spin_lock(&hwq->cq_lock);
> + spin_lock_irqsave(&hwq->cq_lock, flags);
> completed_reqs = ufshcd_mcq_poll_cqe_nolock(hba, hwq);
> - spin_unlock(&hwq->cq_lock);
> + spin_unlock_irqrestore(&hwq->cq_lock, flags);
>
> return completed_reqs;
> }
Reviewed-by: Can Guo <quic_cang@quicinc.com>
Thanks for the fix.
Regards,
Can Guo.
_______________________________________________
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] coresight: Fix signedness bug in tmc_etr_buf_insert_barrier_packet()
From: Suzuki K Poulose @ 2023-04-21 12:12 UTC (permalink / raw)
To: Dan Carpenter
Cc: Mike Leach, Leo Yan, Alexander Shishkin, Mathieu Poirier,
Greg Kroah-Hartman, coresight, linux-arm-kernel, kernel-janitors
In-Reply-To: <7d33e244-d8b9-4c27-9653-883a13534b01@kili.mountain>
Hi Dan
On 21/04/2023 11:42, Dan Carpenter wrote:
> This code generates a Smatch warning:
>
> drivers/hwtracing/coresight/coresight-tmc-etr.c:947 tmc_etr_buf_insert_barrier_packet()
> error: uninitialized symbol 'bufp'.
>
> The problem is that if tmc_sg_table_get_data() returns -EINVAL, then
> when we test if "len < CORESIGHT_BARRIER_PKT_SIZE", the negative "len"
> value is type promoted to a high unsigned long value which is greater
> than CORESIGHT_BARRIER_PKT_SIZE. Fix this bug by adding an explicit
> check for error codes.
>
> Fixes: 75f4e3619fe2 ("coresight: tmc-etr: Add transparent buffer management")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> index 918d461fcf4a..eaa296ced167 100644
> --- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
> +++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
> @@ -942,7 +942,7 @@ tmc_etr_buf_insert_barrier_packet(struct etr_buf *etr_buf, u64 offset)
>
> len = tmc_etr_buf_get_data(etr_buf, offset,
> CORESIGHT_BARRIER_PKT_SIZE, &bufp);
> - if (WARN_ON(len < CORESIGHT_BARRIER_PKT_SIZE))
> + if (WARN_ON(len < 0 || len < CORESIGHT_BARRIER_PKT_SIZE))
> return -EINVAL;
> coresight_insert_barrier_packet(bufp);
> return offset + CORESIGHT_BARRIER_PKT_SIZE;
Thanks for the fix, I will send this as fixes at 6.4-rc1, as I have
already sent the PULL request for 6.4
Suzuki
_______________________________________________
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: dts: rockchip: fix nEXTRST on SOQuartz
From: Heiko Stuebner @ 2023-04-21 11:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Peter Geis, Nicolas Frattaroli
Cc: Nicolas Frattaroli, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20230419171731.28641-1-frattaroli.nicolas@gmail.com>
Hi,
Am Mittwoch, 19. April 2023, 19:17:31 CEST schrieb Nicolas Frattaroli:
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> index ce7165d7f1a1..f589a4fdaccb 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-soquartz.dtsi
> @@ -65,6 +65,17 @@ led_work: led-work {
> };
> };
>
> + nextrst_pin: nextrst-pin-regulator {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpio = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&nextrst_h>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-name = "nextrst";
> + };
> +
I agree with the sentiment and of course the rationale of the change,
but not necessarily with the implementation ;-) .
Why is this done as a regulator?
If you want the nextrst line to be high, you could just use a gpio-hog
for the line instead of doing a (fake?-)regulator.
For example the px30-ringneck.dtsi does something similar:
&gpio2 {
/*
* The Qseven BIOS_DISABLE signal on the PX30-µQ7 keeps the on-module
* eMMC powered-down initially (in fact it keeps the reset signal
* asserted). BIOS_DISABLE_OVERRIDE pin allows to re-enable eMMC after
* the SPL has been booted from SD Card.
*/
bios-disable-override-hog {
gpios = <RK_PB5 GPIO_ACTIVE_LOW>;
output-high;
line-name = "bios_disable_override";
gpio-hog;
};
...
};
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
* [PATCH v2 1/1] clk: imx6ul: retain early UART clocks during kernel init
From: Alexander Stein @ 2023-04-21 11:55 UTC (permalink / raw)
To: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd, Shawn Guo,
Sascha Hauer, Fabio Estevam
Cc: Alexander Stein, Pengutronix Kernel Team, NXP Linux Team,
linux-clk, linux-arm-kernel
Make sure to keep UART clocks enabled during kernel init if
earlyprintk or earlycon are active.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v2:
* Rebased to next-20230420
Apparently i.MX6UL was missed in commit 0822f933735c ("clk: imx6: retain
early UART clocks during kernel init"). But as commit 379c9a24cc23 ("clk:
imx: Fix reparenting of UARTs not associated with stdout") changes the
calling signature it's not warranting a Fixes for the old commit.
drivers/clk/imx/clk-imx6ul.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index e3696a88b5a3..f9394e94f69d 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -544,6 +544,8 @@ static void __init imx6ul_clocks_init(struct device_node *ccm_node)
clk_set_parent(hws[IMX6UL_CLK_ENET1_REF_SEL]->clk, hws[IMX6UL_CLK_ENET_REF]->clk);
clk_set_parent(hws[IMX6UL_CLK_ENET2_REF_SEL]->clk, hws[IMX6UL_CLK_ENET2_REF]->clk);
+
+ imx_register_uart_clocks();
}
CLK_OF_DECLARE(imx6ul, "fsl,imx6ul-ccm", imx6ul_clocks_init);
--
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
* Re: [PATCH 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
From: Adam Ford @ 2023-04-21 11:44 UTC (permalink / raw)
To: Marek Szyprowski
Cc: dri-devel, marex, aford, Rob Herring, Krzysztof Kozlowski,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Inki Dae, Jagan Teki, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, David Airlie, Daniel Vetter, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <28219b3d-e2cc-63b1-555b-c3845300f45a@samsung.com>
On Fri, Apr 21, 2023 at 6:25 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 15.04.2023 12:41, Adam Ford wrote:
> > Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> > having an entry in the device tree for samsung,pll-clock-frequency.
> >
> > Signed-off-by: Adam Ford <aford173@gmail.com>
>
> This one breaks DSI panel operation on my Exynos-based Trats, Trats2 and
> TM2e boards. I've didn't check the details, but probably something is
> missing in the dts to make it working properly. Surprisingly the display
> is still working fine on Arndale board with DSI TC358764 bridge.
Thanks for testing! I'm going to update this patch in V2 which will
use the device tree settings if they are present. If they are
missing, they will fetch the clock rate instead of failing. This way,
it should mitigate breaking your boards, but it will allow the imx8m
mini/nano/plus to eliminate hard-coding some device tree entries since
they can be fetched automatically.
adam
>
> > ---
> > drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 9fec32b44e05..73f0c3fbbdf5 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -1744,11 +1744,6 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
> > struct device_node *node = dev->of_node;
> > int ret;
> >
> > - ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> > - &dsi->pll_clk_rate);
> > - if (ret < 0)
> > - return ret;
> > -
> > ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> > &dsi->burst_clk_rate);
> > if (ret < 0)
> > @@ -1823,13 +1818,18 @@ int samsung_dsim_probe(struct platform_device *pdev)
> > if (IS_ERR(dsi->clks[i])) {
> > if (strcmp(clk_names[i], "sclk_mipi") == 0) {
> > dsi->clks[i] = devm_clk_get(dev, OLD_SCLK_MIPI_CLK_NAME);
> > - if (!IS_ERR(dsi->clks[i]))
> > + if (!IS_ERR(dsi->clks[i])) {
> > + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> > continue;
> > + }
> > }
> >
> > dev_info(dev, "failed to get the clock: %s\n", clk_names[i]);
> > return PTR_ERR(dsi->clks[i]);
> > }
> > +
> > + if (strcmp(clk_names[i], "sclk_mipi") == 0)
> > + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> > }
> >
> > dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
_______________________________________________
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 v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Cristian Marussi @ 2023-04-21 9:30 UTC (permalink / raw)
To: Oleksii Moisieiev
Cc: Peng Fan, sudeep.holla@arm.com, Linus Walleij,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <f73f39e2-81dd-4204-a3be-c5e7f5e54c1b@epam.com>
On Fri, Apr 21, 2023 at 08:40:47AM +0000, Oleksii Moisieiev wrote:
> Hi Peng Fan,
>
> On 17.04.23 05:55, Peng Fan wrote:
> >
> >
> > On 4/13/2023 6:04 AM, Cristian Marussi wrote:
> >> On Fri, Apr 07, 2023 at 10:18:27AM +0000, Oleksii Moisieiev wrote:
> >>> Implementation of the SCMI client driver, which implements
> >>> PINCTRL_PROTOCOL. This protocol has ID 19 and is described
> >>> in the latest DEN0056 document.
> >>
> >> Hi,
> >>
> >>> This protocol is part of the feature that was designed to
> >>> separate the pinctrl subsystem from the SCP firmware.
> >>> The idea is to separate communication of the pin control
> >>> subsystem with the hardware to SCP firmware
> >>> (or a similar system, such as ATF), which provides an interface
> >>> to give the OS ability to control the hardware through SCMI protocol.
> >>> This is a generic driver that implements SCMI protocol,
> >>> independent of the platform type.
> >>>
> >>> DEN0056 document:
> >>> https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!y2hR3PEGGxiPjVeXBcgGyV03DPDhzgUKR0uHvsTpiafKgBar8Egc6oOOs-IkFIquhSf-qBzltqEMyzRZHq8eC4g$
> >>> [developer[.]arm[.]com]
> >>>
> >>
> >> No need to specify all of this in the commit message, just a note that
> >> you are adding a new SCMIv3.2 Pincontrol protocol, highlighting anything
> >> that has been left out in this patch (if any) will be enough.
> >
> > Is it possible to extend the spec to support multilple uint32_t for PIN
> > CONFIG SET?
> >
> > With only one uint32_t could not satisfy i.MX requirement.
> >
> > Thanks,
> > Peng.
> >
> IIUC you are expecting to have an ability to set some kind of array of
> uint32_t config values to some specific ConfigType?
>
> I'm not sure if it's supported by pintctrl subsystem right now. I was
> unable to find an example in the existing device-tree pinctrl bindings.
> This makes me think that this kind of binding is OEM specific.
>
> Maybe it can be implemented by adding new IDs to OEM specific range
> (192-255) which is reserved for OEM specific units (See Table 23 of
> DEN0056E).
>
If I understood correctly the aim of Peng multi-valued request, I think
that even if Linux does not support using this kind of multiple valued
requests (as of now), if it is useful or required by some of the possibly
supported hardware, it should be described and allowed by the specification
and supported by the core SCMI protocol support at least, while the pinctrl
SCMI driver can ignore this and keep using a one-sized array protocol_ops
call internally (since it cannot do any different anyway as of now)
IOW I dont think we should model too strictly the SCMI spec against only
what the Linux pinctrl subsystem support today, since Linux it is just
really only one of the possible SCMI agents and Linux implementation itself
can possibly change: it is better to model the spec on the HW requirements
or the possible usage patterns across all the possibly participating agents.
As an example, for similar reasons, when the SCMI Voltage protocol was added
to the spec, at the very last minute, a change was made to the spec to allow
for negative voltages, even though the Linux regulator subsystem was not
and still is not supporting at all negative voltages as of now; so basically
the SCMI voltage protocol API now exposes a per-domain flag (negative_volts_allowed),
that allows any kind of voltage domain to be enumerated and handled at the SCMI
spec and core layer but that also allows any SCMI driver user, like the SCMI
Regulator driver, to decide on his own if negative voltages domains can be
supported: indeed the scmi-regulator driver just skips the initialization of
any voltage domain that is found to be describing negative voltages.
Here is a bit different, it is more of an optimization in the call path
than an HW difference, but I would follow the same approach: with the
SCMI spec and the core SCMI stack (the protocol) that supports a multi-uint32
call as a general case, if useful for some scenarios, and instead the SCMI
pinctrl driver that just ignores this possibility and keep using a single-value
array anyway....then, it will be up to the guys leveraging this multi-valued
call to come up with a way to use it on their systems, possibly maybe contributing
back to upstream any needed modification if general enough
(not sure about the details of how this multi-vals operation should be...we'll have
to discuss that about the spec all together I think.)
In any case, I would definitely NOT relegate such possibility to vendor space,
since it is something generic and, especially being just (as it seems to me) an
optimization on the call path at the end, it will just lead to uneeded duplication
of functionalities in the vendor implementation of stuff that it is already
very slightly differently supported by the standard.
...just my opinion anyway, I'll happily let other guys in this thread discuss and
decide about this :P
Thanks,
Cristian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] driver: soc: xilinx: use _safe loop iterator to avoid a use after free
From: Dan Carpenter @ 2023-04-21 10:44 UTC (permalink / raw)
To: Abhyuday Godhasara
Cc: Michal Simek, Rajan Vaja, Greg Kroah-Hartman, Tejas Patel,
linux-arm-kernel, linux-kernel, kernel-janitors
The hash_for_each_possible() loop dereferences "eve_data" to get the
next item on the list. However the loop frees eve_data so it leads to
a use after free. Use hash_for_each_possible_safe() instead.
Fixes: c7fdb2404f66 ("drivers: soc: xilinx: add xilinx event management driver")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
Found by static analysis and not tested.
drivers/soc/xilinx/xlnx_event_manager.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/xilinx/xlnx_event_manager.c b/drivers/soc/xilinx/xlnx_event_manager.c
index c76381899ef4..f9d9b82b562d 100644
--- a/drivers/soc/xilinx/xlnx_event_manager.c
+++ b/drivers/soc/xilinx/xlnx_event_manager.c
@@ -192,11 +192,12 @@ static int xlnx_remove_cb_for_suspend(event_cb_func_t cb_fun)
struct registered_event_data *eve_data;
struct agent_cb *cb_pos;
struct agent_cb *cb_next;
+ struct hlist_node *tmp;
is_need_to_unregister = false;
/* Check for existing entry in hash table for given cb_type */
- hash_for_each_possible(reg_driver_map, eve_data, hentry, PM_INIT_SUSPEND_CB) {
+ hash_for_each_possible_safe(reg_driver_map, eve_data, tmp, hentry, PM_INIT_SUSPEND_CB) {
if (eve_data->cb_type == PM_INIT_SUSPEND_CB) {
/* Delete the list of callback */
list_for_each_entry_safe(cb_pos, cb_next, &eve_data->cb_list_head, list) {
@@ -228,11 +229,12 @@ static int xlnx_remove_cb_for_notify_event(const u32 node_id, const u32 event,
u64 key = ((u64)node_id << 32U) | (u64)event;
struct agent_cb *cb_pos;
struct agent_cb *cb_next;
+ struct hlist_node *tmp;
is_need_to_unregister = false;
/* Check for existing entry in hash table for given key id */
- hash_for_each_possible(reg_driver_map, eve_data, hentry, key) {
+ hash_for_each_possible_safe(reg_driver_map, eve_data, tmp, hentry, key) {
if (eve_data->key == key) {
/* Delete the list of callback */
list_for_each_entry_safe(cb_pos, cb_next, &eve_data->cb_list_head, list) {
--
2.39.2
_______________________________________________
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 v10 2/2] i2c: aspeed: support ast2600 i2c new register mode driver
From: Ryan Chen @ 2023-04-21 2:01 UTC (permalink / raw)
To: Andi Shyti
Cc: jk@codeconstruct.com.au, Brendan Higgins, Benjamin Herrenschmidt,
Joel Stanley, Rob Herring, Krzysztof Kozlowski, Andrew Jeffery,
Philipp Zabel, Wolfram Sang, Andy Shevchenko,
linux-i2c@vger.kernel.org, Florian Fainelli, Jean Delvare,
William Zhang, Tyrone Ting, Tharun Kumar P, Conor Dooley,
Phil Edworthy, openbmc@lists.ozlabs.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <20230421000529.6awtnawqgbk5orcp@intel.intel>
Hello Andi,
>
> On Sat, Apr 15, 2023 at 09:28:48AM +0800, Ryan Chen wrote:
> > Add i2c new register mode driver to support AST2600 i2c new register
> > mode. AST2600 i2c controller have legacy and new register mode. The
> > new register mode have global register support 4 base clock for scl
> > clock selection, and new clock divider mode. The i2c new register mode
> > have separate register set to control i2c master and slave.
>
> This commit message is a bit messy, could you please write it more clear?
>
> [...]
>
The more statement is in cover letter.
https://patchwork.ozlabs.org/project/linux-aspeed/cover/20230415012848.1777768-1-ryan_chen@aspeedtech.com/
> > +static int ast2600_i2c_probe(struct platform_device *pdev) {
> > + struct device_node *np = pdev->dev.of_node;
> > + struct device *dev = &pdev->dev;
> > + struct ast2600_i2c_bus *i2c_bus;
> > + struct resource *res;
> > + u32 global_ctrl;
> > + int ret = 0;
> > +
> > + i2c_bus = devm_kzalloc(dev, sizeof(*i2c_bus), GFP_KERNEL);
> > + if (!i2c_bus)
> > + return -ENOMEM;
>
> Let's use dev_err_probe whenever possible, at least we keep a coherent style.
Will modify dev_err_probe to next patch
>
> [...]
>
> > + ret = devm_request_irq(dev, i2c_bus->irq, ast2600_i2c_bus_irq, 0,
> > + dev_name(dev), i2c_bus);
>
> isn't it better to use threaded irq? You have quite an elaborate irq handler, you
> may want to use a thread for it.
Thanks, but I would prefer to stick currently implement of the IRQ request. Thank you for your input.
>
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "Unable to request irq %d\n",
> > +i2c_bus->irq);
> > +
> > + if (of_property_read_bool(dev->of_node, "smbus-alert")) {
> > + i2c_bus->alert_enable = 1;
>
> true;
>
> alert_enable is boolean, make it bool.
Will modify dev_err_probe to next patch
>
> > + i2c_bus->ara = i2c_new_smbus_alert_device(&i2c_bus->adap,
> &i2c_bus->alert_data);
> > + if (!i2c_bus->ara)
> > + dev_warn(dev, "Failed to register ARA client\n");
> > +
> > + writel(AST2600_I2CM_PKT_DONE | AST2600_I2CM_BUS_RECOVER |
> AST2600_I2CM_SMBUS_ALT,
> > + i2c_bus->reg_base + AST2600_I2CM_IER);
> > + } else {
> > + i2c_bus->alert_enable = 0;
>
> false;
Will modify dev_err_probe to next patch
>
> I'm not going to review any further, please send the patch after you have run
> checkpatch.pl on it. Thanks!
Sure.
Thanks, your review.
Ryan Chen.
_______________________________________________
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/6] drm: bridge: samsung-dsim: Support multi-lane calculations
From: Adam Ford @ 2023-04-21 11:41 UTC (permalink / raw)
To: Marek Szyprowski
Cc: Lucas Stach, dri-devel, Krzysztof Kozlowski, aford,
Laurent Pinchart, Andrzej Hajda, Fabio Estevam, marex,
Robert Foss, David Airlie, Jernej Skrabec, Jagan Teki,
NXP Linux Team, devicetree, Daniel Vetter, Jonas Karlman,
Sascha Hauer, Inki Dae, Rob Herring, linux-arm-kernel,
Neil Armstrong, linux-kernel, Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <8cdb2f0d-f6a2-a04c-2cf4-c0762a47c050@samsung.com>
On Fri, Apr 21, 2023 at 6:28 AM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
>
> On 21.04.2023 10:40, Lucas Stach wrote:
> > Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
> >> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >>> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
> >>>> On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >>>>> Hi Adam,
> >>>>>
> >>>>> Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
> >>>>>> On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
> >>>>>>> On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
> >>>>>>>> Hi Adam,
> >>>>>>>>
> >>>>>>>> Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> >>>>>>>>> If there is more than one lane, the HFP, HBP, and HSA is calculated in
> >>>>>>>>> bytes/pixel, then they are divided amongst the different lanes with some
> >>>>>>>>> additional overhead. This is necessary to achieve higher resolutions while
> >>>>>>>>> keeping the pixel clocks lower as the number of lanes increase.
> >>>>>>>>>
> >>>>>>>> In the testing I did to come up with my patch "drm: bridge: samsung-
> >>>>>>>> dsim: fix blanking packet size calculation" the number of lanes didn't
> >>>>>>>> make any difference. My testing might be flawed, as I could only
> >>>>>>>> measure the blanking after translation from MIPI DSI to DPI, so I'm
> >>>>>>>> interested to know what others did here. How did you validate the
> >>>>>>>> blanking with your patch? Would you have a chance to test my patch and
> >>>>>>>> see if it works or breaks in your setup?
> >>>>>> Lucas,
> >>>>>>
> >>>>>> I tried your patch instead of mine. Yours is dependent on the
> >>>>>> hs_clock being always set to the burst clock which is configured by
> >>>>>> the device tree. I unrolled a bit of my stuff and replaced it with
> >>>>>> yours. It worked at 1080p, but when I tried a few other resolutions,
> >>>>>> they did not work. I assume it's because the DSI clock is fixed and
> >>>>>> not changing based on the pixel clock. In the version I did, I only
> >>>>>> did that math when the lanes were > 1. In your patch, you divide by 8,
> >>>>>> and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
> >>>>>> that just in case the bpp ever changes from 8. Overall, I think our
> >>>>>> patches basically do the same thing.
> >>>>> The calculations in your and my patch are quite different. I'm not
> >>>>> taking into account the number of lanes or the MIPI format. I'm basing
> >> I was taking the number of lanes into account in order to calculate
> >> the clock rate, since 4-lanes can run slower.
> >>
> > Ah that makes sense if you aren't running at full clock burst clock
> > rate.
> >
> >>>> I was looking more at the division by 8 and the overhead correction of 6.
> >>>> This number 6 also appears in the NXP downstream kernel [1]. I know
> >>>> Marek V had some concerns about that.
> >>>>
> >>> Yea, I don't fully remember the details about the overhead. Need to
> >>> page that back in. The division by 8 in my patch is just to get from
> >>> the bit to a byte clock, nothing to do with the MIPI format bits per
> >>> channel or something like that.
> >>>
> >>>>> the blanking size purely on the ratio between MIPI DSI byte clock and
> >>>>> the DPI interface clock. It's quite counter-intuitive that the host
> >>>>> would scale the blanking to the number of lanes automatically, but
> >>>>> still require the MIPI packet offset removed, but that's what my
> >>>>> measurements showed to produce the correct blanking after translation
> >>>>> to DPI by the TC358767 bridge chip.
> >>>> How many lanes is your DSI interface using?
> >>>>
> >>> When I did the measurements to come up with the patch, I varied the
> >>> number of lanes between 1 and 4. Different number of lanes didn't make
> >>> a difference. In fact trying to compensate for the number of lanes when
> >>> calculating the blanking size to program into the controller lead to
> >>> wildly wrong blanking on the DPI side of the external bridge.
> >>>
> >>>>> If you dynamically scale the HS clock, then you would need to input the
> >>>>> real used HS clock to the calculation in my patch, instead of the fixed
> >>>>> burst mode rate.
> >>>> I think what you're saying makes sense.
> >>>>
> >>>> The code I originally modeled this from was from the NXP downstream
> >>>> kernel where they define the calculation as being in words [2]. I am
> >>>> not saying the NXP code is perfect, but the NXP code works. With this
> >>>> series, my monitors are able to sync a bunch of different resolutions
> >>>> from 1080p down to 640x480 and a bunch in between with various refresh
> >>>> rates too. That was the goal of this series.
> >>>>
> >>>> Instead of just using your patch as-is, I will adapt yours to use the
> >>>> scaled clock to see how it behaves and get back to you.
> >>>>
> >>> Thanks, that would be very much appreciated.
> >> Lucas,
> >>
> >> I took your patch and added a dsi state variable named "hs_clock" to
> >> keep track of the output of samsung_dsim_set_pll which should be the
> >> active high-speed clock.
> >>
> >> I then replaced one line in your code to reference the hs_clock
> >> instead of the burst clock:
> >>
> >> @@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
> >> samsung_dsim *dsi)
> >> u32 reg;
> >>
> >> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> >> - int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
> >> + int byte_clk_khz = dsi->hs_clock / 1000 / 8;
> >> int hfp = (m->hsync_start - m->hdisplay) *
> >> byte_clk_khz / m->clock;
> >>
> >> With that change, your patch works with the rest of my code, and I
> >> think it's easier to read, and it doesn't involve recalculating the
> >> clock speed each time since it's cached. If you're OK with that, I'll
> >> incorporate your code into V2 of my series, and I'll apply my changes
> >> as a subsequent patch. I hope to be able to send out V2 this weekend.
> >>
> > That's good to hear! Seems we are converging here. Feel free to pick up
> > the patch, that's also easier for me as I don't have to resend with CC
> > fixed.
> >
> >> I would be curious to know frm Marek Szyprowski what the impact is on
> >> the Samsung devices, if any.
> >>
> > Since I messed up the list CC you also couldn't see his reply to my
> > patch:
> >
> > | Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > |
> > | Works fine on the Exynos based boards I have in my test farm.
>
> I didn't follow this discussion, I'm a bit busy with other stuff. I've
> just tested this series and patch #3 break Exynos based board. If you
> want me to test anything else (might be a work-in-progress code), just
> let me know by the separate mail.
That's ok. I'm going to drop my patch in favor of Lucas' patch, since
you've already tested his, and it looks cleaner than mine. Thanks for
your willingness to test. That really helps us move forward without
breaking your stuff.
adam
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R&D Institute Poland
>
_______________________________________________
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] firmware: arm_scmi: Fix incorrect alloc_workqueue() invocation
From: Cristian Marussi @ 2023-04-21 9:38 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Tejun Heo, linux-arm-kernel, linux-kernel, kernel-team
In-Reply-To: <20230421092742.jjr4gnkswj22yt76@bogus>
On Fri, Apr 21, 2023 at 10:27:42AM +0100, Sudeep Holla wrote:
> On Fri, Apr 21, 2023 at 09:46:11AM +0100, Cristian Marussi wrote:
> > On Thu, Apr 20, 2023 at 09:33:49AM -1000, Tejun Heo wrote:
> > > scmi_xfer_raw_worker_init() is specifying a flag, WQ_SYSFS, as @max_active.
> > > Fix it by or'ing WQ_SYSFS into @flags so that it actually enables sysfs
> > > interface and using 0 for @max_active for the default setting.
> > >
>
> Thanks, good catch, very hard to notice.
Indeed :<
>
> >
> > Hi Tejun,
> >
> > my bad I messed up the params in the call.
> >
>
> Hi Cristian,
>
> I think it deserves the fixes tag, right ?
>
> Fixes: 3c3d818a9317 ("firmware: arm_scmi: Add core raw transmission support")
>
I though so, but as usual I am not sure what to do when we are fixing something
in the middle of a cycle... Raw support went in v6.3-rc1 and we are now in
v6.3-rc7, so if you want to pick this up now (as it seems the case) it will fix
the above yes, but it is anyway still on an unreleased kernel...so nothing really
to have to apply on any early stable kernels...buh..I dont know what is the rule,
but the Fix tag seems harmless ... so why not :D
Thanks,
Cristian
_______________________________________________
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 V5 2/3] soc: qcom: boot_stat: Add Driver Support for Boot Stats
From: Souradeep Chowdhury @ 2023-04-21 10:20 UTC (permalink / raw)
To: Bryan O'Donoghue, Andy Gross, Konrad Dybcio,
Krzysztof Kozlowski, Bjorn Andersson, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, devicetree,
Sibi Sankar, Rajendra Nayak
In-Reply-To: <b66290c6-5c1b-70a4-84e3-d65b139d1460@nexus-software.ie>
On 4/21/2023 3:32 PM, Bryan O'Donoghue wrote:
> On 18/04/2023 07:46, Souradeep Chowdhury wrote:
>> All of Qualcomm's proprietary Android boot-loaders capture boot time
>> stats, like the time when the bootloader started execution and at what
>> point the bootloader handed over control to the kernel etc. in the IMEM
>> region. This information is captured in a specific format by this driver
>> by mapping a structure to the IMEM memory region and then accessing the
>> members of the structure to show the information within debugfs file.
>> This information is useful in verifying if the existing boot KPIs have
>> regressed or not. The information is shown in milliseconds, a sample
>> log from sm8450(waipio) device is as follows:-
>>
>> /sys/kernel/debug/146aa6b0.boot_stats # cat abl_time
>> 17898 ms
>> /sys/kernel/debug/146aa6b0.boot_stats # cat pre_abl_time
>> 2879 ms
>>
>> The Module Power Manager(MPM) sleep counter starts ticking at the PBL
>> stage and the timestamp generated by the sleep counter is logged by
>> the Qualcomm proprietary bootloader(ABL) at two points-> First when it
>> starts execution which is logged here as "pre_abl_time" and the second
>> when it is about to load the kernel logged as "abl_time". Documentation
>> details are also added in
>> Documentation/ABI/testing/debugfs-driver-bootstat
>>
>> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> ---
>> Documentation/ABI/testing/debugfs-driver-bootstat | 17 ++++
>> drivers/soc/qcom/Kconfig | 9 ++
>> drivers/soc/qcom/Makefile | 1 +
>> drivers/soc/qcom/boot_stats.c | 101
>> ++++++++++++++++++++++
>> 4 files changed, 128 insertions(+)
>> create mode 100644 Documentation/ABI/testing/debugfs-driver-bootstat
>> create mode 100644 drivers/soc/qcom/boot_stats.c
>>
>> diff --git a/Documentation/ABI/testing/debugfs-driver-bootstat
>> b/Documentation/ABI/testing/debugfs-driver-bootstat
>> new file mode 100644
>> index 0000000..2543029
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/debugfs-driver-bootstat
>> @@ -0,0 +1,17 @@
>> +What: /sys/kernel/debug/...stats/pre_abl_time
>> +Date: April 2023
>> +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> +Description:
>> + This file is used to read the KPI value pre abl time.
>> + It shows the time in milliseconds from the starting
>> + point of PBL to the point when the control shifted
>> + to ABL(Qualcomm proprietary bootloader).
>> +
>> +What: /sys/kernel/debug/...stats/abl_time
>> +Date: April 2023
>> +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
>> +Description:
>> + This file is used to read the KPI value abl time.
>> + It show the duration in milliseconds from the
>> + time control switched to ABL to the point when
>> + the linux kernel started getting loaded.
>> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
>> index a8f2830..0d2cbd3 100644
>> --- a/drivers/soc/qcom/Kconfig
>> +++ b/drivers/soc/qcom/Kconfig
>> @@ -16,6 +16,15 @@ config QCOM_AOSS_QMP
>> subsystems as well as controlling the debug clocks exposed by
>> the Always On
>> Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
>> +config QCOM_BOOTSTAT
>> + tristate "Qualcomm Technologies, Boot Stat driver"
>> + depends on ARCH_QCOM || COMPILE_TEST
>> + help
>> + This option enables driver support for boot stats. Boot stat
>> driver logs
>> + the kernel bootloader information by accessing the imem region.
>> These
>> + information are exposed in the form of debugfs files. This is
>> used to
>> + determine if there is any regression in boot timings.
>> +
>> config QCOM_COMMAND_DB
>> tristate "Qualcomm Command DB"
>> depends on ARCH_QCOM || COMPILE_TEST
>> diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
>> index 6e88da8..bdaa41a 100644
>> --- a/drivers/soc/qcom/Makefile
>> +++ b/drivers/soc/qcom/Makefile
>> @@ -1,6 +1,7 @@
>> # SPDX-License-Identifier: GPL-2.0
>> CFLAGS_rpmh-rsc.o := -I$(src)
>> obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
>> +obj-$(CONFIG_QCOM_BOOTSTAT) += boot_stats.o
>> obj-$(CONFIG_QCOM_GENI_SE) += qcom-geni-se.o
>> obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
>> obj-$(CONFIG_QCOM_CPR) += cpr.o
>> diff --git a/drivers/soc/qcom/boot_stats.c
>> b/drivers/soc/qcom/boot_stats.c
>> new file mode 100644
>> index 0000000..7ae002b
>> --- /dev/null
>> +++ b/drivers/soc/qcom/boot_stats.c
>> @@ -0,0 +1,101 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2013-2019, 2021 The Linux Foundation. All rights
>> reserved.
>> + * Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights
>> reserved.
>> + */
>> +
>> +#include <linux/debugfs.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/init.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/platform_device.h>
>> +
>> +#define TO_MS(timestamp) ((timestamp * 1000) / 32768)
>
> Is this related to the sleep_clk, if not, what is the refrence clock ?
>
> Is this value constant across different SoCs i.e. will this run and
> produce meaningful results on an msm8916 ?
This is the sleep counter of MPM(Module Power Manager), yes, it will
produce meaningful results on almost all QCOM SoCs including msm8916.
>
> ---
> bod
_______________________________________________
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 v6] net: stmmac:fix system hang when setting up tag_8021q VLAN for DSA ports
From: patchwork-bot+netdevbpf @ 2023-04-21 10:50 UTC (permalink / raw)
To: Yan Wang
Cc: davem, edumazet, pabeni, kuba, mcoquelin.stm32, peppe.cavallaro,
alexandre.torgue, joabreu, qiangqing.zhang, netdev, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <KL1PR01MB544874DAEE749710E67727A2E6629@KL1PR01MB5448.apcprd01.prod.exchangelabs.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by David S. Miller <davem@davemloft.net>:
On Wed, 19 Apr 2023 22:13:46 +0800 you wrote:
> The system hang because of dsa_tag_8021q_port_setup()->
> stmmac_vlan_rx_add_vid().
>
> I found in stmmac_drv_probe() that cailing pm_runtime_put()
> disabled the clock.
>
> First, when the kernel is compiled with CONFIG_PM=y,The stmmac's
> resume/suspend is active.
>
> [...]
Here is the summary with links:
- [net-next,v6] net: stmmac:fix system hang when setting up tag_8021q VLAN for DSA ports
https://git.kernel.org/netdev/net-next/c/35226750f7ab
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] KVM/arm64 updates for v6.4
From: Marc Zyngier @ 2023-04-21 10:40 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Christoffer Dall, Colin Ian King, Colton Lewis, Jeremy Linton,
Mark Brown, Oliver Upton, Reiji Watanabe, Ryan Roberts,
Sean Christopherson, Suzuki K Poulose, James Morse, Zenghui Yu,
kvmarm, kvm, linux-arm-kernel
Hi Paolo,
Here's the initial set of changes for KVM/arm64. A bunch of
infrastructure changes this time around, with two new user
visible changes (hypercall forwarding to userspace, global counter
offset) and a large set of locking inversion fixes.
The remaining of the patches contain the NV timer emulation code, and
a small set of less important fixes/improvements.
Please pull,
M.
The following changes since commit 197b6b60ae7bc51dd0814953c562833143b292aa:
Linux 6.3-rc4 (2023-03-26 14:40:20 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-6.4
for you to fetch changes up to 36fe1b29b3cae48f781011abd5a0b9e938f5b35f:
Merge branch kvm-arm64/spec-ptw into kvmarm-master/next (2023-04-21 09:44:58 +0100)
----------------------------------------------------------------
KVM/arm64 updates for 6.4
- Numerous fixes for the pathological lock inversion issue that
plagued KVM/arm64 since... forever.
- New framework allowing SMCCC-compliant hypercalls to be forwarded
to userspace, hopefully paving the way for some more features
being moved to VMMs rather than be implemented in the kernel.
- Large rework of the timer code to allow a VM-wide offset to be
applied to both virtual and physical counters as well as a
per-timer, per-vcpu offset that complements the global one.
This last part allows the NV timer code to be implemented on
top.
- A small set of fixes to make sure that we don't change anything
affecting the EL1&0 translation regime just after having having
taken an exception to EL2 until we have executed a DSB. This
ensures that speculative walks started in EL1&0 have completed.
- The usual selftest fixes and improvements.
----------------------------------------------------------------
Colin Ian King (1):
KVM: selftests: Fix spelling mistake "KVM_HYPERCAL_EXIT_SMC" -> "KVM_HYPERCALL_EXIT_SMC"
Marc Zyngier (33):
KVM: arm64: timers: Use a per-vcpu, per-timer accumulator for fractional ns
arm64: Add CNTPOFF_EL2 register definition
arm64: Add HAS_ECV_CNTPOFF capability
KVM: arm64: timers: Use CNTPOFF_EL2 to offset the physical timer
KVM: arm64: timers: Allow physical offset without CNTPOFF_EL2
KVM: arm64: Expose {un,}lock_all_vcpus() to the rest of KVM
KVM: arm64: timers: Allow userspace to set the global counter offset
KVM: arm64: timers: Allow save/restoring of the physical timer
KVM: arm64: timers: Rationalise per-vcpu timer init
KVM: arm64: timers: Abstract per-timer IRQ access
KVM: arm64: timers: Move the timer IRQs into arch_timer_vm_data
KVM: arm64: Elide kern_hyp_va() in VHE-specific parts of the hypervisor
KVM: arm64: timers: Fast-track CNTPCT_EL0 trap handling
KVM: arm64: timers: Abstract the number of valid timers per vcpu
KVM: arm64: Document KVM_ARM_SET_CNT_OFFSETS and co
KVM: arm64: nv: timers: Add a per-timer, per-vcpu offset
KVM: arm64: nv: timers: Support hyp timer emulation
KVM: arm64: selftests: Add physical timer registers to the sysreg list
KVM: arm64: selftests: Deal with spurious timer interrupts
KVM: arm64: selftests: Augment existing timer test to handle variable offset
KVM: arm64: Expose SMC/HVC width to userspace
KVM: arm64: nvhe: Synchronise with page table walker on vcpu run
KVM: arm64: Handle 32bit CNTPCTSS traps
KVM: arm64: nvhe: Synchronise with page table walker on TLBI
KVM: arm64: pkvm: Document the side effects of kvm_flush_dcache_to_poc()
KVM: arm64: vhe: Synchronise with page table walker on MMU update
KVM: arm64: vhe: Drop extra isb() on guest exit
Merge branch kvm-arm64/lock-inversion into kvmarm-master/next
Merge branch kvm-arm64/timer-vm-offsets into kvmarm-master/next
Merge branch kvm-arm64/selftest/lpa into kvmarm-master/next
Merge branch kvm-arm64/selftest/misc-6.4 into kvmarm-master/next
Merge branch kvm-arm64/smccc-filtering into kvmarm-master/next
Merge branch kvm-arm64/spec-ptw into kvmarm-master/next
Mark Brown (1):
KVM: selftests: Comment newly defined aarch64 ID registers
Oliver Upton (20):
KVM: arm64: Avoid vcpu->mutex v. kvm->lock inversion in CPU_ON
KVM: arm64: Avoid lock inversion when setting the VM register width
KVM: arm64: Use config_lock to protect data ordered against KVM_RUN
KVM: arm64: Use config_lock to protect vgic state
KVM: x86: Redefine 'longmode' as a flag for KVM_EXIT_HYPERCALL
KVM: arm64: Add a helper to check if a VM has ran once
KVM: arm64: Add vm fd device attribute accessors
KVM: arm64: Rename SMC/HVC call handler to reflect reality
KVM: arm64: Start handling SMCs from EL1
KVM: arm64: Refactor hvc filtering to support different actions
KVM: arm64: Use a maple tree to represent the SMCCC filter
KVM: arm64: Add support for KVM_EXIT_HYPERCALL
KVM: arm64: Introduce support for userspace SMCCC filtering
KVM: arm64: Return NOT_SUPPORTED to guest for unknown PSCI version
KVM: arm64: Let errors from SMCCC emulation to reach userspace
KVM: selftests: Add a helper for SMCCC calls with SMC instruction
KVM: selftests: Add test for SMCCC filter
KVM: arm64: Prevent userspace from handling SMC64 arch range
KVM: arm64: Test that SMC64 arch calls are reserved
KVM: arm64: vgic: Don't acquire its_lock before config_lock
Reiji Watanabe (2):
KVM: arm64: Acquire mp_state_lock in kvm_arch_vcpu_ioctl_vcpu_init()
KVM: arm64: Have kvm_psci_vcpu_on() use WRITE_ONCE() to update mp_state
Ryan Roberts (3):
KVM: selftests: Fixup config fragment for access_tracking_perf_test
KVM: selftests: arm64: Fix pte encode/decode for PA bits > 48
KVM: selftests: arm64: Fix ttbr0_el1 encoding for PA bits > 48
Documentation/virt/kvm/api.rst | 71 ++-
Documentation/virt/kvm/devices/vm.rst | 79 +++
arch/arm64/include/asm/kvm_host.h | 25 +-
arch/arm64/include/asm/kvm_mmu.h | 4 +
arch/arm64/include/asm/sysreg.h | 3 +
arch/arm64/include/uapi/asm/kvm.h | 36 ++
arch/arm64/kernel/cpufeature.c | 11 +
arch/arm64/kvm/arch_timer.c | 550 ++++++++++++++++-----
arch/arm64/kvm/arm.c | 147 +++++-
arch/arm64/kvm/guest.c | 31 +-
arch/arm64/kvm/handle_exit.c | 36 +-
arch/arm64/kvm/hyp/include/hyp/switch.h | 53 ++
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 2 -
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 7 +
arch/arm64/kvm/hyp/nvhe/switch.c | 18 +
arch/arm64/kvm/hyp/nvhe/timer-sr.c | 18 +-
arch/arm64/kvm/hyp/nvhe/tlb.c | 38 +-
arch/arm64/kvm/hyp/vhe/switch.c | 7 +-
arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 12 +
arch/arm64/kvm/hypercalls.c | 189 ++++++-
arch/arm64/kvm/pmu-emul.c | 25 +-
arch/arm64/kvm/psci.c | 37 +-
arch/arm64/kvm/reset.c | 15 +-
arch/arm64/kvm/sys_regs.c | 10 +
arch/arm64/kvm/trace_arm.h | 6 +-
arch/arm64/kvm/vgic/vgic-debug.c | 8 +-
arch/arm64/kvm/vgic/vgic-init.c | 36 +-
arch/arm64/kvm/vgic/vgic-its.c | 33 +-
arch/arm64/kvm/vgic/vgic-kvm-device.c | 85 ++--
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4 +-
arch/arm64/kvm/vgic/vgic-mmio.c | 12 +-
arch/arm64/kvm/vgic/vgic-v4.c | 11 +-
arch/arm64/kvm/vgic/vgic.c | 27 +-
arch/arm64/kvm/vgic/vgic.h | 3 -
arch/arm64/tools/cpucaps | 1 +
arch/arm64/tools/sysreg | 4 +
arch/x86/include/asm/kvm_host.h | 7 +
arch/x86/include/uapi/asm/kvm.h | 3 +
arch/x86/kvm/x86.c | 6 +-
include/clocksource/arm_arch_timer.h | 1 +
include/kvm/arm_arch_timer.h | 34 +-
include/kvm/arm_hypercalls.h | 6 +-
include/kvm/arm_vgic.h | 1 +
include/uapi/linux/kvm.h | 12 +-
tools/testing/selftests/kvm/Makefile | 1 +
tools/testing/selftests/kvm/aarch64/arch_timer.c | 56 ++-
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 15 +-
tools/testing/selftests/kvm/aarch64/smccc_filter.c | 268 ++++++++++
tools/testing/selftests/kvm/config | 1 +
.../selftests/kvm/include/aarch64/processor.h | 13 +
.../testing/selftests/kvm/lib/aarch64/processor.c | 91 ++--
51 files changed, 1759 insertions(+), 410 deletions(-)
create mode 100644 tools/testing/selftests/kvm/aarch64/smccc_filter.c
_______________________________________________
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: mediatek: mt8192-asurada-hayato: Enable Bluetooth
From: Chen-Yu Tsai @ 2023-04-21 11:03 UTC (permalink / raw)
To: Matthias Brugger, AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, Nícolas F . R . A . Prado, devicetree,
linux-kernel, linux-mediatek, linux-arm-kernel, Rob Herring,
Krzysztof Kozlowski
Hayato's Realtek WiFi/BT module has it's Bluetooth function wired to
UART1.
Add and enable the relevant device nodes for it.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../dts/mediatek/mt8192-asurada-hayato-r1.dts | 80 +++++++++++++++++++
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts b/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts
index 43a823990a92..6a7d7870525b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dts
@@ -40,9 +40,89 @@ CROS_STD_MAIN_KEYMAP
>;
};
+&pio {
+ bt_pins: bt-pins {
+ bt_kill: pins-bt-kill {
+ pinmux = <PINMUX_GPIO144__FUNC_GPIO144>; /* BT_KILL_L */
+ output-low;
+ };
+
+ bt_wake: pins-bt-wake {
+ pinmux = <PINMUX_GPIO22__FUNC_GPIO22>; /* bt to wake ap */
+ bias-pull-up;
+ };
+
+ ap_wake_bt: pins-ap-wake-bt {
+ pinmux = <PINMUX_GPIO168__FUNC_GPIO168>; /* AP_WAKE_BT_H */
+ output-low;
+ };
+ };
+
+ uart1_pins: uart1-pins {
+ pins-rx {
+ pinmux = <PINMUX_GPIO94__FUNC_URXD1>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-tx {
+ pinmux = <PINMUX_GPIO95__FUNC_UTXD1>;
+ };
+
+ pins-cts {
+ pinmux = <PINMUX_GPIO166__FUNC_UCTS1>;
+ input-enable;
+ };
+
+ pins-rts {
+ pinmux = <PINMUX_GPIO167__FUNC_URTS1>;
+ output-enable;
+ };
+ };
+
+ uart1_pins_sleep: uart1-pins-sleep {
+ pins-rx {
+ pinmux = <PINMUX_GPIO94__FUNC_GPIO94>;
+ input-enable;
+ bias-pull-up;
+ };
+ pins-tx {
+ pinmux = <PINMUX_GPIO95__FUNC_UTXD1>;
+ };
+ pins-cts {
+ pinmux = <PINMUX_GPIO166__FUNC_UCTS1>;
+ input-enable;
+ };
+ pins-rts {
+ pinmux = <PINMUX_GPIO167__FUNC_URTS1>;
+ output-enable;
+ };
+ };
+};
+
&touchscreen {
compatible = "hid-over-i2c";
post-power-on-delay-ms = <10>;
hid-descr-addr = <0x0001>;
vdd-supply = <&pp3300_u>;
};
+
+&uart1 {
+ status = "okay";
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&uart1_pins>;
+ pinctrl-1 = <&uart1_pins_sleep>;
+ /delete-property/ interrupts;
+ interrupts-extended = <&gic GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>,
+ <&pio 94 IRQ_TYPE_EDGE_FALLING>;
+
+ bluetooth: bluetooth {
+ compatible = "realtek,rtl8822cs-bt";
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_pins>;
+
+ enable-gpios = <&pio 144 GPIO_ACTIVE_HIGH>;
+ device-wake-gpios = <&pio 168 GPIO_ACTIVE_HIGH>;
+ host-wake-gpios = <&pio 22 GPIO_ACTIVE_LOW>;
+ };
+};
--
2.40.0.634.g4ca3ef3211-goog
_______________________________________________
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] coresight: Fix signedness bug in tmc_etr_buf_insert_barrier_packet()
From: Dan Carpenter @ 2023-04-21 10:42 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Mike Leach, Leo Yan, Alexander Shishkin, Mathieu Poirier,
Greg Kroah-Hartman, coresight, linux-arm-kernel, kernel-janitors
This code generates a Smatch warning:
drivers/hwtracing/coresight/coresight-tmc-etr.c:947 tmc_etr_buf_insert_barrier_packet()
error: uninitialized symbol 'bufp'.
The problem is that if tmc_sg_table_get_data() returns -EINVAL, then
when we test if "len < CORESIGHT_BARRIER_PKT_SIZE", the negative "len"
value is type promoted to a high unsigned long value which is greater
than CORESIGHT_BARRIER_PKT_SIZE. Fix this bug by adding an explicit
check for error codes.
Fixes: 75f4e3619fe2 ("coresight: tmc-etr: Add transparent buffer management")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
drivers/hwtracing/coresight/coresight-tmc-etr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hwtracing/coresight/coresight-tmc-etr.c b/drivers/hwtracing/coresight/coresight-tmc-etr.c
index 918d461fcf4a..eaa296ced167 100644
--- a/drivers/hwtracing/coresight/coresight-tmc-etr.c
+++ b/drivers/hwtracing/coresight/coresight-tmc-etr.c
@@ -942,7 +942,7 @@ tmc_etr_buf_insert_barrier_packet(struct etr_buf *etr_buf, u64 offset)
len = tmc_etr_buf_get_data(etr_buf, offset,
CORESIGHT_BARRIER_PKT_SIZE, &bufp);
- if (WARN_ON(len < CORESIGHT_BARRIER_PKT_SIZE))
+ if (WARN_ON(len < 0 || len < CORESIGHT_BARRIER_PKT_SIZE))
return -EINVAL;
coresight_insert_barrier_packet(bufp);
return offset + CORESIGHT_BARRIER_PKT_SIZE;
--
2.39.2
_______________________________________________
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 2/7] ASoC: mediatek: mt8188: complete set_tdm_slot function
From: Trevor Wu @ 2023-04-21 10:09 UTC (permalink / raw)
To: broonie, lgirdwood, tiwai, perex, robh+dt, krzysztof.kozlowski+dt,
matthias.bgg, angelogioacchino.delregno
Cc: trevor.wu, alsa-devel, linux-mediatek, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20230421100905.28045-1-trevor.wu@mediatek.com>
User can configures slot number of TDM mode via set_tdm_slot callback.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
---
sound/soc/mediatek/mt8188/mt8188-dai-etdm.c | 21 ++++++++++++++++++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c b/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
index 7a37752d4244..fddecf5bf7c6 100644
--- a/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
+++ b/sound/soc/mediatek/mt8188/mt8188-dai-etdm.c
@@ -1909,6 +1909,10 @@ static int mtk_dai_etdm_hw_params(struct snd_pcm_substream *substream,
if (!is_valid_etdm_dai(mst_dai_id))
return -EINVAL;
+ mst_etdm_data = afe_priv->dai_priv[mst_dai_id];
+ if (mst_etdm_data->slots)
+ channels = mst_etdm_data->slots;
+
ret = mtk_dai_etdm_mclk_configure(afe, mst_dai_id);
if (ret)
return ret;
@@ -1918,7 +1922,6 @@ static int mtk_dai_etdm_hw_params(struct snd_pcm_substream *substream,
if (ret)
return ret;
- mst_etdm_data = afe_priv->dai_priv[mst_dai_id];
for (i = 0; i < mst_etdm_data->cowork_slv_count; i++) {
slv_dai_id = mst_etdm_data->cowork_slv_id[i];
ret = mtk_dai_etdm_configure(afe, rate, channels,
@@ -1931,6 +1934,12 @@ static int mtk_dai_etdm_hw_params(struct snd_pcm_substream *substream,
return ret;
}
} else {
+ if (!is_valid_etdm_dai(dai->id))
+ return -EINVAL;
+ mst_etdm_data = afe_priv->dai_priv[dai->id];
+ if (mst_etdm_data->slots)
+ channels = mst_etdm_data->slots;
+
ret = mtk_dai_etdm_mclk_configure(afe, dai->id);
if (ret)
return ret;
@@ -2073,10 +2082,16 @@ static int mtk_dai_etdm_set_tdm_slot(struct snd_soc_dai *dai,
struct mtk_base_afe *afe = snd_soc_dai_get_drvdata(dai);
struct mt8188_afe_private *afe_priv = afe->platform_priv;
struct mtk_dai_etdm_priv *etdm_data;
+ int dai_id;
- if (!is_valid_etdm_dai(dai->id))
+ if (is_cowork_mode(dai))
+ dai_id = get_etdm_cowork_master_id(dai);
+ else
+ dai_id = dai->id;
+
+ if (!is_valid_etdm_dai(dai_id))
return -EINVAL;
- etdm_data = afe_priv->dai_priv[dai->id];
+ etdm_data = afe_priv->dai_priv[dai_id];
dev_dbg(dai->dev, "%s id %d slot_width %d\n",
__func__, dai->id, slot_width);
--
2.18.0
_______________________________________________
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 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations
From: Marek Szyprowski @ 2023-04-21 11:28 UTC (permalink / raw)
To: Lucas Stach, Adam Ford
Cc: dri-devel, Krzysztof Kozlowski, aford, Laurent Pinchart,
Andrzej Hajda, Fabio Estevam, marex, Robert Foss, David Airlie,
Jernej Skrabec, Jagan Teki, NXP Linux Team, devicetree,
Daniel Vetter, Jonas Karlman, Sascha Hauer, Inki Dae, Rob Herring,
linux-arm-kernel, Neil Armstrong, linux-kernel,
Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <56a805b4a74f620f7948f57d416b135effb6e52d.camel@pengutronix.de>
On 21.04.2023 10:40, Lucas Stach wrote:
> Am Donnerstag, dem 20.04.2023 um 16:51 -0500 schrieb Adam Ford:
>> On Thu, Apr 20, 2023 at 8:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>>> Am Donnerstag, dem 20.04.2023 um 08:24 -0500 schrieb Adam Ford:
>>>> On Thu, Apr 20, 2023 at 8:06 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>>>>> Hi Adam,
>>>>>
>>>>> Am Mittwoch, dem 19.04.2023 um 05:47 -0500 schrieb Adam Ford:
>>>>>> On Mon, Apr 17, 2023 at 6:55 AM Adam Ford <aford173@gmail.com> wrote:
>>>>>>> On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>>>>>>>> Hi Adam,
>>>>>>>>
>>>>>>>> Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
>>>>>>>>> If there is more than one lane, the HFP, HBP, and HSA is calculated in
>>>>>>>>> bytes/pixel, then they are divided amongst the different lanes with some
>>>>>>>>> additional overhead. This is necessary to achieve higher resolutions while
>>>>>>>>> keeping the pixel clocks lower as the number of lanes increase.
>>>>>>>>>
>>>>>>>> In the testing I did to come up with my patch "drm: bridge: samsung-
>>>>>>>> dsim: fix blanking packet size calculation" the number of lanes didn't
>>>>>>>> make any difference. My testing might be flawed, as I could only
>>>>>>>> measure the blanking after translation from MIPI DSI to DPI, so I'm
>>>>>>>> interested to know what others did here. How did you validate the
>>>>>>>> blanking with your patch? Would you have a chance to test my patch and
>>>>>>>> see if it works or breaks in your setup?
>>>>>> Lucas,
>>>>>>
>>>>>> I tried your patch instead of mine. Yours is dependent on the
>>>>>> hs_clock being always set to the burst clock which is configured by
>>>>>> the device tree. I unrolled a bit of my stuff and replaced it with
>>>>>> yours. It worked at 1080p, but when I tried a few other resolutions,
>>>>>> they did not work. I assume it's because the DSI clock is fixed and
>>>>>> not changing based on the pixel clock. In the version I did, I only
>>>>>> did that math when the lanes were > 1. In your patch, you divide by 8,
>>>>>> and in mine, I fetch the bits-per-pixel (which is 8) and I divide by
>>>>>> that just in case the bpp ever changes from 8. Overall, I think our
>>>>>> patches basically do the same thing.
>>>>> The calculations in your and my patch are quite different. I'm not
>>>>> taking into account the number of lanes or the MIPI format. I'm basing
>> I was taking the number of lanes into account in order to calculate
>> the clock rate, since 4-lanes can run slower.
>>
> Ah that makes sense if you aren't running at full clock burst clock
> rate.
>
>>>> I was looking more at the division by 8 and the overhead correction of 6.
>>>> This number 6 also appears in the NXP downstream kernel [1]. I know
>>>> Marek V had some concerns about that.
>>>>
>>> Yea, I don't fully remember the details about the overhead. Need to
>>> page that back in. The division by 8 in my patch is just to get from
>>> the bit to a byte clock, nothing to do with the MIPI format bits per
>>> channel or something like that.
>>>
>>>>> the blanking size purely on the ratio between MIPI DSI byte clock and
>>>>> the DPI interface clock. It's quite counter-intuitive that the host
>>>>> would scale the blanking to the number of lanes automatically, but
>>>>> still require the MIPI packet offset removed, but that's what my
>>>>> measurements showed to produce the correct blanking after translation
>>>>> to DPI by the TC358767 bridge chip.
>>>> How many lanes is your DSI interface using?
>>>>
>>> When I did the measurements to come up with the patch, I varied the
>>> number of lanes between 1 and 4. Different number of lanes didn't make
>>> a difference. In fact trying to compensate for the number of lanes when
>>> calculating the blanking size to program into the controller lead to
>>> wildly wrong blanking on the DPI side of the external bridge.
>>>
>>>>> If you dynamically scale the HS clock, then you would need to input the
>>>>> real used HS clock to the calculation in my patch, instead of the fixed
>>>>> burst mode rate.
>>>> I think what you're saying makes sense.
>>>>
>>>> The code I originally modeled this from was from the NXP downstream
>>>> kernel where they define the calculation as being in words [2]. I am
>>>> not saying the NXP code is perfect, but the NXP code works. With this
>>>> series, my monitors are able to sync a bunch of different resolutions
>>>> from 1080p down to 640x480 and a bunch in between with various refresh
>>>> rates too. That was the goal of this series.
>>>>
>>>> Instead of just using your patch as-is, I will adapt yours to use the
>>>> scaled clock to see how it behaves and get back to you.
>>>>
>>> Thanks, that would be very much appreciated.
>> Lucas,
>>
>> I took your patch and added a dsi state variable named "hs_clock" to
>> keep track of the output of samsung_dsim_set_pll which should be the
>> active high-speed clock.
>>
>> I then replaced one line in your code to reference the hs_clock
>> instead of the burst clock:
>>
>> @@ -960,7 +962,7 @@ static void samsung_dsim_set_display_mode(struct
>> samsung_dsim *dsi)
>> u32 reg;
>>
>> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
>> - int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
>> + int byte_clk_khz = dsi->hs_clock / 1000 / 8;
>> int hfp = (m->hsync_start - m->hdisplay) *
>> byte_clk_khz / m->clock;
>>
>> With that change, your patch works with the rest of my code, and I
>> think it's easier to read, and it doesn't involve recalculating the
>> clock speed each time since it's cached. If you're OK with that, I'll
>> incorporate your code into V2 of my series, and I'll apply my changes
>> as a subsequent patch. I hope to be able to send out V2 this weekend.
>>
> That's good to hear! Seems we are converging here. Feel free to pick up
> the patch, that's also easier for me as I don't have to resend with CC
> fixed.
>
>> I would be curious to know frm Marek Szyprowski what the impact is on
>> the Samsung devices, if any.
>>
> Since I messed up the list CC you also couldn't see his reply to my
> patch:
>
> | Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> |
> | Works fine on the Exynos based boards I have in my test farm.
I didn't follow this discussion, I'm a bit busy with other stuff. I've
just tested this series and patch #3 break Exynos based board. If you
want me to test anything else (might be a work-in-progress code), just
let me know by the separate mail.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
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 3/6] drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
From: Marek Szyprowski @ 2023-04-21 11:25 UTC (permalink / raw)
To: Adam Ford, dri-devel
Cc: marex, aford, Rob Herring, Krzysztof Kozlowski, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Inki Dae, Jagan Teki, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, David Airlie, Daniel Vetter, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20230415104104.5537-3-aford173@gmail.com>
On 15.04.2023 12:41, Adam Ford wrote:
> Fetch the clock rate of "sclk_mipi" (or "pll_clk") instead of
> having an entry in the device tree for samsung,pll-clock-frequency.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
This one breaks DSI panel operation on my Exynos-based Trats, Trats2 and
TM2e boards. I've didn't check the details, but probably something is
missing in the dts to make it working properly. Surprisingly the display
is still working fine on Arndale board with DSI TC358764 bridge.
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 9fec32b44e05..73f0c3fbbdf5 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -1744,11 +1744,6 @@ static int samsung_dsim_parse_dt(struct samsung_dsim *dsi)
> struct device_node *node = dev->of_node;
> int ret;
>
> - ret = samsung_dsim_of_read_u32(node, "samsung,pll-clock-frequency",
> - &dsi->pll_clk_rate);
> - if (ret < 0)
> - return ret;
> -
> ret = samsung_dsim_of_read_u32(node, "samsung,burst-clock-frequency",
> &dsi->burst_clk_rate);
> if (ret < 0)
> @@ -1823,13 +1818,18 @@ int samsung_dsim_probe(struct platform_device *pdev)
> if (IS_ERR(dsi->clks[i])) {
> if (strcmp(clk_names[i], "sclk_mipi") == 0) {
> dsi->clks[i] = devm_clk_get(dev, OLD_SCLK_MIPI_CLK_NAME);
> - if (!IS_ERR(dsi->clks[i]))
> + if (!IS_ERR(dsi->clks[i])) {
> + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> continue;
> + }
> }
>
> dev_info(dev, "failed to get the clock: %s\n", clk_names[i]);
> return PTR_ERR(dsi->clks[i]);
> }
> +
> + if (strcmp(clk_names[i], "sclk_mipi") == 0)
> + dsi->pll_clk_rate = clk_get_rate(dsi->clks[i]);
> }
>
> dsi->reg_base = devm_platform_ioremap_resource(pdev, 0);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
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