> >> 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
On 25/11/17 12:56, Udit Kumar wrote:>> -Original Message-
From: Daniel Thompson [mailto:daniel.thomp...@linaro.org]
Sent: Thursday, November 23, 2017 1:42 AM
To: Ard Biesheuvel
Cc: Udit Kumar ; Leif Lindholm
;
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.
> On Nov 25, 2017, at 4:56 AM, Udit Kumar wrote:
>
>
>
>> -Original Message-
>> From: Daniel Thompson [mailto:daniel.thomp...@linaro.org]
>> Sent: Thursday, November 23, 2017 1:42 AM
>> To: Ard Biesheuvel
>> Cc: Udit Kumar
> -Original Message-
> From: Daniel Thompson [mailto:daniel.thomp...@linaro.org]
> Sent: Thursday, November 23, 2017 1:42 AM
> To: Ard Biesheuvel
> Cc: Udit Kumar ; Leif Lindholm
> ; edk2-devel@lists.01.org; Varun
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 23, 2017 1:10 AM
> To: Daniel Thompson
> Cc: Udit Kumar ; Leif Lindholm
> ; edk2-devel@lists.01.org; Varun
org; Leif Lindholm
<leif.lindh...@linaro.org>
Subject: Re: [edk2] [RFC] ACPI table HID/CID allocation
FYI now that the UEFI Forum owns the ACPI Spec here is the location to register
a new PNP ID or ACPI ID:
https://stash.sd.apple.com/projects/COREOSMACFW/repos/macefifirmware/pull-req
On 22/11/17 19:39, Ard Biesheuvel wrote:
On 22 November 2017 at 11:30, Daniel Thompson
wrote:
On 21/11/17 18:10, Udit Kumar wrote:
Thanks Ard,
For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
This could be a valid reason to use PRP0001 +
On 22 November 2017 at 11:30, Daniel Thompson
wrote:
> On 21/11/17 18:10, Udit Kumar wrote:
>>
>> Thanks Ard,
>> For internal SOC devices, this is perfectly ok to drop PRP0001 from CID.
>>
>>> This could be a valid reason to use PRP0001 + compatible, for things like
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
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
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),
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 +
On 21 November 2017 at 13:24, Udit Kumar wrote:
> Thanks Ard,
>
> My intend of this email to know, what is right way to define HID and CID in
> ACPI firmware i.e
>
> Device(XYZ) {
> Name(_HID, "NXP0001")
> Name(_CID, "PRP0001")
>
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")
On 21 November 2017 at 11:32, Udit Kumar wrote:
>
>> On 21 November 2017 at 09:59, Udit Kumar wrote:
>> > Thanks Ard.
>> > Below table was for example. I am not converting whole DT to ACPI
>> > tables :) My idea is to reduce Linux patches for probing as
> On 21 November 2017 at 09:59, Udit Kumar wrote:
> > Thanks Ard.
> > Below table was for example. I am not converting whole DT to ACPI
> > tables :) My idea is to reduce Linux patches for probing as possible.
> > Also keeping firmware and OS separately then Let firmware
On 21 November 2017 at 09:59, Udit Kumar wrote:
> Thanks Ard.
> Below table was for example. I am not converting whole DT to ACPI tables :)
> My idea is to reduce Linux patches for probing as possible.
> Also keeping firmware and OS separately then
> Let firmware expose both
Thanks Ard.
Below table was for example. I am not converting whole DT to ACPI tables :)
My idea is to reduce Linux patches for probing as possible.
Also keeping firmware and OS separately then
Let firmware expose both way (HID and PRP1) and Linux to decide binding
Please see inline as
On 21 November 2017 at 09:19, Udit Kumar wrote:
> Hi,
>
> I am enabling ACPI on NXP platform , In order to do minimal changes in Linux
> driver for device-driver binding.
>
> I want to use PRP0001 device as CID and HID as actual (NXP allocated HID).
>
> So that Linux can bind
20 matches
Mail list logo