On 7.4.2021 16.29, Hans Verkuil wrote:
On 02/04/2021 09:40, Bixuan Cui wrote:
Fix the error:
drivers/staging/media/tegra-video/vi.c:1180:4:
error: implicit declaration of function 'host1x_syncpt_free'
[-Werror,-Wimplicit-function-declaration]
Against what tree is this being built? The
On 2/16/21 2:47 PM, Robin Murphy wrote:
Hi Mikko,
On 2021-02-08 16:38, Mikko Perttunen wrote:
To allow for more customized device tree bindings that point to IOMMUs,
allow manual specification of iommu_spec to of_dma_configure.
The initial use case for this is with Host1x, where the driver
On 2/15/21 2:09 PM, Thierry Reding wrote:
On Mon, Feb 15, 2021 at 12:35:31PM +0200, Mikko Perttunen wrote:
On 2/15/21 12:25 PM, Thierry Reding wrote:
On Sat, Feb 13, 2021 at 01:58:24PM +0200, Mikko Perttunen wrote:
Add an earlycon driver for platforms with TCU, namely Tegra194.
The driver
On 2/15/21 12:25 PM, Thierry Reding wrote:
On Sat, Feb 13, 2021 at 01:58:24PM +0200, Mikko Perttunen wrote:
Add an earlycon driver for platforms with TCU, namely Tegra194.
The driver is compatible with boot parameters passed by NVIDIA
boot chains.
I'm not sure I understand the latter part
Add an earlycon driver for platforms with TCU, namely Tegra194.
The driver is compatible with boot parameters passed by NVIDIA
boot chains.
Signed-off-by: Mikko Perttunen
---
drivers/tty/serial/Kconfig | 12 +
drivers/tty/serial/Makefile | 1 +
drivers/tty/serial
On Tegra194, due to both BPMP and TCU using mailboxes, we get a
lockdep spew at boot. Both are using different instances of HSP,
so this is harmless. As such give each HSP instance a different
lockdep class.
Signed-off-by: Mikko Perttunen
---
drivers/mailbox/tegra-hsp.c | 15 +++
1
On 2/8/21 6:38 PM, Mikko Perttunen wrote:
...
-static int of_iommu_xlate(struct device *dev,
- struct of_phandle_args *iommu_spec)
+int of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
...
+EXPORT_SYMBOL_GPL(of_iommu_xlate);
These two chunks
erted them to YAML) yet, so this
is RFC for now.
Thanks!
Mikko
Mikko Perttunen (8):
of/device: Allow specifying a custom iommu_spec to of_dma_configure
gpu: host1x: Add context bus
gpu: host1x: Add context device management code
gpu: host1x: Program context stream ID on submission
iomm
that might do DMA using the new stream ID.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/hw/channel_hw.c| 52 +--
drivers/gpu/host1x/hw/host1x06_hardware.h | 10 +
drivers/gpu/host1x/hw/host1x07_hardware.h | 10 +
include/linux/host1x.h| 4
. These contexts don't correspond to
platform devices and are instead attached to dummy devices on a custom
software bus.
Signed-off-by: Mikko Perttunen
---
drivers/iommu/of_iommu.c | 12
drivers/of/device.c | 9 +
include/linux/of_device.h | 34
Add code to register context devices from device tree, allocate them
out and manage their refcounts.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/host1x/Makefile | 1 +
drivers/gpu/host1x/context.c | 161 +++
drivers/gpu/host1x/context.h | 27
Implement the get_streamid_offset required for supporting context
isolation. Since old firmware cannot support context isolation
without hacks that we don't want to implement, check the firmware
binary to see if context isolation should be enabled.
Signed-off-by: Mikko Perttunen
---
drivers/gpu
-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index c567aa65418b..25a8cb1a97a6 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186
For engines that support context isolation, allocate a context when
opening a channel, and set up stream ID offset and context fields
when submitting a job.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.h | 1 +
drivers/gpu/drm/tegra/uapi.h| 1 +
drivers/gpu/drm
Set itself as the IOMMU for the host1x context device bus, containing
"dummy" devices used for Host1x context isolation.
Signed-off-by: Mikko Perttunen
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/iommu/arm/ar
Signed-off-by: Mikko Perttunen
---
drivers/gpu/Makefile | 3 +--
drivers/gpu/host1x/Kconfig | 5 +
drivers/gpu/host1x/Makefile| 1 +
drivers/gpu/host1x/context_bus.c | 31 ++
include/linux/host1x_context_bus.h | 15 ++
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
On 1/12/21 12:26 PM, Wolfram Sang wrote:
I wonder if bailing out on an unknown flag shouldn't be revisited in
general? I mean this will happen again when a new I2C_M_* flag is
introduced.
If it's guaranteed that any new flags are optional to handle by the driver,
than that is certainly
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 that already exists.
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Mikko Perttunen
---
v3:
- Ignore all unknown
On 1/11/21 11:42 PM, Wolfram Sang wrote:
On Mon, Jan 11, 2021 at 05:58:16PM +0200, Mikko Perttunen wrote:
From: Muhammed Fazal
Ignore I2C_M_DMA_SAFE flag as it does not make a difference
for bpmp-i2c, but causes -EINVAL to be returned for valid
transactions.
I wonder if bailing out
mentioned
in the Fixes tag.
Fixes: ede2299f7101 ("i2c: tegra: Support atomic transfers")
Cc: sta...@vger.kernel.org
Signed-off-by: Mikko Perttunen
---
v2:
* Use in_irq() instead of passing a flag from the ISR.
Thanks to Dmitry for the suggestion.
* Update commit message.
---
drivers/i2c/
From: Muhammed Fazal
Ignore I2C_M_DMA_SAFE flag as it does not make a difference
for bpmp-i2c, but causes -EINVAL to be returned for valid
transactions.
Signed-off-by: Muhammed Fazal
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Mikko Perttunen
---
v2:
- Remove unnecessary check
On 1/11/21 5:14 PM, Dmitry Osipenko wrote:
11.01.2021 16:55, Mikko Perttunen пишет:
Upon a communication error, the interrupt handler can call
tegra_i2c_disable_packet_mode. This causes a sleeping poll to happen
unless the current transaction was marked atomic. Since
On 1/11/21 5:04 PM, Ben Dooks wrote:
On 11/01/2021 14:27, Mikko Perttunen wrote:
From: Muhammed Fazal
Ignore I2C_M_DMA_SAFE flag as it does not make a difference
for bpmp-i2c, but causes -EINVAL to be returned for valid
transactions.
Signed-off-by: Muhammed Fazal
Cc: sta...@vger.kernel.org
Agreed that this is possibly not optimal, but this patch simply returns
the behavior to what it was before "i2c: tegra: Support atomic
transfers", fixing the overt issue.
Design fixes can be considered later, in a non-stable patch.
Mikko
On 1/11/21 4:31 PM, David Laight wrote:
F
From: Muhammed Fazal
Ignore I2C_M_DMA_SAFE flag as it does not make a difference
for bpmp-i2c, but causes -EINVAL to be returned for valid
transactions.
Signed-off-by: Muhammed Fazal
Cc: sta...@vger.kernel.org # v4.19+
Signed-off-by: Mikko Perttunen
---
This fixes failures seen with PMIC
: ede2299f7101 ("i2c: tegra: Support atomic transfers")
Cc: sta...@vger.kernel.org
Signed-off-by: Mikko Perttunen
---
This fixes constant spew for me while HDMI is connected to a
powered off television.
drivers/i2c/busses/i2c-tegra.c | 16
1 file changed, 8 insert
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
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
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 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
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:
^~
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 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'?
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 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 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:
...
+ /* 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
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,
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 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
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
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: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 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 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
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
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 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
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
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
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
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:
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:
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:
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:
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:
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
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
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:
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
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
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: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
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
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
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
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
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
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
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:
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:
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 Tegra210.
Signed-off-by: Aapo Vienamo
---
arch/arm64/boot/dts/nvidia/tegra210.dtsi | 27 +++
1 file changed, 27
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
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
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
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
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
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
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
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
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
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
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
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
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: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
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):
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):
.
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
.
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
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 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 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 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
1 - 100 of 1248 matches
Mail list logo
