[Nouveau] [PATCH v4] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

[Lyude Paul]

Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:

nouveau :01:00.0: disp: chid 0 mthd 008c data  508c 102b

This is magic nvidia speak for "You need to have the DMA notifier offset
programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
this by doing that, and also perform an update afterwards to prevent
racing with the GPU when reading capabilities.

v2:
* Don't just program the DMA notifier offset, make sure to actually
  perform an update
v3:
* Don't call UPDATE()
* Actually read the correct notifier fields, as apparently the
  CAPABILITIES_DONE field lives in a different location than the main
  NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
  CAPABILITIES_DONE field then pre-907d cards.
v4:
* Don't forget to check the return value of core507d_read_caps()

Signed-off-by: Lyude Paul 
Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP 
interlacing support")
Cc:  # v5.8+
---
 drivers/gpu/drm/nouveau/dispnv50/core.h   |  2 +
 drivers/gpu/drm/nouveau/dispnv50/core507d.c   | 37 ++-
 drivers/gpu/drm/nouveau/dispnv50/core907d.c   | 36 +-
 drivers/gpu/drm/nouveau/dispnv50/core917d.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.h   |  2 +
 .../drm/nouveau/include/nvhw/class/cl507d.h   |  5 ++-
 .../drm/nouveau/include/nvhw/class/cl907d.h   |  4 ++
 7 files changed, 83 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h 
b/drivers/gpu/drm/nouveau/dispnv50/core.h
index 498622c0c670d..b789139e5fff6 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
@@ -44,6 +44,7 @@ int core507d_new_(const struct nv50_core_func *, struct 
nouveau_drm *, s32,
  struct nv50_core **);
 int core507d_init(struct nv50_core *);
 void core507d_ntfy_init(struct nouveau_bo *, u32);
+int core507d_read_caps(struct nv50_disp *disp, u32 offset);
 int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
 int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
 int core507d_update(struct nv50_core *, u32 *, bool);
@@ -55,6 +56,7 @@ extern const struct nv50_outp_func pior507d;
 int core827d_new(struct nouveau_drm *, s32, struct nv50_core **);
 
 int core907d_new(struct nouveau_drm *, s32, struct nv50_core **);
+int core907d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp);
 extern const struct nv50_outp_func dac907d;
 extern const struct nv50_outp_func sor907d;
 
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c 
b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
index ad1f09a143aa4..d0f2b80a32103 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
@@ -75,18 +75,51 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
 }
 
 int
-core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
+core507d_read_caps(struct nv50_disp *disp, u32 offset)
 {
struct nvif_push *push = disp->core->chan.push;
int ret;
 
-   if ((ret = PUSH_WAIT(push, 2)))
+   ret = PUSH_WAIT(push, 4);
+   if (ret)
return ret;
 
+   PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL,
+ NVDEF(NV507D, SET_NOTIFIER_CONTROL, MODE, WRITE) |
+ NVVAL(NV507D, SET_NOTIFIER_CONTROL, OFFSET, offset >> 2) |
+ NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, ENABLE));
PUSH_MTHD(push, NV507D, GET_CAPABILITIES, 0x);
+
return PUSH_KICK(push);
 }
 
+int
+core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
+{
+   struct nv50_core *core = disp->core;
+   struct nouveau_bo *bo = disp->sync;
+   s64 time;
+   int ret;
+
+   NVBO_WR32(bo, NV50_DISP_CAPS_NTFY1, NV_DISP_CORE_NOTIFIER_1, 
CAPABILITIES_1,
+ NVDEF(NV_DISP_CORE_NOTIFIER_1, 
CAPABILITIES_1, DONE, FALSE));
+
+   ret = core507d_read_caps(disp, NV50_DISP_CAPS_NTFY1);
+   if (ret < 0)
+   return ret;
+
+   time = nvif_msec(core->chan.base.device, 2000ULL,
+if (NVBO_TD32(bo, NV50_DISP_CAPS_NTFY1,
+  NV_DISP_CORE_NOTIFIER_1, CAPABILITIES_1, 
DONE, ==, TRUE))
+break;
+usleep_range(1, 2);
+);
+   if (time < 0)
+   NV_ERROR(drm, "core caps notifier timeout\n");
+
+   return 0;
+}
+
 int
 core507d_init(struct nv50_core *core)
 {
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core907d.c 
b/drivers/gpu/drm/nouveau/dispnv50/core907d.c
index b17c03529c784..45505a18aca17 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core907d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core907d.c
@@ -22,11 +22,45 

[Nouveau] [PATCH v3] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

[Lyude Paul]

Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:

nouveau :01:00.0: disp: chid 0 mthd 008c data  508c 102b

This is magic nvidia speak for "You need to have the DMA notifier offset
programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
this by doing that, and also perform an update afterwards to prevent
racing with the GPU when reading capabilities.

v2:
* Don't just program the DMA notifier offset, make sure to actually
  perform an update
v3:
* Don't call UPDATE()
* Actually read the correct notifier fields, as apparently the
  CAPABILITIES_DONE field lives in a different location than the main
  NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different
  CAPABILITIES_DONE field then pre-907d cards.

Signed-off-by: Lyude Paul 
Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP 
interlacing support")
Cc:  # v5.8+
---
 drivers/gpu/drm/nouveau/dispnv50/core.h   |  2 ++
 drivers/gpu/drm/nouveau/dispnv50/core507d.c   | 34 +--
 drivers/gpu/drm/nouveau/dispnv50/core907d.c   | 33 +-
 drivers/gpu/drm/nouveau/dispnv50/core917d.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.h   |  2 ++
 .../drm/nouveau/include/nvhw/class/cl507d.h   |  5 ++-
 .../drm/nouveau/include/nvhw/class/cl907d.h   |  4 +++
 7 files changed, 77 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h 
b/drivers/gpu/drm/nouveau/dispnv50/core.h
index 498622c0c670d..b789139e5fff6 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
@@ -44,6 +44,7 @@ int core507d_new_(const struct nv50_core_func *, struct 
nouveau_drm *, s32,
  struct nv50_core **);
 int core507d_init(struct nv50_core *);
 void core507d_ntfy_init(struct nouveau_bo *, u32);
+int core507d_read_caps(struct nv50_disp *disp, u32 offset);
 int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
 int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
 int core507d_update(struct nv50_core *, u32 *, bool);
@@ -55,6 +56,7 @@ extern const struct nv50_outp_func pior507d;
 int core827d_new(struct nouveau_drm *, s32, struct nv50_core **);
 
 int core907d_new(struct nouveau_drm *, s32, struct nv50_core **);
+int core907d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp);
 extern const struct nv50_outp_func dac907d;
 extern const struct nv50_outp_func sor907d;
 
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c 
b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
index ad1f09a143aa4..3ec4c3a238c41 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
@@ -75,18 +75,48 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
 }
 
 int
-core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
+core507d_read_caps(struct nv50_disp *disp, u32 offset)
 {
struct nvif_push *push = disp->core->chan.push;
int ret;
 
-   if ((ret = PUSH_WAIT(push, 2)))
+   ret = PUSH_WAIT(push, 4);
+   if (ret)
return ret;
 
+   PUSH_MTHD(push, NV507D, SET_NOTIFIER_CONTROL,
+ NVDEF(NV507D, SET_NOTIFIER_CONTROL, MODE, WRITE) |
+ NVVAL(NV507D, SET_NOTIFIER_CONTROL, OFFSET, offset >> 2) |
+ NVDEF(NV507D, SET_NOTIFIER_CONTROL, NOTIFY, ENABLE));
PUSH_MTHD(push, NV507D, GET_CAPABILITIES, 0x);
+
return PUSH_KICK(push);
 }
 
+int
+core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
+{
+   struct nv50_core *core = disp->core;
+   struct nouveau_bo *bo = disp->sync;
+   s64 time;
+
+   NVBO_WR32(bo, NV50_DISP_CAPS_NTFY1, NV_DISP_CORE_NOTIFIER_1, 
CAPABILITIES_1,
+ NVDEF(NV_DISP_CORE_NOTIFIER_1, 
CAPABILITIES_1, DONE, FALSE));
+
+   core507d_read_caps(disp, NV50_DISP_CAPS_NTFY1);
+
+   time = nvif_msec(core->chan.base.device, 2000ULL,
+if (NVBO_TD32(bo, NV50_DISP_CAPS_NTFY1,
+  NV_DISP_CORE_NOTIFIER_1, CAPABILITIES_1, 
DONE, ==, TRUE))
+break;
+usleep_range(1, 2);
+);
+   if (time < 0)
+   NV_ERROR(drm, "core caps notifier timeout\n");
+
+   return 0;
+}
+
 int
 core507d_init(struct nv50_core *core)
 {
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core907d.c 
b/drivers/gpu/drm/nouveau/dispnv50/core907d.c
index b17c03529c784..8a2005adb0e2f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core907d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core907d.c
@@ -22,11 +22,42 @@
 #include "core.h"
 #include "head.h"
 
+#include 
+#include 
+
+#include 
+
+#include "nouveau_bo.h"
+
+int

Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

[Lyude Paul]

On Mon, 2020-08-31 at 14:26 +1000, Ben Skeggs wrote:
> On Wed, 26 Aug 2020 at 02:52, Lyude Paul  wrote:
> > On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> > > On Tue, 25 Aug 2020 at 04:33, Lyude Paul  wrote:
> > > > Not entirely sure why this never came up when I originally tested this
> > > > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > > > appears to cause the display engine to throw an exception on driver
> > > > init, at least on my ThinkPad P72:
> > > > 
> > > > nouveau :01:00.0: disp: chid 0 mthd 008c data  508c
> > > > 102b
> > > > 
> > > > This is magic nvidia speak for "You need to have the DMA notifier offset
> > > > programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix
> > > > this by doing that, and also perform an update afterwards to prevent
> > > > racing with the GPU when reading capabilities.
> > > > 
> > > > Changes since v1:
> > > > * Don't just program the DMA notifier offset, make sure to actually
> > > >   perform an update
> > > I'm not sure there's a need to send an Update() method here, I believe
> > > GetCapabilities() is an action method on its own right?
> > > 
> > 
> > I'm not entirely sure about this part tbh. I do know that we need to call
> > GetCapabilities() _after_ the DMA notifier offset is programmed. But, my
> > assumption was that if GetCapabilities() requires a DMA notifier offset to
> > store
> > its results in, we'd probably want to fire an update or something to make
> > sure
> > that we're not reading before it finishes writing capabilities?
> We definitely want to *wait* on GetCapabilities() finishing, I believe
> it should also update the notifier the same (or similar) way Update()
> does.  But I don't think we want to send an Update() here, it'll
> actually trigger a modeset (which, on earlier HW, will tear down the
> boot mode.  Not sure about current HW, it might preserve state), and
> we may not want that to happen there.

I'm not so sure about that, as it seems like the notifier times out without the
update:

[5.142033] nouveau :1f:00.0: DRM: [DRM/:kmsChanPush] : 
00040088 mthd 0x0088 size 1 - core507d_init
[5.142037] nouveau :1f:00.0: DRM: [DRM/:kmsChanPush] 0004: 
f000-> NV507D_SET_CONTEXT_DMA_NOTIFIER
[5.142041] nouveau :1f:00.0: DRM: [DRM/:kmsChanPush] 0008: 
00040084 mthd 0x0084 size 1 - core507d_caps_init
[5.142044] nouveau :1f:00.0: DRM: [DRM/:kmsChanPush] 000c: 
8000-> NV507D_SET_NOTIFIER_CONTROL
[5.142047] nouveau :1f:00.0: DRM: [DRM/:kmsChanPush] 0010: 
0004008c mthd 0x008c size 1 - core507d_caps_init
[5.142050] nouveau :1f:00.0: DRM: [DRM/:kmsChanPush] 0014: 
-> NV507D_GET_CAPABILITIES
[7.142026] nouveau :1f:00.0: DRM: core notifier timeout
[7.142700] nouveau :1f:00.0: DRM: sor-0002-0fc1 caps: dp_interlace=0
[7.142708] nouveau :1f:00.0: DRM: sor-0002-0fc4 caps: dp_interlace=0
[7.142715] nouveau :1f:00.0: DRM: sor-0002-0f42 caps: dp_interlace=0
[7.142829] nouveau :1f:00.0: DRM: sor-0006-0f82 caps: dp_interlace=0
[7.142842] nouveau :1f:00.0: DRM: sor-0002-0f82 caps: dp_interlace=0
[7.142849] nouveau :1f:00.0: DRM: failed to create encoder 1/8/0: -19
[7.142851] nouveau :1f:00.0: DRM: Virtual-1 has no encoders, removing

Any other alternatives to UPDATE we might want to try?

> 
> Ben.
> 
> > > Ben.
> > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for
> > > > DP
> > > > interlacing support")
> > > > Cc:  # v5.8+
> > > > ---
> > > >  drivers/gpu/drm/nouveau/dispnv50/core507d.c | 25 -
> > > >  1 file changed, 19 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > > b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > > index e341f572c2696..5e86feec3b720 100644
> > > > --- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > > +++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
> > > > @@ -65,13 +65,26 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32
> > > > offset)
> > > >  int
> > > >  core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
> > > >  {
> > > > -   u32 *push = evo_wait(>core->chan, 2);
> > > > +   struct nv50_core *core = disp->core;
> > > > +   u32 interlock[NV50_DISP_INTERLOCK__SIZE] = {0};
> > > > +   u32 *push;
> > > > 
> > > > -   if (push) {
> > > > -   evo_mthd(push, 0x008c, 1);
> > > > -   evo_data(push, 0x0);
> > > > -   evo_kick(push, >core->chan);
> > > > -   }
> > > > +   core->func->ntfy_init(disp->sync, NV50_DISP_CORE_NTFY);
> > > > +
> > > > +   push = evo_wait(>chan, 4);
> > > > +   if (!push)
> > > > +   return 0;
> > > > +
> > > > +   evo_mthd(push, 0x0084, 1);
> > > > +   evo_data(push, 0x8000 | 

Re: [Nouveau] [PATCH 3/3] drm/ttm: remove io_reserve_lru handling v2

[kernel test robot]

Hi "Christian,

I love your patch! Perhaps something to improve:

[auto build test WARNING on next-20200828]
[cannot apply to linus/master v5.9-rc3 v5.9-rc2 v5.9-rc1 v5.9-rc3]
[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-make-sure-that-we-always-zero-init-mem-bus-v2/20200901-230736
base:b36c969764ab12faebb74711c942fa3e6eaf1e96
config: x86_64-randconfig-a006-20200901 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/ttm/ttm_bo_util.c: In function 'ttm_resource_iounmap':
>> drivers/gpu/drm/ttm/ttm_bo_util.c:157:31: warning: variable 'man' set but 
>> not used [-Wunused-but-set-variable]
 157 |  struct ttm_resource_manager *man;
 |   ^~~
   In file included from include/linux/energy_model.h:10,
from include/linux/device.h:16,
from include/drm/drm_print.h:32,
from include/drm/drm_mm.h:49,
from include/drm/ttm/ttm_bo_driver.h:33,
from drivers/gpu/drm/ttm/ttm_bo_util.c:32:
   At top level:
   include/linux/sched/topology.h:40:3: warning: 'sd_flag_debug' defined but 
not used [-Wunused-const-variable=]
  40 | } sd_flag_debug[] = {
 |   ^
   In file included from include/linux/energy_model.h:10,
from include/linux/device.h:16,
from include/drm/drm_print.h:32,
from include/drm/drm_mm.h:49,
from include/drm/ttm/ttm_bo_driver.h:33,
from drivers/gpu/drm/ttm/ttm_bo_util.c:32:
   include/linux/sched/topology.h:30:27: warning: 'SD_DEGENERATE_GROUPS_MASK' 
defined but not used [-Wunused-const-variable=]
  30 | static const unsigned int SD_DEGENERATE_GROUPS_MASK =
 |   ^

# 
https://github.com/0day-ci/linux/commit/640f5da8a063c527c64720caa2c7b8b29aee5bb3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Christian-K-nig/drm-ttm-make-sure-that-we-always-zero-init-mem-bus-v2/20200901-230736
git checkout 640f5da8a063c527c64720caa2c7b8b29aee5bb3
vim +/man +157 drivers/gpu/drm/ttm/ttm_bo_util.c

ba4e7d973dd09b Thomas Hellstrom 2009-06-10  152  
2966141ad2dda2 Dave Airlie  2020-08-04  153  static void 
ttm_resource_iounmap(struct ttm_bo_device *bdev,
2966141ad2dda2 Dave Airlie  2020-08-04  154 
struct ttm_resource *mem,
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  155 
void *virtual)
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  156  {
9de59bc201496f Dave Airlie  2020-08-04 @157 struct 
ttm_resource_manager *man;
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  158  
9eca33f4a13919 Dave Airlie  2020-08-04  159 man = 
ttm_manager_type(bdev, mem->mem_type);
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  160  
0c321c79627189 Jerome Glisse2010-04-07  161 if (virtual && 
mem->bus.addr == NULL)
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  162 
iounmap(virtual);
82c5da6bf8b55a Jerome Glisse2010-04-09  163 ttm_mem_io_free(bdev, 
mem);
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  164  }
ba4e7d973dd09b Thomas Hellstrom 2009-06-10  165  

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


.config.gz
Description: application/gzip
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

[Thomas Bogendoerfer]

On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> Use the proper modern API to transfer cache ownership for incoherent DMA.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/net/ethernet/seeq/sgiseeq.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/ethernet/seeq/sgiseeq.c 
> b/drivers/net/ethernet/seeq/sgiseeq.c
> index 39599bbb5d45b6..f91dae16d69a19 100644
> --- a/drivers/net/ethernet/seeq/sgiseeq.c
> +++ b/drivers/net/ethernet/seeq/sgiseeq.c
> @@ -112,14 +112,18 @@ struct sgiseeq_private {
>  
>  static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
>  {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> -DMA_FROM_DEVICE);
> + struct sgiseeq_private *sp = netdev_priv(dev);
> +
> + dma_sync_single_for_cpu(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
>  }
>  
>  static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
>  {
> - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> -DMA_TO_DEVICE);
> + struct sgiseeq_private *sp = netdev_priv(dev);
> +
> + dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
>  }

this breaks ethernet on IP22 completely, but I haven't figured out why, yet.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 08/28] MIPS: make dma_sync_*_for_cpu a little less overzealous

[Thomas Bogendoerfer]

On Wed, Aug 19, 2020 at 08:55:35AM +0200, Christoph Hellwig wrote:
> When transferring DMA ownership back to the CPU there should never
> be any writeback from the cache, as the buffer was owned by the
> device until now.  Instead it should just be invalidated for the
> mapping directions where the device could have written data.
> Note that the changes rely on the fact that kmap_atomic is stubbed
> out for the !HIGHMEM case to simplify the code a bit.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/mips/mm/dma-noncoherent.c | 44 +-
>  1 file changed, 28 insertions(+), 16 deletions(-)

Acked-by: Thomas Bogendoerfer 

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

[Christoph Hellwig]

On Tue, Sep 01, 2020 at 07:12:41PM +0200, Thomas Bogendoerfer wrote:
> On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote:
> > On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> > > Use the proper modern API to transfer cache ownership for incoherent DMA.
> > > 
> > > Signed-off-by: Christoph Hellwig 
> > > ---
> > >  drivers/net/ethernet/seeq/sgiseeq.c | 12 
> > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/net/ethernet/seeq/sgiseeq.c 
> > > b/drivers/net/ethernet/seeq/sgiseeq.c
> > > index 39599bbb5d45b6..f91dae16d69a19 100644
> > > --- a/drivers/net/ethernet/seeq/sgiseeq.c
> > > +++ b/drivers/net/ethernet/seeq/sgiseeq.c
> > > @@ -112,14 +112,18 @@ struct sgiseeq_private {
> > >  
> > >  static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
> > >  {
> > > - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> > > -DMA_FROM_DEVICE);
> > > + struct sgiseeq_private *sp = netdev_priv(dev);
> > > +
> > > + dma_sync_single_for_cpu(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> > > + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> > >  }
> > >  
> > >  static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
> > >  {
> > > - dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> > > -DMA_TO_DEVICE);
> > > + struct sgiseeq_private *sp = netdev_priv(dev);
> > > +
> > > + dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> > > + sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> > >  }
> > 
> > this breaks ethernet on IP22 completely, but I haven't figured out why, yet.
> 
> the problem is that dma_sync_single_for_cpu() doesn't flush anything
> for IP22, because it only flushes for CPUs which do speculation. So
> either MIPS arch_sync_dma_for_cpu() should always flush or sgiseeq
> needs to use a different sync funktion, when it wants to re-read descriptors
> from memory.

Well, if IP22 doesn't speculate (which I'm pretty sure is the case),
dma_sync_single_for_cpu should indeeed be a no-op.  But then there
also shouldn't be anything in the cache, as the previous
dma_sync_single_for_device should have invalidated it.  So it seems like
we are missing one (or more) ownership transfers to the device.  I'll
try to look at the the ownership management in a little more detail
tomorrow.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

[Thomas Bogendoerfer]

On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote:
> On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote:
> > Use the proper modern API to transfer cache ownership for incoherent DMA.
> > 
> > Signed-off-by: Christoph Hellwig 
> > ---
> >  drivers/net/ethernet/seeq/sgiseeq.c | 12 
> >  1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/net/ethernet/seeq/sgiseeq.c 
> > b/drivers/net/ethernet/seeq/sgiseeq.c
> > index 39599bbb5d45b6..f91dae16d69a19 100644
> > --- a/drivers/net/ethernet/seeq/sgiseeq.c
> > +++ b/drivers/net/ethernet/seeq/sgiseeq.c
> > @@ -112,14 +112,18 @@ struct sgiseeq_private {
> >  
> >  static inline void dma_sync_desc_cpu(struct net_device *dev, void *addr)
> >  {
> > -   dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> > -  DMA_FROM_DEVICE);
> > +   struct sgiseeq_private *sp = netdev_priv(dev);
> > +
> > +   dma_sync_single_for_cpu(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> > +   sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> >  }
> >  
> >  static inline void dma_sync_desc_dev(struct net_device *dev, void *addr)
> >  {
> > -   dma_cache_sync(dev->dev.parent, addr, sizeof(struct sgiseeq_rx_desc),
> > -  DMA_TO_DEVICE);
> > +   struct sgiseeq_private *sp = netdev_priv(dev);
> > +
> > +   dma_sync_single_for_device(dev->dev.parent, VIRT_TO_DMA(sp, addr),
> > +   sizeof(struct sgiseeq_rx_desc), DMA_BIDIRECTIONAL);
> >  }
> 
> this breaks ethernet on IP22 completely, but I haven't figured out why, yet.

the problem is that dma_sync_single_for_cpu() doesn't flush anything
for IP22, because it only flushes for CPUs which do speculation. So
either MIPS arch_sync_dma_for_cpu() should always flush or sgiseeq
needs to use a different sync funktion, when it wants to re-read descriptors
from memory.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

[James Bottomley]

On Wed, 2020-08-19 at 08:55 +0200, Christoph Hellwig wrote:
> Switch the 53c700 driver to only use non-coherent descriptor memory
> if it really has to because dma_alloc_coherent fails.  This doesn't
> matter for any of the platforms it runs on currently, but that will
> change soon.
> 
> To help with this two new helpers to transfer ownership to and from
> the device are added that abstract the syncing of the non-coherent
> memory. The two current bidirectional cases are mapped to transfers
> to the device, as that appears to what they are used for.  Note that
> for parisc, which is the only architecture this driver needs to use
> non-coherent memory on, the direction argument of dma_cache_sync is
> ignored, so this will not change behavior in any way.

I think this looks mostly OK, except for one misnamed parameter below. 
Unfortunately, the last non-coherent parisc was the 700 series and I no
longer own a box, so I can't test that part of it (I can fire up the
C360 to test it on a coherent arch).

[...]
> diff --git a/drivers/scsi/53c700.h b/drivers/scsi/53c700.h
> index 05fe439b66afe5..0f545b05fe611d 100644
> --- a/drivers/scsi/53c700.h
> +++ b/drivers/scsi/53c700.h
> @@ -209,6 +209,7 @@ struct NCR_700_Host_Parameters {
>  #endif
>   __u32   chip710:1;  /* set if really a 710 not
> 700 */
>   __u32   burst_length:4; /* set to 0 to disable
> 710 bursting */
> + __u32   noncoherent:1;  /* needs to use non-
> coherent DMA */
>  
>   /* NOTHING BELOW HERE NEEDS ALTERING */
>   __u32   fast:1; /* if we can alter the
> SCSI bus clock
> @@ -429,7 +430,7 @@ struct NCR_700_Host_Parameters {
>   for(i=0; i< (sizeof(A_##symbol##_used) / sizeof(__u32));
> i++) { \
>   __u32 val =
> bS_to_cpu((script)[A_##symbol##_used[i]]) + da; \
>   (script)[A_##symbol##_used[i]] = bS_to_host(val); \
> - dma_cache_sync((dev),
> &(script)[A_##symbol##_used[i]], 4, DMA_TO_DEVICE); \
> + dma_sync_to_dev((dev),
> &(script)[A_##symbol##_used[i]], 4); \
>   DEBUG((" script, patching %s at %d to %pad\n", \
>  #symbol, A_##symbol##_used[i], )); \
>   } \
> @@ -441,7 +442,7 @@ struct NCR_700_Host_Parameters {
>   dma_addr_t da = value; \
>   for(i=0; i< (sizeof(A_##symbol##_used) / sizeof(__u32));
> i++) { \
>   (script)[A_##symbol##_used[i]] = bS_to_host(da); \
> - dma_cache_sync((dev),
> &(script)[A_##symbol##_used[i]], 4, DMA_TO_DEVICE); \
> + dma_sync_to_dev((dev),
> &(script)[A_##symbol##_used[i]], 4); \
>   DEBUG((" script, patching %s at %d to %pad\n", \
>  #symbol, A_##symbol##_used[i], )); \
>   } \
> @@ -456,7 +457,7 @@ struct NCR_700_Host_Parameters {
>   val &= 0xff00; \
>   val |= ((value) & 0xff) << 16; \
>   (script)[A_##symbol##_used[i]] = bS_to_host(val); \
> - dma_cache_sync((dev),
> &(script)[A_##symbol##_used[i]], 4, DMA_TO_DEVICE); \
> + dma_sync_to_dev((dev),
> &(script)[A_##symbol##_used[i]], 4); \
>   DEBUG((" script, patching ID field %s at %d to
> 0x%x\n", \
>  #symbol, A_##symbol##_used[i], val)); \
>   } \
> @@ -470,7 +471,7 @@ struct NCR_700_Host_Parameters {
>   val &= 0x; \
>   val |= ((value) & 0x); \
>   (script)[A_##symbol##_used[i]] = bS_to_host(val); \
> - dma_cache_sync((dev),
> &(script)[A_##symbol##_used[i]], 4, DMA_TO_DEVICE); \
> + dma_sync_to_dev((dev),
> &(script)[A_##symbol##_used[i]], 4); \
>   DEBUG((" script, patching short field %s at %d to
> 0x%x\n", \
>  #symbol, A_##symbol##_used[i], val)); \
>   } \

These macro arguments need updating.  Since you changed the input from
hostdata->dev to hostdata, leaving the macro argument as dev is simply
misleading.  It needs to become hostdata or h.

James

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

[Helge Deller]

On 01.09.20 17:22, James Bottomley wrote:
> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
>>> I think this looks mostly OK, except for one misnamed parameter
>>> below. Unfortunately, the last non-coherent parisc was the 700
>>> series and I no longer own a box, so I can't test that part of it
>>> (I can fire up the C360 to test it on a coherent arch).
>>
>> I have a 715/50 that probably hasn't been powered on in 15 years if
>> you need something that old to test on (I believe the 725/100 uses
>> the 7100LC and so is coherent).  I'll need to set up a cross-compiler
>> ...
>
> I'm not going to say no to actual testing, but it's going to be a world
> of pain getting something so old going.  I do have a box of older
> systems I keep for architectural testing that I need to rummage around
> in ... I just have a vague memory that my 715 actually caught fire a
> decade ago and had to be disposed of.

I still have a zoo of machines running for such testing, including a
715/64 and two 730.
I'm going to test this git tree on the 715/64:
git://git.infradead.org/users/hch/misc.git dma_alloc_pages

Helge
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

[Thomas Bogendoerfer]

On Tue, Sep 01, 2020 at 07:16:27PM +0200, Christoph Hellwig wrote:
> Well, if IP22 doesn't speculate (which I'm pretty sure is the case),
> dma_sync_single_for_cpu should indeeed be a no-op.  But then there
> also shouldn't be anything in the cache, as the previous
> dma_sync_single_for_device should have invalidated it.  So it seems like
> we are missing one (or more) ownership transfers to the device.  I'll
> try to look at the the ownership management in a little more detail
> tomorrow.

this is the problem:

   /* Always check for received packets. */
sgiseeq_rx(dev, sp, hregs, sregs);

so the driver will look at the rx descriptor on every interrupt, so
we cache the rx descriptor on the first interrupt and if there was
$no rx packet, we will only see it, if cache line gets flushed for
some other reason. kick_tx() does a busy loop checking tx descriptors,
with just sync_desc_cpu...

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

[Lyude Paul]

Super minor nitpicks:

On Tue, 2020-09-01 at 16:22 +1000, Sam McNally wrote:
> From: Hans Verkuil 
> 
> Signed-off-by: Hans Verkuil 
> [sa...@chromium.org:
>  - rebased
>  - removed polling-related changes
>  - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
> ]
> Signed-off-by: Sam McNally 
> ---
> 
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
>  drivers/gpu/drm/drm_dp_cec.c  | 22 ++-
>  drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
>  include/drm/drm_dp_helper.h   |  6 +++--
>  5 files changed, 19 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 461fa4da0a34..6e7075893ec9 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
>  
>   drm_dp_aux_init(>dm_dp_aux.aux);
>   drm_dp_cec_register_connector(>dm_dp_aux.aux,
> -   >base);
> +   >base, false);
>  
>   if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
>   return;
> diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
> index 3ab2609f9ec7..04ab7b88055c 100644
> --- a/drivers/gpu/drm/drm_dp_cec.c
> +++ b/drivers/gpu/drm/drm_dp_cec.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /*
>   * Unfortunately it turns out that we have a chicken-and-egg situation
> @@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>   if (aux->cec.adap) {
>   if (aux->cec.adap->capabilities == cec_caps &&
>   aux->cec.adap->available_log_addrs == num_las) {
> - /* Unchanged, so just set the phys addr */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
>   goto unlock;
>   }

May as well drop the braces here

>   /*
> @@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const
> struct edid *edid)
>   if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
>   cec_delete_adapter(aux->cec.adap);
>   aux->cec.adap = NULL;
> - } else {
> - /*
> -  * Update the phys addr for the new CEC adapter. When called
> -  * from drm_dp_cec_register_connector() edid == NULL, so in
> -  * that case the phys addr is just invalidated.
> -  */
> - cec_s_phys_addr_from_edid(aux->cec.adap, edid);
>   }
>  unlock:
> + /*
> +  * Update the phys addr for the new CEC adapter. When called
> +  * from drm_dp_cec_register_connector() edid == NULL, so in
> +  * that case the phys addr is just invalidated.
> +  */
> + if (aux->cec.adap && edid) {
> + cec_s_phys_addr_from_edid(aux->cec.adap, edid);
> + }

And here

>   mutex_unlock(>cec.lock);
>  }
>  EXPORT_SYMBOL(drm_dp_cec_set_edid);
> @@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
>   * drm_dp_cec_register_connector() - register a new connector
>   * @aux: DisplayPort AUX channel
>   * @connector: drm connector
> + * @is_mst: set to true if this is an MST branch
>   *
>   * A new connector was registered with associated CEC adapter name and
>   * CEC adapter parent device. After registering the name and parent
> @@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
>   * CEC and to register a CEC adapter if that is the case.
>   */
>  void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
> -struct drm_connector *connector)
> +struct drm_connector *connector, bool is_mst)
>  {
>   WARN_ON(aux->cec.adap);
>   if (WARN_ON(!aux->transfer))
>   return;
>   aux->cec.connector = connector;
> + aux->cec.is_mst = is_mst;

Also JFYI, you can also check aux->is_remote, but maybe you've got another
reason for copying this here

Either way:

Reviewed-by: Lyude Paul 

...Also, maybe this is just a coincidence - but do I know your name from
somewhere? Perhaps an IRC community from long ago?

>   INIT_DELAYED_WORK(>cec.unregister_work,
> drm_dp_cec_unregister_work);
>  }
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 82b9de274f65..744cb55572f9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6261,7 +6261,7 @@ intel_dp_connector_register(struct drm_connector
> *connector)
>   intel_dp->aux.dev = connector->kdev;
>   ret = drm_dp_aux_register(_dp->aux);
>   if 

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

[James Bottomley]

On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> > I think this looks mostly OK, except for one misnamed parameter
> > below. Unfortunately, the last non-coherent parisc was the 700
> > series and I no longer own a box, so I can't test that part of it
> > (I can fire up the C360 to test it on a coherent arch).
> 
> I have a 715/50 that probably hasn't been powered on in 15 years if
> you need something that old to test on (I believe the 725/100 uses
> the 7100LC and so is coherent).  I'll need to set up a cross-compiler 
> ...

I'm not going to say no to actual testing, but it's going to be a world
of pain getting something so old going.  I do have a box of older
systems I keep for architectural testing that I need to rummage around
in ... I just have a vague memory that my 715 actually caught fire a
decade ago and had to be disposed of.

James

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

[Matthew Wilcox]

On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote:
> > I still have a zoo of machines running for such testing, including a
> > 715/64 and two 730.
> > I'm going to test this git tree on the 715/64:

The 715/64 is a 7100LC machine though.  I think you need to boot on
the 730 to test the non-coherent path.

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

[Tomasz Figa]

On Tue, Sep 1, 2020 at 1:06 PM Christoph Hellwig  wrote:
>
> On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote:
> > > It wasn't meant to be too insulting, but I found this out when trying
> > > to figure out how to just disable it.  But it also ends up using
> > > the actual dma attr flags for it's own consistency checks, so just
> > > not setting the flag did not turn out to work that easily.
> > >
> >
> > Yes, sadly the videobuf2 ended up becoming quite counterintuitive
> > after growing for the long years and that is reflected in the design
> > of this feature as well. I think we need to do something about it.
>
> So I'm about to respin the series and wonder how we should proceed.
> I've failed to come up with a clean patch to keep the flag and make
> it a no-op.  Can you or your team give it a spin?
>

Okay, I'll take a look.

> Also I wonder if the flag should be renamed from NON_CONSISTENT
> to NON_COHERENT - the consistent thing is a weird wart from the times
> the old PCI DMA API that is mostly gone now.

It originated from the DMA_ATTR_NON_CONSISTENT flag, but agreed that
NON_COHERENT would be more consistent (pun not intended) with the rest
of the DMA API given the removal of that flag. Let me see if we can
still change it.

Best regards,
Tomasz
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 06/28] lib82596: move DMA allocation into the callers of i82596_probe

[Thomas Bogendoerfer]

On Wed, Aug 19, 2020 at 08:55:33AM +0200, Christoph Hellwig wrote:
> This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare
> for untangling the coherent vs non-coherent DMA allocation API.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  drivers/net/ethernet/i825xx/lasi_82596.c | 24 ++--
>  drivers/net/ethernet/i825xx/lib82596.c   | 36 
>  drivers/net/ethernet/i825xx/sni_82596.c  | 19 +
>  3 files changed, 40 insertions(+), 39 deletions(-)
> 
> [...]
> diff --git a/drivers/net/ethernet/i825xx/sni_82596.c 
> b/drivers/net/ethernet/i825xx/sni_82596.c
> index 22f5887578b2bd..e80e790ffbd4d4 100644
> --- a/drivers/net/ethernet/i825xx/sni_82596.c
> +++ b/drivers/net/ethernet/i825xx/sni_82596.c
> @@ -24,8 +24,6 @@
>  
>  static const char sni_82596_string[] = "snirm_82596";
>  
> -#define LIB82596_DMA_ATTR0
> -
>  #define DMA_WBACK(priv, addr, len) do { } while (0)
>  #define DMA_INV(priv, addr, len)   do { } while (0)
>  #define DMA_WBACK_INV(priv, addr, len) do { } while (0)
> @@ -134,10 +132,19 @@ static int sni_82596_probe(struct platform_device *dev)
>   lp->ca = ca_addr;
>   lp->mpu_port = mpu_addr;
>  
> + lp->dma = dma_alloc_coherent(dev->dev.parent, sizeof(struct i596_dma),
> +  >dma_addr, GFP_KERNEL);

this needs to use >dev as device argument otherwise I get a

WARNING: CPU: 0 PID: 1 at linux/kernel/dma/mapping.c:416 
dma_alloc_attrs+0x64/0x98

(coherent_dma_mask is set correctly).

dev->dev.parent was correct when going from netdevice to underlying device,
but now allocation is done via platform_device probe. I wonder why this works
for parisc.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 09/28] MIPS/jazzdma: remove the unused vdma_remap function

[Thomas Bogendoerfer]

On Wed, Aug 19, 2020 at 08:55:36AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/mips/include/asm/jazzdma.h |  2 -
>  arch/mips/jazz/jazzdma.c| 70 -
>  2 files changed, 72 deletions(-)

Acked-by: Thomas Bogendoerfer 

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 10/28] MIPS/jazzdma: decouple from dma-direct

[Thomas Bogendoerfer]

On Wed, Aug 19, 2020 at 08:55:37AM +0200, Christoph Hellwig wrote:
> The jazzdma ops implement support for a very basic IOMMU.  Thus we really
> should not use the dma-direct code that takes physical address limits
> into account.  This survived through the great MIPS DMA ops cleanup mostly
> because I was lazy, but now it is time to fully split the implementations.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/mips/jazz/jazzdma.c | 32 +---
>  1 file changed, 21 insertions(+), 11 deletions(-)

Acked-by: Thomas Bogendoerfer 

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

[Helge Deller]

On 01.09.20 18:21, Helge Deller wrote:
> On 01.09.20 17:22, James Bottomley wrote:
>> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote:
>>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
 I think this looks mostly OK, except for one misnamed parameter
 below. Unfortunately, the last non-coherent parisc was the 700
 series and I no longer own a box, so I can't test that part of it
 (I can fire up the C360 to test it on a coherent arch).
>>>
>>> I have a 715/50 that probably hasn't been powered on in 15 years if
>>> you need something that old to test on (I believe the 725/100 uses
>>> the 7100LC and so is coherent).  I'll need to set up a cross-compiler
>>> ...
>>
>> I'm not going to say no to actual testing, but it's going to be a world
>> of pain getting something so old going.  I do have a box of older
>> systems I keep for architectural testing that I need to rummage around
>> in ... I just have a vague memory that my 715 actually caught fire a
>> decade ago and had to be disposed of.
>
> I still have a zoo of machines running for such testing, including a
> 715/64 and two 730.
> I'm going to test this git tree on the 715/64:
> git://git.infradead.org/users/hch/misc.git dma_alloc_pages

This tree boots nicely (up to a command prompt with i82596 nic working):

53c700: Version 2.8 By james.bottom...@hansenpartnership.com
scsi0: 53c710 rev 2
scsi host0: LASI SCSI 53c700
scsi 0:0:6:0: Direct-Access QUANTUM  FIREBALL_TM3200S 300X PQ: 0 ANSI: 2
scsi target0:0:6: Beginning Domain Validation
scsi 0:0:6:0: tag#56 Enabling Tag Command Queuing
scsi target0:0:6: asynchronous
scsi target0:0:6: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 8)
scsi target0:0:6: Domain Validation skipping write tests
scsi target0:0:6: Ending Domain Validation
scsi 0:0:6:1: tag#63 Disabling Tag Command Queuing
st: Version 20160209, fixed bufsize 32768, s/g segs 256
sd 0:0:6:0: Power-on or device reset occurred
sd 0:0:6:0: Attached scsi generic sg0 type 0
LASI 82596 driver - Revision: 1.30
Found i82596 at 0xf0107000, IRQ 17
eth0: 82596 at 0xf0107000, 08:00:09:c2:9e:60 IRQ 17.
sd 0:0:6:0: [sda] 6281856 512-byte logical blocks: (3.22 GB/3.00 GiB)
sd 0:0:6:0: [sda] Write Protect is off

Christoph, you may add a
Tested-by: Helge Deller  # parisc
to the series.

Helge
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

[Matthew Wilcox]

On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote:
> I think this looks mostly OK, except for one misnamed parameter below. 
> Unfortunately, the last non-coherent parisc was the 700 series and I no
> longer own a box, so I can't test that part of it (I can fire up the
> C360 to test it on a coherent arch).

I have a 715/50 that probably hasn't been powered on in 15 years if you
need something that old to test on (I believe the 725/100 uses the 7100LC
and so is coherent).  I'll need to set up a cross-compiler ...
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] VAAPI on GeForce GT 620M

[Julien Isorce]

Hi,

Try:  DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo --display drm --device
/dev/dri/renderD129

Also try with and without the --device option, the important one is
--display drm

Cheers
Julien

On Tue, Sep 1, 2020 at 10:49 AM Analabha Roy  wrote:

>
>
> On Tue, 1 Sep 2020 at 18:59, Ilia Mirkin  wrote:
>
>> On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy 
>> wrote:
>> > Any suggestions on how to trace the config issues? Do I have to debug
>> the va_openDriver() function?
>>
>> My guess, without reading any code, is that DRI_PRIME isn't doing what
>> you want it to, and the nouveau driver is being handed an intel
>> device. This does not work well. Fixing this will require tracing
>> through the va winsys code which to figure out how it invokes the
>> loader.
>>
>>
>> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/frontends/va/context.c#n111
>>
>> For the DRM/rendernodes "platform", it will just take whatever fd it
>> is given. vainfo appears to give it a fixed device:
>>
>>
>> https://github.com/intel/libva-utils/blob/master/common/va_display_drm.c#L39
>>
>> However it looks like you can pass in --device /dev/dri/renderD129 or
>> whatever the right one is, which should pass in the right render node,
>> as seen here:
>>
>> https://github.com/intel/libva-utils/blob/master/common/va_display.c#L80
>>
>> Note that I've never tried this, just did a few google searches to
>> find this stuff.
>>
>>
> Brilliant googling. get_drm_device_name() does seem to do a crude argparse
> of "--device"
>
> So I ran
>
> $ DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo --device /dev/dri/renderD128
>
> *vainfo: unrecognized option '--device'*Show information from VA-API
> driver
> Usage: vainfo --help
> --help print this message
>
> Usage: vainfo [options]
> Display options:
> --display display | help Show information for the
> specified display, or the available display list
>
> *--device device  Set device name, only available
> under drm display*
>
>
> What does this mean?
>
>  Note that I also ran
>
>
> $ nm -Dn -o /usr/lib/x86_64-linux-gnu/libva*|grep get_drm_device_name
>
> Didn't get anything...
>
> Cheers,
>>
>>   -ilia
>>
>
>
> --
> Analabha Roy
> Assistant Professor
> Department of Physics
> 
> The University of Burdwan 
> Golapbag Campus, Barddhaman 713104
> West Bengal, India
> Emails: dan...@utexas.edu, a...@phys.buruniv.ac.in, hariseldo...@gmail.com
> Webpage: http://www.ph.utexas.edu/~daneel/
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] VAAPI on GeForce GT 620M

[Analabha Roy]

On Tue, 1 Sep 2020 at 18:59, Ilia Mirkin  wrote:

> On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy 
> wrote:
> > Any suggestions on how to trace the config issues? Do I have to debug
> the va_openDriver() function?
>
> My guess, without reading any code, is that DRI_PRIME isn't doing what
> you want it to, and the nouveau driver is being handed an intel
> device. This does not work well. Fixing this will require tracing
> through the va winsys code which to figure out how it invokes the
> loader.
>
>
> https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/frontends/va/context.c#n111
>
> For the DRM/rendernodes "platform", it will just take whatever fd it
> is given. vainfo appears to give it a fixed device:
>
>
> https://github.com/intel/libva-utils/blob/master/common/va_display_drm.c#L39
>
> However it looks like you can pass in --device /dev/dri/renderD129 or
> whatever the right one is, which should pass in the right render node,
> as seen here:
>
> https://github.com/intel/libva-utils/blob/master/common/va_display.c#L80
>
> Note that I've never tried this, just did a few google searches to
> find this stuff.
>
>
Brilliant googling. get_drm_device_name() does seem to do a crude argparse
of "--device"

So I ran

$ DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo --device /dev/dri/renderD128

*vainfo: unrecognized option '--device'*Show information from VA-API driver
Usage: vainfo --help
--help print this message

Usage: vainfo [options]
Display options:
--display display | help Show information for the specified
display, or the available display list

*--device device  Set device name, only available
under drm display*


What does this mean?

 Note that I also ran


$ nm -Dn -o /usr/lib/x86_64-linux-gnu/libva*|grep get_drm_device_name

Didn't get anything...

Cheers,
>
>   -ilia
>


-- 
Analabha Roy
Assistant Professor
Department of Physics

The University of Burdwan 
Golapbag Campus, Barddhaman 713104
West Bengal, India
Emails: dan...@utexas.edu, a...@phys.buruniv.ac.in, hariseldo...@gmail.com
Webpage: http://www.ph.utexas.edu/~daneel/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 3/3] drm/ttm: remove io_reserve_lru handling v2

[Christian König]

From: Christian König 

That is not used any more.

v2: keep the NULL checks in TTM.

Signed-off-by: Christian König 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/ttm/ttm_bo.c   |  34 +
 drivers/gpu/drm/ttm/ttm_bo_util.c  | 113 +++--
 drivers/gpu/drm/ttm/ttm_bo_vm.c|  39 +++---
 drivers/gpu/drm/ttm/ttm_resource.c |   3 -
 include/drm/ttm/ttm_bo_api.h   |   1 -
 include/drm/ttm/ttm_bo_driver.h|   5 --
 include/drm/ttm/ttm_resource.h |  16 
 7 files changed, 24 insertions(+), 187 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 772c640a6046..89d8ab6edd40 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -263,11 +263,7 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object 
*bo,
struct ttm_resource_manager *new_man = ttm_manager_type(bdev, 
mem->mem_type);
int ret;
 
-   ret = ttm_mem_io_lock(old_man, true);
-   if (unlikely(ret != 0))
-   goto out_err;
-   ttm_bo_unmap_virtual_locked(bo);
-   ttm_mem_io_unlock(old_man);
+   ttm_bo_unmap_virtual(bo);
 
/*
 * Create and bind a ttm if required.
@@ -538,7 +534,6 @@ static void ttm_bo_release(struct kref *kref)
struct ttm_buffer_object *bo =
container_of(kref, struct ttm_buffer_object, kref);
struct ttm_bo_device *bdev = bo->bdev;
-   struct ttm_resource_manager *man = ttm_manager_type(bdev, 
bo->mem.mem_type);
size_t acc_size = bo->acc_size;
int ret;
 
@@ -556,9 +551,7 @@ static void ttm_bo_release(struct kref *kref)
bo->bdev->driver->release_notify(bo);
 
drm_vma_offset_remove(bdev->vma_manager, >base.vma_node);
-   ttm_mem_io_lock(man, false);
-   ttm_mem_io_free_vm(bo);
-   ttm_mem_io_unlock(man);
+   ttm_mem_io_free(bdev, >mem);
}
 
if (!dma_resv_test_signaled_rcu(bo->base.resv, true) ||
@@ -648,8 +641,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
 
evict_mem = bo->mem;
evict_mem.mm_node = NULL;
-   evict_mem.bus.io_reserved_vm = false;
-   evict_mem.bus.io_reserved_count = 0;
evict_mem.bus.base = 0;
evict_mem.bus.offset = 0;
evict_mem.bus.addr = NULL;
@@ -1085,8 +1076,6 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
mem.num_pages = bo->num_pages;
mem.size = mem.num_pages << PAGE_SHIFT;
mem.page_alignment = bo->mem.page_alignment;
-   mem.bus.io_reserved_vm = false;
-   mem.bus.io_reserved_count = 0;
mem.bus.base = 0;
mem.bus.offset = 0;
mem.bus.addr = NULL;
@@ -1238,7 +1227,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(>lru);
INIT_LIST_HEAD(>ddestroy);
INIT_LIST_HEAD(>swap);
-   INIT_LIST_HEAD(>io_reserve_lru);
bo->bdev = bdev;
bo->type = type;
bo->num_pages = num_pages;
@@ -1247,8 +1235,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->mem.num_pages = bo->num_pages;
bo->mem.mm_node = NULL;
bo->mem.page_alignment = page_alignment;
-   bo->mem.bus.io_reserved_vm = false;
-   bo->mem.bus.io_reserved_count = 0;
bo->mem.bus.base = 0;
bo->mem.bus.offset = 0;
bo->mem.bus.addr = NULL;
@@ -1554,25 +1540,13 @@ EXPORT_SYMBOL(ttm_bo_device_init);
  * buffer object vm functions.
  */
 
-void ttm_bo_unmap_virtual_locked(struct ttm_buffer_object *bo)
-{
-   struct ttm_bo_device *bdev = bo->bdev;
-
-   drm_vma_node_unmap(>base.vma_node, bdev->dev_mapping);
-   ttm_mem_io_free_vm(bo);
-}
-
 void ttm_bo_unmap_virtual(struct ttm_buffer_object *bo)
 {
struct ttm_bo_device *bdev = bo->bdev;
-   struct ttm_resource_manager *man = ttm_manager_type(bdev, 
bo->mem.mem_type);
 
-   ttm_mem_io_lock(man, false);
-   ttm_bo_unmap_virtual_locked(bo);
-   ttm_mem_io_unlock(man);
+   drm_vma_node_unmap(>base.vma_node, bdev->dev_mapping);
+   ttm_mem_io_free(bdev, >mem);
 }
-
-
 EXPORT_SYMBOL(ttm_bo_unmap_virtual);
 
 int ttm_bo_wait(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index ee04716b2603..40ded10055d2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -91,122 +91,42 @@ int ttm_bo_move_ttm(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_move_ttm);
 
-int ttm_mem_io_lock(struct ttm_resource_manager *man, bool interruptible)
-{
-   if (likely(!man->use_io_reserve_lru))
-   return 0;
-
-   if (interruptible)
-   return mutex_lock_interruptible(>io_reserve_mutex);
-
-   mutex_lock(>io_reserve_mutex);
-   return 0;
-}
-
-void ttm_mem_io_unlock(struct ttm_resource_manager *man)
-{
-   if (likely(!man->use_io_reserve_lru))
-   return;
-
-   

[Nouveau] [PATCH 2/3] drm/nouveau: move io_reserve_lru handling into the driver v5

[Christian König]

While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.

In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.

v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
v3: rebased and use both base and offset in the check
v4: fix small typos and test the patch
v5: rebased and keep the mem.bus init in TTM.

Signed-off-by: Christian König 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 101 --
 drivers/gpu/drm/nouveau/nouveau_bo.h  |   3 +
 drivers/gpu/drm/nouveau/nouveau_drv.h |   2 +
 drivers/gpu/drm/nouveau/nouveau_ttm.c |  44 ++-
 4 files changed, 127 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 9140387f30dc..f74988771ed8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -137,6 +137,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct nouveau_bo *nvbo = nouveau_bo(bo);
 
WARN_ON(nvbo->pin_refcnt > 0);
+   nouveau_bo_del_io_reserve_lru(bo);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
 
/*
@@ -304,6 +305,7 @@ nouveau_bo_init(struct nouveau_bo *nvbo, u64 size, int 
align, u32 flags,
 
nvbo->bo.mem.num_pages = size >> PAGE_SHIFT;
nouveau_bo_placement_set(nvbo, flags, 0);
+   INIT_LIST_HEAD(>io_reserve_lru);
 
ret = ttm_bo_init(nvbo->bo.bdev, >bo, size, type,
  >placement, align >> PAGE_SHIFT, false,
@@ -574,6 +576,26 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
PAGE_SIZE, DMA_FROM_DEVICE);
 }
 
+void nouveau_bo_add_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+   struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+   mutex_lock(>ttm.io_reserve_mutex);
+   list_move_tail(>io_reserve_lru, >ttm.io_reserve_lru);
+   mutex_unlock(>ttm.io_reserve_mutex);
+}
+
+void nouveau_bo_del_io_reserve_lru(struct ttm_buffer_object *bo)
+{
+   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
+   struct nouveau_bo *nvbo = nouveau_bo(bo);
+
+   mutex_lock(>ttm.io_reserve_mutex);
+   list_del_init(>io_reserve_lru);
+   mutex_unlock(>ttm.io_reserve_mutex);
+}
+
 int
 nouveau_bo_validate(struct nouveau_bo *nvbo, bool interruptible,
bool no_wait_gpu)
@@ -888,6 +910,8 @@ nouveau_bo_move_ntfy(struct ttm_buffer_object *bo, bool 
evict,
if (bo->destroy != nouveau_bo_del_ttm)
return;
 
+   nouveau_bo_del_io_reserve_lru(bo);
+
if (mem && new_reg->mem_type != TTM_PL_SYSTEM &&
mem->mem.page == nvbo->page) {
list_for_each_entry(vma, >vma_list, head) {
@@ -1018,17 +1042,42 @@ nouveau_bo_verify_access(struct ttm_buffer_object *bo, 
struct file *filp)
  filp->private_data);
 }
 
+static void
+nouveau_ttm_io_mem_free_locked(struct nouveau_drm *drm,
+  struct ttm_resource *reg)
+{
+   struct nouveau_mem *mem = nouveau_mem(reg);
+
+   if (drm->client.mem->oclass >= NVIF_CLASS_MEM_NV50) {
+   switch (reg->mem_type) {
+   case TTM_PL_TT:
+   if (mem->kind)
+   nvif_object_unmap_handle(>mem.object);
+   break;
+   case TTM_PL_VRAM:
+   nvif_object_unmap_handle(>mem.object);
+   break;
+   default:
+   break;
+   }
+   }
+}
+
 static int
 nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_resource 
*reg)
 {
struct nouveau_drm *drm = nouveau_bdev(bdev);
struct nvkm_device *device = nvxx_device(>client.device);
struct nouveau_mem *mem = nouveau_mem(reg);
+   int ret;
 
+   mutex_lock(>ttm.io_reserve_mutex);
+retry:
switch (reg->mem_type) {
case TTM_PL_SYSTEM:
/* System memory */
-   return 0;
+   ret = 0;
+   goto out;
case TTM_PL_TT:
 #if IS_ENABLED(CONFIG_AGP)
if (drm->agp.bridge) {
@@ -1037,9 +1086,12 @@ nouveau_ttm_io_mem_reserve(struct ttm_bo_device *bdev, 
struct ttm_resource *reg)
reg->bus.is_iomem = !drm->agp.cma;
}
 #endif
-   if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 || !mem->kind)
+   if (drm->client.mem->oclass < NVIF_CLASS_MEM_NV50 ||
+   !mem->kind) {
/* untiled */
+   ret = 0;
break;
+   }
fallthrough;/* tiled memory */
case TTM_PL_VRAM:
reg->bus.offset = reg->start << 

[Nouveau] [PATCH 1/3] drm/ttm: make sure that we always zero init mem.bus v2

[Christian König]

We are trying to remove the io_lru handling and depend
on zero init base, offset and addr here.

v2: init addr as well

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e3931e515906..772c640a6046 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -650,6 +650,9 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
evict_mem.mm_node = NULL;
evict_mem.bus.io_reserved_vm = false;
evict_mem.bus.io_reserved_count = 0;
+   evict_mem.bus.base = 0;
+   evict_mem.bus.offset = 0;
+   evict_mem.bus.addr = NULL;
 
ret = ttm_bo_mem_space(bo, , _mem, ctx);
if (ret) {
@@ -1084,6 +1087,9 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
mem.page_alignment = bo->mem.page_alignment;
mem.bus.io_reserved_vm = false;
mem.bus.io_reserved_count = 0;
+   mem.bus.base = 0;
+   mem.bus.offset = 0;
+   mem.bus.addr = NULL;
mem.mm_node = NULL;
 
/*
@@ -1243,6 +1249,9 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
bo->mem.page_alignment = page_alignment;
bo->mem.bus.io_reserved_vm = false;
bo->mem.bus.io_reserved_count = 0;
+   bo->mem.bus.base = 0;
+   bo->mem.bus.offset = 0;
+   bo->mem.bus.addr = NULL;
bo->moving = NULL;
bo->mem.placement = (TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED);
bo->acc_size = acc_size;
-- 
2.17.1

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] VAAPI on GeForce GT 620M

[Ilia Mirkin]

On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy  wrote:
> Any suggestions on how to trace the config issues? Do I have to debug the 
> va_openDriver() function?

My guess, without reading any code, is that DRI_PRIME isn't doing what
you want it to, and the nouveau driver is being handed an intel
device. This does not work well. Fixing this will require tracing
through the va winsys code which to figure out how it invokes the
loader.

https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/frontends/va/context.c#n111

For the DRM/rendernodes "platform", it will just take whatever fd it
is given. vainfo appears to give it a fixed device:

https://github.com/intel/libva-utils/blob/master/common/va_display_drm.c#L39

However it looks like you can pass in --device /dev/dri/renderD129 or
whatever the right one is, which should pass in the right render node,
as seen here:

https://github.com/intel/libva-utils/blob/master/common/va_display.c#L80

Note that I've never tried this, just did a few google searches to
find this stuff.

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] VAAPI on GeForce GT 620M

[Analabha Roy]

>
> It does indicate a config problem, but why do you want to use the
> nvidia GPU for video accel? I'd rely on intel to provide acceleration
> as this also reduces power consumption of the entire system. Also I
> think vaapi on the secondary GPU is pretty much untested.



Well you've got a point there. It's just that the dang nvidia is pretty
much sitting there on its hiney doing nothing (the mediaserver is running
headless), while the CPU block is doing all the heavy lifting (I'm running
torznab grabbers, DLNA streaming etc off an old laptop whose screen's
busted).

I tried nvenc/nvdec, but the 650M doesn't seem to support it according to my
reading of the support page

Doesn't support CUDA either, it seems. so I switched the hardware
transcoding to vaapi on the intel gpu.

I figure if the nvidia took some load off then the heat would be more
evenly distributed across the motherboard, increasing the server's shelf
life, plus the nvidia actually gets to do something.

On Tue, 1 Sep 2020 at 18:01, Ilia Mirkin  wrote:

> On Tue, Sep 1, 2020 at 3:31 AM Analabha Roy 
> wrote:
> >
> > Hi,
> >
> > If I am reading the featurematrix right, VAAPI is supported for nouveau
> on the GeForce650M (my card).
> >
> > Here is the output of inxi -F
> >
> > System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64
> Console: tty 1 Distro: Ubuntu 18.04.5 LTS
> > Machine:   Device: laptop System: SAMSUNG product: 300E4C/300E5C/300E7C
> v: 0.1 serial: N/A
> >Mobo: SAMSUNG model: NP300E5X-U01IN v: FAB1 serial: N/A
> >UEFI [Legacy]: Phoenix v: P06RAC date: 10/25/2012
> > BatteryBAT1: charge: 47.5 Wh 100.0% condition: 47.5/47.5 Wh (100%)
> > CPU:   Dual core Intel Core i3-2310M (-MT-MCP-) cache: 3072 KB
> >clock speeds: max: 2100 MHz 1: 835 MHz 2: 1031 MHz 3: 905 MHz
> 4: 927 MHz
> > Graphics:  Card-1: Intel 2nd Generation Core Processor Family Integrated
> Graphics Controller
> >Card-2: NVIDIA GF108M [GeForce GT 620M]
> >Display Server: X.org 1.20.8 driver: i915 tty size: 171x45
> Advanced Data: N/A out of X
> >
> >
> > I have installed nouveau, and extracted the firmware from the prop
> nvidia drivers separately as per instructions on
> https://nouveau.freedesktop.org/wiki/VideoAcceleration/
> > See installed firmware @ https://pastebin.com/Gaqxb88g
> >
> > But running vainfo yields error: https://pastebin.com/NyULBhXt
> >
> > Does the error mean that VAAPI is unsupported, or does it indicate a
> config problem?
>
> As Karol suggests, using the onboard CPU's decoding capabilities will
> yield better results. However if there's some specific reason you
> want/need to use the NVIDIA card, it should still work. I note that
> you don't have an X server running - is that on purpose?


Yes. This is a headless media server hosting jellyfin. Hence the tinkering
around with hardware transcoding.
This was an old laptop whose screen got busted, so am repurposing as a
media server/streamer.


> I believe
> that va-api needs some sort of winsys to be available, but I guess I'm
> not entirely sure.
>
>
vainfo works off the intel driver even though there is no X running:
https://pastebin.com/pnaAMCFd

vaapi is happily transcoding off the intel on the headless machine if I'm
reading the ffmpeg logs correctly


> Do you see any errors in dmesg after running vainfo?
>
>
nope.


> Cheers,
>
>   -ilia
>


Any suggestions on how to trace the config issues? Do I have to debug
the va_openDriver() function?

-- 
Analabha Roy
Assistant Professor
Department of Physics

The University of Burdwan 
Golapbag Campus, Barddhaman 713104
West Bengal, India
Emails: dan...@utexas.edu, a...@phys.buruniv.ac.in, hariseldo...@gmail.com
Webpage: http://www.ph.utexas.edu/~daneel/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] VAAPI on GeForce GT 620M

[Ilia Mirkin]

On Tue, Sep 1, 2020 at 3:31 AM Analabha Roy  wrote:
>
> Hi,
>
> If I am reading the featurematrix right, VAAPI is supported for nouveau on 
> the GeForce650M (my card).
>
> Here is the output of inxi -F
>
> System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64 
> Console: tty 1 Distro: Ubuntu 18.04.5 LTS
> Machine:   Device: laptop System: SAMSUNG product: 300E4C/300E5C/300E7C v: 
> 0.1 serial: N/A
>Mobo: SAMSUNG model: NP300E5X-U01IN v: FAB1 serial: N/A
>UEFI [Legacy]: Phoenix v: P06RAC date: 10/25/2012
> BatteryBAT1: charge: 47.5 Wh 100.0% condition: 47.5/47.5 Wh (100%)
> CPU:   Dual core Intel Core i3-2310M (-MT-MCP-) cache: 3072 KB
>clock speeds: max: 2100 MHz 1: 835 MHz 2: 1031 MHz 3: 905 MHz 4: 
> 927 MHz
> Graphics:  Card-1: Intel 2nd Generation Core Processor Family Integrated 
> Graphics Controller
>Card-2: NVIDIA GF108M [GeForce GT 620M]
>Display Server: X.org 1.20.8 driver: i915 tty size: 171x45 
> Advanced Data: N/A out of X
>
>
> I have installed nouveau, and extracted the firmware from the prop nvidia 
> drivers separately as per instructions on 
> https://nouveau.freedesktop.org/wiki/VideoAcceleration/
> See installed firmware @ https://pastebin.com/Gaqxb88g
>
> But running vainfo yields error: https://pastebin.com/NyULBhXt
>
> Does the error mean that VAAPI is unsupported, or does it indicate a config 
> problem?

As Karol suggests, using the onboard CPU's decoding capabilities will
yield better results. However if there's some specific reason you
want/need to use the NVIDIA card, it should still work. I note that
you don't have an X server running - is that on purpose? I believe
that va-api needs some sort of winsys to be available, but I guess I'm
not entirely sure.

Do you see any errors in dmesg after running vainfo?

Cheers,

  -ilia
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

[Sam McNally]

From: Hans Verkuil 

Signed-off-by: Hans Verkuil 
[sa...@chromium.org:
 - rebased
 - removed polling-related changes
 - moved the calls to drm_dp_cec_(un)set_edid() into the next patch
]
Signed-off-by: Sam McNally 
---

 .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  2 +-
 drivers/gpu/drm/drm_dp_cec.c  | 22 ++-
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c   |  2 +-
 include/drm/drm_dp_helper.h   |  6 +++--
 5 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 461fa4da0a34..6e7075893ec9 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -419,7 +419,7 @@ void amdgpu_dm_initialize_dp_connector(struct 
amdgpu_display_manager *dm,
 
drm_dp_aux_init(>dm_dp_aux.aux);
drm_dp_cec_register_connector(>dm_dp_aux.aux,
- >base);
+ >base, false);
 
if (aconnector->base.connector_type == DRM_MODE_CONNECTOR_eDP)
return;
diff --git a/drivers/gpu/drm/drm_dp_cec.c b/drivers/gpu/drm/drm_dp_cec.c
index 3ab2609f9ec7..04ab7b88055c 100644
--- a/drivers/gpu/drm/drm_dp_cec.c
+++ b/drivers/gpu/drm/drm_dp_cec.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Unfortunately it turns out that we have a chicken-and-egg situation
@@ -338,8 +339,6 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
struct edid *edid)
if (aux->cec.adap) {
if (aux->cec.adap->capabilities == cec_caps &&
aux->cec.adap->available_log_addrs == num_las) {
-   /* Unchanged, so just set the phys addr */
-   cec_s_phys_addr_from_edid(aux->cec.adap, edid);
goto unlock;
}
/*
@@ -364,15 +363,16 @@ void drm_dp_cec_set_edid(struct drm_dp_aux *aux, const 
struct edid *edid)
if (cec_register_adapter(aux->cec.adap, connector->dev->dev)) {
cec_delete_adapter(aux->cec.adap);
aux->cec.adap = NULL;
-   } else {
-   /*
-* Update the phys addr for the new CEC adapter. When called
-* from drm_dp_cec_register_connector() edid == NULL, so in
-* that case the phys addr is just invalidated.
-*/
-   cec_s_phys_addr_from_edid(aux->cec.adap, edid);
}
 unlock:
+   /*
+* Update the phys addr for the new CEC adapter. When called
+* from drm_dp_cec_register_connector() edid == NULL, so in
+* that case the phys addr is just invalidated.
+*/
+   if (aux->cec.adap && edid) {
+   cec_s_phys_addr_from_edid(aux->cec.adap, edid);
+   }
mutex_unlock(>cec.lock);
 }
 EXPORT_SYMBOL(drm_dp_cec_set_edid);
@@ -418,6 +418,7 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
  * drm_dp_cec_register_connector() - register a new connector
  * @aux: DisplayPort AUX channel
  * @connector: drm connector
+ * @is_mst: set to true if this is an MST branch
  *
  * A new connector was registered with associated CEC adapter name and
  * CEC adapter parent device. After registering the name and parent
@@ -425,12 +426,13 @@ EXPORT_SYMBOL(drm_dp_cec_unset_edid);
  * CEC and to register a CEC adapter if that is the case.
  */
 void drm_dp_cec_register_connector(struct drm_dp_aux *aux,
-  struct drm_connector *connector)
+  struct drm_connector *connector, bool is_mst)
 {
WARN_ON(aux->cec.adap);
if (WARN_ON(!aux->transfer))
return;
aux->cec.connector = connector;
+   aux->cec.is_mst = is_mst;
INIT_DELAYED_WORK(>cec.unregister_work,
  drm_dp_cec_unregister_work);
 }
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 82b9de274f65..744cb55572f9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6261,7 +6261,7 @@ intel_dp_connector_register(struct drm_connector 
*connector)
intel_dp->aux.dev = connector->kdev;
ret = drm_dp_aux_register(_dp->aux);
if (!ret)
-   drm_dp_cec_register_connector(_dp->aux, connector);
+   drm_dp_cec_register_connector(_dp->aux, connector, false);
return ret;
 }
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 49dd0cbc332f..671a70e95cd1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1414,7 +1414,7 @@ nouveau_connector_create(struct drm_device *dev,
switch (type) {
case 

Re: [Nouveau] [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

[Christoph Hellwig]

On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote:
> > It wasn't meant to be too insulting, but I found this out when trying
> > to figure out how to just disable it.  But it also ends up using
> > the actual dma attr flags for it's own consistency checks, so just
> > not setting the flag did not turn out to work that easily.
> >
> 
> Yes, sadly the videobuf2 ended up becoming quite counterintuitive
> after growing for the long years and that is reflected in the design
> of this feature as well. I think we need to do something about it.

So I'm about to respin the series and wonder how we should proceed.
I've failed to come up with a clean patch to keep the flag and make
it a no-op.  Can you or your team give it a spin?

Also I wonder if the flag should be renamed from NON_CONSISTENT
to NON_COHERENT - the consistent thing is a weird wart from the times
the old PCI DMA API that is mostly gone now.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v2 1/2] drm: allow limiting the scatter list size.

[Daniel Vetter]

On Tue, Aug 18, 2020 at 11:20:16AM +0200, Gerd Hoffmann wrote:
> Add max_segment argument to drm_prime_pages_to_sg().  When set pass it
> through to the __sg_alloc_table_from_pages() call, otherwise use
> SCATTERLIST_MAX_SEGMENT.
> 
> Also add max_segment field to drm driver and pass it to
> drm_prime_pages_to_sg() calls in drivers and helpers.
> 
> v2: place max_segment in drm driver not gem object.
> 
> Signed-off-by: Gerd Hoffmann 
> ---
>  include/drm/drm_device.h|  8 
>  include/drm/drm_prime.h |  3 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c |  3 ++-
>  drivers/gpu/drm/drm_gem_shmem_helper.c  |  3 ++-
>  drivers/gpu/drm/drm_prime.c | 10 +++---
>  drivers/gpu/drm/etnaviv/etnaviv_gem.c   |  3 ++-
>  drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c |  3 ++-
>  drivers/gpu/drm/msm/msm_gem.c   |  3 ++-
>  drivers/gpu/drm/msm/msm_gem_prime.c |  3 ++-
>  drivers/gpu/drm/nouveau/nouveau_prime.c |  3 ++-
>  drivers/gpu/drm/radeon/radeon_prime.c   |  3 ++-
>  drivers/gpu/drm/rockchip/rockchip_drm_gem.c |  6 --
>  drivers/gpu/drm/tegra/gem.c |  3 ++-
>  drivers/gpu/drm/vgem/vgem_drv.c |  3 ++-
>  drivers/gpu/drm/xen/xen_drm_front_gem.c |  3 ++-
>  15 files changed, 43 insertions(+), 17 deletions(-)
> 
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 0988351d743c..47cb547a8115 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -329,6 +329,14 @@ struct drm_device {
>*/
>   struct drm_fb_helper *fb_helper;
>  
> + /**
> +  * @max_segment:
> +  *
> +  * Max size for scatter list segments.  When unset the default
> +  * (SCATTERLIST_MAX_SEGMENT) is used.
> +  */
> + size_t max_segment;

Is there no better place for this then "at the bottom"? drm_device is a
huge structure, piling stuff up randomly doesn't make it better :-)

I think ideally we'd have a gem substruct like we have on the modeset side
at least.
-Daniel

> +
>   /* Everything below here is for legacy driver, never use! */
>   /* private: */
>  #if IS_ENABLED(CONFIG_DRM_LEGACY)
> diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
> index 9af7422b44cf..2c3689435cb4 100644
> --- a/include/drm/drm_prime.h
> +++ b/include/drm/drm_prime.h
> @@ -88,7 +88,8 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void 
> *vaddr);
>  int drm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct 
> *vma);
>  int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct *vma);
>  
> -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int 
> nr_pages);
> +struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int 
> nr_pages,
> +size_t max_segment);
>  struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
>int flags);
>  
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> index 519ce4427fce..8f6a647757e7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> @@ -303,7 +303,8 @@ static struct sg_table *amdgpu_dma_buf_map(struct 
> dma_buf_attachment *attach,
>   switch (bo->tbo.mem.mem_type) {
>   case TTM_PL_TT:
>   sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
> - bo->tbo.num_pages);
> + bo->tbo.num_pages,
> + obj->dev->max_segment);
>   if (IS_ERR(sgt))
>   return sgt;
>  
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 4b7cfbac4daa..8f47b41b0b2f 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -656,7 +656,8 @@ struct sg_table *drm_gem_shmem_get_sg_table(struct 
> drm_gem_object *obj)
>  
>   WARN_ON(shmem->base.import_attach);
>  
> - return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT);
> + return drm_prime_pages_to_sg(shmem->pages, obj->size >> PAGE_SHIFT,
> +  obj->dev->max_segment);
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_get_sg_table);
>  
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 1693aa7c14b5..27c783fd6633 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -802,7 +802,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
> =  {
>   *
>   * This is useful for implementing _gem_object_funcs.get_sg_table.
>   */
> -struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int 
> nr_pages)
> +struct sg_table *drm_prime_pages_to_sg(struct page **pages, unsigned int 
> nr_pages,
> +size_t 

Re: [Nouveau] VAAPI on GeForce GT 620M

[Karol Herbst]

On Tue, Sep 1, 2020 at 9:31 AM Analabha Roy  wrote:
>
> Hi,
>
> If I am reading the featurematrix right, VAAPI is supported for nouveau on 
> the GeForce650M (my card).
>
> Here is the output of inxi -F
>
> System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64 
> Console: tty 1 Distro: Ubuntu 18.04.5 LTS
> Machine:   Device: laptop System: SAMSUNG product: 300E4C/300E5C/300E7C v: 
> 0.1 serial: N/A
>Mobo: SAMSUNG model: NP300E5X-U01IN v: FAB1 serial: N/A
>UEFI [Legacy]: Phoenix v: P06RAC date: 10/25/2012
> BatteryBAT1: charge: 47.5 Wh 100.0% condition: 47.5/47.5 Wh (100%)
> CPU:   Dual core Intel Core i3-2310M (-MT-MCP-) cache: 3072 KB
>clock speeds: max: 2100 MHz 1: 835 MHz 2: 1031 MHz 3: 905 MHz 4: 
> 927 MHz
> Graphics:  Card-1: Intel 2nd Generation Core Processor Family Integrated 
> Graphics Controller
>Card-2: NVIDIA GF108M [GeForce GT 620M]
>Display Server: X.org 1.20.8 driver: i915 tty size: 171x45 
> Advanced Data: N/A out of X
>
>
> I have installed nouveau, and extracted the firmware from the prop nvidia 
> drivers separately as per instructions on 
> https://nouveau.freedesktop.org/wiki/VideoAcceleration/
> See installed firmware @ https://pastebin.com/Gaqxb88g
>
> But running vainfo yields error: https://pastebin.com/NyULBhXt
>
> Does the error mean that VAAPI is unsupported, or does it indicate a config 
> problem?
>

It does indicate a config problem, but why do you want to use the
nvidia GPU for video accel? I'd rely on intel to provide acceleration
as this also reduces power consumption of the entire system. Also I
think vaapi on the secondary GPU is pretty much untested.

> Thanks,
> AR
> --
> Analabha Roy
> Assistant Professor
> Department of Physics
> The University of Burdwan
> Golapbag Campus, Barddhaman 713104
> West Bengal, India
> Emails: dan...@utexas.edu, a...@phys.buruniv.ac.in, hariseldo...@gmail.com
> Webpage: http://www.ph.utexas.edu/~daneel/
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] VAAPI on GeForce GT 620M

[Analabha Roy]

Hi,

If I am reading the featurematrix
 right, VAAPI is
supported for nouveau on the GeForce650M (my card).

Here is the output of inxi -F

System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64
Console: tty 1 Distro: Ubuntu 18.04.5 LTS
Machine:   Device: laptop System: SAMSUNG product: 300E4C/300E5C/300E7C v:
0.1 serial: N/A
   Mobo: SAMSUNG model: NP300E5X-U01IN v: FAB1 serial: N/A
   UEFI [Legacy]: Phoenix v: P06RAC date: 10/25/2012
BatteryBAT1: charge: 47.5 Wh 100.0% condition: 47.5/47.5 Wh (100%)
CPU:   Dual core Intel Core i3-2310M (-MT-MCP-) cache: 3072 KB
   clock speeds: max: 2100 MHz 1: 835 MHz 2: 1031 MHz 3: 905 MHz 4:
927 MHz
Graphics:  Card-1: Intel 2nd Generation Core Processor Family Integrated
Graphics Controller
   Card-2: NVIDIA GF108M [GeForce GT 620M]
   Display Server: X.org 1.20.8 driver: i915 tty size: 171x45
Advanced Data: N/A out of X


I have installed nouveau, and extracted the firmware from the prop nvidia
drivers separately as per instructions on
 https://nouveau.freedesktop.org/wiki/VideoAcceleration/

See installed firmware @ https://pastebin.com/Gaqxb88g


But running vainfo yields error: https://pastebin.com/NyULBhXt

Does the error mean that VAAPI is unsupported, or does it indicate a config
problem?

Thanks,
AR
-- 
Analabha Roy
Assistant Professor
Department of Physics

The University of Burdwan 
Golapbag Campus, Barddhaman 713104
West Bengal, India
Emails: dan...@utexas.edu, a...@phys.buruniv.ac.in, hariseldo...@gmail.com
Webpage: http://www.ph.utexas.edu/~daneel/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [v3] drm/nouveau: utilize subconnector property for DP

[B, Jeevan]

Hi Ben Skeggs,

Gentle Reminder, Can you please take a look at the patch and provide your ack.  

Thanks 
Jeevan B 

>-Original Message-
>From: B, Jeevan 
>Sent: Sunday, August 16, 2020 12:22 PM
>To: nouveau@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: bske...@redhat.com; airl...@redhat.com;
>maarten.lankho...@linux.intel.com; Nikula, Jani ;
>Shankar, Uma ; Oleg Vasilev
>; B, Jeevan 
>Subject: [v3] drm/nouveau: utilize subconnector property for DP
>
>From: Oleg Vasilev 
>
>Since DP-specific information is stored in driver's structures, every driver
>needs to implement subconnector property by itself.
>
>v2: rebase
>
>v3: renamed a function call
>
>Cc: Ben Skeggs 
>Cc: nouveau@lists.freedesktop.org
>Signed-off-by: Jeevan B 
>Signed-off-by: Oleg Vasilev 
>Reviewed-by: Emil Velikov 
>---
> drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +
> drivers/gpu/drm/nouveau/nouveau_dp.c|  9 +
> drivers/gpu/drm/nouveau/nouveau_encoder.h   |  1 +
> 3 files changed, 23 insertions(+)
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
>b/drivers/gpu/drm/nouveau/nouveau_connector.c
>index 7674025..955afed 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
>@@ -654,6 +654,17 @@ nouveau_connector_detect(struct drm_connector
>*connector, bool force)
>   pm_runtime_mark_last_busy(dev->dev);
>   pm_runtime_put_autosuspend(dev->dev);
>
>+  if (connector->connector_type ==
>DRM_MODE_CONNECTOR_DisplayPort ||
>+  connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
>+  enum drm_mode_subconnector subconnector =
>+DRM_MODE_SUBCONNECTOR_Unknown;
>+
>+  if (conn_status == connector_status_connected &&
>nv_encoder)
>+  subconnector = nv_encoder->dp.subconnector;
>+  drm_object_property_set_value(>base,
>+  connector->dev-
>>mode_config.dp_subconnector_property,
>+  subconnector);
>+  }
>+
>   return conn_status;
> }
>
>@@ -1390,6 +1401,8 @@ nouveau_connector_create(struct drm_device *dev,
>   kfree(nv_connector);
>   return ERR_PTR(ret);
>   }
>+
>+
>   drm_connector_attach_dp_subconnector_property(connector);
>   funcs = _connector_funcs;
>   break;
>   default:
>diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
>b/drivers/gpu/drm/nouveau/nouveau_dp.c
>index 8a0f799..3eff884 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
>+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
>@@ -62,6 +62,7 @@ nouveau_dp_detect(struct nouveau_encoder
>*nv_encoder)
>   struct nouveau_drm *drm = nouveau_drm(dev);
>   struct nvkm_i2c_aux *aux;
>   u8 dpcd[8];
>+  u8 port_cap[DP_MAX_DOWNSTREAM_PORTS] = {};
>   int ret;
>
>   aux = nv_encoder->aux;
>@@ -72,6 +73,14 @@ nouveau_dp_detect(struct nouveau_encoder
>*nv_encoder)
>   if (ret)
>   return ret;
>
>+  if (dpcd[DP_DPCD_REV] > 0x10) {
>+  ret = nvkm_rdaux(aux, DP_DOWNSTREAM_PORT_0,
>+   port_cap, DP_MAX_DOWNSTREAM_PORTS);
>+  if (ret)
>+  memset(port_cap, 0,
>DP_MAX_DOWNSTREAM_PORTS);
>+  }
>+  nv_encoder->dp.subconnector = drm_dp_subconnector_type(dpcd,
>+port_cap);
>+
>   nv_encoder->dp.link_bw = 27000 * dpcd[1];
>   nv_encoder->dp.link_nr = dpcd[2] & DP_MAX_LANE_COUNT_MASK;
>
>diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h
>b/drivers/gpu/drm/nouveau/nouveau_encoder.h
>index a72c412..49b5c10 100644
>--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
>+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
>@@ -64,6 +64,7 @@ struct nouveau_encoder {
>   struct nv50_mstm *mstm;
>   int link_nr;
>   int link_bw;
>+  enum drm_mode_subconnector subconnector;
>   } dp;
>   };
>
>--
>2.7.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau