Re: [edk2] [PATCH] Platform/ARM: Correct LevelID in PLPI packages of DSDT

[Evan Lloyd]

Reviewed-by: Evan Lloyd 

> -Original Message-
> From: AlexeiFedorov 
> Sent: 04 July 2018 14:05
> To: edk2-devel@lists.01.org
> Cc: Arvind Chauhan ; Thomas Abraham
> ; ard.biesheu...@linaro.org;
> leif.lindh...@linaro.org; Matteo Carlini ;
> Stephanie Hughes-Fitt ; nd
> ; Thomas Abraham ; Evan
> Lloyd ; Sami Mujawar 
> Subject: [PATCH] Platform/ARM: Correct LevelID in PLPI packages of DSDT
> 
> From: Alexei Fedorov 
> 
> Juno's DSDT contains 2 PLPI packages in Clusters #0 and #1 and _OSC method
> reports support for platform coordinated mode only.
> According to the description of LevelID field in ACPI 6.2 Errata A 
> Specification
> #8.4.4.3, "In a platform that only supports platform coordinated mode, this
> field must be 0."
> 
> This patch fixes the above issue by changing value of LevelID fields from 1 to
> 0.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Alexei Fedorov 
> ---
> All the changes can be reviewed at:
> https://github.com/AlexeiFedorov/edk2-
> platforms/tree/282_correct_levelid_v1
> 
> Notes:
> v1:
> - Change LevelID Value of PLPI package from 1 to 0.
> 
>  Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl
> b/Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl
> index
> 07e32bae21f891461fde0183028e4c0f817e45a7..702b057757457fee40ddfc10
> e91d38c5dd7ca0b8 100644
> --- a/Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl
> +++ b/Platform/ARM/JunoPkg/AcpiTables/Dsdt.asl
> @@ -1,7 +1,7 @@
>  /** @file
>Differentiated System Description Table Fields (DSDT)
> 
> -  Copyright (c) 2014-2015, ARM Ltd. All rights reserved.
> +  Copyright (c) 2014-2018, ARM Ltd. All rights reserved.
>  This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -65,7 +65,7 @@ DefinitionBlock("DsdtTable.aml", "DSDT", 1,
> "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_O
>})
>Name(PLPI, Package() {
>  0, // Version
> -1, // Level Index
> +0, // Level Index
>  2, // Count
>  Package() { // WFI for CPU
>1, // Min residency (uS)
> @@ -157,7 +157,7 @@ DefinitionBlock("DsdtTable.aml", "DSDT", 1,
> "ARMLTD", "ARM-JUNO", EFI_ACPI_ARM_O
>})
>Name(PLPI, Package() {
>  0, // Version
> -1, // Level Index
> +0, // Level Index
>  2, // Count
>  Package() { // WFI for CPU
>1, // Min residency (uS)
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 3/3] Readme.md: Add instructions to build in a Windows Environment

[Evan Lloyd]

Reviewed-by: Evan Lloyd 

Leif - would it make sense/be acceptable to add a GNU make.exe image to 
edk2-non-osi?

Evan


> -Original Message-
> From: Leif Lindholm 
> Sent: 03 July 2018 11:24
> To: Chris Co 
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel ;
> Michael D Kinney ; Evan Lloyd
> 
> Subject: Re: [PATCH edk2-platforms v2 3/3] Readme.md: Add instructions to
> build in a Windows Environment
>
> Hi Christopher,
>
> Patches 1-2 Reviewed-by: Leif Lindholm  Pushed
> as 5ed298efba..df5cbc93b8 - thanks!
>
> In general, I'm happy enough with the below that I might just push that as
> well, but I will give others a chance to pipe up.
> (Adding Evan to cc.)
>
> I have one comment below.
>
> On Tue, Jul 03, 2018 at 02:29:38AM +, Chris Co wrote:
> > These instructions explain how to setup a Windows build environment
> > with extra instructions to build for ARM platforms using the GCC
> > cross-compiler toolchain.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Christopher Co 
> > Cc: Ard Biesheuvel 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > ---
> >  Readme.md | 249 +++-
> >  1 file changed, 248 insertions(+), 1 deletion(-)
> >
> > diff --git a/Readme.md b/Readme.md
> > index 6ad5953093d6..9916db7f3a1f 100644
> > --- a/Readme.md
> > +++ b/Readme.md
> > @@ -190,8 +190,255 @@ $ ./uefi-tools/edk2-build.sh -b DEBUG -b
> RELEASE
> >
> >  # How To Build (Windows Environment)
> >
> > -(I genuinely have no idea. Please help!)
> > +These instructions will be a summary of the [Windows Systems wiki
> > +entry](https://github.com/tianocore/tianocore.github.io/wiki/Windows-
> systems).
> > +The wiki entry is targeted towards using the Visual Studio compiler.
> > +The instructions below will have some extra steps if you are cross-
> compiling with GCC.
> >
> > +## Prerequisites
> > +You will need Git for Windows and Visual Studio installed to build EDK2
> from source.
> > +If you wish to build the build tools, you will also need Python 2.7
> > +for Windows and cx_Freeze.
> > +
> > +## If cross compiling
> > +If building EDK2 for a different architecture than the build machine,
> > +you need to obtain an appropriate cross-compiler. X64 (x86_64)
> > +compilers also support IA32, but the reverse may not always be true.
> > +
> > +Target architecture | Cross compilation prefix
> > +|-
> > +ARM | arm-eabi-
> > +
> > +### GCC
> > +Linaro provides a Windows-compatible GCC toolchain for
> > +[arm-eabi](https://releases.linaro.org/components/toolchain/binaries/
> > +latest/arm-eabi/) compiled to run on x86_64/i686 Windows.  Select the
> > +i686 mingw32 variant.
> > +
> > +To use the GCC toolchain, you will also need a Windows-compatible GNU
> > +Make.  These instructions will use [MinGW](http://mingw.org/) but any
> > +Windows-compatible GNU Make tool will work.
> > +
> > +## Obtaining source code
>
> Ideally, we would have a single section for this, regardless of build 
> platform.
> You're adding info about submodule handling here that we'd otherwise need
> to duplicate to the Linux section, and keep in sync.
>
> /
> Leif
>
> > +1. Create a new folder (directory) on your local development machine
> > +   for use as your workspace. This example uses `C:\git\tianocore`, modify
> as
> > +   appropriate for your needs.
> > +
> > +1. In a Windows command prompt:
> > +   ```
> > +   > set WORKSPACE=C:\git\tianocore
> > +   > mkdir %WORKSPACE%
> > +   > cd %WORKSPACE%
> > +   ```
> > +
> > +1. Into that folder, clone:
> > +   1. [edk2](https://github.com/tianocore/edk2)
> > +   1. [edk2-platforms](https://github.com/tianocore/edk2-platforms)
> > +   1. [edk2-non-osi](https://github.com/tianocore/edk2-non-osi) (if
> building
> > +  platforms that need it)
> > +   ```
> > +   > git clone https://github.com/tianocore/edk2.git
> > +   ...
> > +   > git clone https://github.com/tianocore/edk2-platforms.git
> > +   ...
> > +   > git clone https://github.com/tianocore/edk2-non-osi.git
> > +   ```
> > +
> > +1. Clone submodules
> > +   ```
> > +   > pushd edk2
> > +   > git submodule update --init --recursive
> > +   > popd
> > +   ```
> > +
> > +1. Set up a **PACKAGES_PATH** to point to the locations of these three
> > +   repositories.
> > +
> > +   Note: o

Re: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight calculation methods

[Evan Lloyd]

Hi Tomas
I'm not a maintainer here, so my comments are just that and carry no weight 
beyond making suggestions that you may wish to consider.

> -Original Message-
> From: edk2-devel  On Behalf Of Tomas
> Pilar (tpilar)
> Sent: 29 June 2018 10:42
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] MdePkg/BaseLib: Add bit field Hamming weight
> calculation methods
>
> Add 32-bit and 64-bit functions that count number of set bits in a bitfield
> using the divide-and-count method.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Tomas Pilar 
> ---
>  MdePkg/Include/Library/BaseLib.h  | 56 +++
> MdePkg/Library/BaseLib/BitField.c | 79
> +++
>  2 files changed, 135 insertions(+)
>
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 1db3a04..7eb0488 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -4609,6 +4609,62 @@ BitFieldAndThenOr64 (
>IN  UINT64OrData
>);
>
> +/**
> +  Reads a bit field from a 32-bit value, counts and returns
> +  the number of set bits.
> +
> +  Counts the number of set bits in the  bit field specified by
> + StartBit and EndBit in Operand. The count is returned.
> +
> +  If StartBit is greater than 31, then ASSERT().
> +  If EndBit is greater than 31, then ASSERT().
> +  If EndBit is less than StartBit, then ASSERT().
> +
> +  @param  Operand   Operand on which to perform the bitfield operation.
> +  @param  StartBit  The ordinal of the least significant bit in the bit 
> field.
> +Range 0..31.
> +  @param  EndBitThe ordinal of the most significant bit in the bit field.
> +Range 0..31.
> +
> +  @return The number of bits set between StartBit and EndBit.
> +
> +**/
> +UINT8
> +EFIAPI
> +BitFieldHammingWeight32 (
> +  IN   UINT32   Operand,
> +  IN   UINTNStartBit,
> +  IN   UINTNEndBit
> +  );
> +

 [[Evan Lloyd]] I can see the benefit of a "CountOnes" function, but why not 
call it that (or similar)?  (I had to look up "HammingWeight")
Also, why conflate BitField access and CountOnes in one function?  A "pure" 
function to count ones might be used in other ways, and it is fairly clear if 
you write:
CountOnes(BitFieldRead64 (Operand, StartBit, EndBit));


> +/**
> +   Reads a bit field from a 64-bit value, counts and returns
> +   the number of set bits.
> +
> +   Counts the number of set bits in the  bit field specified by
> +   StartBit and EndBit in Operand. The count is returned.
> +
> +   If StartBit is greater than 63, then ASSERT().
> +   If EndBit is greater than 63, then ASSERT().
> +   If EndBit is less than StartBit, then ASSERT().
> +
> +   @param  Operand   Operand on which to perform the bitfield operation.
> +   @param  StartBit  The ordinal of the least significant bit in the bit 
> field.
> +   Range 0..63.
> +   @param  EndBitThe ordinal of the most significant bit in the bit 
> field.
> +   Range 0..63.
> +
> +   @return The number of bits set between StartBit and EndBit.
> +
> +**/
> +UINT8
> +EFIAPI
> +BitFieldHammingWeight64 (
> +  IN   UINT64   Operand,
> +  IN   UINTNStartBit,
> +  IN   UINTNEndBit
> +  );
> +
>  //
>  // Base Library Checksum Functions
>  //
> diff --git a/MdePkg/Library/BaseLib/BitField.c
> b/MdePkg/Library/BaseLib/BitField.c
> index d2d3150..af06db8 100644
> --- a/MdePkg/Library/BaseLib/BitField.c
> +++ b/MdePkg/Library/BaseLib/BitField.c
> @@ -920,3 +920,82 @@ BitFieldAndThenOr64 (
> OrData
> );
>  }
> +
> +/**
> +  Reads a bit field from a 32-bit value, counts and returns
> +  the number of set bits.
> +
> +  Counts the number of set bits in the  bit field specified by
> + StartBit and EndBit in Operand. The count is returned.
> +
> +  If StartBit is greater than 31, then ASSERT().

 [[Evan Lloyd]] This ASSERT is not in the code and is redundant given the next 
two.

> +  If EndBit is greater than 31, then ASSERT().
> +  If EndBit is less than StartBit, then ASSERT().
> +
> +  @param  Operand   Operand on which to perform the bitfield operation.
> +  @param  StartBit  The ordinal of the least significant bit in the bit 
> field.
> +Range 0..31.
> +  @param  EndBitThe ordinal of the most significant bit in the bit field.
> +Range 0..31.
> +
> +  @return The number of bits set between Sta

Re: [edk2] [PATCH edk2-platforms v1 0/6][platforms/devel-dynamictables] Fix issues reported by ecc tool

[Evan Lloyd]

> -Original Message-
> From: edk2-devel  On Behalf Of Evan
> Lloyd
> Sent: 27 June 2018 17:58
> To: Sami Mujawar ; edk2-devel@lists.01.org
> Cc: Arvind Chauhan ; Stephanie Hughes-Fitt
> ; nd 
> Subject: Re: [edk2] [PATCH edk2-platforms v1 0/6][platforms/devel-
> dynamictables] Fix issues reported by ecc tool
> 
> 
> Signed-off-by: Evan Lloyd 

 [[Evan Lloyd]] Oops, copy pasted wrong line, sorry.
Reviewed-by: Evan Lloyd 

> 
> > -Original Message-
> > From: Sami Mujawar 
> > Sent: 27 June 2018 17:49
> > To: edk2-devel@lists.01.org
> > Cc: Arvind Chauhan ; Daniil Egranov
> > ; Thomas Abraham
> ;
> > leif.lindh...@linaro.org; Evan Lloyd ; Matteo
> > Carlini ; Stephanie Hughes-Fitt
> > ; nd 
> > Subject: [PATCH edk2-platforms v1 0/6][platforms/devel-dynamictables]
> > Fix issues reported by ecc tool
> >
> > This patch series fixes the issues reported by the ecc tool.
> >
> > The changes can be seen at https://github.com/samimujawar/edk2-
> > platforms/tree/290_fix_ecc_issues_v1
> >
> > Sami Mujawar (6):
> >   Platform/ARM: FVP: Add module info to file header
> >   Platform/ARM: FVP: Fix function documentation
> >   Platform/ARM: FVP: Fix variable declaration
> >   Platform/ARM: Juno: Add module info to file header
> >   Platform/ARM: Juno: Fix function documentation
> >   Platform/ARM: Juno: Fix variable declaration
> >
> >
> >
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.i
> > nc|  3 +-
> >
> >
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/C
> > onfigurationManager.c  | 86 +-
> >
> >
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/C
> > onfigurationManagerDxe.inf |  1 +
> >
> >
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Platfo
> > rmASLTablesLib.inf   |  1 +
> >
> >
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager.d
> > sc.inc|  3 +-
> >
> >
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerD
> > xe/ConfigurationManager.c  | 93 ++--
> >
> >
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerD
> > xe/ConfigurationManagerDxe.inf |  1 +
> >
> >
> Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/Pl
> > atformASLTablesLib.inf   |  1 +
> >  8 files changed, 101 insertions(+), 88 deletions(-)
> >
> > --
> > 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> >
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] EDK II stable tag releases

[Evan Lloyd]

> -Original Message-
> From: edk2-devel  On Behalf Of Laszlo
> Ersek
> Sent: 25 June 2018 16:23
> To: Kinney, Michael D ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] [RFC] EDK II stable tag releases
>
> On 06/25/18 01:07, Kinney, Michael D wrote:
> > Hello,
> >
> > This is a proposal for periodic stable tags on edk2 repositories.
> >
> > The goal is to produce a stable tag for edk2 repositories every 3
> > months with the initial proposed dates of 8/10/2018 and 11/16/2018.
> > Each release is preceded by a 2 week quiet period where only commits
> > for critical bug fixes are accepted.
> >
> > When the stable tag release is completed, the release is tagged with
> > the following naming convention:
> >
> > edk2-stable<4 digit year><2 digit month>
> >
> > For example, the first 2 proposed tags would be:
> >
> > edk2-stable201808
> > edk2-stable201811
> >
> > The goal is to integrate major feature at the beginning of each 3
> > month release cycle.  Work through integration issues, smaller
> > features, and normal bug fixes through the remainder of the release
> > cycle until the start of the quiet period.  The community focuses on
> > testing and critical bug fixes during the quiet period.
> >
> > An EDK II Wiki page will be created to plan the development and
> > testing activities along with the dates associated for future EDK II
> > stable tag releases.
> >
> > Please provide any feedback you have on this proposal.
>
> I welcome it. :)
>
> Thanks!
> Laszlo

 [[Evan Lloyd]] I too think this is a good idea.

> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths to fix comparison

[Evan Lloyd]

Hi Chris.

> -Original Message-
> From: Chris Co 
> Sent: 27 June 2018 21:03
> To: Evan Lloyd ; edk2-devel@lists.01.org; Liming Gao
> 
> Cc: Leif Lindholm ; Sami Mujawar
> 
> Subject: RE: [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths to fix
> comparison
>
> > -Original Message-
> > From: Chris Co
> > Sent: Wednesday, June 27, 2018 11:23 AM
> > To: 'Evan Lloyd' ; 'edk2-devel@lists.01.org'
> > ; 'Liming Gao' 
> > Cc: 'Leif Lindholm' ; Sami Mujawar
> > 
> > Subject: RE: [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths to
> > fix comparison
> >
> > Forgot to add that I'll try out the os.path.normpath/normcase to see
> > if this will work.
> >
>
> Just tried out os.path.normpath and os.path.normcase and together, these
> calls do achieve the desired result.
>
> Initial filepath string =
> "e:\\rebase\\Build\\HUMMINGBOARD_EDGE_IMX6Q_2GB\\RELEASE_GCC49
> xASL\\ARM\\Platform\\SolidRun\\HUMMINGBOARD_EDGE_IMX6Q_2GB\\Ac
> piTables\\AcpiTables\\OUTPUT\\.\\DSDT.i"
> After normpath =
> "e:\rebase\Build\HUMMINGBOARD_EDGE_IMX6Q_2GB\RELEASE_GCC49xAS
> L\ARM\Platform\SolidRun\HUMMINGBOARD_EDGE_IMX6Q_2GB\AcpiTables
> \AcpiTables\OUTPUT\DSDT.i"
> After normcase =
> "e:\rebase\build\hummingboard_edge_imx6q_2gb\release_gcc49xasl\arm\
> platform\solidrun\hummingboard_edge_imx6q_2gb\acpitables\acpitables\o
> utput\dsdt.i"
>
> I would prefer to use the os module instead of my direct string manipulation
> approach so let me know if this change is acceptable and I can submit a v2
> using these functions instead.

 [[Evan Lloyd]] This is not my call but, as Leif asked me to stick my oar in, 
I'll say that I think it would be very acceptable.
Of course, the guy to convince is Liming.

Thank you, again.  (Are you getting the idea I'm pleased with this?)
Evan

>
> > > -Original Message-
> > > From: Chris Co
> > > Sent: Wednesday, June 27, 2018 11:13 AM
> > > To: 'Evan Lloyd' ; edk2-devel@lists.01.org;
> > > Liming Gao 
> > > Cc: Leif Lindholm ; Sami Mujawar
> > > 
> > > Subject: RE: [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths
> > > to fix comparison
> > >
> > > Hi Liming, Evan,
> > >
> > > I have attached an example of a generated DSDT.iii file which gets
> > > processed using Trim.  It will give us a concrete example of what
> > > these
> > changes do.
> > >
> > > The first line has its #line directive stripped and the filepath
> > > saved as the PreProcessedFile.  In GCC49, the filepath was:
> > >
> >
> "e:\\rebase\\Build\\HUMMINGBOARD_EDGE_IMX6Q_2GB\\RELEASE_GCC4
> > >
> >
> 9xASL\\ARM\\Platform\\SolidRun\\HUMMINGBOARD_EDGE_IMX6Q_2GB\\
> > > AcpiTables\\AcpiTables\\OUTPUT\\.\\DSDT.i"
> > >
> > > while in GCC5+ it is:
> > >
> >
> "e:\\rebase\\build\\hummingboard_edge_imx6q_2gb\\release_gcc5\\arm\
> > >
> >
> \platform\\solidrun\\hummingboard_edge_imx6q_2gb\\acpitables\\acpitab
> > > les\\output\\dsdt.i"
> > >
> > > So there is a difference in both lowercase as well as \\.\\ before dsdt.i.
> > >
> > > As the Trim function goes through each line, it strips the #line
> > > directive and saves the filepath as InjectedFile, which is then
> > > compared against PreProcessedFile
> > >
> >
> (https://github.com/tianocore/edk2/blob/975478f6bb22668efae311eb3f740
> > > 6e1f18411c2/BaseTools/Source/Python/Trim/Trim.py#L174)
> > > If it is not a match, skip to next line.  When using GCC5+,
> > > DSDT.iii's #line directives after the first keeps the old GCC49
> > > filepath syntax so the string comparison always fails.  An example
> > > of a line which should match line 602 in DSDT.iii.
> > >
> > > So my changes target these two cases directly, but admittedly I'm
> > > more of a kernel dev than a python dev so if there is a better way
> > > to address this, I'm all for it.
> > >
> > > > -Original Message-
> > > > From: Evan Lloyd 
> > > > Sent: Wednesday, June 27, 2018 4:35 AM
> > > > To: Chris Co ;
> > > > edk2-devel@lists.01.org
> > > > Cc: Liming Gao ; Leif Lindholm
> > > > ; Sami Mujawar 
> > > > Subject: RE: [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths
> > > > to fix comparison
> > > >
> > > > Hi Chris.
> > > > Firstly, thank you: this is a useful, pragmatic solution to an
> > > >

Re: [edk2] [PATCH edk2-platforms v1 0/6][platforms/devel-dynamictables] Fix issues reported by ecc tool

[Evan Lloyd]

Signed-off-by: Evan Lloyd 

> -Original Message-
> From: Sami Mujawar 
> Sent: 27 June 2018 17:49
> To: edk2-devel@lists.01.org
> Cc: Arvind Chauhan ; Daniil Egranov
> ; Thomas Abraham
> ; leif.lindh...@linaro.org; Evan Lloyd
> ; Matteo Carlini ;
> Stephanie Hughes-Fitt ; nd
> 
> Subject: [PATCH edk2-platforms v1 0/6][platforms/devel-dynamictables] Fix
> issues reported by ecc tool
> 
> This patch series fixes the issues reported by the ecc tool.
> 
> The changes can be seen at https://github.com/samimujawar/edk2-
> platforms/tree/290_fix_ecc_issues_v1
> 
> Sami Mujawar (6):
>   Platform/ARM: FVP: Add module info to file header
>   Platform/ARM: FVP: Fix function documentation
>   Platform/ARM: FVP: Fix variable declaration
>   Platform/ARM: Juno: Add module info to file header
>   Platform/ARM: Juno: Fix function documentation
>   Platform/ARM: Juno: Fix variable declaration
> 
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.i
> nc|  3 +-
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/C
> onfigurationManager.c  | 86 +-
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/C
> onfigurationManagerDxe.inf |  1 +
> 
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Platfo
> rmASLTablesLib.inf   |  1 +
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager.d
> sc.inc|  3 +-
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerD
> xe/ConfigurationManager.c  | 93 ++--
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerD
> xe/ConfigurationManagerDxe.inf |  1 +
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/Pl
> atformASLTablesLib.inf   |  1 +
>  8 files changed, 101 insertions(+), 88 deletions(-)
> 
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [staging/dynamictables PATCH v1 0/5] Fix issues reported by ecc tool

[Evan Lloyd]

Signed-off-by: Evan Lloyd 

> -Original Message-
> From: Sami Mujawar 
> Sent: 27 June 2018 17:48
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; Evan Lloyd ; Matteo
> Carlini ; Stephanie Hughes-Fitt
> ; nd 
> Subject: [staging/dynamictables PATCH v1 0/5] Fix issues reported by ecc tool
> 
> This patch series fixes the issues reported by the ecc tool.
> 
> The changes can be seen at https://github.com/samimujawar/edk2-
> staging/tree/290_fix_ecc_issues_v1
> 
> Sami Mujawar (5):
>   DynamicTablesPkg: Add module info to file header
>   DynamicTablesPkg: Fix function documentation
>   DynamicTablesPkg: Fix variable naming issue
>   DynamicTablesPkg: Fix macro to prevent side effect
>   DynamicTablesPkg: Fix variable declaration
> 
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/AcpiTableFactory/Acpi
> TableFactory.c |   6 +-
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DeviceTreeTableFactor
> y/DeviceTreeTableFactory.c |   6 +-
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactory.
> h   |   6 +-
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryD
> xe.c|   2 +-
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryD
> xe.inf  |   1 +
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/SmbiosTableFactory/S
> mbiosTableFactory.c |   6 +-
> 
> DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManag
> erDxe.c|  59 +++---
> 
> DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManag
> erDxe.inf  |   1 +
>  DynamicTablesPkg/DynamicTablesPkg.dec
>|
> 5 +-
>  DynamicTablesPkg/Include/AcpiTableGenerator.h
> |  30 +--
>  DynamicTablesPkg/Include/ConfigurationManagerHelper.h
> |   2 +-
>  DynamicTablesPkg/Include/ConfigurationManagerObject.h
> |  12 +-
>  DynamicTablesPkg/Include/DeviceTreeTableGenerator.h
> |  24 +--
>  DynamicTablesPkg/Include/Library/TableHelperLib.h
> |   6 +-
>  DynamicTablesPkg/Include/Protocol/ConfigurationManagerProtocol.h
> |   4 +-
>  DynamicTablesPkg/Include/Protocol/DynamicTableFactoryProtocol.h
> |   6 +-
>  DynamicTablesPkg/Include/SmbiosTableGenerator.h
> |  24 +--
>  DynamicTablesPkg/Include/StandardNameSpaceObjects.h
> |   2 +-
>  DynamicTablesPkg/Include/TableGenerator.h
> |  32 ++--
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiDbg2LibArm/Dbg2Generator.c
> |  16 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/AcpiFadtLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/FadtGenerator.c
> |  20 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/AcpiGtdtLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
> |  38 ++--
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/AcpiIortLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
> | 194 ++--
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c
> |  32 ++--
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/McfgGenerator.c
> |  16 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/AcpiRawLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/RawGenerator.c
> |  13 +-
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.inf
> |   1 +
>  DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/SpcrGenerator.c
> |  12 +-
>  DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
> |   4 +-
>  DynamicTablesPkg/Library/Common/TableHelperLib/TableHelperLib.inf
> |   1 +
>  37 files changed, 316 insertions(+), 272 deletions(-)
> 
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths to fix comparison

[Evan Lloyd]

Hi Chris.
Firstly, thank you: this is a useful, pragmatic solution to an major annoyance.
I personally think it unfortunate that the GCC guys can't be bothered to fix 
their compiler, but ...

> -Original Message-
> From: edk2-devel  On Behalf Of Chris Co
> Sent: 27 June 2018 04:58
> To: edk2-devel@lists.01.org
> Cc: Liming Gao 
> Subject: [edk2] [PATCH v1 1/1] BaseTools/Trim: Canonicalize filepaths to fix
> comparison
>
> When using Linaro GCC5+ arm-eabi toolchain on Windows, the generated
> DSDT.iii contains a canonicalized ("\.\" removed and lower case) filepath for
> the preprocessed DSDT.i file in the first line.
> Due to this, when Trim.exe is called to generate DSDT., future filepath
> comparisons against this canonicalized filepath, which should match, actually
> fail the comparison which results in an empty DSDT..
>
> Issue was first reported to Linaro here:
> https://bugs.linaro.org/show_bug.cgi?id=2909
> where the recommendation was to address the issue in Trim.exe.
>
> This patch canonicalizes and lower cases all file paths encountered during
> trim execution on preprocessed files.  Since file paths are standarized, the
> comparison succeeds for files that should match regardless of the presence
> of upper case or "\.\" characters in the file path.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Christopher Co 
> Cc: Leif Lindholm 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> ---
>  BaseTools/Source/Python/Trim/Trim.py | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/BaseTools/Source/Python/Trim/Trim.py
> b/BaseTools/Source/Python/Trim/Trim.py
> index a74075859148..cca4e5c9694a 100644
> --- a/BaseTools/Source/Python/Trim/Trim.py
> +++ b/BaseTools/Source/Python/Trim/Trim.py
> @@ -166,6 +166,8 @@ def TrimPreprocessedFile(Source, Target, ConvertHex,
> TrimLong):
>  if len(MatchList) == 2:
>  LineNumber = int(MatchList[0], 0)
>  InjectedFile = MatchList[1]
> +InjectedFile = InjectedFile.replace("\\.\\","")

[[Evan Lloyd]] I've not actually tried this yet, but it looks surprizing.  I'd 
have expected InjectedFile.replace("\\.\\","\\").
  Can I ask how it works, please?  Have I missed something?
[[Evan Lloyd]] Would it be possible to achieve the same effect with 
os.path.normpath (see Common/LongFilePathOsPath.py imported via line 17)?

> +InjectedFile = InjectedFile.lower()
[[Evan Lloyd]] Similarly, there is "os.path.normcase" - but that may not get 
the comparison working (because it converts '/' to '\' on Windows).

>  # The first injetcted file must be the preprocessed file 
> itself
>  if PreprocessedFile == "":
>  PreprocessedFile = InjectedFile
> --
> 2.16.2.gvfs.1.33.gf5370f1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] MdeModulePkg: Enable SATA Controller PCI mem space

[Evan Lloyd]

Hi Laszlo, Star.
Looking at the e-mail thread, I think I also made the mistake of getting Star's 
name inverted.
I'm sorry, especially as in this case it is not as unclear as some Chinese 
names can be for foreigners.  I can only put this one down to approaching 
senility.
 Sorry, Star - I'll try not to do it again.

Evan

> -Original Message-
> From: edk2-devel  On Behalf Of Laszlo
> Ersek
> Sent: 18 June 2018 16:52
> To: Sami Mujawar ; edk2-devel@lists.01.org
> Cc: ruiyu...@intel.com; Stephanie Hughes-Fitt  f...@arm.com>; eric.d...@intel.com; ard.biesheu...@linaro.org;
> leif.lindh...@linaro.org; nd ; star.z...@intel.com
> Subject: Re: [edk2] [PATCH v2] MdeModulePkg: Enable SATA Controller PCI
> mem space
> 
> off-topic:
> 
> On 06/15/18 16:13, Sami Mujawar wrote:
> > - Enable IO space, suggestion to use EFI_PCI_DEVICE_ENABLE[ZENG]
> 
> My understanding is that "Star" is Star's given name, and "Zeng" is his
> surname. Let's not start calling each other by surname, shall we?
> 
> (Email addresses under @intel.com seem to follow the "given-
> name.surname" or "given-name.middle-initial.surname" pattern.)
> 
> Thanks,
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] MdeModulePkg: Enable SATA Controller PCI mem space

[Evan Lloyd]

Hi Ard, Zeng

> -Original Message-
> From: Ard Biesheuvel 
> Sent: 15 June 2018 15:17
> To: Sami Mujawar 
> Cc: edk2-devel@lists.01.org; Zeng, Star ; Eric Dong
> ; Ruiyu Ni ; Leif Lindholm
> ; Matteo Carlini ;
> Stephanie Hughes-Fitt ; Evan Lloyd
> ; Thomas Abraham ;
> nd 
> Subject: Re: [PATCH v2] MdeModulePkg: Enable SATA Controller PCI mem
> space
> 
> On 15 June 2018 at 16:13, Sami Mujawar  wrote:
> > The SATA controller driver crashes while accessing the PCI memory
> > [AHCI Base Registers (ABAR)], as the PCI memory space is not enabled.
> >
> > Enable the PCI memory space access to prevent the SATA Controller
> > driver from crashing.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Sami Mujawar 
> > ---
> > The changes can be viewed at
> >
> https://github.com/samimujawar/edk2/tree/284_sata_controler_pci_mem_f
> i
> > x_v2
> >
> > Notes:
> > v2:
> > - Improved log message and code documentation based on feedback
> [SAMI]
> > - Enable IO space, suggestion to use EFI_PCI_DEVICE_ENABLE[ZENG]
> > - This SATA Controller driver only uses the PCI BAR5 register
> >   space which is the AHCI Base Address (ABAR). According to the
> >   'Serial ATA Advanced Host Controller Interface (AHCI) 1.3.1'
> >   specification, section 2.1.11, 'This register allocates space
> >   for the HBA memory registers'.
> >   The section 2.1.10, allows provision for Optional BARs which
> >   may support either memory or I/O spaces. However, in the context
> >   of the current SATA controller driver, which only ever access
> >   the ABAR, enabling I/O memory space is not required.[SAMI]
> > - Prefer to use // surrounding comments   [ZENG]
> > - Doing this would violate the edk2 coding standard. See EDK2
> >   Coding Standard Specification, revision 2.20, section 6.2.3.[SAMI]
> >
> 
> Please stop obsessing about the coding standard. The maintainer was quite
> clear what he wanted, and in the past, I have also indicated that for the ARM
> related packages, I prefer readability and consistency over adherence to a
> dubious standard.

[[Evan Lloyd]] I'd like to make some points here:
1.  It is perfectly reasonable for Sami to explain why he has done 
something a certain way - Zeng is then at liberty to respond with his 
preference, but we do not (yet) know what that might be.  

2.  "readability and consistency" is the very purpose of any coding 
standard.  If consistency is valuable, doesn't that apply across modules?  I 
understand that it may be particularly valuable for maintainers within their 
modules, but the rest of us benefit from a consistent style - especially when 
looking outside our normal demesne.

3.  Applying a consistent Coding Standard across the whole project is a 
necessary pre-condition for automated CI checks on new submissions.  I'd like 
to aim e.g. for an improved patchcheck.py, but that requires consistency across 
modules, at least for new code.

Note: I am not disputing the dubiosity of the  CCS.  It could be improved (a 
lot).  However it is all we have right now.

Regards,
Evan

> 
> 
> > v1:
> > - Fix SATA Controller driver crash[SAMI]
...
> > --
> > 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> >
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1] MdeModulePkg: Enable SATA Controller PCI mem space

[Evan Lloyd]

Reviewed-by: Evan Lloyd 

> -Original Message-
> From: Sami Mujawar 
> Sent: 14 June 2018 12:38
> To: edk2-devel@lists.01.org
> Cc: star.z...@intel.com; eric.d...@intel.com; ruiyu...@intel.com;
> ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Matteo Carlini
> ; Stephanie Hughes-Fitt  f...@arm.com>; Evan Lloyd ; Thomas Abraham
> ; nd 
> Subject: [PATCH v1] MdeModulePkg: Enable SATA Controller PCI mem space
> 
> The SATA controller driver crashes while accessing the PCI memory, as the
> PCI memory space is not enabled.
> 
> Enable the PCI memory space access to prevent the SATA Controller driver
> from crashing.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar 
> ---
> The changes can be seen at
> https://github.com/samimujawar/edk2/tree/284_sata_controler_pci_mem_f
> ix_v1
> 
> Notes:
> v1:
> - Fix SATA Controller driver crash[SAMI]
> 
>  MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c | 80
> +++-
> MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.h |  7 ++
>  2 files changed, 86 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
> b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
> index
> a6d55c15571728eb3fd572003f383ba7c86635ae..21cc101d693f5adfd9d43f0c2
> 1a096eb59ba73b1 100644
> --- a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
> +++ b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
> @@ -2,6 +2,7 @@
>This driver module produces IDE_CONTROLLER_INIT protocol for Sata
> Controllers.
> 
>Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2018, ARM Ltd. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -364,6 +365,7 @@ SataControllerStart (
>EFI_SATA_CONTROLLER_PRIVATE_DATA  *Private;
>UINT32Data32;
>UINTN TotalCount;
> +  UINT64PciAttributes;
> 
>DEBUG ((EFI_D_INFO, "SataControllerStart start\n"));
> 
> @@ -406,6 +408,61 @@ SataControllerStart (
>Private->IdeInit.CalculateMode  = IdeInitCalculateMode;
>Private->IdeInit.SetTiming  = IdeInitSetTiming;
>Private->IdeInit.EnumAll= SATA_ENUMER_ALL;
> +  Private->PciAttributesChanged   = FALSE;
> +
> +  // Save original PCI attributes
> +  Status = PciIo->Attributes (
> +PciIo,
> +EfiPciIoAttributeOperationGet,
> +0,
> +>OriginalPciAttributes
> +);
> +  if (EFI_ERROR (Status)) {
> +  goto Done;
> +  }
> +
> +  DEBUG ((
> +EFI_D_INFO,
> +"PCI Attributes = 0x%llx\n",
> +Private->OriginalPciAttributes
> +));
> +
> +  if ((Private->OriginalPciAttributes & EFI_PCI_IO_ATTRIBUTE_MEMORY) == 0)
> {
> +Status = PciIo->Attributes (
> +  PciIo,
> +  EfiPciIoAttributeOperationSupported,
> +  0,
> +  
> +  );
> +if (EFI_ERROR (Status)) {
> +  goto Done;
> +}
> +
> +DEBUG ((EFI_D_INFO, "Supported PCI Attributes = 0x%llx\n",
> + PciAttributes));
> +
> +if ((PciAttributes & EFI_PCI_IO_ATTRIBUTE_MEMORY) == 0) {
> +  DEBUG ((
> +EFI_D_ERROR,
> +"Error: EFI_PCI_IO_ATTRIBUTE_MEMORY not supported\n"
> +));
> +  Status = EFI_UNSUPPORTED;
> +  goto Done;
> +}
> +
> +PciAttributes = Private->OriginalPciAttributes |
> + EFI_PCI_IO_ATTRIBUTE_MEMORY;
> +
> +DEBUG ((EFI_D_INFO, "Enable PCI Attributes = 0x%llx\n", PciAttributes));
> +Status = PciIo->Attributes (
> +  PciIo,
> +  EfiPciIoAttributeOperationEnable,
> +  PciAttributes,
> +  NULL
> +  );
> +if (EFI_ERROR (Status)) {
> +  goto Done;
> +}
> +Private->PciAttributesChanged = TRUE;  }
> 
>Status = PciIo->Pci.Read (
>  PciIo,
> @@ -414,7 +471,10 @@ SataControllerStart (
>  sizeof (PciData.Hdr.ClassCode),
>  PciData.Hdr.ClassCode
>  );
> -  ASSERT_EFI_ERROR (Status);
> +  if (EFI_ER

Re: [edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-dynamictables] Update for ACPICA compiler enhancements

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

Leif, Ard - are you happy to accept this for the patchset, or should I respond 
to each patch?

Regards,
Evan

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Sami
> Mujawar
> Sent: 18 May 2018 14:13
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Arvind Chauhan <arvind.chau...@arm.com>;
> ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Stephanie Hughes-Fitt
> <stephanie.hughes-f...@arm.com>
> Subject: [edk2] [PATCH edk2-platforms v2 0/3][platforms/devel-
> dynamictables] Update for ACPICA compiler enhancements
> 
> The ACPICA iAsl compiler has recently been enhanced to support a feature
> required by Dynamic Tables Framework for processing ASL files. The
> compiler however generates slightly different symbol names to what was
> previously referenced in the Configuration Manager.
> 
> This patchset adapts to the latest iASL compiler options.
> 
> The changes can be seen at
> https://github.com/samimujawar/edk2-
> platforms/tree/258_reflect_acpica_compiler_enhancement_v2
> 
> Sami Mujawar (3):
>   Platform/ARM: Match asl compiler output for Juno
>   Platform/ARM: Match asl compiler output for FVP
>   Update Readme.md to reflect ACPICA compiler update
> 
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/C
> onfigurationManager.c |  8 +++
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManagerD
> xe/ConfigurationManager.c |  2 +-
>  Readme.md
> | 25
> +---
>  3 files changed, 21 insertions(+), 14 deletions(-)
> 
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [staging/dynamictables PATCH v2] Update Readme.md to reflect ACPICA compiler update

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: Sami Mujawar <sami.muja...@arm.com>
> Sent: 18 May 2018 12:09
> To: edk2-devel@lists.01.org
> Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Matteo Carlini
> <matteo.carl...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; nd <n...@arm.com>; Evan Lloyd <evan.ll...@arm.com>
> Subject: [staging/dynamictables PATCH v2] Update Readme.md to reflect
> ACPICA compiler update
> 
> The ACPICA iASL compiler has been enhanced to support the generation of
> an AML hex file which is required by the Dynamic Tables Framework. The
> patch for this enhancement has been integrated in the ACPICA repository.
> Therefore the Prerequisites section in the Readme has been updated
> accordingly.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> ---
> 
> The changes can be seen at https://github.com/samimujawar/edk2-
> staging/tree/258_reflect_acpica_compiler_enhancement_v2
> 
> Notes:
> v2:
> - Add patch commit date and info about presentation.  [LEIF]
> - Updated Readme.md to add date for referencing ACPICA patch.
>   Also annotated the UEFI presentation.   [SAMI]
> 
> v1:
> - Update ACPICA iAsl compiler usage guidelines.   [SAMI]
> 
>  Readme.md | 25 +---
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/Readme.md b/Readme.md
> index
> b72efca18e8ab5de17cab06f0a1a0725991256d4..6501623503d6ec8ef4840aeb
> c70561d44cf1ca12 100644
> --- a/Readme.md
> +++ b/Readme.md
> @@ -87,9 +87,9 @@ contains the Dynamic Tables Framework.
>  ### ACPICA iASL compiler
>  The RAW table generator, used to process the DSDT/SSDT files depends on
> the iASL compiler to convert the DSDT/SSDT ASL files to a C array containing -
> the hex AML code. The current implementation of the iASL compiler does not
> -support generation of a C header file suitable for including from a C source 
> -
> file.
> +the hex AML code. The "-tc" option of the iASL compiler has been
> +enhanced to support generation of an AML hex file (C header) with a
> +unique symbol name so that it is suitable for inclusion from a C source file.
> 
>  Related Links
>  --
> @@ -135,16 +135,23 @@ or
> 
>  Prerequisites
>  -
> -ACPICA iASL compiler with support for generating a C header file.
> +ACPICA iASL compiler with the enhanced "-tc" option to support
> +generation of AML hex (C header) files with unique symbol names.
> 
> -A patch ***'Modify hex AML C header file generation'***, to enable -this
> support has been submitted to the ACPICA source repository.
> -<https://lists.acpica.org/pipermail/devel/2018-March/001755.html>
> +A patch *'[iASL: Enhance the -tc option (create AML hex file in
> +C)](https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63
> b29626852a0b5f37)'*, dated 16 March 2018 (2018-03-16), to enable this
> support has been integrated to the ACPICA source repository.
> +
> +Ensure that the iASL compiler used for building *Dynamic Tables
> Framework* has this feature enabled.
> +
> +This feature was made available in the *ACPICA Compiler update [Version
> +20180508](https://www.acpica.org/node/156)*, dated 8 May 2018 (2018-
> 05-08).
> 
>  Documentation
>  -
> -A description document is in preparation, and should be available in the -
> near future.
> +
> +Refer to the following presentation from *UEFI Plugfest Seattle 2018*:
> +
> +[Dynamic Tables Framework: A Step Towards Automatic Generation of
> +Advanced Configuration and Power Interface (ACPI) & System Management
> +BIOS (SMBIOS) Tables – Sami Mujawar
> +(Arm).](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic%2
> +0Tables%20Framework%20A%20Step%20Towards%20Automatic%20Gener
> ation%20of%
> +20Advanced%20Configuration%20and%20Power%20Interface%20%28ACPI
> %29%20%26
> +%20System%20Management%20BIOS%20%28SMBIOS%29%20Tables%20_0.
> pdf)
> 
>  Miscellaneous
>  -
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v1 3/3][platforms/devel-dynamictables] Update Readme.md to reflect ACPICA compiler update

[Evan Lloyd]

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Leif
> Lindholm
> Sent: 09 May 2018 12:04
> To: Sami Mujawar <sami.muja...@arm.com>
> Cc: nd <n...@arm.com>; Arvind Chauhan <arvind.chau...@arm.com>;
> ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Stephanie Hughes-Fitt
> <stephanie.hughes-f...@arm.com>
> Subject: Re: [edk2] [PATCH edk2-platforms v1 3/3][platforms/devel-
> dynamictables] Update Readme.md to reflect ACPICA compiler update
>
...
> > -A patch ***'Modify hex AML C header file generation'***, to enable
> > -this support has been submitted to the ACPICA source repository.
> > -<https://lists.acpica.org/pipermail/devel/2018-March/001755.html>
> > +A patch ***'[iASL: Enhance the -tc option (create AML hex file in
> >
> +C)](https://github.com/acpica/acpica/commit/f9a88a4c1cd020b6a5475d63
> b
> > +29626852a0b5f37)'***, to enable this support has been integrated to
> > +the ACPICA source repository.
> 
> Linux distributions tend to use dates to refer to what particular point a
> version is based on, since snapshot updates are frequently necessary.
[[Evan Lloyd]] Whilst agreeing that a date would be helpful, I don't think that 
Linux usage is relevant.  EDK II seems to go to some lengths to avoid Linux 
usage (e.g. CR LF).
> 
> In this case, that is 16 March 2018 - please mention that as well in the
> message.
[[Evan Lloyd]] Given the international nature of edk2-devel, I suggest there is 
a strong case for adopting ISO-8601 date format, so I'd prefer 2018-03-16.
> 
> > +
> > +
> > +Ensure that the iASL compiler used for building *Dynamic Tables
> > +Framework* has this feature enabled.
> >
> >  Documentation
> >  -
> > -A description document is in preparation, and should be available in
> > the -near future.
> > +[Dynamic Tables Framework: A Step Towards Automatic Generation of
> > +Advanced Configuration and Power Interface (ACPI) & System
> Management
> > +BIOS (SMBIOS) Tables – Sami Mujawar
> > +(Arm).](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic
> >
> +%20Tables%20Framework%20A%20Step%20Towards%20Automatic%20Gen
> eration%2
> >
> +0of%20Advanced%20Configuration%20and%20Power%20Interface%20%28
> ACPI%29
> >
> +%20%26%20System%20Management%20BIOS%20%28SMBIOS%29%20Table
> s%20_0.pdf)
> 
> Add a description?
> I.e.: "Presentation from UEFI Plugfest Seattle 2018"?
> 
> >
> >  Miscellaneous
> >  -
> > --
> > 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> >
> >
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Incorrect Author on patch

[Evan Lloyd]

One obvious way of precluding this sort of problem would be to move to using 
the pull request mechanism on GitHub, rather than requiring maintainers to play 
with upstreaming local patches.  I can well understand why it would be useful 
to use Gerrit as a means of reviewing a patch - actually a brilliant idea, but 
it does introduce problems. If, post review, the merge were  to be from a pull 
request then there would be no risk of "meta-data corruption".

Regards
Evan

> -Original Message-
> From: Laszlo Ersek <ler...@redhat.com>
> Sent: 25 April 2018 22:15
> To: Evan Lloyd <evan.ll...@arm.com>; ruiyu...@intel.com
> Cc: edk2-devel (edk2-devel@lists.01.org) <edk2-devel@lists.01.org>
> Subject: Re: [edk2] Incorrect Author on patch
>
> On 04/25/18 17:02, Evan Lloyd wrote:
> > Hi Ruiyu.
> > When we look at the edk2 git log, or GitHub
> >
> https://github.com/tianocore/edk2/commit/ee4dc24f57c32a445e7c747396c
> 9b
> > fbd8b221568 we see that Sami's AcpiView patch shows you as the Author.
> > I'm not sure what might have caused that (and it is obviously accidental), 
> > but
> it is a little unfortunate in that the commit doesn't show up on Sami's GitHub
> stats.
> > Fortunately, this is not currently significant for our organisation, 
> > although I'm
> sure Sami would prefer to have the credit.
> > This is a trivial matter, but you may wish to understand what caused it so 
> > that
> you don't accidentally upset someone for whom the stats are significant.
>
> Right, this occurred at least one other time as well: see commit
> 8b5c80e0296c ("MdeModulePkg/UefiBootManagerLib: fix
> AddLoadOptionVariable docs/prototype", 2018-04-23). Ray pushed the patch
> (so the Committer field is certainly right), but Ray's name+email replaced 
> mine
> in the Author field. I had noticed that earlier, but now I'm seeing it as a 
> pattern.
>
> I believe this is a tooling issue. I notice the following bit on the commit
> message:
>
> Change-Id: I8a609d6502b6f8929b2f568acaa147065003b6f4
>
> I certainly didn't post the patch with that, and I doubt Ray added it 
> manually.
> So, whatever tool Ray used to handle the patch lost the authorship
> information.
>
> And, I see the exact same kind of tag, namely
>
> Change-Id: Ifa23dc80ab8ab042c56e88424847e796a8122a7c
>
> on commit ee4dc24f57c3 ("ShellPkg: Add acpiview tool to dump ACPI tables",
> 2018-04-23), which you mention.
>
> ... In fact, my patch happens to be the direct ancestor of Sami's, in the git
> history, and their commit times are just ~3 minutes apart. I'm quite certain 
> Ray
> has started using a new tool.
>
> For example, commit bc2288f59ba2 ("UefiCpuPkg/MpInitLib: put
> mReservedApLoopFunc in executable memory", 2018-03-08) was also
> committed by Ray, *but* Jian's authorship was preserved fine. (No "Change-
> Id" either.)
>
> ... Oh... it looks like those Change-Id's were added by Gerrit:
>
> https://git.eclipse.org/r/Documentation/user-changeid.html
>
> And then, please look at this:
>
> https://gerrit-review.googlesource.com/Documentation/error-invalid-
> author.html
>
> For every pushed commit Gerrit verifies that the e-mail address of
> the author matches one of the registered e-mail addresses of the
> pushing user. If this is not the case pushing the commit fails with
> the error message "invalid author". This policy can be bypassed by
> having the access right 'Forge Author'.
>
> Uh, what?... Gerrit says "invalid author" if Ray pushes a patch that wasn't
> authored by himself? And the option to override that is called "forge" author?
> O_o
>
> Anyway, the page continues,
>
> If pushing to Gerrit fails with the error message "invalid author"
> and somebody else is author of the commit for which the push fails,
> then you have no permissions to forge the author identity. In this
> case you may contact the project owner to request the access right
> '+1 Forge Author Identity' in the 'Forge Identity' category or ask
> the maintainer to commit this change on the author’s behalf.
>
> Ray, if you absolutely must use Gerrit, please make sure that you have the '+1
> Forge Author Identity' access right. IMO, we maintainers are responsible for
> preserving git metadata the best we can.
>
> (For example, if a patch is applied from the mailing list with "git am", it
> preserves the authorship information -- the documentation says, 'The commit
> author name is taken from the "From: " line of the message, and commit
> author date is taken from the "Date: " line of t

[edk2] Incorrect Author on patch

[Evan Lloyd]

Hi Ruiyu.
When we look at the edk2 git log, or GitHub 
https://github.com/tianocore/edk2/commit/ee4dc24f57c32a445e7c747396c9bfbd8b221568
we see that Sami's AcpiView patch shows you as the Author.
I'm not sure what might have caused that (and it is obviously accidental), but 
it is a little unfortunate in that the commit doesn't show up on Sami's GitHub 
stats.
Fortunately, this is not currently significant for our organisation, although 
I'm sure Sami would prefer to have the credit.
This is a trivial matter, but you may wish to understand what caused it so that 
you don't accidentally upset someone for whom the stats are significant.

Regards,
Evan



Evan Lloyd | Technical Lead for Windows on Arm | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m. +44 (0)7825256132
110 Fulbourn Road, Cambridge, CB1 9NJ
Arm.com

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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v3 12/17] ARM/VExpressPkg: Allocate framebuffer using EfiRuntimeServicesData

[Evan Lloyd]

Hi Ard.

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Ard
> Biesheuvel
> Sent: 21 March 2018 18:27
> To: Girish Pathak <girish.pat...@arm.com>
> Cc: nd <n...@arm.com>; edk2-devel@lists.01.org; Leif Lindholm
> <leif.lindh...@linaro.org>; Stephanie Hughes-Fitt  f...@arm.com>; Arvind Chauhan <arvind.chau...@arm.com>
> Subject: Re: [edk2] [PATCH edk2-platforms v3 12/17] ARM/VExpressPkg:
> Allocate framebuffer using EfiRuntimeServicesData
> 
> On 21 March 2018 at 19:07, Girish Pathak <girish.pat...@arm.com>
> wrote:
> >
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 21 March 2018 03:38
> >> To: Girish Pathak <girish.pat...@arm.com>
> >> Cc: edk2-devel@lists.01.org; Leif Lindholm
> >> <leif.lindh...@linaro.org>; Matteo Carlini <matteo.carl...@arm.com>;
> >> Stephanie Hughes-Fitt <stephanie.hughes-f...@arm.com>; nd
> >> <n...@arm.com>; Arvind Chauhan <arvind.chau...@arm.com>; Daniil
> Egranov
> >> <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>
> >> Subject: Re: [PATCH edk2-platforms v3 12/17] ARM/VExpressPkg:
> >> Allocate framebuffer using EfiRuntimeServicesData
> >>
> >> On 21 March 2018 at 00:18, Girish Pathak <girish.pat...@arm.com>
> wrote:
> >> > As per the UEFI specification(2.7) section 12.9, the GOP
> >> > framebuffer memory can be accessed in the pre-boot and the post
> >> > boot phase (by OS) Therefore the memory type EfiBootServicesData is
> >> > incorrect for the framebuffer memory allocation. Change
> >> > EfiBootServicesData with EfiRuntimeServicesData flag so that
> >> > allocated memory can be access by the OS in the post boot phase.
> >> >
> >>
> >> EfiRuntimeServicesData is intended for allocations that the EFI
> >> runtime services need to access themselves at runtime, and will hence
> >> be virtually remapped by SetVirtualAddressMap().
> >>
> >> This does not apply to the framebuffer. Even if it may be used at OS
> >> runtime, the firmware itself will never access it, so
> >> EfiRuntimeServicesData is not appropriate
> >>
> >> Please use EfiReservedMemory instead.
> >
> > Specification (UEFI Spec 2_7_A Sept 6.pdf) describes
> > EfiReservedMemoryType as  Not usable before and after ExitBootServices,
> See Table 28 & 29 Hence EfiReservedMemoryType is not suitable in this
> case.  Agree?
> >
> 
> It is not usable as ordinary memory, given that you turn it into 'special'
> memory (with side effects) by turning it into a framebuffer.
> 
> So EfiReservedMemory is perfectly appropriate here.
[[Evan Lloyd]] First, I agree EfiReservedMemory is probably the sensible 
option.  The only alternative would be EfiMemoryMappedIO, and that, as you have 
pointed out in the past, introduces alignment requirements.  If you are happy 
to accept it, I'll ask Girish to go with that.  However, Girish has a point, if 
only that the UEFI spec need more clarity on this, especially as 
https://lists.01.org/pipermail/edk2-devel/2017-February/007494.html pretty much 
confirms it is the right way to go.  In particular, the bald statement 
"EfiReservedMemoryTypeNot usable.", seems unfortunate.

Regards,
Evan

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

Re: [edk2] [staging/dynamictables PATCH 0/2] Dynamic Tables Framework core

[Evan Lloyd]

Hi Nathaniel.

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of
> Desimone, Nathaniel L
> Sent: 20 March 2018 22:08
> To: Sami Mujawar <sami.muja...@arm.com>; edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org
> Subject: Re: [edk2] [staging/dynamictables PATCH 0/2] Dynamic Tables
> Framework core
> 
> Please don't use the name DynamicTableManagerDxe. What does it manage?
> DynamicTables? How does adding the word "Manager" provide any useful
> information for the reader? I recommend the name "DynamicAcpiTableDxe".
[[Evan Lloyd]] 
The problem with " DynamicAcpiTableDxe" is that the table manager can be used 
for SMBIOS tables and even, should you be so inclined (perverse?) Device Tree.  
The "DynamicTableManager" name relates to the fact that the component generates 
and submits tables (of whatever sort) as opposed to the ConfigurationManager 
component which obtains, collates and provides the Configuration information.

> It makes it clear this this code is specifically for generating ACPI tables at
> runtime (as opposed to some sort of unnamed table), and it removes the
> unnecessary prose.
[[Evan Lloyd]] As noted (and implied by the name), the code is not 
"specifically for generating ACPI tables"

That being said, we'd be happy to change the names if you can suggest something 
clearer.
DynamicTablesDxe might do - the "Manager" part is, as you indicate, pretty 
redundant.
That implies changing ConfigurationManager to something like "DynamicConfig".

Would that strike you as clearer?

Regards,
Evan



> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Sami Mujawar
> Sent: Monday, March 19, 2018 8:19 AM
> To: edk2-devel@lists.01.org
> Cc: n...@arm.com; leif.lindh...@linaro.org; Stephanie.Hughes-
> f...@arm.com
> Subject: [edk2] [staging/dynamictables PATCH 0/2] Dynamic Tables
> Framework core
> 
> The Dynamic Tables Framework is a prototyped as a solution for
> automatically generating the firmware tables based on hardware
> description.
> 
> This patchset is the Dynamic Tables Framework core and implement the
> generic/standard modules for dynamically generating ACPI 6.2 tables for
> ARM platform. The platform specific modules are in the devel-
> dynamictables branch in the edk2-platforms repository at:
> https://github.com/tianocore/edk2-platforms/tree/devel-dynamictables
> 
> The first patch in this patchset 'MdePkg: SMMUv3 updates for IORT'
> is a precursor for the Dynamic Tables Framework and has been submitted
> independently to the edk2-devel mailing list where it is currently awaiting
> acceptance.
> 
> The sources for this patchset can be seen at:
> https://github.com/samimujawar/edk2-
> staging/tree/187_dynamictables_v1
> 
> Sami Mujawar (2):
>   MdePkg: SMMUv3 updates for IORT table definitions
>   DynamicTablesPkg: Dynamic Tables Framework
> 
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/AcpiTableFactory/Acpi
> TableFactory.c |  226 +++
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DeviceTreeTableFactor
> y/DeviceTreeTableFactory.c |  225 +++
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactory.
> h   |  125 ++
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactory
> Dxe.c|   84 +
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactory
> Dxe.inf  |   59 +
> 
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/SmbiosTableFactory/S
> mbiosTableFactory.c |  226 +++
> 
> DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManag
> erDxe.c|  533 +
> 
> DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManag
> erDxe.inf  |   48 +
>  DynamicTablesPkg/DynamicTables.dsc.inc
> |   46 +
>  DynamicTablesPkg/DynamicTables.fdf.inc
> |   35 +
>  DynamicTablesPkg/DynamicTablesPkg.dec
> |   42 +
>  DynamicTablesPkg/Include/AcpiTableGenerator.h
> |  282 +++
>  DynamicTablesPkg/Include/ArmNameSpaceObjects.h
> |  587 ++
>  DynamicTablesPkg/Include/ConfigurationManagerHelper.h
> |  119 ++
>  DynamicTablesPkg/Include/ConfigurationManagerObject.h
> |  176 ++
>  DynamicTablesPkg/Include/DeviceTreeTableGenerator.h
> |  182 ++
>  DynamicTablesPkg/Include/Library/TableHelperLib.h
> |   70 +
>  DynamicTablesPkg/Include/Protocol/ConfigurationManagerProtocol.h
> |  128 ++
>  DynamicTablesPkg/Include/Protocol/DynamicTableFactoryProtocol.h
> |  140 ++
>  DynamicTab

Re: [edk2] [PATCH edk2-platforms v3 00/17] Update GOP

[Evan Lloyd]

To minimise the spam involved, I'm hoping the maintainers will accept this as 
covering all the patches listed.  (Please?)

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>


> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:18
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; ard.biesheu...@linaro.org;
> leif.lindh...@linaro.org; Stephanie Hughes-Fitt  f...@arm.com>; Arvind Chauhan <arvind.chau...@arm.com>
> Subject: [edk2] [PATCH edk2-platforms v3 00/17] Update GOP
> 
> This patch series addresses comments on the patch v2
> (https://lists.01.org/pipermail/edk2-devel/2017-December/019406.html)
> reworking of the Graphics Output Protocol code in ArmPlatformPkg.
> It also contains updates for the new SCMI protocol (MTL Library).
> 
> Code is available for examination at:
>   https://github.com/girishpathak/edk2-platforms/tree/201_gop_v3
> 
> 
> Ard Biesheuvel (1):
>   ARM/VExpressPkg: Fix MODULE_TYPE of HDLCD/PL111 platform libraries
> 
> EvanLloyd (2):
>   ARM/VExpressPkg: HdLcdArmVExpressLib: Remove redundant Bpp
>   ARM/VExpressPkg: Redefine LcdPlatformGetTimings function
> 
> Girish Pathak (14):
>   ARM/VExpressPkg: Tidy HDLCD and PL11LCD platform Lib: Coding
> standard
>   ARM/VExpressPkg: Tidy HdLcd/PL111Lcd code: Updated comments
>   ARM/VExpressPkg: Remove unused PcdPL111LcdMaxMode from HDLCD
> inf
>   ARM/VExpressPkg: Add and update debug ASSERTS
>   ARM/VExpressPkg: PL111Lcd/HdLcd plaform libs: Minor code cleanup
>   ARM/VExpressPkg: PL111 and HDLCD: Use FixedPcdGet32
>   ARM/VExpressPkg: HdLcdArmVExpressLib: Remove status check
> EFI_TIMEOUT
>   ARM/VExpressPkg: PL111 and HDLCD: Add PCD to select pixel format
>   ARM/VExpressPkg: Allocate framebuffer using EfiRuntimeServicesData
>   ARM/VExpressPkg: Reserving framebuffer at build
>   ARM/VExpressPkg: Set EFI_MEMORY_XP flag on GOP framebuffer
>   ARM/VExpressPkg: New DP500/DP550/DP650 platform library
>   ARM/JunoPkg: Adding SCMI MTL library
>   ARM/JunoPkg: Add HDLCD platform library
> 
>  Platform/ARM/JunoPkg/ArmJuno.dec 
>   |  17 +-
>  Platform/ARM/JunoPkg/ArmJuno.dsc 
>   |  31 +-
>  Platform/ARM/JunoPkg/ArmJuno.fdf 
>   |  12 +-
>  Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
> |   5 +-
>  Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c
> |  29 +-
>  Platform/ARM/JunoPkg/Library/ArmJunoMtlLib/ArmJunoMtlLib.c
> | 198 +++
>  Platform/ARM/JunoPkg/Library/ArmJunoMtlLib/ArmJunoMtlLib.inf
> |  39 ++
>  Platform/ARM/JunoPkg/Library/ArmJunoMtlLib/ArmJunoMtlPrivateLib.h
> |  94 
>  Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJuno.c
> | 555 
>  Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf
> |  41 ++
>  Platform/ARM/VExpressPkg/ArmVExpressPkg.dec  
>   |
> 3 +-
>  Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c
> | 387 ++
>  Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf
> |  43 ++
> 
> Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib
> .inf |   7 +-
>  Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
> |  53 +-
> 
> Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExp
> ress.c| 310 +++
> 
> Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExp
> ressLib.inf   |  14 +-
> 
> Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdAr
> mVExpress.c  | 389 +-
> 
> Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdAr
> mVExpressLib.inf |  10 +-
>  19 files changed, 1945 insertions(+), 292 deletions(-)  create mode 100644
> Platform/ARM/JunoPkg/Library/ArmJunoMtlLib/ArmJunoMtlLib.c
>  create mode 100644
> Platform/ARM/JunoPkg/Library/ArmJunoMtlLib/ArmJunoMtlLib.inf
>  create mode 100644
> Platform/ARM/JunoPkg/Library/ArmJunoMtlLib/ArmJunoMtlPrivateLib.h
>  create mode 100644
> Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJuno.c
>  create mode 100644
> Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf
>  create mode 100644
> Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c
>  create mode 100644
> Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf
> 
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 16/16] ArmPkg: Introduce SCMI protocol

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 16/16] ArmPkg: Introduce SCMI protocol
> 
> This change introduces a new SCMI protocol driver for
> Arm systems. The driver currently supports only clock
> and performance management protocols. Other protocols
> will be added as and when needed.
> 
> Clock management protocol is used to configure various clocks
> available on the platform e.g. HDLCD clock on the Juno platforms.
> 
> Whereas performance management protocol allows adjustment
> of various performance domains. Currently this is used to evaluate
> performance of the Juno platform.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
> 
> Notes:
> v3:
> - Please rename ArmMtl.h to ArmMtlLibi.h, and
>   declare it as a library class in the package file.  [Ard]
> 
>   Done, however ArmMtlLib.h is now part of earlier commit [Girish]
> 
> - Move ArmScmiDxe to ArmPkg from ArmPlatformPkg   [Ard]
> 
>   Done[Girish]
> 
> - Declare gArmScmiBaseProtocolGuid and similar
>   protocols Guids in ArmPkg.dec   [Ard]
> 
>   Done[Girish]
> 
> - Replace flexible array member [] with [1]   [Ard]
> 
>   Done[Girish]
> 
> - Move protocol init function which are not part of
>   of protocol like  ScmiBaseProtocolInit elsewhere[Ard]
> 
>   Done[Girish]
> 
> - Please don't put stuff in Include/Drivers.  [Ard]
> 
>   Moved headers to Include/Protocol.  [Girish]
> 
>  ArmPkg/ArmPkg.dec |  13 +
>  ArmPkg/ArmPkg.dsc |   6 +-
>  ArmPkg/Drivers/ArmScmiDxe/ArmScmiBaseProtocolPrivate.h|  46 ++
>  ArmPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h   |  84
> 
>  ArmPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf  |  53 +++
>  ArmPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h |  55
> +++
>  ArmPkg/Drivers/ArmScmiDxe/Scmi.c  | 262 
> +++
>  ArmPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c  | 318
> ++
>  ArmPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c | 418
> ++
>  ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c   | 138 ++
>  ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.h   |  41 ++
>  ArmPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c   | 457
> 
>  ArmPkg/Drivers/ArmScmiDxe/ScmiPrivate.h   | 174 
>  ArmPkg/Include/Protocol/ArmScmi.h |  27 ++
>  ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h | 174
> 
>  ArmPkg/Include/Protocol/ArmScmiClockProtocol.h| 218
> ++
>  ArmPkg/Include/Protocol/ArmScmiPerformanceProtocol.h  | 265
> 
>  17 files changed, 2748 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index
> 881751d81c6384a3eb0b4c180c76d01a58266a74..16f7e40046429142b44
> b526043b61a3d5e089d2c 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -51,6 +51,19 @@ [Guids.common]
> 
>gArmGicDxeFileGuid = { 0xde371f7c, 0xdec4, 0x4d21, { 0xad, 0xf1, 0x59,
> 0x3a, 0xbc, 0xc1, 0x58, 0x82 } }
> 
> +[Protocols.common]
> +  ## Arm System Control and Management Interface(SCMI) Base protocol
> +  ## ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
> +  gArmScmiBaseProtocolGuid = { 0xd7e5abe9, 0x33ab, 0x418e, { 0x9f,
> 0x91, 0x72, 0xda, 0xe2, 0xba, 0x8e, 0x2f } }
> +
> +  ## Arm System Control and Management Interface(SCMI) Clock
> management protocol
> +  ## ArmPkg/Include/Protocol/ArmScmiClockProtocol.h
> +  gArmScmiClockProtocolGuid = { 0x91ce67a8, 0xe0aa, 0x4012, { 0xb9,
> 0x9f, 0xb6, 0xfc, 0xf3, 0x4, 0x8e, 0xaa } }
> +
> +  ## Arm System Control and Management Interface(SCMI) Clock
> management protocol
> +  ## ArmPkg/Include/Protoco

Re: [edk2] [PATCH v3 15/16] ArmPkg: MTL Library interface and Null library implementation

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 15/16] ArmPkg: MTL Library interface and Null
> library implementation
> 
> Upcoming new component ArmPkg/Drivers/ArmScmiDxe is dependent on
> platform specific ArmMtlLib library implementation, however in order to be
> able to build the ArmScmiDxe component outside of the context of a
> particular platform, this change adds Null implementation of the ArmMtlLib
> along with ARM MTL library header.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  ArmPkg/ArmPkg.dec  |   3 +-
>  ArmPkg/Include/Library/ArmMtlLib.h | 137
> 
>  ArmPkg/Library/ArmMtlNullLib/ArmMtlNullLib.c   | 108
> +++
>  ArmPkg/Library/ArmMtlNullLib/ArmMtlNullLib.inf |  26 
>  4 files changed, 273 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index
> a55b6268ff85ffd7da140be813ec875f7f242c4d..881751d81c6384a3eb0b4c
> 180c76d01a58266a74 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -2,7 +2,7 @@
>  # ARM processor package.
>  #
>  # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved. -#
> Copyright (c) 2011 - 2017, ARM Limited. All rights reserved.
> +# Copyright (c) 2011 - 2018, ARM Limited. All rights reserved.
>  #
>  #This program and the accompanying materials
>  #are licensed and made available under the terms and conditions of the
> BSD License
> @@ -40,6 +40,7 @@ [LibraryClasses.common]
>ArmDisassemblerLib|Include/Library/ArmDisassemblerLib.h
>ArmGicArchLib|Include/Library/ArmGicArchLib.h
>ArmSvcLib|Include/Library/ArmSvcLib.h
> +  ArmMtlLib|ArmPlatformPkg/Include/Library/ArmMtlLib.h
> 
>  [Guids.common]
>gArmTokenSpaceGuid   = { 0xBB11ECFE, 0x820F, 0x4968, { 0xBB, 0xA6,
> 0xF7, 0x6A, 0xFE, 0x30, 0x25, 0x96 } }
> diff --git a/ArmPkg/Include/Library/ArmMtlLib.h
> b/ArmPkg/Include/Library/ArmMtlLib.h
> new file mode 100644
> index
> ..4218a741e5ebddd080
> 22b94354d5ef47576cd3b8
> --- /dev/null
> +++ b/ArmPkg/Include/Library/ArmMtlLib.h
> @@ -0,0 +1,137 @@
> +/** @file
> +
> +  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
> +
> +  This program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +  System Control and Management Interface V1.0
> +http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
> +DEN0056A_System_Control_and_Management_Interface.pdf
> +**/
> +
> +#ifndef ARM_MTL_LIB_H_
> +#define ARM_MTL_LIB_H_
> +
> +#include 
> +
> +// Ideally we don't need packed struct. However we can't rely on compilers.
> +#pragma pack(1)
> +
> +typedef struct {
> +  UINT32 Reserved1;
> +  UINT32 ChannelStatus;
> +  UINT64 Reserved2;
> +  UINT32 Flags;
> +  UINT32 Length;
> +  UINT32 MessageHeader;
> +
> +  // NOTE: Since EDK2 does not allow flexible array member [] we
> +declare
> +  // here array of 1 element length. However below is used as a
> +variable
> +  // length array.
> +  UINT32 Payload[1];// size less object gives offset to payload.
> +} MTL_MAILBOX;
> +
> +#pragma pack()
> +
> +// Channel Type, Low-priority, and High-priority typedef enum {
> +  MTL_CHANNEL_TYPE_LOW = 0,
> +  MTL_CHANNEL_TYPE_HIGH = 1
> +} MTL_CHANNEL_TYPE;
> +
> +typedef struct {
> +  UINT64 PhysicalAddress;
> +  UINT32 ModifyMask;
> +  UINT32 PreserveMask;
> +} MTL_DOORBELL;
> +
> +typedef struct {
> +  MTL_CHANNEL_TYPE ChannelType;
> +  MTL_MAILBOX  * CONST MailBox;
> +  MTL_DOORBELL DoorBell;
> +} MTL_CHANNEL;
> +
> +/** Wait until channel is free.
> +
> +  @param[in] ChannelPointer to a channel.
> +  @param[in] TimeOutInMicroSeconds  Time out in micro seconds.
> +
> +  @retval EFI_SUCCESS   Channel is free.
> +  @retval EFI

Re: [edk2] [PATCH v3 03/16] ArmPlatformPkg: Tidy Lcd code: Coding standard

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 03/16] ArmPlatformPkg: Tidy Lcd code: Coding
> standard
> 
> From: Girish Pathak 
> 
> There is no functional modification in this change As preparation for further
> work, the formatting is corrected to meet the EDKII coding standard.
> Of specific note, some invalid include guards were fixed.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
> 
> Notes:
> v3:
> - Minor coding style changes  [Ard]
> 
>   Done[Girish]
> 
> - Changing one style to the other is just pointless churn [Ard]
> 
>   Fixing the include guards: is a small improvement.
>   (Ideally patchcheck should reject these.)
>   Reducing lines to 80 columns: makes Leif (at least)
>   happy, and aligns with formatter behaviour. Correcting
>   Doxygen format comments: prevents Doxygen generating
>   gibberish. Spaces before '(': Maintains consistency,
>   and aligns  with desired formatter behaviour.   [Evan]
> 
>  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
> | 187 +++-
> ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |
> 10 +-
>  ArmPlatformPkg/Include/Library/LcdPlatformLib.h|  14 +-
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c   |  88 
> +
>  ArmPlatformPkg/Library/HdLcd/HdLcd.h   |  21 ++-
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c |  64 
> ---
>  6 files changed, 208 insertions(+), 176 deletions(-)
> 
> diff --git
> a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> index
> b721061fc1df5695092e8c71da97ae0b9af46b3f..905eb26ee01b5037dfbaf3
> c054a62593837c8b5f 100644
> ---
> a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> +++
> b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> @@ -1,6 +1,6 @@
>  /** @file
> 
> - Copyright (c) 2011-2014, ARM Ltd. All rights reserved.
> + Copyright (c) 2011-2018, ARM Ltd. All rights reserved.
>   This program and the accompanying materials
>   are licensed and made available under the terms and conditions of the BSD
> License
>   which accompanies this distribution.  The full text of the license may be
> found at @@ -9,7 +9,7 @@
>   THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
>   WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> 
> - **/
> +**/
> 
>  #include 
>  #include 
> @@ -22,12 +22,10 @@
> 
>  #include "LcdGraphicsOutputDxe.h"
> 
> -
> /**
> 
> - *
> - *  This file implements the Graphics Output protocol on
> ArmVersatileExpress
> - *  using the Lcd controller
> - *
> -
> **
> /
> +/** This file implements the Graphics Output protocol on
> +ArmVersatileExpress
> +  using the Lcd controller
> +
> +**/
> 
>  //
>  // Global variables
> @@ -64,7 +62,10 @@ LCD_INSTANCE mLcdTemplate = {
>  {
>{
>  HARDWARE_DEVICE_PATH, HW_VENDOR_DP,
> -{ (UINT8) (sizeof(VENDOR_DEVICE_PATH)), (UINT8)
> ((sizeof(VENDOR_DEVICE_PATH)) >> 8) },
> +{
> +  (UINT8)(sizeof (VENDOR_DEVICE_PATH)),
> +  (UINT8)((sizeof (VENDOR_DEVICE_PATH)) >> 8)
> +},
>},
>// Hardware Device Path for Lcd
>EFI_CALLER_ID_GUID // Use the driver's GUID @@ -73,10 +74,13 @@
> LCD_INSTANCE mLcdTemplate = {
>  {
>END_DEVICE_PATH_TYPE,
>END_ENTIRE_DEVICE_PATH_SUBTYPE,
> -  { sizeof(EFI_DEVICE_PATH_PROTOCOL), 0 }
> +  {
> +sizeof (EFI_DEVICE_PATH_PROTOCOL),
> +0
> +  }
>  }
>},
> -  (EFI_EVENT) NULL // ExitBootServicesEvent
> +  (EFI_EVENT)NULL // ExitBootServicesEvent
>  };
> 
>  EFI_STATUS
> @@ -86,7 +90,7 @@ LcdInstanceContructor (  {
>LCD_INSTANC

Re: [edk2] [PATCH v3 13/16] ArmPlatformPkg: Reserving framebuffer at build

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 13/16] ArmPlatformPkg: Reserving framebuffer
> at build
> 
> From: Girish Pathak 
> 
> Currently framebuffer memory is either reserved in special VRAM or
> dynamically allocated using boot services memory allocation functions.
> When allocated using boot services calls the memory has to be allocated as
> EfiBootServicesData. Unfortunately failures have been seen with this case.
> There is also an unfortunate lack of control on the placement of the
> framebuffer.
> 
> This change introduces two PCDs, PcdArmLcdFrameBufferBase and
> PcdArmLcdFrameBufferSize which enable build time reservation of the
> framebuffer, avoiding the need to allocate dynamically. This allows the
> framebuffer to appear as "I/O memory" outside of the normal RAM map,
> which is similar to the "VRAM" case.
> 
> This change has no impact on current code, only enables the option of build
> time reservation of framebuffers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  ArmPlatformPkg/ArmPlatformPkg.dec | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index
> 5231ea822f05c2f281a6190d6eae0fc7d0bc0cb3..5c702718a78a78e6c67ab
> 407e198382e0a0df4be 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -93,6 +93,11 @@ [PcdsFixedAtBuild.common]
> 
> gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x0|UINT32|0x002
> 6
> 
> gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x0|UINT32|0x002
> 7
> 
> +  ## Default size for display modes upto 1920x1080 (1920 * 1080 * 4
> + Bytes Per Pixel)
> +
> +
> gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize|0x7E9000|
> UINT32
> + |0x0043  ## If set, framebuffer memory will be reserved and
> mapped
> + in the system RAM
> +
> +
> gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase|0x0|UINT6
> 4|0x00
> + 44
> +
>## PL180 MCI
> 
> gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x|
> UINT32|0x0028
> 
> gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x|UI
> NT32|0x0029
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 14/16] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 14/16] ArmPlatformPkg: New
> DP500/DP550/DP650 GOP driver
> 
> From: Girish Pathak 
> 
> This change adds support for the ARM Mali DP500/DP500/DP650 display
> processors using the GOP protocol. It has been tested on FVP base models
> + DP550 support. This change adds platform independant LcdHwLib library.
> A corresponding platform specific library will be submitted to edk-
> platforms/Platform/ARM/VExpressPkg.
> 
> This change does not modify functionality provided by PL111 or HDLCD.
> This LcdHwLib implementation should be suitable for those platforms that
> implement ARM Mali DP500/DP550/DP650 replacing PL111/HDLCD.
> 
> Only graphics layer of the ARM Mali DP is configured for rendering the
> RGB/BGR format frame buffer to satisfy the UEFI GOP requirements Other
> layers e.g. video layers are not configured.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
> 
> Notes:
> v3:
> - Please add this library as a component to
>   ArmPlatformPkg.dsc as well, so we can do build testing
>   on it.   [Ard]
> 
>   Done [Girish]
> 
> - Please drop references to edk2-platforms.
>   This driver should be able to be used independently
>   from VExpress platform code  [Ard]
> 
>   Done [Girish]
> 
>  ArmPlatformPkg/ArmPlatformPkg.dec  |   4 +
>  ArmPlatformPkg/ArmPlatformPkg.dsc  |   4 +-
>  ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.c   | 409
> 
>  ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h   | 243 
>  ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.inf |  43 ++
>  5 files changed, 702 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index
> 5c702718a78a78e6c67ab407e198382e0a0df4be..28cdc259849da11b172a
> d52045bccc0276669852 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -98,6 +98,10 @@ [PcdsFixedAtBuild.common]
>## If set, framebuffer memory will be reserved and mapped in the system
> RAM
> 
> gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase|0x0|UINT6
> 4|0x0044
> 
> +  ## ARM Mali Display Processor DP500/DP550/DP650
> +
> gArmPlatformTokenSpaceGuid.PcdArmMaliDpBase|0x0|UINT64|0x00
> 50
> +
> +
> gArmPlatformTokenSpaceGuid.PcdArmMaliDpMemoryRegionLength|0x0|U
> INT32|0
> + x0051
> +
>## PL180 MCI
> 
> gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x|
> UINT32|0x0028
> 
> gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x|UI
> NT32|0x0029
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dsc
> b/ArmPlatformPkg/ArmPlatformPkg.dsc
> index
> 82adb9ef8891b7ba1628ede2f8eb124c25c2774a..0013106b94c371f827e0
> 1c6d402faa6aa42e4bdd 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dsc
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dsc
> @@ -2,7 +2,7 @@
>  # ARM platform package.
>  #
>  # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved. -#
> Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
> +# Copyright (c) 2011 - 2018, ARM Ltd. All rights reserved.
>  # Copyright (c) 2016 - 2017, Linaro Ltd. All rights reserved.  #
>  #This program and the accompanying materials
> @@ -120,3 +120,5 @@ [Components.common]
> 
>ArmPlatformPkg/PrePi/PeiMPCore.inf
>ArmPlatformPkg/PrePi/PeiUniCore.inf
> +
> +  ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.inf
> diff --git a/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.c
> b/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.c
> new file mode 100644
> index
> ..69c88416a448caa506
> bf8a772432144d8a138495
> --- /dev/null
> +++ b/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.c
> @@ -0,0 +1,409 @@
> +/** @file
> +
> +  ARM Mali DP 500/550/650 display controller driver
> +
> +  Copyright (c) 2017-2018, Arm Limited. All rights reserved.
> +
> +  This program and the accompanying materials  are licensed and made
> + available under the terms and cond

Re: [edk2] [PATCH v3 12/16] ArmPlatformPkg: Additional display modes

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 12/16] ArmPlatformPkg: Additional display
> modes
> 
> From: Girish Pathak 
> 
> Add definitions for new display modes such as HD 720.
> This has no effect on existing display drivers.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  ArmPlatformPkg/Include/Library/LcdPlatformLib.h | 60
> 
>  1 file changed, 60 insertions(+)
> 
> diff --git a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> index
> 8338b327fd2dd0d6b31653e278e25da5ac850939..cc535f0cd42db5673d41
> 8cbec940023927408687 100644
> --- a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> +++ b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> @@ -26,6 +26,11 @@
>  #define WSXGA 4
>  #define UXGA  5
>  #define HD6
> +#define WVGA  7
> +#define QHD   8
> +#define WSVGA 9
> +#define HD720 10
> +#define WXGA  11
> 
>  // VGA Mode: 640 x 480
>  #define VGA_H_RES_PIXELS  640
> @@ -118,6 +123,61 @@
>  #define HD_V_FRONT_PORCH  (  3 - 1)
>  #define HD_V_BACK_PORCH   ( 32 - 1)
> 
> +// WVGA Mode: 800 x 480
> +#define WVGA_H_RES_PIXELS 800
> +#define WVGA_V_RES_PIXELS 480
> +#define WVGA_OSC_FREQUENCY2950   /* 0x01C22260 */
> +#define WVGA_H_SYNC   ( 72 - 1)
> +#define WVGA_H_FRONT_PORCH( 24 - 1)
> +#define WVGA_H_BACK_PORCH ( 96 - 1)
> +#define WVGA_V_SYNC   (  7 - 1)
> +#define WVGA_V_FRONT_PORCH(  3 - 1)
> +#define WVGA_V_BACK_PORCH ( 10 - 1)
> +
> +// QHD Mode: 960 x 540
> +#define QHD_H_RES_PIXELS  960
> +#define QHD_V_RES_PIXELS  540
> +#define QHD_OSC_FREQUENCY 4075   /* 0x026DCBB0 */
> +#define QHD_H_SYNC( 96 - 1)
> +#define QHD_H_FRONT_PORCH ( 32 - 1)
> +#define QHD_H_BACK_PORCH  (128 - 1)
> +#define QHD_V_SYNC(  5 - 1)
> +#define QHD_V_FRONT_PORCH (  3 - 1)
> +#define QHD_V_BACK_PORCH  ( 14 - 1)
> +
> +// WSVGA Mode: 1024 x 600
> +#define WSVGA_H_RES_PIXELS1024
> +#define WSVGA_V_RES_PIXELS600
> +#define WSVGA_OSC_FREQUENCY   4900   /* 0x02EBAE40 */
> +#define WSVGA_H_SYNC  (104 - 1)
> +#define WSVGA_H_FRONT_PORCH   ( 40 - 1)
> +#define WSVGA_H_BACK_PORCH(144 - 1)
> +#define WSVGA_V_SYNC  ( 10 - 1)
> +#define WSVGA_V_FRONT_PORCH   (  3 - 1)
> +#define WSVGA_V_BACK_PORCH( 11 - 1)
> +
> +// HD720 Mode: 1280 x 720
> +#define HD720_H_RES_PIXELS 1280
> +#define HD720_V_RES_PIXELS 720
> +#define HD720_OSC_FREQUENCY7450   /* 0x0470C7A0 */
> +#define HD720_H_SYNC   (128 - 1)
> +#define HD720_H_FRONT_PORCH( 64 - 1)
> +#define HD720_H_BACK_PORCH (192 - 1)
> +#define HD720_V_SYNC   (  5 - 1)
> +#define HD720_V_FRONT_PORCH(  3 - 1)
> +#define HD720_V_BACK_PORCH ( 20 - 1)
> +
> +// WXGA Mode: 1280 x 800
> +#define WXGA_H_RES_PIXELS  1280
> +#define WXGA_V_RES_PIXELS  800
> +#define WXGA_OSC_FREQUENCY 8350  /* 0x04FA1BE0 */
> +#define WXGA_H_SYNC(128 - 1)
> +#define WXGA_H_FRONT_PORCH ( 72 - 1)
> +#define WXGA_H_BACK_PORCH  (200 - 1)
> +#define WXGA_V_SYNC(  6 - 1)
> +#define WXGA_V_FRONT_PORCH (  3 - 1)
> +#define WXGA_V_BACK_PORCH  ( 22 - 1)
> +
>  // Colour Masks
>  #define LCD_24BPP_RED_MASK  0x00FF
>  #define LCD_24BPP_GREEN_MASK0xFF0

Re: [edk2] [PATCH v3 04/16] ArmPlatformPkg: Tidy Lcd code: Updated comments

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 04/16] ArmPlatformPkg: Tidy Lcd code: Updated
> comments
> 
> From: Girish Pathak 
> 
> There is no functional modification in this change some comments are
> modified and a few new comments are added.
> This is to prevent mixing formatting changes with functional changes.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
> 
> Notes:
> v3:
> - Propagated comments to LcdPlatformNullLib
> 
>  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c
> | 20 ++---
>  ArmPlatformPkg/Include/Library/LcdPlatformLib.h| 92
> +++-
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 26 
> +-
>  ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c | 65
> ++
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 24 -
>  5 files changed, 189 insertions(+), 38 deletions(-)
> 
> diff --git
> a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> index
> 905eb26ee01b5037dfbaf3c054a62593837c8b5f..872361cd23fbdf52c5f128
> d0e172701e76d832b2 100644
> ---
> a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> +++
> b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> c
> @@ -1,13 +1,14 @@
>  /** @file
> +  This file implements the Graphics Output protocol for Arm platforms
> 
> - Copyright (c) 2011-2018, ARM Ltd. All rights reserved.
> - This program and the accompanying materials
> - are licensed and made available under the terms and conditions of the BSD
> License
> - which accompanies this distribution.  The full text of the license may be
> found at
> - http://opensource.org/licenses/bsd-license.php
> +  Copyright (c) 2011-2018, ARM Ltd. All rights reserved.  This
> + program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> 
> - THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> - WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> 
>  **/
> 
> @@ -22,11 +23,6 @@
> 
>  #include "LcdGraphicsOutputDxe.h"
> 
> -/** This file implements the Graphics Output protocol on
> ArmVersatileExpress
> -  using the Lcd controller
> -
> -**/
> -
>  //
>  // Global variables
>  //
> diff --git a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> index
> 3d13e417972c67cc51ae4410efd548053511e5d1..e51e78640ae7b1acd51a
> c333ba3faa8c78aea5a5 100644
> --- a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> +++ b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> @@ -18,9 +18,7 @@
> 
>  #define LCD_VRAM_SIZE SIZE_8MB
> 
> -//
>  // Modes definitions
> -//
>  #define VGA   0
>  #define SVGA  1
>  #define XGA   2
> @@ -29,9 +27,7 @@
>  #define UXGA  5
>  #define HD6
> 
> -//
>  // VGA Mode: 640 x 480
> -//
>  #define VGA_H_RES_PIXELS  640
>  #define VGA_V_RES_PIXELS  480
>  #define VGA_OSC_FREQUENCY 2375  /* 0x016A6570 */
> @@ -44,9 +40,7 @@
>  #define VGA_V_FRONT_PORCH (  3 - 1)
>  #define VGA_V_BACK_PORCH  ( 13 - 1)
> 
> -//
>  // SVGA Mode: 800 x 600
> -//
>  #define SVGA_H_RES_PIXELS 800
>  #define SVGA_V_RES_PIXELS 600
>  #define SVGA_OSC_FREQUENCY3825  /* 0x0247A610 */
> @@ -59,9 +53,7 @@
>  #define SVGA_V_FRONT_PORCH(  3 - 1)
>  #define SVGA_V_BACK_PORCH ( 17 - 1)
> 
> -

Re: [edk2] [PATCH v3 09/16] ArmPlatformPkg: Redefine LcdPlatformGetTimings function

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 09/16] ArmPlatformPkg: Redefine
> LcdPlatformGetTimings function
> 
> From: Girish Pathak 
> 
> The LcdPlatformGetTimings interface function takes similar sets of multiple
> parameters for horizontal and vertical timings which can be aggregated in a
> common data type. This change defines a structure SCAN_TIMINGS for this
> which can be used to describe both horizontal and vertical scan timings,
> and accordingly redefines the LcdPlatformGetTiming interface, greatly
> reducing the amount of data passed about.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  ArmPlatformPkg/Include/Library/LcdPlatformLib.h| 31 
> ++
> --
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 50 
> +
> ---
>  ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c | 10 +---
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 43
> +
>  4 files changed, 64 insertions(+), 70 deletions(-)
> 
> diff --git a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> index
> e51e78640ae7b1acd51ac333ba3faa8c78aea5a5..8338b327fd2dd0d6b316
> 53e278e25da5ac850939 100644
> --- a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> +++ b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
> @@ -153,6 +153,14 @@ typedef enum {
>LCD_BITS_PER_PIXEL_12_444
>  } LCD_BPP;
> 
> +// Display timing settings.
> +typedef struct {
> +  UINT32  Resolution;
> +  UINT32  Sync;
> +  UINT32  BackPorch;
> +  UINT32  FrontPorch;
> +} SCAN_TIMINGS;
> +
>  /** Platform related initialization function.
> 
>@param[in] Handle  Handle to the LCD device instance.
> @@ -228,14 +236,11 @@ LcdPlatformQueryMode (
> 
>@param[in]  ModeNumber  Mode Number.
> 
> -  @param[out] HResPointer to horizontal resolution.
> -  @param[out] HSync   Pointer to horizontal sync width.
> -  @param[out] HBackPorch  Pointer to horizontal back porch.
> -  @param[out] HFrontPorch Pointer to horizontal front porch.
> -  @param[out] VResPointer to vertical resolution.
> -  @param[out] VSync   Pointer to vertical sync width.
> -  @param[out] VBackPorch  Pointer to vertical back porch.
> -  @param[out] VFrontPorch Pointer to vertical front porch.
> +  @param[out] Horizontal  Pointer to horizontal timing parameters.
> +  (Resolution, Sync, Back porch, Front porch)
> +  @param[out] VerticalPointer to vertical timing parameters.
> +  (Resolution, Sync, Back porch, Front
> + porch)
> +
> 
>@retval EFI_SUCCESS Display timing information for the 
> requested
>mode returned successfully.
> @@ -244,14 +249,8 @@ LcdPlatformQueryMode (  EFI_STATUS
> LcdPlatformGetTimings (
>IN  UINT32  ModeNumber,
> -  OUT UINT32* HRes,
> -  OUT UINT32* HSync,
> -  OUT UINT32* HBackPorch,
> -  OUT UINT32* HFrontPorch,
> -  OUT UINT32* VRes,
> -  OUT UINT32* VSync,
> -  OUT UINT32* VBackPorch,
> -  OUT UINT32* VFrontPorch
> +  OUT SCAN_TIMINGS**Horizontal,
> +  OUT SCAN_TIMINGS**Vertical
>);
> 
>  /** Return bits per pixel information for a mode number.
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> index
> 039048398c531ec944bc4b43a5551a554a368481..f5886848ce582b475b5
> 97ccca015c816707ade0e 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> @@ -98,34 +98,25 @@ LcdSetMode (
>)
>  {
>EFI_STATUSStatus;
> -  UINT32HRes;
> -  UINT32HSync;
> -  U

Re: [edk2] [PATCH v3 05/16] ArmPlatformPkg: HDLCD and PL111: Update debug ASSERTS

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 05/16] ArmPlatformPkg: HDLCD and PL111:
> Update debug ASSERTS
> 
> From: Girish Pathak 
> 
> This change moves some ASSERTs in error handling code to improve
> efficiency in DEBUG build. This change also removes redundant error code
> returns.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
> 
> Notes:
> v3:
> - Reverted to ASSERT_EFI_ERROR (Status) from ASSERT (FALSE)
> 
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 11 +--
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 12 ++--
>  2 files changed, 11 insertions(+), 12 deletions(-)
> 
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> index
> be4ccfdc1f421060faec792c8e8acfcfb3232014..28306c530e08b5e0fcef430
> 8435045da3c9e093c 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> @@ -90,8 +90,7 @@ LcdInitialize (
>@param[in] ModeNumber  Display mode number.
> 
>@retval EFI_SUCCESSDisplay mode set successfully.
> -  @retval EFI_DEVICE_ERROR   Reurns an error if display timing
> - information is not available.
> +  @retval !(EFI_SUCCESS) Other errors.
>  **/
>  EFI_STATUS
>  LcdSetMode (
> @@ -122,15 +121,15 @@ LcdSetMode (
>   ,
>   
>   );
> -  ASSERT_EFI_ERROR (Status);
>if (EFI_ERROR (Status)) {
> -return EFI_DEVICE_ERROR;
> +ASSERT_EFI_ERROR (Status);
> +return Status;
>}
> 
>Status = LcdPlatformGetBpp (ModeNumber, );
> -  ASSERT_EFI_ERROR (Status);
>if (EFI_ERROR (Status)) {
> -return EFI_DEVICE_ERROR;
> +ASSERT_EFI_ERROR (Status);
> +return Status;
>}
> 
>BytesPerPixel = GetBytesPerPixel (LcdBpp); diff --git
> a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> index
> ccd7a4d1d43ad5c2f495683ac68236e17f3b55a5..cb64c57dd79f3bb1345e4
> d3dbda7f5b3ce859f40 100644
> --- a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> +++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> @@ -75,8 +75,8 @@ LcdInitialize (
>@param[in] ModeNumbe   Display mode number.
> 
>@retval EFI_SUCCESSDisplay mode set successfuly.
> -  @retval EFI_DEVICE_ERROR   It returns an error if display timing
> - information is not available.
> +  @retval !(EFI_SUCCESS) Other errors.
> +
>  **/
>  EFI_STATUS
>  LcdSetMode (
> @@ -107,15 +107,15 @@ LcdSetMode (
>   ,
>   
>   );
> -  ASSERT_EFI_ERROR (Status);
>if (EFI_ERROR (Status)) {
> -return EFI_DEVICE_ERROR;
> +ASSERT_EFI_ERROR (Status);
> +return Status;
>}
> 
>Status = LcdPlatformGetBpp (ModeNumber, );
> -  ASSERT_EFI_ERROR (Status);
>if (EFI_ERROR (Status)) {
> -return EFI_DEVICE_ERROR;
> +ASSERT_EFI_ERROR (Status);
> +return Status;
>}
> 
>// Disable the CLCD_LcdEn bit
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 10/16] ArmPlatformPkg: Add PCD to select pixel format

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 10/16] ArmPlatformPkg: Add PCD to select pixel
> format
> 
> From: Girish Pathak 
> 
> Current HDLCD and PL111 platform libraries do not support display modes
> with PixelBlueGreenRedReserved8BitPerColor format, i.e. because of
> historical confusion, they do not support the UEFI default
> PixelBlueGreenRedReserved8BitPerColor format
> 
> In LcdPlatformLib for PL111, LcdPlatformQueryMode returns the pixel
> format as PixelRedGreenBlueReserved8BitPerColor which is wrong, because
> that does not match the display controller's pixel format which is set to
> BGR in PL111Lcd LcdHwLib.
> 
> Also it is not possible to configure pixel format as RGB/BGR for the display
> modes for a platform at build time.
> 
> This change adds PcdGopPixelFormat to configure pixel format as
> PixelRedGreenBlueReserved8BitPerColoror
> PixelBlueGreenRedReserved8BitPerColoror
> PixelBitMask.
> With this change, pixel format can be selected in the platform specific .dsc
> file for all supported display modes.
> 
> Support for PixelBitMask is not implemented in PL111 or HDLCD LcdHwLib
> libraries, hence  HDLCD and PL111 platform libraries will return error
> EFI_UNSUPPORTED if PcdGopPixelFormat is set to PixelBitMask.  Indeed, it
> is not clear what selecting PixelBitMask might mean, but the option is
> allowed as it might suit a custom platform.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  ArmPlatformPkg/ArmPlatformPkg.dec  |  9 +++-
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 54 +++-
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 15 +-
>  3 files changed, 40 insertions(+), 38 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index
> 7cec775abeee219e6821488a2c5abe88d23bbed1..378bee9cbc9e4bd50c37
> b38156016424e24cba73 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -1,6 +1,6 @@
>  #/** @file
>  #
> -#  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
> +#  Copyright (c) 2011-2018, ARM Limited. All rights reserved.
>  #  Copyright (c) 2015, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials @@ -97,6 +97,13 @@
> [PcdsFixedAtBuild.common]
> 
> gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x|
> UINT32|0x0028
> 
> gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x|UI
> NT32|0x0029
> 
> +  # Graphics Output Pixel format
> +  # 0 : PixelRedGreenBlueReserved8BitPerColor
> +  # 1 : PixelBlueGreenRedReserved8BitPerColor
> +  # 2 : PixelBitMask
> +  # Default is set to UEFI console font format
> + PixelBlueGreenRedReserved8BitPerColor
> +
> +
> gArmPlatformTokenSpaceGuid.PcdGopPixelFormat|0x0001|UINT32|0
> x0
> + 040
> +
>  [PcdsFixedAtBuild.common,PcdsDynamic.common]
>## PL031 RealTimeClock
> 
> gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> index
> f5886848ce582b475b597ccca015c816707ade0e..96f2bf437fbabd2509f86
> 0c67c5442def5b5f03d 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> @@ -22,31 +22,7 @@
> 
>  #include "HdLcd.h"
> 
> -STATIC
> -UINTN
> -GetBytesPerPixel (
> -  IN  LCD_BPP   Bpp
> -  )
> -{
> -  switch (Bpp) {
> -  case LCD_BITS_PER_PIXEL_24:
> -return 4;
> -
> -  case LCD_BITS_PER_PIXEL_16_565:
> -  case LCD_BITS_PER_PIXEL_16_555:
> -  case LCD_BITS_PER_PIXEL_12_444:
> -return 2;
> -
> -  case LCD_BITS_PER_PIXEL_8:
> -  case LCD_BITS_PER_PIXEL_4:
> -  case LCD_BITS_PER_PIXEL_2:
> -  case LCD_BITS_PER_PIXEL_1:
> -return 1;
> -
> -  default:
> -return 0;
> -  }
> -}
> +#define BYTES_PER_PIXEL 4
> 
>  /** Initialize display.
> 
> @@ -78,10 +54,6 @@ LcdInitialize (
>  HDLCD_LITTLE_ENDIAN | HDLCD_4BYTES_PER_PIXEL
>  );
> 
> -  MmioWrite32 (HDLCD_REG_RED_SELECT,   (0 << 16 | 8 << 8 | 0));
> -  MmioWrite32 (HDLCD

Re: [edk2] [PATCH v3 11/16] ArmPlatformPkg: PCD to swap red/blue format for HDLCD

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 11/16] ArmPlatformPkg: PCD to swap red/blue
> format for HDLCD
> 
> From: Girish Pathak 
> 
> This change adds a new PCD PcdArmHdlcdSwapBlueRedSelect to swap
> values for HDLCD RED_SELECT and BLUE_SELECT registers on platforms
> where blue and red hardware lines are swapped.
> 
> If set to TRUE in the platform dsc, HDLCD library will swap the values while
> setting RED_SELECT and BLUE_SELECT registers. The default value of the
> PCD is FALSE.
> 
> NOTE: The motive for this is that a discrepancy in the Red/Blue lines exists
> between some VersatileExpress platforms.  Rather than have divergent code,
> this build switch allows a simple, pragmatic solution.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
> 
> Notes:
> v3:
> - Please don't nest CPP and C conditionals like this.
>   It is difficult to follow, and results in poor build
>   time coverage (the non-taken branch at the CPP level
>   is never seen by the compiler)   [Ard]
> 
>   Done [Girish]
> 
>  ArmPlatformPkg/ArmPlatformPkg.dec  |  3 +++
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 11 ++-
>  ArmPlatformPkg/Library/HdLcd/HdLcd.inf |  4 +++-
>  3 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec
> b/ArmPlatformPkg/ArmPlatformPkg.dec
> index
> 378bee9cbc9e4bd50c37b38156016424e24cba73..5231ea822f05c2f281a6
> 190d6eae0fc7d0bc0cb3 100644
> --- a/ArmPlatformPkg/ArmPlatformPkg.dec
> +++ b/ArmPlatformPkg/ArmPlatformPkg.dec
> @@ -104,6 +104,9 @@ [PcdsFixedAtBuild.common]
># Default is set to UEFI console font format
> PixelBlueGreenRedReserved8BitPerColor
> 
> gArmPlatformTokenSpaceGuid.PcdGopPixelFormat|0x0001|UINT32|0
> x0040
> 
> +  ## If set, this will swap settings for HDLCD RED_SELECT and
> + BLUE_SELECT registers
> +
> +
> gArmPlatformTokenSpaceGuid.PcdArmHdLcdSwapBlueRedSelect|FALSE|BO
> OLEAN|
> + 0x0045
> +
>  [PcdsFixedAtBuild.common,PcdsDynamic.common]
>## PL031 RealTimeClock
> 
> gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> index
> 96f2bf437fbabd2509f860c67c5442def5b5f03d..5396dde3ba6cd147a8333
> 241a9bc71ab05d7fee3 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> @@ -73,6 +73,8 @@ LcdSetMode (
>SCAN_TIMINGS  *Horizontal;
>SCAN_TIMINGS  *Vertical;
> 
> +  EFI_GRAPHICS_PIXEL_FORMAT  PixelFormat;
> +
>EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  ModeInfo;
> 
>// Set the video mode timings and other relevant information @@ -96,7
> +98,14 @@ LcdSetMode (
>  return Status;
>}
> 
> -  if (ModeInfo.PixelFormat == PixelBlueGreenRedReserved8BitPerColor) {
> +  // By default PcdArmHdLcdSwapBlueRedSelect is set to false  //
> + However on the Juno platform HW lines for BLUE and RED are swapped  //
> + Therefore PcdArmHdLcdSwapBlueRedSelect is set to TRUE for the Juno
> + platform  PixelFormat = FixedPcdGetBool
> (PcdArmHdLcdSwapBlueRedSelect)
> +? PixelRedGreenBlueReserved8BitPerColor
> +: PixelBlueGreenRedReserved8BitPerColor;
> +
> +  if (ModeInfo.PixelFormat == PixelFormat) {
>  MmioWrite32 (HDLCD_REG_RED_SELECT,  (8 << 8) | 16);
>  MmioWrite32 (HDLCD_REG_BLUE_SELECT, (8 << 8) | 0);
>} else {
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
> index
> 67aad05d210b95b2d23b8e52e4392685efcf3795..7f2ba7bf1c602f4c214ea
> caa6425bf9ec7e6da15 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
> @@ -2,7 +2,7 @@
>  #
>  #  Component description file for HDLCD module  # -#  Copyright (c) 2011-
> 2012, ARM Ltd. All rights reserved.
> +#  Copyright (c) 2011-2018, ARM Ltd. All rights reserved.
>  #
>  #  This program and the accompanying materials  #  are licensed and made
> available under the terms and conditions of the BSD License @@ -40,3
> +40,5 @@ [LibraryClasses]
> 
>  [FixedPcd]
>gArmP

Re: [edk2] [PATCH v3 01/16] ArmPlatformPkg: Rectify line endings of LcdHwNullLib

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 01/16] ArmPlatformPkg: Rectify line endings of
> LcdHwNullLib
> 
> This fix changes line endings of LcdHwNullLib.c to DOS style line endings
> from UNIX style line endings to meet the
> EDK2 coding standard. Note it also fixes an end of line whitespace.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  ArmPlatformPkg/Library/LcdHwNullLib/LcdHwNullLib.c | 150
> ++--
>  1 file changed, 75 insertions(+), 75 deletions(-)
> 
> diff --git a/ArmPlatformPkg/Library/LcdHwNullLib/LcdHwNullLib.c
> b/ArmPlatformPkg/Library/LcdHwNullLib/LcdHwNullLib.c
> index
> 2d31b5183c959c88eb1dab7703ec9b87f03eb50f..50e1c88112db69054597
> 9e7d008678c4f8ecd949 100644
> --- a/ArmPlatformPkg/Library/LcdHwNullLib/LcdHwNullLib.c
> +++ b/ArmPlatformPkg/Library/LcdHwNullLib/LcdHwNullLib.c
> @@ -1,75 +1,75 @@
> -/** @file
> -
> -  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
> -
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of the
> BSD License
> -  which accompanies this distribution.  The full text of the license may be
> found at
> -  http://opensource.org/licenses/bsd-license.php
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -
> -**/
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -/**
> -  Check for presence of display
> -
> -  @retval EFI_SUCCESSPlatform implements display.
> -  @retval EFI_NOT_FOUND  Display not found on the platform.
> -
> -**/
> -EFI_STATUS
> -LcdIdentify (
> -  VOID
> -  )
> -{
> -  return EFI_SUCCESS;
> -}
> -
> -/**
> -  Initialize display.
> -
> -  @param  FrameBaseAddress   Address of the frame buffer.
> -  @retval EFI_SUCCESSDisplay initialization success.
> -  @retval !(EFI_SUCCESS) Display initialization failure.
> -
> -**/
> -EFI_STATUS
> -LcdInitialize (
> -  EFI_PHYSICAL_ADDRESS  FrameBaseAddress
> -  )
> -{
> -  return EFI_SUCCESS;
> -}
> -
> -/**
> -  Set requested mode of the display.
> -
> -  @param  ModeNumber Display mode number.
> -  @retval EFI_SUCCESSDisplay set mode success.
> -  @retval EFI_DEVICE_ERROR   If mode not found/supported.
> -
> -**/
> -EFI_STATUS
> -LcdSetMode (
> -  IN UINT32  ModeNumber
> -  )
> -{
> -  return EFI_SUCCESS;
> -}
> -
> -/**
> -  De-initializes the display.
> -**/
> -VOID
> -LcdShutdown (
> -  VOID
> -  )
> -{
> -}
> +/** @file
> +
> +  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
> +
> +  This program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> +  Check for presence of display
> +
> +  @retval EFI_SUCCESSPlatform implements display.
> +  @retval EFI_NOT_FOUND  Display not found on the platform.
> +
> +**/
> +EFI_STATUS
> +LcdIdentify (
> +  VOID
> +  )
> +{
> +  return EFI_SUCCESS;
> +}
> +
> +/**
> +  Initialize display.
> +
> +  @param  FrameBaseAddress   Address of the frame buffer.
> +  @retval EFI_SUCCESSDisplay initialization success.
> +  @retval !(EFI_SUCCESS) Display initialization failure.
> +
> +**/
> +EFI_STATUS
> +LcdInitialize (
> +  EFI_PHYSICAL_ADDRESS  FrameBaseAddress
> +  )
> +{
> +  return EFI_SUCCESS;
> +}
> +
> +/**
> +  Set requested mode of the display.
> +
> +  @param  ModeNumber Display mode number.
> +  @retval EFI_SUCCESSDisplay set mode success.
> +  @retval EFI_DEVICE_ERROR   If mode not found/

Re: [edk2] [PATCH v3 02/16] ArmPlatformPkg: Rectify line endings of LcdPlatformNullLib

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 02/16] ArmPlatformPkg: Rectify line endings of
> LcdPlatformNullLib
> 
> This fix changes line endings of LcdPlatformNullLib.c to DOS style line
> endings from UNIX style line endings to meet the EDK2 coding standard.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c | 184
> ++--
>  1 file changed, 92 insertions(+), 92 deletions(-)
> 
> diff --git
> a/ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c
> b/ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c
> index
> 071eb5ffd4be895a0ce2ed5144f1f99e8195d1a0..b78d9a3bbd3e1fac4238f2
> be961a343020360a32 100644
> --- a/ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c
> +++ b/ArmPlatformPkg/Library/LcdPlatformNullLib/LcdPlatformNullLib.c
> @@ -1,92 +1,92 @@
> -/** @file
> -
> -  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
> -
> -  This program and the accompanying materials
> -  are licensed and made available under the terms and conditions of the
> BSD License
> -  which accompanies this distribution.  The full text of the license may be
> found at
> -  http://opensource.org/licenses/bsd-license.php
> -
> -  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> -  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> -
> -**/
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -EFI_STATUS
> -LcdPlatformInitializeDisplay (
> -  IN EFI_HANDLE   Handle
> -  )
> -{
> -  ASSERT (FALSE);
> -  return EFI_UNSUPPORTED;
> -}
> -
> -EFI_STATUS
> -LcdPlatformGetVram (
> -  OUT EFI_PHYSICAL_ADDRESS* VramBaseAddress,
> -  OUT UINTN*VramSize
> -  )
> -{
> -  ASSERT (FALSE);
> -  return EFI_UNSUPPORTED;
> -}
> -
> -UINT32
> -LcdPlatformGetMaxMode (
> -  VOID
> -  )
> -{
> -  ASSERT (FALSE);
> -  return 0;
> -}
> -
> -EFI_STATUS
> -LcdPlatformSetMode (
> -  IN UINT32 ModeNumber
> -  )
> -{
> -  ASSERT (FALSE);
> -  return EFI_UNSUPPORTED;
> -}
> -
> -EFI_STATUS
> -LcdPlatformQueryMode (
> -  IN  UINT32ModeNumber,
> -  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *Info
> -  )
> -{
> -  ASSERT (FALSE);
> -  return EFI_UNSUPPORTED;
> -}
> -
> -EFI_STATUS
> -LcdPlatformGetTimings (
> -  IN  UINT32  ModeNumber,
> -  OUT UINT32* HRes,
> -  OUT UINT32* HSync,
> -  OUT UINT32* HBackPorch,
> -  OUT UINT32* HFrontPorch,
> -  OUT UINT32* VRes,
> -  OUT UINT32* VSync,
> -  OUT UINT32* VBackPorch,
> -  OUT UINT32* VFrontPorch
> -  )
> -{
> -  ASSERT (FALSE);
> -  return EFI_UNSUPPORTED;
> -}
> -
> -EFI_STATUS
> -LcdPlatformGetBpp (
> -  IN  UINT32ModeNumber,
> -  OUT LCD_BPP*  Bpp
> -  )
> -{
> -  ASSERT (FALSE);
> -  return EFI_UNSUPPORTED;
> -}
> +/** @file
> +
> +  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
> +
> +  This program and the accompanying materials  are licensed and made
> + available under the terms and conditions of the BSD License  which
> + accompanies this distribution.  The full text of the license may be
> + found at  http://opensource.org/licenses/bsd-license.php
> +
> +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +EFI_STATUS
> +LcdPlatformInitializeDisplay (
> +  IN EFI_HANDLE   Handle
> +  )
> +{
> +  ASSERT (FALSE);
> +  return EFI_UNSUPPORTED;
> +}
> +
> +EFI_STATUS
> +LcdPlatformGetVram (
> +  OUT EFI_PHYSICAL_ADDRESS* VramBaseAddress,
> +  OUT UINTN*

Re: [edk2] [PATCH v3 06/16] ArmPlatformPkg: PL111Lcd: Replace magic number with macro

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 06/16] ArmPlatformPkg: PL111Lcd: Replace
> magic number with macro
> 
> From: Girish Pathak 
> 
> Minor code change, replaces magic number with macro in LCD disable.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> index
> cb64c57dd79f3bb1345e4d3dbda7f5b3ce859f40..287e3ca272c0c19f8045a
> 3bf4e69a092d8da6fd8 100644
> --- a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> +++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> @@ -119,8 +119,7 @@ LcdSetMode (
>}
> 
>// Disable the CLCD_LcdEn bit
> -  LcdControl = MmioRead32 (PL111_REG_LCD_CONTROL);
> -  MmioWrite32 (PL111_REG_LCD_CONTROL, LcdControl & ~1);
> +  MmioAnd32 (PL111_REG_LCD_CONTROL, ~PL111_CTRL_LCD_EN);
> 
>// Set Timings
>MmioWrite32 (
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 07/16] ArmPlatformPkg: PL111Lcd: Combine two writes to LCDControl

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 07/16] ArmPlatformPkg: PL111Lcd: Combine
> two writes to LCDControl
> 
> Currenty bit LcdPwr of the LCDControl register is enabled immediately after
> setting other bits of the LCDControl register. This two write sequence is
> unnecessary. This change removes this extra write by setting LcdPwr bit
> along with other bits of the LcdControl register.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> index
> 287e3ca272c0c19f8045a3bf4e69a092d8da6fd8..465cb6845437f57d15f05
> a271d1b01f634e11b56 100644
> --- a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> +++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
> @@ -137,11 +137,7 @@ LcdSetMode (
> 
>// PL111_REG_LCD_CONTROL
>LcdControl = PL111_CTRL_LCD_EN | PL111_CTRL_LCD_BPP (LcdBpp) |
> -   PL111_CTRL_LCD_TFT | PL111_CTRL_BGR;
> -  MmioWrite32 (PL111_REG_LCD_CONTROL, LcdControl);
> -
> -  // Turn on power to the LCD Panel
> -  LcdControl |= PL111_CTRL_LCD_PWR;
> +   PL111_CTRL_LCD_TFT | PL111_CTRL_LCD_PWR |
> + PL111_CTRL_BGR;
>MmioWrite32 (PL111_REG_LCD_CONTROL, LcdControl);
> 
>return EFI_SUCCESS;
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 08/16] ArmPlatformPkg: Implement LcdIdentify function for HDLCD GOP

[Evan Lloyd]

Reviewed-by: Evan Lloyd <evan.ll...@arm.com>

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Girish
> Pathak
> Sent: 20 March 2018 16:12
> To: edk2-devel@lists.01.org
> Cc: nd <n...@arm.com>; Stephanie Hughes-Fitt  f...@arm.com>; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH v3 08/16] ArmPlatformPkg: Implement LcdIdentify
> function for HDLCD GOP
> 
> From: Girish Pathak 
> 
> LcdIdentify function does not currently check presence of HDLCD controller.
> 
> Implement this functionality by reading HDLCD_REG_VERSION and checking
> against the PRODUCT_ID field to detect presence of HDLCD controller.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
> ---
>  ArmPlatformPkg/Library/HdLcd/HdLcd.c | 8 +++-
> ArmPlatformPkg/Library/HdLcd/HdLcd.h | 2 ++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> index
> 28306c530e08b5e0fcef4308435045da3c9e093c..039048398c531ec944bc4
> b43a5551a554a368481 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
> @@ -175,11 +175,17 @@ LcdShutdown (
> 
>@retval EFI_SUCCESSReturns success if platform implements a
> HDLCD
>   controller.
> +  @retval EFI_NOT_FOUND  HDLCD display controller not found on the
> + platform.
>  **/
>  EFI_STATUS
>  LcdIdentify (
>VOID
>)
>  {
> -  return EFI_SUCCESS;
> +  if ((MmioRead32 (HDLCD_REG_VERSION) >> 16) == HDLCD_PRODUCT_ID)
> {
> +return EFI_SUCCESS;
> +  }
> +
> +  return EFI_NOT_FOUND;
>  }
> diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.h
> b/ArmPlatformPkg/Library/HdLcd/HdLcd.h
> index
> cd2c0366c7b563d7fb313f82abeef7eb1aa3ef72..1efa78eedc3013b3ab4615
> 181a59c7d15b851ab5 100644
> --- a/ArmPlatformPkg/Library/HdLcd/HdLcd.h
> +++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.h
> @@ -85,4 +85,6 @@
>  // Number of bytes per pixel
>  #define HDLCD_4BYTES_PER_PIXEL   ((4 - 1) << 3)
> 
> +#define HDLCD_PRODUCT_ID 0x1CDC
> +
>  #endif /* HDLCD_H_ */
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [staging/dynamictables PATCH 1/2] MdePkg: SMMUv3 updates for IORT table definitions

[Evan Lloyd]

> -Original Message-
> From: Sami Mujawar [mailto:sami.muja...@arm.com]
> Sent: 19 March 2018 15:19
> To: edk2-devel@lists.01.org
> Cc: Evan Lloyd <evan.ll...@arm.com>; leif.lindh...@linaro.org; Matteo
> Carlini <matteo.carl...@arm.com>; Stephanie Hughes-Fitt
> <stephanie.hughes-f...@arm.com>; nd <n...@arm.com>
> Subject: [staging/dynamictables PATCH 1/2] MdePkg: SMMUv3 updates for
> IORT table definitions
> 
> Updated the IORT SMMUv3 Node structure and flags to match the IO
> Remapping Table, Platform Design Document, Revision C dated
> 15 MAY 2017.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> Reviewed-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
Reviewed-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  MdePkg/Include/IndustryStandard/IoRemappingTable.h | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/IoRemappingTable.h
> b/MdePkg/Include/IndustryStandard/IoRemappingTable.h
> index
> c113afdd27843111bc7ad6e1de1108260fad2bbc..2e5cb45d7e2ffd4a0559ef
> 706b71874843e3fdbd 100644
> --- a/MdePkg/Include/IndustryStandard/IoRemappingTable.h
> +++ b/MdePkg/Include/IndustryStandard/IoRemappingTable.h
> @@ -4,6 +4,7 @@
> 
> http://infocenter.arm.com/help/topic/com.arm.doc.den0049c/DEN0049C_
> IO_Remapping_Table.pdf
> 
>Copyright (c) 2017, Linaro Limited. All rights reserved.
> +  Copyright (c) 2018, ARM Limited. All rights reserved.
> 
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the
> BSD License @@ -53,6 +54,11 @@
> 
>  #define EFI_ACPI_IORT_SMMUv3_FLAG_COHAC_OVERRIDEBIT0
>  #define EFI_ACPI_IORT_SMMUv3_FLAG_HTTU_OVERRIDE BIT1
> +#define EFI_ACPI_IORT_SMMUv3_FLAG_PROXIMITY_DOMAIN  BIT3
> +
> +#define EFI_ACPI_IORT_SMMUv3_MODEL_GENERIC  0x0
> +#define EFI_ACPI_IORT_SMMUv3_MODEL_HISILICON_HI161X 0x1
> +#define EFI_ACPI_IORT_SMMUv3_MODEL_CAVIUM_CN99XX0x2
> 
>  #define EFI_ACPI_IORT_ROOT_COMPLEX_ATS_UNSUPPORTED  0x0
>  #define EFI_ACPI_IORT_ROOT_COMPLEX_ATS_SUPPORTED0x1
> @@ -165,7 +171,7 @@ typedef struct {
>  } EFI_ACPI_6_0_IO_REMAPPING_SMMU_NODE;
> 
>  ///
> -/// Node type 4: SMMUv4 node
> +/// Node type 4: SMMUv3 node
>  ///
>  typedef struct {
>EFI_ACPI_6_0_IO_REMAPPING_NODE  Node;
> @@ -179,6 +185,9 @@ typedef struct {
>UINT32  Pri;
>UINT32  Gerr;
>UINT32  Sync;
> +  UINT8   ProximityDomain;
> +  UINT8   Reserved1[3];
> +  UINT32  DeviceIdMappingIndex;
>  } EFI_ACPI_6_0_IO_REMAPPING_SMMU3_NODE;
> 
>  ///
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2][platforms/dynamictables] Platform/ARM: Dynamic Tables support for FVP

[Evan Lloyd]

> -Original Message-
> From: Sami Mujawar [mailto:sami.muja...@arm.com]
> Sent: 19 March 2018 15:22
> To: edk2-devel@lists.01.org
> Cc: Arvind Chauhan <arvind.chau...@arm.com>; Daniil Egranov
> <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>; Evan Lloyd <evan.ll...@arm.com>;
> leif.lindh...@linaro.org; Matteo Carlini <matteo.carl...@arm.com>;
> Stephanie Hughes-Fitt <stephanie.hughes-f...@arm.com>; nd
> <n...@arm.com>
> Subject: [PATCH 2/2][platforms/dynamictables] Platform/ARM: Dynamic
> Tables support for FVP
> 
> The dynamic tables framework utilizes the configuration manager protocol
> to get the platform specific information required for building the firmware
> tables.
> 
> The configuration manager is a platform specific component that collates
> the platform hardware information and builds an abstract platform
> configuration repository. The configuration manager also implements the
> configuration manager protocol which returns the hardware information
> requested by the table generators.
> 
> This patch implements the configuration manager support for the FVP
> platform.
> 
> The dynamic tables framework support is configurable and can be enabled
> using the DYNAMIC_TABLES_FRAMEWORK build option.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
Reviewed-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> |  15 +
>  Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
> |  16 +-
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager.
> dsc.inc|  31 +
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager
> Dxe/ConfigurationManager.c  | 607 
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager
> Dxe/ConfigurationManager.h  | 172 ++
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager
> Dxe/ConfigurationManagerDxe.inf |  78 +++
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManager
> Dxe/Platform.h  |  91 +++
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/
> Dsdt.asl   |  77 +++
> 
> Platform/ARM/VExpressPkg/ConfigurationManager/PlatformASLTablesLib/
> PlatformASLTablesLib.inf   |  34 ++
>  9 files changed, 1119 insertions(+), 2 deletions(-)
> 
> diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> index
> cdf9e2d49784d542701dc84eb511f592e77ec106..ed1a16b7b35d9854847e
> 3898f8061abb5261e134 100644
> --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> @@ -38,6 +38,10 @@ [Defines]
>DT_SUPPORT = FALSE
> 
>  !include Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> +!ifdef DYNAMIC_TABLES_FRAMEWORK
> +  !include DynamicTablesPkg/DynamicTables.dsc.inc
> +  !include
> +Platform/ARM/VExpressPkg/ConfigurationManager/ConfigurationManage
> r.dsc.
> +inc
> +!endif
> 
>  [LibraryClasses.common]
>ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> @@ -128,6 +132,15 @@ [PcdsFixedAtBuild.common]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
> +  gArmPlatformTokenSpaceGuid.PL011UartInterrupt|0x25
> +
> +  ## PL011 Serial Debug UART
> +  gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase|0x1c0a
> +  gArmPlatformTokenSpaceGuid.PcdSerialDbgUartBaudRate|115200
> +  gArmPlatformTokenSpaceGuid.PcdSerialDbgUartClkInHz|2400
> +
> +  # SBSA Generic Watchdog
> +  gArmTokenSpaceGuid.PcdGenericWatchdogEl2IntrNum|59
> 
>## PL031 RealTimeClock
>gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x1C17
> @@ -255,8 +268,10 @@ [Components.common]  !endif
>}
> 
> +!ifndef DYNAMIC_TABLES_FRAMEWORK
>MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf
>Platform/ARM/VExpressPkg/AcpiTables/AcpiTables.inf
> +!endif
> 
>ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
>ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.inf
> diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
> b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
> index
> 305e661a2bdc3ade2c16232c77769df5fc6f0c32..db164be9641cf6e315302
> 3752f60f95909ce803c 100644
> --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
> +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.fdf
> @

Re: [edk2] [PATCH 1/2][platforms/dynamictables] Platform/ARM: Dynamic Tables support for Juno

[Evan Lloyd]

> -Original Message-
> From: Sami Mujawar [mailto:sami.muja...@arm.com]
> Sent: 19 March 2018 15:22
> To: edk2-devel@lists.01.org
> Cc: Arvind Chauhan <arvind.chau...@arm.com>; Daniil Egranov
> <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>; Evan Lloyd <evan.ll...@arm.com>;
> leif.lindh...@linaro.org; Matteo Carlini <matteo.carl...@arm.com>;
> Stephanie Hughes-Fitt <stephanie.hughes-f...@arm.com>; nd
> <n...@arm.com>
> Subject: [PATCH 1/2][platforms/dynamictables] Platform/ARM: Dynamic
> Tables support for Juno
> 
> The dynamic tables framework utilizes the configuration manager
> protocol to get the platform specific information required for
> building the firmware tables.
> 
> The configuration manager is a platform specific component that
> collates the platform hardware information and builds an abstract
> platform configuration repository. The configuration manager also
> implements the configuration manager protocol which returns the
> hardware information requested by the table generators.
> 
> This patch implements the configuration manager support for the
> Juno platform.
> 
> The dynamic tables framework support is configurable and can be
> enabled using the DYNAMIC_TABLES_FRAMEWORK build option.
> 
> When DYNAMIC_TABLES_FRAMEWORK is defined, ACPI tables are
> generated
> and installed by the dynamic table framework. Therefore installation
> of ACPI tables from the Firmware Volume (FV) is disabled by this
> option.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
Reviewed-by: Evan Lloyd <evan.ll...@arm.com>
> ---
>  Platform/ARM/JunoPkg/ArmJuno.dsc 
>  |
> 16 +-
>  Platform/ARM/JunoPkg/ArmJuno.fdf 
>  |
> 14 +-
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.i
> nc|  29 +
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/
> ConfigurationManager.c  | 589 
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/
> ConfigurationManager.h  | 156 ++
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/
> ConfigurationManagerDxe.inf |  85 +++
> 
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManagerDxe/
> Platform.h  |  65 +++
> 
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Dsdt
> .asl   | 306 ++
> 
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Platf
> ormASLTablesLib.inf   |  44 ++
> 
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/SsdtJ
> unoUsb.asl| 122 
> 
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Ssdt
> Pci.asl| 218 
> 
> Platform/ARM/JunoPkg/ConfigurationManager/PlatformASLTablesLib/Ssdt
> Uart.asl   |  48 ++
>  Platform/ARM/JunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c
> |   9 +-
>  13 files changed, 1697 insertions(+), 4 deletions(-)
> 
> diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc
> b/Platform/ARM/JunoPkg/ArmJuno.dsc
> index
> 9d7317683ef39ab47429234b98d94c04953b41cb..e75b4848345b83e73aa
> aabea9f5f1dacea5895f6 100644
> --- a/Platform/ARM/JunoPkg/ArmJuno.dsc
> +++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
> @@ -33,6 +33,11 @@ [Defines]
>  # On RTSM, most peripherals are VExpress Motherboard peripherals
>  !include Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc
> 
> +!ifdef DYNAMIC_TABLES_FRAMEWORK
> +!include DynamicTablesPkg/DynamicTables.dsc.inc
> +!include
> Platform/ARM/JunoPkg/ConfigurationManager/ConfigurationManager.dsc.i
> nc
> +!endif
> +
>  [LibraryClasses.common]
>ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
>ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> @@ -71,6 +76,14 @@ [LibraryClasses.common.UEFI_DRIVER,
> LibraryClasses.common.UEFI_APPLICATION, Libr
>  [BuildOptions]
>GCC:*_*_ARM_PLATFORM_FLAGS = -march=armv8-a
> 
> +!ifdef DYNAMIC_TABLES_FRAMEWORK
> +  *_*_*_PLATFORM_FLAGS = -DDYNAMIC_TABLES_FRAMEWORK
> +!endif
> +
> +!ifdef DISABLE_LPI
> +  *_*_*_ASLPP_FLAGS = -DDISABLE_LPI
> +!endif
> +
> 
> ##
> ##
>  #
>  # Pcd Section - list of all EDK II PCD Entries defined by this Platform
> @@ -242,8 +255,9 @@ [Components.common]
># ACPI Support
>#
>MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> +!ifndef DYNAMIC_TABLES_FRAMEWO

[edk2] GOP:Frame Buffer memory type?

[Evan Lloyd]

The EFI_GRAPHICS_OUTPUT_PROTOCOL provides for a frame buffer:
"FrameBufferBase  Base  address of graphics linear frame buffer. Info contains 
information required to allow software to draw directly to the frame buffer 
without using Blt().Offset zero in FrameBufferBase represents the upper left 
pixel of the display."

The spec is silent on how (or if) the frame buffer should appear in the memory 
map.  The obvious option is EfiMemoryMappedIO, however the spec has (Table 29. 
"Memory Type Usage after ExitBootServices") :
"EfiMemoryMappedIO
This memory is not used by the OS. All system memory-mapped IO information 
should come from ACPI tables."
This is slightly problematic because the GOP Frame Buffer is not described in 
an ACPI table.

Most options are obviously unusable (like "EfiBootServicesData  Memory 
available for general use.") as the "available for general use" basically means 
overwritten by OS memory usage, so the pixels corrupt OS data.

So -  can anyone advise us on whether there is some "Standard" way of doing 
this, is this an undefined area, or have we missed something?

Regards,
Evan

Evan Lloyd | Technical Lead for Windows on Arm | Arm
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
m. +44 (0)7825256132
110 Fulbourn Road, Cambridge, CB1 9NJ
Arm.com

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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] AARCH64:Use of EFI_MEMORY_XP

[Evan Lloyd]

Hi Ard.
We still have a minor problem in that the spec disqualifies EFI_MEMORY_XP for 
AARCH64.
Do you have any thoughts on this?
How should we proceed here?  I assume the specification statement was a 
considered decision.
Do we need to get it changed, or is EFI_MEMORY_XP unnecessary?

Regards,
Evan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Evan Lloyd
> Sent: 08 January 2018 18:51
> To: Ard Biesheuvel <ard.biesheu...@linaro.org>
> Cc: "matteo.carl...@arm.com"@arm.com;
> "leif.lindh...@linaro.org"@arm.com; "n...@arm.com"@arm.com; edk2-
> de...@lists.01.org; Arvind Chauhan <arvind.chau...@arm.com>;
> "ard.biesheu...@linaro.org"@arm.com; Thomas Abraham
> <thomas.abra...@arm.com>
> Subject: Re: [edk2] [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg:
> New DP500/DP550/DP650 platform library.
>
>
>
> > -Original Message-----
> > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> > Sent: 23 December 2017 16:07
> > To: Evan Lloyd <evan.ll...@arm.com>
> > Cc: edk2-devel@lists.01.org; Arvind Chauhan
> <arvind.chau...@arm.com>;
> > Daniil Egranov <daniil.egra...@arm.com>; Thomas Abraham
> > <thomas.abra...@arm.com>; "ard.biesheu...@linaro.org"@arm.com;
> > "leif.lindh...@linaro.org"@arm.com;
> > "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> > Subject: Re: [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg: New
> > DP500/DP550/DP650 platform library.
> >
...
> > > +  // Mark the VRAM as write-combining. The VRAM is inside the DRAM,
> > > + which is  // cacheable, for ARM/AArch64 EFI_MEMORY_WC memory
> is
> > actually uncached.
> > > +  Status = gDS->SetMemorySpaceAttributes (
> > > +  *VramBaseAddress,
> > > +  *VramSize,
> > > +  EFI_MEMORY_WC
> >
> > Please add EFI_MEMORY_XP here
> >
>
>  [[Evan Lloyd]] We can do that, happily.  However, in looking at this we
> found that the UEFI spec has in "2.3.6 AArch64 Platforms", section "2.3.6.1
> Memory types":
> EFI_MEMORY_XP, ...
>  Not used
> or defined
>
> Does that suggest we need a minor spec update?
>
> > > +  );
...
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg: Add and update debug ASSERTS

[Evan Lloyd]

In that case, would you be happy to take Girish's patches with the ASSERTs done 
your (our) way?
Leif can fulminate about it when he gets back, if he really feels that strongly.
I suspect, though, that Leif is capable of being reasonable if pressed (and 
offered beer at Plugfest).

Regards,
Evan

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 02 March 2018 19:07
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: leif.lindh...@linaro.org; Girish Pathak <girish.pat...@arm.com>;
> Matteo Carlini <matteo.carl...@arm.com>; nd <n...@arm.com>; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg:
> Add and update debug ASSERTS
> 
> On 28 February 2018 at 20:27, Evan Lloyd <evan.ll...@arm.com> wrote:
> > Hi Leif, Ard.
> > Can I get you two argue out the pros and cons of the "ASSERT(FALSE)"
> debate, please.
> 
> I can argue the cons if you like. For the pros, you'll have to wait for Leif 
> to
> return from holiday (in a week or two AFAIK)
> 
> > (see
> > https://lists.01.org/pipermail/edk2-devel/2018-January/019788.html)
> > For what it is worth, our (surprisingly unanimous) opinion is that, since
> the ASSERT is only there to help spot a problem, then the more information
> reported the better.  The only benefits of ASSERT(FALSE) would be a smaller
> debug image and minor efficiency improvement on the path to the crash.
> >
> > Regards,
> > Evan
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 04 January 2018 19:55
> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> Cc: Girish Pathak <girish.pat...@arm.com>; Matteo Carlini
> >> <matteo.carl...@arm.com>; nd <n...@arm.com>; edk2-
> de...@lists.01.org;
> >> Thomas Abraham <thomas.abra...@arm.com>; Arvind Chauhan
> >> <arvind.chau...@arm.com>; leif.lindh...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg:
> >> Add and update debug ASSERTS
> >>
> >> On 4 January 2018 at 19:51, Evan Lloyd <evan.ll...@arm.com> wrote:
> >> >
> >> >
> >> >> -Original Message-
> >> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> >> Sent: 04 January 2018 19:24
> >> >> To: Girish Pathak <girish.pat...@arm.com>
> >> >> Cc: Evan Lloyd <evan.ll...@arm.com>; Matteo Carlini
> >> >> <matteo.carl...@arm.com>; nd <n...@arm.com>; edk2-
> >> de...@lists.01.org;
> >> >> Thomas Abraham <thomas.abra...@arm.com>; Arvind Chauhan
> >> >> <arvind.chau...@arm.com>; leif.lindh...@linaro.org
> >> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18]
> ARM/VExpressPkg:
> >> >> Add and update debug ASSERTS
> >> >>
> >> >> On 4 January 2018 at 18:55, Girish Pathak <girish.pat...@arm.com>
> >> >> wrote:
> >> >> > Hi Ard,
> >> >> >
> >> >> >> -Original Message-
> >> >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> >> >> >> Behalf Of Ard Biesheuvel
> >> >> >> Sent: 23 December 2017 14:12
> >> >> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> >> >> Cc: "matteo.carl...@arm.com"@arm.com;
> >> >> >> "leif.lindh...@linaro.org"@arm.com; "n...@arm.com"@arm.com;
> >> edk2-
> >> >> >> de...@lists.01.org; Thomas Abraham
> <thomas.abra...@arm.com>;
> >> >> Arvind
> >> >> >> Chauhan <arvind.chau...@arm.com>;
> >> >> "ard.biesheu...@linaro.org"@arm.com
> >> >> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18]
> >> ARM/VExpressPkg:
> >> >> >> Add and update debug ASSERTS
> >> >> >>
> >> >> >> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> >> >> >> > From: Girish Pathak 
> >> >> >> >
> >> >> >> > This change adds some debug assertions e.g to catch NULL
> >> >> >> > pointer errors missing in PL11Lcd and HdLcd platform libraries.
> >> >> >> >
> >> >> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> >> > Signed-of

Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg: Add and update debug ASSERTS

[Evan Lloyd]

Hi Leif, Ard.
Can I get you two argue out the pros and cons of the "ASSERT(FALSE)" debate, 
please.
(see https://lists.01.org/pipermail/edk2-devel/2018-January/019788.html)
For what it is worth, our (surprisingly unanimous) opinion is that, since the 
ASSERT is only there to help spot a problem, then the more information reported 
the better.  The only benefits of ASSERT(FALSE) would be a smaller debug image 
and minor efficiency improvement on the path to the crash.

Regards,
Evan

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 04 January 2018 19:55
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: Girish Pathak <girish.pat...@arm.com>; Matteo Carlini
> <matteo.carl...@arm.com>; nd <n...@arm.com>; edk2-devel@lists.01.org;
> Thomas Abraham <thomas.abra...@arm.com>; Arvind Chauhan
> <arvind.chau...@arm.com>; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg:
> Add and update debug ASSERTS
> 
> On 4 January 2018 at 19:51, Evan Lloyd <evan.ll...@arm.com> wrote:
> >
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 04 January 2018 19:24
> >> To: Girish Pathak <girish.pat...@arm.com>
> >> Cc: Evan Lloyd <evan.ll...@arm.com>; Matteo Carlini
> >> <matteo.carl...@arm.com>; nd <n...@arm.com>; edk2-
> de...@lists.01.org;
> >> Thomas Abraham <thomas.abra...@arm.com>; Arvind Chauhan
> >> <arvind.chau...@arm.com>; leif.lindh...@linaro.org
> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg:
> >> Add and update debug ASSERTS
> >>
> >> On 4 January 2018 at 18:55, Girish Pathak <girish.pat...@arm.com>
> >> wrote:
> >> > Hi Ard,
> >> >
> >> >> -Original Message-
> >> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On
> >> >> Behalf Of Ard Biesheuvel
> >> >> Sent: 23 December 2017 14:12
> >> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> >> Cc: "matteo.carl...@arm.com"@arm.com;
> >> >> "leif.lindh...@linaro.org"@arm.com; "n...@arm.com"@arm.com;
> edk2-
> >> >> de...@lists.01.org; Thomas Abraham <thomas.abra...@arm.com>;
> >> Arvind
> >> >> Chauhan <arvind.chau...@arm.com>;
> >> "ard.biesheu...@linaro.org"@arm.com
> >> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18]
> ARM/VExpressPkg:
> >> >> Add and update debug ASSERTS
> >> >>
> >> >> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> >> >> > From: Girish Pathak 
> >> >> >
> >> >> > This change adds some debug assertions e.g to catch NULL pointer
> >> >> > errors missing in PL11Lcd and HdLcd platform libraries.
> >> >> >
> >> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> >> >> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> >> >> > ---
> >> >> >
> >> >>
> >>
> Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExp
> >> r
> >> >> ess.c   | 22 +-
> >> >> >
> >> >> >
> >> >>
> >>
> Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdAr
> >> m
> >> >> VEx
> >> >> > press.c | 24 +++-
> >> >> >  2 files changed, 44 insertions(+), 2 deletions(-)
> >> >> >
> >> >> > diff --git
> >> >> >
> >> >>
> >>
> a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVE
> >> x
> >> >> pres
> >> >> > s.c
> >> >> >
> >> >>
> >>
> b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVE
> >> x
> >> >> pres
> >> >> > s.c index
> >> >> >
> >> >>
> >>
> 6afd764897f49c64490ce891682f99bb0f5d993b..a8fe8696da0653017ce9fa
> >> 6e4a
> >> >> 86
> >> >> > caf283bc04c9 100644
> >> >> > ---
> >> >> >
> >> >>
> >>
> a/Platform/ARM/VExpressPkg/Library/HdLcdAr

[edk2] [PATCH] Platform/ARM: Fix flash alignment access

[evan . lloyd]

From: Alexei Fedorov <alexei.fedo...@arm.com>

Flash memory is mapped as device memory and should use only aligned
accesses.
Update VariableRuntimeDxe from using BaseMemoryLibOptDxe to the generic
BaseMemoryLib which provides aligned memory access only.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Alexei Fedorov <alxei.fedo...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/JunoPkg/ArmJuno.dsc | 1 +
 Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc| 3 ++-
 Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 
5c2a29fe8330bbf308e31e34b617517a5aebcf6d..9d7317683ef39ab47429234b98d94c04953b41cb
 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -234,6 +234,7 @@ [Components.common]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   }
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
 
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
index 
1f612cc282eb8bf4fdc74ff0933c36ecf70c6daf..6c6c8d3938e61abf7456b4c2cd6b464c0238353b
 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-CTA15-A7.dsc
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2012-2015, ARM Limited. All rights reserved.
+#  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
 #  Copyright (c) 2015, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
@@ -215,6 +215,7 @@ [Components.common]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   }
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc 
b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
index 
3dbc105f6f8a565da34807508ac8178e4d524e41..295e9a126b0ebaa4653d7e25e2f7d8c396403764
 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
+++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
@@ -224,6 +224,7 @@ [Components.common]
   MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
 
   NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   }
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 13/13] ArmPlatformPkg: Introduce SCMI protocol

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 December 2017 14:06
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH v2 13/13] ArmPlatformPkg: Introduce SCMI protocol
>
> , couOn 22 December 2017 at 18:34,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak <girish.pat...@arm.com>
> >
> > This change introduces a new SCMI protocol driver for
> > Arm Platforms. The driver currently supports only clock
> > and performance management protocols. Other protocols
> > will be added as and when needed.
> >
> > Clock management protocol is used to configure the HDLCD clock
> > on Juno platforms.
> >
> > Whereas performance management protocol allows adjustment
> > of various performance domains to evaluate performance of the
> > Juno platform.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> > ---
...
> > +
> > +#ifndef ARM_SCMI_BASE_PROTOCOL_PRIVATE_H_
> > +#define ARM_SCMI_BASE_PROTOCOL_PRIVATE_H_
> > +
> > +// Return values of BASE_DISCOVER_LIST_PROTOCOLS command.
> > +typedef struct {
> > +  UINT32 NumProtocols;
> > +  // Array of four protocols in each element
> > +  // Total elements = 1 + (NumProtocols-1)/4
> > +  UINT8 Protocols[];
>
> For paleontological reasons, EDK2 code does not allow arrays of
> unspecified length at the end of a struct. I don't know which version
> of which toolchain used to be the issue here, and I would be surprised
> if anyone went through the trouble of writing that down, but it is the
> reason that EDK2 only allows a [1] array, and hence care needs to be
> taken to add/substract 1 as appropriate when sizing the variable.

 [[Evan Lloyd]] Whilst not disputing your claim, we have failed to find any 
such restriction in the coding standard.  Do you have a reference?

>
> So now, it's my turn to cut /you/ a deal here. If you stop whingeing
> about frivolous patches that only move whitespace around or change //
> for /*, or move ASSERT()s into if () conditions on cold-as-ice code
> paths, I am not going to complain about the arrays of unspecified
> length in this patch, simply because I don't take the coding standard
> as gospel, and feel that the Tianocore could do with a bit more
> pragmatism when it comes to matters like these.

 [[Evan Lloyd]] I'm happy to take the deal.  You know why some of the 
formatting changes are there, and why the ASSERT moves are relevant, so I can't 
promise we'll stop doing it.

>
>
> > +} BASE_DISCOVER_LIST;
> > +
> > +#endif /* ARM_SCMI_BASE_PROTOCOL_PRIVATE_H_ */
> > diff --git
> a/ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
> b/ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
> > new file mode 100644
> > index
> ..2807b6b476ac1b8cf8
> 21a29ca7a59a78e9188c52
> > --- /dev/null
> > +++
> b/ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h

> > +
> > +#endif /* SCMI_PRIVATE_H_ */
> > diff --git a/ArmPlatformPkg/Include/Drivers/ArmScmi.h
> b/ArmPlatformPkg/Include/Drivers/ArmScmi.h
>
> Please don't put stuff in Include/Drivers.
>
> Things derived from industry specs belong in Include/IndustryStandard,
> but given that this header only defines SCMI_MAX_STR_LEN, could you
> move it into the protocol header instead?

 [[Evan Lloyd]] Can do.  However, this point raises some interesting thoughts.
e.g. Does SBBR count as an "Industry" standard?  How about SCMI?
Also, I believe we aim to eventually put ArmPlatformPkg out of our misery.
So, would the SCMI driver belong in ArmPkg (as an arm ATG standard), or should 
it be in edk2-platforms?

>
>
> > new file mode 100644
> > index
> 0000..04ea3de5b34157ed45
> 9ee47440abbcaa7114e93a
> > --- /dev/null
> > +++ b/ArmPlatformPkg/Include/Drivers/ArmScmi.h
> > @@ -0,0 +1,27 @@
...
> > diff --git a/ArmPlatformPkg/Include/Drivers/ArmScmiBaseProtocol.h
> b/ArmPlatformPkg/Include/Drivers/ArmScmiBaseProtocol.h
>
> This belongs in Include/Protocol, and needs to be declared in the
> package .dec file as well, along with its GUID.
>

 [[Evan Lloyd]]   We can do that, but can I check that is actually what you 
want.
This file relates to an SCMI (communications) protocol definition, not a UEFI 
protocol (although Girish has used t

Re: [edk2] [PATCH edk2-platforms v2 18/18] ARM/JunoPkg: Add HDLCD platform library

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 December 2017 16:23
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; Arvind Chauhan <arvind.chau...@arm.com>;
> Daniil Egranov <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH edk2-platforms v2 18/18] ARM/JunoPkg: Add HDLCD
> platform library
>
> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak <girish.pat...@arm.com>
> >
> > This change adds the HDLCD platform lib for the Juno plaform. This
> > library will be instantiated as a LcdPlatformLib to link with
> > LcdGraphicsOutputDxe for the Juno platform.
> >
> > HDLCD platform library depends on the Arm SCMI DXE driver for
> > communication with the SCP for clock setting. Therefore this change
> > also enables building of Arm SCMI DXE driver for the Juno platform.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
>
> Missing signoff?
[[Evan Lloyd]] Yes.  Oops.

>
> > ---
> >  Platform/ARM/JunoPkg/ArmJuno.dec |   8 +
> >  Platform/ARM/JunoPkg/ArmJuno.dsc |  29 +
> >  Platform/ARM/JunoPkg/ArmJuno.fdf |  12 +-
> >  Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf   |   5 +-
> >  Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf
> |  40 ++
> >  Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c |
> 18 +-
> >  Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJuno.c  |
> 559 
> >  7 files changed, 668 insertions(+), 3 deletions(-)
> >
> > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec
> > b/Platform/ARM/JunoPkg/ArmJuno.dec
> > index
> >
> b733480c3198d135df16ca024b5e85ff350e11c7..cd6710feb2faf0bd17b5ea
> 39a21d
> > be5406cd4ffd 100644
> > --- a/Platform/ARM/JunoPkg/ArmJuno.dec
> > +++ b/Platform/ARM/JunoPkg/ArmJuno.dec
> > @@ -53,3 +53,11 @@ [PcdsFixedAtBuild.common]
> >
> gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxBase|0x2E00|UINT64|0
> x0025
> >
> gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxSize|0x80|UINT32|0x0
> 026
> >
> > +  # MaxMode must be one number higher than the actual max mode,  #
> > + i.e. for actual maximum mode 2, set the value to 3.
> > +  #
> > +  # Default value zero allows platform to enumerate maximum
> supported mode.
> > +  #
> > +  # For a list of mode numbers look in HdLcdArmJuno.c
> > +
> gArmJunoTokenSpaceGuid.PcdArmHdLcdMaxMode|0|UINT32|0x001
> 7
> > +
> > diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc
> > b/Platform/ARM/JunoPkg/ArmJuno.dsc
> > index
> >
> fe860956a4dc497cac52be70bab3657246a08bd0..9027c5b0728a6941f850
> 636b3bc3
> > 15fd33b867fb 100644
> > --- a/Platform/ARM/JunoPkg/ArmJuno.dsc
> > +++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
> > @@ -50,6 +50,11 @@ [LibraryClasses.common]
> ># SCMI Mailbox Transport Layer
> >ArmMtl|Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
> >
> > +!ifndef HEADLESS_PLATFORM
>
> Wouldn't it make more sense to add a macro ENABLE_HDLCD, rather than
> inverting the logic?

 [[Evan Lloyd]] We used this to correspond with the ACPI (FADT) terminology, 
where HEADLESS implies more than just no display (e.g. no keyboard or mouse).
It would be possible to insert another level to define ENABLE_HDLCD, 
ENABLE_KEYBOARD, and ENABLE_MOUSE when  HEADLESS_PLATFORM is not defined, but 
I'm not convinced that would improve clarity.
For mobile platforms (Juno, say) the default seems obvious, as a mobile without 
MMI is pretty pointless (unless you contemplate UEFI on IOT?).  For servers, 
less so, but the option is still available.  It also seems more natural to 
explicitly exclude support for hardware that is present, rather than defaulting 
to a crippled state.


>
> > +
> >
...
> > +  # SCMI Driver
> > +  ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf {
> > +
> > +
> BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
>
> I take it your trusted SRAM does not tolerate unaligned memcpy() because
> it is mapped as device memory. Couldn't you map it as non-cacheable
> memory instead? (I meant to ask in response to the other patch but I forgot)
>

 [[Evan Lloyd]]  As this is generic cod

Re: [edk2] [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg: New DP500/DP550/DP650 platform library.

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 December 2017 16:07
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; Arvind Chauhan <arvind.chau...@arm.com>;
> Daniil Egranov <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg: New
> DP500/DP550/DP650 platform library.
>
> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak 
> >
...
> > +
> > +/* Internal helper function to allocate memory if memory is not
> > +already
> > +  reserved for framebuffer
> > +
> > +  @param[in]  VramSize  Requested framebuffer size in bytes.
> > +  @param[out] VramBaseAddress   Pointer to memory allocated for
> framebuffer.
> > +
> > +  @retval EFI_SUCCESS   Framebuffer memory allocated successfully.
> > +  @retval EFI_UNSUPPORTED   Allocated address wider than 40 bits.
> > +  @retval !EFI_SUCCESS  Other errors.
> > +**/
> > +STATIC
> > +EFI_STATUS
> > +GetVram (
> > +  IN  UINTN CONST  VramSize,
> > +  OUT EFI_PHYSICAL_ADDRESS *CONST  VramBaseAddress
> > +  )
> > +{
> > +  EFI_STATUS Status;
> > +
> > +  // Check if memory is already reserved for the framebuffer.
> > +#if (FixedPcdGet64 (PcdArmLcdDdrFrameBufferBase) != 0)
> > +
>
> Please don't use CPP conditionals for control flow
>
> > +#if (!DP_VALID_BASE_ADDR (FixedPcdGet64
> > +(PcdArmLcdDdrFrameBufferBase))) #error ARM Mali DP framebuffer
> base address cannot be wider than 40 bits.
> > +#else
> > +  *VramBaseAddress =
> > +(EFI_PHYSICAL_ADDRESS)FixedPcdGet64
> > +(PcdArmLcdDdrFrameBufferBase);
> > +
> > +  Status = EFI_SUCCESS;
> > +#endif
> > +
> > +#else
> > +  // If not already reserved, attempt to allocate the VRAM from the
> DRAM.
> > +  Status = gBS->AllocatePages (
> > +  AllocateAnyPages,
> > +  EfiBootServicesData,
> > +  EFI_SIZE_TO_PAGES (*VramSize),
> > +  VramBaseAddress
> > +  );
> > +  if (EFI_ERROR (Status)) {
> > +DEBUG ((DEBUG_ERROR, "ArmMaliDpLib: Failed to allocate
> framebuffer.\n"));
> > +ASSERT (FALSE);
> > +return Status;
> > +  }
> > +
> > +  // ARM Mali DP framebuffer base address can not be wider than 40 bits.
> > +  if (!DP_VALID_BASE_ADDR (*VramBaseAddress)) {
> > +gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES
> (*VramSize));
> > +    ASSERT (DP_VALID_BASE_ADDR (*VramBaseAddress));
> > +return EFI_UNSUPPORTED;
> > +  }
> > +
> > +  // Mark the VRAM as write-combining. The VRAM is inside the DRAM,
> > + which is  // cacheable, for ARM/AArch64 EFI_MEMORY_WC memory is
> actually uncached.
> > +  Status = gDS->SetMemorySpaceAttributes (
> > +  *VramBaseAddress,
> > +  *VramSize,
> > +  EFI_MEMORY_WC
>
> Please add EFI_MEMORY_XP here
>

 [[Evan Lloyd]] We can do that, happily.  However, in looking at this we found 
that the UEFI spec has in "2.3.6 AArch64 Platforms", section "2.3.6.1 Memory 
types":
EFI_MEMORY_XP, ...  
   Not used or defined

Does that suggest we need a minor spec update?

> > +  );
> > +  if (EFI_ERROR (Status)) {
> > +ASSERT (FALSE);
> > +gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES
> (*VramSize));
> > +  }
> > +#endif
> > +
> > +  return Status;
> > +}
> > +
> > +/** Allocate VRAM memory in DRAM for the framebuffer
> > +  (unless it is reserved already).
> > +
> > +  The allocated address can be used to set the framebuffer as a base
> > + buffer  address for any layer of the ARM Mali DP.
> > +
> > +  @param[out] VramBaseAddress A pointer to the framebuffer
> address.
> > +  @param[out] VramSizeA pointer to the size of the frame
> > +  buffer in bytes
> > +
> > +  @retval EFI_SUCCESS Frame buffer memory allocation success.
> > +  @retval EFI_UNSUPPORTED Allocated address wider than 40 bits
> > +  @retval !EFI_SUCCESSOther errors.
> > +

Re: [edk2] [edk2-CCodingStandardsSpecification PATCH 4/5] Fix Chapter 4 Typo

[Evan Lloyd]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 03 January 2018 16:56
> To: Evan Lloyd <evan.ll...@arm.com>; edk2-devel@lists.01.org
> Cc: "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "ler...@redhat.com"@arm.com;
> "liming@intel.com"@arm.com;
> "michael.d.kin...@intel.com"@arm.com;
> "jordan.l.jus...@intel.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [edk2-CCodingStandardsSpecification PATCH 4/5] Fix Chapter 4
> Typo
>
> On 01/03/18 12:22, evan.ll...@arm.com wrote:
> > From: Evan Lloyd <evan.ll...@arm.com>
> >
> > 4.1.3.2 - remove "See" from 'as specified in See "File Heading"'
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
> >  4_naming_conventions/README.md | 418 ++--
> >  1 file changed, 209 insertions(+), 209 deletions(-)
>
> Looks like this file underwent a line terminator conversion as well.
>
> If the file is currently not using CRLF, then I agree it should be converted;
> however, the conversion should be please separated from the typo fix.
>
> ... Hmm, the file already seems to use CRLF. So I think the conversion was to
> LF, and must have been unintended.

 [[Evan Lloyd]] It certainly was unintended, and seems to be an artefact of a 
core.autocrlf setting change.  Sorry.

>
> Can you please resubmit without the line terminator changes?
[[Evan Lloyd]] Will do.
>
> Thanks!
> Laszlo
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-CCodingStandardsSpecification PATCH 5/5] Fix Chapter 5 Typos

[Evan Lloyd]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 03 January 2018 17:08
> To: Evan Lloyd <evan.ll...@arm.com>; edk2-devel@lists.01.org
> Cc: "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "ler...@redhat.com"@arm.com;
> "liming@intel.com"@arm.com;
> "michael.d.kin...@intel.com"@arm.com;
> "jordan.l.jus...@intel.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [edk2-CCodingStandardsSpecification PATCH 5/5] Fix Chapter 5
> Typos
>
> On 01/03/18 12:22, evan.ll...@arm.com wrote:
> > From: Evan Lloyd <evan.ll...@arm.com>
> >
> > 5.1.1 - Replace "less" with "fewer" (because columns is plural and
> > countable)
> > 5.1.5 - Correct tense.  (because the C specification still defines...)
> > Insert full stop.
> > Insert comma.
> > 5.1.8 - Correct "provided" to "proven".
> > 5.1.9 - remove hanging "This."
> > 5.2.3.1 - replace "is comprised of" with "comprises" (comprise means
> >   "consists of", so "comprised of" is a solecism.
> >   Remove use of tab, as they are forbidden.
> >   Remove -- before date in copyright header (None of the edk2
> >   files have it).
> > 5.4 - Add indent to comment text.
> > 5.6.1.2 - Fix copy/paste text (from UEFI spec).
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
> >  5_source_files/52_spacing.md|  9 +
> >  5_source_files/54_code_file_structure.md|  4 ++--
> >  5_source_files/56_declarations_and_types.md |  4 ++--
> >  5_source_files/README.md| 18 +-
> >  4 files changed, 18 insertions(+), 17 deletions(-)
> >
> > diff --git a/5_source_files/52_spacing.md
> > b/5_source_files/52_spacing.md index
> >
> ddeabf7753a8713bf04e143d6e2e9bccf881f691..3c79f4e4ee91bcd4035d6c
> f7d8d3
> > 2f1bb9c7756f 100644
> > --- a/5_source_files/52_spacing.md
> > +++ b/5_source_files/52_spacing.md
> > @@ -249,7 +249,7 @@ And the comment will end with:
> >  **/
> >  ```
> >
> > -The File Heading comment block is comprised of the following
> > sections: File
> > +The File Heading comment block comprises the following sections: File
> >  Description, Copyright, License, and the optional Specification
> > Reference and  Glossary sections.
> >
> > @@ -266,8 +266,9 @@ Glossary sections.
> >  **/
> >  ```
> >
> > -The following example begins each body line with a tab (two spaces).
> > This is -the preferred indentation, but two tabs (four spaces) is also
> acceptable.
> > +The following example begins each body line with an indent (two spaces).
> > +This is the preferred indentation, but a double indent (four spaces)
> > +is also acceptable.
> >
> >   Example
> >
> > @@ -278,7 +279,7 @@ the preferred indentation, but two tabs (four
> spaces) is also acceptable.
> >Detailed description of the file’s contents and other useful
> >information for a person viewing the file for the first time.
> >
> > -  Copyright (C) --20XX, Acme Corporation. All rights reserved.
> > +  Copyright (C) 20XX, Acme Corporation. All rights reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> >the BSD License which accompanies this distribution. The full diff
> > --git a/5_source_files/54_code_file_structure.md
> > b/5_source_files/54_code_file_structure.md
> > index
> >
> 8cc9f4f61412b07f765d80d7b680c6dd38b838c1..ac999aae99ae9cfd8b6f97
> dc483e
> > 51bfbd7c7a0b 100644
> > --- a/5_source_files/54_code_file_structure.md
> > +++ b/5_source_files/54_code_file_structure.md
> > @@ -68,8 +68,8 @@ these are C files with an extension of "`.c`".
> >
> >  /* Function Definitions */
> >
> > -/* If this is a protocol definition, the -protocol structure is
> > defined and initialized here.
> > +/* If this is a protocol definition, the protocol structure is
> > +defined and
> > +  initialized here.
> >  */
> >  ```
>
> So, I'm a bit hesitant about this. In edk2 we use /* comments */ (to my
> knowledge, that is) only when they have to be embedded in replacement
> texts of function-like macros,

Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg: Add and update debug ASSERTS

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 04 January 2018 19:24
> To: Girish Pathak <girish.pat...@arm.com>
> Cc: Evan Lloyd <evan.ll...@arm.com>; Matteo Carlini
> <matteo.carl...@arm.com>; nd <n...@arm.com>; edk2-devel@lists.01.org;
> Thomas Abraham <thomas.abra...@arm.com>; Arvind Chauhan
> <arvind.chau...@arm.com>; leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg:
> Add and update debug ASSERTS
> 
> On 4 January 2018 at 18:55, Girish Pathak <girish.pat...@arm.com>
> wrote:
> > Hi Ard,
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf
> >> Of Ard Biesheuvel
> >> Sent: 23 December 2017 14:12
> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> Cc: "matteo.carl...@arm.com"@arm.com;
> >> "leif.lindh...@linaro.org"@arm.com; "n...@arm.com"@arm.com; edk2-
> >> de...@lists.01.org; Thomas Abraham <thomas.abra...@arm.com>;
> Arvind
> >> Chauhan <arvind.chau...@arm.com>;
> "ard.biesheu...@linaro.org"@arm.com
> >> Subject: Re: [edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg:
> >> Add and update debug ASSERTS
> >>
> >> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> >> > From: Girish Pathak 
> >> >
> >> > This change adds some debug assertions e.g to catch NULL pointer
> >> > errors missing in PL11Lcd and HdLcd platform libraries.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> >> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> >> > ---
> >> >
> >>
> Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExp
> r
> >> ess.c   | 22 +-
> >> >
> >> >
> >>
> Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdAr
> m
> >> VEx
> >> > press.c | 24 +++-
> >> >  2 files changed, 44 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git
> >> >
> >>
> a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVE
> x
> >> pres
> >> > s.c
> >> >
> >>
> b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVE
> x
> >> pres
> >> > s.c index
> >> >
> >>
> 6afd764897f49c64490ce891682f99bb0f5d993b..a8fe8696da0653017ce9fa
> 6e4a
> >> 86
> >> > caf283bc04c9 100644
> >> > ---
> >> >
> >>
> a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVE
> x
> >> pres
> >> > s.c
> >> > +++
> >>
> b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVE
> x
> >> > +++ press.c
> >> > @@ -153,6 +153,9 @@ LcdPlatformGetVram (
> >> >EFI_STATUS  Status;
> >> >EFI_ALLOCATE_TYPE   AllocationType;
> >> >
> >> > +  ASSERT (VramBaseAddress != NULL);  ASSERT (VramSize != NULL);
> >> > +
> >> >// Set the vram size
> >> >*VramSize = LCD_VRAM_SIZE;
> >> >
> >> > @@ -171,6 +174,7 @@ LcdPlatformGetVram (
> >> >VramBaseAddress
> >> >);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT (FALSE);
> >> >  return Status;
> >> >}
> >> >
> >> > @@ -181,8 +185,8 @@ LcdPlatformGetVram (
> >> >*VramSize,
> >> >EFI_MEMORY_WC
> >> >);
> >> > -  ASSERT_EFI_ERROR (Status);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT (FALSE);
> >>
> >> As in the sibling patch against EDK2, this patch makes it more
> >> difficult to figure out what went wrong when you hit the ASSERT.
> >> ASSERT_EFI_ERROR prints the value of Status, ASSERT(FALSE) only
> >> prints
> >> '0 != 1'
> >>
> >
> > This change(and other similar changes) is in response to review
> > comments on patch v1
> > https://lists.01.org/pipermail/edk2-devel/2017-October/015995.html
> >
> > with above reference, Can you please confirm if we should revert to the
> patch v1 version ?
> &

Re: [edk2] [edk2-CCodingStandardsSpecification PATCH 4/5] Fix Chapter 4 Typo

[Evan Lloyd]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 03 January 2018 16:56
> To: Evan Lloyd <evan.ll...@arm.com>; edk2-devel@lists.01.org
> Cc: "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "ler...@redhat.com"@arm.com;
> "liming@intel.com"@arm.com;
> "michael.d.kin...@intel.com"@arm.com;
> "jordan.l.jus...@intel.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [edk2-CCodingStandardsSpecification PATCH 4/5] Fix Chapter 4
> Typo
>
> On 01/03/18 12:22, evan.ll...@arm.com wrote:
> > From: Evan Lloyd <evan.ll...@arm.com>
> >
> > 4.1.3.2 - remove "See" from 'as specified in See "File Heading"'
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
> >  4_naming_conventions/README.md | 418 ++--
> >  1 file changed, 209 insertions(+), 209 deletions(-)
>
> Looks like this file underwent a line terminator conversion as well.
>
> If the file is currently not using CRLF, then I agree it should be converted;
> however, the conversion should be please separated from the typo fix.
>
> ... Hmm, the file already seems to use CRLF. So I think the conversion was to
> LF, and must have been unintended.

 [[Evan Lloyd]] It certainly was unintended, and seems to be an artefact of a 
core.autocrlf setting change.  Sorry.

>
> Can you please resubmit without the line terminator changes?
>
> Thanks!
> Laszlo
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [edk2-CCodingStandardsSpecification PATCH 1/5] Fix Chapter 1 Typos

[Evan Lloyd]

Hi Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 03 January 2018 16:51
> To: Evan Lloyd <evan.ll...@arm.com>; edk2-devel@lists.01.org
> Cc: "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "ler...@redhat.com"@arm.com;
> "liming@intel.com"@arm.com;
> "michael.d.kin...@intel.com"@arm.com;
> "jordan.l.jus...@intel.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [edk2-CCodingStandardsSpecification PATCH 1/5] Fix Chapter 1
> Typos
>
> On 01/03/18 12:22, evan.ll...@arm.com wrote:
> > From: Evan Lloyd <evan.ll...@arm.com>
> >
> > 1.1 Abstract - replace "then" with "can" (to make meaningful)
> > 1.2 Rationale - change
> >   "commit to conforming to standards of this specification"
> >   to   commit to conforming with the standards of this specification
> > 1.3 Scope - add missing "to" in "an attempt make you aware of your
> >   actions"
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
> >  1_introduction.md | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/1_introduction.md b/1_introduction.md index
> >
> c22c04c9f76d2352e4f294c0e70f5ebf787f7054..5471a6bf5e94df6dd0c5fd0
> a4b50
> > 20c77d1f8ca0 100644
> > --- a/1_introduction.md
> > +++ b/1_introduction.md
> > @@ -62,7 +62,7 @@ This specification addresses the chronic problem of
> > providing accurate  documentation of the code base by embedding the
> documentation within the code.
> >  While this does not guarantee that the documentation will be kept up
> > to date,  it significantly increases the chances. A document
> > generation system, Doxygen, -then produce formatted documentation by
> > extracting information from specially
> > +can produce formatted documentation by extracting information from
> > +specially
> >  formatted comment blocks and the syntactic elements of the code.
> >
> >  This specification presents protocol standards that will ensure that
> > the @@ -97,10 +97,10 @@ wide support. On the downside in that each
> > developer's C code could  lack of uniformity makes understanding and
> maintaining the code very difficult.
> >
> >  Uniformity is the key theme of these rules. You may disagree with
> > some of our -decisions. Nevertheless, we ask that you commit to
> > conforming to standards of -this specification. Also, there are
> > pitfalls inherent in the C language that -this style guide may help
> > you to avoid. The goal of this document is making -you, and those who
> follow you, more productive.
> > +decisions. Nevertheless, we ask that you commit to conforming with
> > +the standards of this specification. Also, there are pitfalls
> > +inherent in the C language that this style guide may help you to
> > +avoid. The goal of this document is making you, and those who follow
> you, more productive.
> >
> >  Some of the strict rules for protocol and driver construction may
> > seem overly  onerous. Don't panic - there is a method to our madness -
> > we intend to
>
> OK, a risky observation from non-native speaker to native speaker:

 [[Evan Lloyd]] To avoid false appearances, I'm not English either, so feel 
free.

>
> To my knowledge, it's "conform to", not "conform with". Thus, an update to
> this paragraph looks unnecessary to me, but I'm more than prepared to be
> corrected :)
[[Evan Lloyd]]  You are correct, conform to is usual, but I think it is equally 
correct usage to conform 'with' a request, or regulation.
I changed it because "to conform to" has too many "to"s

>
> (Also, I'd replace "help you to avoid" with "help you avoid", i.e. drop the
> "to". But, that's a separate thing, and the same caveat about being a non-
> native speaker applies :) )

 [[Evan Lloyd]] I agree, your version is better.

>
> Looks fine to me otherwise.
>
> Thanks!
> Laszlo
>
> > @@ -161,7 +161,7 @@ Topics covered in this coding standard include:
> >  * Commenting rules
> >  * Doxygen
> >
> > -These guidelines represent an attempt make you aware of your actions,
> > because
> > +These guidelines represent an attempt to make you aware of your
> > +actions, because
> >  those actions affect the future readers and maintainers of the code you
> produce.
> >
> >  Pre-existing code ported to the EDK II environment does not have to
> > conform to
> >

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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding standard

[Evan Lloyd]

Hi Ard

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 02 January 2018 15:21
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; Matteo Carlini <matteo.carl...@arm.com>;
> eif.lindh...@linaro.org; nd <n...@arm.com>
> Subject: Re: [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding
> standard
> 
> On 2 January 2018 at 15:11, Evan Lloyd <evan.ll...@arm.com> wrote:
> > Hi Ard.
> > One aim of these changes is to get those files we have to play with into a
> state where a beautifier like indent, astyle,  or clang-format can be used to
> help tidy our changes.  (NOTE, we do not have that fully working yet, but
> they do help.)  In a world where we have to play with several contradictory
> formatting standards (not just EDK2) then anything that can help is
> welcome.
> > Of the changes made:
> > Fixing the include guards: is a small improvement.  (Ideally
> patchcheck should reject these.)
> > Reducing lines to 80 columns: makes Leif (at least) happy, and 
> > aligns
> with formatter behaviour.
> > Correcting Doxygen format comments: prevents Doxygen generating
> gibberish.
> > Spaces before '(': Maintains consistency, and aligns with desired
> formatter behaviour.
> >
> 
> To be honest, this is an aspect I hadn't considered at all. It would be
> excellent if we could use tooling to fix our code wrt to coding style, and if
> changes such as these bring us closer to that goal, I am all for it.

 [[Evan Lloyd]] Excellent news - now you know why we were doing all those 
inexplicable things.  I really should have explained this more clearly before.

> 
> Would it be feasible to run that on entire packages, i.e., ArmPkg and
> ArmPlatformPkg?

 [[Evan Lloyd]]  As it stands, none of the tools is very happy with the EDK2 
style, and they tend to miss meeting it in different ways.
(As an aside - one common problem is that I have found no means of coercing 
them to force the ");" at the end of a function call onto its own line.  Your 
recent CCS change to make that optional helps a lot with that.)  However, I 
have so far failed to get any of the above tools to do exactly what we want.  
All that I can achieve is to generate a formatted view that can be compared 
against the original with a visual program like kdiff3 - highlighting some 
formatting improvements that can then be copied across, whilst the mismatches 
can be ignored.  This is not much, but it does help, especially with spacing 
and line length errors.

If you are interested, I am very happy to make those parameter files that I 
have available for consideration, as long as everyone understands how far from 
fully compliant they are, and that their limitations are manifold.  I suspect 
the path to a fully automated reformat will be a long and winding road.  The 
best bet might be to actually change one of the Open Source tools to suit us, 
but I certainly don't know of anyone with the leisure time available to take 
that on.

Regards,
Evan

> 
...
> >> > --
> >> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-CCodingStandardsSpecification PATCH 4/5] Fix Chapter 4 Typo

[evan . lloyd]

From: Evan Lloyd <evan.ll...@arm.com>

4.1.3.2 - remove "See" from 'as specified in See "File Heading"'

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 4_naming_conventions/README.md | 418 ++--
 1 file changed, 209 insertions(+), 209 deletions(-)

diff --git a/4_naming_conventions/README.md b/4_naming_conventions/README.md
index 
bcf902875719f94c5c4c3e58af24e18772dae055..1a9cd008b5dbbf203148408f92ffb4881f499766
 100644
--- a/4_naming_conventions/README.md
+++ b/4_naming_conventions/README.md
@@ -1,209 +1,209 @@
-
-
-# 4 Naming Conventions
-
-## 4.1 General Naming Rules
-
-**Use good naming practice when declaring variable names.**
-
-Studies show that programs with names averaging 10 to 16 characters are the
-easiest to debug. The name length is just a guideline_; the most important
-thing is that the name conveys a clear meaning of what it represents_.
-
-**Do not overload commonly used terms.**
-
-For example, EFI has an event model, so don't call some abstraction that you
-define an Event. People will get confused. Make sure someone reading the code
-can tell what you are talking about.
-
-**Each word or concept must start with a capital letter and be followed by
-lower-case letters.**
-
-The intent is for names to be consistent and easily readable. Each word in a
-compound name should be visually distinct.
-
-### 4.1.1 Identifiers that are always reserved
-
-**Identifiers beginning with an underscore are always reserved**
-
-Define them only in the special ways allowed elsewhere in this document.
-
-**Identifiers that are defined in the Standard C and POSIX libraries are always
-reserved.**
-
-This includes macros, typedefs, variables, and functions, whether with external
-linkage or file scope. The only exception is with modules that are mutually
-exclusive with these libraries. These reserved identifiers are listed in
-"Reserved Identifiers" and reserved keywords are listed in "Reserved Keywords".
-
-### 4.1.2 Common Opposites in Variable Names
-
-Use the correct opposites when declaring names.
-
-## Table 1 Common Opposites
-
-|   | |  |
-| - | --- |  |
-| add / remove  | begin / end | create / destroy |
-| increment / decrement | first / last| get / release|
-| lock / unlock | put / get   | up / down|
-| old / new | min / max   | next / previous  |
-| source / destination  | open / close| show / hide  |
-|   | source / target | start / stop |
-
-### 4.1.3 Abbreviation Usage
-
- 4.1.3.1 The use of abbreviations shall be regulated.
-
-This document describes a common set of abbreviations that can be freely used.
-If you must make up abbreviations, remember the name is most important to the
-reader of the code, not the writer.
-
- 4.1.3.2 New abbreviations must be documented in the header of each using 
file.
-
-Any abbreviation used, which is not documented in this specification, or in the
-_UEFI Specification_ shall be placed into a Glossary section of the File header
-as specified in See "File Heading".
-
-Do not define a new abbreviation to replace an abbreviation that is already
-defined in this document. For example, do not define No to mean Number, because
-Num is the supported abbreviation.
-
-"EFI Supported Abbreviations" below lists the abbreviations that are
-standardized by this document and do not require a defining comment.
-
-## Table 2 EFI Supported Abbreviations
-
-| Abbreviation | Description |
-|  | --- |
-| Ptr  | Pointer |
-| Str  | Unicode string  |
-| Ascii| ASCII string|
-| Len  | Length  |
-| Arg  | Argument|
-| Max  | Maximum |
-| Min  | Minimum |
-| Char | Character   |
-| Num  | Number  |
-| Temp | Temporary   |
-| Src  | Source  |
-| Dst  | Destination |
-| BS   | EFI Boot Services Table |
-| RT   | EFI Runtime Table   |
-| ST   | EFI System Table|
-| Tpl  | EFI Task Priority Level |
-
- 4.1.3.3 Powers of 2 and 10
-
-You are encouraged to use the IEC international abbreviations for powers of 2
-(KiB for 2^10, MiB for 2^20, GiB for 2^30, etc.) rather than the old KB, MB,
-and GB, which IEC now reserves for powers of 10 (10^3, 10^6, 10^9). Given that
-many readers of the code may not have made the conversion to add the 'i', do
-not use KB, MB, and GB for powers of 10 Instead, use e.g. "2*10^6 bytes"
-instead of 2MB to avoid confusion. Note that GiB is derived from th

[edk2] [edk2-CCodingStandardsSpecification PATCH 5/5] Fix Chapter 5 Typos

[evan . lloyd]

From: Evan Lloyd <evan.ll...@arm.com>

5.1.1 - Replace "less" with "fewer" (because columns is plural and
countable)
5.1.5 - Correct tense.  (because the C specification still defines...)
Insert full stop.
Insert comma.
5.1.8 - Correct "provided" to "proven".
5.1.9 - remove hanging "This."
5.2.3.1 - replace "is comprised of" with "comprises" (comprise means
  "consists of", so "comprised of" is a solecism.
  Remove use of tab, as they are forbidden.
  Remove -- before date in copyright header (None of the edk2
  files have it).
5.4 - Add indent to comment text.
5.6.1.2 - Fix copy/paste text (from UEFI spec).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 5_source_files/52_spacing.md|  9 +
 5_source_files/54_code_file_structure.md|  4 ++--
 5_source_files/56_declarations_and_types.md |  4 ++--
 5_source_files/README.md| 18 +-
 4 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/5_source_files/52_spacing.md b/5_source_files/52_spacing.md
index 
ddeabf7753a8713bf04e143d6e2e9bccf881f691..3c79f4e4ee91bcd4035d6cf7d8d32f1bb9c7756f
 100644
--- a/5_source_files/52_spacing.md
+++ b/5_source_files/52_spacing.md
@@ -249,7 +249,7 @@ And the comment will end with:
 **/
 ```
 
-The File Heading comment block is comprised of the following sections: File
+The File Heading comment block comprises the following sections: File
 Description, Copyright, License, and the optional Specification Reference and
 Glossary sections.
 
@@ -266,8 +266,9 @@ Glossary sections.
 **/
 ```
 
-The following example begins each body line with a tab (two spaces). This is
-the preferred indentation, but two tabs (four spaces) is also acceptable.
+The following example begins each body line with an indent (two spaces).
+This is the preferred indentation, but a double indent (four spaces) is also
+acceptable.
 
  Example
 
@@ -278,7 +279,7 @@ the preferred indentation, but two tabs (four spaces) is 
also acceptable.
   Detailed description of the file’s contents and other useful
   information for a person viewing the file for the first time.
 
-  Copyright (C) --20XX, Acme Corporation. All rights reserved.
+  Copyright (C) 20XX, Acme Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of
   the BSD License which accompanies this distribution. The full
diff --git a/5_source_files/54_code_file_structure.md 
b/5_source_files/54_code_file_structure.md
index 
8cc9f4f61412b07f765d80d7b680c6dd38b838c1..ac999aae99ae9cfd8b6f97dc483e51bfbd7c7a0b
 100644
--- a/5_source_files/54_code_file_structure.md
+++ b/5_source_files/54_code_file_structure.md
@@ -68,8 +68,8 @@ these are C files with an extension of "`.c`".
 
 /* Function Definitions */
 
-/* If this is a protocol definition, the
-protocol structure is defined and initialized here.
+/* If this is a protocol definition, the protocol structure is defined and
+  initialized here.
 */
 ```
 
diff --git a/5_source_files/56_declarations_and_types.md 
b/5_source_files/56_declarations_and_types.md
index 
ec1803d980e1fa808b9dc515cdffbc4b47437435..5c57834fe1195b5487f0f59e8a0385e44d91aff4
 100644
--- a/5_source_files/56_declarations_and_types.md
+++ b/5_source_files/56_declarations_and_types.md
@@ -43,9 +43,9 @@ or from common EFI data types.
 The corresponding EFI types must be used instead.
 
 "EFI Data Types" below contains the common data types that are referenced in
-the interface definitions defined by this specification. Per the _UEFI
-Specification_, version 2.3.1:
+the interface definitions defined by the UEFI specification.
 
+Per the _UEFI Specification_, version 2.3.1:
 "Unless otherwise specified, all data types are naturally aligned. Structures
 are aligned on boundaries equal to the largest internal datum of the structure,
 and internal data is implicitly padded to achieve natural alignment."
diff --git a/5_source_files/README.md b/5_source_files/README.md
index 
a93492db4f0f17e14d9c2c3c95e57cf0f6cc911e..a443148138f2abaf6b9131f4758858a4a5f45fd3
 100644
--- a/5_source_files/README.md
+++ b/5_source_files/README.md
@@ -33,9 +33,9 @@
 
 ## 5.1 General Rules
 
-### 5.1.1 Lines shall be 120 columns, or less
+### 5.1.1 Lines shall be 120 columns, or fewer
 
-Preferably, limit line lengths to 80 columns or less. When this doesn't leave
+Preferably, limit line lengths to 80 columns or fewer. When this doesn't leave
 sufficient space for a good postfix style comment, extend the line to a total
 of 120 columns. Having some level of uniformity in the expected width of the
 source is useful for viewing and printing the code.
@@ -79,9 +79,9 @@ Other than '\0', the only permissible escape seq

[edk2] [edk2-CCodingStandardsSpecification PATCH 1/5] Fix Chapter 1 Typos

[evan . lloyd]

From: Evan Lloyd <evan.ll...@arm.com>

1.1 Abstract - replace "then" with "can" (to make meaningful)
1.2 Rationale - change
  "commit to conforming to standards of this specification"
  to   commit to conforming with the standards of this specification
1.3 Scope - add missing "to" in "an attempt make you aware of your
  actions"

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 1_introduction.md | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/1_introduction.md b/1_introduction.md
index 
c22c04c9f76d2352e4f294c0e70f5ebf787f7054..5471a6bf5e94df6dd0c5fd0a4b5020c77d1f8ca0
 100644
--- a/1_introduction.md
+++ b/1_introduction.md
@@ -62,7 +62,7 @@ This specification addresses the chronic problem of providing 
accurate
 documentation of the code base by embedding the documentation within the code.
 While this does not guarantee that the documentation will be kept up to date,
 it significantly increases the chances. A document generation system, Doxygen,
-then produce formatted documentation by extracting information from specially
+can produce formatted documentation by extracting information from specially
 formatted comment blocks and the syntactic elements of the code.
 
 This specification presents protocol standards that will ensure that the
@@ -97,10 +97,10 @@ wide support. On the downside in that each developer's C 
code could
 lack of uniformity makes understanding and maintaining the code very difficult.
 
 Uniformity is the key theme of these rules. You may disagree with some of our
-decisions. Nevertheless, we ask that you commit to conforming to standards of
-this specification. Also, there are pitfalls inherent in the C language that
-this style guide may help you to avoid. The goal of this document is making
-you, and those who follow you, more productive.
+decisions. Nevertheless, we ask that you commit to conforming with the
+standards of this specification. Also, there are pitfalls inherent in the C
+language that this style guide may help you to avoid. The goal of this document
+is making you, and those who follow you, more productive.
 
 Some of the strict rules for protocol and driver construction may seem overly
 onerous. Don't panic - there is a method to our madness - we intend to
@@ -161,7 +161,7 @@ Topics covered in this coding standard include:
 * Commenting rules
 * Doxygen
 
-These guidelines represent an attempt make you aware of your actions, because
+These guidelines represent an attempt to make you aware of your actions, 
because
 those actions affect the future readers and maintainers of the code you 
produce.
 
 Pre-existing code ported to the EDK II environment does not have to conform to
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-CCodingStandardsSpecification PATCH 0/5] Typographic Corrections

[evan . lloyd]

From: Evan Lloyd <evan.ll...@arm.com>

https://bugzilla.tianocore.org/show_bug.cgi?id=839

This patch set contains a number of minor typographical corrections.
They have no specific theme, being only that set of things I happened to
notice during recent code review sessions where I was frequently
consulting the CCS.  Some are pedantic or may come under the heading of
"Typographic silliness", but they were enough to distract my attention
from the content, so fixing them may help others.

GitHub branch for review:
https://github.com/EvanLloyd/edk2-CCodingStandardsSpecification/tree/17Q4Typos_v1

GitHub word diff view of the patches in this series:
https://github.com/tianocore-docs/edk2-CCodingStandardsSpecification/compare/master...EvanLloyd:17Q4Typos_v1?w1


Evan Lloyd (5):
  Fix Chapter 1 Typos
  Fix Chapter 2 Typos
  Fix Chapter 3 Typos
  Fix Chapter 4 Typo
  Fix Chapter 5 Typos

 1_introduction.md   |  12 +-
 2_guiding_principles.md |   8 +-
 3_quick_reference.md|   2 +-
 4_naming_conventions/README.md  | 418 ++--
 5_source_files/52_spacing.md|   9 +-
 5_source_files/54_code_file_structure.md|   4 +-
 5_source_files/56_declarations_and_types.md |   4 +-
 5_source_files/README.md|  18 +-
 8 files changed, 238 insertions(+), 237 deletions(-)

-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-CCodingStandardsSpecification PATCH 3/5] Fix Chapter 3 Typos

[evan . lloyd]

From: Evan Lloyd <evan.ll...@arm.com>

3_quick_reference.md has some obviously invalid extra characters at the
end of line 55 ( ",).  This patch removes them.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 3_quick_reference.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/3_quick_reference.md b/3_quick_reference.md
index 
13045d297b3be848d91f9be05380454b4cc2fe91..9367e422fb0337007409d6597913cb43da92e0c5
 100644
--- a/3_quick_reference.md
+++ b/3_quick_reference.md
@@ -55,7 +55,7 @@
   any file using the abbreviation or acronym. See "Abbreviation Usage" and
   "Glossary".
 
-* There is no limit to name lengths. A length of 10 to 30 characters is ",
+* There is no limit to name lengths. A length of 10 to 30 characters is
   recommended. See "File Names" & "Identifiers that are always reserved".
 
 * File names must not start with numbers. See "File Names".
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [edk2-CCodingStandardsSpecification PATCH 2/5] Fix Chapter 2 Typos

[evan . lloyd]

From: Evan Lloyd <evan.ll...@arm.com>

2.1 Accessibility - remove erroneous "as"
2.1 Confirmation - insert missing full stop
2.1 Forgiveness - excise superfluous "errors"
2.1 Standard techniques - remove redundant "be to"

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 2_guiding_principles.md | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/2_guiding_principles.md b/2_guiding_principles.md
index 
a7759f27dcf71a948b903332c9bc14946e445cd8..5a51225b65dec2159a4fb94481920666c0d042ff
 100644
--- a/2_guiding_principles.md
+++ b/2_guiding_principles.md
@@ -47,7 +47,7 @@ The following is an alphabetical list of software design 
principles:
 **Accessibility**
 
 This entails designing objects and environments to be usable, with no
-modification, by the greatest number of people as possible, including people
+modification, by the greatest number of people possible, including people
 with varying educational and social backgrounds, as well as those with motor or
 sensory challenges.
 
@@ -68,7 +68,7 @@ shortterm memory, as well as to accommodate its limits.
 This is a technique used for critical actions, inputs, or commands.
 Confirmations are primarily used to prevent unintended actions. Minimize errors
 in critical or irreversible operations with confirmations. If you overuse
-confirmations, expect that they will be ignored Avoid overusing confirmations
+confirmations, expect that they will be ignored. Avoid overusing confirmations
 to ensure that they remain unexpected and uncommon; otherwise, they may be
 ignored. Use a two-step operation for hardware confirmations and dialogs for
 software confirmations.
@@ -97,7 +97,7 @@ about the assumptions you make.
 **Forgiveness**
 
 Design to help users avoid errors and reduce the negative consequences of
-errors any errors made. Recommended methods for achieving design forgiveness
+any errors made. Recommended methods for achieving design forgiveness
 include affordances, reversibility of actions, and safety nets. Effectively
 designing for forgiveness results in a design needing minimal confirmations,
 warnings, and help.
@@ -171,7 +171,7 @@ classes of platforms from embedded systems to massively 
parallel computers.
 
 Greater reliance on unique or exotic pieces makes a system harder to
 understand, and more intimidating for someone trying to understand it the first
-time. Using standardized, common approaches should be to give the whole system
+time. Using standardized, common approaches should give the whole system
 a familiar feeling. This standardization is one of the primary goals of this
 document.
 
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2 14/18] ARM/VExpressPkg: Reserving framebuffer at build

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 December 2017 16:03
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; Arvind Chauhan <arvind.chau...@arm.com>;
> Daniil Egranov <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH edk2-platforms v2 14/18] ARM/VExpressPkg:
> Reserving framebuffer at build
>
> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak 
> >
> > This change uses two PCDs, PcdArmLcdFrameBufferBase and
> > PcdArmLcdFrameBufferSize introduced in correspondiong EDK2 patch to
> > reserve framebuffer in DRAM if these values are defined in platform
> > specific DSC file, avoiding the need to allocate dynamically.
> > This allows the framebuffer to appear as "I/O memory" outside of the
> > normal RAM map, which is similar to the "VRAM" case.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
...
> > +  VirtualMemoryTable[Index].Attributes =
> > +ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
> > +#endif
> > +
>
> Whose responsibility is it to ensure that this region is removed from
> SystemMemoryBase/SystemMemorySize? If it is up to the .DSC author,
> could you please add an ASSERT() here that they don't overlap?

 [[Evan Lloyd]] That is an excellent suggestion, thank you - we'll add that.

>
> >// Map sparse memory region if present
> >if (HasSparseMemory) {
> >  VirtualMemoryTable[++Index].PhysicalBase = SparseMemoryBase;
> > --
> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding standard

[Evan Lloyd]

Hi Ard.
One aim of these changes is to get those files we have to play with into a 
state where a beautifier like indent, astyle,  or clang-format can be used to 
help tidy our changes.  (NOTE, we do not have that fully working yet, but they 
do help.)  In a world where we have to play with several contradictory 
formatting standards (not just EDK2) then anything that can help is welcome.
Of the changes made:
Fixing the include guards: is a small improvement.  (Ideally patchcheck 
should reject these.)
Reducing lines to 80 columns: makes Leif (at least) happy, and aligns 
with formatter behaviour.
Correcting Doxygen format comments: prevents Doxygen generating 
gibberish.
Spaces before '(': Maintains consistency, and aligns with desired 
formatter behaviour.

More below:

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 23 December 2017 13:19
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding
> standard
> 
> On 22 December 2017 at 18:34,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak 
> >
> > There is no functional modification in this change As preparation for
> > further work, the formatting is corrected to meet the EDKII coding
> > standard.
> > Of specific note, some invalid include guards were fixed.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> 
> Hi Girish, Evan,
> 
> I am sorry, but I really don't see the point of this patch. Given that the
> coding standard is not in line with common practice in Tianocore, changing
> comments to remove empty lines after // or changing one style to the
> other is just pointless churn. Also, changes like
> 
> >  VOID
> > -LcdShutdown (
> > -  VOID
> > -  )
> > +LcdShutdown (VOID)
> >  {
> 
> look backward to me, and so if the coding standard mandates that, we
> should changes the coding standard, not the code.
> 
> --
> Ard.
> 
[[Evan Lloyd]] Hi Ard.
The coding standard doesn't mandate this format, but permits it (5.7.1.5).
Our case is that whilst either format is acceptable, consistency is desirable, 
so we aimed (however imperfectly) to use a consistent style.
In this instance, though, this  would be reverted by the formatting tools, so I 
agree that it is pointless.

> 
> 
> > ---
> >
> ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |
> 10 +-
> >  ArmPlatformPkg/Include/Library/LcdPlatformLib.h|  14 +-
> >  ArmPlatformPkg/Library/HdLcd/HdLcd.h   |  21 
> > ++-
> >
> ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c |
> 187 +++-
> >  ArmPlatformPkg/Library/HdLcd/HdLcd.c   |  96 
> > +
> -
> >  ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c |  72 
> > --
> --
> >  6 files changed, 212 insertions(+), 188 deletions(-)
> >
> > diff --git
> a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> h
> b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> h
> > index
> b66efd34561f655b74a5ecfad8a97281cdd5929d..2b001b107927fc75317ce
> 39d370049d7740953a8 100644
> > ---
> a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> h
> > +++
> b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.
> h
> > @@ -1,6 +1,6 @@
> >  /** @file
> >
> > -  Copyright (c) 2011, ARM Ltd. All rights reserved.
> > +  Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of the
> BSD License
> >which accompanies this distribution.  The full text of the license may be
> found at
> > @@ -11,9 +11,8 @@
> >
> >  **/
> >
> > -#ifndef __ARM_VE_GRAPHICS_DXE_H__
> > -#define __ARM_VE_GRAPHICS_DXE_H__
> > -
> > +#ifndef LCD_GRAPHICS_OUTPUT_DXE_H_
> > +#define LCD_GRAPHICS_OUTPUT_DXE_H_
> >
> >  #include 
> >
> > @@ -25,7 +24,6 @@
> >
> >  #include 
> >
> > -
> >  //
> >  // Device structures
> >  //
> > @@ -106,4 +104,4 @@ InitializeDisplay (
> >IN LCD_INSTANCE* Instanc

Re: [edk2] [PATCH edk2-platforms v2 00/18] ARM: Update GOP

[Evan Lloyd]

Hi Ard.
Happy New Year!
I have no idea what has caused that.  I haven't changed the script I use to 
generate patches, so I'm off to consult our IT guys to find out what's up.
I'll resume when I've done that.

Sorry,
Evan

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 22 December 2017 19:30
> To: Evan Lloyd <evan.ll...@arm.com>; Leif Lindholm
> <leif.lindh...@linaro.org>; Ard Biesheuvel <ard.biesheu...@linaro.org>;
> Matteo Carlini <matteo.carl...@arm.com>
> Cc: edk2-devel@lists.01.org; Arvind Chauhan <arvind.chau...@arm.com>;
> Daniil Egranov <daniil.egra...@arm.com>; Thomas Abraham
> <thomas.abra...@arm.com>
> Subject: Re: [PATCH edk2-platforms v2 00/18] ARM: Update GOP
>
> On 22 December 2017 at 19:08,  <evan.ll...@arm.com> wrote:
> > From: EvanLloyd <evan.ll...@arm.com>
> >
>
> Hello Evan,
>
> Before reviewing in detail, could you please confirm that replying to the
> addresses below is going to work as expected for non @arm.com reviewers?
> They look a bit odd, but perhaps the arm.com SMTP server doesn't care??
>
> Cc: Arvind Chauhan <arvind.chau...@arm.com>, Daniil Egranov
> <daniil.egra...@arm.com>, Thomas Panakamattam Abraham
> <thomas.abra...@arm.com>, "ard.biesheu...@linaro.org"@arm.com,
> "leif.lindh...@linaro.org"@arm.com,
> "matteo.carl...@arm.com"@arm.com, "n...@arm.com"@arm.com
>
> --
> Ard.
>
>
> > This patch series addresses comments on the original
> > (https://lists.01.org/pipermail/edk2-devel/2017-September/015356.html)
> > reworking of the Graphics Output Protocol code in Platform/ARM.
> > It also contains updates for the new SCMI protocol (MTL Library).
> >
> > After a number of format and quality modifications, several errors
> > are corrected and new functionality added for Mali DP.
> >
> > The changes are tested on Juno, and FVP.
> >
> > Code is available for examination at:
> >   https://github.com/EvanLloyd/edk2-platforms/tree/166_gop_v2
> >
> > Ard Biesheuvel (1):
> >   ARM/VExpressPkg: Fix MODULE_TYPE of HDLCD/PL111 platform libraries
> >
> > EvanLloyd (1):
> >   ARM/VExpressPkg: HdLcdArmVExpressLib: Remove redundant Bpp
> >
> > Girish Pathak (16):
> >   ARM/VExpressPkg: Tidy HDLCD and PL11LCD platform Lib: Coding
> standard
> >   ARM/VExpressPkg: Tidy HdLcd/PL111Lcd code: Updated comments
> >   ARM/VExpressPkg: Remove unused PcdPL111LcdMaxMode from HDLCD
> inf
> >   ARM/VExpressPkg: PL111 and HDLCD: add const qualifier
> >   ARM/VExpressPkg: Add and update debug ASSERTS
> >   ARM/VExpressPkg: PL111LcdArmVExpressLib: Minor code cleanup
> >   ARM/VExpressPkg: PL111 and HDLCD: Use FixedPcdGet32
> >   ARM/VExpressPkg: PL11LcdArmVExpressLib: Improvement conditional
> >   ARM/VExpressPkg: HdLcdArmVExpressLib: Remove status check
> EFI_TIMEOUT
> >   ARM/VExpressPkg: Redefine LcdPlatformGetTimings function
> >   ARM/VExpressPkg: PL111 and HDLCD: Add PCD to select pixel format
> >   ARM/VExpressPkg: Reserving framebuffer at build
> >   ARM/VExpressPkg: New DP500/DP550/DP650 platform library.
> >   ARM/JunoPkg: Mapping Non-Trused SRAM as device memory
> >   ARM/JunoPkg: Adding SCMI MTL library
> >   ARM/JunoPkg: Add HDLCD platform library
> >
> >  Platform/ARM/JunoPkg/ArmJuno.dec   
> > |  17
> +-
> >  Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
> |   3 +-
> >  Platform/ARM/JunoPkg/ArmJuno.dsc   
> > |  32
> ++
> >  Platform/ARM/JunoPkg/ArmJuno.fdf   
> > |  12
> +-
> >  Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf
> |   5 +-
> >  Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
> |  39 ++
> >  Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf
> |  40 ++
> >  Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf
> |  45 ++
> >
> Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib
> .inf |   7 +-
> >
> Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExp
> ressLib.inf   |  13 +-
> >
> Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdAr
> mVExpressLib.inf |   9 +-
> >  Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h
> |  94 
> >  Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c
> |  24 +-
> >  Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.c
> | 195 +++
> >  Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLc

[edk2] [PATCH edk2-platforms v2 11/18] ARM/VExpressPkg: HdLcdArmVExpressLib: Remove redundant Bpp

[evan . lloyd]

From: EvanLloyd 

Because of copy/paste effects, HdLcdArmVExpress.c contained a
table entry "LCD_BPP Bpp;" specifying the Bits per Pixel for each mode.
However, all modes are LCD_BITS_PER_PIXEL_24.

This change removes the table entry and related use of the field.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c | 42 
++--
 1 file changed, 13 insertions(+), 29 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
533d7fa4777e8f22429e2ae63a828dcb5401b5c0..8496a0215bc78585b546f63312c9d7f1ad07adb6
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -32,7 +32,6 @@ typedef struct {
   UINT32 Mode;
   UINT32 HorizontalResolution;
   UINT32 VerticalResolution;
-  LCD_BPPBpp;
   UINT32 OscFreq;
 
   // These are used by HDLCD
@@ -48,37 +47,37 @@ typedef struct {
 **/
 STATIC CONST LCD_RESOLUTION mResolutions[] = {
   { // Mode 0 : VGA : 640 x 480 x 24 bpp
-VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
+VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS,
 VGA_OSC_FREQUENCY,
 VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
 VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
   },
   { // Mode 1 : SVGA : 800 x 600 x 24 bpp
-SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
+SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS,
 SVGA_OSC_FREQUENCY,
 SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
 SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
   },
   { // Mode 2 : XGA : 1024 x 768 x 24 bpp
-XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
+XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS,
 XGA_OSC_FREQUENCY,
 XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH,
 XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH
   },
   { // Mode 3 : SXGA : 1280 x 1024 x 24 bpp
-SXGA, SXGA_H_RES_PIXELS, SXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
+SXGA, SXGA_H_RES_PIXELS, SXGA_V_RES_PIXELS,
 (SXGA_OSC_FREQUENCY/2),
 SXGA_H_SYNC, SXGA_H_BACK_PORCH, SXGA_H_FRONT_PORCH,
 SXGA_V_SYNC, SXGA_V_BACK_PORCH, SXGA_V_FRONT_PORCH
   },
   { // Mode 4 : UXGA : 1600 x 1200 x 24 bpp
-UXGA, UXGA_H_RES_PIXELS, UXGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
+UXGA, UXGA_H_RES_PIXELS, UXGA_V_RES_PIXELS,
 (UXGA_OSC_FREQUENCY/2),
 UXGA_H_SYNC, UXGA_H_BACK_PORCH, UXGA_H_FRONT_PORCH,
 UXGA_V_SYNC, UXGA_V_BACK_PORCH, UXGA_V_FRONT_PORCH
   },
   { // Mode 5 : HD : 1920 x 1080 x 24 bpp
-HD, HD_H_RES_PIXELS, HD_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
+HD, HD_H_RES_PIXELS, HD_V_RES_PIXELS,
 (HD_OSC_FREQUENCY/2),
 HD_H_SYNC, HD_H_BACK_PORCH, HD_H_FRONT_PORCH,
 HD_V_SYNC, HD_V_BACK_PORCH, HD_V_FRONT_PORCH
@@ -292,27 +291,12 @@ LcdPlatformQueryMode (
   Info->VerticalResolution = mResolutions[ModeNumber].VerticalResolution;
   Info->PixelsPerScanLine = mResolutions[ModeNumber].HorizontalResolution;
 
-  switch (mResolutions[ModeNumber].Bpp) {
-  case LCD_BITS_PER_PIXEL_24:
-Info->PixelFormat   = 
PixelRedGreenBlueReserved8BitPerColor;
-Info->PixelInformation.RedMask  = LCD_24BPP_RED_MASK;
-Info->PixelInformation.GreenMask= LCD_24BPP_GREEN_MASK;
-Info->PixelInformation.BlueMask = LCD_24BPP_BLUE_MASK;
-Info->PixelInformation.ReservedMask = LCD_24BPP_RESERVED_MASK;
-break;
-
-  case LCD_BITS_PER_PIXEL_16_555:
-  case LCD_BITS_PER_PIXEL_16_565:
-  case LCD_BITS_PER_PIXEL_12_444:
-  case LCD_BITS_PER_PIXEL_8:
-  case LCD_BITS_PER_PIXEL_4:
-  case LCD_BITS_PER_PIXEL_2:
-  case LCD_BITS_PER_PIXEL_1:
-  default:
-// These are not supported
-ASSERT (FALSE);
-break;
-  }
+  /* Bits per Pixel is always LCD_BITS_PER_PIXEL_24 */
+  Info->PixelFormat   = PixelRedGreenBlueReserved8BitPerColor;
+  Info->PixelInformation.RedMask  = LCD_24BPP_RED_MASK;
+  Info->PixelInformation.GreenMask= LCD_24BPP_GREEN_MASK;
+  Info->PixelInformation.BlueMask = LCD_24BPP_BLUE_MASK;
+  Info->PixelInformation.ReservedMask = LCD_24BPP_RESERVED_MASK;
 
   return EFI_SUCCESS;
 }
@@ -395,7 +379,7 @@ LcdPlatformGetBpp (
 return EFI_INVALID_PARAMETER;
   }
 
-  *Bpp = mResolutions[ModeNumber].Bpp;
+  *Bpp = LCD_BITS_PER_PIXEL_24;
 
   return EFI_SUCCESS;
 }
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 15/18] ARM/VExpressPkg: New DP500/DP550/DP650 platform library.

[evan . lloyd]

From: Girish Pathak 

This change adds LcdPlatformLib implementation for ARM Mali
DP500/DP500/DP650 display processors for models (with DP550 support).

NOTE: Versions for actual hardware are liable to require extra handling
for clock input changes, etc.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/ArmVExpressPkg.dec|   3 +-
 Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf |  45 
+++
 Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf |   3 +
 Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c   | 374 

 Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c  |  10 +-
 5 files changed, 433 insertions(+), 2 deletions(-)

diff --git a/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec 
b/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
index 
695553a94f7f7e963b5db995c5e54f1ae1559daf..a82bc905b3a2180e85f78a6c16aeba9fcb495bed
 100644
--- a/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
+++ b/Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
@@ -1,7 +1,7 @@
 #/** @file
 # Arm Versatile Express package.
 #
-#  Copyright (c) 2012-2015, ARM Limited. All rights reserved.
+#  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials are licensed and made available
 #  under the terms and conditions of the BSD License which accompanies this
@@ -51,6 +51,7 @@ [PcdsFixedAtBuild.common]
   gArmVExpressTokenSpaceGuid.PcdPL111LcdVideoModeOscId|1|UINT32|0x0003
 
   gArmVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId|0|UINT32|0x0005
+  gArmVExpressTokenSpaceGuid.PcdArmMaliDpMaxMode|0|UINT32|0x0008
 
   #
   # Device path of block device on which Fastboot will flash partitions
diff --git a/Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf 
b/Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf
new file mode 100644
index 
..4c8f3c3b3b6540505fce173ef16e2f3eafeb048b
--- /dev/null
+++ b/Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf
@@ -0,0 +1,45 @@
+#/** @file ArmMaliDpLib.inf
+#
+#  Component description file for ArmMaliDpLib module
+#
+#  Copyright (c) 2017, ARM Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#**/
+
+[Defines]
+  INF_VERSION= 0x00010019
+  BASE_NAME  = ArmMaliDpLib
+  FILE_GUID  = 36C47FED-2F3F-49C7-89CE-31B13F0431D8
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = LcdPlatformLib
+
+[Sources.common]
+  ArmMaliDpLib.c
+
+[Packages]
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  MdePkg/MdePkg.dec
+  Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  DxeServicesTableLib
+
+[FixedPcd.common]
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize
+  gArmPlatformTokenSpaceGuid.PcdGopPixelFormat
+
+  # MaxMode must be one number higher than the actual max mode,
+  # i.e. for actual maximum mode 2, set the value to 3.
+  # See Section 12.9 of the UEFI Specification 2.7
+  gArmVExpressTokenSpaceGuid.PcdArmMaliDpMaxMode
+
diff --git 
a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf 
b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
index 
c70c4ce64826174e6d15611de640ad3b902835b9..c2d8749d0c08d6afc71f7c41a27075d58ff27557
 100644
--- a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
+++ b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
@@ -60,5 +60,8 @@ [FixedPcd]
   gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase
   gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize
 
+  gArmPlatformTokenSpaceGuid.PcdArmMaliDpBase
+  gArmPlatformTokenSpaceGuid.PcdArmMaliDpMemoryRegionLength
+
 [Ppis]
   gArmMpCoreInfoPpiGuid
diff --git a/Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c 
b/Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c
new file mode 100644
index 
..63f7c3b874b4fea80ab81c396a08e3e2e9b0581c
--- /dev/null
+++ b/Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c
@@ -0,0 +1,374 @@
+/** @file ArmMaliDpLib.c
+
+  The file contains ARM Mali DP platform specific implementation.
+
+  Copyright (c) 2017, ARM Ltd. All rights reser

[edk2] [PATCH edk2-platforms v2 17/18] ARM/JunoPkg: Adding SCMI MTL library

[evan . lloyd]

From: Girish Pathak 

This change adds a new Mailbox Transport Layer library for the Juno
platform. This library is required for ArmScmiDxe driver communication
with the SCP.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
---
 Platform/ARM/JunoPkg/ArmJuno.dec|   9 +-
 Platform/ARM/JunoPkg/ArmJuno.dsc|   3 +
 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf  |  39 
 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h |  94 ++
 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.c| 195 
 5 files changed, 339 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec b/Platform/ARM/JunoPkg/ArmJuno.dec
index 
60cef6d23a2d904103b9806d871fd2b89fff51c3..b733480c3198d135df16ca024b5e85ff350e11c7
 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dec
+++ b/Platform/ARM/JunoPkg/ArmJuno.dec
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2013-2015, ARM Limited. All rights reserved.
+#  Copyright (c) 2013-2017, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -46,3 +46,10 @@ [PcdsFixedAtBuild.common]
   # Juno Device Trees are loaded from NOR Flash
   
gArmJunoTokenSpaceGuid.PcdJunoFdtDevicePath|L"VenHw(E7223039-5836-41E1-B542-D7EC736C5E59)/board.dtb"|VOID*|0x0008
 
+  # MHU Register base used by SCMI Mailbox transport
+  gArmJunoTokenSpaceGuid.PcdArmMtlDoorBell|0x2B1F|UINT64|0x0024
+
+  # ARM_JUNO_NON_SECURE_SRAM_BASE used by SCMI Mailbox transport
+  gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxBase|0x2E00|UINT64|0x0025
+  gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxSize|0x80|UINT32|0x0026
+
diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 
5c2a29fe8330bbf308e31e34b617517a5aebcf6d..fe860956a4dc497cac52be70bab3657246a08bd0
 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -47,6 +47,9 @@ [LibraryClasses.common]
   # USB Requirements
   UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
 
+  # SCMI Mailbox Transport Layer
+  ArmMtl|Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
+
 [LibraryClasses.common.SEC]
   PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
   
ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
diff --git a/Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf 
b/Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
new file mode 100644
index 
..69e845f93f9332205fd5d36af2753681304058e3
--- /dev/null
+++ b/Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
@@ -0,0 +1,39 @@
+#/** @file
+#  Copyright (c) 2017, ARM Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#**/
+
+[Defines]
+  INF_VERSION= 0x00010019
+  BASE_NAME  = ArmMtl
+  FILE_GUID  = 21FB2D8F-C6C8-4B2C-A616-A30CB2FBA277
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = ArmMtl
+
+[Sources.common]
+  ArmMtl.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  MdePkg/MdePkg.dec
+  Platform/ARM/JunoPkg/ArmJuno.dec
+
+[LibraryClasses]
+  ArmLib
+  DebugLib
+  IoLib
+  UefiBootServicesTableLib
+
+[FixedPcd.common]
+  gArmJunoTokenSpaceGuid.PcdArmMtlDoorBell
+  gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxBase
+  gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxSize
diff --git a/Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h 
b/Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h
new file mode 100644
index 
..825fc788722bbe01ede24d9f867565c4c1dc938b
--- /dev/null
+++ b/Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h
@@ -0,0 +1,94 @@
+/** @file
+
+  Copyright (c) 2017, ARM Limited. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+  System Control and Management Interface V1.0
+http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
+DEN0056A_System_Control_and_Management_Interface.pdf
+
+  Juno ARM Development 

[edk2] [PATCH edk2-platforms v2 18/18] ARM/JunoPkg: Add HDLCD platform library

[evan . lloyd]

From: Girish Pathak 

This change adds the HDLCD platform lib for the Juno plaform. This
library will be instantiated as a LcdPlatformLib to link with
LcdGraphicsOutputDxe for the Juno platform.

HDLCD platform library depends on the Arm SCMI DXE driver for
communication with the SCP for clock setting. Therefore this change also
enables building of Arm SCMI DXE driver for the Juno platform.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
---
 Platform/ARM/JunoPkg/ArmJuno.dec |   8 +
 Platform/ARM/JunoPkg/ArmJuno.dsc |  29 +
 Platform/ARM/JunoPkg/ArmJuno.fdf |  12 +-
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf   |   5 +-
 Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf |  40 ++
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c |  18 +-
 Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJuno.c  | 559 

 7 files changed, 668 insertions(+), 3 deletions(-)

diff --git a/Platform/ARM/JunoPkg/ArmJuno.dec b/Platform/ARM/JunoPkg/ArmJuno.dec
index 
b733480c3198d135df16ca024b5e85ff350e11c7..cd6710feb2faf0bd17b5ea39a21dbe5406cd4ffd
 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dec
+++ b/Platform/ARM/JunoPkg/ArmJuno.dec
@@ -53,3 +53,11 @@ [PcdsFixedAtBuild.common]
   gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxBase|0x2E00|UINT64|0x0025
   gArmJunoTokenSpaceGuid.PcdArmMtlMailBoxSize|0x80|UINT32|0x0026
 
+  # MaxMode must be one number higher than the actual max mode,
+  # i.e. for actual maximum mode 2, set the value to 3.
+  #
+  # Default value zero allows platform to enumerate maximum supported mode.
+  #
+  # For a list of mode numbers look in HdLcdArmJuno.c
+  gArmJunoTokenSpaceGuid.PcdArmHdLcdMaxMode|0|UINT32|0x0017
+
diff --git a/Platform/ARM/JunoPkg/ArmJuno.dsc b/Platform/ARM/JunoPkg/ArmJuno.dsc
index 
fe860956a4dc497cac52be70bab3657246a08bd0..9027c5b0728a6941f850636b3bc315fd33b867fb
 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.dsc
+++ b/Platform/ARM/JunoPkg/ArmJuno.dsc
@@ -50,6 +50,11 @@ [LibraryClasses.common]
   # SCMI Mailbox Transport Layer
   ArmMtl|Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
 
+!ifndef HEADLESS_PLATFORM
+  
LcdPlatformLib|Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf
+  LcdHwLib|ArmPlatformPkg/Library/HdLcd/HdLcd.inf
+!endif
+
 [LibraryClasses.common.SEC]
   PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
   
ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
@@ -100,7 +105,15 @@ [PcdsFixedAtBuild.common]
 
   # System Memory (2GB - 16MB of Trusted DRAM at the top of the 32bit address 
space)
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0x8000
+
+!ifdef HEADLESS_PLATFORM
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x7F00
+!else
+  gArmTokenSpaceGuid.PcdSystemMemorySize|0x7B00
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase|0xFB00
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize|0x0400
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdSwapBlueRedSelect|TRUE
+!endif
 
   # Juno Dual-Cluster profile
   gArmPlatformTokenSpaceGuid.PcdCoreCount|6
@@ -142,6 +155,11 @@ [PcdsFixedAtBuild.common]
   gArmTokenSpaceGuid.PcdGicDistributorBase|0x2C01
   gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x2C02F000
 
+!ifndef HEADLESS_PLATFORM
+  # ARM Juno HDLCD Base
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x7FF6
+!endif
+
   #
   # PLDA PCI Root Complex
   #
@@ -314,6 +332,11 @@ [Components.common]
   MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
   
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
+!ifndef HEADLESS_PLATFORM
+  # Graphic Output Protocol
+  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.inf
+!endif
+
   #
   # Juno platform driver
   #
@@ -347,6 +370,12 @@ [Components.common]
   BdsLib|Platform/ARM/Library/BdsLib/BdsLib.inf
   }
 
+  # SCMI Driver
+  ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf {
+
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
+  }
+
 [Components.AARCH64]
   #
   # EBC
diff --git a/Platform/ARM/JunoPkg/ArmJuno.fdf b/Platform/ARM/JunoPkg/ArmJuno.fdf
index 
ee9d0e7f4f6e6ac99ded6a14e88eb2c7854dd473..0b62760cbb3ff93490204ac636b41d5a867dfb80
 100644
--- a/Platform/ARM/JunoPkg/ArmJuno.fdf
+++ b/Platform/ARM/JunoPkg/ArmJuno.fdf
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2013-2015, ARM Limited. All rights reserved.
+#  Copyright (c) 2013-2017, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -163,6 +163,13 @@ [FV.FvMain]
   INF MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
   INF 
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
+!ifndef 

[edk2] [PATCH edk2-platforms v2 12/18] ARM/VExpressPkg: Redefine LcdPlatformGetTimings function

[evan . lloyd]

From: Girish Pathak 

The LcdPlatformGetTimings interface function takes similar sets of
multiple parameters for horizontal and vertical timings which can be
aggregated in a common data type. This change defines a structure
SCAN_TIMINGS for this which can be used to describe both horizontal and
vertical scan timings, and accordingly redefines the
LcdPlatformGetTiming interface, greatly reducing the amount of data
passed about.

Similarly the mode definition tables are also changed to use this data
type and thus enable pass through access.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
| 104 +---
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
| 168 
 2 files changed, 108 insertions(+), 164 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
8496a0215bc78585b546f63312c9d7f1ad07adb6..b448d70f86d6acbc6bdae9749c7b6d0205935ba7
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -30,57 +30,51 @@
 
 typedef struct {
   UINT32 Mode;
-  UINT32 HorizontalResolution;
-  UINT32 VerticalResolution;
   UINT32 OscFreq;
 
   // These are used by HDLCD
-  UINT32 HSync;
-  UINT32 HBackPorch;
-  UINT32 HFrontPorch;
-  UINT32 VSync;
-  UINT32 VBackPorch;
-  UINT32 VFrontPorch;
-} LCD_RESOLUTION;
+  SCAN_TIMINGS   Horizontal;
+  SCAN_TIMINGS   Vertical;
+} DISPLAY_MODE;
 
 /** The display modes supported by the platform.
 **/
-STATIC CONST LCD_RESOLUTION mResolutions[] = {
+STATIC CONST DISPLAY_MODE mDisplayModes[] = {
   { // Mode 0 : VGA : 640 x 480 x 24 bpp
-VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS,
+VGA,
 VGA_OSC_FREQUENCY,
-VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH,
-VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH
+{VGA_H_RES_PIXELS, VGA_H_SYNC, VGA_H_BACK_PORCH, VGA_H_FRONT_PORCH},
+{VGA_V_RES_PIXELS, VGA_V_SYNC, VGA_V_BACK_PORCH, VGA_V_FRONT_PORCH}
   },
   { // Mode 1 : SVGA : 800 x 600 x 24 bpp
-SVGA, SVGA_H_RES_PIXELS, SVGA_V_RES_PIXELS,
+SVGA,
 SVGA_OSC_FREQUENCY,
-SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH,
-SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH
+{SVGA_H_RES_PIXELS, SVGA_H_SYNC, SVGA_H_BACK_PORCH, SVGA_H_FRONT_PORCH},
+{SVGA_V_RES_PIXELS, SVGA_V_SYNC, SVGA_V_BACK_PORCH, SVGA_V_FRONT_PORCH}
   },
   { // Mode 2 : XGA : 1024 x 768 x 24 bpp
-XGA, XGA_H_RES_PIXELS, XGA_V_RES_PIXELS,
+XGA,
 XGA_OSC_FREQUENCY,
-XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH,
-XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH
+{XGA_H_RES_PIXELS, XGA_H_SYNC, XGA_H_BACK_PORCH, XGA_H_FRONT_PORCH},
+{XGA_V_RES_PIXELS, XGA_V_SYNC, XGA_V_BACK_PORCH, XGA_V_FRONT_PORCH}
   },
   { // Mode 3 : SXGA : 1280 x 1024 x 24 bpp
-SXGA, SXGA_H_RES_PIXELS, SXGA_V_RES_PIXELS,
+SXGA,
 (SXGA_OSC_FREQUENCY/2),
-SXGA_H_SYNC, SXGA_H_BACK_PORCH, SXGA_H_FRONT_PORCH,
-SXGA_V_SYNC, SXGA_V_BACK_PORCH, SXGA_V_FRONT_PORCH
+{SXGA_H_RES_PIXELS, SXGA_H_SYNC, SXGA_H_BACK_PORCH, SXGA_H_FRONT_PORCH},
+{SXGA_V_RES_PIXELS, SXGA_V_SYNC, SXGA_V_BACK_PORCH, SXGA_V_FRONT_PORCH}
   },
   { // Mode 4 : UXGA : 1600 x 1200 x 24 bpp
-UXGA, UXGA_H_RES_PIXELS, UXGA_V_RES_PIXELS,
+UXGA,
 (UXGA_OSC_FREQUENCY/2),
-UXGA_H_SYNC, UXGA_H_BACK_PORCH, UXGA_H_FRONT_PORCH,
-UXGA_V_SYNC, UXGA_V_BACK_PORCH, UXGA_V_FRONT_PORCH
+{UXGA_H_RES_PIXELS, UXGA_H_SYNC, UXGA_H_BACK_PORCH, UXGA_H_FRONT_PORCH},
+{UXGA_V_RES_PIXELS, UXGA_V_SYNC, UXGA_V_BACK_PORCH, UXGA_V_FRONT_PORCH}
   },
   { // Mode 5 : HD : 1920 x 1080 x 24 bpp
-HD, HD_H_RES_PIXELS, HD_V_RES_PIXELS,
+HD,
 (HD_OSC_FREQUENCY/2),
-HD_H_SYNC, HD_H_BACK_PORCH, HD_H_FRONT_PORCH,
-HD_V_SYNC, HD_V_BACK_PORCH, HD_V_FRONT_PORCH
+{HD_H_RES_PIXELS, HD_H_SYNC, HD_H_BACK_PORCH, HD_H_FRONT_PORCH},
+{HD_V_RES_PIXELS, HD_V_SYNC, HD_V_BACK_PORCH, HD_V_FRONT_PORCH}
   }
 };
 
@@ -205,7 +199,7 @@ LcdPlatformGetMaxMode (VOID)
 {
   // The following line will report correctly the total number of graphics 
modes
   // that could be supported by the graphics driver
-  return (sizeof (mResolutions) / sizeof (LCD_RESOLUTION));
+  return (sizeof (mDisplayModes) / sizeof (DISPLAY_MODE));
 }
 
 /** Set the requested display mode.
@@ -242,7 +236,7 @@ LcdPlatformSetMode (
   // Set the DVI into the new mode
   Status = ArmPlatformSysConfigSet (
  SYS

[edk2] [PATCH edk2-platforms v2 14/18] ARM/VExpressPkg: Reserving framebuffer at build

[evan . lloyd]

From: Girish Pathak 

This change uses two PCDs, PcdArmLcdFrameBufferBase and
PcdArmLcdFrameBufferSize introduced in correspondiong EDK2 patch to
reserve framebuffer in DRAM if these values are defined in platform
specific DSC file, avoiding the need to allocate dynamically.
This allows the framebuffer to appear as "I/O memory" outside of the
normal RAM map, which is similar to the "VRAM" case.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf |  4 
+++-
 Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c  | 20 
++--
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf 
b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
index 
4cbd2ff4b4faf11ccd4fe30117708d7cc4c1bf0e..c70c4ce64826174e6d15611de640ad3b902835b9
 100644
--- a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
+++ b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf
@@ -1,5 +1,5 @@
 #/* @file
-#  Copyright (c) 2011-2014, ARM Limited. All rights reserved.
+#  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -57,6 +57,8 @@ [FixedPcd]
   gArmTokenSpaceGuid.PcdArmPrimaryCore
 
   gArmPlatformTokenSpaceGuid.PcdCoreCount
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize
 
 [Ppis]
   gArmMpCoreInfoPpiGuid
diff --git a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c 
b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
index 
6379e81751fca5e7972c5c30f305be65fd1ae71d..1e8f3205312ebf30fa1666130bc944261384359a
 100644
--- a/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
+++ b/Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2011-2016, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
 *
 *  This program and the accompanying materials
 *  are licensed and made available under the terms and conditions of the BSD 
License
@@ -20,8 +20,10 @@
 #include 
 #include 
 
+#define FRAME_BUFFER_DESCRIPTOR ((FixedPcdGet64 (PcdArmLcdDdrFrameBufferBase) 
!= 0) ? 1 : 0)
+
 // Number of Virtual Memory Map Descriptors
-#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS  9
+#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS (9 + FRAME_BUFFER_DESCRIPTOR)
 
 // DDR attributes
 #define DDR_ATTRIBUTES_CACHED   ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
@@ -142,6 +144,20 @@ ArmPlatformGetVirtualMemoryMap (
   //
   VirtualMemoryTable[Index].Attributes = 
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
 
+  // Map region for the frame buffer in the system RAM
+#if (FixedPcdGet32 (PcdArmLcdDdrFrameBufferSize) != 0)
+  VirtualMemoryTable[++Index].PhysicalBase = FixedPcdGet64 
(PcdArmLcdDdrFrameBufferBase);
+  VirtualMemoryTable[Index].VirtualBase = FixedPcdGet64 
(PcdArmLcdDdrFrameBufferBase);
+  VirtualMemoryTable[Index].Length = FixedPcdGet32 
(PcdArmLcdDdrFrameBufferSize);
+  // Map as Normal Non-Cacheable memory, so that we can use the accelerated
+  // SetMem/CopyMem routines that may use unaligned accesses or
+  // DC ZVA instructions. If mapped as device memory, these routine may cause
+  // alignment faults.
+  // NOTE: The attribute value is misleading, it indicates memory map type as
+  // an un-cached, un-buffered but allows buffering and reordering.
+  VirtualMemoryTable[Index].Attributes = 
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED;
+#endif
+
   // Map sparse memory region if present
   if (HasSparseMemory) {
 VirtualMemoryTable[++Index].PhysicalBase = SparseMemoryBase;
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 16/18] ARM/JunoPkg: Mapping Non-Trused SRAM as device memory

[evan . lloyd]

From: Girish Pathak 

This fix changes the cache attribute of Non-Trusted SRAM on the Juno
platform to device memory. This change is required to avoid coherency
problems as Non-Trusted SRAM is used as a shared memory between the
application processor and the SCP for communication. This change is a
prerequisite for upcoming SCMI driver for the Juno platform.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
---
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c 
b/Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c
index 
aa8d7d9c3b0d41e62d1849e6e88760e3066617f7..afb2db0050c65b0d1b2b69c9038e168755c152c1
 100644
--- a/Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c
+++ b/Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2013-2015, ARM Limited. All rights reserved.
+*  Copyright (c) 2013-2017, ARM Limited. All rights reserved.
 *
 *  This program and the accompanying materials
 *  are licensed and made available under the terms and conditions of the BSD 
License
@@ -111,7 +111,9 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[++Index].PhysicalBase  = ARM_JUNO_NON_SECURE_SRAM_BASE;
   VirtualMemoryTable[Index].VirtualBase = ARM_JUNO_NON_SECURE_SRAM_BASE;
   VirtualMemoryTable[Index].Length  = ARM_JUNO_NON_SECURE_SRAM_SZ;
-  VirtualMemoryTable[Index].Attributes  = CacheAttributes;
+  // This memory is shared between the application processor
+  // and the SCP. To avoid coherency problems, map it as device memory.
+  VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
   // PCI Root Complex
   VirtualMemoryTable[++Index].PhysicalBase  = PcdGet64 
(PcdPcieControlBaseAddress);
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 05/18] ARM/VExpressPkg: PL111 and HDLCD: add const qualifier

[evan . lloyd]

From: Girish Pathak 

This change adds some STATIC and CONST qualifiers (mainly to arguments
of  functions) in PL111 and HdLcd platform libraries.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
| 34 ++--
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
| 32 +-
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
e4d0a4c8407835df6ab62c02d18531c4d3f08c97..6afd764897f49c64490ce891682f99bb0f5d993b
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -46,7 +46,7 @@ typedef struct {
 
 /** The display modes supported by the platform.
 **/
-LCD_RESOLUTION mResolutions[] = {
+STATIC CONST LCD_RESOLUTION mResolutions[] = {
   { // Mode 0 : VGA : 640 x 480 x 24 bpp
 VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
 VGA_OSC_FREQUENCY,
@@ -146,8 +146,8 @@ LcdPlatformInitializeDisplay (
 **/
 EFI_STATUS
 LcdPlatformGetVram (
-  OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
-  OUT UINTN* VramSize
+  OUT EFI_PHYSICAL_ADDRESS * CONST  VramBaseAddress,
+  OUT UINTN * CONST VramSize
   )
 {
   EFI_STATUS  Status;
@@ -215,7 +215,7 @@ LcdPlatformGetMaxMode (VOID)
 **/
 EFI_STATUS
 LcdPlatformSetMode (
-  IN UINT32 ModeNumber
+  IN CONST UINT32 ModeNumber
   )
 {
   EFI_STATUSStatus;
@@ -275,8 +275,8 @@ LcdPlatformSetMode (
 **/
 EFI_STATUS
 LcdPlatformQueryMode (
-  IN  UINT32ModeNumber,
-  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *Info
+  IN CONST UINT32   ModeNumber,
+  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION * CONST  Info
   )
 {
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
@@ -332,15 +332,15 @@ LcdPlatformQueryMode (
 **/
 EFI_STATUS
 LcdPlatformGetTimings (
-  IN  UINT32  ModeNumber,
-  OUT UINT32* HRes,
-  OUT UINT32* HSync,
-  OUT UINT32* HBackPorch,
-  OUT UINT32* HFrontPorch,
-  OUT UINT32* VRes,
-  OUT UINT32* VSync,
-  OUT UINT32* VBackPorch,
-  OUT UINT32* VFrontPorch
+  IN  CONST UINT32  ModeNumber,
+  OUT UINT32 * CONSTHRes,
+  OUT UINT32 * CONSTHSync,
+  OUT UINT32 * CONSTHBackPorch,
+  OUT UINT32 * CONSTHFrontPorch,
+  OUT UINT32 * CONSTVRes,
+  OUT UINT32 * CONSTVSync,
+  OUT UINT32 * CONSTVBackPorch,
+  OUT UINT32 * CONSTVFrontPorch
   )
 {
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
@@ -371,8 +371,8 @@ LcdPlatformGetTimings (
 **/
 EFI_STATUS
 LcdPlatformGetBpp (
-  IN  UINT32  ModeNumber,
-  OUT LCD_BPP  *  Bpp
+  IN CONST UINT32ModeNumber,
+  OUT LCD_BPP * CONSTBpp
   )
 {
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 
0bbd40ceeb850209cd4842f34e72a0b635309a15..799fb3fc781ce04bb64cb1fa0b87f262a670ed78
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -197,8 +197,8 @@ LcdPlatformInitializeDisplay (
 **/
 EFI_STATUS
 LcdPlatformGetVram (
-  OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
-  OUT UINTN* VramSize
+  OUT EFI_PHYSICAL_ADDRESS * CONST VramBaseAddress,
+  OUT UINTN * CONSTVramSize
   )
 {
   EFI_STATUS  Status;
@@ -284,7 +284,7 @@ LcdPlatformGetMaxMode (VOID)
 **/
 EFI_STATUS
 LcdPlatformSetMode (
-  IN UINT32 ModeNumber
+  IN CONST UINT32 ModeNumber
   )
 {
   EFI_STATUSStatus;
@@ -365,8 +365,8 @@ LcdPlatformSetMode (
 **/
 EFI_STATUS
 LcdPlatformQueryMode (
-  IN  UINT32ModeNumber,
-  OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *Info
+  IN CONST UINT32  ModeNumber,
+  OUT EFI_GRAPHICS_OUTPUT_MOD

[edk2] [PATCH edk2-platforms v2 07/18] ARM/VExpressPkg: PL111LcdArmVExpressLib: Minor code cleanup

[evan . lloyd]

From: Girish Pathak 

This minor change removes some unecessary initializations and variables
in PL111LcdArmVExpress.c

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
| 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 
fd4eea8f8e2397bc7d4ddf4cfe3dcc97a5109edb..11335bb2cef9d7ca2606d4a8671382bf3dc2d254
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -203,8 +203,6 @@ LcdPlatformGetVram (
 {
   EFI_STATUS  Status;
 
-  Status = EFI_SUCCESS;
-
   ASSERT (VramBaseAddress != NULL);
   ASSERT (VramSize != NULL);
 
@@ -214,6 +212,7 @@ LcdPlatformGetVram (
   case ARM_VE_MOTHERBOARD_SITE:
 *VramBaseAddress = (EFI_PHYSICAL_ADDRESS)PL111_CLCD_VRAM_MOTHERBOARD_BASE;
 *VramSize = LCD_VRAM_SIZE;
+Status = EFI_SUCCESS;
 break;
 
   case ARM_VE_DAUGHTERBOARD_1_SITE:
@@ -242,7 +241,6 @@ LcdPlatformGetVram (
 if (EFI_ERROR (Status)) {
   ASSERT (FALSE);
   gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
-  return Status;
 }
 break;
 
@@ -292,7 +290,6 @@ LcdPlatformSetMode (
   )
 {
   EFI_STATUSStatus;
-  UINT32LcdSite;
   UINT32OscillatorId;
   SYS_CONFIG_FUNCTION   Function;
   UINT32SysId;
@@ -302,9 +299,7 @@ LcdPlatformSetMode (
 return EFI_INVALID_PARAMETER;
   }
 
-  LcdSite = PL111_CLCD_SITE;
-
-  switch (LcdSite) {
+  switch (PL111_CLCD_SITE) {
   case ARM_VE_MOTHERBOARD_SITE:
 Function = SYS_CFG_OSC;
 OscillatorId = PL111_CLCD_MOTHERBOARD_VIDEO_MODE_OSC_ID;
@@ -349,11 +344,8 @@ LcdPlatformSetMode (
   }
 
   // Set the multiplexer
-  Status = ArmPlatformSysConfigSet (SYS_CFG_MUXFPGA, LcdSite);
-  if (EFI_ERROR (Status)) {
-ASSERT_EFI_ERROR (Status);
-return Status;
-  }
+  Status = ArmPlatformSysConfigSet (SYS_CFG_MUXFPGA, PL111_CLCD_SITE);
+  ASSERT_EFI_ERROR (Status);
 
   return Status;
 }
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 06/18] ARM/VExpressPkg: Add and update debug ASSERTS

[evan . lloyd]

From: Girish Pathak 

This change adds some debug assertions e.g to catch NULL pointer errors
missing in PL11Lcd and HdLcd platform libraries.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c   
| 22 +-
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
| 24 +++-
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
6afd764897f49c64490ce891682f99bb0f5d993b..a8fe8696da0653017ce9fa6e4a86caf283bc04c9
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -153,6 +153,9 @@ LcdPlatformGetVram (
   EFI_STATUS  Status;
   EFI_ALLOCATE_TYPE   AllocationType;
 
+  ASSERT (VramBaseAddress != NULL);
+  ASSERT (VramSize != NULL);
+
   // Set the vram size
   *VramSize = LCD_VRAM_SIZE;
 
@@ -171,6 +174,7 @@ LcdPlatformGetVram (
   VramBaseAddress
   );
   if (EFI_ERROR (Status)) {
+ASSERT (FALSE);
 return Status;
   }
 
@@ -181,8 +185,8 @@ LcdPlatformGetVram (
   *VramSize,
   EFI_MEMORY_WC
   );
-  ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
+ASSERT (FALSE);
 gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
 return Status;
   }
@@ -221,6 +225,7 @@ LcdPlatformSetMode (
   EFI_STATUSStatus;
 
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
@@ -279,7 +284,10 @@ LcdPlatformQueryMode (
   OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION * CONST  Info
   )
 {
+  ASSERT (Info != NULL);
+
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
@@ -343,7 +351,18 @@ LcdPlatformGetTimings (
   OUT UINT32 * CONSTVFrontPorch
   )
 {
+  // One of the pointers is NULL
+  ASSERT (HRes != NULL);
+  ASSERT (HSync != NULL);
+  ASSERT (HBackPorch != NULL);
+  ASSERT (HFrontPorch != NULL);
+  ASSERT (VRes != NULL);
+  ASSERT (VSync != NULL);
+  ASSERT (VBackPorch != NULL);
+  ASSERT (VFrontPorch != NULL);
+
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
@@ -376,6 +395,7 @@ LcdPlatformGetBpp (
   )
 {
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 
799fb3fc781ce04bb64cb1fa0b87f262a670ed78..fd4eea8f8e2397bc7d4ddf4cfe3dcc97a5109edb
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -205,6 +205,9 @@ LcdPlatformGetVram (
 
   Status = EFI_SUCCESS;
 
+  ASSERT (VramBaseAddress != NULL);
+  ASSERT (VramSize != NULL);
+
   // Is it on the motherboard or on the daughterboard?
   switch (PL111_CLCD_SITE) {
 
@@ -225,6 +228,7 @@ LcdPlatformGetVram (
 VramBaseAddress
 );
 if (EFI_ERROR (Status)) {
+  ASSERT (FALSE);
   return Status;
 }
 
@@ -235,8 +239,8 @@ LcdPlatformGetVram (
 *VramSize,
 EFI_MEMORY_WC
 );
-ASSERT_EFI_ERROR (Status);
 if (EFI_ERROR (Status)) {
+  ASSERT (FALSE);
   gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
   return Status;
 }
@@ -294,6 +298,7 @@ LcdPlatformSetMode (
   UINT32SysId;
 
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
@@ -369,7 +374,10 @@ LcdPlatformQueryMode (
   OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION * CONST Info
   )
 {
+  ASSERT (Info != NULL);
+
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
@@ -433,7 +441,18 @@ LcdPlatformGetTimings (
   OUT UINT32 * CONST  VFrontPorch
   )
 {
+  // One of the pointers is NULL
+  ASSERT (HRes != NULL);
+  ASSERT (HSync != NULL);
+  ASSERT (HBackPorch != NULL);
+  ASSERT (HFrontPorch != NULL);
+  ASSERT (VRes != NULL);
+  ASSERT (VSync != NULL);
+  ASSERT (VBackPorch != NULL);
+  ASSERT (VFrontPorch != NULL);
+
   if (ModeNumber >= LcdPlatformGetMaxMode ()) {
+ASSERT (FALSE);
 return EFI_INVALID_PARAMETER;
   }
 
@@ -465,7 +484,10 @@ LcdPlatformGetBpp (
   OUT 

[edk2] [PATCH edk2-platforms v2 03/18] ARM/VExpressPkg: Tidy HdLcd/PL111Lcd code: Updated comments

[evan . lloyd]

From: Girish Pathak 

There is no functional modification in this change.
In this change some comments in HDLCD and PL111LCD platform library
code are modified and a few new comments are added. This is to
prevent mixing formatting changes with functional changes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 
Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  2 +-
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
| 74 
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c  
| 73 +++
 3 files changed, 148 insertions(+), 1 deletion(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
index 
335c84841a4ff4b57c0d495bc48e93579b5ce576..e97febb91c89f82f8cad12823f5ffe182e87f8cd
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
@@ -1,6 +1,6 @@
 #/** @file
 #
-#  Component description file for ArmVeGraphicsDxe module
+#  Component description file for PL111LcdArmVExpressLib module
 #
 #  Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
 #
diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
851ba83b79f0fea7019269c30e7add58f5ff9cb2..e4d0a4c8407835df6ab62c02d18531c4d3f08c97
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -44,6 +44,8 @@ typedef struct {
   UINT32 VFrontPorch;
 } LCD_RESOLUTION;
 
+/** The display modes supported by the platform.
+**/
 LCD_RESOLUTION mResolutions[] = {
   { // Mode 0 : VGA : 640 x 480 x 24 bpp
 VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS, LCD_BITS_PER_PIXEL_24,
@@ -93,6 +95,13 @@ EFI_EDID_ACTIVE_PROTOCOL  mEdidActive = {
   NULL
 };
 
+/** HDLCD platform specific initialization function.
+
+  @param[in] Handle  Handle to the LCD device instance.
+
+  @retval EFI_SUCCESSPlaform library initialized successfully.
+  @retval !(EFI_SUCCESS) Other errors.
+**/
 EFI_STATUS
 LcdPlatformInitializeDisplay (
   IN EFI_HANDLE   Handle
@@ -123,6 +132,18 @@ LcdPlatformInitializeDisplay (
   return Status;
 }
 
+/** Allocate VRAM memory in DRAM for the frame buffer
+  (unless it is reserved already).
+
+  The allocated address can be used to set the frame buffer.
+
+  @param[out] VramBaseAddress A pointer to the frame buffer address.
+  @param[out] VramSizeA pointer to the size of the frame
+  buffer in bytes
+
+  @retval EFI_SUCCESS Frame buffer memory allocated successfully.
+  @retval !(EFI_SUCCESS)  Other errors.
+**/
 EFI_STATUS
 LcdPlatformGetVram (
   OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
@@ -169,6 +190,13 @@ LcdPlatformGetVram (
   return EFI_SUCCESS;
 }
 
+/** Return total number of modes supported.
+
+  Note: Valid mode numbers are 0 to MaxMode - 1
+  See Section 12.9 of the UEFI Specification 2.7
+
+  @retval UINT32 Mode Number.
+**/
 UINT32
 LcdPlatformGetMaxMode (VOID)
 {
@@ -177,6 +205,14 @@ LcdPlatformGetMaxMode (VOID)
   return (sizeof (mResolutions) / sizeof (LCD_RESOLUTION));
 }
 
+/** Set the requested display mode.
+
+  @param[in] ModeNumber Mode Number.
+
+  @retval EFI_SUCCESS   Mode set successfully.
+  @retval EFI_INVALID_PARAMETER Requested mode not found.
+  @retval !(EFI_SUCCESS)Other errors.
+**/
 EFI_STATUS
 LcdPlatformSetMode (
   IN UINT32 ModeNumber
@@ -226,6 +262,17 @@ LcdPlatformSetMode (
   return Status;
 }
 
+/** Return information for the requested mode number.
+
+  @param[in]  ModeNumber  Mode Number.
+
+  @param[out] InfoPointer for returned mode information
+  (on success).
+
+  @retval EFI_SUCCESS Mode information for the requested mode
+  returned successfully.
+  @retval EFI_INVALID_PARAMETER   Requested mode not found.
+**/
 EFI_STATUS
 LcdPlatformQueryMode (
   IN  UINT32ModeNumber,
@@ -266,6 +313,23 @@ LcdPlatformQueryMode (
   return EFI_SUCCESS;
 }
 
+/** Return display timing information for the requested mode number.
+
+  @param[in]  ModeNumber  Mode Number.
+
+  @param[out] HResPointer to horizontal resolution.
+  @param[out] HSync   Pointer to horizontal sync width.
+  @param[out] HBackPorch  Pointer to hor

[edk2] [PATCH edk2-platforms v2 13/18] ARM/VExpressPkg: PL111 and HDLCD: Add PCD to select pixel format

[evan . lloyd]

From: Girish Pathak 

Current HDLCD and PL111 platform libraries do not support display modes
with PixelBlueGreenRedReserved8BitPerColor format,  i.e. because of
historical confusion, they do not support the UEFI default
PixelBlueGreenRedReserved8BitPerColor

LcdPlatformLib for PL111, LcdPlatformQueryMode function returns the
pixel format as PixelRedGreenBlueReserved8BitPerColor which is wrong,
because that does not match the display controller's pixel format which
is set to BGR in PL111Lcd GOP driver.

Also it is not possible to configure pixel format as RGB/BGR for the
display modes for a platform at build time.

This change adds PcdGopPixelFormat to configure pixel format as
PixelRedGreenBlueReserved8BitPerColoror
PixelBlueGreenRedReserved8BitPerColoror
PixelBitMask.
With this change, pixel format can be selected in the platform specific
.dsc file for all supported display modes.

Support for PixelBitMask is not implemented in PL111 or HDLCD
GOP driver, hence  HDLCD and PL111 platform libraries will return error
EFI_UNSUPPORTED if PcdGopPixelFormat is set to PixelBitMask.
Indeed, it is not clear what selecting PixelBitMask might mean, but
the option is allowed as it might suit a custom platform.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf   
|  1 +
 
Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |  1 +
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
| 23 
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c  
| 38 +---
 4 files changed, 35 insertions(+), 28 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
index 
2e83736609cf8c63cb498368cd377f6a23964ef4..4cbd324338be76a0b0bfb811159d893628e74155
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
@@ -41,3 +41,4 @@ [Protocols]
 
 [FixedPcd]
   gArmVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId
+  gArmPlatformTokenSpaceGuid.PcdGopPixelFormat
diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
index 
1ee878041559fa84a810f65175f2507bda663d76..20045380149241ce14f41bcb70afcb8145fe821f
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
@@ -42,3 +42,4 @@ [Protocols]
 [FixedPcd]
   gArmVExpressTokenSpaceGuid.PcdPL111LcdMaxMode
   gArmVExpressTokenSpaceGuid.PcdPL111LcdVideoModeOscId
+  gArmPlatformTokenSpaceGuid.PcdGopPixelFormat
diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
b448d70f86d6acbc6bdae9749c7b6d0205935ba7..f1c18ac955f621e9eab3dede86758f5f1b1a791d
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -15,7 +15,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -93,6 +92,10 @@ EFI_EDID_ACTIVE_PROTOCOL  mEdidActive = {
   @param[in] Handle  Handle to the LCD device instance.
 
   @retval EFI_SUCCESSPlaform library initialized successfully.
+  @retval EFI_UNSUPPORTEDPcdGopPixelFormat must be
+ PixelRedGreenBlueReserved8BitPerColor OR
+ PixelBlueGreenRedReserved8BitPerColor
+ any other format is not supported.
   @retval !(EFI_SUCCESS) Other errors.
 **/
 EFI_STATUS
@@ -101,6 +104,17 @@ LcdPlatformInitializeDisplay (
   )
 {
   EFI_STATUS  Status;
+  EFI_GRAPHICS_PIXEL_FORMAT PixelFormat;
+
+  // PixelBitMask and PixelBltOnly pixel formats are not supported
+  PixelFormat = FixedPcdGet32 (PcdGopPixelFormat);
+  if (PixelFormat != PixelRedGreenBlueReserved8BitPerColor
+&& PixelFormat != PixelBlueGreenRedReserved8BitPerColor) {
+
+ASSERT (PixelFormat == PixelRedGreenBlueReserved8BitPerColor
+  ||  PixelFormat == PixelBlueGreenRedReserved8BitPerColor);
+   return EFI_UNSUPPORTED;
+  }
 
   // Set the FPGA multiplexer to select the video output from the
   // motherboard or the daughterboard
@@ -285,12 +299,7 @@ LcdPlatformQueryMode (
   Info->VerticalResolution = mDisplayModes[ModeNumber].Vertical.Resolution;
   Info->PixelsPerScanLine = mDisplayModes[ModeNum

[edk2] [PATCH edk2-platforms v2 09/18] ARM/VExpressPkg: PL11LcdArmVExpressLib: Improvement conditional

[evan . lloyd]

From: Girish Pathak 

PL111_CLCD_SITE and ARM_VE_MOTHERBOARD_SITE are both constants and
available at build time. Use conditional compilation to process the code
based on the value of PL111_CLCD_SITE, instead of selecting code in a
switch statement at runtime.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
| 40 +++-
 1 file changed, 14 insertions(+), 26 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 
92918bb4ee6811db47791a435bc06a6dc77ae9a3..cf50b20fd9b1b44a81963655c2f88305ce6bdc67
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -206,16 +206,11 @@ LcdPlatformGetVram (
   ASSERT (VramBaseAddress != NULL);
   ASSERT (VramSize != NULL);
 
-  // Is it on the motherboard or on the daughterboard?
-  switch (PL111_CLCD_SITE) {
-
-  case ARM_VE_MOTHERBOARD_SITE:
+#if (PL111_CLCD_SITE == ARM_VE_MOTHERBOARD_SITE)
 *VramBaseAddress = (EFI_PHYSICAL_ADDRESS)PL111_CLCD_VRAM_MOTHERBOARD_BASE;
 *VramSize = LCD_VRAM_SIZE;
 Status = EFI_SUCCESS;
-break;
-
-  case ARM_VE_DAUGHTERBOARD_1_SITE:
+#elif (PL111_CLCD_SITE == ARM_VE_DAUGHTERBOARD_1_SITE)
 *VramBaseAddress = (EFI_PHYSICAL_ADDRESS)LCD_VRAM_CORE_TILE_BASE;
 *VramSize = LCD_VRAM_SIZE;
 
@@ -242,13 +237,9 @@ LcdPlatformGetVram (
   ASSERT (FALSE);
   gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
 }
-break;
-
-  default:
-// Unsupported site
-Status = EFI_UNSUPPORTED;
-break;
-  }
+#else
+#error PL111LcdVExpressLib: Unsupported PL111_CLCD_SITE
+#endif // (PL111_CLCD_SITE == ARM_VE_MOTHERBOARD_SITE)
 
   return Status;
 }
@@ -299,18 +290,15 @@ LcdPlatformSetMode (
 return EFI_INVALID_PARAMETER;
   }
 
-  switch (PL111_CLCD_SITE) {
-  case ARM_VE_MOTHERBOARD_SITE:
-Function = SYS_CFG_OSC;
-OscillatorId = PL111_CLCD_MOTHERBOARD_VIDEO_MODE_OSC_ID;
-break;
-  case ARM_VE_DAUGHTERBOARD_1_SITE:
-Function = SYS_CFG_OSC_SITE1;
-OscillatorId = FixedPcdGet32 (PcdPL111LcdVideoModeOscId);
-break;
-  default:
-return EFI_UNSUPPORTED;
-  }
+#if (PL111_CLCD_SITE == ARM_VE_MOTHERBOARD_SITE)
+  Function = SYS_CFG_OSC;
+  OscillatorId = PL111_CLCD_MOTHERBOARD_VIDEO_MODE_OSC_ID;
+#elif (PL111_CLCD_SITE == ARM_VE_DAUGHTERBOARD_1_SITE)
+  Function = SYS_CFG_OSC_SITE1;
+  OscillatorId = FixedPcdGet32 (PcdPL111LcdVideoModeOscId);
+#else
+#error PL111LcdVExpressLib: Unsupported PL111_CLCD_SITE
+#endif // (PL111_CLCD_SITE == ARM_VE_MOTHERBOARD_SITE)
 
   // Set the video mode oscillator
   Status = ArmPlatformSysConfigSetDevice (
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 08/18] ARM/VExpressPkg: PL111 and HDLCD: Use FixedPcdGet32

[evan . lloyd]

From: Girish Pathak 

This change replaces PcdGet32 with FixedPcdGet32 for the PCDs which
are defined as fixed PCDs.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf   
| 2 +-
 
Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 | 2 +-
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
| 2 +-
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c  
| 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
index 
52158c4771b5b7651e234fdd73208dcae14c1025..2e83736609cf8c63cb498368cd377f6a23964ef4
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
@@ -39,5 +39,5 @@ [Protocols]
   gEfiEdidDiscoveredProtocolGuid# Produced
   gEfiEdidActiveProtocolGuid# Produced
 
-[Pcd]
+[FixedPcd]
   gArmVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId
diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
index 
e97febb91c89f82f8cad12823f5ffe182e87f8cd..1ee878041559fa84a810f65175f2507bda663d76
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
@@ -39,6 +39,6 @@ [Protocols]
   gEfiEdidDiscoveredProtocolGuid# Produced
   gEfiEdidActiveProtocolGuid# Produced
 
-[Pcd]
+[FixedPcd]
   gArmVExpressTokenSpaceGuid.PcdPL111LcdMaxMode
   gArmVExpressTokenSpaceGuid.PcdPL111LcdVideoModeOscId
diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
a8fe8696da0653017ce9fa6e4a86caf283bc04c9..f8d19df79260cdfbe1876d6ccc10d49abd0637cf
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -233,7 +233,7 @@ LcdPlatformSetMode (
   do {
 Status = ArmPlatformSysConfigSetDevice (
SYS_CFG_OSC_SITE1,
-   PcdGet32 (PcdHdLcdVideoModeOscId),
+   FixedPcdGet32 (PcdHdLcdVideoModeOscId),
mResolutions[ModeNumber].OscFreq
);
   } while (Status == EFI_TIMEOUT);
diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
index 
11335bb2cef9d7ca2606d4a8671382bf3dc2d254..92918bb4ee6811db47791a435bc06a6dc77ae9a3
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c
@@ -272,7 +272,7 @@ LcdPlatformGetMaxMode (VOID)
   // certain limitations.
 
   // Set the maximum mode allowed
-  return (PcdGet32 (PcdPL111LcdMaxMode));
+  return (FixedPcdGet32 (PcdPL111LcdMaxMode));
 }
 
 /** Set the requested display mode.
@@ -306,7 +306,7 @@ LcdPlatformSetMode (
 break;
   case ARM_VE_DAUGHTERBOARD_1_SITE:
 Function = SYS_CFG_OSC_SITE1;
-OscillatorId = (UINT32)PcdGet32 (PcdPL111LcdVideoModeOscId);
+OscillatorId = FixedPcdGet32 (PcdPL111LcdVideoModeOscId);
 break;
   default:
 return EFI_UNSUPPORTED;
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 10/18] ARM/VExpressPkg: HdLcdArmVExpressLib: Remove status check EFI_TIMEOUT

[evan . lloyd]

From: Girish Pathak 

None of the ArmPlatformSys*  functions returns EFI_TIMEOUT. Hence checking
this in the do {} while loop in LcdPlatformSetMode is wrong. Therefore
remove this comparision and as a result remove the do {} while loop.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c | 22 

 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
index 
f8d19df79260cdfbe1876d6ccc10d49abd0637cf..533d7fa4777e8f22429e2ae63a828dcb5401b5c0
 100644
--- a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
+++ b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
@@ -230,25 +230,21 @@ LcdPlatformSetMode (
   }
 
   // Set the video mode oscillator
-  do {
-Status = ArmPlatformSysConfigSetDevice (
-   SYS_CFG_OSC_SITE1,
-   FixedPcdGet32 (PcdHdLcdVideoModeOscId),
-   mResolutions[ModeNumber].OscFreq
-   );
-  } while (Status == EFI_TIMEOUT);
+  Status = ArmPlatformSysConfigSetDevice (
+ SYS_CFG_OSC_SITE1,
+ FixedPcdGet32 (PcdHdLcdVideoModeOscId),
+ mResolutions[ModeNumber].OscFreq
+ );
   if (EFI_ERROR (Status)) {
 ASSERT_EFI_ERROR (Status);
 return Status;
   }
 
   // Set the DVI into the new mode
-  do {
-Status = ArmPlatformSysConfigSet (
-   SYS_CFG_DVIMODE,
-   mResolutions[ModeNumber].Mode
-   );
-  } while (Status == EFI_TIMEOUT);
+  Status = ArmPlatformSysConfigSet (
+ SYS_CFG_DVIMODE,
+ mResolutions[ModeNumber].Mode
+ );
   if (EFI_ERROR (Status)) {
 ASSERT_EFI_ERROR (Status);
 return Status;
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 00/18] ARM: Update GOP

[evan . lloyd]

From: EvanLloyd 

This patch series addresses comments on the original
(https://lists.01.org/pipermail/edk2-devel/2017-September/015356.html)
reworking of the Graphics Output Protocol code in Platform/ARM.
It also contains updates for the new SCMI protocol (MTL Library).

After a number of format and quality modifications, several errors
are corrected and new functionality added for Mali DP.

The changes are tested on Juno, and FVP.

Code is available for examination at:
  https://github.com/EvanLloyd/edk2-platforms/tree/166_gop_v2

Ard Biesheuvel (1):
  ARM/VExpressPkg: Fix MODULE_TYPE of HDLCD/PL111 platform libraries

EvanLloyd (1):
  ARM/VExpressPkg: HdLcdArmVExpressLib: Remove redundant Bpp

Girish Pathak (16):
  ARM/VExpressPkg: Tidy HDLCD and PL11LCD platform Lib: Coding standard
  ARM/VExpressPkg: Tidy HdLcd/PL111Lcd code: Updated comments
  ARM/VExpressPkg: Remove unused PcdPL111LcdMaxMode from HDLCD inf
  ARM/VExpressPkg: PL111 and HDLCD: add const qualifier
  ARM/VExpressPkg: Add and update debug ASSERTS
  ARM/VExpressPkg: PL111LcdArmVExpressLib: Minor code cleanup
  ARM/VExpressPkg: PL111 and HDLCD: Use FixedPcdGet32
  ARM/VExpressPkg: PL11LcdArmVExpressLib: Improvement conditional
  ARM/VExpressPkg: HdLcdArmVExpressLib: Remove status check EFI_TIMEOUT
  ARM/VExpressPkg: Redefine LcdPlatformGetTimings function
  ARM/VExpressPkg: PL111 and HDLCD: Add PCD to select pixel format
  ARM/VExpressPkg: Reserving framebuffer at build
  ARM/VExpressPkg: New DP500/DP550/DP650 platform library.
  ARM/JunoPkg: Mapping Non-Trused SRAM as device memory
  ARM/JunoPkg: Adding SCMI MTL library
  ARM/JunoPkg: Add HDLCD platform library

 Platform/ARM/JunoPkg/ArmJuno.dec   
|  17 +-
 Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
|   3 +-
 Platform/ARM/JunoPkg/ArmJuno.dsc   
|  32 ++
 Platform/ARM/JunoPkg/ArmJuno.fdf   
|  12 +-
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoLib.inf 
|   5 +-
 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf 
|  39 ++
 Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf   
|  40 ++
 Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf 
|  45 ++
 Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/ArmVExpressLib.inf 
|   7 +-
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf   
|  13 +-
 
Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 |   9 +-
 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h
|  94 
 Platform/ARM/JunoPkg/Library/ArmJunoLib/ArmJunoMem.c   
|  24 +-
 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.c   
| 195 +++
 Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJuno.c
| 559 
 Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c   
| 374 +
 Platform/ARM/VExpressPkg/Library/ArmVExpressLibRTSM/RTSMMem.c  
|  28 +-
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpress.c
| 309 +++
 Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpress.c  
| 425 +--
 19 files changed, 1920 insertions(+), 310 deletions(-)
 create mode 100644 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.inf
 create mode 100644 
Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJunoLib.inf
 create mode 100644 
Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.inf
 create mode 100644 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtlPrivate.h
 create mode 100644 Platform/ARM/JunoPkg/Library/ArmMtl/ArmMtl.c
 create mode 100644 Platform/ARM/JunoPkg/Library/HdLcdArmJunoLib/HdLcdArmJuno.c
 create mode 100644 Platform/ARM/VExpressPkg/Library/ArmMaliDpLib/ArmMaliDpLib.c

-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 01/18] ARM/VExpressPkg: Fix MODULE_TYPE of HDLCD/PL111 platform libraries

[evan . lloyd]

From: Ard Biesheuvel 

This change fixes incorrect MODULE_TYPE of HDLCD and PL111
LcdPlatformLibs. Currently set MODUL_TYPE DXE_DRIVER is incorrect
for these platform libraries. Hence set this to type BASE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak 
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf   
| 4 ++--
 
Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
index 
fc51c781b45122eaf4f2269af61b44c8630cdfb8..18d210ce718db45e018681cd1ccdad48f4adc7f3
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
@@ -2,7 +2,7 @@
 #
 #  Component description file for HdLcdArmLib module
 #
-#  Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+#  Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -18,7 +18,7 @@ [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = HdLcdArmVExpress
   FILE_GUID  = 535a720e-06c0-4bb9-b563-452216abbed4
-  MODULE_TYPE= DXE_DRIVER
+  MODULE_TYPE= BASE
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = LcdPlatformLib
 
diff --git 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
index 
fd83d2412d4fd2dfa59204f21626c62e377e3c55..335c84841a4ff4b57c0d495bc48e93579b5ce576
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/PL111LcdArmVExpressLib/PL111LcdArmVExpressLib.inf
@@ -2,7 +2,7 @@
 #
 #  Component description file for ArmVeGraphicsDxe module
 #
-#  Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+#  Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -18,7 +18,7 @@ [Defines]
   INF_VERSION= 0x00010005
   BASE_NAME  = PL111LcdArmVExpressLib
   FILE_GUID  = b7f06f20-496f-11e0-a8e8-0002a5d5c51b
-  MODULE_TYPE= DXE_DRIVER
+  MODULE_TYPE= BASE
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = LcdPlatformLib
 
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH edk2-platforms v2 04/18] ARM/VExpressPkg: Remove unused PcdPL111LcdMaxMode from HDLCD inf

[evan . lloyd]

From: Girish Pathak 

PCD PcdPL111LcdMaxMode is not used in HDLCD platform library.
Presence of this PCD in HDLCD is probably due to copy/paste code
from PL111 Lcd platform library. This change removes it from
the HdLcdArmVExpressLib.inf file.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Girish Pathak 
---
 Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf | 
1 -
 1 file changed, 1 deletion(-)

diff --git 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
index 
d44aa7776a4ac60d60f3b4386e67c53423287383..52158c4771b5b7651e234fdd73208dcae14c1025
 100644
--- 
a/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
+++ 
b/Platform/ARM/VExpressPkg/Library/HdLcdArmVExpressLib/HdLcdArmVExpressLib.inf
@@ -40,5 +40,4 @@ [Protocols]
   gEfiEdidActiveProtocolGuid# Produced
 
 [Pcd]
-  gArmVExpressTokenSpaceGuid.PcdPL111LcdMaxMode
   gArmVExpressTokenSpaceGuid.PcdHdLcdVideoModeOscId
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 09/13] ArmPlatformPkg: PCD to swap red/blue format for HDLCD

[evan . lloyd]

From: Girish Pathak 

This change adds a new PCD PcdArmHdlcdSwapBlueRedSelect
to swap values for HDLCD RED_SELECT and BLUE_SELECT registers
on platforms where blue and red hardware lines are swapped.

If set to TRUE in the platform dsc, HDLCD library will swap the values
while setting RED_SELECT and BLUE_SELECT registers. The default
value of the PCD is FALSE.

NOTE: The motive for this is that a discrepancy in the Red/Blue lines
exists between some VersatileExpress platforms.  Rather than have
divergent code, this build switch allows a simple, pragmatic solution.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/ArmPlatformPkg.dec  | 3 +++
 ArmPlatformPkg/Library/HdLcd/HdLcd.inf | 2 ++
 ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 4 
 3 files changed, 9 insertions(+)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 
e412414e0ba6506c7158e69bac04469e45601736..9a61e4a511024c80e787500de5038779363f0d95
 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -104,6 +104,9 @@ [PcdsFixedAtBuild.common]
   # Default is set to UEFI console font format 
PixelBlueGreenRedReserved8BitPerColor
   gArmPlatformTokenSpaceGuid.PcdGopPixelFormat|0x0001|UINT32|0x0040
 
+  ## If set, this will swap settings for HDLCD RED_SELECT and BLUE_SELECT 
registers
+  
gArmPlatformTokenSpaceGuid.PcdArmHdLcdSwapBlueRedSelect|FALSE|BOOLEAN|0x0045
+
 [PcdsFixedAtBuild.common,PcdsDynamic.common]
   ## PL031 RealTimeClock
   gArmPlatformTokenSpaceGuid.PcdPL031RtcBase|0x0|UINT32|0x0024
diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.inf 
b/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
index 
67aad05d210b95b2d23b8e52e4392685efcf3795..0f440d1ef730159a8be3780667700979b607a1e2
 100644
--- a/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
+++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.inf
@@ -40,3 +40,5 @@ [LibraryClasses]
 
 [FixedPcd]
   gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase
+  gArmPlatformTokenSpaceGuid.PcdArmHdLcdSwapBlueRedSelect
+
diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c 
b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
index 
72cd5fa33b2553195638c595e72843a56b2e267c..4f802977e8b55ed83364d3ec8fa46082e128c76b
 100644
--- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
+++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
@@ -98,7 +98,11 @@ LcdSetMode (
 return Status;
   }
 
+#if (!FixedPcdGetBool (PcdArmHdLcdSwapBlueRedSelect))
   if (ModeInfo.PixelFormat == PixelBlueGreenRedReserved8BitPerColor) {
+#else
+  if (ModeInfo.PixelFormat == PixelRedGreenBlueReserved8BitPerColor) {
+#endif
 MmioWrite32 (HDLCD_REG_RED_SELECT,  (8 << 8) | 16);
 MmioWrite32 (HDLCD_REG_BLUE_SELECT, (8 << 8) | 0);
   } else {
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 11/13] ArmPlatformPkg: Reserving framebuffer at build

[evan . lloyd]

From: Girish Pathak 

Currently framebuffer memory is either reserved in special VRAM or
dynamically allocated using boot services memory allocation functions.
When allocated using boot services calls the memory has to be allocated
as EfiBootServicesData. Unfortunately failures have been seen with this
case.  There is also an unfortunate lack of control on the placement of
the framebuffer.

This change introduces two PCDs, PcdArmLcdFrameBufferBase and
PcdArmLcdFrameBufferSize which enable build time reservation of the
framebuffer, avoiding the need to allocate dynamically. This allows
the framebuffer to appear as "I/O memory" outside of the normal RAM
map, which is similar to the "VRAM" case.

This change has no impact on current code, only enables the option
of build time reservation of framebuffers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/ArmPlatformPkg.dec | 4 
 1 file changed, 4 insertions(+)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 
9a61e4a511024c80e787500de5038779363f0d95..a887ffcfd9f3b168bfb19ff0a84e310c7891b527
 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -93,6 +93,10 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x0|UINT32|0x0026
   gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x0|UINT32|0x0027
 
+  ## If set, frame buffer memory will be reserved and mapped in the system RAM
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize|0x0|UINT32|0x0043
+  gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase|0x0|UINT64|0x0044
+
   ## PL180 MCI
   
gArmPlatformTokenSpaceGuid.PcdPL180SysMciRegAddress|0x|UINT32|0x0028
   
gArmPlatformTokenSpaceGuid.PcdPL180MciBaseAddress|0x|UINT32|0x0029
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 12/13] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

[evan . lloyd]

From: Girish Pathak 

This change adds support for the ARM Mali DP500/DP500/DP650 display
processors using the GOP protocol. It has been tested on FVP base
models + DP550 support. This change adds platform independant LcdHwLib
library. A corresponding platform specific library will be submitted
to edk-platforms/Platform/ARM/VExpressPkg.

This change does not modify functionality provided by PL111 or
HDLCD. This LcdHwLib implementation should be suitable for those
platforms that implement ARM Mali DP500/DP550/DP650 replacing
PL111/HDLCD.

Only graphics layer of the ARM Mali DP is configured for rendering
the RGB/BGR format frame buffer to satisfy the UEFI GOP requirements
Other layers e.g. video layers are not configured.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/ArmPlatformPkg.dec  |   4 +
 ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.inf |  44 +++
 ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h   | 243 
 ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.c   | 414 
 4 files changed, 705 insertions(+)

diff --git a/ArmPlatformPkg/ArmPlatformPkg.dec 
b/ArmPlatformPkg/ArmPlatformPkg.dec
index 
a887ffcfd9f3b168bfb19ff0a84e310c7891b527..a05cf59fbe6278bc69a674f128a4349477052e3d
 100644
--- a/ArmPlatformPkg/ArmPlatformPkg.dec
+++ b/ArmPlatformPkg/ArmPlatformPkg.dec
@@ -93,6 +93,10 @@ [PcdsFixedAtBuild.common]
   gArmPlatformTokenSpaceGuid.PcdPL111LcdBase|0x0|UINT32|0x0026
   gArmPlatformTokenSpaceGuid.PcdArmHdLcdBase|0x0|UINT32|0x0027
 
+  ## ARM Mali Display Processor DP500/DP550/DP650
+  gArmPlatformTokenSpaceGuid.PcdArmMaliDpBase|0x0|UINT64|0x0050
+  
gArmPlatformTokenSpaceGuid.PcdArmMaliDpMemoryRegionLength|0x0|UINT32|0x0051
+
   ## If set, frame buffer memory will be reserved and mapped in the system RAM
   gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferSize|0x0|UINT32|0x0043
   gArmPlatformTokenSpaceGuid.PcdArmLcdDdrFrameBufferBase|0x0|UINT64|0x0044
diff --git a/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.inf 
b/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.inf
new file mode 100644
index 
..461b194b2719d1b3761bee2bbb0e3a245d72fdc1
--- /dev/null
+++ b/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.inf
@@ -0,0 +1,44 @@
+#/** @file ArmMaliDp.inf
+#
+#  Component description file for ArmMaliDp module
+#
+#  Copyright (c) 2017, ARM Ltd. All rights reserved.
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x00010019
+  BASE_NAME  = ArmMaliDp
+  FILE_GUID  = E724AAF7-19E2-40A3-BAE1-D82A7C8B7A76
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.0
+  LIBRARY_CLASS  = LcdHwLib
+
+[Sources.common]
+  ArmMaliDp.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Platform/ARM/VExpressPkg/ArmVExpressPkg.dec
+
+[LibraryClasses]
+  BaseLib
+  BaseMemoryLib
+  DebugLib
+  IoLib
+  LcdPlatformLib
+  UefiLib
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGuid.PcdArmMaliDpBase
+
diff --git a/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h 
b/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h
new file mode 100644
index 
..ca071093ebb6b0da8ace50ab57d3506b86d53fe9
--- /dev/null
+++ b/ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h
@@ -0,0 +1,243 @@
+/** @file
+
+  This header file contains the platform independent parts of ARM Mali DP
+
+  Copyright (c) 2017, ARM Ltd. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+#ifndef ARMMALIDP_H_
+#define ARMMALIDP_H_
+
+#define DP_BASE(FixedPcdGet64 (PcdArmMaliDpBase))
+
+// MALI DP Ids
+#define MALIDP_NOT_PRESENT 0xFFF
+#define MALIDP_500 0x500
+#define MALIDP_550 0x550
+#define MALIDP_650 0x650
+
+// DP500 Peripheral Ids
+#define DP500_ID_PART_00x00
+#define DP500_ID_DES_0 

[edk2] [PATCH v2 10/13] ArmPlatformPkg: Additional display modes

[evan . lloyd]

From: Girish Pathak 

Add definitions for new display modes such as HD 720.
This has no effect on existing display drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/Include/Library/LcdPlatformLib.h | 60 
 1 file changed, 60 insertions(+)

diff --git a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h 
b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
index 
02be124f00ff5c34c3f8c07ff16ebb4ffc1ba20f..82426f7c903cff09de962e9b7ce10bb2568d340c
 100644
--- a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
+++ b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
@@ -26,6 +26,11 @@
 #define WSXGA 4
 #define UXGA  5
 #define HD6
+#define WVGA  7
+#define QHD   8
+#define WSVGA 9
+#define HD720 10
+#define WXGA  11
 
 // VGA Mode: 640 x 480
 #define VGA_H_RES_PIXELS  640
@@ -118,6 +123,61 @@
 #define HD_V_FRONT_PORCH  (  3 - 1)
 #define HD_V_BACK_PORCH   ( 32 - 1)
 
+// WVGA Mode: 800 x 480
+#define WVGA_H_RES_PIXELS 800
+#define WVGA_V_RES_PIXELS 480
+#define WVGA_OSC_FREQUENCY2950   /* 0x01C22260 */
+#define WVGA_H_SYNC   ( 72 - 1)
+#define WVGA_H_FRONT_PORCH( 24 - 1)
+#define WVGA_H_BACK_PORCH ( 96 - 1)
+#define WVGA_V_SYNC   (  7 - 1)
+#define WVGA_V_FRONT_PORCH(  3 - 1)
+#define WVGA_V_BACK_PORCH ( 10 - 1)
+
+// QHD Mode: 960 x 540
+#define QHD_H_RES_PIXELS  960
+#define QHD_V_RES_PIXELS  540
+#define QHD_OSC_FREQUENCY 4075   /* 0x026DCBB0 */
+#define QHD_H_SYNC( 96 - 1)
+#define QHD_H_FRONT_PORCH ( 32 - 1)
+#define QHD_H_BACK_PORCH  (128 - 1)
+#define QHD_V_SYNC(  5 - 1)
+#define QHD_V_FRONT_PORCH (  3 - 1)
+#define QHD_V_BACK_PORCH  ( 14 - 1)
+
+// WSVGA Mode: 1024 x 600
+#define WSVGA_H_RES_PIXELS1024
+#define WSVGA_V_RES_PIXELS600
+#define WSVGA_OSC_FREQUENCY   4900   /* 0x02EBAE40 */
+#define WSVGA_H_SYNC  (104 - 1)
+#define WSVGA_H_FRONT_PORCH   ( 40 - 1)
+#define WSVGA_H_BACK_PORCH(144 - 1)
+#define WSVGA_V_SYNC  ( 10 - 1)
+#define WSVGA_V_FRONT_PORCH   (  3 - 1)
+#define WSVGA_V_BACK_PORCH( 11 - 1)
+
+// HD720 Mode: 1280 x 720
+#define HD720_H_RES_PIXELS 1280
+#define HD720_V_RES_PIXELS 720
+#define HD720_OSC_FREQUENCY7450   /* 0x0470C7A0 */
+#define HD720_H_SYNC   (128 - 1)
+#define HD720_H_FRONT_PORCH( 64 - 1)
+#define HD720_H_BACK_PORCH (192 - 1)
+#define HD720_V_SYNC   (  5 - 1)
+#define HD720_V_FRONT_PORCH(  3 - 1)
+#define HD720_V_BACK_PORCH ( 20 - 1)
+
+// WXGA Mode: 1280 x 800
+#define WXGA_H_RES_PIXELS  1280
+#define WXGA_V_RES_PIXELS  800
+#define WXGA_OSC_FREQUENCY 8350  /* 0x04FA1BE0 */
+#define WXGA_H_SYNC(128 - 1)
+#define WXGA_H_FRONT_PORCH ( 72 - 1)
+#define WXGA_H_BACK_PORCH  (200 - 1)
+#define WXGA_V_SYNC(  6 - 1)
+#define WXGA_V_FRONT_PORCH (  3 - 1)
+#define WXGA_V_BACK_PORCH  ( 22 - 1)
+
 // Colour Masks
 #define LCD_24BPP_RED_MASK  0x00FF
 #define LCD_24BPP_GREEN_MASK0xFF00
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 04/13] ArmPlatformPkg: HDLCD and PL111: Update debug ASSERTS

[evan . lloyd]

From: Girish Pathak 

This change moves some ASSERTs in error handling code
to improve efficiency in DEBUG build.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 11 ---
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c |  8 
 2 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c 
b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
index 
a1eeabfefe7d32e6182371e5b131ac5df0dd4dd7..d71b6020dc0c4b91e74d16e96b06a60601b9628a
 100644
--- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
+++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
@@ -122,15 +122,15 @@ LcdSetMode (
  ,
  
  );
-  ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
-return EFI_DEVICE_ERROR;
+ASSERT (FALSE);
+return Status;
   }
 
   Status = LcdPlatformGetBpp (ModeNumber, );
-  ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
-return EFI_DEVICE_ERROR;
+ASSERT (FALSE);
+return Status;
   }
 
   BytesPerPixel = GetBytesPerPixel (LcdBpp);
@@ -174,9 +174,6 @@ LcdShutdown (VOID)
 
   @retval EFI_SUCCESSReturns success if platform implements a HDLCD
  controller.
-
-  @retval EFI_NOT_FOUND  HDLCD display controller not found on the
- platform
 **/
 EFI_STATUS
 LcdIdentify (VOID)
diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c 
b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
index 
53b402f711ff10d70feba38671171c027a98b4ba..267c972bf795997f1df88b82acbaea5f75a7a00e
 100644
--- a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
+++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
@@ -105,15 +105,15 @@ LcdSetMode (
  ,
  
  );
-  ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
-return EFI_DEVICE_ERROR;
+ASSERT (FALSE);
+return Status;
   }
 
   Status = LcdPlatformGetBpp (ModeNumber, );
-  ASSERT_EFI_ERROR (Status);
   if (EFI_ERROR (Status)) {
-return EFI_DEVICE_ERROR;
+ASSERT (FALSE);
+return Status;
   }
 
   // Disable the CLCD_LcdEn bit
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 02/13] ArmPlatformPkg: Tidy Lcd code: Updated comments

[evan . lloyd]

From: Girish Pathak 

There is no functional modification in this change
some comments are modified and a few new comments are added.
This is to prevent mixing formatting changes with functional
changes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/Include/Library/LcdPlatformLib.h| 92 
+++-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c | 20 ++---
 ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 29 +-
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 24 -
 4 files changed, 127 insertions(+), 38 deletions(-)

diff --git a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h 
b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
index 
b9316ec8de8425a83e2f627f5c24821ff9a2f750..2a70307031fc21c8fb0d655d358ca9a102a95920
 100644
--- a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
+++ b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
@@ -18,9 +18,7 @@
 
 #define LCD_VRAM_SIZE SIZE_8MB
 
-//
 // Modes definitions
-//
 #define VGA   0
 #define SVGA  1
 #define XGA   2
@@ -29,9 +27,7 @@
 #define UXGA  5
 #define HD6
 
-//
 // VGA Mode: 640 x 480
-//
 #define VGA_H_RES_PIXELS  640
 #define VGA_V_RES_PIXELS  480
 #define VGA_OSC_FREQUENCY 2375  /* 0x016A6570 */
@@ -44,9 +40,7 @@
 #define VGA_V_FRONT_PORCH (  3 - 1)
 #define VGA_V_BACK_PORCH  ( 13 - 1)
 
-//
 // SVGA Mode: 800 x 600
-//
 #define SVGA_H_RES_PIXELS 800
 #define SVGA_V_RES_PIXELS 600
 #define SVGA_OSC_FREQUENCY3825  /* 0x0247A610 */
@@ -59,9 +53,7 @@
 #define SVGA_V_FRONT_PORCH(  3 - 1)
 #define SVGA_V_BACK_PORCH ( 17 - 1)
 
-//
 // XGA Mode: 1024 x 768
-//
 #define XGA_H_RES_PIXELS  1024
 #define XGA_V_RES_PIXELS  768
 #define XGA_OSC_FREQUENCY 6350  /* 0x03C8EEE0 */
@@ -74,9 +66,7 @@
 #define XGA_V_FRONT_PORCH (  3 - 1)
 #define XGA_V_BACK_PORCH  ( 23 - 1)
 
-//
 // SXGA Mode: 1280 x 1024
-//
 #define SXGA_H_RES_PIXELS 1280
 #define SXGA_V_RES_PIXELS 1024
 #define SXGA_OSC_FREQUENCY10900  /* 0x067F3540 */
@@ -89,9 +79,7 @@
 #define SXGA_V_FRONT_PORCH(  3 - 1)
 #define SXGA_V_BACK_PORCH ( 29 - 1)
 
-//
 // WSXGA+ Mode: 1680 x 1050
-//
 #define WSXGA_H_RES_PIXELS1680
 #define WSXGA_V_RES_PIXELS1050
 #define WSXGA_OSC_FREQUENCY   14700  /* 0x08C30AC0 */
@@ -104,9 +92,7 @@
 #define WSXGA_V_FRONT_PORCH   (  4 - 1)
 #define WSXGA_V_BACK_PORCH( 41 - 1)
 
-//
 // UXGA Mode: 1600 x 1200
-//
 #define UXGA_H_RES_PIXELS 1600
 #define UXGA_V_RES_PIXELS 1200
 #define UXGA_OSC_FREQUENCY16100  /* 0x0998AA40 */
@@ -119,9 +105,7 @@
 #define UXGA_V_FRONT_PORCH(  3 - 1)
 #define UXGA_V_BACK_PORCH ( 38 - 1)
 
-//
 // HD Mode: 1920 x 1080
-//
 #define HD_H_RES_PIXELS   1920
 #define HD_V_RES_PIXELS   1080
 #define HD_OSC_FREQUENCY  16500  /* 0x09D5B340 */
@@ -134,10 +118,7 @@
 #define HD_V_FRONT_PORCH  (  3 - 1)
 #define HD_V_BACK_PORCH   ( 32 - 1)
 
-//
 // Colour Masks
-//
-
 #define LCD_24BPP_RED_MASK  0x00FF
 #define LCD_24BPP_GREEN_MASK0xFF00
 #define LCD_24BPP_BLUE_MASK 0x00FF
@@ -158,7 +139,7 @@
 #define LCD_12BPP_444_BLUE_MASK 0x000F
 #define LCD_12BPP_444_RESERVED_MASK 0xF000
 
-/** The enumeration indexes maps the PL111 LcdBpp values used in the LCD 
Control
+/** The enumeration maps the PL111 LcdBpp values used in the LCD Control
   Register
 **/
 typedef enum {
@@ -172,33 +153,94 @@ typedef enum {
   LCD_BITS_PER_PIXEL_12_444
 } LCD_BPP;
 
+/** Platform related initialization function.
+
+  @param[in] Handle  Handle to the LCD device instance.
+
+  @retval EFI_SUCCESSPlaform library initialized successfully.
+  @retval !(EFI_SUCCESS) Other errors.
+**/
 EFI_STATUS
 LcdPlatformInitializeDisplay (
   IN EFI_HANDLE   Handle
   );
 
+/** Allocate VRAM memory in DRAM for the frame buffer
+  (unless it is reserved already).
+
+  The allocated address can be used to set the frame buffer.
+
+  @param[out] VramBaseAddress  A pointer to the frame buffer address.
+  @param[out] VramSize A pointer to the size of the frame
+   buffer in bytes
+
+  @retval

[edk2] [PATCH v2 01/13] ArmPlatformPkg: Tidy Lcd code: Coding standard

[evan . lloyd]

From: Girish Pathak 

There is no functional modification in this change
As preparation for further work, the formatting is corrected to meet
the EDKII coding standard.
Of specific note, some invalid include guards were fixed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h |  10 +-
 ArmPlatformPkg/Include/Library/LcdPlatformLib.h|  14 +-
 ArmPlatformPkg/Library/HdLcd/HdLcd.h   |  21 ++-
 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c | 187 
+++-
 ArmPlatformPkg/Library/HdLcd/HdLcd.c   |  96 
+-
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c |  72 

 6 files changed, 212 insertions(+), 188 deletions(-)

diff --git a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h 
b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
index 
b66efd34561f655b74a5ecfad8a97281cdd5929d..2b001b107927fc75317ce39d370049d7740953a8
 100644
--- a/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
+++ b/ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h
@@ -1,6 +1,6 @@
 /** @file
 
-  Copyright (c) 2011, ARM Ltd. All rights reserved.
+  Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -11,9 +11,8 @@
 
 **/
 
-#ifndef __ARM_VE_GRAPHICS_DXE_H__
-#define __ARM_VE_GRAPHICS_DXE_H__
-
+#ifndef LCD_GRAPHICS_OUTPUT_DXE_H_
+#define LCD_GRAPHICS_OUTPUT_DXE_H_
 
 #include 
 
@@ -25,7 +24,6 @@
 
 #include 
 
-
 //
 // Device structures
 //
@@ -106,4 +104,4 @@ InitializeDisplay (
   IN LCD_INSTANCE* Instance
 );
 
-#endif /* __ARM_VE_GRAPHICS_DXE_H__ */
+#endif /* LCD_GRAPHICS_OUTPUT_DXE_H_ */
diff --git a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h 
b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
index 
b9bdf471e2d65dba7a0fcb0f7ecc352bd576b46b..b9316ec8de8425a83e2f627f5c24821ff9a2f750
 100644
--- a/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
+++ b/ArmPlatformPkg/Include/Library/LcdPlatformLib.h
@@ -1,6 +1,6 @@
 /** @file
 
- Copyright (c) 2011, ARM Ltd. All rights reserved.
+ Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
  This program and the accompanying materials
  are licensed and made available under the terms and conditions of the BSD 
License
  which accompanies this distribution.  The full text of the license may be 
found at
@@ -11,8 +11,8 @@
 
  **/
 
-#ifndef __LCDPLATFORMLIB_H
-#define __LCDPLATFORMLIB_H
+#ifndef LCD_PLATFORM_LIB_H_
+#define LCD_PLATFORM_LIB_H_
 
 #include 
 
@@ -158,8 +158,9 @@
 #define LCD_12BPP_444_BLUE_MASK 0x000F
 #define LCD_12BPP_444_RESERVED_MASK 0xF000
 
-
-// The enumeration indexes maps the PL111 LcdBpp values used in the LCD 
Control Register
+/** The enumeration indexes maps the PL111 LcdBpp values used in the LCD 
Control
+  Register
+**/
 typedef enum {
   LCD_BITS_PER_PIXEL_1 = 0,
   LCD_BITS_PER_PIXEL_2,
@@ -171,7 +172,6 @@ typedef enum {
   LCD_BITS_PER_PIXEL_12_444
 } LCD_BPP;
 
-
 EFI_STATUS
 LcdPlatformInitializeDisplay (
   IN EFI_HANDLE   Handle
@@ -218,4 +218,4 @@ LcdPlatformGetBpp (
   OUT LCD_BPP*  Bpp
   );
 
-#endif
+#endif /* LCD_PLATFORM_LIB_H_ */
diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.h 
b/ArmPlatformPkg/Library/HdLcd/HdLcd.h
index 
6df97a9dfee60e9fda615cf3bea1b6a164a42333..861d3c398f7d6b9a171b4d8718c2816419d8e20a
 100644
--- a/ArmPlatformPkg/Library/HdLcd/HdLcd.h
+++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.h
@@ -1,6 +1,6 @@
-/** @file  HDLcd.h
+/** @file
 
- Copyright (c) 2011-2012, ARM Ltd. All rights reserved.
+ Copyright (c) 2011-2017, ARM Ltd. All rights reserved.
 
  This program and the accompanying materials
  are licensed and made available under the terms and conditions of the BSD 
License
@@ -12,13 +12,10 @@
 
  **/
 
-#ifndef _HDLCD_H_
-#define _HDLCD_H_
+#ifndef HDLCD_H_
+#define HDLCD_H_
 
-//
 // HDLCD Controller Register Offsets
-//
-
 #define HDLCD_REG_VERSION ((UINTN)PcdGet32 (PcdArmHdLcdBase) + 
0x000)
 #define HDLCD_REG_INT_RAWSTAT ((UINTN)PcdGet32 (PcdArmHdLcdBase) + 
0x010)
 #define HDLCD_REG_INT_CLEAR   ((UINTN)PcdGet32 (PcdArmHdLcdBase) + 
0x014)
@@ -44,10 +41,7 @@
 #define HDLCD_REG_GREEN_SELECT((UINTN)PcdGet32 (PcdArmHdLcdBase) + 
0x248)
 #define HDLCD_REG_BLUE_SELECT ((UINTN)PcdGet32 (PcdArmHdLcdBase) + 
0x24C)
 
-
-//
 // HDLCD Values of registers
-//
 
 // HDLCD Interrupt mask, clear and status register
 #define HDLCD_DMA_END BIT0/* DMA has finished reading 
a frame */
@@ 

[edk2] [PATCH v2 05/13] ArmPlatformPkg: PL111Lcd: Replace magic number with macro

[evan . lloyd]

From: Girish Pathak 

Minor code change, replaces magic number with macro in LCD disable.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c 
b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
index 
267c972bf795997f1df88b82acbaea5f75a7a00e..b236cbfcfffadd6fa7610dcae5c5bc748aac0f69
 100644
--- a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
+++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
@@ -117,8 +117,7 @@ LcdSetMode (
   }
 
   // Disable the CLCD_LcdEn bit
-  LcdControl = MmioRead32 (PL111_REG_LCD_CONTROL);
-  MmioWrite32 (PL111_REG_LCD_CONTROL, LcdControl & ~1);
+  MmioAnd32 (PL111_REG_LCD_CONTROL, ~PL111_CTRL_LCD_EN);
 
   // Set Timings
   MmioWrite32 (
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 00/13] ArmPlatformPkg: Update GOP

[evan . lloyd]

From: EvanLloyd 


This patch series addresses comments on the original
(https://lists.01.org/pipermail/edk2-devel/2017-September/015321.html)
reworking of the Graphics Output Protocol code in ArmPlatformPkg.
It also contains updates for the new SCMI protocol.

After a number of format and quality modifications, several errors
are corrected and new functionality added for Mali DP.

The changes are tested on Juno, and FVP. Edk2-platforms changes will
follow shortly.

Code is available for examination at:
  https://github.com/EvanLloyd/tianocore/tree/166_gop_v2



Girish Pathak (13):
  ArmPlatformPkg: Tidy Lcd code: Coding standard
  ArmPlatformPkg: Tidy Lcd code: Updated comments
  ArmPlatformPkg: PL111 and HDLCD: add const qualifier
  ArmPlatformPkg: HDLCD and PL111: Update debug ASSERTS
  ArmPlatformPkg: PL111Lcd: Replace magic number with macro
  ArmPlatformPkg: Implement LcdIdentify function for HDLCD GOP
  ArmPlatformPkg: Redefine LcdPlatformGetTimings function
  ArmPlatformPkg: Add PCD to select pixel format
  ArmPlatformPkg: PCD to swap red/blue format for HDLCD
  ArmPlatformPkg: Additional display modes
  ArmPlatformPkg: Reserving framebuffer at build
  ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.
  ArmPlatformPkg: Introduce SCMI protocol

 ArmPlatformPkg/ArmPlatformPkg.dec |  18 +
 ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf  |  48 ++
 ArmPlatformPkg/Library/{HdLcd/HdLcd.inf => ArmMaliDp/ArmMaliDp.inf}   |  26 +-
 ArmPlatformPkg/Library/HdLcd/HdLcd.inf|   2 +
 ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiBaseProtocolPrivate.h|  29 ++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h   |  69 +++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h |  39 ++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiDxe.h   |  41 ++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiPrivate.h   | 174 

 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.h|  10 +-
 ArmPlatformPkg/Include/Drivers/ArmScmi.h  |  27 ++
 ArmPlatformPkg/Include/Drivers/ArmScmiBaseProtocol.h  | 182 

 ArmPlatformPkg/Include/Drivers/ArmScmiClockProtocol.h | 225 
++
 ArmPlatformPkg/Include/Drivers/ArmScmiPerformanceProtocol.h   | 274 

 ArmPlatformPkg/Include/Library/ArmMtl.h   | 132 
++
 ArmPlatformPkg/Include/Library/LcdPlatformLib.h   | 181 
++--
 ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h  | 243 
+++
 ArmPlatformPkg/Library/HdLcd/HdLcd.h  |  23 +-
 ArmPlatformPkg/Drivers/ArmScmiDxe/Scmi.c  | 261 
+++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c  | 320 
++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c | 419 
++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiDxe.c   | 135 
++
 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c   | 457 

 ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/LcdGraphicsOutputDxe.c| 197 
+
 ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.c  | 414 
++
 ArmPlatformPkg/Library/HdLcd/HdLcd.c  | 185 

 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c| 143 
--
 27 files changed, 3984 insertions(+), 290 deletions(-)
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiDxe.inf
 copy ArmPlatformPkg/Library/{HdLcd/HdLcd.inf => ArmMaliDp/ArmMaliDp.inf} (61%)
 create mode 100644 
ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiBaseProtocolPrivate.h
 create mode 100644 
ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiClockProtocolPrivate.h
 create mode 100644 
ArmPlatformPkg/Drivers/ArmScmiDxe/ArmScmiPerformanceProtocolPrivate.h
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiDxe.h
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiPrivate.h
 create mode 100644 ArmPlatformPkg/Include/Drivers/ArmScmi.h
 create mode 100644 ArmPlatformPkg/Include/Drivers/ArmScmiBaseProtocol.h
 create mode 100644 ArmPlatformPkg/Include/Drivers/ArmScmiClockProtocol.h
 create mode 100644 ArmPlatformPkg/Include/Drivers/ArmScmiPerformanceProtocol.h
 create mode 100644 ArmPlatformPkg/Include/Library/ArmMtl.h
 create mode 100644 ArmPlatformPkg/Library/ArmMaliDp/ArmMaliDp.h
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/Scmi.c
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiBaseProtocol.c
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiClockProtocol.c
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiDxe.c
 create mode 100644 ArmPlatformPkg/Drivers/ArmScmiDxe/ScmiPerformanceProtocol.c
 create mode 100644 

[edk2] [PATCH v2 03/13] ArmPlatformPkg: PL111 and HDLCD: add const qualifier

[evan . lloyd]

From: Girish Pathak 

This change adds CONST qualifiers (mainly to arguments
of  functions) in PL111 and HdLcd libraries.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Girish Pathak <girish.pat...@arm.com>
Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
---
 ArmPlatformPkg/Library/HdLcd/HdLcd.c   | 4 ++--
 ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/ArmPlatformPkg/Library/HdLcd/HdLcd.c 
b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
index 
079fe64ccf30dc21c357298511aeb660faa67e4a..a1eeabfefe7d32e6182371e5b131ac5df0dd4dd7
 100644
--- a/ArmPlatformPkg/Library/HdLcd/HdLcd.c
+++ b/ArmPlatformPkg/Library/HdLcd/HdLcd.c
@@ -56,7 +56,7 @@ GetBytesPerPixel (
 **/
 EFI_STATUS
 LcdInitialize (
-  IN EFI_PHYSICAL_ADDRESS   VramBaseAddress
+  IN CONST EFI_PHYSICAL_ADDRESS   VramBaseAddress
   )
 {
   // Disable the controller
@@ -95,7 +95,7 @@ LcdInitialize (
 **/
 EFI_STATUS
 LcdSetMode (
-  IN UINT32  ModeNumber
+  IN CONST UINT32  ModeNumber
   )
 {
   EFI_STATUSStatus;
diff --git a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c 
b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
index 
b1b7d0dd19076e3afba0d144af8d95b9f350006c..53b402f711ff10d70feba38671171c027a98b4ba
 100644
--- a/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
+++ b/ArmPlatformPkg/Library/PL111Lcd/PL111Lcd.c
@@ -55,7 +55,7 @@ LcdIdentify (VOID)
 **/
 EFI_STATUS
 LcdInitialize (
-  IN EFI_PHYSICAL_ADDRESS   VramBaseAddress
+  IN CONST EFI_PHYSICAL_ADDRESS   VramBaseAddress
   )
 {
   // Define start of the VRAM. This never changes for any graphics mode
@@ -78,7 +78,7 @@ LcdInitialize (
 **/
 EFI_STATUS
 LcdSetMode (
-  IN UINT32  ModeNumber
+  IN CONST UINT32  ModeNumber
   )
 {
   EFI_STATUSStatus;
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables

[Evan Lloyd]

I've just submitted this patch from Sami.
It is a new version of his "AcpiView" updated in response to comments, and to 
match ACPI 6.2.
It also now matches ECR 1784 (for command line options).
The code can be seen at 
https://github.com/EvanLloyd/tianocore/tree/188_acpiview_v2
>From https://bugzilla.tianocore.org/show_bug.cgi?id=805, it can be added to 
>edk2 (not staging).

Regards,
Evan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> evan.ll...@arm.com
> Sent: 15 December 2017 19:29
> To: edk2-devel@lists.01.org
> Cc: "ruiyu...@intel.com"@arm.com; "matteo.carl...@arm.com"@arm.com;
> "n...@arm.com"@arm.com; "ard.biesheu...@linaro.org"@arm.com;
> "sami.muja...@arm.com"@arm.com; "jiewen@intel.com "@arm.com;
> "leif.lindh...@linaro.org"@arm.com
> Subject: [edk2] [PATCH] ShellPkg: Add acpiview tool to dump ACPI tables
>
> From: Sami Mujawar <sami.muja...@arm.com>
>
> This program is provided to allow examination of ACPI table contents
> from the UEFI Shell.  This can help with investigations, especially at
> that stage where the tables are not enabling an OS to boot.
> The program is not exhaustive, and only encapsulates detailed knowledge
> of a limited number of table types.
>
> Default behaviour is to display the content of all tables installed.
> 'Known' table types will be parsed and displayed with descriptions and
> field values.  Where appropriate a degree of consistency checking is
> done and errors may be reported in the output.
> Other table types will be displayed as an array of Hexadecimal bytes.
>
> To facilitate debugging, the -t and -b options can be used to generate a
> binary file image of a table that can be copied elsewhere for
> investigation using tools such as those provided by acpica.org.  This is
> especially relevant for AML type tables like DSDT and SSDT.
>
> The inspiration for this is the existing smbiosview Debug1 Shell
> command.
>
> Many tables are not explicitly handled, in part because no examples are
> available for our testing.
>
> The program is designed to be extended to new tables with minimal
> effort, and contributions are invited.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
> Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> ---
...
> --
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [staging/DynamicTables] What about edk2-platforms.

[Evan Lloyd]

We are about to submit a new (ACPI 6.2) version of Sami's Dynamic Tables module.
As suggested in previous threads, the aim is to submit it to edk2-staging.
To that end, following the instructions at 
https://github.com/tianocore/edk2-staging/blob/about/README
(paragraph 4 a) "Maintainer sends patch email to edk2-devel", we need to 
generate a patch.

The problem is that the patch involves modules in both edk2 and edk2-platforms.
What is the best strategy to use for that scenario?
Is there any plan to have an edk2-platforms-staging?
If not, we could roll the bits of platforms into edk2-staging, but that may 
engender problems later.
Does anyone have any advice on how best to handle this, please?

Regards,
Evan
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

[Evan Lloyd]

Hi Ard.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 05 December 2017 21:28
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; Matteo Carlini <matteo.carl...@arm.com>;
> Leif Lindholm <leif.lindh...@linaro.org>; Girish Pathak
> <girish.pat...@arm.com>
> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP driver.
>
> On 5 December 2017 at 20:03, Evan Lloyd <evan.ll...@arm.com> wrote:
> >
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 01 December 2017 17:19
> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> Cc: edk2-devel@lists.01.org; Matteo Carlini <matteo.carl...@arm.com>;
> >> Leif Lindholm <leif.lindh...@linaro.org>; Girish Pathak
> >> <girish.pat...@arm.com>
> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP
> >> driver.
> >>
...
> >> >
> >> >> whatsoever. If you introduce any library classes that abstract
> >> >> away the differences between platforms, you can include a Null
> >> >> version of such a library that simply does ASSERT (FALSE) in every
> function:
> >> >> this
> >> >
> >> >  [[Evan Lloyd]] One could, indeed, do that.  We, however, would be
> >> > very
> >> reluctant to incur the overhead of rework in response to spurious
> >> cavils from a maintainer when it is of no direct relevance to us.
> >> >
> >>
> >> I don't think the suggestion that we evil maintainers are nothing but
> >> an impediment to the likes of you and your team members doing the
> >> actual work is justified.
> >>
> >> We are all on the same team here, and the goal is to make UEFI code
> >> reusable for the customers of /your/ employer. Throwing stuff over
> >> the fence != upstreaming, and it is my job as a maintainer to ensure
> >> that code is still maintainable long after the original authors have
> >> moved on to something else.
> >>
> >> ArmPlatformPkg is a perfect example where code reuse is much more
> >> difficult than it needs to be, and we as maintainers need to deal
> >> with contributors from other companies that have used it as
> >> 'guidance' for how to architect their UEFI firmware, which is usually
> >> filled with vexpress-isms that date back to before anyone currently
> involved with UEFI can remember.
> >>
> >> This is why I have taken the time to sit down, go through all the
> >> crap code, clean it up, refactor it and propose it on the list as
> >> improvements. I even went so far as taking the preparatory Mali work
> >> of your team and rebase it so that we can keep the bits that we may
> >> share, and move the bits out that should not be kept in main EDK2
> >> because they are being taken as gospel by engineers that are new to
> >> ARM+UEFI.
> >>
> >> If this is too much to deal with for you, then fine, don't upstream your
> code.
> >> But if you do, you are going to have to play nice with the others,
> >> including the maintainers.
> >>
> > [[Evan Lloyd]] Hi Ard.  Firstly, I apologize, I assumed from your name that
> you were Dutch and would therefore probably have a lively sense of
> humour.  Of course, if I have touched a nerve, that is unfortunate and I'm
> sorry.
>
> No, the apparently blatantly obvious tongue-in-cheek nature of your
> response was completely lost on me. But I know a person who does have a
> lively sense of humour, so next time I will ask him for help.

 [[Evan Lloyd]] I would like to extend my apology.  From comments others have 
made it is apparent that my wording was too easily interpreted as just 
offensive.  I shall try and resist the temptation to make such points with 
dubious attempts at humour in the future, at least on fora like this where they 
are out of place.  Het spijt me.

>
> > I agree that cleaning up the code is important, worthwhile, and an
> objective for us all.  What can be a difficulty is our very different
> conceptions of what clean means.
> >
>
> Fair enough. But as maintainers, we take ownership of your code, with the
> implied promise to keep it in a working state. I don't think it is
> unreasonable that we get to dictate some of the terms under which that
> occurs.
>
> > You should be aware though that a certain amount of whingeing is to be
> > expected when dealing with Brits. (Ask Leif - he knows! Or any Australia

Re: [edk2] [PATCH 02/19] ArmPlatformPkg: Tidy LcdGraphicsOutputDxe code: Added comments

[Evan Lloyd]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 05 December 2017 19:59
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 02/19] ArmPlatformPkg: Tidy
> LcdGraphicsOutputDxe code: Added comments
>
> On Tue, Dec 05, 2017 at 06:55:25PM +, Evan Lloyd wrote:
> >
> >
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: 12 October 2017 20:02
> > > To: Evan Lloyd <evan.ll...@arm.com>
> > > Cc: edk2-devel@lists.01.org
> > > Subject: Re: [edk2] [PATCH 02/19] ArmPlatformPkg: Tidy
> > > LcdGraphicsOutputDxe code: Added comments
> > >
> > > Given that all changes to the first file _remove_ comments, it may
> > > be better with a subject line saying "updating comments".
> > >
> > > On Tue, Sep 26, 2017 at 09:15:12PM +0100, evan.ll...@arm.com
> wrote:
> > > > From: Girish Pathak <girish.pat...@arm.com>
> > > >
> > > > There is no functional modification in this change As preparation
> > > > for a Change (Rejig of LcdGraphicsOutPutDxe), some comments are
> > > > modified and a few new comments are added.
> > > > This is to prevent mixing formatting changes with functional changes.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> > > > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > > > ---
> > ...
> > > >
> > > > -
> > > > +/** Platform related initialization function.
> > > > +  *
> > > > +  * @param IN Handle   Handle to the LCD device instance.
> > > > +  *
> > > > +  * @retval EFI_SUCCESSPlatform initialization success.
> > > > +  * @retval !(EFI_SUCCESS) Other errors.
> > > > +**/
> > >
> > > So ... 6.8 lists
> > > /**
> > >   text
> > > **/
> > > as the
> > >
> > > The format
> > > /**
> > >  * text
> > > **/
> > > is mentioned as "also legal because doxygen ignores the leading *".
> > >
> > > The format
> > > /**
> > >   *
> > > **/
> > > is never mentioned, although I guess "also legal" because * ignored.
> > >
> > > However, a quick skim in MdePkg suggests the former is the generally
> > > used variant. Can you please update to that format throughout (drop
> > > the leading '*' on lines not starting or ending the comment block)?
> >
> >  [[Evan Lloyd]] I'm not sure if Outlook has mangled something, or I'm
> > being obtuse, but I'm not sure I follow the distinction you are making
> there.
> > However, if your objection is to the leading '*' then we can remove
> > it.
>
> The objection is slightly with regards to the leading *, but moreso over it
> aligning with the second * of the opening /** rather than the first.

[[Evan Lloyd]] Just to be a barrack room lawyer - the CCS clearly states:
" 3.2.1 Formatting: General Rules
...
 All indentation (tabs) is two spaces. See "General Rules”."
" 5.1.2 ... All indentation is on two space boundaries. There are no exceptions 
to this rule!"

Of course you may quibble over this being an indentation, but the leading '*'s 
are certainly indented relative to the "/**" in either case.

>
> It is entirely possible that some form of email mangling is the cause
> (including perhaps you reading my reply in non-fixed width font).
[[Evan Lloyd]] Almost certainly true.
>
> > By the way - shouldn't it be:
> > /**  Brief description
> >
> >   Details
> > **/  (see Horor vacuii)
>
> That would be my preferred version. (I started typing that above, but seem
> to have lost my way after "as the".)
>
> It's just that
> /**
>  *
>  **/
> is common enough in the codebase that I wouldn't object to it.
>
> Whereas I haven't seen
> /**
>   *
>  **/
> anywhere else

 [[Evan Lloyd]] I refer my learned friend to  "CCS 5.1.2 ... All indentation is 
on two space boundaries. There are no exceptions to this rule!"
Also:
"1.1 Abstract
... All changes or additions from this point on shall conform to this 
specification. Pre-existing code does not need to be updated for the sole 
purpose of conforming to this specification. As conforming updates are made, 
the developer may update other con

Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 01 December 2017 17:35
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org@arm.com
> <"ard.biesheu...@linaro.org"@arm.com>;
> leif.lindh...@linaro.org@arm.com <"leif.lindh...@linaro.org"@arm.com>;
> matteo.carl...@arm.com@arm.com
> <"matteo.carl...@arm.com"@arm.com>; n...@arm.com@arm.com
> <"n...@arm.com"@arm.com>
> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
> debug asserts
>
> On 1 December 2017 at 16:33, Evan Lloyd <evan.ll...@arm.com> wrote:
> > Responses inline:
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 13 October 2017 08:33
> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> >> "leif.lindh...@linaro.org"@arm.com;
> >> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> >> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe:
> Add
> >> debug asserts
> >>
> >> On 26 September 2017 at 21:15,  <evan.ll...@arm.com> wrote:
> >> > From: Girish Pathak <girish.pat...@arm.com>
> >> >
> >> > This change adds some debug assertions e.g to catch NULL pointer
> >> > errors missing in PL11Lcd and HdLcd modules.
> >> >
> >> > This change also improves related error handling code.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> >> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> >> > ---
> >> >
> >>
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
> >> mVExpress.c   | 44 ++--
> >> >
> >>
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
> >> 1LcdArmVExpress.c | 43 ++-
> >> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
> >> |  8 ++--
> >> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
> >> |  8 ++--
> >> >  4 files changed, 90 insertions(+), 13 deletions(-)
> >> >
> >> > diff --git
> >> >
> >>
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c
> >> >
> >>
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c index
> >> >
> >>
> b9859a56988f7e5be0adbaa49048a683fe586bfe..58dd9f0c77e1bc9af559a
> >> 71d0c7c
> >> > ce72d71c6da5 100644
> >> > ---
> >> >
> >>
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c
> >> > +++
> >>
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> A
> >> > +++ rmVExpress.c
> >> > @@ -140,6 +140,7 @@ LcdPlatformInitializeDisplay (
> >> >* buffer in bytes
> >> >*
> >> >* @retval EFI_SUCCESS Frame buffer memory allocation
> success.
> >> > +  * @retval EFI_INVALID_PARAMETER   VramBaseAddress or
> VramSize
> >> are NULL.
> >> >* @retval !(EFI_SUCCESS)  Other errors.
> >> >  **/
> >> >  EFI_STATUS
> >> > @@ -151,6 +152,13 @@ LcdPlatformGetVram (
> >> >EFI_STATUS  Status;
> >> >    EFI_ALLOCATE_TYPE   AllocationType;
> >> >
> >> > +  // Check VramBaseAddress and VramSize are not NULL.
> >> > +  if (VramBaseAddress == NULL || VramSize == NULL) {
> >> > +ASSERT (VramBaseAddress != NULL);
> >> > +ASSERT (VramSize != NULL);
> >> > +return EFI_INVALID_PARAMETER;
> >> > +  }
> >> > +
> >> >// Set the vram size
> >> >*VramSize = LCD_VRAM_SIZE;
> >> >
> >> > @@ -169,6 +177,7 @@ LcdPlatformGetVram (
> >> >        VramBaseAddress
> >> >);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT_EFI_ERROR (Status);
> >> >  return Status;
> >> >}
> >> >
> >> >

Re: [edk2] [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add const qualifier

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 01 December 2017 17:32
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org@arm.com
> <"ard.biesheu...@linaro.org"@arm.com>;
> leif.lindh...@linaro.org@arm.com <"leif.lindh...@linaro.org"@arm.com>;
> matteo.carl...@arm.com@arm.com
> <"matteo.carl...@arm.com"@arm.com>; n...@arm.com@arm.com
> <"n...@arm.com"@arm.com>
> Subject: Re: [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add const
> qualifier
>
> On 1 December 2017 at 16:17, Evan Lloyd <evan.ll...@arm.com> wrote:
> > Hi Ard.
> > Response inline below
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 12 October 2017 20:47
> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> >> "leif.lindh...@linaro.org"@arm.com;
> >> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> >> Subject: Re: [PATCH 03/19] ArmPlatformPkg: PL111 and HDLCD: add
> const
> >> qualifier
> >>
> >> On 26 September 2017 at 21:15,  <evan.ll...@arm.com> wrote:
> >> > From: Girish Pathak <girish.pat...@arm.com>
> >> >
> >> > This change adds some STATIC and CONST qualifiers (mainly to
> >> > arguments of  functions) in PL111 and HdLcd modules.
> >> >
> >> > It doesn't add or modify any functionality.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> >> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> >> > ---
> >> >
> >>
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
> >> mVExpress.c   | 34 ++--
> >> >
> >>
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
> >> 1LcdArmVExpress.c | 34 ++--
> >> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
> >> |  4 +--
> >> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
> >> |  4 +--
> >> >  4 files changed, 38 insertions(+), 38 deletions(-)
> >> >
> >> > diff --git
> >> >
> >>
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c
> >> >
> >>
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c index
> >> >
> >>
> cfe3259d3c737de240350e8c3eab867b80c40948..b9859a56988f7e5be0ad
> >> baa49048
> >> > a683fe586bfe 100644
> >> > ---
> >> >
> >>
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> ArmVE
> >> > xpress.c
> >> > +++
> >>
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> >> A
> >> > +++ rmVExpress.c
> >> > @@ -46,7 +46,7 @@ typedef struct {
> >> >
> >> >  /** The display modes supported by the platform.
> >> >  **/
> >> > -LCD_RESOLUTION mResolutions[] = {
> >> > +STATIC CONST LCD_RESOLUTION mResolutions[] = {
> >> >{ // Mode 0 : VGA : 640 x 480 x 24 bpp
> >> >  VGA, VGA_H_RES_PIXELS, VGA_V_RES_PIXELS,
> >> LCD_BITS_PER_PIXEL_24,
> >> >  VGA_OSC_FREQUENCY,
> >> > @@ -144,8 +144,8 @@ LcdPlatformInitializeDisplay (  **/  EFI_STATUS
> >> > LcdPlatformGetVram (
> >> > -  OUT EFI_PHYSICAL_ADDRESS*  VramBaseAddress,
> >> > -  OUT UINTN* VramSize
> >> > +  OUT EFI_PHYSICAL_ADDRESS * CONST  VramBaseAddress,
> >> > +  OUT UINTN * CONST VramSize
> >>
> >> What is the point of this CONST (and all the other occurrences in
> >> this patch)
> >>
> >> In all cases [AFAICT] the CONST applies to the argument itself, not
> >> to the object it points to, which means the variable is CONST in the
> >> scope of the function, but can still be dereferenced to assign the OUT
> value.
> >>
> >> This means your change is technically correct, but it is extremely
> >> unidiomatic for EDK2, so an explanation why this driver needs this
> >> would be highly appreciated.
> >>

Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

[Evan Lloyd]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 01 December 2017 17:19
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; Matteo Carlini <matteo.carl...@arm.com>;
> Leif Lindholm <leif.lindh...@linaro.org>; Girish Pathak
> <girish.pat...@arm.com>
> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP driver.
>
> On 1 December 2017 at 13:12, Evan Lloyd <evan.ll...@arm.com> wrote:
> >
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 28 November 2017 18:18
> >> To: Evan Lloyd <evan.ll...@arm.com>
> >> Cc: edk2-devel@lists.01.org; Matteo Carlini <matteo.carl...@arm.com>;
> >> Leif Lindholm <leif.lindh...@linaro.org>; Girish Pathak
> >> <girish.pat...@arm.com>
> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP
> >> driver.
> >>
> >> On 26 September 2017 at 21:15,  <evan.ll...@arm.com> wrote:
> >> > From: Girish Pathak <girish.pat...@arm.com>
> >> >
> >> > This change adds support for the ARM Mali DP500/DP500/DP650
> display
> >> > processors using the GOP protocol. It has been tested on FVP base
> >> > models + DP550 support.
> >> >
> >> > This change does not modify functionality provided by PL111 or
> >> > HDLCD. The driver should be suitable for those platforms that
> >> > implement ARM Mali DP500/DP550/DP650 replacing PL111/HDLCD.
> >> >
> >> > Only "Layer Graphics" of the ARM Mali DP is configured for
> >> > rendering the RGB/BGR format frame buffer to satisfy the UEFI GOP
> >> > requirements Other layers e.g. video layers are not configured.
> >> >
> >> > NOTE: This change implements the Mali DP on models. Versions for
> >> > actual hardware are liable to require extra handling for clock
> >> > input changes, etc.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> >> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> >>
> >> Hello Girish, Evan,
> >>
> >> (replying to 19/19 because I cannot find the cover letter in my
> >> edk2-devel archive but this really applies to the whole series)
> >>
> >> I have been looking at these patches again now that I am trying to
> >> clean up ArmPlatformPkg, which is currently a dumping ground for all
> >> things vaguely ARM related, and is also structured quite differently
> >> from other packages.
> >>
> >> Ideally, ArmPlatformPkg should only contain the following:
> >> - library class interfaces under Include/Library; header files kept
> >> here should only contain elements that define API
> >> - driver specific include files Include/IndustryStandard but *only*
> >> if they cannot be kept locally with the driver in question
> >> - libraries under Library/
> >> - drivers under Drivers/
> >>
> >> This aligns with the common arrangement adopted by most EDK2
> packages.
> >>
> >> This series does many different things, and does not distinguish at
> >> all between common code and code living under ArmVExpressPkg. Given
> >
> >  [[Evan Lloyd]] All of the commits in the series are in ArmPlatformPkg.
> > You may be in the process of disentangling the VE specific bits, but
> > hitherto that has not been a consideration.  (Note: I'm not arguing against
> the disentangling, only pointing out that it was not a factor at the point we
> submitted the patches) The reason there are so many commits is only that
> we have been asked to break things up into "bite sized" chunks for the
> convenience of maintainers.
> > The aim was to make each a coherent item with a simple justification.
> >
> >> that I am trying to move ArmVExpressPkg out of EDK2 into
> >> edk2-platforms (where it arguably belongs) having this series in
> >> limbo for two months is basically blocking my work, and so I would
> >> like to explore ways to proceed with this without interfering with
> >> each other's work too much. At the same time, the way the code is
> >> structured is a continuation of the pattern I am trying to get rid
> >> of, so they will need some rework anyway in order to be upstreamable
> IMHO.
> >
> >  [[Evan Lloyd]] Not being psy

Re: [edk2] [PATCH 02/19] ArmPlatformPkg: Tidy LcdGraphicsOutputDxe code: Added comments

[Evan Lloyd]

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 12 October 2017 20:02
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH 02/19] ArmPlatformPkg: Tidy
> LcdGraphicsOutputDxe code: Added comments
>
> Given that all changes to the first file _remove_ comments, it may be better
> with a subject line saying "updating comments".
>
> On Tue, Sep 26, 2017 at 09:15:12PM +0100, evan.ll...@arm.com wrote:
> > From: Girish Pathak <girish.pat...@arm.com>
> >
> > There is no functional modification in this change As preparation for
> > a Change (Rejig of LcdGraphicsOutPutDxe), some comments are modified
> > and a few new comments are added.
> > This is to prevent mixing formatting changes with functional changes.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
...
> >
> > -
> > +/** Platform related initialization function.
> > +  *
> > +  * @param IN Handle   Handle to the LCD device instance.
> > +  *
> > +  * @retval EFI_SUCCESSPlatform initialization success.
> > +  * @retval !(EFI_SUCCESS) Other errors.
> > +**/
>
> So ... 6.8 lists
> /**
>   text
> **/
> as the
>
> The format
> /**
>  * text
> **/
> is mentioned as "also legal because doxygen ignores the leading *".
>
> The format
> /**
>   *
> **/
> is never mentioned, although I guess "also legal" because * ignored.
>
> However, a quick skim in MdePkg suggests the former is the generally used
> variant. Can you please update to that format throughout (drop the leading
> '*' on lines not starting or ending the comment block)?

 [[Evan Lloyd]] I'm not sure if Outlook has mangled something, or I'm being 
obtuse,
but I'm not sure I follow the distinction you are making there.
However, if your objection is to the leading '*' then we can remove it.
By the way - shouldn't it be:
/**  Brief description

  Details
**/  (see Horor vacuii)

I actually think the CCS is woefully inconsistent in its example comment style, 
and that although leading '*'s are acceptable to Doxygen, it would be better to 
stick to one style (that of the file header comment, without leading '*'s) 
throughout.

>
> No other comments (other than having these prototype documentations
> are a great improvement).
>
> /
> Leif
>
> >  EFI_STATUS
> >  LcdPlatformInitializeDisplay (
> >IN EFI_HANDLE   Handle
> >);
> >
> > +/** Reserve VRAM memory in DRAM for the frame buffer
> > +  * (unless it is reserved already).
> > +  *
> > +  * The allocated address can be used to set the frame buffer.
> > +  * @param OUT VramBaseAddress  A pointer to the frame buffer
> address.
> > +  * @param OUT VramSize A pointer to the size of the frame
> > +  * buffer in bytes
> > +  *
> > +  * @retval EFI_SUCCESS Frame buffer memory allocation success.
> > +  * @retval !(EFI_SUCCESS)  Other errors.
> > +**/
> >  EFI_STATUS
> >  LcdPlatformGetVram (
> >OUT EFI_PHYSICAL_ADDRESS* VramBaseAddress,
> >OUT UINTN*VramSize
> >);
> >
> > +/** Return total number of modes.
> > +  *
> > +  * @retval UINT32 Mode Number.
> > +**/
> >  UINT32
> >  LcdPlatformGetMaxMode (
> >VOID
> >);
> >
> > +/** Set the requested display mode.
> > +  *
> > +  * @param IN ModeNumber Mode Number.
> > +  * @retval   EFI_SUCCESSSet mode success.
> > +  * @retval   EFI_INVALID_PARAMTER   Requested mode not found.
> > +**/
> >  EFI_STATUS
> >  LcdPlatformSetMode (
> >IN UINT32 ModeNumber
> >);
> >
> > +/** Return information for the requested mode number.
> > +  *
> > +  * @param IN ModeNumberMode Number.
> > +  * @param OUT Info Pointer for returned mode information
> > +  * (on success).
> > +  *
> > +  * @retval EFI_SUCCESS Success if the requested mode is found.
> > +  * @retval EFI_INVALID_PARAMETER   Requested mode not found.
> > +**/
> >  EFI_STATUS
> >  LcdPlatformQueryMode (
> >IN  UINT32ModeNumber,
> >OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  

Re: [edk2] [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at build

[Evan Lloyd]

Responses inline

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 25 October 2017 19:10
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH 18/19] ArmPlatformPkg: Reserving framebuffer at
> build
>
> On 26 September 2017 at 21:15,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak <girish.pat...@arm.com>
> >
> > Currently frame buffer memory is either reserved in special VRAM or
> > dynamically allocated using boot services memory allocation functions.
> > When allocated using boot services calls the memory has to be
> > allocated as EfiBootServicesData. Unfortunately failures have been
> > seen with this case.  There is also an unfortunate lack of control on
> > the placement of the frmae buffer.
> >
> > This change introduces two PCDs, PcdArmLcdFrameBufferBase and
> > PcdArmLcdFrameBufferSize which enable build time reservation of the
> > frame buffer, avoiding the need to allocate dynamically.  This allows
> > the frame buffer to appear as "I/O memory" outside of the normal RAM
> > map, which is similar to the "VRAM" case.
> >
> > This change has no impact on current code, only enables the option of
> > build time reservation of frame buffers.
> >
>
> Where is the memory actually being reserved? And if it is reserved, how can
> the OS reclaim it if it is not interested in using the GOP?

[[Evan Lloyd]] The memory is reserved by whatever sets the Pcd - normally the 
.dsc.  It may or may not be system RAM.
If it is excised from system memory, then there is no way for the OS to reclaim 
it, as it can't differentiate that from the VRAM case.
I'm not sure I see the relevance of that anyway.  Is our objective to provide 
restricted firmware tightly tuned for a specific operating system in an 
unrealistic mode, or to provide a generic example of firmware exercising the 
standard interfaces and testing real use cases?

Regards,
Evan

>
>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
> >  ArmPlatformPkg/ArmPlatformPkg.dec  
> >  |  4 
> >
...
> > --
> > Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> >
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

[Evan Lloyd]

Responses inline:

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 13 October 2017 08:33
> To: Evan Lloyd <evan.ll...@arm.com>
> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> "leif.lindh...@linaro.org"@arm.com;
> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
> debug asserts
>
> On 26 September 2017 at 21:15,  <evan.ll...@arm.com> wrote:
> > From: Girish Pathak <girish.pat...@arm.com>
> >
> > This change adds some debug assertions e.g to catch NULL pointer
> > errors missing in PL11Lcd and HdLcd modules.
> >
> > This change also improves related error handling code.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Girish Pathak <girish.pat...@arm.com>
> > Signed-off-by: Evan Lloyd <evan.ll...@arm.com>
> > ---
> >
> ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcdAr
> mVExpress.c   | 44 ++--
> >
> ArmPlatformPkg/ArmVExpressPkg/Library/PL111LcdArmVExpressLib/PL11
> 1LcdArmVExpress.c | 43 ++-
> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/HdLcd.c
> |  8 ++--
> >  ArmPlatformPkg/Drivers/LcdGraphicsOutputDxe/PL111Lcd.c
> |  8 ++--
> >  4 files changed, 90 insertions(+), 13 deletions(-)
> >
> > diff --git
> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c
> >
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c index
> >
> b9859a56988f7e5be0adbaa49048a683fe586bfe..58dd9f0c77e1bc9af559a
> 71d0c7c
> > ce72d71c6da5 100644
> > ---
> >
> a/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> ArmVE
> > xpress.c
> > +++
> b/ArmPlatformPkg/ArmVExpressPkg/Library/HdLcdArmVExpressLib/HdLcd
> A
> > +++ rmVExpress.c
> > @@ -140,6 +140,7 @@ LcdPlatformInitializeDisplay (
> >* buffer in bytes
> >*
> >* @retval EFI_SUCCESS Frame buffer memory allocation success.
> > +  * @retval EFI_INVALID_PARAMETER   VramBaseAddress or VramSize
> are NULL.
> >* @retval !(EFI_SUCCESS)  Other errors.
> >  **/
> >  EFI_STATUS
> > @@ -151,6 +152,13 @@ LcdPlatformGetVram (
> >EFI_STATUS  Status;
> >EFI_ALLOCATE_TYPE   AllocationType;
> >
> > +  // Check VramBaseAddress and VramSize are not NULL.
> > +  if (VramBaseAddress == NULL || VramSize == NULL) {
> > +ASSERT (VramBaseAddress != NULL);
> > +ASSERT (VramSize != NULL);
> > +return EFI_INVALID_PARAMETER;
> > +  }
> > +
> >// Set the vram size
> >*VramSize = LCD_VRAM_SIZE;
> >
> > @@ -169,6 +177,7 @@ LcdPlatformGetVram (
> >VramBaseAddress
> >);
> >if (EFI_ERROR (Status)) {
> > +ASSERT_EFI_ERROR (Status);
> >  return Status;
> >}
> >
> > @@ -179,8 +188,8 @@ LcdPlatformGetVram (
> >*VramSize,
> >EFI_MEMORY_WC
> >);
> > -  ASSERT_EFI_ERROR (Status);
> >if (EFI_ERROR (Status)) {
> > +ASSERT_EFI_ERROR (Status);
>
> What is the point of this change?
[[Evan Lloyd]] It is a minor efficiency improvement.  Since the ASSERT can only 
fire when the if condition is true, it removes a duplicated test from the main 
(non-error) code flow.  This is irrelevant on hardware, but actually 
significant when running debug builds on an emulator environment.

>
> >  gBS->FreePages (*VramBaseAddress, EFI_SIZE_TO_PAGES (*VramSize));
> >  return Status;
> >}
> > @@ -215,6 +224,7 @@ LcdPlatformSetMode (
> >EFI_STATUSStatus;
> >
> >if (ModeNumber >= LcdPlatformGetMaxMode ()) {
> > +ASSERT (ModeNumber < LcdPlatformGetMaxMode ());
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> > @@ -264,6 +274,7 @@ LcdPlatformSetMode (
> >*
> >* @retval EFI_SUCCESS Success if the requested mode is found.
> >* @retval EFI_INVALID_PARAMETER   Requested mode not found.
> > +  * @retval EFI_INVALID_PARAMETER   Info is NULL.
> >  **/
> >  EFI_STATUS
> >  LcdPlatformQueryMode (
> > @@ -271,7 +282,9 @@ LcdPlatformQueryMode (
> >OUT EFI_GRAPHICS_OUTPUT_MODE_INFORMATION * CONST  Info
> >)
> >  {
> > -  if (ModeN