Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3)
On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote: > On 05/07/2023 19:53, Maxime Ripard wrote: > > On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: > > > On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote: > > > > > > > > On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: > > > > > > > > > > > > > > > > Either way, I'm not really sure it's a good idea to multiply the > > > > > > > > capabilities flags of the DSI host, and we should just stick to > > > > > > > > the > > > > > > > > spec. If the spec says that we have to support DSC while video > > > > > > > > is > > > > > > > > output, then that's what the panels should expect. > > > > > > > > > > > > > > Except some panels supports DSC & non-DSC, Video and Command > > > > > > > mode, and > > > > > > > all that is runtime configurable. How do you handle that ? > > > > > > > > > > > > In this case, most of the constraints are going to be on the encoder > > > > > > still so it should be the one driving it. The panel will only care > > > > > > about > > > > > > which mode has been selected, but it shouldn't be the one driving > > > > > > it, > > > > > > and thus we still don't really need to expose the host capabilities. > > > > > > > > > > This is an interesting perspective. This means that we can and > > > > > actually have > > > > > to extend the drm_display_mode with the DSI data and compression > > > > > information. > > > > > > > > I wouldn't extend drm_display_mode, but extending one of the state > > > > structures definitely. > > > > > > > > We already have some extra variables in drm_connector_state for HDMI, > > > > I don't think it would be a big deal to add a few for MIPI-DSI. > > > > > > > > We also floated the idea for a while to create bus-specific states, with > > > > helpers to match. Maybe it would be a good occasion to start doing it? > > > > > > > > > For example, the panel that supports all four types for the 1080p > > > > > should > > > > > export several modes: > > > > > > > > > > 1920x1080-command > > > > > 1920x1080-command-DSC > > > > > 1920x1080-video > > > > > 1920x1080-video-DSC > > > > > > > > > > where video/command and DSC are some kinds of flags and/or > > > > > information in > > > > > the drm_display_mode? Ideally DSC also has several sub-flags, which > > > > > denote > > > > > what kind of configuration is supported by the DSC sink (e.g. bpp, > > > > > yuv, > > > > > etc). > > > > > > > > So we have two things to do, right? We need to expose what the panel can > > > > take (ie, EDID for HDMI), and then we need to tell it what we picked > > > > (infoframes). > > > > > > > > We already express the former in mipi_dsi_device, so we could extend the > > > > flags stored there. > > > > > > > > And then, we need to tie what the DSI host chose to a given atomic state > > > > so the panel knows what was picked and how it should set everything up. > > > > > > This is definitely something we need. Marijn has been stuck with the > > > panels that support different models ([1]). > > > > > > Would you prefer a separate API for this kind of information or > > > abusing atomic_enable() is fine from your point of view? > > > > > > My vote would be for going with existing operations, with the slight > > > fear of ending up with another DSI-specific hack (like > > > pre_enable_prev_first). > > > > I don't think we can get away without getting access to the atomic_state > > from the panel at least. > > > > Choosing one setup over another is likely going to depend on the mode, > > and that's only available in the state. > > > > We don't have to go the whole way though and create the sub-classes of > > drm_connector_state, but I think we should at least provide it to the > > panel. > > > > What do you think of creating a new set of atomic_* callbacks for > > panels, call that new set of functions from msm and start from there? > > We are (somewhat) bound by the panel_bridge, but yeah, it seems possible. Bridges have access to the atomic state already, so it's another place to plumb this through but I guess it would still be doable? Maxime signature.asc Description: PGP signature
Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3)
On 06/07/2023 09:24, Maxime Ripard wrote: On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote: On 05/07/2023 19:53, Maxime Ripard wrote: On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote: On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: Either way, I'm not really sure it's a good idea to multiply the capabilities flags of the DSI host, and we should just stick to the spec. If the spec says that we have to support DSC while video is output, then that's what the panels should expect. Except some panels supports DSC & non-DSC, Video and Command mode, and all that is runtime configurable. How do you handle that ? In this case, most of the constraints are going to be on the encoder still so it should be the one driving it. The panel will only care about which mode has been selected, but it shouldn't be the one driving it, and thus we still don't really need to expose the host capabilities. This is an interesting perspective. This means that we can and actually have to extend the drm_display_mode with the DSI data and compression information. I wouldn't extend drm_display_mode, but extending one of the state structures definitely. We already have some extra variables in drm_connector_state for HDMI, I don't think it would be a big deal to add a few for MIPI-DSI. We also floated the idea for a while to create bus-specific states, with helpers to match. Maybe it would be a good occasion to start doing it? For example, the panel that supports all four types for the 1080p should export several modes: 1920x1080-command 1920x1080-command-DSC 1920x1080-video 1920x1080-video-DSC where video/command and DSC are some kinds of flags and/or information in the drm_display_mode? Ideally DSC also has several sub-flags, which denote what kind of configuration is supported by the DSC sink (e.g. bpp, yuv, etc). So we have two things to do, right? We need to expose what the panel can take (ie, EDID for HDMI), and then we need to tell it what we picked (infoframes). We already express the former in mipi_dsi_device, so we could extend the flags stored there. And then, we need to tie what the DSI host chose to a given atomic state so the panel knows what was picked and how it should set everything up. This is definitely something we need. Marijn has been stuck with the panels that support different models ([1]). Would you prefer a separate API for this kind of information or abusing atomic_enable() is fine from your point of view? My vote would be for going with existing operations, with the slight fear of ending up with another DSI-specific hack (like pre_enable_prev_first). I don't think we can get away without getting access to the atomic_state from the panel at least. Choosing one setup over another is likely going to depend on the mode, and that's only available in the state. We don't have to go the whole way though and create the sub-classes of drm_connector_state, but I think we should at least provide it to the panel. What do you think of creating a new set of atomic_* callbacks for panels, call that new set of functions from msm and start from there? We are (somewhat) bound by the panel_bridge, but yeah, it seems possible. Bridges have access to the atomic state already, so it's another place to plumb this through but I guess it would still be doable? It's definitely doable, but I fear we won't be able to test most of the panel drivers, should we introduce a new atomic set of panel callbacks ? Or shall be simply move the "new" panel driver supporting atomic to bridge and only use panel_bridge for basic panels ? Neil Maxime
Re: [PATCH] backlight: led_bl: fix initial power state
Daniel Thompson writes:
> On Wed, Jul 05, 2023 at 03:24:14PM +0100, Mans Rullgard wrote:
>> The condition for the initial power state based on the default
>> brightness value is reversed. Fix it.
>>
>> Furthermore, use the actual state of the LEDs rather than the default
>> brightness specified in the devicetree as the latter should not cause
>> the backlight to be automatically turned on.
>>
>> If the backlight device is not linked to any display, set the initial
>> power to on unconditionally.
>>
>> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
>> Signed-off-by: Mans Rullgard
>> ---
>> Changes in v3:
>> - Add comment
>
> This mismatches the subject line ;-) but I can live with that if Lee
> and Jingoo can!
Does it not fix it? If you think the subject is misleading, feel free
to change it.
--
Måns Rullgård
[PATCH] backlight: led_bl: fix initial power state
The condition for the initial power state based on the default
brightness value is reversed. Fix it.
Furthermore, use the actual state of the LEDs rather than the default
brightness specified in the devicetree as the latter should not cause
the backlight to be automatically turned on.
If the backlight device is not linked to any display, set the initial
power to on unconditionally.
Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
Signed-off-by: Mans Rullgard
---
Changes in v3:
- Add comment
Changes in v2:
- Use the reported LED state to set initial power state
- Always power on if no phandle in DT
---
drivers/video/backlight/led_bl.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
index 3259292fda76..c94843c00a30 100644
--- a/drivers/video/backlight/led_bl.c
+++ b/drivers/video/backlight/led_bl.c
@@ -176,6 +176,7 @@ static int led_bl_probe(struct platform_device *pdev)
{
struct backlight_properties props;
struct led_bl_data *priv;
+ int init_brightness;
int ret, i;
priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
@@ -190,6 +191,8 @@ static int led_bl_probe(struct platform_device *pdev)
if (ret)
return ret;
+ init_brightness = priv->default_brightness;
+
ret = led_bl_parse_levels(&pdev->dev, priv);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to parse DT data\n");
@@ -200,8 +203,11 @@ static int led_bl_probe(struct platform_device *pdev)
props.type = BACKLIGHT_RAW;
props.max_brightness = priv->max_brightness;
props.brightness = priv->default_brightness;
- props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
- FB_BLANK_UNBLANK;
+
+ /* Set power on if LEDs already on or not linked to a display. */
+ props.power = (init_brightness || !pdev->dev.of_node->phandle) ?
+ FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
+
priv->bl_dev = backlight_device_register(dev_name(&pdev->dev),
&pdev->dev, priv, &led_bl_ops, &props);
if (IS_ERR(priv->bl_dev)) {
--
2.41.0
Re: [PATCH v3 07/17] drm/imagination: Add GPU ID parsing and firmware loading
On 7/5/23 15:13, Frank Binns wrote: On Mon, 2023-06-26 at 10:38 -0500, Adam Ford wrote: On Mon, Jun 26, 2023 at 8:22 AM Frank Binns wrote: Hi Adam, On Sat, 2023-06-17 at 07:48 -0500, Adam Ford wrote: On Tue, Jun 13, 2023 at 10:20 AM Sarah Walker wrote: Read the GPU ID register at probe time and select the correct features/quirks/enhancements. Use the GPU ID to form the firmware file name and load the firmware. I have a Rogue 6250 variant, but the BVNC is returning a slightly different revision than the firmware that's currently available, and the older firmware for the vendor driver doesn't work with this new code. Linux responds with Unsupported BVNC: 4.45.2.58. From what I can tell, the closest available firmware is 4.40.2.51. Will there be more firmware variants in the future or will there be some options to build the firmware somehow? We don't plan to support the SoC vendor provided firmware binaries as this will mean having to deal with many different versions of the firmware and its interface. Specifically, the interface can change in backwards incompatible ways between releases, it changes based on the hardware feature set & bugs and it's split across userspace & the kernel. This makes these SoC provided firmware binaries very difficult to support in this new driver. Thanks for the response. That makes sense. I would hope that various SoC vendors would jump on the bandwagon to work with your group to get their hardware supported. As an alternative, we'll be releasing firmware binaries as we add support for more Rogue GPUs. We'll also release binaries upon request, in case others in the community want to work on support in the meantime - we're just getting things set up for this at the moment. The Mesa side of things appears to be missing some documentation, and the power VR stuff still appears listed as experimental. Is there some documentation somewhere that would explain to someone how to go about porting the Rogue 6250 to a different hardware variant of the 6250? I don't really know the difference between BVNC of 4.45.2.58 and 4.40.2.51, but I can't imagine they are drastically different. One thing I forgot to mention is that, alongside the firmware binaries, we'll also provide the corresponding device info, e.g. for Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/blob/e714b35301a33145399f8939ca864ffd14b49de9/src/imagination/common/pvr_device_info.c#L32-125 We don't have any specific porting documentation, but we did just send out a Mesa MR adding some initial (basic) documentation: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23992 In terms of differences between the two GX6250 variants, it doesn't seem that there's anything feature-wise that will require any driver changes that are specific to the 4.45.2.58 variant (the different firmware should in theory be sufficient). There are still some driver changes required, however. Assuming the SoC you're interested in is already well supported upstream and the clocks, power controllers, etc needed by the GPU are also already supported then the following changes will be required at a minimum: 1. A GPU node will need adding to the device tree source file for your specific board 2. The compatible string for the GPU node will need adding to the list of supported devices in the kernel driver (grep for "dt_match" in the driver code) 3. The device info we provide alongside the firmware binary will need adding to the kernel driver and Mesa 4. The compatible string for the GPU and display controller device tree nodes will need adding to the Vulkan driver (grep for "pvr_drm_configs" in the Mesa code to see existing examples) Hopefully that covers everything, but no doubt I missed something! With respect to the experimental status of the driver, I think there are three things that need to happen before we can drop this tag. Firstly, the kernel driver needs to be merged to the kernel. Secondly, we need to pass Khronos conformance on at least one of the devices we support (our current focus is on the AXE-1-16M). Finally, we need to upstream all our Mesa changes. This is something that we've been chipping away at, but we do have a big backlog in our public branch [1]. I expect it's going to be quite some time until all of this work is complete. While so much code is sitting in downstream branches I think it's going to be somewhat painful for people to meaningfully contribute to the driver itself. Effort is probably best spent on getting the other drivers, which the GPU driver depends on, upstream for the platform(s) you're interested in. Just to say that I'm by no means trying to put you off from contributing, but simply trying to warn you that until the driver is out of its experimental state, a lot of things are going to be in flux and the development process is currently a lot more complicated. It's also worth highlighting that we're a small team tackling a very large job! We're doi
[PATCH v1] gpu: i915: display: Replace define function
Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE. Signed-off-by: Minjie Du --- drivers/gpu/drm/i915/display/intel_psr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 56c17283b..822858f3e 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -2998,7 +2998,7 @@ i915_edp_psr_debug_get(void *data, u64 *val) return -ENODEV; } -DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops, +DEFINE_DEBUGFS_ATTRIBUTE(i915_edp_psr_debug_fops, i915_edp_psr_debug_get, i915_edp_psr_debug_set, "%llu\n"); -- 2.39.0
[PATCH v2] drm/i915/gt: Convert to use time_before macro
Use time_before macro instead of open it for readability. Signed-off-by: Zehao Zhang --- v2: -update subject drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c index 86b5a9ba323d..9145f9e22860 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c @@ -57,7 +57,7 @@ static bool pool_free_older_than(struct intel_gt_buffer_pool *pool, long keep) node = list_entry(pos, typeof(*node), link); age = READ_ONCE(node->age); - if (!age || jiffies - age < keep) + if (!age || time_before(jiffies, age + keep)) break; /* Check we are the first to claim this node */ -- 2.35.3
[PATCH] Fix max/min warnings in virtio_net, amd/display, and io_uring
The files drivers/net/virtio_net.c,
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c, and io_uring/io_uring.c were
modified to fix warnings.
Specifically, the opportunities for max() and min() were utilized to address
the warnings.
Signed-off-by: Yang Rong
---
drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 6 +++---
drivers/net/virtio_net.c | 3 ++-
io_uring/io_uring.c | 3 ++-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
index c753c6f30dd7..df79aea49a3c 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
+++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
@@ -22,7 +22,7 @@
* Authors: AMD
*
*/
-
+#include
#include "dc.h"
#include "dc_dmub_srv.h"
#include "../dmub/dmub_srv.h"
@@ -481,7 +481,7 @@ static void populate_subvp_cmd_drr_info(struct dc *dc,
max_drr_vblank_us = div64_u64((subvp_active_us - prefetch_us -
dc->caps.subvp_fw_processing_delay_us - drr_active_us),
2) + drr_active_us;
max_drr_mallregion_us = subvp_active_us - prefetch_us - mall_region_us
- dc->caps.subvp_fw_processing_delay_us;
- max_drr_supported_us = max_drr_vblank_us > max_drr_mallregion_us ?
max_drr_vblank_us : max_drr_mallregion_us;
+ max_drr_supported_us = max(max_drr_vblank_us, max_drr_mallregion_us);
max_vtotal_supported = div64_u64(((uint64_t)drr_timing->pix_clk_100hz *
100 * max_drr_supported_us),
(((uint64_t)drr_timing->h_total * 100)));
@@ -771,7 +771,7 @@ void dc_dmub_setup_subvp_dmub_command(struct dc *dc,
wm_val_refclk =
context->bw_ctx.bw.dcn.watermarks.a.cstate_pstate.pstate_change_ns *
(dc->res_pool->ref_clocks.dchub_ref_clock_inKhz
/ 1000) / 1000;
- cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache =
wm_val_refclk < 0x ? wm_val_refclk : 0x;
+ cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache =
min(wm_val_refclk, 0x);
}
dm_execute_dmub_cmd(dc->ctx, &cmd, DM_DMUB_WAIT_TYPE_WAIT);
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 9b3721424e71..5bb7da885f00 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
static int napi_weight = NAPI_POLL_WEIGHT;
module_param(napi_weight, int, 0444);
@@ -1291,7 +1292,7 @@ static struct sk_buff *build_skb_from_xdp_buff(struct
net_device *dev,
__skb_put(skb, data_len);
metasize = xdp->data - xdp->data_meta;
- metasize = metasize > 0 ? metasize : 0;
+ metasize = max(metasize, 0);
if (metasize)
skb_metadata_set(skb, metasize);
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index e8096d502a7c..875ca657227d 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -47,6 +47,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2660,7 +2661,7 @@ static void *__io_uaddr_map(struct page ***pages,
unsigned short *npages,
page_array);
if (ret != nr_pages) {
err:
- io_pages_free(&page_array, ret > 0 ? ret : 0);
+ io_pages_free(&page_array, max(ret, 0));
return ret < 0 ? ERR_PTR(ret) : ERR_PTR(-EFAULT);
}
/*
--
2.35.3
本邮件及其附件内容可能含有机密和/或隐私信息，仅供指定个人或机构使用。若您非发件人指定收件人或其代理人，请勿使用、传播、复制或存储此邮件之任何内容或其附件。如您误收本邮件，请即以回复或电话方式通知发件人，并将原始邮件、附件及其所有复本删除。谢谢。
The contents of this message and any attachments may contain confidential
and/or privileged information and are intended exclusively for the
addressee(s). If you are not the intended recipient of this message or their
agent, please note that any use, dissemination, copying, or storage of this
message or its attachments is not allowed. If you receive this message in
error, please notify the sender by reply the message or phone and delete this
message, any attachments and any copies immediately.
Thank you
Re: [PATCH] backlight: led_bl: fix initial power state
Daniel Thompson writes:
> On Wed, Jul 05, 2023 at 03:36:46PM +0100, Måns Rullgård wrote:
>> Daniel Thompson writes:
>>
>> > On Wed, Jul 05, 2023 at 03:24:14PM +0100, Mans Rullgard wrote:
>> >> The condition for the initial power state based on the default
>> >> brightness value is reversed. Fix it.
>> >>
>> >> Furthermore, use the actual state of the LEDs rather than the default
>> >> brightness specified in the devicetree as the latter should not cause
>> >> the backlight to be automatically turned on.
>> >>
>> >> If the backlight device is not linked to any display, set the initial
>> >> power to on unconditionally.
>> >>
>> >> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
>> >> Signed-off-by: Mans Rullgard
>> >> ---
>> >> Changes in v3:
>> >> - Add comment
>> >
>> > This mismatches the subject line ;-) but I can live with that if Lee
>> > and Jingoo can!
>>
>> Does it not fix it? If you think the subject is misleading, feel free
>> to change it.
>
> The bit that goes into version control is fine!
>
> However without '[PATCH v3]' on the subject line for the initial patch
> there is a risk this thread will get overlooked and not queued[1].
Oh, I see now I forgot to add the v3 tag. Sorry about that.
--
Måns Rullgård
[PATCH] Covert to use time_before macro
Use time_before macro instead of open it for readability. Signed-off-by: Zehao Zhang --- drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c index 86b5a9ba323d..9145f9e22860 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c +++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.c @@ -57,7 +57,7 @@ static bool pool_free_older_than(struct intel_gt_buffer_pool *pool, long keep) node = list_entry(pos, typeof(*node), link); age = READ_ONCE(node->age); - if (!age || jiffies - age < keep) + if (!age || time_before(jiffies, age + keep)) break; /* Check we are the first to claim this node */ -- 2.35.3
[PATCH v1] drivers: dcn315: remove duplicate assignments
make clk_mgr_base->clks.zstate_support avoid double assignment.
It looks like the value of new_clocks is unchanged, so there
may be no need for repeated assignments.
Signed-off-by: Minjie Du
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
index b2c4f97af..45b811610 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn315/dcn315_clk_mgr.c
@@ -143,7 +143,6 @@ static void dcn315_update_clocks(struct clk_mgr
*clk_mgr_base,
* if it is safe to lower, but we are already in the lower state, we
don't have to do anything
* also if safe to lower is false, we just go in the higher state
*/
- clk_mgr_base->clks.zstate_support = new_clocks->zstate_support;
if (safe_to_lower) {
/* check that we're not already in lower */
if (clk_mgr_base->clks.pwr_state != DCN_PWR_STATE_LOW_POWER) {
--
2.39.0
Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3)
On Thu, Jul 06, 2023 at 09:33:15AM +0200, Neil Armstrong wrote: > On 06/07/2023 09:24, Maxime Ripard wrote: > > On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote: > > > On 05/07/2023 19:53, Maxime Ripard wrote: > > > > On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote: > > > > > On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote: > > > > > > > > > > > > On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote: > > > > > > > > > > > > > > > > > > > > Either way, I'm not really sure it's a good idea to > > > > > > > > > > multiply the > > > > > > > > > > capabilities flags of the DSI host, and we should just > > > > > > > > > > stick to the > > > > > > > > > > spec. If the spec says that we have to support DSC while > > > > > > > > > > video is > > > > > > > > > > output, then that's what the panels should expect. > > > > > > > > > > > > > > > > > > Except some panels supports DSC & non-DSC, Video and Command > > > > > > > > > mode, and > > > > > > > > > all that is runtime configurable. How do you handle that ? > > > > > > > > > > > > > > > > In this case, most of the constraints are going to be on the > > > > > > > > encoder > > > > > > > > still so it should be the one driving it. The panel will only > > > > > > > > care about > > > > > > > > which mode has been selected, but it shouldn't be the one > > > > > > > > driving it, > > > > > > > > and thus we still don't really need to expose the host > > > > > > > > capabilities. > > > > > > > > > > > > > > This is an interesting perspective. This means that we can and > > > > > > > actually have > > > > > > > to extend the drm_display_mode with the DSI data and compression > > > > > > > information. > > > > > > > > > > > > I wouldn't extend drm_display_mode, but extending one of the state > > > > > > structures definitely. > > > > > > > > > > > > We already have some extra variables in drm_connector_state for > > > > > > HDMI, > > > > > > I don't think it would be a big deal to add a few for MIPI-DSI. > > > > > > > > > > > > We also floated the idea for a while to create bus-specific states, > > > > > > with > > > > > > helpers to match. Maybe it would be a good occasion to start doing > > > > > > it? > > > > > > > > > > > > > For example, the panel that supports all four types for the 1080p > > > > > > > should > > > > > > > export several modes: > > > > > > > > > > > > > > 1920x1080-command > > > > > > > 1920x1080-command-DSC > > > > > > > 1920x1080-video > > > > > > > 1920x1080-video-DSC > > > > > > > > > > > > > > where video/command and DSC are some kinds of flags and/or > > > > > > > information in > > > > > > > the drm_display_mode? Ideally DSC also has several sub-flags, > > > > > > > which denote > > > > > > > what kind of configuration is supported by the DSC sink (e.g. > > > > > > > bpp, yuv, > > > > > > > etc). > > > > > > > > > > > > So we have two things to do, right? We need to expose what the > > > > > > panel can > > > > > > take (ie, EDID for HDMI), and then we need to tell it what we picked > > > > > > (infoframes). > > > > > > > > > > > > We already express the former in mipi_dsi_device, so we could > > > > > > extend the > > > > > > flags stored there. > > > > > > > > > > > > And then, we need to tie what the DSI host chose to a given atomic > > > > > > state > > > > > > so the panel knows what was picked and how it should set everything > > > > > > up. > > > > > > > > > > This is definitely something we need. Marijn has been stuck with the > > > > > panels that support different models ([1]). > > > > > > > > > > Would you prefer a separate API for this kind of information or > > > > > abusing atomic_enable() is fine from your point of view? > > > > > > > > > > My vote would be for going with existing operations, with the slight > > > > > fear of ending up with another DSI-specific hack (like > > > > > pre_enable_prev_first). > > > > > > > > I don't think we can get away without getting access to the atomic_state > > > > from the panel at least. > > > > > > > > Choosing one setup over another is likely going to depend on the mode, > > > > and that's only available in the state. > > > > > > > > We don't have to go the whole way though and create the sub-classes of > > > > drm_connector_state, but I think we should at least provide it to the > > > > panel. > > > > > > > > What do you think of creating a new set of atomic_* callbacks for > > > > panels, call that new set of functions from msm and start from there? > > > > > > We are (somewhat) bound by the panel_bridge, but yeah, it seems possible. > > > > Bridges have access to the atomic state already, so it's another place > > to plumb this through but I guess it would still be doable? > > It's definitely doable, but I fear we won't be able to test most of the > panel drivers, should we introduce a new atomic set of panel callbacks ? That was my original intent yeah :) Creating an atomic_enable/disable/ et
Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots
On Wed, 5 Jul 2023 09:08:07 -0700 Michael Banack wrote: > On 7/4/23 01:08, Pekka Paalanen wrote: > > On Mon, 3 Jul 2023 14:06:56 -0700 > > Michael Banack wrote: > > > >> Hi, I can speak to the virtual mouse/console half of this from the > >> VMware-side. > >> > >> I believe Zack's preparing a new set of comments here that can speak to > >> most of your concerns, but I'll answer some of the other questions > >> directly. > >> > >> On 6/29/23 01:03, Pekka Paalanen wrote: > >>> Is it really required that the hotspot coordinates fall inside the > >>> cursor plane? Will the atomic commit be rejected otherwise? > >> Most console systems require the hotspot to get within the cursor image, > >> but in theory it's semantically meaningful to have it extend outside the > >> image. > >> > >> VMware's clients in particular will clamp the hotspot to the dimension > >> of the cursor image if we receive one that's out of bounds. > >> > >> So I would assume the right thing to do here would be to allow it and > >> let the clients figure out how to best handle it. > > Hi, > > > > if it is normal that clients clamp the hotspot to inside the cursor > > image, then I would come to the opposite conclusion: KMS UAPI needs to > > require the hotspot to be within the cursor image. Otherwise the > > results would be unpredictable, if clients still continue to clamp it > > anyway. I would assume that clients in use today are not prepared to > > handle hotspot outside the cursor image. > > > > It is also not a big deal to require that. I think it would be very rare > > to not have hotspot inside the cursor image, and even if it happened, > > the only consequence would be that the guest display server falls back > > to rendered cursor instead of a cursor plane. That may happen any time > > anyway, if an application sets e.g. a huge cursor that exceeds cursor > > plane size limits. > Hypervisors are normally more privileged than the kernel, so any > hypervisor/remoting client here really should be dealing with this case > rather than trusting the kernel to handle it for them. Sorry, handle what? Trust the guest kernel to do what? Personally I'm only interested in the KMS UAPI the guest kernel offers to guest userspace, and requiring hotspot to be inside the cursor image is fine. I don't think it needs even a strong justification, it's what most would likely expect, and expectations are good to record in spec. The UAPI contract is between (guest) kernel and (guest) userspace, and I expect the kernel to fully enforce that towards the userspace. I understand that hypervisors cannot trust guest kernels for security, but I also think that's a different matter. > From that perspective, we would normally try to preserve the > application/guest semantics as much as possible, and then that gives us > the ability to deal with this on the hypervisor side if it turns out > that there's a critical case with the hotspot outside the image that we > need to handle. > > But that said, while I've seen real Guests do this in the past, I don't > recall seeing this from any modern operating systems, so I don't think > it's a big deal for us either way. > > > > > What I'm after with the question is that the requirement must be spelled > > out clearly if it is there, or not even hinted at if it's not there. > Agreed. > > >>> The question of which input device corresponds to which cursor plane > >>> might be good to answer too. I presume the VM runner is configured to > >>> expose exactly one of each, so there can be only one association? > >> As far as I know, all of the VM consoles are written as though they > >> taking the place of what would the the physical monitors and input > >> devices on a native machine. So they assume that there is one user, > >> sitting in front of one console, and all monitors/input devices are > >> being used by that user. > > Ok, but having a single user does not mean that there cannot be > > multiple independent pointers, especially on Wayland. The same with > > keyboards. > > True, and if the userspace is doing anything complicated here, the > hypervisor has to be responsible for ensuring that whatever it's doing > works with that, or else this system won't work. I don't know that the > kernel is in a good position to police that. What do you mean by policing here? Isn't it the hypervisor that determines what virtual input devices will be available to the guest OS? Therefore, the hypervisor is in a position to expose exactly one pointer device and exactly one cursor plane to guest OS which means the guest OS cannot get the association wrong. If that's the general and expected hypervisor policy, then there is no need to design explicit device association in the guest kernel UAPI. If so, I'd like it to be mentioned in the kernel docs, too. > > > >> Any more complicated multi-user/multi-cursor setup would have to be > >> coordinated through a lot of layers (ie from the VM's usersp
Re: RFC: DSI host capabilities (was: [PATCH RFC 03/10] drm/panel: Add LGD panel driver for Sony Xperia XZ3)
On 06/07/2023 09:59, Maxime Ripard wrote:
On Thu, Jul 06, 2023 at 09:33:15AM +0200, Neil Armstrong wrote:
On 06/07/2023 09:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 11:09:40PM +0300, Dmitry Baryshkov wrote:
On 05/07/2023 19:53, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 06:20:13PM +0300, Dmitry Baryshkov wrote:
On Wed, 5 Jul 2023 at 17:24, Maxime Ripard wrote:
On Wed, Jul 05, 2023 at 04:37:57PM +0300, Dmitry Baryshkov wrote:
Either way, I'm not really sure it's a good idea to multiply the
capabilities flags of the DSI host, and we should just stick to the
spec. If the spec says that we have to support DSC while video is
output, then that's what the panels should expect.
Except some panels supports DSC & non-DSC, Video and Command mode, and
all that is runtime configurable. How do you handle that ?
In this case, most of the constraints are going to be on the encoder
still so it should be the one driving it. The panel will only care about
which mode has been selected, but it shouldn't be the one driving it,
and thus we still don't really need to expose the host capabilities.
This is an interesting perspective. This means that we can and actually have
to extend the drm_display_mode with the DSI data and compression
information.
I wouldn't extend drm_display_mode, but extending one of the state
structures definitely.
We already have some extra variables in drm_connector_state for HDMI,
I don't think it would be a big deal to add a few for MIPI-DSI.
We also floated the idea for a while to create bus-specific states, with
helpers to match. Maybe it would be a good occasion to start doing it?
For example, the panel that supports all four types for the 1080p should
export several modes:
1920x1080-command
1920x1080-command-DSC
1920x1080-video
1920x1080-video-DSC
where video/command and DSC are some kinds of flags and/or information in
the drm_display_mode? Ideally DSC also has several sub-flags, which denote
what kind of configuration is supported by the DSC sink (e.g. bpp, yuv,
etc).
So we have two things to do, right? We need to expose what the panel can
take (ie, EDID for HDMI), and then we need to tell it what we picked
(infoframes).
We already express the former in mipi_dsi_device, so we could extend the
flags stored there.
And then, we need to tie what the DSI host chose to a given atomic state
so the panel knows what was picked and how it should set everything up.
This is definitely something we need. Marijn has been stuck with the
panels that support different models ([1]).
Would you prefer a separate API for this kind of information or
abusing atomic_enable() is fine from your point of view?
My vote would be for going with existing operations, with the slight
fear of ending up with another DSI-specific hack (like
pre_enable_prev_first).
I don't think we can get away without getting access to the atomic_state
from the panel at least.
Choosing one setup over another is likely going to depend on the mode,
and that's only available in the state.
We don't have to go the whole way though and create the sub-classes of
drm_connector_state, but I think we should at least provide it to the
panel.
What do you think of creating a new set of atomic_* callbacks for
panels, call that new set of functions from msm and start from there?
We are (somewhat) bound by the panel_bridge, but yeah, it seems possible.
Bridges have access to the atomic state already, so it's another place
to plumb this through but I guess it would still be doable?
It's definitely doable, but I fear we won't be able to test most of the
panel drivers, should we introduce a new atomic set of panel callbacks ?
That was my original intent yeah :)
Creating an atomic_enable/disable/ etc. and then switch
drm_panel_enable() to take the state (and fixing up all the callers), or
create a drm_panel_enable_atomic() function.
The latter is probably simpler, something like:
int drm_panel_enable_atomic(struct drm_panel *panel,
struct drm_atomic_state *state)
{
struct drm_panel_funcs *funcs = panel->funcs;
if (funcs->atomic_enable)
return funcs->atomic_enable(panel, state);
return funcs->enable(panel);
}
And we should probably mention that it supersedes/deprecates
drm_panel_enable.
We've switched most of the other atomic hooks to take the full
drm_atomic_state so I'd prefer to use it. However, for it to be somewhat
useful we'd need to have access to the connector assigned to that panel.
drm_panel doesn't store the drm_connector it's connected to at all, and
of_drm_find_panel() doesn't take it as an argument so we can't fill it
when we retrieve it either.
So I guess we can go for:
- Create a new set of atomic hooks
- Create a new set of functions to call those hooks, that we would
document as deprecating the former functions. Those functions would
take a pointer to the drm_connector_state of the drm_connector it's
conn
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #56 from Harald Judt (h.j...@gmx.at) --- I think that the issue with VT-switching is not fixed by the commit, but by another measure, that is switching to a text console before hibernating (the script I use has an option to do this). This seems to prevent the freezes. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH v1] gpu: i915: display: Replace define function
On Thu, 06 Jul 2023, Minjie Du wrote: > Replace DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE. The subject prefix should be "drm/i915/psr: ". Please try git log on the file to see what is commonly used. The subject should say what's being done. "Replace define function" is way too generic to be useful. Even "Prefer DEFINE_DEBUGFS_ATTRIBUTE" is better. Finally, the commit message itself should say *why*. Why are we replacing DEFINE_SIMPLE_ATTRIBUTE with DEFINE_DEBUGFS_ATTRIBUTE? BR, Jani. > > Signed-off-by: Minjie Du > --- > drivers/gpu/drm/i915/display/intel_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_psr.c > b/drivers/gpu/drm/i915/display/intel_psr.c > index 56c17283b..822858f3e 100644 > --- a/drivers/gpu/drm/i915/display/intel_psr.c > +++ b/drivers/gpu/drm/i915/display/intel_psr.c > @@ -2998,7 +2998,7 @@ i915_edp_psr_debug_get(void *data, u64 *val) > return -ENODEV; > } > > -DEFINE_SIMPLE_ATTRIBUTE(i915_edp_psr_debug_fops, > +DEFINE_DEBUGFS_ATTRIBUTE(i915_edp_psr_debug_fops, > i915_edp_psr_debug_get, i915_edp_psr_debug_set, > "%llu\n"); -- Jani Nikula, Intel Open Source Graphics Center
[PULL] drm-intel-next-fixes
Hi Dave, Daniel, A weekly collection of fixes for the drm-next/6.5 merge window. Mostly small display fixups, one for GuC/SLPC and one header file tidy. I see last week did not get pulled so this week contains those ones plus two more fixups - one code tidy actually and one fixup. Regards, Tvrtko drm-intel-next-fixes-2023-06-29: - Allow DC states along with PW2 only for PWB functionality [adlp+] (Imre Deak) - Fix SSC selection for MPLLA [mtl] (Radhakrishna Sripada) - Use hw.adjusted mode when calculating io/fast wake times [psr] (Jouni Högander) - Apply min softlimit correctly [guc/slpc] (Vinay Belgaumkar) - Assign correct hdcp content type [hdcp] (Suraj Kandpal) - Add missing forward declarations/includes to display power headers (Imre Deak) drm-intel-next-fixes-2023-07-06: - Fix BDW PSR AUX CH data register offsets [psr] (Ville Syrjälä) - Use mock device info for creating mock device (Jani Nikula) The following changes since commit 274d4b96b12f78cef4f72a97a4967032233f6cae: drm/i915: Fix a NULL vs IS_ERR() bug (2023-06-20 08:54:47 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-07-06 for you to fetch changes up to f6cf3883df471abbcf1553127681dc244c8ff8dd: drm/i915: use mock device info for creating mock device (2023-07-04 10:40:29 +0100) drm-intel-next-fixes-2023-06-29: - Allow DC states along with PW2 only for PWB functionality [adlp+] (Imre Deak) - Fix SSC selection for MPLLA [mtl] (Radhakrishna Sripada) - Use hw.adjusted mode when calculating io/fast wake times [psr] (Jouni Högander) - Apply min softlimit correctly [guc/slpc] (Vinay Belgaumkar) - Assign correct hdcp content type [hdcp] (Suraj Kandpal) - Add missing forward declarations/includes to display power headers (Imre Deak) drm-intel-next-fixes-2023-07-06: - Fix BDW PSR AUX CH data register offsets [psr] (Ville Syrjälä) - Use mock device info for creating mock device (Jani Nikula) Imre Deak (2): drm/i915/adlp+: Allow DC states along with PW2 only for PWB functionality drm/i915: Add missing forward declarations/includes to display power headers Jani Nikula (1): drm/i915: use mock device info for creating mock device Jouni Högander (1): drm/i915/psr: Use hw.adjusted mode when calculating io/fast wake times Radhakrishna Sripada (1): drm/i915/mtl: Fix SSC selection for MPLLA Suraj Kandpal (1): drm/i915/hdcp: Assign correct hdcp content type Ville Syrjälä (1): drm/i915/psr: Fix BDW PSR AUX CH data register offsets Vinay Belgaumkar (1): drm/i915/guc/slpc: Apply min softlimit correctly drivers/gpu/drm/i915/display/intel_cx0_phy.c | 3 +- drivers/gpu/drm/i915/display/intel_display_power.h | 4 ++ .../gpu/drm/i915/display/intel_display_power_map.c | 16 .../drm/i915/display/intel_display_power_well.h| 2 + drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +- drivers/gpu/drm/i915/display/intel_psr.c | 4 +- drivers/gpu/drm/i915/display/intel_psr_regs.h | 2 +- drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c| 2 +- drivers/gpu/drm/i915/selftests/mock_gem_device.c | 45 -- 9 files changed, 45 insertions(+), 35 deletions(-)
[PATCH libdrm v2] amdgpu: Use PRI?64 to format uint64_t
On 32-bit:
../tests/amdgpu/amdgpu_stress.c: In function ‘alloc_bo’:
../tests/amdgpu/amdgpu_stress.c:178:49: warning: format ‘%lx’ expects
argument of type ‘long unsigned int’, but argument 4 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Allocated BO number %u at 0x%lx, domain 0x%x, size
%lu\n",
~~^
%llx
num_buffers++, addr, domain, size);
../tests/amdgpu/amdgpu_stress.c:178:72: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 6 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Allocated BO number %u at 0x%lx, domain 0x%x, size
%lu\n",
~~^
%llu
num_buffers++, addr, domain, size);
../tests/amdgpu/amdgpu_stress.c: In function ‘submit_ib’:
../tests/amdgpu/amdgpu_stress.c:276:54: warning: format ‘%lx’ expects
argument of type ‘long unsigned int’, but argument 5 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Submitted %u IBs to copy from %u(%lx) to %u(%lx) %lu
bytes took %lu usec\n",
~~^
%llx
count, from, virtual[from], to, virtual[to], copied, delta / 1000);
~
../tests/amdgpu/amdgpu_stress.c:276:65: warning: format ‘%lx’ expects
argument of type ‘long unsigned int’, but argument 7 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Submitted %u IBs to copy from %u(%lx) to %u(%lx) %lu
bytes took %lu usec\n",
~~^
%llx
count, from, virtual[from], to, virtual[to], copied, delta / 1000);
~~~
../tests/amdgpu/amdgpu_stress.c:276:70: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 8 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Submitted %u IBs to copy from %u(%lx) to %u(%lx) %lu
bytes took %lu usec\n",
~~^
%llu
count, from, virtual[from], to, virtual[to], copied, delta / 1000);
~~
../tests/amdgpu/amdgpu_stress.c:276:85: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 9 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stdout, "Submitted %u IBs to copy from %u(%lx) to %u(%lx) %lu
bytes took %lu usec\n",
~~^
%llu
count, from, virtual[from], to, virtual[to], copied, delta / 1000);
../tests/amdgpu/amdgpu_stress.c: In function ‘parse_size’:
../tests/amdgpu/amdgpu_stress.c:296:24: warning: format ‘%li’ expects
argument of type ‘long int *’, but argument 3 has type ‘uint64_t *’ {aka ‘long
long unsigned int *’} [-Wformat=]
if (sscanf(optarg, "%li%1[kmgKMG]", &size, ext) < 1) {
~~^ ~
%lli
../tests/amdgpu/amdgpu_stress.c: In function ‘main’:
../tests/amdgpu/amdgpu_stress.c:378:45: warning: format ‘%lu’ expects
argument of type ‘long unsigned int’, but argument 3 has type ‘uint64_t’ {aka
‘long long unsigned int’} [-Wformat=]
fprintf(stderr, "Buffer size to small %lu\n", size);
~~^
%llu
Fix this by using the proper "PRI?64" format specifiers.
Fixes: d77ccdf3ba6f5a39 ("amdgpu: add amdgpu_stress utility v2")
Signed-off-by: Geert Uytterhoeven
---
On Linux/amd64, the format strings in the resulting binary are
unchanged.
v2:
- Use PRI?64 to unbreak 64-bit build.
---
tests/amdgpu/amdgpu_stress.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/tests/amdgpu/amdgpu_stress.c b/tests/amdgpu/amdgpu_stress.c
index 5c5c88c5be985eb6..f919351e1f17d70b 100644
--- a/tests/amdgpu/amdgpu_stress.c
+++ b/tests/amdgpu/amdgpu_stress.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include "drm.h"
#include "xf86drmMode.h"
@@ -175,7 +176,7 @@ int alloc_bo(uint32_t domain, uint64_t size)
resources[num_buffers] = bo;
Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings
Hi, Danilo Some review comments below: On 6/30/23 00:25, Danilo Krummrich wrote: Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, making use of the maple_tree. It looks like we're not using the maple tree anymore, but rather an instantiation of an interval tree. (Perhaps as a follow-up it makes sense to provide a pre-instantiated common u64 version of the interval tree in addition to the unsigned long one since it appears to be used in multiple places in graphics drivers). 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Tested-by: Donald Robson Reviewed-by: Boris Brezillon Suggested-by: Dave Airlie Signed-off-by: Danilo Krummrich --- Documentation/gpu/drm-mm.rst| 36 + drivers/gpu/drm/Makefile|1 + drivers/gpu/drm/drm_gem.c |3 + drivers/gpu/drm/drm_gpuva_mgr.c | 1743 +++ include/drm/drm_drv.h |6 + include/drm/drm_gem.h | 52 + include/drm/drm_gpuva_mgr.h | 756 ++ 7 files changed, 2597 insertions(+) create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c create mode 100644 include/drm/drm_gpuva_mgr.h diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index a52e6f4117d6..3d5dc9dc1bfe 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -466,6 +466,42 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: +DRM GPU VA Manager +== + +Overview + + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Overview + +Split and Merge +--- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Split and Merge + +Locking +--- + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Locking + +Examples + + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :doc: Examples + +DRM GPU VA Manager Function References +-- + +.. kernel-doc:: include/drm/drm_gpuva_mgr.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c + :export: + DRM Buddy Allocator === diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 414855e2a463..6d6c9dec66e8 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -45,6 +45,7 @@ drm-y := \ drm_vblank.o \ drm_vblank_work.o \ drm_vma_manager.o \ + drm_gpuva_mgr.o \ drm_writeback.o drm-$(CONFIG_DRM_LEGACY) += \ drm_agpsupport.o \ diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 1a5a2cd0d4ec..cd878ebddbd0 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -164,6 +164,9 @@ void drm_gem_private_object_init(struct drm_device *dev, if (!obj->resv) obj->resv = &obj->_resv; + if (drm_core_check_feature(dev, DRIVER_GEM_GPUVA)) + drm_gem_gpuva_init(obj); + drm_vma_node_reset(&obj->vma_node); INIT_LIST_HEAD(&obj->lru_node); } diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c new file mode 100644 index ..4414990c05cc --- /dev/null +++ b/drivers/gpu/drm/drm_gpuva_mgr.c @@ -0,0 +1,1743 @@ +// SPDX-License-Identifier: GPL-2.0 +/* SPDX-License is GPL-2.0 but below looks like MIT. Can we use "GPL-2.0 OR MIT" or does something restrict it to GPL-only? + * Copyright (c) 2022 Red Hat. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice shall be included in + * all copies or substantial portions of the Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S
Re: [PATCH v2, 1/2] dt-bindings: display: mediatek: dp: Add compatible for MediaTek MT8188
On 06/07/2023 04:14, Shuijing Li wrote: > Add dt-binding documentation of dp-tx for MediaTek MT8188 SoC. > > Signed-off-by: Shuijing Li > Signed-off-by: Jitao Shi > --- > Changes in v2: > add a mediatek,mt8188-edp-tx compatible per suggestion from the previous > thread: > https://lore.kernel.org/lkml/c4a4a900-c80d-b110-f10e-7fa2dae8b...@collabora.com/ > --- Acked-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH] Covert to use time_before macro
Correct the format of the Subject in v2: https://lore.kernel.org/all/20230706072924.2562-1-zhangze...@vivo.com/
Re: [PATCH v3 4/4] drm/panel: ili9882t: Break out function for switching page
Hi,
On Mon, Jul 3, 2023 at 9:22 PM Linus Walleij wrote:
>
> The ILI9882t has similarities with other Ilitek panels, such
> as the characteristic internal page switching code that uses
> the model number (0x98, 0x82) as parameter.
>
> We can clearly abstract out the page switching sequence from
> the initialization code.
>
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 54
> ++-
> 1 file changed, 37 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> index 20f3cc37fa83..c1a0f10fbaf7 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9882t.c
> @@ -55,13 +55,33 @@ struct ili9882t {
> struct gpio_desc *enable_gpio;
> };
>
> +/* ILI9882-specific commands, add new commands as you decode them */
> +#define ILI9882T_DCS_SWITCH_PAGE 0xFF
> +
> +static int ili9882t_switch_page(struct mipi_dsi_device *dsi, u8 page)
> +{
> + u8 switch_cmd[] = {0x98, 0x82, 0x00};
> + int ret;
> +
> + switch_cmd[2] = page;
> +
> + ret = mipi_dsi_dcs_write(dsi, ILI9882T_DCS_SWITCH_PAGE, switch_cmd,
> 3);
> + if (ret) {
> + dev_err(&dsi->dev,
> + "error switching panel controller page (%d)\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> static int starry_ili9882t_init(struct mipi_dsi_device *dsi)
> {
> int ret;
>
> msleep(5);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x01);
> + ili9882t_switch_page(dsi, 0x01);
> mipi_dsi_dcs_write_seq(dsi, 0x00, 0x42);
> mipi_dsi_dcs_write_seq(dsi, 0x01, 0x11);
> mipi_dsi_dcs_write_seq(dsi, 0x02, 0x00);
> @@ -192,7 +212,7 @@ static int starry_ili9882t_init(struct mipi_dsi_device
> *dsi)
> mipi_dsi_dcs_write_seq(dsi, 0x8B, 0x07);
> mipi_dsi_dcs_write_seq(dsi, 0x8C, 0x07);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x02);
> + ili9882t_switch_page(dsi, 0x02);
> mipi_dsi_dcs_write_seq(dsi, 0x29, 0x3A);
> mipi_dsi_dcs_write_seq(dsi, 0x2A, 0x3B);
>
> @@ -211,12 +231,12 @@ static int starry_ili9882t_init(struct mipi_dsi_device
> *dsi)
> mipi_dsi_dcs_write_seq(dsi, 0x5E, 0x40);
> mipi_dsi_dcs_write_seq(dsi, 0x84, 0x00);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x03);
> + ili9882t_switch_page(dsi, 0x03);
> mipi_dsi_dcs_write_seq(dsi, 0x20, 0x01);
> mipi_dsi_dcs_write_seq(dsi, 0x21, 0x3C);
> mipi_dsi_dcs_write_seq(dsi, 0x22, 0xFA);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x0A);
> + ili9882t_switch_page(dsi, 0x0a);
> mipi_dsi_dcs_write_seq(dsi, 0xE0, 0x01);
> mipi_dsi_dcs_write_seq(dsi, 0xE2, 0x01);
> mipi_dsi_dcs_write_seq(dsi, 0xE5, 0x91);
> @@ -224,10 +244,10 @@ static int starry_ili9882t_init(struct mipi_dsi_device
> *dsi)
> mipi_dsi_dcs_write_seq(dsi, 0xE7, 0x00);
> mipi_dsi_dcs_write_seq(dsi, 0xE8, 0xFA);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x12);
> + ili9882t_switch_page(dsi, 0x12);
> mipi_dsi_dcs_write_seq(dsi, 0x87, 0x2C);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x05);
> + ili9882t_switch_page(dsi, 0x05);
> mipi_dsi_dcs_write_seq(dsi, 0x73, 0xE5);
> mipi_dsi_dcs_write_seq(dsi, 0x7F, 0x6B);
> mipi_dsi_dcs_write_seq(dsi, 0x6D, 0xA4);
> @@ -242,7 +262,7 @@ static int starry_ili9882t_init(struct mipi_dsi_device
> *dsi)
> mipi_dsi_dcs_write_seq(dsi, 0x1D, 0x90);
> mipi_dsi_dcs_write_seq(dsi, 0x86, 0x87);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x06);
> + ili9882t_switch_page(dsi, 0x06);
> mipi_dsi_dcs_write_seq(dsi, 0xC0, 0x80);
> mipi_dsi_dcs_write_seq(dsi, 0xC1, 0x07);
> mipi_dsi_dcs_write_seq(dsi, 0xCA, 0x58);
> @@ -256,7 +276,7 @@ static int starry_ili9882t_init(struct mipi_dsi_device
> *dsi)
> mipi_dsi_dcs_write_seq(dsi, 0xD6, 0x55);
> mipi_dsi_dcs_write_seq(dsi, 0xDC, 0x38);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x08);
> + ili9882t_switch_page(dsi, 0x08);
> mipi_dsi_dcs_write_seq(dsi, 0xE0, 0x00, 0x10, 0x2A, 0x4D, 0x61, 0x56,
> 0x6A, 0x6E, 0x79,
>0x76, 0x8F, 0x95, 0x98, 0xAE, 0xAA, 0xB2,
> 0xBB, 0xCE, 0xC6, 0xBD,
>0xD5, 0xE2, 0xE8);
> @@ -264,10 +284,10 @@ static int starry_ili9882t_init(struct mipi_dsi_device
> *dsi)
>0x76, 0x8F, 0x95, 0x98, 0xAE, 0xAA, 0xB2,
> 0xBB, 0xCE, 0xC6, 0xBD,
>0xD5, 0xE2, 0xE8);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xFF, 0x98, 0x82, 0x04);
> + ili9882t_switch_page(dsi, 0x04);
> mipi_dsi_dcs_write_seq(dsi, 0xBA, 0x81);
>
> - mipi_dsi_dcs_write_seq(dsi, 0xF
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
On 04/07/2023 18:45, Jocelyn Falempe wrote:
On 04/07/2023 16:54, Jani Nikula wrote:
On Fri, 23 Jun 2023, Jocelyn Falempe wrote:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480,
which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.
This conflates "monitor connected" and "EDID present", which are not
necessarily the same thing.
The fallback in drm_helper_probe_single_connector_modes() is for no
modes, but connector status is connected or unknown.
When debugging the issue, I found it surprising that the status is
"connected" when nothing is plugged in the DP port.
You could add a connector ->detect callback that returns disconnected
when there's no display, and the problem should go away. If there's no
->detect callback, it'll default to connected.
ok, I'll try that. I don't know how the hardware detect something is
connected, but looking at the dp code, maybe checking
"AST_IO_CRTC_PORT,0xDC, ASTDP_LINK_SUCCESS" would be good enough.
I've tested this approach, and it works. But on the server I'm testing,
there are VGA and DP output. I think on a server that has only one DP
output, if no monitor is connected, then no modes will be reported to
userspace, and the remote BMC may not work ?
Also I don't have physical access to the server, so I only tested when
no monitor is plugged.
I will send shortly a v2 with this change, so others can help me test
this case.
Best regards,
--
Jocelyn
Fixes: fae7d186403e ("drm/probe-helper: Default to 640x480 if no EDID
on DP")
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c
b/drivers/gpu/drm/ast/ast_mode.c
index 36374828f6c8..8f7b7cc021c7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1589,9 +1589,31 @@ static const struct drm_connector_helper_funcs
ast_dp501_connector_helper_funcs
.get_modes = ast_dp501_connector_helper_get_modes,
};
+static int ast_dp_probe_single_connector_modes(struct drm_connector
*connector,
+ uint32_t maxX, uint32_t maxY)
+{
+ int ret;
+ struct drm_display_mode *mode;
+
+ ret = drm_helper_probe_single_connector_modes(connector, maxX,
maxY);
+ /*
+ * When no monitor are detected, DP now default to 640x480
+ * As aspeed is mostly used in remote server, and DP monitors are
+ * rarely attached, it's better to default to 1024x768
+ */
+ if (!connector->edid_blob_ptr) {
Please try not to use connector->edid_blob_ptr for anything in
drivers. The logic is complicated enough as it is, with the firmware and
override EDIDs and everything, and makes future refactoring of EDID
handling harder.
Ok, I will try your other suggestion, and remove this.
Thanks a lot for your comments.
Re: [PATCH 2/2] drm/bridge: lt9611: Do not generate HFP/HBP/HSA and EOT packet
On Wed, 5 Jul 2023 at 11:09, Dmitry Baryshkov wrote: > > [Adding freedreno@ to cc list] > > On Wed, 5 Jul 2023 at 08:31, Jagan Teki wrote: > > > > Hi Amit, > > > > On Wed, Jul 5, 2023 at 10:15 AM Amit Pundir wrote: > > > > > > Hi Marek, > > > > > > On Wed, 5 Jul 2023 at 01:48, Marek Vasut wrote: > > > > > > > > Do not generate the HS front and back porch gaps, the HSA gap and > > > > EOT packet, as these packets are not required. This makes the bridge > > > > work with Samsung DSIM on i.MX8MM and i.MX8MP. > > > > > > This patch broke display on Dragonboard 845c (SDM845) devboard running > > > AOSP. This is what I see > > > https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg. > > > Reverting this patch fixes this regression for me. > > > > Might be msm dsi host require proper handling on these updated > > mode_flags? did they? > > The msm DSI host supports those flags. Also, I'd like to point out > that the patch didn't change the rest of the driver code. So even if > drm/msm ignored some of the flags, it should not have caused the > issue. Most likely the issue is on the lt9611 side. I's suspect that > additional programming is required to make it work with these flags. I spent some time today on smoke testing these flags (individually and in limited combination) on DB845c, to narrow down this breakage to one or more flag(s) triggering it. Here are my observations in limited testing done so far. There is no regression with MIPI_DSI_MODE_NO_EOT_PACKET when enabled alone and system boots to UI as usual. MIPI_DSI_MODE_VIDEO_NO_HFP always trigger the broken display as in the screenshot[1] shared earlier as well. Adding either of MIPI_DSI_MODE_VIDEO_NO_HSA and MIPI_DSI_MODE_VIDEO_NO_HBP always result in no display, unless paired with MIPI_DSI_MODE_VIDEO_NO_HFP and in that case we get the broken display as reported. In short other than MIPI_DSI_MODE_NO_EOT_PACKET flag, all other flags added in this commit break the display on DB845c one way or another. Regards, Amit Pundir [1] https://people.linaro.org/~amit.pundir/db845c-userdebug/v6.5-broken-display/PXL_20230704_150156326.jpg > > -- > With best wishes > Dmitry
[PATCH] drm/imx/lcdc: Fix double-free of driver data
The struct imx_lcdc driver data is allocated using devm_drm_dev_alloc()
so it must not be explicitly kfree()d.
Also drm_kms_helper_poll_fini() should not be called as there is no
matching drm_kms_helper_poll_init(). So drop the release function
completely.
Fixes: c87e859cdeb5 ("drm/imx/lcdc: Implement DRM driver for imx25")
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/imx/lcdc/imx-lcdc.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
index 8e6d457917da..7bd433847824 100644
--- a/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
+++ b/drivers/gpu/drm/imx/lcdc/imx-lcdc.c
@@ -342,21 +342,12 @@ static const struct drm_mode_config_helper_funcs
imx_lcdc_mode_config_helpers =
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
};
-static void imx_lcdc_release(struct drm_device *drm)
-{
- struct imx_lcdc *lcdc = imx_lcdc_from_drmdev(drm);
-
- drm_kms_helper_poll_fini(drm);
- kfree(lcdc);
-}
-
DEFINE_DRM_GEM_DMA_FOPS(imx_lcdc_drm_fops);
static struct drm_driver imx_lcdc_drm_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.fops = &imx_lcdc_drm_fops,
DRM_GEM_DMA_DRIVER_OPS_VMAP,
- .release = imx_lcdc_release,
.name = "imx-lcdc",
.desc = "i.MX LCDC driver",
.date = "20200716",
base-commit: 6995e2de6891c724bfeb2db33d7b87775f913ad1
--
2.39.2
[drm-rerere] nightly.conf: drop sound tree from drm-tip altogether
We used to have the sound branches be part of drm-tip to help development of DP and HDMI audio. However, we always used to run into problems with the sound branches merging Linus' master at non-tagged random commits, wreaking havoc especially during the merge windows. We only ever want to have tagged stuff merged back from Linus' tree to drm-tip. We introduced a mechanism in dim to hold back branches at certain commits, just to hold back sound branches when problems arise. We moved it along, but in the end nobody has updated this in literally years, and sound branches have been held back at v5.13. The merge window is currently open, and AFAICT the sound/for-linus branch again contains commits from the merge window. Let's just forget about the sound tree, as nobody has really missed it since v5.13, and focus on the drm branches. Signed-off-by: Jani Nikula --- nightly.conf | 7 --- 1 file changed, 7 deletions(-) diff --git a/nightly.conf b/nightly.conf index 73aec820e98f..c1e22800e276 100644 --- a/nightly.conf +++ b/nightly.conf @@ -46,11 +46,6 @@ git://anongit.freedesktop.org/drm/drm https://anongit.freedesktop.org/git/drm/drm https://anongit.freedesktop.org/git/drm/drm.git " -drm_tip_repos[sound-upstream]=" -git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git -https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git -https://kernel.googlesource.com/pub/scm/linux/kernel/git/tiwai/sound.git -" drm_tip_repos[linux-upstream]=" git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git @@ -79,8 +74,6 @@ drm_tip_config=( "drm-intel drm-intel-next" "drm-intel drm-intel-gt-next" - "sound-upstream for-linus v5.13" - "sound-upstream for-nextv5.13" "drm-intel topic/core-for-CI" "drm-misc topic/i915-ttm" "drmtopic/nouveau-misc" -- 2.39.2
[Bug 217636] Commit edcfed8671 disables previously supported video resolutions (on AMD Rembrandt)
https://bugzilla.kernel.org/show_bug.cgi?id=217636 Artem S. Tashkinov (a...@gmx.com) changed: What|Removed |Added Bisected commit-id||aa9704d5127f06c9ffedb0480d2 ||788b87fecedfb Status|NEW |RESOLVED Kernel Version||6.3.9 Resolution|--- |PATCH_ALREADY_AVAILABLE Regression|No |Yes -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
On Thu, 06 Jul 2023, Jocelyn Falempe wrote:
> On 04/07/2023 18:45, Jocelyn Falempe wrote:
>> On 04/07/2023 16:54, Jani Nikula wrote:
>>> On Fri, 23 Jun 2023, Jocelyn Falempe wrote:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480,
which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.
>>>
>>> This conflates "monitor connected" and "EDID present", which are not
>>> necessarily the same thing.
>>>
>>> The fallback in drm_helper_probe_single_connector_modes() is for no
>>> modes, but connector status is connected or unknown.
>>
>> When debugging the issue, I found it surprising that the status is
>> "connected" when nothing is plugged in the DP port.
>>>
>>> You could add a connector ->detect callback that returns disconnected
>>> when there's no display, and the problem should go away. If there's no
>>> ->detect callback, it'll default to connected.
>>
>> ok, I'll try that. I don't know how the hardware detect something is
>> connected, but looking at the dp code, maybe checking
>> "AST_IO_CRTC_PORT,0xDC, ASTDP_LINK_SUCCESS" would be good enough.
>
> I've tested this approach, and it works.
\o/
> But on the server I'm testing,
> there are VGA and DP output. I think on a server that has only one DP
> output, if no monitor is connected, then no modes will be reported to
> userspace, and the remote BMC may not work ?
I couldn't say, but having the driver lie about the connected status to
make it work feels wrong.
> Also I don't have physical access to the server, so I only tested when
> no monitor is plugged.
>
> I will send shortly a v2 with this change, so others can help me test
> this case.
Thanks,
Jani.
>
> Best regards,
--
Jani Nikula, Intel Open Source Graphics Center
[PATCH v2] drm/ast: report connection status on Display Port.
Aspeed always report the display port as "connected", because it
doesn't set a .detect callback.
Fix this by providing the proper detect callback for astdp and dp501.
This also fixes the following regression:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the remote BMC resolution to 640x480,
which is inconvenient, and breaks the anaconda installer.
v2: Add .detect callback to the dp/dp501 connector (Jani Nikula)
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_dp.c| 9
drivers/gpu/drm/ast/ast_dp501.c | 37 ++---
drivers/gpu/drm/ast/ast_drv.h | 2 ++
drivers/gpu/drm/ast/ast_mode.c | 24 +
4 files changed, 60 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp.c b/drivers/gpu/drm/ast/ast_dp.c
index 6dc1a09504e1..fbc154930fdf 100644
--- a/drivers/gpu/drm/ast/ast_dp.c
+++ b/drivers/gpu/drm/ast/ast_dp.c
@@ -7,6 +7,15 @@
#include
#include "ast_drv.h"
+bool ast_astdp_is_connected(struct ast_device *ast)
+{
+ if (ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xD1,
ASTDP_MCU_FW_EXECUTING) &&
+ ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDC,
ASTDP_LINK_SUCCESS) &&
+ ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xDF, ASTDP_HPD))
+ return true;
+ return false;
+}
+
int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata)
{
struct ast_device *ast = to_ast_device(dev);
diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index a5d285850ffb..f10d53b0c94f 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -272,11 +272,9 @@ static bool ast_launch_m68k(struct drm_device *dev)
return true;
}
-bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata)
+bool ast_dp501_is_connected(struct ast_device *ast)
{
- struct ast_device *ast = to_ast_device(dev);
- u32 i, boot_address, offset, data;
- u32 *pEDIDidx;
+ u32 boot_address, offset, data;
if (ast->config_mode == ast_use_p2a) {
boot_address = get_fw_base(ast);
@@ -292,14 +290,6 @@ bool ast_dp501_read_edid(struct drm_device *dev, u8
*ediddata)
data = ast_mindwm(ast, boot_address + offset);
if (!(data & AST_DP501_PNP_CONNECTED))
return false;
-
- /* Read EDID */
- offset = AST_DP501_EDID_DATA;
- for (i = 0; i < 128; i += 4) {
- data = ast_mindwm(ast, boot_address + offset + i);
- pEDIDidx = (u32 *)(ediddata + i);
- *pEDIDidx = data;
- }
} else {
if (!ast->dp501_fw_buf)
return false;
@@ -319,7 +309,30 @@ bool ast_dp501_read_edid(struct drm_device *dev, u8
*ediddata)
data = readl(ast->dp501_fw_buf + offset);
if (!(data & AST_DP501_PNP_CONNECTED))
return false;
+ }
+ return true;
+}
+
+bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata)
+{
+ struct ast_device *ast = to_ast_device(dev);
+ u32 i, boot_address, offset, data;
+ u32 *pEDIDidx;
+
+ if (!ast_dp501_is_connected(ast))
+ return false;
+
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
+ /* Read EDID */
+ offset = AST_DP501_EDID_DATA;
+ for (i = 0; i < 128; i += 4) {
+ data = ast_mindwm(ast, boot_address + offset + i);
+ pEDIDidx = (u32 *)(ediddata + i);
+ *pEDIDidx = data;
+ }
+ } else {
/* Read EDID */
offset = AST_DP501_EDID_DATA;
for (i = 0; i < 128; i += 4) {
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 3f6e0c984523..99a24d779b9c 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -510,6 +510,7 @@ void ast_patch_ahb_2500(struct ast_device *ast);
/* ast dp501 */
void ast_set_dp501_video_output(struct drm_device *dev, u8 mode);
bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32 size);
+bool ast_dp501_is_connected(struct ast_device *ast);
bool ast_dp501_read_edid(struct drm_device *dev, u8 *ediddata);
u8 ast_get_dp501_max_clk(struct drm_device *dev);
void ast_init_3rdtx(struct drm_device *dev);
@@ -518,6 +519,7 @@ void ast_init_3rdtx(struct drm_device *dev);
struct ast_i2c_chan *ast_i2c_create(struct drm_device *dev);
/* aspeed DP */
+bool ast_astdp_is_connected(struct ast_device *ast);
int ast_astdp_read_edid(struct drm_device *dev, u8 *ediddata);
void ast_dp_launch(struct drm_devi
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
On 06/07/2023 11:32, Jani Nikula wrote:
On Thu, 06 Jul 2023, Jocelyn Falempe wrote:
On 04/07/2023 18:45, Jocelyn Falempe wrote:
On 04/07/2023 16:54, Jani Nikula wrote:
On Fri, 23 Jun 2023, Jocelyn Falempe wrote:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480,
which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.
This conflates "monitor connected" and "EDID present", which are not
necessarily the same thing.
The fallback in drm_helper_probe_single_connector_modes() is for no
modes, but connector status is connected or unknown.
When debugging the issue, I found it surprising that the status is
"connected" when nothing is plugged in the DP port.
You could add a connector ->detect callback that returns disconnected
when there's no display, and the problem should go away. If there's no
->detect callback, it'll default to connected.
ok, I'll try that. I don't know how the hardware detect something is
connected, but looking at the dp code, maybe checking
"AST_IO_CRTC_PORT,0xDC, ASTDP_LINK_SUCCESS" would be good enough.
I've tested this approach, and it works.
\o/
But on the server I'm testing,
there are VGA and DP output. I think on a server that has only one DP
output, if no monitor is connected, then no modes will be reported to
userspace, and the remote BMC may not work ?
I couldn't say, but having the driver lie about the connected status to
make it work feels wrong.
Yes, so maybe a better way would be to add a remote/bmc connector, with
proper default resolution ?
That will better reflect what the hardware does.
--
Jocelyn
Also I don't have physical access to the server, so I only tested when
no monitor is plugged.
I will send shortly a v2 with this change, so others can help me test
this case.
Thanks,
Jani.
Best regards,
Re: [PATCH v2, 1/2] dt-bindings: display: mediatek: dp: Add compatible for MediaTek MT8188
Il 06/07/23 04:14, Shuijing Li ha scritto: Add dt-binding documentation of dp-tx for MediaTek MT8188 SoC. Signed-off-by: Shuijing Li Signed-off-by: Jitao Shi Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
On Thu, 06 Jul 2023, Jocelyn Falempe wrote: > Yes, so maybe a better way would be to add a remote/bmc connector, with > proper default resolution ? > That will better reflect what the hardware does. I'm afraid I don't know enough about the hardware or use case to say. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
Hi
Am 06.07.23 um 11:16 schrieb Jocelyn Falempe:
On 04/07/2023 18:45, Jocelyn Falempe wrote:
On 04/07/2023 16:54, Jani Nikula wrote:
On Fri, 23 Jun 2023, Jocelyn Falempe wrote:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480,
which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.
This conflates "monitor connected" and "EDID present", which are not
necessarily the same thing.
The fallback in drm_helper_probe_single_connector_modes() is for no
modes, but connector status is connected or unknown.
When debugging the issue, I found it surprising that the status is
"connected" when nothing is plugged in the DP port.
You could add a connector ->detect callback that returns disconnected
when there's no display, and the problem should go away. If there's no
->detect callback, it'll default to connected.
ok, I'll try that. I don't know how the hardware detect something is
connected, but looking at the dp code, maybe checking
"AST_IO_CRTC_PORT,0xDC, ASTDP_LINK_SUCCESS" would be good enough.
I've tested this approach, and it works. But on the server I'm testing,
there are VGA and DP output. I think on a server that has only one DP
output, if no monitor is connected, then no modes will be reported to
userspace, and the remote BMC may not work ?
You could out-comment the VGA code in the ast driver for testing.
Best regards
Thomas
Also I don't have physical access to the server, so I only tested when
no monitor is plugged.
I will send shortly a v2 with this change, so others can help me test
this case.
Best regards,
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v2,2/2] drm/mediatek: dp: Add the audio control to mtk_dp_data struct
Il 06/07/23 04:14, Shuijing Li ha scritto:
Mainly add the following two flag:
1.The audio packet arrangement function is to only arrange audio
packets into the Hblanking area. In order to align with the HW
default setting of g1200, this function needs to be turned off.
2.Due to the difference of HW, different dividers need to be set.
Signed-off-by: Shuijing Li
Signed-off-by: Jitao Shi
---
Changes in v2:
- change the variables' name to be more descriptive
- add a comment that describes the function of mtk_dp_audio_sample_arrange
- reduce indentation by doing the inverse check
- add a definition of some bits
- add support for mediatek, mt8188-edp-tx
per suggestion from the previous thread:
https://lore.kernel.org/lkml/ac0fcec9-a2fe-06cc-c727-189ef7bab...@collabora.com/
---
drivers/gpu/drm/mediatek/mtk_dp.c | 47 ++-
drivers/gpu/drm/mediatek/mtk_dp_reg.h | 6
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 64eee77452c0..8e1a13ab2ba2 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -139,6 +139,8 @@ struct mtk_dp_data {
unsigned int smc_cmd;
const struct mtk_dp_efuse_fmt *efuse_fmt;
bool audio_supported;
+ bool audio_pkt_in_hblank_area;
+ u16 audio_m_div2_bit;
};
static const struct mtk_dp_efuse_fmt mt8195_edp_efuse_fmt[MTK_DP_CAL_MAX] = {
@@ -647,7 +649,7 @@ static void mtk_dp_audio_sdp_asp_set_channels(struct mtk_dp
*mtk_dp,
static void mtk_dp_audio_set_divider(struct mtk_dp *mtk_dp)
{
mtk_dp_update_bits(mtk_dp, MTK_DP_ENC0_P0_30BC,
- AUDIO_M_CODE_MULT_DIV_SEL_DP_ENC0_P0_DIV_2,
+ mtk_dp->data->audio_m_div2_bit,
AUDIO_M_CODE_MULT_DIV_SEL_DP_ENC0_P0_MASK);
}
@@ -1362,6 +1364,18 @@ static void mtk_dp_sdp_set_down_cnt_init_in_hblank(struct mtk_dp *mtk_dp)
SDP_DOWN_CNT_INIT_IN_HBLANK_DP_ENC1_P0_MASK);
}
+static void mtk_dp_audio_sample_arrange(struct mtk_dp *mtk_dp)
+{
+ /* arrange audio packets into the Hblanking and Vblanking area */
+ if (!mtk_dp->data->audio_pkt_in_hblank_area)
+ return;
There's only one remaining question: why is this done for MT8188 but *not* for
MT8195?
Thanks,
Angelo
+
+ mtk_dp_update_bits(mtk_dp, MTK_DP_ENC1_P0_3374, 0,
+ SDP_ASP_INSERT_IN_HBLANK_DP_ENC1_P0_MASK);
+ mtk_dp_update_bits(mtk_dp, MTK_DP_ENC1_P0_3374, 0,
+ SDP_DOWN_ASP_CNT_INIT_DP_ENC1_P0_MASK);
+}
+
static void mtk_dp_setup_tu(struct mtk_dp *mtk_dp)
{
u32 sram_read_start = min_t(u32, MTK_DP_TBC_BUF_READ_START_ADDR,
@@ -1371,6 +1385,7 @@ static void mtk_dp_setup_tu(struct mtk_dp *mtk_dp)
MTK_DP_PIX_PER_ADDR);
mtk_dp_set_sram_read_start(mtk_dp, sram_read_start);
mtk_dp_setup_encoder(mtk_dp);
+ mtk_dp_audio_sample_arrange(mtk_dp);
mtk_dp_sdp_set_down_cnt_init_in_hblank(mtk_dp);
mtk_dp_sdp_set_down_cnt_init(mtk_dp, sram_read_start);
}
@@ -2616,11 +2631,31 @@ static int mtk_dp_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(mtk_dp_pm_ops, mtk_dp_suspend, mtk_dp_resume);
+static const struct mtk_dp_data mt8188_edp_data = {
+ .bridge_type = DRM_MODE_CONNECTOR_eDP,
+ .smc_cmd = MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE,
+ .efuse_fmt = mt8195_edp_efuse_fmt,
+ .audio_supported = false,
+ .audio_pkt_in_hblank_area = false,
+ .audio_m_div2_bit = MT8188_AUDIO_M_CODE_MULT_DIV_SEL_DP_ENC0_P0_DIV_2,
+};
+
+static const struct mtk_dp_data mt8188_dp_data = {
+ .bridge_type = DRM_MODE_CONNECTOR_DisplayPort,
+ .smc_cmd = MTK_DP_SIP_ATF_VIDEO_UNMUTE,
+ .efuse_fmt = mt8195_dp_efuse_fmt,
+ .audio_supported = true,
+ .audio_pkt_in_hblank_area = true,
+ .audio_m_div2_bit = MT8188_AUDIO_M_CODE_MULT_DIV_SEL_DP_ENC0_P0_DIV_2,
+};
+
static const struct mtk_dp_data mt8195_edp_data = {
.bridge_type = DRM_MODE_CONNECTOR_eDP,
.smc_cmd = MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE,
.efuse_fmt = mt8195_edp_efuse_fmt,
.audio_supported = false,
+ .audio_pkt_in_hblank_area = false,
+ .audio_m_div2_bit = AUDIO_M_CODE_MULT_DIV_SEL_DP_ENC0_P0_DIV_2,
};
static const struct mtk_dp_data mt8195_dp_data = {
@@ -2628,9 +2663,19 @@ static const struct mtk_dp_data mt8195_dp_data = {
.smc_cmd = MTK_DP_SIP_ATF_VIDEO_UNMUTE,
.efuse_fmt = mt8195_dp_efuse_fmt,
.audio_supported = true,
+ .audio_pkt_in_hblank_area = false,
+ .audio_m_div2_bit = AUDIO_M_CODE_MULT_DIV_SEL_DP_ENC0_P0_DIV_2,
};
static const struct of_device_id mtk_dp_of_match[] = {
+ {
+ .compatible = "mediatek,mt8188-edp-tx",
+ .data = &mt8188_edp_data,
+ },
+ {
+ .compatible =
[PATCH v2 2/4] fbdev/sm712fb: Do not include
Sm712fb's dependency on is artificial in that
it only uses struct screen_info for its internals. Replace the use of
struct screen_info with a custom data structure and remove the include
of .
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Cc: Sudip Mukherjee
Cc: Teddy Wang
Cc: Helge Deller
---
drivers/video/fbdev/sm712fb.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index b7ad3c644e13..f929091da4e7 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -27,12 +27,17 @@
#include
#include
#include
-#include
#include
#include "sm712.h"
+struct smtcfb_screen_info {
+ u16 lfb_width;
+ u16 lfb_height;
+ u16 lfb_depth;
+};
+
/*
* Private structure
*/
@@ -829,7 +834,7 @@ static const struct modeinit vgamode[] = {
},
};
-static struct screen_info smtc_scr_info;
+static struct smtcfb_screen_info smtc_scr_info;
static char *mode_option;
--
2.41.0
[PATCH v2 4/4] staging/sm750fb: Do not include
The sm750fb driver does not need anything from . Remove the include statements. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Cc: Sudip Mukherjee Cc: Teddy Wang --- drivers/staging/sm750fb/sm750.c| 1 - drivers/staging/sm750fb/sm750_accel.c | 1 - drivers/staging/sm750fb/sm750_cursor.c | 1 - drivers/staging/sm750fb/sm750_hw.c | 1 - 4 files changed, 4 deletions(-) diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c index 55e302a27847..c260f73cf570 100644 --- a/drivers/staging/sm750fb/sm750.c +++ b/drivers/staging/sm750fb/sm750.c @@ -14,7 +14,6 @@ #include #include #include -#include #include #include "sm750.h" diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c index 24b9077a634a..44b9e3fe3a41 100644 --- a/drivers/staging/sm750fb/sm750_accel.c +++ b/drivers/staging/sm750fb/sm750_accel.c @@ -14,7 +14,6 @@ #include #include #include -#include #include "sm750.h" #include "sm750_accel.h" diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c index 43e6f52c2551..eea4d1bd36ce 100644 --- a/drivers/staging/sm750fb/sm750_cursor.c +++ b/drivers/staging/sm750fb/sm750_cursor.c @@ -14,7 +14,6 @@ #include #include #include -#include #include "sm750.h" #include "sm750_cursor.h" diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c index 55cb00e8b0d1..71247eaf26ee 100644 --- a/drivers/staging/sm750fb/sm750_hw.c +++ b/drivers/staging/sm750fb/sm750_hw.c @@ -17,7 +17,6 @@ #include #endif #include -#include #include #include "sm750.h" -- 2.41.0
[PATCH v2 0/4] Remove unnecessary includes of
(was: arch,fbdev: Move screen_info into arch/) Remove include statements of The patches have been reviewed as part of the patchset at [1]. Patch 1 has a fix to make it build on loongarch. v2: * update loongarch [1] https://patchwork.freedesktop.org/series/120010/#rev1 Thomas Zimmermann (4): efi: Do not include from EFI header fbdev/sm712fb: Do not include sysfb: Do not include from sysfb header staging/sm750fb: Do not include arch/arm/kernel/efi.c | 2 ++ arch/arm64/kernel/efi.c | 1 + arch/loongarch/kernel/efi.c | 1 + drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++ drivers/firmware/efi/libstub/screen_info.c| 2 ++ drivers/staging/sm750fb/sm750.c | 1 - drivers/staging/sm750fb/sm750_accel.c | 1 - drivers/staging/sm750fb/sm750_cursor.c| 1 - drivers/staging/sm750fb/sm750_hw.c| 1 - drivers/video/fbdev/sm712fb.c | 9 +++-- include/linux/efi.h | 3 ++- include/linux/sysfb.h | 3 ++- 12 files changed, 19 insertions(+), 8 deletions(-) -- 2.41.0
[PATCH v2 1/4] efi: Do not include from EFI header
The header file does not need anything from . Declare struct screen_info and remove the include statements. Update a number of source files that require struct screen_info's definition. v2: * update loongarch (Jingfeng) Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Reviewed-by: Sui Jingfeng Cc: Ard Biesheuvel Cc: Russell King Cc: Catalin Marinas Cc: Will Deacon --- arch/arm/kernel/efi.c | 2 ++ arch/arm64/kernel/efi.c | 1 + arch/loongarch/kernel/efi.c | 1 + drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++ drivers/firmware/efi/libstub/screen_info.c| 2 ++ include/linux/efi.h | 3 ++- 6 files changed, 10 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c index e2b9d2618c67..e94655ef16bb 100644 --- a/arch/arm/kernel/efi.c +++ b/arch/arm/kernel/efi.c @@ -5,6 +5,8 @@ #include #include +#include + #include #include #include diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c index baab8dd3ead3..3afbe503b066 100644 --- a/arch/arm64/kernel/efi.c +++ b/arch/arm64/kernel/efi.c @@ -9,6 +9,7 @@ #include #include +#include #include #include diff --git a/arch/loongarch/kernel/efi.c b/arch/loongarch/kernel/efi.c index 3d448fef3af4..9fc10cea21e1 100644 --- a/arch/loongarch/kernel/efi.c +++ b/arch/loongarch/kernel/efi.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include diff --git a/drivers/firmware/efi/libstub/efi-stub-entry.c b/drivers/firmware/efi/libstub/efi-stub-entry.c index cc4dcaea67fa..2f1902e5d407 100644 --- a/drivers/firmware/efi/libstub/efi-stub-entry.c +++ b/drivers/firmware/efi/libstub/efi-stub-entry.c @@ -1,6 +1,8 @@ // SPDX-License-Identifier: GPL-2.0-only #include +#include + #include #include "efistub.h" diff --git a/drivers/firmware/efi/libstub/screen_info.c b/drivers/firmware/efi/libstub/screen_info.c index 4be1c4d1f922..a51ec201ca3c 100644 --- a/drivers/firmware/efi/libstub/screen_info.c +++ b/drivers/firmware/efi/libstub/screen_info.c @@ -1,6 +1,8 @@ // SPDX-License-Identifier: GPL-2.0 #include +#include + #include #include "efistub.h" diff --git a/include/linux/efi.h b/include/linux/efi.h index 571d1a6e1b74..360895a5572c 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -24,10 +24,11 @@ #include #include #include -#include #include +struct screen_info; + #define EFI_SUCCESS0 #define EFI_LOAD_ERROR ( 1 | (1UL << (BITS_PER_LONG-1))) #define EFI_INVALID_PARAMETER ( 2 | (1UL << (BITS_PER_LONG-1))) -- 2.41.0
[PATCH v2 3/4] sysfb: Do not include from sysfb header
The header file does not need anything from
. Declare struct screen_info and remove
the include statements.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Sui Jingfeng
Cc: Ard Biesheuvel
Cc: Hans de Goede
Cc: Javier Martinez Canillas
---
include/linux/sysfb.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index c1ef5fc60a3c..19cb803dd5ec 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -9,7 +9,8 @@
#include
#include
-#include
+
+struct screen_info;
enum {
M_I17, /* 17-Inch iMac */
--
2.41.0
Re: [PATCH] drm/i915: Remove some dead "code"
On 05/07/2023 13:08, Jani Nikula wrote:
On Wed, 05 Jul 2023, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 2caffbf11762 ("drm/i915: Revoke mmaps and prevent access to fence
registers across reset") removed the temporary implementation of a reset
under stop machine but forgot to remove this one commented out define.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Jani Nikula
Thanks, pushed!
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gt/intel_reset.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 6916eba3bd33..cdbc08dad7ae 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -35,9 +35,6 @@
#define RESET_MAX_RETRIES 3
-/* XXX How to handle concurrent GGTT updates using tiling registers? */
-#define RESET_UNDER_STOP_MACHINE 0
-
static void client_mark_guilty(struct i915_gem_context *ctx, bool banned)
{
struct drm_i915_file_private *file_priv = ctx->file_priv;
[PULL] drm-misc-next-fixes
Hi Dave and Daniel, here's the weekly PR for drm-misc-next-fixes. Best regards Thomas drm-misc-next-fixes-2023-07-06: Short summary of fixes pull: * panel: Fix mode on Starry-ili9882t The following changes since commit 861c249cd782cb9f2d5a881bbb32e8da7f0c1192: arch/sparc: Add module license and description for fbdev helpers (2023-06-29 13:30:02 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2023-07-06 for you to fetch changes up to 59bba51ec2a50e3dc5c3ee80f0a23207346303ff: drm/panel: Fine tune Starry-ili9882t panel HFP and HBP (2023-06-29 17:35:34 -0700) Short summary of fixes pull: * panel: Fix mode on Starry-ili9882t Cong Yang (1): drm/panel: Fine tune Starry-ili9882t panel HFP and HBP drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Re: [PATCH] drm/ast: Fix default resolution when no monitor is connected on DP
On 06/07/2023 12:26, Thomas Zimmermann wrote:
Hi
Am 06.07.23 um 11:16 schrieb Jocelyn Falempe:
On 04/07/2023 18:45, Jocelyn Falempe wrote:
On 04/07/2023 16:54, Jani Nikula wrote:
On Fri, 23 Jun 2023, Jocelyn Falempe wrote:
Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
EDID on DP")
The default resolution is now 640x480 when no monitor is connected.
But Aspeed graphics is mostly used in servers, where no monitor
is attached. This also affects the "remote" resolution to 640x480,
which is
inconvenient, and breaks the anaconda installer.
So when no EDID is present, set 1024x768 as preferred resolution.
This conflates "monitor connected" and "EDID present", which are not
necessarily the same thing.
The fallback in drm_helper_probe_single_connector_modes() is for no
modes, but connector status is connected or unknown.
When debugging the issue, I found it surprising that the status is
"connected" when nothing is plugged in the DP port.
You could add a connector ->detect callback that returns disconnected
when there's no display, and the problem should go away. If there's no
->detect callback, it'll default to connected.
ok, I'll try that. I don't know how the hardware detect something is
connected, but looking at the dp code, maybe checking
"AST_IO_CRTC_PORT,0xDC, ASTDP_LINK_SUCCESS" would be good enough.
I've tested this approach, and it works. But on the server I'm
testing, there are VGA and DP output. I think on a server that has
only one DP output, if no monitor is connected, then no modes will be
reported to userspace, and the remote BMC may not work ?
You could out-comment the VGA code in the ast driver for testing.
Oh, Thanks for the idea, I will try that.
--
Jocelyn
Best regards
Thomas
Also I don't have physical access to the server, so I only tested when
no monitor is plugged.
I will send shortly a v2 with this change, so others can help me test
this case.
Best regards,
Re: [PATCH v2 2/4] fbdev/sm712fb: Do not include
On Thu, Jul 6, 2023, at 12:42, Thomas Zimmermann wrote: > Sm712fb's dependency on is artificial in that > it only uses struct screen_info for its internals. Replace the use of > struct screen_info with a custom data structure and remove the include > of . > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Javier Martinez Canillas > Cc: Sudip Mukherjee > Cc: Teddy Wang > Cc: Helge Deller Reviewed-by: Arnd Bergmann
Re: [PATCH v2 1/4] efi: Do not include from EFI header
On Thu, Jul 6, 2023, at 12:42, Thomas Zimmermann wrote: > The header file does not need anything from > . Declare struct screen_info and remove > the include statements. Update a number of source files that > require struct screen_info's definition. > > v2: > * update loongarch (Jingfeng) > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Javier Martinez Canillas > Reviewed-by: Sui Jingfeng > Cc: Ard Biesheuvel > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon Reviewed-by: Arnd Bergmann
Re: [PATCH v2 3/4] sysfb: Do not include from sysfb header
On Thu, Jul 6, 2023, at 12:42, Thomas Zimmermann wrote: > The header file does not need anything from > . Declare struct screen_info and remove > the include statements. > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Javier Martinez Canillas > Reviewed-by: Sui Jingfeng > Cc: Ard Biesheuvel > Cc: Hans de Goede > Cc: Javier Martinez Canillas Reviewed-by: Arnd Bergmann
Re: [PATCH] drm/mediatek: Fix potential memory leak if vmap() fail
On 26/06/2023 20:58, Sui Jingfeng wrote:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index a25b28d3ee90..9f364df52478 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -247,7 +247,11 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj,
struct iosys_map *map)
mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
-
+ if (!mtk_gem->kvaddr) {
+ kfree(sgt);
+ kfree(mtk_gem->pages);
+ return -ENOMEM;
+ }
Reviewed-by: Matthias Brugger
out:
kfree(sgt);
iosys_map_set_vaddr(map, mtk_gem->kvaddr);
Re: [PATCH] drm/mediatek: Fix potential memory leak if vmap() fail
On 26/06/2023 20:58, Sui Jingfeng wrote: Also return -ENOMEM if such a failure happens, the implement should take responsibility for the error handling. Reviewed-by: Alexandre Mergnat -- Regards, Alexandre
[PATCH v4 1/9] drm/mediatek: dp: Cache EDID for eDP panel
Since eDP panels are not removable it is safe to cache the EDID:
this will avoid a relatively long read transaction at every PM
resume that is unnecessary only in the "special" case of eDP,
hence speeding it up a little, as from now on, as resume operation,
we will perform only link training.
Signed-off-by: AngeloGioacchino Del Regno
Reviewed-by: Matthias Brugger
Tested-by: Chen-Yu Tsai
---
drivers/gpu/drm/mediatek/mtk_dp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 64eee77452c0..fdf5b7686884 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -118,6 +118,7 @@ struct mtk_dp {
const struct mtk_dp_data *data;
struct mtk_dp_info info;
struct mtk_dp_train_info train_info;
+ struct edid *edid;
struct platform_device *phy_dev;
struct phy *phy;
@@ -1993,7 +1994,11 @@ static struct edid *mtk_dp_get_edid(struct drm_bridge
*bridge,
usleep_range(2000, 5000);
}
- new_edid = drm_get_edid(connector, &mtk_dp->aux.ddc);
+ /* eDP panels aren't removable, so we can return a cached EDID. */
+ if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP && mtk_dp->edid)
+ new_edid = drm_edid_duplicate(mtk_dp->edid);
+ else
+ new_edid = drm_get_edid(connector, &mtk_dp->aux.ddc);
/*
* Parse capability here to let atomic_get_input_bus_fmts and
@@ -2022,6 +2027,10 @@ static struct edid *mtk_dp_get_edid(struct drm_bridge
*bridge,
drm_atomic_bridge_chain_post_disable(bridge,
connector->state->state);
}
+ /* If this is an eDP panel and the read EDID is good, cache it for
later */
+ if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP && !mtk_dp->edid &&
new_edid)
+ mtk_dp->edid = drm_edid_duplicate(new_edid);
+
return new_edid;
}
--
2.40.1
[PATCH v4 0/9] MediaTek DisplayPort: support eDP and aux-bus
Changes in v4:
- Set data lanes to idle to prevent stalls if bootloader didn't
properly close the eDP port
- Now using the .done_probing() callback for AUX bus to prevent
probe deferral loops in case the panel-edp driver is a module
as previously seen with another bridge driver (ANX7625) on
some other SoCs (MT8192 and others)
- Rebased over next-20230706
- Dropped Chen-Yu's T-b tag on last patch as some logic changed
(before, I wasn't using the .done_probing() callback).
Changes in v3:
- Added DPTX AUX block initialization before trying to communicate
to stop relying on the bootloader keeping it initialized before
booting Linux.
- Fixed commit description for patch [09/09] and removed commented
out code (that slipped from dev phase.. sorry!).
This series adds "real" support for eDP in the mtk-dp DisplayPort driver.
Explaining the "real":
Before this change, the DisplayPort driver did support eDP to some
extent, but it was treating it entirely like a regular DP interface
which is partially fine, after all, embedded DisplayPort *is* actually
DisplayPort, but there might be some differences to account for... and
this is for both small performance improvements and, more importantly,
for correct functionality in some systems.
Functionality first:
One of the common differences found in various boards implementing eDP
and machines using an eDP panel is that many times the HPD line is not
connected. This *must* be accounted for: at startup, this specific IP
will raise a HPD interrupt (which should maybe be ignored... as it does
not appear to be a "real" event...) that will make the eDP panel to be
detected and to actually work but, after a suspend-resume cycle, there
will be no HPD interrupt (as there's no HPD line in my case!) producing
a functionality issue - specifically, the DP Link Training fails because
the panel doesn't get powered up, then it stays black and won't work
until rebooting the machine (or removing and reinserting the module I
think, but I haven't tried that).
Now for.. both:
eDP panels are *e*DP because they are *not* removable (in the sense that
you can't unplug the cable without disassembling the machine, in which
case, the machine shall be powered down..!): this (correct) assumption
makes us able to solve some issues and to also gain a little performance
during PM operations.
What was done here is:
- Caching the EDID if the panel is eDP: we're always going to read the
same data everytime, so we can just cache that (as it's small enough)
shortening PM resume times for the eDP driver instance;
- Always return connector_status_connected if it's eDP: non-removable
means connector_status_disconnected can't happen during runtime...
this also saves us some time and even power, as we won't have to
perform yet another power cycle of the HW;
- Added aux-bus support!
This makes us able to rely on panel autodetection from the EDID,
avoiding to add more and more panel timings to panel-edp and, even
better, allowing to use one panel node in devicetrees for multiple
variants of the same machine since, at that point, it's not important
to "preventively know" what panel we have (eh, it's autodetected...!).
This was tested on a MT8195 Cherry Tomato Chromebook (panel-edp on aux-bus)
P.S.: For your own testing commodity, here's a reference devicetree:
&edp_tx {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&edptx_pins_default>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
edp_in: endpoint {
remote-endpoint = <&dp_intf0_out>;
};
};
port@1 {
reg = <1>;
edp_out: endpoint {
data-lanes = <0 1 2 3>;
remote-endpoint = <&panel_in>;
};
};
};
aux-bus {
panel: panel {
compatible = "edp-panel";
power-supply = <&pp3300_disp_x>;
backlight = <&backlight_lcd0>;
port {
panel_in: endpoint {
remote-endpoint = <&edp_out>;
};
};
};
};
};
AngeloGioacchino Del Regno (9):
drm/mediatek: dp: Cache EDID for eDP panel
drm/mediatek: dp: Move AUX and panel poweron/off sequence to function
drm/mediatek: dp: Always return connected status for eDP i
[PATCH v4 3/9] drm/mediatek: dp: Always return connected status for eDP in .detect()
If this is an eDP panel it's not removable, hence it's always connected: as a shortcut, always return connector_status_connected in the .detect() callback for eDP connector, avoiding a poweron, a check for sink count and a poweroff. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai --- drivers/gpu/drm/mediatek/mtk_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c index 8f7d4af7076f..5b35a2e23896 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -1957,6 +1957,9 @@ static enum drm_connector_status mtk_dp_bdg_detect(struct drm_bridge *bridge) bool enabled = mtk_dp->enabled; u8 sink_count = 0; + if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP) + return connector_status_connected; + if (!mtk_dp->train_info.cable_plugged_in) return ret; -- 2.40.1
[PATCH v4 5/9] drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()
Change logging from drm_{err,info}() to dev_{err,info}() in functions
mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be
essential to avoid getting NULL pointer kernel panics if any kind
of error happens during AUX transfers happening before the bridge
is attached.
This may potentially start happening in a later commit implementing
aux-bus support, as AUX transfers will be triggered from the panel
driver (for EDID) before the mtk-dp bridge gets attached, and it's
done in preparation for the same.
Signed-off-by: AngeloGioacchino Del Regno
Tested-by: Chen-Yu Tsai
---
drivers/gpu/drm/mediatek/mtk_dp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 35f3549d258e..274119356dfb 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -848,7 +848,7 @@ static int mtk_dp_aux_do_transfer(struct mtk_dp *mtk_dp,
bool is_read, u8 cmd,
u32 phy_status = mtk_dp_read(mtk_dp, MTK_DP_AUX_P0_3628) &
AUX_RX_PHY_STATE_AUX_TX_P0_MASK;
if (phy_status != AUX_RX_PHY_STATE_AUX_TX_P0_RX_IDLE) {
- drm_err(mtk_dp->drm_dev,
+ dev_err(mtk_dp->dev,
"AUX Rx Aux hang, need SW reset\n");
return -EIO;
}
@@ -2061,7 +2061,7 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux
*mtk_aux,
is_read = true;
break;
default:
- drm_err(mtk_aux->drm_dev, "invalid aux cmd = %d\n",
+ dev_err(mtk_dp->dev, "invalid aux cmd = %d\n",
msg->request);
ret = -EINVAL;
goto err;
@@ -2077,7 +2077,7 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux
*mtk_aux,
to_access, &msg->reply);
if (ret) {
- drm_info(mtk_dp->drm_dev,
+ dev_info(mtk_dp->dev,
"Failed to do AUX transfer: %d\n", ret);
goto err;
}
--
2.40.1
[PATCH v4 8/9] drm/mediatek: dp: Move AUX_P0 setting to mtk_dp_initialize_aux_settings()
Move the register write to MTK_DP_AUX_P0_3690 to set the AUX reply mode to function mtk_dp_initialize_aux_settings(), as this is effectively part of the DPTX AUX setup sequence. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai --- drivers/gpu/drm/mediatek/mtk_dp.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c index 6bc620aded45..2ad836fbb7c4 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -1011,6 +1011,11 @@ static void mtk_dp_initialize_aux_settings(struct mtk_dp *mtk_dp) mtk_dp_update_bits(mtk_dp, MTK_DP_AUX_P0_37C8, MTK_ATOP_EN_AUX_TX_P0, MTK_ATOP_EN_AUX_TX_P0); + + /* Set complete reply mode for AUX */ + mtk_dp_update_bits(mtk_dp, MTK_DP_AUX_P0_3690, + RX_REPLY_COMPLETE_MODE_AUX_TX_P0, + RX_REPLY_COMPLETE_MODE_AUX_TX_P0); } static void mtk_dp_initialize_digital_settings(struct mtk_dp *mtk_dp) @@ -1823,10 +1828,6 @@ static void mtk_dp_init_port(struct mtk_dp *mtk_dp) mtk_dp_initialize_settings(mtk_dp); mtk_dp_initialize_aux_settings(mtk_dp); mtk_dp_initialize_digital_settings(mtk_dp); - - mtk_dp_update_bits(mtk_dp, MTK_DP_AUX_P0_3690, - RX_REPLY_COMPLETE_MODE_AUX_TX_P0, - RX_REPLY_COMPLETE_MODE_AUX_TX_P0); mtk_dp_initialize_hpd_detect_settings(mtk_dp); mtk_dp_digital_sw_reset(mtk_dp); -- 2.40.1
[PATCH v4 4/9] drm/mediatek: dp: Always set cable_plugged_in at resume for eDP panel
eDP panels are not removable: at PM resume, the cable will obviously still be plugged in. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai --- drivers/gpu/drm/mediatek/mtk_dp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c index 5b35a2e23896..35f3549d258e 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -2606,6 +2606,9 @@ static int mtk_dp_resume(struct device *dev) mtk_dp_hwirq_enable(mtk_dp, true); mtk_dp_power_enable(mtk_dp); + if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP) + mtk_dp->train_info.cable_plugged_in = true; + return 0; } #endif -- 2.40.1
[PATCH v4 6/9] drm/mediatek: dp: Enable event interrupt only when bridge attached
In preparation for implementing support for aux-bus in this driver,
add a IRQ_NOAUTOEN flag to the event interrupt that we request at
probe time and manage the enablement of the ISR at bridge_attach
and detach time.
When aux-bus will be implemented, enabling the interrupt before
attaching the bridge will create an event storm and hang the kernel
during boot.
In any case, the interrupt handler anyway requires resources that
are initialized by mtk_dp_bridge_attach(), so it cannot do anything
meaningful without... and even crash, but that's not happening in
the current code because the HW remains unpowered until resources
are made available.
Signed-off-by: AngeloGioacchino Del Regno
Tested-by: Chen-Yu Tsai
---
drivers/gpu/drm/mediatek/mtk_dp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 274119356dfb..eebcb32e67ee 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -100,6 +100,7 @@ struct mtk_dp_efuse_fmt {
struct mtk_dp {
bool enabled;
bool need_debounce;
+ int irq;
u8 max_lanes;
u8 max_linkrate;
u8 rx_cap[DP_RECEIVER_CAP_SIZE];
@@ -2147,6 +2148,8 @@ static int mtk_dp_bridge_attach(struct drm_bridge *bridge,
mtk_dp->drm_dev = bridge->dev;
+ irq_clear_status_flags(mtk_dp->irq, IRQ_NOAUTOEN);
+ enable_irq(mtk_dp->irq);
mtk_dp_hwirq_enable(mtk_dp, true);
return 0;
@@ -2163,6 +2166,7 @@ static void mtk_dp_bridge_detach(struct drm_bridge
*bridge)
struct mtk_dp *mtk_dp = mtk_dp_from_bridge(bridge);
mtk_dp_hwirq_enable(mtk_dp, false);
+ disable_irq(mtk_dp->irq);
mtk_dp->drm_dev = NULL;
mtk_dp_poweroff(mtk_dp);
drm_dp_aux_unregister(&mtk_dp->aux);
@@ -2481,7 +2485,7 @@ static int mtk_dp_probe(struct platform_device *pdev)
{
struct mtk_dp *mtk_dp;
struct device *dev = &pdev->dev;
- int ret, irq_num;
+ int ret;
mtk_dp = devm_kzalloc(dev, sizeof(*mtk_dp), GFP_KERNEL);
if (!mtk_dp)
@@ -2490,9 +2494,9 @@ static int mtk_dp_probe(struct platform_device *pdev)
mtk_dp->dev = dev;
mtk_dp->data = (struct mtk_dp_data *)of_device_get_match_data(dev);
- irq_num = platform_get_irq(pdev, 0);
- if (irq_num < 0)
- return dev_err_probe(dev, irq_num,
+ mtk_dp->irq = platform_get_irq(pdev, 0);
+ if (mtk_dp->irq < 0)
+ return dev_err_probe(dev, mtk_dp->irq,
"failed to request dp irq resource\n");
mtk_dp->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
@@ -2513,7 +2517,8 @@ static int mtk_dp_probe(struct platform_device *pdev)
spin_lock_init(&mtk_dp->irq_thread_lock);
- ret = devm_request_threaded_irq(dev, irq_num, mtk_dp_hpd_event,
+ irq_set_status_flags(mtk_dp->irq, IRQ_NOAUTOEN);
+ ret = devm_request_threaded_irq(dev, mtk_dp->irq, mtk_dp_hpd_event,
mtk_dp_hpd_event_thread,
IRQ_TYPE_LEVEL_HIGH, dev_name(dev),
mtk_dp);
--
2.40.1
[PATCH v4 7/9] drm/mediatek: dp: Use devm variant of drm_bridge_add()
In preparation for adding support for aux-bus, which will add a code path that may fail after the drm_bridge_add() call, change that to devm_drm_bridge_add() to simplify failure paths later. Signed-off-by: AngeloGioacchino Del Regno Tested-by: Chen-Yu Tsai --- drivers/gpu/drm/mediatek/mtk_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c index eebcb32e67ee..6bc620aded45 100644 --- a/drivers/gpu/drm/mediatek/mtk_dp.c +++ b/drivers/gpu/drm/mediatek/mtk_dp.c @@ -2564,7 +2564,7 @@ static int mtk_dp_probe(struct platform_device *pdev) DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID | DRM_BRIDGE_OP_HPD; mtk_dp->bridge.type = mtk_dp->data->bridge_type; - drm_bridge_add(&mtk_dp->bridge); + devm_drm_bridge_add(dev, &mtk_dp->bridge); mtk_dp->need_debounce = true; timer_setup(&mtk_dp->debounce_timer, mtk_dp_debounce_timer, 0); -- 2.40.1
[PATCH v4 2/9] drm/mediatek: dp: Move AUX and panel poweron/off sequence to function
Everytime we run bridge detection and/or EDID read we run a poweron
and poweroff sequence for both the AUX and the panel; moreover, this
is also done when enabling the bridge in the .atomic_enable() callback.
Move this power on/off sequence to a new mtk_dp_aux_panel_poweron()
function as to commonize it.
Note that, before this commit, in mtk_dp_bridge_atomic_enable() only
the AUX was getting powered on but the panel was left powered off if
the DP cable wasn't plugged in while now we unconditionally send a D0
request and this is done for two reasons:
- First, whether this request fails or not, it takes the same time
and anyway the DP hardware won't produce any error (or, if it
does, it's ignorable because it won't block further commands)
- Second, training the link between a sleeping/standby/unpowered
display makes little sense.
Signed-off-by: AngeloGioacchino Del Regno
Tested-by: Chen-Yu Tsai
---
drivers/gpu/drm/mediatek/mtk_dp.c | 76 ---
1 file changed, 30 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index fdf5b7686884..8f7d4af7076f 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -1252,6 +1252,29 @@ static void mtk_dp_audio_mute(struct mtk_dp *mtk_dp,
bool mute)
val[2], AU_TS_CFG_DP_ENC0_P0_MASK);
}
+static void mtk_dp_aux_panel_poweron(struct mtk_dp *mtk_dp, bool pwron)
+{
+ if (pwron) {
+ /* power on aux */
+ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
+ DP_PWR_STATE_BANDGAP_TPLL_LANE,
+ DP_PWR_STATE_MASK);
+
+ /* power on panel */
+ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
+ usleep_range(2000, 5000);
+ } else {
+ /* power off panel */
+ drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
+ usleep_range(2000, 3000);
+
+ /* power off aux */
+ mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
+ DP_PWR_STATE_BANDGAP_TPLL,
+ DP_PWR_STATE_MASK);
+ }
+}
+
static void mtk_dp_power_enable(struct mtk_dp *mtk_dp)
{
mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_RESET_AND_PROBE,
@@ -1937,16 +1960,9 @@ static enum drm_connector_status
mtk_dp_bdg_detect(struct drm_bridge *bridge)
if (!mtk_dp->train_info.cable_plugged_in)
return ret;
- if (!enabled) {
- /* power on aux */
- mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
- DP_PWR_STATE_BANDGAP_TPLL_LANE,
- DP_PWR_STATE_MASK);
+ if (!enabled)
+ mtk_dp_aux_panel_poweron(mtk_dp, true);
- /* power on panel */
- drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
- usleep_range(2000, 5000);
- }
/*
* Some dongles still source HPD when they do not connect to any
* sink device. To avoid this, we need to read the sink count
@@ -1958,16 +1974,8 @@ static enum drm_connector_status
mtk_dp_bdg_detect(struct drm_bridge *bridge)
if (DP_GET_SINK_COUNT(sink_count))
ret = connector_status_connected;
- if (!enabled) {
- /* power off panel */
- drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
- usleep_range(2000, 3000);
-
- /* power off aux */
- mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
- DP_PWR_STATE_BANDGAP_TPLL,
- DP_PWR_STATE_MASK);
- }
+ if (!enabled)
+ mtk_dp_aux_panel_poweron(mtk_dp, false);
return ret;
}
@@ -1983,15 +1991,7 @@ static struct edid *mtk_dp_get_edid(struct drm_bridge
*bridge,
if (!enabled) {
drm_atomic_bridge_chain_pre_enable(bridge,
connector->state->state);
-
- /* power on aux */
- mtk_dp_update_bits(mtk_dp, MTK_DP_TOP_PWR_STATE,
- DP_PWR_STATE_BANDGAP_TPLL_LANE,
- DP_PWR_STATE_MASK);
-
- /* power on panel */
- drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D0);
- usleep_range(2000, 5000);
+ mtk_dp_aux_panel_poweron(mtk_dp, true);
}
/* eDP panels aren't removable, so we can return a cached EDID. */
@@ -2015,15 +2015,7 @@ static struct edid *mtk_dp_get_edid(struct drm_bridge
*bridge,
}
if (!enabled) {
- /* power off panel */
- drm_dp_dpcd_writeb(&mtk_dp->aux, DP_SET_POWER, DP_SET_POWER_D3);
- usleep_range(2000, 3000);
-
-
[PATCH v4 9/9] drm/mediatek: dp: Add support for embedded DisplayPort aux-bus
For the eDP case we can support using aux-bus on MediaTek DP: this
gives us the possibility to declare our panel as generic "panel-edp"
which will automatically configure the timings and available modes
via the EDID that we read from it.
To do this, move the panel parsing at the end of the probe function
so that the hardware is initialized beforehand and also initialize
the DPTX AUX block and power both on as, when we populate the
aux-bus, the panel driver will trigger an EDID read to perform
panel detection.
Last but not least, since now the AUX transfers can happen in the
separated aux-bus, it was necessary to add an exclusion for the
cable_plugged_in check in `mtk_dp_aux_transfer()` and the easiest
way to do this is to simply ignore checking that when the bridge
type is eDP.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_dp.c | 72 ++-
1 file changed, 62 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c
b/drivers/gpu/drm/mediatek/mtk_dp.c
index 2ad836fbb7c4..16109d5ca5ae 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -4,6 +4,7 @@
* Copyright (c) 2022 BayLibre
*/
+#include
#include
#include
#include
@@ -2042,7 +2043,8 @@ static ssize_t mtk_dp_aux_transfer(struct drm_dp_aux
*mtk_aux,
mtk_dp = container_of(mtk_aux, struct mtk_dp, aux);
- if (!mtk_dp->train_info.cable_plugged_in) {
+ if (mtk_dp->bridge.type != DRM_MODE_CONNECTOR_eDP &&
+ !mtk_dp->train_info.cable_plugged_in) {
ret = -EAGAIN;
goto err;
}
@@ -2153,6 +2155,11 @@ static int mtk_dp_bridge_attach(struct drm_bridge
*bridge,
enable_irq(mtk_dp->irq);
mtk_dp_hwirq_enable(mtk_dp, true);
+ if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP) {
+ mtk_dp->train_info.cable_plugged_in = true;
+ drm_helper_hpd_irq_event(mtk_dp->drm_dev);
+ }
+
return 0;
err_bridge_attach:
@@ -2482,6 +2489,25 @@ static int mtk_dp_register_audio_driver(struct device
*dev)
return PTR_ERR_OR_ZERO(mtk_dp->audio_pdev);
}
+static int mtk_dp_edp_link_panel(struct drm_dp_aux *mtk_aux)
+{
+ struct mtk_dp *mtk_dp = container_of(mtk_aux, struct mtk_dp, aux);
+ struct device *dev = mtk_aux->dev;
+ struct drm_bridge *panel_aux_bridge;
+
+ panel_aux_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+
+ /* Power off the DP: either detection is done, or no panel present */
+ mtk_dp_aux_panel_poweron(mtk_dp, false);
+ mtk_dp_power_disable(mtk_dp);
+
+ if (IS_ERR(panel_aux_bridge))
+ return PTR_ERR(panel_aux_bridge);
+
+ mtk_dp->next_bridge = panel_aux_bridge;
+ return 0;
+}
+
static int mtk_dp_probe(struct platform_device *pdev)
{
struct mtk_dp *mtk_dp;
@@ -2500,21 +2526,14 @@ static int mtk_dp_probe(struct platform_device *pdev)
return dev_err_probe(dev, mtk_dp->irq,
"failed to request dp irq resource\n");
- mtk_dp->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
- if (IS_ERR(mtk_dp->next_bridge) &&
- PTR_ERR(mtk_dp->next_bridge) == -ENODEV)
- mtk_dp->next_bridge = NULL;
- else if (IS_ERR(mtk_dp->next_bridge))
- return dev_err_probe(dev, PTR_ERR(mtk_dp->next_bridge),
-"Failed to get bridge\n");
-
ret = mtk_dp_dt_parse(mtk_dp, pdev);
if (ret)
return dev_err_probe(dev, ret, "Failed to parse dt\n");
- drm_dp_aux_init(&mtk_dp->aux);
mtk_dp->aux.name = "aux_mtk_dp";
+ mtk_dp->aux.dev = dev;
mtk_dp->aux.transfer = mtk_dp_aux_transfer;
+ drm_dp_aux_init(&mtk_dp->aux);
spin_lock_init(&mtk_dp->irq_thread_lock);
@@ -2570,6 +2589,39 @@ static int mtk_dp_probe(struct platform_device *pdev)
mtk_dp->need_debounce = true;
timer_setup(&mtk_dp->debounce_timer, mtk_dp_debounce_timer, 0);
+ if (mtk_dp->bridge.type == DRM_MODE_CONNECTOR_eDP) {
+ /*
+* Set the data lanes to idle in case the bootloader didn't
+* properly close the eDP port to avoid stalls and then
+* reinitialize, reset and power on the AUX block.
+*/
+ mtk_dp_set_idle_pattern(mtk_dp, true);
+ mtk_dp_initialize_aux_settings(mtk_dp);
+ mtk_dp_power_enable(mtk_dp);
+
+ /*
+* Power on the panel to allow reading the EDID from aux-bus:
+* please note that it is necessary to call power off in the
+* .done_probing() callback (mtk_dp_edp_link_panel), as only
+* there we can safely assume that we finished reading EDID.
+*/
+ mtk_dp_aux_panel_poweron(mtk_dp, true);
+
+
[PATCH v2] dma-buf: fix an error pointer vs NULL bug
Smatch detected potential error pointer dereference.
drivers/gpu/drm/drm_syncobj.c:888 drm_syncobj_transfer_to_timeline()
error: 'fence' dereferencing possible ERR_PTR()
The error pointer comes from dma_fence_allocate_private_stub(). One
caller expected error pointers and one expected NULL pointers. Change
it to return NULL and update the caller which expected error pointers,
drm_syncobj_assign_null_handle(), to check for NULL instead.
Fixes: f781f661e8c9 ("dma-buf: keep the signaling time of merged fences v3")
Signed-off-by: Dan Carpenter
---
v2: Fix it in dma_fence_allocate_private_stub() instead of
__dma_fence_unwrap_merge().
drivers/dma-buf/dma-fence.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index ad076f208760..8aa8f8cb7071 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -160,7 +160,7 @@ struct dma_fence *dma_fence_allocate_private_stub(ktime_t
timestamp)
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (fence == NULL)
- return ERR_PTR(-ENOMEM);
+ return NULL;
dma_fence_init(fence,
&dma_fence_stub_ops,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 04589a35eb09..e592c5da70ce 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -355,8 +355,8 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
{
struct dma_fence *fence = dma_fence_allocate_private_stub(ktime_get());
- if (IS_ERR(fence))
- return PTR_ERR(fence);
+ if (!fence)
+ return -ENOMEM;
drm_syncobj_replace_fence(syncobj, fence);
dma_fence_put(fence);
--
2.39.2
Re: [PATCH] dma-buf: fix an error pointer vs NULL bug
On Thu, Jul 06, 2023 at 08:21:35AM +0200, Christian König wrote: > Am 06.07.23 um 07:52 schrieb Dan Carpenter: > > The __dma_fence_unwrap_merge() function is supposed to return NULL on > > error. But the dma_fence_allocate_private_stub() returns error pointers > > so check for that and covert the error pointers to NULL returns. > > Otherwise, the callers do not expect error pointers and it leads to an > > Oops. > > Oh, good catch. > > But I think we should probably change dma_fence_allocate_private_stub() > instead, that this function returns an ERR_PTR doesn't seem to make to much > sense. Sure, I've sent v2. regards, dan carpenter
Re: [PATCH 04/10] drm/tegra: Set fbdev flags
Hi Am 05.07.23 um 11:34 schrieb Javier Martinez Canillas: Thomas Zimmermann writes: [...] + info->flags |= FBINFO_VIRTFB; I see that all fbdev drivers just do: info->flags = FBINFO_FLAG_DEFAULT | FBINFO_VIRTFB Guess you are doing in two assignments to be consistent with drm_fbdev_dma.c ? I was just curious about the rationale for setting the flags in two steps. The _DEFAULT flag is really just a zero. And the other flags describe different aspects of the framebuffer. I think it makes sense to set the flags together with the respective state. For example, _VIRTFB is set next to ->screen_buffer, because they belong together. Yes, that makes sense. _VIRTFB is currently only used in defio code at https://elixir.bootlin.com/linux/latest/source/drivers/video/fbdev/core/fb_defio.c#L232 I think the fbdev I/O helpers should also test this flag after all drivers have been annotated correctly. For example, fb_io_read() would WARN_ONCE if the _VIRTFB flag has been set; and fb_sys_read() would warn if it hasn't been set. For the read helpers, it also makes sense to WARN_ONCE if the _READS_FAST flag has not been set. Agreed. Maybe you could add those warn (or at least info or debug?) even if not all drivers have been annotated correctly. That way people can be aware that is missing and fix if there are remaining drivers. Yes, we could do that. I want to go through drivers first and fix the low-hanging fruits. Some of the old fbdev drivers use either DMA or I/O memory. They would only be fix-worthy if someone complains. Best regards Thomas Best regards Thomas -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH] drm/mediatek: Fix potential memory leak if vmap() fail
Hi, Thanks a lot!
On 2023/7/6 19:39, Matthias Brugger wrote:
On 26/06/2023 20:58, Sui Jingfeng wrote:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index a25b28d3ee90..9f364df52478 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -247,7 +247,11 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object
*obj, struct iosys_map *map)
mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
-
+ if (!mtk_gem->kvaddr) {
+ kfree(sgt);
+ kfree(mtk_gem->pages);
+ return -ENOMEM;
+ }
Reviewed-by: Matthias Brugger
out:
kfree(sgt);
iosys_map_set_vaddr(map, mtk_gem->kvaddr);
Re: [PATCH] drm/mediatek: Fix potential memory leak if vmap() fail
Hi, thanks a lot! On 2023/7/6 20:13, Alexandre Mergnat wrote: On 26/06/2023 20:58, Sui Jingfeng wrote: Also return -ENOMEM if such a failure happens, the implement should take responsibility for the error handling. Reviewed-by: Alexandre Mergnat
Re: [PATCH] drm/mediatek: Fix potential memory leak if vmap() fail
Il 26/06/23 20:58, Sui Jingfeng ha scritto:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
This commit needs a Fixes tag. Please add the relevant one and resend.
Thanks,
Angelo
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index a25b28d3ee90..9f364df52478 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -247,7 +247,11 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj,
struct iosys_map *map)
mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
-
+ if (!mtk_gem->kvaddr) {
+ kfree(sgt);
+ kfree(mtk_gem->pages);
+ return -ENOMEM;
+ }
out:
kfree(sgt);
iosys_map_set_vaddr(map, mtk_gem->kvaddr);
[PATCH v2 00/11] drm: Improve fbdev emulation for DMA-able framebuffers
Add fbdev helpers for framebuffers in DMA-able memory and update fbdev emulation in the respective DRM drivers. DMA memory used to handled as system memory. Improve this and prepare for possible future changes. Patch 1 adds initializer macros for struct fb_ops and a Kconfig token for framebuffers in DMA memory. Patches 2 to 4 update fbdev-dma and tegra. No functional changes are expected as both used system memory before. Patches 5 and 6 update exynos to use DMA helpers. Exynos incorrectly used fbdev's I/O-memory helpers. Fix this. Patches 7 to 9 update omapdrm to use DMA helpers. Patch 7 first reworks the driver's mmap to current best practices. This also makes it suitable for use with fbdev, which patches 8 and 9 implement. Patchies 10 removes some fbdev macros for system memory that are now unused; patch 11 fixes some comments. The patchset would ideally go through drm-misc-next. Future patches can build upon it and update fbdev drivers in similar ways. v2: * fix omap mmap flags * drop FBINFO_DEFAULT from patches * minor cleanups Thomas Zimmermann (11): fbdev: Add fb_ops init macros for framebuffers in DMA-able memory drm/fbdev-dma: Use fbdev DMA helpers drm/tegra: Use fbdev DMA helpers drm/tegra: Set fbdev FBINFO_VIRTFB flag drm/exynos: Use fbdev DMA helpers drm/exynos: Set fbdev FBINFO_VIRTFB flag drm/omapdrm: Set VM flags in GEM-object mmap function drm/omapdrm: Use GEM mmap for fbdev emulation drm/omapdrm: Set fbdev FBINFO_VIRTFB flag fbdev: Remove FB_DEFAULT_SYS_OPS fbdev: Harmonize some comments in drivers/gpu/drm/Kconfig | 2 +- drivers/gpu/drm/drm_fbdev_dma.c | 4 ++-- drivers/gpu/drm/exynos/Kconfig| 2 +- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 ++-- drivers/gpu/drm/omapdrm/Kconfig | 2 +- drivers/gpu/drm/omapdrm/omap_drv.c| 12 +- drivers/gpu/drm/omapdrm/omap_fbdev.c | 16 +++-- drivers/gpu/drm/omapdrm/omap_gem.c| 24 +-- drivers/gpu/drm/omapdrm/omap_gem.h| 3 --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 7 +- drivers/gpu/drm/tegra/Kconfig | 2 +- drivers/gpu/drm/tegra/fbdev.c | 5 ++-- drivers/video/fbdev/Kconfig | 8 +++ include/linux/fb.h| 29 ++- 14 files changed, 55 insertions(+), 66 deletions(-) -- 2.41.0
[PATCH v2 01/11] fbdev: Add fb_ops init macros for framebuffers in DMA-able memory
Add initializer macros for struct fb_ops for framebuffers in DMA-able memory areas. Also add a corresponding Kconfig token. As of now, this is equivalent to system framebuffers and mostly useful for labeling drivers correctly. A later patch may add a generic DMA-specific mmap operation. Linux offers a number of dma_mmap_*() helpers for different use cases. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Helge Deller --- drivers/video/fbdev/Kconfig | 8 include/linux/fb.h | 13 + 2 files changed, 21 insertions(+) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index cecf15418632..f14229757311 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -168,6 +168,14 @@ config FB_DEFERRED_IO bool depends on FB +config FB_DMA_HELPERS + bool + depends on FB + select FB_SYS_COPYAREA + select FB_SYS_FILLRECT + select FB_SYS_FOPS + select FB_SYS_IMAGEBLIT + config FB_IO_HELPERS bool depends on FB diff --git a/include/linux/fb.h b/include/linux/fb.h index 1d5c13f34b09..1191a78c5289 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -594,6 +594,19 @@ extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf, __FB_DEFAULT_SYS_OPS_DRAW, \ __FB_DEFAULT_SYS_OPS_MMAP +/* + * Helpers for framebuffers in DMA-able memory + */ + +#define __FB_DEFAULT_DMA_OPS_RDWR \ + .fb_read= fb_sys_read, \ + .fb_write = fb_sys_write + +#define __FB_DEFAULT_DMA_OPS_DRAW \ + .fb_fillrect= sys_fillrect, \ + .fb_copyarea= sys_copyarea, \ + .fb_imageblit = sys_imageblit + /* drivers/video/fbmem.c */ extern int register_framebuffer(struct fb_info *fb_info); extern void unregister_framebuffer(struct fb_info *fb_info); -- 2.41.0
[PATCH v2 02/11] drm/fbdev-dma: Use fbdev DMA helpers
Use fbdev's DMA helpers for fbdev-dma. They are equivalent to the
previously used system-memory helpers, so no functional changes here.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Acked-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig | 2 +-
drivers/gpu/drm/drm_fbdev_dma.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..da3aa0625c36 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -216,7 +216,7 @@ config DRM_TTM_HELPER
config DRM_GEM_DMA_HELPER
tristate
depends on DRM
- select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
+ select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
help
Choose this if you need the GEM DMA helper functions
diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index 8217f1ddc007..040c229a1737 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -62,9 +62,9 @@ static const struct fb_ops drm_fbdev_dma_fb_ops = {
.owner = THIS_MODULE,
.fb_open = drm_fbdev_dma_fb_open,
.fb_release = drm_fbdev_dma_fb_release,
- __FB_DEFAULT_SYS_OPS_RDWR,
+ __FB_DEFAULT_DMA_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
- __FB_DEFAULT_SYS_OPS_DRAW,
+ __FB_DEFAULT_DMA_OPS_DRAW,
.fb_mmap = drm_fbdev_dma_fb_mmap,
.fb_destroy = drm_fbdev_dma_fb_destroy,
};
--
2.41.0
[PATCH v2 03/11] drm/tegra: Use fbdev DMA helpers
Use fbdev's DMA helpers for fbdev emulation. They are equivalent to the
previously used system-memory helpers, so no functional changes here.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Acked-by: Maxime Ripard
Cc: Thierry Reding
Cc: Mikko Perttunen
---
drivers/gpu/drm/tegra/Kconfig | 2 +-
drivers/gpu/drm/tegra/fbdev.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index 498313778175..39452c8480c1 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -12,7 +12,7 @@ config DRM_TEGRA
select DRM_KMS_HELPER
select DRM_MIPI_DSI
select DRM_PANEL
- select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
+ select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
select TEGRA_HOST1X
select INTERCONNECT
select IOMMU_IOVA
diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c
index e74d9be981c7..82577b7c88da 100644
--- a/drivers/gpu/drm/tegra/fbdev.c
+++ b/drivers/gpu/drm/tegra/fbdev.c
@@ -59,9 +59,9 @@ static void tegra_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops tegra_fb_ops = {
.owner = THIS_MODULE,
- __FB_DEFAULT_SYS_OPS_RDWR,
+ __FB_DEFAULT_DMA_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
- __FB_DEFAULT_SYS_OPS_DRAW,
+ __FB_DEFAULT_DMA_OPS_DRAW,
.fb_mmap = tegra_fb_mmap,
.fb_destroy = tegra_fbdev_fb_destroy,
};
--
2.41.0
[PATCH v2 07/11] drm/omapdrm: Set VM flags in GEM-object mmap function
Use the mmap callback in struct drm_gem_object_funcs to set the
VM flags. Replace a number of mmap helpers in omapdrm with their
GEM helper counterparts. Generate DRM's file-operations instance
with GEM's DEFINE_DRM_GEM_FOPS.
The omapdrm driver uses DRM's drm_gem_mmap() helper to prepare
the VMA structure. It then modifies the resulting VMA state in
its own helper omap_gem_mmap_obj(). The patch improves this by
setting up the VMA in the mmap callback in drm_gem_object_funcs,
which is called from within drm_gem_mmap().
Omapdrm's omap_gem_mmap() and omap_gem_mmap() can then be removed
from the driver. A call to drm_gem_mmap() is sufficient for the
mmap operation.
Finally, with the omap functions gone, the drivers file_ops in
omapdriver_fops can be generated with DEFINE_DRM_GEM_FOPS, which
sets DRM's default helpers.
v2:
* detailed commit message (Javier)
* do not set VM_PFNMAP
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Acked-by: Maxime Ripard
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_drv.c| 12 +---
drivers/gpu/drm/omapdrm/omap_gem.c| 24 ++-
drivers/gpu/drm/omapdrm/omap_gem.h| 3 ---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 7 +--
4 files changed, 8 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index e2697fe80e62..afeeb7737552 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -636,17 +636,7 @@ static int dev_open(struct drm_device *dev, struct
drm_file *file)
return 0;
}
-static const struct file_operations omapdriver_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .unlocked_ioctl = drm_ioctl,
- .compat_ioctl = drm_compat_ioctl,
- .release = drm_release,
- .mmap = omap_gem_mmap,
- .poll = drm_poll,
- .read = drm_read,
- .llseek = noop_llseek,
-};
+DEFINE_DRM_GEM_FOPS(omapdriver_fops);
static const struct drm_driver omap_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM |
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index 6b58a5bb7b44..c48fa531ca32 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -524,26 +524,11 @@ static vm_fault_t omap_gem_fault(struct vm_fault *vmf)
return ret;
}
-/** We override mainly to fix up some of the vm mapping flags.. */
-int omap_gem_mmap(struct file *filp, struct vm_area_struct *vma)
-{
- int ret;
-
- ret = drm_gem_mmap(filp, vma);
- if (ret) {
- DBG("mmap failed: %d", ret);
- return ret;
- }
-
- return omap_gem_mmap_obj(vma->vm_private_data, vma);
-}
-
-int omap_gem_mmap_obj(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
+static int omap_gem_object_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
{
struct omap_gem_object *omap_obj = to_omap_bo(obj);
- vm_flags_mod(vma, VM_MIXEDMAP, VM_PFNMAP);
+ vm_flags_set(vma, VM_DONTEXPAND | VM_DONTDUMP | VM_IO | VM_MIXEDMAP);
if (omap_obj->flags & OMAP_BO_WC) {
vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
@@ -563,12 +548,14 @@ int omap_gem_mmap_obj(struct drm_gem_object *obj,
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
- vma->vm_pgoff = 0;
+ vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
vma_set_file(vma, obj->filp);
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
+ vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
+
return 0;
}
@@ -1282,6 +1269,7 @@ static const struct vm_operations_struct omap_gem_vm_ops
= {
static const struct drm_gem_object_funcs omap_gem_object_funcs = {
.free = omap_gem_free_object,
.export = omap_gem_prime_export,
+ .mmap = omap_gem_object_mmap,
.vm_ops = &omap_gem_vm_ops,
};
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.h
b/drivers/gpu/drm/omapdrm/omap_gem.h
index 4d4488939f6b..fec3fa0e4c33 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.h
+++ b/drivers/gpu/drm/omapdrm/omap_gem.h
@@ -57,9 +57,6 @@ int omap_gem_dumb_create(struct drm_file *file, struct
drm_device *dev,
struct drm_mode_create_dumb *args);
/* mmap() Interface */
-int omap_gem_mmap(struct file *filp, struct vm_area_struct *vma);
-int omap_gem_mmap_obj(struct drm_gem_object *obj,
- struct vm_area_struct *vma);
u64 omap_gem_mmap_offset(struct drm_gem_object *obj);
size_t omap_gem_mmap_size(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 8e194dbc9506..36f9ee4baad3 100644
--- a/driver
[PATCH v2 05/11] drm/exynos: Use fbdev DMA helpers
Use fbdev's DMA helpers for fbdev emulation. The driver previously
used the I/O-memory helpers, while allocating DMA-able system memory.
This could (in theory) result in bus errors from accessing the memory
range.
This bug has been present since the exynos driver was first added.
v2:
* drop the pointless Fixes tag (Javier)
* fix typo in commit message
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Acked-by: Inki Dae
Acked-by: Maxime Ripard
Cc: Inki Dae
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: Alim Akhtar
---
drivers/gpu/drm/exynos/Kconfig| 2 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7ca7e1dab52c..661b42ad4873 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -7,7 +7,7 @@ config DRM_EXYNOS
select DRM_DISPLAY_HELPER if DRM_EXYNOS_DP
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
- select FB_IO_HELPERS if DRM_FBDEV_EMULATION
+ select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option if you have a Samsung SoC Exynos chipset.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index fdf65587f1fe..7ca3424b59ce 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -49,9 +49,9 @@ static void exynos_drm_fb_destroy(struct fb_info *info)
static const struct fb_ops exynos_drm_fb_ops = {
.owner = THIS_MODULE,
- __FB_DEFAULT_IO_OPS_RDWR,
+ __FB_DEFAULT_DMA_OPS_RDWR,
DRM_FB_HELPER_DEFAULT_OPS,
- __FB_DEFAULT_IO_OPS_DRAW,
+ __FB_DEFAULT_DMA_OPS_DRAW,
.fb_mmap= exynos_drm_fb_mmap,
.fb_destroy = exynos_drm_fb_destroy,
};
--
2.41.0
[PATCH v2 06/11] drm/exynos: Set fbdev FBINFO_VIRTFB flag
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_FLAG_DEFAULT Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Inki Dae Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Krzysztof Kozlowski Cc: Alim Akhtar --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 7ca3424b59ce..828318de8529 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -79,6 +79,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper *helper, offset = fbi->var.xoffset * fb->format->cpp[0]; offset += fbi->var.yoffset * fb->pitches[0]; + fbi->flags |= FBINFO_VIRTFB; fbi->screen_buffer = exynos_gem->kvaddr + offset; fbi->screen_size = size; fbi->fix.smem_len = size; -- 2.41.0
[PATCH v2 04/11] drm/tegra: Set fbdev FBINFO_VIRTFB flag
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_DEFAULT Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Thierry Reding Cc: Mikko Perttunen --- drivers/gpu/drm/tegra/fbdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c index 82577b7c88da..d8460c5dc91e 100644 --- a/drivers/gpu/drm/tegra/fbdev.c +++ b/drivers/gpu/drm/tegra/fbdev.c @@ -132,6 +132,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper, } } + info->flags |= FBINFO_VIRTFB; info->screen_base = (void __iomem *)bo->vaddr + offset; info->screen_size = size; info->fix.smem_start = (unsigned long)(bo->iova + offset); -- 2.41.0
[PATCH v2 10/11] fbdev: Remove FB_DEFAULT_SYS_OPS
Remove the initializer macro FB_DEFAULT_SYS_OPS and its helper macro __FB_DEFAULT_SYS_OPS_MMAP. There are no users. Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Helge Deller (maintainer:FRAMEBUFFER LAYER) --- include/linux/fb.h | 8 1 file changed, 8 deletions(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index 1191a78c5289..d370f84fbca9 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -586,14 +586,6 @@ extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf, .fb_copyarea= sys_copyarea, \ .fb_imageblit = sys_imageblit -#define __FB_DEFAULT_SYS_OPS_MMAP \ - .fb_mmap= NULL /* default implementation */ - -#define FB_DEFAULT_SYS_OPS \ - __FB_DEFAULT_SYS_OPS_RDWR, \ - __FB_DEFAULT_SYS_OPS_DRAW, \ - __FB_DEFAULT_SYS_OPS_MMAP - /* * Helpers for framebuffers in DMA-able memory */ -- 2.41.0
[PATCH v2 08/11] drm/omapdrm: Use GEM mmap for fbdev emulation
The fbdev emulation currently uses fbdev's default mmap code, which
has been written for I/O memory. Provide an mmap that uses GEM's mmap
infrastructure.
Utilize fine-grained fbdev macros to initialize struct fb_ops. The
macros set the read/write and the draw callbacks for DMA memory. Set
the fb_mmap callback to omapdrm's new mmap helper. Also select the
correct Kconfig token for fbdev's DMA helpers. Note that the DMA
helpers are the same as for system memory.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Javier Martinez Canillas
Acked-by: Maxime Ripard
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/Kconfig | 2 +-
drivers/gpu/drm/omapdrm/omap_fbdev.c | 15 +--
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
index b4ac76c9f31b..d3c4877e465c 100644
--- a/drivers/gpu/drm/omapdrm/Kconfig
+++ b/drivers/gpu/drm/omapdrm/Kconfig
@@ -4,7 +4,7 @@ config DRM_OMAP
depends on DRM && OF
depends on ARCH_OMAP2PLUS
select DRM_KMS_HELPER
- select FB_SYS_HELPERS if DRM_FBDEV_EMULATION
+ select FB_DMA_HELPERS if DRM_FBDEV_EMULATION
select VIDEOMODE_HELPERS
select HDMI
default n
diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
b/drivers/gpu/drm/omapdrm/omap_fbdev.c
index b7ccce0704a3..b1a2d00ef52d 100644
--- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
+++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
@@ -76,6 +76,15 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo
*var,
return drm_fb_helper_pan_display(var, fbi);
}
+static int omap_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct drm_fb_helper *helper = info->par;
+ struct drm_framebuffer *fb = helper->fb;
+ struct drm_gem_object *bo = drm_gem_fb_get_obj(fb, 0);
+
+ return drm_gem_mmap_obj(bo, omap_gem_mmap_size(bo), vma);
+}
+
static void omap_fbdev_fb_destroy(struct fb_info *info)
{
struct drm_fb_helper *helper = info->par;
@@ -97,14 +106,16 @@ static void omap_fbdev_fb_destroy(struct fb_info *info)
static const struct fb_ops omap_fb_ops = {
.owner = THIS_MODULE,
- FB_DEFAULT_SYS_OPS,
+ __FB_DEFAULT_DMA_OPS_RDWR,
.fb_check_var = drm_fb_helper_check_var,
.fb_set_par = drm_fb_helper_set_par,
.fb_setcmap = drm_fb_helper_setcmap,
.fb_blank = drm_fb_helper_blank,
.fb_pan_display = omap_fbdev_pan_display,
+ __FB_DEFAULT_DMA_OPS_DRAW,
.fb_ioctl = drm_fb_helper_ioctl,
- .fb_destroy = omap_fbdev_fb_destroy,
+ .fb_mmap= omap_fbdev_fb_mmap,
+ .fb_destroy = omap_fbdev_fb_destroy,
};
static int omap_fbdev_create(struct drm_fb_helper *helper,
--
2.41.0
[PATCH v2 11/11] fbdev: Harmonize some comments in
Make the comments for I/O, system and DMA memory say the same. Makes the header file's structure more obvious. Signed-off-by: Thomas Zimmermann Suggested-by: Javier Martinez Canillas --- include/linux/fb.h | 12 ++-- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/include/linux/fb.h b/include/linux/fb.h index d370f84fbca9..c8ca9c265fda 100644 --- a/include/linux/fb.h +++ b/include/linux/fb.h @@ -529,7 +529,7 @@ extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var); extern int fb_blank(struct fb_info *info, int blank); /* - * Drawing operations where framebuffer is in I/O memory + * Helpers for framebuffers in I/O memory */ extern void cfb_fillrect(struct fb_info *info, const struct fb_fillrect *rect); @@ -540,10 +540,6 @@ extern ssize_t fb_io_read(struct fb_info *info, char __user *buf, extern ssize_t fb_io_write(struct fb_info *info, const char __user *buf, size_t count, loff_t *ppos); -/* - * Initializes struct fb_ops for framebuffers in I/O memory. - */ - #define __FB_DEFAULT_IO_OPS_RDWR \ .fb_read= fb_io_read, \ .fb_write = fb_io_write @@ -562,7 +558,7 @@ extern ssize_t fb_io_write(struct fb_info *info, const char __user *buf, __FB_DEFAULT_IO_OPS_MMAP /* - * Drawing operations where framebuffer is in system RAM + * Helpers for framebuffers in system memory */ extern void sys_fillrect(struct fb_info *info, const struct fb_fillrect *rect); @@ -573,10 +569,6 @@ extern ssize_t fb_sys_read(struct fb_info *info, char __user *buf, extern ssize_t fb_sys_write(struct fb_info *info, const char __user *buf, size_t count, loff_t *ppos); -/* - * Initializes struct fb_ops for framebuffers in system memory. - */ - #define __FB_DEFAULT_SYS_OPS_RDWR \ .fb_read= fb_sys_read, \ .fb_write = fb_sys_write -- 2.41.0
[PATCH v2 09/11] drm/omapdrm: Set fbdev FBINFO_VIRTFB flag
Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_DEFAULT Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fbdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c index b1a2d00ef52d..2821182f1d93 100644 --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c @@ -207,6 +207,7 @@ static int omap_fbdev_create(struct drm_fb_helper *helper, drm_fb_helper_fill_info(fbi, helper, sizes); + fbi->flags |= FBINFO_VIRTFB; fbi->screen_buffer = omap_gem_vaddr(bo); fbi->screen_size = bo->size; fbi->fix.smem_start = dma_addr; -- 2.41.0
Re: [PATCH v2] dma-buf: fix an error pointer vs NULL bug
Am 06.07.23 um 14:37 schrieb Dan Carpenter:
Smatch detected potential error pointer dereference.
drivers/gpu/drm/drm_syncobj.c:888 drm_syncobj_transfer_to_timeline()
error: 'fence' dereferencing possible ERR_PTR()
The error pointer comes from dma_fence_allocate_private_stub(). One
caller expected error pointers and one expected NULL pointers. Change
it to return NULL and update the caller which expected error pointers,
drm_syncobj_assign_null_handle(), to check for NULL instead.
Fixes: f781f661e8c9 ("dma-buf: keep the signaling time of merged fences v3")
Signed-off-by: Dan Carpenter
Reviewed-by: Christian König
Should I push that one to drm-misc-fixes?
Regards,
Christian.
---
v2: Fix it in dma_fence_allocate_private_stub() instead of
__dma_fence_unwrap_merge().
drivers/dma-buf/dma-fence.c | 2 +-
drivers/gpu/drm/drm_syncobj.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index ad076f208760..8aa8f8cb7071 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -160,7 +160,7 @@ struct dma_fence *dma_fence_allocate_private_stub(ktime_t
timestamp)
fence = kzalloc(sizeof(*fence), GFP_KERNEL);
if (fence == NULL)
- return ERR_PTR(-ENOMEM);
+ return NULL;
dma_fence_init(fence,
&dma_fence_stub_ops,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 04589a35eb09..e592c5da70ce 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -355,8 +355,8 @@ static int drm_syncobj_assign_null_handle(struct
drm_syncobj *syncobj)
{
struct dma_fence *fence = dma_fence_allocate_private_stub(ktime_get());
- if (IS_ERR(fence))
- return PTR_ERR(fence);
+ if (!fence)
+ return -ENOMEM;
drm_syncobj_replace_fence(syncobj, fence);
dma_fence_put(fence);
Re: [PATCH v2] drm/ast: report connection status on Display Port.
On 06.07.23 11:58, Jocelyn Falempe wrote:
> Aspeed always report the display port as "connected", because it
> doesn't set a .detect callback.
> Fix this by providing the proper detect callback for astdp and dp501.
>
> This also fixes the following regression:
> Since commit fae7d186403e ("drm/probe-helper: Default to 640x480 if no
> EDID on DP")
> The default resolution is now 640x480 when no monitor is connected.
> But Aspeed graphics is mostly used in servers, where no monitor
> is attached. This also affects the remote BMC resolution to 640x480,
> which is inconvenient, and breaks the anaconda installer.
>
> v2: Add .detect callback to the dp/dp501 connector (Jani Nikula)
>
> Signed-off-by: Jocelyn Falempe
So if this "also fixes a regression" how about a Fixes: tag and a CC:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
Re: [PATCH v2 11/11] fbdev: Harmonize some comments in
Thomas Zimmermann writes: Hello Thomas, > Make the comments for I/O, system and DMA memory say the same. > Makes the header file's structure more obvious. > > Signed-off-by: Thomas Zimmermann > Suggested-by: Javier Martinez Canillas > --- Looks good to me. Thanks! Reviewed-by: Javier Martinez Canillas -- Best regards, Javier Martinez Canillas Core Platforms Red Hat
[PATCH v2] drm/mediatek: Fix potential memory leak if vmap() fail
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap function")
Reviewed-by: Matthias Brugger
Reviewed-by: Alexandre Mergnat
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index a25b28d3ee90..9f364df52478 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -247,7 +247,11 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj,
struct iosys_map *map)
mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
-
+ if (!mtk_gem->kvaddr) {
+ kfree(sgt);
+ kfree(mtk_gem->pages);
+ return -ENOMEM;
+ }
out:
kfree(sgt);
iosys_map_set_vaddr(map, mtk_gem->kvaddr);
--
2.34.1
Re: [PATCH] drm/mediatek: Fix potential memory leak if vmap() fail
Hi,
On 2023/7/6 20:47, AngeloGioacchino Del Regno wrote:
Il 26/06/23 20:58, Sui Jingfeng ha scritto:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
This commit needs a Fixes tag. Please add the relevant one and resend.
Done at [1],
Thanks for point this out, I got it.
[1] https://patchwork.freedesktop.org/patch/545843/?series=119885&rev=2
Thanks,
Angelo
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index a25b28d3ee90..9f364df52478 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -247,7 +247,11 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object
*obj, struct iosys_map *map)
mtk_gem->kvaddr = vmap(mtk_gem->pages, npages, VM_MAP,
pgprot_writecombine(PAGE_KERNEL));
-
+ if (!mtk_gem->kvaddr) {
+ kfree(sgt);
+ kfree(mtk_gem->pages);
+ return -ENOMEM;
+ }
out:
kfree(sgt);
iosys_map_set_vaddr(map, mtk_gem->kvaddr);
Re: [PATCH] Fix max/min warnings in virtio_net, amd/display, and io_uring
On Thu, Jul 6, 2023 at 3:37 AM Yang Rong wrote:
>
> The files drivers/net/virtio_net.c,
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c, and io_uring/io_uring.c were
> modified to fix warnings.
> Specifically, the opportunities for max() and min() were utilized to address
> the warnings.
Please split this into 3 patches, one for each component.
Alex
>
> Signed-off-by: Yang Rong
> ---
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 6 +++---
> drivers/net/virtio_net.c | 3 ++-
> io_uring/io_uring.c | 3 ++-
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> index c753c6f30dd7..df79aea49a3c 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> @@ -22,7 +22,7 @@
> * Authors: AMD
> *
> */
> -
> +#include
> #include "dc.h"
> #include "dc_dmub_srv.h"
> #include "../dmub/dmub_srv.h"
> @@ -481,7 +481,7 @@ static void populate_subvp_cmd_drr_info(struct dc *dc,
> max_drr_vblank_us = div64_u64((subvp_active_us - prefetch_us -
> dc->caps.subvp_fw_processing_delay_us -
> drr_active_us), 2) + drr_active_us;
> max_drr_mallregion_us = subvp_active_us - prefetch_us -
> mall_region_us - dc->caps.subvp_fw_processing_delay_us;
> - max_drr_supported_us = max_drr_vblank_us > max_drr_mallregion_us ?
> max_drr_vblank_us : max_drr_mallregion_us;
> + max_drr_supported_us = max(max_drr_vblank_us, max_drr_mallregion_us);
> max_vtotal_supported = div64_u64(((uint64_t)drr_timing->pix_clk_100hz
> * 100 * max_drr_supported_us),
> (((uint64_t)drr_timing->h_total * 100)));
>
> @@ -771,7 +771,7 @@ void dc_dmub_setup_subvp_dmub_command(struct dc *dc,
> wm_val_refclk =
> context->bw_ctx.bw.dcn.watermarks.a.cstate_pstate.pstate_change_ns *
>
> (dc->res_pool->ref_clocks.dchub_ref_clock_inKhz / 1000) / 1000;
>
> - cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache
> = wm_val_refclk < 0x ? wm_val_refclk : 0x;
> + cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache
> = min(wm_val_refclk, 0x);
> }
>
> dm_execute_dmub_cmd(dc->ctx, &cmd, DM_DMUB_WAIT_TYPE_WAIT);
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9b3721424e71..5bb7da885f00 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
> @@ -1291,7 +1292,7 @@ static struct sk_buff *build_skb_from_xdp_buff(struct
> net_device *dev,
> __skb_put(skb, data_len);
>
> metasize = xdp->data - xdp->data_meta;
> - metasize = metasize > 0 ? metasize : 0;
> + metasize = max(metasize, 0);
> if (metasize)
> skb_metadata_set(skb, metasize);
>
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index e8096d502a7c..875ca657227d 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -2660,7 +2661,7 @@ static void *__io_uaddr_map(struct page ***pages,
> unsigned short *npages,
> page_array);
> if (ret != nr_pages) {
> err:
> - io_pages_free(&page_array, ret > 0 ? ret : 0);
> + io_pages_free(&page_array, max(ret, 0));
> return ret < 0 ? ERR_PTR(ret) : ERR_PTR(-EFAULT);
> }
> /*
> --
> 2.35.3
>
>
>
> 本邮件及其附件内容可能含有机密和/或隐私信息，仅供指定个人或机构使用。若您非发件人指定收件人或其代理人，请勿使用、传播、复制或存储此邮件之任何内容或其附件。如您误收本邮件，请即以回复或电话方式通知发件人，并将原始邮件、附件及其所有复本删除。谢谢。
> The contents of this message and any attachments may contain confidential
> and/or privileged information and are intended exclusively for the
> addressee(s). If you are not the intended recipient of this message or their
> agent, please note that any use, dissemination, copying, or storage of this
> message or its attachments is not allowed. If you receive this message in
> error, please notify the sender by reply the message or phone and delete this
> message, any attachments and any copies immediately.
> Thank you
Re: [drm-rerere] nightly.conf: drop sound tree from drm-tip altogether
On Thu, Jul 6, 2023 at 5:29 AM Jani Nikula wrote: > > We used to have the sound branches be part of drm-tip to help > development of DP and HDMI audio. However, we always used to run into > problems with the sound branches merging Linus' master at non-tagged > random commits, wreaking havoc especially during the merge windows. We > only ever want to have tagged stuff merged back from Linus' tree to > drm-tip. > > We introduced a mechanism in dim to hold back branches at certain > commits, just to hold back sound branches when problems arise. We moved > it along, but in the end nobody has updated this in literally years, and > sound branches have been held back at v5.13. > > The merge window is currently open, and AFAICT the sound/for-linus > branch again contains commits from the merge window. > > Let's just forget about the sound tree, as nobody has really missed it > since v5.13, and focus on the drm branches. > > Signed-off-by: Jani Nikula Acked-by: Alex Deucher > --- > nightly.conf | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/nightly.conf b/nightly.conf > index 73aec820e98f..c1e22800e276 100644 > --- a/nightly.conf > +++ b/nightly.conf > @@ -46,11 +46,6 @@ git://anongit.freedesktop.org/drm/drm > https://anongit.freedesktop.org/git/drm/drm > https://anongit.freedesktop.org/git/drm/drm.git > " > -drm_tip_repos[sound-upstream]=" > -git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > -https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > -https://kernel.googlesource.com/pub/scm/linux/kernel/git/tiwai/sound.git > -" > drm_tip_repos[linux-upstream]=" > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > @@ -79,8 +74,6 @@ drm_tip_config=( > "drm-intel drm-intel-next" > "drm-intel drm-intel-gt-next" > > - "sound-upstream for-linus v5.13" > - "sound-upstream for-nextv5.13" > "drm-intel topic/core-for-CI" > "drm-misc topic/i915-ttm" > "drmtopic/nouveau-misc" > -- > 2.39.2 >
Re: [PATCH] Fix max/min warnings in virtio_net, amd/display, and io_uring
On Thu, Jul 06, 2023 at 10:06:16AM +0800, Yang Rong wrote:
> The files drivers/net/virtio_net.c,
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c, and io_uring/io_uring.c were
> modified to fix warnings.
what warnings? the point of the warning is to analyze it not "fix" it
blindly.
> Specifically, the opportunities for max() and min() were utilized to address
> the warnings.
>
> Signed-off-by: Yang Rong
> ---
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 6 +++---
> drivers/net/virtio_net.c | 3 ++-
> io_uring/io_uring.c | 3 ++-
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> index c753c6f30dd7..df79aea49a3c 100644
> --- a/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> +++ b/drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c
> @@ -22,7 +22,7 @@
> * Authors: AMD
> *
> */
> -
> +#include
> #include "dc.h"
> #include "dc_dmub_srv.h"
> #include "../dmub/dmub_srv.h"
> @@ -481,7 +481,7 @@ static void populate_subvp_cmd_drr_info(struct dc *dc,
> max_drr_vblank_us = div64_u64((subvp_active_us - prefetch_us -
> dc->caps.subvp_fw_processing_delay_us -
> drr_active_us), 2) + drr_active_us;
> max_drr_mallregion_us = subvp_active_us - prefetch_us -
> mall_region_us - dc->caps.subvp_fw_processing_delay_us;
> - max_drr_supported_us = max_drr_vblank_us > max_drr_mallregion_us ?
> max_drr_vblank_us : max_drr_mallregion_us;
> + max_drr_supported_us = max(max_drr_vblank_us, max_drr_mallregion_us);
> max_vtotal_supported = div64_u64(((uint64_t)drr_timing->pix_clk_100hz
> * 100 * max_drr_supported_us),
> (((uint64_t)drr_timing->h_total * 100)));
>
> @@ -771,7 +771,7 @@ void dc_dmub_setup_subvp_dmub_command(struct dc *dc,
> wm_val_refclk =
> context->bw_ctx.bw.dcn.watermarks.a.cstate_pstate.pstate_change_ns *
>
> (dc->res_pool->ref_clocks.dchub_ref_clock_inKhz / 1000) / 1000;
>
> - cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache
> = wm_val_refclk < 0x ? wm_val_refclk : 0x;
> + cmd.fw_assisted_mclk_switch_v2.config_data.watermark_a_cache
> = min(wm_val_refclk, 0x);
> }
>
> dm_execute_dmub_cmd(dc->ctx, &cmd, DM_DMUB_WAIT_TYPE_WAIT);
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 9b3721424e71..5bb7da885f00 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> static int napi_weight = NAPI_POLL_WEIGHT;
> module_param(napi_weight, int, 0444);
> @@ -1291,7 +1292,7 @@ static struct sk_buff *build_skb_from_xdp_buff(struct
> net_device *dev,
> __skb_put(skb, data_len);
>
> metasize = xdp->data - xdp->data_meta;
> - metasize = metasize > 0 ? metasize : 0;
> + metasize = max(metasize, 0);
> if (metasize)
> skb_metadata_set(skb, metasize);
>
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index e8096d502a7c..875ca657227d 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -2660,7 +2661,7 @@ static void *__io_uaddr_map(struct page ***pages,
> unsigned short *npages,
> page_array);
> if (ret != nr_pages) {
> err:
> - io_pages_free(&page_array, ret > 0 ? ret : 0);
> + io_pages_free(&page_array, max(ret, 0));
> return ret < 0 ? ERR_PTR(ret) : ERR_PTR(-EFAULT);
> }
> /*
> --
> 2.35.3
>
>
>
> 本邮件及其附件内容可能含有机密和/或隐私信息，仅供指定个人或机构使用。若您非发件人指定收件人或其代理人，请勿使用、传播、复制或存储此邮件之任何内容或其附件。如您误收本邮件，请即以回复或电话方式通知发件人，并将原始邮件、附件及其所有复本删除。谢谢。
> The contents of this message and any attachments may contain confidential
> and/or privileged information and are intended exclusively for the
> addressee(s). If you are not the intended recipient of this message or their
> agent, please note that any use, dissemination, copying, or storage of this
> message or its attachments is not allowed. If you receive this message in
> error, please notify the sender by reply the message or phone and delete this
> message, any attachments and any copies immediately.
> Thank you
Re: [PATCH v2] dma-buf: fix an error pointer vs NULL bug
On Thu, 6 Jul 2023 at 18:24, Christian König wrote:
>
> Am 06.07.23 um 14:37 schrieb Dan Carpenter:
> > Smatch detected potential error pointer dereference.
> >
> > drivers/gpu/drm/drm_syncobj.c:888 drm_syncobj_transfer_to_timeline()
> > error: 'fence' dereferencing possible ERR_PTR()
> >
> > The error pointer comes from dma_fence_allocate_private_stub(). One
> > caller expected error pointers and one expected NULL pointers. Change
> > it to return NULL and update the caller which expected error pointers,
> > drm_syncobj_assign_null_handle(), to check for NULL instead.
> >
> > Fixes: f781f661e8c9 ("dma-buf: keep the signaling time of merged fences v3")
> > Signed-off-by: Dan Carpenter
>
Thanks for catching this!
> Reviewed-by: Christian König
Reviewed-by: Sumit Semwal
>
> Should I push that one to drm-misc-fixes?
If you haven't pushed already, I can push it now.
>
> Regards,
> Christian.
Best,
Sumit.
>
> > ---
> > v2: Fix it in dma_fence_allocate_private_stub() instead of
> > __dma_fence_unwrap_merge().
> >
> >
> > drivers/dma-buf/dma-fence.c | 2 +-
> > drivers/gpu/drm/drm_syncobj.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index ad076f208760..8aa8f8cb7071 100644
> > --- a/drivers/dma-buf/dma-fence.c
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -160,7 +160,7 @@ struct dma_fence
> > *dma_fence_allocate_private_stub(ktime_t timestamp)
> >
> > fence = kzalloc(sizeof(*fence), GFP_KERNEL);
> > if (fence == NULL)
> > - return ERR_PTR(-ENOMEM);
> > + return NULL;
> >
> > dma_fence_init(fence,
> > &dma_fence_stub_ops,
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index 04589a35eb09..e592c5da70ce 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -355,8 +355,8 @@ static int drm_syncobj_assign_null_handle(struct
> > drm_syncobj *syncobj)
> > {
> > struct dma_fence *fence =
> > dma_fence_allocate_private_stub(ktime_get());
> >
> > - if (IS_ERR(fence))
> > - return PTR_ERR(fence);
> > + if (!fence)
> > + return -ENOMEM;
> >
> > drm_syncobj_replace_fence(syncobj, fence);
> > dma_fence_put(fence);
>
--
Thanks and regards,
Sumit Semwal (he / him)
Tech Lead - LCG, Vertical Technologies
Linaro.org │ Open source software for ARM SoCs
Re: [PATCH v2 04/11] drm/tegra: Set fbdev FBINFO_VIRTFB flag
On Thu, Jul 06, 2023 at 02:46:42PM +0200, Thomas Zimmermann wrote: > Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is > in DMA-able memory and should be accessed with the CPU's regular > memory ops. > > v2: > * drop FBINFO_DEFAULT > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Javier Martinez Canillas > Acked-by: Maxime Ripard > Cc: Thierry Reding > Cc: Mikko Perttunen > --- > drivers/gpu/drm/tegra/fbdev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c > index 82577b7c88da..d8460c5dc91e 100644 > --- a/drivers/gpu/drm/tegra/fbdev.c > +++ b/drivers/gpu/drm/tegra/fbdev.c > @@ -132,6 +132,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper, > } > } > > + info->flags |= FBINFO_VIRTFB; > info->screen_base = (void __iomem *)bo->vaddr + offset; As part of this, do we also need to set info->screen_buffer instead of info->screen_base? The drm_fbdev_dma_helper functions do that. Thierry > info->screen_size = size; > info->fix.smem_start = (unsigned long)(bo->iova + offset); > -- > 2.41.0 > signature.asc Description: PGP signature
Re: [PATCH v2 04/11] drm/tegra: Set fbdev FBINFO_VIRTFB flag
Hi Am 06.07.23 um 16:31 schrieb Thierry Reding: On Thu, Jul 06, 2023 at 02:46:42PM +0200, Thomas Zimmermann wrote: Mark the framebuffer with FBINFO_VIRTFB. The framebuffer range is in DMA-able memory and should be accessed with the CPU's regular memory ops. v2: * drop FBINFO_DEFAULT Signed-off-by: Thomas Zimmermann Reviewed-by: Javier Martinez Canillas Acked-by: Maxime Ripard Cc: Thierry Reding Cc: Mikko Perttunen --- drivers/gpu/drm/tegra/fbdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tegra/fbdev.c b/drivers/gpu/drm/tegra/fbdev.c index 82577b7c88da..d8460c5dc91e 100644 --- a/drivers/gpu/drm/tegra/fbdev.c +++ b/drivers/gpu/drm/tegra/fbdev.c @@ -132,6 +132,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper, } } + info->flags |= FBINFO_VIRTFB; info->screen_base = (void __iomem *)bo->vaddr + offset; As part of this, do we also need to set info->screen_buffer instead of info->screen_base? The drm_fbdev_dma_helper functions do that. Indeed, good point. I'll update this in the next iteration. Best regards Thomas Thierry info->screen_size = size; info->fix.smem_start = (unsigned long)(bo->iova + offset); -- 2.41.0 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #57 from Alex Deucher (alexdeuc...@gmail.com) --- Does this patch help? https://gitlab.freedesktop.org/drm/amd/uploads/64dc2a05039b583e89da17309969fa50/0001-client-register-fix-plus-fbdev-debug-noise-2.patch It's pretty noisy. The meat of the patch is this hunk: diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 76e46713b2f0..5d28c54b2512 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2634,10 +2678,12 @@ void drm_fbdev_generic_setup(struct drm_device *dev, preferred_bpp = 32; fb_helper->preferred_bpp = preferred_bpp; + drm_client_register(&fb_helper->client); + ret = drm_fbdev_client_hotplug(&fb_helper->client); if (ret) drm_dbg_kms(dev, "client hotplug ret=%d\n", ret); - drm_client_register(&fb_helper->client); + drm_warn(dev, "%s:%d\n", __FILE__, __LINE__); } EXPORT_SYMBOL(drm_fbdev_generic_setup); -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390
https://bugzilla.kernel.org/show_bug.cgi?id=216119 --- Comment #58 from Alex Deucher (alexdeuc...@gmail.com) --- Nevermind, sorry, wrong bug. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings
Hi Boris,
On 6/30/23 10:02, Boris Brezillon wrote:
Hi Danilo,
On Fri, 30 Jun 2023 00:25:18 +0200
Danilo Krummrich wrote:
+ * int driver_gpuva_remap(struct drm_gpuva_op *op, void *__ctx)
+ * {
+ * struct driver_context *ctx = __ctx;
+ *
+ * drm_gpuva_remap(ctx->prev_va, ctx->next_va, &op->remap);
+ *
+ * drm_gpuva_unlink(op->remap.unmap->va);
+ * kfree(op->remap.unmap->va);
+ *
+ * if (op->remap.prev) {
+ * drm_gpuva_link(ctx->prev_va);
I ended up switching to dma_resv-based locking for the GEMs and I
wonder what the locking is supposed to look like in the async-mapping
case, where we insert/remove the VA nodes in the drm_sched::run_job()
path.
If you decide to pick the interface where you just call
drm_gpuva_sm_[un]map() and receive a callback for each operation it
takes to fulfill the request, you probably do this because you want to
do everything one shot, updating the VA space, link/unlink GPUVAs
to/from its corresponding backing GEMs, do the actual GPU mappings.
This has a few advantages over generating a list of operations when the
job is submitted. You've pointed out one of them, when you noticed that
with a list of operations one can't sneak in a synchronous job between
already queued up asynchronous jobs.
However, for the asynchronous path it has the limitation that the
dma-resv lock can't be used to link/unlink GPUVAs to/from its
corresponding backing GEMs, since this would happen in the fence
signalling critical path and we're not allowed to hold the dma-resv lock
there. Hence, as we discussed I added the option for drivers to provide
an external lock for that, just to be able to keep some lockdep checks.
What I have right now is something like:
dma_resv_lock(vm->resv);
// split done in drm_gpuva_sm_map(), each iteration
// of the loop is a call to the driver ->[re,un]map()
// hook
for_each_sub_op() {
// Private BOs have their resv field pointing to the
// VM resv and we take the VM resv lock before calling
// drm_gpuva_sm_map()
if (vm->resv != gem->resv)
dma_resv_lock(gem->resv);
drm_gpuva_[un]link(va);
gem_[un]pin(gem);
if (vm->resv != gem->resv)
dma_resv_unlock(gem->resv);
}
dma_resv_unlock(vm->resv);
I'm not sure I get this code right, reading "for_each_sub_op()" and
"drm_gpuva_sm_map()" looks a bit like things are mixed up?
Or do you mean to represent the sum of all callbacks with
"for_each_sub_op()"? In this case I assume this code runs in
drm_sched::run_job() and hence isn't allowed to take the dma-resv lock.
In practice, I don't expect things to deadlock, because the VM resv is
not supposed to be taken outside the VM context and the locking order
is always the same (VM lock first, and then each shared BO
taken/released independently), but I'm not super thrilled by this
nested lock, and I'm wondering if we shouldn't have a pass collecting
locks in a drm_exec context first, and then have
the operations executed. IOW, something like that:
drm_exec_init(exec, DRM_EXEC_IGNORE_DUPLICATES)
drm_exec_until_all_locked(exec) {
// Dummy GEM is the dummy GEM object I use to make the VM
// participate in the locking without having to teach
// drm_exec how to deal with raw dma_resv objects.
ret = drm_exec_lock_obj(exec, vm->dummy_gem);
drm_exec_retry_on_contention(exec);
if (ret)
return ret;
// Could take the form of drm_gpuva_sm_[un]map_acquire_locks()
// helpers
for_each_sub_op() {
ret = drm_exec_lock_obj(exec, gem);
if (ret)
return ret;
}
}
// each iteration of the loop is a call to the driver
// ->[re,un]map() hook
for_each_sub_op() {
...
gem_[un]pin_locked(gem);
drm_gpuva_[un]link(va);
...
}
drm_exec_fini(exec);
I have a follow-up patch (still WIP) in the queue to generalize dma-resv
handling, fence handling and GEM validation within the GPUVA manager as
optional helper functions:
https://gitlab.freedesktop.org/nouvelles/kernel/-/commit/a5fc29f3b1edbf3f96fb5a21b858ffe00a3f2584
This was suggested by Matt Brost.
- Danilo
Don't know if I got this right, or if I'm just confused again by how
the drm_gpuva API is supposed to be used.
Regards,
Boris
+ * ctx->prev_va = NULL;
+ * }
+ *
+ * if (op->remap.next) {
+ * drm_gpuva_link(ctx->next_va);
+ * ctx->next_va
[PATCH 00/10] fbdev: Generate deferred-I/O helpers
Generate the I/O callbacks for drivers with deferred I/O. As in the old, opencoded functions, the generated functions operate on system memory and trigger damage handling if necessary. Also bring the drivers' Kconfig options up to date. Generating and initializing via helpers macros will later allow for a fine-grained setup, depending on Kconfig options. For example, it will be possible to leave out file I/O if FB_DEVICE has not been set. Thomas Zimmermann (10): fbdev/broadsheetfb: Select FB_SYS_HELPERS_DEFERRED fbdev/broadsheetfb: Generate deferred I/O ops fbdev/hecubafb: Select FB_SYS_HELPERS_DEFERRED fbdev/hecubafb: Generate deferred I/O ops fbdev/metronomefb: Select FB_SYS_HELPERS_DEFERRED fbdev/metronomefb: Generate deferred I/O ops fbdev/ssd1307fb: Select FB_SYS_HELPERS_DEFERRED fbdev/ssd1307fb: Generate deferred I/O ops fbdev/xen-fbfront: Select FB_SYS_HELPERS_DEFERRED fbdev/xen-fbfront: Generate deferred I/O ops drivers/video/fbdev/Kconfig| 31 ++-- drivers/video/fbdev/broadsheetfb.c | 78 +++--- drivers/video/fbdev/hecubafb.c | 78 +++--- drivers/video/fbdev/metronomefb.c | 74 +++- drivers/video/fbdev/ssd1307fb.c| 69 +- drivers/video/fbdev/xen-fbfront.c | 61 --- 6 files changed, 60 insertions(+), 331 deletions(-) -- 2.41.0
[PATCH 04/10] fbdev/hecubafb: Generate deferred I/O ops
Use the existing generator macros to create deferred-I/O helpers
for hecubafb and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Hecubafb's implementation of fb_write writes to system memory,
so the generated code can use the respective helper internally.
This also fixes a long-standing bug where fb_write returned an
errno code instead of the number of written bytes. See the commit
message of commit 921b7383f348 ("fbdev: Return number of bytes
read or written") for more details.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/hecubafb.c | 78 --
1 file changed, 8 insertions(+), 70 deletions(-)
diff --git a/drivers/video/fbdev/hecubafb.c b/drivers/video/fbdev/hecubafb.c
index 7ce0a16ce8b9..5043d08ade54 100644
--- a/drivers/video/fbdev/hecubafb.c
+++ b/drivers/video/fbdev/hecubafb.c
@@ -120,90 +120,28 @@ static void hecubafb_dpy_deferred_io(struct fb_info
*info, struct list_head *pag
hecubafb_dpy_update(info->par);
}
-static void hecubafb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
+static void hecubafb_defio_damage_range(struct fb_info *info, off_t off,
size_t len)
{
struct hecubafb_par *par = info->par;
- sys_fillrect(info, rect);
-
hecubafb_dpy_update(par);
}
-static void hecubafb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
+static void hecubafb_defio_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
{
struct hecubafb_par *par = info->par;
- sys_copyarea(info, area);
-
hecubafb_dpy_update(par);
}
-static void hecubafb_imageblit(struct fb_info *info,
- const struct fb_image *image)
-{
- struct hecubafb_par *par = info->par;
-
- sys_imageblit(info, image);
-
- hecubafb_dpy_update(par);
-}
-
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it's inefficient to do anything less than a full screen draw
- */
-static ssize_t hecubafb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct hecubafb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (!info->screen_buffer)
- return -ENODEV;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = info->screen_buffer + p;
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
-
- hecubafb_dpy_update(par);
-
- return (err) ? err : count;
-}
+FB_GEN_DEFAULT_DEFERRED_SYS_OPS(hecubafb,
+ hecubafb_defio_damage_range,
+ hecubafb_defio_damage_area)
static const struct fb_ops hecubafb_ops = {
- .owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = hecubafb_write,
- .fb_fillrect= hecubafb_fillrect,
- .fb_copyarea= hecubafb_copyarea,
- .fb_imageblit = hecubafb_imageblit,
- .fb_mmap= fb_deferred_io_mmap,
+ .owner = THIS_MODULE,
+ FB_DEFAULT_DEFERRED_OPS(hecubafb),
};
static struct fb_deferred_io hecubafb_defio = {
--
2.41.0
[PATCH 02/10] fbdev/broadsheetfb: Generate deferred I/O ops
Use the existing generator macros to create deferred-I/O helpers
for broadsheetfb and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Broadsheedfb's implementation of fb_write writes to system memory,
so the generated code can use the respective helper internally.
This also fixes a long-standing bug where fb_write returned an
errno code instead of the number of written bytes. See the commit
message of commit 921b7383f348 ("fbdev: Return number of bytes
read or written") for more details.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/broadsheetfb.c | 78 +++---
1 file changed, 8 insertions(+), 70 deletions(-)
diff --git a/drivers/video/fbdev/broadsheetfb.c
b/drivers/video/fbdev/broadsheetfb.c
index 5a5fe4bbc10b..cb725a91b6bb 100644
--- a/drivers/video/fbdev/broadsheetfb.c
+++ b/drivers/video/fbdev/broadsheetfb.c
@@ -970,90 +970,28 @@ static void broadsheetfb_dpy_deferred_io(struct fb_info
*info, struct list_head
}
}
-static void broadsheetfb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
+static void broadsheetfb_defio_damage_range(struct fb_info *info, off_t off,
size_t len)
{
struct broadsheetfb_par *par = info->par;
- sys_fillrect(info, rect);
-
broadsheetfb_dpy_update(par);
}
-static void broadsheetfb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
+static void broadsheetfb_defio_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
{
struct broadsheetfb_par *par = info->par;
- sys_copyarea(info, area);
-
broadsheetfb_dpy_update(par);
}
-static void broadsheetfb_imageblit(struct fb_info *info,
- const struct fb_image *image)
-{
- struct broadsheetfb_par *par = info->par;
-
- sys_imageblit(info, image);
-
- broadsheetfb_dpy_update(par);
-}
-
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it's inefficient to do anything less than a full screen draw
- */
-static ssize_t broadsheetfb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct broadsheetfb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (!info->screen_buffer)
- return -ENODEV;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = info->screen_buffer + p;
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
-
- broadsheetfb_dpy_update(par);
-
- return (err) ? err : count;
-}
+FB_GEN_DEFAULT_DEFERRED_SYS_OPS(broadsheetfb,
+ broadsheetfb_defio_damage_range,
+ broadsheetfb_defio_damage_area)
static const struct fb_ops broadsheetfb_ops = {
- .owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = broadsheetfb_write,
- .fb_fillrect= broadsheetfb_fillrect,
- .fb_copyarea= broadsheetfb_copyarea,
- .fb_imageblit = broadsheetfb_imageblit,
- .fb_mmap= fb_deferred_io_mmap,
+ .owner = THIS_MODULE,
+ FB_DEFAULT_DEFERRED_OPS(broadsheetfb),
};
static struct fb_deferred_io broadsheetfb_defio = {
--
2.41.0
[PATCH 05/10] fbdev/metronomefb: Select FB_SYS_HELPERS_DEFERRED
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that is required for deferred I/O on system-memory framebuffers. Select it from FB_METRONOME in favor of the existing identical selection. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 7587f06cb793..1155d7aa0917 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2088,11 +2088,7 @@ config XEN_FBDEV_FRONTEND config FB_METRONOME tristate "E-Ink Metronome/8track controller support" depends on FB - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYS_HELPERS_DEFERRED help This driver implements support for the E-Ink Metronome controller. The pre-release name for this device was 8track -- 2.41.0
[PATCH 08/10] fbdev/ssd1307fb: Generate deferred I/O ops
Use the existing generator macros to create deferred-I/O helpers
for ssd1307fb and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Ssd1307fb's implementation of fb_write writes to system memory,
so the generated code can use the respective helper internally.
This also fixes a long-standing bug where fb_write returned an
errno code instead of the number of written bytes. See the commit
message of commit 921b7383f348 ("fbdev: Return number of bytes
read or written") for more details.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/ssd1307fb.c | 69 ++---
1 file changed, 11 insertions(+), 58 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 11c373798279..a2b939342a4f 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -292,43 +292,6 @@ static int ssd1307fb_update_display(struct ssd1307fb_par
*par)
return ssd1307fb_update_rect(par, 0, 0, par->width, par->height);
}
-static ssize_t ssd1307fb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct ssd1307fb_par *par = info->par;
- unsigned long total_size;
- unsigned long p = *ppos;
- void *dst;
- int ret;
-
- if (!info->screen_buffer)
- return -ENODEV;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EINVAL;
-
- if (count + p > total_size)
- count = total_size - p;
-
- if (!count)
- return -EINVAL;
-
- dst = info->screen_buffer + p;
-
- if (copy_from_user(dst, buf, count))
- return -EFAULT;
-
- ret = ssd1307fb_update_display(par);
- if (ret < 0)
- return ret;
-
- *ppos += count;
-
- return count;
-}
-
static int ssd1307fb_blank(int blank_mode, struct fb_info *info)
{
struct ssd1307fb_par *par = info->par;
@@ -339,39 +302,29 @@ static int ssd1307fb_blank(int blank_mode, struct fb_info
*info)
return ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
}
-static void ssd1307fb_fillrect(struct fb_info *info, const struct fb_fillrect
*rect)
+static void ssd1307fb_defio_damage_range(struct fb_info *info, off_t off,
size_t len)
{
struct ssd1307fb_par *par = info->par;
- sys_fillrect(info, rect);
- ssd1307fb_update_rect(par, rect->dx, rect->dy, rect->width,
- rect->height);
-}
-static void ssd1307fb_copyarea(struct fb_info *info, const struct fb_copyarea
*area)
-{
- struct ssd1307fb_par *par = info->par;
- sys_copyarea(info, area);
- ssd1307fb_update_rect(par, area->dx, area->dy, area->width,
- area->height);
+ ssd1307fb_update_display(par);
}
-static void ssd1307fb_imageblit(struct fb_info *info, const struct fb_image
*image)
+static void ssd1307fb_defio_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
{
struct ssd1307fb_par *par = info->par;
- sys_imageblit(info, image);
- ssd1307fb_update_rect(par, image->dx, image->dy, image->width,
- image->height);
+
+ ssd1307fb_update_rect(par, x, y, width, height);
}
+FB_GEN_DEFAULT_DEFERRED_SYS_OPS(ssd1307fb,
+ ssd1307fb_defio_damage_range,
+ ssd1307fb_defio_damage_area)
+
static const struct fb_ops ssd1307fb_ops = {
.owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = ssd1307fb_write,
+ FB_DEFAULT_DEFERRED_OPS(ssd1307fb),
.fb_blank = ssd1307fb_blank,
- .fb_fillrect= ssd1307fb_fillrect,
- .fb_copyarea= ssd1307fb_copyarea,
- .fb_imageblit = ssd1307fb_imageblit,
- .fb_mmap= fb_deferred_io_mmap,
};
static void ssd1307fb_deferred_io(struct fb_info *info, struct list_head
*pagereflist)
--
2.41.0
[PATCH 07/10] fbdev/ssd1307fb: Select FB_SYS_HELPERS_DEFERRED
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that is required for deferred I/O on system-memory framebuffers. Select it from FB_SSD1307 in favor of the existing identical selection. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 1155d7aa0917..763316acfc02 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2211,12 +2211,8 @@ config FB_SSD1307 tristate "Solomon SSD1307 framebuffer support" depends on FB && I2C depends on GPIOLIB || COMPILE_TEST - select FB_SYS_FOPS - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_DEFERRED_IO select FB_BACKLIGHT + select FB_SYS_HELPERS_DEFERRED help This driver implements support for the Solomon SSD1307 OLED controller over I2C. -- 2.41.0
[PATCH 03/10] fbdev/hecubafb: Select FB_SYS_HELPERS_DEFERRED
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that is required for deferred I/O on system-memory framebuffers. Select it from FB_HECUBA. Deferred I/O helpers were previously selected by n411, which builds upon hecubafb. Remove these select statements in favor of the new one. N411 does not implement any framebuffer I/O by itself. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index fd862faafe66..7587f06cb793 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -200,7 +200,7 @@ config FB_SYS_HELPERS_DEFERRED config FB_HECUBA tristate depends on FB - depends on FB_DEFERRED_IO + select FB_SYS_HELPERS_DEFERRED config FB_SVGALIB tristate @@ -691,11 +691,6 @@ config FB_EFI config FB_N411 tristate "N411 Apollo/Hecuba devkit support" depends on FB && X86 && MMU - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO select FB_HECUBA help This enables support for the Apollo display controller in its -- 2.41.0
[PATCH 06/10] fbdev/metronomefb: Generate deferred I/O ops
Use the existing generator macros to create deferred-I/O helpers
for metronomefb and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Metronomefb's implementation of fb_write writes to system memory,
so the generated code can use the respective helper internally.
This also fixes a long-standing bug where fb_write returned an
errno code instead of the number of written bytes. See the commit
message of commit 921b7383f348 ("fbdev: Return number of bytes
read or written") for more details.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/metronomefb.c | 74 ---
1 file changed, 8 insertions(+), 66 deletions(-)
diff --git a/drivers/video/fbdev/metronomefb.c
b/drivers/video/fbdev/metronomefb.c
index 3e1daca76e11..667bef10738c 100644
--- a/drivers/video/fbdev/metronomefb.c
+++ b/drivers/video/fbdev/metronomefb.c
@@ -483,86 +483,28 @@ static void metronomefb_dpy_deferred_io(struct fb_info
*info, struct list_head *
metronome_display_cmd(par);
}
-static void metronomefb_fillrect(struct fb_info *info,
- const struct fb_fillrect *rect)
+static void metronomefb_defio_damage_range(struct fb_info *info, off_t off,
size_t len)
{
struct metronomefb_par *par = info->par;
- sys_fillrect(info, rect);
metronomefb_dpy_update(par);
}
-static void metronomefb_copyarea(struct fb_info *info,
- const struct fb_copyarea *area)
+static void metronomefb_defio_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
{
struct metronomefb_par *par = info->par;
- sys_copyarea(info, area);
metronomefb_dpy_update(par);
}
-static void metronomefb_imageblit(struct fb_info *info,
- const struct fb_image *image)
-{
- struct metronomefb_par *par = info->par;
-
- sys_imageblit(info, image);
- metronomefb_dpy_update(par);
-}
-
-/*
- * this is the slow path from userspace. they can seek and write to
- * the fb. it is based on fb_sys_write
- */
-static ssize_t metronomefb_write(struct fb_info *info, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct metronomefb_par *par = info->par;
- unsigned long p = *ppos;
- void *dst;
- int err = 0;
- unsigned long total_size;
-
- if (!info->screen_buffer)
- return -ENODEV;
-
- total_size = info->fix.smem_len;
-
- if (p > total_size)
- return -EFBIG;
-
- if (count > total_size) {
- err = -EFBIG;
- count = total_size;
- }
-
- if (count + p > total_size) {
- if (!err)
- err = -ENOSPC;
-
- count = total_size - p;
- }
-
- dst = info->screen_buffer + p;
-
- if (copy_from_user(dst, buf, count))
- err = -EFAULT;
-
- if (!err)
- *ppos += count;
-
- metronomefb_dpy_update(par);
-
- return (err) ? err : count;
-}
+FB_GEN_DEFAULT_DEFERRED_SYS_OPS(metronomefb,
+ metronomefb_defio_damage_range,
+ metronomefb_defio_damage_area)
static const struct fb_ops metronomefb_ops = {
- .owner = THIS_MODULE,
- .fb_write = metronomefb_write,
- .fb_fillrect= metronomefb_fillrect,
- .fb_copyarea= metronomefb_copyarea,
- .fb_imageblit = metronomefb_imageblit,
- .fb_mmap= fb_deferred_io_mmap,
+ .owner = THIS_MODULE,
+ FB_DEFAULT_DEFERRED_OPS(metronomefb),
};
static struct fb_deferred_io metronomefb_defio = {
--
2.41.0
[PATCH 10/10] fbdev/xen-fbfront: Generate deferred I/O ops
Use the existing generator macros to create deferred-I/O helpers
for xen-fbfront and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Xen-fbfront's implementation of fb_write writes to system memory,
so the generated code can use the respective helper internally.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/xen-fbfront.c | 61 ++-
1 file changed, 20 insertions(+), 41 deletions(-)
diff --git a/drivers/video/fbdev/xen-fbfront.c
b/drivers/video/fbdev/xen-fbfront.c
index 9b2a786621a6..6664dc7a5a41 100644
--- a/drivers/video/fbdev/xen-fbfront.c
+++ b/drivers/video/fbdev/xen-fbfront.c
@@ -240,41 +240,6 @@ static int xenfb_setcolreg(unsigned regno, unsigned red,
unsigned green,
return 0;
}
-static void xenfb_fillrect(struct fb_info *p, const struct fb_fillrect *rect)
-{
- struct xenfb_info *info = p->par;
-
- sys_fillrect(p, rect);
- xenfb_refresh(info, rect->dx, rect->dy, rect->width, rect->height);
-}
-
-static void xenfb_imageblit(struct fb_info *p, const struct fb_image *image)
-{
- struct xenfb_info *info = p->par;
-
- sys_imageblit(p, image);
- xenfb_refresh(info, image->dx, image->dy, image->width, image->height);
-}
-
-static void xenfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
-{
- struct xenfb_info *info = p->par;
-
- sys_copyarea(p, area);
- xenfb_refresh(info, area->dx, area->dy, area->width, area->height);
-}
-
-static ssize_t xenfb_write(struct fb_info *p, const char __user *buf,
- size_t count, loff_t *ppos)
-{
- struct xenfb_info *info = p->par;
- ssize_t res;
-
- res = fb_sys_write(p, buf, count, ppos);
- xenfb_refresh(info, 0, 0, info->page->width, info->page->height);
- return res;
-}
-
static int
xenfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info)
{
@@ -326,17 +291,31 @@ static int xenfb_set_par(struct fb_info *info)
return 0;
}
+static void xenfb_defio_damage_range(struct fb_info *info, off_t off, size_t
len)
+{
+ struct xenfb_info *xenfb_info = info->par;
+
+ xenfb_refresh(xenfb_info, 0, 0, xenfb_info->page->width,
xenfb_info->page->height);
+}
+
+static void xenfb_defio_damage_area(struct fb_info *info, u32 x, u32 y,
+ u32 width, u32 height)
+{
+ struct xenfb_info *xenfb_info = info->par;
+
+ xenfb_refresh(xenfb_info, x, y, width, height);
+}
+
+FB_GEN_DEFAULT_DEFERRED_SYS_OPS(xenfb,
+ xenfb_defio_damage_range,
+ xenfb_defio_damage_area)
+
static const struct fb_ops xenfb_fb_ops = {
.owner = THIS_MODULE,
- .fb_read= fb_sys_read,
- .fb_write = xenfb_write,
+ FB_DEFAULT_DEFERRED_OPS(xenfb),
.fb_setcolreg = xenfb_setcolreg,
- .fb_fillrect= xenfb_fillrect,
- .fb_copyarea= xenfb_copyarea,
- .fb_imageblit = xenfb_imageblit,
.fb_check_var = xenfb_check_var,
.fb_set_par = xenfb_set_par,
- .fb_mmap= fb_deferred_io_mmap,
};
static irqreturn_t xenfb_event_handler(int rq, void *dev_id)
--
2.41.0
[PATCH 01/10] fbdev/broadsheetfb: Select FB_SYS_HELPERS_DEFERRED
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that is required for deferred I/O on system-memory framebuffers. Select it from FB_BROADSHEET in favor of the existing identical selection. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index f14229757311..fd862faafe66 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2179,11 +2179,7 @@ config FB_MX3 config FB_BROADSHEET tristate "E-Ink Broadsheet/Epson S1D13521 controller support" depends on FB && (ARCH_PXA || COMPILE_TEST) - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYS_HELPERS_DEFERRED help This driver implements support for the E-Ink Broadsheet controller. The release name for this device was Epson S1D13521 -- 2.41.0
[PATCH 09/10] fbdev/xen-fbfront: Select FB_SYS_HELPERS_DEFERRED
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that is required for deferred I/O on system-memory framebuffers. Select it from XEN_FBDEV_FRONTEND in favor of the existing identical selection. Signed-off-by: Thomas Zimmermann --- drivers/video/fbdev/Kconfig | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig index 763316acfc02..ec2abe882ed9 100644 --- a/drivers/video/fbdev/Kconfig +++ b/drivers/video/fbdev/Kconfig @@ -2073,11 +2073,7 @@ config FB_VIRTUAL config XEN_FBDEV_FRONTEND tristate "Xen virtual frame buffer support" depends on FB && XEN - select FB_SYS_FILLRECT - select FB_SYS_COPYAREA - select FB_SYS_IMAGEBLIT - select FB_SYS_FOPS - select FB_DEFERRED_IO + select FB_SYS_HELPERS_DEFERRED select XEN_XENBUS_FRONTEND default y help -- 2.41.0
