Re: [PATCH AUTOSEL 5.4 003/205] drm/v3d: don't leak bin job if v3d_job_init fails.

2020-01-16 Thread Iago Toral
Hi Sasha,


please notice that there were two separate patches that addressed the
same issue and applying both simultaneously leads to a double free
(which is what I see is happening with this patch: see the second call
to kfree(bin) right below the one added here). This issue was raised
previously here:

https://lists.freedesktop.org/archives/dri-devel/2019-October/241425.html

Iago

On Thu, 2020-01-16 at 11:39 -0500, Sasha Levin wrote:
> From: Iago Toral Quiroga 
> 
> [ Upstream commit 0d352a3a8a1f26168d09f7073e61bb4b328e3bb9 ]
> 
> If the initialization of the job fails we need to kfree() it
> before returning.
> 
> Signed-off-by: Iago Toral Quiroga 
> Signed-off-by: Eric Anholt 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20190916071125.5255-1-ito...@igalia.com
> Fixes: a783a09ee76d ("drm/v3d: Refactor job management.")
> Reviewed-by: Eric Anholt 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/gpu/drm/v3d/v3d_gem.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
> b/drivers/gpu/drm/v3d/v3d_gem.c
> index 19c092d75266..6316bf3646af 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -565,6 +565,7 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void
> *data,
>   ret = v3d_job_init(v3d, file_priv, >base,
>  v3d_job_free, args->in_sync_bcl);
>   if (ret) {
> + kfree(bin);
>   v3d_job_put(>base);
>   kfree(bin);
>   return ret;

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


Re: [PATCH v2 4/4] drm/simple-kms: Let DRM core send VBLANK events by default

2020-01-16 Thread Thomas Zimmermann
Hi

Am 17.01.20 um 00:59 schrieb Daniel Vetter:
> On Thu, Jan 16, 2020 at 05:22:34PM +, Emil Velikov wrote:
>> Hi all,
>>
>> On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann  wrote:
>>
 diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
 b/drivers/gpu/drm/drm_atomic_state_helper.c
 index 7cf3cf936547..23d2f51fc1d4 100644
 --- a/drivers/gpu/drm/drm_atomic_state_helper.c
 +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
 @@ -149,6 +149,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
 drm_crtc *crtc,
   /* Self refresh should be canceled when a new update is available */
   state->active = drm_atomic_crtc_effectively_active(state);
   state->self_refresh_active = false;
 +
 + if (drm_dev_has_vblank(crtc->dev))
 + state->no_vblank = true;
 + else
 + state->no_vblank = false;
  }
  EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>>>
>>> I think the if/else branches are in the wrong order.
> 
> Yeah fumbled that.
> 
>>> But generally speaking, is it really that easy? The xen driver already
>>> has to work around simple-kms's auto-enabling of no_vblank (see patch
>>> 4). Maybe this settings interferes with other drivers as well. At least
>>> the calls for sending fake vblanks should be removed from all affected
>>> drivers.
> 
> Hm xen is really special, in that it has a flip complete event, but not a
> vblank. I think forcing drivers to overwrite stuff in that case makes
> sense.
> 
>> I'm not sure if setting no_vblank based on dev->num_crtcs is the correct 
>> thing.
>> From the original commit and associated description for no_vblank:
>>
>> In some cases CRTCs are active but are not able to generating events, at
>> least not at every frame at it's expected to.
>> This is typically the case when the CRTC is feeding a writeback connector...
> 
> Yeah, but Thomas' series here wants to extend that. And I think if we roll
> this out the common case will be "no hw vblank", and the writeback special

Default values should usually be 0 for zalloc and static initializers.
Should we rename no_vblank to has_vblank then?

> case is going to be the exception to the exception. Yup, patch 1 that
> updates the docs doesn't reflect that, which is why I'm bringing up more
> suggestions here around code & semantics of all these pieces to make them
> do the most reasonable thing for most of the drivers.
> 
>> Reflects the ability of a CRTC to send VBLANK events
>>
>>
>> The proposed handling of no_vblank feels a little dirty, although
>> nothing better comes to mind.
>> Nevertheless code seems perfectly reasonable, so if it were me I'd merge it.
> 
> The idea with setting it very early is that drivers can overwrite it very
> easily. Feels slightly dirty, so I guess we could also set it somewhere in
> the atomic_helper_check function (similar to how we set the various
> crtc->*_changed flags, but we're not entirely consistent on these either).
> 
> For the overall thing what feels irky to me is making this no_vblank
> default logic (however we end up computing it in the end, whether like
> this or what I suggested) specific to simple pipe helpers feels kinda
> wrong. Simple pipe tends to have a higher ratio of drivers for hw without
> vblank support, but by far not the only ones. Having that special case
> feels confusing to me (and likely will trip up some people, vblank and
> event handling is already a huge source of confusion in drm).

Making it a default for simple KMS was only the start. I intended to
cover all drivers at some point. I just didn't want to go through all
drivers at once.

I guess for the patchset's v3 I'll audit all drivers for the use of
no_blank and drm_crtc_send_vblank_event(); and convert the possible
candidates.

Best regards
Thomas

> 
> One idea behind drm_dev_has_vblank() is also that we could formalize a bit
> all that, at least for the usual case - xen and maybe others being some
> exceptions as usual (hence definitely not something the core code should
> handle).
> 
> Cheers, Daniel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



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


[radeon-alex:amd-19.50 1962/2704] include/kcl/kcl_drm.h:191:9: error: too few arguments to function 'drm_encoder_init'

2020-01-16 Thread kbuild test robot
Hi Yifan,

FYI, the error/warning still remains.

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head:   1f30c089d757f6d88703676d913f06d8a5ef4353
commit: 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff [1962/2704] drm/amdkcl: Test 
whether drm_encoder_init() wants name
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff
# save the attached .config to linux build tree
make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
   include/kcl/kcl_drm.h:98:1: error: conflicting types for 
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
   In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
   include/drm/drm_fb_helper.h:589:1: note: previous definition of 
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
   In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
   include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
>> include/kcl/kcl_drm.h:191:9: error: too few arguments to function 
>> 'drm_encoder_init'
 return drm_encoder_init(dev, encoder, funcs,
^~~~
   In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
   include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~

vim +/drm_encoder_init +191 include/kcl/kcl_drm.h

5027d12c82b867 changzhu 2019-04-03  181  
950c9c93299ece Junwei Zhang 2016-12-23  182  static inline int 
kcl_drm_encoder_init(struct drm_device *dev,
950c9c93299ece Junwei Zhang 2016-12-23  183   struct 
drm_encoder *encoder,
950c9c93299ece Junwei Zhang 2016-12-23  184   const struct 
drm_encoder_funcs *funcs,
950c9c93299ece Junwei Zhang 2016-12-23  185   int encoder_type, 
const char *name, ...)
950c9c93299ece Junwei Zhang 2016-12-23  186  {
35781c0b8d19ed Yifan Zhang  2019-07-15  187  #if 
defined(HAVE_DRM_ENCODER_INIT_VALID_WITH_NAME)
950c9c93299ece Junwei Zhang 2016-12-23  188 return drm_encoder_init(dev, 
encoder, funcs,
950c9c93299ece Junwei Zhang 2016-12-23  189  encoder_type, 
name);
950c9c93299ece Junwei Zhang 2016-12-23  190  #else
950c9c93299ece Junwei Zhang 2016-12-23 @191 return drm_encoder_init(dev, 
encoder, funcs,
950c9c93299ece Junwei Zhang 2016-12-23  192  encoder_type);
950c9c93299ece Junwei Zhang 2016-12-23  193  #endif
950c9c93299ece Junwei Zhang 2016-12-23  194  }
950c9c93299ece Junwei Zhang 2016-12-23  195  

:: The code at line 191 was first introduced by commit
:: 950c9c93299eceb8cca4b12eb09a04a48d383ec6 drm/amdkcl: [4.5] fix drm 
encoder and plane functions

:: TO: Junwei Zhang 
:: CC: Chengming Gui 

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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


[PATCH v2 0/1] Take SST-only branch device into account

2020-01-16 Thread Wayne Lin
Noticed this while testing 4 ports MST hub from StarTech.com.
While plugging in and display a MST monitor(Dell U2417H), change the MST
feature to off from OSD. Monitor then can't display anymore.

After analyzing, found out that the CSN reports the specific port from
Device with MST Branching Unit (Message_Capability_Status=1 &&
Peer_Device_Type=010) to SST-only Branch Device ((Message_Capability_Status=0 &&
Peer_Device_Type=010). Current code expects peer device as MST branch
device and can handle sideband message once the peer device type is
declared as Peer_Device_Type=010. But for SST-only Branch Device, its
Peer_Device_Type is 010 and can't handle sideband message. For this case,
we should follow the same handling procedure as the case in
DP_PEER_DEVICE_DP_LEGACY_CONV & DP_PEER_DEVICE_SST_SINK.

This patch is trying to add the SST-only branch device case in and remain
the original processing logic in current code.

Changes since v1:(https://patchwork.kernel.org/cover/11323075/)
* Squash previous two patches into one patch
* Combine if statements to have code cleaner

Wayne Lin (1):
  drm/dp_mst: Handle SST-only branch device case

 drivers/gpu/drm/drm_dp_mst_topology.c | 140 +++---
 1 file changed, 80 insertions(+), 60 deletions(-)

-- 
2.17.1

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


[PATCH v2 1/1] drm/dp_mst: Handle SST-only branch device case

2020-01-16 Thread Wayne Lin
[Why]
While handling LINK_ADDRESS reply, current code expects a peer device
can handle sideband message once the peer device type is reported as
DP_PEER_DEVICE_MST_BRANCHING. However, when the connected device is
a SST branch case, it can't handle the sideband message(MST_CAP=0 in
DPCD 00021h).

Current code will try to send LINK_ADDRESS to SST branch device and end
up with message timeout and monitor can't display normally. As the
result of that, we should take SST branch device into account.

[How]
According to DP 1.4 spec, we can use Peer_Device_Type as
DP_PEER_DEVICE_MST_BRANCHING and Message_Capability_Status as 0 to
indicate peer device as a SST-only branch device.

Fix following:
- Add the function drm_dp_mst_is_dp_mst_end_device() to decide whether a
peer device connected to a DFP is mst end device. Which also indicates
if the peer device is capable of handling message or not.
- Take SST-only branch device case into account in
drm_dp_port_set_pdt() and add a new parameter 'new_mcs'. Take sst branch
device case as the same case as DP_PEER_DEVICE_DP_LEGACY_CONV and
DP_PEER_DEVICE_SST_SINK. All original handling logics remain.
- Take SST-only branch device case into account in
drm_dp_mst_port_add_connector().
- Fix some parts in drm_dp_mst_handle_link_address_port() to have SST
branch device case into consideration.
- Fix the arguments of drm_dp_port_set_pdt() in
drm_dp_mst_handle_conn_stat().
- Have SST branch device also report
connector_status_connected when the ddps is true
in drm_dp_mst_detect_port()
- Fix the arguments of drm_dp_port_set_pdt() in
drm_dp_delayed_destroy_port()

Changes since v1:(https://patchwork.kernel.org/patch/11323079/)
* Squash previous patch into one patch and merge the commit message here.
* Combine the if statements mentioned in comments

Fixes: c485e2c97dae ("drm/dp_mst: Refactor pdt setup/teardown, add more 
locking")
Cc: Ville Syrjälä 
Cc: Harry Wentland 
Cc: Lyude Paul 
Signed-off-by: Wayne Lin 
Reviewed-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 140 +++---
 1 file changed, 80 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 79691c553182..c40a9bd63cfb 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1914,73 +1914,90 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port 
*port,
return parent_lct + 1;
 }
 
-static int drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt)
+static bool drm_dp_mst_is_dp_mst_end_device(u8 pdt, bool mcs)
+{
+   switch (pdt) {
+   case DP_PEER_DEVICE_DP_LEGACY_CONV:
+   case DP_PEER_DEVICE_SST_SINK:
+   return true;
+   case DP_PEER_DEVICE_MST_BRANCHING:
+   /* For sst branch device */
+   if (!mcs)
+   return true;
+
+   return false;
+   }
+   return true;
+}
+
+static int
+drm_dp_port_set_pdt(struct drm_dp_mst_port *port, u8 new_pdt,
+   bool new_mcs)
 {
struct drm_dp_mst_topology_mgr *mgr = port->mgr;
struct drm_dp_mst_branch *mstb;
u8 rad[8], lct;
int ret = 0;
 
-   if (port->pdt == new_pdt)
+   if (port->pdt == new_pdt && port->mcs == new_mcs)
return 0;
 
/* Teardown the old pdt, if there is one */
-   switch (port->pdt) {
-   case DP_PEER_DEVICE_DP_LEGACY_CONV:
-   case DP_PEER_DEVICE_SST_SINK:
-   /*
-* If the new PDT would also have an i2c bus, don't bother
-* with reregistering it
-*/
-   if (new_pdt == DP_PEER_DEVICE_DP_LEGACY_CONV ||
-   new_pdt == DP_PEER_DEVICE_SST_SINK) {
-   port->pdt = new_pdt;
-   return 0;
-   }
+   if (port->pdt != DP_PEER_DEVICE_NONE) {
+   if (drm_dp_mst_is_dp_mst_end_device(port->pdt, port->mcs)) {
+   /*
+* If the new PDT would also have an i2c bus,
+* don't bother with reregistering it
+*/
+   if (new_pdt != DP_PEER_DEVICE_NONE &&
+   drm_dp_mst_is_dp_mst_end_device(new_pdt, new_mcs)) {
+   port->pdt = new_pdt;
+   port->mcs = new_mcs;
+   return 0;
+   }
 
-   /* remove i2c over sideband */
-   drm_dp_mst_unregister_i2c_bus(>aux);
-   break;
-   case DP_PEER_DEVICE_MST_BRANCHING:
-   mutex_lock(>lock);
-   drm_dp_mst_topology_put_mstb(port->mstb);
-   port->mstb = NULL;
-   mutex_unlock(>lock);
-   break;
+   /* remove i2c over sideband */
+   drm_dp_mst_unregister_i2c_bus(>aux);
+   } else {
+

Re: [RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include

2020-01-16 Thread Zhenyu Wang
On 2020.01.16 15:13:01 +0100, Julian Stecklina wrote:
> Hi Greg, Christoph,
> 
> On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote:
> > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote:
> > > Now that the GVT interface to hypervisors does not depend on i915/GVT
> > > internals anymore, we can move the headers to the global include/.
> > > 
> > > This makes out-of-tree modules for hypervisor integration possible.
> > 
> > What kind of out-of-tree modules do you need/want for this?
> 
> The mediated virtualization support in the i915 driver needs a backend to the
> hypervisor. There is currently one backend for KVM in the tree
> (drivers/gpu/drm/i915/gvt/kvmgt.c) and at least 3 other hypervisor backends 
> out
> of tree in various states of development that I know of. We are currently
> developing one of these.
> 
> > 
> > Also, as Christoph said, adding exports for functions that are not used
> > by anything within the kernel tree itself is not ok, that's not how we
> > work.
> 
> The exports are used by the KVM hypervisor backend. The patchset I sent
> basically decouples KVMGT from i915 driver internals. So personally I would
> count this as a benefit in itself.
> 
> There is already an indirection in place that looks like it is intended to
> decouple the hypervisor backends from the i915 driver core: intel_gvt_ops. 
> This
> is a struct of function pointers that the hypervisor backend uses to talk to 
> the
> GPU mediator code.
> 
> Unfortunately, this struct doesn't cover all usecases and the KVM hypervisor
> backend directly touches the i915 devices' internal state in very few places. 
> My
> current solution was to wrap these accesses in accessor functions and
> EXPORT_SYMBOL_GPL them.
> 
> If the more acceptable solution is to add more function pointers to
> intel_gvt_ops instead of exporting symbols, I'm happy to go along this route.
>

That depends on the hypervisor requirement and purpose, if it requires
gvt device model for some function e.g emulate mmio, we want it to be
a general gvt_ops, if it just trys to retrieve some vgpu info, we
might see if some common wrapper of internal data would be more easier.

> > And why do they somehow have to be out of the tree?  We want them in the
> > tree, and so should you, as it will save you time and money if they are.
> 
> I also want these hypervisor backends in the tree, but from a development
> workflow having the ability to build them as a out-of-tree modules is very
> convenient. I guess this is also true for the developers working on the other
> hypervisor backends.
> 
> When I looked at the status quo in i915/gvt a couple of weeks ago, it seemed
> like it would be a win for everyone. Let me just clearly say that we have no
> intention of doing binary blob drivers. :)
>

yeah, we do like to see more hypervisor support and make more clear interface
between core device model with that.

thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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


[PATCH 2/4] drm/mst: Some style improvements in drm_dp_mst_topology_mgr_set_mst()

2020-01-16 Thread José Roberto de Souza
Removing this lose code block and removing unnecessary bracket.

Cc: Lyude Paul 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 38bf111e5f9b..e3a22362aaf2 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3491,6 +3491,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
mgr->mst_state = mst_state;
/* set the device into MST mode */
if (mst_state) {
+   struct drm_dp_payload reset_pay;
+
WARN_ON(mgr->mst_primary);
 
/* get dpcd info */
@@ -3521,16 +3523,12 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
 
ret = drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL,
 DP_MST_EN | 
DP_UP_REQ_EN | DP_UPSTREAM_IS_SRC);
-   if (ret < 0) {
+   if (ret < 0)
goto out_unlock;
-   }
 
-   {
-   struct drm_dp_payload reset_pay;
-   reset_pay.start_slot = 0;
-   reset_pay.num_slots = 0x3f;
-   drm_dp_dpcd_write_payload(mgr, 0, _pay);
-   }
+   reset_pay.start_slot = 0;
+   reset_pay.num_slots = 0x3f;
+   drm_dp_dpcd_write_payload(mgr, 0, _pay);
 
queue_work(system_long_wq, >work);
 
-- 
2.25.0

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


[PATCH 1/4] drm/mst: Don't do atomic checks over disabled managers

2020-01-16 Thread José Roberto de Souza
When a main MST port is disconnected drivers should call
drm_dp_mst_topology_mgr_set_mst() disabling the MST manager, this
function will set manager mst_primary to NULL and it will cause the
crash bellow on the next atomic check when trying to access
mst_primary->port.

As there is no use in running checks over managers that are not
active this patch will skip it.

[  305.616450] [drm:drm_dp_mst_atomic_check] [MST PORT:cc2049e9] 
releases all VCPI slots
[  305.625085] [drm:drm_dp_mst_atomic_check] [MST PORT:020ab43e] 
releases all VCPI slots
[  305.633729] [drm:drm_dp_mst_atomic_check] [MST MGR:cdd467d4] mst 
state b67672eb VCPI avail=63 used=0
[  305.644405] BUG: kernel NULL pointer dereference, address: 0030
[  305.651448] #PF: supervisor read access in kernel mode
[  305.656640] #PF: error_code(0x) - not-present page
[  305.661807] PGD 0 P4D 0
[  305.664396] Oops:  [#1] PREEMPT SMP NOPTI
[  305.668789] CPU: 3 PID: 183 Comm: kworker/3:2 Not tainted 5.5.0-rc6+ #1404
[  305.675703] Hardware name: Intel Corporation Ice Lake Client 
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS 
ICLSFWR1.R00.3201.A00.1905140358 05/14/2019
[  305.689425] Workqueue: events drm_dp_delayed_destroy_work
[  305.694874] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0
[  305.700306] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 
b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 
30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28
[  305.719169] RSP: 0018:c90001687b58 EFLAGS: 00010246
[  305.724434] RAX:  RBX: 003f RCX: 
[  305.731611] RDX:  RSI: 88849fba8cb8 RDI: 
[  305.738785] RBP:  R08:  R09: 0001
[  305.745962] R10: c900016879a0 R11: c900016879a5 R12: 
[  305.753139] R13:  R14: 8884905c9bc0 R15: 
[  305.760315] FS:  () GS:88849fb8() 
knlGS:
[  305.768452] CS:  0010 DS:  ES:  CR0: 80050033
[  305.774263] CR2: 0030 CR3: 05610006 CR4: 00760ee0
[  305.781441] PKRU: 5554
[  305.784228] Call Trace:
[  305.786739]  intel_atomic_check+0xb2e/0x2560 [i915]
[  305.791678]  ? printk+0x53/0x6a
[  305.794856]  ? drm_atomic_check_only+0x3e/0x810
[  305.799417]  ? __drm_dbg+0x82/0x90
[  305.802848]  drm_atomic_check_only+0x56a/0x810
[  305.807322]  drm_atomic_commit+0xe/0x50
[  305.811185]  drm_client_modeset_commit_atomic+0x1e2/0x250
[  305.816619]  drm_client_modeset_commit_force+0x4d/0x180
[  305.821921]  drm_fb_helper_restore_fbdev_mode_unlocked+0x46/0xa0
[  305.827963]  drm_fb_helper_set_par+0x2b/0x40
[  305.832265]  drm_fb_helper_hotplug_event.part.0+0xb2/0xd0
[  305.837755]  drm_kms_helper_hotplug_event+0x21/0x30
[  305.842694]  process_one_work+0x25b/0x5b0
[  305.846735]  worker_thread+0x4b/0x3b0
[  305.850439]  kthread+0x100/0x140
[  305.853690]  ? process_one_work+0x5b0/0x5b0
[  305.857901]  ? kthread_park+0x80/0x80
[  305.861588]  ret_from_fork+0x24/0x50
[  305.865202] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic i915 btusb btrtl btbcm btintel bluetooth prime_numbers 
snd_hda_intel snd_intel_dspcfg snd_hda_codec e1000e snd_hwdep snd_hda_core 
thunderbolt mei_hdcp mei_me asix cdc_ether x86_pkg_temp_thermal r8152 mei 
coretemp usbnet snd_pcm mii crct10dif_pclmul ptp crc32_pclmul ecdh_generic 
ghash_clmulni_intel pps_core ecc i2c_i801 intel_lpss_pci
[  305.903096] CR2: 0030
[  305.906431] ---[ end trace 70ee364eed801cb0 ]---
[  305.940816] RIP: 0010:drm_dp_mst_atomic_check+0x138/0x2c0
[  305.946261] Code: 00 00 00 41 29 d9 41 89 d8 4c 89 fa 4c 89 f1 48 c7 c6 b0 
b1 34 82 bf 10 00 00 00 45 31 ed e8 3f 99 02 00 4d 8b bf 80 04 00 00 <49> 8b 47 
30 49 8d 5f 30 4c 8d 60 e8 48 39 c3 74 35 49 8b 7c 24 28
[  305.965125] RSP: 0018:c90001687b58 EFLAGS: 00010246
[  305.970382] RAX:  RBX: 003f RCX: 
[  305.977571] RDX:  RSI: 88849fba8cb8 RDI: 
[  305.984747] RBP:  R08:  R09: 0001
[  305.991921] R10: c900016879a0 R11: c900016879a5 R12: 
[  305.999099] R13:  R14: 8884905c9bc0 R15: 
[  306.006271] FS:  () GS:88849fb8() 
knlGS:
[  306.014407] CS:  0010 DS:  ES:  CR0: 80050033
[  306.020185] CR2: 0030 CR3: 00048b3aa003 CR4: 00760ee0
[  306.027404] PKRU: 5554
[  306.030127] BUG: sleeping function called from invalid context at 
include/linux/percpu-rwsem.h:38
[  306.039049] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 183, 
name: kworker/3:2
[  306.047272] INFO: lockdep is turned off.
[  306.051217] irq event stamp: 77505
[  306.054647] 

[PATCH 4/4] drm/i915/display: Set TRANS_DDI_MODE_SELECT to default value when disabling TRANS_DDI

2020-01-16 Thread José Roberto de Souza
TGL timeouts when disabling MST transcoder and fifo underruns over MST
transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
mode) during the disable sequence.

Although BSpec disable sequence don't require this step it is a
harmless change and it is also done by Windows driver.
Anyhow HW team was notified about that but it can take some time to
documentation to be updated.

A case that always lead to those issues is:
- do a modeset enabling pipe A and pipe B in the same MST stream
leaving A as master
- disable pipe A, promote B as master doing a full modeset in A
- enable pipe A, changing the master transcoder back to A(doing a
full modeset in B)
- Pow: underruns and timeouts

The transcoders involved will only work again when complete disabled
and their power wells turned off causing a reset in their registers.

Cc: Ville Syrjälä 
Cc: Matt Roper 
Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c 
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 32ea3c7e8b62..82e90f271974 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1997,6 +1997,7 @@ void intel_ddi_disable_transcoder_func(const struct 
intel_crtc_state *crtc_state
 
val = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
val &= ~TRANS_DDI_FUNC_ENABLE;
+   val &= ~TRANS_DDI_MODE_SELECT_MASK;
 
if (INTEL_GEN(dev_priv) >= 12) {
if (!intel_dp_mst_is_master_trans(crtc_state))
-- 
2.25.0

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


[PATCH 3/4] drm/i915/display: Remove useless call intel_dp_mst_encoder_cleanup()

2020-01-16 Thread José Roberto de Souza
This is a eDP function and it will always returns true for non-eDP
ports.

Signed-off-by: José Roberto de Souza 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index 4074d83b1a5f..a50b5b6dd009 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -7537,7 +7537,6 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
intel_dp_aux_fini(intel_dp);
-   intel_dp_mst_encoder_cleanup(intel_dig_port);
goto fail;
}
 
-- 
2.25.0

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


[pull] amdgpu, amdkfd, scheduler drm-next-5.6

2020-01-16 Thread Alex Deucher
Hi Dave, Daniel,

Last pull for 5.6.  Mostly bug fixes.

The following changes since commit 688486a49cf500a193dfe15be9eb5aa468887769:

  Merge tag 'amd-drm-next-5.6-2020-01-10-dp-mst-dsc' of 
git://people.freedesktop.org/~agd5f/linux into drm-next (2020-01-13 17:14:34 
+1000)

are available in the Git repository at:

  git://people.freedesktop.org/~agd5f/linux tags/amd-drm-next-5.6-2020-01-16

for you to fetch changes up to 31635887cb8d899584484620b597e401b2350a79:

  drm/amd/display: skip opp blank or unblank if test pattern enabled 
(2020-01-16 14:17:08 -0500)


amd-drm-next-5.6-2020-01-16:

amdgpu:
- Fix 32 bit harder
- Powerplay cleanups
- VCN fixes for Arcturus
- RAS fixes
- eDP/DP fixes
- SR-IOV fixes
- Re-enable S/G display for PCO/RV2
- Free stolen memory after init on gmc10
- DF hashing optimizations for Arcturus
- Properly handle runtime pm in sysfs and debugfs
- Unify more GC programming between amdgpu and amdkfd
- Golden settings updates for gfx10
- GDDR6 training fixes
- Freesync fixes
- DSC fixes
- TMDS fixes
- Renoir USB-C fixes
- DC dml updates from hw team
- Pollock support

amdkfd:
- Unify more GC programming between amdgpu and amdkfd
- Use KIQ to setup HIQ rather than using MMIO

scheduler:
- Documentation fixes
- Improve job distribution with load sharing


Aaron Liu (3):
  drm/amd/powerplay: update SMU12_DRIVER_IF_VERSION to 11
  drm/amdgpu: update goldensetting for renoir
  drm/amdkfd: use kiq to load the mqd of hiq queue for gfx v9 (v6)

Alex Deucher (11):
  drm/amdgpu/powerplay: fix warning in smu_v11_0.c
  drm/amdgpu/gfx9: remove unused sdma headers
  drm/amdgpu/display: set gpu vm flag for all asics which support it
  drm/amdgpu: enable S/G display on PCO and RV2 (v2)
  drm/amdgpu/display: set gpu vm flag for renoir
  drm/amdgpu/gmc10: remove dead code
  drm/amdgpu/gmc10: free stolen memory in late_init
  drm/amdgpu/psp: declare navi1x ta firmware
  drm/amdgpu/pm: properly handle runtime pm
  drm/amdgpu/debugfs: properly handle runtime pm
  drm/amdgpu/pm: clean up return types

Alex Sierra (7):
  drm/amdgpu: Avoid reclaim fs while eviction lock
  drm/amdgpu: kiq pm4 function implementation for gfx_v9
  drm/amdgpu: implement tlbs invalidate on gfx9 gfx10
  drm/amdgpu: replace kcq enable/disable functions on gfx_v9
  drm/amdgpu: export function to flush TLB via pasid
  drm/amdgpu: GPU TLB flush API moved to amdgpu_amdkfd
  drm/amdgpu: flush TLB functions removal from kfd2kgd interface

Alvin Lee (3):
  drm/amd/display: Fix 300Hz Freesync bug
  drm/amd/display: Don't always set pstate true if dummy latency = 0
  drm/amd/display: Enable double buffer for OTG_BLANK

Amanda Liu (1):
  drm/amd/display: Clear state after exiting fixed active VRR state

Anthony Koo (1):
  drm/amd/display: make PSR static screen entry within 30 ms

Aric Cyr (4):
  drm/amd/display: 3.2.65
  drm/amd/display: 3.2.66
  drm/amd/display: 3.2.67
  drm/amd/display: 3.2.68

Charlene Liu (1):
  drm/amd/display: rename _lvp to l_vp

Chen Zhou (1):
  drm/amd/display: remove unnecessary conversion to bool

Chris Park (1):
  drm/amd/display: Add default switch case for DCC

Christian König (1):
  drm/amdgpu: drop amdgpu_job.owner

Dmytro Laktyushkin (1):
  drm/amd/display: expand dml structs

Eric Yang (1):
  drm/amd/display: fix chroma vp wa corner case

Evan Quan (2):
  drm/amd/powerplay: cover the powerplay implementation details V3
  drm/amd/powerplay: a quick fix for the deadlock issue below

Flora Cui (1):
  drm/amdgpu: add header file for macro SZ_1M

George Shen (1):
  drm/amd/display: Add w/a to reset PHY before link training in 
verify_link_cap

Guchun Chen (2):
  drm/amdgpu: add MCUMC_ADDRT0 offset to ip header file
  drm/amdgpu: calculate MCUMC_ADDRT0 per asic's UMC offset

Hawking Zhang (7):
  drm/amdgpu: add query_ras_error_count function for sdma v4
  drm/amdgpu: support error reporting for sdma ip block
  drm/amdgpu: add ras_late_init and ras_fini for sdma v4
  drm/amdgpu: read sdma edc counter to clear the counters
  drm/amdgpu: check sdma ras funcs pointer before accessing
  drm/amdgpu: check if driver should try recovery in ras recovery path
  drm/amdgpu: add arcturus to gpu recovery check code path

Huang Rui (2):
  drm/amdkfd: use map_queues for hiq on gfx v10 as well
  drm/amdgpu: only set cp active field for kiq queue

Jack Zhang (1):
  drm/amdgpu/sriov skip the update of SMU_TABLE_ACTIVITY_MONITOR_COEFF

James Zhu (6):
  drm/amdgpu/vcn: support multiple-instance dpg pause mode
  drm/amdgpu/vcn: support multiple instance direct SRAM read and write (v2)
  drm/amdgpu/vcn: move macro from vcn2.0 to share amdgpu_vcn (v2)
  drm/amdgpu/vcn2.5: add DPG mode 

[RFC PATCH v3 1/2] drm/i915: Add mechanism to submit a context WA on ring submission

2020-01-16 Thread Akeem G Abodunrin
From: Mika Kuoppala 

 NOTE: 
This series is in active development and is not intended to be merged to
mainline in its current form. The intent of the RFC is simply to outline
the strategy for the mitigation, as a focus for active discussion, and
to openly share progress. There has been only minimal attention paid to
performance thus far, as the focus is on robustness. It is not
anticipated that there will be any measurable performance impact in the
final version.
 END NOTE 

This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.

The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require rewriting the
ringbuffer. As each request would set up its own context, leaving it to
the HW to notice and elide no-op context switches, we could restart the
ring at any point, and reorder the requests freely.

However, to avoid emitting clear_residuals() between consecutive requests
in the ringbuffer of the same context, we do want to track the current
context in the ring. In doing so, we need to be careful to only record a
context switch when we are sure the next request will be emitted.

v2: No change
v3: elide optimization patch squashed, courtesy of Chris Wilson - the
changes show significant performance improvements, on par with current
drm-tips.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Akeem G Abodunrin 
Cc: Kumar Valsan Prathap 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
---
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 132 +-
 1 file changed, 129 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c 
b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
index bc44fe8e5ffa..58500032c993 100644
--- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
@@ -1384,7 +1384,9 @@ static int load_pd_dir(struct i915_request *rq,
return rq->engine->emit_flush(rq, EMIT_FLUSH);
 }
 
-static inline int mi_set_context(struct i915_request *rq, u32 flags)
+static inline int mi_set_context(struct i915_request *rq,
+struct intel_context *ce,
+u32 flags)
 {
struct drm_i915_private *i915 = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -1459,7 +1461,7 @@ static inline int mi_set_context(struct i915_request *rq, 
u32 flags)
 
*cs++ = MI_NOOP;
*cs++ = MI_SET_CONTEXT;
-   *cs++ = i915_ggtt_offset(rq->context->state) | flags;
+   *cs++ = i915_ggtt_offset(ce->state) | flags;
/*
 * w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
 * WaMiSetContext_Hang:snb,ivb,vlv
@@ -1574,13 +1576,56 @@ static int switch_mm(struct i915_request *rq, struct 
i915_address_space *vm)
return rq->engine->emit_flush(rq, EMIT_INVALIDATE);
 }
 
+static int clear_residuals(struct i915_request *rq)
+{
+   struct intel_engine_cs *engine = rq->engine;
+   int ret;
+
+   GEM_BUG_ON(!engine->kernel_context->state);
+
+   ret = switch_mm(rq, vm_alias(engine->kernel_context));
+   if (ret)
+   return ret;
+
+   ret = mi_set_context(rq,
+engine->kernel_context,
+MI_MM_SPACE_GTT | MI_RESTORE_INHIBIT);
+   if (ret)
+   return ret;
+
+   ret = engine->emit_bb_start(rq,
+   engine->wa_ctx.vma->node.start, 0,
+   0);
+   if (ret)
+   return ret;
+
+   ret = engine->emit_flush(rq, EMIT_FLUSH);
+   if (ret)
+   return ret;
+
+   /* Always invalidate before the next switch_mm() */
+   return engine->emit_flush(rq, EMIT_INVALIDATE);
+}
+
 static int switch_context(struct i915_request *rq)
 {
+   struct intel_engine_cs *engine = rq->engine;
struct intel_context *ce = rq->context;
+   void **residuals = NULL;
int ret;
 
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
 
+   if (engine->wa_ctx.vma && ce != engine->kernel_context) {
+   if (engine->wa_ctx.vma->private != ce) {
+   ret = clear_residuals(rq);
+   if (ret)
+   return ret;
+
+   residuals = >wa_ctx.vma->private;
+   }
+   }
+
ret = switch_mm(rq, vm_alias(ce));
if (ret)
return ret;
@@ -1600,7 +1645,7 @@ static int switch_context(struct i915_request *rq)
else
flags |= MI_RESTORE_INHIBIT;
 
-   ret = mi_set_context(rq, flags);
+   ret = mi_set_context(rq, ce, flags);
if (ret)
return ret;
}
@@ -1609,6 +1654,20 @@ static int switch_context(struct 

[RFC PATCH v3 0/2] Security mitigation for Intel Gen7 HWs

2020-01-16 Thread Akeem G Abodunrin
 NOTE: 
This series is in active development and is not intended to be merged to
mainline in its current form. The intent of the RFC is simply to outline
the strategy for the mitigation, as a focus for active discussion, and
to openly share progress. There has been only minimal attention paid to
performance thus far, as the focus is on robustness. It is not
anticipated that there will be any measurable performance impact in the
final version.
 END NOTE  

Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615

Summary of Vulnerability

Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via local access

Products affected:
--
Intel CPU’s with Gen7, Gen7.5 and Gen9 Graphics.

Mitigation Summary
--
This patch provides mitigation for Gen7 and Gen7.5 hardware only.
Patch for Gen9 devices have been provided and merged to Linux mainline,
and backported to stable kernels.
Note that Gen8 is not impacted due to a previously implemented
workaround.

The mitigation involves submitting a custom EU kernel prior to every
context restore, in order to forcibly clear down residual EU and URB
resources.

This is currently an RFC while more analysis is performed on the
performance implications.

Note on Address Space Isolation (Full PPGTT)


Isolation of EU kernel assets should be considered complementary to the
existing support for address space isolation (aka Full PPGTT), since
without address space isolation there is minimal value in preventing
leakage between EU contexts. Full PPGTT has long been supported on Gen
Gfx devices since Gen8, and protection against EU residual leakage is a
welcome addition for these newer platforms.

By contrast, Gen7 and Gen7.5 device introduced Full PPGTT support only
as a hardware development feature for anticipated Gen8 productization.
Support was never intended for, or provided to the Linux kernels for
these platforms. Recent work (still ongoing) to the mainline kernel is
retroactively providing this support, but due to the level of complexity
it is not practical to attempt to backport this to earlier stable
kernels. Since without Full PPGTT, EU residuals protection has
questionable benefit, *there are no plans to provide stable kernel
backports for this patch series.*

Mika Kuoppala (1):
  drm/i915: Add mechanism to submit a context WA on ring submission

Prathap Kumar Valsan (1):
  drm/i915/gen7: Clear all EU/L3 residual contexts

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c| 524 ++
 drivers/gpu/drm/i915/gt/gen7_renderclear.h|  15 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   | 133 -
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 6 files changed, 689 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h

-- 
2.20.1

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


[RFC PATCH v3 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

2020-01-16 Thread Akeem G Abodunrin
From: Prathap Kumar Valsan 

 NOTE: 
This series is in active development and is not intended to be merged to
mainline in its current form. The intent of the RFC is simply to outline
the strategy for the mitigation, as a focus for active discussion, and
to openly share progress. There has been only minimal attention paid to
performance thus far, as the focus is on robustness. It is not
anticipated that there will be any measurable performance impact in the
final version.
 END NOTE 

On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each context switching.

v2: Addressed comments about unused code, code formatting, and include
additional debug code as suggested by Chris Wilson.
v3: Expand debug code for every batch_alloc_items() call...
Current patch series shows significant performance improvements, on par
with current drm-tips.

Signed-off-by: Mika Kuoppala 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Akeem G Abodunrin 
Cc: Chris Wilson 
Cc: Balestrieri Francesco 
Cc: Bloomfield Jon 
Cc: Dutt Sudeep 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gt/gen7_renderclear.c| 524 ++
 drivers/gpu/drm/i915/gt/gen7_renderclear.h|  15 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   3 +-
 drivers/gpu/drm/i915/i915_utils.h |   5 +
 6 files changed, 561 insertions(+), 4 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
 create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 3c88d7d8c764..f96bae664a03 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -78,6 +78,7 @@ gt-y += \
gt/debugfs_gt.o \
gt/debugfs_gt_pm.o \
gt/gen6_ppgtt.o \
+   gt/gen7_renderclear.o \
gt/gen8_ppgtt.o \
gt/intel_breadcrumbs.o \
gt/intel_context.o \
diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
new file mode 100644
index ..5425c2149b30
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
@@ -0,0 +1,524 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include "gen7_renderclear.h"
+#include "i915_drv.h"
+#include "i915_utils.h"
+#include "intel_gpu_commands.h"
+
+#define MAX_URB_ENTRIES 64
+#define STATE_SIZE (4 * 1024)
+#define GT3_INLINE_DATA_DELAYS 0x1E00
+#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))
+
+/* Media CB Kernel for gen7 devices */
+static const u32 cb7_kernel[][4] = {
+   { 0x0001, 0x26020128, 0x0024, 0x },
+   { 0x0040, 0x20280c21, 0x0028, 0x0001 },
+   { 0x0110, 0x2c20, 0x002c, 0x },
+   { 0x00010220, 0x34001c00, 0x1400, 0x002c },
+   { 0x0061, 0x20600061, 0x, 0x },
+   { 0x0008, 0x20601c85, 0x0e00, 0x000c },
+   { 0x0005, 0x20601ca5, 0x0060, 0x0001 },
+   { 0x0008, 0x20641c85, 0x0e00, 0x000d },
+   { 0x0005, 0x20641ca5, 0x0064, 0x0003 },
+   { 0x0041, 0x207424a5, 0x0064, 0x0034 },
+   { 0x0040, 0x206014a5, 0x0060, 0x0074 },
+   { 0x0008, 0x20681c85, 0x0e00, 0x0008 },
+   { 0x0005, 0x20681ca5, 0x0068, 0x000f },
+   { 0x0041, 0x20701ca5, 0x0060, 0x0010 },
+   { 0x0040, 0x206814a5, 0x0068, 0x0070 },
+   { 0x0061, 0x20a00061, 0x, 0x },
+   { 0x0005, 0x206c1c85, 0x0e00, 0x0007 },
+   { 0x0041, 0x206c1ca5, 0x006c, 0x0004 },
+   { 0x0061, 0x20800021, 0x008d, 0x },
+   { 0x0001, 0x20800021, 0x006c, 0x },
+   { 0x0001, 0x20840021, 0x0068, 0x },
+   { 0x0001, 0x20880061, 0x, 0x0003 },
+   { 0x0005, 0x208c0d21, 0x0086, 0x },
+   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x02190001 },
+   { 0x0040, 0x20a01ca5, 0x00a0, 0x0001 },
+   { 0x05600032, 0x20a01fa1, 0x008d0080, 0x040a8001 },
+   { 0x0240, 0x20281c21, 0x0028, 0x },
+   { 0x00010220, 0x34001c00, 0x1400, 0xfffc },
+   { 0x0001, 0x26020128, 0x0024, 0x },
+   { 0x0001, 0x22e4, 0x, 0x },
+   { 0x0001, 0x220801ec, 0x, 0x007f007f },
+   { 0x0061, 0x20400021, 0x008d, 0x },
+   { 0x0061, 0x2fe00021, 0x008d, 0x },
+   { 0x0021, 0x20400121, 0x00450020, 0x },
+   { 0x0001, 0x20480061, 0x, 0x000f000f },
+   { 0x0005, 

Re: [PATCH v2 4/4] drm/simple-kms: Let DRM core send VBLANK events by default

2020-01-16 Thread Daniel Vetter
On Thu, Jan 16, 2020 at 05:22:34PM +, Emil Velikov wrote:
> Hi all,
> 
> On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann  wrote:
> 
> > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > index 7cf3cf936547..23d2f51fc1d4 100644
> > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > @@ -149,6 +149,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> > > drm_crtc *crtc,
> > >   /* Self refresh should be canceled when a new update is available */
> > >   state->active = drm_atomic_crtc_effectively_active(state);
> > >   state->self_refresh_active = false;
> > > +
> > > + if (drm_dev_has_vblank(crtc->dev))
> > > + state->no_vblank = true;
> > > + else
> > > + state->no_vblank = false;
> > >  }
> > >  EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
> >
> > I think the if/else branches are in the wrong order.

Yeah fumbled that.

> > But generally speaking, is it really that easy? The xen driver already
> > has to work around simple-kms's auto-enabling of no_vblank (see patch
> > 4). Maybe this settings interferes with other drivers as well. At least
> > the calls for sending fake vblanks should be removed from all affected
> > drivers.

Hm xen is really special, in that it has a flip complete event, but not a
vblank. I think forcing drivers to overwrite stuff in that case makes
sense.

> I'm not sure if setting no_vblank based on dev->num_crtcs is the correct 
> thing.
> From the original commit and associated description for no_vblank:
> 
> In some cases CRTCs are active but are not able to generating events, at
> least not at every frame at it's expected to.
> This is typically the case when the CRTC is feeding a writeback connector...

Yeah, but Thomas' series here wants to extend that. And I think if we roll
this out the common case will be "no hw vblank", and the writeback special
case is going to be the exception to the exception. Yup, patch 1 that
updates the docs doesn't reflect that, which is why I'm bringing up more
suggestions here around code & semantics of all these pieces to make them
do the most reasonable thing for most of the drivers.

> Reflects the ability of a CRTC to send VBLANK events
> 
> 
> The proposed handling of no_vblank feels a little dirty, although
> nothing better comes to mind.
> Nevertheless code seems perfectly reasonable, so if it were me I'd merge it.

The idea with setting it very early is that drivers can overwrite it very
easily. Feels slightly dirty, so I guess we could also set it somewhere in
the atomic_helper_check function (similar to how we set the various
crtc->*_changed flags, but we're not entirely consistent on these either).

For the overall thing what feels irky to me is making this no_vblank
default logic (however we end up computing it in the end, whether like
this or what I suggested) specific to simple pipe helpers feels kinda
wrong. Simple pipe tends to have a higher ratio of drivers for hw without
vblank support, but by far not the only ones. Having that special case
feels confusing to me (and likely will trip up some people, vblank and
event handling is already a huge source of confusion in drm).

One idea behind drm_dev_has_vblank() is also that we could formalize a bit
all that, at least for the usual case - xen and maybe others being some
exceptions as usual (hence definitely not something the core code should
handle).

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


[PATCH v2] drm/msm: Add syncobj support.

2020-01-16 Thread Bas Nieuwenhuizen
This

1) Enables core DRM syncobj support.
2) Adds options to the submission ioctl to wait/signal syncobjs.

Just like the wait fence fd, this does inline waits. Using the
scheduler would be nice but I believe it is out of scope for
this work.

Support for timeline syncobjs is implemented and the interface
is ready for it, but I'm not enabling it yet until there is
some code for turnip to use it.

The reset is mostly in there because in the presence of waiting
and signalling the same semaphores, resetting them after
signalling can become very annoying.

v2:
  - Fixed style issues
  - Removed a cleanup issue in a failure case
  - Moved to a copy_from_user per syncobj

Signed-off-by: Bas Nieuwenhuizen 
---
 drivers/gpu/drm/msm/msm_drv.c|   6 +-
 drivers/gpu/drm/msm/msm_gem_submit.c | 236 ++-
 include/uapi/drm/msm_drm.h   |  24 ++-
 3 files changed, 262 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c84f0a8b3f2c..5246b41798df 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -37,9 +37,10 @@
  * - 1.4.0 - softpin, MSM_RELOC_BO_DUMP, and GEM_INFO support to set/get
  *   GEM object's debug name
  * - 1.5.0 - Add SUBMITQUERY_QUERY ioctl
+ * - 1.6.0 - Syncobj support
  */
 #define MSM_VERSION_MAJOR  1
-#define MSM_VERSION_MINOR  5
+#define MSM_VERSION_MINOR  6
 #define MSM_VERSION_PATCHLEVEL 0
 
 static const struct drm_mode_config_funcs mode_config_funcs = {
@@ -988,7 +989,8 @@ static struct drm_driver msm_driver = {
.driver_features= DRIVER_GEM |
DRIVER_RENDER |
DRIVER_ATOMIC |
-   DRIVER_MODESET,
+   DRIVER_MODESET |
+   DRIVER_SYNCOBJ,
.open   = msm_open,
.postclose   = msm_postclose,
.lastclose  = drm_fb_helper_lastclose,
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index be5327af16fa..6c7f95fc5cfd 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -8,7 +8,9 @@
 #include 
 #include 
 
+#include 
 #include 
+#include 
 
 #include "msm_drv.h"
 #include "msm_gpu.h"
@@ -394,6 +396,191 @@ static void submit_cleanup(struct msm_gem_submit *submit)
ww_acquire_fini(>ticket);
 }
 
+
+struct msm_submit_post_dep {
+   struct drm_syncobj *syncobj;
+   uint64_t point;
+   struct dma_fence_chain *chain;
+};
+
+static int msm_wait_deps(struct drm_device *dev,
+ struct drm_file *file,
+ uint64_t in_syncobjs_addr,
+ uint32_t nr_in_syncobjs,
+ uint32_t syncobj_stride,
+ struct msm_ringbuffer *ring,
+ struct drm_syncobj ***syncobjs)
+{
+   struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
+   int ret = 0;
+   uint32_t i, j;
+
+   *syncobjs = kcalloc(nr_in_syncobjs, sizeof(**syncobjs),
+   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
+   if (!syncobjs) {
+   ret = -ENOMEM;
+   goto out_syncobjs;
+   }
+
+   for (i = 0; i < nr_in_syncobjs; ++i) {
+   uint64_t address = in_syncobjs_addr + i * syncobj_stride;
+   struct dma_fence *fence;
+
+   if (copy_from_user(_desc,
+  u64_to_user_ptr(address),
+  min(syncobj_stride, sizeof(syncobj_desc {
+   ret = -EFAULT;
+   goto out_syncobjs;
+   }
+
+   if (syncobj_desc.point &&
+   !drm_core_check_feature(dev, DRIVER_SYNCOBJ_TIMELINE)) {
+   ret = -EOPNOTSUPP;
+   break;
+   }
+
+   if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS) {
+   ret = -EINVAL;
+   break;
+   }
+
+   ret = drm_syncobj_find_fence(file, syncobj_desc.handle,
+syncobj_desc.point, 0, );
+   if (ret)
+   break;
+
+   if (!dma_fence_match_context(fence, ring->fctx->context))
+   ret = dma_fence_wait(fence, true);
+
+   dma_fence_put(fence);
+   if (ret)
+   break;
+
+   if (syncobj_desc.flags & MSM_SUBMIT_SYNCOBJ_RESET) {
+   (*syncobjs)[i] =
+   drm_syncobj_find(file, syncobj_desc.handle);
+   if (!(*syncobjs)[i]) {
+   ret = -EINVAL;
+   break;
+   }
+   }
+   }
+
+out_syncobjs:
+   if (ret && 

[PATCH v7 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

2020-01-16 Thread Jyri Sarha
This patch adds a new DRM driver for Texas Instruments DSS IPs used on
Texas Instruments Keystone K2G, AM65x, and J721e SoCs. The new DSS IP is
a major change to the older DSS IP versions, which are supported by
the omapdrm driver. While on higher level the Keystone DSS resembles
the older DSS versions, the registers are completely different and the
internal pipelines differ a lot.

DSS IP found on K2G is an "ultra-light" version, and has only a single
plane and a single output. The K3 DSS IPs are found on AM65x and J721E
SoCs. AM65x DSS has two video ports, one full video plane, and another
"lite" plane without scaling support. J721E has 4 video ports, 2 video
planes and 2 lite planes. AM65x DSS has also an integrated OLDI (LVDS)
output.

Version history:

v2: - rebased on top of drm-next-2019-11-27
- sort all include lines in all files
- remove all include 
- remove select "select VIDEOMODE_HELPERS"
- call dispc_vp_setup() later in tidss_crtc_atomic_flush() (there is no
  to call it in new modeset case as it is also called in vp_enable())
- change probe sequence and drm_device allocation (follow example in
  drm_drv.c)
- use __maybe_unused instead of #ifdef for pm functions
- remove "struct drm_fbdev_cma *fbdev;" from driver data
- check panel connector type before connecting it

v3: no change

v4: no change

v5: - remove fifo underflow irq handling, it is not an error and
  it should be used for debug purposes only
- memory tuning, prefetch plane fifo up to high-threshold value to
  minimize possibility of underflows.

v6: - Check CTM and gamma support from dispc_features when creating crtc
- Implement CTM support for k2g and fix k3 CTM implementation
- Remove gamma property persistence and always write color properties
  in a new modeset

v7: - Fix checkpatch.pl --strict issues
- Rebase on top of drm-misc-next-2020-01-10

Co-developed-by: Tomi Valkeinen 
Signed-off-by: Jyri Sarha 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/tidss/Kconfig |   14 +
 drivers/gpu/drm/tidss/Makefile|   12 +
 drivers/gpu/drm/tidss/tidss_crtc.c|  377 +++
 drivers/gpu/drm/tidss/tidss_crtc.h|   46 +
 drivers/gpu/drm/tidss/tidss_dispc.c   | 2774 +
 drivers/gpu/drm/tidss/tidss_dispc.h   |  132 +
 drivers/gpu/drm/tidss/tidss_dispc_regs.h  |  243 ++
 drivers/gpu/drm/tidss/tidss_drv.c |  285 +++
 drivers/gpu/drm/tidss/tidss_drv.h |   39 +
 drivers/gpu/drm/tidss/tidss_encoder.c |   88 +
 drivers/gpu/drm/tidss/tidss_encoder.h |   17 +
 drivers/gpu/drm/tidss/tidss_irq.c |  146 ++
 drivers/gpu/drm/tidss/tidss_irq.h |   77 +
 drivers/gpu/drm/tidss/tidss_kms.c |  249 ++
 drivers/gpu/drm/tidss/tidss_kms.h |   15 +
 drivers/gpu/drm/tidss/tidss_plane.c   |  217 ++
 drivers/gpu/drm/tidss/tidss_plane.h   |   25 +
 drivers/gpu/drm/tidss/tidss_scale_coefs.c |  202 ++
 drivers/gpu/drm/tidss/tidss_scale_coefs.h |   22 +
 21 files changed, 4983 insertions(+)
 create mode 100644 drivers/gpu/drm/tidss/Kconfig
 create mode 100644 drivers/gpu/drm/tidss/Makefile
 create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_crtc.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_dispc_regs.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_drv.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_drv.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_encoder.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_irq.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_irq.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_kms.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_kms.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_plane.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_plane.h
 create mode 100644 drivers/gpu/drm/tidss/tidss_scale_coefs.c
 create mode 100644 drivers/gpu/drm/tidss/tidss_scale_coefs.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d0aa6cff2e02..4bffa08f610a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -389,6 +389,8 @@ source "drivers/gpu/drm/aspeed/Kconfig"
 
 source "drivers/gpu/drm/mcde/Kconfig"
 
+source "drivers/gpu/drm/tidss/Kconfig"
+
 # Keep legacy drivers last
 
 menuconfig DRM_LEGACY
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6493088a0fdd..ca0ca775d37f 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -122,3 +122,4 @@ obj-$(CONFIG_DRM_LIMA)  += lima/
 obj-$(CONFIG_DRM_PANFROST) += panfrost/
 obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/
 obj-$(CONFIG_DRM_MCDE) += mcde/
+obj-$(CONFIG_DRM_TIDSS) += tidss/
diff --git 

[PATCH v3 5/5] drm/i915: Auto detect DPCD backlight support by default

2020-01-16 Thread Lyude Paul
Turns out we actually already have some companies, such as Lenovo,
shipping machines with AMOLED screens that don't allow controlling the
backlight through the usual PWM interface and only allow controlling it
through the standard EDP DPCD interface. One example of one of these
laptops is the X1 Extreme 2nd Generation.

Since we've got systems that need this turned on by default now to have
backlight controls working out of the box, let's start auto-detecting it
for systems by default based on what the VBT tells us. We do this by
changing the default value for the enable_dpcd_backlight module param
from 0 to -1.

Tested-by: AceLan Kao 
Tested-by: Perry Yuan 
Signed-off-by: Lyude Paul 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/i915_params.c | 2 +-
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 64009e99073d..905decc36e53 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -172,7 +172,7 @@ i915_param_named_unsafe(inject_probe_failure, uint, 0400,
 
 i915_param_named(enable_dpcd_backlight, int, 0600,
"Enable support for DPCD backlight control"
-   "(-1=use per-VBT LFP backlight type setting, 0=disabled [default], 
1=enabled)");
+   "(-1=use per-VBT LFP backlight type setting [default], 0=disabled, 
1=enabled)");
 
 #if IS_ENABLED(CONFIG_DRM_I915_GVT)
 i915_param_named(enable_gvt, bool, 0400,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index be6089e4f9e6..947d0a38fa3c 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@ struct drm_printer;
param(int, reset, 3, 0600) \
param(unsigned int, inject_probe_failure, 0, 0600) \
param(int, fastboot, -1, 0600) \
-   param(int, enable_dpcd_backlight, 0, 0600) \
+   param(int, enable_dpcd_backlight, -1, 0600) \
param(char *, force_probe, CONFIG_DRM_I915_FORCE_PROBE, 0400) \
param(unsigned long, fake_lmem_start, 0, 0400) \
/* leave bools at the end to not create holes */ \
-- 
2.24.1

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


[PATCH v3 3/5] drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()

2020-01-16 Thread Lyude Paul
For eDP panels, it appears it's expected that so long as the panel is in
DPCD control mode that the brightness value is never set to 0. Instead,
if the desired effect is to set the panel's backlight to 0 we're
expected to simply turn off the backlight through the
DP_EDP_DISPLAY_CONTROL_REGISTER.

We already do the latter correctly in intel_dp_aux_disable_backlight().
But, we make the mistake of writing the DPCD registers in the wrong
order when enabling the backlight in intel_dp_aux_enable_backlight()
since we currently enable the backlight through
DP_EDP_DISPLAY_CONTROL_REGISTER before writing the brightness level. On
the X1 Extreme 2nd Generation, this appears to have the potential of
confusing the panel in such a way that further attempts to set the
brightness don't actually change the backlight as expected and leave it
off. Presumably, this happens because the incorrect register writing
order briefly leaves the panel with DPCD mode enabled and a 0 brightness
level set.

So, reverse the order we write the DPCD registers when enabling the
panel backlight so that we write the brightness value first, and enable
the backlight second. This fix appears to be the final bit needed to get
the backlight on the ThinkPad X1 Extreme 2nd Generation's AMOLED screen
working.

Tested-by: AceLan Kao 
Tested-by: Perry Yuan 
Signed-off-by: Lyude Paul 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 5d4db5f8a165..77a759361c5c 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -207,8 +207,9 @@ static void intel_dp_aux_enable_backlight(const struct 
intel_crtc_state *crtc_st
}
}
 
+   intel_dp_aux_set_backlight(conn_state,
+  connector->panel.backlight.level);
set_aux_backlight_enable(intel_dp, true);
-   intel_dp_aux_set_backlight(conn_state, 
connector->panel.backlight.level);
 }
 
 static void intel_dp_aux_disable_backlight(const struct drm_connector_state 
*old_conn_state)
-- 
2.24.1

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


[PATCH v3 4/5] drm/i915: Don't use VBT for detecting DPCD backlight controls

2020-01-16 Thread Lyude Paul
Despite the fact that the VBT appears to have a field for specifying
that a system is equipped with a panel that supports standard VESA
backlight controls over the DP AUX channel, so far every system we've
spotted DPCD backlight control support on doesn't actually set this
field correctly and all have it set to INTEL_BACKLIGHT_DISPLAY_DDI.

While we don't know the exact reason for this VBT misuse, talking with
some vendors indicated that there's a good number of laptop panels out
there that supposedly support both PWM backlight controls and DPCD
backlight controls as a workaround until Intel supports DPCD backlight
controls across platforms universally. This being said, the X1 Extreme
2nd Gen that I have here (note that Lenovo is not the hardware vendor
that informed us of this) PWM backlight controls are advertised, but
only DPCD controls actually function. I'm going to make an educated
guess here and say that on systems like this one, it's likely that PWM
backlight controls might have been intended to work but were never
really tested by QA.

Since we really need backlights to work without any extra module
parameters, let's take the risk here and rely on the standard DPCD caps
to tell us whether AUX backlight controls are supported or not. We still
check the VBT, but only to make sure that we don't enable DPCD backlight
controls on a panel that uses something other then the standard VESA
interfaces over AUX. Since panels using such non-standard interfaces
should probably have support added to i915, we'll print a warning when
seeing this in the VBT. We can remove this warning later if we end up
adding support for any custom backlight interfaces.

Signed-off-by: Lyude Paul 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112376
Cc: Jani Nikula 
Cc: Perry Yuan 
Cc: AceLan Kao 
---
 .../drm/i915/display/intel_dp_aux_backlight.c| 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 77a759361c5c..3002b600635f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -330,13 +330,17 @@ int intel_dp_aux_init_backlight_funcs(struct 
intel_connector *intel_connector)
struct intel_panel *panel = _connector->panel;
struct drm_i915_private *dev_priv = to_i915(intel_connector->base.dev);
 
-   if (i915_modparams.enable_dpcd_backlight == 0 ||
-   (i915_modparams.enable_dpcd_backlight == -1 &&
-   dev_priv->vbt.backlight.type != 
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE))
-   return -ENODEV;
-
-   if (!intel_dp_aux_display_control_capable(intel_connector))
+   if (i915_modparams.enable_dpcd_backlight == 0)
return -ENODEV;
+   if (i915_modparams.enable_dpcd_backlight == -1) {
+   if (dev_priv->vbt.backlight.type
+   == INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE) {
+   DRM_WARN("VBT says panel uses custom panel driver 
interface, not using DPCD backlight controls\n");
+   return -ENODEV;
+   }
+   if (!intel_dp_aux_display_control_capable(intel_connector))
+   return -ENODEV;
+   }
 
panel->backlight.setup = intel_dp_aux_setup_backlight;
panel->backlight.enable = intel_dp_aux_enable_backlight;
-- 
2.24.1

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


[PATCH v3 0/5] drm/i915: eDP DPCD aux backlight fixes

2020-01-16 Thread Lyude Paul
I recently got a ThinkPad X1 Extreme 2nd Generation for fixing some
issues on, and noticed that out of the box the backlight doesn't work.
Along the way of fixing that, I found a few issues with how i915 handles
DPCD AUX backlight control and fixed them. Now I've got working
backlight controls, hooray!

Note that this patch series enables DPCD backlight controls by default.
This time however, we ignore the backlight type advertised in the VBT
(unless it's a custom backlight interface that doesn't use the standard
VESA interface over AUX) and just trust the DPCD.

Lyude Paul (5):
  drm/i915: Fix eDP DPCD aux max backlight calculations
  drm/i915: Assume 100% brightness when not in DPCD control mode
  drm/i915: Fix DPCD register order in intel_dp_aux_enable_backlight()
  drm/i915: Don't use VBT for detecting DPCD backlight controls
  drm/i915: Auto detect DPCD backlight support by default

 .../drm/i915/display/intel_display_types.h|   3 +
 .../drm/i915/display/intel_dp_aux_backlight.c | 175 --
 drivers/gpu/drm/i915/i915_params.c|   2 +-
 drivers/gpu/drm/i915/i915_params.h|   2 +-
 4 files changed, 126 insertions(+), 56 deletions(-)

-- 
2.24.1

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


[PATCH v3 1/5] drm/i915: Fix eDP DPCD aux max backlight calculations

2020-01-16 Thread Lyude Paul
Max backlight value for the panel was being calculated using byte
count i.e. 0x if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel uses 2 byte setting, it might not use
all the control bits. Thus, max backlight should be set based on the
value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255.

Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT
frequency which results in a different max backlight value. Thus,
setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of
enable so that max backlight can be calculated correctly. Only the
frequency divider is set during the enable phase using the value of
EDP_PWMGEN_BIT_COUNT.

This is based off the original patch series from Furquan Shaikh
:

https://patchwork.freedesktop.org/patch/317255/?series=62326=3

Changes since original patch:
* Remove unused intel_dp variable in intel_dp_aux_setup_backlight()
* Fix checkpatch issues
* Make sure that we rewrite the pwmgen bit count whenever we bring the
  panel out of D3 mode

v2 by Jani:
* rebase
* fix readb return value check

Cc: Furquan Shaikh 
Tested-by: AceLan Kao 
Tested-by: Perry Yuan 
Signed-off-by: Lyude Paul 
Signed-off-by: Jani Nikula 
---
 .../drm/i915/display/intel_display_types.h|   3 +
 .../drm/i915/display/intel_dp_aux_backlight.c | 139 --
 2 files changed, 95 insertions(+), 47 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index fdd943a17de3..155ce49ae764 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -214,6 +214,9 @@ struct intel_panel {
u8 controller;  /* bxt+ only */
struct pwm_device *pwm;
 
+   /* DPCD backlight */
+   u8 pwmgen_bit_count;
+
struct backlight_device *device;
 
/* Connector and platform specific backlight functions */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 7c653f8c307f..345eed641455 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -111,61 +111,28 @@ static bool intel_dp_aux_set_pwm_freq(struct 
intel_connector *connector)
 {
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
-   int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
-   u8 pn, pn_min, pn_max;
+   const u8 pn = connector->panel.backlight.pwmgen_bit_count;
+   int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
 
-   /* Find desired value of (F x P)
-* Note that, if F x P is out of supported range, the maximum value or
-* minimum value will applied automatically. So no need to check that.
-*/
freq = dev_priv->vbt.backlight.pwm_freq_hz;
-   DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
if (!freq) {
DRM_DEBUG_KMS("Use panel default backlight frequency\n");
return false;
}
 
fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
+   f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
+   fxp_actual = f << pn;
 
-   /* Use highest possible value of Pn for more granularity of brightness
-* adjustment while satifying the conditions below.
-* - Pn is in the range of Pn_min and Pn_max
-* - F is in the range of 1 and 255
-* - FxP is within 25% of desired value.
-*   Note: 25% is arbitrary value and may need some tweak.
-*/
-   if (drm_dp_dpcd_readb(_dp->aux,
-  DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
-   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
-   return false;
-   }
-   if (drm_dp_dpcd_readb(_dp->aux,
-  DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
-   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
-   return false;
-   }
-   pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
-   pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
-
+   /* Ensure frequency is within 25% of desired value */
fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
-   if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
-   DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
-   return false;
-   }
 
-   for (pn = pn_max; pn >= pn_min; pn--) {
-   f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
-   fxp_actual = f << pn;
-   if (fxp_min 

[PATCH v3 2/5] drm/i915: Assume 100% brightness when not in DPCD control mode

2020-01-16 Thread Lyude Paul
Currently we always determine the initial panel brightness level by
simply reading the value from DP_EDP_BACKLIGHT_BRIGHTNESS_MSB/LSB. This
seems wrong though, because if the panel is not currently in DPCD
control mode there's not really any reason why there would be any
brightness value programmed in the first place.

This appears to be the case on the Lenovo ThinkPad X1 Extreme 2nd
Generation, where the default value in these registers is always 0 on
boot despite the fact the panel runs at max brightness by default.
Getting the initial brightness value correct here is important as well,
since the panel on this laptop doesn't behave well if it's ever put into
DPCD control mode while the brightness level is programmed to 0.

So, let's fix this by checking what the current backlight control mode
is before reading the brightness level. If it's in DPCD control mode, we
return the programmed brightness level. Otherwise we assume 100%
brightness and return the highest possible brightness level. This also
prevents us from accidentally programming a brightness level of 0.

This is one of the many fixes that gets backlight controls working on
the ThinkPad X1 Extreme 2nd Generation with optional 4K AMOLED screen.

Changes since v1:
* s/DP_EDP_DISPLAY_CONTROL_REGISTER/DP_EDP_BACKLIGHT_MODE_SET_REGISTER/
  - Jani

Tested-by: AceLan Kao 
Tested-by: Perry Yuan 
Signed-off-by: Lyude Paul 
Signed-off-by: Jani Nikula 
---
 .../drm/i915/display/intel_dp_aux_backlight.c   | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 345eed641455..5d4db5f8a165 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -59,8 +59,25 @@ static u32 intel_dp_aux_get_backlight(struct intel_connector 
*connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(connector->encoder);
u8 read_val[2] = { 0x0 };
+   u8 mode_reg;
u16 level = 0;
 
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
+ _reg) != 1) {
+   DRM_DEBUG_KMS("Failed to read the DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+   return 0;
+   }
+
+   /*
+* If we're not in DPCD control mode yet, the programmed brightness
+* value is meaningless and we should assume max brightness
+*/
+   if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
+   DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
+   return connector->panel.backlight.max;
+
if (drm_dp_dpcd_read(_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
 _val, sizeof(read_val)) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
-- 
2.24.1

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


[PATCH v7 3/5] dt-bindings: display: ti, j721e-dss: Add dt-schema yaml binding

2020-01-16 Thread Jyri Sarha
Add dt-schema yaml bindig for J721E DSS, J721E version TI Keystone
Display SubSystem.

Version history:

v2: no change

v3: - reg-names: "wp" -> "wb"
- Add ports node
- Add includes to dts example
- reindent dts example

v4: - Add descriptions to reg, clocks, and interrups properties
- Remove minItems when its value is the same as maxItems value

v5: - itemize reg, clocks and interrupts properties' descriptions
- there is no "vp" reg-name, only "wb" for write back

v6: - Add Reviewed-by: from Rob Herring  and
  Benoit Parrot 

v7: no change

Signed-off-by: Jyri Sarha 
Reviewed-by: Rob Herring 
Reviewed-by: Benoit Parrot 
---
 .../bindings/display/ti/ti,j721e-dss.yaml | 208 ++
 1 file changed, 208 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml

diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
new file mode 100644
index ..ade9b2f513f5
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
@@ -0,0 +1,208 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/ti/ti,j721e-dss.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Texas Instruments J721E Display Subsystem
+
+maintainers:
+  - Jyri Sarha 
+  - Tomi Valkeinen 
+
+description: |
+  The J721E TI Keystone Display SubSystem with four output ports and
+  four video planes. There is two full video planes and two "lite
+  planes" without scaling support. The video ports can be connected to
+  the SoC's DPI pins or to integrated display bridges on the SoC.
+
+properties:
+  compatible:
+const: ti,j721e-dss
+
+  reg:
+items:
+  - description: common_m DSS Master common
+  - description: common_s0 DSS Shared common 0
+  - description: common_s1 DSS Shared common 1
+  - description: common_s2 DSS Shared common 2
+  - description: VIDL1 light video plane 1
+  - description: VIDL2 light video plane 2
+  - description: VID1 video plane 1
+  - description: VID1 video plane 2
+  - description: OVR1 overlay manager for vp1
+  - description: OVR2 overlay manager for vp2
+  - description: OVR3 overlay manager for vp3
+  - description: OVR4 overlay manager for vp4
+  - description: VP1 video port 1
+  - description: VP2 video port 2
+  - description: VP3 video port 3
+  - description: VP4 video port 4
+  - description: WB Write Back
+
+  reg-names:
+items:
+  - const: common_m
+  - const: common_s0
+  - const: common_s1
+  - const: common_s2
+  - const: vidl1
+  - const: vidl2
+  - const: vid1
+  - const: vid2
+  - const: ovr1
+  - const: ovr2
+  - const: ovr3
+  - const: ovr4
+  - const: vp1
+  - const: vp2
+  - const: vp3
+  - const: vp4
+  - const: wb
+
+  clocks:
+items:
+  - description: fck DSS functional clock
+  - description: vp1 Video Port 1 pixel clock
+  - description: vp2 Video Port 2 pixel clock
+  - description: vp3 Video Port 3 pixel clock
+  - description: vp4 Video Port 4 pixel clock
+
+  clock-names:
+items:
+  - const: fck
+  - const: vp1
+  - const: vp2
+  - const: vp3
+  - const: vp4
+
+  interrupts:
+ items:
+  - description: common_m DSS Master common
+  - description: common_s0 DSS Shared common 0
+  - description: common_s1 DSS Shared common 1
+  - description: common_s2 DSS Shared common 2
+
+  interrupt-names:
+items:
+  - const: common_m
+  - const: common_s0
+  - const: common_s1
+  - const: common_s2
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  ports:
+type: object
+description:
+  Ports as described in Documentation/devictree/bindings/graph.txt
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description:
+  The output port node form video port 1
+
+  port@1:
+type: object
+description:
+  The output port node from video port 2
+
+  port@2:
+type: object
+description:
+  The output port node from video port 3
+
+  port@3:
+type: object
+description:
+  The output port node from video port 4
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+
+  max-memory-bandwidth:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Input memory (from main memory to dispc) bandwidth limit in
+  bytes per second
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - interrupts
+  - interrupt-names
+  - ports
+
+additionalProperties: false

[PATCH v7 1/5] dt-bindings: display: ti, k2g-dss: Add dt-schema yaml binding

2020-01-16 Thread Jyri Sarha
Add dt-schema yaml bindig for K2G DSS, an ultra-light version of TI
Keystone Display SubSystem.

Version history:

v2: no change

v3: - Add ports node
- Add includes to dts example
- reindent dts example

v4: - Add descriptions to reg and clocks properties
- Remove minItems when its value is the same as maxItems value
- Remove ports node

v5: - itemize reg and clocks properties' descriptions

v6: - Add Reviewed-by: from Rob Herring  and
  Benoit Parrot 

v7: no change

Signed-off-by: Jyri Sarha 
Reviewed-by: Rob Herring 
Reviewed-by: Benoit Parrot 
---
 .../bindings/display/ti/ti,k2g-dss.yaml   | 109 ++
 1 file changed, 109 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml

diff --git a/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
new file mode 100644
index ..532bb4794968
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/ti/ti,k2g-dss.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Texas Instruments K2G Display Subsystem
+
+maintainers:
+  - Jyri Sarha 
+  - Tomi Valkeinen 
+
+description: |
+  The K2G DSS is an ultra-light version of TI Keystone Display
+  SubSystem. It has only one output port and video plane. The
+  output is DPI.
+
+properties:
+  compatible:
+const: ti,k2g-dss
+
+  reg:
+items:
+  - description: cfg DSS top level
+  - description: common DISPC common
+  - description: VID1 video plane 1
+  - description: OVR1 overlay manager for vp1
+  - description: VP1 video port 1
+
+  reg-names:
+items:
+  - const: cfg
+  - const: common
+  - const: vid1
+  - const: ovr1
+  - const: vp1
+
+  clocks:
+items:
+  - description: fck DSS functional clock
+  - description: vp1 Video Port 1 pixel clock
+
+  clock-names:
+items:
+  - const: fck
+  - const: vp1
+
+  interrupts:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  port:
+type: object
+description:
+  Port as described in Documentation/devictree/bindings/graph.txt.
+  The DSS DPI output port node
+
+  max-memory-bandwidth:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Input memory (from main memory to dispc) bandwidth limit in
+  bytes per second
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - interrupts
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+dss: dss@0254 {
+compatible = "ti,k2g-dss";
+reg =   <0x0254 0x400>,
+<0x0255 0x1000>,
+<0x02557000 0x1000>,
+<0x0255a800 0x100>,
+<0x0255ac00 0x100>;
+reg-names = "cfg", "common", "vid1", "ovr1", "vp1";
+clocks =<_clks 0x2 0>,
+<_clks 0x2 1>;
+clock-names = "fck", "vp1";
+interrupts = ;
+
+power-domains = <_pds 0x2>;
+
+max-memory-bandwidth = <23000>;
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@0 {
+dpi_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCH v7 5/5] MAINTAINERS: add entry for tidss

2020-01-16 Thread Jyri Sarha
Add entry for tidss DRM driver.

Version history:

v2: no change

v3: - Move tidss entry after omapdrm
- Add "T: git git://anongit.freedesktop.org/drm/drm-misc"

v4: no change

v5: no change

v6: no change

v7: no change

Signed-off-by: Jyri Sarha 
---
 MAINTAINERS | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index aa9add598b7d..d8f65dc1dde8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5630,6 +5630,17 @@ S:   Maintained
 F: drivers/gpu/drm/omapdrm/
 F: Documentation/devicetree/bindings/display/ti/
 
+DRM DRIVERS FOR TI KEYSTONE
+M: Jyri Sarha 
+M: Tomi Valkeinen 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+F: drivers/gpu/drm/tidss/
+F: Documentation/devicetree/bindings/display/ti/ti,k2g-dss.yaml
+F: Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+F: Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
 DRM DRIVERS FOR V3D
 M: Eric Anholt 
 S: Supported
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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


[PATCH v7 2/5] dt-bindings: display: ti, am65x-dss: Add dt-schema yaml binding

2020-01-16 Thread Jyri Sarha
Add dt-schema yaml bindig for AM65x DSS, AM65x version TI Keystone
Display SubSystem.

Version history:

v2: no change

v3: - Add ports node
- use allOf in ti,am65x-oldi-io-ctrl to add both $ref and maxItems
- Add includes to dts example
- reindent dts example

v4: - Add descriptions to reg and clocks properties
- Remove minItems when its value is the same as maxItems value

v5: - itemize reg and clocks properties' descriptions

v6: - Add Reviewed-by: from Rob Herring  and
  Benoit Parrot 

v7: no change

Signed-off-by: Jyri Sarha 
Reviewed-by: Rob Herring 
Reviewed-by: Benoit Parrot 
---
 .../bindings/display/ti/ti,am65x-dss.yaml | 152 ++
 1 file changed, 152 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml

diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml 
b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
new file mode 100644
index ..cac61a998203
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -0,0 +1,152 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/ti/ti,am65x-dss.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Texas Instruments AM65x Display Subsystem
+
+maintainers:
+  - Jyri Sarha 
+  - Tomi Valkeinen 
+
+description: |
+  The AM65x TI Keystone Display SubSystem with two output ports and
+  two video planes. The first video port supports OLDI and the second
+  supports DPI format. The fist plane is full video plane with all
+  features and the second is a "lite plane" without scaling support.
+
+properties:
+  compatible:
+const: ti,am65x-dss
+
+  reg:
+description:
+  Addresses to each DSS memory region described in the SoC's TRM.
+items:
+  - description: common DSS register area
+  - description: VIDL1 light video plane
+  - description: VID video plane
+  - description: OVR1 overlay manager for vp1
+  - description: OVR2 overlay manager for vp2
+  - description: VP1 video port 1
+  - description: VP2 video port 2
+
+  reg-names:
+items:
+  - const: common
+  - const: vidl1
+  - const: vid
+  - const: ovr1
+  - const: ovr2
+  - const: vp1
+  - const: vp2
+
+  clocks:
+items:
+  - description: fck DSS functional clock
+  - description: vp1 Video Port 1 pixel clock
+  - description: vp2 Video Port 2 pixel clock
+
+  clock-names:
+items:
+  - const: fck
+  - const: vp1
+  - const: vp2
+
+  interrupts:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+description: phandle to the associated power domain
+
+  ports:
+type: object
+description:
+  Ports as described in Documentation/devictree/bindings/graph.txt
+properties:
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  port@0:
+type: object
+description:
+  The DSS OLDI output port node form video port 1
+
+  port@1:
+type: object
+description:
+  The DSS DPI output port node from video port 2
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+
+  ti,am65x-oldi-io-ctrl:
+allOf:
+  - $ref: "/schemas/types.yaml#/definitions/phandle-array"
+  - maxItems: 1
+description:
+  phandle to syscon device node mapping OLDI IO_CTRL registers.
+  The mapped range should point to OLDI_DAT0_IO_CTRL, map it and
+  following OLDI_DAT1_IO_CTRL, OLDI_DAT2_IO_CTRL, OLDI_DAT3_IO_CTRL,
+  and OLDI_CLK_IO_CTRL registers. This property is needed for OLDI
+  interface to work.
+
+  max-memory-bandwidth:
+$ref: /schemas/types.yaml#/definitions/uint32
+description:
+  Input memory (from main memory to dispc) bandwidth limit in
+  bytes per second
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - clock-names
+  - interrupts
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+dss: dss@04a0 {
+compatible = "ti,am65x-dss";
+reg =   <0x0 0x04a0 0x0 0x1000>, /* common */
+<0x0 0x04a02000 0x0 0x1000>, /* vidl1 */
+<0x0 0x04a06000 0x0 0x1000>, /* vid */
+<0x0 0x04a07000 0x0 0x1000>, /* ovr1 */
+<0x0 0x04a08000 0x0 0x1000>, /* ovr2 */
+<0x0 0x04a0a000 0x0 0x1000>, /* vp1 */
+<0x0 0x04a0b000 0x0 0x1000>; /* vp2 */
+reg-names = "common", "vidl1", "vid",
+"ovr1", "ovr2", "vp1", "vp2";
+ti,am65x-oldi-io-ctrl = <_oldi_io_ctrl>;
+power-domains = <_pds 67 TI_SCI_PD_EXCLUSIVE>;
+clocks =<_clks 67 1>,
+<_clks 216 1>,
+

[PATCH v7 0/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

2020-01-16 Thread Jyri Sarha
Changes since v6:
- Rebase on top of drm-misc-next-2020-01-10
- Fix all checkpatch.pl -q --emacs --strict --show-types issues
  - all issues but these have been fixed:
- over 80 char lines in scale coefficients found in tidss_scale_coefs.c
- Co-developed-by and Signed-off-by: name/email do not match
- added, moved or deleted file(s), does MAINTAINERS need updating
- Add Acked-by: Sam Ravnborg  to "drm/tidss: New driver ..."

Changes since v5:
- Add Add Reviewed-by: from Rob Herring  and
  Benoit Parrot  to binding patches
- Color property changes and fixes to the driver implementation patch
  - Check CTM and gamma support from dispc_features when creating crtc
  - Implement CTM support for k2g and fix k3 CTM implementation
  - Remove gamma property persistence and always write color properties
in a new modeset

Changes since v4:
- itemize named resource property descriptions in dt binding
- fix wp to wb in the ti,j721e-dss reg property description
- remove fifo underflow irq handling, it is not an error and
  it should be used for debug purposes only
- memory tuning, prefetch plane fifo up to high-threshold value to
  minimize possibility of underflows.

Changes since v3:
- Add descriptions some yaml binding properites
- Remove redundant minItems directives from yaml bindings
- Remove ports node from ti,k2g-dss yaml binding
- no change to MAINTAINERS or to the driver code

Changes since v2:
- Add version history to commit messages
- Fix yaml bindings now that got dt_binding_check dtbs_check working propery
- Move tidss entry in MAINTAINERS after omapdrm and add "T: git
  git://anongit.freedesktop.org/drm/drm-misc"
- no change to driver code

Changes since the first version of the patch series [2]:
- "drm/tidss: New driver for TI Keystone platform Display SubSystem"
 - rebased on top of drm-next-2019-11-27
 - sort all include lines in all files
 - remove all include 
 - remove select "select VIDEOMODE_HELPERS"
 - call dispc_vp_setup() later in tidss_crtc_atomic_flush() (there is no
   to call it in new modeset case as it is also called in vp_enable())
 - change probe sequence and drm_device allocation (follow example in drm_drv.c)
 - use __maybe_unused instead of #ifdef for pm functions
 - remove "struct drm_fbdev_cma *fbdev;" from driver data
 - check panel connector type before connecting it
- No change to binding or MAINTAINERS patches

There was couple of attempts upstream an earlier version of this
driver about a year ago [1]. Back then I needed to stop my efforts to
implement support for next Keystone DSS version, so now the driver
supports three different Keystone DSS version on three different SoCs.

I am starting the patch series versioning from the beginning because it
has been over a year since the previous patch set and the structure of
the driver has evolved quite a bit. However, all the earlier comments
should be addressed in this series.

[1] https://patchwork.freedesktop.org/series/44947/
[2] https://lists.freedesktop.org/archives/dri-devel/2019-November/246542.html

Jyri Sarha (5):
  dt-bindings: display: ti,k2g-dss: Add dt-schema yaml binding
  dt-bindings: display: ti,am65x-dss: Add dt-schema yaml binding
  dt-bindings: display: ti,j721e-dss: Add dt-schema yaml binding
  drm/tidss: New driver for TI Keystone platform Display SubSystem
  MAINTAINERS: add entry for tidss

 .../bindings/display/ti/ti,am65x-dss.yaml |  152 +
 .../bindings/display/ti/ti,j721e-dss.yaml |  208 ++
 .../bindings/display/ti/ti,k2g-dss.yaml   |  109 +
 MAINTAINERS   |   11 +
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/tidss/Kconfig |   14 +
 drivers/gpu/drm/tidss/Makefile|   12 +
 drivers/gpu/drm/tidss/tidss_crtc.c|  377 +++
 drivers/gpu/drm/tidss/tidss_crtc.h|   46 +
 drivers/gpu/drm/tidss/tidss_dispc.c   | 2774 +
 drivers/gpu/drm/tidss/tidss_dispc.h   |  132 +
 drivers/gpu/drm/tidss/tidss_dispc_regs.h  |  243 ++
 drivers/gpu/drm/tidss/tidss_drv.c |  285 ++
 drivers/gpu/drm/tidss/tidss_drv.h |   39 +
 drivers/gpu/drm/tidss/tidss_encoder.c |   88 +
 drivers/gpu/drm/tidss/tidss_encoder.h |   17 +
 drivers/gpu/drm/tidss/tidss_irq.c |  146 +
 drivers/gpu/drm/tidss/tidss_irq.h |   77 +
 drivers/gpu/drm/tidss/tidss_kms.c |  249 ++
 drivers/gpu/drm/tidss/tidss_kms.h |   15 +
 drivers/gpu/drm/tidss/tidss_plane.c   |  217 ++
 drivers/gpu/drm/tidss/tidss_plane.h   |   25 +
 drivers/gpu/drm/tidss/tidss_scale_coefs.c |  202 ++
 drivers/gpu/drm/tidss/tidss_scale_coefs.h |   22 +
 25 files changed, 5463 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml
 

Re: [PATCH v12 04/22] mm: devmap: refactor 1-based refcounting for ZONE_DEVICE pages

2020-01-16 Thread John Hubbard

On 1/16/20 1:37 AM, Christoph Hellwig wrote:

On Wed, Jan 15, 2020 at 01:19:41PM -0800, John Hubbard wrote:

On 1/15/20 7:23 AM, Christoph Hellwig wrote:
...


I'm really not sold on this scheme.  Note that I think it is
particularly bad, but it also doesn't seem any better than what
we had before, and it introduced quite a bit more code.



Hi Christoph,

All by itself, yes. But the very next patch (which needs a little
rework for other reasons, so not included here) needs to reuse some of
these functions within __unpin_devmap_managed_user_page():


Well, then combine it with the series that actually does the change.



OK, that makes sense. I just double-checked with a quick test run, that it
doesn't have dependencies with the rest of this series, and it came out clean,
so:

Andrew, could you please remove just this one patch from mmotm and linux-next?




Also my vaguely recollection is that we had some idea on how to get rid
of the off by one refcounting for the zone device pages, which would be
a much better outcome.



Yes, I recall that Dan Williams mentioned it, but I don't think he provided
any details yet.


thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC PATCH 4/4] drm/i915/gvt: move public gvt headers out into global include

2020-01-16 Thread Greg KH
On Thu, Jan 16, 2020 at 04:05:22PM +0100, Julian Stecklina wrote:
> Hi Greg,
> 
> On Thu, 2020-01-16 at 15:23 +0100, Greg KH wrote:
> > On Thu, Jan 16, 2020 at 03:13:01PM +0100, Julian Stecklina wrote:
> > > Hi Greg, Christoph,
> > > 
> > > On Wed, 2020-01-15 at 16:22 +0100, Greg KH wrote:
> > > > On Thu, Jan 09, 2020 at 07:13:57PM +0200, Julian Stecklina wrote:
> > > > > Now that the GVT interface to hypervisors does not depend on i915/GVT
> > > > > internals anymore, we can move the headers to the global include/.
> > > > > 
> > > > > This makes out-of-tree modules for hypervisor integration possible.
> > > > 
> > > > What kind of out-of-tree modules do you need/want for this?
> > > 
> > > The mediated virtualization support in the i915 driver needs a backend to
> > > the
> > > hypervisor. There is currently one backend for KVM in the tree
> > > (drivers/gpu/drm/i915/gvt/kvmgt.c) and at least 3 other hypervisor 
> > > backends
> > > out
> > > of tree in various states of development that I know of. We are currently
> > > developing one of these.
> > 
> > Great, then just submit this patch series as part of your patch series
> > when submitting yoru hypervisor code.  That's the normal way to export
> > new symbols, we can't do so without an in-kernel user.
> 
> Fair enough.
> 
> As I already said, the KVMGT code is the in-kernel user. But I guess I can
> extend the already existing function pointer way of decoupling KVMGT from i915
> and be on my way without exporting any symbols.
> 
> Somewhat independent of the current discussion, I also think that it's 
> valuable
> to have a defined API (I'm not saying stable API) for the hypervisor backends 
> to
> define what's okay and not okay for them to do.

The only way to get a "good" api is for at least 3 users of them get
into the kernel tree.  If all you have is one or two, then you go with
what you got, and evolve over time as more get added and find better
ways to use them.

In short, it's just basic evolution, not intelligent design :)

thanks,

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


Re: [RFC PATCH v2 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

2020-01-16 Thread Chris Wilson
Quoting Akeem G Abodunrin (2020-01-14 17:45:48)
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.h 
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.h
> new file mode 100644
> index ..4b88dd8d0fd4
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.h
> @@ -0,0 +1,16 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#ifndef __GEN7_RENDERCLEAR_H__
> +#define __GEN7_RENDERCLEAR_H__
> +
> +#define batch_advance(Y, CS) GEM_BUG_ON((Y)->end != (CS))

It works better if you actually put it to use, after every
batch_alloc_items() [give or take]. And it doesn't need to be used
outside of gen7_renderclear.c so can live there.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH AUTOSEL 4.4 172/174] drm/radeon: fix bad DMA from INTERRUPT_CNTL2

2020-01-16 Thread Sasha Levin
From: Sam Bobroff 

[ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]

The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address.  This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).

Instead, use the DMA address of the dummy page because it will always
be safe.

Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx 
chips (v3)")
Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/cik.c  | 4 ++--
 drivers/gpu/drm/radeon/r600.c | 4 ++--
 drivers/gpu/drm/radeon/si.c   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 80b6d6e4721a..7acde09c8e8f 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7372,8 +7372,8 @@ static int cik_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* XXX this should actually be a bus address, not an MC address. same 
on older asics */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 0e20c08f8977..2056224d0b3c 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3647,8 +3647,8 @@ int r600_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 5cf3a2cbc07e..4128c98d9054 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6013,8 +6013,8 @@ static int si_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 148/174] drm/msm/dsi: Implement reset correctly

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit 78e31c42261779a01bc73472d0f65f15378e9de3 ]

On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP.  This is because the reset
logic is not correct per the hardware documentation.

The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.

wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes.  Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.

Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.

Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li 
Cc: Rob Clark 
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Sean Paul 
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.h...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 4c49868efcda..12ddbbb53107 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -30,6 +30,8 @@
 #include "dsi.xml.h"
 #include "dsi_cfg.h"
 
+#define DSI_RESET_TOGGLE_DELAY_MS 20
+
 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
 {
u32 ver;
@@ -764,7 +766,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
wmb(); /* clocks need to be enabled before reset */
 
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb(); /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
 }
 
@@ -,7 +1113,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host 
*msm_host)
 
/* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb();  /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
wmb();  /* controller out of reset */
dsi_write(msm_host, REG_DSI_CTRL, data0);
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 101/174] drm/msm/mdp5: Fix mdp5_cfg_init error return

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit fc19cbb785d7bbd1a1af26229b5240a3ab332744 ]

If mdp5_cfg_init fails because of an unknown major version, a null pointer
dereference occurs.  This is because the caller of init expects error
pointers, but init returns NULL on error.  Fix this by returning the
expected values on error.

Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module)
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index bb1225aa2f75..89305ad3cde2 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -547,7 +547,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
if (cfg_handler)
mdp5_cfg_destroy(cfg_handler);
 
-   return NULL;
+   return ERR_PTR(ret);
 }
 
 static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev)
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 105/174] drm/msm/a3xx: remove TPL1 regs from snapshot

2020-01-16 Thread Sasha Levin
From: Rob Clark 

[ Upstream commit f47bee2ba447bebc304111c16ef1e1a73a9744dd ]

These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
when we try to read them for GPU state snapshot, in response to a GPU
hang.  It is rather impolite when GPU recovery triggers an insta-
reboot, so lets remove the TPL1 registers from the snapshot.

Fixes: 7198e6b03155 drm/msm: add a3xx gpu support
Signed-off-by: Rob Clark 
Reviewed-by: Jordan Crouse 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index fd266ed963b6..25a0e7d13340 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -383,19 +383,17 @@ static const unsigned int a3xx_registers[] = {
0x2200, 0x2212, 0x2214, 0x2217, 0x221a, 0x221a, 0x2240, 0x227e,
0x2280, 0x228b, 0x22c0, 0x22c0, 0x22c4, 0x22ce, 0x22d0, 0x22d8,
0x22df, 0x22e6, 0x22e8, 0x22e9, 0x22ec, 0x22ec, 0x22f0, 0x22f7,
-   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2348, 0x2349, 0x2350, 0x2356,
-   0x2360, 0x2360, 0x2440, 0x2440, 0x2444, 0x2444, 0x2448, 0x244d,
-   0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470, 0x2472, 0x2472,
-   0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3, 0x24e4, 0x24ef,
-   0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e, 0x2510, 0x2511,
-   0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea, 0x25ec, 0x25ed,
-   0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617, 0x261a, 0x261a,
-   0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0, 0x26c4, 0x26ce,
-   0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9, 0x26ec, 0x26ec,
-   0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743, 0x2748, 0x2749,
-   0x2750, 0x2756, 0x2760, 0x2760, 0x300c, 0x300e, 0x301c, 0x301d,
-   0x302a, 0x302a, 0x302c, 0x302d, 0x3030, 0x3031, 0x3034, 0x3036,
-   0x303c, 0x303c, 0x305e, 0x305f,
+   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2440, 0x2440, 0x2444, 0x2444,
+   0x2448, 0x244d, 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470,
+   0x2472, 0x2472, 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3,
+   0x24e4, 0x24ef, 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e,
+   0x2510, 0x2511, 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea,
+   0x25ec, 0x25ed, 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617,
+   0x261a, 0x261a, 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0,
+   0x26c4, 0x26ce, 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9,
+   0x26ec, 0x26ec, 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743,
+   0x300c, 0x300e, 0x301c, 0x301d, 0x302a, 0x302a, 0x302c, 0x302d,
+   0x3030, 0x3031, 0x3034, 0x3036, 0x303c, 0x303c, 0x305e, 0x305f,
~0   /* sentinel */
 };
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 092/174] backlight: lm3630a: Return 0 on success in update_status functions

2020-01-16 Thread Sasha Levin
From: Brian Masney 

[ Upstream commit d3f48ec0954c6aac736ab21c34a35d7554409112 ]

lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.

Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Signed-off-by: Brian Masney 
Acked-by: Pavel Machek 
Acked-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/video/backlight/lm3630a_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/lm3630a_bl.c 
b/drivers/video/backlight/lm3630a_bl.c
index 35fe4825a454..5ef6f9d420a2 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -200,7 +200,7 @@ static int lm3630a_bank_a_update_status(struct 
backlight_device *bl)
  LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -277,7 +277,7 @@ static int lm3630a_bank_b_update_status(struct 
backlight_device *bl)
  LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 049/174] drm/nouveau/pmu: don't print reply values if exec is false

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]

Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
updated.

Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable")
Fixes: ebb58dc2ef8c ("drm/nouveau/pmu: rename from pwr (no binary change)")

Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
index e6f74168238c..2ef9e942f43a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
@@ -87,10 +87,10 @@ nvkm_memx_fini(struct nvkm_memx **pmemx, bool exec)
if (exec) {
nvkm_pmu_send(pmu, reply, PROC_MEMX, MEMX_MSG_EXEC,
  memx->base, finish);
+   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
+  reply[0], reply[1]);
}
 
-   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
-  reply[0], reply[1]);
kfree(memx);
return 0;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 041/174] fbdev: chipsfb: remove set but not used variable 'size'

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 8e71fa5e4d86bedfd26df85381d65d6b4c860020 ]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/chipsfb.c: In function 'chipsfb_pci_init':
drivers/video/fbdev/chipsfb.c:352:22: warning:
 variable 'size' set but not used [-Wunused-but-set-variable]

Fixes: 8c8709334cec ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK").
Signed-off-by: YueHaibing 
Acked-by: Michael Ellerman 
Cc: Daniel Vetter 
Cc: Christophe Leroy 
[b.zolnierkie: minor commit summary and description fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/chipsfb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
index 59abdc6a97f6..314b7eceb81c 100644
--- a/drivers/video/fbdev/chipsfb.c
+++ b/drivers/video/fbdev/chipsfb.c
@@ -350,7 +350,7 @@ static void init_chips(struct fb_info *p, unsigned long 
addr)
 static int chipsfb_pci_init(struct pci_dev *dp, const struct pci_device_id 
*ent)
 {
struct fb_info *p;
-   unsigned long addr, size;
+   unsigned long addr;
unsigned short cmd;
int rc = -ENODEV;
 
@@ -362,7 +362,6 @@ static int chipsfb_pci_init(struct pci_dev *dp, const 
struct pci_device_id *ent)
if ((dp->resource[0].flags & IORESOURCE_MEM) == 0)
goto err_disable;
addr = pci_resource_start(dp, 0);
-   size = pci_resource_len(dp, 0);
if (addr == 0)
goto err_disable;
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 048/174] drm/nouveau/bios/ramcfg: fix missing parentheses when calculating RON

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]

Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator.  I believe the missing
parentheses around the expression before appying the ! operator will
result in the desired result.

[ Note, not tested ]

Detected by CoveritScan, CID#1324005 ("Operands don't affect result")

Fixes: c25bf7b6155c ("drm/nouveau/bios/ramcfg: Separate out RON pull value")
Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
index 60ece0a8a2e1..1d2d6bae73cd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
@@ -87,7 +87,7 @@ nvkm_gddr3_calc(struct nvkm_ram *ram)
WR  = (ram->next->bios.timing[2] & 0x007f) >> 16;
/* XXX: Get these values from the VBIOS instead */
DLL = !(ram->mr[1] & 0x1);
-   RON = !(ram->mr[1] & 0x300) >> 8;
+   RON = !((ram->mr[1] & 0x300) >> 8);
break;
default:
return -ENOSYS;
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 008/174] drm/dp_mst: Skip validating ports during destruction, just ref

2020-01-16 Thread Sasha Levin
From: Lyude Paul 

[ Upstream commit c54c7374ff44de5e609506aca7c0deae4703b6d1 ]

Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
accidentally introduced into DRM two years ago.

Pretend we have a topology like this:

|- DP-1: mst_primary
   |- DP-4: active display
   |- DP-5: disconnected
   |- DP-6: active hub
  |- DP-7: active display
  |- DP-8: disconnected
  |- DP-9: disconnected

If we unplug DP-6, the topology starting at DP-7 will be destroyed but
it's payloads will live on in DP-1's VCPI allocations and thus require
removal. However, this removal currently fails because
drm_dp_update_payload_part1() will (rightly so) try to validate the port
before accessing it, fail then abort. If we keep going, eventually we
run the MST hub out of bandwidth and all new allocations will start to
fail (or in my case; all new displays just start flickering a ton).

We could just teach drm_dp_update_payload_part1() not to drop the port
ref in this case, but then we also need to teach
drm_dp_destroy_payload_step1() to do the same thing, then hope no one
ever adds anything to the that requires a validated port reference in
drm_dp_destroy_connector_work(). Kind of sketchy.

So let's go with a more clever solution: any port that
drm_dp_destroy_connector_work() interacts with is guaranteed to still
exist in memory until we say so. While said port might not be valid we
don't really care: that's the whole reason we're destroying it in the
first place! So, teach drm_dp_get_validated_port_ref() to use the all
mighty current_work() function to avoid attempting to validate ports
from the context of mgr->destroy_connector_work. I can't see any
situation where this wouldn't be safe, and this avoids having to play
whack-a-mole in the future of trying to work around port validation.

Signed-off-by: Lyude Paul 
Fixes: 263efde31f97 ("drm/dp/mst: Get validated port ref in 
drm_dp_update_payload_part1()")
Reported-by: Jerry Zuo 
Cc: Jerry Zuo 
Cc: Harry Wentland 
Cc:  # v4.6+
Reviewed-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-ly...@redhat.com
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 2cb924ffd5a3..4d0f77f0edad 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -975,9 +975,20 @@ static struct drm_dp_mst_port 
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
 static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
 {
struct drm_dp_mst_port *rport = NULL;
+
mutex_lock(>lock);
-   if (mgr->mst_primary)
-   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary, port);
+   /*
+* Port may or may not be 'valid' but we don't care about that when
+* destroying the port and we are guaranteed that the port pointer
+* will be valid until we've finished
+*/
+   if (current_work() == >destroy_connector_work) {
+   kref_get(>kref);
+   rport = port;
+   } else if (mgr->mst_primary) {
+   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary,
+  port);
+   }
mutex_unlock(>lock);
return rport;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.4 001/174] drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 09c4b49457434fa74749ad6194ef28464d9f5df9 ]

This doesn't affect runtime because in the current code "idx" is always
valid.

First, we read from "vgdev->capsets[idx].max_size" before checking
whether "idx" is within bounds.  And secondly the bounds check is off by
one so we could end up reading one element beyond the end of the
vgdev->capsets[] array.

Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
Signed-off-by: Dan Carpenter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20180704094250.m7sgvvzg3dhcvv3h@kili.mountain
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index a1b3ea1ccb65..772a5a3b0ce1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -681,11 +681,11 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
 {
struct virtio_gpu_get_capset *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
-   int max_size = vgdev->capsets[idx].max_size;
+   int max_size;
struct virtio_gpu_drv_cap_cache *cache_ent;
void *resp_buf;
 
-   if (idx > vgdev->num_capsets)
+   if (idx >= vgdev->num_capsets)
return -EINVAL;
 
if (version > vgdev->capsets[idx].max_version)
@@ -695,6 +695,7 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
if (!cache_ent)
return -ENOMEM;
 
+   max_size = vgdev->capsets[idx].max_size;
cache_ent->caps_cache = kmalloc(max_size, GFP_KERNEL);
if (!cache_ent->caps_cache) {
kfree(cache_ent);
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 248/251] drm/radeon: fix bad DMA from INTERRUPT_CNTL2

2020-01-16 Thread Sasha Levin
From: Sam Bobroff 

[ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]

The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address.  This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).

Instead, use the DMA address of the dummy page because it will always
be safe.

Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx 
chips (v3)")
Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/cik.c  | 4 ++--
 drivers/gpu/drm/radeon/r600.c | 4 ++--
 drivers/gpu/drm/radeon/si.c   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b99f3e59011c..5fcb5869a489 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7026,8 +7026,8 @@ static int cik_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* XXX this should actually be a bus address, not an MC address. same 
on older asics */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index f2eac6b6c46a..9569c35f8766 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3697,8 +3697,8 @@ int r600_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index b75d809c292e..919d389869ce 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -6018,8 +6018,8 @@ static int si_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 217/251] drm/msm/dsi: Implement reset correctly

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit 78e31c42261779a01bc73472d0f65f15378e9de3 ]

On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP.  This is because the reset
logic is not correct per the hardware documentation.

The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.

wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes.  Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.

Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.

Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li 
Cc: Rob Clark 
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Sean Paul 
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.h...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 6f240021705b..e49b414c012c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -33,6 +33,8 @@
 #include "sfpb.xml.h"
 #include "dsi_cfg.h"
 
+#define DSI_RESET_TOGGLE_DELAY_MS 20
+
 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
 {
u32 ver;
@@ -909,7 +911,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
wmb(); /* clocks need to be enabled before reset */
 
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb(); /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
 }
 
@@ -1288,7 +1290,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host 
*msm_host)
 
/* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb();  /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
wmb();  /* controller out of reset */
dsi_write(msm_host, REG_DSI_CTRL, data0);
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 153/251] drm/msm/mdp5: Fix mdp5_cfg_init error return

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit fc19cbb785d7bbd1a1af26229b5240a3ab332744 ]

If mdp5_cfg_init fails because of an unknown major version, a null pointer
dereference occurs.  This is because the caller of init expects error
pointers, but init returns NULL on error.  Fix this by returning the
expected values on error.

Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module)
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 8b4e3004f451..86b0448d2ce5 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -542,7 +542,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
if (cfg_handler)
mdp5_cfg_destroy(cfg_handler);
 
-   return NULL;
+   return ERR_PTR(ret);
 }
 
 static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev)
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 158/251] drm/msm/a3xx: remove TPL1 regs from snapshot

2020-01-16 Thread Sasha Levin
From: Rob Clark 

[ Upstream commit f47bee2ba447bebc304111c16ef1e1a73a9744dd ]

These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
when we try to read them for GPU state snapshot, in response to a GPU
hang.  It is rather impolite when GPU recovery triggers an insta-
reboot, so lets remove the TPL1 registers from the snapshot.

Fixes: 7198e6b03155 drm/msm: add a3xx gpu support
Signed-off-by: Rob Clark 
Reviewed-by: Jordan Crouse 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index fd266ed963b6..25a0e7d13340 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -383,19 +383,17 @@ static const unsigned int a3xx_registers[] = {
0x2200, 0x2212, 0x2214, 0x2217, 0x221a, 0x221a, 0x2240, 0x227e,
0x2280, 0x228b, 0x22c0, 0x22c0, 0x22c4, 0x22ce, 0x22d0, 0x22d8,
0x22df, 0x22e6, 0x22e8, 0x22e9, 0x22ec, 0x22ec, 0x22f0, 0x22f7,
-   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2348, 0x2349, 0x2350, 0x2356,
-   0x2360, 0x2360, 0x2440, 0x2440, 0x2444, 0x2444, 0x2448, 0x244d,
-   0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470, 0x2472, 0x2472,
-   0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3, 0x24e4, 0x24ef,
-   0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e, 0x2510, 0x2511,
-   0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea, 0x25ec, 0x25ed,
-   0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617, 0x261a, 0x261a,
-   0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0, 0x26c4, 0x26ce,
-   0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9, 0x26ec, 0x26ec,
-   0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743, 0x2748, 0x2749,
-   0x2750, 0x2756, 0x2760, 0x2760, 0x300c, 0x300e, 0x301c, 0x301d,
-   0x302a, 0x302a, 0x302c, 0x302d, 0x3030, 0x3031, 0x3034, 0x3036,
-   0x303c, 0x303c, 0x305e, 0x305f,
+   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2440, 0x2440, 0x2444, 0x2444,
+   0x2448, 0x244d, 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470,
+   0x2472, 0x2472, 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3,
+   0x24e4, 0x24ef, 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e,
+   0x2510, 0x2511, 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea,
+   0x25ec, 0x25ed, 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617,
+   0x261a, 0x261a, 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0,
+   0x26c4, 0x26ce, 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9,
+   0x26ec, 0x26ec, 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743,
+   0x300c, 0x300e, 0x301c, 0x301d, 0x302a, 0x302a, 0x302c, 0x302d,
+   0x3030, 0x3031, 0x3034, 0x3036, 0x303c, 0x303c, 0x305e, 0x305f,
~0   /* sentinel */
 };
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 141/251] backlight: lm3630a: Return 0 on success in update_status functions

2020-01-16 Thread Sasha Levin
From: Brian Masney 

[ Upstream commit d3f48ec0954c6aac736ab21c34a35d7554409112 ]

lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.

Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Signed-off-by: Brian Masney 
Acked-by: Pavel Machek 
Acked-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/video/backlight/lm3630a_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/lm3630a_bl.c 
b/drivers/video/backlight/lm3630a_bl.c
index 60d6c2ac87aa..1771220b2437 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -200,7 +200,7 @@ static int lm3630a_bank_a_update_status(struct 
backlight_device *bl)
  LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -277,7 +277,7 @@ static int lm3630a_bank_b_update_status(struct 
backlight_device *bl)
  LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 081/251] drm/nouveau/pmu: don't print reply values if exec is false

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]

Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
updated.

Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable")
Fixes: ebb58dc2ef8c ("drm/nouveau/pmu: rename from pwr (no binary change)")

Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
index e6f74168238c..2ef9e942f43a 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
@@ -87,10 +87,10 @@ nvkm_memx_fini(struct nvkm_memx **pmemx, bool exec)
if (exec) {
nvkm_pmu_send(pmu, reply, PROC_MEMX, MEMX_MSG_EXEC,
  memx->base, finish);
+   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
+  reply[0], reply[1]);
}
 
-   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
-  reply[0], reply[1]);
kfree(memx);
return 0;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 080/251] drm/nouveau/bios/ramcfg: fix missing parentheses when calculating RON

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]

Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator.  I believe the missing
parentheses around the expression before appying the ! operator will
result in the desired result.

[ Note, not tested ]

Detected by CoveritScan, CID#1324005 ("Operands don't affect result")

Fixes: c25bf7b6155c ("drm/nouveau/bios/ramcfg: Separate out RON pull value")
Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
index 60ece0a8a2e1..1d2d6bae73cd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
@@ -87,7 +87,7 @@ nvkm_gddr3_calc(struct nvkm_ram *ram)
WR  = (ram->next->bios.timing[2] & 0x007f) >> 16;
/* XXX: Get these values from the VBIOS instead */
DLL = !(ram->mr[1] & 0x1);
-   RON = !(ram->mr[1] & 0x300) >> 8;
+   RON = !((ram->mr[1] & 0x300) >> 8);
break;
default:
return -ENOSYS;
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 063/251] fbdev: chipsfb: remove set but not used variable 'size'

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 8e71fa5e4d86bedfd26df85381d65d6b4c860020 ]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/chipsfb.c: In function 'chipsfb_pci_init':
drivers/video/fbdev/chipsfb.c:352:22: warning:
 variable 'size' set but not used [-Wunused-but-set-variable]

Fixes: 8c8709334cec ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK").
Signed-off-by: YueHaibing 
Acked-by: Michael Ellerman 
Cc: Daniel Vetter 
Cc: Christophe Leroy 
[b.zolnierkie: minor commit summary and description fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/chipsfb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
index 59abdc6a97f6..314b7eceb81c 100644
--- a/drivers/video/fbdev/chipsfb.c
+++ b/drivers/video/fbdev/chipsfb.c
@@ -350,7 +350,7 @@ static void init_chips(struct fb_info *p, unsigned long 
addr)
 static int chipsfb_pci_init(struct pci_dev *dp, const struct pci_device_id 
*ent)
 {
struct fb_info *p;
-   unsigned long addr, size;
+   unsigned long addr;
unsigned short cmd;
int rc = -ENODEV;
 
@@ -362,7 +362,6 @@ static int chipsfb_pci_init(struct pci_dev *dp, const 
struct pci_device_id *ent)
if ((dp->resource[0].flags & IORESOURCE_MEM) == 0)
goto err_disable;
addr = pci_resource_start(dp, 0);
-   size = pci_resource_len(dp, 0);
if (addr == 0)
goto err_disable;
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 002/251] drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 09c4b49457434fa74749ad6194ef28464d9f5df9 ]

This doesn't affect runtime because in the current code "idx" is always
valid.

First, we read from "vgdev->capsets[idx].max_size" before checking
whether "idx" is within bounds.  And secondly the bounds check is off by
one so we could end up reading one element beyond the end of the
vgdev->capsets[] array.

Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
Signed-off-by: Dan Carpenter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20180704094250.m7sgvvzg3dhcvv3h@kili.mountain
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index a1b3ea1ccb65..772a5a3b0ce1 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -681,11 +681,11 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
 {
struct virtio_gpu_get_capset *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
-   int max_size = vgdev->capsets[idx].max_size;
+   int max_size;
struct virtio_gpu_drv_cap_cache *cache_ent;
void *resp_buf;
 
-   if (idx > vgdev->num_capsets)
+   if (idx >= vgdev->num_capsets)
return -EINVAL;
 
if (version > vgdev->capsets[idx].max_version)
@@ -695,6 +695,7 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
if (!cache_ent)
return -ENOMEM;
 
+   max_size = vgdev->capsets[idx].max_size;
cache_ent->caps_cache = kmalloc(max_size, GFP_KERNEL);
if (!cache_ent->caps_cache) {
kfree(cache_ent);
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 012/251] drm/dp_mst: Skip validating ports during destruction, just ref

2020-01-16 Thread Sasha Levin
From: Lyude Paul 

[ Upstream commit c54c7374ff44de5e609506aca7c0deae4703b6d1 ]

Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
accidentally introduced into DRM two years ago.

Pretend we have a topology like this:

|- DP-1: mst_primary
   |- DP-4: active display
   |- DP-5: disconnected
   |- DP-6: active hub
  |- DP-7: active display
  |- DP-8: disconnected
  |- DP-9: disconnected

If we unplug DP-6, the topology starting at DP-7 will be destroyed but
it's payloads will live on in DP-1's VCPI allocations and thus require
removal. However, this removal currently fails because
drm_dp_update_payload_part1() will (rightly so) try to validate the port
before accessing it, fail then abort. If we keep going, eventually we
run the MST hub out of bandwidth and all new allocations will start to
fail (or in my case; all new displays just start flickering a ton).

We could just teach drm_dp_update_payload_part1() not to drop the port
ref in this case, but then we also need to teach
drm_dp_destroy_payload_step1() to do the same thing, then hope no one
ever adds anything to the that requires a validated port reference in
drm_dp_destroy_connector_work(). Kind of sketchy.

So let's go with a more clever solution: any port that
drm_dp_destroy_connector_work() interacts with is guaranteed to still
exist in memory until we say so. While said port might not be valid we
don't really care: that's the whole reason we're destroying it in the
first place! So, teach drm_dp_get_validated_port_ref() to use the all
mighty current_work() function to avoid attempting to validate ports
from the context of mgr->destroy_connector_work. I can't see any
situation where this wouldn't be safe, and this avoids having to play
whack-a-mole in the future of trying to work around port validation.

Signed-off-by: Lyude Paul 
Fixes: 263efde31f97 ("drm/dp/mst: Get validated port ref in 
drm_dp_update_payload_part1()")
Reported-by: Jerry Zuo 
Cc: Jerry Zuo 
Cc: Harry Wentland 
Cc:  # v4.6+
Reviewed-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-ly...@redhat.com
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e05dda92398c..17aedaaf364c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -980,9 +980,20 @@ static struct drm_dp_mst_port 
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
 static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
 {
struct drm_dp_mst_port *rport = NULL;
+
mutex_lock(>lock);
-   if (mgr->mst_primary)
-   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary, port);
+   /*
+* Port may or may not be 'valid' but we don't care about that when
+* destroying the port and we are guaranteed that the port pointer
+* will be valid until we've finished
+*/
+   if (current_work() == >destroy_connector_work) {
+   kref_get(>kref);
+   rport = port;
+   } else if (mgr->mst_primary) {
+   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary,
+  port);
+   }
mutex_unlock(>lock);
return rport;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.9 001/251] drm/sti: do not remove the drm_bridge that was never added

2020-01-16 Thread Sasha Levin
From: Peter Rosin 

[ Upstream commit 66e31a72dc38543b2d9d1ce267dc78ba9beebcfd ]

Removing the drm_bridge_remove call should avoid a NULL dereference
during list processing in drm_bridge_remove if the error path is ever
taken.

The more natural approach would perhaps be to add a drm_bridge_add,
but there are several other bridges that never call drm_bridge_add.
Just removing the drm_bridge_remove is the easier fix.

Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
Signed-off-by: Benjamin Gaignard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180806061910.29914-2-p...@axentia.se
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_hda.c  | 1 -
 drivers/gpu/drm/sti/sti_hdmi.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index e7c243f70870..08808e3701de 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -740,7 +740,6 @@ static int sti_hda_bind(struct device *dev, struct device 
*master, void *data)
return 0;
 
 err_sysfs:
-   drm_bridge_remove(bridge);
return -EINVAL;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 376b0763c874..a5412a6fbeca 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1352,7 +1352,6 @@ static int sti_hdmi_bind(struct device *dev, struct 
device *master, void *data)
return 0;
 
 err_sysfs:
-   drm_bridge_remove(bridge);
hdmi->drm_connector = NULL;
return -EINVAL;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 363/371] drm/radeon: fix bad DMA from INTERRUPT_CNTL2

2020-01-16 Thread Sasha Levin
From: Sam Bobroff 

[ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]

The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address.  This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).

Instead, use the DMA address of the dummy page because it will always
be safe.

Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx 
chips (v3)")
Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/cik.c  | 4 ++--
 drivers/gpu/drm/radeon/r600.c | 4 ++--
 drivers/gpu/drm/radeon/si.c   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ce8b353b5753..ba31c7674fcd 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -7012,8 +7012,8 @@ static int cik_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* XXX this should actually be a bus address, not an MC address. same 
on older asics */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e06e2d8feab3..a724bb87cfad 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3690,8 +3690,8 @@ int r600_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 1907c950d76f..1144cafea9ac 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -5993,8 +5993,8 @@ static int si_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 322/371] drm/msm/dsi: Implement reset correctly

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit 78e31c42261779a01bc73472d0f65f15378e9de3 ]

On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP.  This is because the reset
logic is not correct per the hardware documentation.

The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.

wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes.  Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.

Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.

Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li 
Cc: Rob Clark 
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Sean Paul 
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.h...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index a9a0b56f1fbc..b9cb7c09e05a 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -34,6 +34,8 @@
 #include "dsi_cfg.h"
 #include "msm_kms.h"
 
+#define DSI_RESET_TOGGLE_DELAY_MS 20
+
 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
 {
u32 ver;
@@ -906,7 +908,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
wmb(); /* clocks need to be enabled before reset */
 
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb(); /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
 }
 
@@ -1288,7 +1290,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host 
*msm_host)
 
/* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb();  /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
wmb();  /* controller out of reset */
dsi_write(msm_host, REG_DSI_CTRL, data0);
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 230/371] drm/msm/mdp5: Fix mdp5_cfg_init error return

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit fc19cbb785d7bbd1a1af26229b5240a3ab332744 ]

If mdp5_cfg_init fails because of an unknown major version, a null pointer
dereference occurs.  This is because the caller of init expects error
pointers, but init returns NULL on error.  Fix this by returning the
expected values on error.

Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module)
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
index 824067d2d427..42f0ecb0cf35 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c
@@ -635,7 +635,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
if (cfg_handler)
mdp5_cfg_destroy(cfg_handler);
 
-   return NULL;
+   return ERR_PTR(ret);
 }
 
 static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev)
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 236/371] drm/msm/a3xx: remove TPL1 regs from snapshot

2020-01-16 Thread Sasha Levin
From: Rob Clark 

[ Upstream commit f47bee2ba447bebc304111c16ef1e1a73a9744dd ]

These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
when we try to read them for GPU state snapshot, in response to a GPU
hang.  It is rather impolite when GPU recovery triggers an insta-
reboot, so lets remove the TPL1 registers from the snapshot.

Fixes: 7198e6b03155 drm/msm: add a3xx gpu support
Signed-off-by: Rob Clark 
Reviewed-by: Jordan Crouse 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 7791313405b5..c8671b1578c6 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -394,19 +394,17 @@ static const unsigned int a3xx_registers[] = {
0x2200, 0x2212, 0x2214, 0x2217, 0x221a, 0x221a, 0x2240, 0x227e,
0x2280, 0x228b, 0x22c0, 0x22c0, 0x22c4, 0x22ce, 0x22d0, 0x22d8,
0x22df, 0x22e6, 0x22e8, 0x22e9, 0x22ec, 0x22ec, 0x22f0, 0x22f7,
-   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2348, 0x2349, 0x2350, 0x2356,
-   0x2360, 0x2360, 0x2440, 0x2440, 0x2444, 0x2444, 0x2448, 0x244d,
-   0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470, 0x2472, 0x2472,
-   0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3, 0x24e4, 0x24ef,
-   0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e, 0x2510, 0x2511,
-   0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea, 0x25ec, 0x25ed,
-   0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617, 0x261a, 0x261a,
-   0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0, 0x26c4, 0x26ce,
-   0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9, 0x26ec, 0x26ec,
-   0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743, 0x2748, 0x2749,
-   0x2750, 0x2756, 0x2760, 0x2760, 0x300c, 0x300e, 0x301c, 0x301d,
-   0x302a, 0x302a, 0x302c, 0x302d, 0x3030, 0x3031, 0x3034, 0x3036,
-   0x303c, 0x303c, 0x305e, 0x305f,
+   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2440, 0x2440, 0x2444, 0x2444,
+   0x2448, 0x244d, 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470,
+   0x2472, 0x2472, 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3,
+   0x24e4, 0x24ef, 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e,
+   0x2510, 0x2511, 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea,
+   0x25ec, 0x25ed, 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617,
+   0x261a, 0x261a, 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0,
+   0x26c4, 0x26ce, 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9,
+   0x26ec, 0x26ec, 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743,
+   0x300c, 0x300e, 0x301c, 0x301d, 0x302a, 0x302a, 0x302c, 0x302d,
+   0x3030, 0x3031, 0x3034, 0x3036, 0x303c, 0x303c, 0x305e, 0x305f,
~0   /* sentinel */
 };
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 202/371] backlight: lm3630a: Return 0 on success in update_status functions

2020-01-16 Thread Sasha Levin
From: Brian Masney 

[ Upstream commit d3f48ec0954c6aac736ab21c34a35d7554409112 ]

lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.

Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Signed-off-by: Brian Masney 
Acked-by: Pavel Machek 
Acked-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/video/backlight/lm3630a_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/lm3630a_bl.c 
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct 
backlight_device *bl)
  LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct 
backlight_device *bl)
  LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 153/371] spi: tegra114: configure dma burst size to fifo trig level

2020-01-16 Thread Sasha Levin
From: Sowjanya Komatineni 

[ Upstream commit f4ce428c41fb22e3ed55496dded94df44cb920fa ]

Fixes: Configure DMA burst size to be same as SPI TX/RX trigger levels
to avoid mismatch.

SPI FIFO trigger levels are calculated based on the transfer length.
So this patch moves DMA slave configuration to happen before start
of DMAs.

Signed-off-by: Sowjanya Komatineni 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-tegra114.c | 52 ++
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 18dfbd57c61f..84ff0c507f0b 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -529,6 +529,8 @@ static int tegra_spi_start_dma_based_transfer(
u32 val;
unsigned int len;
int ret = 0;
+   u8 dma_burst;
+   struct dma_slave_config dma_sconfig = {0};
 
val = SPI_DMA_BLK_SET(tspi->curr_dma_words - 1);
tegra_spi_writel(tspi, val, SPI_DMA_BLK);
@@ -540,12 +542,16 @@ static int tegra_spi_start_dma_based_transfer(
len = tspi->curr_dma_words * 4;
 
/* Set attention level based on length of transfer */
-   if (len & 0xF)
+   if (len & 0xF) {
val |= SPI_TX_TRIG_1 | SPI_RX_TRIG_1;
-   else if (((len) >> 4) & 0x1)
+   dma_burst = 1;
+   } else if (((len) >> 4) & 0x1) {
val |= SPI_TX_TRIG_4 | SPI_RX_TRIG_4;
-   else
+   dma_burst = 4;
+   } else {
val |= SPI_TX_TRIG_8 | SPI_RX_TRIG_8;
+   dma_burst = 8;
+   }
 
if (tspi->cur_direction & DATA_DIR_TX)
val |= SPI_IE_TX;
@@ -556,7 +562,18 @@ static int tegra_spi_start_dma_based_transfer(
tegra_spi_writel(tspi, val, SPI_DMA_CTL);
tspi->dma_control_reg = val;
 
+   dma_sconfig.device_fc = true;
if (tspi->cur_direction & DATA_DIR_TX) {
+   dma_sconfig.dst_addr = tspi->phys + SPI_TX_FIFO;
+   dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   dma_sconfig.dst_maxburst = dma_burst;
+   ret = dmaengine_slave_config(tspi->tx_dma_chan, _sconfig);
+   if (ret < 0) {
+   dev_err(tspi->dev,
+   "DMA slave config failed: %d\n", ret);
+   return ret;
+   }
+
tegra_spi_copy_client_txbuf_to_spi_txbuf(tspi, t);
ret = tegra_spi_start_tx_dma(tspi, len);
if (ret < 0) {
@@ -567,6 +584,16 @@ static int tegra_spi_start_dma_based_transfer(
}
 
if (tspi->cur_direction & DATA_DIR_RX) {
+   dma_sconfig.src_addr = tspi->phys + SPI_RX_FIFO;
+   dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   dma_sconfig.src_maxburst = dma_burst;
+   ret = dmaengine_slave_config(tspi->rx_dma_chan, _sconfig);
+   if (ret < 0) {
+   dev_err(tspi->dev,
+   "DMA slave config failed: %d\n", ret);
+   return ret;
+   }
+
/* Make the dma buffer to read by dma */
dma_sync_single_for_device(tspi->dev, tspi->rx_dma_phys,
tspi->dma_buf_size, DMA_FROM_DEVICE);
@@ -626,7 +653,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data 
*tspi,
u32 *dma_buf;
dma_addr_t dma_phys;
int ret;
-   struct dma_slave_config dma_sconfig;
 
dma_chan = dma_request_slave_channel_reason(tspi->dev,
dma_to_memory ? "rx" : "tx");
@@ -646,19 +672,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data 
*tspi,
return -ENOMEM;
}
 
-   if (dma_to_memory) {
-   dma_sconfig.src_addr = tspi->phys + SPI_RX_FIFO;
-   dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   dma_sconfig.src_maxburst = 0;
-   } else {
-   dma_sconfig.dst_addr = tspi->phys + SPI_TX_FIFO;
-   dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   dma_sconfig.dst_maxburst = 0;
-   }
-
-   ret = dmaengine_slave_config(dma_chan, _sconfig);
-   if (ret)
-   goto scrub;
if (dma_to_memory) {
tspi->rx_dma_chan = dma_chan;
tspi->rx_dma_buf = dma_buf;
@@ -669,11 +682,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data 
*tspi,
tspi->tx_dma_phys = dma_phys;
}
return 0;
-
-scrub:
-   dma_free_coherent(tspi->dev, tspi->dma_buf_size, dma_buf, dma_phys);
-   dma_release_channel(dma_chan);
-   return ret;
 }
 
 static void tegra_spi_deinit_dma_param(struct tegra_spi_data *tspi,
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH AUTOSEL 4.14 111/371] drm/nouveau/bios/ramcfg: fix missing parentheses when calculating RON

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]

Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator.  I believe the missing
parentheses around the expression before appying the ! operator will
result in the desired result.

[ Note, not tested ]

Detected by CoveritScan, CID#1324005 ("Operands don't affect result")

Fixes: c25bf7b6155c ("drm/nouveau/bios/ramcfg: Separate out RON pull value")
Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
index 60ece0a8a2e1..1d2d6bae73cd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
@@ -87,7 +87,7 @@ nvkm_gddr3_calc(struct nvkm_ram *ram)
WR  = (ram->next->bios.timing[2] & 0x007f) >> 16;
/* XXX: Get these values from the VBIOS instead */
DLL = !(ram->mr[1] & 0x1);
-   RON = !(ram->mr[1] & 0x300) >> 8;
+   RON = !((ram->mr[1] & 0x300) >> 8);
break;
default:
return -ENOSYS;
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 112/371] drm/nouveau/pmu: don't print reply values if exec is false

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]

Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
updated.

Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable")
Fixes: ebb58dc2ef8c ("drm/nouveau/pmu: rename from pwr (no binary change)")

Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
index 11b28b086a06..7b052879af72 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
@@ -88,10 +88,10 @@ nvkm_memx_fini(struct nvkm_memx **pmemx, bool exec)
if (exec) {
nvkm_pmu_send(pmu, reply, PROC_MEMX, MEMX_MSG_EXEC,
  memx->base, finish);
+   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
+  reply[0], reply[1]);
}
 
-   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
-  reply[0], reply[1]);
kfree(memx);
return 0;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 089/371] fbdev: chipsfb: remove set but not used variable 'size'

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 8e71fa5e4d86bedfd26df85381d65d6b4c860020 ]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/chipsfb.c: In function 'chipsfb_pci_init':
drivers/video/fbdev/chipsfb.c:352:22: warning:
 variable 'size' set but not used [-Wunused-but-set-variable]

Fixes: 8c8709334cec ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK").
Signed-off-by: YueHaibing 
Acked-by: Michael Ellerman 
Cc: Daniel Vetter 
Cc: Christophe Leroy 
[b.zolnierkie: minor commit summary and description fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/chipsfb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
index f103665cad43..f9b366d17587 100644
--- a/drivers/video/fbdev/chipsfb.c
+++ b/drivers/video/fbdev/chipsfb.c
@@ -350,7 +350,7 @@ static void init_chips(struct fb_info *p, unsigned long 
addr)
 static int chipsfb_pci_init(struct pci_dev *dp, const struct pci_device_id 
*ent)
 {
struct fb_info *p;
-   unsigned long addr, size;
+   unsigned long addr;
unsigned short cmd;
int rc = -ENODEV;
 
@@ -362,7 +362,6 @@ static int chipsfb_pci_init(struct pci_dev *dp, const 
struct pci_device_id *ent)
if ((dp->resource[0].flags & IORESOURCE_MEM) == 0)
goto err_disable;
addr = pci_resource_start(dp, 0);
-   size = pci_resource_len(dp, 0);
if (addr == 0)
goto err_disable;
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 092/371] drm/etnaviv: potential NULL dereference

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 9e05352340d3a3e68c144136db9810b26ebb88c3 ]

The etnaviv_gem_prime_get_sg_table() is supposed to return error
pointers.  Otherwise it can lead to a NULL dereference when it's called
from drm_gem_map_dma_buf().

Fixes: 5f4a4a73f437 ("drm/etnaviv: fix gem_prime_get_sg_table to return new SG 
table")
Signed-off-by: Dan Carpenter 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index ae884723e9b1..880b95511b98 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -26,7 +26,7 @@ struct sg_table *etnaviv_gem_prime_get_sg_table(struct 
drm_gem_object *obj)
int npages = obj->size >> PAGE_SHIFT;
 
if (WARN_ON(!etnaviv_obj->pages))  /* should have already pinned! */
-   return NULL;
+   return ERR_PTR(-EINVAL);
 
return drm_prime_pages_to_sg(etnaviv_obj->pages, npages);
 }
-- 
2.20.1

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


Re: [PATCH v2 4/4] drm/simple-kms: Let DRM core send VBLANK events by default

2020-01-16 Thread Emil Velikov
Hi all,

On Thu, 16 Jan 2020 at 07:37, Thomas Zimmermann  wrote:

> > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c 
> > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > index 7cf3cf936547..23d2f51fc1d4 100644
> > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > @@ -149,6 +149,11 @@ void __drm_atomic_helper_crtc_duplicate_state(struct 
> > drm_crtc *crtc,
> >   /* Self refresh should be canceled when a new update is available */
> >   state->active = drm_atomic_crtc_effectively_active(state);
> >   state->self_refresh_active = false;
> > +
> > + if (drm_dev_has_vblank(crtc->dev))
> > + state->no_vblank = true;
> > + else
> > + state->no_vblank = false;
> >  }
> >  EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>
> I think the if/else branches are in the wrong order.
>
> But generally speaking, is it really that easy? The xen driver already
> has to work around simple-kms's auto-enabling of no_vblank (see patch
> 4). Maybe this settings interferes with other drivers as well. At least
> the calls for sending fake vblanks should be removed from all affected
> drivers.
>

I'm not sure if setting no_vblank based on dev->num_crtcs is the correct thing.
>From the original commit and associated description for no_vblank:

In some cases CRTCs are active but are not able to generating events, at
least not at every frame at it's expected to.
This is typically the case when the CRTC is feeding a writeback connector...

Reflects the ability of a CRTC to send VBLANK events


The proposed handling of no_vblank feels a little dirty, although
nothing better comes to mind.
Nevertheless code seems perfectly reasonable, so if it were me I'd merge it.

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


[PATCH AUTOSEL 4.14 053/371] drm/shmob: Fix return value check in shmob_drm_probe

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 06c3bbd3c12737a50c2e981821b5585e1786e73d ]

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Fixes: 8f1597c8f1a5 ("drm: shmobile: Perform initialization/cleanup at 
probe/remove time")
Signed-off-by: YueHaibing 
Reviewed-by: Simon Horman 
Reviewed-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 592572554eb0..58d8a98c749b 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -233,8 +233,8 @@ static int shmob_drm_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sdev->mmio = devm_ioremap_resource(>dev, res);
-   if (sdev->mmio == NULL)
-   return -ENOMEM;
+   if (IS_ERR(sdev->mmio))
+   return PTR_ERR(sdev->mmio);
 
ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
if (ret < 0)
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 014/371] drm/sun4i: hdmi: Fix double flag assignation

2020-01-16 Thread Sasha Levin
From: Maxime Ripard 

[ Upstream commit 1e0ff648940e603cab6c52cf3723017d30d78f30 ]

The is_double flag is a boolean currently assigned to the value of the d
variable, that is either 1 or 2. It means that this is_double variable is
always set to true, even though the initial intent was to have it set to
true when d is 2.

Fix this.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Reported-by: Dan Carpenter 
Signed-off-by: Maxime Ripard 
Reviewed-by: Giulio Benetti 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181021163446.29135-2-maxime.rip...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index 5cf2527bffc8..d7a8fea94557 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -50,7 +50,7 @@ static unsigned long sun4i_tmds_calc_divider(unsigned long 
rate,
(rate - tmp_rate) < (rate - best_rate)) {
best_rate = tmp_rate;
best_m = m;
-   is_double = d;
+   is_double = (d == 2) ? true : false;
}
}
}
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 006/371] drm/hisilicon: hibmc: Don't overwrite fb helper surface depth

2020-01-16 Thread Sasha Levin
From: John Garry 

[ Upstream commit 0ff9f49646353ce31312411e7e7bd2281492a40e ]

Currently the driver overwrites the surface depth provided by the fb
helper to give an invalid bpp/surface depth combination.

This has been exposed by commit 70109354fed2 ("drm: Reject unknown legacy
bpp and depth for drm_mode_addfb ioctl"), which now causes the driver to
fail to probe.

Fix by not overwriting the surface depth.

Fixes: d1667b86795a ("drm/hisilicon/hibmc: Add support for frame buffer")
Signed-off-by: John Garry 
Reviewed-by: Xinliang Liu 
Signed-off-by: Xinliang Liu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index 8bd29075ae4e..edcca1761500 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -71,7 +71,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
 sizes->surface_width, sizes->surface_height,
 sizes->surface_bpp);
-   sizes->surface_depth = 32;
 
bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 001/371] drm/sti: do not remove the drm_bridge that was never added

2020-01-16 Thread Sasha Levin
From: Peter Rosin 

[ Upstream commit 66e31a72dc38543b2d9d1ce267dc78ba9beebcfd ]

Removing the drm_bridge_remove call should avoid a NULL dereference
during list processing in drm_bridge_remove if the error path is ever
taken.

The more natural approach would perhaps be to add a drm_bridge_add,
but there are several other bridges that never call drm_bridge_add.
Just removing the drm_bridge_remove is the easier fix.

Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
Signed-off-by: Benjamin Gaignard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180806061910.29914-2-p...@axentia.se
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_hda.c  | 1 -
 drivers/gpu/drm/sti/sti_hdmi.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index cf65e32b5090..0399bb18d387 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device 
*master, void *data)
return 0;
 
 err_sysfs:
-   drm_bridge_remove(bridge);
return -EINVAL;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 30f02d2fdd03..bbb195a92e93 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1314,7 +1314,6 @@ static int sti_hdmi_bind(struct device *dev, struct 
device *master, void *data)
return 0;
 
 err_sysfs:
-   drm_bridge_remove(bridge);
hdmi->drm_connector = NULL;
return -EINVAL;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 019/371] drm/dp_mst: Skip validating ports during destruction, just ref

2020-01-16 Thread Sasha Levin
From: Lyude Paul 

[ Upstream commit c54c7374ff44de5e609506aca7c0deae4703b6d1 ]

Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
accidentally introduced into DRM two years ago.

Pretend we have a topology like this:

|- DP-1: mst_primary
   |- DP-4: active display
   |- DP-5: disconnected
   |- DP-6: active hub
  |- DP-7: active display
  |- DP-8: disconnected
  |- DP-9: disconnected

If we unplug DP-6, the topology starting at DP-7 will be destroyed but
it's payloads will live on in DP-1's VCPI allocations and thus require
removal. However, this removal currently fails because
drm_dp_update_payload_part1() will (rightly so) try to validate the port
before accessing it, fail then abort. If we keep going, eventually we
run the MST hub out of bandwidth and all new allocations will start to
fail (or in my case; all new displays just start flickering a ton).

We could just teach drm_dp_update_payload_part1() not to drop the port
ref in this case, but then we also need to teach
drm_dp_destroy_payload_step1() to do the same thing, then hope no one
ever adds anything to the that requires a validated port reference in
drm_dp_destroy_connector_work(). Kind of sketchy.

So let's go with a more clever solution: any port that
drm_dp_destroy_connector_work() interacts with is guaranteed to still
exist in memory until we say so. While said port might not be valid we
don't really care: that's the whole reason we're destroying it in the
first place! So, teach drm_dp_get_validated_port_ref() to use the all
mighty current_work() function to avoid attempting to validate ports
from the context of mgr->destroy_connector_work. I can't see any
situation where this wouldn't be safe, and this avoids having to play
whack-a-mole in the future of trying to work around port validation.

Signed-off-by: Lyude Paul 
Fixes: 263efde31f97 ("drm/dp/mst: Get validated port ref in 
drm_dp_update_payload_part1()")
Reported-by: Jerry Zuo 
Cc: Jerry Zuo 
Cc: Harry Wentland 
Cc:  # v4.6+
Reviewed-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-ly...@redhat.com
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c8c83f84aced..9d94c306c8ca 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -982,9 +982,20 @@ static struct drm_dp_mst_port 
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
 static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
 {
struct drm_dp_mst_port *rport = NULL;
+
mutex_lock(>lock);
-   if (mgr->mst_primary)
-   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary, port);
+   /*
+* Port may or may not be 'valid' but we don't care about that when
+* destroying the port and we are guaranteed that the port pointer
+* will be valid until we've finished
+*/
+   if (current_work() == >destroy_connector_work) {
+   kref_get(>kref);
+   rport = port;
+   } else if (mgr->mst_primary) {
+   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary,
+  port);
+   }
mutex_unlock(>lock);
return rport;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.14 002/371] drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 09c4b49457434fa74749ad6194ef28464d9f5df9 ]

This doesn't affect runtime because in the current code "idx" is always
valid.

First, we read from "vgdev->capsets[idx].max_size" before checking
whether "idx" is within bounds.  And secondly the bounds check is off by
one so we could end up reading one element beyond the end of the
vgdev->capsets[] array.

Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
Signed-off-by: Dan Carpenter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20180704094250.m7sgvvzg3dhcvv3h@kili.mountain
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 21c2de81f3e3..a3be65e689fd 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -648,11 +648,11 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
 {
struct virtio_gpu_get_capset *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
-   int max_size = vgdev->capsets[idx].max_size;
+   int max_size;
struct virtio_gpu_drv_cap_cache *cache_ent;
void *resp_buf;
 
-   if (idx > vgdev->num_capsets)
+   if (idx >= vgdev->num_capsets)
return -EINVAL;
 
if (version > vgdev->capsets[idx].max_version)
@@ -662,6 +662,7 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
if (!cache_ent)
return -ENOMEM;
 
+   max_size = vgdev->capsets[idx].max_size;
cache_ent->caps_cache = kmalloc(max_size, GFP_KERNEL);
if (!cache_ent->caps_cache) {
kfree(cache_ent);
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 659/671] drm/radeon: fix bad DMA from INTERRUPT_CNTL2

2020-01-16 Thread Sasha Levin
From: Sam Bobroff 

[ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]

The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address.  This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).

Instead, use the DMA address of the dummy page because it will always
be safe.

Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx 
chips (v3)")
Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/radeon/cik.c  | 4 ++--
 drivers/gpu/drm/radeon/r600.c | 4 ++--
 drivers/gpu/drm/radeon/si.c   | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index ebce4601a305..827d551962d9 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -6965,8 +6965,8 @@ static int cik_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* XXX this should actually be a bus address, not an MC address. same 
on older asics */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e06e2d8feab3..a724bb87cfad 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3690,8 +3690,8 @@ int r600_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
diff --git a/drivers/gpu/drm/radeon/si.c b/drivers/gpu/drm/radeon/si.c
index 85c604d29235..639f0698f961 100644
--- a/drivers/gpu/drm/radeon/si.c
+++ b/drivers/gpu/drm/radeon/si.c
@@ -5993,8 +5993,8 @@ static int si_irq_init(struct radeon_device *rdev)
}
 
/* setup interrupt control */
-   /* set dummy read address to ring address */
-   WREG32(INTERRUPT_CNTL2, rdev->ih.gpu_addr >> 8);
+   /* set dummy read address to dummy page address */
+   WREG32(INTERRUPT_CNTL2, rdev->dummy_page.addr >> 8);
interrupt_cntl = RREG32(INTERRUPT_CNTL);
/* IH_DUMMY_RD_OVERRIDE=0 - dummy read disabled with msi, enabled 
without msi
 * IH_DUMMY_RD_OVERRIDE=1 - dummy read controlled by IH_DUMMY_RD_EN
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 610/671] drm: panel-lvds: Potential Oops in probe error handling

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit fb2ee9bf084bcaeff1e5be100decc0eacb4af2d5 ]

The "lvds->backlight" pointer could be NULL in situations where
of_parse_phandle() returns NULL.  This code is cleaner if we use the
managed devm_of_find_backlight() so the clean up is automatic.

Fixes: 7c9dff5bd643 ("drm: panels: Add LVDS panel driver")
Signed-off-by: Dan Carpenter 
Signed-off-by: Sam Ravnborg 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190911104928.GA15930@mwanda
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/panel/panel-lvds.c | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-lvds.c 
b/drivers/gpu/drm/panel/panel-lvds.c
index 8a1687887ae9..bd704a36c5d0 100644
--- a/drivers/gpu/drm/panel/panel-lvds.c
+++ b/drivers/gpu/drm/panel/panel-lvds.c
@@ -199,7 +199,6 @@ static int panel_lvds_parse_dt(struct panel_lvds *lvds)
 static int panel_lvds_probe(struct platform_device *pdev)
 {
struct panel_lvds *lvds;
-   struct device_node *np;
int ret;
 
lvds = devm_kzalloc(>dev, sizeof(*lvds), GFP_KERNEL);
@@ -245,14 +244,9 @@ static int panel_lvds_probe(struct platform_device *pdev)
return ret;
}
 
-   np = of_parse_phandle(lvds->dev->of_node, "backlight", 0);
-   if (np) {
-   lvds->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
-
-   if (!lvds->backlight)
-   return -EPROBE_DEFER;
-   }
+   lvds->backlight = devm_of_find_backlight(lvds->dev);
+   if (IS_ERR(lvds->backlight))
+   return PTR_ERR(lvds->backlight);
 
/*
 * TODO: Handle all power supplies specified in the DT node in a generic
@@ -268,14 +262,10 @@ static int panel_lvds_probe(struct platform_device *pdev)
 
ret = drm_panel_add(>panel);
if (ret < 0)
-   goto error;
+   return ret;
 
dev_set_drvdata(lvds->dev, lvds);
return 0;
-
-error:
-   put_device(>backlight->dev);
-   return ret;
 }
 
 static int panel_lvds_remove(struct platform_device *pdev)
@@ -286,9 +276,6 @@ static int panel_lvds_remove(struct platform_device *pdev)
 
panel_lvds_disable(>panel);
 
-   if (lvds->backlight)
-   put_device(>backlight->dev);
-
return 0;
 }
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 595/671] drm/msm/dsi: Implement reset correctly

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit 78e31c42261779a01bc73472d0f65f15378e9de3 ]

On msm8998, vblank timeouts are observed because the DSI controller is not
reset properly, which ends up stalling the MDP.  This is because the reset
logic is not correct per the hardware documentation.

The documentation states that after asserting reset, software should wait
some time (no indication of how long), or poll the status register until it
returns 0 before deasserting reset.

wmb() is insufficient for this purpose since it just ensures ordering, not
timing between writes.  Since asserting and deasserting reset occurs on the
same register, ordering is already guaranteed by the architecture, making
the wmb extraneous.

Since we would define a timeout for polling the status register to avoid a
possible infinite loop, lets just use a static delay of 20 ms, since 16.666
ms is the time available to process one frame at 60 fps.

Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support")
Cc: Hai Li 
Cc: Rob Clark 
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Sean Paul 
[seanpaul renamed RESET_DELAY to DSI_RESET_TOGGLE_DELAY_MS]
Signed-off-by: Sean Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20191011133939.16551-1-jeffrey.l.h...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index cc4ea5502d6c..3b78bca0bb4d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -34,6 +34,8 @@
 #include "dsi_cfg.h"
 #include "msm_kms.h"
 
+#define DSI_RESET_TOGGLE_DELAY_MS 20
+
 static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
 {
u32 ver;
@@ -994,7 +996,7 @@ static void dsi_sw_reset(struct msm_dsi_host *msm_host)
wmb(); /* clocks need to be enabled before reset */
 
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb(); /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
 }
 
@@ -1402,7 +1404,7 @@ static void dsi_sw_reset_restore(struct msm_dsi_host 
*msm_host)
 
/* dsi controller can only be reset while clocks are running */
dsi_write(msm_host, REG_DSI_RESET, 1);
-   wmb();  /* make sure reset happen */
+   msleep(DSI_RESET_TOGGLE_DELAY_MS); /* make sure reset happen */
dsi_write(msm_host, REG_DSI_RESET, 0);
wmb();  /* controller out of reset */
dsi_write(msm_host, REG_DSI_CTRL, data0);
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 496/671] drm: rcar-du: lvds: Fix bridge_to_rcar_lvds

2020-01-16 Thread Sasha Levin
From: Fabrizio Castro 

[ Upstream commit 0b936e6122738f4cf474d1f3ff636cba0edc8b94 ]

Using name "bridge" for macro bridge_to_rcar_lvds argument doesn't
work when the pointer name used by the caller is not "bridge".
Rename the argument to "b" to allow for any pointer name.

While at it, fix the connector_to_rcar_lvds macro similarly.

Fixes: c6a27fa41fab ("drm: rcar-du: Convert LVDS encoder code to bridge driver")
Signed-off-by: Fabrizio Castro 
Reviewed-by: Laurent Pinchart 
[Fix connector_to_rcar_lvds]
Signed-off-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c 
b/drivers/gpu/drm/rcar-du/rcar_lvds.c
index 4c39de3f4f0f..b6dc91cdff68 100644
--- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -59,11 +59,11 @@ struct rcar_lvds {
enum rcar_lvds_mode mode;
 };
 
-#define bridge_to_rcar_lvds(bridge) \
-   container_of(bridge, struct rcar_lvds, bridge)
+#define bridge_to_rcar_lvds(b) \
+   container_of(b, struct rcar_lvds, bridge)
 
-#define connector_to_rcar_lvds(connector) \
-   container_of(connector, struct rcar_lvds, connector)
+#define connector_to_rcar_lvds(c) \
+   container_of(c, struct rcar_lvds, connector)
 
 static void rcar_lvds_write(struct rcar_lvds *lvds, u32 reg, u32 data)
 {
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 465/671] drm/panel: make drm_panel.h self-contained

2020-01-16 Thread Sasha Levin
From: Jani Nikula 

[ Upstream commit bf3f5e98559360661a3d2af340d46522512c0b00 ]

Fix build warning if drm_panel.h is built with CONFIG_OF=n or
CONFIG_DRM_PANEL=n and included without the prerequisite err.h:

./include/drm/drm_panel.h: In function ‘of_drm_find_panel’:
./include/drm/drm_panel.h:203:9: error: implicit declaration of function 
‘ERR_PTR’ [-Werror=implicit-function-declaration]
  return ERR_PTR(-ENODEV);
 ^~~
./include/drm/drm_panel.h:203:9: error: returning ‘int’ from a function with 
return type ‘struct drm_panel *’ makes pointer from integer without a cast 
[-Werror=int-conversion]
  return ERR_PTR(-ENODEV);
 ^~~~

Fixes: 5fa8e4a22182 ("drm/panel: Make of_drm_find_panel() return an ERR_PTR() 
instead of NULL")
Signed-off-by: Jani Nikula 
Acked-by: Thierry Reding 
Reviewed-by: Sam Ravnborg 
Reviewed-by: Sean Paul 
Cc: Boris Brezillon 
Signed-off-by: Sam Ravnborg 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190718161507.2047-2-...@ravnborg.org
Signed-off-by: Sasha Levin 
---
 include/drm/drm_panel.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 777814755fa6..675aa1e876ce 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -24,6 +24,7 @@
 #ifndef __DRM_PANEL_H__
 #define __DRM_PANEL_H__
 
+#include 
 #include 
 #include 
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 430/671] drm/msm/a3xx: remove TPL1 regs from snapshot

2020-01-16 Thread Sasha Levin
From: Rob Clark 

[ Upstream commit f47bee2ba447bebc304111c16ef1e1a73a9744dd ]

These regs are write-only, and the hw throws a hissy-fit (ie. reboots)
when we try to read them for GPU state snapshot, in response to a GPU
hang.  It is rather impolite when GPU recovery triggers an insta-
reboot, so lets remove the TPL1 registers from the snapshot.

Fixes: 7198e6b03155 drm/msm: add a3xx gpu support
Signed-off-by: Rob Clark 
Reviewed-by: Jordan Crouse 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 669c2d4b070d..5c068301d817 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -395,19 +395,17 @@ static const unsigned int a3xx_registers[] = {
0x2200, 0x2212, 0x2214, 0x2217, 0x221a, 0x221a, 0x2240, 0x227e,
0x2280, 0x228b, 0x22c0, 0x22c0, 0x22c4, 0x22ce, 0x22d0, 0x22d8,
0x22df, 0x22e6, 0x22e8, 0x22e9, 0x22ec, 0x22ec, 0x22f0, 0x22f7,
-   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2348, 0x2349, 0x2350, 0x2356,
-   0x2360, 0x2360, 0x2440, 0x2440, 0x2444, 0x2444, 0x2448, 0x244d,
-   0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470, 0x2472, 0x2472,
-   0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3, 0x24e4, 0x24ef,
-   0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e, 0x2510, 0x2511,
-   0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea, 0x25ec, 0x25ed,
-   0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617, 0x261a, 0x261a,
-   0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0, 0x26c4, 0x26ce,
-   0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9, 0x26ec, 0x26ec,
-   0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743, 0x2748, 0x2749,
-   0x2750, 0x2756, 0x2760, 0x2760, 0x300c, 0x300e, 0x301c, 0x301d,
-   0x302a, 0x302a, 0x302c, 0x302d, 0x3030, 0x3031, 0x3034, 0x3036,
-   0x303c, 0x303c, 0x305e, 0x305f,
+   0x22ff, 0x22ff, 0x2340, 0x2343, 0x2440, 0x2440, 0x2444, 0x2444,
+   0x2448, 0x244d, 0x2468, 0x2469, 0x246c, 0x246d, 0x2470, 0x2470,
+   0x2472, 0x2472, 0x2474, 0x2475, 0x2479, 0x247a, 0x24c0, 0x24d3,
+   0x24e4, 0x24ef, 0x2500, 0x2509, 0x250c, 0x250c, 0x250e, 0x250e,
+   0x2510, 0x2511, 0x2514, 0x2515, 0x25e4, 0x25e4, 0x25ea, 0x25ea,
+   0x25ec, 0x25ed, 0x25f0, 0x25f0, 0x2600, 0x2612, 0x2614, 0x2617,
+   0x261a, 0x261a, 0x2640, 0x267e, 0x2680, 0x268b, 0x26c0, 0x26c0,
+   0x26c4, 0x26ce, 0x26d0, 0x26d8, 0x26df, 0x26e6, 0x26e8, 0x26e9,
+   0x26ec, 0x26ec, 0x26f0, 0x26f7, 0x26ff, 0x26ff, 0x2740, 0x2743,
+   0x300c, 0x300e, 0x301c, 0x301d, 0x302a, 0x302a, 0x302c, 0x302d,
+   0x3030, 0x3031, 0x3034, 0x3036, 0x303c, 0x303c, 0x305e, 0x305f,
~0   /* sentinel */
 };
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 419/671] drm/msm/mdp5: Fix mdp5_cfg_init error return

2020-01-16 Thread Sasha Levin
From: Jeffrey Hugo 

[ Upstream commit fc19cbb785d7bbd1a1af26229b5240a3ab332744 ]

If mdp5_cfg_init fails because of an unknown major version, a null pointer
dereference occurs.  This is because the caller of init expects error
pointers, but init returns NULL on error.  Fix this by returning the
expected values on error.

Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module)
Signed-off-by: Jeffrey Hugo 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
index 824067d2d427..42f0ecb0cf35 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c
@@ -635,7 +635,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms 
*mdp5_kms,
if (cfg_handler)
mdp5_cfg_destroy(cfg_handler);
 
-   return NULL;
+   return ERR_PTR(ret);
 }
 
 static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev)
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 438/671] backlight: pwm_bl: Fix heuristic to determine number of brightness levels

2020-01-16 Thread Sasha Levin
From: Matthias Kaehlcke 

[ Upstream commit 73fbfc499448455f1e1c77717040e09e25f1d976 ]

With commit 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of
LED linearly to human eye") the number of set bits (aka hweight())
in the PWM period is used in the heuristic to determine the number
of brightness levels, when the brightness table isn't specified in
the DT. The number of set bits doesn't provide a reliable clue about
the length of the period, instead change the heuristic to:

 nlevels = period / fls(period)

Also limit the maximum number of brightness levels to 4096 to avoid
excessively large tables.

With this the number of levels increases monotonically with the PWM
period, until the maximum of 4096 levels is reached:

period (ns)# levels

10016
50062
1000   111
5000   416
1  769
5  
10 4096

Fixes: 88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly to 
human eye")
Signed-off-by: Matthias Kaehlcke 
Acked-by: Daniel Thompson 
Tested-by: Enric Balletbo i Serra 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/video/backlight/pwm_bl.c | 24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 7ddc0930e98c..3a3098d4873b 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -199,29 +199,17 @@ int pwm_backlight_brightness_default(struct device *dev,
 struct platform_pwm_backlight_data *data,
 unsigned int period)
 {
-   unsigned int counter = 0;
-   unsigned int i, n;
+   unsigned int i;
u64 retval;
 
/*
-* Count the number of bits needed to represent the period number. The
-* number of bits is used to calculate the number of levels used for the
-* brightness-levels table, the purpose of this calculation is have a
-* pre-computed table with enough levels to get linear brightness
-* perception. The period is divided by the number of bits so for a
-* 8-bit PWM we have 255 / 8 = 32 brightness levels or for a 16-bit PWM
-* we have 65535 / 16 = 4096 brightness levels.
-*
-* Note that this method is based on empirical testing on different
-* devices with PWM of 8 and 16 bits of resolution.
+* Once we have 4096 levels there's little point going much higher...
+* neither interactive sliders nor animation benefits from having
+* more values in the table.
 */
-   n = period;
-   while (n) {
-   counter += n % 2;
-   n >>= 1;
-   }
+   data->max_brightness =
+   min((int)DIV_ROUND_UP(period, fls(period)), 4096);
 
-   data->max_brightness = DIV_ROUND_UP(period, counter);
data->levels = devm_kcalloc(dev, data->max_brightness,
sizeof(*data->levels), GFP_KERNEL);
if (!data->levels)
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 356/671] backlight: lm3630a: Return 0 on success in update_status functions

2020-01-16 Thread Sasha Levin
From: Brian Masney 

[ Upstream commit d3f48ec0954c6aac736ab21c34a35d7554409112 ]

lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status()
both return the brightness value if the brightness was successfully
updated. Writing to these attributes via sysfs would cause a 'Bad
address' error to be returned. These functions should return 0 on
success, so let's change it to correct that error.

Fixes: 28e64a68a2ef ("backlight: lm3630: apply chip revision")
Signed-off-by: Brian Masney 
Acked-by: Pavel Machek 
Acked-by: Daniel Thompson 
Signed-off-by: Lee Jones 
Signed-off-by: Sasha Levin 
---
 drivers/video/backlight/lm3630a_bl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/lm3630a_bl.c 
b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..ef2553f452ca 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -201,7 +201,7 @@ static int lm3630a_bank_a_update_status(struct 
backlight_device *bl)
  LM3630A_LEDA_ENABLE, LM3630A_LEDA_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access\n");
@@ -278,7 +278,7 @@ static int lm3630a_bank_b_update_status(struct 
backlight_device *bl)
  LM3630A_LEDB_ENABLE, LM3630A_LEDB_ENABLE);
if (ret < 0)
goto out_i2c_err;
-   return bl->props.brightness;
+   return 0;
 
 out_i2c_err:
dev_err(pchip->dev, "i2c failed to access REG_CTRL\n");
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 281/671] drm/vmwgfx: Remove set but not used variable 'restart'

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit b2130cca9c8db5073b71d832da2a6c8311a8f3bb ]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_work_func':
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:514:7: warning:
 variable 'restart' set but not used [-Wunused-but-set-variable]

It not used any more after commit dc366364c4ef ("drm/vmwgfx: Fix multiple
command buffer context use")

Signed-off-by: YueHaibing 
Reviewed-by: Deepak Rawat 
Signed-off-by: Deepak Rawat 
Fixes: dc366364c4ef ("drm/vmwgfx: Fix multiple command buffer context use")
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index e7e4655d3f36..ce1ad7cd7899 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -511,17 +511,14 @@ static void vmw_cmdbuf_work_func(struct work_struct *work)
container_of(work, struct vmw_cmdbuf_man, work);
struct vmw_cmdbuf_header *entry, *next;
uint32_t dummy;
-   bool restart[SVGA_CB_CONTEXT_MAX];
bool send_fence = false;
struct list_head restart_head[SVGA_CB_CONTEXT_MAX];
int i;
struct vmw_cmdbuf_context *ctx;
bool global_block = false;
 
-   for_each_cmdbuf_ctx(man, i, ctx) {
+   for_each_cmdbuf_ctx(man, i, ctx)
INIT_LIST_HEAD(_head[i]);
-   restart[i] = false;
-   }
 
mutex_lock(>error_mutex);
spin_lock(>lock);
@@ -533,7 +530,6 @@ static void vmw_cmdbuf_work_func(struct work_struct *work)
const char *cmd_name;
 
list_del_init(>list);
-   restart[entry->cb_context] = true;
global_block = true;
 
if (!vmw_cmd_describe(header, _cmd_size, _name)) {
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 275/671] drm/fb-helper: generic: Call drm_client_add() after setup is done

2020-01-16 Thread Sasha Levin
From: Noralf Trønnes 

[ Upstream commit 6e3f17ee73f7e3c2ef0e2c8fd8624b2ece8ef2c9 ]

Hotplug can happen while drm_fbdev_generic_setup() is running so move
drm_client_add() call after setup is done to avoid
drm_fbdev_client_hotplug() running in two threads at the same time.

Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation")
Cc: sta...@vger.kernel.org
Reported-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190401141358.25309-1-nor...@tronnes.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_fb_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1c87ad6667e7..da9a381d6b57 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -3257,8 +3257,6 @@ int drm_fbdev_generic_setup(struct drm_device *dev, 
unsigned int preferred_bpp)
return ret;
}
 
-   drm_client_add(_helper->client);
-
if (!preferred_bpp)
preferred_bpp = dev->mode_config.preferred_depth;
if (!preferred_bpp)
@@ -3267,6 +3265,8 @@ int drm_fbdev_generic_setup(struct drm_device *dev, 
unsigned int preferred_bpp)
 
drm_fbdev_client_hotplug(_helper->client);
 
+   drm_client_add(_helper->client);
+
return 0;
 }
 EXPORT_SYMBOL(drm_fbdev_generic_setup);
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 270/671] spi: tegra114: configure dma burst size to fifo trig level

2020-01-16 Thread Sasha Levin
From: Sowjanya Komatineni 

[ Upstream commit f4ce428c41fb22e3ed55496dded94df44cb920fa ]

Fixes: Configure DMA burst size to be same as SPI TX/RX trigger levels
to avoid mismatch.

SPI FIFO trigger levels are calculated based on the transfer length.
So this patch moves DMA slave configuration to happen before start
of DMAs.

Signed-off-by: Sowjanya Komatineni 
Signed-off-by: Mark Brown 
Signed-off-by: Sasha Levin 
---
 drivers/spi/spi-tegra114.c | 52 ++
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 5114b8008472..09cfae3abce2 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -529,6 +529,8 @@ static int tegra_spi_start_dma_based_transfer(
u32 val;
unsigned int len;
int ret = 0;
+   u8 dma_burst;
+   struct dma_slave_config dma_sconfig = {0};
 
val = SPI_DMA_BLK_SET(tspi->curr_dma_words - 1);
tegra_spi_writel(tspi, val, SPI_DMA_BLK);
@@ -540,12 +542,16 @@ static int tegra_spi_start_dma_based_transfer(
len = tspi->curr_dma_words * 4;
 
/* Set attention level based on length of transfer */
-   if (len & 0xF)
+   if (len & 0xF) {
val |= SPI_TX_TRIG_1 | SPI_RX_TRIG_1;
-   else if (((len) >> 4) & 0x1)
+   dma_burst = 1;
+   } else if (((len) >> 4) & 0x1) {
val |= SPI_TX_TRIG_4 | SPI_RX_TRIG_4;
-   else
+   dma_burst = 4;
+   } else {
val |= SPI_TX_TRIG_8 | SPI_RX_TRIG_8;
+   dma_burst = 8;
+   }
 
if (tspi->cur_direction & DATA_DIR_TX)
val |= SPI_IE_TX;
@@ -556,7 +562,18 @@ static int tegra_spi_start_dma_based_transfer(
tegra_spi_writel(tspi, val, SPI_DMA_CTL);
tspi->dma_control_reg = val;
 
+   dma_sconfig.device_fc = true;
if (tspi->cur_direction & DATA_DIR_TX) {
+   dma_sconfig.dst_addr = tspi->phys + SPI_TX_FIFO;
+   dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   dma_sconfig.dst_maxburst = dma_burst;
+   ret = dmaengine_slave_config(tspi->tx_dma_chan, _sconfig);
+   if (ret < 0) {
+   dev_err(tspi->dev,
+   "DMA slave config failed: %d\n", ret);
+   return ret;
+   }
+
tegra_spi_copy_client_txbuf_to_spi_txbuf(tspi, t);
ret = tegra_spi_start_tx_dma(tspi, len);
if (ret < 0) {
@@ -567,6 +584,16 @@ static int tegra_spi_start_dma_based_transfer(
}
 
if (tspi->cur_direction & DATA_DIR_RX) {
+   dma_sconfig.src_addr = tspi->phys + SPI_RX_FIFO;
+   dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
+   dma_sconfig.src_maxburst = dma_burst;
+   ret = dmaengine_slave_config(tspi->rx_dma_chan, _sconfig);
+   if (ret < 0) {
+   dev_err(tspi->dev,
+   "DMA slave config failed: %d\n", ret);
+   return ret;
+   }
+
/* Make the dma buffer to read by dma */
dma_sync_single_for_device(tspi->dev, tspi->rx_dma_phys,
tspi->dma_buf_size, DMA_FROM_DEVICE);
@@ -626,7 +653,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data 
*tspi,
u32 *dma_buf;
dma_addr_t dma_phys;
int ret;
-   struct dma_slave_config dma_sconfig;
 
dma_chan = dma_request_slave_channel_reason(tspi->dev,
dma_to_memory ? "rx" : "tx");
@@ -646,19 +672,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data 
*tspi,
return -ENOMEM;
}
 
-   if (dma_to_memory) {
-   dma_sconfig.src_addr = tspi->phys + SPI_RX_FIFO;
-   dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   dma_sconfig.src_maxburst = 0;
-   } else {
-   dma_sconfig.dst_addr = tspi->phys + SPI_TX_FIFO;
-   dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   dma_sconfig.dst_maxburst = 0;
-   }
-
-   ret = dmaengine_slave_config(dma_chan, _sconfig);
-   if (ret)
-   goto scrub;
if (dma_to_memory) {
tspi->rx_dma_chan = dma_chan;
tspi->rx_dma_buf = dma_buf;
@@ -669,11 +682,6 @@ static int tegra_spi_init_dma_param(struct tegra_spi_data 
*tspi,
tspi->tx_dma_phys = dma_phys;
}
return 0;
-
-scrub:
-   dma_free_coherent(tspi->dev, tspi->dma_buf_size, dma_buf, dma_phys);
-   dma_release_channel(dma_chan);
-   return ret;
 }
 
 static void tegra_spi_deinit_dma_param(struct tegra_spi_data *tspi,
-- 
2.20.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH AUTOSEL 4.19 202/671] drm/nouveau/bios/ramcfg: fix missing parentheses when calculating RON

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 13649101a25c53c87f4ab98a076dfe61f3636ab1 ]

Currently, the expression for calculating RON is always going to result
in zero no matter the value of ram->mr[1] because the ! operator has
higher precedence than the shift >> operator.  I believe the missing
parentheses around the expression before appying the ! operator will
result in the desired result.

[ Note, not tested ]

Detected by CoveritScan, CID#1324005 ("Operands don't affect result")

Fixes: c25bf7b6155c ("drm/nouveau/bios/ramcfg: Separate out RON pull value")
Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
index 60ece0a8a2e1..1d2d6bae73cd 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/gddr3.c
@@ -87,7 +87,7 @@ nvkm_gddr3_calc(struct nvkm_ram *ram)
WR  = (ram->next->bios.timing[2] & 0x007f) >> 16;
/* XXX: Get these values from the VBIOS instead */
DLL = !(ram->mr[1] & 0x1);
-   RON = !(ram->mr[1] & 0x300) >> 8;
+   RON = !((ram->mr[1] & 0x300) >> 8);
break;
default:
return -ENOSYS;
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 203/671] drm/nouveau/pmu: don't print reply values if exec is false

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit b1d03fc36ec9834465a08c275c8d563e07f6f6bf ]

Currently the uninitialized values in the array reply are printed out
when exec is false and nvkm_pmu_send has not updated the array. Avoid
confusion by only dumping out these values if they have been actually
updated.

Detected by CoverityScan, CID#1271291 ("Uninitialized scaler variable")
Fixes: ebb58dc2ef8c ("drm/nouveau/pmu: rename from pwr (no binary change)")

Signed-off-by: Colin Ian King 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
index 11b28b086a06..7b052879af72 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pmu/memx.c
@@ -88,10 +88,10 @@ nvkm_memx_fini(struct nvkm_memx **pmemx, bool exec)
if (exec) {
nvkm_pmu_send(pmu, reply, PROC_MEMX, MEMX_MSG_EXEC,
  memx->base, finish);
+   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
+  reply[0], reply[1]);
}
 
-   nvkm_debug(subdev, "Exec took %uns, PMU_IN %08x\n",
-  reply[0], reply[1]);
kfree(memx);
return 0;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 204/671] drm/nouveau: fix missing break in switch statement

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 785cf1eeafa23ec63f426d322401054d13abe2a3 ]

The NOUVEAU_GETPARAM_PCI_DEVICE case is missing a break statement and falls
through to the following NOUVEAU_GETPARAM_BUS_TYPE case and may end up
re-assigning the getparam->value to an undesired value. Fix this by adding
in the missing break.

Detected by CoverityScan, CID#1460507 ("Missing break in switch")

Fixes: 359088d5b8ec ("drm/nouveau: remove trivial cases of nvxx_device() usage")
Signed-off-by: Colin Ian King 
Reviewed-by: Gustavo A. R. Silva 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index e67a471331b5..6ec745873bc5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -214,6 +214,7 @@ nouveau_abi16_ioctl_getparam(ABI16_IOCTL_ARGS)
WARN_ON(1);
break;
}
+   break;
case NOUVEAU_GETPARAM_FB_SIZE:
getparam->value = drm->gem.vram_available;
break;
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 171/671] drm/etnaviv: potential NULL dereference

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 9e05352340d3a3e68c144136db9810b26ebb88c3 ]

The etnaviv_gem_prime_get_sg_table() is supposed to return error
pointers.  Otherwise it can lead to a NULL dereference when it's called
from drm_gem_map_dma_buf().

Fixes: 5f4a4a73f437 ("drm/etnaviv: fix gem_prime_get_sg_table to return new SG 
table")
Signed-off-by: Dan Carpenter 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c 
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 0566171f8df2..f21529e635e3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -15,7 +15,7 @@ struct sg_table *etnaviv_gem_prime_get_sg_table(struct 
drm_gem_object *obj)
int npages = obj->size >> PAGE_SHIFT;
 
if (WARN_ON(!etnaviv_obj->pages))  /* should have already pinned! */
-   return NULL;
+   return ERR_PTR(-EINVAL);
 
return drm_prime_pages_to_sg(etnaviv_obj->pages, npages);
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 152/671] drm/xen-front: Fix mmap attributes for display buffers

2020-01-16 Thread Sasha Levin
From: Oleksandr Andrushchenko 

[ Upstream commit 24ded292a5c2ed476f01c77fee65f8320552cd27 ]

When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")

Signed-off-by: Oleksandr Andrushchenko 
Suggested-by: Julien Grall 
Acked-by: Julien Grall 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190129150422.19867-1-andr2...@gmail.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/xen/xen_drm_front_gem.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/xen/xen_drm_front_gem.c 
b/drivers/gpu/drm/xen/xen_drm_front_gem.c
index c85bfe7571cb..802662839e7e 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_gem.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_gem.c
@@ -236,8 +236,14 @@ static int gem_mmap_obj(struct xen_gem_object *xen_obj,
vma->vm_flags &= ~VM_PFNMAP;
vma->vm_flags |= VM_MIXEDMAP;
vma->vm_pgoff = 0;
-   vma->vm_page_prot =
-   pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+   /*
+* According to Xen on ARM ABI (xen/include/public/arch-arm.h):
+* all memory which is shared with other entities in the system
+* (including the hypervisor and other guests) must reside in memory
+* which is mapped as Normal Inner Write-Back Outer Write-Back
+* Inner-Shareable.
+*/
+   vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
 
/*
 * vm_operations_struct.fault handler will be called if CPU access
@@ -283,8 +289,9 @@ void *xen_drm_front_gem_prime_vmap(struct drm_gem_object 
*gem_obj)
if (!xen_obj->pages)
return NULL;
 
+   /* Please see comment in gem_mmap_obj on mapping and attributes. */
return vmap(xen_obj->pages, xen_obj->num_pages,
-   VM_MAP, pgprot_writecombine(PAGE_KERNEL));
+   VM_MAP, PAGE_KERNEL);
 }
 
 void xen_drm_front_gem_prime_vunmap(struct drm_gem_object *gem_obj,
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 166/671] fbdev: chipsfb: remove set but not used variable 'size'

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 8e71fa5e4d86bedfd26df85381d65d6b4c860020 ]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/video/fbdev/chipsfb.c: In function 'chipsfb_pci_init':
drivers/video/fbdev/chipsfb.c:352:22: warning:
 variable 'size' set but not used [-Wunused-but-set-variable]

Fixes: 8c8709334cec ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK").
Signed-off-by: YueHaibing 
Acked-by: Michael Ellerman 
Cc: Daniel Vetter 
Cc: Christophe Leroy 
[b.zolnierkie: minor commit summary and description fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/chipsfb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/chipsfb.c b/drivers/video/fbdev/chipsfb.c
index f103665cad43..f9b366d17587 100644
--- a/drivers/video/fbdev/chipsfb.c
+++ b/drivers/video/fbdev/chipsfb.c
@@ -350,7 +350,7 @@ static void init_chips(struct fb_info *p, unsigned long 
addr)
 static int chipsfb_pci_init(struct pci_dev *dp, const struct pci_device_id 
*ent)
 {
struct fb_info *p;
-   unsigned long addr, size;
+   unsigned long addr;
unsigned short cmd;
int rc = -ENODEV;
 
@@ -362,7 +362,6 @@ static int chipsfb_pci_init(struct pci_dev *dp, const 
struct pci_device_id *ent)
if ((dp->resource[0].flags & IORESOURCE_MEM) == 0)
goto err_disable;
addr = pci_resource_start(dp, 0);
-   size = pci_resource_len(dp, 0);
if (addr == 0)
goto err_disable;
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 106/671] drm/fb-helper: generic: Fix setup error path

2020-01-16 Thread Sasha Levin
From: Noralf Trønnes 

[ Upstream commit 6e1490cf439aa86b104e5124c36275b964238e1f ]

If register_framebuffer() fails during fbdev setup we will leak the
framebuffer, the GEM buffer and the shadow buffer for defio. This is
because drm_fb_helper_fbdev_setup() just calls drm_fb_helper_fini() on
error not taking into account that register_framebuffer() can fail.

Since the generic emulation uses DRM client for its framebuffer and
backing buffer in addition to a shadow buffer, it's necessary to open code
drm_fb_helper_fbdev_setup() to properly handle the error path.

Error cleanup is removed from .fb_probe and is handled by one function for
all paths.

Fixes: 9060d7f49376 ("drm/fb-helper: Finish the generic fbdev emulation")
Reported-by: Peter Wu 
Signed-off-by: Noralf Trønnes 
Acked-by: Gerd Hoffmann 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20190105181846.26495-1-nor...@tronnes.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_fb_helper.c | 98 +++--
 1 file changed, 58 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f57fc1450b61..1c87ad6667e7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2979,18 +2979,16 @@ static int drm_fbdev_fb_release(struct fb_info *info, 
int user)
return 0;
 }
 
-/*
- * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
- * unregister_framebuffer() or fb_release().
- */
-static void drm_fbdev_fb_destroy(struct fb_info *info)
+static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper)
 {
-   struct drm_fb_helper *fb_helper = info->par;
struct fb_info *fbi = fb_helper->fbdev;
struct fb_ops *fbops = NULL;
void *shadow = NULL;
 
-   if (fbi->fbdefio) {
+   if (!fb_helper->dev)
+   return;
+
+   if (fbi && fbi->fbdefio) {
fb_deferred_io_cleanup(fbi);
shadow = fbi->screen_buffer;
fbops = fbi->fbops;
@@ -3004,6 +3002,12 @@ static void drm_fbdev_fb_destroy(struct fb_info *info)
}
 
drm_client_framebuffer_delete(fb_helper->buffer);
+}
+
+static void drm_fbdev_release(struct drm_fb_helper *fb_helper)
+{
+   drm_fbdev_cleanup(fb_helper);
+
/*
 * FIXME:
 * Remove conditional when all CMA drivers have been moved over to using
@@ -3015,6 +3019,15 @@ static void drm_fbdev_fb_destroy(struct fb_info *info)
}
 }
 
+/*
+ * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
+ * unregister_framebuffer() or fb_release().
+ */
+static void drm_fbdev_fb_destroy(struct fb_info *info)
+{
+   drm_fbdev_release(info->par);
+}
+
 static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
 {
struct drm_fb_helper *fb_helper = info->par;
@@ -3065,7 +3078,6 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper 
*fb_helper,
struct drm_framebuffer *fb;
struct fb_info *fbi;
u32 format;
-   int ret;
 
DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d)\n",
  sizes->surface_width, sizes->surface_height,
@@ -3082,10 +3094,8 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper 
*fb_helper,
fb = buffer->fb;
 
fbi = drm_fb_helper_alloc_fbi(fb_helper);
-   if (IS_ERR(fbi)) {
-   ret = PTR_ERR(fbi);
-   goto err_free_buffer;
-   }
+   if (IS_ERR(fbi))
+   return PTR_ERR(fbi);
 
fbi->par = fb_helper;
fbi->fbops = _fbdev_fb_ops;
@@ -3116,8 +3126,7 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper 
*fb_helper,
if (!fbops || !shadow) {
kfree(fbops);
vfree(shadow);
-   ret = -ENOMEM;
-   goto err_fb_info_destroy;
+   return -ENOMEM;
}
 
*fbops = *fbi->fbops;
@@ -3129,13 +3138,6 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper 
*fb_helper,
}
 
return 0;
-
-err_fb_info_destroy:
-   drm_fb_helper_fini(fb_helper);
-err_free_buffer:
-   drm_client_framebuffer_delete(buffer);
-
-   return ret;
 }
 EXPORT_SYMBOL(drm_fb_helper_generic_probe);
 
@@ -3147,18 +3149,11 @@ static void drm_fbdev_client_unregister(struct 
drm_client_dev *client)
 {
struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
 
-   if (fb_helper->fbdev) {
-   drm_fb_helper_unregister_fbi(fb_helper);
+   if (fb_helper->fbdev)
/* drm_fbdev_fb_destroy() takes care of cleanup */
-   return;
-   }
-
-   /* Did drm_fb_helper_fbdev_setup() run? */
-   if (fb_helper->dev)
-   drm_fb_helper_fini(fb_helper);
-
-   drm_client_release(client);
-   kfree(fb_helper);
+   drm_fb_helper_unregister_fbi(fb_helper);
+   else
+   

[PATCH AUTOSEL 4.19 102/671] drm: Fix error handling in drm_legacy_addctx

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit c39191feed4540fed98badeb484833dcf659bb96 ]

'ctx->handle' is unsigned, it never less than zero.
This patch use int 'tmp_handle' to handle the err condition.

Fixes: 62968144e673 ("drm: convert drm context code to use Linux idr")
Signed-off-by: YueHaibing 
Signed-off-by: Daniel Vetter 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181229024907.12852-1-yuehaib...@huawei.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_context.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index f973d287696a..da5abf24f59f 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -361,23 +361,26 @@ int drm_legacy_addctx(struct drm_device *dev, void *data,
 {
struct drm_ctx_list *ctx_entry;
struct drm_ctx *ctx = data;
+   int tmp_handle;
 
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
return -EINVAL;
 
-   ctx->handle = drm_legacy_ctxbitmap_next(dev);
-   if (ctx->handle == DRM_KERNEL_CONTEXT) {
+   tmp_handle = drm_legacy_ctxbitmap_next(dev);
+   if (tmp_handle == DRM_KERNEL_CONTEXT) {
/* Skip kernel's context and get a new one. */
-   ctx->handle = drm_legacy_ctxbitmap_next(dev);
+   tmp_handle = drm_legacy_ctxbitmap_next(dev);
}
-   DRM_DEBUG("%d\n", ctx->handle);
-   if (ctx->handle < 0) {
+   DRM_DEBUG("%d\n", tmp_handle);
+   if (tmp_handle < 0) {
DRM_DEBUG("Not enough free contexts.\n");
/* Should this return -EBUSY instead? */
-   return -ENOMEM;
+   return tmp_handle;
}
 
+   ctx->handle = tmp_handle;
+
ctx_entry = kmalloc(sizeof(*ctx_entry), GFP_KERNEL);
if (!ctx_entry) {
DRM_DEBUG("out of memory\n");
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 105/671] drm/etnaviv: fix some off by one bugs

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit f5fd9fd4000984f19db689282054953981a50534 ]

The ->nr_signal is the supposed to be the number of elements in the
->signal array.  There was one place where it was 5 but it was supposed
to be 4.  That looks like a copy and paste bug.  There were also two
checks that were off by one.

Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
Signed-off-by: Dan Carpenter 
Reviewed-by: Christian Gmeiner 
Tested-by: Christian Gmeiner 
Signed-off-by: Lucas Stach 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 9980d81a26e3..4227a4006c34 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -113,7 +113,7 @@ static const struct etnaviv_pm_domain doms_3d[] = {
.name = "PE",
.profile_read = VIVS_MC_PROFILE_PE_READ,
.profile_config = VIVS_MC_PROFILE_CONFIG0,
-   .nr_signals = 5,
+   .nr_signals = 4,
.signal = (const struct etnaviv_pm_signal[]) {
{
"PIXEL_COUNT_KILLED_BY_COLOR_PIPE",
@@ -435,7 +435,7 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
 
dom = meta->domains + signal->domain;
 
-   if (signal->iter > dom->nr_signals)
+   if (signal->iter >= dom->nr_signals)
return -EINVAL;
 
sig = >signal[signal->iter];
@@ -461,7 +461,7 @@ int etnaviv_pm_req_validate(const struct 
drm_etnaviv_gem_submit_pmr *r,
 
dom = meta->domains + r->domain;
 
-   if (r->signal > dom->nr_signals)
+   if (r->signal >= dom->nr_signals)
return -EINVAL;
 
return 0;
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 111/671] drm/shmob: Fix return value check in shmob_drm_probe

2020-01-16 Thread Sasha Levin
From: YueHaibing 

[ Upstream commit 06c3bbd3c12737a50c2e981821b5585e1786e73d ]

In case of error, the function devm_ioremap_resource() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check should
be replaced with IS_ERR().

Fixes: 8f1597c8f1a5 ("drm: shmobile: Perform initialization/cleanup at 
probe/remove time")
Signed-off-by: YueHaibing 
Reviewed-by: Simon Horman 
Reviewed-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 592572554eb0..58d8a98c749b 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -233,8 +233,8 @@ static int shmob_drm_probe(struct platform_device *pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
sdev->mmio = devm_ioremap_resource(>dev, res);
-   if (sdev->mmio == NULL)
-   return -ENOMEM;
+   if (IS_ERR(sdev->mmio))
+   return PTR_ERR(sdev->mmio);
 
ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
if (ret < 0)
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 041/671] drm/sun4i: hdmi: Fix double flag assignation

2020-01-16 Thread Sasha Levin
From: Maxime Ripard 

[ Upstream commit 1e0ff648940e603cab6c52cf3723017d30d78f30 ]

The is_double flag is a boolean currently assigned to the value of the d
variable, that is either 1 or 2. It means that this is_double variable is
always set to true, even though the initial intent was to have it set to
true when d is 2.

Fix this.

Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Reported-by: Dan Carpenter 
Signed-off-by: Maxime Ripard 
Reviewed-by: Giulio Benetti 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181021163446.29135-2-maxime.rip...@bootlin.com
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c 
b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
index 3ecffa52c814..a74adec6c5dc 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c
@@ -52,7 +52,7 @@ static unsigned long sun4i_tmds_calc_divider(unsigned long 
rate,
(rate - tmp_rate) < (rate - best_rate)) {
best_rate = tmp_rate;
best_m = m;
-   is_double = d;
+   is_double = (d == 2) ? true : false;
}
}
}
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 056/671] drm/dp_mst: Skip validating ports during destruction, just ref

2020-01-16 Thread Sasha Levin
From: Lyude Paul 

[ Upstream commit c54c7374ff44de5e609506aca7c0deae4703b6d1 ]

Jerry Zuo pointed out a rather obscure hotplugging issue that it seems I
accidentally introduced into DRM two years ago.

Pretend we have a topology like this:

|- DP-1: mst_primary
   |- DP-4: active display
   |- DP-5: disconnected
   |- DP-6: active hub
  |- DP-7: active display
  |- DP-8: disconnected
  |- DP-9: disconnected

If we unplug DP-6, the topology starting at DP-7 will be destroyed but
it's payloads will live on in DP-1's VCPI allocations and thus require
removal. However, this removal currently fails because
drm_dp_update_payload_part1() will (rightly so) try to validate the port
before accessing it, fail then abort. If we keep going, eventually we
run the MST hub out of bandwidth and all new allocations will start to
fail (or in my case; all new displays just start flickering a ton).

We could just teach drm_dp_update_payload_part1() not to drop the port
ref in this case, but then we also need to teach
drm_dp_destroy_payload_step1() to do the same thing, then hope no one
ever adds anything to the that requires a validated port reference in
drm_dp_destroy_connector_work(). Kind of sketchy.

So let's go with a more clever solution: any port that
drm_dp_destroy_connector_work() interacts with is guaranteed to still
exist in memory until we say so. While said port might not be valid we
don't really care: that's the whole reason we're destroying it in the
first place! So, teach drm_dp_get_validated_port_ref() to use the all
mighty current_work() function to avoid attempting to validate ports
from the context of mgr->destroy_connector_work. I can't see any
situation where this wouldn't be safe, and this avoids having to play
whack-a-mole in the future of trying to work around port validation.

Signed-off-by: Lyude Paul 
Fixes: 263efde31f97 ("drm/dp/mst: Get validated port ref in 
drm_dp_update_payload_part1()")
Reported-by: Jerry Zuo 
Cc: Jerry Zuo 
Cc: Harry Wentland 
Cc:  # v4.6+
Reviewed-by: Dave Airlie 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20181113224613.28809-1-ly...@redhat.com
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 4d7715845306..58fe3945494c 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1022,9 +1022,20 @@ static struct drm_dp_mst_port 
*drm_dp_mst_get_port_ref_locked(struct drm_dp_mst_
 static struct drm_dp_mst_port *drm_dp_get_validated_port_ref(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port)
 {
struct drm_dp_mst_port *rport = NULL;
+
mutex_lock(>lock);
-   if (mgr->mst_primary)
-   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary, port);
+   /*
+* Port may or may not be 'valid' but we don't care about that when
+* destroying the port and we are guaranteed that the port pointer
+* will be valid until we've finished
+*/
+   if (current_work() == >destroy_connector_work) {
+   kref_get(>kref);
+   rport = port;
+   } else if (mgr->mst_primary) {
+   rport = drm_dp_mst_get_port_ref_locked(mgr->mst_primary,
+  port);
+   }
mutex_unlock(>lock);
return rport;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 054/671] drm: rcar-du: Fix vblank initialization

2020-01-16 Thread Sasha Levin
From: Laurent Pinchart 

[ Upstream commit 3d61fe5f59dd3e6f96fc0772156d257cb04dc656 ]

The drm_vblank_init() takes the total number of CRTCs as an argument,
but the rcar-du driver passes a bitmask of the CRTC indices. Fix it.

Fixes: 4bf8e1962f91 ("drm: Renesas R-Car Display Unit DRM driver")
Reported-by: Tomi Valkeinen 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 0386b454e221..6a9578159c2b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -544,7 +544,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
 * Initialize vertical blanking interrupts handling. Start with vblank
 * disabled for all CRTCs.
 */
-   ret = drm_vblank_init(dev, (1 << rcdu->num_crtcs) - 1);
+   ret = drm_vblank_init(dev, rcdu->num_crtcs);
if (ret < 0)
return ret;
 
-- 
2.20.1

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


Re: [Intel-gfx] [RFC PATCH v2 2/2] drm/i915/gen7: Clear all EU/L3 residual contexts

2020-01-16 Thread Ville Syrjälä
On Tue, Jan 14, 2020 at 09:45:48AM -0800, Akeem G Abodunrin wrote:
> From: Prathap Kumar Valsan 
> 
> On gen7 and gen7.5 devices, there could be leftover data residuals in
> EU/L3 from the retiring context. This patch introduces workaround to clear
> that residual contexts, by submitting a batch buffer with dedicated HW
> context to the GPU with ring allocation for each context switching.
> 
> V2: Addressed comments about unused code, code formatting, and include
> additional debug code
> 
> Signed-off-by: Mika Kuoppala 
> Signed-off-by: Prathap Kumar Valsan 
> Signed-off-by: Akeem G Abodunrin 
> Cc: Chris Wilson 
> Cc: Balestrieri Francesco 
> Cc: Bloomfield Jon 
> Cc: Dutt Sudeep 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/gt/gen7_renderclear.c| 515 ++
>  drivers/gpu/drm/i915/gt/gen7_renderclear.h|  16 +
>  drivers/gpu/drm/i915/gt/intel_gpu_commands.h  |  17 +-
>  .../gpu/drm/i915/gt/intel_ring_submission.c   |   3 +-
>  drivers/gpu/drm/i915/i915_utils.h |   5 +
>  6 files changed, 553 insertions(+), 4 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.c
>  create mode 100644 drivers/gpu/drm/i915/gt/gen7_renderclear.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b8c5f8934dbd..e5386871f015 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -75,6 +75,7 @@ gt-y += \
>   gt/debugfs_gt.o \
>   gt/debugfs_gt_pm.o \
>   gt/gen6_ppgtt.o \
> + gt/gen7_renderclear.o \
>   gt/gen8_ppgtt.o \
>   gt/intel_breadcrumbs.o \
>   gt/intel_context.o \
> diff --git a/drivers/gpu/drm/i915/gt/gen7_renderclear.c 
> b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> new file mode 100644
> index ..6fe2a6fcbddd
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gt/gen7_renderclear.c
> @@ -0,0 +1,515 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#include "gen7_renderclear.h"
> +#include "i915_drv.h"
> +#include "i915_utils.h"
> +#include "intel_gpu_commands.h"
> +
> +#define MAX_URB_ENTRIES 64
> +#define STATE_SIZE (4 * 1024)
> +#define GT3_INLINE_DATA_DELAYS 0x1E00
> +
> +/* Media CB Kernel for gen7 devices */
> +static const u32 cb7_kernel[][4] = {
> + { 0x0001, 0x26020128, 0x0024, 0x },
> + { 0x0040, 0x20280c21, 0x0028, 0x0001 },
> + { 0x0110, 0x2c20, 0x002c, 0x },
> + { 0x00010220, 0x34001c00, 0x1400, 0x002c },
> + { 0x0061, 0x20600061, 0x, 0x },
> + { 0x0008, 0x20601c85, 0x0e00, 0x000c },
> + { 0x0005, 0x20601ca5, 0x0060, 0x0001 },
> + { 0x0008, 0x20641c85, 0x0e00, 0x000d },
> + { 0x0005, 0x20641ca5, 0x0064, 0x0003 },
> + { 0x0041, 0x207424a5, 0x0064, 0x0034 },
> + { 0x0040, 0x206014a5, 0x0060, 0x0074 },
> + { 0x0008, 0x20681c85, 0x0e00, 0x0008 },
> + { 0x0005, 0x20681ca5, 0x0068, 0x000f },
> + { 0x0041, 0x20701ca5, 0x0060, 0x0010 },
> + { 0x0040, 0x206814a5, 0x0068, 0x0070 },
> + { 0x0061, 0x20a00061, 0x, 0x },
> + { 0x0005, 0x206c1c85, 0x0e00, 0x0007 },
> + { 0x0041, 0x206c1ca5, 0x006c, 0x0004 },
> + { 0x0061, 0x20800021, 0x008d, 0x },
> + { 0x0001, 0x20800021, 0x006c, 0x },
> + { 0x0001, 0x20840021, 0x0068, 0x },
> + { 0x0001, 0x20880061, 0x, 0x0003 },
> + { 0x0005, 0x208c0d21, 0x0086, 0x },
> + { 0x05600032, 0x20a01fa1, 0x008d0080, 0x02190001 },
> + { 0x0040, 0x20a01ca5, 0x00a0, 0x0001 },
> + { 0x05600032, 0x20a01fa1, 0x008d0080, 0x040a8001 },
> + { 0x0240, 0x20281c21, 0x0028, 0x },
> + { 0x00010220, 0x34001c00, 0x1400, 0xfffc },
> + { 0x0001, 0x26020128, 0x0024, 0x },
> + { 0x0001, 0x22e4, 0x, 0x },
> + { 0x0001, 0x220801ec, 0x, 0x007f007f },
> + { 0x0061, 0x20400021, 0x008d, 0x },
> + { 0x0061, 0x2fe00021, 0x008d, 0x },
> + { 0x0021, 0x20400121, 0x00450020, 0x },
> + { 0x0001, 0x20480061, 0x, 0x000f000f },
> + { 0x0005, 0x204c0d21, 0x0046, 0xffef },
> + { 0x0081, 0x20600061, 0x, 0x },
> + { 0x0081, 0x20800061, 0x, 0x },
> + { 0x0081, 0x20a00061, 0x, 0x },
> + { 0x0081, 0x20c00061, 0x, 0x },
> + { 0x0081, 0x20e00061, 0x, 0x },
> + { 0x0081, 0x2161, 0x, 0x },
> + { 0x0081, 0x21200061, 0x, 0x },
> + { 0x0081, 0x21400061, 0x, 0x },
> + { 0x05600032, 

[PATCH AUTOSEL 4.19 053/671] drm: rcar-du: Fix the return value in case of error in 'rcar_du_crtc_set_crc_source()'

2020-01-16 Thread Sasha Levin
From: Christophe JAILLET 

[ Upstream commit 4d486f18d91b1876040bf87e9ad78981a08b15a6 ]

We return 0 unconditionally in 'rcar_du_crtc_set_crc_source()'.
However, 'ret' is set to some error codes if some function calls fail.

Return 'ret' instead to propagate the error code.

Fixes: 47a52d024e89 ("media: drm: rcar-du: Add support for CRC computation")
Signed-off-by: Christophe JAILLET 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 15dc9caa128b..212e5e11e4b7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -837,7 +837,7 @@ static int rcar_du_crtc_set_crc_source(struct drm_crtc 
*crtc,
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
 
-   return 0;
+   return ret;
 }
 
 static const struct drm_crtc_funcs crtc_funcs_gen2 = {
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 027/671] drm/msm: fix unsigned comparison with less than zero

2020-01-16 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit dfdb3be43ef1195c491e6c3760b922acb52e3575 ]

The return from the call to _mixer_stages can be a negative error
code however this is being assigned to an unsigned variable 'stages'
hence the check is always false. Fix this by making 'stages' an
int.

Detected by Coccinelle ("Unsigned expression compared with zero:
stages < 0")

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Colin Ian King 
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 06be7cf7ce50..79bafea66354 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -310,7 +310,7 @@ static void dpu_hw_ctl_setup_blendstage(struct dpu_hw_ctl 
*ctx,
u32 mixercfg = 0, mixercfg_ext = 0, mix, ext;
u32 mixercfg_ext2 = 0, mixercfg_ext3 = 0;
int i, j;
-   u8 stages;
+   int stages;
int pipes_per_stage;
 
stages = _mixer_stages(ctx->mixer_hw_caps, ctx->mixer_count, lm);
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 014/671] drm/hisilicon: hibmc: Don't overwrite fb helper surface depth

2020-01-16 Thread Sasha Levin
From: John Garry 

[ Upstream commit 0ff9f49646353ce31312411e7e7bd2281492a40e ]

Currently the driver overwrites the surface depth provided by the fb
helper to give an invalid bpp/surface depth combination.

This has been exposed by commit 70109354fed2 ("drm: Reject unknown legacy
bpp and depth for drm_mode_addfb ioctl"), which now causes the driver to
fail to probe.

Fix by not overwriting the surface depth.

Fixes: d1667b86795a ("drm/hisilicon/hibmc: Add support for frame buffer")
Signed-off-by: John Garry 
Reviewed-by: Xinliang Liu 
Signed-off-by: Xinliang Liu 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index 8bd29075ae4e..edcca1761500 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -71,7 +71,6 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
DRM_DEBUG_DRIVER("surface width(%d), height(%d) and bpp(%d)\n",
 sizes->surface_width, sizes->surface_height,
 sizes->surface_bpp);
-   sizes->surface_depth = 32;
 
bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
 
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 001/671] drm/sti: do not remove the drm_bridge that was never added

2020-01-16 Thread Sasha Levin
From: Peter Rosin 

[ Upstream commit 66e31a72dc38543b2d9d1ce267dc78ba9beebcfd ]

Removing the drm_bridge_remove call should avoid a NULL dereference
during list processing in drm_bridge_remove if the error path is ever
taken.

The more natural approach would perhaps be to add a drm_bridge_add,
but there are several other bridges that never call drm_bridge_add.
Just removing the drm_bridge_remove is the easier fix.

Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
Acked-by: Daniel Vetter 
Signed-off-by: Peter Rosin 
Signed-off-by: Benjamin Gaignard 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180806061910.29914-2-p...@axentia.se
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/sti/sti_hda.c  | 1 -
 drivers/gpu/drm/sti/sti_hdmi.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
index 49438337f70d..19b9b5ed1297 100644
--- a/drivers/gpu/drm/sti/sti_hda.c
+++ b/drivers/gpu/drm/sti/sti_hda.c
@@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct device 
*master, void *data)
return 0;
 
 err_sysfs:
-   drm_bridge_remove(bridge);
return -EINVAL;
 }
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 34cdc4644435..ccf718404a1c 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, struct 
device *master, void *data)
return 0;
 
 err_sysfs:
-   drm_bridge_remove(bridge);
hdmi->drm_connector = NULL;
return -EINVAL;
 }
-- 
2.20.1

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


[PATCH AUTOSEL 4.19 005/671] drm/virtio: fix bounds check in virtio_gpu_cmd_get_capset()

2020-01-16 Thread Sasha Levin
From: Dan Carpenter 

[ Upstream commit 09c4b49457434fa74749ad6194ef28464d9f5df9 ]

This doesn't affect runtime because in the current code "idx" is always
valid.

First, we read from "vgdev->capsets[idx].max_size" before checking
whether "idx" is within bounds.  And secondly the bounds check is off by
one so we could end up reading one element beyond the end of the
vgdev->capsets[] array.

Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support")
Signed-off-by: Dan Carpenter 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20180704094250.m7sgvvzg3dhcvv3h@kili.mountain
Signed-off-by: Gerd Hoffmann 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/virtio/virtgpu_vq.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c 
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index c8a581b1f4c4..608906f06ced 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -650,11 +650,11 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
 {
struct virtio_gpu_get_capset *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
-   int max_size = vgdev->capsets[idx].max_size;
+   int max_size;
struct virtio_gpu_drv_cap_cache *cache_ent;
void *resp_buf;
 
-   if (idx > vgdev->num_capsets)
+   if (idx >= vgdev->num_capsets)
return -EINVAL;
 
if (version > vgdev->capsets[idx].max_version)
@@ -664,6 +664,7 @@ int virtio_gpu_cmd_get_capset(struct virtio_gpu_device 
*vgdev,
if (!cache_ent)
return -ENOMEM;
 
+   max_size = vgdev->capsets[idx].max_size;
cache_ent->caps_cache = kmalloc(max_size, GFP_KERNEL);
if (!cache_ent->caps_cache) {
kfree(cache_ent);
-- 
2.20.1

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


  1   2   >