Date: Wed, 11 Dec 2013 14:48:38 +0100 From: Marius Strobl <marius@alchemy.franken.de> To: Justin Hibbits <chmeeedalf@gmail.com> Cc: Justin Hibbits <jhibbits@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: Request for testing an alternate branch Message-ID: <20131211134838.GM12343@alchemy.franken.de> In-Reply-To: <20131208154854.7425d9a7@zhabar.gateway.2wire.net> References: <20131204222113.39fb23dd@zhabar.gateway.2wire.net> <20131208133853.GA75604@alchemy.franken.de> <20131208154854.7425d9a7@zhabar.gateway.2wire.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 08, 2013 at 03:48:54PM -0800, Justin Hibbits wrote: > On Sun, 8 Dec 2013 14:38:53 +0100 > Marius Strobl <marius@alchemy.franken.de> wrote: > > > On Wed, Dec 04, 2013 at 10:21:13PM -0800, Justin Hibbits wrote: > > > I've been working on the projects/pmac_pmu branch for some time now > > > to add suspend/resume as well as CPU speed change for certain > > > PowerPC machines, about a year since I created the branch, and now > > > it's stable enough that I want to merge it into HEAD, hence this > > > request. However, it does touch several drivers, turning them into > > > "early drivers", such that they can be initialized, and suspended > > > and resumed at a different time. Saying that, I do need testing > > > from other architectures, to make sure I haven't broken anything. > > > > > > The technical details: > > > > > > To get proper ordering, I've extended the bus_generic_suspend() and > > > bus_generic_resume() to do multiple passes. Devices which cannot be > > > enabled or disabled at the current pass level would return an > > > EAGAIN. This could possibly cause problems, since it's an addition > > > to an existing API rather than a new API to run along side it, so > > > it needs a great deal of testing. It works fine on PowerPC, but I > > > don't have any i386/amd64 or sparc64 hardware to test it on, so > > > would like others who do to test it. I don't think that it would > > > impact x86 at all (testing is obviously required), because the > > > nexus is not an EARLY_DRIVER_MODULE, so all devices would be > > > handled at the same pass. But, I do know the sparc64 has an > > > EARLY_DRIVER_MODULE() nexus, so that will likely be impacted. > > > > > > Also, any comments are of course welcome. Technical concerns are > > > obviously welcome, and I will try to address everything. > > > > Do you have a patch against head? > > > > Marius > > > > Here you go. > Thanks; on a sparc64 machine where the EARLY_DRIVER_MODULE nexus actually matters, your patch doesn't seem to have an ill effect. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131211134838.GM12343>