Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support
2017년 02월 03일 15:38에 Inki Dae 이(가) 쓴 글:
>
>
> 2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글:
>> On TM2/TM2e platforms HDMI output is connected to MHL bridge
>> SiI8620. To allow configure UltraHD modes on the bridge
>> and to eliminate unsupported modes this bridge should be
>> attached to drm_encoder implemented in exynos_hdmi.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 56
>> +---
>> 1 file changed, 46 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a73b192..41fb894 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -35,6 +35,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -133,6 +134,7 @@ struct hdmi_context {
>> struct regulator_bulk_data regul_bulk[ARRAY_SIZE(supply)];
>> struct regulator*reg_hdmi_en;
>> struct exynos_drm_clk phy_clk;
>> +struct drm_bridge *bridge;
>> };
>>
>> static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
>> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder
>> *encoder)
>> drm_connector_register(connector);
>> drm_mode_connector_attach_encoder(connector, encoder);
>>
>> -return 0;
>> +if (hdata->bridge) {
>> +encoder->bridge = hdata->bridge;
>> +hdata->bridge->encoder = encoder;
>> +ret = drm_bridge_attach(encoder->dev, hdata->bridge);
>
> arguments of drm_bridge_attach function has been changed so fixed it -
> trivial thing.
> Applied it including other patches.
The argument was changed by below patch,
drm: bridge: Link encoder and bridge in core code
Thanks.
>
> Thanks,
> Inki Dae
>
>> +if (ret)
>> +DRM_ERROR("Failed to attach bridge\n");
>> +}
>> +
>> +return ret;
>> }
>>
>> static bool hdmi_mode_fixup(struct drm_encoder *encoder,
>> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk
>> *clk, bool enable)
>> hdmiphy_disable(hdata);
>> }
>>
>> +static int hdmi_bridge_init(struct hdmi_context *hdata)
>> +{
>> +struct device *dev = hdata->dev;
>> +struct device_node *ep, *np;
>> +
>> +ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
>> +if (!ep)
>> +return 0;
>> +
>> +np = of_graph_get_remote_port_parent(ep);
>> +of_node_put(ep);
>> +if (!np) {
>> +DRM_ERROR("failed to get remote port parent");
>> +return -EINVAL;
>> +}
>> +
>> +hdata->bridge = of_drm_find_bridge(np);
>> +of_node_put(np);
>> +
>> +if (!hdata->bridge)
>> +return -EPROBE_DEFER;
>> +
>> +return 0;
>> +}
>> +
>> static int hdmi_resources_init(struct hdmi_context *hdata)
>> {
>> struct device *dev = hdata->dev;
>> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context
>> *hdata)
>>
>> hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>>
>> -if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
>> -return 0;
>> +if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
>> +if (IS_ERR(hdata->reg_hdmi_en))
>> +return PTR_ERR(hdata->reg_hdmi_en);
>>
>> -if (IS_ERR(hdata->reg_hdmi_en))
>> -return PTR_ERR(hdata->reg_hdmi_en);
>> -
>> -ret = regulator_enable(hdata->reg_hdmi_en);
>> -if (ret)
>> -DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +ret = regulator_enable(hdata->reg_hdmi_en);
>> +if (ret) {
>> +DRM_ERROR("failed to enable hdmi-en regulator\n");
>> +return ret;
>> +}
>> +}
>>
>> -return ret;
>> +return hdmi_bridge_init(hdata);
>> }
>>
>> static struct of_device_id hdmi_match_types[] = {
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/7] drm/exynos/hdmi: add bridge support
2017년 02월 01일 17:29에 Andrzej Hajda 이(가) 쓴 글:
> On TM2/TM2e platforms HDMI output is connected to MHL bridge
> SiI8620. To allow configure UltraHD modes on the bridge
> and to eliminate unsupported modes this bridge should be
> attached to drm_encoder implemented in exynos_hdmi.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 56
> +---
> 1 file changed, 46 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index a73b192..41fb894 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -133,6 +134,7 @@ struct hdmi_context {
> struct regulator_bulk_data regul_bulk[ARRAY_SIZE(supply)];
> struct regulator*reg_hdmi_en;
> struct exynos_drm_clk phy_clk;
> + struct drm_bridge *bridge;
> };
>
> static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -922,7 +924,15 @@ static int hdmi_create_connector(struct drm_encoder
> *encoder)
> drm_connector_register(connector);
> drm_mode_connector_attach_encoder(connector, encoder);
>
> - return 0;
> + if (hdata->bridge) {
> + encoder->bridge = hdata->bridge;
> + hdata->bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, hdata->bridge);
arguments of drm_bridge_attach function has been changed so fixed it - trivial
thing.
Applied it including other patches.
Thanks,
Inki Dae
> + if (ret)
> + DRM_ERROR("Failed to attach bridge\n");
> + }
> +
> + return ret;
> }
>
> static bool hdmi_mode_fixup(struct drm_encoder *encoder,
> @@ -1591,6 +1601,31 @@ static void hdmiphy_clk_enable(struct exynos_drm_clk
> *clk, bool enable)
> hdmiphy_disable(hdata);
> }
>
> +static int hdmi_bridge_init(struct hdmi_context *hdata)
> +{
> + struct device *dev = hdata->dev;
> + struct device_node *ep, *np;
> +
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, 1, -1);
> + if (!ep)
> + return 0;
> +
> + np = of_graph_get_remote_port_parent(ep);
> + of_node_put(ep);
> + if (!np) {
> + DRM_ERROR("failed to get remote port parent");
> + return -EINVAL;
> + }
> +
> + hdata->bridge = of_drm_find_bridge(np);
> + of_node_put(np);
> +
> + if (!hdata->bridge)
> + return -EPROBE_DEFER;
> +
> + return 0;
> +}
> +
> static int hdmi_resources_init(struct hdmi_context *hdata)
> {
> struct device *dev = hdata->dev;
> @@ -1630,17 +1665,18 @@ static int hdmi_resources_init(struct hdmi_context
> *hdata)
>
> hdata->reg_hdmi_en = devm_regulator_get_optional(dev, "hdmi-en");
>
> - if (PTR_ERR(hdata->reg_hdmi_en) == -ENODEV)
> - return 0;
> + if (PTR_ERR(hdata->reg_hdmi_en) != -ENODEV) {
> + if (IS_ERR(hdata->reg_hdmi_en))
> + return PTR_ERR(hdata->reg_hdmi_en);
>
> - if (IS_ERR(hdata->reg_hdmi_en))
> - return PTR_ERR(hdata->reg_hdmi_en);
> -
> - ret = regulator_enable(hdata->reg_hdmi_en);
> - if (ret)
> - DRM_ERROR("failed to enable hdmi-en regulator\n");
> + ret = regulator_enable(hdata->reg_hdmi_en);
> + if (ret) {
> + DRM_ERROR("failed to enable hdmi-en regulator\n");
> + return ret;
> + }
> + }
>
> - return ret;
> + return hdmi_bridge_init(hdata);
> }
>
> static struct of_device_id hdmi_match_types[] = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
2017년 02월 02일 04:03에 Sean Paul 이(가) 쓴 글: > On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote: >> On 1 February 2017 at 14:52, Thierry Reding wrote: >>> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: Thierry Reding writes: > [ Unknown signature status ] > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: >> Thierry Reding writes: >> >>> [ Unknown signature status ] >>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote: On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote: > On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: >> >> >> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: >>> Dear Thierry, >>> >>> Could you please review this patch? >> >> Thierry, I think this patch has been reviewed enough but no comment >> from you. Seems you are busy. I will pick up this. > > Sorry, but that's not how it works. This patch has gone through 8 > revisions within 4 weeks, and I tend to ignore patches like that until > the dust settles. > Seems like the dust was pretty settled. It was posted on 1/11, pinged on 1/24, and picked up on 1/31. I don't think it's unreasonable to take it through another tree after that. I wonder if drm_panel would benefit from the -misc group maintainership model as drm_bridge does. By spreading out the workload, the high-maintenance patches would hopefully find someone to shepherd them through. >>> >>> Except that nobody except me really cares. If we let people take patches >>> through separate trees or group-maintained trees they'll likely go in >>> without too much thought. DRM panel is somewhat different from core DRM >>> in this regard because its infrastructure is minimal and there's little >>> outside the panel-simple driver. So we're still at a stage where we need >>> to fine-tune what drivers should look like and how we can improve. >> >> I would love to care and participate in review, but with the structure >> of your tree you're the only one whose review counts, so I don't >> participate. > > Really? What exactly do you think is special about the structure of my > tree? I require patches to be on dri-devel (I pick them up from the > patchwork instance at freedesktop.org), the tree is publicly available > and reviewed-by tags get picked up automatically by patchwork. > > The panel tree works exactly like any other maintainer tree. And my > review is *not* the only one that counts. I appreciate every Reviewed-by > tag I see on panel patches because it means that I don't have to look as > closely as I have to otherwise. > > It is true that I am responsible for those patches, that's why I get to > have the final word on whether or not a patch gets applied. And that's > no different from any other maintainer tree either. If me reviewing a patch isn't part of unblocking that patch getting in, then I won't bother because all I could end up doing is punishing the developer of the patch. Contributors have a hard enough time already. >>> >>> Maybe you should go and read my previous reply again more carefully. >>> Perhaps then you'll realize that reviews are in fact helping in getting >>> patches merged. >>> >>> Interestingly my inbox doesn't show you ever bothering to review panel >>> patches, so maybe you should be more careful about your assumptions. >>> >> Gents, it's understandable that emotions might be running high. >> >> What's the point in pointing fingers at each other - there is enough >> to go in each direction. >> Let us all step back for a second and consider how we can make things better. >> > > Seems like I kicked up some dust here, for that I apologize. I certainly did > not > intend to diminish Thierry's (or anyone else's) role as maintainer. > > To put this as concisely as I can, I thought drm_panel would be a good > candidate > for -misc given: > - drm_bridge is already maintained there > - the drivers are small, and we just resolved to maintain small > drivers > in -misc > - new patches are blocked on a single reviewer/committer as opposed > to a > qualified committee (which I have come to understand is a feature in > this instance) Agree. drm_panel is not large enough to require another maintainer. However, we had already agreed that Thierry manages drm_panel, either implicitly or explicitly. Seems he's tired now and he wants to talk about this issue again on next Monday. At the meeting, I think we could decide whether going to group maintainership model, stay as-is or other better way, including reaching consensus. Thanks, Inki Dae > > So if we can't migrate it to
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
2017년 02월 02일 00:29에 Emil Velikov 이(가) 쓴 글: > On 1 February 2017 at 14:52, Thierry Reding wrote: >> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote: >>> Thierry Reding writes: >>> [ Unknown signature status ] On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > Thierry Reding writes: > >> [ Unknown signature status ] >> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote: >>> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote: On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: > > > 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: >> Dear Thierry, >> >> Could you please review this patch? > > Thierry, I think this patch has been reviewed enough but no comment > from you. Seems you are busy. I will pick up this. Sorry, but that's not how it works. This patch has gone through 8 revisions within 4 weeks, and I tend to ignore patches like that until the dust settles. >>> >>> Seems like the dust was pretty settled. It was posted on 1/11, pinged >>> on 1/24, >>> and picked up on 1/31. I don't think it's unreasonable to take it >>> through >>> another tree after that. >>> >>> I wonder if drm_panel would benefit from the -misc group maintainership >>> model >>> as drm_bridge does. By spreading out the workload, the high-maintenance >>> patches would hopefully find someone to shepherd them through. >> >> Except that nobody except me really cares. If we let people take patches >> through separate trees or group-maintained trees they'll likely go in >> without too much thought. DRM panel is somewhat different from core DRM >> in this regard because its infrastructure is minimal and there's little >> outside the panel-simple driver. So we're still at a stage where we need >> to fine-tune what drivers should look like and how we can improve. > > I would love to care and participate in review, but with the structure > of your tree you're the only one whose review counts, so I don't > participate. Really? What exactly do you think is special about the structure of my tree? I require patches to be on dri-devel (I pick them up from the patchwork instance at freedesktop.org), the tree is publicly available and reviewed-by tags get picked up automatically by patchwork. The panel tree works exactly like any other maintainer tree. And my review is *not* the only one that counts. I appreciate every Reviewed-by tag I see on panel patches because it means that I don't have to look as closely as I have to otherwise. It is true that I am responsible for those patches, that's why I get to have the final word on whether or not a patch gets applied. And that's no different from any other maintainer tree either. >>> >>> If me reviewing a patch isn't part of unblocking that patch getting in, >>> then I won't bother because all I could end up doing is punishing the >>> developer of the patch. Contributors have a hard enough time already. >> >> Maybe you should go and read my previous reply again more carefully. >> Perhaps then you'll realize that reviews are in fact helping in getting >> patches merged. >> >> Interestingly my inbox doesn't show you ever bothering to review panel >> patches, so maybe you should be more careful about your assumptions. >> > Gents, it's understandable that emotions might be running high. > > What's the point in pointing fingers at each other - there is enough > to go in each direction. > Let us all step back for a second and consider how we can make things better. > > I think it'll be nice to have some/most of the common concerns that > Thierry/others comes across documented - in-kernel, blog post, other. > Such that one can reference to specific points as patch falls sub-par. > We all want to have a balance of nicely written driver and quick > merge. > > Inki, I believe myself and others have invited you before on > #dri-devel. This is another medium where you can poke devs and from my > experience - it tends to be more efficient, most of the time. It's true and totally agree. I can really understand Thierry but I think we need to think about maintainer's role for our community. And also I think the big and small collisions between maintainers and contributors are just the process of getting better. Thanks, Inki Dae > > Thanks > Emil > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: scrambling support in drm layer
Regards
Shashank
On 2/2/2017 11:43 PM, Thierry Reding wrote:
On Thu, Feb 02, 2017 at 11:08:22AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:02 PM, Thierry Reding wrote:
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340Mhz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime using SCDC read.
- Two functions to enable/disable scrambling using SCDC read/write.
- Few new bools to reflect scrambling support and status.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 131
+++-
include/drm/drm_connector.h | 24
include/drm/drm_edid.h | 6 +-
3 files changed, 159 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 37902e5..f0d940a 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#define version_greater(edid, maj, min) \
(((edid)->version > (maj)) || \
@@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector
*connector,
}
}
+static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
+const u8 *hf_vsdb)
+{
+ struct drm_display_info *display = &connector->display_info;
+ struct drm_hdmi_info *hdmi = &display->hdmi_info;
+
+ /*
+* All HDMI 2.0 monitors must support scrambling at rates > 340M.
In comments below you use Mhz as the abbreviations. This should be
consistent. Also I think "MHz" is actually the correct spelling.
Agree.
+* And as per the spec, three factors confirm this:
+* * Availability of a HF-VSDB block in EDID (check)
+* * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
+* * SCDC support available
+* Lets check it out.
+*/
+
+ if (hf_vsdb[5]) {
+ display->max_tmds_clock = hf_vsdb[5] * 5000;
+ DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
+ display->max_tmds_clock);
+
+ if (hdmi->scdc_supported) {
+ hdmi->scr_info.supported = true;
+
+ /* Few sinks support scrambling for cloks < 340M */
+ if ((hf_vsdb[6] & 0x8))
+ hdmi->scr_info.low_clocks = true;
+ }
+ }
+}
+
+/**
+ * drm_check_scrambling_status - what is status of scrambling?
+ * @adapter: i2c adapter for SCDC channel
"I2C", same in other parts of this patch.
Got it.
+ *
+ * Read the scrambler status over SCDC channel, and check the
+ * scrambling status.
+ *
+ * Return: True if the scrambling is enabled, false otherwise.
I think the rest of DRM/KMS kerneldoc tries to use "Returns:\n" as a
standard way to document return values.
Ok.
+ */
+
+bool drm_check_scrambling_status(struct i2c_adapter *adapter)
Maybe use a drm_scdc_*() prefix for this to make it more consistent with
other SCDC API.
While at it, would this not be better located in drm_scdc.c along with
the other helpers? drm_edid.c is more focussed on the parsing aspects of
all things EDID.
Yeah, the same is mentioned by Ville too, will do that.
+{
+ u8 status;
+
+ if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status) < 0) {
How about storing the error code...
+ DRM_ERROR("Failed to read scrambling status\n");
... and making it part of the error message? Sometimes its useful to
know what exact error triggered this because it helps narrowing down
where things went wrong.
Agree, in fact while debugging and testing this patch series, I had to print
it explicitly.
+ return false;
+ }
+
+ status &= SCDC_SCRAMBLING_STATUS;
+ return status != 0;
Maybe make this a single line:
return (status & SCDC_SCRAMBLING_STATUS) != 0;
Got it.
+}
+
+/**
+ * drm_enable_scrambling - enable scrambling
+ * @connector: target drm_connector
"target DRM connector"?
Got it.
+ * @adapter: i2c adapter for SCDC channel
+ * @force: enable scrambling, even if its already enabled
+ *
+ * Write the TMDS config over SCDC channel, and enable scrambling
+ * Return: True if scrambling is successfully enabled, false otherwise.
+ */
+
+bool drm_enable_scrambling(struct drm_connector *connector,
+ struct i2c_adapter *adapter, bool force)
I think I'd move this to drm_scdc.c as well because it primarily
operates on SCDC. If you do so, might be worth making adapter the first
argument for consistency with other SCDC API.
Agree, will move it.
+{
+ u8 config;
+ struct drm_hdmi_info *hdmi_info = &connector->display_info.hdmi_info;
+
+ if (
[Bug 99488] [r600g]OpenCL driver causes ImageMagick to hang on JPEG input in Gaussian Blur kernel
https://bugs.freedesktop.org/show_bug.cgi?id=99488 --- Comment #3 from Jan Vesely --- (In reply to nixscripter from comment #1) > I'm still trying some versions in order to help you guys pin this down (it's > not always easy to tell what reinstall is having what effect, since Arch > Linux has three packages involved). In the mean time, I did the basics on > the process in its hung state. > > It's currently running three threads, two blocked, one continuing to run: > > (gdb) info threads > Id Target Id Frame > * 1Thread 0x39ac9cdf7c0 (LWP 3806) "display" 0x039abefef921 in > llvm::MachineInstr::findRegisterDefOperandIdx(unsigned int, bool, bool, > llvm::TargetRegisterInfo const*) const () from /usr/lib/libLLVM-5.0svn.so can you get backtrace of this thread? does it ever leave this function? you can check by adding breakpoint on that function and checking if it gets hit. this can be repeated going up the stack to find the function that won't exit. > 2Thread 0x39abd04f700 (LWP 3809) "radeon_cs:0" 0x039ac6b0310f in > pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 > 3Thread 0x39abadd4700 (LWP 3814) "display" futex_wait (val=8, > addr=0x25349d4) > at /build/gcc-multilib/src/gcc/libgomp/config/linux/x86/futex.h:44 > (gdb) > > > What is that call to findRegisterDefOperandIdx doing? there's a loop, it can't be infinite, but if the num of operands is corrupted, it can take a very long time to finish. can you check "p e" in gdb? > It's not entirely > clear, but it's sucking up a lot of memory. Running strace confirms that: > > strace: Process 3806 attached with 3 threads > strace: [ Process PID=3806 runs in x32 mode. ] > [pid 3809] futex(0x2599e64, FUTEX_WAIT_PRIVATE, 1, NULL > [pid 3814] futex(0x25349d4, FUTEX_WAIT_PRIVATE, 8, NULL > [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x640f4000 > strace: [ Process PID=3806 runs in 64 bit mode. ] > [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39a638f3000 > [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39a630f2000 > [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39a628f1000 > [...] > > And down the address space it goes, 0x1000 bytes (4k) a time or two per > second. the above mmaps show 8M (+4K, probably for bookkeeping) allocations. is there any other, not shown? I haven't found anything in the mentioned function that would need such big amount of memory, the hand if probably higher in the call stack. > > Looking at the function name, I'm thinking about what Jan said on another > bug: > > > the hang is probably a separate bug. ImageMagick test suite results on my > > Turks GPU are: > > # TOTAL: 86 > > # PASS: 78 > > # SKIP: 0 > > # XFAIL: 0 > > # FAIL: 3 > > # XPASS: 0 > > # ERROR: 5 > > > > the errors and failures are accompanied by: > > Assertion `i < getNumRegs() && "Register number out of range!"' failed. > > Could this be perhaps the same registers that were out of range on a > different card? all cards of one class have the same number of architecturally available registers. I see you have debug symbols, is that a debug build? if not, it can be that the assert is not hit, and the hang is just fallout. > > Either way, I will continue to investigate, and hope to narrow down the > issue soon. thanks. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99488] [r600g]OpenCL driver causes ImageMagick to hang on JPEG input in Gaussian Blur kernel
https://bugs.freedesktop.org/show_bug.cgi?id=99488 nixscrip...@gmail.com changed: What|Removed |Added Summary|[r600g]OpenCL driver causes |[r600g]OpenCL driver causes |process to hang in |ImageMagick to hang on JPEG |ImageMagick's Gaussian Blur |input in Gaussian Blur |kernel |kernel -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99488] [r600g]OpenCL driver causes process to hang in ImageMagick's Gaussian Blur kernel
https://bugs.freedesktop.org/show_bug.cgi?id=99488 --- Comment #2 from nixscrip...@gmail.com --- Correction on the steps to reproduce: 1. Get the current tree of ImageMagick from GitHub: https://github.com/ImageMagick/ImageMagick 2. Compile it with OpenCL and HDRI support (--enable-opencl --enable-hdri flags). 3. Create a JPEG image, and try to perform a simple Gaussian blur on it: convert rose: input.jpg && convert input.jpg -blur 0x20 output.jpg The blur does work for other image formats, strangely enough. Perhaps there is a difference in data types? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99488] [r600g]OpenCL driver causes process to hang in ImageMagick's Gaussian Blur kernel
https://bugs.freedesktop.org/show_bug.cgi?id=99488 --- Comment #1 from nixscrip...@gmail.com --- I'm still trying some versions in order to help you guys pin this down (it's not always easy to tell what reinstall is having what effect, since Arch Linux has three packages involved). In the mean time, I did the basics on the process in its hung state. It's currently running three threads, two blocked, one continuing to run: (gdb) info threads Id Target Id Frame * 1Thread 0x39ac9cdf7c0 (LWP 3806) "display" 0x039abefef921 in llvm::MachineInstr::findRegisterDefOperandIdx(unsigned int, bool, bool, llvm::TargetRegisterInfo const*) const () from /usr/lib/libLLVM-5.0svn.so 2Thread 0x39abd04f700 (LWP 3809) "radeon_cs:0" 0x039ac6b0310f in pthread_cond_wait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0 3Thread 0x39abadd4700 (LWP 3814) "display" futex_wait (val=8, addr=0x25349d4) at /build/gcc-multilib/src/gcc/libgomp/config/linux/x86/futex.h:44 (gdb) What is that call to findRegisterDefOperandIdx doing? It's not entirely clear, but it's sucking up a lot of memory. Running strace confirms that: strace: Process 3806 attached with 3 threads strace: [ Process PID=3806 runs in x32 mode. ] [pid 3809] futex(0x2599e64, FUTEX_WAIT_PRIVATE, 1, NULL [pid 3814] futex(0x25349d4, FUTEX_WAIT_PRIVATE, 8, NULL [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x640f4000 strace: [ Process PID=3806 runs in 64 bit mode. ] [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39a638f3000 [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39a630f2000 [pid 3806] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x39a628f1000 [...] And down the address space it goes, 0x1000 bytes (4k) a time or two per second. Looking at the function name, I'm thinking about what Jan said on another bug: > the hang is probably a separate bug. ImageMagick test suite results on my > Turks GPU are: > # TOTAL: 86 > # PASS: 78 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 3 > # XPASS: 0 > # ERROR: 5 > > the errors and failures are accompanied by: > Assertion `i < getNumRegs() && "Register number out of range!"' failed. Could this be perhaps the same registers that were out of range on a different card? Either way, I will continue to investigate, and hope to narrow down the issue soon. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-staging-4.9 5/14] ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.9 head: 99eb22d3eab149aa18e770da839165e07467db25 commit: 7adb2bbcdf7259533c5afc95c4a788b59bb59306 [5/14] drm/amd/display: DMCU Compile and Load config: i386-allmodconfig (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout 7adb2bbcdf7259533c5afc95c4a788b59bb59306 # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 Michel Dänzer changed: What|Removed |Added Attachment #129306|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 192271] kernel 4.9 hangs during shutdown or reboot
https://bugzilla.kernel.org/show_bug.cgi?id=192271 Richard Herbert changed: What|Removed |Added CC||rherb...@sympatico.ca --- Comment #5 from Richard Herbert --- Glad the patch made it into the latest kernel 4.9 (4.9.7). Same HD5770 as upcwteng. Thanks. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote: > On 01/02/17 22:05, Manasi Navare wrote: > >On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > >>Jani Nikula writes: > >> > >>>On Tue, 31 Jan 2017, Eric Anholt wrote: > Martin Peres writes: > > >Despite all the careful planing of the kernel, a link may become > >insufficient to handle the currently-set mode. At this point, the > >kernel should mark this particular configuration as being broken > >and potentially prune the mode before setting the offending connector's > >link-status to BAD and send the userspace a hotplug event. This may > >happen right after a modeset or later on. > > > >When available, we should use the link-status information to reset > >the wanted mode. > > > >Signed-off-by: Martin Peres > If I understand this right, there are two failure modes being handled: > > 1) A mode that won't actually work because the link isn't good enough. > > 2) A mode that should work, but link parameters were too optimistic and > if we just ask the kernel to set the mode again it'll use more > conservative parameters that work. > > This patch seems good for 2). For 1), the drmmode_set_mode_major is > going to set our old mode back. Won't the modeset then fail to link > train again, and bring us back into this loop? The only escape that I > see would be some other userspace responding to the advertised mode list > changing, and then asking X to modeset to something new. > > To avoid that failure busy loop, should we re-fetching modes at this > point, and only re-setting if our mode still exists? > >>>Disclaimer: I don't know anything about the internals of the modesetting > >>>driver. > >>> > >>>Perhaps we can identify the two cases now, but I'd put this more > >>>generally: if the link status has gone bad, it's an indicator to > >>>userspace that the circumstances may have changed, and userspace should > >>>query the kernel for the list of available modes again. It should no > >>>longer trust information obtained prior to getting the bad link status, > >>>including the current mode. > >>> > >>>But specifically, I think you're right, and AFAICT asking for the list > >>>of modes again is the only way for the userspace to distinguish between > >>>the two cases. I don't think there's a shortcut for deciding the current > >>>mode is still valid. > >>To avoid the busy-loop problem, I think I'd like this patch to re-query > >>the kernel to ask about the current mode list, and only try to re-set > >>the mode if our mode is still there. > >> > >>If the mode isn't there, then it's up to the DE to take action in > >>response to the notification of new modes. If you don't have a DE to > >>take appropriate action, you're kind of out of luck. > >> > >>As far as the ABI goes, this seems fine to me. The only concern I had > >>about ABI was having to walk all the connectors on every uevent to see > >>if any had gone bad -- couldn't we have a flag of some sort about what > >>the uevent indicates? But uevents should be super rare, so I'd say the > >>kernel could go ahead with the current plan. > >Yes I agree. The kernel sets the link status BAD as soona s link training > >fails > >but does not prune the modes until a new modelist is requested by the > >userspace. > >So this patch should re query the mode list as soon as it sees the link > >status > >BAD in order for the kernel to validate the modes again based on new link > >paarmeters and send a new mode list back. > > Seems like a bad behaviour from the kernel, isn't it? It should > return immediatly > if the mode is gonna be pruned :s The kernel only knows that the link was bad because link training failed so it sets the link status as BAD and sends a uevent expecting userspace to take action. It will not prune the modes unless drm_helper_probe_single_connector_modes is called by the userspace which would happen only when drmModeGetConnector call is initiated by userspace. So in your function too to read the link status you should do a drmModeGetConnector() that will probe the connector modes and validate and prune necessary modes, then if the link status is BAD handle it by two ways: 1. Modeset on the existing mode which will fail if the current mode was pruned already 2. If step 1 fails, then fetch the modes and this will be an updated mode list and modeset on the first mode in the list. This is how SNA driver implements this. Danvet/Jani, please correct me if I am wrong and suggest if pruning should be done by kernel instead before sending a uevent on link status BAD. Regards Manasi > > With the behaviour you are talking about, I should see 2 uevents > when injecting one > BAD link-state (first uevent generates a new modeset that will then > generate a BAD > state and another uevent, but this time the mode will have been > pruned so when > -modese
Re: [PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
2017-02-02 19:26 GMT-02:00 Fabio Estevam : > > From: Fabio Estevam > > Currently the framebuffer content is displayed with incorrect offsets > in both the vertical and horizontal directions. > > The fbdev version of the driver does not show this problem. Breno Lima > dumped the eLCDIF controller registers on both the drm and fbdev drivers > and noticed that the VDCTRL3 register is configured incorrectly in the > drm driver. > > The fbdev driver calculates the vertical and horizontal wait counts > of the VDCTRL3 register by doing: back porch + sync length. > > Looking at the horizontal and vertical timing diagram from > include/drm/drm_modes.h this value corresponds to: > > crtc_[hv]total - crtc_[hv]sync_start > > So fix the VDCTRL3 register setting accordingly so that the eLCDIF > controller can properly show the framebuffer content in the correct > position. > > Reported-by: Breno Lima > Signed-off-by: Fabio Estevam > --- > drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > index e10a4ed..b56f86c 100644 > --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c > @@ -184,8 +184,8 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) >VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal), >mxsfb->base + LCDC_VDCTRL2); > > - writel(SET_HOR_WAIT_CNT(m->crtc_hblank_end - m->crtc_hsync_end) | > - SET_VERT_WAIT_CNT(m->crtc_vblank_end - m->crtc_vsync_end), > + writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) | > + SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start), >mxsfb->base + LCDC_VDCTRL3); > > writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay), > -- > 2.7.4 > Tested-by: Breno Lima ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On 02/01/2017 05:51 PM, Peter Senna Tschudin wrote:
On 01 February, 2017 12:35 CET, Daniel Vetter wrote:
On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
Hi Archit,
On 01 February, 2017 10:44 CET, Archit Taneja wrote:
On 01/30/2017 10:35 PM, Jani Nikula wrote:
On Sat, 28 Jan 2017, Peter Senna Tschudin wrote:
On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
Hi Archit,
Thank you for the comments!
[...]
+ total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
+ if (total_size > EDID_LENGTH) {
+ kfree(block);
+ block = kmalloc(total_size, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ /* Yes, read the entire buffer, and do not skip the first
+* EDID_LENGTH bytes.
+*/
Is this the reason why you aren't using drm_do_get_edid()?
Yes, for some hw specific reason, it is necessary to read the entire
EDID buffer starting from 0, not block by block.
Hrmh, I'm planning on moving the edid override and firmware edid
mechanisms at the drm_do_get_edid() level to be able to truly and
transparently use a different edid. Currently, they're only used for
modes, really, and lead to some info retrieved from overrides, some from
the real edid. This kind of hacks will bypass the override/firmware edid
mechanisms then too. :(
It seems like there is a HW issue which prevents them from reading EDID
from an offset. So, I'm not sure if it is a hack or a HW limitation.
One way around this would be to hide the HW requirement in the
get_edid_block func pointer passed to drm_do_get_edid(). This
would, however, result in more i2c reads (equal to # of extension
blocks) than what the patch currently does.
Peter, if you think doing extra EDID reads isn't too costly on your
platform, you could consider using drm_do_get_edid(). If not, I guess
you'll miss out on the additional functionality Jani is going to add
in the future.
My concern is that for almost one year now, every time I fix something
one or two new requests are made. I'm happy to fix the driver, but I
want a list of the changes that are required to get it upstream, before
I make more changes. Can we agree on exactly what is preventing this
driver to get upstream? Then I'll fix it.
I think addressing this edid reading question post-merge is perfectly
fine. Aside, want to keep maintaing your stuff as part of the drm-misc
group, with the drivers-in-misc experiment?
The edid thing was only a suggestion. As Daniel said, it's okay to work on
it post merge.
Please do fix the minor comments I mentioned in the latest patch set. I'll
pull in the first 3 patches once Rob H gives an Ack on the DT bindings
patch. The 4th patch needs to go through the SoC maintainer.
Thanks,
Archit
Yes, sure!
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
TFT with Touch-Panel, which can be supported by the simple panel driver.
Data-sheet available at:
http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
Signed-off-by: Breno Lima
---
.../bindings/display/panel/sii,43wvf1g.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 28 ++
2 files changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
diff --git a/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
new file mode 100644
index 000..bbbc49f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
@@ -0,0 +1,7 @@
+Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
+
+Required properties:
+- compatible: should be "sii,43wvf1g"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 06aaf79..0e08c56 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -863,6 +863,31 @@ static const struct panel_desc hannstar_hsd070pww1 = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
};
+static const struct display_timing sii_43wvf1g_timing = {
+ .pixelclock = { 3350, 3350, 3350 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 164, 164, 164 },
+ .hback_porch = { 89, 89, 89 },
+ .hsync_len = { 10, 10, 10 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 10, 10, 10 },
+ .vback_porch = { 23, 23, 23 },
+ .vsync_len = { 10, 10, 10 },
+ .flags = DISPLAY_FLAGS_DE_LOW,
+};
+
+static const struct panel_desc sii_43wvf1g = {
+ .timings = &sii_43wvf1g_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 93,
+ .height = 57,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+};
+
static const struct display_timing hannstar_hsd100pxn1_timing = {
.pixelclock = { 5500, 6500, 7500 },
.hactive = { 1024, 1024, 1024 },
@@ -1853,6 +1878,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "samsung,ltn140at29-301",
.data = &samsung_ltn140at29_301,
}, {
+ .compatible = "sii,43wvf1g",
+ .data = &sii_43wvf1g,
+ }, {
.compatible = "sharp,lq101k1ly04",
.data = &sharp_lq101k1ly04,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: change connector disconnected debug message to an error
On 02/02/2017 01:32 AM, Jani Nikula wrote:
> On Thu, 02 Feb 2017, Shuah Khan wrote:
>> Change drm_helper_probe_single_connector_modes() to print an error to
>> report connector disconnected status instead of a debug message.
>>
>> When this condition occurs, application doesn't know the real error and
>> reports it as driver lacking support for mode setting. Change it to an
>> error to make it easier to debug.
>
> Please explain what makes this condition an error. Connectors get
> connected and disconnected, business as usual, why should this be an
> error?
>
> BR,
> Jani.
Disconnecting connector itself isn't an error. When user-space tries
to access it, it would be useful to report the status that the connector
is disconnected.
I use embedded system(s) that don't like it when HDMI is hot added or
removed. Also, because of return power, it is safer to disconnect HDMI
and then apply power to the board. It chased a few libdrm and user-space
dead ends before I enabled drm debug and was able to fix the real issue,
which is a disconnected cable.
User-space prints rather confusing messages as it doesn't really know
the disconnected status as it isn't returned to it.
I figured it might be a good idea to at least print a message and this can
be a notice or info instead of an error. I do think its is worth while in
some cases.
thanks,
-- Shuah
>
>
>>
>> Signed-off-by: Shuah Khan
>> ---
>> drivers/gpu/drm/drm_probe_helper.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index ac953f0..6472b7f 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -282,8 +282,8 @@ int drm_helper_probe_single_connector_modes(struct
>> drm_connector *connector,
>> dev->mode_config.poll_running = drm_kms_helper_poll;
>>
>> if (connector->status == connector_status_disconnected) {
>> -DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
>> -connector->base.id, connector->name);
>> +DRM_ERROR("[CONNECTOR:%d:%s] disconnected\n",
>> + connector->base.id, connector->name);
>> drm_mode_connector_update_edid_property(connector, NULL);
>> verbose_prune = false;
>> goto prune;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On 02 February, 2017 02:46 CET, Emil Velikov wrote:
> On 1 February 2017 at 11:35, Daniel Vetter wrote:
> > On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
> >> Hi Archit,
> >>
> >> On 01 February, 2017 10:44 CET, Archit Taneja
> >> wrote:
> >>
> >> >
> >> >
> >> > On 01/30/2017 10:35 PM, Jani Nikula wrote:
> >> > > On Sat, 28 Jan 2017, Peter Senna Tschudin
> >> > > wrote:
> >> > >> On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
> >> > >> Hi Archit,
> >> > >>
> >> > >> Thank you for the comments!
> >> > >>
> >> > >> [...]
> >> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
> >> > + if (total_size > EDID_LENGTH) {
> >> > + kfree(block);
> >> > + block = kmalloc(total_size, GFP_KERNEL);
> >> > + if (!block)
> >> > + return NULL;
> >> > +
> >> > + /* Yes, read the entire buffer, and do not skip the
> >> > first
> >> > + * EDID_LENGTH bytes.
> >> > + */
> >> > >>>
> >> > >>> Is this the reason why you aren't using drm_do_get_edid()?
> >>
> >> > >>
> >> > >> Yes, for some hw specific reason, it is necessary to read the entire
> >> > >> EDID buffer starting from 0, not block by block.
> >> > >
> >> > > Hrmh, I'm planning on moving the edid override and firmware edid
> >> > > mechanisms at the drm_do_get_edid() level to be able to truly and
> >> > > transparently use a different edid. Currently, they're only used for
> >> > > modes, really, and lead to some info retrieved from overrides, some
> >> > > from
> >> > > the real edid. This kind of hacks will bypass the override/firmware
> >> > > edid
> >> > > mechanisms then too. :(
> >> >
> >> > It seems like there is a HW issue which prevents them from reading EDID
> >> > from an offset. So, I'm not sure if it is a hack or a HW limitation.
> >>
> >> >
> >> > One way around this would be to hide the HW requirement in the
> >> > get_edid_block func pointer passed to drm_do_get_edid(). This
> >> > would, however, result in more i2c reads (equal to # of extension
> >> > blocks) than what the patch currently does.
> >> >
> >> > Peter, if you think doing extra EDID reads isn't too costly on your
> >> > platform, you could consider using drm_do_get_edid(). If not, I guess
> >> > you'll miss out on the additional functionality Jani is going to add
> >>
> >> > in the future.
> >>
> >> My concern is that for almost one year now, every time I fix something
> >> one or two new requests are made. I'm happy to fix the driver, but I
> >> want a list of the changes that are required to get it upstream, before
> >> I make more changes. Can we agree on exactly what is preventing this
> >> driver to get upstream? Then I'll fix it.
> >
> > I think addressing this edid reading question post-merge is perfectly
> > fine. Aside, want to keep maintaing your stuff as part of the drm-misc
> > group, with the drivers-in-misc experiment?
>
> Wasn't there some entry level for people ? It's not like Peter is
> thick or anything, just that he has not reviewed or replied (afaict)
> to any patches, even on ones where he was explicitly cc'd.
> Although he's got dozens of contributions elsewhere, there's only a
> single patch of his in DRM.
"Any" is an exaggeration. See:
c6c1f9bc798bee7cf
...
Tested-by: Peter Senna Tschudin
Even if my involvement with drm started with my driver last year, I took my
personal time to report this issue, and to test multiple iterations of the fix.
Then my "single patch in DRM" involved some work to get it right, and it is
something, that made imx-ldb better by adding a feature it did not support
before.
You made me curious. Can you point to the explicit cases where Peter "has not
reviewed or replied to any patches, even on ones where he was explicitly cc'd"?
And can you list case by case your take on why I should have done differently?
Also it is not clear to me what the problem really is here. I'm assuming is not
me, but if I was qualified from your perspective then would be no problem,
right?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On 1 February 2017 at 11:35, Daniel Vetter wrote:
> On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
>> Hi Archit,
>>
>> On 01 February, 2017 10:44 CET, Archit Taneja wrote:
>>
>> >
>> >
>> > On 01/30/2017 10:35 PM, Jani Nikula wrote:
>> > > On Sat, 28 Jan 2017, Peter Senna Tschudin
>> > > wrote:
>> > >> On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
>> > >> Hi Archit,
>> > >>
>> > >> Thank you for the comments!
>> > >>
>> > >> [...]
>> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
>> > + if (total_size > EDID_LENGTH) {
>> > + kfree(block);
>> > + block = kmalloc(total_size, GFP_KERNEL);
>> > + if (!block)
>> > + return NULL;
>> > +
>> > + /* Yes, read the entire buffer, and do not skip the
>> > first
>> > + * EDID_LENGTH bytes.
>> > + */
>> > >>>
>> > >>> Is this the reason why you aren't using drm_do_get_edid()?
>>
>> > >>
>> > >> Yes, for some hw specific reason, it is necessary to read the entire
>> > >> EDID buffer starting from 0, not block by block.
>> > >
>> > > Hrmh, I'm planning on moving the edid override and firmware edid
>> > > mechanisms at the drm_do_get_edid() level to be able to truly and
>> > > transparently use a different edid. Currently, they're only used for
>> > > modes, really, and lead to some info retrieved from overrides, some from
>> > > the real edid. This kind of hacks will bypass the override/firmware edid
>> > > mechanisms then too. :(
>> >
>> > It seems like there is a HW issue which prevents them from reading EDID
>> > from an offset. So, I'm not sure if it is a hack or a HW limitation.
>>
>> >
>> > One way around this would be to hide the HW requirement in the
>> > get_edid_block func pointer passed to drm_do_get_edid(). This
>> > would, however, result in more i2c reads (equal to # of extension
>> > blocks) than what the patch currently does.
>> >
>> > Peter, if you think doing extra EDID reads isn't too costly on your
>> > platform, you could consider using drm_do_get_edid(). If not, I guess
>> > you'll miss out on the additional functionality Jani is going to add
>>
>> > in the future.
>>
>> My concern is that for almost one year now, every time I fix something
>> one or two new requests are made. I'm happy to fix the driver, but I
>> want a list of the changes that are required to get it upstream, before
>> I make more changes. Can we agree on exactly what is preventing this
>> driver to get upstream? Then I'll fix it.
>
> I think addressing this edid reading question post-merge is perfectly
> fine. Aside, want to keep maintaing your stuff as part of the drm-misc
> group, with the drivers-in-misc experiment?
Wasn't there some entry level for people ? It's not like Peter is
thick or anything, just that he has not reviewed or replied (afaict)
to any patches, even on ones where he was explicitly cc'd.
Although he's got dozens of contributions elsewhere, there's only a
single patch of his in DRM.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: change connector disconnected debug message to an error
Change drm_helper_probe_single_connector_modes() to print an error to
report connector disconnected status instead of a debug message.
When this condition occurs, application doesn't know the real error and
reports it as driver lacking support for mode setting. Change it to an
error to make it easier to debug.
Signed-off-by: Shuah Khan
---
drivers/gpu/drm/drm_probe_helper.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index ac953f0..6472b7f 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -282,8 +282,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
dev->mode_config.poll_running = drm_kms_helper_poll;
if (connector->status == connector_status_disconnected) {
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
- connector->base.id, connector->name);
+ DRM_ERROR("[CONNECTOR:%d:%s] disconnected\n",
+ connector->base.id, connector->name);
drm_mode_connector_update_edid_property(connector, NULL);
verbose_prune = false;
goto prune;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On 2 February 2017 at 11:53, Peter Senna Tschudin
wrote:
>
> On 02 February, 2017 02:46 CET, Emil Velikov wrote:
>
>> On 1 February 2017 at 11:35, Daniel Vetter wrote:
>> > On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
>> >> Hi Archit,
>> >>
>> >> On 01 February, 2017 10:44 CET, Archit Taneja
>> >> wrote:
>> >>
>> >> >
>> >> >
>> >> > On 01/30/2017 10:35 PM, Jani Nikula wrote:
>> >> > > On Sat, 28 Jan 2017, Peter Senna Tschudin
>> >> > > wrote:
>> >> > >> On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
>> >> > >> Hi Archit,
>> >> > >>
>> >> > >> Thank you for the comments!
>> >> > >>
>> >> > >> [...]
>> >> > + total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
>> >> > + if (total_size > EDID_LENGTH) {
>> >> > + kfree(block);
>> >> > + block = kmalloc(total_size, GFP_KERNEL);
>> >> > + if (!block)
>> >> > + return NULL;
>> >> > +
>> >> > + /* Yes, read the entire buffer, and do not skip the
>> >> > first
>> >> > + * EDID_LENGTH bytes.
>> >> > + */
>> >> > >>>
>> >> > >>> Is this the reason why you aren't using drm_do_get_edid()?
>> >>
>> >> > >>
>> >> > >> Yes, for some hw specific reason, it is necessary to read the entire
>> >> > >> EDID buffer starting from 0, not block by block.
>> >> > >
>> >> > > Hrmh, I'm planning on moving the edid override and firmware edid
>> >> > > mechanisms at the drm_do_get_edid() level to be able to truly and
>> >> > > transparently use a different edid. Currently, they're only used for
>> >> > > modes, really, and lead to some info retrieved from overrides, some
>> >> > > from
>> >> > > the real edid. This kind of hacks will bypass the override/firmware
>> >> > > edid
>> >> > > mechanisms then too. :(
>> >> >
>> >> > It seems like there is a HW issue which prevents them from reading EDID
>> >> > from an offset. So, I'm not sure if it is a hack or a HW limitation.
>> >>
>> >> >
>> >> > One way around this would be to hide the HW requirement in the
>> >> > get_edid_block func pointer passed to drm_do_get_edid(). This
>> >> > would, however, result in more i2c reads (equal to # of extension
>> >> > blocks) than what the patch currently does.
>> >> >
>> >> > Peter, if you think doing extra EDID reads isn't too costly on your
>> >> > platform, you could consider using drm_do_get_edid(). If not, I guess
>> >> > you'll miss out on the additional functionality Jani is going to add
>> >>
>> >> > in the future.
>> >>
>> >> My concern is that for almost one year now, every time I fix something
>> >> one or two new requests are made. I'm happy to fix the driver, but I
>> >> want a list of the changes that are required to get it upstream, before
>> >> I make more changes. Can we agree on exactly what is preventing this
>> >> driver to get upstream? Then I'll fix it.
>> >
>> > I think addressing this edid reading question post-merge is perfectly
>> > fine. Aside, want to keep maintaing your stuff as part of the drm-misc
>> > group, with the drivers-in-misc experiment?
>>
>> Wasn't there some entry level for people ? It's not like Peter is
>> thick or anything, just that he has not reviewed or replied (afaict)
>
>> to any patches, even on ones where he was explicitly cc'd.
>> Although he's got dozens of contributions elsewhere, there's only a
>> single patch of his in DRM.
>
> "Any" is an exaggeration. See:
>
> c6c1f9bc798bee7cf
> ...
> Tested-by: Peter Senna Tschudin
>
> Even if my involvement with drm started with my driver last year, I took my
> personal time to report this issue, and to test multiple iterations of the
> fix. Then my "single patch in DRM" involved some work to get it right, and it
> is something, that made imx-ldb better by adding a feature it did not support
> before.
>
> You made me curious. Can you point to the explicit cases where Peter "has not
> reviewed or replied to any patches, even on ones where he was explicitly
> cc'd"? And can you list case by case your take on why I should have done
> differently?
>
> Also it is not clear to me what the problem really is here. I'm assuming is
> not me, but if I was qualified from your perspective then would be no
> problem, right?
>
Ok seems like my wording came out, rather off.
Peter, as mentioned on IRC my messages is not aimed to be picking on
you in the slightest way. Pardon if it came as such.
It had two main points:
- Daniel, gents - is drm-misc aimed at devs with limited (no?)
review/commit history in the area and/or the kernel in general ?
In this case, Peter have quite noticeable experience [in kernel
development] with little-to no in DRM.
Should one draw a line in the sand somewhere ?
- You patch has been on a long [bit rocky road] for a while, with
devs giving you [what seems like] a partial reviews.
Have you considered reviewing others' patches in exchange for a [more
complete
[PATCH] drm/i915: fix i915 running as dom0 under Xen
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption similar to that done in
commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().
So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.
Signed-off-by: Juergen Gross
---
Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
with i915 graphics.
---
drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 4b3ff3e..d09c749 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
- max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
+ if (swiotlb_nr_tbl()) {
+ unsigned int max_segment;
+
+ max_segment = swiotlb_max_segment();
+ if (max_segment) {
+ max_segment = max_t(unsigned int, max_segment,
+ PAGE_SIZE) >> PAGE_SHIFT;
+ max_order = min(max_order, ilog2(max_segment));
+ }
+ }
#endif
gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
--
2.10.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: simple: ensure Sharp lq123p1jx31 isn't turned off too soon
The Sharp lq123p1jx31 has a requirement that the VDD is on for at
least 300 ms before being turned off. At the moment nothing anywhere
in the kernel is ensuring this.
The simplest way to ensure this is to add a "disable" timing of 150
ms. With this the we know that there will be at least 300 ms between
the regulator/gpio being turned on and being turned off.
Specifically, here's what happens after this change:
* prepare: enable regulator, delay 110 ms (10 for regulator, then 100)
* enable: delay 50 ms
* disable: delay 150 ms, then disable regulator
* unprepare: delay 550 ms (50 for regulator, 500 to off=>on too quick)
As you can see, even giving the regulator 10 ms (the max the panel
spec allows) for ramping up we are sure that the regulator was on for
300 ms now.
Signed-off-by: Douglas Anderson
---
drivers/gpu/drm/panel/panel-simple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 89eb0422821c..dbaadfa6b823 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1622,6 +1622,7 @@ static const struct panel_desc sharp_lq123p1jx31 = {
.delay = {
.prepare = 110,
.enable = 50,
+ .disable = 150,
.unprepare = 550,
},
};
--
2.11.0.483.g087da7b7c-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On 01/02/17 22:05, Manasi Navare wrote: On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: Jani Nikula writes: On Tue, 31 Jan 2017, Eric Anholt wrote: Martin Peres writes: Despite all the careful planing of the kernel, a link may become insufficient to handle the currently-set mode. At this point, the kernel should mark this particular configuration as being broken and potentially prune the mode before setting the offending connector's link-status to BAD and send the userspace a hotplug event. This may happen right after a modeset or later on. When available, we should use the link-status information to reset the wanted mode. Signed-off-by: Martin Peres If I understand this right, there are two failure modes being handled: 1) A mode that won't actually work because the link isn't good enough. 2) A mode that should work, but link parameters were too optimistic and if we just ask the kernel to set the mode again it'll use more conservative parameters that work. This patch seems good for 2). For 1), the drmmode_set_mode_major is going to set our old mode back. Won't the modeset then fail to link train again, and bring us back into this loop? The only escape that I see would be some other userspace responding to the advertised mode list changing, and then asking X to modeset to something new. To avoid that failure busy loop, should we re-fetching modes at this point, and only re-setting if our mode still exists? Disclaimer: I don't know anything about the internals of the modesetting driver. Perhaps we can identify the two cases now, but I'd put this more generally: if the link status has gone bad, it's an indicator to userspace that the circumstances may have changed, and userspace should query the kernel for the list of available modes again. It should no longer trust information obtained prior to getting the bad link status, including the current mode. But specifically, I think you're right, and AFAICT asking for the list of modes again is the only way for the userspace to distinguish between the two cases. I don't think there's a shortcut for deciding the current mode is still valid. To avoid the busy-loop problem, I think I'd like this patch to re-query the kernel to ask about the current mode list, and only try to re-set the mode if our mode is still there. If the mode isn't there, then it's up to the DE to take action in response to the notification of new modes. If you don't have a DE to take appropriate action, you're kind of out of luck. As far as the ABI goes, this seems fine to me. The only concern I had about ABI was having to walk all the connectors on every uevent to see if any had gone bad -- couldn't we have a flag of some sort about what the uevent indicates? But uevents should be super rare, so I'd say the kernel could go ahead with the current plan. Yes I agree. The kernel sets the link status BAD as soona s link training fails but does not prune the modes until a new modelist is requested by the userspace. So this patch should re query the mode list as soon as it sees the link status BAD in order for the kernel to validate the modes again based on new link paarmeters and send a new mode list back. Seems like a bad behaviour from the kernel, isn't it? It should return immediatly if the mode is gonna be pruned :s With the behaviour you are talking about, I should see 2 uevents when injecting one BAD link-state (first uevent generates a new modeset that will then generate a BAD state and another uevent, but this time the mode will have been pruned so when -modesetting tries to set the mode, it will fail immediatly). During my testing, I do not remember seeing such behaviour, so the kernel seemed to be doing the right thing from my PoV (failing a modeset to a mode that is known not to be achievable). I can verify tommorow, but it would be nice to make sure it is part of the ABI. As for re-fetching the modes, this is something the DE will do anyway when asking for them via randr. So, really, that will generate double probing in the common case for what seems to be a workaround. Given that probing can be a super expensive operation (request EDID from all monitors, potentially first starting up powered-down GPUs such as NVIDIA or AMD), I would say that probing should not be taken lightly. Isn't it possible to just return an error from the kernel if the mode should disapear? As far as my testing goes, this was already what seemed to be happening... but I may be wrong, especially since my DP monitor was fine with no link training whatsoever. What is the current ABI for the userspace requesting a mode from a previous monitor to a new one, because it did not reprobe? In any case, this is a good discussion to have! Remember that it could still not prune any mode if the same mode is valid with lower bpp, it will still keep the mode list same and when the userspace retries the same mode, it will do a modeset at lower bpp (say 18bpp) an
[git pull] drm fixes for 4.10-rc7
Hi Linus, Another fixes pull for v4.10, it's a bit big due to the backport of the VMA fixes for i915 that should fix the oops on shutdown problems that you've worked around. There are also two drm core connector registration fixes, a bunch of nouveau regression fixes and two AMD fixes. Dave. The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637: Linux 4.10-rc6 (2017-01-29 14:25:17 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.10-rc7 for you to fetch changes up to f63cf464fc379382a271f94ddef36e8c5a0628eb: Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-02-03 09:10:08 +1000) intel vma fixes, amd and nouveau fixes. Alastair Bridgewater (1): drm/nouveau/disp/gt215: Fix HDA ELD handling (thus, HDMI audio) on gt215 Alex Deucher (1): drm/amdgpu/si: fix crash on headless asics Ben Skeggs (4): drm/nouveau/fence/g84-: protect against concurrent access to semaphore buffers drm/nouveau: prevent userspace from deleting client object drm/nouveau/disp/mcp7x: disable dptmds workaround drm/nouveau/kms/nv50: request vblank events for commits that send completion events Chris Wilson (1): drm/i915: Track pinned vma in intel_plane_state Daniel Vetter (2): drm: prevent double-(un)registration for connectors drm: Don't race connector registration Dave Airlie (4): Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-fixes Merge tag 'drm-misc-fixes-2017-01-31' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'topic/vma-fix-for-4.10-2017-02-02' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Ilia Mirkin (1): drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval Maarten Lankhorst (2): drm/atomic: Fix double free in drm_atomic_state_default_clear drm/atomic: Unconditionally call prepare_fb. Martin Peres (1): drm/nouveau/nouveau/led: prevent compiling the led-code if nouveau=y and leds=m Michel Dänzer (1): drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 4 +- drivers/gpu/drm/drm_atomic.c | 13 ++- drivers/gpu/drm/drm_atomic_helper.c| 9 -- drivers/gpu/drm/drm_connector.c| 23 +++- drivers/gpu/drm/drm_drv.c | 4 + drivers/gpu/drm/i915/i915_drv.h| 16 +-- drivers/gpu/drm/i915/intel_atomic_plane.c | 20 drivers/gpu/drm/i915/intel_display.c | 125 +++-- drivers/gpu/drm/i915/intel_drv.h | 9 +- drivers/gpu/drm/i915/intel_fbc.c | 52 - drivers/gpu/drm/i915/intel_fbdev.c | 4 +- drivers/gpu/drm/i915/intel_sprite.c| 8 +- drivers/gpu/drm/nouveau/dispnv04/hw.c | 3 +- drivers/gpu/drm/nouveau/nouveau_fence.h| 1 + drivers/gpu/drm/nouveau/nouveau_led.h | 2 +- drivers/gpu/drm/nouveau/nouveau_usif.c | 3 +- drivers/gpu/drm/nouveau/nv50_display.c | 6 + drivers/gpu/drm/nouveau/nv84_fence.c | 6 + .../gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c| 2 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c| 2 - drivers/gpu/drm/radeon/radeon_drv.c| 3 +- drivers/gpu/drm/radeon/radeon_gem.c| 4 +- include/drm/drmP.h | 1 + include/drm/drm_connector.h| 16 ++- 24 files changed, 171 insertions(+), 165 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] intel: avoid null pointer dereference
Introduced in 028715ee Move the dereference after the null check. --- intel/intel_decode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index 803d202..2721ffd 100644 --- a/intel/intel_decode.c +++ b/intel/intel_decode.c @@ -3899,7 +3899,7 @@ drm_intel_decode(struct drm_intel_decode *ctx) int ret; unsigned int index = 0; uint32_t devid; - int size = ctx->base_count * 4; + int size; void *temp; if (!ctx) @@ -3909,6 +3909,7 @@ drm_intel_decode(struct drm_intel_decode *ctx) * the batchbuffer. This lets us avoid a bunch of length * checking in statically sized packets. */ + size = ctx->base_count * 4; temp = malloc(size + 4096); memcpy(temp, ctx->base_data, size); memset((char *)temp + size, 0xd0, 4096); -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #13 from Steven A. Falco --- I successfully built a custom kernel. It appears to be working well. Thanks for the help! I included a new dmesg.log file because I still see messages like: [9.719278] amdgpu: [powerplay] failed to send pre message 15b ret is 0 [ 10.158327] amdgpu: [powerplay] failed to send message 15b ret is 0 Are these harmless or do they indicate a problem? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #14 from Steven A. Falco --- One other error message I just noticed: [5.538117] amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #12 from Steven A. Falco --- Created attachment 253891 --> https://bugzilla.kernel.org/attachment.cgi?id=253891&action=edit New dmesg file -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/3] drm/amd/display: Switch to using atomic_helper for flip.
v2:
Modify for movig pflip flags to crtc_state
v4:
Fix identation.
v5:
Rename field to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 +
2 files changed, 24 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 4c0a86e..3ff3c14 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -443,7 +443,6 @@ struct amdgpu_crtc {
enum amdgpu_interrupt_state vsync_timer_enabled;
int otg_inst;
- uint32_t flip_flags;
/* After Set Mode target will be non-NULL */
struct dc_target *target;
};
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index a443b70..81c46d6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -1060,83 +1060,6 @@ static int dm_crtc_funcs_atomic_set_property(
return 0;
}
-
-static int amdgpu_atomic_helper_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event,
- uint32_t flags)
-{
- struct drm_plane *plane = crtc->primary;
- struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
- struct drm_atomic_state *state;
- struct drm_plane_state *plane_state;
- struct drm_crtc_state *crtc_state;
- int ret = 0;
-
- state = drm_atomic_state_alloc(plane->dev);
- if (!state)
- return -ENOMEM;
-
- ret = drm_crtc_vblank_get(crtc);
- if (ret)
- return ret;
-
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
-retry:
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state)) {
- ret = PTR_ERR(crtc_state);
- goto fail;
- }
- crtc_state->event = event;
-
- plane_state = drm_atomic_get_plane_state(state, plane);
- if (IS_ERR(plane_state)) {
- ret = PTR_ERR(plane_state);
- goto fail;
- }
-
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
- if (ret != 0)
- goto fail;
- drm_atomic_set_fb_for_plane(plane_state, fb);
-
- /* Make sure we don't accidentally do a full modeset. */
- state->allow_modeset = false;
- if (!crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
-crtc->base.id);
- ret = -EINVAL;
- goto fail;
- }
- acrtc->flip_flags = flags;
-
- ret = drm_atomic_nonblocking_commit(state);
-
-fail:
- if (ret == -EDEADLK)
- goto backoff;
-
- if (ret)
- drm_crtc_vblank_put(crtc);
-
- drm_atomic_state_put(state);
-
- return ret;
-backoff:
- drm_atomic_state_clear(state);
- drm_atomic_legacy_backoff(state);
-
- /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
- plane->old_fb = plane->fb;
-
- goto retry;
-}
-
/* Implemented only the options currently availible for the driver */
static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
@@ -1145,7 +1068,7 @@ static int amdgpu_atomic_helper_page_flip(struct drm_crtc
*crtc,
.destroy = amdgpu_dm_crtc_destroy,
.gamma_set = amdgpu_dm_atomic_crtc_gamma_set,
.set_config = drm_atomic_helper_set_config,
- .page_flip = amdgpu_atomic_helper_page_flip,
+ .page_flip_target = drm_atomic_helper_page_flip_target,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.atomic_set_property = dm_crtc_funcs_atomic_set_property
@@ -1626,7 +1549,8 @@ static void clear_unrelated_fields(struct drm_plane_state
*state)
static bool page_flip_needed(
const struct drm_plane_state *new_state,
const struct drm_plane_state *old_state,
- bool commit_surface_required)
+ bool commit_surface_required,
+ uint32_t pflip_flags)
{
struct drm_plane_state old_state_tmp;
struct drm_plane_state new_state_tmp;
@@ -1679,7 +1603,7 @@ static bool page_flip_needed(
sizeof(old_state_tmp)) == 0 ? true:false;
if (new_state->crtc && page_flip_required == false) {
acrtc_new = to_amdgpu_crtc(new_state->crtc);
- if (acrtc_new->flip_flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ if
[PATCH v5 0/3] Allow ASYNC flip with atomic helpers.
This series is a folow-up on https://patchwork.kernel.org/patch/9501787/ The first patch makes changes to atomic helpers to allow for drives with ASYNC flip support to use them. Patch 2 is to use this in AMDGPU/DC. Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the helper as we did to support ASYNC flips. v2: Resend drm/atomic: Save flip flags in drm_plane_state since the original patch was incomplete. Squash 2 AMD changes into one to not break compilation. v3: Following Daniel's comments, save flip flags in crtc_state instead of plane_state. v4: Lauren's comment, reset flp flags before using again. Harry's comment, fix identation in amd/display. v5: Rename the flag, fix typo in header. Andrey Grodzovsky (3): drm/atomic: Save flip flags in drm_crtc_state drm/nouveau/kms/nv50: Switch to using atomic helper for flip. drm/amd/display: Switch to using atomic_helper for flip. drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 + drivers/gpu/drm/drm_atomic_helper.c| 20 ++-- drivers/gpu/drm/nouveau/nv50_display.c | 84 ++- include/drm/drm_crtc.h | 9 +- 5 files changed, 48 insertions(+), 179 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/3] drm/nouveau/kms/nv50: Switch to using atomic helper for flip.
v2:
Update code after flip_flags moved from plane_state
to crtc_state
v5:
Rename to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/nouveau/nv50_display.c | 84 --
1 file changed, 10 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 2c2c645..c6153d3 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -831,7 +831,8 @@ struct nv50_wndw_func {
static int
nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw,
struct nv50_wndw_atom *asyw,
- struct nv50_head_atom *asyh)
+ struct nv50_head_atom *asyh,
+ u32 pflip_flags)
{
struct nouveau_framebuffer *fb = nouveau_framebuffer(asyw->state.fb);
struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
@@ -846,6 +847,9 @@ struct nv50_wndw_func {
asyw->image.w = fb->base.width;
asyw->image.h = fb->base.height;
asyw->image.kind = (fb->nvbo->tile_flags & 0xff00) >> 8;
+
+ asyw->interval = pflip_flags & DRM_MODE_PAGE_FLIP_ASYNC ? 0 : 1;
+
if (asyw->image.kind) {
asyw->image.layout = 0;
if (drm->device.info.chipset >= 0xc0)
@@ -883,6 +887,7 @@ struct nv50_wndw_func {
struct nv50_head_atom *harm = NULL, *asyh = NULL;
bool varm = false, asyv = false, asym = false;
int ret;
+ u32 pflip_flags = 0;
NV_ATOMIC(drm, "%s atomic_check\n", plane->name);
if (asyw->state.crtc) {
@@ -891,6 +896,7 @@ struct nv50_wndw_func {
return PTR_ERR(asyh);
asym = drm_atomic_crtc_needs_modeset(&asyh->state);
asyv = asyh->state.active;
+ pflip_flags = asyh->state.pageflip_flags;
}
if (armw->state.crtc) {
@@ -907,7 +913,8 @@ struct nv50_wndw_func {
asyw->set.point = true;
if (!varm || asym || armw->state.fb != asyw->state.fb) {
- ret = nv50_wndw_atomic_check_acquire(wndw, asyw, asyh);
+ ret = nv50_wndw_atomic_check_acquire(
+ wndw, asyw, asyh, pflip_flags);
if (ret)
return ret;
}
@@ -2221,77 +2228,6 @@ struct nv50_base {
.atomic_check = nv50_head_atomic_check,
};
-/* This is identical to the version in the atomic helpers, except that
- * it supports non-vblanked ("async") page flips.
- */
-static int
-nv50_head_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event, u32 flags)
-{
- struct drm_plane *plane = crtc->primary;
- struct drm_atomic_state *state;
- struct drm_plane_state *plane_state;
- struct drm_crtc_state *crtc_state;
- int ret = 0;
-
- state = drm_atomic_state_alloc(plane->dev);
- if (!state)
- return -ENOMEM;
-
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
-retry:
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state)) {
- ret = PTR_ERR(crtc_state);
- goto fail;
- }
- crtc_state->event = event;
-
- plane_state = drm_atomic_get_plane_state(state, plane);
- if (IS_ERR(plane_state)) {
- ret = PTR_ERR(plane_state);
- goto fail;
- }
-
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
- if (ret != 0)
- goto fail;
- drm_atomic_set_fb_for_plane(plane_state, fb);
-
- /* Make sure we don't accidentally do a full modeset. */
- state->allow_modeset = false;
- if (!crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
-crtc->base.id);
- ret = -EINVAL;
- goto fail;
- }
-
- if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
- nv50_wndw_atom(plane_state)->interval = 0;
-
- ret = drm_atomic_nonblocking_commit(state);
-fail:
- if (ret == -EDEADLK)
- goto backoff;
-
- drm_atomic_state_put(state);
- return ret;
-
-backoff:
- drm_atomic_state_clear(state);
- drm_atomic_legacy_backoff(state);
-
- /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
- plane->old_fb = plane->fb;
-
- goto retry;
-}
-
static int
nv50_head_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t size)
@@ -2386,7 +2322,7 @@ struct nv50_base {
.gamma_set = nv50_head_gamma_set,
.destroy = nv50_head_destroy,
[PATCH v5 1/3] drm/atomic: Save flip flags in drm_crtc_state
Allows using atomic flip helpers for drivers
using ASYNC flip.
Remove ASYNC_FLIP restriction in helpers and
caches the page flip flags in drm_crtc_state
to be used in the low level drivers.
v2:
Resending the patch since the original was broken.
v3:
Save flag in crtc_state instead of plane_state
v4:
Reset the flag before using again.
v5:
Fix type in header.
Rename the field to pageflip_flags.
Remove unrelated hunk.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
include/drm/drm_crtc.h | 9 -
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a4e5477..63efa05 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2737,7 +2737,8 @@ static int page_flip_common(
struct drm_atomic_state *state,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event)
+ struct drm_pending_vblank_event *event,
+ uint32_t flags)
{
struct drm_plane *plane = crtc->primary;
struct drm_plane_state *plane_state;
@@ -2749,12 +2750,12 @@ static int page_flip_common(
return PTR_ERR(crtc_state);
crtc_state->event = event;
+ crtc_state->pageflip_flags = flags;
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state))
return PTR_ERR(plane_state);
-
ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
if (ret != 0)
return ret;
@@ -2781,10 +2782,6 @@ static int page_flip_common(
* Provides a default &drm_crtc_funcs.page_flip implementation
* using the atomic driver interface.
*
- * Note that for now so called async page flips (i.e. updates which are not
- * synchronized to vblank) are not supported, since the atomic interfaces have
- * no provisions for this yet.
- *
* Returns:
* Returns 0 on success, negative errno numbers on failure.
*
@@ -2800,9 +2797,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
struct drm_atomic_state *state;
int ret = 0;
- if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
- return -EINVAL;
-
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
@@ -2810,7 +2804,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
retry:
- ret = page_flip_common(state, crtc, fb, event);
+ ret = page_flip_common(state, crtc, fb, event, flags);
if (ret != 0)
goto fail;
@@ -2865,9 +2859,6 @@ int drm_atomic_helper_page_flip_target(
struct drm_crtc_state *crtc_state;
int ret = 0;
- if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
- return -EINVAL;
-
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
@@ -2875,7 +2866,7 @@ int drm_atomic_helper_page_flip_target(
state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
retry:
- ret = page_flip_common(state, crtc, fb, event);
+ ret = page_flip_common(state, crtc, fb, event, flags);
if (ret != 0)
goto fail;
@@ -3072,6 +3063,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
state->color_mgmt_changed = false;
state->zpos_changed = false;
state->event = NULL;
+ state->pageflip_flags = 0;
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c77c3f..76561fb 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -162,10 +162,17 @@ struct drm_crtc_state {
* Target vertical blank period when a page flip
* should take effect.
*/
-
u32 target_vblank;
/**
+* @pageflip_flags:
+*
+* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
+* Zero in any other case.
+*/
+ u32 pageflip_flags;
+
+ /**
* @event:
*
* Optional pointer to a DRM event to signal upon completion of the
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
From: Fabio Estevam Currently the framebuffer content is displayed with incorrect offsets in both the vertical and horizontal directions. The fbdev version of the driver does not show this problem. Breno Lima dumped the eLCDIF controller registers on both the drm and fbdev drivers and noticed that the VDCTRL3 register is configured incorrectly in the drm driver. The fbdev driver calculates the vertical and horizontal wait counts of the VDCTRL3 register by doing: back porch + sync length. Looking at the horizontal and vertical timing diagram from include/drm/drm_modes.h this value corresponds to: crtc_[hv]total - crtc_[hv]sync_start So fix the VDCTRL3 register setting accordingly so that the eLCDIF controller can properly show the framebuffer content in the correct position. Reported-by: Breno Lima Signed-off-by: Fabio Estevam --- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c index e10a4ed..b56f86c 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c @@ -184,8 +184,8 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal), mxsfb->base + LCDC_VDCTRL2); - writel(SET_HOR_WAIT_CNT(m->crtc_hblank_end - m->crtc_hsync_end) | - SET_VERT_WAIT_CNT(m->crtc_vblank_end - m->crtc_vsync_end), + writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) | + SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start), mxsfb->base + LCDC_VDCTRL3); writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay), -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Hi Thierry, On Thu, Feb 2, 2017 at 6:18 PM, Thierry Reding wrote: > Shawn, Fabio, anyone want to give this a Tested-by? I take it that this, > in combination with Fabio's patch to fix the displacement would make the > SabreSD display work properly? Yes, that is correct. It also needs the other patch I sent yesterday that allows the power-supply regulator to work. I was able to test it on a imx6sx-sdb board, so: Tested-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.
v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Rob Clark
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Cc: Eric Anholt
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Reviewed-by: Alex Deucher
Reviewed-by: Sinclair Yeh # vmwgfx
---
v5: Rebase onto etnaviv pull for 4.11 -- no intentional changes from v4.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
drivers/gpu/drm/armada/armada_gem.c | 4 +-
drivers/gpu/drm/drm_mm.c | 488 +++
drivers/gpu/drm/drm_vma_manager.c| 3 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 11 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
drivers/gpu/drm/msm/msm_gem.c| 3 +-
drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
drivers/gpu/drm/sis/sis_mm.c | 6 +-
drivers/gpu/drm/tegra/gem.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
drivers/gpu/drm/via/via_mm.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
include/drm/drm_mm.h | 184 +-
23 files changed, 470 insertions(+), 442 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index e4eb6dd3798a..0335c2f331e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
{
struct amdgpu_gtt_mgr *mgr = man->priv;
struct drm_mm_node *node = mem->mm_node;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long fpfn, lpfn;
int r;
@@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
else
lpfn = man->size;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+ if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
- mem->page_alignment, 0,
- fpfn, lpfn, sflags, aflags);
+ r = drm_mm_insert_node_in_range(&mgr->mm, node,
+ mem->num_pages, mem->page_alignment, 0,
+ fpfn, lpfn, mode);
spin_unlock(&mgr->lock);
if (!r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ac9007986c11..9e577e3d3147 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
struct amdgpu_vram_mgr *mgr = man->priv;
struct drm_mm *mm = &mgr->mm;
struct drm_mm_node *nodes;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
unsigned i;
int r;
@@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
if (!nodes)
return -ENOMEM;
- if (place->flags & TTM_PL_FLAG_TOPDOWN) {
-
Re: [Freedreno] [RFC] drm/msm/adreno: clean up gpu bindings
On Thu, Jan 26, 2017 at 05:03:54PM -0500, Rob Clark wrote: > On Thu, Jan 26, 2017 at 4:09 PM, Rob Herring wrote: > > On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote: > >> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote: > >>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote: > So, cleaning up the GPU bindings is something that has been on my TODO > list for a while, but always $bigger_fires. Existing bindings are a bit > ugly, but served a purpose when too many of the other drivers the GPU > depends on where still working their way upstream. But now enough of > that is in place for a few devices, that we should start trying to get > the GPU nodes into the upstream dts files. > > This drops the "qcom,chipid" property and parses the GPU revision out of > the compat string. It does mean you need to list both "qcom,adreno" and > the more specific string, for example "qcom,adreno-530.2". I'm not sure > if that is "weird" or anyone has better ideas (hence this RFC). > >>> > >>> Is version and SoC close to a 1-1 mapping? If one version is in lots > >>> of different SoCs, then you should have an SoC specific compatible. > >> > >> I'm not sure how common it is, but I'm pretty sure in the past I've > >> seen same gpu (but maybe not same patchlevel). > >> > >> Also, there tend to be multiple revisions of the SoC which may or may > >> not bump the gpu patchlevel. I think it is quite likely to be > >> insanity to try and figure out gpu revision from SoC.. > > > > I'm not saying you should. My point is gpu revision alone may not be > > enough. Things can get integrated or configured differently. You could > > use an SoC based compatible, read the revision registers for the > > revision, and override wrong revision registers based on SoC > > compatible (assuming that is rare). > > Hmm, I'll probably defer to Jordan on this, since he has seen more > combinations over the years. > > I think any integration differences would just amount to which > clks/gdsc/etc are wired up. At least what I've seen in downstream > kgsl driver, all the things that are conditional are purely keyed to > the revision+patchlevel. I think for all practical purposes there is a 1-1 mapping between a GPU version and a SoC at least over the last few years. The last time I can remember was an unfortunate series of revisions in the 3XX family which I think ended up being the catalyst for the hardware team getting their act together in this regard. > As far as revision registers, IIRC back in the a3xx days they were not > to be trusted. I'm not entirely sure when they became trustworthy. > Last I checked, android kgsl driver was not using them. We got burned to a crisp over these back in the day and I have never forgotten it so thats why the downstream driver is exclusively DT based (which I admit is probably too far in the other direction). These days I think they are mostly agreeable again (sometimes they don't get updated for metal spins but I think they even got that figured out too). I'm open to using revision registers again as long as we don't blindly trust them and give ourselves a way to override the version. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
On Thu, Feb 2, 2017 at 8:46 PM, Volker Vogelhuber
wrote:
> On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>>> doing the following:
>>>
>>> std::vector image_attribs = {
>>> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
>>> EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
>>> EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
>>> EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
>>> EGL_NONE
>>> };
>>> glGenTextures( 1, &texID );
>>> glBindTexture( GL_TEXTURE_2D, texID );
>>> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), &image_attribs[0]
>>> );
>>> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
>>> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
>>> &nplanes, &modifiers)
>>> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
>>> offsets)
>>>
>>> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
>>> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
>>> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>>>
>>> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
>>> while
>>> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
>>> an Intel CherryTrail (i915).
>>>
>>> Is there an obvious reason why I'm not able to mmap the texture FD with
>>> PROT_WRITE flags?
>>> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
>>> have guessed that
>>> this should be possible. Or is it only true for specific GEM buffers not
>>> textures created using
>>> eglCreateDRMImageMESA?
>>
> >From a quick look the mesa/libdrm (depending upon driver) handle2fd
>>implementations don't set the DRM_RDWR flag when asking PRIME for a
>>dma-buf fd, which means you fd doesn't have write permissions. Which means
>>mmap with writing allowed will fail.
>>
>>Not sure how to fix that.
> Thanks for the reply. I guess you mean that line of code:
> http://code.metager.de/source/xref/freedesktop/mesa/drm/intel/intel_bufmgr_gem.c#2679
> Is there a good reason not to patch drm_intel_bo_gem_export_to_prime to call
> drmPrimeHandleToFD with DRM_RDWR flag set as well? I just saw a similar
> discussion
> under https://chromium-review.googlesource.com/c/323990/
Probably none, just a historical accident because the first prime
support didn't have support for mmap. Feel free to submit patches for
this all.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-nightly 1076/1086] drivers/gpu/drm/gma500/framebuffer.c:566:8: error: too few arguments to function 'drm_fb_helper_init'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 0f01216949002d20b9dc6d300c82df5ffa59e9a7 commit: e4563f6ba71792c77aeccb2092cc23149b44e642 [1076/1086] drm: Rely on mode_config data for fb_helper initialization config: i386-randconfig-x0-02030244 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout e4563f6ba71792c77aeccb2092cc23149b44e642 # save the attached .config to linux build tree make ARCH=i386 Note: the drm-intel/drm-intel-nightly HEAD 0f01216949002d20b9dc6d300c82df5ffa59e9a7 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/gpu/drm/gma500/framebuffer.c: In function 'psb_fbdev_init': >> drivers/gpu/drm/gma500/framebuffer.c:566:8: error: too few arguments to >> function 'drm_fb_helper_init' ret = drm_fb_helper_init(dev, &fbdev->psb_fb_helper, ^~ In file included from drivers/gpu/drm/gma500/framebuffer.c:35:0: include/drm/drm_fb_helper.h:309:19: note: declared here static inline int drm_fb_helper_init(struct drm_device *dev, ^~ -- drivers/gpu/drm/qxl/qxl_fb.c: In function 'qxl_fbdev_init': >> drivers/gpu/drm/qxl/qxl_fb.c:401:8: error: too few arguments to function >> 'drm_fb_helper_init' ret = drm_fb_helper_init(&qdev->ddev, &qfbdev->helper, ^~ In file included from drivers/gpu/drm/qxl/qxl_fb.c:35:0: include/drm/drm_fb_helper.h:309:19: note: declared here static inline int drm_fb_helper_init(struct drm_device *dev, ^~ vim +/drm_fb_helper_init +566 drivers/gpu/drm/gma500/framebuffer.c 4d8d096e9 Alan Cox2011-11-03 560 } 4d8d096e9 Alan Cox2011-11-03 561 4d8d096e9 Alan Cox2011-11-03 562 dev_priv->fbdev = fbdev; 10a231026 Thierry Reding 2014-06-27 563 10a231026 Thierry Reding 2014-06-27 564 drm_fb_helper_prepare(dev, &fbdev->psb_fb_helper, &psb_fb_helper_funcs); 4d8d096e9 Alan Cox2011-11-03 565 01934c2a6 Thierry Reding 2014-12-19 @566 ret = drm_fb_helper_init(dev, &fbdev->psb_fb_helper, e4563f6ba Gabriel Krisman Bertazi 2017-02-02 567 INTELFB_CONN_LIMIT); 01934c2a6 Thierry Reding 2014-12-19 568 if (ret) 01934c2a6 Thierry Reding 2014-12-19 569 goto free; :: The code at line 566 was first introduced by commit :: 01934c2a691882185b3021d437df13bcba07711d drm/fb-helper: Propagate errors from initial config failure :: TO: Thierry Reding :: CC: Daniel Vetter --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
On Thu, Feb 02, 2017 at 06:04:00PM -0200, Breno Lima wrote:
> Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel, which can be supported by the simple panel driver.
>
> Data-sheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Signed-off-by: Breno Lima
> ---
> .../bindings/display/panel/sii,43wvf1g.txt | 7 ++
> drivers/gpu/drm/panel/panel-simple.c | 28
> ++
> 2 files changed, 35 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
> b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
> new file mode 100644
> index 000..bbbc49f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
> @@ -0,0 +1,7 @@
> +Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
> +
> +Required properties:
> +- compatible: should be "sii,43wvf1g"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 06aaf79..0e08c56 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -863,6 +863,31 @@ static const struct panel_desc hannstar_hsd070pww1 = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> };
>
> +static const struct display_timing sii_43wvf1g_timing = {
> + .pixelclock = { 3350, 3350, 3350 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 164, 164, 164 },
> + .hback_porch = { 89, 89, 89 },
> + .hsync_len = { 10, 10, 10 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 10, 10, 10 },
> + .vback_porch = { 23, 23, 23 },
> + .vsync_len = { 10, 10, 10 },
> + .flags = DISPLAY_FLAGS_DE_LOW,
> +};
I was going to say that you should list minimum and maximum values, and
that the default implementation will give you the typical values, but it
seems like the datasheet doesn't have minimum and maximum values, so
this looks fine.
Shawn, Fabio, anyone want to give this a Tested-by? I take it that this,
in combination with Fabio's patch to fix the displacement would make the
SabreSD display work properly?
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #23 from Jean-François Fortin Tam --- Created attachment 129306 --> https://bugs.freedesktop.org/attachment.cgi?id=129306&action=edit Xorg log Xorg.0.log file found in ~/.local/share/xorg as "Xorg.0.log.old" As you can see it says nothing about the crash. It seems only the global journalctl output caught something. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 Jean-François Fortin Tam changed: What|Removed |Added Attachment #128278|0 |1 is obsolete|| --- Comment #22 from Jean-François Fortin Tam --- Created attachment 129305 --> https://bugs.freedesktop.org/attachment.cgi?id=129305&action=edit journalctl output at the time of a deadlock on F25 - take 2 Full journal output at the time of the crash. Exactly the same as before as far as I can tell. If there's any other information I can provide, please tell. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #21 from Jean-François Fortin Tam --- Created attachment 129304 --> https://bugs.freedesktop.org/attachment.cgi?id=129304&action=edit journalctl output at the time of a deadlock on F25 - X GDM session output only Hi Alex and thanks for the pointer, here's the output as per those instructions... but the result seems quite useless compared to the full journalctl output (which I'll be attaching as well). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
I'm going to need to cool down for a bit. Let's resume this on Monday, maybe we can get back to being constructive after the weekend. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
AW: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>> doing the following:
>>
>> std::vector image_attribs = {
>> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
>> EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
>> EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
>> EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
>> EGL_NONE
>> };
>> glGenTextures( 1, &texID );
>> glBindTexture( GL_TEXTURE_2D, texID );
>> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), &image_attribs[0]
>> );
>> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
>> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
>> &nplanes, &modifiers)
>> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
>> offsets)
>>
>> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
>> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
>> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>>
>> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
>> while
>> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
>> an Intel CherryTrail (i915).
>>
>> Is there an obvious reason why I'm not able to mmap the texture FD with
>> PROT_WRITE flags?
>> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
>> have guessed that
>> this should be possible. Or is it only true for specific GEM buffers not
>> textures created using
>> eglCreateDRMImageMESA?
>
>From a quick look the mesa/libdrm (depending upon driver) handle2fd
>implementations don't set the DRM_RDWR flag when asking PRIME for a
>dma-buf fd, which means you fd doesn't have write permissions. Which means
>mmap with writing allowed will fail.
>
>Not sure how to fix that.
Thanks for the reply. I guess you mean that line of code:
http://code.metager.de/source/xref/freedesktop/mesa/drm/intel/intel_bufmgr_gem.c#2679
Is there a good reason not to patch drm_intel_bo_gem_export_to_prime to call
drmPrimeHandleToFD with DRM_RDWR flag set as well? I just saw a similar
discussion
under https://chromium-review.googlesource.com/c/323990/
Regards,
Volker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix build when FBDEV_EMULATION is disabled
On Thu, Feb 02, 2017 at 05:39:00PM -0200, Gabriel Krisman Bertazi wrote:
> Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
> initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
> disabled because it didn't update the prototype for drm_fb_helper_init
> in that case.
>
> Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
> initialization")
> Signed-off-by: Gabriel Krisman Bertazi
Oops. Applied, thanks for the quick fix.
-Daniel
> ---
> include/drm/drm_fb_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 278820ee17ad..6f5acebb266a 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -307,7 +307,7 @@ static inline void drm_fb_helper_prepare(struct
> drm_device *dev,
> }
>
> static inline int drm_fb_helper_init(struct drm_device *dev,
> -struct drm_fb_helper *helper, int crtc_count,
> +struct drm_fb_helper *helper,
> int max_conn)
> {
> return 0;
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix build when FBDEV_EMULATION is disabled
Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
disabled because it didn't update the prototype for drm_fb_helper_init
in that case.
Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization")
Signed-off-by: Gabriel Krisman Bertazi
---
include/drm/drm_fb_helper.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 278820ee17ad..6f5acebb266a 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -307,7 +307,7 @@ static inline void drm_fb_helper_prepare(struct drm_device
*dev,
}
static inline int drm_fb_helper_init(struct drm_device *dev,
- struct drm_fb_helper *helper, int crtc_count,
+ struct drm_fb_helper *helper,
int max_conn)
{
return 0;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 1066/1073] drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:376:8: error: too few arguments to function 'drm_fb_helper_init'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36aab92fa2091dd54ea983752aa40e427e83d113
commit: e4563f6ba71792c77aeccb2092cc23149b44e642 [1066/1073] drm: Rely on
mode_config data for fb_helper initialization
config: i386-randconfig-x007-201705 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout e4563f6ba71792c77aeccb2092cc23149b44e642
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c: In function 'amdgpu_fbdev_init':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:376:8: error: too few arguments to
>> function 'drm_fb_helper_init'
ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
^~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:39:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:50,
from drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:34:
include/drm/drm_fb_helper.h:309:19: note: declared here
static inline int drm_fb_helper_init(struct drm_device *dev,
^~
vim +/drm_fb_helper_init +376 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
d38ceaf9 Alex Deucher 2015-04-20 370 rfbdev->adev = adev;
d38ceaf9 Alex Deucher 2015-04-20 371 adev->mode_info.rfbdev = rfbdev;
d38ceaf9 Alex Deucher 2015-04-20 372
d38ceaf9 Alex Deucher 2015-04-20 373 drm_fb_helper_prepare(adev->ddev,
&rfbdev->helper,
d38ceaf9 Alex Deucher 2015-04-20 374
&amdgpu_fb_helper_funcs);
d38ceaf9 Alex Deucher 2015-04-20 375
d38ceaf9 Alex Deucher 2015-04-20 @376 ret = drm_fb_helper_init(adev->ddev,
&rfbdev->helper,
d38ceaf9 Alex Deucher 2015-04-20 377
AMDGPUFB_CONN_LIMIT);
d38ceaf9 Alex Deucher 2015-04-20 378 if (ret) {
d38ceaf9 Alex Deucher 2015-04-20 379 kfree(rfbdev);
:: The code at line 376 was first introduced by commit
:: d38ceaf99ed015f2a0b9af3499791bd3a3daae21 drm/amdgpu: add core driver (v4)
:: TO: Alex Deucher
:: CC: Alex Deucher
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
vmwgfx part: Reviewed-by: Sinclair Yeh
On Thu, Feb 02, 2017 at 11:44:33AM +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> v2: Search for holes both high and low. Rename flags to mode.
> v3: Discover rb_entry_safe() and use it!
> v4: Kerneldoc for enum drm_mm_insert_mode.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Rob Clark
> Cc: Thierry Reding
> Cc: Stephen Warren
> Cc: Alexandre Courbot
> Cc: Eric Anholt
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
> drivers/gpu/drm/armada/armada_gem.c | 4 +-
> drivers/gpu/drm/drm_mm.c | 488
> +++
> drivers/gpu/drm/drm_vma_manager.c| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 3 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
> drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
> drivers/gpu/drm/sis/sis_mm.c | 6 +-
> drivers/gpu/drm/tegra/gem.c | 4 +-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
> drivers/gpu/drm/via/via_mm.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
> include/drm/drm_mm.h | 184 +-
> 23 files changed, 470 insertions(+), 447 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index e4eb6dd3798a..0335c2f331e9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
> {
> struct amdgpu_gtt_mgr *mgr = man->priv;
> struct drm_mm_node *node = mem->mm_node;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long fpfn, lpfn;
> int r;
>
> @@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager
> *man,
> else
> lpfn = man->size;
>
> - if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
> - sflags = DRM_MM_SEARCH_BELOW;
> - aflags = DRM_MM_CREATE_TOP;
> - }
> + mode = DRM_MM_INSERT_BEST;
> + if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
> + mode = DRM_MM_INSERT_HIGH;
>
> spin_lock(&mgr->lock);
> - r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
> - mem->page_alignment, 0,
> - fpfn, lpfn, sflags, aflags);
> + r = drm_mm_insert_node_in_range(&mgr->mm, node,
> + mem->num_pages, mem->page_alignment, 0,
> + fpfn, lpfn, mode);
> spin_unlock(&mgr->lock);
>
> if (!r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index ac9007986c11..9e577e3d3147 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
> *man,
> struct amdgpu_vram_mgr *mgr = man->priv;
> struct drm_mm *mm = &mgr->mm;
> struct drm_mm_node *nodes;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long lpfn, num_nodes, pages_per_node, pages_left;
> unsigned i;
> int r;
> @@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct
> ttm_me
Re: [PATCH 4/6] drm: scrambling support in drm layer
On Thu, Feb 02, 2017 at 11:08:22AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:02 PM, Thierry Reding wrote:
> > On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> > > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> > > than 340Mhz. This patch adds few new functions in drm layer for
> > > core drivers to enable/disable scrambling.
> > >
> > > This patch adds:
> > > - A function to detect scrambling support parsing HF-VSDB
> > > - A function to check scrambling status runtime using SCDC read.
> > > - Two functions to enable/disable scrambling using SCDC read/write.
> > > - Few new bools to reflect scrambling support and status.
> > >
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 131
> > > +++-
> > > include/drm/drm_connector.h | 24
> > > include/drm/drm_edid.h | 6 +-
> > > 3 files changed, 159 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 37902e5..f0d940a 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -37,6 +37,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #define version_greater(edid, maj, min) \
> > > (((edid)->version > (maj)) || \
> > > @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct
> > > drm_connector *connector,
> > > }
> > > }
> > > +static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
> > > + const u8 *hf_vsdb)
> > > +{
> > > + struct drm_display_info *display = &connector->display_info;
> > > + struct drm_hdmi_info *hdmi = &display->hdmi_info;
> > > +
> > > + /*
> > > + * All HDMI 2.0 monitors must support scrambling at rates > 340M.
> > In comments below you use Mhz as the abbreviations. This should be
> > consistent. Also I think "MHz" is actually the correct spelling.
> Agree.
> > > + * And as per the spec, three factors confirm this:
> > > + * * Availability of a HF-VSDB block in EDID (check)
> > > + * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
> > > + * * SCDC support available
> > > + * Lets check it out.
> > > + */
> > > +
> > > + if (hf_vsdb[5]) {
> > > + display->max_tmds_clock = hf_vsdb[5] * 5000;
> > > + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> > > + display->max_tmds_clock);
> > > +
> > > + if (hdmi->scdc_supported) {
> > > + hdmi->scr_info.supported = true;
> > > +
> > > + /* Few sinks support scrambling for cloks < 340M */
> > > + if ((hf_vsdb[6] & 0x8))
> > > + hdmi->scr_info.low_clocks = true;
> > > + }
> > > + }
> > > +}
> > > +
> > > +/**
> > > + * drm_check_scrambling_status - what is status of scrambling?
> > > + * @adapter: i2c adapter for SCDC channel
> > "I2C", same in other parts of this patch.
> Got it.
> > > + *
> > > + * Read the scrambler status over SCDC channel, and check the
> > > + * scrambling status.
> > > + *
> > > + * Return: True if the scrambling is enabled, false otherwise.
> > I think the rest of DRM/KMS kerneldoc tries to use "Returns:\n" as a
> > standard way to document return values.
> Ok.
> > > + */
> > > +
> > > +bool drm_check_scrambling_status(struct i2c_adapter *adapter)
> > Maybe use a drm_scdc_*() prefix for this to make it more consistent with
> > other SCDC API.
> >
> > While at it, would this not be better located in drm_scdc.c along with
> > the other helpers? drm_edid.c is more focussed on the parsing aspects of
> > all things EDID.
> Yeah, the same is mentioned by Ville too, will do that.
> > > +{
> > > + u8 status;
> > > +
> > > + if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status) < 0) {
> > How about storing the error code...
> >
> > > + DRM_ERROR("Failed to read scrambling status\n");
> > ... and making it part of the error message? Sometimes its useful to
> > know what exact error triggered this because it helps narrowing down
> > where things went wrong.
> Agree, in fact while debugging and testing this patch series, I had to print
> it explicitly.
> >
> > > + return false;
> > > + }
> > > +
> > > + status &= SCDC_SCRAMBLING_STATUS;
> > > + return status != 0;
> > Maybe make this a single line:
> >
> > return (status & SCDC_SCRAMBLING_STATUS) != 0;
> Got it.
> >
> > > +}
> > > +
> > > +/**
> > > + * drm_enable_scrambling - enable scrambling
> > > + * @connector: target drm_connector
> > "target DRM connector"?
> Got it.
> > > + * @adapter: i2c adapter for SCDC channel
> > > + * @force: enable scrambling, even if its already enabled
> > > + *
> > > + * Write the TMDS config over SCDC channel, and enable scrambling
> > > + * Return: True if scrambling is successfully enabled, false otherwise.
> > > + */
> > > +
> > > +bool drm_enable_scrambling(struct
Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.
On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima wrote: > - The image is displaced even when using the same timing values in > the datasheet. Managed to fix this framebuffer displacement problem. Will submit a patch soon. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization
On Thu, Feb 02, 2017 at 02:26:40PM -0200, Gabriel Krisman Bertazi wrote:
> Instead of receiving the num_crts as a parameter, we can read it
> directly from the mode_config structure. I audited the drivers that
> invoke this helper and I believe all of them initialize the mode_config
> struct accordingly, prior to calling the fb_helper.
>
> I used the following coccinelle hack to make this transformation, except
> for the function headers and comment updates. The first and second
> rules are split because I couldn't find a way to remove the unused
> temporary variables at the same time I removed the parameter.
>
> //
> @r@
> expression A,B,D,E;
> identifier C;
> @@
> (
> - drm_fb_helper_init(A,B,C,D)
> + drm_fb_helper_init(A,B,D)
> |
> - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
> + drm_fbdev_cma_init_with_funcs(A,B,D,E)
> |
> - drm_fbdev_cma_init(A,B,C,D)
> + drm_fbdev_cma_init(A,B,D)
> )
>
> @@
> expression A,B,C,D,E;
> @@
> (
> - drm_fb_helper_init(A,B,C,D)
> + drm_fb_helper_init(A,B,D)
> |
> - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
> + drm_fbdev_cma_init_with_funcs(A,B,D,E)
> |
> - drm_fbdev_cma_init(A,B,C,D)
> + drm_fbdev_cma_init(A,B,D)
> )
>
> @@
> identifier r.C;
> type T;
> expression V;
> @@
> - T C;
> <...
> when != C
> - C = V;
> ...>
> //
>
> Changes since v1:
> - Rebased on top of the tip of drm-misc-next.
> - Remove mention to sti since a proper fix got merged.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Gabriel Krisman Bertazi
> Reviewed-by: Eric Anholt
Yup, this applied cleanly, thanks for respinning.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 1 -
> drivers/gpu/drm/arc/arcpgu_drv.c | 3 +--
> drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
> drivers/gpu/drm/arm/malidp_drv.c | 2 +-
> drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
> drivers/gpu/drm/ast/ast_fb.c | 3 +--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 -
> drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +--
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
> drivers/gpu/drm/drm_fb_cma_helper.c | 15 +++
> drivers/gpu/drm/drm_fb_helper.c | 10 +-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
> drivers/gpu/drm/gma500/framebuffer.c | 2 +-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 3 +--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +--
> drivers/gpu/drm/i915/intel_fbdev.c| 3 +--
> drivers/gpu/drm/imx/imx-drm-core.c| 3 +--
> drivers/gpu/drm/meson/meson_drv.c | 1 -
> drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
> drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +--
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +--
> drivers/gpu/drm/qxl/qxl_fb.c | 1 -
> drivers/gpu/drm/radeon/radeon_fb.c| 1 -
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 5 +
> drivers/gpu/drm/sti/sti_drv.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 4 +---
> drivers/gpu/drm/tegra/fb.c| 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
> drivers/gpu/drm/udl/udl_fb.c | 3 +--
> drivers/gpu/drm/vc4/vc4_kms.c | 1 -
> drivers/gpu/drm/virtio/virtgpu_fb.c | 1 -
> drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
> include/drm/drm_fb_cma_helper.h | 7 +++
> include/drm/drm_fb_helper.h | 3 +--
> 38 files changed, 43 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 838943d0962e..36ce3cac81ba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -374,7 +374,6 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
> &amdgpu_fb_helper_funcs);
>
> ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
> - adev->mode_info.num_crtc,
>AMDGPUFB_CONN_LIMIT);
> if (ret) {
> kfree(rfbdev);
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 0b6eaa49a1db..8d8344ed655e 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -135,8 +135,7 @@ static int arcpgu_load(struct drm_device *drm)
> drm_kms_helper_poll_init(drm);
>
> arcpgu->fbdev = drm_fbdev_cma_init(drm, 16,
> -
Re: [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB
On Thu, Feb 02, 2017 at 10:58:43AM +0530, Sharma, Shashank wrote:
> Thanks for the review Thierry. My comments inline.
>
> Regards
> Shashank
> On 2/1/2017 9:40 PM, Thierry Reding wrote:
> > On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> > > This patch does following:
> > > - Adds a new structure (drm_hdmi_info) in drm_display_info.
> > >This structure will be used to save and indicate if sink
> > >supports advance HDMI 2.0 features
> > "advanced"
> got it.
> >
> > > - Checks the HF-VSDB block for presence of SCDC, and marks it
> > >in hdmi_info structure.
> > "drm_hdmi_info structure"?
> yep, sure.
> > > - If SCDC is present, checks if sink is capable of generating
> > >scdc read request, and marks it in hdmi_info structure.
> > "SCDC" to be consistent and because it's an abbreviation.
> Agree.
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 14 ++
> > > include/drm/drm_connector.h | 26 ++
> > > 2 files changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 96d3e47..37902e5 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
> > > }
> > > EXPORT_SYMBOL(drm_default_rgb_quant_range);
> > > +static void drm_detect_hdmi_scdc(struct drm_connector *connector,
> > > + const u8 *hf_vsdb)
> > > +{
> > > + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi_info;
> > > +
> > > + if (hf_vsdb[6] & 0x80) {
> > > + hdmi->scdc_supported = true;
> > > + if (hf_vsdb[6] & 0x40)
> > > + hdmi->scdc_rr = true;
> > > + }
> > > +}
> > > +
> > > static void drm_parse_hdmi_deep_color_info(struct drm_connector
> > > *connector,
> > > const u8 *hdmi)
> > > {
> > > @@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector
> > > *connector,
> > > if (cea_db_is_hdmi_vsdb(db))
> > > drm_parse_hdmi_vsdb_video(connector, db);
> > > + if (cea_db_is_hdmi_forum_vsdb(db))
> > > + drm_detect_hdmi_scdc(connector, db);
> > > }
> > > }
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index e5e1edd..2435598 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -87,6 +87,27 @@ enum subpixel_order {
> > > SubPixelVerticalRGB,
> > > SubPixelVerticalBGR,
> > > SubPixelNone,
> > > +
> > > +};
> > > +
> > > +/**
> > > + * struct drm_hdmi_info - runtime data about the connected sink
> > Maybe "connected HDMI sink"?
> Agree.
> > > + *
> > > + * Describes if a given hdmi display supports advance HDMI 2.0 featutes.
> > "HDMI", "advanced", "features"
> Oops, got it :-)
> > > + * This information is available in CEA-861-F extension blocks (like
> > > + * HF-VSDB)
> > This should be terminated by a full-stop.
> Ok
> > > + * For sinks which provide an EDID this can be filled out by calling
> > > + * drm_add_edid_modes().
> > And maybe make this sentence start right after the one above rather than
> > breaking it to the next line.
> Ok
> > I'm not sure how useful this line is. Most
> > driver will be calling drm_add_edid_modes() anyway, but the above makes
> > it sound like drm_add_edid_modes() is something you have to explicitly
> > call to get these fields parsed.
> Mostly a 'yy' and 'p' from the function above, but makes sense, I can remove
> this line.
> > > + */
> > > +struct drm_hdmi_info {
> > > + /**
> > > + * @scdc_supported: status control & data channel present.
> > > + */
> > > + bool scdc_supported;
> > > + /**
> > > + * @scdc_rr: sink is capable of generating scdc read request.
> > > + */
> > > + bool scdc_rr;
> > > };
> > > /**
> > > @@ -188,6 +209,11 @@ struct drm_display_info {
> > >* @cea_rev: CEA revision of the HDMI sink.
> > >*/
> > > u8 cea_rev;
> > > +
> > > + /**
> > > + * @hdmi_info: advance features of a HDMI sink.
> > > + */
> > > + struct drm_hdmi_info hdmi_info;
> > I think we can safely drop the _info suffix on the field name. It's
> > already inside a structure that carries this suffix.
> Sure, should I call it hdmi_sink OR connected_hdmi ?
No, I think just plain "hdmi" would be fine. This is part of
drm_display_info, which kind of implies that it's a sink, and I think
it's also fair to assume that this isn't valid if nothing's connected.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Tue, Jan 31, 2017 at 01:05:20PM +0100, Andrzej Hajda wrote: > On 31.01.2017 09:54, Thierry Reding wrote: > > On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: > >> > >> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: > >>> Dear Thierry, > >>> > >>> Could you please review this patch? > >> Thierry, I think this patch has been reviewed enough but no comment > >> from you. Seems you are busy. I will pick up this. > > Sorry, but that's not how it works. This patch has gone through 8 > > revisions within 4 weeks, and I tend to ignore patches like that until > > the dust settles. > > > > Other than that, this continues the same madness that I've repeatedly > > complained about in the past. The whole mechanism of running through a > > series of writes and not caring about errors until the very end is > > something we've discussed at length in the past. > > Yes, we have discussed the pattern, but without any conclusion. The > pattern is correct, used in different places in kernel (see below for > examples) and significantly decreases source code size. Disallowing it > in panels subsystem just because of personal preferences of the > maintainer does not seem to be proper. > > > It also in large parts > > duplicates a bunch of functions from other Samsung panel drivers that I > > already said should eventually be moved to something saner. > > Currently there are two Samsung panel drivers, one is on SPI bus, > another one is on DSI. > I am (co-)author of both drivers, they have some similarities but I did > not see any gain in making additional abstractions over transport layer > just to make one or two small functions common. > Could you be more precise what are you talking about, or could you give > a link to the mail where you said it. Anything I remember was a > discussion about ugly magic initialization sequences due to poor > documentation. > > And below promised examples of the error pattern, it was time consuming > to find them, so please at least read them :) I've done better, below is what I hope a list of good arguments why the pattern is a bad idea, and why in some cases it can be justified. > Almost exactly the same patterns for the same purpose: > > 1. http://lxr.free-electrons.com/source/drivers/net/ieee802154/atusb.c#L63 > Citation from the code: > To reduce the number of error checks in the code, we record the > first error > in atusb->err and reject all subsequent requests until the error is > cleared. That's about the worst example you could've used. Have you even looked at the code that uses this? It's completely crazy. So here we have the atusb_control_msg() function that stores this error, but then also propagates it to its caller. One of these callers is atusb_read_reg(), which also propagates the error or returns the register value if the read was successful. Now the really insane part is how this is then used in something like atusb_write_subreg(): orig = atusb_read_reg(atusb, reg); tmp = orig & ~mask; tmp |= (value << shift) & mask; if (tmp != orig) ret = atusb_write_reg(atusb, reg, tmp); So let's assume that atusb_control_msg() fails in the call to atusb_read_reg(). You'll be returning an error code, mask out some bits, OR in new ones and write the result to the register. So not only does the code not bother to check for errors, but it will also happily go and corrupt registers when an error has occurred while reading. > 2. http://lxr.free-electrons.com/source/drivers/md/dm-thin.c?v=4.4#L917 This is completely different from the panel driver because it's used to store a value from within callbacks that can't return one. > 3. http://lxr.free-electrons.com/source/net/9p/trans_fd.c?v=3.18#L297 Essentially the same thing. > 4. > http://lxr.free-electrons.com/source/drivers/media/v4l2-core/v4l2-ctrls.c#L2234 Looks like this could be replaced by the more idiomatic use of ERR_PTR() encoding error codes. But the most significant difference here is that each use of the handler_set_err() function is followed by a return. So instead of ignoring errors like you do in the panel drivers, this does recognize them and aborts early, rather than trying to go through the remainder of the code, irrespective of how small the chances are of it succeeding. Or ignoring that /even if/ the remainder didn't fail, the one operation that fail might have been essential to the operation of the device. > 5. http://lxr.free-electrons.com/source/drivers/media/i2c/s5k5baf.c#L451 That's a particularly good example of why you shouldn't be doing this kind of thing. Consider what would happen in these cases if for example there was a problem with the I2C interface. There's a bunch of read and write sequences in that driver that go completely without checking for errors. Imagine how that will look to a user when the communication to a chip doesn't work. They'll get a load of error messages all saying that communication timed out, or th
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
Daniel Vetter writes: > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: >> Jani Nikula writes: >> >> > On Tue, 31 Jan 2017, Eric Anholt wrote: >> >> Martin Peres writes: >> >> >> >>> Despite all the careful planing of the kernel, a link may become >> >>> insufficient to handle the currently-set mode. At this point, the >> >>> kernel should mark this particular configuration as being broken >> >>> and potentially prune the mode before setting the offending connector's >> >>> link-status to BAD and send the userspace a hotplug event. This may >> >>> happen right after a modeset or later on. >> >>> >> >>> When available, we should use the link-status information to reset >> >>> the wanted mode. >> >>> >> >>> Signed-off-by: Martin Peres >> >> >> >> If I understand this right, there are two failure modes being handled: >> >> >> >> 1) A mode that won't actually work because the link isn't good enough. >> >> >> >> 2) A mode that should work, but link parameters were too optimistic and >> >> if we just ask the kernel to set the mode again it'll use more >> >> conservative parameters that work. >> >> >> >> This patch seems good for 2). For 1), the drmmode_set_mode_major is >> >> going to set our old mode back. Won't the modeset then fail to link >> >> train again, and bring us back into this loop? The only escape that I >> >> see would be some other userspace responding to the advertised mode list >> >> changing, and then asking X to modeset to something new. >> >> >> >> To avoid that failure busy loop, should we re-fetching modes at this >> >> point, and only re-setting if our mode still exists? >> > >> > Disclaimer: I don't know anything about the internals of the modesetting >> > driver. >> > >> > Perhaps we can identify the two cases now, but I'd put this more >> > generally: if the link status has gone bad, it's an indicator to >> > userspace that the circumstances may have changed, and userspace should >> > query the kernel for the list of available modes again. It should no >> > longer trust information obtained prior to getting the bad link status, >> > including the current mode. >> > >> > But specifically, I think you're right, and AFAICT asking for the list >> > of modes again is the only way for the userspace to distinguish between >> > the two cases. I don't think there's a shortcut for deciding the current >> > mode is still valid. >> >> To avoid the busy-loop problem, I think I'd like this patch to re-query >> the kernel to ask about the current mode list, and only try to re-set >> the mode if our mode is still there. > > Yeah, I guess that sounds like a reasonable heuristics. More integrated > compositors (aka the wayland ones) might be able to make more useful > decisions, but for -modesetting that's probably the best we can do. > >> If the mode isn't there, then it's up to the DE to take action in >> response to the notification of new modes. If you don't have a DE to >> take appropriate action, you're kind of out of luck. >> >> As far as the ABI goes, this seems fine to me. The only concern I had >> about ABI was having to walk all the connectors on every uevent to see >> if any had gone bad -- couldn't we have a flag of some sort about what >> the uevent indicates? But uevents should be super rare, so I'd say the >> kernel could go ahead with the current plan. > > We've discussed finer-grained uevent singalling a few times, and I'd like > that to be an orthogonal abi extension. Right now we just don't have the > required tracking even within the kernel to know which connector changed > (and the tracking we do have missed a few things, too). My idea is to push > the tracking into the leaves of the callchains with a function that > increases some per-connector epoch counter. Then we'd just have to expose > that somehow cheaply to userspace (could probably just send it along in > the uevent). Plus expose it as a read-only property so that userspace can > re-synchronize. > > But again, that should be an orthogonal thing imo. Yeah, that was roughly my thought process, too. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-fixes-4.10
Hi Dave, Just a couple of small fixes for 4.10 The following changes since commit 52b679f60e2a68af88411f12318675a2424a0e14: Merge tag 'drm-misc-fixes-2017-01-31' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-02-01 08:45:27 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.10 for you to fetch changes up to 51964e9e12d0a054002a1a0d1dec4f661c7aaf28: drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl (2017-02-02 11:14:09 -0500) Alex Deucher (1): drm/amdgpu/si: fix crash on headless asics Michel Dänzer (1): drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 4 +++- drivers/gpu/drm/radeon/radeon_drv.c | 3 ++- drivers/gpu/drm/radeon/radeon_gem.c | 4 ++-- 3 files changed, 7 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Allow ASYNC flip with atomic helpers.
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky wrote: > This series is a folow-up on > https://patchwork.kernel.org/patch/9501787/ > > The first patch makes changes to atomic helpers to allow for drives with > ASYNC flip support to use them. > Patch 2 is to use this in AMDGPU/DC. > Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the > helper as we did to support ASYNC flips. > > v2: > Resend drm/atomic: Save flip flags in drm_plane_state since the original > patch was incomplete. > Squash 2 AMD changes into one to not break compilation. > > v3: > Following Daniel's comments, save flip flags in crtc_state instead of > plane_state. > > v4: > Lauren's comment, reset flp flags before using again. > Harry's comment, fix identation in amd/display. > > Andrey Grodzovsky (3): > drm/atomic: Save flip flags in drm_crtct_state > drm/nouveau/kms/nv50: Switch to using atomic helper for flip. > drm/amd/display: Switch to using atomic_helper for flip. A few comments on patch 1. WIth those addressed the series is: Reviewed-by: Alex Deucher > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - > .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 > + > drivers/gpu/drm/drm_atomic_helper.c| 20 ++-- > drivers/gpu/drm/nouveau/nv50_display.c | 84 ++- > include/drm/drm_crtc.h | 9 +- > include/drm/drm_plane.h| 1 + > 6 files changed, 49 insertions(+), 179 deletions(-) > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] drm/atomic: Save flip flags in drm_crtct_state
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch since the original was broken.
>
> v3:
> Save flag in crtc_state instead of plane_state
>
> v4:
> Reset the flag before using again.
>
> Change-Id: I0219c3ec3ecceb82143ee176d30cb50d9aa76bf0
> Signed-off-by: Andrey Grodzovsky
typo in the patch title:
drm_crtct_state
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> include/drm/drm_crtc.h | 9 -
> include/drm/drm_plane.h | 1 +
> 3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f84b5aa 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event)
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -2749,12 +2750,12 @@ static int page_flip_common(
> return PTR_ERR(crtc_state);
>
> crtc_state->event = event;
> + crtc_state->pflip_flags = flags;
>
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state))
> return PTR_ERR(plane_state);
>
> -
> ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> if (ret != 0)
> return ret;
> @@ -2781,10 +2782,6 @@ static int page_flip_common(
> * Provides a default &drm_crtc_funcs.page_flip implementation
> * using the atomic driver interface.
> *
> - * Note that for now so called async page flips (i.e. updates which are not
> - * synchronized to vblank) are not supported, since the atomic interfaces
> have
> - * no provisions for this yet.
> - *
> * Returns:
> * Returns 0 on success, negative errno numbers on failure.
> *
> @@ -2800,9 +2797,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> struct drm_atomic_state *state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2810,7 +2804,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
>
> retry:
> - ret = page_flip_common(state, crtc, fb, event);
> + ret = page_flip_common(state, crtc, fb, event, flags);
> if (ret != 0)
> goto fail;
>
> @@ -2865,9 +2859,6 @@ int drm_atomic_helper_page_flip_target(
> struct drm_crtc_state *crtc_state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2875,7 +2866,7 @@ int drm_atomic_helper_page_flip_target(
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
>
> retry:
> - ret = page_flip_common(state, crtc, fb, event);
> + ret = page_flip_common(state, crtc, fb, event, flags);
> if (ret != 0)
> goto fail;
>
> @@ -3072,6 +3063,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc,
> state->color_mgmt_changed = false;
> state->zpos_changed = false;
> state->event = NULL;
> + state->pflip_flags = 0;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5c77c3f..b74dbe1 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -162,10 +162,17 @@ struct drm_crtc_state {
> * Target vertical blank period when a page flip
> * should take effect.
> */
> -
> u32 target_vblank;
>
> /**
> +* @pflip_flags:
> +*
> +* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
> +* Zero in any other case.
> +*/
> + u32 pflip_flags;
I can go either way on whether we call this pflip or page_flip. I
guess it's better to spell it out.
> +
> + /**
> * @event:
> *
> * Optional pointer to a DRM event to signal upon completion of the
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index db3bbde..57414ae 100644
> --- a/include/dr
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Thu, Feb 02, 2017 at 05:30:34PM +0200, Jani Nikula wrote: > On Tue, 31 Jan 2017, Thierry Reding wrote: > > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > >> I would love for drm-panel to be moved under -misc. > > > > Like that's going to magically motivate people to spend their time > > reviewing other patches. The only thing that group maintainership adds > > is redundancy. > > Adding redundancy is not an insignificant thing. I think it can be quite > liberating to not have everything and everybody depend on you. You can > defer to others when you're busy, tired, sick, whatever. Things still > move on. Oh, I certainly see the advantages in sharing maintainership. However, I think it really only works well if you've got active developers working together on the code already. Then it's very natural to let all of them manage a tree. But for drm-panel, I've rarely seen anyone review patches. Sometimes the easy patches (i.e. panel-simple) get reviewed by parties that have some interest in seeing the patches merged. However, there's usually no review at all for the more complicated patches. Given that, I doubt that group maintainership is going to have the desired effect. Just because the tree is group maintained doesn't mean that all of a sudden people are going to care about the patches. So I suspect that even if panel drivers were managed in drm-misc, I'd still be the only person reviewing the patches. And really, managing a tree is peanuts compared to the amount of work it takes to properly review code. With group maintainership, for this type of tree in particular, I think it's likely for the quality bar to be lowered. There aren't any best practices yet for anything beyond panel-simple, and therefore little to no review is likely going to make people still pick up patches. This is quite different to the DRM/KMS core bits and drivers because there are established best practices and people can usually spot when new code is not living up to expectations. > And I don't think redundancy is the only thing that group maintainership > adds. You'll have maintainers that complement each other, with different > skill sets and abilities and experience. They don't all look at the same > things. As maintainers tend to be more senior folks, I find sharing the > load of the more mundane tasks of maintainership free up their time to > contribute more of their technical skills to the project, for example > review. I don't understand why group maintainership would be necessary for this. Surely people will review code irrespective of who finally applies their patch. If they don't in a single maintainer project, why would they suddenly start reviewing code in group maintained projects? > It's just my personal view on i915, but I think people take more > responsibility of their own work, instead of just sending patches and > waiting for stuff to happen, when they have commit access. But you have > to trust the people. That's not something that we're discussing here. Surely giving the world access to the maintainer trees is not a goal that we're pursuing here. It will still only be a handful of selected people that will have commit access, so how's that going to change things for contributors that don't have commit access? The bottom line still is that we have a requirement to have patches reviewed before they get applied. So even if everybody had commit access we'd still need someone to review a patch before it gets applied. Like I said, reviewing is really the difficult part of a maintainer's job. Applying a patch is trivial, build-testing is equally trivial and so is sending out a pull request. All of the above can be easily automated to a point where it's completely painless. > I didn't intend for this to become a kind of sales pitch, but I do think > drm-panel would be a good fit for drm-misc. Personally I think it's your > call, but I think you should think about it. (And that decision should, > obviously, be made calmly, independent of any particular patch series.) You know what? I completely agree with you that drm-panel would be a good fit for drm-misc. It's effectively part of the DRM/KMS core and used by most drivers. But it's never been treated that way. Maybe it is because it's been maintained in a separate tree from the very beginning, perhaps that was a mistake in the first place. Then again, back when drm-panel was started we didn't have group maintainership, so none of the existing trees would've been a good fit. In the end, I keep getting back to the question that everybody except me seems to know the answer to: why would there be a difference in how contributors behave depending on the number of maintainers? Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
> Hi,
>
> I'm currently trying to mmap the memory of an OpenGL texture I've created by
> doing the following:
>
> std::vector image_attribs = {
> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
> EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
> EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
> EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
> EGL_NONE
> };
> glGenTextures( 1, &texID );
> glBindTexture( GL_TEXTURE_2D, texID );
> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), &image_attribs[0]
> );
> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
> &nplanes, &modifiers)
> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
> offsets)
>
> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>
> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
> while
> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
> an Intel CherryTrail (i915).
>
> Is there an obvious reason why I'm not able to mmap the texture FD with
> PROT_WRITE flags?
> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
> have guessed that
> this should be possible. Or is it only true for specific GEM buffers not
> textures created using
> eglCreateDRMImageMESA?
From a quick look the mesa/libdrm (depending upon driver) handle2fd
implementations don't set the DRM_RDWR flag when asking PRIME for a
dma-buf fd, which means you fd doesn't have write permissions. Which means
mmap with writing allowed will fail.
Not sure how to fix that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #20 from Alex Deucher --- (In reply to Jean-François Fortin Tam from comment #19) > What would be the equivalent in the systemd/journalctl world? Apparently > Fedora 25 doesn't generate Xorg.log files anymore, the last modification > timestamp on that one file is october 10th 2016... See this page for how to access the xorg log output on various versions of fedora: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
Hi,
I'm currently trying to mmap the memory of an OpenGL texture I've
created by
doing the following:
std::vector image_attribs = {
EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
EGL_NONE
};
glGenTextures( 1, &texID );
glBindTexture( GL_TEXTURE_2D, texID );
eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(),
&image_attribs[0] );
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
&nplanes, &modifiers)
eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
offsets)
struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
while
using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6
on an Intel CherryTrail (i915).
Is there an obvious reason why I'm not able to mmap the texture FD with
PROT_WRITE flags?
Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I
would have guessed that
this should be possible. Or is it only true for specific GEM buffers not
textures created using
eglCreateDRMImageMESA?
Regards,
Volker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm: Rely on mode_config data for fb_helper initialization
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates. The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.
//
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
//
Changes since v1:
- Rebased on top of the tip of drm-misc-next.
- Remove mention to sti since a proper fix got merged.
Suggested-by: Daniel Vetter
Signed-off-by: Gabriel Krisman Bertazi
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 3 +--
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
drivers/gpu/drm/arm/malidp_drv.c | 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 3 +--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 -
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +--
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 15 +++
drivers/gpu/drm/drm_fb_helper.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 3 +--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c| 3 +--
drivers/gpu/drm/imx/imx-drm-core.c| 3 +--
drivers/gpu/drm/meson/meson_drv.c | 1 -
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +--
drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +--
drivers/gpu/drm/qxl/qxl_fb.c | 1 -
drivers/gpu/drm/radeon/radeon_fb.c| 1 -
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 5 +
drivers/gpu/drm/sti/sti_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 4 +---
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
drivers/gpu/drm/udl/udl_fb.c | 3 +--
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
drivers/gpu/drm/virtio/virtgpu_fb.c | 1 -
drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
include/drm/drm_fb_cma_helper.h | 7 +++
include/drm/drm_fb_helper.h | 3 +--
38 files changed, 43 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..36ce3cac81ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -374,7 +374,6 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
&amdgpu_fb_helper_funcs);
ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
-adev->mode_info.num_crtc,
AMDGPUFB_CONN_LIMIT);
if (ret) {
kfree(rfbdev);
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 0b6eaa49a1db..8d8344ed655e 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -135,8 +135,7 @@ static int arcpgu_load(struct drm_device *drm)
drm_kms_helper_poll_init(drm);
arcpgu->fbdev = drm_fbdev_cma_init(drm, 16,
- drm->mode_config.num_crtc,
- drm->mode_config.num_connector);
+ drm->mode_config.num_connector);
if (IS_ERR(arcpgu->fbdev)) {
ret = PTR_ERR(arcpgu->fbdev);
arcpgu->fbdev = NULL;
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/g
Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages
On Wed, Jan 04, 2017 at 08:42:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DRM_UT_CORE generates way too much noise usually, so having the
> framebuffer init failures use DRM_UT_CORE is a pain when trying to
> find out the reason why you failed in creating a framebuffer.
> Let's use DRM_UT_KMS for these debug messages instead.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 66
> ++--
> 1 file changed, 33 insertions(+), 33 deletions(-)
> [...]
> @@ -15940,17 +15940,17 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
>*/
> if (INTEL_INFO(dev_priv)->gen < 4 &&
> tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> - DRM_DEBUG("tiling_mode must match fb modifier exactly on
> gen2/3\n");
> + DRM_DEBUG_KMS("tiling_mode must match fb modifier exactly on
> gen2/3\n");
> return -EINVAL;
> }
>
> pitch_limit = intel_fb_pitch_limit(dev_priv, mode_cmd->modifier[0],
> mode_cmd->pixel_format);
> if (mode_cmd->pitches[0] > pitch_limit) {
> - DRM_DEBUG("%s pitch (%u) must be at less than %d\n",
> - mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
> - "tiled" : "linear",
> - mode_cmd->pitches[0], pitch_limit);
> + DRM_DEBUG_KMS("%s pitch (%u) must be at less than %d\n",
While at it: s/at less than/at most/
Reviewed-by: Imre Deak
> + mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
> + "tiled" : "linear",
> + mode_cmd->pitches[0], pitch_limit);
> return -EINVAL;
> }
>
> @@ -15960,9 +15960,9 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
>*/
> if (tiling != I915_TILING_NONE &&
> mode_cmd->pitches[0] != i915_gem_object_get_stride(obj)) {
> - DRM_DEBUG("pitch (%d) must match tiling stride (%d)\n",
> - mode_cmd->pitches[0],
> - i915_gem_object_get_stride(obj));
> + DRM_DEBUG_KMS("pitch (%d) must match tiling stride (%d)\n",
> + mode_cmd->pitches[0],
> + i915_gem_object_get_stride(obj));
> return -EINVAL;
> }
>
> @@ -15975,16 +15975,16 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
> break;
> case DRM_FORMAT_XRGB1555:
> if (INTEL_GEN(dev_priv) > 3) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> case DRM_FORMAT_ABGR:
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
> INTEL_GEN(dev_priv) < 9) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> @@ -15992,15 +15992,15 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
> case DRM_FORMAT_XRGB2101010:
> case DRM_FORMAT_XBGR2101010:
> if (INTEL_GEN(dev_priv) < 4) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> case DRM_FORMAT_ABGR2101010:
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> @@ -16009,14 +16009,14 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
> case DRM_FORMAT_YVYU:
> case DRM_FORMAT_VYUY:
> if (INTEL_GEN(dev_priv) < 5) {
> -
Re: [PATCH 6/9] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()
On Wed, Jan 04, 2017 at 08:42:29PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > intel_fill_fb_info() should pass the correct plane index to > _intel_compute_tile_offset() once we start to care about the AUX > surface. > > Signed-off-by: Ville Syrjälä This changes how x/y and offset is calculated already now for planes with a cpp different than that of plane 0, but the end result remains the same: Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 0ca0dbccc005..5fee5a7ac9a4 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -2525,7 +2525,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv, > intel_fb->normal[i].y = y; > > offset = _intel_compute_tile_offset(dev_priv, &x, &y, > - fb, 0, fb->pitches[i], > + fb, i, fb->pitches[i], > DRM_ROTATE_0, tile_size); > offset /= tile_size; > > -- > 2.10.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99549] pp: Failed to translate a shader
https://bugs.freedesktop.org/show_bug.cgi?id=99549 --- Comment #3 from Marek Olšák --- That's up to you. I'm not so into fixing the postprocessing, because the options shouldn't be put into drirc, because the filters change what the OpenGL spec specifies. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #11 from Alex Deucher --- (In reply to fin4478 from comment #8) > Alex, thanks for the new firmware. Still Bios recognition errors at boot, > but otherwise ok. > > [3.461112] [drm] BIOS signature incorrect 20 7 > [3.461117] amdgpu :01:00.0: Invalid PCI ROM header signature: > expecting 0xaa55, got 0x > This is harmless. The driver tries several methods to fetch the vbios image. The driver would not load at all if it failed to fetch the vbios image. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: sti: Prevent race on fbdev initialization
Gabriel Krisman Bertazi writes:
> Scheduling the output_poll_work before calling bind_all to create the
> crtcs can race the fbdev initialization with the components
> initialization (i.e. crtc initialization). One side effect is that we
> may call drm_fbdev_cma_init with a zeroed num_crtc value, crashing the
> fbdev allocation.
This is no longer true after
8953e9ee0ce5 ("drm/sti: create fbdev at binding") # drm-misc-next.
That commit moved the fbdev initialization out of the output_poll_work,
forcing it to happen after creating crtcs, so this patch is no longer
necessary. I'll resend a v2 of the series without it.
--
Gabriel Krisman Bertazi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/vma-fix-for-4.10
Hi Dave, here's Maarten's backport of the vma fixes for v4.10. BR, Jani. The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637: Linux 4.10-rc6 (2017-01-29 14:25:17 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/topic/vma-fix-for-4.10-2017-02-02 for you to fetch changes up to e8fe4f4b2b7b93048729538321c681c0cff33b39: drm/i915: Track pinned vma in intel_plane_state (2017-02-01 11:45:21 +0200) Chris Wilson (1): drm/i915: Track pinned vma in intel_plane_state Maarten Lankhorst (1): drm/atomic: Unconditionally call prepare_fb. drivers/gpu/drm/drm_atomic_helper.c | 9 --- drivers/gpu/drm/i915/i915_drv.h | 16 +--- drivers/gpu/drm/i915/intel_atomic_plane.c | 20 + drivers/gpu/drm/i915/intel_display.c | 125 ++ drivers/gpu/drm/i915/intel_drv.h | 9 ++- drivers/gpu/drm/i915/intel_fbc.c | 52 + drivers/gpu/drm/i915/intel_fbdev.c| 4 +- drivers/gpu/drm/i915/intel_sprite.c | 8 +- 8 files changed, 99 insertions(+), 144 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Tue, 31 Jan 2017, Thierry Reding wrote: > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: >> I would love for drm-panel to be moved under -misc. > > Like that's going to magically motivate people to spend their time > reviewing other patches. The only thing that group maintainership adds > is redundancy. Adding redundancy is not an insignificant thing. I think it can be quite liberating to not have everything and everybody depend on you. You can defer to others when you're busy, tired, sick, whatever. Things still move on. And I don't think redundancy is the only thing that group maintainership adds. You'll have maintainers that complement each other, with different skill sets and abilities and experience. They don't all look at the same things. As maintainers tend to be more senior folks, I find sharing the load of the more mundane tasks of maintainership free up their time to contribute more of their technical skills to the project, for example review. It's just my personal view on i915, but I think people take more responsibility of their own work, instead of just sending patches and waiting for stuff to happen, when they have commit access. But you have to trust the people. I didn't intend for this to become a kind of sales pitch, but I do think drm-panel would be a good fit for drm-misc. Personally I think it's your call, but I think you should think about it. (And that decision should, obviously, be made calmly, independent of any particular patch series.) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99549] pp: Failed to translate a shader
https://bugs.freedesktop.org/show_bug.cgi?id=99549 --- Comment #2 from LoneVVolf --- After seeing marek reply I experimented a bit with PP_DEBUG and post processing filters. Half of the error messages comes from pp_jimenezmlaa filter , the other half from pp_jimenezmlaa_color . disabling those filters through driconf does make the corresponding error messages disappear. The error messages started recently, want me to try bisecting to find out what caused them ? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
On Thu, Feb 02, 2017 at 02:33:54PM +0100, Lucas Stach wrote: > Am Donnerstag, den 02.02.2017, 11:44 + schrieb Chris Wilson: > > @@ -192,6 +188,8 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu > > *mmu, > > list_del_init(&m->scan_node); > > } > > > > + mode = DRM_MM_INSERT_EVICT; > > + > > /* > > * We removed enough mappings so that the new allocation will > > * succeed. Ensure that the MMU will be flushed before the > > This needs a rebase on the etnaviv for 4.11 pull, that removes the hack > mentioned in the comment above. Otherwise the code change looks fine. Is that pull request already on the list and/or in drm-next? Chris' patch fell a bit through the cracks, but since it's fairly big I'd like to get it into 4.11 still if possible, instead of keeping it in drm-misc for a few weeks to route around the merge window blackout ... Otherwise I guess 4.12 it is, but I'll still push it into drm-misc-next next week if possible (we have drm-misc-next-fixes for bugfixes for the merge window, to be able to keep merging feature work). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Fix Yf tile width
On Wed, Jan 04, 2017 at 08:42:28PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Based on empirical evidence the display engine (at least) always
> treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions
> change based on the pixel format. Let's adjust our code to match the
> hardware.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
BSpec "Address Tiling Function Introduction/Linear vs Tiled Storage":
"""
Note that the dimensions of tiles are irrespective of the data contained
within – e.g., a tile can hold twice as many 16-bit pixels (256
pixels/row x 8 rows = 2K pixels) than 32-bit pixels (128 pixels/row x 8
rows = 1K pixels).
"""
"Tile-Yf Format":
"""
The 64 Byte block is always 4-high. Width (in pixels) is defined by bpp.
"""
Then it continues to specify the different tile aspect ratios for
different bpps which contradict the above. This aspect ratio definition
is what matches the current code. Filing a BSpec issue for this would be
good.
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 ++--
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc398743e941..0ca0dbccc005 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2070,20 +2070,12 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> else
> return 512;
> case I915_FORMAT_MOD_Yf_TILED:
> - switch (cpp) {
> - case 1:
> - return 64;
> - case 2:
> - case 4:
> - return 128;
> - case 8:
> - case 16:
> - return 256;
> - default:
> - MISSING_CASE(cpp);
> - return cpp;
> - }
> - break;
> + /*
> + * Bspec seems to suggest that the Yf tile width would
> + * depend on the cpp. In reality it doesn't, at least
> + * as far as the display engine is concerned.
> + */
> + return 128;
> default:
> MISSING_CASE(fb->modifier);
> return cpp;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #10 from Steven A. Falco --- Thanks for the information on building a new kernel. I'll give that a try. I'm running Fedora 25, but I think I can follow your Debian instructions. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
On Thu, Feb 2, 2017 at 6:44 AM, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> v2: Search for holes both high and low. Rename flags to mode.
> v3: Discover rb_entry_safe() and use it!
> v4: Kerneldoc for enum drm_mm_insert_mode.
>
I haven't had drm_mm.c paged into my head in a while, but the patch
appears to do the right thing. The series is:
Reviewed-by: Alex Deucher
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Rob Clark
> Cc: Thierry Reding
> Cc: Stephen Warren
> Cc: Alexandre Courbot
> Cc: Eric Anholt
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
> drivers/gpu/drm/armada/armada_gem.c | 4 +-
> drivers/gpu/drm/drm_mm.c | 488
> +++
> drivers/gpu/drm/drm_vma_manager.c| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 3 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
> drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
> drivers/gpu/drm/sis/sis_mm.c | 6 +-
> drivers/gpu/drm/tegra/gem.c | 4 +-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
> drivers/gpu/drm/via/via_mm.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
> include/drm/drm_mm.h | 184 +-
> 23 files changed, 470 insertions(+), 447 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index e4eb6dd3798a..0335c2f331e9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
> {
> struct amdgpu_gtt_mgr *mgr = man->priv;
> struct drm_mm_node *node = mem->mm_node;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long fpfn, lpfn;
> int r;
>
> @@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager
> *man,
> else
> lpfn = man->size;
>
> - if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
> - sflags = DRM_MM_SEARCH_BELOW;
> - aflags = DRM_MM_CREATE_TOP;
> - }
> + mode = DRM_MM_INSERT_BEST;
> + if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
> + mode = DRM_MM_INSERT_HIGH;
>
> spin_lock(&mgr->lock);
> - r = drm_mm_insert_node_in_range_generic(&mgr->mm, node,
> mem->num_pages,
> - mem->page_alignment, 0,
> - fpfn, lpfn, sflags, aflags);
> + r = drm_mm_insert_node_in_range(&mgr->mm, node,
> + mem->num_pages, mem->page_alignment,
> 0,
> + fpfn, lpfn, mode);
> spin_unlock(&mgr->lock);
>
> if (!r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index ac9007986c11..9e577e3d3147 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
> *man,
> struct amdgpu_vram_mgr *mgr = man->priv;
> struct drm_mm *mm = &mgr->mm;
> struct drm_mm_node *nodes;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Tue, Jan 31, 2017 at 10:51:06PM +0100, Thierry Reding wrote: > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > [...] > > As is, I'm stuck out here with my panel driver I submitted on December > > 14th completely ignored, and no other developer will look at it because > > their review doesn't count and only yours does. > > For the record, until earlier today when Daniel started to review your > patches, no doubt in response to this discussion, there was exactly one > response to one of your clock driver patches in the series. > > So can we please stop singling out panel drivers? This is a general > problem that we've had across the kernel, or at least the ARM and > related parts of it, for as long as I can remember. I only looked at that as part of the drm-misc small drivers experiment, to help kickstart a review market. I didn't look at the panel stuff. And the reason I looked at that right now is because right now we started this experiment. That has nothing at all to do with what's going on with drm-panel. If you look at drm-misc, the dsi patches for vc4 have now landed, but the panel driver for the rpi 7" touchscreen hasn't. And Eric had the dsi patches queued in his vc4 tree since a while, just waiting to be sent out in a pull request. We've only gone through the fast review+merging to drm-misc to try out the new process. So not related at all I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #19 from Jean-François Fortin Tam --- What would be the equivalent in the systemd/journalctl world? Apparently Fedora 25 doesn't generate Xorg.log files anymore, the last modification timestamp on that one file is october 10th 2016... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane
On Wed, Jan 04, 2017 at 08:42:27PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> To make life easier let's allow skl_plane_stride() to be called for the
> AUX surface even when there is no AUX surface. Avoids special cases in
> the callers.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4d514ca1da88..bc398743e941 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3261,7 +3261,12 @@ static void skl_detach_scalers(struct intel_crtc
> *intel_crtc)
> u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
>unsigned int rotation)
> {
> - u32 stride = intel_fb_pitch(fb, plane, rotation);
> + u32 stride;
> +
> + if (plane >= fb->format->num_planes)
> + return 0;
> +
> + stride = intel_fb_pitch(fb, plane, rotation);
>
> /*
>* The stride is either expressed as a multiple of 64 bytes chunks for
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/9] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()
On Wed, Jan 04, 2017 at 08:42:26PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's try to keep the alignment requirements in one place, and so
> towards that end let's move the AUX_DIST alignment handling into
> intel_surf_alignment() alongside the main surface alignment stuff.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f0cb80aba89a..4d514ca1da88 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2163,6 +2163,10 @@ static unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> {
> struct drm_i915_private *dev_priv = to_i915(fb->dev);
>
> + /* AUX_DIST needs only 4K alignment */
> + if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
> + return 4096;
> +
> switch (fb->modifier) {
> case DRM_FORMAT_MOD_NONE:
> return intel_linear_alignment(dev_priv);
> @@ -2452,13 +2456,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
> const struct drm_framebuffer *fb = state->base.fb;
> unsigned int rotation = state->base.rotation;
> int pitch = intel_fb_pitch(fb, plane, rotation);
> - u32 alignment;
> -
> - /* AUX_DIST needs only 4K alignment */
> - if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
> - alignment = 4096;
> - else
> - alignment = intel_surf_alignment(fb, plane);
> + u32 alignment = intel_surf_alignment(fb, plane);
>
> return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
> rotation, alignment);
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
Am Donnerstag, den 02.02.2017, 11:44 + schrieb Chris Wilson:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> v2: Search for holes both high and low. Rename flags to mode.
> v3: Discover rb_entry_safe() and use it!
> v4: Kerneldoc for enum drm_mm_insert_mode.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Rob Clark
> Cc: Thierry Reding
> Cc: Stephen Warren
> Cc: Alexandre Courbot
> Cc: Eric Anholt
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
> drivers/gpu/drm/armada/armada_gem.c | 4 +-
> drivers/gpu/drm/drm_mm.c | 488
> +++
> drivers/gpu/drm/drm_vma_manager.c| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 3 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
> drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
> drivers/gpu/drm/sis/sis_mm.c | 6 +-
> drivers/gpu/drm/tegra/gem.c | 4 +-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
> drivers/gpu/drm/via/via_mm.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
> include/drm/drm_mm.h | 184 +-
> 23 files changed, 470 insertions(+), 447 deletions(-)
[...]
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index f503af462dad..004456534e48 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -107,6 +107,7 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> struct drm_mm_node *node, size_t size)
> {
> struct etnaviv_vram_mapping *free = NULL;
> + enum drm_mm_insert_mode mode = DRM_MM_INSERT_LOW;
> int ret;
>
> lockdep_assert_held(&mmu->lock);
> @@ -117,15 +118,10 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> struct list_head list;
> bool found;
>
> - /*
> - * XXX: The DRM_MM_SEARCH_BELOW is really a hack to trick
> - * drm_mm into giving out a low IOVA after address space
> - * rollover. This needs a proper fix.
> - */
> ret = drm_mm_insert_node_in_range(&mmu->mm, node,
> - size, 0, mmu->last_iova, ~0UL,
> - mmu->last_iova ? DRM_MM_SEARCH_DEFAULT :
> DRM_MM_SEARCH_BELOW);
> -
> + size, 0, 0,
> + mmu->last_iova, U64_MAX,
> + mode);
> if (ret != -ENOSPC)
> break;
>
> @@ -140,7 +136,7 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> }
>
> /* Try to retire some entries */
> - drm_mm_scan_init(&scan, &mmu->mm, size, 0, 0, 0);
> + drm_mm_scan_init(&scan, &mmu->mm, size, 0, 0, mode);
>
> found = 0;
> INIT_LIST_HEAD(&list);
> @@ -192,6 +188,8 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> list_del_init(&m->scan_node);
> }
>
> + mode = DRM_MM_INSERT_EVICT;
> +
> /*
>* We removed enough mappings so that the new allocation will
>* succeed. Ensure that the MMU will be flushed before the
This needs a rebase on the etnaviv for 4.11 pull, that removes the hack
mentioned in the comment above. Otherwise the code change looks fine.
Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.free
Re: [Intel-gfx] [PATCH 2/9] drm/i915: Plumb drm_framebuffer into more places
On Wed, Jan 04, 2017 at 08:42:25PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that framebuffers can be used even before calling
> drm_framebuffer_init() we can start to plumb them into more places,
> instead of passing individual pieces for fb metadata.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 127
> +++
> drivers/gpu/drm/i915/intel_drv.h | 11 +--
> drivers/gpu/drm/i915/intel_fbdev.c | 4 +-
> 3 files changed, 57 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e2150a64860c..f0cb80aba89a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2050,10 +2050,13 @@ static unsigned int intel_tile_size(const struct
> drm_i915_private *dev_priv)
> return IS_GEN2(dev_priv) ? 2048 : 4096;
> }
>
> -static unsigned int intel_tile_width_bytes(const struct drm_i915_private
> *dev_priv,
> -uint64_t fb_modifier, unsigned int
> cpp)
> +static unsigned int
> +intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
> {
> - switch (fb_modifier) {
> + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> + unsigned int cpp = fb->format->cpp[plane];
> +
> + switch (fb->modifier) {
> case DRM_FORMAT_MOD_NONE:
> return cpp;
> case I915_FORMAT_MOD_X_TILED:
> @@ -2082,41 +2085,38 @@ static unsigned int intel_tile_width_bytes(const
> struct drm_i915_private *dev_pr
> }
> break;
> default:
> - MISSING_CASE(fb_modifier);
> + MISSING_CASE(fb->modifier);
> return cpp;
> }
> }
>
> -unsigned int intel_tile_height(const struct drm_i915_private *dev_priv,
> -uint64_t fb_modifier, unsigned int cpp)
> +static unsigned int
> +intel_tile_height(const struct drm_framebuffer *fb, int plane)
> {
> - if (fb_modifier == DRM_FORMAT_MOD_NONE)
> + if (fb->modifier == DRM_FORMAT_MOD_NONE)
> return 1;
> else
> - return intel_tile_size(dev_priv) /
> - intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
> + return intel_tile_size(to_i915(fb->dev)) /
> + intel_tile_width_bytes(fb, plane);
> }
>
> /* Return the tile dimensions in pixel units */
> -static void intel_tile_dims(const struct drm_i915_private *dev_priv,
> +static void intel_tile_dims(const struct drm_framebuffer *fb, int plane,
> unsigned int *tile_width,
> - unsigned int *tile_height,
> - uint64_t fb_modifier,
> - unsigned int cpp)
> + unsigned int *tile_height)
> {
> - unsigned int tile_width_bytes =
> - intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
> + unsigned int tile_width_bytes = intel_tile_width_bytes(fb, plane);
> + unsigned int cpp = fb->format->cpp[plane];
>
> *tile_width = tile_width_bytes / cpp;
> - *tile_height = intel_tile_size(dev_priv) / tile_width_bytes;
> + *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes;
> }
>
> unsigned int
> -intel_fb_align_height(struct drm_device *dev, unsigned int height,
> - uint32_t pixel_format, uint64_t fb_modifier)
> +intel_fb_align_height(const struct drm_framebuffer *fb,
> + int plane, unsigned int height)
> {
> - unsigned int cpp = drm_format_plane_cpp(pixel_format, 0);
> - unsigned int tile_height = intel_tile_height(to_i915(dev), fb_modifier,
> cpp);
> + unsigned int tile_height = intel_tile_height(fb, plane);
>
> return ALIGN(height, tile_height);
> }
> @@ -2158,21 +2158,23 @@ static unsigned int intel_linear_alignment(const
> struct drm_i915_private *dev_pr
> return 0;
> }
>
> -static unsigned int intel_surf_alignment(const struct drm_i915_private
> *dev_priv,
> - uint64_t fb_modifier)
> +static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
> + int plane)
> {
> - switch (fb_modifier) {
> + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> +
> + switch (fb->modifier) {
> case DRM_FORMAT_MOD_NONE:
> return intel_linear_alignment(dev_priv);
> case I915_FORMAT_MOD_X_TILED:
> - if (INTEL_INFO(dev_priv)->gen >= 9)
> + if (INTEL_GEN(dev_priv) >= 9)
> return 256 * 1024;
> return 0;
> case I915_FORMAT_MOD_Y_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> return 1 * 1024 * 1024;
> default:
> - MISSING_CASE(fb_modifier);
> + MISSING_CASE(fb->modifier);
>
[Bug 97861] [amdgpu SI] purple line is visible on left side of the screen connected by HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=97861 --- Comment #4 from Elia Argentieri --- Same problem on R7 370 except that my monitor shows a black screen and reports "frequency not supported". -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Dear Thierry, 2017년 02월 01일 23:44에 Thierry Reding 이(가) 쓴 글: > On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote: >> >> >> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글: >>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: Thierry Reding writes: > [ Unknown signature status ] > On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote: >> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote: >>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: > Dear Thierry, > > Could you please review this patch? Thierry, I think this patch has been reviewed enough but no comment from you. Seems you are busy. I will pick up this. >>> >>> Sorry, but that's not how it works. This patch has gone through 8 >>> revisions within 4 weeks, and I tend to ignore patches like that until >>> the dust settles. >>> >> >> Seems like the dust was pretty settled. It was posted on 1/11, pinged on >> 1/24, >> and picked up on 1/31. I don't think it's unreasonable to take it through >> another tree after that. >> >> I wonder if drm_panel would benefit from the -misc group maintainership >> model >> as drm_bridge does. By spreading out the workload, the high-maintenance >> patches would hopefully find someone to shepherd them through. > > Except that nobody except me really cares. If we let people take patches > through separate trees or group-maintained trees they'll likely go in > without too much thought. DRM panel is somewhat different from core DRM > in this regard because its infrastructure is minimal and there's little > outside the panel-simple driver. So we're still at a stage where we need > to fine-tune what drivers should look like and how we can improve. I would love to care and participate in review, but with the structure of your tree you're the only one whose review counts, so I don't participate. >>> >>> Really? What exactly do you think is special about the structure of my >>> tree? I require patches to be on dri-devel (I pick them up from the >>> patchwork instance at freedesktop.org), the tree is publicly available >>> and reviewed-by tags get picked up automatically by patchwork. >>> >>> The panel tree works exactly like any other maintainer tree. And my >>> review is *not* the only one that counts. I appreciate every Reviewed-by >>> tag I see on panel patches because it means that I don't have to look as >>> closely as I have to otherwise. >> >> I don't think the panel tree works exactly like other maintainer tree. >> >> I'd like to recommend you to read below Greg's blog. This blog says >> about *Role of a Linux Kernel Maintainer*. >> http://www.kroah.com/log/linux/maintainer_pledge.html > > Okay, now you're being unfair. You can't compare people to Greg. He > is beyond human. > >> Especially, I'd like to emphasize below things, >> - I will review your patch within 1-2 weeks. >> - I will offer semi-constructive criticism of your patches. >> - I will let you know the status of your patch if it is rejected, or >> if it is accepted, what tree it has gone into, where you can find it, >> and when you can expect to see it merged into Linus's tree. > > First, this is a pledge by Greg, and you can hardly hold me to this if > it isn't coming from me. I agree that the above is ideal, but I'm also > much less efficient as a maintainer as Greg. So are many others. There > simply isn't enough bandwidth to be able to do the above in every case > in addition to the day job and real life. > > That said, when I do get around to review patches I think I'm pretty > good at the second and third points, though. Agree. You did well really. > > Secondly, it's very convenient how you focus on the maintainers' duties > and completely leave out what maintainers expect from contributors. If > you go and read some of the references linked to by Greg's post, maybe > you'll understand my position a little better as well. > >> Why do you ignore contributor's patch? Even though the patch is ugly, >> I think you need to point it out and give your feedback to >> contributers as a maintainer. >> There was some cases I often missed to review with busy work but I >> don't ignore contributor's patch. > > I will admit that ignoring the patch in this instance may not have been > the best course of action. But this particular instance was making it > exceptionally difficult for me, which is why I was going to shunt this > until the next cycle so that I could focus on getting the less tiresome > patches in. > > And interestingly nobody seems to care about this current discussion > either. So yesterday somebody requested another change to the DT binding > after this discussion had started, and after I had NAK'ed the patch, but > then I see that today there's y
Re: [PATCH 5/6] drm/i915: enable scrambling
On Thu, Feb 02, 2017 at 04:15:21PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/2/2017 3:32 PM, Ville Syrjälä wrote:
> > On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
> >>> On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> Geminilake platform has a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_ddi.c | 5 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 42
> +++
> 4 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 495b789..cc85892 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7807,6 +7807,8 @@ enum {
> #define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
> #define TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
> #define TRANS_DDI_BFI_ENABLE (1<<4)
> +#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
> +#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
>
> /* DisplayPort Transport Control */
> #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 9a9a670..aea81ce 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct
> drm_crtc *crtc)
> temp |= TRANS_DDI_MODE_SELECT_HDMI;
> else
> temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> +if (IS_GEMINILAKE(dev_priv)) {
> +temp |=
> intel_hdmi_check_scrambling(intel_encoder,
> +
> &intel_crtc->config->base.adjusted_mode);
> +}
> } else if (type == INTEL_OUTPUT_ANALOG) {
> temp |= TRANS_DDI_MODE_SELECT_FDI;
> temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 393f243..aafce7f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state);
> +uint32_t intel_hdmi_check_scrambling(struct intel_encoder
> *intel_encoder,
> +struct drm_display_mode *mode);
> void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
> enable);
>
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ebae2bd..92dd9bc 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct
> drm_connector *connector)
> intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> }
>
> +static void
> +intel_hdmi_enable_scrambling(struct drm_connector *connector)
> +{
> +struct drm_i915_private *dev_priv = connector->dev->dev_private;
> +struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> +struct i2c_adapter *adapter =
> +intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus);
> +
> +if (!drm_enable_scrambling(connector, adapter, true))
> +DRM_ERROR("Request to enable scrambling failed\n");
> +}
> >>> I don't like hiding this somewhere deep like this. It should be
> >>> somewhere much higher up.
> >> Why ? All we need to do here is enable two bits in transcoder control
> >> register, which is already being
> >> programmed in a calling function, so I dont see the use case, but I
> >> might be missing some bigger picture.
> >> Can you please elaborate on this ?
> > We're talking to the display here, which is rather surprising to happen
> > from a function thing that on the fir
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 12:11:29PM +, Tvrtko Ursulin wrote:
>
> On 02/02/2017 09:47, Juergen Gross wrote:
> >Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> >disposable private objects") introduced a regression for the kernel
> >running as Xen dom0: when switching to graphics mode a GPU HANG
> >occurred.
> >
> >Reason seems to be a missing adaption similar to that done in
> >commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> >to i915_gem_object_get_pages_internal().
> >
> >So limit the maximum page order to be used according to the maximum
> >swiotlb segment size instead to the complete swiotlb size.
> >
> >Signed-off-by: Juergen Gross
> >---
> >Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
> >with i915 graphics.
> >---
> > drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
> >b/drivers/gpu/drm/i915/i915_gem_internal.c
> >index 4b3ff3e..d09c749 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_internal.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> >@@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
> >drm_i915_gem_object *obj)
> >
> > max_order = MAX_ORDER;
> > #ifdef CONFIG_SWIOTLB
> >-if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
> >-max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
> >+if (swiotlb_nr_tbl()) {
> >+unsigned int max_segment;
> >+
> >+max_segment = swiotlb_max_segment();
> >+if (max_segment) {
> >+max_segment = max_t(unsigned int, max_segment,
> >+PAGE_SIZE) >> PAGE_SHIFT;
> >+max_order = min(max_order, ilog2(max_segment));
> >+}
> >+}
> > #endif
> >
> > gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >
>
> Looks OK to me. We could bikeshed it to only use
> swiotlb_max_segment() which I think was the intention when that API
> was added but can leave that for the future.
>
> Reviewed-by: Tvrtko Ursulin
Pushed, I imagine this has been added to the list of sg cleanups you
have :)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On 02/02/2017 09:47, Juergen Gross wrote:
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption similar to that done in
commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().
So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.
Signed-off-by: Juergen Gross
---
Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
with i915 graphics.
---
drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 4b3ff3e..d09c749 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
- max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
+ if (swiotlb_nr_tbl()) {
+ unsigned int max_segment;
+
+ max_segment = swiotlb_max_segment();
+ if (max_segment) {
+ max_segment = max_t(unsigned int, max_segment,
+ PAGE_SIZE) >> PAGE_SHIFT;
+ max_order = min(max_order, ilog2(max_segment));
+ }
+ }
#endif
gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
Looks OK to me. We could bikeshed it to only use swiotlb_max_segment()
which I think was the intention when that API was added but can leave
that for the future.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On Thu, Feb 02, 2017 at 11:50:59AM +0100, Neil Armstrong wrote:
> On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> > On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> >> The platform driver name is currently "meson" which can lead to some
> >> confusion, this patch renames it to "meson-drm" and removes the owner
> >> attribute.
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> drivers/gpu/drm/meson/meson_drv.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> >> b/drivers/gpu/drm/meson/meson_drv.c
> >> index ff1f601..380bde7 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.c
> >> +++ b/drivers/gpu/drm/meson/meson_drv.c
> >> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device
> >> *pdev)
> >>.probe = meson_drv_probe,
> >>.remove = meson_drv_remove,
> >>.driver = {
> >> - .owner = THIS_MODULE,
>
> Hi Daniel,
>
> > I don't get why you remove this, generally that will lead to trouble of
> > being able to unload code that's still in use ...
>
> Indeed, but since a (long ?) time, the owner field is now populated by the
> platform_driver_register() core code.
>
> >
> > Otherwise ack.
> >
> > Now, do you want to get this landed as part of the small drivers in
> > drm-mis experiment?
>
> I have a PR ready, but it can go through this experiment, yes.
If you want to give it a spin, you need:
- fdo account https://www.freedesktop.org/wiki/AccountRequests/
- drm-misc group access
- dim set up for drm-misc, see
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html and
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
For questions it's best to pipe up #dri-devel.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers
Sure, Thanks for the information, will add that in V2. Regards Shashank -Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Thursday, February 2, 2017 4:55 PM To: Sharma, Shashank ; dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; ville.syrj...@linux.intel.com Cc: jose.ab...@synopsys.com; =daniel.vet...@intel.com; Thierry Reding ; thierry.red...@gmail.com Subject: Re: [Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers On Wed, 01 Feb 2017, Shashank Sharma wrote: > From: Thierry Reding > > SCDC is a mechanism defined in the HDMI 2.0 specification that allows > the source and sink devices to communicate. > > This commit introduces helpers to access the SCDC and provides the > symbolic names for the various registers defined in the specification. > > Signed-off-by: Thierry Reding One process note, you need to add your own Signed-off-by under the original author's sign-off, even when you're posting them unchanged. Signed-off-by means https://developercertificate.org/ BR, Jani. > --- > Documentation/gpu/drm-kms-helpers.rst | 12 > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/drm_scdc_helper.c | 111 > include/drm/drm_scdc_helper.h | 132 > ++ > 4 files changed, 257 insertions(+), 1 deletion(-) create mode 100644 > drivers/gpu/drm/drm_scdc_helper.c create mode 100644 > include/drm/drm_scdc_helper.h > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index 03040aa..7592756 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -217,6 +217,18 @@ EDID Helper Functions Reference .. kernel-doc:: > drivers/gpu/drm/drm_edid.c > :export: > > +SCDC Helper Functions Reference > +=== > + > +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > + :doc: scdc helpers > + > +.. kernel-doc:: include/drm/drm_scdc_helper.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > + :export: > + > Rectangle Utilities Reference > = > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > 92de399..ad91cd9 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o > drm_debugfs_crc.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_probe_helper.o \ > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \ > - drm_simple_kms_helper.o drm_modeset_helper.o > + drm_simple_kms_helper.o drm_modeset_helper.o \ > + drm_scdc_helper.o > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o diff > --git a/drivers/gpu/drm/drm_scdc_helper.c > b/drivers/gpu/drm/drm_scdc_helper.c > new file mode 100644 > index 000..fe0e121 > --- /dev/null > +++ b/drivers/gpu/drm/drm_scdc_helper.c > @@ -0,0 +1,111 @@ > +/* > + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person > +obtaining a > + * copy of this software and associated documentation files (the > +"Software"), > + * to deal in the Software without restriction, including without > +limitation > + * the rights to use, copy, modify, merge, publish, distribute, sub > +license, > + * 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 NON-INFRINGEMENT. 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. > + */ > + > +#include > + > +#include > + > +/** > + * DOC: scdc helpers > + * > + * Status and Control Data Channel (SCDC) is a mechanism introduced > +by the > + * HDMI 2.0 specification. It is a point-to-point protocol that > +allows the > + * HDMI source and HDMI sink to exchange data. The same I2C interface > +that > + * is used to access EDID serves as the transport mechanism for SCDC. > + */ > + > +#define SCDC_I2C_SLAVE_ADDRESS 0x54 > + > +/** > + * drm_scdc_read - read a block of data from SCDC > + * @
[PATCH v4 2/2] drm: kselftest for drm_mm and bottom-up allocation
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 100 +++
2 files changed, 101 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 6a4575fdc1c0..37bbdac52896 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -17,6 +17,7 @@ selftest(align32, igt_align32)
selftest(align64, igt_align64)
selftest(evict, igt_evict)
selftest(evict_range, igt_evict_range)
+selftest(bottomup, igt_bottomup)
selftest(topdown, igt_topdown)
selftest(color, igt_color)
selftest(color_evict, igt_color_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index bb5b7480e0b4..1e71bc182ca9 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1697,6 +1697,106 @@ static int igt_topdown(void *ignored)
return ret;
}
+static int igt_bottomup(void *ignored)
+{
+ const struct insert_mode *bottomup = &insert_modes[BOTTOMUP];
+ DRM_RND_STATE(prng, random_seed);
+ const unsigned int count = 8192;
+ unsigned int size;
+ unsigned long *bitmap;
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int *order, n, m, o = 0;
+ int ret;
+
+ /* Like igt_topdown, but instead of searching for the last hole,
+* we search for the first.
+*/
+
+ ret = -ENOMEM;
+ nodes = vzalloc(count * sizeof(*nodes));
+ if (!nodes)
+ goto err;
+
+ bitmap = kzalloc(count / BITS_PER_LONG * sizeof(unsigned long),
+GFP_TEMPORARY);
+ if (!bitmap)
+ goto err_nodes;
+
+ order = drm_random_order(count, &prng);
+ if (!order)
+ goto err_bitmap;
+
+ ret = -EINVAL;
+ for (size = 1; size <= 64; size <<= 1) {
+ drm_mm_init(&mm, 0, size*count);
+ for (n = 0; n < count; n++) {
+ if (!expect_insert(&mm, &nodes[n],
+ size, 0, n,
+ bottomup)) {
+ pr_err("bottomup insert failed, size %u step
%d\n", size, n);
+ goto out;
+ }
+
+ if (!assert_one_hole(&mm, size*(n + 1), size*count))
+ goto out;
+ }
+
+ if (!assert_continuous(&mm, size))
+ goto out;
+
+ drm_random_reorder(order, count, &prng);
+ for_each_prime_number_from(n, 1, min(count, max_prime)) {
+ for (m = 0; m < n; m++) {
+ node = &nodes[order[(o + m) % count]];
+ drm_mm_remove_node(node);
+ __set_bit(node_index(node), bitmap);
+ }
+
+ for (m = 0; m < n; m++) {
+ unsigned int first;
+
+ node = &nodes[order[(o + m) % count]];
+ if (!expect_insert(&mm, node,
+ size, 0, 0,
+ bottomup)) {
+ pr_err("insert failed, step %d/%d\n",
m, n);
+ goto out;
+ }
+
+ first = find_first_bit(bitmap, count);
+ if (node_index(node) != first) {
+ pr_err("node %d/%d not inserted into
bottom hole, expected %d, found %d\n",
+ m, n, first, node_index(node));
+ goto out;
+ }
+ __clear_bit(first, bitmap);
+ }
+
+ DRM_MM_BUG_ON(find_first_bit(bitmap, count) != count);
+
+ o += n;
+ }
+
+ drm_mm_for_each_node_safe(node, next, &mm)
+ drm_mm_remove_node(node);
+ DRM_MM_BUG_ON(!drm_mm_clean(&mm));
+ }
+
+ ret = 0;
+out:
+ drm_mm_for_each_node_safe(node, next, &mm)
+ drm_mm_remove_node(node);
+ drm_mm_takedown(&mm);
+ kfree(order);
+err_bitmap:
+ kfree(bitmap);
+err_nodes:
+ vfree(nodes);
+err:
+ return ret;
+}
+
static void separate_adjacent_colors(const struct drm_mm_node *node,
unsigned long color,
[PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.
v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Rob Clark
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Cc: Eric Anholt
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
drivers/gpu/drm/armada/armada_gem.c | 4 +-
drivers/gpu/drm/drm_mm.c | 488 +++
drivers/gpu/drm/drm_vma_manager.c| 3 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
drivers/gpu/drm/msm/msm_gem.c| 3 +-
drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
drivers/gpu/drm/sis/sis_mm.c | 6 +-
drivers/gpu/drm/tegra/gem.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
drivers/gpu/drm/via/via_mm.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
include/drm/drm_mm.h | 184 +-
23 files changed, 470 insertions(+), 447 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index e4eb6dd3798a..0335c2f331e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
{
struct amdgpu_gtt_mgr *mgr = man->priv;
struct drm_mm_node *node = mem->mm_node;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long fpfn, lpfn;
int r;
@@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
else
lpfn = man->size;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+ if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
- mem->page_alignment, 0,
- fpfn, lpfn, sflags, aflags);
+ r = drm_mm_insert_node_in_range(&mgr->mm, node,
+ mem->num_pages, mem->page_alignment, 0,
+ fpfn, lpfn, mode);
spin_unlock(&mgr->lock);
if (!r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ac9007986c11..9e577e3d3147 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
struct amdgpu_vram_mgr *mgr = man->priv;
struct drm_mm *mm = &mgr->mm;
struct drm_mm_node *nodes;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
unsigned i;
int r;
@@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
if (!nodes)
return -ENOMEM;
- if (place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+
Re: [Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers
On Wed, 01 Feb 2017, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides the
> symbolic names for the various registers defined in the specification.
>
> Signed-off-by: Thierry Reding
One process note, you need to add your own Signed-off-by under the
original author's sign-off, even when you're posting them unchanged.
Signed-off-by means https://developercertificate.org/
BR,
Jani.
> ---
> Documentation/gpu/drm-kms-helpers.rst | 12
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_scdc_helper.c | 111
> include/drm/drm_scdc_helper.h | 132
> ++
> 4 files changed, 257 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
> create mode 100644 include/drm/drm_scdc_helper.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 03040aa..7592756 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -217,6 +217,18 @@ EDID Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_edid.c
> :export:
>
> +SCDC Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> + :doc: scdc helpers
> +
> +.. kernel-doc:: include/drm/drm_scdc_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> + :export:
> +
> Rectangle Utilities Reference
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 92de399..ad91cd9 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> - drm_simple_kms_helper.o drm_modeset_helper.o
> + drm_simple_kms_helper.o drm_modeset_helper.o \
> + drm_scdc_helper.o
>
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
> b/drivers/gpu/drm/drm_scdc_helper.c
> new file mode 100644
> index 000..fe0e121
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sub license,
> + * 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 NON-INFRINGEMENT. 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.
> + */
> +
> +#include
> +
> +#include
> +
> +/**
> + * DOC: scdc helpers
> + *
> + * Status and Control Data Channel (SCDC) is a mechanism introduced by the
> + * HDMI 2.0 specification. It is a point-to-point protocol that allows the
> + * HDMI source and HDMI sink to exchange data. The same I2C interface that
> + * is used to access EDID serves as the transport mechanism for SCDC.
> + */
> +
> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
> +
> +/**
> + * drm_scdc_read - read a block of data from SCDC
> + * @adapter: I2C controller
> + * @offset: start offset of block to read
> + * @buffer: return location for the block to read
> + * @size: size of the block to read
> + *
> + * Reads a block of data from SCDC, starting at a given offset.
> + *
> + * Returns:
> + * The number of bytes read from SCDC or a negative error code on failure.
> + */
> +ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
> + size_t size)
> +{
> + struct i2c_msg msgs[2] = {
> + {
> + .addr = SCDC_I2C_SL
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 11:48:21AM +0100, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> > disposable private objects") introduced a regression for the kernel
> > running as Xen dom0: when switching to graphics mode a GPU HANG
> > occurred.
> >
> > Reason seems to be a missing adaption similar to that done in
> > commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> > to i915_gem_object_get_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross
> Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for
> disposable private objects")
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-...@lists.freedesktop.org
> Cc: # v4.10-rc1+
>
> We have a nice script for these :-)
Pffifle. 7453c549f5f648 allowed Xen to change it and silently conflicted
with those that already used the previous limits, which didn't land in
our tree until v4.10-rc3.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
>> The platform driver name is currently "meson" which can lead to some
>> confusion, this patch renames it to "meson-drm" and removes the owner
>> attribute.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_drv.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>> b/drivers/gpu/drm/meson/meson_drv.c
>> index ff1f601..380bde7 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
>> .probe = meson_drv_probe,
>> .remove = meson_drv_remove,
>> .driver = {
>> -.owner = THIS_MODULE,
Hi Daniel,
> I don't get why you remove this, generally that will lead to trouble of
> being able to unload code that's still in use ...
Indeed, but since a (long ?) time, the owner field is now populated by the
platform_driver_register() core code.
>
> Otherwise ack.
>
> Now, do you want to get this landed as part of the small drivers in
> drm-mis experiment?
I have a PR ready, but it can go through this experiment, yes.
> -Daniel
>
>> -.name = DRIVER_NAME,
>> +.name = "meson-drm",
>> .of_match_table = dt_match,
>> },
>> };
>> --
Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> disposable private objects") introduced a regression for the kernel
> running as Xen dom0: when switching to graphics mode a GPU HANG
> occurred.
>
> Reason seems to be a missing adaption similar to that done in
> commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> to i915_gem_object_get_pages_internal().
>
> So limit the maximum page order to be used according to the maximum
> swiotlb segment size instead to the complete swiotlb size.
>
> Signed-off-by: Juergen Gross
Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable
private objects")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-...@lists.freedesktop.org
Cc: # v4.10-rc1+
We have a nice script for these :-)
-Daniel
> ---
> Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
> with i915 graphics.
> ---
> drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
> b/drivers/gpu/drm/i915/i915_gem_internal.c
> index 4b3ff3e..d09c749 100644
> --- a/drivers/gpu/drm/i915/i915_gem_internal.c
> +++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> @@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
> drm_i915_gem_object *obj)
>
> max_order = MAX_ORDER;
> #ifdef CONFIG_SWIOTLB
> - if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
> - max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
> + if (swiotlb_nr_tbl()) {
> + unsigned int max_segment;
> +
> + max_segment = swiotlb_max_segment();
> + if (max_segment) {
> + max_segment = max_t(unsigned int, max_segment,
> + PAGE_SIZE) >> PAGE_SHIFT;
> + max_order = min(max_order, ilog2(max_segment));
> + }
> + }
> #endif
>
> gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/i915: enable scrambling
Regards
Shashank
On 2/2/2017 3:32 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
Geminilake platform has a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 5 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 42
+++
4 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 495b789..cc85892 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7807,6 +7807,8 @@ enum {
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
#define TRANS_DDI_BFI_ENABLE(1<<4)
+#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
/* DisplayPort Transport Control */
#define _DP_TP_CTL_A 0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a9a670..aea81ce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+ if (IS_GEMINILAKE(dev_priv)) {
+ temp |= intel_hdmi_check_scrambling(intel_encoder,
+ &intel_crtc->config->base.adjusted_mode);
+ }
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 393f243..aafce7f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state);
+uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
+ struct drm_display_mode *mode);
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
enable);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index ebae2bd..92dd9bc 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
+static void
+intel_hdmi_enable_scrambling(struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = connector->dev->dev_private;
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+ struct i2c_adapter *adapter =
+ intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+ if (!drm_enable_scrambling(connector, adapter, true))
+ DRM_ERROR("Request to enable scrambling failed\n");
+}
I don't like hiding this somewhere deep like this. It should be
somewhere much higher up.
Why ? All we need to do here is enable two bits in transcoder control
register, which is already being
programmed in a calling function, so I dont see the use case, but I
might be missing some bigger picture.
Can you please elaborate on this ?
We're talking to the display here, which is rather surprising to happen
from a function thing that on the first glance doesn't even seem to
touch the hardware.
I kind of agree with this, and I am also tempted now to shift this call
upwards, but I want to
keep this close to port enabling as well, as the HDMI 2.0 spec says:
"Max time period between a source enables scrambling on monitor, and
starts sending scrambled
video should be 100ms" else the sink might choose to disable scrambling.
Considering this, where do you think would be right place to enabled
scrambling on monitor ?
- Shashank
And I'm thinkign we might want to track the scrambler state
in the crtc state.
Yes, that's a pretty good way to track dynamic status of scrambler, do
you think we should add this in
drm_crtc_state itself ?
I'd just start with intel specific state and later we can see what
everyone else wants to
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> The platform driver name is currently "meson" which can lead to some
> confusion, this patch renames it to "meson-drm" and removes the owner
> attribute.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index ff1f601..380bde7 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
> .probe = meson_drv_probe,
> .remove = meson_drv_remove,
> .driver = {
> - .owner = THIS_MODULE,
I don't get why you remove this, generally that will lead to trouble of
being able to unload code that's still in use ...
Otherwise ack.
Now, do you want to get this landed as part of the small drivers in
drm-mis experiment?
-Daniel
> - .name = DRIVER_NAME,
> + .name = "meson-drm",
> .of_match_table = dt_match,
> },
> };
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: scrambling support in drm layer
Regards Shashank On 2/2/2017 3:58 PM, Ville Syrjälä wrote: On Thu, Feb 02, 2017 at 03:46:55PM +0530, Sharma, Shashank wrote: Regards Shashank On 2/2/2017 3:21 PM, Ville Syrjälä wrote: On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote: Regards Shashank On 2/1/2017 10:02 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340Mhz. This patch adds few new functions in drm layer for core drivers to enable/disable scrambling. This patch adds: - A function to detect scrambling support parsing HF-VSDB - A function to check scrambling status runtime using SCDC read. - Two functions to enable/disable scrambling using SCDC read/write. - Few new bools to reflect scrambling support and status. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 131 +++- include/drm/drm_connector.h | 24 include/drm/drm_edid.h | 6 +- 3 files changed, 159 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 37902e5..f0d940a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -37,6 +37,7 @@ #include #include #include +#include #define version_greater(edid, maj, min) \ (((edid)->version > (maj)) || \ @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector *connector, } } +static void drm_detect_hdmi_scrambling(struct drm_connector *connector, +const u8 *hf_vsdb) That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or something. Actually, unlike the last patch set, we are not parsing the whole hf_vsdb, but parsing it only for scrambling status byte (hf_vsdb[5]). But may be I can make it drm_detect_scrambling_from_hfvsdb ot something similar. We will have more hf_vsdb parsing for 3d flags, yuv420_deep_color etc. Well, so far I'm not seeing much point in splitting it up. So I'd stuff it all into one place, for now at least. I had published a patch just doing as you suggested which was parsing complete hf-vsdb in one shot, and adding info in hdmi_info structure, to accommodate it. (Patch https://patchwork.freedesktop.org/patch/128963/ and https://patchwork.freedesktop.org/patch/128962/) But you gave a review comment not to add anything which is not being used in the patch series: https://patchwork.freedesktop.org/patch/128962/ That's doesn't require the things that are left to be split into separate functions. So please let me know if my understanding is correct. - Name the function as *_parse_hfvsdb only - Call it while parsing the EDID extension blocks (the same place) - Keep on adding parsing of the HF-VSDB blocks, in the same function, in an incremental way, as we add patches for them. In this way the function won't be split into multiple small functions, but all the parsing will be done in one function. - Shashank That was the only reason I have split hf-vsdb parsing patch into 3 parts - parse SCDC and scrambling info (here) - with YUV420 deep color ( upcoming ) - with 3d handling (upcoming) So I am confused, split or no split :-) ? - Shashank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #9 from fin4...@hotmail.com --- After updating the firmware I still have powerplay erros: [3.574222] amdgpu: [powerplay] [AVFS] Something is broken. See log! [3.577052] amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm: Support framebuffer panning
Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v1: - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS - Expanded a bit the kerneldoc for drm_fb_helper_ioctl - Added some locking to drm_fb_helper_ioctl - Checked that the framebuffer is indeed attached before allowing ioctl - Added a module parameter to specify the number of framebuffers to allocate Initial cover letter: Support fast framebuffer panning for i.MX6 im currently working on supporting double/tripple buffering for the framebuffer emulation on the i.MX6. While working on it I noticed that the mainline kernel does not support some features in the generic drm framebuffer emulation for framebuffer panning and vsync synchronisation. They are needed for simple framebuffer applications and some OpenGL libraries using double buffering with FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY. Stefan Christ (1): drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Xinliang Liu (1): drm/cma-helper: Add multi buffer support for cma fbdev drivers/gpu/drm/Kconfig | 8 - drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- drivers/gpu/drm/drm_fb_helper.c | 55 ++- include/drm/drm_fb_helper.h | 5 ++- 4 files changed, 74 insertions(+), 2 deletions(-) base-commit: 8b394ae674998d4ade6cb48aec3fca5445908dfe -- git-series 0.8.11 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev
From: Xinliang Liu This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu [s.chr...@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ Signed-off-by: Maxime Ripard --- drivers/gpu/drm/Kconfig | 8 drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index ebfe8404c25f..2ca9bb26a4e4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER help Choose this if you need the KMS CMA helper functions +config DRM_CMA_FBDEV_BUFFER_NUM + int "Cma Fbdev Buffer Number" + depends on DRM_KMS_CMA_HELPER + default 1 + help + Defines the buffer number of cma fbdev. Default is one buffer. + For double buffer please set to 2 and 3 for triple buffer. + source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) kfree(fbi->fbops); } +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; +module_param(fbdev_num_buffers, int, 0444); +MODULE_PARM_DESC(fbdev_num_buffers, +"Number of frame buffers to allocate [default=" +__MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); + /* * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); mode_cmd.width = sizes->surface_width; - mode_cmd.height = sizes->surface_height; + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); -- git-series 0.8.11 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
