[GIT PULL] exynos-drm-next
Hi Dave and Daniel, Just one fixup series to restore proper bridge chain order of Exynos Display pipeline. This is also required by a patch series[1] which makes existing Exynos DSI driver to be common driver so that it can be used by Exynos and I.MX8MM SoC commonly - under the review yet. [1] https://lore.kernel.org/linux-arm-kernel/d4267645-448c-f702-fcc3-6c534d9ec...@denx.de/T/ Please let me know if there is any problem. Thanks, Inki Dae The following changes since commit 68de345e101ce9a24e5c8849e69dd0dba2e8c9b2: Merge tag 'drm-misc-next-2023-01-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2023-01-25 12:14:08 +1000) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos tags/exynos-drm-next-for-v6.3 for you to fetch changes up to 1a1ce789e6c5da5a16d3d17bc228c6ab0b5863ed: drm: exynos: dsi: Restore proper bridge chain order (2023-01-26 15:11:24 +0900) One fixup series - Make sure to restore bridge chain order by enabling the drm panel prepare_prev_first flag of the bridge and panel drivers - tc358764 display bridge device and Samsung s6e3ha2/s6e63j0x03/s6e8aa0 panel devices. In case of any boards using Exynos5433 SoC, below Display pipeline could be configured. Decon -> MIC -> MIPI-DSI -> Panel So, this patch series makes sure to enable previous bridge device before enabling MIPI-DSI device. Jagan Teki (2): drm: panel: Enable prepare_prev_first flag for samsung-s6e panels drm: exynos: dsi: Restore proper bridge chain order Marek Szyprowski (1): drm/bridge: tc358764: Enable pre_enable_prev_first flag drivers/gpu/drm/bridge/tc358764.c| 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +++-- drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c| 1 + drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 + drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 1 + 5 files changed, 11 insertions(+), 2 deletions(-)
Re: [vmwgfx] crash upon vmw_open_channel() when booting on Oracle VM VirtualBox
On Sun, 2023-01-29 at 17:11 +0900, Tetsuo Handa wrote: > On 2023/01/29 15:00, Zack Rusin wrote: > > On Sat, 2023-01-28 at 20:44 +0900, Tetsuo Handa wrote: > > > Hello. > > > > > > I noticed that a kernel built with vmwgfx driver fails to boot a Linux > > > guest > > > on Oracle VM VirtualBox 7.0.4 on Windows 11 on DELL Inspiron 14 5420. > > > I didn't notice this problem when I booted an older kernel on an older > > > version > > > of Oracle VM VirtualBox on Windows 8.1 on an older PC. > > > > > > The location that crashes is > > > > > > VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL, > > > (protocol | GUESTMSG_FLAG_COOKIE), si, di, > > > 0, > > > VMW_HYPERVISOR_MAGIC, > > > eax, ebx, ecx, edx, si, di); > > > > > > in vmw_open_channel(). It might be that some changes in VirtualBox side > > > is conflicting with how VMware tries to test if the guest is VMware. > > > How can I debug this problem? > > > > You'd have to figure out what exactly is the problem. I couldn't reproduce > > it on > > vmware hypervisors with your .config. > > This problem happens on not VMware hypervisors but VirtualBox hypervisors. Yea, that's why I can't debug it myself and would need someone else to figure out the exact issue. > > > FWIW that code has been there and > > hasn't > > been > > changed in years. Oracle emulated svga device always had problems, was never > > supported by vmwgfx and afaict is not maintained by Oracle so I'd strongly > > suggest > > that you switch to some other graphics device on virtualbox. > > Indeed, not selecting VMSVGA as Graphics Controller in the screen tab of > display > setting allowed me to boot the guest. > > The reason I built-in vmwgfx is that I want to reuse the same kernel > configuration > on > multiple environments; syzbot uses a large kernel configuration that builts-in > almost > everything. Building vmwgfx is great, it's selecting the vmsvga device in virtualbox that's the problem. afaict that device is unmaintained and unsupported. > > In the meantime I think the attached patch should at least get you booting. > > You > > can > > give it a try and if it works I can push it sometime this week. > > Yes, this patch allowed me to boot the guest when selecting VMSVGA as Graphics > Controller. > > Thank you. Great. I'll clean it up and send it for review to dri-devel sometime this week. z
Re: linux-6.2-rc4+ hangs on poweroff/reboot: Bisected
On Sat, 28 Jan 2023 at 21:29, Chris Clayton wrote: > > > > On 28/01/2023 05:42, Linux kernel regression tracking (Thorsten Leemhuis) > wrote: > > On 27.01.23 20:46, Chris Clayton wrote: > >> [Resend because the mail client on my phone decided to turn HTML on behind > >> my back, so my reply got bounced.] > >> > >> Thanks Thorsten. > >> > >> I did try to revert but it didnt revert cleanly and I don't have the > >> knowledge to fix it up. > >> > >> The patch was part of a merge that included a number of related patches. > >> Tomorrow, I'll try to revert the lot and report > >> back. > > > > You are free to do so, but there is no need for that from my side. I > > only wanted to know if a simple revert would do the trick; if it > > doesn't, it in my experience often is best to leave things to the > > developers of the code in question, > > Sound advice, Thorsten. Way to many conflicts for me to resolve. Hey, This is a complete shot-in-the-dark, as I don't see this behaviour on *any* of my boards. Could you try the attached patch please? Thanks, Ben. > > as they know it best and thus have a > > better idea which hidden side effect a more complex revert might have. > > > > Ciao, Thorsten > > > >> On 27/01/2023 11:20, Linux kernel regression tracking (Thorsten Leemhuis) > >> wrote: > >>> Hi, this is your Linux kernel regression tracker. Top-posting for once, > >>> to make this easily accessible to everyone. > >>> > >>> @nouveau-maintainers, did anyone take a look at this? The report is > >>> already 8 days old and I don't see a single reply. Sure, we'll likely > >>> get a -rc8, but still it would be good to not fix this on the finish line. > >>> > >>> Chris, btw, did you try if you can revert the commit on top of latest > >>> mainline? And if so, does it fix the problem? > >>> > >>> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) > >>> -- > >>> Everything you wanna know about Linux kernel regression tracking: > >>> https://linux-regtracking.leemhuis.info/about/#tldr > >>> If I did something stupid, please tell me, as explained on that page. > >>> > >>> #regzbot poke > >>> > >>> On 19.01.23 15:33, Linux kernel regression tracking (Thorsten Leemhuis) > >>> wrote: > [adding various lists and the two other nouveau maintainers to the list > of recipients] > >>> > On 18.01.23 21:59, Chris Clayton wrote: > > Hi. > > > > I build and installed the lastest development kernel earlier this week. > > I've found that when I try the laptop down (or > > reboot it), it hangs right at the end of closing the current session. > > The last line I see on the screen when rebooting is: > > > > sd 4:0:0:0: [sda] Synchronising SCSI cache > > > > when closing down I see one additional line: > > > > sd 4:0:0:0 [sda]Stopping disk > > > > In both cases the machine then hangs and I have to hold down the power > > button fot a few seconds to switch it off. > > > > Linux 6.1 is OK but 6.2-rc1 hangs, so I bisected between this two and > > landed on: > > > > # first bad commit: [0e44c21708761977dcbea9b846b51a6fb684907a] > > drm/nouveau/flcn: new code to load+boot simple HS FWs > > (VPR scrubber) > > > > I built and installed a kernel with > > f15cde64b66161bfa74fb58f4e5697d8265b802e (the parent of the bad commit) > > checked out > > and that shuts down and reboots fine. It the did the same with the bad > > commit checked out and that does indeed hang, so > > I'm confident the bisect outcome is OK. > > > > Kernels 6.1.6 and 5.15.88 are also OK. > > > > My system had dual GPUs - one intel and one NVidia. Related extracts > > from 'lscpi -v' is: > > > > 00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 > > [UHD Graphics] (rev 05) (prog-if 00 [VGA controller]) > > Subsystem: CLEVO/KAPOK Computer CometLake-H GT2 [UHD Graphics] > > > > Flags: bus master, fast devsel, latency 0, IRQ 142 > > > > Memory at c200 (64-bit, non-prefetchable) [size=16M] > > > > Memory at a000 (64-bit, prefetchable) [size=256M] > > > > I/O ports at 5000 [size=64] > > > > Expansion ROM at 000c [virtual] [disabled] [size=128K] > > > > Capabilities: [40] Vendor Specific Information: Len=0c > > > > Capabilities: [70] Express Root Complex Integrated Endpoint, > > MSI 00 > > > > Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- > > > > Capabilities: [d0] Power Management version 2 > > > > Kernel driver in use: i915 > > > > Kernel modules: i915 > > > > > > 01:00.0 VGA compatible controller: NVIDIA Corporation TU117M [GeForce > > GTX 1650 Ti Mobile] (rev a1) (prog-if 00 [VGA > > controller]) > > Subsystem:
Re: [PATCH] dt-bindings: Add missing (unevaluated|additional)Properties on child node schemas
Hi, On Tue, Jan 24, 2023 at 05:02:28PM -0600, Rob Herring wrote: > Just as unevaluatedProperties or additionalProperties are required at > the top level of schemas, they should (and will) also be required for > child node schemas. That ensures only documented properties are > present. > > Add unevaluatedProperties or additionalProperties as appropriate, and > then add any missing properties flagged by the addition. > > Signed-off-by: Rob Herring > --- > [...] > diff --git a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml > b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml > index ce6fbdba8f6b..0542d4126cf5 100644 > --- a/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml > +++ b/Documentation/devicetree/bindings/power/supply/ti,lp8727.yaml > @@ -28,6 +28,7 @@ properties: > patternProperties: >'^(ac|usb)$': > type: object > +additionalProperties: false > description: USB/AC charging parameters > properties: >charger-type: Acked-by: Sebastian Reichel -- Sebastian signature.asc Description: PGP signature
Re: [REGRESSION] GM20B probe fails after commit 2541626cfb79
On Fri, 27 Jan 2023 at 20:42, Diogo Ivo wrote:
>
> On Fri, Jan 27, 2023 at 04:00:59PM +1000, Ben Skeggs wrote:
> > On Fri, 20 Jan 2023 at 21:37, Diogo Ivo
> > wrote:
> > >
> > > On Wed, Jan 18, 2023 at 11:28:49AM +1000, Ben Skeggs wrote:
> > > > On Mon, 16 Jan 2023 at 22:27, Diogo Ivo
> > > > wrote:
> > > > > On Mon, Jan 16, 2023 at 07:45:05AM +1000, David Airlie wrote:
> > > > > > As a quick check can you try changing
> > > > > >
> > > > > > drivers/gpu/drm/nouveau/nvkm/core/firmware.c:nvkm_firmware_mem_target
> > > > > > from NVKM_MEM_TARGET_HOST to NVKM_MEM_TARGET_NCOH ?
> > >
> > > > In addition to Dave's change, can you try changing the
> > > > nvkm_falcon_load_dmem() call in gm20b_pmu_init() to:
> > > >
> > > > nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args,
> > > > sizeof(args), 0, false);
> > >
> > > Chiming in just to say that with this change I see the same as Nicolas
> > > except that the init message size is 255 instead of 0:
> > >
> > > [2.196934] nouveau 5700.gpu: pmu: unexpected init message size
> > > 255 vs 42
> > I've attached an entirely untested patch (to go on top of the other
> > hacks/fixes so far), that will hopefully get us a little further.
>
> Hello,
>
> Thank you for the patch! I can confirm that it fixes the problem
> on the Pixel C, and everything works as before the regression.
> With this, for the combination of patches
>
> Tested-by: Diogo Ivo
>
> which I can resend after testing the final patch version.
Thank you (both!) for testing!
I've attached a "final" version of a patch that I'll send (assuming it
still works ;)) after re-testing. There's only a minor change to
avoid breaking the non-Tegra path, so I expect it should be fine.
Ben.
>
> Thanks,
> Diogo
From bfc1b84d26ca28f78a07d494b0813fe642e80bbe Mon Sep 17 00:00:00 2001
From: Ben Skeggs
Date: Fri, 27 Jan 2023 15:42:27 +1000
Subject: [PATCH] drm/nouveau/acr/gm20b: regression fixes
Missed some Tegra-specific quirks when reworking ACR to support Ampere.
Fixes: 2541626cfb79 ("drm/nouveau/acr: use common falcon HS FW code for ACR FWs")
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/core/firmware.c| 3 +++
drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c | 14 +-
drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c | 2 +-
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index fcf2a002f6cb..91fb494d4009 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -151,6 +151,9 @@ nvkm_firmware_mem_page(struct nvkm_memory *memory)
static enum nvkm_memory_target
nvkm_firmware_mem_target(struct nvkm_memory *memory)
{
+ if (nvkm_firmware_mem(memory)->device->func->tegra)
+ return NVKM_MEM_TARGET_NCOH;
+
return NVKM_MEM_TARGET_HOST;
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
index 393ade9f7e6c..b7da3ab44c27 100644
--- a/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
+++ b/drivers/gpu/drm/nouveau/nvkm/falcon/gm200.c
@@ -48,6 +48,16 @@ gm200_flcn_pio_dmem_rd(struct nvkm_falcon *falcon, u8 port, const u8 *img, int l
img += 4;
len -= 4;
}
+
+ /* Sigh. Tegra PMU FW's init message... */
+ if (len) {
+ u32 data = nvkm_falcon_rd32(falcon, 0x1c4 + (port * 8));
+
+ while (len--) {
+ *(u8 *)img++ = data & 0xff;
+ data >>= 8;
+ }
+ }
}
static void
@@ -64,6 +74,8 @@ gm200_flcn_pio_dmem_wr(struct nvkm_falcon *falcon, u8 port, const u8 *img, int l
img += 4;
len -= 4;
}
+
+ WARN_ON(len);
}
static void
@@ -74,7 +86,7 @@ gm200_flcn_pio_dmem_wr_init(struct nvkm_falcon *falcon, u8 port, bool sec, u32 d
const struct nvkm_falcon_func_pio
gm200_flcn_dmem_pio = {
- .min = 4,
+ .min = 1,
.max = 0x100,
.wr_init = gm200_flcn_pio_dmem_wr_init,
.wr = gm200_flcn_pio_dmem_wr,
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
index a72403777329..2ed04da3621d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/gm20b.c
@@ -225,7 +225,7 @@ gm20b_pmu_init(struct nvkm_pmu *pmu)
pmu->initmsg_received = false;
- nvkm_falcon_load_dmem(falcon, , addr_args, sizeof(args), 0);
+ nvkm_falcon_pio_wr(falcon, (u8 *), 0, 0, DMEM, addr_args, sizeof(args), 0, false);
nvkm_falcon_start(falcon);
return 0;
}
--
2.35.1
Re: [PATCH drm-next 05/14] drm/nouveau: new VM_BIND uapi interfaces
On 1/27/23 22:09, Danilo Krummrich wrote: On 1/27/23 16:17, Christian König wrote: Am 27.01.23 um 15:44 schrieb Danilo Krummrich: [SNIP] What you want is one component for tracking the VA allocations (drm_mm based) and a different component/interface for tracking the VA mappings (probably rb tree based). That's what the GPUVA manager is doing. There are gpuva_regions which correspond to VA allocations and gpuvas which represent the mappings. Both are tracked separately (currently both with a separate drm_mm, though). However, the GPUVA manager needs to take regions into account when dealing with mappings to make sure the GPUVA manager doesn't propose drivers to merge over region boundaries. Speaking from userspace PoV, the kernel wouldn't merge mappings from different VKBuffer objects even if they're virtually and physically contiguous. That are two completely different things and shouldn't be handled in a single component. They are different things, but they're related in a way that for handling the mappings (in particular merging and sparse) the GPUVA manager needs to know the VA allocation (or region) boundaries. I have the feeling there might be a misunderstanding. Userspace is in charge to actually allocate a portion of VA space and manage it. The GPUVA manager just needs to know about those VA space allocations and hence keeps track of them. The GPUVA manager is not meant to be an allocator in the sense of finding and providing a hole for a given request. Maybe the non-ideal choice of using drm_mm was implying something else. Uff, well long story short that doesn't even remotely match the requirements. This way the GPUVA manager won't be usable for a whole bunch of use cases. What we have are mappings which say X needs to point to Y with this and hw dependent flags. The whole idea of having ranges is not going to fly. Neither with AMD GPUs and I strongly think not with Intels XA either. A range in the sense of the GPUVA manager simply represents a VA space allocation (which in case of Nouveau is taken in userspace). Userspace allocates the portion of VA space and lets the kernel know about it. The current implementation needs that for the named reasons. So, I think there is no reason why this would work with one GPU, but not with another. It's just part of the design choice of the manager. And I'm absolutely happy to discuss the details of the manager implementation though. We should probably talk about the design of the GPUVA manager once more when this should be applicable to all GPU drivers. That's what I try to figure out with this RFC, how to make it appicable for all GPU drivers, so I'm happy to discuss this. :-) Yeah, that was really good idea :) That proposal here is really far away from the actual requirements. And those are the ones I'm looking for. Do you mind sharing the requirements for amdgpu in particular? For sparse residency the kernel also needs to know the region boundaries to make sure that it keeps sparse mappings around. What? When userspace creates a new VKBuffer with the VK_BUFFER_CREATE_SPARSE_BINDING_BIT the kernel may need to create sparse mappings in order to ensure that using this buffer without any memory backed mappings doesn't fault the GPU. Currently, the implementation does this the following way: 1. Userspace creates a new VKBuffer and hence allocates a portion of the VA space for it. It calls into the kernel indicating the new VA space region and the fact that the region is sparse. 2. The kernel picks up the region and stores it in the GPUVA manager, the driver creates the corresponding sparse mappings / page table entries. 3. Userspace might ask the driver to create a couple of memory backed mappings for this particular VA region. The GPUVA manager stores the mapping parameters, the driver creates the corresponding page table entries. 4. Userspace might ask to unmap all the memory backed mappings from this particular VA region. The GPUVA manager removes the mapping parameters, the driver cleans up the corresponding page table entries. However, the driver also needs to re-create the sparse mappings, since it's a sparse buffer, hence it needs to know the boundaries of the region it needs to create the sparse mappings in. Again, this is not how things are working. First of all the kernel absolutely should *NOT* know about those regions. What we have inside the kernel is the information what happens if an address X is accessed. On AMD HW this can be: 1. Route to the PCIe bus because the mapped BO is stored in system memory. 2. Route to the internal MC because the mapped BO is stored in local memory. 3. Route to other GPUs in the same hive. 4. Route to some doorbell to kick of other work. ... x. Ignore write, return 0 on reads (this is what is used for sparse mappings). x+1. Trigger a recoverable page fault. This is used for things like SVA. x+2.
[PATCH] drm/amd: Optimize some memory initializations
Instead of zeroing some memory and then copying data in part or all of it, use memcpy_and_pad(). This avoids writing some memory twice and should save a few cycles. Signed-off-by: Christophe JAILLET --- drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 11 --- drivers/gpu/drm/amd/amdgpu/psp_v13_0.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c | 8 ++-- 3 files changed, 8 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c index a8391f269cd0..5e69693a5cc4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c @@ -613,9 +613,8 @@ psp_cmd_submit_buf(struct psp_context *psp, if (!drm_dev_enter(adev_to_drm(psp->adev), )) return 0; - memset(psp->cmd_buf_mem, 0, PSP_CMD_BUFFER_SIZE); - - memcpy(psp->cmd_buf_mem, cmd, sizeof(struct psp_gfx_cmd_resp)); + memcpy_and_pad(psp->cmd_buf_mem, PSP_CMD_BUFFER_SIZE, cmd, + sizeof(struct psp_gfx_cmd_resp), 0); index = atomic_inc_return(>fence_value); ret = psp_ring_cmd_submit(psp, psp->cmd_buf_mc_addr, fence_mc_addr, index); @@ -947,8 +946,7 @@ static int psp_rl_load(struct amdgpu_device *adev) cmd = acquire_psp_cmd_buf(psp); - memset(psp->fw_pri_buf, 0, PSP_1_MEG); - memcpy(psp->fw_pri_buf, psp->rl.start_addr, psp->rl.size_bytes); + memcpy_and_pad(psp->fw_pri_buf, PSP_1_MEG, psp->rl.start_addr, psp->rl.size_bytes, 0); cmd->cmd_id = GFX_CMD_ID_LOAD_IP_FW; cmd->cmd.cmd_load_ip_fw.fw_phy_addr_lo = lower_32_bits(psp->fw_pri_mc_addr); @@ -3479,8 +3477,7 @@ void psp_copy_fw(struct psp_context *psp, uint8_t *start_addr, uint32_t bin_size if (!drm_dev_enter(adev_to_drm(psp->adev), )) return; - memset(psp->fw_pri_buf, 0, PSP_1_MEG); - memcpy(psp->fw_pri_buf, start_addr, bin_size); + memcpy_and_pad(psp->fw_pri_buf, PSP_1_MEG, start_addr, bin_size, 0); drm_dev_exit(idx); } diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c b/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c index d62fcc77af95..79733ec4ffab 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v13_0.c @@ -168,10 +168,8 @@ static int psp_v13_0_bootloader_load_component(struct psp_context *psp, if (ret) return ret; - memset(psp->fw_pri_buf, 0, PSP_1_MEG); - /* Copy PSP KDB binary to memory */ - memcpy(psp->fw_pri_buf, bin_desc->start_addr, bin_desc->size_bytes); + memcpy_and_pad(psp->fw_pri_buf, PSP_1_MEG, bin_desc->start_addr, bin_desc->size_bytes, 0); /* Provide the PSP KDB to bootloader */ WREG32_SOC15(MP0, 0, regMP0_SMN_C2PMSG_36, @@ -237,10 +235,8 @@ static int psp_v13_0_bootloader_load_sos(struct psp_context *psp) if (ret) return ret; - memset(psp->fw_pri_buf, 0, PSP_1_MEG); - /* Copy Secure OS binary to PSP memory */ - memcpy(psp->fw_pri_buf, psp->sos.start_addr, psp->sos.size_bytes); + memcpy_and_pad(psp->fw_pri_buf, PSP_1_MEG, psp->sos.start_addr, psp->sos.size_bytes, 0); /* Provide the PSP secure OS to bootloader */ WREG32_SOC15(MP0, 0, regMP0_SMN_C2PMSG_36, diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c b/drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c index d5ba58eba3e2..c73415b09e85 100644 --- a/drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c +++ b/drivers/gpu/drm/amd/amdgpu/psp_v13_0_4.c @@ -107,10 +107,8 @@ static int psp_v13_0_4_bootloader_load_component(struct psp_context*psp, if (ret) return ret; - memset(psp->fw_pri_buf, 0, PSP_1_MEG); - /* Copy PSP KDB binary to memory */ - memcpy(psp->fw_pri_buf, bin_desc->start_addr, bin_desc->size_bytes); + memcpy_and_pad(psp->fw_pri_buf, PSP_1_MEG, bin_desc->start_addr, bin_desc->size_bytes, 0); /* Provide the PSP KDB to bootloader */ WREG32_SOC15(MP0, 0, regMP0_SMN_C2PMSG_36, @@ -170,10 +168,8 @@ static int psp_v13_0_4_bootloader_load_sos(struct psp_context *psp) if (ret) return ret; - memset(psp->fw_pri_buf, 0, PSP_1_MEG); - /* Copy Secure OS binary to PSP memory */ - memcpy(psp->fw_pri_buf, psp->sos.start_addr, psp->sos.size_bytes); + memcpy_and_pad(psp->fw_pri_buf, PSP_1_MEG, psp->sos.start_addr, psp->sos.size_bytes, 0); /* Provide the PSP secure OS to bootloader */ WREG32_SOC15(MP0, 0, regMP0_SMN_C2PMSG_36, -- 2.34.1
[PATCH v2] dt-bindings: display: bridge: sil, sii8620: convert to dtschema
Convert the Silicon Image SiI8620 HDMI/MHL bridge bindings to DT schema.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Require also port@1 (Laurent)
---
.../bindings/display/bridge/sil,sii8620.yaml | 108 ++
.../bindings/display/bridge/sil-sii8620.txt | 33 --
2 files changed, 108 insertions(+), 33 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
delete mode 100644
Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
diff --git a/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
new file mode 100644
index ..6d1a36b76fcb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/sil,sii8620.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/sil,sii8620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Silicon Image SiI8620 HDMI/MHL bridge
+
+maintainers:
+ - Krzysztof Kozlowski
+
+properties:
+ compatible:
+const: sil,sii8620
+
+ reg:
+maxItems: 1
+
+ clocks:
+maxItems: 1
+
+ clock-names:
+items:
+ - const: xtal
+
+ cvcc10-supply:
+description: Digital Core Supply Voltage (1.0V)
+
+ interrupts:
+maxItems: 1
+
+ iovcc18-supply:
+description: I/O Supply Voltage (1.8V)
+
+ reset-gpios:
+maxItems: 1
+
+ ports:
+$ref: /schemas/graph.yaml#/properties/ports
+unevaluatedProperties: false
+
+properties:
+ port@0:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ Video port for HDMI (encoder) input
+
+ port@1:
+$ref: /schemas/graph.yaml#/properties/port
+description:
+ MHL to connector port
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - cvcc10-supply
+ - interrupts
+ - iovcc18-supply
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+#include
+#include
+
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+bridge@39 {
+reg = <0x39>;
+compatible = "sil,sii8620";
+cvcc10-supply = <_reg>;
+iovcc18-supply = <_reg>;
+interrupt-parent = <>;
+interrupts = <2 IRQ_TYPE_LEVEL_HIGH>;
+reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+clocks = <_system_controller 0>;
+clock-names = "xtal";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+mhl_to_hdmi: endpoint {
+remote-endpoint = <_to_mhl>;
+};
+};
+
+port@1 {
+reg = <1>;
+mhl_to_musb_con: endpoint {
+remote-endpoint = <_con_to_mhl>;
+};
+};
+};
+};
+};
diff --git a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
b/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
deleted file mode 100644
index b05052f7d62f..
--- a/Documentation/devicetree/bindings/display/bridge/sil-sii8620.txt
+++ /dev/null
@@ -1,33 +0,0 @@
-Silicon Image SiI8620 HDMI/MHL bridge bindings
-
-Required properties:
- - compatible: "sil,sii8620"
- - reg: i2c address of the bridge
- - cvcc10-supply: Digital Core Supply Voltage (1.0V)
- - iovcc18-supply: I/O Supply Voltage (1.8V)
- - interrupts: interrupt specifier of INT pin
- - reset-gpios: gpio specifier of RESET pin
- - clocks, clock-names: specification and name of "xtal" clock
- - video interfaces: Device node can contain video interface port
- node for HDMI encoder according to [1].
-
-[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
- sii8620@39 {
- reg = <0x39>;
- compatible = "sil,sii8620";
- cvcc10-supply = <_reg>;
- iovcc18-supply = <_reg>;
- interrupt-parent = <>;
- interrupts = <2 0>;
- reset-gpio = < 0 0>;
- clocks = <_system_controller 0>;
- clock-names = "xtal";
-
- port {
- mhl_to_hdmi: endpoint {
- remote-endpoint = <_to_mhl>;
- };
- };
- };
--
2.34.1
[PATCH] drm/amdgpu: Fix a typo ("boradcast")
Spell it as "broadcast". Signed-off-by: Jonathan Neuschäfer --- drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c index b991609f46c10..5dfab8021 100644 --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c @@ -94,7 +94,7 @@ static void df_v1_7_update_medium_grain_clock_gating(struct amdgpu_device *adev, WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp); } - /* Exit boradcast mode */ + /* Exit broadcast mode */ adev->df.funcs->enable_broadcast_mode(adev, false); } -- 2.39.0
[PATCHv2] fbcon: Check font dimension limits
blit_x and blit_y are u32, so fbcon currently cannot support fonts
larger than 32x32.
The 32x32 case also needs shifting an unsigned int, to properly set bit
31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
as reported on:
http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
Kernel Branch: 6.2.0-rc5-next-20230124
Kernel config:
https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
Reproducer:
https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing
Reported-by: Sanan Hasanov
Signed-off-by: Samuel Thibault
Fixes: 2d2699d98492 ("fbcon: font setting should check limitation of driver")
Cc: sta...@vger.kernel.org
---
v1 -> v2:
- Use BIT macro instead of fixing bit test by hand.
- Add Fixes and Cc: stable headers.
Index: linux-6.0/drivers/video/fbdev/core/fbcon.c
===
--- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c
+++ linux-6.0/drivers/video/fbdev/core/fbcon.c
@@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data
h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres))
return -EINVAL;
+ if (font->width > 32 || font->height > 32)
+ return -EINVAL;
+
/* Make sure drawing engine can handle the font */
- if (!(info->pixmap.blit_x & (1 << (font->width - 1))) ||
- !(info->pixmap.blit_y & (1 << (font->height - 1
+ if (!(info->pixmap.blit_x & BIT(font->width - 1)) ||
+ !(info->pixmap.blit_y & BIT(font->height - 1)))
return -EINVAL;
/* Make sure driver can handle the font length */
Re: [PATCH] fbcon: Check font dimension limits
Jiri Slaby, le jeu. 26 janv. 2023 10:02:55 +0100, a ecrit: > On 26. 01. 23, 1:49, Samuel Thibault wrote: > > Index: linux-6.0/drivers/video/fbdev/core/fbcon.c > > === > > --- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c > > +++ linux-6.0/drivers/video/fbdev/core/fbcon.c > > @@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data > > h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres)) > > return -EINVAL; > > + if (font->width > 32 || font->height > 32) > > + return -EINVAL; > > + > > /* Make sure drawing engine can handle the font */ > > - if (!(info->pixmap.blit_x & (1 << (font->width - 1))) || > > - !(info->pixmap.blit_y & (1 << (font->height - 1 > > + if (!(info->pixmap.blit_x & (1U << (font->width - 1))) || > > + !(info->pixmap.blit_y & (1U << (font->height - 1 > > So use BIT() properly then? That should be used in all these shifts anyway. > Exactly to avoid UB. Right, I'll use that in next version. Samuel
Re: [PATCH] fbcon: Check font dimension limits
Greg KH, le jeu. 26 janv. 2023 08:43:02 +0100, a ecrit: > On Thu, Jan 26, 2023 at 01:49:12AM +0100, Samuel Thibault wrote: > > blit_x and blit_y are uint32_t, so fbcon currently cannot support fonts > > larger than 32x32. > > "u32" you mean, right? Right :) > > The 32x32 case also needs shifting an unsigned int, to properly set bit > > 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font", > > as reported on > > > > http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com > > Odd blank line? Not sure what you mean? I found it easier to read to put a blank line between the text and the references. > > Kernel Branch: 6.2.0-rc5-next-20230124 > > Kernel config: > > https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing > > Reproducer: > > https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing > > What are all of these lines for? They provide the references that were set in the original report http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com Arguably the "branch" and "config" are not that useful since the bug has been there for more than a dozen years, but notably the "Reproducer" is useful to provide a userland program that triggers the UB. > > Reported-by: Sanan Hasanov > > Signed-off-by: Samuel Thibault > > What commit id does this fix? I though it was there forever, but it seems the check was added in 2007, so I'll add it in next version. > Should it go to stable kernels? Yes. I added stable in Cc of the mail but missed adding it in the text, I will add it. > > Index: linux-6.0/drivers/video/fbdev/core/fbcon.c > > === > > --- linux-6.0.orig/drivers/video/fbdev/core/fbcon.c > > +++ linux-6.0/drivers/video/fbdev/core/fbcon.c > > @@ -2489,9 +2489,12 @@ static int fbcon_set_font(struct vc_data > > h > FBCON_SWAP(info->var.rotate, info->var.yres, info->var.xres)) > > return -EINVAL; > > > > + if (font->width > 32 || font->height > 32) > > + return -EINVAL; > > + > > /* Make sure drawing engine can handle the font */ > > - if (!(info->pixmap.blit_x & (1 << (font->width - 1))) || > > - !(info->pixmap.blit_y & (1 << (font->height - 1 > > + if (!(info->pixmap.blit_x & (1U << (font->width - 1))) || > > + !(info->pixmap.blit_y & (1U << (font->height - 1 > > Are you sure this is still needed with the above check added? If so, > why? What is the difference in the compiled code? As mentioned by Jiri, yes in the 32 case it's needed otherwise it's UB. Samuel
Re: [PATCH 1/3] dt-bindings: display: panel: sitronix,st7701: Add another panel
On 29/01/2023 15:31, Maya Matuszczyk wrote: > Add compatible for 854x480 Elida KD50T048A panel, found in Odroid Go Super > and Odroid Go Ultra Please wrap commit message according to Linux coding style / submission process (neither too early nor over the limit): https://elixir.bootlin.com/linux/v5.18-rc4/source/Documentation/process/submitting-patches.rst#L586 > > Signed-off-by: Maya Matuszczyk > --- > .../devicetree/bindings/display/panel/sitronix,st7701.yaml | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml > b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml > index 34d5e20c6cb3..dbc92c4e26ed 100644 > --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml > +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml > @@ -29,6 +29,7 @@ properties: >- enum: >- densitron,dmt028vghmcmi-1a >- techstar,ts8550b > + - elida,kd50t048a Alphabetical order, please. Best regards, Krzysztof
[PATCH 2/3] drm: panel: Add Elida KD50T048A to Sitronix ST7701 driver
Add KD50T048A MIPI-DSI panel, which is based on ST7701 chip.
Not sure what else to add to this commit message.
Signed-off-by: Maya Matuszczyk
---
drivers/gpu/drm/panel/panel-sitronix-st7701.c | 125 ++
1 file changed, 125 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7701.c
b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
index 0b8cf65172ff..660c3f435008 100644
--- a/drivers/gpu/drm/panel/panel-sitronix-st7701.c
+++ b/drivers/gpu/drm/panel/panel-sitronix-st7701.c
@@ -397,6 +397,31 @@ static void dmt028vghmcmi_1a_gip_sequence(struct st7701
*st7701)
ST7701_DSI(st7701, 0x3A, 0x70);
}
+static void kd50t048a_gip_sequence(struct st7701 *st7701)
+{
+ /**
+* ST7701_SPEC_V1.2 is unable to provide enough information above this
+* specific command sequence, so grab the same from vendor BSP driver.
+*/
+ ST7701_DSI(st7701, 0xE0, 0x00, 0x00, 0x02);
+ ST7701_DSI(st7701, 0xE1, 0x08, 0x00, 0x0A, 0x00, 0x07, 0x00, 0x09,
+ 0x00, 0x00, 0x33, 0x33);
+ ST7701_DSI(st7701, 0xE2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00);
+ ST7701_DSI(st7701, 0xE3, 0x00, 0x00, 0x33, 0x33);
+ ST7701_DSI(st7701, 0xE4, 0x44, 0x44);
+ ST7701_DSI(st7701, 0xE5, 0x0E, 0x60, 0xA0, 0xA0, 0x10, 0x60, 0xA0,
+ 0xA0, 0x0A, 0x60, 0xA0, 0xA0, 0x0C, 0x60, 0xA0, 0xA0);
+ ST7701_DSI(st7701, 0xE6, 0x00, 0x00, 0x33, 0x33);
+ ST7701_DSI(st7701, 0xE7, 0x44, 0x44);
+ ST7701_DSI(st7701, 0xE8, 0x0D, 0x60, 0xA0, 0xA0, 0x0F, 0x60, 0xA0,
+ 0xA0, 0x09, 0x60, 0xA0, 0xA0, 0x0B, 0x60, 0xA0, 0xA0);
+ ST7701_DSI(st7701, 0xEB, 0x02, 0x01, 0xE4, 0xE4, 0x44, 0x00, 0x40);
+ ST7701_DSI(st7701, 0xEC, 0x02, 0x01);
+ ST7701_DSI(st7701, 0xED, 0xAB, 0x89, 0x76, 0x54, 0x01, 0xFF, 0xFF,
+ 0xFF, 0xFF, 0xFF, 0xFF, 0x10, 0x45, 0x67, 0x98, 0xBA);
+}
+
static int st7701_prepare(struct drm_panel *panel)
{
struct st7701 *st7701 = panel_to_st7701(panel);
@@ -700,6 +725,105 @@ static const struct st7701_panel_desc
dmt028vghmcmi_1a_desc = {
.gip_sequence = dmt028vghmcmi_1a_gip_sequence,
};
+static const struct drm_display_mode kd50t048a_mode = {
+ .clock = 27500,
+
+ .hdisplay = 480,
+ .hsync_start= 480 + 2,
+ .hsync_end = 480 + 2 + 10,
+ .htotal = 480 + 2 + 10 + 2,
+
+ .vdisplay = 854, // was: 854 12 2 60
+ .vsync_start= 854 + 2,
+ .vsync_end = 854 + 2 + 2,
+ .vtotal = 854 + 2 + 2 + 17,
+
+ .width_mm = 69,
+ .height_mm = 139,
+
+ .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+};
+
+static const struct st7701_panel_desc kd50t048a_desc = {
+ .mode = _mode,
+ .lanes = 2,
+ .format = MIPI_DSI_FMT_RGB888,
+ .panel_sleep_delay = 0,
+
+ .pv_gamma = {
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC0_MASK, 0),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC4_MASK, 0xd),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC8_MASK, 0x14),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC16_MASK, 0xd),
+
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC24_MASK, 0x10),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC52_MASK, 0x5),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC80_MASK, 0x2),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC108_MASK, 0x8),
+
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC147_MASK, 0x8),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC175_MASK, 0x1e),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC203_MASK, 0x5),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC231_MASK, 0x13),
+
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC239_MASK, 0x11),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 2) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC247_MASK, 0x23),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC251_MASK, 0x29),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC255_MASK, 0x18)
+ },
+ .nv_gamma = {
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC0_MASK, 0),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC4_MASK, 0xc),
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_AJ_MASK, 0) |
+ CFIELD_PREP(DSI_CMD2_BK0_GAMCTRL_VC8_MASK, 0x14),
+
[PATCH 3/3] arm64: dts: rockchip: Add display support to Odroid Go Super
Note that orientation property in ST7701 driver is currently missing,
And that ST7701 panel driver uses different regulator names compared to
driver for Elida KD35T133 driver.
Signed-off-by: Maya Matuszczyk
---
arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts
b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts
index 842efbaf1a6a..1b9769ccfdeb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3326-odroid-go3.dts
@@ -142,7 +142,9 @@ button-sw22 {
};
_display {
- status = "disabled";
+ compatible = "elida,kd50t048a", "sitronix,st7701";
+ reset-gpios = < RK_PC0 GPIO_ACTIVE_HIGH>;
+ VCC-supply = <_lcd>;
};
_charger {
--
2.39.1
[PATCH 1/3] dt-bindings: display: panel: sitronix, st7701: Add another panel
Add compatible for 854x480 Elida KD50T048A panel, found in Odroid Go Super and Odroid Go Ultra Signed-off-by: Maya Matuszczyk --- .../devicetree/bindings/display/panel/sitronix,st7701.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml index 34d5e20c6cb3..dbc92c4e26ed 100644 --- a/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml +++ b/Documentation/devicetree/bindings/display/panel/sitronix,st7701.yaml @@ -29,6 +29,7 @@ properties: - enum: - densitron,dmt028vghmcmi-1a - techstar,ts8550b + - elida,kd50t048a - const: sitronix,st7701 reg: -- 2.39.1
[PATCH 0/3] Add internal display support to Odroid Go Super
This patch series introduces internal display to Odroid Go Super, which shares panel with Odroid Go Ultra and several clone devices. Maya Matuszczyk (3): dt-bindings: display: panel: sitronix,st7701: Add Elida KD50T048A Panel drm: panel: Add Elida KD50T048A to Sitronix ST7701 driver arm64: dts: rockchip: Add display support to Odroid Go Super .../display/panel/sitronix,st7701.yaml| 1 + .../boot/dts/rockchip/rk3326-odroid-go3.dts | 4 +- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 125 ++ 3 files changed, 129 insertions(+), 1 deletion(-) -- 2.39.1
Re: (subset) [PATCH V12 0/4] drm/panel: Add Magnachip D53E6EA8966 Panel Controller
On Mon, 23 Jan 2023 09:45:59 -0600, Chris Morgan wrote: > From: Chris Morgan > > Add the Magnachip D53E6EA8966 panel IC controller for display panels > such as the Samsung AMS495QA01 panel as found on the Anbernic RG503. > This panel uses DSI to receive video signals, but 3-wire SPI to receive > command signals using DBI. > > [...] Applied, thanks! [4/4] arm64: dts: rockchip: add display to RG503 commit: 97ce9f36631dafd6daaab0c06a6a48b4301199b5 Best regards, -- Heiko Stuebner
Re: (subset) [PATCH v3 0/6] drm/rockchip: vop2: add support for the rgb output block
On Tue, 24 Jan 2023 06:47:00 +0100, Michael Riesch wrote: > This series adds support for the RGB output block that can be found in the > Rockchip Video Output Processor (VOP) 2. Version 2 of this series > incorporates the feedback by Dan Carpenter and Sascha Hauer. Version 3 > fixes a dumb mistake pointed out by Sascha :-) Thanks for your comments! > > Patches 1-4 clean up the code and make it more general. > > [...] Applied, thanks! [6/6] arm64: dts: rockchip: add pinctrls for 16-bit/18-bit rgb interface to rk356x commit: 381b6d432f6eb00e1faff763f55e67519af9fa23 Best regards, -- Heiko Stuebner
Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"
On Fri, Jan 27, 2023 at 03:02:41PM +, Limonciello, Mario wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Linux kernel regression tracking (Thorsten Leemhuis)
> >
> > Sent: Friday, January 27, 2023 03:15
> > To: Greg KH ; Limonciello, Mario
> >
> > Cc: dri-devel@lists.freedesktop.org; sta...@vger.kernel.org;
> > stanislav.lisovs...@intel.com; Zuo, Jerry ; amd-
> > g...@lists.freedesktop.org; Lin, Wayne ; Guenter
> > Roeck ; bske...@redhat.com
> > Subject: Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into
> > the atomic state"
> >
> > On 27.01.23 08:39, Greg KH wrote:
> > > On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote:
> > >> On 1/20/2023 11:46, Guenter Roeck wrote:
> > >>> On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
> > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> >
> > [Why]
> > Changes cause regression on amdgpu mst.
> > E.g.
> > In fill_dc_mst_payload_table_from_drm(), amdgpu expects to
> > add/remove payload
> > one by one and call fill_dc_mst_payload_table_from_drm() to update
> > the HW
> > maintained payload table. But previous change tries to go through all
> > the
> > payloads in mst_state and update amdpug hw maintained table in once
> > everytime
> > driver only tries to add/remove a specific payload stream only. The
> > newly
> > design idea conflicts with the implementation in amdgpu nowadays.
> >
> > [How]
> > Revert this patch first. After addressing all regression problems
> > caused
> > by
> > this previous patch, will add it back and adjust it.
> > >>>
> > >>> Has there been any progress on this revert, or on fixing the underlying
> > >>> problem ?
> > >>>
> > >>> Thanks,
> > >>> Guenter
> > >>
> > >> Hi Guenter,
> > >>
> > >> Wayne is OOO for CNY, but let me update you.
> > >>
> > >> Harry has sent out this series which is a collection of proper fixes.
> > >> https://patchwork.freedesktop.org/series/113125/
> > >>
> > >> Once that's reviewed and accepted, 4 of them are applicable for 6.1.
> > >
> > > Any hint on when those will be reviewed and accepted? patchwork
> > doesn't
> > > show any activity on them, or at least I can't figure it out...
> >
> > I didn't look closer (hence please correct me if I'm wrong), but the
> > core changes afaics are in the DRM pull airlied send a few hours ago to
> > Linus (note the "amdgpu […] DP MST fixes" line):
> >
> > https://lore.kernel.org/all/CAPM%3D9tzuu4xnx6T5v7sKsK%2BA5HEaPOc1ie
> > myznsyqzgztj%3d...@mail.gmail.com/
>
> That's right. There are 4 commits in that PR with the appropriate stable tags
> that should fix the majority of the MST issues introduced in 6.1 by
> 4d07b0bc40340
> ("drm/display/dp_mst: Move all payload info into the atomic state"):
>
> drm/amdgpu/display/mst: Fix mst_state->pbn_div and slot count
> assignments
> drm/amdgpu/display/mst: limit payload to be updated one by one
> drm/amdgpu/display/mst: update mst_mgr relevant variable when long HPD
> drm/display/dp_mst: Correct the kref of port.
>
> There will be follow ups for any remaining corner cases.
Great, thanks for this, all are now queued up in the 6.1.y queue.
greg k-h
[PATCH] dma-buf: Add "dma-buf" to title of documentation
To make it easier to find the dma-buf documentation when looking through tables-of-contents etc., put the name "dma-buf" in the title. Signed-off-by: Jonathan Neuschäfer --- Documentation/driver-api/dma-buf.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 622b8156d2127..61b6f42ed0f18 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -1,5 +1,5 @@ -Buffer Sharing and Synchronization -== +Buffer Sharing and Synchronization (dma-buf) + The dma-buf subsystem provides the framework for sharing buffers for hardware (DMA) access across multiple device drivers and subsystems, and -- 2.39.0
Re: [PATCH 1/2] dt-bindings: display: bridge: Add NXP i.MX93 parallel display format configuration
On 28/01/2023 04:47, Liu Ying wrote: > NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which > configures parallel display format by using the "PARALLEL_DISP_FORMAT" > field. Add device tree bindings for the display format configuration. > > Signed-off-by: Liu Ying > --- > .../display/bridge/nxp,imx93-pdfc.yaml| 78 +++ > 1 file changed, 78 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml > > diff --git > a/Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml > b/Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml > new file mode 100644 > index ..a84bfb46b01d > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/bridge/nxp,imx93-pdfc.yaml > @@ -0,0 +1,78 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/bridge/nxp,imx93-pdfc.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: NXP i.MX93 Parallel Display Format Configuration > + > +maintainers: > + - Liu Ying > + > +description: | > + The i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which > + configures parallel display format by using the "PARALLEL_DISP_FORMAT" > + field. > + > +properties: > + compatible: > +const: nxp,imx93-pdfc Based on description, I have doubts this is a separate bridge device. Why this is not part of display driver/bindings? We do not create usually devices for single registers, because they are not a devices. Devices are a bit more complex - have some pin inputs/outputs, not a register only. Of course there are exception, but this one does not look like one. > + > + reg: > +maxItems: 1 Your driver tells different story: syscon_node_to_regmap(dev->of_node->parent); (which also points to fact this is not a separate device) Best regards, Krzysztof
Re: [PATCH v3] drm/mediatek: Add support for AR30 and BA30
Hi Justin,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm/drm-next drm-exynos/exynos-drm-next
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip
linus/master v6.2-rc5]
[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#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Justin-Green/drm-mediatek-Add-support-for-AR30-and-BA30/20230128-112134
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230127230123.941930-1-greenjustin%40google.com
patch subject: [PATCH v3] drm/mediatek: Add support for AR30 and BA30
config: arm-allyesconfig
(https://download.01.org/0day-ci/archive/20230129/202301291906.az5nhf9w-...@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0
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/intel-lab-lkp/linux/commit/c32525cf66e7bbf4e798aef3aafbf88dee5d049c
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Justin-Green/drm-mediatek-Add-support-for-AR30-and-BA30/20230128-112134
git checkout c32525cf66e7bbf4e798aef3aafbf88dee5d049c
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arm olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arm SHELL=/bin/bash drivers/gpu/drm/mediatek/
sound/soc/samsung/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from drivers/gpu/drm/mediatek/mtk_drm_crtc.h:10,
from drivers/gpu/drm/mediatek/mtk_disp_aal.c:15:
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h: In function
'mtk_ddp_comp_supports_10bit':
>> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h:159:35: warning: returning 'int
>> (*)(struct device *)' from a function with return type 'int' makes integer
>> from pointer without a cast [-Wint-conversion]
159 | return comp->funcs->supports_10bit;
|~~~^~~~
vim +159 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
154
155 static inline
156 int mtk_ddp_comp_supports_10bit(struct mtk_ddp_comp *comp)
157 {
158 if (comp->funcs && comp->funcs->supports_10bit)
> 159 return comp->funcs->supports_10bit;
160
161 return 0;
162 }
163
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[PATCH v2] fbdev: Fix invalid page access after closing deferred I/O devices
When a fbdev with deferred I/O is once opened and closed, the dirty
pages still remain queued in the pageref list, and eventually later
those may be processed in the delayed work. This may lead to a
corruption of pages, hitting an Oops.
This patch makes sure to cancel the delayed work and clean up the
pageref list at closing the device for addressing the bug. A part of
the cleanup code is factored out as a new helper function that is
called from the common fb_release().
Reviewed-by: Patrik Jakobsson
Cc:
Signed-off-by: Takashi Iwai
---
v1->v2: Fix build error without CONFIG_FB_DEFERRED_IO
drivers/video/fbdev/core/fb_defio.c | 10 +-
drivers/video/fbdev/core/fbmem.c| 4
include/linux/fb.h | 1 +
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fb_defio.c
b/drivers/video/fbdev/core/fb_defio.c
index c730253ab85c..583cbcf09446 100644
--- a/drivers/video/fbdev/core/fb_defio.c
+++ b/drivers/video/fbdev/core/fb_defio.c
@@ -313,7 +313,7 @@ void fb_deferred_io_open(struct fb_info *info,
}
EXPORT_SYMBOL_GPL(fb_deferred_io_open);
-void fb_deferred_io_cleanup(struct fb_info *info)
+void fb_deferred_io_release(struct fb_info *info)
{
struct fb_deferred_io *fbdefio = info->fbdefio;
struct page *page;
@@ -327,6 +327,14 @@ void fb_deferred_io_cleanup(struct fb_info *info)
page = fb_deferred_io_page(info, i);
page->mapping = NULL;
}
+}
+EXPORT_SYMBOL_GPL(fb_deferred_io_release);
+
+void fb_deferred_io_cleanup(struct fb_info *info)
+{
+ struct fb_deferred_io *fbdefio = info->fbdefio;
+
+ fb_deferred_io_release(info);
kvfree(info->pagerefs);
mutex_destroy(>lock);
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 3a6c8458eb8d..ab3545a00abc 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1454,6 +1454,10 @@ __releases(>lock)
struct fb_info * const info = file->private_data;
lock_fb_info(info);
+#if IS_ENABLED(CONFIG_FB_DEFERRED_IO)
+ if (info->fbdefio)
+ fb_deferred_io_release(info);
+#endif
if (info->fbops->fb_release)
info->fbops->fb_release(info,1);
module_put(info->fbops->owner);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 96b96323e9cb..73eb1f85ea8e 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -662,6 +662,7 @@ extern int fb_deferred_io_init(struct fb_info *info);
extern void fb_deferred_io_open(struct fb_info *info,
struct inode *inode,
struct file *file);
+extern void fb_deferred_io_release(struct fb_info *info);
extern void fb_deferred_io_cleanup(struct fb_info *info);
extern int fb_deferred_io_fsync(struct file *file, loff_t start,
loff_t end, int datasync);
--
2.35.3
Re: [vmwgfx] crash upon vmw_open_channel() when booting on Oracle VM VirtualBox
On 2023/01/29 15:00, Zack Rusin wrote: > On Sat, 2023-01-28 at 20:44 +0900, Tetsuo Handa wrote: >> Hello. >> >> I noticed that a kernel built with vmwgfx driver fails to boot a Linux guest >> on Oracle VM VirtualBox 7.0.4 on Windows 11 on DELL Inspiron 14 5420. >> I didn't notice this problem when I booted an older kernel on an older >> version >> of Oracle VM VirtualBox on Windows 8.1 on an older PC. >> >> The location that crashes is >> >> VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL, >> (protocol | GUESTMSG_FLAG_COOKIE), si, di, >> 0, >> VMW_HYPERVISOR_MAGIC, >> eax, ebx, ecx, edx, si, di); >> >> in vmw_open_channel(). It might be that some changes in VirtualBox side >> is conflicting with how VMware tries to test if the guest is VMware. >> How can I debug this problem? > > You'd have to figure out what exactly is the problem. I couldn't reproduce it > on > vmware hypervisors with your .config. This problem happens on not VMware hypervisors but VirtualBox hypervisors. > FWIW that code has been there and > hasn't been > changed in years. Oracle emulated svga device always had problems, was never > supported by vmwgfx and afaict is not maintained by Oracle so I'd strongly > suggest > that you switch to some other graphics device on virtualbox. Indeed, not selecting VMSVGA as Graphics Controller in the screen tab of display setting allowed me to boot the guest. The reason I built-in vmwgfx is that I want to reuse the same kernel configuration on multiple environments; syzbot uses a large kernel configuration that builts-in almost everything. > > In the meantime I think the attached patch should at least get you booting. > You can > give it a try and if it works I can push it sometime this week. Yes, this patch allowed me to boot the guest when selecting VMSVGA as Graphics Controller. Thank you.
