/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
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 domain structure, the top one being a
> generic PCI/MSI domain, the bottom one being
On 15/10/2020 15:55, Masami Hiramatsu wrote:
> To help debugging kernel, show real address for trace event arguments
> in tracefs/trace{,pipe} instead of hashed pointer value.
>
> Since ftrace human-readable format uses vsprintf(), all %p are
> translated to hash values instead of pointer
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
On 08/04/2021 08:26, Dinghao Liu wrote:
> pm_runtime_get_sync() will increase the runtime PM counter
> even it returns an error. Thus a pairing decrement is needed
> to prevent refcount leak. Fix this by replacing this API with
> pm_runtime_resume_and_get(), which will not change the runtime
>
On 08/04/2021 08:11, Dinghao Liu wrote:
> pm_runtime_get_sync() will increase the rumtime PM counter
> even it returns an error. Thus a pairing decrement is needed
> to prevent refcount leak. Fix this by replacing this API with
> pm_runtime_resume_and_get(), which will not change the runtime
>
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
>> since Linux v5.8 and so we have the ability to bisect such regressions. So
>> it is
>>
On 31/03/2021 12:10, Joakim Zhang wrote:
...
You mean one of your boards? Does other boards with STMMAC can
work
>>> fine?
>>>
>>> We have two devices with the STMMAC and one works OK and the
>>> other
> fails.
>>> They are different generation of
On 31/03/2021 08:43, Joakim Zhang wrote:
...
>>> You mean one of your boards? Does other boards with STMMAC can
>>> work
>> fine?
>>
>> We have two devices with the STMMAC and one works OK and the other
fails.
>> They are different generation of device and so there
On 25/03/2021 08:12, Joakim Zhang wrote:
...
> You mean one of your boards? Does other boards with STMMAC can work
fine?
We have two devices with the STMMAC and one works OK and the other
>> fails.
They are different generation of device and so there could be some
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
On 24/03/2021 12:20, Joakim Zhang wrote:
...
> Sorry for this breakage at your side.
>
> You mean one of your boards? Does other boards with STMMAC can work fine?
We have two devices with the STMMAC and one works OK and the other
fails. They are different generation of device and so there
Hi Joakim,
Starting with v5.12-rc3 I noticed that one of our boards, Tegra186
Jetson TX2, was not long resuming from suspend. Bisect points to commit
9c63faaa931e ("net: stmmac: re-init rx buffers when mac resume back")
and reverting this on top of mainline fixes the problem.
Interestingly, the
> 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
On 10/03/2021 18:37, Pierre-Louis Bossart wrote:
>
Build time dependencies aren't going to help anything, arm64 (and to my
understanding some future x86 systems, LynxPoint IIRC) supports both DT
and ACPI and so you have kernels built with support for both.
>>
>>> well, that's
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
On 10/02/2021 22:56, Andrew Lunn wrote:
> On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
>> Hi,
>>
>> This email was triggered by this other email[1].
>
> And it appears the Tegra194 Jetson Xavier uses the Marvell 88E1512
> PHY. So ensure the Marvell driver is available, and
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
On 31/01/2021 18:40, Ion Agorria wrote:
> From: Ion Agorria
>
> Adds support for Tegra SoC devices with RT5631 sound codec.
> Playback to speakers, headphones and internal mic recording works.
>
> This driver is used for ASUS Transformer TF201, TF700T and others
> Tegra based devices
On 31/01/2021 18:41, Ion Agorria wrote:
> From: Svyatoslav Ryhel
>
> Add Tegra ASoC driver for Realtek ALC5631/RT5631 codec. The RT5631
> codec is found on devices like ASUS Transformer TF201, TF700T and other
> Tegra-based Android tablets.
>
> Signed-off-by: Svyatoslav Ryhel
>
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
> <&{/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
On 11/11/2020 02:11, Nick Desaulniers wrote:
> The "fallthrough" pseudo-keyword was added as a portable way to denote
> intentional fallthrough. This code seemed to be using a mix of
> fallthrough comments that GCC recognizes, and some kind of lint marker.
> I'm guessing that linter hasn't been
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
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 consumer device when this warning is
> happening and let me know? That'd help too. I'm guessing the phy
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
On 13/01/2021 21:29, Saravana Kannan wrote:
...
>> I am seeing the same problem on Tegra30 Cardhu A04 where several regulators
>> are continuously deferred and prevents the board from booting ...
>>
>> [2.518334] platform panel: probe deferral - supplier regulator@11 not
>> ready
>>
>> [
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
On 13/01/2021 11:11, Marc Zyngier wrote:
> On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
>> On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
>>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>>> be broken using logic was one of the last remaining
On 18/12/2020 03:16, Saravana Kannan wrote:
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a cyclic dependency is
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
_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
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
On 18/12/2020 15:42, Masahiro Yamada 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.
>>
>
>
> Yes, please do so.
>
>
> Kconfig evaluates $(CC) capabilities, and
> hides CONFIG options it cannot
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
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
>> wrote:
>>> On 03.12.2020 13:57, Masahiro Yamada wrote:
Linus pointed out a third of the time in the Kconfig parse stage comes
from the
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
On 04/12/2020 16:07, Marek Szyprowski wrote:
> Hi All,
>
> On 04.12.2020 14:42, Qian Cai wrote:
>> On Thu, 2020-12-03 at 23:23 +0800, carver4...@163.com wrote:
>>> From: Hailong Liu
>>>
>>> When system in the booting stage, pages span from [start, end] of a memblock
>>> are freed to buddy in a
On 01/12/2020 21:12, Sowjanya Komatineni wrote:
> Tegra SoC has a Quad SPI controller starting from Tegra210.
>
> This patch adds support for Tegra210 QSPI controller.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> drivers/spi/Kconfig |9 +
> drivers/spi/Makefile |1 +
>
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
On 25/11/2020 20:45, Alex Elder wrote:
> Update the IPA code to make use of the updated IPA v4.5 register
> definitions. Generally what this patch does is, if IPA v4.5
> hardware is in use:
> - Ensure new registers or fields in IPA v4.5 are updated where
> required
> - Ensure registers
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.
>
> Signed-off-by: Dmitry Osipenko
This change is generating the following warning on Tegra20 Ventana
and prevents the EMC from probing ...
[
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
On 24/11/2020 11:14, claudiu.bez...@microchip.com wrote:
...
> I would say that a solution would be to have a new helper to retrieve the
> linear_min_sel (e.g. regulator_min_sel()) and use this for all the
> consumers of regulator_list_voltage() and the other APIs that patch
> "regulator:
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"
On 13/11/2020 15:21, Claudiu Beznea wrote:
> There are regulators who's min selector is not zero. Selectors loops
> (looping b/w zero and regulator::desc::n_voltages) might throw errors
> because invalid selectors are used (lower than
> regulator::desc::linear_min_sel). For this situations
://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
On 11/11/2020 18:34, Sameer Pujar wrote:
> Add Tegra audio machine driver which is based on generic audio graph card
> driver. It re-uses most of the common stuff from audio graph driver and
> uses the same DT binding. Required Tegra specific customizations are done
> in the driver and
-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
On 12/11/2020 10:51, Dmitry Osipenko wrote:
...
> If you don't see a message in KMSG saying "bringing vdd_cpu to
> 100uV", then should be good.
The bootlog shows ...
[2.271768] tps6586x 3-0034: Found TPS658621C/D, VERSIONCRC is 2c
[2.280320] vdd_sys: supplied by vdd_5v0
[
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-0000,
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.
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. I will send a revert for this once rc1 is out.
Cheers
Jon
--
nvpublic
-g1cbc5f2d0eac
Boards tested: tegra124-jetson-tk1, tegra186-p2771-,
tegra194-p2972-, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04
Tested-by: Jon Hunter
Jon
[0]
https://lore.kernel.org/linux-pm/37c3f
Hi Viresh,
On 25/08/2020 06:50, Viresh Kumar wrote:
> On 24-08-20, 15:59, Jon Hunter wrote:
>> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
>> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for
>> Tegra186 but as a consequence the following w
that we need to look
at next.
> So, I'm tempted to say:
>
> Tested-by: Thierry Reding
Yes and you can have my ...
Tested-by: Jon Hunter
Thanks again Marc for tracking this down!
Cheers
Jon
--
nvpublic
On 05/10/2020 05:34, Viresh Kumar wrote:
> On 17-09-20, 09:36, Jon Hunter wrote:
>> Viresh, ideally we need to include this fix for v5.9. Do you need Sumit
>> to resend with the Fixes tag or are you happy to add?
>
> I understand that this fixes a patch which got merg
On 01/10/2020 20:07, Michał Mirosław wrote:
> On Thu, Oct 01, 2020 at 11:03:04PM +0530, Sameer Pujar wrote:
>> Add Tegra audio machine driver which is based on generic audio graph card
>> driver. It re-uses most of the common stuff from audio graph driver and
>> uses the same DT binding.
On 29/09/2020 18:25, Marc Zyngier wrote:
> On 2020-09-29 14:22, Jon Hunter wrote:
>> Hi Jisheng,
>>
>> On 29/09/2020 11:48, Jisheng Zhang wrote:
>>> Hi Jon,
>>>
>>> On Fri, 25 Sep 2020 09:53:45 +0100 Jon Hunter wrote:
>>>
>>>>
Hi Jisheng,
On 29/09/2020 11:48, Jisheng Zhang wrote:
> Hi Jon,
>
> On Fri, 25 Sep 2020 09:53:45 +0100 Jon Hunter wrote:
>
>>
>> On 24/09/2020 12:05, Jisheng Zhang wrote:
>>> Improve the msi code:
>>> 1. Add proper error handling.
>>> 2. Mo
On 27/09/2020 09:28, Jisheng Zhang wrote:
...
> I see, the msi_domain_set_affinity() calls parent->chip->irq_set_affinity
> without checking, grepping the irqchip and pci dir, I found that
> if the MSI is based on some cascaded interrupt mechanism, they all
> point the irq_set_affinity to
Hi Jisheng,
On 25/09/2020 10:27, Jisheng Zhang wrote:
...
>> Could you please try below patch?
>>
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
>> b/drivers/pci/controller/dwc/pcie-designware-host.c
>> index bf25d783b5c5..7e5dc54d060e 100644
>> ---
On 24/09/2020 12:05, Jisheng Zhang wrote:
> Improve the msi code:
> 1. Add proper error handling.
> 2. Move dw_pcie_msi_init() from each users to designware host to solve
> msi page leakage in resume path.
Apologies if this is slightly off topic, but I have been meaning to ask
about MSIs and
On 23/09/2020 10:15, Bartosz Golaszewski wrote:
> On Wed, Sep 16, 2020 at 11:50 AM Jon Hunter wrote:
>>
>> For platforms that have multiple boards and hence have multiple EEPROMs
>> for identifying the different boards, it is useful to label the EEPROMs
>> in d
Hi Rafael, Sudeep,
On 17/09/2020 09:44, Jon Hunter wrote:
> Adding Sudeep ...
>
> On 17/09/2020 09:36, Jon Hunter wrote:
>>
>>
>> On 16/09/2020 18:11, Sumit Gupta wrote:
>>> Frequency returned by 'cpuinfo_cur_freq' using counters is not fixed
>>> and
1 - 100 of 3084 matches
Mail list logo
