[Bug 81281] 8970M boot problems since 3.13 with dpm
https://bugzilla.kernel.org/show_bug.cgi?id=81281 --- Comment #3 from sharkgoesmad --- Thank you for looking into it! Yes, the startup was successful on 3.16 and I'm currently using it with no issues. I'll attach dmesg and xorg log file shortly. -- 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 #4 from sharkgoesmad --- Created attachment 144551 --> https://bugzilla.kernel.org/attachment.cgi?id=144551&action=edit dmesg on 3.16-rc5 with radeon.runpm=0 -- 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 Attachment #144541|0 |1 is obsolete|| --- Comment #5 from sharkgoesmad --- Created attachment 144561 --> https://bugzilla.kernel.org/attachment.cgi?id=144561&action=edit Xorg.0.log on 3.16-rc5 with radeon.runpm=0 -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
Hi Andrzej,
On 07/29/2014 01:09 AM, Andrzej Hajda wrote:
> 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.
The 2nd one.
>
>>
>> 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?
I'm also not sure that there is a case to transfer image data in Low
Power Mode, but this flag is not related with 'command mode' only.
Inki may consider generic condition.
>
> 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?
>
The nt35502a panel is video(RGB) mode panel and it requires low power
mode for initial commands, which means to initialize nt35502a panel, the
initial commands are transferred by LP mode(Not HS mode).
And after initialization, its other features like gamma control or etc
could be controlled in HS mode.
Thank you.
Best regards YJ
>
>
>>
>> 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_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_LPM BIT(11)
>>
>> enum mipi_dsi_pixel_format {
>> MIPI_DSI_FMT_RGB888,
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[Bug 79157] [Tesseract Game] Grainy SSAO on RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=79157 Michel D?nzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Michel D?nzer --- Yep, seems fixed, thanks for the followup. -- 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/20140729/69cdb8aa/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #116 from Michel D?nzer --- (In reply to comment #115) > I found > <http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3. > 16&id=f53f81b2576a9bd3af947e2b1c3a46dfab51c5ef>. Is that the correct commit > for Hawaii? Yes, but you probably want all page-flipping related fixes. > Doesn't look like the appropriate commit to me (so much "Evergreen" > everywhere), The programming of that hardware block hasn't changed since Evergreen. -- 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/20140729/cfb84e96/attachment.html>
[Bug 81837] [radeonsi] memory leaks in OpenCL
https://bugs.freedesktop.org/show_bug.cgi?id=81837 --- Comment #2 from Michel D?nzer --- The output from running the app with valgrind --leak-check=full might be interesting as well. -- 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/20140729/a3b4e903/attachment.html>
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 2014? 07? 29? 01:09, Andrzej Hajda wrote: > 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. > I wrote the descriptions in host controller point of view: with MIPI_DSI_MODE_CMD_LPM, host controller will set the operation mode to command mode operation and transfer command data to Panel (MIPI DSI client), and with MIPI_DSI_MODE_VIDEO_LPM, host controller will set the operation mode to video mode and transfer video data (pixel stream) to Panel. However, it seems that these descriptions aren't enough. So make sure the meanings. MIPI-DSI has two operation modes, Command and Video mode. And MIPI-DSI spec says, "Command Mode refers to operation in which transactions primarily take the form of sending commands and data to a peripheral, such as a display module, that incorporates a display controller. The display controller may include local registers and a frame buffer. Systems using Command Mode write to, and read from, the registers and frame buffer memory. The host processor indirectly controls activity at the peripheral by sending commands, parameters and data to the display controller. The host processor can also read display module status information or the contents of the frame memory. Command Mode operation requires a bidirectional interface.". And also the spec says for Video mode, "Video mode Mode refers to operation in which transfers from the host processor to the peripheral take the form of a real-time pixel stream. In normal operation, the display module relies on the host processor to provide image data at sufficient bandwidth to avoid flicker or other visible artifacts in the displayed image. Video information should only be transmitted using High Speed Mode. Some Video Mode architectures may include a simple timing controller and partial frame buffer, used to maintain a partial-screen or lower-resolution image in standby or low-power mode. This permits the interface to be shut down to reduce power consumption. To reduce complexity and cost, systems that only operate in Video Mode may use a unidirectional data path." Thus, with Command mode, host can send command and image data to Panel device, and with Video mode, host can send image data to Panel device in High Speed Mode (HS clock enabled) Therefore, I think MIPI_DSI_MODE_CMD_LPM and MIPI_DSI_MODE_VIDEO_LPM flags have generic meaning, In default, host transmits Command and image data to Panel in High Speed Mode. MIP_DSI_MODE_CMD_LPM: Host transmits command and image data to Panel in Low Power mode, and also the host can read data from SRF and internal frame buffer of Panel device. With this flag, host needs to set transmission mode to Low Power Mode (and HS clock disabled) MIPI_DSI_MODE_VIDEO_LPM: Host transmits image data to Panel in Low Power mode. With this flags, host needs to set transmission mode to Low Power Mode. I think above two flags are common to all SoC. In case of Exynos MIPI-DSI, 'CmdLpdt bit = 1' specifies that host transmits commands to Panel in Low Power Mode so this would be corresponded to MIPI_DSI_MODE_CMD_LPM. However, 'TxLpdt = 1' specifies that host transmits all data that include commands and imageto Panel in Low Power Mode (and HS clock disabled). So this bit would be corresponded to MIPI_DSI_MODE_VIDEO_LPM. Feel free to give me your opinions if you have other opinions or there is my missing point. Thanks, Inki Dae > >> >> 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 comman
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #33 from Michel D?nzer --- (In reply to comment #32) > > 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. Yep, that looks like bug 81834. I'm actually not sure why I'm not failing the assertion in Mesa before the one in LLVM. > (bug 81834 doesn't say what versions he uses. I normally use current Git of everything. -- 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/20140729/f7a0fe8c/attachment.html>
[Bug 75276] Implement VGPR Register Spilling
https://bugs.freedesktop.org/show_bug.cgi?id=75276 --- Comment #34 from Michel D?nzer --- (In reply to comment #33) > > So I built mesa with debug symbols and I guess debugging enables some > > assertions because now fails at some assertion about Register.Index stuff. > > Yep, that looks like bug 81834. BTW, you may be able to work around this by reverting Mesa commit f4b0ab7afd83c811329211eae8167c9bf238870c, but then you may run into bug 80880 instead. -- 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/20140729/e0890101/attachment.html>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #15 from Michel D?nzer --- (In reply to comment #14) > I use HTML5 video. But it's a Chromium issue in general, flash video just > helps it happen faster. Is it HTML5 or Flash now? :) > 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. Yes, backtraces of those crashes might be interesting. -- 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/20140729/9e14f0cd/attachment.html>
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
> 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.
If you can test thmorstat board, you will face with that its panel is
not worked.
> 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.
HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
> 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.
As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
that host can transmit command and also image data to Panel in Low Power
Mode. So these flags are specific to MIPI-DSI controller of Exynos.
> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
This flag is set only when command msg transmission is requested by
Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
transmit command and also image.
Thanks,
Inki Dae
> 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;
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #16 from Aaron B --- (In reply to comment #15) > (In reply to comment #14) > > I use HTML5 video. But it's a Chromium issue in general, flash video just > > helps it happen faster. > > Is it HTML5 or Flash now? :) > > > > 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. > > Yes, backtraces of those crashes might be interesting. Whoops, I meant the video playing in HTML5 made the glitch happen worse. But it's video in general, Flash video on other sites does crash it too. And okay, if I can get it working I'll hopefully have a good log to show sooner or later. -- 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/20140729/051b9ecf/attachment.html>
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 28? 23:45, Sjoerd Simons wrote: > 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. > It seems that you want that module data of sub drivers are added by depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some hot-plug system should use modules.xxxmap file to find the proper driver to load. Ok, then does exynos drm driver is loaded well with your patches? My concern is that device_id of exynos drm core driver , exynos_drm_drv.c, wouldn't be exported to userspace, which means that exynos drm subsystem aren't bound by component framework because most sub drivers except vidi are bound by component interfaces of exynos drm core: exynos drm drv is not device tree base driver. Thanks, Inki Dae
[Bug 81644] Random crashes on RadeonSI with Chromium.
https://bugs.freedesktop.org/show_bug.cgi?id=81644 --- Comment #17 from Aaron B --- I just got a crash while trying to get some debugging output...but all Chromium would output, and it was just through the terminal, was "GPU process stalled after 1ms." and that was basically all the information I got from it. I'll try again tomorrow, maybe try valgrind or some different CL arguments this time around. We'll see. Now it's time for sleep, though. -- 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/20140729/6640be4e/attachment.html>
[PATCH 1/5] drm/radeon: add userptr support v5
Am 28.07.2014 um 17:27 schrieb Daniel Vetter:
> 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.
It's not only cross device sharing we need to deny, but indeed cross
process sharing of the buffer.
Apart from that those buffers should never leave the driver in any way.
Christian.
> -Daniel
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #12 from Maciej --- It started happening no more than two weeks ago (doing Mesa updates through Oibaf PPA almost daily). Happens with Kernel 3.15.6 and 3.16-RCx (up to latest RC7) on Ubuntu 14.04 with HD7770. -- 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/20140729/c09b31d7/attachment.html>
[PATCH 3/3] drm/radeon/cik: Read back SDMA WPTR register after writing it
From: Michel D?nzer For symmetry with other *_set_wptr hooks. Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/cik_sdma.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/cik_sdma.c b/drivers/gpu/drm/radeon/cik_sdma.c index 73bd2b2..ec7c7b6 100644 --- a/drivers/gpu/drm/radeon/cik_sdma.c +++ b/drivers/gpu/drm/radeon/cik_sdma.c @@ -121,6 +121,7 @@ void cik_sdma_set_wptr(struct radeon_device *rdev, reg = SDMA0_GFX_RB_WPTR + SDMA1_REGISTER_OFFSET; WREG32(reg, (ring->wptr << 2) & 0x3fffc); + (void)RREG32(reg); } /** -- 2.0.1
[PATCH 2/3] drm/radeon: Use write-combined CPU mappings of IBs on >= CIK
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_ring.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 7cfea7e..20b0e4f 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -201,10 +201,22 @@ int radeon_ib_pool_init(struct radeon_device *rdev)
if (rdev->ib_pool_ready) {
return 0;
}
- r = radeon_sa_bo_manager_init(rdev, &rdev->ring_tmp_bo,
- RADEON_IB_POOL_SIZE*64*1024,
- RADEON_GPU_PAGE_SIZE,
- RADEON_GEM_DOMAIN_GTT, 0);
+
+ if (rdev->family >= CHIP_BONAIRE) {
+ r = radeon_sa_bo_manager_init(rdev, &rdev->ring_tmp_bo,
+ RADEON_IB_POOL_SIZE*64*1024,
+ RADEON_GPU_PAGE_SIZE,
+ RADEON_GEM_DOMAIN_GTT,
+ RADEON_GEM_GTT_WC);
+ } else {
+ /* Before CIK, it's better to stick to cacheable GTT due
+* to the command stream checking
+*/
+ r = radeon_sa_bo_manager_init(rdev, &rdev->ring_tmp_bo,
+ RADEON_IB_POOL_SIZE*64*1024,
+ RADEON_GPU_PAGE_SIZE,
+ RADEON_GEM_DOMAIN_GTT, 0);
+ }
if (r) {
return r;
}
--
2.0.1
[PATCH 1/3] drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe
From: Michel D?nzer
PCI GART doesn't support unsnooped access. AGP GART already uses
write-combined CPU mappings.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/radeon_ring.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 71439f0..7cfea7e 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -640,7 +640,9 @@ int radeon_ring_init(struct radeon_device *rdev, struct
radeon_ring *ring, unsig
/* Allocate ring buffer */
if (ring->ring_obj == NULL) {
r = radeon_bo_create(rdev, ring->ring_size, PAGE_SIZE, true,
-RADEON_GEM_DOMAIN_GTT, 0,
+RADEON_GEM_DOMAIN_GTT,
+(rdev->flags & RADEON_IS_PCIE) ?
+RADEON_GEM_GTT_WC : 0,
NULL, &ring->ring_obj);
if (r) {
dev_err(rdev->dev, "(%d) ring create failed\n", r);
--
2.0.1
[PATCH 1/3] drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe
Am 29.07.2014 um 11:47 schrieb Michel D?nzer:
> From: Michel D?nzer
>
> PCI GART doesn't support unsnooped access. AGP GART already uses
> write-combined CPU mappings.
>
> Signed-off-by: Michel D?nzer
For this series Reviewed-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/radeon_ring.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index 71439f0..7cfea7e 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -640,7 +640,9 @@ int radeon_ring_init(struct radeon_device *rdev, struct
> radeon_ring *ring, unsig
> /* Allocate ring buffer */
> if (ring->ring_obj == NULL) {
> r = radeon_bo_create(rdev, ring->ring_size, PAGE_SIZE, true,
> - RADEON_GEM_DOMAIN_GTT, 0,
> + RADEON_GEM_DOMAIN_GTT,
> + (rdev->flags & RADEON_IS_PCIE) ?
> + RADEON_GEM_GTT_WC : 0,
>NULL, &ring->ring_obj);
> if (r) {
> dev_err(rdev->dev, "(%d) ring create failed\n", r);
[PATCH 1/4] drm/radeon: invalidate moved BOs in the VM
This series is Tested-by: Michel D?nzer -- Earthling Michel D?nzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH 4/4] imx-drm: ipuv3-plane: fix plane updates for active planes
While the DMA channel is running, it is not allowed to change anything
but the inactive (double) buffer base address, so resizing a plane or
changing to a frame buffer with different pixel format is not possible.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 15 +++
drivers/staging/imx-drm/ipuv3-plane.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index 9fdab14..3dfcdfd 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -145,6 +145,18 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
if (crtc_h < 2)
return -EINVAL;
+ /*
+* since we cannot touch active IDMAC channels, we do not support
+* resizing the enabled plane or changing its format
+*/
+ if (ipu_plane->enabled) {
+ if (src_w != ipu_plane->w || src_h != ipu_plane->h ||
+ fb->pixel_format != ipu_plane->base.fb->pixel_format)
+ return -EINVAL;
+
+ return ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
+ }
+
switch (ipu_plane->dp_flow) {
case IPU_DP_FLOW_SYNC_BG:
ret = ipu_dp_setup_channel(ipu_plane->dp,
@@ -205,6 +217,9 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
if (ret < 0)
return ret;
+ ipu_plane->w = src_w;
+ ipu_plane->h = src_h;
+
return 0;
}
diff --git a/drivers/staging/imx-drm/ipuv3-plane.h
b/drivers/staging/imx-drm/ipuv3-plane.h
index c0aae5b..af125fb 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.h
+++ b/drivers/staging/imx-drm/ipuv3-plane.h
@@ -26,6 +26,8 @@ struct ipu_plane {
int x;
int y;
+ int w;
+ int h;
boolenabled;
};
--
2.0.1
[PATCH 3/4] imx-drm: ipuv3-plane: enable double buffering
This allows to update the buffer base address while the DMA
channel is running. It is needed to flip the frame buffer of
an active plane.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index 9f79a17..9fdab14 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -65,6 +65,7 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
drm_framebuffer *fb,
struct ipu_ch_param __iomem *cpmem;
struct drm_gem_cma_object *cma_obj;
unsigned long eba;
+ int active;
cma_obj = drm_fb_cma_get_gem_obj(fb, 0);
if (!cma_obj) {
@@ -75,11 +76,17 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct
drm_framebuffer *fb,
dev_dbg(ipu_plane->base.dev->dev, "phys = %pad, x = %d, y = %d",
&cma_obj->paddr, x, y);
- cpmem = ipu_get_cpmem(ipu_plane->ipu_ch);
eba = cma_obj->paddr + fb->offsets[0] +
fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x;
- ipu_cpmem_set_buffer(cpmem, 0, eba);
- ipu_cpmem_set_buffer(cpmem, 1, eba);
+
+ cpmem = ipu_get_cpmem(ipu_plane->ipu_ch);
+ if (ipu_plane->enabled) {
+ active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
+ ipu_cpmem_set_buffer(cpmem, !active, eba);
+ } else {
+ ipu_cpmem_set_buffer(cpmem, 0, eba);
+ ipu_cpmem_set_buffer(cpmem, 1, eba);
+ }
/* cache offsets for subsequent pageflips */
ipu_plane->x = x;
@@ -191,6 +198,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
return ret;
}
ipu_cpmem_set_high_priority(ipu_plane->ipu_ch);
+ ipu_idmac_set_double_buffer(ipu_plane->ipu_ch, 1);
ipu_cpmem_set_stride(cpmem, fb->pitches[0]);
ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y);
--
2.0.1
[PATCH 2/4] imx-drm: ipuv3-plane: move stride setting out of base setup
Setting the stride can only be done on inactive channels, while the buffer base address can also be updated for running channels using the hardware double buffering feature. Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/ipuv3-plane.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/imx-drm/ipuv3-plane.c b/drivers/staging/imx-drm/ipuv3-plane.c index 43e36ea..9f79a17 100644 --- a/drivers/staging/imx-drm/ipuv3-plane.c +++ b/drivers/staging/imx-drm/ipuv3-plane.c @@ -76,8 +76,6 @@ int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct drm_framebuffer *fb, &cma_obj->paddr, x, y); cpmem = ipu_get_cpmem(ipu_plane->ipu_ch); - ipu_cpmem_set_stride(cpmem, fb->pitches[0]); - eba = cma_obj->paddr + fb->offsets[0] + fb->pitches[0] * y + (fb->bits_per_pixel >> 3) * x; ipu_cpmem_set_buffer(cpmem, 0, eba); @@ -193,6 +191,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct drm_crtc *crtc, return ret; } ipu_cpmem_set_high_priority(ipu_plane->ipu_ch); + ipu_cpmem_set_stride(cpmem, fb->pitches[0]); ret = ipu_plane_set_base(ipu_plane, fb, src_x, src_y); if (ret < 0) -- 2.0.1
[PATCH 1/4] imx-drm: ipuv3-plane: allow local alpha in ipu_plane_mode_set()
For the overlay plane scanning out a framebuffer with an alpha component,
enable the DP local alpha feature on the partial plane.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-plane.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/imx-drm/ipuv3-plane.c
b/drivers/staging/imx-drm/ipuv3-plane.c
index 50de10a..43e36ea 100644
--- a/drivers/staging/imx-drm/ipuv3-plane.c
+++ b/drivers/staging/imx-drm/ipuv3-plane.c
@@ -151,14 +151,22 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane,
struct drm_crtc *crtc,
ret);
return ret;
}
- ipu_dp_set_global_alpha(ipu_plane->dp, 1, 0, 1);
+ ipu_dp_set_global_alpha(ipu_plane->dp, true, 0, true);
break;
case IPU_DP_FLOW_SYNC_FG:
ipu_dp_setup_channel(ipu_plane->dp,
ipu_drm_fourcc_to_colorspace(fb->pixel_format),
IPUV3_COLORSPACE_UNKNOWN);
ipu_dp_set_window_pos(ipu_plane->dp, crtc_x, crtc_y);
- break;
+ /* Enable local alpha on partial plane */
+ switch (fb->pixel_format) {
+ case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ABGR:
+ ipu_dp_set_global_alpha(ipu_plane->dp, false, 0, false);
+ break;
+ default:
+ break;
+ }
}
ret = ipu_dmfc_init_channel(ipu_plane->dmfc, crtc_w);
--
2.0.1
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #13 from Damian Nowak --- @Maciej, Please analyze dpkg logs and tell what Mesa version started to behave incorrectly for you. @Michel, haven't been able to try 10.2.* since I have been very busy recently and needed a non-hanging machine, hence used 10.1.4 for time being. When I'm less busy I will go back to the case and try out next versions. -- 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/20140729/072398c7/attachment.html>
[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support
On 07/29/2014 02:57 AM, YoungJun Cho wrote:
> Hi Andrzej,
>
> On 07/29/2014 01:09 AM, Andrzej Hajda wrote:
>> 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.
> The 2nd one.
>
>>> 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?
> I'm also not sure that there is a case to transfer image data in Low
> Power Mode, but this flag is not related with 'command mode' only.
> Inki may consider generic condition.
>
>> 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?
>>
> The nt35502a panel is video(RGB) mode panel and it requires low power
> mode for initial commands, which means to initialize nt35502a panel, the
> initial commands are transferred by LP mode(Not HS mode).
> And after initialization, its other features like gamma control or etc
> could be controlled in HS mode.
It sounds similar to my tc358764 bridge driver [1]. The difference is that
it uses only MIPI_DSI_GENERIC_LONG_(WRITE|READ) in LPM.
As I understand nt35502a requires also different driving of
TxRequestHSClk signal
and this seems to me unrelated to LPM. As LPM is not related at all with
HS clock, AFAIK.
Regards
Andrzej
[1]: http://permalink.gmane.org/gmane.linux.drivers.devicetree/61559
>
> Thank you.
> Best regards YJ
>
>>
>>> 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_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,
>>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
[Bug 81690] nouveau GPU locks up under memory pressure
https://bugs.freedesktop.org/show_bug.cgi?id=81690 --- Comment #1 from sven --- I also have memory related problems when loading big textures. When I try to use a ~717MB sized OpenGL 2D texture array, I get the following to the application's stderr (or stdout, haven't checked): > nouveau: kernel rejected pushbuf: Device or resource busy > nouveau: ch0: krec 0 pushes 1 bufs 10 relocs 0 > nouveau: ch0: buf 0003 0004 0004 > nouveau: ch0: buf 0001 0010 0002 0002 > nouveau: ch0: buf 0002 0008 0002 0002 > nouveau: ch0: buf 0003 0013 0002 0002 0002 > nouveau: ch0: buf 0004 0019 0002 0002 > nouveau: ch0: buf 0005 0011 0002 0002 > nouveau: ch0: buf 0006 0012 0002 0002 > nouveau: ch0: buf 0007 0015 0002 0002 > nouveau: ch0: buf 0008 0017 0002 0002 > nouveau: ch0: buf 0009 0014 0002 0002 > nouveau: ch0: psh 04e6fc 04eef4 And the kernel log reads: > [ 12.849796] nouveau [ DEVICE][:01:00.0] Chipset: GF119 (NVD9) > [ 12.849800] nouveau [ DEVICE][:01:00.0] Family : NVD0 > [ 13.584920] nouveau [ PFB][:01:00.0] RAM size: 1024 MiB ... > [ 328.496640] nouveau W[ PFIFO][:01:00.0] INTR 0x0001: 0x > [ 328.496652] nouveau E[ PFIFO][:01:00.0] INTR 0x0880 > [ 328.496689] nouveau E[PBUS][:01:00.0] MMIO read of 0x > FAULT at 0x002100 [ !ENGINE ] > [ 340.851380] nouveau E[ PFIFO][:01:00.0] read fault at 0x003a33 > [PAGE_NOT_PRESENT] from PGRAPH/DISPATCH on channel 0x003fb4e000 > [DummyName[1554]] > [ 340.851386] nouveau E[ PFIFO][:01:00.0] PGRAPH engine fault on > channel 3, recovering... > [ 344.331776] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 344.438226] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 344.544699] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 344.650491] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 344.756217] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 344.861902] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 344.969239] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 345.076069] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 345.183105] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 345.290630] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 345.398302] nouveau E[DummyName[1554]] nv50cal_space: -16 > [ 360.409590] nouveau E[DummyName[1554]] failed to idle channel 0x > [DummyName[1554]] > [ 360.512756] nouveau E[DummyName[1554]] failed to idle channel 0x > [DummyName[1554]] -- 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/20140729/06b749d2/attachment-0001.html>
[Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote: > On 23 July 2014 06:02, Paulo Zanoni wrote: >> 2014-06-05 1:01 GMT-03:00 Dave Airlie : >>> From: Dave Airlie >>> >>> This adds DP 1.2 MST support on Haswell systems. >> >> Hi >> >> It looks like drm-intel-nightly now includes this patch. It actually >> includes v7, but I couldn't find it on my mail dirs. >> >> Just by booting the machine with this patch, I get: >> > > There are two patches in my drm-i915-next branch > > They should remove the offending bits for the fbdev and powersave warning. Paulo, can you please test these two patches? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On 29 July 2014 20:46, Daniel Vetter wrote: > On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote: >> On 23 July 2014 06:02, Paulo Zanoni wrote: >>> 2014-06-05 1:01 GMT-03:00 Dave Airlie : From: Dave Airlie This adds DP 1.2 MST support on Haswell systems. >>> >>> Hi >>> >>> It looks like drm-intel-nightly now includes this patch. It actually >>> includes v7, but I couldn't find it on my mail dirs. >>> >>> Just by booting the machine with this patch, I get: >>> >> >> There are two patches in my drm-i915-next branch >> >> They should remove the offending bits for the fbdev and powersave warning. > > Paulo, can you please test these two patches? > Oh he did already, didn't I push them? I must have forgotten. Dave.
[Intel-gfx] [PATCH 09/11] i915: add DP 1.2 MST support (v0.6)
On Tue, Jul 29, 2014 at 12:50 PM, Dave Airlie wrote: > On 29 July 2014 20:46, Daniel Vetter wrote: >> On Wed, Jul 23, 2014 at 6:32 AM, Dave Airlie wrote: >>> On 23 July 2014 06:02, Paulo Zanoni wrote: 2014-06-05 1:01 GMT-03:00 Dave Airlie : > From: Dave Airlie > > This adds DP 1.2 MST support on Haswell systems. Hi It looks like drm-intel-nightly now includes this patch. It actually includes v7, but I couldn't find it on my mail dirs. Just by booting the machine with this patch, I get: >>> >>> There are two patches in my drm-i915-next branch >>> >>> They should remove the offending bits for the fbdev and powersave warning. >> >> Paulo, can you please test these two patches? >> > Oh he did already, didn't I push them? I must have forgotten. Oh, I guess I've missed that since it didn't go over the m-l ;-) It's there already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
> Hi Ajay,
>
> Am 28.07.2014 08:13, schrieb Ajay kumar:
> > On 7/27/14, Andreas F?rber wrote:
> >> 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
>
> That fixed my build, thanks.
>
> Unfortunately the most I got on Spring with attached DT was a blank
> screen with a white horizontal line in the middle.
>
> Do I need to specify a specific panel model for Spring?
>
> For testing I re-applied your iommu patches (which btw fail now for 5420
> due to disp_pd) but didn't know what to do about your panel-lvds
> regulator patch now that it's gone.
>
> If I don't apply this series, then commenting out the dp-controller node
> gets me a working display with simplefb as before.
>
> Regards,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andreas=20F=C3=A4rber?=
> Date: Sun, 27 Jul 2014 21:58:06 +0200
> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Signed-off-by: Ajay Kumar
> [AF: Redone for v6]
> Signed-off-by: Andreas F??rber
> ---
> arch/arm/boot/dts/exynos5250-spring.dts | 32 +++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> b/arch/arm/boot/dts/exynos5250-spring.dts
> index 687dfab86bc8..517b1ff2bfdf 100644
> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> @@ -64,10 +64,14 @@
> vdd_pll-supply = <&s5m_ldo8_reg>;
> };
>
> + panel: panel {
> + compatible = "simple-panel";
> + };
You can't do this. "simple-panel" isn't a valid panel model. It should
probably be removed from the platform_of_match table in the driver.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140729/363a8db7/attachment.sig>
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 07/29/2014 05:42 AM, Inki Dae wrote:
> On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
>> 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.
> If you can test thmorstat board, you will face with that its panel is
> not worked.
So it means this panel requires proper driving of this bit, but it does
not prove it is
LPM related.
>> 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.
> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
This sounds very strange. DSI specs and D-PHY specs says clearly
that LPM transmissions are unrelated to HS clock [1][2]. Even timing
diagrams
in Exynos specs shows no dependency of LPM transmissions on HS clock.
And the
description of TxRequestHsClk bit says "HS clock request for HS transfer
at clock lane (Turn
on HS clock)".
Maybe different flag should be used to describe your panel requirements
regarding this bit.
It would be good to see the real initialization sequence in form of
pseudo-code or better in the driver.
[1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
functionally embedded in the data signals. When LP
data transmission ends, the clock effectively stops and subsequent LP
clocks are not available to the
peripheral. The peripheral shall not require additional bits, bytes, or
packets from the host processor in
order to complete processing or pipeline movement of received data in LP
mode transmissions. There are a
variety of ways to meet this requirement. For example, the peripheral
may generate its own clock or it may
require the host processor to keep the HS serial clock running."
[2]: MIPI D-PHY: "The data is self-clocked by the applied bit encoding
and does not rely on the Clock Lane".
Regards
Andrzej
>
>> 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.
> As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
> that host can transmit command and also image data to Panel in Low Power
> Mode. So these flags are specific to MIPI-DSI controller of Exynos.
>
>> The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
> This flag is set only when command msg transmission is requested by
> Panel driver. So we would need separated flags, MIPI_DSI_MODE_CMD_LPM
> and MIPI_DSI_MODE_VIDEO_LPM, to notify how host controller should
> transmit command and also image.
>
> Thanks,
> Inki Dae
>
>> 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
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:36:46PM +0200, Thierry Reding wrote:
> On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
> > Hi Ajay,
> >
> > Am 28.07.2014 08:13, schrieb Ajay kumar:
> > > On 7/27/14, Andreas F?rber wrote:
> > >> 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
> >
> > That fixed my build, thanks.
> >
> > Unfortunately the most I got on Spring with attached DT was a blank
> > screen with a white horizontal line in the middle.
> >
> > Do I need to specify a specific panel model for Spring?
> >
> > For testing I re-applied your iommu patches (which btw fail now for 5420
> > due to disp_pd) but didn't know what to do about your panel-lvds
> > regulator patch now that it's gone.
> >
> > If I don't apply this series, then commenting out the dp-controller node
> > gets me a working display with simplefb as before.
> >
> > Regards,
> > Andreas
> >
> > --
> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
>
> > From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Andreas=20F=C3=A4rber?=
> > Date: Sun, 27 Jul 2014 21:58:06 +0200
> > Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Signed-off-by: Ajay Kumar
> > [AF: Redone for v6]
> > Signed-off-by: Andreas F??rber
> > ---
> > arch/arm/boot/dts/exynos5250-spring.dts | 32
> > +++-
> > 1 file changed, 31 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> > b/arch/arm/boot/dts/exynos5250-spring.dts
> > index 687dfab86bc8..517b1ff2bfdf 100644
> > --- a/arch/arm/boot/dts/exynos5250-spring.dts
> > +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> > @@ -64,10 +64,14 @@
> > vdd_pll-supply = <&s5m_ldo8_reg>;
> > };
> >
> > + panel: panel {
> > + compatible = "simple-panel";
> > + };
>
> You can't do this. "simple-panel" isn't a valid panel model. It should
> probably be removed from the platform_of_match table in the driver.
Done.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140729/796eb26d/attachment-0001.sig>
[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support
On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas F?rber wrote:
> Am 29.07.2014 13:36, schrieb Thierry Reding:
> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas F?rber wrote:
> >> Hi Ajay,
> >>
> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> >>> On 7/27/14, Andreas F?rber wrote:
> >>>> 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
> [...]
> >> Unfortunately the most I got on Spring with attached DT was a blank
> >> screen with a white horizontal line in the middle.
> >>
> >> Do I need to specify a specific panel model for Spring?
> [...]
> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00 2001
> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?=
> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> >> MIME-Version: 1.0
> >> Content-Type: text/plain; charset=UTF-8
> >> Content-Transfer-Encoding: 8bit
> >>
> >> Signed-off-by: Ajay Kumar
> >> [AF: Redone for v6]
> >> Signed-off-by: Andreas F??rber
> >> ---
> >> arch/arm/boot/dts/exynos5250-spring.dts | 32
> >> +++-
> >> 1 file changed, 31 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> >> b/arch/arm/boot/dts/exynos5250-spring.dts
> >> index 687dfab86bc8..517b1ff2bfdf 100644
> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> >> @@ -64,10 +64,14 @@
> >>vdd_pll-supply = <&s5m_ldo8_reg>;
> >>};
> >>
> >> + panel: panel {
> >> + compatible = "simple-panel";
> >> + };
> >
> > You can't do this. "simple-panel" isn't a valid panel model. It should
> > probably be removed from the platform_of_match table in the driver.
>
> Okay, that means the Snow DT is wrong, too:
> https://patchwork.kernel.org/patch/4625441/
>
> And the others specify it as fallback:
> https://patchwork.kernel.org/patch/4625461/
> https://patchwork.kernel.org/patch/4625451/
A quick grep shows that many (all?) devices that use DRM panels provide
simple-panel as fallback. That's probably fine as long as they also do
provide the specific model. But given that simple-panel does not have a
mode or physical size, I don't think even that makes sense.
Any of the DTS files in the tree I have that list simple-panel as a
fallback are Tegra, so I'll go write a patch that removes the fallback.
I can't think of a reason why it would ever be needed or meaningful.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140729/93f94111/attachment.sig>
[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support
On 2014? 07? 29? 20:39, Andrzej Hajda wrote:
> On 07/29/2014 05:42 AM, Inki Dae wrote:
>> On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
>>> 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.
>> If you can test thmorstat board, you will face with that its panel is
>> not worked.
>
> So it means this panel requires proper driving of this bit, but it does
> not prove it is
> LPM related.
>
>>> 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.
>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
>
> This sounds very strange. DSI specs and D-PHY specs says clearly
> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
> diagrams
> in Exynos specs shows no dependency of LPM transmissions on HS clock.
> And the
> description of TxRequestHsClk bit says "HS clock request for HS transfer
> at clock lane (Turn
> on HS clock)".
There are three System power states of D-PHY, Low-Power mode, High-Speed
mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
Lane. Therefore, to use HS mode, HS clock should be enabled. On the
other hand, LP mode needs only 10MHz (max).
So do you really think LP mode will be worked well with HS clock
enabled? The purpose of LP mode is to reduce power consumption while
transmitting data. Can you reduce the power consumption in LP mode with
HS clock enabled?
Thanks,
Inki Dae
>
> Maybe different flag should be used to describe your panel requirements
> regarding this bit.
>
> It would be good to see the real initialization sequence in form of
> pseudo-code or better in the driver.
>
>
> [1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
> functionally embedded in the data signals. When LP
> data transmission ends, the clock effectively stops and subsequent LP
> clocks are not available to the
> peripheral. The peripheral shall not require additional bits, bytes, or
> packets from the host processor in
> order to complete processing or pipeline movement of received data in LP
> mode transmissions. There are a
> variety of ways to meet this requirement. For example, the peripheral
> may generate its own clock or it may
> require the host processor to keep the HS serial clock running."
>
> [2]: MIPI D-PHY: "The data is self-clocked by the applied bit encoding
> and does not rely on the Clock Lane".
>
> Regards
> Andrzej
>
>>
>>> 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.
>> As I mentioned already at other email thread, DSIM_TX_LPDT_LP specifies
>> that host can transmit command and also image data to Panel in Low Power
>> Mode. So these flags are specific to MIPI-D
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
On 2014? 07? 29? 20:59, Andreas F?rber wrote: > Am 29.07.2014 10:05, schrieb Sjoerd Simons: >> On Tue, 2014-07-29 at 14:38 +0900, Inki Dae wrote: >>> On 2014? 07? 28? 23:45, Sjoerd Simons wrote: On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote: > On 2014? 07? 28? 17:30, Sjoerd Simons wrote: > 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. >>> >>> It seems that you want that module data of sub drivers are added by >>> depmod to /lib/modules/KERNEL_VERSION/modules.xxxmap because some >>> hot-plug system should use modules.xxxmap file to find the proper driver >>> to load. >> >> Yes. I would like the module to export its module alias information for >> the subdrivers such that depmod can add it to its databases and the >> normal module autoloading mechanisms work as intended. Note that in my >> case, "some hot-plug" system is really just udev, not something >> special.. > > +1 here. > > While I haven't tested this on my Exynos devices yet since I'm still > working on -next kernels there, here's an example of such a 3.16 config: > > http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default > > Of the platforms enabled, all drivers are configured as modules where > possible, to keep kernel size small, and dracut (or kiwi) is used to > generate an initrd that makes available the modules. > > So it would certainly be good to have the DRM auto-load somehow, without > the user having to manually touch config files. In particular when I > think of the Chromebooks, where Wifi needs configuration on first boot > and no serial console is accessible. Got it. will merge them. However, I'm not sure that Exynos drm should have hot-plug feature such as PCI base devices: all devices covered by Exynos drm framework cannot attached and detached to and from machine. Thanks, Inki Dae > > Regards, > Andreas >
[PATCH v6 10/14] drm/panel: add S6E3FA0 driver
Hi Thierry,
Sorry for late reply.
I implemented common DSI helper functions and tested in s6e3fa0 panel
(I should test with other panels).
The helper function prototypes are like below:
int mipi_dsi_set_maximum_return_packet_size(struct mipi_dsi_device *dsi,
u16 size);
int mipi_dcs_enter_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dcs_exit_sleep_mode(struct mipi_dsi_device *dsi);
int mipi_dcs_set_display_off(struct mipi_dsi_device *dsi);
int mipi_dcs_set_display_on(struct mipi_dsi_device *dsi);
int mipi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
enum mipi_dcs_tear_mode {
MIPI_DCS_TEAR_MODE_VBLANK,
MIPI_DCS_TEAR_MODE_HVBLANK,
};
int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dcs_tear_mode mode);
Last time you recommended to implement mipi_dcs_set_tear_on() unrelated
with mipi_dsi_dcs_write().
As you know, the only difference between mipi_dcs_xxx() except
mipi_dcs_set_tear_on() is data(dcs command).
So I think it's better to use mipi_dsi_dcs_write() instead.
Do you agree?
And one more thing.
From my point of view there is no initialization sequence in simple
panel driver, so this and s6e8aa0 panel couldn't use that interface.
The s6e3fa0 and s6e8aa0 are very similar so I think it is possible to
combine together like simple panel driver.
I want to ask you for advice on this.
Thank you.
Best regards YJ
On 07/22/2014 12:56 PM, YoungJun Cho wrote:
> Hi Thierry,
>
> Now I understand what you mean.
>
> I'll implement common DSI helper functions.
>
> Thank you.
> Best regards YJ
>
> On 07/21/2014 06:35 PM, Thierry Reding wrote:
>> On Fri, Jul 18, 2014 at 10:49:35AM +0900, YoungJun Cho wrote:
>>> Hi Thierry,
>>>
>>> Thank you a lot for kind comments.
>>>
>>> On 07/17/2014 07:36 PM, Thierry Reding wrote:
On Thu, Jul 17, 2014 at 06:01:25PM +0900, YoungJun Cho wrote:
>> [...]
> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> b/drivers/gpu/drm/panel/panel-s6e3fa0.c
>> [...]
> +static void s6e3fa0_set_maximum_return_packet_size(struct s6e3fa0
> *ctx,
> +unsigned int size)
> +{
> +struct mipi_dsi_device *dsi = to_mipi_dsi_device(ctx->dev);
> +const struct mipi_dsi_host_ops *ops = dsi->host->ops;
> +
> +if (ops && ops->transfer) {
> +unsigned char buf[] = {size, 0};
> +struct mipi_dsi_msg msg = {
> +.channel = dsi->channel,
> +.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE,
> +.tx_len = sizeof(buf),
> +.tx_buf = buf
> +};
> +
> +ops->transfer(dsi->host, &msg);
> +}
> +}
The Set Maximum Return Packet Size command is a standard command, so
please turn that into a generic function exposed by the DSI core.
>>>
>>> For this and below standard DCS commands, you want to use generic
>>> functions,
>>> but I have no idea for that.
>>> Could you explain more detail?
>>
>> The goal should be to make these standard DCS commands available to all
>> DSI peripherals, so the implementation should look something like this:
>>
>> static int mipi_dsi_set_maximum_return_packet_size(struct
>> mipi_dsi_device *dsi,
>>u16 size)
>> {
>> struct mipi_dsi_msg msg;
>>
>> if (!dsi->ops || !dsi->ops->transfer)
>> return -ENOSYS;
>>
>> memset(&msg, 0, sizeof(msg));
>> msg.channel = dsi->channel;
>> msg.type = MIPI_DSI_SET_MAXIMUM_RETURN_PACKET_SIZE;
>> msg.tx_len = sizeof(size);
>> msg.tx_buf = &size;
>>
>> return dsi->ops->transfer(dsi->host, &msg);
>> }
>>
>> The above is somewhat special, since it isn't DCS. For DCS I'd suggest a
>> common prefix, like so:
>>
>> enum mipi_dcs_tear_mode {
>> MIPI_DCS_TEAR_VBLANK,
>> MIPI_DCS_TEAR_BLANK,
>> };
>>
>> static int mipi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
>> enum mipi_dcs_tear_mode mode)
>> {
>> u8 data[2] = { MIPI_DSI_DCS_SET_TEAR_ON, mode };
>> struct mipi_dsi_msg msg;
>>
>> if (!dsi->ops || !dsi->ops->transfer)
>> return -ENOSYS;
>>
>> memset(&msg, 0, sizeof(msg));
>> msg.channel = dsi->channel;
>> msg.type = MIPI_DSI_DCS_SHORT_WRITE_PARAM;
>> msg.tx_len = sizeof(data);
>> msg.tx_buf = data;
>>
>> return dsi->ops->transfer(dsi->host, &msg);
>> }
>>
>> Thierry
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH 1/3] drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe
On Tue, Jul 29, 2014 at 5:54 AM, Christian K?nig
wrote:
> Am 29.07.2014 um 11:47 schrieb Michel D?nzer:
>
>> From: Michel D?nzer
>>
>> PCI GART doesn't support unsnooped access. AGP GART already uses
>> write-combined CPU mappings.
>>
>> Signed-off-by: Michel D?nzer
>
>
> For this series Reviewed-by: Christian K?nig
Applied to my 3.17 tree.
Thanks.
>
>
>> ---
>> drivers/gpu/drm/radeon/radeon_ring.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
>> b/drivers/gpu/drm/radeon/radeon_ring.c
>> index 71439f0..7cfea7e 100644
>> --- a/drivers/gpu/drm/radeon/radeon_ring.c
>> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
>> @@ -640,7 +640,9 @@ int radeon_ring_init(struct radeon_device *rdev,
>> struct radeon_ring *ring, unsig
>> /* Allocate ring buffer */
>> if (ring->ring_obj == NULL) {
>> r = radeon_bo_create(rdev, ring->ring_size, PAGE_SIZE,
>> true,
>> -RADEON_GEM_DOMAIN_GTT, 0,
>> +RADEON_GEM_DOMAIN_GTT,
>> +(rdev->flags & RADEON_IS_PCIE) ?
>> +RADEON_GEM_GTT_WC : 0,
>> NULL, &ring->ring_obj);
>> if (r) {
>> dev_err(rdev->dev, "(%d) ring create failed\n",
>> r);
>
>
> ___
> 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/29/2014 02:08 PM, Inki Dae wrote:
> On 2014? 07? 29? 20:39, Andrzej Hajda wrote:
>> On 07/29/2014 05:42 AM, Inki Dae wrote:
>>> On 2014? 07? 29? 00:50, Andrzej Hajda wrote:
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.
>>> If you can test thmorstat board, you will face with that its panel is
>>> not worked.
>> So it means this panel requires proper driving of this bit, but it does
>> not prove it is
>> LPM related.
>>
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.
>>> HSCLK only has meaning when it is used with CmdLpdt and TxLpdt bits.
>> This sounds very strange. DSI specs and D-PHY specs says clearly
>> that LPM transmissions are unrelated to HS clock [1][2]. Even timing
>> diagrams
>> in Exynos specs shows no dependency of LPM transmissions on HS clock.
>> And the
>> description of TxRequestHsClk bit says "HS clock request for HS transfer
>> at clock lane (Turn
>> on HS clock)".
> There are three System power states of D-PHY, Low-Power mode, High-Speed
> mode and Ultra-Low Power mode. High-Speed mode needs 80Mbps ~ 1Gbps per
> Lane. Therefore, to use HS mode, HS clock should be enabled. On the
> other hand, LP mode needs only 10MHz (max).
>
> So do you really think LP mode will be worked well with HS clock
> enabled? The purpose of LP mode is to reduce power consumption while
> transmitting data. Can you reduce the power consumption in LP mode with
> HS clock enabled?
As MIPI specs says "All DSI transmitters and receivers shall support
continuous clock
behavior on the Clock Lane, and optionally may support non-continuous
clock behavior"
and "For continuous clock behavior, the Clock Lane remains in high-speed
mode generating
active clock signals between HS data packet transmissions".
This means that HS clock should be on even in LP mode, unless panel
supports non-continuous clock
behavior. For signaling non-continuous clock capability there is
MIPI_DSI_CLOCK_NON_CONTINUOUS flag already.
Regards
Andrzej
>
> Thanks,
> Inki Dae
>
>> Maybe different flag should be used to describe your panel requirements
>> regarding this bit.
>>
>> It would be good to see the real initialization sequence in form of
>> pseudo-code or better in the driver.
>>
>>
>> [1]: MIPI DSI: "Note that in Low Power signaling mode, LP clock is
>> functionally embedded in the data signals. When LP
>> data transmission ends, the clock effectively stops and subsequent LP
>> clocks are not available to the
>> peripheral. The peripheral shall not require additional bits, bytes, or
>> packets from the host processor in
>> order to complete processing or pipeline movement of received data in LP
>> mode transmissions. There are a
>> variety of ways to meet this requirement. For example, the peripheral
>> may generate its own clock or it may
>> requi
[PATCH 0/3] drm/exynos: Allow module to be autoloaded
Hi Inki, On 29 July 2014 13:29, Inki Dae wrote: > On 2014? 07? 29? 20:59, Andreas F?rber wrote: > > Am 29.07.2014 10:05, schrieb Sjoerd Simons: > >> Yes. I would like the module to export its module alias information for > >> the subdrivers such that depmod can add it to its databases and the > >> normal module autoloading mechanisms work as intended. Note that in my > >> case, "some hot-plug" system is really just udev, not something > >> special.. > > > > +1 here. > > > > While I haven't tested this on my Exynos devices yet since I'm still > > working on -next kernels there, here's an example of such a 3.16 config: > > > > > http://kernel.opensuse.org/cgit/kernel-source/tree/config/armv7hl/default > > > > Of the platforms enabled, all drivers are configured as modules where > > possible, to keep kernel size small, and dracut (or kiwi) is used to > > generate an initrd that makes available the modules. > > > > So it would certainly be good to have the DRM auto-load somehow, without > > the user having to manually touch config files. In particular when I > > think of the Chromebooks, where Wifi needs configuration on first boot > > and no serial console is accessible. > > Got it. will merge them. However, I'm not sure that Exynos drm should > have hot-plug feature such as PCI base devices: all devices covered by > Exynos drm framework cannot attached and detached to and from machine. > Thanks for merging these. Just wanted to reiterate that it is not about hotplug at all: it is about delayed/conditional loading. There is no expectation that these will be used in a hotplug manner, it is just about being able to load them in the initrd without having to have explicit cases for every single driver and device in userspace (which would make it much harder to change the driver later). Cheers, Daniel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140729/62cb9b7d/attachment.html>
[PATCH] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
Return 2 so we can be sure the kernel has the necessary
changes for acceleration to work.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 35d9318..dcec4ff 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev, void
*data, struct drm_file
}
break;
case RADEON_INFO_ACCEL_WORKING2:
- *value = rdev->accel_working;
+ if (rdev->family == CHIP_HAWAII) {
+ if (rdev->accel_working && rdev->new_fw)
+ *value = 2;
+ else
+ *value = 0;
+ } else {
+ *value = rdev->accel_working;
+ }
break;
case RADEON_INFO_TILING_CONFIG:
if (rdev->family >= CHIP_BONAIRE)
--
1.8.3.1
[Bug 65963] screen goes blank, Linux hangs - Radeon 7870, Gallium, Glamor
https://bugs.freedesktop.org/show_bug.cgi?id=65963 --- Comment #14 from Maciej --- @Damian Nowak Before I've seen your answer I did full, fresh system reinstallation (cause hangs started happening after few minutes). Ubuntu was running fine for few hours, so I added Oibaf PPA and kernel 3.16-RC7 - so far no hang. I'll report if it happens again and add some logs. -- 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/20140729/66a59f11/attachment.html>
[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded
https://bugzilla.kernel.org/show_bug.cgi?id=81021 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|cpufreq |Video(DRI - non Intel) Assignee|cpufreq at vger.kernel.org |drivers_video-dri at kernel-bu ||gs.osdl.org Product|Power Management|Drivers -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded
https://bugzilla.kernel.org/show_bug.cgi?id=81021 --- Comment #1 from Alan --- (moving in the direction of those who would know, and whose code would need to do the GPU setup if there is any) -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote:
> Return 2 so we can be sure the kernel has the necessary
> changes for acceleration to work.
I highly dislike that ? Why about just using nop2 in userspace ?
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_kms.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 35d9318..dcec4ff 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev,
> void *data, struct drm_file
> }
> break;
> case RADEON_INFO_ACCEL_WORKING2:
> - *value = rdev->accel_working;
> + if (rdev->family == CHIP_HAWAII) {
> + if (rdev->accel_working && rdev->new_fw)
> + *value = 2;
> + else
> + *value = 0;
> + } else {
> + *value = rdev->accel_working;
> + }
> break;
> case RADEON_INFO_TILING_CONFIG:
> if (rdev->family >= CHIP_BONAIRE)
> --
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 80331] Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(AGP) |Video(DRI - non Intel) Assignee|airlied at linux.ie|drivers_video-dri at kernel-bu ||gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 Alan changed: What|Removed |Added Summary|Radeon driver broken in |[BISECTED]Radeon driver |kernel 3.12.15 onwards for |broken in kernel 3.12.15 |ATI Radeon HD4770 Card |onwards for ATI Radeon ||HD4770 Card -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80341] Radeon firmware fails to load
https://bugzilla.kernel.org/show_bug.cgi?id=80341 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk Component|Video(AGP) |Video(DRI - non Intel) Assignee|airlied at linux.ie|drivers_video-dri at kernel-bu ||gs.osdl.org -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 81021] AMD CPUs w/ Integrated Graphics (APUs) And Turbo Core Only Boost If "fglrx" Module Is Loaded
https://bugzilla.kernel.org/show_bug.cgi?id=81021 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- You can enable it by setting pi->enable_bapm = true; in trinity_dpm_init() in trinity_dpm.c. Unforunately, it's not stable yet on all systems. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- You need to have the firmware installed to use the driver. We don't support the driver without firmware loaded. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80341] Radeon firmware fails to load
https://bugzilla.kernel.org/show_bug.cgi?id=80341 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- You need to have the firmware loaded to use the driver. We don't support the driver without firmware. Make sure you have the firmware installed and that your initrd is updated to contain the firmwware if your are using one. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #3 from Colin --- (In reply to Alex Deucher from comment #2) > You need to have the firmware installed to use the driver. We don't support > the driver without firmware loaded. Sorry, I didn't explain very well. The firmware is installed; it just doesn't load when the patch I attached is applied and the driver is statically linked. If the patch is undone with no other changes the firmware seems to load and the card works. Equally if I leave the patch in but make the driver a module instead of being statically linked then it also works. The reason I suggested the firmware is failing to load with the patch present is that I inserted printk statements at various places and found that the function to load the firmware returns an error even though when it is using the correct path to the firmware file. Best wishes. Colin -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 0/8] Upstreaming the Android build and misc fixes
> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Monday, July 28, 2014 4:22 PM > To: Emil Velikov > Cc: Daniel Vetter; Gore, Tim; dri-devel at lists.freedesktop.org > Subject: Re: [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 On the whole these look fine. Jon Bloomfield seemed happy with the overall idea. 3 comments. 1) Patch 3 didn't apply cleanly, I assume because it was based on a different branch (ie not master), but the difference was trivial. 2) The Android makefiles as they are will not build within the android tree. I am Trying to get them to work at the moment. 3) Depending on which Android tree you have, the resulting libdrm may or may not Work in there. I don't think the latest intel android tree is compatible with the Upstream libdrm. Tim > > > > > > -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 0/8] Upstreaming the Android build and misc fixes
Hi Emil, these seemed to work ok, with two fixes. 1) Patch 3 didn't apply cleanly to the master branch due to a difference in the Author email address for a couple of files. 2) The Android.mk at the top level, at the end where you include the sub makefiles, You need to use LIBDRM_TOP instead of LOCAL_PATH. (Patches 4,6,7,8) So include $(LOCAL_PATH)/. Becomes include $(LIBDRM_TOP)/ this is because the included Android.mk files modify LOCAL_PATH TIm
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #4 from Alex Deucher --- If the driver is built into the kernel, you need to built the firmware into the kernel as well. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #5 from Colin --- (In reply to Alex Deucher from comment #4) > If the driver is built into the kernel, you need to built the firmware into > the kernel as well. I am just using the standard build system e.g. make bzImage. As I said if I remove the patch I mentioned in the original post everything works fine. If the patch is applied it doesn't work. I don't know if that has anything to do with building the firmware. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #117 from Kai --- (In reply to comment #116) > (In reply to comment #115) > > I found > > <http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3. > > 16&id=f53f81b2576a9bd3af947e2b1c3a46dfab51c5ef>. Is that the correct commit > > for Hawaii? > > Yes, but you probably want all page-flipping related fixes. Ok. I tried to pick all those page-flipping patches from Mario Kleiner over, but I could only get 60c90d98ba00f7f8e8ec55f6b24096372f57e9a4 and 5900fdc42ca3cbbc50bab7133750459a165a5cca to apply. The other two failed and the code looked quite different, so I left them out. If I need either 826484977c29b42c8cb8c42bd41acaa6e152a4bb or 5f87e090a7368adc2290ae17ffd82a070caadd20), then any help in adapting them, would be appreciated very much. > > Doesn't look like the appropriate commit to me (so much "Evergreen" > > everywhere), > > The programming of that hardware block hasn't changed since Evergreen. Ok, was just irritated by all the changes happening in evergreen.c and similar "non-CIK" named files. But I didn't check the entire include chain. ;-) Thanks for clearing this up. With regard to <http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-3.17-wip&id=505178d8b01dd65567b3445d5aa13e81c3a479c0>: does that mean, that I would need a new version of <http://people.freedesktop.org/~agd5f/0001-radeon-enable-hawaii-accel-conditionally.patch>? -- 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/20140729/4691b657/attachment.html>
[PATCH] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse wrote:
> On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote:
>> Return 2 so we can be sure the kernel has the necessary
>> changes for acceleration to work.
>
> I highly dislike that ? Why about just using nop2 in userspace ?
How to we tell whether the version of mesa has that change or not?
Also, packet2 nops are deprecated so may not work in future firmwares
if we end up updating them again.
Alex
>
>>
>> Signed-off-by: Alex Deucher
>> ---
>> drivers/gpu/drm/radeon/radeon_kms.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index 35d9318..dcec4ff 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev,
>> void *data, struct drm_file
>> }
>> break;
>> case RADEON_INFO_ACCEL_WORKING2:
>> - *value = rdev->accel_working;
>> + if (rdev->family == CHIP_HAWAII) {
>> + if (rdev->accel_working && rdev->new_fw)
>> + *value = 2;
>> + else
>> + *value = 0;
>> + } else {
>> + *value = rdev->accel_working;
>> + }
>> break;
>> case RADEON_INFO_TILING_CONFIG:
>> if (rdev->family >= CHIP_BONAIRE)
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote:
> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse wrote:
> > On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote:
> >> Return 2 so we can be sure the kernel has the necessary
> >> changes for acceleration to work.
> >
> > I highly dislike that ? Why about just using nop2 in userspace ?
>
> How to we tell whether the version of mesa has that change or not?
You do not need to know that in kernel, all that is needed is for userspace
to test 3.16 kernel as it's all that is needed to get accel working. So i
would say enable accel on ddx now because truly if someone update its ddx
then it must have updated mesa too.
> Also, packet2 nops are deprecated so may not work in future firmwares
> if we end up updating them again.
I do not want to go into discussion on closed source firmware, if they offer
no API stability i would consider that utterly broken.
>
> Alex
>
> >
> >>
> >> Signed-off-by: Alex Deucher
> >> ---
> >> drivers/gpu/drm/radeon/radeon_kms.c | 9 -
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> >> b/drivers/gpu/drm/radeon/radeon_kms.c
> >> index 35d9318..dcec4ff 100644
> >> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> >> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> >> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev,
> >> void *data, struct drm_file
> >> }
> >> break;
> >> case RADEON_INFO_ACCEL_WORKING2:
> >> - *value = rdev->accel_working;
> >> + if (rdev->family == CHIP_HAWAII) {
> >> + if (rdev->accel_working && rdev->new_fw)
> >> + *value = 2;
> >> + else
> >> + *value = 0;
> >> + } else {
> >> + *value = rdev->accel_working;
> >> + }
> >> break;
> >> case RADEON_INFO_TILING_CONFIG:
> >> if (rdev->family >= CHIP_BONAIRE)
> >> --
> >> 1.8.3.1
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #118 from Alex Deucher --- I'll post a link to a new git tree with the radeon 3.17 changes rebased on drm-fixes. -- 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/20140729/9433235e/attachment.html>
[PATCH 0/8] Upstreaming the Android build and misc fixes
On 29/07/14 17:14, Gore, Tim wrote: > > >> -Original Message- >> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel >> Vetter >> Sent: Monday, July 28, 2014 4:22 PM >> To: Emil Velikov >> Cc: Daniel Vetter; Gore, Tim; dri-devel at lists.freedesktop.org >> Subject: Re: [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 > > On the whole these look fine. Jon Bloomfield seemed happy with the overall > idea. > 3 comments. >1) Patch 3 didn't apply cleanly, I assume because it > was based on a different branch (ie not master), but the difference > was trivial. > 2) The Android makefiles as they are will not build within the android > tree. I am >Trying to get them to work at the moment. The Android issue you've mentioned in the other email is fixed in the branch mentioned above + I have squashed additional fixes over at fixes+android-v2 in https://github.com/evelikov/libdrm. Will post these in just a moment. > 3) Depending on which Android tree you have, the resulting libdrm may or > may not >Work in there. I don't think the latest intel android tree is > compatible with the > Upstream libdrm. > Not sure what is the exact meaning of "compatible" is in this case. IMHO Intel (if interested) can easily rebase their repo on top of upstream (as these land) thus keep a smaller (if any) delta and ease development :) -Emil P.S. Who is Jon Bloomfield ? >Tim > >>> >>> >>> -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
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #6 from Alex Deucher --- (In reply to Colin from comment #5) > (In reply to Alex Deucher from comment #4) > > If the driver is built into the kernel, you need to built the firmware into > > the kernel as well. > > I am just using the standard build system e.g. make bzImage. As I said if I > remove the patch I mentioned in the original post everything works fine. If > the patch is applied it doesn't work. I don't know if that has anything to > do with building the firmware. The firmware still fails to load, it just fails later and the driver does not fail to load because of it. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #7 from Colin --- (In reply to Alex Deucher from comment #6) > (In reply to Colin from comment #5) > > (In reply to Alex Deucher from comment #4) > > > If the driver is built into the kernel, you need to built the firmware > > > into > > > the kernel as well. > > > > I am just using the standard build system e.g. make bzImage. As I said if I > > remove the patch I mentioned in the original post everything works fine. If > > the patch is applied it doesn't work. I don't know if that has anything to > > do with building the firmware. > > The firmware still fails to load, it just fails later and the driver does > not fail to load because of it. Oh. I hadn't realised. Anyway, with the patch removed the card supports XV in X windows and with the patch installed it doesn't. If the firmware always fails to load what does it do? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
Am 29.07.2014 um 19:10 schrieb Jerome Glisse:
> On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote:
>> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse
>> wrote:
>>> On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote:
Return 2 so we can be sure the kernel has the necessary
changes for acceleration to work.
>>> I highly dislike that ? Why about just using nop2 in userspace ?
>> How to we tell whether the version of mesa has that change or not?
> You do not need to know that in kernel, all that is needed is for userspace
> to test 3.16 kernel as it's all that is needed to get accel working. So i
> would say enable accel on ddx now because truly if someone update its ddx
> then it must have updated mesa too.
>
>> Also, packet2 nops are deprecated so may not work in future firmwares
>> if we end up updating them again.
> I do not want to go into discussion on closed source firmware, if they offer
> no API stability i would consider that utterly broken.e
And that's exactly what the firmware guys actually do here, they tell us
that nop2 packets are not part of the API any more. The API between
different hardware generations was never stable in the first place.
Christian.
>
>> Alex
>>
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_kms.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 35d9318..dcec4ff 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev,
void *data, struct drm_file
}
break;
case RADEON_INFO_ACCEL_WORKING2:
- *value = rdev->accel_working;
+ if (rdev->family == CHIP_HAWAII) {
+ if (rdev->accel_working && rdev->new_fw)
+ *value = 2;
+ else
+ *value = 0;
+ } else {
+ *value = rdev->accel_working;
+ }
break;
case RADEON_INFO_TILING_CONFIG:
if (rdev->family >= CHIP_BONAIRE)
--
1.8.3.1
___
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
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #8 from Alex Deucher --- (In reply to Colin from comment #7) > > Oh. I hadn't realised. Anyway, with the patch removed the card supports XV > in X windows and with the patch installed it doesn't. If the firmware always > fails to load what does it do? The firmware doesn't always fail to load; it loads fine. Something is wrong with yourt setup. Attach your xorg log and dmesg output for both cases. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCHv2 0/8] Upstreaming the Android build and misc fixes
Changes since the orignal posting:
- Rebased on top of master.
- Used _H_FILES for header lists (_HEADERS is a no-go with autotools)
- Install the freedreno headers to {include_dir}/freedreno, similar to
the automake builds.
- Correctly include $(hw)/Android.mk
The series is also available at the fixes+android-v2 branch in
https://github.com/evelikov/libdrm.
-Emil
[PATCH 1/8] all: include config.h only when available and use its defines
... rather than explicitly redefining HAVE_STDINT_H and _GNU_SOURCE. Signed-off-by: Emil Velikov --- intel/test_decode.c | 5 +++-- libkms/api.c | 2 ++ libkms/dumb.c | 4 +++- libkms/exynos.c | 4 +++- libkms/intel.c| 4 +++- libkms/linux.c| 2 ++ libkms/nouveau.c | 4 +++- libkms/radeon.c | 4 +++- libkms/vmwgfx.c | 4 +++- tests/drmstat.c | 2 ++ tests/modetest/buffers.c | 2 ++ tests/modetest/cursor.c | 2 ++ tests/modetest/modetest.c | 2 ++ tests/vbltest/vbltest.c | 2 ++ 14 files changed, 35 insertions(+), 8 deletions(-) diff --git a/intel/test_decode.c b/intel/test_decode.c index b710f34..bef9d99 100644 --- a/intel/test_decode.c +++ b/intel/test_decode.c @@ -21,7 +21,9 @@ * IN THE SOFTWARE. */ -#define _GNU_SOURCE +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #include #include @@ -33,7 +35,6 @@ #include #include -#include "config.h" #include "intel_bufmgr.h" #include "intel_chipset.h" diff --git a/libkms/api.c b/libkms/api.c index 5befaa0..b512c42 100644 --- a/libkms/api.c +++ b/libkms/api.c @@ -26,7 +26,9 @@ **/ +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #include #include #include diff --git a/libkms/dumb.c b/libkms/dumb.c index 440efb3..794282f 100644 --- a/libkms/dumb.c +++ b/libkms/dumb.c @@ -26,7 +26,9 @@ **/ -#define HAVE_STDINT_H +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #define _FILE_OFFSET_BITS 64 #include diff --git a/libkms/exynos.c b/libkms/exynos.c index 93e36a1..243915b 100644 --- a/libkms/exynos.c +++ b/libkms/exynos.c @@ -11,7 +11,9 @@ * option) any later version. */ -#define HAVE_STDINT_H +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #define _FILE_OFFSET_BITS 64 #include diff --git a/libkms/intel.c b/libkms/intel.c index abae452..92f1cf2 100644 --- a/libkms/intel.c +++ b/libkms/intel.c @@ -26,7 +26,9 @@ **/ -#define HAVE_STDINT_H +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #define _FILE_OFFSET_BITS 64 #include diff --git a/libkms/linux.c b/libkms/linux.c index 9b4f29e..17e1d58 100644 --- a/libkms/linux.c +++ b/libkms/linux.c @@ -30,7 +30,9 @@ */ +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #include #include #include diff --git a/libkms/nouveau.c b/libkms/nouveau.c index 608092f..2de827d 100644 --- a/libkms/nouveau.c +++ b/libkms/nouveau.c @@ -26,7 +26,9 @@ **/ -#define HAVE_STDINT_H +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #define _FILE_OFFSET_BITS 64 #include diff --git a/libkms/radeon.c b/libkms/radeon.c index f5e382a..29375c4 100644 --- a/libkms/radeon.c +++ b/libkms/radeon.c @@ -26,7 +26,9 @@ **/ -#define HAVE_STDINT_H +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #define _FILE_OFFSET_BITS 64 #include diff --git a/libkms/vmwgfx.c b/libkms/vmwgfx.c index d594b3b..598f383 100644 --- a/libkms/vmwgfx.c +++ b/libkms/vmwgfx.c @@ -26,7 +26,9 @@ **/ -#define HAVE_STDINT_H +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif #define _FILE_OFFSET_BITS 64 #include diff --git a/tests/drmstat.c b/tests/drmstat.c index c51cbc6..5935d07 100644 --- a/tests/drmstat.c +++ b/tests/drmstat.c @@ -28,7 +28,9 @@ * */ +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #include #include diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c index 8206ce3..29b520d 100644 --- a/tests/modetest/buffers.c +++ b/tests/modetest/buffers.c @@ -24,7 +24,9 @@ * IN THE SOFTWARE. */ +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #include #include diff --git a/tests/modetest/cursor.c b/tests/modetest/cursor.c index 7077f20..60f240a 100644 --- a/tests/modetest/cursor.c +++ b/tests/modetest/cursor.c @@ -22,7 +22,9 @@ * IN THE SOFTWARE. */ +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #include #include diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index 7d436b5..92efb82 100644 --- a/tests/modetest/modetest.c +++ b/tests/modetest/modetest.c @@ -37,7 +37,9 @@ * TODO: use cairo to write the mode info on the selected output once * the mode has been programmed, along with possible test patterns. */ +#ifdef HAVE_CONFIG_H #include "config.h" +#endif #include #include diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c index 2a09d28..50e29dc 100644 --- a/tests/vbltest/vbltest.c +++ b/tests/vbltest/vbltest.c @@ -37,7 +37,9 @@ * TODO: use cairo to write the mode info on the selected output once * the mode has been programmed, along with possible tes
[PATCH 4/8] libdrm,intel: Add Android build
Contains the following patches squashed in: commit f340a8b9f2b84d5762553bef046914e0bde20795 Author: Chad Versace Date: Wed, 21 Dec 2011 11:43:57 -0800 libdrm,intel: Add Android makefiles (v2) This enables libdrm.so and libdrm_intel.so to build on Android IceCreamSandwich. v2: Link libdrm_intel to libpciaccess. Change-Id: Ie5ed4bc0e6b4f9f819e3ec44488e385c35e97128 Signed-off-by: Chad Versace commit 8fb3f42389dea34218ed1fe59550ec2abb4d6953 Author: Andrew Boie Date: Wed, 26 Sep 2012 13:32:05 -0700 libdrm, libdrm_intel: Skip driver name checks These libraries have 'optional' tags, which means they won't get built unless something else depends on them or they are added to PRODUCT_PACKAGES. There's no need for additional filtering. Change-Id: I5d90969f38671f8144c0dc27d47144b3f09a15ce Signed-off-by: Andrew Boie --- Android.mk | 45 + intel/Android.mk | 50 ++ 2 files changed, 95 insertions(+) create mode 100644 Android.mk create mode 100644 intel/Android.mk diff --git a/Android.mk b/Android.mk new file mode 100644 index 000..afe59ce --- /dev/null +++ b/Android.mk @@ -0,0 +1,45 @@ +# +# Copyright ? 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. +# + +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +LIBDRM_TOP := $(LOCAL_PATH) + +# Import variables LIBDRM_FILES, LIBDRM_HEADERS +include $(LOCAL_PATH)/Makefile.sources + +LOCAL_MODULE := libdrm +LOCAL_MODULE_TAGS := optional + +LOCAL_SRC_FILES := $(LIBDRM_FILES) + +LOCAL_C_INCLUDES := \ + $(LIBDRM_TOP)/include/drm + +LOCAL_CFLAGS := \ + -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 + +include $(BUILD_SHARED_LIBRARY) + +include $(LOCAL_PATH)/intel/Android.mk diff --git a/intel/Android.mk b/intel/Android.mk new file mode 100644 index 000..5c48a95 --- /dev/null +++ b/intel/Android.mk @@ -0,0 +1,50 @@ +# +# Copyright ? 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the "Software"), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +# IN THE SOFTWARE. +# + +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +# Import variables LIBDRM_INTEL_FILES, LIBDRM_INTEL_HEADERS +include $(LOCAL_PATH)/Makefile.sources + +LOCAL_MODULE := libdrm_intel +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libdrm + +LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES) + +LOCAL_C_INCLUDES := \ + $(LIBDRM_TOP) \ + $(LIBDRM_TOP)/intel \ + $(LIBDRM_TOP)/include/drm \ + external/libpciaccess/include + +LOCAL_CFLAGS := \ + -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 + +LOCAL_SHARED_LIBRARIES := \ + libdrm \ + libpciaccess + +include $(BUILD_SHARED_LIBRARY) -- 2.0.2
[PATCH 3/8] libdrm, freedreno, intel, nouveau, radeon: add Makefile.sources
Will be used to consolidate the required sources lists as well as the
install-able headers. This is turn will help us to avoid the
duplication with the upcoming Android build support.
v2 Rename the headers variable to *_H_FILES.
Signed-off-by: Emil Velikov
---
Makefile.am | 13 -
Makefile.sources | 12
freedreno/Makefile.am| 24 +++-
freedreno/Makefile.sources | 24
include/drm/Makefile.am | 20
include/drm/Makefile.sources | 18 ++
intel/Makefile.am| 16
intel/Makefile.sources | 14 ++
nouveau/Makefile.am | 11 ---
nouveau/Makefile.sources | 9 +
radeon/Makefile.am | 22 --
radeon/Makefile.sources | 19 +++
12 files changed, 119 insertions(+), 83 deletions(-)
create mode 100644 Makefile.sources
create mode 100644 freedreno/Makefile.sources
create mode 100644 include/drm/Makefile.sources
create mode 100644 intel/Makefile.sources
create mode 100644 nouveau/Makefile.sources
create mode 100644 radeon/Makefile.sources
diff --git a/Makefile.am b/Makefile.am
index 826c30d..fab2a9a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,6 +18,8 @@
# IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
# CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+include Makefile.sources
+
ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
pkgconfigdir = @pkgconfigdir@
@@ -62,17 +64,10 @@ libdrm_la_CPPFLAGS = -I$(top_srcdir)/include/drm
AM_CFLAGS = \
$(VALGRIND_CFLAGS)
-libdrm_la_SOURCES =\
- xf86drm.c \
- xf86drmHash.c \
- xf86drmRandom.c \
- xf86drmSL.c \
- xf86drmMode.c \
- xf86atomic.h\
- libdrm_lists.h
+libdrm_la_SOURCES = $(LIBDRM_FILES)
libdrmincludedir = ${includedir}
-libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
+libdrminclude_HEADERS = $(LIBDRM_H_FILES)
EXTRA_DIST = libdrm.pc.in include/drm/*
diff --git a/Makefile.sources b/Makefile.sources
new file mode 100644
index 000..15e38b5
--- /dev/null
+++ b/Makefile.sources
@@ -0,0 +1,12 @@
+LIBDRM_FILES := \
+ xf86drm.c \
+ xf86drmHash.c \
+ xf86drmRandom.c \
+ xf86drmSL.c \
+ xf86drmMode.c \
+ xf86atomic.h \
+ libdrm_lists.h
+
+LIBDRM_H_FILES := \
+ xf86drm.h \
+ xf86drmMode.h
diff --git a/freedreno/Makefile.am b/freedreno/Makefile.am
index 7903e5b..3a6f7f5 100644
--- a/freedreno/Makefile.am
+++ b/freedreno/Makefile.am
@@ -1,4 +1,5 @@
AUTOMAKE_OPTIONS=subdir-objects
+include Makefile.sources
AM_CFLAGS = \
$(WARN_CFLAGS) \
@@ -12,29 +13,10 @@ libdrm_freedreno_ladir = $(libdir)
libdrm_freedreno_la_LDFLAGS = -version-number 1:0:0 -no-undefined
libdrm_freedreno_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-libdrm_freedreno_la_SOURCES = \
- freedreno_device.c \
- freedreno_pipe.c \
- freedreno_priv.h \
- freedreno_ringbuffer.c \
- freedreno_bo.c \
- kgsl/kgsl_bo.c \
- kgsl/kgsl_device.c \
- kgsl/kgsl_drm.h \
- kgsl/kgsl_pipe.c \
- kgsl/kgsl_priv.h \
- kgsl/kgsl_ringbuffer.c \
- kgsl/msm_kgsl.h \
- msm/msm_bo.c \
- msm/msm_device.c \
- msm/msm_drm.h \
- msm/msm_pipe.c \
- msm/msm_priv.h \
- msm/msm_ringbuffer.c \
- list.h
+libdrm_freedreno_la_SOURCES = $(LIBDRM_FREEDRENO_FILES)
libdrm_freedrenocommonincludedir = ${includedir}/freedreno
-libdrm_freedrenocommoninclude_HEADERS = freedreno_drmif.h
freedreno_ringbuffer.h
+libdrm_freedrenocommoninclude_HEADERS = $(LIBDRM_FREEDRENO_H_FILES)
pkgconfigdir = @pkgconfigdir@
pkgconfig_DATA = libdrm_freedreno.pc
diff --git a/freedreno/Makefile.sources b/freedreno/Makefile.sources
new file mode 100644
index 000..91020df
--- /dev/null
+++ b/freedreno/Makefile.sources
@@ -0,0 +1,24 @@
+LIBDRM_FREEDRENO_FILES := \
+ freedreno_device.c \
+ freedreno_pipe.c \
+ freedreno_priv.h \
+ freedreno_ringbuffer.c \
+ freedreno_bo.c \
+ kgsl/kgsl_bo.c \
+ kgsl/kgsl_device.c \
+ kgsl/kgsl_drm.h \
+ kgsl/kgsl_pipe.c \
+ kgsl/kgsl_priv.h \
+ kgsl/kgsl_ringbuffer.c \
+ kgsl/msm_kgsl.h \
+ msm/msm_bo.c \
+ msm/msm_device.c \
+ msm/msm_drm.h \
+ msm/msm_pipe.c \
+ msm/msm_priv.h \
+ msm/msm_ringbuffer.c \
+ list.h
+
+LIBDRM_FREEDRENO_H_FILES := \
+ freedreno_drmif.h \
+ freedreno_ringbuffer.h
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 2bc34d2..7a246ae 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -22,23 +22,11 @@
# however, r300
[PATCH 2/8] libkms: remove explicit define _FILE_OFFSET_BITS 64
configure.ac has AC_SYS_LARGEFILE which provides the define and/or approapriate magic when required. Signed-off-by: Emil Velikov --- libkms/dumb.c| 1 - libkms/exynos.c | 1 - libkms/intel.c | 1 - libkms/nouveau.c | 1 - libkms/radeon.c | 1 - libkms/vmwgfx.c | 1 - 6 files changed, 6 deletions(-) diff --git a/libkms/dumb.c b/libkms/dumb.c index 794282f..5702543 100644 --- a/libkms/dumb.c +++ b/libkms/dumb.c @@ -29,7 +29,6 @@ #ifdef HAVE_CONFIG_H #include "config.h" #endif -#define _FILE_OFFSET_BITS 64 #include #include diff --git a/libkms/exynos.c b/libkms/exynos.c index 243915b..92e329c 100644 --- a/libkms/exynos.c +++ b/libkms/exynos.c @@ -14,7 +14,6 @@ #ifdef HAVE_CONFIG_H #include "config.h" #endif -#define _FILE_OFFSET_BITS 64 #include #include diff --git a/libkms/intel.c b/libkms/intel.c index 92f1cf2..b006ea4 100644 --- a/libkms/intel.c +++ b/libkms/intel.c @@ -29,7 +29,6 @@ #ifdef HAVE_CONFIG_H #include "config.h" #endif -#define _FILE_OFFSET_BITS 64 #include #include diff --git a/libkms/nouveau.c b/libkms/nouveau.c index 2de827d..15c012e 100644 --- a/libkms/nouveau.c +++ b/libkms/nouveau.c @@ -29,7 +29,6 @@ #ifdef HAVE_CONFIG_H #include "config.h" #endif -#define _FILE_OFFSET_BITS 64 #include #include diff --git a/libkms/radeon.c b/libkms/radeon.c index 29375c4..938321b 100644 --- a/libkms/radeon.c +++ b/libkms/radeon.c @@ -29,7 +29,6 @@ #ifdef HAVE_CONFIG_H #include "config.h" #endif -#define _FILE_OFFSET_BITS 64 #include #include diff --git a/libkms/vmwgfx.c b/libkms/vmwgfx.c index 598f383..08163a1 100644 --- a/libkms/vmwgfx.c +++ b/libkms/vmwgfx.c @@ -29,7 +29,6 @@ #ifdef HAVE_CONFIG_H #include "config.h" #endif -#define _FILE_OFFSET_BITS 64 #include #include -- 2.0.2
[PATCH 8/8] freedreno: add Android build support
v2 Rename the headers variable(s) to *_H_FILES. Signed-off-by: Emil Velikov --- Android.mk | 1 + freedreno/Android.mk | 30 ++ 2 files changed, 31 insertions(+) create mode 100644 freedreno/Android.mk diff --git a/Android.mk b/Android.mk index d040d4f..bb49b0b 100644 --- a/Android.mk +++ b/Android.mk @@ -54,6 +54,7 @@ LOCAL_COPY_HEADERS_TO := libdrm include $(BUILD_SHARED_LIBRARY) SUBDIRS := \ + freedreno \ intel \ nouveau \ radeon diff --git a/freedreno/Android.mk b/freedreno/Android.mk new file mode 100644 index 000..243a1e2 --- /dev/null +++ b/freedreno/Android.mk @@ -0,0 +1,30 @@ +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +# Import variables LIBDRM_FREEDRENO_FILES, LIBDRM_FREEDRENO_H_FILES +include $(LOCAL_PATH)/Makefile.sources + +LOCAL_MODULE := libdrm_freedreno +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libdrm + +LOCAL_SRC_FILES := $(LIBDRM_FREEDRENO_FILES) +LOCAL_EXPORT_C_INCLUDE_DIRS += \ + $(LOCAL_PATH)/freedreno + +LOCAL_C_INCLUDES := \ + $(LIBDRM_TOP) \ + $(LIBDRM_TOP)/freedreno \ + $(LIBDRM_TOP)/include/drm + +LOCAL_CFLAGS := \ + -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 + +LOCAL_COPY_HEADERS := $(LIBDRM_FREEDRENO_H_FILES) +LOCAL_COPY_HEADERS_TO := freedreno + +LOCAL_SHARED_LIBRARIES := \ + libdrm + +include $(BUILD_SHARED_LIBRARY) -- 2.0.2
[PATCH 6/8] radeon: add Android build support
v2 Rename the headers variable(s) to *_H_FILES. Signed-off-by: Emil Velikov --- Android.mk| 7 ++- radeon/Android.mk | 30 ++ 2 files changed, 36 insertions(+), 1 deletion(-) create mode 100644 radeon/Android.mk diff --git a/Android.mk b/Android.mk index 795e554..3f43625 100644 --- a/Android.mk +++ b/Android.mk @@ -53,4 +53,9 @@ LOCAL_COPY_HEADERS := \ LOCAL_COPY_HEADERS_TO := libdrm include $(BUILD_SHARED_LIBRARY) -include $(LOCAL_PATH)/intel/Android.mk +SUBDIRS := \ + intel \ + radeon + +mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS)) +include $(mkfiles) diff --git a/radeon/Android.mk b/radeon/Android.mk new file mode 100644 index 000..9cba546 --- /dev/null +++ b/radeon/Android.mk @@ -0,0 +1,30 @@ +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +# Import variables LIBDRM_RADEON_FILES, LIBDRM_RADEON_H_FILES +include $(LOCAL_PATH)/Makefile.sources + +LOCAL_MODULE := libdrm_radeon +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libdrm + +LOCAL_SRC_FILES := $(LIBDRM_RADEON_FILES) +LOCAL_EXPORT_C_INCLUDE_DIRS += \ + $(LOCAL_PATH)/radeon + +LOCAL_C_INCLUDES := \ + $(LIBDRM_TOP) \ + $(LIBDRM_TOP)/radeon \ + $(LIBDRM_TOP)/include/drm + +LOCAL_CFLAGS := \ + -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 + +LOCAL_COPY_HEADERS := $(LIBDRM_RADEON_H_FILES) +LOCAL_COPY_HEADERS_TO := libdrm + +LOCAL_SHARED_LIBRARIES := \ + libdrm + +include $(BUILD_SHARED_LIBRARY) -- 2.0.2
[PATCH 5/8] libdrm,intel: rework android header handling
Contains the following patches squashed in: commit 99247a5bd724ddcf0f06a5518baad207c53f1e2b Author: Haitao Huang Date: Fri, 27 Apr 2012 13:20:53 -0500 Android.mk: use LOCAL_COPY_HEADERS to export headers. Export necessary header files used by other components for Android, such as libva intel-driver, gralloc, hwcomposer, etc. Change-Id: I2feabf6941379ef4d756e942f30eba059de641f1 Signed-off-by: Haitao Huang [chad: Fixed inconsistent indentation.] Signed-off-by: Chad Versace commit 7d0b528cb69995d7ea4e29b2daa1e3b28a362f42 Author: Emil Velikov Date: Sun, 27 Jul 2014 18:22:41 +0100 android: reuse headers lists, separate libdrm from intel headers Rather than having a duplicate copy of the headers list(s), reuse the existing one(s). Distinguish that the intel headers should be copied when libdrm_intel is used. v2 Rename the headers variable(s) to *_H_FILES. Signed-off-by: Emil Velikov commit 361de3ba4cadd5357596d1537bb3f216d281532b Author: Piotr Luc Date: Fri, 14 Jun 2013 13:00:39 +0200 Export include dir from libdrm BZ: 116218 Google introduced new method of specifying include path(s) between modules. This allows a module to include header from a library without directly specifyining by includer the path where headers are located. The method requires from library that holds headers to export include path(s) in LOCAL_EXPORT_C_INCLUDE_DIRS variable. These exported include path(s) are automatically added to include path(s) of modules that have name of the library in the LOCAL_SHARED_LIBRARIES or LOCAL_STATIC_LIBRARIES list. This change sets LOCAL_EXPORT_C_INCLUDE_DIRS to folders that contain headers file that used by other modules in order to export these paths. Change-Id: Id1ac885b31ef2efe194e0289fbcaecd9eb533df0 Signed-off-by: Piotr Luc Reviewed-on: http://android.intel.com:8080/113562 Reviewed-by: cactus Reviewed-by: Luc, Piotr Reviewed-by: Purushothaman, Vijay A Reviewed-by: Stimson, Dale B Tested-by: Stimson, Dale B Reviewed-by: buildbot Tested-by: buildbot commit 2bf22fcbd4cbb9e7c7764d5eff0bb4e75ab1a005 Author: Emil Velikov Date: 27 Jul 2014 18:27:21 +0100 android: Separate libdrm and intel LOCAL_EXPORT_C_INCLUDE_DIRS Signed-off-by: Emil Velikov --- Android.mk | 15 +-- intel/Android.mk | 7 ++- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/Android.mk b/Android.mk index afe59ce..795e554 100644 --- a/Android.mk +++ b/Android.mk @@ -1,5 +1,5 @@ # -# Copyright ? 2011 Intel Corporation +# Copyright ? 2011-2012 Intel Corporation # # Permission is hereby granted, free of charge, to any person obtaining a # copy of this software and associated documentation files (the "Software"), @@ -26,13 +26,18 @@ include $(CLEAR_VARS) LIBDRM_TOP := $(LOCAL_PATH) -# Import variables LIBDRM_FILES, LIBDRM_HEADERS +# Import variables LIBDRM_FILES, LIBDRM_H_FILES include $(LOCAL_PATH)/Makefile.sources +# Import variables LIBDRM_INCLUDE_H_FILES, LIBDRM_INCLUDE_VMWGFX_H_FILES +include $(LOCAL_PATH)/include/drm/Makefile.sources LOCAL_MODULE := libdrm LOCAL_MODULE_TAGS := optional LOCAL_SRC_FILES := $(LIBDRM_FILES) +LOCAL_EXPORT_C_INCLUDE_DIRS += \ + $(LOCAL_PATH) \ + $(LOCAL_PATH)/include/drm LOCAL_C_INCLUDES := \ $(LIBDRM_TOP)/include/drm @@ -40,6 +45,12 @@ LOCAL_C_INCLUDES := \ LOCAL_CFLAGS := \ -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +LOCAL_COPY_HEADERS := \ + $(LIBDRM_H_FILES) \ + $(addprefix include/drm/,$(LIBDRM_INCLUDE_H_FILES)) \ + $(addprefix include/drm/,$(LIBDRM_INCLUDE_VMWGFX_H_FILES)) + +LOCAL_COPY_HEADERS_TO := libdrm include $(BUILD_SHARED_LIBRARY) include $(LOCAL_PATH)/intel/Android.mk diff --git a/intel/Android.mk b/intel/Android.mk index 5c48a95..f2f21b9 100644 --- a/intel/Android.mk +++ b/intel/Android.mk @@ -24,7 +24,7 @@ LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) -# Import variables LIBDRM_INTEL_FILES, LIBDRM_INTEL_HEADERS +# Import variables LIBDRM_INTEL_FILES, LIBDRM_INTEL_H_FILES include $(LOCAL_PATH)/Makefile.sources LOCAL_MODULE := libdrm_intel @@ -33,6 +33,8 @@ LOCAL_MODULE_TAGS := optional LOCAL_SHARED_LIBRARIES := libdrm LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES) +LOCAL_EXPORT_C_INCLUDE_DIRS += \ + $(LOCAL_PATH)/intel LOCAL_C_INCLUDES := \ $(LIBDRM_TOP) \ @@ -43,6 +45,9 @@ LOCAL_C_INCLUDES := \ LOCAL_CFLAGS := \ -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 +LOCAL_COPY_HEADERS := $(LIBDRM_INTEL_H_FILES) +LOCAL_COPY_HEADERS_TO := libdrm + LOCAL_SHARED_LIBRARIES := \ libdrm \ libpciaccess -- 2.0.2
[PATCH 7/8] nouveau: add Android build support
v2 Rename the headers variable(s) to *_H_FILES. Signed-off-by: Emil Velikov --- Android.mk | 1 + nouveau/Android.mk | 30 ++ 2 files changed, 31 insertions(+) create mode 100644 nouveau/Android.mk diff --git a/Android.mk b/Android.mk index 3f43625..d040d4f 100644 --- a/Android.mk +++ b/Android.mk @@ -55,6 +55,7 @@ include $(BUILD_SHARED_LIBRARY) SUBDIRS := \ intel \ + nouveau \ radeon mkfiles := $(patsubst %,$(LIBDRM_TOP)/%/Android.mk,$(SUBDIRS)) diff --git a/nouveau/Android.mk b/nouveau/Android.mk new file mode 100644 index 000..734fc21 --- /dev/null +++ b/nouveau/Android.mk @@ -0,0 +1,30 @@ +LOCAL_PATH := $(call my-dir) +include $(CLEAR_VARS) + +# Import variables LIBDRM_NOUVEAU_FILES, LIBDRM_NOUVEAU_H_FILES +include $(LOCAL_PATH)/Makefile.sources + +LOCAL_MODULE := libdrm_nouveau +LOCAL_MODULE_TAGS := optional + +LOCAL_SHARED_LIBRARIES := libdrm + +LOCAL_SRC_FILES := $(LIBDRM_NOUVEAU_FILES) +LOCAL_EXPORT_C_INCLUDE_DIRS += \ + $(LOCAL_PATH)/nouveau + +LOCAL_C_INCLUDES := \ + $(LIBDRM_TOP) \ + $(LIBDRM_TOP)/nouveau \ + $(LIBDRM_TOP)/include/drm + +LOCAL_CFLAGS := \ + -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 + +LOCAL_COPY_HEADERS := $(LIBDRM_NOUVEAU_H_FILES) +LOCAL_COPY_HEADERS_TO := libdrm + +LOCAL_SHARED_LIBRARIES := \ + libdrm + +include $(BUILD_SHARED_LIBRARY) -- 2.0.2
[PATCH] drm/radeon: tweak ACCEL_WORKING2 query for hawaii
On Tue, Jul 29, 2014 at 1:10 PM, Jerome Glisse wrote:
> On Tue, Jul 29, 2014 at 01:05:15PM -0400, Alex Deucher wrote:
>> On Tue, Jul 29, 2014 at 11:39 AM, Jerome Glisse
>> wrote:
>> > On Tue, Jul 29, 2014 at 10:33:18AM -0400, Alex Deucher wrote:
>> >> Return 2 so we can be sure the kernel has the necessary
>> >> changes for acceleration to work.
>> >
>> > I highly dislike that ? Why about just using nop2 in userspace ?
>>
>> How to we tell whether the version of mesa has that change or not?
>
> You do not need to know that in kernel, all that is needed is for userspace
> to test 3.16 kernel as it's all that is needed to get accel working. So i
> would say enable accel on ddx now because truly if someone update its ddx
> then it must have updated mesa too.
>
>> Also, packet2 nops are deprecated so may not work in future firmwares
>> if we end up updating them again.
>
> I do not want to go into discussion on closed source firmware, if they offer
> no API stability i would consider that utterly broken.
>
It is stable within a generation. The packet 2 nops were deprecated
for CI which is way we switched all the CI parts to use the new packet
3 nop. I must have inadvertently grabbed an old version of the hawaii
firmware when I initially released it.
Alex
>>
>> Alex
>>
>> >
>> >>
>> >> Signed-off-by: Alex Deucher
>> >> ---
>> >> drivers/gpu/drm/radeon/radeon_kms.c | 9 -
>> >> 1 file changed, 8 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
>> >> b/drivers/gpu/drm/radeon/radeon_kms.c
>> >> index 35d9318..dcec4ff 100644
>> >> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> >> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> >> @@ -254,7 +254,14 @@ static int radeon_info_ioctl(struct drm_device *dev,
>> >> void *data, struct drm_file
>> >> }
>> >> break;
>> >> case RADEON_INFO_ACCEL_WORKING2:
>> >> - *value = rdev->accel_working;
>> >> + if (rdev->family == CHIP_HAWAII) {
>> >> + if (rdev->accel_working && rdev->new_fw)
>> >> + *value = 2;
>> >> + else
>> >> + *value = 0;
>> >> + } else {
>> >> + *value = rdev->accel_working;
>> >> + }
>> >> break;
>> >> case RADEON_INFO_TILING_CONFIG:
>> >> if (rdev->family >= CHIP_BONAIRE)
>> >> --
>> >> 1.8.3.1
>> >>
>> >> ___
>> >> dri-devel mailing list
>> >> dri-devel at lists.freedesktop.org
>> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] [PATCH 10/9] drm: Add dev->vblank_disable_immediate flag
On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
> On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrj?l?
> >
> > Add a flag to drm_device which will cause the vblank code to bypass the
> > disable timer and always disable the vblank interrupt immediately when
> > the last reference is dropped.
> >
> > Signed-off-by: Ville Syrj?l?
> > ---
> > drivers/gpu/drm/drm_irq.c | 6 +++---
> > include/drm/drmP.h| 10 ++
> > 2 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 20a4855..b008803 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -994,11 +994,11 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
> >
> > /* Last user schedules interrupt disable */
> > if (atomic_dec_and_test(&vblank->refcount)) {
> > - if (drm_vblank_offdelay > 0)
> > + if (dev->vblank_disable_immediate || drm_vblank_offdelay == 0)
> > + vblank_disable_fn((unsigned long)vblank);
> > + else if (drm_vblank_offdelay > 0)
> > mod_timer(&vblank->disable_timer,
> > jiffies + ((drm_vblank_offdelay * HZ)/1000));
> > - else if (drm_vblank_offdelay == 0)
> > - vblank_disable_fn((unsigned long)vblank);
> > }
> > }
> > EXPORT_SYMBOL(drm_vblank_put);
>
> Would it be better if we just squashed this device flag logic back into
> patch 7, but kept the drm_vblank_offdelay == 0 meaning of "never
> disable?" I can see there being people who might already use this when
> debugging new and potentially flaky hardware platforms who would be
> surprised by the change in behavior. So basically something like:
>
> if (drm_vblank_offdelay == 0)
> return
> else if (dev->vblank_disable_immediate)
> vblank_disable_fn((unsigned long)vblank);
> else
> mod_timer(...);
I'm not sure I want drm_vblank_offdelay affecting drivers that have
vblank_disable_immediate set since it's a global variable. If there
are two devices on the system where one has
vblank_disable_immediate==true and the other doesn't, the user
might want to keep vblank interrupts enabled on the crappy device
all time by frobbing drm_vblank_offdelay.
I agree that changing the meaning of drm_vblank_offdelay=0 is a bit
questionable, but reversing the meaning so that '==0' meas 'never disable'
and '<0' means 'disable immediately' seemed a bit weird for my taste. But
I suppose I could make that change if people think it's better. Or maybe
just forget about the 'disable immediately' behaviour when
vblank_disable_immediate==false?
> I'd also suggest adding a comment in drm_stub.c to indicate that
> drm_vblank_offdelay gets ignored for drivers that set
> vblank_disable_immediate.
Good idea.
>
> Other than that, patches 1-8, 10, and 11 are
> Reviewed-by: Matt Roper
>
> I'll finish up reviewing #9 and 12-14 tomorrow when I have some more
> time.
>
>
>
> Matt
>
>
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 979a498..0944544 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -1117,6 +1117,16 @@ struct drm_device {
> > */
> > bool vblank_disable_allowed;
> >
> > + /*
> > +* If true, vblank interrupt will be disabled immediately when the
> > +* refcount drops to zero, as opposed to via the vblank disable
> > +* timer.
> > +* This can be set to true it the hardware has a working vblank
> > +* counter and the driver uses drm_vblank_on() and drm_vblank_off()
> > +* appropriately.
> > +*/
> > + bool vblank_disable_immediate;
> > +
> > /* array of size num_crtcs */
> > struct drm_vblank_crtc *vblank;
> >
> > --
> > 1.8.5.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
--
Ville Syrj?l?
Intel OTC
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #9 from Colin --- (In reply to Alex Deucher from comment #8) > (In reply to Colin from comment #7) > > > > Oh. I hadn't realised. Anyway, with the patch removed the card supports XV > > in X windows and with the patch installed it doesn't. If the firmware always > > fails to load what does it do? > > The firmware doesn't always fail to load; it loads fine. Something is wrong > with yourt setup. Attach your xorg log and dmesg output for both cases. but it was you that said it always failed to load so I am getting confused now. It is not to do with X because the problem shows up in plain text mode as well before X is ever loaded. With the patch installed it won't load any fonts other than the default one when it is booting. With the patch removed it will with no other changes. If I undo the patch and make no other changes what so ever it works correctly If I compile the driver as a module it with no other changes what so ever it works correctly. If I apply the patch and compile the kernel with the driver statically linked but no other changes what so ever it works correctly. I don't see how it can be my setup when the only change to make it work or break is that patch. I am not at home just now so I can't create a dmesg or xorg file but I'll send them later. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #10 from Alex Deucher --- (In reply to Colin from comment #9) > but it was you that said it always failed to load so I am getting confused > now. > > It is not to do with X because the problem shows up in plain text mode as > well before X is ever loaded. With the patch installed it won't load any > fonts other than the default one when it is booting. With the patch removed > it will with no other changes. > > If I undo the patch and make no other changes what so ever it works correctly > > If I compile the driver as a module it with no other changes what so ever it > works correctly. > > If I apply the patch and compile the kernel with the driver statically > linked but no other changes what so ever it works correctly. > > I don't see how it can be my setup when the only change to make it work or > break is that patch. I was referring to your setup. All the patch does it move the firmware loading earlier in the driver init process. So if the firmware loading fails with the patch applied, it should also fail without it asuming everything else is the same in your setup. Something is wrong with your local configuration such that the firmware is not availabl at driver load in some cases. The firmware is required to use acceleration in the driver. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] [PATCH 10/9] drm: Add dev->vblank_disable_immediate flag
On Tue, Jul 29, 2014 at 08:31:55PM +0300, Ville Syrj?l? wrote:
> On Thu, Jun 19, 2014 at 05:41:24PM -0700, Matt Roper wrote:
> > On Mon, May 26, 2014 at 05:26:47PM +0300, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrj?l?
> > >
> > > Add a flag to drm_device which will cause the vblank code to bypass the
> > > disable timer and always disable the vblank interrupt immediately when
> > > the last reference is dropped.
> > >
> > > Signed-off-by: Ville Syrj?l?
> > > ---
> > > drivers/gpu/drm/drm_irq.c | 6 +++---
> > > include/drm/drmP.h| 10 ++
> > > 2 files changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index 20a4855..b008803 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -994,11 +994,11 @@ void drm_vblank_put(struct drm_device *dev, int
> > > crtc)
> > >
> > > /* Last user schedules interrupt disable */
> > > if (atomic_dec_and_test(&vblank->refcount)) {
> > > - if (drm_vblank_offdelay > 0)
> > > + if (dev->vblank_disable_immediate || drm_vblank_offdelay == 0)
> > > + vblank_disable_fn((unsigned long)vblank);
> > > + else if (drm_vblank_offdelay > 0)
> > > mod_timer(&vblank->disable_timer,
> > > jiffies + ((drm_vblank_offdelay * HZ)/1000));
> > > - else if (drm_vblank_offdelay == 0)
> > > - vblank_disable_fn((unsigned long)vblank);
> > > }
> > > }
> > > EXPORT_SYMBOL(drm_vblank_put);
> >
> > Would it be better if we just squashed this device flag logic back into
> > patch 7, but kept the drm_vblank_offdelay == 0 meaning of "never
> > disable?" I can see there being people who might already use this when
> > debugging new and potentially flaky hardware platforms who would be
> > surprised by the change in behavior. So basically something like:
> >
> > if (drm_vblank_offdelay == 0)
> > return
> > else if (dev->vblank_disable_immediate)
> > vblank_disable_fn((unsigned long)vblank);
> > else
> > mod_timer(...);
>
> I'm not sure I want drm_vblank_offdelay affecting drivers that have
> vblank_disable_immediate set since it's a global variable. If there
> are two devices on the system where one has
> vblank_disable_immediate==true and the other doesn't, the user
> might want to keep vblank interrupts enabled on the crappy device
> all time by frobbing drm_vblank_offdelay.
>
> I agree that changing the meaning of drm_vblank_offdelay=0 is a bit
> questionable, but reversing the meaning so that '==0' meas 'never disable'
> and '<0' means 'disable immediately' seemed a bit weird for my taste. But
> I suppose I could make that change if people think it's better. Or maybe
> just forget about the 'disable immediately' behaviour when
> vblank_disable_immediate==false?
>
> > I'd also suggest adding a comment in drm_stub.c to indicate that
> > drm_vblank_offdelay gets ignored for drivers that set
> > vblank_disable_immediate.
>
> Good idea.
Yeah, I think that's good enough. There really shouldn't be any need for
drivers which support immediate vblank disabling to ever keep it on for a
while. Presuming the immediate disable actually works ofc.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #119 from Luzipher --- (In reply to comment #88) > Try re-grabbing my drm-next-3.17-wip tree. I dropped the last commit. Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo v3.1 table ? Or does it need to be handled differently ? Just so you don't forget ;-) -- 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/20140729/a606537f/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #120 from Alex Deucher --- (In reply to comment #119) > (In reply to comment #88) > > Try re-grabbing my drm-next-3.17-wip tree. I dropped the last commit. > > Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo > v3.1 table ? Or does it need to be handled differently ? Just so you don't > forget ;-) Can someone test it to see if it fixes any issues other than the messages in the log? I don't have a hawaii board with that table version. -- 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/20140729/4605bd27/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #121 from Kai --- (In reply to comment #120) > (In reply to comment #119) > > (In reply to comment #88) > > > Try re-grabbing my drm-next-3.17-wip tree. I dropped the last commit. > > > > Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo > > v3.1 table ? Or does it need to be handled differently ? Just so you don't > > forget ;-) > > Can someone test it to see if it fixes any issues other than the messages in > the log? I don't have a hawaii board with that table version. What kind of issues would I be looking for? (I think I see the relevant error message: > [drm:radeon_atom_get_leakage_vddc_based_on_leakage_params] *ERROR* Unknown > table version 3, 1 but I didn't see any issues besides what I've reported here (mainly missing speed)) And just to ensure this doesn't get overlooked: if we need a new version of the DDX patch (since the kernel is now returning a "2" to signal acceleration), please provide that as well. ;-) -- 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/20140729/3fd20498/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #122 from Kai --- (In reply to comment #106) > (In reply to comment #105) > > Kai: did changing "Composition type" also fix the corrupted glyphs or just > > the title bars ? I've seen exactly one corrupted glyph in firefox so far > > (several hours of use) on cinnamon (but I'm not sure what cinnamon uses as I > > couldn't find any settings related to opengl). > > Can't say for sure. With XRender I saw a corrupted glyph almost immediately > on the first page I visited. Since switching to OpenGL as "compositing type" > in KDE's settings, I haven't seen a corrupt glyph. But it could also be > coincidence. Just to get back to this: I'm still seeing misrendered glyphs from time to time. The way they are misrendered is different each time. Sometimes I get just a black block, sometimes what can be seen in the image I posted, etc. It's also not just limited to the browser, even though I can observe it there most often. -- 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/20140729/2fbf6444/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #123 from Alex Deucher --- (In reply to comment #121) > (In reply to comment #120) > > (In reply to comment #119) > > > (In reply to comment #88) > > > > Try re-grabbing my drm-next-3.17-wip tree. I dropped the last commit. > > > > > > Alex, are you going to reapply the dropped patch for the > > > ASIC_ProfilingInfo > > > v3.1 table ? Or does it need to be handled differently ? Just so you don't > > > forget ;-) > > > > Can someone test it to see if it fixes any issues other than the messages in > > the log? I don't have a hawaii board with that table version. > > What kind of issues would I be looking for? (I think I see the relevant > error message: > > [drm:radeon_atom_get_leakage_vddc_based_on_leakage_params] *ERROR* Unknown > > table version 3, 1 > but I didn't see any issues besides what I've reported here (mainly missing > speed)) That issue is tracked separately in bug 74250. As for the performance, check sudo cat /sys/kernel/debug/dri/64/radeon_pm_info and see if the values in there look sane and if they scale up properly with 3D load. Report any issues related to that on bug 74250. Here's the 3.17 rebased on fixes branch: http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.17-rebased-on-fixes -- 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/20140729/93ba4caf/attachment.html>
[ANNOUNCE] libdrm 2.4.56
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Libdrm 2.4.56 has been released. It fixes MSAA for the Radeon Hawaii GPU. Andreas Boll (1): libdrm: Fix drm.h include in qxl drm header file Marek Ol??k (2): radeon: fix typo in sample split / fixes MSAA on Hawaii configure.ac: bump version to 2.4.56 for release git tag: libdrm-2.4.56 http://dri.freedesktop.org/libdrm/libdrm-2.4.56.tar.bz2 MD5: 93fdb76d392ce27b23561afb8f70db81 libdrm-2.4.56.tar.bz2 SHA1: c61feed76db0ca729febbc45794d13d04a3eeb53 libdrm-2.4.56.tar.bz2 SHA256: e20fbbe092177a8422913d8884a1255477456ab5b10b07389fa891a4dce54030 libdrm-2.4.56.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.56.tar.gz MD5: 43a7a7b15383a49738fc3a70d53e5a28 libdrm-2.4.56.tar.gz SHA1: eae152deb842dda2b909b605117bc10412971ee2 libdrm-2.4.56.tar.gz SHA256: 2af97b79d9c3947d596b80f70ae603af6539e9c0351113da5facab0488813990 libdrm-2.4.56.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJT2A/bAAoJEP3RXVrO8PKxFsMIANAmeK2ZHFvl9g0tijPwAO/W VbsaeH9+JMXz/GzCJ6xGJCnyNqkeV5v8FeO0i5f/8bDlBI50LP2yn+fhGdQRcQTD Kpz/aNQJrQ2SeBX6H3e3roV6TkdosOk1mVo2vDTs0LArwkc3K/izKHrI4P1AgTQm g13pMo7SpnXmD6ZcWVybNiCzwrtBTCT5dbegJ4C1lV1ev13nxXMtrqnNBaWtv4TU ccP2cKQLkTM8WZAjnTKbhnOCL7/TbcACTvXQuqVLETPLQvqHJEQz00qxygyta3YW IOJyImGhrEjmROiPbiz6/giDcF9t6AxWcCfmUiCdZgjf+FFqJNRHCsJHEFhHwv4= =3H85 -END PGP SIGNATURE-
[PATCH 0/8] atomic prep work
Hi all, So I've split out every single hunk that touches existing code from my atomic series and this is it. It mostly touches error handling code and other more exceptional stuff. My idea is that if we get this in now we have a bit more leeway with the actual atomic infrastructure work since that won't touch any code any more which is used by current drivers. Comments, flames and reviews highly welcome. Cheers, Daniel Daniel Vetter (8): 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 ctx drm: Move ->old_fb from crtc to plane drm: trylock modest locking for fbdev panics drm: Add a plane->reset hook drm/irq: Implement a generic vblank_wait function drm/i915: Use generic vblank wait drivers/gpu/drm/drm_crtc.c | 194 +-- drivers/gpu/drm/drm_fb_helper.c | 10 +- drivers/gpu/drm/drm_irq.c| 45 drivers/gpu/drm/drm_modeset_lock.c | 213 ++- drivers/gpu/drm/i915/intel_display.c | 41 +-- include/drm/drmP.h | 2 + include/drm/drm_crtc.h | 21 ++-- include/drm/drm_modeset_lock.h | 16 +++ 8 files changed, 373 insertions(+), 169 deletions(-) -- 2.0.1
[PATCH 1/8] drm: Add drm_plane/connector_index
In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.
If it later on turns out that the list walking is too expensive we can
add the index to the relevant modeset objects.
Rob Clark doesn't like the loops too much, but we can always add an
obj->idx parameter later on. And for now reiterating is actually safer
since nowadays we have hotpluggable connectors (thanks to DP MST).
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 46 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 805240b11229..5a494caa8c9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector *connector)
EXPORT_SYMBOL(drm_connector_cleanup);
/**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_connector_index(struct drm_connector *connector)
+{
+ unsigned int index = 0;
+ struct drm_connector *tmp;
+
+ list_for_each_entry(tmp, &connector->dev->mode_config.connector_list,
head) {
+ if (tmp == connector)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_connector_index);
+
+/**
* drm_connector_register - register a connector
* @connector: the connector to register
*
@@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
EXPORT_SYMBOL(drm_plane_cleanup);
/**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_plane_index(struct drm_plane *plane)
+{
+ unsigned int index = 0;
+ struct drm_plane *tmp;
+
+ list_for_each_entry(tmp, &plane->dev->mode_config.plane_list, head) {
+ if (tmp == plane)
+ return index;
+
+ index++;
+ }
+
+ BUG();
+}
+EXPORT_SYMBOL(drm_plane_index);
+
+/**
* drm_plane_force_disable - Forcibly disable a plane
* @plane: plane to disable
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0da059..4cae44611ab0 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -903,6 +903,7 @@ int drm_connector_register(struct drm_connector *connector);
void drm_connector_unregister(struct drm_connector *connector);
extern void drm_connector_cleanup(struct drm_connector *connector);
+extern unsigned int drm_connector_index(struct drm_connector *crtc);
/* helper to unplug all connectors from sysfs for device */
extern void drm_connector_unplug_all(struct drm_device *dev);
@@ -942,6 +943,7 @@ extern int drm_plane_init(struct drm_device *dev,
const uint32_t *formats, uint32_t format_count,
bool is_primary);
extern void drm_plane_cleanup(struct drm_plane *plane);
+extern unsigned int drm_plane_index(struct drm_plane *crtc);
extern void drm_plane_force_disable(struct drm_plane *plane);
extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
int x, int y,
--
2.0.1
[PATCH 2/8] drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
Somehow we've forgotten about this little bit of OCD.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 95 --
drivers/gpu/drm/drm_modeset_lock.c | 95 ++
include/drm/drm_crtc.h | 4 --
include/drm/drm_modeset_lock.h | 5 ++
4 files changed, 100 insertions(+), 99 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5a494caa8c9a..ff583bec31f9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -45,101 +45,6 @@ static struct drm_framebuffer
*add_framebuffer_internal(struct drm_device *dev,
struct drm_mode_fb_cmd2
*r,
struct drm_file
*file_priv);
-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx;
- int ret;
-
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
-
- mutex_lock(&config->mutex);
-
- drm_modeset_acquire_init(ctx, 0);
-
-retry:
- ret = drm_modeset_lock(&config->connection_mutex, ctx);
- if (ret)
- goto fail;
- ret = drm_modeset_lock_all_crtcs(dev, ctx);
- if (ret)
- goto fail;
-
- WARN_ON(config->acquire_ctx);
-
- /* now we hold the locks, so now that it is safe, stash the
-* ctx for drm_modeset_unlock_all():
-*/
- config->acquire_ctx = ctx;
-
- drm_warn_on_modeset_not_all_locked(dev);
-
- return;
-
-fail:
- if (ret == -EDEADLK) {
- drm_modeset_backoff(ctx);
- goto retry;
- }
-}
-EXPORT_SYMBOL(drm_modeset_lock_all);
-
-/**
- * drm_modeset_unlock_all - drop all modeset locks
- * @dev: device
- *
- * This function drop all modeset locks taken by drm_modeset_lock_all.
- */
-void drm_modeset_unlock_all(struct drm_device *dev)
-{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
-
- if (WARN_ON(!ctx))
- return;
-
- config->acquire_ctx = NULL;
- drm_modeset_drop_locks(ctx);
- drm_modeset_acquire_fini(ctx);
-
- kfree(ctx);
-
- mutex_unlock(&dev->mode_config.mutex);
-}
-EXPORT_SYMBOL(drm_modeset_unlock_all);
-
-/**
- * drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
- * @dev: device
- *
- * Useful as a debug assert.
- */
-void drm_warn_on_modeset_not_all_locked(struct drm_device *dev)
-{
- struct drm_crtc *crtc;
-
- /* Locking is currently fubar in the panic handler. */
- if (oops_in_progress)
- return;
-
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
-
- WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
- WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
-}
-EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
-
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 0dc57d5ecd10..73e6534fd0aa 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,6 +57,101 @@
/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+ struct drm_mode_config *config = &dev->mode_config;
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ mutex_lock(&config->mutex);
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(&config->connection_mutex, ctx);
+ if (ret)
+ goto fail;
+ ret = drm_modeset_lock_all_crtcs(dev, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(config->acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_all():
+*/
+ config->acquire_ctx = ctx;
+
+ drm_warn_on_modeset_not_all_locked(dev);
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ct
[PATCH 3/8] drm: Handle legacy per-crtc locking with full acquire ctx
So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.
Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those paths which grab all locks we already
have to keep around an acquire context in dev->mode_config. Helper
functions that implement legacy interfaces in terms of atomic support
can therefore grab this acquire contexts and reuse it.
The only interfaces left are the cursor and pageflip ioctls. So add
functions to grab the crtc lock these need using an acquire context
and preserve it for atomic drivers to reuse.
v2:
- Fixup comments&kerneldoc.
- Drop the WARNING from modeset_lock_all_crtcs since that can be used
in legacy paths with crtc locking.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 8 ++--
drivers/gpu/drm/drm_modeset_lock.c | 84 ++
include/drm/drm_crtc.h | 6 +++
include/drm/drm_modeset_lock.h | 5 +++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index ff583bec31f9..c09374038f9a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2714,7 +2714,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (crtc->cursor)
return drm_mode_cursor_universal(crtc, req, file_priv);
- drm_modeset_lock(&crtc->mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (req->flags & DRM_MODE_CURSOR_BO) {
if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
ret = -ENXIO;
@@ -2738,7 +2738,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
}
out:
- drm_modeset_unlock(&crtc->mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
@@ -4474,7 +4474,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!crtc)
return -ENOENT;
- drm_modeset_lock(&crtc->mutex, NULL);
+ drm_modeset_lock_crtc(crtc);
if (crtc->primary->fb == NULL) {
/* The framebuffer is currently unbound, presumably
* due to a hotplug event, that userspace has not
@@ -4558,7 +4558,7 @@ out:
drm_framebuffer_unreference(fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
- drm_modeset_unlock(&crtc->mutex);
+ drm_modeset_unlock_crtc(crtc);
return ret;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 73e6534fd0aa..4d2aa549c614 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -130,6 +130,90 @@ void drm_modeset_unlock_all(struct drm_device *dev)
EXPORT_SYMBOL(drm_modeset_unlock_all);
/**
+ * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx
+ * @crtc: drm crtc
+ *
+ * This function locks the given crtc using a hidden acquire context. This is
+ * necessary so that drivers internally using the atomic interfaces can grab
+ * furether locks with the lock acquire context.
+ */
+void drm_modeset_lock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx;
+ int ret;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (WARN_ON(!ctx))
+ return;
+
+ drm_modeset_acquire_init(ctx, 0);
+
+retry:
+ ret = drm_modeset_lock(&crtc->mutex, ctx);
+ if (ret)
+ goto fail;
+
+ WARN_ON(crtc->acquire_ctx);
+
+ /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_crtc():
+*/
+ crtc->acquire_ctx = ctx;
+
+ return;
+
+fail:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(ctx);
+ goto retry;
+ }
+}
+EXPORT_SYMBOL(drm_modeset_lock_crtc);
+
+/**
+ * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
+ * crtc: drm crtc
+ *
+ * Legacy ioctl operations like cursor updates or page flips only have per-crtc
+ * locking, and store the acquire ctx in the corresponding crtc. All other
+ * legacy operations take all locks and use a global acquire context. This
+ * function grabs the right one.
+ */
+struct drm_modeset_acquire_ctx *
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
+{
+ if (crtc->acquire_ctx)
+ return crtc->acquire_ctx;
+
+ WARN_ON(!crtc->dev->mode_config.acquire_ctx);
+
+ return crtc->dev->mode_config.acquire_ctx;
+}
+EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
+
+/**
+ * drm_modeset_unlock_crtc - drop crtc lock
+ * @crtc: drm crtc
+ *
+ * This drops the crtc lock acquire with drm_modeset_lock_crtc() and all other
+ * locks acquired through the hidden context.
+ */
+void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
+{
+ struct drm_modeset_acquire_ctx *ctx = crtc->acquire_
[PATCH 4/8] drm: Move ->old_fb from crtc to plane
Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.
The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 40
include/drm/drm_crtc.h | 8
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index c09374038f9a..bacf565449d5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
*/
void drm_plane_force_disable(struct drm_plane *plane)
{
- struct drm_framebuffer *old_fb = plane->fb;
int ret;
- if (!old_fb)
+ if (!plane->fb)
return;
+ plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (ret) {
DRM_ERROR("failed to disable plane with busy fb\n");
+ plane->old_fb = NULL;
return;
}
/* disconnect the plane from the fb and crtc: */
- __drm_framebuffer_unreference(old_fb);
+ __drm_framebuffer_unreference(plane->old_fb);
+ plane->old_fb = NULL;
plane->fb = NULL;
plane->crtc = NULL;
}
@@ -2188,7 +2190,7 @@ static int setplane_internal(struct drm_plane *plane,
uint32_t src_w, uint32_t src_h)
{
struct drm_device *dev = plane->dev;
- struct drm_framebuffer *old_fb = NULL;
+ struct drm_framebuffer *old_fb;
int ret = 0;
unsigned int fb_width, fb_height;
int i;
@@ -2196,14 +2198,16 @@ static int setplane_internal(struct drm_plane *plane,
/* No fb means shut it down */
if (!fb) {
drm_modeset_lock_all(dev);
- old_fb = plane->fb;
+ plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (!ret) {
plane->crtc = NULL;
plane->fb = NULL;
} else {
- old_fb = NULL;
+ plane->old_fb = NULL;
}
+ old_fb = plane->old_fb;
+ plane->old_fb = NULL;
drm_modeset_unlock_all(dev);
goto out;
}
@@ -2245,7 +2249,7 @@ static int setplane_internal(struct drm_plane *plane,
}
drm_modeset_lock_all(dev);
- old_fb = plane->fb;
+ plane->old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h);
@@ -2254,8 +2258,10 @@ static int setplane_internal(struct drm_plane *plane,
plane->fb = fb;
fb = NULL;
} else {
- old_fb = NULL;
+ plane->old_fb = NULL;
}
+ old_fb = plane->old_fb;
+ plane->old_fb = NULL;
drm_modeset_unlock_all(dev);
out:
@@ -2369,7 +2375,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
* crtcs. Atomic modeset will have saner semantics ...
*/
list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head)
- tmp->old_fb = tmp->primary->fb;
+ tmp->primary->old_fb = tmp->primary->fb;
fb = set->fb;
@@ -2382,8 +2388,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
list_for_each_entry(tmp, &crtc->dev->mode_config.crtc_list, head) {
if (tmp->primary->fb)
drm_framebuffer_reference(tmp->primary->fb);
- if (tmp->old_fb)
- drm_framebuffer_unreference(tmp->old_fb);
+ if (tmp->primary->old_fb)
+ drm_framebuffer_unreference(tmp->primary->old_fb);
+ tmp->primary->old_fb = NULL;
}
return ret;
@@ -4458,7 +4465,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
{
struct drm_mode_crtc_page_flip *page_flip = data;
struct drm_crtc *crtc;
- struct drm_framebuffer *fb = NULL, *old_fb = NULL;
+ struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
int ret = -EINVAL;
@@ -4530,7 +4537,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
(void (*) (struct drm_pending_event *)) kfree;
}
- old_fb = crtc->primary->fb;
+ crtc->primary->old_fb = crtc->primary->fb;
ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags);
[PATCH 5/8] drm: trylock modest locking for fbdev panics
In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.
So add a trylock mode to the modeset locking code which attempts all
locks only with trylocks, if possible. We need to track this in the
locking functions themselves and can't restrict this to drivers since
driver-private w/w mutexes must be treated the same way.
There's still the issue that other driver private locks aren't handled
here at all, but well can't have everything. With this we will at
least not regress, even once atomic allows lots of concurrent kms
activity.
Aside: We should move the acquire context to stack-based allocation in
the callers to get rid of that awful WARN_ON(kmalloc_failed) control
flow which just blows up when memory is short. But that's material for
separate patches.
v2:
- Fix logic inversion fumble in the fb helper.
- Add proper kerneldoc.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 10 +++
drivers/gpu/drm/drm_modeset_lock.c | 56 ++
include/drm/drm_modeset_lock.h | 6
3 files changed, 55 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9dc0f1..841e039ba028 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -419,11 +419,11 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;
- /* NOTE: we use lockless flag below to avoid grabbing other
-* modeset locks. So just trylock the underlying mutex
-* directly:
+ /*
+* NOTE: Use trylock mode to avoid deadlocks and sleeping in
+* panic context.
*/
- if (!mutex_trylock(&dev->mode_config.mutex)) {
+ if (__drm_modeset_lock_all(dev, true) != 0) {
error = true;
continue;
}
@@ -432,7 +432,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (ret)
error = true;
- mutex_unlock(&dev->mode_config.mutex);
+ drm_modeset_unlock_all(dev);
}
return error;
}
diff --git a/drivers/gpu/drm/drm_modeset_lock.c
b/drivers/gpu/drm/drm_modeset_lock.c
index 4d2aa549c614..acfe187609b0 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,26 +57,37 @@
/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
+ * __drm_modeset_lock_all - internal helper to grab all modeset locks
+ * @dev: DRM device
+ * @trylock: trylock mode for atomic contexts
*
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
+ * This is a special version of drm_modeset_lock_all() which can also be used
in
+ * atomic contexts. Then @trylock must be set to true.
+ *
+ * Returns:
+ * 0 on success or negative error code on failure.
*/
-void drm_modeset_lock_all(struct drm_device *dev)
+int __drm_modeset_lock_all(struct drm_device *dev,
+ bool trylock)
{
struct drm_mode_config *config = &dev->mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;
- ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
- if (WARN_ON(!ctx))
- return;
+ ctx = kzalloc(sizeof(*ctx),
+ trylock ? GFP_ATOMIC : GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
- mutex_lock(&config->mutex);
+ if (trylock) {
+ if (!mutex_trylock(&config->mutex))
+ return -EBUSY;
+ } else {
+ mutex_lock(&config->mutex);
+ }
drm_modeset_acquire_init(ctx, 0);
+ ctx->trylock_only = trylock;
retry:
ret = drm_modeset_lock(&config->connection_mutex, ctx);
@@ -95,13 +106,29 @@ retry:
drm_warn_on_modeset_not_all_locked(dev);
- return;
+ return 0;
fail:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
goto retry;
}
+
+ return ret;
+}
+EXPORT_SYMBOL(__drm_modeset_lock_all);
+
+/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+ WARN_ON(__drm_modeset_lock_all(dev, false) != 0);
}
EXPORT_SYMBOL(drm_modeset_lock_all);
@@ -287,7 +314,12 @@ static inline int modeset_lock(struct drm_modeset_lock
[PATCH 6/8] drm: Add a plane->reset hook
In general having this can't hurt, and the atomic helpers will need
it to be able to reset the state objects properly. The overall idea
is to reset in the order pixels flow, so planes -> crtcs ->
encoders -> connectors.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 +
include/drm/drm_crtc.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bacf565449d5..ff705ea3f50e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4582,9 +4582,14 @@ out:
void drm_mode_config_reset(struct drm_device *dev)
{
struct drm_crtc *crtc;
+ struct drm_crtc *plane;
struct drm_encoder *encoder;
struct drm_connector *connector;
+ list_for_each_entry(plane, &dev->mode_config.plane_list, head)
+ if (plane->funcs->reset)
+ plane->funcs->reset(plane);
+
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
if (crtc->funcs->reset)
crtc->funcs->reset(crtc);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5fffb5c53ba6..0115b80a0632 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -580,6 +580,7 @@ struct drm_plane_funcs {
uint32_t src_w, uint32_t src_h);
int (*disable_plane)(struct drm_plane *plane);
void (*destroy)(struct drm_plane *plane);
+ void (*reset)(struct drm_plane *plane);
int (*set_property)(struct drm_plane *plane,
struct drm_property *property, uint64_t val);
--
2.0.1
[PATCH 7/8] drm/irq: Implement a generic vblank_wait function
As usual in both a crtc index and a struct drm_crtc * version.
The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.
v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.
Cc: Ville Syrj?l?
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_irq.c | 45 +
include/drm/drmP.h| 2 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123afdb34..76024fdde452 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -999,6 +999,51 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
EXPORT_SYMBOL(drm_crtc_vblank_put);
/**
+ * drm_vblank_wait - wait for one vblank
+ * @dev: DRM device
+ * @crtc: crtc index
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_vblank_wait(struct drm_device *dev, int crtc)
+{
+ int ret;
+ u32 last;
+
+ ret = drm_vblank_get(dev, crtc);
+ if (WARN_ON(ret))
+ return;
+
+ last = drm_vblank_count(dev, crtc);
+
+#define C (last != drm_vblank_count(dev, crtc))
+ ret = wait_event_timeout(dev->vblank[crtc].queue,
+C, msecs_to_jiffies(100));
+
+ WARN_ON(ret == 0);
+#undef C
+
+ drm_vblank_put(dev, crtc);
+}
+EXPORT_SYMBOL(drm_vblank_wait);
+
+/**
+ * drm_crtc_vblank_wait - wait for one vblank
+ * @crtc: DRM crtc
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc->dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
* drm_vblank_off - disable vblank events on a CRTC
* @dev: DRM device
* @crtc: CRTC in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 06a673894c47..f72e5ef5f7b0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1355,6 +1355,8 @@ extern int drm_vblank_get(struct drm_device *dev, int
crtc);
extern void drm_vblank_put(struct drm_device *dev, int crtc);
extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
+extern void drm_vblank_wait(struct drm_device *dev, int crtc);
+extern void drm_crtc_vblank_wait(struct drm_crtc *crtc);
extern void drm_vblank_off(struct drm_device *dev, int crtc);
extern void drm_vblank_on(struct drm_device *dev, int crtc);
extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
--
2.0.1
[PATCH 8/8] drm/i915: Use generic vblank wait
This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.
Cc: Ville Syrj?l?
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 41 +---
1 file changed, 1 insertion(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1edfd1ae5b37..13bcf1348fc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -891,17 +891,6 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct
drm_i915_private *dev_priv,
return intel_crtc->config.cpu_transcoder;
}
-static void g4x_wait_for_vblank(struct drm_device *dev, int pipe)
-{
- struct drm_i915_private *dev_priv = dev->dev_private;
- u32 frame, frame_reg = PIPE_FRMCOUNT_GM45(pipe);
-
- frame = I915_READ(frame_reg);
-
- if (wait_for(I915_READ_NOTRACE(frame_reg) != frame, 50))
- WARN(1, "vblank wait timed out\n");
-}
-
/**
* intel_wait_for_vblank - wait for vblank on a given pipe
* @dev: drm device
@@ -912,35 +901,7 @@ static void g4x_wait_for_vblank(struct drm_device *dev,
int pipe)
*/
void intel_wait_for_vblank(struct drm_device *dev, int pipe)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
- int pipestat_reg = PIPESTAT(pipe);
-
- if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
- g4x_wait_for_vblank(dev, pipe);
- return;
- }
-
- /* Clear existing vblank status. Note this will clear any other
-* sticky status fields as well.
-*
-* This races with i915_driver_irq_handler() with the result
-* that either function could miss a vblank event. Here it is not
-* fatal, as we will either wait upon the next vblank interrupt or
-* timeout. Generally speaking intel_wait_for_vblank() is only
-* called during modeset at which time the GPU should be idle and
-* should *not* be performing page flips and thus not waiting on
-* vblanks...
-* Currently, the result of us stealing a vblank from the irq
-* handler is that a single frame will be skipped during swapbuffers.
-*/
- I915_WRITE(pipestat_reg,
- I915_READ(pipestat_reg) | PIPE_VBLANK_INTERRUPT_STATUS);
-
- /* Wait for vblank interrupt bit to set */
- if (wait_for(I915_READ(pipestat_reg) &
-PIPE_VBLANK_INTERRUPT_STATUS,
-50))
- DRM_DEBUG_KMS("vblank wait timed out\n");
+ drm_vblank_wait(dev, pipe);
}
static bool pipe_dsl_stopped(struct drm_device *dev, enum pipe pipe)
--
2.0.1
[Bug 74250] [HAWAII][DPM] New Version 3.1 for ASIC_ProfilingInfo / ci_upload_dpm_level_enable_mask failed
https://bugs.freedesktop.org/show_bug.cgi?id=74250 --- Comment #3 from Luzipher --- Now with working Hawaii acceleration, the issue still persists: [drm:ci_dpm_set_power_state] *ERROR* ci_upload_dpm_level_enable_mask failed appears one time during bootup. But I could also trigger it later by doing (accelerated X is up): 1. If I type "xrandr --output HDMI-0 --off" all my three screens go black and never come back (ssh keeps working). Switching on and off DVI-1 works. 2. If I start enlightenment, the same happens (black screens - I think it might be the same issue, maybe enlightenment always sets up the screens on startup ?) Note that I cannot get back to a text console (ctrl-alt-f2 etc.), the screens stay black (but are not in powersave). All of this with the first kernel with working acceleration in bug #78453, comment #81 (drm-next-3.17-wip branch, v3.16-rc4), including the "ASIC_ProfilingInfo v3.1" patch. -- 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/20140729/44d71f45/attachment.html>
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #124 from Luzipher --- (In reply to comment #120) > (In reply to comment #119) > > (In reply to comment #88) > > > Try re-grabbing my drm-next-3.17-wip tree. I dropped the last commit. > > > > Alex, are you going to reapply the dropped patch for the ASIC_ProfilingInfo > > v3.1 table ? Or does it need to be handled differently ? Just so you don't > > forget ;-) > > Can someone test it to see if it fixes any issues other than the messages in > the log? I don't have a hawaii board with that table version. Hm, I'll test if there is any change with your unmodified drm-next-3.17-rebased-on-fixes branch (no v3.1 patch). Other than that (all still with the v3.1 patch included): I can reliably cause GPU resets with entering the world in World of Warcraft (see previous comment #97 for a dmesg). I never gat a rendered image before the game crashes. I didn't yet notice more corrupted glyphs, but the single one I saw was a black rectangle. And for the DPM stuff: dpm doesn't seem to work, the numbers never changed (tested on console without X and Metro Last Light; I dropped my previous "radeon.dpm=0" from the kernel parameters): # cat /sys/kernel/debug/dri/64/radeon_pm_info power level avgsclk: 3 mclk: 15000 I also updated bug #72450 regarding the ASIC_ProfilingInfo v3.1 table with some new information. -- 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/20140729/21faf1ea/attachment.html>
[Intel-gfx] [PATCH 1/8] drm: Add drm_plane/connector_index
On Tue, Jul 29, 2014 at 11:32:16PM +0200, Daniel Vetter wrote:
> In the atomic state we'll have an array of states for crtcs, planes
> and connectors and need to be able to at them by their index. We
> already have a drm_crtc_index function so add the missing ones for
> planes and connectors.
>
> If it later on turns out that the list walking is too expensive we can
> add the index to the relevant modeset objects.
>
> Rob Clark doesn't like the loops too much, but we can always add an
> obj->idx parameter later on. And for now reiterating is actually safer
> since nowadays we have hotpluggable connectors (thanks to DP MST).
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 46
> ++
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 805240b11229..5a494caa8c9a 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> EXPORT_SYMBOL(drm_connector_cleanup);
>
> /**
> + * drm_plane_index - find the index of a registered CRTC
Looks like some copy/paste that needs an update...your kerneldoc calls
the function drm_*PLANE*_index and then talks about CRTC's, but the
actual function is for connectors...
> + * @plane: CRTC to find index for
> + *
> + * Given a registered CRTC, return the index of that CRTC within a DRM
> + * device's list of CRTCs.
> + */
> +unsigned int drm_connector_index(struct drm_connector *connector)
> +{
> + unsigned int index = 0;
> + struct drm_connector *tmp;
> +
> + list_for_each_entry(tmp, &connector->dev->mode_config.connector_list,
> head) {
> + if (tmp == connector)
> + return index;
> +
> + index++;
> + }
> +
> + BUG();
> +}
> +EXPORT_SYMBOL(drm_connector_index);
> +
> +/**
> * drm_connector_register - register a connector
> * @connector: the connector to register
> *
> @@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
> EXPORT_SYMBOL(drm_plane_cleanup);
>
> /**
> + * drm_plane_index - find the index of a registered CRTC
> + * @plane: CRTC to find index for
> + *
> + * Given a registered CRTC, return the index of that CRTC within a DRM
> + * device's list of CRTCs.
> + */
More copy/paste referenecs to CRTC's.
> +unsigned int drm_plane_index(struct drm_plane *plane)
> +{
> + unsigned int index = 0;
> + struct drm_plane *tmp;
> +
> + list_for_each_entry(tmp, &plane->dev->mode_config.plane_list, head) {
> + if (tmp == plane)
> + return index;
> +
> + index++;
> + }
> +
> + BUG();
> +}
> +EXPORT_SYMBOL(drm_plane_index);
> +
> +/**
> * drm_plane_force_disable - Forcibly disable a plane
> * @plane: plane to disable
> *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index f1105d0da059..4cae44611ab0 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -903,6 +903,7 @@ int drm_connector_register(struct drm_connector
> *connector);
> void drm_connector_unregister(struct drm_connector *connector);
>
> extern void drm_connector_cleanup(struct drm_connector *connector);
> +extern unsigned int drm_connector_index(struct drm_connector *crtc);
connector?
> /* helper to unplug all connectors from sysfs for device */
> extern void drm_connector_unplug_all(struct drm_device *dev);
>
> @@ -942,6 +943,7 @@ extern int drm_plane_init(struct drm_device *dev,
> const uint32_t *formats, uint32_t format_count,
> bool is_primary);
> extern void drm_plane_cleanup(struct drm_plane *plane);
> +extern unsigned int drm_plane_index(struct drm_plane *crtc);
plane?
> extern void drm_plane_force_disable(struct drm_plane *plane);
> extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
> int x, int y,
> --
> 2.0.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
[Bug 80331] [BISECTED]Radeon driver broken in kernel 3.12.15 onwards for ATI Radeon HD4770 Card
https://bugzilla.kernel.org/show_bug.cgi?id=80331 --- Comment #11 from Colin --- (In reply to Alex Deucher from comment #10) > (In reply to Colin from comment #9) > > but it was you that said it always failed to load so I am getting confused > > now. > > > > It is not to do with X because the problem shows up in plain text mode as > > well before X is ever loaded. With the patch installed it won't load any > > fonts other than the default one when it is booting. With the patch removed > > it will with no other changes. > > > > If I undo the patch and make no other changes what so ever it works > > correctly > > > > If I compile the driver as a module it with no other changes what so ever it > > works correctly. > > > > If I apply the patch and compile the kernel with the driver statically > > linked but no other changes what so ever it works correctly. > > > > I don't see how it can be my setup when the only change to make it work or > > break is that patch. > > I was referring to your setup. All the patch does it move the firmware > loading earlier in the driver init process. So if the firmware loading > fails with the patch applied, it should also fail without it asuming > everything else is the same in your setup. Something is wrong with your > local configuration such that the firmware is not availabl at driver load in > some cases. The firmware is required to use acceleration in the driver. I've built three versions of the same kernel 3.15.4. The first is the standard kernel including the patch with the radeon driver built as a module. The second is the kernel with the radeon driver statically linked and the third is also statically linked but this time with that patch removed. I've booted from each kernel and made copies of the output from dmesg, the output of setfont and the Xorg log file. I've put the 9 files in a zip file and attached it. The names of each file will tell you what they are. I think your suggestion is correct. With the patch applied something is not ready that prevents the firmware from being loaded. Without the patch or with the driver loaded as a module the firmware loads every time. Loading as a module will presumably mean that it tries to access the firmware file later in the boot process. -- You are receiving this mail because: You are watching the assignee of the bug.
