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

2017-11-27 Thread Udit Kumar
> >> 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

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

2017-11-27 Thread Daniel Thompson
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 ;

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

2017-11-26 Thread Udit Kumar
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

2017-11-25 Thread Andrew Fish
> 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

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

2017-11-25 Thread Udit Kumar
> -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

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

2017-11-25 Thread Udit Kumar
> -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

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

2017-11-25 Thread Udit Kumar
org; Leif Lindholm <leif.lindh...@linaro.org> Subject: 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-req

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

2017-11-22 Thread Daniel Thompson
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 +

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

2017-11-22 Thread Ard Biesheuvel
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

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

2017-11-22 Thread Andrew Fish
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

2017-11-22 Thread Udit Kumar
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

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

2017-11-22 Thread Daniel Thompson
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),

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

2017-11-21 Thread Udit Kumar
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 +

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

2017-11-21 Thread Ard Biesheuvel
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") >

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

2017-11-21 Thread Udit Kumar
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

2017-11-21 Thread Ard Biesheuvel
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

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

2017-11-21 Thread Udit Kumar
> 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

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

2017-11-21 Thread Ard Biesheuvel
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

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

2017-11-21 Thread Udit Kumar
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

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

2017-11-21 Thread Ard Biesheuvel
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