Skip site navigation (1)Skip section navigation (2)
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>