From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=17.171.2.31; helo=mail-in21.apple.com; envelope-from=afish@apple.com; receiver=edk2-devel@lists.01.org Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id CC1EC220C1622 for ; Wed, 22 Nov 2017 09:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1511372075; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DEmhw4923cIo/7dEqugpIixgTsgShEIqxspHS1C3pQI=; b=IsUlW2qD/X304HL1d25WeI5P+YFgSXjYctpjTycc1AhtJj+AesjQBxVHek00pYOX XOkv415/VMMhXH6lz4XqFMSzAPIb7zgrBE5i3cBvnLJPcaAK7CjFMCJKz9W21+hP T/lyCAoyv9axYVQVPQOBvl8auhMcCdRIwWFvdHy2SIVt2eMhNon2BEAWC7gWXmWw AzFJMBr78uEArSQMPOKEtK6vsnwX/UdZLFD9s7Xzy93Ux5ajmiHpVAxQkEIhcyRt biiTBq6uyPPUi7zfUfBAF7xAGhItXX/Cducw5Q5+dMdG8rBH2LDWBNaMXphI8rZ5 oc2lxaRCBQAVPwXV9tKf/g==; Received: from relay27.apple.com (relay27.apple.com [17.171.128.108]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id CB.72.01566.B25B51A5; Wed, 22 Nov 2017 09:34:35 -0800 (PST) X-AuditID: 11ab0215-fddff7000000061e-89-5a15b52ba195 Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by relay27.apple.com (Apple SCV relay) with SMTP id B8.0D.31824.B25B51A5; Wed, 22 Nov 2017 09:34:35 -0800 (PST) MIME-version: 1.0 Received: from [17.234.161.189] by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.1.20171102 64bit (built Nov 2 2017)) with ESMTPSA id <0OZT00ESGY5JNXA0@ma1-mmpp-sz10.apple.com>; Wed, 22 Nov 2017 09:34:35 -0800 (PST) Sender: afish@apple.com From: Andrew Fish Message-id: <45939FDA-1DA8-424C-BBD1-4A46480DC6DD@apple.com> Date: Wed, 22 Nov 2017 09:34:31 -0800 In-reply-to: Cc: Daniel Thompson , Ard Biesheuvel , "edk2-devel@lists.01.org" , Leif Lindholm To: Udit Kumar References: X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUiuLohR1d7q2iUwZ/5ihb/P+xmtDjz5i67 xZ5DR5ktPu3ew2KxYskhNgdWjzvX9rB5dM/+x+Kx8d0OpgDmKC6blNSczLLUIn27BK6MJz/S CjZtY6pY/fQScwPjgk6mLkZODgkBE4nm9i3sILaQwHomic0TzWHia/4uYe5i5AKKH2aU+NLb DVbEKyAo8WPyPRYQm1kgTOLp7/tsEEXfGCWezb4MlhAWEJd4d2YTM4jNJqAssWL+B6BmDqBm G4kd8xkhSswlNs/6AjaTRUBVYs+lZjYQm1MgWaL32iUWkJnMAgcZJaa+awebIwI053bDFKiL nrJJPN63gBHiVFmJW7MvgSUkBHawSTz8doNxAqPQLCTXzkJy7SygQ5gF1CWmTMmFCGtLPHl3 gRXCVpNY+HsRE7L4Aka2VYzCuYmZObqZeUaGeokFBTmpesn5uZsYwZHDJLqDcf4rw0OMAhyM Sjy8DPNFo4RYE8uKK3MPMUpzsCiJ8y7UEY4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwLiq p/a8wOSQnVqLOlmcL89X9pQXEPr4LvQKX7rumjijE0tYfN79vvMiXuEfV0Xp2arYkGtRnBP1 Rc7vkl8psTZ29UP/o+t7FgvIaH/g2NRX+nT+DtZ9udaOLcv1LLyf/UjxuvGN++STMOmnTjYx Xv96d9wQqhA5c5uF/+uHdUlzbHR2K+9fv0WJpTgj0VCLuag4EQD8EwKffQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUiuLphmq72VtEogykzpSz+f9jNaHHmzV12 iz2HjjJbfNq9h8VixZJDbA6sHneu7WHz6J79j8Vj47sdTAHMUVw2Kak5mWWpRfp2CVwZT36k FWzaxlSx+ukl5gbGBZ1MXYycHBICJhJr/i5h7mLk4hASOMwo8aW3mx0kwSsgKPFj8j0WEJtZ IEzi6e/7bBBF3xglns2+DJYQFhCXeHdmEzOIzSagLLFi/gegZg6gZhuJHfMZIUrMJTbP+gI2 k0VAVWLPpWY2EJtTIFmi99olFpCZzAIHGSWmvmsHmyMCNOd2wxSoi56ySTzet4AR4lRZiVuz LzFPYOSfheTAWUgOnAW0m1lAXWLKlFyIsLbEk3cXWCFsNYmFvxcxIYsvYGRbxShYlJqTWGlk rpdYUJCTqpecn7uJERLqOTsY79w0O8QowMGoxMMbsVA0Sog1say4MvcQowQHs5IIb/ACoBBv SmJlVWpRfnxRaU5q8SFGaQ4WJXHezZ78UUIC6YklqdmpqQWpRTBZJg5OqQZGTku3nt5unztK WlvO7N6UxHGryMczpmdi6/8fq3Tkf0969OL7Hx3rt6svaFQ0uR7/ce3N8arNMySOeFg+v77A 8JPDj18LNUQLXnAmRv5XKv0wz4otb8O3ide5XqgrBC5n39XcxR+63fmc8AYZzWLfdIPdGm/D RCV5r7863Psm2XRjudgEYcUcJZbijERDLeai4kQAkycXdHECAAA= X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [RFC] ACPI table HID/CID allocation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 17:30:21 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 = . Anyone can make a request.=20 PNP ID Registry: http://www.uefi.org/pnp_id_list = ACPI ID Registry: http://www.uefi.org/acpi_id_list = Thanks, Andrew Fish > On Nov 22, 2017, at 5:39 AM, Udit Kumar wrote: >=20 > Hi Daniel=20 >=20 >=20 >>> 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. >>=20 >> 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. >=20 > This is more a choice/rule between allocating HID or using PRP0001. > HID could be assigned to external devices, and getting them reviewed=20= > by maintainers.=20 >=20 >> 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). >=20 > Thanks, for this example.=20 > This is good example for me, where HID allocation is not limited to = Vendor devices. >=20 >=20 >> 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. >=20 > 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.=20 >=20 > Thanks > Udit=20 >=20 >>=20 >> Daniel. >>=20 >>=20 >>>=20 >>> As you pointed out, are external devices to SOC such exception to = use >>> PRP0001 + compatible be it i2c slave or SPI slave ? >>>=20 >>>=20 >>> Regards >>> Udit >>>=20 >>>> -----Original Message----- >>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>>> Sent: Tuesday, November 21, 2017 7:34 PM >>>> To: Udit Kumar >>>> Cc: Leif Lindholm ; >>>> edk2-devel@lists.01.org; Varun Sethi ; Daniel >>>> Thompson ; Graeme Gregory >>>> >>>> Subject: Re: [RFC] ACPI table HID/CID allocation >>>>=20 >>>> On 21 November 2017 at 13:24, Udit Kumar = wrote: >>>>> Thanks Ard, >>>>>=20 >>>>> My intend of this email to know, what is right way to define HID = and >>>>> CID in ACPI firmware i.e >>>>>=20 >>>>> Device(XYZ) { >>>>> Name(_HID, "NXP0001") >>>>> Name(_CID, "PRP0001") >>>>> Device(Slave1) { >>>>> Name(_CID, "PRP0001") >>>>> } >>>>> } >>>>> is ok or >>>>>=20 >>>>>=20 >>>>> Device(XYZ) { >>>>> Name(_HID, "NXP0001") >>>>> Name(_CID, " NXP0001") >>>>> Device(Slave1) { >>>>> Name(_CID, " NXP0002") >>>>> } >>>>> } >>>>> Seems good >>>>>=20 >>>>=20 >>>> 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. >>>=20 >>> Sure, >>>=20 >>>>> For sure, AML methods (as needed _ON/OFF/RST/STA etc) /_DSD will = to >>>>> be >>>> coded in table using either of. >>>>>=20 >>>>> Please see more in line >>>>>=20 >>>>> Regards >>>>> Udit >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] >>>>>> Sent: Tuesday, November 21, 2017 5:59 PM >>>>>> To: Udit Kumar >>>>>> Cc: Leif Lindholm ; >>>>>> edk2-devel@lists.01.org; Varun Sethi ; Daniel >>>>>> Thompson ; Graeme Gregory >>>>>> >>>>>> Subject: Re: [RFC] ACPI table HID/CID allocation >>>>>>=20 >>>>>> On 21 November 2017 at 11:32, Udit Kumar >> wrote: >>>>>>>=20 >>>>>>>> On 21 November 2017 at 09:59, Udit Kumar >>>> wrote: >>>>>>>>> Thanks Ard. >>>>>>>>> Below table was for example. I am not converting whole DT to >>>>>>>>> ACPI tables :) My idea is to reduce Linux patches for probing = as >> possible. >>>>>>>>> Also keeping firmware and OS separately then Let firmware = expose >>>>>>>>> both way (HID and PRP00001) and Linux to decide binding >>>>>>>>=20 >>>>>>>> No. >>>>>>>>=20 >>>>>>>> You are still assuming ACPI and DT device drivers bind at the >>>>>>>> same level, and they don't. >>>>>>>=20 >>>>>>> No, my above comments was just limited to binding. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> Agreed, I never meant something to add in DSD which was prohibited = in ACPI >> spces. >>>=20 >>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>=20 >>>>>> Yes, declaring the presence of the device is the main purpose of >>>>>> describing it both in ACPI and in DT. >>>>>>=20 >>>>>>>> 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. >>>>>>>=20 >>>>>>> You meant, If we need to update driver for AML methods then why >>>>>>> not to >>>>>> update binding as well . ? >>>>>>>=20 >>>>>>=20 >>>>>> No. What I am saying is that you should not expose two different >>>>>> bindings, and let the OS choose. >>>>>=20 >>>>> Ok, got it , then PRP00001 stuff should be used only at urgent or >>>>> say no other choice left , Right ? >>>>>=20 >>>>=20 >>>> Yes. >>>=20 >>>=20 >>>>>>> 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) { >>>>>>=20 >>>>>> These were taken from the ACPI tables for an emulator >>>>>>=20 >>>>>>> Device(KMI0) { >>>>>>=20 >>>>>> I have no clue what kind of device this is >>>>>>=20 >>>>>>> Device(ETH0) { >>>>>>=20 >>>>>> 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) >>>>>=20 >>>>> 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) >>>>>=20 >>>>=20 >>>> Why can a simple driver only survive with _DSD? That statement does >>>> not make any sense to me. >>>=20 >>> Why so, please see below one for example >>>=20 >>>>> Copying below from Juno, >>>>> Are below kind of tables are acceptable ? >>>>>=20 >>>>> 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() >>>>> } >>>>>=20 >>>>=20 >>>> 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 >>>=20 >>> Agreed, I didn=E2=80=99t meant to add something new, which is not = available at >>> present, >>>=20 >>>=20 >>>> = https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww >>>> w.k >>>> ernel.org%2Fdoc%2FDocumentation%2Facpi%2FDSD-properties- >>>>=20 >> rules.txt&data=3D02%7C01%7Cudit.kumar%40nxp.com%7C164c1ff7350a4f6373e >>>>=20 >> e08d530e8b591%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63646 >>>>=20 >> 8698397705869&sdata=3DO78k8r6tcK9fwpuTuQ82ZXGiWkBtLduf4bqrM6D6L1U% >>>> 3D&reserved=3D0 >>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>=20 >>>>>> So what is your point? Why does this argue in favor of allowing >>>>>> PRP0001 + compatible? >>>>>=20 >>>>> 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) >>>>>=20 >>>>=20 >>>> This could be a valid reason to use PRP0001 + compatible, for = things >>>> like I2C slaves that are external to the SoC >>>=20 >>> 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 >>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> So now, you have the worst of both worlds: >>>>>>>>=20 >>>>>>>> - 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. >>>>>>>=20 >>>>>>> Yes, for time being or may be longer, DT support needs to be = there >>>>>>> along with ACPI introduction. >>>>>>>=20 >>>>>>> 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 >> ? >>>>>>>=20 >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> Ok, I am align on this, to have one driver which supports both. >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>=20 >>>>> Do you mean here with PRP0001 HID/CID, we cannot use AML methods. >>>>=20 >>>> You cannot use the abstractions ACPI provides when using PRP0001 + >>>> compatible. >>> Oh, thx >>>=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel