On 17/09/2020 09:54, Marek Szyprowski wrote:
> Hi Jon,
>
> On 17.09.2020 10:49, Jon Hunter wrote:
>> On 17/09/2020 09:45, Marc Zyngier wrote:
>>> On 2020-09-17 08:54, Jon Hunter wrote:
>>>> On 17/09/2020 08:50, Marc Zyngier wrote:
>>>>> On 2
On 17/09/2020 15:53, Jon Hunter wrote:
...
>> next-20200916 completely broken on ARM and ARM64. Please check
>> next-20200915 + the mentioned fix or just check
>> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/ipi-as-irq
>
> OK,
On 17/09/2020 09:54, Marek Szyprowski wrote:
> Hi Jon,
>
> On 17.09.2020 10:49, Jon Hunter wrote:
>> On 17/09/2020 09:45, Marc Zyngier wrote:
>>> On 2020-09-17 08:54, Jon Hunter wrote:
>>>> On 17/09/2020 08:50, Marc Zyngier wrote:
>>>>> On 2
On 17/09/2020 09:45, Marc Zyngier wrote:
> On 2020-09-17 08:54, Jon Hunter wrote:
>> On 17/09/2020 08:50, Marc Zyngier wrote:
>>> Hi Linus,
>>>
>>> On 2020-09-17 08:40, Linus Walleij wrote:
>>>> On Wed, Sep 16, 2020 at 5:11 PM Marc Zyngier wrote
On 17/09/2020 09:38, Jon Hunter wrote:
>
> On 16/09/2020 18:11, Sumit Gupta wrote:
>> Warning coming during boot because the boot freq set by bootloader
>> gets filtered out due to big freq steps while creating freq_table.
>> Fixing this by setting closest ndiv value fro
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 keeps changing slightly. This change returns a consistent value
>>
e the previous frequency while
> turning-on non-boot cores during exit from SC7(Suspend-to-RAM).
Same here ...
Fixes: df320f89359c ("cpufreq: Add Tegra194 cpufreq driver")
>
> Signed-off-by: Sumit Gupta
Reviewed-by: Jon Hunter
Tested-by: Jon Hunter
Viresh, this is also needed for v5.9.
Thanks
Jon
--
nvpublic
> Signed-off-by: Sumit Gupta
Otherwise ...
Reviewed-by: Jon Hunter
Tested-by: Jon Hunter
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?
Thanks
Jon
--
nvpublic
On 17/09/2020 08:50, Marc Zyngier wrote:
> Hi Linus,
>
> On 2020-09-17 08:40, Linus Walleij wrote:
>> On Wed, Sep 16, 2020 at 5:11 PM Marc Zyngier wrote:
>>
>>> Can you try the patch below and let me know?
>>
>> I tried this patch and now Ux500 WORKS. So this patch is definitely
>> something yo
On 16/09/2020 16:55, Marc Zyngier wrote:
> On 2020-09-16 16:46, Jon Hunter wrote:
>> On 16/09/2020 16:10, Marc Zyngier wrote:
>>> Hi Jon,
>>>
>>> +Linus, who is facing a similar issue.
>>>
>>> On 2020-09-16 15:16, Jon Hunter wrote:
>>
On 16/09/2020 20:26, Mikko Perttunen wrote:
> Not sure which boards this issue is happening on, but looking at my
> hobby kernel's git history (from a couple of years ago, memory is a bit
> hazy), the commit labeled "Add support for TX2" adds code to drop from
> EL2 to EL1 at boot.
I am seeing b
On 16/09/2020 17:28, Marc Zyngier wrote:
...
> Make it that instead:
>
> static void gic_eoimode1_eoi_irq(struct irq_data *d)
> {
> + u32 hwirq = gic_irq(d);
> +
> /* Do not deactivate an IRQ forwarded to a vcpu. */
> if (irqd_is_forwarded_to_vcpu(d))
> return;
>
> -
On 16/09/2020 17:22, Marc Zyngier wrote:
> Do you boot form EL2?
Not that I am aware of. There is no hypervisor that we are using.
Jon
--
nvpublic
Hi Marc,
On 14/09/2020 14:06, Marek Szyprowski wrote:
> Hi Marc,
>
> On 01.09.2020 16:43, Marc Zyngier wrote:
>> Change the way we deal with GIC SGIs by turning them into proper
>> IRQs, and calling into the arch code to register the interrupt range
>> instead of a callback.
>>
>> Reviewed-by: Va
On 16/09/2020 16:10, Marc Zyngier wrote:
> Hi Jon,
>
> +Linus, who is facing a similar issue.
>
> On 2020-09-16 15:16, Jon Hunter wrote:
>> Hi Marc,
>>
>> On 14/09/2020 14:06, Marek Szyprowski wrote:
>>> Hi Marc,
>>>
>>> On 01.09
inding doc.
Jon Hunter (5):
misc: eeprom: at24: Initialise AT24 NVMEM ID field
dt-bindings: eeprom: at24: Add label property for AT24
misc: eeprom: at24: Support custom device names for AT24 EEPROMs
arm64: tegra: Add label properties for EEPROMs
arm64: tegra: Populate EEPROMs for Jetson
Add a label property for the AT24 EEPROM to allow a custom name to be
used for identifying the EEPROM on a board. This is useful when there
is more than one EEPROM present.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/eeprom/at24.yaml | 3 +++
1 file changed, 3 insertions
ed to as
the carrier board).
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts | 1 +
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 1 +
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 1 +
arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 1 +
arch/a
T24 EEPROM, we do not want the NVMEM driver to append the 'devid'
to the name and so the nvmem_config.id is initialised to
NVMEM_DEVID_NONE.
Signed-off-by: Jon Hunter
---
drivers/misc/eeprom/at24.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff
Populate the EEPROMs that are present on the Jetson Xavier NX developer
platform.
Signed-off-by: Jon Hunter
---
.../nvidia/tegra194-p3509-+p3668-.dts| 14 ++
.../boot/dts/nvidia/tegra194-p3668-.dtsi | 16
2 files changed, 30 insertions(+)
diff
onetheless we should ensure that the 'id' field of
the nvmem_config structure is initialised so that there is no chance of
a random value causes problems in the future. Therefore, set the NVMEM
config.id to NVMEM_DEVID_AUTO for AT24 EEPROMs so that the 'devid' is
always appended.
erefore, fix this by
setting the NVMEM config.id to NVMEM_DEVID_NONE for AT24 EEPROMs.
Signed-off-by: Jon Hunter
---
drivers/misc/eeprom/at24.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index e9df1ca251df..3f7a3bb6a36c 100644
--- a
By using the label property, a more descriptive name can be populated
for AT24 EEPROMs NVMEM device. Update the AT24 driver to check to see
if the label property is present and if so, use this as the name for
NVMEM device.
Signed-off-by: Jon Hunter
---
drivers/misc/eeprom/at24.c | 10
On 10/09/2020 19:15, Jon Hunter wrote:
>
> On 10/09/2020 16:35, Bartosz Golaszewski wrote:
>> On Thu, Sep 10, 2020 at 3:43 PM Jon Hunter wrote:
>>>
>>> The AT24 EEPROM driver does not initialise the 'id' field of the
>>> nvmem_config
On 10/09/2020 16:35, Bartosz Golaszewski wrote:
> On Thu, Sep 10, 2020 at 3:43 PM Jon Hunter wrote:
>>
>> The AT24 EEPROM driver does not initialise the 'id' field of the
>> nvmem_config structure and because the entire structure is not
>> initialised,
ed to as
the carrier board).
Signed-off-by: Jon Hunter
---
arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts | 1 +
arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 1 +
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 1 +
arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts | 1 +
arch/a
Populate the EEPROMs that are present on the Jetson Xavier NX developer
platform.
Signed-off-by: Jon Hunter
---
.../nvidia/tegra194-p3509-+p3668-.dts| 14 ++
.../boot/dts/nvidia/tegra194-p3668-.dtsi | 16
2 files changed, 30 insertions(+)
diff
Add a label property for the AT24 EEPROM to allow a custom name to be
used for identifying the EEPROM on a board. This is useful when there
is more than one EEPROM present.
Signed-off-by: Jon Hunter
---
Documentation/devicetree/bindings/eeprom/at24.yaml | 4
1 file changed, 4 insertions
platforms which is not only required by the kernel but the
bootloader as well. So having a simple way to identify the EEPROM is
needed.
Jon Hunter (5):
misc: eeprom: at24: Initialise AT24 NVMEM ID field
dt-bindings: eeprom: at24: Add label property for AT24
misc: eeprom: at24: Support custom
On 02/09/2020 17:23, Krzysztof Kozlowski wrote:
> On Wed, 2 Sep 2020 at 16:45, Naresh Kamboju wrote:
>>
>> On Thu, 27 Aug 2020 at 15:44, Matthias Brugger
>> wrote:
>>>
>>>
>>>
>>> On 12/11/2019 12:03, Pi-Hsun Shih wrote:
From: Eddie Huang
Add scp node to mt8183 and mt8183-evb
>
On 27/08/2020 16:43, Sowjanya Komatineni wrote:
>
> On 8/27/20 8:14 AM, Jon Hunter wrote:
>> On 27/08/2020 16:03, Sowjanya Komatineni wrote:
>>> On 8/27/20 1:40 AM, Jon Hunter wrote:
>>>> On 27/08/2020 04:50, Sowjanya Komatineni wrote:
>>>>>
On 27/08/2020 16:03, Sowjanya Komatineni wrote:
>
> On 8/27/20 1:40 AM, Jon Hunter wrote:
>> On 27/08/2020 04:50, Sowjanya Komatineni wrote:
>>> commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
>>>
>>> Tegra210 and later has a separat
inctrl-names = "sdmmc-3v3", "sdmmc-1v8";
> + pinctrl-0 = <&sdmmc1_3v3>;
> + pinctrl-1 = <&sdmmc1_1v8>;
> + nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>;
> + nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>;
> + nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>;
> + nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>;
> + status = "disabled";
> +};
>
Thanks!
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
ra SDMMC hardware and having TMCLK not enabled
> is not recommended.
>
> So, this patch adds quirk NVQUIRK_HAS_TMCLK for SoC having separate
> timeout clock and keeps TMCLK enabled all the time.
>
> Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
> Cc:
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 warnings are now see
On 24/08/2020 20:15, Sowjanya Komatineni wrote:
> Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data
> timeout.
>
> So, this patch adds "tmclk" to Tegra sdhci clock property in the
> device tree binding.
>
> Signed-off-by: Sowjanya Komatineni
> ---
> .../bindings/mmc/nvidia,tegra
ra SDMMC hardware and having TMCLK not enabled
> is not recommended.
>
> So, this patch fixes it.
>
> Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support")
> Cc: stable # 5.4
> Tested-by: Jon Hunter
> Reviewed-by: Jon Hunter
> Acked-by: Adrian Hunter
ting frequency for a given CPU. The 'get'
callback uses the current 'ndiv' value that is programmed to determine
that current operating frequency.
Signed-off-by: Jon Hunter
---
Changes since V1:
- Moved code into a 'get' callback
drivers/cpufreq/tegra186-cpufreq.c |
On 20/08/2020 10:19, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.194 release.
> There are 228 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
On 06/08/2020 08:30, Rajesh Gumasta wrote:
> Add device tree node for GPCDMA controller on Tegra186 target
> and Tegra194 target.
>
> Signed-off-by: Rajesh Gumasta
> ---
> arch/arm64/boot/dts/nvidia/tegra186-p3310.dtsi | 4 +++
> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 46
>
On 06/08/2020 08:30, Rajesh Gumasta wrote:
> Adding GPC DMA controller driver for Tegra186 and Tegra194. The driver
> supports dma transfers between memory to memory, IO peripheral to memory
> and memory to IO peripheral.
>
> Signed-off-by: Pavan Kunapuli
> Signed-off-by: Rajesh Gumasta
> ---
On 06/08/2020 08:30, Rajesh Gumasta wrote:
> Adding GPC DMA controller driver for Tegra186 and Tegra194. The driver
> supports dma transfers between memory to memory, IO peripheral to memory
> and memory to IO peripheral.
>
> Signed-off-by: Pavan Kunapuli
> Signed-off-by: Rajesh Gumasta
> ---
"tx3",
> + "rx4", "tx4",
> + "rx5", "tx5",
> + "rx6", "tx6",
> + "rx7", "tx7",
> + "rx8", "tx8",
> + "rx9", "tx9",
> + "rx10", "tx10";
> + status = "disabled";
> + };
> +
> + tegra_i2s1: i2s@702d1000 {
> + compatible = "nvidia,tegra210-i2s";
> + reg = <0x702d1000 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_I2S0>,
> + <&tegra_car TEGRA210_CLK_I2S0_SYNC>;
> + clock-names = "i2s", "sync_input";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_I2S0>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <1536000>;
> + sound-name-prefix = "I2S1";
> + status = "disabled";
> + };
> +
> + tegra_i2s2: i2s@702d1100 {
> + compatible = "nvidia,tegra210-i2s";
> + reg = <0x702d1100 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_I2S1>,
> + <&tegra_car TEGRA210_CLK_I2S1_SYNC>;
> + clock-names = "i2s", "sync_input";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_I2S1>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <1536000>;
> + sound-name-prefix = "I2S2";
> + status = "disabled";
> + };
> +
> + tegra_i2s3: i2s@702d1200 {
> + compatible = "nvidia,tegra210-i2s";
> + reg = <0x702d1200 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_I2S2>,
> + <&tegra_car TEGRA210_CLK_I2S2_SYNC>;
> + clock-names = "i2s", "sync_input";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_I2S2>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <1536000>;
> + sound-name-prefix = "I2S3";
> + status = "disabled";
> + };
> +
> + tegra_i2s4: i2s@702d1300 {
> + compatible = "nvidia,tegra210-i2s";
> + reg = <0x702d1300 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_I2S3>,
> + <&tegra_car TEGRA210_CLK_I2S3_SYNC>;
> + clock-names = "i2s", "sync_input";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_I2S3>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <1536000>;
> + sound-name-prefix = "I2S4";
> + status = "disabled";
> + };
> +
> + tegra_i2s5: i2s@702d1400 {
> + compatible = "nvidia,tegra210-i2s";
> + reg = <0x702d1400 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_I2S4>,
> + <&tegra_car TEGRA210_CLK_I2S4_SYNC>;
> + clock-names = "i2s", "sync_input";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_I2S4>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <1536000>;
> + sound-name-prefix = "I2S5";
> + status = "disabled";
> + };
> +
> + tegra_dmic1: dmic@702d4000 {
> + compatible = "nvidia,tegra210-dmic";
> + reg = <0x702d4000 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_DMIC1>;
> + clock-names = "dmic";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_DMIC1>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <3072000>;
> + sound-name-prefix = "DMIC1";
> + status = "disabled";
> + };
> +
> + tegra_dmic2: dmic@702d4100 {
> + compatible = "nvidia,tegra210-dmic";
> + reg = <0x702d4100 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_DMIC2>;
> + clock-names = "dmic";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_DMIC2>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <3072000>;
> + sound-name-prefix = "DMIC2";
> + status = "disabled";
> + };
> +
> + tegra_dmic3: dmic@702d4200 {
> + compatible = "nvidia,tegra210-dmic";
> + reg = <0x702d4200 0x100>;
> + clocks = <&tegra_car TEGRA210_CLK_DMIC3>;
> + clock-names = "dmic";
> + assigned-clocks = <&tegra_car
> TEGRA210_CLK_DMIC3>;
> + assigned-clock-parents = <&tegra_car
> TEGRA210_CLK_PLL_A_OUT0>;
> + assigned-clock-rates = <3072000>;
> + sound-name-prefix = "DMIC3";
> + status = "disabled";
> + };
> + };
> };
>
> spi@7041 {
>
Thanks LGTM!
Reviewed-by: Jon Hunter
Cheers!
Jon
--
nvpublic
ay";
> +
> + dma@702e2000 {
> + status = "okay";
> + };
> +
> + interrupt-controller@702f9000 {
> + status = "okay";
> + };
> + };
> };
>
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
CONFIG_TEGRA20_APB_DMA=y
> +CONFIG_TEGRA210_ADMA=m
> CONFIG_QCOM_BAM_DMA=y
> CONFIG_QCOM_HIDMA_MGMT=y
> CONFIG_QCOM_HIDMA=y
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
ND_SOC_AK4613=m
> CONFIG_SND_SOC_ES7134=m
> CONFIG_SND_SOC_ES7241=m
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
nterrupt.
Fixes: d8f090dbeafd ("rtc: max77686: Do not allow interrupt to fire before
system resume")
Signed-off-by: Jon Hunter
---
drivers/rtc/rtc-max77686.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max
Hi Viresh,
On 14/07/2020 04:46, Viresh Kumar wrote:
...
> The get() callback is supposed to read the frequency from hardware and
> return it, no cached value here. policy->cur may end up being wrong in
> case there is a bug.
I have been doing some more testing on Tegra, I noticed that when
read
On 23/07/2020 12:19, Greg Kroah-Hartman wrote:
> On Wed, Jul 15, 2020 at 12:38:42PM +0100, Jon Hunter wrote:
>> Commit 5c4e8d3781bc ("usb: host: xhci-tegra: Add support for XUSB
>> context save/restore") is using the IPFS 'num_offsets' value when
>> allo
On 28/07/2020 16:51, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.135 release.
> There are 86 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 s
On 27/07/2020 13:47, Aniruddha Rao wrote:
> Add runtime suspend/resume callbacks to save power
> when the bus is not in use.
> In runtime suspend
> - Turn off the SDMMC host CAR clock.
> - Turn off the trimmer/DLL circuit(BG) power supply(VREG).
> - Turn off the SDMMC host internal clocks.
>
> R
https://lore.kernel.org/linux-arm-kernel/20191210120909.GA2703785@ulmo/T/
> Signed-off-by: Dmitry Osipenko
> ---
>
> Changelog:
>
> v4: - Renamed pllm_pmc_clk_enabled() to pllm_clk_is_gated_by_pmc() as
> it was suggested by Jon Hunter in the review comment to v3.
&g
On 15/07/2020 14:31, Sumit Gupta wrote:
> Add support for CPU frequency scaling on Tegra194. The frequency
> of each core can be adjusted by writing a clock divisor value to
> a MSR on the core. The range of valid divisors is queried from
> the BPMP.
>
> Signed-off-by: Mikko Perttunen
> Signed-
L pointer deference when we access the memory. Fix this by
correcting the amount of memory we are allocating for FPCI contexts.
Cc: sta...@vger.kernel.org
Fixes: 5c4e8d3781bc ("usb: host: xhci-tegra: Add support for XUSB context
save/restore")
Signed-off-by: Jon Hunter
Acked-by: Thier
On 14/07/2020 19:42, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.7.9 release.
> There are 166 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 sho
On 14/07/2020 19:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.52 release.
> There are 109 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 sh
On 14/07/2020 19:43, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.133 release.
> There are 58 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 s
On 14/07/2020 10:32, Thierry Reding wrote:
> On Sun, Jul 12, 2020 at 11:28:37AM +0100, Jon Hunter wrote:
>> After commit cad064f1bd52 ("devres: handle zero size in devm_kmalloc()")
>> was added system suspend started failing on Tegra186. The kernel log
>> showed
On 14/07/2020 17:18, Thierry Reding wrote:
> On Sun, Jul 12, 2020 at 11:01:13AM +0100, Jon Hunter wrote:
>> This series adds support for in-band debug messaging for the BPMP and
>> updates the BPMP ABI to align with the latest version.
>>
>> Jon Hunter (4):
>>
https://lore.kernel.org/linux-arm-kernel/20191210120909.GA2703785@ulmo/T/
> Signed-off-by: Dmitry Osipenko
> ---
>
> Changelog:
>
> v4: - Renamed pllm_pmc_clk_enabled() to pllm_clk_is_gated_by_pmc() as
> it was suggested by Jon Hunter in the review comment to v3.
&g
On 14/07/2020 04:46, Viresh Kumar wrote:
> On 13-07-20, 17:37, Jon Hunter wrote:
>>
>> On 13/07/2020 04:25, Viresh Kumar wrote:
>>> On 12-07-20, 11:06, Jon Hunter wrote:
>>>> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
>>>> CPUFREQ_NEE
iter to the proxy ops to prepare for seq_file to
>> be switch to ->read_iter.
>>
>> Reported-by: Jon Hunter
>> Signed-off-by: Christoph Hellwig
>
> Acked-by: Greg Kroah-Hartman
>
Tested-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 13/07/2020 04:25, Viresh Kumar wrote:
> On 12-07-20, 11:06, 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 warnings are now see
On 24/06/2020 03:23, Rishabh Bhatnagar wrote:
> Currently there is a single notification chain which is called whenever any
> remoteproc shuts down. This leads to all the listeners being notified, and
> is not an optimal design as kernel drivers might only be interested in
> listening to notifica
On 13/07/2020 15:39, Zhenyu Ye wrote:
> Hi Jon,
>
> On 2020/7/13 22:27, Jon Hunter wrote:
>> After this change I am seeing the following build errors ...
>>
>> /tmp/cckzq3FT.s: Assembler messages:
>> /tmp/cckzq3FT.s:854: Error: unknown or missing operation name
On 10/07/2020 10:44, Zhenyu Ye wrote:
> Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range().
>
> When cpu supports TLBI feature, the minimum range granularity is
> decided by 'scale', so we can not flush all pages by one instruction
> in some cases.
>
> For example, when the pages = 0x
d FPCI contexts when required.
Cc: sta...@vger.kernel.org
Fixes: 5c4e8d3781bc ("usb: host: xhci-tegra: Add support for XUSB context
save/restore")
Signed-off-by: Jon Hunter
---
drivers/usb/host/xhci-tegra.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
d
cause too much memory or too little memory to be allocated. Fix this
by using the FPCI 'num_offsets' for allocating the FPCI memory for
storing the FPCI state.
Cc: sta...@vger.kernel.org
Fixes: 5c4e8d3781bc ("usb: host: xhci-tegra: Add support for XUSB context
save/restore")
We always put the reference to BPMP device on exit of the Tegra186
CPUFREQ driver and so there is no need to have separate exit paths
for success and failure. Therefore, simplify the probe return path
in the Tegra186 CPUFREQ driver by combining the success and failure
paths.
Signed-off-by: Jon
hen initialising
the CPUFREQ driver.
Signed-off-by: Jon Hunter
---
drivers/cpufreq/tegra186-cpufreq.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/cpufreq/tegra186-cpufreq.c
b/drivers/cpufreq/tegra186-cpufreq.c
index 3d2f143748ef..c44190ce3f03 100644
--- a/drivers/cpufre
This series adds support for in-band debug messaging for the BPMP and
updates the BPMP ABI to align with the latest version.
Jon Hunter (4):
firmware: tegra: Use consistent return variable name
firmware: tegra: Prepare for supporting in-band debugfs
firmware: tegra: Add support for in-band
, ensure that no access outside of allocated memory buffer
happens in case BPMP-FW returns an invalid response size (nbytes) from
mrq_debugfs_dumpdir() call.
Signed-off-by: Timo Alho
Signed-off-by: Jon Hunter
---
drivers/firmware/tegra/bpmp-debugfs.c | 12 ++--
1 file changed, 10 insertions
Update the BPMP ABI to align with the the latest version.
Signed-off-by: Jon Hunter
---
include/soc/tegra/bpmp-abi.h | 748 +--
1 file changed, 460 insertions(+), 288 deletions(-)
diff --git a/include/soc/tegra/bpmp-abi.h b/include/soc/tegra/bpmp-abi.h
index
Most functions in the BPMP driver use 'err' as the return variable
name but there are a few places that use 'ret'. Let's use 'err' to
be consistent.
Signed-off-by: Jon Hunter
---
drivers/firmware/tegra/bpmp-debugfs.c | 36 +--
drivers
BPMP, move the shared-memory specific initialisation from the
tegra_bpmp_init_debugfs() into a sub-function.
Signed-off-by: Jon Hunter
---
drivers/firmware/tegra/bpmp-debugfs.c | 53 ---
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/drivers/firmware/tegra
. Therefore, if the BPMP firmware supports the in-band
messaging for debug use this and otherwise fall-back to using shared
memory.
Signed-off-by: Jon Hunter
---
drivers/firmware/tegra/bpmp-debugfs.c | 377 +-
include/soc/tegra/bpmp-abi.h | 189 -
2 files
t;read_iter
>
> debugfs registrations typically go through a set of proxy ops to deal
> with refcounting, which need to support every method that can be
> supported. Add ->read_iter to the proxy ops to prepare for seq_file to
> be switch to ->read_iter.
>
> Reported-by: Jon Hunt
On 10/07/2020 17:24, Bartosz Golaszewski wrote:
> On Fri, Jul 10, 2020 at 6:11 PM Jon Hunter wrote:
>>
>>
>> On 10/07/2020 17:03, Bartosz Golaszewski wrote:
>>> On Fri, Jul 10, 2020 at 3:46 PM Jon Hunter wrote:
>>>>
>>>> Hi Bartosz,
&g
On 10/07/2020 17:03, Bartosz Golaszewski wrote:
> On Fri, Jul 10, 2020 at 3:46 PM Jon Hunter wrote:
>>
>> Hi Bartosz,
>>
>> On 29/06/2020 07:50, Bartosz Golaszewski wrote:
>>> From: Bartosz Golaszewski
>>>
>>> Make devm_kmall
Hi Bartosz,
On 29/06/2020 07:50, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Make devm_kmalloc() behave similarly to non-managed kmalloc(): return
> ZERO_SIZE_PTR when requested size is 0. Update devm_kfree() to handle
> this case.
>
> Signed-off-by: Bartosz Golaszewski
> ---
>
Hi Christoph,
On 07/07/2020 18:47, Christoph Hellwig wrote:
> Switch over all instances used directly as methods using these sed
> expressions:
>
> sed -i -e 's/\.read\(\s*=\s*\)seq_read/\.read_iter\1seq_read_iter/g'
>
> Signed-off-by: Christoph Hellwig
> ---
> Documentation/filesystems/seq_fi
On 08/07/2020 08:54, Dmitry Osipenko wrote:
> Power Management Controller (PMC) can override the PLLM clock settings,
> including the enable-state. Although PMC could only act as a second level
> gate, meaning that PLLM needs to be enabled by the Clock and Reset
> Controller (CaR) anyways if we w
On 08/07/2020 16:15, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2020 at 09:41:33AM +0100, Jon Hunter wrote:
>>
>> On 07/07/2020 16:16, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 5.4.51 release.
>>> There are 65 patches i
global_fault,
> IRQF_SHARED,
> "arm-smmu global fault",
> smmu);
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index fad63efa1a72..d890a4a968e8 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -389,6 +390,8 @@ struct arm_smmu_impl {
> void (*tlb_sync)(struct arm_smmu_device *smmu, int page, int sync,
>int status);
> int (*def_domain_type)(struct device *dev);
> + irqreturn_t (*global_fault)(int irq, void *dev);
> + irqreturn_t (*context_fault)(int irq, void *dev);
> };
>
> static inline void __iomem *arm_smmu_page(struct arm_smmu_device *smmu, int
> n)
>
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
ible:
> + contains:
> +enum:
> + - nvidia,tegra194-smmu
> +then:
> + properties:
> +reg:
> + minItems: 2
> + maxItems: 2
> +
> examples:
>- |+
> /* SMMU with stream matching or stream indexing */
>
Reviewed-by: Jon Hunter
Thanks
Jon
--
nvpublic
c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -1943,6 +1943,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
> { .compatible = "arm,mmu-401", .data = &arm_mmu401 },
> { .compatible = "arm,mmu-500", .data = &arm_mmu500 },
> { .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
> + { .compatible = "nvidia,smmu-500", .data = &arm_mmu500 },
> { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
> { },
> };
> diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
> index c7d0122a7c6c..fad63efa1a72 100644
> --- a/drivers/iommu/arm-smmu.h
> +++ b/drivers/iommu/arm-smmu.h
> @@ -452,6 +452,7 @@ static inline void arm_smmu_writeq(struct arm_smmu_device
> *smmu, int page,
> arm_smmu_writeq((s), ARM_SMMU_CB((s), (n)), (o), (v))
>
> struct arm_smmu_device *arm_smmu_impl_init(struct arm_smmu_device *smmu);
> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu);
> struct arm_smmu_device *qcom_smmu_impl_init(struct arm_smmu_device *smmu);
>
> int arm_mmu500_reset(struct arm_smmu_device *smmu);
>
Reviewed-by: Jon Hunter
Thanks
Jon
--
nvpublic
l_init(smmu);
> + if (IS_ERR(smmu))
> + return PTR_ERR(smmu);
> +
> num_irqs = 0;
> while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, num_irqs))) {
> num_irqs++;
>
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
S 128
>
> +#define TLB_LOOP_TIMEOUT 100 /* 1s! */
> +#define TLB_SPIN_COUNT 10
>
> /* Shared driver definitions */
> enum arm_smmu_arch_version {
>
Reviewed-by: Jon Hunter
Thanks!
Jon
--
nvpublic
On 07/07/2020 16:16, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.132 release.
> There are 36 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 s
On 07/07/2020 16:16, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.51 release.
> There are 65 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 sho
On 07/07/2020 16:15, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.188 release.
> There are 27 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 s
On 07/07/2020 16:13, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.230 release.
> There are 24 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 sh
On 07/07/2020 16:10, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.230 release.
> There are 19 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 sh
0xc300 0x1c 0x 0x1c 0x 0x3
> 0x4000 /* prefetchable memory (13GB) */
> - 0x8200 0x0 0x4000 0x1f 0x4000 0x0
> 0xc000>; /* non-prefetchable memory (3GB) */
> + ranges = <0xc300 0x1c 0x 0x1c 0x 0x3
> 0x4000 /* prefetchable memory (13GB) */
> + 0x8200 0x00 0x4000 0x1f 0x4000 0x0
> 0xbfff /* non-prefetchable memory (3GB - 64KB) */
> + 0x8100 0x00 0x 0x1f 0x 0x0
> 0x0001>; /* downstream I/O (64KB) */
> };
>
> pcie_ep@1416 {
>
Acked-by: Jon Hunter
Cheers!
Jon
--
nvpublic
p;
> - (reg <= LAST_REG(DAP_CTRL_SEL)))
> + if (reg <= LAST_REG(DAP_CTRL_SEL))
> return true;
> if ((reg >= TEGRA20_DAS_DAC_INPUT_DATA_CLK_SEL) &&
> (reg <= LAST_REG(DAC_INPUT_DATA_CLK_SEL)))
>
Thanks!
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 01/07/2020 20:00, Krishna Reddy wrote:
> +items:
> + - enum:
> + - nvdia,tegra194-smmu
> + - const: arm,mmu-500
>>>
Is the fallback compatible appropriate here? If software treats this as a
standard MMU-500 it will only program
On 01/07/2020 19:28, Krishna Reddy wrote:
>>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500"
>> Hmm, there must be a better way to word that to express that it only applies
>> to the sets of SMMUs that must be programmed identically, and not any other
>> independent MMU-
On 01/07/2020 00:57, Krishna Reddy wrote:
> Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
> on ARM MMU-500.
>
> Signed-off-by: Krishna Reddy
> ---
> .../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/
On 01/07/2020 00:57, Krishna Reddy wrote:
> NVIDIA's Tegra194 SoC has three ARM MMU-500 instances.
> It uses two of ARM MMU-500s together to interleave IOVA accesses
> across them and must be programmed identically.
> The third SMMU instance is used as a regular ARM MMU-500 and it
> can either be
On 30/06/2020 18:16, Krishna Reddy wrote:
>> OK, well I see what you are saying, but if we intended to support all 3 for
>> Tegra194, then we should ensure all 3 are initialised correctly.
>
> The driver intend to support up to 3 instances. It doesn't really mandate
> that all three instances
101 - 200 of 1296 matches
Mail list logo
