Re: [PATCH v1 0/5] CPUFREQ OPP's and Tegra30 support by tegra20-cpufreq driver

On 9/6/18 3:35 PM, Marcel Ziswiler wrote: On Thu, 2018-08-30 at 22:43 +0300, Dmitry Osipenko wrote: Hello, This series adds support for CPU frequency scaling on Tegra30 and device tree support that allows to implement thermal throttling and customize available CPU frequencies per-board

Re: [PATCH v2 2/2] clk: tegra20: Enable lock-status polling for PLLs

On 8/31/18 12:29 PM, Peter De Schrijver wrote: > On Thu, Aug 30, 2018 at 09:42:10PM +0300, Dmitry Osipenko wrote: >> Currently all PLL's on Tegra20 use a hardcoded delay despite of having >> a lock-status bit. The lock-status polling was disabled ~7 years ago >> because PLL

Re: [PATCH v2 0/5] Initial support of Trusted Foundations on Tegra30

On Monday, 2 July 2018 21:53:08 MSK Peter Geis wrote: > On 07/02/2018 10:48 AM, Dmitry Osipenko wrote: > > On Friday, 29 June 2018 22:37:02 MSK Peter Geis wrote: > >> Good Afternoon, > >> > >> I have tested these patches on the Ouya T3 device. > &g

Re: [PATCH v2 0/5] Initial support of Trusted Foundations on Tegra30

Kexec works for me on T30 with the following kernel config options on top of the tegra_defconfig: CONFIG_SMP=n CONFIG_CPU_IDLE=n CONFIG_TEGRA_IOMMU_SMMU=n CPU stopping isn't working correctly with the trusted foundations and it's not obvious what is wrong. I hope we'll fix it at some point.

Re: [PATCH v1] memory: tegra: Correct driver probe order

On Saturday, 26 May 2018 17:20:35 MSK Dmitry Osipenko wrote: > The Reset Controller should be registered in the end of probe, otherwise > Memory Controller device goes away if IRQ requesting fails and the Reset > Controller stays registered. To avoid having to unwind the MC probing in

Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes

On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote: > On Fri, Jul 06, 2018 at 05:58:50PM +0300, Dmitry Osipenko wrote: > > On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote: > > > IIRC my earlier idea was to have different colorkey modes for the > >

Re: [PATCH v3 6/8] clk: tegra20: Turn EMC clock gate into divider

On Monday, 9 July 2018 03:00:17 MSK Stephen Boyd wrote: > Quoting Dmitry Osipenko (2018-06-17 07:55:37) > > > Kernel should never gate the EMC clock as it causes immediate lockup, so > > removing clk-gate functionality doesn't affect anything. Turning EMC clk > >

Re: [RFCv4,19/21] media: vim2m: add request support

Hello, On 07.03.2018 19:37, Paul Kocialkowski wrote: > Hi, > > First off, I'd like to take the occasion to say thank-you for your work. > This is a major piece of plumbing that is required for me to add support > for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers, > such as

Re: [RFCv4,19/21] media: vim2m: add request support

Hello, On 07.03.2018 19:37, Paul Kocialkowski wrote: > Hi, > > First off, I'd like to take the occasion to say thank-you for your work. > This is a major piece of plumbing that is required for me to add support > for the Allwinner CedarX VPU hardware in upstream Linux. Other drivers, > such as

Re: [PATCH v3 1/3] clk: tegra: Mark HCLK, SCLK and EMC as critical

On 12.03.2018 10:15, Thierry Reding wrote: > On Fri, Mar 09, 2018 at 05:35:46PM +0300, Dmitry Osipenko wrote: >> On 08.03.2018 17:44, Thierry Reding wrote: >>> On Thu, Mar 01, 2018 at 04:33:29PM +0300, Dmitry Osipenko wrote: >>>> On 15.01.2018 13:56, Dmitry Osipenko

Re: [RFCv4,19/21] media: vim2m: add request support

t;> On Mon, Mar 12, 2018 at 5:10 PM, Paul Kocialkowski >>> <paul.kocialkow...@bootlin.com> wrote: >>>> Hi, >>>> >>>> On Sun, 2018-03-11 at 22:42 +0300, Dmitry Osipenko wrote: >>>>> Hello, >>>>> >>>>> On

Re: [RFCv4,19/21] media: vim2m: add request support

On 12.03.2018 15:32, Alexandre Courbot wrote: > On Mon, Mar 12, 2018 at 5:15 PM, Tomasz Figa <tf...@chromium.org> wrote: >> Hi Paul, Dmitry, >> >> On Mon, Mar 12, 2018 at 5:10 PM, Paul Kocialkowski >> <paul.kocialkow...@bootlin.com> wrote: >>> Hi, &

Re: [PATCH] clk: tegra: fix pllu rate configuration

On 01.03.2018 10:41, Peter De Schrijver wrote: > On Wed, Feb 28, 2018 at 08:20:47PM +0300, Dmitry Osipenko wrote: >> On 28.02.2018 17:14, Peter De Schrijver wrote: >>> On Wed, Feb 28, 2018 at 03:00:23PM +0300, Dmitry Osipenko wrote: >>>> On 28.02.2018 12:36, Peter De

Re: [PATCH v3 1/3] clk: tegra: Mark HCLK, SCLK and EMC as critical

On 15.01.2018 13:56, Dmitry Osipenko wrote: > On 10.01.2018 16:59, Dmitry Osipenko wrote: >> Machine dies if HCLK, SCLK or EMC is disabled. Hence mark these clocks >> as critical. >> >> Signed-off-by: Dmitry Osipenko <dig...@gmail.com> >> Acked-by: Pete

Re: [PATCH] clk: tegra: fix pllu rate configuration

On 01.03.2018 16:19, Dmitry Osipenko wrote: > On 01.03.2018 10:41, Peter De Schrijver wrote: >> On Wed, Feb 28, 2018 at 08:20:47PM +0300, Dmitry Osipenko wrote: >>> On 28.02.2018 17:14, Peter De Schrijver wrote: >>>> On Wed, Feb 28, 2018 at 03:00:23P

[PATCH v1 3/3] drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/gpu/drm/tegra/dc.c | 28 +++- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 22bf513612d1..e4d567ec07cc 100644 --- a/drivers/gpu/drm/tegra/dc.c

[PATCH v1 1/3] drm/tegra: plane: Fix RGB565 plane format on older Tegra's

t;drm/tegra: dc: Implement legacy blending") Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/gpu/drm/tegra/dc.c| 11 ++- drivers/gpu/drm/tegra/plane.c | 21 ++--- drivers/gpu/drm/tegra/plane.h | 2 +- 3 files changed, 9 insertions(+), 25 deletion

[PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

Keep old 'dependent' state of unaffected planes, this way new state takes into account current state of unaffected planes. Fixes: ebae8d07435a ("drm/tegra: dc: Implement legacy blending") Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/gpu/drm/tegra/plane.c | 15 ++

Re: [PATCH v1 1/3] drm/tegra: plane: Fix RGB565 plane format on older Tegra's

On 15.03.2018 13:27, Thierry Reding wrote: > On Thu, Mar 15, 2018 at 04:00:23AM +0300, Dmitry Osipenko wrote: >> Simplify opaque format adjustment by removing format checking. There are >> only 4 formats that require the adjustment and so this way is less error >> prone,

Re: [PATCH v1 1/3] drm/tegra: plane: Fix RGB565 plane format on older Tegra's

On 15.03.2018 15:48, Dmitry Osipenko wrote: > On 15.03.2018 13:27, Thierry Reding wrote: >> On Thu, Mar 15, 2018 at 04:00:23AM +0300, Dmitry Osipenko wrote: >>> Simplify opaque format adjustment by removing format checking. There are >>> only 4 formats that require the

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

On 15.03.2018 13:29, Thierry Reding wrote: > On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote: >> Keep old 'dependent' state of unaffected planes, this way new state takes >> into account current state of unaffected planes. >> >> Fixes: ebae8d07435a ("

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

On 15.03.2018 15:42, Dmitry Osipenko wrote: > On 15.03.2018 13:29, Thierry Reding wrote: >> On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote: >>> Keep old 'dependent' state of unaffected planes, this way new state takes >>> into account current

Re: [PATCH v1 2/3] drm/tegra: plane: Correct legacy blending

On 15.03.2018 15:42, Dmitry Osipenko wrote: > On 15.03.2018 13:29, Thierry Reding wrote: >> On Thu, Mar 15, 2018 at 04:00:24AM +0300, Dmitry Osipenko wrote: >>> Keep old 'dependent' state of unaffected planes, this way new state takes >>> into account current

[PATCH v2] drm/tegra: plane: Keep 'dependent' blending state of unaffected planes

This way new state takes into account the current state of unaffected (by the atomic commit) planes. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- v2: Dropped unrelated 'cleanup' changes and fixed s/state->dependent[i]/state->dependent[index]/ typo. drivers/gpu/drm/t

Re: [PATCH v3 1/3] clk: tegra: Mark HCLK, SCLK and EMC as critical

On 08.03.2018 17:44, Thierry Reding wrote: > On Thu, Mar 01, 2018 at 04:33:29PM +0300, Dmitry Osipenko wrote: >> On 15.01.2018 13:56, Dmitry Osipenko wrote: >>> On 10.01.2018 16:59, Dmitry Osipenko wrote: >>>> Machine dies if HCLK, SCLK or EMC is disabled. Hence mark

[PATCH v4 06/15] memory: tegra: Setup interrupts mask before requesting IRQ

This avoids unwanted interrupt during MC driver probe. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/mc.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c index d2005b

[PATCH v4 04/15] dt-bindings: memory: tegra: Add hot resets definitions

Add definitions for the Tegra20+ memory controller hot resets. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> Reviewed-by: Rob Herring <r...@kernel.org> --- include/dt-bindings/memory/tegra114-mc.h | 19 +++ include/dt-bindings/memory/tegra1

[PATCH v4 03/15] dt-bindings: arm: tegra: Document #reset-cells property of the Tegra20 MC

Memory Controller has a memory client "hot reset" functionality, which resets the DMA interface of a memory client, so MC is a reset controller. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> Reviewed-by: Rob Herring <r...@kernel.org> --- .../devicetree/bindings/ar

[PATCH v4 05/15] memory: tegra: Do not handle spurious interrupts

-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/mc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c index a4803ac192bb..d2005b995821 100644 --- a/drivers/memory/tegra/mc.c +++ b/drivers/memory/tegra/mc.c @@

[PATCH v4 08/15] memory: tegra: Remove unused headers inclusions

Tegra210 contains some unused leftover headers, remove them for consistency. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/tegra210.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/memory/tegra/tegra210.c b/drivers/memory/tegra/tegra210.c

[PATCH v4 07/15] memory: tegra: Apply interrupts mask per SoC

faults which may be undesirable by newer generations. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/mc.c | 21 +++-- drivers/memory/tegra/mc.h | 9 + drivers/memory/tegra/tegra114.c | 2 ++ drivers/memory/tegra/tegra124.

[PATCH v4 02/15] dt-bindings: memory: tegra: Document #reset-cells property of the Tegra30 MC

Memory Controller has a memory client "hot reset" functionality, which resets the DMA interface of a memory client. So MC is a reset controller in addition to IOMMU. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> Reviewed-by: Rob Herring <r...@kernel.org> --- .../devi

[PATCH v4 01/15] dt-bindings: arm: tegra: Remove duplicated Tegra30+ MC binding

There are two bindings for the same Memory Controller. One of the bindings became obsolete long time ago and probably was left unnoticed, remove it for consistency. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> Reviewed-by: Rob Herring <r...@kernel.org> --- .../bindings/arm/

[PATCH v4 09/15] memory: tegra: Squash tegra20-mc into common tegra-mc driver

Tegra30+ has some minor differences in registers / bits layout compared to Tegra20. Let's squash Tegra20 driver into the common tegra-mc driver in a preparation for the upcoming MC hot reset controls implementation, avoiding code duplication. Signed-off-by: Dmitry Osipenko <dig...@gmail.

[PATCH v4 00/15] Memory controller hot reset

Basically a re-send of V1 with some minor changes. Dmitry Osipenko (14): dt-bindings: arm: tegra: Remove duplicated Tegra30+ MC binding dt-bindings: memory: tegra: Document #reset-cells property of the Tegra30 MC dt-bindings: arm: tegra: Document #reset-cells property of the Tegra20

[PATCH v1 3/4] iommu/tegra: gart: Constify number of GART pages

GART has a fixed aperture size, hence the number of pages is constant. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/iommu/tegra-gart.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c

[PATCH v1 1/4] iommu/tegra: gart: Add debugging facility

-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/iommu/tegra-gart.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c index b62f790ad1ba..4c0abdcd1ad2 100644 --- a/drivers/iommu/tegra-gart.c +++ b/drivers/iommu

[PATCH v1 4/4] iommu/tegra: gart: Optimize map/unmap

Currently GART writes one page entry at a time. More optimal would be to aggregate the writes and flush BUS buffer in the end, this gives map/unmap 10-40% (depending on size of mapping) performance boost compared to a flushing after each entry update. Signed-off-by: Dmitry Osipenko <

[PATCH v1 0/4] Tegra GART fixes and improvements

GART driver wasn't ever been utilized in upstream, but finally this should change sometime soon with Tegra's DRM driver rework. In general GART driver works fine, though there are couple things that could be improved. Dmitry Osipenko (4): iommu/tegra: gart: Add debugging facility iommu/tegra

[PATCH v1 2/4] iommu/tegra: gart: Fix gart_iommu_unmap()

It must return the number of unmapped bytes on success, returning 0 means that unmapping failed and in result only one page is unmapped. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/iommu/tegra-gart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/d

[PATCH v3 3/3] usb: phy: Add Kconfig entry for Tegra PHY driver

disabled in kernels config by allowing user to manually select the PHY driver. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/usb/host/Kconfig | 4 +--- drivers/usb/phy/Kconfig | 9 + drivers/usb/phy/Makefile | 2 +- 3 files changed, 11 insertions(+), 4 deletions(-) diff

[PATCH v3 0/3] Tegra's USB driver dependency fix

set assert/deassert to the PHY's probe. Removed function names as per Thierry's suggestion. Dmitry Osipenko (3): usb: phy: tegra: Cleanup error messages usb: tegra: Move utmi-pads reset from ehci-tegra to tegra-phy usb: phy: Add Kconfig entry for Tegra PHY driver drivers/usb/ho

[PATCH v3 1/3] usb: phy: tegra: Cleanup error messages

Tegra's PHY driver has a mix of pr_err() and dev_err(), let's switch to dev_err() and use common errors message formatting across the driver for consistency. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/usb/phy/phy-tegra-usb.c | 69 --

[PATCH v3 2/3] usb: tegra: Move utmi-pads reset from ehci-tegra to tegra-phy

to resolve the problem. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/usb/host/ehci-tegra.c | 87 ++- drivers/usb/phy/phy-tegra-usb.c | 79 --- include/linux/usb/tegra_usb_phy.h | 2 + 3 files change

[PATCH v4 10/15] memory: tegra: Introduce memory client hot reset

In order to reset busy HW properly, memory controller needs to be involved, otherwise it is possible to get corrupted memory or hang machine if HW was reset during DMA. Introduce memory client 'hot reset' that will be used for resetting of busy HW. Signed-off-by: Dmitry Osipenko <dig...@gmail.

[PATCH v4 12/15] memory: tegra: Add Tegra124 memory controller hot resets

Define the table of memory controller hot resets for Tegra124. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/tegra124.c | 42 + 1 file changed, 42 insertions(+) diff --git a/drivers/memory/tegra/tegra124.c b/drivers/memory

[PATCH v4 11/15] memory: tegra: Add Tegra210 memory controller hot resets

From: Thierry Reding Define the table of memory controller hot resets for Tegra210. Signed-off-by: Thierry Reding --- drivers/memory/tegra/tegra210.c | 45 + 1 file changed, 45 insertions(+) diff --git

[PATCH v4 15/15] memory: tegra: Add Tegra20 memory controller hot resets

Define the table of memory controller hot resets for Tegra20 and add specific to Tegra20 hot reset operations. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/tegra20.c | 118 + 1 file changed, 118 insertions(+) diff --git a/d

[PATCH v4 13/15] memory: tegra: Add Tegra114 memory controller hot resets

Define the table of memory controller hot resets for Tegra114. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/tegra114.c | 33 + 1 file changed, 33 insertions(+) diff --git a/drivers/memory/tegra/tegra114.c b/drivers/memory

[PATCH v4 14/15] memory: tegra: Add Tegra30 memory controller hot resets

Define the table of memory controller hot resets for Tegra30. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/memory/tegra/tegra30.c | 33 + 1 file changed, 33 insertions(+) diff --git a/drivers/memory/tegra/tegra30.c b/drivers/memory/tegra/t

[PATCH v1 1/4] drm/tegra: plane: Implement zPos plane property for older Tegra's

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

[PATCH v1 0/4] More DRM object properties on Tegra

This patchset adds new custom plane / CRTC properties that are very useful for displaying video overlay, they will be used by Opentegra Xorg driver. Also generic zPos property is implemented for older Tegra's. Dmitry Osipenko (4): drm/tegra: plane: Implement zPos plane property for older

[PATCH v1 3/4] drm/tegra: plane: Add custom colorkey properties for older Tegra's

userspace like Opentegra Xorg driver to implement colorkey support for XVideo extension. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/gpu/drm/tegra/dc.c| 166 ++ drivers/gpu/drm/tegra/dc.h| 18 +++- drivers/gpu/drm/tegra/plane.c

[PATCH v1 4/4] drm/tegra: plane: Add custom CSC BLOB property

This new property allows userspace to apply custom color conversion coefficients per plane, making possible to utilize display controller for color adjustments of a video overlay. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/gpu/drm/tegra/dc.c

[PATCH v1 2/4] drm/tegra: dc: Rename supports_blending to legacy_blending

Older Tegra's support blending. Rename SoC info entry supports_blending to 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 insertions(

Re: [PATCH] ARM: tegra: fix ulpi regression on tegra20

On 20.04.2018 11:52, Marc Dietrich wrote: > Hi Marcel, > > Am Montag, 19. Februar 2018, 16:12:52 CEST schrieb Marcel Ziswiler: >> From: Marcel Ziswiler >> >> Since commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting >> during registration") ULPI has been

[PATCH v1] gpu: host1x: Fix dma_free_wc() argument in the error path

If IOVA allocation or IOMMU mapping fails, dma_free_wc() is invoked with size=0 because of a typo, that triggers "kernel BUG at mm/vmalloc.c:124!". Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/gpu/host1x/cdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletio

Re: [PATCH] ARM: tegra: fix ulpi regression on tegra20

Hi Marcel, On 24.04.2018 01:05, Marcel Ziswiler wrote: > Hi Dmitry > > On Fri, 2018-04-20 at 13:50 +0300, Dmitry Osipenko wrote: >> ... >> I managed to find CDEV clocks in TRM this time. > > And where exactly in which TRM? In all my attempts at finding anything > C

Re: [PATCH v1 3/4] drm/tegra: plane: Add custom colorkey properties for older Tegra's

On 17.04.2018 12:00, Daniel Vetter wrote: > On Mon, Apr 16, 2018 at 03:16:27PM +0300, Dmitry Osipenko wrote: >> Colorkey'ing allows to draw on top of overlapping planes, like for example >> on top of a video plane. Older Tegra's have a limited colorkey'ing >> capability such t

Re: [PATCH v1 3/4] drm/tegra: plane: Add custom colorkey properties for older Tegra's

Daniel, Oddly thunderbird and gmail webinterface are refusing to add your 'Daniel Vetter <dan...@ffwll.ch>' to list of recipients automatically. On 17.04.2018 20:08, Dmitry Osipenko wrote: > On 17.04.2018 12:00, Daniel Vetter wrote: >> On Mon, Apr 16, 2018 at 03:16:27PM +0300,

Re: [PATCH v1 4/4] drm/tegra: plane: Add custom CSC BLOB property

On 17.04.2018 12:01, Daniel Vetter wrote: > On Mon, Apr 16, 2018 at 03:16:28PM +0300, Dmitry Osipenko wrote: >> This new property allows userspace to apply custom color conversion >> coefficients per plane, making possible to utilize display controller >> for color adjustmen

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

On 27.03.2018 14:54, Robin Murphy wrote: > On 26/03/18 22:20, Dmitry Osipenko wrote: >> On 25.03.2018 21:09, Stefan Agner wrote: >>> As documented in GCC naked functions should only use Basic asm >>> syntax. The Extended asm or mixture of Basic asm and "C"

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

: "r" (type), "r" (arg1), "r" (arg2) >^ > > Use a regular function to be more portable. This aligns also with > the other smc call implementations e.g. in qcom_scm-32.c and > bcm_kona_smc.c. > > Cc: Dmitry Osipenko <dig

Re: [PATCH v1 3/3] drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

On 16.03.2018 10:36, Daniel Vetter wrote: > On Thu, Mar 15, 2018 at 11:45 AM, Thierry Reding > <thierry.red...@gmail.com> wrote: >> On Thu, Mar 15, 2018 at 04:00:25AM +0300, Dmitry Osipenko wrote: >>> Older Tegra's do not support RGBA format for the cursor, but inst

[PATCH v1 0/5] Tegra Video Decoder patches for 4.17

is the best bet now for the proper VDE reset. So here is a small patchset that addresses couple of minor issues that I've spotted over time. Dmitry Osipenko (5): media: staging: tegra-vde: Align bitstream size to 16K media: staging: tegra-vde: Silence some of checkpatch warnings media: staging

[PATCH v1 2/5] media: staging: tegra-vde: Silence some of checkpatch warnings

Make all strings single line to make them grep'able and add a comment to the memory barrier. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/staging/media/tegra-vde/tegra-vde.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/staging

[PATCH v1 3/5] media: staging: tegra-vde: Correct minimum size of U/V planes

Stride of U/V planes must be aligned to 16 bytes (2 macroblocks). This needs to be taken into account, otherwise it is possible to get a silent memory corruption if dmabuf size is less than the size of decoded video frame. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/s

[PATCH v1 1/5] media: staging: tegra-vde: Align bitstream size to 16K

I've noticed that decoding fails sometime if size of bitstream buffer isn't aligned to 16K, probably because HW fetches data from memory in a 16K granularity and if the last chunk of data isn't aligned, HW reads garbage data beyond the dmabuf and tries to parse it. Signed-off-by: Dmitry Osipenko

[PATCH v1 4/5] media: staging: tegra-vde: Do not handle spurious interrupts

Do not handle interrupts if we haven't asked for them, potentially that could happen if HW wasn't programmed properly. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/staging/media/tegra-vde/tegra-vde.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/staging

[PATCH v1 5/5] media: staging: tegra-vde: Correct included header

This is Open Firmware driver, hence 'of_device.h' should be included instead of 'platform_device.h'. Right now OF headers happen to be included indirectly and this may break in the future, so let's correct the header. Signed-off-by: Dmitry Osipenko <dig...@gmail.com> --- drivers/staging

Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function

On 22.03.2018 15:43, Stefan Agner wrote: > On 22.03.2018 12:48, Robin Murphy wrote: >> On 21/03/18 21:41, Stefan Agner wrote: >>> On 21.03.2018 18:16, Robin Murphy wrote: >>>> On 21/03/18 16:40, Stephen Warren wrote: >>>>> On 03/21/2018 09:26 AM, Dmit

Re: [PATCH 3/5] ARM: trusted_foundations: do not use naked function

On 21.03.2018 17:09, Stefan Agner wrote: > On 21.03.2018 13:13, Robin Murphy wrote: >> On 20/03/18 23:02, Stefan Agner wrote: >>> As documented in GCC naked functions should only use Basic asm >>> syntax. The Extended asm or mixture of Basic asm and "C" code is >>> not guaranteed. Currently this

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

On 01.03.2018 23:20, Andreas Dilger wrote: > > On Mar 1, 2018, at 9:04 AM, Theodore Ts'o wrote: >> This doesn't seem to make sense; the PC is where we are currently >> executing, and LR is the "Link Register" where the flow of control >> will be returning after the current

Re: [PATCH V15 06/22] mmc: block: Add blk-mq support

On 27.02.2018 11:57, Linus Walleij wrote: > On Mon, Feb 26, 2018 at 10:48 PM, Dmitry Osipenko <dig...@gmail.com> wrote: >> On 22.02.2018 20:54, Dmitry Osipenko wrote: >>> On 22.02.2018 10:42, Adrian Hunter wrote: > >>>> SDIO (unless it is a comb

Re: [PATCH] clk: tegra: fix pllu rate configuration

On 27.02.2018 02:04, Marcel Ziswiler wrote: > On Mon, 2018-02-26 at 15:42 +0300, Dmitry Osipenko wrote: >> On 23.02.2018 02:04, Marcel Ziswiler wrote: >>> Turns out latest upstream U-Boot does not configure/enable pllu >>> which >>> leaves it at some default

Re: [PATCH] clk: tegra: fix pllu rate configuration

On 23.02.2018 02:04, Marcel Ziswiler wrote: > Turns out latest upstream U-Boot does not configure/enable pllu which > leaves it at some default rate of 500 kHz: > > root@apalis-t30:~# cat /sys/kernel/debug/clk/clk_summary | grep pll_u >pll_u 330

Re: [PATCH] clk: tegra: fix pllu rate configuration

On 28.02.2018 12:36, Peter De Schrijver wrote: > On Tue, Feb 27, 2018 at 02:59:11PM +0300, Dmitry Osipenko wrote: >> On 27.02.2018 02:04, Marcel Ziswiler wrote: >>> On Mon, 2018-02-26 at 15:42 +0300, Dmitry Osipenko wrote: >>>> On 23.02.2018 02:04, Marcel Ziswiler

Re: [PATCH] clk: tegra: fix pllu rate configuration

On 28.02.2018 17:14, Peter De Schrijver wrote: > On Wed, Feb 28, 2018 at 03:00:23PM +0300, Dmitry Osipenko wrote: >> On 28.02.2018 12:36, Peter De Schrijver wrote: >>> On Tue, Feb 27, 2018 at 02:59:11PM +0300, Dmitry Osipenko wrote: >>>> On 27.02.2018 02:04, Marce

Re: EXT4 Oops (Re: [PATCH V15 06/22] mmc: block: Add blk-mq support)

On 01.03.2018 19:04, Theodore Ts'o wrote: > On Thu, Mar 01, 2018 at 10:55:37AM +0200, Adrian Hunter wrote: >> On 27/02/18 11:28, Adrian Hunter wrote: >>> On 26/02/18 23:48, Dmitry Osipenko wrote: >>>> But still something is wrong... I've been getting occas

[PATCH v1 11/11] regulator: core: Properly handle case where supply is the couple

Check whether supply regulator is the couple to avoid infinite recursion during of locking. Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c

[PATCH v1 07/11] dt-bindings: regulator: Document new regulator-max-step-microvolt property

Certain hardware may require supply voltage to be changed in steps. Define new property that allow to describe such hardware. Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/regulator/regulator.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation

[PATCH v1 03/11] regulator: core: Mutually resolve regulators coupling

If registered regulator found a couple, then the couple can find the registered regulator too and hence coupling can be mutually resolved at the registration time. Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 54 +--- 1 file changed, 17

[PATCH v1 10/11] regulator: core: Use ww_mutex for regulators locking

Wait/wound mutex shall be used in order to avoid lockups on locking of coupled regulators. Signed-off-by: Dmitry Osipenko Suggested-by: Lucas Stach --- drivers/regulator/core.c | 401 +++ include/linux/regulator/driver.h | 3 +- 2 files changed, 307

[PATCH v1 09/11] regulator: core: Decouple regulators on regulator_unregister()

Regulators shall be uncoupled if one of the couples disappear. Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 38 ++ 1 file changed, 38 insertions(+) diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index ba03bdf3716f

[PATCH v1 05/11] dt-bindings: regulator: Change regulator-coupled-max-spread property

= < >; regulator-coupled-max-spread = <30 20>; }; Signed-off-by: Dmitry Osipenko --- Documentation/devicetree/bindings/regulator/regulator.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/regulator/regul

[PATCH v1 06/11] regulator: core: Limit regulators coupling to a single couple

Device tree binding was changed in a way that now max-spread values must be defied per regulator pair. Limit number of pairs in order to adapt to the new binding without changing regulators code. Signed-off-by: Dmitry Osipenko --- include/linux/regulator/driver.h | 2 +- 1 file changed, 1

[PATCH v1 04/11] regulator: core: Don't allow to get regulator until all couples resolved

Don't allow to get regulator until all of its couples resolved because consumer will get EPERM and coupling shall be transparent for the drivers. Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/regulator/core.c

[PATCH v1 08/11] regulator: core: Add new max_uV_step constraint

nt). Add new "max_uV_step" constraint that breaks voltage change into several steps, each step is limited by the max_uV_step value. Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 41 +++ drivers/regulator/of_regulator.c | 4 +++ inc

[PATCH v1 00/11] Continuing the work on coupled regulators

g is okay. 6. Patches were tested with KASAN on Tegra20 / Tegra30, I tried to cover various cases and verified that voltage constraints not violated under different circumstances. Please review, thanks. [0] https://lkml.org/lkml/2018/4/23/619 Dmitry Osipenko (9): regulator: core: Mutual

[PATCH v1 02/11] regulator: core: Change voltage setting path

registered. Add function for locking coupled regulators and supplies. Extract a new function regulator_set_voltage_rdev() from regulator_set_voltage_unlocked(), which is called when setting voltage of a single regulator. Signed-off-by: Maciej Purski Signed-off-by: Dmitry Osipenko --- drivers

[PATCH v1 01/11] regulator: core: Add voltage balancing mechanism

, is not coupled, method regulator_get_optimal_voltage() should simply return the lowest voltage fulfilling consumers' demands. Coupling should be checked only if the system is in PM_SUSPEND_ON state. Signed-off-by: Maciej Purski Signed-off-by: Dmitry Osipenko --- drivers/regulator/core.c | 229

Re: [PATCH v1 1/2] soc/tegra: pmc: Turn powergates_lock into spinlock

On 8/30/18 9:36 PM, Dmitry Osipenko wrote: > This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y > and machine (Tegra30) booted with SMP=n or all secondary CPU's are put > offline. > > BUG: sleeping function called from invalid context at > kernel/l

Re: [PATCH v3 0/8] Support Trusted Foundations firmware on Tegra30

On 8/30/18 9:04 PM, Dmitry Osipenko wrote: > Hello, > > All consumer-grade Tegra30 devices, like Nexus 7 tablet; Ouya console and > others, use Trusted Foundations firmware that doesn't allow CPU to access > secure registers directly from the Linux kernel, these accesses shal

Re: [PATCH v1 0/2] LP1/LP2 suspend-resume CPU clock fixes for Tegra30

On 8/30/18 10:04 PM, Dmitry Osipenko wrote: > Hello, > > This patch-series fixes CPU hanging after suspend-resume / LP2 cpuidle > on Tegra30. The bug really appears during stress-testing, like frequent > suspending under variable load + the upcoming Tegra30 CPUFREQ driver. > &g

Re: [PATCH v1 0/4] EMC fixes for Tegra30+

On 8/30/18 9:54 PM, Dmitry Osipenko wrote: > Hello, > > This patch series fixes couple bugs in the memory self-refresh code. > The EMC / MC state is properly restored after patches being applied, > please review. > > Dmitry Osipenko (4): > ARM: tegra: Fix misse

Re: [PATCH v5 0/8] Tegra20 External Memory Controller driver

On 7/24/18 7:42 PM, Dmitry Osipenko wrote: > Changelog: > > v5: > - Fixed wrong EMC clock divider type in the "Turn EMC clock gate into > divider" patch. It is a Tegra's fractional 7.1 divider and not a > simple integer divider. Peter, plea

Re: [PATCH v1 1/2] soc/tegra: pmc: Turn powergates_lock into spinlock

On 10/15/18 3:52 PM, Jon Hunter wrote: > > On 30/08/18 19:36, Dmitry Osipenko wrote: >> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y >> and machine (Tegra30) booted with SMP=n or all secondary CPU's are put >> offline. >> >> BUG: s

Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

On 10/22/18 8:36 AM, Viresh Kumar wrote: > On 21-10-18, 23:54, Dmitry Osipenko wrote: >> Voltage regulators may be not available on some variations of HW, allow to >> request stub voltage regulators by OPP core in a such case to reduce code >> churning within drivers. >&g

Re: [RFC PATCH v2 01/17] OPP: Allow to request stub voltage regulators

On 10/22/18 2:32 PM, Viresh Kumar wrote: > On 22-10-18, 14:29, Dmitry Osipenko wrote: >> On 10/22/18 8:36 AM, Viresh Kumar wrote: >>> On 21-10-18, 23:54, Dmitry Osipenko wrote: >>>> Voltage regulators may be not available on some variations of HW, allow to >&g

Re: [PATCH] mfd: tps6586x: Handle interrupts on suspend

On 10/22/18 12:52 PM, Thierry Reding wrote: > On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote: >> From: Jonathan Hunter >> >> The tps6586x driver creates an irqchip that is used by its various child >> devices for managing interrupts. The tps6586x-rtc device is one of its >> children

<    2   3   4   5   6   7   8   9   10   11   >