Date: Tue, 04 Jul 2017 11:17:01 +0200 From: M&T Marketing <newsletter@m-t.co.za> To: freebsd-arch@freebsd.org Subject: Development in Centurion Message-ID: <201707041111416.11884.556@m-t.co.za>
next in thread | raw e-mail | index | archive | help
M%26T_Header.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344203 ) Centurion Peach_Orchard__Logo.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344204 ) Facilities.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344205 ) Peach_Orchard_Stacks_image.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344206 ) Peach_Orchard_Prices.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344207 ) Ben 078 784 9901 ben@m-t.co.za ( ben@m-t.co.za?subject=Peach%20Orchard%20e-mail%20newsletter%20enquiry ) Key_places_in_the_area.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344208 ) Peach-Orchard_MAP.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344209 ) Show_Times.jpg ( http://comms.m-tdevelopment-mail.com/servlet/link/9695/31907/58966527/344210 ) From owner-freebsd-arch@freebsd.org Tue Jul 4 23:17:25 2017 Return-Path: <owner-freebsd-arch@freebsd.org> Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD9E4D9CFD0 for <freebsd-arch@mailman.ysv.freebsd.org>; Tue, 4 Jul 2017 23:17:25 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48A6C66836 for <freebsd-arch@freebsd.org>; Tue, 4 Jul 2017 23:17:24 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e93532a2-610e-11e7-b2f5-7fbc454a3a22 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e93532a2-610e-11e7-b2f5-7fbc454a3a22; Tue, 04 Jul 2017 23:17:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v64NHCA7001802 for <freebsd-arch@FreeBSD.org>; Tue, 4 Jul 2017 17:17:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1499210232.4402.7.camel@freebsd.org> Subject: Changes to realtime clock/time-of-day clock support for review From: Ian Lepore <ian@freebsd.org> To: "freebsd-arch@FreeBSD.org" <freebsd-arch@FreeBSD.org> Date: Tue, 04 Jul 2017 17:17:12 -0600 Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>; List-Post: <mailto:freebsd-arch@freebsd.org> List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>, <mailto:freebsd-arch-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 04 Jul 2017 23:17:25 -0000 FYI, I've put up two related phab reviews for changes to realtime clock support. https://reviews.freebsd.org/D11483 https://reviews.freebsd.org/D11484 D11483 changes some amd64 EFI code to use a hardware-specific mutex instead of the registered-clock mutex when accessing the atrtc hardware clock; this just clears the way for the main change. The main change in D11484 adds support for multiple concurrent realtime clocks, and eliminates restrictions on locking and sleeping in the clock driver gettime and settime methods. The sleeping restriction has been especially problematic for systems using an i2c realtime clock chip, as i2c bus access often requires sleeping. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201707041111416.11884.556>