[edk2-devel] Device and driver

[Kumar G]

Thanks Tom,
I really appreciate your reply,
I didn't get 100% but I went through ~3K pages of UEFI specification.

I understand a bit of protocols and handles now.
Handle is an identifier on which some sort of function pointers (protocol
in UEFI world) are installed.

Thing which I am trying to understand, where EFI Boot service's connect
controller API says
'connect one or more drivers to controller'
Basically at code level, where this differentiation is done, what is
controller-handle and what is driver.

If you say , at entrypoint controller needs to install a protocol such as
I/O or read/write protocol supported by this controller-handle
(Say C1).
Later some piece of code (may be bus or other) create another
controller-handle (C2) (which is a device, connected over this i/o).
And the driver needs to install *only* device binding protocol.
During binding , this driver looks for controller (C2) and when found it
happily says matched or supported.
If the above rule is true, then it’s easy to understand the device (aka
controller-handle) and the driver.

But in a few places, I am not able to understand what is a controller and
what is a driver really.
e.g
at ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
By name this looks to be a driver for Lcd gfx,  but if this is driver then
what it has to do with device path.
Is this driver and controller  managed by the same code ? no clear
differentiation

For sure, this is new world for me, There will be differences w,r,t Linux

Thanks
KumarG

On Mon, 8 Jun 2020 at 17:04, Tomas Pilar <Tomas.Pilar at arm.com> wrote:

> Hi,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *   By no means a complete answer but some important points below.   There
> are two important concepts in UEFI that you absolutely need to get
> comfortable with. These two are Handles and Protocols.   You can think of a
> protocol as an implementation of a well defined API that allows you to do
> something. For example, do you want to print a string to screen? There is a
> SIMPLE_TEXT_OUT_PROTOCOL provided by the platform (hopefully) that allows
> you to do that. There might be multiple instances depending on how many
> devices support displaying/printing/outputting text. Do you want to send
> some data to a PCI device? The PCI_IO_PROTOCOL is your friend.
> Syntactically, a protocol is just a well-defined C struct, defined in a
> header file in an include folder somewhere (both the producer and the
> consumer of the protocol must have access to the header file). You can
> navigate to MdePkg/Include/Protocol to look at some examples.   Then there
> are handles (EFI_HANDLE). The main use of handles is that protocols are
> installed on handles, and as such can be conceptually grouped (a handle can
> carry many different protocols but a protocol instance is usually installed
> on only one handle). A ControllerHandle is just a handle – lets you install
> protocols on it. But importantly, the ControllerHandle contains those
> protocols that pertain to a single device. You can’t really do much if you
> are given a handle but you can check what protocols are installed on it and
> use those. When the platform enumerates peripheral devices, these are
> represented internally as ControllerHandles and each of them will have a
> PCI_IO_PROTOCOL already installed by the point a driver gets to it. That
> PCI_IO_PROTOCOL is then the way the driver can talk to the device. Handles
> are tracked in an internal database and you can search through them.
> Speaking of which. Most of the stuff you do in UEFI is done by protocols,
> with the main exception being the intrinsic services such as allocating
> memory, handling callbacks/events/locks, connecting/disconnecting devices,
> loading and executing files/code, and of course installing/using/removing
> protocols. These functionalities are provided by the BootServicesTable
> which you really need to read about in the UEFI Spec.   There really are no
> quick answers here unfortunately, you’ll have to get stuck in and play
> around until you get comfortable with things. I appreciate that the
> paradigm is quite different to for example Linux, but there are (usually)
> quite good reasons for many of the differences.   Cheers, Tom   From:
> devel at edk2.groups.io <devel at edk2.groups.io> <devel at edk2.groups.io
> <devel at edk2.groups.io>> On Behalf Of Kumar G via groups.io
> <http://groups.io> Sent: 08 June 2020 09:15 To: devel at edk2.groups.io
> <devel at edk2.groups.io> Subject: [edk2-devel] Device and driver   Hi Edk2
> expert folks, I am starting on UEFI coming from Linux background, In Linux,
> There is clear identification of device and driver, platform code adds the
> device into system and later OS code binds driver for the same. With UEFI
> driver writer guide, I am bit confused, please help me, how devices are
> being added in UEFI. what code/API adds device. Let me ask with an example,
> say i have PCI controller then driver for this controller (DXE_DRIVER)
> could be named as controller handle. Now there could be a driver
> represented as device handle, which handles device connected over this
> PCIe. Now when PCIe bus driver scans the bus then it found a PCIe device,
> how this bus driver adds the device into system ? Second, say we have spi
> controller and with this controller there is spi flash. with UEFI
> terminology spi controller will be controller handle spi flash will be
> device and driver for this flash will be called driver handle. spi
> controller and spi flash are marked as DXE_DRIVER what I am missing,where
> are added spi flash as device in system ? Sorry for basic question, but
> UEFI is complicated w.r.t originally i thought Thanks KumarG    *
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#60902): https://edk2.groups.io/g/devel/message/60902
Mute This Topic: https://groups.io/mt/74749142/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20200608/7181bc61/attachment.htm>