drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
/*
|
2014-11-19 01:49:47 +08:00
|
|
|
* Copyright (c) 2014, The Linux Foundation. All rights reserved.
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
* Copyright (C) 2013 Red Hat
|
|
|
|
* Author: Rob Clark <robdclark@gmail.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as published by
|
|
|
|
* the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
|
|
#include "mdp5_kms.h"
|
|
|
|
#include "mdp5_smp.h"
|
|
|
|
|
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
struct mdp5_smp {
|
|
|
|
struct drm_device *dev;
|
|
|
|
|
2015-09-15 20:41:44 +08:00
|
|
|
uint8_t reserved[MAX_CLIENTS]; /* fixed MMBs allocation per client */
|
2015-07-07 04:35:30 +08:00
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
int blk_cnt;
|
|
|
|
int blk_size;
|
2017-07-28 18:47:06 +08:00
|
|
|
|
|
|
|
/* register cache */
|
|
|
|
u32 alloc_w[22];
|
|
|
|
u32 alloc_r[22];
|
|
|
|
u32 pipe_reqprio_fifo_wm0[SSPP_MAX];
|
|
|
|
u32 pipe_reqprio_fifo_wm1[SSPP_MAX];
|
|
|
|
u32 pipe_reqprio_fifo_wm2[SSPP_MAX];
|
2014-11-19 01:49:47 +08:00
|
|
|
};
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
static inline
|
|
|
|
struct mdp5_kms *get_kms(struct mdp5_smp *smp)
|
|
|
|
{
|
|
|
|
struct msm_drm_private *priv = smp->dev->dev_private;
|
|
|
|
|
|
|
|
return to_mdp5_kms(to_mdp_kms(priv->kms));
|
|
|
|
}
|
|
|
|
|
2015-03-09 21:11:06 +08:00
|
|
|
static inline u32 pipe2client(enum mdp5_pipe pipe, int plane)
|
2014-11-19 01:49:47 +08:00
|
|
|
{
|
2015-03-09 21:11:06 +08:00
|
|
|
#define CID_UNUSED 0
|
|
|
|
|
|
|
|
if (WARN_ON(plane >= pipe2nclients(pipe)))
|
|
|
|
return CID_UNUSED;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note on SMP clients:
|
|
|
|
* For ViG pipes, fetch Y/Cr/Cb-components clients are always
|
|
|
|
* consecutive, and in that order.
|
|
|
|
*
|
|
|
|
* e.g.:
|
|
|
|
* if mdp5_cfg->smp.clients[SSPP_VIG0] = N,
|
|
|
|
* Y plane's client ID is N
|
|
|
|
* Cr plane's client ID is N + 1
|
|
|
|
* Cb plane's client ID is N + 2
|
|
|
|
*/
|
|
|
|
|
|
|
|
return mdp5_cfg->smp.clients[pipe] + plane;
|
2014-11-19 01:49:47 +08:00
|
|
|
}
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
/* allocate blocks for the specified request: */
|
2014-11-19 01:49:47 +08:00
|
|
|
static int smp_request_block(struct mdp5_smp *smp,
|
2016-11-02 04:35:32 +08:00
|
|
|
struct mdp5_smp_state *state,
|
2015-03-09 21:11:06 +08:00
|
|
|
u32 cid, int nblks)
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
{
|
2016-11-02 04:35:32 +08:00
|
|
|
void *cs = state->client_state[cid];
|
|
|
|
int i, avail, cnt = smp->blk_cnt;
|
2015-09-15 20:41:44 +08:00
|
|
|
uint8_t reserved;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
/* we shouldn't be requesting blocks for an in-use client: */
|
|
|
|
WARN_ON(bitmap_weight(cs, cnt) > 0);
|
2014-11-19 01:49:48 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
reserved = smp->reserved[cid];
|
2014-11-19 01:49:47 +08:00
|
|
|
|
2015-01-17 02:22:14 +08:00
|
|
|
if (reserved) {
|
|
|
|
nblks = max(0, nblks - reserved);
|
2014-11-19 01:49:47 +08:00
|
|
|
DBG("%d MMBs allocated (%d reserved)", nblks, reserved);
|
2015-01-17 02:22:14 +08:00
|
|
|
}
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
avail = cnt - bitmap_weight(state->state, cnt);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
if (nblks > avail) {
|
2016-11-02 04:35:32 +08:00
|
|
|
dev_err(smp->dev->dev, "out of blks (req=%d > avail=%d)\n",
|
2014-11-19 01:49:47 +08:00
|
|
|
nblks, avail);
|
2016-11-02 04:35:32 +08:00
|
|
|
return -ENOSPC;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
for (i = 0; i < nblks; i++) {
|
|
|
|
int blk = find_first_zero_bit(state->state, cnt);
|
|
|
|
set_bit(blk, cs);
|
|
|
|
set_bit(blk, state->state);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_fifo_thresholds(struct mdp5_smp *smp,
|
|
|
|
enum mdp5_pipe pipe, int nblks)
|
|
|
|
{
|
|
|
|
u32 smp_entries_per_blk = smp->blk_size / (128 / BITS_PER_BYTE);
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
/* 1/4 of SMP pool that is being fetched */
|
|
|
|
val = (nblks * smp_entries_per_blk) / 4;
|
|
|
|
|
2017-07-28 18:47:06 +08:00
|
|
|
smp->pipe_reqprio_fifo_wm0[pipe] = val * 1;
|
|
|
|
smp->pipe_reqprio_fifo_wm1[pipe] = val * 2;
|
|
|
|
smp->pipe_reqprio_fifo_wm2[pipe] = val * 3;
|
2014-11-19 01:49:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: looks like if horizontal decimation is used (if we supported that)
|
|
|
|
* then the width used to calculate SMP block requirements is the post-
|
|
|
|
* decimated width. Ie. SMP buffering sits downstream of decimation (which
|
|
|
|
* presumably happens during the dma from scanout buffer).
|
|
|
|
*/
|
2016-11-02 04:35:32 +08:00
|
|
|
uint32_t mdp5_smp_calculate(struct mdp5_smp *smp,
|
|
|
|
const struct mdp_format *format,
|
|
|
|
u32 width, bool hdecim)
|
2014-11-19 01:49:47 +08:00
|
|
|
{
|
|
|
|
struct mdp5_kms *mdp5_kms = get_kms(smp);
|
2014-11-19 03:28:43 +08:00
|
|
|
int rev = mdp5_cfg_get_hw_rev(mdp5_kms->cfg);
|
2016-11-02 04:35:32 +08:00
|
|
|
int i, hsub, nplanes, nlines;
|
2015-07-07 04:35:30 +08:00
|
|
|
u32 fmt = format->base.pixel_format;
|
2016-11-02 04:35:32 +08:00
|
|
|
uint32_t blkcfg = 0;
|
2014-11-19 01:49:47 +08:00
|
|
|
|
|
|
|
nplanes = drm_format_num_planes(fmt);
|
|
|
|
hsub = drm_format_horz_chroma_subsampling(fmt);
|
|
|
|
|
|
|
|
/* different if BWC (compressed framebuffer?) enabled: */
|
|
|
|
nlines = 2;
|
|
|
|
|
2015-07-07 04:35:30 +08:00
|
|
|
/* Newer MDPs have split/packing logic, which fetches sub-sampled
|
|
|
|
* U and V components (splits them from Y if necessary) and packs
|
|
|
|
* them together, writes to SMP using a single client.
|
|
|
|
*/
|
|
|
|
if ((rev > 0) && (format->chroma_sample > CHROMA_FULL)) {
|
|
|
|
fmt = DRM_FORMAT_NV24;
|
|
|
|
nplanes = 2;
|
|
|
|
|
|
|
|
/* if decimation is enabled, HW decimates less on the
|
|
|
|
* sub sampled chroma components
|
|
|
|
*/
|
|
|
|
if (hdecim && (hsub > 1))
|
|
|
|
hsub = 1;
|
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
for (i = 0; i < nplanes; i++) {
|
2014-11-19 01:49:47 +08:00
|
|
|
int n, fetch_stride, cpp;
|
|
|
|
|
|
|
|
cpp = drm_format_plane_cpp(fmt, i);
|
|
|
|
fetch_stride = width * cpp / (i ? hsub : 1);
|
|
|
|
|
|
|
|
n = DIV_ROUND_UP(fetch_stride * nlines, smp->blk_size);
|
|
|
|
|
|
|
|
/* for hw rev v1.00 */
|
2014-11-19 01:49:48 +08:00
|
|
|
if (rev == 0)
|
2014-11-19 01:49:47 +08:00
|
|
|
n = roundup_pow_of_two(n);
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
blkcfg |= (n << (8 * i));
|
|
|
|
}
|
|
|
|
|
|
|
|
return blkcfg;
|
|
|
|
}
|
|
|
|
|
|
|
|
int mdp5_smp_assign(struct mdp5_smp *smp, struct mdp5_smp_state *state,
|
|
|
|
enum mdp5_pipe pipe, uint32_t blkcfg)
|
|
|
|
{
|
|
|
|
struct mdp5_kms *mdp5_kms = get_kms(smp);
|
|
|
|
struct drm_device *dev = mdp5_kms->dev;
|
|
|
|
int i, ret;
|
|
|
|
|
|
|
|
for (i = 0; i < pipe2nclients(pipe); i++) {
|
|
|
|
u32 cid = pipe2client(pipe, i);
|
|
|
|
int n = blkcfg & 0xff;
|
|
|
|
|
|
|
|
if (!n)
|
|
|
|
continue;
|
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
DBG("%s[%d]: request %d SMP blocks", pipe2name(pipe), i, n);
|
2016-11-02 04:35:32 +08:00
|
|
|
ret = smp_request_block(smp, state, cid, n);
|
2014-11-19 01:49:47 +08:00
|
|
|
if (ret) {
|
|
|
|
dev_err(dev->dev, "Cannot allocate %d SMP blocks: %d\n",
|
|
|
|
n, ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
blkcfg >>= 8;
|
2014-11-19 01:49:47 +08:00
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
state->assigned |= (1 << pipe);
|
2014-11-19 01:49:47 +08:00
|
|
|
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
/* Release SMP blocks for all clients of the pipe */
|
2016-11-02 04:35:32 +08:00
|
|
|
void mdp5_smp_release(struct mdp5_smp *smp, struct mdp5_smp_state *state,
|
|
|
|
enum mdp5_pipe pipe)
|
2014-11-19 01:49:47 +08:00
|
|
|
{
|
2015-06-20 02:03:42 +08:00
|
|
|
int i;
|
|
|
|
int cnt = smp->blk_cnt;
|
|
|
|
|
|
|
|
for (i = 0; i < pipe2nclients(pipe); i++) {
|
|
|
|
u32 cid = pipe2client(pipe, i);
|
2016-11-02 04:35:32 +08:00
|
|
|
void *cs = state->client_state[cid];
|
2015-06-20 02:03:42 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
/* update global state: */
|
|
|
|
bitmap_andnot(state->state, state->state, cs, cnt);
|
2015-06-20 02:03:42 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
/* clear client's state */
|
|
|
|
bitmap_zero(cs, cnt);
|
2015-06-20 02:03:42 +08:00
|
|
|
}
|
2014-11-19 01:49:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
state->released |= (1 << pipe);
|
2014-11-19 01:49:47 +08:00
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
/* NOTE: SMP_ALLOC_* regs are *not* double buffered, so release has to
|
|
|
|
* happen after scanout completes.
|
|
|
|
*/
|
|
|
|
static unsigned update_smp_state(struct mdp5_smp *smp,
|
2015-03-09 21:11:06 +08:00
|
|
|
u32 cid, mdp5_smp_state_t *assigned)
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
{
|
2014-11-19 01:49:47 +08:00
|
|
|
int cnt = smp->blk_cnt;
|
2016-11-02 04:35:32 +08:00
|
|
|
unsigned nblks = 0;
|
2014-11-19 01:49:47 +08:00
|
|
|
u32 blk, val;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
|
|
|
for_each_set_bit(blk, *assigned, cnt) {
|
|
|
|
int idx = blk / 3;
|
|
|
|
int fld = blk % 3;
|
|
|
|
|
2017-07-28 18:47:06 +08:00
|
|
|
val = smp->alloc_w[idx];
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
|
|
|
switch (fld) {
|
|
|
|
case 0:
|
2016-05-10 13:35:58 +08:00
|
|
|
val &= ~MDP5_SMP_ALLOC_W_REG_CLIENT0__MASK;
|
|
|
|
val |= MDP5_SMP_ALLOC_W_REG_CLIENT0(cid);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
break;
|
|
|
|
case 1:
|
2016-05-10 13:35:58 +08:00
|
|
|
val &= ~MDP5_SMP_ALLOC_W_REG_CLIENT1__MASK;
|
|
|
|
val |= MDP5_SMP_ALLOC_W_REG_CLIENT1(cid);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
break;
|
|
|
|
case 2:
|
2016-05-10 13:35:58 +08:00
|
|
|
val &= ~MDP5_SMP_ALLOC_W_REG_CLIENT2__MASK;
|
|
|
|
val |= MDP5_SMP_ALLOC_W_REG_CLIENT2(cid);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-07-28 18:47:06 +08:00
|
|
|
smp->alloc_w[idx] = val;
|
|
|
|
smp->alloc_r[idx] = val;
|
2016-11-02 04:35:32 +08:00
|
|
|
|
|
|
|
nblks++;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|
2016-11-02 04:35:32 +08:00
|
|
|
|
|
|
|
return nblks;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|
|
|
|
|
2017-07-28 18:47:06 +08:00
|
|
|
static void write_smp_alloc_regs(struct mdp5_smp *smp)
|
|
|
|
{
|
|
|
|
struct mdp5_kms *mdp5_kms = get_kms(smp);
|
|
|
|
int i, num_regs;
|
|
|
|
|
|
|
|
num_regs = smp->blk_cnt / 3 + 1;
|
|
|
|
|
|
|
|
for (i = 0; i < num_regs; i++) {
|
|
|
|
mdp5_write(mdp5_kms, REG_MDP5_SMP_ALLOC_W_REG(i),
|
|
|
|
smp->alloc_w[i]);
|
|
|
|
mdp5_write(mdp5_kms, REG_MDP5_SMP_ALLOC_R_REG(i),
|
|
|
|
smp->alloc_r[i]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void write_smp_fifo_regs(struct mdp5_smp *smp)
|
|
|
|
{
|
|
|
|
struct mdp5_kms *mdp5_kms = get_kms(smp);
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < mdp5_kms->num_hwpipes; i++) {
|
|
|
|
struct mdp5_hw_pipe *hwpipe = mdp5_kms->hwpipes[i];
|
|
|
|
enum mdp5_pipe pipe = hwpipe->pipe;
|
|
|
|
|
|
|
|
mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_0(pipe),
|
|
|
|
smp->pipe_reqprio_fifo_wm0[pipe]);
|
|
|
|
mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_1(pipe),
|
|
|
|
smp->pipe_reqprio_fifo_wm1[pipe]);
|
|
|
|
mdp5_write(mdp5_kms, REG_MDP5_PIPE_REQPRIO_FIFO_WM_2(pipe),
|
|
|
|
smp->pipe_reqprio_fifo_wm2[pipe]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
void mdp5_smp_prepare_commit(struct mdp5_smp *smp, struct mdp5_smp_state *state)
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
{
|
2016-11-02 04:35:32 +08:00
|
|
|
enum mdp5_pipe pipe;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
for_each_set_bit(pipe, &state->assigned, sizeof(state->assigned) * 8) {
|
|
|
|
unsigned i, nblks = 0;
|
2015-06-20 02:03:42 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
for (i = 0; i < pipe2nclients(pipe); i++) {
|
|
|
|
u32 cid = pipe2client(pipe, i);
|
|
|
|
void *cs = state->client_state[cid];
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
nblks += update_smp_state(smp, cid, cs);
|
2014-11-19 01:49:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
DBG("assign %s:%u, %u blks",
|
|
|
|
pipe2name(pipe), i, nblks);
|
|
|
|
}
|
2014-11-19 01:49:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
set_fifo_thresholds(smp, pipe, nblks);
|
|
|
|
}
|
2014-11-19 01:49:47 +08:00
|
|
|
|
2017-07-28 18:47:06 +08:00
|
|
|
write_smp_alloc_regs(smp);
|
|
|
|
write_smp_fifo_regs(smp);
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
state->assigned = 0;
|
|
|
|
}
|
2014-11-19 01:49:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
void mdp5_smp_complete_commit(struct mdp5_smp *smp, struct mdp5_smp_state *state)
|
|
|
|
{
|
|
|
|
enum mdp5_pipe pipe;
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
for_each_set_bit(pipe, &state->released, sizeof(state->released) * 8) {
|
|
|
|
DBG("release %s", pipe2name(pipe));
|
|
|
|
set_fifo_thresholds(smp, pipe, 0);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|
2016-11-02 04:35:32 +08:00
|
|
|
|
2017-07-28 18:47:06 +08:00
|
|
|
write_smp_fifo_regs(smp);
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
state->released = 0;
|
2014-11-19 01:49:47 +08:00
|
|
|
}
|
|
|
|
|
2016-10-27 02:06:55 +08:00
|
|
|
void mdp5_smp_dump(struct mdp5_smp *smp, struct drm_printer *p)
|
|
|
|
{
|
|
|
|
struct mdp5_kms *mdp5_kms = get_kms(smp);
|
|
|
|
struct mdp5_hw_pipe_state *hwpstate;
|
|
|
|
struct mdp5_smp_state *state;
|
|
|
|
int total = 0, i, j;
|
|
|
|
|
|
|
|
drm_printf(p, "name\tinuse\tplane\n");
|
|
|
|
drm_printf(p, "----\t-----\t-----\n");
|
|
|
|
|
2016-11-05 21:04:31 +08:00
|
|
|
if (drm_can_sleep())
|
|
|
|
drm_modeset_lock(&mdp5_kms->state_lock, NULL);
|
2016-10-27 02:06:55 +08:00
|
|
|
|
|
|
|
/* grab these *after* we hold the state_lock */
|
|
|
|
hwpstate = &mdp5_kms->state->hwpipe;
|
|
|
|
state = &mdp5_kms->state->smp;
|
|
|
|
|
|
|
|
for (i = 0; i < mdp5_kms->num_hwpipes; i++) {
|
|
|
|
struct mdp5_hw_pipe *hwpipe = mdp5_kms->hwpipes[i];
|
|
|
|
struct drm_plane *plane = hwpstate->hwpipe_to_plane[hwpipe->idx];
|
|
|
|
enum mdp5_pipe pipe = hwpipe->pipe;
|
|
|
|
for (j = 0; j < pipe2nclients(pipe); j++) {
|
|
|
|
u32 cid = pipe2client(pipe, j);
|
|
|
|
void *cs = state->client_state[cid];
|
|
|
|
int inuse = bitmap_weight(cs, smp->blk_cnt);
|
|
|
|
|
|
|
|
drm_printf(p, "%s:%d\t%d\t%s\n",
|
|
|
|
pipe2name(pipe), j, inuse,
|
|
|
|
plane ? plane->name : NULL);
|
|
|
|
|
|
|
|
total += inuse;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
drm_printf(p, "TOTAL:\t%d\t(of %d)\n", total, smp->blk_cnt);
|
|
|
|
drm_printf(p, "AVAIL:\t%d\n", smp->blk_cnt -
|
|
|
|
bitmap_weight(state->state, smp->blk_cnt));
|
|
|
|
|
2016-11-05 21:04:31 +08:00
|
|
|
if (drm_can_sleep())
|
|
|
|
drm_modeset_unlock(&mdp5_kms->state_lock);
|
2016-10-27 02:06:55 +08:00
|
|
|
}
|
|
|
|
|
2014-11-19 03:28:43 +08:00
|
|
|
void mdp5_smp_destroy(struct mdp5_smp *smp)
|
2014-11-19 01:49:47 +08:00
|
|
|
{
|
|
|
|
kfree(smp);
|
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
struct mdp5_smp *mdp5_smp_init(struct mdp5_kms *mdp5_kms, const struct mdp5_smp_block *cfg)
|
2014-11-19 01:49:47 +08:00
|
|
|
{
|
2016-11-02 04:35:32 +08:00
|
|
|
struct mdp5_smp_state *state = &mdp5_kms->state->smp;
|
2014-11-19 01:49:47 +08:00
|
|
|
struct mdp5_smp *smp = NULL;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
smp = kzalloc(sizeof(*smp), GFP_KERNEL);
|
|
|
|
if (unlikely(!smp)) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2016-11-02 04:35:32 +08:00
|
|
|
smp->dev = mdp5_kms->dev;
|
2014-11-19 01:49:47 +08:00
|
|
|
smp->blk_cnt = cfg->mmb_count;
|
|
|
|
smp->blk_size = cfg->mmb_size;
|
|
|
|
|
|
|
|
/* statically tied MMBs cannot be re-allocated: */
|
2016-11-02 04:35:32 +08:00
|
|
|
bitmap_copy(state->state, cfg->reserved_state, smp->blk_cnt);
|
2015-09-15 20:41:44 +08:00
|
|
|
memcpy(smp->reserved, cfg->reserved, sizeof(smp->reserved));
|
2014-11-19 01:49:47 +08:00
|
|
|
|
|
|
|
return smp;
|
|
|
|
fail:
|
|
|
|
if (smp)
|
|
|
|
mdp5_smp_destroy(smp);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
|
2014-11-19 01:49:47 +08:00
|
|
|
return ERR_PTR(ret);
|
drm/msm: add mdp5/apq8x74
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
2013-12-01 06:51:47 +08:00
|
|
|
}
|