Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 17 Feb 2014 14:44:05 +0100
From:      =?ISO-8859-1?Q?Jean-S=E9bastien_P=E9dron?= <dumbbell@FreeBSD.org>
To:        freebsd-stable@freebsd.org
Subject:   Radeon driver in stable/9: changes in VM, atomic.h and iicbus
Message-ID:  <53021225.4030407@FreeBSD.org>

next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JnixPL4fN9nWLPECdM2s1As19IrLIFd88
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello!

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.

Here's a first version of the merge:
http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9.a.patch

However, the current driver relies on changes to other parts of the kerne=
l:

=3D=3D VM =3D=3D

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

Here's a shorter patch containing only the VM changes:
http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9-vm.a.patch

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.

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?

=3D=3D atomic.h =3D=3D

I merged the following revisions, which add new atomic operations for
both amd64 and i386:
  - 254610
  - 254611
  - 254617
  - 254620

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.

So here's shorter patch with only the changes to atomic.h:
http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9-atomic.a.pat=
ch

Therefore, it only adds new code used by the Radeon driver, and I think
it's safe. Opinions on that?

=3D=3D iicbus =3D=3D

Revision 232365 was merged to add optional pre/post transfer methods to
iicbb, used by the Radeon driver.

Again, here's a patch limited to iicbb changes:
http://people.freebsd.org/~dumbbell/radeonkms/radeon-stable9-iic.a.patch

I think this merge is safe too, but I'm not confident enough :) Any
thoughts?

--=20
Jean-S=E9bastien P=E9dron


--JnixPL4fN9nWLPECdM2s1As19IrLIFd88
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTAhIxAAoJEDnpl2Gl/ZTM7lIP/RF1iDoNvioRfQxnRMkG4aBU
vDAtHqFNs2r6qfQhqy7sqxrfNDy0tEpTPXHP67vq2lfB0LnrrI/U+2Pz2oCVphGH
qUX8jFtR8AYAizl4I549HRXE9N0VP6BT/nRKN9xpgj3f46w6Lrq2UwopzS69EAP7
4iso+NI5LNRlBmVLqp/7elORVZwr0yGSfClg/mZJOSWwqLhs1OEfVnKkVwp+Crag
Ib4zcpIo5zFxlTQ/iRdM+BwxbV1lxE0tFw30UlGpa6nX0g1UNMefJ/oHywPBIate
gf+A81ED37nZCIJmG3kKoNH8iKSlSk4rEYBTbtIiP1QiBeg3l+ns1+hhD3GoAYgH
HQMlyiv9jf6vivB78ZC0ObTIMXPbA1xMzKmhSzA5ly+WSqsEdsbF2ywl+v7ZaDYw
d9DdAEW/Y97oRxY8eAQ/r2R2rsa9DKSSo/uc7i4EQfJZiBLRigtYmFTrKRIpf0WA
sjTGVaul9+eXXflhAkROufiSTx/XU7PkunmgdSOQNn/O141ADaXATMfXiNhpYYBQ
vkgGh9IMISIrv14zF50AempEPQoyoWM5/wH4BxhpMVp+hUzGkWjsAl2qRk2FyFqr
BrwdUHnDcIO83XoTCufXkIZypkzB9NYcTG59+wqu2UPlyr8SGgiPV5U7qGye7s4u
7lv69N1fFxZ0rYPm9Voh
=DgD0
-----END PGP SIGNATURE-----

--JnixPL4fN9nWLPECdM2s1As19IrLIFd88--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53021225.4030407>