Date: Tue, 18 Feb 2014 16:29:46 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: =?iso-8859-15?q?Jean-S=E9bastien?= =?iso-8859-15?q?_P=E9dron?= <dumbbell@freebsd.org> Subject: Re: Radeon driver in stable/9: changes in VM, atomic.h and iicbus Message-ID: <201402181629.46372.jhb@freebsd.org> In-Reply-To: <53021225.4030407@FreeBSD.org> References: <53021225.4030407@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, February 17, 2014 8:44:05 am Jean-S=E9bastien P=E9dron wrote: > Hello! >=20 > I'm working on the merge of the Radeon KMS driver to stable/9, to help > with a future merge of vt(9) and the activation of WITH_NEW_XORG by > default in this branch. >=20 > Here's a first version of the merge: > http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9.a.patch >=20 > However, the current driver relies on changes to other parts of the kerne= l: >=20 > =3D=3D VM =3D=3D >=20 > In my first attempt, I merged the following revisions, which add > vm_page_alloc_contig(), used by TTM: > - 226824 > - 226848 > - 226891 > - 226928 > - 227012 > - 227072 > - 227127 > - 227568 >=20 > Here's a shorter patch containing only the VM changes: > http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9-vm.a.patch >=20 > I found the following API/ABI breakage: > o kmem_alloc_contig()'s and vm_phys_alloc_contig()'s "boundary" > argument, going from unsigned long to vm_paddr_t. > o vm_page_alloc_init() becoming a static function. > o vm_phys_bootstrap_alloc() removed. >=20 > I don't know how to proceed with this. Should TTM use another function > than vm_page_alloc_contig() to avoid the MFC? Or should the merge be > modified so that "boundary" argument keeps its unsigned long type, > vm_page_alloc_init() remains public and vm_phys_bootstrap_alloc() is not > removed? You can leave the boundary as unsigned long. The other two functions are n= ot public APIs, so I think they are fine to change. > =3D=3D atomic.h =3D=3D >=20 > I merged the following revisions, which add new atomic operations for > both amd64 and i386: > - 254610 > - 254611 > - 254617 > - 254620 >=20 > The merge was modified to not break the API/ABI. For instance, in the > original commits, some operations were transformed from a real function > to a macro using one of the new operation. >=20 > So here's shorter patch with only the changes to atomic.h: > http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9-atomic.a.pat= ch >=20 > Therefore, it only adds new code used by the Radeon driver, and I think > it's safe. Opinions on that? Looks fine. > =3D=3D iicbus =3D=3D >=20 > Revision 232365 was merged to add optional pre/post transfer methods to > iicbb, used by the Radeon driver. >=20 > Again, here's a patch limited to iicbb changes: > http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9-iic.a.patch >=20 > I think this merge is safe too, but I'm not confident enough :) Any > thoughts? This looks fine. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201402181629.46372.jhb>