On Thursday, December 04, 2014 10:48:19 AM Grant Likely wrote:
> On Tue, 25 Nov 2014 22:40:53 +0100
> , "Rafael J. Wysocki"
> wrote:
> > On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
> > >
> > > --ReaqsoxgOBHFXBhH
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Dispo
On Thu, Dec 04, 2014 at 10:48:19AM +, Grant Likely wrote:
> On Tue, 25 Nov 2014 22:40:53 +0100
> > We absolutely need to start registering the existing bindings in there, but
> > that needs to be rate limited somehow, because the process may not be very
> > efficient to start with.
> Beyond h
On Thu, Dec 04, 2014 at 11:12:34AM +, Grant Likely wrote:
> On Sat, 29 Nov 2014 23:27:52 +0100
> > There basically are two ways around that. The first one is to have all
> > knowledge related to device IDs in drivers (which effectively is what
> > Windows does and which implies "board files"
On Sat, 29 Nov 2014 23:27:52 +0100
, "Rafael J. Wysocki"
wrote:
> On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
> >
> > --9GYGtdBumnmR69ER
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Sat
On Tue, 25 Nov 2014 22:40:53 +0100
, "Rafael J. Wysocki"
wrote:
> On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
> >
> > --ReaqsoxgOBHFXBhH
> > Content-Type: text/plain; charset=us-ascii
> > Content-Disposition: inline
> >
> > On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wys
On Monday, December 01, 2014 10:19:07 PM Mark Brown wrote:
> On Mon, Dec 01, 2014 at 11:16:31PM +0100, Rafael J. Wysocki wrote:
> > On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
>
> > > The dream here is that people working on building systems, people
> > > working on Windows drivers
On Mon, Dec 01, 2014 at 11:16:31PM +0100, Rafael J. Wysocki wrote:
> On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
> > The dream here is that people working on building systems, people
> > working on Windows drivers and people working on Linux drivers will at
> > some point be able to
On Monday, December 01, 2014 05:51:00 PM Mark Brown wrote:
>
> --MRL9B5bOucwGAkwp
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Sat, Nov 29, 2014 at 11:27:52PM +0100, Rafael J. Wysocki wrote:
> > On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
>
>
On Sat, Nov 29, 2014 at 11:27:52PM +0100, Rafael J. Wysocki wrote:
> On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
> > > There's the PRP0001 ID that can be use to in combination with the
> > > "compatible" property which then works the same way as for DT.
> > > That should be suffi
On Saturday, November 29, 2014 11:52:09 AM Mark Brown wrote:
>
> --9GYGtdBumnmR69ER
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
> > On Friday, Novemb
On Sat, Nov 29, 2014 at 12:51:59AM +0100, Rafael J. Wysocki wrote:
> On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
> > OK, we probably should have one to aid discoverability since as far as I
> > can tell what's happening is that people (hi Intel!) are allocating
> > their own identif
On Friday, November 28, 2014 04:00:36 PM Mark Brown wrote:
>
> --k9ssVBY1NpawPNl1
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Nov 27, 2014 at 12:09:55AM +0100, Rafael J. Wysocki wrote:
> > On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
>
On Thu, Nov 27, 2014 at 12:09:55AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
> > > As to registering ACPI IDs, I believe this is the right link:
> > > http://www.uefi.org/PNP_ACPI_Registry
> > No, those are vendors as far as I can tell. I mea
On Wednesday, November 26, 2014 11:17:16 AM Mark Brown wrote:
>
> --4mL5lf+nIvB09VHj
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Nov 25, 2014 at 05:48:24PM -0800, Darren Hart wrote:
> > On 11/25/14 10:43, Mark Brown wrote:
>
> > > Link from where - do w
On Tue, Nov 25, 2014 at 05:48:24PM -0800, Darren Hart wrote:
> On 11/25/14 10:43, Mark Brown wrote:
> > Link from where - do we want to talk to the ACPI/UEFI forum and
> > figure out some kind of fast track process for them to add an "it's
> > already covered by DT, see here" entry to their databa
On 11/25/14 10:43, Mark Brown wrote:
> On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
>> On 11/25/14 09:21, Mark Brown wrote:
>
>>> Given the design of _DSD is to share with DT and we already
>>> have device tree bindings for the device we should be using,
>>> it's not clear to me
On Tue, Nov 25, 2014 at 02:41:28PM -0800, Ben Zhang wrote:
> +Duncan who works on our firmware project.
>
> Please correct me if I'm wrong. Here is the summary of what I understand.
> Looks
> like the recommended practice for passing device platform data is using _DSD
> and
> the new device_prop
+Duncan who works on our firmware project.
Please correct me if I'm wrong. Here is the summary of what I understand. Looks
like the recommended practice for passing device platform data is using _DSD and
the new device_property_read_ API from include/linux/property.h
For example, the firmware (co
On Tue, Nov 25, 2014 at 10:40:53PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
> > My initial thought would be to require that we send any DT properties
> > defined for devices with ACPI identifiers registered there and hope the
> > volume doesn't
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
>
> --ReaqsoxgOBHFXBhH
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
>
On Tue, Nov 25, 2014 at 09:31:27PM +0100, Rafael J. Wysocki wrote:
> On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
> > This is a current topic with the ACPI working group. We have the
> > following document:
> > http://www.uefi.org/sites/default/files/resources/_DSD-device-properti
On Tuesday, November 25, 2014 07:36:23 PM Mark Brown wrote:
>
> --njUEgrJvs9ryr/H/
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Nov 25, 2014 at 11:07:06AM -0800, Darren Hart wrote:
> > On 11/25/14 10:43, Mark
On Tuesday, November 25, 2014 11:07:06 AM Darren Hart wrote:
>
> On 11/25/14 10:43, Mark Brown wrote:
> > On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
> >> On 11/25/14 09:21, Mark Brown wrote:
> >
> >>> Given the design of _DSD is to share with DT and we already
> >>> have device
On Tue, Nov 25, 2014 at 11:07:06AM -0800, Darren Hart wrote:
> On 11/25/14 10:43, Mark Brown wrote:
> > Link from where - do we want to talk to the ACPI/UEFI forum and
> > figure out some kind of fast track process for them to add an
> > "it's already covered by DT, see here" entry to their datab
On 11/25/14 10:43, Mark Brown wrote:
> On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
>> On 11/25/14 09:21, Mark Brown wrote:
>
>>> Given the design of _DSD is to share with DT and we already
>>> have device tree bindings for the device we should be using,
>>> it's not clear to m
On Tue, Nov 25, 2014 at 10:33:01AM -0800, Darren Hart wrote:
> On 11/25/14 09:21, Mark Brown wrote:
> > Given the design of _DSD is to share with DT and we already have
> > device tree bindings for the device we should be using, it's not
> > clear to me if we want to grind them all through UEFI an
On 11/25/14 09:21, Mark Brown wrote:
> On Tue, Nov 25, 2014 at 08:00:12AM -0800, Darren Hart wrote:
>> On 11/25/14 04:11, Grant Likely wrote:
>
>>> Also, since this patch is targeted at v3.19 or later, the
>>> device-properties API should be used. Don't create something
>>> custom.
>
>> Right.
On Tue, Nov 25, 2014 at 08:00:12AM -0800, Darren Hart wrote:
> On 11/25/14 04:11, Grant Likely wrote:
> > Also, since this patch is targeted at v3.19 or later, the
> > device-properties API should be used. Don't create something custom.
> Right. The ACPI/UEFI forum is managing the creation of new
On 11/25/14 04:11, Grant Likely wrote:
> On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote:
>> The rt5677 codec driver looks for ACPI device ID "RT5677CE",
>> which is specified in coreboot. This patch allows platform
>> data to be obtained via ACPI
>>
>> Signed-off-by: Ben Zhang
>
> This looks
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang wrote:
> The rt5677 codec driver looks for ACPI device ID "RT5677CE",
> which is specified in coreboot. This patch allows platform
> data to be obtained via ACPI
>
> Signed-off-by: Ben Zhang
This looks like an ideal time to talk about shared DT and ACPI
On Fri, Nov 14, 2014 at 10:56:47PM -0800, Ben Zhang wrote:
> The rt5677 codec driver looks for ACPI device ID "RT5677CE",
> which is specified in coreboot. This patch allows platform
> data to be obtained via ACPI
This actually does two things - it adds the ACPI device probing and it
adds the ACP
31 matches
Mail list logo
