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-11-30 22:51:47 +00:00
|
|
|
/*
|
2014-11-18 17:49:47 +00: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-11-30 22:51:47 +00: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/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __MDP5_SMP_H__
|
|
|
|
#define __MDP5_SMP_H__
|
|
|
|
|
2016-10-26 18:06:55 +00:00
|
|
|
#include <drm/drm_print.h>
|
|
|
|
|
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-11-30 22:51:47 +00:00
|
|
|
#include "msm_drv.h"
|
|
|
|
|
2016-11-01 20:35:32 +00:00
|
|
|
/*
|
|
|
|
* SMP - Shared Memory Pool:
|
|
|
|
*
|
|
|
|
* SMP blocks are shared between all the clients, where each plane in
|
|
|
|
* a scanout buffer is a SMP client. Ie. scanout of 3 plane I420 on
|
|
|
|
* pipe VIG0 => 3 clients: VIG0_Y, VIG0_CB, VIG0_CR.
|
|
|
|
*
|
|
|
|
* Based on the size of the attached scanout buffer, a certain # of
|
|
|
|
* blocks must be allocated to that client out of the shared pool.
|
|
|
|
*
|
|
|
|
* In some hw, some blocks are statically allocated for certain pipes
|
|
|
|
* and CANNOT be re-allocated (eg: MMB0 and MMB1 both tied to RGB0).
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Atomic SMP State:
|
|
|
|
*
|
|
|
|
* On atomic updates that modify SMP configuration, the state is cloned
|
|
|
|
* (copied) and modified. For test-only, or in cases where atomic
|
|
|
|
* update fails (or if we hit ww_mutex deadlock/backoff condition) the
|
|
|
|
* new state is simply thrown away.
|
|
|
|
*
|
|
|
|
* Because the SMP registers are not double buffered, updates are a
|
|
|
|
* two step process:
|
|
|
|
*
|
|
|
|
* 1) in _prepare_commit() we configure things (via read-modify-write)
|
|
|
|
* for the newly assigned pipes, so we don't take away blocks
|
|
|
|
* assigned to pipes that are still scanning out
|
|
|
|
* 2) in _complete_commit(), after vblank/etc, we clear things for the
|
|
|
|
* released clients, since at that point old pipes are no longer
|
|
|
|
* scanning out.
|
|
|
|
*/
|
|
|
|
struct mdp5_smp_state {
|
|
|
|
/* global state of what blocks are in use: */
|
|
|
|
mdp5_smp_state_t state;
|
|
|
|
|
|
|
|
/* per client state of what blocks they are using: */
|
|
|
|
mdp5_smp_state_t client_state[MAX_CLIENTS];
|
|
|
|
|
|
|
|
/* assigned pipes (hw updated at _prepare_commit()): */
|
|
|
|
unsigned long assigned;
|
|
|
|
|
|
|
|
/* released pipes (hw updated at _complete_commit()): */
|
|
|
|
unsigned long released;
|
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-11-30 22:51:47 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct mdp5_kms;
|
2014-11-18 19:28:43 +00:00
|
|
|
struct mdp5_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-11-30 22:51:47 +00:00
|
|
|
|
2014-11-18 17:49:47 +00:00
|
|
|
/*
|
|
|
|
* SMP module prototypes:
|
|
|
|
* mdp5_smp_init() returns a SMP @handler,
|
|
|
|
* which is then used to call the other mdp5_smp_*(handler, ...) functions.
|
|
|
|
*/
|
|
|
|
|
2016-11-01 20:35:32 +00:00
|
|
|
struct mdp5_smp *mdp5_smp_init(struct mdp5_kms *mdp5_kms,
|
|
|
|
const struct mdp5_smp_block *cfg);
|
2014-11-18 19:28:43 +00:00
|
|
|
void mdp5_smp_destroy(struct mdp5_smp *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-11-30 22:51:47 +00:00
|
|
|
|
2016-10-26 18:06:55 +00:00
|
|
|
void mdp5_smp_dump(struct mdp5_smp *smp, struct drm_printer *p);
|
|
|
|
|
2016-11-01 20:35:32 +00:00
|
|
|
uint32_t mdp5_smp_calculate(struct mdp5_smp *smp,
|
|
|
|
const struct mdp_format *format,
|
|
|
|
u32 width, bool hdecim);
|
|
|
|
|
|
|
|
int mdp5_smp_assign(struct mdp5_smp *smp, struct mdp5_smp_state *state,
|
|
|
|
enum mdp5_pipe pipe, uint32_t blkcfg);
|
|
|
|
void mdp5_smp_release(struct mdp5_smp *smp, struct mdp5_smp_state *state,
|
|
|
|
enum mdp5_pipe pipe);
|
|
|
|
|
|
|
|
void mdp5_smp_prepare_commit(struct mdp5_smp *smp, struct mdp5_smp_state *state);
|
|
|
|
void mdp5_smp_complete_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-11-30 22:51:47 +00:00
|
|
|
|
|
|
|
#endif /* __MDP5_SMP_H__ */
|