Re: [edk2] [RFC] ACPI table HID/CID allocation

> >> Hmnnn it sounds like jedec,spi-nor meets this test. > >> > >> There is only one property in the DT bindings that describes the > >> device itself (fast read support) rather than its "bus address" (chip > >> select, frequency). Further, that single property is obsolete, at > >> least for L

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 25/11/17 12:56, Udit Kumar wrote:>> -Original Message- From: Daniel Thompson [mailto:daniel.thomp...@linaro.org] Sent: Thursday, November 23, 2017 1:42 AM To: Ard Biesheuvel Cc: Udit Kumar ; Leif Lindholm ; edk2-devel@lists.01.org; Varun Sethi ; Graeme Gregory Subject: Re: [RFC] ACPI

Re: [edk2] [RFC] ACPI table HID/CID allocation

Hi Andrew > Udit, > > I think it is more like you only need ACPI if you don't have a driver. Ok, then ACPI or say firmware needs to export AML methods, which are known to OS. > If it is standard bus with standard drivers the OS code can do power > management > without any help from ACPI.

Re: [edk2] [RFC] ACPI table HID/CID allocation

> On Nov 25, 2017, at 4:56 AM, Udit Kumar wrote: > > > >> -Original Message- >> From: Daniel Thompson [mailto:daniel.thomp...@linaro.org] >> Sent: Thursday, November 23, 2017 1:42 AM >> To: Ard Biesheuvel >> Cc: Udit Kumar ; Leif Lindholm >> ; edk2-devel@lists.01.org; Varun Sethi >> ;

Re: [edk2] [RFC] ACPI table HID/CID allocation

> -Original Message- > From: Daniel Thompson [mailto:daniel.thomp...@linaro.org] > Sent: Thursday, November 23, 2017 1:42 AM > To: Ard Biesheuvel > Cc: Udit Kumar ; Leif Lindholm > ; edk2-devel@lists.01.org; Varun Sethi > ; Graeme Gregory > Subject: Re: [RFC] ACPI table HID/CID allocati

Re: [edk2] [RFC] ACPI table HID/CID allocation

> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, November 23, 2017 1:10 AM > To: Daniel Thompson > Cc: Udit Kumar ; Leif Lindholm > ; edk2-devel@lists.01.org; Varun Sethi > ; Graeme Gregory > Subject: Re: [RFC] ACPI table HID/CID allocatio

Re: [edk2] [RFC] ACPI table HID/CID allocation

methods to be implemented. Regards Udit From: af...@apple.com [mailto:af...@apple.com] Sent: Wednesday, November 22, 2017 11:05 PM To: Udit Kumar Cc: Daniel Thompson ; Ard Biesheuvel ; edk2-devel@lists.01.org; Leif Lindholm Subject: Re: [edk2] [RFC] ACPI table HID/CID allocation FYI now that the

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 22/11/17 19:39, Ard Biesheuvel wrote: On 22 November 2017 at 11:30, Daniel Thompson wrote: On 21/11/17 18:10, Udit Kumar wrote: Thanks Ard, For internal SOC devices, this is perfectly ok to drop PRP0001 from CID. This could be a valid reason to use PRP0001 + compatible, for things like I

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 22 November 2017 at 11:30, Daniel Thompson wrote: > On 21/11/17 18:10, Udit Kumar wrote: >> >> Thanks Ard, >> For internal SOC devices, this is perfectly ok to drop PRP0001 from CID. >> >>> This could be a valid reason to use PRP0001 + compatible, for things like >>> I2C >>> slaves that are ext

Re: [edk2] [RFC] ACPI table HID/CID allocation

FYI now that the UEFI Forum owns the ACPI Spec here is the location to register a new PNP ID or ACPI ID: https://stash.sd.apple.com/projects/COREOSMACFW/repos/macefifirmware/pull-requests/630/overview

Re: [edk2] [RFC] ACPI table HID/CID allocation

Hi Daniel > > For external devices (for which HID is not available), you suggest to > > go with PRP0001 + compatible or that device driver needs add ACPI HID > support. > > I don't think internal or external to the SoC would be any kind of deciding > factor > in how to best to bind, simply bec

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 21/11/17 18:10, Udit Kumar wrote: Thanks Ard, For internal SOC devices, this is perfectly ok to drop PRP0001 from CID. This could be a valid reason to use PRP0001 + compatible, for things like I2C slaves that are external to the SoC For external devices (for which HID is not available), yo

Re: [edk2] [RFC] ACPI table HID/CID allocation

Thanks Ard, For internal SOC devices, this is perfectly ok to drop PRP0001 from CID. > This could be a valid reason to use PRP0001 + compatible, for things like I2C > slaves that are external to the SoC For external devices (for which HID is not available), you suggest to go with PRP0001 + comp

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 13:24, Udit Kumar wrote: > Thanks Ard, > > My intend of this email to know, what is right way to define HID and CID in > ACPI firmware i.e > > Device(XYZ) { > Name(_HID, "NXP0001") > Name(_CID, "PRP0001") > Device(Slave1) { >

Re: [edk2] [RFC] ACPI table HID/CID allocation

Thanks Ard, My intend of this email to know, what is right way to define HID and CID in ACPI firmware i.e Device(XYZ) { Name(_HID, "NXP0001") Name(_CID, "PRP0001") Device(Slave1) { Name(_CID, "PRP0001")

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 11:32, Udit Kumar wrote: > >> On 21 November 2017 at 09:59, Udit Kumar wrote: >> > Thanks Ard. >> > Below table was for example. I am not converting whole DT to ACPI >> > tables :) My idea is to reduce Linux patches for probing as possible. >> > Also keeping firmware and OS

Re: [edk2] [RFC] ACPI table HID/CID allocation

> On 21 November 2017 at 09:59, Udit Kumar wrote: > > Thanks Ard. > > Below table was for example. I am not converting whole DT to ACPI > > tables :) My idea is to reduce Linux patches for probing as possible. > > Also keeping firmware and OS separately then Let firmware expose both > > way (HID

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 09:59, Udit Kumar wrote: > Thanks Ard. > Below table was for example. I am not converting whole DT to ACPI tables :) > My idea is to reduce Linux patches for probing as possible. > Also keeping firmware and OS separately then > Let firmware expose both way (HID and PRP1)

Re: [edk2] [RFC] ACPI table HID/CID allocation

Thanks Ard. Below table was for example. I am not converting whole DT to ACPI tables :) My idea is to reduce Linux patches for probing as possible. Also keeping firmware and OS separately then Let firmware expose both way (HID and PRP1) and Linux to decide binding Please see inline as wel

Re: [edk2] [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 09:19, Udit Kumar wrote: > Hi, > > I am enabling ACPI on NXP platform , In order to do minimal changes in Linux > driver for device-driver binding. > > I want to use PRP0001 device as CID and HID as actual (NXP allocated HID). > > So that Linux can bind with PRP0001 and com

[edk2] [RFC] ACPI table HID/CID allocation

Hi, I am enabling ACPI on NXP platform , In order to do minimal changes in Linux driver for device-driver binding. I want to use PRP0001 device as CID and HID as actual (NXP allocated HID). So that Linux can bind with PRP0001 and compatible field, where as other OS (Window etc) can rely on HI