Re: linux-next: build failure after merge of the drm tree

[David Airlie]

On Fri, Jul 12, 2024 at 12:28 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> On Mon, 1 Jul 2024 10:19:01 -0700 Nathan Chancellor  wrote:
> >
> > On Mon, Jul 01, 2024 at 07:13:19PM +1000, Stephen Rothwell wrote:
> > >
> > > After merging the drm tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > >
> > > In file included from arch/powerpc/include/asm/mmu.h:144,
> > >  from arch/powerpc/include/asm/paca.h:18,
> > >  from arch/powerpc/include/asm/current.h:13,
> > >  from include/linux/sched.h:12,
> > >  from include/linux/ratelimit.h:6,
> > >  from include/linux/dev_printk.h:16,
> > >  from include/linux/device.h:15,
> > >  from include/linux/dma-mapping.h:8,
> > >  from drivers/gpu/drm/omapdrm/omap_gem.c:7:
> > > drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_pin_tiler':
> > > arch/powerpc/include/asm/page.h:25:33: error: conversion from 'long 
> > > unsigned int' to 'u16' {aka 'short unsigned int'} changes value from 
> > > '65536' to '0' [-Werror=overflow]
> > >25 | #define PAGE_SIZE   (ASM_CONST(1) << PAGE_SHIFT)
> > >   | ^~~~
> > > drivers/gpu/drm/omapdrm/omap_gem.c:758:42: note: in expansion of macro 
> > > 'PAGE_SIZE'
> > >   758 |  PAGE_SIZE);
> > >   |  ^
> > > drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init':
> > > arch/powerpc/include/asm/page.h:25:33: error: conversion from 'long 
> > > unsigned int' to 'u16' {aka 'short unsigned int'} changes value from 
> > > '65536' to '0' [-Werror=overflow]
> > >25 | #define PAGE_SIZE   (ASM_CONST(1) << PAGE_SHIFT)
> > >   | ^~~~
> > > drivers/gpu/drm/omapdrm/omap_gem.c:1504:65: note: in expansion of macro 
> > > 'PAGE_SIZE'
> > >  1504 | block = tiler_reserve_2d(fmts[i], w, h, 
> > > PAGE_SIZE);
> > >   | 
> > > ^
> > > cc1: all warnings being treated as errors
> > >
> > > Exposed by commit
> > >
> > >   dc6fcaaba5a5 ("drm/omap: Allow build with COMPILE_TEST=y")
> > >
> > > PowerPC 64 bit uses 64k pages.
> > >
> > > I have reverted that commit for today.
> >
> > FWIW, I sent a patch to address this in a bit of a more targeted manner
> > over a week ago:
> >
> > https://lore.kernel.org/20240620-omapdrm-restrict-compile-test-to-sub-64kb-page-size-v1-1-5e56de71f...@kernel.org/
> >
> > Although somehow, I left off Ville from that patch :/
>
> I am still reverting that commit (as of yesterday, the failure still
> occurs) ...

I'll merge this directly to drm-next today.

Dave.

Re: [PATCH v2 1/2] drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()

[David Airlie]

> V2:
> * Fixup explanation as the prior one was bogus

For v2 of both patches,

Reviewed-by: Dave Airlie 

Please apply to drm-misc-fixes

Dave.

Re: [PATCH] drm/nouveau/dp: Fix incorrect return code in r535_dp_aux_xfer()

[David Airlie]

Reviewed-by: Dave Airlie 

On Sat, Mar 16, 2024 at 7:21 AM Lyude Paul  wrote:
>
> I've recently been seeing some unexplained GSP errors on my RTX 6000 from
> failed aux transactions:
>
>   [  132.915867] nouveau :1f:00.0: gsp: cli:0xc1d2 obj:0x0073
>   ctrl cmd:0x00731341 failed: 0x
>
> While the cause of these is not yet clear, these messages made me notice
> that the aux transactions causing these transactions were succeeding - not
> failing. As it turns out, this is because we're currently not returning the
> correct variable when r535_dp_aux_xfer() hits an error - causing us to
> never propagate GSP errors for failed aux transactions to userspace.
>
> So, let's fix that.
>
> Fixes: 4ae3a20102b2 ("nouveau/gsp: don't free ctrl messages on errors")
> Signed-off-by: Lyude Paul 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
> index 6a0a4d3b8902d..027867c2a8c5b 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/r535.c
> @@ -1080,7 +1080,7 @@ r535_dp_aux_xfer(struct nvkm_outp *outp, u8 type, u32 
> addr, u8 *data, u8 *psize)
> ret = nvkm_gsp_rm_ctrl_push(>rm.objcom, , sizeof(*ctrl));
> if (ret) {
> nvkm_gsp_rm_ctrl_done(>rm.objcom, ctrl);
> -   return PTR_ERR(ctrl);
> +   return ret;
> }
>
> memcpy(data, ctrl->data, size);
> --
> 2.43.0
>

Re: Making drm_gpuvm work across gpu devices

[David Airlie]

On Wed, Jan 31, 2024 at 8:29 AM Zeng, Oak  wrote:
>
> Hi Christian,
>
>
>
> Nvidia Nouveau driver uses exactly the same concept of SVM with HMM, GPU 
> address in the same process is exactly the same with CPU virtual address. It 
> is already in upstream Linux kernel. We Intel just follow the same direction 
> for our customers. Why we are not allowed?


Oak, this isn't how upstream works, you don't get to appeal to
customer or internal design. nouveau isn't "NVIDIA"'s and it certainly
isn't something NVIDIA would ever suggest for their customers. We also
likely wouldn't just accept NVIDIA's current solution upstream without
some serious discussions. The implementation in nouveau was more of a
sample HMM use case rather than a serious implementation. I suspect if
we do get down the road of making nouveau an actual compute driver for
SVM etc then it would have to severely change.

Dave.

Re: Making drm_gpuvm work across gpu devices

[David Airlie]

>
>
> For us, Xekmd doesn't need to know it is running under bare metal or 
> virtualized environment. Xekmd is always a guest driver. All the virtual 
> address used in xekmd is guest virtual address. For SVM, we require all the 
> VF devices share one single shared address space with guest CPU program. So 
> all the design works in bare metal environment can automatically work under 
> virtualized environment. +@Shah, Ankur N +@Winiarski, Michal to backup me if 
> I am wrong.
>
>
>
> Again, shared virtual address space b/t cpu and all gpu devices is a hard 
> requirement for our system allocator design (which means malloc’ed memory, 
> cpu stack variables, globals can be directly used in gpu program. Same 
> requirement as kfd SVM design). This was aligned with our user space software 
> stack.

Just to make a very general point here (I'm hoping you listen to
Christian a bit more and hoping he replies in more detail), but just
because you have a system allocator design done, it doesn't in any way
enforce the requirements on the kernel driver to accept that design.
Bad system design should be pushed back on, not enforced in
implementation stages. It's a trap Intel falls into regularly since
they say well we already agreed this design with the userspace team
and we can't change it now. This isn't acceptable. Design includes
upstream discussion and feedback, if you say misdesigned the system
allocator (and I'm not saying you definitely have), and this is
pushing back on that, then you have to go fix your system
architecture.

KFD was an experiment like this, I pushed back on AMD at the start
saying it was likely a bad plan, we let it go and got a lot of
experience in why it was a bad design.

Dave.

Re: [PATCH AUTOSEL 6.1 5/5] nouveau: fix disp disabling with GSP

[David Airlie]

NAK for backporting this to anything, it is just a fix for 6.7


On Mon, Jan 8, 2024 at 10:28 PM Sasha Levin  wrote:
>
> From: Dave Airlie 
>
> [ Upstream commit 7854ea0e408d7f2e8faaada1773f3ddf9cb538f5 ]
>
> This func ptr here is normally static allocation, but gsp r535
> uses a dynamic pointer, so we need to handle that better.
>
> This fixes a crash with GSP when you use config=disp=0 to avoid
> disp problems.
>
> Signed-off-by: Dave Airlie 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-4-airl...@gmail.com
> Signed-off-by: Sasha Levin 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
> index 65c99d948b686..ae47eabd5d0bd 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
> @@ -359,7 +359,7 @@ nvkm_disp_oneinit(struct nvkm_engine *engine)
> if (ret)
> return ret;
>
> -   if (disp->func->oneinit) {
> +   if (disp->func && disp->func->oneinit) {
> ret = disp->func->oneinit(disp);
> if (ret)
> return ret;
> @@ -461,8 +461,10 @@ nvkm_disp_new_(const struct nvkm_disp_func *func, struct 
> nvkm_device *device,
> spin_lock_init(>client.lock);
>
> ret = nvkm_engine_ctor(_disp, device, type, inst, true, 
> >engine);
> -   if (ret)
> +   if (ret) {
> +   disp->func = NULL;
> return ret;
> +   }
>
> if (func->super) {
> disp->super.wq = create_singlethread_workqueue("nvkm-disp");
> --
> 2.43.0
>

Re: [PATCH 2/2] modules/firmware: add a new option to denote a firmware group to choose one.

[David Airlie]

On Tue, Jul 18, 2023 at 5:41 AM Lucas De Marchi
 wrote:
>
> On Fri, Jul 07, 2023 at 11:41:48AM -0700, Luis Chamberlain wrote:
> >On Tue, Jul 04, 2023 at 12:50:50PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie 
> >>
> >> This adds two tags that will go into the module info.
> >>
> >> The first denotes a group of firmwares, when that tag is present all
> >> MODULE_FIRMWARE lines between the tags will be ignored by new versions of
> >> dracut.
> >>
> >> The second makes an explicitly ordered group of firmwares to search for
> >> inside a group setting. New dracut will pick the first available firmware
> >> from this to put in the initramfs.
> >>
> >> Old dracut will just ignore these tags and fallback to installing all
> >> the firmwares.
> >>
> >> The corresponding dracut code it at:
> >> https://github.com/dracutdevs/dracut/pull/2309
> >>
> >> Cc: Luis Chamberlain 
> >> Cc: linux-modu...@vger.kernel.org
> >> Cc: dri-devel@lists.freedesktop.org
> >> Signed-off-by: Dave Airlie 
> >
> >Lucas, did this end up working for you as well?
>
> I didn't try this yet, no. My opinion is similar to the first version of
> this series:  this is the first case in which we are making the order of
> 2 different keys to be relevant and it doesn't look so pretty. It may
> also be hard to adapt some of the drivers like i915 to intertwine the 2
> modinfo keys.

This doesn't have as much reliance on order, it just relies on the
group tags not being reordered outside the modinfos between them.

>
> However, the alternative I provided also has some flaws, so I said I'd
> be ok continuing in this direction. Humn... how about merging part of my
> suggestion to mitigate the duplication we have now?
>
> - Document that when using a fw group, it's expected userspace
>   will consider higher versions within a group to have higher
>   prio and add only one of them. Thinking on a distro packaging,
>   it could be extended to packaging fewer blobs too.
>
> If we agree on "firmware files within a group are version-sorted", then
> we don't need the extra MODULE_FIRMWARE_GROUP_LIST, do we?

But what is the versioning to be used, I have to be very careful to
have this be backwards compat, and not suddenly stop pulling in some
versions of a fw because they happen to have used a version scheme
that this tramples.

If you are saying, we need to define a firmware versioning rule, then
that's a big task and would involve changing a bunch of things in the
fw and drivers.

i915:
adlp_dmc_ver2_14.bin.xz
dg2_guc_70.1.2.bin.xz
mtl_guc_70.bin.xz

amdgpu:
polaris11_mec.bin.xz
polaris11_mec2.bin.xz
polaris11_mec_2.bin.xz
polaris11_mec2_2.bin.xz

I don't see what is a version field I can sort on reliably here. Now
maybe I could introduce a new field

Do you think we should just add explicit ordering to each module group?,

so we create a

MODULE_FIRMWARE_GROUP_VERSIONED("nvidia/ga106/gsp/gsp-5258902.bin", 1);
MODULE_FIRMWARE_GROUP_VERSIONED("nvidia/ga106/gsp/gsp-5303002.bin", 2);

and I just output group brackets + that? and fix dracut to deal with it?

Dave.

Re: [PATCH] modules/firmware: add a new option to denote a firmware group to choose one.

[David Airlie]

On Wed, May 24, 2023 at 3:26 PM Luis Chamberlain  wrote:
>
> On Wed, May 03, 2023 at 01:19:31PM +1000, Dave Airlie wrote:
> > >
> > > >
> > > >> > the GROUP until after the FIRMWARE, so this can't work, as it already
> > > >> > will have included all the ones below, hence why I bracketed top and
> > > >> > bottom with a group.
> > > >>
> > > >> well... that is something that can be adapted easily by using a 2 pass
> > > >> approach, filtering out the list based on the groups.
> > > >>
> > > >> I agree that yours is simpler though.  If we can rely on the
> > > >> order produced by the compiler and we document the expectations of
> > > >> MODULE_FIRMWARE_GROUP_ONLY_ONE, then I believe we can stay with the
> > > >> simpler approach.
> > > >>
> > > >> Luis, any thoughts here?
> > > >
> > > >I see the Dracut code indicates that the order says now that you should
> > > >put the preferred firmware last, and that seems to match most coding
> > > >conventions, ie, new firmwares likely get added last, so it's a nice
> > >
> > > not all. i915 for example keeps it newest first so when attempting
> > > multiple firmware versions it starts from the preferred version.  It
> > > will be harder to convert since it also uses a x-macro to make sure the
> > > MODULE_FIRMWARE() and the the platform mapping are actually using the same
> > > firmware.
> > >
> > > >coincidence. Will this always work? I don't know. But if you like to
> > >
> > > short answer: it depends if your compiler is gcc *and* -O2 is used
> > > Longer debug ahead. Simple test with the expansion of MODULE_FIRMWARE
> > > baked in:
> > >
> > > $ cat /tmp/a.c
> > > static const __attribute__((section("__modinfo_manual"), used, 
> > > aligned(1))) char foo[] = "modinfo_manual_foo";
> > > static const __attribute__((section("__modinfo_manual"), used, 
> > > aligned(1))) char bar[] = "modinfo_manual_bar";
> > > $ gcc -c -o /tmp/a.o /tmp/a.c
> > > $ objcopy -O binary --only-section=__modinfo_manual /tmp/a.o 
> > > /tmp/modinfo_manual
> > > $ strings /tmp/modinfo_manual
> > > modinfo_manual_foo
> > > modinfo_manual_bar
> > >
> > > However that doesn't match when building modules. In kmod:
> > >
> > > diff --git a/testsuite/module-playground/mod-simple.c 
> > > b/testsuite/module-playground/mod-simple.c
> > > index 503e4d8..6dd5771 100644
> > > --- a/testsuite/module-playground/mod-simple.c
> > > +++ b/testsuite/module-playground/mod-simple.c
> > > @@ -30,3 +30,9 @@ module_exit(test_module_exit);
> > >
> > >   MODULE_AUTHOR("Lucas De Marchi ");
> > >   MODULE_LICENSE("GPL");
> > > +
> > > +
> > > +static const char __UNIQUE_ID_firmware404[] __attribute__((__used__)) 
> > > __attribute__((__section__("__modinfo_cpp"))) 
> > > __attribute__((__aligned__(1))) = "modinfo_cpp_foo";
> > > +static const char __UNIQUE_ID_firmware405[] __attribute__((__used__)) 
> > > __attribute__((__section__("__modinfo_cpp"))) 
> > > __attribute__((__aligned__(1))) = "modinfo_cpp_bar";
> > >
> > > $ make 
> > > $ objcopy -O binary --only-section=__modinfo_cpp 
> > > testsuite/module-playground/mod-simple.ko /tmp/modinfo_cpp
> > > $ strings /tmp/modinfo_cpp
> > > modinfo_cpp_bar
> > > modinfo_cpp_foo
> > >
> > > It doesn't seem to be ./scripts/Makefile.modfinal neither as it's also
> > > inverted in testsuite/module-playground/mod-simple.o
> > >
> > > After checking the options passed to gcc, here is the "culprit": -O2
> > >
> > > $ gcc -c -o /tmp/a.o /tmp/a.c && objcopy -O binary 
> > > --only-section=__modinfo_manual /tmp/a.o /tmp/modinfo_manual && strings 
> > > /tmp/modinfo_manual
> > > modinfo_manual_foo
> > > modinfo_manual_bar
> > > $ gcc -O2 -c -o /tmp/a.o /tmp/a.c && objcopy -O binary 
> > > --only-section=__modinfo_manual /tmp/a.o /tmp/modinfo_manual && strings 
> > > /tmp/modinfo_manual
> > > modinfo_manual_bar
> > > modinfo_manual_foo
> > >
> > > It seems anything but -O0 inverts the section.
> > >
> > > $ gcc --version
> > > gcc (GCC) 12.2.1 20230201
> > >
> > > It doesn't match the behavior described in its man page though. Manually
> > > specifying all the options that -O1 turns on doesn't invert it.
> > >
> > > $ gcc -fauto-inc-dec -fbranch-count-reg 
> > > -fcombine-stack-adjustments \
> > > -fcompare-elim -fcprop-registers -fdce -fdefer-pop 
> > > -fdelayed-branch
> > > -fdse -fforward-propagate -fguess-branch-probability 
> > > -fif-conversion \
> > > -fif-conversion2 -finline-functions-called-once 
> > > -fipa-modref \
> > > -fipa-profile -fipa-pure-const -fipa-reference 
> > > -fipa-reference-addressable \
> > > -fmerge-constants -fmove-loop-stores -fomit-frame-pointer 
> > > -freorder-blocks \
> > > -fshrink-wrap -fshrink-wrap-separate -fsplit-wide-types 
> > > -fssa-backprop \
> > >

Re: linux-next: duplicate patch in the drm-misc-fixes tree

[David Airlie]

On Fri, Feb 10, 2023 at 9:47 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> The following commit is also in the drm-fixes tree as a different commit
> (but the same patch):
>
>   94d8b6572a1f ("nvidiafb: detect the hardware support before removing 
> console.")
>
> This is commit
>
>   04119ab1a49f ("nvidiafb: detect the hardware support before removing 
> console.")
>
> in the drm-fixes tree.

Just FYI misc team, I've force pushed drm-misc-fixes to drop this
patch, please make sure any local misc fixes don't bring it back in if
we can avoid it.

Dave.

Re: [PATCH] nvidiafb: detect the hardware support before removing console.

[David Airlie]

On Mon, Feb 6, 2023 at 6:38 PM Zeno Davatz  wrote:
>
> Dear Dave
>
> On Mon, Feb 6, 2023 at 9:10 AM Dave Airlie  wrote:
> >
> > On Mon, 6 Feb 2023 at 18:01, Zeno Davatz  wrote:
> > >
> > > Dear Dave
> > >
> > > On Mon, Feb 6, 2023 at 8:54 AM Dave Airlie  wrote:
> > > >
> > > > On Mon, 6 Feb 2023 at 17:52, Zeno Davatz  wrote:
> > > > >
> > > > > Dear Dave
> > > > >
> > > > > Thank you for your patch.
> > > > >
> > > > > On Sun, Feb 5, 2023 at 10:07 PM Dave Airlie  wrote:
> > > > > >
> > > > > > From: Dave Airlie 
> > > > > >
> > > > > > This driver removed the console, but hasn't yet decided if it could
> > > > > > take over the console yet. Instead of doing that, probe the hw for
> > > > > > support and then remove the console afterwards.
> > > > > >
> > > > > > Signed-off-by: Dave Airlie 
> > > > > > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=216859
> > > > > > Reported-by: Zeno Davatz 
> > > > > > ---
> > > > > >  drivers/video/fbdev/nvidia/nvidia.c | 81 
> > > > > > +++--
> > > > > >  1 file changed, 42 insertions(+), 39 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/video/fbdev/nvidia/nvidia.c 
> > > > > > b/drivers/video/fbdev/nvidia/nvidia.c
> > > > > > index 1960916098d4..e60a276b4855 100644
> > > > > > --- a/drivers/video/fbdev/nvidia/nvidia.c
> > > > > > +++ b/drivers/video/fbdev/nvidia/nvidia.c
> > > > > > @@ -1197,17 +1197,17 @@ static int nvidia_set_fbinfo(struct fb_info 
> > > > > > *info)
> > > > > > return nvidiafb_check_var(>var, info);
> > > > > >  }
> > > > > >
> > > > > > -static u32 nvidia_get_chipset(struct fb_info *info)
> > > > > > +static u32 nvidia_get_chipset(struct pci_dev *pci_dev,
> > > > > > + volatile u32 __iomem *REGS)
> > > > > >  {
> > > > > > -   struct nvidia_par *par = info->par;
> > > > > > -   u32 id = (par->pci_dev->vendor << 16) | 
> > > > > > par->pci_dev->device;
> > > > > > +   u32 id = (pci_dev->vendor << 16) | pci_dev->device;
> > > > > >
> > > > > > printk(KERN_INFO PFX "Device ID: %x \n", id);
> > > > > >
> > > > > > if ((id & 0xfff0) == 0x00f0 ||
> > > > > > (id & 0xfff0) == 0x02e0) {
> > > > > > /* pci-e */
> > > > > > -   id = NV_RD32(par->REGS, 0x1800);
> > > > > > +   id = NV_RD32(REGS, 0x1800);
> > > > > >
> > > > > > if ((id & 0x) == 0x10DE)
> > > > > > id = 0x10DE | (id >> 16);
> > > > > > @@ -1220,12 +1220,11 @@ static u32 nvidia_get_chipset(struct 
> > > > > > fb_info *info)
> > > > > > return id;
> > > > > >  }
> > > > > >
> > > > > > -static u32 nvidia_get_arch(struct fb_info *info)
> > > > > > +static u32 nvidia_get_arch(u32 Chipset)
> > > > > >  {
> > > > > > -   struct nvidia_par *par = info->par;
> > > > > > u32 arch = 0;
> > > > > >
> > > > > > -   switch (par->Chipset & 0x0ff0) {
> > > > > > +   switch (Chipset & 0x0ff0) {
> > > > > > case 0x0100:/* GeForce 256 */
> > > > > > case 0x0110:/* GeForce2 MX */
> > > > > > case 0x0150:/* GeForce2 */
> > > > > > @@ -1278,16 +1277,44 @@ static int nvidiafb_probe(struct pci_dev 
> > > > > > *pd, const struct pci_device_id *ent)
> > > > > > struct fb_info *info;
> > > > > > unsigned short cmd;
> > > > > > int ret;
> > > > > > +   volatile u32 __iomem *REGS;
> > > > > > +   int Chipset;
> > > > > > +   u32 Architecture;
> > > > > >
> > > > > > NVTRACE_ENTER();
> > > > > > assert(pd != NULL);
> > > > > >
> > > > > > +   if (pci_enable_device(pd)) {
> > > > > > +   printk(KERN_ERR PFX "cannot enable PCI device\n");
> > > > > > +   return -ENODEV;
> > > > > > +   }
> > > > > > +
> > > > > > +   /* enable IO and mem if not already done */
> > > > > > +   pci_read_config_word(pd, PCI_COMMAND, );
> > > > > > +   cmd |= (PCI_COMMAND_IO | PCI_COMMAND_MEMORY);
> > > > > > +   pci_write_config_word(pd, PCI_COMMAND, cmd);
> > > > > > +
> > > > > > +   nvidiafb_fix.mmio_start = pci_resource_start(pd, 0);
> > > > > > +   nvidiafb_fix.mmio_len = pci_resource_len(pd, 0);
> > > > > > +
> > > > > > +   REGS = ioremap(nvidiafb_fix.mmio_start, 
> > > > > > nvidiafb_fix.mmio_len);
> > > > > > +   if (!REGS) {
> > > > > > +   printk(KERN_ERR PFX "cannot ioremap MMIO base\n");
> > > > > > +   return -ENODEV;
> > > > > > +   }
> > > > > > +
> > > > > > +   Chipset = nvidia_get_chipset(pd, REGS);
> > > > > > +   Architecture = nvidia_get_arch(Chipset);
> > > > > > +   if (Architecture == 0) {
> > > > > > +   printk(KERN_ERR PFX "unknown NV_ARCH\n");
> > > > > > +   goto err_out;
> > > > > > +   }
> > > > > > +
> > > > > > ret = aperture_remove_conflicting_pci_devices(pd, 
> > > > > > "nvidiafb");
> > > > > > if (ret)
> > > > > > -  

Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces

[David Airlie]

On Sat, Jan 28, 2023 at 1:17 AM Christian König
 wrote:
>
> Am 27.01.23 um 15:44 schrieb Danilo Krummrich:
> > [SNIP]
> 
>  What you want is one component for tracking the VA allocations
>  (drm_mm based) and a different component/interface for tracking the
>  VA mappings (probably rb tree based).
> >>>
> >>> That's what the GPUVA manager is doing. There are gpuva_regions
> >>> which correspond to VA allocations and gpuvas which represent the
> >>> mappings. Both are tracked separately (currently both with a
> >>> separate drm_mm, though). However, the GPUVA manager needs to take
> >>> regions into account when dealing with mappings to make sure the
> >>> GPUVA manager doesn't propose drivers to merge over region
> >>> boundaries. Speaking from userspace PoV, the kernel wouldn't merge
> >>> mappings from different VKBuffer objects even if they're virtually
> >>> and physically contiguous.
> >>
> >> That are two completely different things and shouldn't be handled in
> >> a single component.
> >
> > They are different things, but they're related in a way that for
> > handling the mappings (in particular merging and sparse) the GPUVA
> > manager needs to know the VA allocation (or region) boundaries.
> >
> > I have the feeling there might be a misunderstanding. Userspace is in
> > charge to actually allocate a portion of VA space and manage it. The
> > GPUVA manager just needs to know about those VA space allocations and
> > hence keeps track of them.
> >
> > The GPUVA manager is not meant to be an allocator in the sense of
> > finding and providing a hole for a given request.
> >
> > Maybe the non-ideal choice of using drm_mm was implying something else.
>
> Uff, well long story short that doesn't even remotely match the
> requirements. This way the GPUVA manager won't be usable for a whole
> bunch of use cases.
>
> What we have are mappings which say X needs to point to Y with this and
> hw dependent flags.
>
> The whole idea of having ranges is not going to fly. Neither with AMD
> GPUs and I strongly think not with Intels XA either.
>
> >> We should probably talk about the design of the GPUVA manager once
> >> more when this should be applicable to all GPU drivers.
> >
> > That's what I try to figure out with this RFC, how to make it
> > appicable for all GPU drivers, so I'm happy to discuss this. :-)
>
> Yeah, that was really good idea :) That proposal here is really far away
> from the actual requirements.
>
> >>> For sparse residency the kernel also needs to know the region
> >>> boundaries to make sure that it keeps sparse mappings around.
> >>
> >> What?
> >
> > When userspace creates a new VKBuffer with the
> > VK_BUFFER_CREATE_SPARSE_BINDING_BIT the kernel may need to create
> > sparse mappings in order to ensure that using this buffer without any
> > memory backed mappings doesn't fault the GPU.
> >
> > Currently, the implementation does this the following way:
> >
> > 1. Userspace creates a new VKBuffer and hence allocates a portion of
> > the VA space for it. It calls into the kernel indicating the new VA
> > space region and the fact that the region is sparse.
> >
> > 2. The kernel picks up the region and stores it in the GPUVA manager,
> > the driver creates the corresponding sparse mappings / page table
> > entries.
> >
> > 3. Userspace might ask the driver to create a couple of memory backed
> > mappings for this particular VA region. The GPUVA manager stores the
> > mapping parameters, the driver creates the corresponding page table
> > entries.
> >
> > 4. Userspace might ask to unmap all the memory backed mappings from
> > this particular VA region. The GPUVA manager removes the mapping
> > parameters, the driver cleans up the corresponding page table entries.
> > However, the driver also needs to re-create the sparse mappings, since
> > it's a sparse buffer, hence it needs to know the boundaries of the
> > region it needs to create the sparse mappings in.
>
> Again, this is not how things are working. First of all the kernel
> absolutely should *NOT* know about those regions.
>
> What we have inside the kernel is the information what happens if an
> address X is accessed. On AMD HW this can be:
>
> 1. Route to the PCIe bus because the mapped BO is stored in system memory.
> 2. Route to the internal MC because the mapped BO is stored in local memory.
> 3. Route to other GPUs in the same hive.
> 4. Route to some doorbell to kick of other work.
> ...
> x. Ignore write, return 0 on reads (this is what is used for sparse
> mappings).
> x+1. Trigger a recoverable page fault. This is used for things like SVA.
> x+2. Trigger a non-recoverable page fault. This is used for things like
> unmapped regions where access is illegal.
>
> All this is plus some hw specific caching flags.
>
> When Vulkan allocates a sparse VKBuffer what should happen is the following:
>
> 1. The Vulkan driver somehow figures out a VA region A..B for the
> buffer. This can be in userspace (libdrm_amdgpu) or 

Re: [REGRESSION] GM20B probe fails after commit 2541626cfb79

[David Airlie]

On Thu, Dec 29, 2022 at 12:58 AM Diogo Ivo  wrote:
>
> Hello,
>
> Commit 2541626cfb79 breaks GM20B probe with
> the following kernel log:
>
> [2.153892] [ cut here ]
> [2.153897] WARNING: CPU: 1 PID: 36 at 
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c:273 
> gf100_vmm_valid+0x2c4/0x390
> [2.153916] Modules linked in:
> [2.153922] CPU: 1 PID: 36 Comm: kworker/u8:1 Not tainted 6.1.0+ #1
> [2.153929] Hardware name: Google Pixel C (DT)
> [2.153933] Workqueue: events_unbound deferred_probe_work_func
> [2.153943] pstate: 8005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [2.153950] pc : gf100_vmm_valid+0x2c4/0x390
> [2.153959] lr : gf100_vmm_valid+0xb4/0x390
> [2.153966] sp : ffc009e134b0
> [2.153969] x29: ffc009e134b0 x28:  x27: 
> ffc008fd44c8
> [2.153979] x26: ffea x25: ffc0087b98d0 x24: 
> ff8080f89038
> [2.153987] x23: ff8081fadc08 x22:  x21: 
> 
> [2.153995] x20: ff8080f8a000 x19: ffc009e13678 x18: 
> 
> [2.154003] x17: f37a8b93418958e6 x16: ffc009f0d000 x15: 
> 
> [2.154011] x14: 0002 x13: 0003a020 x12: 
> ffc00800
> [2.154019] x11: 000102913000 x10:  x9 : 
> 
> [2.154026] x8 : ffc009e136d8 x7 : ffc008fd44c8 x6 : 
> ff80803d0f00
> [2.154034] x5 :  x4 : ff8080f88c00 x3 : 
> 0010
> [2.154041] x2 : 000c x1 : ffea x0 : 
> ffea
> [2.154050] Call trace:
> [2.154053]  gf100_vmm_valid+0x2c4/0x390
> [2.154061]  nvkm_vmm_map_valid+0xd4/0x204
> [2.154069]  nvkm_vmm_map_locked+0xa4/0x344
> [2.154076]  nvkm_vmm_map+0x50/0x84
> [2.154083]  nvkm_firmware_mem_map+0x84/0xc4
> [2.154094]  nvkm_falcon_fw_oneinit+0xc8/0x320
> [2.154101]  nvkm_acr_oneinit+0x428/0x5b0
> [2.154109]  nvkm_subdev_oneinit_+0x50/0x104
> [2.154114]  nvkm_subdev_init_+0x3c/0x12c
> [2.154119]  nvkm_subdev_init+0x60/0xa0
> [2.154125]  nvkm_device_init+0x14c/0x2a0
> [2.154133]  nvkm_udevice_init+0x60/0x9c
> [2.154140]  nvkm_object_init+0x48/0x1b0
> [2.154144]  nvkm_ioctl_new+0x168/0x254
> [2.154149]  nvkm_ioctl+0xd0/0x220
> [2.154153]  nvkm_client_ioctl+0x10/0x1c
> [2.154162]  nvif_object_ctor+0xf4/0x22c
> [2.154168]  nvif_device_ctor+0x28/0x70
> [2.154174]  nouveau_cli_init+0x150/0x590
> [2.154180]  nouveau_drm_device_init+0x60/0x2a0
> [2.154187]  nouveau_platform_device_create+0x90/0xd0
> [2.154193]  nouveau_platform_probe+0x3c/0x9c
> [2.154200]  platform_probe+0x68/0xc0
> [2.154207]  really_probe+0xbc/0x2dc
> [2.154211]  __driver_probe_device+0x78/0xe0
> [2.154216]  driver_probe_device+0xd8/0x160
> [2.154221]  __device_attach_driver+0xb8/0x134
> [2.154226]  bus_for_each_drv+0x78/0xd0
> [2.154230]  __device_attach+0x9c/0x1a0
> [2.154234]  device_initial_probe+0x14/0x20
> [2.154239]  bus_probe_device+0x98/0xa0
> [2.154243]  deferred_probe_work_func+0x88/0xc0
> [2.154247]  process_one_work+0x204/0x40c
> [2.154256]  worker_thread+0x230/0x450
> [2.154261]  kthread+0xc8/0xcc
> [2.154266]  ret_from_fork+0x10/0x20
> [2.154273] ---[ end trace  ]---
> [2.154278] nouveau 5700.gpu: pmu: map -22
> [2.154285] nouveau 5700.gpu: acr: one-time init failed, -22
> [2.154559] nouveau 5700.gpu: init failed with -22
> [2.154564] nouveau: DRM-master::0080: init failed with -22
> [2.154574] nouveau 5700.gpu: DRM-master: Device allocation failed: -22
> [2.162905] nouveau: probe of 5700.gpu failed with error -22
>
> #regzbot introduced: 2541626cfb79

As a quick check can you try changing

drivers/gpu/drm/nouveau/nvkm/core/firmware.c:nvkm_firmware_mem_target
from NVKM_MEM_TARGET_HOST to NVKM_MEM_TARGET_NCOH ?

Dave.
>
> Thanks,
>
> Diogo Ivo
>

Re: linux-next: build failure after merge of the drm-misc tree

[David Airlie]

On Wed, Nov 23, 2022 at 3:21 PM Stephen Rothwell  wrote:
>
> Hi all,
>
> On Thu, 17 Nov 2022 18:32:14 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the drm-misc tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled':
> > fbmon.c:(.text+0x1e4): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/fbcmap.o: in function 
> > `fb_modesetting_disabled':
> > fbcmap.c:(.text+0x478): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/fbsysfs.o: in function 
> > `fb_modesetting_disabled':
> > fbsysfs.c:(.text+0xb64): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/modedb.o: in function 
> > `fb_modesetting_disabled':
> > modedb.c:(.text+0x129c): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> > ld: drivers/video/fbdev/core/fbcvt.o: in function `fb_modesetting_disabled':
> > fbcvt.c:(.text+0x0): multiple definition of `fb_modesetting_disabled'; 
> > drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
> >
> > Caused by commit
> >
> >   0ba2fa8cbd29 ("fbdev: Add support for the nomodeset kernel parameter")
> >
> > This build does not have CONFIG_VIDEO_NOMODESET set.
> >
> > I applied the following patch for today.
> >
> > From 63f957a050c62478ed1348c5b204bc65c68df4d7 Mon Sep 17 00:00:00 2001
> > From: Stephen Rothwell 
> > Date: Thu, 17 Nov 2022 18:19:22 +1100
> > Subject: [PATCH] fix up for "fbdev: Add support for the nomodeset kernel 
> > parameter"
> >
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  include/linux/fb.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 3a822e4357b1..ea421724f733 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -807,7 +807,7 @@ extern int fb_find_mode(struct fb_var_screeninfo *var,
> >  #if defined(CONFIG_VIDEO_NOMODESET)
> >  bool fb_modesetting_disabled(const char *drvname);
> >  #else
> > -bool fb_modesetting_disabled(const char *drvname)
> > +static inline bool fb_modesetting_disabled(const char *drvname)
> >  {
> >   return false;
> >  }
> > --
> > 2.35.1
>
> This commit went away for a couple of linux-next releases, but now has
> reappeared in the drm tree :-(  What went wrong?

Nothing gone wrong as such, just the drm-misc-next pull request was
sent on a regular weekly cadence, then I merged it a few days later.
The fix for this is still in the drm-misc-next queue for the next PR
which I will get this week.

Dave.

Re: linux-next: build failure after merge of the drm tree

[David Airlie]

On Tue, Oct 4, 2022 at 12:21 PM Stephen Rothwell  wrote:
>
> Hi broo...@kernel.org,
>
> On Fri, 30 Sep 2022 11:54:34 +0100 broo...@kernel.org wrote:
> >
> > After merging the drm tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > /tmp/next/build/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: 
> > In function 'dc_stream_remove_writeback':
> > /tmp/next/build/drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:527:55:
> >  error: array subscript [0, 0] is outside array bounds of 'struct 
> > dc_writeback_info[1]' [-Werror=array-bounds]
> >   527 | stream->writeback_info[j] = stream->writeback_info[i];
> >   | ~~^~~
> > cc1: all warnings being treated as errors
> >
> > Caused by
> >
> > 5d8c3e836fc224 ("drm/amd/display: fix array-bounds error in 
> > dc_stream_remove_writeback()")
> >
> > I have reverted that commit for today.
>
> I am still getting this failure.  The full error is:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c: In function 
> 'dc_stream_remove_writeback':
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:527:83: error: 
> array subscript [0, 0] is outside array bounds of 'struct 
> dc_writeback_info[1]' [-Werror=array-bounds]
>   527 | stream->writeback_info[j] = 
> stream->writeback_info[i];
>   | 
> ~~^~~
> In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc.h:1269,
>  from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/inc/core_types.h:29,
>  from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/basics/dc_common.h:29,
>  from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:27:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dc_stream.h:241:34: note: while 
> referencing 'writeback_info'
>   241 | struct dc_writeback_info writeback_info[MAX_DWB_PIPES];
>   |  ^~

I'm not seeing it here, what gcc is this with?

Dave.

Re: [PATCH v2] drm/qxl: fix qxl can't use in arm64

[David Airlie]

I'd like to make sure this has no side effects on x86 guests, it
probably is safe, but keep an eye for regression reports.

Reviewed-by: Dave Airlie 
Dave.

On Wed, Mar 30, 2022 at 8:20 PM Cong Liu  wrote:
>
> any suggestions or extra test I can do now?
>
> Regards,
> Cong
>
> On 2022/3/25 15:45, Christian König wrote:
> > Am 24.03.22 um 11:49 schrieb Cong Liu:
> >> qxl use ioremap to map ram_header and rom, in the arm64 implementation,
> >> the device is mapped as DEVICE_nGnRE, it can not support unaligned
> >> access. and qxl is a virtual device, it can be treated more like RAM
> >> than actual MMIO registers. use ioremap_wc() replace it.
> >>
> >> Signed-off-by: Cong Liu 
> >
> > Looks sane to me, but I'm really not involved enough to fully judge.
> >
> > Acked-by: Christian König 
> >
> >> ---
> >>   drivers/gpu/drm/qxl/qxl_kms.c | 4 ++--
> >>   drivers/gpu/drm/qxl/qxl_ttm.c | 4 ++--
> >>   2 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/qxl/qxl_kms.c
> >> b/drivers/gpu/drm/qxl/qxl_kms.c
> >> index 4dc5ad13f12c..a054e4a00fe8 100644
> >> --- a/drivers/gpu/drm/qxl/qxl_kms.c
> >> +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> >> @@ -165,7 +165,7 @@ int qxl_device_init(struct qxl_device *qdev,
> >>(int)qdev->surfaceram_size / 1024,
> >>(sb == 4) ? "64bit" : "32bit");
> >> -qdev->rom = ioremap(qdev->rom_base, qdev->rom_size);
> >> +qdev->rom = ioremap_wc(qdev->rom_base, qdev->rom_size);
> >>   if (!qdev->rom) {
> >>   pr_err("Unable to ioremap ROM\n");
> >>   r = -ENOMEM;
> >> @@ -183,7 +183,7 @@ int qxl_device_init(struct qxl_device *qdev,
> >>   goto rom_unmap;
> >>   }
> >> -qdev->ram_header = ioremap(qdev->vram_base +
> >> +qdev->ram_header = ioremap_wc(qdev->vram_base +
> >>  qdev->rom->ram_header_offset,
> >>  sizeof(*qdev->ram_header));
> >>   if (!qdev->ram_header) {
> >> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c
> >> b/drivers/gpu/drm/qxl/qxl_ttm.c
> >> index b2e33d5ba5d0..95df5750f47f 100644
> >> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> >> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> >> @@ -82,13 +82,13 @@ int qxl_ttm_io_mem_reserve(struct ttm_device *bdev,
> >>   case TTM_PL_VRAM:
> >>   mem->bus.is_iomem = true;
> >>   mem->bus.offset = (mem->start << PAGE_SHIFT) + qdev->vram_base;
> >> -mem->bus.caching = ttm_cached;
> >> +mem->bus.caching = ttm_write_combined;
> >>   break;
> >>   case TTM_PL_PRIV:
> >>   mem->bus.is_iomem = true;
> >>   mem->bus.offset = (mem->start << PAGE_SHIFT) +
> >>   qdev->surfaceram_base;
> >> -mem->bus.caching = ttm_cached;
> >> +mem->bus.caching = ttm_write_combined;
> >>   break;
> >>   default:
> >>   return -EINVAL;
> >
>

Re: BUG: KASAN: use-after-free in enqueue_timer+0x4f/0x1e0

[David Airlie]

On Tue, Oct 12, 2021 at 2:07 AM Kim Phillips  wrote:
>
> Hi,
>
> On 10/5/21 1:10 PM, Kim Phillips wrote:
> > Hi, I occasionally see the below trace with Linus' master on an
> > AMD Milan system:
> >
> > [   25.657322] BUG: kernel NULL pointer dereference, address: 
> > 
> > [   25.665097] #PF: supervisor instruction fetch in kernel mode
> > [   25.671448] #PF: error_code(0x0010) - not-present page
> 
> > That bisection led to this commit:
> >
> > commit aae74ff9caa8de9a45ae2e46068c417817392a26
> > Author: Ainux 
> > Date:   Wed May 26 19:15:15 2021 +0800
> >  drm/ast: Add detect function support
> 
> > I confirmed that if I revert it from v5.15-rc4 (after reverting
> > its dependent 572994bf18ff "drm/ast: Zero is missing in detect
> > function"), the problem goes away.
> >
> > Full .config, dmesg attached.
> >
> > I can test any possible fixes...
>
>
> Ping - if no fixes are in the works, can the offending commit(s)
> be reverted?

tzimmermann?

Dave.

Re: Kernel 5.14.0 - invalid opcode: 0000 [#1] SMP NOPTI

[David Airlie]

cc'ing lists/people

On Sun, Sep 5, 2021 at 11:50 AM Andrew Falcon  wrote:
>
> Hello,
>
> I am encountering a kernel panic with the error in the subject line using 
> kernel 5.14.0 (final). Kernel 5.14.0-rc7 works without issue for me so 
> looking back at the last amdgpu commits for 5.14.0 (final) not sure which one 
> is at fault and causing the panic - 
> https://cgit.freedesktop.org/drm/drm/tag/?h=drm-fixes-2021-08-27
>
> I filed a kernel bug here - 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942684 with a full log 
> attached in the report. I am not sure if a separate bug report is needed in 
> drm kernel? I'm hoping I can get some advice on who needs to be aware of this 
> bug or how to bring it to the right developer's attention...
>
> Below is the boot log and the specific error message:
>
> Sep 04 09:07:39 bluestang-pc kernel: [drm] initializing kernel modesetting 
> (SIENNA_CICHLID 0x1002:0x73BF 0x1849:0x5201 0xC1).
> Sep 04 09:07:39 bluestang-pc kernel: amdgpu :2f:00.0: amdgpu: Trusted 
> Memory Zone (TMZ) feature not supported
> Sep 04 09:07:39 bluestang-pc kernel: [drm] register mmio base: 0xFC90
> Sep 04 09:07:39 bluestang-pc kernel: [drm] register mmio size: 1048576
> Sep 04 09:07:39 bluestang-pc kernel: invalid opcode:  [#1] SMP NOPTI
> Sep 04 09:07:39 bluestang-pc kernel: CPU: 1 PID: 533 Comm: systemd-udevd Not 
> tainted 5.14.1-051401-generic #202109030936
> Sep 04 09:07:39 bluestang-pc kernel: Hardware name: Micro-Star International 
> Co., Ltd. MS-7C84/MAG X570 TOMAHAWK WIFI (MS-7C84), BIOS 1.81 08/05/2021
> Sep 04 09:07:39 bluestang-pc kernel: RIP: 
> 0010:amdgpu_discovery_reg_base_init+0x225/0x260 [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel: Code: 0f 85 d4 fe ff ff 48 83 45 c0 01 
> 48 8b 45 c0 39 45 c8 0f 8f 55 fe ff ff 8b 45 b4 48 8d 65 d8 5b 41 5c 41 5d 41 
> 5e 41 5f 5d c3 <0f> 0b 48 c7 c7 e4 5a 61 c1 e8 9d 79 10 ff eb de 41 89 d0 48 
> c7 c7
> Sep 04 09:07:39 bluestang-pc kernel: RSP: 0018:b883c1907928 EFLAGS: 
> 00010202
> Sep 04 09:07:39 bluestang-pc kernel: RAX: 0008 RBX: 
> 99558b89f128 RCX: 0006
> Sep 04 09:07:39 bluestang-pc kernel: RDX: c1615b69 RSI: 
> c15c0428 RDI: 
> Sep 04 09:07:39 bluestang-pc kernel: RBP: b883c1907978 R08: 
> 0008 R09: 000b
> Sep 04 09:07:39 bluestang-pc kernel: R10: 99558b89f120 R11: 
>  R12: 995587c0
> Sep 04 09:07:39 bluestang-pc kernel: R13: 0019 R14: 
> 0019 R15: 99558b89f120
> Sep 04 09:07:39 bluestang-pc kernel: FS:  7f3d5b7138c0() 
> GS:995c7ea4() knlGS:
> Sep 04 09:07:39 bluestang-pc kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Sep 04 09:07:39 bluestang-pc kernel: CR2: 7fc505b6c420 CR3: 
> 000106d9 CR4: 00750ee0
> Sep 04 09:07:39 bluestang-pc kernel: PKRU: 5554
> Sep 04 09:07:39 bluestang-pc kernel: Call Trace:
> Sep 04 09:07:39 bluestang-pc kernel:  nv_set_ip_blocks+0x8e/0xab0 [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  amdgpu_device_ip_early_init+0x2b1/0x47f 
> [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  ? 
> amdgpu_device_get_job_timeout_settings+0x90/0x1cc [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  amdgpu_device_init.cold+0xc9/0x6d1 
> [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  amdgpu_driver_load_kms+0x6d/0x310 
> [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  amdgpu_pci_probe+0x11b/0x1a0 [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  local_pci_probe+0x48/0x80
> Sep 04 09:07:39 bluestang-pc kernel:  pci_device_probe+0x105/0x1d0
> Sep 04 09:07:39 bluestang-pc kernel:  really_probe+0x1fe/0x400
> Sep 04 09:07:39 bluestang-pc kernel:  __driver_probe_device+0x109/0x180
> Sep 04 09:07:39 bluestang-pc kernel:  driver_probe_device+0x23/0x90
> Sep 04 09:07:39 bluestang-pc kernel:  __driver_attach+0xac/0x1b0
> Sep 04 09:07:39 bluestang-pc kernel:  ? __device_attach_driver+0xe0/0xe0
> Sep 04 09:07:39 bluestang-pc kernel:  bus_for_each_dev+0x7e/0xc0
> Sep 04 09:07:39 bluestang-pc kernel:  driver_attach+0x1e/0x20
> Sep 04 09:07:39 bluestang-pc kernel:  bus_add_driver+0x135/0x1f0
> Sep 04 09:07:39 bluestang-pc kernel:  driver_register+0x95/0xf0
> Sep 04 09:07:39 bluestang-pc kernel:  __pci_register_driver+0x68/0x70
> Sep 04 09:07:39 bluestang-pc kernel:  amdgpu_init+0x7c/0x1000 [amdgpu]
> Sep 04 09:07:39 bluestang-pc kernel:  ? 0xc0e95000
> Sep 04 09:07:39 bluestang-pc kernel:  do_one_initcall+0x48/0x1d0
> Sep 04 09:07:39 bluestang-pc kernel:  ? kmem_cache_alloc_trace+0x159/0x2c0
> Sep 04 09:07:39 bluestang-pc kernel:  do_init_module+0x62/0x290
> Sep 04 09:07:39 bluestang-pc kernel:  load_module+0xaa8/0xb40
> Sep 04 09:07:39 bluestang-pc kernel:  __do_sys_finit_module+0xbf/0x120
> Sep 04 09:07:39 bluestang-pc kernel:  __x64_sys_finit_module+0x18/0x20
> Sep 04 09:07:39 bluestang-pc kernel:  do_syscall_64+0x5c/0xc0
> Sep 04 09:07:39 bluestang-pc kernel:  ? 

Re: [PATCH] drm/i915: Add relocation exceptions for two other platforms

[David Airlie]

On Wed, Jun 2, 2021 at 12:25 AM Zbigniew Kempczyński
 wrote:
>
> We have established previously we stop using relocations starting
> from gen12 platforms with Tigerlake as an exception. We keep this
> statement but we want to enable relocations conditionally for
> Rocketlake and Alderlake under require_force_probe flag set.
>
> Keeping relocations under require_force_probe flag is interim solution
> until IGTs will be rewritten to use softpin.
>
> v2: - remove inline from function definition (Jani)
> - fix indentation
>
> Signed-off-by: Zbigniew Kempczyński 
> Cc: Dave Airlie 
> Cc: Daniel Vetter 
> Cc: Jason Ekstrand 

Acked-by: Dave Airlie 
> ---
>  .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 +++
>  1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 297143511f99..78b86a7bc39a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -491,16 +491,30 @@ eb_unreserve_vma(struct eb_vma *ev)
> ev->flags &= ~__EXEC_OBJECT_RESERVED;
>  }
>
> +static bool platform_has_relocs_enabled(const struct i915_execbuffer *eb)
> +{
> +   /*
> +* Relocations are disallowed starting from gen12 with Tigerlake
> +* as an exception. We allow temporarily use relocations for 
> Rocketlake
> +* and Alderlake when require_force_probe flag is set.
> +*/
> +   if (INTEL_GEN(eb->i915) < 12 || IS_TIGERLAKE(eb->i915))
> +   return true;
> +
> +   if (INTEL_INFO(eb->i915)->require_force_probe &&
> +   (IS_ROCKETLAKE(eb->i915) || IS_ALDERLAKE_S(eb->i915) ||
> +IS_ALDERLAKE_P(eb->i915)))
> +   return true;
> +
> +   return false;
> +}
> +
>  static int
>  eb_validate_vma(struct i915_execbuffer *eb,
> struct drm_i915_gem_exec_object2 *entry,
> struct i915_vma *vma)
>  {
> -   /* Relocations are disallowed for all platforms after TGL-LP.  This
> -* also covers all platforms with local memory.
> -*/
> -   if (entry->relocation_count &&
> -   INTEL_GEN(eb->i915) >= 12 && !IS_TIGERLAKE(eb->i915))
> +   if (entry->relocation_count && !platform_has_relocs_enabled(eb))
> return -EINVAL;
>
> if (unlikely(entry->flags & eb->invalid_flags))
> --
> 2.26.0
>

Re: [PATCH] drm/ast: Avoid to access BMC addressing when P2A is disabled

[David Airlie]

On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou
 wrote:
>
> The patch is upstreamed
> 1. For RHEL7.x, because its native kernel is suggested to update
>from 3.10 to 4.9 on 2 ODM's platform.
> 2. For AST2600.
> 3. For ASTDP.
> 4. v1.11

Hi,

I've cc'ed Thomas who is maintaining this upstream, but this patch in
it's current form isn't acceptable, Maybe Thomas can provide more
detailed info, but the basic rules are

One patch should do one thing.
Patches should be bisectable so any issues can be tracked down easier.
Fixes should be separated from new code.
New features and chip support should be separate.

https://www.kernel.org/doc/html/v5.9/process/submitting-patches.html

Please maybe work with Thomas on having a better upstream development
process for ast chipsets.

Thanks,
Dave.

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

Re: Msg "PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] returns -22" after migrating to V5.6.7 kernel from v5.5.10.

[David Airlie]

36:08.055762 kernel: Filesystems sync: 0.069 seconds
> Apr 28 14:36:08.055898 kernel: Freezing user space processes ... (elapsed 
> 0.001 seconds) done.
> Apr 28 14:36:08.056031 kernel: OOM killer disabled.
> Apr 28 14:36:08.056108 kernel: Freezing remaining freezable tasks ... 
> (elapsed 0.001 seconds) done.
> Apr 28 14:36:08.056182 kernel: printk: Suspending console(s) (use 
> no_console_suspend to debug)
> Apr 28 14:36:08.056239 kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
> Apr 28 14:36:08.056872 kernel: sd 6:0:1:0: [sdc] Synchronizing SCSI cache
> Apr 28 14:36:08.057477 kernel: serial 00:09: disabled
> Apr 28 14:36:08.057795 kernel: serial 00:06: disabled
> Apr 28 14:36:08.058070 kernel: serial 00:05: disabled
> Apr 28 14:36:08.058332 kernel: PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 
> [ast] returns -22
> Apr 28 14:36:08.058386 kernel: PM: dpm_run_callback(): 
> pci_pm_suspend+0x0/0x160 returns -22
> Apr 28 14:36:08.058435 kernel: PM: Device :04:00.0 failed to suspend 
> async: error -22
> Apr 28 14:36:08.058472 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
> Apr 28 14:36:08.058879 kernel: sd 0:0:0:0: [sda] Stopping disk
> Apr 28 14:36:08.059229 kernel: ata6: SATA link down (SStatus 0 SControl 300)
> Apr 28 14:36:08.059289 kernel: ata4: SATA link down (SStatus 0 SControl 300)
> Apr 28 14:36:08.059337 kernel: ata2: SATA link down (SStatus 0 SControl 300)
> Apr 28 14:36:08.059384 kernel: ata3: SATA link down (SStatus 0 SControl 300)
> Apr 28 14:36:08.059433 kernel: ata5: SATA link down (SStatus 0 SControl 300)
> Apr 28 14:36:08.059470 kernel: PM: Some devices failed to suspend, or early 
> wake event detected
> Apr 28 14:36:08.059515 kernel: sd 0:0:0:0: [sda] Starting disk
> Apr 28 14:36:08.059840 kernel: serial 00:05: activated
> Apr 28 14:36:08.060115 kernel: serial 00:06: activated
> Apr 28 14:36:08.060378 kernel: serial 00:09: activated
> Apr 28 14:36:08.060632 kernel: OOM killer enabled.
> Apr 28 14:36:08.060684 kernel: Restarting tasks ... done.
> Apr 28 14:36:08.060738 kernel: PM: suspend exit
> Apr 28 14:36:08.056877 systemd-sleep[822]: Failed to suspend system. System 
> resumed again: Invalid
> argument
>
> Hopes this helps. Cary
>
> On Tue, 2020-04-28 at 09:11 +1000, David Airlie wrote:
> > Adding dri-devel.
> >
> > This might need a bisect to work out where it went wrong,
> >
> > Dave.
> >
> > On Tue, Apr 28, 2020 at 7:48 AM Cary Garrett  wrote:
> > > Hello,
> > >
> > > System won't go into suspend state after migrating to V5.6.7 kernel. 
> > > Working in V5.5.10.
> > >
> > > Journal showing following:
> > >
> > > Apr 27 16:07:54 kernel: PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 
> > > [ast] returns -22
> > > Apr 27 16:07:54 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 
> > > returns -22
> > > Apr 27 16:07:54 kernel: PM: Device :04:00.0 failed to suspend async: 
> > > error -22
> > >
> > > Journalctl output at time of failure:
> > >
> > > -- Logs begin at Tue 2020-04-21 17:10:11 CDT, end at Mon 2020-04-27 
> > > 16:23:33 CDT. --
> > > Apr 27 16:07:54 systemd[1]: Reached target Sleep.
> > > Apr 27 16:07:54 systemd[1]: Starting Suspend...
> > > Apr 27 16:07:54 systemd-sleep[1104]: Suspending system...
> > > Apr 27 16:07:54 kernel: PM: suspend entry (deep)
> > > Apr 27 16:07:54 kernel: Filesystems sync: 0.091 seconds
> > > Apr 27 16:07:54 kernel: Freezing user space processes ... (elapsed 0.001 
> > > seconds) done.
> > > Apr 27 16:07:54 kernel: OOM killer disabled.
> > > Apr 27 16:07:54 kernel: Freezing remaining freezable tasks ... (elapsed 
> > > 0.001 seconds) done.
> > > Apr 27 16:07:54 kernel: printk: Suspending console(s) (use 
> > > no_console_suspend to debug)
> > > Apr 27 16:07:54 kernel: sd 6:0:1:0: [sdc] Synchronizing SCSI cache
> > > Apr 27 16:07:54 kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
> > > Apr 27 16:07:54 kernel: serial 00:09: disabled
> > > Apr 27 16:07:54 kernel: serial 00:06: disabled
> > > Apr 27 16:07:54 kernel: serial 00:05: disabled
> > > Apr 27 16:07:54 kernel: PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 
> > > [ast] returns -22
> > > Apr 27 16:07:54 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 
> > > returns -22
> > > Apr 27 16:07:54 kernel: PM: Device :04:00.0 failed to suspend async: 
> > > error -22
> > > Apr 27 16:07:54 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > > Apr 27 16:07:54 kernel: sd 0:0:0:0: [sda] Stopping disk
> > > Apr 27 16:07

Re: Msg "PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] returns -22" after migrating to V5.6.7 kernel from v5.5.10.

[David Airlie]

Adding dri-devel.

This might need a bisect to work out where it went wrong,

Dave.

On Tue, Apr 28, 2020 at 7:48 AM Cary Garrett  wrote:
>
> Hello,
>
> System won't go into suspend state after migrating to V5.6.7 kernel. Working 
> in V5.5.10.
>
> Journal showing following:
>
> Apr 27 16:07:54 kernel: PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] 
> returns -22
> Apr 27 16:07:54 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 
> returns -22
> Apr 27 16:07:54 kernel: PM: Device :04:00.0 failed to suspend async: 
> error -22
>
> Journalctl output at time of failure:
>
> -- Logs begin at Tue 2020-04-21 17:10:11 CDT, end at Mon 2020-04-27 16:23:33 
> CDT. --
> Apr 27 16:07:54 systemd[1]: Reached target Sleep.
> Apr 27 16:07:54 systemd[1]: Starting Suspend...
> Apr 27 16:07:54 systemd-sleep[1104]: Suspending system...
> Apr 27 16:07:54 kernel: PM: suspend entry (deep)
> Apr 27 16:07:54 kernel: Filesystems sync: 0.091 seconds
> Apr 27 16:07:54 kernel: Freezing user space processes ... (elapsed 0.001 
> seconds) done.
> Apr 27 16:07:54 kernel: OOM killer disabled.
> Apr 27 16:07:54 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 
> seconds) done.
> Apr 27 16:07:54 kernel: printk: Suspending console(s) (use no_console_suspend 
> to debug)
> Apr 27 16:07:54 kernel: sd 6:0:1:0: [sdc] Synchronizing SCSI cache
> Apr 27 16:07:54 kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
> Apr 27 16:07:54 kernel: serial 00:09: disabled
> Apr 27 16:07:54 kernel: serial 00:06: disabled
> Apr 27 16:07:54 kernel: serial 00:05: disabled
> Apr 27 16:07:54 kernel: PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] 
> returns -22
> Apr 27 16:07:54 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 
> returns -22
> Apr 27 16:07:54 kernel: PM: Device :04:00.0 failed to suspend async: 
> error -22
> Apr 27 16:07:54 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
> Apr 27 16:07:54 kernel: sd 0:0:0:0: [sda] Stopping disk
> Apr 27 16:07:54 kernel: PM: Some devices failed to suspend, or early wake 
> event detected
> Apr 27 16:07:54 kernel: sd 0:0:0:0: [sda] Starting disk
> Apr 27 16:07:54 kernel: serial 00:05: activated
> Apr 27 16:07:54 kernel: serial 00:06: activated
> Apr 27 16:07:54 kernel: serial 00:09: activated
> Apr 27 16:07:54 kernel: OOM killer enabled.
> Apr 27 16:07:54 kernel: Restarting tasks ... done.
> Apr 27 16:07:54 kernel: PM: suspend exit
> Apr 27 16:07:54 kernel: PM: suspend entry (s2idle)
> Apr 27 16:07:55 kernel: Filesystems sync: 0.078 seconds
> Apr 27 16:07:55 kernel: Freezing user space processes ... (elapsed 0.001 
> seconds) done.
> Apr 27 16:07:55 kernel: OOM killer disabled.
> Apr 27 16:07:55 kernel: Freezing remaining freezable tasks ... (elapsed 0.001 
> seconds) done.
> Apr 27 16:07:55 kernel: printk: Suspending console(s) (use no_console_suspend 
> to debug)
> Apr 27 16:07:55 kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
> Apr 27 16:07:55 kernel: sd 6:0:1:0: [sdc] Synchronizing SCSI cache
> Apr 27 16:07:55 kernel: serial 00:09: disabled
> Apr 27 16:07:55 kernel: serial 00:06: disabled
> Apr 27 16:07:55 kernel: serial 00:05: disabled
> Apr 27 16:07:55 kernel: PM: pci_pm_suspend(): ast_pm_suspend+0x0/0x40 [ast] 
> returns -22
> Apr 27 16:07:55 kernel: PM: dpm_run_callback(): pci_pm_suspend+0x0/0x160 
> returns -22
> Apr 27 16:07:55 kernel: PM: Device :04:00.0 failed to suspend async: 
> error -22
> Apr 27 16:07:55 kernel: mpt2sas_cm0: pdev=0x03c9e977, 
> slot=:02:00.0, entering operating
> state [D4]
> Apr 27 16:07:55 kernel: mpt2sas_cm0: sending message unit reset !!
> Apr 27 16:07:55 kernel: mpt2sas_cm0: message unit reset: SUCCESS
> Apr 27 16:07:55 kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache
> Apr 27 16:07:55 kernel: sd 0:0:0:0: [sda] Stopping disk
> Apr 27 16:07:55 kernel: ata3: SATA link down (SStatus 0 SControl 300)
> Apr 27 16:07:55 kernel: ata2: SATA link down (SStatus 0 SControl 300)
> Apr 27 16:07:55 kernel: ata4: SATA link down (SStatus 0 SControl 300)
> Apr 27 16:07:55 kernel: ata6: SATA link down (SStatus 0 SControl 300)
> Apr 27 16:07:55 kernel: ata5: SATA link down (SStatus 0 SControl 300)
> Apr 27 16:07:55 kernel: PM: Some devices failed to suspend, or early wake 
> event detected
> Apr 27 16:07:55 kernel: sd 0:0:0:0: [sda] Starting disk
> Apr 27 16:07:55 kernel: serial 00:05: activated
> Apr 27 16:07:55 kernel: serial 00:06: activated
> Apr 27 16:07:55 kernel: serial 00:09: activated
> Apr 27 16:07:55 kernel: mpt2sas_cm0: pdev=0x03c9e977, 
> slot=:02:00.0, previous operating
> state [D0]
> Apr 27 16:07:55 kernel: mpt2sas_cm0: 64 BIT PCI BUS DMA ADDRESSING SUPPORTED, 
> total mem (16354848
> kB)
> Apr 27 16:07:55 kernel: mpt2sas_cm0: CurrentHostPageSize is 0: Setting 
> default host page size to 4k
> Apr 27 16:07:55 kernel: mpt2sas_cm0: MSI-X vectors supported: 16
> Apr 27 16:07:55 kernel:  no of cores: 8, max_msix_vectors: -1
> Apr 27 16:07:55 kernel: mpt2sas_cm0:  0 8
> Apr 27 16:07:55 kernel: 

Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'

[David Airlie]

On Fri, Dec 6, 2019 at 4:14 PM Thomas Zimmermann  wrote:
>
> Hi
>
> Am 04.12.19 um 10:36 schrieb Dave Airlie:
> > On Wed, 4 Dec 2019 at 17:30, Thomas Zimmermann  wrote:
> >>
> >> Hi John
> >>
> >> Am 03.12.19 um 18:55 schrieb John Donnelly:
> >>> Hi ,
> >>>
> >>> See below ,
> >>>
> >>>
>  On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann  
>  wrote:
> 
>  Hi
> 
>  Am 26.11.19 um 10:37 schrieb Daniel Vetter:
> > On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
> >> There's at least one system that does not interpret the value of
> >> the device's 'startadd' field correctly, which leads to incorrectly
> >> displayed scanout buffers. Always placing the active scanout buffer
> >> at offset 0 works around the problem.
> >>
> >> Signed-off-by: Thomas Zimmermann 
> >> Reported-by: John Donnelly 
> >> Link: https://gitlab.freedesktop.org/drm/misc/issues/7
> >
> > Tested-by: John Donnelly 
> >
> > (Not quite this patch, but pretty much the logic, so counts).
> >
> > Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with 
> > kunmap + unpin")
> > Cc:  # v5.3+
> >
> > Also you need the stable line on both prep patches too. For next time
> > around,
> >
> > $ dim fixes 81da87f63a1e
> >
> > will generate all the stuff you need, including a good set of suggested
> > Cc: you should have.
> >
> > On the first 3 patches, with all that stuff added:
> >
> > Reviewed-by: Daniel Vetter 
> 
>  Thanks for the review.
> 
>  Sorry for leaving out some of the tags. I wanted to wait for feedback
>  before adding tested-by, fixes, stable. I'll split off patch 4 from the
>  series and get 1 to 3 merged ASAP.
> 
>  Best regards
>  Thomas
> 
> >
> > Please push these to drm-misc-next-fixes so they get backported as 
> > quickly
> > as possible.
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
> >> drivers/gpu/drm/mgag200/mgag200_drv.h |  3 +++
> >> 2 files changed, 38 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
> >> b/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> index 397f8b0a9af8..d43951caeea0 100644
> >> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> >> @@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int, 
> >> 0400);
> >> static struct drm_driver driver;
> >>
> >> static const struct pci_device_id pciidlist[] = {
> >> +  { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
> >> +  G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
> >>>
> >>>
> >>>
> >>> I will have an additional list of vendor IDs (0x4852)  I will provide in 
> >>> a follow up patch shortly .  This fixes only 1 flavor  of server.
> >>
> >> Thank you for all the testing you do. We can add these ids as necessary.
> >>
> >> Before, I posted a patch at [1] that prints an internal unique id. The
> >> id of your original test machine was 0x2 IIRC.
> >>
> >> My guess is that the problem might be related to the chip's revision. If
> >> you have the option of booting your own kernels on all these machines,
> >> could you apply the patch and look for a pattern in these ids? Maybe
> >> only revision 0x2 is affected.
> >>
> >
> > I've got an old bug I never got around to that has a comment from Matrox
> >
> > "The issue is reproducible with G200e chip. The device ID is 0x0522."
> >
> > so it might be a broader problem than we think.
>
> Did they tell you a subvendor id? John reported that the internal
> revision id differs among affected machines. I'm thinking about flagging
> either Sun devices or all 0x0522 devices as broken.

Well it was from Matrox themselves, so they are the vendor ID, it
didn't sounds like subvendor mattered, though I expect the problem is
the BMC firmware anyways, not sure if we can even know what ths is.

Dave.

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

Re: [PATCH v2] drm/qxl: get vga ioports

[David Airlie]

Reviewed-by: Dave Airlie 

On Thu, Aug 22, 2019 at 4:59 PM Gerd Hoffmann  wrote:
>
> On Mon, Aug 05, 2019 at 12:54:01PM +0200, Gerd Hoffmann wrote:
> > qxl has two modes: "native" (used by the drm driver) and "vga" (vga
> > compatibility mode, typically used for boot display and firmware
> > framebuffers).
> >
> > Accessing any vga ioport will switch the qxl device into vga mode.
> > The qxl driver never does that, but other drivers accessing vga ports
> > can trigger that too and therefore disturb qxl operation.  So aquire
> > the legacy vga ioports from vgaarb to avoid that.
> >
> > Reproducer: Boot kvm guest with both qxl and i915 vgpu, with qxl being
> > first in pci scan order.
> >
> > v2: Skip this for secondary qxl cards which don't have vga mode in the
> > first place (Frediano).
>
> Ping, any chance for an ack?
>
> thanks,
>   Gerd
>
> >
> > Cc: Frediano Ziglio 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >  drivers/gpu/drm/qxl/qxl_drv.c | 20 +++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> > index b57a37543613..fcb48ac60598 100644
> > --- a/drivers/gpu/drm/qxl/qxl_drv.c
> > +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> > @@ -63,6 +63,11 @@ module_param_named(num_heads, qxl_num_crtc, int, 0400);
> >  static struct drm_driver qxl_driver;
> >  static struct pci_driver qxl_pci_driver;
> >
> > +static bool is_vga(struct pci_dev *pdev)
> > +{
> > + return pdev->class == PCI_CLASS_DISPLAY_VGA << 8;
> > +}
> > +
> >  static int
> >  qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> >  {
> > @@ -87,9 +92,17 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> >   if (ret)
> >   goto disable_pci;
> >
> > + if (is_vga(pdev)) {
> > + ret = vga_get_interruptible(pdev, VGA_RSRC_LEGACY_IO);
> > + if (ret) {
> > + DRM_ERROR("can't get legacy vga ioports\n");
> > + goto disable_pci;
> > + }
> > + }
> > +
> >   ret = qxl_device_init(qdev, _driver, pdev);
> >   if (ret)
> > - goto disable_pci;
> > + goto put_vga;
> >
> >   ret = qxl_modeset_init(qdev);
> >   if (ret)
> > @@ -109,6 +122,9 @@ qxl_pci_probe(struct pci_dev *pdev, const struct 
> > pci_device_id *ent)
> >   qxl_modeset_fini(qdev);
> >  unload:
> >   qxl_device_fini(qdev);
> > +put_vga:
> > + if (is_vga(pdev))
> > + vga_put(pdev, VGA_RSRC_LEGACY_IO);
> >  disable_pci:
> >   pci_disable_device(pdev);
> >  free_dev:
> > @@ -126,6 +142,8 @@ qxl_pci_remove(struct pci_dev *pdev)
> >
> >   qxl_modeset_fini(qdev);
> >   qxl_device_fini(qdev);
> > + if (is_vga(pdev))
> > + vga_put(pdev, VGA_RSRC_LEGACY_IO);
> >
> >   dev->dev_private = NULL;
> >   kfree(qdev);
> > --
> > 2.18.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm] tests/util: fix incorrect memset argument order

[David Airlie]

Reviewed-by: Dave Airlie 

On Wed, Jul 3, 2019 at 1:20 PM Ilia Mirkin  wrote:
>
> Make it actually clear the LUT.
>
> Reported-by: Dave Airlie 
> Signed-off-by: Ilia Mirkin 
> ---
>  tests/util/pattern.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/util/pattern.c b/tests/util/pattern.c
> index 42a0e5c7..bf1797d4 100644
> --- a/tests/util/pattern.c
> +++ b/tests/util/pattern.c
> @@ -643,7 +643,7 @@ void util_smpte_c8_gamma(unsigned size, struct 
> drm_color_lut *lut)
> printf("Error: gamma too small: %d < %d\n", size, 7 + 7 + 8);
> return;
> }
> -   memset(lut, size * sizeof(struct drm_color_lut), 0);
> +   memset(lut, 0, size * sizeof(struct drm_color_lut));
>
>  #define FILL_COLOR(idx, r, g, b) \
> lut[idx].red = (r) << 8; \
> --
> 2.21.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/qxl: drop prime import/export callbacks

[David Airlie]

On Tue, Apr 9, 2019 at 4:03 PM Gerd Hoffmann  wrote:
>
> On Tue, Apr 09, 2019 at 02:01:33PM +1000, Dave Airlie wrote:
> > On Sat, 12 Jan 2019 at 07:13, Dave Airlie  wrote:
> > >
> > > On Thu, 10 Jan 2019 at 18:17, Gerd Hoffmann  wrote:
> > > >
> > > > Also set prime_handle_to_fd and prime_fd_to_handle to NULL,
> > > > so drm will not advertive DRM_PRIME_CAP_{IMPORT,EXPORT} to
> > > > userspace.
> >
> > It's been pointed out to me that disables DRI3 for these devices, I'm
> > not sure that is the solution we actually wanted.
> >
> > any ideas?
>
> Well.  Lets have a look at where we stand:
>
>  * drm_gem_prime_export() works with qxl, you'll get a dma-buf handle.
>
>  * Other drivers trying to map that dma-buf (drm_gem_map_dma_buf()
>callback) will not work, due to the ->gem_prime_get_sg_table()
>callback not being there.
>
>  * drm_gem_prime_import() will work with buffers from the same qxl
>device, there is a shortcut for this special case.  Otherwise it
>will not work, due to the ->gem_prime_import_sg_table() callback
>not being there.
>
> Bottom line: you can use prime to pass qxl object handles from one
> application to another.  But you can't actually export/import qxl
> buffer objects from/to other devices.
>
> Problem is that we have no way to signal to userspace that prime can
> be used that way.
>
> Setting DRM_PRIME_CAP_{IMPORT,EXPORT} even though the driver can't
> do that leads to other problems.  Userspace thinks it can have other
> devices (intel vgpu for example) handle the rendering, then import
> the rendered buffer into qxl for scanout.
>
> Should we add something like DRM_PRIME_CAP_SAME_DEVICE?

Yeah I expect we need some sort of same device only capability, so
that dri3 userspace can work.

If we just fail importing in these cases what happens? userspace just
gets confused, I know we used to print a backtrace if we hit the mmap
path, but if we didn't do that what happens?

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

Re: [PATCH] drm/cirrus: rewrite and modernize driver.

[David Airlie]

On Wed, Apr 3, 2019 at 5:23 PM Gerd Hoffmann  wrote:
>
> Time to kill some bad sample code people are copying from ;)
>
> This is a complete rewrite of the cirrus driver.  The cirrus_mode_set()
> function is pretty much the only function which is carried over largely
> unmodified.  Everything else is upside down.
>
> It is a single monster patch.  But given that it does some pretty
> fundamental changes to the drivers workflow and also reduces the code
> size by roughly 70% I think it'll still be alot easier to review than a
> longish baby-step patch series.
>
> Changes summary:
>  - Given the small amout of video memory (4 MB) the cirrus device has
>the rewritten driver doesn't try to manage buffers there.  Instead
>it will blit (memcpy) the active framebuffer to video memory.

Does it get any slower, with TTM I just wrote it to migrate just the
frontbuffer in/out of VRAM on modeset, won't we end up with more
copies now?

>  - All gem objects are stored in main memory and are manged using the
>new shmem helpers.  ttm is out.
>  - Only DRM_FORMAT_RGB565 (depth 16) is supported.  The old driver does
>that too by default.  There was a module parameter which enables 24/32
>bpp support and disables higher resolutions (due to cirrus hardware
>constrains).  That parameter wasn't reimplemented.
This might be the big sticking point, this is a userspace regression
for a feature that was explicitly added a few years ago, can we really
get away without it?

The rest looks good though!
Dave.

>  - The simple display pipeline is used.
>  - The generic fbdev emulation is used.
>  - It's a atomic driver now.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Performance regression in ast drm driver

[David Airlie]

On Thu, Nov 8, 2018 at 10:05 PM Jean Delvare  wrote:
>
> On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote:
> > Hi David,
> >
> > The following commit:
> >
> > commit 7cf321d118a825c1541b43ca45294126fd474efa
> > Author: Dave Airlie
> > Date:   Mon Oct 24 15:37:48 2016 +1000
> >
> > drm/drivers: add support for using the arch wc mapping API.
> >
> > is causing a huge performance regression for the ast drm driver. In a
> > text console, if I call "cat" on a large text file, it takes almost
> > twice as much time to be displayed and scrolled completely.
> >
> > Can you please check that the ast driver portion of that commit is both
> > correct and complete?
>
> And in the meantime, what bad will happen if we just revert the ast
> portion of that commit?
>

This seems likely to be a hw problem with PCI writes to the AST "GPU",
since it's just some sort of RAM + ARM on the end of a PCIE bus, we've
definitely seen possible issues in the past with write combining
around some of the mga GPUs with some CPUs.

Have we seen the problem across a number of AST devices?

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

Re: nouveau-fixes 4.19

[David Airlie]

On Tue, Oct 9, 2018 at 11:29 AM Ben Skeggs  wrote:
>
> On Fri, Oct 5, 2018 at 5:50 PM Daniel Vetter  wrote:
> >
> > On Fri, Oct 05, 2018 at 04:45:54PM +1000, Ben Skeggs wrote:
> > > The following changes since commit 
> > > 3483f08106fcd0e8edad2b9f2fc4726d25177799:
> > >
> > >   drm/nouveau/devinit: fix warning when PMU/PRE_OS is missing
> > > (2018-09-13 10:56:58 +1000)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://github.com/skeggsb/linux linux-4.19
> > >
> > > for you to fetch changes up to e46368cf77f2cb6304c51d9ff5f147cfb7dc0074:
> > >
> > >   drm/nouveau/drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
> > > (2018-10-05 16:43:15 +1000)
> >
> > Adding Greg because Dave is out already for the w/e and this looks like
> > something we should get in.
> Ping on this, it does not appear to have been picked up yet.

I pulled it into drm-fixes yesterday, I'm pretty sure.

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

Re: [PATCH 1/2] MAINTAINERS: Move udl drm driver to drm-misc tree

[David Airlie]

On Thu, Sep 20, 2018 at 6:40 AM Sean Paul  wrote:
>
> From: Sean Paul 
>
> Move udl maintenance into drm-misc tree. I've also signed up to be a
> reviewer, but have kept it at "Odd Fixes" level of support.
>
> Cc: Dave Airlie 

Acked-by: Dave Airlie 

> Cc: David Airlie 
> Cc: Gustavo Padovan 
> Cc: Maarten Lankhorst 
> Signed-off-by: Sean Paul 
> ---
>  MAINTAINERS | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9d9068ed4ee5..ba1dbb8735b8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4720,8 +4720,11 @@ F:   drivers/gpu/drm/tdfx/
>
>  DRM DRIVER FOR USB DISPLAYLINK VIDEO ADAPTERS
>  M: Dave Airlie 
> +R: Sean Paul 
> +L: dri-devel@lists.freedesktop.org
>  S: Odd Fixes
>  F: drivers/gpu/drm/udl/
> +T: git git://anongit.freedesktop.org/drm/drm-misc
>
>  DRM DRIVER FOR VMWARE VIRTUAL GPU
>  M: "VMware Graphics" 
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Sleeping from invalid context in udlfb

[David Airlie]

I'm pretty sure udlkms handles this already.

Dave.

On Wed, Aug 1, 2018 at 11:34 PM, Mikulas Patocka 
wrote:

>
>
> On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
>
> > Hi Mikulas,
> >
> > On Wed, Aug 1, 2018 at 12:59 PM Mikulas Patocka 
> wrote:
> > > On Wed, 1 Aug 2018, Geert Uytterhoeven wrote:
> > > > On Tue, Jul 31, 2018 at 5:23 PM Mikulas Patocka 
> wrote:
> > > > > BTW when using the udlfb driver as a console, I've got this
> warning.
> > > > > vt_console_print takes a spinlock and then calls the framebuffer
> driver
> > > > > that sleeps.
> > > > >
> > > > > The question is - whose fault is this? Could the console code
> somehow be
> > > > > told to print characters without holding a spinlock? Or does it
> mean that
> > > > > framebuffer drivers can't sleep?
> > > > >
> > > > > udlfb communicates through USB, so the sleeping is inevitable.
> > > > >
> > > > > Mikulas
> > > > >
> > > > >
> > > > > BUG: sleeping function called from invalid context at mm/slab.h:421
> > > > > in_atomic(): 1, irqs_disabled(): 0, pid: 430, name: kworker/2:3
> > > > > 6 locks held by kworker/2:3/430:
> > > > >  #0: 1301127e ( (wq_completion)"events"){} , at:
> process_one_work+0x17c/0x3a8
> > > > >  #1: beacc951 ( (work_completion)(&(>
> init_framebuffer_work)->work)){} , at: process_one_work+0x17c/0x3a8
> > > > >  #2: a402f826 ( registration_lock){} , at:
> register_framebuffer+0x28/0x2c0 [fb]
> > > > >  #3: 21cbe902 ( console_lock){} , at:
> register_framebuffer+0x258/0x2c0 [fb]
> > > > >  #4: 96d51735 ( console_owner){} , at:
> console_unlock+0x174/0x500
> > > > >  #5: faa7f206 ( printing_lock){} , at:
> vt_console_print+0x60/0x3a0
> > > > > Preemption disabled at: []
> vt_console_print+0x60/0x3a0
> > > > > CPU: 2 PID: 430 Comm: kworker/2:3 Not tainted 4.17.10-debug #3
> > > > > Hardware name: Marvell Armada 8040 MacchiatoBin/Armada 8040
> MacchiatoBin, BIOS EDK II Jul 30 2018
> > > > > Workqueue: events dlfb_init_framebuffer_work [udlfb]
> > > > > Call trace:
> > > > >  dump_backtrace+0x0/0x150
> > > > >  show_stack+0x14/0x20
> > > > >  dump_stack+0x8c/0xac
> > > > >  ___might_sleep+0x140/0x170
> > > > >  __might_sleep+0x50/0x88
> > > > >  __kmalloc+0x1b0/0x270
> > > > >  xhci_urb_enqueue+0xa8/0x460 [xhci_hcd]
> > > > >  usb_hcd_submit_urb+0xc0/0x998 [usbcore]
> > > > >  usb_submit_urb+0x1e0/0x518 [usbcore]
> > > > >  dlfb_submit_urb+0x38/0x98 [udlfb]
> > > > >  dlfb_handle_damage.isra.4+0x1e0/0x210 [udlfb]
> > > > >  dlfb_ops_imageblit+0x28/0x38 [udlfb]
> > > > >  soft_cursor+0x15c/0x1d8 [fb]
> > > > >  bit_cursor+0x324/0x510 [fb]
> > > > >  fbcon_cursor+0x144/0x1a0 [fb]
> > > > >  hide_cursor+0x38/0xa0
> > > > >  vt_console_print+0x334/0x3a0
> > > > >  console_unlock+0x274/0x500
> > > > >  register_framebuffer+0x22c/0x2c0 [fb]
> > > > >  dlfb_init_framebuffer_work+0x1ec/0x2fc [udlfb]
> > > > >  process_one_work+0x1e8/0x3a8
> > > > >  worker_thread+0x44/0x418
> > > > >  kthread+0x11c/0x120
> > > > >  ret_from_fork+0x10/0x18
> > > >
> > > > This is sort of expected: you cannot do USB transfers from printk().
> > > >
> > > > Gr{oetje,eeting}s,
> > > >
> > > > Geert
> > >
> > > So, should there be a framebuffer flag that prevents the console from
> > > binding to it?
> > >
> > > If I start the kernel with "console=ttyS0,115200", it doesn't try to
> bind
> > > to the udlfb driver, but if I start it without this flag, it does and
> > > crashes :-(
> >
> > Your frame buffer driver should offload tasks that may sleep to e.g. a
> > workqueue.
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
>
> I can try to do this - but - taking a spinlock and copying 8MB framebuffer
> would damage scheduling latency even for PCI framebuffer drivers.
>
> Mikulas
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[David Airlie]

> 
> No.
> 
> IMO Not fixing this immediately through stable is out of the question.
> The deal is that we don't break userspace.
> Having said that, I'm not against a long term vmwgfx-only solution. But
> let's fix this now.
> 
> Admittedly we missed testing this but you got to understand that not all
> developer teams have a multitude of
> developers (we have on average one for the whole linux graphics driver
> stack except GL), and the bug
> doesn't show up for QE on regression testing unless they run
> gnome-sheel/Wayland which they currently don't, and I guess they've been
> focused on the fb2 regression.
> 
> It's no secret that we've been using the control nodes for some time.
> The CONTROL_ALLOW is present in the
> driver private ioctls and the commit has been there since 2016.
> 
> The user-space code has been present in vmware-tools also since that
> commit and due to the long release cycles of
> open-vm-tools the open-vm-tools version was just about to be released.
> It's necessary for non-xorg

can you send a revert against drm-next? I'm not sure how clean it will be.

there might be an intermediate step.

Then can we port vmtools of this behaviour, not even sure what it is doing.

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

Linux 4.8-rc1 Cirrus QEMU crashes on boot.

[David Airlie]

- Original Message -
> From: "Linus Torvalds" 
> To: "Eric W. Biederman" , "Boris Brezillon" 
> , "Daniel
> Vetter" 
> Cc: "Linux Kernel Mailing List" , "Dave 
> Airlie" , "David Airlie"
> , "DRI" 
> Sent: Tuesday, 9 August, 2016 7:19:23 AM
> Subject: Re: Linux 4.8-rc1 Cirrus QEMU crashes on boot.
> 
> On Mon, Aug 8, 2016 at 1:24 PM, Eric W. Biederman 
> wrote:
> >
> > Booting up v4.8-rc1 in qemu today I ran I ran into this beautiful oops.
> >
> > I am just about to head out the door on vacation until the end of the
> > month so hopefully I am tossing out enough information to the right
> > people.
> >
> > I have confirmed that disabling CONFIG_DRM_CIRRUS_QEMU avoids this
> > crash.
> >
> > [0.720167] BUG: unable to handle kernel NULL pointer dereference at
> > 0018
> > [0.721348] IP: [] drm_pick_crtcs+0xfc/0x270
> > [0.722249] PGD 0
> > [0.722659] Oops:  [#1] SMP
> > [0.723141] Modules linked in:
> > [0.723643] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc1+ #116
> > [0.724602] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> > [0.725450] task: 8800bbf28000 task.stack: 8800bbf3
> > [0.726327] RIP: 0010:[]  []
> > drm_pick_crtcs+0xfc/0x270
> > [0.727648] RSP: :8800bbf33978  EFLAGS: 00010217
> > [0.728444] RAX: 8d623a20 RBX:  RCX:
> > 8800baf3f860
> > [0.729498] RDX:  RSI: 1000 RDI:
> > 8800baf3f800
> > [0.730626] RBP: 8800bbf339f8 R08:  R09:
> > 0001
> > [0.731704] R10: 0001 R11:  R12:
> > 8800bbaf3af0
> > [0.732827] R13: 8800bbaf3af8 R14:  R15:
> > 8800baf3fc00
> > [0.733863] FS:  () GS:8800bf80()
> > knlGS:
> > [0.735106] CS:  0010 DS:  ES:  CR0: 80050033
> > [0.735964] CR2: 0018 CR3: 3b219000 CR4:
> > 06f0
> > [0.737021] Stack:
> > [0.737342]  8800bbf33998 0246 8800bbaf3b18
> > 8800bbaf3b00
> > [0.738602]  1001  8800bbaf3b00
> > 8800baf3f800
> > [0.739807]  00031000 8800bbaf3b18 8800bbf339e8
> > 8800baf3fc00
> > [0.740993] Call Trace:
> > [0.741393]  [] drm_setup_crtcs+0x3bd/0xb50
> > [0.742252]  [] ? mark_held_locks+0x71/0x90
> > [0.743176]  [] ? __mutex_unlock_slowpath+0xeb/0x1c0
> > [0.744138]  []
> > drm_fb_helper_initial_config+0x81/0x3c0
> > [0.745166]  [] ? drm_modeset_unlock_all+0x54/0x80
> > [0.746136]  [] cirrus_fbdev_init+0xa0/0xb0
> > [0.747033]  [] cirrus_modeset_init+0x18b/0x1e0
> > .. snip snip ..
> > [0.771023] Code: e8 ba e1 ff ff 48 8b 55 b8 48 83 f8 01 83 5d c4 ff 48
> > 8b 7d b8 48 8b 82 98 02 00 00 49 8b 57 08 48 8b 40 10 48 8b 92 00 0a 00 00
> > <48> 83 7a 18 00 74 09 48 85 c0 0f 84 53 01 00 00 ff d0 49 89 c3
> 
> This decodes to
> 
>0: e8 ba e1 ff ff   callq  ...
>5: 48 8b 55 b8   mov-0x48(%rbp),%rdx
>9: 48 83 f8 01   cmp$0x1,%rax
>d: 83 5d c4 ff   sbbl   $0x,-0x3c(%rbp)
>   11: 48 8b 7d b8   mov-0x48(%rbp),%rdi
>   15: 48 8b 82 98 02 00 00 mov0x298(%rdx),%rax
>   1c: 49 8b 57 08   mov0x8(%r15),%rdx
>   20: 48 8b 40 10   mov0x10(%rax),%rax
>   24: 48 8b 92 00 0a 00 00 mov0xa00(%rdx),%rdx
>   2b:* 48 83 7a 18 00   cmpq   $0x0,0x18(%rdx) <-- trapping instruction
>   30: 74 09 je 0x3b
>   32: 48 85 c0 test   %rax,%rax
>   35: 0f 84 53 01 00 00 je 0x18e
>   3b: ff d0 callq  *%rax
>   3d: 49 89 c3 mov%rax,%r11
> 
> 
> and trying to find matching code I think the oops is from this:
> 
> if (fb_helper->dev->mode_config.funcs->atomic_commit &&
> !connector_funcs->best_encoder)
> encoder = drm_atomic_helper_best_encoder(connector);
> else
> encoder = connector_funcs->best_encoder(connector);
> 
> in particular, the trapping instruction is the load of "atomic_commit".
> 
> (The "callq *%rax" seems to be the "connector_funcs->best_encoder()" call)
> 
> So I *think* we have "fb_helper->dev->mode_config.funcs" being NULL.
> 
> 

[GIT PULL] drm/arcpgu: use dedicated memory area for frame buffer

[David Airlie]

- Original Message -
> From: "Alexey Brodkin" 
> To: airlied at redhat.com, daniel at ffwll.ch, "Vineet Gupta"  at synopsys.com>, airlied at linux.ie
> Cc: dri-devel at lists.freedesktop.org, linux-kernel at vger.kernel.org, 
> linux-snps-arc at lists.infradead.org
> Sent: Monday, 23 May, 2016 8:31:41 PM
> Subject: Re: [GIT PULL] drm/arcpgu: use dedicated memory area for frame buffer
> 
> Hi Dave,
> 
> On Mon, 2016-05-16 at 08:22 +, Alexey Brodkin wrote:
> > Hi Dave,
> > 
> > On Tue, 2016-05-10 at 09:51 +, Alexey Brodkin wrote:
> > > 
> > > Hi Dave,
> > > 
> > > On Fri, 2016-04-29 at 11:36 +, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Dave,
> > > > 
> > > > Please pull this mini-series that allows ARC PGU to use
> > > > dedicated memory location as framebuffer backing storage.
> > > > 
> > > > v2 of that series was reviewed here
> > > > https://lists.freedesktop.org/archives/dri-devel/2016-April/106279.html
> > > > 
> > > > It is based on top of today's drm-next branch.
> > > > 
> > > > Best regards,
> > > > Alexey
> > > > 
> > > > The following changes since commit
> > > > b89359bdf0f1e95a4c5f92300594ba9dde323fc4:
> > > > 
> > > >   Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu
> > > >   into drm-next (2016-04-29 14:57:51 +1000)
> > > > 
> > > > are available in the git repository at:
> > > > 
> > > >   https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git
> > > >   topic-arcpgu-updates
> > > > 
> > > > for you to fetch changes up to
> > > > cb2ad5e5339c5122166265cea579cc6a356d46de:
> > > > 
> > > >   ARC: [axs10x] Specify reserved memory for frame buffer (2016-04-29
> > > >   14:34:13 +0300)
> > > > 
> > > > 
> > > > Alexey Brodkin (2):
> > > >       drm/arcpgu: use dedicated memory area for frame buffer
> > > >       ARC: [axs10x] Specify reserved memory for frame buffer
> > > > 
> > > >  arch/arc/boot/dts/axc001.dtsi     | 22 --
> > > >  arch/arc/boot/dts/axc003.dtsi     | 14 ++
> > > >  arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
> > > >  arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
> > > >  drivers/gpu/drm/arc/arcpgu_drv.c  |  6 ++
> > > >  5 files changed, 55 insertions(+), 3 deletions(-)
> > > Could you please take a look at this pull request?
> > Another polite reminder.
> 
> Could you please pull this one?
> Indeed it was created quite some time ago so if required I may
> rebase it on top of whatever current you'd like.
> 
> Alternatively you may just apply the first patch from the series
> (could be found here
>  https://lists.freedesktop.org/archives/dri-devel/2016-April/106280.html)
> and the second patch will be picked up by ARC maintainer (Vineet Gupta).

I thought I did pull this, please check drm-next.


Dave.

VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs

[David Airlie]

- Original Message -
> From: "Saket Sinha" 
> To: dri-devel at lists.freedesktop.org, kvm at vger.kernel.org, qemu-devel at 
> nongnu.org
> Cc: "Dave Airlie" 
> Sent: Monday, 15 February, 2016 12:34:18 PM
> Subject: VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs
> 
> Hi,
> 
> It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained
> virtualized support for 3D/OpenGL hardware acceleration in VMs,
> allowing using the GPU of the host in VMs.
> 
> As per my understanding the following components are needed -
> 
> - Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D
> acceleration (needed in the VM).
> - Qemu 2.5  includes the VirtIO-GPU 3D mode support.

In qemu 2.5 only gtk3 frontend support 3D and must be enabled with gl=on

> - Gallium3D VirGL driver is included in Mesa git (needed in the VM,
> supports up to OpenGL 3.3 atm).
> - On the host *any* OpenGL driver (for the host GPU obviously), no
> special requirements there.
> 
> In order to do test this, if I can be guided as to what are the right
> applications to test the entire Graphic stack on a QEMU-KVM Virtual
> machine, I shall be grateful.

glxinfo in the guest should print virgl in the renderer string, that is enough
to know the stack is functioning.

if it shows llvmpipe it isn't.

Dave.

Regression on Chromebook Pixel 2015 due to i915 fastboot always-on

[David Airlie]

- Original Message -
> From: "Linus Torvalds" 
> To: "Jani Nikula" 
> Cc: "Daniel Vetter" , "Olof Johansson"  lixom.net>, "Maarten Lankhorst"
> , "Dave Airlie"  redhat.com>, "Duncan Laurie" ,
> "dri-devel" , "Linux Kernel Mailing List" 
> 
> Sent: Thursday, 19 November, 2015 2:18:50 AM
> Subject: Re: Regression on Chromebook Pixel 2015 due to i915 fastboot 
> always-on
> 
> On Wed, Nov 18, 2015 at 12:29 AM, Jani Nikula
>  wrote:
> > On Tue, 17 Nov 2015, Daniel Vetter  wrote:
> >>
> >> Imo revert. With all the QA awol fail we've suffered the past few
> >> months we've become a bit too lax imo with reverting fast, and the
> >> point of the split-out commit was to allow exactly that.
> >
> > Based on the logs from Olof, looks like a modeset would be required to
> > enable backlight, instead of just cranking up the brightness. So agreed
> > on the revert.
> 
> Should I just do the revert myself in my tree, or will I get it
> through the drm tree?

I'm assuming I'll get a pull request from Jani by the end of the week, and I'll
pass it on to you as per normal, but it might be good if he could accelerate 
that.

Dave.

[PATCH v3 0/4] Add virtio gpu driver.

[David Airlie]

- Original Message -
> From: "Michael S. Tsirkin" 
> To: "Gerd Hoffmann" 
> Cc: "Dave Airlie" , "Dave Airlie"  redhat.com>, "dri-devel"
> 
> Sent: Tuesday, 2 June, 2015 6:57:33 PM
> Subject: Re: [PATCH v3 0/4] Add virtio gpu driver.
> 
> On Tue, Jun 02, 2015 at 10:48:27AM +0200, Gerd Hoffmann wrote:
> > On Di, 2015-06-02 at 17:27 +1000, Dave Airlie wrote:
> > > On 1 June 2015 at 17:26, Gerd Hoffmann  wrote:
> > > >   Hi,
> > > >
> > > >> This looks reasonable to me.
> > > >> Would you be willing to be listed in
> > > >> MAINTAINERS and review patches for this driver?
> > > >
> > > > Yes, that is fine.
> > > 
> > > Can you send me a git pull request with this all in it, based on
> > > drm-next?
> > > 
> > > I'd really like to have the qemu code landed as close as possible so
> > > we don't get
> > > any digressions on review in qemu land.
> > > 
> > > Dave.
> > 
> > Busy preparing & running some final tests, pull req should go out no
> > later than tomorrow.  Will add an patch with an MAINTAINERS entry too.
> > Do you want be added there?  If so, which email address?

Yes add me airlied at linux.ie, and add the L lines for dri-devel and
virtualisation lists (as mst suggested).

Dave.

[PATCH] drm/dp-mst: Remove branches before dropping the reference

[David Airlie]

> On 8 December 2014 at 22:55, Daniel Vetter  wrote:
> > When we unplug a dp mst branch we unreference the entire tree from
> > the root towards the leaves. Which is ok, since that's the way the
> > pointers and so also the refcounts go.
> >
> > But when we drop the reference we must make sure that we remove the
> > branches/ports from the lists/pointers before dropping the reference.
> > Otherwise the get_validated functions will still return it instead
> > of returning NULL (which indicates a potentially on-going unplug).
> >
> > The mst branch destroy gets this right for ports: First it deletes
> > the port from the ports list, then it unrefs. But the ports destroy
> > function gets it wrong: First it unrefs, then it drops the ref. Which
> > means a zombie mst branch can still be validate with get_validated_mstb_ref
> > when it shouldn't.
> >
> > Fix this.
> >
> > This should address a backtrace Dave dug out somewhere on unplug:
> >
> >  [] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0
> >  [drm_kms_helper]
> >  [] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0
> >  [drm_kms_helper]
> >  [] drm_dp_get_validated_mstb_ref+0x3a/0x60
> >  [drm_kms_helper]
> >  [] drm_dp_payload_send_msg.isra.14+0x2b/0x100
> >  [drm_kms_helper]
> >  [] drm_dp_update_payload_part1+0x177/0x360
> >  [drm_kms_helper]
> >  [] intel_mst_disable_dp+0x3e/0x80 [i915]
> >  [] haswell_crtc_disable+0x1cb/0x340 [i915]
> >  [] intel_crtc_control+0x49/0x100 [i915]
> >  [] intel_crtc_update_dpms+0x67/0x80 [i915]
> >  [] intel_connector_dpms+0x59/0x70 [i915]
> >  [] intel_dp_destroy_mst_connector+0x32/0xc0 [i915]
> >  [] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper]
> >  [] drm_dp_destroy_mst_branch_device+0x108/0x130
> >  [drm_kms_helper]
> >  [] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper]
> >  [] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper]
> >  [] ? trace_hardirqs_on_caller+0x15d/0x200
> >  []
> >  drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] []
> >  ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] []
> >  ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] []
> >  intel_dp_check_mst_status+0xb5/0x250 [i915] []
> >  intel_dp_hpd_pulse+0x181/0x210 [i915] []
> >  i915_digport_work_func+0x96/0x120 [i915]
> >
> > Cc: Dave Airlie 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 5682d7e9f1ec..71a56d65a0d2 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -839,6 +839,8 @@ static void drm_dp_put_mst_branch_device(struct
> > drm_dp_mst_branch *mstb)
> >
> >  static void drm_dp_port_teardown_pdt(struct drm_dp_mst_port *port, int
> >  old_pdt)
> >  {
> > +   struct drm_dp_mst_branch *mstb;
> > +
> > switch (old_pdt) {
> > case DP_PEER_DEVICE_DP_LEGACY_CONV:
> > case DP_PEER_DEVICE_SST_SINK:
> > @@ -846,8 +848,9 @@ static void drm_dp_port_teardown_pdt(struct
> > drm_dp_mst_port *port, int old_pdt)
> > drm_dp_mst_unregister_i2c_bus(>aux);
> > break;
> > case DP_PEER_DEVICE_MST_BRANCHING:
> > -   drm_dp_put_mst_branch_device(port->mstb);
> > +   mstb = port_mstb;
> 
> drivers/gpu/drm/drm_dp_mst_topology.c:851:10: error: ‘port_mstb’ 
> undeclared
> 
> This needs to be port->mstb. Spotted while testing this for
> https://bugs.freedesktop.org/show_bug.cgi?id=87099

The version I checked in fixed this.

Dave.

Reminder: drm/crtc-helper patch

[David Airlie]

Wierd I can't see this in my dri-devel feed,

Daniel any quick opinions?
Dave.


- Original Message -
> From: "Sergei Antonov" 
> To: "Dave Airlie" 
> Cc: "Daniel Vetter" 
> Sent: Friday, 30 May, 2014 8:12:54 PM
> Subject: Reminder: drm/crtc-helper patch
> 
> Dave,
> did you notice this [*] patch of mine? It fixes a regression
> introduced in 3.15-rc1. Can it (or an analogous code) be committed
> before 3.15 is released?
> 
> I'm not promoting my patch specifically. Any patch adding "if
> (!oops_in_progress)" before those WARN_ONs will fix the problem.
> 
> [*] http://lists.freedesktop.org/archives/dri-devel/2014-May/059315.html
> 

[3.10rc6] /proc/dri/0/vma broken on nouveau.

[David Airlie]

> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> loaded.
> (Note, no X running on that box)
> 
> Trace below shows trinity, but I can reproduce it with just cat
> /proc/dri/0/vma

How about this, lets just rip it all out.

Dave.
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-remove-vma-debug-code.patch
Type: text/x-patch
Size: 4047 bytes
Desc: not available
URL: 

Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.

[David Airlie]

 Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
 loaded.
 (Note, no X running on that box)
 
 Trace below shows trinity, but I can reproduce it with just cat
 /proc/dri/0/vma

How about this, lets just rip it all out.

Dave.From 54f9605737437272f440bbc6cc4adf805334884b Mon Sep 17 00:00:00 2001
From: Dave Airlie airl...@redhat.com
Date: Tue, 18 Jun 2013 11:38:10 +1000
Subject: [PATCH] drm: remove vma debug code

This lists vma in /proc and is both crash prone and quite possible horribly
racy. Just nuke it I don't think I've used it in years and years.

Signed-off-by: Dave Airlie airl...@redhat.com
---
 drivers/gpu/drm/drm_debugfs.c |  3 ---
 drivers/gpu/drm/drm_info.c| 54 ---
 drivers/gpu/drm/drm_proc.c|  3 ---
 include/drm/drmP.h|  4 
 4 files changed, 64 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index a05087c..595c8c1 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -48,9 +48,6 @@ static struct drm_info_list drm_debugfs_list[] = {
 	{clients, drm_clients_info, 0},
 	{bufs, drm_bufs_info, 0},
 	{gem_names, drm_gem_name_info, DRIVER_GEM},
-#if DRM_DEBUG_CODE
-	{vma, drm_vma_info, 0},
-#endif
 };
 #define DRM_DEBUGFS_ENTRIES ARRAY_SIZE(drm_debugfs_list)
 
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index d4b20ce..0d25f8d 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -222,57 +222,3 @@ int drm_gem_name_info(struct seq_file *m, void *data)
 	return 0;
 }
 
-#if DRM_DEBUG_CODE
-
-int drm_vma_info(struct seq_file *m, void *data)
-{
-	struct drm_info_node *node = (struct drm_info_node *) m-private;
-	struct drm_device *dev = node-minor-dev;
-	struct drm_vma_entry *pt;
-	struct vm_area_struct *vma;
-#if defined(__i386__)
-	unsigned int pgprot;
-#endif
-
-	mutex_lock(dev-struct_mutex);
-	seq_printf(m, vma use count: %d, high_memory = %pK, 0x%pK\n,
-		   atomic_read(dev-vma_count),
-		   high_memory, (void *)(unsigned long)virt_to_phys(high_memory));
-
-	list_for_each_entry(pt, dev-vmalist, head) {
-		vma = pt-vma;
-		if (!vma)
-			continue;
-		seq_printf(m,
-			   \n%5d 0x%pK-0x%pK %c%c%c%c%c%c 0x%08lx000,
-			   pt-pid,
-			   (void *)vma-vm_start, (void *)vma-vm_end,
-			   vma-vm_flags  VM_READ ? 'r' : '-',
-			   vma-vm_flags  VM_WRITE ? 'w' : '-',
-			   vma-vm_flags  VM_EXEC ? 'x' : '-',
-			   vma-vm_flags  VM_MAYSHARE ? 's' : 'p',
-			   vma-vm_flags  VM_LOCKED ? 'l' : '-',
-			   vma-vm_flags  VM_IO ? 'i' : '-',
-			   vma-vm_pgoff);
-
-#if defined(__i386__)
-		pgprot = pgprot_val(vma-vm_page_prot);
-		seq_printf(m,  %c%c%c%c%c%c%c%c%c,
-			   pgprot  _PAGE_PRESENT ? 'p' : '-',
-			   pgprot  _PAGE_RW ? 'w' : 'r',
-			   pgprot  _PAGE_USER ? 'u' : 's',
-			   pgprot  _PAGE_PWT ? 't' : 'b',
-			   pgprot  _PAGE_PCD ? 'u' : 'c',
-			   pgprot  _PAGE_ACCESSED ? 'a' : '-',
-			   pgprot  _PAGE_DIRTY ? 'd' : '-',
-			   pgprot  _PAGE_PSE ? 'm' : 'k',
-			   pgprot  _PAGE_GLOBAL ? 'g' : 'l');
-#endif
-		seq_printf(m, \n);
-	}
-	mutex_unlock(dev-struct_mutex);
-	return 0;
-}
-
-#endif
-
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index d7f2324..92e9abd 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -55,9 +55,6 @@ static const struct drm_info_list drm_proc_list[] = {
 	{clients, drm_clients_info, 0},
 	{bufs, drm_bufs_info, 0},
 	{gem_names, drm_gem_name_info, DRIVER_GEM},
-#if DRM_DEBUG_CODE
-	{vma, drm_vma_info, 0},
-#endif
 };
 #define DRM_PROC_ENTRIES ARRAY_SIZE(drm_proc_list)
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..849523d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1600,10 +1600,6 @@ int drm_prime_add_dma_buf(struct drm_device *dev, struct drm_gem_object *obj);
 int drm_prime_lookup_obj(struct drm_device *dev, struct dma_buf *buf,
 			 struct drm_gem_object **obj);
 
-#if DRM_DEBUG_CODE
-extern int drm_vma_info(struct seq_file *m, void *data);
-#endif
-
 /* Scatter Gather Support (drm_scatter.h) */
 extern void drm_sg_cleanup(struct drm_sg_mem * entry);
 extern int drm_sg_alloc_ioctl(struct drm_device *dev, void *data,
-- 
1.8.1.2

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

cascade panic in cirrus framebuffer mode setting

[David Airlie]

> 
> I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
> the
> kernel mode setting panic's as well.
> 
> In this example, the first one is my fault; but then cirrus framebuffer DRM
> modesetting craps out.

Yeah the fix went to stable today I think

drm: don't check modeset locks in panic handler

Dave.

Re: cascade panic in cirrus framebuffer mode setting

[David Airlie]

 
 I use KVM VM's to test kernels, and lately with 3.9.2 when my code panic's
 the
 kernel mode setting panic's as well.
 
 In this example, the first one is my fault; but then cirrus framebuffer DRM
 modesetting craps out.

Yeah the fix went to stable today I think

drm: don't check modeset locks in panic handler

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

No screens after (WW) Falling back to old probe method for modesetting

[David Airlie]

- Original Message -
> From: "Rafa? Mi?ecki" 
> To: xorg-devel at lists.x.org, "dri-devel"  lists.freedesktop.org>, "Dave Airlie" 
> Cc: "Alex Deucher" 
> Sent: Monday, 11 June, 2012 8:55:56 PM
> Subject: Re: No screens after (WW) Falling back to old probe method for 
> modesetting
> 
> 2012/6/11 Rafa? Mi?ecki :
> > I'm trying to switch from fbdev to modesetting for my AMD Southern
> > Islands VERDE card. Of course I've KMS running just fine, radeon
> > module loads and sets correct resolution, dmesg looks alright
> >
> > Unfortunately Xorg doesn't start after forcing "modesetting", AFAIU
> > the driver doesn't provide any screens/modes. It looks like this:
> > (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
> > (WW) Falling back to old probe method for modesetting
> > (II) UnloadModule: "modesetting"
> > (II) Unloading modesetting
> > (EE) Screen(s) found, but none have a usable configuration.
> >
> > Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
> > using xf86-video-modesetting from today's git. Any patch/trick to
> > debug this issue?
> 
> Attaching Xorg.0.logs

Try adding a BusID maybe, though I'm not sure how tested modesetting is with 
that old an X server.

Dave.

Re: No screens after (WW) Falling back to old probe method for modesetting

[David Airlie]

- Original Message -
 From: Rafał Miłecki zaj...@gmail.com
 To: xorg-de...@lists.x.org, dri-devel dri-devel@lists.freedesktop.org, 
 Dave Airlie airl...@redhat.com
 Cc: Alex Deucher alexdeuc...@gmail.com
 Sent: Monday, 11 June, 2012 8:55:56 PM
 Subject: Re: No screens after (WW) Falling back to old probe method for 
 modesetting
 
 2012/6/11 Rafał Miłecki zaj...@gmail.com:
  I'm trying to switch from fbdev to modesetting for my AMD Southern
  Islands VERDE card. Of course I've KMS running just fine, radeon
  module loads and sets correct resolution, dmesg looks alright
 
  Unfortunately Xorg doesn't start after forcing modesetting, AFAIU
  the driver doesn't provide any screens/modes. It looks like this:
  (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
  (WW) Falling back to old probe method for modesetting
  (II) UnloadModule: modesetting
  (II) Unloading modesetting
  (EE) Screen(s) found, but none have a usable configuration.
 
  Can you give me any tip on this? My X.Org X Server is 1.10.4, I'm
  using xf86-video-modesetting from today's git. Any patch/trick to
  debug this issue?
 
 Attaching Xorg.0.logs

Try adding a BusID maybe, though I'm not sure how tested modesetting is with 
that old an X server.

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

[PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[David Airlie]

- Original Message -
> From: "Christian K?nig" 
> To: "j glisse" 
> Cc: "Jerome Glisse" , dri-devel at 
> lists.freedesktop.org
> Sent: Thursday, 26 April, 2012 10:11:12 AM
> Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
> 
> Hi Jerome,
> 
> I totally agree that we can remove the following debugfs files, since
> everything that just prints out or modifies register informations
> doesn't belongs into the kernel driver and should be moved to
> radeontool
> instead.

In the future with secure boot we will need a better mechanism to diagnose 
things
than a userspace tool mapping pci bars, which we can't allow to happen in a 
secure
boot environment, so dropping all the files might not be a good idea unless we
provide a mechanism for radeontool to use. We can't allow userspace to 
read/write
arbitrary registers and stay secure.

Dave.

Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files

[David Airlie]

- Original Message -
 From: Christian König deathsim...@vodafone.de
 To: j glisse j.gli...@gmail.com
 Cc: Jerome Glisse jgli...@redhat.com, dri-devel@lists.freedesktop.org
 Sent: Thursday, 26 April, 2012 10:11:12 AM
 Subject: Re: [PATCH 01/24] drm/radeon: remove fence/ring/ib debugfs files
 
 Hi Jerome,
 
 I totally agree that we can remove the following debugfs files, since
 everything that just prints out or modifies register informations
 doesn't belongs into the kernel driver and should be moved to
 radeontool
 instead.

In the future with secure boot we will need a better mechanism to diagnose 
things
than a userspace tool mapping pci bars, which we can't allow to happen in a 
secure
boot environment, so dropping all the files might not be a good idea unless we
provide a mechanism for radeontool to use. We can't allow userspace to 
read/write
arbitrary registers and stay secure.

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

[Intel-gfx] [PATCH] drm/edid: Adding common CVT inferred modes when monitor allows range limited ones trough EDID.

[David Airlie]

> 
> I agree with your point, too.  When I worked on supporting these
> modes
> in X server side, I didn't pick up all such modes but only really de
> facto standard ones.  It should suffice for most demands, indeed.
> 
> Also, we don't have to add always 1600x900 or 1366x768.  Such a mode
> is necessary basically only when the laptop panel resolution isn't
> found in the mode list.  We may add it selectively, too.
> 

I'm still intrigued about what hardware exists with a panel with a native mode 
it doesn't describe.

How are we to know what the panel preferred mode is in this case?

Or is this for larger panels wanting to use smaller modes?

Still confused.

Dave.

broken nouveau dependency on power supply

[David Airlie]

> 
> Ok, not that trivial...
> 
> The problem is more like POWER_SUPPLY should be a bool, not a
> tristate.
> 
> If you think about it: you don't want things like nouveau to depend
> on a
> random subsystem like that, people will never get it. In fact,
> POWER_SUPPLY provides empty inline stubs when not enabled, so that's
> really designed to not have depends...
> 
> However that -cannot- work if POWER_SUPPLY is modular and the drivers
> who use it are not. The only fixes here that make sense I can think
> of
> that don't also involve Kconfig horrors are:
> 
>  - Ugly: in power_supply.h, use the extern variant if
> 
>   defined(CONFIG_POWER_SUPPLY) ||
>(defined(CONFIG_POWER_SUPPLY_MODULE) && defined(MODULE))
> 
> IE. use the stub if power supply is a module and what is being built
> is
> built-in. Of course that's not only ugly, it somewhat sucks from a
> user
> perspective as the subsystem now exists but can't be used by some
> drivers...
> 
>  - Better: Just make the bloody thing a bool :-) The power supply
> framework itself is small enough, just make it a boolean option and
> avoid the problem entirely. The actual power supply sub drivers can
> remain modular of course.

We can just do select POWER_SUPPLY.

Yes it reduces the option range for some stupid corner case but really I don't 
care, removing features from the kernel that a driver depends on is just 
leading to insane state combination and QA problems.

Dave.

Re: broken nouveau dependency on power supply

[David Airlie]

 
 Ok, not that trivial...
 
 The problem is more like POWER_SUPPLY should be a bool, not a
 tristate.
 
 If you think about it: you don't want things like nouveau to depend
 on a
 random subsystem like that, people will never get it. In fact,
 POWER_SUPPLY provides empty inline stubs when not enabled, so that's
 really designed to not have depends...
 
 However that -cannot- work if POWER_SUPPLY is modular and the drivers
 who use it are not. The only fixes here that make sense I can think
 of
 that don't also involve Kconfig horrors are:
 
  - Ugly: in power_supply.h, use the extern variant if
 
   defined(CONFIG_POWER_SUPPLY) ||
(defined(CONFIG_POWER_SUPPLY_MODULE)  defined(MODULE))
 
 IE. use the stub if power supply is a module and what is being built
 is
 built-in. Of course that's not only ugly, it somewhat sucks from a
 user
 perspective as the subsystem now exists but can't be used by some
 drivers...
 
  - Better: Just make the bloody thing a bool :-) The power supply
 framework itself is small enough, just make it a boolean option and
 avoid the problem entirely. The actual power supply sub drivers can
 remain modular of course.

We can just do select POWER_SUPPLY.

Yes it reduces the option range for some stupid corner case but really I don't 
care, removing features from the kernel that a driver depends on is just 
leading to insane state combination and QA problems.

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

drm-core-next vs drm-next

[David Airlie]

- Original Message -
> From: "James Simmons" 
> To: "Dave Airlie" 
> Cc: "dri-devel" 
> Sent: Thursday, 15 March, 2012 3:18:14 PM
> Subject: Re: drm-core-next vs drm-next
> 
> 
> > as a headsup, if you are basing a tree on mine, please use
> > drm-core-next not drm-next itself as a basis for your tree.
> > 
> > At the moment they've diverged as I've put the UDL kms driver into
> > drm-next but not drm-core-next as it needs an external fbdev patch
> > to
> > work.
> 
> Is this temporary?

Well its the way things are supposed to work, but I realise I haven't mentioned 
that in a while.

drm-core-next isn't going to be rebased, but drm-next sometimes has to get a 
bit messy just to ensure upstream -next can build.

Dave.

[PATCH 10/10] drm/exynos: added virtual display driver.

[David Airlie]

- Original Message -
> From: "Inki Dae" 
> To: "Dave Airlie" 
> Cc: "kyungmin park" , "sw0312 kim"  at samsung.com>,
> dri-devel at lists.freedesktop.org
> Sent: Thursday, 15 March, 2012 11:36:14 AM
> Subject: RE: [PATCH 10/10] drm/exynos: added virtual display driver.
> 
> 
> 
> > -Original Message-
> > From: Dave Airlie [mailto:airlied at gmail.com]
> > Sent: Thursday, March 15, 2012 7:44 PM
> > To: Inki Dae
> > Cc: dri-devel at lists.freedesktop.org; kyungmin.park at samsung.com;
> > sw0312.kim at samsung.com
> > Subject: Re: [PATCH 10/10] drm/exynos: added virtual display
> > driver.
> > 
> > > diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
> > > index 907daaf..1123342 100644
> > > --- a/include/drm/exynos_drm.h
> > > +++ b/include/drm/exynos_drm.h
> > > @@ -76,6 +76,22 @@ struct drm_exynos_gem_mmap {
> > > ? ? ? ?uint64_t mapped;
> > > ?};
> > >
> > > +/**
> > > + * A structure for user connection request of virtual display.
> > > + *
> > > + * @connection: indicate whether doing connetion or not by user.
> > > + * @extensions: if this value is 1 then the vidi driver would
> > > need
> > additional
> > > + * ? ? 128bytes edid data.
> > > + * @pad: just padding to be 64-bit aligned.
> > > + * @edid: the edid data pointer from user side.
> > > + */
> > > +struct drm_exynos_vidi_connection {
> > > + ? ? ? unsigned int connection;
> > > + ? ? ? unsigned int extensions;
> > > + ? ? ? unsigned int pad;
> > > + ? ? ? void *edid;
> > > +};
> > > +
> > 
> > No void * in ioctl structs use u64, also not sure why you have a
> > 32-bit pad since you probably want it padded to 64-bit.
> > 
> > Dave.
> 
> Yes, right. I wanted it to be padded to 64-bit. and edid would point
> to
> buffer containing edit data and it would be passed from user to
> kernel side
> so for this, is it right to use u64? I will change variable type to
> "void
> __user *" if your missing point. please let me know if there is any
> problem.
> 

You need to use __u64 instead of a void, since void * isn't a fixed length 
across 32/64-bit.

You'll notice this done a few places in the drm kms interfaces.

Dave.

Re: [PATCH 10/10] drm/exynos: added virtual display driver.

[David Airlie]

- Original Message -
 From: Inki Dae inki@samsung.com
 To: Dave Airlie airl...@gmail.com
 Cc: kyungmin park kyungmin.p...@samsung.com, sw0312 kim 
 sw0312@samsung.com,
 dri-devel@lists.freedesktop.org
 Sent: Thursday, 15 March, 2012 11:36:14 AM
 Subject: RE: [PATCH 10/10] drm/exynos: added virtual display driver.
 
 
 
  -Original Message-
  From: Dave Airlie [mailto:airl...@gmail.com]
  Sent: Thursday, March 15, 2012 7:44 PM
  To: Inki Dae
  Cc: dri-devel@lists.freedesktop.org; kyungmin.p...@samsung.com;
  sw0312@samsung.com
  Subject: Re: [PATCH 10/10] drm/exynos: added virtual display
  driver.
  
   diff --git a/include/drm/exynos_drm.h b/include/drm/exynos_drm.h
   index 907daaf..1123342 100644
   --- a/include/drm/exynos_drm.h
   +++ b/include/drm/exynos_drm.h
   @@ -76,6 +76,22 @@ struct drm_exynos_gem_mmap {
          uint64_t mapped;
    };
  
   +/**
   + * A structure for user connection request of virtual display.
   + *
   + * @connection: indicate whether doing connetion or not by user.
   + * @extensions: if this value is 1 then the vidi driver would
   need
  additional
   + *     128bytes edid data.
   + * @pad: just padding to be 64-bit aligned.
   + * @edid: the edid data pointer from user side.
   + */
   +struct drm_exynos_vidi_connection {
   +       unsigned int connection;
   +       unsigned int extensions;
   +       unsigned int pad;
   +       void *edid;
   +};
   +
  
  No void * in ioctl structs use u64, also not sure why you have a
  32-bit pad since you probably want it padded to 64-bit.
  
  Dave.
 
 Yes, right. I wanted it to be padded to 64-bit. and edid would point
 to
 buffer containing edit data and it would be passed from user to
 kernel side
 so for this, is it right to use u64? I will change variable type to
 void
 __user * if your missing point. please let me know if there is any
 problem.
 

You need to use __u64 instead of a void, since void * isn't a fixed length 
across 32/64-bit.

You'll notice this done a few places in the drm kms interfaces.

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

Re: drm-core-next vs drm-next

[David Airlie]

- Original Message -
 From: James Simmons jsimm...@infradead.org
 To: Dave Airlie airl...@gmail.com
 Cc: dri-devel dri-devel@lists.freedesktop.org
 Sent: Thursday, 15 March, 2012 3:18:14 PM
 Subject: Re: drm-core-next vs drm-next
 
 
  as a headsup, if you are basing a tree on mine, please use
  drm-core-next not drm-next itself as a basis for your tree.
  
  At the moment they've diverged as I've put the UDL kms driver into
  drm-next but not drm-core-next as it needs an external fbdev patch
  to
  work.
 
 Is this temporary?

Well its the way things are supposed to work, but I realise I haven't mentioned 
that in a while.

drm-core-next isn't going to be rebased, but drm-next sometimes has to get a 
bit messy just to ensure upstream -next can build.

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

[PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

[David Airlie]

- Original Message -
> From: "Linus Torvalds" 
> To: "Alan Cox" 
> Cc: dri-devel at lists.freedesktop.org
> Sent: Monday, 5 March, 2012 4:50:14 PM
> Subject: Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc
> 
> On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox 
> wrote:
> > From: Alan Cox 
> >
> > [Resending with correct address for Linus]
> 
> Should I take this directly, or is there a pending DRM pull that will
> contain this?

I've just queued it up in drm-fixes, will send it out now since nothing else
came in today.

Dave.

Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc

[David Airlie]

- Original Message -
 From: Linus Torvalds torva...@linux-foundation.org
 To: Alan Cox a...@lxorguk.ukuu.org.uk
 Cc: dri-devel@lists.freedesktop.org
 Sent: Monday, 5 March, 2012 4:50:14 PM
 Subject: Re: [PATCH] drm, gma500: Fix Cedarview boot failures in 3.3-rc
 
 On Mon, Mar 5, 2012 at 6:22 AM, Alan Cox a...@lxorguk.ukuu.org.uk
 wrote:
  From: Alan Cox a...@linux.intel.com
 
  [Resending with correct address for Linus]
 
 Should I take this directly, or is there a pending DRM pull that will
 contain this?

I've just queued it up in drm-fixes, will send it out now since nothing else
came in today.

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

[PATCH] drm/radeon/kms: give better user feedback if a VM CS fails

[David Airlie]

> ---
>  drivers/gpu/drm/radeon/radeon_cs.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
> b/drivers/gpu/drm/radeon/radeon_cs.c
> index 9b4124e..f7ee2f8 100644
> --- a/drivers/gpu/drm/radeon/radeon_cs.c
> +++ b/drivers/gpu/drm/radeon/radeon_cs.c
> @@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct
> radeon_device *rdev,
>   }
>   r = radeon_ring_ib_parse(rdev, parser->ring, parser->ib);
>   if (r) {
> + DRM_ERROR("Invalid VM CS\n");
>   return r;

Isn't this user triggerable?

Dave.

Re: [PATCH] drm/radeon/kms: give better user feedback if a VM CS fails

[David Airlie]

 ---
  drivers/gpu/drm/radeon/radeon_cs.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
 b/drivers/gpu/drm/radeon/radeon_cs.c
 index 9b4124e..f7ee2f8 100644
 --- a/drivers/gpu/drm/radeon/radeon_cs.c
 +++ b/drivers/gpu/drm/radeon/radeon_cs.c
 @@ -420,6 +420,7 @@ static int radeon_cs_ib_vm_chunk(struct
 radeon_device *rdev,
   }
   r = radeon_ring_ib_parse(rdev, parser-ring, parser-ib);
   if (r) {
 + DRM_ERROR(Invalid VM CS\n);
   return r;

Isn't this user triggerable?

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

Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes

[David Airlie]

> 
> I'm certainly absolutely in favour of creating a common EDID parser,
> and
> the DRM/KMS implementation might indeed be the most complete /
> advanced
> one, but at least back in 2010 as I was working on the sh-mobile HDMI
> driver, some functinality was still missing there, which I had to add
> to
> fbdev independently. Unless those features have been added to DRM /
> KMS
> since then you might want to use the fbdev version. See
> 
> http://thread.gmane.org/gmane.linux.ports.arm.omap/55193/focus=55337
> 
> as well as possibly some other discussions from that period
> 
> http://marc.info/?l=linux-fbdev=1=201010=4

One feature missing from the drm EDID parser doesn't mean the fbdev one is 
better in all cases.

Whoever takes over the merging process will have to check for missing bits 
anyways to avoid regressions.

> > 
> > I think we should include kernel cmdline video mode parsing here,
> > afaik
> > kms and fbdev are rather similar (won't work if they're too
> > different,
> > obviously).
> 
> This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI
> too:-) The goal was to (1) take into account driver's capabilities:
> not
> all standard HDMI modes were working properly, (2) use EDID data, (3)
> give
> the user a chance to select a specific mode. Also here a generic
> solution
> would be very welcome, without breaking existing configurations, of
> course:)

The reason the drm has a more enhanced command line parser is to allow
for multiple devices otherwise it should parse mostly the same I thought
I based the drm one directly on the fbdev one + connector specifiers.

Dave.

Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes

[David Airlie]

 
 I'm certainly absolutely in favour of creating a common EDID parser,
 and
 the DRM/KMS implementation might indeed be the most complete /
 advanced
 one, but at least back in 2010 as I was working on the sh-mobile HDMI
 driver, some functinality was still missing there, which I had to add
 to
 fbdev independently. Unless those features have been added to DRM /
 KMS
 since then you might want to use the fbdev version. See
 
 http://thread.gmane.org/gmane.linux.ports.arm.omap/55193/focus=55337
 
 as well as possibly some other discussions from that period
 
 http://marc.info/?l=linux-fbdevr=1b=201010w=4

One feature missing from the drm EDID parser doesn't mean the fbdev one is 
better in all cases.

Whoever takes over the merging process will have to check for missing bits 
anyways to avoid regressions.

  
  I think we should include kernel cmdline video mode parsing here,
  afaik
  kms and fbdev are rather similar (won't work if they're too
  different,
  obviously).
 
 This has been a pretty hot discussion topic wrt sh-mobile LCDC / HDMI
 too:-) The goal was to (1) take into account driver's capabilities:
 not
 all standard HDMI modes were working properly, (2) use EDID data, (3)
 give
 the user a chance to select a specific mode. Also here a generic
 solution
 would be very welcome, without breaking existing configurations, of
 course:)

The reason the drm has a more enhanced command line parser is to allow
for multiple devices otherwise it should parse mostly the same I thought
I based the drm one directly on the fbdev one + connector specifiers.

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

`radeontool light off` does not turn off backlight

[David Airlie]

> 
> 
> using radeontool 1.6.2-1.1 from Debian Wheezy/testing [1]
> 
> $ sudo radeontool --debug light off
> Found card 1002:9555 (3)
> Radeon found. Base control address is 7f0746826000; base
> framebuffer address is 7f0735e73000.
> reading RADEON_LVDS_GEN_CNTL (2d0) is 
> writing RADEON_LVDS_GEN_CNTL (2d0) -> 
> 
> does not turn off the backlight of the laptop monitor. This is a
> Lenovo
> G555 laptop with a ATI Radeon HD 4200 graphic device [2].
> 
> Do I need to submit a report to Freedesktop.org?s Bugzilla bug
> tracking
> system?
> 

radeontool doesn't support turning on/off backlights on newer GPUs, and I'm not 
sure I see any reason for it to do so.

It was originally in radeontool as a hack around lack of drivers.


Dave.

Re: `radeontool light off` does not turn off backlight

[David Airlie]

 
 
 using radeontool 1.6.2-1.1 from Debian Wheezy/testing [1]
 
 $ sudo radeontool --debug light off
 Found card 1002:9555 (3)
 Radeon found. Base control address is 7f0746826000; base
 framebuffer address is 7f0735e73000.
 reading RADEON_LVDS_GEN_CNTL (2d0) is 
 writing RADEON_LVDS_GEN_CNTL (2d0) - 
 
 does not turn off the backlight of the laptop monitor. This is a
 Lenovo
 G555 laptop with a ATI Radeon HD 4200 graphic device [2].
 
 Do I need to submit a report to Freedesktop.org’s Bugzilla bug
 tracking
 system?
 

radeontool doesn't support turning on/off backlights on newer GPUs, and I'm not 
sure I see any reason for it to do so.

It was originally in radeontool as a hack around lack of drivers.


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

[PATCH] drm: cleanup device registration

[David Airlie]

- Original Message -
> From: "Sascha Hauer" 
> To: "David Airlie" 
> Cc: "Inki Dae" , kernel at pengutronix.de, dri-devel 
> at lists.freedesktop.org
> Sent: Thursday, 2 February, 2012 12:34:02 PM
> Subject: Re: [PATCH] drm: cleanup device registration
> 
> On Thu, Feb 02, 2012 at 07:05:00AM -0500, David Airlie wrote:
> > - Original Message -
> > > From: "Sascha Hauer" 
> > > To: dri-devel at lists.freedesktop.org
> > > Cc: "Inki Dae" , kernel at pengutronix.de
> > > Sent: Thursday, 2 February, 2012 11:57:52 AM
> > > Subject: [PATCH] drm: cleanup device registration
> > > 
> > > The non modesetting drm drivers currently use a handcrafted pci
> > > probe
> > > function. This requires the drm core to keep a list of registered
> > > devices
> > > for each driver. This series adds a probe function for the non
> > > modesetting
> > > drivers and removes the legacy probe code. The USB and platform
> > > drivers
> > > use the devices_list aswell which is unnecessary. This is also
> > > cleaned
> > > up in this series.
> > 
> > No it can't work like this because we have conflicts between fb and
> > drm drivers, so the DRM is required to do its own
> > probe if an fb driver for a device is already loaded.
> > 
> > it can't use the PCI probe out of the box.
> 
> I see. For example the i810 also has a framebuffer driver. Do you see
> a way to fix this except writing a kms driver for all legacy devices?
> Otherwise I would leave the pci part untouched and only keep the
> platform/USB pieces which I'm admittedly more interested in.
> 

Its one of those things that would be a real pain to fix, since we can't remove
drm drivers since their interfaces are ABI. So its why its been left like it is.

It might be possible to split the PCI path up a bit so the non-kms drivers use 
it,
and we port kms ones to a newer interfaces, but I think nouveau is the only PCI 
KMS only
driver we have (maybe vmwgfx as well).

Dave.

[PATCH] drm: cleanup device registration

[David Airlie]

- Original Message -
> From: "Sascha Hauer" 
> To: dri-devel at lists.freedesktop.org
> Cc: "Inki Dae" , kernel at pengutronix.de
> Sent: Thursday, 2 February, 2012 11:57:52 AM
> Subject: [PATCH] drm: cleanup device registration
> 
> The non modesetting drm drivers currently use a handcrafted pci probe
> function. This requires the drm core to keep a list of registered
> devices
> for each driver. This series adds a probe function for the non
> modesetting
> drivers and removes the legacy probe code. The USB and platform
> drivers
> use the devices_list aswell which is unnecessary. This is also
> cleaned
> up in this series.

No it can't work like this because we have conflicts between fb and drm 
drivers, so the DRM is required to do its own
probe if an fb driver for a device is already loaded.

it can't use the PCI probe out of the box.

Dave.

Re: [PATCH] drm: cleanup device registration

[David Airlie]

- Original Message -
 From: Sascha Hauer s.ha...@pengutronix.de
 To: dri-devel@lists.freedesktop.org
 Cc: Inki Dae inki@samsung.com, ker...@pengutronix.de
 Sent: Thursday, 2 February, 2012 11:57:52 AM
 Subject: [PATCH] drm: cleanup device registration
 
 The non modesetting drm drivers currently use a handcrafted pci probe
 function. This requires the drm core to keep a list of registered
 devices
 for each driver. This series adds a probe function for the non
 modesetting
 drivers and removes the legacy probe code. The USB and platform
 drivers
 use the devices_list aswell which is unnecessary. This is also
 cleaned
 up in this series.

No it can't work like this because we have conflicts between fb and drm 
drivers, so the DRM is required to do its own
probe if an fb driver for a device is already loaded.

it can't use the PCI probe out of the box.

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

Re: [PATCH] drm: cleanup device registration

[David Airlie]

- Original Message -
 From: Sascha Hauer s.ha...@pengutronix.de
 To: David Airlie airl...@redhat.com
 Cc: Inki Dae inki@samsung.com, ker...@pengutronix.de, 
 dri-devel@lists.freedesktop.org
 Sent: Thursday, 2 February, 2012 12:34:02 PM
 Subject: Re: [PATCH] drm: cleanup device registration
 
 On Thu, Feb 02, 2012 at 07:05:00AM -0500, David Airlie wrote:
  - Original Message -
   From: Sascha Hauer s.ha...@pengutronix.de
   To: dri-devel@lists.freedesktop.org
   Cc: Inki Dae inki@samsung.com, ker...@pengutronix.de
   Sent: Thursday, 2 February, 2012 11:57:52 AM
   Subject: [PATCH] drm: cleanup device registration
   
   The non modesetting drm drivers currently use a handcrafted pci
   probe
   function. This requires the drm core to keep a list of registered
   devices
   for each driver. This series adds a probe function for the non
   modesetting
   drivers and removes the legacy probe code. The USB and platform
   drivers
   use the devices_list aswell which is unnecessary. This is also
   cleaned
   up in this series.
  
  No it can't work like this because we have conflicts between fb and
  drm drivers, so the DRM is required to do its own
  probe if an fb driver for a device is already loaded.
  
  it can't use the PCI probe out of the box.
 
 I see. For example the i810 also has a framebuffer driver. Do you see
 a way to fix this except writing a kms driver for all legacy devices?
 Otherwise I would leave the pci part untouched and only keep the
 platform/USB pieces which I'm admittedly more interested in.
 

Its one of those things that would be a real pain to fix, since we can't remove
drm drivers since their interfaces are ABI. So its why its been left like it is.

It might be possible to split the PCI path up a bit so the non-kms drivers use 
it,
and we port kms ones to a newer interfaces, but I think nouveau is the only PCI 
KMS only
driver we have (maybe vmwgfx as well).

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

[PATCH 14/20] drm: add convenience function to create an enum property

[David Airlie]

- Original Message -
> From: "Chris Wilson" 
> To: "Sascha Hauer" , dri-devel at 
> lists.freedesktop.org
> Cc: kernel at pengutronix.de
> Sent: Wednesday, 1 February, 2012 11:48:53 AM
> Subject: Re: [PATCH 14/20] drm: add convenience function to create an enum
> property
> 
> On Wed,  1 Feb 2012 11:38:32 +0100, Sascha Hauer
>  wrote:
> > Creating an enum property is a common pattern, so create
> > a convenience function for this and use it where appropriate.
> 
> Similar naming comments apply as for drm_property_create_range.
> However,
> I did spot something anomalous...
> 
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 8d593ad..cdbbb40 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -394,7 +394,7 @@ struct drm_crtc {
> > s64 framedur_ns, linedur_ns, pixeldur_ns;
> >  
> > /* if you are using the helper */
> > -   void *helper_private;
> > +   struct drm_crtc_helper_funcs *helper_private;
> >  };
> >  
> >  
> > @@ -481,7 +481,7 @@ struct drm_encoder {
> >  
> > struct drm_crtc *crtc;
> > const struct drm_encoder_funcs *funcs;
> > -   void *helper_private;
> > +   struct drm_encoder_helper_funcs *helper_private;
> >  };
> >  
> >  enum drm_connector_force {
> > @@ -573,7 +573,7 @@ struct drm_connector {
> > /* requested DPMS state */
> > int dpms;
> >  
> > -   void *helper_private;
> > +   struct drm_connector_helper_funcs *helper_private;
> >  
> > /* forced on connector */
> > enum drm_connector_force force;
> 
> This is a separate chunk.

And totally wrong, using the helper should remain optional, and the helper 
includes should not be included into the main headers.

Dave.

Re: [PATCH 14/20] drm: add convenience function to create an enum property

[David Airlie]

- Original Message -
 From: Chris Wilson ch...@chris-wilson.co.uk
 To: Sascha Hauer s.ha...@pengutronix.de, dri-devel@lists.freedesktop.org
 Cc: ker...@pengutronix.de
 Sent: Wednesday, 1 February, 2012 11:48:53 AM
 Subject: Re: [PATCH 14/20] drm: add convenience function to create an enum
 property
 
 On Wed,  1 Feb 2012 11:38:32 +0100, Sascha Hauer
 s.ha...@pengutronix.de wrote:
  Creating an enum property is a common pattern, so create
  a convenience function for this and use it where appropriate.
 
 Similar naming comments apply as for drm_property_create_range.
 However,
 I did spot something anomalous...
 
  diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
  index 8d593ad..cdbbb40 100644
  --- a/include/drm/drm_crtc.h
  +++ b/include/drm/drm_crtc.h
  @@ -394,7 +394,7 @@ struct drm_crtc {
  s64 framedur_ns, linedur_ns, pixeldur_ns;
   
  /* if you are using the helper */
  -   void *helper_private;
  +   struct drm_crtc_helper_funcs *helper_private;
   };
   
   
  @@ -481,7 +481,7 @@ struct drm_encoder {
   
  struct drm_crtc *crtc;
  const struct drm_encoder_funcs *funcs;
  -   void *helper_private;
  +   struct drm_encoder_helper_funcs *helper_private;
   };
   
   enum drm_connector_force {
  @@ -573,7 +573,7 @@ struct drm_connector {
  /* requested DPMS state */
  int dpms;
   
  -   void *helper_private;
  +   struct drm_connector_helper_funcs *helper_private;
   
  /* forced on connector */
  enum drm_connector_force force;
 
 This is a separate chunk.

And totally wrong, using the helper should remain optional, and the helper 
includes should not be included into the main headers.

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

[PATCH] drm/radeon: Add support for userspace fence waits

[David Airlie]

Some comments below.

> + struct radeon_device *rdev = dev->dev_private;
> + struct drm_gem_object *gobj;
> + struct radeon_bo *robj;
> + void *buffer_data;
> + uint32_t *fence_data;
> + int r = 0;
> + long timeout;
> + int ring = RADEON_RING_TYPE_GFX_INDEX;
> +
> + /* If you're implementing this for other rings, you'll want to
> share
> +code with radeon_cs_get_ring in radeon_cs.c */
> + if (args->ring != RADEON_CS_RING_GFX) {
> + return -EINVAL;
> + }
> +
> + gobj = drm_gem_object_lookup(dev, filp, args->handle);
> + if (gobj == NULL) {
> + return -ENOENT;
> + }
> + robj = gem_to_radeon_bo(gobj);
> +
> + if (gobj->size < args->offset) {
> + r = -EINVAL;
> + goto unreference;
> + }
> +
> + r = radeon_bo_reserve(robj, true);
> + if (r) {
> + goto unreference;
> + }
> +
> + r = radeon_bo_pin(robj, RADEON_GEM_DOMAIN_GTT, NULL);
> + if (r) {
> + goto unreserve;
> + }
> +
> + r = radeon_bo_kmap(robj, _data);
> + if (r) {
> + goto unpin;
> + }
> +


Do you need to pin it? I think if you have it reserved and you are in here you 
shouldn't need to. (unless kmapping requires a pin)/


> + radeon_irq_kms_sw_irq_get(rdev, ring);
> +
> + fence_data = (uint32_t*)buffer_data;
> + timeout =
> an
> + * interrupt and the value in the buffer might have changed.
> + */
> +struct drm_radeon_gem_wait_user_fence {
> + uint32_thandle;
> + uint32_tring;
> + uint64_toffset;
> + uint32_tvalue;
> + uint64_ttimeout_usec;

Align things here, 64 then 64 then 32 32 32 and a 32 pad.

Re: [PATCH] drm/radeon: Add support for userspace fence waits

[David Airlie]

Some comments below.

 + struct radeon_device *rdev = dev-dev_private;
 + struct drm_gem_object *gobj;
 + struct radeon_bo *robj;
 + void *buffer_data;
 + uint32_t *fence_data;
 + int r = 0;
 + long timeout;
 + int ring = RADEON_RING_TYPE_GFX_INDEX;
 +
 + /* If you're implementing this for other rings, you'll want to
 share
 +code with radeon_cs_get_ring in radeon_cs.c */
 + if (args-ring != RADEON_CS_RING_GFX) {
 + return -EINVAL;
 + }
 +
 + gobj = drm_gem_object_lookup(dev, filp, args-handle);
 + if (gobj == NULL) {
 + return -ENOENT;
 + }
 + robj = gem_to_radeon_bo(gobj);
 +
 + if (gobj-size  args-offset) {
 + r = -EINVAL;
 + goto unreference;
 + }
 +
 + r = radeon_bo_reserve(robj, true);
 + if (r) {
 + goto unreference;
 + }
 +
 + r = radeon_bo_pin(robj, RADEON_GEM_DOMAIN_GTT, NULL);
 + if (r) {
 + goto unreserve;
 + }
 +
 + r = radeon_bo_kmap(robj, buffer_data);
 + if (r) {
 + goto unpin;
 + }
 +


Do you need to pin it? I think if you have it reserved and you are in here you 
shouldn't need to. (unless kmapping requires a pin)/


 + radeon_irq_kms_sw_irq_get(rdev, ring);
 +
 + fence_data = (uint32_t*)buffer_data;
 + timeout =
 an
 + * interrupt and the value in the buffer might have changed.
 + */
 +struct drm_radeon_gem_wait_user_fence {
 + uint32_thandle;
 + uint32_tring;
 + uint64_toffset;
 + uint32_tvalue;
 + uint64_ttimeout_usec;

Align things here, 64 then 64 then 32 32 32 and a 32 pad.

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

[GIT PULL] drm/exynos: update exynos drm driver.

[David Airlie]

- Original Message -
> From: "Inki Dae" 
> To: airlied at linux.ie, dri-devel at lists.freedesktop.org
> Cc: "Inki Dae" , "kyungmin park"  samsung.com>, "sw0312 kim"
> 
> Sent: Wednesday, 21 December, 2011 6:22:16 AM
> Subject: [GIT PULL] drm/exynos: update exynos drm driver.
> 
> Hi, Dave.
> 
> Please pull from
>   git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

Pulled into drm-next.

Dave.

[PATCH RESEND] vmwgfx: fix incorrect vram size check in vmw_kms_fb_create()

[David Airlie]

- Original Message -
> From: "Xi Wang" 
> To: "Jakob Bornecrantz" , "Thomas Hellstrom"  at vmware.com>
> Cc: dri-devel at lists.freedesktop.org, "Dave Airlie" 
> Sent: Tuesday, 20 December, 2011 9:08:32 PM
> Subject: [PATCH RESEND] vmwgfx: fix incorrect vram size check in 
> vmw_kms_fb_create()

This patch doesn't apply with git am, please regenerate it,

Thomas, can you ack as well please?

Is this for -fixes or -next?

Dave.

Re: [PATCH RESEND] vmwgfx: fix incorrect vram size check in vmw_kms_fb_create()

[David Airlie]

- Original Message -
 From: Xi Wang xi.w...@gmail.com
 To: Jakob Bornecrantz ja...@vmware.com, Thomas Hellstrom 
 thellst...@vmware.com
 Cc: dri-devel@lists.freedesktop.org, Dave Airlie airl...@redhat.com
 Sent: Tuesday, 20 December, 2011 9:08:32 PM
 Subject: [PATCH RESEND] vmwgfx: fix incorrect vram size check in 
 vmw_kms_fb_create()

This patch doesn't apply with git am, please regenerate it,

Thomas, can you ack as well please?

Is this for -fixes or -next?

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

Re: [GIT PULL] drm/exynos: update exynos drm driver.

[David Airlie]

- Original Message -
 From: Inki Dae inki@samsung.com
 To: airl...@linux.ie, dri-devel@lists.freedesktop.org
 Cc: Inki Dae inki@samsung.com, kyungmin park 
 kyungmin.p...@samsung.com, sw0312 kim
 sw0312@samsung.com
 Sent: Wednesday, 21 December, 2011 6:22:16 AM
 Subject: [GIT PULL] drm/exynos: update exynos drm driver.
 
 Hi, Dave.
 
 Please pull from
   git://git.infradead.org/users/kmpark/linux-samsung exynos-drm-next

Pulled into drm-next.

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

Rebased drm_plane patches

[David Airlie]

- Original Message -
> From: "ville syrjala" 
> To: dri-devel at lists.freedesktop.org
> Sent: Monday, 19 December, 2011 10:06:37 PM
> Subject: Rebased drm_plane patches
> 
> I rebased this set on top of drm-next.
> 
> I updated some of the error values based on what Jesse suggested.
> 
> I also added a few patches to fix various issues that came up
> since I last posted the patches.
> 
> Since the patch to drop the planar formats with YVU plane order
> wasn't
> applied to drm-next, I check those too in patch 11/12.

Applied these 12 to drm-next all looked fine to me.

Dave.

Re: Rebased drm_plane patches

[David Airlie]

- Original Message -
 From: ville syrjala ville.syrj...@linux.intel.com
 To: dri-devel@lists.freedesktop.org
 Sent: Monday, 19 December, 2011 10:06:37 PM
 Subject: Rebased drm_plane patches
 
 I rebased this set on top of drm-next.
 
 I updated some of the error values based on what Jesse suggested.
 
 I also added a few patches to fix various issues that came up
 since I last posted the patches.
 
 Since the patch to drop the planar formats with YVU plane order
 wasn't
 applied to drm-next, I check those too in patch 11/12.

Applied these 12 to drm-next all looked fine to me.

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

DVI/VGA/HDI mess on Radeon HD 6570

[David Airlie]

> 
> about two months ago I bought a Radeon HD 6570 with
> 2GB memory for my main computer and I have a single
> monitor connected to it, until now via VGA D-Sub.
> 
> Last week our secondary TV died (it was 15 years old, R.I.P.)
> so I bought a nice 32" LED TV which has 3 external HDMI
> connectors.
> 
> The HD 6570 has one DVI-D, one HDMI and one VGA connectors
> so I thought it would be fun to allow the family to watch videos
> while I can also work on the computer.
> 
> Here comes my problem: no matter which connectors I use
> for the monitor (DVI-D or D-Sub), if the TV is switched on,
> HDMI comes up as primary display. The result: GNOME 3
> workspaces are switchable on the TV but a single workspace
> is visible on my monitor. This would be the perfect setup
> if I can reverse the roles of the TV and the monitor.
> 
> "man radeon" had an option which I tried but didn't help:
> Option "ZaphodHeads" "DVI-0,HDMI-0"

xrandr --output DVI-0 --primary

or open the gnome display applet and drag the bar from one monitor to another.

Dave.

Re: DVI/VGA/HDI mess on Radeon HD 6570

[David Airlie]

 
 about two months ago I bought a Radeon HD 6570 with
 2GB memory for my main computer and I have a single
 monitor connected to it, until now via VGA D-Sub.
 
 Last week our secondary TV died (it was 15 years old, R.I.P.)
 so I bought a nice 32 LED TV which has 3 external HDMI
 connectors.
 
 The HD 6570 has one DVI-D, one HDMI and one VGA connectors
 so I thought it would be fun to allow the family to watch videos
 while I can also work on the computer.
 
 Here comes my problem: no matter which connectors I use
 for the monitor (DVI-D or D-Sub), if the TV is switched on,
 HDMI comes up as primary display. The result: GNOME 3
 workspaces are switchable on the TV but a single workspace
 is visible on my monitor. This would be the perfect setup
 if I can reverse the roles of the TV and the monitor.
 
 man radeon had an option which I tried but didn't help:
 Option ZaphodHeads DVI-0,HDMI-0

xrandr --output DVI-0 --primary

or open the gnome display applet and drag the bar from one monitor to another.

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

[PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()

[David Airlie]

- Original Message -
> From: "Eugene Teo" 
> To: "Xi Wang" 
> Cc: "David Airlie" , dri-devel at lists.freedesktop.org, 
> linux-kernel at vger.kernel.org,
> security at kernel.org, "Dave Airlie" 
> Sent: Wednesday, 14 December, 2011 1:16:49 PM
> Subject: Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
> 
> Cc'ed Dave's work email.

This is already in Linus tree, went there a while ago.

a5cd335165e31db9dbab636fd29895d41da55dd2

Dave.

Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()

[David Airlie]

- Original Message -
 From: Eugene Teo eugene...@kernel.sg
 To: Xi Wang xi.w...@gmail.com
 Cc: David Airlie airl...@linux.ie, dri-devel@lists.freedesktop.org, 
 linux-ker...@vger.kernel.org,
 secur...@kernel.org, Dave Airlie airl...@redhat.com
 Sent: Wednesday, 14 December, 2011 1:16:49 PM
 Subject: Re: [PATCH] drm: integer overflow in drm_mode_dirtyfb_ioctl()
 
 Cc'ed Dave's work email.

This is already in Linus tree, went there a while ago.

a5cd335165e31db9dbab636fd29895d41da55dd2

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

[patch] drm/ttm: fix condition (and vs or)

[David Airlie]

- Original Message -
> From: "Konrad Rzeszutek Wilk" 
> To: "Jerome Glisse" 
> Cc: dri-devel at lists.freedesktop.org, "Jerome Glisse"  redhat.com>, kernel-janitors at vger.kernel.org, "Thomas
> Hellstrom" , "Dan Carpenter"  oracle.com>
> Sent: Thursday, 8 December, 2011 4:53:34 PM
> Subject: Re: [patch] drm/ttm: fix condition (and vs or)
> 
> On Thu, Dec 08, 2011 at 10:34:00AM -0500, Jerome Glisse wrote:
> > On Thu, Dec 08, 2011 at 09:50:54AM +0300, Dan Carpenter wrote:
> > > The "if (!p && !p->dev)" condition isn't right because || was
> > > intended
> > > instead of &&.  But actually, "p" is the list cursor and so it's
> > > always
> 
> Duh!
> > > non-NULL and we can just remove that bit.  We can remove the
> > > another
> > > similar check as well.
> > > 
> > > Signed-off-by: Dan Carpenter 
> > Reviewed-by: Jerome Glisse 
> 
> And Acked-by me.
> 
> Jerome, since you have the patches (And are thinking to send a GIT
> PULL
> to Dave) in your tree, could you include this patch in your queue?
> 

I've taken the TTM changes into drm-next already, just reviewing the radeon 
stuff.

But if that appeared on top in Jerome's tree I can steal it.

Dave.

Re: [patch] drm/ttm: fix condition (and vs or)

[David Airlie]

- Original Message -
 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 To: Jerome Glisse j.gli...@gmail.com
 Cc: dri-devel@lists.freedesktop.org, Jerome Glisse jgli...@redhat.com, 
 kernel-janit...@vger.kernel.org, Thomas
 Hellstrom thellst...@vmware.com, Dan Carpenter dan.carpen...@oracle.com
 Sent: Thursday, 8 December, 2011 4:53:34 PM
 Subject: Re: [patch] drm/ttm: fix condition (and vs or)
 
 On Thu, Dec 08, 2011 at 10:34:00AM -0500, Jerome Glisse wrote:
  On Thu, Dec 08, 2011 at 09:50:54AM +0300, Dan Carpenter wrote:
   The if (!p  !p-dev) condition isn't right because || was
   intended
   instead of .  But actually, p is the list cursor and so it's
   always
 
 Duh!
   non-NULL and we can just remove that bit.  We can remove the
   another
   similar check as well.
   
   Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
  Reviewed-by: Jerome Glisse jgli...@redhat.com
 
 And Acked-by me.
 
 Jerome, since you have the patches (And are thinking to send a GIT
 PULL
 to Dave) in your tree, could you include this patch in your queue?
 

I've taken the TTM changes into drm-next already, just reviewing the radeon 
stuff.

But if that appeared on top in Jerome's tree I can steal it.

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

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7

[David Airlie]

- Original Message -
> From: "Konrad Rzeszutek Wilk" 
> To: "Jerome Glisse" , dri-devel at 
> lists.freedesktop.org, "konrad wilk" ,
> thellstrom at vmware.com, airlied at gmail.com, "Jerome Glisse"  redhat.com>
> Sent: Friday, 2 December, 2011 2:19:01 PM
> Subject: Re: ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V7
> 
> On Fri, Nov 18, 2011 at 08:08:36PM -0500, Jerome Glisse wrote:
> > On Fri, Nov 18, 2011 at 08:04:47PM -0500, j.glisse at gmail.com
> > wrote:
> > > Important fix to patch 14, fix accounting of ghost bo. When
> > > creating a
> > > ghost bo we don't account it, so set its acc_size to 0 so that
> > > when
> > > ghost is release we don't overfree.
> > > 
> > > I wonder how i didn't run into this before.
> > > 
> > > Patch are also at
> > > 
> > > http://people.freedesktop.org/~glisse/ttmdma/
> > > 
> > > Cheers,
> > > Jerome
> > > 
> > 
> > Oh i forgot to add some of the reviewed by, i updated patches on
> > fdo,
> > i don't resend to the ml.
> 
> Great! How should we ask Dave to pull them? Does he prefer to do it
> via git
> tree? In which I can create a branch with those patches and send him
> a GIT PULL
> email? Or is there a more convient way?

If someone could suck them all into a git tree + all the Reviewed-by tags from 
the people who reviewed them it would make it a lot easier,

I lost track of where this ended up as Jerome had a few balls in the air and I 
know Thomas wasn't liking some of them.

So please send me a git url and I'll go review that next week.

Dave.

[RFC] Virtual CRTCs (proposal + experimental code)

[David Airlie]

> 
> Hi everyone,
> 
> I would like to bring to the attention of dri-devel and linux-fbdev
> community a set of hopefully useful and interesting patches that
> I (and a few other colleagues) have been working on during the past
> few months. Here, I will provide a short abstract, so that you can
> decide whether this is of interest for you. At the end, I will
> provide the pointers to the code and documentation.
> 
> The code is based on Dave Arilie's tree, drm-next branch and it
> allows a GPU driver to have an arbitrary number of CRTCs
> (configurable by user) instead of only those CRTCs that represent
> real hardware.

Well the current plan I had for this was to do it in userspace, I don't think 
the kernel
has any business doing it and I think for the simple USB case its fine but will 
fallover
when you get to the non-trivial cases where some sort of acceleration is 
required to move
pixels around. But in saying that its good you've done what something, and I'll 
try and spend
some time reviewing it.

The current plan from my POV is to add hotplug support to the X server and just 
hotplug USB
devices up there, and not mess up the kernel with lots of extra state that 
really the drivers
don't need to know about.

I'm also not sure how you deal with tiling etc, you can also start hitting 
rendering limits,
where a GPU can render to 4kx4k but you can plug in more USB devices, again I'm 
hoping to
solve this in userspace as well.

But I'll take some time if I can find it to look over it.

Dave.

Re: [RFC] Virtual CRTCs (proposal + experimental code)

[David Airlie]

 
 Hi everyone,
 
 I would like to bring to the attention of dri-devel and linux-fbdev
 community a set of hopefully useful and interesting patches that
 I (and a few other colleagues) have been working on during the past
 few months. Here, I will provide a short abstract, so that you can
 decide whether this is of interest for you. At the end, I will
 provide the pointers to the code and documentation.
 
 The code is based on Dave Arilie's tree, drm-next branch and it
 allows a GPU driver to have an arbitrary number of CRTCs
 (configurable by user) instead of only those CRTCs that represent
 real hardware.

Well the current plan I had for this was to do it in userspace, I don't think 
the kernel
has any business doing it and I think for the simple USB case its fine but will 
fallover
when you get to the non-trivial cases where some sort of acceleration is 
required to move
pixels around. But in saying that its good you've done what something, and I'll 
try and spend
some time reviewing it.

The current plan from my POV is to add hotplug support to the X server and just 
hotplug USB
devices up there, and not mess up the kernel with lots of extra state that 
really the drivers
don't need to know about.

I'm also not sure how you deal with tiling etc, you can also start hitting 
rendering limits,
where a GPU can render to 4kx4k but you can plug in more USB devices, again I'm 
hoping to
solve this in userspace as well.

But I'll take some time if I can find it to look over it.

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

[PATCH 01/12] RADEON: Drop inlines from evergreen_cs.c / r600_cs.c

[David Airlie]

> 
> From: Andi Kleen 

Hi Andi,

I've merged all the RADEON: patches to drm-next locally, with one minor change 
(moving some of the out-of-lines to a more appropriate place).

Thanks,
Dave.

Re: [PATCH 01/12] RADEON: Drop inlines from evergreen_cs.c / r600_cs.c

[David Airlie]

 
 From: Andi Kleen a...@linux.intel.com

Hi Andi,

I've merged all the RADEON: patches to drm-next locally, with one minor change 
(moving some of the out-of-lines to a more appropriate place).

Thanks,
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply: Question on S3 on evergreen

[David Airlie]

- Original Message -
> From: "FrankR Huang" 
> To: "Xavier Bestel" , "Dave Airlie"  gmail.com>
> Cc: dri-devel at lists.freedesktop.org
> Sent: Thursday, 13 October, 2011 3:16:07 PM
> Subject: Reply: Question on S3 on evergreen
> 
> 
> Reply: Question on S3 on evergreen
> 
> Xav, thanks for your reminder. Actually our law leam has already
> checked the license. As Dave said, the DRM kernel driver is all
> MIT-licensed and we will be free to use them. When the drm uses
> linux kernel function calls, we will use freebsd(none-GPL)
> equivalent to replace.
> Dave, by the way, I want to ask you about some exceptions in DRM. you
> know in some files(i.e. drm_fb_helper.c), it includes
> MODULE_LICENSE("GPL and additional rights"). Does it mean it is GPL
> licensed? Is it free to use this file?

Those files are derived from the kernel fb layer so are not drm core 
infrastructure.

They make no sense on other OSes, since they don't have the same kernel fb 
layer.

Dave.

Re: Reply: Question on S3 on evergreen

[David Airlie]

- Original Message -
 From: FrankR Huang frankr.hu...@amd.com
 To: Xavier Bestel xavier.bes...@free.fr, Dave Airlie airl...@gmail.com
 Cc: dri-devel@lists.freedesktop.org
 Sent: Thursday, 13 October, 2011 3:16:07 PM
 Subject: Reply: Question on S3 on evergreen
 
 
 Reply: Question on S3 on evergreen
 
 Xav, thanks for your reminder. Actually our law leam has already
 checked the license. As Dave said, the DRM kernel driver is all
 MIT-licensed and we will be free to use them. When the drm uses
 linux kernel function calls, we will use freebsd(none-GPL)
 equivalent to replace.
 Dave, by the way, I want to ask you about some exceptions in DRM. you
 know in some files(i.e. drm_fb_helper.c), it includes
 MODULE_LICENSE(GPL and additional rights). Does it mean it is GPL
 licensed? Is it free to use this file?

Those files are derived from the kernel fb layer so are not drm core 
infrastructure.

They make no sense on other OSes, since they don't have the same kernel fb 
layer.

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

[PATCH] drm: fix messages about failed procfs/debugfs file registration

[David Airlie]

- Original Message -
> From: "Dave Airlie" 
> To: "Marcin Slusarz" 
> Cc: "Daniel Yek" , dri-devel at 
> lists.freedesktop.org
> Sent: Monday, 10 October, 2011 9:00:19 AM
> Subject: Re: [PATCH] drm: fix messages about failed procfs/debugfs file   
> registration
> 
> On Sun, Oct 9, 2011 at 7:38 PM, Marcin Slusarz
>  wrote:
> > It printed garbage from stack:
> > [drm:drm_debugfs_create_files] *ERROR* Cannot create
> > /sys/kernel/debug/dri/!.wy/2
> >
> > Reported-by: Daniel Yek 
> > Signed-off-by: Marcin Slusarz 
> 

I have 4d5cb60d3f6c396899a515e0e667d0f855ed66cc

Typoed some vim onto the original mail.

Dave.

Re: [PATCH] drm: fix messages about failed procfs/debugfs file registration

[David Airlie]

- Original Message -
 From: Dave Airlie airl...@gmail.com
 To: Marcin Slusarz marcin.slus...@gmail.com
 Cc: Daniel Yek danie...@alumni.washington.edu, 
 dri-devel@lists.freedesktop.org
 Sent: Monday, 10 October, 2011 9:00:19 AM
 Subject: Re: [PATCH] drm: fix messages about failed procfs/debugfs file   
 registration
 
 On Sun, Oct 9, 2011 at 7:38 PM, Marcin Slusarz
 marcin.slus...@gmail.com wrote:
  It printed garbage from stack:
  [drm:drm_debugfs_create_files] *ERROR* Cannot create
  /sys/kernel/debug/dri/!.wy/2
 
  Reported-by: Daniel Yek danie...@alumni.washington.edu
  Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
 

I have 4d5cb60d3f6c396899a515e0e667d0f855ed66cc

Typoed some vim onto the original mail.

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

An inquiry about DRM Driver work for mainline.

[David Airlie]

Hi Inki,

Well it seems that so far you've only done KMS work so you don't need to worry 
as much about a userspace. When you start adding driver specific acceleration 
ioctls then we'll have to allow for making sure an open userspace exists to 
work and demonstrate the new ioctls.

Dave.

- Original Message -
> From: "Inki Dae" 
> To: airlied at linux.ie
> Cc: "kyungmin park" , dri-devel at 
> lists.freedesktop.org
> Sent: Thursday, 22 September, 2011 1:52:19 PM
> Subject: An inquiry about DRM Driver work for mainline.
> 
> Hello, Dave.
> 
> Now we are preparing Samsung SoC based DRM Driver patch v5 for
> mainline and
> it would be posted soon. I wonder that you want to open user side
> based on
> DRI2 of Xorg or just simple test application to have our driver
> accepted as
> prerequisite. If so, should we post it to libdrm or  is it enough to
> open
> independent user side repository? we would be happy you to give me
> your
> advice. if necessary then we are going to start additional work.
> thank you
> and I hope you have a great day.
> 
> Best Regards,
> Inki Dae.
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

Re: An inquiry about DRM Driver work for mainline.

[David Airlie]

Hi Inki,

Well it seems that so far you've only done KMS work so you don't need to worry 
as much about a userspace. When you start adding driver specific acceleration 
ioctls then we'll have to allow for making sure an open userspace exists to 
work and demonstrate the new ioctls.

Dave.

- Original Message -
 From: Inki Dae inki@samsung.com
 To: airl...@linux.ie
 Cc: kyungmin park kyungmin.p...@samsung.com, 
 dri-devel@lists.freedesktop.org
 Sent: Thursday, 22 September, 2011 1:52:19 PM
 Subject: An inquiry about DRM Driver work for mainline.
 
 Hello, Dave.
 
 Now we are preparing Samsung SoC based DRM Driver patch v5 for
 mainline and
 it would be posted soon. I wonder that you want to open user side
 based on
 DRI2 of Xorg or just simple test application to have our driver
 accepted as
 prerequisite. If so, should we post it to libdrm or  is it enough to
 open
 independent user side repository? we would be happy you to give me
 your
 advice. if necessary then we are going to start additional work.
 thank you
 and I hope you have a great day.
 
 Best Regards,
 Inki Dae.
 
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Kernel almost hangs when CONFIG_DRM_RADEON=y

[David Airlie]

- Original Message -
> From: "Borislav Petkov" 
> To: "Alex Deucher" , "Dave Airlie"  gmail.com>
> Cc: "Peter Zijlstra" , "Michel D?nzer"  daenzer.net>, "linux-kernel"
> , dri-devel at lists.freedesktop.org, "Pavel 
> Ivanov" 
> Sent: Monday, 29 August, 2011 3:16:12 PM
> Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
> On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
> > >> Should we make Kconfig pop up a dialog and ask for the
> > >> whereabouts of
> > >> these firmware thingies when you mark the driver =y?
> > >>
> > >> This all sounds like magic to me, having to know you need to add
> > >> to
> > >> EXTRA_FIRMWARE, having to know what file it needs etc.. For all
> > >> intents
> > >> and purposes =y just doesn't work and that's broken.
> > >
> > > Yep, you make a lot of sense. I had to fumble the build/reboot
> > > cycle a
> > > couple of times and do some code staring even to figure this out.
> > > In
> > > the end, I copied the whole radeon/ folder from David's firmware
> > > git
> > > repo into /lib/firmware and made radeon.ko =m again so that I
> > > don't have
> > > to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm
> > > building a
> > > kernel on a different machine.
> > >
> > > Besides, there was this other issue on lkml today where
> > > CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you
> > > overflow
> > > its length of 256 by trying to include a bunch of firmware *bin
> > > files:
> > > http://lkml.org/lkml/2011/8/29/86
> >
> > If you are going to build the ucode into your kernel you'll need to
> > pick the ones you want to include or increase the limit regardless
> > of
> > whether it's radeon ucode or ucode for some other chip. For a
> > particular card you only need the ones for that card (e.g.,
> > CEDAR_*.bin or REDWOOD_*.bin, etc.)
> 
> Alex, Dave, yeah, that's all fine.
> 
> The question Peter asked is, how to make this much more understandable
> to the user so that she/he doesn't have to figure it out on their own.
> IOW, if one sets RADEON to =y in Kconfig, it should automatically
> generate a selection menu with all the firmware required so that
> the user can select from it either the CEDAR* or the REDWOOD* (or
> the DOUGHNUT* :-)) ones for her/his card and when the user selects
> one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE
> _automatically_.
> 
> Maybe even Kbuild should try to find them on the system, and, if
> unable
> to, remind the user to install the needed firmware package.
> 
> Anyway, something to that effect, the above is just to illustrate the
> intention, I don't know whether it would work. In any case, we're
> lacking user help there and we don't want to put every user through
> the process of finding which firmware files she/he needs when setting
> RADEON=y.
> 
> Does that make more sense?

Oh it makes sense, just neither of us are Kbuild hackers and I'm not sure 
that'll change at any point :)

It also sounds like something that could apply to any driver with external 
firmware.

Dave.

Re: Kernel almost hangs when CONFIG_DRM_RADEON=y

[David Airlie]

- Original Message -
 From: Borislav Petkov b...@alien8.de
 To: Alex Deucher alexdeuc...@gmail.com, Dave Airlie airl...@gmail.com
 Cc: Peter Zijlstra pet...@infradead.org, Michel Dänzer 
 mic...@daenzer.net, linux-kernel
 linux-ker...@vger.kernel.org, dri-devel@lists.freedesktop.org, Pavel 
 Ivanov paiva...@gmail.com
 Sent: Monday, 29 August, 2011 3:16:12 PM
 Subject: Re: Kernel almost hangs when CONFIG_DRM_RADEON=y
 On Mon, Aug 29, 2011 at 09:48:22AM -0400, Alex Deucher wrote:
   Should we make Kconfig pop up a dialog and ask for the
   whereabouts of
   these firmware thingies when you mark the driver =y?
  
   This all sounds like magic to me, having to know you need to add
   to
   EXTRA_FIRMWARE, having to know what file it needs etc.. For all
   intents
   and purposes =y just doesn't work and that's broken.
  
   Yep, you make a lot of sense. I had to fumble the build/reboot
   cycle a
   couple of times and do some code staring even to figure this out.
   In
   the end, I copied the whole radeon/ folder from David's firmware
   git
   repo into /lib/firmware and made radeon.ko =m again so that I
   don't have
   to add *.bin entries to CONFIG_EXTRA_FIRMWARE each time I'm
   building a
   kernel on a different machine.
  
   Besides, there was this other issue on lkml today where
   CONFIG_EXTRA_FIRMWARE can cause nconf to segfault when you
   overflow
   its length of 256 by trying to include a bunch of firmware *bin
   files:
   http://lkml.org/lkml/2011/8/29/86
 
  If you are going to build the ucode into your kernel you'll need to
  pick the ones you want to include or increase the limit regardless
  of
  whether it's radeon ucode or ucode for some other chip. For a
  particular card you only need the ones for that card (e.g.,
  CEDAR_*.bin or REDWOOD_*.bin, etc.)
 
 Alex, Dave, yeah, that's all fine.
 
 The question Peter asked is, how to make this much more understandable
 to the user so that she/he doesn't have to figure it out on their own.
 IOW, if one sets RADEON to =y in Kconfig, it should automatically
 generate a selection menu with all the firmware required so that
 the user can select from it either the CEDAR* or the REDWOOD* (or
 the DOUGHNUT* :-)) ones for her/his card and when the user selects
 one entry, the required strings are added to CONFIG_EXTRA_FIRMWARE
 _automatically_.
 
 Maybe even Kbuild should try to find them on the system, and, if
 unable
 to, remind the user to install the needed firmware package.
 
 Anyway, something to that effect, the above is just to illustrate the
 intention, I don't know whether it would work. In any case, we're
 lacking user help there and we don't want to put every user through
 the process of finding which firmware files she/he needs when setting
 RADEON=y.
 
 Does that make more sense?

Oh it makes sense, just neither of us are Kbuild hackers and I'm not sure 
that'll change at any point :)

It also sounds like something that could apply to any driver with external 
firmware.

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