Re: [Xpert] Re: Current CVS version of X does indeed break wrt SHM

Odd, Isn't 777 insecure for shared memory segments? Yes; Enlightenment does have it's own little set of features... [EMAIL PROTECTED]XFree86 Core Team SuSE, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

Re: PCI resource problems caused by improper address rounding

On Tue, 2007-12-18 at 13:09 -0800, Linus Torvalds wrote: It's not like 256MB is even as large as they come, half-gig graphics cards are getting to be fairly common at the high end, and X absolutely _has_ to be able to handle a 64-bit address for those. We're now using a system-dependent

Re: [RFC] AGP initial support for chipset flushing..

On Mon, 2007-10-29 at 08:15 +, Dave Airlie wrote: The attached patches add a new AGP interface for this purpose and implements this in the Intel AGP driver. This stuff is based of some guesswork in the 915 case from comments in the documentation :). The relevant register lives in

Re: [RFC] AGP initial support for chipset flushing..

On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote: In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE) right? But this is just for the GPU; every other DMA device in the system is cache-coherent. Can we be sure that a single flush is sufficient? Is there any

Re: Revert intel_agp: fix stolen mem range on G33

On Sat, 2007-10-06 at 08:59 -0700, Linus Torvalds wrote: We do have a rule about no regressions, so I think we'll have to do the revert, but it would be nice to hear what the consequences for the revert is for the affected hardware and new X.org.. No regressions is more important than

Re: CFS review

On Wed, 2007-08-29 at 06:18 +0200, Ingo Molnar wrote: Then lay them out side by side to see the periodic stallings for ~10sec. The X scheduling code isn't really designed to handle software GL well; the requests can be very expensive to execute, and yet are specified as atomic operations

Re: CFS review

On Wed, 2007-08-29 at 06:46 +0200, Ingo Molnar wrote: ok, i finally managed to reproduce the artifact myself on an older box. It goes like this: start up X with the vesa driver (or with NoDRI) to force software rendering. Then start up a couple of glxgears instances. Those glxgears

Re: CFS review

On Wed, 2007-08-29 at 10:04 +0200, Ingo Molnar wrote: is that old enough to not have the smart X scheduler? The smart scheduler went into the server in like 2000. I don't think you've got any systems that old. XFree86 4.1 or 4.2, I can't remember which. (probably the GLX bug you mentioned)

Re: POSTing of video cards (WAS: Solo Xgl..)

Around 11 o'clock on Feb 28, Vladimir Dergachev wrote: I agree. For example, on my Dell notebook the graphics card is not reinitialized properly on return from resume. At some point I'll get bothered enough to write code that does it. # vbetool post Run from your suspend script while on a

Re: State of Linux graphics

On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote: On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote: | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote: | In general, the whole concept of programmable graphics hardware is | not addressed in APIs like xlib and Cairo. This is

Re: State of Linux graphics

On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote: On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote: | The real goal is to provide a good programming environment for 2D | applications, not to push some particular low-level graphics library. I think that's a reasonable goal

Re: State of Linux graphics

On Wed, 2005-08-31 at 18:58 -0700, Allen Akin wrote: On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote: | On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote: | ... | | Right, the goal is to have only one driver for the hardware, whether an | X server for simple 2D only

Re: [Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge

Lespiau, Damien damien.lesp...@intel.com writes: On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard kei...@keithp.com wrote: @@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv) */ static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX

Lespiau, Damien damien.lesp...@intel.com writes: I can't see anything in the docs about an order requirement for those. Right, the docs don't say anything, which is a bit disconcerting. Not sure why the other way does not make sense. Somehow disabling TX before RX makes some sense to me (TX

[PATCH] drm: use drm_compat_ioctl for 32-bit apps

/psb_drv.c unchanged; it has a custom .unlocked_ioctl and will presumably need a custom .compat_ioctl as well. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/ast/ast_drv.c |3 +++ drivers/gpu/drm/cirrus/cirrus_drv.c |3 +++ drivers/gpu/drm/exynos

Re: [patch] CFS scheduler, -v18

On Tue, 2007-07-03 at 09:22 +0200, Ingo Molnar wrote: which allows xterm-spam (attached) to easily flood the xterm (without any scrolling that would act as a throttle) and the xterm to flood Xorg. It's just an Xterm bug. Xterm will look for X input if it ever manages to fill the input

Announcing free software drivers for the new Intel® 965GM Express Chipset

The Intel® 965GM Express Chipset represents the first mobile product that implements fourth generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders.

Re: [RFC] enhancing the kernel's graphics subsystem

On Tue, 2007-05-22 at 10:09 +1000, Benjamin Herrenschmidt wrote: I do stongly beleive that the decision of what mode to choose should not be made in the kernel. That's the plan; the kernel just provides mechanism. The architecture used in the X server splits precisely at this point with the

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

On Thu, 2007-05-03 at 01:01 +0200, Thomas Hellström wrote: It might be possible to find schemes that work around this. One way could possibly be to have a buffer mapping -and validate order for shared buffers. If mapping never blocks on anything other than the fence, then there isn't any

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

On Fri, 2007-05-04 at 10:07 +0200, Thomas Hellström wrote: It's rare to have two clients access the same buffer at the same time. In what situation will this occur? Right, what I'm trying to avoid is having any contention for applications *not* sharing the same objects. If there is any

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

On Fri, 2007-05-04 at 11:40 +0200, Jerome Glisse wrote: On a side note i think this scheme also fit well with gpu having several context and which doesn't need big validation (read nv gpu). Yeah, I want to make sure we have a simple model that supports multi-context hardware while also

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

On Fri, 2007-05-04 at 14:32 +0200, Thomas Hellström wrote: If there isn't we can at least consider other alternatives that resolve the deadlock issue but that also will help clients synchronize and keep data coherent. If clients want coherence, they're welcome to implement their own

Re: [RFC] [PATCH] DRM TTM Memory Manager patch

On Fri, 2007-05-04 at 16:57 +0100, Keith Whitwell wrote: That's a special case of a the general problem of what do you do when a client submits any validation list that can't be satisfied. Failing to render isn't really an option, either the client or the memory manager has to either

Re: [PATCH 4/5] drm/i915: Add async page flip support for IVB

Daniel Vetter dan...@ffwll.ch writes: We could just unconditionally increase the alignement in intel_pin_and_fence_fb_obj - we already have more strict requirements due to a bunch of w/a in other places. So shouldn't hurt at all really. That seems like a fine plan; 32kB isn't that onerous. Do

Re: [PATCH 4/5] drm/i915: Add async page flip support for IVB

Daniel Vetter dan...@ffwll.ch writes: On Wed, Jul 24, 2013 at 06:40:16PM -0700, Keith Packard wrote: Daniel Vetter dan...@ffwll.ch writes: We could just unconditionally increase the alignement in intel_pin_and_fence_fb_obj - we already have more strict requirements due to a bunch of w

Re: [PATCH 4/5] drm/i915: Add async page flip support for IVB

Generally I think checking our current sw state instead of reading hw registers would be safer, e.g. in case we start to queue up more than one pageflip. For async pageflips in benchmark mode flip as fast as you can queue would be a sensible mode. Ok, I've moved the tiling checks to the

[PATCH 1/2] drm/i915: Add async page flip support for IVB

This adds the necesary register defines for async page flipping through the command ring, and then hooks those up for Ivybridge (gen7) page flipping. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_display.c | 37

[PATCH 2/2] drm/i915: Add async page flip support for SNB

Just copies the IVB code Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_display.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 166aa2c

[PATCH] net/usb: Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver

The Lenovo OneLink dock includes a USB ethernet adapter using the AX88179 chip, but with a different USB ID. Add this new USB id to the driver so that it will autodetect the adapter correctly. Signed-off-by: Keith Packard kei...@keithp.com Tested-by: Carl Worth cwo...@cworth.org --- drivers/net

[PATCH] net/usb: Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver

The Lenovo OneLink dock includes a USB ethernet adapter using the AX88179 chip, but with a different USB ID. Add this new USB id to the driver so that it will autodetect the adapter correctly. Signed-off-by: Keith Packard kei...@keithp.com Tested-by: Carl Worth cwo...@cworth.org --- Kyle

RE: [PATCH] net/usb: Add Lenovo ThinkPad OneLink GigaLAN USB ID to ax88179 driver

David Laight david.lai...@aculab.com writes: I think you meant lenovo_info. I posted an updated patch already; nice to know that so many people are looking at this kernel patch :-) -- keith.pack...@intel.com pgp7s9JXIJnNo.pgp Description: PGP signature

Re: [PATCH 1/1] AX88179_178A: Add VID:DID for Lenovo OneLinkDock Gigabit LAN

Bjørn Mork bj...@mork.no writes: No, you didn't. And when I went looking at it now, I see why: It was posted to linux-usb and linux-kernel but not to netdev: http://www.kernelhub.org/?msg=420289p=2 I looked in MAINTAINERS and found linux-usb as a suitable address for drivers/net/usb/. I'm

Re: [PATCH 1/1] AX88179_178A: Add VID:DID for Lenovo OneLinkDock Gigabit LAN

Joe Perches j...@perches.com writes: You could use scripts/get_maintainer.pl next time. Yeah, good point. I always forget about that tool when I'm hacking outside my normal areas. -- keith.pack...@intel.com pgpx2ESTnYiYI.pgp Description: PGP signature

Re: [Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

Ville Syrjälä ville.syrj...@linux.intel.com writes: Todd already implemented 5.4Gbps support a while back. So it seems your tree is a bit out of date. I didn't find it on drm-intel-fixes-2014-02-14; can you explain which tree it is present in? -- keith.pack...@intel.com pgpgC2kYUyjJ_.pgp

Re: [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value

Thierry Reding thierry.red...@gmail.com writes: That doesn't sound right. Maybe drmIoctl() needs fixing instead. Looking at the history, drmIoctl() was introduced to automatically loop if a signal was received (commit 8b9ab108ec1f2ba2b503f713769c4946849b3cb2). However the ioctl(3p) manpage

drm: Asynchronouse page flipping interface and Intel implementation

Here's a sequence of five patches that exposes an interface to request of the driver that the page flipping request be executed without waiting for vblank. It's optional, and drivers can expose whether it is supported through the existing GETCAP ioctl. This supports only Ivybridge and Sandybridge

[PATCH 3/5] drm: Advertise async page flip ability through GETCAP ioctl

Let applications know whether the kernel supports asynchronous page flipping. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/drm_crtc.c | 3 +++ drivers/gpu/drm/drm_ioctl.c | 3 +++ include/drm/drm_crtc.h | 3 +++ include/uapi/drm/drm.h | 1 + 4 files changed, 10

[PATCH 5/5] drm/i915: Add async page flip support for SNB

Just copies the IVB code Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/intel_display.c | 39 1 file changed, 35 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

[PATCH 1/5] drm: Pass page flip ioctl flags to driver

This lets drivers see the flags requested by the application Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/drm_crtc.c| 2 +- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +++-- drivers/gpu/drm/i915/i915_drv.h | 3 ++- drivers/gpu/drm/i915

[PATCH 2/5] drm: Add DRM_MODE_PAGE_FLIP_ASYNC flag definition

This requests that the driver perform the page flip as soon as possible, not necessarily waiting for vblank. Signed-off-by: Keith Packard kei...@keithp.com --- include/uapi/drm/drm_mode.h | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/include/uapi/drm

[PATCH 4/5] drm/i915: Add async page flip support for IVB

This adds the necesary register defines for async page flipping through the command ring, and then hooks those up for Ivybridge (gen7) page flipping. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_display.c | 40

Re: drm: Asynchronouse page flipping interface and Intel implementation

Daniel Vetter dan...@ffwll.ch writes: Quick comments on the i915 kernel part: - Iirc the w/a database has a bunch of entries about async flips. Those need to be addressed and annoted with the new w/a tag comment format Damien recently created. Where does this database live? - kms_flip

Re: [PATCH 4/5] drm/i915: Add async page flip support for IVB

Daniel Vetter dan...@ffwll.ch writes: Matching tiling modes is actually already a requirement on gen4+ (since the tiling bit and the linear/tiled offset registers can't be changed with a MI_DISPLAY_FLIP command). Async flip has a harder requirement -- you must use X tiling, both before and

[PATCH] fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs

by clearing the con2fb_map for the affected vcs and calling the modified con2fb_release_info function to clean up the fb_info structure. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/video/console/fbcon.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions

[PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

. When running efifb on an nVidia card, executing this store to SR01 ends up causing the screen to go black. I'm not sure if this store is still required; this patch limits it to when the intel card is primary. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

Chris Wilson ch...@chris-wilson.co.uk writes: The bspec still says we must assert SR01 bit5 prior to disabling the VGA plane. Perhaps the test should be whether (vga_reg VGA_DISP_DISABLE) == 0 and do nothing if the plane is already off. The problem is that for some reason we're smashing

Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

Chris Wilson ch...@chris-wilson.co.uk writes: Ok, so as no vgaarb_clients have yet been registered and so the call to grab the IO resource does not actually disable VGA IO routing to the nvidia card. Yikes! This explains a lot. If you care to update the changelog to explain the problem is

Re: REGRESSION 3.14 i915 warning mouse cursor vanishing

Steven Noonan ste...@uplinklabs.net writes: Was using my machine normally, then my mouse cursor vanished. After switching to a VT and back to X11, my cursor came back. But I did notice a nasty trace in dmesg (below). I don't think the trace below is related to the cursor disappearing. I

Re: REGRESSION 3.14 i915 warning mouse cursor vanishing

Steven Noonan ste...@uplinklabs.net writes: OK, good to know. Thanks for pointing those out! As Julien points out, this bug only affects people running master from the X server though... -- keith.pack...@intel.com pgpQYeZyUjBWJ.pgp Description: PGP signature

[PATCH] fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs

by clearing the con2fb_map for the affected vcs and calling the modified con2fb_release_info function to clean up the fb_info structure. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/video/console/fbcon.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions

Re: [PATCH] fbcon: Clean up fbcon data in fb_info on FB_EVENT_FB_UNBIND with 0 fbs

Keith Packard kei...@keithp.com writes: When FB_EVENT_FB_UNBIND is sent, fbcon has two paths, one path taken when there is another frame buffer to switch any affected vcs to and another path when there isn't. What I meant to attach to this bug report but clearly failed was that I think

Re: [PATCH] hwrng: core - allow perfect entropy from hardware devices

Herbert Xu herb...@gondor.apana.org.au writes: Please cc all hwrng patches to linux-cry...@vger.kernel.org so that it gets picked up by patchworks. Thanks! Thanks! I didn't catch that in the MAINTAINERS file. Might be a good thing to add? -- -keith signature.asc Description: PGP signature

[PATCH] hwrng: core - allow perfect entropy from hardware devices

Hardware random number quality is measured from 0 (no entropy) to 1024 (perfect entropy). Allow hardware devices to assert the full range by truncating the device-provided value at 1024 instead of 1023. Signed-off-by: Keith Packard kei...@keithp.com --- drivers/char/hw_random/core.c | 3 ++- 1

[PATCH] ALSA: hda/realtek: Enable headphone amp on HP Folio 9480m

This laptop needs GPIO4 pulled high to enable the headphone amplifier. I modelled the patch on the existing GPIO4 code which pulls the line low for the same purpose. Signed-off-by: Keith Packard kei...@keithp.com --- sound/pci/hda/patch_realtek.c | 23 +++ 1 file changed, 23

Re: [PATCH] ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m

Takashi Iwai ti...@suse.de writes: Great, I queued the patch now. It'll be included in the next pull request for 4.2-rc3. Thanks -- you're an awesome maintainer. -- -keith signature.asc Description: PGP signature

Re: [PATCH] ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m

in, and then removed the code which was disabling power saving, which lets everything (including the amp) get turned back off when the device goes idle. Here's a second version of the patch. From 60e2c02d651b0ca6e4b72aa1cab21660400fe2eb Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com

Re: [PATCH] ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m

. Thanks again for your help; it's always interesting to dive into some different area of the kernel and see how it works. From ca694a8c6d481fd327822dd2adec35e82affb2be Mon Sep 17 00:00:00 2001 From: Keith Packard kei...@keithp.com Date: Tue, 14 Jul 2015 09:30:33 -0700 Subject: [PATCH] ALSA: hda/realtek

[PATCH] ALSA: hda/realtek: Enable HP amp and mute LED on HP Folio 9480m

This laptop needs GPIO4 pulled high to enable the headphone amplifier, and has a mute LED on GPIO3. I modelled the patch on the existing GPIO4 code which pulls the line low for the same purpose; this time, the HP amp line is pulled high. Signed-off-by: Keith Packard kei...@keithp.com --- sound

Re: [RFC] A first shot at asciidoc-based formatted docs

Jonathan Corbet writes: > asciidoc->HTML on its own isn't viable, I think; we do have people wanting > other formats. Though one might well ask when somebody last successfully > generated PDF...maybe it's not worth the trouble. I would like epub > someday... I'm hopeful that I

Re: [RFC] A first shot at asciidoc-based formatted docs

Jani Nikula writes: > One of the chief complaints with the current pipeline (and some of the > proposals) has been the need to install lots of tools with lots of > dependencies. I would like to avoid the need to install bleeding edge > tools and stick to what's already

Re: Kernel docs: muddying the waters a bit

Jonathan Corbet writes: > Asciidoc is a credible solution to the formatted documentation problem, > but it's not the only such; I'd like to be sure that we pick the right > one. I worry that asciidoc seems to be aimed mostly at small documents, > and that the project itself

Re: [RFC] A first shot at asciidoc-based formatted docs

Keith Packard <kei...@keithp.com> writes: > The goal would be to create an html document which could be used without > javascript, and that would work without css as well. I've managed to hack up asciidoc to generate the TOC within the document, rather than requiring javascript.

Re: [PATCH] usb: check for signals in chaoskey read function

Oliver Neukum writes: > why is this needed? You are doing this right after a > mutex_lock_interruptible(). When the device isn't contended, this mutex will never block and so mutex_lock_interruptible will never check for a signal. I had mistakenly assumed that usb_bulk_msg

Re: Kernel docs: muddying the waters a bit

Jani Nikula writes: > However I didn't think Sphinx could produce docbook, and a quick search > doesn't convince me otherwise. Do you have some links to back this up? > Would the lack of docbook be a showstopper? (Of course, the pandoc > swiss-army knife can handle

Re: Kernel docs: muddying the waters a bit

Jonathan Corbet writes: > Indeed, I doubt many people want the DocBook itself. Might be nice to actually have a set of requirements before anyone tries to select a suitable system then :-) Here's my current set: asciidocsphinx htmlvia docbook native

Re: [PATCH] usb: check for signals in chaoskey read function

Oliver Neukum <oneu...@suse.com> writes: > On Tue, 2016-02-16 at 11:09 -0800, Keith Packard wrote: >> I could be convinced that the driver should be using a different path >> through the USB stack that would allow a signal to wake up while >> waiting >> for th

Re: [PATCH] usb: check for signals in chaoskey read function

Keith Packard <kei...@keithp.com> writes: > Yup, with a few minor fixes to pass the right arguments: Argh. Just after hitting 'send', I noticed that I'd not moved the URB deallocation out of the way when merging the first patch in this series. That means the driver won't build

Re: V4L docs and docbook

Hans Verkuil writes: > But good table handling is a prerequisite for us since we rely heavily on > that. I converted an asciidoc document that included some tables to sphinx via docbook using pandoc; that seemed to generate workable results for me, but my needs are pretty

[PATCH] usb: check for signals in chaoskey read function

Call signal_pending before reading a chunk of data from the device so that long read operations can be interrupted with a signal. Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/usb/misc/chaoskey.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/us

Re: Kernel docs: muddying the waters a bit

Daniel Vetter writes: > The other one is graphs - Keith showed me some neat stuff that > asciidoc can do, and I definitely wanted to integrate something like > that as a follow-up into the kerneldoc toolchain. Often a diagram is a > lot more helpful than lots of words.

Re: [RFC] A first shot at asciidoc-based formatted docs

Jonathan Corbet writes: > [Adding Keith since you said you wanted to be a part of this - let us know > when you've had enough!] Thanks. > - I would like to format directly to HTML if at all possible. Agreed. asciidoc's docbook path seems to only increase the amount of

Re: Kernel docs: muddying the waters a bit

Mauro Carvalho Chehab writes: > On my tests, Sphinix seemed too limited to format tables. Asciidoc > produced an output that worked better. Yes, asciidoc has much more flexibility in table formatting, including the ability to control text layout within cells and full

Re: Kernel docs: muddying the waters a bit

Daniel Vetter writes: > So sphinx/rst y/n? Jon, is that ok with you from the doc maintainer > pov? I think the right answer for today is to use sphinx to generate docs From inline comments, to encourage outline docs to give it a try but to allow doc writers to use

[PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Instead of having only one hwrng feeding /dev/random at a time, maintain a list of devices and cycle between them when filling the entropy pool. Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/char/hw_random/core.c | 155 +++--- include

[PATCH] drm: Don't prepare or cleanup unchanging frame buffers [v2]

to cleanup. Otherwise, failure paths and success paths would need different tests in the cleanup code as the plane state points to different places in the two cases. cc: dri-de...@lists.freedesktop.org cc: David Airlie <airl...@linux.ie> Signed-off-by: Keith Packard <kei...@k

[PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

c: Daniel Vetter <daniel.vet...@intel.com> cc: David Airlie <airl...@linux.ie> cc: intel-...@lists.freedesktop.org cc: dri-de...@lists.freedesktop.org Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+

Re: [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

Daniel Vetter writes: > Hm, I think we should just clean up wiat_req in ->atomic_destroy_state > instead of littering cleanup code all over. But this gets the job done, so > applied. Thanks. It's required for the DRM patch I posted that makes moving the cursor not block on

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Jason Cooper writes: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} I was interested in the data being

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Henrique de Moraes Holschuh writes: > IMHO, this is mightly annoying to use from inside a rngd-like utility in > a race-free, safe way. It looks to me that ioctl() would be a much > better interface for everything but the "enabled" functionality (which > should be reported to

Re: [PATCH] drm: Don't prepare or cleanup unchanging frame buffers [v2]

Daniel Vetter writes: > Rebased onto 4.8 while applying, which did simplify the patch a lot (4.8 > is already using for_each_plane_in_state, but slightly differently). Your rebase looks great, thanks! -- -keith signature.asc Description: PGP signature

Re: [PATCH] drm: Don't prepare or cleanup unchanging frame buffers [v2]

ring the fb's, I'm using the framebuffer_changed function, which seems like a nice bit of documentation if nothing else. From a75251d5762b1c200ed2f3dca2a5b00cc85bea95 Mon Sep 17 00:00:00 2001 From: Keith Packard <kei...@keithp.com> Date: Sat, 4 Jun 2016 01:16:22 -0700 Subject: [PATCH] drm: Don't prepa

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Jason Cooper writes: > On another thread, regarding the ath9k-rng (actually just the adc > registers), Henrique asked about per-source knobs. My suggestion > follows from that. I'd do that with the source-specific driver instead of attempting to route controls through

Re: [PATCH 2/4] drm: Add drm_object lease infrastructure

Daniel Vetter writes: > Still not sure we want to restrict objects on the lessor side. Feels like > unecessary complexity (i.e. more bugs in kernel, that's never good), and > at best only needed for lessors who can't keep track of stuff. It's been useful when hacking existing

Re: [PATCH 4/4] drm: Add four ioctls for managing drm mode object leases

Daniel Vetter writes: > Should we just use fd for this? Essentially lessors would be required to > keep track of all their pending leases, and just dup() them over to the > client. Would reduce the uapi scope a bit, and if a lessor can't keep > track of it's leases there's a

Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

Daniel Vetter writes: > I think it'd be good if we could consolidate all the lease checking into > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > wire up the fpriv to be able to do that, but we could upstream that patch > right away before anything

Re: [PATCH 2/4] drm: Add drm_object lease infrastructure

Daniel Vetter <dan...@ffwll.ch> writes: > On Sat, Apr 01, 2017 at 10:08:39AM -0700, Keith Packard wrote: >> +BUG_ON(__mutex_owner(>dev->mode_config.idr_mutex) != current); > > Forgot to reply on this: > > lockdep_assert_held + enable lockdep. Thanks. Will

Re: [PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

Daniel Vetter writes: > I think it'd be good if we could consolidate all the lease checking into > drm_mode_object_find (respectively __drm_mode_object_find). We'd need to > wire up the fpriv to be able to do that, but we could upstream that patch > right away before anything

[PATCH 4/4] drm: Add four ioctls for managing drm mode object leases

the leased objects for a particular lessee drm_mode_change_lease Adjust the terms of a lease, adding or removing resources or switching from masking to non-masking. This should suffice to at least create, query and manage available leases. Signed-off-by: Keith Packard <kei...@keithp.

[PATCH 2/4] drm: Add drm_object lease infrastructure

ly through another lessee), can be searched from an idr in the drm_master of the owner. Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/gpu/drm/Makefile| 3 +- drivers/gpu/drm/drm_auth.c | 22 +- drivers/gpu/drm/drm_lease.c | 485 +

[PATCH 1/4] drm: Add new LEASE debug level

Separate out lease debugging from the core. Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/gpu/drm/drm_drv.c | 3 ++- include/drm/drmP.h| 4 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c

[PATCH 0/4] drm: Add mode resource leasing

Here's a first cut of the proposed mode resource leasing code. What this does is allow an application to create a new drm_master which "leases" resources from an existing drm_master. This new drm_master can do whatever it likes with the resources it was granted, including setting modes, performing

[PATCH 3/4] drm: Check mode object lease status in all master ioctl paths

Attempts to modify un-leased objects are rejected with an error. Information returned about unleased objects is modified to make them appear unusable and/or disconnected. Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/gpu/drm/drm_atomic.c | 3 +++ drivers/gpu/drm/drm_

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > With the disable_immediate thing we only wait until the next vblank > before disabling the irq again. Ok, still sounds like we'll be doing fine if the application does a get immediately followed by a queue event. At least most of the time.

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > where we can avoid doing the full update more than once if we enable > the interrupt already during the query. Don't we still wait 5 seconds before disabling vblank? In

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Daniel Vetter writes: > I'd drop that part (but keep 64 everywhere else ofc). Yeah, we only ever ask drivers for a delta anyways, so keeping an internal 64-bit value while retaining the 32-bit driver API is easy to manage. >> > Other thought on this, since you bother to change

Re: [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types

Daniel Vetter writes: > A few nits below, but looks good otherwise. Thanks. >> static struct drm_pending_vblank_event *create_vblank_event( >> -struct drm_device *dev, uint64_t user_data) >> +struct drm_device *dev, struct drm_crtc *crtc, uint64_t >>

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Daniel Vetter writes: > Extending the reported/sw vblank counter to u64 makes sense imo, but do we > have to extend the driver interfaces too? If there's no 64 bit hw vblank > currently I think I'd be good to postpone that part, simply because I'm > too lazy to audit all the

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > Subtle breakage here: vblwait->request.sequence must still get updated > for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal. Thanks for finding this. I think it might be better to just not modify the request.type field instead, so that

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > BTW, this got me thinking that we should probably treat > _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating > vblwait->request.sequence. Otherwise there could theoretically (though > unlikely) be an infinite loop: I was thinking

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Daniel Vetter writes: > I very much like this since the old ioctl really is a rather bad horror > show. And since it's tied in with ums drivers everything is > complicated. Thanks for your kind words. > I started a discussion a while back whether these should be restricted to

  1   2   3   4   >