From owner-freebsd-stable@FreeBSD.ORG Tue Feb 18 21:38:27 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FBA59FD; Tue, 18 Feb 2014 21:38:27 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45F4C17F0; Tue, 18 Feb 2014 21:38:27 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4D2A9B9A6; Tue, 18 Feb 2014 16:38:26 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Subject: Re: Radeon driver in stable/9: changes in VM, atomic.h and iicbus Date: Tue, 18 Feb 2014 16:29:46 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <53021225.4030407@FreeBSD.org> In-Reply-To: <53021225.4030407@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201402181629.46372.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 18 Feb 2014 16:38:26 -0500 (EST) Cc: =?iso-8859-15?q?Jean-S=E9bastien?= =?iso-8859-15?q?_P=E9dron?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:38:27 -0000 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