Michel Dänzer wrote: > On Tue, 2009-08-11 at 10:48 +0200, Thomas Hellström wrote: > >> Michel Dänzer wrote: >> >>> On Wed, 2009-08-05 at 12:06 +0200, Thomas Hellström wrote: >>> >>> >>>> Michel Dänzer wrote: >>>> >>>> >>>>> On Wed, 2009-08-05 at 11:18 +0200, Thomas Hellström wrote: >>>>> >>>>> >>>>> >>>>>> Aargh. Wait. I remember now. >>>>>> >>>>>> The fbcon bo is exported through the fbdev address space at offset 0. >>>>>> The vm_node is for the drm device address space only. So it is perfectly >>>>>> legal and actually correct for it not to have a vm_node, unless it's >>>>>> going to be accessible from the drm device. Does it need to for KMS? >>>>>> >>>>>> >>>>>> >>>>> I don't think so. >>>>> >>>>> >>>>> >>>>> >>>>>> I'm a bit unsure whether it's OK to export a bo through two different >>>>>> address spaces. In particular, unmap_mapping_range() on the drm device >>>>>> will not kill the fbdev user-space mappings. >>>>>> >>>>>> >>>>>> >>>>> Hmm, so that would mean that if an fbdev mapping is created while the BO >>>>> is in VRAM, it would still access VRAM after the BO has been evicted? Is >>>>> there a solution for this? >>>>> >>>>> >>>>> >>>>> >>>> Yes, You need to call unmap_mapping_range() on the fbdev address space. >>>> See how that is done in ttm_bo_unmap_virtual() for the drm address >>>> space. Actually, I think you need to set up a bo_driver hook in >>>> ttm_bo_unmap_virtual() to do this every time the bo is moved or swapped >>>> out. >>>> >>>> >>> The attached patches should hopefully address all the feedback I've >>> received here and on IRC. Let me know what you think. >>> >>> >>> >>> >> Michel, >> The TTM parts look good to me. >> > > The only thing I'm not quite sure about is the ttm_bo_vm_fault changes; > I think they make the assumption that the BO backs the beginning of the > address space if bo->vm_node is NULL? If that is a problem, how could it > be solved? > >
I think this is OK for now. If we want to export bo maps through even more devices, we can probably deal with that when that happens. >> I'm not 100% sure, but the Radeon part still looks a little problematic. >> First, I think it's illegal to call radeonfb_remap() from the fbdev >> accelerated hooks, since these may be called from within atomic context >> and there's no way to detect this since in_atomic() only works if >> CONFIG_PREEMPT is set. IIRC Jakob hit this with psbfb. >> >> Also when you test for mem_reg_is_pci() to determine that it's ok to >> kmap, I'd instead test for TTM_BO_FLAG_NO_EVICT to make sure the object >> is pinned, regardless of its whereabouts. >> > > Note that the primary purpose of the test isn't to check that it's okay > to kmap but that the resulting screen_base will be suitable for cfb_* > (i.e. essentially that it uses ioremap). Otherwise it just leaves > screen_base invalid. > > Hmm. Ok. I just want to make sure that the screen_base will *never* be valid when the bo is unpinned or unreserved. That would potentially cause severe memory corruption. >> So the problem is really: How do we avoid the >> invalidate_kernel_address() racing with an fbcon access? >> To be completely sure we would want a spinlock protecting the address >> pointer, but we don't have one, and the error is fatal if this happens. >> > > Hmm. Maybe the console semaphore could be used for this? If we can't > acquire it, maybe we could just fail whatever we would need it for... > > > We've tried various uses of that one as well for psb, but we didn't really succeed, but I admit I don't have a clear understanding of exactly what it is used for. /Thomas ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
