[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #54 from Joe Coutcher --- Ondrej - I'm on a fresh install of Ubuntu 19.04 with no workarounds applied, using a similar setup to yours (HP Envy x360 15m-bq121dx.) I installed kernel 5.2 RC7 (since the AMD64 build of 5.2 final on kernel.ubuntu.com is broken), and updated to the latest linux-firmware package available on the disco feed (1.178.2). I should also note I'm on HP BIOS firmware version 21. While the system boots to the desktop environment, there's tons of garbage, and when using Firefox, screen writes are occuring on random parts of the screen. Also, I attempted running Basemark Web 3.0 in Firefox, and can consistently lock up the machine. For reference, the kernel version is 5.2.0-050200rc7-lowlatency. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 5/5] drm/vkms: Add support for writeback
On 07/11, Daniel Vetter wrote:
> On Tue, Jun 25, 2019 at 10:39:03PM -0300, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with writeback support.
> >
> > Change in V3 (Daniel):
> > - If writeback is enabled, compose everything into the writeback buffer
> > instead of CRC private buffer.
> > - Guarantees that the CRC will match exactly what we have in the
> > writeback buffer.
> >
> > Change in V2:
> > - Rework signal completion (Brian)
> > - Integrates writeback with active_planes (Daniel)
> > - Compose cursor (Daniel)
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/Makefile | 9 +-
> > drivers/gpu/drm/vkms/vkms_composer.c | 16 ++-
> > drivers/gpu/drm/vkms/vkms_drv.c | 4 +
> > drivers/gpu/drm/vkms/vkms_drv.h | 8 ++
> > drivers/gpu/drm/vkms/vkms_output.c| 10 ++
> > drivers/gpu/drm/vkms/vkms_writeback.c | 141 ++
> > 6 files changed, 185 insertions(+), 3 deletions(-)
> > create mode 100644 drivers/gpu/drm/vkms/vkms_writeback.c
> >
> > diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> > index 0b767d7efa24..333d3cead0e3 100644
> > --- a/drivers/gpu/drm/vkms/Makefile
> > +++ b/drivers/gpu/drm/vkms/Makefile
> > @@ -1,4 +1,11 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > -vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
> > vkms_composer.o
> > +vkms-y := \
> > + vkms_drv.o \
> > + vkms_plane.o \
> > + vkms_output.o \
> > + vkms_crtc.o \
> > + vkms_gem.o \
> > + vkms_composer.o \
> > + vkms_writeback.o
> >
> > obj-$(CONFIG_DRM_VKMS) += vkms.o
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 8126aa0f968f..2317803e7320 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -157,16 +157,17 @@ void vkms_composer_worker(struct work_struct *work)
> > struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
> > struct vkms_composer *primary_composer = NULL;
> > struct vkms_composer *cursor_composer = NULL;
> > + bool crc_pending, wb_pending;
>
> I'm not seeing how you schedule this work for writeback if there's no crc
> enabled. Does that work?
If we enable writeback, we set true for the flag composer_enabled (see
vkms_output.c in this patch) which also make vkms_vblank_simulate able
to handle crc. Since writeback is oneshot, we only enable it on
vkms_wb_atomic_commit (crtc_state->wb_pending = true); in its turn
vkms_composer_worker() use writeback buffer instead of creating a new
one for computing crc. Finally, at the end of vkms_composer_worker() we
disable the writeback.
> > void *vaddr_out = NULL;
> > u32 crc32 = 0;
> > u64 frame_start, frame_end;
> > - bool crc_pending;
> > int ret;
> >
> > spin_lock_irq(>composer_lock);
> > frame_start = crtc_state->frame_start;
> > frame_end = crtc_state->frame_end;
> > crc_pending = crtc_state->crc_pending;
> > + wb_pending = crtc_state->wb_pending;
> > crtc_state->frame_start = 0;
> > crtc_state->frame_end = 0;
> > crtc_state->crc_pending = false;
> > @@ -188,9 +189,12 @@ void vkms_composer_worker(struct work_struct *work)
> > if (!primary_composer)
> > return;
> >
> > + if (wb_pending)
> > + vaddr_out = crtc_state->active_writeback;
> > +
> > ret = compose_planes(_out, primary_composer, cursor_composer);
> > if (ret) {
> > - if (ret == -EINVAL)
> > + if (ret == -EINVAL && !wb_pending)
> > kfree(vaddr_out);
> > return;
> > }
> > @@ -203,6 +207,14 @@ void vkms_composer_worker(struct work_struct *work)
> > while (frame_start <= frame_end)
> > drm_crtc_add_crc_entry(crtc, true, frame_start++, );
> >
> > + if (wb_pending) {
> > + drm_writeback_signal_completion(>wb_connector, 0);
> > + spin_lock_irq(>composer_lock);
> > + crtc_state->wb_pending = false;
> > + spin_unlock_irq(>composer_lock);
> > + return;
> > + }
> > +
> > kfree(vaddr_out);
> > }
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index ac790b6527e4..152d7de24a76 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -30,6 +30,10 @@ bool enable_cursor;
> > module_param_named(enable_cursor, enable_cursor, bool, 0444);
> > MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
> >
> > +bool enable_writeback;
> > +module_param_named(enable_writeback, enable_writeback, bool, 0444);
> > +MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector");
> > +
> > static const struct file_operations vkms_driver_fops = {
> > .owner = THIS_MODULE,
> >
Re: [PATCH V3 4/5] drm/vkms: Compute CRC without change input data
On 07/11, Daniel Vetter wrote:
> On Tue, Jun 25, 2019 at 10:38:31PM -0300, Rodrigo Siqueira wrote:
> > The compute_crc() function is responsible for calculating the
> > framebuffer CRC value; due to the XRGB format, this function has to
> > ignore the alpha channel during the CRC computation. Therefore,
> > compute_crc() set zero to the alpha channel directly in the input
> > framebuffer, which is not a problem since this function receives a copy
> > of the original buffer. However, if we want to use this function in a
> > context without a buffer copy, it will change the initial value. This
> > patch makes compute_crc() calculate the CRC value without modifying the
> > input framebuffer.
>
> Uh why? For writeback we're writing the output too, so we can write
> whatever we want to into the alpha channel. For writeback we should never
> accept a pixel format where alpha actually matters, that doesn't make
> sense. You can't see through a real screen either, they are all opaque :-)
> -Daniel
Hmmm,
I see your point and I agree, but even though we can write whatever we
want in the output, don’t you think that is weird to change the
framebuffer value in the compute_crc() function?
Thanks
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/vkms_composer.c | 31 +---
> > 1 file changed, 19 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> > b/drivers/gpu/drm/vkms/vkms_composer.c
> > index 51a270514219..8126aa0f968f 100644
> > --- a/drivers/gpu/drm/vkms/vkms_composer.c
> > +++ b/drivers/gpu/drm/vkms/vkms_composer.c
> > @@ -6,33 +6,40 @@
> > #include
> > #include
> >
> > +static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
> > +const struct vkms_composer *composer)
> > +{
> > + int src_offset = composer->offset + (y * composer->pitch)
> > + + (x * composer->cpp);
> > +
> > + return *(u32 *)[src_offset];
> > +}
> > +
> > /**
> > * compute_crc - Compute CRC value on output frame
> > *
> > - * @vaddr_out: address to final framebuffer
> > + * @vaddr: address to final framebuffer
> > * @composer: framebuffer's metadata
> > *
> > * returns CRC value computed using crc32 on the visible portion of
> > * the final framebuffer at vaddr_out
> > */
> > -static uint32_t compute_crc(void *vaddr_out, struct vkms_composer
> > *composer)
> > +static uint32_t compute_crc(const u8 *vaddr,
> > + const struct vkms_composer *composer)
> > {
> > - int i, j, src_offset;
> > + int x, y;
> > int x_src = composer->src.x1 >> 16;
> > int y_src = composer->src.y1 >> 16;
> > int h_src = drm_rect_height(>src) >> 16;
> > int w_src = drm_rect_width(>src) >> 16;
> > - u32 crc = 0;
> > + u32 crc = 0, pixel = 0;
> >
> > - for (i = y_src; i < y_src + h_src; ++i) {
> > - for (j = x_src; j < x_src + w_src; ++j) {
> > - src_offset = composer->offset
> > -+ (i * composer->pitch)
> > -+ (j * composer->cpp);
> > + for (y = y_src; y < y_src + h_src; ++y) {
> > + for (x = x_src; x < x_src + w_src; ++x) {
> > /* XRGB format ignores Alpha channel */
> > - memset(vaddr_out + src_offset + 24, 0, 8);
> > - crc = crc32_le(crc, vaddr_out + src_offset,
> > - sizeof(u32));
> > + pixel = get_pixel_from_buffer(x, y, vaddr, composer);
> > + bitmap_clear((void *), 0, 8);
> > + crc = crc32_le(crc, (void *), sizeof(u32));
> > }
> > }
> >
> > --
> > 2.21.0
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Rodrigo Siqueira
https://siqueira.tech
signature.asc
Description: PGP signature
[RFC PATCH] fbcon: fix ypos over boundary issue
From: Feng Tiantian While using "top" on a CentOS guest's VNC-client, then continuously press "Shift+PgUp", the guest kernel will get panic! Backtrace is attached below. We tested it on 5.2.0, and the issue remains. [ 66.946362] Unable to handle kernel paging request at virtual address 0e240840 [ 66.946363] Mem abort info: [ 66.946364] Exception class = DABT (current EL), IL = 32 bits [ 66.946365] SET = 0, FnV = 0 [ 66.946366] EA = 0, S1PTW = 0 [ 66.946367] Data abort info: [ 66.946368] ISV = 0, ISS = 0x0047 [ 66.946368] CM = 0, WnR = 1 [ 66.946370] swapper pgtable: 64k pages, 48-bit VAs, pgd = 0966 [ 66.946372] [0e240840] *pgd=00023ffe0003, *pud=00023ffe0003, *pmd=00023ffd0003, *pte= [ 66.946378] Internal error: Oops: 9647 [#1] SMP [ 66.946379] Modules linked in: vfat fat crc32_ce ghash_ce sg sha2_ce sha256_arm64 virtio_balloon virtio_net sha1_ce ip_tables ext4 mbcache jbd2 virtio_gpu drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm i2c_core virtio_scsi virtio_pci virtio_mmio virtio_ring virtio [ 66.946403] CPU: 0 PID: 1035 Comm: top Not tainted 4.14.0-49.el7a.aarch64 #1 [ 66.946404] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 66.946405] task: 8001c18fdc00 task.stack: 0d4e [ 66.946409] PC is at sys_imageblit+0x40c/0x1 [sysimgblt] [ 66.946431] LR is at drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper] [ 66.946433] pc : [] lr : [] pstate: 0005 [ 66.946433] sp : 0d4ef7f0 [ 66.946434] x29: 0d4ef7f0 x28: 01ff [ 66.946436] x27: 8001c1c88100 x26: 0001 [ 66.946438] x25: 01f0 x24: 0018 [ 66.946440] x23: x22: 0d4ef978 [ 66.946442] x21: 0e240840 x20: [ 66.946444] x19: 8001c98c9000 x18: f9d56670 [ 66.946445] x17: x16: [ 66.946447] x15: 0008 x14: 1b20202020202020 [ 66.946449] x13: 01f0 x12: 003e [ 66.946450] x11: 000f x10: 8001c840 [ 66.946452] x9 : 00aa x8 : 0001 [ 66.946454] x7 : 020b0090 x6 : 0001 [ 66.946456] x5 : x4 : [ 66.946457] x3 : 8001c840 x2 : 0e240840 [ 66.946459] x1 : 01ef x0 : 0007 [ 66.946461] Process top (pid: 1035, stack limit = 0x0d4e) [ 66.946462] Call trace: [ 66.946464] Exception stack(0x0d4ef6b0 to 0x0d4ef7f0) [ 66.946465] f6a0: 0007 01ef [ 66.946467] f6c0: 0e240840 8001c840 [ 66.946468] f6e0: 0001 020b0090 0001 00aa [ 66.946470] f700: 8001c840 000f 003e 01f0 [ 66.946471] f720: 1b20202020202020 0008 [ 66.946472] f740: f9d56670 8001c98c9000 0e240840 [ 66.946474] f760: 0d4ef978 0018 01f0 [ 66.946475] f780: 0001 8001c1c88100 01ff 0d4ef7f0 [ 66.946476] f7a0: 02202e74 0d4ef7f0 020a040c 0005 [ 66.946478] f7c0: 0d4ef7e0 080ea614 0001 08152f08 [ 66.946479] f7e0: 0d4ef7f0 020a040c [ 66.946481] [] sys_imageblit+0x40c/0x1 [sysimgblt] [ 66.946501] [] drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper] [ 66.946510] [] virtio_gpu_3d_imageblit+0x2c/0x78 [virtio_gpu] [ 66.946515] [] bit_putcs+0x288/0x49c [ 66.946517] [] fbcon_putcs+0x114/0x148 [ 66.946519] [] do_update_region+0x118/0x19c [ 66.946521] [] do_con_trol+0x114c/0x1314 [ 66.946523] [] do_con_write.part.22+0x1d8/0x890 [ 66.946525] [] con_write+0x84/0x8c [ 66.946527] [] n_tty_write+0x19c/0x408 [ 66.946529] [] tty_write+0x150/0x270 [ 66.946532] [] __vfs_write+0x58/0x180 [ 66.946534] [] vfs_write+0xa8/0x1a0 [ 66.946536] [] SyS_write+0x60/0xc0 [ 66.946537] Exception stack(0x0d4efec0 to 0x0d4f) [ 66.946539] fec0: 0001 00457958 0800 [ 66.946540] fee0: fbad2885 0bd0 8556add4 [ 66.946541] ff00: 0040 00434a88 0012 [ 66.946543] ff20: 0001 f9d564f0 f9d564a0 0008 [ 66.946544] ff40: 85593b1c f9d56670 0800 [ 66.946546] ff60: 00457958 856a1158 0800 8572 [ 66.946547] ff80: 856f604c 00436000 [ 66.946548] ffa0:
Re: [PATCH 0/2] drm/vkms: Introduce basic support for configfs
On 07/10, Daniel Vetter wrote: > On Mon, Jul 01, 2019 at 12:23:39AM -0300, Rodrigo Siqueira wrote: > > This patchset introduces the support for configfs in vkms by adding a > > primary structure for handling the vkms subsystem and exposing > > connectors as a use case. This series allows enabling/disabling virtual > > and writeback connectors on the fly. The first patch of this series > > reworks the initialization and cleanup code of each type of connector, > > with this change, the second patch adds the configfs support for vkms. > > It is important to highlight that this patchset depends on > > https://patchwork.freedesktop.org/series/61738/. > > > > After applying this series, the user can utilize these features with the > > following steps: > > > > 1. Load vkms without parameter > > > > modprobe vkms > > > > 2. Mount a configfs filesystem > > > > mount -t configfs none /mnt/ > > > > After that, the vkms subsystem will look like this: > > > > vkms/ > > |__connectors > > |__Virtual > > |__ enable > > > > The connectors directories have information related to connectors, and > > as can be seen, the virtual connector is enabled by default. Inside a > > connector directory (e.g., Virtual) has an attribute named ‘enable’ > > which is used to enable and disable the target connector. For example, > > the Virtual connector has the enable attribute set to 1. If the user > > wants to enable the writeback connector it is required to use the mkdir > > command, as follows: > > > > cd /mnt/vkms/connectors > > mkdir Writeback > > > > After the above command, the writeback connector will be enabled, and > > the user could see the following tree: > > > > vkms/ > > |__connectors > > |__Virtual > > | |__ enable > > |__Writeback > > |__ enable > > > > If the user wants to remove the writeback connector, it is required to > > use the command rmdir, for example > > > > rmdir Writeback > > > > Another way to enable and disable a connector it is by using the enable > > attribute, for example, we can disable the Virtual connector with: > > > > echo 0 > /mnt/vkms/connectors/Virtual/enable > > > > And enable it again with: > > > > echo 1 > /mnt/vkms/connectors/Virtual/enable > > > > It is important to highlight that configfs 'obey' the parameters used > > during the vkms load and does not allow users to remove a connector > > directory if it was load via module parameter. For example: > > > > modprobe vkms enable_writeback=1 > > > > vkms/ > > |__connectors > > |__Virtual > > | |__ enable > > |__Writeback > > |__ enable > > > > If the user tries to remove the Writeback connector with “rmdir > > Writeback”, the operation will be not permitted because the Writeback > > connector was loaded with the modules. However, the user may disable the > > writeback connector with: > > > > echo 0 > /mnt/vkms/connectors/Writeback/enable Thanks for detail this issue, I just have some few questions inline. > I guess I should have put a warning into that task that step one is > designing the interface. Here's the fundamental thoughts: > > - The _only_ thing we can hotplug after drm_dev_register() is a > drm_connector. That's an interesting use-case, but atm not really > supported by the vkms codebase. So we can't just enable/disable > writeback like this. We also can't change _anything_ else in the drm > driver like this. In the first patch of this series, I tried to decouple enable/disable for virtual and writeback connectors; I tried to take advantage of drm_connector_[register/unregister] in each connector. Can we use the first patch or it doesn't make sense? I did not understand why writeback connectors should not be registered and unregister by calling drm_connector_[register/unregister], is it a writeback or vkms limitation? Could you detail why we cannot change connectors as I did? Additionally, below you said "enable going from 1 -> 0, needs to be treated like a physical hotunplug", do you mean that we first have to add support for drm_dev_plug and drm_dev_unplug in vkms? > - The other bit we want is support multiple vkms instances, to simulate > multi-gpus and fun stuff like that. Do you mean something like this: configfs/vkms/instance1 |_enable_device |_more_stuff configfs/vkms/instance2 |_enable_device |_more_stuff configfs/vkms/instanceN |_enable_device |_more_stuff Will each instance work like a totally independent device? What is the main benefit of this? I can think about some use case for testing prime, but I cannot see other things. > - Therefore vkms configs should be at the drm_device level, so a > directory under configfs/vkms/ represents an entire device. > > - We need a special config item to control > drm_dev_register/drm_dev_unregister. While a drm_device is registers, > all other config items need to fail if userspace tries to change them. > Maybe this should be a top-level "enable"
[Bug 204145] amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580
https://bugzilla.kernel.org/show_bug.cgi?id=204145 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3] drm/vkms: Add support for vkms work without vblank
On 07/10, Daniel Vetter wrote:
> On Tue, Jul 09, 2019 at 10:55:14PM -0300, Rodrigo Siqueira wrote:
> > Currently, vkms only work with enabled VBlank. This patch adds another
> > operation model that allows vkms to work without VBlank support. In this
> > scenario, vblank signaling is faked by calling drm_send_vblank_event()
> > in vkms_crtc_atomic_flush(); this approach works due to the
> > drm_vblank_get() == 0 checking.
> >
> > Changes since V2:
> > - Rebase
> >
> > Changes since V1:
> > Daniel Vetter:
> > - Change module parameter name from disablevblank to virtual_hw
> > - Improve parameter description
> > - Improve commit message
> >
> > Signed-off-by: Rodrigo Siqueira
> > ---
> > drivers/gpu/drm/vkms/vkms_crtc.c | 10 ++
> > drivers/gpu/drm/vkms/vkms_drv.c | 13 +++--
> > drivers/gpu/drm/vkms/vkms_drv.h | 2 ++
> > 3 files changed, 23 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c
> > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > index 49a8ec2cb1c1..a0c75b8c4335 100644
> > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > @@ -207,12 +207,22 @@ static int vkms_crtc_atomic_check(struct drm_crtc
> > *crtc,
> > static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
> > struct drm_crtc_state *old_state)
> > {
> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> > +
> > + if (vkms_out->disable_vblank)
> > + return;
> > +
> > drm_crtc_vblank_on(crtc);
> > }
> >
> > static void vkms_crtc_atomic_disable(struct drm_crtc *crtc,
> > struct drm_crtc_state *old_state)
> > {
> > + struct vkms_output *vkms_out = drm_crtc_to_vkms_output(crtc);
> > +
> > + if (vkms_out->disable_vblank)
> > + return;
> > +
> > drm_crtc_vblank_off(crtc);
> > }
> >
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.c
> > b/drivers/gpu/drm/vkms/vkms_drv.c
> > index 152d7de24a76..542a002ef9d5 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.c
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> > @@ -34,6 +34,11 @@ bool enable_writeback;
> > module_param_named(enable_writeback, enable_writeback, bool, 0444);
> > MODULE_PARM_DESC(enable_writeback, "Enable/Disable writeback connector");
> >
> > +bool virtual_hw;
>
> Can be static, you only use this in vkms_drv.c.
>
> > +module_param_named(virtual_hw, virtual_hw, bool, 0444);
> > +MODULE_PARM_DESC(virtual_hw,
> > +"Enable virtual hardware mode (disables vblanks and
> > immediately completes flips)");
> > +
> > static const struct file_operations vkms_driver_fops = {
> > .owner = THIS_MODULE,
> > .open = drm_open,
> > @@ -154,9 +159,13 @@ static int __init vkms_init(void)
> > if (ret)
> > goto out_unregister;
> >
> > - vkms_device->drm.irq_enabled = true;
> > + vkms_device->output.disable_vblank = virtual_hw;
> > + vkms_device->drm.irq_enabled = !virtual_hw;
> > +
> > + if (virtual_hw)
> > + DRM_INFO("Virtual hardware mode enabled");
> >
> > - ret = drm_vblank_init(_device->drm, 1);
> > + ret = (virtual_hw) ? 0 : drm_vblank_init(_device->drm, 1);
> > if (ret) {
> > DRM_ERROR("Failed to vblank\n");
> > goto out_fini;
> > diff --git a/drivers/gpu/drm/vkms/vkms_drv.h
> > b/drivers/gpu/drm/vkms/vkms_drv.h
> > index 9ff2cd4ebf81..256e5e65c947 100644
> > --- a/drivers/gpu/drm/vkms/vkms_drv.h
> > +++ b/drivers/gpu/drm/vkms/vkms_drv.h
> > @@ -21,6 +21,7 @@
> >
> > extern bool enable_cursor;
> > extern bool enable_writeback;
> > +extern bool virtual_hw;
> >
> > struct vkms_composer {
> > struct drm_framebuffer fb;
> > @@ -69,6 +70,7 @@ struct vkms_output {
> > struct drm_connector connector;
> > struct drm_writeback_connector wb_connector;
> > struct hrtimer vblank_hrtimer;
> > + bool disable_vblank;
> > ktime_t period_ns;
> > struct drm_pending_vblank_event *event;
> > /* ordered wq for composer_work */
>
> I'm kinda wondering how this works at all ... does writeback/crc still
> work if you set virtual mode? Writeback since this seems based on the
> writeback series ...
Hi,
I tested this patch with kms_flip with the "drm/drm_vblank: Change
EINVAL by the correct errno" patch [1]. However, you’re right about the
writeback/crc tests, they does not pass because this patch disables
vblank which in turn does not invoke "vkms_vblank_simulate()".
In this sense, I’m a little bit confused about how should I handle this
issue. If I correctly understood, without vblank support we have to
trigger vkms_composer_worker() when the userspace invoke
drmModePageFlip(), am I right? If so, an approach could add page_flip()
callback to vkms and invoke vkms_composer_worker(); however, the
documentation says that page_flip is a legacy entry point. Do you have a
suggestion?
1. https://patchwork.freedesktop.org/patch/314399/?series=50697=7
Thanks
>
[Bug 204145] amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580
https://bugzilla.kernel.org/show_bug.cgi?id=204145 --- Comment #2 from Shawn Anastasio (sh...@anastas.io) --- Created attachment 283639 --> https://bugzilla.kernel.org/attachment.cgi?id=283639=edit lspci -vv -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204145] New: amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580
https://bugzilla.kernel.org/show_bug.cgi?id=204145 Bug ID: 204145 Summary: amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580 Product: Drivers Version: 2.5 Kernel Version: 5.1.15 Hardware: PPC-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: sh...@anastas.io Regression: No Created attachment 283635 --> https://bugzilla.kernel.org/attachment.cgi?id=283635=edit 5.1.15 kconfig On recent kernels (at least since 5.1.15), video playback will (sometimes) hard reset my POWER9 system with an AMD RX 580. Due to the nature of the crash, it does not seem that any kernel logs are produced by the event. The system Hostboot firmware does record the crash though, and it produces a GUARD event which disables the CPU slice the crash occurred on for subsequent boots until it is cleared. An upstream Hostboot issue has been submitted by another person who has encountered this behavior as well: https://github.com/open-power/hostboot/issues/180 I have been unable to reproduce the issue on kernel 5.0.9, indicating a regression somewhere in between. Attached is my 5.1.15 kernel config, the output of lspci -vv, and the contents of /proc/cpuinfo. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204145] amdgpu video playback causes host to hard reset (checkstop) on POWER9 with RX 580
https://bugzilla.kernel.org/show_bug.cgi?id=204145 --- Comment #1 from Shawn Anastasio (sh...@anastas.io) --- Created attachment 283637 --> https://bugzilla.kernel.org/attachment.cgi?id=283637=edit /proc/cpuinfo -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108806] AMDGPU Failed to read EDID from display
https://bugs.freedesktop.org/show_bug.cgi?id=108806 --- Comment #2 from Cameron --- I'm also having having the "No EDID read." issue with this monitor and a wx 5100. With the generic Ubuntu 5.0.0-20 kernel on 10.94 as well as on my custom 5.1.17 kernel. However, I don't even get anything on the screen. My monitor just flashes from black to lighter black... However, I'm running on POWER (PPC) so I may be encountering additional issues in my case. However, the petitboot firmware gives me a text screen. The firmware is running 4.19.0 which suggests that something has broken since then as others have suggested. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111010] Cemu Shader Cache Corruption Displaying Solid Color After commit 11e16ca7ce0
https://bugs.freedesktop.org/show_bug.cgi?id=111010
--- Comment #4 from Timothy Arceri ---
Fixed by:
commit 3043908ccb9c7030add1f34f9a947a787949a399
Author: Timothy Arceri
Date: Mon Jul 1 12:25:19 2019 +1000
mesa: save/restore SSO flag when using ARB_get_program_binary
Without this the restored program will fail the pipeline validation
checks when we attempt to use an SSO program.
Fixes: c20fd744fef1 ("mesa: Add Mesa ARB_get_program_binary helper
functions")
Reviewed-by: Jordan Justen
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111010
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
Am Donnerstag, 11. Juli 2019, 23:27:44 CEST schrieb Heiko Stübner: > Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson: > > Let's document the display timings that most veyron chromebooks (like > > jaq, jerry, mighty, speedy) have been using out in the field. This > > uses the standard blankings but a slightly slower clock rate, thus > > getting a refresh rate 58.3 Hz. > > > > NOTE: this won't really do anything except cause DRM to properly > > report the refresh rate since vop_crtc_mode_fixup() was rounding the > > pixel clock to 74.25 MHz anyway. Apparently the adjusted rate isn't > > exposed to userspace so it's important that the rate we're trying to > > achieve is mostly right. > > > > For the downstream kernel change related to this see See > > https://crrev.com/c/324558. > > > > NOTE: minnie uses a different panel will be fixed up in a future > > patch, so for now we'll just delete the panel timings there. > > > > Signed-off-by: Douglas Anderson > > applied for 5.3 5.4 obviously [just to not confuse people reading that later]
Re: [PATCH 00/12] treewide: Fix GENMASK misuses
From: Joe Perches Date: Tue, 9 Jul 2019 22:04:13 -0700 > These GENMASK uses are inverted argument order and the > actual masks produced are incorrect. Fix them. > > Add checkpatch tests to help avoid more misuses too. Patches #7 and #8 applied to 'net', with appropriate Fixes tags added to #8.
Re: [PATCH v5 3/7] arm64: dts: rockchip: Specify override mode for kevin panel
Am Montag, 1. April 2019, 19:17:20 CEST schrieb Douglas Anderson: > From: Sean Paul > > This patch adds an override mode for kevin devices. The mode increases > both back porches to allow a pixel clock of 2kHz as opposed to the > 'typical' value of 252750kHz. This is needed to avoid interference with > the touch digitizer on these laptops. > > Cc: Doug Anderson > Cc: Eric Anholt > Cc: Heiko Stuebner > Cc: Jeffy Chen > Cc: Rob Herring > Cc: Stéphane Marchesin > Cc: Thierry Reding > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-rockc...@lists.infradead.org > Signed-off-by: Sean Paul > Tested-by: Enric Balletbo i Serra > Signed-off-by: Douglas Anderson applied for 5.4 Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/7] ARM: dts: rockchip: Specify rk3288-veyron-chromebook's display timings
Am Montag, 1. April 2019, 19:17:23 CEST schrieb Douglas Anderson: > Let's document the display timings that most veyron chromebooks (like > jaq, jerry, mighty, speedy) have been using out in the field. This > uses the standard blankings but a slightly slower clock rate, thus > getting a refresh rate 58.3 Hz. > > NOTE: this won't really do anything except cause DRM to properly > report the refresh rate since vop_crtc_mode_fixup() was rounding the > pixel clock to 74.25 MHz anyway. Apparently the adjusted rate isn't > exposed to userspace so it's important that the rate we're trying to > achieve is mostly right. > > For the downstream kernel change related to this see See > https://crrev.com/c/324558. > > NOTE: minnie uses a different panel will be fixed up in a future > patch, so for now we'll just delete the panel timings there. > > Signed-off-by: Douglas Anderson applied for 5.3 Thanks Heiko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 7/7] ARM: dts: rockchip: Specify rk3288-veyron-minnie's display timings
Am Montag, 1. April 2019, 19:17:24 CEST schrieb Douglas Anderson: > Just like we did for rk3288-veyron-chromebook, we want to be able to > use one of the fixed PLLs in the system to make the pixel clock for > minnie. > > Specifying these timings matches us with how the display is used on > the downstream Chrome OS kernel. See https://crrev.com/c/323211. > > Unlike what we did for rk3288-veyron-chromebook, this CL actually > changes the timings (though not the pixel clock) that is used when > using the upstream kernel. Booting up a minnie shows that it ended up > with a 66.67 MHz pixel clock but it was still using the > porches/blankings it would have wanted for a 72.5 MHz pixel clock. > > NOTE: compared to the downstream kernel, this seems to cause a > slightly different result reported in the 'modetest' command on a > Chromebook. The downstream kernel shows: > 1280x800 60 1280 1298 1330 1351 800 804 822 830 7 > > With this patch we have: > 1280x800 59 1280 1298 1330 1351 800 804 822 830 6 > > Specifically modetest was reporting 60 Hz on the downstream kernel but > the upstream kernel does the math and comesup with 59 (because we > actually achieve 59.45 Hz). Also upstream doesn't round the Hz up > when converting to kHz--it seems to truncate. > > ALSO NOTE: when I look at the EDID from the datasheet, I see: > -hsync -vsync > ...but it seems like we've never actually run with that so I've > continued leaving that out. > > Signed-off-by: Douglas Anderson applied for 5.4 Thanks Heiko
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #23 from i...@yahoo.com --- I can confirm that mesa-19.1.2 works for me too. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/3] drm/panel: simple: Add mode support to devicetree
I'm reviving Sean Paul's old patchset to get mode support in device
tree. The cover letter for his v3 is at:
https://lists.freedesktop.org/archives/dri-devel/2018-February/165162.html
v6 of this patch is just a repost of the 3 DRM patches in v5 rebased
atop drm-misc. A few notes:
- I've dropped the bindings patch. Commit 821a1f7171ae ("dt-bindings:
display: Convert common panel bindings to DT schema") has landed and
Rob H said [1] that when that landed the bindings were implicitly
supported.
- Since the bindings patch was dropped I am assuming that Heiko
can just pick up the .dts patches from the v5 series. I
double-checked with him and he confirmed this is fine. Thus I
have left the device tree patches out of this version.
There were some coding style discussions on v5 of the path but it's
been agreed that we can land this series as-is and after it lands we
can address the minor style issues.
[1]
https://lkml.kernel.org/r/CAL_JsqJGtUTpJL+SDEKi09aDT4yDzY4x9KwYmz08NaZcn=n...@mail.gmail.com
Changes in v6:
- Rebased to drm-misc next
- Added tags
Changes in v5:
- Added Heiko's Tested-by
Changes in v4:
- Don't add mode from timing if override was specified (Thierry)
- Add warning if timing and fixed mode was specified (Thierry)
- Don't add fixed mode if timing was specified (Thierry)
- Refactor/rename a bit to avoid extra indentation from "if" tests
- i should be unsigned (Thierry)
- Add annoying WARN_ONs for some cases (Thierry)
- Simplify 'No display_timing found' handling (Thierry)
- Rename to panel_simple_parse_override_mode() (Thierry)
- display_timing for Innolux n116bge new for v4.
- display_timing for AUO b101ean01 new for v4.
Changes in v3:
- No longer parse display-timings subnode, use panel-timing (Rob)
Changes in v2:
- Parse the full display-timings node (using the native-mode) (Rob)
Douglas Anderson (2):
drm/panel: simple: Use display_timing for Innolux n116bge
drm/panel: simple: Use display_timing for AUO b101ean01
Sean Paul (1):
drm/panel: simple: Add ability to override typical timing
drivers/gpu/drm/panel/panel-simple.c | 171 ++-
1 file changed, 139 insertions(+), 32 deletions(-)
--
2.22.0.410.gd8fdbe21b5-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/3] drm/panel: simple: Add ability to override typical timing
From: Sean Paul
This patch adds the ability to override the typical display timing for a
given panel. This is useful for devices which have timing constraints
that do not apply across the entire display driver (eg: to avoid
crosstalk between panel and digitizer on certain laptops). The rules are
as follows:
- panel must not specify fixed mode (since the override mode will
either be the same as the fixed mode, or we'll be unable to
check the bounds of the overried)
- panel must specify at least one display_timing range which will be
used to ensure the override mode fits within its bounds
Changes in v2:
- Parse the full display-timings node (using the native-mode) (Rob)
Changes in v3:
- No longer parse display-timings subnode, use panel-timing (Rob)
Changes in v4:
- Don't add mode from timing if override was specified (Thierry)
- Add warning if timing and fixed mode was specified (Thierry)
- Don't add fixed mode if timing was specified (Thierry)
- Refactor/rename a bit to avoid extra indentation from "if" tests
- i should be unsigned (Thierry)
- Add annoying WARN_ONs for some cases (Thierry)
- Simplify 'No display_timing found' handling (Thierry)
- Rename to panel_simple_parse_override_mode() (Thierry)
Changes in v5:
- Added Heiko's Tested-by
Changes in v6:
- Rebased to drm-misc next
- Added tags
Cc: Doug Anderson
Cc: Eric Anholt
Cc: Heiko Stuebner
Cc: Jeffy Chen
Cc: Rob Herring
Cc: Stéphane Marchesin
Cc: Thierry Reding
Cc: devicet...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
Tested-by: Enric Balletbo i Serra
Signed-off-by: Douglas Anderson
Tested-by: Heiko Stuebner
Reviewed-by: Boris Brezillon
Acked-by: Thierry Reding
---
drivers/gpu/drm/panel/panel-simple.c | 109 +--
1 file changed, 104 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index af6bf5611b4e..1bee197821ef 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -30,6 +30,7 @@
#include
#include
+#include
#include
#include
@@ -92,6 +93,8 @@ struct panel_simple {
struct i2c_adapter *ddc;
struct gpio_desc *enable_gpio;
+
+ struct drm_display_mode override_mode;
};
static inline struct panel_simple *to_panel_simple(struct drm_panel *panel)
@@ -99,16 +102,13 @@ static inline struct panel_simple *to_panel_simple(struct
drm_panel *panel)
return container_of(panel, struct panel_simple, base);
}
-static int panel_simple_get_fixed_modes(struct panel_simple *panel)
+static unsigned int panel_simple_get_timings_modes(struct panel_simple *panel)
{
struct drm_connector *connector = panel->base.connector;
struct drm_device *drm = panel->base.drm;
struct drm_display_mode *mode;
unsigned int i, num = 0;
- if (!panel->desc)
- return 0;
-
for (i = 0; i < panel->desc->num_timings; i++) {
const struct display_timing *dt = >desc->timings[i];
struct videomode vm;
@@ -132,6 +132,16 @@ static int panel_simple_get_fixed_modes(struct
panel_simple *panel)
num++;
}
+ return num;
+}
+
+static unsigned int panel_simple_get_fixed_modes(struct panel_simple *panel)
+{
+ struct drm_connector *connector = panel->base.connector;
+ struct drm_device *drm = panel->base.drm;
+ struct drm_display_mode *mode;
+ unsigned int i, num = 0;
+
for (i = 0; i < panel->desc->num_modes; i++) {
const struct drm_display_mode *m = >desc->modes[i];
@@ -153,6 +163,44 @@ static int panel_simple_get_fixed_modes(struct
panel_simple *panel)
num++;
}
+ return num;
+}
+
+static int panel_simple_get_non_edid_modes(struct panel_simple *panel)
+{
+ struct drm_connector *connector = panel->base.connector;
+ struct drm_device *drm = panel->base.drm;
+ struct drm_display_mode *mode;
+ bool has_override = panel->override_mode.type;
+ unsigned int num = 0;
+
+ if (!panel->desc)
+ return 0;
+
+ if (has_override) {
+ mode = drm_mode_duplicate(drm, >override_mode);
+ if (mode) {
+ drm_mode_probed_add(connector, mode);
+ num = 1;
+ } else {
+ dev_err(drm->dev, "failed to add override mode\n");
+ }
+ }
+
+ /* Only add timings if override was not there or failed to validate */
+ if (num == 0 && panel->desc->num_timings)
+ num = panel_simple_get_timings_modes(panel);
+
+ /*
+* Only add fixed modes if timings/override added no mode.
+*
+* We should only ever have either the display timings specified
+* or a fixed mode. Anything else is rather bogus.
+*/
+ WARN_ON(panel->desc->num_timings &&
[PATCH v6 2/3] drm/panel: simple: Use display_timing for Innolux n116bge
Convert the Innolux n116bge from using a fixed mode to specifying a
display timing with min/typ/max values.
Note that the n116bge's datasheet doesn't fit too well into DRM's way
of specifying things. Specifically the panel's datasheet just
specifies the vertical blanking period and horizontal blanking period
and doesn't break things out. For now we'll leave everything as a
fixed value but just allow adjusting the pixel clock. I've added a
comment on what the datasheet claims so someone could later expand
things to fit their needs if they wanted to test other blanking
periods.
The goal here is to be able to specify the panel timings in the device
tree for several rk3288 Chromebooks (like rk3288-veryon-jerry). These
Chromebooks have all been running in the downstream kernel with the
standard porches and sync lengths but just with a slightly slower
pixel clock because the 76.42 MHz clock is not achievable from the
fixed PLL that was available. These Chromebooks only achieve a
refresh rate of ~58 Hz. While it's probable that we could adjust the
timings to achieve 60 Hz it's probably wisest to match what's been
running on these devices all these years.
I'll note that though the upstream kernel has always tried to achieve
76.42 MHz, it has actually been running at 74.25 MHz also since the
video processor is parented off the same fixed PLL.
Changes in v4:
- display_timing for Innolux n116bge new for v4.
Changes in v5:
- Added Heiko's Tested-by
Changes in v6:
- Rebased to drm-misc next
- Added tags
Signed-off-by: Douglas Anderson
Tested-by: Heiko Stuebner
Acked-by: Thierry Reding
---
drivers/gpu/drm/panel/panel-simple.c | 37 +---
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 1bee197821ef..602809f6da6a 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1702,23 +1702,32 @@ static const struct panel_desc innolux_g121x1_l03 = {
},
};
-static const struct drm_display_mode innolux_n116bge_mode = {
- .clock = 76420,
- .hdisplay = 1366,
- .hsync_start = 1366 + 136,
- .hsync_end = 1366 + 136 + 30,
- .htotal = 1366 + 136 + 30 + 60,
- .vdisplay = 768,
- .vsync_start = 768 + 8,
- .vsync_end = 768 + 8 + 12,
- .vtotal = 768 + 8 + 12 + 12,
- .vrefresh = 60,
- .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+/*
+ * Datasheet specifies that at 60 Hz refresh rate:
+ * - total horizontal time: { 1506, 1592, 1716 }
+ * - total vertical time: { 788, 800, 868 }
+ *
+ * ...but doesn't go into exactly how that should be split into a front
+ * porch, back porch, or sync length. For now we'll leave a single setting
+ * here which allows a bit of tweaking of the pixel clock at the expense of
+ * refresh rate.
+ */
+static const struct display_timing innolux_n116bge_timing = {
+ .pixelclock = { 7260, 7642, 8024 },
+ .hactive = { 1366, 1366, 1366 },
+ .hfront_porch = { 136, 136, 136 },
+ .hback_porch = { 60, 60, 60 },
+ .hsync_len = { 30, 30, 30 },
+ .vactive = { 768, 768, 768 },
+ .vfront_porch = { 8, 8, 8 },
+ .vback_porch = { 12, 12, 12 },
+ .vsync_len = { 12, 12, 12 },
+ .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW,
};
static const struct panel_desc innolux_n116bge = {
- .modes = _n116bge_mode,
- .num_modes = 1,
+ .timings = _n116bge_timing,
+ .num_timings = 1,
.bpc = 6,
.size = {
.width = 256,
--
2.22.0.410.gd8fdbe21b5-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/3] drm/panel: simple: Use display_timing for AUO b101ean01
Convert the AUO b101ean01 from using a fixed mode to specifying a
display timing with min/typ/max values.
The AUO b101ean01's datasheet says:
* Vertical blanking min is 12
* Horizontal blanking min is 60
* Pixel clock is between 65.3 MHz and 75 MHz
The goal here is to be able to specify the proper timing in device
tree to use on rk3288-veyron-minnie to match what the downstream
kernel is using so that it can used the fixed PLL.
Changes in v4:
- display_timing for AUO b101ean01 new for v4.
Changes in v6:
- Rebased to drm-misc next
- Added tags
Signed-off-by: Douglas Anderson
Acked-by: Thierry Reding
---
drivers/gpu/drm/panel/panel-simple.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 602809f6da6a..226f068fb679 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -595,22 +595,21 @@ static const struct panel_desc auo_b101aw03 = {
},
};
-static const struct drm_display_mode auo_b101ean01_mode = {
- .clock = 72500,
- .hdisplay = 1280,
- .hsync_start = 1280 + 119,
- .hsync_end = 1280 + 119 + 32,
- .htotal = 1280 + 119 + 32 + 21,
- .vdisplay = 800,
- .vsync_start = 800 + 4,
- .vsync_end = 800 + 4 + 20,
- .vtotal = 800 + 4 + 20 + 8,
- .vrefresh = 60,
+static const struct display_timing auo_b101ean01_timing = {
+ .pixelclock = { 6530, 7250, 7500 },
+ .hactive = { 1280, 1280, 1280 },
+ .hfront_porch = { 18, 119, 119 },
+ .hback_porch = { 21, 21, 21 },
+ .hsync_len = { 32, 32, 32 },
+ .vactive = { 800, 800, 800 },
+ .vfront_porch = { 4, 4, 4 },
+ .vback_porch = { 8, 8, 8 },
+ .vsync_len = { 18, 20, 20 },
};
static const struct panel_desc auo_b101ean01 = {
- .modes = _b101ean01_mode,
- .num_modes = 1,
+ .timings = _b101ean01_timing,
+ .num_timings = 1,
.bpc = 6,
.size = {
.width = 217,
--
2.22.0.410.gd8fdbe21b5-goog
Re: [PATCH v2] drm/i915: Copy name string into ring buffer for intel_update/disable_plane tracepoints
On Wed, Jul 10, 2019 at 08:12:30PM +0300, Ville Syrjala wrote:
> From: "Steven Rostedt (VMware)"
>
> Currently the intel_update_plane and intel_disable_plane tracepoints record
> the address of plane->name in the ring buffer, and then when reading the
> ring buffer uses %s to get the name. The issue with this, is that those two
> events can be minutes, hours or even days apart. It is very dangerous to
> dereference a string pointer without knowing if it still exists or not.
>
> The proper way to handle this is to use the __string() macro in the
> tracepoint which will save the string into the ring buffer at the time of
> recording. Then there's no worries if the original string still exists in
> memory when the ring buffer is read.
>
> Signed-off-by: Steven Rostedt (VMware)
> [vsyrjala: Rebase on top of drm-tip]
> Signed-off-by: Ville Syrjälä
CI is happy (not that we test this stuff) and I'm happy (the tracepoints
still work) -> pushed to drm-intel-next-queued. Thanks for the patch.
> ---
> drivers/gpu/drm/i915/i915_trace.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h
> b/drivers/gpu/drm/i915/i915_trace.h
> index cce426b23a24..da18b8d6b80c 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -293,16 +293,16 @@ TRACE_EVENT(intel_update_plane,
>
> TP_STRUCT__entry(
>__field(enum pipe, pipe)
> - __field(const char *, name)
>__field(u32, frame)
>__field(u32, scanline)
>__array(int, src, 4)
>__array(int, dst, 4)
> + __string(name, plane->name)
>),
>
> TP_fast_assign(
> +__assign_str(name, plane->name);
> __entry->pipe = crtc->pipe;
> -__entry->name = plane->name;
> __entry->frame = intel_crtc_get_vblank_counter(crtc);
> __entry->scanline = intel_get_crtc_scanline(crtc);
> memcpy(__entry->src, >state->src,
> sizeof(__entry->src));
> @@ -310,7 +310,7 @@ TRACE_EVENT(intel_update_plane,
> ),
>
> TP_printk("pipe %c, plane %s, frame=%u, scanline=%u, "
> DRM_RECT_FP_FMT " -> " DRM_RECT_FMT,
> - pipe_name(__entry->pipe), __entry->name,
> + pipe_name(__entry->pipe), __get_str(name),
> __entry->frame, __entry->scanline,
> DRM_RECT_FP_ARG((const struct drm_rect *)__entry->src),
> DRM_RECT_ARG((const struct drm_rect *)__entry->dst))
> @@ -322,20 +322,20 @@ TRACE_EVENT(intel_disable_plane,
>
> TP_STRUCT__entry(
>__field(enum pipe, pipe)
> - __field(const char *, name)
>__field(u32, frame)
>__field(u32, scanline)
> + __string(name, plane->name)
>),
>
> TP_fast_assign(
> +__assign_str(name, plane->name);
> __entry->pipe = crtc->pipe;
> -__entry->name = plane->name;
> __entry->frame = intel_crtc_get_vblank_counter(crtc);
> __entry->scanline = intel_get_crtc_scanline(crtc);
> ),
>
> TP_printk("pipe %c, plane %s, frame=%u, scanline=%u",
> - pipe_name(__entry->pipe), __entry->name,
> + pipe_name(__entry->pipe), __get_str(name),
> __entry->frame, __entry->scanline)
> );
>
> --
> 2.21.0
--
Ville Syrjälä
Intel
Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing
Hi Doug.
> > > > > @@ -91,6 +92,8 @@ struct panel_simple {
> > > > > struct i2c_adapter *ddc;
> > > > >
> > > > > struct gpio_desc *enable_gpio;
> > > > > +
> > > > > + struct drm_display_mode override_mode;
> > > > I fail to see where this poiter is assigned.
> > >
> > > In panel_simple_parse_override_mode(). Specifically:
> > >
> > > drm_display_mode_from_videomode(, >override_mode);
> >
> > The above code-snippet is only called in the panel has specified display
> > timings using display_timings - it is not called when display_mode is
> > used.
> > So override_mode is only assigned in some cases and not all cases.
> > This needs to be fixed so we do not reference override_mode unless
> > it is set.
>
> I'm afraid I'm not following you here.
>
> * override_mode is a structure that's directly part of "struct panel_simple".
I had somehow confused myself to think this was a pointer.
And you are right that override_mode is properly initialized when the
structure is allocated.
Sorry for not reading the code and your replies carefully enough.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi On Thu, Jul 11, 2019 at 7:43 PM Michael Nazzareno Trimarchi wrote: > > Hi Maxime > > On Thu, Jul 11, 2019 at 2:23 PM Maxime Ripard > wrote: > > > > On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > > > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > > > wrote: > > > > > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > > > instead of having > > > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might > > > > > > > > > > > > be a bug in > > > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > > > generated from > > > > > > > > > > > > the pixel clock, and it indeed looks like the ratio > > > > > > > > > > > > between the pixel > > > > > > > > > > > > clock and the TCON dotclock is defined through the > > > > > > > > > > > > number of bits per > > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same > > > > > > > > > > > > than lcd_rate, > > > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > > > dsi_rate == > > > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 > > > > > > > > > > > > MHz. Indeed, if > > > > > > > > > > > > we look at: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > > > different than > > > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, > > > > > > > > > > > > in the case of a > > > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 > > > > > > > > > > > > > > > > > > > > > > Let me explain, something more. > > > > > > > > > > > > > > > > > > > > > > According to bsp there are clk_info.tcon_div which I will > > > > > > > > > > > explain below. > > > > > > > > > > > clk_info.dsi_div which is dynamic and it depends on > > > > > > > > > > > bpp/lanes, so it > > > > > > > > > > > is 6 for 24bpp and 4 lanes devices. > > > > > > > > > > > > > > > > > > > > > > PLL rate here depends on dsi_div (not tcon_div) > > > > > > > > > > > > > > > > > > > > > > Code here > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L784 > > > > > > > > > > > > > > > > > > > > > > is computing the actual set rate, which depends on > > > > > > > > > > > dsi_rate. > > > > > > > > > > > > > > > > > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > > > > > > > > > dsi_rate = pll_rate / clk_info.dsi_div; > > > > > > > > > > > > > > > > > > > > > > Say if the dclk_rate 148MHz then the dsi_rate is 888MHz > > > > > > > > > > > which set rate > > > > > > > > > > > for above link you mentioned. > > > > > > > > > > > > > > > > > > > > > > Here are the evidence with some prints. > > > > > > > > > > > > > > > > > > > > > > https://gist.github.com/openedev/9bae2d87d2fcc06b999fe48c998b7043 > > > > > > > > > > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > > > > > > > > > > > > > > > > > > > Ok, so we agree up to this point, and the prints confirm > > > > > > > > > > that the > > > > > > > > > > analysis above is the right one. > > > > > > > > > > > > > > > > > > > > > > So, the DSI clock is set to this here: > > > > > > > > > > > >
Re: [PATCH v5 0/7] drm/panel: simple: Add mode support to devicetree
Hi Dough. > > So Thierry was able to look at the patches yesterday it seems and has Acked > > all the relevant ones. As a drm-misc-contributor I could also apply them > > myself, but now don't want to preempt any additional comments you might > > have ;-) . So I guess my question would be if you still want to do a review > > or if I should apply them. > > Hopefully you saw, but I responded to all of your review feedback. In > the end, I thought it'd be OK to land the series as-is and I can fix > up nits in a follow-up series, though I'm waiting for your responses > to a couple questions first. > > It would be ideal if you could confirm that you're OK with this plan > even if you don't have time to respond in detail to my emails yet. I > think Heiko can land them all through the appropriate channels since > the patches have all the proper Acks. My main concern was the bug cocerning override_mode - which turned out to be me confused. There is one part about flags that does not yet makes sense but we can fix it later. Please resend a series that applies to drm-misc-next so we can land this. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/7] drm/panel: simple: Add ability to override typical timing
On Wed, Jul 10, 2019 at 6:56 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 8, 2019 at 10:56 AM Sam Ravnborg wrote:
> >
> > On Mon, Jul 01, 2019 at 09:39:06AM -0700, Doug Anderson wrote:
> > > Hi,
> > >
> > > On Sun, Jun 30, 2019 at 1:55 PM Sam Ravnborg wrote:
> > > >
> > > > Hi Douglas.
> > > >
> > > > > > +
> > > > > > + /* Only add timings if override was not there or failed to
> > > > > > validate */
> > > > > > + if (num == 0 && panel->desc->num_timings)
> > > > > > + num = panel_simple_get_timings_modes(panel);
> > > > > > +
> > > > > > + /*
> > > > > > +* Only add fixed modes if timings/override added no mode.
> > > > >
> > > > > This part I fail to understand.
> > > > > If we have a panel where we in panel-simple have specified the
> > > > > timings,
> > > > > and done so using display_timing so with proper {min, typ, max} then
> > > > > it
> > > > > should be perfectly legal to specify a more precise variant in the DT
> > > > > file.
> > > > > Or what did I miss here?
> > > >
> > > > Got it now.
> > > > If display_mode is used for timings this is what you call "fixed mode".
> > > > Hmm, if I got confused someone else may also be confused by this naming.
> > >
> > > The name "fixed mode" comes from the old code, though I guess in the
> > > old code it used to refer to a mode that came from either the
> > > display_timing or the display_mode.
> > >
> > > How about if I call it "panel_simple_get_from_fixed_display_mode"?
> > > ...or if you have another suggestion feel free to chime in.
> > What we really want to distingush here is the use of display_mode
> > and display_timings (if I got the names right).
> > That display_mode specify a fixed timing and display_timing specify
> > a valid range is something in the semantics of the two types.
> > So naming that refer to display_mode versus display_timing will make the
> > code simpler to understand. and then a nice comment that when
> > display_mode
> > is used one looses the possibility to use override_mode.
> > That would be fine to have in the struct in the driver.
>
> OK, I can change the names here and try to find a good place to add a comment.
>
>
> > > NOTE: Since this feedback is minor and this patch has been outstanding
> > > for a while (and is blocking other work), I am assuming that the best
> > > path forward is for Heiko to land this patch with Thierry's Ack and
> > > I'll send a follow-up. Please yell if you disagree.
> > Let's give the patches a spin more as we have passed the possibility for
> > the current merge window.
>
> Any way I can convince you to change your mind here? There are no
> functional changes requested so far in your feedback and no bugs--it's
> just a few variable names and comments. By landing the existing
> patches as-is:
>
> 1. We stop spamming all the people CCed on this whole series (which
> includes device tree patches) that might be interested in the series
> as a whole but aren't interested in details.
>
> 2. We can debate the bikeshed-type issues on their own merit and I
> don't have to debate removing existing Acks / Reviewed-by / Tested-by
> tags as I make changes.
>
> 3. Even if it's not a good time to land the patches right now we know
> that these patches will be ready to land as soon as the window opens.
> As I mentioned earlier these patches are blocking other work [1] and
> landing that patch is actually preventing Matthias from submitting
> another series of patches to add support for rk3288-veyron-tiger and
> rk3288-veyron-fievel. Certainly I know that upstream doesn't make a
> policy of landing things just to suit the timelines of a downstream
> project, but in this case there seems very little downsides to landing
> the existing patches and taking a later cleanup patch.
>
[sending from my @chromium.org address so any appearance of bias is
explicit :) ]
Agree with Doug here, the naming and casting discussion is pretty
subjective and non-functional. We've got an Ack from Thierry and a
Review from Boris (both seasoned drm_panel'ers), this patch has been
sitting in review for a while. Let's not let the perfect be the enemy
of the good.
Sean
>
> > I am on vacation at the moment and thus slow in responses, but will be back
> > at the home office next week and will be more responsive again.
> >
> > Sam - who is enjoying the alps in Austria
>
> Hope you have had a great vacation!
>
> [1] https://lkml.kernel.org/r/20190625222629.154619-1-...@chromium.org
>
> -Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: remove dpu_mdss:hwversion
On Sun, Jun 30, 2019 at 06:14:42AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Unused and the extra rpm get/put interferes with handover from
> bootloader (ie. happens before we have a chance to check if
> things are already enabled).
Yay for not turning on the hardware before we need to.
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> index 986915bbbc02..e83dd4c6ec58 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> @@ -22,7 +22,6 @@ struct dpu_mdss {
> struct msm_mdss base;
> void __iomem *mmio;
> unsigned long mmio_len;
> - u32 hwversion;
> struct dss_module_power mp;
> struct dpu_irq_controller irq_controller;
> struct icc_path *path[2];
> @@ -287,10 +286,6 @@ int dpu_mdss_init(struct drm_device *dev)
>
> dpu_mdss_icc_request_bw(priv->mdss);
>
> - pm_runtime_get_sync(dev->dev);
> - dpu_mdss->hwversion = readl_relaxed(dpu_mdss->mmio);
> - pm_runtime_put_sync(dev->dev);
> -
> return ret;
>
> irq_error:
> --
> 2.20.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm: add mode flags in uapi for seamless mode switch
Add drm mode flag values to expose mode capabilities to perform dynamic seamless mode switch. This change also exposes the backing panel type associated with a mode for panels which can dynamically switch between video and command display modes. Signed-off-by: Jeykumar Sankaran --- include/uapi/drm/drm_mode.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 5ab331e..b76f1bf 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -124,6 +124,11 @@ #define DRM_MODE_FLAG_PIC_AR_256_135 \ (DRM_MODE_PICTURE_ASPECT_256_135<<19) +#define DRM_MODE_FLAG_SEAMLESS_SWITCH (1<<23) + +#define DRM_MODE_FLAG_VIDEO_MODE (1<<24) +#define DRM_MODE_FLAG_COMMAND_MODE (1<<25) + #define DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \ DRM_MODE_FLAG_NHSYNC | \ DRM_MODE_FLAG_PVSYNC | \ -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/msm: don't open-code governor name
On Sun, Jun 30, 2019 at 06:14:41AM -0700, Rob Clark wrote:
> From: Rob Clark
Reviewed-by: Jordan Crouse
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 0a4c77fb3d94..e323259a16d3 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -106,7 +106,7 @@ static void msm_devfreq_init(struct msm_gpu *gpu)
>*/
>
> gpu->devfreq.devfreq = devm_devfreq_add_device(>pdev->dev,
> - _devfreq_profile, "simple_ondemand", NULL);
> + _devfreq_profile, DEVFREQ_GOV_SIMPLE_ONDEMAND,
> NULL);
>
> if (IS_ERR(gpu->devfreq.devfreq)) {
> DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
> devfreq\n");
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] Expanding drm_mode_modeinfo flags
Hello All, drm_mode_modeinfo::flags is a 32 bit field currently used to describe the properties of a connector mode. I see the least order 22 bits are already in use. Posting this RFC to discuss on any potential plans to expand the bit range support of this field for growing mode properties and ways to handle one such property needed by the msm dpu driver. msm drivers support panels which can dynamically switch between video(active) and command(smart) modes. Within video mode, they also support switching between resolutions seamlessly i.e. glitch free resolution switch. But they cannot do a seamless switch from a resolutions from video to command or vice versa. Clients need to be aware for these capablities before they switch between the resolutions. Since these capabilities are identified per drm_mode, we are considering the below two approaches to handle this use case. Option 1: Attached patch adds flag values to associate a drm_mode to video/command mode and to indicate its capability to do a seamless switch. Option 2: drm_mode_modeinfo can expose a new "private_flags" field to handle vendor specific mode flags. Besides the above mentioned use case, we are also expoloring methods to handle some of our display port resolution switch use cases where the DP ports can be operated in a tiled/detiled modes. This approach will provide a standard channel for drm driver vendors for their growing need for drm_mode specific capabilities. Please provide your inputs on the options or any upstream friendly recommendation to handle such custom use cases. Thanks and Regards, Jeykumar S. Jeykumar Sankaran (1): drm: add mode flags in uapi for seamless mode switch include/uapi/drm/drm_mode.h | 5 + 1 file changed, 5 insertions(+) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 AngryPenguin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
Hi Maxime On Thu, Jul 11, 2019 at 2:23 PM Maxime Ripard wrote: > > On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > > wrote: > > > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > > wrote: > > > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > > instead of having > > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might be > > > > > > > > > > > a bug in > > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > > generated from > > > > > > > > > > > the pixel clock, and it indeed looks like the ratio > > > > > > > > > > > between the pixel > > > > > > > > > > > clock and the TCON dotclock is defined through the number > > > > > > > > > > > of bits per > > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same than > > > > > > > > > > > lcd_rate, > > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > > dsi_rate == > > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 MHz. > > > > > > > > > > > Indeed, if > > > > > > > > > > > we look at: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > > different than > > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, in > > > > > > > > > > > the case of a > > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 > > > > > > > > > > > > > > > > > > > > Let me explain, something more. > > > > > > > > > > > > > > > > > > > > According to bsp there are clk_info.tcon_div which I will > > > > > > > > > > explain below. > > > > > > > > > > clk_info.dsi_div which is dynamic and it depends on > > > > > > > > > > bpp/lanes, so it > > > > > > > > > > is 6 for 24bpp and 4 lanes devices. > > > > > > > > > > > > > > > > > > > > PLL rate here depends on dsi_div (not tcon_div) > > > > > > > > > > > > > > > > > > > > Code here > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L784 > > > > > > > > > > > > > > > > > > > > is computing the actual set rate, which depends on dsi_rate. > > > > > > > > > > > > > > > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > > > > > > > > dsi_rate = pll_rate / clk_info.dsi_div; > > > > > > > > > > > > > > > > > > > > Say if the dclk_rate 148MHz then the dsi_rate is 888MHz > > > > > > > > > > which set rate > > > > > > > > > > for above link you mentioned. > > > > > > > > > > > > > > > > > > > > Here are the evidence with some prints. > > > > > > > > > > > > > > > > > > > > https://gist.github.com/openedev/9bae2d87d2fcc06b999fe48c998b7043 > > > > > > > > > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > > > > > > > > > > > > > > > > > Ok, so we agree up to this point, and the prints confirm that > > > > > > > > > the > > > > > > > > > analysis above is the right one. > > > > > > > > > > > > > > > > > > > > So, the DSI clock is set to this here: > > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L805 > > > > > > > > > > > > > > > > > > Your patch doesn't address that, so let's leave that one > > > > > > > > > alone. > > > > > > > > > > > > > > > > Basically this is final pll set rate when sun4i_dotclock.c > > > > > > > > called the > > > > >
Re: [PATCH] drm/bridge: ti-sn65dsi86: use dev name for debugfs
On Thu, Jul 11, 2019 at 9:49 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Sat, Jul 06, 2019 at 01:31:02PM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > This should be more future-proof if we ever encounter a device with two
> > of these bridges.
> >
> > Suggested-by: Laurent Pinchart
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > index c8fb45e7b06d..9f4ff88d4a10 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> > @@ -204,7 +204,7 @@ DEFINE_SHOW_ATTRIBUTE(status);
> >
> > static void ti_sn_debugfs_init(struct ti_sn_bridge *pdata)
> > {
> > - pdata->debugfs = debugfs_create_dir("ti_sn65dsi86", NULL);
> > + pdata->debugfs = debugfs_create_dir(dev_name(pdata->dev), NULL);
>
> That should work, but won't it become quite confusing for users ? I
> wonder if the directory name shouldn't be prefixed with the driver name.
> Something like "ti_sn65dsi86:%s", dev_name(pdata->dev).
*maybe*, if they are badly named in dt? In the end the target
audience is really to help developers and people bringing up a new
board, so maybe my way encourages them to use sensible names in dt ;-)
BR,
-R
>
> > debugfs_create_file("status", 0600, pdata->debugfs, pdata,
> > _fops);
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH v4 17/23] drm/ast: Provide ddc symlink in connector sysfs directory
Acked-by: Thomas Zimmermann
Am 11.07.19 um 13:26 schrieb Andrzej Pietrasiewicz:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/ast/ast_mode.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index ffccbef962a4..1ca9bc4aa3bb 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -890,6 +890,11 @@ static int ast_connector_init(struct drm_device *dev)
> return -ENOMEM;
>
> connector = _connector->base;
> + ast_connector->i2c = ast_i2c_create(dev);
> + if (!ast_connector->i2c)
> + DRM_ERROR("failed to add ddc bus for connector\n");
> +
> + connector->ddc = _connector->i2c->adapter;
> drm_connector_init(dev, connector, _connector_funcs,
> DRM_MODE_CONNECTOR_VGA);
>
> drm_connector_helper_add(connector, _connector_helper_funcs);
> @@ -904,10 +909,6 @@ static int ast_connector_init(struct drm_device *dev)
> encoder = list_first_entry(>mode_config.encoder_list, struct
> drm_encoder, head);
> drm_connector_attach_encoder(connector, encoder);
>
> - ast_connector->i2c = ast_i2c_create(dev);
> - if (!ast_connector->i2c)
> - DRM_ERROR("failed to add ddc bus for connector\n");
> -
> return 0;
> }
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 16/23] drm/mgag200: Provide ddc symlink in connector sysfs directory
Acked-by: Thomas Zimmermann
Am 11.07.19 um 13:26 schrieb Andrzej Pietrasiewicz:
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
> b/drivers/gpu/drm/mgag200/mgag200_mode.c
> index a25054015e8c..8fb9444b2142 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_mode.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
> @@ -1703,6 +1703,11 @@ static struct drm_connector *mga_vga_init(struct
> drm_device *dev)
> return NULL;
>
> connector = _connector->base;
> + mga_connector->i2c = mgag200_i2c_create(dev);
> + if (!mga_connector->i2c)
> + DRM_ERROR("failed to add ddc bus\n");
> +
> + connector->ddc = _connector->i2c->adapter;
>
> drm_connector_init(dev, connector,
> _vga_connector_funcs, DRM_MODE_CONNECTOR_VGA);
> @@ -1711,10 +1716,6 @@ static struct drm_connector *mga_vga_init(struct
> drm_device *dev)
>
> drm_connector_register(connector);
>
> - mga_connector->i2c = mgag200_i2c_create(dev);
> - if (!mga_connector->i2c)
> - DRM_ERROR("failed to add ddc bus\n");
> -
> return connector;
> }
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-sn65dsi86: use dev name for debugfs
Hi Rob,
Thank you for the patch.
On Sat, Jul 06, 2019 at 01:31:02PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> This should be more future-proof if we ever encounter a device with two
> of these bridges.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c8fb45e7b06d..9f4ff88d4a10 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -204,7 +204,7 @@ DEFINE_SHOW_ATTRIBUTE(status);
>
> static void ti_sn_debugfs_init(struct ti_sn_bridge *pdata)
> {
> - pdata->debugfs = debugfs_create_dir("ti_sn65dsi86", NULL);
> + pdata->debugfs = debugfs_create_dir(dev_name(pdata->dev), NULL);
That should work, but won't it become quite confusing for users ? I
wonder if the directory name shouldn't be prefixed with the driver name.
Something like "ti_sn65dsi86:%s", dev_name(pdata->dev).
> debugfs_create_file("status", 0600, pdata->debugfs, pdata,
> _fops);
--
Regards,
Laurent Pinchart
Re: [PATCH] drm/msm/phy/dsi_phy: silence -EPROBE_DEFER warnings
On Sat 06 Jul 04:11 PDT 2019, Brian Masney wrote:
> The following errors show up when booting the Nexus 5:
>
> msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR*
> dsi_phy_regulator_init: failed to init regulator, ret=-517
> msm_dsi_phy fd922a00.dsi-phy: [drm:dsi_phy_driver_probe] *ERROR*
> dsi_phy_driver_probe: failed to init regulator
>
> dsi_phy_regulator_init() already logs the error, so no need to log
> the same error a second time in dsi_phy_driver_probe(). This patch
> also changes dsi_phy_regulator_init() to not log the error if the
> error code is -EPROBE_DEFER to reduce noise in dmesg.
>
> Signed-off-by: Brian Masney
> ---
> drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> index 4097eca1b3ef..d0e1cc6728dc 100644
> --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
> @@ -396,8 +396,11 @@ static int dsi_phy_regulator_init(struct msm_dsi_phy
> *phy)
>
> ret = devm_regulator_bulk_get(dev, num, s);
> if (ret < 0) {
> - DRM_DEV_ERROR(dev, "%s: failed to init regulator, ret=%d\n",
> - __func__, ret);
> + if (ret != -EPROBE_DEFER)
> + DRM_DEV_ERROR(dev,
> + "%s: failed to init regulator, ret=%d\n",
> + __func__, ret);
Some {} wouldn't hurt here, but not a big deal.
Reviewed-by: Bjorn Andersson
> +
> return ret;
> }
>
> @@ -584,10 +587,8 @@ static int dsi_phy_driver_probe(struct platform_device
> *pdev)
> }
>
> ret = dsi_phy_regulator_init(phy);
> - if (ret) {
> - DRM_DEV_ERROR(dev, "%s: failed to init regulator\n", __func__);
> + if (ret)
> goto fail;
> - }
>
> phy->ahb_clk = msm_clk_get(pdev, "iface");
> if (IS_ERR(phy->ahb_clk)) {
> --
> 2.20.1
>
Re: [PATCH] drm/bridge: ti-sn65dsi86: use dev name for debugfs
On Sat 06 Jul 13:31 PDT 2019, Rob Clark wrote:
> From: Rob Clark
>
> This should be more future-proof if we ever encounter a device with two
> of these bridges.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Rob Clark
Reviewed-by: Bjorn Andersson
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c8fb45e7b06d..9f4ff88d4a10 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -204,7 +204,7 @@ DEFINE_SHOW_ATTRIBUTE(status);
>
> static void ti_sn_debugfs_init(struct ti_sn_bridge *pdata)
> {
> - pdata->debugfs = debugfs_create_dir("ti_sn65dsi86", NULL);
> + pdata->debugfs = debugfs_create_dir(dev_name(pdata->dev), NULL);
>
> debugfs_create_file("status", 0600, pdata->debugfs, pdata,
> _fops);
> --
> 2.20.1
>
[Bug 111111] Corrupted output with vaapi 10 bit -> 8 bit transcoding on AMD RAVEN
https://bugs.freedesktop.org/show_bug.cgi?id=11 Bug ID: 11 Summary: Corrupted output with vaapi 10 bit -> 8 bit transcoding on AMD RAVEN Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: gre...@outlook.com QA Contact: dri-devel@lists.freedesktop.org Initially, I've filled ffmpeg bug since vaapi transcoding 10 bit > 8 bit was just failing, someone refereed to a "separated field of surfaces bug" which I couldn't find and offered patch which fixed the initial issue here: https://trac.ffmpeg.org/ticket/7764 After applying patch transcoding goes through with significant speed increase [from 2x to 7x] but the resulting output has flashing green overlay/glitch in upper half of the video. E.g from command" ffmpeg -threads 4 \ -init_hw_device vaapi=amd:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device amd -filter_hw_device amd \ -i trk.mkv \ -vf "scale_vaapi=format=nv12,hwupload" \ -c:v h264_vaapi -profile:v 578 \ -c:a copy -bf 0 -c:s copy \ -f mpegts -y plop.mkv Input is any 10 bit hevc video. Vainfo:libva info: VA-API version 1.6.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib64/va/drivers/radeonsi_drv_video.so libva info: Found init function __vaDriverInit_1_6 libva info: va_openDriver() returns 0 vainfo: VA-API version: 1.6 (libva 2.6.0.pre1) vainfo: Driver version: Mesa Gallium driver 19.2.0-devel for AMD RAVEN (DRM 3.32.0, 5.2.0-gentoo, LLVM 8.0.0) vainfo: Supported profile and entrypoints VAProfileMPEG2Simple: VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main: VAEntrypointVLD VAProfileVC1Advanced: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileJPEGBaseline : VAEntrypointVLD VAProfileVP9Profile0: VAEntrypointVLD VAProfileVP9Profile2: VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc mesa git AMD RAVEN APU 2200G -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/syncobj: Include the prototype for drm_timeout_abs_to_jiffies()
On Thu, Jul 11, 2019 at 11:39:15AM -0400, Sean Paul wrote: > On Wed, Jul 10, 2019 at 03:51:42PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Sparse complains: > > ../drivers/gpu/drm/drm_syncobj.c:942:13: warning: symbol > > 'drm_timeout_abs_to_jiffies' was not declared. Should it be static? > > > > Include the correct header with the prototype. > > > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_syncobj.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c > > index a199c8d56b95..00eecc9c464b 100644 > > --- a/drivers/gpu/drm/drm_syncobj.c > > +++ b/drivers/gpu/drm/drm_syncobj.c > > @@ -58,6 +58,7 @@ > > #include > > #include > > #include > > +#include > > Just realized we have both drm_util.h and drm_utils.h, what a world! On my TODO list to get rid of one of them. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1] drm/modes: Skip invalid cmdline mode
11.07.2019 12:03, Maxime Ripard пишет: > On Wed, Jul 10, 2019 at 06:05:18PM +0300, Dmitry Osipenko wrote: >> 10.07.2019 17:05, Maxime Ripard пишет: >>> On Wed, Jul 10, 2019 at 04:29:19PM +0300, Dmitry Osipenko wrote: This works: diff --git a/drivers/gpu/drm/drm_client_modeset.c b/drivers/gpu/drm/drm_client_modeset.c index 56d36779d213..e5a2f9c8f404 100644 --- a/drivers/gpu/drm/drm_client_modeset.c +++ b/drivers/gpu/drm/drm_client_modeset.c @@ -182,6 +182,8 @@ drm_connector_pick_cmdline_mode(struct drm_connector *connector) mode = drm_mode_create_from_cmdline_mode(connector->dev, cmdline_mode); if (mode) list_add(>head, >modes); + else + cmdline_mode->specified = false; >>> >>> Hmmm, it's not clear to me why that wouldn't be the case. >>> >>> If we come back to the beginning of that function, we retrieve the >>> cmdline_mode buffer from the connector pointer, that will probably >>> have been parsed a first time using drm_mode_create_from_cmdline_mode >>> in drm_helper_probe_add_cmdline_mode. >>> >>> Now, I'm guessing that the issue is that in >>> drm_mode_parse_command_line_for_connector, if we have a named mode, we >>> just copy the mode over and set mode->specified. >>> >>> And we then move over to do other checks, and that's probably what >>> fails and returns, but our drm_cmdline_mode will have been modified. >>> >>> I'm not entirely sure how to deal with that though. >>> >>> I guess we could allocate a drm_cmdline_mode structure on the stack, >>> fill that, and if successful copy over its content to the one in >>> drm_connector. That would allow us to only change the content on >>> success, which is what I would expect from such a function? >>> >>> How does that sound? >> >> I now see that there is DRM_MODE_TYPE_USERDEF flag that is assigned only >> for the "cmdline" mode and drm_client_rotation() is the only place in >> DRM code that cares about whether mode is from cmdline, hence looks like >> it will be more correct to do the following: > > I'm still under the impression that we're dealing with workarounds of > a more central issue, which is that we shouldn't return a partially > modified drm_cmdline_mode. > > You said it yourself, the breakage is in the commit changing the > command line parsing logic, while you're fixing here some code that > was introduced later on. The problem stems from assumption that *any* named mode is valid. It looks to me that the ultimate solution would be to move the mode's name comparison into the [1], if that's possible. [1] drm_mode_parse_command_line_for_connector() > Can you try the followintg patch? > http://code.bulix.org/8cwk4c-794565?raw This doesn't help because the problem with the rotation_reflection is that it's 0 if "rotation" not present in the cmdline and then ilog2(0) returns -1. So the patch "drm/modes: Don't apply cmdline's rotation if it wasn't specified" should be correct in any case.
Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
On Thu, Jul 11, 2019 at 05:12:26PM +0200, Andrzej Hajda wrote:
> On 11.07.2019 15:18, Daniel Vetter wrote:
> > On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> >> On 11.07.2019 09:35, Daniel Vetter wrote:
> >>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> Hi Laurent,
>
>
> I like the approach, current practice when almost every bridge should
> optionally implement connector, or alternatively downstream bridge or
> panel is very painful.
> >>> Yeah I think this looks mostly reasonable. Some api design comments on top
> >>> of Andrzej', with the fair warning that I didn't bother to read up on how
> >>> it's all used in the end. I probably should go and do that, at least to
> >>> get a feeling for what your hpd_cb usually does.
> >>>
> More comments inlined.
>
> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > To support implementation of DRM connectors on top of DRM bridges
> > instead of by bridges, the drm_bridge needs to expose new operations and
> > data:
> >
> > - Output detection, hot-plug notification, mode retrieval and EDID
> > retrieval operations
> > - Bitmask of supported operations
> Why do we need these bitmask at all? Why cannot we rely on presence of
> operation's callback?
> >>> Yeah also not a huge fan of these bitmasks. Smells like
> >>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> >>> add, generally good excuse to not have to think through the design between
> >>> different parts of drivers - "just" add another flag.
> > - Bridge output type
> >
> > Add and document these.
> >
> > Three new bridge helper functions are also added to handle hot plug
> > notification in a way that is as transparent as possible for the
> > bridges.
> Documentation of new opses does not explain how it should cooperate with
> bridge chaining, I suppose they should be chained explicitly, am I
> right? More comments about it later.
>
>
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/drm_bridge.c | 92 +++
> > include/drm/drm_bridge.h | 170 ++-
> > 2 files changed, 261 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index 519577f363e3..3c2a255df7af 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> > */
> > void drm_bridge_add(struct drm_bridge *bridge)
> > {
> > + mutex_init(>hpd_mutex);
> > +
> > mutex_lock(_lock);
> > list_add_tail(>list, _list);
> > mutex_unlock(_lock);
> > @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> > mutex_lock(_lock);
> > list_del_init(>list);
> > mutex_unlock(_lock);
> > +
> > + mutex_destroy(>hpd_mutex);
> > }
> > EXPORT_SYMBOL(drm_bridge_remove);
> >
> > @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge
> > *bridge,
> > }
> > EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >
> > +/**
> > + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> > + * @bridge: bridge control structure
> > + * @cb: hot-plug detection callback
> > + * @data: data to be passed to the hot-plug detection callback
> > + *
> > + * Call _bridge_funcs.hpd_enable and register the given @cb and
> > @data as
> > + * hot plug notification callback. From now on the @cb will be called
> > with
> > + * @data when an output status change is detected by the bridge, until
> > hot plug
> > + * notification gets disabled with drm_bridge_hpd_disable().
> > + *
> > + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag
> > is set in
> > + * bridge->ops. This function shall not be called when the flag is not
> > set.
> > + *
> > + * Only one hot plug detection callback can be registered at a time,
> > it is an
> > + * error to call this function when hot plug detection is already
> > enabled for
> > + * the bridge.
> > + */
> To simplify architecture maybe would be better to enable hpd just on
> bridge attach:
>
> bridge->hpd_cb = cb;
>
> bridge->hpd_data = data;
>
> ret = drm_bridge_attach(...);
> >>> Yeah I like this more. The other problem here is, what if you need more
> >>> than 1 callback registers on the same bridge hdp signal?
> >>>
> >>>
> This way we could avoid adding new callbacks hpd_(enable|disable)
> without big sacrifices.
>
>
> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> notifies about sink status change, how it
Re: [PATCH 5/5] drm: Fix return type of crc .poll()
On Wed, Jul 10, 2019 at 03:51:43PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Sparse compains:
> ../drivers/gpu/drm/drm_debugfs_crc.c:350:17: warning: incorrect type in
> initializer (different base types)
> ../drivers/gpu/drm/drm_debugfs_crc.c:350:17:expected restricted __poll_t
> ( *poll )( ... )
> ../drivers/gpu/drm/drm_debugfs_crc.c:350:17:got unsigned int ( * )( ... )
>
> Change the .poll() return type to __poll_t to silence it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_debugfs_crc.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index 7ca486d750e9..284d615ed08b 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -325,19 +325,17 @@ static ssize_t crtc_crc_read(struct file *filep, char
> __user *user_buf,
> return LINE_LEN(crc->values_cnt);
> }
>
> -static unsigned int crtc_crc_poll(struct file *file, poll_table *wait)
> +static __poll_t crtc_crc_poll(struct file *file, poll_table *wait)
> {
> struct drm_crtc *crtc = file->f_inode->i_private;
> struct drm_crtc_crc *crc = >crc;
> - unsigned ret;
> + __poll_t ret = 0;
>
> poll_wait(file, >wq, wait);
>
> spin_lock_irq(>lock);
> if (crc->source && crtc_crc_data_count(crc))
> - ret = POLLIN | POLLRDNORM;
> - else
> - ret = 0;
> + ret |= EPOLLIN | EPOLLRDNORM;
> spin_unlock_irq(>lock);
>
> return ret;
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/5] drm/syncobj: Include the prototype for drm_timeout_abs_to_jiffies()
On Wed, Jul 10, 2019 at 03:51:42PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Sparse complains: > ../drivers/gpu/drm/drm_syncobj.c:942:13: warning: symbol > 'drm_timeout_abs_to_jiffies' was not declared. Should it be static? > > Include the correct header with the prototype. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_syncobj.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c > index a199c8d56b95..00eecc9c464b 100644 > --- a/drivers/gpu/drm/drm_syncobj.c > +++ b/drivers/gpu/drm/drm_syncobj.c > @@ -58,6 +58,7 @@ > #include > #include > #include > +#include Just realized we have both drm_util.h and drm_utils.h, what a world! Reviewed-by: Sean Paul > > #include "drm_internal.h" > > -- > 2.21.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm: Include prototype for drm_need_swiotlb()
On Wed, Jul 10, 2019 at 03:51:41PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Sparse is not happy: > ../drivers/gpu/drm/drm_memory.c:159:6: warning: symbol 'drm_need_swiotlb' was > not declared. Should it be static? > > Include the correct header for drm_need_swiotlb() prototype. > > Signed-off-by: Ville Syrjälä Reviewed-by: Sean Paul > --- > drivers/gpu/drm/drm_memory.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_memory.c b/drivers/gpu/drm/drm_memory.c > index b634e1670190..477937bb902e 100644 > --- a/drivers/gpu/drm/drm_memory.c > +++ b/drivers/gpu/drm/drm_memory.c > @@ -40,6 +40,7 @@ > #include > > #include > +#include > #include > > #include "drm_legacy.h" > -- > 2.21.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] drm/dsc: Fix bogus cpu_to_be16() usage
On Wed, Jul 10, 2019 at 03:51:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> __be16 = cpu_to_be16(__be16) is nonsense. Do it right.
>
> ../drivers/gpu/drm/drm_dsc.c:218:53: warning: incorrect type in assignment
> (different base types)
> ../drivers/gpu/drm/drm_dsc.c:218:53:expected restricted __be16
> ../drivers/gpu/drm/drm_dsc.c:218:53:got int
> ../drivers/gpu/drm/drm_dsc.c:225:25: warning: cast from restricted __be16
> ../drivers/gpu/drm/drm_dsc.c:225:25: warning: incorrect type in argument 1
> (different base types)
> ../drivers/gpu/drm/drm_dsc.c:225:25:expected unsigned short [usertype] val
> ../drivers/gpu/drm/drm_dsc.c:225:25:got restricted __be16
> ../drivers/gpu/drm/drm_dsc.c:225:25: warning: cast from restricted __be16
> ../drivers/gpu/drm/drm_dsc.c:225:25: warning: cast from restricted __be16
>
> Cc: Manasi Navare
> Cc: David Francis
> Signed-off-by: Ville Syrjälä
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_dsc.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index 77f4e5ae4197..f2fc47f123d2 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -216,13 +216,11 @@ void drm_dsc_pps_payload_pack(struct
> drm_dsc_picture_parameter_set *pps_payload,
>*/
> for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
> pps_payload->rc_range_parameters[i] =
> - ((dsc_cfg->rc_range_params[i].range_min_qp <<
> - DSC_PPS_RC_RANGE_MINQP_SHIFT) |
> - (dsc_cfg->rc_range_params[i].range_max_qp <<
> - DSC_PPS_RC_RANGE_MAXQP_SHIFT) |
> - (dsc_cfg->rc_range_params[i].range_bpg_offset));
> - pps_payload->rc_range_parameters[i] =
> - cpu_to_be16(pps_payload->rc_range_parameters[i]);
> + cpu_to_be16((dsc_cfg->rc_range_params[i].range_min_qp <<
> + DSC_PPS_RC_RANGE_MINQP_SHIFT) |
> + (dsc_cfg->rc_range_params[i].range_max_qp <<
> + DSC_PPS_RC_RANGE_MAXQP_SHIFT) |
> +
> (dsc_cfg->rc_range_params[i].range_bpg_offset));
> }
>
> /* PPS 88 */
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/fb-helper: Include prototype for drm_fb_helper_modinit()
On Wed, Jul 10, 2019 at 03:51:39PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Sparse complains: > drivers/gpu/drm/drm_fb_helper.c:2409:12: warning: symbol > 'drm_fb_helper_modinit' was not declared. Should it be static? > > Include the header with the correct prototype. > > Signed-off-by: Ville Syrjälä Reviewed-by: Sean Paul > --- > drivers/gpu/drm/drm_fb_helper.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index a7ba5b4902d6..b75ae8555baf 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -46,6 +46,7 @@ > #include > #include > > +#include "drm_crtc_helper_internal.h" > #include "drm_internal.h" > > static bool drm_fbdev_emulation = true; > -- > 2.21.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v9 3/6] drm: uevent for connector status change
On Mon, Jul 08, 2019 at 04:51:13PM +0530, Ramalingam C wrote:
> DRM API for generating uevent for a status changes of connector's
> property.
>
> This uevent will have following details related to the status change:
>
> HOTPLUG=1, CONNECTOR= and PROPERTY=
>
> Need ACK from this uevent from userspace consumer.
>
> v2:
> Minor fixes at KDoc comments [Daniel]
> v3:
> Check the property is really attached with connector [Daniel]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_sysfs.c | 35 +++
> include/drm/drm_sysfs.h | 5 -
> 2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ad10810bc972..d13a77057045 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -26,6 +26,7 @@
> #include
>
> #include "drm_internal.h"
> +#include "drm_crtc_internal.h"
>
> #define to_drm_minor(d) dev_get_drvdata(d)
> #define to_drm_connector(d) dev_get_drvdata(d)
> @@ -325,6 +326,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
> * Send a uevent for the DRM device specified by @dev. Currently we only
> * set HOTPLUG=1 in the uevent environment, but this could be expanded to
> * deal with other types of events.
> + *
> + * Any new uapi should be using the drm_sysfs_connector_status_event()
> + * for uevents on connector status change.
> */
> void drm_sysfs_hotplug_event(struct drm_device *dev)
> {
> @@ -337,6 +341,37 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_sysfs_hotplug_event);
>
> +/**
> + * drm_sysfs_connector_status_event - generate a DRM uevent for connector
> + * property status change
> + * @connector: connector on which property status changed
> + * @property: connector property whoes status changed.
s/whoes/whose/
> + *
> + * Send a uevent for the DRM device specified by @dev. Currently we
> + * set HOTPLUG=1 and connector id along with the attached property id
> + * related to the status change.
> + */
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> + struct drm_property *property)
> +{
> + struct drm_device *dev = connector->dev;
> + char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
30 chars is a bit aggressive. UINT_MAX will only take up 10 chars, so with
the NULL char, you should only need 21 for conn_id and 20 for prop_id.
> + char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
> +
> + WARN_ON(!drm_mode_obj_find_prop_id(>base,
> +property->base.id));
> +
> + snprintf(conn_id, ARRAY_SIZE(conn_id),
> + "CONNECTOR=%u", connector->base.id);
> + snprintf(prop_id, ARRAY_SIZE(prop_id),
> + "PROPERTY=%u", property->base.id);
> +
> + DRM_DEBUG("generating connector status event\n");
> +
> + kobject_uevent_env(>primary->kdev->kobj, KOBJ_CHANGE, envp);
> +}
> +EXPORT_SYMBOL(drm_sysfs_connector_status_event);
With nits addressed,
Reviewed-by: Sean Paul
> +
> static void drm_sysfs_release(struct device *dev)
> {
> kfree(dev);
> diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
> index 4f311e836cdc..d454ef617b2c 100644
> --- a/include/drm/drm_sysfs.h
> +++ b/include/drm/drm_sysfs.h
> @@ -4,10 +4,13 @@
>
> struct drm_device;
> struct device;
> +struct drm_connector;
> +struct drm_property;
>
> int drm_class_device_register(struct device *dev);
> void drm_class_device_unregister(struct device *dev);
>
> void drm_sysfs_hotplug_event(struct drm_device *dev);
> -
> +void drm_sysfs_connector_status_event(struct drm_connector *connector,
> + struct drm_property *property);
> #endif
> --
> 2.19.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
On 11.07.2019 15:18, Daniel Vetter wrote:
> On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
>> On 11.07.2019 09:35, Daniel Vetter wrote:
>>> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
Hi Laurent,
I like the approach, current practice when almost every bridge should
optionally implement connector, or alternatively downstream bridge or
panel is very painful.
>>> Yeah I think this looks mostly reasonable. Some api design comments on top
>>> of Andrzej', with the fair warning that I didn't bother to read up on how
>>> it's all used in the end. I probably should go and do that, at least to
>>> get a feeling for what your hpd_cb usually does.
>>>
More comments inlined.
On 07.07.2019 20:18, Laurent Pinchart wrote:
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval operations
> - Bitmask of supported operations
Why do we need these bitmask at all? Why cannot we rely on presence of
operation's callback?
>>> Yeah also not a huge fan of these bitmasks. Smells like
>>> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
>>> add, generally good excuse to not have to think through the design between
>>> different parts of drivers - "just" add another flag.
> - Bridge output type
>
> Add and document these.
>
> Three new bridge helper functions are also added to handle hot plug
> notification in a way that is as transparent as possible for the
> bridges.
Documentation of new opses does not explain how it should cooperate with
bridge chaining, I suppose they should be chained explicitly, am I
right? More comments about it later.
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_bridge.c | 92 +++
> include/drm/drm_bridge.h | 170 ++-
> 2 files changed, 261 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 519577f363e3..3c2a255df7af 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> */
> void drm_bridge_add(struct drm_bridge *bridge)
> {
> + mutex_init(>hpd_mutex);
> +
> mutex_lock(_lock);
> list_add_tail(>list, _list);
> mutex_unlock(_lock);
> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> mutex_lock(_lock);
> list_del_init(>list);
> mutex_unlock(_lock);
> +
> + mutex_destroy(>hpd_mutex);
> }
> EXPORT_SYMBOL(drm_bridge_remove);
>
> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge
> *bridge,
> }
> EXPORT_SYMBOL(drm_atomic_bridge_enable);
>
> +/**
> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> + * @bridge: bridge control structure
> + * @cb: hot-plug detection callback
> + * @data: data to be passed to the hot-plug detection callback
> + *
> + * Call _bridge_funcs.hpd_enable and register the given @cb and
> @data as
> + * hot plug notification callback. From now on the @cb will be called
> with
> + * @data when an output status change is detected by the bridge, until
> hot plug
> + * notification gets disabled with drm_bridge_hpd_disable().
> + *
> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is
> set in
> + * bridge->ops. This function shall not be called when the flag is not
> set.
> + *
> + * Only one hot plug detection callback can be registered at a time, it
> is an
> + * error to call this function when hot plug detection is already
> enabled for
> + * the bridge.
> + */
To simplify architecture maybe would be better to enable hpd just on
bridge attach:
bridge->hpd_cb = cb;
bridge->hpd_data = data;
ret = drm_bridge_attach(...);
>>> Yeah I like this more. The other problem here is, what if you need more
>>> than 1 callback registers on the same bridge hdp signal?
>>>
>>>
This way we could avoid adding new callbacks hpd_(enable|disable)
without big sacrifices.
One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
notifies about sink status change, how it translates to this cb?
> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> +void (*cb)(void *data,
> + enum drm_connector_status status),
> +void *data)
> +{
> + if (!bridge || !bridge->funcs->hpd_enable)
> + return;
> +
> +
Re: [PATCH 00/10] Improvements and fixes for mxsfb DRM driver
Hi Robert, On Wed, Jun 26, 2019 at 04:32:08PM +0300, Robert Chiras wrote: > This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM > and 8QXP). Following, are the new features added and fixes from this > patch-set: > > 1. Add support for drm_bridge > On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel > display connector, where an LCD panel can be attached, but instead it is > connected to DSI controller. Since this DSI stands between the display > controller (eLCDIF) and the physical connector, the DSI can be implemented > as a DRM bridge. So, in order to be able to connect the mxsfb driver to > the DSI driver, the support for a drm_bridge was needed in mxsfb DRM > driver (the actual driver for the eLCDIF block). So I wanted to test this but with both my somewhat cleaned up nwl driver¹ and the nwl driver forward ported from the nxp vendor tree I'm looking at a black screen with current mainline - while my dcss forward port gives me nice output on mipi dsi. Do you have a tree that uses mipi dsi on imx8mq where I could look at to check for differences? Cheers, -- Guido > > 2. Add support for additional pixel formats > Some of the pixel formats needed by Android were not implemented in this > driver, but they were actually supported. So, add support for them. > > 3. Add support for horizontal stride > Having support for horizontal stride allows the use of eLCDIF with a GPU > (for example) that can only output resolution sizes multiple of a power of > 8. For example, 1080 is not a power of 16, so in order to support 1920x1080 > output from GPUs that can produce linear buffers only in sizes multiple to 16, > this feature is needed. > > 3. Few minor features and bug-fixing > The addition of max-res DT property was actually needed in order to limit > the bandwidth usage of the eLCDIF block. This is need on systems where > multiple display controllers are presend and the memory bandwidth is not > enough to handle all of them at maximum capacity (like it is the case on > 8MQ, where there are two display controllers: DCSS and eLCDIF). > The rest of the patches are bug-fixes. > > Mirela Rabulea (1): > drm/mxsfb: Signal mode changed when bpp changed > > Robert Chiras (9): > drm/mxsfb: Update mxsfb to support a bridge > drm/mxsfb: Update mxsfb with additional pixel formats > drm/mxsfb: Fix the vblank events > dt-bindings: display: Add max-res property for mxsfb > drm/mxsfb: Add max-res property for MXSFB > drm/mxsfb: Update mxsfb to support LCD reset > drm/mxsfb: Improve the axi clock usage > drm/mxsfb: Clear OUTSTANDING_REQS bits > drm/mxsfb: Add support for horizontal stride > > .../devicetree/bindings/display/mxsfb.txt | 6 + > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 290 > ++--- > drivers/gpu/drm/mxsfb/mxsfb_drv.c | 189 +++--- > drivers/gpu/drm/mxsfb/mxsfb_drv.h | 10 +- > drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +- > drivers/gpu/drm/mxsfb/mxsfb_regs.h | 128 ++--- > 6 files changed, 531 insertions(+), 118 deletions(-) > > -- > 2.7.4 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > ¹ https://lists.freedesktop.org/archives/dri-devel/2019-March/209685.html
Re: [PATCH 1/2] regmap: Add DSI bus support
On Thu, Jul 11, 2019 at 03:11:56PM +0200, Andrzej Hajda wrote: > 1. DSI protocol defines actually more than 30 types of transactions[1], > but this patchset implements only few of them (dsi generic write/read > family). Is it possible to implement multiple types of transactions in > regmap? You can, there's a couple of different ways depending on how exactly things are done. > 3. DSI devices are no MFDs so regmap abstraction has no big value added > (correct me, if there are other significant benefits). There's a few extra bits even if you're not using the marshalling code to get things onto the bus - the main ones are the register cache support (which people often use for simpler suspend/resume support) and the debug and trace facilities (things like tracepoints and debugfs for dumping the register map). There's no real connection to MFDs, I'd say the majority of users are not MFDs. signature.asc Description: PGP signature
Re: [PATCH v2 5/5] drm/edid: Make sure the CEA mode arrays have the correct amount of modes
On Thu, Jul 11, 2019 at 01:32:34PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We depend on a specific relationship between the VIC number and the
> index in the CEA mode arrays. Assert that the arrays have the excpected
> size to make sure we've not accidentally left holes in them.
>
> Cc: Hans Verkuil
> Cc: Shashank Sharma
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e6b1e785d158..f0b449225727 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3209,6 +3209,9 @@ static u8 *drm_find_cea_extension(const struct edid
> *edid)
>
> static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
> {
> + BUILD_BUG_ON(ARRAY_SIZE(edid_cea_modes_1) != 127);
> + BUILD_BUG_ON(ARRAY_SIZE(edid_cea_modes_193) != 27);
Maybe better to write these as something like
BUILD_BUG_ON(1 + ARRAY_SIZE(edid_cea_modes_1) - 1 != 127);
BUILD_BUG_ON(193 + ARRAY_SIZE(edid_cea_modes_193) - 1 != 219);
to make it super trivial to cross check against the VICs of the
first and last entry in the arrays.
> +
> if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
> return _cea_modes_1[vic - 1];
> if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
> --
> 2.21.0
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] regmap: Add DSI bus support
On Wed, Jul 10, 2019 at 12:08:34PM -0600, Jeffrey Hugo wrote: > On Fri, Jul 5, 2019 at 7:06 PM Mark Brown wrote: > The addresses for these spec defined messages are 8-bit wide, so 256 > valid "destinations". However, the payload is variable. Most of the > defined operations take an 8-bit payload, but there are a few that I > see with 16-bit payloads. Oh, good, variable register sizes, what a market leading idea :( That basically doesn't work with regmap, you need to either define one regmap per register size and attach them to the device or use reg_read() and reg_write() and hide the complexity in there. > As the contents of the generic read/write messages are implementation > defined, the answer to your question seems to be no - the spec does > not define that the registers are 8-bit addressable, and 8-bit wide. The code definitely ought to at least be more flexible then. Right now it's very hard coded. > I think perhaps the discussion needs to step back a bit, and decide > how flexible do we want this regmap over DSI to be? I think its > usefulness comes from when a device can be configured via multiple > interfaces, so I don't expect it to be useful for every DSI interface. > It seems like the DSI panels use DSI directly to craft their > configuration. As a result, we are probably looking at just devices > which use the generic read/write commands, but sadly the format for > those is not universal per the spec. From the implementations I've > seen, I suspect 8-bit addressing of 8-bit wide registers to be the > most common, but apparently there is an exception to that already in > the one device that I care about. It's relatively easy to add a bunch of special cases in - look at how the I2C code handles it, keying off a combination of the register configuration and the capabilities of the host controller. I guess for this it'd mainly be the register configuration. You might find the reg_read()/reg_write() interface better than the raw buffer one for some of the formats, it does let > Do we want to go forward with this regmap support just for the one TI > device, and see what other usecases come out of it, and attempt to > solve those as we go? I have no strong opinions here, it looks fine from a framework point of view though it's unclear to me if viewing it as a register map meshes well with how the hardware is designed or not - it seems plausible though. signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH v9 1/6] drm: Add Content protection type property
On Mon, Jul 08, 2019 at 04:51:11PM +0530, Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content providers.
> Type 0 content can be rendered on any HDCP protected display wires.
> But Type 1 content can be rendered only on HDCP2.2 protected paths.
>
> So when a userspace sets this property to Type 1 and starts the HDCP
> enable, kernel will honour it only if HDCP2.2 authentication is through
> for type 1. Else HDCP enable will be failed.
>
> Need ACK for this new conenctor property from userspace consumer.
>
> v2:
> cp_content_type is replaced with content_protection_type [daniel]
> check at atomic_set_property is removed [Maarten]
> v3:
> %s/content_protection_type/hdcp_content_type [Pekka]
> v4:
> property is created for the first requested connector and then reused.
> [Danvet]
> v5:
> kernel doc nits addressed [Daniel]
> Rebased as part of patch reordering.
> v6:
> Kernel docs are modified [pekka]
> v7:
> More details in Kernel docs. [pekka]
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> drivers/gpu/drm/drm_connector.c | 39 +++
> drivers/gpu/drm/drm_hdcp.c| 36 -
> drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> include/drm/drm_connector.h | 7
> include/drm/drm_hdcp.h| 2 +-
> include/drm/drm_mode_config.h | 6
> include/uapi/drm/drm_mode.h | 4 +++
> 8 files changed, 99 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index abe38bdf85ae..19ae119f1a5d 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == config->hdcp_content_type_property) {
> + state->hdcp_content_type = val;
> } else if (property == connector->colorspace_property) {
> state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> state->hdr_output_metadata->base.id : 0;
> } else if (property == config->content_protection_property) {
> *val = state->content_protection;
> + } else if (property == config->hdcp_content_type_property) {
> + *val = state->hdcp_content_type;
> } else if (property == config->writeback_fb_id_property) {
> /* Writeback framebuffer is one-shot, write and forget */
> *val = 0;
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 068d4b05f1be..732f6645643d 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -952,6 +952,45 @@ static const struct drm_prop_enum_list
> hdmi_colorspaces[] = {
> * is no longer protected and userspace should take appropriate action
> * (whatever that might be).
> *
> + * HDCP Content Type:
> + * This Enum property is used by the userspace to declare the content type
> + * of the display stream, to kernel. Here display stream stands for any
> + * display content that userspace intended to render with HDCP encryption.
> + *
> + * Content Type of a stream is decided by the owner of the stream, as
> + * "HDCP Type0" or "HDCP Type1".
> + *
> + * The value of the property can be one the below:
> + * - "HDCP Type0": DRM_MODE_HDCP_CONTENT_TYPE0 = 0
> + * - "HDCP Type1": DRM_MODE_HDCP_CONTENT_TYPE1 = 1
> + *
> + * When kernel starts the HDCP authentication upon the "DESIRED" state of
> + * the "Content Protection", it refers the "HDCP Content Type" property
> + * state. And perform the HDCP authentication with the display sink for
> + * the content type mentioned by "HDCP Content Type".
> + *
> + * Stream classified as HDCP Type0 can be transmitted on a link which is
> + * encrypted with HDCP 1.4 or higher versions of HDCP(i.e HDCP2.2
> + * and more).
> + *
> + * Streams classified as HDCP Type1 can be transmitted on a link which is
> + * encrypted only with HDCP 2.2. In future, HDCP versions >2.2 also might
> + * support Type1 based on their spec.
> + *
> + * HDCP2.2 authentication protocol itself takes the "Content Type" as a
> + * parameter, which is a input for the DP HDCP2.2 encryption algo.
> + *
> + * Note that the HDCP Content Type property is introduced at HDCP 2.2, and
> + * defaults to type 0. It is only
Re: [PATCH 1/2] regmap: Add DSI bus support
On Thu, Jul 11, 2019 at 6:11 AM Andrzej Hajda wrote:
>
> On 06.07.2019 03:06, Mark Brown wrote:
> > On Wed, Jul 03, 2019 at 02:45:12PM -0700, Jeffrey Hugo wrote:
> >> Add basic support with a simple implementation that utilizes the generic
> >> read/write commands to allow device registers to be configured.
> > This looks good to me but I really don't know anything about DSI,
> > I'd appreciate some review from other people who do. I take it
> > there's some spec thing in DSI that says registers and bytes must
> > both be 8 bit?
>
>
> I am little bit confused about regmap usage here. On the one hand it
> nicely fits to this specific driver, probably because it already uses
> regmap_i2c.
>
> On the other it will be unusable for almost all current DSI drivers and
> probably for most new drivers. Why?
>
> 1. DSI protocol defines actually more than 30 types of transactions[1],
> but this patchset implements only few of them (dsi generic write/read
> family). Is it possible to implement multiple types of transactions in
> regmap?
>
> 2. There is already some set of helpers which uses dsi bus, rewriting it
> on regmap is possible or driver could use of regmap and direct access
> together, the question is if it is really necessary.
>
> 3. DSI devices are no MFDs so regmap abstraction has no big value added
> (correct me, if there are other significant benefits).
>
I assume it is not *just* this one bridge that can be programmed over
either i2c or dsi, depending on how things are wired up on the board.
It certainly would be nice for regmap to support this case, so we
don't have to write two different bridge drivers for the same bridge.
I wouldn't expect a panel that is only programmed via dsi to use this.
BR,
-R
>
> [1]:
> https://elixir.bootlin.com/linux/latest/source/include/video/mipi_display.h#L15
>
>
> Regards
>
> Andrzej
>
>
> >
> > A couple of minor comments, no need to resend just for these:
> >
> >> + payload[0] = (char)reg;
> >> + payload[1] = (char)val;
> > Do you need the casts?
> >
> >> +ret = mipi_dsi_generic_write(dsi, payload, 2);
> >> +return ret < 0 ? ret : 0;
> > Please just write an if statement, it helps with legibility.
> >
> >> +struct regmap *__regmap_init_dsi(struct mipi_dsi_device *dsi,
> >> + const struct regmap_config *config,
> >> + struct lock_class_key *lock_key,
> >> + const char *lock_name)
> >> +{
> >> +return __regmap_init(>dev, _bus, >dev, config,
> >> + lock_key, lock_name);
> >> +}
> >> +EXPORT_SYMBOL_GPL(__regmap_init_dsi);
> > Perhaps validate that the config is OK (mainly the register/value
> > sizes)? Though I'm not sure it's worth it so perhaps not - up to
> > you.
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: Add 'alpha' and 'pixel blend mode' plane properties
Add the following properties for planes: * alpha * pixel blend mode. Only "Pre-multiplied" and "Coverage" are supported Signed-off-by: Jean-Jacques Hiblot --- drivers/gpu/drm/omapdrm/omap_plane.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index 84e1be981cfe..73ec99819a3d 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -53,8 +53,12 @@ static void omap_plane_atomic_update(struct drm_plane *plane, memset(, 0, sizeof(info)); info.rotation_type = OMAP_DSS_ROT_NONE; info.rotation = DRM_MODE_ROTATE_0; - info.global_alpha = 0xff; + info.global_alpha = state->alpha >> 8; info.zorder = state->normalized_zpos; + if (state->pixel_blend_mode == DRM_MODE_BLEND_PREMULTI) + info.pre_mult_alpha = 1; + else + info.pre_mult_alpha = 0; /* update scanout: */ omap_framebuffer_update_scanout(state->fb, state, ); @@ -285,6 +289,9 @@ struct drm_plane *omap_plane_init(struct drm_device *dev, omap_plane_install_properties(plane, >base); drm_plane_create_zpos_property(plane, 0, 0, num_planes - 1); + drm_plane_create_alpha_property(plane); + drm_plane_create_blend_mode_property(plane, BIT(DRM_MODE_BLEND_PREMULTI) | +BIT(DRM_MODE_BLEND_COVERAGE)); return plane; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 23/23] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
On Thu, Jul 11, 2019 at 02:59:26PM +0300, Ville Syrjälä wrote: > On Thu, Jul 11, 2019 at 01:26:50PM +0200, Andrzej Pietrasiewicz wrote: > > Use the ddc pointer provided by the generic connector. > > We already have a symlink via intel_hdmi_create_i2c_symlink(). I guess > we should remove that in favor of the generic one. Oleg? Since that commit is very new I think we should try real hard to avoid the i915-ism here ... -Daniel > > > > > Signed-off-by: Andrzej Pietrasiewicz > > --- > > drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c > > b/drivers/gpu/drm/i915/display/intel_hdmi.c > > index 0ebec69bbbfc..678fa4d1bd4e 100644 > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > > @@ -3094,6 +3094,9 @@ void intel_hdmi_init_connector(struct > > intel_digital_port *intel_dig_port, > > intel_dig_port->max_lanes, port_name(port))) > > return; > > > > + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > > + connector->ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); > > + > > drm_connector_init(dev, connector, _hdmi_connector_funcs, > >DRM_MODE_CONNECTOR_HDMIA); > > drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); > > @@ -3105,8 +3108,6 @@ void intel_hdmi_init_connector(struct > > intel_digital_port *intel_dig_port, > > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > > connector->ycbcr_420_allowed = true; > > > > - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > > - > > if (WARN_ON(port == PORT_A)) > > return; > > intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); > > -- > > 2.17.1 > > -- > Ville Syrjälä > Intel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
On Thu, Jul 11, 2019 at 02:41:01PM +0200, Andrzej Hajda wrote:
> On 11.07.2019 09:35, Daniel Vetter wrote:
> > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >> Hi Laurent,
> >>
> >>
> >> I like the approach, current practice when almost every bridge should
> >> optionally implement connector, or alternatively downstream bridge or
> >> panel is very painful.
> > Yeah I think this looks mostly reasonable. Some api design comments on top
> > of Andrzej', with the fair warning that I didn't bother to read up on how
> > it's all used in the end. I probably should go and do that, at least to
> > get a feeling for what your hpd_cb usually does.
> >
> >> More comments inlined.
> >>
> >> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>> To support implementation of DRM connectors on top of DRM bridges
> >>> instead of by bridges, the drm_bridge needs to expose new operations and
> >>> data:
> >>>
> >>> - Output detection, hot-plug notification, mode retrieval and EDID
> >>> retrieval operations
> >>> - Bitmask of supported operations
> >>
> >> Why do we need these bitmask at all? Why cannot we rely on presence of
> >> operation's callback?
> > Yeah also not a huge fan of these bitmasks. Smells like
> > DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> > add, generally good excuse to not have to think through the design between
> > different parts of drivers - "just" add another flag.
> >>
> >>> - Bridge output type
> >>>
> >>> Add and document these.
> >>>
> >>> Three new bridge helper functions are also added to handle hot plug
> >>> notification in a way that is as transparent as possible for the
> >>> bridges.
> >>
> >> Documentation of new opses does not explain how it should cooperate with
> >> bridge chaining, I suppose they should be chained explicitly, am I
> >> right? More comments about it later.
> >>
> >>
> >>> Signed-off-by: Laurent Pinchart
> >>> ---
> >>> drivers/gpu/drm/drm_bridge.c | 92 +++
> >>> include/drm/drm_bridge.h | 170 ++-
> >>> 2 files changed, 261 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> >>> index 519577f363e3..3c2a255df7af 100644
> >>> --- a/drivers/gpu/drm/drm_bridge.c
> >>> +++ b/drivers/gpu/drm/drm_bridge.c
> >>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
> >>> */
> >>> void drm_bridge_add(struct drm_bridge *bridge)
> >>> {
> >>> + mutex_init(>hpd_mutex);
> >>> +
> >>> mutex_lock(_lock);
> >>> list_add_tail(>list, _list);
> >>> mutex_unlock(_lock);
> >>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
> >>> mutex_lock(_lock);
> >>> list_del_init(>list);
> >>> mutex_unlock(_lock);
> >>> +
> >>> + mutex_destroy(>hpd_mutex);
> >>> }
> >>> EXPORT_SYMBOL(drm_bridge_remove);
> >>>
> >>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge
> >>> *bridge,
> >>> }
> >>> EXPORT_SYMBOL(drm_atomic_bridge_enable);
> >>>
> >>> +/**
> >>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
> >>> + * @bridge: bridge control structure
> >>> + * @cb: hot-plug detection callback
> >>> + * @data: data to be passed to the hot-plug detection callback
> >>> + *
> >>> + * Call _bridge_funcs.hpd_enable and register the given @cb and
> >>> @data as
> >>> + * hot plug notification callback. From now on the @cb will be called
> >>> with
> >>> + * @data when an output status change is detected by the bridge, until
> >>> hot plug
> >>> + * notification gets disabled with drm_bridge_hpd_disable().
> >>> + *
> >>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is
> >>> set in
> >>> + * bridge->ops. This function shall not be called when the flag is not
> >>> set.
> >>> + *
> >>> + * Only one hot plug detection callback can be registered at a time, it
> >>> is an
> >>> + * error to call this function when hot plug detection is already
> >>> enabled for
> >>> + * the bridge.
> >>> + */
> >>
> >> To simplify architecture maybe would be better to enable hpd just on
> >> bridge attach:
> >>
> >> bridge->hpd_cb = cb;
> >>
> >> bridge->hpd_data = data;
> >>
> >> ret = drm_bridge_attach(...);
> > Yeah I like this more. The other problem here is, what if you need more
> > than 1 callback registers on the same bridge hdp signal?
> >
> >
> >> This way we could avoid adding new callbacks hpd_(enable|disable)
> >> without big sacrifices.
> >>
> >>
> >> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
> >> notifies about sink status change, how it translates to this cb?
> >>
> >>
> >>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
> >>> +void (*cb)(void *data,
> >>> + enum drm_connector_status status),
> >>> +void *data)
> >>> +{
> >>> + if (!bridge || !bridge->funcs->hpd_enable)
> >>> + return;
> >>> +
> >>> + mutex_lock(>hpd_mutex);
>
Re: [PATCH 1/2] regmap: Add DSI bus support
On 06.07.2019 03:06, Mark Brown wrote:
> On Wed, Jul 03, 2019 at 02:45:12PM -0700, Jeffrey Hugo wrote:
>> Add basic support with a simple implementation that utilizes the generic
>> read/write commands to allow device registers to be configured.
> This looks good to me but I really don't know anything about DSI,
> I'd appreciate some review from other people who do. I take it
> there's some spec thing in DSI that says registers and bytes must
> both be 8 bit?
I am little bit confused about regmap usage here. On the one hand it
nicely fits to this specific driver, probably because it already uses
regmap_i2c.
On the other it will be unusable for almost all current DSI drivers and
probably for most new drivers. Why?
1. DSI protocol defines actually more than 30 types of transactions[1],
but this patchset implements only few of them (dsi generic write/read
family). Is it possible to implement multiple types of transactions in
regmap?
2. There is already some set of helpers which uses dsi bus, rewriting it
on regmap is possible or driver could use of regmap and direct access
together, the question is if it is really necessary.
3. DSI devices are no MFDs so regmap abstraction has no big value added
(correct me, if there are other significant benefits).
[1]:
https://elixir.bootlin.com/linux/latest/source/include/video/mipi_display.h#L15
Regards
Andrzej
>
> A couple of minor comments, no need to resend just for these:
>
>> + payload[0] = (char)reg;
>> + payload[1] = (char)val;
> Do you need the casts?
>
>> +ret = mipi_dsi_generic_write(dsi, payload, 2);
>> +return ret < 0 ? ret : 0;
> Please just write an if statement, it helps with legibility.
>
>> +struct regmap *__regmap_init_dsi(struct mipi_dsi_device *dsi,
>> + const struct regmap_config *config,
>> + struct lock_class_key *lock_key,
>> + const char *lock_name)
>> +{
>> +return __regmap_init(>dev, _bus, >dev, config,
>> + lock_key, lock_name);
>> +}
>> +EXPORT_SYMBOL_GPL(__regmap_init_dsi);
> Perhaps validate that the config is OK (mainly the register/value
> sizes)? Though I'm not sure it's worth it so perhaps not - up to
> you.
[Bug 110783] Mesa 19.1 rc crashing MPV with VAAPI
https://bugs.freedesktop.org/show_bug.cgi?id=110783 --- Comment #22 from AngryPenguin --- I can confirm. 19.1.2 fixed my issue on OpenMandirva. Thanks -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm: Add Content protection type property
On 2019-07-10 at 11:16:24 +0300, Pekka Paalanen wrote:
> On Tue, 9 Jul 2019 18:17:59 +0530
> Ramalingam C wrote:
>
> > On 2019-07-09 at 17:31:10 +0300, Pekka Paalanen wrote:
> > > On Mon, 8 Jul 2019 16:51:11 +0530
> > > Ramalingam C wrote:
> > >
> > > > This patch adds a DRM ENUM property to the selected connectors.
> > > > This property is used for mentioning the protected content's type
> > > > from userspace to kernel HDCP authentication.
> > > >
> > > > Type of the stream is decided by the protected content providers.
> > > > Type 0 content can be rendered on any HDCP protected display wires.
> > > > But Type 1 content can be rendered only on HDCP2.2 protected paths.
> > > >
> > > > So when a userspace sets this property to Type 1 and starts the HDCP
> > > > enable, kernel will honour it only if HDCP2.2 authentication is through
> > > > for type 1. Else HDCP enable will be failed.
> > > >
> > > > Need ACK for this new conenctor property from userspace consumer.
> > > >
> > > > v2:
> > > > cp_content_type is replaced with content_protection_type [daniel]
> > > > check at atomic_set_property is removed [Maarten]
> > > > v3:
> > > > %s/content_protection_type/hdcp_content_type [Pekka]
> > > > v4:
> > > > property is created for the first requested connector and then reused.
> > > > [Danvet]
> > > > v5:
> > > > kernel doc nits addressed [Daniel]
> > > > Rebased as part of patch reordering.
> > > > v6:
> > > > Kernel docs are modified [pekka]
> > > > v7:
> > > > More details in Kernel docs. [pekka]
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > Reviewed-by: Daniel Vetter
> > > > ---
> > > > drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
> > > > drivers/gpu/drm/drm_connector.c | 39 +++
> > > > drivers/gpu/drm/drm_hdcp.c| 36 -
> > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++-
> > > > include/drm/drm_connector.h | 7
> > > > include/drm/drm_hdcp.h| 2 +-
> > > > include/drm/drm_mode_config.h | 6
> > > > include/uapi/drm/drm_mode.h | 4 +++
> > > > 8 files changed, 99 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > index abe38bdf85ae..19ae119f1a5d 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > > > @@ -747,6 +747,8 @@ static int drm_atomic_connector_set_property(struct
> > > > drm_connector *connector,
> > > > return -EINVAL;
> > > > }
> > > > state->content_protection = val;
> > > > + } else if (property == config->hdcp_content_type_property) {
> > > > + state->hdcp_content_type = val;
> > > > } else if (property == connector->colorspace_property) {
> > > > state->colorspace = val;
> > > > } else if (property == config->writeback_fb_id_property) {
> > > > @@ -831,6 +833,8 @@ drm_atomic_connector_get_property(struct
> > > > drm_connector *connector,
> > > > state->hdr_output_metadata->base.id : 0;
> > > > } else if (property == config->content_protection_property) {
> > > > *val = state->content_protection;
> > > > + } else if (property == config->hdcp_content_type_property) {
> > > > + *val = state->hdcp_content_type;
> > > > } else if (property == config->writeback_fb_id_property) {
> > > > /* Writeback framebuffer is one-shot, write and forget
> > > > */
> > > > *val = 0;
> > > > diff --git a/drivers/gpu/drm/drm_connector.c
> > > > b/drivers/gpu/drm/drm_connector.c
> > > > index 068d4b05f1be..732f6645643d 100644
> > > > --- a/drivers/gpu/drm/drm_connector.c
> > > > +++ b/drivers/gpu/drm/drm_connector.c
> > > > @@ -952,6 +952,45 @@ static const struct drm_prop_enum_list
> > > > hdmi_colorspaces[] = {
> > > > * is no longer protected and userspace should take appropriate
> > > > action
> > > > * (whatever that might be).
> > > > *
> > > > + * HDCP Content Type:
> > > > + * This Enum property is used by the userspace to declare the
> > > > content type
> > > > + * of the display stream, to kernel. Here display stream stands
> > > > for any
> > > > + * display content that userspace intended to render with HDCP
> > > > encryption.
> > >
> > > Hi,
> > >
> > > I'd suggest s/render with/display through/.
> > >
> > > As a gfx dev, rendering is something quite different to me.
> > Ok.
> > >
> > > > + *
> > > > + * Content Type of a stream is decided by the owner of the stream,
> > > > as
> > > > + * "HDCP Type0" or "HDCP Type1".
> > > > + *
> > > > + * The value of the property can be one the below:
> > >
> > > *one of the below
> > Sure.
> > >
> > > > + * - "HDCP Type0":
Re: [PATCH 09/60] drm/bridge: Add connector-related bridge operations and data
On 11.07.2019 09:35, Daniel Vetter wrote:
> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
>> Hi Laurent,
>>
>>
>> I like the approach, current practice when almost every bridge should
>> optionally implement connector, or alternatively downstream bridge or
>> panel is very painful.
> Yeah I think this looks mostly reasonable. Some api design comments on top
> of Andrzej', with the fair warning that I didn't bother to read up on how
> it's all used in the end. I probably should go and do that, at least to
> get a feeling for what your hpd_cb usually does.
>
>> More comments inlined.
>>
>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>> To support implementation of DRM connectors on top of DRM bridges
>>> instead of by bridges, the drm_bridge needs to expose new operations and
>>> data:
>>>
>>> - Output detection, hot-plug notification, mode retrieval and EDID
>>> retrieval operations
>>> - Bitmask of supported operations
>>
>> Why do we need these bitmask at all? Why cannot we rely on presence of
>> operation's callback?
> Yeah also not a huge fan of these bitmasks. Smells like
> DRIVER_GEM|DRIVER_MODESET, and I personally really hate those. Easy to
> add, generally good excuse to not have to think through the design between
> different parts of drivers - "just" add another flag.
>>
>>> - Bridge output type
>>>
>>> Add and document these.
>>>
>>> Three new bridge helper functions are also added to handle hot plug
>>> notification in a way that is as transparent as possible for the
>>> bridges.
>>
>> Documentation of new opses does not explain how it should cooperate with
>> bridge chaining, I suppose they should be chained explicitly, am I
>> right? More comments about it later.
>>
>>
>>> Signed-off-by: Laurent Pinchart
>>> ---
>>> drivers/gpu/drm/drm_bridge.c | 92 +++
>>> include/drm/drm_bridge.h | 170 ++-
>>> 2 files changed, 261 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 519577f363e3..3c2a255df7af 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -70,6 +70,8 @@ static LIST_HEAD(bridge_list);
>>> */
>>> void drm_bridge_add(struct drm_bridge *bridge)
>>> {
>>> + mutex_init(>hpd_mutex);
>>> +
>>> mutex_lock(_lock);
>>> list_add_tail(>list, _list);
>>> mutex_unlock(_lock);
>>> @@ -86,6 +88,8 @@ void drm_bridge_remove(struct drm_bridge *bridge)
>>> mutex_lock(_lock);
>>> list_del_init(>list);
>>> mutex_unlock(_lock);
>>> +
>>> + mutex_destroy(>hpd_mutex);
>>> }
>>> EXPORT_SYMBOL(drm_bridge_remove);
>>>
>>> @@ -463,6 +467,94 @@ void drm_atomic_bridge_enable(struct drm_bridge
>>> *bridge,
>>> }
>>> EXPORT_SYMBOL(drm_atomic_bridge_enable);
>>>
>>> +/**
>>> + * drm_bridge_hpd_enable - enable hot plug detection for the bridge
>>> + * @bridge: bridge control structure
>>> + * @cb: hot-plug detection callback
>>> + * @data: data to be passed to the hot-plug detection callback
>>> + *
>>> + * Call _bridge_funcs.hpd_enable and register the given @cb and @data
>>> as
>>> + * hot plug notification callback. From now on the @cb will be called with
>>> + * @data when an output status change is detected by the bridge, until hot
>>> plug
>>> + * notification gets disabled with drm_bridge_hpd_disable().
>>> + *
>>> + * Hot plug detection is supported only if the DRM_BRIDGE_OP_HPD flag is
>>> set in
>>> + * bridge->ops. This function shall not be called when the flag is not set.
>>> + *
>>> + * Only one hot plug detection callback can be registered at a time, it is
>>> an
>>> + * error to call this function when hot plug detection is already enabled
>>> for
>>> + * the bridge.
>>> + */
>>
>> To simplify architecture maybe would be better to enable hpd just on
>> bridge attach:
>>
>> bridge->hpd_cb = cb;
>>
>> bridge->hpd_data = data;
>>
>> ret = drm_bridge_attach(...);
> Yeah I like this more. The other problem here is, what if you need more
> than 1 callback registers on the same bridge hdp signal?
>
>
>> This way we could avoid adding new callbacks hpd_(enable|disable)
>> without big sacrifices.
>>
>>
>> One more thing: HPD in DisplayPort/HDMI beside signalling plug/unplug,
>> notifies about sink status change, how it translates to this cb?
>>
>>
>>> +void drm_bridge_hpd_enable(struct drm_bridge *bridge,
>>> + void (*cb)(void *data,
>>> + enum drm_connector_status status),
>>> + void *data)
>>> +{
>>> + if (!bridge || !bridge->funcs->hpd_enable)
>>> + return;
>>> +
>>> + mutex_lock(>hpd_mutex);
>>> +
>>> + if (WARN(bridge->hpd_cb, "Hot plug detection already enabled\n"))
>>> + goto unlock;
>>> +
>>> + bridge->hpd_cb = cb;
>>> + bridge->hpd_data = data;
>>> +
>>> + bridge->funcs->hpd_enable(bridge);
>>> +
>>> +unlock:
>>> + mutex_unlock(>hpd_mutex);
>>> +}
>>>
Re: [PATCH v6 11/22] clk: sunxi-ng: a64: Add minimum rate for PLL_MIPI
On Fri, Jul 05, 2019 at 07:52:27PM +0200, Michael Nazzareno Trimarchi wrote: > On Wed, Jul 3, 2019 at 1:49 PM Maxime Ripard > wrote: > > > > On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote: > > > On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard > > > wrote: > > > > > > > > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote: > > > > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > On Wed, Jun 05, 2019 at 01:03:16PM +0530, Jagan Teki wrote: > > > > > > > On Wed, Jun 5, 2019 at 12:19 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I've reordered the mail a bit to work on chunks > > > > > > > > > > > > > > > > On Fri, May 24, 2019 at 03:37:42PM +0530, Jagan Teki wrote: > > > > > > > > > > I wish it was in your commit log in the first place, > > > > > > > > > > instead of having > > > > > > > > > > to exchange multiple mails over this. > > > > > > > > > > > > > > > > > > > > However, I don't think that's quite true, and it might be a > > > > > > > > > > bug in > > > > > > > > > > Allwinner's implementation (or rather something quite > > > > > > > > > > confusing). > > > > > > > > > > > > > > > > > > > > You're right that the lcd_rate and pll_rate seem to be > > > > > > > > > > generated from > > > > > > > > > > the pixel clock, and it indeed looks like the ratio between > > > > > > > > > > the pixel > > > > > > > > > > clock and the TCON dotclock is defined through the number > > > > > > > > > > of bits per > > > > > > > > > > lanes. > > > > > > > > > > > > > > > > > > > > However, in this case, dsi_rate is actually the same than > > > > > > > > > > lcd_rate, > > > > > > > > > > since pll_rate is going to be divided by dsi_div: > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L791 > > > > > > > > > > > > > > > > > > > > Since lcd_div is 1, it also means that in this case, > > > > > > > > > > dsi_rate == > > > > > > > > > > dclk_rate. > > > > > > > > > > > > > > > > > > > > The DSI module clock however, is always set to 148.5 MHz. > > > > > > > > > > Indeed, if > > > > > > > > > > we look at: > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L804 > > > > > > > > > > > > > > > > > > > > We can see that the rate in clk_info is used if it's > > > > > > > > > > different than > > > > > > > > > > 0. This is filled by disp_al_lcd_get_clk_info, which, in > > > > > > > > > > the case of a > > > > > > > > > > DSI panel, will hardcode it to 148.5 MHz: > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/disp_al.c#L164 > > > > > > > > > > > > > > > > > > Let me explain, something more. > > > > > > > > > > > > > > > > > > According to bsp there are clk_info.tcon_div which I will > > > > > > > > > explain below. > > > > > > > > > clk_info.dsi_div which is dynamic and it depends on > > > > > > > > > bpp/lanes, so it > > > > > > > > > is 6 for 24bpp and 4 lanes devices. > > > > > > > > > > > > > > > > > > PLL rate here depends on dsi_div (not tcon_div) > > > > > > > > > > > > > > > > > > Code here > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L784 > > > > > > > > > > > > > > > > > > is computing the actual set rate, which depends on dsi_rate. > > > > > > > > > > > > > > > > > > lcd_rate = dclk_rate * clk_info.dsi_div; > > > > > > > > > dsi_rate = pll_rate / clk_info.dsi_div; > > > > > > > > > > > > > > > > > > Say if the dclk_rate 148MHz then the dsi_rate is 888MHz which > > > > > > > > > set rate > > > > > > > > > for above link you mentioned. > > > > > > > > > > > > > > > > > > Here are the evidence with some prints. > > > > > > > > > > > > > > > > > > https://gist.github.com/openedev/9bae2d87d2fcc06b999fe48c998b7043 > > > > > > > > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > > > > > > > > > > > > > > > Ok, so we agree up to this point, and the prints confirm that > > > > > > > > the > > > > > > > > analysis above is the right one. > > > > > > > > > > > > > > > > > > So, the DSI clock is set to this here: > > > > > > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/de/disp_lcd.c#L805 > > > > > > > > > > > > > > > > Your patch doesn't address that, so let's leave that one alone. > > > > > > > > > > > > > > Basically this is final pll set rate when sun4i_dotclock.c called > > > > > > > the > > > > > > > desired rate with ccu_nkm.c so it ended the final rate with > > > > > > > parent as > > > > > > > Line 8 of > > > > > > > https://gist.github.com/openedev/700de2e3701b2bf3ad1aa0f0fa862c9a > > > > > > > > > > > > If that's important to the driver, it should be set explicitly
Re: [PATCH v4 01/23] drm: Include ddc adapter pointer in struct drm_connector
On Thu, Jul 11, 2019 at 01:26:28PM +0200, Andrzej Pietrasiewicz wrote:
> Add generic code which creates symbolic links in sysfs, pointing to ddc
> interface used by a particular video output. For example:
>
> ls -l /sys/class/drm/card0-HDMI-A-1/ddc
> lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
> -> ../../../../soc/1388.i2c/i2c-2
>
> This makes it easy for user to associate a display with its ddc adapter
> and use e.g. ddcutil to control the chosen monitor.
>
> This patch adds an i2c_adapter pointer to struct drm_connector. Particular
> drivers can then use it instead of using their own private instance. If a
> connector contains a ddc, then create a symbolic link in sysfs.
>
> Signed-off-by: Andrzej Pietrasiewicz
> Acked-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/drm_sysfs.c | 7 +++
> include/drm/drm_connector.h | 11 +++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> index ad10810bc972..26d359b39785 100644
> --- a/drivers/gpu/drm/drm_sysfs.c
> +++ b/drivers/gpu/drm/drm_sysfs.c
> @@ -294,6 +294,9 @@ int drm_sysfs_connector_add(struct drm_connector
> *connector)
> /* Let userspace know we have a new connector */
> drm_sysfs_hotplug_event(dev);
>
> + if (connector->ddc)
> + return sysfs_create_link(>kdev->kobj,
> + >ddc->dev.kobj, "ddc");
> return 0;
> }
>
> @@ -301,6 +304,10 @@ void drm_sysfs_connector_remove(struct drm_connector
> *connector)
> {
> if (!connector->kdev)
> return;
> +
> + if (connector->ddc)
> + sysfs_remove_link(>kdev->kobj, "ddc");
> +
> DRM_DEBUG("removing \"%s\" from sysfs\n",
> connector->name);
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ca745d9feaf5..1ad3d1d54ba7 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -23,6 +23,7 @@
> #ifndef __DRM_CONNECTOR_H__
> #define __DRM_CONNECTOR_H__
>
> +#include
struct i2c_adapter;
would suffice.
> #include
> #include
> #include
> @@ -1308,6 +1309,16 @@ struct drm_connector {
>* [0]: progressive, [1]: interlaced
>*/
> int audio_latency[2];
> +
> + /**
> + * @ddc: associated ddc adapter.
> + * A connector usually has its associated ddc adapter. If a driver uses
> + * this field, then an appropriate symbolic link is created in connector
> + * sysfs directory to make it easy for the user to tell which i2c
> + * adapter is for a particular display.
> + */
> + struct i2c_adapter *ddc;
> +
> /**
>* @null_edid_counter: track sinks that give us all zeros for the EDID.
>* Needed to workaround some HW bugs where we get all 0s
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 23/23] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
On Thu, Jul 11, 2019 at 01:26:50PM +0200, Andrzej Pietrasiewicz wrote: > Use the ddc pointer provided by the generic connector. We already have a symlink via intel_hdmi_create_i2c_symlink(). I guess we should remove that in favor of the generic one. Oleg? > > Signed-off-by: Andrzej Pietrasiewicz > --- > drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c > b/drivers/gpu/drm/i915/display/intel_hdmi.c > index 0ebec69bbbfc..678fa4d1bd4e 100644 > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c > @@ -3094,6 +3094,9 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, >intel_dig_port->max_lanes, port_name(port))) > return; > > + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > + connector->ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); > + > drm_connector_init(dev, connector, _hdmi_connector_funcs, > DRM_MODE_CONNECTOR_HDMIA); > drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); > @@ -3105,8 +3108,6 @@ void intel_hdmi_init_connector(struct > intel_digital_port *intel_dig_port, > if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) > connector->ycbcr_420_allowed = true; > > - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); > - > if (WARN_ON(port == PORT_A)) > return; > intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); > -- > 2.17.1 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/60] drm/omap: Replace custom display drivers with drm_bridge and drm_panel
Hi, On Thu, Jul 11, 2019 at 09:37:26AM +0200, Daniel Vetter wrote: > > [1] The only notable exception is the omapdrm-specific DSI panel driver > > that implements a large number of custom operations. This should be > > addressed separately. > > DSI tends to be fairly custom in all drivers, I think that's totally fine. > Maybe not forever, but we have a lot worse crimes in our codebase than > that :-) I have a WIP branch, which moves omapdrm DSI to mipi_dsi_driver and drm_panel: https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-n900.git/log/?h=omapdrm-5.2-with-dsi-untested-work-branch The name is a bit misleading, since it is tested now. HEAD~2, which moves the last custom operation (panel update for DSI command mode) from the panel driver to the DSI core unfortunatley does not yet work. I'm still investigating the reason. Anyways - this is being worked on :) -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 22/23] drm/radeon: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/radeon/radeon_connectors.c | 80 ++
1 file changed, 52 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index c60d1a44d22a..ee7430d0516e 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1947,10 +1947,12 @@ radeon_add_atom_connector(struct drm_device *dev,
radeon_connector->con_priv = radeon_dig_connector;
if (i2c_bus->valid) {
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
- if (radeon_connector->ddc_bus)
+ if (radeon_connector->ddc_bus) {
has_aux = true;
- else
+ connector->ddc =
_connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
@@ -2042,13 +2044,15 @@ radeon_add_atom_connector(struct drm_device *dev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, _connector->base,
_vga_connector_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_vga_connector_helper_funcs);
if (i2c_bus->valid) {
radeon_connector->ddc_bus =
radeon_i2c_lookup(rdev, i2c_bus);
if (!radeon_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init(dev, _connector->base,
_vga_connector_funcs, connector_type);
+ drm_connector_helper_add(_connector->base,
_vga_connector_helper_funcs);
radeon_connector->dac_load_detect = true;
drm_object_attach_property(_connector->base.base,
rdev->mode_info.load_detect_property,
@@ -2067,13 +2071,15 @@ radeon_add_atom_connector(struct drm_device *dev,
connector->doublescan_allowed = true;
break;
case DRM_MODE_CONNECTOR_DVIA:
- drm_connector_init(dev, _connector->base,
_vga_connector_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_vga_connector_helper_funcs);
if (i2c_bus->valid) {
radeon_connector->ddc_bus =
radeon_i2c_lookup(rdev, i2c_bus);
if (!radeon_connector->ddc_bus)
DRM_ERROR("DVIA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init(dev, _connector->base,
_vga_connector_funcs, connector_type);
+ drm_connector_helper_add(_connector->base,
_vga_connector_helper_funcs);
radeon_connector->dac_load_detect = true;
drm_object_attach_property(_connector->base.base,
rdev->mode_info.load_detect_property,
@@ -2098,13 +2104,15 @@ radeon_add_atom_connector(struct drm_device *dev,
goto failed;
radeon_dig_connector->igp_lane_info = igp_lane_info;
radeon_connector->con_priv = radeon_dig_connector;
- drm_connector_init(dev, _connector->base,
_dvi_connector_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_dvi_connector_helper_funcs);
if (i2c_bus->valid) {
radeon_connector->ddc_bus =
radeon_i2c_lookup(rdev, i2c_bus);
if (!radeon_connector->ddc_bus)
DRM_ERROR("DVI: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init(dev, _connector->base,
_dvi_connector_funcs, connector_type);
+
[PATCH v4 23/23] drm/i915: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 0ebec69bbbfc..678fa4d1bd4e 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -3094,6 +3094,9 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, intel_dig_port->max_lanes, port_name(port))) return; + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); + connector->ddc = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus); + drm_connector_init(dev, connector, _hdmi_connector_funcs, DRM_MODE_CONNECTOR_HDMIA); drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); @@ -3105,8 +3108,6 @@ void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port, if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) connector->ycbcr_420_allowed = true; - intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port); - if (WARN_ON(port == PORT_A)) return; intel_encoder->hpd_pin = intel_hpd_pin_default(dev_priv, port); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 19/23] drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 +++
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index c6490949d9db..0b9c9f2619da 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -161,7 +161,6 @@ struct dw_hdmi {
struct drm_display_mode previous_mode;
- struct i2c_adapter *ddc;
void __iomem *regs;
bool sink_is_hdmi;
bool sink_has_audio;
@@ -1118,7 +1117,7 @@ static bool dw_hdmi_support_scdc(struct dw_hdmi *hdmi)
return false;
/* Disable if no DDC bus */
- if (!hdmi->ddc)
+ if (!hdmi->connector.ddc)
return false;
/* Disable if SCDC is not supported, or if an HF-VSDB block is absent */
@@ -1156,10 +1155,11 @@ void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi
*hdmi)
/* Control for TMDS Bit Period/TMDS Clock-Period Ratio */
if (dw_hdmi_support_scdc(hdmi)) {
+ struct i2c_adapter *ddc = hdmi->connector.ddc;
if (mtmdsclock > HDMI14_MAX_TMDSCLK)
- drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1);
+ drm_scdc_set_high_tmds_clock_ratio(ddc, 1);
else
- drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0);
+ drm_scdc_set_high_tmds_clock_ratio(ddc, 0);
}
}
EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio);
@@ -1750,6 +1750,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
if (dw_hdmi_support_scdc(hdmi)) {
if (vmode->mtmdsclock > HDMI14_MAX_TMDSCLK ||
hdmi_info->scdc.scrambling.low_rates) {
+ struct i2c_adapter *ddc = hdmi->connector.ddc;
/*
* HDMI2.0 Specifies the following procedure:
* After the Source Device has determined that
@@ -1759,13 +1760,12 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
* Source Devices compliant shall set the
* Source Version = 1.
*/
- drm_scdc_readb(hdmi->ddc, SCDC_SINK_VERSION,
- );
- drm_scdc_writeb(hdmi->ddc, SCDC_SOURCE_VERSION,
+ drm_scdc_readb(ddc, SCDC_SINK_VERSION, );
+ drm_scdc_writeb(ddc, SCDC_SOURCE_VERSION,
min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION));
/* Enabled Scrambling in the Sink */
- drm_scdc_set_scrambling(hdmi->ddc, 1);
+ drm_scdc_set_scrambling(hdmi->connector.ddc, 1);
/*
* To activate the scrambler feature, you must ensure
@@ -1781,7 +1781,7 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi,
hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL);
hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ,
HDMI_MC_SWRSTZ);
- drm_scdc_set_scrambling(hdmi->ddc, 0);
+ drm_scdc_set_scrambling(hdmi->connector.ddc, 0);
}
}
@@ -2127,10 +2127,10 @@ static int dw_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
int ret = 0;
- if (!hdmi->ddc)
+ if (!hdmi->connector.ddc)
return 0;
- edid = drm_get_edid(connector, hdmi->ddc);
+ edid = drm_get_edid(connector, hdmi->connector.ddc);
if (edid) {
dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
edid->width_cm, edid->height_cm);
@@ -2548,9 +2548,9 @@ __dw_hdmi_probe(struct platform_device *pdev,
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
- hdmi->ddc = of_get_i2c_adapter_by_node(ddc_node);
+ hdmi->connector.ddc = of_get_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
- if (!hdmi->ddc) {
+ if (!hdmi->connector.ddc) {
dev_dbg(hdmi->dev, "failed to read ddc node\n");
return ERR_PTR(-EPROBE_DEFER);
}
@@ -2689,7 +2689,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
hdmi_init_clk_regenerator(hdmi);
/* If DDC bus is not specified, try to register HDMI I2C bus */
- if (!hdmi->ddc) {
+ if (!hdmi->connector.ddc) {
/* Look for (optional) stuff related to unwedging */
hdmi->pinctrl = devm_pinctrl_get(dev);
if (!IS_ERR(hdmi->pinctrl)) {
@@ -2708,9 +2708,9 @@
[PATCH v4 21/23] drm/amdgpu: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 56 ---
1 file changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 73b2ede773d3..e119d4c1f724 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -1574,10 +1574,12 @@ amdgpu_connector_add(struct amdgpu_device *adev,
amdgpu_connector->con_priv = amdgpu_dig_connector;
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus = amdgpu_i2c_lookup(adev,
i2c_bus);
- if (amdgpu_connector->ddc_bus)
+ if (amdgpu_connector->ddc_bus) {
has_aux = true;
- else
+ connector->ddc =
_connector->ddc_bus->adapter;
+ } else {
DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
}
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
@@ -1659,13 +1661,15 @@ amdgpu_connector_add(struct amdgpu_device *adev,
} else {
switch (connector_type) {
case DRM_MODE_CONNECTOR_VGA:
- drm_connector_init(dev, _connector->base,
_connector_vga_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_connector_vga_helper_funcs);
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus =
amdgpu_i2c_lookup(adev, i2c_bus);
if (!amdgpu_connector->ddc_bus)
DRM_ERROR("VGA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init(dev, _connector->base,
_connector_vga_funcs, connector_type);
+ drm_connector_helper_add(_connector->base,
_connector_vga_helper_funcs);
amdgpu_connector->dac_load_detect = true;
drm_object_attach_property(_connector->base.base,
adev->mode_info.load_detect_property,
@@ -1679,13 +1683,15 @@ amdgpu_connector_add(struct amdgpu_device *adev,
connector->doublescan_allowed = true;
break;
case DRM_MODE_CONNECTOR_DVIA:
- drm_connector_init(dev, _connector->base,
_connector_vga_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_connector_vga_helper_funcs);
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus =
amdgpu_i2c_lookup(adev, i2c_bus);
if (!amdgpu_connector->ddc_bus)
DRM_ERROR("DVIA: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init(dev, _connector->base,
_connector_vga_funcs, connector_type);
+ drm_connector_helper_add(_connector->base,
_connector_vga_helper_funcs);
amdgpu_connector->dac_load_detect = true;
drm_object_attach_property(_connector->base.base,
adev->mode_info.load_detect_property,
@@ -1704,13 +1710,15 @@ amdgpu_connector_add(struct amdgpu_device *adev,
if (!amdgpu_dig_connector)
goto failed;
amdgpu_connector->con_priv = amdgpu_dig_connector;
- drm_connector_init(dev, _connector->base,
_connector_dvi_funcs, connector_type);
- drm_connector_helper_add(_connector->base,
_connector_dvi_helper_funcs);
if (i2c_bus->valid) {
amdgpu_connector->ddc_bus =
amdgpu_i2c_lookup(adev, i2c_bus);
if (!amdgpu_connector->ddc_bus)
DRM_ERROR("DVI: Failed to assign ddc
bus! Check dmesg for i2c errors.\n");
+ else
+ connector->ddc =
_connector->ddc_bus->adapter;
}
+ drm_connector_init(dev, _connector->base,
_connector_dvi_funcs, connector_type);
+ drm_connector_helper_add(_connector->base,
[PATCH v4 20/23] drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/ti-tfp410.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index dbf35c7bc85e..e55358f0a5ba 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -26,7 +26,6 @@ struct tfp410 {
unsigned intconnector_type;
u32 bus_format;
- struct i2c_adapter *ddc;
struct gpio_desc*hpd;
int hpd_irq;
struct delayed_work hpd_work;
@@ -55,10 +54,10 @@ static int tfp410_get_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (!dvi->ddc)
+ if (!dvi->connector.ddc)
goto fallback;
- edid = drm_get_edid(connector, dvi->ddc);
+ edid = drm_get_edid(connector, dvi->connector.ddc);
if (!edid) {
DRM_INFO("EDID read failed. Fallback to standard modes\n");
goto fallback;
@@ -98,8 +97,8 @@ tfp410_connector_detect(struct drm_connector *connector, bool
force)
return connector_status_disconnected;
}
- if (dvi->ddc) {
- if (drm_probe_ddc(dvi->ddc))
+ if (dvi->connector.ddc) {
+ if (drm_probe_ddc(dvi->connector.ddc))
return connector_status_connected;
else
return connector_status_disconnected;
@@ -297,8 +296,8 @@ static int tfp410_get_connector_properties(struct tfp410
*dvi)
if (!ddc_phandle)
goto fail;
- dvi->ddc = of_get_i2c_adapter_by_node(ddc_phandle);
- if (dvi->ddc)
+ dvi->connector.ddc = of_get_i2c_adapter_by_node(ddc_phandle);
+ if (dvi->connector.ddc)
dev_info(dvi->dev, "Connector's ddc i2c bus found\n");
else
ret = -EPROBE_DEFER;
@@ -367,7 +366,7 @@ static int tfp410_init(struct device *dev, bool i2c)
return 0;
fail:
- i2c_put_adapter(dvi->ddc);
+ i2c_put_adapter(dvi->connector.ddc);
if (dvi->hpd)
gpiod_put(dvi->hpd);
return ret;
@@ -382,8 +381,8 @@ static int tfp410_fini(struct device *dev)
drm_bridge_remove(>bridge);
- if (dvi->ddc)
- i2c_put_adapter(dvi->ddc);
+ if (dvi->connector.ddc)
+ i2c_put_adapter(dvi->connector.ddc);
if (dvi->hpd)
gpiod_put(dvi->hpd);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/23] drm/tilcdc: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c index 62d014c20988..c373edb95666 100644 --- a/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c +++ b/drivers/gpu/drm/tilcdc/tilcdc_tfp410.c @@ -219,6 +219,7 @@ static struct drm_connector *tfp410_connector_create(struct drm_device *dev, tfp410_connector->mod = mod; connector = _connector->base; + connector->ddc = mod->i2c; drm_connector_init(dev, connector, _connector_funcs, DRM_MODE_CONNECTOR_DVID); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 18/23] drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/bridge/dumb-vga-dac.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
b/drivers/gpu/drm/bridge/dumb-vga-dac.c
index d32885b906ae..b4cc3238400a 100644
--- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
+++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
@@ -20,7 +20,6 @@ struct dumb_vga {
struct drm_bridge bridge;
struct drm_connectorconnector;
- struct i2c_adapter *ddc;
struct regulator*vdd;
};
@@ -42,10 +41,10 @@ static int dumb_vga_get_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- if (IS_ERR(vga->ddc))
+ if (IS_ERR(vga->connector.ddc))
goto fallback;
- edid = drm_get_edid(connector, vga->ddc);
+ edid = drm_get_edid(connector, vga->connector.ddc);
if (!edid) {
DRM_INFO("EDID readout failed, falling back to standard
modes\n");
goto fallback;
@@ -84,7 +83,7 @@ dumb_vga_connector_detect(struct drm_connector *connector,
bool force)
* wire the DDC pins, or the I2C bus might not be working at
* all.
*/
- if (!IS_ERR(vga->ddc) && drm_probe_ddc(vga->ddc))
+ if (!IS_ERR(vga->connector.ddc) && drm_probe_ddc(vga->connector.ddc))
return connector_status_connected;
return connector_status_unknown;
@@ -190,14 +189,14 @@ static int dumb_vga_probe(struct platform_device *pdev)
dev_dbg(>dev, "No vdd regulator found: %d\n", ret);
}
- vga->ddc = dumb_vga_retrieve_ddc(>dev);
- if (IS_ERR(vga->ddc)) {
- if (PTR_ERR(vga->ddc) == -ENODEV) {
+ vga->connector.ddc = dumb_vga_retrieve_ddc(>dev);
+ if (IS_ERR(vga->connector.ddc)) {
+ if (PTR_ERR(vga->connector.ddc) == -ENODEV) {
dev_dbg(>dev,
"No i2c bus specified. Disabling EDID
readout\n");
} else {
dev_err(>dev, "Couldn't retrieve i2c bus\n");
- return PTR_ERR(vga->ddc);
+ return PTR_ERR(vga->connector.ddc);
}
}
@@ -216,8 +215,8 @@ static int dumb_vga_remove(struct platform_device *pdev)
drm_bridge_remove(>bridge);
- if (!IS_ERR(vga->ddc))
- i2c_put_adapter(vga->ddc);
+ if (!IS_ERR(vga->connector.ddc))
+ i2c_put_adapter(vga->connector.ddc);
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 17/23] drm/ast: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/ast/ast_mode.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index ffccbef962a4..1ca9bc4aa3bb 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -890,6 +890,11 @@ static int ast_connector_init(struct drm_device *dev)
return -ENOMEM;
connector = _connector->base;
+ ast_connector->i2c = ast_i2c_create(dev);
+ if (!ast_connector->i2c)
+ DRM_ERROR("failed to add ddc bus for connector\n");
+
+ connector->ddc = _connector->i2c->adapter;
drm_connector_init(dev, connector, _connector_funcs,
DRM_MODE_CONNECTOR_VGA);
drm_connector_helper_add(connector, _connector_helper_funcs);
@@ -904,10 +909,6 @@ static int ast_connector_init(struct drm_device *dev)
encoder = list_first_entry(>mode_config.encoder_list, struct
drm_encoder, head);
drm_connector_attach_encoder(connector, encoder);
- ast_connector->i2c = ast_i2c_create(dev);
- if (!ast_connector->i2c)
- DRM_ERROR("failed to add ddc bus for connector\n");
-
return 0;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 16/23] drm/mgag200: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index a25054015e8c..8fb9444b2142 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1703,6 +1703,11 @@ static struct drm_connector *mga_vga_init(struct
drm_device *dev)
return NULL;
connector = _connector->base;
+ mga_connector->i2c = mgag200_i2c_create(dev);
+ if (!mga_connector->i2c)
+ DRM_ERROR("failed to add ddc bus\n");
+
+ connector->ddc = _connector->i2c->adapter;
drm_connector_init(dev, connector,
_vga_connector_funcs, DRM_MODE_CONNECTOR_VGA);
@@ -1711,10 +1716,6 @@ static struct drm_connector *mga_vga_init(struct
drm_device *dev)
drm_connector_register(connector);
- mga_connector->i2c = mgag200_i2c_create(dev);
- if (!mga_connector->i2c)
- DRM_ERROR("failed to add ddc bus\n");
-
return connector;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 15/23] drm: sti: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/sti/sti_hdmi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c index f03d617edc4c..90f8db63c095 100644 --- a/drivers/gpu/drm/sti/sti_hdmi.c +++ b/drivers/gpu/drm/sti/sti_hdmi.c @@ -1279,6 +1279,7 @@ static int sti_hdmi_bind(struct device *dev, struct device *master, void *data) drm_bridge_attach(encoder, bridge, NULL); connector->encoder = encoder; + drm_connector->ddc = hdmi->ddc_adapt; drm_connector = (struct drm_connector *)connector; -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 12/23] drm: zte: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/zte/zx_hdmi.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c
index bfe918b27c5c..862a855ea14a 100644
--- a/drivers/gpu/drm/zte/zx_hdmi.c
+++ b/drivers/gpu/drm/zte/zx_hdmi.c
@@ -29,15 +29,11 @@
#define ZX_HDMI_INFOFRAME_SIZE 31
#define DDC_SEGMENT_ADDR 0x30
-struct zx_hdmi_i2c {
- struct i2c_adapter adap;
- struct mutex lock;
-};
-
struct zx_hdmi {
struct drm_connector connector;
struct drm_encoder encoder;
- struct zx_hdmi_i2c *ddc;
+ /* protects ddc access */
+ struct mutex ddc_lock;
struct device *dev;
struct drm_device *drm;
void __iomem *mmio;
@@ -264,7 +260,7 @@ static int zx_hdmi_connector_get_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- edid = drm_get_edid(connector, >ddc->adap);
+ edid = drm_get_edid(connector, connector->ddc);
if (!edid)
return 0;
@@ -562,10 +558,9 @@ static int zx_hdmi_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
{
struct zx_hdmi *hdmi = i2c_get_adapdata(adap);
- struct zx_hdmi_i2c *ddc = hdmi->ddc;
int i, ret = 0;
- mutex_lock(>lock);
+ mutex_lock(>ddc_lock);
/* Enable DDC master access */
hdmi_writeb_mask(hdmi, TPI_DDC_MASTER_EN, HW_DDC_MASTER, HW_DDC_MASTER);
@@ -590,7 +585,7 @@ static int zx_hdmi_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
/* Disable DDC master access */
hdmi_writeb_mask(hdmi, TPI_DDC_MASTER_EN, HW_DDC_MASTER, 0);
- mutex_unlock(>lock);
+ mutex_unlock(>ddc_lock);
return ret;
}
@@ -608,17 +603,15 @@ static const struct i2c_algorithm zx_hdmi_algorithm = {
static int zx_hdmi_ddc_register(struct zx_hdmi *hdmi)
{
struct i2c_adapter *adap;
- struct zx_hdmi_i2c *ddc;
int ret;
- ddc = devm_kzalloc(hdmi->dev, sizeof(*ddc), GFP_KERNEL);
- if (!ddc)
+ adap = devm_kzalloc(hdmi->dev, sizeof(*adap), GFP_KERNEL);
+ if (!adap)
return -ENOMEM;
- hdmi->ddc = ddc;
- mutex_init(>lock);
+ hdmi->connector.ddc = adap;
+ mutex_init(>ddc_lock);
- adap = >adap;
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DDC;
adap->dev.parent = hdmi->dev;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 13/23] drm: zte: Provide ddc symlink in vga connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/zte/zx_vga.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c
index 1634a08707fb..a3a4d6982888 100644
--- a/drivers/gpu/drm/zte/zx_vga.c
+++ b/drivers/gpu/drm/zte/zx_vga.c
@@ -23,15 +23,11 @@ struct zx_vga_pwrctrl {
u32 mask;
};
-struct zx_vga_i2c {
- struct i2c_adapter adap;
- struct mutex lock;
-};
-
struct zx_vga {
struct drm_connector connector;
struct drm_encoder encoder;
- struct zx_vga_i2c *ddc;
+ /* protects ddc access */
+ struct mutex ddc_lock;
struct device *dev;
void __iomem *mmio;
struct clk *i2c_wclk;
@@ -86,7 +82,7 @@ static int zx_vga_connector_get_modes(struct drm_connector
*connector)
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
- edid = drm_get_edid(connector, >ddc->adap);
+ edid = drm_get_edid(connector, connector->ddc);
if (!edid) {
/*
* If EDID reading fails, we set the device state into
@@ -282,11 +278,10 @@ static int zx_vga_i2c_xfer(struct i2c_adapter *adap,
struct i2c_msg *msgs,
int num)
{
struct zx_vga *vga = i2c_get_adapdata(adap);
- struct zx_vga_i2c *ddc = vga->ddc;
int ret = 0;
int i;
- mutex_lock(>lock);
+ mutex_lock(>ddc_lock);
for (i = 0; i < num; i++) {
if (msgs[i].flags & I2C_M_RD)
@@ -301,7 +296,7 @@ static int zx_vga_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg *msgs,
if (!ret)
ret = num;
- mutex_unlock(>lock);
+ mutex_unlock(>ddc_lock);
return ret;
}
@@ -320,17 +315,15 @@ static int zx_vga_ddc_register(struct zx_vga *vga)
{
struct device *dev = vga->dev;
struct i2c_adapter *adap;
- struct zx_vga_i2c *ddc;
int ret;
- ddc = devm_kzalloc(dev, sizeof(*ddc), GFP_KERNEL);
- if (!ddc)
+ adap = devm_kzalloc(dev, sizeof(*adap), GFP_KERNEL);
+ if (!adap)
return -ENOMEM;
- vga->ddc = ddc;
- mutex_init(>lock);
+ vga->connector.ddc = adap;
+ mutex_init(>ddc_lock);
- adap = >adap;
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DDC;
adap->dev.parent = dev;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/23] drm/vc4: Provide ddc symlink in connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ee7d4e7b0ee3..abacd48a1462 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -76,7 +76,6 @@ struct vc4_hdmi {
struct vc4_hdmi_audio audio;
- struct i2c_adapter *ddc;
void __iomem *hdmicore_regs;
void __iomem *hd_regs;
int hpd_gpio;
@@ -207,7 +206,7 @@ vc4_hdmi_connector_detect(struct drm_connector *connector,
bool force)
return connector_status_disconnected;
}
- if (drm_probe_ddc(vc4->hdmi->ddc))
+ if (drm_probe_ddc(connector->ddc))
return connector_status_connected;
if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
@@ -233,7 +232,7 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
int ret = 0;
struct edid *edid;
- edid = drm_get_edid(connector, vc4->hdmi->ddc);
+ edid = drm_get_edid(connector, connector->ddc);
cec_s_phys_addr_from_edid(vc4->hdmi->cec_adap, edid);
if (!edid)
return -ENODEV;
@@ -267,7 +266,8 @@ static const struct drm_connector_helper_funcs
vc4_hdmi_connector_helper_funcs =
};
static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
-struct drm_encoder
*encoder)
+struct drm_encoder
*encoder,
+struct i2c_adapter *ddc)
{
struct drm_connector *connector;
struct vc4_hdmi_connector *hdmi_connector;
@@ -280,6 +280,7 @@ static struct drm_connector *vc4_hdmi_connector_init(struct
drm_device *dev,
connector = _connector->base;
hdmi_connector->encoder = encoder;
+ connector->ddc = ddc;
drm_connector_init(dev, connector, _hdmi_connector_funcs,
DRM_MODE_CONNECTOR_HDMIA);
@@ -1291,6 +1292,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
struct vc4_hdmi *hdmi;
struct vc4_hdmi_encoder *vc4_hdmi_encoder;
struct device_node *ddc_node;
+ struct i2c_adapter *ddc;
u32 value;
int ret;
@@ -1338,9 +1340,9 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
return -ENODEV;
}
- hdmi->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
- if (!hdmi->ddc) {
+ if (ddc) {
DRM_DEBUG("Failed to get ddc i2c adapter by node\n");
return -EPROBE_DEFER;
}
@@ -1395,7 +1397,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(hdmi->encoder, _hdmi_encoder_helper_funcs);
- hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder);
+ hdmi->connector = vc4_hdmi_connector_init(drm, hdmi->encoder, ddc);
if (IS_ERR(hdmi->connector)) {
ret = PTR_ERR(hdmi->connector);
goto err_destroy_encoder;
@@ -1452,7 +1454,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
err_put_i2c:
- put_device(>ddc->dev);
+ put_device(>dev);
return ret;
}
@@ -1463,6 +1465,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct
device *master,
struct drm_device *drm = dev_get_drvdata(master);
struct vc4_dev *vc4 = drm->dev_private;
struct vc4_hdmi *hdmi = vc4->hdmi;
+ struct i2c_adapter *ddc = hdmi->connector->ddc;
cec_unregister_adapter(hdmi->cec_adap);
vc4_hdmi_connector_destroy(hdmi->connector);
@@ -1471,7 +1474,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct
device *master,
clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
- put_device(>ddc->dev);
+ put_device(>dev);
vc4->hdmi = NULL;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/23] drm/imx: imx-tve: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/imx/imx-tve.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index e725af8a0025..b8bee4e1f169 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -109,7 +109,6 @@ struct imx_tve {
struct regmap *regmap;
struct regulator *dac_reg;
- struct i2c_adapter *ddc;
struct clk *clk;
struct clk *di_sel_clk;
struct clk_hw clk_hw_di;
@@ -218,14 +217,13 @@ static int tve_setup_vga(struct imx_tve *tve)
static int imx_tve_connector_get_modes(struct drm_connector *connector)
{
- struct imx_tve *tve = con_to_tve(connector);
struct edid *edid;
int ret = 0;
- if (!tve->ddc)
+ if (!connector->ddc)
return 0;
- edid = drm_get_edid(connector, tve->ddc);
+ edid = drm_get_edid(connector, connector->ddc);
if (edid) {
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
@@ -551,7 +549,7 @@ static int imx_tve_bind(struct device *dev, struct device
*master, void *data)
ddc_node = of_parse_phandle(np, "ddc-i2c-bus", 0);
if (ddc_node) {
- tve->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ tve->connector.ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/23] drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/imx/imx-ldb.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 383733302280..44fdb264339e 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -55,7 +55,6 @@ struct imx_ldb_channel {
struct drm_bridge *bridge;
struct device_node *child;
- struct i2c_adapter *ddc;
int chno;
void *edid;
int edid_len;
@@ -131,8 +130,8 @@ static int imx_ldb_connector_get_modes(struct drm_connector
*connector)
return num_modes;
}
- if (!imx_ldb_ch->edid && imx_ldb_ch->ddc)
- imx_ldb_ch->edid = drm_get_edid(connector, imx_ldb_ch->ddc);
+ if (!imx_ldb_ch->edid && connector->ddc)
+ imx_ldb_ch->edid = drm_get_edid(connector, connector->ddc);
if (imx_ldb_ch->edid) {
drm_connector_update_edid_property(connector,
@@ -550,15 +549,15 @@ static int imx_ldb_panel_ddc(struct device *dev,
ddc_node = of_parse_phandle(child, "ddc-i2c-bus", 0);
if (ddc_node) {
- channel->ddc = of_find_i2c_adapter_by_node(ddc_node);
+ channel->connector.ddc = of_find_i2c_adapter_by_node(ddc_node);
of_node_put(ddc_node);
- if (!channel->ddc) {
+ if (!channel->connector.ddc) {
dev_warn(dev, "failed to get ddc i2c adapter\n");
return -EPROBE_DEFER;
}
}
- if (!channel->ddc) {
+ if (!channel->connector.ddc) {
/* if no DDC available, fallback to hardcoded EDID */
dev_dbg(dev, "no ddc available\n");
@@ -725,7 +724,7 @@ static void imx_ldb_unbind(struct device *dev, struct
device *master,
drm_panel_detach(channel->panel);
kfree(channel->edid);
- i2c_put_adapter(channel->ddc);
+ i2c_put_adapter(channel->connector.ddc);
}
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 08/23] drm/tegra: Provide ddc symlink in output connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/tegra/drm.h| 1 -
drivers/gpu/drm/tegra/output.c | 12 ++--
drivers/gpu/drm/tegra/sor.c| 6 +++---
3 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 86daa19fcf24..9bf72bcd3ec1 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -120,7 +120,6 @@ struct tegra_output {
struct device *dev;
struct drm_panel *panel;
- struct i2c_adapter *ddc;
const struct edid *edid;
struct cec_notifier *cec;
unsigned int hpd_irq;
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 274cb955e2e1..0b5037a29c63 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -30,8 +30,8 @@ int tegra_output_connector_get_modes(struct drm_connector
*connector)
if (output->edid)
edid = kmemdup(output->edid, sizeof(*edid), GFP_KERNEL);
- else if (output->ddc)
- edid = drm_get_edid(connector, output->ddc);
+ else if (connector->ddc)
+ edid = drm_get_edid(connector, connector->ddc);
cec_notifier_set_phys_addr_from_edid(output->cec, edid);
drm_connector_update_edid_property(connector, edid);
@@ -111,8 +111,8 @@ int tegra_output_probe(struct tegra_output *output)
ddc = of_parse_phandle(output->of_node, "nvidia,ddc-i2c-bus", 0);
if (ddc) {
- output->ddc = of_find_i2c_adapter_by_node(ddc);
- if (!output->ddc) {
+ output->connector.ddc = of_find_i2c_adapter_by_node(ddc);
+ if (!output->connector.ddc) {
err = -EPROBE_DEFER;
of_node_put(ddc);
return err;
@@ -174,8 +174,8 @@ void tegra_output_remove(struct tegra_output *output)
if (output->hpd_gpio)
free_irq(output->hpd_irq, output);
- if (output->ddc)
- put_device(>ddc->dev);
+ if (output->connector.ddc)
+ put_device(>connector.ddc->dev);
}
int tegra_output_init(struct drm_device *drm, struct tegra_output *output)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 4ffe3794e6d3..77e61f98de07 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -2311,7 +2311,7 @@ static void tegra_sor_hdmi_disable_scrambling(struct
tegra_sor *sor)
static void tegra_sor_hdmi_scdc_disable(struct tegra_sor *sor)
{
- struct i2c_adapter *ddc = sor->output.ddc;
+ struct i2c_adapter *ddc = sor->output.connector.ddc;
drm_scdc_set_high_tmds_clock_ratio(ddc, false);
drm_scdc_set_scrambling(ddc, false);
@@ -2339,7 +2339,7 @@ static void tegra_sor_hdmi_enable_scrambling(struct
tegra_sor *sor)
static void tegra_sor_hdmi_scdc_enable(struct tegra_sor *sor)
{
- struct i2c_adapter *ddc = sor->output.ddc;
+ struct i2c_adapter *ddc = sor->output.connector.ddc;
drm_scdc_set_high_tmds_clock_ratio(ddc, true);
drm_scdc_set_scrambling(ddc, true);
@@ -2350,7 +2350,7 @@ static void tegra_sor_hdmi_scdc_enable(struct tegra_sor
*sor)
static void tegra_sor_hdmi_scdc_work(struct work_struct *work)
{
struct tegra_sor *sor = container_of(work, struct tegra_sor, scdc.work);
- struct i2c_adapter *ddc = sor->output.ddc;
+ struct i2c_adapter *ddc = sor->output.connector.ddc;
if (!drm_scdc_get_scrambling_status(ddc)) {
DRM_DEBUG_KMS("SCDC not scrambled\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 07/23] drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c
b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 5d6a9f094df5..6c5321dcc4b8 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -146,7 +146,6 @@ struct mtk_hdmi {
struct device *dev;
struct phy *phy;
struct device *cec_dev;
- struct i2c_adapter *ddc_adpt;
struct clk *clk[MTK_HDMI_CLK_COUNT];
struct drm_display_mode mode;
bool dvi_mode;
@@ -1213,10 +1212,10 @@ static int mtk_hdmi_conn_get_modes(struct drm_connector
*conn)
struct edid *edid;
int ret;
- if (!hdmi->ddc_adpt)
+ if (!conn->ddc)
return -ENODEV;
- edid = drm_get_edid(conn, hdmi->ddc_adpt);
+ edid = drm_get_edid(conn, conn->ddc);
if (!edid)
return -ENODEV;
@@ -1509,9 +1508,9 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
}
of_node_put(remote);
- hdmi->ddc_adpt = of_find_i2c_adapter_by_node(i2c_np);
+ hdmi->conn.ddc = of_find_i2c_adapter_by_node(i2c_np);
of_node_put(i2c_np);
- if (!hdmi->ddc_adpt) {
+ if (!hdmi->conn.ddc) {
dev_err(dev, "Failed to get ddc i2c adapter by node\n");
return -EINVAL;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/23] drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f8ca98d294d0..d64b119c2649 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -59,7 +59,6 @@ struct inno_hdmi {
struct drm_encoder encoder;
struct inno_hdmi_i2c *i2c;
- struct i2c_adapter *ddc;
unsigned int tmds_rate;
@@ -552,10 +551,10 @@ static int inno_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
int ret = 0;
- if (!hdmi->ddc)
+ if (!hdmi->connector.ddc)
return 0;
- edid = drm_get_edid(connector, hdmi->ddc);
+ edid = drm_get_edid(connector, hdmi->connector.ddc);
if (edid) {
hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
@@ -850,10 +849,10 @@ static int inno_hdmi_bind(struct device *dev, struct
device *master,
inno_hdmi_reset(hdmi);
- hdmi->ddc = inno_hdmi_i2c_adapter(hdmi);
- if (IS_ERR(hdmi->ddc)) {
- ret = PTR_ERR(hdmi->ddc);
- hdmi->ddc = NULL;
+ hdmi->connector.ddc = inno_hdmi_i2c_adapter(hdmi);
+ if (IS_ERR(hdmi->connector.ddc)) {
+ ret = PTR_ERR(hdmi->connector.ddc);
+ hdmi->connector.ddc = NULL;
goto err_disable_clk;
}
@@ -886,7 +885,7 @@ static int inno_hdmi_bind(struct device *dev, struct device
*master,
hdmi->connector.funcs->destroy(>connector);
hdmi->encoder.funcs->destroy(>encoder);
err_put_adapter:
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
err_disable_clk:
clk_disable_unprepare(hdmi->pclk);
return ret;
@@ -900,7 +899,7 @@ static void inno_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(>connector);
hdmi->encoder.funcs->destroy(>encoder);
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
clk_disable_unprepare(hdmi->pclk);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 06/23] drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/sun4i/sun4i_hdmi.h | 1 -
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 14 +++---
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 7ad3f06c127e..1649273b1493 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -265,7 +265,6 @@ struct sun4i_hdmi {
struct clk *tmds_clk;
struct i2c_adapter *i2c;
- struct i2c_adapter *ddc_i2c;
/* Regmap fields for I2C adapter */
struct regmap_field *field_ddc_en;
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 9c3f99339b82..250bec00dc35 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -213,7 +213,7 @@ static int sun4i_hdmi_get_modes(struct drm_connector
*connector)
struct edid *edid;
int ret;
- edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
+ edid = drm_get_edid(connector, connector->ddc ?: hdmi->i2c);
if (!edid)
return 0;
@@ -598,11 +598,11 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
goto err_disable_mod_clk;
}
- hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
- if (IS_ERR(hdmi->ddc_i2c)) {
- ret = PTR_ERR(hdmi->ddc_i2c);
+ hdmi->connector.ddc = sun4i_hdmi_get_ddc(dev);
+ if (IS_ERR(hdmi->connector.ddc)) {
+ ret = PTR_ERR(hdmi->connector.ddc);
if (ret == -ENODEV)
- hdmi->ddc_i2c = NULL;
+ hdmi->connector.ddc = NULL;
else
goto err_del_i2c_adapter;
}
@@ -663,7 +663,7 @@ static int sun4i_hdmi_bind(struct device *dev, struct
device *master,
cec_delete_adapter(hdmi->cec_adap);
drm_encoder_cleanup(>encoder);
err_put_ddc_i2c:
- i2c_put_adapter(hdmi->ddc_i2c);
+ i2c_put_adapter(hdmi->connector.ddc);
err_del_i2c_adapter:
i2c_del_adapter(hdmi->i2c);
err_disable_mod_clk:
@@ -684,7 +684,7 @@ static void sun4i_hdmi_unbind(struct device *dev, struct
device *master,
drm_connector_cleanup(>connector);
drm_encoder_cleanup(>encoder);
i2c_del_adapter(hdmi->i2c);
- i2c_put_adapter(hdmi->ddc_i2c);
+ i2c_put_adapter(hdmi->connector.ddc);
clk_disable_unprepare(hdmi->mod_clk);
clk_disable_unprepare(hdmi->bus_clk);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/23] drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory
Use the ddc pointer provided by the generic connector. Signed-off-by: Andrzej Pietrasiewicz --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c index 07b4cb877d82..6f33d5e43dd2 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi_connector.c @@ -450,6 +450,7 @@ struct drm_connector *msm_hdmi_connector_init(struct hdmi *hdmi) connector = _connector->base; + connector->ddc = hdmi->i2c; drm_connector_init(hdmi->dev, connector, _connector_funcs, DRM_MODE_CONNECTOR_HDMIA); drm_connector_helper_add(connector, _hdmi_connector_helper_funcs); -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/23] drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory
Use the ddc pointer provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/rockchip/rk3066_hdmi.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
index 85fc5f01f761..1f3e630ecdab 100644
--- a/drivers/gpu/drm/rockchip/rk3066_hdmi.c
+++ b/drivers/gpu/drm/rockchip/rk3066_hdmi.c
@@ -49,7 +49,6 @@ struct rk3066_hdmi {
struct drm_encoder encoder;
struct rk3066_hdmi_i2c *i2c;
- struct i2c_adapter *ddc;
unsigned int tmdsclk;
@@ -470,10 +469,10 @@ static int rk3066_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
int ret = 0;
- if (!hdmi->ddc)
+ if (!connector->ddc)
return 0;
- edid = drm_get_edid(connector, hdmi->ddc);
+ edid = drm_get_edid(connector, connector->ddc);
if (edid) {
hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
drm_connector_update_edid_property(connector, edid);
@@ -789,10 +788,10 @@ static int rk3066_hdmi_bind(struct device *dev, struct
device *master,
/* internal hclk = hdmi_hclk / 25 */
hdmi_writeb(hdmi, HDMI_INTERNAL_CLK_DIVIDER, 25);
- hdmi->ddc = rk3066_hdmi_i2c_adapter(hdmi);
- if (IS_ERR(hdmi->ddc)) {
- ret = PTR_ERR(hdmi->ddc);
- hdmi->ddc = NULL;
+ hdmi->connector.ddc = rk3066_hdmi_i2c_adapter(hdmi);
+ if (IS_ERR(hdmi->connector.ddc)) {
+ ret = PTR_ERR(hdmi->connector.ddc);
+ hdmi->connector.ddc = NULL;
goto err_disable_hclk;
}
@@ -824,7 +823,7 @@ static int rk3066_hdmi_bind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(>connector);
hdmi->encoder.funcs->destroy(>encoder);
err_disable_i2c:
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
err_disable_hclk:
clk_disable_unprepare(hdmi->hclk);
@@ -839,7 +838,7 @@ static void rk3066_hdmi_unbind(struct device *dev, struct
device *master,
hdmi->connector.funcs->destroy(>connector);
hdmi->encoder.funcs->destroy(>encoder);
- i2c_put_adapter(hdmi->ddc);
+ i2c_put_adapter(hdmi->connector.ddc);
clk_disable_unprepare(hdmi->hclk);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/23] drm/exynos: Provide ddc symlink in connector's sysfs
Switch to using the ddc provided by the generic connector.
Signed-off-by: Andrzej Pietrasiewicz
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index bc1565f1822a..b4332dae6ed5 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -125,7 +125,6 @@ struct hdmi_context {
void __iomem*regs;
void __iomem*regs_hdmiphy;
struct i2c_client *hdmiphy_port;
- struct i2c_adapter *ddc_adpt;
struct gpio_desc*hpd_gpio;
int irq;
struct regmap *pmureg;
@@ -871,10 +870,10 @@ static int hdmi_get_modes(struct drm_connector *connector)
struct edid *edid;
int ret;
- if (!hdata->ddc_adpt)
+ if (!connector->ddc)
return -ENODEV;
- edid = drm_get_edid(connector, hdata->ddc_adpt);
+ edid = drm_get_edid(connector, connector->ddc);
if (!edid)
return -ENODEV;
@@ -1892,7 +1891,7 @@ static int hdmi_get_ddc_adapter(struct hdmi_context
*hdata)
return -EPROBE_DEFER;
}
- hdata->ddc_adpt = adpt;
+ hdata->connector.ddc = adpt;
return 0;
}
@@ -2044,7 +2043,7 @@ static int hdmi_probe(struct platform_device *pdev)
if (hdata->regs_hdmiphy)
iounmap(hdata->regs_hdmiphy);
err_ddc:
- put_device(>ddc_adpt->dev);
+ put_device(>connector.ddc->dev);
return ret;
}
@@ -2071,7 +2070,7 @@ static int hdmi_remove(struct platform_device *pdev)
if (hdata->regs_hdmiphy)
iounmap(hdata->regs_hdmiphy);
- put_device(>ddc_adpt->dev);
+ put_device(>connector.ddc->dev);
mutex_destroy(>mutex);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/23] drm: Include ddc adapter pointer in struct drm_connector
Add generic code which creates symbolic links in sysfs, pointing to ddc
interface used by a particular video output. For example:
ls -l /sys/class/drm/card0-HDMI-A-1/ddc
lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \
-> ../../../../soc/1388.i2c/i2c-2
This makes it easy for user to associate a display with its ddc adapter
and use e.g. ddcutil to control the chosen monitor.
This patch adds an i2c_adapter pointer to struct drm_connector. Particular
drivers can then use it instead of using their own private instance. If a
connector contains a ddc, then create a symbolic link in sysfs.
Signed-off-by: Andrzej Pietrasiewicz
Acked-by: Daniel Vetter
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/drm_sysfs.c | 7 +++
include/drm/drm_connector.h | 11 +++
2 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ad10810bc972..26d359b39785 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -294,6 +294,9 @@ int drm_sysfs_connector_add(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(dev);
+ if (connector->ddc)
+ return sysfs_create_link(>kdev->kobj,
+>ddc->dev.kobj, "ddc");
return 0;
}
@@ -301,6 +304,10 @@ void drm_sysfs_connector_remove(struct drm_connector
*connector)
{
if (!connector->kdev)
return;
+
+ if (connector->ddc)
+ sysfs_remove_link(>kdev->kobj, "ddc");
+
DRM_DEBUG("removing \"%s\" from sysfs\n",
connector->name);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ca745d9feaf5..1ad3d1d54ba7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -23,6 +23,7 @@
#ifndef __DRM_CONNECTOR_H__
#define __DRM_CONNECTOR_H__
+#include
#include
#include
#include
@@ -1308,6 +1309,16 @@ struct drm_connector {
* [0]: progressive, [1]: interlaced
*/
int audio_latency[2];
+
+ /**
+* @ddc: associated ddc adapter.
+* A connector usually has its associated ddc adapter. If a driver uses
+* this field, then an appropriate symbolic link is created in connector
+* sysfs directory to make it easy for the user to tell which i2c
+* adapter is for a particular display.
+*/
+ struct i2c_adapter *ddc;
+
/**
* @null_edid_counter: track sinks that give us all zeros for the EDID.
* Needed to workaround some HW bugs where we get all 0s
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 00/23] Associate ddc adapters with connectors
It is difficult for a user to know which of the i2c adapters is for which drm connector. This series addresses this problem. The idea is to have a symbolic link in connector's sysfs directory, e.g.: ls -l /sys/class/drm/card0-HDMI-A-1/ddc lrwxrwxrwx 1 root root 0 Jun 24 10:42 /sys/class/drm/card0-HDMI-A-1/ddc \ -> ../../../../soc/1388.i2c/i2c-2 The user then knows that their card0-HDMI-A-1 uses i2c-2 and can e.g. run ddcutil: ddcutil -b 2 getvcp 0x10 VCP code 0x10 (Brightness): current value =90, max value = 100 The first patch in the series adds struct i2c_adapter pointer to struct drm_connector. If the field is used by a particular driver, then an appropriate symbolic link is created by the generic code, which is also added by this patch. The next 22 patches is an example of how to convert a driver to this new scheme. v1..v2: - used fixed name "ddc" for the symbolic link in order to make it easy for userspace to find the i2c adapter v2..v3: - converted as many drivers as possible. v3..v4: - added Reviewed-by for patch 01/23 - moved "ddc" field assignment to before drm_connector_init() is called in msm, vc4, sti, mgag200, ast, amdgpu, radeon - simplified the code in amdgpu and radeon at the expense of some lines exceeding 80 characters as per Alex Deucher's suggestion - added i915 TODO: nouveau, gma500, omapdrm, panel-simple - if applicable. Other drivers are either already converted or don't mention neither "ddc" nor "i2c_adapter". Andrzej Pietrasiewicz (23): drm: Include ddc adapter pointer in struct drm_connector drm/exynos: Provide ddc symlink in connector's sysfs drm: rockchip: Provide ddc symlink in rk3066_hdmi sysfs directory drm: rockchip: Provide ddc symlink in inno_hdmi sysfs directory drm/msm/hdmi: Provide ddc symlink in hdmi connector sysfs directory drm/sun4i: hdmi: Provide ddc symlink in sun4i hdmi connector sysfs directory drm/mediatek: Provide ddc symlink in hdmi connector sysfs directory drm/tegra: Provide ddc symlink in output connector sysfs directory drm/imx: imx-ldb: Provide ddc symlink in connector's sysfs drm/imx: imx-tve: Provide ddc symlink in connector's sysfs drm/vc4: Provide ddc symlink in connector sysfs directory drm: zte: Provide ddc symlink in hdmi connector sysfs directory drm: zte: Provide ddc symlink in vga connector sysfs directory drm/tilcdc: Provide ddc symlink in connector sysfs directory drm: sti: Provide ddc symlink in hdmi connector sysfs directory drm/mgag200: Provide ddc symlink in connector sysfs directory drm/ast: Provide ddc symlink in connector sysfs directory drm/bridge: dumb-vga-dac: Provide ddc symlink in connector sysfs directory drm/bridge: dw-hdmi: Provide ddc symlink in connector sysfs directory drm/bridge: ti-tfp410: Provide ddc symlink in connector sysfs directory drm/amdgpu: Provide ddc symlink in connector sysfs directory drm/radeon: Provide ddc symlink in connector sysfs directory drm/i915: Provide ddc symlink in hdmi connector sysfs directory .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 56 - drivers/gpu/drm/ast/ast_mode.c| 9 ++- drivers/gpu/drm/bridge/dumb-vga-dac.c | 19 +++-- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 +- drivers/gpu/drm/bridge/ti-tfp410.c| 19 +++-- drivers/gpu/drm/drm_sysfs.c | 7 ++ drivers/gpu/drm/exynos/exynos_hdmi.c | 11 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 5 +- drivers/gpu/drm/imx/imx-ldb.c | 13 ++- drivers/gpu/drm/imx/imx-tve.c | 8 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +-- drivers/gpu/drm/mgag200/mgag200_mode.c| 9 ++- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 1 + drivers/gpu/drm/radeon/radeon_connectors.c| 80 --- drivers/gpu/drm/rockchip/inno_hdmi.c | 17 ++-- drivers/gpu/drm/rockchip/rk3066_hdmi.c| 17 ++-- drivers/gpu/drm/sti/sti_hdmi.c| 1 + drivers/gpu/drm/sun4i/sun4i_hdmi.h| 1 - drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 14 ++-- drivers/gpu/drm/tegra/drm.h | 1 - drivers/gpu/drm/tegra/output.c| 12 +-- drivers/gpu/drm/tegra/sor.c | 6 +- drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 1 + drivers/gpu/drm/vc4/vc4_hdmi.c| 21 ++--- drivers/gpu/drm/zte/zx_hdmi.c | 25 +++--- drivers/gpu/drm/zte/zx_vga.c | 25 +++--- include/drm/drm_connector.h | 11 +++ 27 files changed, 240 insertions(+), 198 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: add audio graph card support
On 03/07/2019 11:04, Olivier Moysan wrote:
> Implement get_dai_id callback of audio HDMI codec
> to support ASoC audio graph card.
> HDMI audio output has to be connected to sii902x port 3.
> get_dai_id callback maps this port to ASoC DAI index 0.
>
> Signed-off-by: Olivier Moysan
I have not used audio graph binding, but compared to the other
get_dai_id() implementations, this looks identical. So:
Reviewed-by: Jyri Sarha
> ---
> drivers/gpu/drm/bridge/sii902x.c | 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> b/drivers/gpu/drm/bridge/sii902x.c
> index dd7aa466b280..daf9ef3cd817 100644
> --- a/drivers/gpu/drm/bridge/sii902x.c
> +++ b/drivers/gpu/drm/bridge/sii902x.c
> @@ -158,6 +158,8 @@
>
> #define SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS 500
>
> +#define SII902X_AUDIO_PORT_INDEX 3
> +
> struct sii902x {
> struct i2c_client *i2c;
> struct regmap *regmap;
> @@ -690,11 +692,32 @@ static int sii902x_audio_get_eld(struct device *dev,
> void *data,
> return 0;
> }
>
> +static int sii902x_audio_get_dai_id(struct snd_soc_component *component,
> + struct device_node *endpoint)
> +{
> + struct of_endpoint of_ep;
> + int ret;
> +
> + ret = of_graph_parse_endpoint(endpoint, _ep);
> + if (ret < 0)
> + return ret;
> +
> + /*
> + * HDMI sound should be located at reg = <3>
> + * Return expected DAI index 0.
> + */
> + if (of_ep.port == SII902X_AUDIO_PORT_INDEX)
> + return 0;
> +
> + return -EINVAL;
> +}
> +
> static const struct hdmi_codec_ops sii902x_audio_codec_ops = {
> .hw_params = sii902x_audio_hw_params,
> .audio_shutdown = sii902x_audio_shutdown,
> .digital_mute = sii902x_audio_digital_mute,
> .get_eld = sii902x_audio_get_eld,
> + .get_dai_id = sii902x_audio_get_dai_id,
> };
>
> static int sii902x_audio_codec_init(struct sii902x *sii902x,
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: add audio graph card support
On 11.07.2019 11:27, Philippe CORNU wrote: > Hi Daniel, > > > On 7/10/19 5:27 PM, Daniel Vetter wrote: >> On Fri, Jul 05, 2019 at 12:41:03PM +, Philippe CORNU wrote: >>> Hi Olivier, >>> and many thanks for your patch. >>> Good to have the audio graph card support, looks ok. >>> Reviewed-by: Philippe Cornu >> Since you have drm-misc commit rights I'm assuming you're going to push >> this too. Correct? >> -Daniel > Regarding this patch in particular, there is still missing an acked-by > from a "bridge" maintainer. Also it could be nice to wait for the > reviewed-by from Jiry as it knows well this sii driver and sent recently > good patches on it (already merged). > > With that, Benjamin or I (or a bridge maintainer) can push this patch + > the serie named "drm/bridge: sii902x: fix audio mclk management" as I > think it is better to push this serie *before* this patch. > > Thanks, > Philippe :-) Acked-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 5/5] drm/edid: Make sure the CEA mode arrays have the correct amount of modes
From: Ville Syrjälä
We depend on a specific relationship between the VIC number and the
index in the CEA mode arrays. Assert that the arrays have the excpected
size to make sure we've not accidentally left holes in them.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e6b1e785d158..f0b449225727 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3209,6 +3209,9 @@ static u8 *drm_find_cea_extension(const struct edid *edid)
static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
{
+ BUILD_BUG_ON(ARRAY_SIZE(edid_cea_modes_1) != 127);
+ BUILD_BUG_ON(ARRAY_SIZE(edid_cea_modes_193) != 27);
+
if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
return _cea_modes_1[vic - 1];
if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/5] drm/edid: Throw away the dummy VIC 0 cea mode
From: Ville Syrjälä
Now that the cea mode handling is not 100% tied to the single
array the dummy VIC 0 mode is pretty much pointles. Throw it
out.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 0e103c99e471..e6b1e785d158 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -709,11 +709,9 @@ static const struct minimode extra_modes[] = {
/*
* From CEA/CTA-861 spec.
*
- * Index with VIC.
+ * Index with VIC-1.
*/
-static const struct drm_display_mode edid_cea_modes_0[] = {
- /* 0 - dummy, VICs start at 1 */
- { },
+static const struct drm_display_mode edid_cea_modes_1[] = {
/* 1 - 640x480@60Hz 4:3 */
{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
752, 800, 0, 480, 490, 492, 525, 0,
@@ -3211,10 +3209,8 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
{
- if (!vic)
- return NULL;
- if (vic < ARRAY_SIZE(edid_cea_modes_0))
- return _cea_modes_0[vic];
+ if (vic >= 1 && vic < 1 + ARRAY_SIZE(edid_cea_modes_1))
+ return _cea_modes_1[vic - 1];
if (vic >= 193 && vic < 193 + ARRAY_SIZE(edid_cea_modes_193))
return _cea_modes_193[vic - 193];
return NULL;
@@ -3227,7 +3223,7 @@ static u8 cea_num_vics(void)
static u8 cea_next_vic(u8 vic)
{
- if (++vic == ARRAY_SIZE(edid_cea_modes_0))
+ if (++vic == 1 + ARRAY_SIZE(edid_cea_modes_1))
vic = 193;
return vic;
}
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/edid: Abstract away cea_edid_modes[]
From: Ville Syrjälä
We're going to need two cea mode tables (on for VICs < 128,
another one for VICs >= 193). To that end replace the direct
edid_cea_modes[] lookups with a function call. And we'll rename
the array to edid_cea_modes_0[] to indicathe how it's to be
indexed.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 80 +++---
1 file changed, 58 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index bcd9ed569d64..703d2bc26fd9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -707,12 +707,11 @@ static const struct minimode extra_modes[] = {
};
/*
- * Probably taken from CEA-861 spec.
- * This table is converted from xorg's hw/xfree86/modes/xf86EdidModes.c.
+ * From CEA/CTA-861 spec.
*
- * Index using the VIC.
+ * Index with VIC.
*/
-static const struct drm_display_mode edid_cea_modes[] = {
+static const struct drm_display_mode edid_cea_modes_0[] = {
/* 0 - dummy, VICs start at 1 */
{ },
/* 1 - 640x480@60Hz 4:3 */
@@ -3067,6 +3066,25 @@ static u8 *drm_find_cea_extension(const struct edid
*edid)
return cea;
}
+static const struct drm_display_mode *cea_mode_for_vic(u8 vic)
+{
+ if (!vic)
+ return NULL;
+ if (vic < ARRAY_SIZE(edid_cea_modes_0))
+ return _cea_modes_0[vic];
+ return NULL;
+}
+
+static u8 cea_num_vics(void)
+{
+ return ARRAY_SIZE(edid_cea_modes_0);
+}
+
+static u8 cea_next_vic(u8 vic)
+{
+ return vic + 1;
+}
+
/*
* Calculate the alternate clock for the CEA mode
* (60Hz vs. 59.94Hz etc.)
@@ -3104,14 +3122,14 @@ cea_mode_alternate_timings(u8 vic, struct
drm_display_mode *mode)
* get the other variants by simply increasing the
* vertical front porch length.
*/
- BUILD_BUG_ON(edid_cea_modes[8].vtotal != 262 ||
-edid_cea_modes[9].vtotal != 262 ||
-edid_cea_modes[12].vtotal != 262 ||
-edid_cea_modes[13].vtotal != 262 ||
-edid_cea_modes[23].vtotal != 312 ||
-edid_cea_modes[24].vtotal != 312 ||
-edid_cea_modes[27].vtotal != 312 ||
-edid_cea_modes[28].vtotal != 312);
+ BUILD_BUG_ON(cea_mode_for_vic(8)->vtotal != 262 ||
+cea_mode_for_vic(9)->vtotal != 262 ||
+cea_mode_for_vic(12)->vtotal != 262 ||
+cea_mode_for_vic(13)->vtotal != 262 ||
+cea_mode_for_vic(23)->vtotal != 312 ||
+cea_mode_for_vic(24)->vtotal != 312 ||
+cea_mode_for_vic(27)->vtotal != 312 ||
+cea_mode_for_vic(28)->vtotal != 312);
if (((vic == 8 || vic == 9 ||
vic == 12 || vic == 13) && mode->vtotal < 263) ||
@@ -3139,10 +3157,16 @@ static u8 drm_match_cea_mode_clock_tolerance(const
struct drm_display_mode *to_m
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
- for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
- struct drm_display_mode cea_mode = edid_cea_modes[vic];
+ for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+ const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+ struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
+ if (!mode)
+ continue;
+
+ cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3178,10 +3202,16 @@ u8 drm_match_cea_mode(const struct drm_display_mode
*to_match)
if (to_match->picture_aspect_ratio)
match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
- for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
- struct drm_display_mode cea_mode = edid_cea_modes[vic];
+ for (vic = 1; vic < cea_num_vics(); vic = cea_next_vic(vic)) {
+ const struct drm_display_mode *mode = cea_mode_for_vic(vic);
+ struct drm_display_mode cea_mode;
unsigned int clock1, clock2;
+ if (!mode)
+ continue;
+
+ cea_mode = *mode;
+
/* Check both 60Hz and 59.94Hz */
clock1 = cea_mode.clock;
clock2 = cea_mode_alternate_clock(_mode);
@@ -3202,7 +3232,7 @@ EXPORT_SYMBOL(drm_match_cea_mode);
static bool drm_valid_cea_vic(u8 vic)
{
- return vic > 0 && vic < ARRAY_SIZE(edid_cea_modes);
+ return cea_mode_for_vic(vic) != NULL;
}
/**
@@ -3214,7 +3244,13 @@ static bool drm_valid_cea_vic(u8 vic)
*/
enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const u8 video_code)
{
- return
[PATCH v2 1/5] drm/edid: Add CTA-861-G modes with VIC < 128
From: Ville Syrjälä
Fill out our list of cea modes with the new stuff from CTA-861-G.
We only do the modes with VIC < 128 here. Adding the higher
numbered VICs will need some slight code refactoring first.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 100 +
1 file changed, 100 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 82a4ceed3fcf..bcd9ed569d64 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1275,6 +1275,106 @@ static const struct drm_display_mode edid_cea_modes[] =
{
4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
.vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 108 - 1280x720@48Hz 16:9 */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
+ 2280, 2500, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 109 - 1280x720@48Hz 64:27 */
+ { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 9, 1280, 2240,
+ 2280, 2500, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 110 - 1680x720@48Hz 64:27 */
+ { DRM_MODE("1680x720", DRM_MODE_TYPE_DRIVER, 99000, 1680, 2490,
+ 2530, 2750, 0, 720, 725, 730, 750, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 111 - 1920x1080@48Hz 16:9 */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2558,
+ 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 112 - 1920x1080@48Hz 64:27 */
+ { DRM_MODE("1920x1080", DRM_MODE_TYPE_DRIVER, 148500, 1920, 2558,
+ 2602, 2750, 0, 1080, 1084, 1089, 1125, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 113 - 2560x1080@48Hz 64:27 */
+ { DRM_MODE("2560x1080", DRM_MODE_TYPE_DRIVER, 198000, 2560, 3558,
+ 3602, 3750, 0, 1080, 1084, 1089, 1100, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 114 - 3840x2160@48Hz 16:9 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 5116,
+ 5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 115 - 4096x2160@48Hz 256:135 */
+ { DRM_MODE("4096x2160", DRM_MODE_TYPE_DRIVER, 594000, 4096, 5116,
+ 5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_256_135,
},
+ /* 116 - 3840x2160@48Hz 64:27 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 594000, 3840, 5116,
+ 5204, 5500, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 117 - 3840x2160@100Hz 16:9 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4896,
+ 4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 118 - 3840x2160@120Hz 16:9 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4016,
+ 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 119 - 3840x2160@100Hz 64:27 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4896,
+ 4984, 5280, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 120 - 3840x2160@120Hz 64:27 */
+ { DRM_MODE("3840x2160", DRM_MODE_TYPE_DRIVER, 1188000, 3840, 4016,
+ 4104, 4400, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio =
[PATCH v2 0/5] drm/edid: Add new modes from CTA-861-G
From: Ville Syrjälä Reposting a series from 1-2 years ago. I did toss in one extra patch at the end to boost our confidence a bit bit. Cc: Hans Verkuil Cc: Shashank Sharma Ville Syrjälä (5): drm/edid: Add CTA-861-G modes with VIC < 128 drm/edid: Abstract away cea_edid_modes[] drm/edid: Add CTA-861-G modes with VIC >= 193 drm/edid: Throw away the dummy VIC 0 cea mode drm/edid: Make sure the CEA mode arrays have the correct amount of modes drivers/gpu/drm/drm_edid.c | 330 ++--- 1 file changed, 306 insertions(+), 24 deletions(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/5] drm/edid: Add CTA-861-G modes with VIC >= 193
From: Ville Syrjälä
Add a second table to the cea modes with VIC >= 193.
Cc: Hans Verkuil
Cc: Shashank Sharma
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 151 -
1 file changed, 149 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 703d2bc26fd9..0e103c99e471 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1376,6 +1376,149 @@ static const struct drm_display_mode edid_cea_modes_0[]
= {
.vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
};
+/*
+ * From CEA/CTA-861 spec.
+ *
+ * Index with VIC-193.
+ */
+static const struct drm_display_mode edid_cea_modes_193[] = {
+ /* 193 - 5120x2160@120Hz 64:27 */
+ { DRM_MODE("5120x2160", DRM_MODE_TYPE_DRIVER, 1485000, 5120, 5284,
+ 5372, 5500, 0, 2160, 2168, 2178, 2250, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 194 - 7680x4320@24Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 195 - 7680x4320@25Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
+ 10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 196 - 7680x4320@30Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
+ 8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 197 - 7680x4320@48Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 198 - 7680x4320@50Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10032,
+ 10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 199 - 7680x4320@60Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 8232,
+ 8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 200 - 7680x4320@100Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 9792,
+ 9968, 10560, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 100, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 201 - 7680x4320@120Hz 16:9 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 4752000, 7680, 8032,
+ 8208, 8800, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 120, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
+ /* 202 - 7680x4320@24Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 24, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 203 - 7680x4320@25Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 10032,
+ 10208, 10800, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 25, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 204 - 7680x4320@30Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 1188000, 7680, 8232,
+ 8408, 9000, 0, 4320, 4336, 4356, 4400, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 30, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 205 - 7680x4320@48Hz 64:27 */
+ { DRM_MODE("7680x4320", DRM_MODE_TYPE_DRIVER, 2376000, 7680, 10232,
+ 10408, 11000, 0, 4320, 4336, 4356, 4500, 0,
+ DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
+ .vrefresh = 48, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_64_27, },
+ /* 206 - 7680x4320@50Hz 64:27 */
+ {
Re: [PATCH] drm/bridge: sii902x: add audio graph card support
On Thu, Jul 11, 2019 at 09:27:30AM +, Philippe CORNU wrote:
> Hi Daniel,
>
>
> On 7/10/19 5:27 PM, Daniel Vetter wrote:
> > On Fri, Jul 05, 2019 at 12:41:03PM +, Philippe CORNU wrote:
> >> Hi Olivier,
> >> and many thanks for your patch.
> >> Good to have the audio graph card support, looks ok.
> >> Reviewed-by: Philippe Cornu
> >
> > Since you have drm-misc commit rights I'm assuming you're going to push
> > this too. Correct?
>
> Regarding this patch in particular, there is still missing an acked-by
> from a "bridge" maintainer. Also it could be nice to wait for the
> reviewed-by from Jiry as it knows well this sii driver and sent recently
> good patches on it (already merged).
The bridge maintainer is looking for new bridge maintainers (atm we have
only one, defacto), so for bridge driver patches I really don't think it's
a good idea to gate on that single bottle-neck. Infrastructure is a bit a
different thing.
> With that, Benjamin or I (or a bridge maintainer) can push this patch +
> the serie named "drm/bridge: sii902x: fix audio mclk management" as I
> think it is better to push this serie *before* this patch.
Wahtever you feel like, just wanted to make sure you're not stuck
twiddling thumbs. The entire point of drm-misc is to facility mesh review
and maintainership, because the strict hierarchy just doesn't work for
smaller things. Exactly because you're always blocked on a bottleneck
somewhere.
-Daniel
>
> Thanks,
> Philippe :-)
>
>
> >> Philippe :-)
> >>
> >> On 7/3/19 10:04 AM, Olivier Moysan wrote:
> >>> Implement get_dai_id callback of audio HDMI codec
> >>> to support ASoC audio graph card.
> >>> HDMI audio output has to be connected to sii902x port 3.
> >>> get_dai_id callback maps this port to ASoC DAI index 0.
> >>>
> >>> Signed-off-by: Olivier Moysan
> >>> ---
> >>>drivers/gpu/drm/bridge/sii902x.c | 23 +++
> >>>1 file changed, 23 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/bridge/sii902x.c
> >>> b/drivers/gpu/drm/bridge/sii902x.c
> >>> index dd7aa466b280..daf9ef3cd817 100644
> >>> --- a/drivers/gpu/drm/bridge/sii902x.c
> >>> +++ b/drivers/gpu/drm/bridge/sii902x.c
> >>> @@ -158,6 +158,8 @@
> >>>
> >>>#define SII902X_I2C_BUS_ACQUISITION_TIMEOUT_MS 500
> >>>
> >>> +#define SII902X_AUDIO_PORT_INDEX 3
> >>> +
> >>>struct sii902x {
> >>> struct i2c_client *i2c;
> >>> struct regmap *regmap;
> >>> @@ -690,11 +692,32 @@ static int sii902x_audio_get_eld(struct device
> >>> *dev, void *data,
> >>> return 0;
> >>>}
> >>>
> >>> +static int sii902x_audio_get_dai_id(struct snd_soc_component *component,
> >>> + struct device_node *endpoint)
> >>> +{
> >>> + struct of_endpoint of_ep;
> >>> + int ret;
> >>> +
> >>> + ret = of_graph_parse_endpoint(endpoint, _ep);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> +
> >>> + /*
> >>> + * HDMI sound should be located at reg = <3>
> >>> + * Return expected DAI index 0.
> >>> + */
> >>> + if (of_ep.port == SII902X_AUDIO_PORT_INDEX)
> >>> + return 0;
> >>> +
> >>> + return -EINVAL;
> >>> +}
> >>> +
> >>>static const struct hdmi_codec_ops sii902x_audio_codec_ops = {
> >>> .hw_params = sii902x_audio_hw_params,
> >>> .audio_shutdown = sii902x_audio_shutdown,
> >>> .digital_mute = sii902x_audio_digital_mute,
> >>> .get_eld = sii902x_audio_get_eld,
> >>> + .get_dai_id = sii902x_audio_get_dai_id,
> >>>};
> >>>
> >>>static int sii902x_audio_codec_init(struct sii902x *sii902x,
> >>>
> >
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
