Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property
> How about for sensitive video streams in government offices where you > want to avoid a spy potentially tapping the cable to see the video > stream? Last time I checked HDCP did not meet government security requirements - which is hardly surprising since you can buy $10 boxes from China to de-hdcp video streams 8) Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 1/6] drm: Add Content Protection property
> If you want to actually lock down a machine to implement content > protection, then you need secure boot without unlockable boot-loader and a > pile more bits in userspace. So let me take my Intel hat off for a moment. The upstream policy has always been that we don't merge things which don't have an open usable user space. Is the HDCP encryption feature useful on its own ? What do users get from it ? If this is just an enabler for a lump of binary stuff in ChromeOS then I don't think it belongs, if it is useful standalone then it seems it does belong ? Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] fbcon: Make fbcon a built-time depency for fbdev
On Wed, 28 Jun 2017 12:36:35 +0200 Daniel Vetter <daniel.vet...@ffwll.ch> wrote: > There's a bunch of folks who're trying to make printk less > contended and faster, but there's a problem: printk uses the > console_lock, and the console lock has become the BKL for all things > fbdev/fbcon, which in turn pulled in half the drm subsystem under that > lock. That's awkward. Yes - very. Although if you implement your console printing method with sufficient cunning it shouldn't cause much latency in most cases but for unaccelerated fb it's really bad. It also makes it unnecessarily hard for a drm driver to accelerate console output. > 4. Push console_lock down the call-chain, until it is down in > console_register again. I don't think that's actually going to work out. To fix it is going to need more invasive changes so that you can 'create' a console and set it up separately to actually 'enabling' it when you make it visible and start scribbling. I don't see any other way to make the changeover locking saner at this point without still having huge potential stalls in printk(). Reviewed-by: Alan Cox <a...@linux.intel.com> Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix vxd392 memory corruption on VLV and 4GB
offending pages around when vxd392 attaches - i.e. we need to check the attached device's dma masks and if there's something offending, migrate the buffer with a differen shmem allocation mask. Iirc Alan Cox had patches to do just that (but for swapoff, still the same idea though). The shmemfs code knows about this for GEM (and anything else it backs). My only credit is finding the problem, I didn't do the fixing! Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix vxd392 memory corruption on VLV and 4GB
On Sat, 2014-03-08 at 11:25 -0800, Sean V Kelley wrote: On Saturday 08 Mar 2014 at 09:25:54 (+), Chris Wilson writes : On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote: On VLV systems addressing 4GB of memory or greater, memory corruption was seen when initializing and attempting to render VP8 hardware decode surfaces using the VXD392 HW IP block. The VXD MMU has a limitation to addressing only 32bits. On 64bit kernel and user space builds this can cause problems for use of that IP block. When 2G memory is inserted, fw buffer pfn was at 0x5f62b, which is below 4GB. While for 4GB of memory the fw buffer pfn was 0x162ea9 with a physical address at 0x162ea9000, above 4GB. So although the memory is 4GB in the test hardware (Bayleybay CRB), a large physical region (for example 3G-4G) can be occupied by onboard system resources. Enabling ZONE_DMA32 and setting the correct mask DMA for this device resolves the issue kernel side. That's a shame. I guess this is restricted to a subset of byt? It should affect all baytrail systems. To my knowledge there are no subsets that have it fused off. This is in the gross hacks department but what happens if you set the VXD to DMA to GTT translated addresses, does it see the memory directly or via the GTT translations ? Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] x86/Sandy Bridge: reserve pages when integrated graphics is present
On Wed, 14 Nov 2012 20:43:31 + Jesse Barnes jbar...@virtuousgeek.org wrote: SNB graphics devices have a bug that prevent them from accessing certain memory ranges, namely anything below 1M and in the pages listed in the table. So reserve those at boot if set detect a SNB gfx device on the CPU to avoid GPU hangs. What happens if the other addresses map to an external memory object - eg a PCI device which is a legitimate DMA source for video overlay etc ? I assume this is just for GPU fetches from main memory ? Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] x86/Sandy Bridge: reserve pages when integrated graphics is present
On Wed, 14 Nov 2012 13:55:34 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 14 Nov 2012 21:19:05 + Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Wed, 14 Nov 2012 20:43:31 + Jesse Barnes jbar...@virtuousgeek.org wrote: SNB graphics devices have a bug that prevent them from accessing certain memory ranges, namely anything below 1M and in the pages listed in the table. So reserve those at boot if set detect a SNB gfx device on the CPU to avoid GPU hangs. What happens if the other addresses map to an external memory object - eg a PCI device which is a legitimate DMA source for video overlay etc ? Other addresses as in the 5 pages high in the address space? I'm not sure how to do what I want with memblock, doesn't it just allocate RAM not I/O space?... /me looks at the memblock API Or do you mean if we map GTT pages to point at some non-RAM region will SNB gfx be able to decode them? If that's the question, then I think the answer is no, but I don't have enough detail on the hw bug to be certain. I assume this is just for GPU fetches from main memory ? AIUI, it's an address decoder bug, so it would affect any fetch by the GPU through its memory interface glue. Well the extreme case (and I suspect one we don't care about too much in reality) is a box with a PCI/E or similar MMIO graphics device which is taking part in Dave Airlie's wonderous new graphics architecture so being rendered into or fetched by the Intel GPU and whose PCI/E space is mapped crossing one of those addresses. The other case of concern would be if the Intel IOMMU had mappings there that were then touched in some way by the GPU ? Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] PM: make VT switching to the suspend console optional
On Fri, 2 Nov 2012 14:43:40 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: KMS drivers can potentially restore the display configuration without userspace help. Such drivers can set a new global, pm_vt_switch, to false if they support this feature. In that case, the PM layer won't VT switch to the suspend console at suspend time and then back to the original VT on resume, but rather leave things alone for a nicer looking suspend and resume sequence. What if you are multi-head ? What are the locking rules for a suspend/kms module unload race, what happens when you load/unload and hand over multiple frame buffers ? What if you have vts split across two adapters ? Put me down as 100% in favour of the feature but we need to be a bit more careful about the implementation. The logic probably needs to be in the vt layer. I suspect we actually need a per vt flag for this, or a flag on the underlying object below the vt somewhere. So NAK for the implementation ACK for the idea. Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] PM: make VT switching to the suspend console optional
that, but how would I even configure a VT split across two adapters today? For vgacon we just route VGA to a single adapter, but I'm not con2fb /dev/fb1 /dev/tty1 Dunno about suspend vs unload, how do we deal that in other drivers like the disk driver for suspend for example? Overall that case seems pretty esoteric... What do you mean about hand over to multiple frame buffers? You have a global but I can insmod i915 move the consoles off it and unload it (at least in theory - last time I tried it crashed at least on gma500 which I need to fix 8)) So you've got a global you can't just set back but need to adjust on unload. And you've got races like suspend as we are changing framebuffer which your code doesn't consider as you have no locking. If we push the logic into the vt layer we can pretty easily dump it under the vt locks. It's not the whole story as there are all sorts of things it doesn't handle but it does mean we can handle the case of if we are switching from a vt which is on a device that doesn't need it for suspend then do nothing properly, and we can make any future features work right I think all we need is consw to have a con_sw_suspend/con_sw_resume method and the framebuffer layer to let kms get at it. Alan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
