Re: [PATCH 4/4] drm/sun4i: make sure we don't have a commit pending
On Fri, Jul 14, 2017 at 04:56:01PM +0800, Chen-Yu Tsai wrote: > Hi, > > On Thu, Jul 13, 2017 at 10:41 PM, Maxime Ripard > wrote: > > In the earlier display engine designs, any register access while a commit > > is pending is forbidden. > > > > One of the symptoms is that reading a register will return another, random, > > register value which can lead to register corruptions if we ever do a > > read/modify/write cycle. > > Alternatively, if changes to the backend (layers) are guaranteed to happen > while the CRTC is disabled (which seems to be the case after looking at > drm_atomic_helper_commit_planes and drm_atomic_helper_commit_tail), we > could just turn on register auto-commit all the time and not deal with > this. As far as I understand, it will only be the case if we need a new modeset or we changed the active CRTC or connectors. But if you change only the format, buffers or properties it won't be the case, and we'll need to commit. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Setup planes before enabling CRTC to avoid flicker
On Thu, Jul 13, 2017 at 05:25:08PM +0100, Kieran Bingham wrote: > >>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> index 82b978a5dae6..c2f382feca07 100644 > >>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > >>> @@ -255,9 +255,9 @@ static void rcar_du_atomic_commit_tail(struct > >>> drm_atomic_state *old_state) > >>> > >>> /* Apply the atomic update. */ > >>> drm_atomic_helper_commit_modeset_disables(dev, old_state); > >>> - drm_atomic_helper_commit_modeset_enables(dev, old_state); > >>> drm_atomic_helper_commit_planes(dev, old_state, > >>> DRM_PLANE_COMMIT_ACTIVE_ONLY); > >> > >> Except for DRM_PLANE_COMMIT_ACTIVE_ONLY, this function now looks very much > >> like > >> the default drm_atomic_helper_commit_tail() code. > >> > >> Reading around other uses /variants of commit_tail() style functions in > >> other > >> drivers has left me confused as to how the ordering affects things here. > >> > >> Could be worth adding a comment at least to describe why we can't use the > >> default helper... > > > > Or better still ... Use Maxime's new : > > > > [PATCH 1/4] drm/atomic: implement drm_atomic_helper_commit_tail for > > runtime_pm users > > Never mind - I've just looked again, and seen that this new helper function is > the ordering previous to *this* patch, and therefore isn't the same. > > However - it's worth noting that Maxime's patch converts this function to the > new helper - which contradicts this patch's motivations. So I guess I should drop the renesas modifications in my serie then? Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console
On Wed, Jul 12, 2017 at 10:40:16AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jul 12, 2017 at 3:21 AM, Maxime Ripard
> wrote:
> > On Mon, Jul 10, 2017 at 04:55:04PM +1000, Jonathan Liu wrote:
> >> The drm_driver lastclose callback is called when the last userspace
> >> DRM client has closed. Call drm_fbdev_cma_restore_mode to restore
> >> the fbdev console otherwise the fbdev console will stop working.
> >>
> >> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
> >> Cc: sta...@vger.kernel.org
> >> Signed-off-by: Jonathan Liu
> >> Reviewed-by: Chen-Yu Tsai
> >
> > Queued for 4.14, thanks!
>
> May we have this sooner? Like 4.13? :)
Yes, of course :)
I queued it for 4.13.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: sunxi: Improve endpoint ID scheme readability
Hi, On Wed, Jul 12, 2017 at 10:38:38AM +0800, Chen-Yu Tsai wrote: > On Wed, Jul 12, 2017 at 3:31 AM, Maxime Ripard > wrote: > > On Mon, Jul 10, 2017 at 11:48:00PM +0800, Chen-Yu Tsai wrote: > >> On Sun, Jun 18, 2017 at 10:05 PM, Rob Herring wrote: > >> > On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote: > >> >> The explanation for the endpoint ID numbering scheme is convoluted > >> >> and hard to understand. > >> >> > >> >> This patch aims to improve the readability of it by combining the > >> >> existing two paragraphs, while also providing a diagram example, > >> >> and how endpoints should be numbered based on that example. > >> >> > >> >> Signed-off-by: Chen-Yu Tsai > >> >> --- > >> >> > >> >> Hope this helps. I'm not sure I can improve this even more without > >> >> spelling out all cases. > >> >> > >> >> --- > >> >> .../bindings/display/sunxi/sun4i-drm.txt | 36 > >> >> -- > >> >> 1 file changed, 27 insertions(+), 9 deletions(-) > >> > > >> > Acked-by: Rob Herring > >> > >> Maxime, this patch seems to have fallen through the cracks. > >> > >> Could you queue it as a fix for 4.13? > > > > Sorry, I don't know why I overlooked it. > > > > Is it really 4.13 material though? It doesn't look that urgent. > > Unless I'm mistaken, this clarifies the numbering scheme introduced > in 4.13. I'd say that's enough reason to have it in the same release. > > But I should update the diagram first. The backend <-> TCON mux is > missing. And maybe a Fixes tag. If it's just clarification, I don't think we should push it as a fix, but and it can definitely wait. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 119/659] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: db8f738b815a11a4d093951cd753d6eb256813b7
commit: eb701dfaf7db5bb4f1cae66fb0c65d1cf52442d6 [119/659] ASoC: AMD: enable
ACP3x drivers build
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout eb701dfaf7db5bb4f1cae66fb0c65d1cf52442d6
# save the attached .config to linux build tree
make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from sound/soc/amd/raven/acp3x-pcm-dma.c:26:0:
sound/soc/amd/raven/acp3x.h: In function 'rv_readl':
>> sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function
>> 'readl' [-Werror=implicit-function-declaration]
return readl(base_addr - ACP3x_PHY_BASE_ADDRESS);
^
sound/soc/amd/raven/acp3x.h: In function 'rv_writel':
>> sound/soc/amd/raven/acp3x.h:33:2: error: implicit declaration of function
>> 'writel' [-Werror=implicit-function-declaration]
writel(val, base_addr - ACP3x_PHY_BASE_ADDRESS);
^~
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_audio_probe':
>> sound/soc/amd/raven/acp3x-pcm-dma.c:638:22: error: implicit declaration of
>> function 'devm_ioremap' [-Werror=implicit-function-declaration]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^~~~
sound/soc/amd/raven/acp3x-pcm-dma.c:638:20: warning: assignment makes
pointer from integer without a cast [-Wint-conversion]
adata->acp3x_base = devm_ioremap(&pdev->dev, res->start,
^
cc1: some warnings being treated as errors
vim +/readl +28 sound/soc/amd/raven/acp3x.h
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 25
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 26 static inline u32
rv_readl(void __iomem *base_addr)
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 27 {
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 @28 return readl(base_addr
- ACP3x_PHY_BASE_ADDRESS);
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 29 }
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 30
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 31 static inline void
rv_writel(u32 val, void __iomem *base_addr)
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 32 {
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 @33 writel(val, base_addr -
ACP3x_PHY_BASE_ADDRESS);
:: The code at line 28 was first introduced by commit
:: eb4a0b6f076f1a8d2c00c17e9f6ed76d5008655c ASoC: AMD: add ACP3.0 PCI driver
:: TO: Maruthi Srinivas Bayyavarapu
:: CC: Alex Deucher
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101748] war thunder crash with mesa_glthread enabled
https://bugs.freedesktop.org/show_bug.cgi?id=101748 higu...@gmx.net changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from higu...@gmx.net --- Something between 6b05c080f202c25531f59b547d5e6ba339cedd09 and 9ee67467c9ea592340aee10a55ba54d7266ff0a9 fixed this problem ... most changes where vulkan related, so i guess acf1e132afd1578eb7346635e1ca60f5ac6d05b1 was the one that was causing the problem. on a under-performance system (https://bugs.freedesktop.org/show_bug.cgi?id=101749) , glthread increased performance about 7%... someone with a different system needs do do a new test, but even for 7%, i vote to enable glthread on war thunder (binary name is aces) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.
On 07/15/2017 04:28 AM, Eric Anholt wrote:
Archit Taneja writes:
On 06/28/2017 01:28 AM, Eric Anholt wrote:
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings. Those get registered as DSI devices,
and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes.
There is one special case currently, the adv7533 bridge, where the
bridge probes on I2C, and during the bridge attach step it looks up
the mipi_dsi_host and registers the mipi_dsi_device (for its own stub
mipi_dsi_driver).
For the Raspberry Pi panel, though, we also need to attach on I2C (our
control bus), but don't have a bridge driver. The lack of a bridge's
attach() step like adv7533 uses means that we aren't able to delay the
mipi_dsi_device creation until the mipi_dsi_host is present.
To fix this, we extend mipi_dsi_device_register_full() to allow being
called with a NULL host, which puts the device on a queue waiting for
a host to appear. When a new host is registered, we fill in the host
value and finish the device creation process.
This is quite a nice idea. The only bothering thing is the info.of_node usage
varies between child nodes (mipi_dsi_devs) and non-child nodes (i2c control
bus).
For DSI children expressed in DT, the of_node in info holds the DT node
corresponding to the DSI child itself. For non-DT ones, this patch assumes
that info.of_node stores the DSI host DT node. I think it should be okay as
long as we mention the usage in a comment somewhere. The other option is to
have a new info.host_node field to keep a track of the host DT node.
I think maybe you misread the patch? We're using
of_get_parent(dsi->dev.node), which came from info->node, to compare to
host->dev->of_node().
I think I did misread it.
Although, I'm not entirely clear what we should be setting info.node to.
In patch #8, info.node is set by:
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
info.node = of_graph_get_remote_port(endpoint);
Looking at the dt bindings in patch #7, it looks like info.node is set
to the 'port' device node in dsi@7e70, is that right?
I suppose 'port' here seems like a reasonable representation of
dsi->dev.node, I wonder how it would work if the dsi host had multiple
ports underneath it. I.e:
dsi@7e70 {
...
...
ports {
port@0 {
...
dsi_out_port: endpoint {
remote-endpoint = <&panel_dsi_port>;
};
};
port@1 {
...
...
};
};
};
Here, we would need to set info.node to the 'ports' node, so that
of_get_parent(dsi->dev.of_node) equals host->dev->of_node. That doesn't
seem correct.
Ideally, a dev's 'of_node' should be left to NULL if we don't have a
corresponding OF node. We're sort of overriding it here since we don't
have any other place to store this information in the mipi_dsi_device
struct.
Maybe we could add a 'host_node' entry in mipi_dsi_device itself, which
is exclusively used cases where the DSI device doesn't have a DT node.
Our check in mipi_dsi_host_register() could then be something like:
if (dsi->host_node) == host->dev->of_node) {
...
...
}
Since Thierry also reviews drm_mipi_dsi.c changes, it would nice to
get some comments from him too.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-drm-next 119/659] sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: db8f738b815a11a4d093951cd753d6eb256813b7
commit: eb701dfaf7db5bb4f1cae66fb0c65d1cf52442d6 [119/659] ASoC: AMD: enable
ACP3x drivers build
config: blackfin-allmodconfig (attached as .config)
compiler: bfin-uclinux-gcc (GCC) 6.2.0
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout eb701dfaf7db5bb4f1cae66fb0c65d1cf52442d6
# save the attached .config to linux build tree
make.cross ARCH=blackfin
All errors (new ones prefixed by >>):
sound/soc/amd/raven/pci-acp3x.c: In function 'snd_acp3x_probe':
>> sound/soc/amd/raven/pci-acp3x.c:58:8: error: implicit declaration of
>> function 'pci_enable_msi' [-Werror=implicit-function-declaration]
ret = pci_enable_msi(pci);
^~
>> sound/soc/amd/raven/pci-acp3x.c:122:2: error: implicit declaration of
>> function 'pci_disable_msi' [-Werror=implicit-function-declaration]
pci_disable_msi(pci);
^~~
sound/soc/amd/raven/pci-acp3x.c: At top level:
sound/soc/amd/raven/pci-acp3x.c:159:1: warning: data definition has no type
or storage class
module_pci_driver(acp3x_driver);
^
>> sound/soc/amd/raven/pci-acp3x.c:159:1: error: type defaults to 'int' in
>> declaration of 'module_pci_driver' [-Werror=implicit-int]
sound/soc/amd/raven/pci-acp3x.c:159:1: warning: parameter names (without
types) in function declaration
sound/soc/amd/raven/pci-acp3x.c:152:26: warning: 'acp3x_driver' defined but
not used [-Wunused-variable]
static struct pci_driver acp3x_driver = {
^~~~
cc1: some warnings being treated as errors
vim +/pci_enable_msi +58 sound/soc/amd/raven/pci-acp3x.c
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 29
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 30 static int
snd_acp3x_probe(struct pci_dev *pci,
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 31
const struct pci_device_id *pci_id)
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 32 {
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 33 int ret;
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 34 u32 addr, val;
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 35 struct
acp3x_dev_data *adata;
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 36 struct
platform_device_info pdevinfo;
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 37 unsigned int
irqflags;
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 38
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 39 if
(pci_enable_device(pci)) {
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 40
dev_err(&pci->dev, "pci_enable_device failed\n");
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 41 return
-ENODEV;
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 42 }
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 43
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 44 ret =
pci_request_regions(pci, "AMD ACP3x audio");
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 45 if (ret < 0) {
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 46
dev_err(&pci->dev, "pci_request_regions failed\n");
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 47 goto
disable_pci;
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 48 }
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 49
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 50 adata =
devm_kzalloc(&pci->dev, sizeof(struct acp3x_dev_data),
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 51
GFP_KERNEL);
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 52 if (adata ==
NULL) {
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 53 ret =
-ENOMEM;
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 54 goto
release_regions;
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 55 }
eb4a0b6f0 Maruthi Srinivas Bayyavarapu 2017-03-27 56
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 57 /* check for
msi interrupt support */
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 @58 ret =
pci_enable_msi(pci);
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 59 if (ret)
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 60 /* msi
is not enabled */
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 61
irqflags = IRQF_SHARED;
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 62 else
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 63 /* msi
is enabled */
2e0e8d861 Maruthi Srinivas Bayyavarapu 2017-03-29 64
irqflags
Re: [PATCH v2 1/3] drm/i915/gvt: Add framebuffer decoder support
On 2017.07.17 11:06:24 +0800, Tina Zhang wrote:
> Framebuffer decoder returns guest framebuffer information.
> Guest framebuffer includes primary, cursor and sprite plane.
>
> Signed-off-by: Xiaoguang Chen
> Signed-off-by: Tina Zhang
> ---
> drivers/gpu/drm/i915/gvt/Makefile | 3 +-
> drivers/gpu/drm/i915/gvt/display.c| 2 +-
> drivers/gpu/drm/i915/gvt/display.h| 2 +
> drivers/gpu/drm/i915/gvt/fb_decoder.c | 429
> ++
> drivers/gpu/drm/i915/gvt/fb_decoder.h | 175 ++
> drivers/gpu/drm/i915/gvt/gvt.h| 1 +
> 6 files changed, 610 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
> create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h
>
> diff --git a/drivers/gpu/drm/i915/gvt/Makefile
> b/drivers/gpu/drm/i915/gvt/Makefile
> index f5486cb9..019d596 100644
> --- a/drivers/gpu/drm/i915/gvt/Makefile
> +++ b/drivers/gpu/drm/i915/gvt/Makefile
> @@ -1,7 +1,8 @@
> GVT_DIR := gvt
> GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o
> firmware.o \
> interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
> - execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
> + execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
> + fb_decoder.o
>
> ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR)
> i915-y += $(addprefix $(GVT_DIR)/,
> $(GVT_SOURCE))
> diff --git a/drivers/gpu/drm/i915/gvt/display.c
> b/drivers/gpu/drm/i915/gvt/display.c
> index 2deb05f..58d90cf 100644
> --- a/drivers/gpu/drm/i915/gvt/display.c
> +++ b/drivers/gpu/drm/i915/gvt/display.c
> @@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
> return 1;
> }
>
> -static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
> +int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
> {
> struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
>
> diff --git a/drivers/gpu/drm/i915/gvt/display.h
> b/drivers/gpu/drm/i915/gvt/display.h
> index d73de22..b46b868 100644
> --- a/drivers/gpu/drm/i915/gvt/display.h
> +++ b/drivers/gpu/drm/i915/gvt/display.h
> @@ -179,4 +179,6 @@ int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64
> resolution);
> void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
> void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
>
> +int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
> +
> #endif
> diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
> b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> new file mode 100644
> index 000..2bd5b3c
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
> @@ -0,0 +1,429 @@
> +/*
> + * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> THE
> + * SOFTWARE.
> + *
> + * Authors:
> + *Kevin Tian
> + *
> + * Contributors:
> + *Bing Niu
> + *Xu Han
> + *Ping Gao
> + *Xiaoguang Chen
> + *Yang Liu
> + *Tina Zhang
> + *
> + */
> +
> +#include
> +#include "i915_drv.h"
> +#include "gvt.h"
> +
> +#define PRIMARY_FORMAT_NUM 16
> +struct pixel_format {
> + int drm_format; /* Pixel format in DRM definition */
> + int bpp;/* Bits per pixel, 0 indicates invalid */
> + char *desc; /* The description */
> +};
> +
> +/* non-supported format has bpp default to 0 */
> +static struct pixel_format bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
> + [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
> + [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
> + [0x6] = {DRM_FORMAT_XRGB, 32,
> + "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
> + [0x8] = {DRM_FORMAT_XBGR2101010, 32,
> + "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
> + [0xa] = {DRM_FORMAT_XRGB2101010,
Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support
> > I can take a look at it, I just won't have time until next week most likely. I've taken a look, and it's seemingly more complicated than I'm expecting I'd want to land in Mesa before 17.2 ships, I'd really prefer to just push the new libdrm_amdgpu api from this patch. If I have to port all the current radv code to the new API, I'll most definitely get something wrong. Adding the new API so far looks like https://cgit.freedesktop.org/~airlied/drm/log/?h=drm-amdgpu-cs-submit-raw https://cgit.freedesktop.org/~airlied/drm/commit/?h=drm-amdgpu-cs-submit-raw&id=e7f85d0ca617fa41e72624780c9035df132e23c4 being the API, and whether it should take a uint32_t context id or context handle left as an open question in the last patch in the series. However to hook this into radv or radeonsi will take a bit of rewriting of a lot of code that is probably a bit more fragile than I'd like for this sort of surgery at this point. I'd actually suspect if we do want to proceed with this type of interface, we might be better doing it all in common mesa code, and maybe bypassing libdrm_amdgpu altogether, which I suppose the API I've written here is mostly already doing. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/3] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10
guest VM. This patch is to add this pixel format support to gvt device
model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash
and make guest screen black.
Signed-off-by: Xiaoguang Chen
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gvt/fb_decoder.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 2bd5b3c..739ca81 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -54,6 +54,8 @@ static struct pixel_format
bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
"32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
[0xa] = {DRM_FORMAT_XRGB2101010, 32,
"32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ [0xc] = {DRM_FORMAT_XRGB161616, 64,
+ "64-bit RGBX Floating Point(16:16:16:16 MSB-X:B:G:R)"},
[0xe] = {DRM_FORMAT_XBGR, 32,
"32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
};
@@ -75,6 +77,10 @@ static struct pixel_format skl_pixel_formats[] = {
{DRM_FORMAT_XBGR2101010, 32, "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
{DRM_FORMAT_XRGB2101010, 32, "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ {DRM_FORMAT_XRGB161616, 64,
+ "64-bit XRGB (16:16:16:16 MSB-X:R:G:B)"},
+ {DRM_FORMAT_XBGR161616, 64,
+ "64-bit XBGR (16:16:16:16 MSB-X:B:G:R)"},
/* non-supported format has bpp default to 0 */
{0, 0, NULL},
@@ -101,6 +107,9 @@ static int skl_format_to_drm(int format, bool rgb_order,
bool alpha,
case PLANE_CTL_FORMAT_XRGB_2101010:
skl_pixel_formats_index = rgb_order ? 10 : 11;
break;
+ case PLANE_CTL_FORMAT_XRGB_16161616F:
+ skl_pixel_formats_index = rgb_order ? 12 : 13;
+ break;
case PLANE_CTL_FORMAT_YUV422:
skl_pixel_formats_index = yuv_order >> 16;
if (skl_pixel_formats_index > 3)
@@ -321,6 +330,8 @@ static struct pixel_format
sprite_pixel_formats[SPRITE_FORMAT_NUM] = {
[0x0] = {DRM_FORMAT_YUV422, 16, "YUV 16-bit 4:2:2 packed"},
[0x1] = {DRM_FORMAT_XRGB2101010, 32, "RGB 32-bit 2:10:10:10"},
[0x2] = {DRM_FORMAT_XRGB, 32, "RGB 32-bit 8:8:8:8"},
+ [0x3] = {DRM_FORMAT_XRGB161616, 64,
+ "RGB 64-bit 16:16:16:16 Floating Point"},
[0x4] = {DRM_FORMAT_AYUV, 32,
"YUV 32-bit 4:4:4 packed (8:8:8:8 MSB-X:Y:U:V)"},
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/3] drm: Introduce RGB 64-bit 16:16:16:16 float format
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows
guest VM. This patch is to introduce the format to drm.
v1:
Suggested by Ville to submit this patch to dri-devel.
Signed-off-by: Xiaoguang Chen
Signed-off-by: Tina Zhang
---
include/uapi/drm/drm_fourcc.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 7586c46..3e002e3 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -113,6 +113,10 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/* 64 bpp RGB */
+#define DRM_FORMAT_XRGB161616 fourcc_code('X', 'R', '4', '8') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR161616 fourcc_code('X', 'B', '4', '8') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/3] drm/i915/gvt: Introduce framebuffer decoder
Framebuffer decoder is used by gvt device model to get the display plane information, which can be used for local and spice remote display. This patch set is used to introduce the framebuffer decoder to gvt. v1->v2: Rebase to the latest staging branch. Tina Zhang (3): drm/i915/gvt: Add framebuffer decoder support drm: Introduce RGB 64-bit 16:16:16:16 float format drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c| 2 +- drivers/gpu/drm/i915/gvt/display.h| 2 + drivers/gpu/drm/i915/gvt/fb_decoder.c | 440 ++ drivers/gpu/drm/i915/gvt/fb_decoder.h | 175 ++ drivers/gpu/drm/i915/gvt/gvt.h| 1 + include/uapi/drm/drm_fourcc.h | 4 + 7 files changed, 625 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/3] drm/i915/gvt: Add framebuffer decoder support
Framebuffer decoder returns guest framebuffer information.
Guest framebuffer includes primary, cursor and sprite plane.
Signed-off-by: Xiaoguang Chen
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gvt/Makefile | 3 +-
drivers/gpu/drm/i915/gvt/display.c| 2 +-
drivers/gpu/drm/i915/gvt/display.h| 2 +
drivers/gpu/drm/i915/gvt/fb_decoder.c | 429 ++
drivers/gpu/drm/i915/gvt/fb_decoder.h | 175 ++
drivers/gpu/drm/i915/gvt/gvt.h| 1 +
6 files changed, 610 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index f5486cb9..019d596 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,7 +1,8 @@
GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
- execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
+ execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
+ fb_decoder.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index 2deb05f..58d90cf 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
return 1;
}
-static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
{
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index d73de22..b46b868 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -179,4 +179,6 @@ int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64
resolution);
void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
+
#endif
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
new file mode 100644
index 000..2bd5b3c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -0,0 +1,429 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Kevin Tian
+ *
+ * Contributors:
+ *Bing Niu
+ *Xu Han
+ *Ping Gao
+ *Xiaoguang Chen
+ *Yang Liu
+ *Tina Zhang
+ *
+ */
+
+#include
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define PRIMARY_FORMAT_NUM 16
+struct pixel_format {
+ int drm_format; /* Pixel format in DRM definition */
+ int bpp;/* Bits per pixel, 0 indicates invalid */
+ char *desc; /* The description */
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
+ [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
+ [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
+ [0x6] = {DRM_FORMAT_XRGB, 32,
+ "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
+ [0x8] = {DRM_FORMAT_XBGR2101010, 32,
+ "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
+ [0xa] = {DRM_FORMAT_XRGB2101010, 32,
+ "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ [0xe] = {DRM_FORMAT_XBGR, 32,
+ "32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format skl_pixel_formats[] = {
+
[PATCH v1 3/3] drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows 10
guest VM. This patch is to add this pixel format support to gvt device
model. Without this patch, some Apps, e.g. "DXGIGammaVM.exe", will crash
and make guest screen black.
Signed-off-by: Xiaoguang Chen
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gvt/fb_decoder.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
index 2bd5b3c..739ca81 100644
--- a/drivers/gpu/drm/i915/gvt/fb_decoder.c
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -54,6 +54,8 @@ static struct pixel_format
bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
"32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
[0xa] = {DRM_FORMAT_XRGB2101010, 32,
"32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ [0xc] = {DRM_FORMAT_XRGB161616, 64,
+ "64-bit RGBX Floating Point(16:16:16:16 MSB-X:B:G:R)"},
[0xe] = {DRM_FORMAT_XBGR, 32,
"32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
};
@@ -75,6 +77,10 @@ static struct pixel_format skl_pixel_formats[] = {
{DRM_FORMAT_XBGR2101010, 32, "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
{DRM_FORMAT_XRGB2101010, 32, "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ {DRM_FORMAT_XRGB161616, 64,
+ "64-bit XRGB (16:16:16:16 MSB-X:R:G:B)"},
+ {DRM_FORMAT_XBGR161616, 64,
+ "64-bit XBGR (16:16:16:16 MSB-X:B:G:R)"},
/* non-supported format has bpp default to 0 */
{0, 0, NULL},
@@ -101,6 +107,9 @@ static int skl_format_to_drm(int format, bool rgb_order,
bool alpha,
case PLANE_CTL_FORMAT_XRGB_2101010:
skl_pixel_formats_index = rgb_order ? 10 : 11;
break;
+ case PLANE_CTL_FORMAT_XRGB_16161616F:
+ skl_pixel_formats_index = rgb_order ? 12 : 13;
+ break;
case PLANE_CTL_FORMAT_YUV422:
skl_pixel_formats_index = yuv_order >> 16;
if (skl_pixel_formats_index > 3)
@@ -321,6 +330,8 @@ static struct pixel_format
sprite_pixel_formats[SPRITE_FORMAT_NUM] = {
[0x0] = {DRM_FORMAT_YUV422, 16, "YUV 16-bit 4:2:2 packed"},
[0x1] = {DRM_FORMAT_XRGB2101010, 32, "RGB 32-bit 2:10:10:10"},
[0x2] = {DRM_FORMAT_XRGB, 32, "RGB 32-bit 8:8:8:8"},
+ [0x3] = {DRM_FORMAT_XRGB161616, 64,
+ "RGB 64-bit 16:16:16:16 Floating Point"},
[0x4] = {DRM_FORMAT_AYUV, 32,
"YUV 32-bit 4:4:4 packed (8:8:8:8 MSB-X:Y:U:V)"},
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/3] drm: Introduce RGB 64-bit 16:16:16:16 float format
The RGB 64-bit 16:16:16:16 float pixel format is needed by windows
guest VM. This patch is to introduce the format to drm.
v1:
Suggested by Ville to submit this patch to dri-devel.
Signed-off-by: Xiaoguang Chen
Signed-off-by: Tina Zhang
---
include/uapi/drm/drm_fourcc.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 7586c46..3e002e3 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -113,6 +113,10 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
+/* 64 bpp RGB */
+#define DRM_FORMAT_XRGB161616 fourcc_code('X', 'R', '4', '8') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR161616 fourcc_code('X', 'B', '4', '8') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
/*
* 2 plane RGB + A
* index 0 = RGB plane, same format as the corresponding non _A8 format has
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/3] drm/i915/gvt: Introduce framebuffer decoder
Framebuffer decoder is used by gvt device model to get the display plane information, which can be used for local and spice remote display. This patch set is used to introduce the framebuffer decoder to gvt. Tina Zhang (3): drm/i915/gvt: Add framebuffer decoder support drm: Introduce RGB 64-bit 16:16:16:16 float format drm/i915/gvt: Add RGB 64-bit 16:16:16:16 float format support drivers/gpu/drm/i915/gvt/Makefile | 3 +- drivers/gpu/drm/i915/gvt/display.c| 2 +- drivers/gpu/drm/i915/gvt/display.h| 2 + drivers/gpu/drm/i915/gvt/fb_decoder.c | 440 ++ drivers/gpu/drm/i915/gvt/fb_decoder.h | 175 ++ drivers/gpu/drm/i915/gvt/gvt.h| 1 + include/uapi/drm/drm_fourcc.h | 4 + 7 files changed, 625 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/3] drm/i915/gvt: Add framebuffer decoder support
Framebuffer decoder returns guest framebuffer information.
Guest framebuffer includes primary, cursor and sprite plane.
Signed-off-by: Xiaoguang Chen
Signed-off-by: Tina Zhang
---
drivers/gpu/drm/i915/gvt/Makefile | 3 +-
drivers/gpu/drm/i915/gvt/display.c| 2 +-
drivers/gpu/drm/i915/gvt/display.h| 2 +
drivers/gpu/drm/i915/gvt/fb_decoder.c | 429 ++
drivers/gpu/drm/i915/gvt/fb_decoder.h | 175 ++
drivers/gpu/drm/i915/gvt/gvt.h| 1 +
6 files changed, 610 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.c
create mode 100644 drivers/gpu/drm/i915/gvt/fb_decoder.h
diff --git a/drivers/gpu/drm/i915/gvt/Makefile
b/drivers/gpu/drm/i915/gvt/Makefile
index f5486cb9..019d596 100644
--- a/drivers/gpu/drm/i915/gvt/Makefile
+++ b/drivers/gpu/drm/i915/gvt/Makefile
@@ -1,7 +1,8 @@
GVT_DIR := gvt
GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \
interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \
- execlist.o scheduler.o sched_policy.o render.o cmd_parser.o
+ execlist.o scheduler.o sched_policy.o render.o cmd_parser.o \
+ fb_decoder.o
ccflags-y += -I$(src) -I$(src)/$(GVT_DIR)
i915-y += $(addprefix $(GVT_DIR)/,
$(GVT_SOURCE))
diff --git a/drivers/gpu/drm/i915/gvt/display.c
b/drivers/gpu/drm/i915/gvt/display.c
index 2deb05f..58d90cf 100644
--- a/drivers/gpu/drm/i915/gvt/display.c
+++ b/drivers/gpu/drm/i915/gvt/display.c
@@ -67,7 +67,7 @@ static int edp_pipe_is_enabled(struct intel_vgpu *vgpu)
return 1;
}
-static int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe)
{
struct drm_i915_private *dev_priv = vgpu->gvt->dev_priv;
diff --git a/drivers/gpu/drm/i915/gvt/display.h
b/drivers/gpu/drm/i915/gvt/display.h
index d73de22..b46b868 100644
--- a/drivers/gpu/drm/i915/gvt/display.h
+++ b/drivers/gpu/drm/i915/gvt/display.h
@@ -179,4 +179,6 @@ int intel_vgpu_init_display(struct intel_vgpu *vgpu, u64
resolution);
void intel_vgpu_reset_display(struct intel_vgpu *vgpu);
void intel_vgpu_clean_display(struct intel_vgpu *vgpu);
+int pipe_is_enabled(struct intel_vgpu *vgpu, int pipe);
+
#endif
diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c
b/drivers/gpu/drm/i915/gvt/fb_decoder.c
new file mode 100644
index 000..2bd5b3c
--- /dev/null
+++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c
@@ -0,0 +1,429 @@
+/*
+ * Copyright(c) 2011-2016 Intel Corporation. All rights reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ *
+ * Authors:
+ *Kevin Tian
+ *
+ * Contributors:
+ *Bing Niu
+ *Xu Han
+ *Ping Gao
+ *Xiaoguang Chen
+ *Yang Liu
+ *Tina Zhang
+ *
+ */
+
+#include
+#include "i915_drv.h"
+#include "gvt.h"
+
+#define PRIMARY_FORMAT_NUM 16
+struct pixel_format {
+ int drm_format; /* Pixel format in DRM definition */
+ int bpp;/* Bits per pixel, 0 indicates invalid */
+ char *desc; /* The description */
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format bdw_pixel_formats[PRIMARY_FORMAT_NUM] = {
+ [0x2] = {DRM_FORMAT_C8, 8, "8-bit Indexed"},
+ [0x5] = {DRM_FORMAT_RGB565, 16, "16-bit BGRX (5:6:5 MSB-R:G:B)"},
+ [0x6] = {DRM_FORMAT_XRGB, 32,
+ "32-bit BGRX (8:8:8:8 MSB-X:R:G:B)"},
+ [0x8] = {DRM_FORMAT_XBGR2101010, 32,
+ "32-bit RGBX (2:10:10:10 MSB-X:B:G:R)"},
+ [0xa] = {DRM_FORMAT_XRGB2101010, 32,
+ "32-bit BGRX (2:10:10:10 MSB-X:R:G:B)"},
+ [0xe] = {DRM_FORMAT_XBGR, 32,
+ "32-bit RGBX (8:8:8:8 MSB-X:B:G:R)"},
+};
+
+/* non-supported format has bpp default to 0 */
+static struct pixel_format skl_pixel_formats[] = {
+
Re: [PATCH v2 1/5] drm/rockchip: vop: get rid of register init table
On 2017年07月14日 04:29, Sean Paul wrote:
On Thu, Jul 13, 2017 at 09:33:45AM +0800, Mark yao wrote:
On 2017年07月13日 00:47, Sean Paul wrote:
On Wed, Jul 12, 2017 at 10:03:27AM +0800, Mark Yao wrote:
Register init table use un-document define, it is unreadable,
And sometimes we only want to update tiny bits, init table
method is not friendly, it's diffcult to reuse for difference
chips.
While I'm happy to see the init_table removed, it seems like the new code is not
equivalent to the old (ie: some register writes have been dropped). How did you
ensure that you're not breaking existing boards that depend on the deleted
register
initialization?
Sean
All the existing boards works fine on my internal kernel board with the
init_table removed,
We had tested all the existing boards, so it's no problem to removed init_table
That begs the question... why was it introduced if it's not necessary?
Hi Sean
Some registers need to be initialized when vop power on, global_config_done,
blank, win gate, etc.
Previously init_table was introduced to handle the initialization of these
registers.
So, when we remove the init_table mechanism, we need to re-join the
initialization of these registers,
this job is already done in this patch.
I think the title "get rid of" caused some doubts, it's not just remove
init_table mechanism,
to be exact, direct setting needed register instead of handling with init_table.
I will make it cleaner next version.
Thanks.
Sean
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 10 ++-
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 43
+++--
3 files changed, 10 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 45589d6..7a5f809 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1393,7 +1393,6 @@ static void vop_destroy_crtc(struct vop *vop)
static int vop_initial(struct vop *vop)
{
const struct vop_data *vop_data = vop->data;
- const struct vop_reg_data *init_table = vop_data->init_table;
struct reset_control *ahb_rst;
int i, ret;
@@ -1453,13 +1452,14 @@ static int vop_initial(struct vop *vop)
memcpy(vop->regsbak, vop->regs, vop->len);
- for (i = 0; i < vop_data->table_size; i++)
- vop_writel(vop, init_table[i].offset, init_table[i].value);
+ VOP_CTRL_SET(vop, global_regdone_en, 1);
+ VOP_CTRL_SET(vop, dsp_blank, 0);
for (i = 0; i < vop_data->win_size; i++) {
const struct vop_win_data *win = &vop_data->win[i];
VOP_WIN_SET(vop, win, enable, 0);
+ VOP_WIN_SET(vop, win, gate, 1);
}
vop_cfg_done(vop);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 9979fd0..084d3b2 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -24,11 +24,6 @@ enum vop_data_format {
VOP_FMT_YUV444SP,
};
-struct vop_reg_data {
- uint32_t offset;
- uint32_t value;
-};
-
struct vop_reg {
uint32_t offset;
uint32_t shift;
@@ -46,6 +41,7 @@ struct vop_ctrl {
struct vop_reg hdmi_en;
struct vop_reg mipi_en;
struct vop_reg dp_en;
+ struct vop_reg dsp_blank;
struct vop_reg out_mode;
struct vop_reg dither_down;
struct vop_reg dither_up;
@@ -65,6 +61,7 @@ struct vop_ctrl {
struct vop_reg line_flag_num[2];
+ struct vop_reg global_regdone_en;
struct vop_reg cfg_done;
};
@@ -115,6 +112,7 @@ struct vop_win_phy {
uint32_t nformats;
struct vop_reg enable;
+ struct vop_reg gate;
struct vop_reg format;
struct vop_reg rb_swap;
struct vop_reg act_info;
@@ -136,8 +134,6 @@ struct vop_win_data {
};
struct vop_data {
- const struct vop_reg_data *init_table;
- unsigned int table_size;
const struct vop_ctrl *ctrl;
const struct vop_intr *intr;
const struct vop_win_data *win;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index bafd698..00e9d79 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -127,13 +127,7 @@
.cfg_done = VOP_REG(RK3036_REG_CFG_DONE, 0x1, 0),
};
-static const struct vop_reg_data rk3036_vop_init_reg_table[] = {
- {RK3036_DSP_CTRL1, 0x},
-};
-
static const struct vop_data rk3036_vop = {
- .init_table = rk3036_vop_init_reg_table,
- .table_size = ARRAY_SIZE(rk3036_vop_init_reg_table),
.ctrl = &rk3036_ctrl_data,
.intr = &rk3036_intr,
.win = rk3036_vop_win_data,
@@ -193,7 +187,8 @@
static const struct vop_win_phy rk328
[PATCH] drm/panel: simple: Remove unneeded gpiod NULL check
From: Fabio Estevam The gpiod API checks for NULL descriptors, so there is no need to duplicate the check in the driver. Signed-off-by: Fabio Estevam --- drivers/gpu/drm/panel/panel-simple.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 474fa75..8c0d6a6 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -187,8 +187,7 @@ static int panel_simple_unprepare(struct drm_panel *panel) if (!p->prepared) return 0; - if (p->enable_gpio) - gpiod_set_value_cansleep(p->enable_gpio, 0); + gpiod_set_value_cansleep(p->enable_gpio, 0); regulator_disable(p->supply); @@ -214,8 +213,7 @@ static int panel_simple_prepare(struct drm_panel *panel) return err; } - if (p->enable_gpio) - gpiod_set_value_cansleep(p->enable_gpio, 1); + gpiod_set_value_cansleep(p->enable_gpio, 1); if (p->desc->delay.prepare) msleep(p->desc->delay.prepare); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=99801 --- Comment #14 from Matthew Treinish --- Just for some more information I gave the current tip of the amd-staging-4.11 branch on https://cgit.freedesktop.org/~agd5f/linux/ (commit 308514e6861e) a try and it was still having the same problems driving my monitor at 5120x2880. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100387] War Thunder game has visual errors, missing textures
https://bugs.freedesktop.org/show_bug.cgi?id=100387 --- Comment #5 from Hi-Angel --- Sorry for long time not answering. The error is because one instruction is using more than 2 cfiles which check_and_set_bank_swizzle() doesn't allow, though acc. to docs it can handle up to 4 distinct cfiles in a group. I was trying to fix it be rewriting the bank_swizzle scheduler into smarter version, but had to abandon it because it turned out to be pointless (the effeciency is about the same, but more importantly, for some reason r600g have 2 schedulers, and this one simply does validation). FTR, unfinished code is here https://github.com/Hi-Angel/mesa/tree/wip-bank_swizzle-scheduler I am not sure if I'll have a motivation to look into modifying the current scheduler, the more that there's some oddness in documentation (you can say "pun intended" because it is that docs don't allow odd number of distinct cfiles in a group, however a group with 1 cfile works just fine). But fixing this bug won't help to the game anyway, because the next problem it runs into is a very old one of requiring too many GPRs https://bugs.freedesktop.org/buglist.cgi?quicksearch=Shader%20GPR%20limit%20exceeded&list_id=619399 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99349] Failed to build shader (translation from TGSI)
https://bugs.freedesktop.org/show_bug.cgi?id=99349 --- Comment #17 from Gert Wollny --- An updated version of the patch set is currently under review: https://patchwork.freedesktop.org/series/25594/ -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dim: Switch Link: tags to https://
Dear Daniel, Am Sonntag, den 16.07.2017, 12:26 +0200 schrieb Daniel Vetter: > http: gets a "301 moved permanently" reply. > > Reported-by: Paul Menzel > Cc: Paul Menzel > Signed-off-by: Daniel Vetter Reviewed-by: Paul Menzel Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101787] colours all messed up
https://bugs.freedesktop.org/show_bug.cgi?id=101787 --- Comment #1 from 247 --- just a quick update...tried edit an mp4 video and even converting with transmageddon but the result is the same...is there any solution to this?it is solvable by a mesa update?or i just have to surrender? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling
On Sun, Jul 16, 2017 at 12:43 AM, Mike Galbraith wrote: > On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote: >> >> OK, so this issue appears to be that we're calling >> drm_crtc_vblank_off() on a crtc for which vblank is already disabled. >> My guess is that this happens because the crtc is disabled. >> >> Not sure what the proper check is to see if vblanks are already disabled... > > Seems so, the below shut up suspend for both 8600 GT and GTX 980. The modeset done by drm_atomic_helper_suspend (called previously to that *_fini) should already take care of disabling vblanks, I think. So the vblank_off calls can just be done when we're not doing an atomic modeset [drm_drv_uses_atomic_modeset(dev)] -- this is all very confusing since pre-nv50 uses legacy modesets, while nv50+ has been moved to atomic, but they share a bunch of helpers =/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101802] Radeon HD5870: Can't get 60HZ monitor refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=101802 Michel Dänzer changed: What|Removed |Added Product|xorg|DRI Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Version|7.7 (2012.06) |unspecified QA Contact|xorg-t...@lists.x.org | Component|Driver/Radeon |DRM/Radeon -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 3/3] drm/vc4: add HDMI CEC support
From: Hans Verkuil
This patch adds support to VC4 for CEC.
Thanks to Eric Anholt for providing me with the CEC register information.
To prevent the firmware from eating the CEC interrupts you need to add this to
your config.txt:
mask_gpu_interrupt1=0x100
Signed-off-by: Hans Verkuil
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/Kconfig| 8 ++
drivers/gpu/drm/vc4/vc4_hdmi.c | 227 +++--
drivers/gpu/drm/vc4/vc4_regs.h | 113
3 files changed, 342 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
index 4361bdcfd28a..fdae18aeab4f 100644
--- a/drivers/gpu/drm/vc4/Kconfig
+++ b/drivers/gpu/drm/vc4/Kconfig
@@ -19,3 +19,11 @@ config DRM_VC4
This driver requires that "avoid_warnings=2" be present in
the config.txt for the firmware, to keep it from smashing
our display setup.
+
+config DRM_VC4_HDMI_CEC
+ bool "Broadcom VC4 HDMI CEC Support"
+ depends on DRM_VC4
+ select CEC_CORE
+ help
+ Choose this option if you have a Broadcom VC4 GPU
+ and want to use CEC.
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index e0104f96011e..761b95f5deed 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -57,9 +57,14 @@
#include
#include
#include
+#include "media/cec.h"
#include "vc4_drv.h"
#include "vc4_regs.h"
+#define HSM_CLOCK_FREQ 163682864
+#define CEC_CLOCK_FREQ 4
+#define CEC_CLOCK_DIV (HSM_CLOCK_FREQ / CEC_CLOCK_FREQ)
+
/* HDMI audio information */
struct vc4_hdmi_audio {
struct snd_soc_card card;
@@ -85,6 +90,11 @@ struct vc4_hdmi {
int hpd_gpio;
bool hpd_active_low;
+ struct cec_adapter *cec_adap;
+ struct cec_msg cec_rx_msg;
+ bool cec_tx_ok;
+ bool cec_irq_was_rx;
+
struct clk *pixel_clock;
struct clk *hsm_clock;
};
@@ -149,6 +159,23 @@ static const struct {
HDMI_REG(VC4_HDMI_VERTB1),
HDMI_REG(VC4_HDMI_TX_PHY_RESET_CTL),
HDMI_REG(VC4_HDMI_TX_PHY_CTL0),
+
+ HDMI_REG(VC4_HDMI_CEC_CNTRL_1),
+ HDMI_REG(VC4_HDMI_CEC_CNTRL_2),
+ HDMI_REG(VC4_HDMI_CEC_CNTRL_3),
+ HDMI_REG(VC4_HDMI_CEC_CNTRL_4),
+ HDMI_REG(VC4_HDMI_CEC_CNTRL_5),
+ HDMI_REG(VC4_HDMI_CPU_STATUS),
+ HDMI_REG(VC4_HDMI_CPU_MASK_STATUS),
+
+ HDMI_REG(VC4_HDMI_CEC_RX_DATA_1),
+ HDMI_REG(VC4_HDMI_CEC_RX_DATA_2),
+ HDMI_REG(VC4_HDMI_CEC_RX_DATA_3),
+ HDMI_REG(VC4_HDMI_CEC_RX_DATA_4),
+ HDMI_REG(VC4_HDMI_CEC_TX_DATA_1),
+ HDMI_REG(VC4_HDMI_CEC_TX_DATA_2),
+ HDMI_REG(VC4_HDMI_CEC_TX_DATA_3),
+ HDMI_REG(VC4_HDMI_CEC_TX_DATA_4),
};
static const struct {
@@ -216,8 +243,8 @@ vc4_hdmi_connector_detect(struct drm_connector *connector,
bool force)
if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio) ^
vc4->hdmi->hpd_active_low)
return connector_status_connected;
- else
- return connector_status_disconnected;
+ cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
+ return connector_status_disconnected;
}
if (drm_probe_ddc(vc4->hdmi->ddc))
@@ -225,8 +252,8 @@ vc4_hdmi_connector_detect(struct drm_connector *connector,
bool force)
if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
return connector_status_connected;
- else
- return connector_status_disconnected;
+ cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
+ return connector_status_disconnected;
}
static void vc4_hdmi_connector_destroy(struct drm_connector *connector)
@@ -247,6 +274,7 @@ static int vc4_hdmi_connector_get_modes(struct
drm_connector *connector)
struct edid *edid;
edid = drm_get_edid(connector, vc4->hdmi->ddc);
+ cec_s_phys_addr_from_edid(vc4->hdmi->cec_adap, edid);
if (!edid)
return -ENODEV;
@@ -1121,6 +1149,159 @@ static void vc4_hdmi_audio_cleanup(struct vc4_hdmi
*hdmi)
snd_soc_unregister_codec(dev);
}
+#ifdef CONFIG_DRM_VC4_HDMI_CEC
+static irqreturn_t vc4_cec_irq_handler_thread(int irq, void *priv)
+{
+ struct vc4_dev *vc4 = priv;
+ struct vc4_hdmi *hdmi = vc4->hdmi;
+
+ if (hdmi->cec_irq_was_rx) {
+ if (hdmi->cec_rx_msg.len)
+ cec_received_msg(hdmi->cec_adap, &hdmi->cec_rx_msg);
+ } else if (hdmi->cec_tx_ok) {
+ cec_transmit_done(hdmi->cec_adap, CEC_TX_STATUS_OK,
+ 0, 0, 0, 0);
+ } else {
+ /*
+* This CEC implementation makes 1 retry, so if we
+* get a NACK, then that means it made 2 attempts.
+*/
+ cec_transmit_done(hdmi->cec_adap, CEC_TX_STATUS_NACK,
+ 0, 2, 0, 0);
+
[PATCHv2 0/3] drm/vc4: add HDMI CEC support
From: Hans Verkuil This patch series adds support for HDMI CEC to the vc4 drm driver. This series is based on 4.13-rc1. Note: the first cec patch is independent of the vc4 patches and will be merged via the media subsystem for 4.14. Without that patch everything will still work, but it will attempt to retry messages twice as many times as it should. This has been tested with the Raspberry Pi 2B and 3B. I don't have older rpi's, so I can't test those. Many thanks to Eric Anholt for his help with this driver! There is one open issue: when booting the rpi without an HDMI cable connected, then CEC won't work. But neither apparently does HDMI since reconnecting it will not bring back any display. If you boot with the HDMI cable connected, then all is well and disconnecting and reconnecting the cable will do the right thing. I don't understand what is going on here, but it does not appear to be CEC related and the same problem occurs without this patch series. You also need to update your config.txt with this line to prevent the firmware from eating the CEC interrupts: mask_gpu_interrupt1=0x100 Eric, I've experimented with setting hdmi_ignore_cec=1 but that simply doesn't work. Instead that disables CEC completely. With this mask_gpu_interrupt1 setting everything works perfectly. This also prevents the firmware from sending the initial Active Source CEC message so the CPU has full control over the CEC bus, as it should. My main concern is that this is rather magical, but it is not something I have any control over. Changes since v1: - Merged patch 3 and 4 together as suggested by Eric. - The clock divider is now set explicitly instead of relying on the default value. Regards, Hans Hans Verkuil (3): cec: be smarter about detecting the number of attempts made drm/vc4: prepare for CEC support drm/vc4: add HDMI CEC support drivers/gpu/drm/vc4/Kconfig| 8 ++ drivers/gpu/drm/vc4/vc4_hdmi.c | 284 - drivers/gpu/drm/vc4/vc4_regs.h | 113 drivers/media/cec/cec-adap.c | 9 +- 4 files changed, 377 insertions(+), 37 deletions(-) -- 2.13.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 2/3] drm/vc4: prepare for CEC support
From: Hans Verkuil
In order to support CEC the hsm clock needs to be enabled in
vc4_hdmi_bind(), not in vc4_hdmi_encoder_enable(). Otherwise you wouldn't
be able to support CEC when there is no hotplug detect signal, which is
required by some monitors that turn off the HPD when in standby, but keep
the CEC bus alive so they can be woken up.
The HDMI core also has to be enabled in vc4_hdmi_bind() for the same
reason.
Signed-off-by: Hans Verkuil
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 59 +-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index ed63d4e85762..e0104f96011e 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -463,11 +463,6 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
*encoder)
HD_WRITE(VC4_HD_VID_CTL,
HD_READ(VC4_HD_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
- HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_SW_RST);
- udelay(1);
- HD_WRITE(VC4_HD_M_CTL, 0);
-
- clk_disable_unprepare(hdmi->hsm_clock);
clk_disable_unprepare(hdmi->pixel_clock);
ret = pm_runtime_put(&hdmi->pdev->dev);
@@ -509,16 +504,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
*encoder)
return;
}
- /* This is the rate that is set by the firmware. The number
-* needs to be a bit higher than the pixel clock rate
-* (generally 148.5Mhz).
-*/
- ret = clk_set_rate(hdmi->hsm_clock, 163682864);
- if (ret) {
- DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
- return;
- }
-
ret = clk_set_rate(hdmi->pixel_clock,
mode->clock * 1000 *
((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
@@ -533,20 +518,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
*encoder)
return;
}
- ret = clk_prepare_enable(hdmi->hsm_clock);
- if (ret) {
- DRM_ERROR("Failed to turn on HDMI state machine clock: %d\n",
- ret);
- clk_disable_unprepare(hdmi->pixel_clock);
- return;
- }
-
- HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_SW_RST);
- udelay(1);
- HD_WRITE(VC4_HD_M_CTL, 0);
-
- HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_ENABLE);
-
HDMI_WRITE(VC4_HDMI_SW_RESET_CONTROL,
VC4_HDMI_SW_RESET_HDMI |
VC4_HDMI_SW_RESET_FORMAT_DETECT);
@@ -1205,6 +1176,23 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
return -EPROBE_DEFER;
}
+ /* This is the rate that is set by the firmware. The number
+* needs to be a bit higher than the pixel clock rate
+* (generally 148.5Mhz).
+*/
+ ret = clk_set_rate(hdmi->hsm_clock, 163682864);
+ if (ret) {
+ DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
+ goto err_put_i2c;
+ }
+
+ ret = clk_prepare_enable(hdmi->hsm_clock);
+ if (ret) {
+ DRM_ERROR("Failed to turn on HDMI state machine clock: %d\n",
+ ret);
+ goto err_put_i2c;
+ }
+
/* Only use the GPIO HPD pin if present in the DT, otherwise
* we'll use the HDMI core's register.
*/
@@ -1216,7 +1204,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
&hpd_gpio_flags);
if (hdmi->hpd_gpio < 0) {
ret = hdmi->hpd_gpio;
- goto err_put_i2c;
+ goto err_unprepare_hsm;
}
hdmi->hpd_active_low = hpd_gpio_flags & OF_GPIO_ACTIVE_LOW;
@@ -1224,6 +1212,14 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
vc4->hdmi = hdmi;
+ /* HDMI core must be enabled. */
+ if (!(HD_READ(VC4_HD_M_CTL) & VC4_HD_M_ENABLE)) {
+ HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_SW_RST);
+ udelay(1);
+ HD_WRITE(VC4_HD_M_CTL, 0);
+
+ HD_WRITE(VC4_HD_M_CTL, VC4_HD_M_ENABLE);
+ }
pm_runtime_enable(dev);
drm_encoder_init(drm, hdmi->encoder, &vc4_hdmi_encoder_funcs,
@@ -1244,6 +1240,8 @@ static int vc4_hdmi_bind(struct device *dev, struct
device *master, void *data)
err_destroy_encoder:
vc4_hdmi_encoder_destroy(hdmi->encoder);
+err_unprepare_hsm:
+ clk_disable_unprepare(hdmi->hsm_clock);
pm_runtime_disable(dev);
err_put_i2c:
put_device(&hdmi->ddc->dev);
@@ -1263,6 +1261,7 @@ static void vc4_hdmi_unbind(struct device *dev, struct
device *master,
vc4_hdmi_connector_destroy(hdmi->connector);
vc4_hdmi_encoder_destroy(hdmi->encoder);
+ clk_disable_unprepare(hdmi->hsm_clo
[PATCHv2 1/3] cec: be smarter about detecting the number of attempts made
From: Hans Verkuil
Some hardware does more than one attempt. So when it calls
cec_transmit_done when an error occurred it will e.g. use an error count
of 2 instead of 1.
The framework always assumed a single attempt, but now it is smarter
and will sum the counters to detect how many attempts were made.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index bf45977b2823..e9284dbdc880 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -472,9 +472,14 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
{
struct cec_data *data;
struct cec_msg *msg;
+ unsigned int attempts_made = arb_lost_cnt + nack_cnt +
+low_drive_cnt + error_cnt;
u64 ts = ktime_get_ns();
dprintk(2, "%s: status %02x\n", __func__, status);
+ if (attempts_made < 1)
+ attempts_made = 1;
+
mutex_lock(&adap->lock);
data = adap->transmitting;
if (!data) {
@@ -507,10 +512,10 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
* the hardware didn't signal that it retried itself (by setting
* CEC_TX_STATUS_MAX_RETRIES), then we will retry ourselves.
*/
- if (data->attempts > 1 &&
+ if (data->attempts > attempts_made &&
!(status & (CEC_TX_STATUS_MAX_RETRIES | CEC_TX_STATUS_OK))) {
/* Retry this message */
- data->attempts--;
+ data->attempts -= attempts_made;
if (msg->timeout)
dprintk(2, "retransmit: %*ph (attempts: %d, wait for
0x%02x)\n",
msg->len, msg->msg, data->attempts, msg->reply);
--
2.13.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/vc4: add HDMI CEC support
On 12/07/17 21:43, Hans Verkuil wrote:
> On 12/07/17 21:02, Eric Anholt wrote:
>>> +static int vc4_hdmi_cec_adap_transmit(struct cec_adapter *adap, u8
>>> attempts,
>>> + u32 signal_free_time, struct cec_msg *msg)
>>> +{
>>> + struct vc4_dev *vc4 = cec_get_drvdata(adap);
>>> + u32 val;
>>> + unsigned int i;
>>> +
>>> + for (i = 0; i < msg->len; i += 4)
>>> + HDMI_WRITE(VC4_HDMI_CEC_TX_DATA_1 + i,
>>> + (msg->msg[i]) |
>>> + (msg->msg[i + 1] << 8) |
>>> + (msg->msg[i + 2] << 16) |
>>> + (msg->msg[i + 3] << 24));
>>> +
>>> + val = HDMI_READ(VC4_HDMI_CEC_CNTRL_1);
>>> + val &= ~VC4_HDMI_CEC_START_XMIT_BEGIN;
>>> + HDMI_WRITE(VC4_HDMI_CEC_CNTRL_1, val);
>>> + val &= ~VC4_HDMI_CEC_MESSAGE_LENGTH_MASK;
>>> + val |= (msg->len - 1) << VC4_HDMI_CEC_MESSAGE_LENGTH_SHIFT;
>>> + val |= VC4_HDMI_CEC_START_XMIT_BEGIN;
>>
>> It doesn't look to me like len should have 1 subtracted from it. The
>> field has 4 bits for our up-to-16-byte length, and the firmware seems to
>> be setting it to the same value as a memcpy for the message data uses.
>
> You need to subtract by one. The CEC protocol supports messages of 1-16
> bytes in length. Since the message length mask is only 4 bits you need to
> encode this in the value 0-15. Hence the '-1', otherwise you would never
> be able to send 16 byte messages.
>
> I actually found this when debugging the messages it was transmitting: they
> were one too long.
>
> This suggests that the firmware does this wrong. I don't have time tomorrow,
> but I'll see if I can do a quick test on Friday to verify that.
I double-checked this and both the driver and the firmware do the right thing.
Just to be certain I also tried sending a message that uses the full 16 byte
payload and that too went well. So the code is definitely correct.
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dim: Switch Link: tags to https://
http: gets a "301 moved permanently" reply. Reported-by: Paul Menzel Cc: Paul Menzel Signed-off-by: Daniel Vetter --- dim | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/dim b/dim index 79d616cbf354..1fcd8d73fe1e 100755 --- a/dim +++ b/dim @@ -749,7 +749,7 @@ function dim_apply_branch git am --scissors -3 $sob "$@" $file if [ -n "$message_id" ]; then - dim_commit_add_tag "Link: http://patchwork.freedesktop.org/patch/msgid/$message_id"; + dim_commit_add_tag "Link: https://patchwork.freedesktop.org/patch/msgid/$message_id"; else echoerr "WARNING: No message-id found in the patch file." rv=1 @@ -789,7 +789,7 @@ function dim_apply_pull git commit --amend -s --no-edit if [ -n "$message_id" ]; then - dim_commit_add_tag "Link: http://patchwork.freedesktop.org/patch/msgid/$message_id"; + dim_commit_add_tag "Link: https://patchwork.freedesktop.org/patch/msgid/$message_id"; else echoerr "WARNING: No message-id found in the patch file." rv=1 @@ -872,7 +872,7 @@ function dim_add_link rm -f $file if [[ -n "$message_id" ]]; then - dim_commit_add_tag "Link: http://patchwork.freedesktop.org/patch/msgid/$message_id"; + dim_commit_add_tag "Link: https://patchwork.freedesktop.org/patch/msgid/$message_id"; else echoerr "No message-id found in the patch file." fi -- 2.13.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm: radeon: constify pci_device_id.
Hi Christian,
On Saturday 15 July 2017 07:17 PM, Christian König wrote:
Am 15.07.2017 um 09:12 schrieb Arvind Yadav:
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by work with
const pci_device_id. So mark the non-const structs as const.
File size before:
text databssdechexfilename
6560 23212 72 29844 7494
gpu/drm/radeon/radeon_drv.o
File size After adding 'const':
text databssdechexfilename
28960812 72 29844 7494
gpu/drm/radeon/radeon_drv.o
Signed-off-by: Arvind Yadav
Impressive result for such a simple change.
Patch is Reviewed-by: Christian König
Are the PCI IDs already const in amdgpu or do we need a similar patch
there as well? I only see patch 1 of 5 in my inbox.
I have send all gpu patch to David Airlie. Please check with him.
Christian.
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e25cb51..b079937 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -298,7 +298,7 @@ module_param_named(uvd, radeon_uvd, int, 0444);
MODULE_PARM_DESC(vce, "vce enable/disable vce support (1 = enable,
0 = disable)");
module_param_named(vce, radeon_vce, int, 0444);
-static struct pci_device_id pciidlist[] = {
+static const struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
};
Regards,
~arvind
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling
On Sat, 2017-07-15 at 14:52 -0400, Ilia Mirkin wrote:
>
> OK, so this issue appears to be that we're calling
> drm_crtc_vblank_off() on a crtc for which vblank is already disabled.
> My guess is that this happens because the crtc is disabled.
>
> Not sure what the proper check is to see if vblanks are already disabled...
Seems so, the below shut up suspend for both 8600 GT and GTX 980.
---
drivers/gpu/drm/drm_vblank.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -323,6 +323,14 @@ void drm_vblank_disable_and_save(struct
spin_lock_irqsave(&dev->vblank_time_lock, irqflags);
/*
+* Always update the count and timestamp to maintain the
+* appearance that the counter has been ticking all along until
+* this time. This makes the count account for the entire time
+* between drm_crtc_vblank_on() and drm_crtc_vblank_off().
+*/
+ drm_update_vblank_count(dev, pipe, false);
+
+ /*
* Only disable vblank interrupts if they're enabled. This avoids
* calling the ->disable_vblank() operation in atomic context with the
* hardware potentially runtime suspended.
@@ -332,14 +340,6 @@ void drm_vblank_disable_and_save(struct
vblank->enabled = false;
}
- /*
-* Always update the count and timestamp to maintain the
-* appearance that the counter has been ticking all along until
-* this time. This makes the count account for the entire time
-* between drm_crtc_vblank_on() and drm_crtc_vblank_off().
-*/
- drm_update_vblank_count(dev, pipe, false);
-
spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags);
}
@@ -605,7 +605,7 @@ bool drm_calc_vbltimestamp_from_scanoutp
*/
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
- WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+ WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev) &&
vblank->enabled);
return false;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Please use HTTPS URLs for Patchwork references
Dear Linux folks, Currently commits contain non HTTPS URLs like below. ``` Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-7-ville.syrj...@linux.intel.com ``` I guess these are generated by scripts. Could you please update them to generate HTTPS URLs, as that’s where the “non-secure” URLs are redirected to? ``` $ curl -I http://patchwork.freedesktop.org HTTP/1.1 301 Moved Permanently Date: Sun, 16 Jul 2017 09:25:15 GMT Server: Apache/2.4.10 (Debian) Location: https://patchwork.freedesktop.org/ Content-Type: text/html; charset=iso-8859-1 ``` Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
