[RFC] ACPI table HID/CID allocation

[RFC] ACPI table HID/CID allocation

[Udit Kumar]

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 HID.

Below is sample, ACPI table for SPI controller and its slave device.



Hope this approach is ok ?



Thanks

Udit





Scope(_SB)

{

        Device(SPI0) {

                Name(_HID, "NXP0001")

                Name(_CID, "PRP0001")

                Name(_CRS, ResourceTemplate() {

                        }) // end of _CRS for i2c0 device

                Name (_DSD, Package () {

                        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

                                Package () {

                                Package() {"compatible", " fsl,ls2085a-dspi"},

                        }

                }) // end of DSD SPI device

                Device (EEP0) {

                        Name(_HID, " NXP0002")  //HID can be discussed with flash vendor

                        Name(_CID, "PRP0001") // m25p80 flash

                        Name(_CRS, ResourceTemplate()

                        {

                               SPISerialBus(....)

                        }) // ResourceTemplate()

                        Name (_DSD, Package () {

                                ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),

                                        Package () {

                                        Package() {"compatible", "st,m25p80"},

                        }

                } // End of e2prom device

        } // end of SPI device

}

Re: [RFC] ACPI table HID/CID allocation

[Ard Biesheuvel]

On 21 November 2017 at 09:19, Udit Kumar <udit.kumar@nxp.com> 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  compatible field, where as other OS
> (Window etc) can rely on HID.
>
> Below is sample, ACPI table for SPI controller and its slave device.
>
>
>
> Hope this approach is ok ?
>

No, it is not.

Architecting an ACPI platform is not a matter of taking a device tree
and converting each node into an ACPI device.

Linux/DT makes no assumptions about the presence of firmware. This
means most device drivers have to manage clocks, regulators etc
because they will not be in a known state. Also, the OS can own all
devices in the system.

Linux/ACPI relies on the firmware to set up clocks and regulators, and
uses abstract firmware methods to manage power states etc. Also, due
to the dependency on UEFI, things like the RTC and NOR flash are not
exposed to the OS via device nodes, but via UEFI runtime services.

In a nutshell, the difference between ACPI and DT is that the handoff
point between the OS and the firmware is at a different abstraction
level.

So no, it is not ok to use PRP0001 + compatible for everything. It may
be acceptable in some exceptional cases, but you will have to explain
why. Everything else should use proper ACPI bindings.

-- 
Ard.

Re: [RFC] ACPI table HID/CID allocation

[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 PRP00001) and Linux to decide binding 
Please see inline as well 

Regards
Udit

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Tuesday, November 21, 2017 3:08 PM
> To: Udit Kumar <udit.kumar@nxp.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
> Graeme Gregory <graeme.gregory@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 21 November 2017 at 09:19, Udit Kumar <udit.kumar@nxp.com> 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  compatible field, where as
> > other OS (Window etc) can rely on HID.
> >
> > Below is sample, ACPI table for SPI controller and its slave device.
> >
> >
> >
> > Hope this approach is ok ?
> >
> 
> No, it is not.
> 
> Architecting an ACPI platform is not a matter of taking a device tree and
> converting each node into an ACPI device.

No , no, Here I am not converting everything from DT to ACPI
 
> Linux/DT makes no assumptions about the presence of firmware. This means
> most device drivers have to manage clocks, regulators etc because they will not
> be in a known state. Also, the OS can own all devices in the system.

Thanks to Linux documentation , I noted this, During hand off ACPI
firmware needs to ensure proper clocking. 
 
> Linux/ACPI relies on the firmware to set up clocks and regulators, and uses
> abstract firmware methods to manage power states etc. Also, due to the
> dependency on UEFI, things like the RTC and NOR flash are not exposed to the
> OS via device nodes, but via UEFI runtime services.

Agreed, RTC and NOR (containing firmware)  should not exposed to Linux or OS. 
 
> In a nutshell, the difference between ACPI and DT is that the handoff point
> between the OS and the firmware is at a different abstraction level.
> 
> So no, it is not ok to use PRP0001 + compatible for everything. It may be
> acceptable in some exceptional cases, but you will have to explain why.
> Everything else should use proper ACPI bindings.

HID is not going away , I am keeping with PRP0001 + compatible
and let linux driver to decide what to use. 

If PRP0001 + compatible is restricted or meant for limited use
then I can assign HID for NXP devices or say driver managed by NXP.
For other vendors, will this be accepted to have HID something like NXP00xx  ??
 
> --
> Ard.

Re: [RFC] ACPI table HID/CID allocation

[Ard Biesheuvel]

On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com> 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 PRP00001) and Linux to decide binding

No.

You are still assuming ACPI and DT device drivers bind at the same
level, and they don't.

An ACPI device has AML methods to manage power state and perform other
device related low-level tasks. The device driver has no knowledge of
the hardware beyond what it needs to invoke those abstract methods.

A DT device describes everything in detail, and requires clock and
regulator drivers and other bits and pieces that are tightly coupled
to details of the hardware.

So now, you have the worst of both worlds:

- you need to implement all of this in firmware so ACPI can support it,
- you have to expose the internals to the OS so DT can support it.

The result is that you lose *all* of the benefits of ACPI, because the
power of the abstraction is that you can modify the low-level
implementation on the firmware side without the need for modifying the
OS. *That* is the value proposition of ACPI, the ability to run last
year's OS on this year's hardware.

Implementing ACPI in the way you propose is absolutely pointless,
sorry to be harsh about it.

-- 
Ard.


> Please see inline as well
>
> Regards
> Udit
>
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> Sent: Tuesday, November 21, 2017 3:08 PM
>> To: Udit Kumar <udit.kumar@nxp.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
>> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
>> Graeme Gregory <graeme.gregory@linaro.org>
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>
>> On 21 November 2017 at 09:19, Udit Kumar <udit.kumar@nxp.com> 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  compatible field, where as
>> > other OS (Window etc) can rely on HID.
>> >
>> > Below is sample, ACPI table for SPI controller and its slave device.
>> >
>> >
>> >
>> > Hope this approach is ok ?
>> >
>>
>> No, it is not.
>>
>> Architecting an ACPI platform is not a matter of taking a device tree and
>> converting each node into an ACPI device.
>
> No , no, Here I am not converting everything from DT to ACPI
>
>> Linux/DT makes no assumptions about the presence of firmware. This means
>> most device drivers have to manage clocks, regulators etc because they will not
>> be in a known state. Also, the OS can own all devices in the system.
>
> Thanks to Linux documentation , I noted this, During hand off ACPI
> firmware needs to ensure proper clocking.
>
>> Linux/ACPI relies on the firmware to set up clocks and regulators, and uses
>> abstract firmware methods to manage power states etc. Also, due to the
>> dependency on UEFI, things like the RTC and NOR flash are not exposed to the
>> OS via device nodes, but via UEFI runtime services.
>
> Agreed, RTC and NOR (containing firmware)  should not exposed to Linux or OS.
>
>> In a nutshell, the difference between ACPI and DT is that the handoff point
>> between the OS and the firmware is at a different abstraction level.
>>
>> So no, it is not ok to use PRP0001 + compatible for everything. It may be
>> acceptable in some exceptional cases, but you will have to explain why.
>> Everything else should use proper ACPI bindings.
>
> HID is not going away , I am keeping with PRP0001 + compatible
> and let linux driver to decide what to use.
>
> If PRP0001 + compatible is restricted or meant for limited use
> then I can assign HID for NXP devices or say driver managed by NXP.
> For other vendors, will this be accepted to have HID something like NXP00xx  ??
>
>> --
>> Ard.

Re: [RFC] ACPI table HID/CID allocation

[Udit Kumar]

 
> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com> 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 PRP00001) and Linux to decide binding
> 
> No.
> 
> You are still assuming ACPI and DT device drivers bind at the same level, and
> they don't.

No, my above comments was just limited to binding. 
Right, here device driver should know that device is present in system, 
I see probe function (device-driver binding) is way to know this. 
Then driver can execute AML methods exposed by firmware.
 
> An ACPI device has AML methods to manage power state and perform other
> device related low-level tasks. The device driver has no knowledge of the
> hardware beyond what it needs to invoke those abstract methods.

You meant, If we need to update driver for AML methods then why not to update binding as well . ?

On side track, 
 With limited search,  I got many each driver is having (acpi_id and of_id), 
looks, acpi support is added on the top of DT flavored drivers.
and therefore acpi tables are following the same.
Sorry to say, reference I am looking at (edk2-platform) JunoPkg and VExpressPkg, 
Has following devices has description similar to Device tree 
    Device (NET0) {
    Device (SREG) {
    Device (VIRT) {
   Device(KMI0) {
   Device(ETH0) {
Where no AML method is exposed. Then I expect OS driver to manage this device.
While grepping over few other edk2-platforms.  Looks some of methods 
are abstracted, not whole device. 


> A DT device describes everything in detail, and requires clock and regulator
> drivers and other bits and pieces that are tightly coupled to details of the
> hardware.
> 
> So now, you have the worst of both worlds:
> 
> - you need to implement all of this in firmware so ACPI can support it,
> - you have to expose the internals to the OS so DT can support it.

Yes, for time being or may be longer, DT support needs to be there 
along with ACPI introduction.

Are you suggesting here to abstract whole device details from 
OS and expose AML methods to be used by device driver. 
And maintain two drivers instead of fitting DT style driver into ACPI world ?
 
> The result is that you lose *all* of the benefits of ACPI, because the power of
> the abstraction is that you can modify the low-level implementation on the
> firmware side without the need for modifying the OS. *That* is the value
> proposition of ACPI, the ability to run last year's OS on this year's hardware.


> Implementing ACPI in the way you propose is absolutely pointless, sorry to be
> harsh about it.
> 
> --
> Ard.
> 
> 
> > Please see inline as well
> >
> > Regards
> > Udit
> >
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: Tuesday, November 21, 2017 3:08 PM
> >> To: Udit Kumar <udit.kumar@nxp.com>
> >> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
> >> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
> >> Graeme Gregory <graeme.gregory@linaro.org>
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 09:19, Udit Kumar <udit.kumar@nxp.com> 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  compatible field, where as
> >> > other OS (Window etc) can rely on HID.
> >> >
> >> > Below is sample, ACPI table for SPI controller and its slave device.
> >> >
> >> >
> >> >
> >> > Hope this approach is ok ?
> >> >
> >>
> >> No, it is not.
> >>
> >> Architecting an ACPI platform is not a matter of taking a device tree and
> >> converting each node into an ACPI device.
> >
> > No , no, Here I am not converting everything from DT to ACPI
> >
> >> Linux/DT makes no assumptions about the presence of firmware. This means
> >> most device drivers have to manage clocks, regulators etc because they will
> not
> >> be in a known state. Also, the OS can own all devices in the system.
> >
> > Thanks to Linux documentation , I noted this, During hand off ACPI
> > firmware needs to ensure proper clocking.
> >
> >> Linux/ACPI relies on the firmware to set up clocks and regulators, and uses
> >> abstract firmware methods to manage power states etc. Also, due to the
> >> dependency on UEFI, things like the RTC and NOR flash are not exposed to
> the
> >> OS via device nodes, but via UEFI runtime services.
> >
> > Agreed, RTC and NOR (containing firmware)  should not exposed to Linux or
> OS.
> >
> >> In a nutshell, the difference between ACPI and DT is that the handoff point
> >> between the OS and the firmware is at a different abstraction level.
> >>
> >> So no, it is not ok to use PRP0001 + compatible for everything. It may be
> >> acceptable in some exceptional cases, but you will have to explain why.
> >> Everything else should use proper ACPI bindings.
> >
> > HID is not going away , I am keeping with PRP0001 + compatible
> > and let linux driver to decide what to use.
> >
> > If PRP0001 + compatible is restricted or meant for limited use
> > then I can assign HID for NXP devices or say driver managed by NXP.
> > For other vendors, will this be accepted to have HID something like NXP00xx
> ??
> >
> >> --
> >> Ard.

Re: [RFC] ACPI table HID/CID allocation

[Ard Biesheuvel]

On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com> wrote:
>
>> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com> 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 PRP00001) and Linux to decide binding
>>
>> No.
>>
>> You are still assuming ACPI and DT device drivers bind at the same level, and
>> they don't.
>
> No, my above comments was just limited to binding.

Yes, but if you leave it to the OS to decide which binding it uses,
you will have to support all of them into eternity. And the more
detailed binding you need to support may limit you in the available
choices when it comes to making hardware changes, something ACPI
allows you to do.

> Right, here device driver should know that device is present in system,
> I see probe function (device-driver binding) is way to know this.
> Then driver can execute AML methods exposed by firmware.
>

Yes, declaring the presence of the device is the main purpose of
describing it both in ACPI and in DT.

>> An ACPI device has AML methods to manage power state and perform other
>> device related low-level tasks. The device driver has no knowledge of the
>> hardware beyond what it needs to invoke those abstract methods.
>
> You meant, If we need to update driver for AML methods then why not to update binding as well . ?
>

No. What I am saying is that you should not expose two different
bindings, and let the OS choose.

> On side track,
>  With limited search,  I got many each driver is having (acpi_id and of_id),
> looks, acpi support is added on the top of DT flavored drivers.
> and therefore acpi tables are following the same.
> Sorry to say, reference I am looking at (edk2-platform) JunoPkg and VExpressPkg,
> Has following devices has description similar to Device tree
>     Device (NET0) {
>     Device (SREG) {
>     Device (VIRT) {

These were taken from the ACPI tables for an emulator

>    Device(KMI0) {

I have no clue what kind of device this is

>    Device(ETH0) {

This one uses _DSD as intended, to set device properties in a DT
compatible fashion, but note that this does *not* include the
'compatible' property, nor anything else that ACPI defines itself
(status, dma-coherent, etc)

> Where no AML method is exposed. Then I expect OS driver to manage this device.
> While grepping over few other edk2-platforms.  Looks some of methods
> are abstracted, not whole device.
>

So what is your point? Why does this argue in favor of allowing
PRP0001 + compatible?

>> A DT device describes everything in detail, and requires clock and regulator
>> drivers and other bits and pieces that are tightly coupled to details of the
>> hardware.
>>
>> So now, you have the worst of both worlds:
>>
>> - you need to implement all of this in firmware so ACPI can support it,
>> - you have to expose the internals to the OS so DT can support it.
>
> Yes, for time being or may be longer, DT support needs to be there
> along with ACPI introduction.
>
> Are you suggesting here to abstract whole device details from
> OS and expose AML methods to be used by device driver.
> And maintain two drivers instead of fitting DT style driver into ACPI world ?
>

No. You should update the driver so it can support both ACPI and DT
bindings. That way, the driver can use the abstractions offered by
ACPI when it can, and can invoke the clock and regulator frameworks
and other low level infrastructure only when it needs to.

Let me try to illustrate this a bit better: imagine a NXP customer
that runs a datacenter that has 10,000 NXP servers, and is using RHEL
x.y. The business is going well, and at some point, he wants to order
another 2,000 servers. Unfortunately, the vendor cannot supply the
exact same revision of the hardware, and the latest revision uses some
component that is not supported in RHEL x.y.

You now have made your customer very unhappy. He invested in RHEL and
ACPI based servers precisely to avoid this situation. The cost of
adding 2,000 servers now includes the cost of upgrading the other
10,000 servers to a new OS version or the cost of supporting two
different OS versions at the same time, for a reason that is not
justifiable.

Re: [RFC] ACPI table HID/CID allocation

[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")
                 }
} 
is ok or 


Device(XYZ) { 
                Name(_HID, "NXP0001") 
                Name(_CID, " NXP0001")
	  Device(Slave1) {
		                Name(_CID, " NXP0002")
                 }
} 
Seems good

For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to be coded in table using either of.

Please see more in line 

Regards
Udit

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Tuesday, November 21, 2017 5:59 PM
> To: Udit Kumar <udit.kumar@nxp.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
> Graeme Gregory <graeme.gregory@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com> wrote:
> >
> >> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com> 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 PRP00001) and Linux to decide binding
> >>
> >> No.
> >>
> >> You are still assuming ACPI and DT device drivers bind at the same
> >> level, and they don't.
> >
> > No, my above comments was just limited to binding.
> 
> Yes, but if you leave it to the OS to decide which binding it uses, you will have to
> support all of them into eternity. And the more detailed binding you need to
> support may limit you in the available choices when it comes to making
> hardware changes, something ACPI allows you to do.

Thanks,  
Is this ok to say , we can provide max same properties in driver as of DT
(with _DSD) , But prefer to use AML methods.
With note, clocking regulators are out of scope here. 

 
> > Right, here device driver should know that device is present in
> > system, I see probe function (device-driver binding) is way to know this.
> > Then driver can execute AML methods exposed by firmware.
> >
> 
> Yes, declaring the presence of the device is the main purpose of describing it
> both in ACPI and in DT.
> 
> >> An ACPI device has AML methods to manage power state and perform
> >> other device related low-level tasks. The device driver has no
> >> knowledge of the hardware beyond what it needs to invoke those abstract
> methods.
> >
> > You meant, If we need to update driver for AML methods then why not to
> update binding as well . ?
> >
> 
> No. What I am saying is that you should not expose two different bindings, and
> let the OS choose.

Ok, got it , then PRP00001 stuff should be used only at urgent or say 
no other choice left , Right ? 
 
> > On side track,
> >  With limited search,  I got many each driver is having (acpi_id and
> > of_id), looks, acpi support is added on the top of DT flavored drivers.
> > and therefore acpi tables are following the same.
> > Sorry to say, reference I am looking at (edk2-platform) JunoPkg and
> > VExpressPkg, Has following devices has description similar to Device tree
> >     Device (NET0) {
> >     Device (SREG) {
> >     Device (VIRT) {
> 
> These were taken from the ACPI tables for an emulator
> 
> >    Device(KMI0) {
> 
> I have no clue what kind of device this is
> 
> >    Device(ETH0) {
> 
> This one uses _DSD as intended, to set device properties in a DT compatible
> fashion, but note that this does *not* include the 'compatible' property, nor
> anything else that ACPI defines itself (status, dma-coherent, etc)

Let me put in simple way,
A simple driver can survive only with _DSD in acpi world. (clocking/regulators are used
as said in UEFI/ACPI)

Copying below from Juno, 
Are below kind of tables are acceptable ? 

    Device(ETH0) {
      Name(_HID, "ARMH9118")
      Name(_UID, Zero)
      Name(_CRS, ResourceTemplate() {
              Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
              Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
      })
      Name(_DSD, Package() {
                   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                       Package() {
                               Package(2) {"phy-mode", "mii"},
                               Package(2) {"reg-io-width", 4 },
                               Package(2) {"smsc,irq-active-high",1},
                               Package(2) {"smsc,irq-push-pull",1}
                      }
      }) // _DSD()
    }

> > Where no AML method is exposed. Then I expect OS driver to manage this
> device.
> > While grepping over few other edk2-platforms.  Looks some of methods
> > are abstracted, not whole device.
> >
> 
> So what is your point? Why does this argue in favor of allowing
> PRP0001 + compatible?

I am seeking your help here to define HID and CID,  please see above 
Also for non-NXP devices, how to define HID (if PRP0001 + compatible not to be used) 
 
> >> A DT device describes everything in detail, and requires clock and
> >> regulator drivers and other bits and pieces that are tightly coupled
> >> to details of the hardware.
> >>
> >> So now, you have the worst of both worlds:
> >>
> >> - you need to implement all of this in firmware so ACPI can support
> >> it,
> >> - you have to expose the internals to the OS so DT can support it.
> >
> > Yes, for time being or may be longer, DT support needs to be there
> > along with ACPI introduction.
> >
> > Are you suggesting here to abstract whole device details from OS and
> > expose AML methods to be used by device driver.
> > And maintain two drivers instead of fitting DT style driver into ACPI world ?
> >
> 
> No. You should update the driver so it can support both ACPI and DT bindings.
> That way, the driver can use the abstractions offered by ACPI when it can, and
> can invoke the clock and regulator frameworks and other low level
> infrastructure only when it needs to.

Ok, I am align on this, to have one driver which supports both. 

> Let me try to illustrate this a bit better: imagine a NXP customer that runs a
> datacenter that has 10,000 NXP servers, and is using RHEL x.y. The business is
> going well, and at some point, he wants to order another 2,000 servers.
> Unfortunately, the vendor cannot supply the exact same revision of the
> hardware, and the latest revision uses some component that is not supported in
> RHEL x.y.
> 
> You now have made your customer very unhappy. He invested in RHEL and ACPI
> based servers precisely to avoid this situation. The cost of adding 2,000 servers
> now includes the cost of upgrading the other
> 10,000 servers to a new OS version or the cost of supporting two different OS
> versions at the same time, for a reason that is not justifiable.

Do you mean here with PRP0001 HID/CID, we cannot use AML methods.  

Re: [RFC] ACPI table HID/CID allocation

[Ard Biesheuvel]

On 21 November 2017 at 13:24, Udit Kumar <udit.kumar@nxp.com> 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) {
>                                 Name(_CID, "PRP0001")
>                  }
> }
> is ok or
>
>
> Device(XYZ) {
>                 Name(_HID, "NXP0001")
>                 Name(_CID, " NXP0001")
>           Device(Slave1) {
>                                 Name(_CID, " NXP0002")
>                  }
> }
> Seems good
>

I don't think it makes a lot of sense to use the same value for _HID
and _CID, so you can just drop the latter.

> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to be coded in table using either of.
>
> Please see more in line
>
> Regards
> Udit
>
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> Sent: Tuesday, November 21, 2017 5:59 PM
>> To: Udit Kumar <udit.kumar@nxp.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
>> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
>> Graeme Gregory <graeme.gregory@linaro.org>
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>
>> On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com> wrote:
>> >
>> >> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com> 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 PRP00001) and Linux to decide binding
>> >>
>> >> No.
>> >>
>> >> You are still assuming ACPI and DT device drivers bind at the same
>> >> level, and they don't.
>> >
>> > No, my above comments was just limited to binding.
>>
>> Yes, but if you leave it to the OS to decide which binding it uses, you will have to
>> support all of them into eternity. And the more detailed binding you need to
>> support may limit you in the available choices when it comes to making
>> hardware changes, something ACPI allows you to do.
>
> Thanks,
> Is this ok to say , we can provide max same properties in driver as of DT
> (with _DSD) , But prefer to use AML methods.
> With note, clocking regulators are out of scope here.
>

Yes. _DSD may be used to describe device specific data that goes
beyond what ACPI can express natively. Using _DSD to describe clocks
and regulators is an absolute no-go. Putting things like "status" or
"dma-coherent" in _DSD properties is absolutely unacceptable as well.
But even things like initialization data that the driver programs into
the device a single time really do not belong in _DSD. Instead, it
should be the firmware that initializes the device, and presents it to
the OS in its initialized state.

>
>> > Right, here device driver should know that device is present in
>> > system, I see probe function (device-driver binding) is way to know this.
>> > Then driver can execute AML methods exposed by firmware.
>> >
>>
>> Yes, declaring the presence of the device is the main purpose of describing it
>> both in ACPI and in DT.
>>
>> >> An ACPI device has AML methods to manage power state and perform
>> >> other device related low-level tasks. The device driver has no
>> >> knowledge of the hardware beyond what it needs to invoke those abstract
>> methods.
>> >
>> > You meant, If we need to update driver for AML methods then why not to
>> update binding as well . ?
>> >
>>
>> No. What I am saying is that you should not expose two different bindings, and
>> let the OS choose.
>
> Ok, got it , then PRP00001 stuff should be used only at urgent or say
> no other choice left , Right ?
>

Yes.

>> > On side track,
>> >  With limited search,  I got many each driver is having (acpi_id and
>> > of_id), looks, acpi support is added on the top of DT flavored drivers.
>> > and therefore acpi tables are following the same.
>> > Sorry to say, reference I am looking at (edk2-platform) JunoPkg and
>> > VExpressPkg, Has following devices has description similar to Device tree
>> >     Device (NET0) {
>> >     Device (SREG) {
>> >     Device (VIRT) {
>>
>> These were taken from the ACPI tables for an emulator
>>
>> >    Device(KMI0) {
>>
>> I have no clue what kind of device this is
>>
>> >    Device(ETH0) {
>>
>> This one uses _DSD as intended, to set device properties in a DT compatible
>> fashion, but note that this does *not* include the 'compatible' property, nor
>> anything else that ACPI defines itself (status, dma-coherent, etc)
>
> Let me put in simple way,
> A simple driver can survive only with _DSD in acpi world. (clocking/regulators are used
> as said in UEFI/ACPI)
>

Why can a simple driver only survive with _DSD? That statement does
not make any sense to me.

> Copying below from Juno,
> Are below kind of tables are acceptable ?
>
>     Device(ETH0) {
>       Name(_HID, "ARMH9118")
>       Name(_UID, Zero)
>       Name(_CRS, ResourceTemplate() {
>               Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
>               Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
>       })
>       Name(_DSD, Package() {
>                    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>                        Package() {
>                                Package(2) {"phy-mode", "mii"},
>                                Package(2) {"reg-io-width", 4 },
>                                Package(2) {"smsc,irq-active-high",1},
>                                Package(2) {"smsc,irq-push-pull",1}
>                       }
>       }) // _DSD()
>     }
>

Yes. But please be aware that you should not simply invent your own
properties here. The _DSD namespace was intended to be managed, and
not free for all

https://www.kernel.org/doc/Documentation/acpi/DSD-properties-rules.txt

>> > Where no AML method is exposed. Then I expect OS driver to manage this
>> device.
>> > While grepping over few other edk2-platforms.  Looks some of methods
>> > are abstracted, not whole device.
>> >
>>
>> So what is your point? Why does this argue in favor of allowing
>> PRP0001 + compatible?
>
> I am seeking your help here to define HID and CID,  please see above
> Also for non-NXP devices, how to define HID (if PRP0001 + compatible not to be used)
>

This could be a valid reason to use PRP0001 + compatible, for things
like I2C slaves that are external to the SoC

>> >> A DT device describes everything in detail, and requires clock and
>> >> regulator drivers and other bits and pieces that are tightly coupled
>> >> to details of the hardware.
>> >>
>> >> So now, you have the worst of both worlds:
>> >>
>> >> - you need to implement all of this in firmware so ACPI can support
>> >> it,
>> >> - you have to expose the internals to the OS so DT can support it.
>> >
>> > Yes, for time being or may be longer, DT support needs to be there
>> > along with ACPI introduction.
>> >
>> > Are you suggesting here to abstract whole device details from OS and
>> > expose AML methods to be used by device driver.
>> > And maintain two drivers instead of fitting DT style driver into ACPI world ?
>> >
>>
>> No. You should update the driver so it can support both ACPI and DT bindings.
>> That way, the driver can use the abstractions offered by ACPI when it can, and
>> can invoke the clock and regulator frameworks and other low level
>> infrastructure only when it needs to.
>
> Ok, I am align on this, to have one driver which supports both.
>
>> Let me try to illustrate this a bit better: imagine a NXP customer that runs a
>> datacenter that has 10,000 NXP servers, and is using RHEL x.y. The business is
>> going well, and at some point, he wants to order another 2,000 servers.
>> Unfortunately, the vendor cannot supply the exact same revision of the
>> hardware, and the latest revision uses some component that is not supported in
>> RHEL x.y.
>>
>> You now have made your customer very unhappy. He invested in RHEL and ACPI
>> based servers precisely to avoid this situation. The cost of adding 2,000 servers
>> now includes the cost of upgrading the other
>> 10,000 servers to a new OS version or the cost of supporting two different OS
>> versions at the same time, for a reason that is not justifiable.
>
> Do you mean here with PRP0001 HID/CID, we cannot use AML methods.

You cannot use the abstractions ACPI provides when using PRP0001 + compatible.

Re: [RFC] ACPI table HID/CID allocation

[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 + compatible or that device driver needs add ACPI HID support.

As you pointed out, are external devices to SOC such exception to use PRP0001 + compatible be it 
i2c slave or SPI slave ?


Regards
Udit

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Tuesday, November 21, 2017 7:34 PM
> To: Udit Kumar <udit.kumar@nxp.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
> Graeme Gregory <graeme.gregory@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 21 November 2017 at 13:24, Udit Kumar <udit.kumar@nxp.com> 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) {
> >                                 Name(_CID, "PRP0001")
> >                  }
> > }
> > is ok or
> >
> >
> > Device(XYZ) {
> >                 Name(_HID, "NXP0001")
> >                 Name(_CID, " NXP0001")
> >           Device(Slave1) {
> >                                 Name(_CID, " NXP0002")
> >                  }
> > }
> > Seems good
> >
> 
> I don't think it makes a lot of sense to use the same value for _HID and _CID, so
> you can just drop the latter.

Sure, 
 
> > For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to be
> coded in table using either of.
> >
> > Please see more in line
> >
> > Regards
> > Udit
> >
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: Tuesday, November 21, 2017 5:59 PM
> >> To: Udit Kumar <udit.kumar@nxp.com>
> >> Cc: Leif Lindholm <leif.lindholm@linaro.org>;
> >> edk2-devel@lists.01.org; Varun Sethi <V.Sethi@nxp.com>; Daniel
> >> Thompson <daniel.thompson@linaro.org>; Graeme Gregory
> >> <graeme.gregory@linaro.org>
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com> wrote:
> >> >
> >> >> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com>
> 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 PRP00001) and Linux to decide binding
> >> >>
> >> >> No.
> >> >>
> >> >> You are still assuming ACPI and DT device drivers bind at the same
> >> >> level, and they don't.
> >> >
> >> > No, my above comments was just limited to binding.
> >>
> >> Yes, but if you leave it to the OS to decide which binding it uses,
> >> you will have to support all of them into eternity. And the more
> >> detailed binding you need to support may limit you in the available
> >> choices when it comes to making hardware changes, something ACPI allows
> you to do.
> >
> > Thanks,
> > Is this ok to say , we can provide max same properties in driver as of
> > DT (with _DSD) , But prefer to use AML methods.
> > With note, clocking regulators are out of scope here.
> >
> 
> Yes. _DSD may be used to describe device specific data that goes beyond what
> ACPI can express natively. Using _DSD to describe clocks and regulators is an
> absolute no-go. Putting things like "status" or "dma-coherent" in _DSD
> properties is absolutely unacceptable as well.
> But even things like initialization data that the driver programs into the device a
> single time really do not belong in _DSD. Instead, it should be the firmware that
> initializes the device, and presents it to the OS in its initialized state.
>

Agreed, I never meant something to add in DSD which was prohibited in ACPI spces.

> >
> >> > Right, here device driver should know that device is present in
> >> > system, I see probe function (device-driver binding) is way to know this.
> >> > Then driver can execute AML methods exposed by firmware.
> >> >
> >>
> >> Yes, declaring the presence of the device is the main purpose of
> >> describing it both in ACPI and in DT.
> >>
> >> >> An ACPI device has AML methods to manage power state and perform
> >> >> other device related low-level tasks. The device driver has no
> >> >> knowledge of the hardware beyond what it needs to invoke those
> >> >> abstract
> >> methods.
> >> >
> >> > You meant, If we need to update driver for AML methods then why not
> >> > to
> >> update binding as well . ?
> >> >
> >>
> >> No. What I am saying is that you should not expose two different
> >> bindings, and let the OS choose.
> >
> > Ok, got it , then PRP00001 stuff should be used only at urgent or say
> > no other choice left , Right ?
> >
> 
> Yes.


> >> > On side track,
> >> >  With limited search,  I got many each driver is having (acpi_id
> >> > and of_id), looks, acpi support is added on the top of DT flavored drivers.
> >> > and therefore acpi tables are following the same.
> >> > Sorry to say, reference I am looking at (edk2-platform) JunoPkg and
> >> > VExpressPkg, Has following devices has description similar to Device tree
> >> >     Device (NET0) {
> >> >     Device (SREG) {
> >> >     Device (VIRT) {
> >>
> >> These were taken from the ACPI tables for an emulator
> >>
> >> >    Device(KMI0) {
> >>
> >> I have no clue what kind of device this is
> >>
> >> >    Device(ETH0) {
> >>
> >> This one uses _DSD as intended, to set device properties in a DT
> >> compatible fashion, but note that this does *not* include the
> >> 'compatible' property, nor anything else that ACPI defines itself
> >> (status, dma-coherent, etc)
> >
> > Let me put in simple way,
> > A simple driver can survive only with _DSD in acpi world.
> > (clocking/regulators are used as said in UEFI/ACPI)
> >
> 
> Why can a simple driver only survive with _DSD? That statement does not make
> any sense to me.

Why so, please see below one for example 
 
> > Copying below from Juno,
> > Are below kind of tables are acceptable ?
> >
> >     Device(ETH0) {
> >       Name(_HID, "ARMH9118")
> >       Name(_UID, Zero)
> >       Name(_CRS, ResourceTemplate() {
> >               Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
> >               Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
> >       })
> >       Name(_DSD, Package() {
> >                    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >                        Package() {
> >                                Package(2) {"phy-mode", "mii"},
> >                                Package(2) {"reg-io-width", 4 },
> >                                Package(2) {"smsc,irq-active-high",1},
> >                                Package(2) {"smsc,irq-push-pull",1}
> >                       }
> >       }) // _DSD()
> >     }
> >
> 
> Yes. But please be aware that you should not simply invent your own properties
> here. The _DSD namespace was intended to be managed, and not free for all

Agreed, I didn’t meant to add something new, which is not available at present, 

 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.k
> ernel.org%2Fdoc%2FDocumentation%2Facpi%2FDSD-properties-
> rules.txt&data=02%7C01%7Cudit.kumar%40nxp.com%7C164c1ff7350a4f6373e
> e08d530e8b591%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63646
> 8698397705869&sdata=O78k8r6tcK9fwpuTuQ82ZXGiWkBtLduf4bqrM6D6L1U%
> 3D&reserved=0
> 
> >> > Where no AML method is exposed. Then I expect OS driver to manage
> >> > this
> >> device.
> >> > While grepping over few other edk2-platforms.  Looks some of
> >> > methods are abstracted, not whole device.
> >> >
> >>
> >> So what is your point? Why does this argue in favor of allowing
> >> PRP0001 + compatible?
> >
> > I am seeking your help here to define HID and CID,  please see above
> > Also for non-NXP devices, how to define HID (if PRP0001 + compatible
> > not to be used)
> >
> 
> This could be a valid reason to use PRP0001 + compatible, for things like I2C
> slaves that are external to the SoC

Well,  for internal SOC devices, I am in agreement to use NXP specific HIDs 
But for external devices (for which HID is not available), you suggest to go
With PRP0001 + compatible
 
> >> >> A DT device describes everything in detail, and requires clock and
> >> >> regulator drivers and other bits and pieces that are tightly
> >> >> coupled to details of the hardware.
> >> >>
> >> >> So now, you have the worst of both worlds:
> >> >>
> >> >> - you need to implement all of this in firmware so ACPI can
> >> >> support it,
> >> >> - you have to expose the internals to the OS so DT can support it.
> >> >
> >> > Yes, for time being or may be longer, DT support needs to be there
> >> > along with ACPI introduction.
> >> >
> >> > Are you suggesting here to abstract whole device details from OS
> >> > and expose AML methods to be used by device driver.
> >> > And maintain two drivers instead of fitting DT style driver into ACPI world ?
> >> >
> >>
> >> No. You should update the driver so it can support both ACPI and DT bindings.
> >> That way, the driver can use the abstractions offered by ACPI when it
> >> can, and can invoke the clock and regulator frameworks and other low
> >> level infrastructure only when it needs to.
> >
> > Ok, I am align on this, to have one driver which supports both.
> >
> >> Let me try to illustrate this a bit better: imagine a NXP customer
> >> that runs a datacenter that has 10,000 NXP servers, and is using RHEL
> >> x.y. The business is going well, and at some point, he wants to order another
> 2,000 servers.
> >> Unfortunately, the vendor cannot supply the exact same revision of
> >> the hardware, and the latest revision uses some component that is not
> >> supported in RHEL x.y.
> >>
> >> You now have made your customer very unhappy. He invested in RHEL and
> >> ACPI based servers precisely to avoid this situation. The cost of
> >> adding 2,000 servers now includes the cost of upgrading the other
> >> 10,000 servers to a new OS version or the cost of supporting two
> >> different OS versions at the same time, for a reason that is not justifiable.
> >
> > Do you mean here with PRP0001 HID/CID, we cannot use AML methods.
> 
> You cannot use the abstractions ACPI provides when using PRP0001 +
> compatible.
Oh, thx 

Re: [RFC] ACPI table HID/CID allocation

[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), 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 because I don't 
understand why there is no HID available.

Large OEMs and board manufacturers usually have their own vendor IDs and 
sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx 
on the ARM Juno uses an ARM HID).

Admittedly the part you are describing follows a JEDEC standard so it 
would be nice to have more widely agreed bindings... however making SPI 
NOR FLASH available as raw MTD device to the OS is sufficiently unusual 
in ACPI systems that there may not be any prior art to follow.


Daniel.


> 
> As you pointed out, are external devices to SOC such exception to use PRP0001 + compatible be it
> i2c slave or SPI slave ?
> 
> 
> Regards
> Udit
> 
>> -----Original Message-----
>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>> Sent: Tuesday, November 21, 2017 7:34 PM
>> To: Udit Kumar <udit.kumar@nxp.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun
>> Sethi <V.Sethi@nxp.com>; Daniel Thompson <daniel.thompson@linaro.org>;
>> Graeme Gregory <graeme.gregory@linaro.org>
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>
>> On 21 November 2017 at 13:24, Udit Kumar <udit.kumar@nxp.com> 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) {
>>>                                  Name(_CID, "PRP0001")
>>>                   }
>>> }
>>> is ok or
>>>
>>>
>>> Device(XYZ) {
>>>                  Name(_HID, "NXP0001")
>>>                  Name(_CID, " NXP0001")
>>>            Device(Slave1) {
>>>                                  Name(_CID, " NXP0002")
>>>                   }
>>> }
>>> Seems good
>>>
>>
>> I don't think it makes a lot of sense to use the same value for _HID and _CID, so
>> you can just drop the latter.
> 
> Sure,
>   
>>> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to be
>> coded in table using either of.
>>>
>>> Please see more in line
>>>
>>> Regards
>>> Udit
>>>
>>>> -----Original Message-----
>>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>>>> Sent: Tuesday, November 21, 2017 5:59 PM
>>>> To: Udit Kumar <udit.kumar@nxp.com>
>>>> Cc: Leif Lindholm <leif.lindholm@linaro.org>;
>>>> edk2-devel@lists.01.org; Varun Sethi <V.Sethi@nxp.com>; Daniel
>>>> Thompson <daniel.thompson@linaro.org>; Graeme Gregory
>>>> <graeme.gregory@linaro.org>
>>>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>>>
>>>> On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com> wrote:
>>>>>
>>>>>> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com>
>> 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 PRP00001) and Linux to decide binding
>>>>>>
>>>>>> No.
>>>>>>
>>>>>> You are still assuming ACPI and DT device drivers bind at the same
>>>>>> level, and they don't.
>>>>>
>>>>> No, my above comments was just limited to binding.
>>>>
>>>> Yes, but if you leave it to the OS to decide which binding it uses,
>>>> you will have to support all of them into eternity. And the more
>>>> detailed binding you need to support may limit you in the available
>>>> choices when it comes to making hardware changes, something ACPI allows
>> you to do.
>>>
>>> Thanks,
>>> Is this ok to say , we can provide max same properties in driver as of
>>> DT (with _DSD) , But prefer to use AML methods.
>>> With note, clocking regulators are out of scope here.
>>>
>>
>> Yes. _DSD may be used to describe device specific data that goes beyond what
>> ACPI can express natively. Using _DSD to describe clocks and regulators is an
>> absolute no-go. Putting things like "status" or "dma-coherent" in _DSD
>> properties is absolutely unacceptable as well.
>> But even things like initialization data that the driver programs into the device a
>> single time really do not belong in _DSD. Instead, it should be the firmware that
>> initializes the device, and presents it to the OS in its initialized state.
>>
> 
> Agreed, I never meant something to add in DSD which was prohibited in ACPI spces.
> 
>>>
>>>>> Right, here device driver should know that device is present in
>>>>> system, I see probe function (device-driver binding) is way to know this.
>>>>> Then driver can execute AML methods exposed by firmware.
>>>>>
>>>>
>>>> Yes, declaring the presence of the device is the main purpose of
>>>> describing it both in ACPI and in DT.
>>>>
>>>>>> An ACPI device has AML methods to manage power state and perform
>>>>>> other device related low-level tasks. The device driver has no
>>>>>> knowledge of the hardware beyond what it needs to invoke those
>>>>>> abstract
>>>> methods.
>>>>>
>>>>> You meant, If we need to update driver for AML methods then why not
>>>>> to
>>>> update binding as well . ?
>>>>>
>>>>
>>>> No. What I am saying is that you should not expose two different
>>>> bindings, and let the OS choose.
>>>
>>> Ok, got it , then PRP00001 stuff should be used only at urgent or say
>>> no other choice left , Right ?
>>>
>>
>> Yes.
> 
> 
>>>>> On side track,
>>>>>   With limited search,  I got many each driver is having (acpi_id
>>>>> and of_id), looks, acpi support is added on the top of DT flavored drivers.
>>>>> and therefore acpi tables are following the same.
>>>>> Sorry to say, reference I am looking at (edk2-platform) JunoPkg and
>>>>> VExpressPkg, Has following devices has description similar to Device tree
>>>>>      Device (NET0) {
>>>>>      Device (SREG) {
>>>>>      Device (VIRT) {
>>>>
>>>> These were taken from the ACPI tables for an emulator
>>>>
>>>>>     Device(KMI0) {
>>>>
>>>> I have no clue what kind of device this is
>>>>
>>>>>     Device(ETH0) {
>>>>
>>>> This one uses _DSD as intended, to set device properties in a DT
>>>> compatible fashion, but note that this does *not* include the
>>>> 'compatible' property, nor anything else that ACPI defines itself
>>>> (status, dma-coherent, etc)
>>>
>>> Let me put in simple way,
>>> A simple driver can survive only with _DSD in acpi world.
>>> (clocking/regulators are used as said in UEFI/ACPI)
>>>
>>
>> Why can a simple driver only survive with _DSD? That statement does not make
>> any sense to me.
> 
> Why so, please see below one for example
>   
>>> Copying below from Juno,
>>> Are below kind of tables are acceptable ?
>>>
>>>      Device(ETH0) {
>>>        Name(_HID, "ARMH9118")
>>>        Name(_UID, Zero)
>>>        Name(_CRS, ResourceTemplate() {
>>>                Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
>>>                Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
>>>        })
>>>        Name(_DSD, Package() {
>>>                     ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>>                         Package() {
>>>                                 Package(2) {"phy-mode", "mii"},
>>>                                 Package(2) {"reg-io-width", 4 },
>>>                                 Package(2) {"smsc,irq-active-high",1},
>>>                                 Package(2) {"smsc,irq-push-pull",1}
>>>                        }
>>>        }) // _DSD()
>>>      }
>>>
>>
>> Yes. But please be aware that you should not simply invent your own properties
>> here. The _DSD namespace was intended to be managed, and not free for all
> 
> Agreed, I didn’t meant to add something new, which is not available at present,
> 
>   
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.k
>> ernel.org%2Fdoc%2FDocumentation%2Facpi%2FDSD-properties-
>> rules.txt&data=02%7C01%7Cudit.kumar%40nxp.com%7C164c1ff7350a4f6373e
>> e08d530e8b591%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63646
>> 8698397705869&sdata=O78k8r6tcK9fwpuTuQ82ZXGiWkBtLduf4bqrM6D6L1U%
>> 3D&reserved=0
>>
>>>>> Where no AML method is exposed. Then I expect OS driver to manage
>>>>> this
>>>> device.
>>>>> While grepping over few other edk2-platforms.  Looks some of
>>>>> methods are abstracted, not whole device.
>>>>>
>>>>
>>>> So what is your point? Why does this argue in favor of allowing
>>>> PRP0001 + compatible?
>>>
>>> I am seeking your help here to define HID and CID,  please see above
>>> Also for non-NXP devices, how to define HID (if PRP0001 + compatible
>>> not to be used)
>>>
>>
>> This could be a valid reason to use PRP0001 + compatible, for things like I2C
>> slaves that are external to the SoC
> 
> Well,  for internal SOC devices, I am in agreement to use NXP specific HIDs
> But for external devices (for which HID is not available), you suggest to go
> With PRP0001 + compatible
>   
>>>>>> A DT device describes everything in detail, and requires clock and
>>>>>> regulator drivers and other bits and pieces that are tightly
>>>>>> coupled to details of the hardware.
>>>>>>
>>>>>> So now, you have the worst of both worlds:
>>>>>>
>>>>>> - you need to implement all of this in firmware so ACPI can
>>>>>> support it,
>>>>>> - you have to expose the internals to the OS so DT can support it.
>>>>>
>>>>> Yes, for time being or may be longer, DT support needs to be there
>>>>> along with ACPI introduction.
>>>>>
>>>>> Are you suggesting here to abstract whole device details from OS
>>>>> and expose AML methods to be used by device driver.
>>>>> And maintain two drivers instead of fitting DT style driver into ACPI world ?
>>>>>
>>>>
>>>> No. You should update the driver so it can support both ACPI and DT bindings.
>>>> That way, the driver can use the abstractions offered by ACPI when it
>>>> can, and can invoke the clock and regulator frameworks and other low
>>>> level infrastructure only when it needs to.
>>>
>>> Ok, I am align on this, to have one driver which supports both.
>>>
>>>> Let me try to illustrate this a bit better: imagine a NXP customer
>>>> that runs a datacenter that has 10,000 NXP servers, and is using RHEL
>>>> x.y. The business is going well, and at some point, he wants to order another
>> 2,000 servers.
>>>> Unfortunately, the vendor cannot supply the exact same revision of
>>>> the hardware, and the latest revision uses some component that is not
>>>> supported in RHEL x.y.
>>>>
>>>> You now have made your customer very unhappy. He invested in RHEL and
>>>> ACPI based servers precisely to avoid this situation. The cost of
>>>> adding 2,000 servers now includes the cost of upgrading the other
>>>> 10,000 servers to a new OS version or the cost of supporting two
>>>> different OS versions at the same time, for a reason that is not justifiable.
>>>
>>> Do you mean here with PRP0001 HID/CID, we cannot use AML methods.
>>
>> You cannot use the abstractions ACPI provides when using PRP0001 +
>> compatible.
> Oh, thx
> 

Re: [RFC] ACPI table HID/CID allocation

[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 because I don't understand why there is no HID
> available.

This is more a choice/rule between allocating HID or using PRP0001.
HID could be assigned to external devices, and getting them reviewed 
by maintainers. 

> Large OEMs and board manufacturers usually have their own vendor IDs and
> sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx on
> the ARM Juno uses an ARM HID).

Thanks,  for this example. 
This is good example for me, where HID allocation is not limited to Vendor devices.

 
> Admittedly the part you are describing follows a JEDEC standard so it would be
> nice to have more widely agreed bindings... however making SPI NOR FLASH
> available as raw MTD device to the OS is sufficiently unusual in ACPI systems
> that there may not be any prior art to follow.

Please take this as an example. ( Main point was to use HID or PRP0001)
Could be possible, if such device is exposed then this may not be used at all.
Thanks for help. 

Thanks
Udit 

> 
> Daniel.
> 
> 
> >
> > As you pointed out, are external devices to SOC such exception to use
> > PRP0001 + compatible be it i2c slave or SPI slave ?
> >
> >
> > Regards
> > Udit
> >
> >> -----Original Message-----
> >> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >> Sent: Tuesday, November 21, 2017 7:34 PM
> >> To: Udit Kumar <udit.kumar@nxp.com>
> >> Cc: Leif Lindholm <leif.lindholm@linaro.org>;
> >> edk2-devel@lists.01.org; Varun Sethi <V.Sethi@nxp.com>; Daniel
> >> Thompson <daniel.thompson@linaro.org>; Graeme Gregory
> >> <graeme.gregory@linaro.org>
> >> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>
> >> On 21 November 2017 at 13:24, Udit Kumar <udit.kumar@nxp.com> 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) {
> >>>                                  Name(_CID, "PRP0001")
> >>>                   }
> >>> }
> >>> is ok or
> >>>
> >>>
> >>> Device(XYZ) {
> >>>                  Name(_HID, "NXP0001")
> >>>                  Name(_CID, " NXP0001")
> >>>            Device(Slave1) {
> >>>                                  Name(_CID, " NXP0002")
> >>>                   }
> >>> }
> >>> Seems good
> >>>
> >>
> >> I don't think it makes a lot of sense to use the same value for _HID
> >> and _CID, so you can just drop the latter.
> >
> > Sure,
> >
> >>> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
> >>> be
> >> coded in table using either of.
> >>>
> >>> Please see more in line
> >>>
> >>> Regards
> >>> Udit
> >>>
> >>>> -----Original Message-----
> >>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> >>>> Sent: Tuesday, November 21, 2017 5:59 PM
> >>>> To: Udit Kumar <udit.kumar@nxp.com>
> >>>> Cc: Leif Lindholm <leif.lindholm@linaro.org>;
> >>>> edk2-devel@lists.01.org; Varun Sethi <V.Sethi@nxp.com>; Daniel
> >>>> Thompson <daniel.thompson@linaro.org>; Graeme Gregory
> >>>> <graeme.gregory@linaro.org>
> >>>> Subject: Re: [RFC] ACPI table HID/CID allocation
> >>>>
> >>>> On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com>
> wrote:
> >>>>>
> >>>>>> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com>
> >> 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 PRP00001) and Linux to decide binding
> >>>>>>
> >>>>>> No.
> >>>>>>
> >>>>>> You are still assuming ACPI and DT device drivers bind at the
> >>>>>> same level, and they don't.
> >>>>>
> >>>>> No, my above comments was just limited to binding.
> >>>>
> >>>> Yes, but if you leave it to the OS to decide which binding it uses,
> >>>> you will have to support all of them into eternity. And the more
> >>>> detailed binding you need to support may limit you in the available
> >>>> choices when it comes to making hardware changes, something ACPI
> >>>> allows
> >> you to do.
> >>>
> >>> Thanks,
> >>> Is this ok to say , we can provide max same properties in driver as
> >>> of DT (with _DSD) , But prefer to use AML methods.
> >>> With note, clocking regulators are out of scope here.
> >>>
> >>
> >> Yes. _DSD may be used to describe device specific data that goes
> >> beyond what ACPI can express natively. Using _DSD to describe clocks
> >> and regulators is an absolute no-go. Putting things like "status" or
> >> "dma-coherent" in _DSD properties is absolutely unacceptable as well.
> >> But even things like initialization data that the driver programs
> >> into the device a single time really do not belong in _DSD. Instead,
> >> it should be the firmware that initializes the device, and presents it to the OS
> in its initialized state.
> >>
> >
> > Agreed, I never meant something to add in DSD which was prohibited in ACPI
> spces.
> >
> >>>
> >>>>> Right, here device driver should know that device is present in
> >>>>> system, I see probe function (device-driver binding) is way to know this.
> >>>>> Then driver can execute AML methods exposed by firmware.
> >>>>>
> >>>>
> >>>> Yes, declaring the presence of the device is the main purpose of
> >>>> describing it both in ACPI and in DT.
> >>>>
> >>>>>> An ACPI device has AML methods to manage power state and perform
> >>>>>> other device related low-level tasks. The device driver has no
> >>>>>> knowledge of the hardware beyond what it needs to invoke those
> >>>>>> abstract
> >>>> methods.
> >>>>>
> >>>>> You meant, If we need to update driver for AML methods then why
> >>>>> not to
> >>>> update binding as well . ?
> >>>>>
> >>>>
> >>>> No. What I am saying is that you should not expose two different
> >>>> bindings, and let the OS choose.
> >>>
> >>> Ok, got it , then PRP00001 stuff should be used only at urgent or
> >>> say no other choice left , Right ?
> >>>
> >>
> >> Yes.
> >
> >
> >>>>> On side track,
> >>>>>   With limited search,  I got many each driver is having (acpi_id
> >>>>> and of_id), looks, acpi support is added on the top of DT flavored drivers.
> >>>>> and therefore acpi tables are following the same.
> >>>>> Sorry to say, reference I am looking at (edk2-platform) JunoPkg
> >>>>> and VExpressPkg, Has following devices has description similar to Device
> tree
> >>>>>      Device (NET0) {
> >>>>>      Device (SREG) {
> >>>>>      Device (VIRT) {
> >>>>
> >>>> These were taken from the ACPI tables for an emulator
> >>>>
> >>>>>     Device(KMI0) {
> >>>>
> >>>> I have no clue what kind of device this is
> >>>>
> >>>>>     Device(ETH0) {
> >>>>
> >>>> This one uses _DSD as intended, to set device properties in a DT
> >>>> compatible fashion, but note that this does *not* include the
> >>>> 'compatible' property, nor anything else that ACPI defines itself
> >>>> (status, dma-coherent, etc)
> >>>
> >>> Let me put in simple way,
> >>> A simple driver can survive only with _DSD in acpi world.
> >>> (clocking/regulators are used as said in UEFI/ACPI)
> >>>
> >>
> >> Why can a simple driver only survive with _DSD? That statement does
> >> not make any sense to me.
> >
> > Why so, please see below one for example
> >
> >>> Copying below from Juno,
> >>> Are below kind of tables are acceptable ?
> >>>
> >>>      Device(ETH0) {
> >>>        Name(_HID, "ARMH9118")
> >>>        Name(_UID, Zero)
> >>>        Name(_CRS, ResourceTemplate() {
> >>>                Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
> >>>                Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
> >>>        })
> >>>        Name(_DSD, Package() {
> >>>                     ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >>>                         Package() {
> >>>                                 Package(2) {"phy-mode", "mii"},
> >>>                                 Package(2) {"reg-io-width", 4 },
> >>>                                 Package(2) {"smsc,irq-active-high",1},
> >>>                                 Package(2) {"smsc,irq-push-pull",1}
> >>>                        }
> >>>        }) // _DSD()
> >>>      }
> >>>
> >>
> >> Yes. But please be aware that you should not simply invent your own
> >> properties here. The _DSD namespace was intended to be managed, and
> >> not free for all
> >
> > Agreed, I didn’t meant to add something new, which is not available at
> > present,
> >
> >
> >> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> >> w.k
> >> ernel.org%2Fdoc%2FDocumentation%2Facpi%2FDSD-properties-
> >>
> rules.txt&data=02%7C01%7Cudit.kumar%40nxp.com%7C164c1ff7350a4f6373e
> >>
> e08d530e8b591%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63646
> >>
> 8698397705869&sdata=O78k8r6tcK9fwpuTuQ82ZXGiWkBtLduf4bqrM6D6L1U%
> >> 3D&reserved=0
> >>
> >>>>> Where no AML method is exposed. Then I expect OS driver to manage
> >>>>> this
> >>>> device.
> >>>>> While grepping over few other edk2-platforms.  Looks some of
> >>>>> methods are abstracted, not whole device.
> >>>>>
> >>>>
> >>>> So what is your point? Why does this argue in favor of allowing
> >>>> PRP0001 + compatible?
> >>>
> >>> I am seeking your help here to define HID and CID,  please see above
> >>> Also for non-NXP devices, how to define HID (if PRP0001 + compatible
> >>> not to be used)
> >>>
> >>
> >> This could be a valid reason to use PRP0001 + compatible, for things
> >> like I2C slaves that are external to the SoC
> >
> > Well,  for internal SOC devices, I am in agreement to use NXP specific
> > HIDs But for external devices (for which HID is not available), you
> > suggest to go With PRP0001 + compatible
> >
> >>>>>> A DT device describes everything in detail, and requires clock
> >>>>>> and regulator drivers and other bits and pieces that are tightly
> >>>>>> coupled to details of the hardware.
> >>>>>>
> >>>>>> So now, you have the worst of both worlds:
> >>>>>>
> >>>>>> - you need to implement all of this in firmware so ACPI can
> >>>>>> support it,
> >>>>>> - you have to expose the internals to the OS so DT can support it.
> >>>>>
> >>>>> Yes, for time being or may be longer, DT support needs to be there
> >>>>> along with ACPI introduction.
> >>>>>
> >>>>> Are you suggesting here to abstract whole device details from OS
> >>>>> and expose AML methods to be used by device driver.
> >>>>> And maintain two drivers instead of fitting DT style driver into ACPI world
> ?
> >>>>>
> >>>>
> >>>> No. You should update the driver so it can support both ACPI and DT
> bindings.
> >>>> That way, the driver can use the abstractions offered by ACPI when
> >>>> it can, and can invoke the clock and regulator frameworks and other
> >>>> low level infrastructure only when it needs to.
> >>>
> >>> Ok, I am align on this, to have one driver which supports both.
> >>>
> >>>> Let me try to illustrate this a bit better: imagine a NXP customer
> >>>> that runs a datacenter that has 10,000 NXP servers, and is using
> >>>> RHEL x.y. The business is going well, and at some point, he wants
> >>>> to order another
> >> 2,000 servers.
> >>>> Unfortunately, the vendor cannot supply the exact same revision of
> >>>> the hardware, and the latest revision uses some component that is
> >>>> not supported in RHEL x.y.
> >>>>
> >>>> You now have made your customer very unhappy. He invested in RHEL
> >>>> and ACPI based servers precisely to avoid this situation. The cost
> >>>> of adding 2,000 servers now includes the cost of upgrading the
> >>>> other
> >>>> 10,000 servers to a new OS version or the cost of supporting two
> >>>> different OS versions at the same time, for a reason that is not justifiable.
> >>>
> >>> Do you mean here with PRP0001 HID/CID, we cannot use AML methods.
> >>
> >> You cannot use the abstractions ACPI provides when using PRP0001 +
> >> compatible.
> > Oh, thx
> >

Re: [RFC] ACPI table HID/CID allocation

[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 <https://stash.sd.apple.com/projects/COREOSMACFW/repos/macefifirmware/pull-requests/630/overview>. Anyone can make a request. 

PNP ID Registry: http://www.uefi.org/pnp_id_list <http://www.uefi.org/pnp_id_list>
ACPI ID Registry: http://www.uefi.org/acpi_id_list <http://www.uefi.org/acpi_id_list>

Thanks,

Andrew Fish

> On Nov 22, 2017, at 5:39 AM, Udit Kumar <udit.kumar@nxp.com> wrote:
> 
> 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 because I don't understand why there is no HID
>> available.
> 
> This is more a choice/rule between allocating HID or using PRP0001.
> HID could be assigned to external devices, and getting them reviewed 
> by maintainers. 
> 
>> Large OEMs and board manufacturers usually have their own vendor IDs and
>> sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx on
>> the ARM Juno uses an ARM HID).
> 
> Thanks,  for this example. 
> This is good example for me, where HID allocation is not limited to Vendor devices.
> 
> 
>> Admittedly the part you are describing follows a JEDEC standard so it would be
>> nice to have more widely agreed bindings... however making SPI NOR FLASH
>> available as raw MTD device to the OS is sufficiently unusual in ACPI systems
>> that there may not be any prior art to follow.
> 
> Please take this as an example. ( Main point was to use HID or PRP0001)
> Could be possible, if such device is exposed then this may not be used at all.
> Thanks for help. 
> 
> Thanks
> Udit 
> 
>> 
>> Daniel.
>> 
>> 
>>> 
>>> As you pointed out, are external devices to SOC such exception to use
>>> PRP0001 + compatible be it i2c slave or SPI slave ?
>>> 
>>> 
>>> Regards
>>> Udit
>>> 
>>>> -----Original Message-----
>>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>>>> Sent: Tuesday, November 21, 2017 7:34 PM
>>>> To: Udit Kumar <udit.kumar@nxp.com>
>>>> Cc: Leif Lindholm <leif.lindholm@linaro.org>;
>>>> edk2-devel@lists.01.org; Varun Sethi <V.Sethi@nxp.com>; Daniel
>>>> Thompson <daniel.thompson@linaro.org>; Graeme Gregory
>>>> <graeme.gregory@linaro.org>
>>>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>>> 
>>>> On 21 November 2017 at 13:24, Udit Kumar <udit.kumar@nxp.com> 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) {
>>>>>                                 Name(_CID, "PRP0001")
>>>>>                  }
>>>>> }
>>>>> is ok or
>>>>> 
>>>>> 
>>>>> Device(XYZ) {
>>>>>                 Name(_HID, "NXP0001")
>>>>>                 Name(_CID, " NXP0001")
>>>>>           Device(Slave1) {
>>>>>                                 Name(_CID, " NXP0002")
>>>>>                  }
>>>>> }
>>>>> Seems good
>>>>> 
>>>> 
>>>> I don't think it makes a lot of sense to use the same value for _HID
>>>> and _CID, so you can just drop the latter.
>>> 
>>> Sure,
>>> 
>>>>> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
>>>>> be
>>>> coded in table using either of.
>>>>> 
>>>>> Please see more in line
>>>>> 
>>>>> Regards
>>>>> Udit
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
>>>>>> Sent: Tuesday, November 21, 2017 5:59 PM
>>>>>> To: Udit Kumar <udit.kumar@nxp.com>
>>>>>> Cc: Leif Lindholm <leif.lindholm@linaro.org>;
>>>>>> edk2-devel@lists.01.org; Varun Sethi <V.Sethi@nxp.com>; Daniel
>>>>>> Thompson <daniel.thompson@linaro.org>; Graeme Gregory
>>>>>> <graeme.gregory@linaro.org>
>>>>>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>>>>> 
>>>>>> On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com>
>> wrote:
>>>>>>> 
>>>>>>>> On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com>
>>>> 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 PRP00001) and Linux to decide binding
>>>>>>>> 
>>>>>>>> No.
>>>>>>>> 
>>>>>>>> You are still assuming ACPI and DT device drivers bind at the
>>>>>>>> same level, and they don't.
>>>>>>> 
>>>>>>> No, my above comments was just limited to binding.
>>>>>> 
>>>>>> Yes, but if you leave it to the OS to decide which binding it uses,
>>>>>> you will have to support all of them into eternity. And the more
>>>>>> detailed binding you need to support may limit you in the available
>>>>>> choices when it comes to making hardware changes, something ACPI
>>>>>> allows
>>>> you to do.
>>>>> 
>>>>> Thanks,
>>>>> Is this ok to say , we can provide max same properties in driver as
>>>>> of DT (with _DSD) , But prefer to use AML methods.
>>>>> With note, clocking regulators are out of scope here.
>>>>> 
>>>> 
>>>> Yes. _DSD may be used to describe device specific data that goes
>>>> beyond what ACPI can express natively. Using _DSD to describe clocks
>>>> and regulators is an absolute no-go. Putting things like "status" or
>>>> "dma-coherent" in _DSD properties is absolutely unacceptable as well.
>>>> But even things like initialization data that the driver programs
>>>> into the device a single time really do not belong in _DSD. Instead,
>>>> it should be the firmware that initializes the device, and presents it to the OS
>> in its initialized state.
>>>> 
>>> 
>>> Agreed, I never meant something to add in DSD which was prohibited in ACPI
>> spces.
>>> 
>>>>> 
>>>>>>> Right, here device driver should know that device is present in
>>>>>>> system, I see probe function (device-driver binding) is way to know this.
>>>>>>> Then driver can execute AML methods exposed by firmware.
>>>>>>> 
>>>>>> 
>>>>>> Yes, declaring the presence of the device is the main purpose of
>>>>>> describing it both in ACPI and in DT.
>>>>>> 
>>>>>>>> An ACPI device has AML methods to manage power state and perform
>>>>>>>> other device related low-level tasks. The device driver has no
>>>>>>>> knowledge of the hardware beyond what it needs to invoke those
>>>>>>>> abstract
>>>>>> methods.
>>>>>>> 
>>>>>>> You meant, If we need to update driver for AML methods then why
>>>>>>> not to
>>>>>> update binding as well . ?
>>>>>>> 
>>>>>> 
>>>>>> No. What I am saying is that you should not expose two different
>>>>>> bindings, and let the OS choose.
>>>>> 
>>>>> Ok, got it , then PRP00001 stuff should be used only at urgent or
>>>>> say no other choice left , Right ?
>>>>> 
>>>> 
>>>> Yes.
>>> 
>>> 
>>>>>>> On side track,
>>>>>>>  With limited search,  I got many each driver is having (acpi_id
>>>>>>> and of_id), looks, acpi support is added on the top of DT flavored drivers.
>>>>>>> and therefore acpi tables are following the same.
>>>>>>> Sorry to say, reference I am looking at (edk2-platform) JunoPkg
>>>>>>> and VExpressPkg, Has following devices has description similar to Device
>> tree
>>>>>>>     Device (NET0) {
>>>>>>>     Device (SREG) {
>>>>>>>     Device (VIRT) {
>>>>>> 
>>>>>> These were taken from the ACPI tables for an emulator
>>>>>> 
>>>>>>>    Device(KMI0) {
>>>>>> 
>>>>>> I have no clue what kind of device this is
>>>>>> 
>>>>>>>    Device(ETH0) {
>>>>>> 
>>>>>> This one uses _DSD as intended, to set device properties in a DT
>>>>>> compatible fashion, but note that this does *not* include the
>>>>>> 'compatible' property, nor anything else that ACPI defines itself
>>>>>> (status, dma-coherent, etc)
>>>>> 
>>>>> Let me put in simple way,
>>>>> A simple driver can survive only with _DSD in acpi world.
>>>>> (clocking/regulators are used as said in UEFI/ACPI)
>>>>> 
>>>> 
>>>> Why can a simple driver only survive with _DSD? That statement does
>>>> not make any sense to me.
>>> 
>>> Why so, please see below one for example
>>> 
>>>>> Copying below from Juno,
>>>>> Are below kind of tables are acceptable ?
>>>>> 
>>>>>     Device(ETH0) {
>>>>>       Name(_HID, "ARMH9118")
>>>>>       Name(_UID, Zero)
>>>>>       Name(_CRS, ResourceTemplate() {
>>>>>               Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
>>>>>               Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
>>>>>       })
>>>>>       Name(_DSD, Package() {
>>>>>                    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>>>>>                        Package() {
>>>>>                                Package(2) {"phy-mode", "mii"},
>>>>>                                Package(2) {"reg-io-width", 4 },
>>>>>                                Package(2) {"smsc,irq-active-high",1},
>>>>>                                Package(2) {"smsc,irq-push-pull",1}
>>>>>                       }
>>>>>       }) // _DSD()
>>>>>     }
>>>>> 
>>>> 
>>>> Yes. But please be aware that you should not simply invent your own
>>>> properties here. The _DSD namespace was intended to be managed, and
>>>> not free for all
>>> 
>>> Agreed, I didn’t meant to add something new, which is not available at
>>> present,
>>> 
>>> 
>>>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>>>> w.k
>>>> ernel.org%2Fdoc%2FDocumentation%2Facpi%2FDSD-properties-
>>>> 
>> rules.txt&data=02%7C01%7Cudit.kumar%40nxp.com%7C164c1ff7350a4f6373e
>>>> 
>> e08d530e8b591%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63646
>>>> 
>> 8698397705869&sdata=O78k8r6tcK9fwpuTuQ82ZXGiWkBtLduf4bqrM6D6L1U%
>>>> 3D&reserved=0
>>>> 
>>>>>>> Where no AML method is exposed. Then I expect OS driver to manage
>>>>>>> this
>>>>>> device.
>>>>>>> While grepping over few other edk2-platforms.  Looks some of
>>>>>>> methods are abstracted, not whole device.
>>>>>>> 
>>>>>> 
>>>>>> So what is your point? Why does this argue in favor of allowing
>>>>>> PRP0001 + compatible?
>>>>> 
>>>>> I am seeking your help here to define HID and CID,  please see above
>>>>> Also for non-NXP devices, how to define HID (if PRP0001 + compatible
>>>>> not to be used)
>>>>> 
>>>> 
>>>> This could be a valid reason to use PRP0001 + compatible, for things
>>>> like I2C slaves that are external to the SoC
>>> 
>>> Well,  for internal SOC devices, I am in agreement to use NXP specific
>>> HIDs But for external devices (for which HID is not available), you
>>> suggest to go With PRP0001 + compatible
>>> 
>>>>>>>> A DT device describes everything in detail, and requires clock
>>>>>>>> and regulator drivers and other bits and pieces that are tightly
>>>>>>>> coupled to details of the hardware.
>>>>>>>> 
>>>>>>>> So now, you have the worst of both worlds:
>>>>>>>> 
>>>>>>>> - you need to implement all of this in firmware so ACPI can
>>>>>>>> support it,
>>>>>>>> - you have to expose the internals to the OS so DT can support it.
>>>>>>> 
>>>>>>> Yes, for time being or may be longer, DT support needs to be there
>>>>>>> along with ACPI introduction.
>>>>>>> 
>>>>>>> Are you suggesting here to abstract whole device details from OS
>>>>>>> and expose AML methods to be used by device driver.
>>>>>>> And maintain two drivers instead of fitting DT style driver into ACPI world
>> ?
>>>>>>> 
>>>>>> 
>>>>>> No. You should update the driver so it can support both ACPI and DT
>> bindings.
>>>>>> That way, the driver can use the abstractions offered by ACPI when
>>>>>> it can, and can invoke the clock and regulator frameworks and other
>>>>>> low level infrastructure only when it needs to.
>>>>> 
>>>>> Ok, I am align on this, to have one driver which supports both.
>>>>> 
>>>>>> Let me try to illustrate this a bit better: imagine a NXP customer
>>>>>> that runs a datacenter that has 10,000 NXP servers, and is using
>>>>>> RHEL x.y. The business is going well, and at some point, he wants
>>>>>> to order another
>>>> 2,000 servers.
>>>>>> Unfortunately, the vendor cannot supply the exact same revision of
>>>>>> the hardware, and the latest revision uses some component that is
>>>>>> not supported in RHEL x.y.
>>>>>> 
>>>>>> You now have made your customer very unhappy. He invested in RHEL
>>>>>> and ACPI based servers precisely to avoid this situation. The cost
>>>>>> of adding 2,000 servers now includes the cost of upgrading the
>>>>>> other
>>>>>> 10,000 servers to a new OS version or the cost of supporting two
>>>>>> different OS versions at the same time, for a reason that is not justifiable.
>>>>> 
>>>>> Do you mean here with PRP0001 HID/CID, we cannot use AML methods.
>>>> 
>>>> You cannot use the abstractions ACPI provides when using PRP0001 +
>>>> compatible.
>>> Oh, thx
>>> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] ACPI table HID/CID allocation

[Ard Biesheuvel]

On 22 November 2017 at 11:30, Daniel Thompson
<daniel.thompson@linaro.org> 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 external to the SoC
>>
>>
>> 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 because I don't understand why there
> is no HID available.
>

PRP0001 + compatible was invented to avoid the need to allocate a _HID
for each and every component in existence that can already be
identified by a DT compatible string (and little else except, e.g., a
I2C slave address) and is not deeply engrained in the SoC in terms of
clock tree, power states etc. So while internal/external may not be
the most accurate distinction, it is still a useful one IMHO.

Re: [RFC] ACPI table HID/CID allocation

[Daniel Thompson]

On 22/11/17 19:39, Ard Biesheuvel wrote:
> On 22 November 2017 at 11:30, Daniel Thompson
> <daniel.thompson@linaro.org> 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 external to the SoC
>>>
>>>
>>> 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 because I don't understand why there
>> is no HID available.
>>
> 
> PRP0001 + compatible was invented to avoid the need to allocate a _HID
> for each and every component in existence that can already be
> identified by a DT compatible string (and little else except, e.g., a
> I2C slave address) and is not deeply engrained in the SoC in terms of
> clock tree, power states etc. So while internal/external may not be
> the most accurate distinction, it is still a useful one IMHO.

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 
Linux; the kernel driver now contains a quirks tables to look up by 
device ID whether fast read is supported and will use that on non-DT 
systems (and also to censor broken DT systems ;-) ).


Daniel.

Re: [RFC] ACPI table HID/CID allocation

[Udit Kumar]

Thanks Andrew,
We have one ACPI PNP ID.
I am looking for better way to define ACPI tables. Say a driver (could be slave or master) can work with PRP0001, (example flashes, i2c slaves)
then do we need to define HID for the same or not . With condition such driver don’t expose or need some AML methods to be implemented.

Regards
Udit

From: afish@apple.com [mailto:afish@apple.com]
Sent: Wednesday, November 22, 2017 11:05 PM
To: Udit Kumar <udit.kumar@nxp.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel@lists.01.org; Leif Lindholm <leif.lindholm@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-requests/630/overview<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstash.sd.apple.com%2Fprojects%2FCOREOSMACFW%2Frepos%2Fmacefifirmware%2Fpull-requests%2F630%2Foverview&data=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091&sdata=Cgf%2B0oIi8sbAFYi%2FUghFBBWJzkfUhNPEvRDiLRyvd%2FQ%3D&reserved=0>. Anyone can make a request.

PNP ID Registry: http://www.uefi.org/pnp_id_list<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uefi.org%2Fpnp_id_list&data=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091&sdata=CFZj6YvToS%2FseGn38djKKARF8JpoMUvkwChZf3JHwzo%3D&reserved=0>
ACPI ID Registry: http://www.uefi.org/acpi_id_list<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uefi.org%2Facpi_id_list&data=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091&sdata=DWgfdanDSssKaYcJ0UJ4djgy6l4lxdv%2BfdHCrif9JHA%3D&reserved=0>

Thanks,

Andrew Fish

On Nov 22, 2017, at 5:39 AM, Udit Kumar <udit.kumar@nxp.com<mailto:udit.kumar@nxp.com>> wrote:

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 because I don't understand why there is no HID
available.

This is more a choice/rule between allocating HID or using PRP0001.
HID could be assigned to external devices, and getting them reviewed
by maintainers.


Large OEMs and board manufacturers usually have their own vendor IDs and
sometimes have to use these to describe hardware (IIRC the SMC LAN9xxx on
the ARM Juno uses an ARM HID).

Thanks,  for this example.
This is good example for me, where HID allocation is not limited to Vendor devices.



Admittedly the part you are describing follows a JEDEC standard so it would be
nice to have more widely agreed bindings... however making SPI NOR FLASH
available as raw MTD device to the OS is sufficiently unusual in ACPI systems
that there may not be any prior art to follow.

Please take this as an example. ( Main point was to use HID or PRP0001)
Could be possible, if such device is exposed then this may not be used at all.
Thanks for help.

Thanks
Udit



Daniel.




As you pointed out, are external devices to SOC such exception to use
PRP0001 + compatible be it i2c slave or SPI slave ?


Regards
Udit


-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Tuesday, November 21, 2017 7:34 PM
To: Udit Kumar <udit.kumar@nxp.com<mailto:udit.kumar@nxp.com>>
Cc: Leif Lindholm <leif.lindholm@linaro.org<mailto:leif.lindholm@linaro.org>>;
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Varun Sethi <V.Sethi@nxp.com<mailto:V.Sethi@nxp.com>>; Daniel
Thompson <daniel.thompson@linaro.org<mailto:daniel.thompson@linaro.org>>; Graeme Gregory
<graeme.gregory@linaro.org<mailto:graeme.gregory@linaro.org>>
Subject: Re: [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 13:24, Udit Kumar <udit.kumar@nxp.com<mailto:udit.kumar@nxp.com>> 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) {
                                Name(_CID, "PRP0001")
                 }
}
is ok or


Device(XYZ) {
                Name(_HID, "NXP0001")
                Name(_CID, " NXP0001")
          Device(Slave1) {
                                Name(_CID, " NXP0002")
                 }
}
Seems good

I don't think it makes a lot of sense to use the same value for _HID
and _CID, so you can just drop the latter.

Sure,


For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will to
be
coded in table using either of.


Please see more in line

Regards
Udit


-----Original Message-----
From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
Sent: Tuesday, November 21, 2017 5:59 PM
To: Udit Kumar <udit.kumar@nxp.com<mailto:udit.kumar@nxp.com>>
Cc: Leif Lindholm <leif.lindholm@linaro.org<mailto:leif.lindholm@linaro.org>>;
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Varun Sethi <V.Sethi@nxp.com<mailto:V.Sethi@nxp.com>>; Daniel
Thompson <daniel.thompson@linaro.org<mailto:daniel.thompson@linaro.org>>; Graeme Gregory
<graeme.gregory@linaro.org<mailto:graeme.gregory@linaro.org>>
Subject: Re: [RFC] ACPI table HID/CID allocation

On 21 November 2017 at 11:32, Udit Kumar <udit.kumar@nxp.com<mailto:udit.kumar@nxp.com>>
wrote:



On 21 November 2017 at 09:59, Udit Kumar <udit.kumar@nxp.com<mailto:udit.kumar@nxp.com>>
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 PRP00001) and Linux to decide binding

No.

You are still assuming ACPI and DT device drivers bind at the
same level, and they don't.

No, my above comments was just limited to binding.

Yes, but if you leave it to the OS to decide which binding it uses,
you will have to support all of them into eternity. And the more
detailed binding you need to support may limit you in the available
choices when it comes to making hardware changes, something ACPI
allows
you to do.


Thanks,
Is this ok to say , we can provide max same properties in driver as
of DT (with _DSD) , But prefer to use AML methods.
With note, clocking regulators are out of scope here.

Yes. _DSD may be used to describe device specific data that goes
beyond what ACPI can express natively. Using _DSD to describe clocks
and regulators is an absolute no-go. Putting things like "status" or
"dma-coherent" in _DSD properties is absolutely unacceptable as well.
But even things like initialization data that the driver programs
into the device a single time really do not belong in _DSD. Instead,
it should be the firmware that initializes the device, and presents it to the OS
in its initialized state.



Agreed, I never meant something to add in DSD which was prohibited in ACPI
spces.





Right, here device driver should know that device is present in
system, I see probe function (device-driver binding) is way to know this.
Then driver can execute AML methods exposed by firmware.

Yes, declaring the presence of the device is the main purpose of
describing it both in ACPI and in DT.


An ACPI device has AML methods to manage power state and perform
other device related low-level tasks. The device driver has no
knowledge of the hardware beyond what it needs to invoke those
abstract
methods.


You meant, If we need to update driver for AML methods then why
not to
update binding as well . ?



No. What I am saying is that you should not expose two different
bindings, and let the OS choose.

Ok, got it , then PRP00001 stuff should be used only at urgent or
say no other choice left , Right ?

Yes.



On side track,
 With limited search,  I got many each driver is having (acpi_id
and of_id), looks, acpi support is added on the top of DT flavored drivers.
and therefore acpi tables are following the same.
Sorry to say, reference I am looking at (edk2-platform) JunoPkg
and VExpressPkg, Has following devices has description similar to Device
tree

    Device (NET0) {
    Device (SREG) {
    Device (VIRT) {

These were taken from the ACPI tables for an emulator


   Device(KMI0) {

I have no clue what kind of device this is


   Device(ETH0) {

This one uses _DSD as intended, to set device properties in a DT
compatible fashion, but note that this does *not* include the
'compatible' property, nor anything else that ACPI defines itself
(status, dma-coherent, etc)

Let me put in simple way,
A simple driver can survive only with _DSD in acpi world.
(clocking/regulators are used as said in UEFI/ACPI)

Why can a simple driver only survive with _DSD? That statement does
not make any sense to me.

Why so, please see below one for example


Copying below from Juno,
Are below kind of tables are acceptable ?

    Device(ETH0) {
      Name(_HID, "ARMH9118")
      Name(_UID, Zero)
      Name(_CRS, ResourceTemplate() {
              Memory32Fixed(ReadWrite, 0x18000000, 0x1000)
              Interrupt(ResourceConsumer, Level, ActiveHigh, Exclusive) { 192 }
      })
      Name(_DSD, Package() {
                   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
                       Package() {
                               Package(2) {"phy-mode", "mii"},
                               Package(2) {"reg-io-width", 4 },
                               Package(2) {"smsc,irq-active-high",1},
                               Package(2) {"smsc,irq-push-pull",1}
                      }
      }) // _DSD()
    }

Yes. But please be aware that you should not simply invent your own
properties here. The _DSD namespace was intended to be managed, and
not free for all

Agreed, I didn’t meant to add something new, which is not available at
present,



https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.k
ernel.org%2Fdoc%2FDocumentation%2Facpi%2FDSD-properties-
rules.txt&data=02%7C01%7Cudit.kumar%40nxp.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40nxp.com&data=02%7C01%7Cudit.kumar%40nxp.com%7C1a3ff6112c264748866708d531cf4d9b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636469688791080091&sdata=9usd%2B0c9dtpM0nEXU7tN%2BEzT4Swsee4IpCfotH3Vwg4%3D&reserved=0>%7C164c1ff7350a4f6373e


e08d530e8b591%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63646


8698397705869&sdata=O78k8r6tcK9fwpuTuQ82ZXGiWkBtLduf4bqrM6D6L1U%

3D&reserved=0


Where no AML method is exposed. Then I expect OS driver to manage
this
device.

While grepping over few other edk2-platforms.  Looks some of
methods are abstracted, not whole device.

So what is your point? Why does this argue in favor of allowing
PRP0001 + compatible?

I am seeking your help here to define HID and CID,  please see above
Also for non-NXP devices, how to define HID (if PRP0001 + compatible
not to be used)

This could be a valid reason to use PRP0001 + compatible, for things
like I2C slaves that are external to the SoC

Well,  for internal SOC devices, I am in agreement to use NXP specific
HIDs But for external devices (for which HID is not available), you
suggest to go With PRP0001 + compatible


A DT device describes everything in detail, and requires clock
and regulator drivers and other bits and pieces that are tightly
coupled to details of the hardware.

So now, you have the worst of both worlds:

- you need to implement all of this in firmware so ACPI can
support it,
- you have to expose the internals to the OS so DT can support it.

Yes, for time being or may be longer, DT support needs to be there
along with ACPI introduction.

Are you suggesting here to abstract whole device details from OS
and expose AML methods to be used by device driver.
And maintain two drivers instead of fitting DT style driver into ACPI world
?



No. You should update the driver so it can support both ACPI and DT
bindings.

That way, the driver can use the abstractions offered by ACPI when
it can, and can invoke the clock and regulator frameworks and other
low level infrastructure only when it needs to.

Ok, I am align on this, to have one driver which supports both.


Let me try to illustrate this a bit better: imagine a NXP customer
that runs a datacenter that has 10,000 NXP servers, and is using
RHEL x.y. The business is going well, and at some point, he wants
to order another
2,000 servers.

Unfortunately, the vendor cannot supply the exact same revision of
the hardware, and the latest revision uses some component that is
not supported in RHEL x.y.

You now have made your customer very unhappy. He invested in RHEL
and ACPI based servers precisely to avoid this situation. The cost
of adding 2,000 servers now includes the cost of upgrading the
other
10,000 servers to a new OS version or the cost of supporting two
different OS versions at the same time, for a reason that is not justifiable.

Do you mean here with PRP0001 HID/CID, we cannot use AML methods.

You cannot use the abstractions ACPI provides when using PRP0001 +
compatible.
Oh, thx
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] ACPI table HID/CID allocation

[Udit Kumar]

> -----Original Message-----
> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org]
> Sent: Thursday, November 23, 2017 1:10 AM
> To: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Udit Kumar <udit.kumar@nxp.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun Sethi
> <V.Sethi@nxp.com>; Graeme Gregory <graeme.gregory@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 
> On 22 November 2017 at 11:30, Daniel Thompson
> <daniel.thompson@linaro.org> 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 external to the SoC
> >>
> >>
> >> 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 because I don't understand why there
> > is no HID available.
> >
> 
> PRP0001 + compatible was invented to avoid the need to allocate a _HID
> for each and every component in existence that can already be
> identified by a DT compatible string (and little else except, e.g., a
> I2C slave address) and is not deeply engrained in the SoC in terms of
> clock tree, power states etc. So while internal/external may not be
> the most accurate distinction, it is still a useful one IMHO.

Along with this line, say if a driver (what is available in kernel)
can work with PRP0001, and this driver is not exposing/need
any AML methods (i2c slave and flashes are good example here)
then no need to assign HID , right ? 

Re: [RFC] ACPI table HID/CID allocation

[Udit Kumar]

> -----Original Message-----
> From: Daniel Thompson [mailto:daniel.thompson@linaro.org]
> Sent: Thursday, November 23, 2017 1:42 AM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Udit Kumar <udit.kumar@nxp.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun Sethi
> <V.Sethi@nxp.com>; Graeme Gregory <graeme.gregory@linaro.org>
> Subject: Re: [RFC] ACPI table HID/CID allocation
> 

> >
> > PRP0001 + compatible was invented to avoid the need to allocate a _HID
> > for each and every component in existence that can already be
> > identified by a DT compatible string (and little else except, e.g., a
> > I2C slave address) and is not deeply engrained in the SoC in terms of
> > clock tree, power states etc. So while internal/external may not be
> > the most accurate distinction, it is still a useful one IMHO.
> 
> 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
> Linux; the kernel driver now contains a quirks tables to look up by
> device ID whether fast read is supported and will use that on non-DT
> systems (and also to censor broken DT systems ;-) ).


You mean, this more on bus frame work, how to probe slave. 
Example rtc-ds3232.c , when is spi mode just need name 
but for i2c mode it needs of_match_table

Thanks 
Udit 

Re: [RFC] ACPI table HID/CID allocation

[Andrew Fish]

> On Nov 25, 2017, at 4:56 AM, Udit Kumar <udit.kumar@nxp.com> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Daniel Thompson [mailto:daniel.thompson@linaro.org]
>> Sent: Thursday, November 23, 2017 1:42 AM
>> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Udit Kumar <udit.kumar@nxp.com>; Leif Lindholm
>> <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun Sethi
>> <V.Sethi@nxp.com>; Graeme Gregory <graeme.gregory@linaro.org>
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>> 
> 
>>> 
>>> PRP0001 + compatible was invented to avoid the need to allocate a _HID
>>> for each and every component in existence that can already be
>>> identified by a DT compatible string (and little else except, e.g., a
>>> I2C slave address) and is not deeply engrained in the SoC in terms of
>>> clock tree, power states etc. So while internal/external may not be
>>> the most accurate distinction, it is still a useful one IMHO.
>> 
>> 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
>> Linux; the kernel driver now contains a quirks tables to look up by
>> device ID whether fast read is supported and will use that on non-DT
>> systems (and also to censor broken DT systems ;-) ).
> 
> 
> You mean, this more on bus frame work, how to probe slave. 
> Example rtc-ds3232.c , when is spi mode just need name 
> but for i2c mode it needs of_match_table
> 

Udit,

I think it is more like you only need ACPI if you don't have a driver. If it is standard bus with standard drivers the OS code can do power management without any help from ACPI. In general ACPI exists to abstract chipsets that don't have OS drivers, or mother board layout of power plains, GPIOs, etc. 

Thanks,

Andrew Fish


> Thanks 
> Udit 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] ACPI table HID/CID allocation

[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. 

In some cases there could be some config registers in IP, which could 
leads to power down mode, then probably power management could be done
without ACPI. 
If we have clock and regulators doing power management,  then ACPI is needed.
No ? 

> In general ACPI exists to abstract chipsets that don't
> have OS drivers, or mother board layout of power plains, GPIOs, etc.

I can think of for power management, without specific driver if such
Power saving is limited to internal SOC.

For example, say temperature of mother board is read using 
some sensor connected with SOC over i2c line. And in SOC
i2c interface is behind some controller.
How do you see to read temperature without having a OS drivers.
For power management based on  temperature, we may not need a
driver.


Thanks,
 Udit

Re: [RFC] ACPI table HID/CID allocation

[Daniel Thompson]

On 25/11/17 12:56, Udit Kumar wrote:>> -----Original Message-----
>> From: Daniel Thompson [mailto:daniel.thompson@linaro.org]
>> Sent: Thursday, November 23, 2017 1:42 AM
>> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Udit Kumar <udit.kumar@nxp.com>; Leif Lindholm
>> <leif.lindholm@linaro.org>; edk2-devel@lists.01.org; Varun Sethi
>> <V.Sethi@nxp.com>; Graeme Gregory <graeme.gregory@linaro.org>
>> Subject: Re: [RFC] ACPI table HID/CID allocation
>>
> 
>>>
>>> PRP0001 + compatible was invented to avoid the need to allocate a _HID
>>> for each and every component in existence that can already be
>>> identified by a DT compatible string (and little else except, e.g., a
>>> I2C slave address) and is not deeply engrained in the SoC in terms of
>>> clock tree, power states etc. So while internal/external may not be
>>> the most accurate distinction, it is still a useful one IMHO.
>>
>> 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
>> Linux; the kernel driver now contains a quirks tables to look up by
>> device ID whether fast read is supported and will use that on non-DT
>> systems (and also to censor broken DT systems ;-) ).
> 
> You mean, this more on bus frame work, how to probe slave.
> Example rtc-ds3232.c , when is spi mode just need name
> but for i2c mode it needs of_match_table
I mean nothing more or less than that PRP0001 + compatible:jedec,spi-nor 
is tolerable within the ACPI tables (rather than allocating a HID) 
because it has no properties[1] beyond the bus configuration that ACPI 
can already describe

I'm afraid I don't understand how rtc-ds3232.c fits into this topic; 
there are no documented device tree bindings for the SPI variant of this 
part and, in any case, an RTC should use the ACPI interfaces 
(rtc-cmos.c) so the choice HID is a moot point; it should not be in the 
ACPI tables at all.


Daniel.


[1] Assuming one accepts the argument that the m25p,fast-read property
     can be ignored.
     ignored.

Re: [RFC] ACPI table HID/CID allocation

[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 Linux; the kernel driver now contains a quirks tables to
> >> look up by device ID whether fast read is supported and will use that
> >> on non-DT systems (and also to censor broken DT systems ;-) ).
> >
> > You mean, this more on bus frame work, how to probe slave.
> > Example rtc-ds3232.c , when is spi mode just need name but for i2c
> > mode it needs of_match_table
> I mean nothing more or less than that PRP0001 + compatible:jedec,spi-nor is
> tolerable within the ACPI tables (rather than allocating a HID) because it has no
> properties[1] beyond the bus configuration that ACPI can already describe

Thanks.  So tables are tolerable with PRP0001 + compatible
 
> I'm afraid I don't understand how rtc-ds3232.c fits into this topic; there are no

Not directly , but just to mention that this is more on bus frame work (or say
controller driver) how they are probing their slaves. 

> documented device tree bindings for the SPI variant of this part and, in any case,
> an RTC should use the ACPI interfaces
> (rtc-cmos.c) so the choice HID is a moot point; it should not be in the ACPI tables
> at all.

Sure, RTC will not be exposed by acpi tables. 

> 
> Daniel.
> 
> 
> [1] Assuming one accepts the argument that the m25p,fast-read property
>      can be ignored.
>      ignored.