Re: [PATCH] drm/vmwgfx: Check check that number of mip levels is above zero in vmw_surface_define_ioctl()

[Sinclair Yeh]

Hi,

thank you for this patch.  Murray McAllister reported this one a couple
of months ago, and this is already in our queue.

Sinclair

On Fri, Mar 24, 2017 at 04:37:10PM +0100, Vladis Dronov wrote:
> In vmw_surface_define_ioctl(), a num_sizes parameter is assigned a
> user-controlled value which is not checked for zero. It is used in
> a call to kmalloc() which returns ZERO_SIZE_PTR. Later ZERO_SIZE_PTR
> is dereferenced which leads to a GPF and possibly to a kernel panic.
> Add the check for zero to avoid this.
> 
> Reference: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1435719&d=DwIBAg&c=uilaK90D4TOVoH58JNXRgQ&r=HaJ2a6NYExoV0cntAYcoqA&m=OW9cIAAez9eRIxEYMaToDu2szuR_YrfQcOzAH6L8dXo&s=-3P2pG3n1YW6-8NG6mLC7kyxmx7mMxJmXgY79ZgQeo4&e=
>  
> Signed-off-by: Vladis Dronov 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index b445ce9..42840cc 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -716,8 +716,8 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
> *data,
>   for (i = 0; i < DRM_VMW_MAX_SURFACE_FACES; ++i)
>   num_sizes += req->mip_levels[i];
>  
> - if (num_sizes > DRM_VMW_MAX_SURFACE_FACES *
> - DRM_VMW_MAX_MIP_LEVELS)
> + if (num_sizes <= 0 ||
> + num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS)
>   return -EINVAL;
>  
>   size = vmw_user_surface_size + 128 +
> -- 
> 2.9.3
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

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

--- Comment #14 from Michel Dänzer (mic...@daenzer.net) ---
First of all, you can just run "git bisect skip" for any commits where you
can't test for the problem you're bisecting, for any reason. With luck, this
will allow git bisect to identify the regressing commit anyway. Even if not,
it'll provide a range of candidate commits, which can be further narrowed down
using Felix's technique.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors

[Bjorn Helgaas]

On Mon, Mar 13, 2017 at 01:41:35PM +0100, Christian König wrote:
> From: Christian König 
> 
> Most BIOS don't enable this because of compatibility reasons.

Can you give any more details here?  Without more hints, it's hard to
know whether any of the compatibility reasons might apply to Linux as
well.

> Manually enable a 64bit BAR of 64GB size so that we have
> enough room for PCI devices.

From the context, I'm guessing this is enabling a new 64GB window
through the PCI host bridge?  That might be documented as a "BAR", but
it's not anything the Linux PCI core would recognize as a BAR.

I think the specs would envision this being done via an ACPI _SRS
method on the PNP0A03 host bridge device.  That would be a more
generic path that would work on any host bridge.  Did you explore that
possibility?  I would prefer to avoid adding device-specific code if
that's possible.

> Signed-off-by: Christian König 
> ---
>  arch/x86/pci/fixup.c | 53 
> 
>  1 file changed, 53 insertions(+)
> 
> diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
> index 6d52b94..bff5242 100644
> --- a/arch/x86/pci/fixup.c
> +++ b/arch/x86/pci/fixup.c
> @@ -571,3 +571,56 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, 
> pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar);
>  DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar);
> +
> +static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
> +{
> + const uint64_t size = 64ULL * 1024 * 1024 * 1024;
> + uint32_t base, limit, high;
> + struct resource *res;
> + unsigned i;
> + int r;
> +
> + for (i = 0; i < 8; ++i) {
> +
> + pci_read_config_dword(dev, 0x80 + i * 0x8, &base);
> + pci_read_config_dword(dev, 0x180 + i * 0x4, &high);
> +
> + /* Is this slot free? */
> + if ((base & 0x3) == 0x0)
> + break;
> +
> + base >>= 8;
> + base |= high << 24;
> +
> + /* Abort if a slot already configures a 64bit BAR. */
> + if (base > 0x1)
> + return;
> +
> + }
> +
> + if (i == 8)
> + return;
> +
> + res = kzalloc(sizeof(*res), GFP_KERNEL);
> + res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH | IORESOURCE_MEM_64 |
> + IORESOURCE_WINDOW;
> + res->name = dev->bus->name;
> + r = allocate_resource(&iomem_resource, res, size, 0x1,
> +   0xfd, size, NULL, NULL);
> + if (r) {
> + kfree(res);
> + return;
> + }
> +
> + base = ((res->start >> 8) & 0xff00) | 0x3;
> + limit = ((res->end + 1) >> 8) & 0xff00;
> + high = ((res->start >> 40) & 0xff) |
> + res->end + 1) >> 40) & 0xff) << 16);
> +
> + pci_write_config_dword(dev, 0x180 + i * 0x4, high);
> + pci_write_config_dword(dev, 0x84 + i * 0x8, limit);
> + pci_write_config_dword(dev, 0x80 + i * 0x8, base);
> +
> + pci_bus_add_resource(dev->bus, res, 0);

We would need some sort of printk here to explain how this new window
magically appeared.

> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 22/03/17 20:57, Dylan Baker wrote:

Quoting Jose Fonseca (2017-03-22 10:59:10)

On 17/03/17 02:28, Brian Paul wrote:


[snip]

Sure, I'd like to see one build system instead of two.  Meson supports
Windows so that's good.  But the big issue is our automated build
system.  Replacing SCons with Meson could be a big deal in that
context.  It would at least involve pulling Meson into our toolchain and
rewriting a bunch of Python code to grok Meson.  I'd have to go off and
investigate that to even see if it's a possibility.  Maybe next week.



I don't have any experience with Meson.  But for the record I don't have
much love for SCons.  I long stopped using SCons for anything but Mesa.

And my have good experience with cmake + ninja/msvc is positive.  So
tools with similar architecture sound good overall.

In fact, knowing what I know now, if I could go back in time, to when I
evaluated CMake and SCons, I'd chose CMake.


BTW, it seems that newer SCons will drop Python 2 support [1], which
might force us to rewrite a lot of SConsfiles/scripts any way.  So
perhaps that's a good time to evaluate migrating to something else.



That said, moving to another build system is always a herculian task.
Thought the benefit of having a single build system is appealing and
might save time down the line.



But there are many questions I have about Meson:  how confident are we
on Meson?  Are big projects using it?  How sure are we that it won't
become abandonware in a few years time?  How does it compare with other
newer gen build systems?



Here's a not so complete list: https://github.com/mesonbuild/meson/wiki/Users

Notably gnome is moving to meson (and some parts already use it), weston and
libinput have ports, libepoxy uses meson, and gstreamer is using meson. I
can't say for sure it's going to be around forever, but its been in development
since late 2012 and still lands several patches a day, they were responsive to
me when I sent a patch (that I still need to respin), and they seem to be
picking up momentum from downstreams.

As to how it compares to other build systems, it's fairly different than cmake
and scons, it's much less scripting and much more declarative, you can look at
the libdrm patch or the meson in libepoxy (which is more mature) to see the
syntax. It doesn't expose python or a full scripting language, though it does
have some fairly simple logic like if/elif/else and foreach, and they support
modules that add functionality, but need to be merged upstream, this is how
pkgconfig writing is implemented, for example. One of the things that it does
better than autotools and (IMHO) cmake, is dependency management, in most cases
it requires no special handling, the only case it does in mesa (so far) is for
local python module dependencies in generators. I think that these are actually
strengths of meson, it's simplicity makes it easy to understand and use.

For support, it's written in pure python (using only the stdlib with no
external deps), and requires python 3.4+. It has backends for ninja on Linux,
ninja and visual studio on Windows, and xcode on macOS; Clang, GCC, and MSVC
are considered first class compilers, some others might work, but are
unsupported.

I have a partial port of piglit to meson that I put together to see what
porting from cmake to meson was like (with no plans to send to the list), I can
push that somewhere for you to look at if you want to see the difference.



We also have special requirements: one is cross-build from Linux to
MinGW, which on Mesa case requires building portions of the tree twice
-- once for host -- another for cross-mingw.


Cross compiling for mingw is supported, and it provides a way to differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag for
this, but the meson approach is to write an ini file once, and use it again and
again), and the first example of cross compiling is using mingw from linux [2].

[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation


Thanks for the info.

It still scares me a bit that most Meson users are mostly Linux focused.

Another tool I heard good about but have not direct experience is 
https://bazel.build .  Any thoughts about it?




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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kenneth Graunke]

On Thursday, March 23, 2017 4:39:50 AM PDT Emil Velikov wrote:
> On 22 March 2017 at 20:10, Dylan Baker  wrote:
[snip]
> The more frustrating part is that atm autotools build is "bug-free"
> and with meson will have to go through the same route again :-\

"Bug-free" - famous last words :)

It is definitely working a lot better than it used to.  I'm grateful
to those who helped make it so (yourself included).

> > For my part, it took me about 3 or 4 days of reading through the docs and
> > writing the libdrm port to get it right, and a lot of that is just the
> > boilerplate of having ~8 drivers that all need basically the same logic.
> >
> Slightly off-topic - 3 days to write the build script for ~10 [nearly]
> identical libraries which do not do anything fancy, seems a lot.
> Which was the most time consuming part ?

As I believe Dylan explained...a lot of his time was spent learning
autotools and its idioms, so he knew how best to translate things.
(Dylan is pretty familiar with CMake, but less so with automake.)
Eric was able to work much more quickly, being already familiar with
the existing build system.

> I'm concerned that we would have to enforce the same time penalty onto
> dozens of developers unfamiliar with meson.
> 
> Thanks
> Emil

There's a time penalty figuring out any build system.  Most people try
to remain blissfully unaware of it as much as possible.  And then, most
tasks people do are pretty simple (adding files, deleting files, etc).
When something complex comes up...it takes time, reading, and sometimes
asking for help...no matter what system you use.

--Ken


signature.asc
Description: This is a digitally signed message part.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 24/03/17 19:10, Kristian Høgsberg wrote:

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:

On 23/03/17 01:38, Rob Clark wrote:


On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:


On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:


On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
wrote:


I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson.  It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.



One of the things that's prompted this on our side (I've talked this
over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases
were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs
and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic.


Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.



Sure, but we're also not the only ones investigating meson. Gnome is
using it
already, libepoxy is using it, gstreamer is using it. There are patches
for
weston (written by Daniel Stone) and libinput (written by Peter
Hutterer), there
are some other projects in the graphics sphere that people are working
on. So
even if we as a community decide that meson isn't for us, it's not going
away.



It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new
maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.



but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

BR,
-R



I tend to disagree.  While we can't avoid a transitory period, when we
embark on another build system (Meson or something else) I think we should
aim at 1) ensure such tool can indeed _completely_ replace at least _one_
existing build system, 2) and aim at migration quickly.

Otherwise we'll just end up with yet another build system, yet another way
builds can fail, with some developers stuck on old build systems because it
works, or because the new build system quite doesn't work.

And this is from (painful) experience.


I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start using meson, which means that life gets easier for
vmware wrt maintaining the build system, and easier for all developers
who have spent to much of their life waiting for autogen.sh.  Then
decommissioning autotools can be a separate topic as Rob suggests,
something we'll do when the world is ready.


There's zero overlap between SCons build users and Meson experience, so 
I don't see how that woul

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Bjorn Helgaas]

On Mon, Mar 13, 2017 at 01:41:36PM +0100, Christian König wrote:
> From: Christian König 
> 
> Try to resize BAR0 to let CPU access all of VRAM.
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
>  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
>  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
>  4 files changed, 40 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 3b81ded..905ded9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device 
> *adev, struct ttm_tt *ttm,
>struct ttm_mem_reg *mem);
>  void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc, 
> u64 base);
>  void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>  void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
>  int amdgpu_ttm_init(struct amdgpu_device *adev);
>  void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 118f4e6..92955fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev, 
> struct amdgpu_mc *mc)
>   mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>  }
>  
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> +{
> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> + int r;
> +
> + r = pci_resize_resource(adev->pdev, 0, size);
> +
> + if (r == -ENOTSUPP) {
> + /* The hardware don't support the extension. */
> + return;
> +
> + } else if (r == -ENOSPC) {
> + DRM_INFO("Not enoigh PCI address space for a large BAR.");

s/enoigh/enough/

> + } else if (r) {
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> + }
> +
> + /* Reinit the doorbell mapping, it is most likely moved as well */

I think you should assume all BARs moved (I don't know how many you have;
maybe this already covers all of them).

> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));

I think things inside BUG_ON() tend to get overlooked, so I avoid things
that have side-effects.  But that's just my personal preference.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] PCI: add functionality for resizing resources v2

[Bjorn Helgaas]

On Mon, Mar 13, 2017 at 01:41:34PM +0100, Christian König wrote:
> From: Christian König 
> 
> This allows device drivers to request resizing their BARs.
> 
> The function only tries to reprogram the windows of the bridge directly above
> the requesting device and only the BAR of the same type (usually mem, 64bit,
> prefetchable). This is done to make sure not to disturb other drivers by
> changing the BARs of their devices.
> 
> If reprogramming the bridge BAR fails the old status is restored and -ENOSPC
> returned to the calling device driver.
> 
> v2: rebase on changes in rbar support
> 
> Signed-off-by: Christian König 
> ---
>  drivers/pci/setup-bus.c | 61 
> +
>  drivers/pci/setup-res.c | 51 +
>  include/linux/pci.h |  2 ++
>  3 files changed, 114 insertions(+)
> 
> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
> index f30ca75..cfab2c7 100644
> --- a/drivers/pci/setup-bus.c
> +++ b/drivers/pci/setup-bus.c
> @@ -1923,6 +1923,67 @@ void pci_assign_unassigned_bridge_resources(struct 
> pci_dev *bridge)
>  }
>  EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);
>  
> +int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
> +{
> + const unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> + IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
> +
> + struct resource saved;
> + LIST_HEAD(add_list);
> + LIST_HEAD(fail_head);
> + struct pci_dev_resource *fail_res;
> + unsigned i;
> + int ret = 0;
> +
> + /* Release all children from the matching bridge resource */
> + for (i = PCI_BRIDGE_RESOURCES; i < PCI_BRIDGE_RESOURCE_END; ++i) {

Nit: use post-increment unless you need pre-increment.

> + struct resource *res = &bridge->resource[i];
> +
> + if ((res->flags & type_mask) != (type & type_mask))
> + continue;
> +
> + saved = *res;
> + if (res->parent) {
> + release_child_resources(res);

Doesn't this recursively release *all* child resources?  There could
be BARs from several devices, or even windows of downstream bridges,
inside this window.  The drivers of those other devices aren't
expecting things to change here.

> + release_resource(res);
> + }
> + res->start = 0;
> + res->end = 0;
> + break;
> + }
> +
> + if (i == PCI_BRIDGE_RESOURCE_END)
> + return -ENOENT;
> +
> + __pci_bus_size_bridges(bridge->subordinate, &add_list);
> + __pci_bridge_assign_resources(bridge, &add_list, &fail_head);
> + BUG_ON(!list_empty(&add_list));
> +
> + /* restore size and flags */
> + list_for_each_entry(fail_res, &fail_head, list) {
> + struct resource *res = fail_res->res;
> +
> + res->start = fail_res->start;
> + res->end = fail_res->end;
> + res->flags = fail_res->flags;
> + }
> +
> + /* Revert to the old configuration */
> + if (!list_empty(&fail_head)) {
> + struct resource *res = &bridge->resource[i];
> +
> + res->start = saved.start;
> + res->end = saved.end;
> + res->flags = saved.flags;
> +
> + pci_claim_resource(bridge, i);
> + ret = -ENOSPC;
> + }
> +
> + free_list(&fail_head);
> + return ret;
> +}
> +
>  void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
>  {
>   struct pci_dev *dev;
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> index 9526e34..3bb1e29 100644
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -363,6 +363,57 @@ int pci_reassign_resource(struct pci_dev *dev, int 
> resno, resource_size_t addsiz
>   return 0;
>  }
>  
> +int pci_resize_resource(struct pci_dev *dev, int resno, int size)
> +{
> + struct resource *res = dev->resource + resno;
> + u32 sizes = pci_rbar_get_possible_sizes(dev, resno);
> + int old = pci_rbar_get_current_size(dev, resno);
> + u64 bytes = 1ULL << (size + 20);
> + int ret = 0;

I think we should fail the request if the device is enabled, i.e., if
the PCI_COMMAND_MEMORY bit is set.  We can't safely change the BAR
while memory decoding is enabled.

I know there's code in pci_std_update_resource() that turns off
PCI_COMMAND_MEMORY, but I think that's a mistake: I think it should
fail when asked to update an enabled BAR the same way
pci_iov_update_resource() does.

I'm not sure why you call pci_reenable_device() below, but I think I
would rather have the driver do something like this:

  pci_disable_device(dev);
  pci_resize_resource(dev, 0, size);
  pci_enable_device(dev);

That way it's very clear to the driver that it must re-read all BARs
after resizing this one.

> + if (!sizes)
> + return -ENOTSUPP;
> +
> + if (!(sizes & (1 << size)))
> + return -EIN

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

[Sean Paul]

On Wed, Mar 22, 2017 at 08:26:07AM -0500, Rob Herring wrote:
> Similar to the previous commit, convert drivers open coding OF graph
> parsing to use drm_of_find_panel_or_bridge instead.
> 
> This changes some error messages to debug messages (in the graph core).
> Graph connections are often "no connects" depending on the particular
> board, so we want to avoid spurious messages. Plus the kernel is not a
> DT validator.
> 
> Signed-off-by: Rob Herring 
> Reviewed-by: Archit Taneja 
> ---
> v3:
> - rebase to v4.11-rc2
> - rework atmel to support 1 to N connections
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_output.c | 73 ++-
>  drivers/gpu/drm/bridge/nxp-ptn3460.c | 16 ++---
>  drivers/gpu/drm/bridge/parade-ps8622.c   | 16 ++---
>  drivers/gpu/drm/bridge/tc358767.c| 27 +--
>  drivers/gpu/drm/exynos/exynos_dp.c   | 35 -
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c| 39 +++---
>  drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 ++-
>  drivers/gpu/drm/imx/imx-ldb.c| 27 ++-
>  drivers/gpu/drm/imx/parallel-display.c   | 36 ++
>  drivers/gpu/drm/mediatek/mtk_dsi.c   | 23 ++
>  drivers/gpu/drm/mxsfb/mxsfb_out.c| 40 ++-
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c  | 26 ++-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c| 11 +--
>  drivers/gpu/drm/sun4i/sun4i_tcon.c   | 90 
> ++--
>  14 files changed, 92 insertions(+), 394 deletions(-)
>


> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> index c3651456c963..511d68e22452 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #include "fsl_dcu_drm_drv.h"
> @@ -141,28 +142,6 @@ static int fsl_dcu_attach_panel(struct 
> fsl_dcu_drm_device *fsl_dev,
>   return ret;
>  }
> 
> -static int fsl_dcu_attach_endpoint(struct fsl_dcu_drm_device *fsl_dev,
> -const struct of_endpoint *ep)
> -{
> - struct drm_bridge *bridge;
> - struct device_node *np;
> -
> - np = of_graph_get_remote_port_parent(ep->local_node);
> -
> - fsl_dev->connector.panel = of_drm_find_panel(np);
> - if (fsl_dev->connector.panel) {
> - of_node_put(np);
> - return fsl_dcu_attach_panel(fsl_dev, fsl_dev->connector.panel);
> - }
> -
> - bridge = of_drm_find_bridge(np);
> - of_node_put(np);
> - if (!bridge)
> - return -ENODEV;
> -
> - return drm_bridge_attach(&fsl_dev->encoder, bridge, NULL);
> -}
> -
>  int fsl_dcu_create_outputs(struct fsl_dcu_drm_device *fsl_dev)
>  {
>   struct of_endpoint ep;
> @@ -179,14 +158,14 @@ int fsl_dcu_create_outputs(struct fsl_dcu_drm_device 
> *fsl_dev)
>   return fsl_dcu_attach_panel(fsl_dev, fsl_dev->connector.panel);
>   }
> 
> - ep_node = of_graph_get_next_endpoint(fsl_dev->np, NULL);
> - if (!ep_node)
> - return -ENODEV;
> -
> - ret = of_graph_parse_endpoint(ep_node, &ep);
> - of_node_put(ep_node);
> + ret = drm_of_find_panel_or_bridge(fsl_dev->np, 0, 0, &panel, &bridge);

Hi Rob,
Apologies for the delay, I've been dealing with overhead the past few days. I 
ran across
this compile error when build testing your set.


../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c: In function
‘fsl_dcu_create_outputs’:
../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:161:56: error: ‘panel’ undeclared
(first use in this function)
../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:161:56: note: each undeclared
identifier is reported only once for each function it appears in
../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:161:64: error: ‘bridge’ undeclared
(first use in this function)
../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:148:22: warning: unused variable
‘ep_node’ [-Wunused-variable]
../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:147:21: warning: unused variable
‘ep’ [-Wunused-variable]
../drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c:171:1: warning: control reaches end
of non-void function [-Wreturn-type]
make[5]: *** [drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.o] Error 1
make[4]: *** [drivers/gpu/drm/fsl-dcu] Error 2
make[4]: *** Waiting for unfinished jobs


The defconfigs we use can be found here:
https://cgit.freedesktop.org/drm/drm-tip/tree/?h=rerere-cache

Sean


>   if (ret)
> - return -ENODEV;
> + return ret;
> 
> - return fsl_dcu_attach_endpoint(fsl_dev, &ep);
> + if (panel) {
> + fsl_dev->connector.panel = panel;
> + return fsl_dcu_attach_panel(fsl_dev, panel);
> + }
> +
> + return drm_bridge_attach(&fsl_dev->encoder, bridge, NULL);



> --
> 2.10.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
__

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 24/03/17 14:22, Daniel Stone wrote:

Hi Jose,

On 24 March 2017 at 14:03, Jose Fonseca  wrote:

On 22/03/17 20:57, Dylan Baker wrote:

Cross compiling for mingw is supported, and it provides a way to
differentiate
the build, host, and target machines [1], I've cross compiled for
aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag
for
this, but the meson approach is to write an ini file once, and use it
again and
again), and the first example of cross compiling is using mingw from linux
[2].


[1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
[2]https://github.com/mesonbuild/meson/wiki/Cross-compilation



Thanks for the info.

It still scares me a bit that most Meson users are mostly Linux focused.


That's not actually true ...

A lot of the reason GStreamer went towards Meson is because it has
native OS X (XCode project) and Windows (MinGW or Visual Studio
project) support. Meson's own source tree goes out of its way to use
spaces in directory and file names for its test suite, to make sure
that that support never breaks. Every build of Meson is CI'd on
AppVeyor as well as Travis for OS X. And of course, the GStreamer CI
uses Meson for its non-Linux builds.

It's true that a lot of the projects taking an interest of late have
been Linux, yes. But if you're native to Windows / OS X, you just use
VS/Xcode. There are (IMO) very few properly cross-platform projects
who are 'Windows projects with a port' or 'mainly OS X but also runs
on Linux', rather than cross-platform 'Linux projects'.


OK.


Another tool I heard good about but have not direct experience is
https://bazel.build .  Any thoughts about it?


If you look at the FAQ, one of the first things you'll see is that
they don't properly support Windows. It also requires Java to run,
which I'd say would be a no-go if people are already complaining about
the impossibility of installing several megabytes of Python stdlib.


I see.  Indeed.


Thanks.  From the label on the tin, it does sound like Meson ticks a lot 
of boxes then.



Like I said in another email, maybe mesademos is a good way to get our 
feet wet.


I can't guarantee I'll be able to dedicate much time, but at least get 
AppVeyor builds of it, since it has been a long objective of mine to get 
mesademos/piglit/etc builds on AppVeyor instead of a private Jenkins server.



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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 24/03/17 20:08, Kristian Høgsberg wrote:

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca  wrote:

On 24/03/17 19:10, Kristian Høgsberg wrote:


On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:


On 23/03/17 01:38, Rob Clark wrote:



On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:



On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:



On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
wrote:



I guess I'm a little late to the party here, but I haven't had time
to
really let all of this sink in and actually look at meson.  It
doesn't
seem so bad with a quick look and I think I could probably sort it
out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar
enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a
big
problem in my opinion.




One of the things that's prompted this on our side (I've talked this
over with
other people at Intel before starting), was that clearly we *don't*
know
autotools well enough to get it right. Emil almost always finds cases
were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs
and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same
logic.


Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal
with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have
years
of investment in existing tools.




Sure, but we're also not the only ones investigating meson. Gnome is
using it
already, libepoxy is using it, gstreamer is using it. There are
patches
for
weston (written by Daniel Stone) and libinput (written by Peter
Hutterer), there
are some other projects in the graphics sphere that people are working
on. So
even if we as a community decide that meson isn't for us, it's not
going
away.




It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new
maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.



but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

BR,
-R




I tend to disagree.  While we can't avoid a transitory period, when we
embark on another build system (Meson or something else) I think we
should
aim at 1) ensure such tool can indeed _completely_ replace at least _one_
existing build system, 2) and aim at migration quickly.

Otherwise we'll just end up with yet another build system, yet another
way
builds can fail, with some developers stuck on old build systems because
it
works, or because the new build system quite doesn't work.

And this is from (painful) experience.



I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start using meson, which means that life gets easier for
vmware wrt maintaining the build system, and easier for all developers
who have spent to much of their life waiting for autogen.sh.  Then
decommissioning autotools can be a separate topic as Rob suggests,
something we'll do when the worl

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

[Tony Lindgren]

* Sebastian Reichel  [170304 16:45]:
> Add basic panel support for the Nokia N950. It must be tweaked a
> little bit later, since the panel was built into the device
> upside-down. Also the first 5 and the last 5 pixels are covered
> by plastic.

This one seems safe to apply separately to shrink the pending
patches a bit. Please confirm if that's the case and I'll apply
this one.

Regards,

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jason Ekstrand]

On Fri, Mar 24, 2017 at 2:16 PM, Jose Fonseca  wrote:

> On 24/03/17 20:08, Kristian Høgsberg wrote:
>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca 
>> wrote:
>>
>>> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>>

 On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca 
 wrote:

>
> On 23/03/17 01:38, Rob Clark wrote:
>
>>
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>
>>>
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>>


 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher <
 alexdeuc...@gmail.com>
 wrote:

>
>
> I guess I'm a little late to the party here, but I haven't had time
> to
> really let all of this sink in and actually look at meson.  It
> doesn't
> seem so bad with a quick look and I think I could probably sort it
> out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar
> enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration
> based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we
> have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a
> big
> problem in my opinion.
>



 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't*
 know
 autotools well enough to get it right. Emil almost always finds
 cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the
 docs
 and
 writing the libdrm port to get it right, and a lot of that is just
 the
 boilerplate of having ~8 drivers that all need basically the same
 logic.

 Next, my bigger concern is for distro and casual packagers and
> people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require
> many
> of these existing tools and systems to be rewritten and then deal
> with
> the debugging and fall out from that.  The potential decreased
> build
> time is a nice bonus, but frankly a lot of people/companies have
> years
> of investment in existing tools.
>



 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are
 patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are
 working
 on. So
 even if we as a community decide that meson isn't for us, it's not
 going
 away.

>>>
>>>
>>>
>>> It is worth pointing out that it is currently required by no
>>> component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>>
>
>
>
> I tend to disagree.  While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I th

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Jose Fonseca]

On 23/03/17 01:38, Rob Clark wrote:

On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:

On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:

On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher  wrote:

I guess I'm a little late to the party here, but I haven't had time to
really let all of this sink in and actually look at meson.  It doesn't
seem so bad with a quick look and I think I could probably sort it out
when the time came, but there would still be a bit of a learning
curve.  While that may not be a big deal at the micro level, I have
concerns at the macro level.

First, I'm concerned it may discourage casual developers and
packagers.  autotools isn't great, but most people are familiar enough
with it that they can get by.  Most people have enough knowledge of
autotools that they can pretty easily diagnose a configuration based
failure. There are a lot of resources for autotools.  I'm not sure
that would be the case for meson.  Do we as a community feel we have
enough meson experience to get people over the hump?  Anything that
makes it harder for someone to try a new build or do a bisect is a big
problem in my opinion.


One of the things that's prompted this on our side (I've talked this over with
other people at Intel before starting), was that clearly we *don't* know
autotools well enough to get it right. Emil almost always finds cases were we've
done things *almost*, but not quite right.

For my part, it took me about 3 or 4 days of reading through the docs and
writing the libdrm port to get it right, and a lot of that is just the
boilerplate of having ~8 drivers that all need basically the same logic.


Next, my bigger concern is for distro and casual packagers and people
that maintain large build systems with lots of existing custom
configurations.  Changing from autotools would basically require many
of these existing tools and systems to be rewritten and then deal with
the debugging and fall out from that.  The potential decreased build
time is a nice bonus, but frankly a lot of people/companies have years
of investment in existing tools.


Sure, but we're also not the only ones investigating meson. Gnome is using it
already, libepoxy is using it, gstreamer is using it. There are patches for
weston (written by Daniel Stone) and libinput (written by Peter Hutterer), there
are some other projects in the graphics sphere that people are working on. So
even if we as a community decide that meson isn't for us, it's not going away.


It is worth pointing out that it is currently required by no component
of an x.org stack.  In the case of libepoxy it was added by a new maintainer
on a new release and even then autoconf remains.

And as far as I can tell nothing in the entire OpenBSD ports tree
currently requires meson to build including gnome and gstreamer.



but I guess that is conflating two completely different topics..
addition of meson and removal of autotools.  It is probably better
that we treat the topics separately.  I don't see any way that the two
can happen at the same time.

The autotools build probably needs to remain for at least a couple
releases, and I certainly wouldn't mind if some of the other desktop
projects took the leap of dropping autotools first (at least then
various different "distro" consumers will have already dealt with how
to build meson packages)

None of that blocks addition of a meson build system (or what various
developers use day to day)

BR,
-R


I tend to disagree.  While we can't avoid a transitory period, when we 
embark on another build system (Meson or something else) I think we 
should aim at 1) ensure such tool can indeed _completely_ replace at 
least _one_ existing build system, 2) and aim at migration quickly.


Otherwise we'll just end up with yet another build system, yet another 
way builds can fail, with some developers stuck on old build systems 
because it works, or because the new build system quite doesn't work.


And this is from (painful) experience.



So I think we should identify stake holders soon, collect requirements 
(OSes platforms, etc), make sure the prospective tool meets them, have 
all stakeholders collaborate on a prototype, them embark on mass migration.


That is, if this fails, let it fail early.  If it succeeds, may it 
succeed early.  Anything but a slow death / zombie life.





BTW, how about migrating mesademos to Meson?  It currently has autotools 
and cmake.  I was hoping that cmake would replace autotools, but I 
couldn't run fast enough, so I couldn't practice what preached above, 
hence cmake doing almost but not all what autotools does.


And is not a crucial project for Linux distros -- few distros package it 
-- and even if they do, no other package would depend on it.  And is one 
of those sort of projects that should be easy to port to any build too.


Even if we ignore everything else, just replacing autotools + cmake with 
just one thing would be a net win.



Jose
___

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

[Tony Lindgren]

* Tomi Valkeinen  [170324 08:01]:
> On 24/03/17 16:29, Tony Lindgren wrote:
> > * Sebastian Reichel  [170304 16:45]:
> >> Add basic panel support for the Nokia N950. It must be tweaked a
> >> little bit later, since the panel was built into the device
> >> upside-down. Also the first 5 and the last 5 pixels are covered
> >> by plastic.
> > 
> > This one seems safe to apply separately to shrink the pending
> > patches a bit. Please confirm if that's the case and I'll apply
> > this one.
> 
> No, I think there are too many open questions to apply this one. And we
> need to move to common DRM drivers at some point (hopefully soon) so the
> bindings must be aligned with those if and when possible.

Hmm so what are the open questions and do you have in mind for
the panel bindings?

Naturally we still need to support the current bindings too.

Regards,

Tony


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

Re: [PATCH 1/4] PCI: add resizeable BAR infrastructure v3

[Bjorn Helgaas]

On Mon, Mar 13, 2017 at 01:41:33PM +0100, Christian König wrote:
> From: Christian König 
> 
> Just the defines and helper functions to read the possible sizes of a BAR and
> update it's size.

s/it's/its/

> See 
> https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf.

It's good to have the public ECN that anybody can read, but we should
also have a reference to the full spec that incorporates it, e.g.,
PCIe r3.1, sec 7.22.

> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1946,6 +1946,9 @@ void pci_request_acs(void);
>  bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags);
>  bool pci_acs_path_enabled(struct pci_dev *start,
> struct pci_dev *end, u16 acs_flags);
> +u32 pci_rbar_get_possible_sizes(struct pci_dev *pdev, int bar);
> +int pci_rbar_get_current_size(struct pci_dev *pdev, int bar);
> +int pci_rbar_set_size(struct pci_dev *pdev, int bar, int size);

These should be declared in drivers/pci/pci.h unless they're needed
outside drivers/pci.  I hope they aren't needed outside, because
they're not safe to use after the PCI core has claimed resources.

>  #define PCI_VPD_LRDT 0x80/* Large Resource Data Type */
>  #define PCI_VPD_LRDT_ID(x)   ((x) | PCI_VPD_LRDT)
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index e5a2e68..6de29d6 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -932,9 +932,16 @@
>  #define PCI_SATA_SIZEOF_LONG 16
>  
>  /* Resizable BARs */
> +#define PCI_REBAR_CAP4   /* capability register */
> +#define  PCI_REBAR_CTRL_SIZES_MASK   (0xF << 4)  /* mask for sizes */
> +#define  PCI_REBAR_CTRL_SIZES_SHIFT  4   /* shift for sizes */
>  #define PCI_REBAR_CTRL   8   /* control register */
> +#define  PCI_REBAR_CTRL_BAR_IDX_MASK (7 << 0)/* mask for bar index */
> +#define  PCI_REBAR_CTRL_BAR_IDX_SHIFT0   /* shift for bar index 
> */
>  #define  PCI_REBAR_CTRL_NBAR_MASK(7 << 5)/* mask for # bars */
>  #define  PCI_REBAR_CTRL_NBAR_SHIFT   5   /* shift for # bars */
> +#define  PCI_REBAR_CTRL_BAR_SIZE_MASK(0x1F << 8) /* mask for bar 
> size */
> +#define  PCI_REBAR_CTRL_BAR_SIZE_SHIFT   8   /* shift for bar size */

s/bar/BAR/ several places above

>  /* Dynamic Power Allocation */
>  #define PCI_DPA_CAP  4   /* capability register */
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

[Tony Lindgren]

* Tomi Valkeinen  [170324 08:22]:
> On 24/03/17 17:12, Tony Lindgren wrote:
> > * Tomi Valkeinen  [170324 08:01]:
> >> On 24/03/17 16:29, Tony Lindgren wrote:
> >>> * Sebastian Reichel  [170304 16:45]:
>  Add basic panel support for the Nokia N950. It must be tweaked a
>  little bit later, since the panel was built into the device
>  upside-down. Also the first 5 and the last 5 pixels are covered
>  by plastic.
> >>>
> >>> This one seems safe to apply separately to shrink the pending
> >>> patches a bit. Please confirm if that's the case and I'll apply
> >>> this one.
> >>
> >> No, I think there are too many open questions to apply this one. And we
> >> need to move to common DRM drivers at some point (hopefully soon) so the
> >> bindings must be aligned with those if and when possible.
> > 
> > Hmm so what are the open questions and do you have in mind for
> > the panel bindings?
> 
> Well, until we have driver that supports the panel without problems, we
> can't be sure if we have everything in the binding. At least the TE was
> missing or broken.

Sure, I don't think that needs a binding though?

> Normal videotimings don't really make sense for DSI command mode panels,
> so I'm not overly enthusiastic in having them in the bindings. Possibly
> that's the easy way to go, but I'm not sure yet.

Are you talking about passing the clock-frequency = <0> where
dsi calculates it or also some other things too?

> There are the "TODO" parts in the bindings, that's a clear sign of open
> questions.

Yeah the default rotation part seems to be completely open :)
We should probably stick with just kernel cmdline for that for
now until there is some generic solution.

> I haven't looked at how the other DRM drivers handle DSI command mode
> panels. That's something to study, before adding anything new to the
> omap specific bindings.

OK. I suggest we just stick to standard existing bindings for now.

> > Naturally we still need to support the current bindings too.
> 
> Do the current bindings work? I guess they did work on omapfb... Do
> these new bindings work with omapfb?

Well yeah in general they work just fine for the basic resolution +
clock + control GPIOs. I think that binding is just fine. So we should
probably stick to that before adding more stuff.

For command mode panels, looking at patch 1 of this series we always
had the resolution hardcoded into the driver.. And talking about
patch 1, do you also have some issues with it other than that typo there
pointed out by Pavel?

> Generally speaking, I've been bitten badly enough with DT bindings that
> weren't up to the task after all, and then changing the later was a
> major pain (or working around it). So I'd rather not merge anything to
> DT if there are any unclarities, and a driver not working which uses
> those bindings is an unclarity. Especially if the only reason to merge
> is to get a single patch out from a bigger patch series, without
> actually enabling anything.

Sure. The solution there is to just stick to basics until with the
binding until things are clear. So in this case resolutions + clocks +
control GPIOs + regulators. Those all are existing standard bindings
that can easily be supported.

Regards,

Tony


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-24 14:16:13)
> 
> Evaluating is one thing.  Actually migrating is another.
> 
> Brian already said he'd take a look and evaluate.  And I'll help in what 
> I can.  I agree we should all evaluate early.
> 
> 
> But I don't think that the proposal of first migrate scons to meson, 
> then in a second separate step migrate autotools to meson, is viable. 
> Like I said: there's no knowledge overlap.  The two group of people -- 
> the Meson and Windows experts -- will be chasing each other tails.  And 
> all that while, the build will continue to be broken or diverge because 
> master dev will go on.
> 
> 
> Jose

https://github.com/dcbaker/mesa-demos wip/meson

I've blindly ported some of the windows bits but have no way to test them, so
you can either delete the lot and go from scratch or see what's left to fix (the
wgl folder, for example). I have not implemented much of the windows or apple
logic in the root CMakeLists.txt, so hopefully that's useful for your purposes.

That branch also builds on my Archlinux machine, but not on debian due to
difference in the way they package freeglut I just ran out of time today. For
the record, I started at about 12:00, and finished at about 17:00 with a 1 hour
lunch in there. So about 3 hours to get a mostly working build. I'm going to try
to iron out the debian and travis issues either over the weekend or next week.

There is one difference, because ninja is non-recursive some targets would have
the same name and collide, so I've renamed some of the not installed binaries. I
believe that a non-recursive make (such as one generated by cmake) would have
the same problem. meson doesn't seem to have a method to rename the target, but
it's also a bit of an odd corner to build multiple binaries with the same name
that are both not installed and are for people (not automated build steps) to
use.

I also have a not quite working .travis.yml on that branch.

I'm also planning to get a mesa RFC sent out early next week once I get i965 and
llvmpipe building.

If we merge mesa we (Intel) will move to using meson as our primary build system
in CI (the one we run tests against) as soon as it's ready. Building mesa is
quite slow for us considering the power of our build hardware, and meson should
help with that. We'll continue to build autotools much the way we do scons now,
as a secondary "buildtest" only target.

Dylan

> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


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

[Bug 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

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

Felix Schwarz (felix.schw...@oss.schwarz.eu) changed:

   What|Removed |Added

 CC||felix.schwarz@oss.schwarz.e
   ||u

--- Comment #13 from Felix Schwarz (felix.schw...@oss.schwarz.eu) ---
> I continue to bisect but do you know to pass the UUID not found.

You could try to find the exact commit which fixed the harddrive detection (at
worst by bisecting it). If the fix is sufficiently simple you can apply at for
every bisection step. This makes bisection a bit harder but if the fix is easy
this should be doable even for non-developers.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/16] drm: document drm_ioctl.[hc]

[kbuild test robot]

Hi Daniel,

[auto build test WARNING on drm/drm-next]
[cannot apply to v4.11-rc3 next-20170324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/more-drmP-h-cleanup/20170325-030940
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick 
(https://www.imagemagick.org)
   include/linux/init.h:1: warning: no structured comments found
   kernel/sched/core.c:2085: warning: No description found for parameter 'rf'
   kernel/sched/core.c:2085: warning: Excess function parameter 'cookie' 
description in 'try_to_wake_up_local'
   include/linux/kthread.h:26: warning: Excess function parameter '...' 
description in 'kthread_create'
   kernel/sys.c:1: warning: no structured comments found
   include/linux/device.h:969: warning: No description found for parameter 
'dma_ops'
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/linux/iio/iio.h:597: warning: No description found for parameter 
'trig_readonly'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'indio_dev'
   include/linux/iio/trigger.h:151: warning: No description found for parameter 
'trig'
   include/linux/device.h:970: warning: No description found for parameter 
'dma_ops'
   drivers/regulator/core.c:1467: warning: Excess function parameter 'ret' 
description in 'regulator_dev_lookup'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'patchlevel'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'name'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'desc'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'date'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'driver_features'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 
'num_ioctls'
   include/drm/drm_drv.h:524: warning: No description found for parameter 'fops'
   include/drm/drm_connector.h:138: warning: No description found for parameter 
'scdc'
   include/drm/drm_color_mgmt.h:1: warning: no structured comments found

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Fri, Mar 24, 2017 at 5:16 PM, Jose Fonseca  wrote:
> On 24/03/17 20:08, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca 
>> wrote:
>>>
>>> On 24/03/17 19:10, Kristian Høgsberg wrote:


 On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca 
 wrote:
>
>
> On 23/03/17 01:38, Rob Clark wrote:
>>
>>
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>>
>>>
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:



 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher
 
 wrote:
>
>
>
> I guess I'm a little late to the party here, but I haven't had time
> to
> really let all of this sink in and actually look at meson.  It
> doesn't
> seem so bad with a quick look and I think I could probably sort it
> out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar
> enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration
> based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we
> have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a
> big
> problem in my opinion.




 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't*
 know
 autotools well enough to get it right. Emil almost always finds
 cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the
 docs
 and
 writing the libdrm port to get it right, and a lot of that is just
 the
 boilerplate of having ~8 drivers that all need basically the same
 logic.

> Next, my bigger concern is for distro and casual packagers and
> people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require
> many
> of these existing tools and systems to be rewritten and then deal
> with
> the debugging and fall out from that.  The potential decreased
> build
> time is a nice bonus, but frankly a lot of people/companies have
> years
> of investment in existing tools.




 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are
 patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are
 working
 on. So
 even if we as a community decide that meson isn't for us, it's not
 going
 away.
>>>
>>>
>>>
>>>
>>> It is worth pointing out that it is currently required by no
>>> component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
>
>
> I tend to disagree.  While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we
> should
>

[PATCH 1/3] drm/i915: Use LINEAR modifier instead of NONE

[Ben Widawsky]

They're the same, so use the one which makes more sense.

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9a28a8917dc1..696d106461f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1997,7 +1997,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int plane)
unsigned int cpp = fb->format->cpp[plane];
 
switch (fb->modifier) {
-   case DRM_FORMAT_MOD_NONE:
+   case DRM_FORMAT_MOD_LINEAR:
return cpp;
case I915_FORMAT_MOD_X_TILED:
if (IS_GEN2(dev_priv))
@@ -2033,7 +2033,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb, 
int plane)
 static unsigned int
 intel_tile_height(const struct drm_framebuffer *fb, int plane)
 {
-   if (fb->modifier == DRM_FORMAT_MOD_NONE)
+   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
return 1;
else
return intel_tile_size(to_i915(fb->dev)) /
@@ -2107,7 +2107,7 @@ static unsigned int intel_surf_alignment(const struct 
drm_framebuffer *fb,
return 4096;
 
switch (fb->modifier) {
-   case DRM_FORMAT_MOD_NONE:
+   case DRM_FORMAT_MOD_LINEAR:
return intel_linear_alignment(dev_priv);
case I915_FORMAT_MOD_X_TILED:
if (INTEL_GEN(dev_priv) >= 9)
@@ -2290,7 +2290,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
 
WARN_ON(new_offset > old_offset);
 
-   if (fb->modifier != DRM_FORMAT_MOD_NONE) {
+   if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
unsigned int tile_size, tile_width, tile_height;
unsigned int pitch_tiles;
 
@@ -2345,7 +2345,7 @@ static u32 _intel_compute_tile_offset(const struct 
drm_i915_private *dev_priv,
if (alignment)
alignment--;
 
-   if (fb_modifier != DRM_FORMAT_MOD_NONE) {
+   if (fb_modifier != DRM_FORMAT_MOD_LINEAR) {
unsigned int tile_size, tile_width, tile_height;
unsigned int tile_rows, tiles, pitch_tiles;
 
@@ -2471,7 +2471,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
DRM_ROTATE_0, tile_size);
offset /= tile_size;
 
-   if (fb->modifier != DRM_FORMAT_MOD_NONE) {
+   if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
unsigned int tile_width, tile_height;
unsigned int pitch_tiles;
struct drm_rect r;
@@ -2803,7 +2803,7 @@ static int skl_max_plane_width(const struct 
drm_framebuffer *fb, int plane,
int cpp = fb->format->cpp[plane];
 
switch (fb->modifier) {
-   case DRM_FORMAT_MOD_NONE:
+   case DRM_FORMAT_MOD_LINEAR:
case I915_FORMAT_MOD_X_TILED:
switch (cpp) {
case 8:
@@ -3199,7 +3199,7 @@ static void ironlake_update_primary_plane(struct 
drm_plane *primary,
 static u32
 intel_fb_stride_alignment(const struct drm_framebuffer *fb, int plane)
 {
-   if (fb->modifier == DRM_FORMAT_MOD_NONE)
+   if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
return 64;
else
return intel_tile_width_bytes(fb, plane);
@@ -3298,7 +3298,7 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
 static u32 skl_plane_ctl_tiling(uint64_t fb_modifier)
 {
switch (fb_modifier) {
-   case DRM_FORMAT_MOD_NONE:
+   case DRM_FORMAT_MOD_LINEAR:
break;
case I915_FORMAT_MOD_X_TILED:
return PLANE_CTL_TILED_X;
@@ -8426,7 +8426,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
tiling = val & PLANE_CTL_TILED_MASK;
switch (tiling) {
case PLANE_CTL_TILED_LINEAR:
-   fb->modifier = DRM_FORMAT_MOD_NONE;
+   fb->modifier = DRM_FORMAT_MOD_LINEAR;
break;
case PLANE_CTL_TILED_X:
plane_config->tiling = I915_TILING_X;
@@ -10399,7 +10399,7 @@ static void skl_do_mmio_flip(struct intel_crtc 
*intel_crtc,
ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
switch (fb->modifier) {
-   case DRM_FORMAT_MOD_NONE:
+   case DRM_FORMAT_MOD_LINEAR:
break;
case I915_FORMAT_MOD_X_TILED:
ctl |= PLANE_CTL_TILED_X;
@@ -13756,7 +13756,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
return -ENOMEM;
}
 
-   if (fb->modifier != DRM_FORMAT_MOD_NONE) {
+   if (fb->modifier != DRM_FORMAT_MOD_LINEAR) {
DRM_DEBUG_KMS("cursor cannot be tiled\n");
return -EINVAL;
}
@@ -14412,7 +14412,7 @@ static int intel_framebuffer_init(struct 
intel_framebuffer *intel_fb,
  

[PATCH 3/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

Cc: Ville Syrjälä 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 112 +--
 drivers/gpu/drm/i915/intel_sprite.c  |  25 +++-
 2 files changed, 131 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 802a8449c5d3..bb559a116fda 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i9xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED,
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13453,6 +13467,83 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   (modifier >= I915_FORMAT_MOD_X_TILED &&
+modifier < I915_FORMAT_MOD_Yf_TILED);
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   (modifier >= I915_FORMAT_MOD_X_TILED &&
+   modifier <= I915_FORMAT_MOD_Yf_TILED);
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   return modifier == DRM_FORMAT_MOD_LINEAR;
+   default:
+   return false;
+   }
+
+}
+
+static bool intel_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return skl_mod_supported(format, modifier);
+   else if (INTEL_GEN(dev_priv) >= 4)
+   return i965_mod_supported(format, modifier);
+   else
+   return i8xx_mod_supported(format, modifier);
+
+   return false;
+}
+
 const struct drm_plane_funcs intel_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
@@ -13462,6 +13553,7 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
+   .format_mod_supported = intel_plane_format_mod_supported,
 };
 
 static int
@@ -13598,6 +13690,7 @@ static const struct drm_plane_funcs 
intel_cursor_plane_funcs = {
.atomic_set_property = intel_plane_atomic_set_property,
.atomic_duplicate

[PATCH 2/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Ben Widawsky]

Originally based off of a patch by Kristian.

This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
about the modifiers that will work with each format.

It's modified from Kristian's patch in that the modifiers and formats
are setup by the driver, and then a callback is used to create the
format list. The LOC was enough difference that I don't think it made
sense to leave his authorship, but the new UABI was primarily his idea.

Additionally, I hit a couple of drivers which Kristian missed updating.

It also contains a change requested by Daniel to make the modifiers
array a sentinel based structure instead of a sized one. Upon discussion
on IRC, it was determined that having an invalid modifier might make
sense in general as well.

v2:
  - Make formats uint32_t, and use an offset, see the comment in the
  patch. Add a WARN_ON and early bail for when there are more than 32
  formats. (Rob)
  - Remove DRM_DEBUG_KMS (Ville)
  - make flags come before count in struct (Ville)

v3:
  - Make formats 64b again to defer the pain, and add a pad
  - Make init fail if > 64 instead of at get_plane. This could be made
  more optimal by doing it in get_plane because 0 masked modifiers don't
  need to be reported back to userspace. As a result, the first driver
  to go back 64 formats has to deal with this.
  - Fix the comment to be more clear.

v4:
  - Add drivers/gpu/drm/qxl/

Cc: Rob Clark 
Cc: Ville Syrjälä 
Cc: Daniel Stone 
Cc: "Kristian H. Kristensen" 
References: https://patchwork.kernel.org/patch/9482393/
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c|  1 +
 drivers/gpu/drm/armada/armada_overlay.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +-
 drivers/gpu/drm/drm_ioctl.c |  2 +-
 drivers/gpu/drm/drm_modeset_helper.c|  1 +
 drivers/gpu/drm/drm_plane.c | 67 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  3 ++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  7 ++-
 drivers/gpu/drm/i915/intel_sprite.c |  4 +-
 drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +-
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 +-
 drivers/gpu/drm/omapdrm/omap_plane.c|  3 +-
 drivers/gpu/drm/qxl/qxl_display.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +-
 drivers/gpu/drm/sti/sti_cursor.c|  2 +-
 drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  | 12 ++---
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_plane.h | 21 +++-
 include/drm/drm_simple_kms_helper.h |  1 +
 include/uapi/drm/drm.h  |  1 +
 include/uapi/drm/drm_fourcc.h   | 11 
 include/uapi/drm/drm_mode.h | 44 
 41 files changed, 200 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..cd8a24c7c67d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
drm_device *drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 798a3cc480a2..0caa03ae8708 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device 
*drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs,

Re: [PATCH 15/16] drm/vblank: Simplify the get_scanout_position helper hook

[kbuild test robot]

Hi Daniel,

[auto build test WARNING on drm/drm-next]
[cannot apply to v4.11-rc3 next-20170324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/more-drmP-h-cleanup/20170325-030940
base:   git://people.freedesktop.org/~airlied/linux.git drm-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/nouveau/nouveau_display.c:154:8-9: WARNING: return of 0/1 in 
>> function 'nouveau_display_scanoutpos' with return type bool

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vblank: fix boolreturn.cocci warnings

[kbuild test robot]

drivers/gpu/drm/nouveau/nouveau_display.c:154:8-9: WARNING: return of 0/1 in 
function 'nouveau_display_scanoutpos' with return type bool

 Return statements in functions returning bool should use
 true/false instead of 1/0.
Generated by: scripts/coccinelle/misc/boolreturn.cocci

CC: Daniel Vetter 
Signed-off-by: Fengguang Wu 
---

 nouveau_display.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -151,7 +151,7 @@ nouveau_display_scanoutpos(struct drm_de
}
}
 
-   return 0;
+   return false;
 }
 
 static void
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Rob Clark]

On Fri, Mar 24, 2017 at 3:10 PM, Kristian Høgsberg  wrote:
> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
>> On 23/03/17 01:38, Rob Clark wrote:
>>>
>>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:

 On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>
> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
> wrote:
>>
>> I guess I'm a little late to the party here, but I haven't had time to
>> really let all of this sink in and actually look at meson.  It doesn't
>> seem so bad with a quick look and I think I could probably sort it out
>> when the time came, but there would still be a bit of a learning
>> curve.  While that may not be a big deal at the micro level, I have
>> concerns at the macro level.
>>
>> First, I'm concerned it may discourage casual developers and
>> packagers.  autotools isn't great, but most people are familiar enough
>> with it that they can get by.  Most people have enough knowledge of
>> autotools that they can pretty easily diagnose a configuration based
>> failure. There are a lot of resources for autotools.  I'm not sure
>> that would be the case for meson.  Do we as a community feel we have
>> enough meson experience to get people over the hump?  Anything that
>> makes it harder for someone to try a new build or do a bisect is a big
>> problem in my opinion.
>
>
> One of the things that's prompted this on our side (I've talked this
> over with
> other people at Intel before starting), was that clearly we *don't* know
> autotools well enough to get it right. Emil almost always finds cases
> were we've
> done things *almost*, but not quite right.
>
> For my part, it took me about 3 or 4 days of reading through the docs
> and
> writing the libdrm port to get it right, and a lot of that is just the
> boilerplate of having ~8 drivers that all need basically the same logic.
>
>> Next, my bigger concern is for distro and casual packagers and people
>> that maintain large build systems with lots of existing custom
>> configurations.  Changing from autotools would basically require many
>> of these existing tools and systems to be rewritten and then deal with
>> the debugging and fall out from that.  The potential decreased build
>> time is a nice bonus, but frankly a lot of people/companies have years
>> of investment in existing tools.
>
>
> Sure, but we're also not the only ones investigating meson. Gnome is
> using it
> already, libepoxy is using it, gstreamer is using it. There are patches
> for
> weston (written by Daniel Stone) and libinput (written by Peter
> Hutterer), there
> are some other projects in the graphics sphere that people are working
> on. So
> even if we as a community decide that meson isn't for us, it's not going
> away.


 It is worth pointing out that it is currently required by no component
 of an x.org stack.  In the case of libepoxy it was added by a new
 maintainer
 on a new release and even then autoconf remains.

 And as far as I can tell nothing in the entire OpenBSD ports tree
 currently requires meson to build including gnome and gstreamer.

>>>
>>> but I guess that is conflating two completely different topics..
>>> addition of meson and removal of autotools.  It is probably better
>>> that we treat the topics separately.  I don't see any way that the two
>>> can happen at the same time.
>>>
>>> The autotools build probably needs to remain for at least a couple
>>> releases, and I certainly wouldn't mind if some of the other desktop
>>> projects took the leap of dropping autotools first (at least then
>>> various different "distro" consumers will have already dealt with how
>>> to build meson packages)
>>>
>>> None of that blocks addition of a meson build system (or what various
>>> developers use day to day)
>>>
>>> BR,
>>> -R
>>
>>
>> I tend to disagree.  While we can't avoid a transitory period, when we
>> embark on another build system (Meson or something else) I think we should
>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>> existing build system, 2) and aim at migration quickly.
>>
>> Otherwise we'll just end up with yet another build system, yet another way
>> builds can fail, with some developers stuck on old build systems because it
>> works, or because the new build system quite doesn't work.
>>
>> And this is from (painful) experience.
>
> I agree, adding a meson build system should aim to phase out one of
> the other build systems within one or two release cycles. But (and
> maybe that was Robs point) that doesn't have be autotools. What if we
> phase out scons? It doesn't seem like anybody is really attached to it
> and if meson is as good as scons on windows, then if nothing else
> happens we end up with the same number of b

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Chad Versace]

On Tue 21 Mar 2017, Matt Turner wrote:
> On Tue, Mar 21, 2017 at 10:16 AM, Emil Velikov  
> wrote:
> > On 21 March 2017 at 15:57, Matt Turner  wrote:
> >> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
> >> wrote:
> >>> On 20 March 2017 at 18:30, Matt Turner  wrote:
>  On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
>  wrote:


> Let me try one last time:
> 
> (1) Non-recursive automake is necessary for parallel build performance
> (2) Non-recursive automake is intractably unmaintainable for
> sufficiently large projects
> (3) Mesa is a sufficiently large project
> 
> Therefore using automake will be either bad for parallel build
> performance, unmaintainable, or both.
> 
> Meson aims to be a build system actually capable of replacing
> autotools (IMO unlike cmake, scons, waf, et al.). It offers a much
> cleaner domain specific language for writing the build rules, while
> generating non-recursive ninja build files. It does not use libtool.
> It supports Windows. It supports cross compilation.
> 
> And it has momentum: libepoxy already has a Meson build system. Others
> in the X.Org community are experimenting with it for libinput, Wayland
> and Weston, and the xserver.
> 
> All of that makes Meson very compelling.

Matt, I just wanted to say thanks for capturing in a nutshell the
argument for a Meson trial.

I want Meson because my builds are too slow. I regularly build an entire
fucking operating system from scratch (Chrome OS), and I cry when top
shows only 1 core at 100% and the other 47 cores sitting idle.

Autotools and libtool are often the culprit. The libtool penalty is paid
on every build, not just at configure time.

The only way to get all 48 cores closer to 100% is to (1) use
a non-recursive build system that (2) doesnt' use shell nor (3) libtool.

I don't care about new shiny. I'm often wary of new shiny things that
receive too much excitement.  Meson is a such a new shiny. But I'm
willing to overlook my aversion to new shiny Meson's immaturity if
it makes Chrome OS build faster... at least for Mesa.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Chad Versace]

On Tue 21 Mar 2017, Matt Turner wrote:
> On Mon, Mar 20, 2017 at 12:39 PM, Emil Velikov  
> wrote:
> > On 20 March 2017 at 18:30, Matt Turner  wrote:
> >> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov  
> >> wrote:

> >>> These projects have been getting closer to upstream and "forcing" the
> >>> extra obstacle is effectively giving them the middle finger.
> >>
> >> No. Requiring us to compile with a 10 year old GCC is giving a middle 
> >> finger.
> >>
> > Can we stop with the GCC thing ? Can we point to a place where we want
> > to use feature A introduced with GCC B and we don't ?
> 
> Are you freaking serious?!
> 
> This happens *all* the time. It happened like two days ago with commit
> 28b134c75c1fa3b2aaa00dc168f0eca35ccd346d. I'm sure it probably
> happened at least once in the previous month, and every month before
> that.

More examples:

- Jason and I wanted to use C11 generic expressions (that's what the
  C11 spec calls them) in anvil, but old GCC => !C11.

- I *still* want to use _Generic.

- If we could use C11, then we could stop using the
  include/c11/thread.h wrapper for the C11 thread features. We could use,
  you know, *real* C11 threads instead of faking it.

- I want to do this:

  #define let __auto_type

  But __auto_type requires GCC 4.9
   or a comparably dated clang.

- I want to use GCC's builtin overflow arithmetic functions
   (such 
as
  __builtin_mul_overflow(), __builtin_add_overflow) where we currently do 
overflow checking by hand.
  The builtin functions are more secure (no chance of stupid mistakes) and
  faster (they simply do the arithmetic op then test the overflow flag in 
the
  CPU's status register).

- I tend to be guilty occasionally breaking the build in
  anvil code, due to old GCC. I think it happened again again this week:

freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
vulkan/anv_device.c:697:4: error: initializer element is not constant
freenode.#dri-devel.log-2017-03-16 11:07:12 | imirkin_ | 
.minImageTransferGranularity = (VkExtent3D) { 1, 1, 1 },
freenode.#dri-devel.log-2017-03-16 11:07:23 | imirkin_ | anyone seen 
this? i'm on HEAD
freenode.#dri-devel.log-2017-03-16 11:13:50 | vsyrjala | yep. gcc-4.9 
strikes again?
freenode.#dri-devel.log-2017-03-16 11:14:54 | imirkin_ | i'm definitely 
using gcc-4.9
freenode.#dri-devel.log-2017-03-16 11:15:16 | vsyrjala | that 
'(VkExtent3D)' looks very much pointless there
freenode.#dri-devel.log-2017-03-16 11:15:56 | imirkin_ | 4.9.4 as it 
happens, which is the "stable" gcc on gentoo
freenode.#dri-devel.log:2017-03-16 11:18:04 | vsyrjala | looks like 
chadv broke it
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 12:44 PM, Jose Fonseca  wrote:
> On 24/03/17 19:10, Kristian Høgsberg wrote:
>>
>> On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
>>>
>>> On 23/03/17 01:38, Rob Clark wrote:


 On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>
>
> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:
>>
>>
>> On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
>> wrote:
>>>
>>>
>>> I guess I'm a little late to the party here, but I haven't had time
>>> to
>>> really let all of this sink in and actually look at meson.  It
>>> doesn't
>>> seem so bad with a quick look and I think I could probably sort it
>>> out
>>> when the time came, but there would still be a bit of a learning
>>> curve.  While that may not be a big deal at the micro level, I have
>>> concerns at the macro level.
>>>
>>> First, I'm concerned it may discourage casual developers and
>>> packagers.  autotools isn't great, but most people are familiar
>>> enough
>>> with it that they can get by.  Most people have enough knowledge of
>>> autotools that they can pretty easily diagnose a configuration based
>>> failure. There are a lot of resources for autotools.  I'm not sure
>>> that would be the case for meson.  Do we as a community feel we have
>>> enough meson experience to get people over the hump?  Anything that
>>> makes it harder for someone to try a new build or do a bisect is a
>>> big
>>> problem in my opinion.
>>
>>
>>
>> One of the things that's prompted this on our side (I've talked this
>> over with
>> other people at Intel before starting), was that clearly we *don't*
>> know
>> autotools well enough to get it right. Emil almost always finds cases
>> were we've
>> done things *almost*, but not quite right.
>>
>> For my part, it took me about 3 or 4 days of reading through the docs
>> and
>> writing the libdrm port to get it right, and a lot of that is just the
>> boilerplate of having ~8 drivers that all need basically the same
>> logic.
>>
>>> Next, my bigger concern is for distro and casual packagers and people
>>> that maintain large build systems with lots of existing custom
>>> configurations.  Changing from autotools would basically require many
>>> of these existing tools and systems to be rewritten and then deal
>>> with
>>> the debugging and fall out from that.  The potential decreased build
>>> time is a nice bonus, but frankly a lot of people/companies have
>>> years
>>> of investment in existing tools.
>>
>>
>>
>> Sure, but we're also not the only ones investigating meson. Gnome is
>> using it
>> already, libepoxy is using it, gstreamer is using it. There are
>> patches
>> for
>> weston (written by Daniel Stone) and libinput (written by Peter
>> Hutterer), there
>> are some other projects in the graphics sphere that people are working
>> on. So
>> even if we as a community decide that meson isn't for us, it's not
>> going
>> away.
>
>
>
> It is worth pointing out that it is currently required by no component
> of an x.org stack.  In the case of libepoxy it was added by a new
> maintainer
> on a new release and even then autoconf remains.
>
> And as far as I can tell nothing in the entire OpenBSD ports tree
> currently requires meson to build including gnome and gstreamer.
>

 but I guess that is conflating two completely different topics..
 addition of meson and removal of autotools.  It is probably better
 that we treat the topics separately.  I don't see any way that the two
 can happen at the same time.

 The autotools build probably needs to remain for at least a couple
 releases, and I certainly wouldn't mind if some of the other desktop
 projects took the leap of dropping autotools first (at least then
 various different "distro" consumers will have already dealt with how
 to build meson packages)

 None of that blocks addition of a meson build system (or what various
 developers use day to day)

 BR,
 -R
>>>
>>>
>>>
>>> I tend to disagree.  While we can't avoid a transitory period, when we
>>> embark on another build system (Meson or something else) I think we
>>> should
>>> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
>>> existing build system, 2) and aim at migration quickly.
>>>
>>> Otherwise we'll just end up with yet another build system, yet another
>>> way
>>> builds can fail, with some developers stuck on old build systems because
>>> it
>>> works, or because the new build system quite doesn't work.
>>>
>>> And this is from (painful) experience.
>>
>>
>> I agree, adding a meson build system should aim to phase out one of
>> the other build systems wi

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

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

--- Comment #5 from John Brooks  ---
Created attachment 130440
  --> https://bugs.freedesktop.org/attachment.cgi?id=130440&action=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

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

--- Comment #6 from John Brooks  ---
Created attachment 130441
  --> https://bugs.freedesktop.org/attachment.cgi?id=130441&action=edit
Xorg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

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

--- Comment #4 from John Brooks  ---
It's possible that I just didn't leave it alone for long enough after it turned
off (or after I turned it off with xset dpms force off). Maybe after a period
of time with no signal, the monitor itself goes into its own sleep state that
affects the DisplayPort connection in a way similar to turning it off
completely. If it's important I can test it further.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

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

--- Comment #3 from John Brooks  ---
(In reply to Alex Deucher from comment #2)
> Do you physically turn the monitor on/off with the button on the monitor or
> just let dpms do it's thing?

I'm turning it on and off with the button. I seem to recall that it would
sometimes stay blank when the desktop environment would blank it (after the
timeout), but I can't seem to reproduce it. Definitely happens with the button
though.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 0/4] RK3399 dw-mipi-dsi patches

[Sean Paul]

On Wed, Mar 22, 2017 at 09:54:47AM +0800, Chris Zhong wrote:
> Hi all
> 
> This series set the phy_cfg_clk to be a required clock for RK3399, and
> add a grf clock control in dw-mipi-dsi driver. And then correct a
> register name.
> 

Applied to drm-misc

Thanks,

Sean


> 
> Changes in v4:
> - remove "additional"
> - print the err after clk_prepare_enable(dsi->grf_clk)
> 
> Changes in v3:
> - add a DW_MIPI_NEEDS_PHY_CFG_CLK for RK3399
> - add a DW_MIPI_NEEDS_GRF_CLK for RK3399
> 
> Changes in v2:
> - check the grf_clk only for RK3399
> 
> Chris Zhong (4):
>   drm/rockchip/dsi: check phy_cfg_clk only for RK3399
>   dt-bindings: add the grf clock for dw-mipi-dsi
>   drm/rockchip/dsi: enable the grf clk before writing grf registers
>   drm/rockchip/dsi: correct the grf_switch_reg name
> 
>  .../display/rockchip/dw_mipi_dsi_rockchip.txt  |  2 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 42 
> +-
>  2 files changed, 35 insertions(+), 9 deletions(-)
> 
> -- 
> 2.6.3
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8] drm/rockchip: Refactor the component match logic.

[Sean Paul]

On Wed, Mar 22, 2017 at 11:21:20AM +0800, Jeffy Chen wrote:
> Currently we are adding all components from the dts, if one of their
> drivers been disabled, we would not be able to bring up others.
> 
> Refactor component match logic, follow exynos drm.

Applied to drm-misc

Thanks,

Sean

> 
> Signed-off-by: Jeffy Chen 
> Reviewed-by: Andrzej Hajda 
> Acked-by: Mark Yao 
> Tested-by: Heiko Stuebner 
> 
> ---
> 
> Changes in v8:
> Address Sean Paul 's comments.
> 
> Changes in v7:
> Add Heiko Stuebner 's Tested-by.
> 
> Changes in v6:
> Add Mark Yao 's Acked-by.
> 
> Changes in v5:
> Fix compile error reported by Heiko Stuebner .
> 
> Changes in v4:
> Use platform_driver helpers to register/unregister drivers.
> Fix null pointer error reported by Heiko Stuebner .
> 
> Changes in v3:
> Address Andrzej Hajda 's comments.
> 
> Changes in v2:
> Address Sean Paul 's comments.
> 
>  drivers/gpu/drm/rockchip/Kconfig|  10 +-
>  drivers/gpu/drm/rockchip/Makefile   |  16 +--
>  drivers/gpu/drm/rockchip/analogix_dp-rockchip.c |   9 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c  |   8 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c  |   8 +-
>  drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  10 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c|  10 +-
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 141 
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   6 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c |   8 +-
>  10 files changed, 118 insertions(+), 108 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> b/drivers/gpu/drm/rockchip/Kconfig
> index 0e4eb84..50c41c0 100644
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> @@ -13,7 +13,7 @@ config DRM_ROCKCHIP
> IP found on the SoC.
>  
>  config ROCKCHIP_ANALOGIX_DP
> - tristate "Rockchip specific extensions for Analogix DP driver"
> + bool "Rockchip specific extensions for Analogix DP driver"
>   depends on DRM_ROCKCHIP
>   select DRM_ANALOGIX_DP
>   help
> @@ -22,7 +22,7 @@ config ROCKCHIP_ANALOGIX_DP
> on RK3288 based SoC, you should selet this option.
>  
>  config ROCKCHIP_CDN_DP
> -tristate "Rockchip cdn DP"
> +bool "Rockchip cdn DP"
>  depends on DRM_ROCKCHIP
>   depends on EXTCON
>   select SND_SOC_HDMI_CODEC if SND_SOC
> @@ -33,7 +33,7 @@ config ROCKCHIP_CDN_DP
> option.
>  
>  config ROCKCHIP_DW_HDMI
> -tristate "Rockchip specific extensions for Synopsys DW HDMI"
> +bool "Rockchip specific extensions for Synopsys DW HDMI"
>  depends on DRM_ROCKCHIP
>  select DRM_DW_HDMI
>  help
> @@ -43,7 +43,7 @@ config ROCKCHIP_DW_HDMI
> option.
>  
>  config ROCKCHIP_DW_MIPI_DSI
> - tristate "Rockchip specific extensions for Synopsys DW MIPI DSI"
> + bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
>   depends on DRM_ROCKCHIP
>   select DRM_MIPI_DSI
>   help
> @@ -53,7 +53,7 @@ config ROCKCHIP_DW_MIPI_DSI
>option.
>  
>  config ROCKCHIP_INNO_HDMI
> - tristate "Rockchip specific extensions for Innosilicon HDMI"
> + bool "Rockchip specific extensions for Innosilicon HDMI"
>   depends on DRM_ROCKCHIP
>   help
> This selects support for Rockchip SoC specific extensions
> diff --git a/drivers/gpu/drm/rockchip/Makefile 
> b/drivers/gpu/drm/rockchip/Makefile
> index c931e2a..fa8dc9d 100644
> --- a/drivers/gpu/drm/rockchip/Makefile
> +++ b/drivers/gpu/drm/rockchip/Makefile
> @@ -3,14 +3,14 @@
>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>  
>  rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
> - rockchip_drm_gem.o rockchip_drm_psr.o rockchip_drm_vop.o
> + rockchip_drm_gem.o rockchip_drm_psr.o \
> + rockchip_drm_vop.o rockchip_vop_reg.o
>  rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o
>  
> -obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp.o
> -cdn-dp-objs := cdn-dp-core.o cdn-dp-reg.o
> -obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> -obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> -obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
> +rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
>  
> -obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_vop_reg.o
> +obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index 8548e82..91ebe5c 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogi

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Kristian Høgsberg]

On Fri, Mar 24, 2017 at 6:42 AM, Jose Fonseca  wrote:
> On 23/03/17 01:38, Rob Clark wrote:
>>
>> On Wed, Mar 22, 2017 at 9:18 PM, Jonathan Gray  wrote:
>>>
>>> On Wed, Mar 22, 2017 at 01:10:14PM -0700, Dylan Baker wrote:

 On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher 
 wrote:
>
> I guess I'm a little late to the party here, but I haven't had time to
> really let all of this sink in and actually look at meson.  It doesn't
> seem so bad with a quick look and I think I could probably sort it out
> when the time came, but there would still be a bit of a learning
> curve.  While that may not be a big deal at the micro level, I have
> concerns at the macro level.
>
> First, I'm concerned it may discourage casual developers and
> packagers.  autotools isn't great, but most people are familiar enough
> with it that they can get by.  Most people have enough knowledge of
> autotools that they can pretty easily diagnose a configuration based
> failure. There are a lot of resources for autotools.  I'm not sure
> that would be the case for meson.  Do we as a community feel we have
> enough meson experience to get people over the hump?  Anything that
> makes it harder for someone to try a new build or do a bisect is a big
> problem in my opinion.


 One of the things that's prompted this on our side (I've talked this
 over with
 other people at Intel before starting), was that clearly we *don't* know
 autotools well enough to get it right. Emil almost always finds cases
 were we've
 done things *almost*, but not quite right.

 For my part, it took me about 3 or 4 days of reading through the docs
 and
 writing the libdrm port to get it right, and a lot of that is just the
 boilerplate of having ~8 drivers that all need basically the same logic.

> Next, my bigger concern is for distro and casual packagers and people
> that maintain large build systems with lots of existing custom
> configurations.  Changing from autotools would basically require many
> of these existing tools and systems to be rewritten and then deal with
> the debugging and fall out from that.  The potential decreased build
> time is a nice bonus, but frankly a lot of people/companies have years
> of investment in existing tools.


 Sure, but we're also not the only ones investigating meson. Gnome is
 using it
 already, libepoxy is using it, gstreamer is using it. There are patches
 for
 weston (written by Daniel Stone) and libinput (written by Peter
 Hutterer), there
 are some other projects in the graphics sphere that people are working
 on. So
 even if we as a community decide that meson isn't for us, it's not going
 away.
>>>
>>>
>>> It is worth pointing out that it is currently required by no component
>>> of an x.org stack.  In the case of libepoxy it was added by a new
>>> maintainer
>>> on a new release and even then autoconf remains.
>>>
>>> And as far as I can tell nothing in the entire OpenBSD ports tree
>>> currently requires meson to build including gnome and gstreamer.
>>>
>>
>> but I guess that is conflating two completely different topics..
>> addition of meson and removal of autotools.  It is probably better
>> that we treat the topics separately.  I don't see any way that the two
>> can happen at the same time.
>>
>> The autotools build probably needs to remain for at least a couple
>> releases, and I certainly wouldn't mind if some of the other desktop
>> projects took the leap of dropping autotools first (at least then
>> various different "distro" consumers will have already dealt with how
>> to build meson packages)
>>
>> None of that blocks addition of a meson build system (or what various
>> developers use day to day)
>>
>> BR,
>> -R
>
>
> I tend to disagree.  While we can't avoid a transitory period, when we
> embark on another build system (Meson or something else) I think we should
> aim at 1) ensure such tool can indeed _completely_ replace at least _one_
> existing build system, 2) and aim at migration quickly.
>
> Otherwise we'll just end up with yet another build system, yet another way
> builds can fail, with some developers stuck on old build systems because it
> works, or because the new build system quite doesn't work.
>
> And this is from (painful) experience.

I agree, adding a meson build system should aim to phase out one of
the other build systems within one or two release cycles. But (and
maybe that was Robs point) that doesn't have be autotools. What if we
phase out scons? It doesn't seem like anybody is really attached to it
and if meson is as good as scons on windows, then if nothing else
happens we end up with the same number of build systems. What's more
likely to happen is that a lot of Linux developers (and CI systems)
will also start using meson, which means that life gets easier for
vmware wrt

Re: [Intel-gfx] [PATCH v10 3/6] drm/edid: detect SCDC support in HF-VSDB

[Daniel Vetter]

On Mon, Mar 13, 2017 at 12:24 PM, Shashank Sharma
 wrote:
> +/**
> + * struct drm_hdmi_info - runtime information about the connected HDMI sink
> + *
> + * Describes if a given display supports advanced HDMI 2.0 features.
> + * This information is available in CEA-861-F extension blocks (like 
> HF-VSDB).
> + */
> +struct drm_hdmi_info {
> +   struct drm_scdc scdc;

This creates a new warning when building docs. Please fix.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Julien Isorce]

Hi Michel,

No this change does not help on the other issue (hard lockup).
I have no tried it in combination with the 0 -> i change.

Thx anyway.
Julien


On 24 March 2017 at 10:03, Michel Dänzer  wrote:

> On 24/03/17 12:31 AM, Zachary Michaels wrote:
> >
> > I should also note that we are experiencing another issue where the
> > kernel locks up in similar circumstances. As Julien noted, we get no
> > output, and the watchdogs don't seem to work. It may be the case that
> > Xorg and our process are calling ttm_bo_mem_force_space concurrently,
> > but I don't think we have enough information yet to say for
> > sure. Reverting this commit does not fix that issue. I have some small
> > amount of evidence indicating that bos flagged for CPU access are
> > getting placed in CPU inaccessible memory. Could that cause this sort of
> > kernel lockup?
>
> Possibly, does this help?
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/
> radeon_ttm.c
> index 37d68cd1f272..40d1bb467a71 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -198,7 +198,8 @@ static void radeon_evict_flags(struct
> ttm_buffer_object *bo,
> case TTM_PL_VRAM:
> if (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready
> == false)
> radeon_ttm_placement_from_domain(rbo,
> RADEON_GEM_DOMAIN_CPU);
> -   else if (rbo->rdev->mc.visible_vram_size <
> rbo->rdev->mc.real_vram_size &&
> +   else if (!(rbo->flags & RADEON_GEM_CPU_ACCESS) &&
> +rbo->rdev->mc.visible_vram_size <
> rbo->rdev->mc.real_vram_size &&
>  bo->mem.start < (rbo->rdev->mc.visible_vram_size
> >> PAGE_SHIFT)) {
> unsigned fpfn = rbo->rdev->mc.visible_vram_size
> >> PAGE_SHIFT;
> int i;
>
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Julien Isorce]

Hi Michel,

I double checked and you are right, the change 0 -> i works.

Cheers
Julien

On 24 March 2017 at 09:59, Michel Dänzer  wrote:

> On 24/03/17 06:50 PM, Julien Isorce wrote:
> > Hi Michel,
> >
> > (Just for other readers my reply has been delayed on the mailing lists
> > and should have been on second position)
>
> It is on https://patchwork.freedesktop.org/patch/145731/ , did you mean
> something else?
>
> The delay was because you weren't subscribed to the amd-gfx mailing list
> yet, so your post went through the moderation queue.
>
>
> > I will have a go with that change and let you know. I do not remember if
> > I tried it for this soft lockup. But for sure it does not solve the hard
> > lockup that Zach also mentioned at the end of his reply.
>
> I'll follow up to his post about that.
>
>
> > But in general, isn't "radeon_lockup_timeout" supposed to detect this
> > situation ?
>
> No, it's for detecting GPU hangs, whereas this is a CPU "hang" (infinite
> loop).
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

[bugzilla-daemon]

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

--- Comment #7 from omegap...@startmail.com ---
Just turned the monitors on in sequence left to right after dinner (new monitor
is last), and the problem occurred:



$ xrandr -q

Screen 0: minimum 320 x 200, current 3840 x 1200, maximum 16384 x 16384
DisplayPort-0 connected 1920x1200+0+0 (normal left inverted right x axis y
axis) 518mm x 324mm
   1920x1200 59.95*+
   1920x1080 60.0050.0059.9430.0025.0024.0029.97   
23.98  
   1920x1080i60.0050.0059.94  
   1600x1200 60.00  
   1280x1024 75.0260.02  
   1152x864  75.00  
   1280x720  60.0050.0059.94  
   1024x768  75.0360.00  
   800x600   75.0060.32  
   720x576   50.00  
   720x576i  50.00  
   720x480   60.0059.94  
   720x480i  60.0059.94  
   640x480   75.0060.0059.94  
   720x400   70.08  
HDMI-0 connected primary 1920x1200+0+0 (normal left inverted right x axis y
axis) 518mm x 324mm
   1920x1200 59.95*+
   1920x1080 60.00  
   1600x1200 60.00  
   1680x1050 59.88  
   1280x1024 60.02  
   1440x900  59.90  
   1280x960  60.00  
   1024x768  60.00  
   800x600   60.32  
   640x480   59.94  
DVI-0 disconnected (normal left inverted right x axis y axis)
DVI-1 connected 1920x1200+1920+0 (normal left inverted right x axis y axis)
518mm x 324mm
   1920x1200 59.95*+
   1920x1080 60.0050.0059.94  
   1600x1200 60.00  
   1680x1050 59.88  
   1280x1024 60.02  
   1440x900  59.90  
   1280x960  60.00  
   1280x800  59.91  
   1280x720  60.0050.0059.94  
   1024x768  60.00  
   800x600   60.3256.25  
   720x576   50.00  
   720x480   60.0059.94  
   640x480   60.0059.94  



So xrandr agrees that DisplayPort-0 and HDMI-0 are on top of each other at
least.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 193981] AMDGPU: R9 380 Fan rotates all the time (loud!)

[bugzilla-daemon]

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

--- Comment #12 from winches (dry...@gmx.fr) ---
I start to bisect.
My problem is, between the linux-git-4.8.r15051.g133d970e0dad and the
linux-git-4.9rc5.r369.g697ed8d03909 my system doesn't found my harddrive with
his UUID and refuse to boot. It's a bug found in the RC release.
Since the fan bug occur after the loading of the drive, i don't know if the fan
bug is present or not...

I continue to bisect but do you know to pass the UUID not found. Something to
do in the compile config maybe.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Daniel Stone]

Hi,

On 24 March 2017 at 17:51, Eric Anholt  wrote:
> Dylan Baker  writes:
>> I also think it's worth talking to Eric (who said he's porting X to meson),
>> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer 
>> (who
>> has patches to port libinput to meson). If they're serious about seeing those
>> land meson is even more appealing, since it would be a single build system 
>> that
>> all of the *nix graphics stack would be moving towards, and would mean that 
>> we
>> wouldn't have an "Autotools for xorg", "meson for weston and libinput", 
>> "cmake for
>> piglit", and " for mesa".
>
> My desire is to push enough of X.org to Meson that I can actually do CI
> of the X Server.  Right now CI is not really tractable on Travis because
> autogen.sh of all the dependencies takes too long.

... and I'm equally serious about Wayland/Weston. I find how slow it
is infuriating for personal development, but for CI, it means that
there's no point trying to test different build options, since the
overhead is so high. Meson would let us actually do that.

I understand there's a huge amount of acquired folk knowledge we're
throwing away with autotools, and in the ~13 years since I started
working on moving X.Org to autotools, I've evaluated and discarded
most of the others because I didn't think they were sufficiently
compelling to do so. In terms of its featureset,
accessibility/tractability to mere mortals, etc, Meson is the only one
I've found where the advantages of moving outweighed the
disadvantages.

I've been pretty buried in atomic work lately, but am going to send
out a revised patchset for Wayland & Weston after I've got the next
iteration out. Similarly I'd expect to see one or two releases
shipping with both build systems, whilst we work with downstreams to
beat any bugs out of the new system before cutting over.

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

Re: [PATCH v4 2/4] dt-bindings: add the grf clock for dw-mipi-dsi

[Rob Herring]

On Wed, Mar 22, 2017 at 09:54:49AM +0800, Chris Zhong wrote:
> For RK3399, the grf clock should be controlled by dw-mipi-dsi driver,
> add the description for this clock.
> 
> Signed-off-by: Chris Zhong 
> Reviewed-by: Sean Paul 
> ---
> 
> Changes in v4:
> - remove "additional"
> 
> Changes in v3: None
> Changes in v2: None
> 
>  .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt   | 2 
> +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

[bugzilla-daemon]

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

--- Comment #2 from Alex Deucher  ---
Do you physically turn the monitor on/off with the button on the monitor or
just let dpms do it's thing?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #29 from Alex Deucher  ---
(In reply to intermedi...@hotmail.com from comment #28)
> I can but i dont know how to ... im a newbee in this geek things.
> but for sure of 411.rc1 was not present . i suggest wait the 4.11.rc4
> because on ml i sow there are many patch for rc 4.11rc3 in case the issue is
> there i will bisect .. but please let me know how to do .

I think it would be good to bisect it now.  Google for "linux kernel git
bisect"

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Eric Anholt]

Dylan Baker  writes:

> [ Unknown signature status ]
> Quoting Jose Fonseca (2017-03-24 06:42:18)
>> 
>> I tend to disagree.  While we can't avoid a transitory period, when we 
>> embark on another build system (Meson or something else) I think we 
>> should aim at 1) ensure such tool can indeed _completely_ replace at 
>> least _one_ existing build system, 2) and aim at migration quickly.
>> 
>> Otherwise we'll just end up with yet another build system, yet another 
>> way builds can fail, with some developers stuck on old build systems 
>> because it works, or because the new build system quite doesn't work.
>> 
>> And this is from (painful) experience.
>
> I tend to agree. Meson is *nice* because it's faster than autotools, but it's
> simplicity and the fact that it works for windows and *nix systems is one of 
> the
> best features. Having fewer build systems is better than more.
>
> We had hoped that we could do one release with both autotools and meson, to 
> give
> some of the fast moving linux distributions (Arch, Fedora, etc) a chance to 
> help
> us iron out bugs, especially for pacakgers. I think it is important though to
> make a commitment for exactly when we're going to either migrate completely to
> meson, or abandon the attempt and revert it.
>
>> So I think we should identify stake holders soon, collect requirements 
>> (OSes platforms, etc), make sure the prospective tool meets them, have 
>> all stakeholders collaborate on a prototype, them embark on mass migration.
>> 
>> That is, if this fails, let it fail early.  If it succeeds, may it 
>> succeed early.  Anything but a slow death / zombie life.
>
> I have a branch that builds intel's Vulkan driver, I'm actively working to get
> intel's i965 dri driver and llvmpipe building and send that out as an RFC to
> mesa-dev. That should give us enough of mesa to evaluate the build system I
> hope (Since it touches all of the major mesa components [classic, gallium,
> neither]).
>
> If other people are interested in collaborating I'd be happy to push the 
> branch
> sooner so that others can look at it.
>
> I also think it's worth talking to Eric (who said he's porting X to meson),
> Daniel Stone (who has patches to port weston to meson), and Peter Hutterer 
> (who
> has patches to port libinput to meson). If they're serious about seeing those
> land meson is even more appealing, since it would be a single build system 
> that
> all of the *nix graphics stack would be moving towards, and would mean that we
> wouldn't have an "Autotools for xorg", "meson for weston and libinput", 
> "cmake for
> piglit", and " for mesa".

My desire is to push enough of X.org to Meson that I can actually do CI
of the X Server.  Right now CI is not really tractable on Travis because
autogen.sh of all the dependencies takes too long.


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

[PATCH v2] drm: Make the decision to keep vblank irq enabled earlier

[Chris Wilson]

We want to provide the vblank irq shadow for pageflip events as well as
vblank queries. Such events are completed within the vblank interrupt
handler, and so the current check for disabling the irq will disable it
from with the same interrupt as the last pageflip event. If we move the
decision on whether to disable the irq (based on there no being no
remaining vblank events, i.e. vblank->refcount == 0) to before we signal
the events, we will only disable the irq on the interrupt after the last
event was signaled. In the normal course of events, this will keep the
vblank irq enabled for the entire flip sequence whereas before it would
flip-flop around every interrupt.

v2: Move the disable_fn() call outside of the vblank_event_lock.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Daniel Vetter 
Cc: Michel Dänzer 
Cc: Laurent Pinchart 
Cc: Dave Airlie ,
Cc: Mario Kleiner 
Reviewed-by: Ville Syrjälä  #v1
Reviewed-by: Mario Kleiner  #v1
---
 drivers/gpu/drm/drm_irq.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 5b77057e91ca..a511597580d8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -1741,6 +1741,7 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
 {
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
+   bool disable_irq;
 
if (WARN_ON_ONCE(!dev->num_crtcs))
return false;
@@ -1768,20 +1769,23 @@ bool drm_handle_vblank(struct drm_device *dev, unsigned 
int pipe)
spin_unlock(&dev->vblank_time_lock);
 
wake_up(&vblank->queue);
-   drm_handle_vblank_events(dev, pipe);
 
/* With instant-off, we defer disabling the interrupt until after
-* we finish processing the following vblank. The disable has to
-* be last (after drm_handle_vblank_events) so that the timestamp
-* is always accurate.
+* we finish processing the following vblank after all events have
+* been signaled. The disable has to be last (after
+* drm_handle_vblank_events) so that the timestamp is always accurate.
 */
-   if (dev->vblank_disable_immediate &&
-   drm_vblank_offdelay > 0 &&
-   !atomic_read(&vblank->refcount))
-   vblank_disable_fn((unsigned long)vblank);
+   disable_irq = (dev->vblank_disable_immediate &&
+  drm_vblank_offdelay > 0 &&
+  !atomic_read(&vblank->refcount));
+
+   drm_handle_vblank_events(dev, pipe);
 
spin_unlock_irqrestore(&dev->event_lock, irqflags);
 
+   if (disable_irq)
+   vblank_disable_fn((unsigned long)vblank);
+
return true;
 }
 EXPORT_SYMBOL(drm_handle_vblank);
-- 
2.11.0

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

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

[Chris Wilson]

On Fri, Mar 24, 2017 at 04:16:28AM +0100, Mario Kleiner wrote:
> Looks good to me. As a further optimization, i think we could move
> the vblank_disable_fn() call outside/below the
> spin_unlock_irqrestore for event_lock, as vblank_disable_fn()
> doesn't need any locks held at call time, so slightly reduce
> event_lock hold time. Don't know if it is worth it.

Hmm, I was cautious since I don't trust myself around the vbl spinlocks.
But yes, the vblank->refcount is controlled by vbl_lock and that is
checked inside the disable callback, so we can move it out from the
vblank_event_lock.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Jose Fonseca (2017-03-24 06:42:18)
> 
> I tend to disagree.  While we can't avoid a transitory period, when we 
> embark on another build system (Meson or something else) I think we 
> should aim at 1) ensure such tool can indeed _completely_ replace at 
> least _one_ existing build system, 2) and aim at migration quickly.
> 
> Otherwise we'll just end up with yet another build system, yet another 
> way builds can fail, with some developers stuck on old build systems 
> because it works, or because the new build system quite doesn't work.
> 
> And this is from (painful) experience.

I tend to agree. Meson is *nice* because it's faster than autotools, but it's
simplicity and the fact that it works for windows and *nix systems is one of the
best features. Having fewer build systems is better than more.

We had hoped that we could do one release with both autotools and meson, to give
some of the fast moving linux distributions (Arch, Fedora, etc) a chance to help
us iron out bugs, especially for pacakgers. I think it is important though to
make a commitment for exactly when we're going to either migrate completely to
meson, or abandon the attempt and revert it.

> So I think we should identify stake holders soon, collect requirements 
> (OSes platforms, etc), make sure the prospective tool meets them, have 
> all stakeholders collaborate on a prototype, them embark on mass migration.
> 
> That is, if this fails, let it fail early.  If it succeeds, may it 
> succeed early.  Anything but a slow death / zombie life.

I have a branch that builds intel's Vulkan driver, I'm actively working to get
intel's i965 dri driver and llvmpipe building and send that out as an RFC to
mesa-dev. That should give us enough of mesa to evaluate the build system I
hope (Since it touches all of the major mesa components [classic, gallium,
neither]).

If other people are interested in collaborating I'd be happy to push the branch
sooner so that others can look at it.

I also think it's worth talking to Eric (who said he's porting X to meson),
Daniel Stone (who has patches to port weston to meson), and Peter Hutterer (who
has patches to port libinput to meson). If they're serious about seeing those
land meson is even more appealing, since it would be a single build system that
all of the *nix graphics stack would be moving towards, and would mean that we
wouldn't have an "Autotools for xorg", "meson for weston and libinput", "cmake 
for
piglit", and " for mesa".

> BTW, how about migrating mesademos to Meson?  It currently has autotools 
> and cmake.  I was hoping that cmake would replace autotools, but I 
> couldn't run fast enough, so I couldn't practice what preached above, 
> hence cmake doing almost but not all what autotools does.
> 
> And is not a crucial project for Linux distros -- few distros package it 
> -- and even if they do, no other package would depend on it.  And is one 
> of those sort of projects that should be easy to port to any build too.

That's definitely doable, but most distros do package it, it's where glxgears,
and more importantly glxinfo live.

I'll have a look at it and see. At the very least we should be able to drop
cmake since I very much doubt anyone but you guys use it.

> Even if we ignore everything else, just replacing autotools + cmake with 
> just one thing would be a net win.
> 
> 
> Jose


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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[randyf]

On Mon, 20 Mar 2017, Matt Turner wrote:




 - dropping the Autotools will lead to OpenBSD and NetBSD having to
write one from scratch, IIRC Solaris/FreeBSD and others are in similar
boat.


Solaris is a closed source operating system whose developers do not
contribute to the project. We do not need to base our decisions on
them.



  For the parts that are relevant to this discussion, this isn't true. 
Yes, the core OS is closed (Oracle Solaris, not the OpenSolaris 
derivative), but the entire graphics stack, including kernel graphics 
drivers are available on java.net and/or github.



  That developers haven't been contributing is primarily due to a 
significant amount of work required on a small set of developers in an 
attempt to just catch up, but they are listening.  What a migration to 
new build system would mean is another item in the list requiring more 
catch-up.



  That said (and I hope I don't get into too hot water), I don't think it 
would be an extremely difficult task for Solaris to migrate; just would 
require resources.



  Cheers!

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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #28 from intermedi...@hotmail.com  ---
I can but i dont know how to ... im a newbee in this geek things.
but for sure of 411.rc1 was not present . i suggest wait the 4.11.rc4 because
on ml i sow there are many patch for rc 4.11rc3 in case the issue is there i
will bisect .. but please let me know how to do .

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Dylan Baker]

Quoting Colin Cross (2017-03-23 17:03:58)
> On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker  wrote:
> >
> > I'm hoping you can clarify a couple of questions I have about blueprint:
> > 1) android is moving to blueprint from android.mk files?
> 
> Yes, in a phased transition.  We support both for now.
> 
> > 2) is there a publicly available project that uses blueprint I could look 
> > at?
> >The documentation I've been able to find is pretty sparse.
> 
> Blueprint is a framework for writing build systems, and Soong is
> AOSP's Blueprint build system.  See
> https://android.googlesource.com/platform/build/soong/+/master/README.md
> for documentation on Soong.

Thanks, that's very useful information.


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

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #27 from Alex Deucher  ---
(In reply to intermedi...@hotmail.com from comment #26)
> Need to notice the issue now is present on 8x slot too on kernel 4.11 rc3

Can you bisect?  That might give us a clue as to the overall root cause
(whether it's a driver or platform issue).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Bas Nieuwenhuizen]

> Another tool I heard good about but have not direct experience is
> https://bazel.build .  Any thoughts about it?

Having looked a bit into it, it also is just a build system (albeit
higher level than ninja or make). It doesn't do configure or install
and working with system dependencies is annoying. While it is awesome
at some stuff, I think for these reasons mesa just is not a good
usecase for it.

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

[Bug 100067] [OpenCL] const int in argument list crashes build

[bugzilla-daemon]

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

--- Comment #8 from Mig  ---
BTW:

I applied the patch from bug 99856 to clc but apparently the bug described
above is not related to that.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100067] [OpenCL] const int in argument list crashes build

[bugzilla-daemon]

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

--- Comment #7 from Mig  ---
Backtrace:

(gdb) run
Starting program:
/home/miguel/Dokumente/OpenCLExamples/myGEMM-master/extra/minimal 
>>> Initializing OpenCL...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffef7f8700 (LWP 3383)]
[New Thread 0x7fffeedf2700 (LWP 3384)]
[New Thread 0x7fffee5f1700 (LWP 3385)]
[New Thread 0x7fffeddf0700 (LWP 3386)]
[New Thread 0x7fffed5ef700 (LWP 3387)]
% Device: AMD TONGA (DRM 3.9.0 / 4.10.4-1-ARCH, LLVM 3.9.1), 2046.3 MiB memory,
max allocation 1432.4 MiB, driver  17.0.1

Thread 1 "minimal" received signal SIGSEGV, Segmentation fault.
0x72b9eb18 in llvm::SIInstrInfo::getInstSizeInBytes(llvm::MachineInstr
const&) const () from /usr/lib/libLLVM-3.9.so
(gdb) bt
#0  0x72b9eb18 in
llvm::SIInstrInfo::getInstSizeInBytes(llvm::MachineInstr const&) const () from
/usr/lib/libLLVM-3.9.so
#1  0x72b33551 in
llvm::AMDGPUAsmPrinter::getSIProgramInfo(llvm::AMDGPUAsmPrinter::SIProgramInfo&,
llvm::MachineFunction const&) const ()
   from /usr/lib/libLLVM-3.9.so
#2  0x72b365ba in
llvm::AMDGPUAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) () from
/usr/lib/libLLVM-3.9.so
#3  0x71e2d1d1 in
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) () from
/usr/lib/libLLVM-3.9.so
#4  0x71cc57c2 in llvm::FPPassManager::runOnFunction(llvm::Function&)
() from /usr/lib/libLLVM-3.9.so
#5  0x71cc5b4b in llvm::FPPassManager::runOnModule(llvm::Module&) ()
   from /usr/lib/libLLVM-3.9.so
#6  0x71cc5e74 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
   from /usr/lib/libLLVM-3.9.so
#7  0x74cc6743 in ?? () from /usr/lib/libMesaOpenCL.so.1
#8  0x74cc6d60 in ?? () from /usr/lib/libMesaOpenCL.so.1
#9  0x74cc311e in ?? () from /usr/lib/libMesaOpenCL.so.1
#10 0x74cb4af9 in ?? () from /usr/lib/libMesaOpenCL.so.1
#11 0x74c929cc in ?? () from /usr/lib/libMesaOpenCL.so.1
#12 0x77bc650b in clBuildProgram () from /usr/lib/libOpenCL.so.1
#13 0x00401190 in main (argc=1, argv=0x7fffe618) at minimal.cpp:113
(gdb)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 2/2] drm/panel: simple: Add support for Winstar WF35LTIACD

[Rob Herring]

On Mon, Mar 20, 2017 at 02:32:22PM +0100, Richard Genoud wrote:
> This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT
> LCD panel, which can be supported by the simple panel driver.
> 
> Signed-off-by: Richard Genoud 
> ---
> 
> Changes since v1:
> Add power-supply property and an example in documentation
> 
>  .../bindings/display/panel/winstar,wf35ltiacd  | 53 
> ++
>  drivers/gpu/drm/panel/panel-simple.c   | 28 
>  2 files changed, 81 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd 
> b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
> new file mode 100644
> index ..9ff59b868b28
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/winstar,wf35ltiacd
> @@ -0,0 +1,53 @@
> +Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "winstar,wf35ltiacd"
> +- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> +
> +Example:
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&hlcdc_pwm 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 31 63 95 127 159 191 223 255>;
> + default-brightness-level = <191>;
> + power-supply = <&bl_reg>;
> + status = "okay";

Drop status from examples.

> + };
> +
> + bl_reg: backlight_regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "backlight-power-supply";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + status = "okay";
> + };
> +
> + panel: panel {
> + compatible = "winstar,wf35ltiacd", "simple-panel";
> + backlight = <&backlight>;
> + power-supply = <&panel_reg>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint@0 {
> + reg = <0>;

You don't need reg and unit-addresses for these.

With that,

Acked-by: Rob Herring 

> + remote-endpoint = <&hlcdc_panel_output>;
> + };
> + };
> + };
> +
> + panel_reg: panel_regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "panel-power-supply";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + status = "okay";
> + };
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/vmwgfx: Check check that number of mip levels is above zero in vmw_surface_define_ioctl()

[Vladis Dronov]

In vmw_surface_define_ioctl(), a num_sizes parameter is assigned a
user-controlled value which is not checked for zero. It is used in
a call to kmalloc() which returns ZERO_SIZE_PTR. Later ZERO_SIZE_PTR
is dereferenced which leads to a GPF and possibly to a kernel panic.
Add the check for zero to avoid this.

Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1435719
Signed-off-by: Vladis Dronov 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index b445ce9..42840cc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -716,8 +716,8 @@ int vmw_surface_define_ioctl(struct drm_device *dev, void 
*data,
for (i = 0; i < DRM_VMW_MAX_SURFACE_FACES; ++i)
num_sizes += req->mip_levels[i];
 
-   if (num_sizes > DRM_VMW_MAX_SURFACE_FACES *
-   DRM_VMW_MAX_MIP_LEVELS)
+   if (num_sizes <= 0 ||
+   num_sizes > DRM_VMW_MAX_SURFACE_FACES * DRM_VMW_MAX_MIP_LEVELS)
return -EINVAL;
 
size = vmw_user_surface_size + 128 +
-- 
2.9.3

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

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

[Tomi Valkeinen]

On 24/03/17 17:12, Tony Lindgren wrote:
> * Tomi Valkeinen  [170324 08:01]:
>> On 24/03/17 16:29, Tony Lindgren wrote:
>>> * Sebastian Reichel  [170304 16:45]:
 Add basic panel support for the Nokia N950. It must be tweaked a
 little bit later, since the panel was built into the device
 upside-down. Also the first 5 and the last 5 pixels are covered
 by plastic.
>>>
>>> This one seems safe to apply separately to shrink the pending
>>> patches a bit. Please confirm if that's the case and I'll apply
>>> this one.
>>
>> No, I think there are too many open questions to apply this one. And we
>> need to move to common DRM drivers at some point (hopefully soon) so the
>> bindings must be aligned with those if and when possible.
> 
> Hmm so what are the open questions and do you have in mind for
> the panel bindings?

Well, until we have driver that supports the panel without problems, we
can't be sure if we have everything in the binding. At least the TE was
missing or broken.

Normal videotimings don't really make sense for DSI command mode panels,
so I'm not overly enthusiastic in having them in the bindings. Possibly
that's the easy way to go, but I'm not sure yet.

There are the "TODO" parts in the bindings, that's a clear sign of open
questions.

I haven't looked at how the other DRM drivers handle DSI command mode
panels. That's something to study, before adding anything new to the
omap specific bindings.

> Naturally we still need to support the current bindings too.

Do the current bindings work? I guess they did work on omapfb... Do
these new bindings work with omapfb?

Generally speaking, I've been bitten badly enough with DT bindings that
weren't up to the task after all, and then changing the later was a
major pain (or working around it). So I'd rather not merge anything to
DT if there are any unclarities, and a driver not working which uses
those bindings is an unclarity. Especially if the only reason to merge
is to get a single patch out from a bigger patch series, without
actually enabling anything.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 10/10] ARM: dts: n950: add display support

[Tomi Valkeinen]

On 24/03/17 16:29, Tony Lindgren wrote:
> * Sebastian Reichel  [170304 16:45]:
>> Add basic panel support for the Nokia N950. It must be tweaked a
>> little bit later, since the panel was built into the device
>> upside-down. Also the first 5 and the last 5 pixels are covered
>> by plastic.
> 
> This one seems safe to apply separately to shrink the pending
> patches a bit. Please confirm if that's the case and I'll apply
> this one.

No, I think there are too many open questions to apply this one. And we
need to move to common DRM drivers at some point (hopefully soon) so the
bindings must be aligned with those if and when possible.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 6/6] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix

[Jyri Sarha]

Implement CTM color management property for OMAP CRTC using DSS
overlay manager's Color Phase Rotation matrix. The CPR matrix does not
exactly match the CTM property documentation. On DSS the CPR matrix is
applied before gamma table look up. However, it seems stupid to add a
custom property just for that.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 026f73b..ed3b631 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -312,6 +312,25 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
 }
 
+static s16 omap_crtc_s32_32_to_s2_8(s64 coef)
+{
+   return (s16)(coef >> 24);
+}
+
+static void omap_crtc_cpr_coefs_from_ctm(const struct drm_color_ctm *ctm,
+struct omap_dss_cpr_coefs *cpr)
+{
+   cpr->rr = omap_crtc_s32_32_to_s2_8(ctm->matrix[0]);
+   cpr->rg = omap_crtc_s32_32_to_s2_8(ctm->matrix[1]);
+   cpr->rb = omap_crtc_s32_32_to_s2_8(ctm->matrix[2]);
+   cpr->gr = omap_crtc_s32_32_to_s2_8(ctm->matrix[3]);
+   cpr->gg = omap_crtc_s32_32_to_s2_8(ctm->matrix[4]);
+   cpr->gb = omap_crtc_s32_32_to_s2_8(ctm->matrix[5]);
+   cpr->br = omap_crtc_s32_32_to_s2_8(ctm->matrix[6]);
+   cpr->bg = omap_crtc_s32_32_to_s2_8(ctm->matrix[7]);
+   cpr->bb = omap_crtc_s32_32_to_s2_8(ctm->matrix[8]);
+}
+
 static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
 {
struct omap_drm_private *priv = crtc->dev->dev_private;
@@ -325,6 +344,15 @@ static void omap_crtc_write_crtc_properties(struct 
drm_crtc *crtc)
info.partial_alpha_enabled = false;
info.cpr_enable = false;
 
+   if (crtc->state->ctm && !WARN_ON(crtc->state->ctm->length !=
+sizeof(struct drm_color_ctm))) {
+   struct drm_color_ctm *ctm =
+   (struct drm_color_ctm *) crtc->state->ctm->data;
+
+   info.cpr_enable = true;
+   omap_crtc_cpr_coefs_from_ctm(ctm, &info.cpr_coefs);
+   }
+
priv->dispc_ops->mgr_setup(omap_crtc->channel, &info);
 }
 
@@ -624,7 +652,7 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
if (priv->dispc_ops->mgr_gamma_size(channel)) {
uint gamma_lut_size = 256;
 
-   drm_crtc_enable_color_mgmt(crtc, 0, false, gamma_lut_size);
+   drm_crtc_enable_color_mgmt(crtc, 0, true, gamma_lut_size);
drm_mode_crtc_set_gamma_size(crtc, gamma_lut_size);
}
 
-- 
1.9.1

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

[PATCH v4 4/6] drm/omap: Remove the obsolete #define omap_plane _omap_plane hack

[Jyri Sarha]

Remove the obsolete "#define omap_plane _omap_plane" hack and other
related hacks to get around the enum omap_plane colliding with struct
omap_plane.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/omap_plane.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 27c1902..64d53c4 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -24,12 +24,6 @@
 #include "omap_dmm_tiler.h"
 #include "omap_drv.h"
 
-/* some hackery because omapdss has an 'enum omap_plane' (which would be
- * better named omap_plane_id).. and compiler seems unhappy about having
- * both a 'struct omap_plane' and 'enum omap_plane'
- */
-#define omap_plane _omap_plane
-
 /*
  * plane funcs
  */
@@ -38,7 +32,7 @@
 
 struct omap_plane {
struct drm_plane base;
-   int id;  /* TODO rename omap_plane -> omap_plane_id in omapdss so I can 
use the enum */
+   enum omap_plane_id id;
const char *name;
 
uint32_t nformats;
-- 
1.9.1

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

[PATCH v4 3/6] drm/omap: Fix one ugly indentation style break left by coccinelle

[Jyri Sarha]

Fix one ugly indentation style break left by the previous coccilnelle
patch.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 8100fec..5ac0145 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -1802,8 +1802,7 @@ static void dispc_ovl_set_scaling(enum omap_plane_id 
plane,
rotation);
 }
 
-static void dispc_ovl_set_rotation_attrs(enum omap_plane_id plane,
-u8 rotation,
+static void dispc_ovl_set_rotation_attrs(enum omap_plane_id plane, u8 rotation,
enum omap_dss_rotation_type rotation_type,
bool mirroring, enum omap_color_mode color_mode)
 {
@@ -2834,7 +2833,7 @@ static int dispc_ovl_setup_common(enum omap_plane_id 
plane,
 }
 
 static int dispc_ovl_setup(enum omap_plane_id plane,
-  const struct omap_overlay_info *oi,
+   const struct omap_overlay_info *oi,
const struct videomode *vm, bool mem_to_mem)
 {
int r;
-- 
1.9.1

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

[PATCH v4 5/6] drm/omap: Major omap_modeset_init() cleanup

[Jyri Sarha]

Cleanup overly complex omap_modeset_init(). The function is trying to
support many unusual configuration, that have never been tested and
are not supported by other parts of the dirver.

After cleanup the init function creates exactly one connector,
encoder, crtc, and primary plane per each connected dss-device. Each
connector->encoder->crtc chain is expected to be separate and each
crtc is connect to a single dss-channel. If the configuration does not
match the expectations or exceeds the available resources, the
configuration is rejected.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c  |  20 +++-
 drivers/gpu/drm/omapdrm/omap_drv.c   | 177 ++-
 drivers/gpu/drm/omapdrm/omap_drv.h   |   4 +-
 drivers/gpu/drm/omapdrm/omap_plane.c |  24 -
 4 files changed, 86 insertions(+), 139 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 606ef80..026f73b 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -561,6 +561,8 @@ static int omap_crtc_atomic_get_property(struct drm_crtc 
*crtc,
 
 void omap_crtc_pre_init(void)
 {
+   memset(omap_crtcs, 0, sizeof(omap_crtcs));
+
dss_install_mgr_ops(&mgr_ops);
 }
 
@@ -571,18 +573,28 @@ void omap_crtc_pre_uninit(void)
 
 /* initialize crtc */
 struct drm_crtc *omap_crtc_init(struct drm_device *dev,
-   struct drm_plane *plane, enum omap_channel channel, int id)
+   struct drm_plane *plane, struct omap_dss_device *dssdev)
 {
struct omap_drm_private *priv = dev->dev_private;
struct drm_crtc *crtc = NULL;
struct omap_crtc *omap_crtc;
+   enum omap_channel channel;
+   struct omap_dss_device *out;
int ret;
 
+   out = omapdss_find_output_from_display(dssdev);
+   channel = out->dispc_channel;
+   omap_dss_put_device(out);
+
DBG("%s", channel_names[channel]);
 
+   /* Multiple displays on same channel is not allowed */
+   if (WARN_ON(omap_crtcs[channel] != NULL))
+   return ERR_PTR(-EINVAL);
+
omap_crtc = kzalloc(sizeof(*omap_crtc), GFP_KERNEL);
if (!omap_crtc)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
crtc = &omap_crtc->base;
 
@@ -594,8 +606,10 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
ret = drm_crtc_init_with_planes(dev, crtc, plane, NULL,
&omap_crtc_funcs, NULL);
if (ret < 0) {
+   dev_err(dev->dev, "%s(): could not init crtc for: %s\n",
+   __func__, dssdev->name);
kfree(omap_crtc);
-   return NULL;
+   return ERR_PTR(ret);
}
 
drm_crtc_helper_add(crtc, &omap_crtc_helper_funcs);
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index b040f5f..2c038cf 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -219,20 +219,6 @@ static int get_connector_type(struct omap_dss_device 
*dssdev)
}
 }
 
-static bool channel_used(struct drm_device *dev, enum omap_channel channel)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   int i;
-
-   for (i = 0; i < priv->num_crtcs; i++) {
-   struct drm_crtc *crtc = priv->crtcs[i];
-
-   if (omap_crtc_channel(crtc) == channel)
-   return true;
-   }
-
-   return false;
-}
 static void omap_disconnect_dssdevs(void)
 {
struct omap_dss_device *dssdev = NULL;
@@ -272,31 +258,6 @@ static int omap_connect_dssdevs(void)
return r;
 }
 
-static int omap_modeset_create_crtc(struct drm_device *dev, int id,
-   enum omap_channel channel,
-   u32 possible_crtcs)
-{
-   struct omap_drm_private *priv = dev->dev_private;
-   struct drm_plane *plane;
-   struct drm_crtc *crtc;
-
-   plane = omap_plane_init(dev, id, DRM_PLANE_TYPE_PRIMARY,
-   possible_crtcs);
-   if (IS_ERR(plane))
-   return PTR_ERR(plane);
-
-   crtc = omap_crtc_init(dev, plane, channel, id);
-
-   BUG_ON(priv->num_crtcs >= ARRAY_SIZE(priv->crtcs));
-   priv->crtcs[id] = crtc;
-   priv->num_crtcs++;
-
-   priv->planes[id] = plane;
-   priv->num_planes++;
-
-   return 0;
-}
-
 static int omap_modeset_init_properties(struct drm_device *dev)
 {
struct omap_drm_private *priv = dev->dev_private;
@@ -314,10 +275,9 @@ static int omap_modeset_init(struct drm_device *dev)
struct omap_dss_device *dssdev = NULL;
int num_ovls = priv->dispc_ops->get_num_ovls();
int num_mgrs = priv->dispc_ops->get_num_mgrs();
-   int num_crtcs = 0;
-   int i, id = 0;
+   int num_crtcs, crtc_idx, plane_idx;
int ret;
-   u32 possible_crtcs;
+   u32 plane_crtc_mask;
 
drm_mode_config

[PATCH v4 2/6] drm/omap: Rename enum omap_plane to enum omap_plane_id

[Jyri Sarha]

The enum omap_plane conflicted with the same struct name for omapdrm
plane private data. This rename should solve the conflict.

The rename was implement with this very simple coccinelle patch:

@@
@@
enum
-omap_plane
+omap_plane_id

The patch was applied like this:
spatch --sp-file  --all-includes --in-place --dir 
drivers/gpu/drm/omapdrm

The above patch did not rename the actual enum definition. That was
added manually on top of the spatch changes.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c| 124 -
 drivers/gpu/drm/omapdrm/dss/dispc.h|  62 +++
 drivers/gpu/drm/omapdrm/dss/dss.h  |   5 +-
 drivers/gpu/drm/omapdrm/dss/dss_features.c |   6 +-
 drivers/gpu/drm/omapdrm/dss/dss_features.h |   6 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  17 ++--
 6 files changed, 117 insertions(+), 103 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 2e6a71d..8100fec 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -303,8 +303,8 @@ struct color_conv_coef {
 static unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
 static unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
 
-static unsigned long dispc_plane_pclk_rate(enum omap_plane plane);
-static unsigned long dispc_plane_lclk_rate(enum omap_plane plane);
+static unsigned long dispc_plane_pclk_rate(enum omap_plane_id plane);
+static unsigned long dispc_plane_lclk_rate(enum omap_plane_id plane);
 
 static void dispc_clear_irqstatus(u32 mask);
 static bool dispc_mgr_is_enabled(enum omap_channel channel);
@@ -653,7 +653,7 @@ bool dispc_wb_go_busy(void)
 
 void dispc_wb_go(void)
 {
-   enum omap_plane plane = OMAP_DSS_WB;
+   enum omap_plane_id plane = OMAP_DSS_WB;
bool enable, go;
 
enable = REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0) == 1;
@@ -670,29 +670,33 @@ void dispc_wb_go(void)
REG_FLD_MOD(DISPC_CONTROL2, 1, 6, 6);
 }
 
-static void dispc_ovl_write_firh_reg(enum omap_plane plane, int reg, u32 value)
+static void dispc_ovl_write_firh_reg(enum omap_plane_id plane, int reg,
+u32 value)
 {
dispc_write_reg(DISPC_OVL_FIR_COEF_H(plane, reg), value);
 }
 
-static void dispc_ovl_write_firhv_reg(enum omap_plane plane, int reg, u32 
value)
+static void dispc_ovl_write_firhv_reg(enum omap_plane_id plane, int reg,
+ u32 value)
 {
dispc_write_reg(DISPC_OVL_FIR_COEF_HV(plane, reg), value);
 }
 
-static void dispc_ovl_write_firv_reg(enum omap_plane plane, int reg, u32 value)
+static void dispc_ovl_write_firv_reg(enum omap_plane_id plane, int reg,
+u32 value)
 {
dispc_write_reg(DISPC_OVL_FIR_COEF_V(plane, reg), value);
 }
 
-static void dispc_ovl_write_firh2_reg(enum omap_plane plane, int reg, u32 
value)
+static void dispc_ovl_write_firh2_reg(enum omap_plane_id plane, int reg,
+ u32 value)
 {
BUG_ON(plane == OMAP_DSS_GFX);
 
dispc_write_reg(DISPC_OVL_FIR_COEF_H2(plane, reg), value);
 }
 
-static void dispc_ovl_write_firhv2_reg(enum omap_plane plane, int reg,
+static void dispc_ovl_write_firhv2_reg(enum omap_plane_id plane, int reg,
u32 value)
 {
BUG_ON(plane == OMAP_DSS_GFX);
@@ -700,14 +704,15 @@ static void dispc_ovl_write_firhv2_reg(enum omap_plane 
plane, int reg,
dispc_write_reg(DISPC_OVL_FIR_COEF_HV2(plane, reg), value);
 }
 
-static void dispc_ovl_write_firv2_reg(enum omap_plane plane, int reg, u32 
value)
+static void dispc_ovl_write_firv2_reg(enum omap_plane_id plane, int reg,
+ u32 value)
 {
BUG_ON(plane == OMAP_DSS_GFX);
 
dispc_write_reg(DISPC_OVL_FIR_COEF_V2(plane, reg), value);
 }
 
-static void dispc_ovl_set_scale_coef(enum omap_plane plane, int fir_hinc,
+static void dispc_ovl_set_scale_coef(enum omap_plane_id plane, int fir_hinc,
int fir_vinc, int five_taps,
enum omap_color_component color_comp)
 {
@@ -753,7 +758,7 @@ static void dispc_ovl_set_scale_coef(enum omap_plane plane, 
int fir_hinc,
 }
 
 
-static void dispc_ovl_write_color_conv_coef(enum omap_plane plane,
+static void dispc_ovl_write_color_conv_coef(enum omap_plane_id plane,
const struct color_conv_coef *ct)
 {
 #define CVAL(x, y) (FLD_VAL(x, 26, 16) | FLD_VAL(y, 10, 0))
@@ -789,27 +794,27 @@ static void dispc_setup_color_conv_coef(void)
dispc_ovl_write_color_conv_coef(OMAP_DSS_WB, &ctbl_bt601_5_wb);
 }
 
-static void dispc_ovl_set_ba0(enum omap_plane plane, u32 paddr)
+static void dispc_ovl_set_ba0(enum omap_plane_id plane, u32 paddr)
 {
dispc_write_reg(DISPC_OVL_BA0(plane), paddr);
 }
 
-static void dispc_ovl_set_ba1(enum omap_plane plane, u32 padd

[PATCH v4 1/6] drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option

[Jyri Sarha]

Allocate one CRTC for each connected output and get rid of
DRM_OMAP_NUM_CRTCS config option. We still can not create more CRTCs
than we have DSS display managers. We also reserve one overlay per
CRTC for primary plane so we can not have more CRTCs than we have
overlays either.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/omapdrm/Kconfig|  9 --
 drivers/gpu/drm/omapdrm/omap_drv.c | 59 +++---
 2 files changed, 16 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
index 556f81f..b3d08c5 100644
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -10,15 +10,6 @@ config DRM_OMAP
 
 if DRM_OMAP
 
-config DRM_OMAP_NUM_CRTCS
-   int "Number of CRTCs"
-   range 1 10
-   default 1  if ARCH_OMAP2 || ARCH_OMAP3
-   default 2  if ARCH_OMAP4
-   help
- Select the number of video overlays which can be used as framebuffers.
- The remaining overlays are reserved for video.
-
 source "drivers/gpu/drm/omapdrm/dss/Kconfig"
 source "drivers/gpu/drm/omapdrm/displays/Kconfig"
 
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index ad8d16c..b040f5f 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -34,11 +34,6 @@
 #define DRIVER_MINOR   0
 #define DRIVER_PATCHLEVEL  0
 
-static int num_crtc = CONFIG_DRM_OMAP_NUM_CRTCS;
-
-MODULE_PARM_DESC(num_crtc, "Number of overlays to use as CRTCs");
-module_param(num_crtc, int, 0600);
-
 /*
  * mode config funcs
  */
@@ -319,7 +314,7 @@ static int omap_modeset_init(struct drm_device *dev)
struct omap_dss_device *dssdev = NULL;
int num_ovls = priv->dispc_ops->get_num_ovls();
int num_mgrs = priv->dispc_ops->get_num_mgrs();
-   int num_crtcs;
+   int num_crtcs = 0;
int i, id = 0;
int ret;
u32 possible_crtcs;
@@ -331,12 +326,15 @@ static int omap_modeset_init(struct drm_device *dev)
return ret;
 
/*
-* We usually don't want to create a CRTC for each manager, at least
-* not until we have a way to expose private planes to userspace.
-* Otherwise there would not be enough video pipes left for drm planes.
-* We use the num_crtc argument to limit the number of crtcs we create.
+* Let's create one CRTC for each connected DSS device if we
+* have display managers and overlays (for primary planes) for
+* them.
 */
-   num_crtcs = min3(num_crtc, num_mgrs, num_ovls);
+   for_each_dss_dev(dssdev)
+   if (omapdss_device_is_connected(dssdev))
+   num_crtcs++;
+
+   num_crtcs = min3(num_crtcs, num_mgrs, num_ovls);
possible_crtcs = (1 << num_crtcs) - 1;
 
dssdev = NULL;
@@ -376,11 +374,9 @@ static int omap_modeset_init(struct drm_device *dev)
drm_mode_connector_attach_encoder(connector, encoder);
 
/*
-* if we have reached the limit of the crtcs we are allowed to
-* create, let's not try to look for a crtc for this
-* panel/encoder and onwards, we will, of course, populate the
-* the possible_crtcs field for all the encoders with the final
-* set of crtcs we create
+* if we have reached the limit of the crtcs we can
+* create, let's not try to create a crtc for this
+* panel/encoder and onwards.
 */
if (id == num_crtcs)
continue;
@@ -415,33 +411,6 @@ static int omap_modeset_init(struct drm_device *dev)
}
 
/*
-* we have allocated crtcs according to the need of the panels/encoders,
-* adding more crtcs here if needed
-*/
-   for (; id < num_crtcs; id++) {
-
-   /* find a free manager for this crtc */
-   for (i = 0; i < num_mgrs; i++) {
-   if (!channel_used(dev, i))
-   break;
-   }
-
-   if (i == num_mgrs) {
-   /* this shouldn't really happen */
-   dev_err(dev->dev, "no managers left for crtc\n");
-   return -ENOMEM;
-   }
-
-   ret = omap_modeset_create_crtc(dev, id, i,
-   possible_crtcs);
-   if (ret < 0) {
-   dev_err(dev->dev,
-   "could not create CRTC (channel %u)\n", i);
-   return ret;
-   }
-   }
-
-   /*
 * Create normal planes for the remaining overlays:
 */
for (; id < num_ovls; id++) {
@@ -456,6 +425,10 @@ static int omap_modeset_init(struct drm_device *dev)
priv->planes[priv->num_planes++] = plane;
}
 
+   /*
+* populate the the po

[PATCH v4 0/6] drm/omap: Remove CONFIG_DRM_OMAP_NUM_CRTCS, cleanup & CTM

[Jyri Sarha]

The first patch removes CONFIG_DRM_OMAP_NUM_CRTCS config option. The
patches number 2-4 gets rid of annoying name collision between dss
backend and omapdrm. The second last patch cleans up the unnecessary
complexity from omap_modeset_init(). And finally the last implements
CRTC's CTM matrix propety by using DSS DISPC's Color Phase Rotation
unit.

Changes since v3:
- Rebased on top Tomi Valkeinen's latest omap-drm series:
   https://lists.freedesktop.org/archives/dri-devel/2017-March/136770.html
- Adds:
  - drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix

Changes since v2:
- drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option
  - No change
- Added:
  - drm/omap: Rename enum omap_plane to enum omap_plane_id
  - drm/omap: Fix ugliest indentation style breaks from previous patch
  - drm/omap: Remove the obsolete #define omap_plane _omap_plane hack
- drm/omap: Major omap_modeset_init() cleanup
  - use memset() to reset omap_crtcs[] in omap_crtc_pre_init()
  - make the mapping between omapdrm plane index and dss plane id explicit

Changes since first version:
- drm/omapdrm: Get rid of DRM_OMAP_NUM_CRTCS config option
  - drm/omapdrm: -> drm/omap:
- Drop:
  - drm/omapdrm: Change possible_crtcs to possible_crtcs_for_planes
  - drm/omapdrm: Separate ids for planes and CRTCs in omap_modeset_init()
- Add:
  - drm/omap: Major omap_modeset_init() cleanup

Jyri Sarha (6):
  drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option
  drm/omap: Rename enum omap_plane to enum omap_plane_id
  drm/omap: Fix one ugly indentation style break left by coccinelle
  drm/omap: Remove the obsolete #define omap_plane _omap_plane hack
  drm/omap: Major omap_modeset_init() cleanup
  drm/omap: Implement CTM property for CRTC using OVL managers CPR
matrix

 drivers/gpu/drm/omapdrm/Kconfig|   9 --
 drivers/gpu/drm/omapdrm/dss/dispc.c| 123 +
 drivers/gpu/drm/omapdrm/dss/dispc.h|  62 -
 drivers/gpu/drm/omapdrm/dss/dss.h  |   5 +-
 drivers/gpu/drm/omapdrm/dss/dss_features.c |   6 +-
 drivers/gpu/drm/omapdrm/dss/dss_features.h |   6 +-
 drivers/gpu/drm/omapdrm/dss/omapdss.h  |  17 +--
 drivers/gpu/drm/omapdrm/omap_crtc.c|  50 ++-
 drivers/gpu/drm/omapdrm/omap_drv.c | 212 +++--
 drivers/gpu/drm/omapdrm/omap_drv.h |   4 +-
 drivers/gpu/drm/omapdrm/omap_plane.c   |  32 +++--
 11 files changed, 236 insertions(+), 290 deletions(-)

-- 
1.9.1

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

[PATCH] drm: mali-dp: Enable power management for the device.

[Liviu Dudau]

Enable runtime and system Power Management. Clocks are now managed
from malidp_crtc_{enable,disable} functions. Suspend-to-RAM tested
as working on Juno.

Signed-off-by: Liviu Dudau 
Reviewed-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_crtc.c |  14 -
 drivers/gpu/drm/arm/malidp_drv.c  | 128 +++---
 drivers/gpu/drm/arm/malidp_drv.h  |   1 +
 drivers/gpu/drm/arm/malidp_hw.h   |   5 ++
 4 files changed, 125 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index f9d665550d3e..fab776c37602 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "malidp_drv.h"
@@ -58,9 +59,14 @@ static void malidp_crtc_enable(struct drm_crtc *crtc)
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
struct videomode vm;
+   int err = pm_runtime_get_sync(crtc->dev->dev);
 
-   drm_display_mode_to_videomode(&crtc->state->adjusted_mode, &vm);
+   if (err < 0) {
+   DRM_DEBUG_DRIVER("Failed to enable runtime power management: 
%d\n", err);
+   return;
+   }
 
+   drm_display_mode_to_videomode(&crtc->state->adjusted_mode, &vm);
clk_prepare_enable(hwdev->pxlclk);
 
/* We rely on firmware to set mclk to a sensible level. */
@@ -75,10 +81,16 @@ static void malidp_crtc_disable(struct drm_crtc *crtc)
 {
struct malidp_drm *malidp = crtc_to_malidp_device(crtc);
struct malidp_hw_device *hwdev = malidp->dev;
+   int err;
 
drm_crtc_vblank_off(crtc);
hwdev->enter_config_mode(hwdev);
clk_disable_unprepare(hwdev->pxlclk);
+
+   err = pm_runtime_put(crtc->dev->dev);
+   if (err < 0) {
+   DRM_DEBUG_DRIVER("Failed to disable runtime power management: 
%d\n", err);
+   }
 }
 
 static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index f5cecdc3f14a..55fb086cd4b4 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -13,9 +13,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -91,6 +93,8 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state 
*state)
 {
struct drm_device *drm = state->dev;
 
+   pm_runtime_get_sync(drm->dev);
+
drm_atomic_helper_commit_modeset_disables(drm, state);
 
drm_atomic_helper_commit_planes(drm, state, 0);
@@ -101,6 +105,8 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
 
drm_atomic_helper_wait_for_vblanks(drm, state);
 
+   pm_runtime_put(drm->dev);
+
drm_atomic_helper_cleanup_planes(drm, state);
 }
 
@@ -283,6 +289,37 @@ static bool malidp_has_sufficient_address_space(const 
struct resource *res,
 
 #define MAX_OUTPUT_CHANNELS3
 
+static int malidp_runtime_pm_suspend(struct device *dev)
+{
+   struct drm_device *drm = dev_get_drvdata(dev);
+   struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
+
+   /* we can only suspend if the hardware is in config mode */
+   WARN_ON(!hwdev->in_config_mode(hwdev));
+
+   hwdev->pm_suspended = true;
+   clk_disable_unprepare(hwdev->mclk);
+   clk_disable_unprepare(hwdev->aclk);
+   clk_disable_unprepare(hwdev->pclk);
+
+   return 0;
+}
+
+static int malidp_runtime_pm_resume(struct device *dev)
+{
+   struct drm_device *drm = dev_get_drvdata(dev);
+   struct malidp_drm *malidp = drm->dev_private;
+   struct malidp_hw_device *hwdev = malidp->dev;
+
+   clk_prepare_enable(hwdev->pclk);
+   clk_prepare_enable(hwdev->aclk);
+   clk_prepare_enable(hwdev->mclk);
+   hwdev->pm_suspended = false;
+
+   return 0;
+}
+
 static int malidp_bind(struct device *dev)
 {
struct resource *res;
@@ -312,7 +349,6 @@ static int malidp_bind(struct device *dev)
memcpy(hwdev, of_device_get_match_data(dev), sizeof(*hwdev));
malidp->dev = hwdev;
 
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hwdev->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(hwdev->regs))
@@ -345,14 +381,17 @@ static int malidp_bind(struct device *dev)
goto alloc_fail;
}
 
-   /* Enable APB clock in order to get access to the registers */
-   clk_prepare_enable(hwdev->pclk);
-   /*
-* Enable AXI clock and main clock so that prefetch can start once
-* the registers are set
-*/
-   clk_prepare_enable(hwdev->aclk);
-   clk_prepare_enable(hwdev->mclk);
+   drm->dev_private = malidp;
+   dev_set_drvdata(dev, drm);
+
+   /* Enable power management */
+   pm_runtime_enable(dev);
+
+   /* Resume 

[PATCH] drm: mali-dp: Update the state of all planes before re-enabling active CRTCs.

[Liviu Dudau]

Mali DP needs to have all the planes that are becoming inactive in the
new state disabled before re-enabling the active CRTC, otherwise we
start streaming out data from old pointers in memory.

Signed-off-by: Liviu Dudau 
Reviewed-by: Brian Starkey 
---
 drivers/gpu/drm/arm/malidp_drv.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ea2546f766c2..f5cecdc3f14a 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -66,10 +66,12 @@ static void malidp_atomic_commit_hw_done(struct 
drm_atomic_state *state)
struct drm_pending_vblank_event *event;
struct drm_device *drm = state->dev;
struct malidp_drm *malidp = drm->dev_private;
-   int ret = malidp_set_and_wait_config_valid(drm);
 
-   if (ret)
-   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   if (malidp->crtc.enabled) {
+   /* only set config_valid if the CRTC is enabled */
+   if (malidp_set_and_wait_config_valid(drm))
+   DRM_DEBUG_DRIVER("timed out waiting for updated 
configuration\n");
+   }
 
event = malidp->crtc.state->event;
if (event) {
@@ -90,9 +92,11 @@ static void malidp_atomic_commit_tail(struct 
drm_atomic_state *state)
struct drm_device *drm = state->dev;
 
drm_atomic_helper_commit_modeset_disables(drm, state);
-   drm_atomic_helper_commit_modeset_enables(drm, state);
+
drm_atomic_helper_commit_planes(drm, state, 0);
 
+   drm_atomic_helper_commit_modeset_enables(drm, state);
+
malidp_atomic_commit_hw_done(state);
 
drm_atomic_helper_wait_for_vblanks(drm, state);
-- 
2.12.0

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

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

[Daniel Stone]

Hi Jose,

On 24 March 2017 at 14:03, Jose Fonseca  wrote:
> On 22/03/17 20:57, Dylan Baker wrote:
>> Cross compiling for mingw is supported, and it provides a way to
>> differentiate
>> the build, host, and target machines [1], I've cross compiled for
>> aarch64-linux-gnu, and it was trivial (I've been told autotools has a flag
>> for
>> this, but the meson approach is to write an ini file once, and use it
>> again and
>> again), and the first example of cross compiling is using mingw from linux
>> [2].
>>
>>
>> [1]https://github.com/mesonbuild/meson/wiki/Reference-manual#build_machine-object
>> [2]https://github.com/mesonbuild/meson/wiki/Cross-compilation
>
>
> Thanks for the info.
>
> It still scares me a bit that most Meson users are mostly Linux focused.

That's not actually true ...

A lot of the reason GStreamer went towards Meson is because it has
native OS X (XCode project) and Windows (MinGW or Visual Studio
project) support. Meson's own source tree goes out of its way to use
spaces in directory and file names for its test suite, to make sure
that that support never breaks. Every build of Meson is CI'd on
AppVeyor as well as Travis for OS X. And of course, the GStreamer CI
uses Meson for its non-Linux builds.

It's true that a lot of the projects taking an interest of late have
been Linux, yes. But if you're native to Windows / OS X, you just use
VS/Xcode. There are (IMO) very few properly cross-platform projects
who are 'Windows projects with a port' or 'mainly OS X but also runs
on Linux', rather than cross-platform 'Linux projects'.

> Another tool I heard good about but have not direct experience is
> https://bazel.build .  Any thoughts about it?

If you look at the FAQ, one of the first things you'll see is that
they don't properly support Windows. It also requires Java to run,
which I'd say would be a no-go if people are already complaining about
the impossibility of installing several megabytes of Python stdlib.

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

Re: [PATCH 08/19] drm/tilcdc: Drop calls to modeset_lock_crtc

[Jyri Sarha]

On 03/22/17 23:50, Daniel Vetter wrote:
> Again this is an internal helper, not the official way to lock a crtc.
> 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Signed-off-by: Daniel Vetter 

Acked-by: Jyri Sarha 

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index c92faa8f7560..afd2a7b2aff7 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -579,7 +579,7 @@ static void tilcdc_crtc_recover_work(struct work_struct 
> *work)
>  
>   dev_info(crtc->dev->dev, "%s: Reset CRTC", __func__);
>  
> - drm_modeset_lock_crtc(crtc, NULL);
> + drm_modeset_lock(&crtc->mutex, NULL);
>  
>   if (!tilcdc_crtc_is_on(crtc))
>   goto out;
> @@ -587,7 +587,7 @@ static void tilcdc_crtc_recover_work(struct work_struct 
> *work)
>   tilcdc_crtc_disable(crtc);
>   tilcdc_crtc_enable(crtc);
>  out:
> - drm_modeset_unlock_crtc(crtc);
> + drm_modeset_unlock(&crtc->mutex);
>  }
>  
>  static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
> @@ -595,9 +595,9 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
>   struct tilcdc_drm_private *priv = crtc->dev->dev_private;
>  
> - drm_modeset_lock_crtc(crtc, NULL);
> + drm_modeset_lock(&crtc->mutex, NULL);
>   tilcdc_crtc_disable(crtc);
> - drm_modeset_unlock_crtc(crtc);
> + drm_modeset_unlock(&crtc->mutex);
>  
>   flush_workqueue(priv->wq);
>  
> @@ -856,7 +856,7 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
>   struct tilcdc_drm_private *priv = dev->dev_private;
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
>  
> - drm_modeset_lock_crtc(crtc, NULL);
> + drm_modeset_lock(&crtc->mutex, NULL);
>   if (tilcdc_crtc->lcd_fck_rate != clk_get_rate(priv->clk)) {
>   if (tilcdc_crtc_is_on(crtc)) {
>   pm_runtime_get_sync(dev->dev);
> @@ -868,7 +868,7 @@ void tilcdc_crtc_update_clk(struct drm_crtc *crtc)
>   pm_runtime_put_sync(dev->dev);
>   }
>   }
> - drm_modeset_unlock_crtc(crtc);
> + drm_modeset_unlock(&crtc->mutex);
>  }
>  
>  #define SYNC_LOST_COUNT_LIMIT 50
> 

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

[Bug 86351] HDMI audio garbled output on Radeon R9 280X

[bugzilla-daemon]

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

--- Comment #28 from Andy Furniss (adf.li...@gmail.com) ---
Yea, I fount that you need io load, I use mprime - but not the test that just
stresses cpu...

Of course using pulse, as most people do, avoids the bug as it uses sound
different from alsa.

TODO - try and get jack to recreate what pulse does.

This is alsa -

andy@andy-desktop:~$ cat /proc/asound/card1/pcm3p/sub0/hw_params 
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 480
buffer_size: 11040

and pulse (well I didn't actually install pulse on my main LFS setup - but
tested with a ubuntu boot - so maybe there are other differences).

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 8192
buffer_size: 16384

I never had any luck playing with period/buffer size so I assume (possibly
falsely) that the different access method is relevant.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [CRTC:24] vblank wait timed out

[Philipp Zabel]

On Fri, 2017-03-24 at 10:24 +, Martyn Welch wrote:
[...]
> > Could you move to v4.9 or v4.10 and check if the four patches in
> > https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.9-ipu-dp-plane-fix
> > or
> > https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.10-ipu-dp-plane-fix-2
> > help?
> > 
> 
> I've updated to v4.10, the patches from v4.10-ipu-dp-plane-fix-2 resolve
> the error, though we are unfortunately still experiencing the loss of
> output on LVDS display. Time to look elsewhere for the cause of that I
> guess. :-)

Is the LVDS serial clock derived from the video PLL on that board?
(What is the output of /sys/kernel/debug/clk/clk_summary?)

If you are driving high resolution displays from the same IPU, this
could also be a bandwidth issue. Maybe try severing the ipu1->hdmi and
ipu2->ldb links in the device tree as done in imx6q-utilite-pro.dts.

regards
Philipp

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

[Bug 86351] HDMI audio garbled output on Radeon R9 280X

[bugzilla-daemon]

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

--- Comment #27 from Gerion (gerion-ker...@flump.de) ---
I've experienced a little more with CPU load and it seems, that not the CPU
load is the essential part, but the memory access.

To be concrete:
stress -m 1
is enough to let the sound play normal,
stress -c X
results in load, but does not change the audio.
(I use this programm: http://people.seas.harvard.edu/~apw/stress/)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100375] forced EDID's can cause a amdgpu to null ptr deref

[bugzilla-daemon]

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

Bug ID: 100375
   Summary: forced EDID's can cause a amdgpu to null ptr deref
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: funfunc...@folklore1984.net

[  307.570505] [drm] Got external EDID base block and 0 extensions from
"edid/768x384.bin" for connector "VGA-1"
[  445.605230] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
remainder is 60
[  445.605232] Raw EDID:
[  445.605235]  00 ff ff ff ff ff ff 00 39 f6 05 04 16 07 02 00
[  445.605236]  10 17 01 03 81 1e 17 b4 ea c1 e5 a3 57 4e 9c 23
[  445.605237]  1d 50 54 21 08 00 01 01 01 01 01 01 01 01 01 01
[  445.605238]  01 01 01 07 01 01 91 26 4f ff ff ff ff ff ff ff
[  445.605239]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  445.605240]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  445.605240]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  445.605241]  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  445.606369] [drm:amdgpu_connector_dvi_detect [amdgpu]] *ERROR* HDMI-A-1:
probed a monitor but no|invalid EDID




 # reboot

INIT: Sending processes the KILL signal
[  521.758143] BUG: unable to handle kernel NULL pointer dereference at
0008
[  521.765999] IP: [] set_root+0x1d/0xa0
[  521.771242] PGD 0 [  521.773080] 
[  521.774580] Oops:  [#1] SMP
[  521.17] Modules linked in: amdgpu blackmagic_io(PO) ttm backlight
hid_sony led_class
[  521.785920] CPU: 2 PID: 3694 Comm: hyperflow-engin Tainted: P   O   
4.9.6-gentoo-r1 #1
[  521.794610] Hardware name: BIOSTAR Group A68N-5200/A68N-5200, BIOS 4.6.5
09/03/2015
[  521.802255] task: 880225698c40 task.stack: c9db8000
[  521.808165] RIP: 0010:[]  []
set_root+0x1d/0xa0
[  521.815828] RSP: 0018:c9dbb688  EFLAGS: 00010202
[  521.821133] RAX: 880225698c40 RBX: c9dbb7c0 RCX:
880225a63400
[  521.828256] RDX: 81c56e48 RSI: 0041 RDI:
c9dbb7c0
[  521.835381] RBP: c9dbb698 R08: 0001a980 R09:
880225a63400
[  521.842505] R10: 880225a80026 R11: 0010 R12:

[  521.849630] R13: 880225a8201c R14: 0001 R15:
880218826d80
[  521.856755] FS:  7fc3f57fa700() GS:88022ed0()
knlGS:
[  521.864834] CS:  0010 DS:  ES:  CR0: 80050033
[  521.870571] CR2: 0008 CR3: 01a08000 CR4:
000406e0
[  521.877694] Stack:
[  521.879706]  c9dbb7c0 0041 c9dbb6d8
81169b89
[  521.887160]  880220ead600 880225a82000 c9dbb7c0
c9dbb8cc
[  521.894612]  0001 880218826d80 c9dbb7b0
8116c28a
[  521.902067] Call Trace:
[  521.904515]  [] path_init+0x1e9/0x330
[  521.909740]  [] path_openat+0x6a/0x1480
[  521.915141]  [] ? default_wake_function+0xd/0x10
[  521.921319]  [] ? __wake_up_common+0x4d/0x80
[  521.927145]  [] do_filp_open+0x79/0xd0
[  521.932467]  [] ? acpi_driver_match_device+0x3d/0x5d
[  521.938991]  [] ? platform_match+0x24/0xa0
[  521.944644]  [] ? klist_next+0x21/0xf0
[  521.949957]  [] file_open_name+0xdf/0x100
[  521.955529]  [] filp_open+0x2e/0x50
[  521.960573]  [] kernel_read_file_from_path+0x31/0x70
[  521.967092]  [] _request_firmware+0x2ef/0x5a0
[  521.973002]  [] request_firmware+0x32/0x50
[  521.978654]  [] drm_load_edid_firmware+0x264/0x500
[  521.985001]  []
drm_helper_probe_single_connector_modes+0x14c/0x4d0
[  521.992826]  []
drm_fb_helper_probe_connector_modes.isra.7+0x48/0x70
[  522.000738]  [] drm_fb_helper_hotplug_event+0x94/0xd0
[  522.007343]  []
drm_fb_helper_restore_fbdev_mode_unlocked+0x1bc/0x2a0
[  522.015381]  [] ? amdgpu_driver_postclose_kms+0x90/0xd0
[amdgpu]
[  522.022965]  [] amdgpu_fbdev_restore_mode+0x15/0x40
[amdgpu]
[  522.030199]  [] amdgpu_driver_lastclose_kms+0xd/0x10
[amdgpu]
[  522.037505]  [] drm_lastclose+0x36/0xf0
[  522.042895]  [] drm_release+0x2a5/0x360
[  522.048288]  [] __fput+0xda/0x1e0
[  522.053167]  [] fput+0x9/0x10
[  522.058039]  [] task_work_run+0x79/0xa0
[  522.063438]  [] do_exit+0x34a/0xaa0
[  522.068533]  [] ? _ZN10IOWorkLoop8openGateEv+0xd/0x10
[blackmagic_io]
[  522.076524]  [] do_group_exit+0x40/0xa0
[  522.081916]  [] get_signal+0x272/0x5e0
[  522.087246]  [] ?
_ZN15UserClientClass21getFlushedInputFramesEPcPj+0x1e/0x20 [blackmagic_io]
[  522.097233]  [] do_signal+0x23/0x5b0
[  522.102395]  [] ?
_ZN20UserClientClassLinux5ioctlEjm+0x8a/0xa0 [blackmagic_io]
[  522.93]  [] ? bmio_client_ioctl+0xc/0x10
[blackmagic_io]
[  522.118424]  [] ? __do_global_dtors_aux+0x145/0x540
[blackmagic_io]
[  522.126251]  [] ? do_vfs_ioctl+0x8b/0x5a0
[  522.131823]  [] ? ktime_ge

Re: [CRTC:24] vblank wait timed out

[Martyn Welch]

On Tue, Mar 21, 2017 at 06:18:44PM +0100, Philipp Zabel wrote:
> Hi Martyn,
> 
> On Tue, 2017-03-21 at 09:50 +, Martyn Welch wrote:
> > I have an i.MX6 platform with 2 display port interfaces, one driven by the
> > HDMI interface, the other by LVDS, both via bridges. We are currently
> > experiencing the following error when we boot with the monitor connected
> > to the LVDS backed interface and then connect a monitor to the HDMI backed
> > interface after boot:
> > 
> > Mar 20 18:15:23 GE00409729044C kernel: [ cut here ]
> > Mar 20 18:15:23 GE00409729044C kernel: WARNING: CPU: 1 PID: 85 at 
> > /home/martyn/build-helix/tmp/work-shared/csmon/kernel-source/drivers/gpu/drm/drm_atomic_helper.c:1121
> >  drm_atomic_helper_wait_for_vblanks+0x264/0x274
> > Mar 20 18:15:23 GE00409729044C kernel: [CRTC:24] vblank wait timed out
> > Mar 20 18:15:23 GE00409729044C kernel: Modules linked in: bonding 
> > snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi cp210x usbserial 
> > atmel_mxt_ts
> > Mar 20 18:15:23 GE00409729044C kernel: CPU: 1 PID: 85 Comm: kworker/u4:1 
> > Not tainted 4.8.0 #4
> > Mar 20 18:15:23 GE00409729044C kernel: Hardware name: Freescale i.MX6 
> > Quad/DualLite (Device Tree)
> > Mar 20 18:15:23 GE00409729044C kernel: Workqueue: events_unbound commit_work
> > Mar 20 18:15:23 GE00409729044C kernel: Backtrace:
> > Mar 20 18:15:23 GE00409729044C kernel: [<8010c968>] (dump_backtrace) from 
> > [<8010cbb0>] (show_stack+0x20/0x24)
> > Mar 20 18:15:23 GE00409729044C kernel:  r7: r6:80d2bf98 r5:600b0013 
> > r4:
> > Mar 20 18:15:23 GE00409729044C kernel: [<8010cb90>] (show_stack) from 
> > [<803c0e68>] (dump_stack+0x98/0xb4)
> > Mar 20 18:15:23 GE00409729044C kernel: [<803c0dd0>] (dump_stack) from 
> > [<80122abc>] (__warn+0xe4/0x110)
> > Mar 20 18:15:23 GE00409729044C kernel:  r7:0009 r6:80a8d490 r5: 
> > r4:ee173e10
> > Mar 20 18:15:23 GE00409729044C kernel: [<801229d8>] (__warn) from 
> > [<80122b2c>] (warn_slowpath_fmt+0x44/0x4c)
> > Mar 20 18:15:23 GE00409729044C kernel:  r9:ee1e5418 r8: r7: 
> > r6: r5:ecc04f00 r4:80a8d5ec
> > Mar 20 18:15:23 GE00409729044C kernel: [<80122aec>] (warn_slowpath_fmt) 
> > from [<80486ce0>] (drm_atomic_helper_wait_for_vblanks+0x264/0x274)
> > Mar 20 18:15:23 GE00409729044C kernel:  r3:0018 r2:80a8d5ec
> > Mar 20 18:15:23 GE00409729044C kernel:  r4:edaa8200
> > Mar 20 18:15:23 GE00409729044C kernel: [<80486a7c>] 
> > (drm_atomic_helper_wait_for_vblanks) from [<804b3990>] 
> > (imx_drm_atomic_commit_tail+0x1b4/0x1e0)
> > Mar 20 18:15:23 GE00409729044C kernel:  r10:0ee80680 r9:80d76580 
> > r8: r7:ee1e5000 r6:ecc04f00 r5:
> > Mar 20 18:15:23 GE00409729044C kernel:  r4:0004
> > Mar 20 18:15:23 GE00409729044C kernel: [<804b37dc>] 
> > (imx_drm_atomic_commit_tail) from [<80487498>] (commit_tail+0x50/0x6c)
> > Mar 20 18:15:23 GE00409729044C kernel:  r7:ee806800 r6:ee82b000 r5:80d3a5fc 
> > r4:ecc04f00
> > Mar 20 18:15:23 GE00409729044C kernel: [<80487448>] (commit_tail) from 
> > [<804874d0>] (commit_work+0x1c/0x20)
> > Mar 20 18:15:23 GE00409729044C kernel:  r5:eeb97280 r4:ecc04f1c
> > Mar 20 18:15:23 GE00409729044C kernel: [<804874b4>] (commit_work) from 
> > [<8013b638>] (process_one_work+0x154/0x510)
> > Mar 20 18:15:23 GE00409729044C kernel: [<8013b4e4>] (process_one_work) from 
> > [<8013ba30>] (worker_thread+0x3c/0x5cc)
> > Mar 20 18:15:23 GE00409729044C kernel:  r10:eeb97280 r9:ee82b000 
> > r8:80d02100 r7:ee82b018 r6:0088 r5:eeb97298
> > Mar 20 18:15:23 GE00409729044C kernel:  r4:ee82b000
> > Mar 20 18:15:23 GE00409729044C kernel: [<8013b9f4>] (worker_thread) from 
> > [<80141670>] (kthread+0xe4/0x100)
> > Mar 20 18:15:23 GE00409729044C kernel:  r10: r9: 
> > r8: r7:8013b9f4 r6:eeb97280 r5:eebae640
> > Mar 20 18:15:23 GE00409729044C kernel:  r4:
> > Mar 20 18:15:23 GE00409729044C kernel: [<8014158c>] (kthread) from 
> > [<80108278>] (ret_from_fork+0x14/0x3c)
> > Mar 20 18:15:23 GE00409729044C kernel:  r7: r6: r5:8014158c 
> > r4:eebae640
> > Mar 20 18:15:23 GE00409729044C kernel: ---[ end trace ba005811962ba6f2 ]---
> > 
> > We believe this may be due to the vblank interrupt for the LVDS interface
> > being affected when the vblank interface for the HDMI backed interface
> > gets enabled. Any pointers regarding how to proceed narrowing down/fixing
> > this would be appreciated.
> > 
> > We are currently running 4.8 kernel with 1.11 Weston compositor.
> > 
> > Martyn
> 
> Could you move to v4.9 or v4.10 and check if the four patches in
> https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.9-ipu-dp-plane-fix
> or
> https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.10-ipu-dp-plane-fix-2
> help?
> 

I've updated to v4.10, the patches from v4.10-ipu-dp-plane-fix-2 resolve
the error, though we are unfortunately still experiencing the loss of
output on LVDS display. Time to look elsewhere for the cause of that I
guess

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

[bugzilla-daemon]

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

--- Comment #26 from intermedi...@hotmail.com  ---
Need to notice the issue now is present on 8x slot too on kernel 4.11 rc3

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Michel Dänzer]

On 24/03/17 12:31 AM, Zachary Michaels wrote:
> 
> I should also note that we are experiencing another issue where the
> kernel locks up in similar circumstances. As Julien noted, we get no
> output, and the watchdogs don't seem to work. It may be the case that
> Xorg and our process are calling ttm_bo_mem_force_space concurrently,
> but I don't think we have enough information yet to say for
> sure. Reverting this commit does not fix that issue. I have some small
> amount of evidence indicating that bos flagged for CPU access are
> getting placed in CPU inaccessible memory. Could that cause this sort of
> kernel lockup?

Possibly, does this help?

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 37d68cd1f272..40d1bb467a71 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -198,7 +198,8 @@ static void radeon_evict_flags(struct ttm_buffer_object *bo,
case TTM_PL_VRAM:
if (rbo->rdev->ring[radeon_copy_ring_index(rbo->rdev)].ready == 
false)
radeon_ttm_placement_from_domain(rbo, 
RADEON_GEM_DOMAIN_CPU);
-   else if (rbo->rdev->mc.visible_vram_size < 
rbo->rdev->mc.real_vram_size &&
+   else if (!(rbo->flags & RADEON_GEM_CPU_ACCESS) &&
+rbo->rdev->mc.visible_vram_size < 
rbo->rdev->mc.real_vram_size &&
 bo->mem.start < (rbo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT)) {
unsigned fpfn = rbo->rdev->mc.visible_vram_size >> 
PAGE_SHIFT;
int i;



-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Michel Dänzer]

On 24/03/17 06:50 PM, Julien Isorce wrote:
> Hi Michel,
> 
> (Just for other readers my reply has been delayed on the mailing lists
> and should have been on second position)

It is on https://patchwork.freedesktop.org/patch/145731/ , did you mean
something else?

The delay was because you weren't subscribed to the amd-gfx mailing list
yet, so your post went through the moderation queue.


> I will have a go with that change and let you know. I do not remember if
> I tried it for this soft lockup. But for sure it does not solve the hard
> lockup that Zach also mentioned at the end of his reply.

I'll follow up to his post about that.


> But in general, isn't "radeon_lockup_timeout" supposed to detect this
> situation ?

No, it's for detecting GPU hangs, whereas this is a CPU "hang" (infinite
loop).


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

[Julien Isorce]

Hi Michel,

(Just for other readers my reply has been delayed on the mailing lists and
should have been on second position)

We have actually spotted this /0/i/ but somehow I convinced myself it was
intentional. The reason I found was that you wanted to set the fpfn only if
there is 2 placements, which means it will try to move from accessible to
inaccessible.

I will have a go with that change and let you know. I do not remember if I
tried it for this soft lockup. But for sure it does not solve the hard
lockup that Zach also mentioned at the end of his reply. I am saying that
because this other issue has some similarities (same ioctl call).

But in general, isn't "radeon_lockup_timeout" supposed to detect this
situation ?

Thx
Julien


On 24 March 2017 at 09:24, Michel Dänzer  wrote:

> On 23/03/17 06:26 PM, Julien Isorce wrote:
> > Hi Michel,
> >
> > When it happens, the main thread of our gl based app is stuck on a
> > ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but
> > same thing happens if true. Other threads are only si_shader:0,1,2,3 and
> > are doing nothing, just waiting for jobs. I can also do sudo gdb -p
> > $(pidof Xorg) to block the X11 server, to make sure there is no ping
> > pong between 2 processes. All other processes are not loading
> > dri/radeonsi_dri.so . And adding a few traces shows that the above ioctl
> > call is looping for ever on
> > https://github.com/torvalds/linux/blob/master/drivers/gpu/
> drm/ttm/ttm_bo.c#L819
> >  drm/ttm/ttm_bo.c#L819> and
> > comes from
> > mesa https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/
> winsys/radeon/drm/radeon_drm_cs.c#n454
> > .
> >
> > After adding even more traces I can see that the bo, which is being
> > indefinitely evicted, has the flag RADEON_GEM_NO_CPU_ACCESS.
> > And it gets 3 potential placements after calling "radeon_evict_flags".
> >  1: VRAM cpu inaccessible, fpfn is 65536
> >  2: VRAM cpu accessible, fpfn is 0
> >  3: GTT, fpfn is 0
> >
> > And it looks like it continuously succeeds to move on the second
> > placement. So I might be wrong but it looks it is not even a ping pong
> > between VRAM accessible / not accessible, it just keeps being blited in
> > the CPU accessible part of the VRAM.
>
> Thanks for the detailed description! AFAICT this can only happen due to
> a silly mistake I made in this code. Does this fix it?
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/
> radeon_ttm.c
> index 5c7cf644ba1d..37d68cd1f272 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -213,8 +213,8 @@ static void radeon_evict_flags(struct
> ttm_buffer_object *bo,
> rbo->placement.num_busy_placement = 0;
> for (i = 0; i < rbo->placement.num_placement; i++)
> {
> if (rbo->placements[i].flags &
> TTM_PL_FLAG_VRAM) {
> -   if (rbo->placements[0].fpfn < fpfn)
> -   rbo->placements[0].fpfn =
> fpfn;
> +   if (rbo->placements[i].fpfn < fpfn)
> +   rbo->placements[i].fpfn =
> fpfn;
> } else {
> rbo->placement.busy_placement =
> &rbo->placements[i];
>
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 08/19] drm/tilcdc: Drop calls to modeset_lock_crtc

[Tomi Valkeinen]

On 22/03/17 23:50, Daniel Vetter wrote:
> Again this is an internal helper, not the official way to lock a crtc.
> 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Reviewed-by: Tomi Valkeinen 

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv2 21/31] drm/omap: dss: Functions to check components in the display/output list

[Tomi Valkeinen]

From: Peter Ujfalusi 

The functions can be used to check a component (by it's of_node) if it is
part of the omapdss display or output list. If the component is found, it
means that the driver is loaded.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/display.c | 18 ++
 drivers/gpu/drm/omapdrm/dss/omapdss.h |  3 +++
 drivers/gpu/drm/omapdrm/dss/output.c  | 13 +
 3 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index e567ff68b216..94c012e0584b 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -132,6 +132,24 @@ void omapdss_unregister_display(struct omap_dss_device 
*dssdev)
 }
 EXPORT_SYMBOL(omapdss_unregister_display);
 
+bool omapdss_component_is_display(struct device_node *node)
+{
+   struct omap_dss_device *dssdev;
+   bool found = false;
+
+   mutex_lock(&panel_list_mutex);
+   list_for_each_entry(dssdev, &panel_list, panel_list) {
+   if (dssdev->dev->of_node == node) {
+   found = true;
+   goto out;
+   }
+   }
+out:
+   mutex_unlock(&panel_list_mutex);
+   return found;
+}
+EXPORT_SYMBOL(omapdss_component_is_display);
+
 struct omap_dss_device *omap_dss_get_device(struct omap_dss_device *dssdev)
 {
if (!try_module_get(dssdev->owner))
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 4545f1824e66..7e1feb935137 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -936,4 +936,7 @@ struct dispc_ops {
 void dispc_set_ops(const struct dispc_ops *o);
 const struct dispc_ops *dispc_get_ops(void);
 
+bool omapdss_component_is_display(struct device_node *node);
+bool omapdss_component_is_output(struct device_node *node);
+
 #endif /* __OMAP_DRM_DSS_H */
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
b/drivers/gpu/drm/omapdrm/dss/output.c
index 2b999dc48621..655c5d73eac9 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -107,6 +107,19 @@ void omapdss_unregister_output(struct omap_dss_device *out)
 }
 EXPORT_SYMBOL(omapdss_unregister_output);
 
+bool omapdss_component_is_output(struct device_node *node)
+{
+   struct omap_dss_device *out;
+
+   list_for_each_entry(out, &output_list, list) {
+   if (out->dev->of_node == node)
+   return true;
+   }
+
+   return false;
+}
+EXPORT_SYMBOL(omapdss_component_is_output);
+
 struct omap_dss_device *omap_dss_get_output(enum omap_dss_output_id id)
 {
struct omap_dss_device *out;
-- 
2.7.4

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

[PATCHv2 22/31] drm/omap: dss: Support for detecting display stack readiness

[Tomi Valkeinen]

From: Peter Ujfalusi 

When omapdss is loaded (all core components are in place) create a list of
devices used in the display graph. This list later can be used by omapdrm
via the omapdss_stack_is_ready() function to check that these components
are loaded. Based on this information, omapdrm can defer probe in case when
the omapdss stack is not ready yet.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/base.c| 107 ++
 drivers/gpu/drm/omapdrm/dss/dss.c |   1 +
 drivers/gpu/drm/omapdrm/dss/omapdss.h |   3 +
 3 files changed, 111 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/dss/base.c 
b/drivers/gpu/drm/omapdrm/dss/base.c
index 7dd447e6c4d7..13e91faaf7a6 100644
--- a/drivers/gpu/drm/omapdrm/dss/base.c
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -1,9 +1,21 @@
 #include 
 #include 
+#include 
+#include 
+#include 
+#include "omapdss.h"
 
 static bool dss_initialized;
 static const struct dispc_ops *ops;
 
+static struct list_head omapdss_comp_list;
+
+struct omapdss_comp_node {
+   struct list_head list;
+   struct device_node *node;
+   bool dss_core_component;
+};
+
 void omapdss_set_is_initialized(bool set)
 {
dss_initialized = set;
@@ -28,6 +40,101 @@ const struct dispc_ops *dispc_get_ops(void)
 }
 EXPORT_SYMBOL(dispc_get_ops);
 
+static bool omapdss_list_contains(const struct device_node *node)
+{
+   struct omapdss_comp_node *comp;
+
+   list_for_each_entry(comp, &omapdss_comp_list, list) {
+   if (comp->node == node)
+   return true;
+   }
+
+   return false;
+}
+
+static void omapdss_walk_device(struct device *dev, struct device_node *node,
+   bool dss_core)
+{
+   struct device_node *n;
+   struct omapdss_comp_node *comp = devm_kzalloc(dev, sizeof(*comp),
+ GFP_KERNEL);
+
+   if (comp) {
+   comp->node = node;
+   comp->dss_core_component = dss_core;
+   list_add(&comp->list, &omapdss_comp_list);
+   }
+
+   /*
+* of_graph_get_remote_port_parent() prints an error if there is no
+* port/ports node. To avoid that, check first that there's the node.
+*/
+   n = of_get_child_by_name(node, "ports");
+   if (!n)
+   n = of_get_child_by_name(node, "port");
+   if (!n)
+   return;
+
+   of_node_put(n);
+
+   n = NULL;
+   while ((n = of_graph_get_next_endpoint(node, n)) != NULL) {
+   struct device_node *pn = of_graph_get_remote_port_parent(n);
+
+   if (!pn)
+   continue;
+
+   if (!of_device_is_available(pn) || omapdss_list_contains(pn)) {
+   of_node_put(pn);
+   continue;
+   }
+
+   omapdss_walk_device(dev, pn, false);
+   }
+}
+
+void omapdss_gather_components(struct device *dev)
+{
+   struct device_node *child;
+
+   INIT_LIST_HEAD(&omapdss_comp_list);
+
+   omapdss_walk_device(dev, dev->of_node, true);
+
+   for_each_available_child_of_node(dev->of_node, child) {
+   if (!of_find_property(child, "compatible", NULL))
+   continue;
+
+   omapdss_walk_device(dev, child, true);
+   }
+}
+EXPORT_SYMBOL(omapdss_gather_components);
+
+static bool omapdss_component_is_loaded(struct omapdss_comp_node *comp)
+{
+   if (comp->dss_core_component)
+   return true;
+   if (omapdss_component_is_display(comp->node))
+   return true;
+   if (omapdss_component_is_output(comp->node))
+   return true;
+
+   return false;
+}
+
+bool omapdss_stack_is_ready(void)
+{
+   struct omapdss_comp_node *comp;
+
+   list_for_each_entry(comp, &omapdss_comp_list, list) {
+   if (!omapdss_component_is_loaded(comp))
+   return false;
+   }
+
+   return true;
+}
+EXPORT_SYMBOL(omapdss_stack_is_ready);
+
 MODULE_AUTHOR("Tomi Valkeinen ");
 MODULE_DESCRIPTION("OMAP Display Subsystem Base");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.c 
b/drivers/gpu/drm/omapdrm/dss/dss.c
index 5eb2f1260547..ceb483650f8c 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss.c
@@ -1258,6 +1258,7 @@ static int dss_bind(struct device *dev)
 
pm_set_vt_switch(0);
 
+   omapdss_gather_components(dev);
omapdss_set_is_initialized(true);
 
return 0;
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 7e1feb935137..d5c369bd565c 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -939,4 +939,7 @@ const struct dispc_ops *dispc_get_ops(void);
 bool omapdss_component_is_display(struct device_node *node);
 bool omapdss_component_is_output(struct de

[PATCHv2 27/31] drm/omap: poll only connectors where the connect/disconnect can be checked

[Tomi Valkeinen]

From: Peter Ujfalusi 

When the connector associated detect callback is not provided, we can not
detect if the display is connected or disconnected. These displays does not
support hot plug, they are always connected. Let DRM know that connectors
w/o detect callback should not be polled.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_connector.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index f90e2d22c5ec..50d2b641c28b 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -229,13 +229,11 @@ struct drm_connector *omap_connector_init(struct 
drm_device *dev,
connector_type);
drm_connector_helper_add(connector, &omap_connector_helper_funcs);
 
-#if 0 /* enable when dss2 supports hotplug */
-   if (dssdev->caps & OMAP_DSS_DISPLAY_CAP_HPD)
-   connector->polled = 0;
-   else
-#endif
+   if (dssdev->driver->detect)
connector->polled = DRM_CONNECTOR_POLL_CONNECT |
-   DRM_CONNECTOR_POLL_DISCONNECT;
+   DRM_CONNECTOR_POLL_DISCONNECT;
+   else
+   connector->polled = 0;
 
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
-- 
2.7.4

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

[PATCHv2 29/31] drm/omap: dispc: improve debug print of display flags

[Tomi Valkeinen]

Instead of printing 0/1 for display flags like vsync high/low, use a
tri-state print (-1/0/1) to indicate the "undefined" state.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 83241052df6b..2e6a71dbc25d 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -3229,6 +3229,16 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel 
channel,
}
 }
 
+static int vm_flag_to_int(enum display_flags flags, enum display_flags high,
+   enum display_flags low)
+{
+   if (flags & high)
+   return 1;
+   if (flags & low)
+   return -1;
+   return 0;
+}
+
 /* change name to mode? */
 static void dispc_mgr_set_timings(enum omap_channel channel,
   const struct videomode *vm)
@@ -3258,11 +3268,11 @@ static void dispc_mgr_set_timings(enum omap_channel 
channel,
t.hsync_len, t.hfront_porch, t.hback_porch,
t.vsync_len, t.vfront_porch, t.vback_porch);
DSSDBG("vsync_level %d hsync_level %d data_pclk_edge %d 
de_level %d sync_pclk_edge %d\n",
-   !!(t.flags & DISPLAY_FLAGS_VSYNC_HIGH),
-   !!(t.flags & DISPLAY_FLAGS_HSYNC_HIGH),
-   !!(t.flags & DISPLAY_FLAGS_PIXDATA_POSEDGE),
-   !!(t.flags & DISPLAY_FLAGS_DE_HIGH),
-   !!(t.flags & DISPLAY_FLAGS_SYNC_POSEDGE));
+   vm_flag_to_int(t.flags, DISPLAY_FLAGS_VSYNC_HIGH, 
DISPLAY_FLAGS_VSYNC_LOW),
+   vm_flag_to_int(t.flags, DISPLAY_FLAGS_HSYNC_HIGH, 
DISPLAY_FLAGS_HSYNC_LOW),
+   vm_flag_to_int(t.flags, DISPLAY_FLAGS_PIXDATA_POSEDGE, 
DISPLAY_FLAGS_PIXDATA_NEGEDGE),
+   vm_flag_to_int(t.flags, DISPLAY_FLAGS_DE_HIGH, 
DISPLAY_FLAGS_DE_LOW),
+   vm_flag_to_int(t.flags, DISPLAY_FLAGS_SYNC_POSEDGE, 
DISPLAY_FLAGS_SYNC_NEGEDGE));
 
DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
} else {
-- 
2.7.4

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

[PATCHv2 31/31] drm/omap: fix crash on module unload

[Tomi Valkeinen]

When unloading omapdrm we get a NULL pointer deref in
omap_drm_irq_uninstall(). This is caused by:

967dd48417874dd25491a4e933648f394a64f70f ("drm: remove
drm_vblank_no_hw_counter assignment from driver code")

As OMAP DSS does not have a HW vblank counter, vblank[i].last is anyway
always 0, so we can just remove the call to get_vblank_counter().

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_irq.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_irq.c 
b/drivers/gpu/drm/omapdrm/omap_irq.c
index 26a3c06aa14d..130fdc3225ed 100644
--- a/drivers/gpu/drm/omapdrm/omap_irq.c
+++ b/drivers/gpu/drm/omapdrm/omap_irq.c
@@ -299,8 +299,6 @@ void omap_drm_irq_uninstall(struct drm_device *dev)
for (i = 0; i < dev->num_crtcs; i++) {
wake_up(&dev->vblank[i].queue);
dev->vblank[i].enabled = false;
-   dev->vblank[i].last =
-   dev->driver->get_vblank_counter(dev, i);
}
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
}
-- 
2.7.4

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

[PATCHv2 12/31] drm/omap: display: don't use dsi_get_pixel_size()

[Tomi Valkeinen]

display.c uses dsi_get_pixel_size() which is implemented in the DSI
driver, and we won't have that in the omapdss-base module, to which we
want to move display.c

This patch changes display.c not to use dsi_get_pixel_size(). The call
can be replaced with a simple check for OMAP_DSS_DSI_FMT_RGB565.

We can also make dsi_get_pixel_size() static as it's no longer used
outside dsi.c.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/display.c | 6 +++---
 drivers/gpu/drm/omapdrm/dss/dsi.c | 2 +-
 drivers/gpu/drm/omapdrm/dss/dss.h | 8 
 3 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index 425a5a8dff8b..333ba284ef6d 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -55,10 +55,10 @@ int omapdss_default_get_recommended_bpp(struct 
omap_dss_device *dssdev)
else
return 16;
case OMAP_DISPLAY_TYPE_DSI:
-   if (dsi_get_pixel_size(dssdev->panel.dsi_pix_fmt) > 16)
-   return 24;
-   else
+   if (dssdev->panel.dsi_pix_fmt == OMAP_DSS_DSI_FMT_RGB565)
return 16;
+   else
+   return 24;
case OMAP_DISPLAY_TYPE_VENC:
case OMAP_DISPLAY_TYPE_SDI:
case OMAP_DISPLAY_TYPE_HDMI:
diff --git a/drivers/gpu/drm/omapdrm/dss/dsi.c 
b/drivers/gpu/drm/omapdrm/dss/dsi.c
index 5e51a5649efb..f50d6fc0d92e 100644
--- a/drivers/gpu/drm/omapdrm/dss/dsi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dsi.c
@@ -527,7 +527,7 @@ static inline int wait_for_bit_change(struct 
platform_device *dsidev,
return !value;
 }
 
-u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
+static u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
 {
switch (fmt) {
case OMAP_DSS_DSI_FMT_RGB888:
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 78f6fc75948b..4d568ac76826 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -315,15 +315,7 @@ void dsi_uninit_platform_driver(void);
 void dsi_dump_clocks(struct seq_file *s);
 
 void dsi_irq_handler(void);
-u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt);
 
-#else
-static inline u8 dsi_get_pixel_size(enum omap_dss_dsi_pixel_format fmt)
-{
-   WARN(1, "%s: DSI not compiled in, returning pixel_size as 0\n",
-__func__);
-   return 0;
-}
 #endif
 
 /* DPI */
-- 
2.7.4

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

[PATCHv2 24/31] drm/omap: fix plane update warning when crtc is disabled

[Tomi Valkeinen]

If omap_plane_atomic_update() is called when the crtc is disabled, and
the timings are zero, we'll see the following warning:

omapdss DISPC error: cannot calculate scaling settings: pclk is zero
omapdrm omapdrm.0: Failed to setup plane vid2

It shouldn't cause any issues, as the crtc is disabled so the plane is
not used by the HW.

To remove the warning, check whether the crtc is enabled at the
beginning of omap_plane_atomic_update(), and bail out if not.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_plane.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 78a92422ede1..27c1902415de 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -86,6 +86,11 @@ static void omap_plane_atomic_update(struct drm_plane *plane,
 
DBG("%s, crtc=%p fb=%p", omap_plane->name, state->crtc, state->fb);
 
+   if (!state->crtc->state->enable) {
+   priv->dispc_ops->ovl_enable(omap_plane->id, false);
+   return;
+   }
+
memset(&info, 0, sizeof(info));
info.rotation_type = OMAP_DSS_ROT_DMA;
info.rotation = OMAP_DSS_ROT_0;
-- 
2.7.4

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

[PATCHv2 17/31] drm/omap: use dispc_ops

[Tomi Valkeinen]

Change omapdrm to get dispc_ops and use that to call the dispc functions
instead or direct function calls.

The change is very straightforward.

The only problem was in omap_crtc_init() which calls pipe2vbl(crtc), and
at that point of time the crtc->dev link, which is used to get the
dispc_ops, has not been set up yet. This patch makes omap_crtc_init()
skip the call to pipe2vbl() and instead calls
dispc_ops->mgr_get_vsync_irq() directly.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 36 +++-
 drivers/gpu/drm/omapdrm/omap_drv.c   | 10 ++
 drivers/gpu/drm/omapdrm/omap_drv.h   |  2 ++
 drivers/gpu/drm/omapdrm/omap_irq.c   | 33 +
 drivers/gpu/drm/omapdrm/omap_plane.c | 15 +--
 5 files changed, 57 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 49fc61963af4..1db96b077ae8 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -107,10 +107,12 @@ static struct omap_dss_device *omap_crtc_output[8];
 static int omap_crtc_dss_connect(enum omap_channel channel,
struct omap_dss_device *dst)
 {
+   const struct dispc_ops *dispc_ops = dispc_get_ops();
+
if (omap_crtc_output[channel])
return -EINVAL;
 
-   if ((dispc_mgr_get_supported_outputs(channel) & dst->id) == 0)
+   if ((dispc_ops->mgr_get_supported_outputs(channel) & dst->id) == 0)
return -EINVAL;
 
omap_crtc_output[channel] = dst;
@@ -134,6 +136,7 @@ static void omap_crtc_dss_start_update(enum omap_channel 
channel)
 static void omap_crtc_set_enabled(struct drm_crtc *crtc, bool enable)
 {
struct drm_device *dev = crtc->dev;
+   struct omap_drm_private *priv = dev->dev_private;
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
enum omap_channel channel = omap_crtc->channel;
struct omap_irq_wait *wait;
@@ -144,7 +147,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
return;
 
if (omap_crtc_output[channel]->output_type == OMAP_DISPLAY_TYPE_HDMI) {
-   dispc_mgr_enable(channel, enable);
+   priv->dispc_ops->mgr_enable(channel, enable);
omap_crtc->enabled = enable;
return;
}
@@ -157,8 +160,8 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
omap_crtc->ignore_digit_sync_lost = true;
}
 
-   framedone_irq = dispc_mgr_get_framedone_irq(channel);
-   vsync_irq = dispc_mgr_get_vsync_irq(channel);
+   framedone_irq = priv->dispc_ops->mgr_get_framedone_irq(channel);
+   vsync_irq = priv->dispc_ops->mgr_get_vsync_irq(channel);
 
if (enable) {
wait = omap_irq_wait_init(dev, vsync_irq, 1);
@@ -178,7 +181,7 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
wait = omap_irq_wait_init(dev, vsync_irq, 2);
}
 
-   dispc_mgr_enable(channel, enable);
+   priv->dispc_ops->mgr_enable(channel, enable);
omap_crtc->enabled = enable;
 
ret = omap_irq_wait(dev, wait, msecs_to_jiffies(100));
@@ -198,9 +201,9 @@ static void omap_crtc_set_enabled(struct drm_crtc *crtc, 
bool enable)
 static int omap_crtc_dss_enable(enum omap_channel channel)
 {
struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct omap_drm_private *priv = omap_crtc->base.dev->dev_private;
 
-   dispc_mgr_set_timings(omap_crtc->channel,
-   &omap_crtc->vm);
+   priv->dispc_ops->mgr_set_timings(omap_crtc->channel, &omap_crtc->vm);
omap_crtc_set_enabled(&omap_crtc->base, true);
 
return 0;
@@ -225,8 +228,10 @@ static void omap_crtc_dss_set_lcd_config(enum omap_channel 
channel,
const struct dss_lcd_mgr_config *config)
 {
struct omap_crtc *omap_crtc = omap_crtcs[channel];
+   struct omap_drm_private *priv = omap_crtc->base.dev->dev_private;
+
DBG("%s", omap_crtc->name);
-   dispc_mgr_set_lcd_config(omap_crtc->channel, config);
+   priv->dispc_ops->mgr_set_lcd_config(omap_crtc->channel, config);
 }
 
 static int omap_crtc_dss_register_framedone(
@@ -274,6 +279,8 @@ void omap_crtc_error_irq(struct drm_crtc *crtc, uint32_t 
irqstatus)
 void omap_crtc_vblank_irq(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+   struct drm_device *dev = omap_crtc->base.dev;
+   struct omap_drm_private *priv = dev->dev_private;
bool pending;
 
spin_lock(&crtc->dev->event_lock);
@@ -281,7 +288,7 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
 * If the dispc is busy we're racing the flush operation. Try again on
 * the next vblank interrupt.
 */
-   if (dispc_mgr_go_busy(omap_crtc->channel)) {
+   if (priv->dispc_ops->mgr_go_busy(omap_crtc->ch

[PATCHv2 25/31] drm/omap: display: Add displays in sorted order to the panel_list

[Tomi Valkeinen]

From: Peter Ujfalusi 

Keep the panel_list ordered according to aliases. The DRM connectors will
be created following the panel_list. By keeping the list ordered the DRM
connectors will be created in the same order regardless of the driver
probe order.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/display.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index 94c012e0584b..26cb59be045e 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -83,6 +83,7 @@ static int disp_num_counter;
 int omapdss_register_display(struct omap_dss_device *dssdev)
 {
struct omap_dss_driver *drv = dssdev->driver;
+   struct list_head *cur;
int id;
 
/*
@@ -118,7 +119,14 @@ int omapdss_register_display(struct omap_dss_device 
*dssdev)
drv->get_timings = omapdss_default_get_timings;
 
mutex_lock(&panel_list_mutex);
-   list_add_tail(&dssdev->panel_list, &panel_list);
+   list_for_each(cur, &panel_list) {
+   struct omap_dss_device *ldev = list_entry(cur,
+struct omap_dss_device,
+panel_list);
+   if (strcmp(ldev->alias, dssdev->alias) > 0)
+   break;
+   }
+   list_add_tail(&dssdev->panel_list, cur);
mutex_unlock(&panel_list_mutex);
return 0;
 }
-- 
2.7.4

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

[PATCHv2 30/31] drm/omap: fix display SYNC/DE flags

[Tomi Valkeinen]

At the moment VSYNC/HSYNC/DE high/low flags set by the panel/encoder
drivers get lost when the videotimings are translated to DRM's
videomode, as DRM's mode does not have corresponding flags.

DRM has bus-flags for this purpose, and while it lacks a few flags at
the moment, it should be used here. However, until we rewrite omapdrm's
device model, using bus-flags is rather difficult.

As a short term fix, this patch makes sure that every time the videomode
is set in omap_crtc_mode_set_nofb(), the driver asks for the SYNC/DE
flags from the panel/encoder drivers, and thus we get the correct flags
into use.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_connector.c |  2 --
 drivers/gpu/drm/omapdrm/omap_crtc.c  | 28 +---
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c 
b/drivers/gpu/drm/omapdrm/omap_connector.c
index 50d2b641c28b..d62c035f050f 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -146,8 +146,6 @@ static int omap_connector_mode_valid(struct drm_connector 
*connector,
int r, ret = MODE_BAD;
 
drm_display_mode_to_videomode(mode, &vm);
-   vm.flags |= DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
-   DISPLAY_FLAGS_SYNC_NEGEDGE;
mode->vrefresh = drm_mode_vrefresh(mode);
 
/*
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c 
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 1db96b077ae8..606ef807741a 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -373,6 +373,11 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
+   struct omap_drm_private *priv = crtc->dev->dev_private;
+   const u32 flags_mask = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_DE_LOW |
+   DISPLAY_FLAGS_PIXDATA_POSEDGE | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+   DISPLAY_FLAGS_SYNC_POSEDGE | DISPLAY_FLAGS_SYNC_NEGEDGE;
+   int i;
 
DBG("%s: set mode: %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x 0x%x",
omap_crtc->name, mode->base.id, mode->name,
@@ -382,9 +387,26 @@ static void omap_crtc_mode_set_nofb(struct drm_crtc *crtc)
mode->type, mode->flags);
 
drm_display_mode_to_videomode(mode, &omap_crtc->vm);
-   omap_crtc->vm.flags |= DISPLAY_FLAGS_DE_HIGH |
-  DISPLAY_FLAGS_PIXDATA_POSEDGE |
-  DISPLAY_FLAGS_SYNC_NEGEDGE;
+
+   for (i = 0; i < priv->num_encoders; ++i) {
+   struct drm_encoder *encoder = priv->encoders[i];
+
+   if (encoder->crtc == crtc) {
+   struct omap_dss_device *dssdev;
+
+   dssdev = omap_encoder_get_dssdev(encoder);
+
+   if (dssdev) {
+   struct videomode vm = {0};
+
+   dssdev->driver->get_timings(dssdev, &vm);
+
+   omap_crtc->vm.flags |= vm.flags & flags_mask;
+   }
+
+   break;
+   }
+   }
 }
 
 static int omap_crtc_atomic_check(struct drm_crtc *crtc,
-- 
2.7.4

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

[PATCHv2 05/31] drm/omap: improve DPI clock selection on DRA7xx

[Tomi Valkeinen]

The clock source selection for the LCD outputs is too hardcoded at the
moment. For example, LCD3 is set to use PLL2_1, and PLL2 doesn't exist
on DRA72x SoCs.

There are quite many ways to configure the clocks, even using HDMI PLL
for LCD outputs, but enabling full configuration of the clocks is rather
tricky.

This patch improves the situation a bit by checking if the PLL about to
be used exists, and if not, tries another one.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dpi.c | 47 ++-
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c 
b/drivers/gpu/drm/omapdrm/dss/dpi.c
index e0b0c5c24c55..0f32d5d078c6 100644
--- a/drivers/gpu/drm/omapdrm/dss/dpi.c
+++ b/drivers/gpu/drm/omapdrm/dss/dpi.c
@@ -67,6 +67,42 @@ static struct dpi_data *dpi_get_data_from_pdev(struct 
platform_device *pdev)
return dev_get_drvdata(&pdev->dev);
 }
 
+static enum dss_clk_source dpi_get_clk_src_dra7xx(enum omap_channel channel)
+{
+   /*
+* Possible clock sources:
+* LCD1: FCK/PLL1_1/HDMI_PLL
+* LCD2: FCK/PLL1_3/HDMI_PLL (DRA74x: PLL2_3)
+* LCD3: FCK/PLL1_3/HDMI_PLL (DRA74x: PLL2_1)
+*/
+
+   switch (channel) {
+   case OMAP_DSS_CHANNEL_LCD:
+   {
+   if (dss_pll_find_by_src(DSS_CLK_SRC_PLL1_1))
+   return DSS_CLK_SRC_PLL1_1;
+   }
+   case OMAP_DSS_CHANNEL_LCD2:
+   {
+   if (dss_pll_find_by_src(DSS_CLK_SRC_PLL1_3))
+   return DSS_CLK_SRC_PLL1_3;
+   if (dss_pll_find_by_src(DSS_CLK_SRC_PLL2_3))
+   return DSS_CLK_SRC_PLL2_3;
+   }
+   case OMAP_DSS_CHANNEL_LCD3:
+   {
+   if (dss_pll_find_by_src(DSS_CLK_SRC_PLL2_1))
+   return DSS_CLK_SRC_PLL2_1;
+   if (dss_pll_find_by_src(DSS_CLK_SRC_PLL1_3))
+   return DSS_CLK_SRC_PLL1_3;
+   }
+   default:
+   break;
+   }
+
+   return DSS_CLK_SRC_FCK;
+}
+
 static enum dss_clk_source dpi_get_clk_src(enum omap_channel channel)
 {
/*
@@ -107,16 +143,7 @@ static enum dss_clk_source dpi_get_clk_src(enum 
omap_channel channel)
}
 
case OMAPDSS_VER_DRA7xx:
-   switch (channel) {
-   case OMAP_DSS_CHANNEL_LCD:
-   return DSS_CLK_SRC_PLL1_1;
-   case OMAP_DSS_CHANNEL_LCD2:
-   return DSS_CLK_SRC_PLL1_3;
-   case OMAP_DSS_CHANNEL_LCD3:
-   return DSS_CLK_SRC_PLL2_1;
-   default:
-   return DSS_CLK_SRC_FCK;
-   }
+   return dpi_get_clk_src_dra7xx(channel);
 
default:
return DSS_CLK_SRC_FCK;
-- 
2.7.4

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

[PATCHv2 26/31] drm/omap: Create fbdev emulation only for the first DRM connector

[Tomi Valkeinen]

From: Peter Ujfalusi 

Add fbdev emulation only for the first DRM connector.
When the fbdev emulation was created for all connectors with different
resolution, the lower res display would only be able to show part of the
framebuffer.
By creating the fbdev emulation only for the first connector we can avoid
this.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_fbdev.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index 73619e201c0c..58c0c5bccc8c 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -269,7 +269,9 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device 
*dev)
goto fail;
}
 
-   ret = drm_fb_helper_single_add_all_connectors(helper);
+   drm_modeset_lock_all(dev);
+   ret = drm_fb_helper_add_one_connector(helper, priv->connectors[0]);
+   drm_modeset_unlock_all(dev);
if (ret)
goto fini;
 
-- 
2.7.4

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

[PATCHv2 23/31] drm/omap: Use omapdss_stack_is_ready() to check that the display stack is up

[Tomi Valkeinen]

From: Peter Ujfalusi 

Instead of 'guessing' based on aliases of the status of the DSS drivers,
use the new interface to check that all needed drivers are loaded.
In this way we can be sure that all needed drivers are loaded so it is
safe to continue the probing of omapdrm.
This method will allow the omapdrm to be probed 'headless', without
outputs.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index c7dbf30a61fa..ad8d16cf819c 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -250,7 +250,9 @@ static int omap_connect_dssdevs(void)
 {
int r;
struct omap_dss_device *dssdev = NULL;
-   bool no_displays = true;
+
+   if (!omapdss_stack_is_ready())
+   return -EPROBE_DEFER;
 
for_each_dss_dev(dssdev) {
r = dssdev->driver->connect(dssdev);
@@ -260,14 +262,9 @@ static int omap_connect_dssdevs(void)
} else if (r) {
dev_warn(dssdev->dev, "could not connect display: %s\n",
dssdev->name);
-   } else {
-   no_displays = false;
}
}
 
-   if (no_displays)
-   return -EPROBE_DEFER;
-
return 0;
 
 cleanup:
-- 
2.7.4

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

[PATCHv2 09/31] drm/omap: add omapdss-base.ko

[Tomi Valkeinen]

We are working towards enabling omapdss6, which will consists of a new
dss, dispc and dpi drivers. omapdss6 will be a new module. The panel,
encoder and omapdrm will need to use either the current omapdss driver
or the new omapdss6 driver, depending on the platform.

This will be implemented with a common base module and function
pointers.

This patch adds a skeleton omapdss-base.ko module, to which we'll be
moving common dss functionality like registration of the panels.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/Kconfig  | 4 
 drivers/gpu/drm/omapdrm/dss/Makefile | 4 
 drivers/gpu/drm/omapdrm/dss/base.c   | 6 ++
 3 files changed, 14 insertions(+)
 create mode 100644 drivers/gpu/drm/omapdrm/dss/base.c

diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig 
b/drivers/gpu/drm/omapdrm/dss/Kconfig
index d1fa730c7d54..f53adb944a0d 100644
--- a/drivers/gpu/drm/omapdrm/dss/Kconfig
+++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
@@ -1,8 +1,12 @@
 config OMAP2_DSS_INIT
bool
 
+config OMAP_DSS_BASE
+   tristate
+
 menuconfig OMAP2_DSS
 tristate "OMAP2+ Display Subsystem support"
+   select OMAP_DSS_BASE
select VIDEOMODE_HELPERS
select OMAP2_DSS_INIT
select HDMI
diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile 
b/drivers/gpu/drm/omapdrm/dss/Makefile
index b651ec9751e6..c7d070168152 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -1,4 +1,8 @@
 obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
+
+obj-$(CONFIG_OMAP_DSS_BASE) += omapdss-base.o
+omapdss-base-y := base.o
+
 obj-$(CONFIG_OMAP2_DSS) += omapdss.o
 # Core DSS files
 omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
diff --git a/drivers/gpu/drm/omapdrm/dss/base.c 
b/drivers/gpu/drm/omapdrm/dss/base.c
new file mode 100644
index ..943030a7523c
--- /dev/null
+++ b/drivers/gpu/drm/omapdrm/dss/base.c
@@ -0,0 +1,6 @@
+#include 
+#include 
+
+MODULE_AUTHOR("Tomi Valkeinen ");
+MODULE_DESCRIPTION("OMAP Display Subsystem Base");
+MODULE_LICENSE("GPL v2");
-- 
2.7.4

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

[PATCHv2 28/31] drm/omap: displays: panel-dpi: Support for handling backlight devices

[Tomi Valkeinen]

From: Peter Ujfalusi 

The associated backlight device can be configured via DT by providing the
phandle to the device.

If the backlight device is configured, the driver can manage the backligt
along with the panel's power state, iow it can turn on the backlight when
the panel is enabled and turn it off when the panel is disabled.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 37 ++--
 1 file changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index 38003208d9ca..51fc78eb212c 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -30,6 +31,8 @@ struct panel_drv_data {
 
struct videomode vm;
 
+   struct backlight_device *backlight;
+
/* used for non-DT boot, to be removed */
int backlight_gpio;
 
@@ -97,6 +100,11 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (gpio_is_valid(ddata->backlight_gpio))
gpio_set_value_cansleep(ddata->backlight_gpio, 1);
 
+   if (ddata->backlight) {
+   ddata->backlight->props.power = FB_BLANK_UNBLANK;
+   backlight_update_status(ddata->backlight);
+   }
+
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
 
return 0;
@@ -113,6 +121,11 @@ static void panel_dpi_disable(struct omap_dss_device 
*dssdev)
if (gpio_is_valid(ddata->backlight_gpio))
gpio_set_value_cansleep(ddata->backlight_gpio, 0);
 
+   if (ddata->backlight) {
+   ddata->backlight->props.power = FB_BLANK_POWERDOWN;
+   backlight_update_status(ddata->backlight);
+   }
+
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
regulator_disable(ddata->vcc_supply);
 
@@ -209,6 +222,7 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
 {
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev->dev.of_node;
+   struct device_node *bl_node;
struct omap_dss_device *in;
int r;
struct display_timing timing;
@@ -236,10 +250,19 @@ static int panel_dpi_probe_of(struct platform_device 
*pdev)
 
ddata->backlight_gpio = -ENOENT;
 
+   bl_node = of_parse_phandle(node, "backlight", 0);
+   if (bl_node) {
+   ddata->backlight = of_find_backlight_by_node(bl_node);
+   of_node_put(bl_node);
+
+   if (!ddata->backlight)
+   return -EPROBE_DEFER;
+   }
+
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
dev_err(&pdev->dev, "failed to get video timing\n");
-   return r;
+   goto free_backlight;
}
 
videomode_from_timing(&timing, &ddata->vm);
@@ -247,12 +270,19 @@ static int panel_dpi_probe_of(struct platform_device 
*pdev)
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(&pdev->dev, "failed to find video source\n");
-   return PTR_ERR(in);
+   r = PTR_ERR(in);
+   goto free_backlight;
}
 
ddata->in = in;
 
return 0;
+
+free_backlight:
+   if (ddata->backlight)
+   put_device(&ddata->backlight->dev);
+
+   return r;
 }
 
 static int panel_dpi_probe(struct platform_device *pdev)
@@ -321,6 +351,9 @@ static int __exit panel_dpi_remove(struct platform_device 
*pdev)
 
omap_dss_put_device(in);
 
+   if (ddata->backlight)
+   put_device(&ddata->backlight->dev);
+
return 0;
 }
 
-- 
2.7.4

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

[PATCHv2 13/31] drm/omap: move display, dss-of, output to omapdss-base

[Tomi Valkeinen]

This patch moves the common parts of omapdss to omapdss-base so that
both the current omapdss driver and the new omapdss6 driver can use
them.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/Makefile  | 6 +++---
 drivers/gpu/drm/omapdrm/dss/display.c | 2 --
 drivers/gpu/drm/omapdrm/dss/dss-of.c  | 3 ++-
 drivers/gpu/drm/omapdrm/dss/dss.h | 4 
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +++
 drivers/gpu/drm/omapdrm/dss/output.c  | 1 -
 6 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile 
b/drivers/gpu/drm/omapdrm/dss/Makefile
index c7d070168152..75ec30f231c7 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -1,12 +1,12 @@
 obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
 
 obj-$(CONFIG_OMAP_DSS_BASE) += omapdss-base.o
-omapdss-base-y := base.o
+omapdss-base-y := base.o display.o dss-of.o output.o
 
 obj-$(CONFIG_OMAP2_DSS) += omapdss.o
 # Core DSS files
-omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
-   output.o dss-of.o pll.o video-pll.o
+omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o \
+   pll.o video-pll.o
 omapdss-$(CONFIG_OMAP2_DSS_DPI) += dpi.o
 omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
 omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index 333ba284ef6d..e567ff68b216 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -29,8 +29,6 @@
 #include 
 
 #include "omapdss.h"
-#include "dss.h"
-#include "dss_features.h"
 
 void omapdss_default_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index dfd4e9621e3b..b46606b0f014 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -19,7 +19,6 @@
 #include 
 
 #include "omapdss.h"
-#include "dss.h"
 
 struct device_node *
 omapdss_of_get_next_port(const struct device_node *parent,
@@ -110,6 +109,7 @@ struct device_node *dss_of_port_get_parent_device(struct 
device_node *port)
 
return NULL;
 }
+EXPORT_SYMBOL_GPL(dss_of_port_get_parent_device);
 
 u32 dss_of_port_get_port_number(struct device_node *port)
 {
@@ -122,6 +122,7 @@ u32 dss_of_port_get_port_number(struct device_node *port)
 
return reg;
 }
+EXPORT_SYMBOL_GPL(dss_of_port_get_port_number);
 
 static struct device_node *omapdss_of_get_remote_port(const struct device_node 
*node)
 {
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h 
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 4d568ac76826..b0551f0090b4 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -253,10 +253,6 @@ struct dss_pll *dss_video_pll_init(struct platform_device 
*pdev, int id,
struct regulator *regulator);
 void dss_video_pll_uninit(struct dss_pll *pll);
 
-/* dss-of */
-struct device_node *dss_of_port_get_parent_device(struct device_node *port);
-u32 dss_of_port_get_port_number(struct device_node *port);
-
 #if defined(CONFIG_OMAP2_DSS_DEBUGFS)
 void dss_debug_dump_clocks(struct seq_file *s);
 #endif
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index b644b12345c3..dab367ae5ca1 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -846,6 +846,9 @@ omapdss_of_find_source_for_first_ep(struct device_node 
*node);
 
 void omapdss_set_is_initialized(bool set);
 
+struct device_node *dss_of_port_get_parent_device(struct device_node *port);
+u32 dss_of_port_get_port_number(struct device_node *port);
+
 u32 dispc_read_irqstatus(void);
 void dispc_clear_irqstatus(u32 mask);
 u32 dispc_read_irqenable(void);
diff --git a/drivers/gpu/drm/omapdrm/dss/output.c 
b/drivers/gpu/drm/omapdrm/dss/output.c
index 0858958677a1..2b999dc48621 100644
--- a/drivers/gpu/drm/omapdrm/dss/output.c
+++ b/drivers/gpu/drm/omapdrm/dss/output.c
@@ -22,7 +22,6 @@
 #include 
 
 #include "omapdss.h"
-#include "dss.h"
 
 static LIST_HEAD(output_list);
 static DEFINE_MUTEX(output_lock);
-- 
2.7.4

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

[PATCHv2 08/31] drm/omap: fix HDMI sync polarities

[Tomi Valkeinen]

While implementing writeback support, odd behavior of WBDELAYCOUNT was
observed with the combination of WB capture and HDMI. The result of the
debugging was that the HDMI sync polarities are not set correctly.

The current code sets the sync polarities going from HDMI WP to DISPC
according to the video mode used, which seems to work normally fine, but
causes problems with WB as WB expects the syncs to be active-high.

This patch changes the HDMI sync polarities so that the DISPC always
gets active-high syncs from HDMI WP, and the HDMI core gets sync
polarities according to the used video mode.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/hdmi_wp.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
index b783d5a0750e..597ec9d87d1d 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi_wp.c
@@ -147,15 +147,17 @@ void hdmi_wp_video_config_interface(struct hdmi_wp_data 
*wp,
struct videomode *vm)
 {
u32 r;
-   bool vsync_pol, hsync_pol;
+   bool vsync_inv, hsync_inv;
DSSDBG("Enter hdmi_wp_video_config_interface\n");
 
-   vsync_pol = !!(vm->flags & DISPLAY_FLAGS_VSYNC_HIGH);
-   hsync_pol = !!(vm->flags & DISPLAY_FLAGS_HSYNC_HIGH);
+   vsync_inv = !!(vm->flags & DISPLAY_FLAGS_VSYNC_LOW);
+   hsync_inv = !!(vm->flags & DISPLAY_FLAGS_HSYNC_LOW);
 
r = hdmi_read_reg(wp->base, HDMI_WP_VIDEO_CFG);
-   r = FLD_MOD(r, vsync_pol, 7, 7);
-   r = FLD_MOD(r, hsync_pol, 6, 6);
+   r = FLD_MOD(r, 1, 7, 7);/* VSYNC_POL to dispc active high */
+   r = FLD_MOD(r, 1, 6, 6);/* HSYNC_POL to dispc active high */
+   r = FLD_MOD(r, vsync_inv, 5, 5);/* CORE_VSYNC_INV */
+   r = FLD_MOD(r, hsync_inv, 4, 4);/* CORE_HSYNC_INV */
r = FLD_MOD(r, !!(vm->flags & DISPLAY_FLAGS_INTERLACED), 3, 3);
r = FLD_MOD(r, 1, 1, 0); /* HDMI_TIMING_MASTER_24BIT */
hdmi_write_reg(wp->base, HDMI_WP_VIDEO_CFG, r);
-- 
2.7.4

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

[PATCHv2 20/31] drm/omap: fix replication logic

[Tomi Valkeinen]

DSS uses "replication logic" to convert color components from smaller
bit widths to bigger bit widths. Without replication logic, the color
component would be shifted and the least significant bits would be left
at 0, whereas with replication logic, the least significat bits will be
filled with the most significant bit.

For some reason omapdrm leaves replication logic always to off, which,
in the most common case, means that showing 16-bit RGB colors on 24-bit
display gives a bit darker colors than expected.

The reset value of the replication logic bit is enabled, and it should
always be set, as there's no practical reason to disable it. This patch
removes the option to disable it from omapdrm, and always sets it to
enabled in dispc.

Signed-off-by: Tomi Valkeinen 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c   | 7 ---
 drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +--
 drivers/gpu/drm/omapdrm/omap_plane.c  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index e9d98046a97f..83241052df6b 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -2823,11 +2823,12 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
 }
 
 static int dispc_ovl_setup(enum omap_plane plane, const struct 
omap_overlay_info *oi,
-   bool replication, const struct videomode *vm, bool mem_to_mem)
+   const struct videomode *vm, bool mem_to_mem)
 {
int r;
enum omap_overlay_caps caps = dss_feat_get_overlay_caps(plane);
enum omap_channel channel;
+   const bool replication = true;
 
channel = dispc_ovl_get_channel_out(plane);
 
@@ -2854,7 +2855,7 @@ int dispc_wb_setup(const struct omap_dss_writeback_info 
*wi,
enum omap_plane plane = OMAP_DSS_WB;
const int pos_x = 0, pos_y = 0;
const u8 zorder = 0, global_alpha = 0;
-   const bool replication = false;
+   const bool replication = true;
bool truncation;
int in_width = vm->hactive;
int in_height = vm->vactive;
@@ -4288,7 +4289,7 @@ static void dispc_errata_i734_wa(void)
 
/* Setup and enable GFX plane */
dispc_ovl_set_channel_out(OMAP_DSS_GFX, OMAP_DSS_CHANNEL_LCD);
-   dispc_ovl_setup(OMAP_DSS_GFX, &ovli, false, &i734.vm, false);
+   dispc_ovl_setup(OMAP_DSS_GFX, &ovli, &i734.vm, false);
dispc_ovl_enable(OMAP_DSS_GFX, true);
 
/* Set up and enable display manager for LCD1 */
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h 
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 3e61f4b2d1ce..4545f1824e66 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -928,8 +928,7 @@ struct dispc_ops {
void (*ovl_set_channel_out)(enum omap_plane plane,
enum omap_channel channel);
int (*ovl_setup)(enum omap_plane plane, const struct omap_overlay_info 
*oi,
-   bool replication, const struct videomode *vm,
-   bool mem_to_mem);
+   const struct videomode *vm, bool mem_to_mem);
 
enum omap_color_mode (*ovl_get_color_modes)(enum omap_plane plane);
 };
diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index bdd74692e0cd..78a92422ede1 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -128,7 +128,7 @@ static void omap_plane_atomic_update(struct drm_plane 
*plane,
  omap_crtc_channel(state->crtc));
 
/* and finally, update omapdss: */
-   ret = priv->dispc_ops->ovl_setup(omap_plane->id, &info, false,
+   ret = priv->dispc_ops->ovl_setup(omap_plane->id, &info,
  omap_crtc_timings(state->crtc), false);
if (ret) {
dev_err(plane->dev->dev, "Failed to setup plane %s\n",
-- 
2.7.4

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