FWIW, we had this problem some years ago with the Tegra CPU clock - then
it was determined that a simpler solution was to have the determine_rate
callback support unsigned long rates - so clock drivers that need to
return rates higher than 2^31 can instead implement the determine_rate
On 01.07.2017 05:53, Eduardo Valentin wrote:
Hey Mikko,
Sorry for the late answer,
Likewise,
On Fri, Jun 16, 2017 at 02:28:25PM +0300, Mikko Perttunen wrote:
On Tegra186, the BPMP (Boot and Power Management Processor) exposes an
interface to thermal sensors on the system-on-chip
On 01.07.2017 02:56, Eduardo Valentin wrote:
On Fri, Jun 16, 2017 at 02:28:22PM +0300, Mikko Perttunen wrote:
This adds the thermal sensor device provided by the BPMP, and the
relevant thermal sensors to the Tegra186 device tree.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia
Thanks for the patch, didn't consider this case. I really need to get
together some system to automatically test on multiple platforms.. :)
Reviewed-by: Mikko Perttunen
On 10.07.2017 22:33, Paul Kocialkowski wrote:
When there is no device to attach to the IOMMU domain, as may be the
case
On 07/11/2017 05:44 PM, Paul Kocialkowski wrote:
On Tue, 2017-07-11 at 14:37 +, Marcel Ziswiler wrote:
On Tue, 2017-07-11 at 11:49 +0300, Paul Kocialkowski wrote:
On Mon, 2017-07-10 at 21:33 +0200, Paul Kocialkowski wrote:
When there is no device to attach to the IOMMU domain, as may be
The Tegra186 CCPLEX_CLUSTER area contains memory-mapped
registers that initiate CPU frequency/voltage transitions.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b
The Tegra186 CCPLEX_CLUSTER area contains memory-mapped
registers that initiate CPU frequency/voltage transitions.
Signed-off-by: Mikko Perttunen
---
.../arm/tegra/nvidia,tegra186-ccplex-cluster.txt| 17 +
1 file changed, 17 insertions(+)
create mode 100644
Hi,
these are the device tree and bindings changes for the Tegra186 cpufreq
driver that was recently merged. The patches are the same as those that
were originally posted with the driver.
Mikko Perttunen (2):
dt-bindings: Add bindings for nvidia,tegra186-ccplex-cluster
arm64: tegra: Add
The upstream kernel currently has no core rail suspend support (LP0/SC7)
on Tegras - in general the downstream kernel (used e.g. in L4T) is the
reference that has the most functionality on Tegra.
IIRC the MMC subsystem and Tegra MMC driver between upstream and
downstream are currently quite
On 29.11.2017 14:18, Dmitry Osipenko wrote:
On 29.11.2017 12:10, Mikko Perttunen wrote:
On 12.11.2017 13:23, Dmitry Osipenko wrote:
On 11.11.2017 00:15, Dmitry Osipenko wrote:
On 07.11.2017 18:29, Dmitry Osipenko wrote:
On 07.11.2017 16:11, Mikko Perttunen wrote:
On 05.11.2017 19:14, Dmitry
On 11/29/2017 06:00 PM, Joshua Abraham wrote:
Signed-off-by: Joshua Abraham
This patch fixes the issue:
CHECK: usleep_range is preferred over udelay; see
Documentation/timers/timers-howto.txt
---
drivers/staging/nvec/nvec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 05.11.2017 18:46, Dmitry Osipenko wrote:
On 05.11.2017 14:01, Mikko Perttunen wrote:
>> ...
+static int mlock_id_for_class(unsigned int class)
+{
+#if HOST1X_HW >= 6
+ switch (class)
+ {
+ case HOST1X_CLASS_HOST1X:
+ return 0;
+ case HOST1X_
On 05.11.2017 19:43, Dmitry Osipenko wrote:
On 05.11.2017 14:01, Mikko Perttunen wrote:
In the traditional channel allocation model, a single hardware channel
was allocated for each client. This is simple from an implementation
perspective but prevents use of hardware scheduling.
This patch
On 05.11.2017 19:14, Dmitry Osipenko wrote:
On 05.11.2017 14:01, Mikko Perttunen wrote:
Add an option to host1x_channel_request to interruptibly wait for a
free channel. This allows IOCTLs that acquire a channel to block
the userspace.
Wouldn't it be more optimal to request channel and block
On 1/17/21 1:20 PM, Wolfram Sang wrote:
On Tue, Jan 12, 2021 at 12:22:25PM +0200, Mikko Perttunen wrote:
In order to not to start returning errors when new I2C_M flags are
added, change behavior to just ignore all flags that we don't know
about. This includes the I2C_M_DMA_SAFE flag
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.
Mikko
On 9/16/20 10:06 PM, Jon Hunter wrote:
On 16/09/2020
On 9/21/20 4:10 PM, Qinglang Miao wrote:
Simplify the return expression.
Signed-off-by: Qinglang Miao
---
drivers/gpu/host1x/cdma.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/gpu/host1x/cdma.c b/drivers/gpu/host1x/cdma.c
index e8d3fda91..08a0f9e10
On 12/17/20 8:06 PM, Dmitry Osipenko wrote:
Add suspend/resume and generic power domain support to the Host1x driver.
This is required for enabling system-wide DVFS and supporting dynamic
power management using a generic power domain.
Tested-by: Peter Geis
Tested-by: Nicolas Chauvet
This nas been NAK'd before as harder to read than the current way.
Thanks,
Mikko
On 01/23/2018 10:29 PM, Christopher Díaz Riveros wrote:
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
This issue was detected by using the Coccinelle software.
Signed-off-by: Christopher Díaz Riveros
as of_find_node_by_name() drops a reference to its first argument.
Fixes: 3568df3d31d6 ("soc: tegra: Add thermal reset (thermtrip) support to PMC")
Cc: stable # 4.0
Cc: Mikko Perttunen
Signed-off-by: Johan Hovold
---
drivers/soc/tegra/pmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Enable Tegra186 CPU frequency scaling support by default.
Signed-off-by: Mikko Perttunen
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6356c6da34ea..42711031a72d 100644
--- a/arch/arm64
Enable Tegra BPMP thermal sensor support by default, built as a module.
Signed-off-by: Mikko Perttunen
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 42711031a72d..d0f05da8baf9 100644
On 02/10/2018 12:49 AM, Rob Herring wrote:
On Tue, Feb 06, 2018 at 09:22:34AM +0200, Mikko Perttunen wrote:
Add compatibility strings for supported but undocumented Tegra chips
(Tegra114/124/132/210/186/194) and reference boards.
Signed-off-by: Mikko Perttunen
---
Notes:
v2:
- add
On 01/16/2018 12:06 AM, Lyude Paul wrote:
It's here! After a lot of investigation, rewrites, and traces, I present
the patch series to implement all known levels of clockgating for
Kepler1 and Kepler2 GPUs.
Starting with Fermi GPUs (this is probably present on earlier GPUs as
well, but with a
Reviewed-by: Mikko Perttunen
On 01/27/2018 04:28 PM, Julia Lawall wrote:
Check the variable that was most recently initialized.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
//
@@
expression x, y, f, g, e, m;
statement S1,S2,S3,S4;
@@
x = f
My understanding is that Tegra186 does not have DMA coherency, but
Tegra194 does.
Mikko
On 23.7.2019 16.34, Jon Hunter wrote:
On 23/07/2019 13:51, Jose Abreu wrote:
From: Jon Hunter
Date: Jul/23/2019, 12:58:55 (UTC+00:00)
On 23/07/2019 11:49, Jose Abreu wrote:
From: Jon Hunter
Date:
On 6/26/20 1:29 PM, Sandipan Patra wrote:
Add the chip IDs for NVIDIA Tegra186, Tegra194 and Tegra234
SoC family.
families
Signed-off-by: Sandipan Patra
---
include/soc/tegra/fuse.h | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/soc/tegra/fuse.h
free_const call to __clk_put and add comments to both
functions to remind that the logic in them should be kept in sync.
Fixes: 253160a8ad06 ("clk: core: Copy connection id")
Signed-off-by: Mikko Perttunen
---
drivers/clk/clk.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers
Hi,
I'm seeing the following spew during boot with Tegra210 with the patch
"regulator: core: Link consumer with regulator driver", recently applied
to linux-next:
[1.196664] [ cut here ]
[1.201480] kobject: '(null)' ((ptrval)): is not initialized,
yet
hsp, which is backwards compatible with tegra186.
Signed-off-by: Mikko Perttunen
---
Notes:
v2:
- Edited commit message to not say that doorbell interrupts cannot be
routed to shared interrupts.
- Added tegra194 compatibility string.
Documentation/devicetree/bindings/mailbox/nvidi
ed on the Tegra194 P2972 board.
Mikko Perttunen (8):
dt-bindings: tegra186-hsp: Add shared interrupts
dt-bindings: serial: Add bindings for nvidia,tegra194-tcu
mailbox: Add transmit done by blocking option
mailbox: tegra-hsp: Refactor in preparation of mailboxes
mailbox: tegra-hsp: Ad
The HSP driver is currently in many places written with the assumption
of only supporting doorbells. Prepare for the addition of shared
mailbox support by removing these assumptions and cleaning up the code.
Signed-off-by: Mikko Perttunen
---
Notes:
v2:
- Moved fixes for some style
The Tegra Combined UART is the proper primary serial port on P2888,
so use it.
Signed-off-by: Mikko Perttunen
Acked-by: Jon Hunter
---
Notes:
v2:
- Added Jon's Acked-by.
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Tegra HSP blocks that are already controlled by the Tegra
HSP mailbox driver.
Signed-off-by: Mikko Perttunen
---
Notes:
v2:
- Removed (void) casts for unused variables.
- Changed the uart_set_options() call to be on one line, even if its
over 80 characters.
- Added defines
Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
send_data function of the mailbox driver is expected to block until
the message has been sent. The new option is used with the Tegra
Combined UART driver to minimize unnecessary overhead when transmitting
data.
Signed-off-by: Mikko
.
The initial use for the mailboxes is the Tegra Combined UART. For this
purpose, we use interrupts to receive data, and spinning to wait for
the transmit mailbox to be emptied to minimize unnecessary overhead.
Signed-off-by: Mikko Perttunen
---
Notes:
v2:
- Added defines for some register fields
but is compatible to tegra186-hsp.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 34 +---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index
Add bindings for the Tegra Combined UART device used to talk to the
UART console on Tegra194 systems.
Signed-off-by: Mikko Perttunen
Reviewed-by: Rob Herring
---
Notes:
v2:
- Added Rob's Reviewed-by.
.../bindings/serial/nvidia,tegra194-tcu.txt| 35 ++
1
On 22.05.2018 18:15, Jon Hunter wrote:
On 08/05/18 12:43, Mikko Perttunen wrote:
Non-doorbell interrupts are routed through "shared interrupts". These
interrupts can be mapped to various internal interrupt lines. Add
interrupt properties for shared interrupts to the tegra186-hsp d
On 22.05.2018 18:36, Jon Hunter wrote:
On 08/05/18 12:43, Mikko Perttunen wrote:
The HSP driver is currently in many places written with the assumption
of only supporting doorbells. Prepare for the addition of shared
mailbox support by removing these assumptions and cleaning up the code
to of_xlate to skip any NULL
clocks.
Signed-off-by: Mikko Perttunen
---
drivers/clk/tegra/clk-bpmp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index a896692b74ec..01dada561c10 100644
--- a/drivers/clk/tegra
HSP interrupts can be routed through exposed "shared interrupts". These
interrupts can be mapped to various internal interrupt lines. Add
interrupt properties for shared interrupts to the tegra186-hsp device
tree bindings.
Signed-off-by: Mikko Perttunen
Acked-by: Jon Hunter
Review
Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
send_data function of the mailbox driver is expected to block until
the message has been sent. The new option is used with the Tegra
Combined UART driver to minimize unnecessary overhead when transmitting
data.
Signed-off-by: Mikko
but is compatible to tegra186-hsp.
Signed-off-by: Mikko Perttunen
Acked-by: Jon Hunter
---
Notes:
v3:
- Added Jon's Acked-by.
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 34 +---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia
The Tegra Combined UART is the proper primary serial port on P2888,
so use it.
Signed-off-by: Mikko Perttunen
Acked-by: Jon Hunter
---
Notes:
v2:
- Added Jon's Acked-by.
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The HSP driver is currently in many places written with the assumption
of only supporting doorbells. Prepare for the addition of shared
mailbox support by removing these assumptions and cleaning up the code.
Signed-off-by: Mikko Perttunen
Reviewed-by: Jon Hunter
---
Notes:
v2:
- Moved
.
The initial use for the mailboxes is the Tegra Combined UART. For this
purpose, we use interrupts to receive data, and spinning to wait for
the transmit mailbox to be emptied to minimize unnecessary overhead.
Signed-off-by: Mikko Perttunen
Reviewed-by: Jon Hunter
---
Notes:
v3:
- Added define
Tegra HSP blocks that are already controlled by the Tegra
HSP mailbox driver.
Signed-off-by: Mikko Perttunen
---
Notes:
v2:
- Removed (void) casts for unused variables.
- Changed the uart_set_options() call to be on one line, even if its
over 80 characters.
- Added defines
Add bindings for the Tegra Combined UART device used to talk to the
UART console on Tegra194 systems.
Signed-off-by: Mikko Perttunen
Reviewed-by: Rob Herring
Acked-by: Jon Hunter
---
Notes:
v2:
- Added Rob's Reviewed-by.
v3:
- Added Jon's Acked-by.
.../bindings/serial
ption to the mailbox
framework.
* patches 4 and 5 add support for the "shared mailbox" primitive
to the Tegra HSP driver.
* patch 6 adds the TCU driver itself
* patches 7 and 8 do the necessary device tree changes.
The series has been tested on the Tegra194 P2972 board.
Mikko Perttunen (8):
On 02.07.2018 16:18, Thierry Reding wrote:
On Mon, Jul 02, 2018 at 02:40:31PM +0300, Mikko Perttunen wrote:
The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
multiplexing multiple "virtual UARTs" into a single hardware serial
port. The TCU is the primary s
On 02.07.2018 16:47, Thierry Reding wrote:
On Mon, Jul 02, 2018 at 04:30:07PM +0300, Mikko Perttunen wrote:
On 02.07.2018 16:18, Thierry Reding wrote:
On Mon, Jul 02, 2018 at 02:40:31PM +0300, Mikko Perttunen wrote:
The Tegra Combined UART (TCU) is a mailbox-based mechanism that allows
Thanks!
Reviewed-by: Mikko Perttunen
On 17.07.2018 13:49, Corentin Labbe wrote:
Since ahci_platform_put_resources() use target_pwrs after "devm_" freed
it, we cannot use devm_kcalloc for allocating target_pwrs.
This reverts commit bd0038b1b4f499d814d8f33a55b1df5ea6cf3b85.
Reported
On 21/09/2018 19.25, Thierry Reding wrote:
...
+ /* route wake to tier 2 (XXX conditionally enable this) */
+ value = readl(pmc->wake + WAKE_AOWAKE_TIER2_CTRL);
+ writel(0x1, pmc->wake + WAKE_AOWAKE_TIER2_CTRL);
This doesn't seem right
Cheers,
Mikko
On 21/09/2018 19.25, Thierry Reding wrote:
From: Thierry Reding
Tegra186 and later have some top-level controls for wake events in the
power management controller (PMC). In order to enable the system to wake
up from low power states, additional registers in the PMC need to be
programmed. Add a
On 08/03/2018 03:54 PM, Jassi Brar wrote:
On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen wrote:
Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
send_data function of the mailbox driver is expected to block until
the message has been sent. The new option is used with the Tegra
One potential issue is with host1x clients where userspace processes can
submit jobs with invalid memory accesses (addresses not mapped to
IOMMU). If when such a failure happens, we disable the DMA for the whole
host1x client, unrelated userspace processes may see failures even
though there is
On 04.08.2018 13:45, Mikko Perttunen wrote:
On 08/03/2018 03:54 PM, Jassi Brar wrote:
On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen
wrote:
Add a new TXDONE option, TXDONE_BY_BLOCK. With this option, the
send_data function of the mailbox driver is expected to block until
the message has
On 08/08/2018 05:10 PM, Jassi Brar wrote:
On Wed, Aug 8, 2018 at 5:08 PM, Mikko Perttunen wrote:
On 04.08.2018 13:45, Mikko Perttunen wrote:
On 08/03/2018 03:54 PM, Jassi Brar wrote:
On Mon, Jul 2, 2018 at 5:10 PM, Mikko Perttunen
wrote:
Add a new TXDONE option, TXDONE_BY_BLOCK
On 08/08/2018 05:39 PM, Jassi Brar wrote:
On Wed, Aug 8, 2018 at 8:04 PM, Mikko Perttunen wrote:
On 08/08/2018 05:10 PM, Jassi Brar wrote:
On Wed, Aug 8, 2018 at 5:08 PM, Mikko Perttunen wrote:
On 04.08.2018 13:45, Mikko Perttunen wrote:
On 08/03/2018 03:54 PM, Jassi Brar wrote
ic. I assume this gets printed through the earlycon
as it's printing out correctly.
Thanks,
Mikko
On 08.08.2018 17:46, Mikko Perttunen wrote:
On 08/08/2018 05:39 PM, Jassi Brar wrote:
On Wed, Aug 8, 2018 at 8:04 PM, Mikko Perttunen wrote:
On 08/08/2018 05:10 PM, Jassi Brar wrote:
On Wed,
On 4.3.2019 21.53, Arnd Bergmann wrote:
drivers/gpu/host1x/hw/channel_hw.c: In function 'host1x_channel_set_streamid':
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit declaration of
function 'dev_iommu_fwspec_get'; did you mean 'iommu_fwspec_free'?
^~
cc1: all warnings being treated as errors
As Mikko explains, we should program SMMU bypass (0x7f) if that
happens.
Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
Suggested-by: Mikko Perttunen
Signed-off-by: Arnd Bergmann
v2: fall back to 0x7f sid
---
On 20.07.2018 15:45, Aapo Vienamo wrote:
Parse the pinctrl states from the device tree and implement pad voltage
state reconfiguration in the mmc start_signal_voltage_switch() callback.
This is done in the mmc callback because the order of pad
reconfiguration and sdhci voltage switch depend on
I would maybe say "dt-bindings: mmc: tegra: Add pad voltage control
properties" or similar for the subject - the current kind of looks like
the SDHCI controller is a pinctrl device :)
Reviewed-by: Mikko Perttunen
On 20.07.2018 15:45, Aapo Vienamo wrote:
Document the pinctrl bin
Reviewed-by: Mikko Perttunen
On 20.07.2018 15:45, Aapo Vienamo wrote:
Add pad voltage configuration nodes for sdmmc pads with configurable
voltages on Tegra210.
Signed-off-by: Aapo Vienamo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 27 +++
1 file changed, 27
Reviewed-by: Mikko Perttunen
On 20.07.2018 15:45, Aapo Vienamo wrote:
Add pad voltage configuration nodes for sdmmc pads with configurable
voltages on Tegra186.
Signed-off-by: Aapo Vienamo
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 40
1 file changed
Reviewed-by: Mikko Perttunen
On 20.07.2018 15:45, Aapo Vienamo wrote:
Set regulator-min-microvolt property of ldo2 to 1.8 V in
tegra210-p2180.dtsi. ldo2 is used by the sdmmc1 SDHCI controller and its
voltage needs to be adjusted down to 1.8 V to support faster signaling
modes. It appears
Technically this shouldn't be required since VDD_1V8 is always on
anyway, but I think it's nicer to specify regulators anyway, so +1!
Reviewed-by: Mikko Perttunen
On 20.07.2018 15:45, Aapo Vienamo wrote:
On p2180 sdmmc4 is powered from a fixed 1.8 V regulator.
Signed-off-by: Aapo Vienamo
Looks like patch 6 will probably cause tegra-sdhci to start advertising
faster modes (see " if (!IS_ERR(host->mmc->supply.vqmmc))" in
sdhci-tegra.c). With that patch and this, will the SDHCI core start to
try putting us into these higher modes? Clearly that won't work yet
before the upcoming
On 24.07.2018 17:29, Aapo Vienamo wrote:
Implement polling with 10 ms timeout for automatic pad drive strength
calibration.
Signed-off-by: Aapo Vienamo
---
drivers/mmc/host/sdhci-tegra.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git
On 24.07.2018 17:34, Aapo Vienamo wrote:
Configure the voltage reference used by the automatic pad drive strength
calibration procedure. The value is a magic number from the TRM.
Signed-off-by: Aapo Vienamo
---
drivers/mmc/host/sdhci-tegra.c | 14 --
1 file changed, 12
Reviewed-by: Mikko Perttunen
On 24.07.2018 17:34, Aapo Vienamo wrote:
Automatic pad drive strength calibration is performed on a separate pad
identical to the ones used for driving the actual bus. Power on the
calibration pad during the calibration procedure and power it off
afterwards to save
On 24.07.2018 17:34, Aapo Vienamo wrote:
Disable the card clock during automatic pad drive strength calibration
and re-enable it aftewards.
s/aftewards/afterwards/.
Signed-off-by: Aapo Vienamo
---
drivers/mmc/host/sdhci-tegra.c | 27 +++
1 file changed, 27
On 24.07.2018 17:34, Aapo Vienamo wrote:
Add bindings documentation for pad pull up and pull down offset values to be
programmed before executing automatic pad drive strength calibration.
Signed-off-by: Aapo Vienamo
---
.../bindings/mmc/nvidia,tegra20-sdhci.txt | 32
On 24.07.2018 17:34, Aapo Vienamo wrote:
Parse the pad drive strength calibration offsets from the device tree.
Program the calibration offsets in accordance with the current signaling
mode.
Signed-off-by: Aapo Vienamo
---
drivers/mmc/host/sdhci-tegra.c | 147
On 24.07.2018 17:34, Aapo Vienamo wrote:
Run the automatic pad calibration after voltage switching if
tegra_host->pad_calib_required is set.
Signed-off-by: Aapo Vienamo
---
drivers/mmc/host/sdhci-tegra.c | 5 +
1 file changed, 5 insertions(+)
diff --git
integer field instead of phandle for thermtrip i2c controller id
- Rearrange pmc.c using a forward declaration to prevent huge patch
Mikko Perttunen (3):
of: Add descriptions of thermtrip properties to Tegra PMC bindings
ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device tree
ARM
From: Mikko Perttunen
This adds the required information to reset the board during an overheating
situation to the Jetson TK1 device tree. The thermal reset is handled by the
PMC by sending an I2C message to the PMIC. The entries specify the I2C
message to be sent.
Signed-off-by: Mikko
From: Mikko Perttunen
Hardware-triggered thermal reset requires configuring the I2C
reset procedure. This configuration is read from the device tree,
so document the relevant properties in the binding documentation.
Signed-off-by: Mikko Perttunen
---
.../bindings/arm/tegra/nvidia,tegra20
From: Mikko Perttunen
This adds a device tree controlled option to enable PMC-based
thermal reset in overheating situations. Thermtrip is supported on
Tegra30, Tegra114 and Tegra124. The thermal reset only works when
the thermal sensors are calibrated, so a soctherm driver is also
required
On 01/06/2015 05:14 PM, Thierry Reding wrote:
On Tue, Jan 06, 2015 at 12:52:58PM +0200, Mikko Perttunen wrote:
From: Mikko Perttunen
This adds a device tree controlled option to enable PMC-based
thermal reset in overheating situations. Thermtrip is supported on
Tegra30, Tegra114 and Tegra124
From: Tuomas Tynkkynen
The cpufreq driver for Tegra124 will be a different one than the old
Tegra20 cpufreq driver (tegra-cpufreq), which does not use the device
tree.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
.../bindings/cpufreq/tegra124-cpufreq.txt | 44
From: Tuomas Tynkkynen
The Tegra124 cpufreq driver depends on CONFIG_CPUFREQ_DT, so
enable it to get the Tegra driver to build by default.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
arch/arm/configs/tegra_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Tuomas Tynkkynen
Save and restore this register since the LP1 restore assembly routines
fiddle with it. Otherwise the CPU would keep running on PLLX after
resume from suspend even when DFLL was the original clocksource.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
block will complete.
Thanks to Aleksandr Frid for identifying this and
saving hours of debugging time.
Signed-off-by: Paul Walmsley
[ttynkkynen: ported to tegra124 from tegra114]
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
drivers/clk/tegra/clk-tegra124.c | 47
-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
.../bindings/clock/nvidia,tegra124-dfll.txt| 69 ++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
diff --git a/Documentation/devicetree
From: Tuomas Tynkkynen
Add the board-specific properties of the DFLL for the Jetson TK1 board.
On this board, the DFLL will take control of the sd0 regulator on the
on-board AS3722 PMIC.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
arch/arm/boot/dts/tegra124-jetson-tk1
From: Tuomas Tynkkynen
The DFLL clocksource is a separate IP block from the usual
clock-and-reset controller, so it gets its own device tree node.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
arch/arm/boot/dts/tegra124.dtsi | 22 ++
1 file changed
-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
drivers/clk/tegra/Makefile | 2 +
drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 165 +
2 files changed, 167 insertions(+)
create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
diff
From: Tuomas Tynkkynen
The DFLL clocksource was missing from the list of possible parents for
the fast CPU cluster. Add it to the list.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
drivers/clk/tegra/clk-tegra-super-gen4.c | 4 +++-
1 file changed, 3 insertions(+), 1
Specify the CPU voltage regulator for the cpufreq driver.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts
Signed-off-by: Mikko Perttunen
---
drivers/clk/tegra/clk-dfll.c | 666 ++-
1 file changed, 663 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index 6f46943..018489b 100644
--- a/drivers/clk/tegra/clk
From: Tuomas Tynkkynen
The Tegra124 will use a different driver for frequency scaling, so
rename the old driver (which handles only Tegra20) appropriately.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
drivers/cpufreq/Kconfig.arm| 6
driver
for all the cpufreq operations.
This driver also relies on the DFLL driver to fill the OPP table for the
CPU0 device, so that the cpufreq-dt driver knows what frequencies to
use.
Signed-off-by: Tuomas Tynkkynen
Acked-by: Viresh Kumar
Signed-off-by: Mikko Perttunen
---
drivers/cpufreq
-off-by: Paul Walmsley
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
drivers/clk/tegra/Makefile |1 +
drivers/clk/tegra/clk-dfll.c | 1090 ++
drivers/clk/tegra/clk-dfll.h | 55 +++
3 files changed, 1146 insertions(+)
create mode
on an per-chip basis.
Add utility functions to parse the Tegra-specific tables and export the
voltage-frequency pairs to the generic OPP framework for other drivers
to use.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
arch/arm/mach-tegra/Kconfig | 1 +
drivers/clk/tegra/cvb.c
From: Tuomas Tynkkynen
The Tegra124 cpufreq driver relies on certain clocks being present
in the /cpus/cpu@0 node.
Signed-off-by: Tuomas Tynkkynen
Signed-off-by: Mikko Perttunen
---
arch/arm/boot/dts/tegra124.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts
this to
the Venice2 should be simple, though do note that it does not have
active cooling.
Thanks,
Tuomas
Mikko Perttunen (1):
ARM: tegra: Add CPU regulator to the Jetson TK1 device tree
Paul Walmsley (1):
clk: tegra: Add DFLL DVCO reset control for Tegra124
Tuomas Tynkkynen (14):
clk: tegra: Add
On 11/17/2014 01:43 PM, Thierry Reding wrote:
On Fri, Nov 14, 2014 at 12:47:33PM +0200, Mikko Perttunen wrote:
Tested-by: Mikko Perttunen
One potential issue I can see is that if the cpufreq driver fails to probe
then you'll never get the thermal driver either. For example, Tegra124
currently
901 - 1000 of 1248 matches
Mail list logo
