Re: [PATCH net-next v2] vhost/net: Defer TX queue re-enable until after sendmsg

> On May 18, 2025, at 5:38 PM, Michael S. Tsirkin wrote: > > !---| > CAUTION: External Email > > |---! > > On Sat, Apr 19, 2025 at 06:0

Re: [PATCH] vhost/net: remove zerocopy support

> On Apr 30, 2025, at 9:21 PM, Jon Kohler wrote: > > > >> On Apr 16, 2025, at 6:15 AM, Eugenio Perez Martin >> wrote: >> >> !---

Re: [PATCH net-next] vhost/net: align variable names with XDP terminology

> On May 8, 2025, at 9:42 AM, Willem de Bruijn > wrote: > > > Jon Kohler wrote: >> >> >>> On May 7, 2025, at 1:23 PM, Willem de Bruijn >>> wrote: >>> > > Minor: can you fix email to avoid the above? I think its a corporat

Re: [PATCH net-next] vhost/net: align variable names with XDP terminology

> On May 7, 2025, at 1:23 PM, Willem de Bruijn > wrote: > > !---| > CAUTION: External Email > > |-------! > > Jon Kohler wrote: &g

[PATCH net-next] vhost/net: use xdp_get_frame_len()

Use xdp_get_frame_len helper to ensure xdp frame size is calculated correctly in both single buffer and multi buffer configurations. Signed-off-by: Jon Kohler --- drivers/vhost/net.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c

[PATCH net-next] vhost/net: align variable names with XDP terminology

. Signed-off-by: Jon Kohler --- drivers/vhost/net.c | 53 ++--- 1 file changed, 26 insertions(+), 27 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 7cbfc7d718b3..86db8add92eb 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c

[PATCH net-next v3] vhost/net: Defer TX queue re-enable until after sendmsg

(~93x reduction) Datagrams/second: ~650k (~1.7x increase) Interval Transfer Bitrate Lost/Total Datagrams 0.00-30.00 sec 26.4 GBytes 7.55 Gbits/sec 0/19554720 (0%) sender Acked-by: Jason Wang Signed-off-by: Jon Kohler --- v2->v3: Address MST&#

Re: [PATCH] vhost/net: remove zerocopy support

:28 AM Jason Wang wrote: >> >> On Tue, Apr 8, 2025 at 9:18 AM Jon Kohler wrote: >>> >>> >>> >>>> On Apr 6, 2025, at 7:14 PM, Jason Wang wrote: >>>> >>>>

Re: [PATCH net-next v2] vhost/net: Defer TX queue re-enable until after sendmsg

> On Apr 26, 2025, at 3:06 PM, Jon Kohler wrote: > > > >> On Apr 24, 2025, at 8:11 AM, Michael S. Tsirkin wrote: >> >> !-

Re: [PATCH net-next v2] vhost/net: Defer TX queue re-enable until after sendmsg

:53PM +0200, Paolo Abeni wrote: >> On 4/20/25 3:05 AM, Jon Kohler wrote: >>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c >>> index b9b9e9d40951..9b04025eea66 100644 >>> --- a/drivers/vhost/net.c >>> +++ b/drivers/vhost/net.c >>> @@ -769,

Re: [PATCH net-next v2] vhost/net: Defer TX queue re-enable until after sendmsg

:53PM +0200, Paolo Abeni wrote: >> On 4/20/25 3:05 AM, Jon Kohler wrote: >>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c >>> index b9b9e9d40951..9b04025eea66 100644 >>> --- a/drivers/vhost/net.c >>> +++ b/drivers/vhost/net.c >>> @@ -769,

Re: [PATCH net-next v2] vhost/net: Defer TX queue re-enable until after sendmsg

> On Apr 20, 2025, at 3:32 AM, Michael S. Tsirkin wrote: > > !---| > CAUTION: External Email > > |---! > > On Sat, Apr 19, 2025 at 06:0

[PATCH net-next v2] vhost/net: Defer TX queue re-enable until after sendmsg

(~93x reduction) Datagrams/second: ~650k (~1.7x increase) Interval Transfer Bitrate Lost/Total Datagrams 0.00-30.00 sec 26.4 GBytes 7.55 Gbits/sec 0/19554720 (0%) sender Acked-by: Jason Wang Signed-off-by: Jon Kohler --- drivers/vhost/net.c | 19 +++

Re: [PATCH] vhost/net: remove zerocopy support

> On Apr 6, 2025, at 7:14 PM, Jason Wang wrote: > > !---| > CAUTION: External Email > > |---! > > On Fri, Apr 4, 2025 at 10:24 PM Jon Kohl

[PATCH] vhost/net: Defer TX queue re-enable until after sendmsg

(~93x reduction) Datagrams/second: ~650k (~1.7x increase) Interval Transfer Bitrate Lost/Total Datagrams 0.00-30.00 sec 26.4 GBytes 7.55 Gbits/sec 0/19554720 (0%) sender Signed-off-by: Jon Kohler --- drivers/vhost/net.c | 19 +++ 1

[PATCH] vhost/net: remove zerocopy support

izations present in the handle_tx_copy path. Given these limitations and the lack of any tangible benefits, remove zerocopy entirely to simplify the code base. Signed-off-by: Jon Kohler --- drivers/vhost/net.c | 398 +--- 1 file changed, 2 insertions(+), 396 del

[PATCH] ptp: Don't print an error if ptp_kvm is not supported

/arm64") Signed-off-by: Jon Hunter --- drivers/ptp/ptp_kvm_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/ptp/ptp_kvm_common.c b/drivers/ptp/ptp_kvm_common.c index 721ddcede5e1..fcae32f56f25 100644 --- a/drivers/ptp/ptp_kvm_common.c +++ b/drivers/

Re: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains

pcie, msi_state[i], AFI_MSI_EN_VEC(i)); > + > /* and unmask the MSI interrupt */ > reg = afi_readl(pcie, AFI_INTR_MASK); > reg |= AFI_INTR_MASK_MSI_MASK; > Thanks, that does fix it indeed! Tested-by: Jon Hunter Cheers Jon -- nvpublic

Re: [PATCH v3 1/3] tracing: Show real address for trace event arguments

On 19/04/2021 19:22, Steven Rostedt wrote: > On Mon, 19 Apr 2021 14:08:14 +0100 > Jon Hunter wrote: > >> I have encountered the following crash on a couple of our ARM64 Jetson >> platforms and bisect is pointing to this change. The crash I am seeing >> is on boot wh

Re: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains

On 19/04/2021 20:19, Jon Hunter wrote: > Hi Marc, > > On 30/03/2021 16:11, Marc Zyngier wrote: >> In anticipation of the removal of the msi_controller structure, convert >> the Tegra host controller driver to MSI domains. >> >> We end-up with the usual two doma

Re: [PATCH v3 01/14] PCI: tegra: Convert to MSI domains

orking is no longer working. The reason why this breaks our suspend test is because that setup is using NFS for the rootfs. I am looking into it, but if anyone has any thoughts please let me know. Jon -- nvpublic

Re: [PATCH v3 1/3] tracing: Show real address for trace event arguments

0x80/0xb8 [5.992359] process_one_work+0x1f0/0x4b8 [5.996368] worker_thread+0x20c/0x450 [6.000112] kthread+0x124/0x150 [6.003337] ret_from_fork+0x10/0x18 [6.006913] Code: b4000b21 aa0003f6 f940 aa0103fa (b9407800) [6.013000] ---[ end trace eae1531f47c7c14a ]--- Thanks! Jon -- nvpublic

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

On 01/04/2021 17:28, Jon Hunter wrote: > > On 31/03/2021 12:41, Joakim Zhang wrote: > > ... > >>> In answer to your question, resuming from suspend does work on this board >>> without your change. We have been testing suspend/resume now on this board >&g

Re: [PATCH] PCI: tegra: Fix runtime PM imbalance in pex_ep_event_pex_rst_deassert

== EP_STATE_ENABLED) > return; > > - ret = pm_runtime_get_sync(dev); > + ret = pm_runtime_resume_and_get(dev); > if (ret < 0) { > dev_err(dev, "Failed to get runtime sync for PCIe dev: %d\n", > r

Re: [PATCH] dmaengine: tegra20: Fix runtime PM imbalance in tegra_dma_issue_pending

gt;tdma->dev); > + err = pm_runtime_resume_and_get(tdc->tdma->dev); > if (err < 0) { > dev_err(tdc2dev(tdc), "Failed to enable DMA\n"); > goto end; > Thanks! Looks like there are two instances of this that need fixing. Cheers Jon -- nvpublic

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

rm_smmu_pm_resume <-platform_pm_resume rtcwake-748 [003] ...1 536.856771: stmmac_pltfr_resume <-platform_pm_resume So I don't see any ordering issues that could be causing this. Jon -- nvpublic

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

ard which fails after this change is made, >>> it has the IOMMU enabled. The other board does not at the moment >>> (although work is in progress to enable). If I add >>> 'iommu.passthrough=1' to cmdline for the failing board, then it works >>> again. So in

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

nt (although work is in >> progress to enable). If I add 'iommu.passthrough=1' to cmdline for the >> failing >> board, then it works again. So in my case, the problem is linked to the IOMMU >> being enabled. >> >> Does you platform enable the IOMMU? &g

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

t;> affect this. Sorry. I realised that for the board which fails after this change is made, it has the IOMMU enabled. The other board does not at the moment (although work is in progress to enable). If I add 'iommu.passthrough=1' to cmdline for the failing board, then it works again. So in my case, the problem is linked to the IOMMU being enabled. Does you platform enable the IOMMU? Thanks Jon -- nvpublic

Re: [PATCH] arm64: PCI: Enable SMC conduit

t footnotes in the historical telling. How we haven't moved the third party IP vendors faster is a significant one. I think we have a chance to finally change that now that Arm is gaining traction. I am very sad that some of the early comers who tried to do the right thing had to deal with the state of third party IP at the time. Jon.

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

On 25/03/2021 07:53, Joakim Zhang wrote: > >> -Original Message- >> From: Jon Hunter >> Sent: 2021年3月24日 20:39 >> To: Joakim Zhang >> Cc: net...@vger.kernel.org; Linux Kernel Mailing List >> ; linux-tegra ; >> Jakub Kicinski >> Subj

Re: Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

ess test, there is no issue found. > > Could you please do more test to see where the issue happen? The issue occurs 100% of the time on the failing board and always on the first resume from suspend. Is there any more debug I can enable to track down what the problem is? Jon -- nvpublic

Regression v5.12-rc3: net: stmmac: re-init rx buffers when mac resume back

-eth-dwmac 249.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx I don't see any crash, but then it hangs at some point. Please note that this board is using NFS for mounting the rootfs. Let me know if there is any more info I can provide or tests I can run. Thanks Jon

Re: [PATCH v3 2/2] arm64: mm: reserve CMA and crashkernel in ZONE_DMA32

On 3/22/21 2:34 PM, Jon Masters wrote: Hi Nicolas, On 11/7/19 4:56 AM, Nicolas Saenz Julienne wrote: With the introduction of ZONE_DMA in arm64 we moved the default CMA and crashkernel reservation into that area. This caused a regression on big machines that need big CMA and crashkernel

Re: [PATCH v3 2/2] arm64: mm: reserve CMA and crashkernel in ZONE_DMA32

enterprise users aren't going to respond to that situation by determining the placement manually, they'll just not have a crashkernel. Jon. -- Computer Architect

Re: [PATCH v1 2/3] driver core: Update device link status properly for device_bind_driver()

int ret; > > ret = driver_sysfs_add(dev); > - if (!ret) > + if (!ret) { > + device_links_force_bind(dev); > driver_bound(dev); > + } > else if (dev->bus) > blocking_notifier_call_chain(&dev->bus->p->bus_notifier, >BUS_NOTIFY_DRIVER_NOT_BOUND, dev); > Thanks, this fixes the problem I had observed. Tested-by: Jon Hunter Cheers! Jon -- nvpublic

Re: [PATCH] ASoC: soc-core: fix DMI handling

ard->long_name) > return 0; /* long name already set by driver or from DMI */ > > - if (!is_acpi_device_node(card->dev->fwnode)) > + if (!dmi_available) > return 0; > > /* make up dmi long name as: vendor-product-version-board */ > Thanks for fixing. Reviewed-by: Jon Hunter Tested-by: Jon Hunter Cheers Jon -- nvpublic

Re: [PATCH V2] ASoC: soc-core: Prevent warning if no DMI table is present

; -   if (!is_acpi_device_node(card->dev->fwnode)) > +   if (!dmi_available) >     return 0; > >     /* make up dmi long name as: vendor-product-version-board */ Sounds good to me. I would have done the same if I had known that the current solution would have caused this regression. Cheers Jon -- nvpublic

[PATCH V2] ASoC: soc-core: Prevent warning if no DMI table is present

se the DMI table if we are booting with ACPI. Signed-off-by: Jon Hunter --- Changes since V1: - Use is_acpi_device_node() to determine if we expect the DMI table to be present. sound/soc/soc-core.c | 4 1 file changed, 4 insertions(+) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-co

Re: [PATCH] ASoC: soc-core: Prevent warning if no DMI table is present

On 02/03/2021 17:23, Takashi Iwai wrote: > On Tue, 02 Mar 2021 13:49:13 +0100, > Mark Brown wrote: >> >> On Tue, Mar 02, 2021 at 09:27:12AM +, Jon Hunter wrote: >>> Many systems do not provide a DMI table and on these systems a warning, >>> such

[PATCH] ASoC: soc-core: Prevent warning if no DMI table is present

card name. Therefore, make this a debug print by default to avoid the warning. Signed-off-by: Jon Hunter --- sound/soc/soc-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index f6d4e99b590c..f1189e7c1fcc 100644 --- a/sound/soc/soc-co

Re: phy_attach_direct()'s use of device_bind_driver()

ing the BRCM PHY resolves that as well. I will ensure that these are enabled going forward. Cheers Jon -- nvpublic

Re: [PATCH v1 2/2] ASoC: tegra: Add RT5631 machine driver

On 02/02/2021 15:25, Dmitry Osipenko wrote: > 02.02.2021 16:22, Jon Hunter пишет: >> So this is very similar to tegra_rt5677, is it not possible to support >> both codecs with the same machine driver? > > These codecs require individual configurations and those >

Re: [PATCH v1 0/2] ASoC: tegra: Add RT5631 machine driver

100644 sound/soc/tegra/tegra_rt5631.c I don't see any user of this driver included. Any reason why? Jon -- nvpublic

Re: [PATCH v1 2/2] ASoC: tegra: Add RT5631 machine driver

s-controller", > 0); > + if (!np_i2s) { > + dev_err(&pdev->dev, > + "Property 'nvidia,i2s-controller' missing or > invalid\n"); > + return -EINVAL; > + } > + > + tegra_rt5631_dai.cpus->of_node = np_i2s; > + tegra_rt5631_dai.codecs->of_node = np_codec; > + tegra_rt5631_dai.platforms->of_node = np_i2s; > + > + ret = tegra_asoc_utils_init(&machine->util_data, &pdev->dev); > + if (ret) > + return ret; > + > + ret = devm_snd_soc_register_card(&pdev->dev, card); > + if (ret) > + return ret; > + > + return 0; > +} > + > +static const struct of_device_id tegra_rt5631_of_match[] = { > + { .compatible = "nvidia,tegra-audio-rt5631", }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, tegra_rt5631_of_match); > + > +static struct platform_driver tegra_rt5631_driver = { > + .driver = { > + .name = "tegra-snd-rt5631", > + .pm = &snd_soc_pm_ops, > + .of_match_table = tegra_rt5631_of_match, > + }, > + .probe = tegra_rt5631_probe, > +}; > +module_platform_driver(tegra_rt5631_driver); > + > +MODULE_DESCRIPTION("Tegra+RT5631 machine ASoC driver"); > +MODULE_AUTHOR("Stephen Warren "); > +MODULE_AUTHOR("Svyatoslav Ryhel "); > +MODULE_AUTHOR("Ion Agorria "); > +MODULE_LICENSE("GPL"); So this is very similar to tegra_rt5677, is it not possible to support both codecs with the same machine driver? Jon -- nvpublic

Re: [PATCH v1 1/2] ASoC: dt-bindings: tegra: Add binding for RT5631

nding describes integration of the Realtek ALC5631/RT5631 sound > + codec with the sound system of NVIDIA Tegra SoCs. > + > +maintainers: > + - Jon Hunter > + - Stephen Warren > + - Thierry Reding Thierry and I should be sufficient and so no need to include Stephen i

Re: [PATCH 4.4 00/24] 4.4.254-rc1 review

43d6297 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra30-cardhu-a04 Tested-by: Jon Hunter Jon -- nvpublic

Re: [PATCH 5.4 00/18] 5.4.94-rc1 review

182cbe9 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-, tegra30-cardhu-a04 Tested-by: Jon Hunter Jon -- nvpublic

Re: [PATCH 5.10 00/32] 5.10.12-rc1 review

e71045b28 Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-, tegra30-cardhu-a04 Tested-by: Jon Hunter Jon -- nvpublic

Re: [PATCH 4.19 00/26] 4.19.172-rc1 review

541af5a Boards tested: tegra124-jetson-tk1, tegra186-p2771-, tegra194-p2972-, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Tested-by: Jon Hunter Jon -- nvpublic

Re: [PATCH 4.14 00/50] 4.14.218-rc1 review

e33037f Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04 Tested-by: Jon Hunter Jon -- nvpublic

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

On 14/01/2021 16:56, Jon Hunter wrote: > > On 14/01/2021 16:47, Saravana Kannan wrote: > > ... > >>> Yes this is the warning shown here [0] and this is coming from >>> the 'Generic PHY stmmac-0:00' device. >> >> Can you print the supplie

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

me looking at this later thinking "wow, what a great idea!", please fix your hardware to have a real IOMMU/SMMU and real PCIe. You'll be pointed at this reply. Jon. -- Computer Architect

Re: [PATCH] arm64: tegra: Enable Jetson-Xavier J512 USB host

ctl@352/pads/usb2/lanes/usb2-0}>, > + > <&{/bus@0/padctl@352/pads/usb2/lanes/usb2-1}>, > > <&{/bus@0/padctl@352/pads/usb2/lanes/usb2-3}>, > > <&{/bus@0/padctl@352/pads/usb3/lanes/usb3-0}>, > + > <&{/bus@0/padctl@352/pads/usb3/lanes/usb3-2}>, > > <&{/bus@0/padctl@352/pads/usb3/lanes/usb3-3}>; > - phy-names = "usb2-1", "usb2-3", "usb3-0", "usb3-3"; > + phy-names = "usb2-0", "usb2-1", "usb2-3", "usb3-0", > "usb3-2", "usb3-3"; > }; > > pwm@c34 { > Thanks. Works for me. Acked-by: Jon Hunter Tested-by: Jon Hunter Cheers Jon -- nvpublic

Re: [PATCH] ACPICA: fix -Wfallthrough

d:287: recipe for target 'drivers/acpi/acpica/dscontrol.o' failed Cheers Jon [0] https://github.com/acpica/acpica/commit/4b9135f5 -- nvpublic

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

On 14/01/2021 21:50, Saravana Kannan wrote: > On Thu, Jan 14, 2021 at 10:55 AM Jon Hunter wrote: >> >> >> On 14/01/2021 16:52, Saravana Kannan wrote: >> >> ... >> >>> Thanks! I think you forgot to enable those logs though. Also, while >>>

Re: [Patch v2 0/4] Add Nvidia Tegra GPC-DMA driver

On 15/01/2021 05:56, Vinod Koul wrote: > On 14-01-21, 10:11, Jon Hunter wrote: >> >> On 06/08/2020 08:30, Rajesh Gumasta wrote: >>> Changes in patch v2: >>> Addressed review comments in patch v1 >> >> >> Is there any update on this series? Wo

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

n an incorrect manner. With enough context of this code (why > the device_bind_driver() is being called directly instead of going > through the normal probe path), it should be easy to fix (I'll just > need to fix up the device link state). Correct, the board seems to boot fine, we just get this warning. Cheers Jon -- nvpublic

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

On 14/01/2021 16:40, Saravana Kannan wrote: > On Thu, Jan 14, 2021 at 3:35 AM Jon Hunter wrote: >> >> >> On 13/01/2021 21:29, Saravana Kannan wrote: >> >> ... >> >>>> I am seeing the same problem on Tegra30 Cardhu A04 where several regulators &g

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

On 13/01/2021 21:26, Saravana Kannan wrote: > On Wed, Jan 13, 2021 at 3:30 AM Jon Hunter wrote: >> >> >> On 18/12/2020 03:16, Saravana Kannan wrote: >>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't >>> be broken using

Re: [PATCH v6 12/16] net: tip: fix a couple kernel-doc markups

* @dnode: address of destination node Acked-by: Jon Maloy

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

gt;> ready > > Looks like this is not the whole log? Do you see any "wait for > supplier" logs? That's what all these boot issues should boil down to. > And as usual, pointer to DT for this board please. Ah yes I see ... platform regulator@1: probe deferral - wait

Re: [Patch v2 0/4] Add Nvidia Tegra GPC-DMA driver

On 06/08/2020 08:30, Rajesh Gumasta wrote: > Changes in patch v2: > Addressed review comments in patch v1 Is there any update on this series? Would be good to get this upstream. Jon -- nvpublic

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

ot ready [2.595088] platform regulator@12: probe deferral - supplier regulator@104 not ready [2.603837] platform regulator@102: probe deferral - supplier regulator@104 not ready [2.611726] platform regulator@103: probe deferral - supplier regulator@104 not ready [2.620137] platform 3000.pcie: probe deferral - supplier regulator@5 not ready Cheers Jon -- nvpublic

Re: [PATCH v1 0/5] Enable fw_devlink=on by default

KERN kernel_init+0x10/0x110 boot: logs: [ 4.376130] WARNING KERN ret_from_fork+0x10/0x18 So looking at this change does this mean that the of_mdio needs to be converted to a proper driver? I would have thought that this will be seen on several platforms. Cheers Jon -- nvpublic

Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc

On 08/01/2021 10:54, Jon Hunter wrote: > > On 08/01/2021 08:00, Sameer Pujar wrote: > > ... > >>>>> Signed-off-by: Peter Geis >>>>> Tested-by: Ion Agorria >>>>> --- >>>>>    sound/pci/hda/hda_tegra.c | 3 +-- >&

Re: [PATCH 2/2] ALSA: hda/tegra: fix tegra-hda on tegra30 soc

e to apply the workaround for > Tegra210/186 as well. So it simplifies things for all existing chips. FYI ... we now have minimal support for Tegra234 in upstream that should not require this. Given that the Tegra234 device-tree does not include support for HDA yet, I think it is fine to apply this as-is. However, once we do add support for Tegra234 HDA, then we should ensure that this is not applied. So that said ... Reviewed-by: Jon Hunter Cheers Jon -- nvpublic

Re: [PATCH] arm64: PCI: Enable SMC conduit

ething strong in return. A firm commitment that they will never come asking for the same stuff in the future. Is there a way we can do something like that? Jon. -- Computer Architect

Re: [PATCH] arm64: tegra: Add power-domain for Tegra210 HDA

<&tegra_car 128>, /* hda2hdmi */ ><&tegra_car 111>; /* hda2codec_2x */ > reset-names = "hda", "hda2hdmi", "hda2codec_2x"; > + power-domains = <&pd_sor>; > status = "disabled"; > }; Thanks! Acked-by: Jon Hunter Cheers Jon -- nvpublic

Re: [PATCH 1/2] clk: tegra30: Add hda clock default rates to clock driver

CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 }, > }; This looks good to me. So ... Acked-by: Jon Hunter Cheers Jon -- nvpublic

Re: [GIT PULL] NTB bug fixes for v5.11

On Mon, Jan 4, 2021 at 3:31 AM Dan Carpenter wrote: > > On Sun, Dec 27, 2020 at 09:38:23AM -0800, Linus Torvalds wrote: > > On Sun, Dec 27, 2020 at 6:16 AM Jon Mason wrote: > > > > > > Wang Qing (1): > > > ntb: idt: fix error check in ntb_hw_idt.c >

[GIT PULL] NTB bug fixes for v5.11

Hello Linus, Here are a few NTB bug fixes for v5.11. Please consider pulling them. Thanks, Jon The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://github.com/jonmason/ntb

Re: [PATCH 5.10 00/16] 5.10.2-rc1 review

ilures: tegra194-p2972-: boot.py Same warning failure as before. The fix for this is now in the mainline if you would like to pick it up ... commit c9f64d1fc101c64ea2be1b2e562b4395127befc9 Author: Thierry Reding Date: Tue Nov 10 08:37:57 2020 +0100 net: ipconfig: Avoid spurious bl

Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test

On 18/12/2020 17:54, Linus Torvalds wrote: > On Fri, Dec 18, 2020 at 7:33 AM Jon Hunter wrote: >> >> However, if you are saying that this is a problem/bug with our builders, >> then of course we will have to get this fixed. > > This seems to be a package dependency p

Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test

c > due to missing , > you need to install the openssl dev package. > > It is the same pattern. OK, thanks for confirming. We will get this fixed. Cheers Jon -- nvpublic

Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test

On 18/12/2020 15:12, Jon Hunter wrote: > > On 18/12/2020 15:09, Marek Szyprowski wrote: >> >> On 18.12.2020 16:03, Jon Hunter wrote: >>> On 18/12/2020 10:05, Marek Szyprowski wrote: >>>> On 18.12.2020 10:43, Masahiro Yamada wrote: >>>>

Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test

On 18/12/2020 15:09, Marek Szyprowski wrote: > > On 18.12.2020 16:03, Jon Hunter wrote: >> On 18/12/2020 10:05, Marek Szyprowski wrote: >>> On 18.12.2020 10:43, Masahiro Yamada wrote: >>>> On Fri, Dec 18, 2020 at 4:58 PM Marek Szyprowski >>>> wrot

Re: [PATCH] gcc-plugins: simplify GCC plugin-dev capability test

-gnueabi/gcc-arm-linux-gnueabi Ubuntu packages, which is: >>> >>> $ arm-linux-gnueabi-gcc --version >>> arm-linux-gnueabi-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0 >>> >> >> I can compile gcc-plugins with Linaro toolchians. >> >> The version of mine is this: >> >> masahiro@oscar:~/ref/linux-next$ >> ~/tools/arm-linaro-7.5/bin/arm-linux-gnueabihf-gcc --version >> arm-linux-gnueabihf-gcc (Linaro GCC 7.5-2019.12) 7.5.0 >> Copyright (C) 2017 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> >> >> >> >> Maybe, it depends on the host environment? >> >> >> Please try this: >> >> $ sudo apt install libgmp-dev > > Indeed, it was missing on my setup. Sorry for the noise. So this change also breaks the build on our farm build machines and while we can request that packages are installed on these machines, it takes time. Is there anyway to avoid this? Cheers Jon -- nvpublic

Re: [PATCH 5.10 0/2] 5.10.1-rc1 review

le, but if you OK to pull this in once in the mainline I can send a request. Otherwise all looks good, so ... Tested-by: Jon Hunter Cheers Jon [0] https://lore.kernel.org/patchwork/patch/1336079/ -- nvpublic

Re: [PATCH RESEND net-next 1/2] dpaa2-eth: send a scatter-gather FD instead of realloc-ing

_timers.part.0+0x2bc/0x370 > > > > > [ 714.465578] run_timer_softirq+0x48/0x80 > > > > > [ 714.465583] __do_softirq+0x120/0x36c > > > > > [ 714.465589] irq_exit+0xac/0x100 > > > > > [ 714.465596] __handle_domain_irq+0x8c/0xf0 > >

Re: [PATCH RESEND net-next 1/2] dpaa2-eth: send a scatter-gather FD instead of realloc-ing

Given it is the iommu code that is provoking the warning I should > > probably mention that the board I have requires > > arm-smmu.disable_bypass=0 on the kernel command line in order to boot. > > Also if it matters I am running the latest firmware from Solidrun > > whic

Re: [PATCH] iommu: arm-smmu-impl: add NXP hook to preserve bootmappings

quivalent information to IORT RMRs then it largely all falls in together. > > Thanks, > Robin. Robin, I have been working with Laurentiu on getting a proper implementation in place. Based on the patchset you noted in [2] I have already added preliminary RMR support to edk2 an

Re: [PATCH] ntb: idt: fix error check in ntb_hw_idt.c

min Applied to the ntb branch. Thanks, Jon > > They are mostly unrelated though. If they weren't trivial I'd have > suggested to split them up into the dedicated patches. Since they > aren't I suppose leaving the patch 'as is' is ok, unless the subsystem >

Re: [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages

firm. Reverting commit 4df001639c84 ("mm/memblock: use a more > appropriate order calculation when free memblock pages") on top of linux > next-20201204 fixed booting of my ARM32bit test systems. FWIW, I also confirm that this is causing several 32-bit Tegra platforms to crash on boot and reverting this fixes the problem. Jon -- nvpublic

Re: [PATCH v1 3/7] spi: qspi-tegra: Add support for Tegra210 QSPI controller

i, QSPI_CS_TIMING2); > + tqspi->def_command2_reg = tegra_qspi_readl(tqspi, QSPI_COMMAND2); > + > + pm_runtime_put(&pdev->dev); > + > + ret = request_threaded_irq(tqspi->irq, tegra_qspi_isr, > +tegra_qspi_isr_thread, IRQF_ONESHOT, > +dev_name(&pdev->dev), tqspi); > + if (ret < 0) { > + dev_err(&pdev->dev, > + "failed to request IRQ#%u: %d\n", tqspi->irq, ret); > + goto exit_pm_disable; > + } > + > + master->dev.of_node = pdev->dev.of_node; > + ret = devm_spi_register_master(&pdev->dev, master); > + if (ret < 0) { > + dev_err(&pdev->dev, "failed to register master: %d\n", ret); > + goto exit_free_irq; > + } > + return ret; return 0 > +static int tegra_qspi_runtime_resume(struct device *dev) > +{ > + struct spi_master *master = dev_get_drvdata(dev); > + struct tegra_qspi_data *tqspi = spi_master_get_devdata(master); > + int ret; > + > + ret = clk_prepare_enable(tqspi->clk); > + if (ret < 0) { > + dev_err(tqspi->dev, "clk_prepare failed: %d\n", ret); > + return ret; > + } > + return 0; Always just 'return ret' here. Cheers Jon -- nvpublic

Re: [PATCH v10 17/19] ARM: tegra: Add EMC OPP properties to Tegra20 device-trees

On 30/11/2020 22:57, Dmitry Osipenko wrote: > 01.12.2020 00:17, Jon Hunter пишет: >> Hi Dmitry, >> >> On 23/11/2020 00:27, Dmitry Osipenko wrote: >>> Add EMC OPP DVFS tables and update board device-trees by removing >>> unsupported OPPs. >>> >&

Re: [PATCH net-next 4/6] net: ipa: add support to code for IPA v4.5

te error: value doesn't fit into mask __field_overflow(); \ ^~ ./include/linux/bitfield.h:151:2: note: in expansion of macro ‘MAKE_OP’ MAKE_OP(u##size,u##size,,) ^~~ ./include/linux/bitfield.h:154:1: note: in expansion of macro ‘__MAKE_OP’ __MAKE_OP(32) ^ Cheers Jon -- nvpublic

Re: [PATCH v10 17/19] ARM: tegra: Add EMC OPP properties to Tegra20 device-trees

[2.730106] 1fc0: [2.738278] 1fe0: 0013 [2.751940] ---[ end trace 61e3b76deca27ef3 ]--- Cheers Jon -- nvpublic

Re: [PATCH] dmaengine: tegra-apb: fix reference leak in tegra_dma_issue_pending and tegra_dma_synchronize

c(tdc->tdma->dev); > + err = pm_runtime_resume_and_get(tdc->tdma->dev); > if (err < 0) { > dev_err(tdc2dev(tdc), "Failed to synchronize DMA: %d\n", err); > return; Reviewed-by: Jon Hunter Cheers Jon -- nvpublic

Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities

lbox is intended for use by platform firmware, so Linux should never be using it anyway. Maybe that message is slightly misleading? Jon. P.S. Related - I've severe doubts about the mailbox approach being proposed by CXL and have begun to push back through the spec org. -- Computer Architect

Re: [PATCH v3 1/6] regulator: core: validate selector against linear_min_sel

has a better solution for this. By the way, I don't think that Tegra is alone here. I see some other drivers doing some similar things [0][1][2] and so I am wondering if this is going to be a problem for a few drivers. Jon [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux

[PATCH] dt-bindings: Correct GV11B GPU register sizes

Commit 90a09178f309 ("dt-bindings: Add documentation for GV11B GPU") added the GV11B GPU device-tree bindings information but incorrectly added an additional 0 to the size of the addresses in the example. Fixes: 90a09178f309 ("dt-bindings: Add documentation for GV11B GPU"

Re: [PATCH v3 1/6] regulator: core: validate selector against linear_min_sel

ghts are the correct way to fix this up. Thanks Jon -- nvpublic

Re: [PATCH v5 0/6] Tegra210 audio graph card

http://patchwork.ozlabs.org/project/devicetree-bindings/patch/20201102203656.220187-2-r...@kernel.org/ > * https://patchwork.kernel.org/project/alsa-devel/list/?series=382009&state=* Only one minor comment, but this looks good to me. Otherwise for the series ... Reviewed-by: Jon Hunter Cheers Jon -- nvpublic

Re: [PATCH v5 3/6] ASoC: tegra: Add audio graph based card driver

priv *simple = snd_soc_card_get_drvdata(rtd->card); > + struct tegra_audio_priv *priv = simple_to_tegra_priv(simple); > + struct device *dev = rtd->card->dev; > + const struct tegra_audio_cdata *data = of_device_get_match_data(dev); > + unsigned int plla_rate, plla_out0_rate, bclk; > + unsigned int srate = params_rate(params); > + int err; > + > + /* There is nothing to configure */ > + if (!data) > + return 0; Seems like this should never happen and so if it did this is an error. Any reason why we don't return an error here? Cheers Jon -- nvpublic

Re: [PATCH v1] arm64: tegra: jetson-tx1: Fix USB_VBUS_EN0 regulator

regulator-min-microvolt = <500>; > + regulator-max-microvolt = <500>; > + gpio = <&gpio TEGRA_GPIO(CC, 4) GPIO_ACTIVE_HIGH>; > + enable-active-high; > + vin-supply = <&vdd_5v0_sys>; > + }; >

Re: [PATCH] cpufreq: tegra186: Fix get frequency callback

Hi Rafael, On 04/11/2020 09:33, Viresh Kumar wrote: > On 03-11-20, 11:55, Jon Hunter wrote: >> Commit b89c01c96051 ("cpufreq: tegra186: Fix initial frequency") >> implemented the CPUFREQ 'get' callback to determine the current >> operating frequency for ea

Re: [PATCH] ARM: tegra: Populate OPP table for Tegra20 Ventana

On 12/11/2020 12:11, Dmitry Osipenko wrote: > 11.11.2020 13:38, Jon Hunter пишет: >> Commit 9ce274630495 ("cpufreq: tegra20: Use generic cpufreq-dt driver >> (Tegra30 supported now)") update the Tegra20 CPUFREQ driver to use the >> generic CPUFREQ device-tree dr

[PATCH V2] ARM: tegra: Populate OPP table for Tegra20 Ventana

a...@vger.kernel.org Signed-off-by: Jon Hunter --- Changes since V1: - Remove unneeded 'cpu0' phandle arch/arm/boot/dts/tegra20-ventana.dts | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/boot/dts/tegra20-ventana.dts b/arch/arm/boot/dts/tegra20-ventana.dts in

Re: [PATCH] ARM: tegra: Populate OPP table for Tegra20 Ventana

ed by vdd_sm2,vin_ldo* [2.380373] vdd_rtc_out,vdd_cell: supplied by vdd_sys Jon

  1   2   3   4   5   6   7   8   9   10   >