Re: [Proposal] drm: amd: Convert logging to drm_* functions with drm_device parameter
On Mon, Jul 06, 2020 at 04:21:38PM +0530, Suraj Upadhyay wrote: > Hii Maintainers, > I recently came across this list of janatorial tasks > for starters on DRM subsystem [1]. One of the tasks is replacing > conventional dmesg macros (like dev_info(), dev_warn() and dev_err()) > with DRM dmesg macros [2]. And I need your input whether the > conversions to DRM dmesg macros are worth it or not. > I would like to start working on this task if this needs the change. For any core code I'm happy to merge such patches. If you're changing a specific driver (all the subdirectories under drivers/gpu/drm/*) then please ping the specific driver maintainer first. They should be all listed in the MAINTAINERS file. Cheers, Daniel > > Thank you, > Suraj Upadhyay. > > [1] https://dri.freedesktop.org/docs/drm/gpu/todo.html. > [2] > https://dri.freedesktop.org/docs/drm/gpu/todo.html#convert-logging-to-drm-functions-with-drm-device-paramater > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 17/20] backlight: use backligt_get_brightness()
On Fri, Jul 03, 2020 at 08:45:43PM +0200, Sam Ravnborg wrote:
> Introduce the backlight_get_brightness() helper in all
> video/backlight/* drivers.
> This simplifies the code and align the implementation of the
> update_status() operation across the different backlight drivers.
>
> Some of the drivers gains a little extra functionality by the change
> as they now respect the fb_blank() ioctl.
>
> Signed-off-by: Sam Ravnborg
This looks really nice!
Since there's a pile more backlight drivers all over the tree, care to
update the gpu/todo.rst entry with a note that conversions should use
backlight_get_brightness?
-Daniel
> ---
> drivers/video/backlight/88pm860x_bl.c | 13 +
> drivers/video/backlight/adp5520_bl.c | 10 +-
> drivers/video/backlight/adp8860_bl.c | 10 +-
> drivers/video/backlight/adp8870_bl.c | 10 +-
> drivers/video/backlight/bd6107.c | 7 +--
> drivers/video/backlight/corgi_lcd.c | 8 +---
> drivers/video/backlight/da903x_bl.c | 13 +
> drivers/video/backlight/ep93xx_bl.c | 8 +---
> drivers/video/backlight/hp680_bl.c| 6 +-
> drivers/video/backlight/kb3886_bl.c | 6 +-
> drivers/video/backlight/led_bl.c | 7 +--
> drivers/video/backlight/lm3533_bl.c | 8 +---
> drivers/video/backlight/locomolcd.c | 6 +-
> drivers/video/backlight/lv5207lp.c| 7 +--
> drivers/video/backlight/max8925_bl.c | 13 +
> drivers/video/backlight/pwm_bl.c | 7 +--
> drivers/video/backlight/qcom-wled.c | 7 +--
> drivers/video/backlight/tps65217_bl.c | 10 +-
> drivers/video/backlight/wm831x_bl.c | 13 +
> 19 files changed, 19 insertions(+), 150 deletions(-)
>
> diff --git a/drivers/video/backlight/88pm860x_bl.c
> b/drivers/video/backlight/88pm860x_bl.c
> index 20d96a5ac384..25e409bbb1a2 100644
> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -121,18 +121,7 @@ static int pm860x_backlight_set(struct backlight_device
> *bl, int brightness)
>
> static int pm860x_backlight_update_status(struct backlight_device *bl)
> {
> - int brightness = bl->props.brightness;
> -
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.state & BL_CORE_SUSPENDED)
> - brightness = 0;
> -
> - return pm860x_backlight_set(bl, brightness);
> + return pm860x_backlight_set(bl, backlight_get_brightness(bl));
> }
>
> static int pm860x_backlight_get_brightness(struct backlight_device *bl)
> diff --git a/drivers/video/backlight/adp5520_bl.c
> b/drivers/video/backlight/adp5520_bl.c
> index 0f63f76723a5..686988c3df3a 100644
> --- a/drivers/video/backlight/adp5520_bl.c
> +++ b/drivers/video/backlight/adp5520_bl.c
> @@ -65,15 +65,7 @@ static int adp5520_bl_set(struct backlight_device *bl, int
> brightness)
>
> static int adp5520_bl_update_status(struct backlight_device *bl)
> {
> - int brightness = bl->props.brightness;
> -
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - return adp5520_bl_set(bl, brightness);
> + return adp5520_bl_set(bl, backlight_get_brightness(bl));
> }
>
> static int adp5520_bl_get_brightness(struct backlight_device *bl)
> diff --git a/drivers/video/backlight/adp8860_bl.c
> b/drivers/video/backlight/adp8860_bl.c
> index 19968104fc47..ddc7f5f0401f 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -361,15 +361,7 @@ static int adp8860_bl_set(struct backlight_device *bl,
> int brightness)
>
> static int adp8860_bl_update_status(struct backlight_device *bl)
> {
> - int brightness = bl->props.brightness;
> -
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - return adp8860_bl_set(bl, brightness);
> + return adp8860_bl_set(bl, backlight_get_brightness(bl));
> }
>
> static int adp8860_bl_get_brightness(struct backlight_device *bl)
> diff --git a/drivers/video/backlight/adp8870_bl.c
> b/drivers/video/backlight/adp8870_bl.c
> index 4c0032010cfe..8b5213a39527 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -399,15 +399,7 @@ static int adp8870_bl_set(struct backlight_device *bl,
> int brightness)
>
> static int adp8870_bl_update_status(struct backlight_device *bl)
> {
> - int brightness = bl->props.brightness;
> -
> - if (bl->props.power != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - if (bl->props.fb_blank != FB_BLANK_UNBLANK)
> - brightness = 0;
> -
> - return adp8870_bl_set(bl, brightness);
> +
Re: [PATCH v4 02/20] backlight: add backlight_is_blank()
On Fri, Jul 03, 2020 at 08:45:28PM +0200, Sam Ravnborg wrote:
> The backlight support has two properties that express the state:
> - power
> - state
Tiny nit, but please add "fb_blank" here too, commit message doesn't match
the code anymore. With that:
Reviewed-by: Daniel Vetter
>
> It is un-documented and easy to get wrong.
> Add backlight_is_blank() helper to make it simpler
> for drivers to get the check of the state correct.
>
> A lot of drivers also includes checks for fb_blank.
> This check is redundant when the state is checked
> and thus not needed in this helper function.
> But added anyway to avoid introducing subtle bugs
> due to the creative use of fb_blank in some drivers.
> Introducing this helper will for some drivers results in
> added support for fb_blank. This will be a change in
> functionality, which will improve the backlight driver.
>
> Rolling out this helper to all relevant backlight drivers
> will eliminate almost all accesses to fb_blank.
>
> v4:
> - struct backlight_device * is now const
>
> v3:
> - Clarified that the fb_blank support in
> backlight_is_blank() may result in functionality
> changes for the users (Emil)
>
> v2:
> - Added fb_blank condition (Daniel)
>
> Signed-off-by: Sam Ravnborg
> Reviewed-by: Daniel Thompson
> Reviewed-by: Peter Ujfalusi
> Reviewed-by: Emil Velikov
> Cc: Emil Velikov
> Cc: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
> include/linux/backlight.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 56e4580d4f55..56e51ebab740 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -175,6 +175,25 @@ static inline void backlight_put(struct backlight_device
> *bd)
> put_device(>dev);
> }
>
> +/**
> + * backlight_is_blank - Return true if display is expected to be blank
> + * @bd: the backlight device
> + *
> + * Display is expected to be blank if any of these is true::
> + *
> + * 1) if power in not UNBLANK
> + * 2) if fb_blank is not UNBLANK
> + * 3) if state indicate BLANK or SUSPENDED
> + *
> + * Returns true if display is expected to be blank, false otherwise.
> + */
> +static inline bool backlight_is_blank(const struct backlight_device *bd)
> +{
> + return bd->props.power != FB_BLANK_UNBLANK ||
> +bd->props.fb_blank != FB_BLANK_UNBLANK ||
> +bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
> +}
> +
> extern struct backlight_device *backlight_device_register(const char *name,
> struct device *dev, void *devdata, const struct backlight_ops *ops,
> const struct backlight_properties *props);
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/msm: dsi: Use OPP API to set clk/perf state
On 7/6/2020 9:40 PM, Matthias Kaehlcke wrote:
On Thu, Jul 02, 2020 at 04:39:09PM +0530, Rajendra Nayak wrote:
On SDM845 and SC7180 DSI needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
dev_pm_opp_set_rate() is designed to be equivalent to clk_set_rate()
for devices without an OPP table, hence the change works fine
on devices/platforms which only need to set a clock rate.
Signed-off-by: Rajendra Nayak
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..09e16b8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -111,6 +112,9 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
+ struct opp_table *opp_table;
+ bool has_opp_table;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -512,9 +516,10 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
DBG("Set clk rates: pclk=%d, byteclk=%d",
msm_host->mode->clock, msm_host->byte_clk_rate);
- ret = clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);
+ ret = dev_pm_opp_set_rate(_host->pdev->dev,
+ msm_host->byte_clk_rate);
if (ret) {
- pr_err("%s: Failed to set rate byte clk, %d\n", __func__, ret);
+ pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
return ret;
}
@@ -658,6 +663,8 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
{
+ /* Drop the performance state vote */
+ dev_pm_opp_set_rate(_host->pdev->dev, 0);
clk_disable_unprepare(msm_host->esc_clk);
clk_disable_unprepare(msm_host->pixel_clk);
if (msm_host->byte_intf_clk)
@@ -1879,6 +1886,18 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
+ msm_host->opp_table = dev_pm_opp_set_clkname(>dev, "byte");
+ if (IS_ERR(msm_host->opp_table))
+ return PTR_ERR(msm_host->opp_table);
+ /* OPP table is optional */
+ ret = dev_pm_opp_of_add_table(>dev);
+ if (!ret) {
+ msm_host->has_opp_table = true;
+ } else if (ret != -ENODEV) {
+ dev_err(>dev, "invalid OPP table in device tree\n");
dev_pm_opp_put_clkname(msm_host->opp_table);
+ return ret;
+ }
With the missing _put_clkname() fixed:
Thanks, I'll fix and resend.
Reviewed-by: Matthias Kaehlcke
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 Christopher Snowhill (kod...@gmail.com) changed: What|Removed |Added CC||kod...@gmail.com --- Comment #43 from Christopher Snowhill (kod...@gmail.com) --- What about this patch? https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.8=6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/9] drm/vc4: Turn the TXP into a CRTC
On Tue, Jun 30, 2020 at 1:25 AM Maxime Ripard wrote: > > Hi Eric, > > On Thu, Jun 11, 2020 at 03:36:45PM +0200, Maxime Ripard wrote: > > Hi, > > > > This is another part of the rpi4 HDMI series that got promoted to a > > series of its own to try to reduce the main one. > > > > This rework is needed since the bcm2711 used in the rpi4 has a more > > complex routing in the HVS that doesn't allow to use a fairly simple > > mapping like what was used before. > > > > Since that mapping affects both the pixelvalves and the TXP, turning the > > TXP into a CRTC just like pixelvalves are allows to deal with the > > mapping in the CRTC states, which turns out to be pretty convenient. > > > > Let me know what you think, > > Maxime > > > > Changes from v3: > > - Stripped the patches out of the main HDMI series > > - Change the bind order of the HVS to avoid a compatible check > > - Added Eric's tags > > - Rebased on top of drm-misc-next > > > > Maxime Ripard (9): > > drm/vc4: Reorder the bind order of the devices > > drm/vc4: crtc: Move HVS setup code to the HVS driver > > Could you review those two patches? You haven't reviewed them yet and > it's holding back the rest of the patches. LKML email workflow is the worst, the patches never came through to me so I didn't see them until you linked me the patchwork. Patch 2, commit message should say "We'll need the HVS to be bound before the TXP", but other than that, r-b. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #42 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Alex Deucher from comment #40) > Does this patch help? No. v5.7 with the patch applied gave me the same graphics freeze, with the usual log trace confirming it's _this_ bug. Sigh, back to the bisect. =:^( -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #41 from Duncan (1i5t5.dun...@cox.net) --- (In reply to Alex Deucher from comment #40) > Does this patch help? Booted to v5.7 with it applied now. We'll see. Since the bug can take awhile to trigger on my hardware, if the patch fixes it I won't know for days, and won't be /sure/ for say a week, the reason bisecting was taking so long. (It wouldn't apply to current 5.8-rc4-plus-an-s390-pull. Too tired to figure out why ATM but if it's because it was there already, hopefully it was pulled in after v5.8-rc3 as I tested that and got the same graphics freeze with the characteristic trace, so if the patch was already in v5.8-rc3, it does /not/ fix the bug.) As for bisecting, I've hard-crashed twice on the current step, apparently with a different bug, so while _this_ bug hasn't seemed to trigger yet, I haven't gotten the necessary confidence that it's a bisect-good. So hopefully this patch /does/ fix it, and I can put this entirely too frustrating bug-bisect behind me! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 8/8] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
Hi, Dennis:
Dennis YC Hsieh 於 2020年7月6日 週一 下午3:20寫道：
>
> Add clear parameter to let client decide if
> event should be clear to 0 after GCE receive it.
>
> Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ control flow")
I think this patch include two things, one is bug fix, another is
changing interface.
below is the bug fix part.
-#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE |
CMDQ_WFE_WAIT | \
- CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT |
CMDQ_WFE_WAIT_VALUE)
the other is changing interface part. So this patch should be broken
into two patches.
Regards,
Chun-Kuang.
> Signed-off-by: Dennis YC Hsieh
> Reviewed-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
> drivers/soc/mediatek/mtk-cmdq-helper.c |5 +++--
> include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
> include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
> 4 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index ec6c9ffbf35e..ba6cf956b239 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
> *mtk_crtc)
> mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
> cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client,
> PAGE_SIZE);
> cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> - cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> + cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
> mtk_crtc_ddp_config(crtc, cmdq_handle);
> cmdq_pkt_finalize(cmdq_handle);
> cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
> b/drivers/soc/mediatek/mtk-cmdq-helper.c
> index d55dc3296105..505651b0d715 100644
> --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> @@ -316,15 +316,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt,
> u8 high_addr_reg_idx,
> }
> EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
>
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
> {
> struct cmdq_instruction inst = { {0} };
> + u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
>
> if (event >= CMDQ_MAX_EVENT)
> return -EINVAL;
>
> inst.op = CMDQ_CODE_WFE;
> - inst.value = CMDQ_WFE_OPTION;
> + inst.value = CMDQ_WFE_OPTION | clear_option;
> inst.event = event;
>
> return cmdq_pkt_append_command(pkt, inst);
> diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
> b/include/linux/mailbox/mtk-cmdq-mailbox.h
> index efbd8a9eb2d1..d5a983d65f05 100644
> --- a/include/linux/mailbox/mtk-cmdq-mailbox.h
> +++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
> @@ -28,8 +28,7 @@
> * bit 16-27: update value
> * bit 31: 1 - update, 0 - no update
> */
> -#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE |
> CMDQ_WFE_WAIT | \
> - CMDQ_WFE_WAIT_VALUE)
> +#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT |
> CMDQ_WFE_WAIT_VALUE)
>
> /** cmdq event maximum */
> #define CMDQ_MAX_EVENT 0x3ff
> diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
> b/include/linux/soc/mediatek/mtk-cmdq.h
> index 34354e952f60..960704d75994 100644
> --- a/include/linux/soc/mediatek/mtk-cmdq.h
> +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> @@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt,
> u8 high_addr_reg_idx,
> /**
> * cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
> * @pkt: the CMDQ packet
> - * @event: the desired event type to "wait and CLEAR"
> + * @event: the desired event type to wait
> + * @clear: clear event or not after event arrive
> *
> * Return: 0 for success; else the error code is returned
> */
> -int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
> +int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
>
> /**
> * cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
> --
> 1.7.9.5
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: rockchip: add NV15, NV20 and NV30 support
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V2: Added NV30 support
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 +
3 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..eb663e25ad9e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -261,6 +261,18 @@ static bool has_rb_swapped(uint32_t format)
}
}
+static bool is_fmt_10(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_NV15:
+ case DRM_FORMAT_NV20:
+ case DRM_FORMAT_NV30:
+ return true;
+ default:
+ return false;
+ }
+}
+
static enum vop_data_format vop_convert_format(uint32_t format)
{
switch (format) {
@@ -276,10 +288,13 @@ static enum vop_data_format vop_convert_format(uint32_t
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV15:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV20:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+ case DRM_FORMAT_NV30:
return VOP_FMT_YUV444SP;
default:
DRM_ERROR("unsupported format[%08x]\n", format);
@@ -922,7 +937,12 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
- offset = (src->x1 >> 16) * fb->format->cpp[0];
+ if (fb->format->block_w[0])
+ offset = (src->x1 >> 16) * fb->format->char_per_block[0] /
+fb->format->block_w[0];
+ else
+ offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
@@ -948,6 +968,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
VOP_WIN_SET(vop, win, format, format);
+ VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -964,7 +985,11 @@ static void vop_plane_atomic_update(struct drm_plane
*plane,
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
- offset = (src->x1 >> 16) * bpp / hsub;
+ if (fb->format->block_w[1])
+ offset = (src->x1 >> 16) * bpp /
+fb->format->block_w[1] / hsub;
+ else
+ offset = (src->x1 >> 16) * bpp / hsub;
offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 4a2099cb582e..eab055d9b56d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -154,6 +154,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+ struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg act_info;
struct vop_reg dsp_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 80053d91a301..2c55e1852c3d 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -50,6 +50,23 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV24,
};
+static const uint32_t formats_win_full_10[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_BGR565,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_NV16,
+ DRM_FORMAT_NV24,
+ DRM_FORMAT_NV15,
+ DRM_FORMAT_NV20,
+ DRM_FORMAT_NV30,
+};
+
static const uint64_t format_modifiers_win_full[] = {
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
@@ -579,11 +596,12 @@ static const struct vop_scl_regs rk3288_win_full_scl = {
static const struct vop_win_phy rk3288_win01_data = {
.scl = _win_full_scl,
- .data_formats = formats_win_full,
- .nformats =
[PATCH v2 0/2] drm: rockchip: add NV15, NV20 and NV30 support
Hi, This series adds support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399. Also include 10-bit 4:4:4 support since VOP can support that also. First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling. Second patch adds support for displaying the the new fourcc formats. Changes in v2: - Add NV30 format - R-B tags was not collected due to NV30 changes This series has been tested on RK3399 using a Rockchip Video Decoder series at [1] together with ffmpeg at [2] and kodi-gbm or mpv. [3] contains all patches needed on top of linux-media master for easy testing. [1] https://patchwork.linuxtv.org/project/linux-media/list/?series=2859 [2] https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3-rkvdec-high-10 [3] https://github.com/Kwiboo/linux-rockchip/commits/linuxtv-rkvdec-high-10-v2 Regards, Jonas Jonas Karlman (2): drm: drm_fourcc: add NV20 and NV30 YUV formats drm: rockchip: add NV15, NV20 and NV30 support drivers/gpu/drm/drm_fourcc.c| 8 ++ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 29 +-- drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 + drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 32 + include/uapi/drm/drm_fourcc.h | 2 ++ 5 files changed, 64 insertions(+), 8 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm: drm_fourcc: add NV20 and NV30 YUV formats
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:
= UVUV = 4 * 10 bits = 40 bits = 5 bytes
The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.
V2: Added NV30 format
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/drm_fourcc.c | 8
include/uapi/drm/drm_fourcc.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 722c7ebe4e88..2daf8a304b53 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -278,6 +278,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
.num_planes = 2, .char_per_block = { 5, 5, 0 },
.block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
.vsub = 2, .is_yuv = true },
+ { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+ { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
.num_planes = 3, .char_per_block = { 2, 2, 2 },
.block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index cbf92fdf2712..c8695673295c 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -242,6 +242,8 @@ extern "C" {
* index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
*/
#define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /*
non-subsampled Cr:Cb plane */
/*
* 2 plane YCbCr MSB aligned
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208443] [amdpgu] NAVI10 shutting second display off causes video corruption/crash on kernels >=5.7.6
https://bugzilla.kernel.org/show_bug.cgi?id=208443 mikkl (ironmi...@gmx.net) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE --- Comment #3 from mikkl (ironmi...@gmx.net) --- (In reply to Alex Deucher from comment #2) > Likely fixed by: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 Applied on 5.7.7. For now, this seems to work for me, thanks! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 11/15] pwm: crc: Implement get_state() method
Hi,
On 6/22/20 9:57 AM, Uwe Kleine-König wrote:
On Sat, Jun 20, 2020 at 02:17:54PM +0200, Hans de Goede wrote:
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v3:
- Add Andy's Reviewed-by tag
- Remove extra whitespace to align some code after assignments (requested by
Uwe Kleine-König)
---
drivers/pwm/pwm-crc.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 8a7f4707279c..b311354d40a3 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -119,8 +119,37 @@ static int crc_pwm_apply(struct pwm_chip *chip, struct
pwm_device *pwm,
return 0;
}
+static void crc_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct crystalcove_pwm *crc_pwm = to_crc_pwm(chip);
+ struct device *dev = crc_pwm->chip.dev;
+ unsigned int clk_div, clk_div_reg, duty_cycle_reg;
+ int error;
+
+ error = regmap_read(crc_pwm->regmap, PWM0_CLK_DIV, _div_reg);
+ if (error) {
+ dev_err(dev, "Error reading PWM0_CLK_DIV %d\n", error);
+ return;
+ }
+
+ error = regmap_read(crc_pwm->regmap, PWM0_DUTY_CYCLE, _cycle_reg);
+ if (error) {
+ dev_err(dev, "Error reading PWM0_DUTY_CYCLE %d\n", error);
+ return;
+ }
+
+ clk_div = (clk_div_reg & ~PWM_OUTPUT_ENABLE) + 1;
+
+ state->period = clk_div * NSEC_PER_USEC * 256 / PWM_BASE_CLK_MHZ;
+ state->duty_cycle = duty_cycle_reg * state->period / PWM_MAX_LEVEL;
Please round up here.
Ok, I can fix that for the next version of this patch-set. Before I
post a new version of this patch-set, you have only responded to
some of the PWM patches in this set. Do you have any remarks on the
other PWM patches ?
Regards,
Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 09/15] pwm: crc: Enable/disable PWM output on enable/disable
Hi, On 6/22/20 9:55 AM, Uwe Kleine-König wrote: Hello, [adding Shobhit Kumar to Cc who is the author of this driver according to the comment on the top of the driver] On Sat, Jun 20, 2020 at 02:17:52PM +0200, Hans de Goede wrote: The pwm-crc code is using 2 different enable bits: 1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE) 2. bit 0 of the BACKLIGHT_EN register So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM, this commit makes crc_pwm_disable() clear it on disable and makes crc_pwm_enable() set it again on re-enable. Signed-off-by: Hans de Goede --- Changes in v3: - Remove paragraph about tri-stating the output from the commit message, we don't have a datasheet so this was just an unfounded guess I have the impression you spend quite some time with this driver trying to understand it. Yes, my initial plan for this patch series was to just convert this driver to atomic PWM, but it turned out to need a bit of TLC first. What I still think is a bit unfortunate is that there is quite some guesswork involved. Actually for 99% of the changes I'm pretty sure they are correct. This patch is the 1% where I'm not sure, and in this case I'm playing it safe by keeping the code as is. As the commit message tries to explain I strongly suspect that bit 0 of the BACKLIGHT_EN register really drives a separate GPIO pin on the PMIC which is earmarked as backlight-enable pin (many LCD panels have both a pwm input for brightness-level and a separate enable/disable pin). If we can get information that my hunch here is correct then the right thing to do would be to change things so that the PWM driver stops poking bit 0 of the BACKLIGHT_EN register and this gets done by the CRC GPIO driver instead. But the poking of that bit is already happening now and since I'm not 100% sure that my hunch is correct, the safe thing to do is to keep this as is. Note that for the main consumer of the CRC PWM, the i915 driver it does not matter. If we change that bit into a GPIO then the i915 drv will need to be modified to drive the GPIO high / low when enabling / disabling the panel. Just like it already enables/ disables the PWM when enabling / disabling the panel. So the end result will still be bit 0 of the BACKLIGHT_EN register going high/low on LCD panel enable/disable. So even if my hunch is right functionality wise nothing will change. The code doing the poking will be technically more correct, but that is all that we would gain. I wonder if it would be possible to get the manual of that PWM. Do I understand correctly that this is IP from Intel? There are quite some Intel people on Cc; maybe someone can help/put in a good word/check and ack the changes? IIRC last time I asked no one from the Intel folks on the Cc has access to the Crystal Cove PMIC datasheet. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/15] acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the atomic PWM API
Hi, On 6/30/20 3:51 PM, Jani Nikula wrote: On Sat, 20 Jun 2020, Hans de Goede wrote: Hi All, Here is v3 of my patch series converting the i915 driver's code for controlling the panel's backlight with an external PWM controller to use the atomic PWM API. See below for the changelog. Initially the plan was for this series to consist of 2 parts: 1. convert the pwm-crc driver to support the atomic PWM API and 2. convert the i915 driver's PWM code to use the atomic PWM API. But during testing I've found a number of bugs in the pwm-lpss and I found that the acpi_lpss code needs some special handling because of some ugliness found in most Cherry Trail DSDTs. So now this series has grown somewhat large and consists of 4 parts: 1. acpi_lpss fixes workarounds for Cherry Trail DSTD nastiness 2. various fixes to the pwm-lpss driver 3. convert the pwm-crc driver to support the atomic PWM API and 4. convert the i915 driver's PWM code to use the atomic PWM API So we need to discuss how to merge this (once it passes review). Although the inter-dependencies are only runtime I still think we should make sure that 1-3 are in the drm-intel-next-queued (dinq) tree before merging the i915 changes. Both to make sure that the intel-gfx CI system does not become unhappy and for bisecting reasons. The involved acpi_lpss and pwm drivers do not see a whole lot of churn, so it likely is the easiest to just merge everything through dinq. Rafael and Thierry, can I get your Acked-by for directly merging this into dinq? This series has been tested (and re-tested after adding various bug-fixes) extensively. It has been tested on the following devices: -Asus T100TA BYT + CRC-PMIC PWM -Toshiba WT8-A BYT + CRC-PMIC PWM -Thundersoft TS178 BYT + CRC-PMIC PWM, inverse PWM -Asus T100HA CHT + CRC-PMIC PWM -Terra Pad 1061 BYT + LPSS PWM -Trekstor Twin 10.1 BYT + LPSS PWM -Asus T101HA CHT + CRC-PMIC PWM -GPD Pocket CHT + CRC-PMIC PWM For the drm/i915 patches 12-15, Acked-by: Jani Nikula I eyeballed through them, and didn't spot anything obviously wrong, but at the same time didn't have the time to do an in-depth review. That said, I do have a lot of trust in you testing this with all the above devices. I think that's enough for merging. As for that matter, I'm fine with merging this via whichever tree you find best. Kind of stating the obvious, but please do ensure you have the proper acks in place for this. Thank you. I plan to push the entire series to dinq once I have a full set of acks for the PWM changes (I already have acks for the rest). Regards, Hans Changelog: Changes in v2: - Fix coverletter subject - Drop accidentally included debugging patch - "[PATCH v3 02/15] ACPI / LPSS: Save Cherry Trail PWM ctx registers only once ( - Move #define LPSS_SAVE_CTX_ONCE define to group it with LPSS_SAVE_CTX Changes in v3: - "[PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value" - Use base_unit_range - 1 as maximum value for the clamp() - "[PATCH v3 05/15] pwm: lpss: Use pwm_lpss_apply() when restoring state on resume" - This replaces the "pwm: lpss: Set SW_UPDATE bit when enabling the PWM" patch from previous versions of this patch-set, which really was a hack working around the resume issue which this patch fixes properly. - PATCH v3 6 - 11 pwm-crc changes: - Various small changes resulting from the reviews by Andy and Uwe, including some refactoring of the patches to reduce the amount of churn in the patch-set Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/15] pwm: lpss: Add range limit check for the base_unit register value
Hi,
Thank you for your review and sorry for the slow reply.
I would like to get this series upstream this cycle, so
I will do my best to be a lot faster with responding from
now on.
On 6/22/20 9:35 AM, Uwe Kleine-König wrote:
On Sat, Jun 20, 2020 at 02:17:47PM +0200, Hans de Goede wrote:
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency. Adding 0
to the counter is a no-op. The data-sheet even explicitly states that
writing 0 to the base_unit bits will result in the PWM outputting a
continuous 0 signal.
When the user requestes a low enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value
which is bigger then base_unit_range - 1. Currently the codes for this
deals with this by applying a mask:
base_unit &= (base_unit_range - 1);
But this means that we let the value overflow the range, we throw away the
higher bits and store whatever value is left in the lower bits into the
register leading to a random output frequency, rather then clamping the
output frequency to the highest frequency which the hardware can do.
This commit fixes both issues by clamping the base_unit value to be
between 1 and (base_unit_range - 1).
Fixes: 684309e5043e ("pwm: lpss: Avoid potential overflow of base_unit")
Signed-off-by: Hans de Goede
---
Changes in v3:
- Change upper limit of clamp to (base_unit_range - 1)
- Add Fixes tag
---
drivers/pwm/pwm-lpss.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-lpss.c b/drivers/pwm/pwm-lpss.c
index 43b1fc634af1..80d0f9c64f9d 100644
--- a/drivers/pwm/pwm-lpss.c
+++ b/drivers/pwm/pwm-lpss.c
@@ -97,6 +97,9 @@ static void pwm_lpss_prepare(struct pwm_lpss_chip *lpwm,
struct pwm_device *pwm,
freq *= base_unit_range;
base_unit = DIV_ROUND_CLOSEST_ULL(freq, c);
DIV_ROUND_CLOSEST_ULL is most probably wrong, too. But I didn't spend
the time to actually confirm that.
Yes I saw your comment elsewhere that the PWM API defines rounding
in a certain direction, but fixing that falls outside of this patch.
+ /* base_unit must not be 0 and we also want to avoid overflowing it */
+ base_unit = clamp_t(unsigned long long, base_unit, 1,
+ base_unit_range - 1);
.get_state seems to handle base_unit == 0 just fine?!
It tries to do something with it to avoid a divide by 0, back when
I wrote the get_state code I wasn't fully aware of how the PWM
controller works. I did have access to the same datasheets as today
(the datasheets for this one are public) but the datasheet needs to
be read and then left to sync in for a couple of months and then read
again, or iow the datasheet does not explain things all that well.
As I tried to explain in the commit msg the way this PWM controller
works is it takes its input clock and then each input clock-cycle the
"base_unit" gets added to a n-bit register lets say a 16-bit register
at that is the case for the HW on which I've done all my testing.
The 8 most significant bits of the 16 bit register are compared with
a 8 bit value programmed by the PWM driver / coming from a ctrl
register and the output of that comparator is the PWM output.
The problem with a base_unit value of '0' is that adding 0 to the
16 bit register is a no-op, so the register never increments
(iow is always 0) and thus can never become bigger then the comparator
input and thus the PWM output is always 0.
The datasheet does helpfully contain a note explicitly warning of
this behavior.
So when we are programming the base_unit value, it seems best to
clamp the lower end to 1, which gives an PWM output frequency of
e.g. 1920 / 65536 = 293 Hz
If the user has request an even lower output frequency, which
would result in our base_unit calculation outputting 0, then we
can either output always low, which is an infinite low output
frequency, or give the user 293 Hz and a working PWM.
This is the low end of the clamp. The high end clamp simply is
there because base_unit itself is e.g. a 16 bit value too.
The looks a bid weird because instead of 65536 (for the divides)
/ 65535 (for the clamp / masking) it uses base_unit_range and
(base_unit_range - 1). This is because different versions of
the SoCs using this driver have a different register size for the
base_unit value.
I hope this helps to explain what is going on a bit.
###
As for the behavior on base_unit==0 in the get_state method,
as mentioned above I wrote that when I did not fully understood
how the controller works.
We really should never encounter this.
But if we do then I think closest to the truth would be:
state->period = UINT_MAX;
state->duty_cycle = 0;
I can submit a separate
Re: Panic booting qemu-system-sparc64 with bochs_drm
On 04/07/2020 15:52, Sam Ravnborg wrote:
> Hi Mark.
>
> On Sat, Jul 04, 2020 at 03:16:47PM +0100, Mark Cave-Ayland wrote:
>> On 04/07/2020 14:41, Sam Ravnborg wrote:
>>
>>> I think what is happening is that the bochs driver request a shadow copy
>>> for the frambuffer. And with the change to fbops we now use the cfb_
>>> functions to write to the shadow framebuffer - which is not in any IO
>>> space. So this does not work.
>>>
>>> So maybe all we need is the fix in drm_fb_helper_dirty_blit_real().
>>> If you try to undo the change so fbops is set to _fbdev_fb_ops,
>>> but keep the fix in drm_fb_helper_dirty_blit_real() how does it then
>>> behave?
>>
>> Bingo! I just tried that and the framebuffer is now working under
>> qemu-system-sparc64
>> again - thank you so much for the help! From what you said I guess
>> drm_fb_helper_dirty_blit_real() is responsible syncing the shadow copy?
>>
>> Below is the current working diff based upon your previous one: it certainly
>> feels
>> like the difference in memcpy() behaviour should be hidden away in
>> fb_memcpy_tofb()
>> or similar.
>
>>From your feedback so far I thnk the minimal fix would be like this:
>
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> .. static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
>> size_t len = (clip->x2 - clip->x1) * cpp;
>> unsigned int y;
>>
>> for (y = clip->y1; y < clip->y2; y++) {
>> - memcpy(dst, src, len);
>> + fb_memcpy_tofb(dst, src, len);
>> src += fb->pitches[0];
>> dst += fb->pitches[0];
>> }
>
> (Hand edited, patch s not a valid syntax)
>
> But I need feedback from someone that know all this a bit better
> to judge if this is an OK change.
> For once - this will only work with shadow buffers.
Hi Sam,
Yes, that's correct - I can confirm that the simplified diff below works:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5609e164805f..83af05fac604 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct
drm_fb_helper
*fb_helper,
unsigned int y;
for (y = clip->y1; y < clip->y2; y++) {
- memcpy(dst, src, len);
+ fb_memcpy_tofb(dst, src, len);
src += fb->pitches[0];
dst += fb->pitches[0];
}
I guess that the next step is to wait for advice from Gerd as to whether this is
sufficient, or if other changes are required to allow non-shadow buffers to
work on
architectures similar to SPARC64 too.
ATB,
Mark.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/amdgpu: stop allocating dummy GTT nodes
Now that TTM is fixed up we can finally stop that nonsense.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 104 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 18 +++-
2 files changed, 42 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 2c20d23d62d1..62cf4fbd803a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -150,60 +150,7 @@ static int amdgpu_gtt_mgr_fini(struct ttm_mem_type_manager
*man)
*/
bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem)
{
- struct amdgpu_gtt_node *node = mem->mm_node;
-
- return (node->node.start != AMDGPU_BO_INVALID_OFFSET);
-}
-
-/**
- * amdgpu_gtt_mgr_alloc - allocate new ranges
- *
- * @man: TTM memory type manager
- * @tbo: TTM BO we need this range for
- * @place: placement flags and restrictions
- * @mem: the resulting mem object
- *
- * Allocate the address space for a node.
- */
-static int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
- struct ttm_buffer_object *tbo,
- const struct ttm_place *place,
- struct ttm_mem_reg *mem)
-{
- struct amdgpu_device *adev = amdgpu_ttm_adev(man->bdev);
- struct amdgpu_gtt_mgr *mgr = man->priv;
- struct amdgpu_gtt_node *node = mem->mm_node;
- enum drm_mm_insert_mode mode;
- unsigned long fpfn, lpfn;
- int r;
-
- if (amdgpu_gtt_mgr_has_gart_addr(mem))
- return 0;
-
- if (place)
- fpfn = place->fpfn;
- else
- fpfn = 0;
-
- if (place && place->lpfn)
- lpfn = place->lpfn;
- else
- lpfn = adev->gart.num_cpu_pages;
-
- mode = DRM_MM_INSERT_BEST;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
- mode = DRM_MM_INSERT_HIGH;
-
- spin_lock(>lock);
- r = drm_mm_insert_node_in_range(>mm, >node, mem->num_pages,
- mem->page_alignment, 0, fpfn, lpfn,
- mode);
- spin_unlock(>lock);
-
- if (!r)
- mem->start = node->node.start;
-
- return r;
+ return mem->mm_node != NULL;
}
/**
@@ -234,29 +181,37 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager
*man,
atomic64_sub(mem->num_pages, >available);
spin_unlock(>lock);
+ if (!place->lpfn) {
+ mem->mm_node = NULL;
+ mem->start = AMDGPU_BO_INVALID_OFFSET;
+ return 0;
+ }
+
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node) {
r = -ENOMEM;
goto err_out;
}
- node->node.start = AMDGPU_BO_INVALID_OFFSET;
- node->node.size = mem->num_pages;
node->tbo = tbo;
- mem->mm_node = node;
- if (place->fpfn || place->lpfn || place->flags & TTM_PL_FLAG_TOPDOWN) {
- r = amdgpu_gtt_mgr_alloc(man, tbo, place, mem);
- if (unlikely(r)) {
- kfree(node);
- mem->mm_node = NULL;
- goto err_out;
- }
- } else {
- mem->start = node->node.start;
- }
+ spin_lock(>lock);
+ r = drm_mm_insert_node_in_range(>mm, >node, mem->num_pages,
+ mem->page_alignment, 0, place->fpfn,
+ place->lpfn, DRM_MM_INSERT_BEST);
+ spin_unlock(>lock);
+
+ if (unlikely(r))
+ goto err_free;
+
+ mem->mm_node = node;
+ mem->start = node->node.start;
return 0;
+
+err_free:
+ kfree(node);
+
err_out:
atomic64_add(mem->num_pages, >available);
@@ -279,17 +234,14 @@ static void amdgpu_gtt_mgr_del(struct
ttm_mem_type_manager *man,
struct amdgpu_gtt_mgr *mgr = man->priv;
struct amdgpu_gtt_node *node = mem->mm_node;
- if (!node)
- return;
-
- spin_lock(>lock);
- if (node->node.start != AMDGPU_BO_INVALID_OFFSET)
+ if (node) {
+ spin_lock(>lock);
drm_mm_remove_node(>node);
- spin_unlock(>lock);
- atomic64_add(mem->num_pages, >available);
+ spin_unlock(>lock);
+ kfree(node);
+ }
- kfree(node);
- mem->mm_node = NULL;
+ atomic64_add(mem->num_pages, >available);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 38d2a7fb5698..50503f860fce 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -429,12 +429,22 @@ int amdgpu_ttm_copy_mem_to_mem(struct amdgpu_device *adev,
}
src_offset = src->offset;
- src_mm =
[PATCH 1/2] drm/ttm: further cleanup ttm_mem_reg handling
Stop touching the backend private pointer alltogether and
make sure we never put the same mem twice by.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 46 +++--
include/drm/ttm/ttm_bo_driver.h | 2 --
2 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 0c13fe96c7e3..7be36b9996ed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -312,7 +312,6 @@ static int ttm_bo_handle_move_mem(struct ttm_buffer_object
*bo,
if (bdev->driver->move_notify)
bdev->driver->move_notify(bo, evict, mem);
bo->mem = *mem;
- mem->mm_node = NULL;
goto moved;
}
}
@@ -616,7 +615,6 @@ static void ttm_bo_release(struct kref *kref)
ttm_bo_cleanup_memtype_use(bo);
dma_resv_unlock(bo->base.resv);
- BUG_ON(bo->mem.mm_node != NULL);
atomic_dec(_bo_glob.bo_count);
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
@@ -843,12 +841,29 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
return ret;
}
+static int ttm_bo_mem_get(struct ttm_buffer_object *bo,
+ const struct ttm_place *place,
+ struct ttm_mem_reg *mem)
+{
+ struct ttm_mem_type_manager *man = >bdev->man[mem->mem_type];
+
+ mem->mm_node = NULL;
+ if (!man->func || !man->func->get_node)
+ return 0;
+
+ return man->func->get_node(man, bo, place, mem);
+}
+
void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct ttm_mem_reg *mem)
{
struct ttm_mem_type_manager *man = >bdev->man[mem->mem_type];
- if (mem->mm_node)
- (*man->func->put_node)(man, mem);
+ if (!man->func || !man->func->put_node)
+ return;
+
+ man->func->put_node(man, mem);
+ mem->mm_node = NULL;
+ mem->mem_type = TTM_PL_SYSTEM;
}
EXPORT_SYMBOL(ttm_bo_mem_put);
@@ -902,7 +917,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object
*bo,
ticket = dma_resv_locking_ctx(bo->base.resv);
do {
- ret = (*man->func->get_node)(man, bo, place, mem);
+ ret = ttm_bo_mem_get(bo, place, mem);
if (likely(!ret))
break;
if (unlikely(ret != -ENOSPC))
@@ -1032,7 +1047,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (unlikely(ret))
return ret;
- mem->mm_node = NULL;
for (i = 0; i < placement->num_placement; ++i) {
const struct ttm_place *place = >placement[i];
struct ttm_mem_type_manager *man;
@@ -1044,20 +1058,16 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
type_found = true;
- mem->mm_node = NULL;
- if (mem->mem_type == TTM_PL_SYSTEM)
- return 0;
-
- man = >man[mem->mem_type];
- ret = (*man->func->get_node)(man, bo, place, mem);
+ ret = ttm_bo_mem_get(bo, place, mem);
if (ret == -ENOSPC)
continue;
if (unlikely(ret))
goto error;
+ man = >man[mem->mem_type];
ret = ttm_bo_add_move_fence(bo, man, mem, ctx->no_wait_gpu);
if (unlikely(ret)) {
- (*man->func->put_node)(man, mem);
+ ttm_bo_mem_put(bo, mem);
if (ret == -EBUSY)
continue;
@@ -1076,12 +1086,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
type_found = true;
- mem->mm_node = NULL;
- if (mem->mem_type == TTM_PL_SYSTEM)
- return 0;
-
ret = ttm_bo_mem_force_space(bo, place, mem, ctx);
- if (ret == 0 && mem->mm_node)
+ if (likely(!ret))
return 0;
if (ret && ret != -EBUSY)
@@ -1129,7 +1135,7 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object
*bo,
goto out_unlock;
ret = ttm_bo_handle_move_mem(bo, , false, ctx);
out_unlock:
- if (ret && mem.mm_node)
+ if (ret)
ttm_bo_mem_put(bo, );
return ret;
}
@@ -1144,7 +1150,7 @@ static bool ttm_bo_places_compat(const struct ttm_place
*places,
for (i = 0; i < num_placement; i++) {
const struct ttm_place *heap = [i];
- if (mem->mm_node && (mem->start < heap->fpfn ||
+ if ((mem->start < heap->fpfn ||
(heap->lpfn != 0 && (mem->start + mem->num_pages) >
heap->lpfn)))
continue;
diff --git
Re: [PATCH] drm/i915: Fix spelling mistake in i915_reg.h
Quoting Flavio Suligoi (2020-07-03 13:50:46) > Fix typo: "TRIGER" --> "TRIGGER" > > The two misplelled macros: > > 1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK > 2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK > > are not used in any other sources of the kernel, > so this change can be consider only a local change > for the i915_reg.h file. > > Signed-off-by: Flavio Suligoi > --- > drivers/gpu/drm/i915/i915_reg.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index 9d6536afc94b..c2153364724a 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -868,7 +868,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > > #define OAREPORTTRIG1 _MMIO(0x2740) > #define OAREPORTTRIG1_THRESHOLD_MASK 0x > -#define OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ > +#define OAREPORTTRIG1_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ > > #define OAREPORTTRIG2 _MMIO(0x2744) > #define OAREPORTTRIG2_INVERT_A_0 (1 << 0) > @@ -921,7 +921,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) > > #define OAREPORTTRIG5 _MMIO(0x2750) > #define OAREPORTTRIG5_THRESHOLD_MASK 0x > -#define OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ > +#define OAREPORTTRIG5_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ Ok, these names are not copied straight from the docs, so renaming them will not hinder us when finding the relevant fields. Reviewed-by: Chris Wilson -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/hisilicon/hibmc: Move drm_fbdev_generic_setup() down to avoid the splat
Hi
Am 06.07.20 um 16:47 schrieb Zenghui Yu:
> The HiSilicon hibmc driver triggers a splat at boot time as below
>
> [ 14.137806] [ cut here ]
> [ 14.142405] hibmc-drm :0a:00.0: Device has not been registered.
> [ 14.148661] WARNING: CPU: 0 PID: 496 at
> drivers/gpu/drm/drm_fb_helper.c:2233 drm_fbdev_generic_setup+0x15c/0x1b8
> [ 14.158787] [...]
> [ 14.278307] Call trace:
> [ 14.280742] drm_fbdev_generic_setup+0x15c/0x1b8
> [ 14.285337] hibmc_pci_probe+0x354/0x418
> [ 14.289242] local_pci_probe+0x44/0x98
> [ 14.292974] work_for_cpu_fn+0x20/0x30
> [ 14.296708] process_one_work+0x1c4/0x4e0
> [ 14.300698] worker_thread+0x2c8/0x528
> [ 14.304431] kthread+0x138/0x140
> [ 14.307646] ret_from_fork+0x10/0x18
> [ 14.311205] ---[ end trace a2000ec2d838af4d ]---
>
> This turned out to be due to the fbdev device hasn't been registered when
> drm_fbdev_generic_setup() is invoked. Let's fix the splat by moving it down
> after drm_dev_register() which will follow the "Display driver example"
> documented by commit de99f0600a79 ("drm/drv: DOC: Add driver example
> code").
>
> Signed-off-by: Zenghui Yu
Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index a6fd0c29e5b8..544b9993c99e 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -307,8 +307,6 @@ static int hibmc_load(struct drm_device *dev)
> /* reset all the states of crtc/plane/encoder/connector */
> drm_mode_config_reset(dev);
>
> - drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
> -
> return 0;
>
> err:
> @@ -355,6 +353,9 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
> ret);
> goto err_unload;
> }
> +
> + drm_fbdev_generic_setup(dev, dev->mode_config.preferred_depth);
> +
> return 0;
>
> err_unload:
>
--
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
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #40 from Alex Deucher (alexdeuc...@gmail.com) --- Does this patch help? https://gitlab.freedesktop.org/drm/amd/uploads/356586b6aa81f64cfa9b4b034499fdd8/amdgpu-bugfix-revert-vmalloc-size-change.patch -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/4] drm/msm: dsi: Use OPP API to set clk/perf state
On Thu, Jul 02, 2020 at 04:39:09PM +0530, Rajendra Nayak wrote:
> On SDM845 and SC7180 DSI needs to express a performance state
> requirement on a power domain depending on the clock rates.
> Use OPP table from DT to register with OPP framework and use
> dev_pm_opp_set_rate() to set the clk/perf state.
>
> dev_pm_opp_set_rate() is designed to be equivalent to clk_set_rate()
> for devices without an OPP table, hence the change works fine
> on devices/platforms which only need to set a clock rate.
>
> Signed-off-by: Rajendra Nayak
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 11ae5b8..09e16b8 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -111,6 +112,9 @@ struct msm_dsi_host {
> struct clk *pixel_clk_src;
> struct clk *byte_intf_clk;
>
> + struct opp_table *opp_table;
> + bool has_opp_table;
> +
> u32 byte_clk_rate;
> u32 pixel_clk_rate;
> u32 esc_clk_rate;
> @@ -512,9 +516,10 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host
> *msm_host)
> DBG("Set clk rates: pclk=%d, byteclk=%d",
> msm_host->mode->clock, msm_host->byte_clk_rate);
>
> - ret = clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);
> + ret = dev_pm_opp_set_rate(_host->pdev->dev,
> + msm_host->byte_clk_rate);
> if (ret) {
> - pr_err("%s: Failed to set rate byte clk, %d\n", __func__, ret);
> + pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
> return ret;
> }
>
> @@ -658,6 +663,8 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
>
> void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
> {
> + /* Drop the performance state vote */
> + dev_pm_opp_set_rate(_host->pdev->dev, 0);
> clk_disable_unprepare(msm_host->esc_clk);
> clk_disable_unprepare(msm_host->pixel_clk);
> if (msm_host->byte_intf_clk)
> @@ -1879,6 +1886,18 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
> goto fail;
> }
>
> + msm_host->opp_table = dev_pm_opp_set_clkname(>dev, "byte");
> + if (IS_ERR(msm_host->opp_table))
> + return PTR_ERR(msm_host->opp_table);
> + /* OPP table is optional */
> + ret = dev_pm_opp_of_add_table(>dev);
> + if (!ret) {
> + msm_host->has_opp_table = true;
> + } else if (ret != -ENODEV) {
> + dev_err(>dev, "invalid OPP table in device tree\n");
dev_pm_opp_put_clkname(msm_host->opp_table);
> + return ret;
> + }
With the missing _put_clkname() fixed:
Reviewed-by: Matthias Kaehlcke
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/amdgpu: remove set but not used variable 'adev'
On Thu, Jul 2, 2020 at 3:25 AM YueHaibing wrote:
>
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 'amdgpu_init_mem_type':
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:81:24: warning:
> variable 'adev' set but not used [-Wunused-but-set-variable]
> struct amdgpu_device *adev;
> ^
>
> Signed-off-by: YueHaibing
With our current -next tree, this patch is no longer applicable.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index bb95627ad2cc..8199702d3354 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -78,10 +78,6 @@
> static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> struct ttm_mem_type_manager *man)
> {
> - struct amdgpu_device *adev;
> -
> - adev = amdgpu_ttm_adev(bdev);
> -
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
>
>
>
>
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208413] amdgpu driver crash
https://bugzilla.kernel.org/show_bug.cgi?id=208413 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Does this patch help? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/8] soc: mediatek: cmdq: add address shift in jump
On 05/07/2020 08:48, Dennis YC Hsieh wrote: > Add address shift when compose jump instruction > to compatible with 35bit format. > > Signed-off-by: Dennis YC Hsieh You are missing Bibby's Reviewed-by. Please honour the effort reviewers do by adding the appropriate tags. Please double check the series and resend with all tags added. Also, it would be good if you could provide a change log. That makes it easier for the maintainer to see which statements you addressed. Thanks, Matthias > --- > drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c > b/drivers/soc/mediatek/mtk-cmdq-helper.c > index dc644cfb6419..9faf78fbed3a 100644 > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c > @@ -329,7 +329,8 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt) > > /* JUMP to end */ > inst.op = CMDQ_CODE_JUMP; > - inst.value = CMDQ_JUMP_PASS; > + inst.value = CMDQ_JUMP_PASS >> > + cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan); > err = cmdq_pkt_append_command(pkt, inst); > > return err; > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208443] [amdpgu] NAVI10 shutting second display off causes video corruption/crash on kernels >=5.7.6
https://bugzilla.kernel.org/show_bug.cgi?id=208443 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Likely fixed by: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eb3cf2e06d22b2b08e6b0ab48cb9c05a8e1a107 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208129] amdgpu: polaris10 sudden crash, garbled graphics.
https://bugzilla.kernel.org/show_bug.cgi?id=208129 Martin Jørgensen (m...@gotu.dk) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INSUFFICIENT_DATA --- Comment #8 from Martin Jørgensen (m...@gotu.dk) --- after upgrade i have not notice any incidence since. does not mean it is fixed, but closing this for now anyway. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] omapfb/dss: Include the right header
The hdmi4.c and hdmi5.c files include the legacy GPIO header but does not use any of the symbols from this file. What it does use is the implicit inclusion of leading to compile errors if we just drop this include. Include the right header. Cc: Tony Lindgren Signed-off-by: Linus Walleij --- Tony if you're OK with this patch I will merge it through the drm-misc tree once you ACKed it. --- drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 2 +- drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c index 7060ae56c062..f2d65aed7f76 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c @@ -19,7 +19,7 @@ #include #include #include -#include +#include #include #include #include diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c index ac49531e4732..d14d339f7fdf 100644 --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c @@ -24,7 +24,7 @@ #include #include #include -#include +#include #include #include #include -- 2.25.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v9 5/5] drm/i915: Enable support for integrated privacy screen
Hi,
On 3/12/20 7:56 PM, Rajat Jain wrote:
Add support for an ACPI based integrated privacy screen that is
available on some systems.
Signed-off-by: Rajat Jain
So as discussed a while ago I'm working on adding support for the
privacy-screen on Lenovo Thinkpads, introducing a small new
subsystem / helper-class as intermediary for when the privacy-screen
is controlled by e.g. some random drivers/platform/x86 driver rather
then directly by the GPU driver.
I'm almost ready to send out v1. I was working on hooking things
up in the i915 code and I was wondering what you were doing when
the property is actually changed and we need to commit the new
privacy-screen state to the hardware.
This made me look at this patch, some comments inline:
---
v9: same as v8
v8: - separate the APCI privacy screen into a separate patch.
- Don't destroy the property if there is no privacy screen (because
drm core doesn't like destroying property in late_register()).
- The setting change needs to be committed in ->update_pipe() for
ddi.c as well as dp.c and both of them call intel_dp_add_properties()
v7: Look for ACPI node in ->late_register() hook.
Do the scan only once per drm_device (instead of 1 per drm_connector)
v6: Addressed minor comments from Jani at
https://lkml.org/lkml/2020/1/24/1143
- local variable renamed.
- used drm_dbg_kms()
- used acpi_device_handle()
- Used opaque type acpi_handle instead of void*
v5: same as v4
v4: Same as v3
v3: fold the code into existing acpi_device_id_update() function
v2: formed by splitting the original patch into ACPI lookup, and privacy
screen property. Also move it into i915 now that I found existing code
in i915 that can be re-used.
drivers/gpu/drm/i915/display/intel_atomic.c | 2 ++
drivers/gpu/drm/i915/display/intel_ddi.c| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 34 -
drivers/gpu/drm/i915/display/intel_dp.h | 5 +++
4 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index d043057d2fa03..9898d8980e7ce 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -150,6 +150,8 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode ||
+ new_conn_state->base.privacy_screen_status !=
+ old_conn_state->base.privacy_screen_status ||
!blob_equal(new_conn_state->base.hdr_output_metadata,
old_conn_state->base.hdr_output_metadata))
crtc_state->mode_changed = true;
Right I was planning on doing this to.
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 73d0f4648c06a..69a5423216dc5 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3708,6 +3708,7 @@ static void intel_ddi_update_pipe(struct intel_encoder
*encoder,
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
intel_ddi_update_pipe_dp(encoder, crtc_state, conn_state);
+ intel_dp_update_privacy_screen(encoder, crtc_state, conn_state);
intel_hdcp_update_pipe(encoder, crtc_state, conn_state);
}
And this too.
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 3ddc424b028c1..5f33ebb466135 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -62,6 +62,7 @@
#include "intel_lspcon.h"
#include "intel_lvds.h"
#include "intel_panel.h"
+#include "intel_privacy_screen.h"
#include "intel_psr.h"
#include "intel_sideband.h"
#include "intel_tc.h"
@@ -5886,6 +5887,10 @@ intel_dp_connector_register(struct drm_connector
*connector)
dev_priv->acpi_scan_done = true;
}
+ /* Check for integrated Privacy screen support */
+ if (intel_privacy_screen_present(to_intel_connector(connector)))
+ drm_connector_attach_privacy_screen_property(connector);
+
DRM_DEBUG_KMS("registering %s bus for %s\n",
intel_dp->aux.name, connector->kdev->kobj.name);
@@ -6883,6 +6888,33 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connect
connector->state->scaling_mode = DRM_MODE_SCALE_ASPECT;
}
+
+ /*
+* Created here, but depending on result of probing for privacy-screen
+* in intel_dp_connector_register(), gets attached in that function.
+* Need to create here because the drm core doesn't like creating
+* properties
[PATCH] drm/radeon: fix double free
From: Tom Rix
clang static analysis flags this error
drivers/gpu/drm/radeon/ci_dpm.c:5652:9: warning: Use of memory after it is
freed [unix.Malloc]
kfree(rdev->pm.dpm.ps[i].ps_priv);
^~
drivers/gpu/drm/radeon/ci_dpm.c:5654:2: warning: Attempt to free released
memory [unix.Malloc]
kfree(rdev->pm.dpm.ps);
^~
problem is reported in ci_dpm_fini, with these code blocks.
for (i = 0; i < rdev->pm.dpm.num_ps; i++) {
kfree(rdev->pm.dpm.ps[i].ps_priv);
}
kfree(rdev->pm.dpm.ps);
The first free happens in ci_parse_power_table where it cleans up locally
on a failure. ci_dpm_fini also does a cleanup.
ret = ci_parse_power_table(rdev);
if (ret) {
ci_dpm_fini(rdev);
return ret;
}
So remove the cleanup in ci_parse_power_table and
move the num_ps calculation to inside the loop so ci_dpm_fini
will know how many array elements to free.
Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/ci_dpm.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index 86ac032275bb..ba20c6f03719 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -5563,6 +5563,7 @@ static int ci_parse_power_table(struct radeon_device
*rdev)
if (!rdev->pm.dpm.ps)
return -ENOMEM;
power_state_offset = (u8 *)state_array->states;
+ rdev->pm.dpm.num_ps = 0;
for (i = 0; i < state_array->ucNumEntries; i++) {
u8 *idx;
power_state = (union pplib_power_state *)power_state_offset;
@@ -5572,10 +5573,8 @@ static int ci_parse_power_table(struct radeon_device
*rdev)
if (!rdev->pm.power_state[i].clock_info)
return -EINVAL;
ps = kzalloc(sizeof(struct ci_ps), GFP_KERNEL);
- if (ps == NULL) {
- kfree(rdev->pm.dpm.ps);
+ if (ps == NULL)
return -ENOMEM;
- }
rdev->pm.dpm.ps[i].ps_priv = ps;
ci_parse_pplib_non_clock_info(rdev, >pm.dpm.ps[i],
non_clock_info,
@@ -5597,8 +5596,8 @@ static int ci_parse_power_table(struct radeon_device
*rdev)
k++;
}
power_state_offset += 2 + power_state->v2.ucNumDPMLevels;
+ rdev->pm.dpm.num_ps = i + 1;
}
- rdev->pm.dpm.num_ps = state_array->ucNumEntries;
/* fill in the vce power states */
for (i = 0; i < RADEON_MAX_VCE_LEVELS; i++) {
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
Hi,
On 06/07/2020 01:57, Paul Boddie wrote:
> Hello,
>
> On Friday, 15 May 2020 09:43:54 CEST Neil Armstrong wrote:
>>
>> On 15/05/2020 00:04, Paul Boddie wrote:
>>>
>>> Well, I've done this but I probably need to know what to look for. One
>>> thing that appears regardless of this debugging output being enabled is a
>>> problem with the vertical blanking functionality:
>>>
>>> WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457
>>> drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c
>>> [CRTC:32:crtc-0] vblank wait timed out
>>
>> This means the CRTC didn't start, usually because the Pixel clock didn't go
>> through the pipeline to the pixel generator, thus not generating
>> vblank/vsync interrupts.
>>
>> You may check if there is not muxes to select the clock source/pixel
>> destination.
>
> It has obviously been a while since I asked about the DW-HDMI functionality.
> Since then, I have verified the initialisation of the Ingenic JZ4780 LCD
> controller and the Synopsys HDMI peripheral in the L4 Runtime Environment
> (running on the Fiasco.OC microkernel), producing a picture and handling
> display interrupts.
>
> Having brought the necessary changes back to the Ingenic DRM driver, I can
> make the driver activate the LCD controller and produce vertical blank
> interrupts, and these are handled and counted in /proc/interrupts. The
> previous errors about timeouts are now gone.
>
> However, the DRM driver can only be made to start if I set the bus format in
> dw_hdmi_bridge_attach:
>
> u32 bus_format[] = { MEDIA_BUS_FMT_RGB888_1X24 };
> ...
> (>display_info,
>bus_format, ARRAY_SIZE(bus_format));
>
> Without this, the DRM driver will test for a bus format on the connector's
> display_info structure in ingenic_drm_encoder_atomic_check and return EINVAL.
> There have previously been indications that this should not need to be done,
> but I see that other drivers do similar things (for example, ti-tfp410.c).
I think this is specific to the ingenic DRM driver, so yeah it may be needed in
your case.
>
> It also seems to be appropriate to set the input_bus_format on the platform-
> specific HDMI driver; otherwise, I doubt that appropriate bus encodings will
> be chosen in the Synopsys driver.
It does but when not provided, it doesn't use it.
It's handled in drm_atomic_bridge_chain_select_bus_fmts() :
if (conn->display_info.num_bus_formats &&
conn->display_info.bus_formats)
out_bus_fmts[0] = conn->display_info.bus_formats[0];
else
out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
>
> [...]
>
>>> Attempting to set a mode using...
>>>
>>> modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
>>>
>>> ...yields the following:
>>>
>>> failed to set mode: Permission denied
>>> setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
>>
>> This is weird, the command line is ok, is it the same for all modes ?
>
> Testing against 5.8-rc3 with the above changes seems to have moved the needle
> slightly. Although I still get "Input not supported" from my monitor, running
> modetest now gives a different error:
>
> modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
>
> ...now yields this:
>
> setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
> failed to set gamma: Invalid argument
This is because you don't provide the gamma setup ioctl, it's not a fatal error
at all.
It should be warning since it's optional.
Did you check all modes ?
>
> There also seems to be a card1, but I get the same result with that, and they
> both seem to produce similar output with modetest without the -s option.
>
> Anyway, progress is rather slow trying to figure out the obstruction here, so
> any advice would still be appreciated.
>
> Thanks in advance,
>
> Paul
>
>
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx
On Mon, Jul 6, 2020 at 1:02 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 03/07/2020 22:36, Sam Ravnborg wrote:
> > Hi Tomi.
> >
> > On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:
> >> On 30/06/2020 21:26, Adam Ford wrote:
> >>> The drm/omap driver was fixed to correct an issue where using a
> >>> divider of 32 breaks the DSS despite the TRM stating 32 is a valid
> >>> number. Through experimentation, it appears that 31 works, and
> >>> it is consistent with the value used by the drm/omap driver.
> >>>
> >>> This patch fixes the divider for fbdev driver instead of the drm.
> >>>
> >>> Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
> >>>
> >>> Cc: #4.9+
> >>> Signed-off-by: Adam Ford
> >>> ---
> >>> Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
> >>>
> >>> The DRM version of this same fix is:
> >>> e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
> >>>
> >>>
> >>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> >>> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> >>> index 7252d22dd117..bfc5c4c5a26a 100644
> >>> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> >>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> >>> @@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats =
> >>> {
> >>>};
> >>>static const struct dss_features omap3630_dss_feats = {
> >>> - .fck_div_max= 32,
> >>> + .fck_div_max= 31,
> >>> .dss_fck_multiplier = 1,
> >>> .parent_clk_name= "dpll4_ck",
> >>> .dpi_select_source = _dpi_select_source_omap2_omap3,
> >>>
> >>
> >> Reviewed-by: Tomi Valkeinen
> > Will you apply to drm-misc?
>
> This is for fbdev, so I presume Bartlomiej will pick this one.
>
> > Note following output from "dim fixes":
> > $ dim fixes f76ee892a99e
> > Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
> > Cc: Tomi Valkeinen
> > Cc: Dave Airlie
> > Cc: Rob Clark
> > Cc: Laurent Pinchart
> > Cc: Sam Ravnborg
> > Cc: Bartlomiej Zolnierkiewicz
> > Cc: Jason Yan
> > Cc: "Andrew F. Davis"
> > Cc: YueHaibing
> > Cc: # v4.5+
> >
> > Here it says the fix is valid from v4.5 onwards.
>
> Hmm... Adam, you marked the fix to apply to v4.9+, and then you said
> v4.4 needs a new patch (that's before the big copy/rename). Did you
> check the versions between 4.4 and 4.9? I would guess this one applies
> to v4.5+.
I only tried 4.9 because it's listed as an LTS kernel. The stuff
between 4.4 and 4.9 were EOL, so I didn't go back further.The 4.5+
is probably more accurate. I would like to do the same thing for the
4.4 kernel, but I am not sure the proper way to do that.
adam
>
> Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208443] [amdpgu] NAVI10 shutting second display off causes video corruption/crash on kernels >=5.7.6
https://bugzilla.kernel.org/show_bug.cgi?id=208443 --- Comment #1 from Michel Dänzer (mic...@daenzer.net) --- See https://gitlab.freedesktop.org/drm/amd/-/issues/1189 . -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx
Hi,
On 03/07/2020 22:36, Sam Ravnborg wrote:
Hi Tomi.
On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:
On 30/06/2020 21:26, Adam Ford wrote:
The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
number. Through experimentation, it appears that 31 works, and
it is consistent with the value used by the drm/omap driver.
This patch fixes the divider for fbdev driver instead of the drm.
Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: #4.9+
Signed-off-by: Adam Ford
---
Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
The DRM version of this same fix is:
e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 7252d22dd117..bfc5c4c5a26a 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats = {
};
static const struct dss_features omap3630_dss_feats = {
- .fck_div_max= 32,
+ .fck_div_max= 31,
.dss_fck_multiplier = 1,
.parent_clk_name= "dpll4_ck",
.dpi_select_source = _dpi_select_source_omap2_omap3,
Reviewed-by: Tomi Valkeinen
Will you apply to drm-misc?
This is for fbdev, so I presume Bartlomiej will pick this one.
Note following output from "dim fixes":
$ dim fixes f76ee892a99e
Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: Tomi Valkeinen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Jason Yan
Cc: "Andrew F. Davis"
Cc: YueHaibing
Cc: # v4.5+
Here it says the fix is valid from v4.5 onwards.
Hmm... Adam, you marked the fix to apply to v4.9+, and then you said
v4.4 needs a new patch (that's before the big copy/rename). Did you
check the versions between 4.4 and 4.9? I would guess this one applies
to v4.5+.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/of: Consider the state in which the ep is disabled
Hi Sandy,
Am Montag, 6. Juli 2020, 09:59:44 CEST schrieb Sandy Huang:
> don't mask possible_crtcs if remote-point is disabled.
>
> Signed-off-by: Sandy Huang
> ---
> drivers/gpu/drm/drm_of.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index fdb05fbf72a0..f5f250435add 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -66,6 +66,11 @@ uint32_t drm_of_find_possible_crtcs(struct drm_device *dev,
> uint32_t possible_crtcs = 0;
>
> for_each_endpoint_of_node(port, ep) {
> + if (!of_device_is_available(ep)) {
> + of_node_put(ep);
You'd only need the of_node_put here, if you were exiting the loop.
With the "continue" below, the next iteration of for_each_endpoint_of_node
will do the put on "ep"
Heiko
> + continue;
> + }
> +
> remote_port = of_graph_get_remote_port(ep);
> if (!remote_port) {
> of_node_put(ep);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/hisilicon: Code refactoring for hibmc_drv_vdac
Hi
Am 02.07.20 um 12:12 schrieb Thomas Zimmermann:
> Thanks!
>
> Am 02.07.20 um 10:54 schrieb Tian Tao:
>> code refactoring for hibmc_drv_vdac.c, no actual function changes.
>>
>> v2:
>> remove the debug message.
>>
>> v3:
>> embedding connector and encoder in struct hibmc_drm_private.
>>
>> Signed-off-by: Tian Tao
>
> Reviewed-by: Thomas Zimmermann
>
> Maybe others want to comment on the patch, so I'll give it a few more
> days before I add it to drm-misc-next. Don't hesitate to ping me if I
> forget about it.
I've added the patch to drm-misc-next
>
> Best regards
> Thomas
>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 52
>> +---
>> 2 files changed, 13 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 50a0c1f..6097687 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -29,6 +29,8 @@ struct hibmc_drm_private {
>>
>> /* drm */
>> struct drm_device *dev;
>> +struct drm_encoder encoder;
>> +struct drm_connector connector;
>> bool mode_config_initialized;
>> };
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> index 678ac2e..2ca69c3 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> @@ -52,32 +52,6 @@ static const struct drm_connector_funcs
>> hibmc_connector_funcs = {
>> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>> };
>>
>> -static struct drm_connector *
>> -hibmc_connector_init(struct hibmc_drm_private *priv)
>> -{
>> -struct drm_device *dev = priv->dev;
>> -struct drm_connector *connector;
>> -int ret;
>> -
>> -connector = devm_kzalloc(dev->dev, sizeof(*connector), GFP_KERNEL);
>> -if (!connector) {
>> -DRM_ERROR("failed to alloc memory when init connector\n");
>> -return ERR_PTR(-ENOMEM);
>> -}
>> -
>> -ret = drm_connector_init(dev, connector,
>> - _connector_funcs,
>> - DRM_MODE_CONNECTOR_VGA);
>> -if (ret) {
>> -DRM_ERROR("failed to init connector: %d\n", ret);
>> -return ERR_PTR(ret);
>> -}
>> -drm_connector_helper_add(connector,
>> - _connector_helper_funcs);
>> -
>> -return connector;
>> -}
>> -
>> static void hibmc_encoder_mode_set(struct drm_encoder *encoder,
>> struct drm_display_mode *mode,
>> struct drm_display_mode *adj_mode)
>> @@ -105,23 +79,10 @@ static const struct drm_encoder_funcs
>> hibmc_encoder_funcs = {
>> int hibmc_vdac_init(struct hibmc_drm_private *priv)
>> {
>> struct drm_device *dev = priv->dev;
>> -struct drm_encoder *encoder;
>> -struct drm_connector *connector;
>> +struct drm_encoder *encoder = >encoder;
>> +struct drm_connector *connector = >connector;
>> int ret;
>>
>> -connector = hibmc_connector_init(priv);
>> -if (IS_ERR(connector)) {
>> -DRM_ERROR("failed to create connector: %ld\n",
>> - PTR_ERR(connector));
>> -return PTR_ERR(connector);
>> -}
>> -
>> -encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL);
>> -if (!encoder) {
>> -DRM_ERROR("failed to alloc memory when init encoder\n");
>> -return -ENOMEM;
>> -}
>> -
>> encoder->possible_crtcs = 0x1;
>> ret = drm_encoder_init(dev, encoder, _encoder_funcs,
>> DRM_MODE_ENCODER_DAC, NULL);
>> @@ -131,6 +92,15 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
>> }
>>
>> drm_encoder_helper_add(encoder, _encoder_helper_funcs);
>> +
>> +ret = drm_connector_init(dev, connector, _connector_funcs,
>> + DRM_MODE_CONNECTOR_VGA);
>> +if (ret) {
>> +DRM_ERROR("failed to init connector: %d\n", ret);
>> +return ret;
>> +}
>> +drm_connector_helper_add(connector, _connector_helper_funcs);
>> +
>> drm_connector_attach_encoder(connector, encoder);
>>
>> return 0;
>>
>
--
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
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Hi,
On 03/07/2020 11:08, Simon Ser wrote:
> Thanks for the update!
>
> The driver should also disallow importing a AMLOGIC_FBC_LAYOUT_SCATTER
> DMA-BUF from another device, but I guess this is clear enough ("not
> transferrable between Amlogic SoCs").
Good idea, I'll experiment disabling import of DRM allocated DUMB buffers,
but not sure I can disable import of other allocaters like ION.
Neil
>
> From a user-space PoV:
>
> Acked-by: Simon Ser
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Hi,
On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote:
> Add an Operating Performance Points table for the GPU to
> enable Dynamic Voltage & Frequency Scaling on the H6.
>
> The voltage range is set with minival voltage set to the target
> and the maximal voltage set to 1.2V. This allow DVFS framework to
> work properly on board with fixed regulator.
>
> Signed-off-by: Clément Péron
That patch seems reasonable, why shouldn't we merge it?
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
> 1 file changed, 80 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index 8f514a2169aa..a69f9e09a829 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -174,6 +174,7 @@ gpu: gpu@180 {
> clocks = < CLK_GPU>, < CLK_BUS_GPU>;
> clock-names = "core", "bus";
> resets = < RST_BUS_GPU>;
> + operating-points-v2 = <_opp_table>;
> #cooling-cells = <2>;
> status = "disabled";
> };
> @@ -1036,4 +1037,83 @@ map0 {
> };
> };
> };
> +
> + gpu_opp_table: gpu-opp-table {
> + compatible = "operating-points-v2";
> +
> + opp@21600 {
> + opp-hz = /bits/ 64 <21600>;
> + opp-microvolt = <81 81 120>;
> + };
All those nodes will create DTC warnings though.
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/14] drm/panfrost: introduce panfrost_devfreq struct
Introduce a proper panfrost_devfreq to deal with devfreq variables.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 76 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 20 +-
drivers/gpu/drm/panfrost/panfrost_device.h | 11 +--
drivers/gpu/drm/panfrost/panfrost_job.c | 6 +-
4 files changed, 66 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index df7b71da9a84..962550363391 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -10,23 +10,23 @@
#include "panfrost_device.h"
#include "panfrost_devfreq.h"
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
+static void panfrost_devfreq_update_utilization(struct panfrost_devfreq
*pfdevfreq)
{
ktime_t now;
ktime_t last;
- if (!pfdev->devfreq.devfreq)
+ if (!pfdevfreq->devfreq)
return;
now = ktime_get();
- last = pfdev->devfreq.time_last_update;
+ last = pfdevfreq->time_last_update;
- if (atomic_read(>devfreq.busy_count) > 0)
- pfdev->devfreq.busy_time += ktime_sub(now, last);
+ if (atomic_read(>busy_count) > 0)
+ pfdevfreq->busy_time += ktime_sub(now, last);
else
- pfdev->devfreq.idle_time += ktime_sub(now, last);
+ pfdevfreq->idle_time += ktime_sub(now, last);
- pfdev->devfreq.time_last_update = now;
+ pfdevfreq->time_last_update = now;
}
static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
@@ -47,30 +47,31 @@ static int panfrost_devfreq_target(struct device *dev,
unsigned long *freq,
return 0;
}
-static void panfrost_devfreq_reset(struct panfrost_device *pfdev)
+static void panfrost_devfreq_reset(struct panfrost_devfreq *pfdevfreq)
{
- pfdev->devfreq.busy_time = 0;
- pfdev->devfreq.idle_time = 0;
- pfdev->devfreq.time_last_update = ktime_get();
+ pfdevfreq->busy_time = 0;
+ pfdevfreq->idle_time = 0;
+ pfdevfreq->time_last_update = ktime_get();
}
static int panfrost_devfreq_get_dev_status(struct device *dev,
struct devfreq_dev_status *status)
{
struct panfrost_device *pfdev = dev_get_drvdata(dev);
+ struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
- panfrost_devfreq_update_utilization(pfdev);
+ panfrost_devfreq_update_utilization(pfdevfreq);
status->current_frequency = clk_get_rate(pfdev->clock);
- status->total_time = ktime_to_ns(ktime_add(pfdev->devfreq.busy_time,
- pfdev->devfreq.idle_time));
+ status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
+ pfdevfreq->idle_time));
- status->busy_time = ktime_to_ns(pfdev->devfreq.busy_time);
+ status->busy_time = ktime_to_ns(pfdevfreq->busy_time);
- panfrost_devfreq_reset(pfdev);
+ panfrost_devfreq_reset(pfdevfreq);
- dev_dbg(pfdev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
status->busy_time,
- status->total_time,
+ dev_dbg(pfdev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
+ status->busy_time, status->total_time,
status->busy_time / (status->total_time / 100),
status->current_frequency / 1000 / 1000);
@@ -91,6 +92,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
ret = dev_pm_opp_of_add_table(dev);
if (ret == -ENODEV) /* Optional, continue without devfreq */
@@ -98,7 +100,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
else if (ret)
return ret;
- panfrost_devfreq_reset(pfdev);
+ panfrost_devfreq_reset(pfdevfreq);
cur_freq = clk_get_rate(pfdev->clock);
@@ -116,53 +118,59 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
dev_pm_opp_of_remove_table(dev);
return PTR_ERR(devfreq);
}
- pfdev->devfreq.devfreq = devfreq;
+ pfdevfreq->devfreq = devfreq;
cooling = of_devfreq_cooling_register(dev->of_node, devfreq);
if (IS_ERR(cooling))
DRM_DEV_INFO(dev, "Failed to register cooling device\n");
else
- pfdev->devfreq.cooling = cooling;
+ pfdevfreq->cooling = cooling;
return 0;
}
void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
- if (pfdev->devfreq.cooling)
- devfreq_cooling_unregister(pfdev->devfreq.cooling);
+ struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
+
+
Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)
Hi Will, On 2020-07-03 19:07, Will Deacon wrote: On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c index f455c597f76d..bd1d58229cc2 100644 --- a/drivers/gpu/drm/msm/msm_iommu.c +++ b/drivers/gpu/drm/msm/msm_iommu.c @@ -218,6 +218,9 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova, iova |= GENMASK_ULL(63, 49); + if (mmu->features & MMU_FEATURE_USE_SYSTEM_CACHE) + prot |= IOMMU_SYS_CACHE_ONLY; Given that I think this is the only user of IOMMU_SYS_CACHE_ONLY, then it looks like it should actually be a property on the domain because we never need to configure it on a per-mapping basis within a domain, and therefore it shouldn't be exposed by the IOMMU API as a prot flag. Do you agree? GPU being the only user is for now, but there are other clients which can use this. Plus how do we set the memory attributes if we do not expose this as prot flag? Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)
On 2020-07-03 21:34, Rob Clark wrote: On Fri, Jul 3, 2020 at 7:53 AM Sai Prakash Ranjan wrote: Hi Will, On 2020-07-03 19:07, Will Deacon wrote: > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: >> diff --git a/drivers/gpu/drm/msm/msm_iommu.c >> b/drivers/gpu/drm/msm/msm_iommu.c >> index f455c597f76d..bd1d58229cc2 100644 >> --- a/drivers/gpu/drm/msm/msm_iommu.c >> +++ b/drivers/gpu/drm/msm/msm_iommu.c >> @@ -218,6 +218,9 @@ static int msm_iommu_map(struct msm_mmu *mmu, >> uint64_t iova, >> iova |= GENMASK_ULL(63, 49); >> >> >> +if (mmu->features & MMU_FEATURE_USE_SYSTEM_CACHE) >> +prot |= IOMMU_SYS_CACHE_ONLY; > > Given that I think this is the only user of IOMMU_SYS_CACHE_ONLY, then > it > looks like it should actually be a property on the domain because we > never > need to configure it on a per-mapping basis within a domain, and > therefore > it shouldn't be exposed by the IOMMU API as a prot flag. > > Do you agree? > GPU being the only user is for now, but there are other clients which can use this. Plus how do we set the memory attributes if we do not expose this as prot flag? It does appear that the downstream kgsl driver sets this for basically all mappings.. well there is some conditional stuff around DOMAIN_ATTR_USE_LLC_NWA but it seems based on the property of the domain. (Jordan may know more about what that is about.) But looks like there are a lot of different paths into iommu_map in kgsl so I might have missed something. Assuming there isn't some case where we specifically don't want to use the system cache for some mapping, I think it could be a domain attribute that sets an io_pgtable_cfg::quirks flag Ok then we are good to remove unused sys cache prot flag which Will has posted. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 09/14] drm/panfrost: dynamically alloc regulators
We will later introduce regulators managed by OPP.
Only alloc regulators when it's needed. This also help use
to release the regulators only when they are allocated.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_device.c | 14 +-
drivers/gpu/drm/panfrost/panfrost_device.h | 3 +--
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 464da1646398..0b0fb45aee82 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -90,9 +90,11 @@ static int panfrost_regulator_init(struct panfrost_device
*pfdev)
{
int ret, i;
- if (WARN(pfdev->comp->num_supplies > ARRAY_SIZE(pfdev->regulators),
- "Too many supplies in compatible structure.\n"))
- return -EINVAL;
+ pfdev->regulators = devm_kcalloc(pfdev->dev, pfdev->comp->num_supplies,
+sizeof(*pfdev->regulators),
+GFP_KERNEL);
+ if (!pfdev->regulators)
+ return -ENOMEM;
for (i = 0; i < pfdev->comp->num_supplies; i++)
pfdev->regulators[i].supply = pfdev->comp->supply_names[i];
@@ -117,8 +119,10 @@ static int panfrost_regulator_init(struct panfrost_device
*pfdev)
static void panfrost_regulator_fini(struct panfrost_device *pfdev)
{
- regulator_bulk_disable(pfdev->comp->num_supplies,
- pfdev->regulators);
+ if (!pfdev->regulators)
+ return;
+
+ regulator_bulk_disable(pfdev->comp->num_supplies, pfdev->regulators);
}
static void panfrost_pm_domain_fini(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.h
b/drivers/gpu/drm/panfrost/panfrost_device.h
index 2efa59c9d1c5..953f7536a773 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.h
+++ b/drivers/gpu/drm/panfrost/panfrost_device.h
@@ -22,7 +22,6 @@ struct panfrost_job;
struct panfrost_perfcnt;
#define NUM_JOB_SLOTS 3
-#define MAX_REGULATORS 2
#define MAX_PM_DOMAINS 3
struct panfrost_features {
@@ -81,7 +80,7 @@ struct panfrost_device {
void __iomem *iomem;
struct clk *clock;
struct clk *bus_clock;
- struct regulator_bulk_data regulators[MAX_REGULATORS];
+ struct regulator_bulk_data *regulators;
struct reset_control *rstc;
/* pm_domains for devices with more than one. */
struct device *pm_domain_devs[MAX_PM_DOMAINS];
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dummy-backlight
Dear all, I'm working on a simple kernel module currently called "dummy-backlight" (https://github.com/fepitre/dummy-backlight) which creates a testing backlight. After loaded, this driver allows to modify integer values of the virtual backlight created through its sysfs attributes directly. In the context of the Qubes OS project, it allows to setup into a VM, a virtual backlight and managing the hardware backlight into the VM directly thanks to a communication channel with the host system. I'm writing to you to know if you would be interested to have such module into kernel. Another name could be "virtual-backlight". I've written a similar module for PSU too (https://lore.kernel.org/linux-pm/a8223cce-636f-578b-7304-eb0e4868e...@qubes-os.org/) where a nice suggestion of improvement has been made to use a misc device for controlling attributes instead of sysfs directly. Indeed, it's appropriated in case of multiple PSU but maybe for a (only one?) "dummy-backligh", using two sysfs attributes is enough. Any kind of improvements are very welcomed. Thank you. Best regards, Frédéric Pierret signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: adjust entry to renaming and conversion
On Sun, Jul 5, 2020 at 1:30 PM Ondřej Jirman wrote:
>
> Hello Lukas,
>
> On Sun, Jul 05, 2020 at 08:59:17AM +0200, Lukas Bulwahn wrote:
> > Commit a74e81a56405 ("drm/panel: rocktech-jh057n00900: Rename the driver to
> > st7703") and commit 7317f4574492 ("dt-bindings: panel: Convert
> > rocktech,jh057n00900 to yaml") renamed and converted the files mentioned in
> > DRM DRIVER FOR ROCKTECH JH057N00900 PANELS, but did not adjust the entries
> > in MAINTAINERS.
>
> A similar patch was already posted:
>
> https://lkml.kernel.org/lkml/20200701184640.1674969-1-meg...@megous.com/
>
Thanks, Ondrej. This patch posted here shall be IGNORED.
Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/8] soc: mediatek: cmdq: add address shift in jump
Add address shift when compose jump instruction to compatible with 35bit format. Signed-off-by: Dennis YC Hsieh --- drivers/soc/mediatek/mtk-cmdq-helper.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c index dc644cfb6419..9faf78fbed3a 100644 --- a/drivers/soc/mediatek/mtk-cmdq-helper.c +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c @@ -329,7 +329,8 @@ int cmdq_pkt_finalize(struct cmdq_pkt *pkt) /* JUMP to end */ inst.op = CMDQ_CODE_JUMP; - inst.value = CMDQ_JUMP_PASS; + inst.value = CMDQ_JUMP_PASS >> + cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan); err = cmdq_pkt_append_command(pkt, inst); return err; -- 1.7.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)
Hello,
On Friday, 15 May 2020 09:43:54 CEST Neil Armstrong wrote:
>
> On 15/05/2020 00:04, Paul Boddie wrote:
> >
> > Well, I've done this but I probably need to know what to look for. One
> > thing that appears regardless of this debugging output being enabled is a
> > problem with the vertical blanking functionality:
> >
> > WARNING: CPU: 1 PID: 396 at drivers/gpu/drm/drm_atomic_helper.c:1457
> > drm_atomic_helper_wait_for_vblanks+0x1ec/0x25c
> > [CRTC:32:crtc-0] vblank wait timed out
>
> This means the CRTC didn't start, usually because the Pixel clock didn't go
> through the pipeline to the pixel generator, thus not generating
> vblank/vsync interrupts.
>
> You may check if there is not muxes to select the clock source/pixel
> destination.
It has obviously been a while since I asked about the DW-HDMI functionality.
Since then, I have verified the initialisation of the Ingenic JZ4780 LCD
controller and the Synopsys HDMI peripheral in the L4 Runtime Environment
(running on the Fiasco.OC microkernel), producing a picture and handling
display interrupts.
Having brought the necessary changes back to the Ingenic DRM driver, I can
make the driver activate the LCD controller and produce vertical blank
interrupts, and these are handled and counted in /proc/interrupts. The
previous errors about timeouts are now gone.
However, the DRM driver can only be made to start if I set the bus format in
dw_hdmi_bridge_attach:
u32 bus_format[] = { MEDIA_BUS_FMT_RGB888_1X24 };
...
drm_display_info_set_bus_formats(>display_info,
bus_format, ARRAY_SIZE(bus_format));
Without this, the DRM driver will test for a bus format on the connector's
display_info structure in ingenic_drm_encoder_atomic_check and return EINVAL.
There have previously been indications that this should not need to be done,
but I see that other drivers do similar things (for example, ti-tfp410.c).
It also seems to be appropriate to set the input_bus_format on the platform-
specific HDMI driver; otherwise, I doubt that appropriate bus encodings will
be chosen in the Synopsys driver.
[...]
> > Attempting to set a mode using...
> >
> > modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
> >
> > ...yields the following:
> >
> > failed to set mode: Permission denied
> > setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
>
> This is weird, the command line is ok, is it the same for all modes ?
Testing against 5.8-rc3 with the above changes seems to have moved the needle
slightly. Although I still get "Input not supported" from my monitor, running
modetest now gives a different error:
modetest -D /dev/dri/card0 -M ingenic-drm -s 34@32:1280x1024-60.02
...now yields this:
setting mode 1280x1024-60.02Hz@XR24 on connectors 34, crtc 32
failed to set gamma: Invalid argument
There also seems to be a card1, but I get the same result with that, and they
both seem to produce similar output with modetest without the -s option.
Anyway, progress is rather slow trying to figure out the obstruction here, so
any advice would still be appreciated.
Thanks in advance,
Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vc4: Convert register accessors to FIELD_*
The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic
already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to
use the FIELD_* macros.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_regs.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
index b5a6b4cdd332..324462cc9cd4 100644
--- a/drivers/gpu/drm/vc4/vc4_regs.h
+++ b/drivers/gpu/drm/vc4/vc4_regs.h
@@ -6,19 +6,18 @@
#ifndef VC4_REGS_H
#define VC4_REGS_H
+#include
#include
#define VC4_MASK(high, low) ((u32)GENMASK(high, low))
/* Using the GNU statement expression extension */
#define VC4_SET_FIELD(value, field)\
({ \
- uint32_t fieldval = (value) << field##_SHIFT; \
- WARN_ON((fieldval & ~field##_MASK) != 0); \
- fieldval & field##_MASK;\
+ WARN_ON(!FIELD_FIT(field##_MASK, value)); \
+ FIELD_PREP(field##_MASK, value);\
})
-#define VC4_GET_FIELD(word, field) (((word) & field##_MASK) >> \
- field##_SHIFT)
+#define VC4_GET_FIELD(word, field) FIELD_GET(field##_MASK, word)
#define V3D_IDENT0 0x0
# define V3D_EXPECTED_IDENT0 \
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/8] soc: mediatek: cmdq: add write_s_mask value function
add write_s_mask_value function in cmdq helper functions which
writes a constant value to address with mask and large dma
access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 21 +
include/linux/soc/mediatek/mtk-cmdq.h | 15 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 4e86b65815fc..b6e25f216605 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -294,6 +294,27 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask)
+{
+ struct cmdq_instruction inst = {};
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index ae73e10da274..d9390d76ee14 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -165,6 +165,21 @@ int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
u16 addr_low, u32 value);
/**
+ * cmdq_pkt_write_s_mask_value() - append write_s command with mask to the CMDQ
+ *packet which write value to a physical
+ *address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ * @mask: the specified target mask
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value, u32 mask);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 7/8] soc: mediatek: cmdq: add jump function
Add jump function so that client can jump to any address which
contains instruction.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 13 +
include/linux/soc/mediatek/mtk-cmdq.h | 11 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index b6e25f216605..d55dc3296105 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -13,6 +13,7 @@
#define CMDQ_POLL_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_ENBIT(0)
#define CMDQ_REG_TYPE 1
+#define CMDQ_JUMP_RELATIVE 1
struct cmdq_instruction {
union {
@@ -407,6 +408,18 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32
value)
}
EXPORT_SYMBOL(cmdq_pkt_assign);
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_JUMP;
+ inst.offset = CMDQ_JUMP_RELATIVE;
+ inst.value = addr >>
+ cmdq_get_shift_pa(((struct cmdq_client *)pkt->cl)->chan);
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_jump);
+
int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index d9390d76ee14..34354e952f60 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -253,6 +253,17 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
/**
+ * cmdq_pkt_jump() - Append jump command to the CMDQ packet, ask GCE
+ * to execute an instruction that change current thread PC to
+ * a physical address which should contains more instruction.
+ * @pkt:the CMDQ packet
+ * @addr: physical address of target instruction buffer
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_jump(struct cmdq_pkt *pkt, dma_addr_t addr);
+
+/**
* cmdq_pkt_finalize() - Append EOC and jump command to pkt.
* @pkt: the CMDQ packet
*
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] dt-bindings: display: Fix example in nwl-dsi.yaml
The example is now validated against rocktech,jh057n00900 schema
that was ported to yaml, and didn't validate with:
- '#address-cells', '#size-cells', 'port@0' do not match any of
the regexes: 'pinctrl-[0-9]+'
- 'vcc-supply' is a required property
- 'iovcc-supply' is a required property
- 'reset-gpios' is a required property
Fix it.
Signed-off-by: Ondrej Jirman
---
.../devicetree/bindings/display/bridge/nwl-dsi.yaml | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
index 8aff2d68fc33..2c4c34e3bc29 100644
--- a/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
@@ -165,6 +165,7 @@ examples:
- |
#include
+ #include
#include
#include
@@ -191,12 +192,12 @@ examples:
phy-names = "dphy";
panel@0 {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "rocktech,jh057n00900";
reg = <0>;
- port@0 {
- reg = <0>;
+ vcc-supply = <_2v8_p>;
+ iovcc-supply = <_1v8_p>;
+ reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+ port {
panel_in: endpoint {
remote-endpoint = <_dsi_out>;
};
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/14] drm/panfrost: clean headers in devfreq
Don't include not required headers and sort them.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 1b560b903ea6..df7b71da9a84 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -1,18 +1,14 @@
// SPDX-License-Identifier: GPL-2.0
/* Copyright 2019 Collabora ltd. */
+
+#include
#include
#include
#include
#include
-#include
-#include
#include "panfrost_device.h"
#include "panfrost_devfreq.h"
-#include "panfrost_features.h"
-#include "panfrost_issues.h"
-#include "panfrost_gpu.h"
-#include "panfrost_regs.h"
static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/14] drm/panfrost: use spinlock instead of atomic
Convert busy_count to a simple int protected by spinlock.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 43 +++--
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 9 -
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 962550363391..78753cfb59fb 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -12,16 +12,12 @@
static void panfrost_devfreq_update_utilization(struct panfrost_devfreq
*pfdevfreq)
{
- ktime_t now;
- ktime_t last;
-
- if (!pfdevfreq->devfreq)
- return;
+ ktime_t now, last;
now = ktime_get();
last = pfdevfreq->time_last_update;
- if (atomic_read(>busy_count) > 0)
+ if (pfdevfreq->busy_count > 0)
pfdevfreq->busy_time += ktime_sub(now, last);
else
pfdevfreq->idle_time += ktime_sub(now, last);
@@ -59,10 +55,14 @@ static int panfrost_devfreq_get_dev_status(struct device
*dev,
{
struct panfrost_device *pfdev = dev_get_drvdata(dev);
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
+ unsigned long irqflags;
+
+ status->current_frequency = clk_get_rate(pfdev->clock);
+
+ spin_lock_irqsave(>lock, irqflags);
panfrost_devfreq_update_utilization(pfdevfreq);
- status->current_frequency = clk_get_rate(pfdev->clock);
status->total_time = ktime_to_ns(ktime_add(pfdevfreq->busy_time,
pfdevfreq->idle_time));
@@ -70,6 +70,8 @@ static int panfrost_devfreq_get_dev_status(struct device *dev,
panfrost_devfreq_reset(pfdevfreq);
+ spin_unlock_irqrestore(>lock, irqflags);
+
dev_dbg(pfdev->dev, "busy %lu total %lu %lu %% freq %lu MHz\n",
status->busy_time, status->total_time,
status->busy_time / (status->total_time / 100),
@@ -100,6 +102,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
else if (ret)
return ret;
+ spin_lock_init(>lock);
+
panfrost_devfreq_reset(pfdevfreq);
cur_freq = clk_get_rate(pfdev->clock);
@@ -162,15 +166,32 @@ void panfrost_devfreq_suspend(struct panfrost_device
*pfdev)
void panfrost_devfreq_record_busy(struct panfrost_devfreq *pfdevfreq)
{
+ unsigned long irqflags;
+
+ if (!pfdevfreq->devfreq)
+ return;
+
+ spin_lock_irqsave(>lock, irqflags);
+
panfrost_devfreq_update_utilization(pfdevfreq);
- atomic_inc(>busy_count);
+
+ pfdevfreq->busy_count++;
+
+ spin_unlock_irqrestore(>lock, irqflags);
}
void panfrost_devfreq_record_idle(struct panfrost_devfreq *pfdevfreq)
{
- int count;
+ unsigned long irqflags;
+
+ if (!pfdevfreq->devfreq)
+ return;
+
+ spin_lock_irqsave(>lock, irqflags);
panfrost_devfreq_update_utilization(pfdevfreq);
- count = atomic_dec_if_positive(>busy_count);
- WARN_ON(count < 0);
+
+ WARN_ON(--pfdevfreq->busy_count < 0);
+
+ spin_unlock_irqrestore(>lock, irqflags);
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 0697f8d5aa34..3392df1020be 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -4,6 +4,7 @@
#ifndef __PANFROST_DEVFREQ_H__
#define __PANFROST_DEVFREQ_H__
+#include
#include
struct devfreq;
@@ -14,10 +15,16 @@ struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+
ktime_t busy_time;
ktime_t idle_time;
ktime_t time_last_update;
- atomic_t busy_count;
+ int busy_count;
+ /*
+* Protect busy_time, idle_time, time_last_update and busy_count
+* because these can be updated concurrently between multiple jobs.
+*/
+ spinlock_t lock;
};
int panfrost_devfreq_init(struct panfrost_device *pfdev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/14] drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle
This use devfreq variable that will be lock with spinlock in future
patches. We should either introduce a function to access this one
but as devfreq is optional let's just remove it.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_job.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/panfrost/panfrost_job.c
index 7914b1570841..63e32a9f2749 100644
--- a/drivers/gpu/drm/panfrost/panfrost_job.c
+++ b/drivers/gpu/drm/panfrost/panfrost_job.c
@@ -581,10 +581,6 @@ int panfrost_job_is_idle(struct panfrost_device *pfdev)
struct panfrost_job_slot *js = pfdev->js;
int i;
- /* Check whether the hardware is idle */
- if (atomic_read(>devfreq.busy_count))
- return false;
-
for (i = 0; i < NUM_JOB_SLOTS; i++) {
/* If there are any jobs in the HW queue, we're not idle */
if (atomic_read(>queue[i].sched.hw_rq_count))
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 8/8] soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
Add clear parameter to let client decide if
event should be clear to 0 after GCE receive it.
Fixes: 2f965be7f9008 ("drm/mediatek: apply CMDQ control flow")
Signed-off-by: Dennis YC Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c |2 +-
drivers/soc/mediatek/mtk-cmdq-helper.c |5 +++--
include/linux/mailbox/mtk-cmdq-mailbox.h |3 +--
include/linux/soc/mediatek/mtk-cmdq.h|5 +++--
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index ec6c9ffbf35e..ba6cf956b239 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -490,7 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc
*mtk_crtc)
mbox_flush(mtk_crtc->cmdq_client->chan, 2000);
cmdq_handle = cmdq_pkt_create(mtk_crtc->cmdq_client, PAGE_SIZE);
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
- cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
+ cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event, false);
mtk_crtc_ddp_config(crtc, cmdq_handle);
cmdq_pkt_finalize(cmdq_handle);
cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index d55dc3296105..505651b0d715 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -316,15 +316,16 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask_value);
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear)
{
struct cmdq_instruction inst = { {0} };
+ u32 clear_option = clear ? CMDQ_WFE_UPDATE : 0;
if (event >= CMDQ_MAX_EVENT)
return -EINVAL;
inst.op = CMDQ_CODE_WFE;
- inst.value = CMDQ_WFE_OPTION;
+ inst.value = CMDQ_WFE_OPTION | clear_option;
inst.event = event;
return cmdq_pkt_append_command(pkt, inst);
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index efbd8a9eb2d1..d5a983d65f05 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -28,8 +28,7 @@
* bit 16-27: update value
* bit 31: 1 - update, 0 - no update
*/
-#define CMDQ_WFE_OPTION(CMDQ_WFE_UPDATE |
CMDQ_WFE_WAIT | \
- CMDQ_WFE_WAIT_VALUE)
+#define CMDQ_WFE_OPTION(CMDQ_WFE_WAIT |
CMDQ_WFE_WAIT_VALUE)
/** cmdq event maximum */
#define CMDQ_MAX_EVENT 0x3ff
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 34354e952f60..960704d75994 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -182,11 +182,12 @@ int cmdq_pkt_write_s_mask_value(struct cmdq_pkt *pkt, u8
high_addr_reg_idx,
/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
- * @event: the desired event type to "wait and CLEAR"
+ * @event: the desired event type to wait
+ * @clear: clear event or not after event arrive
*
* Return: 0 for success; else the error code is returned
*/
-int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event);
+int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event, bool clear);
/**
* cmdq_pkt_clear_event() - append clear event command to the CMDQ packet
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sun4i: lvds: Invert the LVDS polarity
The LVDS controller can invert the polarity / lanes of the LVDS output. The default polarity causes some issues on some panels. However, U-Boot has always used the opposite polarity without any reported issue, and the only currently supported LVDS panel in-tree (the TBS A711) seems to be able to work with both settings. Let's just use the same polarity than U-Boot to be more consistent and hopefully support all the panels. Cc: Ondrej Jirman Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 359b56e43b83..e44635ebd510 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c @@ -474,9 +474,7 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon *tcon, SUN4I_TCON0_BASIC2_V_TOTAL(mode->crtc_vtotal * 2) | SUN4I_TCON0_BASIC2_V_BACKPORCH(bp)); - reg = SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0 | - SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL | - SUN4I_TCON0_LVDS_IF_CLK_POL_NORMAL; + reg = SUN4I_TCON0_LVDS_IF_CLK_SEL_TCON0; if (sun4i_tcon_get_pixel_depth(encoder) == 24) reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS; else -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 14/14] [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always
Hi,
On Sat, 4 Jul 2020 at 12:25, Clément Péron wrote:
>
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> index 3f7ceeb1a767..14257f7476b8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> @@ -245,6 +245,7 @@ reg_dcdca: dcdca {
> };
>
> reg_dcdcc: dcdcc {
> + regulator-always-on;
This patch is normally no more required since this serie:
https://lore.kernel.org/linux-pm/cover.1589528491.git.viresh.ku...@linaro.org/
> regulator-enable-ramp-delay = <32000>;
> regulator-min-microvolt = <81>;
> regulator-max-microvolt = <108>;
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
sam,
I will change to "GPL-2.0-only OR BSD-2-Clause", i thought running
dt_binding_check is enough for .yaml.
On Fri, Jul 3, 2020 at 8:36 PM Sam Ravnborg wrote:
>
> Hi Vinay.
>
> On Thu, Jul 02, 2020 at 06:06:33PM +0530, Vinay Simha BN wrote:
> > Signed-off-by: Vinay Simha BN
> >
> > ---
> > v1:
> > Initial version wast .txt file
> >
> > v2:
> > From txt to yaml file format
> >
> > v3:
> > * Andrzej Hajda review comments incorporated
> > dual port lvds implemented
> >
> > * Laurent Pinchart review comments incorporated
> > dsi lanes property removed and it is dynamically
> > picked from the dsi ports
> > VESA/JEIDA format picked from panel-lvds dts
> >
> > v4:
> > * Sam Ravnborg review comments incorporated
> > }' is indented properly in examples data-lanes
> > description for single-link and dual-link lvds
> > ---
> > .../display/bridge/toshiba,tc358775.yaml | 215 ++
> > 1 file changed, 215 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> > new file mode 100644
> > index ..9ddd63bee403
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> > @@ -0,0 +1,215 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> One detail that I missed - any specific reason this is not (GPL-2.0-only OR
> BSD-2-Clause)
> This is the preferred license for new bindings - as checkpatch also
> tells you.
>
> Sam
>
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toshiba TC358775 DSI to LVDS bridge bindings
> > +
> > +maintainers:
> > + - Vinay Simha BN
> > +
> > +description: |
> > + This binding supports DSI to LVDS bridge TC358775
> > +
> > + MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane.
> > + Video frame size:
> > + Up to 1600x1200 24-bit/pixel resolution for single-link LVDS display panel
> > + limited by 135 MHz LVDS speed
> > + Up to WUXGA (1920x1200 24-bit pixels) resolution for dual-link LVDS
> > display
> > + panel, limited by 270 MHz LVDS speed.
> > +
> > +properties:
> > + compatible:
> > +const: toshiba,tc358775
> > +
> > + reg:
> > +maxItems: 1
> > +description: i2c address of the bridge, 0x0f
> > +
> > + vdd-supply:
> > +maxItems: 1
> > +description: 1.2V LVDS Power Supply
> > +
> > + vddio-supply:
> > +maxItems: 1
> > +description: 1.8V IO Power Supply
> > +
> > + stby-gpios:
> > +maxItems: 1
> > +description: Standby pin, Low active
> > +
> > + reset-gpios:
> > +maxItems: 1
> > +description: Hardware reset, Low active
> > +
> > + ports:
> > +type: object
> > +description:
> > + A node containing input and output port nodes with endpoint
> > definitions
> > + as documented in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > +properties:
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + port@0:
> > +type: object
> > +description: |
> > + DSI Input. The remote endpoint phandle should be a
> > + reference to a valid mipi_dsi_host device node.
> > +
> > + port@1:
> > +type: object
> > +description: |
> > + Video port for LVDS output (panel or connector).
> > +
> > + port@2:
> > +type: object
> > +description: |
> > + Video port for Dual link LVDS output (panel or connector).
> > +
> > +required:
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vdd-supply
> > + - vddio-supply
> > + - stby-gpios
> > + - reset-gpios
> > + - ports
> > +
> > +examples:
> > + - |
> > +#include
> > +
> > +/* For single-link LVDS display panel */
> > +
> > +i2c@78b8000 {
> > +/* On High speed expansion */
> > +label = "HS-I2C2";
> > +reg = <0x078b8000 0x500>;
> > +clock-frequency = <40>; /* fastmode operation */
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +tc_bridge: bridge@f {
> > +compatible = "toshiba,tc358775";
> > +reg = <0x0f>;
> > +
> > +vdd-supply = <_l2>;
> > +vddio-supply = <_l6>;
> > +
> > +stby-gpios = < 99 GPIO_ACTIVE_LOW>;
> > +reset-gpios = < 72 GPIO_ACTIVE_LOW>;
> > +
> > +ports {
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> > +
> > +port@0 {
> > +reg = <0>;
> > +d2l_in_test: endpoint {
> > +remote-endpoint = <_out>;
> > +
[PATCH v2 4/8] soc: mediatek: cmdq: add read_s function
Add read_s function in cmdq helper functions which support read value from
register or dma physical address into gce internal register.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 15 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 12
3 files changed, 28 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 550e9e7e3ff2..ed9f5e63c195 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -227,6 +227,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+ u16 reg_idx)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_READ_S;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.reg_dst = reg_idx;
+ inst.src_reg = addr_low;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_read_s);
+
int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx)
{
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 90d1d8e64412..efbd8a9eb2d1 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_READ_S = 0x80,
CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 53230341bf94..cd7ec714344e 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -104,6 +104,18 @@ struct cmdq_client *cmdq_mbox_create(struct device *dev,
int index,
int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
+/*
+ * cmdq_pkt_read_s() - append read_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @reg_idx: the CMDQ internal register ID to cache read data
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_read_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx, u16 addr_low,
+ u16 reg_idx);
+
/**
* cmdq_pkt_write_s() - append write_s command to the CMDQ packet
* @pkt: the CMDQ packet
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 11/14] arm64: defconfig: Enable devfreq cooling device
Devfreq cooling device framework is used in Panfrost to throttle GPU in order to regulate its temperature. Enable this driver for ARM64 SoC. Signed-off-by: Clément Péron --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 883e8bace3ed..1b7f9ffdc314 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -501,6 +501,7 @@ CONFIG_SENSORS_INA2XX=m CONFIG_SENSORS_INA3221=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y +CONFIG_DEVFREQ_THERMAL=y CONFIG_THERMAL_EMULATION=y CONFIG_QORIQ_THERMAL=m CONFIG_SUN8I_THERMAL=y -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix spelling mistake in i915_reg.h
Fix typo: "TRIGER" --> "TRIGGER" The two misplelled macros: 1) OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 2) OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK are not used in any other sources of the kernel, so this change can be consider only a local change for the i915_reg.h file. Signed-off-by: Flavio Suligoi --- drivers/gpu/drm/i915/i915_reg.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9d6536afc94b..c2153364724a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -868,7 +868,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OAREPORTTRIG1 _MMIO(0x2740) #define OAREPORTTRIG1_THRESHOLD_MASK 0x -#define OAREPORTTRIG1_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ +#define OAREPORTTRIG1_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ #define OAREPORTTRIG2 _MMIO(0x2744) #define OAREPORTTRIG2_INVERT_A_0 (1 << 0) @@ -921,7 +921,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define OAREPORTTRIG5 _MMIO(0x2750) #define OAREPORTTRIG5_THRESHOLD_MASK 0x -#define OAREPORTTRIG5_EDGE_LEVEL_TRIGER_SELECT_MASK 0x /* 0=level */ +#define OAREPORTTRIG5_EDGE_LEVEL_TRIGGER_SELECT_MASK 0x /* 0=level */ #define OAREPORTTRIG6 _MMIO(0x2754) #define OAREPORTTRIG6_INVERT_A_0 (1 << 0) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] MAINTAINERS: adjust entry to renaming and conversion
Hello Lukas,
On Sun, Jul 05, 2020 at 08:59:17AM +0200, Lukas Bulwahn wrote:
> Commit a74e81a56405 ("drm/panel: rocktech-jh057n00900: Rename the driver to
> st7703") and commit 7317f4574492 ("dt-bindings: panel: Convert
> rocktech,jh057n00900 to yaml") renamed and converted the files mentioned in
> DRM DRIVER FOR ROCKTECH JH057N00900 PANELS, but did not adjust the entries
> in MAINTAINERS.
A similar patch was already posted:
https://lkml.kernel.org/lkml/20200701184640.1674969-1-meg...@megous.com/
thank you and regards,
o.
> Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
>
> warning: no file matches F: \
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> warning: no file matches F: \
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
>
> Adjust entries after this file renaming and devicetree conversion.
>
> Signed-off-by: Lukas Bulwahn
> ---
> applies cleanly on next-20200703
>
> Ondrej, please ack this patch.
> Sam, please pick this minor non-urgent patch into your -next tree.
>
> This is the minimal change to address the warning. You might consider
> changing the name of the section from ROCKTECH to ST7703, change
> maintainers etc.
>
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9375edaef11f..8a7b92faff99 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5493,8 +5493,8 @@ DRM DRIVER FOR ROCKTECH JH057N00900 PANELS
> M: Guido Günther
> R: Purism Kernel Team
> S: Maintained
> -F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
> -F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
> +F:
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> +F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
>
> DRM DRIVER FOR SAVAGE VIDEO CARDS
> S: Orphan / Obsolete
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/8] soc: mediatek: cmdq: add write_s_mask function
add write_s_mask function in cmdq helper functions which
writes value contains in internal register to address
with mask and large dma access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 23 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 18 ++
3 files changed, 42 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 880349b3f16c..550e9e7e3ff2 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -242,6 +242,29 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s);
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask)
+{
+ struct cmdq_instruction inst = {};
+ int err;
+
+ inst.op = CMDQ_CODE_MASK;
+ inst.mask = ~mask;
+ err = cmdq_pkt_append_command(pkt, inst);
+ if (err < 0)
+ return err;
+
+ inst.mask = 0;
+ inst.op = CMDQ_CODE_WRITE_S_MASK;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 1f76cfedb16d..90d1d8e64412 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -61,6 +61,7 @@ enum cmdq_code {
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
CMDQ_CODE_WRITE_S = 0x90,
+ CMDQ_CODE_WRITE_S_MASK = 0x91,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 9b0c57a0063d..53230341bf94 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -122,6 +122,24 @@ int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx);
/**
+ * cmdq_pkt_write_s_mask() - append write_s with mask command to the CMDQ
packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ * @mask: the specified target address mask, use U32_MAX if no need
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+ u16 addr_low, u16 src_reg_idx, u32 mask);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Add an Operating Performance Points table for the GPU to
enable Dynamic Voltage & Frequency Scaling on the H6.
The voltage range is set with minival voltage set to the target
and the maximal voltage set to 1.2V. This allow DVFS framework to
work properly on board with fixed regulator.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 8f514a2169aa..a69f9e09a829 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -174,6 +174,7 @@ gpu: gpu@180 {
clocks = < CLK_GPU>, < CLK_BUS_GPU>;
clock-names = "core", "bus";
resets = < RST_BUS_GPU>;
+ operating-points-v2 = <_opp_table>;
#cooling-cells = <2>;
status = "disabled";
};
@@ -1036,4 +1037,83 @@ map0 {
};
};
};
+
+ gpu_opp_table: gpu-opp-table {
+ compatible = "operating-points-v2";
+
+ opp@21600 {
+ opp-hz = /bits/ 64 <21600>;
+ opp-microvolt = <81 81 120>;
+ };
+
+ opp@26400 {
+ opp-hz = /bits/ 64 <26400>;
+ opp-microvolt = <81 81 120>;
+ };
+
+ opp@31200 {
+ opp-hz = /bits/ 64 <31200>;
+ opp-microvolt = <81 81 120>;
+ };
+
+ opp@33600 {
+ opp-hz = /bits/ 64 <33600>;
+ opp-microvolt = <81 81 120>;
+ };
+
+ opp@36000 {
+ opp-hz = /bits/ 64 <36000>;
+ opp-microvolt = <82 82 120>;
+ };
+
+ opp@38400 {
+ opp-hz = /bits/ 64 <38400>;
+ opp-microvolt = <83 83 120>;
+ };
+
+ opp@40800 {
+ opp-hz = /bits/ 64 <40800>;
+ opp-microvolt = <84 84 120>;
+ };
+
+ opp@42000 {
+ opp-hz = /bits/ 64 <42000>;
+ opp-microvolt = <85 85 120>;
+ };
+
+ opp@43200 {
+ opp-hz = /bits/ 64 <43200>;
+ opp-microvolt = <86 86 120>;
+ };
+
+ opp@45600 {
+ opp-hz = /bits/ 64 <45600>;
+ opp-microvolt = <87 87 120>;
+ };
+
+ opp@50400 {
+ opp-hz = /bits/ 64 <50400>;
+ opp-microvolt = <89 89 120>;
+ };
+
+ opp@54000 {
+ opp-hz = /bits/ 64 <54000>;
+ opp-microvolt = <91 91 120>;
+ };
+
+ opp@57600 {
+ opp-hz = /bits/ 64 <57600>;
+ opp-microvolt = <93 93 120>;
+ };
+
+ opp@62400 {
+ opp-hz = /bits/ 64 <62400>;
+ opp-microvolt = <95 95 120>;
+ };
+
+ opp@75600 {
+ opp-hz = /bits/ 64 <75600>;
+ opp-microvolt = <104 104 120>;
+ };
+ };
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 2/2] display/drm/bridge: TC358775 DSI/LVDS driver
This driver is tested with two panels individually with Apq8016-IFC6309 board https://www.inforcecomputing.com/products/single-board-computers-sbc/qualcomm-snapdragon-410-inforce-6309-micro-sbc 1. 1366x768@60 auo,b101xtn01 data-mapping = "jeida-24" 2. 800x480@60 innolux,at070tn92 data-mapping = "vesa-24" - added SPDX identifier license - updated alphabetic order of headers - replaced u32 instead of uint32_t - magic number to macros for CLRSI and mux registers - mdelay to usleep_range - added bus_formats - removed drm_connector_status - regulator enable and disable with proper orders and delays as per the spec - devm_drm_panel_bridge_add method used instead of panel description modified - dual port implemented - panel->connector_type removed - ~vsdelay dynamic value set based on the calculation of dsi speed, output speed, blanking - help modified - display_timings naming local variables - check for bus_formats unsupported - error handling enpoint data-lanes - Kconfig proper indentation - GENMASK and FIELD_PREP used - bus_formats handeld in mode_valid - MODE_CLOCK_HIGH handled properly - len initialized - static function for mode_valid Signed-off-by: Vinay Simha BN --- v1: Initial version v2: * Andrzej Hajda review comments incorporated SPDX identifier development debug removed alphabetic order headers u32 instead of unit32_t magic numbers to macros for CLRSI and mux registers ignored return value * Laurent Pinchart review comments incorporated mdelay to usleep_range bus_formats added v3: * Andrzej Hajda review comments incorporated drm_connector_status removed u32 rev removed and local variabl is used regulator enable disable with proper orders and delays as per the spec devm_drm_panel_bridge_add method used instead of panel description modified dual port implemented v4: * Sam Ravnborg review comments incorporated panel->connector_type removed * Reported-by: kernel test robot parse_dt to static function removed the if (endpoint), since data-lanes has to be present for dsi dts ports v5: ~vsdelay dynamic value set based on the calculation of dsi speed, output speed, blanking v6: * Sam Ravnborg review comments incorporated help modified display_timings naming local variables check for bus_formats unsupported error handling enpoint data-lanes v7: * Sam Ravnborg review comments incorporated Kconfig proper indentation GENMASK and FIELD_PREP used bus_formats handeld in mode_valid MODE_CLOCK_HIGH handled properly * Reported-by: kernel test robot len initialized static function for mode_valid --- drivers/gpu/drm/bridge/Kconfig| 10 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/tc358775.c | 757 ++ 3 files changed, 768 insertions(+) create mode 100644 drivers/gpu/drm/bridge/tc358775.c diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 43271c21d3fc..25c3097c4003 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -181,6 +181,16 @@ config DRM_TOSHIBA_TC358768 help Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. +config DRM_TOSHIBA_TC358775 + tristate "Toshiba TC358775 DSI/LVDS bridge" + depends on OF + select DRM_KMS_HELPER + select REGMAP_I2C + select DRM_PANEL + select DRM_MIPI_DSI + help + Toshiba TC358775 DSI/LVDS bridge chip driver. + config DRM_TI_TFP410 tristate "TI TFP410 DVI/HDMI bridge" depends on OF diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile index d63d4b7e4347..23c770b3bfe4 100644 --- a/drivers/gpu/drm/bridge/Makefile +++ b/drivers/gpu/drm/bridge/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o +obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o diff --git a/drivers/gpu/drm/bridge/tc358775.c b/drivers/gpu/drm/bridge/tc358775.c new file mode 100644 index ..6494179369a6 --- /dev/null +++ b/drivers/gpu/drm/bridge/tc358775.c @@ -0,0 +1,757 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * tc358775 DSI to LVDS bridge driver + * + * Copyright (C) 2020 SMART Wireless Computing + * Author: Vinay Simha BN + * + */ +/* #define DEBUG */ +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include + +#define FLD_VAL(val, start, end) FIELD_PREP(GENMASK(start, end), val) + +/* Registers */ + +/* DSI D-PHY Layer Registers */ +#define D0W_DPHYCONTTX 0x0004 /* Data Lane 0 DPHY Tx Control */ +#define CLW_DPHYCONTRX 0x0020 /* Clock Lane DPHY
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Thu, Jul 02, 2020 at 08:15:40PM +0200, Daniel Vetter wrote: > > > > 3. rdma driver worker gets busy to restart rx: > > > > 1. lock all dma-buf that are currently in use (dma_resv_lock). > > > > thanks to ww_mutex deadlock avoidance this is possible > > > Why all? Why not just lock the one that was invalidated to restore the > > > mappings? That is some artifact of the GPU approach? > > > > No, but you must make sure that mapping one doesn't invalidate others you > > need. > > > > Otherwise you can end up in a nice live lock :) > > Also if you don't have pagefaults, but have to track busy memory at a > context level, you do need to grab all locks of all buffers you need, or > you'd race. There's nothing stopping a concurrent ->notify_move on some > other buffer you'll need otherwise, and if you try to be clever and roll > you're own locking, you'll anger lockdep - you're own lock will have to be > on both sides of ww_mutex or it wont work, and that deadlocks. So you are worried about atomically building some multi buffer transaction? I don't think this applies to RDMA which isn't going to be transcational here.. > > > And why is this done with work queues and locking instead of a > > > callback saying the buffer is valid again? > > > > You can do this as well, but a work queue is usually easier to handle than a > > notification in an interrupt context of a foreign driver. > > Yeah you can just install a dma_fence callback but > - that's hardirq context > - if you don't have per-page hw faults you need the multi-lock ww_mutex > dance anyway to avoid races. It is still best to avoid the per-page faults and preload the new mapping once it is ready. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/14] [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table
Hi Maxime,
On Sat, 4 Jul 2020 at 14:13, Maxime Ripard wrote:
>
> Hi,
>
> On Sat, Jul 04, 2020 at 12:25:34PM +0200, Clément Péron wrote:
> > Add an Operating Performance Points table for the GPU to
> > enable Dynamic Voltage & Frequency Scaling on the H6.
> >
> > The voltage range is set with minival voltage set to the target
> > and the maximal voltage set to 1.2V. This allow DVFS framework to
> > work properly on board with fixed regulator.
> >
> > Signed-off-by: Clément Péron
>
> That patch seems reasonable, why shouldn't we merge it?
I didn't test it a lot and last time I did, some frequencies looked unstable.
https://lore.kernel.org/patchwork/cover/1239739/
This series adds regulator support to Panfrost devfreq, I will send a
new one if DVFS on the H6 GPU is stable.
I got this running glmark2 last time
# glmark2-es2-drm
===
glmark2 2017.07
===
OpenGL Information
GL_VENDOR: Panfrost
GL_RENDERER: Mali T720 (Panfrost)
GL_VERSION:OpenGL ES 2.0 Mesa 20.0.5
===
[ 93.550063] panfrost 180.gpu: GPU Fault 0x0088 (UNKNOWN) at
0x80117100
[ 94.045401] panfrost 180.gpu: gpu sched timeout, js=0,
config=0x3700, status=0x8, head=0x21d6c00, tail=0x21d6c00,
sched_job=e3c2132f
[ 328.871070] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
0x
[ 328.871070] Reason: TODO
[ 328.871070] raw fault status: 0xAA0003C2
[ 328.871070] decoded fault status: SLAVE FAULT
[ 328.871070] exception type 0xC2: TRANSLATION_FAULT_LEVEL2
[ 328.871070] access type 0x3: WRITE
[ 328.871070] source id 0xAA00
[ 329.373327] panfrost 180.gpu: gpu sched timeout, js=1,
config=0x3700, status=0x8, head=0xa1a4900, tail=0xa1a4900,
sched_job=7ac31097
[ 329.386527] panfrost 180.gpu: js fault, js=0,
status=DATA_INVALID_FAULT, head=0xa1a4c00, tail=0xa1a4c00
[ 329.396293] panfrost 180.gpu: gpu sched timeout, js=0,
config=0x3700, status=0x58, head=0xa1a4c00, tail=0xa1a4c00,
sched_job=04c90381
[ 329.411521] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
0x
[ 329.411521] Reason: TODO
[ 329.411521] raw fault status: 0xAA0003C2
[ 329.411521] decoded fault status: SLAVE FAULT
[ 329.411521] exception type 0xC2: TRANSLATION_FAULT_LEVEL2
[ 329.411521] access type 0x3: WRITE
[ 329.411521] source id 0xAA00
Regards,
Clement
>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
> > 1 file changed, 80 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index 8f514a2169aa..a69f9e09a829 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -174,6 +174,7 @@ gpu: gpu@180 {
> > clocks = < CLK_GPU>, < CLK_BUS_GPU>;
> > clock-names = "core", "bus";
> > resets = < RST_BUS_GPU>;
> > + operating-points-v2 = <_opp_table>;
> > #cooling-cells = <2>;
> > status = "disabled";
> > };
> > @@ -1036,4 +1037,83 @@ map0 {
> > };
> > };
> > };
> > +
> > + gpu_opp_table: gpu-opp-table {
> > + compatible = "operating-points-v2";
> > +
> > + opp@21600 {
> > + opp-hz = /bits/ 64 <21600>;
> > + opp-microvolt = <81 81 120>;
> > + };
>
> All those nodes will create DTC warnings though.
>
> Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/14] drm/panfrost: add regulators to devfreq
Some OPP tables specify voltage for each frequency. Devfreq can
handle these regulators but they should be get only 1 time to avoid
issue and know who is in charge.
If OPP table is probe don't init regulator.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 19 +++
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 2 ++
drivers/gpu/drm/panfrost/panfrost_device.c | 11 +++
3 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index d9007f44b772..d1e3e9d00a48 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -93,6 +93,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
unsigned long cur_freq;
struct device *dev = >pdev->dev;
struct devfreq *devfreq;
+ struct opp_table *opp_table;
struct thermal_cooling_device *cooling;
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
@@ -105,6 +106,19 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
spin_lock_init(>lock);
+ opp_table = dev_pm_opp_set_regulators(dev, pfdev->comp->supply_names,
+ pfdev->comp->num_supplies);
+ if (IS_ERR(opp_table)) {
+ ret = PTR_ERR(opp_table);
+ /* Continue if the optional regulator is missing */
+ if (ret != -ENODEV) {
+ DRM_DEV_ERROR(dev, "Couldn't set OPP regulators\n");
+ goto err_fini;
+ }
+ } else {
+ pfdevfreq->regulators_opp_table = opp_table;
+ }
+
panfrost_devfreq_reset(pfdevfreq);
cur_freq = clk_get_rate(pfdev->clock);
@@ -153,6 +167,11 @@ void panfrost_devfreq_fini(struct panfrost_device *pfdev)
dev_pm_opp_of_remove_table(>pdev->dev);
pfdevfreq->opp_of_table_added = false;
}
+
+ if (pfdevfreq->regulators_opp_table) {
+ dev_pm_opp_put_regulators(pfdevfreq->regulators_opp_table);
+ pfdevfreq->regulators_opp_table = NULL;
+ }
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 210269944687..db6ea48e21f9 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -8,12 +8,14 @@
#include
struct devfreq;
+struct opp_table;
struct thermal_cooling_device;
struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
+ struct opp_table *regulators_opp_table;
struct thermal_cooling_device *cooling;
bool opp_of_table_added;
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 0b0fb45aee82..1b5fc9221828 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -223,10 +223,13 @@ int panfrost_device_init(struct panfrost_device *pfdev)
goto out_clk;
}
- err = panfrost_regulator_init(pfdev);
- if (err) {
- dev_err(pfdev->dev, "regulator init failed %d\n", err);
- goto out_devfreq;
+ /* OPP will handle regulators */
+ if (!pfdev->pfdevfreq.opp_of_table_added) {
+ err = panfrost_regulator_init(pfdev);
+ if (err) {
+ dev_err(pfdev->dev, "regulator init failed %d\n", err);
+ goto out_devfreq;
+ }
}
err = panfrost_reset_init(pfdev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 12/14] arm64: dts: allwinner: h6: Add cooling map for GPU
Add a simple cooling map for the GPU.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 22
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 78b1361dfbb9..8f514a2169aa 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -174,6 +174,7 @@ gpu: gpu@180 {
clocks = < CLK_GPU>, < CLK_BUS_GPU>;
clock-names = "core", "bus";
resets = < RST_BUS_GPU>;
+ #cooling-cells = <2>;
status = "disabled";
};
@@ -1012,6 +1013,27 @@ gpu-thermal {
polling-delay-passive = <0>;
polling-delay = <0>;
thermal-sensors = < 1>;
+
+ trips {
+ gpu_alert: gpu-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ gpu-crit {
+ temperature = <10>;
+ hysteresis = <0>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <_alert>;
+ cooling-device = < THERMAL_NO_LIMIT
THERMAL_NO_LIMIT>;
+ };
+ };
};
};
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
- converted from .txt to .yaml
- dual-link lvds port added and implemented
- dsi data-lanes property removed, it will be picked
from dsi0 ports
- VESA/JEIDA formats picked from panel-lvds dts
- proper indentation
- single-link and dual-link lvds description and
examples are added
- license modified to (GPL-2.0-only OR BSD-2-Clause)
Signed-off-by: Vinay Simha BN
---
v1:
Initial version wast .txt file
v2:
From txt to yaml file format
v3:
* Andrzej Hajda review comments incorporated
dual port lvds implemented
* Laurent Pinchart review comments incorporated
dsi lanes property removed and it is dynamically
picked from the dsi ports
VESA/JEIDA format picked from panel-lvds dts
v4:
* Sam Ravnborg review comments incorporated
}' is indented properly in examples data-lanes
description for single-link and dual-link lvds
v5:
* Sam Ravnborg review comments incorporated
license modified to (GPL-2.0-only OR BSD-2-Clause)
changelog added
---
.../display/bridge/toshiba,tc358775.yaml | 215 ++
1 file changed, 215 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
diff --git
a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
new file mode 100644
index ..31f085d8ab13
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
@@ -0,0 +1,215 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba TC358775 DSI to LVDS bridge bindings
+
+maintainers:
+ - Vinay Simha BN
+
+description: |
+ This binding supports DSI to LVDS bridge TC358775
+
+ MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane.
+ Video frame size:
+ Up to 1600x1200 24-bit/pixel resolution for single-link LVDS display panel
+ limited by 135 MHz LVDS speed
+ Up to WUXGA (1920x1200 24-bit pixels) resolution for dual-link LVDS display
+ panel, limited by 270 MHz LVDS speed.
+
+properties:
+ compatible:
+const: toshiba,tc358775
+
+ reg:
+maxItems: 1
+description: i2c address of the bridge, 0x0f
+
+ vdd-supply:
+maxItems: 1
+description: 1.2V LVDS Power Supply
+
+ vddio-supply:
+maxItems: 1
+description: 1.8V IO Power Supply
+
+ stby-gpios:
+maxItems: 1
+description: Standby pin, Low active
+
+ reset-gpios:
+maxItems: 1
+description: Hardware reset, Low active
+
+ ports:
+type: object
+description:
+ A node containing input and output port nodes with endpoint definitions
+ as documented in
+ Documentation/devicetree/bindings/media/video-interfaces.txt
+properties:
+ "#address-cells":
+const: 1
+
+ "#size-cells":
+const: 0
+
+ port@0:
+type: object
+description: |
+ DSI Input. The remote endpoint phandle should be a
+ reference to a valid mipi_dsi_host device node.
+
+ port@1:
+type: object
+description: |
+ Video port for LVDS output (panel or connector).
+
+ port@2:
+type: object
+description: |
+ Video port for Dual link LVDS output (panel or connector).
+
+required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+ - stby-gpios
+ - reset-gpios
+ - ports
+
+examples:
+ - |
+#include
+
+/* For single-link LVDS display panel */
+
+i2c@78b8000 {
+/* On High speed expansion */
+label = "HS-I2C2";
+reg = <0x078b8000 0x500>;
+clock-frequency = <40>; /* fastmode operation */
+#address-cells = <1>;
+#size-cells = <0>;
+
+tc_bridge: bridge@f {
+compatible = "toshiba,tc358775";
+reg = <0x0f>;
+
+vdd-supply = <_l2>;
+vddio-supply = <_l6>;
+
+stby-gpios = < 99 GPIO_ACTIVE_LOW>;
+reset-gpios = < 72 GPIO_ACTIVE_LOW>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+d2l_in_test: endpoint {
+remote-endpoint = <_out>;
+};
+};
+
+port@1 {
+reg = <1>;
+lvds_out: endpoint {
+remote-endpoint = <_in>;
+};
+};
+};
+};
+};
+
+dsi@1a98000 {
+reg = <0x1a98000 0x25c>;
+reg-names = "dsi_ctrl";
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+port@1 {
+reg = <1>;
+dsi0_out: endpoint {
+remote-endpoint = <_in_test>;
+
[PATCH v2 5/8] soc: mediatek: cmdq: add write_s value function
add write_s function in cmdq helper functions which
writes a constant value to address with large dma
access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 14 ++
include/linux/soc/mediatek/mtk-cmdq.h | 13 +
2 files changed, 27 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index ed9f5e63c195..4e86b65815fc 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -280,6 +280,20 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
}
EXPORT_SYMBOL(cmdq_pkt_write_s_mask);
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.value = value;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s_value);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index cd7ec714344e..ae73e10da274 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,19 @@ int cmdq_pkt_write_s_mask(struct cmdq_pkt *pkt, u16
high_addr_reg_idx,
u16 addr_low, u16 src_reg_idx, u32 mask);
/**
+ * cmdq_pkt_write_s_value() - append write_s command to the CMDQ packet which
+ * write value to a physical address
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @value: the specified target value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_write_s_value(struct cmdq_pkt *pkt, u8 high_addr_reg_idx,
+ u16 addr_low, u32 value);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 00/14] Add regulator devfreq support to Panfrost
Hi, This serie cleans and adds regulator support to Panfrost devfreq. This is mostly based on comment for the freshly introduced lima devfreq. We need to add regulator support because on Allwinner the GPU OPP table defines both frequencies and voltages. First patches [01-07] should not change the actual behavior and introduce a proper panfrost_devfreq struct. Regards, Clément Clément Péron (14): drm/panfrost: avoid static declaration drm/panfrost: clean headers in devfreq drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle drm/panfrost: introduce panfrost_devfreq struct drm/panfrost: use spinlock instead of atomic drm/panfrost: properly handle error in probe drm/panfrost: rename error labels in device_init drm/panfrost: move devfreq_init()/fini() in device drm/panfrost: dynamically alloc regulators drm/panfrost: add regulators to devfreq arm64: defconfig: Enable devfreq cooling device arm64: dts: allwinner: h6: Add cooling map for GPU [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 + arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 102 +++ arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/panfrost/panfrost_devfreq.c | 165 -- drivers/gpu/drm/panfrost/panfrost_devfreq.h | 30 +++- drivers/gpu/drm/panfrost/panfrost_device.c| 61 --- drivers/gpu/drm/panfrost/panfrost_device.h| 14 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 15 +- drivers/gpu/drm/panfrost/panfrost_job.c | 10 +- 9 files changed, 290 insertions(+), 109 deletions(-) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dt-binding: display: Allow a single port node on rocktech, jh057n00900
The display has one port. Allow it in the binding. Signed-off-by: Ondrej Jirman --- .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml index a6985cd947fb..d5733ef30954 100644 --- a/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml +++ b/Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml @@ -24,6 +24,7 @@ properties: # Xingbangda XBD599 5.99" 720x1440 TFT LCD panel - xingbangda,xbd599 + port: true reg: maxItems: 1 description: DSI virtual channel -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/14] Add regulator devfreq support to Panfrost
Hi, On Sat, 4 Jul 2020 at 12:25, Clément Péron wrote: > > Hi, > > This serie cleans and adds regulator support to Panfrost devfreq. > This is mostly based on comment for the freshly introduced lima > devfreq. > > We need to add regulator support because on Allwinner the GPU OPP > table defines both frequencies and voltages. > > First patches [01-07] should not change the actual behavior > and introduce a proper panfrost_devfreq struct. > > Regards, > Clément Changes since v1: - Collect Steven Price reviewed-by tags - Fix spinlock comment - Drop OPP clock-name path - Drop device_property_test patch - Add rename error labels patch > > Clément Péron (14): > drm/panfrost: avoid static declaration > drm/panfrost: clean headers in devfreq > drm/panfrost: don't use pfdevfreq.busy_count to know if hw is idle > drm/panfrost: introduce panfrost_devfreq struct > drm/panfrost: use spinlock instead of atomic > drm/panfrost: properly handle error in probe > drm/panfrost: rename error labels in device_init > drm/panfrost: move devfreq_init()/fini() in device > drm/panfrost: dynamically alloc regulators > drm/panfrost: add regulators to devfreq > arm64: defconfig: Enable devfreq cooling device > arm64: dts: allwinner: h6: Add cooling map for GPU > [DO NOT MERGE] arm64: dts: allwinner: h6: Add GPU OPP table > [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always > > .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 + > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 102 +++ > arch/arm64/configs/defconfig | 1 + > drivers/gpu/drm/panfrost/panfrost_devfreq.c | 165 -- > drivers/gpu/drm/panfrost/panfrost_devfreq.h | 30 +++- > drivers/gpu/drm/panfrost/panfrost_device.c| 61 --- > drivers/gpu/drm/panfrost/panfrost_device.h| 14 +- > drivers/gpu/drm/panfrost/panfrost_drv.c | 15 +- > drivers/gpu/drm/panfrost/panfrost_job.c | 10 +- > 9 files changed, 290 insertions(+), 109 deletions(-) > > -- > 2.25.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/8] soc: mediatek: cmdq: add write_s function
add write_s function in cmdq helper functions which
writes value contains in internal register to address
with large dma access support.
Signed-off-by: Dennis YC Hsieh
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 19 +++
include/linux/mailbox/mtk-cmdq-mailbox.h |1 +
include/linux/soc/mediatek/mtk-cmdq.h| 19 +++
3 files changed, 39 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 9faf78fbed3a..880349b3f16c 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -18,6 +18,10 @@ struct cmdq_instruction {
union {
u32 value;
u32 mask;
+ struct {
+ u16 arg_c;
+ u16 src_reg;
+ };
};
union {
u16 offset;
@@ -223,6 +227,21 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_write_mask);
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx)
+{
+ struct cmdq_instruction inst = {};
+
+ inst.op = CMDQ_CODE_WRITE_S;
+ inst.src_t = CMDQ_REG_TYPE;
+ inst.sop = high_addr_reg_idx;
+ inst.offset = addr_low;
+ inst.src_reg = src_reg_idx;
+
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_write_s);
+
int cmdq_pkt_wfe(struct cmdq_pkt *pkt, u16 event)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h
b/include/linux/mailbox/mtk-cmdq-mailbox.h
index 05eea1aef5aa..1f76cfedb16d 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -60,6 +60,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_WRITE_S = 0x90,
CMDQ_CODE_LOGIC = 0xa0,
};
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h
b/include/linux/soc/mediatek/mtk-cmdq.h
index 2249ecaf77e4..9b0c57a0063d 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -12,6 +12,8 @@
#include
#define CMDQ_NO_TIMEOUT0xu
+#define CMDQ_ADDR_HIGH(addr) ((u32)(((addr) >> 16) & GENMASK(31, 0)))
+#define CMDQ_ADDR_LOW(addr)((u16)(addr) | BIT(1))
struct cmdq_pkt;
@@ -103,6 +105,23 @@ int cmdq_pkt_write_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
/**
+ * cmdq_pkt_write_s() - append write_s command to the CMDQ packet
+ * @pkt: the CMDQ packet
+ * @high_addr_reg_idx: internal register ID which contains high address of pa
+ * @addr_low: low address of pa
+ * @src_reg_idx: the CMDQ internal register ID which cache source value
+ *
+ * Return: 0 for success; else the error code is returned
+ *
+ * Support write value to physical address without subsys. Use CMDQ_ADDR_HIGH()
+ * to get high address and call cmdq_pkt_assign() to assign value into internal
+ * reg. Also use CMDQ_ADDR_LOW() to get low address for addr_low parameter when
+ * call to this function.
+ */
+int cmdq_pkt_write_s(struct cmdq_pkt *pkt, u16 high_addr_reg_idx,
+u16 addr_low, u16 src_reg_idx);
+
+/**
* cmdq_pkt_wfe() - append wait for event command to the CMDQ packet
* @pkt: the CMDQ packet
* @event: the desired event type to "wait and CLEAR"
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/14] drm/panfrost: rename error labels in device_init
Rename goto labels in device_init it will be easier to maintain.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_device.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index 8136babd3ba9..cc16d102b275 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -215,57 +215,57 @@ int panfrost_device_init(struct panfrost_device *pfdev)
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
- goto err_out0;
+ goto out_clk;
}
err = panfrost_reset_init(pfdev);
if (err) {
dev_err(pfdev->dev, "reset init failed %d\n", err);
- goto err_out1;
+ goto out_regulator;
}
err = panfrost_pm_domain_init(pfdev);
if (err)
- goto err_out2;
+ goto out_reset;
res = platform_get_resource(pfdev->pdev, IORESOURCE_MEM, 0);
pfdev->iomem = devm_ioremap_resource(pfdev->dev, res);
if (IS_ERR(pfdev->iomem)) {
dev_err(pfdev->dev, "failed to ioremap iomem\n");
err = PTR_ERR(pfdev->iomem);
- goto err_out3;
+ goto out_pm_domain;
}
err = panfrost_gpu_init(pfdev);
if (err)
- goto err_out3;
+ goto out_pm_domain;
err = panfrost_mmu_init(pfdev);
if (err)
- goto err_out4;
+ goto out_gpu;
err = panfrost_job_init(pfdev);
if (err)
- goto err_out5;
+ goto out_mmu;
err = panfrost_perfcnt_init(pfdev);
if (err)
- goto err_out6;
+ goto out_job;
return 0;
-err_out6:
+out_job:
panfrost_job_fini(pfdev);
-err_out5:
+out_mmu:
panfrost_mmu_fini(pfdev);
-err_out4:
+out_gpu:
panfrost_gpu_fini(pfdev);
-err_out3:
+out_pm_domain:
panfrost_pm_domain_fini(pfdev);
-err_out2:
+out_reset:
panfrost_reset_fini(pfdev);
-err_out1:
+out_regulator:
panfrost_regulator_fini(pfdev);
-err_out0:
+out_clk:
panfrost_clk_fini(pfdev);
return err;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] MAINTAINERS: adjust entry to renaming and conversion
Commit a74e81a56405 ("drm/panel: rocktech-jh057n00900: Rename the driver to
st7703") and commit 7317f4574492 ("dt-bindings: panel: Convert
rocktech,jh057n00900 to yaml") renamed and converted the files mentioned in
DRM DRIVER FOR ROCKTECH JH057N00900 PANELS, but did not adjust the entries
in MAINTAINERS.
Hence, ./scripts/get_maintainer.pl --self-test=patterns complains:
warning: no file matches F: \
Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
warning: no file matches F: \
drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
Adjust entries after this file renaming and devicetree conversion.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on next-20200703
Ondrej, please ack this patch.
Sam, please pick this minor non-urgent patch into your -next tree.
This is the minimal change to address the warning. You might consider
changing the name of the section from ROCKTECH to ST7703, change
maintainers etc.
MAINTAINERS | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9375edaef11f..8a7b92faff99 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5493,8 +5493,8 @@ DRM DRIVER FOR ROCKTECH JH057N00900 PANELS
M: Guido Günther
R: Purism Kernel Team
S: Maintained
-F: Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
-F: drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c
+F:
Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
+F: drivers/gpu/drm/panel/panel-sitronix-st7703.c
DRM DRIVER FOR SAVAGE VIDEO CARDS
S: Orphan / Obsolete
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 01/14] drm/panfrost: avoid static declaration
This declaration can be avoided so change it.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 38 ++---
1 file changed, 18 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 413987038fbf..1b560b903ea6 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -14,7 +14,24 @@
#include "panfrost_gpu.h"
#include "panfrost_regs.h"
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev);
+static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
+{
+ ktime_t now;
+ ktime_t last;
+
+ if (!pfdev->devfreq.devfreq)
+ return;
+
+ now = ktime_get();
+ last = pfdev->devfreq.time_last_update;
+
+ if (atomic_read(>devfreq.busy_count) > 0)
+ pfdev->devfreq.busy_time += ktime_sub(now, last);
+ else
+ pfdev->devfreq.idle_time += ktime_sub(now, last);
+
+ pfdev->devfreq.time_last_update = now;
+}
static int panfrost_devfreq_target(struct device *dev, unsigned long *freq,
u32 flags)
@@ -139,25 +156,6 @@ void panfrost_devfreq_suspend(struct panfrost_device
*pfdev)
devfreq_suspend_device(pfdev->devfreq.devfreq);
}
-static void panfrost_devfreq_update_utilization(struct panfrost_device *pfdev)
-{
- ktime_t now;
- ktime_t last;
-
- if (!pfdev->devfreq.devfreq)
- return;
-
- now = ktime_get();
- last = pfdev->devfreq.time_last_update;
-
- if (atomic_read(>devfreq.busy_count) > 0)
- pfdev->devfreq.busy_time += ktime_sub(now, last);
- else
- pfdev->devfreq.idle_time += ktime_sub(now, last);
-
- pfdev->devfreq.time_last_update = now;
-}
-
void panfrost_devfreq_record_busy(struct panfrost_device *pfdev)
{
panfrost_devfreq_update_utilization(pfdev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 08/14] drm/panfrost: move devfreq_init()/fini() in device
Later we will introduce devfreq probing regulator if they
are present. As regulator should be probe only one time we
need to get this logic in the device_init().
panfrost_device is already taking care of devfreq_resume()
and devfreq_suspend(), so it's not totally illogic to move
the devfreq_init() and devfreq_fini() here.
Signed-off-by: Clément Péron
---
drivers/gpu/drm/panfrost/panfrost_device.c | 12 +++-
drivers/gpu/drm/panfrost/panfrost_drv.c| 15 ++-
2 files changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_device.c
b/drivers/gpu/drm/panfrost/panfrost_device.c
index cc16d102b275..464da1646398 100644
--- a/drivers/gpu/drm/panfrost/panfrost_device.c
+++ b/drivers/gpu/drm/panfrost/panfrost_device.c
@@ -212,10 +212,17 @@ int panfrost_device_init(struct panfrost_device *pfdev)
return err;
}
+ err = panfrost_devfreq_init(pfdev);
+ if (err) {
+ if (err != -EPROBE_DEFER)
+ dev_err(pfdev->dev, "devfreq init failed %d\n", err);
+ goto out_clk;
+ }
+
err = panfrost_regulator_init(pfdev);
if (err) {
dev_err(pfdev->dev, "regulator init failed %d\n", err);
- goto out_clk;
+ goto out_devfreq;
}
err = panfrost_reset_init(pfdev);
@@ -265,6 +272,8 @@ int panfrost_device_init(struct panfrost_device *pfdev)
panfrost_reset_fini(pfdev);
out_regulator:
panfrost_regulator_fini(pfdev);
+out_devfreq:
+ panfrost_devfreq_fini(pfdev);
out_clk:
panfrost_clk_fini(pfdev);
return err;
@@ -278,6 +287,7 @@ void panfrost_device_fini(struct panfrost_device *pfdev)
panfrost_gpu_fini(pfdev);
panfrost_pm_domain_fini(pfdev);
panfrost_reset_fini(pfdev);
+ panfrost_devfreq_fini(pfdev);
panfrost_regulator_fini(pfdev);
panfrost_clk_fini(pfdev);
}
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc33fdb..4dda68689015 100644
--- a/drivers/gpu/drm/panfrost/panfrost_drv.c
+++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
@@ -14,7 +14,6 @@
#include
#include "panfrost_device.h"
-#include "panfrost_devfreq.h"
#include "panfrost_gem.h"
#include "panfrost_mmu.h"
#include "panfrost_job.h"
@@ -606,13 +605,6 @@ static int panfrost_probe(struct platform_device *pdev)
goto err_out0;
}
- err = panfrost_devfreq_init(pfdev);
- if (err) {
- if (err != -EPROBE_DEFER)
- dev_err(>dev, "Fatal error during devfreq
init\n");
- goto err_out1;
- }
-
pm_runtime_set_active(pfdev->dev);
pm_runtime_mark_last_busy(pfdev->dev);
pm_runtime_enable(pfdev->dev);
@@ -625,16 +617,14 @@ static int panfrost_probe(struct platform_device *pdev)
*/
err = drm_dev_register(ddev, 0);
if (err < 0)
- goto err_out2;
+ goto err_out1;
panfrost_gem_shrinker_init(ddev);
return 0;
-err_out2:
- pm_runtime_disable(pfdev->dev);
- panfrost_devfreq_fini(pfdev);
err_out1:
+ pm_runtime_disable(pfdev->dev);
panfrost_device_fini(pfdev);
err_out0:
drm_dev_put(ddev);
@@ -650,7 +640,6 @@ static int panfrost_remove(struct platform_device *pdev)
panfrost_gem_shrinker_cleanup(ddev);
pm_runtime_get_sync(pfdev->dev);
- panfrost_devfreq_fini(pfdev);
panfrost_device_fini(pfdev);
pm_runtime_put_sync_suspend(pfdev->dev);
pm_runtime_disable(pfdev->dev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote: > So maybe I'm just totally confused about the rdma model. I thought: > - you bind a pile of memory for various transactions, that might > happen whenever. Kernel driver doesn't have much if any insight into > when memory isn't needed anymore. I think in the rdma world that's > called registering memory, but not sure. Sure, but once registered the memory is able to be used at any moment with no visibilty from the kernel. Unlike GPU the transactions that trigger memory access do not go through the kernel - so there is no ability to interrupt a command flow and fiddle with mappings. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Subject: [PATCH v1 0/8] support cmdq helper function on mt6779 platform
This patch support more gce helper function on mt6779 platform. depends on patch: support gce on mt6779 platform and depends on following applied patches soc: mediatek: cmdq: add set event function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add assign function Change since v1: - Rename cmdq_mbox_shift() to cmdq_get_shift_pa(). Dennis YC Hsieh (8): soc: mediatek: cmdq: add address shift in jump soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +- drivers/soc/mediatek/mtk-cmdq-helper.c | 113 ++- include/linux/mailbox/mtk-cmdq-mailbox.h | 6 +- include/linux/soc/mediatek/mtk-cmdq.h| 93 ++- 4 files changed, 206 insertions(+), 8 deletions(-) -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: connector: Indent code using tabs.
Replace space-indents with tab-indents.
Issues found with checkpatch.
Signed-off-by: Suraj Upadhyay
---
drivers/gpu/drm/drm_connector.c | 38 -
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 00e40a26a800..441d4075dfa5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1906,11 +1906,11 @@ int drm_connector_set_path_property(struct
drm_connector *connector,
int ret;
ret = drm_property_replace_global_blob(dev,
- >path_blob_ptr,
- strlen(path) + 1,
- path,
- >base,
- dev->mode_config.path_property);
+ >path_blob_ptr,
+ strlen(path) + 1,
+ path,
+ >base,
+ dev->mode_config.path_property);
return ret;
}
EXPORT_SYMBOL(drm_connector_set_path_property);
@@ -1936,11 +1936,11 @@ int drm_connector_set_tile_property(struct
drm_connector *connector)
if (!connector->has_tile) {
ret = drm_property_replace_global_blob(dev,
-
>tile_blob_ptr,
- 0,
- NULL,
- >base,
-
dev->mode_config.tile_property);
+
>tile_blob_ptr,
+ 0,
+ NULL,
+ >base,
+
dev->mode_config.tile_property);
return ret;
}
@@ -1951,11 +1951,11 @@ int drm_connector_set_tile_property(struct
drm_connector *connector)
connector->tile_h_size, connector->tile_v_size);
ret = drm_property_replace_global_blob(dev,
- >tile_blob_ptr,
- strlen(tile) + 1,
- tile,
- >base,
- dev->mode_config.tile_property);
+ >tile_blob_ptr,
+ strlen(tile) + 1,
+ tile,
+ >base,
+ dev->mode_config.tile_property);
return ret;
}
EXPORT_SYMBOL(drm_connector_set_tile_property);
@@ -2024,10 +2024,10 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
ret = drm_property_replace_global_blob(dev,
>edid_blob_ptr,
- size,
- edid,
- >base,
- dev->mode_config.edid_property);
+ size,
+ edid,
+ >base,
+ dev->mode_config.edid_property);
if (ret)
return ret;
return drm_connector_set_tile_property(connector);
--
2.17.1
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/connector: Add of_drm_find_connector
Add a function to look up a connector by
device tree node, like what of_drm_find_bridge/panel
does.
Signed-off-by: Andy Yan
Reported-by: kernel test robot
---
Changes in v2:
- Add function declaration
drivers/gpu/drm/drm_connector.c | 33 +
include/drm/drm_connector.h | 14 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d877ddc6dc57..516376cd1868 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -743,6 +743,39 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter)
}
EXPORT_SYMBOL(drm_connector_list_iter_end);
+#ifdef CONFIG_OF
+/**
+ * of_drm_find_connector - look up a connector using a device tree node
+ * @np: device tree node of the connector
+ *
+ *
+ * Return: A pointer to the connector which match the specified device tree
+ * node or NULL if no panel matching the device tree node can be found, or
+ * -ENODEV: the device is not available (status != "okay" or "ok")
+ */
+struct drm_connector *of_drm_find_connector(struct drm_device *dev, const
struct device_node *np)
+{
+ struct drm_connector *connector;
+ struct drm_connector_list_iter conn_iter;
+
+ if (!of_device_is_available(np))
+ return ERR_PTR(-ENODEV);
+
+ drm_connector_list_iter_begin(dev, _iter);
+ drm_for_each_connector_iter(connector, _iter) {
+ if (connector->of_node == np) {
+ drm_connector_list_iter_end(_iter);
+ return connector;
+ }
+ }
+ drm_connector_list_iter_end(_iter);
+
+ return NULL;
+}
+EXPORT_SYMBOL(of_drm_find_connector);
+#endif
+
+
static const struct drm_prop_enum_list drm_subpixel_enum_list[] = {
{ SubPixelUnknown, "Unknown" },
{ SubPixelHorizontalRGB, "Horizontal RGB" },
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fd543d1db9b2..d249e0498375 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1129,6 +1129,9 @@ struct drm_connector {
/** @attr: sysfs attributes */
struct device_attribute *attr;
+ /** @of_node: device tree node */
+ struct device_node *of_node;
+
/**
* @head:
*
@@ -1647,6 +1650,17 @@ void drm_connector_list_iter_end(struct
drm_connector_list_iter *iter);
bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
+#if defined(CONFIG_OF)
+struct drm_connector *
+of_drm_find_connector(struct drm_device *dev, const struct device_node *np);
+#else
+static inline struct drm_connector *
+of_drm_find_connector(struct drm_device *dev, const struct device_node *np)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
/**
* drm_for_each_connector_iter - connector_list iterator macro
* @connector: drm_connector pointer used as cursor
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Fix warnings in display/bridge/nwl-dsi.yaml DT example
This patchset fixes warnings in the example in display/bridge/nwl-dsi.yaml revealed during port of display/panel/rocktech,jh057n00900.yaml to yaml. Please take a look. thank you and regards, Ondrej Jirman Ondrej Jirman (2): dt-bindings: display: Fix example in nwl-dsi.yaml dt-binding: display: Allow a single port node on rocktech,jh057n00900 .../devicetree/bindings/display/bridge/nwl-dsi.yaml | 9 + .../bindings/display/panel/rocktech,jh057n00900.yaml | 1 + 2 files changed, 6 insertions(+), 4 deletions(-) -- 2.27.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 28/37] memory: tegra: Register as interconnect provider
02.07.2020 15:36, Georgi Djakov пишет: ... + mc->provider.data = data; + mc->provider.xlate = of_icc_xlate_onecell; + mc->provider.aggregate = tegra_mc_icc_aggregate; + + err = icc_provider_add(>provider); + if (err) + goto err_msg; >>> >>> Nit: I am planning to re-organize some of the existing drivers to call >>> icc_provider_add() after the topology is populated. Could you please move >>> this after the nodes are created and linked. >> >> Are you planning to remove the provider's list-head initialization from >> the icc_provider_add() [1] and move it to the individual provider >> drivers, correct? > > Yes, that would be the first step, but i need to post some patches first, > so let's keep it as-is for now. Sorry for the confusion. No problems, I'll keep an eye on the ICC core changes! Please feel free to the CC me on the patches, I may give them a whirl. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 14/14] [DO NOT MERGE] arm64: dts: allwinner: force GPU regulator to be always
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 3f7ceeb1a767..14257f7476b8 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -245,6 +245,7 @@ reg_dcdca: dcdca {
};
reg_dcdcc: dcdcc {
+ regulator-always-on;
regulator-enable-ramp-delay = <32000>;
regulator-min-microvolt = <81>;
regulator-max-microvolt = <108>;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DSI probe/bind ordering in vc4
Hi On Fri, Jul 03, 2020 at 05:47:08PM +0200, Andrzej Hajda wrote: > On 30.06.2020 15:27, Maxime Ripard wrote: > > I've tried to bring-up the DSI controller on the RaspberryPi4, and I've > > just encountered something that could make it troublesome to support. > > > > For context, the RaspberryPi has an official panel that uses a DSI->DPI > > bridge, a DPI panel, a touchscreen and a small micro-controller. That > > microcontroller controls the power management on the screen, so > > communicating with it is very much needed, and it's done through an i2c > > bus. > > > > To reflect that, the entire panel has been described in the Device Tree > > as an I2C device (since that's how you would control it), together with > > an OF-Graph endpoint linking that i2c device to the DSI controller[1]. > > > > That deviates a bit from the generic DSI binding though[2], since it > > requires that the panel should be a subnode of the DSI controller (which > > also makes sense since DCS commands is usually how you would control > > that device). > > > > This is where the trouble begins. Since the two devices are on entirely > > different buses, there's basically no guarantee on the probe order. The > > driver has tried to address this by using the OF-Graph and the component > > framework. Indeed, the DSI driver (component-based) will register a > > MIPI-DSI host in its probe, and call component_add[3]. If component_add > > fails, it will remove the DSI host and return the error code. It makes > > sense. > > > > The panel on the other hand will probe, and look for a DSI host through > > the OF-Graph [4]. If it isn't there, it will return EPROBE_DEFER, hoping > > that it will be available at some point. It also makes complete sense. > > > > Where the issue lies is that component_add has two very different > > behaviours here that will create the bug that we see on the RPi4: > > > >- If there's still components to probe, component_add will simply > > return 0 [5][6] > > > >- And if we're the last component to probe, component_add will then > > run all the bind callbacks and return the result on error of the > > master bind callback[7]. That master bind will usually have > > component_bind_all that will return the result of the bind callback > > of each component. > > > > Now, on the RPi4, the last component to probe is the DSI controller > > since it relies on a power-domain exposed by the firmware driver, so the > > driver core will defer its probe function until the power-domain is > > there [8]. We're thus pretty much guaranteed to fall in the second case > > above and run through all the bind callbacks. The DSI bind callback > > however will try to find and attach its panel, and return EPROBE_DEFER > > if it doesn't find it[9]. That error will then be propagated to the > > return code of component_bind_all, then to the master bind callback, and > > finally will be the return code of component_add. > > > > And since component_add is failing, we remove the DSI host. Since the > > DSI host isn't there, on the next occasion the i2c panel driver will not > > probe either, and we enter a loop that cannot really be broken, since > > one depends on the other. > > > > This was working on the RPi3 because the DSI is not the last driver to > > probe: indeed the v3d is depending on the same power domain[10][11] and > > is further down the list of components to add in the driver [12], so > > we're always in the first component_add case for DSI above, the DSI host > > sticks around, and the i2c driver can probe. > > > > I'm not entirely sure how we can fix that though. I guess the real flaw > > here is the assumption that component_add will not fail if one of the > > bind fails, which isn't true, but we can't really ignore those errors > > either since it might be something else than DSI that returns that > > error. > > > > One way to work around it is to make the mailbox, firmware and power > > domain drivers probe earlier by tweaking the initcalls at which they > > register, but it's not really fixing anything and compiling them as > > module would make it broken again. > > > Forgive me - I have not read whole post, but I hope you have a problem > already solved. > > As I understand you have: > > 1. Componentized DSI-host. > > 2. Some sink laying on DSI bus. > > > General rule I promote: "do not expose functionality, until you have all > dependencies", in this case it would be "do not call component_add until you > know sink(your dependency) is ready". > > > Already tested solution (to be checked in drivers): > > 1. In DSI-host you register dsi bus in probe, but do not call component_add. > > 2. In DSI-host callback informing about DSI device registration you get the > sink and since you have all resources then you call component_add. That's a great idea :) I just tested and it works, so it ended up to much easier to fix than I anticipated :) Thanks! Maxime signature.asc
[XDC 2020] Virtual conference + Call for Proposals extended 2 weeks more
Hi, In the last meeting, X.Org Foundation board has decided that XDC 2020 will be a virtual conference, given the uncertain COVID-19 situation in Europe by September, including the possibility of a second wave, outbreaks and travel restrictions, either in Poland or in other countries. XDC 2020 organization team agrees on this decision and it volunteered to organize our first virtual XDC! We would like to announce as well that the new CFP deadline is Sunday July 19th 2020. Don't forget to submit your talk, demo and workshop proposals! Thanks, Sam signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/14] drm/panfrost: properly handle error in probe
Introduce a boolean to know if opp table has been added.
With this, we can call panfrost_devfreq_fini() in case of error
and release what has been initialised.
Signed-off-by: Clément Péron
Reviewed-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 25 -
drivers/gpu/drm/panfrost/panfrost_devfreq.h | 1 +
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
index 78753cfb59fb..d9007f44b772 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.c
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.c
@@ -101,6 +101,7 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
return 0;
else if (ret)
return ret;
+ pfdevfreq->opp_of_table_added = true;
spin_lock_init(>lock);
@@ -109,8 +110,10 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
cur_freq = clk_get_rate(pfdev->clock);
opp = devfreq_recommended_opp(dev, _freq, 0);
- if (IS_ERR(opp))
- return PTR_ERR(opp);
+ if (IS_ERR(opp)) {
+ ret = PTR_ERR(opp);
+ goto err_fini;
+ }
panfrost_devfreq_profile.initial_freq = cur_freq;
dev_pm_opp_put(opp);
@@ -119,8 +122,8 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
DEVFREQ_GOV_SIMPLE_ONDEMAND, NULL);
if (IS_ERR(devfreq)) {
DRM_DEV_ERROR(dev, "Couldn't initialize GPU devfreq\n");
- dev_pm_opp_of_remove_table(dev);
- return PTR_ERR(devfreq);
+ ret = PTR_ERR(devfreq);
+ goto err_fini;
}
pfdevfreq->devfreq = devfreq;
@@ -131,15 +134,25 @@ int panfrost_devfreq_init(struct panfrost_device *pfdev)
pfdevfreq->cooling = cooling;
return 0;
+
+err_fini:
+ panfrost_devfreq_fini(pfdev);
+ return ret;
}
void panfrost_devfreq_fini(struct panfrost_device *pfdev)
{
struct panfrost_devfreq *pfdevfreq = >pfdevfreq;
- if (pfdevfreq->cooling)
+ if (pfdevfreq->cooling) {
devfreq_cooling_unregister(pfdevfreq->cooling);
- dev_pm_opp_of_remove_table(>pdev->dev);
+ pfdevfreq->cooling = NULL;
+ }
+
+ if (pfdevfreq->opp_of_table_added) {
+ dev_pm_opp_of_remove_table(>pdev->dev);
+ pfdevfreq->opp_of_table_added = false;
+ }
}
void panfrost_devfreq_resume(struct panfrost_device *pfdev)
diff --git a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
index 3392df1020be..210269944687 100644
--- a/drivers/gpu/drm/panfrost/panfrost_devfreq.h
+++ b/drivers/gpu/drm/panfrost/panfrost_devfreq.h
@@ -15,6 +15,7 @@ struct panfrost_device;
struct panfrost_devfreq {
struct devfreq *devfreq;
struct thermal_cooling_device *cooling;
+ bool opp_of_table_added;
ktime_t busy_time;
ktime_t idle_time;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
On Fri, Jul 03, 2020 at 12:44:48PM +0200, megous hlavni wrote:
> Hello Sam,
>
> On Fri, Jul 03, 2020 at 07:11:55AM +0200, Sam Ravnborg wrote:
> > Hi Ondrej.
> >
> > > > My bot found errors running 'make dt_binding_check' on your patch:
> > > >
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of
> > > > the regexes: 'pinctrl-[0-9]+'
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: 'vcc-supply' is a required property
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: 'iovcc-supply' is a required property
> > > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > > panel@0: 'reset-gpios' is a required property
> > >
> > > Paths look bogus
> > >
> > > It should be .../rocktech,jh057n00900.yaml: ...
> >
> > The example in nwl-dsi.yaml contains:
> > compatible = "rocktech,jh057n00900";
> >
> > So the example is checked against your updated binding.
> > And the binding check fails because the example is no longer valid.
>
> Ah, now I understand.
>
> > This needs to be fixed as we do not wat to introduce new errors.
> > Either the example or the binding needs the fix.
>
> I think we can unrequire the supplies, but reset is needed really.
Hmm, that's probably wrong kind of thinking. Panel has the supplies, and
obviously requires them, so the dts must describe them somehow, even if
they are the fixed supplies. So I'll not unrequire them.
> The panel only has one port, so there should be no address/size-cells
> in the example, and port@0 should be just port to match existing binding.
> If it had multiple ports, port@0 would have to be inside ports { } node
> anyway, according to the existing binding. Then add reset-gpios to
> the example...
>
> And that should fix it.
>
> I'll prepare the patch shortly.
>
> regards,
> o.
>
> > Sam
> >
> >
> > >
> > > regards,
> > > o.
> > >
> > > >
> > > > See https://patchwork.ozlabs.org/patch/1320690
> > > >
> > > > If you already ran 'make dt_binding_check' and didn't see the above
> > > > error(s), then make sure dt-schema is up to date:
> > > >
> > > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
> > > > --upgrade
> > > >
> > > > Please check and re-submit.
> > > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/dbi: Fix SPI Type 1 (9-bit) transfer
The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit
data, the 9th (MSB) bit being the data/command bit. In order to do that,
it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if
the byte corresponds to data, clears it otherwise. The 7 MSB are
padding. The array of now 16-bit values is then passed to the SPI core
for transfer.
This function was broken since its introduction, as the length of the
SPI transfer was set to the payload size before its conversion, but the
payload doubled in size due to the 8-bit -> 16-bit conversion.
Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
Cc: # 4.10
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index bb27c82757f1..bf7888ad9ad4 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -923,7 +923,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int
dc,
}
}
- tr.len = chunk;
+ tr.len = chunk * 2;
len -= chunk;
ret = spi_sync(spi, );
--
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Hi, On Tue, Jun 30, 2020 at 04:26:20PM +0800, Jian-Hong Pan wrote: > Maxime Ripard 於 2020年6月29日 週一 下午10:21寫道： > > > > Hi! > > > > On Fri, Jun 05, 2020 at 04:44:51PM +0800, Jian-Hong Pan wrote: > > > Maxime Ripard 於 2020年6月2日 週二 下午7:04寫道： > > > > > > > > Hi, > > > > > > > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote: > > > > > Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > > > > > > > > > > > Hi Daniel, > > > > > > > > > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > > > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard > > > > > > > wrote: > > > > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and > > > > > > > > Jian-Hong) if you > > > > > > > > want. > > > > > > > > > > > > > > That would be great, although given the potentially inconsistent > > > > > > > results we've been seeing so far it would be great if you could > > > > > > > additionally push a git branch somewhere. > > > > > > > That way we can have higher confidence that we are applying > > > > > > > exactly > > > > > > > the same patches to the same base etc. > > > > > > > > > > > > So I sent a new iteration yesterday, and of course forgot to cc > > > > > > you... Sorry for > > > > > > that. > > > > > > > > > > > > I've pushed my current branch here: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms > > > > > > > > > > Thanks to Maxime! > > > > > > > > > > I have tried your repository on branch rpi4-kms. The DRM VC4 is used! > > > > > But got some issues: > > > > > 1. Some weird error message in dmesg. Not sure it is related, or not > > > > > [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get > > > > > HDMI state machine clock > > > > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 > > > > > > > > That's a deferred probing. The first time the HDMI driver is being > > > > probed, the firmware clock driver has not been probed yet. It's making > > > > another attempt later on, which succeeds. > > > > > > > > > 2. The screen flashes suddenly sometimes. > > > > > > I append drm.debug=0x3 to boot command. Whenever, the screen flashes, > > > I notice the logs like this: > > > > > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] > > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 > > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] > > > crtc 64: clock 148500 kHz framedur 1666 linedur 14814 > > > Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling > > > vblank on crtc 3, ret: 0 > > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > > 159 (2) > > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > > 154 (1) > > > Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling > > > vblank on crtc 3 > > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, > > > auth=1, DRM_IOCTL_MODE_CURSOR > > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, > > > auth=1, DRM_IOCTL_MODE_CURSOR2 > > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1) > > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1) > > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] > > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 > > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] > > > crtc 64: clock 148500 kHz framedur 1666 linedur 14814 > > > Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling > > > vblank on crtc 3, ret: 0 > > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > > 159 (2) > > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > > 154 (2) > > > > > > Here is the full log > > > https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56 > > > > > > > > 3. The higher resolutions, like 1920x1080 ... are lost after hot > > > > > re-plug HDMI cable (HDMI0) > > > > > > I should explain this in more detail. Here are the steps to reproduce > > > this issue: > > > 1. Before unplug the HDMI cable from HDMI0 port. > > > $ xrandr > > > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 > > > HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x > > > axis y axis) 521mm x 293mm > > >1920x1080 60.00*+ 50.0059.94 > > >1920x1080i60.0050.0059.94 > > >1680x1050 59.88 > > >1280x1024 75.0260.02 > > >1440x900 59.90 > > >1280x960 60.00 > > >1152x864 75.00 > > >1280x720 60.0050.0059.94 > > >1440x576 50.00 > > >1024x768 75.0370.0760.00 > > >1440x480 60.0059.94 > > >832x624 74.55 > > >800x600 72.1975.0060.3256.25 > > >720x576 50.00 > > >720x480 60.0059.94 > > >640x480
Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
Hello Sam,
On Fri, Jul 03, 2020 at 07:11:55AM +0200, Sam Ravnborg wrote:
> Hi Ondrej.
>
> > > My bot found errors running 'make dt_binding_check' on your patch:
> > >
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of
> > > the regexes: 'pinctrl-[0-9]+'
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: 'vcc-supply' is a required property
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: 'iovcc-supply' is a required property
> > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
> > > panel@0: 'reset-gpios' is a required property
> >
> > Paths look bogus
> >
> > It should be .../rocktech,jh057n00900.yaml: ...
>
> The example in nwl-dsi.yaml contains:
> compatible = "rocktech,jh057n00900";
>
> So the example is checked against your updated binding.
> And the binding check fails because the example is no longer valid.
Ah, now I understand.
> This needs to be fixed as we do not wat to introduce new errors.
> Either the example or the binding needs the fix.
I think we can unrequire the supplies, but reset is needed really.
The panel only has one port, so there should be no address/size-cells
in the example, and port@0 should be just port to match existing binding.
If it had multiple ports, port@0 would have to be inside ports { } node
anyway, according to the existing binding. Then add reset-gpios to
the example...
And that should fix it.
I'll prepare the patch shortly.
regards,
o.
> Sam
>
>
> >
> > regards,
> > o.
> >
> > >
> > > See https://patchwork.ozlabs.org/patch/1320690
> > >
> > > If you already ran 'make dt_binding_check' and didn't see the above
> > > error(s), then make sure dt-schema is up to date:
> > >
> > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master
> > > --upgrade
> > >
> > > Please check and re-submit.
> > >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] Fix a bunch of W=1 warnings in Backlight
On Wed, 24 Jun 2020, Lee Jones wrote: > Attempting to clean-up W=1 kernel builds, which are currently > overwhelmingly riddled with niggly little warnings. > > Lee Jones (8): > backlight: lms501kf03: Remove unused const variables > backlight: lcd: Add missing kerneldoc entry for 'struct device parent' > backlight: ili922x: Add missing kerneldoc descriptions for > CHECK_FREQ_REG() args > backlight: ili922x: Remove invalid use of kerneldoc syntax > backlight: ili922x: Add missing kerneldoc description for > ili922x_reg_dump()'s arg > backlight: backlight: Supply description for function args in existing > Kerneldocs > backlight: lm3630a_bl: Remove invalid checks for unsigned int < 0 > backlight: qcom-wled: Remove unused configs for LED3 and LED4 > > drivers/video/backlight/backlight.c | 2 ++ > drivers/video/backlight/ili922x.c| 8 ++-- > drivers/video/backlight/lcd.c| 1 + > drivers/video/backlight/lm3630a_bl.c | 4 ++-- > drivers/video/backlight/lms501kf03.c | 8 > drivers/video/backlight/qcom-wled.c | 8 > 6 files changed, 11 insertions(+), 20 deletions(-) All applied to Backlight. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/8] backlight: ili922x: Add missing kerneldoc description for ili922x_reg_dump()'s arg
On Thu, 25 Jun 2020, Daniel Thompson wrote: > On Wed, Jun 24, 2020 at 03:57:18PM +0100, Lee Jones wrote: > > Kerneldoc syntax is used, but not complete. Descriptions required. > > > > Prevents warnings like: > > > > drivers/video/backlight/ili922x.c:298: warning: Function parameter or > > member 'spi' not described in 'ili922x_reg_dump' > > > > Cc: > > Cc: Bartlomiej Zolnierkiewicz > > Cc: Software Engineering > > Signed-off-by: Lee Jones > > --- > > drivers/video/backlight/ili922x.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/video/backlight/ili922x.c > > b/drivers/video/backlight/ili922x.c > > index cd41433b87aeb..26193f38234e7 100644 > > --- a/drivers/video/backlight/ili922x.c > > +++ b/drivers/video/backlight/ili922x.c > > @@ -295,6 +295,8 @@ static int ili922x_write(struct spi_device *spi, u8 > > reg, u16 value) > > #ifdef DEBUG > > /** > > * ili922x_reg_dump - dump all registers > > + * > > + * @spi: pointer to the controller side proxy for an SPI slave device > > Similar to previous... and I also noticed that there are several other > existing @spi descriptions in this file and it would be good to make > them consistent. I've fixed this and applied the patch. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/8] backlight: ili922x: Add missing kerneldoc descriptions for CHECK_FREQ_REG() args
On Thu, 25 Jun 2020, Daniel Thompson wrote: > On Wed, Jun 24, 2020 at 03:57:16PM +0100, Lee Jones wrote: > > Kerneldoc syntax is used, but not complete. Descriptions required. > > > > Prevents warnings like: > > > > drivers/video/backlight/ili922x.c:116: warning: Function parameter or > > member 's' not described in 'CHECK_FREQ_REG' > > drivers/video/backlight/ili922x.c:116: warning: Function parameter or > > member 'x' not described in 'CHECK_FREQ_REG' > > > > Cc: > > Cc: Bartlomiej Zolnierkiewicz > > Cc: Software Engineering > > Signed-off-by: Lee Jones > > --- > > drivers/video/backlight/ili922x.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/video/backlight/ili922x.c > > b/drivers/video/backlight/ili922x.c > > index 9c5aa3fbb2842..8cb4b9d3c3bba 100644 > > --- a/drivers/video/backlight/ili922x.c > > +++ b/drivers/video/backlight/ili922x.c > > @@ -107,6 +107,8 @@ > > * lower frequency when the registers are read/written. > > * The macro sets the frequency in the spi_transfer structure if > > * the frequency exceeds the maximum value. > > + * @s: pointer to controller side proxy for an SPI slave device > > What's wrong with "a pointer to an SPI device"? I've fixed this and applied the patch. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
