On 04.05.2018 13:40, Thierry Reding wrote:
> On Fri, May 04, 2018 at 01:55:37AM +0300, Dmitry Osipenko wrote:
>> Commit 4c9a27a6c66d ("ARM: tegra: Fix ULPI regression on Tegra20") changed
>> "ulpi-link" clock from CDEV2 to PLL_P_OUT4. Turned out that PLL_P_O
On 04.05.2018 13:45, Thierry Reding wrote:
> On Fri, May 04, 2018 at 02:47:19AM +0300, Dmitry Osipenko wrote:
>> Remove unneeded iommu_group_get() and add missing iommu_group_put(),
>> correcting IOMMU group refcount. This is a minor correction / cleanup that
>> doesn't really
On 04.05.2018 15:15, Thierry Reding wrote:
> On Fri, May 04, 2018 at 03:08:43AM +0300, Dmitry Osipenko wrote:
>> Older Tegra's do not support planes z position handling in hardware,
>> but HW provides knobs for zPos implementation in software.
>>
>> Signed-off-by: Dmitry
On 04.05.2018 16:33, Marcel Ziswiler wrote:
> Hi Dmitry
>
> On Fri, 2018-05-04 at 01:55 +0300, Dmitry Osipenko wrote:
>> Hello,
>>
>> This series of patches fixes ULPI USB on Tegra20. The original
>> problem
>> was reported by Marcel Ziswiler, he found th
Older Tegra's do not support planes z position handling in hardware,
but HW provides knobs for zPos implementation in software.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/dc.c| 134 ---
drivers/gpu/drm/tegra/plane.c
Older Tegra's support blending. Rename SoC info entry supports_blending
to has_legacy_blending to eliminate confusion.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/dc.c | 20 ++--
drivers/gpu/drm/tegra/dc.h | 2 +-
2 files changed, 11 inse
Hi,
This series improves DRM plane support by supporting zPos on older Tegra's
and enabling plane scaling filters (up to Tegra210).
Changelog:
v2:
- Addressed v1 review comments.
Dmitry Osipenko (3):
drm/tegra: dc: Enable plane scaling filters
drm/tegra: plane: Implement zPos plane
Currently resized plane produces a "pixelated" image which doesn't look
nice, especially in a case of a video overlay. Enable scaling filters that
significantly improve image quality of a scaled overlay.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm
On 18.05.2018 04:58, Viresh Kumar wrote:
> On 17-05-18, 21:00, Dmitry Osipenko wrote:
>> Remove unused/unneeded headers and sort them in the alphabet order.
>>
>> Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
>> ---
>> drivers/cpufreq/tegra20-cpufreq.c
On 18.05.2018 05:07, Viresh Kumar wrote:
> On 17-05-18, 21:00, Dmitry Osipenko wrote:
>> -static int __init tegra_cpufreq_init(void)
>> +static int tegra20_cpufreq_probe(struct platform_device *pdev)
>> {
>> +struct tegra20_cpufreq_
On 18.05.2018 12:07, Thierry Reding wrote:
> On Thu, May 17, 2018 at 09:00:55PM +0300, Dmitry Osipenko wrote:
>> Currently tegra20-cpufreq kernel module isn't getting autoloaded because
>> there is no device associated with the module, this is one of two patches
>> tha
On 18.05.2018 12:13, Thierry Reding wrote:
> On Thu, May 17, 2018 at 09:00:56PM +0300, Dmitry Osipenko wrote:
>> Tegra20-cpufreq driver require a platform device in order to be loaded,
>> instantiate a simple platform device for the driver during of the machines
>>
On 18.05.2018 10:30, Rafael J. Wysocki wrote:
> On Thursday, May 17, 2018 8:00:45 PM CEST Dmitry Osipenko wrote:
>> Hello,
>>
>> Recently Peter Geis (who is working on Tegra30 cpufreq driver) asked me how
>> tegra20-cpufreq driver is getting loaded. After taking a lo
On 18.05.2018 13:39, Thierry Reding wrote:
> On Tue, May 08, 2018 at 07:26:04PM +0300, Dmitry Osipenko wrote:
>> Muxing of pins MCLK1/2 determine the muxing of the corresponding clocks.
>> Make pinctrl driver to provide clock muxes for the CDEV1/2 pingroups, so
>> that main
On 16.04.2018 21:21, Stefan Agner wrote:
> On 16.04.2018 18:08, Stephen Warren wrote:
>> On 04/16/2018 09:56 AM, Stefan Agner wrote:
>>> On 27.03.2018 14:16, Dmitry Osipenko wrote:
>>>> On 27.03.2018 14:54, Robin Murphy wrote:
>>>>> On 26/03/18 22:20, D
), it is work-in-progress for now.
This patchset is partially based on the work done by Michał Mirosław [0].
Please review, thanks.
[0] https://www.spinics.net/lists/linux-tegra/msg30368.html
Dmitry Osipenko (5):
ARM: trusted_foundations: Implement L2 cache initialization callback
ARM
Hook up Memory Client reset of the Video Decoder to the decoders DT node.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/boot/dts/tegra30.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra3
Hook up Memory Client reset of the Video Decoder to the decoders DT node.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/boot/dts/tegra20.dtsi | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/t
CPU always jumps into the reset handler in ARM-mode from the Trusted
Foundations firmware, hence make CPU to always jump into kernel in
ARM-mode regardless of the firmware presence to support Thumb2 kernel + TF
case.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/mach-tegra
CPU isn't allowed to touch secure registers while running under secure
monitor. Hence skip applying CPU erratas in the reset handler if Trusted
Foundations firmware presents.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/mach-tegra/reset-handler.
Add a helper that provides information about whether Trusted Foundations
firmware operations have been registered.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/firmware/trusted_foundations.c| 5 +
arch/arm/include/asm/trusted_foundations.h | 7 +++
2 files c
On Tegra20/30 L2 cache must be initialized using firmware call if CPU
is running in insecure mode. Initialize L2 cache and setup the outer-cache
callbacks in early boot using the firmware API.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/mach-tegra/tegra.
Implement L2 cache initialization firmware callback that should be invoked
early in boot to enable cache HW.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/firmware/trusted_foundations.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/ar
On 20.05.2018 17:08, Russell King - ARM Linux wrote:
> On Sun, May 20, 2018 at 01:15:38PM +0300, Dmitry Osipenko wrote:
>> Implement L2 cache initialization firmware callback that should be invoked
>> early in boot to enable cache HW.
>>
>> Signed-off-by: Dmitry
DMA requests must be blocked before resetting VDE HW, otherwise it is
possible to get a memory corruption or a machine hang. Use the reset
control provided by the Memory Controller to block DMA before resetting
the VDE HW.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/s
On 16.05.2018 15:23, Linus Walleij wrote:
> On Fri, May 4, 2018 at 12:55 AM, Dmitry Osipenko <dig...@gmail.com> wrote:
>
>> Muxing of pins MCLK1/2 determine the muxing of the corresponding clocks.
>> Make pinctrl driver to provide clock muxes for the CDEV1/2 pingro
On 14.05.2018 21:18, Robin Murphy wrote:
> On 11/05/18 21:05, Dmitry Osipenko wrote:
>> On 11.05.2018 15:32, Robin Murphy wrote:
>>> On 08/05/18 19:16, Dmitry Osipenko wrote:
>>>> GART aperture is shared by all devices, hence there is a single IOMMU
>>>>
The EMC driver has been gone 4 years ago, since the commit a7cbe92cef27
("ARM: tegra: remove tegra EMC scaling driver"). Remove the EMC clock
usage as it does nothing. We may consider re-implementing the EMC scaling
later, probably using PM Memory Bandwidth QoS API.
Signed-off-by: Dmitr
module to be
loaded on non-Tegra20 machines, by cleaning whitespaces in the code, removing
dead EMC code and in the end by allowing tegra20-cpufreq to be built as a
loadable module.
Please review, thanks.
Dmitry Osipenko (11):
cpufreq: tegra20: Change module description
cpufreq: tegra20: Clean up
Properly put requested clocks in the module init/exit code.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 31 ++-
1 file changed, 26 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/tegra20-cpufreq.c
b/d
Remove unused/unneeded headers and sort them in the alphabet order.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/tegra20-cpufreq.c
b/drivers/cpufreq/t
Don't even try to request the clocks during of module initialization on
non-Tegra20 machines (this is the case for a multi-platform kernel) for
consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 4
1 file changed, 4 insertions(+)
Remove checking of the CPU number for consistency as it won't ever fail
unless there is a severe bug in the cpufreq core.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/cpufreq/t
Remove unneeded variable initialization solely for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/tegra20-cpufreq.c
b/drivers/cpufreq/tegra20-cpufreq.c
Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to
be built as a non-builtin kernel module.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/Kconfig.arm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/Kconfig
Remove unneeded blank line and replace whitespaces with a tab in the code
for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/cpufreq/tegra20-cpufreq.c
b/d
,
other patch will instantiate the actual platform device. And now it makes
sense to wrap cpufreq driver into a platform driver for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 116 +++---
1 file changed, 73 inse
Tegra20-cpufreq driver require a platform device in order to be loaded,
instantiate a simple platform device for the driver during of the machines
late initialization.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/mach-tegra/tegra.c | 4
1 file changed, 4 inse
Change module description to be in line with the other Tegra drivers, just
for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/tegra20-cpufreq.c
b/d
[Re-sending the review I made before of the series RESEND]
> Hello Stefan,
>
> I don't have expertise to review the actual NAND-related driver logic, so I
> only
> reviewed the basics. The driver code looks good to me, though I've couple
> minor
> comments.
>
> On 21.05.2018 03:16, Stefan
On 22.05.2018 15:19, Stefan Agner wrote:
> [review sent to my first patch sent off-ml, moving to ml thread]
>
> On 21.05.2018 16:05, Dmitry Osipenko wrote:
>> Hello Stefan,
>>
>> I don't have expertise to review the actual NAND-related driver logic, so I
>
On 23.05.2018 08:58, Viresh Kumar wrote:
> On 23-05-18, 00:14, Dmitry Osipenko wrote:
>> Tegra20-cpufreq driver missed enabling the CPU clocks. This results in a
>> clock-enable refcount disbalance on PLL_P <-> PLL_X reparent, causing
>> PLL_X to get disab
On 24.05.2018 07:30, Viresh Kumar wrote:
> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>> running on that PLL. Let's use PLL_C
On 23.05.2018 08:58, Viresh Kumar wrote:
> On 23-05-18, 00:14, Dmitry Osipenko wrote:
>> Tegra20-cpufreq driver missed enabling the CPU clocks. This results in a
>> clock-enable refcount disbalance on PLL_P <-> PLL_X reparent, causing
>> PLL_X to get disab
Tegra20-cpufreq driver missed enabling the CPU clocks. This results in a
clock-enable refcount disbalance on PLL_P <-> PLL_X reparent, causing
PLL_X to get disabled while it shouldn't. Fix this by enabling the clocks
on the driver probe.
Signed-off-by: Dmitry Osipenko <dig...@
On 25.05.2018 11:36, Rafael J. Wysocki wrote:
> On Fri, May 25, 2018 at 10:14 AM, Rafael J. Wysocki <raf...@kernel.org> wrote:
>> On Thu, May 24, 2018 at 2:28 PM, Dmitry Osipenko <dig...@gmail.com> wrote:
>>> On 24.05.2018 11:01, Rafael J. Wysocki wrote:
>&g
/drivers/memory/tegra/tegra20.c
> @@ -6,6 +6,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include
> #include
>
> #include "mc.h"
Yes, the spinlock header was getting included indirectly.
Reviewed-by: Dmitry Osipenko <dig...@gmail.com>
On 20.05.2018 16:48, Dmitry Osipenko wrote:
> DMA requests must be blocked before resetting VDE HW, otherwise it is
> possible to get a memory corruption or a machine hang. Use the reset
> control provided by the Memory Controller to block DMA before resetting
> the VDE HW.
>
On 24.05.2018 12:36, Rafael J. Wysocki wrote:
> On Wednesday, May 23, 2018 11:30:39 AM CEST Dmitry Osipenko wrote:
>> On 23.05.2018 08:58, Viresh Kumar wrote:
>>> On 23-05-18, 00:14, Dmitry Osipenko wrote:
>>>> Tegra20-cpufreq driver missed enabling the CPU clocks
On 24.05.2018 13:04, Peter De Schrijver wrote:
> On Wed, May 23, 2018 at 07:00:20PM +0300, Dmitry Osipenko wrote:
>> PLL_C is running at 600MHz which is significantly higher than the 216MHz
>> of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
>> running o
On 24.05.2018 11:01, Rafael J. Wysocki wrote:
> On Thu, May 24, 2018 at 7:37 AM, Dmitry Osipenko <dig...@gmail.com> wrote:
>> On 24.05.2018 07:30, Viresh Kumar wrote:
>>> On 23-05-18, 19:00, Dmitry Osipenko wrote:
>>>> PLL_C is running at 600MHz which is
On 25.05.2018 09:32, Peter De Schrijver wrote:
> On Thu, May 24, 2018 at 03:49:22PM +0300, Dmitry Osipenko wrote:
>> On 24.05.2018 13:04, Peter De Schrijver wrote:
>>> On Wed, May 23, 2018 at 07:00:20PM +0300, Dmitry Osipenko wrote:
>>>> PLL_C is running at 600MHz
,
other patch will instantiate the actual platform device. And now it makes
sense to wrap cpufreq driver into a platform driver for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
---
drivers/cpufreq/tegra20-cpu
Remove unused/unneeded headers and sort them in the alphabet order.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --g
The EMC driver has been gone 4 years ago, since the commit a7cbe92cef27
("ARM: tegra: remove tegra EMC scaling driver"). Remove the EMC clock
usage as it does nothing. We may consider re-implementing the EMC scaling
later, probably using PM Memory Bandwidth QoS API.
Signed-off-by: Dmitr
Remove unneeded variable initialization solely for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 2 +-
1 file changed,
Change module description to be in line with the other Tegra drivers, just
for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/cpufreq/tegra20-cpufre
Don't even try to request the clocks during of module initialization on
non-Tegra20 machines (this is the case for a multi-platform kernel) for
consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry
Nothing prevents Tegra20 CPUFreq module to be unloaded, hence allow it to
be built as a non-builtin kernel module.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/cpufr
Remove unneeded blank line and replace whitespaces with a tab in the code
for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/cpufreq/tegra20-cpufreq
changes for v4.18-rc1" pull request.
Dmitry Osipenko (11):
cpufreq: tegra20: Change module description
cpufreq: tegra20: Clean up whitespaces in the code
cpufreq: tegra20: Clean up included headers
cpufreq: tegra20: Remove EMC clock usage
cpufreq: tegra20: Release clocks properly
Remove unnecessary parentheses as suggested by the checkpatch script.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/tegra20-cpufreq.c
b/drivers/cpufreq/tegra20-cpu
Remove checking of the CPU number for consistency as it won't ever fail
unless there is a severe bug in the cpufreq core.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drive
Properly put requested clocks in the module init/exit code.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Viresh Kumar <viresh.ku...@linaro.org>
Acked-by: Thierry Reding <tred...@nvidia.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 31 ++---
On 19.05.2018 02:52, Dmitry Osipenko wrote:
> Map firewall-copied buffers into Host1x's IOVA space, otherwise Host1x
> CDMA can't access the command buffers and all submitted jobs fail if IOMMU
> and Host1x firewall are enabled in the kernels config.
>
> Signed-off-by: Dmitr
buffer and hence IOMMU isn't needed in this case.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/host1x/dev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index f1d5f76e9c33..d88073e7d22d 100644
--- a/drive
PLL_C is running at 600MHz which is significantly higher than the 216MHz
of the PLL_P and it is known that PLL_C is always-ON because AHB BUS is
running on that PLL. Let's use PLL_C as intermediate clock source, making
CPU snappier a tad during of the frequency transition.
Signed-off-by: Dmitry
PLL_P is known to be always running at 216MHz, hence there is no need to
query its rate.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/cpufreq/tegra20-cpufreq.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/cpufreq/tegra20-cpufre
On 23.05.2018 13:44, Dmitry Osipenko wrote:
> On 23.05.2018 08:58, Viresh Kumar wrote:
>> On 23-05-18, 00:14, Dmitry Osipenko wrote:
>>> Tegra20-cpufreq driver missed enabling the CPU clocks. This results in a
>>> clock-enable refcount disbalance on PLL_P <->
On 20.05.2018 13:15, Dmitry Osipenko wrote:
> CPU isn't allowed to touch secure registers while running under secure
> monitor. Hence skip applying CPU erratas in the reset handler if Trusted
> Foundations firmware presents.
>
> Signed-off-by: Dmitry Osipenko <dig...@gmail.com&
Map firewall-copied buffers into Host1x's IOVA space, otherwise Host1x
CDMA can't access the command buffers and all submitted jobs fail if IOMMU
and Host1x firewall are enabled in the kernels config.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/host1x/job.
On 06.06.2018 13:45, Thierry Reding wrote:
> On Mon, Jun 04, 2018 at 01:36:49AM +0300, Dmitry Osipenko wrote:
>> Hello,
>>
>> Couple years ago the Tegra20 EMC driver was removed from the kernel
>> due to incompatible changes in the Tegra's clock driver. This patchset
>
On 06.06.2018 14:02, Thierry Reding wrote:
> On Mon, Jun 04, 2018 at 01:36:54AM +0300, Dmitry Osipenko wrote:
>> Introduce driver for the External Memory Controller (EMC) found on Tegra20
>> chips, which controls the external DRAM on the board. The purpose of this
>> driver
On Monday, 11 June 2018 23:52:22 MSK Stefan Agner wrote:
> Add support for the NAND flash controller found on NVIDIA
> Tegra 2 SoCs. This implementation does not make use of the
> command queue feature. Regular operations/data transfers are
> done in PIO mode. Page read/writes with hardware ECC
fan Agner
> ---
Otherwise looks good to me:
Reviewed-by: Dmitry Osipenko
There couple nit comments about newlines below, maybe you could clean up them
if there will be another revision.
> MAINTAINERS |7 +
> drivers/mtd/nand/raw/Kconfig |6 +
> driver
On Sunday, 10 June 2018 14:09:24 MSK Stefan Agner wrote:
> On 09.06.2018 14:21, Dmitry Osipenko wrote:
> > On Saturday, 9 June 2018 00:51:01 MSK Stefan Agner wrote:
> >> On 01.06.2018 11:20, Dmitry Osipenko wrote:
> >> > On 01.06.2018 01:16, Stefan Agner wrote:
&g
On Monday, 11 June 2018 23:52:22 MSK Stefan Agner wrote:
> Add support for the NAND flash controller found on NVIDIA
> Tegra 2 SoCs. This implementation does not make use of the
> command queue feature. Regular operations/data transfers are
> done in PIO mode. Page read/writes with hardware ECC
On Tuesday, 12 June 2018 10:46:03 MSK Stephen Boyd wrote:
> Quoting Dmitry Osipenko (2018-06-05 05:12:32)
>
> > Apparently there was an attempt to avoid out-of-bounds accesses when there
> > is only one memory timing available, but there is a typo in the code that
> &g
Add interrupt entry into the EMC DT node.
Signed-off-by: Dmitry Osipenko
Acked-by: Peter De Schrijver
---
arch/arm/boot/dts/tegra20.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 983dd5c14794..3cd3cb28cfd9 100644
Embedded memory controller has a corresponding clock, document the clock
property.
Signed-off-by: Dmitry Osipenko
---
.../devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt| 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20
EMC has a dedicated interrupt that is used to notify about completion of
HW operations. Document the interrupt property.
Signed-off-by: Dmitry Osipenko
Acked-by: Rob Herring
Acked-by: Peter De Schrijver
---
.../devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt| 2 ++
1 file changed
Introduce driver for the External Memory Controller (EMC) found on Tegra20
chips, which controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.
Signed-off-by: Dmitry Osipenko
Acked-by: Peter De Schrijver
Add clock entry into the EMC DT node.
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra20.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 3cd3cb28cfd9..877e41fe87cf 100644
--- a/arch/arm/boot/dts/tegra20
Move tegra20-emc binding to the memory-controllers directory for
consistency with the other Tegra memory bindings.
Signed-off-by: Dmitry Osipenko
---
.../{arm/tegra => memory-controllers}/nvidia,tegra20-emc.txt | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename Documentat
Kernel should never gate the EMC clock as it causes immediate lockup, so
removing clk-gate functionality doesn't affect anything. Turning EMC clk
gate into divider allows to implement glitch-less EMC scaling, avoiding
reparenting to a backup clock.
Signed-off-by: Dmitry Osipenko
Acked-by: Peter
error messages, etc.
- Factored out use_pllm_ud bit checking into a standalone patch for
consistency.
Dmitry Osipenko (8):
dt: bindings: tegra20-emc: Document interrupt property
dt: bindings: tegra20-emc: Document clock property
dt: bindings: Move tegra20-emc binding to memory-control
Ensure that direct PLLM sourcing is turned off for EMC as we don't support
that configuration in the clk driver.
Signed-off-by: Dmitry Osipenko
Acked-by: Peter De Schrijver
---
drivers/clk/tegra/clk-tegra20.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/tegra/clk
On Sunday, 10 June 2018 18:32:02 MSK Boris Brezillon wrote:
> On Sun, 10 Jun 2018 18:00:06 +0300
>
> Dmitry Osipenko wrote:
> > > >> That seems a lot of work for a code path I do not intend to ever use
> > > >> :-)
> > > >
> > >
On Monday, 11 June 2018 14:35:03 MSK Thierry Reding wrote:
> On Wed, Jun 06, 2018 at 04:42:01PM +0300, Dmitry Osipenko wrote:
> > On 06.06.2018 14:02, Thierry Reding wrote:
> > > On Mon, Jun 04, 2018 at 01:36:54AM +0300, Dmitry Osipenko wrote:
> [...]
>
On Monday, 11 June 2018 14:50:13 MSK Boris Brezillon wrote:
> On Mon, 11 Jun 2018 14:45:45 +0300
>
> Dmitry Osipenko wrote:
> > On Sunday, 10 June 2018 18:32:02 MSK Boris Brezillon wrote:
> > > On Sun, 10 Jun 2018 18:00:06 +0300
> > >
> > > Dmitry Osip
On Monday, 11 June 2018 14:41:33 MSK Thierry Reding wrote:
> On Mon, Jun 11, 2018 at 01:35:03PM +0200, Thierry Reding wrote:
> > On Wed, Jun 06, 2018 at 04:42:01PM +0300, Dmitry Osipenko wrote:
> > > On 06.06.2018 14:02, Thierry Reding wrote:
> > > > On Mon, Ju
On Monday, 11 June 2018 18:53:43 MSK Thierry Reding wrote:
> On Mon, Jun 11, 2018 at 04:06:41PM +0300, Dmitry Osipenko wrote:
> > On Monday, 11 June 2018 14:35:03 MSK Thierry Reding wrote:
> > > On Wed, Jun 06, 2018 at 04:42:01PM +0300, Dmitry Osipenko wrote:
> > > >
On Saturday, 9 June 2018 00:51:01 MSK Stefan Agner wrote:
> On 01.06.2018 11:20, Dmitry Osipenko wrote:
> > On 01.06.2018 01:16, Stefan Agner wrote:
> >> Add support for the NAND flash controller found on NVIDIA
> >> Tegra 2 SoCs. This implementation does not make us
On 28.05.2018 16:15, Ville Syrjälä wrote:
> On Sat, May 26, 2018 at 06:56:22PM +0300, Dmitry Osipenko wrote:
>> Color keying is the action of replacing pixels matching a given color
>> (or range of colors) with transparent pixels in an overlay when
>> performing blitting. Depe
On 29.05.2018 02:48, Dmitry Osipenko wrote:
> inversion=true" if mask has form of 0x11000111, though this could be not
For clarity: I meant s/0x11000111/0xFF000FFF/.
On 26.05.2018 19:18, Laurent Pinchart wrote:
> On Saturday, 26 May 2018 19:16:54 EEST Laurent Pinchart wrote:
>> Hi Dimitri,
>
> And sorry for the spelling mistake :-/
That's also a kinda correct spelling. No worries ;)
Recently binding of the Memory Controller has been extended, exposing
the Memory Client reset controls and hence it is now a reset controller.
Tegra video-decoder device is among the Memory Controller reset users,
document the new optional VDE HW reset property.
Signed-off-by: Dmitry Osipenko
failing the MC probe. This allows us to just move the Reset Controller
registering before the SMMU registration, reducing code churning. Also
let's not fail MC probe in a case of Reset Controller registration failure
as it doesn't prevent the MC driver to work.
Signed-off-by: Dmitry Osipenko <
On 26.05.2018 19:16, Laurent Pinchart wrote:
> Hi Dimitri,
>
> Thank you for the patch.
>
> I'll review this in details, but as this patch is based on the "[PATCH/RFC
> 1/4] drm: Add colorkey properties" patch I've submitted, please retain the
> authorship, both in the Signed-off-by line, and
ps://lists.freedesktop.org/archives/dri-devel/2017-December/160510.html
Dmitry Osipenko (2):
drm: Add generic colorkey properties
drm/tegra: plane: Implement generic colorkey property for older
Tegra's
drivers/gpu/drm/drm_atomic.c | 36 ++
drivers/g
301 - 400 of 5091 matches
Mail list logo
