[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103370

--- Comment #45 from Shih-Yuan Lee  ---
I can still reduplicate this issue on Ubuntu 18.04 by `seq 100 | while read i;
do echo Loop $i; DRI_PRIME=1 glxgears -info|head -n2; done`.

-- 
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 105515] hw_init of IP block failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105515

--- Comment #1 from Edward Kigwana  ---
Linux version 4.16.0-rc5 (root@i7-tower) (gcc version 7.3.0 (Gentoo 7.3.0
p1.0)) #5 SMP Thu Mar 15 02:57:39 UTC 2018

-- 
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 105515] hw_init of IP block failed

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105515

Bug ID: 105515
   Summary: hw_init of IP block  failed
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: edwardw...@gmail.com

Card is an MSI RX550 AERO IX OC. I have never gotten it to work with the drm
driver. I can configure EFI for PEG and as along as I black list amdgpu I get
the basic EFI framebuffer. Ass soon as I install the module the screen goes
black. I can reboot using keyboard. With IGD, same story though I can remove
the module and keep trying though parameter settings are not well documented.
E.g What IP blocks can I disable? As for the powerplay messages, what is
message 154 or even 134?

 AMD GPU
[*]   Enable amdgpu support for SI parts
[*]   Enable amdgpu support for CIK parts
[*]   Always enable userptr write support
[ ]   Allow GART access through debugfs
ACP (Audio CoProcessor) Configuration  --->
[*] Enable AMD Audio CoProcessor IP support
Display Engine Configuration  --->
[ ] AMD DC - Enable new display engine
[*] DC support for Polaris and older ASICs
AMD Library routines  --->
[ ] Closed hash table performance statistics
[ ] Closed hash table self test
 HSA kernel driver for AMD GPU devices

[2.540547] fb: switching to inteldrmfb from EFI VGA
[2.540564] Console: switching to colour dummy device 80x25
[2.540613] [drm] Replacing VGA console driver
[2.541103] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.541104] [drm] Driver supports precise vblank timestamp query.
[2.541476] i915 :00:02.0: vgaarb: changed VGA decodes:
olddecodes=io+mem,decodes=none:owns=io+mem
[2.541754] [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin
(v1.4)
[2.551488] [drm] amdgpu kernel modesetting enabled.
[2.552796] AMD IOMMUv2 driver by Joerg Roedel 
[2.552796] AMD IOMMUv2 functionality not available on this system
[2.553582] nct6775: Found NCT6793D or compatible chip at 0x4e:0xa20
[2.558510] CRAT table not found
[2.558511] Virtual CRAT table created for CPU
[2.558511] Parsing CRAT table with 1 nodes
[2.558512] Creating topology SYSFS entries
[2.558519] Topology: Add CPU node
[2.558519] Finished initializing topology
[2.558554] kfd kfd: Initialized module
[2.558695] amdgpu :01:00.0: enabling device ( -> 0003)
[2.558819] [drm] initializing kernel modesetting (POLARIS12 0x1002:0x699F
0x1462:0x8A90 0xC7).
[2.558826] [drm] register mmio base: 0xDF30
[2.558826] [drm] register mmio size: 262144
[2.558833] [drm] probing gen 2 caps for device 8086:1901 = 261ad03/e
[2.558834] [drm] probing mlw for device 8086:1901 = 261ad03
[2.558843] [drm] UVD is enabled in VM mode
[2.558843] [drm] UVD ENC is enabled in VM mode
[2.558845] [drm] VCE enabled in VM mode
[2.819863] [drm] failed to retrieve link info, disabling eDP
[3.461721] ATOM BIOS: 113-d09002-h01
[3.461747] [drm] GPU posting now...
[3.488389] scsi 4:0:0:0: Direct-Access SanDisk  SanDisk Cruzer   8.02
PQ: 0 ANSI: 0 CCS
[3.488457] sd 4:0:0:0: Attached scsi generic sg0 type 0
[3.488720] sd 4:0:0:0: [sda] 31854591 512-byte logical blocks: (16.3
GB/15.2 GiB)
[3.488829] sd 4:0:0:0: [sda] Write Protect is off
[3.488831] sd 4:0:0:0: [sda] Mode Sense: 45 00 00 08
[3.488947] sd 4:0:0:0: [sda] No Caching mode page found
[3.488948] sd 4:0:0:0: [sda] Assuming drive cache: write through
[3.489856] random: crng init done
[3.491902]  sda: sda1
[3.492574] sd 4:0:0:0: [sda] Attached SCSI removable disk
[3.578449] [drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment
size is 9-bit
[3.578457] amdgpu :01:00.0: VRAM: 4096M 0x00F4 -
0x00F4 (4096M used)
[3.578458] amdgpu :01:00.0: GTT: 256M 0x -
0x0FFF
[3.578464] [drm] Detected VRAM RAM=4096M, BAR=256M
[3.578465] [drm] RAM width 128bits GDDR5
[3.578551] [TTM] Zone  kernel: Available graphics memory: 8119498 kiB
[3.578551] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[3.578551] [TTM] Initializing pool allocator
[3.578554] [TTM] Initializing DMA pool allocator
[3.578565] [drm] amdgpu: 4096M of VRAM memory ready
[3.578566] [drm] amdgpu: 4096M of GTT memory ready.
[3.578610] [drm] GART: num cpu pages 65536, num gpu pages 65536
[3.578664] [drm] PCIE GART of 256M enabled (table at 0x00F40004).
[3.578696] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.578697] [drm] Driver supports precise vblank timestamp query.
[3.578839] [drm] AMDGPU Display 

linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  sound/pci/hda/hda_intel.c

between commits:

  1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
  40088dc4e1ea ("ALSA: hda - Revert power_save option default value")

from Linus' tree and commit:

  07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc sound/pci/hda/hda_intel.c
index d5017adf9feb,ec4e6b829ee2..
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@@ -2219,8 -2201,8 +2223,9 @@@ static int azx_probe_continue(struct az
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
struct hdac_bus *bus = azx_bus(chip);
struct pci_dev *pci = chip->pci;
+   struct hda_codec *codec;
int dev = chip->dev_index;
 +  int val;
int err;
  
hda->probe_continued = 1;
@@@ -2302,21 -2284,16 +2307,30 @@@
chip->running = 1;
azx_add_card_list(chip);
  
 +  val = power_save;
 +#ifdef CONFIG_PM
 +  if (pm_blacklist) {
 +  const struct snd_pci_quirk *q;
 +
 +  q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
 +  if (q && val) {
 +  dev_info(chip->card->dev, "device %04x:%04x is on the 
power_save blacklist, forcing power_save to 0\n",
 +   q->subvendor, q->subdevice);
 +  val = 0;
 +  }
 +  }
 +#endif /* CONFIG_PM */
++
+   /*
+* The discrete GPU cannot power down unless the HDA controller runtime
+* suspends, so activate runtime PM on codecs even if power_save == 0.
+*/
+   if (use_vga_switcheroo(hda))
+   list_for_each_codec(codec, >bus)
+   codec->auto_runtime_pm = 1;
+ 
 -  snd_hda_set_power_save(>bus, power_save * 1000);
 +  snd_hda_set_power_save(>bus, val * 1000);
-   if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
+   if (azx_has_pm_runtime(chip))
pm_runtime_put_autosuspend(>dev);
  
  out_free:


pgpL3PuhAk1G_.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[drm-tip:drm-tip 15/1373] arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'?

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   178cfb9373cc2bdfcb6ca73e03369d2c37cc4b58
commit: d8d019ccffb838bb0dd98e583b5c25ccc0bc6ece [15/1373] drm/amdgpu: Add KFD 
eviction fence
config: frv-allyesconfig (attached as .config)
compiler: frv-linux-gcc (GCC) 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
git checkout d8d019ccffb838bb0dd98e583b5c25ccc0bc6ece
# save the attached .config to linux build tree
make.cross ARCH=frv 

All errors (new ones prefixed by >>):

   In file included from arch/frv/include/asm/mmu_context.h:17:0,
from include/linux/mmu_context.h:5,
from drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd.h:29,
from drivers/gpu//drm/amd/amdgpu/amdgpu_amdkfd_fence.c:30:
   arch/frv/include/asm/pgalloc.h: In function 'pte_free':
>> arch/frv/include/asm/pgalloc.h:48:2: error: implicit declaration of function 
>> 'pgtable_page_dtor'; did you mean 'pgdat_page_nr'? 
>> [-Werror=implicit-function-declaration]
 pgtable_page_dtor(pte);
 ^
 pgdat_page_nr
   cc1: some warnings being treated as errors

vim +48 arch/frv/include/asm/pgalloc.h

^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16  45  
2f569afd include/asm-frv/pgalloc.h Martin Schwidefsky 2008-02-08  46  static 
inline void pte_free(struct mm_struct *mm, pgtable_t pte)
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16  47  {
2f569afd include/asm-frv/pgalloc.h Martin Schwidefsky 2008-02-08 @48
pgtable_page_dtor(pte);
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16  49
__free_page(pte);
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16  50  }
^1da177e include/asm-frv/pgalloc.h Linus Torvalds 2005-04-16  51  

:: The code at line 48 was first introduced by commit
:: 2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 CONFIG_HIGHPTE vs. sub-page 
page tables.

:: TO: Martin Schwidefsky 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

[Jeykumar Sankaran]

On 2018-03-14 08:14, Sean Paul wrote:

On Tue, Mar 13, 2018 at 04:57:35PM -0700, Jeykumar Sankaran wrote:

On 2018-03-12 13:21, Sean Paul wrote:
> On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote:
> > On 2018-02-28 11:18, Sean Paul wrote:
> > > Instead, shuffle things around so we kickoff crtc after enabling
> encoder
> > > during modesets. Also moves the vblank wait to after the frame.
> > >
> > > Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3
> > > Signed-off-by: Sean Paul 
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   9 ++
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   5 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  31 -
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   2 +
> > >  drivers/gpu/drm/msm/msm_atomic.c| 132
> +---
> > >  5 files changed, 48 insertions(+), 131 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > index a3ab6ed2bf1d..94fab2dcca5b 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > @@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc
> > > *crtc,
> > >  DPU_EVT32_VERBOSE(DRMID(crtc));
> > >  dpu_crtc = to_dpu_crtc(crtc);
> > >
> > > +if (msm_is_mode_seamless(>state->adjusted_mode) ||
> > > +msm_is_mode_seamless_vrr(>state->adjusted_mode))

{

> > > +DPU_DEBUG("Skipping crtc enable, seamless

mode\n");

> > > +return;
> > > +}
> > > +
> > >  pm_runtime_get_sync(crtc->dev->dev);
> > >
> > >  drm_for_each_encoder(encoder, crtc->dev) {
> > > @@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc
> *crtc,
> > >  DPU_POWER_EVENT_POST_ENABLE |

DPU_POWER_EVENT_POST_DISABLE

> > > |
> > >  DPU_POWER_EVENT_PRE_DISABLE,
> > >  dpu_crtc_handle_power_event, crtc,

dpu_crtc->name);

> > > +
> > > +if

(msm_needs_vblank_pre_modeset(>state->adjusted_mode))

> > > +drm_crtc_wait_one_vblank(crtc);
> > >  }
> > >
> > >  struct plane_state {
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > index 28ceb589ee40..4d1e3652dbf4 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > @@ -3693,8 +3693,11 @@ static void
> dpu_encoder_frame_done_timeout(struct
> > > timer_list *t)
> > >  static const struct drm_encoder_helper_funcs

dpu_encoder_helper_funcs

> =
> > > {
> > >  .mode_set = dpu_encoder_virt_mode_set,
> > >  .disable = dpu_encoder_virt_disable,
> > > -.enable = dpu_encoder_virt_enable,
> > > +.enable = dpu_kms_encoder_enable,
> > >  .atomic_check = dpu_encoder_virt_atomic_check,
> > > +
> > > +/* This is called by dpu_kms_encoder_enable */
> > > +.commit = dpu_encoder_virt_enable,
> > >  };
> > >
> > >  static const struct drm_encoder_funcs dpu_encoder_funcs = {
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > index 81fd3a429e9f..3d83037e8305 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > @@ -425,14 +425,37 @@ static void dpu_kms_prepare_commit(struct
> msm_kms
> > > *kms,
> > >  dpu_encoder_prepare_commit(encoder);
> > >  }
> > >
> > > -static void dpu_kms_commit(struct msm_kms *kms,
> > > -struct drm_atomic_state *old_state)
> > > +/*
> > > + * Override the encoder enable since we need to setup the inline
> > > rotator
> > > and do
> > > + * some crtc magic before enabling any bridge that might be

present.

> > > + */
> > > +void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> > > +{
> > > +const struct drm_encoder_helper_funcs *funcs =
> > > encoder->helper_private;
> > > +struct drm_crtc *crtc = encoder->crtc;
> > > +
> > > +/* Forward this enable call to the commit hook */
> > > +if (funcs && funcs->commit)
> > > +funcs->commit(encoder);
> >
> > The purpose of this function is not clear. Where are we setting up

the

> > inline rotator?
> > Why do we need a kickoff here?
>
> The reason the code is shuffled is to avoid duplicating the entire
> atomic
> helper
> function. By moving calls into the ->enable hooks, we can avoid having
> to
> hand
> roll the helpers.
>
> The kickoff is preserved from the helper copy when you call
> kms->funcs->commit
> in between the encoder enable and bridge enable. If this can be

removed,

> that'd
> be even better. I was simply trying to preserve the call order of
> everything.
>
> Sean
I am with you on cleaning up the atomic helper copy. But using

enc->commit

helper
to call into 

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198123

--- Comment #37 from sh...@tuta.io ---
(In reply to Michel Dänzer from comment #36)
> Can you try the latest test patch attached here, and attach the dmesg output
> from running with it?

With the patch, the background is always black. I guess, there is a race, and
the patch affects the outcome.

-- 
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 105442] Hang when running nine ff lighting shader

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105442

Axel Davy  changed:

   What|Removed |Added

 QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org

-- 
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] drm/tilcdc: Fix setting clock divider for omap-l138

[David Lechner]

This fixes setting the clock divider on the TI OMAP-L138 LCDK board.

The clock drivers for OMAP-L138 are being covernted to the common clock
framework. When this happens, clk_set_rate() will no longer return an
error. However, on this SoC, the clock rate cannot actually be changed
because the clock has to maintain a fixed ratio to the ARM clock. So
after attempting to set the clock rate, we need to check to see if the
new rate is actually close enough. If not, then follow the previous
error path to adjust the divider in LCDC IP block to compensate for not
being able to change the parent clock rate.

Tested working on a TI OMAP-L138 LCDK board.

Signed-off-by: David Lechner 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 8bf6bb9..6931777 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -224,7 +224,7 @@ static void tilcdc_crtc_set_clk(struct drm_crtc *crtc)
 
ret = clk_set_rate(priv->clk, req_rate * clkdiv);
clk_rate = clk_get_rate(priv->clk);
-   if (ret < 0) {
+   if (ret < 0 || tilcdc_pclk_diff(req_rate, clk_rate) > 5) {
/*
 * If we fail to set the clock rate (some architectures don't
 * use the common clock framework yet and may not implement
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Here goes drm-intel-fixes-2018-03-14:

- 1 display fix for bxt
- 1 gem fix for fences
- 1 gem/pm fix for rps freq

Thanks,
Rodrigo.

The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:

  Linux 4.16-rc5 (2018-03-11 17:25:09 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-03-14

for you to fetch changes up to f1430f145eefcab2bddb9e836d427c4aac067faa:

  drm/i915: Kick the rps worker when changing the boost frequency (2018-03-12 
11:24:49 -0700)


- 1 display fix for bxt
- 1 gem fix for fences
- 1 gem/pm fix for rps freq


Chris Wilson (2):
  drm/i915: Only prune fences after wait-for-all
  drm/i915: Kick the rps worker when changing the boost frequency

Mustamin B Mustaffa (1):
  drm/i915: Enable VBT based BL control for DP

 drivers/gpu/drm/i915/i915_gem.c   | 16 
 drivers/gpu/drm/i915/i915_sysfs.c | 10 --
 drivers/gpu/drm/i915/intel_dp.c   | 10 +++---
 3 files changed, 23 insertions(+), 13 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Rodrigo Vivi]

On Wed, Mar 14, 2018 at 01:20:06PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
> V7: typo

https://patchwork.freedesktop.org/series/39473/
Checkpatch noticed few lines like this over 80 char.

> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..793c0ff 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;

int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
DP_TRAINING_AUX_RD_MASK;

> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
> rd_interval);


DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
  rd_interval);

> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DPCD_REV_14))
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;

ditto

> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
> rd_interval);

ditto

> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..9afea9f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DPCD_REV_100x10
> +# define DPCD_REV_110x11
> +# define DPCD_REV_120x12
> +# define DPCD_REV_130x13
> +# define DPCD_REV_140x14

DP_DPCD_REV_ to match the reg name

>  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +123,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */

maybe add "?" to be in sync with the reg offset?

>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon and amdgpu drm-fixes-4.16

[Alex Deucher]

Hi Dave,

A few fixes for 4.16:
- Fix a backlight S/R regression on amdgpu
- Fix prime teardown on radeon and amdgpu
- DP fix for amdgpu

The following changes since commit b0655d668fc4faf0c1985e828820f9b9ca13abe6:

  Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2018-03-09 09:23:02 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16

for you to fetch changes up to 7d617264eb22b18d979eac6e85877a141253034e:

  drm/amdgpu/dce: Don't turn off DP sink when disconnected (2018-03-14 15:40:00 
-0500)


Alex Deucher (1):
  drm/amdgpu: save/restore backlight level in legacy dce code

Christian König (2):
  drm/amdgpu: fix prime teardown order
  drm/radeon: fix prime teardown order

Michel Dänzer (1):
  drm/amdgpu/dce: Don't turn off DP sink when disconnected

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 31 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  2 ++
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c |  4 ++--
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.h |  5 +
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  8 +++
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  8 +++
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |  8 +++
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  8 +++
 drivers/gpu/drm/radeon/radeon_gem.c|  2 --
 drivers/gpu/drm/radeon/radeon_object.c |  2 ++
 12 files changed, 56 insertions(+), 25 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

[Stefan Lengfeld]

Small refactoring. Use the helper define DRM_FB_HELPER_DEFAULT_OPS that
provides the default implementations of the drm_fb_helper functions for
struct fb_ops.

Now the driver implements an additional member of the struct fb_ops:

.fb_ioctl   = drm_fb_helper_ioctl

This change is not tested.

Cc: Dave Airlie 
Signed-off-by: Stefan Lengfeld 
---
 drivers/gpu/drm/ast/ast_fb.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 0cd827e11fa2..e19b3bffe10b 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -149,16 +149,10 @@ static void ast_imageblit(struct fb_info *info,
 
 static struct fb_ops astfb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = ast_fillrect,
.fb_copyarea = ast_copyarea,
.fb_imageblit = ast_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
-   .fb_debug_enter = drm_fb_helper_debug_enter,
-   .fb_debug_leave = drm_fb_helper_debug_leave,
 };
 
 static int astfb_create_object(struct ast_fbdev *afbdev,
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] Final round for DRM_FB_HELPER_DEFAULT_OPS usage

[Stefan Lengfeld]

Hi folks,

this is a follow up patch set to my initial tree wide refactoring

Subject: Introduce DRM_FB_HELPER_DEFAULT_OPS for struct fb_ops
https://patchwork.freedesktop.org/series/13099/

nearly one and a half year ago. It contains three patches for drivers

ast, hisilicon and mgag200

that are currently not using DRM_FB_HELPER_DEFAULT_OPS. 

If the conversion is appropriate for your driver, you can pick up the
patch. If not (because it may enable untested functionality), you can
just ignore it. It's only a gentle remainder in case the conversion was
missed in the first version/round.


In detail: One and a half year ago the drivers 'ast' and 'mgag200' did
not use much of the drm_fb_helper functions. Now they do, so using
DRM_FB_HELPER_DEFAULT_OPS seems beneficial. 

The drm driver 'hisilicon' was either missed in the initial patch set or
the driver was just added later.

Except the three drivers above, there are only two drivers not using
DRM_FB_HELPER_DEFAULT_OPS left in the whole tree (v4.16-rc1): 'cirrus'
and 'vmwgfx'.  The former is marked as *do-not-touch* by checkpatch.pl
and the later implements all fb_ops functions on it's on. No need for a
conversion.

Last but not least: The driver 'omapdrm' just received a patch for the
next kernel version to drop DRM_FB_HELPER_DEFAULT_OPS again. It causes a
compiler waring 'Initializer entry defined twice', because the driver
reassigns .fb_pan_display which is already provided in
DRM_FB_HELPER_DEFAULT_OPS.

Kind Regards,
Stefan

Cc: Dave Airlie 
Cc: Rongrong Zou 
Cc: Xinliang Liu 
---

Stefan Lengfeld (3):
  drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/hisilicon: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops
  drm/mgag200: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

 drivers/gpu/drm/ast/ast_fb.c  | 8 +---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 6 +-
 drivers/gpu/drm/mgag200/mgag200_fb.c  | 6 +-
 3 files changed, 3 insertions(+), 17 deletions(-)

-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/mgag200: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

[Stefan Lengfeld]

Small refactoring. Use the helper define DRM_FB_HELPER_DEFAULT_OPS that
provides the default implementations of the drm_fb_helper functions for
struct fb_ops.

Now the driver implements three additional members of the struct fb_ops:

.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
.fb_ioctl   = drm_fb_helper_ioctl

These changes are not tested.

Cc: Dave Airlie 
Signed-off-by: Stefan Lengfeld 
---
 drivers/gpu/drm/mgag200/mgag200_fb.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index 30726c9fe28c..e02c11b6d27d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -125,14 +125,10 @@ static void mga_imageblit(struct fb_info *info,
 
 static struct fb_ops mgag200fb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = mga_fillrect,
.fb_copyarea = mga_copyarea,
.fb_imageblit = mga_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };
 
 static int mgag200fb_create_object(struct mga_fbdev *afbdev,
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/hisilicon: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

[Stefan Lengfeld]

Small refactoring. Use the helper define DRM_FB_HELPER_DEFAULT_OPS that
provides the default implementations of the drm_fb_helper functions for
struct fb_ops.

Now the driver implements three additional members of the struct fb_ops:

.fb_debug_enter = drm_fb_helper_debug_enter,
.fb_debug_leave = drm_fb_helper_debug_leave,
.fb_ioctl   = drm_fb_helper_ioctl

These changes are not tested.

Cc: Rongrong Zou 
Cc: Xinliang Liu 
Signed-off-by: Stefan Lengfeld 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index b92595c477ef..b18b20535cff 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -43,14 +43,10 @@ static int hibmcfb_create_object(
 
 static struct fb_ops hibmc_drm_fb_ops = {
.owner = THIS_MODULE,
-   .fb_check_var = drm_fb_helper_check_var,
-   .fb_set_par = drm_fb_helper_set_par,
+   DRM_FB_HELPER_DEFAULT_OPS,
.fb_fillrect = drm_fb_helper_sys_fillrect,
.fb_copyarea = drm_fb_helper_sys_copyarea,
.fb_imageblit = drm_fb_helper_sys_imageblit,
-   .fb_pan_display = drm_fb_helper_pan_display,
-   .fb_blank = drm_fb_helper_blank,
-   .fb_setcmap = drm_fb_helper_setcmap,
 };
 
 static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
-- 
2.16.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105502] HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105502

cd  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |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

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction
V7: typo

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..793c0ff 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
rd_interval);
+
+   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DPCD_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..9afea9f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Rodrigo Vivi]

On Wed, Mar 14, 2018 at 10:40:08AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 18 ++
>  include/drm/drm_dp_helper.h |  6 ++
>  2 files changed, 20 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index adf79be..392e92e 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
> rd_interval);
> +
> + if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))

s/DP_REV_14/DPCD_REV_14 right?

>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
> DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
> rd_interval);
> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index da58a42..9afea9f 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -64,6 +64,11 @@
>  /* AUX CH addresses */
>  /* DPCD */
>  #define DP_DPCD_REV 0x000
> +# define DPCD_REV_100x10
> +# define DPCD_REV_110x11
> +# define DPCD_REV_120x12
> +# define DPCD_REV_130x13
> +# define DPCD_REV_140x14
>  
>  #define DP_MAX_LINK_RATE0x001
>  
> @@ -118,6 +123,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[John Stultz]

On Wed, Mar 14, 2018 at 11:55 AM, Robert Foss  wrote:
> Hey John,
>
> Pushed to master

That's great! Thanks so much to you and everyone who provided review input!
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm_hwcomposer: Add platformhisi buffer importer for hikey and hikey960

[Robert Foss]

Hey John,

Pushed to master

On 03/14/2018 12:51 AM, John Stultz wrote:

This allows for importing buffers allocated from the
hikey and hikey960 gralloc implementations.

Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Dmitry Shmidt 
Cc: Robert Foss 
Cc: Matt Szczesiak 
Cc: Liviu Dudau 
Cc: David Hanna 
Cc: Rob Herring 
Cc: Alexandru-Cosmin Gheorghe 
Cc: Alistair Strachan 
Acked-by: Robert Foss 
Signed-off-by: John Stultz 
---
v2:
* Make platformhisi and the generic importer exclusive in the
   build
* Fixup vendor check
v3:
* Unify format conversions
* Subclass the platformdrmgeneric importer implementation to
   reduce code duplication
* Rework to avoid board specific logic (tweak gralloc to be
   consistent between the two)
v4:
* Minor cleanups as suggested by Alexandru-Cosmin Gheorghe
v5:
* Minor spelling fix in commit message noticed by Robert Foss
---
  Android.mk   |  13 +
  platformdrmgeneric.h |   2 +-
  platformhisi.cpp | 135 +++
  platformhisi.h   |  48 ++
  4 files changed, 197 insertions(+), 1 deletion(-)
  create mode 100644 platformhisi.cpp
  create mode 100644 platformhisi.h

diff --git a/Android.mk b/Android.mk
index 8b11e37..1add286 100644
--- a/Android.mk
+++ b/Android.mk
@@ -75,7 +75,20 @@ LOCAL_CPPFLAGS += \
-DHWC2_USE_CPP11 \
-DHWC2_INCLUDE_STRINGIFICATION
  
+

+ifeq ($(TARGET_PRODUCT),hikey960)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc960/
+else
+ifeq ($(TARGET_PRODUCT),hikey)
+LOCAL_CPPFLAGS += -DUSE_HISI_IMPORTER
+LOCAL_SRC_FILES += platformhisi.cpp
+LOCAL_C_INCLUDES += device/linaro/hikey/gralloc/
+else
  LOCAL_CPPFLAGS += -DUSE_DRM_GENERIC_IMPORTER
+endif
+endif
  
  LOCAL_MODULE := hwcomposer.drm

  LOCAL_MODULE_TAGS := optional
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 8376580..fbe059b 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -35,8 +35,8 @@ class DrmGenericImporter : public Importer {
int ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) override;
int ReleaseBuffer(hwc_drm_bo_t *bo) override;
  
- private:

uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ private:
  
DrmResources *drm_;
  
diff --git a/platformhisi.cpp b/platformhisi.cpp

new file mode 100644
index 000..16c5e6f
--- /dev/null
+++ b/platformhisi.cpp
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2015 The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#define LOG_TAG "hwc-platform-hisi"
+
+#include "drmresources.h"
+#include "platform.h"
+#include "platformhisi.h"
+
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include "gralloc_priv.h"
+
+
+namespace android {
+
+Importer *Importer::CreateInstance(DrmResources *drm) {
+  HisiImporter *importer = new HisiImporter(drm);
+  if (!importer)
+return NULL;
+
+  int ret = importer->Init();
+  if (ret) {
+ALOGE("Failed to initialize the hisi importer %d", ret);
+delete importer;
+return NULL;
+  }
+  return importer;
+}
+
+HisiImporter::HisiImporter(DrmResources *drm) : DrmGenericImporter(drm), 
drm_(drm) {
+}
+
+HisiImporter::~HisiImporter() {
+}
+
+int HisiImporter::Init() {
+  int ret = hw_get_module(GRALLOC_HARDWARE_MODULE_ID,
+  (const hw_module_t **)_);
+  if (ret) {
+ALOGE("Failed to open gralloc module %d", ret);
+return ret;
+  }
+
+  if (strcasecmp(gralloc_->common.author, "ARM Ltd."))
+ALOGW("Using non-ARM gralloc module: %s/%s\n", gralloc_->common.name,
+  gralloc_->common.author);
+
+  return 0;
+}
+
+EGLImageKHR HisiImporter::ImportImage(EGLDisplay egl_display, buffer_handle_t 
handle) {
+  private_handle_t const *hnd = reinterpret_cast < private_handle_t const 
*>(handle);
+  if (!hnd)
+return NULL;
+
+  EGLint fmt = ConvertHalFormatToDrm(hnd->req_format);
+  if (fmt < 0)
+   return NULL;
+
+  EGLint attr[] = {
+EGL_WIDTH, hnd->width,
+EGL_HEIGHT, hnd->height,
+EGL_LINUX_DRM_FOURCC_EXT, fmt,
+EGL_DMA_BUF_PLANE0_FD_EXT, hnd->share_fd,
+

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

Hi Sergei,
   thanks for review

On Wed, Mar 14, 2018 at 08:09:52PM +0300, Sergei Shtylyov wrote:
> On 03/13/2018 05:30 PM, Jacopo Mondi wrote:
>
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output decoder.
> >
> > Signed-off-by: Jacopo Mondi 
> [...]
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..4b059c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,241 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static const char * const thc63_reg_names[] = {
> > +   "vcc", "lvcc", "pvcc", "cvcc", };
>
>Your bracing style is pretty strange -- neither here nor there. Please 
> place };
> on the next line...

Yeah, I had doubt about this.. The most common style I found around is

static const char * const foo[] = {
"bar",
"baz",
"...",
};

But seems really too many lines for a bunch of 4 character strings...

>
> [...]
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   unsigned int i;
> > +   int ret;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > +   vcc = thc63->vccs[i];
> > +   if (vcc) {
> > +   ret = regulator_enable(vcc);
> > +   if (ret)
>
>You hardly need this variable, could do a call right in this *if*.
>
> [...]
> > +error_vcc_enable:
> > +   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> > +}
> > +
>
>Why not do this instead of *goto* before?

Well, goto breaks the loop, if I only print out the error message, the
enable sequence will go on and enable the other regulators.

I can print out and break, but I don't see that much benefit

One thing I could do instead, is not only print out the error message,
but disable the already enabled regulators if one fails to start.

>
> > +static void thc63_disable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   unsigned int i;
> > +   int ret;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > +   vcc = thc63->vccs[i];
> > +   if (vcc) {
> > +   ret = regulator_disable(vcc);
> > +   if (ret)
>
>Again, no need for 'ret' whatsoever...
>
> > +   goto error_vcc_disable;
> > +   }
> > +   }
> > +
> > +   if (thc63->pwdn)
> > +   gpiod_set_value(thc63->pwdn, 1);
> > +
> > +   if (thc63->oe)
> > +   gpiod_set_value(thc63->oe, 0);
> > +
> > +   return;
> > +
> > +error_vcc_disable:
> > +   dev_err(thc63->dev, "Failed to disable regulator %u\n", i);
>
>Again, why not do it instead of *goto*?

ditto

>
> [...]
> > +static int thc63_gpio_init(struct thc63_dev *thc63)
> > +{
> > +   thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> > + GPIOD_OUT_LOW);
> > +   if (IS_ERR(thc63->pwdn)) {
> > +   dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
>
>"pwdn-gpios" maybe?
>
> > +   return PTR_ERR(thc63->pwdn);
> > +   }
> > +
> > +   thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> > +   if (IS_ERR(thc63->oe)) {
> > +   dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
>
>"oe-gpios" maybe?

Are you referring to the error message? I can change this, but again, I
see no standards around.

Thanks
   j

>
> [...]
>
> MBR, Sergei


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Sergei Shtylyov]

On 03/14/2018 09:04 PM, jacopo mondi wrote:

>>> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
>>> output decoder.
>>>
>>> Signed-off-by: Jacopo Mondi 
>> [...]
>>> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
>>> b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> new file mode 100644
>>> index 000..4b059c0
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
>>> @@ -0,0 +1,241 @@
[...]
>>> +static void thc63_enable(struct drm_bridge *bridge)
>>> +{
>>> +   struct thc63_dev *thc63 = to_thc63(bridge);
>>> +   struct regulator *vcc;
>>> +   unsigned int i;
>>> +   int ret;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
>>> +   vcc = thc63->vccs[i];
>>> +   if (vcc) {
>>> +   ret = regulator_enable(vcc);
>>> +   if (ret)
>>
>>You hardly need this variable, could do a call right in this *if*.
>>
>> [...]
>>> +error_vcc_enable:
>>> +   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
>>> +}
>>> +
>>
>>Why not do this instead of *goto* before?
> 
> Well, goto breaks the loop, if I only print out the error message, the
> enable sequence will go on and enable the other regulators.

> I can print out and break, but I don't see that much benefit

   Sorry, I meant that you should *return* there instead of *goto*.

> One thing I could do instead, is not only print out the error message,
> but disable the already enabled regulators if one fails to start.

   Yeah, probably...

[...]
>>> +static int thc63_gpio_init(struct thc63_dev *thc63)
>>> +{
>>> +   thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
>>> + GPIOD_OUT_LOW);
>>> +   if (IS_ERR(thc63->pwdn)) {
>>> +   dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");
>>
>>"pwdn-gpios" maybe?
>>
>>> +   return PTR_ERR(thc63->pwdn);
>>> +   }
>>> +
>>> +   thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
>>> +   if (IS_ERR(thc63->oe)) {
>>> +   dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");
>>
>>"oe-gpios" maybe?
> 
> Are you referring to the error message?

   Yes, seems more clear what to look for this way, IMHO...

[...]

MBR, Sergei

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[matthew . s . atwood]

From: Matt Atwood 

DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
receiver capabilities. For panels that use this new feature wait interval
would be increased by 512 ms, when spec is max 16 ms. This behavior is
described in table 2-158 of DP 1.4 spec address eh.

With the introduction of DP 1.4 spec main link clock recovery was
standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.

To avoid breaking panels that are not spec compiant we now warn on
invalid values.

V2: commit title/message, masking all 7 bits, warn on out of spec values.
V3: commit message, make link train clock recovery follow DP 1.4 spec.
V4: style changes
V5: typo
V6: print statement revisions, DP_REV to DPCD_REV, comment correction

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/drm_dp_helper.c | 18 ++
 include/drm/drm_dp_helper.h |  6 ++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index adf79be..392e92e 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -119,18 +119,28 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
 EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
 
 void drm_dp_link_train_clock_recovery_delay(const u8 
dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
rd_interval);
+
+   if (rd_interval == 0 || (dpcd[DP_DPCD_REV] >= DP_REV_14))
udelay(100);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
 
 void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) {
-   if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
+   int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] & 
DP_TRAINING_AUX_RD_MASK;
+
+   if (rd_interval > 4)
+   DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n", 
rd_interval);
+
+   if (rd_interval == 0)
udelay(400);
else
-   mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
+   mdelay(rd_interval * 4);
 }
 EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index da58a42..9afea9f 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -64,6 +64,11 @@
 /* AUX CH addresses */
 /* DPCD */
 #define DP_DPCD_REV 0x000
+# define DPCD_REV_100x10
+# define DPCD_REV_110x11
+# define DPCD_REV_120x12
+# define DPCD_REV_130x13
+# define DPCD_REV_140x14
 
 #define DP_MAX_LINK_RATE0x001
 
@@ -118,6 +123,7 @@
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
 #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[John Stultz]

On Wed, Mar 14, 2018 at 10:21 AM, Emil Velikov  wrote:
> On 14 March 2018 at 16:47, John Stultz  wrote:
>> When building AOSP after updating libdrm project to the
>> freedesktop/master branch, I've seen the following build errors:
>>
>> external/libdrm/intel/Android.mk: error: libdrm_intel
>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>> (SHARED_LIBRARIES android-arm64) You can set
>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>> intentional, but that may defer real problems until later in the
>> build.
>>
>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>> things to function properly, but is not ideal.
>>
>> So basically, while I'm not including the libdrm_intel package
>> into the build, just the fact that the Android.mk file references
>> libpciaccess which isn't a repo included in AOSP causes the build
>> failure.
>>
>> So it seems we need some sort of conditional filter in the
>> Android.mk to skip over it if we're not building for intel.
>>
> Could swear I asked a few times already, but cannot see an answer.
> Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?

Again, this is from the Android build, as the top level Android.mk calls:
include $(call all-makefiles-under,$(LOCAL_PATH))

Which includes all Android.mk files in all the sub directories
(regardless of any BOARD_GPU_DRIVERS value).

The error is that while we don't build the libdrm_intel module, the
android build system still throws a error when any
LOCAL_SHARED_LIBRARIES files aren't present in the larger build
environment.

Since the intel/Android.mk specifies
LOCAL_SHARED_LIBRARIES := \
libdrm \
libpciaccess

And in AOSP there is no libpciaccess module, it generates the error.

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/5] drm/i915: Move DP modeset retry work into intel_dp

[Ville Syrjälä]

On Tue, Mar 13, 2018 at 07:24:20PM -0400, Lyude Paul wrote:
> On Mon, 2018-03-12 at 23:01 +0200, Ville Syrjälä wrote:
> > On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote:
> > > While having the modeset_retry_work in intel_connector makes sense with
> > > SST, this paradigm doesn't make a whole ton of sense when it comes to
> > > MST since we have to deal with multiple connectors. In most cases, it's
> > > more useful to just use the intel_dp struct since it indicates whether
> > > or not we're dealing with an MST device, along with being able to easily
> > > trace the intel_dp struct back to it's respective connector (if there is
> > > any). So, move the modeset_retry_work function out of the
> > > intel_connector struct and into intel_dp.
> > > 
> > > Signed-off-by: Lyude Paul 
> > > Reviewed-by: Manasi Navare 
> > > Cc: Manasi Navare 
> > > Cc: Ville Syrjälä 
> > > 
> > > V2:
> > >  - Remove accidental duplicate modeset_retry_work in intel_connector
> > > V3:
> > >  - Also check against eDP in intel_hpd_poll_fini() - mdnavare
> > > Signed-off-by: Lyude Paul 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c  | 25 
> > > +++-
> > > -
> > >  drivers/gpu/drm/i915/intel_dp.c   | 10 --
> > >  drivers/gpu/drm/i915/intel_dp_link_training.c |  2 +-
> > >  drivers/gpu/drm/i915/intel_drv.h  |  6 +++---
> > >  4 files changed, 31 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f424fff477f6..3b7fa430a84a 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -15394,16 +15394,37 @@ static void intel_hpd_poll_fini(struct 
> > > drm_device
> > > *dev)
> > >  {
> > >   struct intel_connector *connector;
> > >   struct drm_connector_list_iter conn_iter;
> > > + struct work_struct *work;
> > > + int conn_type;
> > >  
> > >   /* Kill all the work that may have been queued by hpd. */
> > >   drm_connector_list_iter_begin(dev, _iter);
> > >   for_each_intel_connector_iter(connector, _iter) {
> > > - if (connector->modeset_retry_work.func)
> > > - cancel_work_sync(>modeset_retry_work);
> > >   if (connector->hdcp_shim) {
> > >   cancel_delayed_work_sync(
> > > >hdcp_check_work);
> > >   cancel_work_sync(>hdcp_prop_work);
> > >   }
> > > +
> > > + conn_type = connector->base.connector_type;
> > > + if (conn_type != DRM_MODE_CONNECTOR_eDP &&
> > > + conn_type != DRM_MODE_CONNECTOR_DisplayPort)
> > > + continue;
> > > +
> > > + if (connector->mst_port) {
> > > + work = >mst_port->modeset_retry_work;
> > > + } else {
> > > + struct intel_encoder *intel_encoder =
> > > + connector->encoder;
> > > + struct intel_dp *intel_dp;
> > > +
> > > + if (!intel_encoder)
> > > + continue;
> > > +
> > > + intel_dp = enc_to_intel_dp(_encoder->base);
> > > + work = _dp->modeset_retry_work;
> > > + }
> > > +
> > > + cancel_work_sync(work);
> > 
> > Why are we even walking the connectors for this? Can't we just
> > walk the encoders instead?
> We could walk the encoders for this, but seeing as we're already walking the
> connectors for the HDCP prop doesn't it make more sense to just stick our code
> there? or is there a simpler solution for this I'm missing

I think walking the encoders when you want encoders is a lot cleaner.
Keeps the snr much higher.

> > 
> > >   }
> > >   drm_connector_list_iter_end(_iter);
> > >  }
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 4dd1b2287dd6..5abf0c95725a 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -6261,12 +6261,10 @@ static bool intel_edp_init_connector(struct 
> > > intel_dp
> > > *intel_dp,
> > >  
> > >  static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
> > >  {
> > > - struct intel_connector *intel_connector;
> > > - struct drm_connector *connector;
> > > + struct intel_dp *intel_dp = container_of(work, typeof(*intel_dp),
> > > +  modeset_retry_work);
> > > + struct drm_connector *connector = _dp->attached_connector-
> > > >base;
> > >  
> > > - intel_connector = container_of(work, typeof(*intel_connector),
> > > -modeset_retry_work);
> > > - connector = _connector->base;
> > >   DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
> > > connector->name);
> > >  
> > > @@ -6295,7 +6293,7 @@ intel_dp_init_connector(struct intel_digital_port

Re: [PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[Emil Velikov]

On 14 March 2018 at 16:47, John Stultz  wrote:
> When building AOSP after updating libdrm project to the
> freedesktop/master branch, I've seen the following build errors:
>
> external/libdrm/intel/Android.mk: error: libdrm_intel
> (SHARED_LIBRARIES android-arm64) missing libpciaccess
> (SHARED_LIBRARIES android-arm64) You can set
> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
> intentional, but that may defer real problems until later in the
> build.
>
> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
> things to function properly, but is not ideal.
>
> So basically, while I'm not including the libdrm_intel package
> into the build, just the fact that the Android.mk file references
> libpciaccess which isn't a repo included in AOSP causes the build
> failure.
>
> So it seems we need some sort of conditional filter in the
> Android.mk to skip over it if we're not building for intel.
>
Could swear I asked a few times already, but cannot see an answer.
Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?

One way to avoid this kind of clutches like is to have meta drivers
like "arm-all" or "x86-all".

Some examples:
 - the Mesa i965/anv drivers will not build for arm
 - the Mesa vc4 (even vc5?) driver has some perf. sensitive arm/thumb assembly
 - building the following combinations is waste of resources -
i915/i965/i915g on !x86, freedreno/etnaviv/imx on !arm

Without something like my earlier suggestion all of the above will
need to be special cased. And more are to come with time :-\

That is, unless I'm loosing my marbles. In which case don't be shy and
let me know, please.

Thanks
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Sergei Shtylyov]

On 03/13/2018 05:30 PM, Jacopo Mondi wrote:

> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output decoder.
> 
> Signed-off-by: Jacopo Mondi 
[...]
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..4b059c0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,241 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +static const char * const thc63_reg_names[] = {
> + "vcc", "lvcc", "pvcc", "cvcc", };

   Your bracing style is pretty strange -- neither here nor there. Please place 
};
on the next line...

[...]
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_enable(vcc);
> + if (ret)

   You hardly need this variable, could do a call right in this *if*.

[...]
> +error_vcc_enable:
> + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> +}
> +

   Why not do this instead of *goto* before?
 
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_disable(vcc);
> + if (ret)

   Again, no need for 'ret' whatsoever...

> + goto error_vcc_disable;
> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 1);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 0);
> +
> + return;
> +
> +error_vcc_disable:
> + dev_err(thc63->dev, "Failed to disable regulator %u\n", i);

   Again, why not do it instead of *goto*?

[...]
> +static int thc63_gpio_init(struct thc63_dev *thc63)
> +{
> + thc63->pwdn = devm_gpiod_get_optional(thc63->dev, "pwdn",
> +   GPIOD_OUT_LOW);
> + if (IS_ERR(thc63->pwdn)) {
> + dev_err(thc63->dev, "Unable to get GPIO \"pwdn\"\n");

   "pwdn-gpios" maybe?

> + return PTR_ERR(thc63->pwdn);
> + }
> +
> + thc63->oe = devm_gpiod_get_optional(thc63->dev, "oe", GPIOD_OUT_LOW);
> + if (IS_ERR(thc63->oe)) {
> + dev_err(thc63->dev, "Unable to get GPIO \"oe\"\n");

   "oe-gpios" maybe?

[...]

MBR, Sergei
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

[John Stultz]

When building AOSP after updating libdrm project to the
freedesktop/master branch, I've seen the following build errors:

external/libdrm/intel/Android.mk: error: libdrm_intel
(SHARED_LIBRARIES android-arm64) missing libpciaccess
(SHARED_LIBRARIES android-arm64) You can set
ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
intentional, but that may defer real problems until later in the
build.

Using ALLOW_MISSING_DEPENDENCIES=true when building allows
things to function properly, but is not ideal.

So basically, while I'm not including the libdrm_intel package
into the build, just the fact that the Android.mk file references
libpciaccess which isn't a repo included in AOSP causes the build
failure.

So it seems we need some sort of conditional filter in the
Android.mk to skip over it if we're not building for intel.

Change-Id: I6cb51c7bb0a7d1a0ab1723b7d3f20aea38988495
Cc: Emil Velikov 
Cc: Chad Versace 
Cc: Marissa Wall 
Cc: Sean Paul 
Cc: Rob Herring 
Cc: Dan Willemsen 
Cc: Tomasz Figa 
Cc: Robert Foss 
Signed-off-by: John Stultz 
---
v2: Check for x86_64 as well
---
 intel/Android.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/intel/Android.mk b/intel/Android.mk
index 5407ff3..3f9db78 100644
--- a/intel/Android.mk
+++ b/intel/Android.mk
@@ -21,6 +21,7 @@
 # IN THE SOFTWARE.
 #
 
+ifeq ($(TARGET_ARCH),$(filter $(TARGET_ARCH),x86 x86_64))
 LOCAL_PATH := $(call my-dir)
 include $(CLEAR_VARS)
 
@@ -37,3 +38,4 @@ LOCAL_SHARED_LIBRARIES := \
 
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
+endif
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 18/47] fbdev: s1d13xxxfb: remove m32r specific hacks

[Arnd Bergmann]

The m32r architecture is being removed, so this is no longer needed.

Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/s1d13xxxfb.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 5d6179ef0298..e04efb567b5c 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -96,18 +96,12 @@ static const struct fb_fix_screeninfo s1d13xxxfb_fix = {
 static inline u8
 s1d13xxxfb_readreg(struct s1d13xxxfb_par *par, u16 regno)
 {
-#if defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_OPSPUT) || 
defined(CONFIG_PLAT_MAPPI3)
-   regno=((regno & 1) ? (regno & ~1L) : (regno + 1));
-#endif
return readb(par->regs + regno);
 }
 
 static inline void
 s1d13xxxfb_writereg(struct s1d13xxxfb_par *par, u16 regno, u8 value)
 {
-#if defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_OPSPUT) || 
defined(CONFIG_PLAT_MAPPI3)
-   regno=((regno & 1) ? (regno & ~1L) : (regno + 1));
-#endif
writeb(value, par->regs + regno);
 }
 
@@ -296,11 +290,7 @@ s1d13xxxfb_setcolreg(u_int regno, u_int red, u_int green, 
u_int blue,
dbg("s1d13xxxfb_setcolreg: pseudo %d, val %08x\n",
regno, pseudo_val);
 
-#if defined(CONFIG_PLAT_MAPPI)
-   ((u32 *)info->pseudo_palette)[regno] = 
cpu_to_le16(pseudo_val);
-#else
((u32 *)info->pseudo_palette)[regno] = pseudo_val;
-#endif
 
break;
case FB_VISUAL_PSEUDOCOLOR:
-- 
2.9.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 17/47] fbdev: remove blackfin drivers

[Arnd Bergmann]

The blackfin architecture is getting removed, this removes the
associated fbdev drivers as well.

Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/Kconfig| 103 
 drivers/video/fbdev/Makefile   |   5 -
 drivers/video/fbdev/bf537-lq035.c  | 891 -
 drivers/video/fbdev/bf54x-lq043fb.c| 764 
 drivers/video/fbdev/bfin-lq035q1-fb.c  | 864 
 drivers/video/fbdev/bfin-t350mcqb-fb.c | 669 -
 drivers/video/fbdev/bfin_adv7393fb.c   | 828 --
 drivers/video/fbdev/bfin_adv7393fb.h   | 319 
 8 files changed, 4443 deletions(-)
 delete mode 100644 drivers/video/fbdev/bf537-lq035.c
 delete mode 100644 drivers/video/fbdev/bf54x-lq043fb.c
 delete mode 100644 drivers/video/fbdev/bfin-lq035q1-fb.c
 delete mode 100644 drivers/video/fbdev/bfin-t350mcqb-fb.c
 delete mode 100644 drivers/video/fbdev/bfin_adv7393fb.c
 delete mode 100644 drivers/video/fbdev/bfin_adv7393fb.h

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 11e699f1062b..399573742487 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -580,109 +580,6 @@ config FB_VGA16
  To compile this driver as a module, choose M here: the
  module will be called vga16fb.
 
-config FB_BF54X_LQ043
-   tristate "SHARP LQ043 TFT LCD (BF548 EZKIT)"
-   depends on FB && (BF54x) && !BF542
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   help
-This is the framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD
-
-config FB_BFIN_T350MCQB
-   tristate "Varitronix COG-T350MCQB TFT LCD display (BF527 EZKIT)"
-   depends on FB && BLACKFIN
-   select BFIN_GPTIMERS
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   help
-This is the framebuffer device driver for a Varitronix 
VL-PS-COG-T350MCQB-01 display TFT LCD
-This display is a QVGA 320x240 24-bit RGB display interfaced by an 
8-bit wide PPI
-It uses PPI[0..7] PPI_FS1, PPI_FS2 and PPI_CLK.
-
-config FB_BFIN_LQ035Q1
-   tristate "SHARP LQ035Q1DH02 TFT LCD"
-   depends on FB && BLACKFIN && SPI
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   select BFIN_GPTIMERS
-   help
- This is the framebuffer device driver for a SHARP LQ035Q1DH02 TFT 
display found on
- the Blackfin Landscape LCD EZ-Extender Card.
- This display is a QVGA 320x240 18-bit RGB display interfaced by an 
16-bit wide PPI
- It uses PPI[0..15] PPI_FS1, PPI_FS2 and PPI_CLK.
-
- To compile this driver as a module, choose M here: the
- module will be called bfin-lq035q1-fb.
-
-config FB_BF537_LQ035
-   tristate "SHARP LQ035 TFT LCD (BF537 STAMP)"
-   depends on FB && (BF534 || BF536 || BF537) && I2C_BLACKFIN_TWI
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   select BFIN_GPTIMERS
-   help
- This is the framebuffer device for a SHARP LQ035Q7DB03 TFT LCD
- attached to a BF537.
-
- To compile this driver as a module, choose M here: the
- module will be called bf537-lq035.
-
-config FB_BFIN_7393
-   tristate "Blackfin ADV7393 Video encoder"
-   depends on FB && BLACKFIN
-   select I2C
-   select FB_CFB_FILLRECT
-   select FB_CFB_COPYAREA
-   select FB_CFB_IMAGEBLIT
-   help
- This is the framebuffer device for a ADV7393 video encoder
- attached to a Blackfin on the PPI port.
- If your Blackfin board has a ADV7393 select Y.
-
- To compile this driver as a module, choose M here: the
- module will be called bfin_adv7393fb.
-
-choice
-   prompt  "Video mode support"
-   depends on FB_BFIN_7393
-   default NTSC
-
-config NTSC
-   bool 'NTSC 720x480'
-
-config PAL
-   bool 'PAL 720x576'
-
-config NTSC_640x480
-   bool 'NTSC 640x480 (Experimental)'
-
-config PAL_640x480
-   bool 'PAL 640x480 (Experimental)'
-
-config NTSC_YCBCR
-   bool 'NTSC 720x480 YCbCR input'
-
-config PAL_YCBCR
-   bool 'PAL 720x576 YCbCR input'
-
-endchoice
-
-choice
-   prompt  "Size of ADV7393 frame buffer memory Single/Double Size"
-   depends on (FB_BFIN_7393)
-   default ADV7393_1XMEM
-
-config ADV7393_1XMEM
-   bool 'Single'
-
-config ADV7393_2XMEM
-   bool 'Double'
-endchoice
-
 config FB_STI
tristate "HP STI frame buffer device support"
depends on FB && PARISC
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 115961e0721b..55282a21b500 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -136,11 +136,6 @@ obj-$(CONFIG_FB_VESA) += vesafb.o
 obj-$(CONFIG_FB_EFI)  += 

[PATCH 16/47] video/logo: remove obsolete logo files

[Arnd Bergmann]

The blackfin and m32r architectures are getting removed, so it's
time to clean up the logos as well.

Signed-off-by: Arnd Bergmann 
---
 drivers/video/logo/Kconfig   |   15 -
 drivers/video/logo/Makefile  |3 -
 drivers/video/logo/logo.c|   12 -
 drivers/video/logo/logo_blackfin_clut224.ppm | 1127 --
 drivers/video/logo/logo_blackfin_vga16.ppm   | 1127 --
 drivers/video/logo/logo_m32r_clut224.ppm | 1292 --
 include/linux/linux_logo.h   |3 -
 7 files changed, 3579 deletions(-)
 delete mode 100644 drivers/video/logo/logo_blackfin_clut224.ppm
 delete mode 100644 drivers/video/logo/logo_blackfin_vga16.ppm
 delete mode 100644 drivers/video/logo/logo_m32r_clut224.ppm

diff --git a/drivers/video/logo/Kconfig b/drivers/video/logo/Kconfig
index 0037104d66ac..d1f6196c8b9a 100644
--- a/drivers/video/logo/Kconfig
+++ b/drivers/video/logo/Kconfig
@@ -27,16 +27,6 @@ config LOGO_LINUX_CLUT224
bool "Standard 224-color Linux logo"
default y
 
-config LOGO_BLACKFIN_VGA16
-   bool "16-colour Blackfin Processor Linux logo"
-   depends on BLACKFIN
-   default y
-
-config LOGO_BLACKFIN_CLUT224
-   bool "224-colour Blackfin Processor Linux logo"
-   depends on BLACKFIN
-   default y
-
 config LOGO_DEC_CLUT224
bool "224-color Digital Equipment Corporation Linux logo"
depends on MACH_DECSTATION || ALPHA
@@ -77,9 +67,4 @@ config LOGO_SUPERH_CLUT224
depends on SUPERH
default y
 
-config LOGO_M32R_CLUT224
-   bool "224-color M32R Linux logo"
-   depends on M32R
-   default y
-
 endif # LOGO
diff --git a/drivers/video/logo/Makefile b/drivers/video/logo/Makefile
index 6194373ee424..228a89b9bdd1 100644
--- a/drivers/video/logo/Makefile
+++ b/drivers/video/logo/Makefile
@@ -5,8 +5,6 @@ obj-$(CONFIG_LOGO)  += logo.o
 obj-$(CONFIG_LOGO_LINUX_MONO)  += logo_linux_mono.o
 obj-$(CONFIG_LOGO_LINUX_VGA16) += logo_linux_vga16.o
 obj-$(CONFIG_LOGO_LINUX_CLUT224)   += logo_linux_clut224.o
-obj-$(CONFIG_LOGO_BLACKFIN_CLUT224)+= logo_blackfin_clut224.o
-obj-$(CONFIG_LOGO_BLACKFIN_VGA16)  += logo_blackfin_vga16.o
 obj-$(CONFIG_LOGO_DEC_CLUT224) += logo_dec_clut224.o
 obj-$(CONFIG_LOGO_MAC_CLUT224) += logo_mac_clut224.o
 obj-$(CONFIG_LOGO_PARISC_CLUT224)  += logo_parisc_clut224.o
@@ -15,7 +13,6 @@ obj-$(CONFIG_LOGO_SUN_CLUT224)+= 
logo_sun_clut224.o
 obj-$(CONFIG_LOGO_SUPERH_MONO) += logo_superh_mono.o
 obj-$(CONFIG_LOGO_SUPERH_VGA16)+= logo_superh_vga16.o
 obj-$(CONFIG_LOGO_SUPERH_CLUT224)  += logo_superh_clut224.o
-obj-$(CONFIG_LOGO_M32R_CLUT224)+= logo_m32r_clut224.o
 
 obj-$(CONFIG_SPU_BASE) += logo_spe_clut224.o
 
diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
index 4d50bfd13e7c..36aa050f9a21 100644
--- a/drivers/video/logo/logo.c
+++ b/drivers/video/logo/logo.c
@@ -63,10 +63,6 @@ const struct linux_logo * __ref fb_find_logo(int depth)
/* Generic Linux logo */
logo = _linux_vga16;
 #endif
-#ifdef CONFIG_LOGO_BLACKFIN_VGA16
-   /* Blackfin processor logo */
-   logo = _blackfin_vga16;
-#endif
 #ifdef CONFIG_LOGO_SUPERH_VGA16
/* SuperH Linux logo */
logo = _superh_vga16;
@@ -78,10 +74,6 @@ const struct linux_logo * __ref fb_find_logo(int depth)
/* Generic Linux logo */
logo = _linux_clut224;
 #endif
-#ifdef CONFIG_LOGO_BLACKFIN_CLUT224
-   /* Blackfin Linux logo */
-   logo = _blackfin_clut224;
-#endif
 #ifdef CONFIG_LOGO_DEC_CLUT224
/* DEC Linux logo on MIPS/MIPS64 or ALPHA */
logo = _dec_clut224;
@@ -107,10 +99,6 @@ const struct linux_logo * __ref fb_find_logo(int depth)
/* SuperH Linux logo */
logo = _superh_clut224;
 #endif
-#ifdef CONFIG_LOGO_M32R_CLUT224
-   /* M32R Linux logo */
-   logo = _m32r_clut224;
-#endif
}
return logo;
 }
diff --git a/drivers/video/logo/logo_blackfin_clut224.ppm 
b/drivers/video/logo/logo_blackfin_clut224.ppm
deleted file mode 100644
index dc9a50a14477..
diff --git a/drivers/video/logo/logo_blackfin_vga16.ppm 
b/drivers/video/logo/logo_blackfin_vga16.ppm
deleted file mode 100644
index 1352b02a9d93..
diff --git a/drivers/video/logo/logo_m32r_clut224.ppm 
b/drivers/video/logo/logo_m32r_clut224.ppm
deleted file mode 100644
index 8b2983c5a0bd..
diff --git a/include/linux/linux_logo.h b/include/linux/linux_logo.h
index 5e3581d76c7f..d4d5b93efe84 100644
--- a/include/linux/linux_logo.h
+++ b/include/linux/linux_logo.h
@@ -36,8 +36,6 @@ struct linux_logo {
 extern const struct linux_logo logo_linux_mono;
 extern const struct linux_logo 

Re: [PATCH] drm/bridge: dw-hdmi: Remove unused hdmi_enable_overflow_interrupts()

[Fabio Estevam]

Hi Laurent,

On Mon, Feb 19, 2018 at 4:50 PM, Laurent Pinchart
 wrote:
> Hi Fabio,
>
> Thank you for the patch.
>
> On Friday, 16 February 2018 22:16:10 EET Fabio Estevam wrote:
>> From: Fabio Estevam 
>>
>> The cable_plugin member never receives an assignment, so it is always
>> false, which causes hdmi_enable_overflow_interrupts() to never
>> be called as per the logic below:
>>
>>   if (hdmi->cable_plugin && hdmi->sink_is_hdmi)
>>   hdmi_enable_overflow_interrupts(hdmi);
>>
>> This has been the case since the driver was originally introduced
>> in commit 9aaf880ed4ee ("imx-drm: Add mx6 hdmi transmitter support").
>>
>> Remove the cable_plugin element and the hdmi_enable_overflow_interrupts()
>> function that is never called.
>>
>> Signed-off-by: Fabio Estevam 
>
> Tested-by: Laurent Pinchart  # On R-Car H3
> Reviewed-by: Laurent Pinchart 

Are you able to apply this patch or should Archit Taneja handle it?

Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [DPU PATCH 02/11] drm/msm: Don't duplicate modeset_enables atomic helper

[Sean Paul]

On Tue, Mar 13, 2018 at 04:57:35PM -0700, Jeykumar Sankaran wrote:
> On 2018-03-12 13:21, Sean Paul wrote:
> > On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote:
> > > On 2018-02-28 11:18, Sean Paul wrote:
> > > > Instead, shuffle things around so we kickoff crtc after enabling
> > encoder
> > > > during modesets. Also moves the vblank wait to after the frame.
> > > >
> > > > Change-Id: I16c7b7f9390d04f6050aa20e17a5335fbf49eba3
> > > > Signed-off-by: Sean Paul 
> > > > ---
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|   9 ++
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |   5 +-
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c |  31 -
> > > >  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |   2 +
> > > >  drivers/gpu/drm/msm/msm_atomic.c| 132
> > +---
> > > >  5 files changed, 48 insertions(+), 131 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > index a3ab6ed2bf1d..94fab2dcca5b 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > > @@ -3525,6 +3525,12 @@ static void dpu_crtc_enable(struct drm_crtc
> > > > *crtc,
> > > > DPU_EVT32_VERBOSE(DRMID(crtc));
> > > > dpu_crtc = to_dpu_crtc(crtc);
> > > >
> > > > +   if (msm_is_mode_seamless(>state->adjusted_mode) ||
> > > > +   msm_is_mode_seamless_vrr(>state->adjusted_mode)) {
> > > > +   DPU_DEBUG("Skipping crtc enable, seamless mode\n");
> > > > +   return;
> > > > +   }
> > > > +
> > > > pm_runtime_get_sync(crtc->dev->dev);
> > > >
> > > > drm_for_each_encoder(encoder, crtc->dev) {
> > > > @@ -3572,6 +3578,9 @@ static void dpu_crtc_enable(struct drm_crtc
> > *crtc,
> > > > DPU_POWER_EVENT_POST_ENABLE | 
> > > > DPU_POWER_EVENT_POST_DISABLE
> > > > |
> > > > DPU_POWER_EVENT_PRE_DISABLE,
> > > > dpu_crtc_handle_power_event, crtc, dpu_crtc->name);
> > > > +
> > > > +   if (msm_needs_vblank_pre_modeset(>state->adjusted_mode))
> > > > +   drm_crtc_wait_one_vblank(crtc);
> > > >  }
> > > >
> > > >  struct plane_state {
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > > index 28ceb589ee40..4d1e3652dbf4 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > > @@ -3693,8 +3693,11 @@ static void
> > dpu_encoder_frame_done_timeout(struct
> > > > timer_list *t)
> > > >  static const struct drm_encoder_helper_funcs dpu_encoder_helper_funcs
> > =
> > > > {
> > > > .mode_set = dpu_encoder_virt_mode_set,
> > > > .disable = dpu_encoder_virt_disable,
> > > > -   .enable = dpu_encoder_virt_enable,
> > > > +   .enable = dpu_kms_encoder_enable,
> > > > .atomic_check = dpu_encoder_virt_atomic_check,
> > > > +
> > > > +   /* This is called by dpu_kms_encoder_enable */
> > > > +   .commit = dpu_encoder_virt_enable,
> > > >  };
> > > >
> > > >  static const struct drm_encoder_funcs dpu_encoder_funcs = {
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > > index 81fd3a429e9f..3d83037e8305 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
> > > > @@ -425,14 +425,37 @@ static void dpu_kms_prepare_commit(struct
> > msm_kms
> > > > *kms,
> > > > dpu_encoder_prepare_commit(encoder);
> > > >  }
> > > >
> > > > -static void dpu_kms_commit(struct msm_kms *kms,
> > > > -   struct drm_atomic_state *old_state)
> > > > +/*
> > > > + * Override the encoder enable since we need to setup the inline
> > > > rotator
> > > > and do
> > > > + * some crtc magic before enabling any bridge that might be present.
> > > > + */
> > > > +void dpu_kms_encoder_enable(struct drm_encoder *encoder)
> > > > +{
> > > > +   const struct drm_encoder_helper_funcs *funcs =
> > > > encoder->helper_private;
> > > > +   struct drm_crtc *crtc = encoder->crtc;
> > > > +
> > > > +   /* Forward this enable call to the commit hook */
> > > > +   if (funcs && funcs->commit)
> > > > +   funcs->commit(encoder);
> > > 
> > > The purpose of this function is not clear. Where are we setting up the
> > > inline rotator?
> > > Why do we need a kickoff here?
> > 
> > The reason the code is shuffled is to avoid duplicating the entire
> > atomic
> > helper
> > function. By moving calls into the ->enable hooks, we can avoid having
> > to
> > hand
> > roll the helpers.
> > 
> > The kickoff is preserved from the helper copy when you call
> > kms->funcs->commit
> > in between the encoder enable and bridge enable. If this can be removed,
> > that'd
> > be even better. I was simply 

[maintainer-tools PATCH] doc: how to become a drm-intel committer

[Jani Nikula]

Until now, the drm-intel commit access have been handed out ad hoc,
without transparency, consistency, or fairness. With pressure to add
more committers, this is no longer tenable, if it ever was. Document the
requirements and expectations around becoming a drm-intel committer.

The Linux kernel operates in a model where, by and large, only
maintainers commit patches. Maintainer teams are no longer rare, but the
drm-intel and drm-misc maintainer/committer model is definitely an
outlier.

The drm-intel maintainers believe that a reasonable level of experience
and track record of working on the driver, as well as actively engaging
in the community upstream, are necessary before becoming a
committer. While the requirements outlined here may seem strict in
contrast with many projects, they are extremely liberal by kernel
standards.

Finally, no rules are carved in stone. We fully expect the requirements
to be adjusted later. However, it will be much easier to start strict
and relax the requirements later than the other way round.

Cc: Gustavo Padovan 
Cc: Maarten Lankhorst 
Cc: Sean Paul 
Cc: Dave Airlie 
Cc: dim-to...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Jani Nikula 
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Rodrigo Vivi 

---

We encourage the drm-misc maintainers to consider and document your
requirements for committers. While there's certain appeal to aligning on
the rules between drm-misc and drm-intel, we don't think they
necessarily have to be the same.
---
 commit-access.rst | 143 ++
 index.rst |   1 +
 2 files changed, 144 insertions(+)
 create mode 100644 commit-access.rst

diff --git a/commit-access.rst b/commit-access.rst
new file mode 100644
index ..dbc50f2b5bd3
--- /dev/null
+++ b/commit-access.rst
@@ -0,0 +1,143 @@
+===
+ Commit Access
+===
+
+The drm-misc and drm-intel repositories operate in a maintainer/committer model
+with a large pool committers who can push patches in accordance with the stated
+merge criteria, and maintainers handling pull requests, topic branches, merges,
+and so on.
+
+This document outlines the requirements for becoming a committer.
+
+drm-misc
+
+
+TBD.
+
+drm-intel
+-
+
+Requirements
+
+
+The baseline requirements for becoming a drm-intel committer are:
+
+- Comfortable with the open collaboration model we have.
+
+- Enough experience to gauge reasonably well how much review a patch needs, and
+  when pushing a patch, whether it needs acks from domain experts or
+  maintainers.
+
+- Strong presence in the project communication channels (intel-gfx mailing list
+  and #intel-gfx IRC channel) for topics in their area of expertise.
+
+Since everyone is different and has different focus in their work, there are no
+hard and fast rules, but just indicators and some judgement.
+
+Positive indicators are:
+
+- Decent amount of non-trivial patches merged in the past year (25+ patches,
+  excluding simple code movement, typo fixes and similar patches).
+
+- Decent amount of in-depth review, again 25+ in the past year as the 
threshold.
+
+- Lots of experience and commit rights in related open-source projects, like
+  Mesa, or kernel trees like drm-misc, since the processes are very similar. 2+
+  years as the threshold here, and this is also fulfilled after 2+ years of
+  working in the virtual upstream team (product tree hacking doesn't count).
+
+- Already merged a complex feature, e.g. spanning multiple subsystems or even
+  involving userspace.
+
+- Active member on freedesktop.org bugzilla. A developer that besides 
submitting
+  patches to fix bugs is also engaged on bugs discussion giving constructive
+  comments helping to drive the bug entry to a solution. Hence keeping bug list
+  active, clean, and under control.
+
+Contra-indicators are:
+
+- Not around on IRC (taking timezones into account of course).
+
+- Mostly simple patches and rubber-stamping reviews not resulting in in-depth
+  discussions.
+
+- No complete feature patch set merged yet.
+
+As a rule of thumb, commit rights will be granted when most positive indicators
+are fulfilled and no negative indicators present. The current project
+maintainers assess whether a candidate meets the requirements, and make the
+decisions about commit rights.
+
+Nomination
+~~
+
+Any developer, who already have demonstrated some of positive requirements, can
+be nominated at any time by anyone: maintainers, committers, managers, peers,
+and even self nomination are accepted.
+
+Nomination process is simply sending an email to the drm-intel
+maintainers. Please nominate one person per email, and Cc: the
+nominee. Nominations are processed by 

[DPU PATCH] drm/msm: Add pm_runtime_get/put calls to dpu

[Sean Paul]

Ensure that pm_runtime is properly referenced/unreferenced when we need
it.

Signed-off-by: Sean Paul 
---

Didn't get a response to my suggestion, so wrote the patch anyways.
Thoughts?


 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |  3 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c  |  2 ++
 drivers/gpu/drm/msm/dpu_power_handle.c   | 12 
 3 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f1642d72469e..df6cbeb15cf5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -3497,6 +3497,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
/* disable clk & bw control until clk & bw properties are set */
cstate->bw_control = false;
cstate->bw_split_vote = false;
+   pm_runtime_put_sync(crtc->dev->dev);
 
mutex_unlock(_crtc->crtc_lock);
 }
@@ -3523,6 +3524,8 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
DPU_EVT32_VERBOSE(DRMID(crtc));
dpu_crtc = to_dpu_crtc(crtc);
 
+   pm_runtime_get_sync(crtc->dev->dev);
+
drm_for_each_encoder(encoder, crtc->dev) {
if (encoder->crtc != crtc)
continue;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index fb4de59d8ed1..90608a303aec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -346,12 +346,14 @@ static void _dpu_debugfs_destroy(struct dpu_kms *dpu_kms)
 
 static int dpu_kms_enable_vblank(struct msm_kms *kms, struct drm_crtc *crtc)
 {
+   pm_runtime_get_sync(crtc->dev->dev);
return dpu_crtc_vblank(crtc, true);
 }
 
 static void dpu_kms_disable_vblank(struct msm_kms *kms, struct drm_crtc *crtc)
 {
dpu_crtc_vblank(crtc, false);
+   pm_runtime_put_sync(crtc->dev->dev);
 }
 
 static void dpu_kms_wait_for_frame_transfer_complete(struct msm_kms *kms,
diff --git a/drivers/gpu/drm/msm/dpu_power_handle.c 
b/drivers/gpu/drm/msm/dpu_power_handle.c
index 477ea9f2778c..a52be861117f 100644
--- a/drivers/gpu/drm/msm/dpu_power_handle.c
+++ b/drivers/gpu/drm/msm/dpu_power_handle.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -857,6 +858,9 @@ int dpu_power_resource_enable(struct dpu_power_handle 
*phandle,
return -EINVAL;
}
 
+   if (enable)
+   pm_runtime_get_sync(phandle->dev);
+
mp = >mp;
 
mutex_lock(>phandle_lock);
@@ -963,10 +967,6 @@ int dpu_power_resource_enable(struct dpu_power_handle 
*phandle,
DPU_POWER_EVENT_POST_DISABLE);
}
 
-end:
-   mutex_unlock(>phandle_lock);
-   return rc;
-
 clk_err:
dpu_power_rsc_update(phandle, false);
 rsc_err:
@@ -979,7 +979,11 @@ int dpu_power_resource_enable(struct dpu_power_handle 
*phandle,
dpu_power_data_bus_update(>data_bus_handle[i], 0);
 data_bus_hdl_err:
phandle->current_usecase_ndx = prev_usecase_ndx;
+
+end:
mutex_unlock(>phandle_lock);
+   if (!enable)
+   pm_runtime_put_sync(phandle->dev);
return rc;
 }
 
-- 
Sean Paul, Software Engineer, Google / Chromium OS

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: Store the calculated vrefresh in the user mode

[Ville Syrjälä]

On Tue, Mar 13, 2018 at 08:04:03PM +0100, Maarten Lankhorst wrote:
> Op 13-03-18 om 16:07 schreef Ville Syrjala:
> > From: Ville Syrjälä 
> >
> > Ignore the vrefresh in the mode the user passed in and instead
> > calculate the value based on the actual timings. This way we can
> > actually trust mode->vrefresh to some degree.
> >
> > Or should we compare the user's idea of vrefresh with the one
> > we get from the timings and return an error if they differ? We
> > can't really be sure what the user is asking in that case.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_modes.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index f6b7c0e36a1a..021526ec6fa0 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1609,7 +1609,11 @@ int drm_mode_convert_umode(struct drm_device *dev,
> > out->vsync_end = in->vsync_end;
> > out->vtotal = in->vtotal;
> > out->vscan = in->vscan;
> > -   out->vrefresh = in->vrefresh;
> > +/*
> > + * Ignore what the user is saying here and instead
> > + * calculate vrefresh based on the actual timings.
> > + */
> > +   out->vrefresh = 0;
> > out->flags = in->flags;
> > out->type = in->type;
> > strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> > @@ -1619,6 +1623,8 @@ int drm_mode_convert_umode(struct drm_device *dev,
> > if (out->status != MODE_OK)
> > return -EINVAL;
> >  
> > +   out->vrefresh = drm_mode_vrefresh(out);
> > +
> > drm_mode_set_crtcinfo(out, CRTC_INTERLACE_HALVE_V);
> >  
> > return 0;
> 
> Could we also get this with dim fixes tags dc911f5bd8aa, so we can backport 
> the alt mode handling patch?

Do we want/need to backport it actually?

> 
> And update the documentation about vrefresh, that you can retrieve it with 
> drm_mode_vrefresh?

The whole "return cached value if present, otherwise calculate but don't
update the cached value" apporach always seemed off to me. Might be a
good idea to change it somehow. Maybe just always calculate it, or do
the cached value updates in sensible places so that you only have to
calculate once. But I haven't actually checked how much work that
would entail.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

[Ville Syrjälä]

On Wed, Mar 14, 2018 at 02:56:28PM +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Do the refresh rate calculation with a single division. This gives
> > us slightly more accurate results, especially for interlaced since
> > we don't just double the final truncated result.
> > 
> > We do lose one bit compared to the old way, so with an interlaced
> > mode the new code can only handle ~2GHz instead of the ~4GHz the
> > old code handeled.
> > 
> > Signed-off-by: Ville Syrjälä 
> 
> I kinda want special integers here that Oops on overflow, I thought
> they're coming.

Would be nice indeed.

> That aside:
> 
> Reviewed-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_modes.c | 19 +--
> >  1 file changed, 9 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 4157250140b0..f6b7c0e36a1a 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -773,24 +773,23 @@ EXPORT_SYMBOL(drm_mode_hsync);
> >  int drm_mode_vrefresh(const struct drm_display_mode *mode)
> >  {
> > int refresh = 0;
> > -   unsigned int calc_val;
> >  
> > if (mode->vrefresh > 0)
> > refresh = mode->vrefresh;
> > else if (mode->htotal > 0 && mode->vtotal > 0) {
> > -   int vtotal;
> > -   vtotal = mode->vtotal;
> > -   /* work out vrefresh the value will be x1000 */
> > -   calc_val = (mode->clock * 1000);
> > -   calc_val /= mode->htotal;
> > -   refresh = (calc_val + vtotal / 2) / vtotal;
> > +   unsigned int num, den;
> > +
> > +   num = mode->clock * 1000;
> > +   den = mode->htotal * mode->vtotal;
> >  
> > if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > -   refresh *= 2;
> > +   num *= 2;
> > if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> > -   refresh /= 2;
> > +   den *= 2;
> > if (mode->vscan > 1)
> > -   refresh /= mode->vscan;
> > +   den *= mode->vscan;
> > +
> > +   refresh = DIV_ROUND_CLOSEST(num, den);
> > }
> > return refresh;
> >  }
> > -- 
> > 2.16.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/16] treewide: simplify Kconfig dependencies for removed archs

[Arnd Bergmann]

A lot of Kconfig symbols have architecture specific dependencies.
In those cases that depend on architectures we have already removed,
they can be omitted.

Signed-off-by: Arnd Bergmann 
---
 block/bounce.c   |  2 +-
 drivers/ide/Kconfig  |  2 +-
 drivers/ide/ide-generic.c| 12 +---
 drivers/input/joystick/analog.c  |  2 +-
 drivers/isdn/hisax/Kconfig   | 10 +-
 drivers/net/ethernet/davicom/Kconfig |  2 +-
 drivers/net/ethernet/smsc/Kconfig|  6 +++---
 drivers/net/wireless/cisco/Kconfig   |  2 +-
 drivers/pwm/Kconfig  |  2 +-
 drivers/rtc/Kconfig  |  2 +-
 drivers/spi/Kconfig  |  4 ++--
 drivers/usb/musb/Kconfig |  2 +-
 drivers/video/console/Kconfig|  3 +--
 drivers/watchdog/Kconfig |  6 --
 drivers/watchdog/Makefile|  6 --
 fs/Kconfig.binfmt|  5 ++---
 fs/minix/Kconfig |  2 +-
 include/linux/ide.h  |  7 +--
 init/Kconfig |  5 ++---
 lib/Kconfig.debug| 13 +
 lib/test_user_copy.c |  2 --
 mm/Kconfig   |  7 ---
 mm/percpu.c  |  4 
 23 files changed, 31 insertions(+), 77 deletions(-)

diff --git a/block/bounce.c b/block/bounce.c
index 6a3e68292273..dd0b93f2a871 100644
--- a/block/bounce.c
+++ b/block/bounce.c
@@ -31,7 +31,7 @@
 static struct bio_set *bounce_bio_set, *bounce_bio_split;
 static mempool_t *page_pool, *isa_page_pool;
 
-#if defined(CONFIG_HIGHMEM) || defined(CONFIG_NEED_BOUNCE_POOL)
+#if defined(CONFIG_HIGHMEM)
 static __init int init_emergency_pool(void)
 {
 #if defined(CONFIG_HIGHMEM) && !defined(CONFIG_MEMORY_HOTPLUG)
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index cf1fb3fb5d26..901b8833847f 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -200,7 +200,7 @@ comment "IDE chipset support/bugfixes"
 
 config IDE_GENERIC
tristate "generic/default IDE chipset support"
-   depends on ALPHA || X86 || IA64 || M32R || MIPS || ARCH_RPC
+   depends on ALPHA || X86 || IA64 || MIPS || ARCH_RPC
default ARM && ARCH_RPC
help
  This is the generic IDE driver.  This driver attaches to the
diff --git a/drivers/ide/ide-generic.c b/drivers/ide/ide-generic.c
index 54d7c4685d23..80c0d69b83ac 100644
--- a/drivers/ide/ide-generic.c
+++ b/drivers/ide/ide-generic.c
@@ -13,13 +13,10 @@
 #include 
 #include 
 
-/* FIXME: convert arm and m32r to use ide_platform host driver */
+/* FIXME: convert arm to use ide_platform host driver */
 #ifdef CONFIG_ARM
 #include 
 #endif
-#ifdef CONFIG_M32R
-#include 
-#endif
 
 #define DRV_NAME   "ide_generic"
 
@@ -35,13 +32,6 @@ static const struct ide_port_info ide_generic_port_info = {
 #ifdef CONFIG_ARM
 static const u16 legacy_bases[] = { 0x1f0 };
 static const int legacy_irqs[]  = { IRQ_HARDDISK };
-#elif defined(CONFIG_PLAT_M32700UT) || defined(CONFIG_PLAT_MAPPI2) || \
-  defined(CONFIG_PLAT_OPSPUT)
-static const u16 legacy_bases[] = { 0x1f0 };
-static const int legacy_irqs[]  = { PLD_IRQ_CFIREQ };
-#elif defined(CONFIG_PLAT_MAPPI3)
-static const u16 legacy_bases[] = { 0x1f0, 0x170 };
-static const int legacy_irqs[]  = { PLD_IRQ_CFIREQ, PLD_IRQ_IDEIREQ };
 #elif defined(CONFIG_ALPHA)
 static const u16 legacy_bases[] = { 0x1f0, 0x170, 0x1e8, 0x168 };
 static const int legacy_irqs[]  = { 14, 15, 11, 10 };
diff --git a/drivers/input/joystick/analog.c b/drivers/input/joystick/analog.c
index be1b4921f22a..eefac7978f93 100644
--- a/drivers/input/joystick/analog.c
+++ b/drivers/input/joystick/analog.c
@@ -163,7 +163,7 @@ static unsigned int get_time_pit(void)
 #define GET_TIME(x)do { x = (unsigned int)rdtsc(); } while (0)
 #define DELTA(x,y) ((y)-(x))
 #define TIME_NAME  "TSC"
-#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || 
defined(CONFIG_RISCV) || defined(CONFIG_TILE)
+#elif defined(__alpha__) || defined(CONFIG_ARM) || defined(CONFIG_ARM64) || 
defined(CONFIG_RISCV)
 #define GET_TIME(x)do { x = get_cycles(); } while (0)
 #define DELTA(x,y) ((y)-(x))
 #define TIME_NAME  "get_cycles"
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index eb83d94ab4fe..38cfc8baae19 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -109,7 +109,7 @@ config HISAX_16_3
 
 config HISAX_TELESPCI
bool "Teles PCI"
-   depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS 
&& !CPU_LITTLE_ENDIAN) || FRV || (XTENSA && !CPU_LITTLE_ENDIAN)))
+   depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS 
&& !CPU_LITTLE_ENDIAN) || (XTENSA && !CPU_LITTLE_ENDIAN)))
help
  This enables HiSax support for the Teles PCI.
  See  on how to configure it.
@@ -237,7 +237,7 @@ config HISAX_MIC
 
 config HISAX_NETJET
  

[PATCH 00/16] remove eight obsolete architectures

[Arnd Bergmann]

Here is the collection of patches I have applied to my 'asm-generic' tree
on top of the 'metag' removal. This does not include any of the device
drivers, I'll send those separately to a someone different list of people.

The removal came out of a discussion that is now documented at
https://lwn.net/Articles/748074/

Following up from the state described there, I ended up removing the
mn10300, tile, blackfin and cris architectures directly, rather than
waiting, after consulting with the respective maintainers.

However, the unicore32 architecture is no longer part of the removal,
after its maintainer Xuetao Guan said that the port is still actively
being used and that he intends to keep working on it, and that he will
try to provide updated toolchain sources.

In the end, it seems that while the eight architectures are extremely
different, they all suffered the same fate: There was one company in
charge of an SoC line, a CPU microarchitecture and a software ecosystem,
which was more costly than licensing newer off-the-shelf CPU cores from
a third party (typically ARM, MIPS, or RISC-V). It seems that all the
SoC product lines are still around, but have not used the custom CPU
architectures for several years at this point.

  Arnd

Arnd Bergmann (14):
  arch: remove frv port
  arch: remove m32r port
  arch: remove score port
  arch: remove blackfin port
  arch: remove tile port
  procfs: remove CONFIG_HARDWALL dependency
  mm: remove blackfin MPU support
  mm: remove obsolete alloc_remap()
  treewide: simplify Kconfig dependencies for removed archs
  asm-generic: siginfo: remove obsolete #ifdefs
  Documentation: arch-support: remove obsolete architectures
  asm-generic: clean up asm/unistd.h
  recordmcount.pl: drop blackin and tile support
  ktest: remove obsolete architectures

David Howells (1):
  mn10300: Remove the architecture

Jesper Nilsson (1):
  CRIS: Drop support for the CRIS port

Dirstat only (full diffstat is over 100KB):

   6.3% arch/blackfin/mach-bf548/include/mach/
   4.5% arch/blackfin/mach-bf609/include/mach/
  26.3% arch/blackfin/
   4.1% arch/cris/arch-v32/
   5.6% arch/cris/include/arch-v32/arch/hwregs/iop/
   4.1% arch/cris/include/arch-v32/mach-a3/mach/hwregs/
   4.7% arch/cris/include/arch-v32/
   7.8% arch/cris/
   5.6% arch/frv/
   5.5% arch/m32r/
   7.0% arch/mn10300/
   7.6% arch/tile/include/
   6.4% arch/tile/kernel/
   0.0% Documentation/admin-guide/
   0.0% Documentation/blackfin/
   0.0% Documentation/cris/
   0.0% Documentation/devicetree/bindings/cris/
   0.0% Documentation/devicetree/bindings/interrupt-controller/
   2.8% Documentation/features/
   0.5% Documentation/frv/
   0.0% Documentation/ioctl/
   0.0% Documentation/mn10300/
   0.0% Documentation/
   0.0% block/
   0.0% crypto/
   0.0% drivers/ide/
   0.0% drivers/input/joystick/
   0.0% drivers/isdn/hisax/
   0.0% drivers/net/ethernet/davicom/
   0.0% drivers/net/ethernet/smsc/
   0.0% drivers/net/wireless/cisco/
   0.0% drivers/pci/
   0.0% drivers/pwm/
   0.0% drivers/rtc/
   0.0% drivers/spi/
   0.0% drivers/staging/speakup/
   0.0% drivers/usb/musb/
   0.0% drivers/video/console/
   0.0% drivers/watchdog/
   0.0% fs/minix/
   0.0% fs/proc/
   0.0% fs/
   0.0% include/asm-generic/
   0.0% include/linux/
   0.0% include/uapi/asm-generic/
   0.0% init/
   0.0% kernel/
   0.0% lib/
   0.0% mm/
   0.0% samples/blackfin/
   0.0% samples/kprobes/
   0.0% samples/
   0.0% scripts/mod/
   0.0% scripts/
   0.0% tools/arch/frv/include/uapi/asm/
   0.0% tools/arch/m32r/include/uapi/asm/
   0.0% tools/arch/mn10300/include/uapi/asm/
   0.0% tools/arch/score/include/uapi/asm/
   0.0% tools/arch/tile/include/asm/
   0.0% tools/arch/tile/include/uapi/asm/
   0.0% tools/include/asm-generic/
   0.0% tools/scripts/
   0.0% tools/testing/ktest/examples/
   0.0% tools/testing/ktest/

Cc: linux-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-bl...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-wirel...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: linux-watch...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux...@kvack.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105505] Request for new account

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105505

Daniel Stone  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Daniel Stone  ---
Done - you should be able to push to ssh://git.freedesktop.org/git/drm/drm-misc
in a few minutes.

-- 
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 105505] Request for new account

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105505

--- Comment #1 from tomi.valkei...@iki.fi  ---
Created attachment 138104
  --> https://bugs.freedesktop.org/attachment.cgi?id=138104=edit
GPG pub key

-- 
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 105505] Request for new account

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105505

Bug ID: 105505
   Summary: Request for new account
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tomi.valkei...@iki.fi

Created attachment 138103
  --> https://bugs.freedesktop.org/attachment.cgi?id=138103=edit
ssh pub key

Request for new account, for drm-misc push rights.

Name: Tomi Valkeinen
Email: tomi.valkei...@iki.fi
Preferred account name: tomba

-- 
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 v8 11/11] drm: Add and handle new aspect ratios in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 9dc54ce..76abe4d 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1657,6 +1657,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case HDMI_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1720,6 +1726,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50bcf42..4b3a1bb 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -93,6 +93,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -102,6 +104,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
 DRM_MODE_FLAG_NHSYNC | \
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 10/11] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
---
 drivers/gpu/drm/drm_fb_helper.c | 12 ++--
 drivers/gpu/drm/drm_modes.c | 35 ++-
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 035784d..8fa4e78 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
-   if (!drm_mode_equal(modes[j], modes[i]))
+   if (!drm_mode_match(modes[j], modes[i],
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
can_clone = false;
}
}
@@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
 
fb_helper_conn = fb_helper->connector_info[i];
list_for_each_entry(mode, _helper_conn->connector->modes, 
head) {
-   if (drm_mode_equal(mode, dmt_mode))
+   if (drm_mode_match(mode, dmt_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
modes[i] = mode;
}
if (!modes[i])
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 36e2abc..9dc54ce 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1050,7 +1050,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
 }
 EXPORT_SYMBOL(drm_mode_equal);
 
@@ -1648,6 +1649,20 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1692,6 +1707,24 @@ int drm_mode_convert_umode(struct drm_device *dev,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* 

[PATCH v8 09/11] drm: Expose modes with aspect ratio, only if requested

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space requested this information or not.

This patch prunes the modes with aspect-ratio information, from a
connector's modelist, if the user-space has not set the aspect ratio
DRM client cap.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
 instead only flags bits of user mode are reset (if aspect-ratio
 is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
---
 drivers/gpu/drm/drm_connector.c | 40 
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b3cde89..5420325 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1531,8 +1531,10 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
 }
 
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct drm_display_mode *last_mode,
+const struct drm_file *file_priv)
 {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
@@ -1540,6 +1542,26 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes with
+* aspect-ratio, don't expose them. But in case of a unique mode, let
+* the mode be passed, so that it can be enumerated with aspect-ratio
+* bits erased.
+*
+* It is assumed here, that the list of modes for a given connector, is
+* sorted, such that modes that have different aspect-ratios, but are
+* otherwise identical, are back to back.
+* This way, saving the last valid mode, and matching it with the
+* current mode will help in determining, if the current mode is unique.
+*/
+   if (!file_priv->aspect_ratio_allowed &&
+   mode->picture_aspect_ratio != HDMI_PICTURE_ASPECT_NONE &&
+   last_mode && drm_mode_match(mode, last_mode,
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
+   return false;
 
return true;
 }
@@ -1551,6 +1573,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_display_mode *mode;
+   struct drm_display_mode *last_valid_mode;
int mode_count = 0;
int encoders_count = 0;
int ret = 0;
@@ -1606,9 +1629,13 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
out_resp->connection = connector->status;
 
/* delayed so we get modes regardless of pre-fill_modes state */
+   last_valid_mode = NULL;
list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(mode, last_valid_mode,
+file_priv)) {
mode_count++;
+   last_valid_mode = mode;
+   }
 
/*
 * This ioctl is called twice, once to determine how much space is
@@ -1617,11 +1644,15 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
if ((out_resp->count_modes >= mode_count) && mode_count) {
copied = 0;
mode_ptr = (struct drm_mode_modeinfo __user *)(unsigned 
long)out_resp->modes_ptr;
+   last_valid_mode = NULL;
list_for_each_entry(mode, >modes, head) {
-   if 

[PATCH v8 02/11] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 788fee4..cfd8ead 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3048,7 +3048,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 07/11] drm: Handle aspect-ratio info in getblob

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, then getblob called
with the blob id of a user-mode, should clear the aspect-ratio
information in the blob data.

Currently for a given blob id, there is no way to determine if the
blob stores user-mode or not. This can only be ascertained when the
blob is used for an atomic modeset call.

This patch:
-adds a new field 'is_video_mode' in drm_property_blob to
 differentiate between the video mode blobs and the other blobs.
-sets the field 'is_video_mode' when the blob is used for modeset.
-removes the aspect-ratio info from the user-mode data if aspect-ratio
 is not supported by the user, while returning the blob to the user,
 in getblob ioctl.

Signed-off-by: Ankit Nautiyal 

V5: This patch is introduced in the rev-5 of the series.
V6: As suggested by Ville:
-added helper functions for determining if aspect-ratio is
 expected in user-mode and for allowing/disallowing the
 aspect-ratio, if its not expected.
-avoided clobbering of blob-data, instead cleared the aspect-ratio
 in the user-mode only, so that another client with aspect-ratio
 cap, can still get the aspect-ratio information from getblob.
V7: Fixed warning [Wint-to-pointer-cast] for 32 bit platforms.
V8: Changed the parameter of aspect-ratio helper functions from 32 bit
flags to user-mode, to avoid passing random integers, as suggested
by Ville.
---
 drivers/gpu/drm/drm_atomic.c   |  1 +
 drivers/gpu/drm/drm_modes.c| 47 ++
 drivers/gpu/drm/drm_property.c |  5 +
 include/drm/drm_modes.h|  4 
 include/drm/drm_property.h |  2 ++
 5 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 34b7d42..2b1c88a 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -464,6 +464,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
else if (property == config->prop_mode_id) {
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
+   mode->is_video_mode = true;
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_blob_put(mode);
return ret;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index a48672c..36e2abc 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1761,3 +1761,50 @@ bool drm_mode_is_420(const struct drm_display_info 
*display,
drm_mode_is_420_also(display, mode);
 }
 EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_mode_aspect_ratio_allowed - checks if the aspect-ratio information
+ * is expected from the user-mode.
+ *
+ * If the user has set aspect-ratio cap, then the flag of the user-mode is
+ * allowed to contain aspect-ratio value.
+ * If the user does not set aspect-ratio cap, then the only value allowed in 
the
+ * flags bits is aspect-ratio NONE.
+ *
+ * @file_priv: file private structure to get the user capabilities
+ * @umode: drm_mode_modeinfo struct, whose flag carry the aspect ratio
+ * information.
+ *
+ * Returns:
+ * true if the aspect-ratio info is allowed in the user-mode flags.
+ * false, otherwise.
+ */
+bool
+drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
+ struct drm_mode_modeinfo *umode)
+{
+   return file_priv->aspect_ratio_allowed || (umode->flags &
+   DRM_MODE_FLAG_PIC_AR_MASK) == DRM_MODE_FLAG_PIC_AR_NONE;
+}
+EXPORT_SYMBOL(drm_mode_aspect_ratio_allowed);
+
+/**
+ * drm_mode_filter_aspect_ratio_flags - filters the aspect-ratio bits in the
+ * user-mode flags.
+ *
+ * Checks if the aspect-ratio information is allowed. Resets the aspect-ratio
+ * bits in the user-mode flags, if aspect-ratio info is not allowed.
+ *
+ * @file_priv: file private structure to get the user capabilities.
+ * @umode: drm_mode_modeinfo struct, whose flags' aspect-ratio bits needs to
+ * be filtered.
+ *
+ */
+void
+drm_mode_filter_aspect_ratio_flags(const struct drm_file *file_priv,
+  struct drm_mode_modeinfo *umode)
+{
+   if (!drm_mode_aspect_ratio_allowed(file_priv, umode))
+   umode->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+}
+EXPORT_SYMBOL(drm_mode_filter_aspect_ratio_flags);
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 6ac6ee4..664cb57 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -770,6 +770,11 @@ int drm_mode_getblob_ioctl(struct drm_device *dev,
ret = -EFAULT;
goto unref;
}
+   if (blob->is_video_mode) {
+   struct drm_mode_modeinfo __user *mode =
+   u64_to_user_ptr(out_resp->data);
+   

[PATCH v8 08/11] drm: Handle aspect ratio info in legacy and atomic modeset paths

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

This patch:
1. passes the file_priv structure from the drm_mode_atomic_ioctl till
   the drm_mode_crtc_set_mode_prop, to get the user capability.
2. rejects the modes with aspect-ratio info, during modeset, if the
   user does not support aspect ratio.
3. does not load the aspect-ratio info in user-mode structure, if
   aspect ratio is not supported.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
---
 drivers/gpu/drm/drm_atomic.c| 35 +--
 drivers/gpu/drm/drm_atomic_helper.c |  6 +++---
 drivers/gpu/drm/drm_crtc.c  |  8 
 drivers/gpu/drm/drm_crtc_internal.h |  3 ++-
 drivers/gpu/drm/drm_mode_object.c   |  9 ++---
 include/drm/drm_atomic.h|  5 +++--
 6 files changed, 47 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2b1c88a..2155aa4 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -368,6 +368,7 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * drm_atomic_set_mode_prop_for_crtc - set mode for CRTC
  * @state: the CRTC whose incoming state to update
  * @blob: pointer to blob property to use for mode
+ * @file_priv: file priv structure, to get the userspace capabilities
  *
  * Set a mode (originating from a blob property) on the desired CRTC state.
  * This function will take a reference on the blob property for the CRTC state,
@@ -378,7 +379,8 @@ EXPORT_SYMBOL(drm_atomic_set_mode_for_crtc);
  * Zero on success, error code on failure. Cannot return -EDEADLK.
  */
 int drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
-  struct drm_property_blob *blob)
+ struct drm_property_blob *blob,
+ struct drm_file *file_priv)
 {
if (blob == state->mode_blob)
return 0;
@@ -389,10 +391,21 @@ int drm_atomic_set_mode_prop_for_crtc(struct 
drm_crtc_state *state,
memset(>mode, 0, sizeof(state->mode));
 
if (blob) {
-   if (blob->length != sizeof(struct drm_mode_modeinfo) ||
-   drm_mode_convert_umode(state->crtc->dev, >mode,
-  (const struct drm_mode_modeinfo *)
-   blob->data))
+   struct drm_mode_modeinfo *u_mode;
+
+   if (blob->length != sizeof(struct drm_mode_modeinfo))
+   return -EINVAL;
+
+   u_mode = (struct drm_mode_modeinfo *) blob->data;
+   if (!drm_mode_aspect_ratio_allowed(file_priv,
+  u_mode)) {
+   DRM_DEBUG_ATOMIC("Unexpected aspect-ratio flag bits\n");
+   return -EINVAL;
+   }
+
+   if (drm_mode_convert_umode(state->crtc->dev, >mode,
+  (const struct drm_mode_modeinfo *)
+  u_mode))
return -EINVAL;
 
state->mode_blob = drm_property_blob_get(blob);
@@ -441,6 +454,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  * @state: the state object to update with the new property value
  * @property: the property to set
  * @val: the new property value
+ * @file_priv: the file private structure, to get the user capabilities
  *
  * This function handles generic/core properties and calls out to driver's
  * _crtc_funcs.atomic_set_property for driver properties. To ensure
@@ -452,7 +466,7 @@ drm_atomic_replace_property_blob_from_id(struct drm_device 
*dev,
  */
 int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_crtc_state *state, struct drm_property *property,
-   uint64_t val)
+   uint64_t val, struct drm_file *file_priv)
 {
struct drm_device *dev = crtc->dev;
struct drm_mode_config *config = >mode_config;
@@ -465,7 +479,7 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
struct drm_property_blob *mode =
drm_property_lookup_blob(dev, val);
mode->is_video_mode = true;
-   ret = 

[PATCH v8 04/11] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Nautiyal, Ankit K]

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b635fca..8d87ab3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4841,6 +4841,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
 {
+   enum hdmi_picture_aspect picture_aspect;
int err;
 
if (!frame || !mode)
@@ -4883,13 +4884,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
 
+   /*
+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 06/11] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.

To avoid this, a new drm client cap is required to enable a
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.

This patch adds the client cap for aspect-ratio.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase

Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_ioctl.c | 5 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index af78291..54a98b7 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -325,6 +325,11 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
default:
return -EINVAL;
}
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 5176c37..02b7dde 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -182,6 +182,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True, if client can handle picture aspect ratios, and has requested
+* to pass this information along with the mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..9c660e1 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will provide aspect ratio information in modes.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 05/11] video/hdmi: Reject illegal picture aspect ratios

[Nautiyal, Ankit K]

From: Ville Syrjälä 

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Jose Abreu 
---
 drivers/video/hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 111a0ab..38716eb5 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
*frame, void *buffer,
if (size < length)
return -ENOSPC;
 
+   if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+   return -EINVAL;
+
memset(buffer, 0, size);
 
ptr[0] = frame->type;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 03/11] drm/edid: Fix cea mode aspect ratio handling

[Nautiyal, Ankit K]

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cfd8ead..b635fca 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2931,11 +2931,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2949,7 +2953,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2966,11 +2970,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2984,7 +2992,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3031,6 +3039,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3048,7 +3057,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3065,6 +3074,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3080,7 +3090,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if 

[PATCH v8 01/11] drm/modes: Introduce drm_mode_match()

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 5a8033f..a48672c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -940,17 +940,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -958,15 +1009,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode 

[PATCH v8 00/11] Aspect ratio support in DRM layer

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series also includes 5 patches from Ville Syrjälä's series for
'Info-frame cleanup and fixes':
https://patchwork.freedesktop.org/series/33730/ which fixes the mode
matching mechanism via flags, and also ensures that no bogus aspect-ratios
are sent in the AVI infoframes.

This patch series, adds a DRM client option for aspect ratio, and loads
aspect ratio flags, only when the client sets this cap. 

To test this patch, the testdiplay IGT test is modified to have an option
to do a modeset with only aspect ratio modes.
Also, there is a userspace implementation in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/
(Which is already ACK'ed by wayland community.)

This, helps us in passing HDMI compliance test cases like 7-27, where the
test equipment applies a CEA mode, and expects the exact VIC in the AVI
infoframes.

Ankit Nautiyal (4):
  drm: Add DRM client cap for aspect-ratio
  drm: Handle aspect-ratio info in getblob
  drm: Handle aspect ratio info in legacy and atomic modeset paths
  drm: Expose modes with aspect ratio, only if requested

Sharma, Shashank (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ville Syrjälä (5):
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix cea mode aspect ratio handling
  drm/edid: Don't send bogus aspect ratios in AVI infoframes
  video/hdmi: Reject illegal picture aspect ratios

 drivers/gpu/drm/drm_atomic.c|  36 --
 drivers/gpu/drm/drm_atomic_helper.c |   6 +-
 drivers/gpu/drm/drm_connector.c |  40 ++-
 drivers/gpu/drm/drm_crtc.c  |   8 ++
 drivers/gpu/drm/drm_crtc_internal.h |   3 +-
 drivers/gpu/drm/drm_edid.c  |  41 +--
 drivers/gpu/drm/drm_fb_helper.c |  12 +-
 drivers/gpu/drm/drm_ioctl.c |   5 +
 drivers/gpu/drm/drm_mode_object.c   |   9 +-
 drivers/gpu/drm/drm_modes.c | 226 +++-
 drivers/gpu/drm/drm_property.c  |   5 +
 drivers/video/hdmi.c|   3 +
 include/drm/drm_atomic.h|   5 +-
 include/drm/drm_file.h  |   8 ++
 include/drm/drm_modes.h |  13 +++
 include/drm/drm_property.h  |   2 +
 include/uapi/drm/drm.h  |   7 ++
 include/uapi/drm/drm_mode.h |   6 +
 18 files changed, 369 insertions(+), 66 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: Make drm_mode_vrefresh() a bit more accurate

[Daniel Vetter]

On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> Do the refresh rate calculation with a single division. This gives
> us slightly more accurate results, especially for interlaced since
> we don't just double the final truncated result.
> 
> We do lose one bit compared to the old way, so with an interlaced
> mode the new code can only handle ~2GHz instead of the ~4GHz the
> old code handeled.
> 
> Signed-off-by: Ville Syrjälä 

I kinda want special integers here that Oops on overflow, I thought
they're coming. That aside:

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_modes.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 4157250140b0..f6b7c0e36a1a 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -773,24 +773,23 @@ EXPORT_SYMBOL(drm_mode_hsync);
>  int drm_mode_vrefresh(const struct drm_display_mode *mode)
>  {
>   int refresh = 0;
> - unsigned int calc_val;
>  
>   if (mode->vrefresh > 0)
>   refresh = mode->vrefresh;
>   else if (mode->htotal > 0 && mode->vtotal > 0) {
> - int vtotal;
> - vtotal = mode->vtotal;
> - /* work out vrefresh the value will be x1000 */
> - calc_val = (mode->clock * 1000);
> - calc_val /= mode->htotal;
> - refresh = (calc_val + vtotal / 2) / vtotal;
> + unsigned int num, den;
> +
> + num = mode->clock * 1000;
> + den = mode->htotal * mode->vtotal;
>  
>   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> - refresh *= 2;
> + num *= 2;
>   if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
> - refresh /= 2;
> + den *= 2;
>   if (mode->vscan > 1)
> - refresh /= mode->vscan;
> + den *= mode->vscan;
> +
> + refresh = DIV_ROUND_CLOSEST(num, den);
>   }
>   return refresh;
>  }
> -- 
> 2.16.1
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199115] New: [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199115

Bug ID: 199115
   Summary: [gma500] BUG: unable to handle kernel NULL pointer
dereference at 0081
   Product: Drivers
   Version: 2.5
Kernel Version: 4.15.7-300.fc27.x86_64
  Hardware: x86-64
OS: Linux
  Tree: Fedora
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: domi...@greysector.net
Regression: No

Created attachment 274725
  --> https://bugzilla.kernel.org/attachment.cgi?id=274725=edit
journalctl -k  --no-hostname --no-pager output

I'm consistently getting this kernel NULL pointer dereference on a Thecus N5550
NAS box (Intel Atom D2550 CPU) on every boot if gma500_gfx module is not
blacklisted:

Mar 14 13:44:02 kernel: BUG: unable to handle kernel NULL pointer dereference
at 0081
Mar 14 13:44:02 kernel: IP: drm_fb_helper_is_bound.isra.16+0x5/0xa0
[drm_kms_helper]
Mar 14 13:44:03 kernel: PGD 0 P4D 0 
Mar 14 13:44:03 kernel: Oops:  [#1] SMP NOPTI
Mar 14 13:44:03 kernel: Modules linked in: it87 hwmon_vid vfat fat
snd_hda_codec_realtek snd_hda_codec_generic gma500_gfx snd_hda_codec_hdmi
iTCO_wdt iTCO_vendor_support snd
Mar 14 13:44:03 kernel: CPU: 0 PID: 277 Comm: kworker/0:2 Not tainted
4.15.7-300.fc27.x86_64 #1
Mar 14 13:44:03 kernel: Hardware name: Intel Corporation Milstead
Platform/Granite Well, BIOS CDV_T30 X64 09/17/2012
Mar 14 13:44:03 kernel: Workqueue: events output_poll_execute [drm_kms_helper]
Mar 14 13:44:03 kernel: RIP: 0010:drm_fb_helper_is_bound.isra.16+0x5/0xa0
[drm_kms_helper]
Mar 14 13:44:03 kernel: RSP: 0018:b118005ebe28 EFLAGS: 00010286
Mar 14 13:44:03 kernel: RAX:  RBX: 9da9b656c800 RCX:
e800
Mar 14 13:44:03 kernel: RDX: 9da9b632da00 RSI: 0031 RDI:
9da9b656c800
Mar 14 13:44:03 kernel: RBP: 9da9b656c8d0 R08: 000251a0 R09:

Mar 14 13:44:03 kernel: R10: f2ca40f61c00 R11:  R12:
0001
Mar 14 13:44:03 kernel: R13: 9da9b71e7800 R14: 9da9b71e79f8 R15:

Mar 14 13:44:03 kernel: FS:  () GS:9da9bb40()
knlGS:
Mar 14 13:44:03 kernel: CS:  0010 DS:  ES:  CR0: 80050033
Mar 14 13:44:03 kernel: CR2: 0081 CR3: 7b2a CR4:
06f0
Mar 14 13:44:03 kernel: Call Trace:
Mar 14 13:44:03 kernel:  drm_fb_helper_hotplug_event.part.29+0x34/0xb0
[drm_kms_helper]
Mar 14 13:44:03 kernel:  output_poll_execute+0x185/0x1b0 [drm_kms_helper]
Mar 14 13:44:03 kernel:  process_one_work+0x175/0x390
Mar 14 13:44:03 kernel:  worker_thread+0x2e/0x380
Mar 14 13:44:03 kernel:  ? process_one_work+0x390/0x390
Mar 14 13:44:03 kernel:  kthread+0x113/0x130
Mar 14 13:44:03 kernel:  ? kthread_create_worker_on_cpu+0x70/0x70
Mar 14 13:44:03 kernel:  ret_from_fork+0x1f/0x40
Mar 14 13:44:03 kernel: Code: 4c d0 f8 8b 45 20 39 c3 7c e6 83 e8 01 4c 89 ef
31 db 89 45 20 e8 6c b0 ea c4 eb 9f 83 c3 02 eb bf 0f 1f 44 00 00 0f 1f 44 00
00 <48> 8b 56 50 
Mar 14 13:44:03 kernel: RIP: drm_fb_helper_is_bound.isra.16+0x5/0xa0
[drm_kms_helper] RSP: b118005ebe28
Mar 14 13:44:03 kernel: CR2: 0081
Mar 14 13:44:03 kernel: ---[ end trace 0bc03676f9e43f5d ]---

Full dmesg attached.

-- 
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 105502] HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105502

--- Comment #1 from Harry Wentland  ---
Created attachment 138100
  --> https://bugs.freedesktop.org/attachment.cgi?id=138100=edit
[PATCH] drm/amd/display: Fix null pointer when setting backlight

My bad for pushing a patch that broke it. This should fix 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: [PATCH 0/3] drm/rockchip: VOP interrupt fixes

[Heiko Stübner]

Am Dienstag, 20. Februar 2018, 14:01:17 CET schrieb Marc Zyngier:
> This small series fixes a number of issues that I found while trying
> to get kexec working on the Chromebook Plus (aka rk3399-gru-kevin) in
> order to use it as some sort of interactive bootloader.
> 
> The main issue is that the vop driver expects the interrupts to be
> cleared and disabled when booting. Nothing could be more wrong. The
> device should be expected to be alive and screaming, and it is the
> driver's job to put it back into a sane state.
> 
> This is what the first patch does, making sure the interrupt is
> requested only when the device has been put back into a known
> state. Given that this is an observable bug that has been around for a
> while, I've tagged it with a Cc: stable.
> 
> The two following patches are less important: Using memcpy on MMIO
> ranges is plain wrong, and using spin_lock_irqsave in irq context is
> slightly pointless.
> 
> With these patches in, I'm able to get kexec to work. There is still
> some funny issues at the iommu level, but that's for another day.
> 
> Patches on top of 4.16-rc2.
> 
> Marc Zyngier (3):
>   drm/rockchip: Clear all interrupts before requesting the IRQ
>   drm/rockchip: Do not use memcpy for MMIO addresses
>   drm/rockchip: Don't use spin_lock_irqsave in interrupt context

Tested on rk3036 (hdmi), rk3288 (hdmi+edp) and rk3399 (edp) and
applied to drm-misc-next after slightly fixing patch1 for a recent change
to the code around the old request_irq position, so it applies.


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105502] HP Envy x360 15-bq101ng, backlight not ajustable, amdgpu, dc_link_set_backlight_level

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105502

Bug ID: 105502
   Summary: HP Envy x360 15-bq101ng, backlight not ajustable,
amdgpu, dc_link_set_backlight_level
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ch...@degree.at

Not sure if this is the correct place to report.
This error occured when using 1de5b5a91c4b101eedb825790a852a19b755faed from
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

Backlight is not ajustable

###
[2.321821] amdgpu: [powerplay] dpm has been enabled
[2.322244] [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector
ObjectID from Adapter Service for connector index:2! type 0 expected 3
[2.330448] [drm] Display Core initialized with v3.1.38!
[2.337391] [drm] SADs count is: -2, don't need to read it
[2.338216] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.338217] [drm] Driver supports precise vblank timestamp query.
[2.348435] input: SynPS/2 Synaptics TouchPad as
/devices/platform/i8042/serio1/input/input9
[2.350703] mousedev: PS/2 mouse device common for all mice
[2.361727] [drm] VCN decode and encode initialized successfully.
[2.371890] [drm] fb mappable at 0xD100
[2.371892] [drm] vram apper at 0xD000
[2.371893] [drm] size 8294400
[2.371893] [drm] fb depth is 24
[2.371894] [drm]pitch is 7680
[2.371970] fbcon: amdgpudrmfb (fb0) is primary device
[2.380213] Console: switching to colour frame buffer device 240x67
[2.400728] amdgpu :04:00.0: fb0: amdgpudrmfb frame buffer device
[2.408049] amdgpu :04:00.0: ring 0(gfx) uses VM inv eng 4 on hub 0
[2.408051] amdgpu :04:00.0: ring 1(comp_1.0.0) uses VM inv eng 5 on hub
0
[2.408053] amdgpu :04:00.0: ring 2(comp_1.1.0) uses VM inv eng 6 on hub
0
[2.408054] amdgpu :04:00.0: ring 3(comp_1.2.0) uses VM inv eng 7 on hub
0
[2.408055] amdgpu :04:00.0: ring 4(comp_1.3.0) uses VM inv eng 8 on hub
0
[2.408056] amdgpu :04:00.0: ring 5(comp_1.0.1) uses VM inv eng 9 on hub
0
[2.408058] amdgpu :04:00.0: ring 6(comp_1.1.1) uses VM inv eng 10 on
hub 0
[2.408059] amdgpu :04:00.0: ring 7(comp_1.2.1) uses VM inv eng 11 on
hub 0
[2.408060] amdgpu :04:00.0: ring 8(comp_1.3.1) uses VM inv eng 12 on
hub 0
[2.408062] amdgpu :04:00.0: ring 9(kiq_2.1.0) uses VM inv eng 13 on hub
0
[2.408063] amdgpu :04:00.0: ring 10(sdma0) uses VM inv eng 4 on hub 1
[2.408064] amdgpu :04:00.0: ring 11(vcn_dec) uses VM inv eng 5 on hub 1
[2.408066] amdgpu :04:00.0: ring 12(vcn_enc0) uses VM inv eng 6 on hub
1
[2.408067] amdgpu :04:00.0: ring 13(vcn_enc1) uses VM inv eng 7 on hub
1
[2.414993] [drm] Initialized amdgpu 3.25.0 20150101 for :04:00.0 on
minor 0
[2.431885] BUG: unable to handle kernel NULL pointer dereference at
023c
[2.431934] IP: dc_link_set_backlight_level+0x5e/0x160 [amdgpu]
[2.431948] PGD 0 P4D 0 
[2.431957] Oops:  [#1] PREEMPT SMP NOPTI
[2.431968] Modules linked in: joydev mousedev hid_sensor_accel_3d
hid_sensor_magn_3d hid_sensor_gyro_3d hid_sensor_rotation hid_sensor_incl_3d
hid_sensor_trigger industrialio_triggered_buffer kfifo_buf
hid_sensor_iio_common industrialio hid_sensor_hub hid_generic btusb btrtl btbcm
btintel bluetooth usbhid ecdh_generic msr cdc_ether usbnet r8152 mii uvcvideo
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media
amdkfd amd_iommu_v2 nls_iso8859_1 nls_cp437 vfat fat arc4 amdgpu r8822be(C)
snd_hda_codec_realtek chash snd_hda_codec_generic gpu_sched snd_hda_codec_hdmi
snd_hda_intel mac80211 hp_wmi ttm edac_mce_amd sparse_keymap wmi_bmof
snd_hda_codec ccp snd_hda_core drm_kms_helper snd_hwdep snd_pcm cfg80211 drm
syscopyarea rtsx_pci_ms kvm sysfillrect snd_timer sysimgblt fb_sys_fops
[2.432149]  i2c_algo_bit snd irqbypass rfkill memstick soundcore evdev
input_leds tpm_crb crct10dif_pclmul sp5100_tco ghash_clmulni_intel tpm_tis
psmouse mac_hid pcspkr i2c_piix4 tpm_tis_core shpchp tpm hp_accel i2c_hid
battery ac thermal wmi rng_core lis3lv02d i2c_scmi input_polldev video hid
pinctrl_amd hp_wireless led_class button acpi_cpufreq sch_fq_codel sg
crypto_user ip_tables x_tables ext4 crc16 mbcache jbd2 fscrypto rtsx_pci_sdmmc
mmc_core serio_raw atkbd libps2 crc32_pclmul crc32c_intel ahci aesni_intel
aes_x86_64 libahci crypto_simd cryptd glue_helper xhci_pci libata xhci_hcd
scsi_mod usbcore usb_common nvme rtsx_pci nvme_core i8042 serio
[2.432298] CPU: 2 PID: 664 Comm: systemd-backlig Tainted: G C  
4.16.0-rc1-165278df2b50 #12
[2.432319] Hardware name: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS
F.13 11/10/2017

Re: [PATCH v5 06/36] drm/rockchip: Only wait for panel ACK on PSR entry

[Heiko Stübner]

Am Freitag, 9. März 2018, 23:22:57 CET schrieb Enric Balletbo i Serra:
> From: zain wang 
> 
> We currently wait for the panel to mirror our intended PSR state
> before continuing on both PSR enter and PSR exit. This is really
> only important to do when we're entering PSR, since we want to
> be sure the last frame we pushed is being served from the panel's
> internal fb before shutting down the soc blocks (vop/analogix).
> 
> This patch changes the behavior such that we only wait for the
> panel to complete the PSR transition when we're entering PSR, and
> to skip verification when we're exiting.
> 
> Cc: Stéphane Marchesin 
> Cc: Sonny Rao 
> Signed-off-by: zain wang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 

applied to drm-misc-next with the subject fixed.


Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105369] HP HP ENVY x360, amdgpu, Call Trace tgn10_lock at startup, VMC page fault during runtime

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105369

cd  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #11 from cd  ---
Was solved by using
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

-- 
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/i915: drop various VLAs in i915_debugfs.c

[Joonas Lahtinen]

Quoting Salvatore Mesoraca (2018-03-13 21:51:28)
> Avoid 3 VLAs[1] by using real constant expressions instead of variables.
> The compiler should be able to optimize the original code and avoid using
> any actual VLAs. Anyway this change is useful because it will avoid a false
> positives with -Wvla, it might also help the compiler generating better
> code.
> 
> [1] https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Salvatore Mesoraca 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index e968aea..bf0a8e3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4259,19 +4259,20 @@ static ssize_t cur_wm_latency_write(struct file 
> *file, const char __user *ubuf,
> i915_cache_sharing_get, i915_cache_sharing_set,
> "%llu\n");
>  
> +#define CHERRYVIEW_SS_MAX 2

CHV_SS_MAX should be good enough. Make these function scoped (so #define
at the beginning and #undef at the end of function).

Do use ARRAY_SIZE() instead of repeating.

Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings

[Emil Velikov]

On 14 March 2018 at 09:12, Lin Huang  wrote:
> From: huang lin 
>
> The Innolux P097PFG panel is 9.7" panel with 1536X2048
> resolution, it reuse P079ZCA panel driver, so improve
> p079ZCA dt-binding to support P097PFG.
>
> Change-Id: I8704914898fe53b734d31fbe646df8aa5fd8b30d
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - None
> Changes in v3:
> - None
> Changes in v4:
> - None
>
>  .../devicetree/bindings/display/panel/innolux,p079zca.txt | 11 
> +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt 
> b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> index d0f5516..8cadd8c 100644
> --- a/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> +++ b/Documentation/devicetree/bindings/display/panel/innolux,p079zca.txt
> @@ -1,13 +1,18 @@
>  Innolux P079ZCA 7.85" 768x1024 TFT LCD panel
> +Innolux P097PFG 9.7" 1536x2048 TFT LCD panel
>
>  Required properties:
> -- compatible: should be "innolux,p079zca"
> +- compatible: should be should be one of the following.
> +-"innolux,p079zca" for Innolux 7.9" P079ZCA 768*1024 panel
> +-"innolux,p097pfg" for Innolux 9.7" P097PFG 1536*2048 panel
>  - reg: DSI virtual channel of the peripheral
> -- power-supply: phandle of the regulator that provides the supply voltage
>  - enable-gpios: panel enable gpio
>
>  Optional properties:
>  - backlight: phandle of the backlight device attached to the panel
> +- power-supply: phandle of the regulator that provides the supply voltage
> +- avdd-supply: phandle of the regulator that provides positive voltage
> +- avee-supply: phandle of the regulator that provides negative voltage
>
Guess that answers my required/optional question earlier.
Currently the code assumes that all of these are required. And will
crash badly if any are missing.

-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/3] drm/panel: support Innolux P097PFG panel

[Emil Velikov]

On 14 March 2018 at 09:12, Lin Huang  wrote:
> Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, it reuse
> the Innolux P079ZCA panel driver.
>
> Change-Id: I97923aa3735f707332681691b0231c9421b427d0
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - None
> Changes in v3:
> - None
> Changes in v4:
> - download panel initial code
>
>  drivers/gpu/drm/panel/panel-innolux-p079zca.c | 192 
> +-
>  1 file changed, 187 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
> b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> index 2075a9d..883b279 100644
> --- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> +++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
> @@ -20,6 +20,15 @@
>
>  #include 
>
> +struct panel_init_cmd {
> +   int len;
> +   const char *data;
> +};
> +
> +#define _INIT_CMD(...) { \
> +   .len = sizeof((char[]){__VA_ARGS__}), \
> +   .data = (char[]){__VA_ARGS__} }
> +
>  struct panel_desc {
> const struct drm_display_mode *modes;
> unsigned int bpc;
> @@ -30,6 +39,7 @@ struct panel_desc {
>
> unsigned long flags;
> enum mipi_dsi_pixel_format format;
> +   const struct panel_init_cmd *init_cmds;
> unsigned int lanes;
>  };
>
> @@ -88,9 +98,12 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
> return err;
> }
>
> +   /* p097pfg: t15 */
> +   msleep(100);
> +
Based on the comment this is not needed for p079zca, yet still executed.

> gpiod_set_value_cansleep(innolux->enable_gpio, 0);
>
> -   /* T8: 80ms - 1000ms */
> +   /* p079zca: t8*/
> msleep(80);
>
And this is seem the opposite - zca only, yet executed on pfg.

One way to to avoid these and use the appropriate sleep throughout is
to store have the numbers in the respective panel_desc entries.



> regulator_disable(innolux->avee);
> @@ -124,13 +137,43 @@ static int innolux_panel_prepare(struct drm_panel 
> *panel)
> if (err < 0)
> goto disable_avdd;
>
> -   /* T2: 15ms - 1000ms */
> -   usleep_range(15000, 16000);
> +   /* p079zca: t2 (20ms), p097pfg: t4 (15ms) */
> +   usleep_range(2, 21000);
>
> gpiod_set_value_cansleep(innolux->enable_gpio, 1);
>
> -   /* T4: 15ms - 1000ms */
> -   usleep_range(15000, 16000);
> +   /* p079zca: t4, p097pfg: t5 */
> +   usleep_range(2, 21000);
> +
> +   if (innolux->desc->init_cmds) {
> +   const struct panel_init_cmd *cmds =
> +   innolux->desc->init_cmds;
> +   int i;
> +
> +   for (i = 0; cmds[i].len != 0; i++) {
> +   const struct panel_init_cmd *cmd = [i];
> +
> +   err = mipi_dsi_generic_write(innolux->link, cmd->data,
> +cmd->len);
> +   if (err < 0) {
> +   dev_err(panel->dev,
> +   "failed to write command %d\n", i);
> +   goto poweroff;
> +   }
> +
> +   /*
> +* Included by random guessing, because without this
> +* (or at least, some delay), the panel sometimes
> +* didn't appear to pick up the command sequence.
> +*/
This seems a bit hackish. Adding a reference to a bugreport/mailing
list discussion would be a nice move.
It'll save you/next person a lot of time searching for the specifics
of the problem.

> +   err = mipi_dsi_dcs_nop(innolux->link);
> +   if (err < 0) {
> +   dev_err(panel->dev,
> +   "failed to send DCS nop: %d\n", err);
> +   goto poweroff;
> +   }
> +   }
> +   }
>
> err = mipi_dsi_dcs_exit_sleep_mode(innolux->link);
> if (err < 0) {
> @@ -213,6 +256,142 @@ static const struct panel_desc 
> innolux_p079zca_panel_desc = {
> .lanes = 4,
>  };
>
> +static const struct drm_display_mode innolux_p097pfg_mode = {
> +   .clock = 229000,
> +   .hdisplay = 1536,
> +   .hsync_start = 1536 + 100,
> +   .hsync_end = 1536 + 100 + 24,
> +   .htotal = 1536 + 100 + 24 + 100,
> +   .vdisplay = 2048,
> +   .vsync_start = 2048 + 100,
> +   .vsync_end = 2048 + 100 + 2,
> +   .vtotal = 2048 + 100 + 2 + 18,
> +   .vrefresh = 60,
> +};
> +
> +static const struct panel_init_cmd innolux_p097pfg_init_cmds[] = {

A lot of magic numbers :-(

Please reference the source of these - say XX spec. vY.
We could get a vY+1, which makes the nop workaround obsolete.

HTH
Emil
___
dri-devel mailing list

Re: [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

[Jani Nikula]

On Tue, 13 Mar 2018, Salvatore Mesoraca  wrote:
> Avoid 3 VLAs[1] by using real constant expressions instead of variables.
> The compiler should be able to optimize the original code and avoid using
> any actual VLAs. Anyway this change is useful because it will avoid a false
> positives with -Wvla, it might also help the compiler generating better
> code.

Thanks for your patch. However, Chris beat you to it with:

7aa0b14ede64 ("drm/i915: Remove variable length arrays from sseu debugfs
printers")

as well as adding -Wvla to our subdir-ccflags-y to prevent more from
cropping up:

c5c2b11894f4 ("drm/i915: Warn against variable length arrays")


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

[Emil Velikov]

Hi Lin,

On 14 March 2018 at 09:12, Lin Huang  wrote:
> From: huang lin 
>
> Refactor Innolux P079ZCA panel driver, let it support
> multi panel.
>
> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
> Signed-off-by: Lin Huang 
> ---
> Changes in v2:
> - Change regulator property name to meet the panel datasheet
> Changes in v3:
> - this patch only refactor P079ZCA panel to support multi panel, support 
> P097PFG panel in another patch
> Changes in v4:
> - Modify the patch which suggest by Thierry
>
Thanks for splitting this up. I think there's another piece that fell
through the cracks.
I'm not deeply familiar with the driver, so just sharing some quick notes.


>  struct innolux_panel {
> struct drm_panel base;
> struct mipi_dsi_device *link;
> +   const struct panel_desc *desc;
>
> struct backlight_device *backlight;
> -   struct regulator *supply;
> +   struct regulator *vddi;

> +   struct regulator *avdd;
> +   struct regulator *avee;
These two seem are new addition, as opposed to a dummy refactor.
Are they optional, does one need them for the existing panel (separate
patch?) or only for the new one (squash with the new panel code)?


> struct gpio_desc *enable_gpio;
>
> bool prepared;
> @@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
> /* T8: 80ms - 1000ms */
> msleep(80);
>
> -   err = regulator_disable(innolux->supply);
> -   if (err < 0)
> -   return err;
Good call on dropping the early return here.


> @@ -207,19 +248,28 @@ static const struct drm_panel_funcs innolux_panel_funcs 
> = {

>
> -   innolux->supply = devm_regulator_get(dev, "power");
> -   if (IS_ERR(innolux->supply))
> -   return PTR_ERR(innolux->supply);
> +   innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
> +   if (!innolux)
> +   return -ENOMEM;
> +
> +   innolux->desc = desc;
> +   innolux->vddi = devm_regulator_get(dev, "power");
> +   innolux->avdd = devm_regulator_get(dev, "avdd");
> +   innolux->avee = devm_regulator_get(dev, "avee");
>
AFAICT devm_regulator_get returns a pointer which is unsuitable to be
passed into regulator_{enable,disable}.
Hence, the IS_ERR check should stay. If any of the regulators are
optional, you want to call regulator_{enable,disable} only as
applicable.


> @@ -318,5 +377,6 @@ static struct mipi_dsi_driver innolux_panel_driver = {
>  module_mipi_dsi_driver(innolux_panel_driver);
>
>  MODULE_AUTHOR("Chris Zhong ");
> +MODULE_AUTHOR("Lin Huang ");
I don't think refactoring existing code classify as being the module author.
Then again, I could be wrong.

HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Patch 4/4] drm/omap: Add virtual plane support to omap_plane

[Tomi Valkeinen]

Hi Benoit,

On 02/03/18 15:48, Benoit Parrot wrote:
> Add virtual plane support by adding an array to contain
> all of the actual plane_id a "omap_plane" correspond to.

"plane_ids", "an", "corresponds"

> When at least one 'plane' child node is present in DT then
> omap_plane_init will only used the plane described in DT.

"use"

> Some of these nodes may be a virtual plane if they are defined
> as two physical planes.
> Planes can also be associated with various crtcs independently.
> Therefore we can restrict the use of virtual plane to specific
> CRTC/video port if need be, if crtc_mask is not specified then
> the plane will be available to all available crtcs.
> Physical plane which are not described will essentially be hidden

"planes"

> from the driver.
> 
> If no 'plane' child node exist then the existing plane

"nodes"

> allocation will take place.

Maybe "normal plane allocation"?

> 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  18 +++--
>  drivers/gpu/drm/omapdrm/omap_fb.c|  66 +++--
>  drivers/gpu/drm/omapdrm/omap_fb.h|   4 +-
>  drivers/gpu/drm/omapdrm/omap_plane.c | 139 
> +--
>  drivers/gpu/drm/omapdrm/omap_plane.h |   3 +-
>  5 files changed, 162 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
> b/drivers/gpu/drm/omapdrm/omap_drv.c
> index dd68b2556f5b..73796364a592 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -188,10 +188,9 @@ static int omap_connect_dssdevs(void)
>   return r;
>  }
>  
> -static int omap_modeset_init_properties(struct drm_device *dev)
> +static int omap_modeset_init_properties(struct drm_device *dev, u32 
> num_planes)
>  {
>   struct omap_drm_private *priv = dev->dev_private;
> - unsigned int num_planes = priv->dispc_ops->get_num_ovls();
>  
>   priv->zorder_prop = drm_property_create_range(dev, 0, "zorder", 0,
> num_planes - 1);
> @@ -210,10 +209,19 @@ static int omap_modeset_init(struct drm_device *dev)
>   int num_crtcs, crtc_idx, plane_idx;
>   int ret;
>   u32 plane_crtc_mask;
> + struct dispc_plane_mappings plane_mappings = {0};
>  
>   drm_mode_config_init(dev);
>  
> - ret = omap_modeset_init_properties(dev);
> + ret = priv->dispc_ops->get_plane_mapping(_mappings);
> + if (ret < 0)
> + return ret;
> +
> + /* use plane mappings info */
> + if (plane_mappings.num_planes)
> + num_ovls = plane_mappings.num_planes;
> +
> + ret = omap_modeset_init_properties(dev, num_ovls);
>   if (ret < 0)
>   return ret;
>  
> @@ -266,7 +274,7 @@ static int omap_modeset_init(struct drm_device *dev)
>   return -ENOMEM;
>  
>   plane = omap_plane_init(dev, plane_idx, DRM_PLANE_TYPE_PRIMARY,
> - plane_crtc_mask);
> + plane_crtc_mask, _mappings);
>   if (IS_ERR(plane))
>   return PTR_ERR(plane);
>  
> @@ -296,7 +304,7 @@ static int omap_modeset_init(struct drm_device *dev)
>   return -EINVAL;
>  
>   plane = omap_plane_init(dev, plane_idx, DRM_PLANE_TYPE_OVERLAY,
> - plane_crtc_mask);
> + plane_crtc_mask, _mappings);
>   if (IS_ERR(plane))
>   return PTR_ERR(plane);
>  
> diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
> b/drivers/gpu/drm/omapdrm/omap_fb.c
> index b2539a90e1a4..80b29b7f5696 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fb.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fb.c
> @@ -153,25 +153,27 @@ static uint32_t drm_rotation_to_tiler(unsigned int 
> drm_rot)
>  /* update ovl info for scanout, handles cases of multi-planar fb's, etc.
>   */
>  void omap_framebuffer_update_scanout(struct drm_framebuffer *fb,
> - struct drm_plane_state *state, struct omap_overlay_info *info)
> + struct drm_plane_state *state,
> + struct omap_overlay_info *main_info,
> + struct omap_overlay_info *aux_info)
>  {
>   struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
>   const struct drm_format_info *format = omap_fb->format;
>   struct plane *plane = _fb->planes[0];
>   uint32_t x, y, orient = 0;
>  
> - info->fourcc = fb->format->format;
> + main_info->fourcc = fb->format->format;
>  
> - info->pos_x  = state->crtc_x;
> - info->pos_y  = state->crtc_y;
> - info->out_width  = state->crtc_w;
> - info->out_height = state->crtc_h;
> - info->width  = state->src_w >> 16;
> - info->height = state->src_h >> 16;
> + main_info->pos_x  = state->crtc_x;
> + main_info->pos_y  = state->crtc_y;
> + main_info->out_width  = state->crtc_w;
> + main_info->out_height = state->crtc_h;
> 

Re: [PATCH][next] drm/amd/pp: remove redundant pointer internal_buf

[Zhu, Rex]

Apply it and thanks.


Best Regards

Rex





From: Colin King 
Sent: Tuesday, March 13, 2018 9:22 PM
To: Deucher, Alexander; Koenig, Christian; Zhou, David(ChunMing); David Airlie; 
Zhu, Rex; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
Cc: kernel-janit...@vger.kernel.org; linux-ker...@vger.kernel.org
Subject: [PATCH][next] drm/amd/pp: remove redundant pointer internal_buf

From: Colin Ian King 

The pointer internal_buf is assigned a value but the pointer is never
read, hence it is redundant and can be removed.

Cleans up clang warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.c:630:2:
warning: Value stored to 'internal_buf' is never read

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
index 7394bb46b8b2..dcb151cabc00 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c
@@ -585,7 +585,6 @@ int smu7_setup_pwr_virus(struct pp_hwmgr *hwmgr)
 int smu7_init(struct pp_hwmgr *hwmgr)
 {
 struct smu7_smumgr *smu_data;
-   uint8_t *internal_buf;
 uint64_t mc_addr = 0;
 int r;
 /* Allocate memory for backend private data */
@@ -627,7 +626,6 @@ int smu7_init(struct pp_hwmgr *hwmgr)
 _data->header_buffer.kaddr);
 return -EINVAL;
 }
-   internal_buf = smu_data->smu_buffer.kaddr;
 smu_data->smu_buffer.mc_addr = mc_addr;

 if (smum_is_hw_avfs_present(hwmgr))
--
2.15.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Tomi Valkeinen]

On 09/03/18 20:27, Benoit Parrot wrote:

>> Is logical plane a h/w concept?
> 
> It does represent a hardware resource.

Logical plane is not a hw concept, it just describes a group of one or
two HW planes. Then again, in the context of 2k+ displays, two HW planes
must always be used together, so that way it could be considered a
single HW resource.

>> Really, I'm skeptical that any of this belongs in DT. For example,
>> can't you figure out you need 2 physical planes whenever your
>> panel/timing width is greater than 2048?
> 
> As stated in the description I added above, we cannot have resources
> exposed to user-space which can "disappear" dynamically.
> Doing so would break user-space applications which rely on these
> resources.

The question is, if not in DT, then where? I agree that this is not
exactly describing the HW. But it can't be done dynamically either (or
at least we have not figured out a way). And it must be user configurable.

Module parameters are an option, but it would be somewhat difficult to
give all this information there. And also, if your board has a 2k+
display, you must have these configurations given to the driver, it's
not optional.

And while it's perhaps stretching the definitions a bit, I guess one
could argue that this describes the HW in a way: it describes how the HW
resources must be used if you have a display of 2k+ width, and is not as
such related to Linux or DRM.

 Tomi

-- 
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 3/4] drm/omap: Add virtual plane DT parsing support

[Tomi Valkeinen]

Hi Benoit,

On 02/03/18 15:48, Benoit Parrot wrote:
> Virtual planes are used to extend display size capability for display
> larger than 2048 pixels by splitting the frame buffer equally between
> two physical planes.
> 
> Here we are adding DT support to parse 'plane' child nodes which
> describe how logical planes are mapped to physical plane(s) and
> which crtc they are available on.
> 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/gpu/drm/omapdrm/dss/dispc.c   | 110 
> ++
>  drivers/gpu/drm/omapdrm/dss/omapdss.h |  11 
>  2 files changed, 121 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
> b/drivers/gpu/drm/omapdrm/dss/dispc.c
> index 624dee22f46b..559b70d9762d 100644
> --- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> @@ -4334,6 +4334,115 @@ static u32 dispc_get_memory_bandwidth_limit(void)
>   return limit;
>  }
>  
> +static struct device_node *dispc_of_get_plane_by_id(struct device_node *node,
> + u32 id)
> +{
> + struct device_node *plane;
> +
> + for_each_child_of_node(node, plane) {
> + u32 plane_id = 0;
> +
> + if (of_node_cmp(plane->name, "plane") != 0)
> + continue;
> + of_property_read_u32(plane, "reg", _id);
> + if (id == plane_id)
> + break;

I think the flow is more readable, if here you "return plane", and at
the end of the func "return NULL".

> + }
> +
> + return plane;
> +}
> +
> +static int dispc_parse_dt_plane_data(struct dispc_plane_mappings *plane)

You could rename the parameter to "map", for example. Using 'plane'
there is quite confusing.

> +{
> + struct platform_device *pdev = dispc.pdev;
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *ep;
> + struct property *prop;
> + const __be32 *cur;
> + u32 v;
> + u32 num_ovls = dispc_get_num_ovls();
> + unsigned long int hw_plane_mask = (1 << num_ovls) - 1;

u32?

> + u32 num_planes;
> + int i, index;
> +
> + if (!np)
> + return 0;
> +
> + for (i = 0; i < num_ovls; i++) {
> + ep = dispc_of_get_plane_by_id(np, i);
> + if (!ep)
> + break;
> + if (!of_property_read_bool(ep, "hw-planes")) {
> + dev_err(>dev,
> + "malformed plane node: hw-planes missing.\n");
> + return -EINVAL;
> + }
> +
> + index = 0;
> + of_property_for_each_u32(ep, "hw-planes", prop, cur, v) {
> + if (v >= num_ovls) {
> + dev_err(>dev,
> + "hw-planes property: '%d' 
> out-of-range.\n",
> + v);
> + return -EINVAL;
> + }
> + if (!(hw_plane_mask & BIT_MASK(v))) {
> + dev_err(>dev,
> + "hw-planes property: '%d' used more 
> than once.\n",
> + v);
> + return -EINVAL;
> + }
> + clear_bit(v, _plane_mask);

Why do you use hw_plane_mask this way? It feels inverse to me, usually
one sets a bit when something is there. And e.g. crtc_mask here is used
the other way.

> +
> + if (index == 0) {
> + plane->plane[i].main_id = v;
> + } else if (index == 1) {
> + plane->plane[i].aux_id = v;
> + plane->plane[i].is_virtual = true;
> + } else if (index > 1) {
> + dev_err(>dev,
> + "hw-planes property: more than 2 values 
> specified.\n");
> + return -EINVAL;
> + }
> + index++;
> + }
> +
> + of_property_for_each_u32(ep, "hw-crtcs", prop, cur, v) {
> + if (v >= num_ovls) {

This should check against num_ovl_mgrs.

> + dev_err(>dev,
> + "hw-crtcs property: '%d' 
> out-of-range.\n",
> + v);
> + return -EINVAL;
> + }
> + plane->plane[i].crtc_mask |= 1 << v;
> + }
> + }
> +
> + num_planes = i;
> +
> + if (num_planes) {
> + dev_dbg(>dev, "Plane definitions found from DT:");
> + for (i = 0; i < num_planes; i++) {
> + if (plane->plane[i].is_virtual) {
> + dev_dbg(>dev,
> + "plane%d: virtual hw-planes: %d, %d 
> crtc_mask: 0x%04x",
> + 

Re: [PATCH] drm/vc4: Add support for SAND modifier.

[Daniel Stone]

Hey Eric,

On 3 March 2018 at 01:34, Eric Anholt  wrote:
> Ccing a couple of folks who are likely to have opinions about
> drm_fourcc.h additions (Do we have enough docs?  Are the macros OK?),
> and Bootlin who are likely reviewers.
>
> The plan is to use these modifiers in VC4 GL imports as well, and for
> buffers coming from the v4l2 mmal camera driver.  You can find a demo
> using this in KMS planes at
> https://github.com/anholt/drm_mmal/commit/sand for now.

I had a dig through and this seems like the most sensible thing to do
if you have a reasonable variety of tile heights. If you only see a
couple of combinations in the wild, then hardcoding them as separate
modifiers might make things easier than hiving off 24 bits. If you do
keep the split though, and especially if you're envisioning future
flexible tile formats, maybe something like an 8 code / 48 params
split would make more sense.

Either way, those are just my opinions (you did ask), and I don't see
anything really objectionable, so if you think that's a good split
then this is:
Acked-by: Daniel Stone 

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

[Thierry Reding]

On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA. In this particular
> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local
> variable cmdline_size. Also, remove cmdline_size as it is not
> actually useful anymore.
> 
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack exhaustion, which can be both a runtime bug
> or a security flaw. Also, in general, as code evolves it is easy to
> lose track of how big a VLA can get. Thus, we can end up having runtime
> failures that are hard to debug.
> 
> Also, fixed as part of the directive to remove all VLAs from
> the kernel: https://lkml.org/lkml/2018/3/7/621
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  - Use sizeof(buf) instead of NVKM_MSGQUEUE_CMDLINE_SIZE. This change
>is based on the feedback provided by David Laight. Thanks David.
> 
>  drivers/gpu/drm/nouveau/nvkm/subdev/secboot/ls_ucode_msgqueue.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

Reviewed-by: Thierry Reding 


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915/pmu: Work around compiler warnings on some kernel configs

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-03-14 08:05:35)
> From: Tvrtko Ursulin 
> 
> Arnd Bergman reports:
> """
> The conditional spinlock confuses gcc into thinking the 'flags' value
> might contain uninitialized data:
> 
> drivers/gpu/drm/i915/i915_pmu.c: In function '__i915_pmu_event_read':
> arch/x86/include/asm/paravirt_types.h:573:3: error: 'flags' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
> 
> The code is correct, but it's easy to see how the compiler gets confused
> here. This avoids the problem by pulling the lock outside of the function
> into its only caller.
> """
> 
> On deeper look it seems this is caused by paravirt spinlocks
> implementation when CONFIG_PARAVIRT_DEBUG is set, which by being
> complicated, manages to convince gcc locked parameter can be changed
> externally (impossible).
> 
> Work around it by removing the conditional locking parameters altogether.
> (It was never the most elegant code anyway.)
> 
> Slight penalty we now pay is an additional irqsave spin lock/unlock cycle
> on the event enable path. But since enable is not a fast path, that is
> preferrable to the alternative solution which was doing MMIO under irqsave
> spinlock.
> 
> Signed-off-by: Tvrtko Ursulin 
> Reported-by: Arnd Bergmann 
> Fixes: 1fe699e30113 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
> Cc: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: Imre Deak 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> Cc: David Airlie 
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 32 +---
>  1 file changed, 13 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 4bc7aefa9541..11fb76bd3860 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -412,7 +412,7 @@ static u64 __get_rc6(struct drm_i915_private *i915)
> return val;
>  }
>  
> -static u64 get_rc6(struct drm_i915_private *i915, bool locked)
> +static u64 get_rc6(struct drm_i915_private *i915)
>  {
>  #if IS_ENABLED(CONFIG_PM)
> unsigned long flags;
> @@ -428,8 +428,7 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
> locked)
>  * previously.
>  */
>  
> -   if (!locked)
> -   spin_lock_irqsave(>pmu.lock, flags);
> +   spin_lock_irqsave(>pmu.lock, flags);
>  
> if (val >= i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur) 
> {
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = 0;
> @@ -438,12 +437,10 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
> locked)
> val = 
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur;
> }
>  
> -   if (!locked)
> -   spin_unlock_irqrestore(>pmu.lock, flags);
> +   spin_unlock_irqrestore(>pmu.lock, flags);
> } else {
> struct pci_dev *pdev = i915->drm.pdev;
> struct device *kdev = >dev;
> -   unsigned long flags2;
>  
> /*
>  * We are runtime suspended.
> @@ -452,10 +449,8 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
> locked)
>  * on top of the last known real value, as the approximated 
> RC6
>  * counter value.
>  */
> -   if (!locked)
> -   spin_lock_irqsave(>pmu.lock, flags);
> -
> -   spin_lock_irqsave(>power.lock, flags2);
> +   spin_lock_irqsave(>pmu.lock, flags);
> +   spin_lock(>power.lock);
>  
> if (!i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur)
> i915->pmu.suspended_jiffies_last =
> @@ -465,14 +460,13 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
> locked)
>   i915->pmu.suspended_jiffies_last;
> val += jiffies - kdev->power.accounting_timestamp;
>  
> -   spin_unlock_irqrestore(>power.lock, flags2);
> +   spin_unlock(>power.lock);
>  
> val = jiffies_to_nsecs(val);
> val += i915->pmu.sample[__I915_SAMPLE_RC6].cur;
> i915->pmu.sample[__I915_SAMPLE_RC6_ESTIMATED].cur = val;
>  
> -   if (!locked)
> -   spin_unlock_irqrestore(>pmu.lock, flags);
> +   spin_unlock_irqrestore(>pmu.lock, flags);
> }
>  
> return val;
> @@ -481,7 +475,7 @@ static u64 get_rc6(struct drm_i915_private *i915, bool 
> locked)
>  #endif
>  }
>  
> -static u64 __i915_pmu_event_read(struct 

Re: [PATCH] drm/panel: rm68200: add backlight dependency

[Thierry Reding]

On Wed, Mar 14, 2018 at 09:49:54AM +0100, Arnd Bergmann wrote:
> On Wed, Mar 14, 2018 at 12:01 AM, Thierry Reding
>  wrote:
> > On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote:
> >> Like many other panel drivers, this one fails to build
> >> when backlight support is disabled:
> >>
> >> drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
> >> panel-raydium-rm68200.c:(.text+0x14a): undefined reference to 
> >> `devm_of_find_backlight'
> >>
> >> This adds the appropriate dependency.
> >>
> >> Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel 
> >> driver")
> >> Signed-off-by: Arnd Bergmann 
> >> ---
> >>  drivers/gpu/drm/panel/Kconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >
> > This shouldn't be necessary. include/linux/backlight.h defines a stub if
> > the backlight class is not enabled.
> >
> > What tree are you seeing this on?
> 
> This is on linux-next.
> 
> It must be with BACKLIGHT_CLASS_DEVICE=m and
> DRM_PANEL_RAYDIUM_RM68200=y, meaning that it should
> be sufficient to do
> 
> depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n
> 
> to force DRM_PANEL_RAYDIUM_RM68200 to be a loadable module
> whenever BACKLIGHT_CLASS_DEVICE=m. For the patch, I looked at
> what the other drivers in the same directory do and followed their
> example.
> 
> I see three options here:
> 
> 1. update my patch changelog with the explanation I wrote here but leave it
> untouched
> 2. use the more elaborate dependency (after testing) but not change the
> others
> 3. change all panel drivers with a backlight dependency the same way,
> possibly with a helper symbol like
> 
> config BACKLIGHT_CLASS_DEVICE_OPTIONAL
>  tristate
>  default m if BACKLIGHT_CLASS_DEVICE=m
>  default y
> 
>   Arnd

I went with option 1) and added some text that hopefully clarifies the
issue.


https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a8efe516316472ac771ba3f591295c7515e46172

Thierry


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105500

--- Comment #3 from Balázs Vinarz  ---
Created attachment 138097
  --> https://bugs.freedesktop.org/attachment.cgi?id=138097=edit
Xorg.0.log

-- 
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 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105500

--- Comment #4 from Balázs Vinarz  ---
Created attachment 138098
  --> https://bugs.freedesktop.org/attachment.cgi?id=138098=edit
xrandr

-- 
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 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105500

--- Comment #2 from Balázs Vinarz  ---
Created attachment 138096
  --> https://bugs.freedesktop.org/attachment.cgi?id=138096=edit
glxinfo

-- 
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 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105500

--- Comment #1 from Balázs Vinarz  ---
Created attachment 138095
  --> https://bugs.freedesktop.org/attachment.cgi?id=138095=edit
dmidecode

-- 
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 105500] AMD Richland (ARUBA) no screen at DP output when using three displays

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105500

Bug ID: 105500
   Summary: AMD Richland (ARUBA) no screen at DP output when using
three displays
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: viniba...@gmail.com

Created attachment 138094
  --> https://bugs.freedesktop.org/attachment.cgi?id=138094=edit
dmesg

Hello there!

After connecting and enabling the 3rd monitor in D-Sub, the one with DP becames
black. Most of the time I use 2 displays with (DVI-I and DP) without any
problem. The desired layout is the following, however I even tried to use HDMI
instead of DVI-I:
 ___  __  __
|DVI||DP||DS|
  21  3

 __  __  
|DS||DP||HDMI|
  2   1   3

None of the options are working, however it's fine on Windows using the lastest
- official beta - Crimson Edition 15.7.1.
The motherboard had an ASMedia ASM1445 DVI/HDMI bridge, so I couldn't use these
outputs at the same time.

CPU: AMD A8-6500
GPU: AMD Radeon HD8570 (ATOMBIOSBK-AMD VER015.031.000.000.00,
02/17/13,02:36:07)
MOBO: ASUS F2A85M-PRO (BIOS 6601)
OS: Arch Linux 4.13 AMD64
xf86-video-ati 1:18.0.0-1
xorg-server 1.19.6+13+gd0d1a694f-1

The logs/outputs were saved at 4.13, however it's not working with both the
up-to-date Arch (4.15) and Xubuntu 18.04 beta.

Thank you

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 05/36] drm/bridge: analogix_dp: add fast link train for eDP

[Heiko Stübner]

Am Freitag, 9. März 2018, 23:22:56 CET schrieb Enric Balletbo i Serra:
> From: zain wang 
> 
> We would meet a short black screen when exit PSR with the full link
> training, In this case, we should use fast link train instead of full
> link training.
> 
> Signed-off-by: zain wang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 

applied to drm-misc-next

Checking the whole series, there is nothing else that touches the
reordered headers, so I've dropped that change, leaving only the
newly added iopoll.h inclusion in [0].

Thanks
Heiko


[0] 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f9d5680596f2dac390918e6aec3e174db03633a3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 03/36] drm/bridge: analogix_dp: Don't change psr while bridge is disabled

[Heiko Stübner]

Am Freitag, 9. März 2018, 23:22:54 CET schrieb Enric Balletbo i Serra:
> From: zain wang 
> 
> There is a race between AUX CH bring-up and enabling bridge which will
> cause link training to fail. To avoid hitting it, don't change psr state
> while enabling the bridge.
> 
> Cc: Tomeu Vizoso 
> Cc: Sean Paul 
> Signed-off-by: zain wang 
> Signed-off-by: Caesar Wang 
> [seanpaul fixed up the commit message a bit and renamed *_supported to
> *_enabled] Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 


applied to drm-misc-next

Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 04/36] drm/rockchip: add mutex vop lock

[Heiko Stübner]

Am Freitag, 9. März 2018, 23:22:55 CET schrieb Enric Balletbo i Serra:
> From: zain wang 
> 
> Add a lock to vop to avoid disabling the crtc while waiting for a line
> flag while enabling psr. If we disable in the middle of waiting for the
> line flag, we'll end up timing out or worse.
> 
> Signed-off-by: zain wang 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 

applied to drm-misc-next

Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 02/36] drm/rockchip: Remove analogix psr worker

[Heiko Stübner]

Am Freitag, 9. März 2018, 23:22:53 CET schrieb Enric Balletbo i Serra:
> From: Sean Paul 
> 
> Now that the spinlocks and timers are gone, we can remove the psr
> worker located in rockchip's analogix driver and do the enable/disable
> directly. This should simplify the code and remove races on disable.
> 
> Cc: 征增 王 
> Cc: Stéphane Marchesin 
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 


applied to drm-misc-next

Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 01/36] drm/bridge: analogix_dp: detect Sink PSR state after configuring the PSR

[Heiko Stübner]

Am Freitag, 9. März 2018, 23:22:52 CET schrieb Enric Balletbo i Serra:
> From: Yakir Yang 
> 
> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
> function, or print the sink PSR error state if we failed to apply the
> requested PSR setting.
> 
> Cc: 征增 王 
> Cc: Stéphane Marchesin 
> Signed-off-by: Yakir Yang 
> [seanpaul changed timeout loop to a readx poll]
> Signed-off-by: Sean Paul 
> Signed-off-by: Thierry Escande 
> Signed-off-by: Enric Balletbo i Serra 
> Tested-by: Marek Szyprowski 

applied to drm-misc-next

Thanks
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ARM: dts: sun8i-h3: Add Mali node

[Giulio Benetti]

Hi,

Il 14/03/2018 09:05, Maxime Ripard ha scritto:

On Tue, Mar 13, 2018 at 11:16:45AM +0100, Giulio Benetti wrote:

The H3 has an ARM Mali 400 GPU, so add binding to our DT.

Signed-off-by: Giulio Benetti 


How was this tested?


I wanted you asked me about this to ask you:
if I can't test it on HW, but others tested it all around,
for example using this patch:
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/32-h3-DT-add-mali-node.patch

Is it enough? Or do I have to test it directly?
Or maybe I can invite those people to tag this patch as tested-by ?



Is there any specific reason not to share it with the H5?


Yes, H5 has dual GPU but quad PP and on IRQ you can clearly see:
- GPU_GP
- GPU_GPMMU
- GPU_PMU
- GPU_PP
- GPU_PP0
- GPU_PPMMU0
- GPU_PP1
- GPU_PPMMU1
- GPU_PP2
- GPU_PPMMU2
- GPU_PP3
- GPU_PPMMU3

So I think they should be placed in specific dts files.
What do you think?

Thanks



Maxime




--
Giulio Benetti
CTO

MICRONOVA SRL
Sede: Via A. Niedda 3 - 35010 Vigonza (PD)
Tel. 049/8931563 - Fax 049/8931346
Cod.Fiscale - P.IVA 02663420285
Capitale Sociale € 26.000 i.v.
Iscritta al Reg. Imprese di Padova N. 02663420285
Numero R.E.A. 258642
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[jacopo mondi]

Hi Andrzej,
thanks for review

On Wed, Mar 14, 2018 at 09:42:36AM +0100, Andrzej Hajda wrote:
> On 13.03.2018 15:30, Jacopo Mondi wrote:
> > Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> > output decoder.
>
> IMO converter suits here better, but it is just suggestion.
>
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  drivers/gpu/drm/bridge/Kconfig|   7 +
> >  drivers/gpu/drm/bridge/Makefile   |   1 +
> >  drivers/gpu/drm/bridge/thc63lvd1024.c | 241 
> > ++
> >  3 files changed, 249 insertions(+)
> >  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
> >
> > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> > index 3b99d5a..facf6bd 100644
> > --- a/drivers/gpu/drm/bridge/Kconfig
> > +++ b/drivers/gpu/drm/bridge/Kconfig
> > @@ -92,6 +92,13 @@ config DRM_SII9234
> >   It is an I2C driver, that detects connection of MHL bridge
> >   and starts encapsulation of HDMI signal.
> >
> > +config DRM_THINE_THC63LVD1024
> > +   tristate "Thine THC63LVD1024 LVDS decoder bridge"
> > +   depends on OF
> > +   select DRM_PANEL_BRIDGE
>
> You don't use PANEL_BRIDGE, it should be possible to drop the select.
>

Ack

> > +   ---help---
> > + Thine THC63LVD1024 LVDS decoder bridge driver.
>
> Decoder to what?
> Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
> converter or bridge.

"LVDS to digital CMOS/TTL parallel data converter" as the manual
describes the chip?

>
> > +
> >  config DRM_TOSHIBA_TC358767
> > tristate "Toshiba TC358767 eDP bridge"
> > depends on OF
> > diff --git a/drivers/gpu/drm/bridge/Makefile 
> > b/drivers/gpu/drm/bridge/Makefile
> > index 373eb28..fd90b16 100644
> > --- a/drivers/gpu/drm/bridge/Makefile
> > +++ b/drivers/gpu/drm/bridge/Makefile
> > @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
> >  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> >  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> > +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
> >  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> >  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> > diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> > b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > new file mode 100644
> > index 000..4b059c0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> > @@ -0,0 +1,241 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> > + *
> > + * Copyright (C) 2018 Jacopo Mondi 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +static const char * const thc63_reg_names[] = {
> > +   "vcc", "lvcc", "pvcc", "cvcc", };
> > +
> > +struct thc63_dev {
> > +   struct device *dev;
> > +
> > +   struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> > +
> > +   struct gpio_desc *pwdn;
> > +   struct gpio_desc *oe;
> > +
> > +   struct drm_bridge bridge;
> > +   struct drm_bridge *next;
> > +};
> > +
> > +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> > +{
> > +   return container_of(bridge, struct thc63_dev, bridge);
> > +}
> > +
> > +static int thc63_attach(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +
> > +   return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> > +}
> > +
> > +static void thc63_enable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   unsigned int i;
> > +   int ret;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > +   vcc = thc63->vccs[i];
> > +   if (vcc) {
> > +   ret = regulator_enable(vcc);
> > +   if (ret)
> > +   goto error_vcc_enable;
> > +   }
> > +   }
> > +
> > +   if (thc63->pwdn)
> > +   gpiod_set_value(thc63->pwdn, 0);
> > +
> > +   if (thc63->oe)
> > +   gpiod_set_value(thc63->oe, 1);
> > +
> > +   return;
> > +
> > +error_vcc_enable:
> > +   dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> > +}
> > +
> > +static void thc63_disable(struct drm_bridge *bridge)
> > +{
> > +   struct thc63_dev *thc63 = to_thc63(bridge);
> > +   struct regulator *vcc;
> > +   unsigned int i;
> > +   int ret;
> > +
> > +   for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> > +   vcc = thc63->vccs[i];
> > +   if (vcc) {
> > +   ret = regulator_disable(vcc);
> > +   if (ret)
> > +   goto error_vcc_disable;
>
> I think in disable path you can report an error and continue - should be
> safer.
>

Ack

> > +   }
> > +   }
> > +
> > +   if (thc63->pwdn)
> > +   gpiod_set_value(thc63->pwdn, 1);
> > +
> > +   

Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector

[Alexandru-Cosmin Gheorghe]

Hi Stefan,

On Tue, Mar 13, 2018 at 07:20:33PM +0100, Stefan Schake wrote:
> Hey Alexandru,
> 
> On Tue, Mar 13, 2018 at 5:21 PM, Alexandru Gheorghe
>  wrote:
> > This patchset tries to add support for using writeback connector to
> > flatten a scene when it doesn't change for a while. This idea had
> > been floated around on IRC here [1] and here [2].
> >
> > 2. Heuristic for triggering the flattening.
> > I just created a VSyncWorker which will trigger the flattening of the
> > scene if it doesn't change for 60 consecutive vsyncs. The countdown
> > gets reset every time ValidateDisplay is called. This is a relatively
> > basic heuristic, so I'm open to suggestions.
> 
> I think when Android deems that the display is sufficiently idle, it will
> disable VSync through setVsyncEnabled. Presumably we could just trigger the
> flattening on an enabled -> disabled transition?
> 
> Thanks,
> Stefan

I will look into it thanks.

-- 
Cheers,
Alex G
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE

[Maxime Ripard]

On Tue, Mar 13, 2018 at 06:54:37PM +0100, Giulio Benetti wrote:
> Handle both positive and negative dclk polarity,
> according to bus_flags, taking care of this:
> 
> On A20 and similar SoCs, the only way to achieve Positive Edge
> (Rising Edge), is setting dclk clock phase to 2/3(240°).
> By default TCON works in Negative Edge(Falling Edge), this is why phase
> is set to 0 in that case.
> Unfortunately there's no way to logically invert dclk through IO_POL
> register.
> The only acceptable way to work, triple checked with scope,
> is using clock phase set to 0° for Negative Edge and set to 240° for
> Positive Edge.
> On A33 and similar SoCs there would be a 90° phase option, but it divides
> also dclk by 2.
> This patch is a way to avoid quirks all around TCON and DOTCLOCK drivers
> for using A33 90° phase divided by 2 and consequently increase code
> complexity.
> 
> Signed-off-by: Giulio Benetti 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
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

Re: [PATCH v2] drm/sun4i: move rgb mode_valid from connector to encoder

[Maxime Ripard]

On Tue, Mar 13, 2018 at 12:36:57PM +0100, Giulio Benetti wrote:
> mode_valid function must be connected to encoder.
> Otherwise it could get not be called by drm in the case there's a
> bridge connected to encoder instead of a panel.
> 
> Move mode_valid function pointer to encoder helper functions,
> changing its prototype according to encoder helper function pointer.
> 
> Signed-off-by: Giulio Benetti 

Applied, thanks!
Maxime


-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
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

Re: [PATCH v2] drm/sun4i: add lvds mode_valid function

[Maxime Ripard]

On Tue, Mar 13, 2018 at 12:20:19PM +0100, Giulio Benetti wrote:
> mode_valid function is missing for lvds.
> 
> Add it making it pointed by encoder helper functions.
> 
> Signed-off-by: Giulio Benetti 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198123

--- Comment #36 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to shibe from comment #35)
> Has the cause of this issue been identified/confirmed?

Not yet, unfortunately.

> On boot I have grey console background instead of black.

Can you try the latest test patch attached here, and attach the dmesg output
from running with it?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[jacopo mondi]

Hi Andrzej,
sorry for the mess :(

On Wed, Mar 14, 2018 at 09:15:42AM +0100, Andrzej Hajda wrote:
> On 13.03.2018 15:30, Jacopo Mondi wrote:
> > Document Thine THC63LVD1024 LVDS decoder device tree bindings.
> >
> > Signed-off-by: Jacopo Mondi 
> > ---
> >  .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 
> > ++
> >  1 file changed, 63 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > new file mode 100644
> > index 000..5b5afcd
> > --- /dev/null
> > +++ 
> > b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> > @@ -0,0 +1,63 @@
> > +Thine Electronics THC63LVD1024 LVDS decoder
> > +---
> > +
> > +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
> > streams
> > +to parallel data outputs. The chip supports single/dual input/output modes,
> > +handling up to two two input LVDS stream and up to two digital CMOS/TTL 
> > outputs.
> > +
> > +Required properties:
> > +- compatible: Shall be "thine,thc63lvd1024",
> > +
> > +Optional properties:
> > +- vcc-supply: Power supply for TTL output and digital circuitry
> > +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> > +- lvcc-supply: Power supply for LVDS inputs
> > +- pvcc-supply: Power supply for PLL circuitry
>
> I wonder if it wouldn't be better to make them required (at least VCC) -
> it is closer to reality.

In cases like our Eagle board, where VCC is directly connected to the
powering rail and not through a controllable regulator, I feel like
making this mandatory requires more effort (not much, I agree, just a
"fixed-regulator" more) with no additional benefits.

But I understand your point, and I'm open to whatever fits better with
the already existing DRM bridges bindings

>
> > +- pwnd-gpios: Power down GPIO signal. Active low.
>
> As I said before, specs[1] says about "/PDWN" pin. Is it your typo, or
> different docs?

I didn't notice the typo in first review, and I thought you were referring to
the initial '/' which I found weird to be part of the gpio name... Then I now
realized I badly typed in "pwnd" in place of "pwdn", which is not even correct
because it has to be "pdwn"... Sorry about this mess, I will fix in v4

> Moreover there are already bindings for THC63LVDM83D with the same
> dichotomy [2].

Seems like this is 'wrong' as well.. The chip manual says the pin is
named "pdwn" here too..

>
> Out of curiosity I have googled for "pwnd pin" and it looks like some
> vendors use this form.
> For me both forms are quite misleading: power down signal, active low,
> why they couldn't call it just 'enable, active high'.
>

It's not much the actual physical active level that bugs me, but the fact
that the GPIO name defines if it has to be set to "active" or
"inactive" logical state in enable/disable routines that I don't
like..

> [1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
> [2]:
> https://elixir.bootlin.com/linux/v4.16-rc5/source/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt
>
> > +- oe-gpios: Output enable GPIO signal. Active high.
> > +
> > +The THC63LVD1024 video port connections are modeled according
> > +to OF graph bindings specified by 
> > Documentation/devicetree/bindings/graph.txt
> > +
> > +Required video port nodes:
> > +- Port@0: First LVDS input port
> > +- Port@2: First digital CMOS/TTL parallel output
> > +
> > +Optional video port nodes:
> > +- Port@1: Second LVDS input port
> > +- Port@3: Second digital CMOS/TTL parallel output
> > +
> > +Example:
> > +
> > +
> > +   thc63lvd1024: lvds-decoder {
> > +   compatible = "thine,thc63lvd1024";
> > +
> > +   vcc-supply = <_lvds_vcc>;
> > +   lvcc-supply = <_lvds_lvcc>;
> > +
> > +   pwdn-gpio = < 15 GPIO_ACTIVE_LOW>;
> And here another variation :), should be pdwn-gpios.

Next time it will be "pndw".. Is there a prize if I do insert all
permutations of the same name in a single bindings document? :)

Will fix this shortly.

Thanks
   j


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] omapdrm changes for v4.17, try 2

[Tomi Valkeinen]

Hi Dave,

Here's the omapdrm pull request with the compile errors fixed. I found
another one while going through different kconfig combinations.

Sorry about those. I think it's time to build a script to compile with
all the possible combinations...

 Tomi

The following changes since commit f073d78eeb8efd85718e611c15f9a78647751dea:

  Merge tag 'drm-intel-next-2018-02-21' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2018-03-01 14:07:22 
+1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.17

for you to fetch changes up to 037f03155b7d87e85168b4296516bfda5c9f6380:

  drm/omap: fix compile error when DPI is disabled (2018-03-14 10:39:50 +0200)


omapdrm patches for v4.17

* Fix sparse warnings from omapdrm
* HPD support for DVI connector
* Big cleanup to remove static variables


Benoit Parrot (2):
  drm/omap: dispc: disp_wb_setup to check return code
  drm/omap: Add pclk setting case when channel is DSS_WB

Jyri Sarha (1):
  drm/omap: Allow HDMI audio setup even if we do not have video configured

Laurent Pinchart (46):
  drm: omapdrm: Use kernel integer types
  drm: omapdrm: Use unsigned int type
  drm: omapdrm: connector-analog-tv: Remove tvc_of_match forward declaration
  drm: omapdrm: displays: Remove OF node check in connector drivers
  drm: omapdrm: displays: Remove OF node check in encoder drivers
  drm: omapdrm: displays: Remove OF node check in panel drivers
  drm: omapdrm: displays: Get connector source at connect time
  drm: omapdrm: displays: Get panel source at connect time
  drm: omapdrm: displays: Get encoder source at connect time
  drm: omapdrm: dss: Make omapdss_default_get_timings static
  drm: omapdrm: dss: Don't export functions internal to omapdss-base
  drm: omapdrm: dss: Move initialization code from component bind to probe
  drm: omapdrm: dss: Remove dss_get_hdmi_venc_clk_source() function
  drm: omapdrm: dss: Remove unused functions prototypes
  drm: omapdrm: dsi: Make wait_for_bit_change() return a status
  drm: omapdrm: Split init and cleanup from probe and remove functions
  drm: omapdrm: dss: Expose DSS data in a dss_device structure
  drm: omapdrm: dss: Pass DSS private structure to runtime PM functions
  drm: omapdrm: dss: Pass PLL pointer to dss_ctrl_pll_enable()
  drm: omapdrm: dss: Pass DSS pointer to dss_sdi_*() functions
  drm: omapdrm: dss: Pass DSS pointer to dss_ops operations
  drm: omapdrm: dss: Pass DSS pointer to dss_get_*_clk_source()
  drm: omapdrm: dss: Pass DSS pointer to dss clock functions
  drm: omapdrm: dss: Pass DSS pointer to remaining dss functions
  drm: omapdrm: dss: Allocate the DSS private data structure dynamically
  drm: omapdrm: dss: Support passing private data to debugfs show handlers
  drm: omapdrm: dss: Store the registered plls array in struct dss_device
  drm: omapdrm: dss: Store the debugfs root directory in struct dss_device
  drm: omapdrm: dss: Don't unnecessarily cast to dev to pdev and back
  drm: omapdrm: dsi: Pass the dsi_data pointer to internal functions
  drm: omapdrm: dsi: Combine two commonly used inline functions
  drm: omapdrm: dsi: Use dev pointer directly in dsi_bind() function
  drm: omapdrm: dsi: Store the struct device pointer in struct dsi_data
  drm: omapdrm: dsi: Don't pass channel to dispc init/uninit functions
  drm: omapdrm: dss: Pass omap_dss_device pointer to dss_mgr_*() functions
  drm: omapdrm: dss: Pass omap_drm_private pointer to dss_mgr_ops
  drm: omapdrm: dss: Store DSS device pointer in the omapdrm private data
  drm: omapdrm: dss: Store dispc ops in dss_device structure
  drm: omapdrm: dispc: Pass DISPC pointer to dispc_ops operations
  drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions
  drm: omapdrm: dispc: Allocate the dispc private data structure dynamically
  drm: omapdrm: hdmi4: Allocate the omap_hdmi data structure dynamically
  drm: omapdrm: hdmi5: Allocate the omap_hdmi data structure dynamically
  drm: omapdrm: sdi: Allocate the sdi private data structure dynamically
  drm: omapdrm: venc: Allocate the venc private data structure dynamically
  drm: omapdrm: displays: panel-dsi-cm: Fix field access before set

Peter Ujfalusi (1):
  drm/omap: Init fbdev emulation only when we have displays

Tomi Valkeinen (19):
  drm/omap: reorganize locking in mgr_fld_write
  drm/omap: acx565akm:  use __be32 when reading status
  drm/omap: fbdev: use 'screen_buffer' field
  drm/omap: fbdev: avoid double initializer entry
  drm/omap: fix omap_fbdev_free() when omap_fbdev_create() wasn't called
  drm/omap: cleanup fbdev init/free
  drm/omap: add HPD 

Re: [PATCH] drm/panel: rm68200: add backlight dependency

[Arnd Bergmann]

On Wed, Mar 14, 2018 at 12:01 AM, Thierry Reding
 wrote:
> On Tue, Mar 13, 2018 at 09:59:54PM +0100, Arnd Bergmann wrote:
>> Like many other panel drivers, this one fails to build
>> when backlight support is disabled:
>>
>> drivers/gpu/drm/panel/panel-raydium-rm68200.o: In function `rm68200_probe':
>> panel-raydium-rm68200.c:(.text+0x14a): undefined reference to 
>> `devm_of_find_backlight'
>>
>> This adds the appropriate dependency.
>>
>> Fixes: 2b7ed18bed1a ("drm/panel: Add support for Raydium RM68200 panel 
>> driver")
>> Signed-off-by: Arnd Bergmann 
>> ---
>>  drivers/gpu/drm/panel/Kconfig | 1 +
>>  1 file changed, 1 insertion(+)
>
> This shouldn't be necessary. include/linux/backlight.h defines a stub if
> the backlight class is not enabled.
>
> What tree are you seeing this on?

This is on linux-next.

It must be with BACKLIGHT_CLASS_DEVICE=m and
DRM_PANEL_RAYDIUM_RM68200=y, meaning that it should
be sufficient to do

depends on BACKLIGHT_CLASS_DEVICE || BACKLIGHT_CLASS_DEVICE=n

to force DRM_PANEL_RAYDIUM_RM68200 to be a loadable module
whenever BACKLIGHT_CLASS_DEVICE=m. For the patch, I looked at
what the other drivers in the same directory do and followed their
example.

I see three options here:

1. update my patch changelog with the explanation I wrote here but leave it
untouched
2. use the more elaborate dependency (after testing) but not change the
others
3. change all panel drivers with a backlight dependency the same way,
possibly with a helper symbol like

config BACKLIGHT_CLASS_DEVICE_OPTIONAL
 tristate
 default m if BACKLIGHT_CLASS_DEVICE=m
 default y

  Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver

[Andrzej Hajda]

On 13.03.2018 15:30, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output decoder.

IMO converter suits here better, but it is just suggestion.

>
> Signed-off-by: Jacopo Mondi 
> ---
>  drivers/gpu/drm/bridge/Kconfig|   7 +
>  drivers/gpu/drm/bridge/Makefile   |   1 +
>  drivers/gpu/drm/bridge/thc63lvd1024.c | 241 
> ++
>  3 files changed, 249 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
>
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 3b99d5a..facf6bd 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -92,6 +92,13 @@ config DRM_SII9234
> It is an I2C driver, that detects connection of MHL bridge
> and starts encapsulation of HDMI signal.
>  
> +config DRM_THINE_THC63LVD1024
> + tristate "Thine THC63LVD1024 LVDS decoder bridge"
> + depends on OF
> + select DRM_PANEL_BRIDGE

You don't use PANEL_BRIDGE, it should be possible to drop the select.

> + ---help---
> +   Thine THC63LVD1024 LVDS decoder bridge driver.

Decoder to what?
Maybe it would be better to say it is LVDS/parallel or LVDS/RGB
converter or bridge.

> +
>  config DRM_TOSHIBA_TC358767
>   tristate "Toshiba TC358767 eDP bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index 373eb28..fd90b16 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
>  obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
>  obj-$(CONFIG_DRM_SII9234) += sii9234.o
> +obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
>  obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c 
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> new file mode 100644
> index 000..4b059c0
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -0,0 +1,241 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * THC63LVD1024 LVDS to parallel data DRM bridge driver.
> + *
> + * Copyright (C) 2018 Jacopo Mondi 
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +static const char * const thc63_reg_names[] = {
> + "vcc", "lvcc", "pvcc", "cvcc", };
> +
> +struct thc63_dev {
> + struct device *dev;
> +
> + struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
> +
> + struct gpio_desc *pwdn;
> + struct gpio_desc *oe;
> +
> + struct drm_bridge bridge;
> + struct drm_bridge *next;
> +};
> +
> +static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct thc63_dev, bridge);
> +}
> +
> +static int thc63_attach(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> +}
> +
> +static void thc63_enable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_enable(vcc);
> + if (ret)
> + goto error_vcc_enable;
> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 0);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 1);
> +
> + return;
> +
> +error_vcc_enable:
> + dev_err(thc63->dev, "Failed to enable regulator %u\n", i);
> +}
> +
> +static void thc63_disable(struct drm_bridge *bridge)
> +{
> + struct thc63_dev *thc63 = to_thc63(bridge);
> + struct regulator *vcc;
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
> + vcc = thc63->vccs[i];
> + if (vcc) {
> + ret = regulator_disable(vcc);
> + if (ret)
> + goto error_vcc_disable;

I think in disable path you can report an error and continue - should be
safer.

> + }
> + }
> +
> + if (thc63->pwdn)
> + gpiod_set_value(thc63->pwdn, 1);
> +
> + if (thc63->oe)
> + gpiod_set_value(thc63->oe, 0);

Usually disable uses reverse order. Ie first disable oe, then, pwdn,
then regulators, also in reverse order.
Looks more reasonable.

> +
> + return;
> +
> +error_vcc_disable:
> + dev_err(thc63->dev, "Failed to disable regulator %u\n", i);
> +}
> +
> +struct drm_bridge_funcs thc63_bridge_func = {
> + .attach = 

Re: [PATCH v2 02/11] media: vsp1: Remove packed attributes from aligned structures

[Geert Uytterhoeven]

On Tue, Mar 13, 2018 at 7:05 PM, Kieran Bingham
 wrote:
> The use of the packed attribute can cause a performance penalty for
> all accesses to the struct members, as the compiler will assume that the
> structure has the potential to have an unaligned base.
>
> These structures are all correctly aligned and contain no holes, thus
> the attribute is redundant and negatively impacts performance, so we
> remove the attributes entirely.
>
> Signed-off-by: Kieran Bingham 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

[Andrzej Hajda]

On 13.03.2018 15:30, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi 
> ---
>  .../bindings/display/bridge/thine,thc63lvd1024.txt | 63 
> ++
>  1 file changed, 63 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt 
> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> new file mode 100644
> index 000..5b5afcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
> @@ -0,0 +1,63 @@
> +Thine Electronics THC63LVD1024 LVDS decoder
> +---
> +
> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS 
> streams
> +to parallel data outputs. The chip supports single/dual input/output modes,
> +handling up to two two input LVDS stream and up to two digital CMOS/TTL 
> outputs.
> +
> +Required properties:
> +- compatible: Shall be "thine,thc63lvd1024",
> +
> +Optional properties:
> +- vcc-supply: Power supply for TTL output and digital circuitry
> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
> +- lvcc-supply: Power supply for LVDS inputs
> +- pvcc-supply: Power supply for PLL circuitry

I wonder if it wouldn't be better to make them required (at least VCC) -
it is closer to reality.

> +- pwnd-gpios: Power down GPIO signal. Active low.

As I said before, specs[1] says about "/PDWN" pin. Is it your typo, or
different docs?
Moreover there are already bindings for THC63LVDM83D with the same
dichotomy [2].

Out of curiosity I have googled for "pwnd pin" and it looks like some
vendors use this form.
For me both forms are quite misleading: power down signal, active low,
why they couldn't call it just 'enable, active high'.

[1]: http://www.thine.co.jp/files/topics/179_ext_12_0.pdf
[2]:
https://elixir.bootlin.com/linux/v4.16-rc5/source/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt

> +- oe-gpios: Output enable GPIO signal. Active high.
> +
> +The THC63LVD1024 video port connections are modeled according
> +to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
> +
> +Required video port nodes:
> +- Port@0: First LVDS input port
> +- Port@2: First digital CMOS/TTL parallel output
> +
> +Optional video port nodes:
> +- Port@1: Second LVDS input port
> +- Port@3: Second digital CMOS/TTL parallel output
> +
> +Example:
> +
> +
> + thc63lvd1024: lvds-decoder {
> + compatible = "thine,thc63lvd1024";
> +
> + vcc-supply = <_lvds_vcc>;
> + lvcc-supply = <_lvds_lvcc>;
> +
> + pwdn-gpio = < 15 GPIO_ACTIVE_LOW>;
And here another variation :), should be pdwn-gpios.

> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_dec_in_0: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> +
> + port@2{
> + reg = <2>;
> +
> + lvds_dec_out_2: endpoint {
> + remote-endpoint = <_in>;
> + };
> +
> + };
> +
> + };
> + };


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=198883

--- Comment #57 from Nicolai Hähnle (nhaeh...@gmail.com) ---
(In reply to Ricardo Ribalda from comment #46)

This was due to the constant address space change in LLVM. It has since been
fixed in Mesa master.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: merge conflict between drm-misc and sound trees

[Stephen Rothwell]

Hi Takashi,

On Wed, 14 Mar 2018 08:37:12 +0100 Takashi Iwai  wrote:
>
> FYI, there was yet another fix over the relevant code, but the
> conflict resolution must be trivial as well.

OK, thanks as well.

-- 
Cheers,
Stephen Rothwell


pgpiIka6PJOwm.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel