* [PATCH v2] iommu: Ensure .iotlb_sync is called correctly
From: Robin Murphy @ 2026-04-09 12:59 UTC (permalink / raw)
To: will, joro; +Cc: iommu, linux-tegra, Jon Hunter, Jason Gunthorpe, Russell King
Many drivers have no reason to use the iotlb_gather mechanism, but do
still depend on .iotlb_sync being called to properly complete an unmap.
Missing or incomplete TLB maintenance at this point can then wreak all
kinds of havoc, particularly in strict DMA mode where IOVAs may be
reused right away, if DMA traffic for a subsequent new mapping hits a
stale TLB entry and goes to the wrong physical address.
Since the core code is now relying on the gather to detect when there
is legitimately something to sync, it should also take care of encoding
a successful unmap when the driver does not touch the gather itself.
Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
Reported-by: Jon Hunter <jonathanh@nvidia.com>
Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Add tags, clarify implications in commit message [rmk]
drivers/iommu/iommu.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 50718ab810a4..ee83850c7060 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2717,6 +2717,12 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
iova, unmapped_page);
+ /*
+ * If the driver itself isn't using the gather, make sure
+ * it looks non-empty so iotlb_sync will still be called.
+ */
+ if (iotlb_gather->start >= iotlb_gather->end)
+ iommu_iotlb_gather_add_range(iotlb_gather, iova, size);
iova += unmapped_page;
unmapped += unmapped_page;
--
2.39.2.101.g768bb238c484.dirty
^ permalink raw reply related
* Re: [PATCH 6.19 000/311] 6.19.12-rc1 review
From: Jon Hunter @ 2026-04-09 9:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr,
linux-tegra, stable
In-Reply-To: <20260408175939.393281918@linuxfoundation.org>
On Wed, 08 Apr 2026 20:00:00 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.19.12 release.
> There are 311 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.19.12-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.19:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 fail
Linux version: 6.19.12-rc1-g571831a3f83a
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra234-p3737-0000+p3701-0000,
tegra234-p3768-0000+p3767-0005, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply
* Re: [PATCH 6.18 000/277] 6.18.22-rc1 review
From: Jon Hunter @ 2026-04-09 9:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr,
linux-tegra, stable
In-Reply-To: <20260408175933.836769063@linuxfoundation.org>
On Wed, 08 Apr 2026 19:59:45 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.18.22 release.
> There are 277 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.22-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.18.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.18:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 fail
Linux version: 6.18.22-rc1-gef4577f805c0
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra234-p3737-0000+p3701-0000,
tegra234-p3768-0000+p3767-0005, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply
* Re: [PATCH 6.12 000/242] 6.12.81-rc1 review
From: Jon Hunter @ 2026-04-09 9:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr,
linux-tegra, stable
In-Reply-To: <20260408175927.064985309@linuxfoundation.org>
On Wed, 08 Apr 2026 20:00:40 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.12.81 release.
> There are 242 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.81-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.12.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.12:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 fail
Linux version: 6.12.81-rc1-g725a3d574146
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra234-p3737-0000+p3701-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply
* Re: [PATCH 6.6 000/160] 6.6.134-rc1 review
From: Jon Hunter @ 2026-04-09 9:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr,
linux-tegra, stable
In-Reply-To: <20260408175913.177092714@linuxfoundation.org>
On Wed, 08 Apr 2026 20:01:27 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.6.134 release.
> There are 160 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.6.134-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.6:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 fail
Linux version: 6.6.134-rc1-g69a5401c4693
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra234-p3737-0000+p3701-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply
* Re: [PATCH 6.1 000/312] 6.1.168-rc1 review
From: Jon Hunter @ 2026-04-09 9:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, patches, linux-kernel, torvalds, akpm, linux,
shuah, patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, rwarsow, conor, hargar, broonie, achill, sr,
linux-tegra, stable
In-Reply-To: <20260408175933.715315542@linuxfoundation.org>
On Wed, 08 Apr 2026 19:58:37 +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.1.168 release.
> There are 312 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri, 10 Apr 2026 17:58:42 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.1.168-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.1.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v6.1:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
132 tests: 132 pass, 0 fail
Linux version: 6.1.168-rc1-g4de16baaa1ea
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply
* Re: [PATCH v8 12/14] PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well
From: Manikanta Maddireddy @ 2026-04-09 8:51 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260408222409.GA329776@bhelgaas>
On 09/04/26 3:54 am, Bjorn Helgaas wrote:
> On Wed, Mar 25, 2026 at 12:37:53AM +0530, Manikanta Maddireddy wrote:
>> The ECRC (TLP digest) workaround was originally added for DesignWare
>> version 4.90a. Tegra234 SoC has 5.00a DWC HW version, which has
>> the same ATU TD override behaviour, so apply the workaround for 5.00a
>> too.
>>
>> Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support")
>> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
>> Tested-by: Jon Hunter <jonathanh@nvidia.com>
>> Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> ---
>> Changes V8: Split into two patches
>> Changes V1 -> V7: None
>>
>> drivers/pci/controller/dwc/pcie-designware.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
>> index 345365ea97c7..c4dc2d88649e 100644
>> --- a/drivers/pci/controller/dwc/pcie-designware.c
>> +++ b/drivers/pci/controller/dwc/pcie-designware.c
>> @@ -486,7 +486,7 @@ static inline void dw_pcie_writel_atu_ob(struct dw_pcie *pci, u32 index, u32 reg
>> static inline u32 dw_pcie_enable_ecrc(u32 val)
>> {
>> /*
>> - * DesignWare core version 4.90A has a design issue where the 'TD'
>> + * DWC versions 0x3530302a and 0x3536322a has a design issue where the 'TD'
>
> 0x3536322a looks like DW_PCIE_VER_562A, not DW_PCIE_VER_500A, so this
> comment doesn't seem to match the commit log or the code.
>
> "0x3530302a and 0x3536322a" is not nearly as readable as 4.90A and
> 5.00A.
>
>> * bit in the Control register-1 of the ATU outbound region acts
>> * like an override for the ECRC setting, i.e., the presence of TLP
>> * Digest (ECRC) in the outgoing TLPs is solely determined by this
>> @@ -559,7 +559,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
>> if (upper_32_bits(limit_addr) > upper_32_bits(parent_bus_addr) &&
>> dw_pcie_ver_is_ge(pci, 460A))
>> val |= PCIE_ATU_INCREASE_REGION_SIZE;
>> - if (dw_pcie_ver_is(pci, 490A))
>> + if (dw_pcie_ver_is(pci, 490A) || dw_pcie_ver_is(pci, 500A))
>> val = dw_pcie_enable_ecrc(val);
>
> This is in shared DWC code, which raises the question of whether this
> issue applies *only* to 490A and 500A? What about other versions,
> e.g., 520A (unused AFAICS), 540A, 562A?
>
Hi Bjorn,
I reviewed our internal bug database, I found that this dependency of
iATU TD bit on ECRC is removed from version 5.10A. A comment from
Synopsys case is quoted in our internal bug. Shall I prepare patch to
address this for all versions < 5.10A? Or do we need inputs from Synopsys?
Proposed patch
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -486,7 +486,7 @@ static inline void dw_pcie_writel_atu_ob(struct
dw_pcie *pci, u32 index, u32 reg
static inline u32 dw_pcie_enable_ecrc(u32 val)
{
/*
- * DWC versions 0x3530302a and 0x3536322a has a design issue
where the 'TD'
+ * DWC versions less than 5.10A has a design issue where the 'TD'
* bit in the Control register-1 of the ATU outbound region acts
* like an override for the ECRC setting, i.e., the presence of TLP
* Digest (ECRC) in the outgoing TLPs is solely determined by this
@@ -559,7 +559,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
if (upper_32_bits(limit_addr) > upper_32_bits(parent_bus_addr) &&
dw_pcie_ver_is_ge(pci, 460A))
val |= PCIE_ATU_INCREASE_REGION_SIZE;
- if (dw_pcie_ver_is(pci, 490A) || dw_pcie_ver_is(pci, 500A))
+ if (!dw_pcie_ver_is_ge(pci, 510A))
val = dw_pcie_enable_ecrc(val);
dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h
b/drivers/pci/controller/dwc/pcie-designware.h
index 5bceadbd2c9f..00891adfd07d 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -35,6 +35,7 @@
#define DW_PCIE_VER_480A 0x3438302a
#define DW_PCIE_VER_490A 0x3439302a
#define DW_PCIE_VER_500A 0x3530302a
+#define DW_PCIE_VER_510A 0x3531302a
#define DW_PCIE_VER_520A 0x3532302a
#define DW_PCIE_VER_540A 0x3534302a
#define DW_PCIE_VER_562A 0x3536322a
Thanks,
Manikanta
>> dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
>>
>> --
>> 2.34.1
>>
--
nvpublic
^ permalink raw reply related
* Re: [PATCH] gpio: tegra: fix irq_release_resources calling enable instead of disable
From: Bartosz Golaszewski @ 2026-04-09 8:36 UTC (permalink / raw)
To: linusw, brgl, thierry.reding, jonathanh, Samasth Norway Ananda
Cc: Bartosz Golaszewski, linux-gpio, linux-tegra, linux-kernel
In-Reply-To: <20260407210247.1737938-1-samasth.norway.ananda@oracle.com>
On Tue, 07 Apr 2026 14:02:47 -0700, Samasth Norway Ananda wrote:
> tegra_gpio_irq_release_resources() erroneously calls tegra_gpio_enable()
> instead of tegra_gpio_disable(). When IRQ resources are released, the
> GPIO configuration bit (CNF) should be cleared to deconfigure the pin as
> a GPIO. Leaving it enabled wastes power and can cause unexpected behavior
> if the pin is later reused for an alternate function via pinctrl.
>
>
> [...]
Applied, thanks!
[1/1] gpio: tegra: fix irq_release_resources calling enable instead of disable
https://git.kernel.org/brgl/c/1561d96f5f55c1bca9ff047ace5813f4f244eea6
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: timestamp: Add Tegra264 support
From: Krzysztof Kozlowski @ 2026-04-09 8:05 UTC (permalink / raw)
To: Suneel Garapati
Cc: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260408212413.217692-2-suneelg@nvidia.com>
On Wed, Apr 08, 2026 at 09:24:11PM +0000, Suneel Garapati wrote:
> Add timestamp provider support for the Tegra264 in devicetree
> bindings. Tegra264 has two generic timestamping engines (GTE)
> which are the always-on GTE (AON) and legacy interrupt
> controller (LIC) GTE.
> 'nvidia,slices' property is deprecated and hence not allowed for
> Tegra264.
>
> Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/1] PCI: tegra194: fix min() signedness when capping ASPM L1 entrance latency
From: Manikanta Maddireddy @ 2026-04-09 7:05 UTC (permalink / raw)
To: David Laight, bhelgaas, mani
Cc: lpieralisi, kwilczynski, robh, krzk+dt, conor+dt, thierry.reding,
jonathanh, kishon, arnd, gregkh, Frank.Li, den, hongxing.zhu,
jingoohan1, vidyas, cassel, 18255117159, linux-pci, linux-tegra,
linux-kernel, kernel test robot
In-Reply-To: <20260408125827.7063fd83@pumpkin>
On 08/04/26 5:28 pm, David Laight wrote:
> On Tue, 7 Apr 2026 20:27:49 +0530
> Manikanta Maddireddy <mmaddireddy@nvidia.com> wrote:
>
>> The DT property "aspm-l1-entry-delay-ns" is converted to microseconds,
>> then encoded for the L1 entrance latency register field as ilog2(us) + 1,
>> clamped to the hardware maximum of 7.
>>
>> ilog2() returns int type, while the upper bound is 7U (unsigned int).
>> The min() macro is implemented with __careful_cmp(), which rejects mixed
>> signed and unsigned operands at compile time via BUILD_BUG_ON_MSG in
>> minmax.h; that check trips on this pair, notably when building with W=1.
>>
>> This combination fails to build (e.g. parisc allyesconfig, GCC 15, as
>> reported by the 0-day bot).
>>
>> Use min_t(u32, ilog2(us) + 1U, 7U) so both sides of the comparison are
>> unsigned and consistent with aspm_l1_enter_lat.
>
> Adding 1U (rather than 1) is enough to make everything signed.
> Alternatively change the 7U to 7 and it will all be fine regardless of
> whether ilog2() returns a signed or unsigned result.
>
> Remember min_t(u32, x, y) is min((u32)x, (u32)y) and you wouldn't put in
> casts like that for any other arithmetic operation.
>
> Note that for the compile to fail there has to be a code path where
> ilog2(us) isn't known to generate a non-negative value.
> ilog2(us) (probably) ends up as 'fls(us) - 1'. If that is implemented using a
> compiler builtin (because there is a single instruction) then gcc knows that
> the input can't be zero (from the max()), so knows that fls() can't return 0
> (which it does for 0), so knows it is never negative and the checks in min()
> pass.
>
> parisc may be one of the architectures that ends up with a real function
> for fls() so the compiler doesn't know the result of ilog2() is
> non-negative.
>
> Just delete the U.
>
> David
Thank you David for the review.
Hi Bjorn, Mani,
Let me know if you are OK with David's suggestion, I will send new patch
as shown below
- pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
+ pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7);
>
>>
>> Fixes: 4a44cd65c9dd ("PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency")
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes: https://lore.kernel.org/oe-kbuild-all/202604051407.AODe3ddZ-lkp@intel.com/
>> ---
>> drivers/pci/controller/dwc/pcie-tegra194.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>> index 393f75ce3df3..93d3452ac117 100644
>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>> @@ -1147,7 +1147,7 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
>> if (!ret) {
>> u32 us = max(val / 1000, 1U);
>>
>> - pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
>> + pcie->aspm_l1_enter_lat = min_t(u32, ilog2(us) + 1U, 7U);
>> }
>>
>> ret = of_property_read_u32(np, "num-lanes", &pcie->num_lanes);
>
--
nvpublic
^ permalink raw reply
* Re: [PATCH v8 09/14] PCI: tegra194: Allow system suspend when the Endpoint link is not up
From: Manikanta Maddireddy @ 2026-04-09 6:59 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260408210323.GA316307@bhelgaas>
On 09/04/26 2:33 am, Bjorn Helgaas wrote:
> On Wed, Apr 08, 2026 at 03:59:59PM -0500, Bjorn Helgaas wrote:
>> On Wed, Mar 25, 2026 at 12:37:50AM +0530, Manikanta Maddireddy wrote:
>>> From: Vidya Sagar <vidyas@nvidia.com>
>>>
>>> Host software initiates the L2 sequence. PCIe link is kept in L2 state
>>> during suspend. If Endpoint mode is enabled and the link is up, the
>>> software cannot proceed with suspend. However, when the PCIe Endpoint
>>> driver is probed, but the PCIe link is not up, Tegra can go into suspend
>>> state. So, allow system to suspend in this case.
>>
>>> +static int tegra_pcie_dw_suspend(struct device *dev)
>>> {
>>> struct tegra_pcie_dw *pcie = dev_get_drvdata(dev);
>>> - u32 val;
>>>
>>> if (pcie->of_data->mode == DW_PCIE_EP_TYPE) {
>>> - dev_err(dev, "Failed to Suspend as Tegra PCIe is in EP mode\n"); > - return -EPERM;
>>> + if (pcie->ep_state == EP_STATE_ENABLED) {
>>> + dev_err(dev, "Tegra PCIe is in EP mode, suspend not allowed\n");
>>
>> Should this message say something about endpoint suspend not being
>> allowed because the link is up? IIUC, the endpoint *can* suspend if
>> the link is down.
>
> Oh, and I forgot: the subject line says "allow *system* suspend", but
> it looks like this patch is concerned with *endpoint* suspend.
>
> I assume that whatever an endpoint does, it can't prevent the host
> from suspending? I guess I'm just confused about the usage of "system
> suspend" in the subject line and commit message -- does "system" refer
> to the host or the endpoint?
Hi Bjorn,
System refers to the SoC which has a PCIe controller configured in
Endpoint mode.
Thanks,
Manikanta
--
nvpublic
^ permalink raw reply
* Re: [PATCH v8 9/9] PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency
From: Manikanta Maddireddy @ 2026-04-09 5:56 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260408223027.GA371101@bhelgaas>
On 09/04/26 4:00 am, Bjorn Helgaas wrote:
> On Wed, Mar 25, 2026 at 12:40:00AM +0530, Manikanta Maddireddy wrote:
>> Program ASPM L1 entrance latency from the optional aspm-l1-entry-delay-ns
>> device tree property instead of of_data. Convert the value from nanoseconds
>> to the hardware encoding (log2(us) + 1, 3-bit field). If the property is
>> absent, default to 7 (maximum latency).
>>
>> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
>> ---
>> Changes V8: Use aspm-l1-entry-delay-ns instead of of_data
>> Changes V1 -> V7: None
>>
>> drivers/pci/controller/dwc/pcie-tegra194.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
>> index 3278353b2c29..a856a48362df 100644
>> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
>> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
>> @@ -18,6 +18,7 @@
>> #include <linux/interrupt.h>
>> #include <linux/iopoll.h>
>> #include <linux/kernel.h>
>> +#include <linux/log2.h>
>> #include <linux/module.h>
>> #include <linux/of.h>
>> #include <linux/of_pci.h>
>> @@ -272,6 +273,7 @@ struct tegra_pcie_dw {
>> u32 aspm_cmrt;
>> u32 aspm_pwr_on_t;
>> u32 aspm_l0s_enter_lat;
>> + u32 aspm_l1_enter_lat;
>>
>> struct regulator *pex_ctl_supply;
>> struct regulator *slot_ctl_3v3;
>> @@ -710,6 +712,8 @@ static void init_host_aspm(struct tegra_pcie_dw *pcie)
>> val = dw_pcie_readl_dbi(pci, PCIE_PORT_AFR);
>> val &= ~PORT_AFR_L0S_ENTRANCE_LAT_MASK;
>> val |= (pcie->aspm_l0s_enter_lat << PORT_AFR_L0S_ENTRANCE_LAT_SHIFT);
>> + val &= ~PORT_AFR_L1_ENTRANCE_LAT_MASK;
>> + val |= (pcie->aspm_l1_enter_lat << PORT_AFR_L1_ENTRANCE_LAT_SHIFT);
>> val |= PORT_AFR_ENTER_ASPM;
>> dw_pcie_writel_dbi(pci, PCIE_PORT_AFR, val);
>> }
>> @@ -1110,6 +1114,7 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
>> {
>> struct platform_device *pdev = to_platform_device(pcie->dev);
>> struct device_node *np = pcie->dev->of_node;
>> + u32 val;
>> int ret;
>>
>> pcie->dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
>> @@ -1136,6 +1141,15 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
>> dev_info(pcie->dev,
>> "Failed to read ASPM L0s Entrance latency: %d\n", ret);
>>
>> + /* Default to max latency of 7. */
>> + pcie->aspm_l1_enter_lat = 7;
>> + ret = of_property_read_u32(np, "aspm-l1-entry-delay-ns", &val);
>> + if (!ret) {
>> + u32 us = max(val / 1000, 1U);
>> +
>> + pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
>
> I haven't investigated yet, but I see this build error on
> pci/controller/dwc-tegra194:
>
> CC drivers/pci/controller/dwc/pcie-tegra194.o
> In file included from <command-line>:
> In function ‘tegra_pcie_dw_parse_dt’,
> inlined from ‘tegra_pcie_dw_probe’ at drivers/pci/controller/dwc/pcie-tegra194.c:2148:8:
> ././include/linux/compiler_types.h:706:45: error: call to ‘__compiletime_assert_515’ declared with attribute error: min(( __builtin_constant_p(us) ? ((us) < 2 ? 0 : 63 - __builtin_clzll(us)) : (sizeof(us) <= 4) ? __ilog2_u32(us) : __ilog2_u64(us) ) + 1, 7U) signedness error
> 706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^
> ././include/linux/compiler_types.h:687:25: note: in definition of macro ‘__compiletime_assert’
> 687 | prefix ## suffix(); \
> | ^~~~~~
> ././include/linux/compiler_types.h:706:9: note: in expansion of macro ‘_compiletime_assert’
> 706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> | ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
> 39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> | ^~~~~~~~~~~~~~~~~~
> ./include/linux/minmax.h:93:9: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
> 93 | BUILD_BUG_ON_MSG(!__types_ok(ux, uy), \
> | ^~~~~~~~~~~~~~~~
> ./include/linux/minmax.h:98:9: note: in expansion of macro ‘__careful_cmp_once’
> 98 | __careful_cmp_once(op, x, y, __UNIQUE_ID(x_), __UNIQUE_ID(y_))
> | ^~~~~~~~~~~~~~~~~~
> ./include/linux/minmax.h:105:25: note: in expansion of macro ‘__careful_cmp’
> 105 | #define min(x, y) __careful_cmp(min, x, y)
> | ^~~~~~~~~~~~~
> drivers/pci/controller/dwc/pcie-tegra194.c:1155:43: note: in expansion of macro ‘min’
> 1155 | pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
> | ^~~
>
Hi Bjorn,
I don't see this error at my side, but kernel test robot reported this
error at
https://lore.kernel.org/oe-kbuild-all/202604051407.AODe3ddZ-lkp@intel.com/.
I published a patch
https://patchwork.kernel.org/project/linux-pci/patch/20260407145749.130753-1-mmaddireddy@nvidia.com/
to fix this issue.
Could you provide me your build environmental details like which tool
chain and make command are you using? I will incorporate these steps so
that I can avoid mistakes like these in future.
Thanks,
Manikanta
--
nvpublic
^ permalink raw reply
* Re: [PATCH v8 9/9] PCI: tegra194: Use aspm-l1-entry-delay-ns DT property for L1 entrance latency
From: Bjorn Helgaas @ 2026-04-08 22:30 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260324191000.1095768-10-mmaddireddy@nvidia.com>
On Wed, Mar 25, 2026 at 12:40:00AM +0530, Manikanta Maddireddy wrote:
> Program ASPM L1 entrance latency from the optional aspm-l1-entry-delay-ns
> device tree property instead of of_data. Convert the value from nanoseconds
> to the hardware encoding (log2(us) + 1, 3-bit field). If the property is
> absent, default to 7 (maximum latency).
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> Changes V8: Use aspm-l1-entry-delay-ns instead of of_data
> Changes V1 -> V7: None
>
> drivers/pci/controller/dwc/pcie-tegra194.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 3278353b2c29..a856a48362df 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -18,6 +18,7 @@
> #include <linux/interrupt.h>
> #include <linux/iopoll.h>
> #include <linux/kernel.h>
> +#include <linux/log2.h>
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_pci.h>
> @@ -272,6 +273,7 @@ struct tegra_pcie_dw {
> u32 aspm_cmrt;
> u32 aspm_pwr_on_t;
> u32 aspm_l0s_enter_lat;
> + u32 aspm_l1_enter_lat;
>
> struct regulator *pex_ctl_supply;
> struct regulator *slot_ctl_3v3;
> @@ -710,6 +712,8 @@ static void init_host_aspm(struct tegra_pcie_dw *pcie)
> val = dw_pcie_readl_dbi(pci, PCIE_PORT_AFR);
> val &= ~PORT_AFR_L0S_ENTRANCE_LAT_MASK;
> val |= (pcie->aspm_l0s_enter_lat << PORT_AFR_L0S_ENTRANCE_LAT_SHIFT);
> + val &= ~PORT_AFR_L1_ENTRANCE_LAT_MASK;
> + val |= (pcie->aspm_l1_enter_lat << PORT_AFR_L1_ENTRANCE_LAT_SHIFT);
> val |= PORT_AFR_ENTER_ASPM;
> dw_pcie_writel_dbi(pci, PCIE_PORT_AFR, val);
> }
> @@ -1110,6 +1114,7 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
> {
> struct platform_device *pdev = to_platform_device(pcie->dev);
> struct device_node *np = pcie->dev->of_node;
> + u32 val;
> int ret;
>
> pcie->dbi_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi");
> @@ -1136,6 +1141,15 @@ static int tegra_pcie_dw_parse_dt(struct tegra_pcie_dw *pcie)
> dev_info(pcie->dev,
> "Failed to read ASPM L0s Entrance latency: %d\n", ret);
>
> + /* Default to max latency of 7. */
> + pcie->aspm_l1_enter_lat = 7;
> + ret = of_property_read_u32(np, "aspm-l1-entry-delay-ns", &val);
> + if (!ret) {
> + u32 us = max(val / 1000, 1U);
> +
> + pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
I haven't investigated yet, but I see this build error on
pci/controller/dwc-tegra194:
CC drivers/pci/controller/dwc/pcie-tegra194.o
In file included from <command-line>:
In function ‘tegra_pcie_dw_parse_dt’,
inlined from ‘tegra_pcie_dw_probe’ at drivers/pci/controller/dwc/pcie-tegra194.c:2148:8:
././include/linux/compiler_types.h:706:45: error: call to ‘__compiletime_assert_515’ declared with attribute error: min(( __builtin_constant_p(us) ? ((us) < 2 ? 0 : 63 - __builtin_clzll(us)) : (sizeof(us) <= 4) ? __ilog2_u32(us) : __ilog2_u64(us) ) + 1, 7U) signedness error
706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^
././include/linux/compiler_types.h:687:25: note: in definition of macro ‘__compiletime_assert’
687 | prefix ## suffix(); \
| ^~~~~~
././include/linux/compiler_types.h:706:9: note: in expansion of macro ‘_compiletime_assert’
706 | _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~
./include/linux/minmax.h:93:9: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
93 | BUILD_BUG_ON_MSG(!__types_ok(ux, uy), \
| ^~~~~~~~~~~~~~~~
./include/linux/minmax.h:98:9: note: in expansion of macro ‘__careful_cmp_once’
98 | __careful_cmp_once(op, x, y, __UNIQUE_ID(x_), __UNIQUE_ID(y_))
| ^~~~~~~~~~~~~~~~~~
./include/linux/minmax.h:105:25: note: in expansion of macro ‘__careful_cmp’
105 | #define min(x, y) __careful_cmp(min, x, y)
| ^~~~~~~~~~~~~
drivers/pci/controller/dwc/pcie-tegra194.c:1155:43: note: in expansion of macro ‘min’
1155 | pcie->aspm_l1_enter_lat = min(ilog2(us) + 1, 7U);
| ^~~
^ permalink raw reply
* Re: [PATCH v8 12/14] PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well
From: Bjorn Helgaas @ 2026-04-08 22:24 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260324190755.1094879-13-mmaddireddy@nvidia.com>
On Wed, Mar 25, 2026 at 12:37:53AM +0530, Manikanta Maddireddy wrote:
> The ECRC (TLP digest) workaround was originally added for DesignWare
> version 4.90a. Tegra234 SoC has 5.00a DWC HW version, which has
> the same ATU TD override behaviour, so apply the workaround for 5.00a
> too.
>
> Fixes: a54e19073718 ("PCI: tegra194: Add Tegra234 PCIe support")
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Vidya Sagar <vidyas@nvidia.com>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> Changes V8: Split into two patches
> Changes V1 -> V7: None
>
> drivers/pci/controller/dwc/pcie-designware.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c b/drivers/pci/controller/dwc/pcie-designware.c
> index 345365ea97c7..c4dc2d88649e 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -486,7 +486,7 @@ static inline void dw_pcie_writel_atu_ob(struct dw_pcie *pci, u32 index, u32 reg
> static inline u32 dw_pcie_enable_ecrc(u32 val)
> {
> /*
> - * DesignWare core version 4.90A has a design issue where the 'TD'
> + * DWC versions 0x3530302a and 0x3536322a has a design issue where the 'TD'
0x3536322a looks like DW_PCIE_VER_562A, not DW_PCIE_VER_500A, so this
comment doesn't seem to match the commit log or the code.
"0x3530302a and 0x3536322a" is not nearly as readable as 4.90A and
5.00A.
> * bit in the Control register-1 of the ATU outbound region acts
> * like an override for the ECRC setting, i.e., the presence of TLP
> * Digest (ECRC) in the outgoing TLPs is solely determined by this
> @@ -559,7 +559,7 @@ int dw_pcie_prog_outbound_atu(struct dw_pcie *pci,
> if (upper_32_bits(limit_addr) > upper_32_bits(parent_bus_addr) &&
> dw_pcie_ver_is_ge(pci, 460A))
> val |= PCIE_ATU_INCREASE_REGION_SIZE;
> - if (dw_pcie_ver_is(pci, 490A))
> + if (dw_pcie_ver_is(pci, 490A) || dw_pcie_ver_is(pci, 500A))
> val = dw_pcie_enable_ecrc(val);
This is in shared DWC code, which raises the question of whether this
issue applies *only* to 490A and 500A? What about other versions,
e.g., 520A (unused AFAICS), 540A, 562A?
> dw_pcie_writel_atu_ob(pci, atu->index, PCIE_ATU_REGION_CTRL1, val);
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: tegra210_adx: simplify byte map get/put logic
From: Piyush Patle @ 2026-04-08 21:25 UTC (permalink / raw)
To: Mark Brown
Cc: Sheetal, Jonathan Hunter, Thierry Reding, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Kuninori Morimoto, linux-sound,
linux-tegra, linux-kernel
In-Reply-To: <ae440ab7-e1ba-4f38-8ef9-85371f3236f0@sirena.org.uk>
> > +static int tegra210_adx_write_map_ram(struct tegra210_adx *adx)
> > {
> > + const unsigned int bits_per_mask = BITS_PER_TYPE(*adx->map) * BITS_PER_BYTE;
>
> Why are we multiplying by BITS_PER_BYTE here? We've got a number of
> bits already from BITS_PER_TYPE().
Okay correct, that's a bug BITS_PER_TYPE() already returns bits,
so the extra * BITS_PER_BYTE is a unit error. It also references
the wrong type: the bitmap word is unsigned int (which is what the
original code's hard-coded 32 came from), not the map element type.
For v3 I'll change it to:
const unsigned int bits_per_mask = BITS_PER_TYPE(*adx->byte_mask);
>
> > + for (i = 0; i < adx->soc_data->ram_depth; i++) {
> > + u32 word = 0;
> > + int b;
> > +
> > + for (b = 0; b < TEGRA_ADX_SLOTS_PER_WORD; b++) {
> > + unsigned int slot = i * TEGRA_ADX_SLOTS_PER_WORD + b;
> > + u16 val = adx->map[slot];
> > +
> > + if (val >= 256)
> > + continue;
> > +
> > + word |= (u32)val << (b * BITS_PER_BYTE);
> > + byte_mask[slot / bits_per_mask] |= 1U << (slot % bits_per_mask);
>
> How big can bits_per_mask get?
With the fix above, bits_per_mask == BITS_PER_TYPE(unsigned int) ==
32,
matching the original "slot / 32" / "slot % 32" expressions exactly.
>
> > @@ -118,9 +144,7 @@ static int tegra210_adx_runtime_resume(struct device *dev)
> > regcache_cache_only(adx->regmap, false);
> > regcache_sync(adx->regmap);
> >
> > - tegra210_adx_write_map_ram(adx);
> > -
> > - return 0;
> > + return tegra210_adx_write_map_ram(adx);
>
> We need to unwind at least the regcache_cache_only() above if resume
> fails.
As per Jon's comment on the same patch, I'm moving the
byte_mask buffer back to a probe-time devm_kcalloc() in v3, so
write_map_ram() no longer has a failure path. runtime_resume() will
go back to returning 0 unconditionally and the regcache_cache_only()
unwind won't be needed. If write_map_ram() ever grows another failure
mode in the future, the unwind would have to be added then.
Thanks
Piyush Patle
^ permalink raw reply
* [PATCH v2 3/3] arm64: tegra: Add GTE nodes for Tegra264
From: Suneel Garapati @ 2026-04-08 21:24 UTC (permalink / raw)
To: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
Cc: Suneel Garapati
In-Reply-To: <20260408212413.217692-1-suneelg@nvidia.com>
Add AON GPIO and system LIC GTE instances for Tegra264.
Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra264.dtsi b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
index 06d8357bdf52..c6630733d5e3 100644
--- a/arch/arm64/boot/dts/nvidia/tegra264.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra264.dtsi
@@ -3207,6 +3207,15 @@ agic_page5: interrupt-controller@99b0000 {
};
};
+ hte_lic: hardware-timestamp@8380000 {
+ compatible = "nvidia,tegra264-gte-lic";
+ reg = <0x0 0x08380000 0x0 0x10000>;
+ interrupts = <GIC_SPI 0x00000268 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ #timestamp-cells = <1>;
+ status = "disabled";
+ };
+
gpcdma: dma-controller@8400000 {
compatible = "nvidia,tegra264-gpcdma", "nvidia,tegra186-gpcdma";
reg = <0x0 0x08400000 0x0 0x210000>;
@@ -3267,6 +3276,16 @@ hsp_top: hsp@8800000 {
#mbox-cells = <2>;
};
+ hte_aon: hardware-timestamp@c2b0000 {
+ compatible = "nvidia,tegra264-gte-aon";
+ reg = <0x0 0x0c2b0000 0x0 0x10000>;
+ interrupts = <GIC_SPI 0x00000226 IRQ_TYPE_LEVEL_HIGH>;
+ nvidia,int-threshold = <1>;
+ #timestamp-cells = <1>;
+ nvidia,gpio-controller = <&gpio_aon>;
+ status = "disabled";
+ };
+
rtc: rtc@c2c0000 {
compatible = "nvidia,tegra264-rtc", "nvidia,tegra20-rtc";
reg = <0x0 0x0c2c0000 0x0 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/3] hte: tegra194: Add Tegra264 GTE support
From: Suneel Garapati @ 2026-04-08 21:24 UTC (permalink / raw)
To: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
Cc: Suneel Garapati
In-Reply-To: <20260408212413.217692-1-suneelg@nvidia.com>
Add AON-GTE mapping and LIC GTE instance support for the Tegra264.
Move TSC clock parameters from macros to members of SoC data
as values differ for Tegra264 chip.
Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
drivers/hte/hte-tegra194.c | 133 +++++++++++++++++++++++++++++++++++--
1 file changed, 128 insertions(+), 5 deletions(-)
diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
index 690eb9be30fb..4a7702b32b24 100644
--- a/drivers/hte/hte-tegra194.c
+++ b/drivers/hte/hte-tegra194.c
@@ -20,10 +20,11 @@
#define HTE_SUSPEND 0
-/* HTE source clock TSC is 31.25MHz */
+/* HTE source clock TSC is 1GHz for T264 and 31.25MHz for others */
#define HTE_TS_CLK_RATE_HZ 31250000ULL
+#define HTE_TS_CLK_RATE_1G 1000000000ULL
#define HTE_CLK_RATE_NS 32
-#define HTE_TS_NS_SHIFT __builtin_ctz(HTE_CLK_RATE_NS)
+#define HTE_CLK_RATE_NS_1G 1
#define NV_AON_SLICE_INVALID -1
#define NV_LINES_IN_SLICE 32
@@ -120,6 +121,8 @@ struct tegra_hte_data {
u32 slices;
u32 map_sz;
u32 sec_map_sz;
+ u64 tsc_clkrate_hz;
+ u32 tsc_clkrate_ns;
const struct tegra_hte_line_mapped *map;
const struct tegra_hte_line_mapped *sec_map;
};
@@ -317,6 +320,94 @@ static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
[40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
};
+static const struct tegra_hte_line_mapped tegra264_aon_gpio_map[] = {
+ /* gpio, slice, bit_index */
+ /* AA port */
+ [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
+ [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
+ [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
+ [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
+ [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
+ [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
+ [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
+ [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
+ /* BB port */
+ [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
+ [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
+ /* CC port */
+ [10] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
+ [11] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
+ [12] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
+ [13] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
+ [14] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
+ [15] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
+ [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
+ [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
+ /* DD port */
+ [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
+ [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
+ [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
+ [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
+ [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
+ [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
+ [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
+ [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
+ /* EE port */
+ [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
+ [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
+ [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
+ [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
+};
+
+static const struct tegra_hte_line_mapped tegra264_aon_gpio_sec_map[] = {
+ /* gpio, slice, bit_index */
+ /* AA port */
+ [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
+ [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
+ [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
+ [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
+ [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
+ [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
+ [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
+ [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
+ /* BB port */
+ [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
+ [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
+ [10] = {NV_AON_SLICE_INVALID, 0},
+ [11] = {NV_AON_SLICE_INVALID, 0},
+ [12] = {NV_AON_SLICE_INVALID, 0},
+ [13] = {NV_AON_SLICE_INVALID, 0},
+ [14] = {NV_AON_SLICE_INVALID, 0},
+ [15] = {NV_AON_SLICE_INVALID, 0},
+ /* CC port */
+ [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
+ [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
+ [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
+ [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
+ [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
+ [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
+ [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
+ [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
+ /* DD port */
+ [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
+ [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
+ [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
+ [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
+ [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
+ [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
+ [30] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
+ [31] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
+ /* EE port */
+ [32] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
+ [33] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
+ [34] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
+ [35] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
+ [36] = {NV_AON_SLICE_INVALID, 0},
+ [37] = {NV_AON_SLICE_INVALID, 0},
+ [38] = {NV_AON_SLICE_INVALID, 0},
+ [39] = {NV_AON_SLICE_INVALID, 0},
+};
+
static const struct tegra_hte_data t194_aon_hte = {
.map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
.map = tegra194_aon_gpio_map,
@@ -324,6 +415,8 @@ static const struct tegra_hte_data t194_aon_hte = {
.sec_map = tegra194_aon_gpio_sec_map,
.type = HTE_TEGRA_TYPE_GPIO,
.slices = 3,
+ .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+ .tsc_clkrate_ns = HTE_CLK_RATE_NS,
};
static const struct tegra_hte_data t234_aon_hte = {
@@ -333,6 +426,19 @@ static const struct tegra_hte_data t234_aon_hte = {
.sec_map = tegra234_aon_gpio_sec_map,
.type = HTE_TEGRA_TYPE_GPIO,
.slices = 3,
+ .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+ .tsc_clkrate_ns = HTE_CLK_RATE_NS,
+};
+
+static const struct tegra_hte_data t264_aon_hte = {
+ .map_sz = ARRAY_SIZE(tegra264_aon_gpio_map),
+ .map = tegra264_aon_gpio_map,
+ .sec_map_sz = ARRAY_SIZE(tegra264_aon_gpio_sec_map),
+ .sec_map = tegra264_aon_gpio_sec_map,
+ .type = HTE_TEGRA_TYPE_GPIO,
+ .slices = 4,
+ .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
+ .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
};
static const struct tegra_hte_data t194_lic_hte = {
@@ -340,6 +446,8 @@ static const struct tegra_hte_data t194_lic_hte = {
.map = NULL,
.type = HTE_TEGRA_TYPE_LIC,
.slices = 11,
+ .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+ .tsc_clkrate_ns = HTE_CLK_RATE_NS,
};
static const struct tegra_hte_data t234_lic_hte = {
@@ -347,6 +455,17 @@ static const struct tegra_hte_data t234_lic_hte = {
.map = NULL,
.type = HTE_TEGRA_TYPE_LIC,
.slices = 17,
+ .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
+ .tsc_clkrate_ns = HTE_CLK_RATE_NS,
+};
+
+static const struct tegra_hte_data t264_lic_hte = {
+ .map_sz = 0,
+ .map = NULL,
+ .type = HTE_TEGRA_TYPE_LIC,
+ .slices = 10,
+ .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
+ .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
};
static inline u32 tegra_hte_readl(struct tegra_hte_soc *hte, u32 reg)
@@ -574,12 +693,12 @@ static int tegra_hte_release(struct hte_chip *chip, struct hte_ts_desc *desc,
static int tegra_hte_clk_src_info(struct hte_chip *chip,
struct hte_clk_info *ci)
{
- (void)chip;
+ struct tegra_hte_soc *hte_dev = chip->data;
if (!ci)
return -EINVAL;
- ci->hz = HTE_TS_CLK_RATE_HZ;
+ ci->hz = hte_dev->prov_data->tsc_clkrate_hz;
ci->type = CLOCK_MONOTONIC;
return 0;
@@ -602,8 +721,10 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
{
u32 tsh, tsl, src, pv, cv, acv, slice, bit_index, line_id;
u64 tsc;
+ u8 tsc_ns_shift;
struct hte_ts_data el;
+ tsc_ns_shift = __builtin_ctz(gs->prov_data->tsc_clkrate_ns);
while ((tegra_hte_readl(gs, HTE_TESTATUS) >>
HTE_TESTATUS_OCCUPANCY_SHIFT) &
HTE_TESTATUS_OCCUPANCY_MASK) {
@@ -621,7 +742,7 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
while (acv) {
bit_index = __builtin_ctz(acv);
line_id = bit_index + (slice << 5);
- el.tsc = tsc << HTE_TS_NS_SHIFT;
+ el.tsc = tsc << tsc_ns_shift;
el.raw_level = tegra_hte_get_level(gs, line_id);
hte_push_ts_ns(gs->chip, line_id, &el);
acv &= ~BIT(bit_index);
@@ -656,6 +777,8 @@ static const struct of_device_id tegra_hte_of_match[] = {
{ .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
{ .compatible = "nvidia,tegra234-gte-lic", .data = &t234_lic_hte},
{ .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
+ { .compatible = "nvidia,tegra264-gte-lic", .data = &t264_lic_hte},
+ { .compatible = "nvidia,tegra264-gte-aon", .data = &t264_aon_hte},
{ }
};
MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: timestamp: Add Tegra264 support
From: Suneel Garapati @ 2026-04-08 21:24 UTC (permalink / raw)
To: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
Cc: Suneel Garapati
In-Reply-To: <20260408212413.217692-1-suneelg@nvidia.com>
Add timestamp provider support for the Tegra264 in devicetree
bindings. Tegra264 has two generic timestamping engines (GTE)
which are the always-on GTE (AON) and legacy interrupt
controller (LIC) GTE.
'nvidia,slices' property is deprecated and hence not allowed for
Tegra264.
Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
---
v1:
- nvidia,slices property is deprecated and hence false for Tegra264
---
.../bindings/timestamp/nvidia,tegra194-hte.yaml | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
index 456797967adc..a96d6cd23895 100644
--- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
+++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
@@ -25,6 +25,8 @@ properties:
- nvidia,tegra194-gte-lic
- nvidia,tegra234-gte-aon
- nvidia,tegra234-gte-lic
+ - nvidia,tegra264-gte-aon
+ - nvidia,tegra264-gte-lic
reg:
maxItems: 1
@@ -112,10 +114,22 @@ allOf:
contains:
enum:
- nvidia,tegra234-gte-aon
+ - nvidia,tegra264-gte-aon
then:
required:
- nvidia,gpio-controller
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nvidia,tegra264-gte-aon
+ - nvidia,tegra264-gte-lic
+ then:
+ properties:
+ nvidia,slices: false
+
additionalProperties: false
examples:
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add Tegra264 HTE provider
From: Suneel Garapati @ 2026-04-08 21:24 UTC (permalink / raw)
To: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
Cc: Suneel Garapati
This patch series mainly adds support for the Tegra264 HTE provider.
- Update devicetree bindings to add Tegra264 support
- Add support in driver for Tegra264 chip including new tsc clock
parameters setup per SoC as values differ for Tegra264
- Populate device-tree nodes for Tegra264 GTE instances
- One of devicetree nodes has reference to gpio_aon node that is
dependent on this series [1]
1 - https://patchwork.ozlabs.org/project/linux-gpio/patch/20260128085114.1137725-3-pshete@nvidia.com/
---
Changes in v2:
- Devicetree bindings has nvidia,slices property deprecated for Tegra264
Suneel Garapati (3):
dt-bindings: timestamp: Add Tegra264 support
hte: tegra194: Add Tegra264 GTE support
arm64: tegra: Add GTE nodes for Tegra264
.../timestamp/nvidia,tegra194-hte.yaml | 14 ++
arch/arm64/boot/dts/nvidia/tegra264.dtsi | 19 +++
drivers/hte/hte-tegra194.c | 133 +++++++++++++++++-
3 files changed, 161 insertions(+), 5 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: tegra210_adx: simplify byte map get/put logic
From: Piyush Patle @ 2026-04-08 21:19 UTC (permalink / raw)
To: Jon Hunter
Cc: Mark Brown, Sheetal, Thierry Reding, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Kuninori Morimoto, linux-sound,
linux-tegra, linux-kernel
In-Reply-To: <f837da45-2b31-4788-a957-085d3f0570d0@nvidia.com>
On Wed, Apr 8, 2026 at 11:09 PM Jon Hunter <jonathanh@nvidia.com> wrote:
>
>
> On 08/04/2026 18:08, Piyush Patle wrote:
> > The byte-map controls ("Byte Map N") already expose a value range of
> > [0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the
> > "disabled" sentinel. The driver stored this state as a byte-packed
> > u32 map[] array plus a separate byte_mask[] bitmap tracking which
> > slots were enabled, because 256 does not fit in a byte. As a result
> > get_byte_map() had to consult byte_mask[] to decide whether to
> > report the stored byte or 256, and put_byte_map() had to keep the
> > two arrays in sync on every write.
> >
> > Store each slot as a u16 holding the control value directly
> > (0..255 enabled, 256 disabled). This is the native representation
> > for what userspace already sees, so get_byte_map() becomes a direct
> > return and put_byte_map() becomes a compare-and-store. The
> > hardware-facing packed RAM word and the IN_BYTE_EN mask are now
> > derived on the fly inside tegra210_adx_write_map_ram() from the
> > slot array, which is the only place that needs to know about the
> > hardware layout.
> >
> > The byte_mask scratch buffer is allocated dynamically using
> > kcalloc() based on soc_data->byte_mask_size, removing dependency
> > on SoC-specific constants. The byte_mask field is dropped from
> > struct tegra210_adx.
>
> So this was already the case. However ...
>
>
> > -static void tegra210_adx_write_map_ram(struct tegra210_adx *adx)
> > +static int tegra210_adx_write_map_ram(struct tegra210_adx *adx)
> > {
> > + const unsigned int bits_per_mask = BITS_PER_TYPE(*adx->map) * BITS_PER_BYTE;
> > + unsigned int *byte_mask;
> > int i;
> >
> > + byte_mask = kcalloc(adx->soc_data->byte_mask_size, sizeof(*byte_mask),
> > + GFP_KERNEL);
> > + if (!byte_mask)
> > + return -ENOMEM;
> > +
>
> Now you are allocating this everytime this function is called (which
> happens on RPM resume) instead of ...
You're right, I was wrong here. I read Sheetal's v1comment as
"allocate it dynamically" and over-corrected by moving the
allocation into write_map_ram() itself.
>
> > @@ -700,16 +706,15 @@ static int tegra210_adx_platform_probe(struct platform_device *pdev)
> >
> > regcache_cache_only(adx->regmap, true);
> >
> > - adx->map = devm_kzalloc(dev, soc_data->ram_depth * sizeof(*adx->map),
> > - GFP_KERNEL);
> > + adx->map = devm_kcalloc(dev,
> > + soc_data->ram_depth * TEGRA_ADX_SLOTS_PER_WORD,
> > + sizeof(*adx->map), GFP_KERNEL);
> > if (!adx->map)
> > return -ENOMEM;
> >
> > - adx->byte_mask = devm_kzalloc(dev,
> > - soc_data->byte_mask_size * sizeof(*adx->byte_mask),
> > - GFP_KERNEL);
> > - if (!adx->byte_mask)
> > - return -ENOMEM;
>
> ... here in the probe function, which makes more sense. IOW I am not
> sure why you have changed this.
>
>
The intent was only to drop the dependency on
the SoC-specific TEGRA264_*_BYTE_MASK_COUNT
constant; the lifetime should still be probe-scoped
For v3 I'll keep byte_mask as a member of struct tegra210_adx and
allocate it once in probe() with:
adx->byte_mask = devm_kcalloc(dev, soc_data->byte_mask_size,
sizeof(*adx->byte_mask),
GFP_KERNEL);
That keeps Sheetal's "no chip-specific constant" requirement (size
is still soc_data->byte_mask_size) while avoiding the per-RPM-resume
allocation.
I think that would be better, Right?
Same change in tegra210_amx.c.
^ permalink raw reply
* Re: [PATCH v8 09/14] PCI: tegra194: Allow system suspend when the Endpoint link is not up
From: Bjorn Helgaas @ 2026-04-08 21:03 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260408205958.GA316081@bhelgaas>
On Wed, Apr 08, 2026 at 03:59:59PM -0500, Bjorn Helgaas wrote:
> On Wed, Mar 25, 2026 at 12:37:50AM +0530, Manikanta Maddireddy wrote:
> > From: Vidya Sagar <vidyas@nvidia.com>
> >
> > Host software initiates the L2 sequence. PCIe link is kept in L2 state
> > during suspend. If Endpoint mode is enabled and the link is up, the
> > software cannot proceed with suspend. However, when the PCIe Endpoint
> > driver is probed, but the PCIe link is not up, Tegra can go into suspend
> > state. So, allow system to suspend in this case.
>
> > +static int tegra_pcie_dw_suspend(struct device *dev)
> > {
> > struct tegra_pcie_dw *pcie = dev_get_drvdata(dev);
> > - u32 val;
> >
> > if (pcie->of_data->mode == DW_PCIE_EP_TYPE) {
> > - dev_err(dev, "Failed to Suspend as Tegra PCIe is in EP mode\n"); > - return -EPERM;
> > + if (pcie->ep_state == EP_STATE_ENABLED) {
> > + dev_err(dev, "Tegra PCIe is in EP mode, suspend not allowed\n");
>
> Should this message say something about endpoint suspend not being
> allowed because the link is up? IIUC, the endpoint *can* suspend if
> the link is down.
Oh, and I forgot: the subject line says "allow *system* suspend", but
it looks like this patch is concerned with *endpoint* suspend.
I assume that whatever an endpoint does, it can't prevent the host
from suspending? I guess I'm just confused about the usage of "system
suspend" in the subject line and commit message -- does "system" refer
to the host or the endpoint?
^ permalink raw reply
* Re: [PATCH v8 09/14] PCI: tegra194: Allow system suspend when the Endpoint link is not up
From: Bjorn Helgaas @ 2026-04-08 20:59 UTC (permalink / raw)
To: Manikanta Maddireddy
Cc: bhelgaas, lpieralisi, kwilczynski, mani, robh, krzk+dt, conor+dt,
thierry.reding, jonathanh, kishon, arnd, gregkh, Frank.Li, den,
hongxing.zhu, jingoohan1, vidyas, cassel, 18255117159, linux-pci,
linux-tegra, linux-kernel
In-Reply-To: <20260324190755.1094879-10-mmaddireddy@nvidia.com>
On Wed, Mar 25, 2026 at 12:37:50AM +0530, Manikanta Maddireddy wrote:
> From: Vidya Sagar <vidyas@nvidia.com>
>
> Host software initiates the L2 sequence. PCIe link is kept in L2 state
> during suspend. If Endpoint mode is enabled and the link is up, the
> software cannot proceed with suspend. However, when the PCIe Endpoint
> driver is probed, but the PCIe link is not up, Tegra can go into suspend
> state. So, allow system to suspend in this case.
> +static int tegra_pcie_dw_suspend(struct device *dev)
> {
> struct tegra_pcie_dw *pcie = dev_get_drvdata(dev);
> - u32 val;
>
> if (pcie->of_data->mode == DW_PCIE_EP_TYPE) {
> - dev_err(dev, "Failed to Suspend as Tegra PCIe is in EP mode\n"); > - return -EPERM;
> + if (pcie->ep_state == EP_STATE_ENABLED) {
> + dev_err(dev, "Tegra PCIe is in EP mode, suspend not allowed\n");
Should this message say something about endpoint suspend not being
allowed because the link is up? IIUC, the endpoint *can* suspend if
the link is down.
^ permalink raw reply
* Re: [PATCH] iommu: Ensure .iotlb_sync is called correctly
From: Russell King (Oracle) @ 2026-04-08 19:55 UTC (permalink / raw)
To: Jon Hunter; +Cc: Robin Murphy, joro, will, jgg, iommu, linux-tegra
In-Reply-To: <bdad8adc-5c20-4fb5-90b0-b7ca4199a7a8@nvidia.com>
On Wed, Apr 08, 2026 at 06:28:55PM +0100, Jon Hunter wrote:
>
> On 08/04/2026 15:40, Robin Murphy wrote:
> > Many drivers have no reason to use the iotlb_gather mechanism, but do
> > still depend on .iotlb_sync being called to properly complete an unmap.
> > Since the core code is now relying on the gather to detect when there
> > is legitimately something to sync, it should also take care of encoding
> > a successful unmap when the driver does not touch the gather itself.
> >
> > Fixes: 90c5def10bea ("iommu: Do not call drivers for empty gathers")
> > Reported-by: Jon Hunter <jonathanh@nvidia.com>
> > Closes: https://lore.kernel.org/r/8800a38b-8515-4bbe-af15-0dae81274bf7@nvidia.com
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> > drivers/iommu/iommu.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index 50718ab810a4..ee83850c7060 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -2717,6 +2717,12 @@ static size_t __iommu_unmap(struct iommu_domain *domain,
> > pr_debug("unmapped: iova 0x%lx size 0x%zx\n",
> > iova, unmapped_page);
> > + /*
> > + * If the driver itself isn't using the gather, make sure
> > + * it looks non-empty so iotlb_sync will still be called.
> > + */
> > + if (iotlb_gather->start >= iotlb_gather->end)
> > + iommu_iotlb_gather_add_range(iotlb_gather, iova, size);
> > iova += unmapped_page;
> > unmapped += unmapped_page;
>
>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
I think the commit message needs to spell out that the blamed commit
causes random memory corruption which leads to data corruption and
kernel oopses.
Thanks!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 2/2] ASoC: tegra210_amx: simplify byte map get/put logic
From: Mark Brown @ 2026-04-08 17:49 UTC (permalink / raw)
To: Piyush Patle
Cc: Sheetal, Jonathan Hunter, Thierry Reding, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Kuninori Morimoto, linux-sound,
linux-tegra, linux-kernel
In-Reply-To: <20260408170818.70322-3-piyushpatle228@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 225 bytes --]
On Wed, Apr 08, 2026 at 10:38:18PM +0530, Piyush Patle wrote:
> The byte-map controls ("Byte Map N") already expose a value range of
> [0, 256] to userspace via SOC_SINGLE_EXT(), where 256 is the
Similar issues in this one.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] ASoC: tegra210_adx: simplify byte map get/put logic
From: Mark Brown @ 2026-04-08 17:47 UTC (permalink / raw)
To: Piyush Patle
Cc: Sheetal, Jonathan Hunter, Thierry Reding, Liam Girdwood,
Jaroslav Kysela, Takashi Iwai, Kuninori Morimoto, linux-sound,
linux-tegra, linux-kernel
In-Reply-To: <20260408170818.70322-2-piyushpatle228@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On Wed, Apr 08, 2026 at 10:38:17PM +0530, Piyush Patle wrote:
> +static int tegra210_adx_write_map_ram(struct tegra210_adx *adx)
> {
> + const unsigned int bits_per_mask = BITS_PER_TYPE(*adx->map) * BITS_PER_BYTE;
Why are we multiplying by BITS_PER_BYTE here? We've got a number of
bits already from BITS_PER_TYPE().
> + for (i = 0; i < adx->soc_data->ram_depth; i++) {
> + u32 word = 0;
> + int b;
> +
> + for (b = 0; b < TEGRA_ADX_SLOTS_PER_WORD; b++) {
> + unsigned int slot = i * TEGRA_ADX_SLOTS_PER_WORD + b;
> + u16 val = adx->map[slot];
> +
> + if (val >= 256)
> + continue;
> +
> + word |= (u32)val << (b * BITS_PER_BYTE);
> + byte_mask[slot / bits_per_mask] |= 1U << (slot % bits_per_mask);
How big can bits_per_mask get?
> @@ -118,9 +144,7 @@ static int tegra210_adx_runtime_resume(struct device *dev)
> regcache_cache_only(adx->regmap, false);
> regcache_sync(adx->regmap);
>
> - tegra210_adx_write_map_ram(adx);
> -
> - return 0;
> + return tegra210_adx_write_map_ram(adx);
We need to unwind at least the regcache_cache_only() above if resume
fails.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ 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