Re: [PATCH v2 1/2] drm: adi: axi-hdmi-tx: Add support for AXI HDMI TX IP core

2020-10-26 Thread kernel test robot
Hi Bogdan,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next linus/master v5.10-rc1 next-20201026]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Bogdan-Togorean/drm-adi-axi-hdmi-tx-Add-support-for-AXI-HDMI-TX-IP-core/20201026-144628
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: powerpc-randconfig-r002-20201026 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
f2c25c70791de95d2466e09b5b58fc37f6ccd7a4)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# 
https://github.com/0day-ci/linux/commit/3b750d1d27d13d89fd7b53ec7154dd2ae2cd36a5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Bogdan-Togorean/drm-adi-axi-hdmi-tx-Add-support-for-AXI-HDMI-TX-IP-core/20201026-144628
git checkout 3b750d1d27d13d89fd7b53ec7154dd2ae2cd36a5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from drivers/gpu/drm/adi/axi_hdmi_tx_encoder.c:11:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :231:1: note: expanded from here
   __do_insb
   ^
   arch/powerpc/include/asm/io.h:541:56: note: expanded from macro '__do_insb'
   #define __do_insb(p, b, n)  readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from drivers/gpu/drm/adi/axi_hdmi_tx_encoder.c:11:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :233:1: note: expanded from here
   __do_insw
   ^
   arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw'
   #define __do_insw(p, b, n)  readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from drivers/gpu/drm/adi/axi_hdmi_tx_encoder.c:11:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c),
   ^~~
   arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 
'DEF_PCI_AC_NORET'
   __do_##name al; \
   ^~
   :235:1: note: expanded from here
   __do_insl
   ^
   arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl'
   #define __do_insl(p, b, n)  readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n))
  ~^
   In file included from drivers/gpu/drm/adi/axi_hdmi_tx_encoder.c:11:
   In file included from include/linux/io.h:13:
   In file included from arch/powerpc/include/asm/io.h:604:
   arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer 
arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]

Re: [PATCH v5 10/10] drm/fb_helper: Support framebuffers in I/O memory

2020-10-26 Thread Thomas Zimmermann
Hi

Am 24.10.20 um 22:38 schrieb Sam Ravnborg:
> Hi Thomas.
> 
> On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
>> At least sparc64 requires I/O-specific access to framebuffers. This
>> patch updates the fbdev console accordingly.
>>
>> For drivers with direct access to the framebuffer memory, the callback
>> functions in struct fb_ops test for the type of memory and call the rsp
>> fb_sys_ of fb_cfb_ functions. Read and write operations are implemented
>> internally by DRM's fbdev helper.
>>
>> For drivers that employ a shadow buffer, fbdev's blit function retrieves
>> the framebuffer address as struct dma_buf_map, and uses dma_buf_map
>> interfaces to access the buffer.
>>
>> The bochs driver on sparc64 uses a workaround to flag the framebuffer as
>> I/O memory and avoid a HW exception. With the introduction of struct
>> dma_buf_map, this is not required any longer. The patch removes the rsp
>> code from both, bochs and fbdev.
>>
>> v5:
>>  * implement fb_read/fb_write internally (Daniel, Sam)
>> v4:
>>  * move dma_buf_map changes into separate patch (Daniel)
>>  * TODO list: comment on fbdev updates (Daniel)
>>
>> Signed-off-by: Thomas Zimmermann 
>> Tested-by: Sam Ravnborg 
> Reviewed-by: Sam Ravnborg 
> 
> But see a few comments below on naming for you to consider.
> 
>   Sam
> 
>> ---
>>  Documentation/gpu/todo.rst|  19 ++-
>>  drivers/gpu/drm/bochs/bochs_kms.c |   1 -
>>  drivers/gpu/drm/drm_fb_helper.c   | 227 --
>>  include/drm/drm_mode_config.h |  12 --
>>  4 files changed, 230 insertions(+), 29 deletions(-)
>>
>> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
>> index 7e6fc3c04add..638b7f704339 100644
>> --- a/Documentation/gpu/todo.rst
>> +++ b/Documentation/gpu/todo.rst
>> @@ -197,13 +197,28 @@ Convert drivers to use drm_fbdev_generic_setup()
>>  
>>  
>>  Most drivers can use drm_fbdev_generic_setup(). Driver have to implement
>> -atomic modesetting and GEM vmap support. Current generic fbdev emulation
>> -expects the framebuffer in system memory (or system-like memory).
>> +atomic modesetting and GEM vmap support. Historically, generic fbdev 
>> emulation
>> +expected the framebuffer in system memory or system-like memory. By 
>> employing
>> +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported
>> +as well.
>>  
>>  Contact: Maintainer of the driver you plan to convert
>>  
>>  Level: Intermediate
>>  
>> +Reimplement functions in drm_fbdev_fb_ops without fbdev
>> +---
>> +
>> +A number of callback functions in drm_fbdev_fb_ops could benefit from
>> +being rewritten without dependencies on the fbdev module. Some of the
>> +helpers could further benefit from using struct dma_buf_map instead of
>> +raw pointers.
>> +
>> +Contact: Thomas Zimmermann , Daniel Vetter
>> +
>> +Level: Advanced
>> +
>> +
>>  drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup
>>  -
>>  
>> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
>> b/drivers/gpu/drm/bochs/bochs_kms.c
>> index 13d0d04c4457..853081d186d5 100644
>> --- a/drivers/gpu/drm/bochs/bochs_kms.c
>> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
>> @@ -151,7 +151,6 @@ int bochs_kms_init(struct bochs_device *bochs)
>>  bochs->dev->mode_config.preferred_depth = 24;
>>  bochs->dev->mode_config.prefer_shadow = 0;
>>  bochs->dev->mode_config.prefer_shadow_fbdev = 1;
>> -bochs->dev->mode_config.fbdev_use_iomem = true;
>>  bochs->dev->mode_config.quirk_addfb_prefer_host_byte_order = true;
>>  
>>  bochs->dev->mode_config.funcs = &bochs_mode_funcs;
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 6212cd7cde1d..1d3180841778 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -372,24 +372,22 @@ static void drm_fb_helper_resume_worker(struct 
>> work_struct *work)
>>  }
>>  
>>  static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
>> -  struct drm_clip_rect *clip)
>> +  struct drm_clip_rect *clip,
>> +  struct dma_buf_map *dst)
>>  {
>>  struct drm_framebuffer *fb = fb_helper->fb;
>>  unsigned int cpp = fb->format->cpp[0];
>>  size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
>>  void *src = fb_helper->fbdev->screen_buffer + offset;
>> -void *dst = fb_helper->buffer->map.vaddr + offset;
>>  size_t len = (clip->x2 - clip->x1) * cpp;
>>  unsigned int y;
>>  
>> -for (y = clip->y1; y < clip->y2; y++) {
>> -if (!fb_helper->dev->mode_config.fbdev_use_iomem)
>> -memcpy(dst, src, len);
>> -else
>> -memcpy_toio((void __iomem *)dst, src, len);

[PATCH v6 41/52] memory: tegra124-emc: Use devm_platform_ioremap_resource()

2020-10-26 Thread Dmitry Osipenko
Use devm_platform_ioremap_resource() helper which makes code a bit
cleaner.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra124-emc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/memory/tegra/tegra124-emc.c 
b/drivers/memory/tegra/tegra124-emc.c
index 48e772ec544d..2814b1b4a1d9 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -1181,7 +1181,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
 {
struct device_node *np;
struct tegra_emc *emc;
-   struct resource *res;
u32 ram_code;
int err;
 
@@ -1191,8 +1190,7 @@ static int tegra_emc_probe(struct platform_device *pdev)
 
emc->dev = &pdev->dev;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   emc->regs = devm_ioremap_resource(&pdev->dev, res);
+   emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
return PTR_ERR(emc->regs);
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 20/52] ARM: tegra: Correct EMC registers size in Tegra20 device-tree

2020-10-26 Thread Dmitry Osipenko
The Tegra20 EMC registers size should be twice bigger. This patch fixes
the size.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 72a4211a618f..9347f7789245 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -634,7 +634,7 @@ mc: memory-controller@7000f000 {
 
memory-controller@7000f400 {
compatible = "nvidia,tegra20-emc";
-   reg = <0x7000f400 0x200>;
+   reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
#address-cells = <1>;
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 45/52] drm/tegra: dc: Extend debug stats with total number of events

2020-10-26 Thread Dmitry Osipenko
It's useful to know the total number of underflow events and currently
the debug stats are getting reset each time CRTC is being disabled. Let's
account the overall number of events that doesn't get a reset.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/dc.c | 10 ++
 drivers/gpu/drm/tegra/dc.h |  5 +
 2 files changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 986e7a0dde2a..f50a42170977 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1539,6 +1539,11 @@ static int tegra_dc_show_stats(struct seq_file *s, void 
*data)
seq_printf(s, "underflow: %lu\n", dc->stats.underflow);
seq_printf(s, "overflow: %lu\n", dc->stats.overflow);
 
+   seq_printf(s, "frames total: %lu\n", dc->stats.frames_total);
+   seq_printf(s, "vblank total: %lu\n", dc->stats.vblank_total);
+   seq_printf(s, "underflow total: %lu\n", dc->stats.underflow_total);
+   seq_printf(s, "overflow total: %lu\n", dc->stats.overflow_total);
+
return 0;
 }
 
@@ -2289,6 +2294,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): frame end\n", __func__);
*/
+   dc->stats.frames_total++;
dc->stats.frames++;
}
 
@@ -2297,6 +2303,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
dev_dbg(dc->dev, "%s(): vertical blank\n", __func__);
*/
drm_crtc_handle_vblank(&dc->base);
+   dc->stats.vblank_total++;
dc->stats.vblank++;
}
 
@@ -2304,6 +2311,7 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): underflow\n", __func__);
*/
+   dc->stats.underflow_total++;
dc->stats.underflow++;
}
 
@@ -2311,11 +2319,13 @@ static irqreturn_t tegra_dc_irq(int irq, void *data)
/*
dev_dbg(dc->dev, "%s(): overflow\n", __func__);
*/
+   dc->stats.overflow_total++;
dc->stats.overflow++;
}
 
if (status & HEAD_UF_INT) {
dev_dbg_ratelimited(dc->dev, "%s(): head underflow\n", 
__func__);
+   dc->stats.underflow_total++;
dc->stats.underflow++;
}
 
diff --git a/drivers/gpu/drm/tegra/dc.h b/drivers/gpu/drm/tegra/dc.h
index 8fade75caef9..e3fc48f8154a 100644
--- a/drivers/gpu/drm/tegra/dc.h
+++ b/drivers/gpu/drm/tegra/dc.h
@@ -40,6 +40,11 @@ struct tegra_dc_stats {
unsigned long vblank;
unsigned long underflow;
unsigned long overflow;
+
+   unsigned long frames_total;
+   unsigned long vblank_total;
+   unsigned long underflow_total;
+   unsigned long overflow_total;
 };
 
 struct tegra_windowgroup_soc {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 24/52] ARM: tegra: Add nvidia, memory-controller phandle to Tegra20 EMC device-tree

2020-10-26 Thread Dmitry Osipenko
Add nvidia,memory-controller to the Tegra20 External Memory Controller
node. This allows to perform a direct lookup of the Memory Controller
instead of walking up the whole tree. This puts Tegra20 device-tree on
par with Tegra30+.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 2e1304493f7d..8f8ad81916e7 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -663,6 +663,8 @@ emc: memory-controller@7000f400 {
#address-cells = <1>;
#size-cells = <0>;
#interconnect-cells = <0>;
+
+   nvidia,memory-controller = <&mc>;
};
 
fuse@7000f800 {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 15/52] dt-bindings: tegra30-actmon: Document OPP and interconnect properties

2020-10-26 Thread Dmitry Osipenko
Document EMC DFS OPP table and interconnect paths that will be used
for scaling of system's memory bandwidth based on memory utilization
statistics. Previously ACTMON was supposed to drive EMC clock rate
directly, but now it should do it using interconnect framework in order
to support shared voltage scaling in addition to the frequency scaling.

Signed-off-by: Dmitry Osipenko 
---
 .../arm/tegra/nvidia,tegra30-actmon.txt   | 25 +++
 1 file changed, 25 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt 
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
index ea670a5d7ee3..412e939c65cb 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt
@@ -18,8 +18,30 @@ clock-names. See ../../clock/clock-bindings.txt for details.
 ../../reset/reset.txt for details.
 - reset-names: Must include the following entries:
   - actmon
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+- interconnects: Should contain entries for memory clients sitting on
+ MC->EMC memory interconnect path.
+- interconnect-names: Should include name of the interconnect path for each
+  interconnect entry. Consult TRM documentation for
+  information about available memory clients, see MEMORY
+  CONTROLLER section.
+
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: bitfield indicating SoC speedo ID mask
+- opp-peak-kBps: peak bandwidth of the memory channel
 
 Example:
+   dfs_opp_table: opp_table {
+   compatible = "operating-points-v2";
+
+   opp@1275 {
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x000F>;
+   opp-peak-kBps = <51000>;
+   };
+   ...
+   };
+
actmon@6000c800 {
compatible = "nvidia,tegra124-actmon";
reg = <0x0 0x6000c800 0x0 0x400>;
@@ -29,4 +51,7 @@ Example:
clock-names = "actmon", "emc";
resets = <&tegra_car 119>;
reset-names = "actmon";
+   operating-points-v2 = <&dfs_opp_table>;
+   interconnects = <&mc TEGRA124_MC_MPCORER &emc>;
+   interconnect-names = "cpu";
};
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 30/52] memory: tegra20-emc: Make driver modular

2020-10-26 Thread Dmitry Osipenko
This patch adds modularization support to the Tegra20 EMC driver. Driver
now can be compiled as a loadable kernel module.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |  2 +-
 drivers/memory/tegra/tegra20-emc.c | 17 -
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index b38e5255effe..ff426747cd7d 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -9,7 +9,7 @@ config TEGRA_MC
  NVIDIA Tegra SoCs.
 
 config TEGRA20_EMC
-   bool "NVIDIA Tegra20 External Memory Controller driver"
+   tristate "NVIDIA Tegra20 External Memory Controller driver"
default y
depends on ARCH_TEGRA_2x_SOC
help
diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 027f46287dbf..0baa6590adea 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -724,6 +724,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, emc);
tegra_emc_debugfs_init(emc);
 
+   /*
+* Don't allow the kernel module to be unloaded. Unloading adds some
+* extra complexity which doesn't really worth the effort in a case of
+* this driver.
+*/
+   try_module_get(THIS_MODULE);
+
return 0;
 
 unset_cb:
@@ -736,6 +743,7 @@ static const struct of_device_id tegra_emc_of_match[] = {
{ .compatible = "nvidia,tegra20-emc", },
{},
 };
+MODULE_DEVICE_TABLE(of, tegra_emc_of_match);
 
 static struct platform_driver tegra_emc_driver = {
.probe = tegra_emc_probe,
@@ -745,9 +753,8 @@ static struct platform_driver tegra_emc_driver = {
.suppress_bind_attrs = true,
},
 };
+module_platform_driver(tegra_emc_driver);
 
-static int __init tegra_emc_init(void)
-{
-   return platform_driver_register(&tegra_emc_driver);
-}
-subsys_initcall(tegra_emc_init);
+MODULE_AUTHOR("Dmitry Osipenko ");
+MODULE_DESCRIPTION("NVIDIA Tegra20 EMC driver");
+MODULE_LICENSE("GPL v2");
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 21/52] ARM: tegra: Add interconnect properties to Tegra20 device-tree

2020-10-26 Thread Dmitry Osipenko
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 9347f7789245..2e1304493f7d 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -111,6 +111,17 @@ dc@5420 {
 
nvidia,head = <0>;
 
+   interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>,
+   <&mc TEGRA20_MC_DISPLAY0B &emc>,
+   <&mc TEGRA20_MC_DISPLAY1B &emc>,
+   <&mc TEGRA20_MC_DISPLAY0C &emc>,
+   <&mc TEGRA20_MC_DISPLAYHC &emc>;
+   interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -128,6 +139,17 @@ dc@5424 {
 
nvidia,head = <1>;
 
+   interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>,
+   <&mc TEGRA20_MC_DISPLAY0BB &emc>,
+   <&mc TEGRA20_MC_DISPLAY1BB &emc>,
+   <&mc TEGRA20_MC_DISPLAY0CB &emc>,
+   <&mc TEGRA20_MC_DISPLAYHCB &emc>;
+   interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -630,15 +652,17 @@ mc: memory-controller@7000f000 {
interrupts = ;
#reset-cells = <1>;
#iommu-cells = <0>;
+   #interconnect-cells = <1>;
};
 
-   memory-controller@7000f400 {
+   emc: memory-controller@7000f400 {
compatible = "nvidia,tegra20-emc";
reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
#address-cells = <1>;
#size-cells = <0>;
+   #interconnect-cells = <0>;
};
 
fuse@7000f800 {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 25/52] ARM: tegra: Add DVFS properties to Tegra20 EMC device-tree node

2020-10-26 Thread Dmitry Osipenko
Add EMC OPP DVFS/DFS tables and emc-stats subdev that will be used for
dynamic memory bandwidth scaling, while EMC itself will perform voltage
scaling. Update board device-trees with optional EMC core supply and
remove unsupported OPPs.

Signed-off-by: Dmitry Osipenko 
---
 .../boot/dts/tegra20-acer-a500-picasso.dts|  12 ++
 arch/arm/boot/dts/tegra20-colibri.dtsi|   8 +
 arch/arm/boot/dts/tegra20-paz00.dts   |  10 +
 .../arm/boot/dts/tegra20-peripherals-opp.dtsi | 181 ++
 arch/arm/boot/dts/tegra20.dtsi|  12 +-
 5 files changed, 222 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/tegra20-peripherals-opp.dtsi

diff --git a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts 
b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
index a0b829738e8f..f5c1591c8ea8 100644
--- a/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
+++ b/arch/arm/boot/dts/tegra20-acer-a500-picasso.dts
@@ -1058,9 +1058,21 @@ map0 {
};
};
 
+   emc_opp_table0 {
+   /delete-node/ opp@66600;
+   /delete-node/ opp@76000;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@66600;
+   /delete-node/ opp@76000;
+   };
+
memory-controller@7000f400 {
nvidia,use-ram-code;
 
+   core-supply = <&vdd_core>;
+
emc-tables@0 {
nvidia,ram-code = <0>; /* elpida-8gb */
 
diff --git a/arch/arm/boot/dts/tegra20-colibri.dtsi 
b/arch/arm/boot/dts/tegra20-colibri.dtsi
index 6162d193e12c..78a2210bf9ae 100644
--- a/arch/arm/boot/dts/tegra20-colibri.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri.dtsi
@@ -611,6 +611,14 @@ i2c-thermtrip {
};
};
 
+   emc_opp_table0 {
+   /delete-node/ opp@76000;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@76000;
+   };
+
memory-controller@7000f400 {
emc-table@83250 {
reg = <83250>;
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts 
b/arch/arm/boot/dts/tegra20-paz00.dts
index ada2bed8b1b5..7b9f0f279744 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -311,9 +311,19 @@ nvec@7000c500 {
reset-names = "i2c";
};
 
+   emc_opp_table0 {
+   /delete-node/ opp@76000;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@76000;
+   };
+
memory-controller@7000f400 {
nvidia,use-ram-code;
 
+   core-supply = <&core_vdd_reg>;
+
emc-tables@0 {
nvidia,ram-code = <0x0>;
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi 
b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
new file mode 100644
index ..d10c61107702
--- /dev/null
+++ b/arch/arm/boot/dts/tegra20-peripherals-opp.dtsi
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+   emc_icc_dvfs_opp_table: emc_opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@3600 {
+   opp-microvolt = <95 95 130>;
+   opp-hz = /bits/ 64 <3600>;
+   };
+
+   opp@4750 {
+   opp-microvolt = <95 95 130>;
+   opp-hz = /bits/ 64 <4750>;
+   };
+
+   opp@5000 {
+   opp-microvolt = <95 95 130>;
+   opp-hz = /bits/ 64 <5000>;
+   };
+
+   opp@5400 {
+   opp-microvolt = <95 95 130>;
+   opp-hz = /bits/ 64 <5400>;
+   };
+
+   opp@5700 {
+   opp-microvolt = <95 95 130>;
+   opp-hz = /bits/ 64 <5700>;
+   };
+
+   opp@1 {
+   opp-microvolt = <100 100 130>;
+   opp-hz = /bits/ 64 <1>;
+   };
+
+   opp@10800 {
+   opp-microvolt = <100 100 130>;
+   opp-hz = /bits/ 64 <10800>;
+   };
+
+   opp@12000 {
+   opp-microvolt = <100 100 130>;
+   opp-hz = /bits/ 64 <12000>;
+   };
+
+   opp@15000 {
+   opp-microvolt = <100 100 130>;
+   opp-hz = /bits/ 64 <15000>;
+   };
+
+   opp@19000 {
+   opp-microvolt = <100 100 130>;
+   opp-hz = /bits/ 64 <19000>;
+   };
+
+   opp@21600 {
+   opp-microvolt = <100 100 13

[PATCH v6 19/52] dt-bindings: memory: tegra124: Add memory client IDs

2020-10-26 Thread Dmitry Osipenko
Each memory client have a unique hardware ID, this patch adds these IDs.

Signed-off-by: Dmitry Osipenko 
---
 include/dt-bindings/memory/tegra124-mc.h | 68 
 1 file changed, 68 insertions(+)

diff --git a/include/dt-bindings/memory/tegra124-mc.h 
b/include/dt-bindings/memory/tegra124-mc.h
index 186e6b7e9b35..7e73bb400eca 100644
--- a/include/dt-bindings/memory/tegra124-mc.h
+++ b/include/dt-bindings/memory/tegra124-mc.h
@@ -54,4 +54,72 @@
 #define TEGRA124_MC_RESET_ISP2B22
 #define TEGRA124_MC_RESET_GPU  23
 
+#define TEGRA124_MC_PTCR   0
+#define TEGRA124_MC_DISPLAY0A  1
+#define TEGRA124_MC_DISPLAY0AB 2
+#define TEGRA124_MC_DISPLAY0B  3
+#define TEGRA124_MC_DISPLAY0BB 4
+#define TEGRA124_MC_DISPLAY0C  5
+#define TEGRA124_MC_DISPLAY0CB 6
+#define TEGRA124_MC_AFIR   14
+#define TEGRA124_MC_AVPCARM7R  15
+#define TEGRA124_MC_DISPLAYHC  16
+#define TEGRA124_MC_DISPLAYHCB 17
+#define TEGRA124_MC_HDAR   21
+#define TEGRA124_MC_HOST1XDMAR 22
+#define TEGRA124_MC_HOST1XR23
+#define TEGRA124_MC_MSENCSRD   28
+#define TEGRA124_MC_PPCSAHBDMAR29
+#define TEGRA124_MC_PPCSAHBSLVR30
+#define TEGRA124_MC_SATAR  31
+#define TEGRA124_MC_VDEBSEVR   34
+#define TEGRA124_MC_VDEMBER35
+#define TEGRA124_MC_VDEMCER36
+#define TEGRA124_MC_VDETPER37
+#define TEGRA124_MC_MPCORELPR  38
+#define TEGRA124_MC_MPCORER39
+#define TEGRA124_MC_MSENCSWR   43
+#define TEGRA124_MC_AFIW   49
+#define TEGRA124_MC_AVPCARM7W  50
+#define TEGRA124_MC_HDAW   53
+#define TEGRA124_MC_HOST1XW54
+#define TEGRA124_MC_MPCORELPW  56
+#define TEGRA124_MC_MPCOREW57
+#define TEGRA124_MC_PPCSAHBDMAW59
+#define TEGRA124_MC_PPCSAHBSLVW60
+#define TEGRA124_MC_SATAW  61
+#define TEGRA124_MC_VDEBSEVW   62
+#define TEGRA124_MC_VDEDBGW63
+#define TEGRA124_MC_VDEMBEW64
+#define TEGRA124_MC_VDETPMW65
+#define TEGRA124_MC_ISPRA  68
+#define TEGRA124_MC_ISPWA  70
+#define TEGRA124_MC_ISPWB  71
+#define TEGRA124_MC_XUSB_HOSTR 74
+#define TEGRA124_MC_XUSB_HOSTW 75
+#define TEGRA124_MC_XUSB_DEVR  76
+#define TEGRA124_MC_XUSB_DEVW  77
+#define TEGRA124_MC_ISPRAB 78
+#define TEGRA124_MC_ISPWAB 80
+#define TEGRA124_MC_ISPWBB 81
+#define TEGRA124_MC_TSECSRD84
+#define TEGRA124_MC_TSECSWR85
+#define TEGRA124_MC_A9AVPSCR   86
+#define TEGRA124_MC_A9AVPSCW   87
+#define TEGRA124_MC_GPUSRD 88
+#define TEGRA124_MC_GPUSWR 89
+#define TEGRA124_MC_DISPLAYT   90
+#define TEGRA124_MC_SDMMCRA96
+#define TEGRA124_MC_SDMMCRAA   97
+#define TEGRA124_MC_SDMMCR 98
+#define TEGRA124_MC_SDMMCRAB   99
+#define TEGRA124_MC_SDMMCWA100
+#define TEGRA124_MC_SDMMCWAA   101
+#define TEGRA124_MC_SDMMCW 102
+#define TEGRA124_MC_SDMMCWAB   103
+#define TEGRA124_MC_VICSRD 108
+#define TEGRA124_MC_VICSWR 109
+#define TEGRA124_MC_VIW114
+#define TEGRA124_MC_DISPLAYD   115
+
 #endif
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 29/52] memory: tegra-mc: Add interconnect framework

2020-10-26 Thread Dmitry Osipenko
Now Memory Controller is a memory interconnection provider. This allows
us to use interconnect API for tuning of memory configuration. This patch
adds common ICC core and adds hooks which should be implemented by the SoC
drivers.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig |   1 +
 drivers/memory/tegra/mc.c| 129 +++
 drivers/memory/tegra/mc.h|   8 +++
 include/soc/tegra/mc.h   |  16 +
 4 files changed, 154 insertions(+)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 9f0a96bf9ccc..b38e5255effe 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -3,6 +3,7 @@ config TEGRA_MC
bool "NVIDIA Tegra Memory Controller support"
default y
depends on ARCH_TEGRA
+   select INTERCONNECT
help
  This driver supports the Memory Controller (MC) hardware found on
  NVIDIA Tegra SoCs.
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 12ea2c79205a..53d61b05ebf8 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -639,6 +639,133 @@ static __maybe_unused irqreturn_t tegra20_mc_irq(int irq, 
void *data)
return IRQ_HANDLED;
 }
 
+static struct icc_node_data *
+tegra_mc_of_icc_xlate_extended(struct of_phandle_args *spec, void *data)
+{
+   struct icc_provider *provider = data;
+   unsigned int idx = spec->args[0];
+   struct icc_node_data *ndata;
+   struct icc_node *node;
+
+   list_for_each_entry(node, &provider->nodes, node_list) {
+   if (node->id != idx)
+   continue;
+
+   ndata = kzalloc(sizeof(*ndata), GFP_KERNEL);
+   if (!ndata)
+   return ERR_PTR(-ENOMEM);
+
+   ndata->node = node;
+
+   /* these clients are isochronous by default on all SoCs */
+   if (strstarts(node->name, "display") ||
+   strstarts(node->name, "ptc") ||
+   strstarts(node->name, "vi"))
+   ndata->tag = TEGRA_MC_ICC_TAG_ISO;
+
+   return ndata;
+   }
+
+   pr_err("%s: invalid client index %u\n", __func__, idx);
+
+   return ERR_PTR(-EINVAL);
+}
+
+/*
+ * Memory Controller (MC) has few Memory Clients that are issuing memory
+ * bandwidth allocation requests to the MC interconnect provider. The MC
+ * provider aggregates the requests and then sends the aggregated request
+ * up to the External Memory Controller (EMC) interconnect provider which
+ * re-configures hardware interface to External Memory (EMEM) in accordance
+ * to the required bandwidth. Each MC interconnect node represents an
+ * individual Memory Client.
+ *
+ * Memory interconnect topology:
+ *
+ *   ++
+ * ++||
+ * | TEXSRD +--->+|
+ * ++||
+ *   ||+-++--+
+ *...| MC +--->+ EMC +--->+ EMEM |
+ *   ||+-++--+
+ * ++||
+ * | DISP.. +--->+|
+ * ++||
+ *   ++
+ */
+static int tegra_mc_interconnect_setup(struct tegra_mc *mc)
+{
+   struct icc_node *node;
+   unsigned int i;
+   int err;
+
+   /* older device-trees don't have interconnect properties */
+   if (!of_find_property(mc->dev->of_node, "#interconnect-cells", NULL) ||
+   !mc->soc->icc_ops)
+   return 0;
+
+   mc->provider.dev = mc->dev;
+   mc->provider.data = &mc->provider;
+   mc->provider.set = mc->soc->icc_ops->set;
+   mc->provider.aggregate = mc->soc->icc_ops->aggregate;
+   mc->provider.xlate_extended = tegra_mc_of_icc_xlate_extended;
+
+   err = icc_provider_add(&mc->provider);
+   if (err)
+   goto err_msg;
+
+   /* create Memory Controller node */
+   node = icc_node_create(TEGRA_ICC_MC);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto del_provider;
+
+   node->name = "Memory Controller";
+   icc_node_add(node, &mc->provider);
+
+   /* link Memory Controller to External Memory Controller */
+   err = icc_link_create(node, TEGRA_ICC_EMC);
+   if (err)
+   goto remove_nodes;
+
+   for (i = 0; i < mc->soc->num_clients; i++) {
+   /* create MC client node */
+   node = icc_node_create(mc->soc->clients[i].id);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto remove_nodes;
+
+   node->name = mc->soc->clients[i].name;
+   icc_node_add(node, &mc->provider);
+
+   /* link Memory Client to Memory Controller */
+   err = icc_link_create(node, TEGRA_ICC_MC);
+   if (err)
+   goto remove_nodes;
+   }
+
+   /*
+* MC driver is registered too early, so early that

[PATCH v6 44/52] drm/tegra: dc: Support memory bandwidth management

2020-10-26 Thread Dmitry Osipenko
Display controller (DC) performs isochronous memory transfers, and thus,
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.

The Memory Controller drivers provide facility for memory bandwidth
management via interconnect API. This patch wires up the interconnect
API support to the DC driver and fixes distorted display output on
T30 Ouya, T124 TK1 and other Tegra devices.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/tegra/Kconfig |   1 +
 drivers/gpu/drm/tegra/dc.c| 330 ++
 drivers/gpu/drm/tegra/dc.h|   6 +
 drivers/gpu/drm/tegra/drm.c   |  14 ++
 drivers/gpu/drm/tegra/hub.c   |   3 +
 drivers/gpu/drm/tegra/plane.c | 122 +
 drivers/gpu/drm/tegra/plane.h |  15 ++
 7 files changed, 491 insertions(+)

diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 5043dcaf1cf9..1650a448eabd 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -9,6 +9,7 @@ config DRM_TEGRA
select DRM_MIPI_DSI
select DRM_PANEL
select TEGRA_HOST1X
+   select INTERCONNECT
select IOMMU_IOVA
select CEC_CORE if CEC_NOTIFIER
help
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 424ad60b4f38..986e7a0dde2a 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -616,6 +617,9 @@ static int tegra_plane_atomic_check(struct drm_plane *plane,
struct tegra_dc *dc = to_tegra_dc(state->crtc);
int err;
 
+   plane_state->peak_memory_bandwidth = 0;
+   plane_state->avg_memory_bandwidth = 0;
+
/* no need for further checks if the plane is being disabled */
if (!state->crtc)
return 0;
@@ -802,6 +806,12 @@ static struct drm_plane *tegra_primary_plane_create(struct 
drm_device *drm,
formats = dc->soc->primary_formats;
modifiers = dc->soc->modifiers;
 
+   err = tegra_plane_interconnect_init(plane);
+   if (err) {
+   kfree(plane);
+   return ERR_PTR(err);
+   }
+
err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
   &tegra_plane_funcs, formats,
   num_formats, modifiers, type, NULL);
@@ -833,9 +843,13 @@ static const u32 tegra_cursor_plane_formats[] = {
 static int tegra_cursor_atomic_check(struct drm_plane *plane,
 struct drm_plane_state *state)
 {
+   struct tegra_plane_state *plane_state = to_tegra_plane_state(state);
struct tegra_plane *tegra = to_tegra_plane(plane);
int err;
 
+   plane_state->peak_memory_bandwidth = 0;
+   plane_state->avg_memory_bandwidth = 0;
+
/* no need for further checks if the plane is being disabled */
if (!state->crtc)
return 0;
@@ -973,6 +987,12 @@ static struct drm_plane 
*tegra_dc_cursor_plane_create(struct drm_device *drm,
num_formats = ARRAY_SIZE(tegra_cursor_plane_formats);
formats = tegra_cursor_plane_formats;
 
+   err = tegra_plane_interconnect_init(plane);
+   if (err) {
+   kfree(plane);
+   return ERR_PTR(err);
+   }
+
err = drm_universal_plane_init(drm, &plane->base, possible_crtcs,
   &tegra_plane_funcs, formats,
   num_formats, NULL,
@@ -1087,6 +1107,12 @@ static struct drm_plane 
*tegra_dc_overlay_plane_create(struct drm_device *drm,
num_formats = dc->soc->num_overlay_formats;
formats = dc->soc->overlay_formats;
 
+   err = tegra_plane_interconnect_init(plane);
+   if (err) {
+   kfree(plane);
+   return ERR_PTR(err);
+   }
+
if (!cursor)
type = DRM_PLANE_TYPE_OVERLAY;
else
@@ -1204,6 +1230,7 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
 {
struct tegra_dc_state *state = to_dc_state(crtc->state);
struct tegra_dc_state *copy;
+   unsigned int i;
 
copy = kmalloc(sizeof(*copy), GFP_KERNEL);
if (!copy)
@@ -1215,6 +1242,9 @@ tegra_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
copy->div = state->div;
copy->planes = state->planes;
 
+   for (i = 0; i < ARRAY_SIZE(state->plane_peak_bw); i++)
+   copy->plane_peak_bw[i] = state->plane_peak_bw[i];
+
return ©->base;
 }
 
@@ -1741,6 +1771,104 @@ static int tegra_dc_wait_idle(struct tegra_dc *dc, 
unsigned long timeout)
return -ETIMEDOUT;
 }
 
+static void
+tegra_crtc_update_memory_bandwidth(struct drm_crtc *crtc,
+  struct drm

[PATCH v6 05/52] dt-bindings: memory: tegra20: mc: Document new interconnect property

2020-10-26 Thread Dmitry Osipenko
Memory controller is interconnected with memory clients and with the
External Memory Controller. Document new interconnect property which
turns memory controller into interconnect provider.

Acked-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra20-mc.txt  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
index e55328237df4..739b7c6f2e26 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt
@@ -16,6 +16,8 @@ Required properties:
   IOMMU specifier needed to encode an address. GART supports only a single
   address space that is shared by all devices, therefore no additional
   information needed for the address encoding.
+- #interconnect-cells : Should be 1. This cell represents memory client.
+  The assignments may be found in header file 
.
 
 Example:
mc: memory-controller@7000f000 {
@@ -27,6 +29,7 @@ Example:
interrupts = ;
#reset-cells = <1>;
#iommu-cells = <0>;
+   #interconnect-cells = <1>;
};
 
video-codec@6001a000 {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/1] video: fbdev: fix divide error in fbcon_switch

2020-10-26 Thread Saeed Mirzamohammadi
Thanks, adding stable.

> On Oct 22, 2020, at 12:34 AM, Thomas Zimmermann  wrote:
> 
> Hi
> 
> On 22.10.20 01:57, saeed.mirzamohamm...@oracle.com 
>  wrote:
>> From: Saeed Mirzamohammadi > >
>> 
>> This patch fixes the issue due to:
>> 
>> [   89.572883] divide_error:  [#1] SMP KASAN PTI
>> [   89.572897] CPU: 3 PID: 16083 Comm: repro Not tainted 
>> 5.9.0-rc7.20200930.rc1.allarch-19-g3e32d0d.syzk #5
>> [   89.572902] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>> 0.5.1 01/01/2011
>> [   89.572934] RIP: 0010:cirrusfb_check_var+0x84/0x1260
> 
> BTW, if you run qemu with cirrus, there's also a DRM driver named
> cirrus.ko. Might be a better choice than the old fbdev driver. If you
> just care about qemu, but not the actual graphics device, take a look at
> 
>  
> https://urldefense.com/v3/__https://www.kraxel.org/blog/2014/10/qemu-using-cirrus-considered-harmful/__;!!GqivPVa7Brio!LmgeM-pVBVH80uVELF1P1nBGAbAlhvnxKKE_ZrEc9d76AznvAAgP1FAp3_zNa2frKaIUZteK$
>  
> 
>  
> 
> Anyway, thanks for your patch.
> 
> Best regards
> Thomas
> 
>> 
>> The error happens when the pixels value is calculated before performing the 
>> sanity checks on bits_per_pixel.
>> A bits_per_pixel set to zero causes divide by zero error.
>> 
>> This patch moves the calculation after the sanity check.
>> 
>> Signed-off-by: Saeed Mirzamohammadi 
>> Tested-by: Saeed Mirzamohammadi 
>> ---
>> drivers/video/fbdev/cirrusfb.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/video/fbdev/cirrusfb.c b/drivers/video/fbdev/cirrusfb.c
>> index 15a9ee7cd734..a7749101b094 100644
>> --- a/drivers/video/fbdev/cirrusfb.c
>> +++ b/drivers/video/fbdev/cirrusfb.c
>> @@ -531,7 +531,7 @@ static int cirrusfb_check_var(struct fb_var_screeninfo 
>> *var,
>> {
>>  int yres;
>>  /* memory size in pixels */
>> -unsigned pixels = info->screen_size * 8 / var->bits_per_pixel;
>> +unsigned int pixels;
>>  struct cirrusfb_info *cinfo = info->par;
>> 
>>  switch (var->bits_per_pixel) {
>> @@ -573,6 +573,7 @@ static int cirrusfb_check_var(struct fb_var_screeninfo 
>> *var,
>>  return -EINVAL;
>>  }
>> 
>> +pixels = info->screen_size * 8 / var->bits_per_pixel;
>>  if (var->xres_virtual < var->xres)
>>  var->xres_virtual = var->xres;
>>  /* use highest possible virtual resolution */
>> 
> 
> -- 
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 42/52] memory: tegra124: Support interconnect framework

2020-10-26 Thread Dmitry Osipenko
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS.

Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig|   1 +
 drivers/memory/tegra/tegra124-emc.c | 186 +++-
 drivers/memory/tegra/tegra124.c |  31 +
 3 files changed, 216 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 94536dc4c495..3d1ef3ec1a2d 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -34,6 +34,7 @@ config TEGRA124_EMC
tristate "NVIDIA Tegra124 External Memory Controller driver"
default y
depends on TEGRA_MC && ARCH_TEGRA_124_SOC
+   select PM_OPP
help
  This driver is for the External Memory Controller (EMC) found on
  Tegra124 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/tegra124-emc.c 
b/drivers/memory/tegra/tegra124-emc.c
index 2814b1b4a1d9..bdce7bebe0ef 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -12,17 +12,21 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include 
 #include 
 
+#include "mc.h"
+
 #define EMC_FBIO_CFG5  0x104
 #defineEMC_FBIO_CFG5_DRAM_TYPE_MASK0x3
 #defineEMC_FBIO_CFG5_DRAM_TYPE_SHIFT   0
@@ -482,6 +486,9 @@ struct tegra_emc {
unsigned long min_rate;
unsigned long max_rate;
} debugfs;
+
+   struct opp_table *opp_table;
+   struct icc_provider provider;
 };
 
 /* Timing change sequence functions */
@@ -1177,6 +1184,169 @@ static void emc_debugfs_init(struct device *dev, struct 
tegra_emc *emc)
emc, &tegra_emc_debug_max_rate_fops);
 }
 
+static inline struct tegra_emc *
+to_tegra_emc_provider(struct icc_provider *provider)
+{
+   return container_of(provider, struct tegra_emc, provider);
+}
+
+static struct icc_node_data *
+emc_of_icc_xlate_extended(struct of_phandle_args *spec, void *data)
+{
+   struct icc_provider *provider = data;
+   struct icc_node_data *ndata;
+   struct icc_node *node;
+
+   /* External Memory is the only possible ICC route */
+   list_for_each_entry(node, &provider->nodes, node_list) {
+   if (node->id != TEGRA_ICC_EMEM)
+   continue;
+
+   ndata = kzalloc(sizeof(*ndata), GFP_KERNEL);
+   if (!ndata)
+   return ERR_PTR(-ENOMEM);
+
+   /*
+* SRC and DST nodes should have matching TAG in order to have
+* it set by default for a requested path.
+*/
+   ndata->tag = TEGRA_MC_ICC_TAG_ISO;
+   ndata->node = node;
+
+   return ndata;
+   }
+
+   return ERR_PTR(-EINVAL);
+}
+
+static int emc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   struct tegra_emc *emc = to_tegra_emc_provider(dst->provider);
+   unsigned long long peak_bw = icc_units_to_bps(dst->peak_bw);
+   unsigned long long avg_bw = icc_units_to_bps(dst->avg_bw);
+   unsigned long long rate = max(avg_bw, peak_bw);
+   unsigned int dram_data_bus_width_bytes = 8;
+   unsigned int ddr = 2;
+   int err;
+
+   /*
+* Tegra124 EMC runs on a clock rate of SDRAM bus. This means that
+* EMC clock rate is twice smaller than the peak data rate because
+* data is sample on both EMC clock edges.
+*/
+   do_div(rate, ddr * dram_data_bus_width_bytes);
+   rate = min_t(u64, rate, U32_MAX);
+
+   err = dev_pm_opp_set_rate(emc->dev, rate);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+static int tegra_emc_interconnect_init(struct tegra_emc *emc)
+{
+   const struct tegra_mc_soc *soc = emc->mc->soc;
+   struct icc_node *node;
+   int err;
+
+   emc->provider.dev = emc->dev;
+   emc->provider.set = emc_icc_set;
+   emc->provider.data = &emc->provider;
+   emc->provider.aggregate = soc->icc_ops->aggregate;
+   emc->provider.xlate_extended = emc_of_icc_xlate_extended;
+
+   err = icc_provider_add(&emc->provider);
+   if (err)
+   goto err_msg;
+
+   /* create External Memory Controller node */
+   node = icc_node_create(TEGRA_ICC_EMC);
+   err = PTR_ERR_OR_ZERO(node);
+   if (err)
+   goto del_provider;
+
+   node->name = "External Memory Controller";
+   icc_node_add(node, &emc->provider);
+
+   /* link External Memory Controller to External Memory (DRAM) */
+   err = icc_link_create(node, TEGRA_ICC_EMEM);
+   if (err)
+   goto remove_nodes;
+
+   /* create Exter

[PATCH v6 35/52] memory: tegra: Add missing latency allowness entry for Page Table Cache

2020-10-26 Thread Dmitry Osipenko
The PTC memory client misses the latency allowness entry and this patch
adds it.

This prevents erroneous clearing of MC_INTSTATUS 0x0 register during
of the LA programming in tegra_mc_setup_latency_allowance() due to the
missing entry. Note that this patch doesn't fix any known problems.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra114.c | 6 ++
 drivers/memory/tegra/tegra124.c | 6 ++
 drivers/memory/tegra/tegra30.c  | 6 ++
 3 files changed, 18 insertions(+)

diff --git a/drivers/memory/tegra/tegra114.c b/drivers/memory/tegra/tegra114.c
index 48ef01c3ff90..ed376ba2d2fe 100644
--- a/drivers/memory/tegra/tegra114.c
+++ b/drivers/memory/tegra/tegra114.c
@@ -15,6 +15,12 @@ static const struct tegra_mc_client tegra114_mc_clients[] = {
.id = 0x00,
.name = "ptcr",
.swgroup = TEGRA_SWGROUP_PTC,
+   .la = {
+   .reg = 0x34c,
+   .shift = 0,
+   .mask = 0xff,
+   .def = 0x0,
+   },
}, {
.id = 0x01,
.name = "display0a",
diff --git a/drivers/memory/tegra/tegra124.c b/drivers/memory/tegra/tegra124.c
index 0cede24479bf..e2389573d3c0 100644
--- a/drivers/memory/tegra/tegra124.c
+++ b/drivers/memory/tegra/tegra124.c
@@ -15,6 +15,12 @@ static const struct tegra_mc_client tegra124_mc_clients[] = {
.id = 0x00,
.name = "ptcr",
.swgroup = TEGRA_SWGROUP_PTC,
+   .la = {
+   .reg = 0x34c,
+   .shift = 0,
+   .mask = 0xff,
+   .def = 0x0,
+   },
}, {
.id = 0x01,
.name = "display0a",
diff --git a/drivers/memory/tegra/tegra30.c b/drivers/memory/tegra/tegra30.c
index fcdd812eed80..b1990b4133d8 100644
--- a/drivers/memory/tegra/tegra30.c
+++ b/drivers/memory/tegra/tegra30.c
@@ -36,6 +36,12 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.id = 0x00,
.name = "ptcr",
.swgroup = TEGRA_SWGROUP_PTC,
+   .la = {
+   .reg = 0x34c,
+   .shift = 0,
+   .mask = 0xff,
+   .def = 0x0,
+   },
}, {
.id = 0x01,
.name = "display0a",
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 02/52] soc/tegra: fuse: Export tegra_read_ram_code()

2020-10-26 Thread Dmitry Osipenko
The tegra_read_ram_code() is used by EMC drivers and we're going to make
these driver modular, hence this function needs to be exported.

Signed-off-by: Dmitry Osipenko 
---
 drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c 
b/drivers/soc/tegra/fuse/tegra-apbmisc.c
index cee207d10024..590c862538d0 100644
--- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
+++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
@@ -3,6 +3,7 @@
  * Copyright (c) 2014, NVIDIA CORPORATION.  All rights reserved.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -90,6 +91,7 @@ u32 tegra_read_ram_code(void)
 
return straps >> PMC_STRAPPING_OPT_A_RAM_CODE_SHIFT;
 }
+EXPORT_SYMBOL_GPL(tegra_read_ram_code);
 
 static const struct of_device_id apbmisc_match[] __initconst = {
{ .compatible = "nvidia,tegra20-apbmisc", },
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 36/52] memory: tegra: Add FIFO sizes to Tegra30 memory clients

2020-10-26 Thread Dmitry Osipenko
The latency allowness is calculated based on buffering capabilities of
memory clients. This patch adds FIFO sizes to the Tegra30 memory clients.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra30.c | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/drivers/memory/tegra/tegra30.c b/drivers/memory/tegra/tegra30.c
index b1990b4133d8..05780a0c6d39 100644
--- a/drivers/memory/tegra/tegra30.c
+++ b/drivers/memory/tegra/tegra30.c
@@ -42,6 +42,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x0,
},
+   .fifo_size = 16 * 2,
}, {
.id = 0x01,
.name = "display0a",
@@ -56,6 +57,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 128,
}, {
.id = 0x02,
.name = "display0ab",
@@ -70,6 +72,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 128,
}, {
.id = 0x03,
.name = "display0b",
@@ -84,6 +87,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 64,
}, {
.id = 0x04,
.name = "display0bb",
@@ -98,6 +102,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 64,
}, {
.id = 0x05,
.name = "display0c",
@@ -112,6 +117,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 128,
}, {
.id = 0x06,
.name = "display0cb",
@@ -126,6 +132,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 128,
}, {
.id = 0x07,
.name = "display1b",
@@ -140,6 +147,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 64,
}, {
.id = 0x08,
.name = "display1bb",
@@ -154,6 +162,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x4e,
},
+   .fifo_size = 16 * 64,
}, {
.id = 0x09,
.name = "eppup",
@@ -168,6 +177,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x17,
},
+   .fifo_size = 16 * 8,
}, {
.id = 0x0a,
.name = "g2pr",
@@ -182,6 +192,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x09,
},
+   .fifo_size = 16 * 64,
}, {
.id = 0x0b,
.name = "g2sr",
@@ -196,6 +207,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x09,
},
+   .fifo_size = 16 * 64,
}, {
.id = 0x0c,
.name = "mpeunifbr",
@@ -210,6 +222,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x50,
},
+   .fifo_size = 16 * 8,
}, {
.id = 0x0d,
.name = "viruv",
@@ -224,6 +237,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x2c,
},
+   .fifo_size = 16 * 8,
}, {
.id = 0x0e,
.name = "afir",
@@ -238,6 +252,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x10,
},
+   .fifo_size = 16 * 32,
}, {
.id = 0x0f,
.name = "avpcarm7r",
@@ -252,6 +267,7 @@ static const struct tegra_mc_client tegra30_mc_clients[] = {
.mask = 0xff,
.def = 0x04,
},
+   

[PATCH v6 38/52] memory: tegra30-emc: Continue probing if timings are missing in device-tree

2020-10-26 Thread Dmitry Osipenko
EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra30-emc.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index b31e11f95462..78f770cf0d64 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -988,6 +988,11 @@ static struct device_node 
*emc_find_node_by_ram_code(struct device *dev)
u32 value, ram_code;
int err;
 
+   if (of_get_child_count(dev->of_node) == 0) {
+   dev_info(dev, "device-tree doesn't have memory timings\n");
+   return NULL;
+   }
+
ram_code = tegra_read_ram_code();
 
for_each_child_of_node(dev->of_node, np) {
@@ -1057,6 +1062,9 @@ static long emc_round_rate(unsigned long rate,
struct tegra_emc *emc = arg;
unsigned int i;
 
+   if (!emc->num_timings)
+   return clk_get_rate(emc->clk);
+
min_rate = min(min_rate, emc->timings[emc->num_timings - 1].rate);
 
for (i = 0; i < emc->num_timings; i++) {
@@ -1262,16 +1270,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
struct tegra_emc *emc;
int err;
 
-   if (of_get_child_count(pdev->dev.of_node) == 0) {
-   dev_info(&pdev->dev,
-"device-tree node doesn't have memory timings\n");
-   return -ENODEV;
-   }
-
-   np = emc_find_node_by_ram_code(&pdev->dev);
-   if (!np)
-   return -EINVAL;
-
emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
if (!emc) {
of_node_put(np);
@@ -1285,10 +1283,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
emc->clk_nb.notifier_call = emc_clk_change_notify;
emc->dev = &pdev->dev;
 
-   err = emc_load_timings_from_dt(emc, np);
-   of_node_put(np);
-   if (err)
-   return err;
+   np = emc_find_node_by_ram_code(&pdev->dev);
+   if (np) {
+   err = emc_load_timings_from_dt(emc, np);
+   of_node_put(np);
+   if (err)
+   return err;
+   }
 
emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 33/52] memory: tegra20: Support interconnect framework

2020-10-26 Thread Dmitry Osipenko
Now Internal and External Memory Controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |   3 +-
 drivers/memory/tegra/mc.h  |  12 ++
 drivers/memory/tegra/tegra20-emc.c | 176 +
 drivers/memory/tegra/tegra20.c |  34 ++
 4 files changed, 224 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index ff426747cd7d..ac3dfe155505 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -11,7 +11,8 @@ config TEGRA_MC
 config TEGRA20_EMC
tristate "NVIDIA Tegra20 External Memory Controller driver"
default y
-   depends on ARCH_TEGRA_2x_SOC
+   depends on TEGRA_MC && ARCH_TEGRA_2x_SOC
+   select PM_OPP
help
  This driver is for the External Memory Controller (EMC) found on
  Tegra20 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/mc.h b/drivers/memory/tegra/mc.h
index abeb6a2cc36a..531fb4fb7b17 100644
--- a/drivers/memory/tegra/mc.h
+++ b/drivers/memory/tegra/mc.h
@@ -78,6 +78,18 @@
 
 #define MC_TIMING_UPDATE   BIT(0)
 
+static inline u32 tegra_mc_scale_percents(u64 val, unsigned int percents)
+{
+   val = val * percents;
+   do_div(val, 100);
+
+   /*
+* High freq + high boosting percent + large polling interval are
+* resulting in integer overflow when watermarks are calculated.
+*/
+   return min_t(u64, val, U32_MAX);
+}
+
 static inline u32 mc_readl(struct tegra_mc *mc, unsigned long offset)
 {
return readl_relaxed(mc->regs + offset);
diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 34085e26dced..69ccb3fe5b0b 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,11 +17,15 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
 #include 
 
+#include "mc.h"
+
 #define EMC_INTSTATUS  0x000
 #define EMC_INTMASK0x004
 #define EMC_DBG0x008
@@ -144,6 +149,9 @@ struct emc_timing {
 
 struct tegra_emc {
struct device *dev;
+   struct tegra_mc *mc;
+   struct opp_table *opp_table;
+   struct icc_provider provider;
struct notifier_block clk_nb;
struct clk *clk;
void __iomem *regs;
@@ -658,6 +666,166 @@ static void tegra_emc_debugfs_init(struct tegra_emc *emc)
emc, &tegra_emc_debug_max_rate_fops);
 }
 
+static inline struct tegra_emc *
+to_tegra_emc_provider(struct icc_provider *provider)
+{
+   return container_of(provider, struct tegra_emc, provider);
+}
+
+static struct icc_node_data *
+emc_of_icc_xlate_extended(struct of_phandle_args *spec, void *data)
+{
+   struct icc_provider *provider = data;
+   struct icc_node_data *ndata;
+   struct icc_node *node;
+
+   /* External Memory is the only possible ICC route */
+   list_for_each_entry(node, &provider->nodes, node_list) {
+   if (node->id != TEGRA_ICC_EMEM)
+   continue;
+
+   ndata = kzalloc(sizeof(*ndata), GFP_KERNEL);
+   if (!ndata)
+   return ERR_PTR(-ENOMEM);
+
+   /*
+* SRC and DST nodes should have matching TAG in order to have
+* it set by default for a requested path.
+*/
+   ndata->tag = TEGRA_MC_ICC_TAG_ISO;
+   ndata->node = node;
+
+   return ndata;
+   }
+
+   return ERR_PTR(-EINVAL);
+}
+
+static int emc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   struct tegra_emc *emc = to_tegra_emc_provider(dst->provider);
+   unsigned long long peak_bw = icc_units_to_bps(dst->peak_bw);
+   unsigned long long avg_bw = icc_units_to_bps(dst->avg_bw);
+   unsigned long long rate = max(avg_bw, peak_bw);
+   unsigned int dram_data_bus_width_bytes = 4;
+   long rounded_rate;
+   int err;
+
+   /*
+* Tegra20 EMC runs on x2 clock rate of SDRAM bus because DDR data
+* is sampled on both clock edges. This means that EMC clock rate
+* equals to the peak data rate.
+*/
+   do_div(rate, dram_data_bus_width_bytes);
+   rate = min_t(u64, rate, U32_MAX);
+
+   rounded_rate = emc_round_rate(rate, 0, U32_MAX, emc);
+   if (rounded_rate < 0)
+   return rounded_rate;
+
+   err = dev_pm_opp_set_rate(emc->dev, rounded_rate);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+static int tegra_emc_interconnect_init(struct tegra_emc *emc)
+

[PATCH v6 09/52] dt-bindings: memory: tegra30: mc: Document new interconnect property

2020-10-26 Thread Dmitry Osipenko
Memory controller is interconnected with memory clients and with the
External Memory Controller. Document new interconnect property which
turns memory controller into interconnect provider.

Acked-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra30-mc.yaml   | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
index 84fd57bcf0dc..5436e6d420bc 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
@@ -57,6 +57,9 @@ properties:
   "#iommu-cells":
 const: 1
 
+  "#interconnect-cells":
+const: 1
+
 patternProperties:
   "^emc-timings-[0-9]+$":
 type: object
@@ -120,6 +123,7 @@ required:
   - clock-names
   - "#reset-cells"
   - "#iommu-cells"
+  - "#interconnect-cells"
 
 additionalProperties: false
 
@@ -135,6 +139,7 @@ examples:
 
 #iommu-cells = <1>;
 #reset-cells = <1>;
+#interconnect-cells = <1>;
 
 emc-timings-1 {
 nvidia,ram-code = <1>;
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 28/52] memory: tegra: Add and use devm_tegra_get_memory_controller()

2020-10-26 Thread Dmitry Osipenko
Multiple Tegra drivers need to retrieve Memory Controller and there is
duplication of the retrieval code among the drivers. This patch removes
the duplication and fixes put_device() which was missed in the duplicated
code.

EMC drivers now use new common devm_tegra_get_memory_controller() helper
instead of opencoding the MC retrieval.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c| 48 
 drivers/memory/tegra/tegra124-emc.c  | 18 ++---
 drivers/memory/tegra/tegra210-emc-core.c | 39 +--
 drivers/memory/tegra/tegra30-emc.c   | 18 ++---
 include/soc/tegra/mc.h   | 10 +
 5 files changed, 74 insertions(+), 59 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index ec8403557ed4..12ea2c79205a 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -42,6 +42,54 @@ static const struct of_device_id tegra_mc_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
 
+static void tegra_mc_devm_action_put_device(void *data)
+{
+   struct tegra_mc *mc = data;
+
+   put_device(mc->dev);
+}
+
+/**
+ * devm_tegra_get_memory_controller() - get Tegra Memory Controller handle
+ * @dev: device pointer for the consumer device
+ *
+ * This function will search for the Memory Controller node in a device-tree
+ * and retrieve the Memory Controller handle.
+ *
+ * Return: ERR_PTR() on error or a valid pointer to a struct tegra_mc.
+ */
+struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
+{
+   struct platform_device *pdev;
+   struct device_node *np;
+   struct tegra_mc *mc;
+   int err;
+
+   np = of_parse_phandle(dev->of_node, "nvidia,memory-controller", 0);
+   if (!np)
+   return ERR_PTR(-ENOENT);
+
+   pdev = of_find_device_by_node(np);
+   of_node_put(np);
+   if (!pdev)
+   return ERR_PTR(-ENODEV);
+
+   mc = platform_get_drvdata(pdev);
+   if (!mc) {
+   put_device(&pdev->dev);
+   return ERR_PTR(-EPROBE_DEFER);
+   }
+
+   err = devm_add_action(dev, tegra_mc_devm_action_put_device, mc);
+   if (err) {
+   put_device(mc->dev);
+   return ERR_PTR(err);
+   }
+
+   return mc;
+}
+EXPORT_SYMBOL_GPL(devm_tegra_get_memory_controller);
+
 static int tegra_mc_block_dma_common(struct tegra_mc *mc,
 const struct tegra_mc_reset *rst)
 {
diff --git a/drivers/memory/tegra/tegra124-emc.c 
b/drivers/memory/tegra/tegra124-emc.c
index 76ace42a688a..b92259d4fbd1 100644
--- a/drivers/memory/tegra/tegra124-emc.c
+++ b/drivers/memory/tegra/tegra124-emc.c
@@ -1177,7 +1177,6 @@ static void emc_debugfs_init(struct device *dev, struct 
tegra_emc *emc)
 
 static int tegra_emc_probe(struct platform_device *pdev)
 {
-   struct platform_device *mc;
struct device_node *np;
struct tegra_emc *emc;
struct resource *res;
@@ -1195,20 +1194,9 @@ static int tegra_emc_probe(struct platform_device *pdev)
if (IS_ERR(emc->regs))
return PTR_ERR(emc->regs);
 
-   np = of_parse_phandle(pdev->dev.of_node, "nvidia,memory-controller", 0);
-   if (!np) {
-   dev_err(&pdev->dev, "could not get memory controller\n");
-   return -ENOENT;
-   }
-
-   mc = of_find_device_by_node(np);
-   of_node_put(np);
-   if (!mc)
-   return -ENOENT;
-
-   emc->mc = platform_get_drvdata(mc);
-   if (!emc->mc)
-   return -EPROBE_DEFER;
+   emc->mc = devm_tegra_get_memory_controller(&pdev->dev);
+   if (IS_ERR(emc->mc))
+   return PTR_ERR(emc->mc);
 
ram_code = tegra_read_ram_code();
 
diff --git a/drivers/memory/tegra/tegra210-emc-core.c 
b/drivers/memory/tegra/tegra210-emc-core.c
index cdd663ba4733..8c6ea634e05a 100644
--- a/drivers/memory/tegra/tegra210-emc-core.c
+++ b/drivers/memory/tegra/tegra210-emc-core.c
@@ -1828,7 +1828,6 @@ static int tegra210_emc_probe(struct platform_device 
*pdev)
 {
struct thermal_cooling_device *cd;
unsigned long current_rate;
-   struct platform_device *mc;
struct tegra210_emc *emc;
struct device_node *np;
unsigned int i;
@@ -1846,35 +1845,19 @@ static int tegra210_emc_probe(struct platform_device 
*pdev)
spin_lock_init(&emc->lock);
emc->dev = &pdev->dev;
 
-   np = of_parse_phandle(pdev->dev.of_node, "nvidia,memory-controller", 0);
-   if (!np) {
-   dev_err(&pdev->dev, "could not get memory controller\n");
-   return -ENOENT;
-   }
-
-   mc = of_find_device_by_node(np);
-   of_node_put(np);
-   if (!mc)
-   return -ENOENT;
-
-   emc->mc = platform_get_drvdata(mc);
-   if (!emc->mc) {
-   put_device(&mc->dev);
-   return -EPROBE_DEFER;
-   }
+   emc->mc = devm_tegra_get_memory_controller

Re: [RESEND PATCH v5 2/2] drm/bridge: hx8837: add a Himax HX8837 display controller driver

2020-10-26 Thread Lubomir Rintel
Hello Sam,

On Fri, Oct 16, 2020 at 10:07:34PM +0200, Sam Ravnborg wrote:
> Hi Lubomir.
> 
> On Sat, Sep 26, 2020 at 02:07:19AM +0200, Lubomir Rintel wrote:
> > Himax HX8837 is used to drive the LCD panel on OLPC platforms.
> > 
> > It controls the panel backlight and is able to refresh it when the LCD
> > controller (and the rest of the plaform) is powered off.
> > 
> > It also converts regular RGB color data from the LCDC so that it looks
> > reasonable on the OLPC LCD panel with a monochromatic layer on top of a
> > layer that can either reflect light (b/w sunlight readable mode) or light
> > pattern of red, green and blue pixels.
> > 
> > At this point, the driver is rather basic. The self-refresh mode is not
> > supported. There's no way of independently controlling the color swizzling,
> > antialiasing or b/w conversion, but it probably isn't too useful either.
> > 
> > There's another driver for the same hardware on OLPC XO-1.5 and XO-1.75
> > in drivers/staging/olpc_dcon. The display on that hardware doesn't utilize
> > DRM, so this driver doesn't replace the other one yet.
> > 
> > Signed-off-by: Lubomir Rintel 
> 
> A little feedback follows.
> 
>   Sam
> 
> > 
> > ---
> > Changes since v3:
> > - Added this patch, in place of a driver derived from
> >   drivers/staging/olpc_dcon. Compared to the previous one this
> >   implements the bare minimum, without the fancy stuff such as
> >   self-refresh that need more work/thinking.
> > 
> >  drivers/gpu/drm/bridge/Kconfig|  13 ++
> >  drivers/gpu/drm/bridge/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/himax-hx8837.c | 325 ++
> >  3 files changed, 339 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/himax-hx8837.c
> > 
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index ef91646441b16..6a923dd56c1d5 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -48,6 +48,19 @@ config DRM_DISPLAY_CONNECTOR
> >   on ARM-based platforms. Saying Y here when this driver is not needed
> >   will not cause any issue.
> >  
> > +config DRM_HIMAX_HX8837
> > +tristate "HiMax HX8837 OLPC Display Controller"
> > +   depends on OF
> > +   depends on OLPC || ARCH_MMP || COMPILE_TEST
> > +   select DRM_KMS_HELPER
> > +select BACKLIGHT_LCD_SUPPORT
> > +select BACKLIGHT_CLASS_DEVICE
> > +help
> > +  Enable support for HiMax HX8837 Display Controller as found in 
> > the
> > +  OLPC XO laptops.
> > +
> > +  If your laptop doesn't have green ears, say "N"
> 
> There is a mixture of tabs and spaces for indent - use tabs only (and
> tabs + 2 spaces for the help text).
> 
> 
> > +
> >  config DRM_LONTIUM_LT9611
> > tristate "Lontium LT9611 DSI/HDMI bridge"
> > select SND_SOC_HDMI_CODEC if SND_SOC
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 2b3aff104e466..21f72df3260db 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -2,6 +2,7 @@
> >  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
> >  obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
> >  obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
> > +obj-$(CONFIG_DRM_HIMAX_HX8837) += himax-hx8837.o
> Please add in alphabetical order.
> 
> >  obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
> >  obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
> >  obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
> > megachips-stdp-ge-b850v3-fw.o
> > diff --git a/drivers/gpu/drm/bridge/himax-hx8837.c 
> > b/drivers/gpu/drm/bridge/himax-hx8837.c
> > new file mode 100644
> > index 0..1e97fcb8ce505
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/himax-hx8837.c
> > @@ -0,0 +1,325 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * HiMax HX8837 Display Controller Driver
> > + *
> > + * Datasheet: 
> > http://wiki.laptop.org/images/0/09/DCON_datasheet_HX8837-A.pdf
> > + *
> > + * Copyright (C) 2020 Lubomir Rintel
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> In blocks are good but please add them in alphabetical order.
> 
> > +
> > +#define bridge_to_hx8837_priv(x) \
> > +   container_of(x, struct hx8837_priv, bridge)
> > +
> > +/* DCON registers */
> > +enum {
> > +   DCON_REG_ID = 0x00,
> > +   DCON_REG_MODE   = 0x01,
> > +   DCON_REG_HRES   = 0x02,
> > +   DCON_REG_HTOTAL = 0x03,
> > +   DCON_REG_HSYNC_WIDTH= 0x04,
> > +   DCON_REG_VRES   = 0x05,
> > +   DCON_REG_VTOTAL = 0x06,
> > +   DCON_REG_VSYNC_WIDTH= 0x07,
> > +   DCON_REG_TIMEOUT= 0x08,
> > +   DCON_REG_SCAN_INT   = 0x09,
> > +   DCON_REG_BRIGHT = 0x0a,
> > +   DCON_REG_MEM_OPT_A  = 0x41,
> > +   DCON_REG_MEM_OPT_B  = 0x42,
> > +};
> > +
> > +/* DCON_REG_M

[PATCH v6 18/52] dt-bindings: memory: tegra30: Add memory client IDs

2020-10-26 Thread Dmitry Osipenko
Each memory client have a unique hardware ID, this patch adds these IDs.

Acked-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 include/dt-bindings/memory/tegra30-mc.h | 67 +
 1 file changed, 67 insertions(+)

diff --git a/include/dt-bindings/memory/tegra30-mc.h 
b/include/dt-bindings/memory/tegra30-mc.h
index 169f005fbc78..930f708aca17 100644
--- a/include/dt-bindings/memory/tegra30-mc.h
+++ b/include/dt-bindings/memory/tegra30-mc.h
@@ -41,4 +41,71 @@
 #define TEGRA30_MC_RESET_VDE   16
 #define TEGRA30_MC_RESET_VI17
 
+#define TEGRA30_MC_PTCR0
+#define TEGRA30_MC_DISPLAY0A   1
+#define TEGRA30_MC_DISPLAY0AB  2
+#define TEGRA30_MC_DISPLAY0B   3
+#define TEGRA30_MC_DISPLAY0BB  4
+#define TEGRA30_MC_DISPLAY0C   5
+#define TEGRA30_MC_DISPLAY0CB  6
+#define TEGRA30_MC_DISPLAY1B   7
+#define TEGRA30_MC_DISPLAY1BB  8
+#define TEGRA30_MC_EPPUP   9
+#define TEGRA30_MC_G2PR10
+#define TEGRA30_MC_G2SR11
+#define TEGRA30_MC_MPEUNIFBR   12
+#define TEGRA30_MC_VIRUV   13
+#define TEGRA30_MC_AFIR14
+#define TEGRA30_MC_AVPCARM7R   15
+#define TEGRA30_MC_DISPLAYHC   16
+#define TEGRA30_MC_DISPLAYHCB  17
+#define TEGRA30_MC_FDCDRD  18
+#define TEGRA30_MC_FDCDRD2 19
+#define TEGRA30_MC_G2DR20
+#define TEGRA30_MC_HDAR21
+#define TEGRA30_MC_HOST1XDMAR  22
+#define TEGRA30_MC_HOST1XR 23
+#define TEGRA30_MC_IDXSRD  24
+#define TEGRA30_MC_IDXSRD2 25
+#define TEGRA30_MC_MPE_IPRED   26
+#define TEGRA30_MC_MPEAMEMRD   27
+#define TEGRA30_MC_MPECSRD 28
+#define TEGRA30_MC_PPCSAHBDMAR 29
+#define TEGRA30_MC_PPCSAHBSLVR 30
+#define TEGRA30_MC_SATAR   31
+#define TEGRA30_MC_TEXSRD  32
+#define TEGRA30_MC_TEXSRD2 33
+#define TEGRA30_MC_VDEBSEVR34
+#define TEGRA30_MC_VDEMBER 35
+#define TEGRA30_MC_VDEMCER 36
+#define TEGRA30_MC_VDETPER 37
+#define TEGRA30_MC_MPCORELPR   38
+#define TEGRA30_MC_MPCORER 39
+#define TEGRA30_MC_EPPU40
+#define TEGRA30_MC_EPPV41
+#define TEGRA30_MC_EPPY42
+#define TEGRA30_MC_MPEUNIFBW   43
+#define TEGRA30_MC_VIWSB   44
+#define TEGRA30_MC_VIWU45
+#define TEGRA30_MC_VIWV46
+#define TEGRA30_MC_VIWY47
+#define TEGRA30_MC_G2DW48
+#define TEGRA30_MC_AFIW49
+#define TEGRA30_MC_AVPCARM7W   50
+#define TEGRA30_MC_FDCDWR  51
+#define TEGRA30_MC_FDCDWR2 52
+#define TEGRA30_MC_HDAW53
+#define TEGRA30_MC_HOST1XW 54
+#define TEGRA30_MC_ISPW55
+#define TEGRA30_MC_MPCORELPW   56
+#define TEGRA30_MC_MPCOREW 57
+#define TEGRA30_MC_MPECSWR 58
+#define TEGRA30_MC_PPCSAHBDMAW 59
+#define TEGRA30_MC_PPCSAHBSLVW 60
+#define TEGRA30_MC_SATAW   61
+#define TEGRA30_MC_VDEBSEVW62
+#define TEGRA30_MC_VDEDBGW 63
+#define TEGRA30_MC_VDEMBEW 64
+#define TEGRA30_MC_VDETPMW 65
+
 #endif
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/2] drm: adi: axi-hdmi-tx: Add support for AXI HDMI TX IP core

2020-10-26 Thread Bogdan Togorean
From: Lars-Peter Clausen 

The AXI HDMI HDL driver is the driver for the HDL graphics core which is
used on various FPGA designs. It's mostly used to interface with the
ADV7511 bridge driver on some Zynq boards (e.g. ZC702 & ZedBoard).

Link: 
https://wiki.analog.com/resources/tools-software/linux-drivers/drm/hdl-axi-hdmi
Link: https://wiki.analog.com/resources/fpga/docs/axi_hdmi_tx

Signed-off-by: Lars-Peter Clausen 
Signed-off-by: Mike Looijmans 
Signed-off-by: Alexandru Ardelean 
Signed-off-by: Bogdan Togorean 
---
 drivers/gpu/drm/Kconfig   |   2 +
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/adi/Kconfig   |  14 +
 drivers/gpu/drm/adi/Makefile  |   4 +
 drivers/gpu/drm/adi/axi_hdmi_tx_crtc.c| 225 +++
 drivers/gpu/drm/adi/axi_hdmi_tx_drv.c | 196 +
 drivers/gpu/drm/adi/axi_hdmi_tx_drv.h |  38 +++
 drivers/gpu/drm/adi/axi_hdmi_tx_encoder.c | 331 ++
 8 files changed, 811 insertions(+)
 create mode 100755 drivers/gpu/drm/adi/Kconfig
 create mode 100644 drivers/gpu/drm/adi/Makefile
 create mode 100755 drivers/gpu/drm/adi/axi_hdmi_tx_crtc.c
 create mode 100755 drivers/gpu/drm/adi/axi_hdmi_tx_drv.c
 create mode 100755 drivers/gpu/drm/adi/axi_hdmi_tx_drv.h
 create mode 100755 drivers/gpu/drm/adi/axi_hdmi_tx_encoder.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 147d61b9674e..fca4c7e89fab 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -231,6 +231,8 @@ config DRM_SCHED
 
 source "drivers/gpu/drm/i2c/Kconfig"
 
+source "drivers/gpu/drm/adi/Kconfig"
+
 source "drivers/gpu/drm/arm/Kconfig"
 
 config DRM_RADEON
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 2f31579f91d4..6ef28d1422ee 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_DRM) += drm.o
 obj-$(CONFIG_DRM_MIPI_DBI) += drm_mipi_dbi.o
 obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
 obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
+obj-y  += adi/
 obj-y  += arm/
 obj-$(CONFIG_DRM_TTM)  += ttm/
 obj-$(CONFIG_DRM_SCHED)+= scheduler/
diff --git a/drivers/gpu/drm/adi/Kconfig b/drivers/gpu/drm/adi/Kconfig
new file mode 100755
index ..b4f8a06756ff
--- /dev/null
+++ b/drivers/gpu/drm/adi/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config DRM_ADI_AXI_HDMI_TX
+   tristate "DRM Support for Analog Devices HDMI FPGA platforms"
+   depends on DRM && OF
+   default n
+   select DRM_KMS_HELPER
+   select DRM_KMS_CMA_HELPER
+   select DMA_CMA if HAVE_DMA_CONTIGUOUS
+   select CMA if HAVE_DMA_CONTIGUOUS
+   help
+ Choose this option if you have an FPGA board using this AXI HDMI
+ Controller (aka GFX).
+
+ If M is selected this module will be called adi_axi_hdmi_tx.
diff --git a/drivers/gpu/drm/adi/Makefile b/drivers/gpu/drm/adi/Makefile
new file mode 100644
index ..2451cdc4480f
--- /dev/null
+++ b/drivers/gpu/drm/adi/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+adi_axi_hdmi_tx-y := axi_hdmi_tx_encoder.o axi_hdmi_tx_crtc.o axi_hdmi_tx_drv.o
+
+obj-$(CONFIG_DRM_ADI_AXI_HDMI_TX) += adi_axi_hdmi_tx.o
diff --git a/drivers/gpu/drm/adi/axi_hdmi_tx_crtc.c 
b/drivers/gpu/drm/adi/axi_hdmi_tx_crtc.c
new file mode 100755
index ..88702763fda5
--- /dev/null
+++ b/drivers/gpu/drm/adi/axi_hdmi_tx_crtc.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices AXI HDMI TX DRM driver.
+ *
+ * Copyright 2012-2020 Analog Devices Inc.
+ *  Author: Lars-Peter Clausen 
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "axi_hdmi_tx_drv.h"
+
+struct axi_hdmi_tx_crtc {
+   struct drm_crtc drm_crtc;
+   struct drm_plane plane;
+
+   struct dma_chan *dma;
+   struct dma_interleaved_template *dma_template;
+};
+
+static struct axi_hdmi_tx_crtc *plane_to_axi_hdmi_tx_crtc(struct drm_plane 
*plane)
+{
+   return container_of(plane, struct axi_hdmi_tx_crtc, plane);
+}
+
+static struct axi_hdmi_tx_crtc *to_axi_hdmi_tx_crtc(struct drm_crtc *crtc)
+{
+   return container_of(crtc, struct axi_hdmi_tx_crtc, drm_crtc);
+}
+
+static inline struct axi_hdmi_tx_private *drm_device_get_priv(struct 
drm_device *drm)
+{
+   return container_of(drm, struct axi_hdmi_tx_private, drm_dev);
+}
+
+static struct dma_async_tx_descriptor *axi_hdmi_tx_vdma_prep_interleaved_desc(
+   struct drm_plane *plane)
+{
+   struct axi_hdmi_tx_crtc *axi_hdmi_tx_crtc = 
plane_to_axi_hdmi_tx_crtc(plane);
+   struct drm_framebuffer *fb = plane->state->fb;
+   size_t offset, hw_row_size;
+   struct drm_gem_cma_object *obj;
+
+   obj = drm_fb_cma_get_gem_obj(plane->state->fb, 0);
+
+   offset = plane->state->crtc_x * fb->format->cpp[0] +
+   plane-

[PATCH v6 01/52] clk: tegra: Export Tegra20 EMC kernel symbols

2020-10-26 Thread Dmitry Osipenko
We're going to modularize Tegra EMC drivers and some of the EMC clk driver
symbols need to be exported, let's export them.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/clk-tegra20-emc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra20-emc.c 
b/drivers/clk/tegra/clk-tegra20-emc.c
index 03bf0009a33c..dd74b8543bf1 100644
--- a/drivers/clk/tegra/clk-tegra20-emc.c
+++ b/drivers/clk/tegra/clk-tegra20-emc.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -235,6 +236,7 @@ void 
tegra20_clk_set_emc_round_callback(tegra20_clk_emc_round_cb *round_cb,
emc->cb_arg = cb_arg;
}
 }
+EXPORT_SYMBOL_GPL(tegra20_clk_set_emc_round_callback);
 
 bool tegra20_clk_emc_driver_available(struct clk_hw *emc_hw)
 {
@@ -291,3 +293,4 @@ int tegra20_clk_prepare_emc_mc_same_freq(struct clk 
*emc_clk, bool same)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(tegra20_clk_prepare_emc_mc_same_freq);
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/2] drm: dt-bindings: adi: axi-hdmi-tx: Add DT bindings for axi-hdmi-tx

2020-10-26 Thread Bogdan Togorean
Add YAML device tree bindings for Analog Devices Inc. AXI HDMI TX
IP core DRM driver.

Signed-off-by: Bogdan Togorean 
---
 .../bindings/display/adi/adi,axi-hdmi-tx.yaml | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/adi/adi,axi-hdmi-tx.yaml

diff --git a/Documentation/devicetree/bindings/display/adi/adi,axi-hdmi-tx.yaml 
b/Documentation/devicetree/bindings/display/adi/adi,axi-hdmi-tx.yaml
new file mode 100644
index ..12a0ed9b187e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/adi/adi,axi-hdmi-tx.yaml
@@ -0,0 +1,72 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/adi/adi,axi-hdmi-tx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AXI HDMI TX HDL core
+
+maintainers:
+  - Bogdan Togorean 
+
+description: |
+  The AXI HDMI HDL driver is the driver for the HDL graphics core which
+  is used on various FPGA designs. It's mostly used to interface with
+  the ADV7511 driver on some Zynq boards (e.g. ZC702 & ZedBoard).
+
+properties:
+  compatible:
+const: adi,axi-hdmi-tx-1.00.a
+
+  reg:
+maxItems: 1
+
+  dmas:
+items:
+  - description: phandle to AXIS DMA controller
+maxItems: 1
+
+  dma-names:
+items:
+  - const: video
+
+  clocks:
+maxItems: 1
+description: phandle to the pixel clock
+
+  adi,is-rgb:
+type: boolean
+description: enable color space conversion
+
+  port:
+type: object
+description: |
+  Port as described in Documentation/devicetree/bindings/graph.txt.
+  Remote output connection to bridge driver
+
+required:
+  - compatible
+  - reg
+  - dmas
+  - dma-names
+  - clocks
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+axi_hdmi_tx: axi_hdmi@70e0 {
+compatible = "adi,axi-hdmi-tx-1.00.a";
+reg = <0x70e0 0x1>;
+dmas = <&hdmi_dma 0>;
+dma-names = "video";
+clocks = <&hdmi_clock>;
+
+port {
+axi_hdmi_out: endpoint {
+remote-endpoint = <&zynq_hdmi_in>;
+};
+};
+};
+...
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 26/52] ARM: tegra: Add DVFS properties to Tegra30 EMC and ACTMON device-tree nodes

2020-10-26 Thread Dmitry Osipenko
Add EMC OPP DVFS/DFS tables and interconnect paths that will be used for
dynamic memory bandwidth scaling based on memory utilization statistics.
Update board device-trees with optional EMC core supply and remove
unsupported OPPs.

Note that ACTMON watches all memory interconnect paths, but we use a
single CPU-READ interconnect path for driving memory bandwidth, for
simplicity.

Signed-off-by: Dmitry Osipenko 
---
 .../tegra30-asus-nexus7-grouper-common.dtsi   |  16 +
 .../arm/boot/dts/tegra30-peripherals-opp.dtsi | 383 ++
 arch/arm/boot/dts/tegra30.dtsi|   6 +
 3 files changed, 405 insertions(+)
 create mode 100644 arch/arm/boot/dts/tegra30-peripherals-opp.dtsi

diff --git a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi 
b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
index 88ca03f57b3b..8758bd39e0db 100644
--- a/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/tegra30-asus-nexus7-grouper-common.dtsi
@@ -956,6 +956,22 @@ pmc@7000e400 {
nvidia,sys-clock-req-active-high;
};
 
+   emc_opp_table0 {
+   /delete-node/ opp@75000,1300;
+   /delete-node/ opp@8,1300;
+   /delete-node/ opp@9,1350;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@75000;
+   /delete-node/ opp@8;
+   /delete-node/ opp@9;
+   };
+
+   memory-controller@7000f400 {
+   core-supply = <&vdd_core>;
+   };
+
ahub@7008 {
i2s@70080400 {
status = "okay";
diff --git a/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi 
b/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
new file mode 100644
index ..a6e171f65f6c
--- /dev/null
+++ b/arch/arm/boot/dts/tegra30-peripherals-opp.dtsi
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+   emc_icc_dvfs_opp_table: emc_opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@1275,950 {
+   opp-microvolt = <95 95 135>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0006>;
+   };
+
+   opp@1275,1000 {
+   opp-microvolt = <100 100 135>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0001>;
+   };
+
+   opp@1275,1250 {
+   opp-microvolt = <125 125 135>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0008>;
+   };
+
+   opp@2550,950 {
+   opp-microvolt = <95 95 135>;
+   opp-hz = /bits/ 64 <2550>;
+   opp-supported-hw = <0x0006>;
+   };
+
+   opp@2550,1000 {
+   opp-microvolt = <100 100 135>;
+   opp-hz = /bits/ 64 <2550>;
+   opp-supported-hw = <0x0001>;
+   };
+
+   opp@2550,1250 {
+   opp-microvolt = <125 125 135>;
+   opp-hz = /bits/ 64 <2550>;
+   opp-supported-hw = <0x0008>;
+   };
+
+   opp@2700,950 {
+   opp-microvolt = <95 95 135>;
+   opp-hz = /bits/ 64 <2700>;
+   opp-supported-hw = <0x0006>;
+   };
+
+   opp@2700,1000 {
+   opp-microvolt = <100 100 135>;
+   opp-hz = /bits/ 64 <2700>;
+   opp-supported-hw = <0x0001>;
+   };
+
+   opp@2700,1250 {
+   opp-microvolt = <125 125 135>;
+   opp-hz = /bits/ 64 <2700>;
+   opp-supported-hw = <0x0008>;
+   };
+
+   opp@5100,950 {
+   opp-microvolt = <95 95 135>;
+   opp-hz = /bits/ 64 <5100>;
+   opp-supported-hw = <0x0006>;
+   };
+
+   opp@5100,1000 {
+   opp-microvolt = <100 100 135>;
+   opp-hz = /bits/ 64 <5100>;
+   opp-supported-hw = <0x0001>;
+   };
+
+   opp@5100,1250 {
+   opp-microvolt = <125 125 135>;
+   opp-hz = /bits/ 64 <5100>;
+   opp-supported-hw = <0x0008>;
+   };
+
+   opp@5400,950 {
+   opp-microvolt = <95 95 135>;
+   opp-hz = /bits/ 64 <5400>;
+  

[PATCH v6 16/52] dt-bindings: host1x: Document new interconnect properties

2020-10-26 Thread Dmitry Osipenko
Most of Host1x devices have at least one memory client. These clients
are directly connected to the memory controller. The new interconnect
properties represent the memory client's connection to the memory
controller.

Reviewed-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 .../display/tegra/nvidia,tegra20-host1x.txt   | 68 +++
 1 file changed, 68 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt 
b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
index ac63ae4a3861..814246e51954 100644
--- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
@@ -20,6 +20,10 @@ Required properties:
 - reset-names: Must include the following entries:
   - host1x
 
+Each host1x client module having to perform DMA through the Memory Controller
+should have the interconnect endpoints set to the Memory Client and External
+Memory respectively.
+
 The host1x top-level node defines a number of children, each representing one
 of the following host1x client modules:
 
@@ -36,6 +40,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - mpe
 
+  Optional properties:
+  - interconnects: Must contain entry for the MPE memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
+
 - vi: video input
 
   Required properties:
@@ -113,6 +123,12 @@ of the following host1x client modules:
  Required properties:
  - remote-endpoint: phandle to vi port 'endpoint' node.
 
+  Optional properties:
+  - interconnects: Must contain entry for the VI memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
+
 - epp: encoder pre-processor
 
   Required properties:
@@ -126,6 +142,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - epp
 
+  Optional properties:
+  - interconnects: Must contain entry for the EPP memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
+
 - isp: image signal processor
 
   Required properties:
@@ -139,6 +161,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - isp
 
+  Optional properties:
+  - interconnects: Must contain entry for the ISP memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
+
 - gr2d: 2D graphics engine
 
   Required properties:
@@ -152,6 +180,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - 2d
 
+  Optional properties:
+  - interconnects: Must contain entry for the GR2D memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
+
 - gr3d: 3D graphics engine
 
   Required properties:
@@ -170,6 +204,12 @@ of the following host1x client modules:
 - 3d
 - 3d2 (Only required on SoCs with two 3D clocks)
 
+  Optional properties:
+  - interconnects: Must contain entry for the GR3D memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
+
 - dc: display controller
 
   Required properties:
@@ -197,6 +237,10 @@ of the following host1x client modules:
   - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
   - nvidia,edid: supplies a binary EDID blob
   - nvidia,panel: phandle of a display panel
+  - interconnects: Must contain entry for the DC memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation for information about
+available memory clients, see MEMORY CONTROLLER section.
 
 - hdmi: High Definition Multimedia Interface
 
@@ -345,6 +389,12 @@ of the following host1x client modules:
   - reset-names: Must include the following entries:
 - vic
 
+  Optional properties:
+  - interconnects: Must contain entry for the VIC memory clients.
+  - interconnect-names: Must include name of the interconnect path for each
+interconnect entry. Consult TRM documentation

[PATCH v6 07/52] dt-bindings: memory: tegra20: emc: Document OPP table and voltage regulator

2020-10-26 Thread Dmitry Osipenko
The SoC core voltage can't be changed without taking into account the
clock rate of External Memory Controller. Document OPP table that will
be used for dynamic voltage frequency scaling, taking into account EMC
voltage requirement. Document optional core voltage regulator, which is
optional because some boards may have a fixed core regulator and still
frequency scaling may be desired to have.

Signed-off-by: Dmitry Osipenko 
---
 .../memory-controllers/nvidia,tegra20-emc.txt  | 14 ++
 1 file changed, 14 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index 0a53adc6ccba..8d09b228ac42 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -14,11 +14,23 @@ Properties:
 - clocks : Should contain EMC clock.
 - nvidia,memory-controller : Phandle of the Memory Controller node.
 - #interconnect-cells : Should be 0.
+- core-supply: Phandle of voltage regulator of the SoC "core" power domain.
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
 
 Child device nodes describe the memory settings for different configurations 
and clock rates.
 
 Example:
 
+   emc_icc_dvfs_opp_table: emc_opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@3600 {
+   opp-microvolt = <95 95 130>;
+   opp-hz = /bits/ 64 <3600>;
+   };
+   ...
+   };
+
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
@@ -28,6 +40,8 @@ Example:
interrupts = <0 78 0x04>;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
nvidia,memory-controller = <&mc>;
+   core-supply = <&core_vdd_reg>;
+   operating-points-v2 = <&emc_icc_dvfs_opp_table>;
}
 
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 32/52] memory: tegra20-emc: Continue probing if timings are missing in device-tree

2020-10-26 Thread Dmitry Osipenko
EMC driver will become mandatory after turning it into interconnect
provider because interconnect users, like display controller driver, will
fail to probe using newer device-trees that have interconnect properties.
Thus make EMC driver to probe even if timings are missing in device-tree.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 34 ++
 1 file changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index ce22ca7cfb77..34085e26dced 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -383,6 +383,11 @@ tegra_emc_find_node_by_ram_code(struct device *dev)
u32 value, ram_code;
int err;
 
+   if (of_get_child_count(dev->of_node) == 0) {
+   dev_info(dev, "device-tree doesn't have memory timings\n");
+   return NULL;
+   }
+
if (!of_property_read_bool(dev->of_node, "nvidia,use-ram-code"))
return of_node_get(dev->of_node);
 
@@ -451,6 +456,9 @@ static long emc_round_rate(unsigned long rate,
struct tegra_emc *emc = arg;
unsigned int i;
 
+   if (!emc->num_timings)
+   return clk_get_rate(emc->clk);
+
min_rate = min(min_rate, emc->timings[emc->num_timings - 1].rate);
 
for (i = 0; i < emc->num_timings; i++) {
@@ -656,13 +664,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
struct tegra_emc *emc;
int irq, err;
 
-   /* driver has nothing to do in a case of memory timing absence */
-   if (of_get_child_count(pdev->dev.of_node) == 0) {
-   dev_info(&pdev->dev,
-"EMC device tree node doesn't have memory timings\n");
-   return 0;
-   }
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
dev_err(&pdev->dev, "interrupt not specified\n");
@@ -670,23 +671,20 @@ static int tegra_emc_probe(struct platform_device *pdev)
return irq;
}
 
-   np = tegra_emc_find_node_by_ram_code(&pdev->dev);
-   if (!np)
-   return -EINVAL;
-
emc = devm_kzalloc(&pdev->dev, sizeof(*emc), GFP_KERNEL);
-   if (!emc) {
-   of_node_put(np);
+   if (!emc)
return -ENOMEM;
-   }
 
emc->clk_nb.notifier_call = tegra_emc_clk_change_notify;
emc->dev = &pdev->dev;
 
-   err = tegra_emc_load_timings_from_dt(emc, np);
-   of_node_put(np);
-   if (err)
-   return err;
+   np = tegra_emc_find_node_by_ram_code(&pdev->dev);
+   if (np) {
+   err = tegra_emc_load_timings_from_dt(emc, np);
+   of_node_put(np);
+   if (err)
+   return err;
+   }
 
emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 06/52] dt-bindings: memory: tegra20: emc: Document new interconnect property

2020-10-26 Thread Dmitry Osipenko
External Memory Controller is interconnected with memory controller and
with external memory. Document new interconnect property which turns EMC
into interconnect provider.

Acked-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra20-emc.txt  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index 1b0d4417aad8..0a53adc6ccba 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -13,6 +13,7 @@ Properties:
 - interrupts : Should contain EMC General interrupt.
 - clocks : Should contain EMC clock.
 - nvidia,memory-controller : Phandle of the Memory Controller node.
+- #interconnect-cells : Should be 0.
 
 Child device nodes describe the memory settings for different configurations 
and clock rates.
 
@@ -21,6 +22,7 @@ Example:
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
+   #interconnect-cells = < 0 >;
compatible = "nvidia,tegra20-emc";
reg = <0x7000f400 0x400>;
interrupts = <0 78 0x04>;
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 14/52] dt-bindings: memory: tegra124: emc: Document OPP table and voltage regulator

2020-10-26 Thread Dmitry Osipenko
Document new OPP table and voltage regulator properties which are needed
for supporting dynamic voltage-frequency scaling of the memory controller.
Some boards may have a fixed core voltage regulator, hence it's optional
because frequency scaling still may be desired.

Signed-off-by: Dmitry Osipenko 
---
 .../memory-controllers/nvidia,tegra124-emc.yaml   | 11 +++
 1 file changed, 11 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
index ac00832ceac1..3f74cd173ba0 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
@@ -37,6 +37,15 @@ properties:
 description:
   phandle of the memory controller node
 
+  core-supply:
+description:
+  Phandle of voltage regulator of the SoC "core" power domain.
+
+  operating-points-v2:
+description:
+  Should contain freqs and voltages and opp-supported-hw property, which
+  is a bitfield indicating SoC speedo ID mask.
+
 patternProperties:
   "^emc-timings-[0-9]+$":
 type: object
@@ -359,6 +368,8 @@ examples:
 clock-names = "emc";
 
 nvidia,memory-controller = <&mc>;
+operating-points-v2 = <&dvfs_opp_table>;
+core-supply = <&vdd_core>;
 
 #interconnect-cells = <0>;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 04/52] dt-bindings: memory: tegra20: emc: Document nvidia, memory-controller property

2020-10-26 Thread Dmitry Osipenko
Tegra20 External Memory Controller talks to DRAM chips and it needs to be
reprogrammed when memory frequency changes. Tegra Memory Controller sits
behind EMC and these controllers are tightly coupled. This patch adds the
new phandle property which allows to properly express connection of EMC
and MC hardware in a device-tree, it also put the Tegra20 EMC binding on
par with Tegra30+ EMC bindings, which is handy to have.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra20-emc.txt  | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index 567cffd37f3f..1b0d4417aad8 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -12,6 +12,7 @@ Properties:
   irrespective of ram-code configuration.
 - interrupts : Should contain EMC General interrupt.
 - clocks : Should contain EMC clock.
+- nvidia,memory-controller : Phandle of the Memory Controller node.
 
 Child device nodes describe the memory settings for different configurations 
and clock rates.
 
@@ -24,6 +25,7 @@ Example:
reg = <0x7000f400 0x400>;
interrupts = <0 78 0x04>;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
+   nvidia,memory-controller = <&mc>;
}
 
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 22/52] ARM: tegra: Add interconnect properties to Tegra30 device-tree

2020-10-26 Thread Dmitry Osipenko
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra30.dtsi | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index aeae8c092d41..2caf6cc6f4b1 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -210,6 +210,17 @@ dc@5420 {
 
nvidia,head = <0>;
 
+   interconnects = <&mc TEGRA30_MC_DISPLAY0A &emc>,
+   <&mc TEGRA30_MC_DISPLAY0B &emc>,
+   <&mc TEGRA30_MC_DISPLAY1B &emc>,
+   <&mc TEGRA30_MC_DISPLAY0C &emc>,
+   <&mc TEGRA30_MC_DISPLAYHC &emc>;
+   interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -229,6 +240,17 @@ dc@5424 {
 
nvidia,head = <1>;
 
+   interconnects = <&mc TEGRA30_MC_DISPLAY0AB &emc>,
+   <&mc TEGRA30_MC_DISPLAY0BB &emc>,
+   <&mc TEGRA30_MC_DISPLAY1BB &emc>,
+   <&mc TEGRA30_MC_DISPLAY0CB &emc>,
+   <&mc TEGRA30_MC_DISPLAYHCB &emc>;
+   interconnect-names = "wina",
+"winb",
+"winb-vfilter",
+"winc",
+"cursor";
+
rgb {
status = "disabled";
};
@@ -748,15 +770,18 @@ mc: memory-controller@7000f000 {
 
#iommu-cells = <1>;
#reset-cells = <1>;
+   #interconnect-cells = <1>;
};
 
-   memory-controller@7000f400 {
+   emc: memory-controller@7000f400 {
compatible = "nvidia,tegra30-emc";
reg = <0x7000f400 0x400>;
interrupts = ;
clocks = <&tegra_car TEGRA30_CLK_EMC>;
 
nvidia,memory-controller = <&mc>;
+
+   #interconnect-cells = <0>;
};
 
fuse@7000f800 {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 13/52] dt-bindings: memory: tegra124: emc: Document new interconnect property

2020-10-26 Thread Dmitry Osipenko
External memory controller is interconnected with memory controller and
with external memory. Document new interconnect property which turns
External Memory Controller into interconnect provider.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra124-emc.yaml   | 7 +++
 1 file changed, 7 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
index 278549f9e051..ac00832ceac1 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml
@@ -29,6 +29,9 @@ properties:
 items:
   - const: emc
 
+  "#interconnect-cells":
+const: 0
+
   nvidia,memory-controller:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -327,6 +330,7 @@ required:
   - clocks
   - clock-names
   - nvidia,memory-controller
+  - "#interconnect-cells"
 
 additionalProperties: false
 
@@ -345,6 +349,7 @@ examples:
 
 #iommu-cells = <1>;
 #reset-cells = <1>;
+#interconnect-cells = <1>;
 };
 
 external-memory-controller@7001b000 {
@@ -355,6 +360,8 @@ examples:
 
 nvidia,memory-controller = <&mc>;
 
+#interconnect-cells = <0>;
+
 emc-timings-0 {
 nvidia,ram-code = <3>;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 48/52] PM / devfreq: tegra20: Relax Kconfig dependency

2020-10-26 Thread Dmitry Osipenko
The Tegra EMC driver now could be compiled as a loadable kernel module.
Currently devfreq driver depends on the EMC/MC drivers in Kconfig, and
thus, devfreq is forced to be a kernel module if EMC is compiled as a
module. This build dependency could be relaxed since devfreq driver
checks MC/EMC presence on probe, allowing kernel configuration where
devfreq is a built-in driver and EMC driver is a loadable module.
This change puts Tegra20 devfreq Kconfig entry on a par with the Tegra30
devfreq entry.

Acked-by: Chanwoo Choi 
Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 37dc40d1fcfb..0ee36ae2fa79 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -123,7 +123,7 @@ config ARM_TEGRA_DEVFREQ
 
 config ARM_TEGRA20_DEVFREQ
tristate "NVIDIA Tegra20 DEVFREQ Driver"
-   depends on (TEGRA_MC && TEGRA20_EMC) || COMPILE_TEST
+   depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
depends on COMMON_CLK
select DEVFREQ_GOV_SIMPLE_ONDEMAND
help
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 12/52] dt-bindings: memory: tegra124: mc: Document new interconnect property

2020-10-26 Thread Dmitry Osipenko
Memory controller is interconnected with memory clients and with the
External Memory Controller. Document new interconnect property which
turns memory controller into interconnect provider.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra124-mc.yaml  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
index 84d0339505b1..7b18b4d11e0a 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml
@@ -40,6 +40,9 @@ properties:
   "#iommu-cells":
 const: 1
 
+  "#interconnect-cells":
+const: 1
+
 patternProperties:
   "^emc-timings-[0-9]+$":
 type: object
@@ -104,6 +107,7 @@ required:
   - clock-names
   - "#reset-cells"
   - "#iommu-cells"
+  - "#interconnect-cells"
 
 additionalProperties: false
 
@@ -119,6 +123,7 @@ examples:
 
 #iommu-cells = <1>;
 #reset-cells = <1>;
+#interconnect-cells = <1>;
 
 emc-timings-3 {
 nvidia,ram-code = <3>;
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 39/52] memory: tegra30: Support interconnect framework

2020-10-26 Thread Dmitry Osipenko
Now Internal and External memory controllers are memory interconnection
providers. This allows us to use interconnect API for tuning of memory
configuration. EMC driver now supports OPPs and DVFS. MC driver now
supports tuning of memory arbitration latency, which needs to be done
for ISO memory clients, like a Display client for example.

Tested-by: Peter Geis 
Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |   1 +
 drivers/memory/tegra/tegra30-emc.c | 184 -
 drivers/memory/tegra/tegra30.c | 119 +++
 3 files changed, 302 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 61cdb5c04b18..73a5c5bca480 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -23,6 +23,7 @@ config TEGRA30_EMC
tristate "NVIDIA Tegra30 External Memory Controller driver"
default y
depends on TEGRA_MC && ARCH_TEGRA_3x_SOC
+   select PM_OPP
help
  This driver is for the External Memory Controller (EMC) found on
  Tegra30 chips. The EMC controls the external DRAM on the board.
diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index 78f770cf0d64..66eae944ca6d 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 
@@ -326,6 +329,8 @@ struct emc_timing {
 struct tegra_emc {
struct device *dev;
struct tegra_mc *mc;
+   struct opp_table *opp_table;
+   struct icc_provider provider;
struct notifier_block clk_nb;
struct clk *clk;
void __iomem *regs;
@@ -973,11 +978,12 @@ static int emc_load_timings_from_dt(struct tegra_emc *emc,
return err;
 
dev_info(emc->dev,
-"got %u timings for RAM code %u (min %luMHz max %luMHz)\n",
+"got %u timings for RAM code %u (min %luMHz max %luMHz) OPP HW 
ver. 0x%lx\n",
 emc->num_timings,
 tegra_read_ram_code(),
 emc->timings[0].rate / 100,
-emc->timings[emc->num_timings - 1].rate / 100);
+emc->timings[emc->num_timings - 1].rate / 100,
+BIT(tegra_sku_info.soc_speedo_id));
 
return 0;
 }
@@ -1264,6 +1270,172 @@ static void tegra_emc_debugfs_init(struct tegra_emc 
*emc)
emc, &tegra_emc_debug_max_rate_fops);
 }
 
+static inline struct tegra_emc *
+to_tegra_emc_provider(struct icc_provider *provider)
+{
+   return container_of(provider, struct tegra_emc, provider);
+}
+
+static struct icc_node_data *
+emc_of_icc_xlate_extended(struct of_phandle_args *spec, void *data)
+{
+   struct icc_provider *provider = data;
+   struct icc_node_data *ndata;
+   struct icc_node *node;
+
+   /* External Memory is the only possible ICC route */
+   list_for_each_entry(node, &provider->nodes, node_list) {
+   if (node->id != TEGRA_ICC_EMEM)
+   continue;
+
+   ndata = kzalloc(sizeof(*ndata), GFP_KERNEL);
+   if (!ndata)
+   return ERR_PTR(-ENOMEM);
+
+   /*
+* SRC and DST nodes should have matching TAG in order to have
+* it set by default for a requested path.
+*/
+   ndata->tag = TEGRA_MC_ICC_TAG_ISO;
+   ndata->node = node;
+
+   return ndata;
+   }
+
+   return ERR_PTR(-EINVAL);
+}
+
+static int emc_icc_set(struct icc_node *src, struct icc_node *dst)
+{
+   struct tegra_emc *emc = to_tegra_emc_provider(dst->provider);
+   unsigned long long peak_bw = icc_units_to_bps(dst->peak_bw);
+   unsigned long long avg_bw = icc_units_to_bps(dst->avg_bw);
+   unsigned long long rate = max(avg_bw, peak_bw);
+   unsigned int dram_data_bus_width_bytes = 4;
+   unsigned int ddr = 2;
+   long rounded_rate;
+   int err;
+
+   /*
+* Tegra30 EMC runs on a clock rate of SDRAM bus. This means that
+* EMC clock rate is twice smaller than the peak data rate because
+* data is sample on both EMC clock edges.
+*/
+   do_div(rate, ddr * dram_data_bus_width_bytes);
+   rate = min_t(u64, rate, U32_MAX);
+
+   rounded_rate = emc_round_rate(rate, 0, U32_MAX, emc);
+   if (rounded_rate < 0)
+   return rounded_rate;
+
+   err = dev_pm_opp_set_rate(emc->dev, rounded_rate);
+   if (err)
+   return err;
+
+   return 0;
+}
+
+static int tegra_emc_interconnect_init(struct tegra_emc *emc)
+{
+   const struct tegra_mc_soc *soc = emc->mc->soc;
+   struct icc_node *node;
+   int err;
+
+   emc->provider.dev = emc->dev;
+   emc->p

[PATCH v6 46/52] opp: Put interconnect paths outside of opp_table_lock

2020-10-26 Thread Dmitry Osipenko
This patch fixes lockup which happens when OPP table is released if
interconnect provider uses OPP in the icc_provider->set() callback
and bandwidth of the ICC path is set to 0 by the ICC core when path
is released. The icc_put() doesn't need the opp_table_lock protection,
hence let's move it outside of the lock in order to resolve the problem.

In particular this fixes tegra-devfreq driver lockup on trying to unload
the driver module. The devfreq driver uses OPP-bandwidth API and its ICC
provider also uses OPP for DVFS, hence they both take same opp_table_lock
when OPP table of the devfreq is released.

Signed-off-by: Dmitry Osipenko 
---
 drivers/opp/core.c | 21 ++---
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 2483e765318a..1134df360fe0 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -1187,12 +1187,6 @@ static void _opp_table_kref_release(struct kref *kref)
if (!IS_ERR(opp_table->clk))
clk_put(opp_table->clk);
 
-   if (opp_table->paths) {
-   for (i = 0; i < opp_table->path_count; i++)
-   icc_put(opp_table->paths[i]);
-   kfree(opp_table->paths);
-   }
-
WARN_ON(!list_empty(&opp_table->opp_list));
 
list_for_each_entry_safe(opp_dev, temp, &opp_table->dev_list, node) {
@@ -1209,9 +1203,22 @@ static void _opp_table_kref_release(struct kref *kref)
mutex_destroy(&opp_table->genpd_virt_dev_lock);
mutex_destroy(&opp_table->lock);
list_del(&opp_table->node);
-   kfree(opp_table);
 
mutex_unlock(&opp_table_lock);
+
+   /*
+* Interconnect provider may use OPP too, hence icc_put() needs to be
+* invoked outside of the opp_table_lock in order to prevent nested
+* locking which happens when bandwidth of the ICC path is set to 0
+* by ICC core on release of the path.
+*/
+   if (opp_table->paths) {
+   for (i = 0; i < opp_table->path_count; i++)
+   icc_put(opp_table->paths[i]);
+   kfree(opp_table->paths);
+   }
+
+   kfree(opp_table);
 }
 
 void dev_pm_opp_put_opp_table(struct opp_table *opp_table)
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 27/52] ARM: tegra: Add DVFS properties to Tegra124 EMC and ACTMON device-tree nodes

2020-10-26 Thread Dmitry Osipenko
Add EMC OPP DVFS/DFS tables and interconnect paths that will be used for
dynamic memory bandwidth scaling based on memory utilization statistics.
Remove unsupported EMC OPPs from board device-trees.

Note that ACTMON watches all memory interconnect paths, but we use a
single CPU-READ interconnect path for driving memory bandwidth, for
simplicity.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra124-apalis-emc.dtsi|   8 +
 .../arm/boot/dts/tegra124-jetson-tk1-emc.dtsi |   8 +
 arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi  |  10 +
 .../boot/dts/tegra124-peripherals-opp.dtsi| 419 ++
 arch/arm/boot/dts/tegra124.dtsi   |   6 +
 5 files changed, 451 insertions(+)
 create mode 100644 arch/arm/boot/dts/tegra124-peripherals-opp.dtsi

diff --git a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi 
b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
index 32401457ae71..29312cffdb3a 100644
--- a/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-apalis-emc.dtsi
@@ -5,6 +5,14 @@
  */
 
 / {
+   emc_opp_table0 {
+   /delete-node/ opp@12,1100;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@12;
+   };
+
clock@60006000 {
emc-timings-1 {
nvidia,ram-code = <1>;
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi 
b/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
index 861d3f22116b..fc8a089cd4dd 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi
@@ -1,5 +1,13 @@
 // SPDX-License-Identifier: GPL-2.0
 / {
+   emc_opp_table0 {
+   /delete-node/ opp@12,1100;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@12;
+   };
+
clock@60006000 {
emc-timings-3 {
nvidia,ram-code = <3>;
diff --git a/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi 
b/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
index c91647d13a50..20c1ae284280 100644
--- a/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
+++ b/arch/arm/boot/dts/tegra124-nyan-big-emc.dtsi
@@ -4,6 +4,16 @@ apbmisc@7800 {
nvidia,long-ram-code;
};
 
+   emc_opp_table0 {
+   /delete-node/ opp@92400,1100;
+   /delete-node/ opp@12,1100;
+   };
+
+   emc_opp_table1 {
+   /delete-node/ opp@92400;
+   /delete-node/ opp@12;
+   };
+
clock@60006000 {
emc-timings-1 {
nvidia,ram-code = <1>;
diff --git a/arch/arm/boot/dts/tegra124-peripherals-opp.dtsi 
b/arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
new file mode 100644
index ..d2b4d8e9cb13
--- /dev/null
+++ b/arch/arm/boot/dts/tegra124-peripherals-opp.dtsi
@@ -0,0 +1,419 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/ {
+   emc_icc_dvfs_opp_table: emc_opp_table0 {
+   compatible = "operating-points-v2";
+
+   opp@1275,800 {
+   opp-microvolt = <80 80 115>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0003>;
+   };
+
+   opp@1275,950 {
+   opp-microvolt = <95 95 115>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0008>;
+   };
+
+   opp@1275,1050 {
+   opp-microvolt = <105 105 115>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0010>;
+   };
+
+   opp@1275,1110 {
+   opp-microvolt = <111 111 115>;
+   opp-hz = /bits/ 64 <1275>;
+   opp-supported-hw = <0x0004>;
+   };
+
+   opp@2040,800 {
+   opp-microvolt = <80 80 115>;
+   opp-hz = /bits/ 64 <2040>;
+   opp-supported-hw = <0x0003>;
+   };
+
+   opp@2040,950 {
+   opp-microvolt = <95 95 115>;
+   opp-hz = /bits/ 64 <2040>;
+   opp-supported-hw = <0x0008>;
+   };
+
+   opp@2040,1050 {
+   opp-microvolt = <105 105 115>;
+   opp-hz = /bits/ 64 <2040>;
+   opp-supported-hw = <0x0010>;
+   };
+
+   opp@2040,1110 {
+   opp-microvolt = <111 111 115>;
+   opp-hz = /bits/ 64 <2040>;
+   opp-supported-hw = <0x0004>;
+   };
+
+   opp@4080,800 {
+   opp-microvolt = <80 80 115>;
+   opp-

[PATCH v6 03/52] dt-bindings: memory: tegra20: emc: Correct registers range in example

2020-10-26 Thread Dmitry Osipenko
There is superfluous zero in the registers base address and registers
size should be twice bigger.

Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra20-emc.txt  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index add95367640b..567cffd37f3f 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -21,7 +21,7 @@ Example:
#address-cells = < 1 >;
#size-cells = < 0 >;
compatible = "nvidia,tegra20-emc";
-   reg = <0x7000f4000 0x200>;
+   reg = <0x7000f400 0x400>;
interrupts = <0 78 0x04>;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
}
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 10/52] dt-bindings: memory: tegra30: emc: Document new interconnect property

2020-10-26 Thread Dmitry Osipenko
External memory controller is interconnected with memory controller and
with external memory. Document new interconnect property which turns
External Memory Controller into interconnect provider.

Acked-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 .../bindings/memory-controllers/nvidia,tegra30-emc.yaml | 6 ++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
index 112bae2fcbbd..c243986db420 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
@@ -31,6 +31,9 @@ properties:
   interrupts:
 maxItems: 1
 
+  "#interconnect-cells":
+const: 0
+
   nvidia,memory-controller:
 $ref: /schemas/types.yaml#/definitions/phandle
 description:
@@ -214,6 +217,7 @@ required:
   - interrupts
   - clocks
   - nvidia,memory-controller
+  - "#interconnect-cells"
 
 additionalProperties: false
 
@@ -227,6 +231,8 @@ examples:
 
 nvidia,memory-controller = <&mc>;
 
+#interconnect-cells = <0>;
+
 emc-timings-1 {
 nvidia,ram-code = <1>;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 37/52] memory: tegra30-emc: Make driver modular

2020-10-26 Thread Dmitry Osipenko
This patch adds modularization support to the Tegra30 EMC driver. Driver
now can be compiled as a loadable kernel module.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |  2 +-
 drivers/memory/tegra/mc.c  |  3 +++
 drivers/memory/tegra/tegra30-emc.c | 17 -
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index ac3dfe155505..61cdb5c04b18 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -20,7 +20,7 @@ config TEGRA20_EMC
  external memory.
 
 config TEGRA30_EMC
-   bool "NVIDIA Tegra30 External Memory Controller driver"
+   tristate "NVIDIA Tegra30 External Memory Controller driver"
default y
depends on TEGRA_MC && ARCH_TEGRA_3x_SOC
help
diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 53d61b05ebf8..15589bf8f5b6 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -346,6 +347,7 @@ int tegra_mc_write_emem_configuration(struct tegra_mc *mc, 
unsigned long rate)
 
return 0;
 }
+EXPORT_SYMBOL_GPL(tegra_mc_write_emem_configuration);
 
 unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc)
 {
@@ -357,6 +359,7 @@ unsigned int tegra_mc_get_emem_device_count(struct tegra_mc 
*mc)
 
return dram_count;
 }
+EXPORT_SYMBOL_GPL(tegra_mc_get_emem_device_count);
 
 static int load_one_timing(struct tegra_mc *mc,
   struct tegra_mc_timing *timing,
diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index 602dc4e08c61..b31e11f95462 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -1331,6 +1331,13 @@ static int tegra_emc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, emc);
tegra_emc_debugfs_init(emc);
 
+   /*
+* Don't allow the kernel module to be unloaded. Unloading adds some
+* extra complexity which doesn't really worth the effort in a case of
+* this driver.
+*/
+   try_module_get(THIS_MODULE);
+
return 0;
 
 unset_cb:
@@ -1381,6 +1388,7 @@ static const struct of_device_id tegra_emc_of_match[] = {
{ .compatible = "nvidia,tegra30-emc", },
{},
 };
+MODULE_DEVICE_TABLE(of, tegra_emc_of_match);
 
 static struct platform_driver tegra_emc_driver = {
.probe = tegra_emc_probe,
@@ -1391,9 +1399,8 @@ static struct platform_driver tegra_emc_driver = {
.suppress_bind_attrs = true,
},
 };
+module_platform_driver(tegra_emc_driver);
 
-static int __init tegra_emc_init(void)
-{
-   return platform_driver_register(&tegra_emc_driver);
-}
-subsys_initcall(tegra_emc_init);
+MODULE_AUTHOR("Dmitry Osipenko ");
+MODULE_DESCRIPTION("NVIDIA Tegra30 EMC driver");
+MODULE_LICENSE("GPL v2");
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 50/52] PM / devfreq: tegra30: Silence deferred probe error

2020-10-26 Thread Dmitry Osipenko
Tegra EMC driver was turned into a regular kernel driver, meaning that it
could be compiled as a loadable kernel module now. Hence EMC clock isn't
guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER.
Let's silence the deferred probe error.

Acked-by: Chanwoo Choi 
Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/tegra30-devfreq.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/devfreq/tegra30-devfreq.c 
b/drivers/devfreq/tegra30-devfreq.c
index f5e74c2ede85..3f732ab53573 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -801,10 +801,9 @@ static int tegra_devfreq_probe(struct platform_device 
*pdev)
}
 
tegra->emc_clock = devm_clk_get(&pdev->dev, "emc");
-   if (IS_ERR(tegra->emc_clock)) {
-   dev_err(&pdev->dev, "Failed to get emc clock\n");
-   return PTR_ERR(tegra->emc_clock);
-   }
+   if (IS_ERR(tegra->emc_clock))
+   return dev_err_probe(&pdev->dev, PTR_ERR(tegra->emc_clock),
+"Failed to get emc clock\n");
 
err = platform_get_irq(pdev, 0);
if (err < 0)
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 43/52] memory: tegra: Remove superfluous error messages around platform_get_irq()

2020-10-26 Thread Dmitry Osipenko
The platform_get_irq() prints error message telling that interrupt is
missing, hence there is no need to duplicated that message in the drivers.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c  | 4 +---
 drivers/memory/tegra/tegra20-emc.c | 1 -
 drivers/memory/tegra/tegra30-emc.c | 5 ++---
 3 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index 15589bf8f5b6..4a3bf08495c9 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -837,10 +837,8 @@ static int tegra_mc_probe(struct platform_device *pdev)
}
 
mc->irq = platform_get_irq(pdev, 0);
-   if (mc->irq < 0) {
-   dev_err(&pdev->dev, "interrupt not specified\n");
+   if (mc->irq < 0)
return mc->irq;
-   }
 
WARN(!mc->soc->client_id_mask, "missing client ID mask for this SoC\n");
 
diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 27242659dfd6..1519d6ce9b28 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -844,7 +844,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
 
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(&pdev->dev, "interrupt not specified\n");
dev_err(&pdev->dev, "please update your device tree\n");
return irq;
}
diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index 66eae944ca6d..d2515d7f3c0b 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -1472,10 +1472,9 @@ static int tegra_emc_probe(struct platform_device *pdev)
return err;
 
err = platform_get_irq(pdev, 0);
-   if (err < 0) {
-   dev_err(&pdev->dev, "interrupt not specified: %d\n", err);
+   if (err < 0)
return err;
-   }
+
emc->irq = err;
 
err = devm_request_irq(&pdev->dev, emc->irq, tegra_emc_isr, 0,
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 47/52] PM / devfreq: tegra20: Silence deferred probe error

2020-10-26 Thread Dmitry Osipenko
Tegra EMC driver was turned into a regular kernel driver, meaning that it
could be compiled as a loadable kernel module now. Hence EMC clock isn't
guaranteed to be available and clk_get("emc") may return -EPROBE_DEFER.
Let's silence the deferred probe error.

Acked-by: Chanwoo Choi 
Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/tegra20-devfreq.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/devfreq/tegra20-devfreq.c 
b/drivers/devfreq/tegra20-devfreq.c
index ff82bac9ee4e..fd801534771d 100644
--- a/drivers/devfreq/tegra20-devfreq.c
+++ b/drivers/devfreq/tegra20-devfreq.c
@@ -141,11 +141,9 @@ static int tegra_devfreq_probe(struct platform_device 
*pdev)
 
/* EMC is a system-critical clock that is always enabled */
tegra->emc_clock = devm_clk_get(&pdev->dev, "emc");
-   if (IS_ERR(tegra->emc_clock)) {
-   err = PTR_ERR(tegra->emc_clock);
-   dev_err(&pdev->dev, "failed to get emc clock: %d\n", err);
-   return err;
-   }
+   if (IS_ERR(tegra->emc_clock))
+   return dev_err_probe(&pdev->dev, PTR_ERR(tegra->emc_clock),
+"failed to get emc clock\n");
 
tegra->regs = mc->regs;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


RE: WARNING in dma_map_page_attrs

2020-10-26 Thread Parav Pandit
Hi Christoph,

> From: Jakub Kicinski 
> Sent: Saturday, October 24, 2020 11:45 PM
> 
> CC: rdma, looks like rdma from the stack trace
> 
> On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote:
> > syzbot has found a reproducer for the following issue on:
> >
> > HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of git://git.kernel.org/..

In [1] you mentioned that dma_mask should not be set for dma_virt_ops.
So patch [2] removed it.

But check to validate the dma mask for all dma_ops was added in [3].

What is the right way? Did I misunderstood your comment about dma_mask in [1]?

[1] https://www.spinics.net/lists/linux-rdma/msg96374.html
[2] e0477b34d9d ("RDMA: Explicitly pass in the dma_device to 
ib_register_device")
[3] f959dcd6ddfd ("dma-direct: Fix potential NULL pointer dereference")

> > WARNING: CPU: 1 PID: 8488 at kernel/dma/mapping.c:149
> > dma_map_page_attrs+0x493/0x700 kernel/dma/mapping.c:149 Modules
> linked in:
> >  dma_map_single_attrs include/linux/dma-mapping.h:279 [inline]
> > ib_dma_map_single include/rdma/ib_verbs.h:3967 [inline]
> >  ib_mad_post_receive_mads+0x23f/0xd60
> > drivers/infiniband/core/mad.c:2715
> >  ib_mad_port_start drivers/infiniband/core/mad.c:2862 [inline]
> > ib_mad_port_open drivers/infiniband/core/mad.c:3016 [inline]
> >  ib_mad_init_device+0x72b/0x1400 drivers/infiniband/core/mad.c:3092
> >  add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:680
> >  enable_device_and_get+0x1d5/0x3c0
> > drivers/infiniband/core/device.c:1301
> >  ib_register_device drivers/infiniband/core/device.c:1376 [inline]
> >  ib_register_device+0x7a7/0xa40 drivers/infiniband/core/device.c:1335
> >  rxe_register_device+0x46d/0x570
> > drivers/infiniband/sw/rxe/rxe_verbs.c:1182
> >  rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247
> >  rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:507
> >  rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline]
> >  rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250
> >  nldev_newlink+0x30e/0x540 drivers/infiniband/core/nldev.c:1555
> >  rdma_nl_rcv_msg+0x367/0x690 drivers/infiniband/core/netlink.c:195
> >  rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
> >  rdma_nl_rcv+0x2f2/0x440 drivers/infiniband/core/netlink.c:259
> >  netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
> >  netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330
> >  netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1919
> > sock_sendmsg_nosec net/socket.c:651 [inline]
> >  sock_sendmsg+0xcf/0x120 net/socket.c:671
> >  sys_sendmsg+0x6e8/0x810 net/socket.c:2353
> >  ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
> >  __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
> >  do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
> >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > RIP: 0033:0x443699
> > Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48
> > 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> > 01 f0 ff ff 0f 83 db 0d fc ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:7ffc067db418 EFLAGS: 0246 ORIG_RAX:
> 002e
> > RAX: ffda RBX: 0003 RCX: 00443699
> > RDX:  RSI: 22c0 RDI: 0003
> > RBP: 7ffc067db420 R08: 01bb R09: 01bb
> > R10:  R11: 0246 R12: 7ffc067db430
> > R13:  R14:  R15: 
> >

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 08/52] dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and statistics sub-device

2020-10-26 Thread Dmitry Osipenko
External Memory Controller can gather various hardware statistics that
are intended to be used for debugging purposes and for dynamic frequency
scaling of memory bus.

Document the new mfd-simple compatible and EMC statistics sub-device.
The subdev contains EMC DFS OPP table and interconnect paths to be used
for dynamic scaling of system's memory bandwidth based on EMC utilization
statistics.

Signed-off-by: Dmitry Osipenko 
---
 .../memory-controllers/nvidia,tegra20-emc.txt | 43 +--
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
index 8d09b228ac42..382aabcd6952 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt
@@ -4,7 +4,7 @@ Properties:
 - name : Should be emc
 - #address-cells : Should be 1
 - #size-cells : Should be 0
-- compatible : Should contain "nvidia,tegra20-emc".
+- compatible : Should contain "nvidia,tegra20-emc" and "simple-mfd".
 - reg : Offset and length of the register set for the device
 - nvidia,use-ram-code : If present, the sub-nodes will be addressed
   and chosen using the ramcode board selector. If omitted, only one
@@ -17,7 +17,8 @@ Properties:
 - core-supply: Phandle of voltage regulator of the SoC "core" power domain.
 - operating-points-v2: See ../bindings/opp/opp.txt for details.
 
-Child device nodes describe the memory settings for different configurations 
and clock rates.
+Child device nodes describe the memory settings for different configurations 
and clock rates,
+as well as EMC activity statistics collection sub-device.
 
 Example:
 
@@ -31,17 +32,34 @@ Example:
...
};
 
+   emc_bw_dfs_opp_table: emc_opp_table1 {
+   compatible = "operating-points-v2";
+
+   opp@3600 {
+   opp-hz = /bits/ 64 <3600>;
+   opp-peak-kBps = <144000>;
+   };
+   ...
+   };
+
memory-controller@7000f400 {
#address-cells = < 1 >;
#size-cells = < 0 >;
#interconnect-cells = < 0 >;
-   compatible = "nvidia,tegra20-emc";
+   compatible = "nvidia,tegra20-emc", "simple-mfd";
reg = <0x7000f400 0x400>;
interrupts = <0 78 0x04>;
clocks = <&tegra_car TEGRA20_CLK_EMC>;
nvidia,memory-controller = <&mc>;
core-supply = <&core_vdd_reg>;
operating-points-v2 = <&emc_icc_dvfs_opp_table>;
+
+   emc-stats {
+   compatible = "nvidia,tegra20-emc-statistics";
+   operating-points-v2 = <&emc_bw_dfs_opp_table>;
+   interconnects = <&mc TEGRA20_MC_MPCORER &emc>;
+   interconnect-names = "cpu";
+   };
}
 
 
@@ -120,3 +138,22 @@ Properties:
 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 >;
};
+
+
+
+Embedded Memory Controller statistics gathering sub-device
+
+EMC statistics subdev gathers information about hardware utilization
+which is intended to be used for debugging purposes and for dynamic
+frequency scaling based on the collected stats.
+
+Properties:
+- name : Should be emc-stats.
+- compatible : Should contain "nvidia,tegra20-emc-statistics".
+- operating-points-v2: See ../bindings/opp/opp.txt for details.
+- interconnects: Should contain entries for memory clients sitting on
+ MC->EMC memory interconnect path.
+- interconnect-names: Should include name of the interconnect path for each
+  interconnect entry. Consult TRM documentation for
+  information about available memory clients, see MEMORY
+  CONTROLLER section.
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 17/52] dt-bindings: memory: tegra20: Add memory client IDs

2020-10-26 Thread Dmitry Osipenko
Each memory client have a unique hardware ID, this patch adds these IDs.

Acked-by: Rob Herring 
Signed-off-by: Dmitry Osipenko 
---
 include/dt-bindings/memory/tegra20-mc.h | 53 +
 1 file changed, 53 insertions(+)

diff --git a/include/dt-bindings/memory/tegra20-mc.h 
b/include/dt-bindings/memory/tegra20-mc.h
index 35e131eee198..6f8829508ad0 100644
--- a/include/dt-bindings/memory/tegra20-mc.h
+++ b/include/dt-bindings/memory/tegra20-mc.h
@@ -18,4 +18,57 @@
 #define TEGRA20_MC_RESET_VDE   13
 #define TEGRA20_MC_RESET_VI14
 
+#define TEGRA20_MC_DISPLAY0A   0
+#define TEGRA20_MC_DISPLAY0AB  1
+#define TEGRA20_MC_DISPLAY0B   2
+#define TEGRA20_MC_DISPLAY0BB  3
+#define TEGRA20_MC_DISPLAY0C   4
+#define TEGRA20_MC_DISPLAY0CB  5
+#define TEGRA20_MC_DISPLAY1B   6
+#define TEGRA20_MC_DISPLAY1BB  7
+#define TEGRA20_MC_EPPUP   8
+#define TEGRA20_MC_G2PR9
+#define TEGRA20_MC_G2SR10
+#define TEGRA20_MC_MPEUNIFBR   11
+#define TEGRA20_MC_VIRUV   12
+#define TEGRA20_MC_AVPCARM7R   13
+#define TEGRA20_MC_DISPLAYHC   14
+#define TEGRA20_MC_DISPLAYHCB  15
+#define TEGRA20_MC_FDCDRD  16
+#define TEGRA20_MC_G2DR17
+#define TEGRA20_MC_HOST1XDMAR  18
+#define TEGRA20_MC_HOST1XR 19
+#define TEGRA20_MC_IDXSRD  20
+#define TEGRA20_MC_MPCORER 21
+#define TEGRA20_MC_MPE_IPRED   22
+#define TEGRA20_MC_MPEAMEMRD   23
+#define TEGRA20_MC_MPECSRD 24
+#define TEGRA20_MC_PPCSAHBDMAR 25
+#define TEGRA20_MC_PPCSAHBSLVR 26
+#define TEGRA20_MC_TEXSRD  27
+#define TEGRA20_MC_VDEBSEVR28
+#define TEGRA20_MC_VDEMBER 29
+#define TEGRA20_MC_VDEMCER 30
+#define TEGRA20_MC_VDETPER 31
+#define TEGRA20_MC_EPPU32
+#define TEGRA20_MC_EPPV33
+#define TEGRA20_MC_EPPY34
+#define TEGRA20_MC_MPEUNIFBW   35
+#define TEGRA20_MC_VIWSB   36
+#define TEGRA20_MC_VIWU37
+#define TEGRA20_MC_VIWV38
+#define TEGRA20_MC_VIWY39
+#define TEGRA20_MC_G2DW40
+#define TEGRA20_MC_AVPCARM7W   41
+#define TEGRA20_MC_FDCDWR  42
+#define TEGRA20_MC_HOST1XW 43
+#define TEGRA20_MC_ISPW44
+#define TEGRA20_MC_MPCOREW 45
+#define TEGRA20_MC_MPECSWR 46
+#define TEGRA20_MC_PPCSAHBDMAW 47
+#define TEGRA20_MC_PPCSAHBSLVW 48
+#define TEGRA20_MC_VDEBSEVW49
+#define TEGRA20_MC_VDEMBEW 50
+#define TEGRA20_MC_VDETPMW 51
+
 #endif
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 31/52] memory: tegra20-emc: Use devm_platform_ioremap_resource()

2020-10-26 Thread Dmitry Osipenko
Use devm_platform_ioremap_resource() helper which makes code a bit
cleaner.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 0baa6590adea..ce22ca7cfb77 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -654,7 +654,6 @@ static int tegra_emc_probe(struct platform_device *pdev)
 {
struct device_node *np;
struct tegra_emc *emc;
-   struct resource *res;
int irq, err;
 
/* driver has nothing to do in a case of memory timing absence */
@@ -689,8 +688,7 @@ static int tegra_emc_probe(struct platform_device *pdev)
if (err)
return err;
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   emc->regs = devm_ioremap_resource(&pdev->dev, res);
+   emc->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(emc->regs))
return PTR_ERR(emc->regs);
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 23/52] ARM: tegra: Add interconnect properties to Tegra124 device-tree

2020-10-26 Thread Dmitry Osipenko
Add interconnect properties to the Memory Controller, External Memory
Controller and the Display Controller nodes in order to describe hardware
interconnection.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra124.dtsi | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 64f488ba1e72..1801e30b1d3a 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -113,6 +113,19 @@ dc@5420 {
iommus = <&mc TEGRA_SWGROUP_DC>;
 
nvidia,head = <0>;
+
+   interconnects = <&mc TEGRA124_MC_DISPLAY0A &emc>,
+   <&mc TEGRA124_MC_DISPLAY0B &emc>,
+   <&mc TEGRA124_MC_DISPLAY0C &emc>,
+   <&mc TEGRA124_MC_DISPLAYHC &emc>,
+   <&mc TEGRA124_MC_DISPLAYD &emc>,
+   <&mc TEGRA124_MC_DISPLAYT &emc>;
+   interconnect-names = "wina",
+"winb",
+"winc",
+"cursor",
+"wind",
+"wint";
};
 
dc@5424 {
@@ -127,6 +140,15 @@ dc@5424 {
iommus = <&mc TEGRA_SWGROUP_DCB>;
 
nvidia,head = <1>;
+
+   interconnects = <&mc TEGRA124_MC_DISPLAY0AB &emc>,
+   <&mc TEGRA124_MC_DISPLAY0BB &emc>,
+   <&mc TEGRA124_MC_DISPLAY0CB &emc>,
+   <&mc TEGRA124_MC_DISPLAYHCB &emc>;
+   interconnect-names = "wina",
+"winb",
+"winc",
+"cursor";
};
 
hdmi: hdmi@5428 {
@@ -628,6 +650,7 @@ mc: memory-controller@70019000 {
 
#iommu-cells = <1>;
#reset-cells = <1>;
+   #interconnect-cells = <1>;
};
 
emc: external-memory-controller@7001b000 {
@@ -637,6 +660,8 @@ emc: external-memory-controller@7001b000 {
clock-names = "emc";
 
nvidia,memory-controller = <&mc>;
+
+   #interconnect-cells = <0>;
};
 
sata@7002 {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 40/52] memory: tegra124-emc: Make driver modular

2020-10-26 Thread Dmitry Osipenko
This patch adds modularization support to the Tegra124 EMC driver. Driver
now can be compiled as a loadable kernel module. Note that EMC clock must
be registered at clk-init time, otherwise PLLM will be disabled as unused
clock at boot time if EMC driver is compiled as a module, hence this patch
adds prepare/complete callbacks, similar to what is done for Tegra20/30
EMC drivers.

Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/Makefile   |  2 +-
 drivers/clk/tegra/clk-tegra124-emc.c | 41 
 drivers/clk/tegra/clk-tegra124.c | 27 --
 drivers/clk/tegra/clk.h  | 16 +++
 drivers/memory/tegra/Kconfig |  2 +-
 drivers/memory/tegra/tegra124-emc.c  | 31 ++---
 include/linux/clk/tegra.h|  9 ++
 include/soc/tegra/emc.h  | 16 ---
 8 files changed, 96 insertions(+), 48 deletions(-)
 delete mode 100644 include/soc/tegra/emc.h

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index eec2313fd37e..c3f6549be069 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_ARCH_TEGRA_3x_SOC)   += 
clk-tegra20-emc.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
 obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124.o
 obj-$(CONFIG_TEGRA_CLK_DFLL)   += clk-tegra124-dfll-fcpu.o
-obj-$(CONFIG_TEGRA124_EMC) += clk-tegra124-emc.o
+obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124-emc.o
 obj-$(CONFIG_ARCH_TEGRA_132_SOC)   += clk-tegra124.o
 obj-y  += cvb.o
 obj-$(CONFIG_ARCH_TEGRA_210_SOC)   += clk-tegra210.o
diff --git a/drivers/clk/tegra/clk-tegra124-emc.c 
b/drivers/clk/tegra/clk-tegra124-emc.c
index 745f9faa98d8..bdf6f4a51617 100644
--- a/drivers/clk/tegra/clk-tegra124-emc.c
+++ b/drivers/clk/tegra/clk-tegra124-emc.c
@@ -11,7 +11,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -21,7 +23,6 @@
 #include 
 
 #include 
-#include 
 
 #include "clk.h"
 
@@ -80,6 +81,9 @@ struct tegra_clk_emc {
int num_timings;
struct emc_timing *timings;
spinlock_t *lock;
+
+   tegra124_emc_prepare_timing_change_cb *prepare_timing_change;
+   tegra124_emc_complete_timing_change_cb *complete_timing_change;
 };
 
 /* Common clock framework callback implementations */
@@ -176,6 +180,9 @@ static struct tegra_emc *emc_ensure_emc_driver(struct 
tegra_clk_emc *tegra)
if (tegra->emc)
return tegra->emc;
 
+   if (!tegra->prepare_timing_change || !tegra->complete_timing_change)
+   return NULL;
+
if (!tegra->emc_node)
return NULL;
 
@@ -241,7 +248,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
 
div = timing->parent_rate / (timing->rate / 2) - 2;
 
-   err = tegra_emc_prepare_timing_change(emc, timing->rate);
+   err = tegra->prepare_timing_change(emc, timing->rate);
if (err)
return err;
 
@@ -259,7 +266,7 @@ static int emc_set_timing(struct tegra_clk_emc *tegra,
 
spin_unlock_irqrestore(tegra->lock, flags);
 
-   tegra_emc_complete_timing_change(emc, timing->rate);
+   tegra->complete_timing_change(emc, timing->rate);
 
clk_hw_reparent(&tegra->hw, __clk_get_hw(timing->parent));
clk_disable_unprepare(tegra->prev_parent);
@@ -473,8 +480,8 @@ static const struct clk_ops tegra_clk_emc_ops = {
.get_parent = emc_get_parent,
 };
 
-struct clk *tegra_clk_register_emc(void __iomem *base, struct device_node *np,
-  spinlock_t *lock)
+struct clk *tegra124_clk_register_emc(void __iomem *base, struct device_node 
*np,
+ spinlock_t *lock)
 {
struct tegra_clk_emc *tegra;
struct clk_init_data init;
@@ -538,3 +545,27 @@ struct clk *tegra_clk_register_emc(void __iomem *base, 
struct device_node *np,
 
return clk;
 };
+
+void tegra124_clk_set_emc_callbacks(tegra124_emc_prepare_timing_change_cb 
*prep_cb,
+   tegra124_emc_complete_timing_change_cb 
*complete_cb)
+{
+   struct clk *clk = __clk_lookup("emc");
+   struct tegra_clk_emc *tegra;
+   struct clk_hw *hw;
+
+   if (clk) {
+   hw = __clk_get_hw(clk);
+   tegra = container_of(hw, struct tegra_clk_emc, hw);
+
+   tegra->prepare_timing_change = prep_cb;
+   tegra->complete_timing_change = complete_cb;
+   }
+}
+EXPORT_SYMBOL_GPL(tegra124_clk_set_emc_callbacks);
+
+bool tegra124_clk_emc_driver_available(struct clk_hw *hw)
+{
+   struct tegra_clk_emc *tegra = container_of(hw, struct tegra_clk_emc, 
hw);
+
+   return tegra->prepare_timing_change && tegra->complete_timing_change;
+}
diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index e93131

[PATCH v6 34/52] memory: tegra20-emc: Don't parse emc-stats node

2020-10-26 Thread Dmitry Osipenko
EMC device-tree node now contains new emc-stats sub-node which needs to
be skipped when timing nodes are parsed by EMC driver, otherwise driver
will try to parse the emc-stats as a timing node and will error out.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/tegra20-emc.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 69ccb3fe5b0b..27242659dfd6 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -349,7 +349,10 @@ static int tegra_emc_load_timings_from_dt(struct tegra_emc 
*emc,
int child_count;
int err;
 
-   child_count = of_get_child_count(node);
+   child = of_find_node_by_name(node, "emc-stats");
+   of_node_put(child);
+
+   child_count = of_get_child_count(node) - (child ? 1 : 0);
if (!child_count) {
dev_err(emc->dev, "no memory timings in DT node: %pOF\n", node);
return -EINVAL;
@@ -364,6 +367,9 @@ static int tegra_emc_load_timings_from_dt(struct tegra_emc 
*emc,
timing = emc->timings;
 
for_each_child_of_node(node, child) {
+   if (of_device_is_compatible(child, 
"nvidia,tegra20-emc-statistics"))
+   continue;
+
err = load_one_timing_from_dt(emc, timing++, child);
if (err) {
of_node_put(child);
@@ -391,7 +397,11 @@ tegra_emc_find_node_by_ram_code(struct device *dev)
u32 value, ram_code;
int err;
 
-   if (of_get_child_count(dev->of_node) == 0) {
+   /* old device-trees don't have emc-stats node */
+   np = of_find_node_by_name(dev->of_node, "emc-stats");
+   of_node_put(np);
+
+   if (of_get_child_count(dev->of_node) == (np ? 1 : 0)) {
dev_info(dev, "device-tree doesn't have memory timings\n");
return NULL;
}
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 52/52] PM / devfreq: tegra30: Separate configurations per-SoC generation

2020-10-26 Thread Dmitry Osipenko
Previously we were using count-weight of the T124 for T30 in order to
get EMC clock rate that was reasonable for T30. In fact the count-weight
should be x2 times smaller on T30, but then devfreq was producing a bit
too low EMC clock rate for ISO memory clients, like display controller
for example.

Now both Tegra ACTMON and Tegra DRM display drivers support interconnect
framework and display driver tells to ICC what a minimum memory bandwidth
is needed, preventing FIFO underflows. Thus, now we can use a proper
count-weight value for Tegra30 and MC_ALL device config needs a bit more
aggressive boosting.

This patch adds a separate ACTMON driver configuration that is specific
to Tegra30.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/tegra30-devfreq.c | 68 ---
 1 file changed, 54 insertions(+), 14 deletions(-)

diff --git a/drivers/devfreq/tegra30-devfreq.c 
b/drivers/devfreq/tegra30-devfreq.c
index 1b0b91a71886..95aba89eae88 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -57,13 +57,6 @@
 #define ACTMON_BELOW_WMARK_WINDOW  3
 #define ACTMON_BOOST_FREQ_STEP 16000
 
-/*
- * Activity counter is incremented every 256 memory transactions, and each
- * transaction takes 4 EMC clocks for Tegra124; So the COUNT_WEIGHT is
- * 4 * 256 = 1024.
- */
-#define ACTMON_COUNT_WEIGHT0x400
-
 /*
  * ACTMON_AVERAGE_WINDOW_LOG2: default value for @DEV_CTRL_K_VAL, which
  * translates to 2 ^ (K_VAL + 1). ex: 2 ^ (6 + 1) = 128
@@ -111,7 +104,7 @@ enum tegra_actmon_device {
MCCPU,
 };
 
-static const struct tegra_devfreq_device_config actmon_device_configs[] = {
+static const struct tegra_devfreq_device_config tegra124_device_configs[] = {
{
/* MCALL: All memory accesses (including from the CPUs) */
.offset = 0x1c0,
@@ -133,6 +126,28 @@ static const struct tegra_devfreq_device_config 
actmon_device_configs[] = {
},
 };
 
+static const struct tegra_devfreq_device_config tegra30_device_configs[] = {
+   {
+   /* MCALL: All memory accesses (including from the CPUs) */
+   .offset = 0x1c0,
+   .irq_mask = 1 << 26,
+   .boost_up_coeff = 200,
+   .boost_down_coeff = 50,
+   .boost_up_threshold = 20,
+   .boost_down_threshold = 10,
+   },
+   {
+   /* MCCPU: memory accesses from the CPUs */
+   .offset = 0x200,
+   .irq_mask = 1 << 25,
+   .boost_up_coeff = 800,
+   .boost_down_coeff = 40,
+   .boost_up_threshold = 27,
+   .boost_down_threshold = 10,
+   .avg_dependency_threshold = 16000, /* 16MHz in kHz units */
+   },
+};
+
 /**
  * struct tegra_devfreq_device - state specific to an ACTMON device
  *
@@ -155,6 +170,12 @@ struct tegra_devfreq_device {
unsigned long target_freq;
 };
 
+struct tegra_devfreq_soc_data {
+   const struct tegra_devfreq_device_config *configs;
+   /* Weight value for count measurements */
+   unsigned int count_weight;
+};
+
 struct tegra_devfreq {
struct devfreq  *devfreq;
struct opp_table*opp_table;
@@ -171,11 +192,13 @@ struct tegra_devfreq {
struct delayed_work cpufreq_update_work;
struct notifier_block   cpu_rate_change_nb;
 
-   struct tegra_devfreq_device devices[ARRAY_SIZE(actmon_device_configs)];
+   struct tegra_devfreq_device 
devices[ARRAY_SIZE(tegra124_device_configs)];
 
unsigned intirq;
 
boolstarted;
+
+   const struct tegra_devfreq_soc_data *soc;
 };
 
 struct tegra_actmon_emc_ratio {
@@ -488,7 +511,7 @@ static void tegra_actmon_configure_device(struct 
tegra_devfreq *tegra,
tegra_devfreq_update_avg_wmark(tegra, dev);
tegra_devfreq_update_wmark(tegra, dev);
 
-   device_writel(dev, ACTMON_COUNT_WEIGHT, ACTMON_DEV_COUNT_WEIGHT);
+   device_writel(dev, tegra->soc->count_weight, ACTMON_DEV_COUNT_WEIGHT);
device_writel(dev, ACTMON_INTR_STATUS_CLEAR, ACTMON_DEV_INTR_STATUS);
 
val |= ACTMON_DEV_CTRL_ENB_PERIODIC;
@@ -781,6 +804,8 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
if (!tegra)
return -ENOMEM;
 
+   tegra->soc = of_device_get_match_data(&pdev->dev);
+
tegra->regs = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(tegra->regs))
return PTR_ERR(tegra->regs);
@@ -858,9 +883,9 @@ static int tegra_devfreq_probe(struct platform_device *pdev)
 
tegra->max_freq = rate / KHZ;
 
-   for (i = 0; i < ARRAY_SIZE(actmon_device_configs); i++) {
+   for (i = 0; i < ARRAY_SIZE(tegra124_device_configs); i++) {
dev = tegra->devices + i;
-   dev->confi

[PATCH v6 51/52] PM / devfreq: tegra30: Support interconnect and OPPs from device-tree

2020-10-26 Thread Dmitry Osipenko
This patch moves ACTMON driver away from generating OPP table by itself,
transitioning it to use the table which comes from device-tree. This
change breaks compatibility with older device-trees in order to bring
support for the interconnect framework to the driver. This is a mandatory
change which needs to be done in order to implement interconnect-based
memory DVFS. Users of legacy device-trees will get a message telling that
theirs DT needs to be upgraded. Now ACTMON issues memory bandwidth request
using dev_pm_opp_set_bw(), instead of driving EMC clock rate directly.

Tested-by: Peter Geis 
Tested-by: Nicolas Chauvet 
Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/tegra30-devfreq.c | 91 ---
 1 file changed, 48 insertions(+), 43 deletions(-)

diff --git a/drivers/devfreq/tegra30-devfreq.c 
b/drivers/devfreq/tegra30-devfreq.c
index 3f732ab53573..1b0b91a71886 100644
--- a/drivers/devfreq/tegra30-devfreq.c
+++ b/drivers/devfreq/tegra30-devfreq.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 
+#include 
+
 #include "governor.h"
 
 #define ACTMON_GLB_STATUS  0x0
@@ -155,6 +157,7 @@ struct tegra_devfreq_device {
 
 struct tegra_devfreq {
struct devfreq  *devfreq;
+   struct opp_table*opp_table;
 
struct reset_control*reset;
struct clk  *clock;
@@ -612,34 +615,19 @@ static void tegra_actmon_stop(struct tegra_devfreq *tegra)
 static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
 {
-   struct tegra_devfreq *tegra = dev_get_drvdata(dev);
-   struct devfreq *devfreq = tegra->devfreq;
struct dev_pm_opp *opp;
-   unsigned long rate;
-   int err;
+   int ret;
 
opp = devfreq_recommended_opp(dev, freq, flags);
if (IS_ERR(opp)) {
-   dev_err(dev, "Failed to find opp for %lu Hz\n", *freq);
+   dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
return PTR_ERR(opp);
}
-   rate = dev_pm_opp_get_freq(opp);
-   dev_pm_opp_put(opp);
-
-   err = clk_set_min_rate(tegra->emc_clock, rate * KHZ);
-   if (err)
-   return err;
-
-   err = clk_set_rate(tegra->emc_clock, 0);
-   if (err)
-   goto restore_min_rate;
 
-   return 0;
-
-restore_min_rate:
-   clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
+   ret = dev_pm_opp_set_bw(dev, opp);
+   dev_pm_opp_put(opp);
 
-   return err;
+   return ret;
 }
 
 static int tegra_devfreq_get_dev_status(struct device *dev,
@@ -655,7 +643,7 @@ static int tegra_devfreq_get_dev_status(struct device *dev,
stat->private_data = tegra;
 
/* The below are to be used by the other governors */
-   stat->current_frequency = cur_freq;
+   stat->current_frequency = cur_freq * KHZ;
 
actmon_dev = &tegra->devices[MCALL];
 
@@ -705,7 +693,7 @@ static int tegra_governor_get_target(struct devfreq 
*devfreq,
target_freq = max(target_freq, dev->target_freq);
}
 
-   *freq = target_freq;
+   *freq = target_freq * KHZ;
 
return 0;
 }
@@ -773,13 +761,22 @@ static struct devfreq_governor tegra_devfreq_governor = {
 
 static int tegra_devfreq_probe(struct platform_device *pdev)
 {
+   u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
struct tegra_devfreq_device *dev;
struct tegra_devfreq *tegra;
+   struct opp_table *opp_table;
struct devfreq *devfreq;
unsigned int i;
long rate;
int err;
 
+   /* legacy device-trees don't have OPP table and must be updated */
+   if (!device_property_present(&pdev->dev, "operating-points-v2")) {
+   dev_err(&pdev->dev, "OPP table not found, cannot continue\n");
+   dev_err(&pdev->dev, "please update your device tree\n");
+   return -ENODEV;
+   }
+
tegra = devm_kzalloc(&pdev->dev, sizeof(*tegra), GFP_KERNEL);
if (!tegra)
return -ENOMEM;
@@ -821,11 +818,29 @@ static int tegra_devfreq_probe(struct platform_device 
*pdev)
return err;
}
 
+   tegra->opp_table = dev_pm_opp_get_opp_table(&pdev->dev);
+   if (IS_ERR(tegra->opp_table))
+   return dev_err_probe(&pdev->dev, PTR_ERR(tegra->opp_table),
+"Failed to prepare OPP table\n");
+
+   opp_table = dev_pm_opp_set_supported_hw(&pdev->dev, &hw_version, 1);
+   err = PTR_ERR_OR_ZERO(opp_table);
+   if (err) {
+   dev_err(&pdev->dev, "Failed to set supported HW: %d\n", err);
+   goto put_table;
+   }
+
+   err = dev_pm_opp_of_add_table(&pdev->dev);
+   if (err) {
+   dev_err(&pdev->dev, "Failed to add OPP table: %d\n", err);
+   goto put_hw;
+   }
+
err = clk_prepare_enable(tegra->clock);
if (err) {
   

[PATCH v6 11/52] dt-bindings: memory: tegra30: emc: Document OPP table and voltage regulator

2020-10-26 Thread Dmitry Osipenko
Document new OPP table and voltage regulator properties which are needed
for supporting dynamic voltage-frequency scaling of the memory controller.
Some boards may have a fixed core voltage regulator, hence it's optional
because frequency scaling still may be desired.

Signed-off-by: Dmitry Osipenko 
---
 .../memory-controllers/nvidia,tegra30-emc.yaml   | 12 
 1 file changed, 12 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
index c243986db420..0a2e2c0d0fdd 100644
--- 
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
+++ 
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml
@@ -39,6 +39,15 @@ properties:
 description:
   Phandle of the Memory Controller node.
 
+  core-supply:
+description:
+  Phandle of voltage regulator of the SoC "core" power domain.
+
+  operating-points-v2:
+description:
+  Should contain freqs and voltages and opp-supported-hw property, which
+  is a bitfield indicating SoC speedo ID mask.
+
 patternProperties:
   "^emc-timings-[0-9]+$":
 type: object
@@ -218,6 +227,7 @@ required:
   - clocks
   - nvidia,memory-controller
   - "#interconnect-cells"
+  - operating-points-v2
 
 additionalProperties: false
 
@@ -230,6 +240,8 @@ examples:
 clocks = <&tegra_car 57>;
 
 nvidia,memory-controller = <&mc>;
+operating-points-v2 = <&dvfs_opp_table>;
+core-supply = <&vdd_core>;
 
 #interconnect-cells = <0>;
 
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v6 00/52] Introduce memory interconnect for NVIDIA Tegra SoCs

2020-10-26 Thread Dmitry Osipenko
Hello,

This series brings initial support for memory interconnect to Tegra20,
Tegra30 and Tegra124 SoCs.

For the starter only display controllers and devfreq devices are getting
interconnect API support, others could be supported later on. The display
controllers have the biggest demand for interconnect API right now because
dynamic memory frequency scaling can't be done safely without taking into
account bandwidth requirement from the displays. In particular this series
fixes distorted display output on T30 Ouya and T124 TK1 devices.

Changelog:

v6: - This series was massively reworked in comparison to v5, most of the
  patches that previously got r-b need a new round of a review (!).

- Added missed clk-rounding to the set() callback of EMC ICC providers.
  Now clk_set_min_rate() doesn't error out on rate overflow.

- Now peak bandwidth is properly taken into account by the set() callback
  of EMC ICC providers.

- EMC runs at 2x of the DRAM bus only on Tegra20, this now taken in account
  properly by the EMC ICC set() callbacks.

- ICC drivers use new icc_sync_state() and xlate_extended().

- ICC drivers support new TEGRA_MC_ICC_TAG_ISO for ICC paths, which
  conveys to ICC driver that memory path uses isochronous transfers.

- Added support for memory latency scaling to Tegra30 ICC provider.
  It's required for fixing display FIFO underflows on T30.

- Added basic interconnect support to Tegra124 drivers.

- Tegra20/30/124 EMC drivers now support voltage scaling using generic
  OPP API.

- The display bandwidth management is reworked and improved. It now
  supports both bandwidth and latency allocations. The nv-display is
  now also taken into account properly, i.e. it's kept untouched.
  The extra bandwidth reservation required for ISO clients is moved
  from DC driver to the ICC drivers.

- Dropped patch that tuned T20 display controller memory client because
  turned out that it kills ~30% of memory bandwidth. It should be possible
  to support client tuning, but it's too complicated for now.

- Corrected display's cursor and winb-vfilter ICC clients.
  The winb-vfilter was erroneously used in place of cursor's client
  in device-trees.

- Added devm_tegra_get_memory_controller() and switched drivers to
  use it.

- Device-tree OPP tables are now supported by memory and devfreq
  drivers.

- Tegra20-devfeq driver is reworked and now uses EMC-stats instead
  of IMC-stats (which are nearly identical modules) because previously
  I failed to understand how EMC-stats work and succeeded this time,
  thinking that it simply doesn't work. This removes a bit icky dependency
  on using both EMC and MC drivers simultaneously by the devfreq driver.

- Tegra20-devfeq driver now is a sub-device of the EMC, it also now uses
  interconnect API for driving memory bandwidth.

- Tegra30-devfreq got interconnect support.

- Devfreq patches now use dev_err_probe(), which was suggested by
  Chanwoo Choi.

- Added acks from Chanwoo Choi and Rob Herring to the reviewed and
  unchanged patches.

- Added tested-by from Peter Geis and Nicolas Chauvet, who tested this
  series on Ouya and TK1 devices, reporting that it fixes display
  corruption on these devices which happened due to insufficient memory
  bandwidth.

- Added patches to fix T20 EMC registers size.

- Fixed missing LA entry for PTC in the Tegra MC drivers.

- New and updated patches in v6:

dt-bindings: memory: tegra20: emc: Correct registers range in example
dt-bindings: memory: tegra20: emc: Document nvidia,memory-controller 
property
dt-bindings: memory: tegra20: emc: Document OPP table and voltage 
regulator
dt-bindings: memory: tegra20: emc: Document mfd-simple compatible and 
statistics sub-device
dt-bindings: memory: tegra30: emc: Document OPP table and voltage 
regulator
dt-bindings: memory: tegra124: mc: Document new interconnect property
dt-bindings: memory: tegra124: emc: Document new interconnect property
dt-bindings: memory: tegra124: emc: Document OPP table and voltage 
regulator
dt-bindings: tegra30-actmon: Document OPP and interconnect properties
dt-bindings: memory: tegra124: Add memory client IDs
ARM: tegra: Correct EMC registers size in Tegra20 device-tree
ARM: tegra: Add interconnect properties to Tegra124 device-tree
ARM: tegra: Add nvidia,memory-controller phandle to Tegra20 EMC 
device-tree
ARM: tegra: Add DVFS properties to Tegra20 EMC device-tree node
ARM: tegra: Add DVFS properties to Tegra30 EMC and ACTMON device-tree 
nodes
ARM: tegra: Add DVFS properties to Tegra124 EMC and ACTMON device-tree 
nodes
memory: tegra: Add and use devm_tegra_get_memory_controller()
memory: tegra-mc: Add interconnect f

[PATCH v6 49/52] PM / devfreq: tegra20: Convert to EMC_STAT driver, support interconnect and device-tree

2020-10-26 Thread Dmitry Osipenko
External (EMC) and Internal Memory Controllers (IMC) have a nearly
identical statistics gathering module. This patch switches driver to use
EMC_STAT instead of IMC_STAT and adds device-tree support which brings ICC
support and makes driver to use bandwidth OPPs defined in device-tree.

The previous tegra20-devfreq variant was depending on presence of both
EMC and IMC drivers simultaneously because it wasn't apparent how to use
EMC_STAT properly back in the day. Dependency on the IMC driver is gone
after this patch.

The older variant of the devfreq driver also isn't suitable anymore
because EMC got support for interconnect framework and DVFS, hence
tegra20-devfreq shouldn't drive the EMC clock directly, but use OPP
API for issuing memory bandwidth requests.

The polling interval is changed from 500ms to 30ms in order to improve
responsiveness of the system in general and because EMC clock is now
allowed to go lower than before since display driver supports ICC now
as well.

The parent EMC device is an MFD device now and tegra20-devfreq its
sub-device. Devfreq driver uses SYSCON API for retrieving regmap of the
EMC registers from the parent device.

Signed-off-by: Dmitry Osipenko 
---
 drivers/devfreq/Kconfig   |   1 +
 drivers/devfreq/tegra20-devfreq.c | 174 +-
 2 files changed, 75 insertions(+), 100 deletions(-)

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 0ee36ae2fa79..1bd225e571df 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -126,6 +126,7 @@ config ARM_TEGRA20_DEVFREQ
depends on ARCH_TEGRA_2x_SOC || COMPILE_TEST
depends on COMMON_CLK
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   select MFD_SYSCON
help
  This adds the DEVFREQ driver for the Tegra20 family of SoCs.
  It reads Memory Controller counters and adjusts the operating
diff --git a/drivers/devfreq/tegra20-devfreq.c 
b/drivers/devfreq/tegra20-devfreq.c
index fd801534771d..0a36b085d32a 100644
--- a/drivers/devfreq/tegra20-devfreq.c
+++ b/drivers/devfreq/tegra20-devfreq.c
@@ -7,180 +7,148 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
-#include 
-
 #include "governor.h"
 
-#define MC_STAT_CONTROL0x90
-#define MC_STAT_EMC_CLOCK_LIMIT0xa0
-#define MC_STAT_EMC_CLOCKS 0xa4
-#define MC_STAT_EMC_CONTROL0xa8
-#define MC_STAT_EMC_COUNT  0xb8
+#define EMC_STAT_CONTROL   0x160
+#define EMC_STAT_LLMC_CONTROL  0x178
+#define EMC_STAT_PWR_CLOCK_LIMIT   0x198
+#define EMC_STAT_PWR_CLOCKS0x19c
+#define EMC_STAT_PWR_COUNT 0x1a0
 
-#define EMC_GATHER_CLEAR   (1 << 8)
-#define EMC_GATHER_ENABLE  (3 << 8)
+#define EMC_PWR_GATHER_CLEAR   (1 << 8)
+#define EMC_PWR_GATHER_DISABLE (2 << 8)
+#define EMC_PWR_GATHER_ENABLE  (3 << 8)
 
 struct tegra_devfreq {
+   struct devfreq_simple_ondemand_data ondemand_data;
+   struct opp_table *opp_table;
struct devfreq *devfreq;
struct clk *emc_clock;
-   void __iomem *regs;
+   struct regmap *rmap;
 };
 
 static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
 {
-   struct tegra_devfreq *tegra = dev_get_drvdata(dev);
-   struct devfreq *devfreq = tegra->devfreq;
struct dev_pm_opp *opp;
-   unsigned long rate;
-   int err;
+   int ret;
 
opp = devfreq_recommended_opp(dev, freq, flags);
-   if (IS_ERR(opp))
+   if (IS_ERR(opp)) {
+   dev_err(dev, "failed to find opp for %lu Hz\n", *freq);
return PTR_ERR(opp);
+   }
 
-   rate = dev_pm_opp_get_freq(opp);
+   ret = dev_pm_opp_set_bw(dev, opp);
dev_pm_opp_put(opp);
 
-   err = clk_set_min_rate(tegra->emc_clock, rate);
-   if (err)
-   return err;
-
-   err = clk_set_rate(tegra->emc_clock, 0);
-   if (err)
-   goto restore_min_rate;
-
-   return 0;
-
-restore_min_rate:
-   clk_set_min_rate(tegra->emc_clock, devfreq->previous_freq);
-
-   return err;
+   return ret;
 }
 
 static int tegra_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *stat)
 {
struct tegra_devfreq *tegra = dev_get_drvdata(dev);
+   u32 count, clocks;
 
-   /*
-* EMC_COUNT returns number of memory events, that number is lower
-* than the number of clocks. Conversion ratio of 1/8 results in a
-* bit higher bandwidth than actually needed, it is good enough for
-* the time being because drivers don't support requesting minimum
-* needed memory bandwidth yet.
-*
-* 

Re: [PATCH 2/5] drm: Compile out legacy chunks from struct drm_device

2020-10-26 Thread Thomas Zimmermann
Hi

Am 23.10.20 um 14:28 schrieb Daniel Vetter:
> This means some very few #ifdef in code, but it allows us to
> enlist the compiler to make sure this stuff isn't used anymore.
> 
> More important, only legacy drivers change drm_device (for the
> legacy_dev_list shadow attach management), therefore this is
> prep to allow modern drivers to have a const driver struct. Which
> is nice, because there's a ton of function pointers in there.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Daniel Vetter 

Review-by: Thomas Zimmermann 

Sort of related: the implementation for KMS and UMS devices is more and
more distinct from each other. Did you ever consider going for separate
legacy helpers instead of mixing-in all these ifdefs?

Best regards
Thomas

> ---
>  drivers/gpu/drm/drm_file.c   |  2 ++
>  drivers/gpu/drm/drm_vblank.c | 15 ---
>  include/drm/drm_drv.h|  2 ++
>  3 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 0ac4566ae3f4..b50380fa80ce 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -258,9 +258,11 @@ void drm_file_free(struct drm_file *file)
> (long)old_encode_dev(file->minor->kdev->devt),
> atomic_read(&dev->open_count));
>  
> +#ifdef CONFIG_DRM_LEGACY
>   if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
>   dev->driver->preclose)
>   dev->driver->preclose(dev, file);
> +#endif
>  
>   if (drm_core_check_feature(dev, DRIVER_LEGACY))
>   drm_legacy_lock_release(dev, file->filp);
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index ba7e741764aa..15e5ea436434 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -210,9 +210,12 @@ static u32 __get_vblank_counter(struct drm_device *dev, 
> unsigned int pipe)
>  
>   if (crtc->funcs->get_vblank_counter)
>   return crtc->funcs->get_vblank_counter(crtc);
> - } else if (dev->driver->get_vblank_counter) {
> + }
> +#ifdef CONFIG_DRM_LEGACY
> + else if (dev->driver->get_vblank_counter) {
>   return dev->driver->get_vblank_counter(dev, pipe);
>   }
> +#endif
>  
>   return drm_vblank_no_hw_counter(dev, pipe);
>  }
> @@ -430,9 +433,12 @@ static void __disable_vblank(struct drm_device *dev, 
> unsigned int pipe)
>  
>   if (crtc->funcs->disable_vblank)
>   crtc->funcs->disable_vblank(crtc);
> - } else {
> + }
> +#ifdef CONFIG_DRM_LEGACY
> + else {
>   dev->driver->disable_vblank(dev, pipe);
>   }
> +#endif
>  }
>  
>  /*
> @@ -1097,9 +1103,12 @@ static int __enable_vblank(struct drm_device *dev, 
> unsigned int pipe)
>  
>   if (crtc->funcs->enable_vblank)
>   return crtc->funcs->enable_vblank(crtc);
> - } else if (dev->driver->enable_vblank) {
> + }
> +#ifdef CONFIG_DRM_LEGACY
> + else if (dev->driver->enable_vblank) {
>   return dev->driver->enable_vblank(dev, pipe);
>   }
> +#endif
>  
>   return -EINVAL;
>  }
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index c6d17550efc9..7af220226a25 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -498,6 +498,7 @@ struct drm_driver {
>*/
>   const struct file_operations *fops;
>  
> +#ifdef CONFIG_DRM_LEGACY
>   /* Everything below here is for legacy driver, never use! */
>   /* private: */
>  
> @@ -512,6 +513,7 @@ struct drm_driver {
>   int (*enable_vblank)(struct drm_device *dev, unsigned int pipe);
>   void (*disable_vblank)(struct drm_device *dev, unsigned int pipe);
>   int dev_priv_size;
> +#endif
>  };
>  
>  void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 4/5] drm: Allow const struct drm_driver

2020-10-26 Thread Thomas Zimmermann
Hi

Am 23.10.20 um 14:28 schrieb Daniel Vetter:
> It's nice if a big function/ioctl table like this is const. Only
> downside here is that we need a few more #ifdef to paper over the
> differences when CONFIG_DRM_LEGACY is enabled. Maybe provides more
> motivation to sunset that horror show :-)
> 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Daniel Vetter 

I very much welcome the change, although the code is *really* ugly.

Acked-by: Thomas Zimmermann 

> ---
>  drivers/gpu/drm/drm_drv.c | 15 ++-
>  include/drm/drm_device.h  |  4 
>  include/drm/drm_drv.h |  5 +++--
>  3 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 457ac0f82be2..94d2c41115b8 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -574,7 +574,7 @@ static void drm_dev_init_release(struct drm_device *dev, 
> void *res)
>  }
>  
>  static int drm_dev_init(struct drm_device *dev,
> - struct drm_driver *driver,
> + const struct drm_driver *driver,
>   struct device *parent)
>  {
>   int ret;
> @@ -589,7 +589,11 @@ static int drm_dev_init(struct drm_device *dev,
>  
>   kref_init(&dev->ref);
>   dev->dev = get_device(parent);
> +#ifdef CONFIG_DRM_LEGACY
> + dev->driver = (struct drm_driver *) driver;
> +#else
>   dev->driver = driver;
> +#endif
>  
>   INIT_LIST_HEAD(&dev->managed.resources);
>   spin_lock_init(&dev->managed.lock);
> @@ -663,7 +667,7 @@ static void devm_drm_dev_init_release(void *data)
>  
>  static int devm_drm_dev_init(struct device *parent,
>struct drm_device *dev,
> -  struct drm_driver *driver)
> +  const struct drm_driver *driver)
>  {
>   int ret;
>  
> @@ -678,7 +682,8 @@ static int devm_drm_dev_init(struct device *parent,
>   return ret;
>  }
>  
> -void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> +void *__devm_drm_dev_alloc(struct device *parent,
> +const struct drm_driver *driver,
>  size_t size, size_t offset)
>  {
>   void *container;
> @@ -713,7 +718,7 @@ EXPORT_SYMBOL(__devm_drm_dev_alloc);
>   * RETURNS:
>   * Pointer to new DRM device, or ERR_PTR on failure.
>   */
> -struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> +struct drm_device *drm_dev_alloc(const struct drm_driver *driver,
>struct device *parent)
>  {
>   struct drm_device *dev;
> @@ -858,7 +863,7 @@ static void remove_compat_control_link(struct drm_device 
> *dev)
>   */
>  int drm_dev_register(struct drm_device *dev, unsigned long flags)
>  {
> - struct drm_driver *driver = dev->driver;
> + const struct drm_driver *driver = dev->driver;
>   int ret;
>  
>   if (!driver->load)
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index f4f68e7a9149..2c361964aee7 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -83,7 +83,11 @@ struct drm_device {
>   } managed;
>  
>   /** @driver: DRM driver managing the device */
> +#ifdef CONFIG_DRM_LEGACY
>   struct drm_driver *driver;
> +#else
> + const struct drm_driver *driver;
> +#endif
>  
>   /**
>* @dev_private:
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 7af220226a25..cc9da43b6eda 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -516,7 +516,8 @@ struct drm_driver {
>  #endif
>  };
>  
> -void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver *driver,
> +void *__devm_drm_dev_alloc(struct device *parent,
> +const struct drm_driver *driver,
>  size_t size, size_t offset);
>  
>  /**
> @@ -549,7 +550,7 @@ void *__devm_drm_dev_alloc(struct device *parent, struct 
> drm_driver *driver,
>   ((type *) __devm_drm_dev_alloc(parent, driver, sizeof(type), \
>  offsetof(type, member)))
>  
> -struct drm_device *drm_dev_alloc(struct drm_driver *driver,
> +struct drm_device *drm_dev_alloc(const struct drm_driver *driver,
>struct device *parent);
>  int drm_dev_register(struct drm_device *dev, unsigned long flags);
>  void drm_dev_unregister(struct drm_device *dev);
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: More whitespace clean-ups in schema files

2020-10-26 Thread Krzysztof Kozlowski
On Fri, Oct 23, 2020 at 02:22:58PM -0500, Rob Herring wrote:
> Clean-up incorrect indentation, extra spaces, and missing EOF newline in
> schema files. Most of the clean-ups are for list indentation which
> should always be 2 spaces more than the preceding keyword.
> 
> Found with yamllint (now integrated into the checks).
> 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-g...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: alsa-de...@alsa-project.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-...@lists.infradead.org
> Cc: linux-ser...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
> Signed-off-by: Rob Herring 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 5/5] drm/: Constify struct drm_driver

2020-10-26 Thread Thomas Zimmermann
Hi

Am 23.10.20 um 14:28 schrieb Daniel Vetter:
> Only the following drivers aren't converted:
> - amdgpu, because of the driver_feature mangling due to virt support
> - nouveau, because DRIVER_ATOMIC uapi is still not the default on the
>   platforms where it's supported (i.e. again driver_feature mangling)
> - vc4, again because of driver_feature mangling
> - qxl, because the ioctl table is somewhere else and moving that is
>   maybe a bit too much, hence the num_ioctls assignment prevents a
>   const driver structure.
> 
> Note that for armada I also went ahead and made the ioctl array const.
> 
> Only cc'ing the driver people who've not been converted (everyone else
> is way too much).
> 
> Signed-off-by: Daniel Vetter 
> Cc: Dave Airlie 
> Cc: Gerd Hoffmann 
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: Harry Wentland 
> Cc: Leo Li 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Eric Anholt 
> Cc: Maxime Ripard 
> Cc: Ben Skeggs 
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_kms.c  | 2 +-
>  drivers/gpu/drm/arm/hdlcd_drv.c  | 2 +-
>  drivers/gpu/drm/arm/malidp_drv.c | 2 +-
>  drivers/gpu/drm/armada/armada_drv.c  | 7 +++
>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 2 +-
>  drivers/gpu/drm/ast/ast_drv.c| 2 +-
>  drivers/gpu/drm/ast/ast_drv.h| 2 +-
>  drivers/gpu/drm/ast/ast_main.c   | 2 +-
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
>  drivers/gpu/drm/bochs/bochs_drv.c| 2 +-
>  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++---
>  drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 2 +-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 2 +-
>  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  | 2 +-
>  drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
>  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
>  drivers/gpu/drm/imx/dcss/dcss-kms.c  | 2 +-
>  drivers/gpu/drm/imx/imx-drm-core.c   | 2 +-
>  drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +-
>  drivers/gpu/drm/lima/lima_drv.c  | 2 +-
>  drivers/gpu/drm/mcde/mcde_drv.c  | 2 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 2 +-
>  drivers/gpu/drm/meson/meson_drv.c| 2 +-
>  drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
>  drivers/gpu/drm/msm/msm_drv.c| 4 ++--
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 2 +-
>  drivers/gpu/drm/panfrost/panfrost_drv.c  | 2 +-
>  drivers/gpu/drm/pl111/pl111_drv.c| 2 +-
>  drivers/gpu/drm/radeon/radeon_drv.c  | 4 ++--
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  | 4 ++--
>  drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
>  drivers/gpu/drm/sti/sti_drv.c| 2 +-
>  drivers/gpu/drm/stm/drv.c| 2 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +-
>  drivers/gpu/drm/tegra/drm.c  | 5 ++---
>  drivers/gpu/drm/tidss/tidss_drv.c| 2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 4 ++--
>  drivers/gpu/drm/tiny/cirrus.c| 2 +-
>  drivers/gpu/drm/tiny/gm12u320.c  | 2 +-
>  drivers/gpu/drm/tiny/hx8357d.c   | 2 +-
>  drivers/gpu/drm/tiny/ili9225.c   | 2 +-
>  drivers/gpu/drm/tiny/ili9341.c   | 2 +-
>  drivers/gpu/drm/tiny/ili9486.c   | 2 +-
>  drivers/gpu/drm/tiny/mi0283qt.c  | 2 +-
>  drivers/gpu/drm/tiny/repaper.c   | 2 +-
>  drivers/gpu/drm/tiny/st7586.c| 2 +-
>  drivers/gpu/drm/tiny/st7735r.c   | 2 +-
>  drivers/gpu/drm/tve200/tve200_drv.c  | 2 +-
>  drivers/gpu/drm/udl/udl_drv.c| 2 +-
>  drivers/gpu/drm/v3d/v3d_drv.c| 2 +-
>  drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++--
>  drivers/gpu/drm/vgem/vgem_drv.c  | 2 +-
>  drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++--
>  drivers/gpu/drm/vkms/vkms_drv.c  | 2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  | 2 +-
>  drivers/gpu/drm/xen/xen_drm_front.c  | 2 +-
>  drivers/gpu/drm/xlnx/zynqmp_dpsub.c  | 2 +-
>  drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
>  63 files changed, 75 insertions(+), 78 deletions(-)

Oh please no. That's a huge patch for no apparent reason. Can you break
this up?

Best regards
Thomas

> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms

Re: [PATCH] drm: Don't create the IN_FORMATS blob when the driver does not provide .format_mod_supported()

2020-10-26 Thread Daniel Vetter
On Sat, Oct 24, 2020 at 12:52 AM Ville Syrjälä
 wrote:
>
> On Fri, Oct 23, 2020 at 10:03:50PM +, Simon Ser wrote:
> > On Friday, October 23, 2020 10:39 PM, Ville Syrjala 
> >  wrote:
> >
> > > From: Ville Syrjälä ville.syrj...@linux.intel.com
> > >
> > > The code responsible for creating the IN_FORMATS
> > > blob is broken when the driver doesn't provide a
> > > .format_mod_supported() hook. It just copies in
> > > the format list, but leaves all the modifier information
> > > zeroed. That would indicate (in a very silly way) that
> > > there are in fact no supported format+modifier combinations.
> > > That is utter nonsense.
> >
> > Should we WARN_ON when the driver enables allow_fb_modifiers but
> > doesn't populate format_mod_supported?
>
> .format_mod_supported() was supposed to be optional IIRC.
>
> But now that I look at it, it looks like only these
> drivers are lacking .format_mod_supported(): exynos, mxsfb,
> tiny/cirrus, tiny/gm12u320.
>
> There is some other oddity going on with sun4i which sometimes
> uses modifiers sometimes it doesn't. No idea what is going on there.
> But it does have .format_mod_supported() at least.
>
> So I guess if we can get exynos, mxsfb, and tiny/* to implement
> the hook then we could make it mandatory.

I'd just delete it all, since it's obviously not tested for these
drivers. And then add a patch which warns if allow_fb_modifiers,
modifiers list passed y/n and .format_mod_support don't all agree.
Since a bunch of your don't even set allow_fb_modifiers but pass a
format list. So it's a complete mess :-/

Next step would then be to add some todo items, at least the
simple/tiny drivers should all be able to do this fairly easily, and
probably with linear only as the default.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] Implement .format_mod_supported in mxsfb

2020-10-26 Thread Daniel Vetter
On Sun, Oct 25, 2020 at 4:52 PM Guido Günther  wrote:
>
> Hi Daniel,
> On Sat, Oct 24, 2020 at 04:59:16PM +, Daniel Abrecht wrote:
> > This will make sure applications which use the IN_FORMATS blob
> > to figure out which modifiers they can use will pick up the
> > linear modifier which is needed by mxsfb. Such applications
> > will not work otherwise if an incompatible implicit modifier
> > ends up being selected.
>
> Since this got broken by the switch away for the simple display
> pipeline helper (ae1ed0093281939b80664a687689f12436c0e874) could
> you add a fixes tag?

mxsfb is also missing setting the allow_fb_modifiers flag, without
which all this modifier stuff won't work great. Please add that too. I
guess some igt testing for this might be useful too, but not sure we
can do that with sufficient generality. It should fall over though
since if you try to create an fb with modifiers you'll fail, so no
idea what userspace you have here.
-Daniel

> Cheers,
>  -- Guido
>
> >
> > Signed-off-by: Daniel Abrecht 
> > ---
> >  drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > index 956f631997f2..fc4b1626261b 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > @@ -484,6 +484,13 @@ static void mxsfb_plane_overlay_atomic_update(struct
> > drm_plane *plane,
> >   writel(ctrl, mxsfb->base + LCDC_AS_CTRL);
> >  }
> >
> > +static bool mxsfb_format_mod_supported(struct drm_plane *plane,
> > +uint32_t format,
> > +uint64_t modifier)
> > +{
> > + return modifier == DRM_FORMAT_MOD_LINEAR;
> > +}
> > +
> >  static const struct drm_plane_helper_funcs mxsfb_plane_primary_helper_funcs
> > = {
> >   .atomic_check = mxsfb_plane_atomic_check,
> >   .atomic_update = mxsfb_plane_primary_atomic_update,
> > @@ -495,6 +502,7 @@ static const struct drm_plane_helper_funcs
> > mxsfb_plane_overlay_helper_funcs = {
> >  };
> >
> >  static const struct drm_plane_funcs mxsfb_plane_funcs = {
> > + .format_mod_supported   = mxsfb_format_mod_supported,
> >   .update_plane   = drm_atomic_helper_update_plane,
> >   .disable_plane  = drm_atomic_helper_disable_plane,
> >   .destroy= drm_plane_cleanup,
> > --
> > 2.20.1
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v3 19/20] drm/tegra: Implement new UAPI

2020-10-26 Thread Mikko Perttunen



On 10/22/20 7:20 AM, Dmitry Osipenko wrote:

20.10.2020 12:18, Mikko Perttunen пишет:

I'm asking this question because right now there is only one potential
client for this IOCTL, the VIC. If other clients aren't supposed to be a
part of the DRM driver, like for example NVDEC which probably should be
a V4L driver, then DRM driver will have only a single VIC and in this
case we shouldn't need this IOCTL because DRM and V4L should use generic
dmabuf API for importing and exporting buffers.


This IOCTL is required for GR2D/GR3D too, as they need to access memory
as well. This is a different step from import/export -- first you import
or allocate your memory so you have a GEM handle, then you map it to the
channel, which does the IOMMU mapping (if there is an IOMMU).



This doesn't answer my question. I don't have a full picture and for now
will remain dubious about this IOCTL, but it should be fine to have it
in a form of WIP patches (maybe staging feature) until userspace code
and hardware specs will become available.

Some more comments:

1. Older Tegra SoCs do not have restrictions which do not allow to group
IOMMU as wished by kernel driver. It's fine to have one static mapping
per-GEM that can be accessed by all DRM devices, that's why CHANNEL_MAP
is questionable.


Sure, on older Tegras this is not strictly necessary because the 
firewall can check pointers. It's not related to IOMMU grouping.




2. IIUC, the mappings need to be done per-device group/stream and not
per-channel_ctx. It looks like nothing stops channel contexts to guess
mapping addresses of the other context, isn't it?

I'm suggesting that each GEM should have a per-device mapping and the
new IOCTL should create these GEM-mappings, instead of the channel_ctx
mappings.


In the absence of context isolation, this is correct. But with context 
isolation (which is next on my upstream todo-list), on supported chips 
(T186+), we can map to individual contexts, which are associated with 
channel_ctx's.


Without context isolation, this IOCTL just maps to the underlying 
engine. The list of mappings can also be used by the firewall later - as 
mentioned, just the relocs would be enough for that, but I think there's 
a good orthogonality in CHANNEL_MAP describing memory regions accessible 
by the engine, and relocations just doing relocations.




3. We shouldn't need channel contexts at all, a single "DRM file"
context should be enough to have.


Yeah, maybe we could just have one "inline" channel context in the DRM 
file, that's just initialized by the CHANNEL_OPEN IOCTL.




4. The new UAPI need to be separated into several parts in the next
revision, one patch for each new feature.


I'll try to split up where possible.



The first patches should be the ones that are relevant to the existing
userspace code, like support for the waits.


Can you elaborate what you mean by this?



Partial mappings should be a separate feature because it's a
questionable feature that needs to be proved by a real userspace first.
Maybe it would be even better to drop it for the starter, to ease reviewing.


Considering that the "no-op" support for it (map the whole buffer but 
just keep track of the starting offset) is only a couple of lines, I'd 
like to keep it in.




Waiting for fences on host1x should be a separate feature.


OK.



The syncfile support needs to be a separate feature as well because I
don't see a use-case for it right now.


I'll separate it - the reason it's there is to avoid the overhead of the 
extra ID/threshold -> sync_file conversion IOCTL if you need it.




I'd like to see the DRM_SCHED and syncobj support. I can help you with
it if it's out of yours scope for now.



I already wrote some code for syncobj I can probably pull in. Regarding 
DRM_SCHED, help is accepted. However, we should keep using the hardware 
scheduler, and considering it's a bigger piece of work, let's not block 
this series on it.


Mikko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 5/5] drm/: Constify struct drm_driver

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 9:43 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 23.10.20 um 14:28 schrieb Daniel Vetter:
> > Only the following drivers aren't converted:
> > - amdgpu, because of the driver_feature mangling due to virt support
> > - nouveau, because DRIVER_ATOMIC uapi is still not the default on the
> >   platforms where it's supported (i.e. again driver_feature mangling)
> > - vc4, again because of driver_feature mangling
> > - qxl, because the ioctl table is somewhere else and moving that is
> >   maybe a bit too much, hence the num_ioctls assignment prevents a
> >   const driver structure.
> >
> > Note that for armada I also went ahead and made the ioctl array const.
> >
> > Only cc'ing the driver people who've not been converted (everyone else
> > is way too much).
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Dave Airlie 
> > Cc: Gerd Hoffmann 
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: Harry Wentland 
> > Cc: Leo Li 
> > Cc: Alex Deucher 
> > Cc: Christian König 
> > Cc: Eric Anholt 
> > Cc: Maxime Ripard 
> > Cc: Ben Skeggs 
> > Cc: nouv...@lists.freedesktop.org
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/arm/display/komeda/komeda_kms.c  | 2 +-
> >  drivers/gpu/drm/arm/hdlcd_drv.c  | 2 +-
> >  drivers/gpu/drm/arm/malidp_drv.c | 2 +-
> >  drivers/gpu/drm/armada/armada_drv.c  | 7 +++
> >  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 2 +-
> >  drivers/gpu/drm/ast/ast_drv.c| 2 +-
> >  drivers/gpu/drm/ast/ast_drv.h| 2 +-
> >  drivers/gpu/drm/ast/ast_main.c   | 2 +-
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 +-
> >  drivers/gpu/drm/bochs/bochs_drv.c| 2 +-
> >  drivers/gpu/drm/etnaviv/etnaviv_drv.c| 2 +-
> >  drivers/gpu/drm/exynos/exynos_drm_drv.c  | 2 +-
> >  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c| 5 ++---
> >  drivers/gpu/drm/gma500/psb_drv.c | 4 ++--
> >  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  | 2 +-
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  | 2 +-
> >  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  | 2 +-
> >  drivers/gpu/drm/i915/i915_drv.c  | 4 ++--
> >  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> >  drivers/gpu/drm/imx/dcss/dcss-kms.c  | 2 +-
> >  drivers/gpu/drm/imx/imx-drm-core.c   | 2 +-
> >  drivers/gpu/drm/ingenic/ingenic-drm-drv.c| 2 +-
> >  drivers/gpu/drm/lima/lima_drv.c  | 2 +-
> >  drivers/gpu/drm/mcde/mcde_drv.c  | 2 +-
> >  drivers/gpu/drm/mediatek/mtk_drm_drv.c   | 2 +-
> >  drivers/gpu/drm/meson/meson_drv.c| 2 +-
> >  drivers/gpu/drm/mgag200/mgag200_drv.c| 2 +-
> >  drivers/gpu/drm/msm/msm_drv.c| 4 ++--
> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
> >  drivers/gpu/drm/omapdrm/omap_drv.c   | 2 +-
> >  drivers/gpu/drm/panfrost/panfrost_drv.c  | 2 +-
> >  drivers/gpu/drm/pl111/pl111_drv.c| 2 +-
> >  drivers/gpu/drm/radeon/radeon_drv.c  | 4 ++--
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c| 2 +-
> >  drivers/gpu/drm/rockchip/rockchip_drm_drv.c  | 4 ++--
> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +-
> >  drivers/gpu/drm/sti/sti_drv.c| 2 +-
> >  drivers/gpu/drm/stm/drv.c| 2 +-
> >  drivers/gpu/drm/sun4i/sun4i_drv.c| 2 +-
> >  drivers/gpu/drm/tegra/drm.c  | 5 ++---
> >  drivers/gpu/drm/tidss/tidss_drv.c| 2 +-
> >  drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 4 ++--
> >  drivers/gpu/drm/tiny/cirrus.c| 2 +-
> >  drivers/gpu/drm/tiny/gm12u320.c  | 2 +-
> >  drivers/gpu/drm/tiny/hx8357d.c   | 2 +-
> >  drivers/gpu/drm/tiny/ili9225.c   | 2 +-
> >  drivers/gpu/drm/tiny/ili9341.c   | 2 +-
> >  drivers/gpu/drm/tiny/ili9486.c   | 2 +-
> >  drivers/gpu/drm/tiny/mi0283qt.c  | 2 +-
> >  drivers/gpu/drm/tiny/repaper.c   | 2 +-
> >  drivers/gpu/drm/tiny/st7586.c| 2 +-
> >  drivers/gpu/drm/tiny/st7735r.c   | 2 +-
> >  drivers/gpu/drm/tve200/tve200_drv.c  | 2 +-
> >  drivers/gpu/drm/udl/udl_drv.c| 2 +-
> >  drivers/gpu/drm/v3d/v3d_drv.c| 2 +-
> >  drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 ++--
> >  drivers/gpu/drm/vgem/vgem_drv.c  | 2 +-
> >  drivers/gpu/drm/virtio/virtgpu_drv.c | 4 ++--
> >  drivers/gpu/drm/vkms/vkms_drv.c  | 2 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  | 2 +-
> >  drivers/gpu/drm/xen/xen_drm_front.c  | 2 +-
> >  drivers/gpu/drm/xlnx/zynqmp_dpsub.c  | 2 +-
> >  drivers/gpu/drm/zte/zx_drm_drv.c  

[radeon-alex:amd-staging-drm-next 744/765] drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c:2280 sienna_cichlid_dump_pptable() error: buffer overflow 'pptable->SkuReserved' 8 <= 8

2020-10-26 Thread Dan Carpenter
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   1e5c252665ac026e977cd87fb8fcdb6f0bc0b759
commit: 62b1f5006728492c79182d960635d749d84f71ec [744/765] drm/amd/pm: update 
driver if file for sienna cichlid
config: i386-randconfig-m031-20201022 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 

smatch warnings:
drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c:2280 
sienna_cichlid_dump_pptable() error: buffer overflow 'pptable->SkuReserved' 8 
<= 8

vim +2280 drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c

d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2263dev_info(smu->adev->dev, "ReservedEquation2{a = 0x%x b 
= 0x%x c = 0x%x}\n",
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2264pptable->ReservedEquation2.a,
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2265pptable->ReservedEquation2.b,
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2266pptable->ReservedEquation2.c);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2267dev_info(smu->adev->dev, "ReservedEquation3{a = 0x%x b 
= 0x%x c = 0x%x}\n",
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2268pptable->ReservedEquation3.a,
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2269pptable->ReservedEquation3.b,
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2270pptable->ReservedEquation3.c);
b455159c053130d drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Likun Gao
2020-05-29  2271  
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2272dev_info(smu->adev->dev, "SkuReserved[0] = 0x%x\n", 
pptable->SkuReserved[0]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2273dev_info(smu->adev->dev, "SkuReserved[1] = 0x%x\n", 
pptable->SkuReserved[1]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2274dev_info(smu->adev->dev, "SkuReserved[2] = 0x%x\n", 
pptable->SkuReserved[2]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2275dev_info(smu->adev->dev, "SkuReserved[3] = 0x%x\n", 
pptable->SkuReserved[3]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2276dev_info(smu->adev->dev, "SkuReserved[4] = 0x%x\n", 
pptable->SkuReserved[4]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2277dev_info(smu->adev->dev, "SkuReserved[5] = 0x%x\n", 
pptable->SkuReserved[5]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2278dev_info(smu->adev->dev, "SkuReserved[6] = 0x%x\n", 
pptable->SkuReserved[6]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2279dev_info(smu->adev->dev, "SkuReserved[7] = 0x%x\n", 
pptable->SkuReserved[7]);
d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05 @2280dev_info(smu->adev->dev, "SkuReserved[8] = 0x%x\n", 
pptable->SkuReserved[8]);
^^^
Smatch thinks this array only has 8 elements.


d9811cfc0ebdf50 drivers/gpu/drm/amd/powerplay/sienna_cichlid_ppt.c Evan Quan
2020-06-05  2281  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/5] drm: Compile out legacy chunks from struct drm_device

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 9:37 AM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 23.10.20 um 14:28 schrieb Daniel Vetter:
> > This means some very few #ifdef in code, but it allows us to
> > enlist the compiler to make sure this stuff isn't used anymore.
> >
> > More important, only legacy drivers change drm_device (for the
> > legacy_dev_list shadow attach management), therefore this is
> > prep to allow modern drivers to have a const driver struct. Which
> > is nice, because there's a ton of function pointers in there.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Signed-off-by: Daniel Vetter 
>
> Review-by: Thomas Zimmermann 
>
> Sort of related: the implementation for KMS and UMS devices is more and
> more distinct from each other. Did you ever consider going for separate
> legacy helpers instead of mixing-in all these ifdefs?

I think we could split out drm_pci_legacy.c. Everything else is
already split out into separate files and made optional at the
Makefile level, it's really only in oddball places around the shared
drm_device where there's any #ifdef at all.
-Daniel

>
> Best regards
> Thomas
>
> > ---
> >  drivers/gpu/drm/drm_file.c   |  2 ++
> >  drivers/gpu/drm/drm_vblank.c | 15 ---
> >  include/drm/drm_drv.h|  2 ++
> >  3 files changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> > index 0ac4566ae3f4..b50380fa80ce 100644
> > --- a/drivers/gpu/drm/drm_file.c
> > +++ b/drivers/gpu/drm/drm_file.c
> > @@ -258,9 +258,11 @@ void drm_file_free(struct drm_file *file)
> > (long)old_encode_dev(file->minor->kdev->devt),
> > atomic_read(&dev->open_count));
> >
> > +#ifdef CONFIG_DRM_LEGACY
> >   if (drm_core_check_feature(dev, DRIVER_LEGACY) &&
> >   dev->driver->preclose)
> >   dev->driver->preclose(dev, file);
> > +#endif
> >
> >   if (drm_core_check_feature(dev, DRIVER_LEGACY))
> >   drm_legacy_lock_release(dev, file->filp);
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index ba7e741764aa..15e5ea436434 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -210,9 +210,12 @@ static u32 __get_vblank_counter(struct drm_device 
> > *dev, unsigned int pipe)
> >
> >   if (crtc->funcs->get_vblank_counter)
> >   return crtc->funcs->get_vblank_counter(crtc);
> > - } else if (dev->driver->get_vblank_counter) {
> > + }
> > +#ifdef CONFIG_DRM_LEGACY
> > + else if (dev->driver->get_vblank_counter) {
> >   return dev->driver->get_vblank_counter(dev, pipe);
> >   }
> > +#endif
> >
> >   return drm_vblank_no_hw_counter(dev, pipe);
> >  }
> > @@ -430,9 +433,12 @@ static void __disable_vblank(struct drm_device *dev, 
> > unsigned int pipe)
> >
> >   if (crtc->funcs->disable_vblank)
> >   crtc->funcs->disable_vblank(crtc);
> > - } else {
> > + }
> > +#ifdef CONFIG_DRM_LEGACY
> > + else {
> >   dev->driver->disable_vblank(dev, pipe);
> >   }
> > +#endif
> >  }
> >
> >  /*
> > @@ -1097,9 +1103,12 @@ static int __enable_vblank(struct drm_device *dev, 
> > unsigned int pipe)
> >
> >   if (crtc->funcs->enable_vblank)
> >   return crtc->funcs->enable_vblank(crtc);
> > - } else if (dev->driver->enable_vblank) {
> > + }
> > +#ifdef CONFIG_DRM_LEGACY
> > + else if (dev->driver->enable_vblank) {
> >   return dev->driver->enable_vblank(dev, pipe);
> >   }
> > +#endif
> >
> >   return -EINVAL;
> >  }
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index c6d17550efc9..7af220226a25 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -498,6 +498,7 @@ struct drm_driver {
> >*/
> >   const struct file_operations *fops;
> >
> > +#ifdef CONFIG_DRM_LEGACY
> >   /* Everything below here is for legacy driver, never use! */
> >   /* private: */
> >
> > @@ -512,6 +513,7 @@ struct drm_driver {
> >   int (*enable_vblank)(struct drm_device *dev, unsigned int pipe);
> >   void (*disable_vblank)(struct drm_device *dev, unsigned int pipe);
> >   int dev_priv_size;
> > +#endif
> >  };
> >
> >  void *__devm_drm_dev_alloc(struct device *parent, struct drm_driver 
> > *driver,
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v4 23/23] drm/msm: Don't implicit-sync if only a single ring

2020-10-26 Thread Daniel Vetter
On Fri, Oct 23, 2020 at 08:49:14PM -0700, Rob Clark wrote:
> On Fri, Oct 23, 2020 at 11:20 AM Lucas Stach  wrote:
> >
> > On Fr, 2020-10-23 at 09:51 -0700, Rob Clark wrote:
> > > From: Rob Clark 
> > >
> > > If there is only a single ring (no-preemption), everything is FIFO order
> > > and there is no need to implicit-sync.
> > >
> > > Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
> > > is undefined when fences are not used to synchronize buffer usage across
> > > contexts (which is the only case where multiple different priority rings
> > > could come into play).
> >
> > Really, doesn't this break cross-device implicit sync? Okay, you may
> > not have many peripherals that rely on implicit sync on devices where
> > Adreno is usually found, but it seems rather heavy-handed.
> >
> > Wouldn't it be better to only ignore fences from your own ring context
> > in the implicit sync, like we do in the common DRM scheduler
> > (drm_sched_dependency_optimized)?
> 
> we already do this.. as was discussed on an earlier iteration of this patchset
> 
> But I'm not aware of any other non-gpu related implicit sync use-case
> (even on imx devices where display is decoupled from gpu).. I'll
> revert the patch if someone comes up with one, but otherwise lets let
> the implicit sync baggage die

The thing is, dma_resv won't die, even if implicit sync is dead. We're
using internally for activity tracking and memory management. If you don't
set these, then we can't share generic code with msm, and I think everyone
inventing their own memory management is a bit a mistake.

Now you only kill the implicit write sync stuff here, but I'm not sure
that's worth much since you still install all the read fences for
consistency. And if userspace doesn't want to be synced, they can set the
flag and do this on their own: I think you should be able to achieve
exactly the same thing in mesa.

Aside: If you're worried about overhead, you can do O(1) submit if you
manage your ppgtt like amdgpu does.
-Daniel

> 
> BR,
> -R
> 
> 
> 
> >
> > Regards,
> > Lucas
> >
> > > Signed-off-by: Rob Clark 
> > > Reviewed-by: Kristian H. Kristensen 
> > > ---
> > >  drivers/gpu/drm/msm/msm_gem_submit.c | 7 ---
> > >  1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > index d04c349d8112..b6babc7f9bb8 100644
> > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > @@ -283,7 +283,7 @@ static int submit_lock_objects(struct msm_gem_submit 
> > > *submit)
> > >   return ret;
> > >  }
> > >
> > > -static int submit_fence_sync(struct msm_gem_submit *submit, bool 
> > > no_implicit)
> > > +static int submit_fence_sync(struct msm_gem_submit *submit, bool 
> > > implicit_sync)
> > >  {
> > >   int i, ret = 0;
> > >
> > > @@ -303,7 +303,7 @@ static int submit_fence_sync(struct msm_gem_submit 
> > > *submit, bool no_implicit)
> > >   return ret;
> > >   }
> > >
> > > - if (no_implicit)
> > > + if (!implicit_sync)
> > >   continue;
> > >
> > >   ret = msm_gem_sync_object(&msm_obj->base, 
> > > submit->ring->fctx,
> > > @@ -774,7 +774,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
> > > *data,
> > >   if (ret)
> > >   goto out;
> > >
> > > - ret = submit_fence_sync(submit, !!(args->flags & 
> > > MSM_SUBMIT_NO_IMPLICIT));
> > > + ret = submit_fence_sync(submit, (gpu->nr_rings > 1) &&
> > > + !(args->flags & MSM_SUBMIT_NO_IMPLICIT));
> > >   if (ret)
> > >   goto out;
> > >
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH resend] drm/v3d: Fix double free in v3d_submit_cl_ioctl()

2020-10-26 Thread Dan Carpenter
Originally this error path used to leak "bin" but then we accidentally
applied two separate commits to fix it and ended up with a double free.

Signed-off-by: Dan Carpenter 
---
Resending a year later because it was confusing at the time who should
apply this and it fell through the cracks.  For some reason the kbuild
bot flagged it as a new warning so it showed up on my radar again.

 drivers/gpu/drm/v3d/v3d_gem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 549dde83408b..37515e47b47e 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
ret = v3d_job_init(v3d, file_priv, &bin->base,
   v3d_job_free, args->in_sync_bcl);
if (ret) {
-   kfree(bin);
v3d_job_put(&render->base);
kfree(bin);
return ret;
-- 
2.20.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/v3d: Fix double free in v3d_submit_cl_ioctl()

2020-10-26 Thread Dan Carpenter
On Fri, Oct 25, 2019 at 09:09:56AM +1100, Stephen Rothwell wrote:
> Hi Dan,
> 
> On Thu, 24 Oct 2019 23:53:06 +0300 Dan Carpenter  
> wrote:
> >
> > Originally this error path used to leak "bin" but then we accidentally
> > applied two separate commits to fix it and ended up with a double free.
> > 
> > Signed-off-by: Dan Carpenter 
> > ---
> > Hi Stephen,
> > 
> > I think this one is actually just a linux-next issue and the Fixes tag
> > would point to commit f8593384f83f ("Merge remote-tracking branch
> > 'drm/drm-next'").
> > 
> > The original commits are 0d352a3a8a1f ("drm/v3d: don't leak bin job if
> > v3d_job_init fails.") and commit 29cd13cfd762 ("drm/v3d: Fix memory leak
> > in v3d_submit_cl_ioctl").
> > 
> > I'm not totally sure how you guys address this normally but presumably
> > you are experts at dealing with merge issues.  :)
> > 
> >  drivers/gpu/drm/v3d/v3d_gem.c | 1 -
> >  1 file changed, 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> > index 549dde83408b..37515e47b47e 100644
> > --- a/drivers/gpu/drm/v3d/v3d_gem.c
> > +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> > @@ -568,7 +568,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
> > ret = v3d_job_init(v3d, file_priv, &bin->base,
> >v3d_job_free, args->in_sync_bcl);
> > if (ret) {
> > -   kfree(bin);
> > v3d_job_put(&render->base);
> > kfree(bin);
> > return ret;
> 
> I will just apply this as part of the drm tree merge until Dave merges
> the drm-misc-fixes tree and fixes this up.
> 

It turns out that Dave never fixed it.  Let me resend.

regards,
dan carpenter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 05/13] drm/ttm: new TT backend allocation pool

2020-10-26 Thread kernel test robot
Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next 
tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.10-rc1 next-20201026]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-nuke-ttm_tt_set_-un-populated-again/20201026-004114
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: s390-randconfig-r036-20201026 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
1c8371692dfe8245bc6690ff1262dcced4649d21)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# 
https://github.com/0day-ci/linux/commit/618def1bc3db379a76b7462ab38236bfeb3df3d3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/drm-ttm-nuke-ttm_tt_set_-un-populated-again/20201026-004114
git checkout 618def1bc3db379a76b7462ab38236bfeb3df3d3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:19:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0x00ffUL) << 24) |\
 ^
   In file included from drivers/gpu/drm/ttm/ttm_pool.c:34:
   In file included from include/linux/dma-mapping.h:11:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/s390/include/asm/io.h:72:
   include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
   ~~ ^
   include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:20:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0xff00UL) <<  8) |\
 ^
   In file included from drivers/gpu/drm/ttm/ttm_pool.c:34:
   In file included from include/linux/dma-mapping.h:11:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/s390/include/asm/io.h:72:
   include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
   ~~ ^
   include/uapi/linux/byteorder/big_endian.h:34:59: note: expanded from macro 
'__le32_to_cpu'
   #define __le32_to_cpu(x) __swab32((__force __u32)(__le32)(x))
 ^
   include/uapi/linux/swab.h:119:21: note: expanded from macro '__swab32'
   ___constant_swab32(x) : \
  ^
   include/uapi/linux/swab.h:21:12: note: expanded from macro 
'___constant_swab32'
   (((__u32)(x) & (__u32)0x00ffUL) >>  8) |\
 ^
   In file included from drivers/gpu/drm/ttm/ttm_pool.c:34:
   In file included from include/linux/dma-mapping.h:11:
   In file included from include/linux/scatterlist.h:9:
   In file included from arch/s390/include/asm/io.h:72:
   include/asm-generic/io.h:490:61: warning: performing pointer arithmetic on a 
null pointer has undefined behavior [-Wnull-pointer-arithmetic]
   val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr));
   ~~ ^

Re: [PATCH] Implement .format_mod_supported in mxsfb

2020-10-26 Thread Ville Syrjälä
On Mon, Oct 26, 2020 at 10:05:17AM +0100, Daniel Vetter wrote:
> On Sun, Oct 25, 2020 at 4:52 PM Guido Günther  wrote:
> >
> > Hi Daniel,
> > On Sat, Oct 24, 2020 at 04:59:16PM +, Daniel Abrecht wrote:
> > > This will make sure applications which use the IN_FORMATS blob
> > > to figure out which modifiers they can use will pick up the
> > > linear modifier which is needed by mxsfb. Such applications
> > > will not work otherwise if an incompatible implicit modifier
> > > ends up being selected.
> >
> > Since this got broken by the switch away for the simple display
> > pipeline helper (ae1ed0093281939b80664a687689f12436c0e874) could
> > you add a fixes tag?
> 
> mxsfb is also missing setting the allow_fb_modifiers flag, without
> which all this modifier stuff won't work great.

drm_universal_plane_init() automagically adds it if a modifier list
is passed in.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 09/15] media/videbuf1|2: Mark follow_pfn usage as unsafe

2020-10-26 Thread Daniel Vetter
The media model assumes that buffers are all preallocated, so that
when a media pipeline is running we never miss a deadline because the
buffers aren't allocated or available.

This means we cannot fix the v4l follow_pfn usage through
mmu_notifier, without breaking how this all works. The only real fix
is to deprecate userptr support for VM_IO | VM_PFNMAP mappings and
tell everyone to cut over to dma-buf memory sharing for zerocopy.

userptr for normal memory will keep working as-is, this only affects
the zerocopy userptr usage enabled in 50ac952d2263 ("[media]
videobuf2-dma-sg: Support io userptr operations on io memory").

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Figa 
Cc: Laurent Dufour 
Cc: Vlastimil Babka 
Cc: Daniel Jordan 
Cc: Michel Lespinasse 
Signed-off-by: Daniel Vetter 
--
v3:
- Reference the commit that enabled the zerocopy userptr use case to
  make it abundandtly clear that this patch only affects that, and not
  normal memory userptr. The old commit message already explained that
  normal memory userptr is unaffected, but I guess that was not clear
  enough.
---
 drivers/media/common/videobuf2/frame_vector.c | 2 +-
 drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/common/videobuf2/frame_vector.c 
b/drivers/media/common/videobuf2/frame_vector.c
index 6590987c14bd..e630494da65c 100644
--- a/drivers/media/common/videobuf2/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -69,7 +69,7 @@ int get_vaddr_frames(unsigned long start, unsigned int 
nr_frames,
break;
 
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
-   err = follow_pfn(vma, start, &nums[ret]);
+   err = unsafe_follow_pfn(vma, start, &nums[ret]);
if (err) {
if (ret == 0)
ret = err;
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c 
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index 52312ce2ba05..821c4a76ab96 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -183,7 +183,7 @@ static int videobuf_dma_contig_user_get(struct 
videobuf_dma_contig_memory *mem,
user_address = untagged_baddr;
 
while (pages_done < (mem->size >> PAGE_SHIFT)) {
-   ret = follow_pfn(vma, user_address, &this_pfn);
+   ret = unsafe_follow_pfn(vma, user_address, &this_pfn);
if (ret)
break;
 
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 02/15] drm/exynos: Use FOLL_LONGTERM for g2d cmdlists

2020-10-26 Thread Daniel Vetter
The exynos g2d interface is very unusual, but it looks like the
userptr objects are persistent. Hence they need FOLL_LONGTERM.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index ecede41af9b9..1e0c5a7f206e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -475,7 +475,8 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct g2d_data 
*g2d,
goto err_free;
}
 
-   ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+   ret = pin_user_pages_fast(start, npages,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
  g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 05/15] mm/frame-vector: Use FOLL_LONGTERM

2020-10-26 Thread Daniel Vetter
This is used by media/videbuf2 for persistent dma mappings, not just
for a single dma operation and then freed again, so needs
FOLL_LONGTERM.

Unfortunately current pup_locked doesn't support FOLL_LONGTERM due to
locking issues. Rework the code to pull the pup path out from the
mmap_sem critical section as suggested by Jason.

By relying entirely on the vma checks in pin_user_pages and follow_pfn
(for vm_flags and vma_is_fsdax) we can also streamline the code a lot.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Figa 
Cc: Mauro Carvalho Chehab 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter 
--
v2: Streamline the code and further simplify the loop checks (Jason)
---
 mm/frame_vector.c | 50 ++-
 1 file changed, 15 insertions(+), 35 deletions(-)

diff --git a/mm/frame_vector.c b/mm/frame_vector.c
index 10f82d5643b6..d44779e56313 100644
--- a/mm/frame_vector.c
+++ b/mm/frame_vector.c
@@ -38,7 +38,6 @@ int get_vaddr_frames(unsigned long start, unsigned int 
nr_frames,
struct vm_area_struct *vma;
int ret = 0;
int err;
-   int locked;
 
if (nr_frames == 0)
return 0;
@@ -48,40 +47,25 @@ int get_vaddr_frames(unsigned long start, unsigned int 
nr_frames,
 
start = untagged_addr(start);
 
-   mmap_read_lock(mm);
-   locked = 1;
-   vma = find_vma_intersection(mm, start, start + 1);
-   if (!vma) {
-   ret = -EFAULT;
-   goto out;
-   }
-
-   /*
-* While get_vaddr_frames() could be used for transient (kernel
-* controlled lifetime) pinning of memory pages all current
-* users establish long term (userspace controlled lifetime)
-* page pinning. Treat get_vaddr_frames() like
-* get_user_pages_longterm() and disallow it for filesystem-dax
-* mappings.
-*/
-   if (vma_is_fsdax(vma)) {
-   ret = -EOPNOTSUPP;
-   goto out;
-   }
-
-   if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) {
+   ret = pin_user_pages_fast(start, nr_frames,
+ FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
+ (struct page **)(vec->ptrs));
+   if (ret > 0) {
vec->got_ref = true;
vec->is_pfns = false;
-   ret = pin_user_pages_locked(start, nr_frames,
-   gup_flags, (struct page **)(vec->ptrs), &locked);
-   goto out;
+   goto out_unlocked;
}
 
+   mmap_read_lock(mm);
vec->got_ref = false;
vec->is_pfns = true;
do {
unsigned long *nums = frame_vector_pfns(vec);
 
+   vma = find_vma_intersection(mm, start, start + 1);
+   if (!vma)
+   break;
+
while (ret < nr_frames && start + PAGE_SIZE <= vma->vm_end) {
err = follow_pfn(vma, start, &nums[ret]);
if (err) {
@@ -92,17 +76,13 @@ int get_vaddr_frames(unsigned long start, unsigned int 
nr_frames,
start += PAGE_SIZE;
ret++;
}
-   /*
-* We stop if we have enough pages or if VMA doesn't completely
-* cover the tail page.
-*/
-   if (ret >= nr_frames || start < vma->vm_end)
+   /* Bail out if VMA doesn't completely cover the tail page. */
+   if (start < vma->vm_end)
break;
-   vma = find_vma_intersection(mm, start, start + 1);
-   } while (vma && vma->vm_flags & (VM_IO | VM_PFNMAP));
+   } while (ret < nr_frames);
 out:
-   if (locked)
-   mmap_read_unlock(mm);
+   mmap_read_unlock(mm);
+out_unlocked:
if (!ret)
ret = -EFAULT;
if (ret > 0)
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 11/15] PCI: Obey iomem restrictions for procfs mmap

2020-10-26 Thread Daniel Vetter
There's three ways to access PCI BARs from userspace: /dev/mem, sysfs
files, and the old proc interface. Two check against
iomem_is_exclusive, proc never did. And with CONFIG_IO_STRICT_DEVMEM,
this starts to matter, since we don't want random userspace having
access to PCI BARs while a driver is loaded and using it.

Fix this by adding the same iomem_is_exclusive() check we already have
on the sysfs side in pci_mmap_resource().

References: 90a545e98126 ("restrict /dev/mem to idle io memory ranges")
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter 
--
v2: Improve commit message (Bjorn)
---
 drivers/pci/proc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index d35186b01d98..3a2f90beb4cb 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -274,6 +274,11 @@ static int proc_bus_pci_mmap(struct file *file, struct 
vm_area_struct *vma)
else
return -EINVAL;
}
+
+   if (dev->resource[i].flags & IORESOURCE_MEM &&
+   iomem_is_exclusive(dev->resource[i].start))
+   return -EINVAL;
+
ret = pci_mmap_page_range(dev, i, vma,
  fpriv->mmap_state, write_combine);
if (ret < 0)
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 03/15] misc/habana: Stop using frame_vector helpers

2020-10-26 Thread Daniel Vetter
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.

Reviewed-by: John Hubbard 
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay 
Cc: Omer Shpigelman 
Cc: Ofir Bitton 
Cc: Tomer Tayar 
Cc: Moti Haimovski 
Cc: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: Pawel Piskorski 
Signed-off-by: Daniel Vetter 
--
v2: Use unpin_user_pages_dirty_lock (John)
v3: Update kerneldoc (Oded)
---
 drivers/misc/habanalabs/Kconfig |  1 -
 drivers/misc/habanalabs/common/habanalabs.h |  6 ++-
 drivers/misc/habanalabs/common/memory.c | 49 -
 3 files changed, 22 insertions(+), 34 deletions(-)

diff --git a/drivers/misc/habanalabs/Kconfig b/drivers/misc/habanalabs/Kconfig
index 8eb5d38c618e..2f04187f7167 100644
--- a/drivers/misc/habanalabs/Kconfig
+++ b/drivers/misc/habanalabs/Kconfig
@@ -6,7 +6,6 @@
 config HABANA_AI
tristate "HabanaAI accelerators (habanalabs)"
depends on PCI && HAS_IOMEM
-   select FRAME_VECTOR
select DMA_SHARED_BUFFER
select GENERIC_ALLOCATOR
select HWMON
diff --git a/drivers/misc/habanalabs/common/habanalabs.h 
b/drivers/misc/habanalabs/common/habanalabs.h
index edbd627b29d2..41af090b3e6a 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -870,7 +870,8 @@ struct hl_ctx_mgr {
  * struct hl_userptr - memory mapping chunk information
  * @vm_type: type of the VM.
  * @job_node: linked-list node for hanging the object on the Job's list.
- * @vec: pointer to the frame vector.
+ * @pages: pointer to struct page array
+ * @npages: size of @pages array
  * @sgt: pointer to the scatter-gather table that holds the pages.
  * @dir: for DMA unmapping, the direction must be supplied, so save it.
  * @debugfs_list: node in debugfs list of command submissions.
@@ -881,7 +882,8 @@ struct hl_ctx_mgr {
 struct hl_userptr {
enum vm_type_t  vm_type; /* must be first */
struct list_headjob_node;
-   struct frame_vector *vec;
+   struct page **pages;
+   unsigned intnpages;
struct sg_table *sgt;
enum dma_data_direction dir;
struct list_headdebugfs_list;
diff --git a/drivers/misc/habanalabs/common/memory.c 
b/drivers/misc/habanalabs/common/memory.c
index 5ff4688683fd..327b64479f97 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1281,45 +1281,41 @@ static int get_user_memory(struct hl_device *hdev, u64 
addr, u64 size,
return -EFAULT;
}
 
-   userptr->vec = frame_vector_create(npages);
-   if (!userptr->vec) {
+   userptr->pages = kvmalloc_array(npages, sizeof(*userptr->pages),
+   GFP_KERNEL);
+   if (!userptr->pages) {
dev_err(hdev->dev, "Failed to create frame vector\n");
return -ENOMEM;
}
 
-   rc = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
-   userptr->vec);
+   rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+userptr->pages);
 
if (rc != npages) {
dev_err(hdev->dev,
"Failed to map host memory, user ptr probably wrong\n");
if (rc < 0)
-   goto destroy_framevec;
+   goto destroy_pages;
+   npages = rc;
rc = -EFAULT;
-   goto put_framevec;
-   }
-
-   if (frame_vector_to_pages(userptr->vec) < 0) {
-   dev_err(hdev->dev,
-   "Failed to translate frame vector to pages\n");
-   rc = -EFAULT;
-   goto put_framevec;
+   goto put_pages;
}
+   userptr->npages = npages;
 
rc = sg_alloc_table_from_pages(userptr->sgt,
-   frame_vector_pages(userptr->vec),
-   npages, offset, size, GFP_ATOMIC);
+  userptr->pages,
+  npages, offset, size, GFP_ATOMIC);
if (rc < 0) {
dev_err(hdev->dev, "failed to create SG table from pages\n");
-   goto put_framevec;
+   goto put_pages;
}
 
return 0;
 
-put_framevec:
-   put_vaddr_frames(userptr->vec);
-destroy_framevec:
-   frame_vector_destroy(userptr->vec);
+put_pages:
+   unpin_user_pages(userptr->pages, npages);
+destroy_pages:
+   kvfree(userptr->pages);
return rc;
 }
 
@@ -1405,8 +1401,6 @@ int hl_pin_host_memo

[PATCH v4 00/15] follow_pfn and other iomap races

2020-10-26 Thread Daniel Vetter
Hi all

Round 3 of my patch series to clamp down a bunch of races and gaps
around follow_pfn and other access to iomem mmaps. Previous version:

v1: 
https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/
v2: 
https://lore.kernel.org/dri-devel/20201009075934.3509076-1-daniel.vet...@ffwll.ch
v3: 
https://lore.kernel.org/dri-devel/20201021085655.1192025-1-daniel.vet...@ffwll.ch/

And the discussion that sparked this journey:

https://lore.kernel.org/dri-devel/20201007164426.1812530-1-daniel.vet...@ffwll.ch/

Changes in v4:
- Drop the s390 patch, that was very stand-alone and now queued up to land
  through s390 trees.
- Comment polish per Dan's review.

Changes in v3:
- Bunch of polish all over, no functional changes aside from one barrier
  in the resource code, for consistency.
- A few more r-b tags.

Changes in v2:
- tons of small polish&fixes all over, thanks to all the reviewers who
  spotted issues
- I managed to test at least the generic_access_phys and pci mmap revoke
  stuff with a few gdb sessions using our i915 debug tools (hence now also
  the drm/i915 patch to properly request all the pci bar regions)
- reworked approach for the pci mmap revoke: Infrastructure moved into
  kernel/resource.c, address_space mapping is now set up at open time for
  everyone (which required some sysfs changes). Does indeed look a lot
  cleaner and a lot less invasive than I feared at first.

I feel like this is ready for some wider soaking. Since the remaining bits
are all kinda connnected probably simplest if it all goes through -mm.

Cheers, Daniel

Daniel Vetter (15):
  drm/exynos: Stop using frame_vector helpers
  drm/exynos: Use FOLL_LONGTERM for g2d cmdlists
  misc/habana: Stop using frame_vector helpers
  misc/habana: Use FOLL_LONGTERM for userptr
  mm/frame-vector: Use FOLL_LONGTERM
  media: videobuf2: Move frame_vector into media subsystem
  mm: Close race in generic_access_phys
  mm: Add unsafe_follow_pfn
  media/videbuf1|2: Mark follow_pfn usage as unsafe
  vfio/type1: Mark follow_pfn as unsafe
  PCI: Obey iomem restrictions for procfs mmap
  /dev/mem: Only set filp->f_mapping
  resource: Move devmem revoke code to resource framework
  sysfs: Support zapping of binary attr mmaps
  PCI: Revoke mappings like devmem

 drivers/char/mem.c|  86 +--
 drivers/gpu/drm/exynos/Kconfig|   1 -
 drivers/gpu/drm/exynos/exynos_drm_g2d.c   |  48 -
 drivers/media/common/videobuf2/Kconfig|   1 -
 drivers/media/common/videobuf2/Makefile   |   1 +
 .../media/common/videobuf2}/frame_vector.c|  54 --
 drivers/media/platform/omap/Kconfig   |   1 -
 drivers/media/v4l2-core/videobuf-dma-contig.c |   2 +-
 drivers/misc/habanalabs/Kconfig   |   1 -
 drivers/misc/habanalabs/common/habanalabs.h   |   6 +-
 drivers/misc/habanalabs/common/memory.c   |  50 -
 drivers/pci/pci-sysfs.c   |   4 +
 drivers/pci/proc.c|   6 ++
 drivers/vfio/vfio_iommu_type1.c   |   4 +-
 fs/sysfs/file.c   |  11 ++
 include/linux/ioport.h|   6 +-
 include/linux/mm.h|  47 +---
 include/linux/sysfs.h |   2 +
 include/media/frame_vector.h  |  47 
 include/media/videobuf2-core.h|   1 +
 kernel/resource.c | 101 +-
 mm/Kconfig|   3 -
 mm/Makefile   |   1 -
 mm/memory.c   |  78 +-
 mm/nommu.c|  17 +++
 security/Kconfig  |  13 +++
 26 files changed, 347 insertions(+), 245 deletions(-)
 rename {mm => drivers/media/common/videobuf2}/frame_vector.c (85%)
 create mode 100644 include/media/frame_vector.h

-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 04/15] misc/habana: Use FOLL_LONGTERM for userptr

2020-10-26 Thread Daniel Vetter
These are persistent, not just for the duration of a dma operation.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Oded Gabbay 
Cc: Omer Shpigelman 
Cc: Ofir Bitton 
Cc: Tomer Tayar 
Cc: Moti Haimovski 
Cc: Daniel Vetter 
Cc: Greg Kroah-Hartman 
Cc: Pawel Piskorski 
Signed-off-by: Daniel Vetter 
---
 drivers/misc/habanalabs/common/memory.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/misc/habanalabs/common/memory.c 
b/drivers/misc/habanalabs/common/memory.c
index 327b64479f97..767d3644c033 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -1288,7 +1288,8 @@ static int get_user_memory(struct hl_device *hdev, u64 
addr, u64 size,
return -ENOMEM;
}
 
-   rc = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+   rc = pin_user_pages_fast(start, npages,
+FOLL_FORCE | FOLL_WRITE | FOLL_LONGTERM,
 userptr->pages);
 
if (rc != npages) {
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 01/15] drm/exynos: Stop using frame_vector helpers

2020-10-26 Thread Daniel Vetter
All we need are a pages array, pin_user_pages_fast can give us that
directly. Plus this avoids the entire raw pfn side of get_vaddr_frames.

Reviewed-by: John Hubbard 
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Signed-off-by: Daniel Vetter 
--
v2: Use unpin_user_pages_dirty_lock (John)
---
 drivers/gpu/drm/exynos/Kconfig  |  1 -
 drivers/gpu/drm/exynos/exynos_drm_g2d.c | 47 +++--
 2 files changed, 20 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 6417f374b923..43257ef3c09d 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -88,7 +88,6 @@ comment "Sub-drivers"
 config DRM_EXYNOS_G2D
bool "G2D"
depends on VIDEO_SAMSUNG_S5P_G2D=n || COMPILE_TEST
-   select FRAME_VECTOR
help
  Choose this option if you want to use Exynos G2D for DRM.
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 967a5cdc120e..ecede41af9b9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -205,7 +205,8 @@ struct g2d_cmdlist_userptr {
dma_addr_t  dma_addr;
unsigned long   userptr;
unsigned long   size;
-   struct frame_vector *vec;
+   struct page **pages;
+   unsigned intnpages;
struct sg_table *sgt;
atomic_trefcount;
boolin_pool;
@@ -378,7 +379,6 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
bool force)
 {
struct g2d_cmdlist_userptr *g2d_userptr = obj;
-   struct page **pages;
 
if (!obj)
return;
@@ -398,15 +398,9 @@ static void g2d_userptr_put_dma_addr(struct g2d_data *g2d,
dma_unmap_sgtable(to_dma_dev(g2d->drm_dev), g2d_userptr->sgt,
  DMA_BIDIRECTIONAL, 0);
 
-   pages = frame_vector_pages(g2d_userptr->vec);
-   if (!IS_ERR(pages)) {
-   int i;
-
-   for (i = 0; i < frame_vector_count(g2d_userptr->vec); i++)
-   set_page_dirty_lock(pages[i]);
-   }
-   put_vaddr_frames(g2d_userptr->vec);
-   frame_vector_destroy(g2d_userptr->vec);
+   unpin_user_pages_dirty_lock(g2d_userptr->pages, g2d_userptr->npages,
+   true);
+   kvfree(g2d_userptr->pages);
 
if (!g2d_userptr->out_of_list)
list_del_init(&g2d_userptr->list);
@@ -474,35 +468,34 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
g2d_data *g2d,
offset = userptr & ~PAGE_MASK;
end = PAGE_ALIGN(userptr + size);
npages = (end - start) >> PAGE_SHIFT;
-   g2d_userptr->vec = frame_vector_create(npages);
-   if (!g2d_userptr->vec) {
+   g2d_userptr->pages = kvmalloc_array(npages, sizeof(*g2d_userptr->pages),
+   GFP_KERNEL);
+   if (!g2d_userptr->pages) {
ret = -ENOMEM;
goto err_free;
}
 
-   ret = get_vaddr_frames(start, npages, FOLL_FORCE | FOLL_WRITE,
-   g2d_userptr->vec);
+   ret = pin_user_pages_fast(start, npages, FOLL_FORCE | FOLL_WRITE,
+ g2d_userptr->pages);
if (ret != npages) {
DRM_DEV_ERROR(g2d->dev,
  "failed to get user pages from userptr.\n");
if (ret < 0)
-   goto err_destroy_framevec;
-   ret = -EFAULT;
-   goto err_put_framevec;
-   }
-   if (frame_vector_to_pages(g2d_userptr->vec) < 0) {
+   goto err_destroy_pages;
+   npages = ret;
ret = -EFAULT;
-   goto err_put_framevec;
+   goto err_unpin_pages;
}
+   g2d_userptr->npages = npages;
 
sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
if (!sgt) {
ret = -ENOMEM;
-   goto err_put_framevec;
+   goto err_unpin_pages;
}
 
ret = sg_alloc_table_from_pages(sgt,
-   frame_vector_pages(g2d_userptr->vec),
+   g2d_userptr->pages,
npages, offset, size, GFP_KERNEL);
if (ret < 0) {
DRM_DEV_ERROR(g2d->dev, "failed to get sgt from pages.\n");
@@ -538,11 +531,11 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
g2d_data *g2d,
 err_free_sgt:
kfree(sgt);
 
-

[PATCH v4 07/15] mm: Close race in generic_access_phys

2020-10-26 Thread Daniel Vetter
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:

- gpu drivers dynamically manage their memory nowadays, invalidating
  ptes with unmap_mapping_range when buffers get moved

- contiguous dma allocations have moved from dedicated carvetouts to
  cma regions. This means if we miss the unmap the pfn might contain
  pagecache or anon memory (well anything allocated with GFP_MOVEABLE)

- even /dev/mem now invalidates mappings when the kernel requests that
  iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
  ("/dev/mem: Revoke mappings when a driver claims the region")

Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea. Fix this.

Since ioremap might need to manipulate pagetables too we need to drop
the pt lock and have a retry loop if we raced.

While at it, also add kerneldoc and improve the comment for the
vma_ops->access function. It's for accessing, not for moving the
memory from iomem to system memory, as the old comment seemed to
suggest.

References: 28b2ee20c7cb ("access_process_vm device memory infrastructure")
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Dan Williams 
Cc: Kees Cook 
Cc: Benjamin Herrensmidt 
Cc: Dave Airlie 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
--
v2: Fix inversion in the retry check (John).

v4: While at it, use offset_in_page (Chris Wilson)
---
 include/linux/mm.h |  3 ++-
 mm/memory.c| 46 +++---
 2 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index acd60fbf1a5a..2a16631c1fda 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -566,7 +566,8 @@ struct vm_operations_struct {
vm_fault_t (*pfn_mkwrite)(struct vm_fault *vmf);
 
/* called by access_process_vm when get_user_pages() fails, typically
-* for use by special VMAs that can switch between memory and hardware
+* for use by special VMAs. See also generic_access_phys() for a generic
+* implementation useful for any iomem mapping.
 */
int (*access)(struct vm_area_struct *vma, unsigned long addr,
  void *buf, int len, int write);
diff --git a/mm/memory.c b/mm/memory.c
index eeae590e526a..1b46eae3b703 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4840,28 +4840,68 @@ int follow_phys(struct vm_area_struct *vma,
return ret;
 }
 
+/**
+ * generic_access_phys - generic implementation for iomem mmap access
+ * @vma: the vma to access
+ * @addr: userspace addres, not relative offset within @vma
+ * @buf: buffer to read/write
+ * @len: length of transfer
+ * @write: set to FOLL_WRITE when writing, otherwise reading
+ *
+ * This is a generic implementation for &vm_operations_struct.access for an
+ * iomem mapping. This callback is used by access_process_vm() when the @vma is
+ * not page based.
+ */
 int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
void *buf, int len, int write)
 {
resource_size_t phys_addr;
unsigned long prot = 0;
void __iomem *maddr;
-   int offset = addr & (PAGE_SIZE-1);
+   pte_t *ptep, pte;
+   spinlock_t *ptl;
+   int offset = offset_in_page(addr);
+   int ret = -EINVAL;
+
+   if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
+   return -EINVAL;
+
+retry:
+   if (follow_pte(vma->vm_mm, addr, &ptep, &ptl))
+   return -EINVAL;
+   pte = *ptep;
+   pte_unmap_unlock(ptep, ptl);
 
-   if (follow_phys(vma, addr, write, &prot, &phys_addr))
+   prot = pgprot_val(pte_pgprot(pte));
+   phys_addr = (resource_size_t)pte_pfn(pte) << PAGE_SHIFT;
+
+   if ((write & FOLL_WRITE) && !pte_write(pte))
return -EINVAL;
 
maddr = ioremap_prot(phys_addr, PAGE_ALIGN(len + offset), prot);
if (!maddr)
return -ENOMEM;
 
+   if (follow_pte(vma->vm_mm, addr, &ptep, &ptl))
+   goto out_unmap;
+
+   if (!pte_same(pte, *ptep)) {
+   pte_unmap_unlock(ptep, ptl);
+   iounmap(maddr);
+
+   goto retry;
+   }
+
if (write)
memcpy_toio(maddr + offset, buf, len);
else
memcpy_fromio(buf, maddr + offset, len);
+   ret = len;
+   pte_unmap_unlock(ptep, ptl);
+out_unmap:
iounmap(maddr);
 
-   return len;
+   return ret;
 }
 EXPORT_SYMBOL_GPL(generic_access_phys);
 #endif
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 06/15] media: videobuf2: Move frame_vector into media subsystem

2020-10-26 Thread Daniel Vetter
It's the only user. This also garbage collects the CONFIG_FRAME_VECTOR
symbol from all over the tree (well just one place, somehow omap media
driver still had this in its Kconfig, despite not using it).

Reviewed-by: John Hubbard 
Acked-by: Mauro Carvalho Chehab 
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Figa 
Cc: Mauro Carvalho Chehab 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
--
v3:
- Create a new frame_vector.h header for this (Mauro)
---
 drivers/media/common/videobuf2/Kconfig|  1 -
 drivers/media/common/videobuf2/Makefile   |  1 +
 .../media/common/videobuf2}/frame_vector.c|  2 +
 drivers/media/platform/omap/Kconfig   |  1 -
 include/linux/mm.h| 42 -
 include/media/frame_vector.h  | 47 +++
 include/media/videobuf2-core.h|  1 +
 mm/Kconfig|  3 --
 mm/Makefile   |  1 -
 9 files changed, 51 insertions(+), 48 deletions(-)
 rename {mm => drivers/media/common/videobuf2}/frame_vector.c (99%)
 create mode 100644 include/media/frame_vector.h

diff --git a/drivers/media/common/videobuf2/Kconfig 
b/drivers/media/common/videobuf2/Kconfig
index edbc99ebba87..d2223a12c95f 100644
--- a/drivers/media/common/videobuf2/Kconfig
+++ b/drivers/media/common/videobuf2/Kconfig
@@ -9,7 +9,6 @@ config VIDEOBUF2_V4L2
 
 config VIDEOBUF2_MEMOPS
tristate
-   select FRAME_VECTOR
 
 config VIDEOBUF2_DMA_CONTIG
tristate
diff --git a/drivers/media/common/videobuf2/Makefile 
b/drivers/media/common/videobuf2/Makefile
index 77bebe8b202f..54306f8d096c 100644
--- a/drivers/media/common/videobuf2/Makefile
+++ b/drivers/media/common/videobuf2/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 videobuf2-common-objs := videobuf2-core.o
+videobuf2-common-objs += frame_vector.o
 
 ifeq ($(CONFIG_TRACEPOINTS),y)
   videobuf2-common-objs += vb2-trace.o
diff --git a/mm/frame_vector.c b/drivers/media/common/videobuf2/frame_vector.c
similarity index 99%
rename from mm/frame_vector.c
rename to drivers/media/common/videobuf2/frame_vector.c
index d44779e56313..6590987c14bd 100644
--- a/mm/frame_vector.c
+++ b/drivers/media/common/videobuf2/frame_vector.c
@@ -8,6 +8,8 @@
 #include 
 #include 
 
+#include 
+
 /**
  * get_vaddr_frames() - map virtual addresses to pfns
  * @start: starting user address
diff --git a/drivers/media/platform/omap/Kconfig 
b/drivers/media/platform/omap/Kconfig
index f73b5893220d..de16de46c0f4 100644
--- a/drivers/media/platform/omap/Kconfig
+++ b/drivers/media/platform/omap/Kconfig
@@ -12,6 +12,5 @@ config VIDEO_OMAP2_VOUT
depends on VIDEO_V4L2
select VIDEOBUF2_DMA_CONTIG
select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3
-   select FRAME_VECTOR
help
  V4L2 Display driver support for OMAP2/3 based boards.
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 16b799a0522c..acd60fbf1a5a 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1743,48 +1743,6 @@ int account_locked_vm(struct mm_struct *mm, unsigned 
long pages, bool inc);
 int __account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc,
struct task_struct *task, bool bypass_rlim);
 
-/* Container for pinned pfns / pages */
-struct frame_vector {
-   unsigned int nr_allocated;  /* Number of frames we have space for */
-   unsigned int nr_frames; /* Number of frames stored in ptrs array */
-   bool got_ref;   /* Did we pin pages by getting page ref? */
-   bool is_pfns;   /* Does array contain pages or pfns? */
-   void *ptrs[];   /* Array of pinned pfns / pages. Use
-* pfns_vector_pages() or pfns_vector_pfns()
-* for access */
-};
-
-struct frame_vector *frame_vector_create(unsigned int nr_frames);
-void frame_vector_destroy(struct frame_vector *vec);
-int get_vaddr_frames(unsigned long start, unsigned int nr_pfns,
-unsigned int gup_flags, struct frame_vector *vec);
-void put_vaddr_frames(struct frame_vector *vec);
-int frame_vector_to_pages(struct frame_vector *vec);
-void frame_vector_to_pfns(struct frame_vector *vec);
-
-static inline unsigned int frame_vector_count(struct frame_vector *vec)
-{
-   return vec->nr_frames;
-}
-
-static inline struct page **frame_vector_pages(struct frame_vector *vec)
-{
-   if (vec->is_pfns) {
-   int err = frame_vector_to_pages(vec);
-
-   if (err)
-   return ERR_PTR(err);
-   }
-   return (struct page **)(vec->ptrs);
-}
-
-static inline unsig

[PATCH v4 14/15] sysfs: Support zapping of binary attr mmaps

2020-10-26 Thread Daniel Vetter
We want to be able to revoke pci mmaps so that the same access rules
applies as for /dev/kmem. Revoke support for devmem was added in
3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims the
region").

The simplest way to achieve this is by having the same filp->f_mapping
for all mappings, so that unmap_mapping_range can find them all, no
matter through which file they've been created. Since this must be set
at open time we need sysfs support for this.

Add an optional mapping parameter bin_attr, which is only consulted
when there's also an mmap callback, since without mmap support
allowing to adjust the ->f_mapping makes no sense.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Cc: Greg Kroah-Hartman 
Cc: "Rafael J. Wysocki" 
Cc: Christian Brauner 
Cc: "David S. Miller" 
Cc: Michael Ellerman 
Cc: Sourabh Jain 
Cc: Daniel Vetter 
Cc: Mauro Carvalho Chehab 
Cc: Nayna Jain 
Signed-off-by: Daniel Vetter 
---
 fs/sysfs/file.c   | 11 +++
 include/linux/sysfs.h |  2 ++
 2 files changed, 13 insertions(+)

diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c
index eb6897ab78e7..9d8ccdb000e3 100644
--- a/fs/sysfs/file.c
+++ b/fs/sysfs/file.c
@@ -169,6 +169,16 @@ static int sysfs_kf_bin_mmap(struct kernfs_open_file *of,
return battr->mmap(of->file, kobj, battr, vma);
 }
 
+static int sysfs_kf_bin_open(struct kernfs_open_file *of)
+{
+   struct bin_attribute *battr = of->kn->priv;
+
+   if (battr->mapping)
+   of->file->f_mapping = battr->mapping;
+
+   return 0;
+}
+
 void sysfs_notify(struct kobject *kobj, const char *dir, const char *attr)
 {
struct kernfs_node *kn = kobj->sd, *tmp;
@@ -240,6 +250,7 @@ static const struct kernfs_ops sysfs_bin_kfops_mmap = {
.read   = sysfs_kf_bin_read,
.write  = sysfs_kf_bin_write,
.mmap   = sysfs_kf_bin_mmap,
+   .open   = sysfs_kf_bin_open,
 };
 
 int sysfs_add_file_mode_ns(struct kernfs_node *parent,
diff --git a/include/linux/sysfs.h b/include/linux/sysfs.h
index 34e84122f635..a17a474d1601 100644
--- a/include/linux/sysfs.h
+++ b/include/linux/sysfs.h
@@ -164,11 +164,13 @@ __ATTRIBUTE_GROUPS(_name)
 
 struct file;
 struct vm_area_struct;
+struct address_space;
 
 struct bin_attribute {
struct attributeattr;
size_t  size;
void*private;
+   struct address_space*mapping;
ssize_t (*read)(struct file *, struct kobject *, struct bin_attribute *,
char *, loff_t, size_t);
ssize_t (*write)(struct file *, struct kobject *, struct bin_attribute 
*,
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 08/15] mm: Add unsafe_follow_pfn

2020-10-26 Thread Daniel Vetter
Way back it was a reasonable assumptions that iomem mappings never
change the pfn range they point at. But this has changed:

- gpu drivers dynamically manage their memory nowadays, invalidating
ptes with unmap_mapping_range when buffers get moved

- contiguous dma allocations have moved from dedicated carvetouts to
cma regions. This means if we miss the unmap the pfn might contain
pagecache or anon memory (well anything allocated with GFP_MOVEABLE)

- even /dev/mem now invalidates mappings when the kernel requests that
iomem region when CONFIG_IO_STRICT_DEVMEM is set, see 3234ac664a87
("/dev/mem: Revoke mappings when a driver claims the region")

Accessing pfns obtained from ptes without holding all the locks is
therefore no longer a good idea.

Unfortunately there's some users where this is not fixable (like v4l
userptr of iomem mappings) or involves a pile of work (vfio type1
iommu). For now annotate these as unsafe and splat appropriately.

This patch adds an unsafe_follow_pfn, which later patches will then
roll out to all appropriate places.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 include/linux/mm.h |  2 ++
 mm/memory.c| 32 +++-
 mm/nommu.c | 17 +
 security/Kconfig   | 13 +
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2a16631c1fda..ec8c90928fc9 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1653,6 +1653,8 @@ int follow_pte_pmd(struct mm_struct *mm, unsigned long 
address,
   pte_t **ptepp, pmd_t **pmdpp, spinlock_t **ptlp);
 int follow_pfn(struct vm_area_struct *vma, unsigned long address,
unsigned long *pfn);
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+ unsigned long *pfn);
 int follow_phys(struct vm_area_struct *vma, unsigned long address,
unsigned int flags, unsigned long *prot, resource_size_t *phys);
 int generic_access_phys(struct vm_area_struct *vma, unsigned long addr,
diff --git a/mm/memory.c b/mm/memory.c
index 1b46eae3b703..9a2ec07ff20b 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4788,7 +4788,12 @@ EXPORT_SYMBOL(follow_pte_pmd);
  * @address: user virtual address
  * @pfn: location to store found PFN
  *
- * Only IO mappings and raw PFN mappings are allowed.
+ * Only IO mappings and raw PFN mappings are allowed. Note that callers must
+ * ensure coherency with pte updates by using a &mmu_notifier to follow 
updates.
+ * If this is not feasible, or the access to the @pfn is only very short term,
+ * use follow_pte_pmd() instead and hold the pagetable lock for the duration of
+ * the access instead. Any caller not following these requirements must use
+ * unsafe_follow_pfn() instead.
  *
  * Return: zero and the pfn at @pfn on success, -ve otherwise.
  */
@@ -4811,6 +4816,31 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long 
address,
 }
 EXPORT_SYMBOL(follow_pfn);
 
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+   unsigned long *pfn)
+{
+#ifdef CONFIG_STRICT_FOLLOW_PFN
+   pr_info("unsafe follow_pfn usage rejected, see 
CONFIG_STRICT_FOLLOW_PFN\n");
+   return -EINVAL;
+#else
+   WARN_ONCE(1, "unsafe follow_pfn usage\n");
+   add_taint(TAINT_USER, LOCKDEP_STILL_OK);
+
+   return follow_pfn(vma, address, pfn);
+#endif
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
+
 #ifdef CONFIG_HAVE_IOREMAP_PROT
 int follow_phys(struct vm_area_struct *vma,
unsigned long address, unsigned int flags,
diff --git a/mm/nommu.c b/mm/nommu.c
index 75a327149af1..3db2910f0d64 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -132,6 +132,23 @@ int follow_pfn(struct vm_area_struct *vma, unsigned long 
address,
 }
 EXPORT_SYMBOL(follow_pfn);
 
+/**
+ * unsafe_follow_pfn - look up PFN at a user virtual address
+ * @vma: memory mapping
+ * @address: user virtual address
+ * @pfn: location to store found PFN
+ *
+ * Only IO mappings and raw PFN mappings are allowed.
+ *
+ * Returns zero and the pfn at @pfn on success, -ve otherwise.
+ */
+int unsafe_follow_pfn(struct vm_area_struct *vma, unsigned long address,
+   unsigned long *pfn)
+{
+   return follow_pfn(vma, address, pfn);
+}
+EXPORT_SYMBOL(unsafe_follow_pfn);
+
 LIST_HEAD(vmap_area_list);
 
 void vfree(const void *addr)
diff --git a/security/K

[PATCH v4 10/15] vfio/type1: Mark follow_pfn as unsafe

2020-10-26 Thread Daniel Vetter
The code seems to stuff these pfns into iommu pts (or something like
that, I didn't follow), but there's no mmu_notifier to ensure that
access is synchronized with pte updates.

Hence mark these as unsafe. This means that with
CONFIG_STRICT_FOLLOW_PFN, these will be rejected.

Real fix is to wire up an mmu_notifier ... somehow. Probably means any
invalidate is a fatal fault for this vfio device, but then this
shouldn't ever happen if userspace is reasonable.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Alex Williamson 
Cc: Cornelia Huck 
Cc: k...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/vfio/vfio_iommu_type1.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 5fbf0c1f7433..a4d53f3d0a35 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -421,7 +421,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma, 
struct mm_struct *mm,
 {
int ret;
 
-   ret = follow_pfn(vma, vaddr, pfn);
+   ret = unsafe_follow_pfn(vma, vaddr, pfn);
if (ret) {
bool unlocked = false;
 
@@ -435,7 +435,7 @@ static int follow_fault_pfn(struct vm_area_struct *vma, 
struct mm_struct *mm,
if (ret)
return ret;
 
-   ret = follow_pfn(vma, vaddr, pfn);
+   ret = unsafe_follow_pfn(vma, vaddr, pfn);
}
 
return ret;
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 12/15] /dev/mem: Only set filp->f_mapping

2020-10-26 Thread Daniel Vetter
When we care about pagecache maintenance, we need to make sure that
both f_mapping and i_mapping point at the right mapping.

But for iomem mappings we only care about the virtual/pte side of
things, so f_mapping is enough. Also setting inode->i_mapping was
confusing me as a driver maintainer, since in e.g. drivers/gpu we
don't do that. Per Dan this seems to be copypasta from places which do
care about pagecache consistency, but not needed. Hence remove it for
slightly less confusion.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Reviewed-by: Dan Williams 
Signed-off-by: Daniel Vetter 
---
 drivers/char/mem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index abd4ffdc8cde..5502f56f3655 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -864,7 +864,6 @@ static int open_port(struct inode *inode, struct file *filp)
 * revocations when drivers want to take over a /dev/mem mapped
 * range.
 */
-   inode->i_mapping = devmem_inode->i_mapping;
filp->f_mapping = inode->i_mapping;
 
return 0;
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v4 13/15] resource: Move devmem revoke code to resource framework

2020-10-26 Thread Daniel Vetter
We want all iomem mmaps to consistently revoke ptes when the kernel
takes over and CONFIG_IO_STRICT_DEVMEM is enabled. This includes the
pci bar mmaps available through procfs and sysfs, which currently do
not revoke mappings.

To prepare for this, move the code from the /dev/kmem driver to
kernel/resource.c.

Reviewed-by: Greg Kroah-Hartman 
Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Daniel Vetter 
Cc: David Hildenbrand 
Cc: "Rafael J. Wysocki" 
Signed-off-by: Daniel Vetter 
--
v3:
- add barrier for consistency and document why we don't have to check
  for NULL (Jason)
v4
- Adjust comments to reflect the general nature of this iomem revoke
  code now (Dan)
---
 drivers/char/mem.c |  85 +-
 include/linux/ioport.h |   6 +--
 kernel/resource.c  | 101 -
 3 files changed, 102 insertions(+), 90 deletions(-)

diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index 5502f56f3655..53338aad8d28 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -31,9 +31,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 
 #ifdef CONFIG_IA64
 # include 
@@ -809,42 +806,6 @@ static loff_t memory_lseek(struct file *file, loff_t 
offset, int orig)
return ret;
 }
 
-static struct inode *devmem_inode;
-
-#ifdef CONFIG_IO_STRICT_DEVMEM
-void revoke_devmem(struct resource *res)
-{
-   /* pairs with smp_store_release() in devmem_init_inode() */
-   struct inode *inode = smp_load_acquire(&devmem_inode);
-
-   /*
-* Check that the initialization has completed. Losing the race
-* is ok because it means drivers are claiming resources before
-* the fs_initcall level of init and prevent /dev/mem from
-* establishing mappings.
-*/
-   if (!inode)
-   return;
-
-   /*
-* The expectation is that the driver has successfully marked
-* the resource busy by this point, so devmem_is_allowed()
-* should start returning false, however for performance this
-* does not iterate the entire resource range.
-*/
-   if (devmem_is_allowed(PHYS_PFN(res->start)) &&
-   devmem_is_allowed(PHYS_PFN(res->end))) {
-   /*
-* *cringe* iomem=relaxed says "go ahead, what's the
-* worst that can happen?"
-*/
-   return;
-   }
-
-   unmap_mapping_range(inode->i_mapping, res->start, resource_size(res), 
1);
-}
-#endif
-
 static int open_port(struct inode *inode, struct file *filp)
 {
int rc;
@@ -864,7 +825,7 @@ static int open_port(struct inode *inode, struct file *filp)
 * revocations when drivers want to take over a /dev/mem mapped
 * range.
 */
-   filp->f_mapping = inode->i_mapping;
+   filp->f_mapping = iomem_get_mapping();
 
return 0;
 }
@@ -995,48 +956,6 @@ static char *mem_devnode(struct device *dev, umode_t *mode)
 
 static struct class *mem_class;
 
-static int devmem_fs_init_fs_context(struct fs_context *fc)
-{
-   return init_pseudo(fc, DEVMEM_MAGIC) ? 0 : -ENOMEM;
-}
-
-static struct file_system_type devmem_fs_type = {
-   .name   = "devmem",
-   .owner  = THIS_MODULE,
-   .init_fs_context = devmem_fs_init_fs_context,
-   .kill_sb= kill_anon_super,
-};
-
-static int devmem_init_inode(void)
-{
-   static struct vfsmount *devmem_vfs_mount;
-   static int devmem_fs_cnt;
-   struct inode *inode;
-   int rc;
-
-   rc = simple_pin_fs(&devmem_fs_type, &devmem_vfs_mount, &devmem_fs_cnt);
-   if (rc < 0) {
-   pr_err("Cannot mount /dev/mem pseudo filesystem: %d\n", rc);
-   return rc;
-   }
-
-   inode = alloc_anon_inode(devmem_vfs_mount->mnt_sb);
-   if (IS_ERR(inode)) {
-   rc = PTR_ERR(inode);
-   pr_err("Cannot allocate inode for /dev/mem: %d\n", rc);
-   simple_release_fs(&devmem_vfs_mount, &devmem_fs_cnt);
-   return rc;
-   }
-
-   /*
-* Publish /dev/mem initialized.
-* Pairs with smp_load_acquire() in revoke_devmem().
-*/
-   smp_store_release(&devmem_inode, inode);
-
-   return 0;
-}
-
 static int __init chr_dev_init(void)
 {
int minor;
@@ -1058,8 +977,6 @@ static int __init chr_dev_init(void)
 */
if ((minor == DEVPORT_MINOR) && !arch_has_dev_port())
continue;
-   if ((minor == DEVMEM_MINOR) && devmem_init_inode() != 0)
-   continue;
 
device_create(mem_class, NULL, MKDEV(MEM_MAJOR, minor),
  

[PATCH v4 15/15] PCI: Revoke mappings like devmem

2020-10-26 Thread Daniel Vetter
Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
the region") /dev/kmem zaps ptes when the kernel requests exclusive
acccess to an iomem region. And with CONFIG_IO_STRICT_DEVMEM, this is
the default for all driver uses.

Except there's two more ways to access PCI BARs: sysfs and proc mmap
support. Let's plug that hole.

For revoke_devmem() to work we need to link our vma into the same
address_space, with consistent vma->vm_pgoff. ->pgoff is already
adjusted, because that's how (io_)remap_pfn_range works, but for the
mapping we need to adjust vma->vm_file->f_mapping. The cleanest way is
to adjust this at at ->open time:

- for sysfs this is easy, now that binary attributes support this. We
  just set bin_attr->mapping when mmap is supported
- for procfs it's a bit more tricky, since procfs pci access has only
  one file per device, and access to a specific resources first needs
  to be set up with some ioctl calls. But mmap is only supported for
  the same resources as sysfs exposes with mmap support, and otherwise
  rejected, so we can set the mapping unconditionally at open time
  without harm.

A special consideration is for arch_can_pci_mmap_io() - we need to
make sure that the ->f_mapping doesn't alias between ioport and iomem
space. There's only 2 ways in-tree to support mmap of ioports: generic
pci mmap (ARCH_GENERIC_PCI_MMAP_RESOURCE), and sparc as the single
architecture hand-rolling. Both approach support ioport mmap through a
special pfn range and not through magic pte attributes. Aliasing is
therefore not a problem.

The only difference in access checks left is that sysfs PCI mmap does
not check for CAP_RAWIO. I'm not really sure whether that should be
added or not.

Signed-off-by: Daniel Vetter 
Cc: Jason Gunthorpe 
Cc: Kees Cook 
Cc: Dan Williams 
Cc: Andrew Morton 
Cc: John Hubbard 
Cc: Jérôme Glisse 
Cc: Jan Kara 
Cc: Dan Williams 
Cc: Greg Kroah-Hartman 
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Bjorn Helgaas 
Cc: linux-...@vger.kernel.org
Signed-off-by: Daniel Vetter 
--
v2:
- Totally new approach: Adjust filp->f_mapping at open time. Note that
  this now works on all architectures, not just those support
  ARCH_GENERIC_PCI_MMAP_RESOURCE
---
 drivers/pci/pci-sysfs.c | 4 
 drivers/pci/proc.c  | 1 +
 2 files changed, 5 insertions(+)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 6d78df981d41..cee38fcb4a86 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -928,6 +928,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_io->read = pci_read_legacy_io;
b->legacy_io->write = pci_write_legacy_io;
b->legacy_io->mmap = pci_mmap_legacy_io;
+   b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_io);
error = device_create_bin_file(&b->dev, b->legacy_io);
if (error)
@@ -940,6 +941,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = 0600;
b->legacy_mem->mmap = pci_mmap_legacy_mem;
+   b->legacy_io->mapping = iomem_get_mapping();
pci_adjust_legacy_attr(b, pci_mmap_mem);
error = device_create_bin_file(&b->dev, b->legacy_mem);
if (error)
@@ -1155,6 +1157,8 @@ static int pci_create_attr(struct pci_dev *pdev, int num, 
int write_combine)
res_attr->mmap = pci_mmap_resource_uc;
}
}
+   if (res_attr->mmap)
+   res_attr->mapping = iomem_get_mapping();
res_attr->attr.name = res_attr_name;
res_attr->attr.mode = 0600;
res_attr->size = pci_resource_len(pdev, num);
diff --git a/drivers/pci/proc.c b/drivers/pci/proc.c
index 3a2f90beb4cb..9bab07302bbf 100644
--- a/drivers/pci/proc.c
+++ b/drivers/pci/proc.c
@@ -298,6 +298,7 @@ static int proc_bus_pci_open(struct inode *inode, struct 
file *file)
fpriv->write_combine = 0;
 
file->private_data = fpriv;
+   file->f_mapping = iomem_get_mapping();
 
return 0;
 }
-- 
2.28.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 13/65] drm/omapdrm: Annotate dma-fence critical section in commit path

2020-10-26 Thread Tomi Valkeinen
On 23/10/2020 15:21, Daniel Vetter wrote:
> Nothing special, just put the end right after hw_done(). Note that in
> one path there's a wait for the flip/update to complete. But as far as
> I understand from comments and code that's only relevant for modesets,
> and skipped if there wasn't a modeset done on a given crtc.
> 
> For a bit more clarity pull the hw_done() call out of the if/else,
> that way it's a bit clearer flow. But happy to shuffle this around as
> is seen fit.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index 2e598b8b72af..2b82a708eca6 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -68,6 +68,7 @@ static void omap_atomic_commit_tail(struct drm_atomic_state 
> *old_state)
>  {
>   struct drm_device *dev = old_state->dev;
>   struct omap_drm_private *priv = dev->dev_private;
> + bool fence_cookie = dma_fence_begin_signalling();
>  
>   priv->dispc_ops->runtime_get(priv->dispc);
>  
> @@ -90,8 +91,6 @@ static void omap_atomic_commit_tail(struct drm_atomic_state 
> *old_state)
>   omap_atomic_wait_for_completion(dev, old_state);
>  
>   drm_atomic_helper_commit_planes(dev, old_state, 0);
> -
> - drm_atomic_helper_commit_hw_done(old_state);
>   } else {
>   /*
>* OMAP3 DSS seems to have issues with the work-around above,
> @@ -101,10 +100,12 @@ static void omap_atomic_commit_tail(struct 
> drm_atomic_state *old_state)
>   drm_atomic_helper_commit_planes(dev, old_state, 0);
>  
>   drm_atomic_helper_commit_modeset_enables(dev, old_state);
> -
> - drm_atomic_helper_commit_hw_done(old_state);
>   }
>  
> + drm_atomic_helper_commit_hw_done(old_state);
> +
> + dma_fence_end_signalling(fence_cookie);
> +
>   /*
>* Wait for completion of the page flips to ensure that old buffers
>* can't be touched by the hardware anymore before cleaning up planes.
> 

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] Implement .format_mod_supported in mxsfb

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 12:52:07PM +0200, Ville Syrjälä wrote:
> On Mon, Oct 26, 2020 at 10:05:17AM +0100, Daniel Vetter wrote:
> > On Sun, Oct 25, 2020 at 4:52 PM Guido Günther  wrote:
> > >
> > > Hi Daniel,
> > > On Sat, Oct 24, 2020 at 04:59:16PM +, Daniel Abrecht wrote:
> > > > This will make sure applications which use the IN_FORMATS blob
> > > > to figure out which modifiers they can use will pick up the
> > > > linear modifier which is needed by mxsfb. Such applications
> > > > will not work otherwise if an incompatible implicit modifier
> > > > ends up being selected.
> > >
> > > Since this got broken by the switch away for the simple display
> > > pipeline helper (ae1ed0093281939b80664a687689f12436c0e874) could
> > > you add a fixes tag?
> > 
> > mxsfb is also missing setting the allow_fb_modifiers flag, without
> > which all this modifier stuff won't work great.
> 
> drm_universal_plane_init() automagically adds it if a modifier list
> is passed in.

Oh right I missed that :-/ I guess then removing the explicit setting from
drivers would be good, and maybe adding a comment to the kerneldoc about
that.

And more of a mess indeed ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: drm/ttm: new TT backend allocation pool

2020-10-26 Thread Christian König

Am 26.10.20 um 06:23 schrieb Dave Airlie:

On Mon, 26 Oct 2020 at 01:41, Christian König
 wrote:

This replaces the spaghetti code in the two existing page pools.

First of all depending on the allocation size it is between 3 (1GiB) and
5 (1MiB) times faster than the old implementation.

It makes better use of buddy pages to allow for larger physical contiguous
allocations which should result in better TLB utilization at least for amdgpu.

Instead of a completely braindead approach of filling the pool with one CPU
while another one is trying to shrink it we only give back freed pages.

This also results in much less locking contention and a trylock free MM
shrinker callback, so we can guarantee that pages are given back to the system
when needed.

Downside of this is that it takes longer for many small allocations until the
pool is filled up. We could address this, but I couldn't find an use case
where this actually matters. And we don't bother freeing large chunks of pages
any more.

The sysfs files are replaced with a single module parameter, allowing users to
override how many pages should be globally pooled in TTM. This unfortunately
breaks the UAPI slightly, but as far as we know nobody ever depended on this.

Zeroing memory coming from the pool was handled inconsistently. The
alloc_pages() based pool was zeroing it, the dma_alloc_attr() based one wasn't.
The new implementation isn't zeroing pages from the pool either and only sets
the __GFP_ZERO flag when necessary.

The implementation has only 753 lines of code compared to the over 2600 of the
old one, and also allows for saving quite a bunch of code in the drivers since
we don't need specialized handling there any more based on kernel config.

Additional to all of that there was a neat bug with IOMMU, coherent DMA
mappings and huge pages which is now fixed in the new code as well.

Please review and comment,

Interesting, 5 doesn't have appeared to make on the list, but it
definitely has some checkpatch warnings. (indents, missing spaces
etc), Please clean those up.


Well #5 is the really interesting one. Going to address the checkpatch 
warnings and send that out again with probably the first patch already 
pushed.




some other random comments on it

+   if (order) {
+   gfp_flags |= GFP_TRANSHUGE_LIGHT | __GFP_NORETRY |
+   __GFP_KSWAPD_RECLAIM;
+   gfp_flags &= ~__GFP_MOVABLE;
+   gfp_flags &= ~__GFP_COMP;
+   }

I'd like some explains of why these flags are chosen.


Good question, I don't remember fully either and have just copied them 
over from the old allocator for the hugepage case.


In general we just want a cheap try to allocate and fallback to 4k if we 
don't have enough free.


Moveable and and compound don't work with how TTMs fault mechanism 
works, so that makes sense anyway.



Otherwise I'm pretty happy with the remaining patch in the series, it
ends up with a pretty nice cleanup.

Note drm_gem_vram_helper fails to build (vmm->dev should be dev->dev possibly).


Ok, going to double check that. What I've also noticed is that QXL 
doesn't seem to have a device structure at all.


Going to support that in the new allocator as well.


Once you clean up checkpatch and make drm_gem_vram_helper build again.
For 5-13 Reviewed-by: Dave Airlie 

I've also boot tested this on nouveau and it survives the basics fine.


Nice to know. I've tested quite a bit on amdgpu and smoke tested on 
radeon/nouveau.


Going to give it a try on my AGP radeon as well when I have time.

Christian.



Dave.


Christian.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: drm/ttm: new TT backend allocation pool

2020-10-26 Thread Daniel Vetter
On Mon, Oct 26, 2020 at 1:01 PM Christian König
 wrote:
>
> Am 26.10.20 um 06:23 schrieb Dave Airlie:
> > On Mon, 26 Oct 2020 at 01:41, Christian König
> >  wrote:
> >> This replaces the spaghetti code in the two existing page pools.
> >>
> >> First of all depending on the allocation size it is between 3 (1GiB) and
> >> 5 (1MiB) times faster than the old implementation.
> >>
> >> It makes better use of buddy pages to allow for larger physical contiguous
> >> allocations which should result in better TLB utilization at least for 
> >> amdgpu.
> >>
> >> Instead of a completely braindead approach of filling the pool with one CPU
> >> while another one is trying to shrink it we only give back freed pages.
> >>
> >> This also results in much less locking contention and a trylock free MM
> >> shrinker callback, so we can guarantee that pages are given back to the 
> >> system
> >> when needed.
> >>
> >> Downside of this is that it takes longer for many small allocations until 
> >> the
> >> pool is filled up. We could address this, but I couldn't find an use case
> >> where this actually matters. And we don't bother freeing large chunks of 
> >> pages
> >> any more.
> >>
> >> The sysfs files are replaced with a single module parameter, allowing 
> >> users to
> >> override how many pages should be globally pooled in TTM. This 
> >> unfortunately
> >> breaks the UAPI slightly, but as far as we know nobody ever depended on 
> >> this.
> >>
> >> Zeroing memory coming from the pool was handled inconsistently. The
> >> alloc_pages() based pool was zeroing it, the dma_alloc_attr() based one 
> >> wasn't.
> >> The new implementation isn't zeroing pages from the pool either and only 
> >> sets
> >> the __GFP_ZERO flag when necessary.
> >>
> >> The implementation has only 753 lines of code compared to the over 2600 of 
> >> the
> >> old one, and also allows for saving quite a bunch of code in the drivers 
> >> since
> >> we don't need specialized handling there any more based on kernel config.
> >>
> >> Additional to all of that there was a neat bug with IOMMU, coherent DMA
> >> mappings and huge pages which is now fixed in the new code as well.
> >>
> >> Please review and comment,
> > Interesting, 5 doesn't have appeared to make on the list, but it
> > definitely has some checkpatch warnings. (indents, missing spaces
> > etc), Please clean those up.
>
> Well #5 is the really interesting one. Going to address the checkpatch
> warnings and send that out again with probably the first patch already
> pushed.
>
> >
> > some other random comments on it
> >
> > +   if (order) {
> > +   gfp_flags |= GFP_TRANSHUGE_LIGHT | __GFP_NORETRY |
> > +   __GFP_KSWAPD_RECLAIM;
> > +   gfp_flags &= ~__GFP_MOVABLE;
> > +   gfp_flags &= ~__GFP_COMP;
> > +   }
> >
> > I'd like some explains of why these flags are chosen.
>
> Good question, I don't remember fully either and have just copied them
> over from the old allocator for the hugepage case.
>
> In general we just want a cheap try to allocate and fallback to 4k if we
> don't have enough free.
>
> Moveable and and compound don't work with how TTMs fault mechanism
> works, so that makes sense anyway.
>
> > Otherwise I'm pretty happy with the remaining patch in the series, it
> > ends up with a pretty nice cleanup.
> >
> > Note drm_gem_vram_helper fails to build (vmm->dev should be dev->dev 
> > possibly).
>
> Ok, going to double check that. What I've also noticed is that QXL
> doesn't seem to have a device structure at all.
>
> Going to support that in the new allocator as well.

Maybe I'm off, but for dma allocations there's drm_device->dma_dev. I
don't think it matters for any ttm using driver right now, but can't
hurt to be consistent on this.
-Daniel

>
> > Once you clean up checkpatch and make drm_gem_vram_helper build again.
> > For 5-13 Reviewed-by: Dave Airlie 
> >
> > I've also boot tested this on nouveau and it survives the basics fine.
>
> Nice to know. I've tested quite a bit on amdgpu and smoke tested on
> radeon/nouveau.
>
> Going to give it a try on my AGP radeon as well when I have time.
>
> Christian.
>
> >
> > Dave.
> >
> >> Christian.
> >>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/msm: Add missing stub definition

2020-10-26 Thread Robin Murphy
DRM_MSM fails to build with DRM_MSM_DP=n; add the missing stub.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/msm/msm_drv.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index b9dd8f8f4887..0b2686b060c7 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -423,6 +423,11 @@ static inline int msm_dp_display_disable(struct msm_dp *dp,
 {
return -EINVAL;
 }
+static inline int msm_dp_display_pre_disable(struct msm_dp *dp,
+   struct drm_encoder *encoder)
+{
+   return -EINVAL;
+}
 static inline void msm_dp_display_mode_set(struct msm_dp *dp,
struct drm_encoder *encoder,
struct drm_display_mode *mode,
-- 
2.28.0.dirty

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 12/52] dt-bindings: memory: tegra124: mc: Document new interconnect property

2020-10-26 Thread Rob Herring
On Mon, 26 Oct 2020 01:16:55 +0300, Dmitry Osipenko wrote:
> Memory controller is interconnected with memory clients and with the
> External Memory Controller. Document new interconnect property which
> turns memory controller into interconnect provider.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  .../bindings/memory-controllers/nvidia,tegra124-mc.yaml  | 5 +
>  1 file changed, 5 insertions(+)
> 


My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.example.dt.yaml:
 memory-controller@70019000: '#interconnect-cells' is a required property
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml


See https://patchwork.ozlabs.org/patch/1387321

The base for the patch is generally the last rc1. Any dependencies
should be noted.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v6 13/52] dt-bindings: memory: tegra124: emc: Document new interconnect property

2020-10-26 Thread Rob Herring
On Mon, 26 Oct 2020 01:16:56 +0300, Dmitry Osipenko wrote:
> External memory controller is interconnected with memory controller and
> with external memory. Document new interconnect property which turns
> External Memory Controller into interconnect provider.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  .../bindings/memory-controllers/nvidia,tegra124-emc.yaml   | 7 +++
>  1 file changed, 7 insertions(+)
> 

Reviewed-by: Rob Herring 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] i915: Add QUIRK_EDP_CHANNEL_EQ for Dell 7200 2-in-1

2020-10-26 Thread Jason Andryuk
On Fri, Oct 23, 2020 at 8:48 AM Jason Andryuk  wrote:
>
> We're seeing channel equalization "fail" consistently coming out of DPMS
> on the eDP of a Dell Latitude 7200 2-in-1.  When the display tries to
> come out of DPMS, it briefly flashes on before going dark.  This repeats
> once per second, and the system is unusable.  ssh-ing into the system,
> it also seems to be sluggish when in this state.  You have to reboot to
> get the display back.
>
> In intel_dp_link_training_channel_equalization, lane 0 can get to state
> 0x7 by the 3rd pattern, but lane 1 never gets further than 0x1.
> [drm] ln0_1:0x0 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x0 adj_req2_3:0x0
> [drm] ln0_1:0x11 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x44 adj_req2_3:0x0
> [drm] ln0_1:0x11 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x88 adj_req2_3:0x0
> [drm] ln0_1:0x71 ln2_3:0x0 align:0x80 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0
> [drm] ln0_1:0x71 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0
> [drm] ln0_1:0x71 ln2_3:0x0 align:0x0 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0
>
> Narrow fast vs. wide slow is not an option because the max clock is
> 27 and the 1920x1280 resolution requires 2x27.
> [drm] DP link computation with lane count min/max 1/2 27/27 bpp
> min/max 18/24 pixel clock 164250KHz
>
> The display is functional even though lane 1 is in state 0x1, so just
> return success for channel equalization on eDP.
>
> Introduce QUIRK_EDP_CHANNEL_EQ and match the DMI for a Dell Latitude
> 7200 2-in-1.  This quirk allows channel equalization to succeed even
> though it failed.
>
> Workaround for https://gitlab.freedesktop.org/drm/intel/-/issues/1378

CI reported the patch doesn't apply to drm-tip.  It was developed
against 5.4 and forward ported to 5.10-rc1-ish when I submitted it.
It applied there but not to drm-tip.

5.4 & 5.6.6 is fine until DPMS.  Then when it tries to come out, it
fails link training and gives the flashing.
5.8.16 starts flashing during boot.  I guess the driver now runs link
training during boot?

drm-tip doesn't have the flashing issue.  I guess "drm/i915: Switch to
LTTPR non-transparent mode link training"  or some of the other link
training change lets the hardware succeed?

Oh, this is interesting:
kernel: i915 :00:02.0: [drm:hsw_set_signal_levels [i915]] Using
signal levels 0200
kernel: [drm:intel_dp_link_train_phy [i915]] ln0_1:0x71 ln2_3:0x0
align:0x0 sink:0x0 adj_req0_1:0x84 adj_req2_3:0x0
kernel: i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]]
Channel equalization failed 5 times
kernel: i915 :00:02.0: [drm:intel_dp_link_train_phy [i915]]
[CONNECTOR:95:eDP-1] Link Training failed at link rate = 27, lane
count = 2, at DPRX
kernel: i915 :00:02.0: [drm:intel_enable_pipe [i915]] enabling pipe A

Note DPRX above, so not using LTTPR.

Looks like the link training logic is wrong. :

intel_dp_link_training_channel_equalization fails, so
intel_dp_link_train_phy fails, but:

intel_dp_link_train_all_phys(struct intel_dp *intel_dp,
 const struct intel_crtc_state *crtc_state,
 int lttpr_count)
{
bool ret = true;
int i;

intel_dp_prepare_link_train(intel_dp, crtc_state);

for (i = lttpr_count - 1; i >= 0; i--) {
enum drm_dp_phy dp_phy = DP_PHY_LTTPR(i);

ret = intel_dp_link_train_phy(intel_dp, crtc_state, dp_phy);
intel_dp_disable_dpcd_training_pattern(intel_dp, dp_phy);

if (!ret)
break;
}

if (ret)
intel_dp_link_train_phy(intel_dp, crtc_state, DP_PHY_DPRX);

Here we don't update ret, so linking training "succeeds" for DPRX.

This does let the 7200 display "work", but it's probably not what you
want in general.

Regards,
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm: deprecate DRM_FORMAT_MOD_NONE

2020-10-26 Thread Simon Ser
DRM_FORMAT_MOD_NONE is in the list of vendors, which is pretty
confusing. We already have DRM_FORMAT_MOD_VENDOR_NONE. Move it down in
the list of format modifiers.

DRM_FORMAT_MOD_NONE is an alias for DRM_FORMAT_MOD_LINEAR, however the
name is confusing: NONE doesn't mean that the modifier is implicit,
instead it means that the layout is linear. Deprecate it.

Signed-off-by: Simon Ser 
Suggested-by: Bas Nieuwenhuizen 
Cc: Daniel Vetter 
Cc: Pekka Paalanen 
---
 include/uapi/drm/drm_fourcc.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index d720f1e8ae5e..ca1d5587b5fc 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -350,7 +350,6 @@ extern "C" {
  */
 
 /* Vendor Ids: */
-#define DRM_FORMAT_MOD_NONE   0
 #define DRM_FORMAT_MOD_VENDOR_NONE0
 #define DRM_FORMAT_MOD_VENDOR_INTEL   0x01
 #define DRM_FORMAT_MOD_VENDOR_AMD 0x02
@@ -422,6 +421,14 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_LINEAR  fourcc_mod_code(NONE, 0)
 
+/*
+ * Deprecated: use DRM_FORMAT_MOD_LINEAR instead
+ *
+ * The "none" format modifier doesn't actually mean that the modifier is
+ * implicit, instead it means that the layout is linear.
+ */
+#define DRM_FORMAT_MOD_NONE0
+
 /* Intel framebuffer modifiers */
 
 /*
-- 
2.28.0


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


  1   2   3   >