[PATCH linux-next] backlight: use sysfs_emit() to instead of scnprintf()
From: ye xingchen
Follow the advice of the Documentation/filesystems/sysfs.rst and show()
should only use sysfs_emit() or sysfs_emit_at() when formatting the
value to be returned to user space.
Signed-off-by: ye xingchen
---
drivers/video/backlight/lm3533_bl.c | 10 +-
drivers/video/backlight/lp855x_bl.c | 4 ++--
drivers/video/backlight/lp8788_bl.c | 2 +-
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/backlight/lm3533_bl.c
b/drivers/video/backlight/lm3533_bl.c
index 1df1b6643c0b..5e2ce9285245 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -66,7 +66,7 @@ static ssize_t show_id(struct device *dev,
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
- return scnprintf(buf, PAGE_SIZE, "%d\n", bl->id);
+ return sysfs_emit(buf, "%d\n", bl->id);
}
static ssize_t show_als_channel(struct device *dev,
@@ -75,7 +75,7 @@ static ssize_t show_als_channel(struct device *dev,
struct lm3533_bl *bl = dev_get_drvdata(dev);
unsigned channel = lm3533_bl_get_ctrlbank_id(bl);
- return scnprintf(buf, PAGE_SIZE, "%u\n", channel);
+ return sysfs_emit(buf, "%u\n", channel);
}
static ssize_t show_als_en(struct device *dev,
@@ -95,7 +95,7 @@ static ssize_t show_als_en(struct device *dev,
mask = 1 << (2 * ctrlbank);
enable = val & mask;
- return scnprintf(buf, PAGE_SIZE, "%d\n", enable);
+ return sysfs_emit(buf, "%d\n", enable);
}
static ssize_t store_als_en(struct device *dev,
@@ -147,7 +147,7 @@ static ssize_t show_linear(struct device *dev,
else
linear = 0;
- return scnprintf(buf, PAGE_SIZE, "%x\n", linear);
+ return sysfs_emit(buf, "%x\n", linear);
}
static ssize_t store_linear(struct device *dev,
@@ -190,7 +190,7 @@ static ssize_t show_pwm(struct device *dev,
if (ret)
return ret;
- return scnprintf(buf, PAGE_SIZE, "%u\n", val);
+ return sysfs_emit(buf, "%u\n", val);
}
static ssize_t store_pwm(struct device *dev,
diff --git a/drivers/video/backlight/lp855x_bl.c
b/drivers/video/backlight/lp855x_bl.c
index bd0bdeae23a4..fafc1a9e76ef 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -293,7 +293,7 @@ static ssize_t lp855x_get_chip_id(struct device *dev,
{
struct lp855x *lp = dev_get_drvdata(dev);
- return scnprintf(buf, PAGE_SIZE, "%s\n", lp->chipname);
+ return sysfs_emit(buf, "%s\n", lp->chipname);
}
static ssize_t lp855x_get_bl_ctl_mode(struct device *dev,
@@ -307,7 +307,7 @@ static ssize_t lp855x_get_bl_ctl_mode(struct device *dev,
else if (lp->mode == REGISTER_BASED)
strmode = "register based";
- return scnprintf(buf, PAGE_SIZE, "%s\n", strmode);
+ return sysfs_emit(buf, "%s\n", strmode);
}
static DEVICE_ATTR(chip_id, S_IRUGO, lp855x_get_chip_id, NULL);
diff --git a/drivers/video/backlight/lp8788_bl.c
b/drivers/video/backlight/lp8788_bl.c
index ba42f3fe0c73..00d79c0cfee9 100644
--- a/drivers/video/backlight/lp8788_bl.c
+++ b/drivers/video/backlight/lp8788_bl.c
@@ -240,7 +240,7 @@ static ssize_t lp8788_get_bl_ctl_mode(struct device *dev,
else
strmode = "Invalid mode";
- return scnprintf(buf, PAGE_SIZE, "%s\n", strmode);
+ return sysfs_emit(buf, "%s\n", strmode);
}
static DEVICE_ATTR(bl_ctl_mode, S_IRUGO, lp8788_get_bl_ctl_mode, NULL);
--
2.25.1
Re: [PATCH v2 6/8] drm/mipi-dbi: Support shadow-plane state
Am 03.12.22 um 17:11 schrieb Noralf Trønnes:
Den 02.12.2022 13.56, skrev Thomas Zimmermann:
Implement MIPI DBI planes with struct drm_shadow_plane_state, so that the
respective drivers can use the vmap'ed GEM-buffer memory. Implement state
helpers, the {begin,end}_fb_access helpers and wire up everything.
With this commit, MIPI DBI drivers can access the GEM object's memory
that is provided by shadow-plane state. The actual changes to drivers
are implemented separately.
v2:
* use shadow-plane state directly (Noralf)
Signed-off-by: Thomas Zimmermann
Tested-by: Javier Martinez Canillas
Tested-by: Noralf Trønnes # drm/tiny/mi0283qt
---
Reviewed-by: Noralf Trønnes
Thanks a lot.
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v8 06/14] drm: bridge: samsung-dsim: Handle proper DSI host initialization
On 02.12.22 15:55, Dave Stevenson wrote:
> Hi Marek
>
> On Fri, 2 Dec 2022 at 12:21, Marek Vasut wrote:
>>
>> On 12/2/22 11:52, Marek Szyprowski wrote:
>>> Hi,
>>>
>>> Sorry for delay, I was on a sick leave last 2 weeks.
>>>
>>> On 28.11.2022 15:43, Jagan Teki wrote:
,On Sat, Nov 26, 2022 at 3:44 AM Marek Vasut wrote:
> On 11/23/22 21:09, Jagan Teki wrote:
>> On Sat, Nov 19, 2022 at 7:45 PM Marek Vasut wrote:
>>> On 11/17/22 14:04, Marek Szyprowski wrote:
On 17.11.2022 05:58, Marek Vasut wrote:
> On 11/10/22 19:38, Jagan Teki wrote:
>> DSI host initialization handling in previous exynos dsi driver has
>> some pitfalls. It initializes the host during host transfer() hook
>> that is indeed not the desired call flow for I2C and any other DSI
>> configured downstream bridges.
>>
>> Host transfer() is usually triggered for downstream DSI panels or
>> bridges and I2C-configured-DSI bridges miss these host initialization
>> as these downstream bridges use bridge operations hooks like
>> pre_enable,
>> and enable in order to initialize or set up the host.
>>
>> This patch is trying to handle the host init handler to satisfy all
>> downstream panels and bridges. Added the DSIM_STATE_REINITIALIZED
>> state
>> flag to ensure that host init is also done on first cmd transfer,
>> this
>> helps existing DSI panels work on exynos platform (form Marek
>> Szyprowski).
>>
>> v8, v7, v6, v5:
>> * none
>>
>> v4:
>> * update init handling to ensure host init done on first cmd transfer
>>
>> v3:
>> * none
>>
>> v2:
>> * check initialized state in samsung_dsim_init
>>
>> v1:
>> * keep DSI init in host transfer
>>
>> Signed-off-by: Marek Szyprowski
>> Signed-off-by: Jagan Teki
>> ---
>> drivers/gpu/drm/bridge/samsung-dsim.c | 25
>> +
>> include/drm/bridge/samsung-dsim.h | 5 +++--
>> 2 files changed, 20 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c
>> b/drivers/gpu/drm/bridge/samsung-dsim.c
>> index bb1f45fd5a88..ec7e01ae02ea 100644
>> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
>> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
>> @@ -1234,12 +1234,17 @@ static void samsung_dsim_disable_irq(struct
>> samsung_dsim *dsi)
>> disable_irq(dsi->irq);
>> }
>> -static int samsung_dsim_init(struct samsung_dsim *dsi)
>> +static int samsung_dsim_init(struct samsung_dsim *dsi, unsigned int
>> flag)
>> {
>> const struct samsung_dsim_driver_data *driver_data =
>> dsi->driver_data;
>> +if (dsi->state & flag)
>> +return 0;
>> +
>> samsung_dsim_reset(dsi);
>> -samsung_dsim_enable_irq(dsi);
>> +
>> +if (!(dsi->state & DSIM_STATE_INITIALIZED))
>> +samsung_dsim_enable_irq(dsi);
>> if (driver_data->reg_values[RESET_TYPE] == DSIM_FUNCRST)
>> samsung_dsim_enable_lane(dsi, BIT(dsi->lanes) - 1);
>> @@ -1250,6 +1255,8 @@ static int samsung_dsim_init(struct
>> samsung_dsim *dsi)
>> samsung_dsim_set_phy_ctrl(dsi);
>> samsung_dsim_init_link(dsi);
>> +dsi->state |= flag;
>> +
>> return 0;
>> }
>> @@ -1269,6 +1276,10 @@ static void
>> samsung_dsim_atomic_pre_enable(struct drm_bridge *bridge,
>> }
>> dsi->state |= DSIM_STATE_ENABLED;
>> +
>> +ret = samsung_dsim_init(dsi, DSIM_STATE_INITIALIZED);
>> +if (ret)
>> +return;
>> }
>> static void samsung_dsim_atomic_enable(struct drm_bridge
>> *bridge,
>> @@ -1458,12 +1469,9 @@ static ssize_t
>> samsung_dsim_host_transfer(struct mipi_dsi_host *host,
>> if (!(dsi->state & DSIM_STATE_ENABLED))
>> return -EINVAL;
>> -if (!(dsi->state & DSIM_STATE_INITIALIZED)) {
>> -ret = samsung_dsim_init(dsi);
>> -if (ret)
>> -return ret;
>> -dsi->state |= DSIM_STATE_INITIALIZED;
>> -}
>> +ret = samsung_dsim_init(dsi, DSIM_STATE_REINITIALIZED);
> This triggers full controller reset and reprogramming upon first
> command transfer, is such heavy handed reload really necessary ?
Yes it is, otherwise the proper DSI panels doesn't work with
[Bug 216774] On amdgpu the drm subsystem lists additional modes beyond what EDID has available
https://bugzilla.kernel.org/show_bug.cgi?id=216774 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |ANSWERED --- Comment #1 from Artem S. Tashkinov (a...@gmx.com) --- Please search for dupes here https://gitlab.freedesktop.org/drm/amd/-/issues and file a bug report if there are none. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: Try to address the DMA-buf coherency problem
Hi Christian, On Thu, Nov 17, 2022 at 9:11 PM Christian König wrote: > > Hi Tomasz, > > Am 17.11.22 um 10:35 schrieb Tomasz Figa: > > Hi Christian and everyone, > > > > On Thu, Nov 3, 2022 at 4:14 AM Christian König > > wrote: > >> Am 02.11.22 um 18:10 schrieb Lucas Stach: > >>> Am Mittwoch, dem 02.11.2022 um 13:21 +0100 schrieb Christian König: > >>> [SNIP] > It would just be doing this for the importer and exactly that > would be bad design because we then have handling for the display driver > outside of the driver. > > >>> The driver would have to do those cache maintenance operations if it > >>> directly worked with a non-coherent device. Doing it for the importer > >>> is just doing it for another device, not the one directly managed by > >>> the exporter. > >>> > >>> I really don't see the difference to the other dma-buf ops: in > >>> dma_buf_map_attachment the exporter maps the dma-buf on behalf and into > >>> the address space of the importer. Why would cache maintenance be any > >>> different? > >> The issue here is the explicit ownership transfer. > >> > >> We intentionally decided against that because it breaks tons of use > >> cases and is at least by me and a couple of others seen as generally > >> design failure of the Linux DMA-API. > > First of all, thanks for starting the discussion and sorry for being > > late to the party. May I ask you to keep me on CC for any changes that > > touch the V4L2 videobuf2 framework, as a maintainer of it? I'm okay > > being copied on the entire series, no need to pick the specific > > patches. Thanks in advance. > > Sorry for that, I've only added people involved in the previous > discussion. Going to keep you in the loop. > No worries. Thanks. Sorry, for being late with the reply, had a bit of vacation and then some catching up last week. > > I agree that we have some design issues in the current DMA-buf > > framework, but I'd try to approach it a bit differently. Instead of > > focusing on the issues in the current design, could we write down our > > requirements and try to come up with how a correct design would look > > like? (A lot of that has been already mentioned in this thread, but I > > find it quite difficult to follow and it might not be a complete view > > either.) > > Well, exactly that's what we disagree on. > > As far as I can see the current design of DMA-buf is perfectly capable > of handling all the requirements. > > A brief summary of the requirements with some implementation notes: > > 1. Device drivers export their memory as it is. E.g. no special handling > for importers on the exporter side. > If an importer can't deal with a specific format, layout, caching > etc... of the data the correct approach is to reject the attachment. > Those parameters are controlled by userspace and negotiating them > is explicitly not part of the framework. Ack. I believe it matches the current implementation of the DMA-buf framework, although as you mentioned, the swiotlb feature of the DMA mapping framework kind of violates this. > > 2. Accesses of the CPU to a buffer are bracket int begin_cpu_access() > and end_cpu_access() calls. > Here we can insert the CPU cache invalidation/flushes as necessary. Ack. I think a part of the problem today is that there exist userspace and kernel code instances that don't insert them and assume that some magic keeps the cache clean... > > 3. Accesses of the device HW to a buffer are represented with dma_fence > objects. > It's explicitly allowed to have multiple devices access the buffer > at the same time. > Ack. Again there exists kernel code that doesn't honor or provide DMA fences (e.g. V4L2). > 4. Access to the DMA-buf by the HW of an importer is setup by the exporter. > In other words the exporter provides a bunch of DMA addresses the > importer should access. > The importer should not try to come up with those on its own. > > > That said, let me address a few aspects already mentioned, to make > > sure that everyone is on the same page. > > > >> DMA-Buf let's the exporter setup the DMA addresses the importer uses to > >> be able to directly decided where a certain operation should go. E.g. we > >> have cases where for example a P2P write doesn't even go to memory, but > >> rather a doorbell BAR to trigger another operation. Throwing in CPU > >> round trips for explicit ownership transfer completely breaks that concept. > > It sounds like we should have a dma_dev_is_coherent_with_dev() which > > accepts two (or an array?) of devices and tells the caller whether the > > devices need explicit ownership transfer. > > No, exactly that's the concept I'm pushing back on very hard here. > > In other words explicit ownership transfer is not something we would > want as requirement in the framework, cause otherwise we break tons of > use cases which require concurrent access to the underlying buffer. > > When a device driver needs explicit ownership transfer
Re: [PATCH] drm: tidss: Fix pixel format definition
On 02-Dec-22 23:22, Andrew Davis wrote:
On 12/1/22 6:18 PM, Randolph Sapp wrote:
There was a long-standing bug from a typo that created 2 ARGB1555 and
ABGR1555 pixel format entries. Weston 10 has a sanity check that alerted
me to this issue.
According to the Supported Pixel Data formats table we have the later
entries should have been for Alpha-X instead.
Fixes 32a1795f57eecc
Acked-by: Andrew Davis
Signed-off-by: Randolph Sapp
Reviewed-by: Aradhya Bhatia
---
drivers/gpu/drm/tidss/tidss_dispc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index ad93acc9abd2..16301bdfead1 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -1858,8 +1858,8 @@ static const struct {
{ DRM_FORMAT_XBGR, 0x21, },
{ DRM_FORMAT_RGBX, 0x22, },
- { DRM_FORMAT_ARGB1555, 0x25, },
- { DRM_FORMAT_ABGR1555, 0x26, },
+ { DRM_FORMAT_XRGB1555, 0x25, },
+ { DRM_FORMAT_XBGR1555, 0x26, },
{ DRM_FORMAT_XRGB, 0x27, },
{ DRM_FORMAT_XBGR, 0x28, },
[syzbot] memory leak in fbcon_set_font (2)
Hello, syzbot found the following issue on: HEAD commit:c2bf05db6c78 Merge tag 'i2c-for-6.1-rc8' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=171883d588 kernel config: https://syzkaller.appspot.com/x/.config?x=979161df0e247659 dashboard link: https://syzkaller.appspot.com/bug?extid=25bdb7b1703639abd498 compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14fff84d88 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=135806a788 Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/63cd45bf1d68/disk-c2bf05db.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/bafbfb42c660/vmlinux-c2bf05db.xz kernel image: https://storage.googleapis.com/syzbot-assets/9f803a721cfc/bzImage-c2bf05db.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+25bdb7b1703639abd...@syzkaller.appspotmail.com BUG: memory leak unreferenced object 0x888111648000 (size 18448): comm "syz-executor148", pid 3653, jiffies 4294970435 (age 13.520s) hex dump (first 32 bytes): 85 44 7e c7 00 00 00 00 00 48 00 00 00 00 00 00 .D~..H.. 92 30 86 d2 8c 38 30 9e e7 a3 05 00 9f 09 33 bb .0...80...3. backtrace: [] __do_kmalloc_node mm/slab_common.c:943 [inline] [] __kmalloc+0xb3/0x120 mm/slab_common.c:968 [] kmalloc include/linux/slab.h:558 [inline] [] fbcon_set_font+0x1a9/0x470 drivers/video/fbdev/core/fbcon.c:2508 [] con_font_set drivers/tty/vt/vt.c:4667 [inline] [] con_font_op+0x3a9/0x600 drivers/tty/vt/vt.c:4713 [] vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] [] vt_ioctl+0x14fd/0x1a80 drivers/tty/vt/vt_ioctl.c:752 [] tty_ioctl+0x6d5/0xbe0 drivers/tty/tty_io.c:2771 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:870 [inline] [] __se_sys_ioctl fs/ioctl.c:856 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd BUG: memory leak unreferenced object 0x888110b18000 (size 18448): comm "syz-executor148", pid 3655, jiffies 4294971001 (age 7.860s) hex dump (first 32 bytes): 85 44 7e c7 00 00 00 00 00 48 00 00 00 00 00 00 .D~..H.. 92 30 86 d2 8c 38 30 9e e7 a3 05 00 9f 09 33 bb .0...80...3. backtrace: [] __do_kmalloc_node mm/slab_common.c:943 [inline] [] __kmalloc+0xb3/0x120 mm/slab_common.c:968 [] kmalloc include/linux/slab.h:558 [inline] [] fbcon_set_font+0x1a9/0x470 drivers/video/fbdev/core/fbcon.c:2508 [] con_font_set drivers/tty/vt/vt.c:4667 [inline] [] con_font_op+0x3a9/0x600 drivers/tty/vt/vt.c:4713 [] vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] [] vt_ioctl+0x14fd/0x1a80 drivers/tty/vt/vt_ioctl.c:752 [] tty_ioctl+0x6d5/0xbe0 drivers/tty/tty_io.c:2771 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:870 [inline] [] __se_sys_ioctl fs/ioctl.c:856 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory write to /proc/sys/kernel/hung_task_check_interval_secs failed: No such file or directory write to /proc/sys/kernel/softlockup_all_cpu_backtrace failed: No such file or directory --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 2/2] vfio/pci: Remove console drivers
On Sat, 3 Dec 2022 17:12:38 -0700
"m...@lab.how" wrote:
> Hi,
>
> I hope it is ok to reply to this old thread.
It is, but the only relic of the thread is the subject. For reference,
the latest version of this posted is here:
https://lore.kernel.org/all/20220622140134.12763-4-tzimmerm...@suse.de/
Which is committed as:
d17378062079 ("vfio/pci: Remove console drivers")
> Unfortunately, I found a
> problem only now after upgrading to 6.0.
>
> My setup has multiple GPUs (2), and I depend on EFIFB to have a working
> console.
> pre-patch behavior, when I bind the vfio-pci to my secondary GPU both
> the passthrough and the EFIFB keep working fine.
> post-patch behavior, when I bind the vfio-pci to the secondary GPU,
> the EFIFB disappears from the system, binding the console to the
> "dummy console".
> Whenever you try to access the terminal, you have the screen stuck in
> whatever was the last buffer content, which gives the impression of
> "freezing," but I can still type.
> Everything else works, including the passthrough.
This sounds like the call to aperture_remove_conflicting_pci_devices()
is removing the conflicting driver itself rather than removing the
device from the driver. Is it not possible to unbind the GPU from
efifb before binding the GPU to vfio-pci to effectively nullify the
added call?
> I can only think about a few options:
>
> - Is there a way to have EFIFB show up again? After all it looks like
> the kernel has just abandoned it, but the buffer is still there. I
> can't find a single message about the secondary card and EFIFB in
> dmesg, but there's a message for the primary card and EFIFB.
> - Can we have a boolean controlling the behavior of vfio-pci
> altogether or at least controlling the behavior of vfio-pci for that
> specific ID? I know there's already some option for vfio-pci and VGA
> cards, would it be appropriate to attach this behavior to that option?
I suppose we could have an opt-out module option on vfio-pci to skip
the above call, but clearly it would be better if things worked by
default. We cannot make full use of GPUs with vfio-pci if they're
still in use by host console drivers. The intention was certainly to
unbind the device from any low level drivers rather than disable use of
a console driver entirely. DRM/GPU folks, is that possibly an
interface we could implement? Thanks,
Alex
[Bug 216774] New: On amdgpu the drm subsystem lists additional modes beyond what EDID has available
https://bugzilla.kernel.org/show_bug.cgi?id=216774 Bug ID: 216774 Summary: On amdgpu the drm subsystem lists additional modes beyond what EDID has available Product: Drivers Version: 2.5 Kernel Version: 5.15.81 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: wolfwi...@gmail.com Regression: No Created attachment 303357 --> https://bugzilla.kernel.org/attachment.cgi?id=303357=edit Single-resolution EDID (1080p120) that demonstrates the problem The attached EDID is one I've used across multiple operating systems, however on Linux it creates the following additional modes at the DRM level visible with drm_info outside of X/Wayland from the CLI: 1680x1050@120.00 1280x1024@120.00 1440x900@120.00 1280x800@120.00 1280x720@120.00 1024x768@120.00 800x600@120.00 640x480@120.00 This EDID is being loaded via "drm.edid_firmware=eDP:edid.bin" and is present in the initramfs, and this happens both with the stock Ubuntu kernel and when I compiled the latest 5.15.81 kernel from source, so I'm reporting it here. This might be a misconfiguration or some additional option I need to pass to the drm subsystem to disable some built-in mode-list it's adding by default, or even fixed in later kernel versions and I was simply unaware, if so I apologize for taking up your time! This EDID is meant to only have a single mode available, 1080p120. Changing the EDID to use 1080p60 (only involves changing the pixel clock value for the single mode and EDID checksum) still has the same problem, and looking at the modes it appears it's just replacing the visible-pixel values with the smaller values and retaining all the other timing details so these seem to be auto-generated somewhere I can't find. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v2 03/11] drm/bridge: ti-sn65dsi86: Propagate errors in .get_state() to the caller
On Sun, Dec 04, 2022 at 10:09:40PM +0100, Uwe Kleine-König wrote: > Hello, > > my initial Cc-list wasn't optimal. So I added a few people here. > > On Wed, Nov 30, 2022 at 04:21:40PM +0100, Uwe Kleine-König wrote: > > .get_state() can return an error indication. Make use of it to propagate > > failing hardware accesses. > > > > Signed-off-by: Uwe Kleine-König Reviewed-by: Laurent Pinchart > > --- > > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > index 6826d2423ae9..9671071490d8 100644 > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > > @@ -1512,19 +1512,19 @@ static int ti_sn_pwm_get_state(struct pwm_chip > > *chip, struct pwm_device *pwm, > > > > ret = regmap_read(pdata->regmap, SN_PWM_EN_INV_REG, _en_inv); > > if (ret) > > - return 0; > > + return ret; > > > > ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_SCALE_REG, ); > > if (ret) > > - return 0; > > + return ret; > > > > ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_REG, ); > > if (ret) > > - return 0; > > + return ret; > > > > ret = regmap_read(pdata->regmap, SN_PWM_PRE_DIV_REG, _div); > > if (ret) > > - return 0; > > + return ret; > > > > state->enabled = FIELD_GET(SN_PWM_EN_MASK, pwm_en_inv); > > if (FIELD_GET(SN_PWM_INV_MASK, pwm_en_inv)) > > It would be great to get an Ack to take this patch and patch #1 via the > PWM tree. (Both got an Ack by Douglas Anderson, I'm unsure if that is > already enough.) -- Regards, Laurent Pinchart
Re: [PATCH v2 03/11] drm/bridge: ti-sn65dsi86: Propagate errors in .get_state() to the caller
Hello, my initial Cc-list wasn't optimal. So I added a few people here. On Wed, Nov 30, 2022 at 04:21:40PM +0100, Uwe Kleine-König wrote: > .get_state() can return an error indication. Make use of it to propagate > failing hardware accesses. > > Signed-off-by: Uwe Kleine-König > --- > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > index 6826d2423ae9..9671071490d8 100644 > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c > @@ -1512,19 +1512,19 @@ static int ti_sn_pwm_get_state(struct pwm_chip *chip, > struct pwm_device *pwm, > > ret = regmap_read(pdata->regmap, SN_PWM_EN_INV_REG, _en_inv); > if (ret) > - return 0; > + return ret; > > ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_SCALE_REG, ); > if (ret) > - return 0; > + return ret; > > ret = ti_sn65dsi86_read_u16(pdata, SN_BACKLIGHT_REG, ); > if (ret) > - return 0; > + return ret; > > ret = regmap_read(pdata->regmap, SN_PWM_PRE_DIV_REG, _div); > if (ret) > - return 0; > + return ret; > > state->enabled = FIELD_GET(SN_PWM_EN_MASK, pwm_en_inv); > if (FIELD_GET(SN_PWM_INV_MASK, pwm_en_inv)) It would be great to get an Ack to take this patch and patch #1 via the PWM tree. (Both got an Ack by Douglas Anderson, I'm unsure if that is already enough.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH v2 1/2] drm/shmem-helper: Remove errant put in error path
On 11/30/22 21:57, Rob Clark wrote:
> From: Rob Clark
>
> drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM
> object getting prematurely freed leading to a later use-after-free.
>
> Link: https://syzkaller.appspot.com/bug?extid=c8ae65286134dd1b800d
> Reported-by: syzbot+c8ae65286134dd1b8...@syzkaller.appspotmail.com
> Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rob Clark
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 35138f8a375c..3b7b71391a4c 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -622,10 +622,8 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object
> *shmem, struct vm_area_struct
> }
>
> ret = drm_gem_shmem_get_pages(shmem);
> - if (ret) {
> - drm_gem_vm_close(vma);
> + if (ret)
> return ret;
> - }
>
> vma->vm_flags |= VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
> vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
AFAICS, the dmabuf mmaping code path needs a similar fix, isn't it?
- /* Drop the reference drm_gem_mmap_obj() acquired.*/
- drm_gem_object_put(obj);
vma->vm_private_data = NULL;
- return dma_buf_mmap(obj->dma_buf, vma, 0);
+ ret = dma_buf_mmap(obj->dma_buf, vma, 0);
+
+ /* Drop the reference drm_gem_mmap_obj() acquired.*/
+ if (!ret)
+ drm_gem_object_put(obj);
+
+ return ret;
--
Best regards,
Dmitry
Re: [PATCH 2/2] vfio/pci: Remove console drivers
Hi, I hope it is ok to reply to this old thread. Unfortunately, I found a problem only now after upgrading to 6.0. My setup has multiple GPUs (2), and I depend on EFIFB to have a working console. pre-patch behavior, when I bind the vfio-pci to my secondary GPU both the passthrough and the EFIFB keep working fine. post-patch behavior, when I bind the vfio-pci to the secondary GPU, the EFIFB disappears from the system, binding the console to the "dummy console". Whenever you try to access the terminal, you have the screen stuck in whatever was the last buffer content, which gives the impression of "freezing," but I can still type. Everything else works, including the passthrough. I can only think about a few options: - Is there a way to have EFIFB show up again? After all it looks like the kernel has just abandoned it, but the buffer is still there. I can't find a single message about the secondary card and EFIFB in dmesg, but there's a message for the primary card and EFIFB. - Can we have a boolean controlling the behavior of vfio-pci altogether or at least controlling the behavior of vfio-pci for that specific ID? I know there's already some option for vfio-pci and VGA cards, would it be appropriate to attach this behavior to that option? Thanks, Carlos Augusto
[PATCH] gpu: ipu-v3: fix refcount leak in ipu_add_client_devices()
The node returned by of_graph_get_port_by_id() with refcount incremented,
of_node_put() needs be called when finish using it. So add it in the
error path in ipu_add_client_devices().
Fixes: 17e052175039 ("gpu: ipu-v3: Do not bail out on missing optional port
nodes")
Signed-off-by: Wang Yufen
---
drivers/gpu/ipu-v3/ipu-common.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 1183185..80587f5 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1164,6 +1164,7 @@ static int ipu_add_client_devices(struct ipu_soc *ipu,
unsigned long ipu_base)
pdev = platform_device_alloc(reg->name, id++);
if (!pdev) {
+ of_node_put(of_node);
ret = -ENOMEM;
goto err_register;
}
--
1.8.3.1
Re: [PATCH 2/3] ASoC: dt-bindings: Reference common DAI properties
On Sonntag, 4. Dezember 2022 17:47:05 CET Krzysztof Kozlowski wrote: > On 04/12/2022 17:09, Nicolas Frattaroli wrote: > > On Samstag, 3. Dezember 2022 17:04:41 CET Krzysztof Kozlowski wrote: > >> Reference in all sound components which have '#sound-dai-cells' the > >> dai-common.yaml schema, which allows to use 'sound-name-prefix' > >> property. > >> > >> Signed-off-by: Krzysztof Kozlowski > >> > >> --- > >> > >> This is an output of discussion here: > >> https://lore.kernel.org/all/y255c+tgnvj9f...@sirena.org.uk/ > >> > >> This patch supersedes previous WSA883x one. > >> --- > > > > Hello, > > > > for rockchip,i2s-tdm, we get some (new?) warnings with W=1: > > > > > > /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-pinenote-v1.1.dtb: > > i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] > > From schema: > > /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml > > I did not touch reset names, so are you sure these are not old warnings? > > > Best regards, > Krzysztof > > You are correct, these aren't new, I thought they were due to it now actually checking reset-names or something. However, checking with linux-next/master shows that these were already there. Apologies for the noise. For rockchip,i2s-tdm: Tested-by: Nicolas Frattaroli Acked-by: Nicolas Frattaroli Kind regards, Nicolas Frattaroli
Re: [PATCH v1 0/2] ASoC/tda998x: Fix reporting of nonexistent capture streams
On Wed, 30 Nov 2022 18:46:42 +, Mark Brown wrote: > The recently added pcm-test selftest has pointed out that systems with > the tda998x driver end up advertising that they support capture when in > reality as far as I can see the tda998x devices are transmit only. The > DAIs registered through hdmi-codec are bidirectional, meaning that for > I2S systems when combined with a typical bidrectional CPU DAI the > overall capability of the PCM is bidirectional. In most cases the I2S > links will clock OK but no useful audio will be returned which isn't so > bad but we should still not advertise the useless capability, and some > systems may notice problems for example due to pinmux management. > > [...] Applied to broonie/sound.git for-next Thanks! [1/2] ASoC: hdmi-codec: Allow playback and capture to be disabled commit: f77a066f4ed307db93aafee621e2683c3bda98ce [2/2] drm: tda99x: Don't advertise non-existent capture support commit: a04f1c81316d27e140c3df5561e5ef87794cd4bc All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Re: [PATCH 2/3] ASoC: dt-bindings: Reference common DAI properties
On 04/12/2022 17:09, Nicolas Frattaroli wrote: > On Samstag, 3. Dezember 2022 17:04:41 CET Krzysztof Kozlowski wrote: >> Reference in all sound components which have '#sound-dai-cells' the >> dai-common.yaml schema, which allows to use 'sound-name-prefix' >> property. >> >> Signed-off-by: Krzysztof Kozlowski >> >> --- >> >> This is an output of discussion here: >> https://lore.kernel.org/all/y255c+tgnvj9f...@sirena.org.uk/ >> >> This patch supersedes previous WSA883x one. >> --- > > Hello, > > for rockchip,i2s-tdm, we get some (new?) warnings with W=1: > > > /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-pinenote-v1.1.dtb: > i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] > From schema: > /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml I did not touch reset names, so are you sure these are not old warnings? Best regards, Krzysztof
Re: [PATCH 2/3] ASoC: dt-bindings: Reference common DAI properties
On Samstag, 3. Dezember 2022 17:04:41 CET Krzysztof Kozlowski wrote: > Reference in all sound components which have '#sound-dai-cells' the > dai-common.yaml schema, which allows to use 'sound-name-prefix' > property. > > Signed-off-by: Krzysztof Kozlowski > > --- > > This is an output of discussion here: > https://lore.kernel.org/all/y255c+tgnvj9f...@sirena.org.uk/ > > This patch supersedes previous WSA883x one. > --- Hello, for rockchip,i2s-tdm, we get some (new?) warnings with W=1: /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-pinenote-v1.1.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml DTC_CHK arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dtb /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-pinenote-v1.2.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml DTC_CHK arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dtb /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-quartz64-b.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-roc-pc.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-bpi-r2-pro.dtb /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-soquartz-blade.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml DTC_CHK arch/arm64/boot/dts/rockchip/rk3568-evb1-v10.dtb /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-soquartz-cm4.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml /home/fratti/Projekte/linux/arch/arm64/boot/dts/rockchip/rk3566-soquartz-model-a.dtb: i2s@fe42: reset-names:0: 'm' is not one of ['tx-m', 'rx-m'] From schema: /home/fratti/Projekte/linux/Documentation/devicetree/bindings/sound/rockchip,i2s-tdm.yaml Apparently we don't have separate resets for tx/rx on i2s2 on this hardware. Should we add 'm' to the allowed reset-names for this case? Cheers, Nicolas Frattaroli
