On 15.12.2017 15:51, Arnd Bergmann wrote:
> The newly introduced driver has optional suspend/resume functions,
> causing a warning when CONFIG_PM is disabled:
>
> drivers/gpu/drm/tegra/hub.c:749:12: error: 'tegra_display_hub_resume' defined
> but not used [-Werror=unused-function]
>
On 15.12.2017 16:33, Thierry Reding wrote:
> On Fri, Dec 15, 2017 at 01:51:52PM +0100, Arnd Bergmann wrote:
>> The newly introduced driver has optional suspend/resume functions,
>> causing a warning when CONFIG_PM is disabled:
>>
>> drivers/gpu/drm/tegra/hub.c:749:12: error:
On 11.12.2017 16:31, Dmitry Osipenko wrote:
> On 11.12.2017 13:25, Thierry Reding wrote:
>> On Mon, Dec 11, 2017 at 02:07:38AM +0300, Dmitry Osipenko wrote:
>>> UTMI pads are shared by USB controllers and reset of UTMI pads is shared
>>> with the reset of USB1 controll
On 15.12.2017 23:25, Lucas Stach wrote:
> Am Freitag, den 15.12.2017, 01:45 +0300 schrieb Dmitry Osipenko:
>> On 15.12.2017 00:41, Lucas Stach wrote:
>>> Am Montag, den 11.12.2017, 18:26 +0300 schrieb Dmitry Osipenko:
>>>> On 11.12.2017 17:27, Thierry Reding wrote:
&g
On 19.12.2017 20:52, Alan Stern wrote:
> On Sun, 17 Dec 2017, Dmitry Osipenko wrote:
>
>> Previously tegra-phy driver was built only when ehci-tegra was, now
>> tegra-phy has its own Kconfig entry. Remove the USB_PHY dependencies
>> from ehci-tegra's Kconfig since th
On 19.12.2017 22:56, Michael Turquette wrote:
> Quoting Dmitry Osipenko (2017-12-18 19:59:06)
>> Machine dies if HCLK, SCLK or EMC is disabled, hence mark these clocks
>> as critical. Currently some of drivers do not manage clocks properly,
>> expecting clocks to be 'always e
USB Ethernet gadget now works on Tegra30.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/usb/chipidea/ci_hdrc_tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_tegra.c
b/drivers/usb/chipidea/ci_hdrc_tegra.c
index 7b65a1
On 05.11.2017 14:01, Mikko Perttunen wrote:
> To allow client drivers to free resources when jobs have completed,
> deliver job completion callbacks to them. This requires adding
> reference counting to context objects, as job completion can happen
> after the userspace application has closed the
On 05.11.2017 14:01, Mikko Perttunen wrote:
> To allow client drivers to free resources when jobs have completed,
> deliver job completion callbacks to them. This requires adding
> reference counting to context objects, as job completion can happen
> after the userspace application has closed the
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 Osipenko wrote:
>>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>>> Add an option to host1x_channel_request to interruptibly wait for a
>>
On 11.11.2017 17:06, Vladimir Zapolskiy wrote:
> Hi Dmitry,
>
> I'll add just a couple of minor comments, in general the code looks
> very good.
>
Thank you very much for the review!
> On 10/20/2017 12:34 AM, Dmitry Osipenko wrote:
>> NVIDIA Tegra20/30/114/124/132
On 11.11.2017 17:21, Vladimir Zapolskiy wrote:
> Hi Dmitry,
>
> On 10/20/2017 12:34 AM, Dmitry Osipenko wrote:
>> Add binding documentation for the Video Decoder Engine which is found
>> on NVIDIA Tegra20/30/114/124/132 SoC's.
>>
>> Signed-off-by:
On 11.11.2017 17:18, Vladimir Zapolskiy wrote:
> Hi Dmitry,
>
> On 10/20/2017 12:34 AM, Dmitry Osipenko wrote:
>> From: Vladimir Zapolskiy <v...@mleia.com>
>>
>> All Tegra SoCs contain 256KiB IRAM, which is used to store CPU resume code
>> and b
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 Osipenko wrote:
>>>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>>>> Add an opti
On 03.11.2017 16:07, Marcel Ziswiler wrote:
> Hi Rafael, dear community
>
> One of our customers reported seeing freezes when running the LTS Linux
> kernel 4.9.x on our Toradex Colibri T20 modules [1]. I was able to
> reproduce a complete SoC lock-up after a few minutes also running the
> latest
On 04.11.2017 23:49, Marcel Ziswiler wrote:
> On Fri, 2017-11-03 at 21:52 +0300, Dmitry Osipenko wrote:
>> I haven't seen any problems with the cpuidle on next and 4.14-rc7
>> works fine.
>>
>> # cat /sys/devices/system/cpu/cpu[0-1]/cpuidle/state[0-1]/usage
>> 1
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 after job's pining,
when all patching
On 05.11.2017 14:01, Mikko Perttunen wrote:
> Host1x has a feature called MLOCKs which allow a certain class
> (~HW unit) to be locked (in the mutex sense) and unlocked during
> command execution, preventing other channels from accessing the
> class while it is locked. This is necessary to prevent
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 implements a channel allocation model
On 07.11.2017 15:28, Mikko Perttunen wrote:
> 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
On 07.11.2017 16:11, Mikko Perttunen wrote:
> 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
On 05.11.2017 14:01, Mikko Perttunen wrote:
> Hi all,
>
> this adds support for a new model of hardware channel allocation for
> Host1x/TegraDRM. In the current model, one hardware channel is
> allocated for each client device at probe time. This is simple but
> does not allow for optimal use of
On 11.12.2017 13:02, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 02:09:59AM +0300, Dmitry Osipenko wrote:
>> Add Kconfig entry so that other drivers other than ehci-tegra
>> (like ChipIdea) could add Tegra's PHY to build dependencies.
>>
>> Signed-off-by: Dmitry
On 11.12.2017 13:13, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko wrote:
>> Add manual HW power management to drivers probe/remove in order to
>> not fail in a case of runtime power management being disabled in kernel
>> config.
>&g
On 11.12.2017 13:04, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 02:10:00AM +0300, Dmitry Osipenko wrote:
>> UDC driver won't probe without Tegra's PHY, hence select it in the
>> Kconfig.
>>
>> Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
>> -
On 11.12.2017 12:37, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 02:07:37AM +0300, Dmitry Osipenko wrote:
>> 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
>> consiste
On 11.12.2017 16:53, Dmitry Osipenko wrote:
> On 11.12.2017 13:13, Thierry Reding wrote:
>> On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko wrote:
>>> Add manual HW power management to drivers probe/remove in order to
>>> not fail in a case of runtime powe
On 11.12.2017 12:53, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 01:55:35AM +0300, Dmitry Osipenko wrote:
>> This fixes "utmi_phy_clk_enable: timeout waiting for phy to stabilize"
>> error message.
>>
>> Signed-off-by: Dmitry Osipenko <dig...@gmail.c
On 11.12.2017 13:25, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 02:07:38AM +0300, Dmitry Osipenko wrote:
>> UTMI pads are shared by USB controllers and reset of UTMI pads is shared
>> with the reset of USB1 controller. Currently reset of UTMI pads is done by
>> the EHC
On 11.12.2017 13:12, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 02:19:43AM +0300, Dmitry Osipenko wrote:
>> HW reset isn't actually broken on Tegra20, but there is a dependency on
>> first display controller to be taken out of reset for the second to be
>> enabled succe
On 11.12.2017 17:27, Thierry Reding wrote:
> On Mon, Dec 11, 2017 at 04:53:56PM +0300, Dmitry Osipenko wrote:
>> On 11.12.2017 13:13, Thierry Reding wrote:
>>> On Mon, Dec 11, 2017 at 02:19:44AM +0300, Dmitry Osipenko wrote:
>>>> Add manual HW power management to
Currently VDE clock rate is determined by clock config left from
bootloader, let's not rely on it and explicitly specify the clock
rate in the CCF driver.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/clk/tegra/clk-tegra114.c | 1 +
drivers/clk/tegra/clk-tegra124
this change once drivers would be corrected.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/clk/tegra/clk-divider.c | 3 ++-
drivers/clk/tegra/clk-tegra-periph.c | 27 ++--
drivers/clk/tegra/clk-tegra-super-gen4.c | 8 ---
drivers/clk/tegra/clk-te
The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
clock driver doesn't provide that rate, so the requested clock is rounded
up to 312 MHz. Let's add entry for 216 MHz to match with cpufreq.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/clk/tegra/clk-teg
PLL_C_OUT_1 can't produce 216 MHz defined in the init_table. Let's
set it to 240 MHz and explicitly specify HCLK rate for consistency.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/clk/tegra/clk-tegra20.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
Hi Hans,
On 04.12.2017 17:04, Hans Verkuil wrote:
> Hi Dmitry,
>
> As you already mention in the TODO, this should become a v4l2 codec driver.
>
> Good existing examples are the coda, qcom/venus and mtk-vcodec drivers.
>
> One thing that is not clear from this code is if the tegra hardware is
On 05.12.2017 16:03, Hans Verkuil wrote:
> On 12/05/17 13:17, Dmitry Osipenko wrote:
>> Hi Hans,
>>
>> On 04.12.2017 17:04, Hans Verkuil wrote:
>>> Hi Dmitry,
>>>
>>> As you already mention in the TODO, this should become a v4l2 codec driver.
>>
This fixes "utmi_phy_clk_enable: timeout waiting for phy to stabilize"
error message.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/usb/phy/phy-tegra-usb.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/phy/phy-tegra
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 | 72 +-
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 | 46 +
include/linux/usb/tegra_usb_phy.h | 2 +
3 files changed, 87 inse
UDC driver won't probe without Tegra's PHY, hence select it in the
Kconfig.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/usb/chipidea/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 785f0e
Add Kconfig entry so that other drivers other than ehci-tegra
(like ChipIdea) could add Tegra's PHY to build dependencies.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/usb/host/Kconfig | 2 +-
drivers/usb/phy/Kconfig | 8
drivers/usb/phy/Makefile | 2 +-
3
Add manual HW power management to drivers probe/remove in order to
not fail in a case of runtime power management being disabled in kernel
config.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/dc.c | 164 +++
drivers/g
HW reset isn't actually broken on Tegra20, but there is a dependency on
first display controller to be taken out of reset for the second to be
enabled successfully.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/dc.
On 10.12.2017 22:29, Nicolas Dufresne wrote:
> Le dimanche 10 décembre 2017 à 21:56 +0300, Dmitry Osipenko a écrit :
>>> I've CC-ed Maxime and Giulio as well: they are looking into adding support
>>> for
>>> the stateless allwinner codec based on thi
Add Video Decoder Engine device node.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/boot/dts/tegra20.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 36909d
Add binding documentation for the Video Decoder Engine which is found
on NVIDIA Tegra20/30/114/124/132 SoC's.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Acked-by: Rob Herring <r...@kernel.org>
---
.../devicetree/bindings/media/nvidia,tegra-vde.txt | 55 ++
NVIDIA Tegra20/30/114/124/132 SoC's have video decoder engine that
supports standard set of video formats like H.264 / MPEG-4 / WMV / VC1.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
MAINTAINERS |9 +
drivers/staging/media/K
TODO'
- CC'd media maintainers for the review as per Greg's K-H request,
v1 can be viewed at https://lkml.org/lkml/2017/9/25/606
Dmitry Osipenko (3):
media: dt: bindings: Add binding for NVIDIA Tegra Video Decoder Engine
staging: media: Introduce NVIDIA Tegra video decoder driver
From: Vladimir Zapolskiy <v...@mleia.com>
All Tegra20 SoCs contain 256KiB IRAM, which is used to store
resume code and by a video decoder engine.
Signed-off-by: Vladimir Zapolskiy <v...@mleia.com>
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
arch/arm/boot/dt
On 12.12.2017 13:02, Peter De Schrijver wrote:
> On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote:
>> The cpufreq driver uses 216 MHz as the lowest CPU clock frequency, but
>> clock driver doesn't provide that rate, so the requested clock is rounded
>> up to 312
On 12.12.2017 05:54, Peter Chen wrote:
> On Mon, Dec 11, 2017 at 04:09:44PM +0300, Dmitry Osipenko wrote:
>> On 11.12.2017 13:04, Thierry Reding wrote:
>>> On Mon, Dec 11, 2017 at 02:10:00AM +0300, Dmitry Osipenko wrote:
>>>> UDC driver won't probe wit
On 05.12.2017 16:21, Mikko Perttunen wrote:
> On 07.11.2017 23:23, Dmitry Osipenko wrote:
>> On 07.11.2017 15:28, Mikko Perttunen wrote:
>>> On 05.11.2017 18:46, Dmitry Osipenko wrote:
>>>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>>>> ...
>&g
HW reset isn't actually broken on Tegra20, but there is a dependency on
first display controller to be taken out of reset for the second to be
enabled successfully.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
Change log:
v2: Got rid of global variable and n
-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/dc.c | 75 +++---
drivers/gpu/drm/tegra/dc.h | 2 ++
2 files changed, 59 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 460510
host1x_syncpt_wait() takes timeout value in jiffies, but DRM passes it in
milliseconds.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/drm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm
iommu_map_sg() doesn't return a error value, but a size of the requested
IOMMU mapping or zero in case of error.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/gem.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/g
ha.
Fixes: 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats")
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/gpu/drm/tegra/dc.c| 29 ++---
drivers/gpu/drm/tegra/dc.h| 1 +
drivers/gpu/drm/tegra/fb.c| 13 -
d
us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dmitry-Osipenko/usb-phy-tegra-Cleanup-error-messages/20171220-142227
> base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> config: arm-tegra_defconfig (att
the overlay plane.
- Fixed warning that was reported by kbuild bot for ARM64 build.
Dmitry Osipenko (5):
drm/tegra: dc: Link DC1 to DC0 on Tegra20
drm/tegra: Restore opaque and drop alpha formats on Tegra20/30
drm/tegra: Trade overlay plane for cursor on older Tegra's
drm/tegra
On 27.04.2018 15:36, Robin Murphy wrote:
> Hi Thierry,
>
> On 27/04/18 11:02, Thierry Reding wrote:
>> On Mon, Apr 09, 2018 at 11:07:22PM +0300, Dmitry Osipenko wrote:
>>> Currently GART writes one page entry at a time. More optimal would be to
>>> aggregat
On 07.05.2018 10:59, Joerg Roedel wrote:
> On Fri, Apr 27, 2018 at 12:02:02PM +0200, Thierry Reding wrote:
>> Joerg, I've gone over the git log and header files and I see no mention
>> of why the TLB flush interface isn't used for mapping. Do you recall any
>> special reasons why the same
On 14.05.2018 14:51, Thierry Reding wrote:
> On Mon, May 14, 2018 at 12:18:42AM +0300, Dmitry Osipenko wrote:
>> Reading of status register within the interrupt handler fails with -EAGAIN
>> if I2C is busy with handling some other request at the same time. Move the
>> actu
On 14.05.2018 15:01, Dmitry Osipenko wrote:
> On 14.05.2018 14:51, Thierry Reding wrote:
>> On Mon, May 14, 2018 at 12:18:42AM +0300, Dmitry Osipenko wrote:
>>> Reading of status register within the interrupt handler fails with -EAGAIN
>>> if I2C is busy with
On 14.05.2018 15:21, Laxman Dewangan wrote:
>
>
> On Monday 14 May 2018 05:29 PM, Thierry Reding wrote:
>> * PGP Signed by an unknown key
>>
>> On Mon, May 14, 2018 at 12:13:47AM +0300, Dmitry Osipenko wrote:
>>> Nothing prevents I2C clients to acce
On 14.05.2018 15:18, Wolfram Sang wrote:
> On Mon, May 14, 2018 at 01:59:33PM +0200, Thierry Reding wrote:
>> On Mon, May 14, 2018 at 12:13:47AM +0300, Dmitry Osipenko wrote:
>>> Nothing prevents I2C clients to access I2C while Tegra's driver is being
>>> suspended, t
On 27.04.2018 12:34, Thierry Reding wrote:
> On Mon, Apr 09, 2018 at 10:28:31PM +0300, Dmitry Osipenko wrote:
> [...]
>> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> [...]
>> +#define MC_GART_ERROR_REQ 0x30
>> +#define MC_DECERR_EME
On 27.04.2018 13:24, Thierry Reding wrote:
> On Fri, Apr 27, 2018 at 01:13:47PM +0300, Dmitry Osipenko wrote:
>> On 27.04.2018 12:34, Thierry Reding wrote:
>>> On Mon, Apr 09, 2018 at 10:28:31PM +0300, Dmitry Osipenko wrote:
>>> [...]
>>>> diff --git a/dri
Hi Marcel,
On 27.04.2018 15:33, Ziswiler wrote:
> Hi Dmitry
>
> Isn't the CLK_RST_CONTROLLER_MISC_CLK_ENB_0 the other way around e.g.
> DEV1_OSC_DIV_SEL at bit 23:22 and DEV2_OSC_DIV_SEL at 21:20?
>
> On Fri, 2018-04-27 at 02:58 +0300, Dmitry Osipenko wrote:
>> CDEV1
On 27.04.2018 13:02, Thierry Reding wrote:
> On Mon, Apr 09, 2018 at 11:07:22PM +0300, Dmitry Osipenko wrote:
>> 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-4
On 27.04.2018 12:39, Thierry Reding wrote:
> On Fri, Apr 13, 2018 at 02:33:50PM +0300, Dmitry Osipenko wrote:
>> From: Thierry Reding <tred...@nvidia.com>
>>
>> Define the table of memory controller hot resets for Tegra210.
>>
>> Signed-off
n the case of TPS6586X. It is fine to remove the
HW-reinitialization for now because it should be only needed in a case of
using lowest power-mode during suspend, which upstream kernel doesn't
support.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Cc: <sta...@vger.kernel.org>
---
drivers/
timeout in the Tegra I2C driver).
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/mfd/tps6586x.c | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9896e0
On 08.05.2018 21:16, Dmitry Osipenko wrote:
> GART aperture is shared by all devices, hence there is a single IOMMU
> domain and group shared by these devices. Allocation of a group per
> device only wastes resources and allowance of having more than one domain
> is simply wrong b
Hi Robin,
On 11.05.2018 14:34, Robin Murphy wrote:
> Hi Dmitry,
>
> On 08/05/18 19:16, Dmitry Osipenko wrote:
>> GART can't handle all devices, ignore devices that aren't related to GART.
>> Device tree must explicitly assign GART IOMMU to the devices.
>>
>> Si
On 11.05.2018 16:02, Robin Murphy wrote:
> On 08/05/18 19:16, Dmitry Osipenko wrote:
>> Introduce iotlb_sync_map() callback that is invoked in the end of
>> iommu_map(). This new callback allows IOMMU drivers to avoid syncing
>> on mapping of each contiguous chunk and sync on
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
>> domain and group shared by these devices. Allocation of a group per
>> device only wastes resources and allowance of
On 07.05.2018 11:04, Joerg Roedel wrote:
> On Mon, May 07, 2018 at 12:19:01AM +0300, Dmitry Osipenko wrote:
>> Probably the best variant would be to give an explicit control over syncing
>> to a
>> user of the IOMMU API, like for example device driver may perform multiple
>
Parents of CDEV1/2 clocks are determined by muxing of the corresponding
pins. Pinctrl driver now provides the CDEV1/2 clock muxes and hence
CDEV1/2 clocks could have correct parents. Set CDEV1/2 parents to the
corresponding muxes to fix the parents.
Signed-off-by: Dmitry Osipenko <
to be enabled by the child, so let's return -EPROBE_DEFER
till parent clock appears.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/clk/tegra/clk-tegra114.c | 2 +-
drivers/clk/tegra/clk-tegra124.c | 2 +-
drivers/clk/tegra/clk-tegra20.c
one board and broke the
other, now Tegra's clk driver correctly sets parent for the CDEV2 clock
and hence patch could be reverted safely, restoring USB for all of the
boards.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Reviewed-by: Marcel Ziswiler <mar...@ziswiler.com>
Tested-by: Ma
alleij.
- Addressed v1 review comments: fixed swapped DEV1/2 clk div bits,
made DEV1/2 divs read-only, etc minor changes.
Dmitry Osipenko (4):
clk: tegra20: Add DEV1/DEV2 OSC dividers
clk: tegra20: Correct parents of CDEV1/2 clocks
clk: tegra: Add quirk for getting C
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 clk-controller driver could get an actual parent clock for the
CDEV1/2 clocks.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Re
CDEV1/CDEV2 clocks could have corresponding oscillator clock divider as
a parent. Add these dividers in order to be able to provide that parent
option.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
Reviewed-by: Marcel Ziswiler <mar...@ziswiler.com>
Tested-by: Marcel Z
Memory Controller driver invokes SMMU driver registration and MC's
registers mapping is shared with SMMU. This mapping goes away if MC
driver probing fails after SMMU registration.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/memory/tegra/mc.c | 18 +-
by a
misbehaving client.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/memory/tegra/mc.c | 40 ++
drivers/memory/tegra/tegra114.c | 64 +
drivers/memory/tegra/tegra124.c | 66 +
drivers/memory/tegra/tegra20.c
GART can't handle all devices, ignore devices that aren't related to GART.
Device tree must explicitly assign GART IOMMU to the devices.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/iommu/tegra-gart.c | 33 -
1 file changed, 32 insertions
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 <
GART contains registers needed by the Memory Controller driver. Provide
access to the MC driver by utilizing its GART-integration facility.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/iommu/tegra-gart.c | 23 +++
1 file changed, 23 insertions(+)
diff
GART driver is built-in, hence it can't be unloaded. This patch merely
removes the dead code.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/iommu/tegra-gart.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/iommu/tegra-
Introduce iotlb_sync_map() callback that is invoked in the end of
iommu_map(). This new callback allows IOMMU drivers to avoid syncing
on mapping of each contiguous chunk and sync only when whole mapping
is completed, optimizing performance of the mapping operation.
Signed-off-by: Dmitry Osipenko
t;
domains will stomp on each other.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/iommu/tegra-gart.c | 107 +
1 file changed, 24 insertions(+), 83 deletions(-)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
index 5b2d276203
dead code,
allowing to have one IOMMU domain at max, etc.
4. This series introduces and utilizes iotlb_sync_map() callback that was
previously suggested by Joerg Roedel in [1].
[1] https://www.spinics.net/lists/linux-tegra/msg32914.html
Dmitry Osipenko (9):
memory: tegra: Provid
In order to report clients name and access direction on GART page fault,
MC driver needs to access GART registers. Add facility that provides
access to the GART.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/memory/tegra/mc.c | 26 +++---
include/soc
Properly clean up allocated resources on driver probe failure.
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/iommu/tegra-gart.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c
Remove unneeded 'includes' and sort them in alphabet order. Also remove
pr_fmt since there is no pr_xxx() and it doesn't affect dev_xxx().
Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
---
drivers/iommu/tegra-gart.c | 17 +
1 file changed, 5 insertions(+), 12 del
On 07.05.2018 18:51, Dmitry Osipenko wrote:
[snip]
> Secondly, the interesting part is that mapping / unmapping of a contiguous
> allocation (CMA using DMA API) is slower by ~50% then doing it for a sparse
> allocation (get_pages using bare IOMMU API). /I think/ it's a sh
On 04.05.2018 13:54, Thierry Reding wrote:
> On Fri, May 04, 2018 at 02:47:20AM +0300, Dmitry Osipenko wrote:
>> Attach GR2D to the display IOMMU group in order to provide GR2D access
>> to BO's IOVA.
>>
>> Signed-off-by: Dmitry Osipenko <dig...@gmail.com>
>&g
On 04.05.2018 14:10, Thierry Reding wrote:
> On Fri, May 04, 2018 at 03:08:42AM +0300, Dmitry Osipenko wrote:
>> Currently resized plane produces a "pixelated" image which doesn't look
>> nice, especially in a case of a video overlay. Enable scaling filters that
>&
On 04.05.2018 13:56, Thierry Reding wrote:
> On Fri, May 04, 2018 at 02:47:18AM +0300, Dmitry Osipenko wrote:
>> Hi,
>>
>> This series enables IOMMU support for 2d/3d HW on Tegra30/114, as a result
>> userspace that uses 2d/3d could work with the active IOMMU.
>>
201 - 300 of 5091 matches
Mail list logo
