* Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode
From: Marcelo Tosatti @ 2023-04-19 11:39 UTC (permalink / raw)
To: David Hildenbrand
Cc: Peter Zijlstra, Frederic Weisbecker, Yair Podemsky, linux, mpe,
npiggin, christophe.leroy, hca, gor, agordeev, borntraeger, svens,
davem, tglx, mingo, bp, dave.hansen, x86, hpa, will, aneesh.kumar,
akpm, arnd, keescook, paulmck, jpoimboe, samitolvanen, ardb,
juerg.haefliger, rmk+kernel, geert+renesas, tony, linus.walleij,
sebastian.reichel, nick.hawkins, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-s390, sparclinux, linux-arch, linux-mm,
vschneid, dhildenb, alougovs, jannh, Yang Shi
In-Reply-To: <914e826e-3fab-4540-d3a1-24ca39b1cf0a@redhat.com>
On Wed, Apr 19, 2023 at 01:30:57PM +0200, David Hildenbrand wrote:
> On 06.04.23 20:27, Peter Zijlstra wrote:
> > On Thu, Apr 06, 2023 at 05:51:52PM +0200, David Hildenbrand wrote:
> > > On 06.04.23 17:02, Peter Zijlstra wrote:
> >
> > > > DavidH, what do you thikn about reviving Jann's patches here:
> > > >
> > > > https://bugs.chromium.org/p/project-zero/issues/detail?id=2365#c1
> > > >
> > > > Those are far more invasive, but afaict they seem to do the right thing.
> > > >
> > >
> > > I recall seeing those while discussed on security@kernel.org. What we
> > > currently have was (IMHO for good reasons) deemed better to fix the issue,
> > > especially when caring about backports and getting it right.
> >
> > Yes, and I think that was the right call. However, we can now revisit
> > without having the pressure of a known defect and backport
> > considerations.
> >
> > > The alternative that was discussed in that context IIRC was to simply
> > > allocate a fresh page table, place the fresh page table into the list
> > > instead, and simply free the old page table (then using common machinery).
> > >
> > > TBH, I'd wish (and recently raised) that we could just stop wasting memory
> > > on page tables for THPs that are maybe never going to get PTE-mapped ... and
> > > eventually just allocate on demand (with some caching?) and handle the
> > > places where we're OOM and cannot PTE-map a THP in some descend way.
> > >
> > > ... instead of trying to figure out how to deal with these page tables we
> > > cannot free but have to special-case simply because of GUP-fast.
> >
> > Not keeping them around sounds good to me, but I'm not *that* familiar
> > with the THP code, most of that happened after I stopped tracking mm. So
> > I'm not sure how feasible is it.
> >
> > But it does look entirely feasible to rework this page-table freeing
> > along the lines Jann did.
>
> It's most probably more feasible, although the easiest would be to just
> allocate a fresh page table to deposit and free the old one using the mmu
> gatherer.
>
> This way we can avoid the khugepaged of tlb_remove_table_smp_sync(), but not
> the tlb_remove_table_one() usage. I suspect khugepaged isn't really relevant
> in RT kernels (IIRC, most of RT setups disable THP completely).
People will disable khugepaged because it causes IPIs (and the fact one
has to disable khugepaged is a configuration overhead, and a source of
headache for configuring the realtime system, since one can forget of
doing that, etc).
But people do want to run non-RT applications along with RT applications
(in case you have a single box on a priviledged location, for example).
>
> tlb_remove_table_one() only triggers if __get_free_page(GFP_NOWAIT |
> __GFP_NOWARN); fails. IIUC, that can happen easily under memory pressure
> because it doesn't wait for direct reclaim.
>
> I don't know much about RT workloads (so I'd appreciate some feedback), but
> I guess we can run int memory pressure as well due to some !rt housekeeping
> task on the system?
Yes, exactly (memory for -RT app will be mlocked).
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] arm64: defconfig; enable TI OMAP2 mailbox driver
From: Hari Nagalla @ 2023-04-19 11:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, quic_bjorande, arnd, krzysztof.kozlowski,
treding, dmitry.baryshkov, nfraprado, broonie, rafal
In-Reply-To: <20230419113958.17141-1-hnagalla@ti.com>
Enable TI OMAP2 mailbox driver. This driver is used in TI K3 platforms
as well for communications with remote processors.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 7790ee42c68a..52da7bad8ef9 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1161,6 +1161,7 @@ CONFIG_TEGRA186_TIMER=y
CONFIG_RENESAS_OSTM=y
CONFIG_ARM_MHU=y
CONFIG_IMX_MBOX=y
+CONFIG_OMAP2PLUS_MBOX=m
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
CONFIG_QCOM_APCS_IPC=y
--
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 0/2] arm64: defconfig: enable TI OMAP2 mailbox and R5/DSP remote proc drivers
From: Hari Nagalla @ 2023-04-19 11:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, quic_bjorande, arnd, krzysztof.kozlowski,
treding, dmitry.baryshkov, nfraprado, broonie, rafal
Enable OMAP2 mailbox driver and Cortex R5, TI DSP (C66x, C71x) drivers
built as modules for TI K3 platform devices.
Hari Nagalla (2):
arm64: defconfig; enable TI OMAP2 mailbox driver
arm64: defconfig: enable TI K3 R5 and DSP remote proc drivers
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
--
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
* [PATCH 2/2] arm64: defconfig: enable TI K3 R5 and DSP remote proc drivers
From: Hari Nagalla @ 2023-04-19 11:39 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: catalin.marinas, will, quic_bjorande, arnd, krzysztof.kozlowski,
treding, dmitry.baryshkov, nfraprado, broonie, rafal
In-Reply-To: <20230419113958.17141-1-hnagalla@ti.com>
Enable Cortex R5 and TI DSP (C66x,C71x) remote proc drivers as modules
for K3 platforms.
Signed-off-by: Hari Nagalla <hnagalla@ti.com>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 52da7bad8ef9..d8e0ae85485f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1173,6 +1173,8 @@ CONFIG_ARM_SMMU_V3=y
CONFIG_MTK_IOMMU=y
CONFIG_QCOM_IOMMU=y
CONFIG_REMOTEPROC=y
+CONFIG_TI_K3_R5_REMOTEPROC=m
+CONFIG_TI_K3_DSP_REMOTEPROC=m
CONFIG_MTK_SCP=m
CONFIG_QCOM_Q6V5_ADSP=m
CONFIG_QCOM_Q6V5_MSS=m
--
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 0/3] arm64: dts: ti: k3-am62a: Add timers, wdt and fixup
From: Roger Quadros @ 2023-04-19 11:37 UTC (permalink / raw)
To: Nishanth Menon, Krzysztof Kozlowski, Rob Herring,
Vignesh Raghavendra
Cc: linux-kernel, devicetree, linux-arm-kernel, Tero Kristo,
Bryan Brattlof
In-Reply-To: <20230418012717.1230882-1-nm@ti.com>
On 18/04/2023 04:27, Nishanth Menon wrote:
> Hi,
>
> This is a series that adds wdt, timers to am62ax support, and adds the
> missing description for uart1 and wkup_uart that is used by firmware.
>
> Nishanth Menon (3):
> arm64: dts: ti: k3-am62a: Add general purpose timers
> arm64: dts: ti: k3-am62a: Add watchdog nodes
> arm64: dts: ti: k3-am62a7-evm: Describe main_uart1 and wkup_uart
>
> arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 141 ++++++++++++++++++++
> arch/arm64/boot/dts/ti/k3-am62a-mcu.dtsi | 56 ++++++++
> arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi | 11 ++
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 36 +++++
> 4 files changed, 244 insertions(+)
>
Reviewed-by: Roger Quadros <rogerq@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 v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
From: Justin Forbes @ 2023-04-19 11:27 UTC (permalink / raw)
To: Catalin Marinas
Cc: Andrew Morton, Mike Rapoport, Arnd Bergmann, Christophe Leroy,
David S. Miller, Dinh Nguyen, Geert Uytterhoeven, Guo Ren,
John Paul Adrian Glaubitz, Kirill A. Shutemov, Max Filippov,
Michael Ellerman, Rich Felker, Russell King, Will Deacon,
Yoshinori Sato, Zi Yan, linux-arm-kernel, linux-csky, linux-ia64,
linux-kernel, linux-m68k, linux-mm, linux-sh, linux-xtensa,
linuxppc-dev, sparclinux
In-Reply-To: <ZD/K+Mof/Dx5yzjQ@arm.com>
On Wed, Apr 19, 2023 at 6:12 AM Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Tue, Apr 18, 2023 at 03:05:57PM -0700, Andrew Morton wrote:
> > On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > > It sounds nice in theory. In practice. EXPERT hides too much. When you
> > > > flip expert, you expose over a 175ish new config options which are
> > > > hidden behind EXPERT. You don't have to know what you are doing just
> > > > with the MAX_ORDER, but a whole bunch more as well. If everyone were
> > > > already running 10, this might be less of a problem. At least Fedora
> > > > and RHEL are running 13 for 4K pages on aarch64. This was not some
> > > > accidental choice, we had to carry a patch to even allow it for a
> > > > while. If this does go in as is, we will likely just carry a patch to
> > > > remove the "if EXPERT", but that is a bit of a disservice to users who
> > > > might be trying to debug something else upstream, bisecting upstream
> > > > kernels or testing a patch. In those cases, people tend to use
> > > > pristine upstream sources without distro patches to verify, and they
> > > > tend to use their existing configs. With this change, their MAX_ORDER
> > > > will drop to 10 from 13 silently. That can look like a different
> > > > issue enough to ruin a bisect or have them give bad feedback on a
> > > > patch because it introduces a "regression" which is not a regression
> > > > at all, but a config change they couldn't see.
> > >
> > > If we remove EXPERT (as prior to this patch), I'd rather keep the ranges
> > > and avoid having to explain to people why some random MAX_ORDER doesn't
> > > build (keeping the range would also make sense for randconfig, not sure
> > > we got to any conclusion there).
> >
> > Well this doesn't seem to have got anywhere. I think I'll send the
> > patchset into Linus for the next merge window as-is. Please let's take
> > a look at this Kconfig presentation issue during the following -rc
> > cycle.
>
> That's fine by me. I have a slight preference to drop EXPERT and keep
> the ranges in, especially if it affects current distro kernels. Debian
> seems to enable EXPERT already in their arm64 kernel config but I'm not
> sure about the Fedora or other distro kernels. If they don't, we can
> fix/revert this Kconfig entry once the merging window is closed.
Fedora and RHEL do not enable EXPERT already.
Justin
_______________________________________________
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] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Marc Zyngier @ 2023-04-19 11:31 UTC (permalink / raw)
To: Dan Carpenter
Cc: Andre Przywara, Oliver Upton, James Morse, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Eric Auger,
Steven Price, linux-arm-kernel, kvmarm, kernel-janitors
In-Reply-To: <4efbab8c-640f-43b2-8ac6-6d68e08280fe@kili.mountain>
Hi Dan,
On Wed, 19 Apr 2023 11:16:13 +0100,
Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
> between 0-32768 but if it is more than sizeof(long) this will corrupt
> memory.
>
> Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
> v2: The original patch was okay but checking for != sizeof(val) is
> stricter and more Obviously Correct[tm]. Return -ENOENT instead of
> -EINVAL in case future ioctls are added which take a different size.
>
> arch/arm64/kvm/hypercalls.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 2e16fc7b31bf..7fb4df0456de 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -544,6 +544,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> u64 val;
> int wa_level;
>
> + if (KVM_REG_SIZE(reg->id) != sizeof(val))
> + return -ENOENT;
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
Thanks for the fix. In the future, please Cc me on KVM/arm64 patches
(specially this particular variety of patches...).
Reviewed-by: Marc Zyngier <maz@kernel.org>
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 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode
From: David Hildenbrand @ 2023-04-19 11:30 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Marcelo Tosatti, Frederic Weisbecker, Yair Podemsky, linux, mpe,
npiggin, christophe.leroy, hca, gor, agordeev, borntraeger, svens,
davem, tglx, mingo, bp, dave.hansen, x86, hpa, will, aneesh.kumar,
akpm, arnd, keescook, paulmck, jpoimboe, samitolvanen, ardb,
juerg.haefliger, rmk+kernel, geert+renesas, tony, linus.walleij,
sebastian.reichel, nick.hawkins, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-s390, sparclinux, linux-arch, linux-mm,
vschneid, dhildenb, alougovs, jannh, Yang Shi
In-Reply-To: <20230406182749.GA405948@hirez.programming.kicks-ass.net>
On 06.04.23 20:27, Peter Zijlstra wrote:
> On Thu, Apr 06, 2023 at 05:51:52PM +0200, David Hildenbrand wrote:
>> On 06.04.23 17:02, Peter Zijlstra wrote:
>
>>> DavidH, what do you thikn about reviving Jann's patches here:
>>>
>>> https://bugs.chromium.org/p/project-zero/issues/detail?id=2365#c1
>>>
>>> Those are far more invasive, but afaict they seem to do the right thing.
>>>
>>
>> I recall seeing those while discussed on security@kernel.org. What we
>> currently have was (IMHO for good reasons) deemed better to fix the issue,
>> especially when caring about backports and getting it right.
>
> Yes, and I think that was the right call. However, we can now revisit
> without having the pressure of a known defect and backport
> considerations.
>
>> The alternative that was discussed in that context IIRC was to simply
>> allocate a fresh page table, place the fresh page table into the list
>> instead, and simply free the old page table (then using common machinery).
>>
>> TBH, I'd wish (and recently raised) that we could just stop wasting memory
>> on page tables for THPs that are maybe never going to get PTE-mapped ... and
>> eventually just allocate on demand (with some caching?) and handle the
>> places where we're OOM and cannot PTE-map a THP in some descend way.
>>
>> ... instead of trying to figure out how to deal with these page tables we
>> cannot free but have to special-case simply because of GUP-fast.
>
> Not keeping them around sounds good to me, but I'm not *that* familiar
> with the THP code, most of that happened after I stopped tracking mm. So
> I'm not sure how feasible is it.
>
> But it does look entirely feasible to rework this page-table freeing
> along the lines Jann did.
It's most probably more feasible, although the easiest would be to just
allocate a fresh page table to deposit and free the old one using the
mmu gatherer.
This way we can avoid the khugepaged of tlb_remove_table_smp_sync(), but
not the tlb_remove_table_one() usage. I suspect khugepaged isn't really
relevant in RT kernels (IIRC, most of RT setups disable THP completely).
tlb_remove_table_one() only triggers if __get_free_page(GFP_NOWAIT |
__GFP_NOWARN); fails. IIUC, that can happen easily under memory pressure
because it doesn't wait for direct reclaim.
I don't know much about RT workloads (so I'd appreciate some feedback),
but I guess we can run int memory pressure as well due to some !rt
housekeeping task on the system?
--
Thanks,
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
* Re: [PATCH 2/3] firmware: arm_ffa: Fix usage of partition info get count flag
From: Jens Wiklander @ 2023-04-19 11:23 UTC (permalink / raw)
To: Sudeep Holla; +Cc: linux-arm-kernel, Lucian Paul-Trifu, Marc Bonnici
In-Reply-To: <20230419-ffa_fixes_6-4-v1-2-1881ee6699f1@arm.com>
On Wed, Apr 19, 2023 at 11:54 AM Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> Commit bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support")
> adds support to discovery the UUIDs of the partitions or just fetch the
> partition count using the PARTITION_INFO_GET_RETURN_COUNT_ONLY flag.
>
> However the commit doesn't handle the fact that the older version doesn't
> understand the flag and must be MBZ which results in firmware returning
> invalid parameter error. That results in the failure of the driver probe
> which is in correct.
>
> Limit the usage of the PARTITION_INFO_GET_RETURN_COUNT_ONLY flag for the
> versions above v1.0(i.e v1.1 and onwards) which fixes the issue.
>
> Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support")
> Reported-by: Jens Wiklander <jens.wiklander@linaro.org>
> Reported-by: Marc Bonnici <marc.bonnici@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/firmware/arm_ffa/driver.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Tested-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Thanks,
Jens
>
> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> index fa85c64d3ded..4aced2e5b772 100644
> --- a/drivers/firmware/arm_ffa/driver.c
> +++ b/drivers/firmware/arm_ffa/driver.c
> @@ -193,7 +193,8 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
> int idx, count, flags = 0, sz, buf_sz;
> ffa_value_t partition_info;
>
> - if (!buffer || !num_partitions) /* Just get the count for now */
> + if (drv_info->version > FFA_VERSION_1_0 &&
> + (!buffer || !num_partitions)) /* Just get the count for now */
> flags = PARTITION_INFO_GET_RETURN_COUNT_ONLY;
>
> mutex_lock(&drv_info->rx_lock);
>
> --
> 2.40.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] arm64: kernel: smp: ignore disabled cpu node
From: Peng Fan @ 2023-04-19 11:22 UTC (permalink / raw)
To: Sudeep Holla, Peng Fan (OSS)
Cc: catalin.marinas@arm.com, will@kernel.org, peterz@infradead.org,
jpoimboe@kernel.org, rafael.j.wysocki@intel.com,
vschneid@redhat.com, ben-linux@fluff.org, Pierre.Gondois@arm.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20230419100214.x6y6jgpvnupmgplr@bogus>
> Subject: Re: [PATCH] arm64: kernel: smp: ignore disabled cpu node
>
> On Wed, Apr 19, 2023 at 05:40:39PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > If the cpu node is set disabled in device tree, we should ignore the
> > node. i.MX8MP has some variants, which have one or two or four A53
> cores.
> > The current imx8mp device tree use the full feature SoC. With such
> > device tree to bring the variant with one or two A53 cores will cause
> > issue.
> >
> > The firmware will update the status property, and kernel will check
> > the property before bring up the core.
> >
>
> IIRC it has been discussed in the past[1][2], has anything changed now ?
Ok, removing cpu nodes also means we need also runtime update
cooling devices node, and etc.
Thanks,
Peng.
>
> --
> Regards,
> Sudeep
>
> [1]
> http://lists.in/
> fradead.org%2Fpipermail%2Flinux-arm-kernel%2F2013-
> June%2F174324.html&data=05%7C01%7Cpeng.fan%40nxp.com%7Cf0e0d9c
> 8626b4ffd8ebe08db40bd29ec%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C
> 0%7C0%7C638174953417504770%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C30
> 00%7C%7C%7C&sdata=4wUcFCMArXHGL%2BGu4gAkRFzrqITYvWfe2uyw9Wj
> n00w%3D&reserved=0
> [2]
> https://yhbt/.
> net%2Flore%2Fall%2F1524697712-20208-1-git-send-email-
> rokhanna%40nvidia.com%2F&data=05%7C01%7Cpeng.fan%40nxp.com%7Cf
> 0e0d9c8626b4ffd8ebe08db40bd29ec%7C686ea1d3bc2b4c6fa92cd99c5c3016
> 35%7C0%7C0%7C638174953417504770%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000%7C%7C%7C&sdata=773VoFqxDZJ2C8QLY6jn62HnOxTVxNkMk0pA
> G6nue44%3D&reserved=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 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode
From: Marcelo Tosatti @ 2023-04-19 11:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Frederic Weisbecker, Yair Podemsky, linux, mpe, npiggin,
christophe.leroy, hca, gor, agordeev, borntraeger, svens, davem,
tglx, mingo, bp, dave.hansen, x86, hpa, will, aneesh.kumar, akpm,
arnd, keescook, paulmck, jpoimboe, samitolvanen, ardb,
juerg.haefliger, rmk+kernel, geert+renesas, tony, linus.walleij,
sebastian.reichel, nick.hawkins, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-s390, sparclinux, linux-arch, linux-mm,
vschneid, dhildenb, alougovs
In-Reply-To: <20230406133206.GN386572@hirez.programming.kicks-ass.net>
On Thu, Apr 06, 2023 at 03:32:06PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 06, 2023 at 09:49:22AM -0300, Marcelo Tosatti wrote:
>
> > > > 2) Depends on the application and the definition of "occasional".
> > > >
> > > > For certain types of applications (for example PLC software or
> > > > RAN processing), upon occurrence of an event, it is necessary to
> > > > complete a certain task in a maximum amount of time (deadline).
> > >
> > > If the application is properly NOHZ_FULL and never does a kernel entry,
> > > it will never get that IPI. If it is a pile of shit and does kernel
> > > entries while it pretends to be NOHZ_FULL it gets to keep the pieces and
> > > no amount of crying will get me to care.
> >
> > I suppose its common practice to use certain system calls in latency
> > sensitive applications, for example nanosleep. Some examples:
> >
> > 1) cyclictest (nanosleep)
>
> cyclictest is not a NOHZ_FULL application, if you tihnk it is, you're
> deluded.
On the field (what end-users do on production):
cyclictest runs on NOHZ_FULL cores.
PLC type programs run on NOHZ_FULL cores.
So accordingly to physical reality i observe, i am not deluded.
> > 2) PLC programs (nanosleep)
>
> What's a PLC? Programmable Logic Circuit?
Programmable logic controller.
> > A system call does not necessarily have to take locks, does it ?
>
> This all is unrelated to locks
OK.
> > Or even if application does system calls, but runs under a VM,
> > then you are requiring it to never VM-exit.
>
> That seems to be a goal for performance anyway.
Not sure what you mean.
> > This reduces the flexibility of developing such applications.
>
> Yeah, that's the cards you're dealt, deal with it.
This is not what happens on the field.
_______________________________________________
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/4] spi: s3c64xx: add cpu_relax in polling loop
From: Jaewon Kim @ 2023-04-19 11:13 UTC (permalink / raw)
To: Krzysztof Kozlowski, Mark Brown, Andi Shyti, Alim Akhtar
Cc: linux-spi, linux-samsung-soc, linux-arm-kernel, linux-kernel,
Chanho Park
In-Reply-To: <36f37a18-0022-0368-bf7c-ebdd724b1558@linaro.org>
On 23. 4. 19. 17:14, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:06, Jaewon Kim wrote:
>> Adds cpu_relax() to prevent long busy-wait.
> How cpu_relax prevents long waiting?
As I know, cpu_relax() can be converted to yield. This can prevent
excessive use of the CPU in busy-loop.
I'll replace poor sentence like below in v3.
("Adds cpu_relax() to allow CPU relaxation in busy-loop")
>> There is busy-wait loop to check data transfer completion in polling mode.
>>
>> Signed-off-by: Jaewon Kim<jaewon02.kim@samsung.com>
>> ---
>> drivers/spi/spi-s3c64xx.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
>> index 273aa02322d9..886722fb40ea 100644
>> --- a/drivers/spi/spi-s3c64xx.c
>> +++ b/drivers/spi/spi-s3c64xx.c
>> @@ -568,6 +568,7 @@ static int s3c64xx_wait_for_pio(struct s3c64xx_spi_driver_data *sdd,
>>
>> val = msecs_to_loops(ms);
>> do {
>> + cpu_relax();
> Shouldn't this be just readl_poll_timeout()? Or the syntax would be too
> complicated?
I think we can replace this while() loop to readl_poll_timeout().
However, we should use 0 value as 'delay_us' parameter. Because delay
can affect throughput.
My purpose is add relax to this busy-loop.
we cannot give relax if we change to readl_poll_timeout().
>> status = readl(regs + S3C64XX_SPI_STATUS);
>> } while (RX_FIFO_LVL(status, sdd) < xfer->len && --val);
>>
> Best regards,
> Krzysztof
>
>
Thanks
Jaewon Kim
_______________________________________________
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] spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPS
From: kernel test robot @ 2023-04-19 11:15 UTC (permalink / raw)
To: Dhruva Gole, Mark Brown
Cc: oe-kbuild-all, Dhruva Gole, Vaishnav Achath, Vignesh,
Apurva Nandan, linux-arm-kernel, linux-spi, linux-kernel
In-Reply-To: <20230419084817.481136-1-d-gole@ti.com>
Hi Dhruva,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20230418]
[also build test ERROR on linus/master v6.3-rc7]
[cannot apply to broonie-spi/for-next v6.3-rc7 v6.3-rc6 v6.3-rc5]
[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/Dhruva-Gole/spi-cadence-quadspi-use-macro-DEFINE_SIMPLE_DEV_PM_OPS/20230419-165052
patch link: https://lore.kernel.org/r/20230419084817.481136-1-d-gole%40ti.com
patch subject: [PATCH V2] spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPS
config: m68k-allyesconfig (https://download.01.org/0day-ci/archive/20230419/202304191900.2fARFQW9-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/83ce1615dd395c8034756cc6aa97b38c16c0b07d
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Dhruva-Gole/spi-cadence-quadspi-use-macro-DEFINE_SIMPLE_DEV_PM_OPS/20230419-165052
git checkout 83ce1615dd395c8034756cc6aa97b38c16c0b07d
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=m68k SHELL=/bin/bash drivers/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202304191900.2fARFQW9-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/spi/spi-cadence-quadspi.c:1918:24: error: 'cqspi_dev_pm_ops' undeclared here (not in a function); did you mean 'cqspi_mem_ops'?
1918 | .pm = &cqspi_dev_pm_ops,
| ^~~~~~~~~~~~~~~~
| cqspi_mem_ops
vim +1918 drivers/spi/spi-cadence-quadspi.c
1912
1913 static struct platform_driver cqspi_platform_driver = {
1914 .probe = cqspi_probe,
1915 .remove_new = cqspi_remove,
1916 .driver = {
1917 .name = CQSPI_NAME,
> 1918 .pm = &cqspi_dev_pm_ops,
1919 .of_match_table = cqspi_dt_ids,
1920 },
1921 };
1922
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
_______________________________________________
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 v2 PATCH 00/17] variable-order, large folios for anonymous memory
From: Ryan Roberts @ 2023-04-19 11:13 UTC (permalink / raw)
To: David Hildenbrand, Andrew Morton, Matthew Wilcox (Oracle),
Yu Zhao, Yin, Fengwei
Cc: linux-mm, linux-arm-kernel
In-Reply-To: <87ad8d4b-b117-0c7a-3d0b-723ad59a0405@redhat.com>
On 19/04/2023 11:51, David Hildenbrand wrote:
>> I'm looking to fix this problem in my code, but am struggling to see how the
>> current code is safe. I'm thinking about the following scenario:
>>
>
> Let's see :)
>
>> - A page is CoW mapped into processes A and B.
>> - The page takes a fault in process A, and do_wp_page() determines that it is
>> "maybe-shared" and therefore must copy. So drops the PTL and calls
>> wp_page_copy().
>
> Note that before calling wp_page_copy(), we do a folio_get(folio); Further, the
> page table reference is only dropped once we actually replace the page in the
> page table. So while in wp_page_copy(), the folio should have at least 2
> references if the page is still mapped.
Ahh, yes, of course!
>
>> - Process B exits.
>> - Another thread in process A faults on the page. This time dw_wp_page()
>> determines that the page is exclusive (due to the ref count), and reuses it,
>> marking it exclusive along the way.
>
> The refcount should not be 1 (other reference from the wp_page_copy() caller),
> so A won't be able to reuse it, and ...
>
>> - wp_page_copy() from the original thread in process A retakes the PTL and
>> copies the _now exclusive_ page.
>>
>> Having typed it up, I guess this can't happen, because wp_page_copy() will only
>> do the copy if the PTE hasn't changed and it will have changed because it is now
>> writable? So this is safe?
>
> this applies as well. If the pte changed (when reusing due to a write failt it's
> now writable, or someone else broke COW), we back off. For FAULT_FLAG_UNSHARE,
> however, the PTE may not change. But the additional reference should make it work.
>
> I think it works as intended. It would be clearer if we'd also recheck in
> wp_page_copy() whether we still don't have an exclusive anon page under PT lock
> -- and if we would, back off.
Yes, agreed. I now have a fix for my code that adds a check during the PTE scan
that each page is non-exclusive. And the scan is (already) done once without the
PTL to determine the size of destination folio, and then again with the lock to
ensure there was no race. I'm not seeing any change in the relative counts of
folio orders (which is expected due to the case being rare).
Thanks!
_______________________________________________
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 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
From: Catalin Marinas @ 2023-04-19 11:05 UTC (permalink / raw)
To: Andrew Morton
Cc: Justin Forbes, Mike Rapoport, Arnd Bergmann, Christophe Leroy,
David S. Miller, Dinh Nguyen, Geert Uytterhoeven, Guo Ren,
John Paul Adrian Glaubitz, Kirill A. Shutemov, Max Filippov,
Michael Ellerman, Rich Felker, Russell King, Will Deacon,
Yoshinori Sato, Zi Yan, linux-arm-kernel, linux-csky, linux-ia64,
linux-kernel, linux-m68k, linux-mm, linux-sh, linux-xtensa,
linuxppc-dev, sparclinux
In-Reply-To: <20230418150557.ea8c87c96ec64c899c88ab08@linux-foundation.org>
On Tue, Apr 18, 2023 at 03:05:57PM -0700, Andrew Morton wrote:
> On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas <catalin.marinas@arm.com> wrote:
> > > It sounds nice in theory. In practice. EXPERT hides too much. When you
> > > flip expert, you expose over a 175ish new config options which are
> > > hidden behind EXPERT. You don't have to know what you are doing just
> > > with the MAX_ORDER, but a whole bunch more as well. If everyone were
> > > already running 10, this might be less of a problem. At least Fedora
> > > and RHEL are running 13 for 4K pages on aarch64. This was not some
> > > accidental choice, we had to carry a patch to even allow it for a
> > > while. If this does go in as is, we will likely just carry a patch to
> > > remove the "if EXPERT", but that is a bit of a disservice to users who
> > > might be trying to debug something else upstream, bisecting upstream
> > > kernels or testing a patch. In those cases, people tend to use
> > > pristine upstream sources without distro patches to verify, and they
> > > tend to use their existing configs. With this change, their MAX_ORDER
> > > will drop to 10 from 13 silently. That can look like a different
> > > issue enough to ruin a bisect or have them give bad feedback on a
> > > patch because it introduces a "regression" which is not a regression
> > > at all, but a config change they couldn't see.
> >
> > If we remove EXPERT (as prior to this patch), I'd rather keep the ranges
> > and avoid having to explain to people why some random MAX_ORDER doesn't
> > build (keeping the range would also make sense for randconfig, not sure
> > we got to any conclusion there).
>
> Well this doesn't seem to have got anywhere. I think I'll send the
> patchset into Linus for the next merge window as-is. Please let's take
> a look at this Kconfig presentation issue during the following -rc
> cycle.
That's fine by me. I have a slight preference to drop EXPERT and keep
the ranges in, especially if it affects current distro kernels. Debian
seems to enable EXPERT already in their arm64 kernel config but I'm not
sure about the Fedora or other distro kernels. If they don't, we can
fix/revert this Kconfig entry once the merging window is closed.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] Revert "ASoC: fsl: remove unnecessary dai_link->platform"
From: Shengjiu Wang @ 2023-04-19 10:29 UTC (permalink / raw)
To: kuninori.morimoto.gx, shengjiu.wang, Xiubo.Lee, festevam,
nicoleotsuka, lgirdwood, broonie, perex, tiwai, shawnguo, s.hauer,
kernel, linux-imx, alsa-devel
Cc: linuxppc-dev, linux-arm-kernel, linux-kernel
This reverts commit 33683cbf49b5412061cb1e4c876063fdef86def4.
dai_link->platform is needed. The platform component is
"snd_dmaengine_pcm", which is registered from cpu driver,
If dai_link->platform is not assigned, then platform
component will not be probed, then there will be issue:
aplay: main:831: audio open error: Invalid argument
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/imx-audmix.c | 14 ++++++++++----
sound/soc/fsl/imx-spdif.c | 5 ++++-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/imx-audmix.c b/sound/soc/fsl/imx-audmix.c
index 2c57fe9d2d08..1292a845c424 100644
--- a/sound/soc/fsl/imx-audmix.c
+++ b/sound/soc/fsl/imx-audmix.c
@@ -207,8 +207,8 @@ static int imx_audmix_probe(struct platform_device *pdev)
for (i = 0; i < num_dai; i++) {
struct snd_soc_dai_link_component *dlc;
- /* for CPU/Codec x 2 */
- dlc = devm_kcalloc(&pdev->dev, 4, sizeof(*dlc), GFP_KERNEL);
+ /* for CPU/Codec/Platform x 2 */
+ dlc = devm_kcalloc(&pdev->dev, 6, sizeof(*dlc), GFP_KERNEL);
if (!dlc)
return -ENOMEM;
@@ -240,9 +240,11 @@ static int imx_audmix_probe(struct platform_device *pdev)
priv->dai[i].cpus = &dlc[0];
priv->dai[i].codecs = &dlc[1];
+ priv->dai[i].platforms = &dlc[2];
priv->dai[i].num_cpus = 1;
priv->dai[i].num_codecs = 1;
+ priv->dai[i].num_platforms = 1;
priv->dai[i].name = dai_name;
priv->dai[i].stream_name = "HiFi-AUDMIX-FE";
@@ -250,6 +252,7 @@ static int imx_audmix_probe(struct platform_device *pdev)
priv->dai[i].codecs->name = "snd-soc-dummy";
priv->dai[i].cpus->of_node = args.np;
priv->dai[i].cpus->dai_name = dev_name(&cpu_pdev->dev);
+ priv->dai[i].platforms->of_node = args.np;
priv->dai[i].dynamic = 1;
priv->dai[i].dpcm_playback = 1;
priv->dai[i].dpcm_capture = (i == 0 ? 1 : 0);
@@ -264,17 +267,20 @@ static int imx_audmix_probe(struct platform_device *pdev)
be_cp = devm_kasprintf(&pdev->dev, GFP_KERNEL,
"AUDMIX-Capture-%d", i);
- priv->dai[num_dai + i].cpus = &dlc[2];
- priv->dai[num_dai + i].codecs = &dlc[3];
+ priv->dai[num_dai + i].cpus = &dlc[3];
+ priv->dai[num_dai + i].codecs = &dlc[4];
+ priv->dai[num_dai + i].platforms = &dlc[5];
priv->dai[num_dai + i].num_cpus = 1;
priv->dai[num_dai + i].num_codecs = 1;
+ priv->dai[num_dai + i].num_platforms = 1;
priv->dai[num_dai + i].name = be_name;
priv->dai[num_dai + i].codecs->dai_name = "snd-soc-dummy-dai";
priv->dai[num_dai + i].codecs->name = "snd-soc-dummy";
priv->dai[num_dai + i].cpus->of_node = audmix_np;
priv->dai[num_dai + i].cpus->dai_name = be_name;
+ priv->dai[num_dai + i].platforms->name = "snd-soc-dummy";
priv->dai[num_dai + i].no_pcm = 1;
priv->dai[num_dai + i].dpcm_playback = 1;
priv->dai[num_dai + i].dpcm_capture = 1;
diff --git a/sound/soc/fsl/imx-spdif.c b/sound/soc/fsl/imx-spdif.c
index 114b49660193..4446fba755b9 100644
--- a/sound/soc/fsl/imx-spdif.c
+++ b/sound/soc/fsl/imx-spdif.c
@@ -26,7 +26,7 @@ static int imx_spdif_audio_probe(struct platform_device *pdev)
}
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
- comp = devm_kzalloc(&pdev->dev, 2 * sizeof(*comp), GFP_KERNEL);
+ comp = devm_kzalloc(&pdev->dev, 3 * sizeof(*comp), GFP_KERNEL);
if (!data || !comp) {
ret = -ENOMEM;
goto end;
@@ -34,15 +34,18 @@ static int imx_spdif_audio_probe(struct platform_device *pdev)
data->dai.cpus = &comp[0];
data->dai.codecs = &comp[1];
+ data->dai.platforms = &comp[2];
data->dai.num_cpus = 1;
data->dai.num_codecs = 1;
+ data->dai.num_platforms = 1;
data->dai.name = "S/PDIF PCM";
data->dai.stream_name = "S/PDIF PCM";
data->dai.codecs->dai_name = "snd-soc-dummy-dai";
data->dai.codecs->name = "snd-soc-dummy";
data->dai.cpus->of_node = spdif_np;
+ data->dai.platforms->of_node = spdif_np;
data->dai.playback_only = true;
data->dai.capture_only = true;
--
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: [RFC v2 PATCH 00/17] variable-order, large folios for anonymous memory
From: David Hildenbrand @ 2023-04-19 10:51 UTC (permalink / raw)
To: Ryan Roberts, Andrew Morton, Matthew Wilcox (Oracle), Yu Zhao,
Yin, Fengwei
Cc: linux-mm, linux-arm-kernel
In-Reply-To: <5b6fe242-a19e-70bf-adba-240f2d5b8548@arm.com>
> I'm looking to fix this problem in my code, but am struggling to see how the
> current code is safe. I'm thinking about the following scenario:
>
Let's see :)
> - A page is CoW mapped into processes A and B.
> - The page takes a fault in process A, and do_wp_page() determines that it is
> "maybe-shared" and therefore must copy. So drops the PTL and calls
> wp_page_copy().
Note that before calling wp_page_copy(), we do a folio_get(folio);
Further, the page table reference is only dropped once we actually
replace the page in the page table. So while in wp_page_copy(), the
folio should have at least 2 references if the page is still mapped.
> - Process B exits.
> - Another thread in process A faults on the page. This time dw_wp_page()
> determines that the page is exclusive (due to the ref count), and reuses it,
> marking it exclusive along the way.
The refcount should not be 1 (other reference from the wp_page_copy()
caller), so A won't be able to reuse it, and ...
> - wp_page_copy() from the original thread in process A retakes the PTL and
> copies the _now exclusive_ page.
>
> Having typed it up, I guess this can't happen, because wp_page_copy() will only
> do the copy if the PTE hasn't changed and it will have changed because it is now
> writable? So this is safe?
this applies as well. If the pte changed (when reusing due to a write
failt it's now writable, or someone else broke COW), we back off. For
FAULT_FLAG_UNSHARE, however, the PTE may not change. But the additional
reference should make it work.
I think it works as intended. It would be clearer if we'd also recheck
in wp_page_copy() whether we still don't have an exclusive anon page
under PT lock -- and if we would, back off.
>
> To make things more convoluted, what happens if the second thread does an
> mprotect() to make the page RO after its write fault was handled? I think
> mprotect() will serialize on the mmap write lock so this is safe too?
Yes, mprotect() synchronizes that. There are other mechanisms to
write-protect a page, though, under mmap lock in read mode (uffd-wp). So
it's a valid concern.
In all of these cases, reuse should be prevented due to the additional
reference on the folio when entering wp_page_copy() right from the
start, not turning the page exclusive but instead replacing it by a
copy. An additional sanity check sounds like the right thing to do.
>
> Sorry if this is a bit rambly, just trying to make sure I've understood
> everything correctly.
It's a very interesting corner case, thanks for bringing that up. I
think the old mapcount based approach could have suffered from this
theoretical issue, but I might be wrong.
--
Thanks,
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
* Re: [PATCH 1/6] drm: bridge: samsung-dsim: Support multi-lane calculations
From: Adam Ford @ 2023-04-19 10:47 UTC (permalink / raw)
To: Lucas Stach
Cc: dri-devel, Krzysztof Kozlowski, aford, Laurent Pinchart,
Andrzej Hajda, Fabio Estevam, m.szyprowski, 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: <CAHCN7xL4+9NogrnXA1PEWorwY7JpSGBozDtHT83JvzjfinmS+A@mail.gmail.com>
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.
adam
>
> Mine was purely by trial and error. I don't have a scope, nor do I
> have a copy of the MIPI DSI spec, so if the image sync'd with my
> monitor, I treated it as successful.
>
> I can give yours a try, but it might be a few days since I've only
> been working on this stuff a bit in my spare time.
>
> adam
>
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Adam Ford <aford173@gmail.com>
> > > ---
> > > drivers/gpu/drm/bridge/samsung-dsim.c | 40 +++++++++++++++++++++++----
> > > 1 file changed, 34 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > index e0a402a85787..1ccbad4ea577 100644
> > > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > > @@ -215,6 +215,7 @@
> > > #define DSI_RX_FIFO_SIZE 256
> > > #define DSI_XFER_TIMEOUT_MS 100
> > > #define DSI_RX_FIFO_EMPTY 0x30800002
> > > +#define DSI_HSYNC_PKT_OVERHEAD 6
> > >
> > > #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
> > >
> > > @@ -879,13 +880,40 @@ static void samsung_dsim_set_display_mode(struct samsung_dsim *dsi)
> > > | DSIM_MAIN_VBP(m->vtotal - m->vsync_end);
> > > samsung_dsim_write(dsi, DSIM_MVPORCH_REG, reg);
> > >
> > > - reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> > > - | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> > > - samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > > + /*
> > > + * 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 correction
> > > + */
> > > + if (dsi->lanes > 1) {
> > > + u32 hfp, hbp, hsa;
> > > + int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format) / 8;
> > > +
> > > + hfp = ((m->hsync_start - m->hdisplay) * bpp) / dsi->lanes;
> > > + hfp -= (hfp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > > +
> > > + hbp = ((m->htotal - m->hsync_end) * bpp) / dsi->lanes;
> > > + hbp -= (hbp > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > >
> > > - reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > > - | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> > > - samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > > + hsa = ((m->hsync_end - m->hsync_start) * bpp) / dsi->lanes;
> > > + hsa -= (hsa > DSI_HSYNC_PKT_OVERHEAD) ? DSI_HSYNC_PKT_OVERHEAD : 0;
> > > +
> > > + reg = DSIM_MAIN_HFP(hfp) | DSIM_MAIN_HBP(hbp);
> > > + samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > > +
> > > + reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > > + | DSIM_MAIN_HSA(hsa);
> > > + samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > > + } else {
> > > + reg = DSIM_MAIN_HFP(m->hsync_start - m->hdisplay)
> > > + | DSIM_MAIN_HBP(m->htotal - m->hsync_end);
> > > + samsung_dsim_write(dsi, DSIM_MHPORCH_REG, reg);
> > > +
> > > + reg = DSIM_MAIN_VSA(m->vsync_end - m->vsync_start)
> > > + | DSIM_MAIN_HSA(m->hsync_end - m->hsync_start);
> > > + samsung_dsim_write(dsi, DSIM_MSYNC_REG, reg);
> > > + }
> > > }
> > > reg = DSIM_MAIN_HRESOL(m->hdisplay, num_bits_resol) |
> > > DSIM_MAIN_VRESOL(m->vdisplay, num_bits_resol);
> >
_______________________________________________
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: Adam Ford @ 2023-04-19 10:41 UTC (permalink / raw)
To: Lucas Stach
Cc: Marek Vasut, Krzysztof Kozlowski, aford, dri-devel,
Laurent Pinchart, Andrzej Hajda, m.szyprowski, Robert Foss,
Jernej Skrabec, Jagan Teki, NXP Linux Team, devicetree,
Jonas Karlman, Sascha Hauer, Rob Herring, linux-arm-kernel,
Neil Armstrong, linux-kernel, Pengutronix Kernel Team, Shawn Guo
In-Reply-To: <426e901f14254cfcff87ba1747534f9b856ef738.camel@pengutronix.de>
On Tue, Apr 18, 2023 at 3:47 AM Lucas Stach <l.stach@pengutronix.de> wrote:
>
> Am Dienstag, dem 18.04.2023 um 10:30 +0200 schrieb Marek Vasut:
> > On 4/18/23 04:29, Adam Ford wrote:
> > > On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut <marex@denx.de> wrote:
> > > >
> > > > On 4/15/23 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>
> > > > > ---
> > > > > 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)
> > > >
> > > > Does this break compatibility with old samsung DTs ?
> > >
> > > My goal here was to declutter the device tree stuff and fetch data
> > > automatically if possible. What if I changed this to make them
> > > optional? If they exist, we can use them, if they don't exist, we
> > > could read the clock rate. Would that be acceptable?
> >
> > If you do not see any potential problem with ignoring the DT property
> > altogether, that would be better of course, but I think you cannot do
> > that with old DTs, so you should retain backward compatibility fallback,
> > yes. What do you think ?
>
> I'm very much in favor of this patch, but I also think we shouldn't
> risk breaking Samsung devices, where we don't now 100% that the input
> clock rate provided by the clock driver is correct.
>
> So I think the right approach is to use "samsung,pll-clock-frequency"
> when present in DT and get it from the clock provider otherwise. Then
> just remove the property from the DTs where we can validate that the
> input clock rate is correct, i.e. all i.MX8M*.
I'll update this accordingly when I do a V2 of this series.
adam
>
> Regards,
> Lucas
_______________________________________________
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 4/5] arm64: dts: ti: k3-j784s4-main: Add DSS and DP-bridge node
From: Jayesh Choudhary @ 2023-04-19 10:35 UTC (permalink / raw)
To: Krzysztof Kozlowski, nm, vigneshr, afd
Cc: s-vadapalli, kristo, robh+dt, krzysztof.kozlowski+dt,
linux-arm-kernel, devicetree, linux-kernel, a-bhatia1
In-Reply-To: <83c8bce1-f4e2-899e-46a9-0ba9da702572@linaro.org>
On 19/04/23 13:21, Krzysztof Kozlowski wrote:
> On 19/04/2023 08:17, Jayesh Choudhary wrote:
>> From: Rahul T R <r-ravikumar@ti.com>
>>
>> Add DSS and DP-bridge node for J784S4 SoC. DSS IP in J784S4 is
>> same as DSS IP in J721E, so same compatible is being used.
>> The DP is Cadence MHDP8546.
>>
>> Signed-off-by: Rahul T R <r-ravikumar@ti.com>
>> [j-choudhary@ti.com: move all k3-j784s4-main.dtsi changes together]
>> Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 77 ++++++++++++++++++++++
>> 1 file changed, 77 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> index 51aa476dedba..739741e93bc1 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
>> @@ -1373,4 +1373,81 @@ main_spi7: spi@2170000 {
>> clocks = <&k3_clks 383 1>;
>> status = "disabled";
>> };
>> +
>> + mhdp: dp-bridge@a000000 {
>> + compatible = "ti,j721e-mhdp8546";
>> +
>> + reg = <0x0 0xa000000 0x0 0x30a00>,
>> + <0x0 0x4f40000 0x0 0x20>;
>> + reg-names = "mhdptx", "j721e-intg";
>> +
>> + clocks = <&k3_clks 217 11>;
>> +
>> + interrupt-parent = <&gic500>;
>> + interrupts = <GIC_SPI 614 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + power-domains = <&k3_pds 217 TI_SCI_PD_EXCLUSIVE>;
>> +
>> + status = "disabled";
>> +
>> + dp0_ports: ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> + };
>> +
>> + dss: dss@4a00000 {
>> + compatible = "ti,j721e-dss";
>> + reg =
>> + <0x00 0x04a00000 0x00 0x10000>,
>
> Fix indent/stray line break.
>
>> + <0x00 0x04a10000 0x00 0x10000>,
>> + <0x00 0x04b00000 0x00 0x10000>,
>> + <0x00 0x04b10000 0x00 0x10000>,
>> +
>> + <0x00 0x04a20000 0x00 0x10000>,
>> + <0x00 0x04a30000 0x00 0x10000>,
>> + <0x00 0x04a50000 0x00 0x10000>,
>> + <0x00 0x04a60000 0x00 0x10000>,
>> +
>> + <0x00 0x04a70000 0x00 0x10000>,
>> + <0x00 0x04a90000 0x00 0x10000>,
>> + <0x00 0x04ab0000 0x00 0x10000>,
>> + <0x00 0x04ad0000 0x00 0x10000>,
>> +
>> + <0x00 0x04a80000 0x00 0x10000>,
>> + <0x00 0x04aa0000 0x00 0x10000>,
>> + <0x00 0x04ac0000 0x00 0x10000>,
>> + <0x00 0x04ae0000 0x00 0x10000>,
>> + <0x00 0x04af0000 0x00 0x10000>;
>> +
>> + reg-names = "common_m", "common_s0",
>> + "common_s1", "common_s2",
>> + "vidl1", "vidl2","vid1","vid2",
>> + "ovr1", "ovr2", "ovr3", "ovr4",
>> + "vp1", "vp2", "vp3", "vp4",
>> + "wb";
>> +
>> + clocks = <&k3_clks 218 0>,
>
> Broken indentation.
Indentation at both places are similar to j721e dss node.
Changes are needed in both?
-Jayesh
>
>
>
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 2/2] arm64: dts: add support for C3 based Amlogic AW409
From: Neil Armstrong @ 2023-04-19 10:23 UTC (permalink / raw)
To: =Xianwei Zhao, linux-arm-kernel, linux-kernel, linux-amlogic,
devicetree
Cc: Catalin Marinas, Will Deacon, Kevin Hilman, Rob Herring,
Krzysztof Kozlowski
In-Reply-To: <20230419073834.972273-3-xianwei.zhao@amlogic.com>
On 19/04/2023 09:38, =Xianwei Zhao wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Amlogic C3 is an advanced edge AI processor designed for smart IP camera
> applications.
>
> Add basic support for the C3 based Amlogic AW409 board, which describes
> the following components: CPU, GIC, IRQ, Timer, UART. It's capable of
> booting up into the serial console.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/Makefile | 1 +
> .../amlogic/amlogic-c3-c302x-aw409-256m.dts | 30 +++++++
> arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi | 87 +++++++++++++++++++
> 3 files changed, 118 insertions(+)
> create mode 100644 arch/arm64/boot/dts/amlogic/amlogic-c3-c302x-aw409-256m.dts
> create mode 100644 arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi
>
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
> index cd1c5b04890a..d2b5d0d750bc 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -74,3 +74,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air-gbit.dtb
> dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air.dtb
> +dtb-$(CONFIG_ARCH_AMLIPC) += amlogic-c3-c302x-aw409-256m.dtb
It's pointless to only build the c3 DTs here.
Neil
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-c3-c302x-aw409-256m.dts b/arch/arm64/boot/dts/amlogic/amlogic-c3-c302x-aw409-256m.dts
> new file mode 100644
> index 000000000000..38ca98a32181
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-c3-c302x-aw409-256m.dts
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Amlogic, Inc. All rights reserved.
> + */
> +
> +/dts-v1/;
> +
> +#include "amlogic-c3.dtsi"
> +
> +/ {
> + model = "Amlogic C302 aw409 Development Board";
> + compatible = "amlogic,aw409", "amlogic,c3";
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + aliases {
> + serial0 = &uart_B;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x10000000>;
> + };
> +
> +};
> +
> +&uart_B {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi
> new file mode 100644
> index 000000000000..c69072ac57f5
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-c3.dtsi
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2021 Amlogic, Inc. All rights reserved.
> + */
> +
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a35";
> + reg = <0x0 0x0>;
> + enable-method = "psci";
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a35";
> + reg = <0x0 0x1>;
> + enable-method = "psci";
> + };
> +
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> + };
> +
> + psci {
> + compatible = "arm,psci-1.0";
> + method = "smc";
> + };
> +
> + xtal: xtal-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <24000000>;
> + clock-output-names = "xtal";
> + #clock-cells = <0>;
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + gic: interrupt-controller@fff01000 {
> + compatible = "arm,gic-400";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + reg = <0x0 0xfff01000 0 0x1000>,
> + <0x0 0xfff02000 0 0x2000>,
> + <0x0 0xfff04000 0 0x2000>,
> + <0x0 0xfff06000 0 0x2000>;
> + interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + };
> +
> + apb4: apb4@fe000000 {
> + compatible = "simple-bus";
> + reg = <0x0 0xfe000000 0x0 0x480000>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges = <0x0 0x0 0x0 0xfe000000 0x0 0x480000>;
> +
> + uart_B: serial@7a000 {
> + compatible = "amlogic,meson-g12a-uart";
> + reg = <0x0 0x7a000 0x0 0x18>;
> + interrupts = <GIC_SPI 169 IRQ_TYPE_EDGE_RISING>;
> + status = "disabled";
> + clocks = <&xtal>, <&xtal>, <&xtal>;
> + clock-names = "xtal", "pclk", "baud";
> + };
> +
> + };
> + };
> +};
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 1/2] arm64: amlogic: add new ARCH_AMLIPC for IPC SoC
From: Neil Armstrong @ 2023-04-19 10:22 UTC (permalink / raw)
To: =Xianwei Zhao, linux-arm-kernel, linux-kernel, linux-amlogic,
devicetree
Cc: Catalin Marinas, Will Deacon, Kevin Hilman, Rob Herring,
Krzysztof Kozlowski
In-Reply-To: <20230419073834.972273-2-xianwei.zhao@amlogic.com>
Hi,
On 19/04/2023 09:38, =Xianwei Zhao wrote:
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> The C series SoCs are designed for smart IP camera
> applications, which does not belong to Meson series.
> So, Add ARCH_AMLIPC for the new series.
>
> There are now multiple amlogic SoC seies supported, so group them under
> their own menu. we can easily add new platforms there in the future.
> Introduce ARCH_AMLOGIC to cover all Amlogic SoC series.
There's no strong reason to add a new ARCH here, apart willing to kill
the MESON name, but it's usual to keep a arch naming from the first
SoC family supported, it doesn't mean the new aren't supported or
whatever, it's only a simple config name.
I understand the new SoCs are a new family, but they still share a lot of
IPs and driver that are present and supported on the Meson SoCs.
Please concentrate on adding the DTs and compatibles, changing the
current config and driver names is low priority unless there's a really
strong reason.
It's perfectly ok to drop meson for new configs, new driver & new bindings,
and it's already the case for the A1 SPIFC driver and most new G12/SM1
compatibles.
Neil
>
> No functional changes introduced.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> arch/arm64/Kconfig.platforms | 12 ++++++++++++
> arch/arm64/configs/defconfig | 2 ++
> 2 files changed, 14 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 89a0b13b058d..bfbc817eef8f 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -162,12 +162,24 @@ config ARCH_MEDIATEK
> This enables support for MediaTek MT27xx, MT65xx, MT76xx
> & MT81xx ARMv8 SoCs
>
> +menuconfig ARCH_AMLOGIC
> + bool "NXP SoC support"
> +
> +if ARCH_AMLOGIC
> +
> config ARCH_MESON
> bool "Amlogic Platforms"
> help
> This enables support for the arm64 based Amlogic SoCs
> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>
> +config ARCH_AMLIPC
> + bool "Amlogic IPC Platforms"
> + help
> + This enables support for the arm64 based Amlogic IPC SoCs
> + such as the C302X, C308L
> +endif
> +
> config ARCH_MVEBU
> bool "Marvell EBU SoC Family"
> select ARMADA_AP806_SYSCON
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 7790ee42c68a..f231bd1723fd 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -46,7 +46,9 @@ CONFIG_ARCH_LG1K=y
> CONFIG_ARCH_HISI=y
> CONFIG_ARCH_KEEMBAY=y
> CONFIG_ARCH_MEDIATEK=y
> +CONFIG_ARCH_AMLOGIC=y
> CONFIG_ARCH_MESON=y
> +CONFIG_ARCH_AMLIPC=y
> CONFIG_ARCH_MVEBU=y
> CONFIG_ARCH_NXP=y
> CONFIG_ARCH_LAYERSCAPE=y
_______________________________________________
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] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Eric Auger @ 2023-04-19 10:21 UTC (permalink / raw)
To: Dan Carpenter, Andre Przywara
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Steven Price, linux-arm-kernel,
kvmarm, kernel-janitors
In-Reply-To: <4efbab8c-640f-43b2-8ac6-6d68e08280fe@kili.mountain>
On 4/19/23 12:16, Dan Carpenter wrote:
> The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
> between 0-32768 but if it is more than sizeof(long) this will corrupt
> memory.
>
> Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
> v2: The original patch was okay but checking for != sizeof(val) is
> stricter and more Obviously Correct[tm]. Return -ENOENT instead of
> -EINVAL in case future ioctls are added which take a different size.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Eric
>
> arch/arm64/kvm/hypercalls.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 2e16fc7b31bf..7fb4df0456de 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -544,6 +544,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> u64 val;
> int wa_level;
>
> + if (KVM_REG_SIZE(reg->id) != sizeof(val))
> + return -ENOENT;
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
_______________________________________________
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 V22 2/3] misc: dcc: Add driver support for Data Capture and Compare unit(DCC)
From: Souradeep Chowdhury @ 2023-04-19 10:20 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman
Cc: Andy Gross, Konrad Dybcio, Krzysztof Kozlowski, Bjorn Andersson,
Rob Herring, Alex Elder, linux-arm-kernel, linux-kernel,
linux-arm-msm, devicetree, Sibi Sankar, Rajendra Nayak
In-Reply-To: <50844899-b047-42fd-807a-db7136e5e590@app.fastmail.com>
On 4/19/2023 1:00 PM, Arnd Bergmann wrote:
> On Wed, Apr 19, 2023, at 09:00, Souradeep Chowdhury wrote:
>> On 4/18/2023 9:15 PM, Greg Kroah-Hartman wrote:
>>>
>>>> The following is the justification of using debugfs interface over the
>>>> other alternatives like sysfs/ioctls
>>>>
>>>> i) As can be seen from the debugfs attribute descriptions, some of the
>>>> debugfs attribute files here contains multiple arguments which needs to
>>>> be accepted from the user. This goes against the design style of sysfs.
>>>>
>>>> ii) The user input patterns have been made simple and convenient in this
>>>> case with the use of debugfs interface as user doesn't need to shuffle
>>>> between different files to execute one instruction as was the case on
>>>> using other alternatives.
>>>
>>> Why do you have debugfs and also a misc device? How are they related?
>>> Why both? Why not just one? What userspace tools are going to use
>>> either of these interfaces and where are they published to show how this
>>> all was tested?
>>
>> DCC has two fundamental steps of usage:-
>>
>> 1.Configuring the register addresses on the dcc_sram which is done by
>> user through the debugfs interface. For example:-
>>
>> echo R 0x10c004 > /sys/kernel/debug/dcc/../3/config
>>
>> Here we are configuring the register addresses for list 3, the 'R'
>> indicates a read operation, so this register value will be read
>> in case of a software trigger or kernel panic/watchdog bite and
>> dumped into the dcc_sram.
>
> Can you describe why the register location needs to be
> runtime configurable? I would have expected this type of setting
> to be part of the devicetree, which already describes other
> parts that interact with sram devices.
Register addresses are made runtime configurable to give the user the
option of going for a software trigger. So the user can debug issues
during run-time as well. These register locations are arbitrary
and is configured by the user for debugging purposes and is not related
to the DCC hardware itself.
>
> How does a user ensure that the address they configure does
> not overlap with some other use of the sram?
The dcc_sram is a dedicated io-memory for exclusive usage by dcc.
The register addresses are programmed in the dcc_sram corresponding
to a particular list and the start and end location on dcc_sram for
a particular list is updated in dcc hardware registers. So no two
lists can overlap. This is ensured by the driver code as follows:-
/* 3. Program DCC_RAM_CFG reg */
dcc_list_writel(drvdata, ram_cfg_base +
drvdata->ram_offset / 4, curr_list, DCC_LL_BASE);
dcc_list_writel(drvdata, drvdata->ram_start +
drvdata->ram_offset / 4, curr_list, DCC_FD_BASE);
>
> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Fix buffer overflow in kvm_arm_set_fw_reg()
From: Steven Price @ 2023-04-19 10:17 UTC (permalink / raw)
To: Dan Carpenter, Andre Przywara
Cc: Oliver Upton, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Eric Auger, linux-arm-kernel,
kvmarm, kernel-janitors
In-Reply-To: <4efbab8c-640f-43b2-8ac6-6d68e08280fe@kili.mountain>
On 19/04/2023 11:16, Dan Carpenter wrote:
> The KVM_REG_SIZE() comes from the ioctl and it can be a power of two
> between 0-32768 but if it is more than sizeof(long) this will corrupt
> memory.
>
> Fixes: 99adb567632b ("KVM: arm/arm64: Add save/restore support for firmware workaround state")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Steven Price <steven.price@arm.com>
Thanks,
Steve
> ---
> v2: The original patch was okay but checking for != sizeof(val) is
> stricter and more Obviously Correct[tm]. Return -ENOENT instead of
> -EINVAL in case future ioctls are added which take a different size.
>
> arch/arm64/kvm/hypercalls.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 2e16fc7b31bf..7fb4df0456de 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -544,6 +544,8 @@ int kvm_arm_set_fw_reg(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
> u64 val;
> int wa_level;
>
> + if (KVM_REG_SIZE(reg->id) != sizeof(val))
> + return -ENOENT;
> if (copy_from_user(&val, uaddr, KVM_REG_SIZE(reg->id)))
> return -EFAULT;
>
_______________________________________________
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