[PATCH v5 00/11] Add DRM for stih4xx platforms
On 16 July 2014 04:33, Rob Clark wrote: > On Tue, Jul 15, 2014 at 5:41 AM, Benjamin Gaignard > wrote: >> Hi all, >> >> Does version 6 fit to all your expectations ? >> If yes will you consider to merge it into drm-next ? >> If no, please tell me what need to be fixed. > > > I had another pass over the driver, and didn't find anything to > complain about, so for the series: > > Reviewed-by: Rob Clark Can I see a git tree of this with Rob's R-B on it? based off drm-next if possible, I'd like to do a quick pre-merge review of it, but I usually don't find anything too major. Dave.
[PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer
This patch series adds lpm tranfer support for video and command data. for this, this patch adds two flags, and makes mipi dsi host to send commands to lcd panel device with lpm if mode_flags of lcd panel driver includes lpm flag. and also it applies this feature to exynos mipi dsi driver. Changelog v2: - Add more describtions. - Enable High Speed clock only in case of stand by request. Inki Dae (2): drm/mipi-dsi: add (LPM) Low Power Mode transfer support drm/exynos: dsi: add LPM (Low Power Mode) transfer support drivers/gpu/drm/drm_mipi_dsi.c |3 +++ drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 -- include/drm/drm_mipi_dsi.h |4 3 files changed, 27 insertions(+), 2 deletions(-) -- 1.7.9.5
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.
MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.
MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.
And above two flags can be combined together to transfer command and video
data to Panel device.
MIPI DSI spec says,
"the host processor controls the desired mode of clock operation.
Host protocol and applications control Clock Lane operating mode
(High Speed or Low Power mode). System designers are responsible
for understanding the clock requirements for peripherals attached
to DSI and controlling clock behavior in accordance with those
requirements."
Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.
Changelog v2: just add more descriptions.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/drm_mipi_dsi.c |3 +++
include/drm/drm_mipi_dsi.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
unsigned int channel,
break;
}
+ if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
+ msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, &msg);
}
EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
#define MIPI_DSI_MODE_VSYNC_FLUSH BIT(8)
/* disable EoT packets in HS mode */
#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)
enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
--
1.7.9.5
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
This patch adds LPM transfer support for video or command data.
With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.
Changelog v2: Enable High Speed clock only in case of stand by request.
Signed-off-by: Inki Dae
Acked-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
- | DSIM_BYTE_CLK_SRC(0)
- | DSIM_TX_REQUEST_HSCLK;
+ | DSIM_BYTE_CLK_SRC(0);
+
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
}
+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+ bool enable)
+{
+ u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
+
+ reg &= ~DSIM_TX_REQUEST_HSCLK;
+ if (enable)
+ reg |= DSIM_TX_REQUEST_HSCLK;
+
+ writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
+}
+
static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
{
u32 reg;
@@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi
*dsi, bool enable)
{
u32 reg;
+ if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
+ exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
--
1.7.9.5
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #12 from Michel D?nzer --- (In reply to comment #11) > I'm guessing as of this patch this can be closed? > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > ?id=2062afb4f804afef61cbe62a30cac9a46e58e067 No, that's unrelated. BTW, the backtraces in Xorg log files aren't useful for diagnosing this kind of problem, so there's no point in attaching more Xorg log files just for that. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/f73909a8/attachment.html>
[PATCH 0/8] Upstreaming the Android build and misc fixes
A few updates: - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to *_H_FILES - Including the platform Android.mk files individually is not the right way to do. One needs to construct an array/list of Android.mks and include it. - The series including the above fixes can be found in branch fixes+android over at https://github.com/evelikov/libdrm. -Emil On 27/07/14 19:25, Emil Velikov wrote: > Hello list, > > Recently I've had a go at the Anroid builds and I felt ... inspired that > there are (at least) two downstream repositories that have the relevant > Android build, yet all of them use 6+month old libdrm. > Making even builds a pain in the neck :'( > > Are there any objections if we get the android build upstream ? AFAICS > it's nicely isolated from everything else + I've managed to reuse all > the source/headers lists. > > Note that the series lacks a couple of patches from the downstream > repos, yet adds support for radeon, nouveau and freedreno :) > > The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel > specific "hacks". If people are happy with the series then we can take > a look at the final bits. > > > Cheers, > Emil >
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #114 from Michel D?nzer --- (In reply to comment #108) > Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of: > > [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip > > completion event has impossible msc 2822274 < target_msc 2822275 These are fixed in drm-fixes-3.16, but that hasn't been merged into drm-next-3.17-wip yet. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/edf3b1bd/attachment.html>
[PATCH] drm: add checking DRM_FORMAT_NV12MT
If user NV12MT uses as pixel format, the Addfb2 ioctl is failed because of missing to check DRM_FORMAT_NV12MT. The NV12MT pixel format is supported by exynos4 and some qualcomm chipset and it is used by exynos drm driver. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/drm_crtc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 1ccf5cb..5d7bd49 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -2960,6 +2960,7 @@ static int format_check(const struct drm_mode_fb_cmd2 *r) case DRM_FORMAT_NV61: case DRM_FORMAT_NV24: case DRM_FORMAT_NV42: + case DRM_FORMAT_NV12MT: case DRM_FORMAT_YUV410: case DRM_FORMAT_YVU410: case DRM_FORMAT_YUV411: @@ -4800,6 +4801,7 @@ int drm_format_num_planes(uint32_t format) case DRM_FORMAT_NV61: case DRM_FORMAT_NV24: case DRM_FORMAT_NV42: + case DRM_FORMAT_NV12MT: return 2; default: return 1; @@ -4835,6 +4837,7 @@ int drm_format_plane_cpp(uint32_t format, int plane) case DRM_FORMAT_NV61: case DRM_FORMAT_NV24: case DRM_FORMAT_NV42: + case DRM_FORMAT_NV12MT: return plane ? 2 : 1; case DRM_FORMAT_YUV410: case DRM_FORMAT_YVU410: @@ -4878,6 +4881,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format) case DRM_FORMAT_NV21: case DRM_FORMAT_NV16: case DRM_FORMAT_NV61: + case DRM_FORMAT_NV12MT: case DRM_FORMAT_YUV422: case DRM_FORMAT_YVU422: case DRM_FORMAT_YUV420: @@ -4907,6 +4911,7 @@ int drm_format_vert_chroma_subsampling(uint32_t format) case DRM_FORMAT_YVU420: case DRM_FORMAT_NV12: case DRM_FORMAT_NV21: + case DRM_FORMAT_NV12MT: return 2; default: return 1; -- 1.8.1.2
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
Hi Andreas, On 7/27/14, Andreas F?rber wrote: > Hi Ajay, > > Am 25.07.2014 21:22, schrieb Ajay Kumar: >> This series is based on exynos-drm-next branch of Inki Dae's tree at: >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> I have tested this after adding few DT changes for exynos5250-snow, >> exynos5420-peach-pit and exynos5800-peach-pi boards. > > I'm trying to test this with a modified exynos5250-spring DT based off > kgene's for-next branch due to DT, and I run into the following: > > CC drivers/gpu/drm/bridge/ptn3460.o > drivers/gpu/drm/bridge/ptn3460.c: In function ?ptn3460_post_encoder_init?: > drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of > function ?drm_connector_register? [-Werror=implicit-function-declaration] > drm_connector_register(&ptn_bridge->connector); > ^ Hope this might help: http://www.spinics.net/lists/dri-devel/msg60578.html Switch back to drm_sysfs_connector_add if your kernel doesn't have this patch. Ajay > cc1: some warnings being treated as errors > scripts/Makefile.build:257: recipe for target > 'drivers/gpu/drm/bridge/ptn3460.o' failed > make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1 > scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge' > failed > make[3]: *** [drivers/gpu/drm/bridge] Error 2 > make[3]: *** Warte auf noch nicht beendete Prozesse... > scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed > make[2]: *** [drivers/gpu/drm] Error 2 > scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed > make[1]: *** [drivers/gpu] Error 2 > Makefile:899: recipe for target 'drivers' failed > make: *** [drivers] Error 2 > > Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree, > and it must be new since v4. > > Thanks, > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg >
[PATCH] radeon: fix typo in sample split / fixes MSAA on Hawaii
On 27.07.2014 03:12, Marek Ol??k wrote: > From: Marek Ol??k > > --- > radeon/radeon_surface.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c > index 9c3a192..8a1fe7d 100644 > --- a/radeon/radeon_surface.c > +++ b/radeon/radeon_surface.c > @@ -1914,7 +1914,7 @@ static void cik_get_2d_params(struct > radeon_surface_manager *surf_man, > sample_split = 1; > break; > case CIK__SAMPLE_SPLIT__2: > -sample_split = 1; > +sample_split = 2; > break; > case CIK__SAMPLE_SPLIT__4: > sample_split = 4; > Reviewed-by: Michel D?nzer -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH 0/8] Upstreaming the Android build and misc fixes
On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote: > A few updates: > > - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to > *_H_FILES > - Including the platform Android.mk files individually is not the right way > to do. One needs to construct an array/list of Android.mks and include it. > > - The series including the above fixes can be found in branch fixes+android > over at https://github.com/evelikov/libdrm. Adding Tim Gore who's working on Android.mk support for i-g-t from our side and probably knows whom to poke for the intel side of things for libdrm Android ports. -Daniel > > -Emil > > On 27/07/14 19:25, Emil Velikov wrote: > > Hello list, > > > > Recently I've had a go at the Anroid builds and I felt ... inspired that > > there are (at least) two downstream repositories that have the relevant > > Android build, yet all of them use 6+month old libdrm. > > Making even builds a pain in the neck :'( > > > > Are there any objections if we get the android build upstream ? AFAICS > > it's nicely isolated from everything else + I've managed to reuse all > > the source/headers lists. > > > > Note that the series lacks a couple of patches from the downstream > > repos, yet adds support for radeon, nouveau and freedreno :) > > > > The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel > > specific "hacks". If people are happy with the series then we can take > > a look at the final bits. > > > > > > Cheers, > > Emil > > > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/exynos: hdmi: add null check for hdmiphy_port
The hdmiphy can be apb and hdmiphy_port can be null. So before accessing hdmiphy_port, it should be checked. Signed-off-by: Seung-Woo Kim --- drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c index fd8141f..54d97f7 100644 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c @@ -2520,7 +2520,8 @@ static int hdmi_remove(struct platform_device *pdev) if (hdata->res.reg_hdmi_en) regulator_disable(hdata->res.reg_hdmi_en); - put_device(&hdata->hdmiphy_port->dev); + if (hdata->hdmiphy_port) + put_device(&hdata->hdmiphy_port->dev); put_device(&hdata->ddc_adpt->dev); pm_runtime_disable(&pdev->dev); -- 1.7.4.1
[PATCH v5 00/11] Add DRM for stih4xx platforms
Hello Dave, You can found the patcheset with Rob's reviewed-by tag here: git://git.linaro.org/people/benjamin.gaignard/kernel.git on drm_kms_for_next-v7 branch It is the same code (drm_kms_for_next-v6) than what Rob has reviewed, rebased (and tested) on top of drm-next. The only changes are clocks typo (upper to lower case) in binding documentation. Regards, Benjamin 2014-07-28 1:23 GMT+02:00 Dave Airlie : > On 16 July 2014 04:33, Rob Clark wrote: >> On Tue, Jul 15, 2014 at 5:41 AM, Benjamin Gaignard >> wrote: >>> Hi all, >>> >>> Does version 6 fit to all your expectations ? >>> If yes will you consider to merge it into drm-next ? >>> If no, please tell me what need to be fixed. >> >> >> I had another pass over the driver, and didn't find anything to >> complain about, so for the series: >> >> Reviewed-by: Rob Clark > > Can I see a git tree of this with Rob's R-B on it? > > based off drm-next if possible, > > I'd like to do a quick pre-merge review of it, but I usually don't > find anything too major. > > Dave. -- Benjamin Gaignard Graphic Working Group Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 00/19] atomic, remixed
On Sun, Jul 27, 2014 at 11:41:29PM +0200, Daniel Vetter wrote: > - I've added a new set of plane helpers. Mostly this was motivated to make the > atomic helpers work on less stellar hardware where you can't just stream the > state and then atomically commit with some GO bits. But those helpers should > also be useful for more gradual transitions of drivers to the atomic > interface. Since a requirement for atomic is to have universal plane support > they can be used bare-bones just for that, without all the other atomic > baggage (i.e. all the state tracking for crtcs/connectors). Maybe a short elaboration on how to smoothly transition to atomic is in order: 1. Implement the plane helpers for the primary plane, use the with the crtc helper set_config function through the provided ->mode_set_base and ->mode_set callbacks. 2. Expose a proper primary plane with the plan helpers and test it a bit (since with primary planes we now allow an enabled crtc with the primary plane off). 3. Convert all other planes (cursor, overlay) over to the primary plane helpers. You should move any constraint checking for planes into the atomic_check callback. 4. Roll out your atomic state handling functions for crtc/plane. Using the provided default handlers in the helper library is probably the best. Plane/crtc helpers will automatically switch to those when available. From here on you can also start to track plane/crtc state in your own subclassed structures. 5. Audit all your ->mode_fixup functions to make sure they don't depend upon the connector->encoder and encoder->crtc links. That's the big difference between atomic and crtc helpers. 6. Wire up the set_config implementation from the atomic helpers and test it. 7. Go through all the connectors individually and convert them to atomic state handling. If a connector has no driver-private properties then you can just wire up the default functions and the atomic set_prop implementation from the helpers. Otherwise you need to subclass the state structure. 8. Add ->atomic_check functions for crtcs to check additional constraints that need checking for global modesets. If you have global/shared resources (e.g. plls) add a modeset_lock for them and grab it if you need to change anything. Make sure you wire up the backoff logic correctly (CONFIG_DEBUG_WW_MUTEX_SLOWPATH is your friend). That's all - each step is fairly well-contained and can be tested on its own. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680 --- Comment #4 from Michel D?nzer --- (In reply to comment #3) > (In reply to comment #2) > > Can you resolve the r600_dri.so symbols? > > If you'll explain me how to. First of all, make sure r600_dri.so has debugging symbols, i.e. is built with -g and not stripped. If the Mozilla crash reporter still doesn't resolve the symbols then, try addr2line -e /path/to/r600_dri.so for every r600_dri.so frame. BTW, I notice the crash involves libgallium.so.0.0.0, which is an Ubuntu specialty. Can your reproduce the problem with a build of upstream Mesa 10.1? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/47b7386a/attachment.html>
[Bug 81678] X crashes on start (integrated 7640G + discrete 7500M/7600M)
https://bugs.freedesktop.org/show_bug.cgi?id=81678 Michel D?nzer changed: What|Removed |Added Assignee|xorg-team at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|DRI Component|Lib/pciaccess |DRM/Radeon --- Comment #8 from Michel D?nzer --- (In reply to comment #6) > This bug occurs on my PC. So, I can answer your questions. So Igor reported the bug on your behalf? > http://4.firepic.org/4/images/2014-07/25/16gbn0d01uyu.jpg [...] > BUG: unable to handle kernel paging request at 2180 I believe this oops might be the central issue, or at least one that needs to be resolved. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/277328fa/attachment.html>
[PATCH 00/19] atomic, remixed
On Sun, Jul 27, 2014 at 11:41:29PM +0200, Daniel Vetter wrote: > Hi all, > > So I've figured instead of just talking I should draw up my ideas for atomic > helpers and related stuff in some draft patches. Major differences compared to > Rob's series: > > - The software side state update is done synchronously, at least when using > the > helper code. Drivers are free to do whatever they want, as usual. This has a > bunch of nice upsides: > > + All the tricky locking dances can be abolished, and if the ordering and > synchronization is done correctly async worker threads don't need any > modeset state locking at all. I'm fairly sure that Rob's scheme won't blow > up, but I much prefer we don't need it at all. > > + In Rob's patches any atomic operation must wait for outstanding updates to > complete. Otherwise the software state isn't committed yet. With the > synchronous updates we can immediately proceed with the state construction > and verification and will only block right before applying the state > update. > And even for that drivers can implement cancellation of the previous > update. > > This has the nice benefit that check-only operations (which compositors > need > to do right after having completed the current frame to know how to render > the next one) can be done without blocking for completion of the previous > update. > > - Internal interfaces for atomic updates don't need to go through properties, > but can directly set the state. Drivers can always compare updates in their > ->check hook later on, so we don't lose expressiveness in the interface. But > the resulting code in the callers looks much better. > > In general I've ditched a lot of interfaces where drivers could overwrite > default behaviour and boiled down the interface two state handling functions > (duplicate+destroy), setting driver-private properties and check/commit. > > - There is a clear helper separation between core code which should be used to > use the atomic interface to drivers, and helper functions. Core never uses > helper functions so that we can keep the clear separation we have in all > other > places in the kms api. > > There's a set of helpers sitting in-between to implement legacy interfaces > on > top of atomic. Those _only_ use the core atomic interfaces. > > - I've added a new set of plane helpers. Mostly this was motivated to make the > atomic helpers work on less stellar hardware where you can't just stream the > state and then atomically commit with some GO bits. But those helpers should > also be useful for more gradual transitions of drivers to the atomic > interface. Since a requirement for atomic is to have universal plane support > they can be used bare-bones just for that, without all the other atomic > baggage (i.e. all the state tracking for crtcs/connectors). > > - State tracking for connectors. i915 has piles of relevant connector > properties, which we want to save/restore in atomic ops (e.g. hdmi metadata > and stuff). > > - fbdev panic locking is implemented with trylock instead of nolock. > > - I've thought a bit about resume. See the proposed state handling for the > default reset functions and the addition of a plane reset callback. > > There's also a metric pile of stuff missing: > > - It's completely untested (except for the parts touching currently used code) > since I lack suitable hw. Converting i915 is just a bit too much of a pain > for > a quick w/e code draft ;-) > > - I didn't add all the properties for things currently exposed through ioctl > structures. Since the interface here doesn't force internal code to use > properties for everything (which really makes things look much better) we > don't have a need for that until we merge the actual atomic ioctl. So I left > that out. > > - I didn't write code for the fbdev helper to use atomic. The w/e ran out of > time for that ... > > - Kerneldoc is occasionally not updated or still missing. > > Anyway I think this draft code is good enough to explain how I'd like to > address > some of the concerns I have with the current atomic code. Comments, flames and > ideas highly welcome. And if anyone is insane enought to try this on real > hardware, that would certainly be interesting and I'm very much willing to > help > out as much as possible ... i915 just really isn't suitable since it won't be > using the helpers, and all the other hw I have here doesn't support planes. The entire thing is available as a git tree at git://people.freedesktop.org/~danvet/drm colder-fusion I've already pushed a bit more polish on top. -Daniel > > Cheers, Daniel > > Daniel Vetter (18): > drm: Add atomic driver interface definitions for objects > drm: Add drm_plane/connector_index > drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc] > drm: Handle legacy per-crtc locking with full acquire ct
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #13 from Michel D?nzer --- (In reply to comment #6) > Chromium randomly crashes with RadeonSI driver when using Chromium. Most > usually with Youtube videos. Using Flash or HTML5 video? Fullscreen or windowed? ... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/e3f205fe/attachment-0001.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #31 from Michel D?nzer --- (In reply to comment #30) > But every demo segfaults. Mostly in LLVMBuildBitCast(). [...] > This is still a problem with register spilling that just looks different, > right? No, that sounds like bug 81834. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/cd30762a/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #32 from Christoph Haag --- Created attachment 103583 --> https://bugs.freedesktop.org/attachment.cgi?id=103583&action=edit backtrace of unreal engine effects demo with debug (In reply to comment #31) > (In reply to comment #30) > > But every demo segfaults. Mostly in LLVMBuildBitCast(). > [...] > > This is still a problem with register spilling that just looks different, > > right? > > No, that sounds like bug 81834. So I built mesa with debug symbols and I guess debugging enables some assertions because now fails at some assertion about Register.Index stuff. Full backtrace attached. (bug 81834 doesn't say what versions he uses. I use upstream llvm 214022 and mesa git with the small patch I mentioned) Of course it could be both problems at the same time. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/1965633b/attachment.html>
[PATCH 00/19] atomic, remixed
On Sun, Jul 27, 2014 at 5:41 PM, Daniel Vetter wrote: > Hi all, > > So I've figured instead of just talking I should draw up my ideas for atomic > helpers and related stuff in some draft patches. Major differences compared to > Rob's series: > > - The software side state update is done synchronously, at least when using > the > helper code. Drivers are free to do whatever they want, as usual. This has a > bunch of nice upsides: > > + All the tricky locking dances can be abolished, and if the ordering and > synchronization is done correctly async worker threads don't need any > modeset state locking at all. I'm fairly sure that Rob's scheme won't blow > up, but I much prefer we don't need it at all. > > + In Rob's patches any atomic operation must wait for outstanding updates to > complete. Otherwise the software state isn't committed yet. With the > synchronous updates we can immediately proceed with the state construction > and verification and will only block right before applying the state > update. > And even for that drivers can implement cancellation of the previous > update. fwiw, the rough plan here for my version was to (since state was refcnt'd) eventually allow things to chain up (ie. copying N+1'th state from N'th state, rather than mode objects themselves) which could be done without locks for check-only.. That said, I'm not super sold on the idea that userspace needs to be able to queue up multiple frames ahead.. but it was something that people ask for from time to time.. > This has the nice benefit that check-only operations (which compositors > need > to do right after having completed the current frame to know how to render > the next one) can be done without blocking for completion of the previous > update. > > - Internal interfaces for atomic updates don't need to go through properties, > but can directly set the state. Drivers can always compare updates in their > ->check hook later on, so we don't lose expressiveness in the interface. But > the resulting code in the callers looks much better. hmm, in cases where drivers have to fwd one property to another object or other sort of side effect, I think my way was nicer, imho ;-) Sure, we can figure it out in check_hook later, but it is a bit awkward. And means we need to be careful about sequence of checks (potentially having to re-check) of different objects. Looks worse to me ;-) > In general I've ditched a lot of interfaces where drivers could overwrite > default behaviour and boiled down the interface two state handling functions > (duplicate+destroy), setting driver-private properties and check/commit. > > - There is a clear helper separation between core code which should be used to > use the atomic interface to drivers, and helper functions. Core never uses > helper functions so that we can keep the clear separation we have in all > other > places in the kms api. > > There's a set of helpers sitting in-between to implement legacy interfaces > on > top of atomic. Those _only_ use the core atomic interfaces. > > - I've added a new set of plane helpers. Mostly this was motivated to make the > atomic helpers work on less stellar hardware where you can't just stream the > state and then atomically commit with some GO bits. But those helpers should > also be useful for more gradual transitions of drivers to the atomic > interface. Since a requirement for atomic is to have universal plane support > they can be used bare-bones just for that, without all the other atomic > baggage (i.e. all the state tracking for crtcs/connectors). > > - State tracking for connectors. i915 has piles of relevant connector > properties, which we want to save/restore in atomic ops (e.g. hdmi metadata > and stuff). > > - fbdev panic locking is implemented with trylock instead of nolock. > > - I've thought a bit about resume. See the proposed state handling for the > default reset functions and the addition of a plane reset callback. > > There's also a metric pile of stuff missing: > > - It's completely untested (except for the parts touching currently used code) > since I lack suitable hw. Converting i915 is just a bit too much of a pain > for > a quick w/e code draft ;-) > > - I didn't add all the properties for things currently exposed through ioctl > structures. Since the interface here doesn't force internal code to use > properties for everything (which really makes things look much better) we > don't have a need for that until we merge the actual atomic ioctl. So I left > that out. > > - I didn't write code for the fbdev helper to use atomic. The w/e ran out of > time for that ... > > - Kerneldoc is occasionally not updated or still missing. Unless I'm missing something you also completely lost all the core crtc and plane check code (except for what you left in legacy codepaths.. tbh, this was one thing that I liked about my approac
[PATCH] work around warning in i915_gem_gtt
Gcc warns that addr might be used uninitialized. It may not, but I see
why gcc gets confused.
Additionally, hiding code with side-effects inside WARN_ON() argument
seems uncool, so I moved it outside.
Signed-off-by: Pavel Machek
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8b3cde7..8fcc974 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1448,7 +1448,7 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
(gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm + first_entry;
int i = 0;
struct sg_page_iter sg_iter;
- dma_addr_t addr;
+ dma_addr_t addr = 0;
for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) {
addr = sg_page_iter_dma_address(&sg_iter);
@@ -1462,9 +1462,10 @@ static void gen6_ggtt_insert_entries(struct
i915_address_space *vm,
* of NUMA access patterns. Therefore, even with the way we assume
* hardware should work, we must keep this posting read for paranoia.
*/
- if (i != 0)
- WARN_ON(readl(>t_entries[i-1]) !=
- vm->pte_encode(addr, level, true));
+ if (i != 0) {
+ unsigned long gtt = readl(>t_entries[i-1]);
+ WARN_ON(gtt != vm->pte_encode(addr, level, true));
+ }
/* This next bit makes the above posting read even more important. We
* want to flush the TLBs only after we're certain all the PTE updates
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[PATCH 5/5] drm/radeon: allow userptr write access under certain conditions
From: Christian K?nig
It needs to be anonymous memory (no file mappings)
and we are requried to install an MMU notifier.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 29e353f..6a7bfc2 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -287,19 +287,24 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
if (offset_in_page(args->addr | args->size))
return -EINVAL;
- /* we only support read only mappings for now */
- if (!(args->flags & RADEON_GEM_USERPTR_READONLY))
- return -EACCES;
-
/* reject unknown flag values */
if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE |
RADEON_GEM_USERPTR_REGISTER))
return -EINVAL;
- /* readonly pages not tested on older hardware */
- if (rdev->family < CHIP_R600)
- return -EINVAL;
+ if (args->flags & RADEON_GEM_USERPTR_READONLY) {
+ /* readonly pages not tested on older hardware */
+ if (rdev->family < CHIP_R600)
+ return -EINVAL;
+
+ } else if (!(args->flags & RADEON_GEM_USERPTR_ANONONLY) ||
+ !(args->flags & RADEON_GEM_USERPTR_REGISTER)) {
+
+ /* if we want to write to it we must require anonymous
+ memory and install a MMU notifier */
+ return -EACCES;
+ }
down_read(&rdev->exclusive_lock);
--
1.9.1
[PATCH 3/5] drm/radeon: add userptr flag to directly validate the BO to GTT
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 18 +-
include/uapi/drm/radeon_drm.h | 1 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index e2c6f44..3ffb2f3 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -293,7 +293,7 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
/* reject unknown flag values */
if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
- RADEON_GEM_USERPTR_ANONONLY))
+ RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE))
return -EINVAL;
/* readonly pages not tested on older hardware */
@@ -314,6 +314,22 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
if (r)
goto release_object;
+ if (args->flags & RADEON_GEM_USERPTR_VALIDATE) {
+ down_read(¤t->mm->mmap_sem);
+ r = radeon_bo_reserve(bo, true);
+ if (r) {
+ up_read(¤t->mm->mmap_sem);
+ goto release_object;
+ }
+
+ radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_GTT);
+ r = ttm_bo_validate(&bo->tbo, &bo->placement, true, false);
+ radeon_bo_unreserve(bo);
+ up_read(¤t->mm->mmap_sem);
+ if (r)
+ goto release_object;
+ }
+
r = drm_gem_handle_create(filp, gobj, &handle);
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(gobj);
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 4080ad3..026111b 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -812,6 +812,7 @@ struct drm_radeon_gem_create {
#define RADEON_GEM_USERPTR_READONLY(1 << 0)
#define RADEON_GEM_USERPTR_ANONONLY(1 << 1)
+#define RADEON_GEM_USERPTR_VALIDATE(1 << 2)
struct drm_radeon_gem_userptr {
uint64_taddr;
--
1.9.1
[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
drivers/gpu/drm/radeon/radeon_ttm.c | 8
include/uapi/drm/radeon_drm.h | 3 ++-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 05b9661..e2c6f44 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -292,7 +292,8 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
return -EACCES;
/* reject unknown flag values */
- if (args->flags & ~RADEON_GEM_USERPTR_READONLY)
+ if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
+ RADEON_GEM_USERPTR_ANONONLY))
return -EINVAL;
/* readonly pages not tested on older hardware */
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index dbc15ec..7a21478 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -541,6 +541,14 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
ttm->num_pages * PAGE_SIZE))
return -EFAULT;
+ if (gtt->userflags & RADEON_GEM_USERPTR_ANONONLY) {
+ unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
+ struct vm_area_struct *vma;
+ vma = find_vma(gtt->usermm, gtt->userptr);
+ if (!vma || vma->vm_file || vma->vm_end < end)
+ return -EPERM;
+ }
+
do {
unsigned num_pages = ttm->num_pages - pinned;
uint64_t userptr = gtt->userptr + pinned * PAGE_SIZE;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index a18ec54..4080ad3 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -810,7 +810,8 @@ struct drm_radeon_gem_create {
uint32_tflags;
};
-#define RADEON_GEM_USERPTR_READONLY0x1
+#define RADEON_GEM_USERPTR_READONLY(1 << 0)
+#define RADEON_GEM_USERPTR_ANONONLY(1 << 1)
struct drm_radeon_gem_userptr {
uint64_taddr;
--
1.9.1
[PATCH 1/5] drm/radeon: add userptr support v5
From: Christian K?nig
This patch adds an IOCTL for turning a pointer supplied by
userspace into a buffer object.
It imposes several restrictions upon the memory being mapped:
1. It must be page aligned (both start/end addresses, i.e ptr and size).
2. It must be normal system memory, not a pointer into another map of IO
space (e.g. it must not be a GTT mmapping of another object).
3. The BO is mapped into GTT, so the maximum amount of memory mapped at
all times is still the GTT limit.
4. The BO is only mapped readonly for now, so no write support.
5. List of backing pages is only acquired once, so they represent a
snapshot of the first use.
Exporting and sharing as well as mapping of buffer objects created by
this function is forbidden and results in an -EPERM.
v2: squash all previous changes into first public version
v3: fix tabs, map readonly, don't use MM callback any more
v4: set TTM_PAGE_FLAG_SG so that TTM never messes with the pages,
pin/unpin pages on bind/unbind instead of populate/unpopulate
v5: rebased on 3.17-wip, IOCTL renamed to userptr, reject any unknown
flags, better handle READONLY flag, improve permission check
Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher (v4)
Reviewed-by: J?r?me Glisse (v4)
---
drivers/gpu/drm/radeon/radeon.h| 5 ++
drivers/gpu/drm/radeon/radeon_cs.c | 25 ++-
drivers/gpu/drm/radeon/radeon_drv.c| 5 +-
drivers/gpu/drm/radeon/radeon_gem.c| 68 ++
drivers/gpu/drm/radeon/radeon_kms.c| 1 +
drivers/gpu/drm/radeon/radeon_object.c | 3 +
drivers/gpu/drm/radeon/radeon_prime.c | 10 +++
drivers/gpu/drm/radeon/radeon_ttm.c| 127 +
drivers/gpu/drm/radeon/radeon_vm.c | 3 +
include/uapi/drm/radeon_drm.h | 11 +++
10 files changed, 255 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cd0d960..2b363f3 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2128,6 +2128,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev, void
*data,
struct drm_file *filp);
int radeon_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_userptr_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
int radeon_gem_pin_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int radeon_gem_unpin_ioctl(struct drm_device *dev, void *data,
@@ -2858,6 +2860,9 @@ extern void radeon_legacy_set_clock_gating(struct
radeon_device *rdev, int enabl
extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int
enable);
extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32
domain);
extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
+extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
+uint32_t flags);
+extern bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm);
extern void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc
*mc, u64 base);
extern void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc
*mc);
extern int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index ee712c1..1321491 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -78,7 +78,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
struct radeon_cs_chunk *chunk;
struct radeon_cs_buckets buckets;
unsigned i, j;
- bool duplicate;
+ bool duplicate, need_mmap_lock = false;
+ int r;
if (p->chunk_relocs_idx == -1) {
return 0;
@@ -164,6 +165,19 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
p->relocs[i].allowed_domains = domain;
}
+ if (radeon_ttm_tt_has_userptr(p->relocs[i].robj->tbo.ttm)) {
+ uint32_t domain = p->relocs[i].prefered_domains;
+ if (!(domain & RADEON_GEM_DOMAIN_GTT)) {
+ DRM_ERROR("Only RADEON_GEM_DOMAIN_GTT is "
+ "allowed for userptr BOs\n");
+ return -EINVAL;
+ }
+ need_mmap_lock = true;
+ domain = RADEON_GEM_DOMAIN_GTT;
+ p->relocs[i].prefered_domains = domain;
+ p->relocs[i].allowed_domains = domain;
+ }
+
p->relocs[i].tv.bo = &p->relocs[i].robj->tbo;
p->relocs[i].handle = r->handle;
@@ -176,8 +190,15 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser
*p)
if (p->cs_flags
[PATCH 4/5] drm/radeon: add userptr flag to register MMU notifier
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/radeon/Makefile| 2 +-
drivers/gpu/drm/radeon/radeon.h| 12 ++
drivers/gpu/drm/radeon/radeon_device.c | 2 +
drivers/gpu/drm/radeon/radeon_gem.c| 9 +-
drivers/gpu/drm/radeon/radeon_mn.c | 270 +
drivers/gpu/drm/radeon/radeon_object.c | 1 +
include/uapi/drm/radeon_drm.h | 1 +
8 files changed, 296 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/radeon/radeon_mn.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9b2eedc..2745284 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -115,6 +115,7 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ select MMU_NOTIFIER
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 1b04002..c66143d 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
- ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o
+ ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_mn.o
# add async DMA block
radeon-y += \
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 2b363f3..57fd145 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -65,6 +65,7 @@
#include
#include
#include
+#include
#include
#include
@@ -483,6 +484,9 @@ struct radeon_bo {
struct ttm_bo_kmap_obj dma_buf_vmap;
pid_t pid;
+
+ struct radeon_mn*mn;
+ struct interval_tree_node mn_it;
};
#define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base)
@@ -1721,6 +1725,11 @@ void radeon_test_ring_sync(struct radeon_device *rdev,
struct radeon_ring *cpB);
void radeon_test_syncing(struct radeon_device *rdev);
+/*
+ * MMU Notifier
+ */
+int radeon_mn_register(struct radeon_bo *bo, unsigned long addr);
+void radeon_mn_unregister(struct radeon_bo *bo);
/*
* Debugfs
@@ -2362,6 +2371,9 @@ struct radeon_device {
/* tracking pinned memory */
u64 vram_pin_size;
u64 gart_pin_size;
+
+ struct mutexmn_lock;
+ DECLARE_HASHTABLE(mn_hash, 7);
};
bool radeon_is_px(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index afcfe8a..3bced2d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1269,6 +1269,8 @@ int radeon_device_init(struct radeon_device *rdev,
init_rwsem(&rdev->pm.mclk_lock);
init_rwsem(&rdev->exclusive_lock);
init_waitqueue_head(&rdev->irq.vblank_queue);
+ mutex_init(&rdev->mn_lock);
+ hash_init(rdev->mn_hash);
r = radeon_gem_init(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index 3ffb2f3..29e353f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -293,7 +293,8 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
/* reject unknown flag values */
if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
- RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE))
+ RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE |
+ RADEON_GEM_USERPTR_REGISTER))
return -EINVAL;
/* readonly pages not tested on older hardware */
@@ -314,6 +315,12 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void
*data,
if (r)
goto release_object;
+ if (args->flags & RADEON_GEM_USERPTR_REGISTER) {
+ r = radeon_mn_register(bo, args->addr);
+ if (r)
+ goto release_object;
+ }
+
if (args->flags & RADEON_GEM_USERPTR_VALIDATE) {
down_read(¤t->mm->mmap_sem);
r = radeon_bo_reserve(bo, true);
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c
b/drivers/gpu/drm/radeon/radeon_mn.c
new file mode 100644
index 000..ef0f9b4
--- /dev/null
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
[PATCH 0/2] Update copyright notices for Renesas DRM drivers
Hi Dave, On Wednesday 02 July 2014 16:42:09 Laurent Pinchart wrote: > Hi Dave, > > Could you please pick those two patches up for v3.17 ? Am I missing something ? Is there a secret e-mail address I need to send my patches to to get them picked up ? This is a trivial change first submitted in February (!). > On Thursday 06 February 2014 18:41:56 Laurent Pinchart wrote: > > The "Renesas Corporation" listed in the copyright notices doesn't exist. > > Replace it with "Renesas Electronics Corporation" and update the > > copyright years. > > > > Laurent Pinchart (2): > > drm/rcar-du: Update copyright notice > > drm/shmob: Update copyright notice > > > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_group.c| 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_kms.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_plane.c| 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_plane.h| 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 2 +- > > drivers/gpu/drm/rcar-du/rcar_du_vgacon.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_crtc.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_drv.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_kms.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_kms.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_plane.h | 2 +- > > drivers/gpu/drm/shmobile/shmob_drm_regs.h | 2 +- > > 29 files changed, 29 insertions(+), 29 deletions(-) -- Regards, Laurent Pinchart
[PATCH 0/8] Upstreaming the Android build and misc fixes
On 28/07/14 08:07, Daniel Vetter wrote: > On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote: >> A few updates: >> >> - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to >> *_H_FILES >> - Including the platform Android.mk files individually is not the right way >> to do. One needs to construct an array/list of Android.mks and include it. >> >> - The series including the above fixes can be found in branch fixes+android >> over at https://github.com/evelikov/libdrm. > > Adding Tim Gore who's working on Android.mk support for i-g-t from our > side and probably knows whom to poke for the intel side of things for > libdrm Android ports. > -Daniel > Thank you Daniel, In case it was not clear enough, some of these patches are taken from android-ia/external/drm. The very same are written by Intel employees AFAICT :) Would be great to hear if anyone is against the idea of getting Android.mks in the canonical repo. -Emil >> >> -Emil >> >> On 27/07/14 19:25, Emil Velikov wrote: >>> Hello list, >>> >>> Recently I've had a go at the Anroid builds and I felt ... inspired that >>> there are (at least) two downstream repositories that have the relevant >>> Android build, yet all of them use 6+month old libdrm. >>> Making even builds a pain in the neck :'( >>> >>> Are there any objections if we get the android build upstream ? AFAICS >>> it's nicely isolated from everything else + I've managed to reuse all >>> the source/headers lists. >>> >>> Note that the series lacks a couple of patches from the downstream >>> repos, yet adds support for radeon, nouveau and freedreno :) >>> >>> The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel >>> specific "hacks". If people are happy with the series then we can take >>> a look at the final bits. >>> >>> >>> Cheers, >>> Emil >>> >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >
drm/i915: CONFIG_DRM_I915_UMS
On Sat, 2014-07-26 at 01:44 +0200, Daniel Vetter wrote:
> On Fri, Jul 25, 2014 at 2:14 PM, Paul Bolle wrote:
> > Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
> > included in today's linux-next (ie, next-20140725). It removes the
> > Kconfig symbol DRM_I915_UMS.
> >
> > It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
> > These checks are superfluous as they now will always evaluate to true.
> > Is the trivial cleanup to remove them already queued somewhere?
>
> No, and intentionally.
So this was not by mistake, which is good to know.
> Actually removing the code for
> user-mode-setting isn't just removing these two blocks,
Just to be clear: I'm only suggesting to remove the two lines reading
#ifndef CONFIG_DRM_I915_UMS
and their corresponding #endif lines.
> but requires
> the gutting of roughly 10k lines splattered all over the driver.
> Essentially all the code that checks for
> !drm_core_check_feature(DRIVER_MODESET) needs to go. That's not quite
> as trivial, and before I do that I want to make really sure that
> really no one misses this option.
>
> So probably after 3.17 is out the door for a bit.
None of what I brought up is urgent. But I do hope you don't mind me
sending a reminder if these few (preprocessor) lines are staying around
longer than expected.
Paul Bolle
[Bug 81837] New: [radeonsi] memory leaks in OpenCL
o allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5836800 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5832704 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 5832704 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 1048576 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 radeon: Failed to allocate virtual address for buffer: radeon:size : 1048576 bytes radeon:alignment : 4096 bytes radeon:domains : 2 radeon:va: 0xfff2b000 ?? ??? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/994039e7/attachment-0001.html>
[Bug 81678] X crashes on start (integrated 7640G + discrete 7500M/7600M)
https://bugs.freedesktop.org/show_bug.cgi?id=81678 --- Comment #9 from Andrey Volkov --- (In reply to comment #8) > (In reply to comment #6) > > This bug occurs on my PC. So, I can answer your questions. > > So Igor reported the bug on your behalf? > Yes. I reported the bug on the Russian Fedora project bugtracker (http://redmine.russianfedora.pro/issues/1356), and, after that, he reported the bug on this bugtracker. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/74fe04d3/attachment.html>
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 28? 17:30, Sjoerd Simons wrote: > Hey Inki, > > On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote: >> Hey Inki, >> >> On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote: >>> On 2014? 07? 19? 05:36, Sjoerd Simons wrote: The exynos DRM module currently is not automatically loaded when build as a module. This is due to the simple fact that it doesn't have any MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed previously as it wasn't possible at the time to have multiple calls to MODULE_DEVICE_TABLE in one module, however commit 21bdd17b21b45ea solved that. The first two patches revert the previous removals of MODULE_DEVICE_TABLE calls, while the last one adds calls for the remaining OF match tables without a MODULE_DEVICE_TABLE call. >> >>> Exynos drm follows single-driver model. So each usb driver of Exynos drm >>> wouldn't need its own MODULE_DEVICE_TABLE. >> >> Strictly speaking you're right, for module autoloading to work the >> module just needs to have one that matches. So in principle all other >> entries are redundant. >> >> However for exynos drm there does not seem to be one main device which >> is guaranteed to always be present which can be used to key the module >> autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries >> for all the various subdrivers to ensure autoloading actually happens, >> especially since the various subdrivers can be seperately enabled >> at build time. > > Been about a week since this last mail. If you have any suggestions on a > better approach or on how to move this forward, i'd be very grateful to > hear as i think i've addressed your original comment on the set in the > previous reply? Sorry for late, I don't see why Exynos drm driver should be auto-loaded module. I think all devices covered by Exynos drm framework are not hot-plugged. Maybe there is my missing point. So can you explain why Exynos drm driver should be auto-loaded module? Thanks, Inki Dae >
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #115 from Kai --- (In reply to comment #106) > Playing streams (live and recorded broadcasts) from Twitch with this setup > is, however, neigh impossible. With the open driver and GLAMOR acceleration, > X uses 80 % CPU time on one core and the video becomes a dia show. The Flash > plugin is at 40 % CPU time (different core), but that's roughly the same as > with fglrx. (For reference: my CPU is an Intel Core i7-3770K.) After some further testing yesterday I could only reproduce the stalling of X with "recorded brodcasts" on Twitch. It doesn't matter what stream quality you pick (if you're patient enough to get that menu open). X starts hogging all resources on one CPU core as soon as you load any recording (I tried four different recordings). Live broadcasts/streams worked normally yesterday afternoon/evening and today. (In reply to comment #114) > (In reply to comment #108) > > Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of: > > > [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip > > > completion event has impossible msc 2822274 < target_msc 2822275 > > These are fixed in drm-fixes-3.16, but that hasn't been merged into > drm-next-3.17-wip yet. Ah, ok. I found <http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.16&id=f53f81b2576a9bd3af947e2b1c3a46dfab51c5ef>. Is that the correct commit for Hawaii? Doesn't look like the appropriate commit to me (so much "Evergreen" everywhere), but it was the only one a search for radeon_dri2_flip_event_handler yielded. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/c88611cb/attachment.html>
[PATCH libdrm] libdrm: Fix drm.h include in qxl drm header file
ping 2014-05-05 23:54 GMT+02:00 Andreas Boll : > Use "drm.h" instead of "drm/drm.h" as used in the other header files. > Fixes xserver-xorg-video-qxl build with KMS support on Debian, where this > file is installed in /usr/include/libdrm. > > Fixes Debian bug #746807 > > Reported-by: Bastian Blank > Signed-off-by: Andreas Boll > --- > include/drm/qxl_drm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h > index 5d7de70..1e331a8 100644 > --- a/include/drm/qxl_drm.h > +++ b/include/drm/qxl_drm.h > @@ -25,7 +25,7 @@ > #define QXL_DRM_H > > #include > -#include "drm/drm.h" > +#include "drm.h" > > /* Please note that modifications to all structs defined here are > * subject to backwards-compatibility constraints. > -- > 1.9.2 >
[PATCH 00/19] atomic, remixed
On Mon, Jul 28, 2014 at 1:17 PM, Rob Clark wrote: > On Sun, Jul 27, 2014 at 5:41 PM, Daniel Vetter > wrote: >> Hi all, >> >> So I've figured instead of just talking I should draw up my ideas for atomic >> helpers and related stuff in some draft patches. Major differences compared >> to >> Rob's series: >> >> - The software side state update is done synchronously, at least when using >> the >> helper code. Drivers are free to do whatever they want, as usual. This has >> a >> bunch of nice upsides: >> >> + All the tricky locking dances can be abolished, and if the ordering and >> synchronization is done correctly async worker threads don't need any >> modeset state locking at all. I'm fairly sure that Rob's scheme won't >> blow >> up, but I much prefer we don't need it at all. >> >> + In Rob's patches any atomic operation must wait for outstanding updates >> to >> complete. Otherwise the software state isn't committed yet. With the >> synchronous updates we can immediately proceed with the state >> construction >> and verification and will only block right before applying the state >> update. >> And even for that drivers can implement cancellation of the previous >> update. > > fwiw, the rough plan here for my version was to (since state was > refcnt'd) eventually allow things to chain up (ie. copying N+1'th > state from N'th state, rather than mode objects themselves) which > could be done without locks for check-only.. > > That said, I'm not super sold on the idea that userspace needs to be > able to queue up multiple frames ahead.. but it was something that > people ask for from time to time.. We should still be able to queue up more than one update I think - the drm-visible software state will always reflect the latest update, even when it's not yet put into the hw. Internally the driver can keep a linked-list (maybe we could move that to the official drm_atomic_state even) to know where it is exactly with pushing out updates. One issue though with either approach is canceling updates in-between. I guess a lot of this will be highly driver-specific. In a way canceling an entire queue is just a more generic version of the "how can we cancel the current pending update" issue. So I think we should postpone the queue problem until we have the normal cancel solved (for lower-latency gaming). Also I think queued updates will only be worth it for some very special workloads like video display, when shutting down both the cpu and gpu is actually possible and might be worth some power saving. And hw engineers seem to flip-flop on whether that's worth it for video or whether it's better to have a slow, but power-sipping special decoder which feeds out frames constantly instead of the rush-stop-rush-stop queued frames would need. >> This has the nice benefit that check-only operations (which compositors >> need >> to do right after having completed the current frame to know how to >> render >> the next one) can be done without blocking for completion of the previous >> update. >> >> - Internal interfaces for atomic updates don't need to go through properties, >> but can directly set the state. Drivers can always compare updates in their >> ->check hook later on, so we don't lose expressiveness in the interface. >> But >> the resulting code in the callers looks much better. > > hmm, in cases where drivers have to fwd one property to another object > or other sort of side effect, I think my way was nicer, imho ;-) Well for driver-private properties you can do that still. E.g. with panel upscaling which you internally implement you could push that to the crtc. > Sure, we can figure it out in check_hook later, but it is a bit > awkward. And means we need to be careful about sequence of checks > (potentially having to re-check) of different objects. Looks worse to > me ;-) Otoh you can't just chase the connector_state->crtc link, since we don't promise to deliver the state updates in any order. So that might still change. I think in the end you really have to do all that cross-object verification/propagation only in the ->check function, and can't do it any earlier. Also I hope that most hw really sets e.g. plane coordinates in their plane functions, otherwise kms would be a serious misfit ;-) So hopefully not too much forwarding of state required. Wrt sequencing checks correctly: We have that problem any way, but the upside is that the order in which the atomic_check helper callbacks are run is well-defined. But the order in which ->atomic_set_prop is run is totally abitrary. So you can't really rely on any ordering in there (which rather seriously restricts what you can check). >> In general I've ditched a lot of interfaces where drivers could overwrite >> default behaviour and boiled down the interface two state handling >> functions >> (duplicate+destroy), setting driver-private properties and check/commit. >> >> - There is a
[Bug 81837] [radeonsi] memory leaks in OpenCL
https://bugs.freedesktop.org/show_bug.cgi?id=81837 --- Comment #1 from Tom Stellard --- Is this a regression? If so, can you bisect? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/56834a46/attachment.html>
[PATCH libdrm] libdrm: Fix drm.h include in qxl drm header file
On 28/07/14 15:35, Andreas Boll wrote: > ping > > 2014-05-05 23:54 GMT+02:00 Andreas Boll : >> Use "drm.h" instead of "drm/drm.h" as used in the other header files. >> Fixes xserver-xorg-video-qxl build with KMS support on Debian, where this >> file is installed in /usr/include/libdrm. >> I believe that's the default location for most linux distributions. Seems like not many of us build the qxl ddx :\ FWIW Reviewed-by: Emil Velikov >> Fixes Debian bug #746807 >> >> Reported-by: Bastian Blank >> Signed-off-by: Andreas Boll >> --- >> include/drm/qxl_drm.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h >> index 5d7de70..1e331a8 100644 >> --- a/include/drm/qxl_drm.h >> +++ b/include/drm/qxl_drm.h >> @@ -25,7 +25,7 @@ >> #define QXL_DRM_H >> >> #include >> -#include "drm/drm.h" >> +#include "drm.h" >> >> /* Please note that modifications to all structs defined here are >> * subject to backwards-compatibility constraints. >> -- >> 1.9.2 >> > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH 0/8] Upstreaming the Android build and misc fixes
On Mon, Jul 28, 2014 at 01:01:19PM +0100, Emil Velikov wrote: > On 28/07/14 08:07, Daniel Vetter wrote: > > On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote: > >> A few updates: > >> > >> - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed > >> to > >> *_H_FILES > >> - Including the platform Android.mk files individually is not the right > >> way > >> to do. One needs to construct an array/list of Android.mks and include it. > >> > >> - The series including the above fixes can be found in branch > >> fixes+android > >> over at https://github.com/evelikov/libdrm. > > > > Adding Tim Gore who's working on Android.mk support for i-g-t from our > > side and probably knows whom to poke for the intel side of things for > > libdrm Android ports. > > -Daniel > > > Thank you Daniel, > > In case it was not clear enough, some of these patches are taken from > android-ia/external/drm. The very same are written by Intel employees AFAICT > :) Would be great to hear if anyone is against the idea of getting Android.mks > in the canonical repo. Oh, that's kinda why I want to drag the relevant people in from Intel's side. Responsibility for Android builds have shifted around a bit the past few years and Intel is big, so I'm trying to get hold off the right person. No success thus far :( But personally I want this, just need to make sure that our own Android guys see it and can start to help out. Occasionally it takes a while until they dare to walk out of their hidings ;-) -Daniel > > > -Emil > > >> > >> -Emil > >> > >> On 27/07/14 19:25, Emil Velikov wrote: > >>> Hello list, > >>> > >>> Recently I've had a go at the Anroid builds and I felt ... inspired that > >>> there are (at least) two downstream repositories that have the relevant > >>> Android build, yet all of them use 6+month old libdrm. > >>> Making even builds a pain in the neck :'( > >>> > >>> Are there any objections if we get the android build upstream ? AFAICS > >>> it's nicely isolated from everything else + I've managed to reuse all > >>> the source/headers lists. > >>> > >>> Note that the series lacks a couple of patches from the downstream > >>> repos, yet adds support for radeon, nouveau and freedreno :) > >>> > >>> The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel > >>> specific "hacks". If people are happy with the series then we can take > >>> a look at the final bits. > >>> > >>> > >>> Cheers, > >>> Emil > >>> > >> > >> ___ > >> dri-devel mailing list > >> dri-devel at lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > > > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] work around warning in i915_gem_gtt
On Mon, Jul 28, 2014 at 01:20:58PM +0200, Pavel Machek wrote:
>
> Gcc warns that addr might be used uninitialized. It may not, but I see
> why gcc gets confused.
>
> Additionally, hiding code with side-effects inside WARN_ON() argument
> seems uncool, so I moved it outside.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8b3cde7..8fcc974 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1448,7 +1448,7 @@ static void gen6_ggtt_insert_entries(struct
> i915_address_space *vm,
> (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm + first_entry;
> int i = 0;
> struct sg_page_iter sg_iter;
> - dma_addr_t addr;
> + dma_addr_t addr = 0;
I want to have a /* shuts up gcc */ for these kinds of things, where we
need to help out the compiler. Added and merged, thanks.
-Daniel
>
> for_each_sg_page(st->sgl, &sg_iter, st->nents, 0) {
> addr = sg_page_iter_dma_address(&sg_iter);
> @@ -1462,9 +1462,10 @@ static void gen6_ggtt_insert_entries(struct
> i915_address_space *vm,
>* of NUMA access patterns. Therefore, even with the way we assume
>* hardware should work, we must keep this posting read for paranoia.
>*/
> - if (i != 0)
> - WARN_ON(readl(>t_entries[i-1]) !=
> - vm->pte_encode(addr, level, true));
> + if (i != 0) {
> + unsigned long gtt = readl(>t_entries[i-1]);
> + WARN_ON(gtt != vm->pte_encode(addr, level, true));
> + }
>
> /* This next bit makes the above posting read even more important. We
>* want to flush the TLBs only after we're certain all the PTE updates
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures)
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 07/12] drm: drop redundant drm_file->is_master
Hi
On Fri, Jul 25, 2014 at 9:56 AM, Daniel Vetter wrote:
> On Thu, Jul 24, 2014 at 11:38:28PM +0200, David Herrmann wrote:
>> On Thu, Jul 24, 2014 at 11:52 AM, Daniel Vetter wrote:
>> > On Wed, Jul 23, 2014 at 05:26:42PM +0200, David Herrmann wrote:
>> >> +static inline bool drm_is_master(const struct drm_file *file)
>> >> +{
>> >
>> > Hm, we don't have any means to synchronize is_master checks with
>> > concurrent ioctls and stuff. Do we care? Orthogonal issue really.
>>
>> We don't.. My drm-master reworks contains a comment about that. It's
>> not really problematic as all ioctls run for a determinate time in
>> kernel-code except for drm_read(), but drm_read() is per-file, not
>> per-device, so we're fine. However, with unfortunate timings, we might
>> really end up with problems.
>>
>> vmwgfx solves this by using separate locks and verifying them against
>> the current master. it's not perfect and I'm not sure I like it better
>> than no locks, but at least they were aware of the problem.
>>
>> Btw., the only thing I know how to solve it properly is to make
>> "master_mutex" an rwlock and all f_op entries take the read-lock,
>> while master modifications take the write-lock. Not sure it's worth
>> it, though.
>
> Imo that's terrible. And I'm not even sure we need to care, e.g. if we do
> a master switch to a different compositor any ioctl the new compositor
> does will grab some locks, which will force the old ioctl to complete.
>
> Well mostly, and only if we don't do lockless tricks or lock-dropping and
> it's racy.
There is always a race! Like this:
CPU A:
1: enter drm_ioctl()
2: check file->is_master
3: enter drm_some_ioctl()
4: acquire some DRM internal locks
If CPU B acquires DRM-Master between step 2 and 3, CPU A might execute
an ioctl with an arbitrary delay. Maybe CPU B even executed some ioctl
after acquiring DRM-Master before CPU A had the chance to enter the
ioctl it's about to execute.
Not that I care much, but we have to remember that those races always
exist. Given that DRM-Master is privileged, this is not really
high-priority to fix..
> I guess a proper fix would be to wait for all ioctls on a device to
> complete. The vfs doesn't have any cool infrastructure for this as part of
> the general revoke work that we could reuse?
What the VFS rework does is this:
if (!atomic_inc_unless_negative(file->sth))
return -ENODEV;
ret = file->f_op->some_op();
atomic_dec(file->sth);
return ret;
That is, it wraps all calls to a file-operation with an
atomic-counter. However, there's only one counter per open-file, not
one per file-operation. If we'd want that for DRM-Master, we couldn't
use it as otherwise all file-operations would be blocked. Furthermore,
VFS only allows disabling an open-file. Once disabled, you cannot
enable it again.
So I don't think a read/write lock is a bad idea. RCU doesn't work as
our ioctls are way to heavy for rcu_read_lock(), SRCU is basically
rw-sem for our use-case. A hand-crafted atomic counter is also
equivalent to rw-sem. So yeah, it might lock nasty, but any other
solution will just hide the fact that we have a read/write lock.
Anyhow, I'm not working on a fix, so if no-one else looks at it, we
can just ignore it.
Thanks
David
[PATCH 1/5] drm/radeon: add userptr support v5
On Mon, Jul 28, 2014 at 01:30:08PM +0200, Christian K?nig wrote:
> +struct dma_buf *radeon_gem_prime_export(struct drm_device *dev,
> + struct drm_gem_object *gobj,
> + int flags)
> +{
> + struct radeon_bo *bo = gem_to_radeon_bo(gobj);
> + if (radeon_ttm_tt_has_userptr(bo->tbo.ttm))
> + return ERR_PTR(-EPERM);
dma-buf is used by wayland and dri3, so this won't cut it. Instead you
need to reject any real device attachments with a special ->attach
callback to make sure that dma-bufs are still useful as buffer cookies,
but not for actual cross-device sharing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH libdrm] libdrm: Fix drm.h include in qxl drm header file
2014-07-28 17:06 GMT+02:00 Emil Velikov : > On 28/07/14 15:35, Andreas Boll wrote: >> ping >> >> 2014-05-05 23:54 GMT+02:00 Andreas Boll : >>> Use "drm.h" instead of "drm/drm.h" as used in the other header files. >>> Fixes xserver-xorg-video-qxl build with KMS support on Debian, where this >>> file is installed in /usr/include/libdrm. >>> > I believe that's the default location for most linux distributions. Seems like > not many of us build the qxl ddx :\ > > FWIW > Reviewed-by: Emil Velikov > Thanks! Pushed. >>> Fixes Debian bug #746807 >>> >>> Reported-by: Bastian Blank >>> Signed-off-by: Andreas Boll >>> --- >>> include/drm/qxl_drm.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h >>> index 5d7de70..1e331a8 100644 >>> --- a/include/drm/qxl_drm.h >>> +++ b/include/drm/qxl_drm.h >>> @@ -25,7 +25,7 @@ >>> #define QXL_DRM_H >>> >>> #include >>> -#include "drm/drm.h" >>> +#include "drm.h" >>> >>> /* Please note that modifications to all structs defined here are >>> * subject to backwards-compatibility constraints. >>> -- >>> 1.9.2 >>> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 07/28/2014 04:00 AM, Inki Dae wrote:
> This patch adds LPM transfer support for video or command data.
>
> With this patch, Exynos MIPI DSI controller can transfer command or
> video data with HS or LP mode in accordance with mode_flags set
> by LCD Panel driver.
>
> Changelog v2: Enable High Speed clock only in case of stand by request.
>
> Signed-off-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 5e78d45..1bed105 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi
> *dsi)
> | DSIM_ESC_PRESCALER(esc_div)
> | DSIM_LANE_ESC_CLK_EN_CLK
> | DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
> - | DSIM_BYTE_CLK_SRC(0)
> - | DSIM_TX_REQUEST_HSCLK;
> + | DSIM_BYTE_CLK_SRC(0);
> +
> + if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
> + reg |= DSIM_TX_REQUEST_HSCLK;
> +
> writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>
> return 0;
> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi
> *dsi)
> writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
> }
>
> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
> + bool enable)
> +{
> + u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
> +
> + reg &= ~DSIM_TX_REQUEST_HSCLK;
> + if (enable)
> + reg |= DSIM_TX_REQUEST_HSCLK;
> +
> + writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
> +}
> +
I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
it works with and without the bit set.
So I start to suspect this bit is not just for simply enable/disable HS
clock as function name suggests, do you know what is its
exact meaning? The specs are quite succinct on it.
On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
in DSIM_ESCMODE register
which seems to be related to flags you have introduced:
- DSIM_CMD_LPDT_LP - transmit commands in LP mode,
- DSIM_TX_LPDT_LP - transmit data in LP mode.
The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
you use the latter?
Regards
Andrzej
> static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
> {
> u32 reg;
> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct
> exynos_dsi *dsi, bool enable)
> {
> u32 reg;
>
> + if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
> + exynos_dsi_enable_hs_clock(dsi, true);
> +
> reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
> if (enable)
> reg |= DSIM_MAIN_STAND_BY;
[PATCH] drm: add checking DRM_FORMAT_NV12MT
On Mon, Jul 28, 2014 at 12:47 AM, Joonyoung Shim wrote: > If user NV12MT uses as pixel format, the Addfb2 ioctl is failed because > of missing to check DRM_FORMAT_NV12MT. The NV12MT pixel format is > supported by exynos4 and some qualcomm chipset and it is used by exynos > drm driver. tbh, format_check() should probably just be made to respect the formats advertised by all the planes.. BR, -R > Signed-off-by: Joonyoung Shim > --- > drivers/gpu/drm/drm_crtc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index 1ccf5cb..5d7bd49 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -2960,6 +2960,7 @@ static int format_check(const struct drm_mode_fb_cmd2 > *r) > case DRM_FORMAT_NV61: > case DRM_FORMAT_NV24: > case DRM_FORMAT_NV42: > + case DRM_FORMAT_NV12MT: > case DRM_FORMAT_YUV410: > case DRM_FORMAT_YVU410: > case DRM_FORMAT_YUV411: > @@ -4800,6 +4801,7 @@ int drm_format_num_planes(uint32_t format) > case DRM_FORMAT_NV61: > case DRM_FORMAT_NV24: > case DRM_FORMAT_NV42: > + case DRM_FORMAT_NV12MT: > return 2; > default: > return 1; > @@ -4835,6 +4837,7 @@ int drm_format_plane_cpp(uint32_t format, int plane) > case DRM_FORMAT_NV61: > case DRM_FORMAT_NV24: > case DRM_FORMAT_NV42: > + case DRM_FORMAT_NV12MT: > return plane ? 2 : 1; > case DRM_FORMAT_YUV410: > case DRM_FORMAT_YVU410: > @@ -4878,6 +4881,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format) > case DRM_FORMAT_NV21: > case DRM_FORMAT_NV16: > case DRM_FORMAT_NV61: > + case DRM_FORMAT_NV12MT: > case DRM_FORMAT_YUV422: > case DRM_FORMAT_YVU422: > case DRM_FORMAT_YUV420: > @@ -4907,6 +4911,7 @@ int drm_format_vert_chroma_subsampling(uint32_t format) > case DRM_FORMAT_YVU420: > case DRM_FORMAT_NV12: > case DRM_FORMAT_NV21: > + case DRM_FORMAT_NV12MT: > return 2; > default: > return 1; > -- > 1.8.1.2 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #14 from Aaron B --- (In reply to comment #13) > (In reply to comment #6) > > Chromium randomly crashes with RadeonSI driver when using Chromium. Most > > usually with Youtube videos. > > Using Flash or HTML5 video? Fullscreen or windowed? ... I use HTML5 video. But it's a Chromium issue in general, flash video just helps it happen faster. It also happens a lot when switching tabs, clicking on content that adds a new element on the page over top of everything else, or loading more objects. Good examples are opening the comments section on Yahoo, and the mousing over of names on facebook. Think it'd be useful to try to attach a gdb session to Chromium? In the dmesg log, every time the problem happens, Chromium does receive a segfault. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/82a6dc07/attachment.html>
[PATCH] drm: add checking DRM_FORMAT_NV12MT
On Mon, Jul 28, 2014 at 11:56:59AM -0400, Rob Clark wrote: > On Mon, Jul 28, 2014 at 12:47 AM, Joonyoung Shim > wrote: > > If user NV12MT uses as pixel format, the Addfb2 ioctl is failed because > > of missing to check DRM_FORMAT_NV12MT. The NV12MT pixel format is > > supported by exynos4 and some qualcomm chipset and it is used by exynos > > drm driver. > > tbh, format_check() should probably just be made to respect the > formats advertised by all the planes.. That can't be done until all drivers are converted to primary/cursor planes. Also I'm not sure if we should allow it even then since that would make it quite easy to sneak in new driver specific formats without anyone necessarily reviewing them. > > BR, > -R > > > Signed-off-by: Joonyoung Shim > > --- > > drivers/gpu/drm/drm_crtc.c | 5 + > > 1 file changed, 5 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index 1ccf5cb..5d7bd49 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -2960,6 +2960,7 @@ static int format_check(const struct drm_mode_fb_cmd2 > > *r) > > case DRM_FORMAT_NV61: > > case DRM_FORMAT_NV24: > > case DRM_FORMAT_NV42: > > + case DRM_FORMAT_NV12MT: > > case DRM_FORMAT_YUV410: > > case DRM_FORMAT_YVU410: > > case DRM_FORMAT_YUV411: > > @@ -4800,6 +4801,7 @@ int drm_format_num_planes(uint32_t format) > > case DRM_FORMAT_NV61: > > case DRM_FORMAT_NV24: > > case DRM_FORMAT_NV42: > > + case DRM_FORMAT_NV12MT: > > return 2; > > default: > > return 1; > > @@ -4835,6 +4837,7 @@ int drm_format_plane_cpp(uint32_t format, int plane) > > case DRM_FORMAT_NV61: > > case DRM_FORMAT_NV24: > > case DRM_FORMAT_NV42: > > + case DRM_FORMAT_NV12MT: > > return plane ? 2 : 1; > > case DRM_FORMAT_YUV410: > > case DRM_FORMAT_YVU410: > > @@ -4878,6 +4881,7 @@ int drm_format_horz_chroma_subsampling(uint32_t > > format) > > case DRM_FORMAT_NV21: > > case DRM_FORMAT_NV16: > > case DRM_FORMAT_NV61: > > + case DRM_FORMAT_NV12MT: > > case DRM_FORMAT_YUV422: > > case DRM_FORMAT_YVU422: > > case DRM_FORMAT_YUV420: > > @@ -4907,6 +4911,7 @@ int drm_format_vert_chroma_subsampling(uint32_t > > format) > > case DRM_FORMAT_YVU420: > > case DRM_FORMAT_NV12: > > case DRM_FORMAT_NV21: > > + case DRM_FORMAT_NV12MT: > > return 2; > > default: > > return 1; > > -- > > 1.8.1.2 > > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel OTC
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 07/28/2014 04:00 AM, Inki Dae wrote:
> This patch adds below two flags for LPM transfer, and it attaches LPM flags
> to a msg in accordance with master's mode_flags set by LCD Panel driver.
>
> MIPI_DSI_MODE_CMD_LPM
> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> command data to Panel device in Low Power Mode.
What do you mean by command data? It could be:
- all transfer in command mode of operations,
- transfer initialized by the driver by writing to DSIM registers.
>
> MIPI_DSI_MODE_VIDEO_LPM
> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> image data to Panel device in Low Power Mode.
What is the meaning of this flag in case of command mode of operation?
Maybe it would be better to create flags based on source of data/FIFOs:
- commands send by SFR registers,
- commands generated from data sent from Display Controller.
>
> And above two flags can be combined together to transfer command and video
> data to Panel device.
>
> MIPI DSI spec says,
> "the host processor controls the desired mode of clock operation.
> Host protocol and applications control Clock Lane operating mode
> (High Speed or Low Power mode). System designers are responsible
> for understanding the clock requirements for peripherals attached
> to DSI and controlling clock behavior in accordance with those
> requirements."
>
> Some LCD Panel devices, nt35502a, would need LPM transfer support
> because they should receive some initial commands with LPM by default
> hardware setting.
Is this requirement for initial commands, or for all commands.
Btw what is the mode of operation of nt35502a? What flags do you need
for it?
>
> Changelog v2: just add more descriptions.
>
> Signed-off-by: Inki Dae
> Acked-by: Kyungmin Park
> ---
> drivers/gpu/drm/drm_mipi_dsi.c |3 +++
> include/drm/drm_mipi_dsi.h |4
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index e633df2..6b2bbda 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi,
> unsigned int channel,
> break;
> }
>
> + if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
> + msg.flags = MIPI_DSI_MSG_USE_LPM;
> +
> return ops->transfer(dsi->host, &msg);
> }
Shouldn't this be also the same for dcs read?
Anyway I think check in the DSIM should be used instead, as panel driver
can issue other dsi transfers without MIPI_DSI_MSG_USE_LPM flag set.
Regards
Andrzej
> EXPORT_SYMBOL(mipi_dsi_dcs_write);
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 944f33f..1c41e49 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
> #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8)
> /* disable EoT packets in HS mode */
> #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> +/* command low power mode */
> +#define MIPI_DSI_MODE_CMD_LPMBIT(10)
> +/* video low power mode */
> +#define MIPI_DSI_MODE_VIDEO_LPM BIT(11)
>
> enum mipi_dsi_pixel_format {
> MIPI_DSI_FMT_RGB888,
>
[PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella
On 07/28/2014 06:17 PM, Andreas F?rber wrote:
> Hi Lars-Peter,
>
> Am 25.07.2014 01:00, schrieb Andreas F?rber:
>> most notably I'm missing
>> ADI ADV7513 and AXI-HDMI support
> [...]
>> Cc: Lars-Peter Clausen (HDMI)
>
> Could you please enlighten us what the status of upstreaming
> ADV7511/ADV7513 support is? It is declared "work in progress" here:
>
> http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511
>
> I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
> drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
> nor any devicetree documentation. Patchwork doesn't show any recent
> submissions to LKML.
>
> Is any major rework needed for you to get the 3.14.12 based driver upstream?
>
It's complicated. The plan for the driver was to wait for the common display
framework (CDF) and convert it to use CDF and then submit it upstream. The
CDF has been rejected though. Meanwhile the V4L2 adv7511 driver has been
merged. So now we are in the ugly situation that we have two different
drivers for two different frameworks. To fix this we need to merge these two
drivers while still exposing the interfaces to both frameworks.
> AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
> Is there any work ongoing to get that upstream as well?
We need to teach the DMAengine framework about cyclic interleaved transfers
before the AXI HDMI driver can be submitted upstream.
- Lars
[Bug 79571] [Regression][radeon] Using Weston while playing video on X with VDPAU in background causes kernel panic.
https://bugzilla.kernel.org/show_bug.cgi?id=79571 M132 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE --- Comment #3 from M132 --- Alex Deucher, you're probably right as I couldn't reproduce this on 3.16-rc6. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/rcar-du: Fix maximum frame buffer pitch computation
The maximum pitch constraint for the hardware is expressed in pixels.
Convert it to bytes to validate frame buffer creation, as frame buffer
pitches are expressed in bytes.
Reported-by: Phil Edworthy
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3875854..7eabbd7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -135,7 +135,9 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
{
struct rcar_du_device *rcdu = dev->dev_private;
const struct rcar_du_format_info *format;
+ unsigned int max_pitch;
unsigned int align;
+ unsigned int bpp;
format = rcar_du_format_info(mode_cmd->pixel_format);
if (format == NULL) {
@@ -144,13 +146,20 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file
*file_priv,
return ERR_PTR(-EINVAL);
}
+ /*
+* The pitch and alignment constraints are expressed in pixels on the
+* hardware side and in bytes in the DRM API.
+*/
+ bpp = format->planes == 2 ? 1 : format->bpp / 8;
+ max_pitch = 4096 * bpp;
+
if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
align = 128;
else
- align = 16 * format->bpp / 8;
+ align = 16 * bpp;
if (mode_cmd->pitches[0] & (align - 1) ||
- mode_cmd->pitches[0] >= 8192) {
+ mode_cmd->pitches[0] >= max_pitch) {
dev_dbg(dev->dev, "invalid pitch value %u\n",
mode_cmd->pitches[0]);
return ERR_PTR(-EINVAL);
--
Regards,
Laurent Pinchart
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #58 from agapito --- 3.16 rc7 solved this bug! but i need more testing. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/c35e4823/attachment.html>
[Bug 79157] [Tesseract Game] Grainy SSAO on RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=79157 --- Comment #4 from smoki --- This seems fixed in current git 10.3-devel :). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/e4e29026/attachment.html>
[PATCH] drm/radeon: load the lm63 driver for an lm64 thermal chip.
Looks like the lm63 driver supports the lm64 as well.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon_atombios.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index fda1e41..2bbf016 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1963,7 +1963,7 @@ static const char *thermal_controller_names[] = {
"adm1032",
"adm1030",
"max6649",
- "lm64",
+ "lm63", /* lm64 */
"f75375",
"asc7xxx",
};
@@ -1974,7 +1974,7 @@ static const char *pp_lib_thermal_controller_names[] = {
"adm1032",
"adm1030",
"max6649",
- "lm64",
+ "lm63", /* lm64 */
"f75375",
"RV6xx",
"RV770",
--
1.8.3.1
[Bug 81281] New: 8970M boot problems since 3.13 with dpm
https://bugzilla.kernel.org/show_bug.cgi?id=81281 Bug ID: 81281 Summary: 8970M boot problems since 3.13 with dpm Product: Drivers Version: 2.5 Kernel Version: 3.16.0-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: sharkgoesmad at gmail.com Regression: No Created attachment 144531 --> https://bugzilla.kernel.org/attachment.cgi?id=144531&action=edit syslog I am using MSI GX60 3BE 240US, which is a AMD/AMD hybrid, sporting a10-5750m Richland apu and super-powerful HD 8970M. Since kernel 3.13, my laptop is unable to boot unless ran with radeon.dpm=0. Worth to note that 3.12 with radeon.dpm=1 works mighty fine. While trying different kernel versions and inspecting syslog, it seems that in all cases the problem starts with the following line: [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) In 3.13-3.15 it results in system restart when the login screen shows up. In 3.16 however, the screen freezes and no restart occurs. The system responds normally when pressing power button and shuts down. Attached is the piece of the syslog and Xorg.0.log when ran with 3.16-rc5. Any help would be greatly appreciated. Thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 81281] 8970M boot problems since 3.13 with dpm
https://bugzilla.kernel.org/show_bug.cgi?id=81281 --- Comment #1 from sharkgoesmad --- Created attachment 144541 --> https://bugzilla.kernel.org/attachment.cgi?id=144541&action=edit Xorg.0.log.old -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 81281] 8970M boot problems since 3.13 with dpm
https://bugzilla.kernel.org/show_bug.cgi?id=81281 sharkgoesmad changed: What|Removed |Added CC||sharkgoesmad at gmail.com Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 81281] 8970M boot problems since 3.13 with dpm
https://bugzilla.kernel.org/show_bug.cgi?id=81281 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- It looks like an issue with runtime pm rather than dpm. Does booting with radeon.runpm=0 fix the issue? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH -next] drm: Remove duplicated include from drm_plane_helper.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- drivers/gpu/drm/drm_plane_helper.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c index 6d13314..64ce96c 100644 --- a/drivers/gpu/drm/drm_plane_helper.c +++ b/drivers/gpu/drm/drm_plane_helper.c @@ -27,7 +27,6 @@ #include #include #include -#include #define SUBPIXEL_MASK 0x
[PATCH -next] drm/i915: Remove duplicated include from intel_dsi_panel_vbt.c
From: Wei Yongjun Remove duplicated include. Signed-off-by: Wei Yongjun --- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c index 47c7584..1439516 100644 --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c @@ -31,7 +31,6 @@ #include #include #include -#include #include "i915_drv.h" #include "intel_drv.h" #include "intel_dsi.h"
[PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella
Hi Lars-Peter,
Am 25.07.2014 01:00, schrieb Andreas F?rber:
> most notably I'm missing
> ADI ADV7513 and AXI-HDMI support
[...]
> Cc: Lars-Peter Clausen (HDMI)
Could you please enlighten us what the status of upstreaming
ADV7511/ADV7513 support is? It is declared "work in progress" here:
http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511
I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
nor any devicetree documentation. Patchwork doesn't show any recent
submissions to LKML.
Is any major rework needed for you to get the 3.14.12 based driver upstream?
AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
Is there any work ongoing to get that upstream as well?
Any pointers appreciated.
Thanks,
Andreas
[*]
http://wiki.analog.com/resources/tools-software/linux-drivers/platforms/zynq
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped
I think i probably hit a regression in the mesa libraries since older versions of mesa used to work. I'll try to downgrade from 10.1.6 and see what happens. Am 27.07.2014 um 14:47 schrieb Marek Ol??k: > I think the problem is the driver hasn't called > radeon_cs_space_add_persistent_bo. > > Marek > > On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen > wrote: >> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx >> Playstation1 Emulator to the Powerpc-architecture. When running certain >> games (for instance "Vagrant Stories") during longer cut-scenes i get a >> reproducible crash of the radeon drm driver (i.e. it always crashes at >> certain points in the scene) with the following message (in german): >> >> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung >> ?boi->space_accounted? nicht erf?llt. >> Abgebrochen (Speicherabzug geschrieben) >> >> This happens with all the latest 3.10, 3.12 and 3.14 kernels. >> >> Other than that i'm running the latest xorg-ati driver, libdrm and mesa from >> git on a Mac Mini G4 (PowerPC). >> >> OpenGL vendor string: Mesa Project >> OpenGL renderer string: Mesa DRI R200 (RV280 5962) TCL DRI2 >> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef) >> >> I guess the issue is memory/vm/swap-related since the machine only has 1 gb >> RAM. The GPU has 64 MB VRAM. >> >> Any ideas what i could do to avoid these crashes ? >> >> >> >> >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hey Inki, On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote: > Hey Inki, > > On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote: > > On 2014? 07? 19? 05:36, Sjoerd Simons wrote: > > > The exynos DRM module currently is not automatically loaded when build as > > > a > > > module. This is due to the simple fact that it doesn't have any > > > MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed > > > previously > > > as it wasn't possible at the time to have multiple calls to > > > MODULE_DEVICE_TABLE > > > in one module, however commit 21bdd17b21b45ea solved that. > > > > > > The first two patches revert the previous removals of MODULE_DEVICE_TABLE > > > calls, while the last one adds calls for the remaining OF match tables > > > without a > > > MODULE_DEVICE_TABLE call. > > > Exynos drm follows single-driver model. So each usb driver of Exynos drm > > wouldn't need its own MODULE_DEVICE_TABLE. > > Strictly speaking you're right, for module autoloading to work the > module just needs to have one that matches. So in principle all other > entries are redundant. > > However for exynos drm there does not seem to be one main device which > is guaranteed to always be present which can be used to key the module > autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries > for all the various subdrivers to ensure autoloading actually happens, > especially since the various subdrivers can be seperately enabled > at build time. Been about a week since this last mail. If you have any suggestions on a better approach or on how to move this forward, i'd be very grateful to hear as i think i've addressed your original comment on the set in the previous reply? -- Sjoerd Simons Collabora Ltd. -- next part ------ A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6170 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/16c29e60/attachment-0001.bin>
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hey Inki, On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: > On 2014? 07? 28? 17:30, Sjoerd Simons wrote: > Sorry for late, > > I don't see why Exynos drm driver should be auto-loaded module. I think > all devices covered by Exynos drm framework are not hot-plugged. Maybe > there is my missing point. So can you explain why Exynos drm driver > should be auto-loaded module? The background for this is that I'm building a distribution-style multiplatform kernel, that is to say a kernel which can boot on a big set of different ARM boards. As such, the intention is to keep the core zImage as small as possible and essentially build things as far as possible as loadable modules. So in a sense, all of the hardware is "hotplugged", depending on which board the kernel is actually booted on! For that use-case, exynosdrm needs to be able to build as a module (which it already can!) and it needs the required meta-data for userspace to know when it should be loaded. The latter is what my patch adds. -- Sjoerd Simons Collabora Ltd. -- next part -- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6170 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/14894732/attachment.bin>
