Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP
On 2/28/22 07:37, Liu Ying wrote: Hi Marek, Hi, On Mon, 2022-02-28 at 01:45 +0100, Marek Vasut wrote: Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it In i.MX23 reference manual, there is no LCDIFv3 found, but only LCDIF. See i.MX23 HW_LCDIF_VERSION MAJOR=0x3 , that's LCDIF V3 . MX28 has LCDIF V4 . has a completely scrambled register layout compared to all previous LCDIF It looks like no single register of i.MX8MP LCDIFv3 overlaps with registers in other i.MX2x/6x/7x/8x LCDIFs. The LCDIFv3 block diagram is totally different from the LCDIF block diagram, according to the SoC reference manuals. LCDIFv3 supports SHADOW_EN bit to update horizontal and vertical size of graphic, position of graphic on the panel, address of graphic in memory and color formats or color palettes, which is not supported by LCDIF and impacts display driver control mechanism considerably. LCDIF supports DOTCLK interface, MPU interface and VSYNC interface, while LCDIFv3 only supports parallel output as a counterpart of the DOTCLK interface. Generally speaking, LCDIFv3 is just a new display IP which happens to have the word 'LCDIF' in its name. Although both of LCDIFv3 and LCDIF are display controllers for scanning out frames onto display devices, I don't think they are in one family. So, LCDIFv3 deserves a new separate dt-binding, IMO. It seems to me a lot of those bits just map to their previous equivalents in older LCDIF, others were dropped, so this is some sort of new LCDIF mutation, is it not ? I am aware NXP has a separate driver in its downstream, but I'm not convinced the duplication of boilerplate code by introducing a separate driver for what looks like another LCDIF variant is the right approach. variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. [...]
Re: [pull] amdgpu, amdkfd drm-next-5.18
On Sat, 26 Feb 2022 at 04:35, Alex Deucher wrote: > > Hi Dave, Daniel, > > New stuff for 5.18. > > The following changes since commit b63c54d978236dd6014cf2ffba96d626e97c915c: > > drm/amdkfd: Use proper enum in pm_unmap_queues_v9() (2022-02-17 15:59:06 > -0500) > > are available in the Git repository at: > > https://gitlab.freedesktop.org/agd5f/linux.git > tags/amd-drm-next-5.18-2022-02-25 > > for you to fetch changes up to 111aeed25ec6bf4d5b4a7b4cb5654f002ba9f795: > > drm/amdgpu: add gfxoff support for smu 13.0.5 (2022-02-25 11:51:18 -0500) > > > amd-drm-next-5.18-2022-02-25: > > amdgpu: > - Raven2 suspend/resume fix > - SDMA 5.2.6 updates > - VCN 3.1.2 updates > - SMU 13.0.5 updates > - DCN 3.1.5 updates > - Virtual display fixes > - SMU code cleanup > - Harvest fixes > - Expose benchmark tests via debugfs > - Drop no longer relevant gart aperture tests > - More RAS restructuring > - W=1 fixes > - PSR rework > - DP/VGA adapter fixes > - DP MST fixes > - GPUVM eviction fix > - GPU reset debugfs register dumping support (this time keeping cc). ^ this seems to conflict with the removal of reset_sem or something in that area. Can you trial merge this to drm-next and send a fixup patch I should apply with it? Dave.
Re: [GIT PULL] drm/tegra: Changes for v5.18-rc1
Hi Thierry,
dim: d65e338027e7 ("gpu: host1x: Fix an error handling path in
'host1x_probe()'"): SHA1 in fixes line not found:
dim: e3166698a8a0 ("drm/tegra: Implement buffer object cache")
not the same as
1f39b1dfa53c84b56d7ad37fed44afda7004959d
Author: Thierry Reding
Date: Fri Feb 7 16:50:52 2020 +0100
drm/tegra: Implement buffer object cache
Please fix that up.
Dave.
On Sat, 26 Feb 2022 at 02:32, Thierry Reding wrote:
>
> Hi Dave, Daniel,
>
> The following changes since commit 8913e1aea4b32a866343b14e565c62cec54f3f78:
>
> drm/tegra: dpaux: Populate AUX bus (2022-02-23 13:00:37 +0100)
>
> are available in the Git repository at:
>
> https://gitlab.freedesktop.org/drm/tegra.git tags/drm/tegra/for-5.18-rc1
>
> for you to fetch changes up to b53c24f69199b88671293de503f1f999a762f4f9:
>
> drm/tegra: Support YVYU, VYUY and YU24 formats (2022-02-25 16:37:40 +0100)
>
> Thanks,
> Thierry
>
>
> drm/tegra: Changes for v5.18-rc1
>
> This contains a couple more minor fixes that didn't seem urgent enough
> for v5.17. On top of that this improves YUV format support on older
> chips.
>
>
> Christophe JAILLET (2):
> gpu: host1x: Fix an error handling path in 'host1x_probe()'
> gpu: host1x: Fix a memory leak in 'host1x_remove()'
>
> Dmitry Osipenko (1):
> drm/tegra: Use dev_err_probe()
>
> Miaoqian Lin (1):
> drm/tegra: Fix reference leak in tegra_dsi_ganged_probe
>
> Thierry Reding (3):
> drm/tegra: Fix planar formats on Tegra186 and later
> drm/tegra: Support semi-planar formats on Tegra114+
> drm/tegra: Support YVYU, VYUY and YU24 formats
>
> chiminghao (1):
> drm/tegra: dpaux: Remove unneeded variable
>
> drivers/gpu/drm/tegra/dc.c| 50 ++---
> drivers/gpu/drm/tegra/dc.h| 7 +
> drivers/gpu/drm/tegra/dpaux.c | 3 +-
> drivers/gpu/drm/tegra/dsi.c | 4 ++-
> drivers/gpu/drm/tegra/hdmi.c | 34 ++--
> drivers/gpu/drm/tegra/hub.c | 24 --
> drivers/gpu/drm/tegra/plane.c | 73
> ++-
> drivers/gpu/drm/tegra/plane.h | 2 +-
> drivers/gpu/host1x/dev.c | 8 +++--
> 9 files changed, 140 insertions(+), 65 deletions(-)
Re: linux-next: build failure after merge of the drm tree
On Mon, 28 Feb 2022 at 16:44, Hsin-Yi Wang wrote:
>
> On Sat, Feb 26, 2022 at 12:43 AM wrote:
> >
> > Hi all,
> >
> > After merging the drm tree, today's linux-next build (x86 allmodconfig)
> > failed like this:
> >
> > lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x10b: call
> > to do_strncpy_from_user() with UACCESS enabled
> > lib/strnlen_user.o: warning: objtool: strnlen_user()+0xbb: call to
> > do_strnlen_user() with UACCESS enabled
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c: In function
> > 'receive_timing_debugfs_show':
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> > | ^~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> > referencing 'read_buf'
> > 3076 | u8 read_buf[READ_BUFFER_SIZE];
> > | ^~~~
> > /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> > subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> > char[200]'} [-Werror=array-bounds]
> > 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> >
Re: linux-next: build failure after merge of the drm tree
On Sat, Feb 26, 2022 at 12:43 AM wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86 allmodconfig)
> failed like this:
>
> lib/strncpy_from_user.o: warning: objtool: strncpy_from_user()+0x10b: call to
> do_strncpy_from_user() with UACCESS enabled
> lib/strnlen_user.o: warning: objtool: strnlen_user()+0xbb: call to
> do_strnlen_user() with UACCESS enabled
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c: In function
> 'receive_timing_debugfs_show':
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
>
Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP
Hi Marek, Thank you for the patch. On Mon, Feb 28, 2022 at 01:45:57AM +0100, Marek Vasut wrote: > Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 > and is completely different from the LCDIFv3 found in i.MX23 in that it > has a completely scrambled register layout compared to all previous LCDIF > variants. The new LCDIFv3 also supports 36bit address space. However, > except for the complete bit reshuffling, this is still LCDIF and it still > works like one. > > Signed-off-by: Marek Vasut > Cc: Alexander Stein > Cc: Laurent Pinchart > Cc: Lucas Stach > Cc: Peng Fan > Cc: Rob Herring > Cc: Robby Cai > Cc: Sam Ravnborg > Cc: Stefan Agner > Cc: devicet...@vger.kernel.org > --- > Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > index 900a56cae80e6..9831ab53a053d 100644 > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > @@ -28,6 +28,7 @@ properties: >- fsl,imx7d-lcdif >- fsl,imx8mm-lcdif >- fsl,imx8mn-lcdif > + - fsl,imx8mp-lcdif As the hardware isn't backward-compatible with any other version, I think the new compatible string should go in the previous enum block, not in this one. We don't want the imx6sx fallback. >- fsl,imx8mq-lcdif >- const: fsl,imx6sx-lcdif > -- Regards, Laurent Pinchart
Re: [PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP
Hi Marek, On Mon, 2022-02-28 at 01:45 +0100, Marek Vasut wrote: > Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 > and is completely different from the LCDIFv3 found in i.MX23 in that it In i.MX23 reference manual, there is no LCDIFv3 found, but only LCDIF. > has a completely scrambled register layout compared to all previous LCDIF It looks like no single register of i.MX8MP LCDIFv3 overlaps with registers in other i.MX2x/6x/7x/8x LCDIFs. The LCDIFv3 block diagram is totally different from the LCDIF block diagram, according to the SoC reference manuals. LCDIFv3 supports SHADOW_EN bit to update horizontal and vertical size of graphic, position of graphic on the panel, address of graphic in memory and color formats or color palettes, which is not supported by LCDIF and impacts display driver control mechanism considerably. LCDIF supports DOTCLK interface, MPU interface and VSYNC interface, while LCDIFv3 only supports parallel output as a counterpart of the DOTCLK interface. Generally speaking, LCDIFv3 is just a new display IP which happens to have the word 'LCDIF' in its name. Although both of LCDIFv3 and LCDIF are display controllers for scanning out frames onto display devices, I don't think they are in one family. So, LCDIFv3 deserves a new separate dt-binding, IMO. > variants. The new LCDIFv3 also supports 36bit address space. However, > except for the complete bit reshuffling, this is still LCDIF and it still > works like one. > > Signed-off-by: Marek Vasut > Cc: Alexander Stein > Cc: Laurent Pinchart > Cc: Lucas Stach > Cc: Peng Fan > Cc: Rob Herring > Cc: Robby Cai > Cc: Sam Ravnborg > Cc: Stefan Agner > Cc: devicet...@vger.kernel.org > --- > Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > index 900a56cae80e6..9831ab53a053d 100644 > --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml > @@ -28,6 +28,7 @@ properties: >- fsl,imx7d-lcdif >- fsl,imx8mm-lcdif >- fsl,imx8mn-lcdif > + - fsl,imx8mp-lcdif Even if LCDIFv3 is covered by this dt-binding(which is obviously not the case), 'fsl,imx8mp-lcdif' should be after 'fsl,imx6x-lcdif' as an enum, otherwise LCDIFv3 is compatible to LCDIF. Regards, Liu Ying >- fsl,imx8mq-lcdif >- const: fsl,imx6sx-lcdif >
Re: [PATCH 9/9] drm: mxsfb: Add support for i.MX8MP LCDIF variant
Hi Marek,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next next-20220225]
[cannot apply to drm/drm-next drm-tip/drm-tip tegra-drm/drm/tegra/for-next
v5.17-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Marek-Vasut/dt-bindings-mxsfb-Add-compatible-for-i-MX8MP/20220228-084809
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a002-20220228
(https://download.01.org/0day-ci/archive/20220228/202202281124.rfkje01p-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d271fc04d5b97b12e6b797c6067d3c96a8d7470e)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/d6832d6fb879aabce18d9b451ed1ead1da38c333
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Marek-Vasut/dt-bindings-mxsfb-Add-compatible-for-i-MX8MP/20220228-084809
git checkout d6832d6fb879aabce18d9b451ed1ead1da38c333
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/mxsfb/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/mxsfb/mxsfb_kms.c:258:3: warning: variable 'ctrl' is
>> uninitialized when used here [-Wuninitialized]
ctrl |= CTRL_INV_HS;
^~~~
drivers/gpu/drm/mxsfb/mxsfb_kms.c:255:10: note: initialize the variable
'ctrl' to silence this warning
u32 ctrl;
^
= 0
1 warning generated.
vim +/ctrl +258 drivers/gpu/drm/mxsfb/mxsfb_kms.c
251
252 static void mxsfb_v8_set_mode(struct mxsfb_drm_private *mxsfb, u32
bus_flags)
253 {
254 struct drm_display_mode *m = >crtc.state->adjusted_mode;
255 u32 ctrl;
256
257 if (m->flags & DRM_MODE_FLAG_PHSYNC)
> 258 ctrl |= CTRL_INV_HS;
259 if (m->flags & DRM_MODE_FLAG_PVSYNC)
260 ctrl |= CTRL_INV_VS;
261 /* Make sure Data Enable is high active by default */
262 if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
263 ctrl |= CTRL_INV_DE;
264 if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)
265 ctrl |= CTRL_INV_PXCK;
266
267 writel(ctrl, mxsfb->base + LCDC_CTRL);
268
269 writel(DISP_SIZE_DELTA_Y(m->crtc_vdisplay) |
270 DISP_SIZE_DELTA_X(m->crtc_hdisplay),
271 mxsfb->base + LCDC_V8_DISP_SIZE);
272
273 writel(HSYN_PARA_BP_H(m->htotal - m->hsync_end) |
274 HSYN_PARA_FP_H(m->hsync_start - m->hdisplay),
275 mxsfb->base + LCDC_V8_HSYN_PARA);
276
277 writel(VSYN_PARA_BP_V(m->vtotal - m->vsync_end) |
278 VSYN_PARA_FP_V(m->vsync_start - m->vdisplay),
279 mxsfb->base + LCDC_V8_VSYN_PARA);
280
281 writel(VSYN_HSYN_WIDTH_PW_V(m->vsync_end - m->vsync_start) |
282 VSYN_HSYN_WIDTH_PW_H(m->hsync_end - m->hsync_start),
283 mxsfb->base + LCDC_V8_VSYN_HSYN_WIDTH);
284
285 writel(CTRLDESCL0_1_HEIGHT(m->crtc_vdisplay) |
286 CTRLDESCL0_1_WIDTH(m->crtc_hdisplay),
287 mxsfb->base + LCDC_V8_CTRLDESCL0_1);
288
289
writel(CTRLDESCL0_3_PITCH(mxsfb->crtc.primary->state->fb->pitches[0]),
290 mxsfb->base + LCDC_V8_CTRLDESCL0_3);
291 }
292
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
Re: linux-next: build failure after merge of the drm tree
Hi all,
On Fri, 25 Feb 2022 16:42:31 + broo...@kernel.org wrote:
>
> After merging the drm tree, today's linux-next build (x86 allmodconfig)
> failed like this:
>
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c: In function
> 'receive_timing_debugfs_show':
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> | ^~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3076:5: note: while
> referencing 'read_buf'
> 3076 | u8 read_buf[READ_BUFFER_SIZE];
> | ^~~~
> /tmp/next/build/drivers/gpu/drm/bridge/ite-it6505.c:3077:23: error: array
> subscript 4096 is outside array bounds of 'u8[200]' {aka 'unsigned
> char[200]'} [-Werror=array-bounds]
> 3077 | u8 *str = read_buf, *end = read_buf + PAGE_SIZE;
> |
Re: linux-next: manual merge of the drm-tegra tree with the drm tree
Hi all,
On Wed, 23 Feb 2022 16:30:07 + broo...@kernel.org wrote:
>
> Today's linux-next merge of the drm-tegra tree got conflicts in:
>
> drivers/gpu/drm/tegra/dpaux.c
> drivers/gpu/drm/tegra/Kconfig
>
> between commit:
>
> adb9d5a2cc77e ("drm/dp: Move DisplayPort helpers into separate helper
> module")
>
> from the drm tree and commit:
>
> 8913e1aea4b32 ("drm/tegra: dpaux: Populate AUX bus")
>
> from the drm-tegra tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc drivers/gpu/drm/tegra/Kconfig
> index 18c319b804c00,201f5175ecfec..0
> --- a/drivers/gpu/drm/tegra/Kconfig
> +++ b/drivers/gpu/drm/tegra/Kconfig
> @@@ -5,7 -5,7 +5,8 @@@ config DRM_TEGR
> depends on COMMON_CLK
> depends on DRM
> depends on OF
> +select DRM_DP_HELPER
> + select DRM_DP_AUX_BUS
> select DRM_KMS_HELPER
> select DRM_MIPI_DSI
> select DRM_PANEL
> diff --cc drivers/gpu/drm/tegra/dpaux.c
> index 8ca500977a46b,d7a731d287d23..0
> --- a/drivers/gpu/drm/tegra/dpaux.c
> +++ b/drivers/gpu/drm/tegra/dpaux.c
> @@@ -18,7 -18,8 +18,8 @@@
> #include
> #include
>
> -#include
> -#include
> +#include
> ++#include
> #include
>
> #include "dp.h"
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpL9RCx7dOXX.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the drm tree with Linus' tree
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
between commit:
e2b993302f40 ("drm/amdgpu: bypass tiling flag check in virtual display case
(v2)")
from Linus' tree and commit:
2af104290da5 ("drm: introduce fb_modifiers_not_supported flag in mode_config")
from the drm tree.
I fixed it up (I think - see below) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index c4387b38229c,9e5fc4cdb8ec..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@@ -1141,7 -1148,7 +1148,8 @@@ int amdgpu_display_framebuffer_init(str
if (ret)
return ret;
- if (!dev->mode_config.allow_fb_modifiers &&
!adev->enable_virtual_display) {
- if (dev->mode_config.fb_modifiers_not_supported) {
++ if (dev->mode_config.fb_modifiers_not_supported &&
++ !adev->enable_virtual_display) {
drm_WARN_ONCE(dev, adev->family >= AMDGPU_FAMILY_AI,
"GFX9+ requires FB check based on format
modifier\n");
ret = check_tiling_flags_gfx6(rfb);
pgpgOMqfjoE8D.pgp
Description: OpenPGP digital signature
[PATCH] docs: fix 'make htmldocs' error in vgaarbiter.rst
Fix following 'make htmldocs' error:
Error: Cannot open file ./drivers/gpu/vga/vgaarb.c
Error: Cannot open file ./drivers/gpu/vga/vgaarb.c
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version
2.4.4 -export ./drivers/gpu/vga/vgaarb.c' failed with return code 2
Fixes: d6e1898bfa5b ("PCI/VGA: Move vgaarb to drivers/pci")
Signed-off-by: Wan Jiabing
---
Documentation/gpu/vgaarbiter.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst
index 339ed5fecd2e..bde3c0afb059 100644
--- a/Documentation/gpu/vgaarbiter.rst
+++ b/Documentation/gpu/vgaarbiter.rst
@@ -100,7 +100,7 @@ In-kernel interface
.. kernel-doc:: include/linux/vgaarb.h
:internal:
-.. kernel-doc:: drivers/gpu/vga/vgaarb.c
+.. kernel-doc:: drivers/pci/vgaarb.c
:export:
libpciaccess
--
2.35.1
Re: [PATCH V2] drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check()
On 2/28/22 02:04, Marek Vasut wrote:
On 2/21/22 13:31, Boris Brezillon wrote:
On Mon, 21 Feb 2022 12:56:43 +0100
Max Krummenacher wrote:
Am Montag, den 21.02.2022, 09:29 +0100 schrieb Boris Brezillon:
Hello Christoph,
On Sat, 19 Feb 2022 09:28:44 +
Christoph Niedermaier wrote:
From: Max Krummenacher [mailto:max.oss...@gmail.com]
Sent: Wednesday, February 9, 2022 10:38 AM
If display timings were read from the devicetree using
of_get_display_timing() and pixelclk-active is defined
there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
automatically generated. Through the function
drm_bus_flags_from_videomode() e.g. called in the
panel-simple driver this flag got into the bus flags,
but then in imx_pd_bridge_atomic_check() the bus flag
check failed and will not initialize the display. The
original commit fe141cedc433 does not explain why this
Can you please update the commit message to fix the following warning:
Please use git commit description style 'commit <12+ chars of sha1>
("")' - ie: 'commit fe141cedc433 ("drm/imx: pd: Use bus
format/flags provided by the bridge when available")'
Also, collect the AB from Boris and TB from Max.
I can also fix it up for you while applying if that's OK with you.
Nevermind, the patch got applied, it seems I'm not that proficient with
dim yet ...
Re: [PATCH V2] drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check()
On 2/21/22 13:31, Boris Brezillon wrote:
On Mon, 21 Feb 2022 12:56:43 +0100
Max Krummenacher wrote:
Am Montag, den 21.02.2022, 09:29 +0100 schrieb Boris Brezillon:
Hello Christoph,
On Sat, 19 Feb 2022 09:28:44 +
Christoph Niedermaier wrote:
From: Max Krummenacher [mailto:max.oss...@gmail.com]
Sent: Wednesday, February 9, 2022 10:38 AM
If display timings were read from the devicetree using
of_get_display_timing() and pixelclk-active is defined
there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is
automatically generated. Through the function
drm_bus_flags_from_videomode() e.g. called in the
panel-simple driver this flag got into the bus flags,
but then in imx_pd_bridge_atomic_check() the bus flag
check failed and will not initialize the display. The
original commit fe141cedc433 does not explain why this
Can you please update the commit message to fix the following warning:
Please use git commit description style 'commit <12+ chars of sha1>
("")' - ie: 'commit fe141cedc433 ("drm/imx: pd: Use bus
format/flags provided by the bridge when available")'
Also, collect the AB from Boris and TB from Max.
I can also fix it up for you while applying if that's OK with you.
[...]
Acked-by: Boris Brezillon
[...]
Re: [PATCH] drm/panel: simple: Fix Innolux G070Y2-L01 BPP settings
On 2/20/22 05:52, Laurent Pinchart wrote:
Hi Marek,
Thank you for the patch.
On Sun, Feb 20, 2022 at 05:07:18AM +0100, Marek Vasut wrote:
The Innolux G070Y2-L01 supports two modes of operation:
1) FRC=Low/NC ... MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ... BPP=6
2) FRC=High . MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ... BPP=8
Currently the panel description mixes both, BPP from 1) and bus
format from 2), which triggers a warning at panel-simple.c:615.
Pick the later, set bpp=8, fix the warning.
Fixes: a5d2ade627dca ("drm/panel: simple: Add support for Innolux G070Y2-L01")
Signed-off-by: Marek Vasut
Cc: Christoph Fritz
Cc: Laurent Pinchart
Cc: Maxime Ripard
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
Reviewed-by: Laurent Pinchart
Applied to drm-misc-next-fixes
[PATCH 5/9] drm: mxsfb: Move mxsfb_get_fb_paddr() away from register IO functions
Move mxsfb_get_fb_paddr() out of the way, away from register IO functions.
This is a clean up. No functional change.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 015b289d93a3c..7b0abd0472aae 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -43,6 +43,21 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private
*mxsfb, u32 val)
mxsfb->devdata->hs_wdth_shift;
}
+static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
+{
+ struct drm_framebuffer *fb = plane->state->fb;
+ struct drm_gem_cma_object *gem;
+
+ if (!fb)
+ return 0;
+
+ gem = drm_fb_cma_get_gem_obj(fb, 0);
+ if (!gem)
+ return 0;
+
+ return gem->paddr;
+}
+
/*
* Setup the MXSFB registers for decoding the pixels out of the framebuffer and
* outputting them on the bus.
@@ -215,21 +230,6 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
return 0;
}
-static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
-{
- struct drm_framebuffer *fb = plane->state->fb;
- struct drm_gem_cma_object *gem;
-
- if (!fb)
- return 0;
-
- gem = drm_fb_cma_get_gem_obj(fb, 0);
- if (!gem)
- return 0;
-
- return gem->paddr;
-}
-
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb,
const u32 bus_format)
{
--
2.34.1
[PATCH 7/9] drm: mxsfb: Reorder mxsfb_crtc_mode_set_nofb()
Reorder mxsfb_crtc_mode_set_nofb() such that all functions which perform register IO are called from one single location in this function. This is a clean up. No functional change. Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 14f5cc590a51b..497603964add8 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -289,13 +289,6 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb, u32 bus_flags = mxsfb->connector->display_info.bus_flags; int err; - /* Mandatory eLCDIF reset as per the Reference Manual */ - err = mxsfb_reset_block(mxsfb); - if (err) - return; - - mxsfb_set_formats(mxsfb, bus_format); - if (mxsfb->bridge && mxsfb->bridge->timings) bus_flags = mxsfb->bridge->timings->input_bus_flags; @@ -306,6 +299,13 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb, bus_flags); DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags); + /* Mandatory eLCDIF reset as per the Reference Manual */ + err = mxsfb_reset_block(mxsfb); + if (err) + return; + + mxsfb_set_formats(mxsfb, bus_format); + mxsfb_set_mode(mxsfb, bus_flags); } -- 2.34.1
[PATCH 4/9] drm: mxsfb: Wrap FIFO reset and comments into mxsfb_reset_block()
Wrap FIFO reset and comments into mxsfb_reset_block(), this is a clean up.
No functional change.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 36 +--
1 file changed, 20 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 657b6afbbf1f9..015b289d93a3c 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -183,6 +183,12 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
{
int ret;
+ /*
+* It seems, you can't re-program the controller if it is still
+* running. This may lead to shifted pictures (FIFO issue?), so
+* first stop the controller and drain its FIFOs.
+*/
+
ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_SFTRST);
if (ret)
return ret;
@@ -193,7 +199,20 @@ static int mxsfb_reset_block(struct mxsfb_drm_private
*mxsfb)
if (ret)
return ret;
- return clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
+ ret = clear_poll_bit(mxsfb->base + LCDC_CTRL, CTRL_CLKGATE);
+ if (ret)
+ return ret;
+
+ /* Clear the FIFOs */
+ writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
+ readl(mxsfb->base + LCDC_CTRL1);
+ writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
+ readl(mxsfb->base + LCDC_CTRL1);
+
+ if (mxsfb->devdata->has_overlay)
+ writel(0, mxsfb->base + LCDC_AS_CTRL);
+
+ return 0;
}
static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
@@ -220,26 +239,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
- /*
-* It seems, you can't re-program the controller if it is still
-* running. This may lead to shifted pictures (FIFO issue?), so
-* first stop the controller and drain its FIFOs.
-*/
-
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb);
if (err)
return;
- /* Clear the FIFOs */
- writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
- readl(mxsfb->base + LCDC_CTRL1);
- writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- readl(mxsfb->base + LCDC_CTRL1);
-
- if (mxsfb->devdata->has_overlay)
- writel(0, mxsfb->base + LCDC_AS_CTRL);
-
mxsfb_set_formats(mxsfb, bus_format);
if (mxsfb->bridge && mxsfb->bridge->timings)
--
2.34.1
[PATCH 2/9] drm: mxsfb: Simplify LCDIF clock handling
The current clock handling in the LCDIF driver is a convoluted mess.
Implement runtime PM ops which turn the clock ON and OFF and let the
pm_runtime_get_sync()/pm_runtime_put_sync() calls in .atomic_enable
and .atomic_disable callbacks turn the clock ON and OFF at the right
time.
This requires slight reordering in mxsfb_crtc_atomic_enable() and
mxsfb_crtc_atomic_disable(), since all the register accesses must
happen only with clock enabled and clock frequency configuration
must happen with clock disabled.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 100 +-
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 27 +++-
2 files changed, 66 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 375f26d4a4172..bb15e32d8a014 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -72,18 +72,6 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
},
};
-void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
- if (mxsfb->clk_axi)
- clk_prepare_enable(mxsfb->clk_axi);
-}
-
-void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
-{
- if (mxsfb->clk_axi)
- clk_disable_unprepare(mxsfb->clk_axi);
-}
-
static struct drm_framebuffer *
mxsfb_fb_create(struct drm_device *dev, struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd)
@@ -172,13 +160,9 @@ static void mxsfb_irq_disable(struct drm_device *drm)
{
struct mxsfb_drm_private *mxsfb = drm->dev_private;
- mxsfb_enable_axi_clk(mxsfb);
-
/* Disable and clear VBLANK IRQ */
writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-
- mxsfb_disable_axi_clk(mxsfb);
}
static int mxsfb_irq_install(struct drm_device *dev, int irq)
@@ -224,33 +208,33 @@ static int mxsfb_load(struct drm_device *drm,
if (IS_ERR(mxsfb->clk))
return PTR_ERR(mxsfb->clk);
- mxsfb->clk_axi = devm_clk_get(drm->dev, "axi");
+ mxsfb->clk_axi = devm_clk_get_optional(drm->dev, "axi");
if (IS_ERR(mxsfb->clk_axi))
- mxsfb->clk_axi = NULL;
+ return PTR_ERR(mxsfb->clk_axi);
- mxsfb->clk_disp_axi = devm_clk_get(drm->dev, "disp_axi");
+ mxsfb->clk_disp_axi = devm_clk_get_optional(drm->dev, "disp_axi");
if (IS_ERR(mxsfb->clk_disp_axi))
- mxsfb->clk_disp_axi = NULL;
+ return PTR_ERR(mxsfb->clk_disp_axi);
+
+ platform_set_drvdata(pdev, drm);
ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
if (ret)
return ret;
- pm_runtime_enable(drm->dev);
-
/* Modeset init */
drm_mode_config_init(drm);
ret = mxsfb_kms_init(mxsfb);
if (ret < 0) {
dev_err(drm->dev, "Failed to initialize KMS pipeline\n");
- goto err_vblank;
+ return ret;
}
ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
if (ret < 0) {
dev_err(drm->dev, "Failed to initialise vblank\n");
- goto err_vblank;
+ return ret;
}
/* Start with vertical blanking interrupt reporting disabled. */
@@ -260,7 +244,7 @@ static int mxsfb_load(struct drm_device *drm,
if (ret) {
if (ret != -EPROBE_DEFER)
dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
- goto err_vblank;
+ return ret;
}
drm->mode_config.min_width = MXSFB_MIN_XRES;
@@ -274,44 +258,37 @@ static int mxsfb_load(struct drm_device *drm,
ret = platform_get_irq(pdev, 0);
if (ret < 0)
- goto err_vblank;
+ return ret;
mxsfb->irq = ret;
- pm_runtime_get_sync(drm->dev);
ret = mxsfb_irq_install(drm, mxsfb->irq);
- pm_runtime_put_sync(drm->dev);
-
if (ret < 0) {
dev_err(drm->dev, "Failed to install IRQ handler\n");
- goto err_vblank;
+ return ret;
}
drm_kms_helper_poll_init(drm);
- platform_set_drvdata(pdev, drm);
-
drm_helper_hpd_irq_event(drm);
- return 0;
-
-err_vblank:
- pm_runtime_disable(drm->dev);
+ pm_runtime_enable(drm->dev);
- return ret;
+ return 0;
}
static void mxsfb_unload(struct drm_device *drm)
{
+ pm_runtime_get_sync(drm->dev);
+
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
- pm_runtime_get_sync(drm->dev);
mxsfb_irq_uninstall(drm);
+
pm_runtime_put_sync(drm->dev);
+ pm_runtime_disable(drm->dev);
[PATCH 8/9] drm: mxsfb: Factor out mxsfb_update_buffer()
Pull functionality responsible for programming framebuffer address into
the controller into dedicated function mxsfb_update_buffer(). This is a
clean up. No functional change.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 497603964add8..4baa3db1f3d10 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -58,6 +58,22 @@ static dma_addr_t mxsfb_get_fb_paddr(struct drm_plane *plane)
return gem->paddr;
}
+static void
+mxsfb_update_buffer(struct mxsfb_drm_private *mxsfb, struct drm_plane *plane,
+ bool both)
+{
+ dma_addr_t paddr;
+
+ paddr = mxsfb_get_fb_paddr(plane);
+ if (!paddr)
+ return;
+
+ if (both)
+ writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
+
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+}
+
/*
* Setup the MXSFB registers for decoding the pixels out of the framebuffer and
* outputting them on the bus.
@@ -352,7 +368,6 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
struct drm_bridge_state *bridge_state;
struct drm_device *drm = mxsfb->drm;
u32 bus_format = 0;
- dma_addr_t paddr;
/* If there is a bridge attached to the LCDIF, use its bus format */
if (mxsfb->bridge) {
@@ -387,11 +402,7 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
mxsfb_crtc_mode_set_nofb(mxsfb, bus_format);
/* Write cur_buf as well to avoid an initial corrupt frame */
- paddr = mxsfb_get_fb_paddr(crtc->primary);
- if (paddr) {
- writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
- writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
- }
+ mxsfb_update_buffer(mxsfb, crtc->primary, true);
mxsfb_enable_controller(mxsfb);
@@ -491,11 +502,8 @@ static void mxsfb_plane_primary_atomic_update(struct
drm_plane *plane,
struct drm_atomic_state *state)
{
struct mxsfb_drm_private *mxsfb = to_mxsfb_drm_private(plane->dev);
- dma_addr_t paddr;
- paddr = mxsfb_get_fb_paddr(plane);
- if (paddr)
- writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ mxsfb_update_buffer(mxsfb, plane, false);
}
static void mxsfb_plane_overlay_atomic_update(struct drm_plane *plane,
--
2.34.1
[PATCH 6/9] drm: mxsfb: Factor out mxsfb_set_mode()
Pull mode registers programming from mxsfb_enable_controller() into
dedicated function mxsfb_set_mode(). This is a clean up. No functional
change.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 96 +--
1 file changed, 52 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 7b0abd0472aae..14f5cc590a51b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -111,6 +111,57 @@ static void mxsfb_set_formats(struct mxsfb_drm_private
*mxsfb,
writel(ctrl, mxsfb->base + LCDC_CTRL);
}
+static void mxsfb_set_mode(struct mxsfb_drm_private *mxsfb, u32 bus_flags)
+{
+ struct drm_display_mode *m = >crtc.state->adjusted_mode;
+ u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
+
+ writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
+ TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
+ mxsfb->base + mxsfb->devdata->transfer_count);
+
+ vsync_pulse_len = m->crtc_vsync_end - m->crtc_vsync_start;
+
+ vdctrl0 = VDCTRL0_ENABLE_PRESENT | /* Always in DOTCLOCK mode */
+ VDCTRL0_VSYNC_PERIOD_UNIT |
+ VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
+ VDCTRL0_SET_VSYNC_PULSE_WIDTH(vsync_pulse_len);
+ if (m->flags & DRM_MODE_FLAG_PHSYNC)
+ vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
+ if (m->flags & DRM_MODE_FLAG_PVSYNC)
+ vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
+ /* Make sure Data Enable is high active by default */
+ if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
+ vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
+ /*
+* DRM_BUS_FLAG_PIXDATA_DRIVE_ defines are controller centric,
+* controllers VDCTRL0_DOTCLK is display centric.
+* Drive on positive edge -> display samples on falling edge
+* DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
+*/
+ if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
+ vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
+
+ writel(vdctrl0, mxsfb->base + LCDC_VDCTRL0);
+
+ /* Frame length in lines. */
+ writel(m->crtc_vtotal, mxsfb->base + LCDC_VDCTRL1);
+
+ /* Line length in units of clocks or pixels. */
+ hsync_pulse_len = m->crtc_hsync_end - m->crtc_hsync_start;
+ writel(set_hsync_pulse_width(mxsfb, hsync_pulse_len) |
+ VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal),
+ mxsfb->base + LCDC_VDCTRL2);
+
+ writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) |
+ SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
+ mxsfb->base + LCDC_VDCTRL3);
+
+ writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
+ mxsfb->base + LCDC_VDCTRL4);
+
+}
+
static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb)
{
u32 reg;
@@ -236,7 +287,6 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
struct drm_device *drm = mxsfb->crtc.dev;
struct drm_display_mode *m = >crtc.state->adjusted_mode;
u32 bus_flags = mxsfb->connector->display_info.bus_flags;
- u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
int err;
/* Mandatory eLCDIF reset as per the Reference Manual */
@@ -256,49 +306,7 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb,
bus_flags);
DRM_DEV_DEBUG_DRIVER(drm->dev, "Mode flags: 0x%08X\n", m->flags);
- writel(TRANSFER_COUNT_SET_VCOUNT(m->crtc_vdisplay) |
- TRANSFER_COUNT_SET_HCOUNT(m->crtc_hdisplay),
- mxsfb->base + mxsfb->devdata->transfer_count);
-
- vsync_pulse_len = m->crtc_vsync_end - m->crtc_vsync_start;
-
- vdctrl0 = VDCTRL0_ENABLE_PRESENT | /* Always in DOTCLOCK mode */
- VDCTRL0_VSYNC_PERIOD_UNIT |
- VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
- VDCTRL0_SET_VSYNC_PULSE_WIDTH(vsync_pulse_len);
- if (m->flags & DRM_MODE_FLAG_PHSYNC)
- vdctrl0 |= VDCTRL0_HSYNC_ACT_HIGH;
- if (m->flags & DRM_MODE_FLAG_PVSYNC)
- vdctrl0 |= VDCTRL0_VSYNC_ACT_HIGH;
- /* Make sure Data Enable is high active by default */
- if (!(bus_flags & DRM_BUS_FLAG_DE_LOW))
- vdctrl0 |= VDCTRL0_ENABLE_ACT_HIGH;
- /*
-* DRM_BUS_FLAG_PIXDATA_DRIVE_ defines are controller centric,
-* controllers VDCTRL0_DOTCLK is display centric.
-* Drive on positive edge -> display samples on falling edge
-* DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE -> VDCTRL0_DOTCLK_ACT_FALLING
-*/
- if (bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE)
- vdctrl0 |= VDCTRL0_DOTCLK_ACT_FALLING;
-
- writel(vdctrl0, mxsfb->base
[PATCH 3/9] drm: mxsfb: Simplify LCDIF IRQ handling
The call to drm_crtc_vblank_off(>crtc); disables IRQ generation
from the LCDIF block already and this is called in mxsfb_load() before
request_irq(), so explicitly disabling IRQ using custom function like
mxsfb_irq_disable() is not needed, remove it. The request_irq() call
would return -ENOTCONN if IRQ is IRQ_NOTCONNECTED already, so remove
the unnecessary check. Finally, remove both mxsfb_irq_install() and
mxsfb_irq_uninstall() as well, since they are no longer useful.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 38 +++
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index bb15e32d8a014..11298df50917c 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -156,33 +156,6 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
-static void mxsfb_irq_disable(struct drm_device *drm)
-{
- struct mxsfb_drm_private *mxsfb = drm->dev_private;
-
- /* Disable and clear VBLANK IRQ */
- writel(CTRL1_CUR_FRAME_DONE_IRQ_EN, mxsfb->base + LCDC_CTRL1 + REG_CLR);
- writel(CTRL1_CUR_FRAME_DONE_IRQ, mxsfb->base + LCDC_CTRL1 + REG_CLR);
-}
-
-static int mxsfb_irq_install(struct drm_device *dev, int irq)
-{
- if (irq == IRQ_NOTCONNECTED)
- return -ENOTCONN;
-
- mxsfb_irq_disable(dev);
-
- return request_irq(irq, mxsfb_irq_handler, 0, dev->driver->name, dev);
-}
-
-static void mxsfb_irq_uninstall(struct drm_device *dev)
-{
- struct mxsfb_drm_private *mxsfb = dev->dev_private;
-
- mxsfb_irq_disable(dev);
- free_irq(mxsfb->irq, dev);
-}
-
static int mxsfb_load(struct drm_device *drm,
const struct mxsfb_devdata *devdata)
{
@@ -261,7 +234,8 @@ static int mxsfb_load(struct drm_device *drm,
return ret;
mxsfb->irq = ret;
- ret = mxsfb_irq_install(drm, mxsfb->irq);
+ ret = request_irq(mxsfb->irq, mxsfb_irq_handler, 0,
+ drm->driver->name, drm);
if (ret < 0) {
dev_err(drm->dev, "Failed to install IRQ handler\n");
return ret;
@@ -278,16 +252,20 @@ static int mxsfb_load(struct drm_device *drm,
static void mxsfb_unload(struct drm_device *drm)
{
+ struct mxsfb_drm_private *mxsfb = drm->dev_private;
+
pm_runtime_get_sync(drm->dev);
+ drm_crtc_vblank_off(>crtc);
+
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);
- mxsfb_irq_uninstall(drm);
-
pm_runtime_put_sync(drm->dev);
pm_runtime_disable(drm->dev);
+ free_irq(mxsfb->irq, drm->dev);
+
drm->dev_private = NULL;
}
--
2.34.1
[PATCH 9/9] drm: mxsfb: Add support for i.MX8MP LCDIF variant
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is
completely different from the LCDIFv3 found in i.MX23 in that it has
a completely scrambled register layout compared to all previous LCDIF
variants. The new LCDIFv3 also supports 36bit address space.
However, except for the complete bit reshuffling, this is still LCDIF
and it still works like one, the boilerplate code is also the same,
hence it is part of this driver. This is probably still a bit better
than a separate driver with a lot of duplicated code.
Signed-off-by: Marek Vasut
Cc: Alexander Stein
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Peng Fan
Cc: Robby Cai
Cc: Sam Ravnborg
Cc: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 34 -
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 +
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 219 +++--
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 136 ++
4 files changed, 374 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 11298df50917c..7fd7fd1496f7d 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -40,6 +40,8 @@ enum mxsfb_devtype {
* i.MX family number as the version.
*/
MXSFB_V6,
+ /* Starting at i.MX8MP the register layout is scrambled. */
+ MXSFB_V8,
};
static const struct mxsfb_devdata mxsfb_devdata[] = {
@@ -51,6 +53,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_shift = 24,
.has_overlay= false,
.has_ctrl2 = false,
+ .has_regsv8 = false,
},
[MXSFB_V4] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
@@ -60,6 +63,7 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_shift = 18,
.has_overlay= false,
.has_ctrl2 = true,
+ .has_regsv8 = false,
},
[MXSFB_V6] = {
.transfer_count = LCDC_V4_TRANSFER_COUNT,
@@ -69,6 +73,13 @@ static const struct mxsfb_devdata mxsfb_devdata[] = {
.hs_wdth_shift = 18,
.has_overlay= true,
.has_ctrl2 = true,
+ .has_regsv8 = false,
+ },
+ [MXSFB_V8] = {
+ /* Old register layout details do not apply here. */
+ .has_overlay= false,
+ .has_ctrl2 = false,
+ .has_regsv8 = true,
},
};
@@ -156,6 +167,22 @@ static irqreturn_t mxsfb_irq_handler(int irq, void *data)
return IRQ_HANDLED;
}
+static irqreturn_t mxsfb_v8_irq_handler(int irq, void *data)
+{
+ struct drm_device *drm = data;
+ struct mxsfb_drm_private *mxsfb = drm->dev_private;
+ u32 reg;
+
+ reg = readl(mxsfb->base + LCDC_V8_INT_STATUS_D0);
+
+ if (reg & INT_STATUS_D0_VS_BLANK)
+ drm_crtc_handle_vblank(>crtc);
+
+ writel(INT_STATUS_D0_VS_BLANK, mxsfb->base + LCDC_V8_INT_STATUS_D0);
+
+ return IRQ_HANDLED;
+}
+
static int mxsfb_load(struct drm_device *drm,
const struct mxsfb_devdata *devdata)
{
@@ -191,7 +218,8 @@ static int mxsfb_load(struct drm_device *drm,
platform_set_drvdata(pdev, drm);
- ret = dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32));
+ ret = dma_set_mask_and_coherent(drm->dev,
+ DMA_BIT_MASK(devdata->has_regsv8 ? 36 : 32));
if (ret)
return ret;
@@ -234,7 +262,8 @@ static int mxsfb_load(struct drm_device *drm,
return ret;
mxsfb->irq = ret;
- ret = request_irq(mxsfb->irq, mxsfb_irq_handler, 0,
+ ret = request_irq(mxsfb->irq, devdata->has_regsv8 ?
+ mxsfb_v8_irq_handler : mxsfb_irq_handler, 0,
drm->driver->name, drm);
if (ret < 0) {
dev_err(drm->dev, "Failed to install IRQ handler\n");
@@ -286,6 +315,7 @@ static const struct of_device_id mxsfb_dt_ids[] = {
{ .compatible = "fsl,imx23-lcdif", .data = _devdata[MXSFB_V3], },
{ .compatible = "fsl,imx28-lcdif", .data = _devdata[MXSFB_V4], },
{ .compatible = "fsl,imx6sx-lcdif", .data = _devdata[MXSFB_V6], },
+ { .compatible = "fsl,imx8mp-lcdif", .data = _devdata[MXSFB_V8], },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, mxsfb_dt_ids);
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
index ddb5b0417a82c..74c5e6013ca43 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
@@ -23,6 +23,7 @@ struct mxsfb_devdata {
unsigned inths_wdth_shift;
boolhas_overlay;
boolhas_ctrl2;
+ boolhas_regsv8;
};
struct mxsfb_drm_private {
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index
[PATCH 1/9] dt-bindings: mxsfb: Add compatible for i.MX8MP
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. Signed-off-by: Marek Vasut Cc: Alexander Stein Cc: Laurent Pinchart Cc: Lucas Stach Cc: Peng Fan Cc: Rob Herring Cc: Robby Cai Cc: Sam Ravnborg Cc: Stefan Agner Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/display/fsl,lcdif.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml index 900a56cae80e6..9831ab53a053d 100644 --- a/Documentation/devicetree/bindings/display/fsl,lcdif.yaml +++ b/Documentation/devicetree/bindings/display/fsl,lcdif.yaml @@ -28,6 +28,7 @@ properties: - fsl,imx7d-lcdif - fsl,imx8mm-lcdif - fsl,imx8mn-lcdif + - fsl,imx8mp-lcdif - fsl,imx8mq-lcdif - const: fsl,imx6sx-lcdif -- 2.34.1
Re: [greybus-dev] [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
On Sun, Feb 27, 2022 at 3:04 PM Alex Elder wrote: > > Glancing at the Greybus code, I don't believe there's any > reason it needs to shift a negative value. Such warnings > could be fixed by making certain variables unsigned, for > example. As mentioned in the original thread, making things unsigned actually is likely to introduce bugs and make things worse. The warning is simply bogus, and the fact that it was enabled by -Wextra in gcc for std=gnu99 and up was a mistake that looks likely to be fixed in gcc. So don't try to "fix" the code to make any possible warnings go away. You may just make things worse. (That is often true in general for the more esoteric warnings, but in this case it's just painfully more obvious). Linus
Re: [PATCH] Kbuild: remove -std=gnu89 from compiler arguments
On Sun, Feb 27, 2022 at 1:54 PM Arnd Bergmann wrote: > > Since the differences between gnu99, gnu11 and gnu17 are fairly minimal > and mainly impact warnings at the -Wpedantic level that the kernel > never enables, the easiest way is to just leave out the -std=gnu89 > argument entirely, and rely on the compiler default language setting, > which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported > versions of gcc or clang. Honestly, I'd rather keep the C version we support as some explicit thing, instead of "whatever the installed compiler is". Not only do I suspect that you can set it in gcc spec files (so the standard version might actually be site-specific, not compiler version specific), but particularly with clang, I'd like that "GNU extensions enabled" to be explicit. Yes, maybe it's the default, but let's make sure. The C version level has traditionally had a lot of odd semantic meaning details - you mention "inline", others have existed. So it's not just the actual new features that some C version implements, it's those kind of "same syntax, different meaning" issues. I really don't think that's something we want in the kernel any more. Been there, done that, and we did the explicit standards level for a reason. It may be true that c99/c11/c17 are all very similar, and don't have those issues. Or maybe they do. And I don't want somebody with a newer compiler version to not notice that he or she ended up using a c17 feature, just because _that_ compiler supported it, and then other people get build errors because their compilers use gnu11 instead by default. Put another way: I see absolutely no upside to allowing different users using higher/lower versions of the standard. There are only downsides. If gnu11 is supported by gcc-5.1 and up, and all the relevant clang versions, then let's just pick that. And if there are any possible future advantages to gnu17 (or eventual gnu2x versions), let's document those, so that we can say "once our compiler version requirements go up sufficiently, we'll move to gnuXX because we want to take advantage of YY". Please? Linus Linus
[PATCH] Kbuild: remove -std=gnu89 from compiler arguments
From: Arnd Bergmann During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well. An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 and gnu89, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago. One minor issue that remains is an added gcc warning for shifts of negative integers when building with -Werror, which happens with the 'make W=1' option, as well as for three drivers in the kernel that always enable -Werror, but it was only observed with the i915 driver so far. Nathan Chancellor reported an additional -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround. Since the differences between gnu99, gnu11 and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables, the easiest way is to just leave out the -std=gnu89 argument entirely, and rely on the compiler default language setting, which is gnu11 for gcc-5, and gnu1x/gnu17 for all other supported versions of gcc or clang. Link: https://lore.kernel.org/lkml/CAHk-=wiych7xehcmifj-ygxuy2jaj7pnkdkpcovt8fybvfw...@mail.gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds Cc: Masahiro Yamada Cc: linux-kbu...@vger.kernel.org Cc: l...@lists.linux.dev Signed-off-by: Arnd Bergmann --- I put the suggestion into patch form, based on what we discussed in the thread. I only gave it minimal testing, but it would be good to have it in linux-next if we want to do this in the merge window. --- Documentation/process/programming-language.rst | 4 ++-- .../translations/it_IT/process/programming-language.rst| 4 ++-- .../translations/zh_CN/process/programming-language.rst| 4 ++-- .../translations/zh_TW/process/programming-language.rst| 4 ++-- Makefile | 7 +++ arch/arm64/kernel/vdso32/Makefile | 3 +-- drivers/gpu/drm/i915/Makefile | 1 + drivers/staging/greybus/tools/Makefile | 3 ++- fs/btrfs/Makefile | 1 + scripts/Makefile.extrawarn | 1 + 10 files changed, 17 insertions(+), 15 deletions(-) diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index ec474a70a02f..894f2a6eb9db 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -5,8 +5,8 @@ Programming Language The kernel is written in the C programming language [c-language]_. More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 -(including some C99 features). ``clang`` [clang]_ is also supported, see +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11 +(including some C17 features). ``clang`` [clang]_ is also supported, see docs on :ref:`Building Linux with Clang/LLVM `. This dialect contains many extensions to the language [gnu-extensions]_, diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index 41db2598ce11..aa21097737ae 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -10,8 +10,8 @@ Linguaggio di programmazione Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_. Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando -l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU -dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99). +l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU +dello standard ISO C11 (con l'aggiunta di alcune funzionalità da C17). Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione :ref:`Building Linux with Clang/LLVM `. diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst index 2a47a1d2ec20..58d2b3bd2d85 100644 --- a/Documentation/translations/zh_CN/process/programming-language.rst +++
Re: [PATCH v3 0/2] drm/dp: Fix out-of-bounds reads
On Fri, Feb 25, 2022 at 10:30:19AM +0100, Thierry Reding wrote: > On Thu, Feb 24, 2022 at 07:56:08PM -0800, Kees Cook wrote: > > Hi, > > > > I'm sending these again, as they still need fixing. They have been > > rebased due to the drm_dp_helper code being moved into a subdirectory. > > Yeah, I noticed the other day that this had been partially reverted by > the DP code move. I've applied this now, though it didn't apply cleanly, > so I'll do a couple of test builds to make sure my resolution is correct > and will push this out later on. Awesome; thank you! Yeah, I had based on drm/drm-next rather than drm-misc/drm-misc-next. I wasn't sure which tree I needed to base on after the files moved. FWIW, the resulting patches look good to me. Thanks for fixing them up! -Kees -- Kees Cook
[CI 2/2] drm/i915/gem: Don't try to map and fence large scanout buffers (v9)
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
more framebuffers/scanout buffers results in only one that is mappable/
fenceable. Therefore, pageflipping between these 2 FBs where only one
is mappable/fenceable creates latencies large enough to miss alternate
vblanks thereby producing less optimal framerate.
This mainly happens because when i915_gem_object_pin_to_display_plane()
is called to pin one of the FB objs, the associated vma is identified
as misplaced and therefore i915_vma_unbind() is called which unbinds and
evicts it. This misplaced vma gets subseqently pinned only when
i915_gem_object_ggtt_pin_ww() is called without PIN_MAPPABLE. This
results in a latency of ~10ms and happens every other vblank/repaint cycle.
Therefore, to fix this issue, we try to see if there is space to map
at-least two objects of a given size and return early if there isn't. This
would ensure that we do not try with PIN_MAPPABLE for any objects that
are too big to map thereby preventing unncessary unbind.
Testcase:
Running Weston and weston-simple-egl on an Alderlake_S (ADLS) platform
with a 8K@60 mode results in only ~40 FPS. Since upstream Weston submits
a frame ~7ms before the next vblank, the latencies seen between atomic
commit and flip event are 7, 24 (7 + 16.66), 7, 24. suggesting that
it misses the vblank every other frame.
Here is the ftrace snippet that shows the source of the ~10ms latency:
i915_gem_object_pin_to_display_plane() {
0.102 us |i915_gem_object_set_cache_level();
i915_gem_object_ggtt_pin_ww() {
0.390 us | i915_vma_instance();
0.178 us | i915_vma_misplaced();
i915_vma_unbind() {
__i915_active_wait() {
0.082 us |i915_active_acquire_if_busy();
0.475 us | }
intel_runtime_pm_get() {
0.087 us |intel_runtime_pm_acquire();
0.259 us | }
__i915_active_wait() {
0.085 us |i915_active_acquire_if_busy();
0.240 us | }
__i915_vma_evict() {
ggtt_unbind_vma() {
gen8_ggtt_clear_range() {
10507.255 us |}
10507.689 us | }
10508.516 us | }
v2: Instead of using bigjoiner checks, determine whether a scanout
buffer is too big by checking to see if it is possible to map
two of them into the ggtt.
v3 (Ville):
- Count how many fb objects can be fit into the available holes
instead of checking for a hole twice the object size.
- Take alignment constraints into account.
- Limit this large scanout buffer check to >= Gen 11 platforms.
v4:
- Remove existing heuristic that checks just for size. (Ville)
- Return early if we find space to map at-least two objects. (Tvrtko)
- Slightly update the commit message.
v5: (Tvrtko)
- Rename the function to indicate that the object may be too big to
map into the aperture.
- Account for guard pages while calculating the total size required
for the object.
- Do not subject all objects to the heuristic check and instead
consider objects only of a certain size.
- Do the hole walk using the rbtree.
- Preserve the existing PIN_NONBLOCK logic.
- Drop the PIN_MAPPABLE check while pinning the VMA.
v6: (Tvrtko)
- Return 0 on success and the specific error code on failure to
preserve the existing behavior.
v7: (Ville)
- Drop the HAS_GMCH(i915), DISPLAY_VER(i915) < 11 and
size < ggtt->mappable_end / 4 checks.
- Drop the redundant check that is based on previous heuristic.
v8:
- Make sure that we are holding the mutex associated with ggtt vm
as we traverse the hole nodes.
v9: (Tvrtko)
- Use mutex_lock_interruptible_nested() instead of mutex_lock().
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Manasi Navare
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/i915/i915_gem.c | 128 +++-
1 file changed, 94 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2e10187cd0a0..4bef9eaa8b2e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -49,6 +49,7 @@
#include "gem/i915_gem_pm.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_userptr.h"
+#include "gem/i915_gem_tiling.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
#include "gt/intel_gt_pm.h"
@@ -879,6 +880,96 @@ static void discard_ggtt_vma(struct i915_vma *vma)
spin_unlock(>vma.lock);
}
+static int
+i915_gem_object_fits_in_aperture(struct drm_i915_gem_object *obj,
+u64 alignment, u64 flags)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+ struct drm_mm_node *hole;
+ u64 hole_start, hole_end, start, end;
+ u64 fence_size, fence_alignment;
+ unsigned int count = 0;
+ int err = 0;
+
+ /*
+* If the
[CI 1/2] drm/mm: Add an iterator to optimally walk over holes for an allocation (v4)
This iterator relies on drm_mm_first_hole() and drm_mm_next_hole()
functions to identify suitable holes for an allocation of a given
size by efficiently traversing the rbtree associated with the given
allocator.
It replaces the for loop in drm_mm_insert_node_in_range() and can
also be used by drm drivers to quickly identify holes of a certain
size within a given range.
v2: (Tvrtko)
- Prepend a double underscore for the newly exported first/next_hole
- s/each_best_hole/each_suitable_hole/g
- Mask out DRM_MM_INSERT_ONCE from the mode before calling
first/next_hole and elsewhere.
v3: (Tvrtko)
- Reduce the number of hunks by retaining the "mode" variable name
v4:
- Typo: s/__drm_mm_next_hole(.., hole/__drm_mm_next_hole(.., pos
Reviewed-by: Tvrtko Ursulin
Acked-by: Christian König
Suggested-by: Tvrtko Ursulin
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/drm_mm.c | 32 +++-
include/drm/drm_mm.h | 36
2 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..8efea548ae9f 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -352,10 +352,10 @@ static struct drm_mm_node *find_hole_addr(struct drm_mm
*mm, u64 addr, u64 size)
return node;
}
-static struct drm_mm_node *
-first_hole(struct drm_mm *mm,
- u64 start, u64 end, u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -374,6 +374,7 @@ first_hole(struct drm_mm *mm,
hole_stack);
}
}
+EXPORT_SYMBOL(__drm_mm_first_hole);
/**
* DECLARE_NEXT_HOLE_ADDR - macro to declare next hole functions
@@ -410,11 +411,11 @@ static struct drm_mm_node *name(struct drm_mm_node
*entry, u64 size) \
DECLARE_NEXT_HOLE_ADDR(next_hole_high_addr, rb_left, rb_right)
DECLARE_NEXT_HOLE_ADDR(next_hole_low_addr, rb_right, rb_left)
-static struct drm_mm_node *
-next_hole(struct drm_mm *mm,
- struct drm_mm_node *node,
- u64 size,
- enum drm_mm_insert_mode mode)
+struct drm_mm_node *
+__drm_mm_next_hole(struct drm_mm *mm,
+ struct drm_mm_node *node,
+ u64 size,
+ enum drm_mm_insert_mode mode)
{
switch (mode) {
default:
@@ -432,6 +433,7 @@ next_hole(struct drm_mm *mm,
return >hole_stack == >hole_stack ? NULL : node;
}
}
+EXPORT_SYMBOL(__drm_mm_next_hole);
/**
* drm_mm_reserve_node - insert an pre-initialized node
@@ -516,11 +518,11 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
u64 size, u64 alignment,
unsigned long color,
u64 range_start, u64 range_end,
- enum drm_mm_insert_mode mode)
+ enum drm_mm_insert_mode caller_mode)
{
struct drm_mm_node *hole;
u64 remainder_mask;
- bool once;
+ enum drm_mm_insert_mode mode = caller_mode & ~DRM_MM_INSERT_ONCE;
DRM_MM_BUG_ON(range_start > range_end);
@@ -533,13 +535,9 @@ int drm_mm_insert_node_in_range(struct drm_mm * const mm,
if (alignment <= 1)
alignment = 0;
- once = mode & DRM_MM_INSERT_ONCE;
- mode &= ~DRM_MM_INSERT_ONCE;
-
remainder_mask = is_power_of_2(alignment) ? alignment - 1 : 0;
- for (hole = first_hole(mm, range_start, range_end, size, mode);
-hole;
-hole = once ? NULL : next_hole(mm, hole, size, mode)) {
+ drm_mm_for_each_suitable_hole(hole, mm, range_start, range_end,
+ size, mode) {
u64 hole_start = __drm_mm_hole_node_start(hole);
u64 hole_end = hole_start + hole->hole_size;
u64 adj_start, adj_end;
diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
index ac33ba1b18bc..dff6db627807 100644
--- a/include/drm/drm_mm.h
+++ b/include/drm/drm_mm.h
@@ -400,6 +400,42 @@ static inline u64 drm_mm_hole_node_end(const struct
drm_mm_node *hole_node)
1 : 0; \
pos = list_next_entry(pos, hole_stack))
+struct drm_mm_node *
+__drm_mm_first_hole(struct drm_mm *mm,
+ u64 start, u64 end, u64 size,
+ enum drm_mm_insert_mode mode);
+
+struct drm_mm_node *
+__drm_mm_next_hole(struct drm_mm *mm,
+ struct drm_mm_node *node,
+ u64 size,
+ enum drm_mm_insert_mode mode);
+
+/**
+ * drm_mm_for_each_suitable_hole - iterator to optimally walk over all
+ * holes that can fit an allocation of the given @size.
+ * @pos: _mm_node used internally to track progress
+ * @mm: _mm allocator to walk
+
[CI 0/2] drm/mm: Add an iterator to optimally walk over holes suitable for an allocation
The first patch is a drm core patch that replaces the for loop in drm_mm_insert_node_in_range() with the iterator and would not cause any functional changes. The second patch is a i915 driver specific patch that also uses the iterator but solves a different problem. v2: - Added a new patch to this series to fix a potential NULL dereference. - Fixed a typo associated with the iterator introduced in the drm core patch. - Added locking around the snippet in the i915 patch that traverses the GGTT hole nodes. v3: (Tvrtko) - Replaced mutex_lock with mutex_lock_interruptible_nested() in the i915 patch. v4: (Tvrtko) - Dropped the patch added in v2 as it was deemed unnecessary. Cc: Tvrtko Ursulin Cc: Nirmoy Das Cc: Christian König Vivek Kasireddy (2): drm/mm: Add an iterator to optimally walk over holes for an allocation (v4) drm/i915/gem: Don't try to map and fence large scanout buffers (v9) drivers/gpu/drm/drm_mm.c| 32 drivers/gpu/drm/i915/i915_gem.c | 128 +++- include/drm/drm_mm.h| 36 + 3 files changed, 145 insertions(+), 51 deletions(-) -- 2.34.1
Re: [PATCH 15/15] drm/i915/gt: Clear compress metadata for Xe_HP platforms
Matt,
Thanks for the review.
On 2022-02-18 at 17:47:22 -0800, Matt Roper wrote:
> On Sat, Feb 19, 2022 at 12:17:52AM +0530, Ramalingam C wrote:
> > From: Ayaz A Siddiqui
> >
> > Xe-HP and latest devices support Flat CCS which reserved a portion of
> > the device memory to store compression metadata, during the clearing of
> > device memory buffer object we also need to clear the associated
> > CCS buffer.
> >
> > Flat CCS memory can not be directly accessed by S/W.
> > Address of CCS buffer associated main BO is automatically calculated
> > by device itself. KMD/UMD can only access this buffer indirectly using
> > XY_CTRL_SURF_COPY_BLT cmd via the address of device memory buffer.
> >
> > v2: Fixed issues with platform naming [Lucas]
> > v3: Rebased [Ram]
> > Used the round_up funcs [Bob]
> > v4: Fixed ccs blk calculation [Ram]
> > Added Kdoc on flat-ccs.
> >
> > Cc: CQ Tang
> > Signed-off-by: Ayaz A Siddiqui
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 15 ++
> > drivers/gpu/drm/i915/gt/intel_migrate.c | 145 ++-
> > 2 files changed, 156 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> > b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> > index f8253012d166..166de5436c4a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
> > @@ -203,6 +203,21 @@
> > #define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
> > #define GFX_OP_DRAWRECT_INFO_I965 ((0x7900<<16)|0x2)
> >
> > +#define XY_CTRL_SURF_INSTR_SIZE5
> > +#define MI_FLUSH_DW_SIZE 3
> > +#define XY_CTRL_SURF_COPY_BLT ((2 << 29) | (0x48 << 22) | 3)
> > +#define SRC_ACCESS_TYPE_SHIFT21
> > +#define DST_ACCESS_TYPE_SHIFT20
> > +#define CCS_SIZE_SHIFT 8
>
> Rather than using a shift, it might be better to just define the
> bitfield. E.g.,
>
> #define CCS_SIZEGENMASK(17, 8)
>
> and then later
>
> FIELD_PREP(CCS_SIZE, i - 1)
>
> to refer to the proper value.
>
> > +#define XY_CTRL_SURF_MOCS_SHIFT 25
>
> Same here; we can use GENMASK(31, 25) to define the field.
Adapting to the GENMASK and FIELD_PREP for these two macros
>
> > +#define NUM_CCS_BYTES_PER_BLOCK 256
> > +#define NUM_BYTES_PER_CCS_BYTE 256
> > +#define NUM_CCS_BLKS_PER_XFER1024
> > +#define INDIRECT_ACCESS 0
> > +#define DIRECT_ACCESS1
> > +#define MI_FLUSH_LLC BIT(9)
> > +#define MI_FLUSH_CCS BIT(16)
> > +
> > #define COLOR_BLT_CMD (2 << 29 | 0x40 << 22 | (5 - 2))
> > #define XY_COLOR_BLT_CMD (2 << 29 | 0x50 << 22)
> > #define SRC_COPY_BLT_CMD (2 << 29 | 0x43 << 22)
> > diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > index 20444d6ceb3c..9f9cd2649377 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > @@ -16,6 +16,8 @@ struct insert_pte_data {
> > };
> >
> > #define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
> > +#define GET_CCS_BYTES(i915, size) (HAS_FLAT_CCS(i915) ? \
> > +DIV_ROUND_UP(size,
> > NUM_BYTES_PER_CCS_BYTE) : 0)
> >
> > static bool engine_supports_migration(struct intel_engine_cs *engine)
> > {
> > @@ -467,6 +469,113 @@ static bool wa_1209644611_applies(int ver, u32 size)
> > return height % 4 == 3 && height <= 8;
> > }
> >
> > +/**
> > + * DOC: Flat-CCS - Memory compression for Local memory
> > + *
> > + * On Xe-HP and later devices, we use dedicated compression control state
> > (CCS)
> > + * stored in local memory for each surface, to support the 3D and media
> > + * compression formats.
> > + *
> > + * The memory required for the CCS of the entire local memory is 1/256 of
> > the
> > + * local memory size. So before the kernel boot, the required memory is
> > reserved
> > + * for the CCS data and a secure register will be programmed with the CCS
> > base
> > + * address.
> > + *
> > + * Flat CCS data needs to be cleared when a lmem object is allocated.
> > + * And CCS data can be copied in and out of CCS region through
> > + * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
> > + *
> > + * When we exaust the lmem, if the object's placements support smem, then
> > we can
>
> Typo: exhaust
>
> > + * directly decompress the compressed lmem object into smem and start
> > using it
> > + * from smem itself.
> > + *
> > + * But when we need to swapout the compressed lmem object into a smem
> > region
> > + * though objects' placement doesn't support smem, then we copy the lmem
> > content
> > + * as it is into smem region along with ccs data (using
> > XY_CTRL_SURF_COPY_BLT).
> > + * When the object is referred, lmem content
[PATCH v2] drm/amdgpu: Fix realloc of ptr
From: Tom Rix
Clang static analysis reports this error
amdgpu_debugfs.c:1690:9: warning: 1st function call
argument is an uninitialized value
tmp = krealloc_array(tmp, i + 1,
^~~
realloc uses tmp, so tmp can not be garbage.
And the return needs to be checked.
Fixes: 5ce5a584cb82 ("drm/amdgpu: add debugfs for reset registers list")
Signed-off-by: Tom Rix
---
v2:
use 'new' to hold/check the ralloc return
fix commit log mistake on ralloc freeing to using input ptr
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 9eb9b440bd438..2f4f8c5618d81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1676,7 +1676,7 @@ static ssize_t
amdgpu_reset_dump_register_list_write(struct file *f,
{
struct amdgpu_device *adev = (struct amdgpu_device
*)file_inode(f)->i_private;
char reg_offset[11];
- uint32_t *tmp;
+ uint32_t *new, *tmp = NULL;
int ret, i = 0, len = 0;
do {
@@ -1687,7 +1687,12 @@ static ssize_t
amdgpu_reset_dump_register_list_write(struct file *f,
goto error_free;
}
- tmp = krealloc_array(tmp, i + 1, sizeof(uint32_t), GFP_KERNEL);
+ new = krealloc_array(tmp, i + 1, sizeof(uint32_t), GFP_KERNEL);
+ if (!new) {
+ ret = -ENOMEM;
+ goto error_free;
+ }
+ tmp = new;
if (sscanf(reg_offset, "%X %n", [i], ) != 1) {
ret = -EINVAL;
goto error_free;
--
2.26.3
RE: [PATCH 2/3] drm/edid: read HF-EEODB ext block
On Saturday, February 26, 2022 2:09 AM, Ville Syrjälä wrote:
>On Thu, Feb 24, 2022 at 10:16:24PM +0800, Lee Shawn C wrote:
>> Support to read HF_EEODB block that request by HDMI 2.1 specification.
>
>Please spell out what that thing is and why it exists.
>
>>
>> Cc: Jani Nikula
>> Cc: Ville Syrjala
>> Cc: Ankit Nautiyal
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/drm_connector.c | 5 ++-
>> drivers/gpu/drm/drm_edid.c | 76 ++---
>> include/drm/drm_edid.h | 2 +
>> 3 files changed, 77 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index a50c82bc2b2f..0f9e3ef00be7
>> 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -2137,8 +2137,11 @@ int drm_connector_update_edid_property(struct
>> drm_connector *connector,
>> if (connector->override_edid)
>> return 0;
>>
>> -if (edid)
>> +if (edid) {
>> size = EDID_LENGTH * (1 + edid->extensions);
>> +if (drm_edid_is_hf_eeodb_blk_available(edid))
>> +size = EDID_LENGTH * (1 +
>> drm_edid_read_hf_eeodb_blk_size(edid));
>
>I think we just want a small helper function that gives us the number of ext
>blocks whether it be from the base block or from this thing.
>
>> +}
>>
>> /* Set the display info, using edid if available, otherwise
>> * resetting the values to defaults. This duplicates the work diff
>> --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
>> 19426f28b411..056e735ef932 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1991,7 +1991,7 @@ struct edid *drm_do_get_edid(struct drm_connector
>> *connector,
>> void *data)
>> {
>> int i, j = 0, valid_extensions = 0;
>> -u8 *edid, *new;
>> +u8 *edid, *new, ext_eeodb_blk_size;
>> struct edid *override;
>>
>> override = drm_get_override_edid(connector); @@ -2051,7 +2051,40 @@
>> struct edid *drm_do_get_edid(struct drm_connector *connector,
>> }
>>
>> kfree(edid);
>> +return (struct edid *)new;
>> +}
>> +
>> +if (drm_edid_is_hf_eeodb_blk_available((struct edid *)edid)) {
>> +ext_eeodb_blk_size = drm_edid_read_hf_eeodb_blk_size((struct
>> edid
>> +*)edid);
>> +
>> +// no more ext blk wait for read
>> +if (ext_eeodb_blk_size <= 1)
>> +return (struct edid *)edid;
>> +
>> +new = krealloc(edid, (ext_eeodb_blk_size + 1) * EDID_LENGTH,
>> GFP_KERNEL);
>> +if (!new)
>> +goto out;
>> edid = new;
>> +
>> +valid_extensions = ext_eeodb_blk_size - 1;
>> +for (j = 2; j <= ext_eeodb_blk_size; j++) {
>> +u8 *block = edid + j * EDID_LENGTH;
>> +
>> +for (i = 0; i < 4; i++) {
>> +if (get_edid_block(data, block, j, EDID_LENGTH))
>> +goto out;
>> +if (drm_edid_block_valid(block, j, false, NULL))
>> +break;
>> +}
>> +
>> +if (i == 4)
>> +valid_extensions--;
>> +}
>> +
>> +if (valid_extensions != ext_eeodb_blk_size - 1) {
>> +DRM_ERROR("Not able to retrieve proper EDID contain
>> HF-EEODB data.\n");
>> +goto out;
>> +}
>> }
>>
>> return (struct edid *)edid;
>> @@ -3315,15 +3348,17 @@ add_detailed_modes(struct drm_connector *connector,
>> struct edid *edid,
>> #define VIDEO_BLOCK 0x02
>> #define VENDOR_BLOCK0x03
>> #define SPEAKER_BLOCK 0x04
>> -#define HDR_STATIC_METADATA_BLOCK 0x6
>> -#define USE_EXTENDED_TAG 0x07
>> -#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>> +#define EXT_VIDEO_CAPABILITY_BLOCK 0x00
>> +#define HDR_STATIC_METADATA_BLOCK 0x06
>> +#define USE_EXTENDED_TAG0x07
>> #define EXT_VIDEO_DATA_BLOCK_4200x0E
>> -#define EXT_VIDEO_CAP_BLOCK_Y420CMDB 0x0F
>> +#define EXT_VIDEO_CAP_BLOCK_Y420CMDB0x0F
>> +#define EXT_VIDEO_HF_EEODB_DATA_BLOCK 0x78
>> #define EDID_BASIC_AUDIO(1 << 6)
>> #define EDID_CEA_YCRCB444 (1 << 5)
>> #define EDID_CEA_YCRCB422 (1 << 4)
>> #define EDID_CEA_VCDB_QS(1 << 6)
>> +#define HF_EEODB_LENGTH 2
>>
>> /*
>> * Search EDID for CEA extension block.
>> @@ -4273,6 +4308,37 @@ static bool cea_db_is_y420vdb(const u8 *db)
>> return true;
>> }
>>
>> +static bool cea_db_is_hdmi_forum_eeodb(const u8 *db) {
>> +if (cea_db_tag(db) != USE_EXTENDED_TAG)
>> +return false;
>> +
>> +if (cea_db_payload_len(db) != HF_EEODB_LENGTH)
>
>We don't have any defines for the length of other blocks. Don't see why this
>one should be different.
>
>Also, the spec says
RE: [PATCH 1/3] drm/edid: parse multiple CEA extension block
On Saturday, February 26, 2022 1:47 AM, Ville Syrjälä wrote:
>On Thu, Feb 24, 2022 at 10:16:23PM +0800, Lee Shawn C wrote:
>> Try to find and parse more CEA ext blocks if edid->extensions is
>> greater than one.
>>
>> Cc: Jani Nikula
>> Cc: Ville Syrjala
>> Cc: Ankit Nautiyal
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/drm_edid.c | 110
>> -
>> 1 file changed, 60 insertions(+), 50 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index a504542238ed..19426f28b411 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -3353,16 +3353,14 @@ const u8 *drm_find_edid_extension(const struct edid
>> *edid,
>> return edid_ext;
>> }
>>
>> -static const u8 *drm_find_cea_extension(const struct edid *edid)
>> +static const u8 *drm_find_cea_extension(const struct edid *edid, int
>> +*ext_index)
>> {
>> const struct displayid_block *block;
>> struct displayid_iter iter;
>> const u8 *cea;
>> -int ext_index = 0;
>>
>> -/* Look for a top level CEA extension block */
>> -/* FIXME: make callers iterate through multiple CEA ext blocks? */
>> -cea = drm_find_edid_extension(edid, CEA_EXT, _index);
>> +/* Look for a CEA extension block from ext_index */
>> +cea = drm_find_edid_extension(edid, CEA_EXT, ext_index);
>> if (cea)
>> return cea;
>>
>> @@ -3643,10 +3641,10 @@ add_alternate_cea_modes(struct drm_connector
>> *connector, struct edid *edid)
>> struct drm_device *dev = connector->dev;
>> struct drm_display_mode *mode, *tmp;
>> LIST_HEAD(list);
>> -int modes = 0;
>> +int modes = 0, ext_index = 0;
>>
>> /* Don't add CEA modes if the CEA extension block is missing */
>> -if (!drm_find_cea_extension(edid))
>> +if (!drm_find_cea_extension(edid, _index))
>> return 0;
>>
>> /*
>> @@ -4321,46 +4319,58 @@ static void drm_parse_y420cmdb_bitmap(struct
>> drm_connector *connector, static int add_cea_modes(struct
>> drm_connector *connector, struct edid *edid) {
>> -const u8 *cea = drm_find_cea_extension(edid);
>> +const u8 *cea = NULL;
>> const u8 *db, *hdmi = NULL, *video = NULL;
>> u8 dbl, hdmi_len, video_len = 0;
>> -int modes = 0;
>> +int modes = 0, ext_index = 0;
>>
>> -if (cea && cea_revision(cea) >= 3) {
>> -int i, start, end;
>> +for (;;) {
>> +cea = drm_find_cea_extension(edid, _index);
>
>Please split this into two patches:
>1. do the *ext_index stuff
>2. do the loop
>
Thanks for comment! Will split this patch to two in next version.
>>
>> -if (cea_db_offsets(cea, , ))
>> -return 0;
>> +if (!cea)
>> +break;
>>
>> -for_each_cea_db(cea, i, start, end) {
>> -db = [i];
>> -dbl = cea_db_payload_len(db);
>> +if (cea && cea_revision(cea) >= 3) {
>> +int i, start, end;
>> +
>> +if (cea_db_offsets(cea, , ))
>> +continue;
>>
>> -if (cea_db_tag(db) == VIDEO_BLOCK) {
>> -video = db + 1;
>> -video_len = dbl;
>> -modes += do_cea_modes(connector, video, dbl);
>> -} else if (cea_db_is_hdmi_vsdb(db)) {
>> -hdmi = db;
>> -hdmi_len = dbl;
>> -} else if (cea_db_is_y420vdb(db)) {
>> -const u8 *vdb420 = [2];
>> -
>> -/* Add 4:2:0(only) modes present in EDID */
>> -modes += do_y420vdb_modes(connector,
>> - vdb420,
>> - dbl - 1);
>> +for_each_cea_db(cea, i, start, end) {
>> +db = [i];
>> +dbl = cea_db_payload_len(db);
>> +
>> +if (cea_db_tag(db) == VIDEO_BLOCK) {
>> +video = db + 1;
>> +video_len = dbl;
>> +modes += do_cea_modes(connector, video,
>> dbl);
>> +} else if (cea_db_is_hdmi_vsdb(db)) {
>> +hdmi = db;
>> +hdmi_len = dbl;
>> +} else if (cea_db_is_y420vdb(db)) {
>> +const u8 *vdb420 = [2];
>> +
>> +/* Add 4:2:0(only) modes present in
>> EDID */
>> +modes += do_y420vdb_modes(connector,
>> + vdb420,
>> +
Re: [PATCH] drm/amdgpu: Fix realloc of ptr
On 2/26/22 2:21 PM, David Laight wrote:
From: t...@redhat.com
Sent: 26 February 2022 15:59
From: Tom Rix
Clang static analysis reports this error
amdgpu_debugfs.c:1690:9: warning: 1st function call
argument is an uninitialized value
tmp = krealloc_array(tmp, i + 1,
^~~
realloc will free tmp, so tmp can not be garbage.
And the return needs to be checked.
Are you sure?
A quick check seems to show that krealloc() behaves the same
way as libc realloc() and the pointer isn't freed on failure.
I suck, I'll respin the patch
Thanks
Tom
David
Fixes: 5ce5a584cb82 ("drm/amdgpu: add debugfs for reset registers list")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 9eb9b440bd438..159b97c0b4ebc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1676,7 +1676,7 @@ static ssize_t
amdgpu_reset_dump_register_list_write(struct file *f,
{
struct amdgpu_device *adev = (struct amdgpu_device
*)file_inode(f)->i_private;
char reg_offset[11];
- uint32_t *tmp;
+ uint32_t *tmp = NULL;
int ret, i = 0, len = 0;
do {
@@ -1688,6 +1688,10 @@ static ssize_t
amdgpu_reset_dump_register_list_write(struct file *f,
}
tmp = krealloc_array(tmp, i + 1, sizeof(uint32_t), GFP_KERNEL);
+ if (!tmp) {
+ ret = -ENOMEM;
+ goto error_free;
+ }
if (sscanf(reg_offset, "%X %n", [i], ) != 1) {
ret = -EINVAL;
goto error_free;
--
2.26.3
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH v4 7/9] drm: vkms: Refactor the plane composer to accept new formats
Hi Pekka,
On 2/25/22 05:38, Pekka Paalanen wrote:
> On Thu, 24 Feb 2022 21:43:01 -0300
> Igor Torrente wrote:
>
>> Hi Pekka,
>>
>> On 2/10/22 06:37, Pekka Paalanen wrote:
>>> On Fri, 21 Jan 2022 18:38:29 -0300
>>> Igor Torrente wrote:
>>>
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
possible inputs. It consists of 16 bits fields that represent each of
the channels.
The pixels blend is done using this internal format. And new handlers
are being added to convert a specific format to/from this internal format.
So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.
This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).
These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.
| Memory consumption (output dimensions) |
|:--:|
| Current | This patch|
|:--:|:-:|
| Width * Heigth | 2 * Width |
Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT tests `*kms_cursor_crc*`:
| Frametime |
|:--:|
| Implementation | Current | This commit |
|:---:|:-:|::|
| frametime range | 8~22 ms |5~18 ms |
| Average | 10.0 ms |7.3 ms|
Reported-by: kernel test robot
Signed-off-by: Igor Torrente
---
V2: Improves the performance drastically, by perfoming the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
---
drivers/gpu/drm/vkms/Makefile| 1 +
drivers/gpu/drm/vkms/vkms_composer.c | 335 +--
drivers/gpu/drm/vkms/vkms_formats.c | 138 +++
drivers/gpu/drm/vkms/vkms_formats.h | 31 +++
4 files changed, 333 insertions(+), 172 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
>>>
>>> Hi Igor,
>>>
>>> I'm really happy to see this, thanks!
>>>
>>> I still have some security/robustness and other comments below.
>>>
>>> I've deleted all the minus lines from the patch to make the new code
>>> more clear.
>>>
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 72f779cbfedd..1b28a6a32948 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -3,6 +3,7 @@ vkms-y := \
vkms_drv.o \
vkms_plane.o \
vkms_output.o \
+vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 95029d2ebcac..9f70fcf84fb9 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -9,202 +9,210 @@
#include
#include "vkms_drv.h"
+#include "vkms_formats.h"
+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
+u32 new_color;
+new_color = (src * 0x + dst * (0x - alpha));
+return DIV_ROUND_UP(new_color, 0x);
>>>
>>> Why round-up rather than the usual mathematical rounding?
>>
>> AFAIK, this is the only round that's present in the kernel. And if I
>> understood correctly it is the round toward positive infinity that we are
>> all used to use.
>
> Should be pretty easy to round-up from 0.5 and round-down otherwise.
> Just add a different offset than DIV_ROUND_UP does.
>
> Not having a ready-made macro and habits are not good
> justifications. The justification needs to be mathematical.
Re: [PATCH v6 1/4] drm/i915/guc: Add fetch of hwconfig table
Hi Jordan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.17-rc5 next-20220225]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jordan-Justen/GuC-HWCONFIG-with-documentation/20220227-161945
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-a011
(https://download.01.org/0day-ci/archive/20220227/202202272041.kr2qxfem-...@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
#
https://github.com/0day-ci/linux/commit/7a92eba9714ffe68202fee73b9916d35b0da2968
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jordan-Justen/GuC-HWCONFIG-with-documentation/20220227-161945
git checkout 7a92eba9714ffe68202fee73b9916d35b0da2968
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:110: warning: Function
parameter or member 'gt' not described in 'guc_hwconfig_init'
>> drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:110: warning: expecting
>> prototype for intel_guc_hwconfig_init(). Prototype was for
>> guc_hwconfig_init() instead
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:143: warning: Function
parameter or member 'gt' not described in 'intel_gt_init_hwconfig'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:156: warning: Function
parameter or member 'gt' not described in 'intel_gt_fini_hwconfig'
vim +110 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
102
103 /**
104 * intel_guc_hwconfig_init - Initialize the HWConfig
105 *
106 * Retrieve the HWConfig table from the GuC and save it locally.
107 * It can then be queried on demand by other users later on.
108 */
109 static int guc_hwconfig_init(struct intel_gt *gt)
> 110 {
111 struct intel_hwconfig *hwconfig = >info.hwconfig;
112 struct intel_guc *guc = >uc.guc;
113 int ret;
114
115 if (!has_table(gt->i915))
116 return 0;
117
118 ret = guc_hwconfig_discover_size(guc, hwconfig);
119 if (ret)
120 return ret;
121
122 hwconfig->ptr = kmalloc(hwconfig->size, GFP_KERNEL);
123 if (!hwconfig->ptr) {
124 hwconfig->size = 0;
125 return -ENOMEM;
126 }
127
128 ret = guc_hwconfig_fill_buffer(guc, hwconfig);
129 if (ret < 0) {
130 intel_gt_fini_hwconfig(gt);
131 return ret;
132 }
133
134 return 0;
135 }
136
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v6 4/5] drm/mipi-dbi: Add driver_private member to struct mipi_dbi_dev
devm_drm_dev_alloc() can't allocate structures that embed a structure
which then again embeds drm_device. Workaround this by adding a
driver_private pointer to struct mipi_dbi_dev which the driver can use for
its additional state.
v3:
- Add documentation
Acked-by: Maxime Ripard
Acked-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
include/drm/drm_mipi_dbi.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_mipi_dbi.h b/include/drm/drm_mipi_dbi.h
index 6fe13cce2670..dad2f187b64b 100644
--- a/include/drm/drm_mipi_dbi.h
+++ b/include/drm/drm_mipi_dbi.h
@@ -130,6 +130,14 @@ struct mipi_dbi_dev {
* @dbi: MIPI DBI interface
*/
struct mipi_dbi dbi;
+
+ /**
+* @driver_private: Driver private data.
+* Necessary for drivers with private data since
devm_drm_dev_alloc()
+* can't allocate structures that embed a structure
which then again
+* embeds drm_device.
+*/
+ void *driver_private;
};
static inline struct mipi_dbi_dev *drm_to_mipi_dbi_dev(struct drm_device *drm)
--
2.33.0
[PATCH v6 1/5] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels
Add binding for MIPI DBI compatible SPI panels.
v6:
- Fix indentation (Rob)
v5:
- Add sainsmart18 to compatible items (Rob)
- Expand write-only description (Sam)
v4:
- There should only be two compatible (Maxime)
- s/panel-dbi-spi/panel-mipi-dbi-spi/in compatible
v3:
- Move properties to Device Tree (Maxime)
- Use contains for compatible (Maxime)
- Add backlight property to example
- Flesh out description
v2:
- Fix path for panel-common.yaml
- Use unevaluatedProperties
- Drop properties which are in the allOf section
- Drop model property (Rob)
Acked-by: Maxime Ripard
Acked-by: Sam Ravnborg
Reviewed-by: Rob Herring
Signed-off-by: Noralf Trønnes
---
.../display/panel/panel-mipi-dbi-spi.yaml | 126 ++
1 file changed, 126 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
diff --git
a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
new file mode 100644
index ..f29789994b18
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
@@ -0,0 +1,126 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI DBI SPI Panel
+
+maintainers:
+ - Noralf Trønnes
+
+description: |
+ This binding is for display panels using a MIPI DBI compatible controller
+ in SPI mode.
+
+ The MIPI Alliance Standard for Display Bus Interface defines the electrical
+ and logical interfaces for display controllers historically used in mobile
+ phones. The standard defines 4 display architecture types and this binding is
+ for type 1 which has full frame memory. There are 3 interface types in the
+ standard and type C is the serial interface.
+
+ The standard defines the following interface signals for type C:
+ - Power:
+- Vdd: Power supply for display module
+- Vddi: Logic level supply for interface signals
+Combined into one in this binding called: power-supply
+ - Interface:
+- CSx: Chip select
+- SCL: Serial clock
+- Dout: Serial out
+- Din: Serial in
+- SDA: Bidrectional in/out
+- D/CX: Data/command selection, high=data, low=command
+ Called dc-gpios in this binding.
+- RESX: Reset when low
+ Called reset-gpios in this binding.
+
+ The type C interface has 3 options:
+
+- Option 1: 9-bit mode and D/CX as the 9th bit
+ | Command | the next command or following
data |
+
|<0>||
+
+- Option 2: 16-bit mode and D/CX as a 9th bit
+ | Command or data |
+ ||
+
+- Option 3: 8-bit mode and D/CX as a separate interface line
+ |Command or data |
+ ||
+
+ The panel resolution is specified using the panel-timing node properties
+ hactive (width) and vactive (height). The other mandatory panel-timing
+ properties should be set to zero except clock-frequency which can be
+ optionally set to inform about the actual pixel clock frequency.
+
+ If the panel is wired to the controller at an offset specify this using
+ hback-porch (x-offset) and vback-porch (y-offset).
+
+allOf:
+ - $ref: panel-common.yaml#
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+properties:
+ compatible:
+items:
+ - enum:
+ - sainsmart18
+ - const: panel-mipi-dbi-spi
+
+ write-only:
+type: boolean
+description:
+ Controller is not readable (ie. Din (MISO on the SPI interface) is not
+ wired up).
+
+ dc-gpios:
+maxItems: 1
+description: |
+ Controller data/command selection (D/CX) in 4-line SPI mode.
+ If not set, the controller is in 3-line SPI mode.
+
+required:
+ - compatible
+ - reg
+ - panel-timing
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+spi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+display@0{
+compatible = "sainsmart18", "panel-mipi-dbi-spi";
+reg = <0>;
+spi-max-frequency = <4000>;
+
+dc-gpios = < 24 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 25 GPIO_ACTIVE_HIGH>;
+write-only;
+
+backlight = <>;
+
+width-mm = <35>;
+height-mm = <28>;
+
+panel-timing {
+hactive = <160>;
+vactive = <128>;
+hback-porch = <0>;
+vback-porch = <0>;
+clock-frequency = <0>;
+hfront-porch = <0>;
+hsync-len = <0>;
+vfront-porch = <0>;
+vsync-len = <0>;
+};
+};
+};
+
+...
--
2.33.0
[PATCH v6 5/5] drm/tiny: Add MIPI DBI compatible SPI driver
Add a driver that will work with most MIPI DBI compatible SPI panels.
This avoids adding a driver for every new MIPI DBI compatible controller
that is to be used by Linux. The 'compatible' Device Tree property with
a '.bin' suffix will be used to load a firmware file that contains the
controller configuration.
Example (driver will load sainsmart18.bin):
display@0 {
compatible = "sainsmart18", "panel-mipi-dbi-spi";
...
};
v5:
- kconfig: s/DRM_KMS_CMA_HELPER/DRM_GEM_CMA_HELPER/ (Sam)
- kconfig: Add select VIDEOMODE_HELPERS (Sam)
- kconfig: Add wiki url in the description (Sam)
- Split out and use of_get_drm_panel_display_mode()(Sam)
- Only use the first compatible to look for a firmware file since the
binding mandates 2 compatibles.
- Make having a firmware file mandatory so we can print an error
message if it's missing to improve the user experience. It's very
unlikely that a controller doesn't need to be initialized and if
it doesn't, it's possible to have a firmware file containing only
a DCS NOP.
v4:
- Move driver to drm/tiny where the other drivers of its kind are located.
The driver module will not be shared with a future DPI driver after all.
v3:
- Move properties to DT (Maxime)
- The MIPI DPI spec has optional support for DPI where the controller is
configured over DBI. Rework the command functions so they can be moved
to drm_mipi_dbi and shared with a future panel-mipi-dpi-spi driver
v2:
- Drop model property and use compatible instead (Rob)
- Add wiki entry in MAINTAINERS
Acked-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
MAINTAINERS | 8 +
drivers/gpu/drm/tiny/Kconfig | 15 +
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/panel-mipi-dbi.c | 398 ++
4 files changed, 422 insertions(+)
create mode 100644 drivers/gpu/drm/tiny/panel-mipi-dbi.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e6e892f99f0..3a0e57f23ad0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6107,6 +6107,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc
F: Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt
F: drivers/gpu/drm/tiny/mi0283qt.c
+DRM DRIVER FOR MIPI DBI compatible panels
+M: Noralf Trønnes
+S: Maintained
+W: https://github.com/notro/panel-mipi-dbi/wiki
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
+F: drivers/gpu/drm/tiny/panel-mipi-dbi.c
+
DRM DRIVER FOR MSM ADRENO GPU
M: Rob Clark
M: Sean Paul
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 712e0004e96e..627d637a1e7e 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -51,6 +51,21 @@ config DRM_GM12U320
This is a KMS driver for projectors which use the GM12U320 chipset
for video transfer over USB2/3, such as the Acer C120 mini projector.
+config DRM_PANEL_MIPI_DBI
+ tristate "DRM support for MIPI DBI compatible panels"
+ depends on DRM && SPI
+ select DRM_KMS_HELPER
+ select DRM_GEM_CMA_HELPER
+ select DRM_MIPI_DBI
+ select BACKLIGHT_CLASS_DEVICE
+ select VIDEOMODE_HELPERS
+ help
+ Say Y here if you want to enable support for MIPI DBI compatible
+ panels. The controller command setup can be provided using a
+ firmware file. For more information see
+ https://github.com/notro/panel-mipi-dbi/wiki.
+ To compile this driver as a module, choose M here.
+
config DRM_SIMPLEDRM
tristate "Simple framebuffer driver"
depends on DRM && MMU
diff --git a/drivers/gpu/drm/tiny/Makefile b/drivers/gpu/drm/tiny/Makefile
index 5d5505d40e7b..1d9d6227e7ab 100644
--- a/drivers/gpu/drm/tiny/Makefile
+++ b/drivers/gpu/drm/tiny/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ARCPGU)+= arcpgu.o
obj-$(CONFIG_DRM_BOCHS)+= bochs.o
obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus.o
obj-$(CONFIG_DRM_GM12U320) += gm12u320.o
+obj-$(CONFIG_DRM_PANEL_MIPI_DBI) += panel-mipi-dbi.o
obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
obj-$(CONFIG_TINYDRM_HX8357D) += hx8357d.o
obj-$(CONFIG_TINYDRM_ILI9163) += ili9163.o
diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c
b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
new file mode 100644
index ..7f8c6c51387f
--- /dev/null
+++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * DRM driver for MIPI DBI compatible display panels
+ *
+ * Copyright 2022 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static const u8 panel_mipi_dbi_magic[15] = { 'M', 'I', 'P', 'I', ' ',
[PATCH v6 3/5] drm/modes: Add of_get_drm_panel_display_mode()
Add a function to get a drm_display_mode from a panel-timing
device tree subnode.
Suggested-by: Sam Ravnborg
Reviewed-by: Sam Ravnborg
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_modes.c | 49 +
include/drm/drm_modes.h | 8 ++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 77a4c8dd0bb8..3f819c7a021b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -35,6 +35,7 @@
#include
#include
+#include
#include
#include
@@ -727,6 +728,54 @@ int of_get_drm_display_mode(struct device_node *np,
return 0;
}
EXPORT_SYMBOL_GPL(of_get_drm_display_mode);
+
+/**
+ * of_get_drm_panel_display_mode - get a panel-timing drm_display_mode from
devicetree
+ * @np: device_node with the panel-timing specification
+ * @dmode: will be set to the return value
+ * @bus_flags: information about pixelclk, sync and DE polarity
+ *
+ * The Device Tree properties width-mm and height-mm will be read and set on
+ * the display mode if they are present.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int of_get_drm_panel_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, u32
*bus_flags)
+{
+ u32 width_mm = 0, height_mm = 0;
+ struct display_timing timing;
+ struct videomode vm;
+ int ret;
+
+ ret = of_get_display_timing(np, "panel-timing", );
+ if (ret)
+ return ret;
+
+ videomode_from_timing(, );
+
+ memset(dmode, 0, sizeof(*dmode));
+ drm_display_mode_from_videomode(, dmode);
+ if (bus_flags)
+ drm_bus_flags_from_videomode(, bus_flags);
+
+ ret = of_property_read_u32(np, "width-mm", _mm);
+ if (ret && ret != -EINVAL)
+ return ret;
+
+ ret = of_property_read_u32(np, "height-mm", _mm);
+ if (ret && ret != -EINVAL)
+ return ret;
+
+ dmode->width_mm = width_mm;
+ dmode->height_mm = height_mm;
+
+ drm_mode_debug_printmodeline(dmode);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_drm_panel_display_mode);
#endif /* CONFIG_OF */
#endif /* CONFIG_VIDEOMODE_HELPERS */
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 29ba4adf0c53..2fa6b2c33b3f 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -466,6 +466,8 @@ void drm_bus_flags_from_videomode(const struct videomode
*vm, u32 *bus_flags);
int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode, u32 *bus_flags,
int index);
+int of_get_drm_panel_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode, u32
*bus_flags);
#else
static inline int of_get_drm_display_mode(struct device_node *np,
struct drm_display_mode *dmode,
@@ -473,6 +475,12 @@ static inline int of_get_drm_display_mode(struct
device_node *np,
{
return -EINVAL;
}
+
+static inline int of_get_drm_panel_display_mode(struct device_node *np,
+ struct drm_display_mode *dmode,
u32 *bus_flags)
+{
+ return -EINVAL;
+}
#endif
void drm_mode_set_name(struct drm_display_mode *mode);
--
2.33.0
[PATCH v6 2/5] drm/modes: Remove trailing whitespace
Remove trailing whitespace from a comment. Acked-by: Sam Ravnborg Signed-off-by: Noralf Trønnes --- drivers/gpu/drm/drm_modes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 96b13e36293c..77a4c8dd0bb8 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -127,7 +127,7 @@ EXPORT_SYMBOL(drm_mode_probed_add); * according to the hdisplay, vdisplay, vrefresh. * It is based from the VESA(TM) Coordinated Video Timing Generator by * Graham Loveridge April 9, 2003 available at - * http://www.elo.utfsm.cl/~elo212/docs/CVTd6r1.xls + * http://www.elo.utfsm.cl/~elo212/docs/CVTd6r1.xls * * And it is copied from xf86CVTmode in xserver/hw/xfree86/modes/xf86cvt.c. * What I have done is to translate it by using integer calculation. -- 2.33.0
[PATCH v6 0/5] drm/tiny: Add MIPI DBI compatible SPI driver
Hi, This patchset adds a driver that will work with most MIPI DBI compatible SPI panels out there. One change this time: Fix indentation in the DT binding. All patches are reviewed now so I will apply this after Rob's bot have looked at the binding. Thanks for reviewing! Noralf. Noralf Trønnes (5): dt-bindings: display: add bindings for MIPI DBI compatible SPI panels drm/modes: Remove trailing whitespace drm/modes: Add of_get_drm_panel_display_mode() drm/mipi-dbi: Add driver_private member to struct mipi_dbi_dev drm/tiny: Add MIPI DBI compatible SPI driver .../display/panel/panel-mipi-dbi-spi.yaml | 126 ++ MAINTAINERS | 8 + drivers/gpu/drm/drm_modes.c | 51 ++- drivers/gpu/drm/tiny/Kconfig | 15 + drivers/gpu/drm/tiny/Makefile | 1 + drivers/gpu/drm/tiny/panel-mipi-dbi.c | 398 ++ include/drm/drm_mipi_dbi.h| 8 + include/drm/drm_modes.h | 8 + 8 files changed, 614 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml create mode 100644 drivers/gpu/drm/tiny/panel-mipi-dbi.c -- 2.33.0
Re: [PATCH v6 1/4] drm/i915/guc: Add fetch of hwconfig table
Hi Jordan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next
drm/drm-next tegra-drm/drm/tegra/for-next v5.17-rc5 next-20220225]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Jordan-Justen/GuC-HWCONFIG-with-documentation/20220227-161945
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-a011
(https://download.01.org/0day-ci/archive/20220227/202202271904.1rr5ckwf-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project
d271fc04d5b97b12e6b797c6067d3c96a8d7470e)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/0day-ci/linux/commit/7a92eba9714ffe68202fee73b9916d35b0da2968
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Jordan-Justen/GuC-HWCONFIG-with-documentation/20220227-161945
git checkout 7a92eba9714ffe68202fee73b9916d35b0da2968
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/gpu/drm/i915/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:110: warning: Function
parameter or member 'gt' not described in 'guc_hwconfig_init'
>> drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:110: warning: expecting
>> prototype for intel_guc_hwconfig_init(). Prototype was for
>> guc_hwconfig_init() instead
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:143: warning: Function
parameter or member 'gt' not described in 'intel_gt_init_hwconfig'
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c:156: warning: Function
parameter or member 'gt' not described in 'intel_gt_fini_hwconfig'
vim +110 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
102
103 /**
104 * intel_guc_hwconfig_init - Initialize the HWConfig
105 *
106 * Retrieve the HWConfig table from the GuC and save it locally.
107 * It can then be queried on demand by other users later on.
108 */
109 static int guc_hwconfig_init(struct intel_gt *gt)
> 110 {
111 struct intel_hwconfig *hwconfig = >info.hwconfig;
112 struct intel_guc *guc = >uc.guc;
113 int ret;
114
115 if (!has_table(gt->i915))
116 return 0;
117
118 ret = guc_hwconfig_discover_size(guc, hwconfig);
119 if (ret)
120 return ret;
121
122 hwconfig->ptr = kmalloc(hwconfig->size, GFP_KERNEL);
123 if (!hwconfig->ptr) {
124 hwconfig->size = 0;
125 return -ENOMEM;
126 }
127
128 ret = guc_hwconfig_fill_buffer(guc, hwconfig);
129 if (ret < 0) {
130 intel_gt_fini_hwconfig(gt);
131 return ret;
132 }
133
134 return 0;
135 }
136
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
[PATCH v6 2/4] drm/i915/uapi: Add query for hwconfig blob
From: Rodrigo Vivi
The DRM_I915_QUERY_HWCONFIG_BLOB query item returns a blob of data
which it receives from the GuC software. This blob provides some
useful data about the hardware for drivers.
Although the blob is not fully documented at this time, the basic
format is an array of u32 values. The array is a simple and flexible
KLV (Key/Length/Value) formatted table. For example, it could be just:
enum device_attr { ATTR_SOME_VALUE = 0, ATTR_SOME_MASK = 1, };
static const u32 hwconfig[] = {
ATTR_SOME_VALUE,
1, // Value Length in DWords
8, // Value
ATTR_SOME_MASK,
3,
0x00, 0x, 0xFF00,
};
The attribute ids and meaning of the values will be documented in the
Programmer Reference Manuals when released.
Cc: Tvrtko Ursulin
Cc: Kenneth Graunke
Cc: Michal Wajdeczko
Cc: Slawomir Milczarek
Cc: Joonas Lahtinen
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
Acked-by: Jordan Justen
Tested-by: Jordan Justen
Acked-by: Jon Bloomfield
---
drivers/gpu/drm/i915/i915_query.c | 23 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_query.c
b/drivers/gpu/drm/i915/i915_query.c
index 2dfbc22857a3..b5ca00cb6cf6 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -479,12 +479,35 @@ static int query_memregion_info(struct drm_i915_private
*i915,
return total_length;
}
+static int query_hwconfig_blob(struct drm_i915_private *i915,
+ struct drm_i915_query_item *query_item)
+{
+ struct intel_gt *gt = to_gt(i915);
+ struct intel_hwconfig *hwconfig = >info.hwconfig;
+
+ if (!hwconfig->size || !hwconfig->ptr)
+ return -ENODEV;
+
+ if (query_item->length == 0)
+ return hwconfig->size;
+
+ if (query_item->length < hwconfig->size)
+ return -EINVAL;
+
+ if (copy_to_user(u64_to_user_ptr(query_item->data_ptr),
+hwconfig->ptr, hwconfig->size))
+ return -EFAULT;
+
+ return hwconfig->size;
+}
+
static int (* const i915_query_funcs[])(struct drm_i915_private *dev_priv,
struct drm_i915_query_item *query_item)
= {
query_topology_info,
query_engine_info,
query_perf_config,
query_memregion_info,
+ query_hwconfig_blob,
};
int i915_query_ioctl(struct drm_device *dev, void *data, struct drm_file *file)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 914ebd9290e5..069d2fadfbd9 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2685,6 +2685,7 @@ struct drm_i915_query_item {
#define DRM_I915_QUERY_ENGINE_INFO 2
#define DRM_I915_QUERY_PERF_CONFIG 3
#define DRM_I915_QUERY_MEMORY_REGIONS 4
+#define DRM_I915_QUERY_HWCONFIG_BLOB 5
/* Must be kept compact -- no holes and well documented */
/**
--
2.34.1
[PATCH v6 3/4] drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
v3:
* Add various changes suggested by Tvrtko
v5:
* Fix documenation formatting and verified with `make htmldocs` as
suggested by Daniel
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
Acked-by: Jon Bloomfield
Acked-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 43 +
1 file changed, 43 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 069d2fadfbd9..d033211cb862 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3279,6 +3279,49 @@ struct drm_i915_gem_create_ext_protected_content {
/* ID of the protected content session managed by i915 when PXP is active */
#define I915_PROTECTED_CONTENT_DEFAULT_SESSION 0xf
+/**
+ * DOC: GuC HWCONFIG blob uAPI
+ *
+ * The GuC produces a blob with information about the current device.
+ * i915 reads this blob from GuC and makes it available via this uAPI.
+ *
+ * The returned blob is a sequence of items of variable length
+ * described by struct drm_i915_query_hwconfig_blob_item.
+ *
+ * The overall blob returned by DRM_I915_QUERY_HWCONFIG_BLOB will end
+ * at the same location as the end of the final struct
+ * drm_i915_query_hwconfig_blob_item. In other words, walking through
+ * the individual items is guaranteed to eventually arrive at the
+ * exact end of the entire blob.
+ */
+
+/**
+ * struct drm_i915_query_hwconfig_blob_item - A single hwconfig item
+ * within the sequence of hwconfig items returned by
+ * DRM_I915_QUERY_HWCONFIG_BLOB.
+ *
+ * The length field gives the length of the data[] array. The length
+ * is the number of u32 items in the data[] array, and *not* the
+ * number of bytes.
+ *
+ * The key and length fields are required, so the minimum item size is
+ * 2 x u32, or 8 bytes, when the length field is 0. If the length
+ * field is 1, then the item's size is 12 bytes.
+ *
+ * The meaning of the key field and the data values are documented in
+ * the Programmer's Reference Manual.
+ */
+struct drm_i915_query_hwconfig_blob_item {
+ /** @key: Enum which defines how to interpret @data values. */
+ __u32 key;
+
+ /** @length: The number of u32 values in the @data array. */
+ __u32 length;
+
+ /** @data: Array of values with meaning defined by @key. */
+ __u32 data[];
+};
+
#if defined(__cplusplus)
}
#endif
--
2.34.1
[PATCH v6 4/4] drm/i915/guc: Verify hwconfig blob matches supported format
i915_drm.h now defines the format of the returned
DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
the black box GuC software, it should verify that the data matches
that format before sending it to user-space.
The verification makes a single simple pass through the blob contents,
so this verification step should not add a significant amount of init
time to i915.
v3:
* Add various changes suggested by Tvrtko
v4:
* Rewrite verify_hwconfig_blob() to hopefully be clearer without
relying on comments so much, and add various suggestions from
Michal.
v6:
* Rework based on John's updated "drm/i915/guc: Add fetch of hwconfig
table" v2 which stores the hwconfig blob at the GT level.
Signed-off-by: Jordan Justen
Acked-by: Jon Bloomfield
Reviewed-by: Tvrtko Ursulin
---
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index e0f65bdd1c84..1a3134d3d434 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -68,8 +68,44 @@ static int guc_hwconfig_discover_size(struct intel_guc *guc,
struct intel_hwconf
return 0;
}
+static int verify_hwconfig_blob(struct intel_guc *guc, struct intel_hwconfig
*hwconfig)
+{
+ struct drm_device *drm = _to_gt(guc)->i915->drm;
+ struct drm_i915_query_hwconfig_blob_item *item = hwconfig->ptr;
+ u64 offset = 0;
+ u64 remaining = hwconfig->size;
+ /* Everything before the data field is required */
+ u64 min_item_size = offsetof(struct drm_i915_query_hwconfig_blob_item,
data);
+ u64 item_size;
+
+ if (!IS_ALIGNED(hwconfig->size, sizeof(u32))) {
+ drm_err(drm, "hwconfig blob size (%d) is not u32 aligned\n",
hwconfig->size);
+ return -EINVAL;
+ }
+
+ while (offset < hwconfig->size) {
+ if (remaining < min_item_size) {
+ drm_err(drm, "hwconfig blob invalid (no room for item
required fields at offset %lld)\n",
+ offset);
+ return -EINVAL;
+ }
+ item_size = min_item_size + sizeof(u32) * item->length;
+ if (item_size > remaining) {
+ drm_err(drm, "hwconfig blob invalid (no room for data
array of item at offset %lld)\n",
+ offset);
+ return -EINVAL;
+ }
+ offset += item_size;
+ remaining -= item_size;
+ item = (void *)>data[item->length];
+ }
+
+ return 0;
+}
+
static int guc_hwconfig_fill_buffer(struct intel_guc *guc, struct
intel_hwconfig *hwconfig)
{
+ struct drm_device *drm = _to_gt(guc)->i915->drm;
struct i915_vma *vma;
u32 ggtt_offset;
void *vaddr;
@@ -84,8 +120,13 @@ static int guc_hwconfig_fill_buffer(struct intel_guc *guc,
struct intel_hwconfig
ggtt_offset = intel_guc_ggtt_offset(guc, vma);
ret = __guc_action_get_hwconfig(guc, ggtt_offset, hwconfig->size);
- if (ret >= 0)
+ if (ret >= 0) {
memcpy(hwconfig->ptr, vaddr, hwconfig->size);
+ if (verify_hwconfig_blob(guc, hwconfig)) {
+ drm_err(drm, "Ignoring invalid hwconfig blob received
from GuC!\n");
+ ret = -EINVAL;
+ }
+ }
i915_vma_unpin_and_release(, I915_VMA_RELEASE_MAP);
--
2.34.1
[PATCH v6 1/4] drm/i915/guc: Add fetch of hwconfig table
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
The table is stored in the GT structure so that it can be fetched once
at driver load time. Keeping inside a GuC structure would mean it
would be release and reloaded on a GuC reset (part of a full GT
reset). However, the table does not change just because the GT has been
reset and the GuC reloaded. Also, dynamic memory allocations inside
the reset path are a problem.
Note that the table is only available on ADL-P and later platforms.
v2 (John's v2 patch):
* Move to GT level to avoid memory allocation during reset path (and
unnecessary re-read of the table on a reset).
v5 (of Jordan's posting):
* Various changes made by Jordan and recommended by Michal
- Makefile ordering
- Adjust "struct intel_guc_hwconfig hwconfig" comment
- Set Copyright year to 2022 in intel_guc_hwconfig.c/.h
- Drop inline from hwconfig_to_guc()
- Replace hwconfig param with guc in __guc_action_get_hwconfig()
- Move zero size check into guc_hwconfig_discover_size()
- Change comment to say zero size offset/size is needed to get size
- Add has_guc_hwconfig to devinfo and drop has_table()
- Change drm_err to notice in __uc_init_hw() and use %pe
v6 (of Jordan's posting):
* Added a couple more small changes recommended by Michal
* Merge in John's v2 patch, but note:
- Using drm_notice as recommended by Michal
- Reverted Michal's suggestion of using devinfo
Cc: Michal Wajdeczko
Signed-off-by: Rodrigo Vivi
Signed-off-by: John Harrison
Reviewed-by: Matthew Brost
Acked-by: Jon Bloomfield
Signed-off-by: Jordan Justen
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c| 6 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 4 +
drivers/gpu/drm/i915/gt/intel_hwconfig.h | 21 +++
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 +
.../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 162 ++
7 files changed, 199 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gt/intel_hwconfig.h
create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 9d588d936e3d..61b078bd1b32 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -187,6 +187,7 @@ i915-y += gt/uc/intel_uc.o \
gt/uc/intel_guc_ct.o \
gt/uc/intel_guc_debugfs.o \
gt/uc/intel_guc_fw.o \
+ gt/uc/intel_guc_hwconfig.o \
gt/uc/intel_guc_log.o \
gt/uc/intel_guc_log_debugfs.o \
gt/uc/intel_guc_rc.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index e8403fa53909..bf02fb28562a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -712,6 +712,11 @@ int intel_gt_init(struct intel_gt *gt)
if (err)
goto err_uc_init;
+ err = intel_gt_init_hwconfig(gt);
+ if (err)
+ drm_notice(>i915->drm, "Failed to retrieve hwconfig table:
%pe\n",
+ ERR_PTR(err));
+
err = __engines_record_defaults(gt);
if (err)
goto err_gt;
@@ -793,6 +798,7 @@ void intel_gt_driver_release(struct intel_gt *gt)
intel_gt_pm_fini(gt);
intel_gt_fini_scratch(gt);
intel_gt_fini_buffer_pool(gt);
+ intel_gt_fini_hwconfig(gt);
}
void intel_gt_driver_late_release(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index f20687796490..514b92cff9b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -20,6 +20,7 @@
#include "i915_vma.h"
#include "intel_engine_types.h"
#include "intel_gt_buffer_pool_types.h"
+#include "intel_hwconfig.h"
#include "intel_llc_types.h"
#include "intel_reset_types.h"
#include "intel_rc6_types.h"
@@ -199,6 +200,9 @@ struct intel_gt {
struct sseu_dev_info sseu;
unsigned long mslice_mask;
+
+ /** @hwconfig: hardware configuration data */
+ struct intel_hwconfig hwconfig;
} info;
struct {
diff --git a/drivers/gpu/drm/i915/gt/intel_hwconfig.h
b/drivers/gpu/drm/i915/gt/intel_hwconfig.h
new file mode 100644
index ..322290780b67
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_hwconfig.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef _INTEL_HWCONFIG_H_
+#define _INTEL_HWCONFIG_H_
+
+#include
+
+struct intel_gt;
+
+struct intel_hwconfig {
+ u32 size;
+ void *ptr;
+};
+
+int intel_gt_init_hwconfig(struct intel_gt
[PATCH v6 0/4] GuC HWCONFIG with documentation
This is John/Rodrigo's 2 patches with some minor changes, and I added 2 patches. "drm/i915/uapi: Add query for hwconfig blob" was changed: * Rename DRM_I915_QUERY_HWCONFIG_TABLE to DRM_I915_QUERY_HWCONFIG_BLOB as requested by Joonas. * Reword commit message * I added Acked-by to this patch, but this Acked-by only applies in the context of this version of the patchset. "drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item" adds a struct to the uAPI and documents the return value for DRM_I915_QUERY_HWCONFIG_BLOB. (Except, keys / values are still deferred to the PRM.) "drm/i915/guc: Verify hwconfig blob matches supported format" does the simple verification of the blob to make sure it matches what the uAPI documents. v2: * Fix -Werror errors. * Rebase to drm-intel/for-linux-next instead of drm-intel/for-linux-next-gt, as this seems to be what CI wants. * Fix u32 -> __u32. * Add commit message for "Verify hwconfig blob" patch as requested by Tvrtko. * Reword text added to i915_drm.h as requested by Tvrtko. (Attempting to indicate the overall blob ends right at the last blob item.) v3: * Add several changes suggested by Tvrtko in the "Verify hwconfig blob", along with some tweaks to i915_drm.h from the feedback for the same patch. v4: * Rewrite verify_hwconfig_blob() to hopefully be clearer without relying on comments so much, and add various suggestions from Michal. * Michal also had some suggestions in John's "drm/i915/guc: Add fetch of hwconfig table" patch. I held off on making any of these changes in this version. v5: * Add many changes suggested by Michal in John's "drm/i915/guc: Add fetch of hwconfig table" patch. * Fix documenation formatting as suggested by Daniel in "drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item" v6: * Updated "drm/i915/guc: Add fetch of hwconfig table" by merging in John's v2 patch which saves the hwconfig blob at the GT level. I also added a few changes requested by Michal on the v5 posting. * Tvrtko requested an example of UMD using the i915 hwconfig interface. Mesa support for this interface can be seen in this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14511 John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Jordan Justen (2): drm/i915/uapi: Add struct drm_i915_query_hwconfig_blob_item drm/i915/guc: Verify hwconfig blob matches supported format Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig blob drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_gt.c| 6 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 4 + drivers/gpu/drm/i915/gt/intel_hwconfig.h | 21 ++ .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 203 ++ drivers/gpu/drm/i915/i915_query.c | 23 ++ include/uapi/drm/i915_drm.h | 44 9 files changed, 307 insertions(+) create mode 100644 drivers/gpu/drm/i915/gt/intel_hwconfig.h create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c -- 2.34.1
