Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 2 Nov 2010 17:26:37 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        "Jung-uk Kim" <jkim@freebsd.org>
Cc:        "Moore, Robert" <robert.moore@intel.com>, freebsd-acpi@freebsd.org, Lin Ming <ming.m.lin@intel.com>, Andriy Gapon <avg@freebsd.org>
Subject:   Re: MacBookPro 5,1
Message-ID:  <201011021726.37423.jhb@freebsd.org>
In-Reply-To: <201011021650.22657.jkim@FreeBSD.org>
References:  <201010121209.06397.hselasky@c2i.net> <201011021624.38882.jhb@freebsd.org> <201011021650.22657.jkim@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, November 02, 2010 4:50:18 pm Jung-uk Kim wrote:
> On Tuesday 02 November 2010 04:24 pm, John Baldwin wrote:
> > On Tuesday, November 02, 2010 4:14:05 pm Jung-uk Kim wrote:
> > > On Tuesday 02 November 2010 03:41 pm, John Baldwin wrote:
> > > > On Tuesday, November 02, 2010 3:29:01 pm Jung-uk Kim wrote:
> > > > > On Tuesday 02 November 2010 11:29 am, Andriy Gapon wrote:
> > > > > > on 29/10/2010 08:51 Andriy Gapon said the following:
> > > > > > > I guess that a general problem here is that it is
> > > > > > > incorrect to merely use memcpy/bcopy to create a copy of
> > > > > > > a resource if the resource has ACPI_RESOURCE_SOURCE field
> > > > > > > in it.
> > > > > >
> > > > > > Hans,
> > > > > >
> > > > > > could you please test the following patch?
> > > > > >
> > > > > > diff --git a/sys/dev/acpica/acpi_pci_link.c
> > > > > > b/sys/dev/acpica/acpi_pci_link.c index dcf101d..e842635
> > > > > > 100644 --- a/sys/dev/acpica/acpi_pci_link.c
> > > > > > +++ b/sys/dev/acpica/acpi_pci_link.c
> > > > > > @@ -767,6 +767,8 @@ acpi_pci_link_srs_from_crs
> > > > > >  				    link->l_irq;
> > > > > >  			else
> > > > > >  				resptr->Data.ExtendedIrq.Interrupts[0] = 0;
> > > > > > +			memset(&resptr->Data.ExtendedIrq.ResourceSource, 0,
> > > > > > +			    sizeof(ACPI_RESOURCE_SOURCE));
> > > > > >  			link++;
> > > > > >  			i++;
> > > > > >  			break;
> > > > >
> > > > > Hmm...  Very interesting.  Can you please try this, too?
> > > >
> > > > Linux doesn't set the resource source bits up at all when doing
> > > > _SRS, so I'd rather just do that.  I think what I'd prefer is
> > > > that we not use the prs_template, perhaps just save the type of
> > > > the resource and build a new resource object from scratch where
> > > > the resource is zero'd, the appropriate bits are set and then
> > > > that resource is appended to the buffer being built.
> > >
> > > "Linux doesn't do it" is wrong if I am reading the spec.
> > > correctly, i.e., _CRS, _PRS and _SRS must have the same format
> > > and size.
> >
> > Umm, but we aren't setting up the raw bits for _SRS.  We are
> > creating a list of ACPI_RESOURCE objects that ACPICA then encodes
> > into a buffer to send to _SRS.
> 
> Yes, I understand.  However, ACPICA is expecting the same size of 
> buffer *including* the optional parts if I am reading the code right.  
> Besides, I don't think there is any harm in doing the right 
> thing. ;-)

To be clear, I am suggesting to take an ACPI_RESOURCE object, bzero it,
then set the type and the IRQ and that's it.  Leave the ResourceSource
bits as zero.  The size will still be set based on the actual type (or
if needed we can use the cached size from the template copy we save from
_PRS).  The point would be to start from a zero structure instead of
from a copy of what we got from _PRS.

-- 
John Baldwin



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