public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Girish Pathak <Girish.Pathak@arm.com>
To: edk2-devel <edk2-devel@lists.01.org>,
	"leif.lindholm@linaro.org" <leif.lindholm@linaro.org>,
	"ard.biesheuvel@linaro.org" <ard.biesheuvel@linaro.org>,
	"ryan.harkin@linaro.org" <ryan.harkin@linaro.org>
Cc: Evan Lloyd <Evan.Lloyd@arm.com>,
	Sami Mujawar <Sami.Mujawar@arm.com>,
	Alexei Fedorov <Alexei.Fedorov@arm.com>
Subject: ArmPlatformPkg: LcdGraphicsOutputDxe, PL111, and HdLcd rejig
Date: Wed, 3 May 2017 16:58:33 +0000	[thread overview]
Message-ID: <AM4PR0802MB2257120E9ECA545CDA2A4DFEEC160@AM4PR0802MB2257.eurprd08.prod.outlook.com> (raw)

Hi,

With a view to an upcoming change, we have been examining the current Graphics
Output Protocol implementation. Currently for, ARM platforms, the UEFI Graphics
Output Protocol is implemented using a platform specific Library
(PL111LcdArmVExpressLib/HdLcdArmVExpressLib) and a DXE driver
(PL111LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe). The platform specific
library handles platform specific variations such as platform supported display
modes, memory management of the frame buffer, and clock/mux setting. The DXE
driver implements the GOP protocol and manages the respective display IP.
Although this implementation works fine for current platforms, we think the way
the current DXE driver sources are linked is sub-optimal and can be improved to
meet recommendation of the EDKII Module Writer's Guide.

The DXE driver source contains three source files per driver. The files
LcdGraphicsOutputDxe.c and LcdGraphicsOutputBlt.c implement common
functionality whereas HdLcd.c/PL111Lcd.c  implement display IP specific part of
the DXE. The problem is, there are two .inf files for HdLcdGraphicsOutputDxe
and PL111LcdGraphicsOutputDxe and both link common code LcdGraphicsOutputDxe.c
and LcdGraphicsOutputBlt.c with display IP source instead of a library instance
, which seems incorrect and can be improved. We propose to separate HdLcd.c
and PL111Lcd.c and create independent libraries managing only respective
display IP which can then be instantiated as LcdHwLib and linked in a common
LcdGraphicsOutputDxe DXE driver. This will help to clearly partition
implementation of the Graphics Output Protocol into three separate components,
a platform specific component for the display IP, a display IP specific
component and GOP common code.

So instead of the current structure in ArmPlatformPkg for display DXE:

  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcdGraphicsOutputDxe.inf    (HDLCD GOP DXE)
  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111LcdGraphicsOutputDxe.inf    (PL111 GOP DXE)

We propose a structure like:

  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf    (GOP DXE independent of hardware/platform)
  ArmPlatformPkg/Drivers/HdLcd/HdLcd.inf    (Library code managing HDLCD HW IP)
  ArmPlatformPkg/Drivers/PL111/PL11Lcd.inf    (Library code managing PL111 HW IP)

LcdGraphicsOutputDxe.inf will link to LcdPlatformLib and LcdHwLib which can be
selected for the platform in the platform specific .dsc file.

e.g.

Under LibraryClasses we might have:
    LcdPlatformLib|ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
    LcdHwLib|ArmPlatformPkg/Drivers/HdLcd/HdLcd.inf

And Under Components:
    ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf  (Common GOP DXE code for ARM Platforms)

This is a significant change and we would like to invite viewpoints before we
proceed with implementing these. Since the change would only be with respect to
display aspects of ArmPlatformPkg we don't foresee any impact on any other
functionality.

Please reply if you feel this intended change might impact you and why ?
Unless objections are raised, we will soon submit the patches for review.

Regards,
Girish
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


             reply	other threads:[~2017-05-03 16:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03 16:58 Girish Pathak [this message]
2017-05-04 11:14 ` ArmPlatformPkg: LcdGraphicsOutputDxe, PL111, and HdLcd rejig Leif Lindholm
2017-05-04 13:34   ` Ard Biesheuvel
2017-05-04 14:49     ` Evan Lloyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AM4PR0802MB2257120E9ECA545CDA2A4DFEEC160@AM4PR0802MB2257.eurprd08.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox