Re: [PATCH v2] fbcon: Silence fbcon logo on 'quiet' boots
Hi Prarit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on sof-driver-fuweitax/master]
[also build test ERROR on v4.19 next-20181029]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Prarit-Bhargava/fbcon-Silence-fbcon-logo-on-quiet-boots/20181029-233506
base: https://github.com/fuweitax/linux master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
kernel/module.c:257:18: warning: symbol 'kdb_modules' was not declared.
Should it be static?
>> kernel/module.c:3915:41: error: incompatible types in comparison expression
>> (different address spaces)
kernel/module.c:4050:28: error: incompatible types in comparison expression
(different address spaces)
kernel/module.c:4069:41: error: incompatible types in comparison expression
(different address spaces)
vim +3915 kernel/module.c
2e7bac53 Rusty Russell2016-02-03 3907
^1da177e Linus Torvalds 2005-04-16 3908 static const char
*get_ksymbol(struct module *mod,
^1da177e Linus Torvalds 2005-04-16 3909 unsigned
long addr,
^1da177e Linus Torvalds 2005-04-16 3910 unsigned
long *size,
^1da177e Linus Torvalds 2005-04-16 3911 unsigned
long *offset)
^1da177e Linus Torvalds 2005-04-16 3912 {
^1da177e Linus Torvalds 2005-04-16 3913 unsigned int i, best = 0;
^1da177e Linus Torvalds 2005-04-16 3914 unsigned long nextval;
8244062e Rusty Russell2016-02-03 @3915 struct mod_kallsyms *kallsyms =
rcu_dereference_sched(mod->kallsyms);
^1da177e Linus Torvalds 2005-04-16 3916
^1da177e Linus Torvalds 2005-04-16 3917 /* At worse, next value is at
end of module */
a06f6211 Masami Hiramatsu 2009-01-06 3918 if (within_module_init(addr,
mod))
7523e4dc Rusty Russell2015-11-26 3919 nextval = (unsigned
long)mod->init_layout.base+mod->init_layout.text_size;
^1da177e Linus Torvalds 2005-04-16 3920 else
7523e4dc Rusty Russell2015-11-26 3921 nextval = (unsigned
long)mod->core_layout.base+mod->core_layout.text_size;
^1da177e Linus Torvalds 2005-04-16 3922
25985edc Lucas De Marchi 2011-03-30 3923 /* Scan for closest preceding
symbol, and next symbol. (ELF
^1da177e Linus Torvalds 2005-04-16 3924 starts real symbols at 1). */
8244062e Rusty Russell2016-02-03 3925 for (i = 1; i <
kallsyms->num_symtab; i++) {
8244062e Rusty Russell2016-02-03 3926 if
(kallsyms->symtab[i].st_shndx == SHN_UNDEF)
^1da177e Linus Torvalds 2005-04-16 3927 continue;
^1da177e Linus Torvalds 2005-04-16 3928
^1da177e Linus Torvalds 2005-04-16 3929 /* We ignore unnamed
symbols: they're uninformative
^1da177e Linus Torvalds 2005-04-16 3930 * and inserted at a
whim. */
8244062e Rusty Russell2016-02-03 3931 if (*symname(kallsyms,
i) == '\0'
8244062e Rusty Russell2016-02-03 3932 ||
is_arm_mapping_symbol(symname(kallsyms, i)))
2e7bac53 Rusty Russell2016-02-03 3933 continue;
2e7bac53 Rusty Russell2016-02-03 3934
8244062e Rusty Russell2016-02-03 3935 if
(kallsyms->symtab[i].st_value <= addr
8244062e Rusty Russell2016-02-03 3936 &&
kallsyms->symtab[i].st_value > kallsyms->symtab[best].st_value)
^1da177e Linus Torvalds 2005-04-16 3937 best = i;
8244062e Rusty Russell2016-02-03 3938 if
(kallsyms->symtab[i].st_value > addr
8244062e Rusty Russell2016-02-03 3939 &&
kallsyms->symtab[i].st_value < nextval)
8244062e Rusty Russell2016-02-03 3940 nextval =
kallsyms->symtab[i].st_value;
^1da177e Linus Torvalds 2005-04-16 3941 }
^1da177e Linus Torvalds 2005-04-16 3942
^1da177e Linus Torvalds 2005-04-16 3943 if (!best)
^1da177e Linus Torvalds 2005-04-16 3944 return NULL;
^1da177e Linus Torvalds 2005-04-16 3945
ffb45122 Alexey Dobriyan 2007-05-08 3946 if (size)
8244062e Rusty Russell2016-02-03 3947 *size = nextval -
kallsyms->symtab[best].st_value;
ffb45122 Alexey Dobriyan 2007-05-08 3948 if (offset)
8244062e Rusty Russell2016-02-03 3949 *offset = addr -
kallsyms->symtab[best].st_value;
8244062e Rusty Russell2016-02-03 3950 return symname(kallsyms, best);
^1da177e Linus Torvalds 2005-04-16 3951 }
^1da177e Linus Torvalds 2005-04-16 3952
:: The code at line 3915 was first introduced by commit
:: 8244062e
Re: [PATCH] gpu/drm/virtio/virtgpu_vq.c: Use kmem_cache_zalloc
On Tue, Oct 23, 2018 at 12:50:36PM +0300, Jani Nikula wrote: > On Tue, 23 Oct 2018, Souptick Joarder wrote: > > On Fri, Oct 19, 2018 at 9:30 PM Sabyasachi Gupta > > wrote: > >> > >> Replaced kmem_cache_alloc + memset with kmem_cache_zalloc > > > > Put a new line gap in between these two lines and send v2. > > Nah, the maintainers can trivially add the newline while > applying. Review is much more valuable than nitpicking on the commit > message. Queued (and added newline). thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/virtio: document drm_dev_set_unique workaround
On Wed, Oct 24, 2018 at 03:42:52PM +0100, Emil Velikov wrote: > From: Emil Velikov > > A while back we removed it, yet that lead to regressions. At some later > point, I've attempted to remove it again without fully grasping the > unique (pun intended) situation that virtio is in. > > Add a bulky comment to document why the call should stay as-is, for the > next person who's around. > > As a Tl;Dr: virtio sits on top of struct virtio_device, which confuses > dev_is_pci(), wrong info gets sent to userspace and X doesn't start. > Driver needs to explicitly call drm_dev_set_unique() to keep it working. > > v2: Fix handful of typos (Laszlo) > > Cc: Daniel Vetter > Cc: Gerd Hoffmann > Cc: Hans de Goede > Cc: Laszlo Ersek > Signed-off-by: Emil Velikov > Reviewed-by: Laszlo Ersek Reviewed-by: Gerd Hoffmann > Sending it out for posterity-sake. Modulo any objections I'll merge > this via drm-misc. Ah, good, leaving merging to you then ;) cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108585] *ERROR* hw_init of IP block failed -22
https://bugs.freedesktop.org/show_bug.cgi?id=108585 --- Comment #4 from Joel --- I see a similar backtrace on 4.19.0-11706-g11743c56785c (Linus' tree mid-merge window). My system has a "fiji" card. The first kernel is 4.19 (upstream release), and the second kernel where the backtrace occurs is with 4.19+. The second kernel is kexec'd from the first. If I don't load amdgpu in the first kernel, the second kernel works. So there is something missed in the shutdown path. -- 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 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #11 from Duncan Roe --- (and the patch enables DRM_AMD_DC_FBC) -- 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: [Intel-gfx] [PATCH] RFC: Make igts for cross-driver stuff mandatory?
On Fri, 19 Oct 2018 at 18:51, Daniel Vetter wrote: > > Hi all, > > This is just to collect feedback on this idea, and see whether the > overall dri-devel community stands on all this. I think the past few > cross-vendor uapi extensions all came with igts attached, and > personally I think there's lots of value in having them: A > cross-vendor interface isn't useful if every driver implements it > slightly differently. > > I think there's 2 questions here: > > - Do we want to make such testcases mandatory? Yes I think if at all practical it probably makes sense to have some mandatory test cases for all cross-vendor features, or features that might become cross vendor in the future. > > - If yes, are we there yet, or is there something crucially missing > still? I think the does igt build in all the places needed is the main one, I've no idea what a baseline IGT test run looks like on non-intel hw, how useful is it? Acked-by: Dave Airlie ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] udmabuf: set read/write flag when exporting
Otherwise, mmap fails when done with PROT_WRITE.
---
drivers/dma-buf/udmabuf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c
index 5b44ef226904..fc359ca4503d 100644
--- a/drivers/dma-buf/udmabuf.c
+++ b/drivers/dma-buf/udmabuf.c
@@ -184,6 +184,7 @@ static long udmabuf_create(const struct udmabuf_create_list
*head,
exp_info.ops = _ops;
exp_info.size = ubuf->pagecount << PAGE_SHIFT;
exp_info.priv = ubuf;
+ exp_info.flags = O_RDWR;
buf = dma_buf_export(_info);
if (IS_ERR(buf)) {
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107947] REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:563 during boot
https://bugs.freedesktop.org/show_bug.cgi?id=107947 --- Comment #5 from Kent Ross --- Created attachment 142269 --> https://bugs.freedesktop.org/attachment.cgi?id=142269=edit dmesg logs for successful boot to login screen -- 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 107947] REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:563 during boot
https://bugs.freedesktop.org/show_bug.cgi?id=107947 --- Comment #4 from Kent Ross --- Created attachment 142268 --> https://bugs.freedesktop.org/attachment.cgi?id=142268=edit dmesg logs for failed boot to black screen -- 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 107947] REG_WAIT timeout 10us * 3500 tries - dce_mi_free_dmif line:563 during boot
https://bugs.freedesktop.org/show_bug.cgi?id=107947 Kent Ross changed: What|Removed |Added CC||root.m...@gmail.com --- Comment #3 from Kent Ross --- I have this issue, or one very like it. I have a system with both a Vega64 and a GTX 980ti. The 980ti is controlled by the vfio-pci driver (preempting nouveau, nvidiafb, etc. on boot) and is therefore not in use by this host system. If a display is plugged into the 980ti at boot time, booting will always fail with a black screen and more failures from drm. If a display is not plugged in, booting will almost always work without a problem, with fewer errors from drm. Even with no display plugged into the 980ti, when the system's displays (plugged into the vega64) resume when they have been sleeping (such as on the lock screen) there is a substantial chance all displays will be completely black and drm failures can be seen in dmesg. If a display is plugged into the 980ti when the main displays wake, the outcome is much less likely to be good. In the case where the system is returning from sleeping screens it fortunately does not fully necessitate a complete reboot, as the displays will sleep again in a few seconds and it can be tried again until success. Nonetheless, as this system is intended to be used as a VM host with a passed-through monitor, this bug is a showstopper. I have full dmesg logs from boot to an unusable black screen, and from boot to a login screen. -- 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: [Intel-gfx] [PATCH v6 13/28] drm/i915/dp: Compute DSC pipe config in atomic check
On Mon, Oct 29, 2018 at 10:34:58PM +0200, Ville Syrjälä wrote:
> On Mon, Oct 29, 2018 at 10:30:39PM +0200, Ville Syrjälä wrote:
> > On Wed, Oct 24, 2018 at 03:28:25PM -0700, Manasi Navare wrote:
> > > DSC params like the enable, compressed bpp, slice count and
> > > dsc_split are added to the intel_crtc_state. These parameters
> > > are set based on the requested mode and available link parameters
> > > during the pipe configuration in atomic check phase.
> > > These values are then later used to populate the remaining DSC
> > > and RC parameters before enbaling DSC in atomic commit.
> > >
> > > v9:
> > > * Rebase on top of drm-tip that now uses fast_narrow config
> > > for edp (Manasi)
> > > v8:
> > > * Check for DSC bpc not 0 (manasi)
> > >
> > > v7:
> > > * Fix indentation in compute_m_n (Manasi)
> > >
> > > v6 (From Gaurav):
> > > * Remove function call of intel_dp_compute_dsc_params() and
> > > invoke intel_dp_compute_dsc_params() in the patch where
> > > it is defined to fix compilation warning (Gaurav)
> > >
> > > v5:
> > > Add drm_dsc_cfg in intel_crtc_state (Manasi)
> > >
> > > v4:
> > > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> > > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
> > >
> > > v3:
> > > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
> > >
> > > v2:
> > > * Add if-else for eDP/DP (Gaurav)
> > >
> > > Cc: Jani Nikula
> > > Cc: Ville Syrjala
> > > Cc: Anusha Srivatsa
> > > Cc: Gaurav K Singh
> > > Signed-off-by: Manasi Navare
> > > Reviewed-by: Anusha Srivatsa
> > > Acked-by: Jani Nikula
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 20 +++-
> > > drivers/gpu/drm/i915/intel_display.h | 3 +-
> > > drivers/gpu/drm/i915/intel_dp.c | 170 ++-
> > > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > > 4 files changed, 155 insertions(+), 40 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index fe045abb6472..18737bd82b68 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6434,7 +6434,7 @@ static int ironlake_fdi_compute_config(struct
> > > intel_crtc *intel_crtc,
> > >
> > > pipe_config->fdi_lanes = lane;
> > >
> > > - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> > > + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> > > link_bw, _config->fdi_m_n, false);
> > >
> > > ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> > > @@ -6671,17 +6671,25 @@ static void compute_m_n(unsigned int m, unsigned
> > > int n,
> > > }
> > >
> > > void
> > > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> > > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> > > +int nlanes,
> > > int pixel_clock, int link_clock,
> > > struct intel_link_m_n *m_n,
> > > bool constant_n)
> > > {
> > > m_n->tu = 64;
> > >
> > > - compute_m_n(bits_per_pixel * pixel_clock,
> > > - link_clock * nlanes * 8,
> > > - _n->gmch_m, _n->gmch_n,
> > > - constant_n);
> > > + /* For DSC, Data M/N calculation uses compressed BPP */
> > > + if (compressed_bpp)
> > > + compute_m_n(compressed_bpp * pixel_clock,
> > > + link_clock * nlanes * 8,
> > > + _n->gmch_m, _n->gmch_n,
> > > + constant_n);
> > > + else
> > > + compute_m_n(bits_per_pixel * pixel_clock,
> > > + link_clock * nlanes * 8,
> > > + _n->gmch_m, _n->gmch_n,
> > > + constant_n);
> > >
> > > compute_m_n(pixel_clock, link_clock,
> > > _n->link_m, _n->link_n,
> > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > b/drivers/gpu/drm/i915/intel_display.h
> > > index 5d50decbcbb5..b0b23e1e9392 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > @@ -407,7 +407,8 @@ struct intel_link_m_n {
> > >(__i)++) \
> > > for_each_if(plane)
> > >
> > > -void intel_link_compute_m_n(int bpp, int nlanes,
> > > +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> > > + int nlanes,
> > > int pixel_clock, int link_clock,
> > > struct intel_link_m_n *m_n,
> > > bool constant_n);
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 6f66a38ba0b2..a88f9371dd32 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -47,6 +47,8 @@
> > >
> > > /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> > > #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> > > +#define
Re: [PATCH v4 1/2] drm: Add drm_any_plane_has_format()
Ville Syrjala writes: > From: Ville Syrjälä > > Add a function to check whether there is at least one plane that > supports a specific format and modifier combination. Drivers can > use this to reject unsupported formats/modifiers in .fb_create(). > > v2: Accept anyformat if the driver doesn't do planes (Eric) > s/planes_have_format/any_plane_has_format/ (Eric) > Check the modifier as well since we already have a function > that does both > v3: Don't do the check in the core since we may not know the > modifier yet, instead export the function and let drivers > call it themselves > > Cc: Eric Anholt > Cc: Dhinakaran Pandiyan > Signed-off-by: Ville Syrjälä > Reviewed-by: Dhinakaran Pandiyan I don't particularly see the point in having FB creation duplicate the validation that atomic check will eventually do, and it means that FB creation cost scales with plane count, but if i915's going to do this, it seems reasonable for them. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 13/28] drm/i915/dp: Compute DSC pipe config in atomic check
On Mon, Oct 29, 2018 at 10:30:39PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:25PM -0700, Manasi Navare wrote:
> > DSC params like the enable, compressed bpp, slice count and
> > dsc_split are added to the intel_crtc_state. These parameters
> > are set based on the requested mode and available link parameters
> > during the pipe configuration in atomic check phase.
> > These values are then later used to populate the remaining DSC
> > and RC parameters before enbaling DSC in atomic commit.
> >
> > v9:
> > * Rebase on top of drm-tip that now uses fast_narrow config
> > for edp (Manasi)
> > v8:
> > * Check for DSC bpc not 0 (manasi)
> >
> > v7:
> > * Fix indentation in compute_m_n (Manasi)
> >
> > v6 (From Gaurav):
> > * Remove function call of intel_dp_compute_dsc_params() and
> > invoke intel_dp_compute_dsc_params() in the patch where
> > it is defined to fix compilation warning (Gaurav)
> >
> > v5:
> > Add drm_dsc_cfg in intel_crtc_state (Manasi)
> >
> > v4:
> > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
> >
> > v3:
> > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
> >
> > v2:
> > * Add if-else for eDP/DP (Gaurav)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Gaurav K Singh
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > Acked-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 20 +++-
> > drivers/gpu/drm/i915/intel_display.h | 3 +-
> > drivers/gpu/drm/i915/intel_dp.c | 170 ++-
> > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > 4 files changed, 155 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fe045abb6472..18737bd82b68 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6434,7 +6434,7 @@ static int ironlake_fdi_compute_config(struct
> > intel_crtc *intel_crtc,
> >
> > pipe_config->fdi_lanes = lane;
> >
> > - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> > + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> >link_bw, _config->fdi_m_n, false);
> >
> > ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> > @@ -6671,17 +6671,25 @@ static void compute_m_n(unsigned int m, unsigned
> > int n,
> > }
> >
> > void
> > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> > + int nlanes,
> >int pixel_clock, int link_clock,
> >struct intel_link_m_n *m_n,
> >bool constant_n)
> > {
> > m_n->tu = 64;
> >
> > - compute_m_n(bits_per_pixel * pixel_clock,
> > - link_clock * nlanes * 8,
> > - _n->gmch_m, _n->gmch_n,
> > - constant_n);
> > + /* For DSC, Data M/N calculation uses compressed BPP */
> > + if (compressed_bpp)
> > + compute_m_n(compressed_bpp * pixel_clock,
> > + link_clock * nlanes * 8,
> > + _n->gmch_m, _n->gmch_n,
> > + constant_n);
> > + else
> > + compute_m_n(bits_per_pixel * pixel_clock,
> > + link_clock * nlanes * 8,
> > + _n->gmch_m, _n->gmch_n,
> > + constant_n);
> >
> > compute_m_n(pixel_clock, link_clock,
> > _n->link_m, _n->link_n,
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 5d50decbcbb5..b0b23e1e9392 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -407,7 +407,8 @@ struct intel_link_m_n {
> > (__i)++) \
> > for_each_if(plane)
> >
> > -void intel_link_compute_m_n(int bpp, int nlanes,
> > +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> > + int nlanes,
> > int pixel_clock, int link_clock,
> > struct intel_link_m_n *m_n,
> > bool constant_n);
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 6f66a38ba0b2..a88f9371dd32 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -47,6 +47,8 @@
> >
> > /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> > #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> > +#define DP_DSC_MIN_SUPPORTED_BPC 8
> > +#define DP_DSC_MAX_SUPPORTED_BPC 10
> >
> > /* DP DSC throughput values used for slice count calculations KPixels/s */
> > #define DP_DSC_PEAK_PIXEL_RATE 272
> > @@ -1924,6
Re: [PATCH 0/4] Improve virtio ID allocation
On Wed, Sep 26, 2018 at 09:00:27AM -0700, Matthew Wilcox wrote: > I noticed you were using IDRs where you could be using the more efficient > IDAs, then while fixing that I noticed the lack of error handling, > and I decided to follow that up with an efficiency improvement. > > There's probably a v2 of this to follow because I couldn't figure > out how to properly handle one of the error cases ... see the comment > embedded in one of the patches. #1 + #2 pushed to drm-misc-next now. #3 should not be needed any more. waiting for v2 of #4 ... cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected
https://bugs.freedesktop.org/show_bug.cgi?id=108577 --- Comment #10 from Duncan Roe --- DRM_AMD_DC_FBC is not in my .config and never has been (from the RCS tree) -- 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 13/28] drm/i915/dp: Compute DSC pipe config in atomic check
On Mon, Oct 29, 2018 at 10:30:39PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:25PM -0700, Manasi Navare wrote:
> > DSC params like the enable, compressed bpp, slice count and
> > dsc_split are added to the intel_crtc_state. These parameters
> > are set based on the requested mode and available link parameters
> > during the pipe configuration in atomic check phase.
> > These values are then later used to populate the remaining DSC
> > and RC parameters before enbaling DSC in atomic commit.
> >
> > v9:
> > * Rebase on top of drm-tip that now uses fast_narrow config
> > for edp (Manasi)
> > v8:
> > * Check for DSC bpc not 0 (manasi)
> >
> > v7:
> > * Fix indentation in compute_m_n (Manasi)
> >
> > v6 (From Gaurav):
> > * Remove function call of intel_dp_compute_dsc_params() and
> > invoke intel_dp_compute_dsc_params() in the patch where
> > it is defined to fix compilation warning (Gaurav)
> >
> > v5:
> > Add drm_dsc_cfg in intel_crtc_state (Manasi)
> >
> > v4:
> > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
> >
> > v3:
> > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
> >
> > v2:
> > * Add if-else for eDP/DP (Gaurav)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Gaurav K Singh
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > Acked-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 20 +++-
> > drivers/gpu/drm/i915/intel_display.h | 3 +-
> > drivers/gpu/drm/i915/intel_dp.c | 170 ++-
> > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > 4 files changed, 155 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fe045abb6472..18737bd82b68 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6434,7 +6434,7 @@ static int ironlake_fdi_compute_config(struct
> > intel_crtc *intel_crtc,
> >
> > pipe_config->fdi_lanes = lane;
> >
> > - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> > + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> >link_bw, _config->fdi_m_n, false);
> >
> > ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> > @@ -6671,17 +6671,25 @@ static void compute_m_n(unsigned int m, unsigned
> > int n,
> > }
> >
> > void
> > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> > + int nlanes,
> >int pixel_clock, int link_clock,
> >struct intel_link_m_n *m_n,
> >bool constant_n)
> > {
> > m_n->tu = 64;
> >
> > - compute_m_n(bits_per_pixel * pixel_clock,
> > - link_clock * nlanes * 8,
> > - _n->gmch_m, _n->gmch_n,
> > - constant_n);
> > + /* For DSC, Data M/N calculation uses compressed BPP */
> > + if (compressed_bpp)
> > + compute_m_n(compressed_bpp * pixel_clock,
> > + link_clock * nlanes * 8,
> > + _n->gmch_m, _n->gmch_n,
> > + constant_n);
> > + else
> > + compute_m_n(bits_per_pixel * pixel_clock,
> > + link_clock * nlanes * 8,
> > + _n->gmch_m, _n->gmch_n,
> > + constant_n);
> >
> > compute_m_n(pixel_clock, link_clock,
> > _n->link_m, _n->link_n,
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 5d50decbcbb5..b0b23e1e9392 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -407,7 +407,8 @@ struct intel_link_m_n {
> > (__i)++) \
> > for_each_if(plane)
> >
> > -void intel_link_compute_m_n(int bpp, int nlanes,
> > +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> > + int nlanes,
> > int pixel_clock, int link_clock,
> > struct intel_link_m_n *m_n,
> > bool constant_n);
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 6f66a38ba0b2..a88f9371dd32 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -47,6 +47,8 @@
> >
> > /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> > #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> > +#define DP_DSC_MIN_SUPPORTED_BPC 8
> > +#define DP_DSC_MAX_SUPPORTED_BPC 10
> >
> > /* DP DSC throughput values used for slice count calculations KPixels/s */
> > #define DP_DSC_PEAK_PIXEL_RATE 272
> > @@ -1924,6
Re: [PATCH v6 27/28] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
On Mon, Oct 29, 2018 at 10:39:21PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:39PM -0700, Manasi Navare wrote:
> > DSC can be supported per DP connector. This patch adds a per connector
> > debugfs node to expose DSC support capability by the kernel.
> > The same node can be used from userspace to force DSC enable.
>
> Why is the force_dsc thing split between two patches so strangely?
This patch just defines the force_dsc and sets it through the debugfs
node. But how it configures DSC during atomic check is moved to a
separate patch.
Would you prefer having that integrated with this patch itself?
Manasi
>
> >
> > v2:
> > * Use kstrtobool_from_user to avoid explicit error checking (Lyude)
> > * Rebase on drm-tip (Manasi)
> >
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Lyude Paul
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Lyude Paul
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 71 -
> > drivers/gpu/drm/i915/intel_dp.c | 1 +
> > drivers/gpu/drm/i915/intel_drv.h| 3 ++
> > 3 files changed, 74 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 5cadfcd03ea9..6e631f08dd4b 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -4999,6 +4999,72 @@ static int i915_hdcp_sink_capability_show(struct
> > seq_file *m, void *data)
> > }
> > DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
> >
> > +static int i915_dsc_support_show(struct seq_file *m, void *data)
> > +{
> > + struct drm_connector *connector = m->private;
> > + struct intel_encoder *encoder = intel_attached_encoder(connector);
> > + struct intel_dp *intel_dp =
> > + enc_to_intel_dp(>base);
> > + struct intel_crtc *crtc;
> > + struct intel_crtc_state *crtc_state;
> > +
> > + crtc = to_intel_crtc(encoder->base.crtc);
> > + crtc_state = to_intel_crtc_state(crtc->base.state);
> > + drm_modeset_lock(>base.mutex, NULL);
> > + seq_printf(m, "Enabled: %s\n",
> > + yesno(crtc_state->dsc_params.compression_enable));
> > + seq_printf(m, "Supported: %s\n",
> > + yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> > + drm_modeset_unlock(>base.mutex);
> > +
> > + return 0;
> > +}
> > +
> > +static ssize_t i915_dsc_support_write(struct file *file,
> > + const char __user *ubuf,
> > + size_t len, loff_t *offp)
> > +{
> > + bool dsc_enable = false;
> > + int ret;
> > + struct drm_connector *connector =
> > + ((struct seq_file *)file->private_data)->private;
> > + struct intel_encoder *encoder = intel_attached_encoder(connector);
> > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > +
> > + if (len == 0)
> > + return 0;
> > +
> > + DRM_DEBUG_DRIVER("Copied %d bytes from user to force DSC\n",
> > +(unsigned int)len);
> > +
> > + ret = kstrtobool_from_user(ubuf, len, _enable);
> > + if (ret < 0)
> > + return ret;
> > +
> > + DRM_DEBUG_DRIVER("Got %s for DSC Enable\n",
> > +(dsc_enable) ? "true" : "false");
> > + intel_dp->force_dsc_en = dsc_enable;
> > +
> > + *offp += len;
> > + return len;
> > +}
> > +
> > +static int i915_dsc_support_open(struct inode *inode,
> > +struct file *file)
> > +{
> > + return single_open(file, i915_dsc_support_show,
> > + inode->i_private);
> > +}
> > +
> > +static const struct file_operations i915_dsc_support_fops = {
> > + .owner = THIS_MODULE,
> > + .open = i915_dsc_support_open,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = single_release,
> > + .write = i915_dsc_support_write
> > +};
> > +
> > /**
> > * i915_debugfs_connector_add - add i915 specific connector debugfs files
> > * @connector: pointer to a registered drm_connector
> > @@ -5017,9 +5083,12 @@ int i915_debugfs_connector_add(struct drm_connector
> > *connector)
> > return -ENODEV;
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> > - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> > + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > debugfs_create_file("i915_dpcd", S_IRUGO, root,
> > connector, _dpcd_fops);
> > + debugfs_create_file("i915_dsc_support", S_IRUGO, root,
> > + connector, _dsc_support_fops);
> > + }
> >
> > if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> > debugfs_create_file("i915_panel_timings", S_IRUGO, root,
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 72e6605f0ed7..0b5939992c2b 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++
[Bug 201201] [amdgpu] Can't raise power limit on Vega
https://bugzilla.kernel.org/show_bug.cgi?id=201201 Aleksandr Mezin (mezin.alexan...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX -- 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 201201] [amdgpu] Can't raise power limit on Vega
https://bugzilla.kernel.org/show_bug.cgi?id=201201 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- fixed: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.20=f7becf9a0803030ae125189823328e2d62b90f7b -- 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 108493] Unigine Heaven at 4K crashes amdgpu and causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=108493 --- Comment #14 from Alex Deucher --- I suspect the display may require additional voltage in your case which is why you see the issue at 4k. The display requirements are not handled as finely on Linux as they are in windows. -- 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 v4] drm/bochs: add edid support.
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 2 ++
drivers/gpu/drm/bochs/bochs_hw.c | 30 ++
drivers/gpu/drm/bochs/bochs_kms.c | 20 +---
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index e7a69077e4..577a8b917c 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -66,6 +66,7 @@ struct bochs_device {
u16 yres_virtual;
u32 stride;
u32 bpp;
+ struct edid *edid;
/* drm */
struct drm_device *dev;
@@ -126,6 +127,7 @@ void bochs_hw_setmode(struct bochs_device *bochs,
const struct drm_format_info *format);
void bochs_hw_setbase(struct bochs_device *bochs,
int x, int y, u64 addr);
+int bochs_hw_load_edid(struct bochs_device *bochs);
/* bochs_mm.c */
int bochs_mm_init(struct bochs_device *bochs);
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index cacff73a64..c90a0d492f 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -69,6 +69,35 @@ static void bochs_hw_set_little_endian(struct bochs_device
*bochs)
#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
#endif
+static int bochs_get_edid_block(void *data, u8 *buf,
+ unsigned int block, size_t len)
+{
+ struct bochs_device *bochs = data;
+ size_t i, start = block * EDID_LENGTH;
+
+ if (start + len > 0x400 /* vga register offset */)
+ return -1;
+
+ for (i = 0; i < len; i++) {
+ buf[i] = readb(bochs->mmio + start + i);
+ }
+ return 0;
+}
+
+int bochs_hw_load_edid(struct bochs_device *bochs)
+{
+ if (!bochs->mmio)
+ return -1;
+
+ kfree(bochs->edid);
+ bochs->edid = drm_do_get_edid(>connector,
+ bochs_get_edid_block, bochs);
+ if (bochs->edid == NULL)
+ return -1;
+
+ return 0;
+}
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
@@ -164,6 +193,7 @@ void bochs_hw_fini(struct drm_device *dev)
if (bochs->fb_map)
iounmap(bochs->fb_map);
pci_release_regions(dev->pdev);
+ kfree(bochs->edid);
}
void bochs_hw_setmode(struct bochs_device *bochs,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 9bc5b438ae..f87c284dd9 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
static int bochs_connector_get_modes(struct drm_connector *connector)
{
- int count;
+ struct bochs_device *bochs =
+ container_of(connector, struct bochs_device, connector);
+ int count = 0;
- count = drm_add_modes_noedid(connector, 8192, 8192);
- drm_set_preferred_mode(connector, defx, defy);
+ if (bochs->edid)
+ count = drm_add_edid_modes(connector, bochs->edid);
+
+ if (!count) {
+ count = drm_add_modes_noedid(connector, 8192, 8192);
+ drm_set_preferred_mode(connector, defx, defy);
+ }
return count;
}
@@ -271,6 +278,13 @@ static void bochs_connector_init(struct drm_device *dev)
drm_connector_helper_add(connector,
_connector_connector_helper_funcs);
drm_connector_register(connector);
+
+ bochs_hw_load_edid(bochs);
+ if (bochs->edid) {
+ DRM_INFO("Found EDID data blob.\n");
+ drm_connector_attach_edid_property(connector);
+ drm_connector_update_edid_property(connector, bochs->edid);
+ }
}
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107334] Artifacts in Unigine Valley with RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=107334 Christian Widmer changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #10 from Christian Widmer --- The issue still has not reappeared and nobody else seems to have this problem so I am going to close this as resolved. -- 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 108260] [Regression?] [powerplay] Failed to retrieve minimum clocks. 4.19-rc6+
https://bugs.freedesktop.org/show_bug.cgi?id=108260 taij...@posteo.de changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from taij...@posteo.de --- OK, the error messages seem to be gone on the latest Linux-mainline compiled from Linus' git. -- 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 108493] Unigine Heaven at 4K crashes amdgpu and causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=108493 --- Comment #13 from Alex Deucher --- (In reply to Timur Kristóf from comment #9) > OD_MCLK: > 0:300MHz750mV > 1: 1000MHz800mV > 2: 1750MHz900mV This is vddc. > [DEFAULT] ATOM_MCLK_ENTRY Array > > > Entry: 0 > Frequency: 300 MHz. > Voltage:. 1000 MV > Entry: 1 > Frequency: 1000 MHz. > Voltage:. 1000 MV > Entry: 2 > Frequency: 1750 MHz. > Voltage:. 1000 MV > This is mvdd. these are not the same voltages. The pp_od_clk_voltage interface only allows you to adjust vddc. The vddc values match what is in the vbios for your card. -- 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 27/28] drm/i915/dsc: Add Per connector debugfs node for DSC support/enable
On Wed, Oct 24, 2018 at 03:28:39PM -0700, Manasi Navare wrote:
> DSC can be supported per DP connector. This patch adds a per connector
> debugfs node to expose DSC support capability by the kernel.
> The same node can be used from userspace to force DSC enable.
Why is the force_dsc thing split between two patches so strangely?
>
> v2:
> * Use kstrtobool_from_user to avoid explicit error checking (Lyude)
> * Rebase on drm-tip (Manasi)
>
> Cc: Rodrigo Vivi
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Lyude Paul
> Signed-off-by: Manasi Navare
> Reviewed-by: Lyude Paul
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 71 -
> drivers/gpu/drm/i915/intel_dp.c | 1 +
> drivers/gpu/drm/i915/intel_drv.h| 3 ++
> 3 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5cadfcd03ea9..6e631f08dd4b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4999,6 +4999,72 @@ static int i915_hdcp_sink_capability_show(struct
> seq_file *m, void *data)
> }
> DEFINE_SHOW_ATTRIBUTE(i915_hdcp_sink_capability);
>
> +static int i915_dsc_support_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct intel_encoder *encoder = intel_attached_encoder(connector);
> + struct intel_dp *intel_dp =
> + enc_to_intel_dp(>base);
> + struct intel_crtc *crtc;
> + struct intel_crtc_state *crtc_state;
> +
> + crtc = to_intel_crtc(encoder->base.crtc);
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> + drm_modeset_lock(>base.mutex, NULL);
> + seq_printf(m, "Enabled: %s\n",
> +yesno(crtc_state->dsc_params.compression_enable));
> + seq_printf(m, "Supported: %s\n",
> +yesno(drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)));
> + drm_modeset_unlock(>base.mutex);
> +
> + return 0;
> +}
> +
> +static ssize_t i915_dsc_support_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + bool dsc_enable = false;
> + int ret;
> + struct drm_connector *connector =
> + ((struct seq_file *)file->private_data)->private;
> + struct intel_encoder *encoder = intel_attached_encoder(connector);
> + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> +
> + if (len == 0)
> + return 0;
> +
> + DRM_DEBUG_DRIVER("Copied %d bytes from user to force DSC\n",
> + (unsigned int)len);
> +
> + ret = kstrtobool_from_user(ubuf, len, _enable);
> + if (ret < 0)
> + return ret;
> +
> + DRM_DEBUG_DRIVER("Got %s for DSC Enable\n",
> + (dsc_enable) ? "true" : "false");
> + intel_dp->force_dsc_en = dsc_enable;
> +
> + *offp += len;
> + return len;
> +}
> +
> +static int i915_dsc_support_open(struct inode *inode,
> + struct file *file)
> +{
> + return single_open(file, i915_dsc_support_show,
> +inode->i_private);
> +}
> +
> +static const struct file_operations i915_dsc_support_fops = {
> + .owner = THIS_MODULE,
> + .open = i915_dsc_support_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = i915_dsc_support_write
> +};
> +
> /**
> * i915_debugfs_connector_add - add i915 specific connector debugfs files
> * @connector: pointer to a registered drm_connector
> @@ -5017,9 +5083,12 @@ int i915_debugfs_connector_add(struct drm_connector
> *connector)
> return -ENODEV;
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> - connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> + connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> debugfs_create_file("i915_dpcd", S_IRUGO, root,
> connector, _dpcd_fops);
> + debugfs_create_file("i915_dsc_support", S_IRUGO, root,
> + connector, _dsc_support_fops);
> + }
>
> if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
> debugfs_create_file("i915_panel_timings", S_IRUGO, root,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 72e6605f0ed7..0b5939992c2b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2287,6 +2287,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
> return false;
>
> + DRM_DEBUG_KMS("Force DSC en = %d\n", intel_dp->force_dsc_en);
> if (!intel_dp_compute_link_config(encoder, pipe_config))
> return false;
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>
Re: [Intel-gfx] [PATCH v6 13/28] drm/i915/dp: Compute DSC pipe config in atomic check
On Mon, Oct 29, 2018 at 10:30:39PM +0200, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:25PM -0700, Manasi Navare wrote:
> > DSC params like the enable, compressed bpp, slice count and
> > dsc_split are added to the intel_crtc_state. These parameters
> > are set based on the requested mode and available link parameters
> > during the pipe configuration in atomic check phase.
> > These values are then later used to populate the remaining DSC
> > and RC parameters before enbaling DSC in atomic commit.
> >
> > v9:
> > * Rebase on top of drm-tip that now uses fast_narrow config
> > for edp (Manasi)
> > v8:
> > * Check for DSC bpc not 0 (manasi)
> >
> > v7:
> > * Fix indentation in compute_m_n (Manasi)
> >
> > v6 (From Gaurav):
> > * Remove function call of intel_dp_compute_dsc_params() and
> > invoke intel_dp_compute_dsc_params() in the patch where
> > it is defined to fix compilation warning (Gaurav)
> >
> > v5:
> > Add drm_dsc_cfg in intel_crtc_state (Manasi)
> >
> > v4:
> > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
> >
> > v3:
> > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
> >
> > v2:
> > * Add if-else for eDP/DP (Gaurav)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Cc: Gaurav K Singh
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > Acked-by: Jani Nikula
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 20 +++-
> > drivers/gpu/drm/i915/intel_display.h | 3 +-
> > drivers/gpu/drm/i915/intel_dp.c | 170 ++-
> > drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> > 4 files changed, 155 insertions(+), 40 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index fe045abb6472..18737bd82b68 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6434,7 +6434,7 @@ static int ironlake_fdi_compute_config(struct
> > intel_crtc *intel_crtc,
> >
> > pipe_config->fdi_lanes = lane;
> >
> > - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> > + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> >link_bw, _config->fdi_m_n, false);
> >
> > ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> > @@ -6671,17 +6671,25 @@ static void compute_m_n(unsigned int m, unsigned
> > int n,
> > }
> >
> > void
> > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> > + int nlanes,
> >int pixel_clock, int link_clock,
> >struct intel_link_m_n *m_n,
> >bool constant_n)
> > {
> > m_n->tu = 64;
> >
> > - compute_m_n(bits_per_pixel * pixel_clock,
> > - link_clock * nlanes * 8,
> > - _n->gmch_m, _n->gmch_n,
> > - constant_n);
> > + /* For DSC, Data M/N calculation uses compressed BPP */
> > + if (compressed_bpp)
> > + compute_m_n(compressed_bpp * pixel_clock,
> > + link_clock * nlanes * 8,
> > + _n->gmch_m, _n->gmch_n,
> > + constant_n);
> > + else
> > + compute_m_n(bits_per_pixel * pixel_clock,
> > + link_clock * nlanes * 8,
> > + _n->gmch_m, _n->gmch_n,
> > + constant_n);
> >
> > compute_m_n(pixel_clock, link_clock,
> > _n->link_m, _n->link_n,
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 5d50decbcbb5..b0b23e1e9392 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -407,7 +407,8 @@ struct intel_link_m_n {
> > (__i)++) \
> > for_each_if(plane)
> >
> > -void intel_link_compute_m_n(int bpp, int nlanes,
> > +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> > + int nlanes,
> > int pixel_clock, int link_clock,
> > struct intel_link_m_n *m_n,
> > bool constant_n);
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 6f66a38ba0b2..a88f9371dd32 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -47,6 +47,8 @@
> >
> > /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> > #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> > +#define DP_DSC_MIN_SUPPORTED_BPC 8
> > +#define DP_DSC_MAX_SUPPORTED_BPC 10
> >
> > /* DP DSC throughput values used for slice count calculations KPixels/s */
> > #define DP_DSC_PEAK_PIXEL_RATE 272
> > @@ -1924,6
Re: [PATCH v6 13/28] drm/i915/dp: Compute DSC pipe config in atomic check
On Wed, Oct 24, 2018 at 03:28:25PM -0700, Manasi Navare wrote:
> DSC params like the enable, compressed bpp, slice count and
> dsc_split are added to the intel_crtc_state. These parameters
> are set based on the requested mode and available link parameters
> during the pipe configuration in atomic check phase.
> These values are then later used to populate the remaining DSC
> and RC parameters before enbaling DSC in atomic commit.
>
> v9:
> * Rebase on top of drm-tip that now uses fast_narrow config
> for edp (Manasi)
> v8:
> * Check for DSC bpc not 0 (manasi)
>
> v7:
> * Fix indentation in compute_m_n (Manasi)
>
> v6 (From Gaurav):
> * Remove function call of intel_dp_compute_dsc_params() and
> invoke intel_dp_compute_dsc_params() in the patch where
> it is defined to fix compilation warning (Gaurav)
>
> v5:
> Add drm_dsc_cfg in intel_crtc_state (Manasi)
>
> v4:
> * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> * Add a comment why we need to check PSR while enabling DSC (Gaurav)
>
> v3:
> * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
>
> v2:
> * Add if-else for eDP/DP (Gaurav)
>
> Cc: Jani Nikula
> Cc: Ville Syrjala
> Cc: Anusha Srivatsa
> Cc: Gaurav K Singh
> Signed-off-by: Manasi Navare
> Reviewed-by: Anusha Srivatsa
> Acked-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 +++-
> drivers/gpu/drm/i915/intel_display.h | 3 +-
> drivers/gpu/drm/i915/intel_dp.c | 170 ++-
> drivers/gpu/drm/i915/intel_dp_mst.c | 2 +-
> 4 files changed, 155 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index fe045abb6472..18737bd82b68 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6434,7 +6434,7 @@ static int ironlake_fdi_compute_config(struct
> intel_crtc *intel_crtc,
>
> pipe_config->fdi_lanes = lane;
>
> - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> link_bw, _config->fdi_m_n, false);
>
> ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> @@ -6671,17 +6671,25 @@ static void compute_m_n(unsigned int m, unsigned int
> n,
> }
>
> void
> -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> +int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> bool constant_n)
> {
> m_n->tu = 64;
>
> - compute_m_n(bits_per_pixel * pixel_clock,
> - link_clock * nlanes * 8,
> - _n->gmch_m, _n->gmch_n,
> - constant_n);
> + /* For DSC, Data M/N calculation uses compressed BPP */
> + if (compressed_bpp)
> + compute_m_n(compressed_bpp * pixel_clock,
> + link_clock * nlanes * 8,
> + _n->gmch_m, _n->gmch_n,
> + constant_n);
> + else
> + compute_m_n(bits_per_pixel * pixel_clock,
> + link_clock * nlanes * 8,
> + _n->gmch_m, _n->gmch_n,
> + constant_n);
>
> compute_m_n(pixel_clock, link_clock,
> _n->link_m, _n->link_n,
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 5d50decbcbb5..b0b23e1e9392 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -407,7 +407,8 @@ struct intel_link_m_n {
>(__i)++) \
> for_each_if(plane)
>
> -void intel_link_compute_m_n(int bpp, int nlanes,
> +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> + int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
> bool constant_n);
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 6f66a38ba0b2..a88f9371dd32 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -47,6 +47,8 @@
>
> /* DP DSC small joiner has 2 FIFOs each of 640 x 6 bytes */
> #define DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER 61440
> +#define DP_DSC_MIN_SUPPORTED_BPC 8
> +#define DP_DSC_MAX_SUPPORTED_BPC 10
>
> /* DP DSC throughput values used for slice count calculations KPixels/s */
> #define DP_DSC_PEAK_PIXEL_RATE 272
> @@ -1924,6 +1926,16 @@ static int intel_dp_compute_bpp(struct intel_dp
> *intel_dp,
> }
> }
>
> + /* If DSC is supported, use the max value reported by panel */
> + if (INTEL_GEN(dev_priv) >= 10 &&
> +
Re: [PATCH v3] drm/bochs: add edid support.
On Mon, Oct 29, 2018 at 07:44:28PM +0200, Jani Nikula wrote: > On Mon, 29 Oct 2018, Gerd Hoffmann wrote: > > Recent qemu (latest master branch, upcoming 3.1 release) got support > > for EDID data. This patch adds guest driver support. > > > > EDID support in qemu is not (yet) enabled by default, so please use > > 'qemu -device VGA,edid=on' for testing. > > Any chance of making this use drm_get_edid() (requires an i2c_adapter) > or at least drm_do_get_edid()? I'll have a look at using drm_do_get_edid(). drm_get_edid() will not fly as there is no i2c adapter in the first place. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
virtio-gpu without ARCH_HAS_SG_CHAIN
Hi, I was looking at adding virtio-gpu support to tinyemu (https://bellard.org/tinyemu/). I got it to work on x86, but just for fun I tried it under riscv and ran into an issue with buffer allocations (though, this should affect any arch without ARCH_HAS_SG_CHAIN). virtio-gpu uses ttm to allocate buffers, which swaps pages to ensure that they aren't consecutive[0][1]. However, this causes sg_alloc_table_from_pages to use a sg entry for every single page, limiting buffers to only 170 pages (the number of sg entries that can fit into a page). This is only 417x417 with 32bpp. I believe the page swapping also makes TRANSFER_TO_HOST_2D inefficient by forcing the host to do many memcpys instead of just a few. Commenting out the swaps in [0] and [1] makes it work with larger buffers. I don't know anything about huge pages, or how sg chaining works, so I have a few questions: - Is virtio-gpu intended to be usable without ARCH_HAS_SG_CHAIN? - Is it still necessary to swap the pages when CONFIG_TRANSPARENT_HUGEPAGE is disabled? - Should riscv support ARCH_HAS_SG_CHAIN? Thanks for any help! [0] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ttm/ttm_page_alloc.c?id=fdb1a2236b07948e83e0a777e1795d4f07e52c33 [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/gpu/drm/ttm/ttm_page_alloc.c?id=ae937fe19636067ec5e20d7f1fa10c6cc6000b52 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm/i915: Eliminate the horrendous format check code
On Mon, 2018-10-29 at 20:34 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the messy framebuffer format/modifier validation code
> with a single call to drm_any_plane_has_format(). The code was
> extremely annoying to maintain as you had to have a lot of platform
> checks for different formats. The new code requires zero maintenance.
>
> v2: Nuke the modifier checks as well since the core does that too now
> v3: Call drm_any_plane_has_format() from the driver code
> v4: Rebase
>
> Cc: Dhinakaran Pandiyan
Reviewed-by: Dhinakaran Pandiyan
-DK
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 105 ++---
> --
> 1 file changed, 8 insertions(+), 97 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9b549d3dd055..de38d5545f3b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14368,7 +14368,6 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> {
> struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> struct drm_framebuffer *fb = _fb->base;
> - struct drm_format_name_buf format_name;
> u32 pitch_limit;
> unsigned int tiling, stride;
> int ret = -EINVAL;
> @@ -14399,39 +14398,14 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> }
> }
>
> - /* Passed in modifier sanity checking. */
> - switch (mode_cmd->modifier[0]) {
> - case I915_FORMAT_MOD_Y_TILED_CCS:
> - case I915_FORMAT_MOD_Yf_TILED_CCS:
> - switch (mode_cmd->pixel_format) {
> - case DRM_FORMAT_XBGR:
> - case DRM_FORMAT_ABGR:
> - case DRM_FORMAT_XRGB:
> - case DRM_FORMAT_ARGB:
> - break;
> - default:
> - DRM_DEBUG_KMS("RC supported only with RGB
> formats\n");
> - goto err;
> - }
> - /* fall through */
> - case I915_FORMAT_MOD_Yf_TILED:
> - if (mode_cmd->pixel_format == DRM_FORMAT_C8) {
> - DRM_DEBUG_KMS("Indexed format does not support
> Yf tiling\n");
> - goto err;
> - }
> - /* fall through */
> - case I915_FORMAT_MOD_Y_TILED:
> - if (INTEL_GEN(dev_priv) < 9) {
> - DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
> - mode_cmd->modifier[0]);
> - goto err;
> - }
> - break;
> - case DRM_FORMAT_MOD_LINEAR:
> - case I915_FORMAT_MOD_X_TILED:
> - break;
> - default:
> - DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
> + if (!drm_any_plane_has_format(_priv->drm,
> + mode_cmd->pixel_format,
> + mode_cmd->modifier[0])) {
> + struct drm_format_name_buf format_name;
> +
> + DRM_DEBUG_KMS("unsupported pixel format %s / modifier
> 0x%llx\n",
> + drm_get_format_name(mode_cmd-
> >pixel_format,
> + _name),
> mode_cmd->modifier[0]);
> goto err;
> }
> @@ -14466,69 +14440,6 @@ static int intel_framebuffer_init(struct
> intel_framebuffer *intel_fb,
> goto err;
> }
>
> - /* Reject formats not supported by any plane early. */
> - switch (mode_cmd->pixel_format) {
> - case DRM_FORMAT_C8:
> - case DRM_FORMAT_RGB565:
> - case DRM_FORMAT_XRGB:
> - case DRM_FORMAT_ARGB:
> - break;
> - case DRM_FORMAT_XRGB1555:
> - if (INTEL_GEN(dev_priv) > 3) {
> - DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd-
> >pixel_format, _name));
> - goto err;
> - }
> - break;
> - case DRM_FORMAT_ABGR:
> - if (!IS_VALLEYVIEW(dev_priv) &&
> !IS_CHERRYVIEW(dev_priv) &&
> - INTEL_GEN(dev_priv) < 9) {
> - DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd-
> >pixel_format, _name));
> - goto err;
> - }
> - break;
> - case DRM_FORMAT_XBGR:
> - case DRM_FORMAT_XRGB2101010:
> - case DRM_FORMAT_XBGR2101010:
> - if (INTEL_GEN(dev_priv) < 4) {
> - DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd-
> >pixel_format, _name));
> - goto err;
> - }
> - break;
> - case DRM_FORMAT_ABGR2101010:
> - if (!IS_VALLEYVIEW(dev_priv) &&
> !IS_CHERRYVIEW(dev_priv)) {
>
Re: [PATCH v6 21/28] drm/i915/dp: Use the existing write_infoframe() for DSC PPS SDPs
On Thu, Oct 25, 2018 at 05:08:39PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 24, 2018 at 03:28:33PM -0700, Manasi Navare wrote:
> > Infoframes are used to send secondary data packets. This patch
> > adds support for DSC Picture parameter set secondary data packets
> > in the existing write_infoframe helpers.
> >
> > v2:
> > * Rebase on drm-tip (Manasi)
> >
> > Cc: Jani Nikula
> > Cc: Ville Syrjala
> > Cc: Anusha Srivatsa
> > Signed-off-by: Manasi Navare
> > Reviewed-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_hdmi.c | 23 +--
> > 2 files changed, 22 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 64cca0a83cf7..0ecdc95f56d8 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4545,6 +4545,7 @@ enum {
> > * of the infoframe structure specified by CEA-861. */
> > #define VIDEO_DIP_DATA_SIZE 32
> > #define VIDEO_DIP_VSC_DATA_SIZE 36
> > +#define VIDEO_DIP_PPS_DATA_SIZE 132
> > #define VIDEO_DIP_CTL _MMIO(0x61170)
> > /* Pre HSW: */
> > #define VIDEO_DIP_ENABLE (1 << 31)
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index d3e653640ce7..02fb54737d92 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -115,6 +115,8 @@ static u32 hsw_infoframe_enable(unsigned int type)
> > switch (type) {
> > case DP_SDP_VSC:
> > return VIDEO_DIP_ENABLE_VSC_HSW;
> > + case DP_SDP_PPS:
> > + return VDIP_ENABLE_PPS;
>
> Hmm. Why is that bit named so differently to the rest?
Will have to address the mess around VDIP_CVTL reg earlier defs in a separate
patch set
>
> > case HDMI_INFOFRAME_TYPE_AVI:
> > return VIDEO_DIP_ENABLE_AVI_HSW;
> > case HDMI_INFOFRAME_TYPE_SPD:
> > @@ -136,6 +138,8 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> > switch (type) {
> > case DP_SDP_VSC:
> > return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
> > + case DP_SDP_PPS:
> > + return ICL_VIDEO_DIP_PPS_DATA(cpu_transcoder, i);
> > case HDMI_INFOFRAME_TYPE_AVI:
> > return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
> > case HDMI_INFOFRAME_TYPE_SPD:
> > @@ -148,6 +152,18 @@ hsw_dip_data_reg(struct drm_i915_private *dev_priv,
> > }
> > }
> >
> > +static int hsw_dip_data_size(unsigned int type)
> > +{
> > + switch (type) {
> > + case DP_SDP_VSC:
> > + return VIDEO_DIP_VSC_DATA_SIZE;
> > + case DP_SDP_PPS:
> > + return VIDEO_DIP_PPS_DATA_SIZE;
> > + default:
> > + return VIDEO_DIP_DATA_SIZE;
> > + }
> > +}
> > +
> > static void g4x_write_infoframe(struct intel_encoder *encoder,
> > const struct intel_crtc_state *crtc_state,
> > unsigned int type,
> > @@ -382,11 +398,14 @@ static void hsw_write_infoframe(struct intel_encoder
> > *encoder,
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder);
> > - int data_size = type == DP_SDP_VSC ?
> > - VIDEO_DIP_VSC_DATA_SIZE : VIDEO_DIP_DATA_SIZE;
> > + i915_reg_t data_reg;
> > + int data_size = 0;
>
> =0 is unnecessary.
This was added to adderss a warning that data_size is uninitialized.
But will double check again if its really needed.
>
> > int i;
> > u32 val = I915_READ(ctl_reg);
> >
> > + data_size = hsw_dip_data_size(type);
> > + data_reg = hsw_dip_data_reg(dev_priv, cpu_transcoder, type, 0);
>
> data_reg is unused.
Yes I think the cleanup patch series that was sent sometime recently now
uses hsw_dip_data_reg directly in I915_WRITE call.
I will remove the data_reg.
Manasi
>
> > +
> > val &= ~hsw_infoframe_enable(type);
> > I915_WRITE(ctl_reg, val);
> >
> > --
> > 2.18.0
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/9] drm/tilcdc: Use drm_fbdev_generic_setup()
On 25/10/18 23:13, Noralf Trønnes wrote:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
>
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Signed-off-by: Noralf Trønnes
> Acked-by: Sam Ravnborg
Thanks!
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 33e533268488..3dac08b24140 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -140,7 +140,6 @@ static int tilcdc_commit(struct drm_device *dev,
>
> static const struct drm_mode_config_funcs mode_config_funcs = {
> .fb_create = tilcdc_fb_create,
> - .output_poll_changed = drm_fb_helper_output_poll_changed,
> .atomic_check = tilcdc_atomic_check,
> .atomic_commit = tilcdc_commit,
> };
> @@ -191,9 +190,6 @@ static void tilcdc_fini(struct drm_device *dev)
> drm_dev_unregister(dev);
>
> drm_kms_helper_poll_fini(dev);
> -
> - drm_fb_cma_fbdev_fini(dev);
> -
> drm_irq_uninstall(dev);
> drm_mode_config_cleanup(dev);
> tilcdc_remove_external_device(dev);
> @@ -396,16 +392,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct
> device *dev)
>
> drm_mode_config_reset(ddev);
>
> - ret = drm_fb_cma_fbdev_init(ddev, bpp, 0);
> - if (ret)
> - goto init_failed;
> -
> drm_kms_helper_poll_init(ddev);
>
> ret = drm_dev_register(ddev, 0);
> if (ret)
> goto init_failed;
>
> + drm_fbdev_generic_setup(ddev, bpp);
> +
> priv->is_registered = true;
> return 0;
>
> @@ -519,7 +513,6 @@ DEFINE_DRM_GEM_CMA_FOPS(fops);
> static struct drm_driver tilcdc_driver = {
> .driver_features= (DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET |
> DRIVER_PRIME | DRIVER_ATOMIC),
> - .lastclose = drm_fb_helper_lastclose,
> .irq_handler= tilcdc_irq,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_print_info = drm_gem_cma_print_info,
>
--
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 v4 3/4] drm: Document variable refresh properties
On 10/29/18 2:03 PM, Ville Syrjälä wrote: > On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: >> On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: >>> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: On 10/26/18 10:53 AM, Ville Syrjälä wrote: > > Speaking of timestamps. What is the expected behaviour of vblank > timestamps when vrr is enabled? When vrr is enabled the duration of the vertical front porch will be extended until flip or timeout occurs. The vblank timestamp will vary based on duration of the vertical front porch. The min/max duration for the front porch can be specified by the driver via the min/max range. No changes to vblank timestamping handling should be necessary to accommodate variable refresh rate. >>> >>> The problem is that the timestamp is supposed to correspond to the first >>> active pixel. And since we don't know how long the front porch will be >>> we can't realistically report the true value. So I guess just assuming >>> min front porch length is as good as anything else? >> >> That (and documenting that the timestamp corresponds to the earliest >> possible first active pixel, not necessarily the actual one, with VRR) >> might be good enough for the actual vblank event timestamps. >> >> >> However, I'm not so sure about the timestamps of page flip completion >> events. Those could be very misleading if the flip completes towards the >> timeout, which could result in bad behaviour of applications which use >> them for animation timing. >> >> Maybe the timestamp could be updated appropriately (yes, I'm hand-waving >> :) in drm_crtc_send_vblank_event? > > Hmm. Updated how? Whether it's a page flip event or vblank even we won't > know when the first active pixel will come. Although I suppose if > there is some kind of vrr slew rate limit we could at least account > for that to report a more correct "this is the earliest you migth be > able to see your frame" timestamp. > > Oh, or are you actually saying that shceduling a new flip before the > timeout is actually going to latch that flip immediately? I figured > that the flip would get latched on the next start of vblank regardless, > and the act of scheduling a flip will just kick the hardware to start > scanning the previously latched frame earlier. > > scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank >^^^ ^ >||flip C latch C >flip B latch B > > vs. > > scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank >^ ^ ^ ^ >| latch B| latch C >flip B flip C > > The latter would seem more like a tearing flip without the tearing. > I'm not sure any of this is necessary. The vblank timestamp is determined (at least if you're using the helpers) by using the scanout position. The crtc_vtotal won't change when variable refresh rate is enabled. What does change is the behavior of the scanout position. The vpos will continue going will beyond the end of crtc_vtotal up until whatever the vtotal would be for the minimum refresh rate. There's no clamping performed for these calculations so it ends up working as expected. Nicholas Kazlauskas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107518] polaris powerplay init fails: There must be 1 or more PCIE levels defined in PPTable
https://bugs.freedesktop.org/show_bug.cgi?id=107518 --- Comment #14 from Alex Deucher --- https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11a88c2e92feca1ed3fba19fa375f76d3c75f5d5 -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #35 from Alex Deucher --- (In reply to bmilreu from comment #34) > The flickering issues I have with 75hz are gone after forcing profile to > high. The disables mclk switching by forcing the clocks to high. What modes and refresh rates exhibit the problem? -- 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 v4 2/2] drm/i915: Eliminate the horrendous format check code
From: Ville Syrjälä
Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.
v2: Nuke the modifier checks as well since the core does that too now
v3: Call drm_any_plane_has_format() from the driver code
v4: Rebase
Cc: Dhinakaran Pandiyan
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 105 ++-
1 file changed, 8 insertions(+), 97 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9b549d3dd055..de38d5545f3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14368,7 +14368,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = _fb->base;
- struct drm_format_name_buf format_name;
u32 pitch_limit;
unsigned int tiling, stride;
int ret = -EINVAL;
@@ -14399,39 +14398,14 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
}
}
- /* Passed in modifier sanity checking. */
- switch (mode_cmd->modifier[0]) {
- case I915_FORMAT_MOD_Y_TILED_CCS:
- case I915_FORMAT_MOD_Yf_TILED_CCS:
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_ABGR:
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- default:
- DRM_DEBUG_KMS("RC supported only with RGB
formats\n");
- goto err;
- }
- /* fall through */
- case I915_FORMAT_MOD_Yf_TILED:
- if (mode_cmd->pixel_format == DRM_FORMAT_C8) {
- DRM_DEBUG_KMS("Indexed format does not support Yf
tiling\n");
- goto err;
- }
- /* fall through */
- case I915_FORMAT_MOD_Y_TILED:
- if (INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG_KMS("Unsupported tiling 0x%llx!\n",
- mode_cmd->modifier[0]);
- goto err;
- }
- break;
- case DRM_FORMAT_MOD_LINEAR:
- case I915_FORMAT_MOD_X_TILED:
- break;
- default:
- DRM_DEBUG_KMS("Unsupported fb modifier 0x%llx!\n",
+ if (!drm_any_plane_has_format(_priv->drm,
+ mode_cmd->pixel_format,
+ mode_cmd->modifier[0])) {
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("unsupported pixel format %s / modifier 0x%llx\n",
+ drm_get_format_name(mode_cmd->pixel_format,
+ _name),
mode_cmd->modifier[0]);
goto err;
}
@@ -14466,69 +14440,6 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
- /* Reject formats not supported by any plane early. */
- switch (mode_cmd->pixel_format) {
- case DRM_FORMAT_C8:
- case DRM_FORMAT_RGB565:
- case DRM_FORMAT_XRGB:
- case DRM_FORMAT_ARGB:
- break;
- case DRM_FORMAT_XRGB1555:
- if (INTEL_GEN(dev_priv) > 3) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, _name));
- goto err;
- }
- break;
- case DRM_FORMAT_ABGR:
- if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
- INTEL_GEN(dev_priv) < 9) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, _name));
- goto err;
- }
- break;
- case DRM_FORMAT_XBGR:
- case DRM_FORMAT_XRGB2101010:
- case DRM_FORMAT_XBGR2101010:
- if (INTEL_GEN(dev_priv) < 4) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, _name));
- goto err;
- }
- break;
- case DRM_FORMAT_ABGR2101010:
- if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
- DRM_DEBUG_KMS("unsupported pixel format: %s\n",
-
drm_get_format_name(mode_cmd->pixel_format, _name));
-
[PATCH v4 1/2] drm: Add drm_any_plane_has_format()
From: Ville Syrjälä
Add a function to check whether there is at least one plane that
supports a specific format and modifier combination. Drivers can
use this to reject unsupported formats/modifiers in .fb_create().
v2: Accept anyformat if the driver doesn't do planes (Eric)
s/planes_have_format/any_plane_has_format/ (Eric)
Check the modifier as well since we already have a function
that does both
v3: Don't do the check in the core since we may not know the
modifier yet, instead export the function and let drivers
call it themselves
Cc: Eric Anholt
Cc: Dhinakaran Pandiyan
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_plane.c | 23 +++
include/drm/drm_mode_config.h | 6 ++
include/drm/drm_plane.h | 2 ++
3 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 1fa98bd12003..679455e36829 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -636,6 +636,29 @@ static int __setplane_check(struct drm_plane *plane,
return 0;
}
+/**
+ * drm_any_plane_has_format - Check whether any plane supports this format and
modifier combination
+ * @dev: DRM device
+ * @format: pixel format (DRM_FORMAT_*)
+ * @modifier: data layout modifier
+ *
+ * Returns:
+ * Whether at least one plane supports the specified format and modifier
combination.
+ */
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier)
+{
+ struct drm_plane *plane;
+
+ drm_for_each_plane(plane, dev) {
+ if (drm_plane_check_pixel_format(plane, format, modifier) == 0)
+ return true;
+ }
+
+ return false;
+}
+EXPORT_SYMBOL(drm_any_plane_has_format);
+
/*
* __setplane_internal - setplane handler for internal callers
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index d643d268693e..5dbeabdbaf91 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -52,6 +52,12 @@ struct drm_mode_config_funcs {
* requested metadata, but most of that is left to the driver. See
* drm_mode_fb_cmd2 for details.
*
+* To validate the pixel format and modifier drivers can use
+* drm_any_plane_has_format() to make sure at least one plane supports
+* the requested values. Note that the driver must first determine the
+* actual modifier used if the request doesn't have it specified,
+* ie. when (@mode_cmd->flags & DRM_MODE_FB_MODIFIERS) == 0.
+*
* If the parameters are deemed valid and the backing storage objects in
* the underlying memory manager all exist, then the driver allocates
* a new _framebuffer structure, subclassed to contain
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 0a0834bef8bd..3701f56c3362 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -798,5 +798,7 @@ static inline struct drm_plane *drm_plane_find(struct
drm_device *dev,
#define drm_for_each_plane(plane, dev) \
list_for_each_entry(plane, &(dev)->mode_config.plane_list, head)
+bool drm_any_plane_has_format(struct drm_device *dev,
+ u32 format, u64 modifier);
#endif
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108507] [rv790] Broken ground textures in World of Tanks
https://bugs.freedesktop.org/show_bug.cgi?id=108507 --- Comment #5 from Vladimir Usikov --- I found environment variable MESA_EXTENSION_OVERRIDE. But i don't understand how it works with comp profile. And cant test. -- 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 v4 3/4] drm: Document variable refresh properties
On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote: > On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: > > On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: > >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: > >>> > >>> Speaking of timestamps. What is the expected behaviour of vblank > >>> timestamps when vrr is enabled? > >> > >> When vrr is enabled the duration of the vertical front porch will be > >> extended until flip or timeout occurs. The vblank timestamp will vary > >> based on duration of the vertical front porch. The min/max duration for > >> the front porch can be specified by the driver via the min/max range. > >> > >> No changes to vblank timestamping handling should be necessary to > >> accommodate variable refresh rate. > > > > The problem is that the timestamp is supposed to correspond to the first > > active pixel. And since we don't know how long the front porch will be > > we can't realistically report the true value. So I guess just assuming > > min front porch length is as good as anything else? > > That (and documenting that the timestamp corresponds to the earliest > possible first active pixel, not necessarily the actual one, with VRR) > might be good enough for the actual vblank event timestamps. > > > However, I'm not so sure about the timestamps of page flip completion > events. Those could be very misleading if the flip completes towards the > timeout, which could result in bad behaviour of applications which use > them for animation timing. > > Maybe the timestamp could be updated appropriately (yes, I'm hand-waving > :) in drm_crtc_send_vblank_event? Hmm. Updated how? Whether it's a page flip event or vblank even we won't know when the first active pixel will come. Although I suppose if there is some kind of vrr slew rate limit we could at least account for that to report a more correct "this is the earliest you migth be able to see your frame" timestamp. Oh, or are you actually saying that shceduling a new flip before the timeout is actually going to latch that flip immediately? I figured that the flip would get latched on the next start of vblank regardless, and the act of scheduling a flip will just kick the hardware to start scanning the previously latched frame earlier. scanout A | ... vblank | scanout A | ... vblank | scanout B | ... vblank ^^^ ^ ||flip C latch C flip B latch B vs. scanout A | ... vblank | scanout B | ... vblank | scanout C | ... vblank ^ ^ ^ ^ | latch B| latch C flip B flip C The latter would seem more like a tearing flip without the tearing. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #34 from bmil...@gmail.com --- Alex this bug looks like the same I reported here https://bugs.freedesktop.org/show_bug.cgi?id=108322 The flickering issues I have with 75hz are gone after forcing profile to high. -- 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] drm/bochs: add edid support.
On Mon, 29 Oct 2018, Gerd Hoffmann wrote:
> Recent qemu (latest master branch, upcoming 3.1 release) got support
> for EDID data. This patch adds guest driver support.
>
> EDID support in qemu is not (yet) enabled by default, so please use
> 'qemu -device VGA,edid=on' for testing.
Any chance of making this use drm_get_edid() (requires an i2c_adapter)
or at least drm_do_get_edid()?
BR,
Jani.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/bochs/bochs.h | 1 +
> drivers/gpu/drm/bochs/bochs_hw.c | 39
> +++
> drivers/gpu/drm/bochs/bochs_kms.c | 18 +++---
> 3 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
> index e7a69077e4..06b8166efa 100644
> --- a/drivers/gpu/drm/bochs/bochs.h
> +++ b/drivers/gpu/drm/bochs/bochs.h
> @@ -66,6 +66,7 @@ struct bochs_device {
> u16 yres_virtual;
> u32 stride;
> u32 bpp;
> + struct edid *edid;
>
> /* drm */
> struct drm_device *dev;
> diff --git a/drivers/gpu/drm/bochs/bochs_hw.c
> b/drivers/gpu/drm/bochs/bochs_hw.c
> index cacff73a64..db4afe94c5 100644
> --- a/drivers/gpu/drm/bochs/bochs_hw.c
> +++ b/drivers/gpu/drm/bochs/bochs_hw.c
> @@ -69,6 +69,41 @@ static void bochs_hw_set_little_endian(struct bochs_device
> *bochs)
> #define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
> #endif
>
> +static int bochs_load_edid(struct bochs_device *bochs)
> +{
> + uint8_t *blob;
> + size_t i, len;
> + uint8_t num_exts;
> +
> + if (!bochs->mmio)
> + return -1;
> +
> + if ((readb(bochs->mmio+0) != 0x00 ||
> + readb(bochs->mmio+1) != 0xff))
> + return -1;
> +
> + num_exts = readb(bochs->mmio + 126);
> + len = EDID_LENGTH * (1 + num_exts);
> + if (len > 0x400 /* vga register offset */)
> + return -1;
> +
> + kfree(bochs->edid);
> + bochs->edid = kmalloc(len, GFP_KERNEL);
> + blob = (void *)bochs->edid;
> + for (i = 0; i < len; i++) {
> + blob[i] = readb(bochs->mmio+i);
> + }
> +
> + if (!drm_edid_is_valid(bochs->edid)) {
> + DRM_ERROR("EDID is not valid, ignoring.\n");
> + kfree(bochs->edid);
> + bochs->edid = NULL;
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> int bochs_hw_init(struct drm_device *dev)
> {
> struct bochs_device *bochs = dev->dev_private;
> @@ -150,6 +185,9 @@ int bochs_hw_init(struct drm_device *dev)
> }
>
> noext:
> + if (bochs_load_edid(bochs) == 0)
> + DRM_INFO("Found EDID data blob.\n");
> +
> return 0;
> }
>
> @@ -164,6 +202,7 @@ void bochs_hw_fini(struct drm_device *dev)
> if (bochs->fb_map)
> iounmap(bochs->fb_map);
> pci_release_regions(dev->pdev);
> + kfree(bochs->edid);
> }
>
> void bochs_hw_setmode(struct bochs_device *bochs,
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 9bc5b438ae..b9931443a7 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
>
> static int bochs_connector_get_modes(struct drm_connector *connector)
> {
> - int count;
> + struct bochs_device *bochs =
> + container_of(connector, struct bochs_device, connector);
> + int count = 0;
>
> - count = drm_add_modes_noedid(connector, 8192, 8192);
> - drm_set_preferred_mode(connector, defx, defy);
> + if (bochs->edid)
> + count = drm_add_edid_modes(connector, bochs->edid);
> +
> + if (!count) {
> + count = drm_add_modes_noedid(connector, 8192, 8192);
> + drm_set_preferred_mode(connector, defx, defy);
> + }
> return count;
> }
>
> @@ -271,6 +278,11 @@ static void bochs_connector_init(struct drm_device *dev)
> drm_connector_helper_add(connector,
>_connector_connector_helper_funcs);
> drm_connector_register(connector);
> +
> + if (bochs->edid) {
> + drm_connector_attach_edid_property(connector);
> + drm_connector_update_edid_property(connector, bochs->edid);
> + }
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/9] drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This had been discussed here.
[1]
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-09-13_html=true
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_framebuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_framebuffer.c
b/drivers/gpu/drm/drm_framebuffer.c
index 6aca8a1ccdb6..167c1c4544af 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -195,8 +195,14 @@ static int framebuffer_check(struct drm_device *dev,
for (i = 0; i < info->num_planes; i++) {
unsigned int width = fb_plane_width(r->width, info, i);
unsigned int height = fb_plane_height(r->height, info, i);
+ unsigned int block_size = info->char_per_block[i];
u64 min_pitch = drm_format_info_min_pitch(info, i, width);
+ if (!block_size && (r->modifier[i] == DRM_FORMAT_MOD_LINEAR)) {
+ DRM_DEBUG_KMS("Format requires non-linear modifier for
plane %d\n", i);
+ return -EINVAL;
+ }
+
if (!r->handles[i]) {
DRM_DEBUG_KMS("no buffer object handle for plane %d\n",
i);
return -EINVAL;
@@ -208,7 +214,7 @@ static int framebuffer_check(struct drm_device *dev,
if ((uint64_t) height * r->pitches[i] + r->offsets[i] >
UINT_MAX)
return -ERANGE;
- if (r->pitches[i] < min_pitch) {
+ if (block_size && r->pitches[i] < min_pitch) {
DRM_DEBUG_KMS("bad pitch %u for plane %d\n",
r->pitches[i], i);
return -EINVAL;
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/9] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by
[PATCH v6 7/9] drm/selftests: Add tests for drm_format_info* helpers
Add selftests for the following newly added functions:
- drm_format_info_block_width
- drm_format_info_block_height
- drm_format_info_min_pitch
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/selftests/Makefile| 3 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm_format.c | 290 ++
.../drm/selftests/test-drm_modeset_common.h | 3 +
4 files changed, 298 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 7e6581921da0..07b4f88b422a 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,3 +1,4 @@
-test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o
+test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
+ test-drm_format.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 9771290ed228..4e203ac8c134 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -7,3 +7,6 @@
* Tests are executed in order by igt/drm_selftests_helper
*/
selftest(check_plane_state, igt_check_plane_state)
+selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
+selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
+selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
diff --git a/drivers/gpu/drm/selftests/test-drm_format.c
b/drivers/gpu/drm/selftests/test-drm_format.c
new file mode 100644
index ..5abfd5e28d7d
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_format.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_format functions
+ */
+
+#define pr_fmt(fmt) "drm_format: " fmt
+
+#include
+#include
+
+#include
+
+#include "test-drm_modeset_common.h"
+
+int igt_check_drm_format_block_width(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_width(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 2) != 1);
+ FAIL_ON(drm_format_info_block_width(info, 3) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ /* Test a tiled format */
+ info = drm_format_info(DRM_FORMAT_X0L0);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_width(info, 0) != 2);
+ FAIL_ON(drm_format_info_block_width(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_width(info, -1) != 0);
+
+ return 0;
+}
+
+int igt_check_drm_format_block_height(void *ignored)
+{
+ const struct drm_format_info *info = NULL;
+
+ /* Test invalid arguments */
+ FAIL_ON(drm_format_info_block_height(info, 0) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+
+ /* Test 1 plane format */
+ info = drm_format_info(DRM_FORMAT_XRGB);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 2 planes format */
+ info = drm_format_info(DRM_FORMAT_NV12);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 1) != 1);
+ FAIL_ON(drm_format_info_block_height(info, 2) != 0);
+ FAIL_ON(drm_format_info_block_height(info, -1) != 0);
+
+ /* Test 3 planes format */
+ info = drm_format_info(DRM_FORMAT_YUV422);
+ FAIL_ON(!info);
+ FAIL_ON(drm_format_info_block_height(info, 0) != 1);
+
[PATCH v6 9/9] drm/selftests: Add tests for drm_internal_framebuffer_create
Add tests that verify that drm_internal_framebuffer_create creates
buffers correctly by creating a dummy drm_device with a mock function
for the fb_create callback.
To decide if a buffer has been created or not it just checks if
fb_create callback has been called for the particular drm_mode_fb_cmd2
that's being tested.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/selftests/Makefile| 2 +-
.../gpu/drm/selftests/drm_modeset_selftests.h | 1 +
.../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++
.../drm/selftests/test-drm_modeset_common.h | 1 +
4 files changed, 347 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 07b4f88b422a..383d8d6c5847 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,4 +1,4 @@
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
- test-drm_format.o
+ test-drm_format.o test-drm_framebuffer.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
index 4e203ac8c134..92601defd8f6 100644
--- a/drivers/gpu/drm/selftests/drm_modeset_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_modeset_selftests.h
@@ -10,3 +10,4 @@ selftest(check_plane_state, igt_check_plane_state)
selftest(check_drm_format_block_width, igt_check_drm_format_block_width)
selftest(check_drm_format_block_height, igt_check_drm_format_block_height)
selftest(check_drm_format_min_pitch, igt_check_drm_format_min_pitch)
+selftest(check_drm_framebuffer_create, igt_check_drm_framebuffer_create)
diff --git a/drivers/gpu/drm/selftests/test-drm_framebuffer.c
b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
new file mode 100644
index ..3098435678af
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_framebuffer.c
@@ -0,0 +1,344 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for the drm_framebuffer functions
+ */
+
+#include
+#include "../drm_crtc_internal.h"
+
+#include "test-drm_modeset_common.h"
+
+#define MIN_WIDTH 4
+#define MAX_WIDTH 4096
+#define MIN_HEIGHT 4
+#define MAX_HEIGHT 4096
+
+struct drm_framebuffer_test {
+ int buffer_created;
+ struct drm_mode_fb_cmd2 cmd;
+ const char *name;
+};
+
+static struct drm_framebuffer_test createbuffer_tests[] = {
+{ .buffer_created = 1, .name = "ABGR normal sizes",
+ .cmd = { .width = 600, .height = 600, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * 600, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR max sizes",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 1, .name = "ABGR pitch greater than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH + 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR pitch less than min required",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH - 1, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid width",
+ .cmd = { .width = MAX_WIDTH + 1, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * (MAX_WIDTH + 1), 0, 0
},
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Invalid buffer handle",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 0, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "No pixel format",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format = 0,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Width 0",
+ .cmd = { .width = 0, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Height 0",
+ .cmd = { .width = MAX_WIDTH, .height = 0, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .pitches = { 4 * MAX_WIDTH, 0, 0 },
+ }
+},
+{ .buffer_created = 0, .name = "ABGR Out of bound height * pitch
combination",
+ .cmd = { .width = MAX_WIDTH, .height = MAX_HEIGHT, .pixel_format =
DRM_FORMAT_ABGR,
+.handles = { 1, 0, 0 }, .offsets = { UINT_MAX - 1,
[PATCH v6 3/9] drm: mali-dp: Enable Mali-DP tiled buffer formats
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 28 +---
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 7aad7dd80d8c..b9bed1138fa3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -77,12 +77,18 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
- { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }
+ { DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
};
+static const struct malidp_format_id malidp650_de_formats[] = {
+ MALIDP_COMMON_FORMATS,
+ { DRM_FORMAT_X0L0, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 4)},
+};
+
static const struct malidp_layer malidp500_layers[] = {
/* id, base address, fb pointer address base, stride offset,
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
@@ -630,6 +636,8 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_BGR565:
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_X0L0:
+ case DRM_FORMAT_X0L2:
bytes_per_col = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
@@ -905,8 +913,8 @@ const struct malidp_hw malidp_device[MALIDP_MAX_DEVICES] = {
MALIDP550_DC_IRQ_SE,
.vsync_irq = MALIDP550_DC_IRQ_CONF_VALID,
},
- .pixel_formats = malidp550_de_formats,
- .n_pixel_formats = ARRAY_SIZE(malidp550_de_formats),
+ .pixel_formats = malidp650_de_formats,
+ .n_pixel_formats = ARRAY_SIZE(malidp650_de_formats),
.bus_align_bytes = 16,
},
.query_hw = malidp650_query_hw,
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 837a24d56675..c9a6d3e0cada 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -398,6 +398,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
struct drm_framebuffer *fb;
u16 pixel_alpha = state->pixel_blend_mode;
int i, ret;
+ unsigned int block_w, block_h;
if (!state->crtc || !state->fb)
return 0;
@@ -413,13 +414,26 @@ static int malidp_de_plane_check(struct drm_plane *plane,
ms->n_planes = fb->format->num_planes;
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if (fb->pitches[i] & (alignment - 1)) {
+
+ if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
}
}
+ block_w = drm_format_info_block_width(fb->format, 0);
+ block_h = drm_format_info_block_height(fb->format, 0);
+ if (fb->width % block_w || fb->height % block_h) {
+ DRM_DEBUG_KMS("Buffer width/height needs to be a multiple of
tile sizes");
+ return -EINVAL;
+ }
+ if ((state->src_x >> 16) % block_w || (state->src_y >> 16) % block_h) {
+ DRM_DEBUG_KMS("Plane src_x/src_y needs to be a multiple of tile
sizes");
+ return -EINVAL;
+ }
+
if ((state->crtc_w > mp->hwdev->max_line_size) ||
(state->crtc_h > mp->hwdev->max_line_size) ||
(state->crtc_w < mp->hwdev->min_line_size) ||
@@ -492,10 +506,18 @@ static void malidp_de_set_plane_pitches(struct
malidp_plane *mp,
num_strides = (mp->hwdev->hw->features &
MALIDP_DEVICE_LV_HAS_3_STRIDES) ? 3 : 2;
- for (i = 0; i < num_strides; ++i)
- malidp_hw_write(mp->hwdev, pitches[i],
+ /*
+* The drm convention for pitch is that it needs to cover width * cpp,
+* but our hardware wants the pitch/stride to cover all rows included
+* in a tile.
+*/
+ for (i = 0; i < num_strides; ++i) {
+ unsigned int
[PATCH v6 2/9] drm/fourcc: Add fourcc for Mali linear tiled formats
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 14 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index a843a5fc8dbf..b2ca0c526c3c 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -228,6 +228,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_P010,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P012,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
{ .format = DRM_FORMAT_P016,.depth = 0,
.num_planes = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L0,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_Y0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
+ { .format = DRM_FORMAT_X0L2,.depth = 0,
.num_planes = 1,
+ .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
.block_h = { 2, 0, 0 },
+ .hsub = 2, .vsub = 2, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 242a1d72a1ce..b82f528202f7 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -152,6 +152,20 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/*
+ * packed YCbCr420 2x2 tiled formats
+ * first 64 bits will contain Y,Cb,Cr components for a 2x2 tile
+ */
+/* [63:0] A3:A2:Y3:0:Cr0:0:Y2:0:A1:A0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_Y0L0fourcc_code('Y', '0', 'L', '0')
+/* [63:0] X3:X2:Y3:0:Cr0:0:Y2:0:X1:X0:Y1:0:Cb0:0:Y0:0
1:1:8:2:8:2:8:2:1:1:8:2:8:2:8:2 little endian */
+#define DRM_FORMAT_X0L0fourcc_code('X', '0', 'L', '0')
+
+/* [63:0] A3:A2:Y3:Cr0:Y2:A1:A0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_Y0L2fourcc_code('Y', '0', 'L', '2')
+/* [63:0] X3:X2:Y3:Cr0:Y2:X1:X0:Y1:Cb0:Y0 1:1:10:10:10:1:1:10:10:10 little
endian */
+#define DRM_FORMAT_X0L2fourcc_code('X', '0', 'L', '2')
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/9] drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per_block[3]
- block_w[3]
- block_h[3]
char_per_block will be put in a union alongside cpp, for transparent
compatibility with the existing format descriptions.
Regarding, block_w and block_h they are intended to be used through
their equivalent getters drm_format_info_block_width /
drm_format_info_block_height, the reason of the getters is to abstract
the fact that for normal formats block_w and block_h will be unset/0,
but the methods will be returning 1.
Additionally, convenience function drm_format_info_min_pitch had been
added that computes the minimum required pitch for a given pixel
format and buffer width.
Using that the following drm core functions had been updated to
generically handle both block and non-block formats:
- drm_fb_cma_get_gem_addr: for block formats it will just return the
beginning of the block.
- framebuffer_check: Use the newly added drm_format_info_min_pitch.
- drm_gem_fb_create_with_funcs: Use the newly added
drm_format_info_min_pitch.
- In places where is not expecting to handle block formats, like fbdev
helpers I just added some warnings in case the block width/height
are greater than 1.
Changes since v3:
- Add helper function for computing the minimum required pitch.
- Improve/cleanup documentation
Reviewed-by: Brian Starkey
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fb_cma_helper.c | 20 ++-
drivers/gpu/drm/drm_fb_helper.c | 6 ++
drivers/gpu/drm/drm_fourcc.c | 62
drivers/gpu/drm/drm_framebuffer.c| 6 +-
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +-
include/drm/drm_fourcc.h | 61 ++-
6 files changed, 148 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index fc2b42dd3dc6..b07ab3f613e0 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -72,7 +72,9 @@ struct drm_gem_cma_object *drm_fb_cma_get_gem_obj(struct
drm_framebuffer *fb,
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_obj);
/**
- * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer
+ * drm_fb_cma_get_gem_addr() - Get physical address for framebuffer, for pixel
+ * formats where values are grouped in blocks this will get you the beginning
of
+ * the block
* @fb: The framebuffer
* @state: Which state of drm plane
* @plane: Which plane
@@ -87,6 +89,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
struct drm_gem_cma_object *obj;
dma_addr_t paddr;
u8 h_div = 1, v_div = 1;
+ u32 block_w = drm_format_info_block_width(fb->format, plane);
+ u32 block_h = drm_format_info_block_height(fb->format, plane);
+ u32 block_size = fb->format->char_per_block[plane];
+ u32 sample_x;
+ u32 sample_y;
+ u32 block_start_y;
+ u32 num_hblocks;
obj = drm_fb_cma_get_gem_obj(fb, plane);
if (!obj)
@@ -99,8 +108,13 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
v_div = fb->format->vsub;
}
- paddr += (fb->format->cpp[plane] * (state->src_x >> 16)) / h_div;
- paddr += (fb->pitches[plane] * (state->src_y >> 16)) / v_div;
+ sample_x = (state->src_x >> 16) / h_div;
+ sample_y = (state->src_y >> 16) / v_div;
+ block_start_y = (sample_y / block_h) * block_h;
+ num_hblocks = sample_x / block_w;
+
+ paddr += fb->pitches[plane] * block_start_y;
+ paddr += block_size * num_hblocks;
return paddr;
}
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 9b111e846847..8024524f0547 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1614,6 +1614,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo
*var,
if (var->pixclock != 0 || in_dbg_master())
return -EINVAL;
+ if ((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1))
+ return -EINVAL;
+
/*
* Changes struct fb_var_screeninfo are currently not pushed back
* to KMS, hence fail if different settings are requested.
@@ -1988,6 +1992,8 @@ void drm_fb_helper_fill_var(struct fb_info *info, struct
drm_fb_helper *fb_helpe
{
struct drm_framebuffer *fb = fb_helper->fb;
+ WARN_ON((drm_format_info_block_width(fb->format, 0) > 1) ||
+ (drm_format_info_block_height(fb->format, 0) > 1));
info->pseudo_palette = fb_helper->pseudo_palette;
info->var.xres_virtual = fb->width;
info->var.yres_virtual =
[PATCH v6 8/9] drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled
If we want to be able to write drmselftests for non-static core functions that are not intended to be used by drivers we need this functions to be exported. This adds a macro that is tied of CONFIG_DRM_DEBUG_SELFTEST, and uses that to export drm_internal_framebuffer_create, in order for subsequent patches to be able to test it. Signed-off-by: Alexandru Gheorghe --- drivers/gpu/drm/drm_framebuffer.c | 1 + include/drm/drmP.h| 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index 167c1c4544af..fcaea8f50513 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -323,6 +323,7 @@ drm_internal_framebuffer_create(struct drm_device *dev, return fb; } +EXPORT_SYMBOL_FOR_TESTS_ONLY(drm_internal_framebuffer_create); /** * drm_mode_addfb2 - add an FB to the graphics configuration diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 05350424a4d3..514beb2d483a 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -110,4 +110,10 @@ static inline bool drm_can_sleep(void) return true; } +#if defined(CONFIG_DRM_DEBUG_SELFTEST_MODULE) +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) EXPORT_SYMBOL(x) +#else +#define EXPORT_SYMBOL_FOR_TESTS_ONLY(x) +#endif + #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 6/9] drm/afbc: Add AFBC modifier usage documentation
From: Brian Starkey AFBC is a flexible, proprietary, lossless compression protocol and format, with a number of defined DRM format modifiers. To facilitate consistency and compatibility between different AFBC producers and consumers, document the expectations for usage of the AFBC DRM format modifiers in a new .rst chapter. Signed-off-by: Brian Starkey Reviewed-by: Liviu Dudau --- Documentation/gpu/afbc.rst| 233 ++ Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + include/uapi/drm/drm_fourcc.h | 3 + 4 files changed, 238 insertions(+) create mode 100644 Documentation/gpu/afbc.rst diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst new file mode 100644 index ..922d955da192 --- /dev/null +++ b/Documentation/gpu/afbc.rst @@ -0,0 +1,233 @@ +=== + Arm Framebuffer Compression (AFBC) +=== + +AFBC is a proprietary lossless image compression protocol and format. +It provides fine-grained random access and minimizes the amount of +data transferred between IP blocks. + +AFBC can be enabled on drivers which support it via use of the AFBC +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). + +All users of the AFBC modifiers must follow the usage guidelines laid +out in this document, to ensure compatibility across different AFBC +producers and consumers. + +Components and Ordering +=== + +AFBC streams can contain several components - where a component +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). +The assignment of input/output color channels must be consistent +between the encoder and the decoder for correct operation, otherwise +the consumer will interpret the decoded data incorrectly. + +Furthermore, when the lossless colorspace transform is used +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for +maximum compression efficiency), the component order must be: + + * Component 0: R + * Component 1: G + * Component 2: B + +The component ordering is communicated via the fourcc code in the +fourcc:modifier pair. In general, component '0' is considered to +reside in the least-significant bits of the corresponding linear +format. For example, COMP(bits): + + * DRM_FORMAT_ABGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: A(8) + + * DRM_FORMAT_BGR888 + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + + * DRM_FORMAT_YUYV + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + +In AFBC, 'X' components are not treated any differently from any other +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR +encodes with 4 components, like so: + + * DRM_FORMAT_XBGR + + * Component 0: R(8) + * Component 1: G(8) + * Component 2: B(8) + * Component 3: X(8) + +Please note, however, that the inclusion of a "wasted" 'X' channel is +bad for compression efficiency, and so it's recommended to avoid +formats containing 'X' bits. If a fourth component is +required/expected by the encoder/decoder, then it is recommended to +instead use an equivalent format with alpha, setting all alpha bits to +'1'. If there is no requirement for a fourth component, then a format +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. + +Number of Planes + + +Formats which are typically multi-planar in linear layouts (e.g. YUV +420), can be encoded into one, or multiple, AFBC planes. As with +component order, the encoder and decoder must agree about the number +of planes in order to correctly decode the buffer. The fourcc code is +used to determine the number of encoded planes in an AFBC buffer, +matching the number of planes for the linear (unmodified) format. +Within each plane, the component ordering also follows the fourcc +code: + +For example: + + * DRM_FORMAT_YUYV: nplanes = 1 + + * Plane 0: + + * Component 0: Y(8) + * Component 1: Cb(8, 2x1 subsampled) + * Component 2: Cr(8, 2x1 subsampled) + + * DRM_FORMAT_NV12: nplanes = 2 + + * Plane 0: + + * Component 0: Y(8) + + * Plane 1: + + * Component 0: Cb(8, 2x1 subsampled) + * Component 1: Cr(8, 2x1 subsampled) + +Cross-device interoperability += + +For maximum compatibility across devices, the table below defines +canonical formats for use between AFBC-enabled devices. Formats which +are listed here must be used exactly as specified when using the AFBC +modifiers. Formats which are not listed should be avoided. + +.. flat-table:: AFBC formats + + * - Fourcc code + - Description + - Planes/Components + + * - DRM_FORMAT_ABGR2101010 + - 10-bit per component RGB, with 2-bit alpha + - Plane 0: 4 components + * Component 0: R(10) + * Component 1: G(10) + * Component 2: B(10) +
[PATCH v6 0/9] Add method to describe tile/bit_level_packed formats
Changes since v5: - Added selftests for drm_internal_framebuffer_create - Added a macro to export internal function only when DRM_DEBUG_SELFTEST is enabled, suggested by Daniel Vetter, here [5]. - Cosmetic fixes suggested by Brian Starkey. - Rebased against drm-misc-next Changes since v4: - Rebased selftests on latest drm-misc-next Changes since v3: - added an utility function that computes the minimum pitch. - switched drm_format_info to in-line member documentation. - Cleanup/Improved the kernel doc. - Added selftests for: drm_format_info* helpers. There has been some discussion about extending drm core to handle linear tile formats, in the series sent by me here [1] and how to handle formats that are intended to be used just with modifiers(particularly AFBC modifiers) on Brian series [2] and on IRC here [3] and [4]. Hence, this big-merged series: Patch 1: Just a preparation patch that converts the drm_format_info kerneldoc to in-line documentation. Patches 2-4: handle tiled formats both in core and in malidp driver, this is done by extending drm_format_info with three new fields char_per_block, block_w, block_h and consistently handle in the generic code paths, both linear tiled formats and normal formats. What's different from [1] is the interpretation of pitch for tile formats which has been kept to be the same as for the other formats: pitch = average_chars_per_pixel * width. Patches 5-7: Introduce the YUV AFBC formats, the only thing noteworthy here is that cpp/char_per_block are set to 0 for formats where it's mandatory to be used together with a non-linear modifier and then that is used to bypass pitch check in framebuffer_check for formats that have cpp/char_per_block set to 0. Patches 8-9: A small fix for test-drm-helper module and adds self tests for drm_format_info* helpers. For the other touched functions we need a bit more infrastructure to be able to unittest/selftest them, since they need a stub drm_device and drm_file. As a side note, igt master branch doesn't seem to be using test-drm-helper.ko, so I just tested by loading/unloading the module manually. [1] https://lists.freedesktop.org/archives/dri-devel/2018-September/188245.html [2] https://lists.freedesktop.org/archives/dri-devel/2018-September/189620.html [3] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-09-13_html=true [4] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2018-09-14_html=true [5] https://www.spinics.net/lists/dri-devel/msg193422.html v5: https://www.spinics.net/lists/dri-devel/msg193384.html Alexandru Gheorghe (7): drm/fourcc: Add char_per_block, block_w and block_h in drm_format_info drm/fourcc: Add fourcc for Mali linear tiled formats drm: mali-dp: Enable Mali-DP tiled buffer formats drm: Extend framebuffer_check to handle formats with cpp/char_per_block 0 drm/selftests: Add tests for drm_format_info* helpers drm: Add macro to export functions only when CONFIG_DRM_DEBUG_SELFTEST is enabled drm/selftests: Add tests for drm_internal_framebuffer_create Brian Starkey (2): drm/fourcc: Add AFBC yuv fourccs for Mali drm/afbc: Add AFBC modifier usage documentation Documentation/gpu/afbc.rst| 233 Documentation/gpu/drivers.rst | 1 + MAINTAINERS | 1 + drivers/gpu/drm/arm/malidp_hw.c | 14 +- drivers/gpu/drm/arm/malidp_planes.c | 28 +- drivers/gpu/drm/drm_fb_cma_helper.c | 20 +- drivers/gpu/drm/drm_fb_helper.c | 6 + drivers/gpu/drm/drm_fourcc.c | 87 + drivers/gpu/drm/drm_framebuffer.c | 13 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 2 +- drivers/gpu/drm/selftests/Makefile| 3 +- .../gpu/drm/selftests/drm_modeset_selftests.h | 4 + drivers/gpu/drm/selftests/test-drm_format.c | 290 +++ .../gpu/drm/selftests/test-drm_framebuffer.c | 344 ++ .../drm/selftests/test-drm_modeset_common.h | 4 + include/drm/drmP.h| 6 + include/drm/drm_fourcc.h | 61 +++- include/uapi/drm/drm_fourcc.h | 31 ++ 18 files changed, 1132 insertions(+), 16 deletions(-) create mode 100644 Documentation/gpu/afbc.rst create mode 100644 drivers/gpu/drm/selftests/test-drm_format.c create mode 100644 drivers/gpu/drm/selftests/test-drm_framebuffer.c -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 --- Comment #21 from Andrey Grodzovsky --- Please load the driver in debug mode so I can see the error code value in dmesg - when loading the kernel add drm.debug=0xff Also to trace where exactly the error originated from please install trace-cmd and beore starting X (assuming you get the failure and the dmesg error right on start) sudo trace-cmd start -p function_graph -l amdgpu_cs_ioctl and get the output from /sys/kernel/debug/tracing/trace -- 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 v2 2/4] drm/dp_mst: Start tracking per-port VCPI allocations
On Mon, 2018-10-29 at 15:24 +0100, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 04:35:47PM -0400, Lyude Paul wrote:
> > There has been a TODO waiting for quite a long time in
> > drm_dp_mst_topology.c:
> >
> > /* We cannot rely on port->vcpi.num_slots to update
> > * topology_state->avail_slots as the port may not exist if the parent
> > * branch device was unplugged. This should be fixed by tracking
> > * per-port slot allocation in drm_dp_mst_topology_state instead of
> > * depending on the caller to tell us how many slots to release.
> > */
> >
> > That's not the only reason we should fix this: forcing the driver to
> > track the VCPI allocations throughout a state's atomic check is
> > error prone, because it means that extra care has to be taken with the
> > order that drm_dp_atomic_find_vcpi_slots() and
> > drm_dp_atomic_release_vcpi_slots() are called in in order to ensure
> > idempotency. Currently the only driver actually using these helpers,
> > i915, doesn't even do this correctly: multiple ->best_encoder() checks
> > with i915's current implementation would not be idempotent and would
> > over-allocate VCPI slots, something I learned trying to implement
> > fallback retraining in MST.
> >
> > So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots()
> > and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for
> > each port. This allows us to ensure idempotency without having to rely
> > on the driver as much. Additionally: the driver doesn't need to do any
> > kind of VCPI slot tracking anymore if it doesn't need it for it's own
> > internal state.
> >
> > Additionally; this adds a new drm_dp_mst_atomic_check() helper which
> > must be used by atomic drivers to perform validity checks for the new
> > VCPI allocations incurred by a state.
> >
> > Also: update the documentation and make it more obvious that these
> > /must/ be called by /all/ atomic drivers supporting MST.
> >
> > Changes since v1:
> > - Don't use the now-removed ->atomic_check() for private objects hook,
> >just give drivers a function to call themselves
> >
> > Signed-off-by: Lyude Paul
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 190 +-
> > drivers/gpu/drm/i915/intel_display.c | 8 ++
> > drivers/gpu/drm/i915/intel_dp_mst.c | 31 +++--
> > include/drm/drm_dp_mst_helper.h | 11 +-
> > 4 files changed, 192 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 8c3cfac437f4..dcfab7536914 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -2614,21 +2614,33 @@ static int drm_dp_init_vcpi(struct
> > drm_dp_mst_topology_mgr *mgr,
> > }
> >
> > /**
> > - * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
> > + * drm_dp_atomic_find_vcpi_slots() - Find and add VCPI slots to the state
> > * @state: global atomic state
> > * @mgr: MST topology manager for the port
> > * @port: port to find vcpi slots for
> > * @pbn: bandwidth required for the mode in PBN
> > *
> > + * Allocates VCPI slots to @port, replacing any previous VCPI allocations
> > it
> > + * may have had. Any atomic drivers which support MST must call this
> > function
> > + * in their atomic_check() handlers to change the current VCPI allocation
> > for
>
> Maybe do a nice kerneldoc reference to the right atomic_check here.
>
> > + * the new state. After the ->atomic_check() hooks of the driver and all
> > other
>
> This will upset the kerneldoc parser I think.
>
> > + * mode objects in the state have been called, DRM will check the final
> > VCPI
> > + * allocations to ensure that they will fit into the available bandwidth
> > on
> > + * the topology.
> > + *
> > + * See also: drm_dp_atomic_release_vcpi_slots()
>
> Also need to reference drm_dp_mst_atomic_check() here and that drivers
> must call it or nothing happens.
> > + *
> > * RETURNS:
> > - * Total slots in the atomic state assigned for this port or error
> > + * Total slots in the atomic state assigned for this port, or a negative
> > error
> > + * code if the port no longer exists
> > */
> > int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
> > struct drm_dp_mst_topology_mgr *mgr,
> > struct drm_dp_mst_port *port, int pbn)
> > {
> > struct drm_dp_mst_topology_state *topology_state;
> > - int req_slots;
> > + struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
> > + int prev_slots, req_slots, ret;
> >
> > topology_state = drm_atomic_get_mst_topology_state(state, mgr);
> > if (IS_ERR(topology_state))
> > @@ -2637,20 +2649,41 @@ int drm_dp_atomic_find_vcpi_slots(struct
> > drm_atomic_state *state,
> > port = drm_dp_get_validated_port_ref(mgr, port);
> > if (port == NULL)
> >
Re: [PATCH v4 3/4] drm: Document variable refresh properties
On 2018-10-26 7:59 p.m., Ville Syrjälä wrote: > On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote: >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: >>> >>> Speaking of timestamps. What is the expected behaviour of vblank >>> timestamps when vrr is enabled? >> >> When vrr is enabled the duration of the vertical front porch will be >> extended until flip or timeout occurs. The vblank timestamp will vary >> based on duration of the vertical front porch. The min/max duration for >> the front porch can be specified by the driver via the min/max range. >> >> No changes to vblank timestamping handling should be necessary to >> accommodate variable refresh rate. > > The problem is that the timestamp is supposed to correspond to the first > active pixel. And since we don't know how long the front porch will be > we can't realistically report the true value. So I guess just assuming > min front porch length is as good as anything else? That (and documenting that the timestamp corresponds to the earliest possible first active pixel, not necessarily the actual one, with VRR) might be good enough for the actual vblank event timestamps. However, I'm not so sure about the timestamps of page flip completion events. Those could be very misleading if the flip completes towards the timeout, which could result in bad behaviour of applications which use them for animation timing. Maybe the timestamp could be updated appropriately (yes, I'm hand-waving :) in drm_crtc_send_vblank_event? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/6] dt-bindings: drm/panel: simple: Add no-hpd property
On Thu, Oct 25, 2018 at 03:21:29PM -0700, Douglas Anderson wrote: > Some eDP panels that are designed to be always connected to a board > use their HPD signal to signal that they've finished powering on and > they're ready to be talked to. > > However, for various reasons it's possible that the HPD signal from > the panel isn't actually hooked up. In the case where the HPD isn't > hooked up you can look at the timing diagram on the panel datasheet > and insert a delay for the maximum amount of time that the HPD might > take to come up. > > Let's add a property in the device tree for this concept. > > Signed-off-by: Douglas Anderson Thanks for the series, Doug, I've applied it all to drm-misc-next-fixes for 4.20. Sean > Reviewed-by: Sean Paul > Reviewed-by: Rob Herring > --- > > Changes in v2: None > > .../devicetree/bindings/display/panel/simple-panel.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > index 45a457ad38f0..b2b872c710f2 100644 > --- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt > +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt > @@ -11,6 +11,9 @@ Optional properties: > - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing > - enable-gpios: GPIO pin to enable or disable the panel > - backlight: phandle of the backlight device attached to the panel > +- no-hpd: This panel is supposed to communicate that it's ready via HPD > + (hot plug detect) signal, but the signal isn't hooked up so we should > + hardcode the max delay from the panel spec when powering up the panel. > > Example: > > -- > 2.19.1.568.g152ad8e336-goog > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108585] *ERROR* hw_init of IP block failed -22
https://bugs.freedesktop.org/show_bug.cgi?id=108585 --- Comment #3 from Dan Horák --- Ha, so it's the firmware stored in the initrds, what is different (lsinitrd lied). And the latest polaris11* ones provoke the crash. When I manually replaced them with the ones from the rc8 initrd, I've successfully booted into the 4.19 GA kernel. -- 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 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #33 from Alex Deucher --- The mclk switching needs to happen during the vblank period to avoid the flickering. If there is not enough time in the vblank period, you may see flickering outside of the blanking period. Can you figure out what modes and refresh rates exhibit this issue? -- 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 v2 3/4] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
On Mon, 2018-10-29 at 15:25 +0100, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 04:35:48PM -0400, Lyude Paul wrote:
> > It occurred to me that we never actually check this! So let's start
> > doing that.
> >
> > Signed-off-by: Lyude Paul
> > Cc: Daniel Vetter
>
> Reviewed-by: Daniel Vetter
>
> One thought on testing all this: I think long term some unti tests, where
> we have a fake driver doing fake mst branch/ports and a bunch of
> allocations and then checking that it all works and validates would be
> nice. Longer term project ofc, and maybe after Kunit has been merged ...
mhm-you see why I was considering how we could use vkms with this :), but yeah
getting unit tests is one of the reasons I'm hoping to move some more MST
logic out into the DRM helpers
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index dcfab7536914..8bb03700e199 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -3238,7 +3238,7 @@ int drm_dp_mst_atomic_check(struct
> > drm_dp_mst_topology_state *state)
> > {
> > struct drm_dp_mst_topology_mgr *mgr = state->mgr;
> > struct drm_dp_vcpi_allocation *pos;
> > - int avail_slots = 63;
> > + int avail_slots = 63, payload_count = 0;
> >
> > list_for_each_entry(pos, >vcpis, next) {
> > DRM_DEBUG_ATOMIC("[MST PORT:%p] requires %d vcpi slots\n",
> > @@ -3251,6 +3251,12 @@ int drm_dp_mst_atomic_check(struct
> > drm_dp_mst_topology_state *state)
> > avail_slots + pos->vcpi);
> > return -ENOSPC;
> > }
> > +
> > + if (++payload_count > mgr->max_payloads) {
> > + DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many
> > payloads (max=%d)\n",
> > +mgr, state, mgr->max_payloads);
> > + return -EINVAL;
> > + }
> > }
> > DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p vcpi avail=%d used=%d\n",
> > mgr, state, avail_slots, 63 - avail_slots);
> > --
> > 2.17.2
> >
>
>
--
Cheers,
Lyude Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] fbcon: Silence fbcon logo on 'quiet' boots
A variant of this patch has been in Fedora since at least 2010 and
AFAWCT there haven't been any complaints about the change in behavior.
https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/silence-fbcon-logo.patch
P.
---8<---
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
v2: It helps to commit all my changes before sending them. Remove extra
bracket.
Signed-off-by: Prarit Bhargava
Cc: Hans de Goede
Cc: Marko Myllynen
Cc: Steven Rostedt (VMware)
Cc: Bartlomiej Zolnierkiewicz
Cc: Kees Cook
Cc: Daniel Vetter
Cc: Thierry Reding
Cc: Yisheng Xie
Cc: dri-devel@lists.freedesktop.org
---
drivers/video/fbdev/core/fbcon.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 75ebbbf0a1fb..53fc151f3f7b 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -650,11 +650,14 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
fb_info *info,
kfree(save);
}
+ if (logo_shown == FBCON_LOGO_DONTSHOW)
+ return;
+
if (logo_lines > vc->vc_bottom) {
logo_shown = FBCON_LOGO_CANSHOW;
printk(KERN_INFO
"fbcon_init: disable boot-logo (boot-logo bigger than
screen).\n");
- } else if (logo_shown != FBCON_LOGO_DONTSHOW) {
+ } else {
logo_shown = FBCON_LOGO_DRAW;
vc->vc_top = logo_lines;
}
@@ -1052,7 +1055,7 @@ static void fbcon_init(struct vc_data *vc, int init)
struct vc_data **default_mode = vc->vc_display_fg;
struct vc_data *svc = *default_mode;
struct display *t, *p = _display[vc->vc_num];
- int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
+ int new_rows, new_cols, rows, cols, charcnt = 256;
int cap, ret;
if (info_idx == -1 || info == NULL)
@@ -1060,9 +1063,9 @@ static void fbcon_init(struct vc_data *vc, int init)
cap = info->flags;
- if (vc != svc || logo_shown == FBCON_LOGO_DONTSHOW ||
+ if (vc != svc || console_loglevel <= CONSOLE_LOGLEVEL_QUIET ||
(info->fix.type == FB_TYPE_TEXT))
- logo = 0;
+ logo_shown = FBCON_LOGO_DONTSHOW;
if (var_to_display(p, >var, info))
return;
@@ -1178,7 +1181,7 @@ static void fbcon_init(struct vc_data *vc, int init)
} else
vc_resize(vc, new_cols, new_rows);
- if (logo)
+ if (logo_shown != FBCON_LOGO_DONTSHOW)
fbcon_prepare_logo(vc, info, cols, rows, new_cols, new_rows);
if (vc == svc && softback_buf)
--
2.14.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] drm/i915: Define Intel HDCP2.2 registers
On Mon, Oct 29, 2018 at 03:15:51PM +0530, Ramalingam C wrote:
> Intel HDCP2.2 registers are defined with addr offsets and bit details.
>
> v2:
> Replaced the arith calc with _PICK [Sean Paul]
> v3:
> No changes.
> v4:
> %s/HDCP2_CTR_DDI/HDCP2_CTL_DDI [Uma]
> v5:
> Added parentheses for the parameters of macro.
> v6:
> No changes
> v7:
> No changes
>
> Signed-off-by: Ramalingam C
> Reviewed-by: Sean Paul
> Reviewed-by: Uma Shankar
All (except the one patch) merged into dinq.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 69eb573348b3..934722693477 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9038,6 +9038,38 @@ enum skl_power_gate {
> #define HDCP_STATUS_CIPHER BIT(16)
> #define HDCP_STATUS_FRAME_CNT(x)(((x) >> 8) & 0xff)
>
> +/* HDCP2.2 Registers */
> +#define _PORTA_HDCP2_BASE0x66800
> +#define _PORTB_HDCP2_BASE0x66500
> +#define _PORTC_HDCP2_BASE0x66600
> +#define _PORTD_HDCP2_BASE0x66700
> +#define _PORTE_HDCP2_BASE0x66A00
> +#define _PORTF_HDCP2_BASE0x66900
> +#define _PORT_HDCP2_BASE(port, x)_MMIO(_PICK((port), \
> + _PORTA_HDCP2_BASE, \
> + _PORTB_HDCP2_BASE, \
> + _PORTC_HDCP2_BASE, \
> + _PORTD_HDCP2_BASE, \
> + _PORTE_HDCP2_BASE, \
> + _PORTF_HDCP2_BASE) + (x))
> +
> +#define HDCP2_AUTH_DDI(port) _PORT_HDCP2_BASE(port, 0x98)
> +#define AUTH_LINK_AUTHENTICATEDBIT(31)
> +#define AUTH_LINK_TYPE BIT(30)
> +#define AUTH_FORCE_CLR_INPUTCTRBIT(19)
> +#define AUTH_CLR_KEYS BIT(18)
> +
> +#define HDCP2_CTL_DDI(port) _PORT_HDCP2_BASE(port, 0xB0)
> +#define CTL_LINK_ENCRYPTION_REQBIT(31)
> +
> +#define HDCP2_STATUS_DDI(port) _PORT_HDCP2_BASE(port, 0xB4)
> +#define STREAM_ENCRYPTION_STATUS_A BIT(31)
> +#define STREAM_ENCRYPTION_STATUS_B BIT(30)
> +#define STREAM_ENCRYPTION_STATUS_C BIT(29)
> +#define LINK_TYPE_STATUS BIT(22)
> +#define LINK_AUTH_STATUS BIT(21)
> +#define LINK_ENCRYPTION_STATUS BIT(20)
> +
> /* Per-pipe DDI Function Control */
> #define _TRANS_DDI_FUNC_CTL_A0x60400
> #define _TRANS_DDI_FUNC_CTL_B0x61400
> --
> 2.7.4
>
--
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] fbcon: Silence fbcon logo on 'quiet' boots
On 10/29/2018 11:24 AM, Thierry Reding wrote:
> On Mon, Oct 29, 2018 at 09:02:32AM -0400, Prarit Bhargava wrote:
>> A variant of this patch has been in Fedora since at least 2010 and
>> AFAWCT there haven't been any complaints about the change in behavior.
>>
>> https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/silence-fbcon-logo.patch
>>
>> P.
>>
>> ---8<---
>>
>> On text-based systems the 'quiet' boot option will show printk levels
>> higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
>> during boot can cause some consoles to lose display data and as a result
>> confuse the end user.
>>
>> Do not display the Tux logo on systems that are in 'quiet' boot.
>>
>> Signed-off-by: Prarit Bhargava
>> Cc: Hans de Goede
>> Cc: Marko Myllynen
>> Cc: Bartlomiej Zolnierkiewicz
>> Cc: Kees Cook
>> Cc: Daniel Vetter
>> Cc: Thierry Reding
>> Cc: Yisheng Xie
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: Steven Rostedt (VMware)
>> ---
>> drivers/video/fbdev/core/fbcon.c | 13 -
>> 1 file changed, 8 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbcon.c
>> b/drivers/video/fbdev/core/fbcon.c
>> index 75ebbbf0a1fb..a2f2c7ea11ef 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -650,11 +650,14 @@ static void fbcon_prepare_logo(struct vc_data *vc,
>> struct fb_info *info,
>> kfree(save);
>> }
>>
>> +if (logo_shown == FBCON_LOGO_DONTSHOW) {
>> +return;
>> +
>
> You're missing a closing } here (well, you really shouldn't have the
> opening { in the first place since this is a single line block.
>
> That's what's causing the warnings from the 0-day builder.
Will send v2.
P.
>
> Thierry
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: Silence fbcon logo on 'quiet' boots
On Mon, Oct 29, 2018 at 09:02:32AM -0400, Prarit Bhargava wrote:
> A variant of this patch has been in Fedora since at least 2010 and
> AFAWCT there haven't been any complaints about the change in behavior.
>
> https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/silence-fbcon-logo.patch
>
> P.
>
> ---8<---
>
> On text-based systems the 'quiet' boot option will show printk levels
> higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
> during boot can cause some consoles to lose display data and as a result
> confuse the end user.
>
> Do not display the Tux logo on systems that are in 'quiet' boot.
>
> Signed-off-by: Prarit Bhargava
> Cc: Hans de Goede
> Cc: Marko Myllynen
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Kees Cook
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Yisheng Xie
> Cc: dri-devel@lists.freedesktop.org
> Cc: Steven Rostedt (VMware)
> ---
> drivers/video/fbdev/core/fbcon.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 75ebbbf0a1fb..a2f2c7ea11ef 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -650,11 +650,14 @@ static void fbcon_prepare_logo(struct vc_data *vc,
> struct fb_info *info,
> kfree(save);
> }
>
> + if (logo_shown == FBCON_LOGO_DONTSHOW) {
> + return;
> +
You're missing a closing } here (well, you really shouldn't have the
opening { in the first place since this is a single line block.
That's what's causing the warnings from the 0-day builder.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/6] drm/i915: Cancel the Link check before disable
On Mon, Oct 29, 2018 at 03:15:48PM +0530, Ramalingam C wrote:
> To avoid the execution of link integrity check when the HDCP is
> already disabled, cancel the delayed work for link integrity check
> before disabling the HDCP.
>
> Signed-off-by: Ramalingam C
This is racy. As an exercise, please lay out the scenario of what exactly
happens where. I'll drop this patch from the series.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index 1bf487f94254..d13e4af9ac05 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -821,6 +821,7 @@ int intel_hdcp_disable(struct intel_connector *connector)
> if (!hdcp->shim)
> return -ENOENT;
>
> + cancel_delayed_work_sync(>check_work);
> mutex_lock(>mutex);
>
> if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> @@ -829,7 +830,6 @@ int intel_hdcp_disable(struct intel_connector *connector)
> }
>
> mutex_unlock(>mutex);
> - cancel_delayed_work_sync(>check_work);
> return ret;
> }
>
> --
> 2.7.4
>
--
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] fbcon: Silence fbcon logo on 'quiet' boots
On 10/29/2018 09:56 AM, kbuild test robot wrote: > Hi Prarit, > > Thank you for the patch! Yet something to improve: > > [auto build test ERROR on sof-driver-fuweitax/master] > [also build test ERROR on v4.19 next-20181029] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: > https://github.com/0day-ci/linux/commits/Prarit-Bhargava/fbcon-Silence-fbcon-logo-on-quiet-boots/20181029-211617 > base: https://github.com/fuweitax/linux master > config: m68k-multi_defconfig (attached as .config) > compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > GCC_VERSION=7.2.0 make.cross ARCH=m68k > > All errors (new ones prefixed by >>): > >drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': >drivers/video/fbdev/core/fbcon.c:680:13: error: invalid storage class for > function 'set_blitting_type' > static void set_blitting_type(struct vc_data *vc, struct fb_info *info) > ^ >drivers/video/fbdev/core/fbcon.c:680:1: warning: ISO C90 forbids mixed > declarations and code [-Wdeclaration-after-statement] > static void set_blitting_type(struct vc_data *vc, struct fb_info *info) > ^~ >drivers/video/fbdev/core/fbcon.c:690:12: error: invalid storage class for > function 'fbcon_invalid_charcount' > static int fbcon_invalid_charcount(struct fb_info *info, unsigned > charcount) >^~~ >drivers/video/fbdev/core/fbcon.c:698:12: error: invalid storage class for > function 'con2fb_acquire_newinfo' > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info > *info, >^~ >drivers/video/fbdev/core/fbcon.c:734:12: error: invalid storage class for > function 'con2fb_release_oldinfo' > static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info > *oldinfo, >^~ >drivers/video/fbdev/core/fbcon.c:780:13: error: invalid storage class for > function 'con2fb_init_display' > static void con2fb_init_display(struct vc_data *vc, struct fb_info *info, > ^~~ >drivers/video/fbdev/core/fbcon.c:825:12: error: invalid storage class for > function 'set_con2fb_map' > static int set_con2fb_map(int unit, int newidx, int user) >^~ >drivers/video/fbdev/core/fbcon.c:882:12: error: invalid storage class for > function 'var_to_display' > static int var_to_display(struct display *disp, >^~ >drivers/video/fbdev/core/fbcon.c:906:13: error: invalid storage class for > function 'display_to_var' > static void display_to_var(struct fb_var_screeninfo *var, > ^~ >drivers/video/fbdev/core/fbcon.c:925:20: error: invalid storage class for > function 'fbcon_startup' > static const char *fbcon_startup(void) >^ >drivers/video/fbdev/core/fbcon.c:1036:13: error: invalid storage class for > function 'fbcon_init' > static void fbcon_init(struct vc_data *vc, int init) > ^~ >drivers/video/fbdev/core/fbcon.c:1183:13: error: invalid storage class for > function 'fbcon_free_font' > static void fbcon_free_font(struct display *p, bool freefont) > ^~~ >drivers/video/fbdev/core/fbcon.c:1191:13: error: invalid storage class for > function 'set_vc_hi_font' > static void set_vc_hi_font(struct vc_data *vc, bool set); > ^~ >drivers/video/fbdev/core/fbcon.c:1193:13: error: invalid storage class for > function 'fbcon_deinit' > static void fbcon_deinit(struct vc_data *vc) > ^~~~ >drivers/video/fbdev/core/fbcon.c: In function 'fbcon_deinit': >>> drivers/video/fbdev/core/fbcon.c:1229:3: error: implicit declaration of >>> function 'set_vc_hi_font'; did you mean 'seq_path_root'? >>> [-Werror=implicit-function-declaration] > set_vc_hi_font(vc, false); > ^~ Hmm ... this doesn't look like anything that is at fault with my patch. There's a lot of warnings here, and perhaps another fix is required to make sure that the configs are set correctly? I can certainly take a look in another patch but AFAICT this isn't an issue with my patch. P. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/scheduler: Add drm_sched_job_cleanup
Reviewed-by: Christian König
Going to push that to into our upstream branch.
Thanks,
Christian.
Am 29.10.18 um 16:01 schrieb Grodzovsky, Andrey:
> Acked-by: Andrey Grodzovsky
>
> Andrey
>
>
> On 10/29/2018 05:32 AM, Sharat Masetty wrote:
>> This patch adds a new API to clean up the scheduler job resources. This
>> is primarliy needed in cases the job was created but was not queued to
>> the scheduler queue. Additionally with this change, the layer which
>> creates the scheduler job also gets to free up the job's resources and
>> this entails moving the dma_fence_put(finished_fence) to the drivers
>> ops free handler routines.
>>
>> Signed-off-by: Sharat Masetty
>> ---
>> Changes from v1:
>> Addressed review comments from Christian Koenig
>>
>>drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
>>drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 ++
>>drivers/gpu/drm/etnaviv/etnaviv_sched.c | 3 +++
>>drivers/gpu/drm/scheduler/sched_entity.c | 1 -
>>drivers/gpu/drm/scheduler/sched_main.c | 13 -
>>drivers/gpu/drm/v3d/v3d_sched.c | 2 ++
>>include/drm/gpu_scheduler.h | 1 +
>>7 files changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index 663043c..5d768f9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -1260,8 +1260,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
>> return 0;
>>
>>error_abort:
>> -dma_fence_put(>base.s_fence->finished);
>> -job->base.s_fence = NULL;
>> +drm_sched_job_cleanup(>base);
>> amdgpu_mn_unlock(p->mn);
>>
>>error_unlock:
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> index 755f733..e0af44f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>> @@ -112,6 +112,8 @@ static void amdgpu_job_free_cb(struct drm_sched_job
>> *s_job)
>> struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
>> struct amdgpu_job *job = to_amdgpu_job(s_job);
>>
>> +drm_sched_job_cleanup(s_job);
>> +
>> amdgpu_ring_priority_put(ring, s_job->s_priority);
>> dma_fence_put(job->fence);
>> amdgpu_sync_free(>sync);
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index e7c3ed6..6f3c9bf 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -127,6 +127,8 @@ static void etnaviv_sched_free_job(struct drm_sched_job
>> *sched_job)
>>{
>> struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
>>
>> +drm_sched_job_cleanup(sched_job);
>> +
>> etnaviv_submit_put(submit);
>>}
>>
>> @@ -159,6 +161,7 @@ int etnaviv_sched_push_job(struct drm_sched_entity
>> *sched_entity,
>> submit->out_fence, 0,
>> INT_MAX, GFP_KERNEL);
>> if (submit->out_fence_id < 0) {
>> +drm_sched_job_cleanup(>sched_job);
>> ret = -ENOMEM;
>> goto out_unlock;
>> }
>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
>> b/drivers/gpu/drm/scheduler/sched_entity.c
>> index 3e22a54..8ff9d21f 100644
>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>> @@ -204,7 +204,6 @@ static void drm_sched_entity_kill_jobs_cb(struct
>> dma_fence *f,
>>
>> drm_sched_fence_finished(job->s_fence);
>> WARN_ON(job->s_fence->parent);
>> -dma_fence_put(>s_fence->finished);
>> job->sched->ops->free_job(job);
>>}
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index 44fe587..14009af 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -220,7 +220,6 @@ static void drm_sched_job_finish(struct work_struct
>> *work)
>> drm_sched_start_timeout(sched);
>> spin_unlock(>job_list_lock);
>>
>> -dma_fence_put(_job->s_fence->finished);
>> sched->ops->free_job(s_job);
>>}
>>
>> @@ -424,6 +423,18 @@ int drm_sched_job_init(struct drm_sched_job *job,
>>EXPORT_SYMBOL(drm_sched_job_init);
>>
>>/**
>> + * drm_sched_job_cleanup - clean up scheduler job resources
>> + *
>> + * @job: scheduler job to clean up
>> + */
>> +void drm_sched_job_cleanup(struct drm_sched_job *job)
>> +{
>> +dma_fence_put(>s_fence->finished);
>> +job->s_fence = NULL;
>> +}
>> +EXPORT_SYMBOL(drm_sched_job_cleanup);
>> +
>> +/**
>> * drm_sched_ready - is the scheduler ready
>> *
>> * @sched: scheduler instance
>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
>> b/drivers/gpu/drm/v3d/v3d_sched.c
>> index 9243dea..4ecd45e 100644
>> --- a/drivers/gpu/drm/v3d/v3d_sched.c
>> +++
[Bug 108573] Cannot set pstate values with under-voltage values for Vega M
https://bugs.freedesktop.org/show_bug.cgi?id=108573 Alex Deucher changed: What|Removed |Added Severity|normal |enhancement -- 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 v2] drm/scheduler: Add drm_sched_job_cleanup
Acked-by: Andrey Grodzovsky
Andrey
On 10/29/2018 05:32 AM, Sharat Masetty wrote:
> This patch adds a new API to clean up the scheduler job resources. This
> is primarliy needed in cases the job was created but was not queued to
> the scheduler queue. Additionally with this change, the layer which
> creates the scheduler job also gets to free up the job's resources and
> this entails moving the dma_fence_put(finished_fence) to the drivers
> ops free handler routines.
>
> Signed-off-by: Sharat Masetty
> ---
> Changes from v1:
> Addressed review comments from Christian Koenig
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +--
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 ++
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 3 +++
> drivers/gpu/drm/scheduler/sched_entity.c | 1 -
> drivers/gpu/drm/scheduler/sched_main.c | 13 -
> drivers/gpu/drm/v3d/v3d_sched.c | 2 ++
> include/drm/gpu_scheduler.h | 1 +
> 7 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 663043c..5d768f9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -1260,8 +1260,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
> return 0;
>
> error_abort:
> - dma_fence_put(>base.s_fence->finished);
> - job->base.s_fence = NULL;
> + drm_sched_job_cleanup(>base);
> amdgpu_mn_unlock(p->mn);
>
> error_unlock:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index 755f733..e0af44f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -112,6 +112,8 @@ static void amdgpu_job_free_cb(struct drm_sched_job
> *s_job)
> struct amdgpu_ring *ring = to_amdgpu_ring(s_job->sched);
> struct amdgpu_job *job = to_amdgpu_job(s_job);
>
> + drm_sched_job_cleanup(s_job);
> +
> amdgpu_ring_priority_put(ring, s_job->s_priority);
> dma_fence_put(job->fence);
> amdgpu_sync_free(>sync);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> index e7c3ed6..6f3c9bf 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
> @@ -127,6 +127,8 @@ static void etnaviv_sched_free_job(struct drm_sched_job
> *sched_job)
> {
> struct etnaviv_gem_submit *submit = to_etnaviv_submit(sched_job);
>
> + drm_sched_job_cleanup(sched_job);
> +
> etnaviv_submit_put(submit);
> }
>
> @@ -159,6 +161,7 @@ int etnaviv_sched_push_job(struct drm_sched_entity
> *sched_entity,
> submit->out_fence, 0,
> INT_MAX, GFP_KERNEL);
> if (submit->out_fence_id < 0) {
> + drm_sched_job_cleanup(>sched_job);
> ret = -ENOMEM;
> goto out_unlock;
> }
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index 3e22a54..8ff9d21f 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -204,7 +204,6 @@ static void drm_sched_entity_kill_jobs_cb(struct
> dma_fence *f,
>
> drm_sched_fence_finished(job->s_fence);
> WARN_ON(job->s_fence->parent);
> - dma_fence_put(>s_fence->finished);
> job->sched->ops->free_job(job);
> }
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 44fe587..14009af 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -220,7 +220,6 @@ static void drm_sched_job_finish(struct work_struct *work)
> drm_sched_start_timeout(sched);
> spin_unlock(>job_list_lock);
>
> - dma_fence_put(_job->s_fence->finished);
> sched->ops->free_job(s_job);
> }
>
> @@ -424,6 +423,18 @@ int drm_sched_job_init(struct drm_sched_job *job,
> EXPORT_SYMBOL(drm_sched_job_init);
>
> /**
> + * drm_sched_job_cleanup - clean up scheduler job resources
> + *
> + * @job: scheduler job to clean up
> + */
> +void drm_sched_job_cleanup(struct drm_sched_job *job)
> +{
> + dma_fence_put(>s_fence->finished);
> + job->s_fence = NULL;
> +}
> +EXPORT_SYMBOL(drm_sched_job_cleanup);
> +
> +/**
>* drm_sched_ready - is the scheduler ready
>*
>* @sched: scheduler instance
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
> index 9243dea..4ecd45e 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -35,6 +35,8 @@
> {
> struct v3d_job *job = to_v3d_job(sched_job);
>
> + drm_sched_job_cleanup(sched_job);
> +
> v3d_exec_put(job->exec);
> }
>
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index d87b268..41136c4a 100644
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 --- Comment #20 from Samuel Pitoiset --- Make sure to load the right version of libdrm (ie. 2.4.93 or more recent). I had this problem today because I was loading and old version of libdrm. Something was installed in the wrong place. -- 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 v4 3/4] drm: Document variable refresh properties
On 10/29/18 4:36 AM, Pekka Paalanen wrote: > On Fri, 26 Oct 2018 17:34:15 + > "Kazlauskas, Nicholas" wrote: > >> On 10/26/18 10:53 AM, Ville Syrjälä wrote: >>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote: On 10/26/18 7:37 AM, Pekka Paalanen wrote: > > Hi, > > where is the documentation that explains how drivers must implement > "variable refresh rate adjustment"? > > What should and could userspace expect to get if it flicks this switch? > > I also think the kernel documentation should include a description of > what VRR actually is and how it conceptually works as far as userspace > is concerned. > > That is, the kernel documentation should describe what this thing does, > so that we avoid every driver implementing a different thing. For > example, one driver could prevent the luminance flickering itself by > tuning the timings while another driver might not do that, which means > that an application tested on the former driver will look just fine > while it is unbearable to watch on the latter. > > > Thanks, > pq I felt it was best to leave this more on the vague side to not impose restrictions yet on what a driver must do. If you think it's worth defining what the "baseline" expectation is for userspace, I would probably describe it as "utilizing the monitor's variable refresh rate to reduce stuttering or tearing that can occur during flipping". This is currently what the amdgpu driver has enabled for support. The implementation also isn't much more complex than just passing the variable refresh range to the hardware. > > Hi, > > sorry, but that says nothing. > > Also, tearing has nothing to do here. VRR reduces stuttering if > userspace is already tear-free. If userspace was driving the display in > a tearing fashion, VRR will not reduce or remove tearing, it just makes > it happen at different points and times. Tearing happens because > framebuffer flips are executed regardless of the refresh cycle, so > adjusting the refresh timings won't help. > > However... > I wouldn't want every driver to be forced to implement some sort of luminance flickering by default. It's not noticeable on many panels and any tuning would inherently add latency to the output. It would probably be better left as a new property or a driver specific feature. > > The point is to give userspace guaranteed expectations. If the > expectation is that some displays might actually emit bad luminance > flickering, then userspace must always assume the worst and implement > the needed slewing algorithms to avoid it, even if it would be > unnecessary. > > Userspace is farther away from the hardware than the drivers are, and > if userspace is required to implement luminance flickering avoidance, > that implementation must be done in all display servers and KMS apps > that might enable VRR. That would also call for a userspace hardware > database, so that people can set up quirks to enable/disable/adjust the > algorithms for specific hardware with the hopes that other users could > then have a good out-of-the-box experience. Instead, if possible, I > would like to see some guarantees from the kernel drivers that > userspace does not need to worry about luminance flickering. > > Unless you would deem all hardware that can exhibit luminance > flickering as faulty and unsupported? > > We need a baseline default expectation. You can modify that expectation > later with new properties, but I believe something needs to be defined > as the default. Even if the definition is really just "hardware takes > care of not flickering". > In general I would imagine that most future VRR features would end up as new properties. Anything that's purely software could be implemented as a drm helper that every driver can use. I think the target presentation timestamp feature is a good example for that. >>> >>> Speaking of timestamps. What is the expected behaviour of vblank >>> timestamps when vrr is enabled? >>> >> >> When vrr is enabled the duration of the vertical front porch will be >> extended until flip or timeout occurs. The vblank timestamp will vary >> based on duration of the vertical front porch. The min/max duration for >> the front porch can be specified by the driver via the min/max range. > > ...This is actually useful information, it explains things. Do all VRR > hardware implementations fundamentally work like this? > > With that definition, there is only more parameter to be exposed to > userspace in the future: what is the length of the timeout? No need to > expose maximum-refresh-freq because that information is already present > in the programmed video mode. > > Btw. even this definition does not give any hint about problems like > the luminance flickering. If possible flickering is an issue that > cannot
Re: [PATCH v2 3/4] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
On Fri, Oct 26, 2018 at 04:35:48PM -0400, Lyude Paul wrote:
> It occurred to me that we never actually check this! So let's start
> doing that.
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
One thought on testing all this: I think long term some unti tests, where
we have a fake driver doing fake mst branch/ports and a bunch of
allocations and then checking that it all works and validates would be
nice. Longer term project ofc, and maybe after Kunit has been merged ...
-Daniel
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index dcfab7536914..8bb03700e199 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -3238,7 +3238,7 @@ int drm_dp_mst_atomic_check(struct
> drm_dp_mst_topology_state *state)
> {
> struct drm_dp_mst_topology_mgr *mgr = state->mgr;
> struct drm_dp_vcpi_allocation *pos;
> - int avail_slots = 63;
> + int avail_slots = 63, payload_count = 0;
>
> list_for_each_entry(pos, >vcpis, next) {
> DRM_DEBUG_ATOMIC("[MST PORT:%p] requires %d vcpi slots\n",
> @@ -3251,6 +3251,12 @@ int drm_dp_mst_atomic_check(struct
> drm_dp_mst_topology_state *state)
>avail_slots + pos->vcpi);
> return -ENOSPC;
> }
> +
> + if (++payload_count > mgr->max_payloads) {
> + DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many
> payloads (max=%d)\n",
> + mgr, state, mgr->max_payloads);
> + return -EINVAL;
> + }
> }
> DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p vcpi avail=%d used=%d\n",
>mgr, state, avail_slots, 63 - avail_slots);
> --
> 2.17.2
>
--
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 v2 2/4] drm/dp_mst: Start tracking per-port VCPI allocations
On Fri, Oct 26, 2018 at 04:35:47PM -0400, Lyude Paul wrote:
> There has been a TODO waiting for quite a long time in
> drm_dp_mst_topology.c:
>
> /* We cannot rely on port->vcpi.num_slots to update
>* topology_state->avail_slots as the port may not exist if the parent
>* branch device was unplugged. This should be fixed by tracking
>* per-port slot allocation in drm_dp_mst_topology_state instead of
>* depending on the caller to tell us how many slots to release.
>*/
>
> That's not the only reason we should fix this: forcing the driver to
> track the VCPI allocations throughout a state's atomic check is
> error prone, because it means that extra care has to be taken with the
> order that drm_dp_atomic_find_vcpi_slots() and
> drm_dp_atomic_release_vcpi_slots() are called in in order to ensure
> idempotency. Currently the only driver actually using these helpers,
> i915, doesn't even do this correctly: multiple ->best_encoder() checks
> with i915's current implementation would not be idempotent and would
> over-allocate VCPI slots, something I learned trying to implement
> fallback retraining in MST.
>
> So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots()
> and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for
> each port. This allows us to ensure idempotency without having to rely
> on the driver as much. Additionally: the driver doesn't need to do any
> kind of VCPI slot tracking anymore if it doesn't need it for it's own
> internal state.
>
> Additionally; this adds a new drm_dp_mst_atomic_check() helper which
> must be used by atomic drivers to perform validity checks for the new
> VCPI allocations incurred by a state.
>
> Also: update the documentation and make it more obvious that these
> /must/ be called by /all/ atomic drivers supporting MST.
>
> Changes since v1:
> - Don't use the now-removed ->atomic_check() for private objects hook,
>just give drivers a function to call themselves
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 190 +-
> drivers/gpu/drm/i915/intel_display.c | 8 ++
> drivers/gpu/drm/i915/intel_dp_mst.c | 31 +++--
> include/drm/drm_dp_mst_helper.h | 11 +-
> 4 files changed, 192 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 8c3cfac437f4..dcfab7536914 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2614,21 +2614,33 @@ static int drm_dp_init_vcpi(struct
> drm_dp_mst_topology_mgr *mgr,
> }
>
> /**
> - * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
> + * drm_dp_atomic_find_vcpi_slots() - Find and add VCPI slots to the state
> * @state: global atomic state
> * @mgr: MST topology manager for the port
> * @port: port to find vcpi slots for
> * @pbn: bandwidth required for the mode in PBN
> *
> + * Allocates VCPI slots to @port, replacing any previous VCPI allocations it
> + * may have had. Any atomic drivers which support MST must call this function
> + * in their atomic_check() handlers to change the current VCPI allocation for
Maybe do a nice kerneldoc reference to the right atomic_check here.
> + * the new state. After the ->atomic_check() hooks of the driver and all
> other
This will upset the kerneldoc parser I think.
> + * mode objects in the state have been called, DRM will check the final VCPI
> + * allocations to ensure that they will fit into the available bandwidth on
> + * the topology.
> + *
> + * See also: drm_dp_atomic_release_vcpi_slots()
Also need to reference drm_dp_mst_atomic_check() here and that drivers
must call it or nothing happens.
> + *
> * RETURNS:
> - * Total slots in the atomic state assigned for this port or error
> + * Total slots in the atomic state assigned for this port, or a negative
> error
> + * code if the port no longer exists
> */
> int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
> struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_port *port, int pbn)
> {
> struct drm_dp_mst_topology_state *topology_state;
> - int req_slots;
> + struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
> + int prev_slots, req_slots, ret;
>
> topology_state = drm_atomic_get_mst_topology_state(state, mgr);
> if (IS_ERR(topology_state))
> @@ -2637,20 +2649,41 @@ int drm_dp_atomic_find_vcpi_slots(struct
> drm_atomic_state *state,
> port = drm_dp_get_validated_port_ref(mgr, port);
> if (port == NULL)
> return -EINVAL;
> - req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> - DRM_DEBUG_KMS("vcpi slots req=%d, avail=%d\n",
> - req_slots, topology_state->avail_slots);
>
> - if (req_slots > topology_state->avail_slots) {
> -
Re: [PATCH v6 7/7] drm/rockchip: dsi: add dual mipi support
On 01.10.2018 14:38, Heiko Stuebner wrote:
> Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
> As described in the general dual-dsi devicetree binding, the panel should
> define two input ports and point each of them to one of the used dsi-
> controllers, as well as declare one of them as clock-master.
> This is used to determine the dual-dsi state and get access to both
> controller instances.
>
> v6:
> handle master+slave component in dsi-attach
> v5:
> use driver-internal mechanism to find dual dsi slave
> v4:
> add component directly in probe when adding empty dsi slave controller
>
> Signed-off-by: Heiko Stuebner
This is not what I really like (putting dual display functionality into
poor dsi driver), but it at least works.
So:
Reviewed-by: Andrzej Hajda
The patchset is quite long on the list so if there will be no objections
I will merge it tomorrow.
--
Regards
Andrzej
> ---
> .../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 136 ++
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 1 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 +
> drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
> 5 files changed, 145 insertions(+)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index b3aae8439aa3..63b028602d08 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -218,6 +218,10 @@ struct dw_mipi_dsi_rockchip {
> struct clk *grf_clk;
> struct clk *phy_cfg_clk;
>
> + /* dual-channel */
> + bool is_slave;
> + struct dw_mipi_dsi_rockchip *slave;
> +
> unsigned int lane_mbps; /* per lane */
> u16 input_div;
> u16 feedback_div;
> @@ -226,6 +230,7 @@ struct dw_mipi_dsi_rockchip {
> struct dw_mipi_dsi *dmd;
> const struct rockchip_dw_dsi_chip_data *cdata;
> struct dw_mipi_dsi_plat_data pdata;
> + int devcnt;
> };
>
> struct dphy_pll_parameter_map {
> @@ -602,6 +607,8 @@ dw_mipi_dsi_encoder_atomic_check(struct drm_encoder
> *encoder,
> }
>
> s->output_type = DRM_MODE_CONNECTOR_DSI;
> + if (dsi->slave)
> + s->output_flags = ROCKCHIP_OUTPUT_DSI_DUAL;
>
> return 0;
> }
> @@ -617,6 +624,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
> *encoder)
> return;
>
> pm_runtime_get_sync(dsi->dev);
> + if (dsi->slave)
> + pm_runtime_get_sync(dsi->slave->dev);
>
> /*
>* For the RK3399, the clk of grf must be enabled before writing grf
> @@ -630,6 +639,8 @@ static void dw_mipi_dsi_encoder_enable(struct drm_encoder
> *encoder)
> }
>
> dw_mipi_dsi_rockchip_config(dsi, mux);
> + if (dsi->slave)
> + dw_mipi_dsi_rockchip_config(dsi->slave, mux);
>
> clk_disable_unprepare(dsi->grf_clk);
> }
> @@ -638,6 +649,8 @@ static void dw_mipi_dsi_encoder_disable(struct
> drm_encoder *encoder)
> {
> struct dw_mipi_dsi_rockchip *dsi = to_dsi(encoder);
>
> + if (dsi->slave)
> + pm_runtime_put(dsi->slave->dev);
> pm_runtime_put(dsi->dev);
> }
>
> @@ -673,14 +686,113 @@ static int rockchip_dsi_drm_create_encoder(struct
> dw_mipi_dsi_rockchip *dsi,
> return 0;
> }
>
> +static struct device
> +*dw_mipi_dsi_rockchip_find_second(struct dw_mipi_dsi_rockchip *dsi)
> +{
> + const struct of_device_id *match;
> + struct device_node *node = NULL, *local;
> +
> + match = of_match_device(dsi->dev->driver->of_match_table, dsi->dev);
> +
> + local = of_graph_get_remote_node(dsi->dev->of_node, 1, 0);
> + if (!local)
> + return NULL;
> +
> + while ((node = of_find_compatible_node(node, NULL,
> +match->compatible))) {
> + struct device_node *remote;
> +
> + /* found ourself */
> + if (node == dsi->dev->of_node)
> + continue;
> +
> + remote = of_graph_get_remote_node(node, 1, 0);
> + if (!remote)
> + continue;
> +
> + /* same display device in port1-ep0 for both */
> + if (remote == local) {
> + struct dw_mipi_dsi_rockchip *dsi2;
> + struct platform_device *pdev;
> +
> + pdev = of_find_device_by_node(node);
> +
> + /*
> + * we have found the second, so will either return it
> + * or return with an error. In any case won't need the
> + * nodes anymore nor continue the loop.
> + */
> + of_node_put(remote);
> + of_node_put(node);
> + of_node_put(local);
> +
> + if (!pdev)
> + return
Re: [PATCH v2 4/4] drm/nouveau: Use atomic VCPI helpers for MST
On Fri, Oct 26, 2018 at 04:35:49PM -0400, Lyude Paul wrote:
> Currently, nouveau uses the yolo method of setting up MST displays: it
> uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
> display configuration. These helpers don't take care to make sure they
> take a reference to the mstb port that they're checking, and
> additionally don't actually check whether or not the topology still has
> enough bandwidth to provide the VCPI tokens required.
>
> So, drop usage of the old helpers and move entirely over to the atomic
> helpers.
>
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 54 +
> 1 file changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 6cbbae3f438b..37503319e5b1 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -747,16 +747,22 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state *conn_state)
> {
> - struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
> + struct drm_atomic_state *state = crtc_state->state;
> + struct drm_connector *connector = conn_state->connector;
> + struct nv50_mstc *mstc = nv50_mstc(connector);
> struct nv50_mstm *mstm = mstc->mstm;
> - int bpp = conn_state->connector->display_info.bpc * 3;
> + int bpp = connector->display_info.bpc * 3;
> int slots;
>
> - mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
> -
> - slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
> - if (slots < 0)
> - return slots;
> + mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
> + bpp);
> + /* Zombies don't need VCPI */
> + if (!drm_connector_is_unregistered(connector)) {
> + slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
> + mstc->port, mstc->pbn);
> + if (slots < 0)
> + return slots;
> + }
>
> return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
> mstc->native);
> @@ -920,12 +926,38 @@ nv50_mstc_get_modes(struct drm_connector *connector)
> return ret;
> }
>
> +static int
> +nv50_mstc_atomic_check(struct drm_connector *connector,
> +struct drm_connector_state *new_conn_state)
> +{
> + struct drm_atomic_state *state = new_conn_state->state;
> + struct nv50_mstc *mstc = nv50_mstc(connector);
> + struct drm_dp_mst_topology_mgr *mgr = >mstm->mgr;
> + struct drm_connector_state *old_conn_state;
> + struct drm_crtc *old_crtc;
> +
> + old_conn_state = drm_atomic_get_old_connector_state(state, connector);
> + old_crtc = old_conn_state->crtc;
> +
> + /* We only need to release VCPI here if we're going from having a CRTC
> + * on this connector, to not having one
> + */
> + if (!old_crtc || new_conn_state->crtc)
> + return 0;
> +
> + /* Release the previous VCPI allocation since the encoder's
> + * atomic_check() won't be called
> + */
> + return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
> +}
> +
> static const struct drm_connector_helper_funcs
> nv50_mstc_help = {
> .get_modes = nv50_mstc_get_modes,
> .mode_valid = nv50_mstc_mode_valid,
> .best_encoder = nv50_mstc_best_encoder,
> .atomic_best_encoder = nv50_mstc_atomic_best_encoder,
> + .atomic_check = nv50_mstc_atomic_check,
> };
>
> static enum drm_connector_status
> @@ -2084,6 +2116,8 @@ nv50_disp_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> struct drm_connector *connector;
> struct drm_crtc_state *new_crtc_state;
> struct drm_crtc *crtc;
> + struct drm_dp_mst_topology_mgr *mgr;
> + struct drm_dp_mst_topology_state *mst_state;
> int ret, i;
>
> /* We need to handle colour management on a per-plane basis. */
> @@ -2109,6 +2143,12 @@ nv50_disp_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> return ret;
> }
>
> + for_each_new_mst_mgr_in_state(state, mgr, mst_state, i) {
> + ret = drm_dp_mst_atomic_check(mst_state);
> + if (ret)
> + return ret;
> + }
For even less code I think you could also push this loop into the helpers.
I can't come up with any scenario where a driver does not want to check
all of them at the same time in the atomic_check sequence.
Otherwise lgtm.
-Daniel
> +
> return 0;
> }
>
> --
> 2.17.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Re: [PATCH v2 1/4] drm/dp_mst: Add some atomic state iterator macros
On Fri, Oct 26, 2018 at 04:35:46PM -0400, Lyude Paul wrote:
> Signed-off-by: Lyude Paul
> Cc: Daniel Vetter
> ---
> include/drm/drm_dp_mst_helper.h | 77 +
> 1 file changed, 77 insertions(+)
>
> diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
> index 59f005b419cf..3faceb66f5cb 100644
> --- a/include/drm/drm_dp_mst_helper.h
> +++ b/include/drm/drm_dp_mst_helper.h
> @@ -628,4 +628,81 @@ int drm_dp_atomic_release_vcpi_slots(struct
> drm_atomic_state *state,
> int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr *mgr,
>struct drm_dp_mst_port *port, bool power_up);
>
> +extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
> +
> +static inline bool
> +__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
> + struct drm_dp_mst_topology_mgr **mgr,
> + struct drm_dp_mst_topology_state **old_state,
> + struct drm_dp_mst_topology_state **new_state,
> + int i)
> +{
> + struct __drm_private_objs_state *objs_state = >private_objs[i];
> +
> + if (objs_state->ptr->funcs != _dp_mst_topology_state_funcs)
> + return false;
> +
> + *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
> + if (old_state)
> + *old_state = to_dp_mst_topology_state(objs_state->old_state);
> + if (new_state)
> + *new_state = to_dp_mst_topology_state(objs_state->new_state);
> +
> + return true;
> +}
> +
> +/**
> + * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
> + * managers in an atomic update
> + * @__state: drm_atomic_state pointer
> + * @mgr: drm_dp_mst_topology_mgr iteration cursor
> + * @old_state: drm_dp_mst_topology_state iteration cursor for the old
> + * state
> + * @new_state: drm_dp_mst_topology_state iteration cursor for the new
> + * state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all DRM DP MST topology managers in an atomic update,
> + * tracking both old and new state. This is useful in places where the state
> + * delta needs to be considered, for example in atomic check functions.
> + */
> +#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state,
> __i) \
> + for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
> + for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
> &(old_state), &(new_state), (__i)))
I just realized that all our iterator macros do not compose at all. Whic
is rather disappointing :-/
list_for_each solves that with a list_for_each_member, which you can then
easily use to create more specialized macros. I wonder whether we should
have a master macros, which also takes the obj type (we have very uniform
naming, so a few well placed ## should make this work neatly), and then
you could just #define more specialized iterators without having to retype
them (or the need for dummy iterator markers and tons of casting).
Anyway, that's a lament for another day This looks good.
Reviewed-by: Daniel Vetter
> +
> +/**
> + * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
> + * in an atomic update
> + * @__state: drm_atomic_state pointer
> + * @mgr: drm_dp_mst_topology_mgr iteration cursor
> + * @old_state: drm_dp_mst_topology_state iteration cursor for the old
> + * state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all DRM DP MST topology managers in an atomic update,
> + * tracking only the old state. This is useful in disable functions, where we
> + * need the old state the hardware is still in.
> + */
> +#define for_each_old_mst_mgr_in_state(__state, mgr, old_state, __i) \
> + for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
> + for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
> &(old_state), NULL, (__i)))
> +
> +/**
> + * for_each_new_mst_mgr_in_state - iterate over all DP MST topology managers
> + * in an atomic update
> + * @__state: drm_atomic_state pointer
> + * @mgr: drm_dp_mst_topology_mgr iteration cursor
> + * @new_state: drm_dp_mst_topology_state iteration cursor for the new
> + * state
> + * @__i: int iteration cursor, for macro-internal use
> + *
> + * This iterates over all DRM DP MST topology managers in an atomic update,
> + * tracking only the new state. This is useful in enable functions, where we
> + * need the new state the hardware should be in when the atomic commit
> + * operation has completed.
> + */
> +#define for_each_new_mst_mgr_in_state(__state, mgr, new_state, __i) \
> + for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
> + for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr),
> NULL, &(new_state), (__i)))
> +
> #endif
> --
> 2.17.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 108096] [amd-staging-drm-next] SDDM screen corruption (not usable) with RX580, amdgpu, dc=1 (of course), regression - [bisected]
https://bugs.freedesktop.org/show_bug.cgi?id=108096 --- Comment #19 from Andrey Grodzovsky --- (In reply to Michel Dänzer from comment #18) > Andrey, can you work with Dieter to figure out where the error is coming > from? E.g. by attaching patches adding debugging printks. Yes, i will look into it. -- 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: [RFC] drm/vkms: Add writeback support
On 10/24, Brian Starkey wrote:
> Hi Rodrigo,
Hi Brian,
Thanks a lot for your feedback! I learned a lot with all of them :)
I will work for make a real PATCH soon.
Again, thanks a lot.
Best Regards
> On Mon, Oct 22, 2018 at 09:27:18AM -0300, Rodrigo Siqueira wrote:
> >Hi,
> >
> >I started to work for add the writeback feature into the VKMS, and this
> >RFC represents my first draft. As a result, I have some questions which
> >I list below.
> >
> >1. In this patch, I replaced the virtual connector by the writeback
> >connector. Is it a good idea? Or should I keep both connectors? If I
> >keep both connectors, should I add a module parameter to enable the
> >writeback?
> >
> >2. When I added the writeback connector (in
> >drm_writeback_connector_init()), I noticed that I had to indicate the
> >struct drm_encoder_helper_funcs. However, I think that VKMS does not
> >need anything sophisticated related to encoders at the writeback
> >perspective. Am I right? Or did I missed something?
> >
> >3. I just discovered that the writeback connectors are not exposed as a
> >connector for the userspace, as a result, IGT tests do not work and
> >Wayland is unable to run as well. Simon Ser and Daniel Stone, explained
> >to me that I have to update the compositor (in my case Weston) to set
> >DRM_CLIENT_CAP_WRITEBACK_CONNECTORS via drmSetClientCap(). Since I do
> >not have experience with userspace, anyone can point me out another
> >aspect that I have to take a look to make the writeback work in the user
> >space? Also, Is it possible to update the IGT test or do I need to
> >create a new set of tests?
>
> Alex added support for writeback connectors into drm_hwcomposer - you
> can see that here[1]
>
> There's also some igt tests like Daniel mentioned - I think Liviu
> already pointed you at those.
>
> Some more review below,
>
> Cheers!
> -Brian
>
> [1]
> https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/3
>
> >
> >Thanks!
> >
> >Signed-off-by: Rodrigo Siqueira
> >---
> > drivers/gpu/drm/vkms/vkms_crc.c| 9 ++-
> > drivers/gpu/drm/vkms/vkms_crtc.c | 2 +
> > drivers/gpu/drm/vkms/vkms_drv.h| 3 +-
> > drivers/gpu/drm/vkms/vkms_output.c | 107 +
> > 4 files changed, 89 insertions(+), 32 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/vkms/vkms_crc.c
> >b/drivers/gpu/drm/vkms/vkms_crc.c
> >index 9d9e8146db90..5d9ac45e00f2 100644
> >--- a/drivers/gpu/drm/vkms/vkms_crc.c
> >+++ b/drivers/gpu/drm/vkms/vkms_crc.c
> >@@ -109,7 +109,8 @@ static void compose_cursor(struct vkms_crc_data
> >*cursor_crc,
> > }
> >
> > static uint32_t _vkms_get_crc(struct vkms_crc_data *primary_crc,
> >- struct vkms_crc_data *cursor_crc)
> >+ struct vkms_crc_data *cursor_crc,
> >+ struct vkms_output *out)
> > {
> > struct drm_framebuffer *fb = _crc->fb;
> > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
> >@@ -130,6 +131,10 @@ static uint32_t _vkms_get_crc(struct vkms_crc_data
> >*primary_crc,
> > }
> >
> > memcpy(vaddr_out, vkms_obj->vaddr, vkms_obj->gem.size);
> >+// TODO: Remove this copy from crc, and make this sort of operation
> >+// generic since we can use in different places
> >+memcpy(out->connector.base.state->writeback_job->fb,
> >+ vkms_obj->vaddr, vkms_obj->gem.size);
>
> This looks like it would crash terribly, you're copying the pixel data
> (from vkms_obj->vaddr) into a "struct drm_framebuffer *" which is a
> pointer to the struct, rather than somewhere to put the actual
> pixels.
>
> The same way you get the vaddr for the input framebuffer, you need to
> get the vaddr for the output framebuffer too - via
> drm_gem_fb_get_obj() and then converting that to a vkms_gem_object.
> Then use that vaddr as the destination of the memcpy. However, see my
> comments at the bottom about drm_writeback_queue_job(). You might be
> better getting and storing the vaddr during atomic_commit(), rather
> than in this function.
>
> In order for this to be a straight memcpy, you need to make sure that
> the input and output buffers have the same size, pixel format, same
> stride etc. as well so you'll need to check that in atomic_check().
> Once it's working you can relax those restrictions by copying a line
> at a time or doing pixel format conversion - but I don't think it's
> necessary to start with.
>
> There might be an opportunity to skip a copy here too - if you have a
> framebuffer attached to the writeback connector, you can skip
> allocating "vaddr_out" and just compose the cursor directly into the
> output framebuffer, and calculate the CRC on that. That's definitely
> an optimisation rather than a requirement though.
>
> > mutex_unlock(_obj->pages_lock);
> >
> > if (cursor_crc)
> >@@ -193,7 +198,7 @@ void vkms_crc_work_handle(struct work_struct *work)
> > }
> >
> > if (primary_crc)
> >-crc32 =
Re: [PATCH] fbcon: Silence fbcon logo on 'quiet' boots
Hi Prarit, Thank you for the patch! Yet something to improve: [auto build test ERROR on sof-driver-fuweitax/master] [also build test ERROR on v4.19 next-20181029] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prarit-Bhargava/fbcon-Silence-fbcon-logo-on-quiet-boots/20181029-211617 base: https://github.com/fuweitax/linux master config: i386-randconfig-x005-201843 (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All error/warnings (new ones prefixed by >>): drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': >> drivers/video/fbdev/core/fbcon.c:655:13: error: invalid storage class for >> function 'set_blitting_type' static void set_blitting_type(struct vc_data *vc, struct fb_info *info) ^ >> drivers/video/fbdev/core/fbcon.c:655:1: warning: ISO C90 forbids mixed >> declarations and code [-Wdeclaration-after-statement] static void set_blitting_type(struct vc_data *vc, struct fb_info *info) ^~ >> drivers/video/fbdev/core/fbcon.c:669:12: error: invalid storage class for >> function 'fbcon_invalid_charcount' static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount) ^~~ >> drivers/video/fbdev/core/fbcon.c:698:12: error: invalid storage class for >> function 'con2fb_acquire_newinfo' static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info, ^~ >> drivers/video/fbdev/core/fbcon.c:734:12: error: invalid storage class for >> function 'con2fb_release_oldinfo' static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo, ^~ >> drivers/video/fbdev/core/fbcon.c:780:13: error: invalid storage class for >> function 'con2fb_init_display' static void con2fb_init_display(struct vc_data *vc, struct fb_info *info, ^~~ >> drivers/video/fbdev/core/fbcon.c:825:12: error: invalid storage class for >> function 'set_con2fb_map' static int set_con2fb_map(int unit, int newidx, int user) ^~ >> drivers/video/fbdev/core/fbcon.c:882:12: error: invalid storage class for >> function 'var_to_display' static int var_to_display(struct display *disp, ^~ >> drivers/video/fbdev/core/fbcon.c:906:13: error: invalid storage class for >> function 'display_to_var' static void display_to_var(struct fb_var_screeninfo *var, ^~ >> drivers/video/fbdev/core/fbcon.c:925:20: error: invalid storage class for >> function 'fbcon_startup' static const char *fbcon_startup(void) ^ >> drivers/video/fbdev/core/fbcon.c:1036:13: error: invalid storage class for >> function 'fbcon_init' static void fbcon_init(struct vc_data *vc, int init) ^~ >> drivers/video/fbdev/core/fbcon.c:1183:13: error: invalid storage class for >> function 'fbcon_free_font' static void fbcon_free_font(struct display *p, bool freefont) ^~~ >> drivers/video/fbdev/core/fbcon.c:1191:13: error: invalid storage class for >> function 'set_vc_hi_font' static void set_vc_hi_font(struct vc_data *vc, bool set); ^~ >> drivers/video/fbdev/core/fbcon.c:1193:13: error: invalid storage class for >> function 'fbcon_deinit' static void fbcon_deinit(struct vc_data *vc) ^~~~ drivers/video/fbdev/core/fbcon.c: In function 'fbcon_deinit': >> drivers/video/fbdev/core/fbcon.c:1229:3: error: implicit declaration of >> function 'set_vc_hi_font'; did you mean 'set_page_zone'? >> [-Werror=implicit-function-declaration] set_vc_hi_font(vc, false); ^~ set_page_zone drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': >> drivers/video/fbdev/core/fbcon.c:1262:13: error: invalid storage class for >> function 'fbcon_clear' static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height, ^~~ >> drivers/video/fbdev/core/fbcon.c:1300:13: error: invalid storage class for >> function 'fbcon_putcs' static void fbcon_putcs(struct vc_data *vc, const unsigned short *s, ^~~ >> drivers/video/fbdev/core/fbcon.c:1313:13: error: invalid storage class for >> function 'fbcon_putc' static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos) ^~ >> drivers/video/fbdev/core/fbcon.c:1321:13: error: invalid storage class for
Re: [PATCH] fbcon: Silence fbcon logo on 'quiet' boots
Hi Prarit, Thank you for the patch! Yet something to improve: [auto build test ERROR on sof-driver-fuweitax/master] [also build test ERROR on v4.19 next-20181029] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prarit-Bhargava/fbcon-Silence-fbcon-logo-on-quiet-boots/20181029-211617 base: https://github.com/fuweitax/linux master config: m68k-multi_defconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All errors (new ones prefixed by >>): drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': drivers/video/fbdev/core/fbcon.c:680:13: error: invalid storage class for function 'set_blitting_type' static void set_blitting_type(struct vc_data *vc, struct fb_info *info) ^ drivers/video/fbdev/core/fbcon.c:680:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] static void set_blitting_type(struct vc_data *vc, struct fb_info *info) ^~ drivers/video/fbdev/core/fbcon.c:690:12: error: invalid storage class for function 'fbcon_invalid_charcount' static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount) ^~~ drivers/video/fbdev/core/fbcon.c:698:12: error: invalid storage class for function 'con2fb_acquire_newinfo' static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info, ^~ drivers/video/fbdev/core/fbcon.c:734:12: error: invalid storage class for function 'con2fb_release_oldinfo' static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo, ^~ drivers/video/fbdev/core/fbcon.c:780:13: error: invalid storage class for function 'con2fb_init_display' static void con2fb_init_display(struct vc_data *vc, struct fb_info *info, ^~~ drivers/video/fbdev/core/fbcon.c:825:12: error: invalid storage class for function 'set_con2fb_map' static int set_con2fb_map(int unit, int newidx, int user) ^~ drivers/video/fbdev/core/fbcon.c:882:12: error: invalid storage class for function 'var_to_display' static int var_to_display(struct display *disp, ^~ drivers/video/fbdev/core/fbcon.c:906:13: error: invalid storage class for function 'display_to_var' static void display_to_var(struct fb_var_screeninfo *var, ^~ drivers/video/fbdev/core/fbcon.c:925:20: error: invalid storage class for function 'fbcon_startup' static const char *fbcon_startup(void) ^ drivers/video/fbdev/core/fbcon.c:1036:13: error: invalid storage class for function 'fbcon_init' static void fbcon_init(struct vc_data *vc, int init) ^~ drivers/video/fbdev/core/fbcon.c:1183:13: error: invalid storage class for function 'fbcon_free_font' static void fbcon_free_font(struct display *p, bool freefont) ^~~ drivers/video/fbdev/core/fbcon.c:1191:13: error: invalid storage class for function 'set_vc_hi_font' static void set_vc_hi_font(struct vc_data *vc, bool set); ^~ drivers/video/fbdev/core/fbcon.c:1193:13: error: invalid storage class for function 'fbcon_deinit' static void fbcon_deinit(struct vc_data *vc) ^~~~ drivers/video/fbdev/core/fbcon.c: In function 'fbcon_deinit': >> drivers/video/fbdev/core/fbcon.c:1229:3: error: implicit declaration of >> function 'set_vc_hi_font'; did you mean 'seq_path_root'? >> [-Werror=implicit-function-declaration] set_vc_hi_font(vc, false); ^~ seq_path_root drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': drivers/video/fbdev/core/fbcon.c:1262:13: error: invalid storage class for function 'fbcon_clear' static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height, ^~~ drivers/video/fbdev/core/fbcon.c:1300:13: error: invalid storage class for function 'fbcon_putcs' static void fbcon_putcs(struct vc_data *vc, const unsigned short *s, ^~~ drivers/video/fbdev/core/fbcon.c:1313:13: error: invalid storage class for function 'fbcon_putc' static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos) ^~ drivers/video/fbdev/core/fbcon.c:1321:13: error: invalid storage class for function 'fbcon_clear_margins' static void fbcon_clear_margins(struct vc_d
Re: [Outreachy kernel] [PATCH 0/6] drm/qxl: Remove checkpatch issues
On Fri, Oct 26, 2018 at 04:20:30PM -0300, Shayenne da Luz Moura wrote:
> This series cleans the following checkpatch.pl issues:
>
> ERROR: trailing whitespace
> WARNING: Missing a blank line after declarations
> CHECK: Please don't use multiple blank lines
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
> ERROR: space required before the open parenthesis '('
> CHECK: Avoid using bool structure members because of possible alignment issues
I looked through the patches, all fine, great work. I've pinged
maintainers and will merge it all as soon as they've acked it.
Assuming you want to continue hacking on gpu drivers, we have a todo list
with more advanced tasks:
https://dri.freedesktop.org/docs/drm/gpu/todo.html
Best to discuss those on #dri-devel irc before getting started, to make
sure scope and all is clear.
Cheers, Daniel
>
> Shayenne da Luz Moura (6):
> drm/qxl: Remove trailing whitespace
> drm/qxl: Add line after variable declarations
> drm/qxl: Remove exceding whiteline
> drm/qxl: Use 'unsigned int' instead of 'usigned'
> drm/qxl: Add space before open parentheses
> drm/qxl: Use 'unsigned int' instead of bool
>
> drivers/gpu/drm/qxl/qxl_cmd.c | 7 +--
> drivers/gpu/drm/qxl/qxl_debugfs.c | 5 ++---
> drivers/gpu/drm/qxl/qxl_dev.h | 1 -
> drivers/gpu/drm/qxl/qxl_display.c | 19 ++-
> drivers/gpu/drm/qxl/qxl_draw.c| 11 ++-
> drivers/gpu/drm/qxl/qxl_drv.h | 31 ++-
> drivers/gpu/drm/qxl/qxl_dumb.c| 3 ++-
> drivers/gpu/drm/qxl/qxl_fb.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_image.c | 4 +++-
> drivers/gpu/drm/qxl/qxl_ioctl.c | 2 ++
> drivers/gpu/drm/qxl/qxl_kms.c | 2 +-
> drivers/gpu/drm/qxl/qxl_object.c | 5 ++---
> drivers/gpu/drm/qxl/qxl_object.h | 2 ++
> drivers/gpu/drm/qxl/qxl_prime.c | 1 -
> drivers/gpu/drm/qxl/qxl_release.c | 1 -
> drivers/gpu/drm/qxl/qxl_ttm.c | 12 +---
> 16 files changed, 56 insertions(+), 54 deletions(-)
>
> --
> 2.19.1
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/outreachy-kernel/cover.1540579956.git.shayenneluzmoura%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
--
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 v2] drm/bridge: analogix_dp: Fix misleading indentation reported by smatch
On 16.10.2018 11:53, Enric Balletbo i Serra wrote: > This patch avoids that building the bridge/analogix source code with > smatch triggers complaints about inconsistent indenting. It also fixes > a typo in DRM_ERROR message, attch is replaced for attach. > > Signed-off-by: Enric Balletbo i Serra > Reviewed-by: Laurent Pinchart Queued to drm-misc-next. Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vgem: create a render node for vgem
On Mon, Oct 29, 2018 at 12:03:46PM +, Emil Velikov wrote: > On Fri, 26 Oct 2018 at 14:40, Daniel Vetter wrote: > > > > On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > VGEM doesn't do anything modeset specific, so in a way exposing a > > > primary node is 'wrong'. At the same time, we extensively use if for > > > creating dumb buffers, fences, prime fd <> handle imports/exports. > > > > > > To the point that we explicitly annotate the vgem fence ioctls as > > > DRM_RENDER_ALLOW and have an IGT test which opens the render node. > > > > > > close(drm_open_driver_render(DRIVER_VGEM)) > > > > Huh, I guess that test doesn't pass? > > > It does since the IGT code seems bonkers... Namely it silently falls > back to the primary/card node. > It seems to be for historical reasons... back in the days where render > nodes were still experimental and had to be explicitly enabled via > kernel arg. > > I'll try and follow-up to address that. I guess enforcing this with igt is a bit harder, since not much with render nodes is generic across drivers. Hence a lot of the tests are very specific. But anything we can increase the odds for people using render nodes is good I guess, and if it's just using vgem as a driver copypaste template. -Daniel > > > > Better late than never, let's flip the switch. > > > > > > Cc: David Airlie > > > Cc: Daniel Vetter > > > Signed-off-by: Emil Velikov > > > > Acked-by: Daniel Vetter > > Thanks. I'll give it a few more days for others to review/comment. > > -Emil -- 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: [RFC PATCH] drm/vc4: Add a load tracker to prevent HVS underflow errors
On Mon, Oct 29, 2018 at 10:10:56AM +0100, Boris Brezillon wrote: > On Mon, 29 Oct 2018 10:03:01 +0100 > Daniel Vetter wrote: > > On Mon, Oct 29, 2018 at 09:41:36AM +0100, Boris Brezillon wrote: > > > On Mon, 29 Oct 2018 09:06:40 +0100 > > > > The other upshot of a counter is that there's no problem with resetting. > > > > Userspace simply grabs the counter before and after the test and > > > > compares. > > > > If you only have 0/1 you need some way to reset, or otherwise automated > > > > running in a CI farm isn't possible. > > > > > > The reset was done during atomic commit in my proposal, so no action > > > was required on the user side apart from applying a new config. > > > Anyway, I'll change that for a real counter. > > > > We want to measure underruns while doing full modesets too (specifically, > > when shutting down the pipeline). At least for our hw this has > > historically helped greatly in catching programming sequence issues. > > Looks like you have particular needs for intel HW which I don't know > about, maybe I shouldn't be the one driving this rework... No one is expecting you do drive i915 work, we just want to make sure that whatever you come up for igt tests is generally useful, and not just only for the limited use case of vc4. Atm the only two drivers interested in underrun reporting are i915 and vc4, and it looks like they span a pretty broad spectrum alredy. -Daniel -- 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: [RFC] Allow fd.o to join forces with X.Org
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote: > On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: > >> > >> Hi, > >> > >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: > >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone > > wrote: > >> Yeah, I think it makes sense. Some things we do: > >> - provide hosted network services for collaborative development, > >> testing, and discussion, of open-source projects > >> - administer, improve, and extend this suite of services as necessary > >> - assist open-source projects in their use of these services > >> - purchase, lease, or subscribe to, computing and networking > >> infrastructure allowing these services to be run > > > > I fully agree that we should document all this. I don't think the > > bylaws are the right place though, much better to put that into > > policies that the board approves and which can be adapted as needed. > > Imo bylaws should cover the high-level mission and procedural details, > > as our "constitution", with the really high acceptance criteria of > > 2/3rd of all members approving any changes. Some of the early > > discussions tried to spell out a lot of the fd.o policies in bylaw > > changes, but then we realized it's all there already. All the details > > are much better served in policies enacted by the board, like we do > > with everything else. > > > > As an example, let's look at XDC. Definitely one of the biggest things > > the foundation does, with handling finances, travel sponsoring grants, > > papers committee, and acquiring lots of sponsors. None of this is > > spelled out in the bylaws, it's all in policies that the board > > deliberates and approves. I think this same approach will also work > > well for fd.o. > > > > And if members are unhappy with what the board does, they can fix in > > the next election by throwing out the unwanted directors. > > yeah, fair call. though IMO in that case we can just reduce to > > \item Support free and open source projects through the > freedesktop.org > infrastructure. > > because my gripe is less with the fdo bit but more with defining what > "project hosting" means, given that we use that term to exclude fdo > projects > from getting anything else. I think just dropping that bit is sufficient. > >>> > >>> Hm yeah, through the lens of "everything not explicitly listed isn't in > >>> scope as X.org's purpose", leaving this out is probably clearest. And > >>> under 2.4 (i) the board already has the duty to interpret what exactly > >>> this means wrt membership eligibility. > >>> > >>> Harry, Daniel, what do you think? > >> > >> Yeah, that's fine. I didn't specifically want the enumerated list of > >> what we do in the bylaws, just spelling it out for background as a > >> handy reference I could point to later. I think maybe we could reduce > >> it to something like: > >> Administer, support, and improve the freedesktop.org hosting > >> infrastructure to support the projects it hosts > > > > This feels a bit self-referential, not the best for the purpose of > > what X.org does. If we do want to be a bit more specific we could do > > something like with (i) and provide a list that the board can extend: > > > > \item Support free and open source projects through the freedesktop.org > > infrastructure. This includes, but is not limited to: > > Administering and providing > > project hosting services. > > > > I like this phrasing, but won't that bring us back to David Hutterer's > point about defining what "project hosting services" means? > > Personally I think "project hosting" is quite clear and shouldn't need to be > defined. I think it's less tricky, since we no longer use it to exclude services and support. It makes it much more clear that defining the details is all up to the board, with just a rough guideline of what should be included. Peter? -Daniel > > Harry > > > That would make it clear that admins are in scope, and > > everything else is up to the board. Similar to how drm, mesa, wayland > > and X are explicitly in scope, and stuff like cros/android gfx stack > > or libinput is up to the board to decide/clarify. > > > >> Gives us enough scope to grow in the future (e.g. we don't need a > >> bylaws change to move from pure-git to GitLab), avoids the sticky > >> question of what exactly fd.o hosts in the bylaws (e.g. if > >> NetworkManager needs a new repo then we don't have to consult > >> membership to add it), but is still pretty firmly limited in scope. > >> > >> Any of the above have my in-principle ack though, I think they're all > >> reasonable
[PATCH v3] drm/bochs: add edid support.
Recent qemu (latest master branch, upcoming 3.1 release) got support
for EDID data. This patch adds guest driver support.
EDID support in qemu is not (yet) enabled by default, so please use
'qemu -device VGA,edid=on' for testing.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs.h | 1 +
drivers/gpu/drm/bochs/bochs_hw.c | 39 +++
drivers/gpu/drm/bochs/bochs_kms.c | 18 +++---
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index e7a69077e4..06b8166efa 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -66,6 +66,7 @@ struct bochs_device {
u16 yres_virtual;
u32 stride;
u32 bpp;
+ struct edid *edid;
/* drm */
struct drm_device *dev;
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c
index cacff73a64..db4afe94c5 100644
--- a/drivers/gpu/drm/bochs/bochs_hw.c
+++ b/drivers/gpu/drm/bochs/bochs_hw.c
@@ -69,6 +69,41 @@ static void bochs_hw_set_little_endian(struct bochs_device
*bochs)
#define bochs_hw_set_native_endian(_b) bochs_hw_set_little_endian(_b)
#endif
+static int bochs_load_edid(struct bochs_device *bochs)
+{
+ uint8_t *blob;
+ size_t i, len;
+ uint8_t num_exts;
+
+ if (!bochs->mmio)
+ return -1;
+
+ if ((readb(bochs->mmio+0) != 0x00 ||
+readb(bochs->mmio+1) != 0xff))
+ return -1;
+
+ num_exts = readb(bochs->mmio + 126);
+ len = EDID_LENGTH * (1 + num_exts);
+ if (len > 0x400 /* vga register offset */)
+ return -1;
+
+ kfree(bochs->edid);
+ bochs->edid = kmalloc(len, GFP_KERNEL);
+ blob = (void *)bochs->edid;
+ for (i = 0; i < len; i++) {
+ blob[i] = readb(bochs->mmio+i);
+ }
+
+ if (!drm_edid_is_valid(bochs->edid)) {
+ DRM_ERROR("EDID is not valid, ignoring.\n");
+ kfree(bochs->edid);
+ bochs->edid = NULL;
+ return -1;
+ }
+
+ return 0;
+}
+
int bochs_hw_init(struct drm_device *dev)
{
struct bochs_device *bochs = dev->dev_private;
@@ -150,6 +185,9 @@ int bochs_hw_init(struct drm_device *dev)
}
noext:
+ if (bochs_load_edid(bochs) == 0)
+ DRM_INFO("Found EDID data blob.\n");
+
return 0;
}
@@ -164,6 +202,7 @@ void bochs_hw_fini(struct drm_device *dev)
if (bochs->fb_map)
iounmap(bochs->fb_map);
pci_release_regions(dev->pdev);
+ kfree(bochs->edid);
}
void bochs_hw_setmode(struct bochs_device *bochs,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 9bc5b438ae..b9931443a7 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -213,10 +213,17 @@ static void bochs_encoder_init(struct drm_device *dev)
static int bochs_connector_get_modes(struct drm_connector *connector)
{
- int count;
+ struct bochs_device *bochs =
+ container_of(connector, struct bochs_device, connector);
+ int count = 0;
- count = drm_add_modes_noedid(connector, 8192, 8192);
- drm_set_preferred_mode(connector, defx, defy);
+ if (bochs->edid)
+ count = drm_add_edid_modes(connector, bochs->edid);
+
+ if (!count) {
+ count = drm_add_modes_noedid(connector, 8192, 8192);
+ drm_set_preferred_mode(connector, defx, defy);
+ }
return count;
}
@@ -271,6 +278,11 @@ static void bochs_connector_init(struct drm_device *dev)
drm_connector_helper_add(connector,
_connector_connector_helper_funcs);
drm_connector_register(connector);
+
+ if (bochs->edid) {
+ drm_connector_attach_edid_property(connector);
+ drm_connector_update_edid_property(connector, bochs->edid);
+ }
}
--
2.9.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: >> >> Hi, >> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote: >> Yeah, I think it makes sense. Some things we do: >> - provide hosted network services for collaborative development, >> testing, and discussion, of open-source projects >> - administer, improve, and extend this suite of services as necessary >> - assist open-source projects in their use of these services >> - purchase, lease, or subscribe to, computing and networking >> infrastructure allowing these services to be run > > I fully agree that we should document all this. I don't think the > bylaws are the right place though, much better to put that into > policies that the board approves and which can be adapted as needed. > Imo bylaws should cover the high-level mission and procedural details, > as our "constitution", with the really high acceptance criteria of > 2/3rd of all members approving any changes. Some of the early > discussions tried to spell out a lot of the fd.o policies in bylaw > changes, but then we realized it's all there already. All the details > are much better served in policies enacted by the board, like we do > with everything else. > > As an example, let's look at XDC. Definitely one of the biggest things > the foundation does, with handling finances, travel sponsoring grants, > papers committee, and acquiring lots of sponsors. None of this is > spelled out in the bylaws, it's all in policies that the board > deliberates and approves. I think this same approach will also work > well for fd.o. > > And if members are unhappy with what the board does, they can fix in > the next election by throwing out the unwanted directors. yeah, fair call. though IMO in that case we can just reduce to \item Support free and open source projects through the freedesktop.org infrastructure. because my gripe is less with the fdo bit but more with defining what "project hosting" means, given that we use that term to exclude fdo projects from getting anything else. I think just dropping that bit is sufficient. >>> >>> Hm yeah, through the lens of "everything not explicitly listed isn't in >>> scope as X.org's purpose", leaving this out is probably clearest. And >>> under 2.4 (i) the board already has the duty to interpret what exactly >>> this means wrt membership eligibility. >>> >>> Harry, Daniel, what do you think? >> >> Yeah, that's fine. I didn't specifically want the enumerated list of >> what we do in the bylaws, just spelling it out for background as a >> handy reference I could point to later. I think maybe we could reduce >> it to something like: >> Administer, support, and improve the freedesktop.org hosting >> infrastructure to support the projects it hosts > > This feels a bit self-referential, not the best for the purpose of > what X.org does. If we do want to be a bit more specific we could do > something like with (i) and provide a list that the board can extend: > > \item Support free and open source projects through the freedesktop.org > infrastructure. This includes, but is not limited to: > Administering and providing > project hosting services. > I like this phrasing, but won't that bring us back to David Hutterer's point about defining what "project hosting services" means? Personally I think "project hosting" is quite clear and shouldn't need to be defined. Harry > That would make it clear that admins are in scope, and > everything else is up to the board. Similar to how drm, mesa, wayland > and X are explicitly in scope, and stuff like cros/android gfx stack > or libinput is up to the board to decide/clarify. > >> Gives us enough scope to grow in the future (e.g. we don't need a >> bylaws change to move from pure-git to GitLab), avoids the sticky >> question of what exactly fd.o hosts in the bylaws (e.g. if >> NetworkManager needs a new repo then we don't have to consult >> membership to add it), but is still pretty firmly limited in scope. >> >> Any of the above have my in-principle ack though, I think they're all >> reasonable colours for our lovely shed. > > Well, one more bikeshed from me! > > Cheers, Daniel > >> >> Cheers, >> Daniel > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/sun4i: hdmi: Fix double flag assignation
On Wed, Oct 24, 2018 at 10:43:34AM +0200, Giulio Benetti wrote:
> Il 21/10/2018 18:34, Maxime Ripard ha scritto:
> > The is_double flag is a boolean currently assigned to the value of the d
> > variable, that is either 1 or 2. It means that this is_double variable is
> > always set to true, even though the initial intent was to have it set to
> > true when d is 2.
> >
> > Fix this.
> >
> > Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
> > Reported-by: Dan Carpenter
> > Signed-off-by: Maxime Ripard
>
> Reviewed-by: Giulio Benetti
Applied both, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbcon: Silence fbcon logo on 'quiet' boots
A variant of this patch has been in Fedora since at least 2010 and
AFAWCT there haven't been any complaints about the change in behavior.
https://src.fedoraproject.org/cgit/rpms/kernel.git/tree/silence-fbcon-logo.patch
P.
---8<---
On text-based systems the 'quiet' boot option will show printk levels
higher than CONSOLE_LOGLEVEL_QUIET. The displaying of the Tux logo
during boot can cause some consoles to lose display data and as a result
confuse the end user.
Do not display the Tux logo on systems that are in 'quiet' boot.
Signed-off-by: Prarit Bhargava
Cc: Hans de Goede
Cc: Marko Myllynen
Cc: Bartlomiej Zolnierkiewicz
Cc: Kees Cook
Cc: Daniel Vetter
Cc: Thierry Reding
Cc: Yisheng Xie
Cc: dri-devel@lists.freedesktop.org
Cc: Steven Rostedt (VMware)
---
drivers/video/fbdev/core/fbcon.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 75ebbbf0a1fb..a2f2c7ea11ef 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -650,11 +650,14 @@ static void fbcon_prepare_logo(struct vc_data *vc, struct
fb_info *info,
kfree(save);
}
+ if (logo_shown == FBCON_LOGO_DONTSHOW) {
+ return;
+
if (logo_lines > vc->vc_bottom) {
logo_shown = FBCON_LOGO_CANSHOW;
printk(KERN_INFO
"fbcon_init: disable boot-logo (boot-logo bigger than
screen).\n");
- } else if (logo_shown != FBCON_LOGO_DONTSHOW) {
+ } else {
logo_shown = FBCON_LOGO_DRAW;
vc->vc_top = logo_lines;
}
@@ -1052,7 +1055,7 @@ static void fbcon_init(struct vc_data *vc, int init)
struct vc_data **default_mode = vc->vc_display_fg;
struct vc_data *svc = *default_mode;
struct display *t, *p = _display[vc->vc_num];
- int logo = 1, new_rows, new_cols, rows, cols, charcnt = 256;
+ int new_rows, new_cols, rows, cols, charcnt = 256;
int cap, ret;
if (info_idx == -1 || info == NULL)
@@ -1060,9 +1063,9 @@ static void fbcon_init(struct vc_data *vc, int init)
cap = info->flags;
- if (vc != svc || logo_shown == FBCON_LOGO_DONTSHOW ||
+ if (vc != svc || console_loglevel <= CONSOLE_LOGLEVEL_QUIET ||
(info->fix.type == FB_TYPE_TEXT))
- logo = 0;
+ logo_shown = FBCON_LOGO_DONTSHOW;
if (var_to_display(p, >var, info))
return;
@@ -1178,7 +1181,7 @@ static void fbcon_init(struct vc_data *vc, int init)
} else
vc_resize(vc, new_cols, new_rows);
- if (logo)
+ if (logo_shown != FBCON_LOGO_DONTSHOW)
fbcon_prepare_logo(vc, info, cols, rows, new_cols, new_rows);
if (vc == svc && softback_buf)
--
2.14.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108585] *ERROR* hw_init of IP block failed -22
https://bugs.freedesktop.org/show_bug.cgi?id=108585 --- Comment #2 from Dan Horák --- (In reply to Michel Dänzer from comment #1) > There were no amdgpu driver changes between rc8 and final... Are you sure > this is 100% reproducible with the latter and not reproducible with the > former? If so, can you bisect? till now 100% reproduceable, will try bisecting the kernel sources and also will look what else might have changed for the record - you can find the kernels at https://copr.fedorainfracloud.org/coprs/sharkcz/talos-kernel/builds/ - amdgpu.dc=0 or 1 makes no difference (0 is my default value, see bug 107049) -- 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] drm/vgem: create a render node for vgem
Quoting Emil Velikov (2018-10-29 12:00:17) > On Fri, 26 Oct 2018 at 15:40, Chris Wilson wrote: > > > > Quoting Daniel Vetter (2018-10-26 14:40:36) > > > On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote: > > > > From: Emil Velikov > > > > > > > > VGEM doesn't do anything modeset specific, so in a way exposing a > > > > primary node is 'wrong'. At the same time, we extensively use if for > > > > creating dumb buffers, fences, prime fd <> handle imports/exports. > > > > What problem are you solving? > Expose a render node, since only the first instance using the card > node gets auth. More accurately, the fence signal/attach do not need DRM_AUTH since they are operating on resources private to the fd. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vgem: create a render node for vgem
On Fri, 26 Oct 2018 at 14:40, Daniel Vetter wrote: > > On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote: > > From: Emil Velikov > > > > VGEM doesn't do anything modeset specific, so in a way exposing a > > primary node is 'wrong'. At the same time, we extensively use if for > > creating dumb buffers, fences, prime fd <> handle imports/exports. > > > > To the point that we explicitly annotate the vgem fence ioctls as > > DRM_RENDER_ALLOW and have an IGT test which opens the render node. > > > > close(drm_open_driver_render(DRIVER_VGEM)) > > Huh, I guess that test doesn't pass? > It does since the IGT code seems bonkers... Namely it silently falls back to the primary/card node. It seems to be for historical reasons... back in the days where render nodes were still experimental and had to be explicitly enabled via kernel arg. I'll try and follow-up to address that. > > Better late than never, let's flip the switch. > > > > Cc: David Airlie > > Cc: Daniel Vetter > > Signed-off-by: Emil Velikov > > Acked-by: Daniel Vetter Thanks. I'll give it a few more days for others to review/comment. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vgem: create a render node for vgem
On Fri, 26 Oct 2018 at 15:40, Chris Wilson wrote: > > Quoting Daniel Vetter (2018-10-26 14:40:36) > > On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote: > > > From: Emil Velikov > > > > > > VGEM doesn't do anything modeset specific, so in a way exposing a > > > primary node is 'wrong'. At the same time, we extensively use if for > > > creating dumb buffers, fences, prime fd <> handle imports/exports. > > What problem are you solving? Expose a render node, since only the first instance using the card node gets auth. > Now if you suggest a way to only expose a > render node and not a master node, that might be more interesting. A couple of years ago, I've proposed a way to have render-only drivers, yet it got shot down. Don't recall was it Daniel V, Dave or someone else. If you fancy going that route, be my guest. Keep in mind that is orthogonal to the goal here. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/bridge: tc358767: fix single lane configuration
PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
Set PHY_2LANE only when 2 lanes are used.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 5f0a666db2fd..fee53422c31f 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -543,6 +543,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
unsigned long rate;
u32 value;
int ret;
+ u32 dp_phy_ctrl;
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -567,7 +568,10 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
+ tc_write(DP_PHY_CTRL, dp_phy_ctrl);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -860,7 +864,9 @@ static int tc_main_link_setup(struct tc_data *tc)
tc_write(SYS_PLLPARAM, value);
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
+ if (tc->link.base.num_lanes == 2)
+ dp_phy_ctrl |= PHY_2LANE;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
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
[PATCH 1/7] drm/bridge: tc358767: add bus flags
tc358767 driver does not set DRM bus_flags, even if it does configures the polarity settings into its registers. This means that the DPI source can't configure the polarities correctly. Add sync flags accordingly. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/bridge/tc358767.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 8e28e738cb52..29a7e33e8ae0 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1195,6 +1195,10 @@ static int tc_bridge_attach(struct drm_bridge *bridge) drm_display_info_set_bus_formats(>connector.display_info, _format, 1); + tc->connector.display_info.bus_flags = + DRM_BUS_FLAG_DE_HIGH | + DRM_BUS_FLAG_PIXDATA_NEGEDGE | + DRM_BUS_FLAG_SYNC_NEGEDGE; drm_connector_attach_encoder(>connector, tc->bridge.encoder); return 0; -- 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
[PATCH 5/7] drm/bridge: tc358767: reject modes which require too much BW
The current driver accepts any videomode with pclk < 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.
Add code to reject modes that require more bandwidth that is available.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index ab299f4debfa..b026b5ef7378 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1114,10 +1114,20 @@ static bool tc_bridge_mode_fixup(struct drm_bridge
*bridge,
static enum drm_mode_status tc_connector_mode_valid(struct drm_connector
*connector,
struct drm_display_mode *mode)
{
+ struct tc_data *tc = connector_to_tc(connector);
+ u32 req, avail;
+ u32 bits_per_pixel = 24;
+
/* DPI interface clock limitation: upto 154 MHz */
if (mode->clock > 154000)
return MODE_CLOCK_HIGH;
+ req = mode->clock * bits_per_pixel / 8 / 1000;
+ avail = tc->link.base.num_lanes * tc->link.base.rate / 1000;
+
+ if (req > avail)
+ return MODE_BAD;
+
return MODE_OK;
}
--
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
[PATCH 0/7] drm/bridge: tc358767: small fixes
Hi, We have TC358867 on our board, which I believe is almost identical to TC358767. We're using it with a DP connector instead of eDP with a fixed panel. I have tested these patches only on TI's 4.14 based kernel, as unfortunately we don't have all the necessary support in mainline yet. These patches fix various bugs, but I'm still seeing at least two issues: * Sync with some videomodes is not correct, resulting in a jumping and skewed display * Link training fails sometimes I would appreciate if someone is able to verify these patches with TC358767. Tomi Tomi Valkeinen (7): drm/bridge: tc358767: add bus flags drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE drm/bridge: tc358767: fix single lane configuration drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value drm/bridge: tc358767: reject modes which require too much BW drm/bridge: tc358767: fix output H/V syncs drm/bridge: tc358767: use DP connector if no panel set drivers/gpu/drm/bridge/tc358767.c | 46 --- 1 file changed, 36 insertions(+), 10 deletions(-) -- 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
[PATCH 2/7] drm/bridge: tc358767: add defines for DP1_SRCCTRL & PHY_2LANE
DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
Add these.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 29a7e33e8ae0..5f0a666db2fd 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -142,6 +142,8 @@
#define DP0_LTLOOPCTRL 0x06d8
#define DP0_SNKLTCTRL 0x06e4
+#define DP1_SRCCTRL0x07a0
+
/* PHY */
#define DP_PHY_CTRL0x0800
#define DP_PHY_RST BIT(28) /* DP PHY Global Soft Reset */
@@ -150,6 +152,7 @@
#define PHY_M1_RST BIT(12) /* Reset PHY1 Main Channel */
#define PHY_RDYBIT(16) /* PHY Main Channels
Ready */
#define PHY_M0_RST BIT(8) /* Reset PHY0 Main Channel */
+#define PHY_2LANE BIT(2) /* PHY Enable 2 lanes */
#define PHY_A0_EN BIT(1) /* PHY Aux Channel0 Enable */
#define PHY_M0_EN BIT(0) /* PHY Main Channel0 Enable */
@@ -564,7 +567,7 @@ static int tc_aux_link_setup(struct tc_data *tc)
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
- tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN);
+ tc_write(DP_PHY_CTRL, BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN);
/*
* Initially PLLs are in bypass. Force PLL parameter update,
@@ -834,7 +837,7 @@ static int tc_main_link_setup(struct tc_data *tc)
DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
/* from excel file - DP1_SrcCtrl */
- tc_write(0x07a0, 0x3083);
+ tc_write(DP1_SRCCTRL, 0x3083);
rate = clk_get_rate(tc->refclk);
switch (rate) {
@@ -855,8 +858,9 @@ static int tc_main_link_setup(struct tc_data *tc)
}
value |= SYSCLK_SEL_LSCLK | LSCLK_DIV_2;
tc_write(SYS_PLLPARAM, value);
+
/* Setup Main Link */
- dp_phy_ctrl = BGREN | PWR_SW_EN | BIT(2) | PHY_A0_EN | PHY_M0_EN;
+ dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_2LANE | PHY_A0_EN | PHY_M0_EN;
tc_write(DP_PHY_CTRL, dp_phy_ctrl);
msleep(100);
--
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
[PATCH 6/7] drm/bridge: tc358767: fix output H/V syncs
The H and V syncs of the DP output are always set to active high. This patch fixes the syncs by configuring them according to the videomode. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/bridge/tc358767.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index b026b5ef7378..be013bd7b30b 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -726,7 +726,9 @@ static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode) tc_write(DP0_ACTIVEVAL, (mode->vdisplay << 16) | (mode->hdisplay)); - tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0)); + tc_write(DP0_SYNCVAL, (vsync_len << 16) | (hsync_len << 0) | +((mode->flags & DRM_MODE_FLAG_NHSYNC) ? (1 << 15) : 0) | +((mode->flags & DRM_MODE_FLAG_NVSYNC) ? (1 << 31) : 0)); tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW | DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888); -- 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
[PATCH 4/7] drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value
Initially DP0_SRCCTRL is set to a static value which includes
DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
This patch changes the configuration as follows:
Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
value.
DP1_SRCCTRL needs to bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index fee53422c31f..ab299f4debfa 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -836,12 +836,11 @@ static int tc_main_link_setup(struct tc_data *tc)
if (!tc->mode)
return -EINVAL;
- /* from excel file - DP0_SrcCtrl */
- tc_write(DP0_SRCCTRL, DP0_SRCCTRL_SCRMBLDIS | DP0_SRCCTRL_EN810B |
-DP0_SRCCTRL_LANESKEW | DP0_SRCCTRL_LANES_2 |
-DP0_SRCCTRL_BW27 | DP0_SRCCTRL_AUTOCORRECT);
- /* from excel file - DP1_SrcCtrl */
- tc_write(DP1_SRCCTRL, 0x3083);
+ tc_write(DP0_SRCCTRL, tc_srcctrl(tc));
+ /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
+ tc_write(DP1_SRCCTRL,
+(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
+((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
rate = clk_get_rate(tc->refclk);
switch (rate) {
--
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
[PATCH 7/7] drm/bridge: tc358767: use DP connector if no panel set
tc358767 driver sets the connector type always to eDP. This patch sets the type to DP if there is no panel defined, which implies that there's a DP connector on the board. Signed-off-by: Tomi Valkeinen --- drivers/gpu/drm/bridge/tc358767.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index be013bd7b30b..db93d927cb9a 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1207,7 +1207,8 @@ static int tc_bridge_attach(struct drm_bridge *bridge) /* Create eDP connector */ drm_connector_helper_add(>connector, _connector_helper_funcs); ret = drm_connector_init(drm, >connector, _connector_funcs, -DRM_MODE_CONNECTOR_eDP); +tc->panel ? DRM_MODE_CONNECTOR_eDP : +DRM_MODE_CONNECTOR_DisplayPort); if (ret) return ret; -- 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 libdrm 0/2] xf86drm: add OF_ fallback mechanism
Am Dienstag, den 23.10.2018, 18:28 +0100 schrieb Emil Velikov: > On Thu, 18 Oct 2018 at 21:07, Christian Gmeiner > > wrote: > > > > Since kernel 4.17 (drm/etnaviv: remove the need for a gpu-subsystem DT > > node) the etnaviv DRM driver doesn't have an associated DT node > > anymore. This is technically correct, as the etnaviv device is a > > virtual device driving multiple hardware devices. > > > > Before 4.17 the userspace had access to the following information: > > # cat /sys/dev/char/226:128/device/uevent > > DRIVER=etnaviv > > OF_NAME=gpu-subsystem > > OF_FULLNAME=/gpu-subsystem > > OF_COMPATIBLE_0=fsl,imx-gpu-subsystem > > OF_COMPATIBLE_N=1 > > MODALIAS=of:Ngpu-subsystemTCfsl,imx-gpu-subsystem > > DRIVER=imx-drm > > OF_NAME=display-subsystem > > OF_FULLNAME=/display-subsystem > > OF_COMPATIBLE_0=fsl,imx-display-subsystem > > OF_COMPATIBLE_N=1 > > > > Afer 4.17: > > # cat /sys/dev/char/226:128/device/uevent > > DRIVER=etnaviv > > MODALIAS=platform:etnaviv > > > > Mostly relaying what I mentioned previously [1], yet forgot to CC RobH. > > - Are the OF entries in uevent part of the ABI or not? Can we have that > documented anywhere? > > There are very few mentions in the official kernel doc - Documentation/ABI/ > Obviously it doesn't mention anything OF_* but it neither does DRIVER > or MODALIAS. Yet if we change those $world will break ;-) The OF node has never been part of the etnaviv UABI, simply due to the fact that it's still possible to instantiate the etnaviv driver from a platform file, instead of a devicetree node. > > - How can we distinguish in the (perhaps hypothetical) case when > there's two or more etnaviv devices? Why not simply use the DRM minor? All you need is an arbitrary handle to grab the right instance. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
