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
> > >
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
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
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.
On Tue, 25 Nov 2014 22:40:53 +0100
, Rafael J. Wysocki r...@rjwysocki.net
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.
On Sat, 29 Nov 2014 23:27:52 +0100
, Rafael J. Wysocki r...@rjwysocki.net
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
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 of
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 having
On Thursday, December 04, 2014 10:48:19 AM Grant Likely wrote:
On Tue, 25 Nov 2014 22:40:53 +0100
, Rafael J. Wysocki r...@rjwysocki.net
wrote:
On Tuesday, November 25, 2014 08:27:22 PM Mark Brown wrote:
--ReaqsoxgOBHFXBhH
Content-Type: text/plain; charset=us-ascii
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
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
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 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 and
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 sufficient if
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 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,
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
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 identifiers
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, November 28,
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
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 mean
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:
As
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
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
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 database for
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 we want to
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
+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
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:
> >
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
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
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
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
On Tue, 2014-11-25 at 08:01 -0800, Darren Hart wrote:
>
> On 11/25/14 06:28, Liam Girdwood wrote:
> > On Tue, 2014-11-25 at 12: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
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.
>
>>
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
On 11/25/14 06:28, Liam Girdwood wrote:
> On Tue, 2014-11-25 at 12: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
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
On Tue, 2014-11-25 at 12: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
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
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
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 ACPI
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org 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 be...@chromium.org
This looks like an ideal time to
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org 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:
On 11/25/14 04:11, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org 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
On 11/25/14 06:28, Liam Girdwood wrote:
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote:
The rt5677 codec driver looks for ACPI device ID RT5677CE,
which is specified in coreboot. This patch allows platform
data to
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 DSD
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. The ACPI/UEFI
On Tue, 2014-11-25 at 08:01 -0800, Darren Hart wrote:
On 11/25/14 06:28, Liam Girdwood wrote:
On Tue, 2014-11-25 at 12:11 +, Grant Likely wrote:
On Sat, Nov 15, 2014 at 6:56 AM, Ben Zhang be...@chromium.org wrote:
The rt5677 codec driver looks for ACPI device ID RT5677CE,
which is
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 and I
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 if we want
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 database for
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 tree bindings
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 Brown
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:
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:
This
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 DoS
+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
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
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 if we want
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
---
sound/soc/codecs/rt5677.c | 52 +--
1 file changed, 50 insertions(+), 2
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 be...@chromium.org
---
sound/soc/codecs/rt5677.c | 52 +--
1 file changed, 50
70 matches
Mail list logo
