/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/
, 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
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
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 do
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
[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
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
== 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
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
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
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
gh 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?
>
> Hi Jon
; 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
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.
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
rnight stress 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
-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
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
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
> 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(>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
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
i_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
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-core.c
index
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
. 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-core.c
+++ b
nd enabling the BRCM PHY resolves that
as well. I will ensure that these are enabled going forward.
Cheers
Jon
--
nvpublic
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
100644 sound/soc/tegra/tegra_rt5631.c
I don't see any user of this driver included. Any reason why?
Jon
--
nvpublic
idia,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(>util_data, >dev);
> + if (ret)
> + return ret;
> +
> + ret = devm_snd_soc_register_card(>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 = _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
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
97
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Tested-by: Jon Hunter
Jon
--
nvpublic
e9
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
5b28
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
5a
Boards tested: tegra124-jetson-tk1, tegra186-p2771-,
tegra194-p2972-, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter
Jon
--
nvpublic
7f
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter
Jon
--
nvpublic
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 supplier and cons
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
> <&{/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
for target 'drivers/acpi/acpica/dscontrol.o' failed
Cheers
Jon
[0] https://github.com/acpica/acpica/commit/4b9135f5
--
nvpublic
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
>>>
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
ith 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
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
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 logi
* @dnode: address of destination node
Acked-by: Jon Maloy
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 for
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
2: 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
nel_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
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 +--
>
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
g for the same stuff in
the future. Is there a way we can do something like that?
Jon.
--
Computer Architect
_car 128>, /* hda2hdmi */
><_car 111>; /* hda2codec_2x */
> reset-names = "hda", "hda2hdmi", "hda2codec_2x";
> + power-domains = <_sor>;
> status = "disabled";
> };
Thanks!
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
CLK_CLK_MAX, TEGRA30_CLK_CLK_MAX, 0, 0 },
> };
This looks good to me. So ...
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
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
>
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
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
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
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
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:
>>>>
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
x-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
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
0
> > > > > [ 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
> > > > > [ 714.465
u 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
> > which is based on LSDK-20.04.
s,
> 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 and have a working patchset for our HoneyComb using the LX2160a.
Laurentiu pointed me to the Nvidia patchse
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
> maintainer thinks diffe
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
> + tqspi->spi_cs_timing2 = tegra_qspi_readl(tqspi, QSPI_CS_TIMING2);
> + tqspi->def_command2_reg = tegra_qspi_readl(tqspi, QSPI_COMMAND2);
> +
> + pm_runtime_put(>dev);
> +
> + ret = request_threaded_irq(tqspi->irq, tegra_qspi_isr,
> +tegra_qspi_isr_thread, IRQF_ONESHOT,
> +dev_name(>dev), tqspi);
> + if (ret < 0) {
> + dev_err(>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(>dev, master);
> + if (ret < 0) {
> + dev_err(>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
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.
>>>
&g
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
000
[2.730106] 1fc0:
[2.738278] 1fe0: 0013
[2.751940] ---[ end trace 61e3b76deca27ef3 ]---
Cheers
Jon
--
nvpublic
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
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
> Maybe Mark 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.git/
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"
are the correct way to fix this up.
Thanks
Jon
--
nvpublic
://patchwork.ozlabs.org/project/devicetree-bindings/patch/20201102203656.220187-2-r...@kernel.org/
> * https://patchwork.kernel.org/project/alsa-devel/list/?series=382009=*
Only one minor comment, but this looks good to me. Otherwise for the
series ...
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
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
-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + gpio = < TEGRA_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + vin-supply = <_5v0_sys>;
> + };
> };
>
Thanks for catching this! We should add the 'Fixes:' tag.
By the way, I assume that VBUS is currently broken for the OTG port.
Without this change is that USB port completely broken? I am wondering
if we need to CC sta...@vger.kernel.org on this.
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
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 each CPU. Th
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
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
index b15877
vdd_sm2,vin_ldo*
[2.380373] vdd_rtc_out,vdd_cell: supplied by vdd_sys
Jon
On 11/11/2020 13:47, 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
On 11/11/2020 13:47, 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
the TCU and the Tegra 8250 node for UARTC. Fix this
by disabling the Tegra 8250 node for UARTC and enabling the Tegra 8250
node for UARTA.
Fixes: 3f9efbbe57bc ("arm64: tegra: Add support for Jetson Xavier NX")
Cc: sta...@vger.kernel.org
Signed-off-by: Jon Hunter
---
arch/arm64/boot/
a...@vger.kernel.org
Signed-off-by: Jon Hunter
---
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
index b158771ac0b7..055334ae3d28 100644
--- a/arch/arm/boot/dts
Deferred probe is an expected return value for devm_regulator_bulk_get().
Given that the driver deals with it properly, there's no need to output a
warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
drivers/phy/tegra/xusb.c | 2 +-
1 file changed, 1 insertion(+), 1
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
Changes since V2:
- Removed duplicate errno print
Changes since V1:
- This time
On 04/11/2020 10:49, Dmitry Osipenko wrote:
> 04.11.2020 12:23, Jon Hunter пишет:
>> Deferred probe is an expected return value for tegra_output_probe().
>> Given that the driver deals with it properly, there's no need to output
>> a warning that may potentially confuse us
pplying this series, AHCI over PCI is back to normal:
>
> [3.543230] ahci 0001:01:00.0: AHCI 0001. 32 slots 1 ports 6 Gbps 0x1
> impl SATA mode
> [3.550841] ahci 0001:01:00.0: flags: 64bit ncq sntf led only pmp fbs pio
> slum part sxs
> [3.559747] scsi host0: ahci
> [3.561998] ata1: SATA max UDMA/133 abar m512@0x123001 port
> 0x1230010100 irq 63
>
> So for the series:
>
> Tested-by: Thierry Reding
FWIW ...
Tested-by: Jon Hunter
Cheers
Jon
--
nvpublic
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
Changes since V1:
- This time, I actually validated it!
drivers/gpu/drm
On 03/11/2020 11:44, Jon Hunter wrote:
> Deferred probe is an expected return value for tegra_output_probe().
> Given that the driver deals with it properly, there's no need to output
> a warning that may potentially confuse users.
>
> Signed-off-by: Jon Hunter
> ---
>
ence clock and dividing by a constant divisor.
Fixes: b89c01c96051 ("cpufreq: tegra186: Fix initial frequency")
Signed-off-by: Jon Hunter
---
drivers/cpufreq/tegra186-cpufreq.c | 33 +++---
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/t
Deferred probe is an expected return value for tegra_output_probe().
Given that the driver deals with it properly, there's no need to output
a warning that may potentially confuse users.
Signed-off-by: Jon Hunter
---
drivers/gpu/drm/tegra/sor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
180, tegra210-p3450-,
tegra30-cardhu-a04
Tested-by: Jon Hunter
The above failure is fixed in the mainline by the following commit ...
commit 97148d0ae5303bcc18fcd1c9b968a9485292f32a
Author: Viresh Kumar
Date: Tue Oct 13 10:42:47 2020 +0530
cpufreq: Improve code around unl
On 28/10/2020 04:11, Viresh Kumar wrote:
> On 26-10-20, 12:57, Jon Hunter wrote:
>> Thinking about this some more, what are your thoughts on making the
>> following change?
>>
>> Basically, if the driver sets the CPUFREQ_NEED_INITIAL_FREQ_CHECK,
>
> This
err = bpmp_populate_debugfs_inband(bpmp, dentry,
> pathbuf);
> if (err < 0)
>
However, this is indeed much better and so thanks for the simplification.
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 19/10/2020 10:33, Jon Hunter wrote:
>
> On 16/10/2020 05:07, Viresh Kumar wrote:
>> On 15-10-20, 15:03, Jon Hunter wrote:
>>> If not too late, would you mind dropping this patch for v5.10?
>>
>> It is already part of Linus's master now.
>
> OK, thanks.
1 - 100 of 7467 matches
Mail list logo
