[Bug 104299] Crash on amdgpu_sync_get_fence
https://bugs.freedesktop.org/show_bug.cgi?id=104299 --- Comment #9 from higu...@gmx.net --- Created attachment 136400 --> https://bugs.freedesktop.org/attachment.cgi?id=136400&action=edit dmesg oops with kasan 2 Another crash, this time in RUST, just to see if it helps in any way i know how to build stuff, but i have no idea how to debug the kernel :) can you please give me some pointers how to find and give you the needed info? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[amd-staging-drm-next] regression - *ERROR* Don't have enable_spread_spectrum_on_ppll for v4
Hello AMD team, I got this since latest 'amd-staging-drm-next' git update (#b956c586e58a) during boot with Polaris RX580 DC on: [3.586342] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't have enable_spread_spectrum_on_ppll for v4 [3.586410] [drm:dal_bios_parser_init_cmd_tbl [amdgpu]] *ERROR* Don't have program_clock for v7 Latest GOOD commit was #b341a19e8039 (drm/radeon: Remove KFD_CIK_SDMA_QUEUE_OFFSET). I'll bisect if I have some time. Maybe someone send a hint to the right commit. Thanks, Dieter[0.00] microcode: microcode updated early to revision 0x7, date = 2013-08-20 [0.00] Linux version 4.15.0-rc2-1.g7262353-default+ (dieter@SunWave1) (gcc version 7.2.1 20171020 [gcc-7-branch revision 253932] (SUSE Linux)) #1 SMP PREEMPT Wed Dec 20 22:10:01 CET 2017 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc2-1.g7262353-default+ root=UUID=e19dd5e4-9df9-4ed6-8962-2d8f4993b6a5 video=1920x1080 noresume splash=silent quiet showopts amdgpu.dc=1 [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009b7ff] usable [0.00] BIOS-e820: [mem 0x0009b800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000d-0x000d7fff] reserved [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x7f7a] usable [0.00] BIOS-e820: [mem 0x7f7b-0x7f7bbfff] ACPI data [0.00] BIOS-e820: [mem 0x7f7bc000-0x7f7bcfff] ACPI NVS [0.00] BIOS-e820: [mem 0x7f7bd000-0x7fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfecf] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00067fff] usable [0.00] NX (Execute Disable) protection: active [0.00] random: fast init done [0.00] SMBIOS 2.6 present. [0.00] DMI: FUJITSU PRIMERGY TX150 S7 /D2759, BIOS 6.00 Rev. 1.19.2759.A1 09/26/2012 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x68 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-D uncachable [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask F8000 write-back [0.00] 1 base 1 mask F write-back [0.00] 2 base 2 mask E write-back [0.00] 3 base 4 mask E write-back [0.00] 4 base 6 mask F8000 write-back [0.00] 5 base 0FE00 mask FFE00 uncachable [0.00] 6 disabled [0.00] 7 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] e820: update [mem 0x8000-0x] usable ==> reserved [0.00] e820: last_pfn = 0x7f7b0 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000f97c0-0x000f97cf] mapped at [ (ptrval)] [0.00] Scanning 1 areas for low memory corruption [0.00] Base memory trampoline at [(ptrval)] 95000 size 24576 [0.00] BRK [0x35d3d, 0x35d3d0fff] PGTABLE [0.00] BRK [0x35d3d1000, 0x35d3d1fff] PGTABLE [0.00] BRK [0x35d3d2000, 0x35d3d2fff] PGTABLE [0.00] BRK [0x35d3d3000, 0x35d3d3fff] PGTABLE [0.00] BRK [0x35d3d4000, 0x35d3d4fff] PGTABLE [0.00] BRK [0x35d3d5000, 0x35d3d5fff] PGTABLE [0.00] BRK [0x35d3d6000, 0x35d3d6fff] PGTABLE [0.00] BRK [0x35d3d7000, 0x35d3d7fff] PGTABLE [0.00] RAMDISK: [mem 0x36517000-0x37282fff] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F9790 24 (v02 PTLTD ) [0.00] ACPI: XSDT 0x7F7B4206 00010C (v01 PTLTD ? XSDT 0006 LTP ) [0.00] ACPI: FACP 0x7F7B9D07 F4 (v03 FTSD2759/Ax 0006 FTS 000F4240) [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm1aControlBlock: 16/32 (20170831/tbfadt-603) [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Pm2ControlBlock: 8/32 (20170831/tbfadt-603) [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/PmTimerBlock: 32/24 (20170831/tbfadt-603) [0.00] ACPI
[Bug 104299] Crash on amdgpu_sync_get_fence
https://bugs.freedesktop.org/show_bug.cgi?id=104299 --- Comment #8 from Andrey Grodzovsky --- (In reply to higuita from comment #7) > Created attachment 136398 [details] > dmesg oops with kasan > > Sure, there is the dmesg after a crash with kasan, this time over warthunder Thanks, this seems like trying to access a fence which already was released, but i can't pinpoint the faulting line in the code both for amdgpu_sync_get_fence and for amdgpu_sync_resv, I am using addr2line for this but the offset into the function shown in the backtrace doesn't make sense. Maybe because our builds differ, can you try it and see if you get the exact offending lines in both functions ? Thanks, Andrey -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/11] Allwinner H3/H5/A64(DE2) SimpleFB support
On Wed, Dec 27, 2017 at 12:10 PM, Icenowy Zheng wrote: > 在 2017年12月27日星期三 CST 下午12:09:41，Chen-Yu Tsai 写道： >> On Fri, Dec 22, 2017 at 8:22 PM, Icenowy Zheng wrote: >> > This patchset adds support for the SimpleFB on Allwinner SoCs with >> > "Display Engine 2.0". >> > >> > PATCH 1 to PATCH 3 are DE2 CCU fixes for H3/H5 SoCs. >> > >> > PATCH 4 adds the pipeline strings for DE2 SimpleFB. >> > >> > PATCH 5 to 7 adds necessary device tree nodes (DE2 CCU and SimpleFB) >> > for H3/H5 SoCs. >> > >> > PATCH 8 to 11 are for Allwinner A64 SoC to enable SimpleFB. >> >> Changelog? > > They're in seperate patches. Please add them to all patches in such a case. List "none" if there were no changes. ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/11] Allwinner H3/H5/A64(DE2) SimpleFB support
On Fri, Dec 22, 2017 at 8:22 PM, Icenowy Zheng wrote: > This patchset adds support for the SimpleFB on Allwinner SoCs with > "Display Engine 2.0". > > PATCH 1 to PATCH 3 are DE2 CCU fixes for H3/H5 SoCs. > > PATCH 4 adds the pipeline strings for DE2 SimpleFB. > > PATCH 5 to 7 adds necessary device tree nodes (DE2 CCU and SimpleFB) > for H3/H5 SoCs. > > PATCH 8 to 11 are for Allwinner A64 SoC to enable SimpleFB. Changelog? ChenYu > > Icenowy Zheng (11): > dt-bindings: fix the binding of Allwinner DE2 CCU of A83T and H3 > clk: sunxi-ng: add support for Allwinner H3 DE2 CCU > clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU > dt-bindings: simplefb-sunxi: add pipelines for DE2 > ARM: sun8i: h3/h5: add DE2 CCU device node for H3 > arm64: allwinner: h5: add compatible string for DE2 CCU > ARM: sunxi: h3/h5: add simplefb nodes > dt-bindings: add binding for A64 DE2 CCU SRAM > clk: sunxi-ng: add support for Allwinner A64 DE2 CCU > arm64: allwinner: a64: add DE2 CCU for A64 SoC > arm64: allwinner: a64: add simplefb for A64 SoC > > .../devicetree/bindings/clock/sun8i-de2.txt| 10 ++- > .../bindings/display/simple-framebuffer-sunxi.txt | 4 + > arch/arm/boot/dts/sun8i-h3.dtsi| 4 + > arch/arm/boot/dts/sunxi-h3-h5.dtsi | 43 +++ > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 65 + > arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 + > drivers/clk/sunxi-ng/ccu-sun8i-de2.c | 85 > +++--- > 7 files changed, 202 insertions(+), 13 deletions(-) > > -- > 2.14.2 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101987] Loud fan and maximum GPU fan speed
https://bugs.freedesktop.org/show_bug.cgi?id=101987 --- Comment #3 from fin4...@hotmail.com --- Here is the source code of the radeon kernel driver: https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/radeon?h=drm-next-4.16-wip Locate the fan handling code for your cpu and try to figure how to fix it. How to make a custom kernel package, see message at 2017-12-22 18:53:16 CST: https://bugs.winehq.org/show_bug.cgi?id=43995 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)
https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #5 from Tom Englund --- happends here aswell on various applications, i do however not really notice any problems in the applications themself when it happends. lscpi: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XT [Radeon RX Vega 64] (rev c3) (prog-if 00 [VGA controller]) glxinfo: OpenGL renderer string: Radeon RX Vega (VEGA10 / DRM 3.23.0 / 4.15.0-rc2-mainline, LLVM 6.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.4.0-devel (git-3667714ccd) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104299] Crash on amdgpu_sync_get_fence
https://bugs.freedesktop.org/show_bug.cgi?id=104299 --- Comment #7 from higu...@gmx.net --- Created attachment 136398 --> https://bugs.freedesktop.org/attachment.cgi?id=136398&action=edit dmesg oops with kasan Sure, there is the dmesg after a crash with kasan, this time over warthunder -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: add jianda vendor prefix
On Thu, Dec 21, 2017 at 01:23:51PM -0600, David Lechner wrote: > This adds a vendor prefix "jianda" for Jiandangjing Technology Co., Ltd. > > Signed-off-by: David Lechner > --- > > v3 changes: > * new patch in v3 > > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 41cb1ff0..fea7903 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -172,6 +172,7 @@ issi Integrated Silicon Solutions Inc. > iteadITEAD Intelligent Systems Co.Ltd > iwave iWave Systems Technologies Pvt. Ltd. > jdi Japan Display Inc. > +jianda Jiandangjing Technology Co., Ltd. > jedecJEDEC Solid State Technology Association Err, not alphabetical order. With that fixed, Reviewed-by: Rob Herring > karo Ka-Ro electronics GmbH > keithkoepKeith & Koep GmbH > -- > 2.7.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] dt-bindings: update compatible string for ILI9225
On Thu, Dec 21, 2017 at 12:33:06PM -0600, David Lechner wrote: > This updates the compatible string for a no-name LCD panel to > "vot,v220hf01a-t", "ilitek,ili9225". > > The original bindings [1] were the generic "ilitek,ili9225-2.2in-176x220" > because I could not find a datasheet. However, after some more research, > I finally found one, so the actual vendor and model name are now known. > > This previous bindings have not made it to the mainline kernel yet, so > this is not breaking backwards compatibility. > > This is also following the precedence of the ILI9322 bindings [2] by using > the pattern "vendor,specific-system-config", "vendor,ip-part"; > > [1]: https://patchwork.ozlabs.org/patch/839352/ > [2]: https://patchwork.ozlabs.org/patch/843576/ > > Signed-off-by: David Lechner > --- > Documentation/devicetree/bindings/display/ilitek,ili9225.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] dt-bindings: Add "vot" vendor prefix
On Thu, Dec 21, 2017 at 12:33:05PM -0600, David Lechner wrote: > This adds a vendor prefix "vot" for Vision Optical Technology Co., Ltd. > They make LCD displays. > > Signed-off-by: David Lechner > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 01/11] dt-bindings: fix the binding of Allwinner DE2 CCU of A83T and H3
On Fri, Dec 22, 2017 at 6:22 AM, Icenowy Zheng wrote:
> The DE2 CCU is different on A83T and H3 -- the parent of the clocks on
> A83T is PLL_DE but on H3 it's the DE module clock. This is not noticed
> when I develop the DE2 CCU driver.
>
> Fix the binding by using different compatibles for A83T and H3, adding
> notes for the PLL_DE usage on A83T, and change the binding example's
> compatible from A83T to H3 (as it specifies the DE module clock).
>
> Fixes: ed74f8a8a679 ("dt-bindings: add binding for the Allwinner DE2 CCU")
> Signed-off-by: Icenowy Zheng
> ---
> Documentation/devicetree/bindings/clock/sun8i-de2.txt | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Please add acks when posting new versions.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/3] dt-bindings: Add binding for Sitronix ST7735R display panels
On Thu, Dec 21, 2017 at 1:23 PM, David Lechner wrote: > This adds a new device tree binding for Sitronix ST7735R display panels, > such as the Adafruit 1.8" TFT. > > Signed-off-by: David Lechner > --- > > v3 changes: > * compatible string is changed from "sitronix,st7735r-jd-t18003-t01" to > "jianda,jd-t18003-t01", "sitronix,st7735r" > > v2 changes: > * none > > .../bindings/display/sitronix,st7735r.txt | 35 > ++ > 1 file changed, 35 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/sitronix,st7735r.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv
On Wed, Dec 20, 2017 at 10:59:57AM +0100, Daniel Vetter wrote: > On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote: > > I forgot to include this brief information about this patch series. > > > > This patch series contains the implementation of a new device driver, > > hyper_dmabuf, which provides a method for DMA-BUF sharing across > > different OSes running on the same virtual OS platform powered by > > a hypervisor. > > > > Detailed information about this driver is described in a high-level doc > > added by the second patch of the series. > > > > [RFC PATCH 02/60] hyper_dmabuf: added a doc for hyper_dmabuf sharing > > > > I am attaching 'Overview' section here as a summary. > > > > -- > > Section 1. Overview > > -- > > > > Hyper_DMABUF driver is a Linux device driver running on multiple Virtual > > achines (VMs), which expands DMA-BUF sharing capability to the VM > > environment > > where multiple different OS instances need to share same physical data > > without > > data-copy across VMs. > > > > To share a DMA_BUF across VMs, an instance of the Hyper_DMABUF drv on the > > exporting VM (so called, “exporter”) imports a local DMA_BUF from the > > original > > producer of the buffer, then re-exports it with an unique ID, > > hyper_dmabuf_id > > for the buffer to the importing VM (so called, “importer”). > > > > Another instance of the Hyper_DMABUF driver on importer registers > > a hyper_dmabuf_id together with reference information for the shared > > physical > > pages associated with the DMA_BUF to its database when the export happens. > > > > The actual mapping of the DMA_BUF on the importer’s side is done by > > the Hyper_DMABUF driver when user space issues the IOCTL command to access > > the shared DMA_BUF. The Hyper_DMABUF driver works as both an importing and > > exporting driver as is, that is, no special configuration is required. > > Consequently, only a single module per VM is needed to enable cross-VM > > DMA_BUF > > exchange. > > So I know that most dma-buf implementations (especially lots of importers > in drivers/gpu) break this, but fundamentally only the original exporter > is allowed to know about the underlying pages. There's various scenarios > where a dma-buf isn't backed by anything like a struct page. > > So your first step of noodling the underlying struct page out from the > dma-buf is kinda breaking the abstraction, and I think it's not a good > idea to have that. Especially not for sharing across VMs. > > I think a better design would be if hyper-dmabuf would be the dma-buf > exporter in both of the VMs, and you'd import it everywhere you want to in > some gpu/video/whatever driver in the VMs. That way hyper-dmabuf is always > in control of the pages, and a lot of the troubling forwarding you > currently need to do disappears. I think one of the main driving use cases here is for a "local" graphics compositor inside the VM to accept client buffers from unmodified applications and then pass those buffers along to a "global" compositor running in the service domain. This would allow the global compositor to composite applications running in different virtual machines (and possibly running under different operating systems). If we require that hyper-dmabuf always be the exporter, that complicates things a little bit since a buffer allocated via regular interfaces (GEM ioctls or whatever) wouldn't be directly transferrable to the global compositor. For graphics use cases like this, we could probably hide a lot of the details by modifying/replacing the EGL implementation that handles the details of buffer allocation. However if we have applications that are themselves just passing along externally-allocated buffers (e.g., images from a camera device), we'd probably need to modify those applications and/or the drivers they get their content from. Matt > > 2nd thing: This seems very much related to what's happening around gvt and > allowing at least the host (in a kvm based VM environment) to be able to > access some of the dma-buf (or well, framebuffers in general) that the > client is using. Adding some mailing lists for that. > -Daniel > > > > > -- > > > > There is a git repository at github.com where this series of patches are all > > integrated in Linux kernel tree based on the commit: > > > > commit ae64f9bd1d3621b5e60d7363bc20afb46aede215 > > Author: Linus Torvalds > > Date: Sun Dec 3 11:01:47 2017 -0500 > > > > Linux 4.15-rc2 > > > > https://github.com/downor/linux_hyper_dmabuf.git hyper_dmabuf_integration_v3 > > > > ___ > > dri-devel mailing list > > dri-devel@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/lis
Re: [PATCH v2 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
On Fri, Dec 22, 2017 at 4:43 AM, Türk, Jan wrote: >> Von: Rob Herring [mailto:r...@kernel.org] >> Gesendet: Freitag, 22. Dezember 2017 00:00 >> Betreff: Re: [PATCH v2 1/5] drm/panel: Add support for the EDT >> ETM0700G0BDH6 >> >> On Wed, Dec 20, 2017 at 02:47:01PM +0100, jan.tu...@emtrion.com wrote: >> > From: Jan Tuerk >> > >> > The Emerging Display Technology ETM0700G0BDH6 is exactly the same >> > display as the ETM0700G0DH6, exept the pixelclock polarity. Therefore >> > re-use the ETM0700G0DH6 modes. It is used by default on emtrion Avari >> > based development kits. >> >> As I asked on v1, why not document the panels together in a single doc? > > As denoted in the cover letter: I generally don't read cover letters... >>The documentation for the EDT display is kept as an extra file currently, >>as it is done by the most displays in the documentation. Also a new >>new Variant of the EDT already arrived. So merging their documentations >>should be discussed separately. You mean a 3rd variant? > I think it will be even a little tricky to find a matching filename for both > versions, > as the recent ones adding an extra character in the description. Are you > expecting sth. > like edt,etm0700series.txt? Yeah, or edt,etm0700g0.txt. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] ARM: dts: Add support for emtrion emCON-MX6 series
On Fri, Dec 22, 2017 at 4:56 AM, Alexandre Belloni
wrote:
> + Philippe
>
> On 22/12/2017 at 11:43:33 +0100, Andreas Färber wrote:
>> >> I'll change it for v3 of this patch however it will end up like this:
>> >> //SPDX-License...
>> >
>> > That should be /* SPDX-License */, // is for c files.
>>
>> Got any reference for that? Since we're using the C preprocessor before
>> feeding them to dtc, we can use the same // style for both, builds fine.
>>
>> Only for my private DT overlay files that I use directly with dtc I
>> couldn't adopt that style.
We are well past the point of being able to build most dts files with just dtc.
> The doc states:
>
> If a specific tool cannot handle the standard comment style, then the
> appropriate comment mechanism which the tool accepts shall be used. This
> is the reason for having the "/\* \*/" style comment in C header
> files.
>
> I interpreted that as dtc doesn't handle // comments, use /**/
It's been so long, I'd forgotten that. Perhaps we should fix dtc to
handle // comments.
>
> But I agree it also states:
> .dts{i}: // SPDX-License-Identifier:
Or we could still change this. The guidelines aren't merged yet.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 1/2] drm/exynos/decon: Move headers from global to local place
The DECON headers contain only defines for registers. There are no other drivers using them so this should be put locally to the Exynos DRM driver. Keeping headers local helps managing the code. Suggested-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski --- Resend after half a year... Changes since v1: 1. Just re-order patches in patchset. --- drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 3 +-- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +- .../exynos5433_decon.h => drivers/gpu/drm/exynos/regs-decon5433.h | 0 include/video/exynos7_decon.h => drivers/gpu/drm/exynos/regs-decon7.h | 3 +-- 4 files changed, 3 insertions(+), 5 deletions(-) rename include/video/exynos5433_decon.h => drivers/gpu/drm/exynos/regs-decon5433.h (100%) rename include/video/exynos7_decon.h => drivers/gpu/drm/exynos/regs-decon7.h (99%) diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c index 6be5b53c3b27..1427c385bddc 100644 --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c @@ -21,13 +21,12 @@ #include #include -#include - #include "exynos_drm_drv.h" #include "exynos_drm_crtc.h" #include "exynos_drm_fb.h" #include "exynos_drm_plane.h" #include "exynos_drm_iommu.h" +#include "regs-decon5433.h" #define DSD_CFG_MUX 0x1004 #define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13) diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c index 615efcf7782a..3931d5e33fe0 100644 --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c @@ -25,13 +25,13 @@ #include #include -#include #include "exynos_drm_crtc.h" #include "exynos_drm_plane.h" #include "exynos_drm_drv.h" #include "exynos_drm_fb.h" #include "exynos_drm_iommu.h" +#include "regs-decon7.h" /* * DECON stands for Display and Enhancement controller. diff --git a/include/video/exynos5433_decon.h b/drivers/gpu/drm/exynos/regs-decon5433.h similarity index 100% rename from include/video/exynos5433_decon.h rename to drivers/gpu/drm/exynos/regs-decon5433.h diff --git a/include/video/exynos7_decon.h b/drivers/gpu/drm/exynos/regs-decon7.h similarity index 99% rename from include/video/exynos7_decon.h rename to drivers/gpu/drm/exynos/regs-decon7.h index a62b11b613f6..339ea1007ff5 100644 --- a/include/video/exynos7_decon.h +++ b/drivers/gpu/drm/exynos/regs-decon7.h @@ -1,5 +1,4 @@ -/* include/video/exynos7_decon.h - * +/* * Copyright (c) 2014 Samsung Electronics Co., Ltd. * Author: Ajay Kumar * -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND PATCH v2 2/2] drm/exynos/decon: Add include guard to the Exynos7 header
Although header is included only once but still having an include guard is a good practice. To avoid confusion, add SoC prefix to existing Exynos5433 header include guard. Signed-off-by: Krzysztof Kozlowski --- Resend after half a year... Changes since v1: 1. Just re-order patches in patchset and slightly adjust include guard name. --- drivers/gpu/drm/exynos/regs-decon5433.h | 6 +++--- drivers/gpu/drm/exynos/regs-decon7.h| 5 + 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/regs-decon5433.h b/drivers/gpu/drm/exynos/regs-decon5433.h index 78957c9626f5..19ad9e47945e 100644 --- a/drivers/gpu/drm/exynos/regs-decon5433.h +++ b/drivers/gpu/drm/exynos/regs-decon5433.h @@ -6,8 +6,8 @@ * published by the Free Software Foundationr */ -#ifndef EXYNOS_REGS_DECON_H -#define EXYNOS_REGS_DECON_H +#ifndef EXYNOS_REGS_DECON5433_H +#define EXYNOS_REGS_DECON5433_H /* Exynos543X DECON */ #define DECON_VIDCON0 0x @@ -206,4 +206,4 @@ #define CRCCTRL_CRCEN (0x1 << 0) #define CRCCTRL_MASK (0x7) -#endif /* EXYNOS_REGS_DECON_H */ +#endif /* EXYNOS_REGS_DECON5433_H */ diff --git a/drivers/gpu/drm/exynos/regs-decon7.h b/drivers/gpu/drm/exynos/regs-decon7.h index 339ea1007ff5..5df7765d2397 100644 --- a/drivers/gpu/drm/exynos/regs-decon7.h +++ b/drivers/gpu/drm/exynos/regs-decon7.h @@ -8,6 +8,9 @@ * option) any later version. */ +#ifndef EXYNOS_REGS_DECON7_H +#define EXYNOS_REGS_DECON7_H + /* VIDCON0 */ #define VIDCON00x00 @@ -346,3 +349,5 @@ #define DECON_UPDATE_SLAVE_SYNC(1 << 4) #define DECON_UPDATE_STANDALONE_F (1 << 0) + +#endif /* EXYNOS_REGS_DECON7_H */ -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
