[PATCH 2/2] nouveau: use new vga_switcheroo power domain.

[Lukas Wunner]

Hi Dave,

On Thu, Mar 10, 2016 at 08:04:26AM +1000, Dave Airlie wrote:
> On 10 March 2016 at 00:40, Lukas Wunner  wrote:
> > On Wed, Mar 09, 2016 at 04:14:05PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie 
> >>
> >> This fixes GPU auto powerdown on the Lenovo W541,
> >> since we advertise Windows 2013 to the ACPI layer.
> >>
> >> Signed-off-by: Dave Airlie 
> >> ---
> >>  drivers/gpu/drm/nouveau/nouveau_vga.c | 10 +++---
> >>  1 file changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
> >> b/drivers/gpu/drm/nouveau/nouveau_vga.c
> >> index af89c36..b987427f 100644
> >> --- a/drivers/gpu/drm/nouveau/nouveau_vga.c
> >> +++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
> >> @@ -101,8 +101,12 @@ nouveau_vga_init(struct nouveau_drm *drm)
> >>   runtime = true;
> >>   vga_switcheroo_register_client(dev->pdev, _switcheroo_ops, 
> >> runtime);
> >>
> >> - if (runtime && nouveau_is_v1_dsm() && !nouveau_is_optimus())
> >> - vga_switcheroo_init_domain_pm_ops(drm->dev->dev, 
> >> >vga_pm_domain);
> >> + if (runtime) {
> >> + if (nouveau_is_v1_dsm() && !nouveau_is_optimus())
> >
> > The " && !nouveau_is_optimus()" can be dropped because a machine cannot
> > have both. Note the "else" in nouveau_dsm_detect():
> 
> I'm pretty sure I've seen a machine with both in my past, back in the
> Vista/Win7 crossover days.

Yes, but the code in nouveau_dsm_detect() is such that you'll never have
both nouveau_is_v1_dsm() and nouveau_is_optimus() return true.

So you can drop the " && !nouveau_is_optimus()".

Best regards,

Lukas

> 
> > You're calling this unconditionally for all Optimus machines yet
> > I assume pre Windows 10 machines lack the PR3 hooks.
> >
> 
> Yes and I've confirmed on my older machine that nothing bad happens
> doing it unconditionally,
> and I couldn't find any bits in the _DSM flags to tell me if I should
> do something different.
> 
> Dave.

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Lukas Wunner]

Hi Alex,

On Tue, Mar 15, 2016 at 02:33:56PM -0400, Alex Deucher wrote:
> On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner  wrote:
> > On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> >> Is there any reason to make use of the mux?
> >
> > Performance (lower latency => no need for framebuffer writes over PCIe),
> > improved battery life (no need to use 2 GPUs simultaneously).
> >
> > Technically you can't just ignore that the mux is there on the MBP
> > because the kernel has no control over the GPU used on boot.
> > (It's determined by EFI).
> >
> Is GPU power switching also handled by the mux?  Is it independent of
> the display mux?

Yes and yes.

Best regards,

Lukas

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Dave Airlie]

>
> I guess that's only useful until we get runtime PM support.

For the discrete GPUs on regular laptops we have runtime PM support for
powerdown already. Some newer laptops need a bit of work in the PCIE layer
but for most things we have it covered. The known broken ones are Apple
laptops. If the apple-gmux code is working well enough to power off GPUs,
then it should be possible to hook up runtime-pm on those machines pretty
simply.

So there shouldn't really be a case we care about.

runtime PM for the Intel GPU isn't as important. We don't even want to
turn the i915 fully off anymore.

>
> After looking at our use cases in the GNOME wiki, I think that might
> not be necessary as we'll want to always run the desktop on the
> integrated GPU. That'll something to keep in mind if we ever want to
>
> Reading through the whole mail it seems to me that it's close to
> impossible to implement a decent integration without runtime PM
> support:
> - DRI_PRIME wouldn't work
> - no external display detection on some machines
>
> Do you have references for the i915 runtime PM support, a bugzilla or
> mailing-list thread?

the i915 runtime PM doesn't matter for this. Only nouveau/radeon runtime
PM matters for this, and that should work on most Windows compatible hw right
now. For Windows 10 machines there are some patches going around to make
things work. For Apple I'm pretty much in the it'll catch up or it
won't, but don't
block on it.

Dave.

[RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture

[Magnus Damm]

Hi Marek,

On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
 wrote:
> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
> side-effect of this change is a switch from bitmap-based IO address space
> management to tree-based code. There should be no functional changes
> for drivers, which rely on initialization from generic arch_setup_dna_ops()
> interface. Code, which used old arm_iommu_* functions must be updated to
> new interface.
>
> Signed-off-by: Marek Szyprowski 
> ---

Thanks for your efforts and my apologies for late comments. Just FYI
I'll try your patch (and this series) with the ipmmu-vmsa.c driver on
32-bit ARM and see how it goes. Nice not to have to support multiple
interfaces depending on architecture!

One question that comes to mind is how to handle features.

For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS
while the shared code in drivers/iommu/dma-iommu.c does not. I assume
existing users may rely on such features so from my point of view it
probably makes sense to carry over features from the 32-bit ARM code
into the shared code before pulling the plug.

I also wonder if it is possible to do a step-by-step migration and
support both old and new interfaces in the same binary? That may make
things easier for multiplatform enablement. So far I've managed to
make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some
ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with
the shared code in drivers/iommu/dma-iommu.c may also be possible. And
probably involving even more ugly magic. =)

Cheers,

/ magnus

[PATCH v13 03/14] drm/mediatek: Add DSI sub driver

[Daniel Kurtz]

On Tue, Mar 15, 2016 at 7:49 PM, Philipp Zabel  
wrote:
>
> Hi Daniel,
>
> Am Mittwoch, den 09.03.2016, 22:07 +0800 schrieb Daniel Kurtz:
> > Hi Philipp, CK,
> >
> > Some small comments.
> > Nothing that couldn't be addressed after merging, if you prefer.
> >
> > On Tue, Mar 8, 2016 at 9:27 PM, Philipp Zabel  
> > wrote:
> [...]
> > > +static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > > +{
> > > +   struct device *dev = dsi->dev;
> > > +   int ret;
> > > +
> > > +   if (++dsi->refcount != 1)
> > > +   return 0;
> >
> > What is the point of this refcount?
> > I believe dsi->enabled already ensures poweron/poweroff calls are paired.
>
> mtk_dsi_poweron() is called from both mtk_dsi_encoder_enable() and
> mtk_dsi_ddp_start() and enables just enough of the DSI to provide power
> and the pixel clock. The reason is that the DSI also provides the pixel
> clock to the rest of the pipeline elements.
>
> dsi->enabled only tracks the whole DSI being active after the call of
> mtk_dsi_encoder_enable().
>
> [...]
> > > +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct 
> > > mtk_dsi *dsi)
> > > +{
> > > +   int ret;
> > > +
> > > +   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
> > > +  DRM_MODE_ENCODER_DSI, NULL);
> > > +   if (ret) {
> > > +   DRM_ERROR("Failed to encoder init to drm\n");
> > > +   return ret;
> > > +   }
> > > +   drm_encoder_helper_add(>encoder, 
> > > _dsi_encoder_helper_funcs);
> > > +
> > > +   /*
> > > +* Currently display data paths are statically assigned to a crtc 
> > > each.
> > > +* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
> > > +*/
> > > +   dsi->encoder.possible_crtcs = 1;
> > > +
> > > +   /* Pre-empt DP connector creation if there's a bridge */
> > > +   ret = mtk_drm_attach_bridge(dsi->bridge, >encoder);
> > > +   if (!ret)
> > > +   return 0;
> >
> > nit: the above valid early termination of this function here is a bit 
> > unusual.
> > It might be more clear if the "connector init" part below was split out 
> > into its
> > own helper function.
>
> Good point, will do that.
>
> [...]
> > > +static int mtk_dsi_remove(struct platform_device *pdev)
> > > +{
> > > +   struct mtk_dsi *dsi = platform_get_drvdata(pdev);
> > > +
> > > +   mtk_output_dsi_disable(dsi);
> >
> > This one looks unmatched.
>
> It is, indeed we should let the drm core disable the encoder before the
> driver is removed.
>
> [...]
> > > +static int mtk_dsi_resume(struct device *dev)
> > > +{
> > > +   struct mtk_dsi *dsi;
> > > +
> > > +   dsi = dev_get_drvdata(dev);
> > > +
> > > +   mtk_output_dsi_enable(dsi);
> > > +   DRM_DEBUG_DRIVER("dsi resume success!\n");
> > > +
> > > +   return 0;
> > > +}
> > > +#endif
> > > +static SIMPLE_DEV_PM_OPS(mtk_dsi_pm_ops, mtk_dsi_suspend, 
> > > mtk_dsi_resume);
> >
> > I don't think we want PM ops.
> > The MTK DRM driver disables/enables encoders during suspend/resume.
>
> Yes, and that will also allow to merge mtk_output_dsi_disable() into
> mtk_dsi_encoder_disable(), too.
>
> [...]
> > > +static unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
> > > +unsigned long 
> > > parent_rate)
> > > +{
> > > +   struct mtk_mipi_tx *mipi_tx = container_of(hw, struct mtk_mipi_tx,
> > > +  pll_hw);
> >
> > An inline function / macro would help here.
>
> Ok.
>
> [...]
> > > +static void mtk_mipi_tx_power_off_signal(struct phy *phy)
> > > +{
> > > +   struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
> > > +
> > > +   mtk_mipi_tx_mask(mipi_tx, MIPITX_DSI_TOP_CON, 
> > > RG_DSI_PAD_TIE_LOW_EN,
> > > +RG_DSI_PAD_TIE_LOW_EN);
> >
> > As mentioned in the HDMI review, _set_bits() / _clr_bits() is more readable 
> > than
> > _mask() if we are just setting/clearing groups of bits.
>
> I don't think
> mtk_mipi_tx_set_bits(mipi_tx, MIPITX_DSI_TOP_CON,
>  RG_DSI_PAD_TIE_LOW_EN);
> is that much easier to read. How about calling the function
> mtk_mipi_tx_update_bits instead?

Actually, the important part here was to remove the redundant 'value'
parameter, and instead have dedicated clear / set functions that
operate on just the mask.



>
> regards
> Philipp
>

[Bug 114711] New: ubsan: "shift exponent 32 is too large" in drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c:167:16

[bugzilla-dae...@bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=114711

Bug ID: 114711
   Summary: ubsan: "shift exponent 32 is too large" in
drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c:167:16
   Product: Drivers
   Version: 2.5
Kernel Version: 4.5.0
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: peter at arbitrary.ch
Regression: No

The following message appeared during boot. Let me know if you need more
information.


Mar 15 12:09:22 ivy kernel:

Mar 15 12:09:22 ivy kernel: UBSAN: Undefined behaviour in
drivers/gpu/drm/nouveau/nvkm/subdev/gpio/base.c:167:16
Mar 15 12:09:22 ivy kernel: shift exponent 32 is too large for 32-bit type
'int'
Mar 15 12:09:22 ivy kernel: CPU: 3 PID: 546 Comm: systemd-udevd Not tainted
4.5.0-pege1 #1
Mar 15 12:09:22 ivy kernel: Hardware name: Hewlett-Packard HP ENVY dv6 Notebook
PC/181B, BIOS F.29 10/03/2013
Mar 15 12:09:22 ivy kernel:   0f597554 816fcef7
0020
Mar 15 12:09:22 ivy kernel:  0f597554 88044999f640 88044999f6c8
817952a9
Mar 15 12:09:22 ivy kernel:  c210dc40 81795caa 0202
000fff003233
Mar 15 12:09:22 ivy kernel: Call Trace:
Mar 15 12:09:22 ivy kernel:  [] ? dump_stack+0x70/0xb9
Mar 15 12:09:22 ivy kernel:  [] ? ubsan_epilogue+0x9/0x40
Mar 15 12:09:22 ivy kernel:  [] ?
__ubsan_handle_shift_out_of_bounds+0xfa/0x150
Mar 15 12:09:22 ivy kernel:  [] ? flush_work+0x2e/0x270
Mar 15 12:09:22 ivy kernel:  [] ? gk104_ram_new+0x2161/0x24a0
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_gpio_fini+0x10b/0x1f0
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_subdev_fini+0x9e/0x4d0
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? ktime_get+0x7c/0x220
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_device_fini+0x80/0x340
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ?
nvkm_device_init+0x107/0x4f0 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ?
nvkm_udevice_init+0x6a/0x110 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_object_init+0x78/0x4a0
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_ioctl_new+0x206/0x740
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_client_new+0xbb/0x160
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ?
nvkm_client_notify+0xe0/0xe0 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_udevice_rd08+0x80/0x80
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvkm_ioctl+0x226/0x6b0
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? bus_find_device+0xaa/0x120
Mar 15 12:09:22 ivy kernel:  [] ?
nvif_object_init+0x130/0x380 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? nvif_device_init+0xe/0x50
[nouveau]
Mar 15 12:09:22 ivy kernel:  [] ?
nouveau_drm_load+0x21b/0x1490 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? _raw_spin_unlock+0x34/0x80
Mar 15 12:09:22 ivy kernel:  [] ?
pci_bus_read_config_word+0xb2/0x100
Mar 15 12:09:22 ivy kernel:  [] ?
_raw_spin_unlock_irqrestore+0x42/0x80
Mar 15 12:09:22 ivy kernel:  [] ? drm_dev_register+0xb9/0x110
[drm]
Mar 15 12:09:22 ivy kernel:  [] ? drm_get_pci_dev+0xbb/0x640
[drm]
Mar 15 12:09:22 ivy kernel:  [] ? __pci_set_master+0x4e/0x190
Mar 15 12:09:22 ivy kernel:  [] ?
nouveau_drm_probe+0x40f/0x780 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ?
nouveau_pmops_runtime_idle+0x2e0/0x2e0 [nouveau]
Mar 15 12:09:22 ivy kernel:  [] ? local_pci_probe+0x6b/0x140
Mar 15 12:09:22 ivy kernel:  [] ?
pci_device_probe+0x149/0x1b0
Mar 15 12:09:22 ivy kernel:  [] ?
driver_probe_device+0x1b2/0xcb0
Mar 15 12:09:22 ivy kernel:  [] ?
driver_probe_device+0xcb0/0xcb0
Mar 15 12:09:22 ivy kernel:  [] ? __driver_attach+0xd2/0x180
Mar 15 12:09:22 ivy kernel:  [] ? bus_for_each_dev+0x8c/0x110
Mar 15 12:09:22 ivy kernel:  [] ? klist_add_tail+0x3d/0x100
Mar 15 12:09:22 ivy kernel:  [] ? bus_add_driver+0x2b4/0x570
Mar 15 12:09:22 ivy kernel:  [] ? 0xc2382000
Mar 15 12:09:22 ivy kernel:  [] ? driver_register+0xf3/0x2f0
Mar 15 12:09:22 ivy kernel:  [] ? do_one_initcall+0xd2/0x290
Mar 15 12:09:22 ivy kernel:  [] ? do_init_module+0xf1/0x366
Mar 15 12:09:22 ivy kernel:  [] ? load_module+0x33a8/0x62f0
Mar 15 12:09:22 ivy kernel:  [] ? __symbol_put+0x90/0x90
Mar 15 12:09:22 ivy kernel:  [] ?
copy_module_from_fd+0x125/0x210
Mar 15 12:09:22 ivy kernel:  [] ? SYSC_finit_module+0x8a/0xc0
Mar 15 12:09:22 ivy kernel:  [] ?
entry_SYSCALL_64_fastpath+0x16/0x75
Mar 15 12:09:22 ivy kernel:

Mar 15 12:09:22 ivy kernel: nouveau :01:00.0: fb: 1024 MiB DDR3
Mar 15 12:09:22 ivy kernel: vga_switcheroo: enabled
Mar 15 12:09:22 ivy kernel: [TTM] Zone  kernel: Available graphics memory:
8149734 kiB
Mar 15 12:09:22 ivy kernel: [TTM] Zone   dma32: Available graphics memory:
2097152 kiB
Mar 

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Lukas Wunner]

Hi Alex,

On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
> Is there any reason to make use of the mux?

Performance (lower latency => no need for framebuffer writes over PCIe),
improved battery life (no need to use 2 GPUs simultaneously).

Technically you can't just ignore that the mux is there on the MBP
because the kernel has no control over the GPU used on boot.
(It's determined by EFI).


> > I've heard that the AMD GPU is picky about external monitors and
> > doesn't recognize them unless they're plugged in at exactly the
> > right moment, so you may need to retry a couple of times until it
> > works.
> 
> Are talking about some issue specific to these muxed apple systems or
> in general?

Feedback I got from William Brown of Red Hat who tested the GPU switching
patches on an MBP8,2 and reported that (independently of the patches),
a display connected with an original Apple DP-to-DVI adapter would only
be recognized if plugged in at exactly the right moment and in the correct
order (first adapter, then display). However it doesn't seem to work
better on OS X.


> If you are having issues, please file a bug.

I'm not having issues so can't file a bug. Besides, filing a bug is no
guarantee that things get fixed. He had opened a bug for GPU switching
3 years ago (https://bugs.freedesktop.org/show_bug.cgi?id=61115) and
nobody did a thing. Obviously whether something gets fixed is a function
of the perceived importance by maintainers, unless a volunteer comes
along and does the dirty work.

Best regards,

Lukas

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

Zentdayn  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #87 from Zentdayn  ---
(In reply to Zentdayn from comment #86)
> I also had this issue but comment #77 fixed it for me.
> 
> My Ubuntu install is now usable.

Nevermind, probably luck. Just froze, going back to low profile.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/a3236ac0/attachment.html>

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91880

Zentdayn  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #86 from Zentdayn  ---
I also had this issue but comment #77 fixed it for me.

My Ubuntu install is now usable.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/fb7e9263/attachment.html>

Please accept my invitation to join Bangaloreans with OCD - Meetup

[Ajay Kumar]

Bangaloreans with OCD - Meetup


Join Ajay Kumar in Bangalore. Be the first to hear about upcoming Meetups.

Hello All,
This is Ajay from Bangalore.I have OCD when it comes to hygiene, decision 
making, relationships, etc.People often think of me as weird, and even I find 
it difficult to adjust to others ofte...

--

Accept invitation

https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkZXN0IjoiaHR0cHM6Ly9zZWN1cmUubWVldHVwLmNvbS9yZWdpc3Rlci8_Z2o9ZWo0cyZjPTE5NzE0MjE4Jl94dGQ9Z3F0bGJXRnBiRjlqYkdsamE5b0FKRGMyWkdRd04yTTVMV0U1TXpZdE5HVmlaQzA0TTJabExUUmhOV05pTTJWaFlUTTFOYXBwYm5acGRHVmxYMmxrcHpZMk5EVXhNRFkmcmc9ZWo0cyZjdHg9aW52JnRhcmdldFVyaT1odHRwJTNBJTJGJTJGd3d3Lm1lZXR1cC5jb20lMkZCYW5nYWxvcmVhbnMtd2l0aC1PQ0QtTWVldHVwJTJGJTNGZ2olM0RlajRzJTI2cmclM0RlajRzIiwiaG9vayI6ImludiIsImVtYWlsX2ludml0ZWVfaWQiOjY2NDUxMDYsImV4cCI6MTQ1OTI4NzEyNSwiaWF0IjoxNDU4MDc3NTI1LCJqdGkiOiI1YmM4MjE4NS1kZGJkLTQwMTctYjg0MC05YmE3YTM0ZDkxYmQifQ%3D%3D.7ME_tgTXdELjJ7HHiS7Z6qFoRYnFRWvdDYIvYmIwBTM%3D

--

---
This message was sent by Meetup on behalf of Ajay Kumar 
(http://www.meetup.com/Bangaloreans-with-OCD-Meetup/members/191236630/) from 
Bangaloreans with OCD - Meetup.


Questions? You can email Meetup Support at support at meetup.com

Unsubscribe 
(https://secure.meetup.com/n/?s=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJob29rIjoiaW52X29wdG91dCIsImRlc3QiOiJodHRwOi8vd3d3Lm1lZXR1cC5jb20vYWNjb3VudC9vcHRvdXQvP3N1Ym1pdD10cnVlJmVvPXRjMiZlbWFpbD1pbnZpdGUmX21zX3Vuc3ViPXRydWUiLCJlbWFpbCI6ImRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmciLCJpbnZpdGVyX2lkIjoxOTEyMzY2MzAsImV4cCI6MTQ1OTI4NzEyNSwiaWF0IjoxNDU4MDc3NTI1LCJqdGkiOiIzOTZhMTUyYi0zNDk0LTQ0ZGUtYTRlOC03MmI2ZDQ5ODdiNWMifQ%3D%3D.dd5N-5eSYNlxeRMP8nAO5G2n4_4epL45UMEaeq2b2bU%3D)
 from this type of email.

Meetup Inc. (http://www.meetup.com/), POB 4668 #37895 New York NY USA 10163
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/87b68988/attachment.html>

[PATCH v8 2/2] staging/android: refactor SYNC IOCTLs

[kbuild test robot]

Hi Gustavo,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20160315]
[cannot apply to v4.5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Gustavo-Padovan/staging-android-remove-redundant-comments-on-sync_merge_data/20160315-051123
config: i386-randconfig-h1-03151610 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from include/linux/linkage.h:4:0,
from include/linux/fs.h:4,
from include/linux/debugfs.h:18,
from drivers/staging/android/sync.c:17:
   drivers/staging/android/sync.c: In function 'sync_file_ioctl_fence_info':
   drivers/staging/android/sync.c:535:19: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
  ^
   include/linux/compiler.h:147:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers/staging/android/sync.c:535:2: note: in expansion of macro 'if'
 if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
 ^
   drivers/staging/android/sync.c:535:19: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
  ^
   include/linux/compiler.h:147:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^
>> drivers/staging/android/sync.c:535:2: note: in expansion of macro 'if'
 if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
 ^
   drivers/staging/android/sync.c:535:19: warning: cast to pointer from integer 
of different size [-Wint-to-pointer-cast]
 if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
  ^
   include/linux/compiler.h:158:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^
>> drivers/staging/android/sync.c:535:2: note: in expansion of macro 'if'
 if (copy_to_user((void __user *)info.sync_fence_info, fence_info,
 ^

vim +/if +535 drivers/staging/android/sync.c

   519   * info->num_fences.
   520   */
   521  if (!info.num_fences)
   522  goto no_fences;
   523  
   524  if (info.num_fences < sync_file->num_fences)
   525  return -EINVAL;
   526  
   527  size = sync_file->num_fences * sizeof(*fence_info);
   528  fence_info = kzalloc(size, GFP_KERNEL);
   529  if (!fence_info)
   530  return -ENOMEM;
   531  
   532  for (i = 0; i < sync_file->num_fences; ++i)
   533  sync_fill_fence_info(sync_file->cbs[i].fence, 
_info[i]);
   534  
 > 535  if (copy_to_user((void __user *)info.sync_fence_info, 
 > fence_info,
   536   size)) {
   537  ret = -EFAULT;
   538  goto out;
   539  }
   540  
   541  no_fences:
   542  strlcpy(info.name, sync_file->name, sizeof(info.name));
   543  info.status = atomic_read(_file->status);

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 22770 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/3a543175/attachment-0001.obj>

[PATCH 1/4 v3] drm: Add support of ARC PGU display controller

[Daniel Vetter]

On Tue, Mar 15, 2016 at 03:24:46PM +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:
> > On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> > > 
> > > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > > > 
> > > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > > > 
> > > > > +static int arcpgu_atomic_commit(struct drm_device *dev,
> > > > > +     struct drm_atomic_state *state, 
> > > > > bool async)
> > > > > +{
> > > > > + return drm_atomic_helper_commit(dev, state, false);
> > > > Note that this isn't really async if you ever get around to implement
> > > > fence support or vblank support. Just fyi.
> > > Ok but for now should I leave it as it is?
> > Yeah ok as-is, hence just fyi.
> 
> Thanks. Just wanted to make sure we're on the same page :)
> 
> > > 
> > > > 
> > > > > 
> > > > > +static struct drm_driver arcpgu_drm_driver = {
> > > > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
> > > > > +    DRIVER_ATOMIC,
> > > > > + .preclose = arcpgu_preclose,
> > > > > + .lastclose = arcpgu_lastclose,
> > > > > + .name = "drm-arcpgu",
> > > > > + .desc = "ARC PGU Controller",
> > > > > + .date = "20160219",
> > > > > + .major = 1,
> > > > > + .minor = 0,
> > > > > + .patchlevel = 0,
> > > > > + .fops = _drm_ops,
> > > > > + .load = arcpgu_load,
> > > > > + .unload = arcpgu_unload,
> > > > Load and unload hooks are deprecated (it's a classic midlayer mistake).
> > > > Please use drm_dev_alloc/register pairs directly instead, and put your
> > > > device setup code in-between. Similar for unloading. There's a bunch of
> > > > example drivers converted already.
> > > Ok I took "atmel-hlcdc" as example.
> > > And that's interesting.
> > > 
> > > If I put my arcpgu_load() in between drm_dev_alloc() and
> > > drm_dev_register() then I'm getting this on the driver probe:
> > > -->8---
> > > [drm] Initialized drm 1.1.0 20060810
> > > arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
> > > [ cut here ]
> > > WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 
> > > kobject_add_internal+0x17c/0x498()
> > > kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
> > > Modules linked in:
> > > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17
> > > 
> > > Stack Trace:
> > >   arc_unwind_core.constprop.1+0xa4/0x110
> > >   warn_slowpath_fmt+0x6e/0xfc
> > >   kobject_add_internal+0x17c/0x498
> > >   kobject_add+0x98/0xe4
> > >   device_add+0xc6/0x734
> > >   device_create_with_groups+0x12a/0x144
> > >   drm_sysfs_connector_add+0x54/0xe8
> > >   arcpgu_drm_hdmi_init+0xd4/0x17c
> > >   arcpgu_probe+0x138/0x24c
> > >   platform_drv_probe+0x2e/0x6c
> > >   really_probe+0x212/0x35c
> > >   __driver_attach+0x90/0x94
> > >   bus_for_each_dev+0x46/0x80
> > >   bus_add_driver+0x14e/0x1b4
> > >   driver_register+0x64/0x108
> > >   do_one_initcall+0x86/0x194
> > >   kernel_init_freeable+0xf0/0x188
> > > ---[ end trace c67166ad43ddcce2 ]---
> > > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs
> > > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector 
> > > device: -2
> > > arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs
> > > arcpgu: probe of e0017000.pgu failed with error -2
> > > -->8---
> > > 
> > > But if I move arcpgu_load() after drm_dev_register() then everything
> > > starts properly and I may see HDMI screen works perfectly fine.
> > > 
> > > Any thoughts?
> > Oops, yeah missed that detail. If you look at atmel it has a loop to
> > register all the drm connectors _after_ calling drm_dev_register().
> > Totally forgot about that. Can you pls
> > - Extract a new drm_connector_register_all() function
> >   (atmel_hlcdc_dc_connector_plug_all seems to be the best template),
> >   including kerneldoc.
> > - Adjust kerneldoc of drm_dev_register() to mention
> >   drm_connector_register_all() and that ordering constraint.
> > - Roll that helper out to all the drivers that currently hand-roll it (one
> >   patch per driver).
> > 
> > I know a bit of work but imo not too much, and by doing some small
> > refactoring every time someone stumbles over a drm pitfall we keep the
> > subsystem clean to understand. You're up for this? Would be a prep
> > series, I'll happily review it to get it merged fast. Just a few weeks ago
> > I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy
> > ones all over the subsystem, in other words: You'll have my full attention
> > ;-)
> 
> Sure, I'm ready to pay that price :)
> Stay tuned and patches will follow.

Awesome, looking forward to your patches.

> > > 
> > > > 
> > > > > 
> > > > > + .dumb_create = 

[PATCH 1/2] drm/atomic: use helper to get crtc state

[Ville Syrjälä]

On Tue, Mar 15, 2016 at 01:46:00PM +0100, Andrzej Hajda wrote:
> DRM core provide helper to access crtc state.
> 
> Signed-off-by: Andrzej Hajda 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2b430b0..e1cbba6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -67,7 +67,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
> *state,
>   struct drm_crtc_state *crtc_state;
>  
>   if (plane->state->crtc) {
> - crtc_state = 
> state->crtc_states[drm_crtc_index(plane->state->crtc)];
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + 
> plane->state->crtc);
>  
>   if (WARN_ON(!crtc_state))
>   return;
> @@ -76,8 +77,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
> *state,
>   }
>  
>   if (plane_state->crtc) {
> - crtc_state =
> - state->crtc_states[drm_crtc_index(plane_state->crtc)];
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + 
> plane_state->crtc);
>  
>   if (WARN_ON(!crtc_state))
>   return;
> @@ -366,8 +367,8 @@ mode_fixup(struct drm_atomic_state *state)
>   if (!conn_state->crtc || !conn_state->best_encoder)
>   continue;
>  
> - crtc_state =
> - state->crtc_states[drm_crtc_index(conn_state->crtc)];
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> + 
> conn_state->crtc);
>  
>   /*
>* Each encoder has at most one connector (since we always steal
> @@ -666,7 +667,8 @@ disable_outputs(struct drm_device *dev, struct 
> drm_atomic_state *old_state)
>   if (!old_conn_state->crtc)
>   continue;
>  
> - old_crtc_state = 
> old_state->crtc_states[drm_crtc_index(old_conn_state->crtc)];
> + old_crtc_state = drm_atomic_get_existing_crtc_state(old_state,
> + 
> old_conn_state->crtc);
>  
>   if (!old_crtc_state->active ||
>   !drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.

[Mika Westerberg]

On Tue, Mar 15, 2016 at 02:39:58PM +0100, Lukas Wunner wrote:
> Hi Mika,
> 
> On Mon, Mar 14, 2016 at 11:43:35AM +0200, Mika Westerberg wrote:
> > On Mon, Mar 14, 2016 at 12:19:14PM +1000, Dave Airlie wrote:
> > > On 11 March 2016 at 23:45, Rafael J. Wysocki  wrote:
> > > > On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
> > > >> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> > > >> > > It doesn't seem to do any runtime PM,
> > > >> > > I do wonder if pcieport should be doing it's own runtime PM 
> > > >> > > handling,
> > > >> > > but that is a
> > > >> > > larger task than I'm thinking to tackle here.
> > > >> >
> > > >> > PCIe ports don't do PM - yet.  Mika has posted a series of patches 
> > > >> > to implement
> > > >> > that, however, that are waiting for comments now:
> > > >> >
> > > >> > https://patchwork.kernel.org/patch/8453311/
> > > >> > https://patchwork.kernel.org/patch/8453381/
> > > >> > https://patchwork.kernel.org/patch/8453391/
> > > >> > https://patchwork.kernel.org/patch/8453411/
> > > >> > https://patchwork.kernel.org/patch/8453371/
> > > >> > https://patchwork.kernel.org/patch/8453351/
> 
> If a pciehp port is runtime suspended and pciehp_poll_mode is enabled,
> the poll timer needs to be disabled and later reenabled on runtime resume.

If we disable the timer then we can't detect when a new device is
connected to the port.

I think in this case it might be better not to enable runtime PM for the
port at all.

linux-next: Tree for Mar 14

[Sergey Senozhatsky]

On (03/15/16 07:43), Wolfram Sang wrote:
> > Hello,
> > 
> > I'm seeing a bunch of warnings and errors
> 
> I pushed the fix to my for-next branch yesterday. Sorry for the fuzz!

no prob, thanks!

-ss

[PATCH v2 00/22] Exynos DRM: new life of IPP (Image Post Processing) subsystem

[Tobias Jakobi]

Hello all,

I wanted to ask if there has been any progress since last time. Also I
was wondering if it would be feasible to just fixup the IPP API and then
go from there (instead of trying to do automagic behind the scenes).
Marek has pointed out that currently the API has some major flaws and
the wording of the objects used (e.g. IPP property) probably isn't
really the best.

However there don't seem to be any upstream users, so again breaking the
API should be fine?

I'm still interested in using the framework for a vo backend for the mpv
media player.


With best wishes,
Tobias


Marek Szyprowski wrote:
> Dear All,
> 
> This patch series introduces a new life into Exynos IPP (Image Post
> Processing) subsystem by integrating it (transparently for userspace
> applications) with Exynos DRM core plane management. This means that all
> CRTC drivers transparently get support for standard features of IPP
> subsystem like rotation, scaling and color space conversion.
> 
> Support for features not supported natively by CRTC drivers is
> implemented with a help of temporary framebuffers, where image data is
> processed by IPP subsystem before performing the scanout by a CRTC driver.
> 
> This is second version of this patchset. The initial version is available
> here:
> http://thread.gmane.org/gmane.linux.kernel.samsung-soc/49743
> 
> The main change since v1 is support for color space conversion and minor
> fixes in the preparation patches (added support for native scaling in
> Exynos Video Processor module).
> 
> This feature is 'experimental'. From the initial discussion I see that
> there is no consensus if this feature should be integrated seamplessly
> in Exynos DRM core or provided by a separate API. This will be further
> discussed.
> 
> However, I would like to ask for merging patches 1-15, which are pure
> bugfixes and code cleanups. The patches are based on top of current
> exynos-drm-next branch.
> 
> Best regards
> Marek Szyprowski
> Samsung R Institute Poland
> 
> 
> Patch summary:
> 
> Marek Szyprowski (17):
>   drm/exynos: rotator: convert to common clock framework
>   drm/exynos: exynos7-decon: remove excessive check
>   drm/exynos: move dma_addr attribute from exynos plane to exynos fb
>   drm/exynos: introduce exynos_drm_plane_state structure
>   drm/exynos: mixer: use crtc->state->adjusted_mode instead of
> crtc->mode
>   drm/exynos: mixer: enable video overlay plane only when VP is
> available
>   drm/exynos: introduce exynos_drm_plane_config structure
>   drm/exynos: add generic check for plane state
>   drm/exynos: mixer: use ratio precalculated in exynos_state
>   drm/exynos: fix clipping when scaling is enabled
>   drm/exynos: fimd: fix dma burst size setting for small plane size
>   drm/exynos: gem: remove old unused prototypes
>   drm/exynos: add fb pointer to exynos_drm_plane_state
>   drm/exynos: gem: set default alignment for dumb GEM buffers
>   drm/exynos: gem: simplify access to exynos gem object
>   drm/exynos: ipp: make framework context global
>   drm/exynos: add support for plane rotation, scalling and colospace
> convesion
> 
> Seung-Woo Kim (5):
>   drm/exynos: gsc: prepare and unprepare gsc clock
>   drm/exynos: gsc: fix wrong pm_runtime state
>   drm/exynos: gsc: add device tree support and remove usage of static
> mappings
>   drm/exynos: fix to calculate offset of each plane for ipp fimc
>   drm/exynos: fix to calculate offset of each plane for ipp gsc
> 
>  .../devicetree/bindings/media/exynos5-gsc.txt  |   4 +
>  drivers/gpu/drm/exynos/Kconfig |  10 +-
>  drivers/gpu/drm/exynos/Makefile|   1 +
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c  |  48 ++-
>  drivers/gpu/drm/exynos/exynos7_drm_decon.c |  68 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h|  96 --
>  drivers/gpu/drm/exynos/exynos_drm_fb.c |  16 +-
>  drivers/gpu/drm/exynos/exynos_drm_fb.h |   3 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimc.c   | 106 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  88 ++---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c|  48 ++-
>  drivers/gpu/drm/exynos/exynos_drm_gem.c|  54 +--
>  drivers/gpu/drm/exynos/exynos_drm_gem.h|  51 +--
>  drivers/gpu/drm/exynos/exynos_drm_gsc.c| 151 -
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c| 240 +++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.h|   8 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c  | 237 -
>  drivers/gpu/drm/exynos/exynos_drm_plane.h  |   7 +-
>  drivers/gpu/drm/exynos/exynos_drm_plane_ipp.c  | 369 
> +
>  drivers/gpu/drm/exynos/exynos_drm_plane_ipp.h  |  73 
>  drivers/gpu/drm/exynos/exynos_drm_rotator.c|   4 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  30 +-
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 129 ---
>  

Oops (NULL pointer dereference) in radeon_fence_ref in 3.14.63

[Michel Dänzer]

On 08.03.2016 11:54, Nicolai Hähnle wrote:
> On 05.03.2016 16:24, Christian König wrote:
>> just an educated guess, but I think the problem is simply that kernel
>> 3.14 doesn't yet contain the code so that radeon_fence_get() can safely
>> called with a NULL pointer.
>>
>> So the backport of Nicolai's patch needs and extra check for the case
>> when the fence is NULL.
> 
> Oops indeed. Only the ref call should need the guard, the unref has
> always had a NULL pointer test as far as I can see.
> 
> Lutz, could you please test whether the attached patch on top of 3.14.63
> fixes the problem?

Nicolai, if you haven't already, please send this patch to
stable at vger.kernel.org with an explicit explanation of which stable
branches need it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 1/4 v3] drm: Add support of ARC PGU display controller

[Alexey Brodkin]

Hi Daniel,

On Tue, 2016-03-15 at 09:10 +0100, Daniel Vetter wrote:
> On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> > 
> > On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > > 
> > > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > > 
> > > > +static int arcpgu_atomic_commit(struct drm_device *dev,
> > > > +       struct drm_atomic_state *state, 
> > > > bool async)
> > > > +{
> > > > +   return drm_atomic_helper_commit(dev, state, false);
> > > Note that this isn't really async if you ever get around to implement
> > > fence support or vblank support. Just fyi.
> > Ok but for now should I leave it as it is?
> Yeah ok as-is, hence just fyi.

Thanks. Just wanted to make sure we're on the same page :)

> > 
> > > 
> > > > 
> > > > +static struct drm_driver arcpgu_drm_driver = {
> > > > +   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
> > > > +      DRIVER_ATOMIC,
> > > > +   .preclose = arcpgu_preclose,
> > > > +   .lastclose = arcpgu_lastclose,
> > > > +   .name = "drm-arcpgu",
> > > > +   .desc = "ARC PGU Controller",
> > > > +   .date = "20160219",
> > > > +   .major = 1,
> > > > +   .minor = 0,
> > > > +   .patchlevel = 0,
> > > > +   .fops = _drm_ops,
> > > > +   .load = arcpgu_load,
> > > > +   .unload = arcpgu_unload,
> > > Load and unload hooks are deprecated (it's a classic midlayer mistake).
> > > Please use drm_dev_alloc/register pairs directly instead, and put your
> > > device setup code in-between. Similar for unloading. There's a bunch of
> > > example drivers converted already.
> > Ok I took "atmel-hlcdc" as example.
> > And that's interesting.
> > 
> > If I put my arcpgu_load() in between drm_dev_alloc() and
> > drm_dev_register() then I'm getting this on the driver probe:
> > -->8---
> > [drm] Initialized drm 1.1.0 20060810
> > arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 
> > kobject_add_internal+0x17c/0x498()
> > kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
> > Modules linked in:
> > CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17
> > 
> > Stack Trace:
> >   arc_unwind_core.constprop.1+0xa4/0x110
> >   warn_slowpath_fmt+0x6e/0xfc
> >   kobject_add_internal+0x17c/0x498
> >   kobject_add+0x98/0xe4
> >   device_add+0xc6/0x734
> >   device_create_with_groups+0x12a/0x144
> >   drm_sysfs_connector_add+0x54/0xe8
> >   arcpgu_drm_hdmi_init+0xd4/0x17c
> >   arcpgu_probe+0x138/0x24c
> >   platform_drv_probe+0x2e/0x6c
> >   really_probe+0x212/0x35c
> >   __driver_attach+0x90/0x94
> >   bus_for_each_dev+0x46/0x80
> >   bus_add_driver+0x14e/0x1b4
> >   driver_register+0x64/0x108
> >   do_one_initcall+0x86/0x194
> >   kernel_init_freeable+0xf0/0x188
> > ---[ end trace c67166ad43ddcce2 ]---
> > [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs
> > [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: 
> > -2
> > arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs
> > arcpgu: probe of e0017000.pgu failed with error -2
> > -->8---
> > 
> > But if I move arcpgu_load() after drm_dev_register() then everything
> > starts properly and I may see HDMI screen works perfectly fine.
> > 
> > Any thoughts?
> Oops, yeah missed that detail. If you look at atmel it has a loop to
> register all the drm connectors _after_ calling drm_dev_register().
> Totally forgot about that. Can you pls
> - Extract a new drm_connector_register_all() function
>   (atmel_hlcdc_dc_connector_plug_all seems to be the best template),
>   including kerneldoc.
> - Adjust kerneldoc of drm_dev_register() to mention
>   drm_connector_register_all() and that ordering constraint.
> - Roll that helper out to all the drivers that currently hand-roll it (one
>   patch per driver).
> 
> I know a bit of work but imo not too much, and by doing some small
> refactoring every time someone stumbles over a drm pitfall we keep the
> subsystem clean to understand. You're up for this? Would be a prep
> series, I'll happily review it to get it merged fast. Just a few weeks ago
> I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy
> ones all over the subsystem, in other words: You'll have my full attention
> ;-)

Sure, I'm ready to pay that price :)
Stay tuned and patches will follow.

> > 
> > > 
> > > > 
> > > > +   .dumb_create = drm_gem_cma_dumb_create,
> > > > +   .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> > > > +   .dumb_destroy = drm_gem_dumb_destroy,
> > > > +   .get_vblank_counter = drm_vblank_no_hw_counter,
> > > > +   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > > > +   .prime_fd_to_handle 

[PATCH] drm/omap: fix panel/encoder probes

[Tomi Valkeinen]

The recent changes which removed platform data support from panels &
encoders had a few mistakes, causing probes of DVI connector and DSI
command mode panels to fail every time due to missing '!'. Fix the
if()s.

Signed-off-by: Tomi Valkeinen 
Reported-by: Laurent Pinchart 
---

Hi Dave,

Can you apply this to drm-next? I have no other fixes at the moment, and
sending a pull request seems pointless.

 drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 2 +-
 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 3fd5a0b4d4cf..747f26a55e43 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -279,7 +279,7 @@ static int dvic_probe(struct platform_device *pdev)

platform_set_drvdata(pdev, ddata);

-   if (pdev->dev.of_node)
+   if (!pdev->dev.of_node)
return -ENODEV;

r = dvic_probe_of(pdev);
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index ae7dd625e19f..36485c2137ce 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -1180,7 +1180,7 @@ static int dsicm_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->pdev = pdev;

-   if (pdev->dev.of_node)
+   if (!pdev->dev.of_node)
return -ENODEV;

r = dsicm_probe_of(pdev);
-- 
2.5.0

[PATCH 1/2] vga_switcheroo: add power support for windows 10 machines.

[Lukas Wunner]

Hi Mika,

On Mon, Mar 14, 2016 at 11:43:35AM +0200, Mika Westerberg wrote:
> On Mon, Mar 14, 2016 at 12:19:14PM +1000, Dave Airlie wrote:
> > On 11 March 2016 at 23:45, Rafael J. Wysocki  wrote:
> > > On Friday, March 11, 2016 12:58:15 PM Mika Westerberg wrote:
> > >> On Thu, Mar 10, 2016 at 09:57:09PM +0100, Rafael J. Wysocki wrote:
> > >> > > It doesn't seem to do any runtime PM,
> > >> > > I do wonder if pcieport should be doing it's own runtime PM handling,
> > >> > > but that is a
> > >> > > larger task than I'm thinking to tackle here.
> > >> >
> > >> > PCIe ports don't do PM - yet.  Mika has posted a series of patches to 
> > >> > implement
> > >> > that, however, that are waiting for comments now:
> > >> >
> > >> > https://patchwork.kernel.org/patch/8453311/
> > >> > https://patchwork.kernel.org/patch/8453381/
> > >> > https://patchwork.kernel.org/patch/8453391/
> > >> > https://patchwork.kernel.org/patch/8453411/
> > >> > https://patchwork.kernel.org/patch/8453371/
> > >> > https://patchwork.kernel.org/patch/8453351/

If a pciehp port is runtime suspended and pciehp_poll_mode is enabled,
the poll timer needs to be disabled and later reenabled on runtime resume.

Don't we need to add runtime pm callbacks to struct pcie_port_service_driver
for that, and call them from pcie_port_runtime_*()?

Best regards,

Lukas

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Alex Deucher]

On Tue, Mar 15, 2016 at 1:54 PM, Lukas Wunner  wrote:
> Hi Alex,
>
> On Sat, Mar 05, 2016 at 01:10:56PM -0500, Alex Deucher wrote:
>> Is there any reason to make use of the mux?
>
> Performance (lower latency => no need for framebuffer writes over PCIe),
> improved battery life (no need to use 2 GPUs simultaneously).
>
> Technically you can't just ignore that the mux is there on the MBP
> because the kernel has no control over the GPU used on boot.
> (It's determined by EFI).
>

Is GPU power switching also handled by the mux?  Is it independent of
the display mux?

>
>> > I've heard that the AMD GPU is picky about external monitors and
>> > doesn't recognize them unless they're plugged in at exactly the
>> > right moment, so you may need to retry a couple of times until it
>> > works.
>>
>> Are talking about some issue specific to these muxed apple systems or
>> in general?
>
> Feedback I got from William Brown of Red Hat who tested the GPU switching
> patches on an MBP8,2 and reported that (independently of the patches),
> a display connected with an original Apple DP-to-DVI adapter would only
> be recognized if plugged in at exactly the right moment and in the correct
> order (first adapter, then display). However it doesn't seem to work
> better on OS X.

Sounds like a issue with their adapter.

>
>
>> If you are having issues, please file a bug.
>
> I'm not having issues so can't file a bug. Besides, filing a bug is no
> guarantee that things get fixed. He had opened a bug for GPU switching
> 3 years ago (https://bugs.freedesktop.org/show_bug.cgi?id=61115) and
> nobody did a thing. Obviously whether something gets fixed is a function
> of the perceived importance by maintainers, unless a volunteer comes
> along and does the dirty work.

Well, of course everyone is busy and developers will prioritize
issues.  However, bugs that are not reported have substantially less
chance of getting fixed.

Alex

[PULL] drm-amdkfd-next-fixes

[Oded Gabbay]

Hi Dave,

Just a small fix for uninitialized variable. Hoping you could squeeze it into 
the merge window's pull request, but -rc2 is perfectly fine as well.

Thanks,

Oded

The following changes since commit 211afd577a186e18d3eece543c6767420d6f6737:

  Merge tag 'drm-vc4-next-2016-03-14' of github.com:anholt/linux into drm-next 
(2016-03-15 09:49:19 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~gabbayo/linux 
tags/drm-amdkfd-next-fixes-2016-03-15

for you to fetch changes up to 93fce954427effee89e44a976299b15dd75b4bbc:

  drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers() 
(2016-03-15 14:09:37 +0200)


Dan Carpenter (1):
  drm/amdkfd: uninitialized variable in dbgdev_wave_control_set_registers()

 drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Bug 81924] No Audio over DisplayPort

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=81924

--- Comment #1 from J�rgen Scholz  ---
I am trying to use a displayport connection between a Tahiti XT R9 280X and my
monitor to output audio.

The initial report seems still valid: Using HDMI for audio works with the same
monitor and it does not with displayport.

Running aplay -D plughw:0,$i does not lead to audible sound. No error messages
though.

Trying to force audio on with xrandr --output DisplayPort-0 --set audio on does
not work either.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/b3c78ad1/attachment-0001.html>

[PATCH 2/2] drm/atmel-hlcdc: use helper to get crtc state

[Daniel Vetter]

On Tue, Mar 15, 2016 at 02:08:05PM +0100, Boris Brezillon wrote:
> On Tue, 15 Mar 2016 14:07:46 +0100
> Daniel Vetter  wrote:
> 
> > On Tue, Mar 15, 2016 at 01:50:09PM +0100, Boris Brezillon wrote:
> > > On Tue, 15 Mar 2016 13:46:28 +0100
> > > Andrzej Hajda  wrote:
> > > 
> > > > DRM core provide helper to access crtc state.
> > > > 
> > > > Signed-off-by: Andrzej Hajda 
> > > 
> > > Acked-by: Boris Brezillon 
> > 
> > Want me to pull this in through drm-misc?
> 
> Yes please.

Both patches from Andrzej applied to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm/atmel-hlcdc: use helper to get crtc state

[Boris Brezillon]

On Tue, 15 Mar 2016 14:07:46 +0100
Daniel Vetter  wrote:

> On Tue, Mar 15, 2016 at 01:50:09PM +0100, Boris Brezillon wrote:
> > On Tue, 15 Mar 2016 13:46:28 +0100
> > Andrzej Hajda  wrote:
> > 
> > > DRM core provide helper to access crtc state.
> > > 
> > > Signed-off-by: Andrzej Hajda 
> > 
> > Acked-by: Boris Brezillon 
> 
> Want me to pull this in through drm-misc?

Yes please.



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 2/2] drm/atmel-hlcdc: use helper to get crtc state

[Daniel Vetter]

On Tue, Mar 15, 2016 at 01:50:09PM +0100, Boris Brezillon wrote:
> On Tue, 15 Mar 2016 13:46:28 +0100
> Andrzej Hajda  wrote:
> 
> > DRM core provide helper to access crtc state.
> > 
> > Signed-off-by: Andrzej Hajda 
> 
> Acked-by: Boris Brezillon 

Want me to pull this in through drm-misc?
-Daniel

> 
> > ---
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> > b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > index 1ffe9c3..d65dcae 100644
> > --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> > @@ -558,7 +558,7 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> > drm_plane *p,
> > if (!state->base.crtc || !fb)
> > return 0;
> >  
> > -   crtc_state = s->state->crtc_states[drm_crtc_index(s->crtc)];
> > +   crtc_state = drm_atomic_get_existing_crtc_state(s->state, s->crtc);
> > mode = _state->adjusted_mode;
> >  
> > state->src_x = s->src_x;
> 
> 
> 
> -- 
> Boris Brezillon, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/2] drm/atmel-hlcdc: use helper to get crtc state

[Boris Brezillon]

On Tue, 15 Mar 2016 13:46:28 +0100
Andrzej Hajda  wrote:

> DRM core provide helper to access crtc state.
> 
> Signed-off-by: Andrzej Hajda 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 1ffe9c3..d65dcae 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -558,7 +558,7 @@ static int atmel_hlcdc_plane_atomic_check(struct 
> drm_plane *p,
>   if (!state->base.crtc || !fb)
>   return 0;
>  
> - crtc_state = s->state->crtc_states[drm_crtc_index(s->crtc)];
> + crtc_state = drm_atomic_get_existing_crtc_state(s->state, s->crtc);
>   mode = _state->adjusted_mode;
>  
>   state->src_x = s->src_x;



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 2/2] drm/atmel-hlcdc: use helper to get crtc state

[Andrzej Hajda]

DRM core provide helper to access crtc state.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index 1ffe9c3..d65dcae 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -558,7 +558,7 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane 
*p,
if (!state->base.crtc || !fb)
return 0;

-   crtc_state = s->state->crtc_states[drm_crtc_index(s->crtc)];
+   crtc_state = drm_atomic_get_existing_crtc_state(s->state, s->crtc);
mode = _state->adjusted_mode;

state->src_x = s->src_x;
-- 
1.9.1

[PATCH 1/2] drm/atomic: use helper to get crtc state

[Andrzej Hajda]

DRM core provide helper to access crtc state.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/drm_atomic_helper.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 2b430b0..e1cbba6 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -67,7 +67,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
struct drm_crtc_state *crtc_state;

if (plane->state->crtc) {
-   crtc_state = 
state->crtc_states[drm_crtc_index(plane->state->crtc)];
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
plane->state->crtc);

if (WARN_ON(!crtc_state))
return;
@@ -76,8 +77,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}

if (plane_state->crtc) {
-   crtc_state =
-   state->crtc_states[drm_crtc_index(plane_state->crtc)];
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
plane_state->crtc);

if (WARN_ON(!crtc_state))
return;
@@ -366,8 +367,8 @@ mode_fixup(struct drm_atomic_state *state)
if (!conn_state->crtc || !conn_state->best_encoder)
continue;

-   crtc_state =
-   state->crtc_states[drm_crtc_index(conn_state->crtc)];
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
conn_state->crtc);

/*
 * Each encoder has at most one connector (since we always steal
@@ -666,7 +667,8 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
if (!old_conn_state->crtc)
continue;

-   old_crtc_state = 
old_state->crtc_states[drm_crtc_index(old_conn_state->crtc)];
+   old_crtc_state = drm_atomic_get_existing_crtc_state(old_state,
+   
old_conn_state->crtc);

if (!old_crtc_state->active ||
!drm_atomic_crtc_needs_modeset(old_conn_state->crtc->state))
-- 
1.9.1

[RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture

[Marek Szyprowski]

Hello,

On 2016-03-15 12:18, Magnus Damm wrote:
> Hi Marek,
>
> On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
>  wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this change is a switch from bitmap-based IO address space
>> management to tree-based code. There should be no functional changes
>> for drivers, which rely on initialization from generic arch_setup_dna_ops()
>> interface. Code, which used old arm_iommu_* functions must be updated to
>> new interface.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
> Thanks for your efforts and my apologies for late comments. Just FYI
> I'll try your patch (and this series) with the ipmmu-vmsa.c driver on
> 32-bit ARM and see how it goes. Nice not to have to support multiple
> interfaces depending on architecture!

Thanks for testing!

> One question that comes to mind is how to handle features.
>
> For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS
> while the shared code in drivers/iommu/dma-iommu.c does not. I assume
> existing users may rely on such features so from my point of view it
> probably makes sense to carry over features from the 32-bit ARM code
> into the shared code before pulling the plug.

Right, this has to be added to common code before merging.

> I also wonder if it is possible to do a step-by-step migration and
> support both old and new interfaces in the same binary? That may make
> things easier for multiplatform enablement. So far I've managed to
> make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some
> ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with
> the shared code in drivers/iommu/dma-iommu.c may also be possible. And
> probably involving even more ugly magic. =)

Having one IOMMU driver for both 32-bit and 64-bit ARM archs is quite easy
IF you rely on the iommu core to setup everything. See exynos-iommu driver
- after my last patches it now works fine on both archs (using arch
specific interfaces). Most of the magic is done automatically by
arch_setup_dma_ops().

The real problem is the fact that there are drivers (like DRM) which rely
on specific dma-mapping functions from ARM architecture, which need to be
rewritten.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

[PATCH] amdgpu: add amdgpu_create_bo_from_userptr()

[Michel Dänzer]

On 11.03.2016 23:38, Christian König wrote:
> From: Christian König 
> 
> We somehow forgot the flags paramter in amdgpu_create_bo_from_user_mem(). Fix
> that with a new function.
> 
> Signed-off-by: Christian König 

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] drm/radeon: hold reference to fences in radeon_sa_bo_new (3.17 and older)

[Nicolai Hähnle]

From: Nicolai Hähnle 

[Backport of upstream commit f6ff4f67cdf8455d0a4226eeeaf5af17c37d05eb, with
 an additional NULL pointer guard that is required for kernels 3.17 and older.

 To be precise, any kernel that does *not* have commit 954605ca3 "drm/radeon:
 use common fence implementation for fences, v4" requires this additional
 NULL pointer guard.]

An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle 
Reviewed-by: Christian König  (v1 + fix)
Tested-by: Lutz Euler 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_sa.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index c507896..7d11901 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -349,8 +349,15 @@ int radeon_sa_bo_new(struct radeon_device *rdev,
/* see if we can skip over some allocations */
} while (radeon_sa_bo_next_hole(sa_manager, fences, tries));

+   for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+   if (fences[i])
+   radeon_fence_ref(fences[i]);
+   }
+
spin_unlock(_manager->wq.lock);
r = radeon_fence_wait_any(rdev, fences, false);
+   for (i = 0; i < RADEON_NUM_RINGS; ++i)
+   radeon_fence_unref([i]);
spin_lock(_manager->wq.lock);
/* if we have nothing to wait for block */
if (r == -ENOENT) {
-- 
2.5.0

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Bastien Nocera]

On Tue, 2016-03-15 at 21:10 +1000, Dave Airlie wrote:
> > 
> > 
> > I guess that's only useful until we get runtime PM support.
> For the discrete GPUs on regular laptops we have runtime PM support
> for
> powerdown already. Some newer laptops need a bit of work in the PCIE
> layer
> but for most things we have it covered. The known broken ones are
> Apple
> laptops. If the apple-gmux code is working well enough to power off
> GPUs,
> then it should be possible to hook up runtime-pm on those machines
> pretty
> simply.
> 
> So there shouldn't really be a case we care about.
> 
> runtime PM for the Intel GPU isn't as important. We don't even want
> to
> turn the i915 fully off anymore.

Fair enough. And it's not that big a problem if we want to try and run
the compositor on the integrated card by default either.

[PATCH v13 03/14] drm/mediatek: Add DSI sub driver

[Philipp Zabel]

Hi Daniel,

Am Mittwoch, den 09.03.2016, 22:07 +0800 schrieb Daniel Kurtz:
> Hi Philipp, CK,
> 
> Some small comments.
> Nothing that couldn't be addressed after merging, if you prefer.
> 
> On Tue, Mar 8, 2016 at 9:27 PM, Philipp Zabel  
> wrote:
[...]
> > +static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> > +{
> > +   struct device *dev = dsi->dev;
> > +   int ret;
> > +
> > +   if (++dsi->refcount != 1)
> > +   return 0;
> 
> What is the point of this refcount?
> I believe dsi->enabled already ensures poweron/poweroff calls are paired.

mtk_dsi_poweron() is called from both mtk_dsi_encoder_enable() and
mtk_dsi_ddp_start() and enables just enough of the DSI to provide power
and the pixel clock. The reason is that the DSI also provides the pixel
clock to the rest of the pipeline elements.

dsi->enabled only tracks the whole DSI being active after the call of
mtk_dsi_encoder_enable().

[...]
> > +static int mtk_dsi_create_conn_enc(struct drm_device *drm, struct mtk_dsi 
> > *dsi)
> > +{
> > +   int ret;
> > +
> > +   ret = drm_encoder_init(drm, >encoder, _dsi_encoder_funcs,
> > +  DRM_MODE_ENCODER_DSI, NULL);
> > +   if (ret) {
> > +   DRM_ERROR("Failed to encoder init to drm\n");
> > +   return ret;
> > +   }
> > +   drm_encoder_helper_add(>encoder, 
> > _dsi_encoder_helper_funcs);
> > +
> > +   /*
> > +* Currently display data paths are statically assigned to a crtc 
> > each.
> > +* crtc 0 is OVL0 -> COLOR0 -> AAL -> OD -> RDMA0 -> UFOE -> DSI0
> > +*/
> > +   dsi->encoder.possible_crtcs = 1;
> > +
> > +   /* Pre-empt DP connector creation if there's a bridge */
> > +   ret = mtk_drm_attach_bridge(dsi->bridge, >encoder);
> > +   if (!ret)
> > +   return 0;
> 
> nit: the above valid early termination of this function here is a bit unusual.
> It might be more clear if the "connector init" part below was split out into 
> its
> own helper function.

Good point, will do that.

[...]
> > +static int mtk_dsi_remove(struct platform_device *pdev)
> > +{
> > +   struct mtk_dsi *dsi = platform_get_drvdata(pdev);
> > +
> > +   mtk_output_dsi_disable(dsi);
> 
> This one looks unmatched.

It is, indeed we should let the drm core disable the encoder before the
driver is removed.

[...]
> > +static int mtk_dsi_resume(struct device *dev)
> > +{
> > +   struct mtk_dsi *dsi;
> > +
> > +   dsi = dev_get_drvdata(dev);
> > +
> > +   mtk_output_dsi_enable(dsi);
> > +   DRM_DEBUG_DRIVER("dsi resume success!\n");
> > +
> > +   return 0;
> > +}
> > +#endif
> > +static SIMPLE_DEV_PM_OPS(mtk_dsi_pm_ops, mtk_dsi_suspend, mtk_dsi_resume);
> 
> I don't think we want PM ops.
> The MTK DRM driver disables/enables encoders during suspend/resume.

Yes, and that will also allow to merge mtk_output_dsi_disable() into
mtk_dsi_encoder_disable(), too.

[...]
> > +static unsigned long mtk_mipi_tx_pll_recalc_rate(struct clk_hw *hw,
> > +unsigned long parent_rate)
> > +{
> > +   struct mtk_mipi_tx *mipi_tx = container_of(hw, struct mtk_mipi_tx,
> > +  pll_hw);
> 
> An inline function / macro would help here.

Ok.

[...]
> > +static void mtk_mipi_tx_power_off_signal(struct phy *phy)
> > +{
> > +   struct mtk_mipi_tx *mipi_tx = phy_get_drvdata(phy);
> > +
> > +   mtk_mipi_tx_mask(mipi_tx, MIPITX_DSI_TOP_CON, RG_DSI_PAD_TIE_LOW_EN,
> > +RG_DSI_PAD_TIE_LOW_EN);
> 
> As mentioned in the HDMI review, _set_bits() / _clr_bits() is more readable 
> than
> _mask() if we are just setting/clearing groups of bits.

I don't think
mtk_mipi_tx_set_bits(mipi_tx, MIPITX_DSI_TOP_CON,
 RG_DSI_PAD_TIE_LOW_EN);
is that much easier to read. How about calling the function
mtk_mipi_tx_update_bits instead?

regards
Philipp

[PATCH v13 04/14] drm/mediatek: Add DPI sub driver

[Philipp Zabel]

Hi Daniel,

Am Mittwoch, den 09.03.2016, 22:23 +0800 schrieb Daniel Kurtz:
> Hi Philipp, Jie,
> 
> Some small comments.
> Nothing that can't be fixed after merging if you prefer.
>
> On Tue, Mar 8, 2016 at 9:27 PM, Philipp Zabel  
> wrote:
[...]
> > +static int mtk_dpi_power_on(struct mtk_dpi *dpi, enum mtk_dpi_power_ctl 
> > pctl)
> > +{
> > +   int ret;
> > +
> > +   dpi->power_ctl |= pctl;
> > +
> > +   if (!(dpi->power_ctl & DPI_POWER_START) &&
> > +   !((dpi->power_ctl & DPI_POWER_ENABLE) &&
> > + ((dpi->power_ctl & DPI_POWER_RESUME
> 
> There one too many () on the POWER_RESUME clause.

I'll try to remove the suspend ops and this with them.

[...]
> > +static SIMPLE_DEV_PM_OPS(mtk_dpi_pm_ops, mtk_dpi_suspend, mtk_dpi_resume);
> 
> Like hdmi & dsi, I think we can remove these PM routines.
> And maybe then we can remove the "DPI_POWER_RESUME" logic (which I
> don't grok yet)?

Right, also we probably should use drm_atomic_helper_suspend/resume in
mtk_drm_sys_suspend/resume.

[...]
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.h 
> > b/drivers/gpu/drm/mediatek/mtk_dpi.h
> > new file mode 100644
> > index 000..4fa4114
> > --- /dev/null
> > +++ b/drivers/gpu/drm/mediatek/mtk_dpi.h
> 
> All of this can be moved to mtk_dpi.c.

Ok, I'll merge this into mtk_dpi.c.

regards
Philipp

[PATCH] drm/exynos: build fbdev code conditionally

[Andrzej Hajda]

Fbdev code should be compiled only if CONFIG_DRM_FBDEV_EMULATION option
is enabled. The patch fixes exynos-drm code trying to manipulate
fbdev data which is not initialized in case CONFIG_DRM_FBDEV_EMULATION
is disabled.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/Makefile   |  6 +++---
 drivers/gpu/drm/exynos/exynos_drm_fb.c| 11 ---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 11 +++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 23 ++-
 4 files changed, 36 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 968b31c..23d2f95 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -2,10 +2,10 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.

-exynosdrm-y := exynos_drm_drv.o exynos_drm_crtc.o exynos_drm_fbdev.o \
-   exynos_drm_fb.o exynos_drm_gem.o exynos_drm_core.o \
-   exynos_drm_plane.o
+exynosdrm-y := exynos_drm_drv.o exynos_drm_crtc.o exynos_drm_fb.o \
+   exynos_drm_gem.o exynos_drm_core.o exynos_drm_plane.o

+exynosdrm-$(CONFIG_DRM_FBDEV_EMULATION) += exynos_drm_fbdev.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_IOMMU) += exynos_drm_iommu.o
 exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)+= exynos_drm_fimd.o
 exynosdrm-$(CONFIG_DRM_EXYNOS5433_DECON)   += exynos5433_drm_decon.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index d614194..81cc553 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -199,17 +199,6 @@ dma_addr_t exynos_drm_fb_dma_addr(struct drm_framebuffer 
*fb, int index)
return exynos_fb->dma_addr[index];
 }

-static void exynos_drm_output_poll_changed(struct drm_device *dev)
-{
-   struct exynos_drm_private *private = dev->dev_private;
-   struct drm_fb_helper *fb_helper = private->fb_helper;
-
-   if (fb_helper)
-   drm_fb_helper_hotplug_event(fb_helper);
-   else
-   exynos_drm_fbdev_init(dev);
-}
-
 static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = exynos_drm_output_poll_changed,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 4ae860c..72d7c0b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -317,3 +317,14 @@ void exynos_drm_fbdev_restore_mode(struct drm_device *dev)

drm_fb_helper_restore_fbdev_mode_unlocked(private->fb_helper);
 }
+
+void exynos_drm_output_poll_changed(struct drm_device *dev)
+{
+   struct exynos_drm_private *private = dev->dev_private;
+   struct drm_fb_helper *fb_helper = private->fb_helper;
+
+   if (fb_helper)
+   drm_fb_helper_hotplug_event(fb_helper);
+   else
+   exynos_drm_fbdev_init(dev);
+}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
index e16d7f0..330eef8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
@@ -15,9 +15,30 @@
 #ifndef _EXYNOS_DRM_FBDEV_H_
 #define _EXYNOS_DRM_FBDEV_H_

+#ifdef CONFIG_DRM_FBDEV_EMULATION
+
 int exynos_drm_fbdev_init(struct drm_device *dev);
-int exynos_drm_fbdev_reinit(struct drm_device *dev);
 void exynos_drm_fbdev_fini(struct drm_device *dev);
 void exynos_drm_fbdev_restore_mode(struct drm_device *dev);
+void exynos_drm_output_poll_changed(struct drm_device *dev);
+
+#else
+
+static inline int exynos_drm_fbdev_init(struct drm_device *dev)
+{
+   return 0;
+}
+
+static inline void exynos_drm_fbdev_fini(struct drm_device *dev)
+{
+}
+
+static inline void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
+{
+}
+
+#define exynos_drm_output_poll_changed (NULL)
+
+#endif

 #endif
-- 
1.9.1

[PATCH] drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set

[Andrzej Hajda]

exynos_plane_mode_set should use adjusted_mode from the same atomic state as
plane state. Otherwise it will result in incorrect behavior in case
crtc mode changes.

The patch fixes bug with black console framebuffer in case of command mode
panels.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index d8622723..50185ac 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -11,9 +11,10 @@

 #include 

-#include 
-#include 
+#include 
 #include 
+#include 
+#include 
 #include "exynos_drm_drv.h"
 #include "exynos_drm_crtc.h"
 #include "exynos_drm_fb.h"
@@ -57,11 +58,12 @@ static int exynos_plane_get_size(int start, unsigned 
length, unsigned last)
 }

 static void exynos_plane_mode_set(struct exynos_drm_plane_state *exynos_state)
-
 {
struct drm_plane_state *state = _state->base;
-   struct drm_crtc *crtc = exynos_state->base.crtc;
-   struct drm_display_mode *mode = >state->adjusted_mode;
+   struct drm_crtc *crtc = state->crtc;
+   struct drm_crtc_state *crtc_state =
+   drm_atomic_get_existing_crtc_state(state->state, crtc);
+   struct drm_display_mode *mode = _state->adjusted_mode;
int crtc_x, crtc_y;
unsigned int crtc_w, crtc_h;
unsigned int src_x, src_y;
-- 
1.9.1

[RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture

[Robin Murphy]

Hi Marek, Arnd,

On 19/02/16 10:30, Arnd Bergmann wrote:
> On Friday 19 February 2016 09:22:44 Marek Szyprowski wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this change is a switch from bitmap-based IO address space
>> management to tree-based code. There should be no functional changes
>> for drivers, which rely on initialization from generic arch_setup_dna_ops()
>> interface. Code, which used old arm_iommu_* functions must be updated to
>> new interface.
>>
>> Signed-off-by: Marek Szyprowski 
>
> I like the overall idea. However, this interface from the iommu
> subsystem into architecture specific code:
>
>> +/*
>> + * The DMA API is built upon the notion of "buffer ownership".  A buffer
>> + * is either exclusively owned by the CPU (and therefore may be accessed
>> + * by it) or exclusively owned by the DMA device.  These helper functions
>> + * represent the transitions between these two ownership states.
>> + *
>> + * Note, however, that on later ARMs, this notion does not work due to
>> + * speculative prefetches.  We model our approach on the assumption that
>> + * the CPU does do speculative prefetches, which means we clean caches
>> + * before transfers and delay cache invalidation until transfer completion.
>> + *
>> + */
>> +extern void __dma_page_cpu_to_dev(struct page *, unsigned long, size_t,
>> +  enum dma_data_direction);
>> +extern void __dma_page_dev_to_cpu(struct page *, unsigned long, size_t,
>> +  enum dma_data_direction);
>> +
>> +static inline void arch_flush_page(struct device *dev, const void *virt,
>> +phys_addr_t phys)
>> +{
>> +dmac_flush_range(virt, virt + PAGE_SIZE);
>> +outer_flush_range(phys, phys + PAGE_SIZE);
>> +}
>> +
>> +static inline void arch_dma_map_area(phys_addr_t phys, size_t size,
>> + enum dma_data_direction dir)
>> +{
>> +unsigned int offset = phys & ~PAGE_MASK;
>> +__dma_page_cpu_to_dev(phys_to_page(phys & PAGE_MASK), offset, size, 
>> dir);
>> +}
>> +
>> +static inline void arch_dma_unmap_area(phys_addr_t phys, size_t size,
>> +   enum dma_data_direction dir)
>> +{
>> +unsigned int offset = phys & ~PAGE_MASK;
>> +__dma_page_dev_to_cpu(phys_to_page(phys & PAGE_MASK), offset, size, 
>> dir);
>> +}
>> +
>> +static inline pgprot_t arch_get_dma_pgprot(struct dma_attrs *attrs,
>> +pgprot_t prot, bool coherent)
>> +{
>> +if (coherent)
>> +return prot;
>> +
>> +prot = dma_get_attr(DMA_ATTR_WRITE_COMBINE, attrs) ?
>> +pgprot_writecombine(prot) :
>> +pgprot_dmacoherent(prot);
>> +return prot;
>> +}
>> +
>> +extern void *arch_alloc_from_atomic_pool(size_t size, struct page 
>> **ret_page,
>> + gfp_t flags);
>> +extern bool arch_in_atomic_pool(void *start, size_t size);
>> +extern int arch_free_from_atomic_pool(void *start, size_t size);
>> +
>> +
>
> doesn't feel completely right yet. In particular the arch_flush_page()
> interface is probably still too specific to ARM/ARM64 and won't work
> that way on other architectures.
>
> I think it would be better to do this either more generic, or less generic:
>
> a) leave the iommu_dma_map_ops definition in the architecture specific
> code, but make it call helper functions in the drivers/iommu to do all
> of the really generic parts.

This was certainly the original intent of the arm64 code. The division 
of responsibility there is a conscious decision - IOMMU-API-wrangling 
goes in the common code, cache maintenance and actual dma_map_ops stay 
hidden in architecture-private code, safe from abuse. It's very much 
modelled on SWIOTLB.

Given all the work Russell did last year getting rid of direct uses of 
the dmac_* cache maintenance functions by ARM drivers, I don't think 
bringing all of that back is a good way to go - Personally I'd much 
rather see several dozen lines of very similar looking (other than 
highmem and outer cache stuff) arch-private code if it maintains a 
robust and clearly-defined abstraction (and avoids yet another level of 
indirection). It does also seem a little odd to factor out only half the 
file on the grounds of architectural similarity, when that argument 
applies equally to the other (non-IOMMU) half too. I think the recent 
tree-wide conversion to generic dma_map_ops was in part motivated by the 
thought of common implementations, so I'm sure that's something we can 
revisit in due course.

Robin.

>
> b) clarify that this is only applicable to arch/arm and arch/arm64, and
> unify things further between these two, as they have very similar
> requirements in the CPU architecture.
>
>   Arnd
> ___

[RFC 3/3] iommu: dma-iommu: use common implementation also on ARM architecture

[Robin Murphy]

Hi Magnus,

On 15/03/16 11:18, Magnus Damm wrote:
> Hi Marek,
>
> On Fri, Feb 19, 2016 at 5:22 PM, Marek Szyprowski
>  wrote:
>> This patch replaces ARM-specific IOMMU-based DMA-mapping implementation
>> with generic IOMMU DMA-mapping code shared with ARM64 architecture. The
>> side-effect of this change is a switch from bitmap-based IO address space
>> management to tree-based code. There should be no functional changes
>> for drivers, which rely on initialization from generic arch_setup_dna_ops()
>> interface. Code, which used old arm_iommu_* functions must be updated to
>> new interface.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>
> Thanks for your efforts and my apologies for late comments. Just FYI
> I'll try your patch (and this series) with the ipmmu-vmsa.c driver on
> 32-bit ARM and see how it goes. Nice not to have to support multiple
> interfaces depending on architecture!
>
> One question that comes to mind is how to handle features.
>
> For instance, the 32-bit ARM code supports DMA_ATTR_FORCE_CONTIGUOUS
> while the shared code in drivers/iommu/dma-iommu.c does not. I assume
> existing users may rely on such features so from my point of view it
> probably makes sense to carry over features from the 32-bit ARM code
> into the shared code before pulling the plug.

Indeed - the patch I posted the other day doing proper scatterlist 
merging in the common code is largely to that end.

> I also wonder if it is possible to do a step-by-step migration and
> support both old and new interfaces in the same binary? That may make
> things easier for multiplatform enablement. So far I've managed to
> make one IOMMU driver support both 32-bit ARM and 64-bit ARM with some
> ugly magic, so adjusting 32-bit ARM dma-mapping code to coexist with
> the shared code in drivers/iommu/dma-iommu.c may also be possible. And
> probably involving even more ugly magic. =)

That was also my thought when I tried to look at this a while ago - I 
started on some patches moving the bitmap from dma_iommu_mapping into 
the iommu_domain->iova_cookie so that the existing code and users could 
then be converted to just passing iommu_domains around, after which it 
should be fairly painless to swap out the back-end implementation 
transparently. That particular effort ground to a halt upon realising 
the number of the IOMMU and DRM drivers I'd have no way of testing - if 
you're interested I've dug out the diff below from an old 
work-in-progress branch (which probably doesn't even compile).

Robin.

>
> Cheers,
>
> / magnus

--->8---
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 4111592..6ea939c 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -14,9 +14,6 @@ struct dev_archdata {
  #ifdef CONFIG_IOMMU_API
void *iommu; /* private IOMMU data */
  #endif
-#ifdef CONFIG_ARM_DMA_USE_IOMMU
-   struct dma_iommu_mapping*mapping;
-#endif
bool dma_coherent;
  };

@@ -28,10 +25,4 @@ struct pdev_archdata {
  #endif
  };

-#ifdef CONFIG_ARM_DMA_USE_IOMMU
-#define to_dma_iommu_mapping(dev) ((dev)->archdata.mapping)
-#else
-#define to_dma_iommu_mapping(dev) NULL
-#endif
-
  #endif
diff --git a/arch/arm/include/asm/dma-iommu.h 
b/arch/arm/include/asm/dma-iommu.h
index 2ef282f..e15197d 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -24,13 +24,12 @@ struct dma_iommu_mapping {
struct kref kref;
  };

-struct dma_iommu_mapping *
+struct iommu_domain *
  arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64 size);

-void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
+void arm_iommu_release_mapping(struct iommu_domain *mapping);

-int arm_iommu_attach_device(struct device *dev,
-   struct dma_iommu_mapping *mapping);
+int arm_iommu_attach_device(struct device *dev, struct iommu_domain 
*mapping);
  void arm_iommu_detach_device(struct device *dev);

  #endif /* __KERNEL__ */
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index e62400e..dfb5001 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1246,7 +1246,8 @@ __iommu_alloc_remap(struct page **pages, size_t 
size, gfp_t gfp, pgprot_t prot,
  static dma_addr_t
  __iommu_create_mapping(struct device *dev, struct page **pages, size_t 
size)
  {
-   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
+   struct iommu_domain *dom = iommu_get_domain_for_dev(dev);
+   struct dma_iommu_mapping *mapping = dom->iova_cookie;
unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
dma_addr_t dma_addr, iova;
int i;
@@ -1268,8 +1269,7 @@ __iommu_create_mapping(struct device *dev, struct 
page **pages, size_t size)
break;

len = (j - i) << PAGE_SHIFT;
-   ret = iommu_map(mapping->domain, iova, phys, len,
-   

[PATCH 13/14] drm: Adjust the maximum value of suggested [X|Y] properties

[Thomas Hellstrom]

On 03/15/2016 10:23 AM, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 09:32:22AM +0100, Thomas Hellstrom wrote:
>> On 03/15/2016 09:14 AM, Daniel Vetter wrote:
>>> On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
 X re-export these values as 32-bit, so they end up as -1.

 Signed-off-by: Thomas Hellstrom 
>>> Imo that's a bug in X, and X should clamp the range itself. Not the
>>> kernel. Prop abi is pretty consistent that its all 64bit values.
>>> -Daniel
>> True. Otoh, we can't really change old X servers to support this, and
>> the range doesn't really need to be that large.
>> (It's already restricted to 32 bits and restricting it to 31 bits
>> doesn't make a big difference).
> Well if current X is fixed (we don't want to repeat this fun for other
> props) then I'm ok with this, with a comment. Just want to avoid working
> around bugs in other software for no good reason.
> -Daniel

Actually, thinking of it, this only affects the modesetting driver
currently. For the vmwgfx driver the re-exporting of kernel properties
hasn't been formally released yet, so I can just limit the range in
vmwgfx, which is the driver we care most about.

That means I'll be dropping this commit.

/Thomas




>
>> /Thomas
>>
>>
 ---
  drivers/gpu/drm/drm_crtc.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 8451400..a27b2e0 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -1789,10 +1789,10 @@ int 
 drm_mode_create_suggested_offset_properties(struct drm_device *dev)
return 0;
  
dev->mode_config.suggested_x_property =
 -  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
 "suggested X", 0, 0x);
 +  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
 "suggested X", 0, 0x7fff);
  
dev->mode_config.suggested_y_property =
 -  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
 "suggested Y", 0, 0x);
 +  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
 "suggested Y", 0, 0x7fff);
  
if (dev->mode_config.suggested_x_property == NULL ||
dev->mode_config.suggested_y_property == NULL)
 -- 
 2.5.0


 ___
 dri-devel mailing list
 dri-devel at lists.freedesktop.org
 https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=BQIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=tk1_0FQoUlZD2ybivU9sASZgACk0FHEeIHWhp07U3Z0=2G9Zzwff6weMglpvwYsaZF9e1ginaxM62nYFBU0x2Bs=
  

[PATCH 13/14] drm: Adjust the maximum value of suggested [X|Y] properties

[Daniel Vetter]

On Tue, Mar 15, 2016 at 10:23:04AM +0100, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 09:32:22AM +0100, Thomas Hellstrom wrote:
> > On 03/15/2016 09:14 AM, Daniel Vetter wrote:
> > > On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
> > >> X re-export these values as 32-bit, so they end up as -1.
> > >>
> > >> Signed-off-by: Thomas Hellstrom 
> > > Imo that's a bug in X, and X should clamp the range itself. Not the
> > > kernel. Prop abi is pretty consistent that its all 64bit values.
> > > -Daniel
> > 
> > True. Otoh, we can't really change old X servers to support this, and
> > the range doesn't really need to be that large.
> > (It's already restricted to 32 bits and restricting it to 31 bits
> > doesn't make a big difference).
> 
> Well if current X is fixed (we don't want to repeat this fun for other
> props) then I'm ok with this, with a comment. Just want to avoid working
> around bugs in other software for no good reason.

And S32_MAX for readability please, I can't count rows of fff ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 13/14] drm: Adjust the maximum value of suggested [X|Y] properties

[Daniel Vetter]

On Tue, Mar 15, 2016 at 09:32:22AM +0100, Thomas Hellstrom wrote:
> On 03/15/2016 09:14 AM, Daniel Vetter wrote:
> > On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
> >> X re-export these values as 32-bit, so they end up as -1.
> >>
> >> Signed-off-by: Thomas Hellstrom 
> > Imo that's a bug in X, and X should clamp the range itself. Not the
> > kernel. Prop abi is pretty consistent that its all 64bit values.
> > -Daniel
> 
> True. Otoh, we can't really change old X servers to support this, and
> the range doesn't really need to be that large.
> (It's already restricted to 32 bits and restricting it to 31 bits
> doesn't make a big difference).

Well if current X is fixed (we don't want to repeat this fun for other
props) then I'm ok with this, with a comment. Just want to avoid working
around bugs in other software for no good reason.
-Daniel

> 
> /Thomas
> 
> 
> >
> >> ---
> >>  drivers/gpu/drm/drm_crtc.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index 8451400..a27b2e0 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -1789,10 +1789,10 @@ int 
> >> drm_mode_create_suggested_offset_properties(struct drm_device *dev)
> >>return 0;
> >>  
> >>dev->mode_config.suggested_x_property =
> >> -  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> >> "suggested X", 0, 0x);
> >> +  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> >> "suggested X", 0, 0x7fff);
> >>  
> >>dev->mode_config.suggested_y_property =
> >> -  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> >> "suggested Y", 0, 0x);
> >> +  drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> >> "suggested Y", 0, 0x7fff);
> >>  
> >>if (dev->mode_config.suggested_x_property == NULL ||
> >>dev->mode_config.suggested_y_property == NULL)
> >> -- 
> >> 2.5.0
> >>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=BQIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=tk1_0FQoUlZD2ybivU9sASZgACk0FHEeIHWhp07U3Z0=2G9Zzwff6weMglpvwYsaZF9e1ginaxM62nYFBU0x2Bs=
> >>  
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 13/14] drm: Adjust the maximum value of suggested [X|Y] properties

[Thomas Hellstrom]

On 03/15/2016 09:14 AM, Daniel Vetter wrote:
> On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
>> X re-export these values as 32-bit, so they end up as -1.
>>
>> Signed-off-by: Thomas Hellstrom 
> Imo that's a bug in X, and X should clamp the range itself. Not the
> kernel. Prop abi is pretty consistent that its all 64bit values.
> -Daniel

True. Otoh, we can't really change old X servers to support this, and
the range doesn't really need to be that large.
(It's already restricted to 32 bits and restricting it to 31 bits
doesn't make a big difference).

/Thomas


>
>> ---
>>  drivers/gpu/drm/drm_crtc.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 8451400..a27b2e0 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -1789,10 +1789,10 @@ int 
>> drm_mode_create_suggested_offset_properties(struct drm_device *dev)
>>  return 0;
>>  
>>  dev->mode_config.suggested_x_property =
>> -drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
>> "suggested X", 0, 0x);
>> +drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
>> "suggested X", 0, 0x7fff);
>>  
>>  dev->mode_config.suggested_y_property =
>> -drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
>> "suggested Y", 0, 0x);
>> +drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
>> "suggested Y", 0, 0x7fff);
>>  
>>  if (dev->mode_config.suggested_x_property == NULL ||
>>  dev->mode_config.suggested_y_property == NULL)
>> -- 
>> 2.5.0
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=BQIBAg=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA=tk1_0FQoUlZD2ybivU9sASZgACk0FHEeIHWhp07U3Z0=2G9Zzwff6weMglpvwYsaZF9e1ginaxM62nYFBU0x2Bs=
>>  

linux-next: Tree for Mar 14

[Sergey Senozhatsky]

On (03/14/16 17:40), Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160311:
> 
> The vfs tree gained a conflict against Linus' tree. I also applied a
> patch for a known runtime bug.
> 
> The tip tree gained a conflict against the mips tree.
> 
> The aio tree still had a build failure so I removed several commits
> from it.  It also gained a conflict against the vfs tree.
> 
> Non-merge commits (relative to Linus' tree): 11202
>  8646 files changed, 426680 insertions(+), 211740 deletions(-)


Hello,

I'm seeing a bunch of warnings and errors

[0.697413] [ cut here ]
[0.697484] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.c:1533 
i2c_register_adapter+0x37/0x367
[0.697560] Modules linked in:
[0.697654] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.5.0-rc7-next-20160314-dbg-00015-gd1f304e-dirty #271
[0.697817]   8801330cf9e8 8124795a 

[0.698029]   8801330cfa28 810444e4 
05fd330cf8d8
[0.698239]  8800bf4b50a8  fff5 
81426c47
[0.698449] Call Trace:
[0.698505]  [] dump_stack+0x67/0x90
[0.698565]  [] __warn+0xc2/0xdd
[0.698623]  [] ? i2c_register_adapter+0x367/0x367
[0.698683]  [] warn_slowpath_null+0x1d/0x1f
[0.698743]  [] i2c_register_adapter+0x37/0x367
[0.698803]  [] ? i2c_register_adapter+0x367/0x367
[0.698863]  [] i2c_add_adapter+0x60/0x65
[0.698922]  [] __i2c_bit_add_bus+0x294/0x2f3
[0.698981]  [] i2c_bit_add_bus+0x15/0x17
[0.699041]  [] nvkm_i2c_bus_ctor+0x1bb/0x1dd
[0.699100]  [] nv50_i2c_bus_new+0xa6/0xd0
[0.699160]  [] nvkm_i2c_new_+0x220/0x57c
[0.699219]  [] ? nvkm_gpio_new_+0x7b/0x86
[0.699278]  [] g94_i2c_new+0x1d/0x1f
[0.699337]  [] nvkm_device_ctor+0x100e/0x2211
[0.699397]  [] nvkm_device_pci_new+0x18c/0x19f
[0.699457]  [] nouveau_drm_probe+0x194/0x1d7
[0.699517]  [] pci_device_probe+0x85/0xee
[0.699578]  [] driver_probe_device+0x118/0x261
[0.699638]  [] __driver_attach+0x73/0x95
[0.699697]  [] ? driver_probe_device+0x261/0x261
[0.699757]  [] bus_for_each_dev+0x6f/0x87
[0.699815]  [] driver_attach+0x1e/0x20
[0.699874]  [] bus_add_driver+0xf2/0x1e4
[0.699932]  [] driver_register+0x8a/0xc6
[0.61]  [] __pci_register_driver+0x60/0x63
[0.700052]  [] drm_pci_init+0x50/0xd1
[0.700110]  [] ? ttm_init+0x60/0x60
[0.700168]  [] nouveau_drm_init+0x1f4/0x1f6
[0.700229]  [] do_one_initcall+0xe7/0x16c
[0.700290]  [] kernel_init_freeable+0x118/0x19e
[0.700351]  [] kernel_init+0xe/0xf0
[0.700409]  [] ret_from_fork+0x22/0x40
[0.700513]  [] ? rest_init+0x136/0x136
[0.700581] ---[ end trace e54473700ba2f16a ]---
[0.700643] [ cut here ]
[0.700701] WARNING: CPU: 0 PID: 1 at drivers/i2c/i2c-core.c:1533 
i2c_register_adapter+0x37/0x367
[0.700777] Modules linked in:
[0.700869] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW   
4.5.0-rc7-next-20160314-dbg-00015-gd1f304e-dirty #271
[0.701031]   8801330cf9e8 8124795a 

[0.701243]   8801330cfa28 810444e4 
05fd330cfa78
[0.701455]  8800bf4b58a8  fff5 
81426c47
[0.701667] Call Trace:
[0.701721]  [] dump_stack+0x67/0x90
[0.701779]  [] __warn+0xc2/0xdd
[0.701837]  [] ? i2c_register_adapter+0x367/0x367
[0.701897]  [] warn_slowpath_null+0x1d/0x1f
[0.701956]  [] i2c_register_adapter+0x37/0x367
[0.705165]  [] ? i2c_register_adapter+0x367/0x367
[0.705225]  [] i2c_add_adapter+0x60/0x65
[0.705284]  [] __i2c_bit_add_bus+0x294/0x2f3
[0.705343]  [] i2c_bit_add_bus+0x15/0x17
[0.705402]  [] nvkm_i2c_bus_ctor+0x1bb/0x1dd
[0.705461]  [] nv50_i2c_bus_new+0xa6/0xd0
[0.705520]  [] nvkm_i2c_new_+0x220/0x57c
[0.705580]  [] ? nvkm_gpio_new_+0x7b/0x86
[0.705639]  [] g94_i2c_new+0x1d/0x1f
[0.705698]  [] nvkm_device_ctor+0x100e/0x2211
[0.705757]  [] nvkm_device_pci_new+0x18c/0x19f
[0.705817]  [] nouveau_drm_probe+0x194/0x1d7
[0.705876]  [] pci_device_probe+0x85/0xee
[0.705935]  [] driver_probe_device+0x118/0x261
[0.705995]  [] __driver_attach+0x73/0x95
[0.706053]  [] ? driver_probe_device+0x261/0x261
[0.706113]  [] bus_for_each_dev+0x6f/0x87
[0.706172]  [] driver_attach+0x1e/0x20
[0.706230]  [] bus_add_driver+0xf2/0x1e4
[0.706289]  [] driver_register+0x8a/0xc6
[0.706347]  [] __pci_register_driver+0x60/0x63
[0.706407]  [] drm_pci_init+0x50/0xd1
[0.706486]  [] ? ttm_init+0x60/0x60
[0.706544]  [] nouveau_drm_init+0x1f4/0x1f6
[0.706603]  [] do_one_initcall+0xe7/0x16c
[0.706663]  [] kernel_init_freeable+0x118/0x19e
[0.706722]  [] kernel_init+0xe/0xf0
[0.706780]  [] ret_from_fork+0x22/0x40
[0.706838]  [] ? rest_init+0x136/0x136
[0.706906] ---[ end trace 

[PATCH v15 1/3] drm: rockchip: Add basic drm driver

[Mark yao]

On 2016年03月14日 21:35, Tomeu Vizoso wrote:
> On 2 December 2014 at 10:15, Mark Yao  wrote:
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> new file mode 100644
>> index 000..e7ca25b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -0,0 +1,1455 @@
> ...
>> +static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
>> +   const struct drm_display_mode *mode,
>> +   struct drm_display_mode *adjusted_mode)
>> +{
>> +   if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
>> +   return false;
> Hi Mark,
>
> what's the rationale for this?
>
> Disabling a CRTC as in [0] will cause mode_fixup() to be called with
> an empty mode, failing that test.
>
> Removing the check seems to get things working fine for a short while,
> but a later modeset invariably gets the VOP to hang (as reported by
> [1]).
>
> Do you know why that check was put in place and what exactly could be
> causing the hw to hang?
>
> [0] 
> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/lib/igt_kms.c#n1616
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/rockchip/rockchip_drm_vop.c#n873
>
> Thanks,
>
> Tomeu
>
Hi Tomeu

Just thinking that "adjusted_mode->htotal == 0 || adjusted_mode->vtotal 
== 0" is not a good mode for vop.

And you said VOP hang, only WARN_ON error message? or system hang, die?

I think maybe crtc disable too fast, vblank is off, then no one can feed the 
wait_update_complete.
Can you test it again with following patch?
drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -503,6 +503,8 @@ static void vop_crtc_disable(struct drm_crtc *crtc)
 if (!vop->is_enabled)
 return;

+   vop_crtc_wait_for_update(crtc);
+
 drm_crtc_vblank_off(crtc);

Thanks.

-- 
ï¼­ark Yao

[PATCH 13/14] drm: Adjust the maximum value of suggested [X|Y] properties

[Daniel Vetter]

On Tue, Mar 15, 2016 at 08:30:03AM +0100, Thomas Hellstrom wrote:
> X re-export these values as 32-bit, so they end up as -1.
> 
> Signed-off-by: Thomas Hellstrom 

Imo that's a bug in X, and X should clamp the range itself. Not the
kernel. Prop abi is pretty consistent that its all 64bit values.
-Daniel

> ---
>  drivers/gpu/drm/drm_crtc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8451400..a27b2e0 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1789,10 +1789,10 @@ int 
> drm_mode_create_suggested_offset_properties(struct drm_device *dev)
>   return 0;
>  
>   dev->mode_config.suggested_x_property =
> - drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> "suggested X", 0, 0x);
> + drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> "suggested X", 0, 0x7fff);
>  
>   dev->mode_config.suggested_y_property =
> - drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> "suggested Y", 0, 0x);
> + drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
> "suggested Y", 0, 0x7fff);
>  
>   if (dev->mode_config.suggested_x_property == NULL ||
>   dev->mode_config.suggested_y_property == NULL)
> -- 
> 2.5.0
> 
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/4 v3] drm: Add support of ARC PGU display controller

[Daniel Vetter]

On Mon, Mar 14, 2016 at 11:15:59AM +, Alexey Brodkin wrote:
> On Mon, 2016-03-14 at 08:00 +0100, Daniel Vetter wrote:
> > On Fri, Mar 11, 2016 at 06:42:36PM +0300, Alexey Brodkin wrote:
> > > +static int arcpgu_atomic_commit(struct drm_device *dev,
> > > +     struct drm_atomic_state *state, bool 
> > > async)
> > > +{
> > > + return drm_atomic_helper_commit(dev, state, false);
> > Note that this isn't really async if you ever get around to implement
> > fence support or vblank support. Just fyi.
> 
> Ok but for now should I leave it as it is?

Yeah ok as-is, hence just fyi.

> > > +static struct drm_driver arcpgu_drm_driver = {
> > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
> > > +    DRIVER_ATOMIC,
> > > + .preclose = arcpgu_preclose,
> > > + .lastclose = arcpgu_lastclose,
> > > + .name = "drm-arcpgu",
> > > + .desc = "ARC PGU Controller",
> > > + .date = "20160219",
> > > + .major = 1,
> > > + .minor = 0,
> > > + .patchlevel = 0,
> > > + .fops = _drm_ops,
> > > + .load = arcpgu_load,
> > > + .unload = arcpgu_unload,
> > Load and unload hooks are deprecated (it's a classic midlayer mistake).
> > Please use drm_dev_alloc/register pairs directly instead, and put your
> > device setup code in-between. Similar for unloading. There's a bunch of
> > example drivers converted already.
> 
> Ok I took "atmel-hlcdc" as example.
> And that's interesting.
> 
> If I put my arcpgu_load() in between drm_dev_alloc() and
> drm_dev_register() then I'm getting this on the driver probe:
> -->8---
> [drm] Initialized drm 1.1.0 20060810
> arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
> [ cut here ]
> WARNING: CPU: 0 PID: 1 at lib/kobject.c:244 kobject_add_internal+0x17c/0x498()
> kobject_add_internal failed for card0-HDMI-A-1 (error: -2 parent: card0)
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc3-01062-ga447822-dirty #17
> 
> Stack Trace:
>   arc_unwind_core.constprop.1+0xa4/0x110
>   warn_slowpath_fmt+0x6e/0xfc
>   kobject_add_internal+0x17c/0x498
>   kobject_add+0x98/0xe4
>   device_add+0xc6/0x734
>   device_create_with_groups+0x12a/0x144
>   drm_sysfs_connector_add+0x54/0xe8
>   arcpgu_drm_hdmi_init+0xd4/0x17c
>   arcpgu_probe+0x138/0x24c
>   platform_drv_probe+0x2e/0x6c
>   really_probe+0x212/0x35c
>   __driver_attach+0x90/0x94
>   bus_for_each_dev+0x46/0x80
>   bus_add_driver+0x14e/0x1b4
>   driver_register+0x64/0x108
>   do_one_initcall+0x86/0x194
>   kernel_init_freeable+0xf0/0x188
> ---[ end trace c67166ad43ddcce2 ]---
> [drm:drm_sysfs_connector_add] adding "HDMI-A-1" to sysfs
> [drm:drm_sysfs_connector_add] *ERROR* failed to register connector device: -2
> arcpgu e0017000.pgu: failed to regiter DRM connector and helper funcs
> arcpgu: probe of e0017000.pgu failed with error -2
> -->8---
> 
> But if I move arcpgu_load() after drm_dev_register() then everything
> starts properly and I may see HDMI screen works perfectly fine.
> 
> Any thoughts?

Oops, yeah missed that detail. If you look at atmel it has a loop to
register all the drm connectors _after_ calling drm_dev_register().
Totally forgot about that. Can you pls
- Extract a new drm_connector_register_all() function
  (atmel_hlcdc_dc_connector_plug_all seems to be the best template),
  including kerneldoc.
- Adjust kerneldoc of drm_dev_register() to mention
  drm_connector_register_all() and that ordering constraint.
- Roll that helper out to all the drivers that currently hand-roll it (one
  patch per driver).

I know a bit of work but imo not too much, and by doing some small
refactoring every time someone stumbles over a drm pitfall we keep the
subsystem clean to understand. You're up for this? Would be a prep
series, I'll happily review it to get it merged fast. Just a few weeks ago
I merged 20+ patches to make ->mode_fixup hooks optional and remove dummy
ones all over the subsystem, in other words: You'll have my full attention
;-)

> > > + .dumb_create = drm_gem_cma_dumb_create,
> > > + .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> > > + .dumb_destroy = drm_gem_dumb_destroy,
> > > + .get_vblank_counter = drm_vblank_no_hw_counter,
> > > + .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > > + .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > > + .gem_free_object = drm_gem_cma_free_object,
> > > + .gem_vm_ops = _gem_cma_vm_ops,
> > > + .gem_prime_export = drm_gem_prime_export,
> > > + .gem_prime_import = drm_gem_prime_import,
> > > + .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> > > + .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> > > + .gem_prime_vmap = drm_gem_cma_prime_vmap,
> > > + .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> > > + .gem_prime_mmap = drm_gem_cma_prime_mmap,
> > > +};
> > > +
> > > +static int arcpgu_probe(struct platform_device *pdev)

[PATCH] drm/etnaviv: move GPU linear window to end of DMA window

[Daniel Vetter]

On Mon, Mar 14, 2016 at 04:18:43PM +0100, Lucas Stach wrote:
> Am Montag, den 14.03.2016, 15:09 + schrieb Russell King - ARM Linux:
> > On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote:
> > > I guess not using the offset on MC10 will also allow you to enable TS on
> > > those parts? In that case we might advertise this with a patchlevel
> > > change of the API.
> > 
> > I don't think we need that - it isn't an API change as such.  What
> > we could do is to clear the fast clear capability for GPUs where the
> > base is non-zero but has MC10, which basically means we don't use
> > tile status.
> > 
> With kernel 4.5 being released now, we already have a kernel version
> that may change the offset, while not clearing the fast clear capability
> bit. So I think we need another way for userspace to know if the kernel
> is doing the right thing for MC10.

btw in drm land we're sometimes a bit sloppy with ABI - if it's just
rendering corruption or maybe oddball gpu hang and small enough to go in
through stable we don't bother to ref the ABI. Instead just ask everyone
to upgrade their kernel once the patch goes through the stable queues.

Otherwise even minor fumbles means ABI complexity forever, and with gpus
that tends to kill you ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina?MacBook Pro

[Daniel Vetter]

On Mon, Mar 14, 2016 at 02:37:44PM +0100, Bastien Nocera wrote:
> Do you have references for the i915 runtime PM support, a bugzilla or
> mailing-list thread?

i915.ko has runtime PM support, it's just not yet enabled by default due
to some funky corner cases. If you enable it you might hit a bunch of
sanity check warnings in dmesg. But besides those it should mostly work.
I didn't read the full context, just figured I'll throw this in.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v9] dma-buf: Add ioctls to allow userspace to flush

[Chris Wilson]

On Mon, Mar 14, 2016 at 05:21:10PM -0300, Tiago Vignatti wrote:
> On 03/05/2016 06:34 AM, Daniel Vetter wrote:
> >On Mon, Feb 29, 2016 at 03:02:09PM +, Chris Wilson wrote:
> >>On Mon, Feb 29, 2016 at 03:54:19PM +0100, Daniel Vetter wrote:
> >>>On Thu, Feb 25, 2016 at 06:01:22PM +, Chris Wilson wrote:
> On Thu, Feb 11, 2016 at 08:04:51PM -0200, Tiago Vignatti wrote:
> >+static long dma_buf_ioctl(struct file *file,
> >+  unsigned int cmd, unsigned long arg)
> >+{
> >+struct dma_buf *dmabuf;
> >+struct dma_buf_sync sync;
> >+enum dma_data_direction direction;
> >+
> >+dmabuf = file->private_data;
> >+
> >+switch (cmd) {
> >+case DMA_BUF_IOCTL_SYNC:
> >+if (copy_from_user(, (void __user *) arg, 
> >sizeof(sync)))
> >+return -EFAULT;
> >+
> >+if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
> >+return -EINVAL;
> >+
> >+switch (sync.flags & DMA_BUF_SYNC_RW) {
> >+case DMA_BUF_SYNC_READ:
> >+direction = DMA_FROM_DEVICE;
> >+break;
> >+case DMA_BUF_SYNC_WRITE:
> >+direction = DMA_TO_DEVICE;
> >+break;
> >+case DMA_BUF_SYNC_RW:
> >+direction = DMA_BIDIRECTIONAL;
> >+break;
> >+default:
> >+return -EINVAL;
> >+}
> >+
> >+if (sync.flags & DMA_BUF_SYNC_END)
> >+dma_buf_end_cpu_access(dmabuf, direction);
> >+else
> >+dma_buf_begin_cpu_access(dmabuf, direction);
> 
> We forgot to report the error back to userspace. Might as well fixup the
> callchain to propagate error from end-cpu-access as well. Found after
> updating igt/gem_concurrent_blit to exercise dmabuf mmaps vs the GPU.
> >>>
> >>>EINTR? Do we need to make this ABI - I guess so? Tiago, do you have
> >>>patches? See drmIoctl() in libdrm for what's needed on the userspace side
> >>>if my guess is right.
> >>
> >>EINTR is the easiest, but conceivably we could also get EIO and
> >>currently EAGAIN.
> >>
> >>I am also seeing some strange timing dependent (i.e. valgrind doesn't
> >>show up anything client side and the tests then pass) failures (SIGSEGV,
> >>SIGBUS) with !llc.
> >
> >Tiago, ping. Also probably a gap in igt coverage besides the kernel side.
> >-Daniel
> 
> Hey guys! I'm back from vacation now. I'll take a look on it in the
> next days and then come back to you.

An unpolished version:
https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs=b83483e87438f870d8209a44a184323a1d54
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 14/14] drm/vmwgfx: Bump driver minor

[Thomas Hellstrom]

signals availability of resolutionKMS support

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclar Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 98cf4ff..019a6ca 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -40,9 +40,9 @@
 #include 
 #include "vmwgfx_fence.h"

-#define VMWGFX_DRIVER_DATE "20150810"
+#define VMWGFX_DRIVER_DATE "20160210"
 #define VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 9
+#define VMWGFX_DRIVER_MINOR 10
 #define VMWGFX_DRIVER_PATCHLEVEL 0
 #define VMWGFX_FILE_PAGE_OFFSET 0x0010
 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
-- 
2.5.0

[PATCH 13/14] drm: Adjust the maximum value of suggested [X|Y] properties

[Thomas Hellstrom]

X re-export these values as 32-bit, so they end up as -1.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/drm_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 8451400..a27b2e0 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1789,10 +1789,10 @@ int drm_mode_create_suggested_offset_properties(struct 
drm_device *dev)
return 0;

dev->mode_config.suggested_x_property =
-   drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"suggested X", 0, 0x);
+   drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"suggested X", 0, 0x7fff);

dev->mode_config.suggested_y_property =
-   drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"suggested Y", 0, 0x);
+   drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
"suggested Y", 0, 0x7fff);

if (dev->mode_config.suggested_x_property == NULL ||
dev->mode_config.suggested_y_property == NULL)
-- 
2.5.0

[PATCH 12/14] drm/vmwgfx: Allow the UPDATE_LAYOUT ioctl from control nodes

[Thomas Hellstrom]

On vmware there is a daemon telling the KMS system about the GUI layout.
Typically it talks to the X server but in the absence of an X server or if
there are multiple, it wants to talk directly to the vmwgfx kernel module.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 1ca9037..6cbb7d4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -195,7 +195,7 @@ static const struct drm_ioctl_desc vmw_ioctls[] = {
  DRM_MASTER | DRM_AUTH),
VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT,
  vmw_kms_update_layout_ioctl,
- DRM_MASTER),
+ DRM_MASTER | DRM_CONTROL_ALLOW),
VMW_IOCTL_DEF(VMW_CREATE_SHADER,
  vmw_shader_define_ioctl,
  DRM_AUTH | DRM_RENDER_ALLOW),
-- 
2.5.0

[PATCH 11/14] drm/vmwgfx: Send a hotplug event at master_set

[Thomas Hellstrom]

Make sure drm clients (mostly the X server) are communicated the current
layout when switched in.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 0ee76e5..1ca9037 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1204,6 +1204,7 @@ static int vmw_master_set(struct drm_device *dev,
}

dev_priv->active_master = vmaster;
+   drm_sysfs_hotplug_event(dev);

return 0;
 }
-- 
2.5.0

[PATCH 10/14] drm/vmwgfx: Default to explicit crtc placement for screen targets and screen objects

[Thomas Hellstrom]

Enables using multiple framebuffers. For legacy display units,
explicit crtc placement is not supported due to hardware limitations.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 8a3d3c9..0ea22fd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -516,7 +516,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, 
unsigned unit)
sou->base.pref_width = dev_priv->initial_width;
sou->base.pref_height = dev_priv->initial_height;
sou->base.pref_mode = NULL;
-   sou->base.is_implicit = true;
+   sou->base.is_implicit = false;

drm_connector_init(dev, connector, _sou_connector_funcs,
   DRM_MODE_CONNECTOR_VIRTUAL);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index fe42a2c..b949102 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1109,7 +1109,7 @@ static int vmw_stdu_init(struct vmw_private *dev_priv, 
unsigned unit)
stdu->base.pref_active = (unit == 0);
stdu->base.pref_width  = dev_priv->initial_width;
stdu->base.pref_height = dev_priv->initial_height;
-   stdu->base.is_implicit = true;
+   stdu->base.is_implicit = false;

drm_connector_init(dev, connector, _stdu_connector_funcs,
   DRM_MODE_CONNECTOR_VIRTUAL);
-- 
2.5.0

[PATCH 09/14] drm/vmwgfx: Calculate the cursor position based on the crtc gui origin

[Thomas Hellstrom]

Base the cursor position on the coordinate of the crtc origin in the
gui coordinate system rather than in the framebuffer coordinate system.

With explicit placement, these may differ (for example when two crtcs
scan out of the same framebuffer location).

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  | 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 2 ++
 5 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0e2340f..4742ec4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -236,8 +236,8 @@ int vmw_du_crtc_cursor_move(struct drm_crtc *crtc, int x, 
int y)
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
bool shown = du->cursor_surface || du->cursor_dmabuf ? true : false;

-   du->cursor_x = x + crtc->x;
-   du->cursor_y = y + crtc->y;
+   du->cursor_x = x + du->set_gui_x;
+   du->cursor_y = y + du->set_gui_y;

/*
 * FIXME: Unclear whether there's any global state touched by the
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index aa21aff..5720321 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -179,6 +179,8 @@ struct vmw_display_unit {
int gui_y;
bool is_implicit;
bool active_implicit;
+   int set_gui_x;
+   int set_gui_y;
 };

 #define vmw_crtc_to_du(x) \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 13b1047..63ccd98 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -288,6 +288,8 @@ static int vmw_ldu_crtc_set_config(struct drm_mode_set *set)
crtc->y = set->y;
crtc->mode = *mode;
crtc->enabled = true;
+   ldu->base.set_gui_x = set->x;
+   ldu->base.set_gui_y = set->y;

vmw_ldu_add_active(dev_priv, ldu, vfb);

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 7ca13ec..8a3d3c9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -144,6 +144,8 @@ static int vmw_sou_fifo_create(struct vmw_private *dev_priv,
cmd->obj.root.x = sou->base.gui_x;
cmd->obj.root.y = sou->base.gui_y;
}
+   sou->base.set_gui_x = cmd->obj.root.x;
+   sou->base.set_gui_y = cmd->obj.root.y;

/* Ok to assume that buffer is pinned in vram */
vmw_bo_get_guest_ptr(>buffer->base, >obj.backingStore.ptr);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 1cd88d1..fe42a2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -202,6 +202,8 @@ static int vmw_stdu_define_st(struct vmw_private *dev_priv,
cmd->body.xRoot  = stdu->base.gui_x;
cmd->body.yRoot  = stdu->base.gui_y;
}
+   stdu->base.set_gui_x = cmd->body.xRoot;
+   stdu->base.set_gui_y = cmd->body.yRoot;

vmw_fifo_commit(dev_priv, sizeof(*cmd));

-- 
2.5.0

[PATCH 08/14] drm/vmwgfx: Add connector properties to switch between explicit and implicit placement

[Thomas Hellstrom]

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 30 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  3 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  7 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  7 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  8 +++-
 6 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 13970fe..98cf4ff 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -409,6 +409,7 @@ struct vmw_private {
struct vmw_legacy_display *ldu_priv;
struct vmw_overlay *overlay_priv;
struct drm_property *hotplug_mode_update_property;
+   struct drm_property *implicit_placement_property;
unsigned num_implicit;
struct vmw_framebuffer *implicit_fb;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 6726294..0e2340f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1622,6 +1622,12 @@ int vmw_du_connector_set_property(struct drm_connector 
*connector,
  struct drm_property *property,
  uint64_t val)
 {
+   struct vmw_display_unit *du = vmw_connector_to_du(connector);
+   struct vmw_private *dev_priv = vmw_priv(connector->dev);
+
+   if (property == dev_priv->implicit_placement_property)
+   du->is_implicit = val;
+
return 0;
 }

@@ -2219,3 +2225,27 @@ void vmw_kms_update_implicit_fb(struct vmw_private 
*dev_priv,

dev_priv->implicit_fb = vfb;
 }
+
+/**
+ * vmw_kms_create_implicit_placement_proparty - Set up the implicit placement
+ * property.
+ *
+ * @dev_priv: Pointer to a device private struct.
+ * @immutable: Whether the property is immutable.
+ *
+ * Sets up the implicit placement property unless it's already set up.
+ */
+void
+vmw_kms_create_implicit_placement_property(struct vmw_private *dev_priv,
+  bool immutable)
+{
+   if (dev_priv->implicit_placement_property)
+   return;
+
+   dev_priv->implicit_placement_property =
+   drm_property_create_range(dev_priv->dev,
+ immutable ?
+ DRM_MODE_PROP_IMMUTABLE : 0,
+ "implicit_placement", 0, 1);
+
+}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 0b5c9ab..aa21aff 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -264,7 +264,8 @@ bool vmw_kms_crtc_flippable(struct vmw_private *dev_priv,
struct drm_crtc *crtc);
 void vmw_kms_update_implicit_fb(struct vmw_private *dev_priv,
struct drm_crtc *crtc);
-
+void vmw_kms_create_implicit_placement_property(struct vmw_private *dev_priv,
+   bool immutable);


 /*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 8fb17b8..13b1047 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -383,6 +383,11 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, 
unsigned unit)
   dev->mode_config.suggested_x_property, 0);
drm_object_attach_property(>base,
   dev->mode_config.suggested_y_property, 0);
+   if (dev_priv->implicit_placement_property)
+   drm_object_attach_property
+   (>base,
+dev_priv->implicit_placement_property,
+1);

return 0;
 }
@@ -418,6 +423,8 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
if (ret != 0)
goto err_vblank_cleanup;

+   vmw_kms_create_implicit_placement_property(dev_priv, true);
+
if (dev_priv->capabilities & SVGA_CAP_MULTIMON)
for (i = 0; i < VMWGFX_NUM_DISPLAY_UNITS; ++i)
vmw_ldu_init(dev_priv, i);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 1390cff..7ca13ec 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -541,6 +541,11 @@ static int vmw_sou_init(struct vmw_private *dev_priv, 
unsigned unit)
   dev->mode_config.suggested_x_property, 0);
drm_object_attach_property(>base,
   dev->mode_config.suggested_y_property, 0);
+   if (dev_priv->implicit_placement_property)
+   drm_object_attach_property
+   (>base,
+dev_priv->implicit_placement_property,
+

[PATCH 07/14] drm/vmwgfx: Add suggested screen x and y connector properties

[Thomas Hellstrom]

Introduced by qxl, add these properties as a generic way to tell a
display manager about the GUI layout.

Also add the hotplug_mode_update_property which advises display managers to
reread the mode list on a hotplug event.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 32 
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  | 10 --
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 10 --
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  6 ++
 5 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index b92521d..13970fe 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -408,6 +408,7 @@ struct vmw_private {
enum vmw_display_unit_type active_display_unit;
struct vmw_legacy_display *ldu_priv;
struct vmw_overlay *overlay_priv;
+   struct drm_property *hotplug_mode_update_property;
unsigned num_implicit;
struct vmw_framebuffer *implicit_fb;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 26c2e9e..6726294 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1108,6 +1108,22 @@ int vmw_kms_present(struct vmw_private *dev_priv,
return 0;
 }

+static void
+vmw_kms_create_hotplug_mode_update_property(struct vmw_private *dev_priv)
+{
+   if (dev_priv->hotplug_mode_update_property)
+   return;
+
+   dev_priv->hotplug_mode_update_property =
+   drm_property_create_range(dev_priv->dev,
+ DRM_MODE_PROP_IMMUTABLE,
+ "hotplug_mode_update", 0, 1);
+
+   if (!dev_priv->hotplug_mode_update_property)
+   return;
+
+}
+
 int vmw_kms_init(struct vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
@@ -1120,6 +1136,9 @@ int vmw_kms_init(struct vmw_private *dev_priv)
dev->mode_config.max_width = dev_priv->texture_max_width;
dev->mode_config.max_height = dev_priv->texture_max_height;

+   drm_mode_create_suggested_offset_properties(dev);
+   vmw_kms_create_hotplug_mode_update_property(dev_priv);
+
ret = vmw_kms_stdu_init_display(dev_priv);
if (ret) {
ret = vmw_kms_sou_init_display(dev_priv);
@@ -1359,15 +1378,28 @@ static int vmw_du_update_layout(struct vmw_private 
*dev_priv, unsigned num,
du->pref_active = true;
du->gui_x = rects[du->unit].x;
du->gui_y = rects[du->unit].y;
+   drm_object_property_set_value
+ (>base, dev->mode_config.suggested_x_property,
+  du->gui_x);
+   drm_object_property_set_value
+ (>base, dev->mode_config.suggested_y_property,
+  du->gui_y);
} else {
du->pref_width = 800;
du->pref_height = 600;
du->pref_active = false;
+   drm_object_property_set_value
+ (>base, dev->mode_config.suggested_x_property,
+  0);
+   drm_object_property_set_value
+ (>base, dev->mode_config.suggested_y_property,
+  0);
}
con->status = vmw_du_connector_detect(con, true);
}

mutex_unlock(>mode_config.mutex);
+   drm_sysfs_hotplug_event(dev);

return 0;
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index b6fa44f..8fb17b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -375,8 +375,14 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, 
unsigned unit)
drm_mode_crtc_set_gamma_size(crtc, 256);

drm_object_attach_property(>base,
- dev->mode_config.dirty_info_property,
- 1);
+  dev->mode_config.dirty_info_property,
+  1);
+   drm_object_attach_property(>base,
+  dev_priv->hotplug_mode_update_property, 1);
+   drm_object_attach_property(>base,
+  dev->mode_config.suggested_x_property, 0);
+   drm_object_attach_property(>base,
+  dev->mode_config.suggested_y_property, 0);

return 0;
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index c11b196..1390cff 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -533,8 +533,14 @@ 

[PATCH 06/14] drm/vmwgfx: Add implicit framebuffer checks to the screen target code

[Thomas Hellstrom]

Just like for screen objects, make sure we use only a single framebuffer
for implicit placement.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index c93af71..a5ab826 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -510,6 +510,7 @@ out_srf_unref:
 static int vmw_stdu_crtc_set_config(struct drm_mode_set *set)
 {
struct vmw_private *dev_priv;
+   struct vmw_framebuffer *vfb;
struct vmw_screen_target_display_unit *stdu;
struct drm_display_mode *mode;
struct drm_framebuffer  *new_fb;
@@ -529,6 +530,7 @@ static int vmw_stdu_crtc_set_config(struct drm_mode_set 
*set)
new_fb   = set->fb;
dev_priv = vmw_priv(crtc->dev);
turning_off = set->num_connectors == 0 || !mode || !new_fb;
+   vfb = (new_fb) ? vmw_framebuffer_to_vfb(new_fb) : NULL;

if (set->num_connectors > 1) {
DRM_ERROR("Too many connectors\n");
@@ -548,6 +550,14 @@ static int vmw_stdu_crtc_set_config(struct drm_mode_set 
*set)
return -EINVAL;
}

+   /* Only one active implicit frame-buffer at a time. */
+   if (!turning_off && stdu->base.is_implicit && dev_priv->implicit_fb &&
+   !(dev_priv->num_implicit == 1 && stdu->base.active_implicit)
+   && dev_priv->implicit_fb != vfb) {
+   DRM_ERROR("Multiple implicit framebuffers not supported.\n");
+   return -EINVAL;
+   }
+
/* Since they always map one to one these are safe */
connector = >base.connector;
encoder   = >base.encoder;
@@ -559,6 +569,7 @@ static int vmw_stdu_crtc_set_config(struct drm_mode_set 
*set)

vmw_stdu_unpin_display(stdu);
(void) vmw_stdu_update_st(dev_priv, stdu);
+   vmw_kms_del_active(dev_priv, >base);

ret = vmw_stdu_destroy_st(dev_priv, stdu);
if (ret)
@@ -603,6 +614,7 @@ static int vmw_stdu_crtc_set_config(struct drm_mode_set 
*set)
if (ret)
return ret;

+   vmw_kms_add_active(dev_priv, >base, vfb);
crtc->enabled = true;
connector->encoder = encoder;
encoder->crtc  = crtc;
@@ -644,13 +656,16 @@ static int vmw_stdu_crtc_page_flip(struct drm_crtc *crtc,
dev_priv  = vmw_priv(crtc->dev);
stdu  = vmw_crtc_to_stdu(crtc);

-   if (!stdu->defined)
+   if (!stdu->defined || !vmw_kms_crtc_flippable(dev_priv, crtc))
return -EINVAL;

ret = vmw_stdu_bind_fb(dev_priv, crtc, >mode, new_fb);
if (ret)
return ret;

+   if (stdu->base.is_implicit)
+   vmw_kms_update_implicit_fb(dev_priv, crtc);
+
vclips.x = crtc->x;
vclips.y = crtc->y;
vclips.w = crtc->mode.hdisplay;
-- 
2.5.0

[PATCH 05/14] drm/vmwgfx: Break out implicit fb code

[Thomas Hellstrom]

Preparation for supporting explicit fbs for screen objects and screen
targets.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  92 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  12 
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 125 ---
 4 files changed, 120 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5cb1b16..b92521d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -407,8 +407,9 @@ struct vmw_private {
void *fb_info;
enum vmw_display_unit_type active_display_unit;
struct vmw_legacy_display *ldu_priv;
-   struct vmw_screen_object_display *sou_priv;
struct vmw_overlay *overlay_priv;
+   unsigned num_implicit;
+   struct vmw_framebuffer *implicit_fb;

/*
 * Context and surface management.
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 29bec97..26c2e9e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2095,3 +2095,95 @@ int vmw_kms_fbdev_init_data(struct vmw_private *dev_priv,

return 0;
 }
+
+/**
+ * vmw_kms_del_active - unregister a crtc binding to the implicit framebuffer
+ *
+ * @dev_priv: Pointer to a device private struct.
+ * @du: The display unit of the crtc.
+ */
+void vmw_kms_del_active(struct vmw_private *dev_priv,
+   struct vmw_display_unit *du)
+{
+   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
+
+   if (du->active_implicit) {
+   if (--(dev_priv->num_implicit) == 0)
+   dev_priv->implicit_fb = NULL;
+   du->active_implicit = false;
+   }
+}
+
+/**
+ * vmw_kms_add_active - register a crtc binding to an implicit framebuffer
+ *
+ * @vmw_priv: Pointer to a device private struct.
+ * @du: The display unit of the crtc.
+ * @vfb: The implicit framebuffer
+ *
+ * Registers a binding to an implicit framebuffer.
+ */
+void vmw_kms_add_active(struct vmw_private *dev_priv,
+   struct vmw_display_unit *du,
+   struct vmw_framebuffer *vfb)
+{
+   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
+
+   WARN_ON_ONCE(!dev_priv->num_implicit && dev_priv->implicit_fb);
+
+   if (!du->active_implicit && du->is_implicit) {
+   dev_priv->implicit_fb = vfb;
+   du->active_implicit = true;
+   dev_priv->num_implicit++;
+   }
+}
+
+/**
+ * vmw_kms_screen_object_flippable - Check whether we can page-flip a crtc.
+ *
+ * @dev_priv: Pointer to device-private struct.
+ * @crtc: The crtc we want to flip.
+ *
+ * Returns true or false depending whether it's OK to flip this crtc
+ * based on the criterion that we must not have more than one implicit
+ * frame-buffer at any one time.
+ */
+bool vmw_kms_crtc_flippable(struct vmw_private *dev_priv,
+   struct drm_crtc *crtc)
+{
+   struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
+
+   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
+
+   if (!du->is_implicit)
+   return true;
+
+   if (dev_priv->num_implicit != 1)
+   return false;
+
+   return true;
+}
+
+/**
+ * vmw_kms_update_implicit_fb - Update the implicit fb.
+ *
+ * @dev_priv: Pointer to device-private struct.
+ * @crtc: The crtc the new implicit frame-buffer is bound to.
+ */
+void vmw_kms_update_implicit_fb(struct vmw_private *dev_priv,
+   struct drm_crtc *crtc)
+{
+   struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
+   struct vmw_framebuffer *vfb;
+
+   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
+
+   if (!du->is_implicit)
+   return;
+
+   vfb = vmw_framebuffer_to_vfb(crtc->primary->fb);
+   WARN_ON_ONCE(dev_priv->num_implicit != 1 &&
+dev_priv->implicit_fb != vfb);
+
+   dev_priv->implicit_fb = vfb;
+}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index d41928c..0b5c9ab 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -178,6 +178,7 @@ struct vmw_display_unit {
int gui_x;
int gui_y;
bool is_implicit;
+   bool active_implicit;
 };

 #define vmw_crtc_to_du(x) \
@@ -254,6 +255,17 @@ int vmw_kms_fbdev_init_data(struct vmw_private *dev_priv,
struct drm_crtc **p_crtc,
struct drm_display_mode **p_mode);
 void vmw_guess_mode_timing(struct drm_display_mode *mode);
+void vmw_kms_del_active(struct vmw_private *dev_priv,
+   struct vmw_display_unit *du);
+void vmw_kms_add_active(struct vmw_private *dev_priv,
+   

[PATCH 04/14] drm/vmwgfx: Rework screen target page flips v2

[Thomas Hellstrom]

Gnome-Shell / Wayland assumes that page-flips can be done on a crtc
regardless of framebuffer size and the crtc position within the
framebuffer.

Therefore rework the screen target code to correctly handle changes in
framebuffer size and content_fb_type. Also make sure that we update
the screen target correctly when the content_fb_type is not
SAME_AS_DISPLAY.

This commit breaks out the framebuffer binding code from crtc_set so it
can be used both from page_flip() and crtc_set() and reworks those
functions a bit to be more robust.

v2: Address review comments by Sinclair Yeh.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 422 ---
 1 file changed, 188 insertions(+), 234 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 4ef5ffd..c93af71 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -96,7 +96,6 @@ struct vmw_stdu_surface_copy {
  *   content_vfbs dimensions, then this is a pointer into the
  *   corresponding field in content_vfbs.  If not, then this
  *   is a separate buffer to which content_vfbs will blit to.
- * @content_fb: holds the rendered content, can be a surface or DMA buffer
  * @content_type:  content_fb type
  * @defined:  true if the current display unit has been initialized
  */
@@ -104,8 +103,6 @@ struct vmw_screen_target_display_unit {
struct vmw_display_unit base;

struct vmw_surface *display_srf;
-   struct drm_framebuffer *content_fb;
-
enum stdu_content_type content_fb_type;

bool defined;
@@ -122,22 +119,6 @@ static void vmw_stdu_destroy(struct 
vmw_screen_target_display_unit *stdu);
  */

 /**
- * vmw_stdu_pin_display - pins the resource associated with the display surface
- *
- * @stdu: contains the display surface
- *
- * Since the display surface can either be a private surface allocated by us,
- * or it can point to the content surface, we use this function to not pin the
- * same resource twice.
- */
-static int vmw_stdu_pin_display(struct vmw_screen_target_display_unit *stdu)
-{
-   return vmw_resource_pin(>display_srf->res, false);
-}
-
-
-
-/**
  * vmw_stdu_unpin_display - unpins the resource associated with display surface
  *
  * @stdu: contains the display surface
@@ -153,13 +134,7 @@ static void vmw_stdu_unpin_display(struct 
vmw_screen_target_display_unit *stdu)
struct vmw_resource *res = >display_srf->res;

vmw_resource_unpin(res);
-
-   if (stdu->content_fb_type != SAME_AS_DISPLAY) {
-   vmw_resource_unreference();
-   stdu->content_fb_type = SAME_AS_DISPLAY;
-   }
-
-   stdu->display_srf = NULL;
+   vmw_surface_unreference(>display_srf);
}
 }

@@ -185,6 +160,9 @@ static void vmw_stdu_crtc_destroy(struct drm_crtc *crtc)
  *
  * @dev_priv:  VMW DRM device
  * @stdu: display unit to create a Screen Target for
+ * @mode: The mode to set.
+ * @crtc_x: X coordinate of screen target relative to framebuffer origin.
+ * @crtc_y: Y coordinate of screen target relative to framebuffer origin.
  *
  * Creates a STDU that we can used later.  This function is called whenever the
  * framebuffer size changes.
@@ -193,7 +171,9 @@ static void vmw_stdu_crtc_destroy(struct drm_crtc *crtc)
  * 0 on success, error code on failure
  */
 static int vmw_stdu_define_st(struct vmw_private *dev_priv,
- struct vmw_screen_target_display_unit *stdu)
+ struct vmw_screen_target_display_unit *stdu,
+ struct drm_display_mode *mode,
+ int crtc_x, int crtc_y)
 {
struct {
SVGA3dCmdHeader header;
@@ -211,14 +191,14 @@ static int vmw_stdu_define_st(struct vmw_private 
*dev_priv,
cmd->header.size = sizeof(cmd->body);

cmd->body.stid   = stdu->base.unit;
-   cmd->body.width  = stdu->display_srf->base_size.width;
-   cmd->body.height = stdu->display_srf->base_size.height;
+   cmd->body.width  = mode->hdisplay;
+   cmd->body.height = mode->vdisplay;
cmd->body.flags  = (0 == cmd->body.stid) ? SVGA_STFLAG_PRIMARY : 0;
cmd->body.dpi= 0;
-   cmd->body.xRoot  = stdu->base.crtc.x;
-   cmd->body.yRoot  = stdu->base.crtc.y;
-
-   if (!stdu->base.is_implicit) {
+   if (stdu->base.is_implicit) {
+   cmd->body.xRoot  = crtc_x;
+   cmd->body.yRoot  = crtc_y;
+   } else {
cmd->body.xRoot  = stdu->base.gui_x;
cmd->body.yRoot  = stdu->base.gui_y;
}
@@ -392,126 +372,43 @@ static int vmw_stdu_destroy_st(struct vmw_private 
*dev_priv,
return ret;
 }

-
-
 /**
- * 

[PATCH 03/14] drm/vmwgfx: Fix screen object page flips for large framebuffers

[Thomas Hellstrom]

For page flips the framebuffer may be much larger than the crtc
scanout area and may be attached to multiple crtcs.
When flipping a crtc, make sure we dirty only that crtc's area of the
framebuffer.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  5 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 18 +++---
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b221a8c..29bec97 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -663,9 +663,8 @@ static int vmw_framebuffer_dmabuf_dirty(struct 
drm_framebuffer *framebuffer,
break;
case vmw_du_screen_object:
ret = vmw_kms_sou_do_dmabuf_dirty(dev_priv, >base,
- clips, num_clips, increment,
- true,
- NULL);
+ clips, NULL, num_clips,
+ increment, true, NULL);
break;
case vmw_du_legacy:
ret = vmw_kms_ldu_do_dmabuf_dirty(dev_priv, >base, 0, 0,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index edd8150..d41928c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -287,6 +287,7 @@ int vmw_kms_sou_do_surface_dirty(struct vmw_private 
*dev_priv,
 int vmw_kms_sou_do_dmabuf_dirty(struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer,
struct drm_clip_rect *clips,
+   struct drm_vmw_rect *vclips,
unsigned num_clips, int increment,
bool interruptible,
struct vmw_fence_obj **out_fence);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index cbc1fba..c0de3b8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -470,7 +470,7 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
struct drm_framebuffer *old_fb = crtc->primary->fb;
struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(fb);
struct vmw_fence_obj *fence = NULL;
-   struct drm_clip_rect clips;
+   struct drm_vmw_rect vclips;
int ret;

/* require ScreenObject support for page flipping */
@@ -483,17 +483,18 @@ static int vmw_sou_crtc_page_flip(struct drm_crtc *crtc,
crtc->primary->fb = fb;

/* do a full screen dirty update */
-   clips.x1 = clips.y1 = 0;
-   clips.x2 = fb->width;
-   clips.y2 = fb->height;
+   vclips.x = crtc->x;
+   vclips.y = crtc->y;
+   vclips.w = crtc->mode.hdisplay;
+   vclips.h = crtc->mode.vdisplay;

if (vfb->dmabuf)
ret = vmw_kms_sou_do_dmabuf_dirty(dev_priv, vfb,
- , 1, 1,
+ NULL, , 1, 1,
  true, );
else
ret = vmw_kms_sou_do_surface_dirty(dev_priv, vfb,
-  , NULL, NULL,
+  NULL, , NULL,
   0, 0, 1, 1, );


@@ -919,6 +920,8 @@ static void vmw_sou_dmabuf_clip(struct vmw_kms_dirty *dirty)
  * @dev_priv: Pointer to the device private structure.
  * @framebuffer: Pointer to the dma-buffer backed framebuffer.
  * @clips: Array of clip rects.
+ * @vclips: Alternate array of clip rects. Either @clips or @vclips must
+ * be NULL.
  * @num_clips: Number of clip rects in @clips.
  * @increment: Increment to use when looping over @clips.
  * @interruptible: Whether to perform waits interruptible if possible.
@@ -932,6 +935,7 @@ static void vmw_sou_dmabuf_clip(struct vmw_kms_dirty *dirty)
 int vmw_kms_sou_do_dmabuf_dirty(struct vmw_private *dev_priv,
struct vmw_framebuffer *framebuffer,
struct drm_clip_rect *clips,
+   struct drm_vmw_rect *vclips,
unsigned num_clips, int increment,
bool interruptible,
struct vmw_fence_obj **out_fence)
@@ -955,7 +959,7 @@ int vmw_kms_sou_do_dmabuf_dirty(struct vmw_private 
*dev_priv,
dirty.clip = vmw_sou_dmabuf_clip;
dirty.fifo_reserve_size = sizeof(struct vmw_kms_sou_dmabuf_blit) *
num_clips;
-   ret = vmw_kms_helper_dirty(dev_priv, framebuffer, clips, NULL,
+   ret = vmw_kms_helper_dirty(dev_priv, 

[PATCH 02/14] drm/vmwgfx: Fix a screen object framebuffer dirty corner case

[Thomas Hellstrom]

If there are no cliprects for a particular crtc, an invalid command would
have been generated. If that's the case, instead ditch the generated
command sequence.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index c5a1a08..cbc1fba 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -738,6 +738,11 @@ static void vmw_sou_surface_fifo_commit(struct 
vmw_kms_dirty *dirty)
SVGASignedRect *blit = (SVGASignedRect *) [1];
int i;

+   if (!dirty->num_hits) {
+   vmw_fifo_commit(dirty->dev_priv, 0);
+   return;
+   }
+
cmd->header.id = SVGA_3D_CMD_BLIT_SURFACE_TO_SCREEN;
cmd->header.size = sizeof(cmd->body) + region_size;

@@ -875,6 +880,11 @@ int vmw_kms_sou_do_surface_dirty(struct vmw_private 
*dev_priv,
  */
 static void vmw_sou_dmabuf_fifo_commit(struct vmw_kms_dirty *dirty)
 {
+   if (!dirty->num_hits) {
+   vmw_fifo_commit(dirty->dev_priv, 0);
+   return;
+   }
+
vmw_fifo_commit(dirty->dev_priv,
sizeof(struct vmw_kms_sou_dmabuf_blit) *
dirty->num_hits);
@@ -967,6 +977,11 @@ out_revert:
  */
 static void vmw_sou_readback_fifo_commit(struct vmw_kms_dirty *dirty)
 {
+   if (!dirty->num_hits) {
+   vmw_fifo_commit(dirty->dev_priv, 0);
+   return;
+   }
+
vmw_fifo_commit(dirty->dev_priv,
sizeof(struct vmw_kms_sou_readback_blit) *
dirty->num_hits);
-- 
2.5.0

[PATCH 01/14] drm/vmwgfx: Add DXGenMips support

[Thomas Hellstrom]

From: Charmaine Lee 

Add support for DXGenMips command.

Signed-off-by: Charmaine Lee 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 5da5de0..723ba16 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3009,6 +3009,26 @@ out_unref:
return ret;
 }

+/**
+ * vmw_cmd_dx_genmips - Validate an SVGA_3D_CMD_DX_GENMIPS command
+ *
+ * @dev_priv: Pointer to a device private struct.
+ * @sw_context: The software context being used for this batch.
+ * @header: Pointer to the command header in the command stream.
+ */
+static int vmw_cmd_dx_genmips(struct vmw_private *dev_priv,
+ struct vmw_sw_context *sw_context,
+ SVGA3dCmdHeader *header)
+{
+   struct {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdDXGenMips body;
+   } *cmd = container_of(header, typeof(*cmd), header);
+
+   return vmw_view_id_val_add(sw_context, vmw_view_sr,
+  cmd->body.shaderResourceViewId);
+}
+
 static int vmw_cmd_check_not_3d(struct vmw_private *dev_priv,
struct vmw_sw_context *sw_context,
void *buf, uint32_t *size)
@@ -3297,7 +3317,7 @@ static const struct vmw_cmd_entry 
vmw_cmd_entries[SVGA_3D_CMD_MAX] = {
_cmd_dx_clear_depthstencil_view, true, false, true),
VMW_CMD_DEF(SVGA_3D_CMD_DX_PRED_COPY, _cmd_invalid,
true, false, true),
-   VMW_CMD_DEF(SVGA_3D_CMD_DX_GENMIPS, _cmd_invalid,
+   VMW_CMD_DEF(SVGA_3D_CMD_DX_GENMIPS, _cmd_dx_genmips,
true, false, true),
VMW_CMD_DEF(SVGA_3D_CMD_DX_UPDATE_SUBRESOURCE,
_cmd_dx_check_subresource, true, false, true),
-- 
2.5.0

linux-next: Tree for Mar 14

[Wolfram Sang]

On Tue, Mar 15, 2016 at 09:30:29AM +0900, Sergey Senozhatsky wrote:
> On (03/14/16 17:40), Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20160311:
> > 
> > The vfs tree gained a conflict against Linus' tree. I also applied a
> > patch for a known runtime bug.
> > 
> > The tip tree gained a conflict against the mips tree.
> > 
> > The aio tree still had a build failure so I removed several commits
> > from it.  It also gained a conflict against the vfs tree.
> > 
> > Non-merge commits (relative to Linus' tree): 11202
> >  8646 files changed, 426680 insertions(+), 211740 deletions(-)
> 
> 
> Hello,
> 
> I'm seeing a bunch of warnings and errors

I pushed the fix to my for-next branch yesterday. Sorry for the fuzz!

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/47c0ce82/attachment.sig>

[Bug 94242] [radeonsi] Crash while running Fedora mock tool for prompting root (gtksu)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94242

Michel D�nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from Michel D�nzer  ---
Fixed in LLVM SVN r263441.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/a8347a44/attachment.html>

[Bug 94512] X segfaults on launching in x32 environment

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=94512

--- Comment #1 from Michel D�nzer  ---
Looks like maybe libglapi.so.0 should be picked up from somewhere other than
/usr/libx32/libglapi.so.0? It should be from the same build as the rest of the
Mesa binaries. If that's not the problem, please get a backtrace with debugging
symbols available for /usr/libx32/libglapi.so.0 as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160315/e4358c4f/attachment.html>