[PATCH v5 0/3] RFC: Secure Memory Allocation Framework
On Wed, 21 Oct 2015, Benjamin Gaignard wrote: > > The outcome of the previous RFC about how do secure data path was the need > of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551) > Have you addressed all the questions raised by Alan here: https://lkml.org/lkml/2015/5/8/629 Also, is there any application of this beyond DRM? - James -- James Morris
[PATCH v5 1/3] create SMAF module
On Wed, 21 Oct 2015, Benjamin Gaignard wrote: > Secure Memory Allocation Framework goal is to be able > to allocate memory that can be securing. > There is so much ways to allocate and securing memory that SMAF > doesn't do it by itself but need help of additional modules. > To be sure to use the correct allocation method SMAF implement > deferred allocation (i.e. allocate memory when only really needed) > > Allocation modules (smaf-alloctor.h): > SMAF could manage with multiple allocation modules at same time. > To select the good one SMAF call match() to be sure that a module > can allocate memory for a given list of devices. It is to the module > to check if the devices are compatible or not with it allocation > method. > > Securing module (smaf-secure.h): > The way of how securing memory it is done is platform specific. > Secure module is responsible of grant/revoke memory access. > This documentation is highly inadequate. What does "allocate memory that can be securing" mean? -- James Morris
[PATCH] drm/gem: Remove unused variable
Remove an unused variable that generates a compilation warning
introduced in commit 4e270f088011 ("drm/gem: Drop struct_mutex
requirement from drm_gem_mmap_obj").
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_gem_cma_helper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 4fb4c45d039f..e109b49cd25d 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -481,7 +481,6 @@ int drm_gem_cma_prime_mmap(struct drm_gem_object *obj,
struct vm_area_struct *vma)
{
struct drm_gem_cma_object *cma_obj;
- struct drm_device *dev = obj->dev;
int ret;
ret = drm_gem_mmap_obj(obj, obj->size, vma);
--
2.4.10
[Bug 91993] Graphical glitch in Astromenace (open-source game).
https://bugs.freedesktop.org/show_bug.cgi?id=91993 --- Comment #20 from Roland Scheidegger --- (In reply to Nicolai Hähnle from comment #16) > (Old versions of) AstroMenace use glTexStorage2D to create a texture with an > incomplete mipmap pyramid (the 1x1 level is missing). This pyramid is not > honored by the state tracker's implementation of glGenerateMipmap, which > results in various broken textures. Hmm I totally missed this when I fixed pretty much the same bug in mesa core mipgen code. I guess it's a real pity there's no piglit test for this... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/65893220/attachment.html>
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #31 from Barto --- llvm developper ( Craig Topper ) has answered this : https://llvm.org/bugs/show_bug.cgi?id=25021#c8 he said that the remove of the SSE4 test for penryn CPUs ( including pentium dual core who don't support SSE4 ) was intentional, he advices mesa developpers to use the llvm function "getHostCPUFeatures()" in order to check if the CPU can support SSE4, before doing a llvm operation ( like a binary code generation ), I check in mesa source code and it seems that mesa developpers don't use this function "getHostCPUFeatures()", I am not a specialist in llvm API, but it seems that there is a change since llvm 3.7.0, developpers like mesa should now always check if the host CPU has some features like SSE4, because without no check llvm will try to apply generic CPU settings fixed in the file /lib/Target/X86.td, in this file there are a sort of definitions of features for each CPU : / Intel Core 2 Solo/Duo. def : ProcessorModel<"core2", SandyBridgeModel, [FeatureSSSE3, FeatureCMPXCHG16B, FeatureSlowBTMem]>; def : ProcessorModel<"penryn", SandyBridgeModel, [FeatureSSE41, FeatureCMPXCHG16B, FeatureSlowBTMem]>; we see here that by default all penryn CPU are treated by llvm as "SSE4 ready", which triggers a bug with pentium dual core ( cpu family 6 model 23 ) if no sanity checks ( like SSE4 test ) have been done by the application who uses llvm libs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/bee338ff/attachment.html>
[GIT PULL] On-demand device probing
On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki > wrote: > > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote: > >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki > >> wrote: > >> > ACPI uses platform devices too. In fact, ACPI device objects are > >> > enumerated as > >> > platform devices by default now. > >> > >> Okay, I should have grepped for that: > >> drivers/base/platform.c:ACPI_COMPANION_SET(&pdev->dev, > >> NULL); > >> drivers/base/platform.c:len = acpi_device_modalias(dev, buf, > >> PAGE_SIZE -1); > >> drivers/base/platform.c:rc = acpi_device_uevent_modalias(dev, env); > >> drivers/base/platform.c:/* Then try ACPI style match */ > >> drivers/base/platform.c:if (acpi_driver_match_device(dev, drv)) > >> > >> These are all cases which have DT version as well, so we're not really > >> all that different here. There's a few more for DT, but that probably > >> means you have just not hit the problems we have yet. For example, > >> what happens if you have an interrupt line in which the controller is > >> probed after the device connected to the interrupt line? That required > >> resolving irqs in platform_get_irq rather than using static resources > >> to support deferred probe. > > > > We don't have this particular problem, because the IRQ controllers are > > enumerated in a special way. > > What does "in a special way" mean? Can you please be more specific? > > Can you have interrupt controllers that depend on clocks, pin controllers, > and PM domains? Currently, there's no native way to represent those dependencies in ACPI. Thanks, Rafael
[GIT PULL] On-demand device probing
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: > On 20 October 2015 at 18:04, Alan Stern wrote: > > On Tue, 20 Oct 2015, Mark Brown wrote: > > > >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: > >> > >> > Furthermore, that applies only to devices that use synchronous suspend. > >> > Async suspend is becoming common, and there the only restrictions are > >> > parent-child relations plus whatever explicit requirements that drivers > >> > impose by calling device_pm_wait_for_dev(). > >> > >> Hrm, this is the first I'd noticed that feature though I see the initial > >> commit dates from January. > > > > Async suspend and device_pm_wait_for_dev() were added in January 2010, > > not 2015! > > > >> It looks like most of the users are PCs at > >> the minute but we should be using it more widely for embedded things, > >> there's definitely some cases I'm aware of where it will allow us to > >> remove some open coding. > >> > >> It does seem like we want to be feeding dependency information we > >> discover for probing way into the suspend dependencies... > > > > Rafael has been thinking about a way to do this systematically. > > Nothing concrete has emerged yet. > > This iteration of the series would make this quite easy, as > dependencies are calculated before probes are attempted: > > https://lkml.org/lkml/2015/6/17/311 Well, if you know how to represent "links" between devices, the mechanism introduced here doesn't really add much value, because in that case the core knows what the dependencies are in the first place and can only defer the probes that have to be deferred. Thanks, Rafael
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #32 from Roland Scheidegger --- (In reply to Barto from comment #31) > llvm developper ( Craig Topper ) has answered this : > > https://llvm.org/bugs/show_bug.cgi?id=25021#c8 > > he said that the remove of the SSE4 test for penryn CPUs ( including pentium > dual core who don't support SSE4 ) was intentional, > > he advices mesa developpers to use the llvm function "getHostCPUFeatures()" > in order to check if the CPU can support SSE4, before doing a llvm operation > ( like a binary code generation ), > > I check in mesa source code and it seems that mesa developpers don't use > this function "getHostCPUFeatures()", We do our own feature detection, though so far we didn't really tell llvm which features it's allowed to use as we were relying on this getting detected automatically. I believe the patch posted by Jose here, http://lists.freedesktop.org/archives/mesa-dev/2015-October/097948.html should help. (Though this bug appears to have nothing to do at all with the originally posted issue) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/01648dbc/attachment-0001.html>
[git pull] drm fixes
Hi Linus, been a bit slow gathering these, drm/mst: one mutex leak in a fail path radeon: two oops fixes, one dpm fix i915: one messy set of fixes, where we revert the original fix, and pull back the proper set of fixes from -next on top. nouveau: one fix for an illegal buffer placement. Doesn't look too bad, hopefully shouldn't be too much more. Dave. The following changes since commit 1099f86044111e9a7807f09523e42d4c9d0fb781: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-10-19 09:55:40 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to c50f13f911b90a722308bffbf26187ff3890aa1e: Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2015-10-22 10:24:55 +1000) Adam Richter (1): drm: fix mutex leak in drm_dp_get_mst_branch_device Alex Deucher (3): drm/radeon/dpm: don't add pwm attributes if DPM is disabled drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled drm/amdgpu: add missing dpm check for KV dpm late init Chris Wilson (2): drm/i915: Flush pipecontrol post-sync writes drm/i915: Deny wrapping an userptr into a framebuffer Daniel Vetter (1): drm/i915: Fix kerneldoc for i915_gem_shrink_all Dave Airlie (3): Merge branch 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6 into drm-fixes Merge tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel into drm-fixes Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Ilia Mirkin (1): drm/nouveau/gem: return only valid domain when there's only one Jani Nikula (1): Revert "drm/i915: Add primary plane to mask if it's visible" Maarten Lankhorst (1): drm/i915: Add primary plane to mask if it's visible Ville Syrjälä (4): drm/i915: Restore lost DPLL register write on gen2-4 drm/i915: Enable DPLL VGA mode before P1/P2 divider write drm/i915: Assign hwmode after encoder state readout drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc() drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 8 ++- drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 3 + drivers/gpu/drm/drm_dp_mst_topology.c| 7 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 5 +- drivers/gpu/drm/i915/intel_display.c | 120 +-- drivers/gpu/drm/i915/intel_lrc.c | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 2 + drivers/gpu/drm/nouveau/nouveau_gem.c| 5 +- drivers/gpu/drm/radeon/radeon_pm.c | 8 ++- 10 files changed, 97 insertions(+), 64 deletions(-)
[Bug 104791] ACPI errors on Lenovo C50-30 (AE_AML_INFINITE_LOOP, argument type mismatch)
https://bugzilla.kernel.org/show_bug.cgi?id=104791 Aaron Lu changed: What|Removed |Added Component|ACPICA-Core |Video(DRI - non Intel) Assignee|lv.zheng at intel.com |drivers_video-dri at kernel-bu ||gs.osdl.org Product|ACPI|Drivers --- Comment #5 from Aaron Lu --- Moving to GPU for nouveau people to take a look. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH RFCv2 0/4] Etnaviv DRM driver again
On Wed, Oct 21, 2015 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> On Tue, Oct 20, 2015 at 11:36:27AM +0200, Daniel Vetter wrote:
> > On Fri, Sep 11, 2015 at 04:10:10PM +0200, Lucas Stach wrote:
> > > Hey all,
> > >
> > > this is a new posting of the Etnaviv DRM driver for Vivante embedded GPUs.
> > > This time I've squashed all patches to the DRM driver itself into a
> > > single commit
> > > to make it easier for people to look at and review this stuff.
> > >
> > > Aside from squashing of some of the trivial bugfixes I intend to keep all
> > > the
> > > individual commits around to retain the authorship of people working on
> > > this
> > > driver. If you want to look at the stream of commits please fetch
> > >
> > > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream
> >
> > Finally unlazied and looked at this, assuming it's v2. Piles of comments:
> >
> > - Please don't use dev->struct_mutex in new driver code. With latest
> > linux-next there's no reason at all for driver's to use it, and doing so
> > will massively encumber your driver with everything else.
> >
> > There's a bit a trick involved since as-is struct_mutex allows you to do
> > horrible leaky locking designs around gem_free_object. On a quick look
> > to fix this you probably need a mutex for the drm_mm and various lists,
> > plus per object reservations. Tricky part is the eviction logic in
> > etnaviv_iommu_map_gem, where you need to trylock eviction candidates. If
> > you can't lock them you can't evict them anyway, so no harm done.
> >
> > If that's too much just replace it with your own lock and trylock in
> > gem_free_object, punting to a worker if that fails (ttm has a
> > deferred_free list for that, protected by a spinlock).
> >
> > - ->load and ->unload are deprecated hooks becaus fundamentally racy (and
> > we can't fix it since it would break dri 1 crap). Please use instead:
> >
> > drm_dev_alloc();
> > /* load code */
> > drm_dev_register();
> >
> > and
> >
> > drm_dev_unregister();
> > /* unload code */
> > drm_dev_unref();
> >
> > Laurent just sent a nice patch for rcar to do that conversion. That will
> > also get rid of the deprecated drm_platform_init and drm_dev_put.
> >
> > - check pad for 0 in gem_info ioctl.
>
> My tree already does this, and afaik it was part of Christian's patches.
> I'm not sure whether Lucas' patches are missing something.
>
> +static int etnaviv_ioctl_gem_info(struct drm_device *dev, void *data,
> + struct drm_file *file)
> +{
> + struct drm_etnaviv_gem_info *args = data;
> + struct drm_gem_object *obj;
> + int ret = 0;
> +
> + if (args->pad)
> + return -EINVAL;
>
> Did you miss it?
That wasn't there, I guess I looked at an outdated tree :()
>
> > - the flags check for gem_new seems leaky since you only check for flags &
> > ETNA_BO_CACHE_MASK.
>
> Fixed in etnaviv_ioctl_gem_new().
>
> > - similar input validation issue for op in gem_cpu_prep
>
> Fixed in etnaviv_ioctl_gem_cpu_prep().
>
> > - maybe add a flags/op to future-proof gem_cpu_fini just in case? Might be
> > useful to optimize cache flushing.
>
> Having just merged Lucas' patch, which carries the op from gem_cpu_prep()
> over to gem_cpu_fini(), I'm wondering if this is hiding a potential
> problem - what if two threads call gem_cpu_prep() but with different 'op'
> arguments. Seems rather fragile, as 'etnaviv_obj->last_cpu_prep_op'
> becomes rather indeterminant.
Hm, dropping last_cpu_prep_op and adding it to the fini ioctl might be an
option. But I have no idea whether the dma api likes that really. Wrt
safety I don't think there's a concern here - if userspace decides to be
buggy wrt coherency tracking it'll get all the pieces.
> > - the naming in gem_submit_reloc confuses me a bit, but that's just a
> > bikeshed ;-)
> >
> > - gem_submit seems to miss a flag, ime definitely needed (just to be able
> > to extend to future hw iterations)
>
> Grumble, another API revision I'll need to maintain in the DDX driver.
> (Even though this isn't in mainline, I'm already up to three different
> kernel APIs for etnadrm.) If we do this, I'll want to lump it together
> with other API changes (like the one below for flags) so I'll wait until
> we've got an answer to the gem_wait_fence question.
>
> > - gem_submit->exec_state doesn't seem to be validated (it's just an if
> > (exec_state == 2D) ... else ... in cmd_select_pipe)
>
> Fixed.
>
> > - all the array allocations aren't checked for integer overflows in
> > gem_submit. Just use kmalloc_array or similar to get this right. That
> > means you need to allocations in submit_create, but imo better safe than
> > security-buggy. Similar problem in submit_reloc, but there
> > copy_from_user will protect you since you only copy individual structs.
> > Still a bit fragile.
>
> I'm not sure kmalloc_array() is the right answer
[alsa-devel] HDMI codec, way forward?
On Wed, Oct 21, 2015 at 10:04:15PM +0100, Russell King - ARM Linux wrote: > On Wed, Oct 21, 2015 at 10:37:27PM +0200, Takashi Iwai wrote: > > On Wed, 21 Oct 2015 20:19:38 +0200, > > Russell King - ARM Linux wrote: > > > > > > On Wed, Oct 21, 2015 at 07:59:06PM +0200, Takashi Iwai wrote: > > > > On Wed, 21 Oct 2015 19:34:37 +0200, > > > > Russell King - ARM Linux wrote: > > > > > > > > > > On Wed, Oct 21, 2015 at 09:49:28PM +0530, Vinod Koul wrote: > > > > > > On Wed, Oct 21, 2015 at 03:37:47PM +0100, Russell King - ARM Linux > > > > > > wrote: > > > > > > > In any case, this doesn't (and can't) solve the CEC problem, so > > > > > > > it's not > > > > > > > a solution to the problem at hand. > > > > > > > > > > > > Sorry am not sure I follow the reasons for that, wouldn't CEC be > > > > > > another > > > > > > slave in such an interface? I though component fwk did allow us to > > > > > > have > > > > > > multiple slaves.. > > > > > > > > > > Not with the way you're using the component helper here. > > > > > > > > > > I guess that not all my message is being read, because people keep > > > > > replying half-way down my messages... > > > > > > > > > > You can only register a struct device _once_ as a slave device. > > > > > > > > > > With the way you're using it here for audio, you're registering the > > > > > i915 DRM device as a slave component device, and the audio side as > > > > > the master. That means the audio master can bind to the DRM slave > > > > > component device. > > > > > > > > > > You can't then have a CEC master bind to the i915 DRM slave device > > > > > (it's already bound to the audio master device), and you can't > > > > > register the i915 DRM device as a second slave component device. > > > > > It becomes indistinguishable from the first, and there's no way > > > > > to tell which of the two different 'ops' structures should be used > > > > > with which master. > > > > > > > > > > I said this in my message 20151021140307.GE32532 at > > > > > n2100.arm.linux.org.uk > > > > > which was two of my replies ago in this sub-thread. > > > > > > > > Can't the limitation of single slave dev be extended simply? e.g. add > > > > some matching semantics to component_master_add_child() like a shared > > > > key in both master and slave, and let assign only the matched slave. > > > > > > I've already explained that in the email message I referred to by > > > message ID above (which was a reply to one of your previous messages) > > > > > > This is why I find email such a poor communication medium - I'm quite > > > sure most people only read half an email message before hitting reply, > > > and then they stick their reply after where they stopped reading and > > > never bother reading the rest of the message. Normally, at this point, > > > I'll start getting grumpy and sending frustrated emails... which would > > > eventually deride into flames, but let's _try_ to keep this civil. > > > > Thank you for patience! > > > > > Here's the relevant paragraph from the above referenced message, and > > > to make the appropriate bit stand out, I've underlined it with ^. > > > > > > > However, there's a lurking problem: you can't register the same struct > > > > device as a slave more than once into the component helpers - that's > > > > because it's designed to look for devices. There's intentionally no > > > > > > > linkage between the slave ops and master ops to allow for generic > > > ^ > > > > slave drivers (like tda998x) to be used with different master drivers > > > ^ > > > > (armada, tilcdc, etc). In theory, you can register the master device > > > ^ > > > > of one componentised system as a slave device of another, but that > > > > requires a much more complicated locking setup in component.c (I have > > > > patches for that, but I've resisted sending them because it makes the > > > > locking very messy.) > > > > > > In a subsequent sentence, I also address the issue that would occur > > > if any of the already componentised DRM drivers were to attempt what > > > you're doing in i915 - although I say it's solvable, I've resisted > > > that because it makes the locking in there _much_ more hairy, and I'm > > > now not certain that my more complex locking implementation would > > > even cope with that scenario. > > > > I understood that the original component design wasn't for cross > > subsystems. OTOH I wondered why it can't be extended for wider use -- > > that was the simple question; I haven't seen so complex locking in > > some upstream drm drivers code through a quick glance, so the mess > > about locking you mentioned wasn't clear to me. Now point taken. > > You can find my patch for the "more complex locking" problem at the > end of this mail.
[Intel-gfx] [PATCH v7 11/25] drm/i915: Register color correction capabilities
On Wed, Oct 21, 2015 at 11:19:10PM +, Bish, Jim wrote:
> On Tue, 2015-10-20 at 18:04 +0530, Shashank Sharma wrote:
> > From DRM color management:
> >
> > DRM color manager supports these color properties:
> > 1. "ctm": Color transformation matrix property, where a
> >color transformation matrix of 9 correction values gets
> >applied as correction.
> > 2. "palette_before_ctm": for corrections which get applied
> >beore color transformation matrix correction.
> > 3. "palette_after_ctm": for corrections which get applied
> >after color transformation matrix correction.
> >
> > These color correction capabilities may differ per platform,
> > supporting
> > various different no. of correction coefficients. So DRM color
> > manager
> > support few properties using which a user space can query the
> > platform's
> > capability, and prepare color correction accordingly.
> > These query properties are:
> > 1. cm_coeff_after_ctm_property
> > 2. cm_coeff_before_ctm_property
> > (CTM is fix to 9 coefficients across industry)
> >
> > Now, Intel color manager registers:
> > ==
> > 1. Gamma correction property as "palette_after_ctm" property
> > 2. Degamma correction capability as "palette_bafore_ctm" property
> >capability as "palette_after_ctm" DRM color property hook.
> > 3. CSC as "ctm" property.
> >
> > So finally, This patch does the following:
> > 1. Add a function which loads the platform's color correction
> >capabilities in the cm_crtc_palette_capabilities_property
> > structure.
> > 2. Attaches the cm_crtc_palette_capabilities_property to every CRTC
> >getting initiaized.
> > 3. Adds two new parameters "num_samples_after_ctm" and
> >"num_samples_before_ctm" in intel_device_info as gamma and
> >degamma coefficients vary per platform basis.
> >
> > Signed-off-by: Shashank Sharma
> > Signed-off-by: Kausal Malladi
> > ---
> > drivers/gpu/drm/i915/i915_drv.h| 2 ++
> > drivers/gpu/drm/i915/intel_color_manager.c | 31
> > ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8afda45..613bee2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -789,6 +789,8 @@ struct intel_device_info {
> > u8 num_sprites[I915_MAX_PIPES];
> > u8 gen;
> > u8 ring_mask; /* Rings supported by the HW */
> > + u16 num_samples_after_ctm;
> > + u16 num_samples_before_ctm;
> thought we agreed last week that num_samples was going to be
> removed. May be ok to handle in a later patch unless
> someone has strong objection.
That's another num_samples. The discussion was about the userspace abi on
in include/uapi.
-Daniel
>
> Jim
> > DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> > /* Register offsets for the various display pipes and transcoders
> > */
> > int pipe_offsets[I915_MAX_TRANSCODERS];
> > diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> > b/drivers/gpu/drm/i915/intel_color_manager.c
> > index b03ee94..334bfff 100644
> > --- a/drivers/gpu/drm/i915/intel_color_manager.c
> > +++ b/drivers/gpu/drm/i915/intel_color_manager.c
> > @@ -30,4 +30,35 @@
> > void intel_attach_color_properties_to_crtc(struct drm_device *dev,
> > struct drm_crtc *crtc)
> > {
> > + struct drm_mode_config *config = &dev->mode_config;
> > + struct drm_mode_object *mode_obj = &crtc->base;
> > +
> > + /*
> > + * Register:
> > + * =
> > + * Gamma correction as palette_after_ctm property
> > + * Degamma correction as palette_before_ctm property
> > + *
> > + * Load:
> > + * =
> > + * no. of coefficients supported on this platform for gamma
> > + * and degamma with the query properties. A user
> > + * space agent should read these query property, and prepare
> > + * the color correction values accordingly. Its expected from the
> > + * driver to load the right number of coefficients during the init
> > + * phase.
> > + */
> > + if (config->cm_coeff_after_ctm_property) {
> > + drm_object_attach_property(mode_obj,
> > + config->cm_coeff_after_ctm_property,
> > + INTEL_INFO(dev)->num_samples_after_ctm);
> > + DRM_DEBUG_DRIVER("Gamma query property initialized\n");
> > + }
> > +
> > + if (config->cm_coeff_before_ctm_property) {
> > + drm_object_attach_property(mode_obj,
> > + config->cm_coeff_before_ctm_property,
> > + INTEL_INFO(dev)->num_samples_before_ctm);
> > + DRM_DEBUG_DRIVER("Degamma query property initialized\n");
> > + }
> > }
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-
[Intel-gfx] [PATCH 1/3] drm: Track drm_mm nodes with an interval tree
On Wed, Oct 21, 2015 at 5:14 PM, David Herrmann wrote: > On Wed, Oct 21, 2015 at 5:11 PM, Daniel Vetter wrote: >> On Tue, Oct 06, 2015 at 11:53:09AM +0100, Chris Wilson wrote: >>> In addition to the last-in/first-out stack for accessing drm_mm nodes, >>> we occasionally and in the future often want to find a drm_mm_node by an >>> address. To do so efficiently we need to track the nodes in an interval >>> tree - lookups for a particular address will then be O(lg(N)), where N >>> is the number of nodes in the range manager as opposed to O(N). >>> Insertion however gains an extra O(lg(N)) step for all nodes >>> irrespective of whether the interval tree is in use. For future i915 >>> patches, eliminating the linear walk is a significant improvement. >>> >>> Signed-off-by: Chris Wilson >>> Cc: dri-devel at lists.freedesktop.org >> >> Reviewed-by: Daniel Vetter >> >> I guess for simpler merge ordering we can just pull this into drm-intel >> and patch up the vma manager (just need to drop a lot of code and adjust >> the search to use the drm_mm internal_tree nodes) later on. > > Agreed. > > Acked-by: David Herrmann Also has Dave's irc-ack for pushing through drm-intel. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH RFCv2 0/4] Etnaviv DRM driver again
Am Donnerstag, den 22.10.2015, 09:12 +0200 schrieb Daniel Vetter:
> On Wed, Oct 21, 2015 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> > On Tue, Oct 20, 2015 at 11:36:27AM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 11, 2015 at 04:10:10PM +0200, Lucas Stach wrote:
> > > > Hey all,
> > > >
> > > > this is a new posting of the Etnaviv DRM driver for Vivante embedded
> > > > GPUs.
> > > > This time I've squashed all patches to the DRM driver itself into a
> > > > single commit
> > > > to make it easier for people to look at and review this stuff.
> > > >
> > > > Aside from squashing of some of the trivial bugfixes I intend to keep
> > > > all the
> > > > individual commits around to retain the authorship of people working on
> > > > this
> > > > driver. If you want to look at the stream of commits please fetch
> > > >
> > > > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream
> > >
> > > Finally unlazied and looked at this, assuming it's v2. Piles of comments:
> > >
> > > - Please don't use dev->struct_mutex in new driver code. With latest
> > > linux-next there's no reason at all for driver's to use it, and doing so
> > > will massively encumber your driver with everything else.
> > >
> > > There's a bit a trick involved since as-is struct_mutex allows you to do
> > > horrible leaky locking designs around gem_free_object. On a quick look
> > > to fix this you probably need a mutex for the drm_mm and various lists,
> > > plus per object reservations. Tricky part is the eviction logic in
> > > etnaviv_iommu_map_gem, where you need to trylock eviction candidates. If
> > > you can't lock them you can't evict them anyway, so no harm done.
> > >
> > > If that's too much just replace it with your own lock and trylock in
> > > gem_free_object, punting to a worker if that fails (ttm has a
> > > deferred_free list for that, protected by a spinlock).
> > >
> > > - ->load and ->unload are deprecated hooks becaus fundamentally racy (and
> > > we can't fix it since it would break dri 1 crap). Please use instead:
> > >
> > > drm_dev_alloc();
> > > /* load code */
> > > drm_dev_register();
> > >
> > > and
> > >
> > > drm_dev_unregister();
> > > /* unload code */
> > > drm_dev_unref();
> > >
> > > Laurent just sent a nice patch for rcar to do that conversion. That will
> > > also get rid of the deprecated drm_platform_init and drm_dev_put.
> > >
> > > - check pad for 0 in gem_info ioctl.
> >
> > My tree already does this, and afaik it was part of Christian's patches.
> > I'm not sure whether Lucas' patches are missing something.
> >
> > +static int etnaviv_ioctl_gem_info(struct drm_device *dev, void *data,
> > + struct drm_file *file)
> > +{
> > + struct drm_etnaviv_gem_info *args = data;
> > + struct drm_gem_object *obj;
> > + int ret = 0;
> > +
> > + if (args->pad)
> > + return -EINVAL;
> >
> > Did you miss it?
>
> That wasn't there, I guess I looked at an outdated tree :()
The tree you've looked at was up-to-date until yesterday when Russell
pulled patches into his tree and build atop of that. I've just looked at
that tree again and it certainly includes the above check.
> >
> > > - the flags check for gem_new seems leaky since you only check for flags &
> > > ETNA_BO_CACHE_MASK.
> >
> > Fixed in etnaviv_ioctl_gem_new().
> >
> > > - similar input validation issue for op in gem_cpu_prep
> >
> > Fixed in etnaviv_ioctl_gem_cpu_prep().
> >
> > > - maybe add a flags/op to future-proof gem_cpu_fini just in case? Might be
> > > useful to optimize cache flushing.
> >
> > Having just merged Lucas' patch, which carries the op from gem_cpu_prep()
> > over to gem_cpu_fini(), I'm wondering if this is hiding a potential
> > problem - what if two threads call gem_cpu_prep() but with different 'op'
> > arguments. Seems rather fragile, as 'etnaviv_obj->last_cpu_prep_op'
> > becomes rather indeterminant.
>
> Hm, dropping last_cpu_prep_op and adding it to the fini ioctl might be an
> option. But I have no idea whether the dma api likes that really. Wrt
> safety I don't think there's a concern here - if userspace decides to be
> buggy wrt coherency tracking it'll get all the pieces.
>
Yes, this is unsafe right now with multiple threads.
But I think we can't just allow multiple userspace threads to prepare a
buffer with different OPs, I'm not even sure it's a good idea to let 2
threads prepare the buffer at the same time at all (even if the OPs are
compatible, this gets really funny about when to write back the caches).
So I think we need to block the second thread until the first one does a
fini.
This might have some performance implications, but it makes it a lot
easier to get the coherency rules straight.
> > > - the naming in gem_submit_reloc confuses me a bit, but that's just a
> > > bikeshed ;-)
> > >
> > > - gem_submit seems to miss a flag, ime definitely needed (just to be abl
[PULL] drm-intel-next-fixes
Hi Dave, Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work from Ville in here since it's low-risk but lots of churn all over. With this Jani will take over 4.4 from me. Cheers, Daniel The following changes since commit 80bea1897d7bc35e2b201847e12029a9d677cf12: drm/i915: Update DRIVER_DATE to 20151010 (2015-10-10 13:35:42 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-10-22 for you to fetch changes up to 606bb5e0b28b540685fb94c22902cd9a948a3779: drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks (2015-10-19 17:56:02 +0200) Bob Paauwe (2): drm/i915/skl+: Enable pipe CSC on cursor planes. (v2) drm/i915/skl: Enable pipe gamma for sprite planes. Chris Wilson (2): drm/i915: Hold dev->event_lock whilst inspecting intel_crtc->unpin_work drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level Daniel Vetter (1): drm/i915: restore ggtt double-bind avoidance Jani Nikula (1): MAINTAINERS: add link to the Intel Graphics for Linux web site Lukas Wunner (1): drm/i915: Drop unnecessary #include Mika Kuoppala (1): drm/i915: Move skl/bxt gt specific workarounds to ring init Paulo Zanoni (1): drm/i915: revert a few more watermark commits Ville Syrjälä (13): drm/i915: Eliminate weird parameter inversion from BXT PPS registers drm/i915: Parametrize HSW video DIP data registers drm/i915: Include gpio_mmio_base in GMBUS reg defines drm/i915: Protect register macro arguments drm/i915: Fix a few bad hex numbers in register defines drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc. drm/i915: Parametrize and fix SWF registers drm/i915: Throw out some useless variables drm/i915: Clean up LVDS register handling drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE drm/i915: Kill the leftover RMW from ivb_sprite_disable() drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks Williams, Dan J (1): i915: switch from acpi_os_ioremap to memremap MAINTAINERS | 1 + drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 18 +- drivers/gpu/drm/i915/i915_gem.c | 99 +-- drivers/gpu/drm/i915/i915_gem_gtt.c | 46 ++- drivers/gpu/drm/i915/i915_irq.c | 38 +-- drivers/gpu/drm/i915/i915_reg.h | 172 ++-- drivers/gpu/drm/i915/i915_suspend.c | 45 ++- drivers/gpu/drm/i915/intel_acpi.c | 1 - drivers/gpu/drm/i915/intel_atomic.c | 1 - drivers/gpu/drm/i915/intel_audio.c | 12 +- drivers/gpu/drm/i915/intel_bios.c | 25 +- drivers/gpu/drm/i915/intel_display.c| 182 +--- drivers/gpu/drm/i915/intel_dp.c | 10 +- drivers/gpu/drm/i915/intel_drv.h| 9 +- drivers/gpu/drm/i915/intel_hdmi.c | 26 +- drivers/gpu/drm/i915/intel_i2c.c| 54 ++-- drivers/gpu/drm/i915/intel_lvds.c | 30 +- drivers/gpu/drm/i915/intel_opregion.c | 83 +++--- drivers/gpu/drm/i915/intel_panel.c | 2 +- drivers/gpu/drm/i915/intel_pm.c | 479 +--- drivers/gpu/drm/i915/intel_psr.c| 18 +- drivers/gpu/drm/i915/intel_ringbuffer.c | 44 ++- drivers/gpu/drm/i915/intel_sprite.c | 18 +- drivers/gpu/drm/i915/intel_uncore.c | 16 +- 25 files changed, 792 insertions(+), 639 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH RFCv2 0/4] Etnaviv DRM driver again
Am Donnerstag, den 22.10.2015, 09:12 +0200 schrieb Daniel Vetter: [...] > > > - all the array allocations aren't checked for integer overflows in > > > gem_submit. Just use kmalloc_array or similar to get this right. That > > > means you need to allocations in submit_create, but imo better safe than > > > security-buggy. Similar problem in submit_reloc, but there > > > copy_from_user will protect you since you only copy individual structs. > > > Still a bit fragile. > > > > I'm not sure kmalloc_array() is the right answer there, but I'll look > > into it - I'd really like to avoid doing lots of small kmalloc()s all > > over the place as each one has a non-zero cost. The more we can lump > > together, the better - but it has to be done safely. > > That was just my preference since I have a hard time reasonining about > overflow checks so like to avoid them. > We might just get some reasonable limits on the number of allowed objects per submit in place, like 64k buffers and relocs should be enough for everyone. *famous last words* Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ |
[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5
https://bugzilla.kernel.org/show_bug.cgi?id=105051 --- Comment #15 from Darren Hart --- Thanks for reporting, we're following up on the platform-drivers-x86 mailing list. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5
https://bugzilla.kernel.org/show_bug.cgi?id=105051 Darren Hart changed: What|Removed |Added Assignee|drivers_video-dri at kernel-bu |drivers_platform_x86 at kernel |gs.osdl.org |-bugs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 91993] Graphical glitch in Astromenace (open-source game).
https://bugs.freedesktop.org/show_bug.cgi?id=91993 --- Comment #21 from Nicolai Hähnle --- (In reply to Roland Scheidegger from comment #20) > Hmm I totally missed this when I fixed pretty much the same bug in mesa core > mipgen code. I guess it's a real pity there's no piglit test for this... Now there is :) MC Return, as for these menu options: Since I don't think any features were _removed_ from the driver, this sounds like it's an AstroMenace bug if anything, so you should probably talk to their developers. In any case, that topic is separate and therefore does not belong into the discussion of this particular bug here. Thanks for your patience :) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/6bf225b8/attachment.html>
[git pull] vmwgfx-fixes-4.3
Hi, Dave, I'm not sure whether this patch comes in too late, but it would be good to have it in. It stabilizes command submission in case of command buffer errors. The following changes since commit ed7d78b2da32198ca4c70172e3b63c6b3e2c570b: drm/vmwgfx: Fix kernel NULL pointer dereference on older hardware (2015-10-13 00:16:48 -0700) are available in the git repository at: git://people.freedesktop.org/~thomash/linux vmwgfx-fixes-4.3 for you to fetch changes up to 09dc1387c9c06cdaf55bc99b35238bd2ec0aed4b: drm/vmwgfx: Stabilize the command buffer submission code (2015-10-21 21:31:49 +0200) Thomas Hellstrom (1): drm/vmwgfx: Stabilize the command buffer submission code drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-)
[PATCH 1/3] amdgpu: Unlock mutex if base_required is invalid
From: Tom St Denis
In the function amdgpu_vamgr_find_va() the function would return
without unlocking the mutex if the base_required offset was below
the va managers base offset.
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
---
amdgpu/amdgpu_vamgr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 04d2881..2221da0 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -124,8 +124,10 @@ amdgpu_vamgr_find_va(struct amdgpu_bo_va_mgr *mgr,
uint64_t size,
}
if (base_required) {
- if (base_required < mgr->va_offset)
+ if (base_required < mgr->va_offset) {
+ pthread_mutex_unlock(&mgr->bo_va_mutex);
return AMDGPU_INVALID_VA_ADDRESS;
+ }
offset = mgr->va_offset;
waste = base_required - mgr->va_offset;
} else {
--
1.8.3.1
[PATCH 2/3] amdgpu: Fix use-after-free bug in vamgr_deinit
From: Tom St Denis
This patch fixes a use-after-free bug in the vamgr_deinit function.
Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
---
amdgpu/amdgpu_vamgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 2221da0..8a707cb 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -57,8 +57,8 @@ drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr
*mgr, uint64_t start,
drm_private void amdgpu_vamgr_deinit(struct amdgpu_bo_va_mgr *mgr)
{
- struct amdgpu_bo_va_hole *hole;
- LIST_FOR_EACH_ENTRY(hole, &mgr->va_holes, list) {
+ struct amdgpu_bo_va_hole *hole, *tmp;
+ LIST_FOR_EACH_ENTRY_SAFE(hole, tmp, &mgr->va_holes, list) {
list_del(&hole->list);
free(hole);
}
--
1.8.3.1
[PATCH 3/3] amdgpu: Cleanly handle ENOMEM on result in amdgpu_bo_list_create()
From: Tom St Denis
Move the allocation of result prior to the IOCTL so we can cleanly
backtrack if the allocation fails.
Signed-off-by: Tom St Denis
Reviewed-by: Alex Deucher
---
amdgpu/amdgpu_bo.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 348da00..1a5a401 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -591,6 +591,12 @@ int amdgpu_bo_list_create(amdgpu_device_handle dev,
if (!list)
return -ENOMEM;
+ *result = malloc(sizeof(struct amdgpu_bo_list));
+ if (!*result) {
+ free(list);
+ return -ENOMEM;
+ }
+
memset(&args, 0, sizeof(args));
args.in.operation = AMDGPU_BO_LIST_OP_CREATE;
args.in.bo_number = number_of_resources;
@@ -608,10 +614,11 @@ int amdgpu_bo_list_create(amdgpu_device_handle dev,
r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_BO_LIST,
&args, sizeof(args));
free(list);
- if (r)
+ if (r) {
+ free(*result);
return r;
+ }
- *result = malloc(sizeof(struct amdgpu_bo_list));
(*result)->dev = dev;
(*result)->handle = args.out.list_handle;
return 0;
--
1.8.3.1
[PATCH 1/3] drm: Update GEM refcounting docs
I just realized that I've forgotten to update all the gem refcounting
docs. For pennance also add pretty docs for the overall drm_gem_object
structure, with a few links thrown in fore good.
As usually we need to make sure the kerneldoc reference is at most a
sect2 for otherwise it won't be listed.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/gpu.tmpl | 15 +++---
include/drm/drm_gem.h | 106 +++--
2 files changed, 100 insertions(+), 21 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 90c2aab31269..6c5865bb5ee8 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -635,10 +635,10 @@ char *date;
acquired and release by calling
drm_gem_object_reference
and drm_gem_object_unreference respectively. The
caller must hold the drm_device
- struct_mutex lock. As a convenience, GEM
- provides the drm_gem_object_reference_unlocked
and
- drm_gem_object_unreference_unlocked functions
that
- can be called without holding the lock.
+ struct_mutex lock when calling
+ drm_gem_object_reference. As a convenience, GEM
+ provides drm_gem_object_unreference_unlocked
+ functions that can be called without holding the lock.
When the last reference to a GEM object is released the GEM core
calls
@@ -836,10 +836,11 @@ char *date;
abstracted from the client in libdrm.
-
-GEM Function Reference
+
+
+ GEM Function Reference
!Edrivers/gpu/drm/drm_gem.c
-
+!Iinclude/drm/drm_gem.h
VMA Offset Manager
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 15e7f007380f..0b3e11ab8757 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -35,76 +35,129 @@
*/
/**
- * This structure defines the drm_mm memory object, which will be used by the
- * DRM for its buffer objects.
+ * struct drm_gem_object - GEM buffer object
+ *
+ * This structure defines the generic parts for GEM buffer objects, which are
+ * mostly around handling mmap and userspace handles.
+ *
+ * Buffer objects are often abbreviated to BO.
*/
struct drm_gem_object {
- /** Reference count of this object */
+ /**
+* @refcount:
+*
+* Reference count of this object
+*
+* Please use drm_gem_object_reference() to acquire and
+* drm_gem_object_unreference() or drm_gem_object_unreference_unlocked()
+* to release a reference to a GEM buffer object.
+*/
struct kref refcount;
/**
-* handle_count - gem file_priv handle count of this object
+* @handle_count:
+*
+* This is the GEM file_priv handle count of this object.
*
* Each handle also holds a reference. Note that when the handle_count
* drops to 0 any global names (e.g. the id in the flink namespace) will
* be cleared.
*
* Protected by dev->object_name_lock.
-* */
+*/
unsigned handle_count;
- /** Related drm device */
+ /**
+* @dev: DRM dev this object belongs to.
+*/
struct drm_device *dev;
- /** File representing the shmem storage */
+ /**
+* @filp:
+*
+* SHMEM file node used as backing storage for swappable buffer objects.
+* GEM also supports driver private objects with driver-specific backing
+* storage (contiguous CMA memory, special reserved blocks). In this
+* case @filp is NULL.
+*/
struct file *filp;
- /* Mapping info for this object */
+ /**
+* @vma_node:
+*
+* Mapping info for this object to support mmap. Drivers are supposed to
+* allocate the mmap offset using drm_gem_create_mmap_offset(). The
+* offset itself can be retrieved using drm_vma_node_offset_addr().
+*
+* Memory mapping itself is handled by drm_gem_mmap(), which also checks
+* that userspace is allowed to access the object.
+*/
struct drm_vma_offset_node vma_node;
/**
+* @size:
+*
* Size of the object, in bytes. Immutable over the object's
* lifetime.
*/
size_t size;
/**
+* @name:
+*
* Global name for this object, starts at 1. 0 means unnamed.
-* Access is covered by the object_name_lock in the related drm_device
+* Access is covered by dev->object_name_lock. This is used by the
GEM_FLINK
+* and GEM_OPEN ioctls.
*/
int name;
/**
-* Memory domains. These monitor which caches contain read/write data
+* @read_domains:
+*
+* Read memory domains. These monitor which caches contain read/write
data
* related
[PATCH 2/3] drm/vma_manage: Drop has_offset
It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.
The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.
While at it add a note in the create_mmap_offset kerneldoc that
drivers must release it again. And then I also noticed that
drm_gem_object_release entirely lacks kerneldoc.
Cc: David Herrmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem.c | 17 +
drivers/gpu/drm/i915/i915_gem.c | 3 ---
include/drm/drm_vma_manager.h | 15 +--
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 64353d40db53..38680380c6b3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -387,6 +387,10 @@ EXPORT_SYMBOL(drm_gem_handle_create);
* @obj: obj in question
*
* This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ *
+ * Note that drm_gem_object_release() already calls this function, so drivers
+ * don't have to take care of releasing the mmap offset themselves when freeing
+ * the GEM object.
*/
void
drm_gem_free_mmap_offset(struct drm_gem_object *obj)
@@ -410,6 +414,9 @@ EXPORT_SYMBOL(drm_gem_free_mmap_offset);
* This routine allocates and attaches a fake offset for @obj, in cases where
* the virtual size differs from the physical size (ie. obj->size). Otherwise
* just use drm_gem_create_mmap_offset().
+ *
+ * This function is idempotent and handles an already allocated mmap offset
+ * transparently. Drivers do not need to check for this case.
*/
int
drm_gem_create_mmap_offset_size(struct drm_gem_object *obj, size_t size)
@@ -431,6 +438,9 @@ EXPORT_SYMBOL(drm_gem_create_mmap_offset_size);
* structures.
*
* This routine allocates and attaches a fake offset for @obj.
+ *
+ * Drivers can call drm_gem_free_mmap_offset() before freeing @obj to release
+ * the fake offset again.
*/
int drm_gem_create_mmap_offset(struct drm_gem_object *obj)
{
@@ -739,6 +749,13 @@ drm_gem_release(struct drm_device *dev, struct drm_file
*file_private)
idr_destroy(&file_private->object_idr);
}
+/**
+ * drm_gem_object_release - release GEM buffer object resources
+ * @obj: GEM buffer object
+ *
+ * This releases any structures and resources used by @obj and is the invers of
+ * drm_gem_object_init().
+ */
void
drm_gem_object_release(struct drm_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d0fa5481543c..01fef54ecb2d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1972,9 +1972,6 @@ static int i915_gem_object_create_mmap_offset(struct
drm_i915_gem_object *obj)
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
int ret;
- if (drm_vma_node_has_offset(&obj->base.vma_node))
- return 0;
-
dev_priv->mm.shrinker_no_lock_stealing = true;
ret = drm_gem_create_mmap_offset(&obj->base);
diff --git a/include/drm/drm_vma_manager.h b/include/drm/drm_vma_manager.h
index 2f63dd5e05eb..06ea8e077ec2 100644
--- a/include/drm/drm_vma_manager.h
+++ b/include/drm/drm_vma_manager.h
@@ -176,19 +176,6 @@ static inline unsigned long drm_vma_node_size(struct
drm_vma_offset_node *node)
}
/**
- * drm_vma_node_has_offset() - Check whether node is added to offset manager
- * @node: Node to be checked
- *
- * RETURNS:
- * true iff the node was previously allocated an offset and added to
- * an vma offset manager.
- */
-static inline bool drm_vma_node_has_offset(struct drm_vma_offset_node *node)
-{
- return drm_mm_node_allocated(&node->vm_node);
-}
-
-/**
* drm_vma_node_offset_addr() - Return sanitized offset for user-space mmaps
* @node: Linked offset node
*
@@ -220,7 +207,7 @@ static inline __u64 drm_vma_node_offset_addr(struct
drm_vma_offset_node *node)
static inline void drm_vma_node_unmap(struct drm_vma_offset_node *node,
struct address_space *file_mapping)
{
- if (drm_vma_node_has_offset(node))
+ if (drm_mm_node_allocated(&node->vm_node))
unmap_mapping_range(file_mapping,
drm_vma_node_offset_addr(node),
drm_vma_node_size(node) << PAGE_SHIFT, 1);
--
2.5.1
[PATCH 3/3] drm/gem: Update/Polish docs
A bunch of things have been removed meanwhile and docs not fully brought up to speed. And a few gaps closed where I noticed missing kerneldoc while reading through the overview sections. Signed-off-by: Daniel Vetter --- Documentation/DocBook/gpu.tmpl | 33 - drivers/gpu/drm/drm_gem.c | 35 --- 2 files changed, 36 insertions(+), 32 deletions(-) diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index 6c5865bb5ee8..e6735d2b6ae8 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -615,18 +615,6 @@ char *date; drm_gem_object_init. Storage for private GEM objects must be managed by drivers. - - Drivers that do not need to extend GEM objects with private information - can call the drm_gem_object_alloc function to - allocate and initialize a struct drm_gem_object - instance. The GEM core will call the optional driver - gem_init_object operation after initializing - the GEM object with drm_gem_object_init. - int (*gem_init_object) (struct drm_gem_object *obj); - - - No alloc-and-init function exists for private GEM objects. - GEM Objects Lifetime @@ -649,15 +637,9 @@ char *date; void (*gem_free_object) (struct drm_gem_object *obj); - Drivers are responsible for freeing all GEM object resources, including - the resources created by the GEM core. If an mmap offset has been - created for the object (in which case - drm_gem_object::map_list::map - is not NULL) it must be freed by a call to - drm_gem_free_mmap_offset. The shmfs backing store - must be released by calling drm_gem_object_release - (that function can safely be called if no shmfs backing store has been - created). + Drivers are responsible for freeing all GEM object resources. This includes + the resources created by the GEM core, which need to be released with + drm_gem_object_release. @@ -740,17 +722,10 @@ char *date; DRM identifies the GEM object to be mapped by a fake offset passed through the mmap offset argument. Prior to being mapped, a GEM object must thus be associated with a fake offset. To do so, drivers must call - drm_gem_create_mmap_offset on the object. The - function allocates a fake offset range from a pool and stores the - offset divided by PAGE_SIZE in - obj->map_list.hash.key. Care must be taken not to - call drm_gem_create_mmap_offset if a fake offset - has already been allocated for the object. This can be tested by - obj->map_list.map being non-NULL. + drm_gem_create_mmap_offset on the object. Once allocated, the fake offset value - (obj->map_list.hash.key << PAGE_SHIFT) must be passed to the application in a driver-specific way and can then be used as the mmap offset argument. diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 38680380c6b3..c55446a789c7 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -244,8 +244,9 @@ drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj) * @filp: drm file-private structure to use for the handle look up * @handle: userspace handle to delete * - * Removes the GEM handle from the @filp lookup table and if this is the last - * handle also cleans up linked resources like GEM names. + * Removes the GEM handle from the @filp lookup table which has been added with + * drm_gem_handle_create(). If this is the last handle also cleans up linked + * resources like GEM names. */ int drm_gem_handle_delete(struct drm_file *filp, u32 handle) @@ -314,6 +315,10 @@ EXPORT_SYMBOL(drm_gem_dumb_destroy); * This expects the dev->object_name_lock to be held already and will drop it * before returning. Used to avoid races in establishing new handles when * importing an object from either an flink name or a dma-buf. + * + * Handles must be release again through drm_gem_handle_delete(). This is done + * when userspace closes @file_priv for all attached handles, or through the + * GEM_CLOSE ioctl for individual handles. */ int drm_gem_handle_create_tail(struct drm_file *file_priv, @@ -551,7 +556,17 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages, } EXPORT_SYMBOL(drm_gem_put_pages); -/** Returns a reference to the object named by the handle. */ +/** + * drm_gem_object_lookup - look up a GEM object from it's handle + * @dev: DRM device + * @filp: DRM file private date + * @handle: userspace handle + * + * Returns: + * + * A reference to the object named by the handle if such exists
i.mx6 video out in mainline
On Thu, Oct 8, 2015 at 5:54 PM, Pushpal Sidhu wrote: > Comparing the imx6qdl-gw54xx.dtsi and imx6qdl-sabersd.dtsi, I couldn't > see too many differences between HDMI and LVDS, so I'm a little > surprised you don't see this exact same behavior there. Note that I've On a imx6q-sabresd I get HDMI at 1080p and LVDS at 1024-768.
[GIT PULL] Raspberry Pi KMS driver
On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt wrote: > Dave suggested it was time to just send a pull request on the driver, so > here goes: Why is that when the binding is still under discussion[1]? Even the agreed changes never got reposted. Rob [1] https://lkml.org/lkml/2015/10/9/676 > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > are available in the git repository at: > > http://github.com/anholt/linux drm-vc4-next-2015-10-21 > > for you to fetch changes up to 98a44504541c6befb28366eb9ec432ba44070dd9: > > drm/vc4: Allow vblank to be disabled (2015-10-21 10:33:13 +0100) > > > This pull request introduces the vc4 driver, for kernel modesetting on > the Raspberry Pi (bcm2835/bcm2836 architectures). It currently > supports a display plane and cursor on the HDMI output. The driver > doesn't do 3D, power management, or overlay planes yet. > > > Derek Foreman (2): > drm/vc4: Use the fbdev_cma helpers > drm/vc4: Allow vblank to be disabled > > Eric Anholt (2): > drm/vc4: Add devicetree bindings for VC4. > drm/vc4: Add KMS support for Raspberry Pi. > > .../devicetree/bindings/display/brcm,bcm-vc4.txt | 65 ++ > drivers/gpu/drm/Kconfig| 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/vc4/Kconfig| 13 + > drivers/gpu/drm/vc4/Makefile | 17 + > drivers/gpu/drm/vc4/vc4_bo.c | 52 ++ > drivers/gpu/drm/vc4/vc4_crtc.c | 672 > + > drivers/gpu/drm/vc4/vc4_debugfs.c | 39 ++ > drivers/gpu/drm/vc4/vc4_drv.c | 298 + > drivers/gpu/drm/vc4/vc4_drv.h | 145 + > drivers/gpu/drm/vc4/vc4_hdmi.c | 590 ++ > drivers/gpu/drm/vc4/vc4_hvs.c | 163 + > drivers/gpu/drm/vc4/vc4_kms.c | 67 ++ > drivers/gpu/drm/vc4/vc4_plane.c| 320 ++ > drivers/gpu/drm/vc4/vc4_regs.h | 570 + > 15 files changed, 3014 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt > create mode 100644 drivers/gpu/drm/vc4/Kconfig > create mode 100644 drivers/gpu/drm/vc4/Makefile > create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c > create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c > create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c > create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c > create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c > create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c > create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 1/3] drm: Update GEM refcounting docs
On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter
wrote:
> I just realized that I've forgotten to update all the gem refcounting
> docs. For pennance also add pretty docs for the overall drm_gem_object
> structure, with a few links thrown in fore good.
>
> As usually we need to make sure the kerneldoc reference is at most a
> sect2 for otherwise it won't be listed.
>
> Signed-off-by: Daniel Vetter
Patches 1 and 3 are:
Reviewed-by: Alex Deucher
> ---
> Documentation/DocBook/gpu.tmpl | 15 +++---
> include/drm/drm_gem.h | 106
> +++--
> 2 files changed, 100 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 90c2aab31269..6c5865bb5ee8 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -635,10 +635,10 @@ char *date;
>acquired and release by calling
> drm_gem_object_reference
>and drm_gem_object_unreference respectively.
> The
>caller must hold the drm_device
> - struct_mutex lock. As a convenience, GEM
> - provides the
> drm_gem_object_reference_unlocked and
> - drm_gem_object_unreference_unlocked functions
> that
> - can be called without holding the lock.
> + struct_mutex lock when calling
> + drm_gem_object_reference. As a convenience, GEM
> + provides drm_gem_object_unreference_unlocked
> + functions that can be called without holding the lock.
>
>
>When the last reference to a GEM object is released the GEM core
> calls
> @@ -836,10 +836,11 @@ char *date;
>abstracted from the client in libdrm.
>
>
> -
> -GEM Function Reference
> +
> +
> + GEM Function Reference
> !Edrivers/gpu/drm/drm_gem.c
> -
> +!Iinclude/drm/drm_gem.h
>
>
>VMA Offset Manager
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 15e7f007380f..0b3e11ab8757 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -35,76 +35,129 @@
> */
>
> /**
> - * This structure defines the drm_mm memory object, which will be used by the
> - * DRM for its buffer objects.
> + * struct drm_gem_object - GEM buffer object
> + *
> + * This structure defines the generic parts for GEM buffer objects, which are
> + * mostly around handling mmap and userspace handles.
> + *
> + * Buffer objects are often abbreviated to BO.
> */
> struct drm_gem_object {
> - /** Reference count of this object */
> + /**
> +* @refcount:
> +*
> +* Reference count of this object
> +*
> +* Please use drm_gem_object_reference() to acquire and
> +* drm_gem_object_unreference() or
> drm_gem_object_unreference_unlocked()
> +* to release a reference to a GEM buffer object.
> +*/
> struct kref refcount;
>
> /**
> -* handle_count - gem file_priv handle count of this object
> +* @handle_count:
> +*
> +* This is the GEM file_priv handle count of this object.
> *
> * Each handle also holds a reference. Note that when the handle_count
> * drops to 0 any global names (e.g. the id in the flink namespace)
> will
> * be cleared.
> *
> * Protected by dev->object_name_lock.
> -* */
> +*/
> unsigned handle_count;
>
> - /** Related drm device */
> + /**
> +* @dev: DRM dev this object belongs to.
> +*/
> struct drm_device *dev;
>
> - /** File representing the shmem storage */
> + /**
> +* @filp:
> +*
> +* SHMEM file node used as backing storage for swappable buffer
> objects.
> +* GEM also supports driver private objects with driver-specific
> backing
> +* storage (contiguous CMA memory, special reserved blocks). In this
> +* case @filp is NULL.
> +*/
> struct file *filp;
>
> - /* Mapping info for this object */
> + /**
> +* @vma_node:
> +*
> +* Mapping info for this object to support mmap. Drivers are supposed
> to
> +* allocate the mmap offset using drm_gem_create_mmap_offset(). The
> +* offset itself can be retrieved using drm_vma_node_offset_addr().
> +*
> +* Memory mapping itself is handled by drm_gem_mmap(), which also
> checks
> +* that userspace is allowed to access the object.
> +*/
> struct drm_vma_offset_node vma_node;
>
> /**
> +* @size:
> +*
> * Size of the object, in bytes. Immutable over the object's
> * lifetime.
> */
> size_t size;
>
> /**
> +* @name:
> +*
> * Global name for this object, starts at 1. 0 means unnamed.
> -* Access is covered by the object_name_lock in the
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #33 from Barto --- (In reply to Roland Scheidegger from comment #32) > I believe the patch posted by Jose here, > http://lists.freedesktop.org/archives/mesa-dev/2015-October/097948.html > should help. > I tested the patch posted by Jose, it doesn't solve the bug, the crash is still here ( "illegal instruction" ), we need to be sure that the "SSE4" argument is not passed to the llvm compiler by mesa if the CPU doesn't support SSE4, for llvm 3.7.0 my cpu name is "penryn" and it seems that SSE4 is enabled by default for penryn cpu in llvm default settings, that's why a check must be done by mesa in order to avoid this crash ( illegal opcode cpu ) when a pentium dual core is used, the SSE4 argument should not be passed to the llvm compiler if the CPU doesn't support it, I don't know exactly what is wrong in mesa source code, if the check related to SSE4 is really done and if mesa tries to pass to llvm the good cpu features arguments ( SSEx, MMX, AVX... ), for now the workaround I found is to patch LLVM 3.7.0 in order to re-add the "SSE4 test", my CPU name will be after this patch : "core2", which was the default behaviour in previous versions of LLVM ( like 3.6.2 version ) : --- a/lib/Support/Host.cpp2015-10-14 07:13:52.381374679 +0200 +++ b/lib/Support/Host.cpp 2015-10-14 07:13:28.224708323 +0200 @@ -332,6 +332,8 @@ // 17h. All processors are manufactured using the 45 nm process. // // 45nm: Penryn , Wolfdale, Yorkfield (XE) +// Not all Penryn processors support SSE 4.1 (such as the Pentium brand) +return HasSSE41 ? "penryn" : "core2"; case 29: // Intel Xeon processor MP. All processors are manufactured using // the 45 nm process. return "penryn"; -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/25b44572/attachment.html>
[PULL] topic/drm-misc
Hi Dave, Few more drm-misc stragglers for 4.4. Big thing is the generic probe for imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing). Also the hdmi clocking fixes from Ville which was a lot of confusion about which tree it should be applied to ;-) Cheers, Daniel The following changes since commit affa0e033b04996700434312c76df3c78f683870: Merge tag 'topic/drm-misc-2015-10-19' of git://anongit.freedesktop.org/drm-intel into drm-next (2015-10-20 09:01:49 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-10-22 for you to fetch changes up to 48aa1e748f29373fdcc2bc341eac08ef16bff269: drm: correctly check failed allocation (2015-10-21 09:27:30 +0200) Insu Yun (1): drm: correctly check failed allocation Liviu Dudau (4): drm: Introduce generic probe function for component based masters. drm/imx: Convert the probe function to the generic drm_of_component_probe() drm/rockchip: Convert the probe function to the generic drm_of_component_probe() drm/armada: Convert the probe function to the generic drm_of_component_probe() Lukas Wunner (1): vga_switcheroo: Constify vga_switcheroo_handler Ville Syrjälä (2): drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings drm/edid: Round to closest when computing the CEA/HDMI alternate clock drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +- drivers/gpu/drm/armada/armada_drv.c | 68 +- drivers/gpu/drm/drm_crtc.c | 30 drivers/gpu/drm/drm_edid.c | 52 +- drivers/gpu/drm/drm_of.c | 88 drivers/gpu/drm/imx/imx-drm-core.c | 55 ++- drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 81 ++ drivers/gpu/vga/vga_switcheroo.c | 4 +- drivers/platform/x86/apple-gmux.c| 2 +- include/drm/drm_of.h | 13 include/linux/vga_switcheroo.h | 4 +- 13 files changed, 218 insertions(+), 185 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Intel-gfx] [PATCH 2/3] drm/vma_manage: Drop has_offset
On Fri, Oct 23, 2015 at 02:47:49AM +0800, kbuild test robot wrote:
> Hi Daniel,
>
> [auto build test WARNING on drm/drm-next -- if it's inappropriate base,
> please suggest rules for selecting the more suitable base]
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-Update-GEM-refcounting-docs/20151023-011317
> config: x86_64-randconfig-s1-10230205 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All warnings (new ones prefixed by >>):
>
>In file included from include/uapi/linux/stddef.h:1:0,
> from include/linux/stddef.h:4,
> from include/uapi/linux/posix_types.h:4,
> from include/uapi/linux/types.h:13,
> from include/linux/types.h:5,
> from include/linux/list.h:4,
> from include/linux/module.h:9,
> from drivers/gpu/drm/vgem/vgem_drv.c:33:
>drivers/gpu/drm/vgem/vgem_drv.c: In function 'vgem_gem_dumb_map':
>drivers/gpu/drm/vgem/vgem_drv.c:211:7: error: implicit declaration of
> function 'drm_vma_node_has_offset' [-Werror=implicit-function-declaration]
> if (!drm_vma_node_has_offset(&obj->vma_node)) {
> ^
>include/linux/compiler.h:147:28: note: in definition of macro '__trace_if'
> if (__builtin_constant_p((cond)) ? !!(cond) : \
>^
> >> drivers/gpu/drm/vgem/vgem_drv.c:211:2: note: in expansion of macro 'if'
> if (!drm_vma_node_has_offset(&obj->vma_node)) {
> ^
>cc1: some warnings being treated as errors
Argh, I've forgotten that the vgem patch in my tree isn't merged yet. So
that one needs to go in (to remove another dubious use of has_offset())
before we can pull in this one.
-Daniel
>
> vim +/if +211 drivers/gpu/drm/vgem/vgem_drv.c
>
> 502e95c6 Zach Reizner 2015-03-04 27
> 502e95c6 Zach Reizner 2015-03-04 28 /**
> 502e95c6 Zach Reizner 2015-03-04 29 * This is vgem, a
> (non-hardware-backed) GEM service. This is used by Mesa's
> 502e95c6 Zach Reizner 2015-03-04 30 * software renderer and the X
> server for efficient buffer sharing.
> 502e95c6 Zach Reizner 2015-03-04 31 */
> 502e95c6 Zach Reizner 2015-03-04 32
> 502e95c6 Zach Reizner 2015-03-04 @33 #include
> 502e95c6 Zach Reizner 2015-03-04 34 #include
> 502e95c6 Zach Reizner 2015-03-04 35 #include
> 502e95c6 Zach Reizner 2015-03-04 36 #include
> 502e95c6 Zach Reizner 2015-03-04 37 #include "vgem_drv.h"
> 502e95c6 Zach Reizner 2015-03-04 38
> 502e95c6 Zach Reizner 2015-03-04 39 #define DRIVER_NAME "vgem"
> 502e95c6 Zach Reizner 2015-03-04 40 #define DRIVER_DESC
> "Virtual GEM provider"
> 502e95c6 Zach Reizner 2015-03-04 41 #define DRIVER_DATE
> "20120112"
> 502e95c6 Zach Reizner 2015-03-04 42 #define DRIVER_MAJOR 1
> 502e95c6 Zach Reizner 2015-03-04 43 #define DRIVER_MINOR 0
> 502e95c6 Zach Reizner 2015-03-04 44
> 502e95c6 Zach Reizner 2015-03-04 45 void vgem_gem_put_pages(struct
> drm_vgem_gem_object *obj)
> 502e95c6 Zach Reizner 2015-03-04 46 {
> 502e95c6 Zach Reizner 2015-03-04 47 drm_gem_put_pages(&obj->base,
> obj->pages, false, false);
> 502e95c6 Zach Reizner 2015-03-04 48 obj->pages = NULL;
> 502e95c6 Zach Reizner 2015-03-04 49 }
> 502e95c6 Zach Reizner 2015-03-04 50
> 502e95c6 Zach Reizner 2015-03-04 51 static void
> vgem_gem_free_object(struct drm_gem_object *obj)
> 502e95c6 Zach Reizner 2015-03-04 52 {
> 502e95c6 Zach Reizner 2015-03-04 53 struct drm_vgem_gem_object
> *vgem_obj = to_vgem_bo(obj);
> 502e95c6 Zach Reizner 2015-03-04 54
> 502e95c6 Zach Reizner 2015-03-04 55 drm_gem_free_mmap_offset(obj);
> 502e95c6 Zach Reizner 2015-03-04 56
> 502e95c6 Zach Reizner 2015-03-04 57 if (vgem_obj->use_dma_buf &&
> obj->dma_buf) {
> 502e95c6 Zach Reizner 2015-03-04 58
> dma_buf_put(obj->dma_buf);
> 502e95c6 Zach Reizner 2015-03-04 59 obj->dma_buf = NULL;
> 502e95c6 Zach Reizner 2015-03-04 60 }
> 502e95c6 Zach Reizner 2015-03-04 61
> 502e95c6 Zach Reizner 2015-03-04 62 drm_gem_object_release(obj);
> 502e95c6 Zach Reizner 2015-03-04 63
> 502e95c6 Zach Reizner 2015-03-04 64 if (vgem_obj->pages)
> 502e95c6 Zach Reizner 2015-03-04 65
> vgem_gem_put_pages(vgem_obj);
> 502e95c6 Zach Reizner 2015-03-04 66
> 502e95c6 Zach Reizner 2015-03-04 67 vgem_obj->pages = NULL;
> 502e95c6 Zach Reizner 2015-03-04 68
> 502e95c6 Zach Reizner 2015-03-04 69 kfree(vgem_obj);
> 502e95c6 Zach Reizner 2015-03-04 70 }
> 502e95c6 Zach Reizner 2015-03-04 71
> 502e95c6 Zach
[PATCH 1/3] drm: Update GEM refcounting docs
On Thu, Oct 22, 2015 at 01:54:17PM -0400, Alex Deucher wrote:
> On Thu, Oct 22, 2015 at 1:11 PM, Daniel Vetter
> wrote:
> > I just realized that I've forgotten to update all the gem refcounting
> > docs. For pennance also add pretty docs for the overall drm_gem_object
> > structure, with a few links thrown in fore good.
> >
> > As usually we need to make sure the kerneldoc reference is at most a
> > sect2 for otherwise it won't be listed.
> >
> > Signed-off-by: Daniel Vetter
>
> Patches 1 and 3 are:
> Reviewed-by: Alex Deucher
Thanks, applied to drm-misc.
-Daniel
>
> > ---
> > Documentation/DocBook/gpu.tmpl | 15 +++---
> > include/drm/drm_gem.h | 106
> > +++--
> > 2 files changed, 100 insertions(+), 21 deletions(-)
> >
> > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> > index 90c2aab31269..6c5865bb5ee8 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -635,10 +635,10 @@ char *date;
> >acquired and release by calling
> > drm_gem_object_reference
> >and drm_gem_object_unreference
> > respectively. The
> >caller must hold the drm_device
> > - struct_mutex lock. As a convenience,
> > GEM
> > - provides the
> > drm_gem_object_reference_unlocked and
> > - drm_gem_object_unreference_unlocked
> > functions that
> > - can be called without holding the lock.
> > + struct_mutex lock when calling
> > + drm_gem_object_reference. As a convenience,
> > GEM
> > + provides drm_gem_object_unreference_unlocked
> > + functions that can be called without holding the lock.
> >
> >
> >When the last reference to a GEM object is released the GEM core
> > calls
> > @@ -836,10 +836,11 @@ char *date;
> >abstracted from the client in libdrm.
> >
> >
> > -
> > -GEM Function Reference
> > +
> > +
> > + GEM Function Reference
> > !Edrivers/gpu/drm/drm_gem.c
> > -
> > +!Iinclude/drm/drm_gem.h
> >
> >
> >VMA Offset Manager
> > diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> > index 15e7f007380f..0b3e11ab8757 100644
> > --- a/include/drm/drm_gem.h
> > +++ b/include/drm/drm_gem.h
> > @@ -35,76 +35,129 @@
> > */
> >
> > /**
> > - * This structure defines the drm_mm memory object, which will be used by
> > the
> > - * DRM for its buffer objects.
> > + * struct drm_gem_object - GEM buffer object
> > + *
> > + * This structure defines the generic parts for GEM buffer objects, which
> > are
> > + * mostly around handling mmap and userspace handles.
> > + *
> > + * Buffer objects are often abbreviated to BO.
> > */
> > struct drm_gem_object {
> > - /** Reference count of this object */
> > + /**
> > +* @refcount:
> > +*
> > +* Reference count of this object
> > +*
> > +* Please use drm_gem_object_reference() to acquire and
> > +* drm_gem_object_unreference() or
> > drm_gem_object_unreference_unlocked()
> > +* to release a reference to a GEM buffer object.
> > +*/
> > struct kref refcount;
> >
> > /**
> > -* handle_count - gem file_priv handle count of this object
> > +* @handle_count:
> > +*
> > +* This is the GEM file_priv handle count of this object.
> > *
> > * Each handle also holds a reference. Note that when the
> > handle_count
> > * drops to 0 any global names (e.g. the id in the flink namespace)
> > will
> > * be cleared.
> > *
> > * Protected by dev->object_name_lock.
> > -* */
> > +*/
> > unsigned handle_count;
> >
> > - /** Related drm device */
> > + /**
> > +* @dev: DRM dev this object belongs to.
> > +*/
> > struct drm_device *dev;
> >
> > - /** File representing the shmem storage */
> > + /**
> > +* @filp:
> > +*
> > +* SHMEM file node used as backing storage for swappable buffer
> > objects.
> > +* GEM also supports driver private objects with driver-specific
> > backing
> > +* storage (contiguous CMA memory, special reserved blocks). In this
> > +* case @filp is NULL.
> > +*/
> > struct file *filp;
> >
> > - /* Mapping info for this object */
> > + /**
> > +* @vma_node:
> > +*
> > +* Mapping info for this object to support mmap. Drivers are
> > supposed to
> > +* allocate the mmap offset using drm_gem_create_mmap_offset(). The
> > +* offset itself can be retrieved using drm_vma_node_offset_addr().
> > +*
> > +* Memory mapping itself is handled by drm_gem_mmap(), which also
> > checks
> > +* that userspace is allowed to access the object.
> > +*/
> >
[GIT PULL] Raspberry Pi KMS driver
On Thu, Oct 22, 2015 at 12:40:23PM -0500, Rob Herring wrote: > On Wed, Oct 21, 2015 at 4:53 AM, Eric Anholt wrote: > > Dave suggested it was time to just send a pull request on the driver, so > > here goes: > > Why is that when the binding is still under discussion[1]? Even the > agreed changes never got reposted. Bit a longer story, so here we go: I don't really like drivers/staging since it's a cage where drivers get forgotten about, and even if there is activity it's completely separate from all the other drm drivers. Which doesn't help with collaboration, which is the entire point really of upstreaming. Otoh I really like how drivers/staging allows not-quite-ready drivers to get in and get more visibility. So for drm I think the right approach is to just merge drivers which are reasonable close to good enough, and fix up anything erregrious once merged. This might be special for drm, since gpus change ridiculously fast, resulting in anyone contributing for more than 2-3 years to be constantly busy cleaning up past code that turned out a mistake in light of todays hardware. I think that means overall drm has a lower bar to entry and much higher acceptance for crap. And there's lots of it. Could very well be that most of the drm subsystem should be in drivers/staging by everyone else's standard. For this specific case here of the rpi driver the only ongoing thing was the dt binding discussion, and it didn't look like it would reach closure anytime soon. On top of that this driver is for rpi specifically (vc5 will require a completely new driver for a bunch of reasons), and on those boards the boot loader will never ship a dt file, it will always come from the kernel. Which means it's really just an internal interface and there's zero concerns about compatibility. Also, besides dt Eric's driver was in excellent shape. Given all that I've seen no reason to delay this any longer and recommended we just pull it in. Yours, Daniel > > Rob > > [1] https://lkml.org/lkml/2015/10/9/676 > > > > > The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: > > > > Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) > > > > are available in the git repository at: > > > > http://github.com/anholt/linux drm-vc4-next-2015-10-21 > > > > for you to fetch changes up to 98a44504541c6befb28366eb9ec432ba44070dd9: > > > > drm/vc4: Allow vblank to be disabled (2015-10-21 10:33:13 +0100) > > > > > > This pull request introduces the vc4 driver, for kernel modesetting on > > the Raspberry Pi (bcm2835/bcm2836 architectures). It currently > > supports a display plane and cursor on the HDMI output. The driver > > doesn't do 3D, power management, or overlay planes yet. > > > > > > Derek Foreman (2): > > drm/vc4: Use the fbdev_cma helpers > > drm/vc4: Allow vblank to be disabled > > > > Eric Anholt (2): > > drm/vc4: Add devicetree bindings for VC4. > > drm/vc4: Add KMS support for Raspberry Pi. > > > > .../devicetree/bindings/display/brcm,bcm-vc4.txt | 65 ++ > > drivers/gpu/drm/Kconfig| 2 + > > drivers/gpu/drm/Makefile | 1 + > > drivers/gpu/drm/vc4/Kconfig| 13 + > > drivers/gpu/drm/vc4/Makefile | 17 + > > drivers/gpu/drm/vc4/vc4_bo.c | 52 ++ > > drivers/gpu/drm/vc4/vc4_crtc.c | 672 > > + > > drivers/gpu/drm/vc4/vc4_debugfs.c | 39 ++ > > drivers/gpu/drm/vc4/vc4_drv.c | 298 + > > drivers/gpu/drm/vc4/vc4_drv.h | 145 + > > drivers/gpu/drm/vc4/vc4_hdmi.c | 590 ++ > > drivers/gpu/drm/vc4/vc4_hvs.c | 163 + > > drivers/gpu/drm/vc4/vc4_kms.c | 67 ++ > > drivers/gpu/drm/vc4/vc4_plane.c| 320 ++ > > drivers/gpu/drm/vc4/vc4_regs.h | 570 + > > 15 files changed, 3014 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt > > create mode 100644 drivers/gpu/drm/vc4/Kconfig > > create mode 100644 drivers/gpu/drm/vc4/Makefile > > create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h > > create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c > > create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h > > > > ___ > > dri-dev
[PATCH drm 0/6] PRIME Synchronization
Hello all, For a while now, I've been working to fix tearing with PRIME. I have a working solution that requires changes to DRM, libdrm, and the X server. I've also implemented sink support in the modesetting driver, and source support in the NVIDIA proprietary driver. These DRM patches ultimately provide a new ioctl, DRM_IOCTL_PRIME_PAGE_FLIP, that sets up a fence on a PRIME member's DMA-BUF reservation object with a callback to schedule a flip to the associated fb. With my synchronization patches to X, it is possible to export two shared buffers per crtc instead of just one. The sink driver uses DRM_IOCTL_PRIME_PAGE_FLIP to set up fences on each of these buffers. When the source driver is done presenting on a given buffer, it signals the associated fence, and the sink flips on the next vblank. In the page flip event handler, the sink driver uses the ioctl to set up another fence, and explicitly requests a present on the current back buffer using a new function in the X ABI. Thus, flips are driven by presents, presents are driven by flips, and the whole thing conforms to the sink's refresh rate. Right now, the part that signals the fence is a vendor-specific ioctl, but I'm open to factoring it out into a core DRM ioctl and DRM driver function helper like DRM_IOCTL_PRIME_PAGE_FLIP if it would make implementing source support easier for open source drivers. Due to the lack of asynchronous atomic modesetting support on i915 (the sink of most hybrid graphics systems,) I've implemented this on top of the old page_flip method. Perhaps an atomic modesetting / nuclear pageflip based method would be better, but it wouldn't be as viable without widespread asynchronous support. I'm willing to implement an atomic modesetting version if required, but it's less clear what the best implementation would be: perhaps a fence property that defers asynchronous commits. There are enough ways to do it that it probably warrants prior discussion. Nonetheless, this method is necessary at least as a fallback until i915 supports asynchronous atomic modesetting. To give some greater context, I've uploaded my branches for DRM, libdrm, and the X server to Github. I'll move forward with upstreaming the libdrm and X changes if and when these DRM patches go in. DRM Tree:https://github.com/GoinsWithTheWind/drm-prime-sync libdrm Tree: https://github.com/GoinsWithTheWind/libdrm-prime-sync X Tree: https://github.com/GoinsWithTheWind/xserver-prime-sync Thanks, Alex @ NVIDIA Linux Driver Team agoins (6): drm: factor out drm_mode_page_flip_ioctl() drm: generalize drm_prime_lookup drm: add fence context drm: add drm_gem_prime_page_flip() helper drm: add prime_page_flip() driver function drm: add DRM_IOCTL_PRIME_PAGE_FLIP drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 + drivers/gpu/drm/armada/armada_drv.c | 1 + drivers/gpu/drm/drm_crtc.c | 90 drivers/gpu/drm/drm_internal.h | 2 + drivers/gpu/drm/drm_ioctl.c | 1 + drivers/gpu/drm/drm_prime.c | 213 ++-- drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 + drivers/gpu/drm/i915/i915_drv.c | 1 + drivers/gpu/drm/imx/imx-drm-core.c | 1 + drivers/gpu/drm/msm/msm_drv.c | 1 + drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + drivers/gpu/drm/omapdrm/omap_drv.c | 1 + drivers/gpu/drm/qxl/qxl_drv.c | 1 + drivers/gpu/drm/radeon/radeon_drv.c | 1 + drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 + drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 + drivers/gpu/drm/shmobile/shmob_drm_drv.c| 1 + drivers/gpu/drm/sti/sti_drv.c | 1 + drivers/gpu/drm/tegra/drm.c | 1 + drivers/gpu/drm/udl/udl_drv.c | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 + include/drm/drmP.h | 8 ++ include/drm/drm_crtc.h | 4 + include/uapi/drm/drm.h | 10 ++ 24 files changed, 303 insertions(+), 42 deletions(-) -- 1.9.1
[PATCH drm 1/6] drm: factor out drm_mode_page_flip_ioctl()
From: agoins
Factors contents of drm_mode_page_flip_ioctl() into drm_mode_page_flip(),
allowing it to be callable from the kernel within DRM. Replace contents of
drm_mode_page_flip_ioctl() with a call to drm_mode_page_flip().
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_crtc.c | 90 +++---
include/drm/drm_crtc.h | 4 +++
2 files changed, 66 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e54660a..503b651 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5126,41 +5126,40 @@ out:
}
/**
- * drm_mode_page_flip_ioctl - schedule an asynchronous fb update
+ * drm_mode_page_flip - schedule an asynchronous fb update
* @dev: DRM device
- * @data: ioctl data
+ * @crtc_id: CRTC to update
+ * @fb_id: FB to update to
+ * @flags: Flags modifying page flip behavior.
+ * @user_data: Returned as user_data field in in the vblank event struct
* @file_priv: DRM file info
*
* This schedules an asynchronous update on a given CRTC, called page flip.
* Optionally a drm event is generated to signal the completion of the event.
* Generic drivers cannot assume that a pageflip with changed framebuffer
* properties (including driver specific metadata like tiling layout) will
work,
- * but some drivers support e.g. pixel format changes through the pageflip
- * ioctl.
- *
- * Called by the user via ioctl.
+ * but some drivers support e.g. pixel format changes through the pageflip.
*
* Returns:
* Zero on success, negative errno on failure.
*/
-int drm_mode_page_flip_ioctl(struct drm_device *dev,
-void *data, struct drm_file *file_priv)
+int drm_mode_page_flip(struct drm_device *dev,
+ uint32_t crtc_id, uint32_t fb_id,
+ uint32_t flags, uint64_t user_data,
+ struct drm_file *file_priv)
{
- struct drm_mode_crtc_page_flip *page_flip = data;
struct drm_crtc *crtc;
struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
- unsigned long flags;
+ unsigned long lock_flags;
int ret = -EINVAL;
- if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
- page_flip->reserved != 0)
- return -EINVAL;
-
- if ((page_flip->flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
!dev->mode_config.async_page_flip)
+ if ((flags & DRM_MODE_PAGE_FLIP_ASYNC) &&
+ !dev->mode_config.async_page_flip) {
return -EINVAL;
+ }
- crtc = drm_crtc_find(dev, page_flip->crtc_id);
+ crtc = drm_crtc_find(dev, crtc_id);
if (!crtc)
return -ENOENT;
@@ -5177,7 +5176,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (crtc->funcs->page_flip == NULL)
goto out;
- fb = drm_framebuffer_lookup(dev, page_flip->fb_id);
+ fb = drm_framebuffer_lookup(dev, fb_id);
if (!fb) {
ret = -ENOENT;
goto out;
@@ -5200,27 +5199,27 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}
- if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
+ if (flags & DRM_MODE_PAGE_FLIP_EVENT) {
ret = -ENOMEM;
- spin_lock_irqsave(&dev->event_lock, flags);
+ spin_lock_irqsave(&dev->event_lock, lock_flags);
if (file_priv->event_space < sizeof(e->event)) {
- spin_unlock_irqrestore(&dev->event_lock, flags);
+ spin_unlock_irqrestore(&dev->event_lock, lock_flags);
goto out;
}
file_priv->event_space -= sizeof(e->event);
- spin_unlock_irqrestore(&dev->event_lock, flags);
+ spin_unlock_irqrestore(&dev->event_lock, lock_flags);
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (e == NULL) {
- spin_lock_irqsave(&dev->event_lock, flags);
+ spin_lock_irqsave(&dev->event_lock, lock_flags);
file_priv->event_space += sizeof(e->event);
- spin_unlock_irqrestore(&dev->event_lock, flags);
+ spin_unlock_irqrestore(&dev->event_lock, lock_flags);
goto out;
}
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
- e->event.user_data = page_flip->user_data;
+ e->event.user_data = user_data;
e->base.event = &e->event.base;
e->base.file_priv = file_priv;
e->base.destroy =
@@ -5228,12 +5227,12 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
crtc->primary->old_fb = crtc->primary->fb;
- ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags);
+ ret = crtc->funcs->
[PATCH drm 3/6] drm: add fence context
From: agoins
Adds new struct drm_prime_fence_ctx as field of drm_prime_member, and
initializes it when member is created. Used for keeping track of context id
and seqno of fences to be generated by PRIME.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_prime.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index e2e86de..2956a65 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
@@ -60,8 +61,14 @@
* use the drm_gem_prime_{import,export} helpers.
*/
+struct drm_prime_fence_ctx {
+ uint32_t context;
+ uint32_t seqno;
+};
+
struct drm_prime_member {
struct list_head entry;
+ struct drm_prime_fence_ctx fctx;
struct dma_buf *dma_buf;
uint32_t handle;
};
@@ -83,6 +90,11 @@ static int drm_prime_add_buf_handle(struct
drm_prime_file_private *prime_fpriv,
get_dma_buf(dma_buf);
member->dma_buf = dma_buf;
member->handle = handle;
+
+ /* Initialize fence context for PRIME flipping */
+ member->fctx.context = fence_context_alloc(1);
+ member->fctx.seqno = 0;
+
list_add(&member->entry, &prime_fpriv->head);
return 0;
}
--
1.9.1
[PATCH drm 2/6] drm: generalize drm_prime_lookup
From: agoins
Replace drm_prime_lookup_buf_by_handle() and drm_prime_lookup_buf_handle()
with more generalized drm_prime_lookup_member_by_handle() and
drm_prime_lookup_buf_member(), respectively. New implementations return the
member itself rather than extracting a specific field, allowing other
fields to be queried as well.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_prime.c | 34 --
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 27aa718..e2e86de 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -87,32 +87,33 @@ static int drm_prime_add_buf_handle(struct
drm_prime_file_private *prime_fpriv,
return 0;
}
-static struct dma_buf *drm_prime_lookup_buf_by_handle(struct
drm_prime_file_private *prime_fpriv,
- uint32_t handle)
+static struct drm_prime_member *drm_prime_lookup_member_by_handle(
+ struct drm_prime_file_private *prime_fpriv,
+ uint32_t handle)
{
struct drm_prime_member *member;
list_for_each_entry(member, &prime_fpriv->head, entry) {
if (member->handle == handle)
- return member->dma_buf;
+ return member;
}
return NULL;
}
-static int drm_prime_lookup_buf_handle(struct drm_prime_file_private
*prime_fpriv,
- struct dma_buf *dma_buf,
- uint32_t *handle)
+static struct drm_prime_member *drm_prime_lookup_buf_member(
+ struct drm_prime_file_private *prime_fpriv,
+ struct dma_buf *dma_buf)
{
struct drm_prime_member *member;
list_for_each_entry(member, &prime_fpriv->head, entry) {
if (member->dma_buf == dma_buf) {
- *handle = member->handle;
- return 0;
+ return member;
}
}
- return -ENOENT;
+
+ return NULL;
}
static int drm_gem_map_attach(struct dma_buf *dma_buf,
@@ -404,6 +405,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
{
struct drm_gem_object *obj;
int ret = 0;
+ struct drm_prime_member *member;
struct dma_buf *dmabuf;
mutex_lock(&file_priv->prime.lock);
@@ -413,8 +415,9 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
goto out_unlock;
}
- dmabuf = drm_prime_lookup_buf_by_handle(&file_priv->prime, handle);
- if (dmabuf) {
+ member = drm_prime_lookup_member_by_handle(&file_priv->prime, handle);
+ if (member) {
+ dmabuf = member->dma_buf;
get_dma_buf(dmabuf);
goto out_have_handle;
}
@@ -564,6 +567,7 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
uint32_t *handle)
{
struct dma_buf *dma_buf;
+ struct drm_prime_member *member;
struct drm_gem_object *obj;
int ret;
@@ -573,10 +577,12 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
mutex_lock(&file_priv->prime.lock);
- ret = drm_prime_lookup_buf_handle(&file_priv->prime,
- dma_buf, handle);
- if (ret == 0)
+ member = drm_prime_lookup_buf_member(&file_priv->prime, dma_buf);
+ if (member) {
+ ret = 0;
+ *handle = member->handle;
goto out_put;
+ }
/* never seen this one, need to import */
mutex_lock(&dev->object_name_lock);
--
1.9.1
[PATCH drm 4/6] drm: add drm_gem_prime_page_flip() helper
From: agoins
Adds drm_gem_prime_page_flip(), a helper implementation of
prime_page_flip() to be used by DRM drivers.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_prime.c | 147
include/drm/drmP.h | 3 +
2 files changed, 150 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 2956a65..175bf4a 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -61,6 +61,11 @@
* use the drm_gem_prime_{import,export} helpers.
*/
+struct drm_prime_fence {
+ struct fence base;
+ spinlock_t lock;
+};
+
struct drm_prime_fence_ctx {
uint32_t context;
uint32_t seqno;
@@ -78,6 +83,16 @@ struct drm_prime_attachment {
enum dma_data_direction dir;
};
+struct drm_gem_prime_page_flip_cb {
+ struct fence_cb base;
+ struct drm_device *dev;
+ uint32_t crtc_id;
+ uint32_t fb_id;
+ uint32_t flags;
+ uint64_t user_data;
+ struct drm_file *file_priv;
+};
+
static int drm_prime_add_buf_handle(struct drm_prime_file_private *prime_fpriv,
struct dma_buf *dma_buf, uint32_t handle)
{
@@ -316,6 +331,28 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =
{
.vunmap = drm_gem_dmabuf_vunmap,
};
+static const char *drm_gem_prime_get_driver_name(struct fence *fence)
+{
+ return "PRIME";
+}
+
+static const char *drm_gem_prime_get_timeline_name(struct fence *fence)
+{
+ return "prime.swonly";
+}
+
+static bool drm_gem_prime_enable_signaling(struct fence *fence)
+{
+ return true; /* SW signaling only */
+}
+
+static const struct fence_ops drm_gem_prime_fence_ops = {
+ .get_driver_name = drm_gem_prime_get_driver_name,
+ .get_timeline_name = drm_gem_prime_get_timeline_name,
+ .enable_signaling = drm_gem_prime_enable_signaling,
+ .wait = fence_default_wait,
+};
+
/**
* DOC: PRIME Helpers
*
@@ -680,6 +717,116 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
args->fd, &args->handle);
}
+/* Callback used by drm_gem_prime_page_flip(). Is added to a fence such that
+ * when the fence is signaled, page flip is requested with given parameters. */
+static void drm_gem_prime_page_flip_cb(struct fence *fence,
+ struct fence_cb *cb)
+{
+ struct drm_gem_prime_page_flip_cb *page_flip_cb =
+ container_of(cb, struct drm_gem_prime_page_flip_cb, base);
+
+ drm_mode_page_flip(page_flip_cb->dev,
+ page_flip_cb->crtc_id,
+ page_flip_cb->fb_id,
+ page_flip_cb->flags,
+ page_flip_cb->user_data,
+ page_flip_cb->file_priv);
+
+ kfree(cb);
+}
+
+/**
+ * drm_gem_prime_page_flip -
+ * helper library implementation of the page flip callback
+ *
+ * @dev: DRM device
+ * @file_priv: DRM file info
+ * @handle: buffer handle to fence
+ * @fb_id: FB to update to
+ * @crtc_id: CRTC to update
+ * @user_data: Returned as user_data field in in the vblank event struct
+ * @flags: Flags modifying page flip behavior, same as drm_mode_page_flip.
+ *
+ * This is the implementation of the prime_page_flip function for GEM drivers
+ * using the PRIME helpers.
+ */
+int drm_gem_prime_page_flip(struct drm_device *dev,
+ struct drm_file *file_priv, uint32_t handle,
+ uint32_t fb_id, uint32_t crtc_id,
+ uint64_t user_data, uint32_t flags)
+{
+ int ret;
+
+ struct dma_buf *dmabuf;
+ struct fence *oldfence;
+ struct drm_prime_fence *fence;
+ struct drm_gem_prime_page_flip_cb *page_flip_cb;
+ struct drm_prime_member *member;
+ struct drm_prime_fence_ctx *fctx;
+
+ mutex_lock(&file_priv->prime.lock);
+
+ member = drm_prime_lookup_member_by_handle(&file_priv->prime,
+ handle);
+ if (!member) {
+ /* Buffer is not a member of PRIME */
+ ret = -EINVAL;
+ goto out;
+ }
+
+ dmabuf = member->dma_buf;
+ fctx = &member->fctx;
+
+ /* Clear out old fence callbacks */
+ oldfence = reservation_object_get_excl(dmabuf->resv);
+ if (oldfence)
+ fence_signal(oldfence);
+
+ /* Create and initialize new fence */
+ fence = kmalloc(sizeof(*fence), GFP_KERNEL);
+ if (!fence) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ spin_lock_init(&fence->lock);
+ fence_init(&fence->base, &drm_gem_prime_fence_ops, &fence->lock,
+ fctx->context, fctx->seqno++);
+
+ /* Create and initialize new page flip callback */
+ page_flip_cb = kmalloc(sizeof(*page_flip_cb), GFP_KERNEL);
+ if (!page_flip_cb) {
+ ret = -ENOM
[PATCH drm 5/6] drm: add prime_page_flip() driver function
From: agoins
Adds prime_page_flip() to struct drm_driver, intended to be a function to
schedule a flip in response to a fence being signaled.
Makes drivers use drm_gem_prime_page_flip() helper implementation.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
drivers/gpu/drm/armada/armada_drv.c | 1 +
drivers/gpu/drm/exynos/exynos_drm_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/imx/imx-drm-core.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 +
drivers/gpu/drm/omapdrm/omap_drv.c | 1 +
drivers/gpu/drm/qxl/qxl_drv.c | 1 +
drivers/gpu/drm/radeon/radeon_drv.c | 1 +
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 +
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 1 +
drivers/gpu/drm/shmobile/shmob_drm_drv.c| 1 +
drivers/gpu/drm/sti/sti_drv.c | 1 +
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/udl/udl_drv.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
include/drm/drmP.h | 5 +
18 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index ef58774..0def3a1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -512,6 +512,7 @@ static struct drm_driver kms_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .prime_page_flip = drm_gem_prime_page_flip,
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = amdgpu_gem_prime_pin,
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index 77ab93d..ecf97cb 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -203,6 +203,7 @@ static struct drm_driver armada_drm_driver = {
.gem_free_object= armada_gem_free_object,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .prime_page_flip= drm_gem_prime_page_flip,
.gem_prime_export = armada_gem_prime_export,
.gem_prime_import = armada_gem_prime_import,
.dumb_create= armada_gem_dumb_create,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 09c4c6a..0f9ceeb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -459,6 +459,7 @@ static struct drm_driver exynos_drm_driver = {
.dumb_destroy = drm_gem_dumb_destroy,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .prime_page_flip= drm_gem_prime_page_flip,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_get_sg_table = exynos_drm_gem_prime_get_sg_table,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b1f1dec..3ca7233 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1724,6 +1724,7 @@ static struct drm_driver driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .prime_page_flip = drm_gem_prime_page_flip,
.gem_prime_export = i915_gem_prime_export,
.gem_prime_import = i915_gem_prime_import,
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
b/drivers/gpu/drm/imx/imx-drm-core.c
index 64f16ea..d087b1f 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -480,6 +480,7 @@ static struct drm_driver imx_drm_driver = {
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .prime_page_flip= drm_gem_prime_page_flip,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index d170131..f40a222 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -988,6 +988,7 @@ static struct drm_driver msm_driver = {
.dumb_destroy = drm_gem_dumb_destroy,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+ .prime_page_flip= drm_gem_prime_page_flip,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = msm_gem_prime_pin,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b/dr
[PATCH drm 6/6] drm: add DRM_IOCTL_PRIME_PAGE_FLIP
From: agoins
Adds DRM_IOCTL_PRIME_PAGE_FLIP, a new PRIME ioctl that uses DRM driver
function prime_page_flip() to request a DRM page flip in response to an
exclusive fence being signaled on a PRIME DMA-BUF's associated reservation
object.
drm_internal.h:
Add declaration for drm_prime_page_flip_ioctl()
drm_ioctl.c:
DRM_IOCTL_DEF DRM_IOCTL_PRIME_PAGE_FLIP.
drm_prime.c:
Define drm_prime_page_flip_ioctl().
drm.h:
Define struct drm_prime_page_flip. Parameter struct from
DRM_IOCTL_PRIME_PAGE_FLIP.
Define DRM_IOCTL_PRIME_PAGE_FLIP.
Signed-off-by: Alex Goins
---
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 1 +
drivers/gpu/drm/drm_prime.c| 20
include/uapi/drm/drm.h | 10 ++
4 files changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 43cbda3..eb82775 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -45,6 +45,8 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void
*data,
struct drm_file *file_priv);
int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+int drm_prime_page_flip_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
void drm_prime_init_file_private(struct drm_prime_file_private *prime_fpriv);
void drm_prime_destroy_file_private(struct drm_prime_file_private
*prime_fpriv);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 8ce2a0c..e89bfef 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -632,6 +632,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_PRIME_PAGE_FLIP, drm_prime_page_flip_ioctl,
DRM_MASTER|DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 175bf4a..094698d 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -827,6 +827,26 @@ out:
}
EXPORT_SYMBOL(drm_gem_prime_page_flip);
+int drm_prime_page_flip_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_prime_page_flip *args = data;
+
+ if (!drm_core_check_feature(dev, DRIVER_PRIME))
+ return -EINVAL;
+
+ if (!dev->driver->prime_page_flip)
+ return -ENOSYS;
+
+ /* check flags are valid */
+ if (args->flags & ~DRM_PRIME_PAGE_FLIP_FLAGS)
+ return -EINVAL;
+
+ return dev->driver->prime_page_flip(dev, file_priv,
+ args->handle, args->fb_id, args->crtc_id,
+ args->user_data, args->flags);
+}
+
/**
* drm_prime_pages_to_sg - converts a page array into an sg list
* @pages: pointer to the array of page pointers to convert
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..0c2a5f4 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -679,6 +679,15 @@ struct drm_prime_handle {
__s32 fd;
};
+#define DRM_PRIME_PAGE_FLIP_FLAGS DRM_MODE_PAGE_FLIP_FLAGS
+struct drm_prime_page_flip {
+ __u32 handle;
+ __u32 fb_id;
+ __u32 crtc_id;
+ __u32 flags;
+ __u64 user_data;
+};
+
#include
#define DRM_IOCTL_BASE 'd'
@@ -738,6 +747,7 @@ struct drm_prime_handle {
#define DRM_IOCTL_PRIME_HANDLE_TO_FDDRM_IOWR(0x2d, struct drm_prime_handle)
#define DRM_IOCTL_PRIME_FD_TO_HANDLEDRM_IOWR(0x2e, struct drm_prime_handle)
+#define DRM_IOCTL_PRIME_PAGE_FLIP DRM_IOWR(0x2f, struct
drm_prime_page_flip)
#define DRM_IOCTL_AGP_ACQUIRE DRM_IO( 0x30)
#define DRM_IOCTL_AGP_RELEASE DRM_IO( 0x31)
--
1.9.1
[PATCH drm 4/6] drm: add drm_gem_prime_page_flip() helper
On Thu, Oct 22, 2015 at 01:00:57PM -0700, Alex Goins wrote:
> From: agoins
>
> Adds drm_gem_prime_page_flip(), a helper implementation of
> prime_page_flip() to be used by DRM drivers.
>
> Signed-off-by: Alex Goins
> ---
> drivers/gpu/drm/drm_prime.c | 147
>
> include/drm/drmP.h | 3 +
> 2 files changed, 150 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 2956a65..175bf4a 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -61,6 +61,11 @@
> * use the drm_gem_prime_{import,export} helpers.
> */
>
> +struct drm_prime_fence {
> + struct fence base;
> + spinlock_t lock;
> +};
> +
> struct drm_prime_fence_ctx {
> uint32_t context;
> uint32_t seqno;
> @@ -78,6 +83,16 @@ struct drm_prime_attachment {
> enum dma_data_direction dir;
> };
>
> +struct drm_gem_prime_page_flip_cb {
> + struct fence_cb base;
> + struct drm_device *dev;
> + uint32_t crtc_id;
> + uint32_t fb_id;
> + uint32_t flags;
> + uint64_t user_data;
> + struct drm_file *file_priv;
> +};
> +
> static int drm_prime_add_buf_handle(struct drm_prime_file_private
> *prime_fpriv,
> struct dma_buf *dma_buf, uint32_t handle)
> {
> @@ -316,6 +331,28 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
> = {
> .vunmap = drm_gem_dmabuf_vunmap,
> };
>
> +static const char *drm_gem_prime_get_driver_name(struct fence *fence)
> +{
> + return "PRIME";
> +}
> +
> +static const char *drm_gem_prime_get_timeline_name(struct fence *fence)
> +{
> + return "prime.swonly";
> +}
> +
> +static bool drm_gem_prime_enable_signaling(struct fence *fence)
> +{
> + return true; /* SW signaling only */
> +}
> +
> +static const struct fence_ops drm_gem_prime_fence_ops = {
> + .get_driver_name = drm_gem_prime_get_driver_name,
> + .get_timeline_name = drm_gem_prime_get_timeline_name,
> + .enable_signaling = drm_gem_prime_enable_signaling,
> + .wait = fence_default_wait,
> +};
> +
> /**
> * DOC: PRIME Helpers
> *
> @@ -680,6 +717,116 @@ int drm_prime_fd_to_handle_ioctl(struct drm_device
> *dev, void *data,
> args->fd, &args->handle);
> }
>
> +/* Callback used by drm_gem_prime_page_flip(). Is added to a fence such that
> + * when the fence is signaled, page flip is requested with given parameters.
> */
> +static void drm_gem_prime_page_flip_cb(struct fence *fence,
> +struct fence_cb *cb)
> +{
> + struct drm_gem_prime_page_flip_cb *page_flip_cb =
> + container_of(cb, struct drm_gem_prime_page_flip_cb, base);
> +
> + drm_mode_page_flip(page_flip_cb->dev,
> +page_flip_cb->crtc_id,
> +page_flip_cb->fb_id,
> +page_flip_cb->flags,
> +page_flip_cb->user_data,
> +page_flip_cb->file_priv);
> +
> + kfree(cb);
> +}
> +
> +/**
> + * drm_gem_prime_page_flip -
> + * helper library implementation of the page flip callback
> + *
> + * @dev: DRM device
> + * @file_priv: DRM file info
> + * @handle: buffer handle to fence
> + * @fb_id: FB to update to
> + * @crtc_id: CRTC to update
> + * @user_data: Returned as user_data field in in the vblank event struct
> + * @flags: Flags modifying page flip behavior, same as drm_mode_page_flip.
> + *
> + * This is the implementation of the prime_page_flip function for GEM drivers
> + * using the PRIME helpers.
> + */
> +int drm_gem_prime_page_flip(struct drm_device *dev,
> + struct drm_file *file_priv, uint32_t handle,
> + uint32_t fb_id, uint32_t crtc_id,
> + uint64_t user_data, uint32_t flags)
> +{
> + int ret;
> +
> + struct dma_buf *dmabuf;
> + struct fence *oldfence;
> + struct drm_prime_fence *fence;
> + struct drm_gem_prime_page_flip_cb *page_flip_cb;
> + struct drm_prime_member *member;
> + struct drm_prime_fence_ctx *fctx;
> +
> + mutex_lock(&file_priv->prime.lock);
> +
> + member = drm_prime_lookup_member_by_handle(&file_priv->prime,
> +handle);
> + if (!member) {
> + /* Buffer is not a member of PRIME */
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + dmabuf = member->dma_buf;
> + fctx = &member->fctx;
> +
> + /* Clear out old fence callbacks */
> + oldfence = reservation_object_get_excl(dmabuf->resv);
> + if (oldfence)
> + fence_signal(oldfence);
This looks really strange - you force-complete the fence already attached
(which might be from any driver attached to this dma-buf)?
The creator of the fence is supposed to complete it when whatever async
operation that is scheduled and which is using this dma-buf is done. So
the way to
[PATCH drm 4/6] drm: add drm_gem_prime_page_flip() helper
Thanks for the quick feedback, Daniel! >This looks really strange - you force-complete the fence already attached >(which might be from any driver attached to this dma-buf)? >The creator of the fence is supposed to complete it when whatever async >operation that is scheduled and which is using this dma-buf is done. So the >way to go about this here is to take out the excl fence from the reservation >object, and wait for it to complete. Yeah, true. I had just added that as a contingency - in reality this ioctl is never called (by my changes) on a buffer with an unsignaled fence. You're right that a wait would be better. I'll have it changed the revised patch set if we end up keeping the ioctl. >But if your goal is to only fix up the page_flip path, and only for i915 as >the display driver I'd be fine with the atomic modesetting path if i915 supported async atomic updates; really I just need a way to fence flips between two shared buffers. While i915 is the main target, we'd ideally like to support this with other devices/drivers as well. >For your limited use-case it really would be simplest to fix up the i915 mmio >flip code to handle fences attached to dma-bufs, and teach the nvidia blob to >attach a suitable exclusive fence somehow. This sounds like a pretty good solution - as long as the semantics stay the same as to who attaches the fence, transitioning from this to an atomic modesetting solution could be relatively painless. I'd need a way to query if a driver supports fencing on page_flip and/or async atomic modesetting in order to get graceful fallback on X. >Wrt merge coordination: RSN (well that's the case since months) all the legacy >pageflip code will be ripped out from i915 and replaced by async atomic >updates). So except for a proof-of-concept I'd prefer if we just implement >this in the atomic codepaths directly. What kind of timeline are we looking at for i915 supporting async atomic updates? Will the legacy pageflip code be ripped out at the same time, or will there be a transition period? With the ability to query for fenced page_flip / fenced async atomic modesetting, I can probably get X to use the best available method. I should be able to test a fenced async atomic update implementation using dGPU + Tegra PRIME prior to i915 supporting it, but I'd be interested to hear from those more well versed on that path as to how they'd like it implemented. Thanks, Alex
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214
--- Comment #34 from Barto ---
Craig Tooper has made a suggestion who solves the problem :
the idea is to "remove" the unsupported CPU features, by adding "-sse4.1" in
MAttrs object when "util_cpu_caps.has_sse4_1 == false",
so if I add this to Jose's patch the bug is solved :
+ if (!util_cpu_caps.has_sse4_1) {
+#if HAVE_LLVM >= 0x0304
+ MAttrs.push_back("-sse4.1");
+#else
+ MAttrs.push_back("-sse41");
+#endif
+ }
this logic is not really natural for a developper who wants to use llvm lib,
this developper would think that llvm will never use an unsupported cpu feature
if this developper only passes good cpu features to the compiler,
it seems that llvm will try to use by himself SSE4.1 even if the developper
didn't add explicitely "+sse4.1" in his source code,
we have this problem because llvm 3.7.0 treats pentium dual core cpu as
"penryn" cpu, "penryn" supports SSE4 but not pentium dual core,
in my logic llvm should be more stric, rigorous when he tries to associate a
cpu with a cpu name, a cpu name should reflect exactly the cpu features,
maybe a better solution would be to create a new cpu name in llvm source code,
a cpu name who targets only cpu family 6 model 23 : "dualcore" in order to
avoid this SSE4 problem,
but I am not a llvm specialist
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/05c22ce0/attachment.html>
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214
--- Comment #35 from Barto ---
Created attachment 119117
--> https://bugs.freedesktop.org/attachment.cgi?id=119117&action=edit
patch who solves the bug by removing explicitely SSE4 when the CPU doesn't
support SSE4
this the modified version of the Jose's patch,
this patch who solves the bug by removing explicitely SSE4 when the CPU doesn't
support SSE4,
the new lines :
+ if (!util_cpu_caps.has_sse4_1) {
+#if HAVE_LLVM >= 0x0304
+ MAttrs.push_back("-sse4.1");
+#else
+ MAttrs.push_back("-sse41");
+#endif
+ }
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/d6cd6ee0/attachment.html>
[Bug 92214] Flightgear crashes during splashboot with R600 driver, LLVM 3.7.0 and mesa 11.0.2
https://bugs.freedesktop.org/show_bug.cgi?id=92214 --- Comment #36 from Roland Scheidegger --- I don't think llvm's behavior makes sense. We got the cpu name from llvm, that we have to manually list cpu features which it CAN'T use when just using that name then is imho crazy. I've updated the llvm bug accordingly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/0e542ef6/attachment.html>
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #58 from Kevin McCormack --- Alex, have you had a chance to look at the vbios files? I think that Michael Larabel of Phoronix is also having difficulties with his R9 270X card. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/3ebd4533/attachment.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 --- Comment #5 from Shawn Starr --- Further info: Top show this: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 10090 spstarr 20 0 7763256 5.236g 110252 S 108.6 16.7 160:54.37 ShooterGame 1315 spstarr 20 0 352204 82332 38544 R 100.3 0.2 15:38.57 Xorg 16140 root 20 0 0 0 0 R 100.0 0.0 0:55.90 kworker/1:1 1572 spstarr9 -11 784400 33620 27204 S 2.0 0.1 8:39.58 pulseaudio -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/23275697/attachment.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 --- Comment #6 from Shawn Starr --- Created attachment 119119 --> https://bugs.freedesktop.org/attachment.cgi?id=119119&action=edit perf top -g -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/533e7233/attachment.html>
[PATCH 1/8] ASoC : dwc : add check for master/slave format
On Thu, Oct 08, 2015 at 12:12:34PM -0400, Alex Deucher wrote: > From: Maruthi Srinivas Bayyavarapu > > DW i2s controller's master/slave config can be read from a > read-only register. Machine driver can try to set a master/slave > format on cpu-dai using 'set_fmt' of dai ops. A check is added to > verify codec is master when dwc is slave and vice-versa. > > Signed-off-by: Maruthi Bayyavarapu > --- I can't apply this, you've not added a Signed-off-by for code sent by someone else as covered in SubmittingPatches. Please also try to use subject lines matching the style for the subsystem. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/1d27045b/attachment-0001.sig>
[PATCH 0/8] Add ASoC support for AMD APUs [v4]
On Tue, Oct 20, 2015 at 10:19:38AM +1000, Dave Airlie wrote: > On 20 October 2015 at 10:14, Mark Brown wrote: > > Please don't send content free pings and please allow a reasonable time > > for review. People get busy, go on holiday, attend conferences and so > > on so unless there is some reason for urgency (like critical bug fixes) > > please allow at least a couple of weeks for review. Sending content > > free pings just adds to the mail volume (if they are seen at all) and if > > something has gone wrong you'll have to resend the patches anyway. > To be honest, maintainers also forget, get busy doing other things, > get diverted down rabbit holes, > get tasked to do something else. We also don't know when maintainers > are at conferences, > or on holidays. This is why I'm saying leave a reasonable amount of time, for relatively short delays on non-critical stuff the most likely explanation is that something like the above has happened and there is no problem. > I don't think repinging patches after 11 days is that unreasonable if > you've gotten replies quicker > than that previously. It's a waste of time, if it's just a delay then at best what's going to happen is that the mail is going to get threaded in with the original posting and make handling the series take longer when it does get looked at (something made worse by the tendency for content free pings to do things like not bother trimming context or top post). If things have been dropped then all it does is require that the maintainer ask that the patch be resent again which just makes things take even longer. Either way a content free ping, especially a rapid one, is at best slowing things down. When people chase me to review their patches ahead of other people's without some reason for it my standard response is to defer reviewing those changes, I don't want to create the impression that this is a good way for people to get their work prioritised. If people are taking the fact that sometimes responses come faster as a sign that content free pings are a good idea then I begin to see why some maintainers are just generally unresponsive. :( > I'd prefer a content free ping, rather than another round of the > patches with two spelling mistakes > fixed etc. It's very easy to just discard old serieses and never even look at them, we have to do that all the time anyway when other people help out with review and identify issues. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/1e95f98a/attachment.sig>
[PATCH 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel
On Tue, Jul 28, 2015 at 6:37 PM, Bjorn Andersson wrote: > From: Werner Johansson > > This adds support for the Sharp panel found on the Qualcomm > Snapdragon 800 Dragonboard (APQ8074) > > Signed-off-by: Werner Johansson > Signed-off-by: Bjorn Andersson Anything holding this back from being merged? I have a bunch more panel drivers and would like to know if this is acceptable before pushing more. Regards, Bjorn
[PATCH 0/2] CRTC background color support for i915
Recent Intel platforms (SKL+) support a background canvas color below the hardware planes. This background color can be seen on areas not covered by a plane, or if we program the hardware with various plane blending modes. Chandra Konduru previously took a stab at writing i915 patches to support this feature, but we were in the middle of the great i915 atomic transition at the time, so there was too much driver churn to ever get them in. Now that i915 atomic work has settled down a bit, let's make another attempt to get this feature support in. One of the items that came up in review of Chandra's earlier patches was that although userspace needs to pass a color value to the kernel, it would be best if userspace didn't have to care about the formatting of color values used by the underyling hardware (i.e., number of bits, ordering of R,G,B components, etc.). The first patch here aims to address that by setting up an 'RGBA' property type, specifying a fixed bit layout (with 16bpc), and providing helper macros to fetch specific color bits with the desired precision. This should prevent drivers from trying to shove property values directly into the hardware, which could lead to incompatibility between platforms if we aren't careful. A libdrm patch that provides helper macros to build color values of the appropriate format will be provided as a followup, as will an update to the i-g-t test for this feature (which is surprisingly already merged, even though the kernel support isn't there yet). Cc: dri-devel at lists.freedesktop.org Cc: Chandra Konduru Matt Roper (2): drm: Add infrastructure for CRTC background color property drm/i915/skl: Add support for pipe background color Documentation/DocBook/gpu.tmpl | 10 +++- drivers/gpu/drm/drm_atomic.c | 4 +++ drivers/gpu/drm/drm_crtc.c | 33 drivers/gpu/drm/i915/i915_debugfs.c | 9 +++ drivers/gpu/drm/i915/i915_reg.h | 10 drivers/gpu/drm/i915/intel_display.c | 43 +++ include/drm/drm_crtc.h | 49 7 files changed, 157 insertions(+), 1 deletion(-) -- 2.1.4
[PATCH 1/2] drm: Add infrastructure for CRTC background color property
To support CRTC background color, we need a way of communicating RGB
color values to the DRM. However there is often a mismatch between how
userspace wants to represent the color value vs how it must be
programmed into the hardware; this mismatch can easily lead to
non-obvious bugs. Let's create a property type that standardizes the
user<->kernel format and add some macros that allow drivers to extract
the bits they care about without having to worry about the internal
representation.
These properties are still exposed to userspace as range properties, so
the only userspace change we need are some helpers to build RGBA values
appropriately.
Cc: dri-devel at lists.freedesktop.org
Cc: Chandra Konduru
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_atomic.c | 4
drivers/gpu/drm/drm_crtc.c | 33 +
include/drm/drm_crtc.h | 49
3 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7bb3845..688ca75 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -415,6 +415,8 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
if (property == config->prop_active)
state->active = val;
+ else if (property == config->prop_background_color)
+ state->background_color.v = val;
else if (property == config->prop_mode_id) {
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
@@ -450,6 +452,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+ else if (property == config->prop_background_color)
+ *val = state->background_color.v;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e54660a..1e0dd09 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3807,6 +3807,30 @@ struct drm_property *drm_property_create_bool(struct
drm_device *dev, int flags,
EXPORT_SYMBOL(drm_property_create_bool);
/**
+ * drm_property_create_rgba - create a new RGBA property type
+ * @dev: drm device
+ * @flags: flags specifying the property type
+ * @name: name of the property
+ *
+ * This creates a new generic drm property which can then be attached to a drm
+ * object with drm_object_attach_property. The returned property object must be
+ * freed with drm_property_destroy.
+ *
+ * Userspace should use the DRM_RGBA() macro to build values with the proper
+ * bit layout.
+ *
+ * Returns:
+ * A pointer to the newly created property on success, NULL on failure.
+ */
+struct drm_property *drm_property_create_rgba(struct drm_device *dev, int
flags,
+ const char *name)
+{
+ return drm_property_create_range(dev, flags, name,
+0, GENMASK_ULL(63, 0));
+}
+EXPORT_SYMBOL(drm_property_create_rgba);
+
+/**
* drm_property_add_enum - add a possible value to an enumeration property
* @property: enumeration property to change
* @index: index of the new enumeration
@@ -5778,6 +5802,15 @@ struct drm_property
*drm_mode_create_rotation_property(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_mode_create_rotation_property);
+struct drm_property
+*drm_mode_create_background_color_property(struct drm_device *dev)
+{
+ return drm_property_create_range(dev, DRM_MODE_PROP_ATOMIC,
+"background_color",
+0, GENMASK_ULL(63, 0));
+}
+EXPORT_SYMBOL(drm_mode_create_background_color_property);
+
/**
* DOC: Tile group
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3f0c690..64f3e62 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -251,6 +251,45 @@ struct drm_bridge;
struct drm_atomic_state;
/**
+ * drm_rgba_t - RGBA property value type
+ *
+ * Structure to abstract away the representation of RGBA values with precision
+ * up to 16 bits per color component. This is primarily intended for use with
+ * DRM properties that need to take a color value since we don't want userspace
+ * to have to worry about the bit layout expected by the underlying hardware.
+ *
+ * We wrap the value in a structure here so that the compiler will flag any
+ * accidental attempts by driver code to directly attempt bitwise operations
+ * that could potentially misinterpret the value. Drivers should instead use
+ * the DRM_RGBA_{RED,GREEN,BLUE,ALPHA}BITS() macros to obtain the component
+ * bits and then build values in the format their hardware expects.
+ */
+typedef struct {
+ uint64_t v;
+} drm_rgba_t;
+
+s
[PATCH 2/2] drm/i915/skl: Add support for pipe background color
SKL and BXT allow CRTC's to be programmed with a background/canvas color
below the programmable planes. Let's expose this as a property to allow
userspace to program a desired value.
This patch is based on earlier work by Chandra Konduru; unfortunately
the driver has evolved so much since his patches were written
(pre-atomic) that the functionality had to be pretty much completely
rewritten for the new i915 atomic internals.
Cc: Chandra Konduru
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper
---
Documentation/DocBook/gpu.tmpl | 10 -
drivers/gpu/drm/i915/i915_debugfs.c | 9
drivers/gpu/drm/i915/i915_reg.h | 10 +
drivers/gpu/drm/i915/intel_display.c | 43
4 files changed, 71 insertions(+), 1 deletion(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index c05d7df..40c0d49 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2819,7 +2819,7 @@ void intel_crt_init(struct drm_device *dev)
TBD
- i915
+ i915
Generic
"Broadcast RGB"
ENUM
@@ -2835,6 +2835,14 @@ void intel_crt_init(struct drm_device *dev)
TBD
+ CRTC
+ âbackground_colorâ
+ RGBA
+
+ CRTC
+ Background color of regions not covered by a
plane
+
+
SDVO-TV
âmodeâ
ENUM
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index a3b22bd..acb05e5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2977,6 +2977,15 @@ static int i915_display_info(struct seq_file *m, void
*unused)
crtc->base.cursor->state->crtc_h,
crtc->cursor_addr, yesno(active));
}
+ if (INTEL_INFO(dev)->gen >= 9 && pipe_config->base.active) {
+ drm_rgba_t background =
pipe_config->base.background_color;
+
+ seq_printf(m, "\tbackground color (10bpc): r=%x g=%x
b=%x\n",
+ background.v,
+ DRM_RGBA_REDBITS(background, 10),
+ DRM_RGBA_GREENBITS(background, 10),
+ DRM_RGBA_BLUEBITS(background, 10));
+ }
seq_printf(m, "\tunderrun reporting: cpu=%s pch=%s \n",
yesno(!crtc->cpu_fifo_underrun_disabled),
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ebf032..95ea394 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7562,6 +7562,16 @@ enum skl_disp_power_wells {
#define PIPE_CSC_POSTOFF_ME(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_ME,
_PIPE_B_CSC_POSTOFF_ME)
#define PIPE_CSC_POSTOFF_LO(pipe) _PIPE(pipe, _PIPE_A_CSC_POSTOFF_LO,
_PIPE_B_CSC_POSTOFF_LO)
+/* Skylake pipe bottom color */
+#define _PIPE_BOTTOM_COLOR_A0x70034
+#define _PIPE_BOTTOM_COLOR_B0x71034
+#define _PIPE_BOTTOM_COLOR_C0x72034
+#define PIPE_BOTTOM_GAMMA_ENABLE (1 << 31)
+#define PIPE_BOTTOM_CSC_ENABLE (1 << 30)
+#define PIPE_BOTTOM_COLOR_MASK 0x3FFF
+#define PIPE_BOTTOM_COLOR(pipe) _PIPE3(pipe, _PIPE_BOTTOM_COLOR_A, \
+ _PIPE_BOTTOM_COLOR_B, _PIPE_BOTTOM_COLOR_C)
+
/* MIPI DSI registers */
#define _MIPI_PORT(port, a, c) _PORT3(port, a, 0, c) /* ports A and C only */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1fc1d24..b00fca9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3332,6 +3332,8 @@ static void intel_update_pipe_config(struct intel_crtc
*crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc->base.state);
+ drm_rgba_t background = pipe_config->base.background_color;
+ uint32_t val;
/* drm_atomic_helper_update_legacy_modeset_state might not be called. */
crtc->base.mode = crtc->base.state->mode;
@@ -3368,6 +3370,26 @@ static void intel_update_pipe_config(struct intel_crtc
*crtc,
else if (old_crtc_state->pch_pfit.enabled)
ironlake_pfit_disable(crtc, true);
}
+
+ if (INTEL_INFO(dev)->gen >= 9) {
+ /* BGR 16bpc ==> RGB 10bpc */
+ val = DRM_RGBA_REDBITS(background, 10) << 20
+ | DRM_RGBA_GREENBITS(background, 10) << 10
+ | DRM_RGBA_BLUEBITS(background, 10);
+
+ /*
+* Set CSC and gamma for bottom color.
+*
+* FIXME: We turn these on unconditionally for now to match
+* how we've setup the various planes. Once the color
+* management framework
[PATCH libdrm] xf86drmMode: Add RGBA property helpers
Now that we've added an RGBA property type to the kernel that handles
RGBA values with a specific bit layout, let's add a userspace helper to
allow userspace to easily build values in the proper format.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Matt Roper
---
xf86drmMode.c | 36
xf86drmMode.h | 7 +++
2 files changed, 43 insertions(+)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index ab6b519..4bfd419 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1445,3 +1445,39 @@ drmModeDestroyPropertyBlob(int fd, uint32_t id)
destroy.blob_id = id;
return DRM_IOCTL(fd, DRM_IOCTL_MODE_DESTROYPROPBLOB, &destroy);
}
+
+/*
+ * Builds an RGBA 16bpc color value with bits laid out in the format expected
+ * by DRM RGBA properties. @bpc is the number of bits per component value
+ * being provided as parameters.
+ */
+uint64_t
+drmModeRGBA(unsigned bpc,
+ uint16_t red,
+ uint16_t green,
+ uint16_t blue,
+ uint16_t alpha)
+{
+ int shift;
+ uint64_t val;
+
+ if (bpc > 16)
+ return -ERANGE;
+
+ /*
+* If we were provided with fewer than 16 bpc, shift the value we
+* received into the most significant bits.
+*/
+ shift = 16 - bpc;
+
+ val = red << shift;
+ val <<= 16;
+ val |= green << shift;
+ val <<= 16;
+ val |= blue << shift;
+ val <<= 16;
+ val |= alpha << shift;
+
+ return val;
+}
+
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 4de7bbb..4aa4917 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -507,6 +507,13 @@ extern int drmModeCreatePropertyBlob(int fd, const void
*data, size_t size,
uint32_t *id);
extern int drmModeDestroyPropertyBlob(int fd, uint32_t id);
+extern uint64_t drmModeRGBA(unsigned bpc,
+ uint16_t red,
+ uint16_t green,
+ uint16_t blue,
+ uint16_t alpha);
+#define DRM_RGBA(r, g, b, a) drmModeRGBA(8, r, g, b, a)
+#define DRM_RGBA16161616(r, g, b, a) drmModeRGBA(16, r, g, b, a)
#if defined(__cplusplus)
}
--
2.1.4
[GIT PULL] On-demand device probing
On 22 October 2015 at 02:54, Rafael J. Wysocki wrote: > On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote: >> On 20 October 2015 at 18:04, Alan Stern wrote: >> > On Tue, 20 Oct 2015, Mark Brown wrote: >> > >> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote: >> >> >> >> > Furthermore, that applies only to devices that use synchronous suspend. >> >> > Async suspend is becoming common, and there the only restrictions are >> >> > parent-child relations plus whatever explicit requirements that drivers >> >> > impose by calling device_pm_wait_for_dev(). >> >> >> >> Hrm, this is the first I'd noticed that feature though I see the initial >> >> commit dates from January. >> > >> > Async suspend and device_pm_wait_for_dev() were added in January 2010, >> > not 2015! >> > >> >> It looks like most of the users are PCs at >> >> the minute but we should be using it more widely for embedded things, >> >> there's definitely some cases I'm aware of where it will allow us to >> >> remove some open coding. >> >> >> >> It does seem like we want to be feeding dependency information we >> >> discover for probing way into the suspend dependencies... >> > >> > Rafael has been thinking about a way to do this systematically. >> > Nothing concrete has emerged yet. >> >> This iteration of the series would make this quite easy, as >> dependencies are calculated before probes are attempted: >> >> https://lkml.org/lkml/2015/6/17/311 > > Well, if you know how to represent "links" between devices, the mechanism > introduced here doesn't really add much value, because in that case the > core knows what the dependencies are in the first place and can only > defer the probes that have to be deferred. By "here" you mean what you are proposing for ordering device suspends, or on-demand probing? If you meant that probing on-demand is unneeded if we already have dependency information, I agree with you and that's why I only pushed forward on-demand, as the approach linked above introduced some duplication when inferring the dependencies. Maybe that could be avoided without too much refactoring. In any case, Thierry mentioned the other day in #tegra that one could also collect dependency information as a follow up to the on-demand series by calling device_depend() or such instead of of_device_probe(). Regards, Tomeu > Thanks, > Rafael > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 11/25] drm/i915: Register color correction capabilities
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 8afda45..613bee2 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -789,6 +789,8 @@ struct intel_device_info {
> > u8 num_sprites[I915_MAX_PIPES];
> > u8 gen;
> > u8 ring_mask; /* Rings supported by the HW */
> > + u16 num_samples_after_ctm;
> > + u16 num_samples_before_ctm;
> thought we agreed last week that num_samples was going to be
> removed. May be ok to handle in a later patch unless
> someone has strong objection.
This is for the reporting out of platform capability and is still
needed as userspace needs to know the recommended table size so that it
can resample as necessary.
Rob
[GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > But that's moot currently because Greg believes that the time spent > probing devices at boot time could be reduced enough so that the order > in which devices are probed becomes irrelevant. IME that would have to > be under 200ms so that the user doesn't notice and that's unicorn-far > from any bootlog I have ever seen. But as no one has actually produced a bootlog, how do you know that? Where exactly is your time being spent? What driver is causing long delays? Why is the long-delay-drivers not being done in their own thread? And most importantly, why are you ignoring the work that people did back in 2008 to solve the issue on other hardware platforms? > Given that downstreams are already carrying as many hacks as they > could think of to speed total boot up, I think this is effectively > telling them to go away. No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to solve-the-random-issue-i'm-having type patch by putting random calls in semi-random subsystems all over the kernel. And when I ask for real data, you respond with the fact that you aren't trying to speed up boot time here at all, so what am I supposed to think other than that you don't care enough to do the real work and are trying to hack the driver core up instead. > Sorry for the rant, No apologies needed, it's cathartic at times :) thanks, greg k-h
Alternative approach to solve the deferred probe
Hi Russell,
On 10/21/2015 09:28 PM, Russell King - ARM Linux wrote:
> On Wed, Oct 21, 2015 at 09:13:48PM +0300, Grygorii Strashko wrote:
>> But I worry a bit (and that my main point) about these few additional
>> rounds of deferred device probing which I have right now and which allows
>> some of drivers to finish, finally, their probes successfully.
>> With proposed change I'll get more messages in boot log, but some of
>> them will belong to drivers which have been probed successfully and so,
>> they will be not really useful.
>
> Then you haven't properly understood my proposal.
>
> I want to get rid of all the "X deferred its probing" messages up until
> the point that we set the "please report deferred probes" flag.
>
> That _should_ mean that all the deferred probing that goes on becomes
> _totally_ silent and becomes hidden (unless you really want to see it,
> in which case we can make a debug option which turns it on) up until
> we're at the point where we want to enter userspace.
>
> At that point, we then report into the kernel log which devices are
> still deferring and, via appropriately placed dev_warn_deferred(),
> the reasons why the devices are being deferred.
>
> So, gone will be all the messages earlier in the log about device X
> not having a GPIO/clock/whatever because the device providing the
> GPIO/clock/whatever hasn't been probed.
>
> If everything is satisfied by the time we run this last round (again,
> I'm not using a three line sentence to describe exactly what I mean,
> I'm sure you know by now... oops, I just did) then the kernel will
> report nothing about any deferrals. That's _got_ to be an improvement.
Sorry Master, but you really don't need to spend so much time typing the
same things three times - I understand what are you trying to do :(
I did my comments with assumption that it's not officially prohibited/deprecated
to register drivers (and execute probes) from late_initcall() layer
(just recommended) and there are still bunch of drivers which are doing this.
Now I see that it's not a recommendation any more, and deferred_probe_initcall()
might be a good place to activate driver_deferred_probe_report if goal is to
identify and fix such drivers.
Sorry for your time.
>
>>
>> As result, I think, the most important thing is to identify (or create)
>> some point during kernel boot when it will be possible to say that all
>> built-in drivers (at least) finish their probes 100% (done or defer).
>>
>> Might be do_initcalls() can be updated (smth like this):
>> static void __init do_initcalls(void)
>> {
>> int level;
>>
>> for (level = 0; level < ARRAY_SIZE(initcall_levels) - 1; level++)
>> do_initcall_level(level);
>>
>> +wait_for_device_probe();
>> +/* Now one final round, reporting any devices that remain deferred */
>> +driver_deferred_probe_report = true;
>> +driver_deferred_probe_trigger();
>> +wait_for_device_probe();
>> }
>>
>> Also, in my opinion, it will be useful if this debugging feature will be
>> optional.
>
> I wonder why you want it optional... so I'm going to guess and cover
> both cases I can think of below to head off another round of reply on
> this point (sorry if this sucks eggs.)
>
> I don't see it as being optional, because it's going to be cheap to run
> in the case of a system which has very few or no errors - which is what
> you should have for production systems, right?
>
Also, I've spend some time today testing your proposal - hope you'll find
results
useful.
I've applied truncated version of your patch (diff below) on TI's 4.1 kernel and
run few tests (log is below) on dra7-evm/am43xx-gpevm - K4.1 is not far away
from LKML,
so I assume this test is valid. Overall boot process consists from two stages:
kernel boot and modules loading.
My Changes:
- only really_probe() modified to show deferred device/drivers
>From the log I can see additional messages in log when modules are loading,
because driver_deferred_probe_report is still true - dwc3 probes were deferred,
but then finally succeeded.
So, as you've mentioned, it seems a good thing to deactivate
driver_deferred_probe_report and
provide user with ability to turn it on again (and probably re-trigger deferred
device probing).
I've found no issues during Kernel boot (built-in) time, new messages are
displayed only
if probe is failed for some drivers:
[3.219700] == deferred_probe_initcalll
[3.226820] platform omapdrm.0: Driver omapdrm requests probe deferral
[3.233378] platform omapdrm.0: deferring probe: Driver omapdrm
requests probe deferral
[3.242084] dra7evm-tpd12s015 encoder at 1: failed to parse CT CP HPD gpio
[3.248737] platform encoder at 1: Driver dra7evm-tpd12s015 requests probe
deferral
[3.256168] platform encoder at 1: deferring probe: Driver
dra7evm-tpd12s015 requests probe deferral
[3.265763] connector-hdmi connector at 1: failed to find v
[GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:53:31AM -0700, Frank Rowand wrote: > On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > >> But that's moot currently because Greg believes that the time spent > >> probing devices at boot time could be reduced enough so that the order > >> in which devices are probed becomes irrelevant. IME that would have to > >> be under 200ms so that the user doesn't notice and that's unicorn-far > >> from any bootlog I have ever seen. > > > > But as no one has actually produced a bootlog, how do you know that? > > Where exactly is your time being spent? What driver is causing long > > delays? Why is the long-delay-drivers not being done in their own > > thread? And most importantly, why are you ignoring the work that people > > did back in 2008 to solve the issue on other hardware platforms? > > > >> Given that downstreams are already carrying as many hacks as they > >> could think of to speed total boot up, I think this is effectively > >> telling them to go away. > > > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > > solve-the-random-issue-i'm-having type patch by putting random calls in > > semi-random subsystems all over the kernel. > > > > And when I ask for real data, you respond with the fact that you aren't > > trying to speed up boot time here at all, so what am I supposed to think > > I also had the understanding that this patch series was about improving > boot time. But I was kindly corrected that the behavior change was > getting the panel displaying stuff at an earlier point in the boot sequence, > _not_ completing the entire boot faster. > > The claim for the current series, in patch 0 in v7 is: > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. > > Just to get side-tracked, one other approach at ordering to reduce > deferrals reported a modest boot time reduction for four boards and a > very slight boot time increase for one other board.) The report of boot > times with that approach was in: > > http://article.gmane.org/gmane.linux.drivers.devicetree/133010 > > from Alexander Holler. > > I have not searched further to see if there is more data of boot time > reductions from any of the other attempts to change driver binding > order to move dependencies before use of a resource. But whether > there is a performance improvement or not, there continues to be > a stream of developers creatively impacting the binding order for > their specific driver(s) or board. So it seems that maybe there > is an underlying problem, or we don't have adequate documentation > explaining how to avoid a need to order bindings, or the > documentation exists and is not being read. > > I have been defaulting to the position that has been asserted by > the device tree maintainters, that probe deferrals work just fine > for at least the majority of cases (and is the message I have been > sharing in my conference presentations about device tree). But I > suspect that there is at least a small minority of cases that are not > well served by probe deferral. (Not to be read as an endorsement of > this specific patch series, just a generic observation.) I agree, there might be some small numbers that this is a problem for, and if so, great, show us the boot logs where things are taking up all of the time, and we can work on resolving those issues. But without hard numbers / details, this all is just random hand-waving, and I don't like making core kernel changes on that basis. And no one else should ever want us to do that either. thanks, greg k-h
[GIT PULL] On-demand device probing
On 21 October 2015 at 23:50, Frank Rowand wrote: > On 10/21/2015 2:12 PM, Rob Herring wrote: >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand >> wrote: >>> On 10/21/2015 9:27 AM, Mark Brown wrote: On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: >> To be clear, I was saying that this series should NOT affect total >> boot times much. > I'm confused. If I understood correctly, improving boot time was > the key justification for accepting this patch set. For example, > from "[PATCH v7 0/20] On-demand device probing": > >I have a problem with the panel on my Tegra Chromebook taking longer >than expected to be ready during boot (Stéphane Marchesin reported > what >is basically the same issue in [0]), and have looked into ordered >probing as a better way of solving this than moving nodes around in the >DT or playing with initcall levels and linking order. > >... > >With this series I get the kernel to output to the panel in 0.5s, >instead of 2.8s. Overall boot time and time to get some individual built in component up and running aren't the same thing - what this'll do is get things up more in the link order of the leaf consumers rather than deferring those leaf consumers when their dependencies aren't ready yet. >>> >>> Thanks! I read too much into what was being improved. >>> >>> So this patch series, which on other merits may be a good idea, is as >>> a by product solving a specific ordering issue, moving successful panel >>> initialization to an earlier point in the boot sequence, if I now >>> understand more correctly. >>> >>> In that context, this seems like yet another ad hoc way of causing the >>> probe order to change in a way to solves one specific issue? Could >>> it just as likely move the boot order of some other driver on some >>> other board later, to the detriment of somebody else? >> >> Time to display on is important for many products. Having the console >> up as early as possible is another case. CAN bus is another. This is a >> real problem that is not just bad drivers. > > Yes, I agree. > > What I am seeing is that there continues to be a need for the ability > to explicitly order at least some driver initialization (at some > granularity), despite the push back against explicit ordering that > has been present in the past. The important point that I have struggled to explain is that right now for downstreams to influence the order in which devices are probed, they have to carry a substantial amount of patches that cannot be ever upstreamed. This fiddling with initcall levels and link order means changing files that are very frequently changing, increasing the amount of work when rebasing and increasing the probability of regressions after a rebase. This just adds up to other shortcomings of mainline and ends up with the net result of vendors getting stuck with 3.4 kernels on SoCs that start production in 2015. Another consequence is that vendors don't have a chance to upstream their stuff even if they cared. The overarching goal of the project I'm in is to reduce those shortcomings that downstreams have to workaround, to facilitate their involvement upstream. With this series, the order in which devices are probed becomes the order in which they were registered, which is the order in which the devices appear in the FW description of the hw or in the board files (much more predictable, which makes for a more robust process). For DT and board files, which cover a good part of the consumer devices shipped today with Linux, the downstream could just change the order of device nodes and get their display or whatever to probe before any other devices. And even if downstream's hw has a SoC .dtsi that exists in mainline, they could add a step to their build process that automatically reorders the nodes to avoid carrying changes to that DT fragment. But that's moot currently because Greg believes that the time spent probing devices at boot time could be reduced enough so that the order in which devices are probed becomes irrelevant. IME that would have to be under 200ms so that the user doesn't notice and that's unicorn-far from any bootlog I have ever seen. Given that downstreams are already carrying as many hacks as they could think of to speed total boot up, I think this is effectively telling them to go away. Sorry for the rant, Tomeu >> I don't think it is completely ad hoc. Given all devices are >> registered after drivers, drivers will still probe first in initcall >> level order and then link order AFAIK. We may not take (more) initcall >> level tweak hacks, but that is a much more simple change for >> downstream. Don't get me wrong, I'd really like to see a way to >> control order independent of initcall level. >> >> Rob > > Yep, it is not directly ad hoc, just a fortunate
[GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > On 21 October 2015 at 23:50, Frank Rowand wrote: > > On 10/21/2015 2:12 PM, Rob Herring wrote: > >> On Wed, Oct 21, 2015 at 1:18 PM, Frank Rowand > >> wrote: > >>> On 10/21/2015 9:27 AM, Mark Brown wrote: > On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote: > > On 10/19/2015 5:34 AM, Tomeu Vizoso wrote: > > >> To be clear, I was saying that this series should NOT affect total > >> boot times much. > > > I'm confused. If I understood correctly, improving boot time was > > the key justification for accepting this patch set. For example, > > from "[PATCH v7 0/20] On-demand device probing": > > > >I have a problem with the panel on my Tegra Chromebook taking longer > >than expected to be ready during boot (Stéphane Marchesin reported > > what > >is basically the same issue in [0]), and have looked into ordered > >probing as a better way of solving this than moving nodes around in > > the > >DT or playing with initcall levels and linking order. > > > >... > > > >With this series I get the kernel to output to the panel in 0.5s, > >instead of 2.8s. > > Overall boot time and time to get some individual built in component up > and running aren't the same thing - what this'll do is get things up > more in the link order of the leaf consumers rather than deferring those > leaf consumers when their dependencies aren't ready yet. > >>> > >>> Thanks! I read too much into what was being improved. > >>> > >>> So this patch series, which on other merits may be a good idea, is as > >>> a by product solving a specific ordering issue, moving successful panel > >>> initialization to an earlier point in the boot sequence, if I now > >>> understand more correctly. > >>> > >>> In that context, this seems like yet another ad hoc way of causing the > >>> probe order to change in a way to solves one specific issue? Could > >>> it just as likely move the boot order of some other driver on some > >>> other board later, to the detriment of somebody else? > >> > >> Time to display on is important for many products. Having the console > >> up as early as possible is another case. CAN bus is another. This is a > >> real problem that is not just bad drivers. > > > > Yes, I agree. > > > > What I am seeing is that there continues to be a need for the ability > > to explicitly order at least some driver initialization (at some > > granularity), despite the push back against explicit ordering that > > has been present in the past. > > The important point that I have struggled to explain is that right now > for downstreams to influence the order in which devices are probed, > they have to carry a substantial amount of patches that cannot be ever > upstreamed. This fiddling with initcall levels and link order means > changing files that are very frequently changing, increasing the > amount of work when rebasing and increasing the probability of > regressions after a rebase. > > This just adds up to other shortcomings of mainline and ends up with > the net result of vendors getting stuck with 3.4 kernels on SoCs that > start production in 2015. Another consequence is that vendors don't > have a chance to upstream their stuff even if they cared. The > overarching goal of the project I'm in is to reduce those shortcomings > that downstreams have to workaround, to facilitate their involvement > upstream. The init order of drivers has no influence at all on the ability for companies to have their individual drivers merged upstream, please don't be so dramatic about this. Worst case, a vendor keeps a single patch to drivers/Makefile in their tree that reorders things, yes it will get conflicts on every release, but really, it's trivial to maintain if they wish to keep doing this type of thing. Again, it is _not_ the reason that we are living with 2million+ lines of code in vendor kernels. thanks, greg k-h
[GIT PULL] On-demand device probing
On Thu, Oct 22, 2015 at 07:44:05AM -0700, Greg Kroah-Hartman wrote: > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: > > Given that downstreams are already carrying as many hacks as they > > could think of to speed total boot up, I think this is effectively > > telling them to go away. > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > solve-the-random-issue-i'm-having type patch by putting random calls in > semi-random subsystems all over the kernel. +1000, fully agree. There's too much verbal diarrhoea going on in this thread and no facts. I've been waiting for real data too, and there's not one shred of it, or even a hint that it might appear. So, the conclusion I'm coming to is that there isn't any data to back up the claims made in this thread. If it was such a problem, then in the _eight_ days that this has been discussed so far, _someone_ would have sent some data showing the problem. I think the fact is, there is no data. Someone prove me wrong. Someone post the verifiable data showing that there is a problem to be solved here. Someone show what the specific failure cases are that are hampering vendors moving forwards. Someone show the long boot times by way of kernel message log. Someone show some evidence of the problems that have been alluded to. If no one can show some evidence, there isn't a problem here. :) -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[GIT PULL] On-demand device probing
On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote: > > > On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote: >> But that's moot currently because Greg believes that the time spent >> probing devices at boot time could be reduced enough so that the order >> in which devices are probed becomes irrelevant. IME that would have to >> be under 200ms so that the user doesn't notice and that's unicorn-far >> from any bootlog I have ever seen. > > But as no one has actually produced a bootlog, how do you know that? > Where exactly is your time being spent? What driver is causing long > delays? Why is the long-delay-drivers not being done in their own > thread? And most importantly, why are you ignoring the work that people > did back in 2008 to solve the issue on other hardware platforms? > >> Given that downstreams are already carrying as many hacks as they >> could think of to speed total boot up, I think this is effectively >> telling them to go away. > > No I'm not, I'm asking for real data, not hand-wavy-this-is-going-to > solve-the-random-issue-i'm-having type patch by putting random calls in > semi-random subsystems all over the kernel. > > And when I ask for real data, you respond with the fact that you aren't > trying to speed up boot time here at all, so what am I supposed to think I also had the understanding that this patch series was about improving boot time. But I was kindly corrected that the behavior change was getting the panel displaying stuff at an earlier point in the boot sequence, _not_ completing the entire boot faster. The claim for the current series, in patch 0 in v7 is: With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. Just to get side-tracked, one other approach at ordering to reduce deferrals reported a modest boot time reduction for four boards and a very slight boot time increase for one other board.) The report of boot times with that approach was in: http://article.gmane.org/gmane.linux.drivers.devicetree/133010 from Alexander Holler. I have not searched further to see if there is more data of boot time reductions from any of the other attempts to change driver binding order to move dependencies before use of a resource. But whether there is a performance improvement or not, there continues to be a stream of developers creatively impacting the binding order for their specific driver(s) or board. So it seems that maybe there is an underlying problem, or we don't have adequate documentation explaining how to avoid a need to order bindings, or the documentation exists and is not being read. I have been defaulting to the position that has been asserted by the device tree maintainters, that probe deferrals work just fine for at least the majority of cases (and is the message I have been sharing in my conference presentations about device tree). But I suspect that there is at least a small minority of cases that are not well served by probe deferral. (Not to be read as an endorsement of this specific patch series, just a generic observation.) -Frank > other than that you don't care enough to do the real work and are trying > to hack the driver core up instead. > >> Sorry for the rant, > > No apologies needed, it's cathartic at times :) > > thanks, > > greg k-h > . >
Alternative approach to solve the deferred probe (was: [GIT PULL] On-demand device probing)
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:
> Something like this. I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
> be fwnode?) See the commented out of_warn_deferred() in
> drivers/gpio/gpiolib-of.c. Adding this stuff in the subsystems searching
> for resources should make debugging why things are getting deferred easier.
Yeah, plus I'd expect it to also result in better error reporting
overall if the subsystems are able to report when they fail to get
something rather than just returning an error to the driver.
> +/**
> + * dev_warn_deferred() - report why a probe has been deferred
> + */
> +void dev_warn_deferred(struct device *dev, const char *fmt, ...)
> +{
> + if (driver_deferred_probe_report) {
> + struct va_format vaf;
> + va_list ap;
> +
> + va_start(ap, fmt);
> + vaf.fmt = fmt;
> + vaf.va = ≈
> +
> + dev_warn(dev, "deferring probe: %pV", &vaf);
> + va_end(ap);
> + }
> +}
> +EXPORT_SYMBOL_GPL(dev_warn_deferred);
I'm not currently able to think of a nice way of writing this but I think
what I'd really like to see from a driver point of view is something
which decays into dev_err() if it's a non-deferral error. That way
drivers can have minimal log and return error handling code and we will
still get the output sensibly. The best I can think of is something
like
void dev_warn_deferred(struct device *dev, int err, const char *fmt, ...)
which requires the caller to pass in err twice to get it logged. That's
not a thing of beauty but it gets the job done... but perhaps your
original interface is better, it's a bit cleaner.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/98ea382a/attachment-0001.sig>
[PATCH] drm: Add helper macro for drm_i2c_encoder_driver boilerplate
This patch introduces the module_drm_i2c_encoder_driver macro which is
a convenience macro for I2C encoder driver modules similar to others
such as module_platform_driver.
To help with this we also add the drm_i2c_encoder_register macro
that gets THIS_MODULE without include chaining or adding it to
every driver filel, renaming the old drm_i2c_encoder_register to
__drm_i2c_encoder_register, again similar to many other subsystems.
Finally, use this macro in all aplicable drivers.
Signed-off-by: Andrew F. Davis
---
drivers/gpu/drm/i2c/adv7511.c | 12 +---
drivers/gpu/drm/i2c/ch7006_drv.c | 12 +---
drivers/gpu/drm/i2c/sil164_drv.c | 14 +-
drivers/gpu/drm/i2c/tda998x_drv.c | 17 +
include/drm/drm_encoder_slave.h | 23 +++
5 files changed, 23 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
index 00416f2..c1d1206 100644
--- a/drivers/gpu/drm/i2c/adv7511.c
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -997,17 +997,7 @@ static struct drm_i2c_encoder_driver adv7511_driver = {
.encoder_init = adv7511_encoder_init,
};
-static int __init adv7511_init(void)
-{
- return drm_i2c_encoder_register(THIS_MODULE, &adv7511_driver);
-}
-module_init(adv7511_init);
-
-static void __exit adv7511_exit(void)
-{
- drm_i2c_encoder_unregister(&adv7511_driver);
-}
-module_exit(adv7511_exit);
+module_drm_i2c_encoder_driver(adv7511_driver);
MODULE_AUTHOR("Lars-Peter Clausen ");
MODULE_DESCRIPTION("ADV7511 HDMI transmitter driver");
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index 51fa323..cdf79f8 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -517,15 +517,7 @@ static struct drm_i2c_encoder_driver ch7006_driver = {
/* Module initialization */
-static int __init ch7006_init(void)
-{
- return drm_i2c_encoder_register(THIS_MODULE, &ch7006_driver);
-}
-
-static void __exit ch7006_exit(void)
-{
- drm_i2c_encoder_unregister(&ch7006_driver);
-}
+module_drm_i2c_encoder_driver(ch7006_driver);
int ch7006_debug;
module_param_named(debug, ch7006_debug, int, 0600);
@@ -548,5 +540,3 @@ MODULE_AUTHOR("Francisco Jerez ");
MODULE_DESCRIPTION("Chrontel ch7006 TV encoder driver");
MODULE_LICENSE("GPL and additional rights");
-module_init(ch7006_init);
-module_exit(ch7006_exit);
diff --git a/drivers/gpu/drm/i2c/sil164_drv.c b/drivers/gpu/drm/i2c/sil164_drv.c
index 002ce78..2d217ba 100644
--- a/drivers/gpu/drm/i2c/sil164_drv.c
+++ b/drivers/gpu/drm/i2c/sil164_drv.c
@@ -444,21 +444,9 @@ static struct drm_i2c_encoder_driver sil164_driver = {
/* Module initialization */
-static int __init
-sil164_init(void)
-{
- return drm_i2c_encoder_register(THIS_MODULE, &sil164_driver);
-}
-
-static void __exit
-sil164_exit(void)
-{
- drm_i2c_encoder_unregister(&sil164_driver);
-}
+module_drm_i2c_encoder_driver(sil164_driver);
MODULE_AUTHOR("Francisco Jerez ");
MODULE_DESCRIPTION("Silicon Image sil164 TMDS transmitter driver");
MODULE_LICENSE("GPL and additional rights");
-module_init(sil164_init);
-module_exit(sil164_exit);
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 424228b..2d77a5a 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1620,23 +1620,8 @@ static struct drm_i2c_encoder_driver tda998x_driver = {
/* Module initialization */
-static int __init
-tda998x_init(void)
-{
- DBG("");
- return drm_i2c_encoder_register(THIS_MODULE, &tda998x_driver);
-}
-
-static void __exit
-tda998x_exit(void)
-{
- DBG("");
- drm_i2c_encoder_unregister(&tda998x_driver);
-}
+module_drm_i2c_encoder_driver(tda998x_driver);
MODULE_AUTHOR("Rob Clark i2c_driver);
}
+/* use a define to avoid include chaining to get THIS_MODULE */
+#define drm_i2c_encoder_register(driver) \
+ __drm_i2c_encoder_register(THIS_MODULE, driver)
+
/**
* drm_i2c_encoder_unregister - Unregister an I2C encoder driver
* @driver:Driver to be unregistered.
@@ -159,7 +163,6 @@ static inline void drm_i2c_encoder_unregister(struct
drm_i2c_encoder_driver *dri
void drm_i2c_encoder_destroy(struct drm_encoder *encoder);
-
/*
* Wrapper fxns which can be plugged in to drm_encoder_helper_funcs:
*/
@@ -178,5 +181,17 @@ enum drm_connector_status drm_i2c_encoder_detect(struct
drm_encoder *encoder,
void drm_i2c_encoder_save(struct drm_encoder *encoder);
void drm_i2c_encoder_restore(struct drm_encoder *encoder);
+/**
+ * module_drm_i2c_encoder_driver() - Helper macro for registering a I2C
+ * Encoder driver
+ * @__drm_i2c_encoder_driver: drm_i2c_encoder_driver struct
+ *
+ * Helper macro for I2C Encoder drivers which do not do anything special in
+ * module init/exit. This eliminates a lot of boilerplate. Each module may only
+ * use this macro once, and calling it replaces module_init() and module_exit()
+ */
+#define module_drm_
Fwd: 5K iMac retina multi stream display port
Sorry, missed to send this to the devel list. -- Forwarded message -- From: Andreas Tunek Date: 2015-10-05 19:57 GMT+02:00 Subject: Re: 5K iMac retina multi stream display port To: Dave Airlie 2015-10-05 12:06 GMT+02:00 Dave Airlie : > On 4 October 2015 at 21:36, Andreas Tunek wrote: >> 2015-10-04 13:31 GMT+02:00 Andreas Tunek : >>> 2015-10-04 13:26 GMT+02:00 Andreas Tunek : >>>> 2015-10-04 6:31 GMT+02:00 Dave Airlie : >>>>> On 3 October 2015 at 04:03, Andreas Tunek >>>>> wrote: >>>>>> Hi >>>>>> >>>>>> I sort of recall that somebody (Dave Airlied) work on this in order to >>>>>> get the full 5K from a retina iMac. Was that work finished or is that >>>>>> coming in 4.3 or later? Or was it abandoned? Or maybe I am not >>>>>> remembering correctly? >>>>> >>>>> you can try a 4.2 kernel with radeon.mst=1 >>>>> >>>>> I've no idea if it will work. >>>> >>>> Didn't seem to have any effect. Is this a correct boot env: >>>> [ >>>> root at iMacLinux tuna]# cat /proc/cmdline >>>> BOOT_IMAGE=/vmlinuz-4.2.1-300.fc23.x86_64 >>>> root=UUID=e3e65337-b654-495f-b7c1-0212e1fd0797 ro rhgb quiet >>>> LANG=en_US.UTF-8 radeon.mst=1 >>>> >>>>> >>>>> Dave. >>> >>> Sorry for replying again, but you wrote some stuff in February*, did >>> you test with an iMac or some other 5K screen then? >>> >>> http://thread.gmane.org/gmane.comp.video.dri.devel/124345 >>> >>> Best regards >>> Andreas > > No I never tested anything on an imac 5K. > > Can you boot with drm.debug=6 radeon.mst=1 and post the > dmesg logfile? > > I'm not sure if the 5K mode on these would need to be reverse engineered > there is definitely some trickery involved. > > Dave. See attached file. cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.2.1-300.fc23.x86_64 root=UUID=e3e65337-b654-495f-b7c1-0212e1fd0797 ro rhgb quiet LANG=en_US.UTF-8 drm.debug=6 radeon.mst=1 -- next part -- A non-text attachment was scrubbed... Name: dmesg Type: application/octet-stream Size: 229992 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/42dbc345/attachment-0001.obj>
[pull] drm/msm: msm-next for 4.4
Hi Dave, A bit smaller pull this time. Few minor things, plus initial support for msm8996 (snapdragon 820).. Sorry, a bit latish, was hoping to get some 8960/8064 DSI stuff included. But still waiting on the v2 of the patchset (just pending some minor review comments). It would be nice to get the DSI patches merged since it would help some folks trying to get upstream kernel running on n4/n7 and xperia z and wanting to write some more panel drivers. Also, waiting for OCMEM driver to get merged via other trees and then I have a small bit to go along with that to make the gpu actually work on devices w/ OCMEM (snapdragon 800, 805, etc). So maybe a second later pull req, time permitting. The following changes since commit 2b5f900e4fb18d85fc62d4efcf4e7016fc384806: Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-next (2015-10-22 10:31:43 +1000) are available in the git repository at: git://people.freedesktop.org/~robclark/linux msm-next for you to fetch changes up to a9ee34b70e07ce942806eda154e48ea3f754a76f: drm/msm: Remove local fbdev emulation Kconfig option (2015-10-22 15:46:36 -0400) Archit Taneja (1): drm/msm: Remove local fbdev emulation Kconfig option Bjorn Andersson (1): drm: msm: dsi: Don't attempt changing voltage of switches Hai Li (1): drm/msm/dsi: Updata LNn_CFG4 register settings for 28nm PHY Rob Clark (1): drm/msm: update generated headers Stephane Viau (7): drm/msm/mdp5: remove the cfg pointer from SMP struct drm/msm: Fix IOMMU clean up path in case msm_iommu_new() fails drm/msm/mdp5: Avoid printing error messages for optional clocks drm/msm/hdmi: Add basic HDMI support for msm8996 drm/msm/mdp5: Use the newly introduced enum mdp_component_type drm/msm/mdp: Add Software Pixel Extension support drm/msm/mdp5: Basic support for MDP5 v1.7 (MSM8996) Documentation/devicetree/bindings/drm/msm/hdmi.txt | 3 + Documentation/devicetree/bindings/drm/msm/mdp.txt | 3 +- drivers/gpu/drm/msm/Kconfig| 14 -- drivers/gpu/drm/msm/Makefile | 2 +- drivers/gpu/drm/msm/adreno/a2xx.xml.h | 9 +- drivers/gpu/drm/msm/adreno/a3xx.xml.h | 27 ++- drivers/gpu/drm/msm/adreno/a4xx.xml.h | 15 +- drivers/gpu/drm/msm/adreno/adreno_common.xml.h | 13 +- drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h| 9 +- drivers/gpu/drm/msm/dsi/dsi.xml.h | 238 - drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +- drivers/gpu/drm/msm/dsi/mmss_cc.xml.h | 8 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 6 +- drivers/gpu/drm/msm/dsi/sfpb.xml.h | 21 +- drivers/gpu/drm/msm/edp/edp.xml.h | 8 +- drivers/gpu/drm/msm/hdmi/hdmi.c| 17 +- drivers/gpu/drm/msm/hdmi/hdmi.xml.h| 8 +- drivers/gpu/drm/msm/hdmi/qfprom.xml.h | 8 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h| 8 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h| 86 +++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c| 95 +++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.h| 11 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 46 ++-- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h| 2 + drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 201 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_smp.c| 8 +- drivers/gpu/drm/msm/mdp/mdp_common.xml.h | 15 +- drivers/gpu/drm/msm/mdp/mdp_kms.h | 6 + drivers/gpu/drm/msm/msm_drv.c | 8 +- drivers/gpu/drm/msm/msm_gpu.c | 8 + 31 files changed, 689 insertions(+), 218 deletions(-)
[Linux v4.3-rc6] i915: issues with Skylake integrated graphics
Hi, I am testing Linux v4.3-rc6 on a laptop with Intel 'Skylake' integrated graphics. The integrated display works, but I noticed several warnings in the kernel log, and a VGA monitor attached to the HDMI input via a VGA->HDMI adapter did not work. Furthermore, the system hung for several seconds during boot. The two WARNs were: [1.078097] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/intel_pm.c:3321 skl_update_pipe_wm+0x7fa/0x810() [1.078097] WARN_ON(p->pixel_rate == 0) ... [1.353670] WARNING: CPU: 1 PID: 6 at drivers/gpu/drm/i915/intel_dp.c:854 intel_dp_aux_ch+0x10f/0x6a0() [1.353670] dp_aux_ch not started status 0xad40001f The following error was reported later, when the HDMI input was connected but the driver failed to report the input as connected: [ 52.553940] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 I have attached the full 'dmesg' output for anyone who may find it useful. Eric -- next part -- A non-text attachment was scrubbed... Name: dmesg.gz Type: application/octet-stream Size: 18629 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151022/1d1bd5fc/attachment-0001.obj>
