Re: [PATCH v3 4/6] drm: Add Generic USB Display driver
Hi Alan, Alan Stern wrote: > > The way I read composite_setup() after try_fun_setup: it calls f->setup() > > when available, and that can return < 0 to stall. > > > > I expect that composite_setup() and thus f->setup() run when the > > SETUP packet has arrived, thus before the data packet arrives, and if > > composite_setup() stalls then the device/function should never see the > > data packet. > > > > For an OUT transaction I think the host controller might still send > > the DATA packet, but the device controllers that I know don't make it > > visible to the application in that case. > > ... > > Are you guys interested in comments from other people who know more > about the kernel and how it works with USB? I am, especially when it comes to the gadget code. > The USB protocol forbids a device from sending a STALL response to a > SETUP packet. The only valid response is ACK. Thus, there is no way > to prevent the host from sending its DATA packet for a control-OUT > transfer. Right; a STALL handshake only after a DATA packet, but a udc could silently drop the first DATA packet if instructed to STALL during SETUP processing. I don't know how common that is for the udc:s supported by gadget, but some MCU:s behave like that. > A gadget driver can STALL in response to a control-OUT data packet, > but only before it has seen the packet. How can it do that for OUT, and IN if possible there too? Is it related to f->setup() returning < 0 ? The spec also allows NAK, but the gadget code seems to not (need to?) explicitly support that. Can you comment on this as well? > Once the driver knows what the data packet contains, the gadget API > doesn't provide any way to STALL the status stage. Thanks. I think this particular gadget driver doesn't need to decide late. Ideally the control transfers can even be avoided. Thanks and kind regards //Peter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drm/msm/dpu: add support for clk and bw scaling for display"
From: Rob Clark
This is causing multiple armv7 missing do_div() errors, so lets drop it
for now.
This reverts commit 04d9044f6c577948609c03b4e33b8fbc8b87c4b1.
Cc: Kalyan Thota
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 106 +++---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 5 +-
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h| 4 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 37 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 -
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 82 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 -
8 files changed, 23 insertions(+), 228 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 9697abcbec3f..7c230f719ad3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -29,73 +29,6 @@ enum dpu_perf_mode {
DPU_PERF_MODE_MAX
};
-/**
- * @_dpu_core_perf_calc_bw() - to calculate BW per crtc
- * @kms - pointer to the dpu_kms
- * @crtc - pointer to a crtc
- * Return: returns aggregated BW for all planes in crtc.
- */
-static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
- struct drm_crtc *crtc)
-{
- struct drm_plane *plane;
- struct dpu_plane_state *pstate;
- u64 crtc_plane_bw = 0;
- u32 bw_factor;
-
- drm_atomic_crtc_for_each_plane(plane, crtc) {
- pstate = to_dpu_plane_state(plane->state);
-
- if (!pstate)
- continue;
-
- crtc_plane_bw += pstate->plane_fetch_bw;
- }
-
- bw_factor = kms->catalog->perf.bw_inefficiency_factor;
- if (bw_factor)
- crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
-
- return crtc_plane_bw;
-}
-
-/**
- * _dpu_core_perf_calc_clk() - to calculate clock per crtc
- * @kms - pointer to the dpu_kms
- * @crtc - pointer to a crtc
- * @state - pointer to a crtc state
- * Return: returns max clk for all planes in crtc.
- */
-static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
- struct drm_crtc *crtc, struct drm_crtc_state *state)
-{
- struct drm_plane *plane;
- struct dpu_plane_state *pstate;
- struct drm_display_mode *mode;
- u64 crtc_clk;
- u32 clk_factor;
-
- mode = >adjusted_mode;
-
- crtc_clk = mode->vtotal * mode->hdisplay * drm_mode_vrefresh(mode);
-
- drm_atomic_crtc_for_each_plane(plane, crtc) {
- pstate = to_dpu_plane_state(plane->state);
-
- if (!pstate)
- continue;
-
- crtc_clk = max(pstate->plane_clk, crtc_clk);
- }
-
- clk_factor = kms->catalog->perf.clk_inefficiency_factor;
- if (clk_factor)
- crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
-
- return crtc_clk;
-}
-
-
static struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
{
struct msm_drm_private *priv;
@@ -118,7 +51,12 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
dpu_cstate = to_dpu_crtc_state(state);
memset(perf, 0, sizeof(struct dpu_core_perf_params));
- if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
+ if (!dpu_cstate->bw_control) {
+ perf->bw_ctl = kms->catalog->perf.max_bw_high *
+ 1000ULL;
+ perf->max_per_pipe_ib = perf->bw_ctl;
+ perf->core_clk_rate = kms->perf.max_core_clk_rate;
+ } else if (kms->perf.perf_tune.mode == DPU_PERF_MODE_MINIMUM) {
perf->bw_ctl = 0;
perf->max_per_pipe_ib = 0;
perf->core_clk_rate = 0;
@@ -126,10 +64,6 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
perf->bw_ctl = kms->perf.fix_core_ab_vote;
perf->max_per_pipe_ib = kms->perf.fix_core_ib_vote;
perf->core_clk_rate = kms->perf.fix_core_clk_rate;
- } else {
- perf->bw_ctl = _dpu_core_perf_calc_bw(kms, crtc);
- perf->max_per_pipe_ib = kms->catalog->perf.min_dram_ib;
- perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
}
DPU_DEBUG(
@@ -181,7 +115,11 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
DPU_DEBUG("crtc:%d bw:%llu ctrl:%d\n",
tmp_crtc->base.id, tmp_cstate->new_perf.bw_ctl,
tmp_cstate->bw_control);
-
+ /*
+* For bw check only use the bw if the
+* atomic property has been already set
+*/
+ if (tmp_cstate->bw_control)
bw_sum_of_intfs += tmp_cstate->new_perf.bw_ctl;
}
@@ -193,7 +131,9 @@ int
[Bug 206987] [drm] [amdgpu] Whole system crashes when the driver is in mode_support_and_system_configuration
https://bugzilla.kernel.org/show_bug.cgi?id=206987 yao...@protonmail.com changed: What|Removed |Added CC||yao...@protonmail.com --- Comment #20 from yao...@protonmail.com --- So far so good Alex. Using the RX 5700 XT as well. Previously, running SteamVR could pretty quickly crash my system (even before launching a game), and since I rebuilt linux-mainline from AUR, haven't had SteamVR crash my system yet. Fingers crossed that this continues. Though Half-Life: Alyx is causing a system crash, which can even happen on Windows with Vulkan apparently! Wow. At least that's not an AMD or Linux specific issue. https://github.com/ValveSoftware/SteamVR-for-Linux/issues/356 -- 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: inux-next: build failure after merge of the drm-msm tree
On Tue, 2 Jun 2020 at 08:15, Stephen Rothwell wrote:
>
> Hi Dave,
>
> On Fri, 29 May 2020 14:10:56 +1000 Stephen Rothwell
> wrote:
> >
> > On Tue, 26 May 2020 14:08:41 +1000 Stephen Rothwell
> > wrote:
> > >
> > > On Tue, 19 May 2020 15:09:55 +1000 Stephen Rothwell
> > > wrote:
> > > >
> > > > After merging the drm-msm tree, today's linux-next build (arm
> > > > multi_v7_defconfig) failed like this:
> > > >
> > > > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko]
> > > > undefined!
> > > > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko]
> > > > undefined!
> > > >
> > > > Caused by commit
> > > >
> > > > 04d9044f6c57 ("drm/msm/dpu: add support for clk and bw scaling for
> > > > display")
> > > >
> > > > I applied the following patch for today (this is mechanical, there may
> > > > be a better way):
> > > >
> > > > From: Stephen Rothwell
> > > > Date: Tue, 19 May 2020 14:12:39 +1000
> > > > Subject: [PATCH] drm/msm/dpu: fix up u64/u32 division for 32 bit
> > > > architectures
> > > >
> > > > Signed-off-by: Stephen Rothwell
> > > > ---
> > > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 23 ++-
> > > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15
> > > > 2 files changed, 28 insertions(+), 10 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > > index 9697abcbec3f..85c2a4190840 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > > @@ -10,6 +10,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include "dpu_kms.h"
> > > > #include "dpu_trace.h"
> > > > @@ -53,8 +54,11 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms
> > > > *kms,
> > > > }
> > > >
> > > > bw_factor = kms->catalog->perf.bw_inefficiency_factor;
> > > > - if (bw_factor)
> > > > - crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
> > > > + if (bw_factor) {
> > > > + u64 quot = crtc_plane_bw;
> > > > + u32 rem = do_div(quot, 100);
> > > > + crtc_plane_bw = (quot * bw_factor) + ((rem * bw_factor) /
> > > > 100);
> > > > + }
> > > >
> > > > return crtc_plane_bw;
> > > > }
> > > > @@ -89,8 +93,11 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms
> > > > *kms,
> > > > }
> > > >
> > > > clk_factor = kms->catalog->perf.clk_inefficiency_factor;
> > > > - if (clk_factor)
> > > > - crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
> > > > + if (clk_factor) {
> > > > + u64 quot = crtc_clk;
> > > > + u32 rem = do_div(quot, 100);
> > > > + crtc_clk = (quot * clk_factor) + ((rem * clk_factor) / 100);
> > > > + }
> > > >
> > > > return crtc_clk;
> > > > }
> > > > @@ -234,8 +241,12 @@ static int _dpu_core_perf_crtc_update_bus(struct
> > > > dpu_kms *kms,
> > > > }
> > > > }
> > > >
> > > > - avg_bw = kms->num_paths ?
> > > > - perf.bw_ctl / kms->num_paths : 0;
> > > > + if (kms->num_paths) {
> > > > + avg_bw = perf.bw_ctl;
> > > > + do_div(avg_bw, kms->num_paths);
> > > > + } else {
> > > > + avg_bw = 0;
> > > > + }
> > > >
> > > > for (i = 0; i < kms->num_paths; i++)
> > > > icc_set_bw(kms->path[i],
> > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > index c2a6e3dacd68..ad95f32eac13 100644
> > > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > > @@ -9,6 +9,7 @@
> > > >
> > > > #include
> > > > #include
> > > > +#include
> > > >
> > > > #include
> > > > #include
> > > > @@ -174,7 +175,11 @@ static void _dpu_plane_calc_bw(struct drm_plane
> > > > *plane,
> > > > plane_prefill_bw =
> > > > src_width * hw_latency_lines * fps * fmt->bpp * scale_factor;
> > > >
> > > > - plane_prefill_bw = mult_frac(plane_prefill_bw, mode->vtotal,
> > > > (vbp+vpw));
> > > > + {
> > > > + u64 quot = plane_prefill_bw;
> > > > + u32 rem = do_div(plane_prefill_bw, vbp + vpw);
> > > > + plane_prefill_bw = quot * mode->vtotal + rem * mode->vtotal /
> > > > (vbp + vpw);
> > > > + }
> > > >
> > > > pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
> > > > }
> > > > @@ -204,9 +209,11 @@ static void _dpu_plane_calc_clk(struct drm_plane
> > > > *plane)
> > > > pstate->plane_clk =
> > > > dst_width * mode->vtotal * fps;
> > > >
> > > > - if (src_height > dst_height)
> > > > - pstate->plane_clk = mult_frac(pstate->plane_clk,
> > > > - src_height, dst_height);
> > > > + if (src_height > dst_height) {
> > > > + u64 quot = pstate->plane_clk;
> > > > + u32 rem = do_div(quot, dst_height);
> > > > + pstate->plane_clk = quot * src_height + rem * src_height /
> > > >
Re: [PATCH v3 4/6] drm: Add Generic USB Display driver
On Tue, Jun 02, 2020 at 12:12:07AM +, Peter Stuge wrote: ... > The way I read composite_setup() after try_fun_setup: it calls f->setup() > when available, and that can return < 0 to stall. > > I expect that composite_setup() and thus f->setup() run when the > SETUP packet has arrived, thus before the data packet arrives, and if > composite_setup() stalls then the device/function should never see the > data packet. > > For an OUT transaction I think the host controller might still send > the DATA packet, but the device controllers that I know don't make it > visible to the application in that case. ... Are you guys interested in comments from other people who know more about the kernel and how it works with USB? Your messages have been far too long to go into in any detail, but I will address this one issue. The USB protocol forbids a device from sending a STALL response to a SETUP packet. The only valid response is ACK. Thus, there is no way to prevent the host from sending its DATA packet for a control-OUT transfer. A gadget driver can STALL in response to a control-OUT data packet, but only before it has seen the packet. Once the driver knows what the data packet contains, the gadget API doesn't provide any way to STALL the status stage. There has been a proposal to change the API to make this possible, but so far it hasn't gone forward. Alan Stern ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 4/6] drm: panel-simple: add Hitachi 3.5" QVGA panel
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg wrote:
>
> This panel is used on evaluation boards for Atmel at91sam9261 and
> at91sam6263.
>
> Signed-off-by: Sam Ravnborg
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-simple.c | 29
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 8624bb80108c..25c96639631f 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1813,6 +1813,32 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> +static const struct drm_display_mode hitachi_tx09d71vm1cca_mode = {
> + .clock = 4965000,
This is the pixel clock in kHz, right? So it runs at almost 5 Terahertz?
> + .hdisplay = 240,
> + .hsync_start = 240 + 0,
> + .hsync_end = 240 + 0 + 5,
> + .htotal = 240 + 0 + 5 + 1,
> + .vdisplay = 320,
> + .vsync_start = 320 + 0,
> + .vsync_end = 320 + 0 + 1,
> + .vtotal = 320 + 0 + 1 + 1,
Some random datasheet I found has really different numbers. If the
numbers above are what everyone is using then I suppose it's fine,
just curious why the mismatch.
Also: should you provide "vrefresh"?
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/6] drm: panel-simple: add Seiko 70WVW2T 7" simple panel
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg wrote:
>
> The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
> Tested on a proprietary product.
>
> Signed-off-by: Sam Ravnborg
> Cc: Søren Andersen
> Cc: Thierry Reding
> Cc: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-simple.c | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index b067f66cea0e..8624bb80108c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -3194,6 +3194,31 @@ static const struct panel_desc shelly_sca07010_bfn_lnn
> = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
> };
>
> +static const struct drm_display_mode sii_70wvw2t_mode = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 256,
> + .hsync_end = 800 + 256 + 0,
> + .htotal = 800 + 256 + 0 + 0,
> + .vdisplay = 480,
> + .vsync_start = 480 + 0,
> + .vsync_end = 480 + 0 + 0,
> + .vtotal = 480 + 0 + 0 + 45,
Important to have a "vrefresh"?
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +};
> +
> +static const struct panel_desc sii_70wvw2t = {
> + .modes = _70wvw2t_mode,
> + .num_modes = 1,
Do we want "bpc = 6"?
> + .size = {
> + .width = 152,
> + .height = 91,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
Should this be a 666 format? Random internet-found data sheet says
262K colors...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 6/6] drm: panel-simple: add LOGIC Technologies panels
Hi,
On Mon, Jun 1, 2020 at 1:33 AM Sam Ravnborg wrote:
>
> +static const struct drm_display_mode logictechno_lttd800480070_l6wh_rt_mode
> = {
> + .clock = 33000,
> + .hdisplay = 800,
> + .hsync_start = 800 + 154,
> + .hsync_end = 800 + 154 + 3,
> + .htotal = 800 + 154 + 3 + 43,
> + .vdisplay = 480,
> + .vsync_start = 480 + 47,
> + .vsync_end = 480 + 47 + 3,
> + .vtotal = 480 + 47 + 3 + 20,
> + .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
This is different than the "typ" mode from the random spreadsheet I
found on the internet:
https://logictechno.com/wp-content/uploads/2016/11/LTTD800480070-L6WH-RT-v1.1.pdf
As per my other comments, I wonder how important "vrefresh" is and if
we should include it.
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm: Add Generic USB Display driver
Hi Noralf,
Thanks a lot for going into more detail.
Noralf Trønnes wrote:
> > Several Linux/DRM internals have "leaked" into the USB protocol - this
> > should be avoided if you want device implementations other than your
> > gadget, because those internals can change within Linux in the future,
> > while the protocol must not.
> >
>
> That's intentional, I see no point in recreating uapi values that won't
> change:
>
> Linux errno: /include/uapi/asm-generic/errno{-base,}.h
> Pixel formats: include/uapi/drm/drm_fourcc.h
> Connector types and status: include/uapi/drm/drm_mode.h
I understand, and it's good that these are uapi values, but I will still
disagree with using errno and DRM connector types in the USB protocol,
which is a "namespace" of its own.
That is an important point here; GUD is three things: a Linux DRM driver,
a Linux gadget driver and a USB protocol. USB protocols (good ones) are
OS-agnostic.
> >> If the device transfer buffer can't fit an uncompressed framebuffer
> >> update, the update is split up into parts that do fit.
> >
> > Does "device transfer buffer" refer to something like display RAM on
> > the device side? If so, its size is a device implementation detail
> > which shouldn't be exposed over USB.
>
> The reason for exposing this is that the Linux gadget driver needs to
> decompress the transfer into a buffer and the host needs to know how big
> this is (the host can choose to lower this if it can't allocate a
> continuous buffer of this size).
I understand; so it's only required for some compression types - then
it should at least be completely optional, but in any case I find
exposing/having to expose this to be awful USB protocol design and I
hope we can find a better way.
Maybe it's premature anyway? How would you feel about skipping compression
to begin with?
> lz4 (in the kernel) is block compression and can't be used for
> decompressing just a stream of bytes. There is a lz4 frame protocol
> which looks like it could be useful, but it's not available in the
> kernel. I hardly know anything about compression so I'm in no position
> to add that to the kernel. Maybe someone will add it at a later time if
> it is useful.
Why did you choose to use lz4?
Whether compression comes now or later, maybe there is a more suitable
algorithm?
> > The R1 idea is great!
>
> My plan was to remove R1 support from this version of the patchset, but
> I forgot. The reason is that it's cumbersome to test when the gadget
> driver doesn't support it.
Why not support R1 also in the gadget?
> You mention further down that you have use cases for this, do you have a
> timeplan for when you will make use of R1?
No strict plan, but if it helps I could make a demo device and -firmware
without much effort. You mentioned that you would like to have a
microcontroller device for testing?
> >> - Use donated Openmoko USB pid
> >
> > If Linux will be the reference for this protocol then perhaps a PID
> > under the Linux Foundation VID (1d6b) makes more sense?
>
> Do they hand out pid's?
I don't know. :) The root hub drivers each have one.
> To me it's no big deal, it can be added later if someones cares about it.
Okay, hopefully we can do without a PID anyway.
> > But: A PID applies on device level, not to interfaces.
>
> Indeed. This is a USB interface driver though, so it only looks at
> vendor class interfaces. Then it checks if there's a bulk out endpoint,
> if not it returns -ENXIO and the device subsytem moves on to another
> interface driver if any. Next it tries to fetch the display descriptor
> and if not succesful it returns -ENODEV to give another driver a chance.
Thanks for clarifying this flow. It's nice not to require particular
endpoint addresses - that makes the protocol/driver much more generic.
> I have tried my best to let the driver tolerate other vendor class
> interfaces on the device.
Ack, this is clear now.
> I don't understand why PID should not be necessary, I'm using a vendor
> class interface and the driver can't probe all of those, so it has to
> look at specific vid:pid's.
Why can't the driver probe all vendor class interfaces?
To probe fewer interfaces, a criteria other than PID can still be defined,
and doing so would enable immediate plug-and-play for non-gadget and especially
composite devices, without requiring the addition of PIDs in the host driver.
I find this possibility especially attractive for composite devices, which
may already have some VID:PID and a non-GUD primary function/interface that
is handled by another driver, such that a GUD PID effectively can't be adopted
for that device.
One example of such a criteria would be to require that the iInterface
string descriptor contains the (sub)string "Generic USB Display".
> I have tried together with a HID interface and that worked.
Great. Thanks!
> >> +static int gud_get_vendor_descriptor(struct usb_interface *interface,
> >> + struct
Re: inux-next: build failure after merge of the drm-msm tree
Hi Dave,
On Fri, 29 May 2020 14:10:56 +1000 Stephen Rothwell
wrote:
>
> On Tue, 26 May 2020 14:08:41 +1000 Stephen Rothwell
> wrote:
> >
> > On Tue, 19 May 2020 15:09:55 +1000 Stephen Rothwell
> > wrote:
> > >
> > > After merging the drm-msm tree, today's linux-next build (arm
> > > multi_v7_defconfig) failed like this:
> > >
> > > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> > > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> > >
> > > Caused by commit
> > >
> > > 04d9044f6c57 ("drm/msm/dpu: add support for clk and bw scaling for
> > > display")
> > >
> > > I applied the following patch for today (this is mechanical, there may
> > > be a better way):
> > >
> > > From: Stephen Rothwell
> > > Date: Tue, 19 May 2020 14:12:39 +1000
> > > Subject: [PATCH] drm/msm/dpu: fix up u64/u32 division for 32 bit
> > > architectures
> > >
> > > Signed-off-by: Stephen Rothwell
> > > ---
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 23 ++-
> > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15
> > > 2 files changed, 28 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > index 9697abcbec3f..85c2a4190840 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > > @@ -10,6 +10,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "dpu_kms.h"
> > > #include "dpu_trace.h"
> > > @@ -53,8 +54,11 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
> > > }
> > >
> > > bw_factor = kms->catalog->perf.bw_inefficiency_factor;
> > > - if (bw_factor)
> > > - crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
> > > + if (bw_factor) {
> > > + u64 quot = crtc_plane_bw;
> > > + u32 rem = do_div(quot, 100);
> > > + crtc_plane_bw = (quot * bw_factor) + ((rem * bw_factor) / 100);
> > > + }
> > >
> > > return crtc_plane_bw;
> > > }
> > > @@ -89,8 +93,11 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
> > > }
> > >
> > > clk_factor = kms->catalog->perf.clk_inefficiency_factor;
> > > - if (clk_factor)
> > > - crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
> > > + if (clk_factor) {
> > > + u64 quot = crtc_clk;
> > > + u32 rem = do_div(quot, 100);
> > > + crtc_clk = (quot * clk_factor) + ((rem * clk_factor) / 100);
> > > + }
> > >
> > > return crtc_clk;
> > > }
> > > @@ -234,8 +241,12 @@ static int _dpu_core_perf_crtc_update_bus(struct
> > > dpu_kms *kms,
> > > }
> > > }
> > >
> > > - avg_bw = kms->num_paths ?
> > > - perf.bw_ctl / kms->num_paths : 0;
> > > + if (kms->num_paths) {
> > > + avg_bw = perf.bw_ctl;
> > > + do_div(avg_bw, kms->num_paths);
> > > + } else {
> > > + avg_bw = 0;
> > > + }
> > >
> > > for (i = 0; i < kms->num_paths; i++)
> > > icc_set_bw(kms->path[i],
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > index c2a6e3dacd68..ad95f32eac13 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > > @@ -9,6 +9,7 @@
> > >
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > @@ -174,7 +175,11 @@ static void _dpu_plane_calc_bw(struct drm_plane
> > > *plane,
> > > plane_prefill_bw =
> > > src_width * hw_latency_lines * fps * fmt->bpp * scale_factor;
> > >
> > > - plane_prefill_bw = mult_frac(plane_prefill_bw, mode->vtotal, (vbp+vpw));
> > > + {
> > > + u64 quot = plane_prefill_bw;
> > > + u32 rem = do_div(plane_prefill_bw, vbp + vpw);
> > > + plane_prefill_bw = quot * mode->vtotal + rem * mode->vtotal /
> > > (vbp + vpw);
> > > + }
> > >
> > > pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
> > > }
> > > @@ -204,9 +209,11 @@ static void _dpu_plane_calc_clk(struct drm_plane
> > > *plane)
> > > pstate->plane_clk =
> > > dst_width * mode->vtotal * fps;
> > >
> > > - if (src_height > dst_height)
> > > - pstate->plane_clk = mult_frac(pstate->plane_clk,
> > > - src_height, dst_height);
> > > + if (src_height > dst_height) {
> > > + u64 quot = pstate->plane_clk;
> > > + u32 rem = do_div(quot, dst_height);
> > > + pstate->plane_clk = quot * src_height + rem * src_height /
> > > dst_height;
> > > + }
> > > }
> > >
> > > /**
> > > --
> > > 2.26.2
> >
> > I am still applying the above ...
>
> Still applying.
>
> Any comment even?
I assume that the drm-msm tree is merged via the drm tree, so just
letting you know that as far as I can tell the above build failure has
not yet been addressed.
[Another failure in
Re: [BUG][AMD tahiti xt][amdgpu] broken dpm
On Mon, Jun 1, 2020 at 7:49 AM wrote: > > Hi, > > updated my amd-staging-drm-next branch yesterday: the GPU fans do not reduce > their rpm anymore. I checked the kernel log (attached) and I noticed: > > [drm:0xa036d50d] *ERROR* si_set_sw_state failed > > Is the fix already known or shall I start to bisect? (no rebase on linux > master: > should not be hell) Bisect please. I don't think anyone has touched the SI code in ages. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208011] [amdgpu][Navi10} Kernel crashes during SteamVR
https://bugzilla.kernel.org/show_bug.cgi?id=208011 --- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) --- Probably best to file a mesa issue. The kernel driver is just the bearer of bad news. https://gitlab.freedesktop.org/groups/mesa/-/issues -- 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 208011] [amdgpu][Navi10} Kernel crashes during SteamVR
https://bugzilla.kernel.org/show_bug.cgi?id=208011 --- Comment #2 from farmb...@googlemail.com --- I am on Mesa 20.1.0. -- 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 0/2] video: fbdev: fix error handling, convert to pin_user_pages*()
On 2020-06-01 10:25, Andy Shevchenko wrote:
On Mon, Jun 1, 2020 at 8:10 PM John Hubbard wrote:
On 2020-06-01 03:35, Andy Shevchenko wrote:
On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote:
On 2020-05-31 14:11, Andy Shevchenko wrote:
...
JFYI, we have history.git starting from v0.01.
OK, thanks for that note. According to that history.git [1],
then: drivers/video/pvr2fb.c had get_user_pages_fast() support added to
pvr2fb_write() back in 2004, but only for CONFIG_SH_DMA, as part of
commit 434502754f2 ("[PATCH] SH Merge")
...and that commit created the minor bug that patch 0001 here
addresses. (+Cc Paul just for the sake of completeness.)
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
I mentioned this one, but I guess content should be the same.
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
Actually, that history.git *starts* at Linux 2.6.12-rc2,
It's not true.
OK I see, neither a straight "git log" nor git branches will suffice, you
have to use tags in order to get to the older versions.
while
tglx/history.git *ends* at Linux 2.6.12-rc2 (which is in April, 2005).
And the commit I was looking for is in 2004. So that's why I needed a
different stretch of history.
Actually history/history.git contains all of them starting from v0.01.
But it ends, indeed, on 2.6.33.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/arm: Kconfig annotate drivers as COMPILE_TEST
Hi Emil, On Wed, May 20, 2020 at 12:54:17AM +0100, Emil Velikov wrote: > On Mon, 18 May 2020 at 12:10, Liviu Dudau wrote: > > > > On Sun, May 17, 2020 at 08:36:53PM +0100, Emil Velikov wrote: > > > Add the COMPILE_TEST conditional, so that people can at least build test > > > the drivers. > > > > > > Cc: Liviu Dudau > > > > Acked-by: Liviu Dudau > > > > > Cc: Brian Starkey > > > Cc: Mali DP Maintainers > > > Cc: dri-devel@lists.freedesktop.org > > > Signed-off-by: Emil Velikov > > > --- > > > Please merge through the ARM tree. > > > > We're not using the ARM tree anymore, we push patches through drm-misc. > > > > I'm happy if you want to push the whole series or I can do the 2 patches > > that I've been Cc-ed on. > > > The third patch should be taken care of. So 1/3 + 2/3 need taking care of. > Please do a quick runtime test for 2/3. As you can see I've only compiled it. For 1/3 + 2/3: Tested-by: Liviu Dudau Acked-by: Liviu Dudau Best regards, Liviu > > -Emil > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] video: fbdev: fix error handling, convert to pin_user_pages*()
On Mon, Jun 1, 2020 at 8:10 PM John Hubbard wrote:
>
> On 2020-06-01 03:35, Andy Shevchenko wrote:
> > On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote:
> >> On 2020-05-31 14:11, Andy Shevchenko wrote:
> >>> ...
> >>> JFYI, we have history.git starting from v0.01.
> >>>
> >> OK, thanks for that note. According to that history.git [1],
> >> then: drivers/video/pvr2fb.c had get_user_pages_fast() support added to
> >> pvr2fb_write() back in 2004, but only for CONFIG_SH_DMA, as part of
> >>
> >> commit 434502754f2 ("[PATCH] SH Merge")
> >>
> >> ...and that commit created the minor bug that patch 0001 here
> >> addresses. (+Cc Paul just for the sake of completeness.)
> >>
> >>
> >> [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> >
> > I mentioned this one, but I guess content should be the same.
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
> >
>
> Actually, that history.git *starts* at Linux 2.6.12-rc2,
It's not true.
> while
> tglx/history.git *ends* at Linux 2.6.12-rc2 (which is in April, 2005).
> And the commit I was looking for is in 2004. So that's why I needed a
> different stretch of history.
Actually history/history.git contains all of them starting from v0.01.
But it ends, indeed, on 2.6.33.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic-helper: reset vblank on crtc reset
On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
>
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
>
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
>
> Big thanks to Tetsuo for helping track down what's going wrong here.
>
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
> __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
> motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
>
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
>
> v2: Use the drm_dev_has_vblank() helper.
>
> Link:
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Brian Starkey
> Cc: Sam Ravnborg
> Cc: Boris Brezillon
> Cc: Nicolas Ferre
> Cc: Alexandre Belloni
> Cc: Ludovic Desroches
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Brian Masney
> Cc: Emil Velikov
> Cc: zhengbin
> Cc: Thomas Gleixner
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c | 1 -
For the komeda and malidp drivers:
Acked-by: Liviu Dudau
Best regards,
Liviu
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 7 ++-
> drivers/gpu/drm/drm_atomic_state_helper.c| 4
> drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> drivers/gpu/drm/tegra/dc.c | 1 -
> drivers/gpu/drm/tidss/tidss_crtc.c | 3 +--
> drivers/gpu/drm/tidss/tidss_kms.c| 4
> 8 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> crtc->state = NULL;
>
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
> }
>
> static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> return err;
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>
> crtc->port = kcrtc->master->of_output_port;
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index c2507b7d8512..02904392e370 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -870,7 +870,6 @@ static int malidp_bind(struct device *dev)
> drm->irq_enabled = true;
>
> ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
> - drm_crtc_vblank_reset(>crtc);
> if (ret < 0) {
> DRM_ERROR("failed to initialise vblank\n");
> goto vblank_fail;
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> index 10985134ce0b..ce246b96330b 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
> +++
Re: [PATCH 0/2] video: fbdev: fix error handling, convert to pin_user_pages*()
On 2020-06-01 03:35, Andy Shevchenko wrote:
On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote:
On 2020-05-31 14:11, Andy Shevchenko wrote:
...
JFYI, we have history.git starting from v0.01.
OK, thanks for that note. According to that history.git [1],
then: drivers/video/pvr2fb.c had get_user_pages_fast() support added to
pvr2fb_write() back in 2004, but only for CONFIG_SH_DMA, as part of
commit 434502754f2 ("[PATCH] SH Merge")
...and that commit created the minor bug that patch 0001 here
addresses. (+Cc Paul just for the sake of completeness.)
[1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
I mentioned this one, but I guess content should be the same.
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
Actually, that history.git *starts* at Linux 2.6.12-rc2, while
tglx/history.git *ends* at Linux 2.6.12-rc2 (which is in April, 2005).
And the commit I was looking for is in 2004. So that's why I needed a
different stretch of history.
thanks,
--
John Hubbard
NVIDIA
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/6] drm: Add Generic USB Display driver
Hi Peter,
Den 30.05.2020 00.45, skrev Peter Stuge:
> Hi Noralf,
>
> Noralf Trønnes wrote:
>> This adds a generic USB display driver with the intention that it can be
>> used with future USB interfaced low end displays/adapters.
>
> Fun!
>
>
>> The Linux gadget device driver will serve as the canonical device
>> implementation.
>
> That's a great goal, but as proposed it isn't as generic as I would like.
>
> Several Linux/DRM internals have "leaked" into the USB protocol - this
> should be avoided if you want device implementations other than your
> gadget, because those internals can change within Linux in the future,
> while the protocol must not.
>
That's intentional, I see no point in recreating uapi values that won't
change:
Linux errno: /include/uapi/asm-generic/errno{-base,}.h
Pixel formats: include/uapi/drm/drm_fourcc.h
Connector types and status: include/uapi/drm/drm_mode.h
>
>> If the device transfer buffer can't fit an uncompressed framebuffer
>> update, the update is split up into parts that do fit.
>
> Does "device transfer buffer" refer to something like display RAM on
> the device side? If so, its size is a device implementation detail
> which shouldn't be exposed over USB.
>
The reason for exposing this is that the Linux gadget driver needs to
decompress the transfer into a buffer and the host needs to know how big
this is (the host can choose to lower this if it can't allocate a
continuous buffer of this size).
lz4 (in the kernel) is block compression and can't be used for
decompressing just a stream of bytes. There is a lz4 frame protocol
which looks like it could be useful, but it's not available in the
kernel. I hardly know anything about compression so I'm in no position
to add that to the kernel. Maybe someone will add it at a later time if
it is useful.
> It's true that the host drives USB communication but the device decides
> whether it will accept data or not. If not, it responds with a NAK
> handshake in the OUT transaction, and the host controller will then
> try to resend the data later, until the transfer timeout given by the
> host software expires. Retries are invisible to host software.
>
> The point is: USB has native flow control on the lowest level; that's
> far more efficient than anything the application can construct, and
> flow control in the application protocol would be redundant.
>
> When using gadgetfs IIRC device controllers NAK as long as the
> userspace process doesn't write new data to the ep?out-bulk fd.
> Have you tried/seen this?
>
>
>> The driver supports a one bit monochrome transfer format: R1. This is not
>> implemented in the gadget driver. It is added in preparation for future
>> monochrome e-ink displays.
>
> The R1 idea is great!
>
My plan was to remove R1 support from this version of the patchset, but
I forgot. The reason is that it's cumbersome to test when the gadget
driver doesn't support it. I had some code to test the implementation
when I made it, but it's removed now. It's very easy to add R1 back in
when there's a display that makes use of it giving it a thorough testing.
You mention further down that you have use cases for this, do you have a
timeplan for when you will make use of R1?
>
>> - Use donated Openmoko USB pid
>
> If Linux will be the reference for this protocol then perhaps a PID
> under the Linux Foundation VID (1d6b) makes more sense?
>
Do they hand out pid's? To me it's no big deal, it can be added later if
someones cares about it.
> But: A PID applies on device level, not to interfaces.
>
Indeed. This is a USB interface driver though, so it only looks at
vendor class interfaces. Then it checks if there's a bulk out endpoint,
if not it returns -ENXIO and the device subsytem moves on to another
interface driver if any. Next it tries to fetch the display descriptor
and if not succesful it returns -ENODEV to give another driver a chance.
I have tried my best to let the driver tolerate other vendor class
interfaces on the device.
> Until this protocol becomes a USB-IF device class maybe it's better
> to create a probe for GUD interface(s) rather than binding to PID?
>
Not sure what you mean here, this is an interface driver.
There exists a HID Display page:
Request #: HUTRR29
Title: Repurposing the Alphanumeric Display Page (0x14) as a generic
Auxiliary Display Page and adding bitmap and custom segment
capabilities
https://www.usb.org/sites/default/files/hutrr29b_0.pdf
I couldn't find anything that uses it. It could have been interesting if
there was a bulk endpoint here.
> Does the driver btw. already support a composite device with multiple GUD
> interfaces? Say a microcontroller with two independent panels. It seems no?
>
I haven't tried, but it should work.
> If yes, would any of the control requests currently sent to the interface
> be better directed at the device? If so, then a PID might make sense again,
> but it's still not possible to create a composite device which uses this
[PATCH v3] drm: drm_fourcc: add NV15, Q410, Q401 YUV formats
DRM_FORMAT_NV15 is a 2 plane format suitable for linear and 16x16
block-linear memory layouts (DRM_FORMAT_MOD_SAMSUNG_16_16_TILE). The
format is similar to P010 with 4:2:0 sub-sampling but 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 '15' suffix refers to the optimum effective bits per pixel which is
achieved when the total number of luminance samples is a multiple of 8.
Q410 and Q401 are both 3 plane non-subsampled formats with 16 bits per
component, but only 10 bits are used and 6 are padded. 'Q' is chosen
as the first letter to denote 3 plane YUV444, (and is the next letter
along from P which is usually 2 plane).
V2: Updated block_w of NV15 to {4, 2, 0}
V3: Updated commit message to include specific modifier name
NV15:
Tested-by: Jonas Karlman
Reviewed-by: Brian Starkey
Signed-off-by: Ben Davis
---
drivers/gpu/drm/drm_fourcc.c | 12
include/uapi/drm/drm_fourcc.h | 24
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index b234bfaeda06..722c7ebe4e88 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -274,6 +274,18 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_YUV420_10BIT,.depth = 0,
.num_planes = 1, .cpp = { 0, 0, 0 }, .hsub = 2, .vsub = 2,
.is_yuv = true },
+ { .format = DRM_FORMAT_NV15,.depth = 0,
+ .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_Q410,.depth = 0,
+ .num_planes = 3, .char_per_block = { 2, 2, 2 },
+ .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
+ .vsub = 0, .is_yuv = true },
+ { .format = DRM_FORMAT_Q401,.depth = 0,
+ .num_planes = 3, .char_per_block = { 2, 2, 2 },
+ .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
+ .vsub = 0, .is_yuv = true },
};
unsigned int i;
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 9e488d10f8b4..bed51236aed9 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -236,6 +236,12 @@ extern "C" {
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
+/*
+ * 2 plane YCbCr
+ * index 0 = Y plane, [39:0] Y3:Y2:Y1:Y0 little endian
+ * 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 */
/*
* 2 plane YCbCr MSB aligned
@@ -265,6 +271,24 @@ extern "C" {
*/
#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 2x2
subsampled Cr:Cb plane 16 bits per channel */
+
+/* 3 plane non-subsampled (444) YCbCr
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
+ * index 1: Cb plane, [15:0] Cb:x [10:6] little endian
+ * index 2: Cr plane, [15:0] Cr:x [10:6] little endian
+ */
+#define DRM_FORMAT_Q410fourcc_code('Q', '4', '1', '0')
+
+/* 3 plane non-subsampled (444) YCrCb
+ * 16 bits per component, but only 10 bits are used and 6 bits are padded
+ * index 0: Y plane, [15:0] Y:x [10:6] little endian
+ * index 1: Cr plane, [15:0] Cr:x [10:6] little endian
+ * index 2: Cb plane, [15:0] Cb:x [10:6] little endian
+ */
+#define DRM_FORMAT_Q401fourcc_code('Q', '4', '0', '1')
+
+
/*
* 3 plane YCbCr
* index 0: Y plane, [7:0] Y
--
2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/13] backlight: add backlight_is_blank()
On 01/06/2020 9.51, Sam Ravnborg wrote:
> The backlight support has two properties that express the state:
> - power
> - state
>
> 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.
Reviewed-by: Peter Ujfalusi
>
> 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
> 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 c7d6b2e8c3b5..a0a083b35c47 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(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);
>
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
pEpkey.asc
Description: application/pgp-keys
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/13] backlight: use backlight_is_blank() in all backlight drivers
On 01/06/2020 9.52, Sam Ravnborg wrote:
> Replaces the open-coded checks of the state etc.,
> with the backlight_is_blank() helper.
> This increases readability of the code and align
> the functionality across the drivers.
Reviewed-by: Peter Ujfalusi
> v3:
> - Dropped as3711_bl, it will be modified in another patch
>
> v2:
> - Fixed so changelog is readable
>
> Signed-off-by: Sam Ravnborg
> Reviewed-by: Daniel Thompson
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Michael Hennerich
> Cc: Support Opensource
> Cc: Thierry Reding
> Cc: "Uwe Kleine-König"
> Cc: Andy Gross
> Cc: Bjorn Andersson
> Cc: linux-...@vger.kernel.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: patc...@opensource.cirrus.com
> ---
> drivers/video/backlight/88pm860x_bl.c| 8 +---
> drivers/video/backlight/adp5520_bl.c | 5 +
> drivers/video/backlight/adp8860_bl.c | 5 +
> drivers/video/backlight/adp8870_bl.c | 5 +
> drivers/video/backlight/bd6107.c | 4 +---
> drivers/video/backlight/corgi_lcd.c | 5 +
> drivers/video/backlight/cr_bllcd.c | 22 +++---
> drivers/video/backlight/da903x_bl.c | 8 +---
> drivers/video/backlight/ep93xx_bl.c | 3 +--
> drivers/video/backlight/gpio_backlight.c | 4 +---
> drivers/video/backlight/hp680_bl.c | 4 +---
> drivers/video/backlight/jornada720_bl.c | 2 +-
> drivers/video/backlight/kb3886_bl.c | 4 +---
> drivers/video/backlight/led_bl.c | 4 +---
> drivers/video/backlight/lm3533_bl.c | 4 +---
> drivers/video/backlight/locomolcd.c | 4 +---
> drivers/video/backlight/lv5207lp.c | 4 +---
> drivers/video/backlight/max8925_bl.c | 8 +---
> drivers/video/backlight/pwm_bl.c | 4 +---
> drivers/video/backlight/qcom-wled.c | 4 +---
> drivers/video/backlight/tps65217_bl.c| 4 +---
> drivers/video/backlight/wm831x_bl.c | 8 +---
> 22 files changed, 28 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/video/backlight/88pm860x_bl.c
> b/drivers/video/backlight/88pm860x_bl.c
> index 20d96a5ac384..162c83ab0f5a 100644
> --- a/drivers/video/backlight/88pm860x_bl.c
> +++ b/drivers/video/backlight/88pm860x_bl.c
> @@ -123,13 +123,7 @@ 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)
> + if (backlight_is_blank(bl))
> brightness = 0;
>
> return pm860x_backlight_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp5520_bl.c
> b/drivers/video/backlight/adp5520_bl.c
> index 0f63f76723a5..d817b0d95c9d 100644
> --- a/drivers/video/backlight/adp5520_bl.c
> +++ b/drivers/video/backlight/adp5520_bl.c
> @@ -67,10 +67,7 @@ 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)
> + if (backlight_is_blank(bl))
> brightness = 0;
>
> return adp5520_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp8860_bl.c
> b/drivers/video/backlight/adp8860_bl.c
> index 19968104fc47..a0ce2a3701fa 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -363,10 +363,7 @@ 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)
> + if (backlight_is_blank(bl))
> brightness = 0;
>
> return adp8860_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/adp8870_bl.c
> b/drivers/video/backlight/adp8870_bl.c
> index 4c0032010cfe..ae4269fdb189 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -401,10 +401,7 @@ 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)
> + if (backlight_is_blank(bl))
> brightness = 0;
>
> return adp8870_bl_set(bl, brightness);
> diff --git a/drivers/video/backlight/bd6107.c
> b/drivers/video/backlight/bd6107.c
> index d5d5fb457e78..f6a5c1dba3bc 100644
> --- a/drivers/video/backlight/bd6107.c
> +++ b/drivers/video/backlight/bd6107.c
> @@ -84,9 +84,7 @@ static int bd6107_backlight_update_status(struct
> backlight_device *backlight)
> struct bd6107 *bd =
Re: Current drm-tip doesn’t build with gcc10 - error in amdgpu_amdkfd_gpuvm.c
On Sun, May 31, 2020 at 9:46 AM Yurii Kolesnykov wrote: > > Originally reported by jghodd[1] in linux-drm-tip-git AUR package [2], also > reported on drm/amd on Freedesktop GitLab [3]. > > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c: In function > ‘amdgpu_amdkfd_gpuvm_free_memory_of_gpu’: > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1357:2: error: implicit > declaration of function ‘drm_gem_object_put_unlocked’; did you mean > ‘drm_gem_object_put_locked’? [-Werror=implicit-function-declaration] 1357 | > drm_gem_object_put_unlocked(>bo->tbo.base); | > ^~~ | drm_gem_object_put_locked cc1: some warnings > being treated as errors make[4]: *** [scripts/Makefile.build:267: > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.o] Error 1 make[3]: *** > [scripts/Makefile.build:488: drivers/gpu/drm/amd/amdgpu] Error 2 make[2]: *** > [scripts/Makefile.build:488: drivers/gpu/drm] Error 2 make[1]: *** > [scripts/Makefile.build:488: drivers/gpu] Error 2 make: *** [Makefile:1729: > drivers] Error 2 ==> ERROR: A failure occurred in build(). Aborting… > It's an API change in drm-misc. When my tree gets combined with drm-misc, there is a conflict. It will get resolved once the trees are in sync again. Alex > [1] https://aur.archlinux.org/account/jghodd > [2] https://aur.archlinux.org/pkgbase/linux-drm-tip-git > [3] https://gitlab.freedesktop.org/drm/amd/-/issues/1156 > > > ___ > 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] drm: document how user-space should use link-status
Describe what a "BAD" link-status means for user-space and how it should
handle it. The logic described has been implemented in igt [1].
[1]:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0920521946a575bd55f00fbe
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Manasi Navare
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_connector.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f2b20fd66319..08ba84f9787a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -994,6 +994,12 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
* after modeset, the kernel driver may set this to "BAD" and issue a
* hotplug uevent. Drivers should update this value using
* drm_connector_set_link_status_property().
+ *
+ * When user-space receives the hotplug uevent and detects a "BAD"
+ * link-status, the connector is no longer enabled. The list of available
+ * modes may have changed. User-space is expected to pick a new mode if
+ * the current one has disappeared and perform a new modeset with
+ * link-status set to "GOOD" to re-enable the connector.
* non_desktop:
* Indicates the output should be ignored for purposes of displaying a
* standard desktop environment or console. This is most likely because
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208011] [amdgpu][Navi10} Kernel crashes during SteamVR
https://bugzilla.kernel.org/show_bug.cgi?id=208011 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- This is a GPU hang. Probably caused by a bug in the user mode drivers. I'd suggest getting a newer version of mesa. -- 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 v3] drm/doc: device hot-unplug for userspace
From: Pekka Paalanen Set up the expectations on how hot-unplugging a DRM device should look like to userspace. Written by Daniel Vetter's request and largely based on his comments in IRC and from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . A related Wayland protocol change proposal is at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35 Signed-off-by: Pekka Paalanen Cc: Daniel Vetter Cc: Andrey Grodzovsky Cc: Dave Airlie Cc: Sean Paul Cc: Simon Ser --- v3: - update ENODEV doc (Daniel) - clarify existing vs. new mmaps (Andrey) - split into KMS and render/cross sections (Andrey, Daniel) - open() returns ENXIO (open(2) man page) - ioctls may return ENODEV (Andrey, Daniel) - new wayland-protocols MR v2: - mmap reads/writes undefined (Daniel) - make render ioctl behaviour driver-specific (Daniel) - restructure the mmap paragraphs (Daniel) - chardev minor notes (Simon) - open behaviour (Daniel) - DRM leasing behaviour (Daniel) - added links Disclaimer: I am a userspace developer writing for other userspace developers. I took some liberties in defining what should happen without knowing what is actually possible or what existing drivers already implement. --- Documentation/gpu/drm-uapi.rst | 114 - 1 file changed, 113 insertions(+), 1 deletion(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 56fec6ed1ad8..db56c681b648 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -1,3 +1,5 @@ +.. Copyright 2020 DisplayLink (UK) Ltd. + === Userland interfaces === @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. +Device Hot-Unplug += + +.. note:: + The following is the plan. Implementation is not there yet + (2020 May). + +Graphics devices (display and/or render) may be connected via USB (e.g. +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end +user is able to hot-unplug this kind of devices while they are being +used, and expects that the very least the machine does not crash. Any +damage from hot-unplugging a DRM device needs to be limited as much as +possible and userspace must be given the chance to handle it if it wants +to. Ideally, unplugging a DRM device still lets a desktop to continue +running, but that is going to need explicit support throughout the whole +graphics stack: from kernel and userspace drivers, through display +servers, via window system protocols, and in applications and libraries. + +Other scenarios that should lead to the same are: unrecoverable GPU +crash, PCI device disappearing off the bus, or forced unbind of a driver +from the physical device. + +In other words, from userspace perspective everything needs to keep on +working more or less, until userspace stops using the disappeared DRM +device and closes it completely. Userspace will learn of the device +disappearance from the device removed uevent, ioctls returning ENODEV +(or driver-specific ioctls returning driver-specific things), or open() +returning ENXIO. + +Only after userspace has closed all relevant DRM device and dmabuf file +descriptors and removed all mmaps, the DRM driver can tear down its +instance for the device that no longer exists. If the same physical +device somehow comes back in the mean time, it shall be a new DRM +device. + +Similar to PIDs, chardev minor numbers are not recycled immediately. A +new DRM device always picks the next free minor number compared to the +previous one allocated, and wraps around when minor numbers are +exhausted. + +The goal raises at least the following requirements for the kernel and +drivers. + +Requirements for KMS UAPI +- + +- KMS connectors must change their status to disconnected. + +- Legacy modesets and pageflips, and atomic commits, both real and + TEST_ONLY, and any other ioctls either fail with ENODEV or fake + success. + +- Pending non-blocking KMS operations deliver the DRM events userspace + is expecting. This applies also to ioctls that faked success. + +- open() on a device node whose underlying device has disappeared will + fail with ENXIO. + +- Attempting to create a DRM lease on a disappeared DRM device will + fail with ENODEV. Existing DRM leases remain and work as listed + above. + +Requirements for Render and Cross-Device UAPI +- + +- All GPU jobs that can no longer run must have their fences + force-signalled to avoid inflicting hangs to userspace. + The associated error code is ENODEV. + +- Some userspace APIs already define what should happen when the device + disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_: + VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this + behaviour
[Bug 208011] New: [amdgpu][Navi10} Kernel crashes during SteamVR
https://bugzilla.kernel.org/show_bug.cgi?id=208011 Bug ID: 208011 Summary: [amdgpu][Navi10} Kernel crashes during SteamVR Product: Drivers Version: 2.5 Kernel Version: 5.5.18 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: farmb...@googlemail.com Regression: No Jun 1 15:56:12 kernel: [ 6949.846779] [drm:amdgpu_job_timedout] *ERROR* ring gfx_0.0.0 timeout, signaled seq=8683543, emitted seq=8683545 Jun 1 15:56:12 kernel: [ 6949.846782] [drm:amdgpu_job_timedout] *ERROR* Process information: process FloorPlan.exe pid 9036 thread FloorPlan.:cs0 pid 9044 Jun 1 15:56:12 kernel: [ 6949.846784] [drm] GPU recovery disabled. May 31 14:16:33 kernel: [ 356.823125] [drm:amdgpu_job_timedout] *ERROR* ring gfx_0.0.0 timeout, signaled seq=109500, emitted seq=109503 May 31 14:16:33 kernel: [ 356.823128] [drm:amdgpu_job_timedout] *ERROR* Process information: process hlvr pid 6547 thread hlvr:cs0 pid 6560 May 31 14:16:33 kernel: [ 356.823129] [drm] GPU recovery disabled. May 31 14:17:47 kernel: [ 425.944116] [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! May 31 14:18:28 kernel: [ 431.063123] [drm:amdgpu_dm_atomic_commit_tail] *ERROR* Waiting for fences timed out! -- 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] drm/fourcc: document modifier uniqueness requirements
On Fri, May 29, 2020 at 11:03 AM Daniel Stone wrote: > > On Fri, 29 May 2020 at 15:36, Alex Deucher wrote: > > On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote: > > > On Fri, 29 May 2020 at 15:29, Alex Deucher wrote: > > > > Maybe I'm over thinking this. I just don't want to get into a > > > > situation where we go through a lot of effort to add modifier support > > > > and then performance ends up being worse than it is today in a lot of > > > > cases. > > > > > > I'm genuinely curious: what do you imagine could cause a worse result? > > > > As an example, in some cases, it's actually better to use linear for > > system memory because it better aligns with pcie access patterns than > > some tiling formats (which are better aligned for the memory > > controller topology on the dGPU). That said, I haven't been in the > > loop as much with the tiling formats on newer GPUs, so that may not be > > as much of an issue anymore. > > Yeah, that makes a lot of sense. On the other hand, placement isn't > explicitly encoded for either modifiers or non-modifiers, so I'm not > sure how it would really regress. > > In case it was missed somewhere, there is no generic code doing > modifier selection for modifier optimality anywhere. The flow is: > - every producer/consumer advertises a list of modifier + format > pairs, declaring what they _can_ support > - for every use where a buffer needs to be allocated, the generic > code intersects these lists of modifiers to determine the set of > modifiers mutually acceptable to all consumers > - the buffer allocator is always handed a _list_ of modifiers, and > makes its own decision based on ?? > > For a concrete end-to-end example: > - KMS declares which modifiers are supported for scanout > - EGL declares which modifiers are supported for EGLImage import > - Weston determines that one of its clients could be directly > scanned out rather than composited > - Weston intersects the KMS + EGL set of modifiers to come up with > the optimal modifier set (i.e. bypassing composition) > - Weston sends this intersected list to the client via the Wayland > protocol (mentioned in previous MR) > - the client is using EGL, so Mesa receives this list of modifiers, > and passes this on to amdgpu > - amdgpu uses magic inscrutable heuristics to determine the most > optimal modifier to use, and allocates a buffer based on that > > Weston (or GNOME Shell, or Chromium, or whatever) will never be in a > position as a generic client to know that on Raven2 it should use a > particular supertiled layout with no DCC if width > 2048. So we > designed the entire framework to explicitly avoid generic code trying > to reason about the performance properties of specific modifiers. > > What Weston _does_ know, however, is that display controller can work > with modifier set A, and the GPU can work with modifier set B, and if > the client can pick something from modifier set A, then there is a > much greater probability that Weston can leave the GPU alone so it can > be entirely used by the client. It also knows that if the surface > can't be directly scanned out for whatever reason, then there's no > point in the client optimising for direct scanout, and it can tell the > client to select based on optimality purely for the GPU. Just so I understand this correctly, the main reason for this is to deal with display hardware and render hardware from different vendors which may or may not support any common formats other than linear. It provides a way to tunnel device capabilities between the different drivers. In the case of a device with display and rendering on the same device or multiple devices from the same vendor, it not really that useful. It doesn't seem to provide much over the current EGL hints (SCANOUT, SECURE, etc.). I still don't understand how it solves the DCC problem though. Compression and encryption seem kind like meta modifiers. There is an under laying high level layout, linear, tiled, etc. but it could also be compressed and/or encrypted. Is the idea that those are separate modifiers? E.g., 0: linear 1: linear | encrypted 2. linear | compressed 3: linear | encrypted | compressed 4: tiled1 5: tiled1 | encrypted 6: tiled1 | compressed 7: tiled1 | encrypted | compressed etc. Or that the modifiers only expose the high level layout, and it's then up the the driver(s) to enable compression, etc. if both sides have a compatible layout? Thanks, Alex > > So that's the thinking behind the interface: that the driver still has > exactly as much control and ability to use magic heuristics as it > always has, but that system components can supplement the driver's > heuristics with their own knowledge, to increase the chance that the > driver's heuristics arrive at a configuration that a) will definitely > work, and b) have a much greater chance of working optimally. > > Does that help at all? > > Cheers, > Daniel ___
[PATCH] drm/i915/panel: Reduce race window between bl_update_status and bl_enable
From: Sean Paul
If the backlight is updated while the panel is being enabled, the value
from userspace (which is stored in panel->backlight.device->props.brightness)
can be replaced by the hardware's minimum level. There's really no good
way to tell if this is happening in enable_backlight() since
props.brightness can be initialized to the same value as is being set by
userspace. So we'll try to reduce the race window as much as possible.
Signed-off-by: Sean Paul
---
I don't think there's any way to eliminate this race since grabbing
bd->op_lock in panel_enable would cause a lock inversion deadlock with
the connection_mutex lock in backlight_device_update_status
Suggestions very much welcome!
drivers/gpu/drm/i915/display/intel_panel.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 3c5056dbf607..abdfb9cc281b 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -1285,8 +1285,22 @@ static int intel_backlight_device_update_status(struct
backlight_device *bd)
struct intel_connector *connector = bl_get_data(bd);
struct intel_panel *panel = >panel;
struct drm_device *dev = connector->base.dev;
+ int value;
+
+ /*
+* Before we attempt to grab the connection mutex, cache the incoming
+* brightness value. If we're in the middle of a modeset,
+* intel_panel_enable_backlight will be called and could pave over
+* props.brightness. This is still racey, but the race window should be
+* significantly smaller and reflects the inherent raceyness of the
+* updating props.brightness outside of bd->op_lock.
+*/
+ value = bd->props.brightness;
drm_modeset_lock(>mode_config.connection_mutex, NULL);
+
+ bd->props.brightness = value;
+
DRM_DEBUG_KMS("updating intel_backlight, brightness=%d/%d\n",
bd->props.brightness, bd->props.max_brightness);
intel_panel_set_backlight(connector->base.state, bd->props.brightness,
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements
On 29/05/2020 15:56, Daniel Stone wrote: > Hi Alex, > > On Fri, 29 May 2020 at 14:29, Alex Deucher wrote: >> On Fri, May 29, 2020 at 4:59 AM Simon Ser wrote: >>> OK. In this case I think it's fine to make the DMA-BUF import fail, as >>> we've suggested on IRC. The more-or-less planned fix for these buffer >>> sharing issues is to revive the buffer constraints proposal from the >>> allocator project. It's a lot of work though. >> >> I get that, but why explicitly limit modifiers then? Shouldn't we try >> and do the best we can with what we have now? If not the situation is >> not much better than what we have now. Why go through the effort or >> adding modifer support in the first place if they are mostly useless? > > Well sure, we could add pitch alignment in there. And height > alignment. And starting byte offset. And acceptable byte distance > between planes. And physical contiguity / number of backing pages. And > placement (system vs. GTT vs. local), which also implies adding a > device-unique identifier whilst we're at it. And acceptable > width/height bounds. All of those are perfectly valid constraints > which could cause imports to fail, and not even an exhaustive list. > > How does Navi ensure that every single linear dmabuf source it can > ever receive is aligned to 256 bytes today? How does adding support > for modifiers - something which does solve other problems, like 'every > three months I wearily review a patch forcing all winsys buffers to be > allocated for scanout usage for a new random reason, regressing > performance for a lot of other vendors' - make Navi's situation worse? > >> I don't quite get what we are trying to do with them. What does this >> mean "Modifiers must uniquely encode buffer layout"? We have a number >> of buffer layouts that are the same from a functional standpoint, but >> they have different alignment requirements depending on the chip and >> the number of memory channels, etc. Would those be considered the >> same modifer? If not, then we are sort of implicitly encoding >> alignment requirements into the modifier. > > Yes, of course some requirements are implicit. Given that tiles are > indivisible, it makes no sense to have a 64x64 tiled buffer with a > 32-pixel stride. But that isn't the same thing as encoding an > arbitrary constraint, it's just a requirement of the encoding. > > The reason why modifiers have been successful and adopted by every > other vendor apart from IMG, is exactly because they _don't_ attempt > to boil the ocean, but are the most practical realisation of improving > performance within a complex ecosystem. The allocator is the complete > and exhaustive solution to all our problems, but it's not exactly > going to be done tomorrow. > > Playing a single video today could easily involve a V4L2 codec source > into a V4L2 postprocessor into Chromium's Wayland host compositor > through Chromium itself into the host Wayland compositor and finally > into EGL and/or Vulkan and/or KMS. If you want to figure out what the > V4L2/DRM/KMS, GStreamer/VA-API/Kodi, EGL/Vulkan, and Wayland/X11 APIs > look for negotiating a totally optimal layout across at least three > different hardware classes from at least three different vendors, then > I'm all for it. I'll be cheering you on from the sidelines and doing > what I can to help. But the only reason we've got to this point today > is because Allwinner, AmLogic, Arm, Broadcom, Intel, NVIDIA, NXP, > Qualcomm, Rockchip, Samsung, and VeriSilicon, have all spent the last > few years trying to avoid perfection being the enemy of good. (And > those are just the hardware vendors - obviously Collabora and others > like us have also put not-inconsiderable effort into getting at least > this far.) I have an hard time understanding how this affects the Amlogic Framebuffer Compression patchset I sent at [1]. [1] http://lore.kernel.org/r/20200529151935.13418-2-narmstr...@baylibre.com Neil > > Cheers, > Daniel > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: pxafb: Fix the function used to balance a 'dma_alloc_coherent()' call
On 4/29/20 10:45 AM, Christophe JAILLET wrote:
> 'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()'
> not 'dma_free_wc()'.
> The correct dma_free_ function is already used in the error handling path
> of the probe function.
>
> Fixes: 77e196752bdd ("[ARM] pxafb: allow video memory size to be
> configurable")
> Signed-off-by: Christophe JAILLET
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/pxafb.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index 00b96a78676e..6f972bed410a 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2417,8 +2417,8 @@ static int pxafb_remove(struct platform_device *dev)
>
> free_pages_exact(fbi->video_mem, fbi->video_mem_size);
>
> - dma_free_wc(>dev, fbi->dma_buff_size, fbi->dma_buff,
> - fbi->dma_buff_phys);
> + dma_free_coherent(>dev, fbi->dma_buff_size, fbi->dma_buff,
> + fbi->dma_buff_phys);
>
> return 0;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: pxafb: Use correct return value for pxafb_probe()
On 5/25/20 9:11 AM, Tiezhu Yang wrote:
> When call function devm_platform_ioremap_resource(), we should use IS_ERR()
> to check the return value and return PTR_ERR() if failed.
>
> Signed-off-by: Tiezhu Yang
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/pxafb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index 00b96a7..423331c 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -2305,7 +2305,7 @@ static int pxafb_probe(struct platform_device *dev)
> fbi->mmio_base = devm_platform_ioremap_resource(dev, 0);
> if (IS_ERR(fbi->mmio_base)) {
> dev_err(>dev, "failed to get I/O memory\n");
> - ret = -EBUSY;
> + ret = PTR_ERR(fbi->mmio_base);
> goto failed;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/video: cleanup coding style in video a bit
On 4/27/20 10:05 AM, Bernard Zhao wrote:
> Eliminate the magic numbers, add vender infoframe size macro
> like other hdmi modules.
>
> Signed-off-by: Bernard Zhao
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/hdmi.c | 2 +-
> include/linux/hdmi.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 856a8c4e84a2..f693076f2e5f 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -495,7 +495,7 @@ int hdmi_vendor_infoframe_init(struct
> hdmi_vendor_infoframe *frame)
>* value
>*/
> frame->s3d_struct = HDMI_3D_STRUCTURE_INVALID;
> - frame->length = 4;
> + frame->length = HDMI_VENDOR_INFOFRAME_SIZE;
>
> return 0;
> }
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index 9613d796cfb1..ff25aeb95ee4 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -57,6 +57,7 @@ enum hdmi_infoframe_type {
> #define HDMI_SPD_INFOFRAME_SIZE25
> #define HDMI_AUDIO_INFOFRAME_SIZE 10
> #define HDMI_DRM_INFOFRAME_SIZE26
> +#define HDMI_VENDOR_INFOFRAME_SIZE 4
>
> #define HDMI_INFOFRAME_SIZE(type)\
> (HDMI_INFOFRAME_HEADER_SIZE + HDMI_ ## type ## _INFOFRAME_SIZE)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] console: newport_con: fix an issue about leak related system resources
On 4/23/20 6:42 PM, Dejin Zheng wrote:
> A call of the function do_take_over_console() can fail here.
> The corresponding system resources were not released then.
> Thus add a call of iounmap() and release_mem_region()
> together with the check of a failure predicate. and also
> add release_mem_region() on device removal.
>
> Fixes: e86bb8acc0fdc ("[PATCH] VT binding: Make newport_con support binding")
> Cc: Andy Shevchenko
> Suggested-by: Bartlomiej Zolnierkiewicz
> Signed-off-by: Dejin Zheng
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> v2 -> v3:
> - modify commit tag CC to Cc by Andy's suggestion.
> - modify Subject 'console: console:' to 'console: newport_con:'
> by Bartlomiej's suggestion.
> - add missing release_mem_region() on error and on device removal
> by Bartlomiej's suggestion.
> - add correct fixes commit, before this patch, add a wrong 'Fixes:
> e84de0c6190503 ("MIPS: GIO bus support for SGI IP22/28")'
> thanks Bartlomiej again!
>
> v1 -> v2:
> - modify the commit comments. The commit comments have some more
> appropriate instructions by Markus'suggestion. here is my first
> version commit comments:
>
> if do_take_over_console() return an error in the newport_probe(),
> due to the io virtual address is not released, it will cause a
> leak.
>
> drivers/video/console/newport_con.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/console/newport_con.c
> b/drivers/video/console/newport_con.c
> index 00dddf6e08b0..2d2ee17052e8 100644
> --- a/drivers/video/console/newport_con.c
> +++ b/drivers/video/console/newport_con.c
> @@ -32,6 +32,8 @@
> #include
> #include
>
> +#define NEWPORT_LEN 0x1
> +
> #define FONT_DATA ((unsigned char *)font_vga_8x16.data)
>
> /* borrowed from fbcon.c */
> @@ -43,6 +45,7 @@
> static unsigned char *font_data[MAX_NR_CONSOLES];
>
> static struct newport_regs *npregs;
> +static unsigned long newport_addr;
>
> static int logo_active;
> static int topscan;
> @@ -702,7 +705,6 @@ const struct consw newport_con = {
> static int newport_probe(struct gio_device *dev,
>const struct gio_device_id *id)
> {
> - unsigned long newport_addr;
> int err;
>
> if (!dev->resource.start)
> @@ -712,7 +714,7 @@ static int newport_probe(struct gio_device *dev,
> return -EBUSY; /* we only support one Newport as console */
>
> newport_addr = dev->resource.start + 0xF;
> - if (!request_mem_region(newport_addr, 0x1, "Newport"))
> + if (!request_mem_region(newport_addr, NEWPORT_LEN, "Newport"))
> return -ENODEV;
>
> npregs = (struct newport_regs *)/* ioremap cannot fail */
> @@ -720,6 +722,11 @@ static int newport_probe(struct gio_device *dev,
> console_lock();
> err = do_take_over_console(_con, 0, MAX_NR_CONSOLES - 1, 1);
> console_unlock();
> +
> + if (err) {
> + iounmap((void *)npregs);
> + release_mem_region(newport_addr, NEWPORT_LEN);
> + }
> return err;
> }
>
> @@ -727,6 +734,7 @@ static void newport_remove(struct gio_device *dev)
> {
> give_up_console(_con);
> iounmap((void *)npregs);
> + release_mem_region(newport_addr, NEWPORT_LEN);
> }
>
> static struct gio_device_id newport_ids[] = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [trivial PATCH] video: fbdev: Use IS_BUILTIN
On 5/5/20 1:29 AM, Joe Perches wrote: > IS_BUILTIN can be use to replace various initializations > like #if CONFIG_ int val = 1; #else int val = 0; #endif > so do so. > > Signed-off-by: Joe Perches Applied to drm-misc-next tree (patch should show up in v5.9), thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics > --- > drivers/video/fbdev/aty/aty128fb.c | 6 +- > drivers/video/fbdev/aty/atyfb_base.c | 7 +-- > drivers/video/fbdev/aty/radeon_base.c | 6 +- > drivers/video/fbdev/nvidia/nvidia.c| 6 +- > drivers/video/fbdev/omap/omapfb_main.c | 6 +- > drivers/video/fbdev/riva/fbdev.c | 6 +- > drivers/video/fbdev/s3c2410fb.c| 6 +- > 7 files changed, 7 insertions(+), 36 deletions(-) > > diff --git a/drivers/video/fbdev/aty/aty128fb.c > b/drivers/video/fbdev/aty/aty128fb.c > index d05d4195acad..6fae6ad6cb77 100644 > --- a/drivers/video/fbdev/aty/aty128fb.c > +++ b/drivers/video/fbdev/aty/aty128fb.c > @@ -384,11 +384,7 @@ static int default_lcd_on = 1; > static bool mtrr = true; > > #ifdef CONFIG_FB_ATY128_BACKLIGHT > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > #endif > > /* PLL constants */ > diff --git a/drivers/video/fbdev/aty/atyfb_base.c > b/drivers/video/fbdev/aty/atyfb_base.c > index 49d192869cf5..23a29d61c2a2 100644 > --- a/drivers/video/fbdev/aty/atyfb_base.c > +++ b/drivers/video/fbdev/aty/atyfb_base.c > @@ -317,12 +317,7 @@ static int mclk; > static int xclk; > static int comp_sync = -1; > static char *mode; > - > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > #ifdef CONFIG_PPC > static int default_vmode = VMODE_CHOOSE; > diff --git a/drivers/video/fbdev/aty/radeon_base.c > b/drivers/video/fbdev/aty/radeon_base.c > index e116a3f9ad56..3fe509cb9b87 100644 > --- a/drivers/video/fbdev/aty/radeon_base.c > +++ b/drivers/video/fbdev/aty/radeon_base.c > @@ -269,11 +269,7 @@ static bool force_measure_pll = 0; > static bool nomtrr = 0; > static bool force_sleep; > static bool ignore_devlist; > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > /* Note about this function: we have some rare cases where we must not > schedule, > * this typically happen with our special "wake up early" hook which allows > us to > diff --git a/drivers/video/fbdev/nvidia/nvidia.c > b/drivers/video/fbdev/nvidia/nvidia.c > index c24de9107958..c6820e21875d 100644 > --- a/drivers/video/fbdev/nvidia/nvidia.c > +++ b/drivers/video/fbdev/nvidia/nvidia.c > @@ -74,11 +74,7 @@ static int vram = 0; > static int bpp = 8; > static int reverse_i2c; > static bool nomtrr = false; > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > static char *mode_option = NULL; > > diff --git a/drivers/video/fbdev/omap/omapfb_main.c > b/drivers/video/fbdev/omap/omapfb_main.c > index 1a9d6242916e..0cbcc74fa943 100644 > --- a/drivers/video/fbdev/omap/omapfb_main.c > +++ b/drivers/video/fbdev/omap/omapfb_main.c > @@ -34,11 +34,7 @@ static unsigned long def_vyres; > static unsigned int def_rotate; > static unsigned int def_mirror; > > -#ifdef CONFIG_FB_OMAP_MANUAL_UPDATE > -static bool manual_update = 1; > -#else > -static bool manual_update; > -#endif > +static bool manual_update = IS_BUILTIN(CONFIG_FB_OMAP_MANUAL_UPDATE); > > static struct platform_device*fbdev_pdev; > static struct lcd_panel *fbdev_panel; > diff --git a/drivers/video/fbdev/riva/fbdev.c > b/drivers/video/fbdev/riva/fbdev.c > index 764ec3285e62..9b3493846f4d 100644 > --- a/drivers/video/fbdev/riva/fbdev.c > +++ b/drivers/video/fbdev/riva/fbdev.c > @@ -202,11 +202,7 @@ static int flatpanel = -1; /* Autodetect later */ > static int forceCRTC = -1; > static bool noaccel = 0; > static bool nomtrr = 0; > -#ifdef CONFIG_PMAC_BACKLIGHT > -static int backlight = 1; > -#else > -static int backlight = 0; > -#endif > +static int backlight = IS_BUILTIN(CONFIG_PMAC_BACKLIGHT); > > static char *mode_option = NULL; > static bool strictmode = 0; > diff --git a/drivers/video/fbdev/s3c2410fb.c b/drivers/video/fbdev/s3c2410fb.c > index 2fb15a540167..6f8fa501583f 100644 > --- a/drivers/video/fbdev/s3c2410fb.c > +++ b/drivers/video/fbdev/s3c2410fb.c > @@ -44,11 +44,7 @@ > #include "s3c2410fb.h" > > /* Debugging stuff */ > -#ifdef CONFIG_FB_S3C2410_DEBUG > -static int debug = 1; > -#else > -static int debug; > -#endif > +static int debug = IS_BUILTIN(CONFIG_FB_S3C2410_DEBUG); > > #define dprintk(msg...) \ >
Re: [PATCH v1] video: fbdev: sm712fb: fix an issue about iounmap for a wrong address
On 4/22/20 6:07 PM, Dejin Zheng wrote:
> the sfb->fb->screen_base is not save the value get by iounmap() when
> the chip id is 0x720. so iounmap() for address sfb->fb->screen_base
> is not right.
>
> Fixes: 1461d6672864854 ("staging: sm7xxfb: merge sm712fb with fbdev")
> CC: Andy Shevchenko
> Signed-off-by: Dejin Zheng
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/sm712fb.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
> index 6a1b4a853d9e..8cd655d6d628 100644
> --- a/drivers/video/fbdev/sm712fb.c
> +++ b/drivers/video/fbdev/sm712fb.c
> @@ -1429,6 +1429,8 @@ static int smtc_map_smem(struct smtcfb_info *sfb,
> static void smtc_unmap_smem(struct smtcfb_info *sfb)
> {
> if (sfb && sfb->fb->screen_base) {
> + if (sfb->chip_id == 0x720)
> + sfb->fb->screen_base -= 0x0020;
> iounmap(sfb->fb->screen_base);
> sfb->fb->screen_base = NULL;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb/dss: fix comparison to bool warning
On 4/22/20 9:19 AM, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING:
> Comparison to bool
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING:
> Comparison of 0/1 to bool variable
>
> Signed-off-by: Jason Yan
Applied to drm-misc-next tree (patch should show up in v5.9), thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/omap2/omapfb/dss/dispc.c | 2 +-
> drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> index 4a16798b2ecd..3bb951eb29c7 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
> @@ -888,7 +888,7 @@ static void dispc_ovl_set_color_mode(enum omap_plane
> plane,
> static void dispc_ovl_configure_burst_type(enum omap_plane plane,
> enum omap_dss_rotation_type rotation_type)
> {
> - if (dss_has_feature(FEAT_BURST_2D) == 0)
> + if (!dss_has_feature(FEAT_BURST_2D))
> return;
>
> if (rotation_type == OMAP_DSS_ROT_TILER)
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> index 7060ae56c062..ef659c89ba58 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
> @@ -455,11 +455,9 @@ static void hdmi_disconnect(struct omap_dss_device
> *dssdev,
> static int hdmi_read_edid(struct omap_dss_device *dssdev,
> u8 *edid, int len)
> {
> - bool need_enable;
> + bool need_enable = !hdmi.core_enabled;
> int r;
>
> - need_enable = hdmi.core_enabled == false;
> -
> if (need_enable) {
> r = hdmi_core_enable(dssdev);
> if (r)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/13] backlight: use backlight_is_blank() in all backlight drivers
On Mon, Jun 01, 2020 at 03:28:01PM +0300, Peter Ujfalusi wrote:
>
>
> On 01/06/2020 9.52, Sam Ravnborg wrote:
> > Replaces the open-coded checks of the state etc.,
> > with the backlight_is_blank() helper.
> > This increases readability of the code and align
> > the functionality across the drivers.
>
> Reviewed-by: Peter Ujfalusi
Thanks, I missed your previsous r-b. Sorry.
Sam
>
> > v3:
> > - Dropped as3711_bl, it will be modified in another patch
> >
> > v2:
> > - Fixed so changelog is readable
> >
> > Signed-off-by: Sam Ravnborg
> > Reviewed-by: Daniel Thompson
> > Cc: Lee Jones
> > Cc: Daniel Thompson
> > Cc: Jingoo Han
> > Cc: Michael Hennerich
> > Cc: Support Opensource
> > Cc: Thierry Reding
> > Cc: "Uwe Kleine-König"
> > Cc: Andy Gross
> > Cc: Bjorn Andersson
> > Cc: linux-...@vger.kernel.org
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: patc...@opensource.cirrus.com
> > ---
> > drivers/video/backlight/88pm860x_bl.c| 8 +---
> > drivers/video/backlight/adp5520_bl.c | 5 +
> > drivers/video/backlight/adp8860_bl.c | 5 +
> > drivers/video/backlight/adp8870_bl.c | 5 +
> > drivers/video/backlight/bd6107.c | 4 +---
> > drivers/video/backlight/corgi_lcd.c | 5 +
> > drivers/video/backlight/cr_bllcd.c | 22 +++---
> > drivers/video/backlight/da903x_bl.c | 8 +---
> > drivers/video/backlight/ep93xx_bl.c | 3 +--
> > drivers/video/backlight/gpio_backlight.c | 4 +---
> > drivers/video/backlight/hp680_bl.c | 4 +---
> > drivers/video/backlight/jornada720_bl.c | 2 +-
> > drivers/video/backlight/kb3886_bl.c | 4 +---
> > drivers/video/backlight/led_bl.c | 4 +---
> > drivers/video/backlight/lm3533_bl.c | 4 +---
> > drivers/video/backlight/locomolcd.c | 4 +---
> > drivers/video/backlight/lv5207lp.c | 4 +---
> > drivers/video/backlight/max8925_bl.c | 8 +---
> > drivers/video/backlight/pwm_bl.c | 4 +---
> > drivers/video/backlight/qcom-wled.c | 4 +---
> > drivers/video/backlight/tps65217_bl.c| 4 +---
> > drivers/video/backlight/wm831x_bl.c | 8 +---
> > 22 files changed, 28 insertions(+), 95 deletions(-)
> >
> > diff --git a/drivers/video/backlight/88pm860x_bl.c
> > b/drivers/video/backlight/88pm860x_bl.c
> > index 20d96a5ac384..162c83ab0f5a 100644
> > --- a/drivers/video/backlight/88pm860x_bl.c
> > +++ b/drivers/video/backlight/88pm860x_bl.c
> > @@ -123,13 +123,7 @@ 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)
> > + if (backlight_is_blank(bl))
> > brightness = 0;
> >
> > return pm860x_backlight_set(bl, brightness);
> > diff --git a/drivers/video/backlight/adp5520_bl.c
> > b/drivers/video/backlight/adp5520_bl.c
> > index 0f63f76723a5..d817b0d95c9d 100644
> > --- a/drivers/video/backlight/adp5520_bl.c
> > +++ b/drivers/video/backlight/adp5520_bl.c
> > @@ -67,10 +67,7 @@ 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)
> > + if (backlight_is_blank(bl))
> > brightness = 0;
> >
> > return adp5520_bl_set(bl, brightness);
> > diff --git a/drivers/video/backlight/adp8860_bl.c
> > b/drivers/video/backlight/adp8860_bl.c
> > index 19968104fc47..a0ce2a3701fa 100644
> > --- a/drivers/video/backlight/adp8860_bl.c
> > +++ b/drivers/video/backlight/adp8860_bl.c
> > @@ -363,10 +363,7 @@ 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)
> > + if (backlight_is_blank(bl))
> > brightness = 0;
> >
> > return adp8860_bl_set(bl, brightness);
> > diff --git a/drivers/video/backlight/adp8870_bl.c
> > b/drivers/video/backlight/adp8870_bl.c
> > index 4c0032010cfe..ae4269fdb189 100644
> > --- a/drivers/video/backlight/adp8870_bl.c
> > +++ b/drivers/video/backlight/adp8870_bl.c
> > @@ -401,10 +401,7 @@ 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)
> > + if (backlight_is_blank(bl))
> > brightness = 0;
> >
> > return adp8870_bl_set(bl, brightness);
> > diff --git
Re: [PATCH] drm/doc: device hot-unplug for userspace
On Thu, 28 May 2020 16:45:45 +0200 Daniel Vetter wrote: > On Thu, May 28, 2020 at 03:27:57PM +0300, Pekka Paalanen wrote: ... > > Hmm. Maybe Wayland compositors should ignore all EGL import failures > > that happen after the wl_buffer has been created (which implies that > > the dmabuf has been validated to work initially). When import fails at > > a later time, the compositor should just paint some error pattern > > instead of the window. That would let the kernel keep on returning > > errors. > > > > Yeah, ok. I'll keep the ENODEV there in my next version. Let's see how > > that looks then. > > tbh I have no idea what to do with dma-buf shared across drivers. > > For dma-fence it's fairly simple: Force-complete them all, with an error > code of ENODEV. But for dma-buf I have no idea. As long as the dma-buf > sits in system memory it should keep working, plus/minus bugs in the > exporter where it tries to look at device state that might no longer be > there. > > The real fun starts when the buffer is in vram, or when the mmap somehow > goes through the device (but that's more a case for integrated gpu, and > it's a bit hard to hotunplug those and consider that a real use-case). Is forced driver unbind not a real use-case, or would it not invalidate the memory references wrapped in a dmabuf? In the proposal, I listed driver unbind as a use-case. I don't mind if cross-driver shared dmabuf needed ten years of kernel internals development to reach a state where it won't explode anymore, but that's the goal I want to set today. I don't think we can tell userspace to never share dmabufs cross-device if the exporter device is hot-unpluggable, can we? Thanks, pq pgplN05qN8CNF.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[BUG][AMD tahiti xt][amdgpu] broken dpm
Hi, updated my amd-staging-drm-next branch yesterday: the GPU fans do not reduce their rpm anymore. I checked the kernel log (attached) and I noticed: [drm:0xa036d50d] *ERROR* si_set_sw_state failed Is the fix already known or shall I start to bisect? (no rebase on linux master: should not be hell) regards, -- Sylvain [0.00] Linux version 5.6.0-1+ (root@) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Sun May 31 11:57:46 UTC 2020 [0.00] Command line: cinitramfs_root_uuid=1ef689ac-d88a-4d69-844e-0197359f772f initrd=\5.6.0-1+.cpio.xz [0.00] KERNEL supported cpus: [0.00] AMD AuthenticAMD [0.00] random: get_random_u32 called from 0x81019458 with crng_init=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009] usable [0.00] BIOS-e820: [mem 0x0010-0xcd841fff] usable [0.00] BIOS-e820: [mem 0xcd842000-0xcdb23fff] reserved [0.00] BIOS-e820: [mem 0xcdb24000-0xcde75fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcde76000-0xcea3dfff] reserved [0.00] BIOS-e820: [mem 0xcea3e000-0xcea3efff] usable [0.00] BIOS-e820: [mem 0xcea3f000-0xcec44fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcec45000-0xcf06dfff] usable [0.00] BIOS-e820: [mem 0xcf06e000-0xcf7eefff] reserved [0.00] BIOS-e820: [mem 0xcf7ef000-0xcf7f] usable [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved [0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved [0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved [0.00] BIOS-e820: [mem 0xfef0-0x] reserved [0.00] BIOS-e820: [mem 0x00011000-0x00022fff] usable [0.00] NX (Execute Disable) protection: active [0.00] e820: update [mem 0xbd18f018-0xbd1ad057] usable ==> usable [0.00] e820: update [mem 0xbd18f018-0xbd1ad057] usable ==> usable [0.00] e820: update [mem 0xbd17e018-0xbd18e057] usable ==> usable [0.00] e820: update [mem 0xbd17e018-0xbd18e057] usable ==> usable [0.00] extended physical RAM map: [0.00] reserve setup_data: [mem 0x-0x0009] usable [0.00] reserve setup_data: [mem 0x0010-0xbd17e017] usable [0.00] reserve setup_data: [mem 0xbd17e018-0xbd18e057] usable [0.00] reserve setup_data: [mem 0xbd18e058-0xbd18f017] usable [0.00] reserve setup_data: [mem 0xbd18f018-0xbd1ad057] usable [0.00] reserve setup_data: [mem 0xbd1ad058-0xcd841fff] usable [0.00] reserve setup_data: [mem 0xcd842000-0xcdb23fff] reserved [0.00] reserve setup_data: [mem 0xcdb24000-0xcde75fff] ACPI NVS [0.00] reserve setup_data: [mem 0xcde76000-0xcea3dfff] reserved [0.00] reserve setup_data: [mem 0xcea3e000-0xcea3efff] usable [0.00] reserve setup_data: [mem 0xcea3f000-0xcec44fff] ACPI NVS [0.00] reserve setup_data: [mem 0xcec45000-0xcf06dfff] usable [0.00] reserve setup_data: [mem 0xcf06e000-0xcf7eefff] reserved [0.00] reserve setup_data: [mem 0xcf7ef000-0xcf7f] usable [0.00] reserve setup_data: [mem 0xfec0-0xfec00fff] reserved [0.00] reserve setup_data: [mem 0xfec1-0xfec10fff] reserved [0.00] reserve setup_data: [mem 0xfec2-0xfec20fff] reserved [0.00] reserve setup_data: [mem 0xfed0-0xfed00fff] reserved [0.00] reserve setup_data: [mem 0xfed61000-0xfed70fff] reserved [0.00] reserve setup_data: [mem 0xfed8-0xfed8] reserved [0.00] reserve setup_data: [mem 0xfef0-0x] reserved [0.00] reserve setup_data: [mem 0x00011000-0x00022fff] usable [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi:
Re: [PATCH v3] drm/fourcc: document modifier uniqueness requirements
Sorry for commenting on the obsolete v1 - that'll teach me for reading
my backlog chronologically.
On Thu, May 28, 2020 at 02:38:36PM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like the consensus was to not allow this. Document this in drm_fourcc.h.
>
> There are several reasons for this.
>
> - Encoding all of these constraints in the modifiers would explode the
> search space pretty quickly (we only have 64 bits to work with).
> - Modifiers need to be unambiguous: a buffer can only have a single
> modifier.
> - Modifier users aren't expected to parse modifiers.
>
> v2: add paragraph about aliases (Daniel)
>
> v3: fix unrelated changes sent with the patch
>
> Signed-off-by: Simon Ser
> Reviewed-by: Daniel Vetter
> Cc: Daniel Stone
> Cc: Bas Nieuwenhuizen
> Cc: Dave Airlie
> Cc: Marek Olšák
> ---
> include/uapi/drm/drm_fourcc.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 490143500a50..f41fcb1ed63d 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -58,6 +58,21 @@ extern "C" {
> * may preserve meaning - such as number of planes - from the fourcc code,
> * whereas others may not.
> *
> + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> must
> + * match only a single modifier. A modifier must not be a subset of layouts
> of
> + * another modifier. For instance, it's incorrect to encode pitch alignment
> in
> + * a modifier: a buffer may match a 64-pixel aligned modifier and a 32-pixel
> + * aligned modifier. That said, modifiers can have implicit minimal
> + * requirements.
> + *
> + * For modifiers where the combination of fourcc code and modifier can alias,
> + * a canonical pair needs to be defined and used by all drivers. An example
> + * is AFBC, where both ARGB and ABGR have the exact same compressed layout.
As I mentioned, this isn't true for AFBC (at least, it shouldn't be),
so I don't think we can use that as an example.
We define a "canonical" ordering in AFBC for exactly this reason - the
ordering can differ and not all decoders support all orderings, so we
need to pick one for best compatibility.
Thanks,
-Brian
> + *
> + * Users see modifiers as opaque tokens they can check for equality and
> + * intersect. Users musn't need to know to reason about the modifier value
> + * (i.e. users are not expected to extract information out of the modifier).
> + *
> * Vendors should document their modifier usage in as much detail as
> * possible, to ensure maximum compatibility across devices, drivers and
> * applications.
> --
> 2.26.2
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: document modifier uniqueness requirements
> > > + * Users see modifiers as opaque tokens they can check for equality and > > > + * intersect. Users musn't need to know to reason about the modifier > > > value > > > + * (i.e. users are not expected to extract information out of the > > > modifier). > > > + * > > Doesn't this conflict with "implicit minimal requirements" above? Ah, when I wrote "users", I meant "non-driver users": programs like compositors and user-space applications. Of course kernel and user-space drivers can extract information out of the modifiers. Is this why there's some confusion here? > Certainly for a bunch of different AFBC modifiers, the allocator would > need to understand some fields in order to properly align-up the > buffer size. It's probably a little early to speculate on the future allocator design. For instance, instead of having a monolithic allocator, the kernel driver (and other buffer consumers) could advertise a list of constraints for each format/modifier. That way no-one would need to extract information out of modifiers to figure out alignment (but maybe drivers would still want to, to reject bad imports for instance). But again, I'm just throwing ideas around at this point. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: uvesafb: use true,false for bool variables
Hi,
On 4/22/20 9:18 AM, Jason Yan wrote:
> Fix the following coccicheck warning:
>
> drivers/video/fbdev/uvesafb.c:48:12-17: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1827:3-13: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1829:3-13: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1835:3-9: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1837:3-9: WARNING: Assignment of 0/1 to
> bool variable
> drivers/video/fbdev/uvesafb.c:1839:3-8: WARNING: Assignment of 0/1 to
> bool variable
>
> Signed-off-by: Jason Yan
> ---
> drivers/video/fbdev/uvesafb.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/uvesafb.c b/drivers/video/fbdev/uvesafb.c
> index 1b385cf76110..bee29aadc646 100644
> --- a/drivers/video/fbdev/uvesafb.c
> +++ b/drivers/video/fbdev/uvesafb.c
> @@ -45,7 +45,7 @@ static const struct fb_fix_screeninfo uvesafb_fix = {
> };
>
> static int mtrr = 3;/* enable mtrr by default */
> -static bool blank= 1;/* enable blanking by default */
> +static bool blank= true; /* enable blanking by default */
> static int ypan = 1;/* 0: scroll, 1: ypan, 2: ywrap */
> static bool pmi_setpal = true; /* use PMI for palette changes */
> static bool nocrtc; /* ignore CRTC settings */
> @@ -1824,19 +1824,19 @@ static int uvesafb_setup(char *options)
> else if (!strcmp(this_opt, "ywrap"))
> ypan = 2;
> else if (!strcmp(this_opt, "vgapal"))
> - pmi_setpal = 0;
> + pmi_setpal = false;
> else if (!strcmp(this_opt, "pmipal"))
> - pmi_setpal = 1;
> + pmi_setpal = true;
> else if (!strncmp(this_opt, "mtrr:", 5))
> mtrr = simple_strtoul(this_opt+5, NULL, 0);
> else if (!strcmp(this_opt, "nomtrr"))
> mtrr = 0;
> else if (!strcmp(this_opt, "nocrtc"))
> - nocrtc = 1;
> + nocrtc = true;
> else if (!strcmp(this_opt, "noedid"))
> - noedid = 1;
> + noedid = true;
> else if (!strcmp(this_opt, "noblank"))
> - blank = 0;
> + blank = true;
The above conversion is incorrect.
The follow-up fix is included below (the original patch has been
already applied).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] video: fbdev: uvesafb: fix "noblank" option handling
Fix the recent regression.
Fixes: dbc7ece12a38 ("video: uvesafb: use true,false for bool variables")
Cc: Jason Yan
Cc: Sam Ravnborg
Cc: Michal Januszewski
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/uvesafb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/video/fbdev/uvesafb.c
===
--- a/drivers/video/fbdev/uvesafb.c
+++ b/drivers/video/fbdev/uvesafb.c
@@ -1836,7 +1836,7 @@ static int uvesafb_setup(char *options)
else if (!strcmp(this_opt, "noedid"))
noedid = true;
else if (!strcmp(this_opt, "noblank"))
- blank = true;
+ blank = false;
else if (!strncmp(this_opt, "vtotal:", 7))
vram_total = simple_strtoul(this_opt + 7, NULL, 0);
else if (!strncmp(this_opt, "vremap:", 7))
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: document modifier uniqueness requirements
On Wed, May 27, 2020 at 10:55:34AM +0200, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 08:52:00AM +, Simon Ser wrote:
> > There have suggestions to bake pitch alignment, address alignement,
> > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > constraints into modifiers. Last time this was brought up it seemed
> > like the consensus was to not allow this. Document this in drm_fourcc.h.
> >
> > There are several reasons for this.
> >
> > - Encoding all of these constraints in the modifiers would explode the
> > search space pretty quickly (we only have 64 bits to work with).
> > - Modifiers need to be unambiguous: a buffer can only have a single
> > modifier.
> > - Modifier users aren't expected to parse modifiers.
> >
> > Signed-off-by: Simon Ser
> > Cc: Daniel Vetter
> > Cc: Daniel Stone
> > Cc: Bas Nieuwenhuizen
> > Cc: Dave Airlie
> > Cc: Marek Olšák
> > ---
> > include/uapi/drm/drm_fourcc.h | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 490143500a50..97eb0f1cf9f8 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -58,6 +58,17 @@ extern "C" {
> > * may preserve meaning - such as number of planes - from the fourcc code,
> > * whereas others may not.
> > *
> > + * Modifiers must uniquely encode buffer layout. In other words, a buffer
> > must
> > + * match only a single modifier. A modifier must not be a subset of
> > layouts of
> > + * another modifier. For instance, it's incorrect to encode pitch
> > alignment in
> > + * a modifier: a buffer may match a 64-pixel aligned modifier and a
> > 32-pixel
> > + * aligned modifier. That said, modifiers can have implicit minimal
> > + * requirements.
>
> I think we should also add the aliasing when the fourcc codes are
> involved, with afbc as example. Maybe:
>
> For modifiers where the combination of fourcc code and modifier can alias,
> a canonical pair needs to be defined and used by all drivers. An example
> is afbc, where both argb and abgr have the exact same compressed layout.
That's actually explicitly _not_ the case for AFBC, which was one of
the things I was trying to document in afbc.rst.
>
> With something like that added:
>
> Reviewed-by: Daniel Vetter
>
>
> > + *
> > + * Users see modifiers as opaque tokens they can check for equality and
> > + * intersect. Users musn't need to know to reason about the modifier value
> > + * (i.e. users are not expected to extract information out of the
> > modifier).
> > + *
Doesn't this conflict with "implicit minimal requirements" above?
Certainly for a bunch of different AFBC modifiers, the allocator would
need to understand some fields in order to properly align-up the
buffer size.
Thanks,
-Brian
> > * Vendors should document their modifier usage in as much detail as
> > * possible, to ensure maximum compatibility across devices, drivers and
> > * applications.
> > --
> > 2.26.2
> >
> >
>
> --
> 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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/2] video: fbdev: fix error handling, convert to pin_user_pages*()
On Mon, Jun 1, 2020 at 1:00 AM John Hubbard wrote:
> On 2020-05-31 14:11, Andy Shevchenko wrote:
> > ...
> > JFYI, we have history.git starting from v0.01.
> >
> OK, thanks for that note. According to that history.git [1],
> then: drivers/video/pvr2fb.c had get_user_pages_fast() support added to
> pvr2fb_write() back in 2004, but only for CONFIG_SH_DMA, as part of
>
> commit 434502754f2 ("[PATCH] SH Merge")
>
> ...and that commit created the minor bug that patch 0001 here
> addresses. (+Cc Paul just for the sake of completeness.)
>
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
I mentioned this one, but I guess content should be the same.
https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/13] backlight: as3711_bl: introduce backlight_is_blank()
On Mon, Jun 01, 2020 at 08:52:06AM +0200, Sam Ravnborg wrote:
> Replaces the open-coded checks of the state, with the
> backlight_is_blank() helper. This increases readability
> of the code and aling the functionality across the drivers.
>
> Futhermore drop the debug prints in update_status().
> If we need debug printing then we can add it to the backlight core.
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Emil Velikov
> ---
> drivers/video/backlight/as3711_bl.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/video/backlight/as3711_bl.c
> b/drivers/video/backlight/as3711_bl.c
> index 33f0f0f2e8b3..cc5628beaffd 100644
> --- a/drivers/video/backlight/as3711_bl.c
> +++ b/drivers/video/backlight/as3711_bl.c
> @@ -107,13 +107,7 @@ static int as3711_bl_update_status(struct
> backlight_device *bl)
> int brightness = bl->props.brightness;
> int ret = 0;
>
> - dev_dbg(>dev, "%s(): brightness %u, pwr %x, blank %x, state %x\n",
> - __func__, bl->props.brightness, bl->props.power,
> - bl->props.fb_blank, bl->props.state);
> -
> - if (bl->props.power != FB_BLANK_UNBLANK ||
> - bl->props.fb_blank != FB_BLANK_UNBLANK ||
> - bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> + if (backlight_is_blank(bl))
> brightness = 0;
>
> if (data->type == AS3711_BL_SU1) {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/13] backlight: add overview and update existing doc
On Mon, Jun 01, 2020 at 08:52:04AM +0200, Sam Ravnborg wrote:
> Add overview chapter to backlight.c.
> Update existing kernel-doc to follow a more consistent
> style and drop kernel-doc for deprecated functions.
>
> v2:
> - Sevaral editorial corrections that makes reading
> much easier (Daniel)
> - Spelling fixes (Daniel)
> - updated intro chapter with a little more info
>
> Signed-off-by: Sam Ravnborg
Two very small nits... but one will affect formatted output so I had to
raise it. Feel free add my Reviewed-by: when recirculating!
Daniel.
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
> drivers/video/backlight/backlight.c | 131 +++-
> 1 file changed, 90 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 17f04cff50ab..06bcddd76a7e 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -22,6 +22,46 @@
> #include
> #endif
>
> +/**
> + * DOC: overview
> + *
> + * The backlight core supports implementing backlight drivers.
> + *
> + * A backlight driver registers a driver using
> + * devm_backlight_device_register(). The properties of the backlight
> + * driver such as type and max_brightness must be specified.
> + * When the core detect changes in for example brightness or power state
> + * the update_status() operation is called. The backlight driver shall
> + * implement this operation and use it to adjust backlight.
> + *
> + * Several sysfs attributes are provided by the backlight core::
> + *
> + * - brightness R/W, set the requested brightness level
> + * - actual_brighness RO, the brightness level used by the HW
> + * - max_brightness RO, the maximum brightness level supported
> + *
> + * See Documentation/ABI/stable/sysfs-class-backlight for the full list.
> + *
> + * The backlight can be adjusted using the sysfs interface, and
> + * the backlight driver may also support adjusting backlight using
> + * a hot-key or some other platfrom or firmware specific way.
> + *
> + * The driver shall implement the get_brightness() operation if
I overlooked this before but this reads better with "must" rather
than "shall". It's not wrong to use shall but I think it is more
idiomatic to use "must".
> + * the HW do not support all the levels that can be specified in
> + * brightness, thus providing user-space access to the actual level
> + * via the actual_brightness attribute.
> + * When the backlight changes this is reported to user-space using
Missing newline between paragraphs...
> + * an uevent connected to the actual_brightness attribute.
> + * When brightness is set by platform specific means, for example
> + * a hot-key to adjust backlight, the driver must notify the backlight
> + * core that brightness has changed using backlight_force_update().
> + *
> + * The backlight driver core receives notifications from fbdev and
> + * if the event is FB_EVENT_BLANK and if the value of blank, from the
> + * FBIOBLANK ioclt, results in a change in the backlight state the
> + * update_status() operation is called.
> + */
> +
> static struct list_head backlight_dev_list;
> static struct mutex backlight_dev_list_mutex;
> static struct blocking_notifier_head backlight_notifier;
> @@ -40,9 +80,17 @@ static const char *const backlight_scale_types[] = {
>
> #if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
> defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
> -/* This callback gets called when something important happens inside a
> - * framebuffer driver. We're looking if that important event is blanking,
> - * and if it is and necessary, we're switching backlight power as well ...
> +/*
> + * fb_notifier_callback
> + *
> + * This callback gets called when something important happens inside a
> + * framebuffer driver. The backlight core only cares about FB_BLANK_UNBLANK
> + * which is reported to the driver using backlight_update_status()
> + * as a state change.
> + *
> + * There may be several fbdev's connected to the backlight device,
> + * in which case they are kept track of. A state change is only reported
> + * if there is a change in backlight for the specified fbdev.
> */
> static int fb_notifier_callback(struct notifier_block *self,
> unsigned long event, void *data)
> @@ -318,12 +366,15 @@ static struct attribute *bl_device_attrs[] = {
> ATTRIBUTE_GROUPS(bl_device);
>
> /**
> - * backlight_force_update - tell the backlight subsystem that hardware state
> - * has changed
> + * backlight_force_update - force an update due to a hardware change
> * @bd: the backlight device to update
> + * @reason: the method used for the backlight update
> *
> * Updates the internal state of the backlight in response to a hardware
> event,
> - * and generate a uevent to notify userspace
> + * and generates an uevent to notify userspace. A
Re: [PATCH v3 05/13] backlight: improve backlight_device documentation
On Mon, Jun 01, 2020 at 08:51:59AM +0200, Sam Ravnborg wrote:
> Improve the documentation for backlight_device and
> adapt it to kernel-doc style.
>
> v2:
> - Add short intro to all fields (Daniel)
> - Updated description of update_lock (Daniel)
I like the update... but it doesn't cover what I was commenting on.
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 69a20da03035..cae1af95dd9d 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -14,21 +14,6 @@
> #include
> #include
>
> -/* Notes on locking:
> - *
> - * backlight_device->ops_lock is an internal backlight lock protecting the
> - * ops pointer and no code outside the core should need to touch it.
> - *
> - * Access to update_status() is serialised by the update_lock mutex since
> - * most drivers seem to need this and historically get it wrong.
> - *
> - * Most drivers don't need locking on their get_brightness() method.
> - * If yours does, you need to implement it in the driver. You can use the
> - * update_lock mutex if appropriate.
This explicitly says that drivers are permitted to use update_lock in
their get_brightness() method.
> - *
> - * Any other use of the locks below is probably wrong.
> - */
> -
> enum backlight_update_reason {
> BACKLIGHT_UPDATE_HOTKEY,
> BACKLIGHT_UPDATE_SYSFS,
> @@ -215,30 +200,71 @@ struct backlight_properties {
> enum backlight_scale scale;
> };
>
> +/**
> + * struct backlight_device - backlight device data
> + *
> + * This structure holds all data required by a backlight device.
> + */
> struct backlight_device {
> - /* Backlight properties */
> + /**
> + * @props: Backlight properties
> + */
> struct backlight_properties props;
>
> - /* Serialise access to update_status method */
> + /**
> + * @update_lock: The lock used when calling the update_status()
> operation.
> + *
> + * update_lock is an internal backlight lock that serialise access
> + * to the update_status() operation. The backlight core holds the
> update_lock
> + * when calling the update_status() operation. The update_lock shall not
> + * be used by backlight drivers.
> + */
This contradicts the original comment about locking.
I'm fairly neutral about the change (AFAICT no driver actually ever
uses update_lock from get_brightness) but if we add new documentation
that flatly contradicts old documentary comments then I'd expect to
see something in the patch description explaining that the change
really is deliberate (and why it is a good change).
Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 04/13] backlight: improve backlight_properties documentation
On Mon, Jun 01, 2020 at 08:51:58AM +0200, Sam Ravnborg wrote:
> Improve the documentation for backlight_properties and
> adapt it to kernel-doc style.
>
> v2:
> - Added into for each field (Daniel)
> - Re-written some parts to explain what to do, rather
> than what not to do.
> Partly based on suggestions from the review (Daniel)
>
> Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> ---
> include/linux/backlight.h | 96 ++-
> 1 file changed, 85 insertions(+), 11 deletions(-)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index b6c1ab6c922a..69a20da03035 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -117,28 +117,102 @@ struct backlight_ops {
> int (*check_fb)(struct backlight_device *bd, struct fb_info *info);
> };
>
> -/* This structure defines all the properties of a backlight */
> +/**
> + * struct backlight_properties - backlight properties
> + *
> + * This structure defines all the properties of a backlight.
> + */
> struct backlight_properties {
> - /* Current User requested brightness (0 - max_brightness) */
> + /**
> + * @brightness: The current brightness requested by the user.
> + *
> + * The backlight core makes sure the range is (0 to max_brightness)
> + * when the brightness is set via the sysfs attribute:
> + * /sys/class/backlight//brightness.
> + *
> + * This value can be set in the backlight_properties passed
> + * to devm_backlight_device_register() to set a default brightness
> + * value.
> + */
> int brightness;
> - /* Maximal value for brightness (read-only) */
> +
> + /**
> + * @max_brightness: The maximum brightness value.
> + *
> + * This value must be set in the backlight_properties passed to
> + * devm_backlight_device_register() and shall not be modified by the
> + * driver after registration.
> + */
> int max_brightness;
> - /* Current FB Power mode (0: full on, 1..3: power saving
> -modes; 4: full off), see FB_BLANK_XXX */
> +
> + /**
> + * @power: The current power mode.
> + *
> + * User space can configure the power mode using the sysfs
> + * attribute: /sys/class/backlight//bl_power
> + * When the power property is updated update_status() is called.
> + *
> + * The possible values are: (0: full on, 1 to 3: power saving
> + * modes; 4: full off), see FB_BLANK_XXX.
> + *
> + * When the backlight device is enabled @power is set
> + * to FB_BLANK_UNBLANK. When the backlight device is disabled
> + * @power is set to FB_BLANK_POWERDOWN.
> + */
> int power;
> - /* FB Blanking active? (values as for power) */
> - /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
> +
> + /**
> + * @fb_blank: The power state from the FBIOBLANK ioclt.
> + *
> + * When the FBIOBLANK ioctl is called fb_blank is set to the
> + * blank parameter and the update_status() operation is called.
> + *
> + * When the backlight device is enabled @fb_blank is set
> + * to FB_BLANK_UNBLANK. When the backlight device is disabled
> + * @fb_blank is set to FB_BLANK_POWERDOWN.
> + *
> + * Backlight drivers should avoid using this property. It has been
> + * replaced by state & BL_CORE_FBLANK (although most drivers should
> + * use backlight_is_blank() as the preferred means to get the blank
> + * state).
> + *
> + * fb_blank is deprecated and will be removed.
> + */
> int fb_blank;
> - /* Backlight type */
> +
> + /**
> + * @type: The type of backlight supported.
> + *
> + * The backlight type allows userspace to make appropriate
> + * policy desicions based on the backlight type.
> + *
> + * This value must be set in the backlight_properties
> + * passed to devm_backlight_device_register().
> + */
> enum backlight_type type;
> - /* Flags used to signal drivers of state changes */
> +
> + /**
> + * @state: The state of the backlight core.
> + *
> + * The state is a bitmask. BL_CORE_FBBLANK is set when the display
> + * is expected to be blank. BL_CORE_SUSPENDED is set when the
> + * driver is suspended.
> + *
> + * backlight drivers are excpected to use backlight_is_blank()
> + * in their update_status() operation rather than reading the
> + * state property.
> + *
> + * The state is maintained by the core and drivers may not modify it.
> + */
> unsigned int state;
> - /* Type of the brightness scale (linear, non-linear, ...) */
> - enum backlight_scale scale;
>
> #define BL_CORE_SUSPENDED(1 << 0)/* backlight is suspended */
> #define BL_CORE_FBBLANK (1 << 1)/*
Re: [RFC PATCH v5 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device
Cc: Rob, devicetree ML
On 31.05.2020 01:57, Chanwoo Choi wrote:
> On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
> wrote:
>>
>> This patch adds registration of a child platform device for the exynos
>> interconnect driver. It is assumed that the interconnect provider will
>> only be needed when #interconnect-cells property is present in the bus
>> DT node, hence the child device will be created only when such a property
>> is present.
>>
>> Signed-off-by: Sylwester Nawrocki
>>
>> Changes for v5:
>> - new patch.
>> ---
>> drivers/devfreq/exynos-bus.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>> index 8fa8eb5..856e37d 100644
>> --- a/drivers/devfreq/exynos-bus.c
>> +++ b/drivers/devfreq/exynos-bus.c
>> @@ -24,6 +24,7 @@
>>
>> struct exynos_bus {
>> struct device *dev;
>> + struct platform_device *icc_pdev;
>>
>> struct devfreq *devfreq;
>> struct devfreq_event_dev **edev;
>> @@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
>> if (ret < 0)
>> dev_warn(dev, "failed to disable the devfreq-event
>> devices\n");
>>
>> + platform_device_unregister(bus->icc_pdev);
>> +
>> dev_pm_opp_of_remove_table(dev);
>> clk_disable_unprepare(bus->clk);
>> if (bus->opp_table) {
>> @@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
>> {
>> struct exynos_bus *bus = dev_get_drvdata(dev);
>>
>> + platform_device_unregister(bus->icc_pdev);
>> +
>> dev_pm_opp_of_remove_table(dev);
>> clk_disable_unprepare(bus->clk);
>> }
>> @@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device
>> *pdev)
>> if (ret < 0)
>> goto err;
>>
>> + /* Create child platform device for the interconnect provider */
>> + if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
>> + bus->icc_pdev = platform_device_register_data(
>> + dev, "exynos-generic-icc",
>> + PLATFORM_DEVID_AUTO, NULL,
>> 0);
>> +
>> + if (IS_ERR(bus->icc_pdev)) {
>> + ret = PTR_ERR(bus->icc_pdev);
>> + goto err;
>> + }
>> + }
>> +
>> max_state = bus->devfreq->profile->max_state;
>> min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
>> max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
>> --
>> 2.7.4
>>
>
> It looks like very similar like the registering the interconnect
> device of imx-bus.c
> and I already reviewed and agreed this approach.
>
> Acked-by: Chanwoo Choi
>
> nitpick: IMHO, I think that 'exynos-icc' is proper and simple without
> 'generic' word.
> If we need to add new icc compatible int the future, we will add
> 'exynos-icc' new compatible.
> But, I'm not forcing it. just opinion. Anyway, I agree this approach.
Thanks for review. I will change the name to exynos-icc in next version,
as I commented at other patch, it is not part of any DT binding,
it is just for device/driver matching between devfreq and interconnect.
--
Thanks,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
Cc: Rob, devicetree ML
On 31.05.2020 02:13, Chanwoo Choi wrote:
> On Sat, May 30, 2020 at 1:34 AM Sylwester Nawrocki
> wrote:
>>
>> This patch adds a generic interconnect driver for Exynos SoCs in order
>> to provide interconnect functionality for each "samsung,exynos-bus"
>> compatible device.
>>
>> The SoC topology is a graph (or more specifically, a tree) and its
>> edges are specified using the 'samsung,interconnect-parent' in the
>> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
>> propagated to ensure that the parent is probed before its children.
>>
>> Each bus is now an interconnect provider and an interconnect node as
>> well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
>> registers itself as a node. Node IDs are not hardcoded but rather
>> assigned dynamically at runtime. This approach allows for using this
>> driver with various Exynos SoCs.
>>
>> Frequencies requested via the interconnect API for a given node are
>> propagated to devfreq using dev_pm_qos_update_request(). Please note
>> that it is not an error when CONFIG_INTERCONNECT is 'n', in which
>> case all interconnect API functions are no-op.
>>
>> Signed-off-by: Artur Świgoń
>> Signed-off-by: Sylwester Nawrocki
>>
>> Changes for v5:
>> - adjust to renamed exynos,interconnect-parent-node property,
>> - use automatically generated platform device id as the interconect
>>node id instead of a now unavailable devfreq->id field,
>> - add icc_ prefix to some variables to make the code more self-commenting,
>> - use icc_nodes_remove() instead of icc_node_del() + icc_node_destroy(),
>> - adjust to exynos,interconnect-parent-node property rename to
>>samsung,interconnect-parent,
>> - converted to a separate platform driver in drivers/interconnect.
>> ---
>> drivers/interconnect/Kconfig | 1 +
>> drivers/interconnect/Makefile| 1 +
>> drivers/interconnect/exynos/Kconfig | 6 ++
>> drivers/interconnect/exynos/Makefile | 4 +
>> drivers/interconnect/exynos/exynos.c | 185
>> +++
>> 5 files changed, 197 insertions(+)
>> create mode 100644 drivers/interconnect/exynos/Kconfig
>> create mode 100644 drivers/interconnect/exynos/Makefile
>> create mode 100644 drivers/interconnect/exynos/exynos.c
>>
>> diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
>> index 5b7204e..eca6eda 100644
>> --- a/drivers/interconnect/Kconfig
>> +++ b/drivers/interconnect/Kconfig
>> @@ -11,6 +11,7 @@ menuconfig INTERCONNECT
>>
>> if INTERCONNECT
>>
>> +source "drivers/interconnect/exynos/Kconfig"
>> source "drivers/interconnect/imx/Kconfig"
>> source "drivers/interconnect/qcom/Kconfig"
>>
>> diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
>> index 4825c28..2ba1de6 100644
>> --- a/drivers/interconnect/Makefile
>> +++ b/drivers/interconnect/Makefile
>> @@ -4,5 +4,6 @@ CFLAGS_core.o := -I$(src)
>> icc-core-objs := core.o
>>
>> obj-$(CONFIG_INTERCONNECT) += icc-core.o
>> +obj-$(CONFIG_INTERCONNECT_EXYNOS) += exynos/
>> obj-$(CONFIG_INTERCONNECT_IMX) += imx/
>> obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
>> diff --git a/drivers/interconnect/exynos/Kconfig
>> b/drivers/interconnect/exynos/Kconfig
>> new file mode 100644
>> index 000..e51e52e
>> --- /dev/null
>> +++ b/drivers/interconnect/exynos/Kconfig
>> @@ -0,0 +1,6 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +config INTERCONNECT_EXYNOS
>> + tristate "Exynos generic interconnect driver"
>> + depends on ARCH_EXYNOS || COMPILE_TEST
>> + help
>> + Generic interconnect driver for Exynos SoCs.
>> diff --git a/drivers/interconnect/exynos/Makefile
>> b/drivers/interconnect/exynos/Makefile
>> new file mode 100644
>> index 000..e19d1df
>> --- /dev/null
>> +++ b/drivers/interconnect/exynos/Makefile
>> @@ -0,0 +1,4 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +exynos-interconnect-objs := exynos.o
>> +
>> +obj-$(CONFIG_INTERCONNECT_EXYNOS) += exynos-interconnect.o
>> diff --git a/drivers/interconnect/exynos/exynos.c
>> b/drivers/interconnect/exynos/exynos.c
>> new file mode 100644
>> index 000..8278194
>> --- /dev/null
>> +++ b/drivers/interconnect/exynos/exynos.c
>> @@ -0,0 +1,185 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Exynos generic interconnect provider driver
>> + *
>> + * Copyright (c) 2020 Samsung Electronics Co., Ltd.
>> + *
>> + * Authors: Artur Świgoń
>> + * Sylwester Nawrocki
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define kbps_to_khz(x) ((x) / 8)
>> +
>> +struct exynos_icc_priv {
>> + struct device *dev;
>> +
>> + /* One interconnect node per provider */
>> + struct icc_provider provider;
>> + struct icc_node *node;
>> +
>> + struct dev_pm_qos_request qos_req;
>> +};
>> +
>> +static
Re: [RFC PATCH v5 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
Hi Chanwoo,
On 31.05.2020 02:01, Chanwoo Choi wrote:
> On Sat, May 30, 2020 at 1:32 AM Sylwester Nawrocki
> wrote:
>>
>> Add documentation for new optional properties in the exynos bus nodes:
>> samsung,interconnect-parent, #interconnect-cells.
>> These properties allow to specify the SoC interconnect structure which
>> then allows the interconnect consumer devices to request specific
>> bandwidth requirements.
>>
>> Signed-off-by: Artur Świgoń
>> Signed-off-by: Sylwester Nawrocki
>> ---
>> Changes for v5:
>> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
>> ---
>> Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15
>> +--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index e71f752..e0d2daa 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -51,6 +51,11 @@ Optional properties only for parent bus device:
>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count against total cycle count.
>>
>> +Optional properties for interconnect functionality (QoS frequency
>> constraints):
>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>> + passive devices should point to same node as the exynos,parent-bus
>> property.
>> +- #interconnect-cells: should be 0
>> +
>> Detailed correlation between sub-blocks and power line according to Exynos
>> SoC:
>> - In case of Exynos3250, there are two power line as following:
>> VDD_MIF |--- DMC
>> @@ -185,8 +190,9 @@ Example1:
>> --
>>
>> Example2 :
>> - The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>> - is listed below:
>> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>> is
>> + listed below. An interconnect path "bus_lcd0 -- bus_leftbus --
>> bus_dmc"
>> + is defined for demonstration purposes.
>>
>> bus_dmc: bus_dmc {
>> compatible = "samsung,exynos-bus";
>> @@ -376,12 +382,15 @@ Example2 :
>> _dmc {
>> devfreq-events = <_dmc0_3>, <_dmc1_3>;
>> vdd-supply = <_reg>; /* VDD_MIF */
>> + #interconnect-cells = <0>;
>> status = "okay";
>> };
>>
>> _leftbus {
>> devfreq-events = <_leftbus_3>, <_rightbus_3>;
>> vdd-supply = <_reg>;
>> + samsung,interconnect-parent = <_dmc>;
>> + #interconnect-cells = <0>;
>> status = "okay";
>> };
>>
>> @@ -392,6 +401,8 @@ Example2 :
>>
>> _lcd0 {
>> devfreq = <_leftbus>;
>> + samsung,interconnect-parent = <_leftbus>;
>> + #interconnect-cells = <0>;
>> status = "okay";
>> };
>>
>> --
>> 2.7.4
>>
>
> If you add the usage example like the mixer device of patch5 to this
> dt-binding document,
> I think it is very beneficial and more helpful for user of
> exynos-bus/exynos-generic-icc.
>
> Acked-by: Chanwoo Choi
Thanks for review. I will make sure the example includes a consumer
in next version. Will also mention ../interconnect/interconnect.txt
in description of the #interconnect-cells property.
--
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next-20200515: Xorg killed due to "OOM"
On Sun 31-05-20 14:16:01, Pavel Machek wrote:
> On Thu 2020-05-28 14:07:50, Michal Hocko wrote:
> > On Thu 28-05-20 14:03:54, Pavel Machek wrote:
> > > On Thu 2020-05-28 11:05:17, Michal Hocko wrote:
> > > > On Tue 26-05-20 11:10:54, Pavel Machek wrote:
> > > > [...]
> > > > > [38617.276517] oom_reaper: reaped process 31769 (chromium), now
> > > > > anon-rss:0kB, file-rss:0kB, shmem-rss:7968kB
> > > > > [38617.277232] Xorg invoked oom-killer: gfp_mask=0x0(), order=0,
> > > > > oom_score_adj=0
> > > > > [38617.277247] CPU: 0 PID: 2978 Comm: Xorg Not tainted
> > > > > 5.7.0-rc5-next-20200515+ #117
> > > > > [38617.277256] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
> > > > > (2.19 ) 03/31/2011
> > > > > [38617.277266] Call Trace:
> > > > > [38617.277286] dump_stack+0x54/0x6e
> > > > > [38617.277300] dump_header+0x45/0x321
> > > > > [38617.277313] oom_kill_process.cold+0x9/0xe
> > > > > [38617.277324] ? out_of_memory+0x167/0x420
> > > > > [38617.277336] out_of_memory+0x1f2/0x420
> > > > > [38617.277348] pagefault_out_of_memory+0x34/0x56
> > > > > [38617.277361] mm_fault_error+0x4a/0x130
> > > > > [38617.277372] do_page_fault+0x3ce/0x416
> > > >
> > > > The reason the OOM killer has been invoked is that the page fault
> > > > handler has returned VM_FAULT_OOM. So this is not a result of the page
> > > > allocator struggling to allocate a memory. It would be interesting to
> > > > check which code path has returned this.
> > >
> > > Should the core WARN_ON if that happens and there's enough memory, or
> > > something like that?
> >
> > I wish it would simply go away. There shouldn't be really any reason for
> > VM_FAULT_OOM to exist. The real low on memory situation is already
> > handled in the page allocator.
>
> Umm. Maybe the WARN_ON is first step in that direction? So we can see
> what driver actually did that, and complain to its authors?
This is much harder done than it seems. But maybe this doesn't really
need a full coverage. Some of the code paths which return VM_FAULT_OOM
will simply not fail. But checking for vma->vm_ops->fault() failures
might be interesting. Does the following tell you more about the failure
you can see
diff --git a/mm/memory.c b/mm/memory.c
index 9ab00dcb95d4..5ff023ab7b49 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3442,8 +3442,11 @@ static vm_fault_t __do_fault(struct vm_fault *vmf)
ret = vma->vm_ops->fault(vmf);
if (unlikely(ret & (VM_FAULT_ERROR | VM_FAULT_NOPAGE | VM_FAULT_RETRY |
- VM_FAULT_DONE_COW)))
+ VM_FAULT_DONE_COW))) {
+ if (unlikely(ret & VM_FAULT_OOM))
+ pr_warn("VM_FAULT_OOM returned from %ps\n",
vma->vm_ops->fault);
return ret;
+ }
if (unlikely(PageHWPoison(vmf->page))) {
if (ret & VM_FAULT_LOCKED)
--
Michal Hocko
SUSE Labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
On Fri, 29 May 2020, Philippe CORNU wrote:
Hi Adrian, and thank you very much for the patchset. Thank you
also for having tested it on STM32F769 and STM32MP1. Sorry for
the late response, Yannick and I will review it as soon as
possible and we will keep you posted. Note: Do not hesitate to
put us in copy for the next version (philippe.co...@st.com,
yannick.fer...@st.com) Regards, Philippe :-)
Hi Philippe,
Thank you very much for your previous and future STM testing,
really appreciate it! I've CC'd Yannick until now but I'll also CC
you sure :)
It's been over a month since I posted v8 and I was just gearing up
to address all feedback, rebase & retest to prepare v9 but I'll
wait a little longer, no problem, it's no rush.
Have an awesome day,
Adrian
On 4/27/20 10:19 AM, Adrian Ratiu wrote:
The stm mipi-dsi platform driver added a version test in
commit fa6251a747b7 ("drm/stm: dsi: check hardware version")
so that HW revisions other than v1.3x get rejected. The rockchip
driver had no such check and just assumed register layouts are
v1.3x compatible.
Having such tests was a good idea because only v130/v131 layouts
were supported at the time, however since adding multiple layout
support in the bridge, the version is automatically checked for
all drivers, compatible layouts get picked and unsupported HW is
automatically rejected by the bridge, so there's no use keeping
the test in the stm driver.
The main reason prompting this change is that the stm driver
test immediately disabled the peripheral clock after reading
the version, making the bridge read version 0x0 immediately
after in its own probe(), so we move the clock disabling after
the bridge does the version test.
Tested on STM32F769 and STM32MP1.
Cc: linux-st...@st-md-mailman.stormreply.com
Reported-by: Adrian Pop
Tested-by: Adrian Pop
Tested-by: Arnaud Ferraris
Signed-off-by: Adrian Ratiu
---
New in v6.
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
index 2e1f2664495d0..7218e405d7e2b 100644
--- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
+++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
@@ -402,15 +402,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
*pdev)
goto err_dsi_probe;
}
- dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
- clk_disable_unprepare(pclk);
-
- if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
- ret = -ENODEV;
- DRM_ERROR("bad dsi hardware version\n");
- goto err_dsi_probe;
- }
-
dw_mipi_dsi_stm_plat_data.base = dsi->base;
dw_mipi_dsi_stm_plat_data.priv_data = dsi;
@@ -423,6 +414,9 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
goto err_dsi_probe;
}
+ dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
+ clk_disable_unprepare(pclk);
+
return 0;
err_dsi_probe:
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Dynamically change enumeration list of DRM enumeration property
On Mon, 1 Jun 2020 09:22:27 +0530 Yogish Kulkarni wrote: > Hi, > > For letting DRM clients to select output encoding: > Sink can support certain display timings with high output bit-depths using > multiple output encodings, e.g. sink can support a particular timing with > RGB 10-bit, YCbCr422 10-bit and YCbCr420 10-bit. So DRM client may want to > select YCbCr422 10-bit over RBG 10-bit output to reduce the link bandwidth > (and in turn reduce power/voltage). If DRM driver automatically selects > output encoding then we are restricting DRM clients from making appropriate > choice. Hi, right, that seems to be another reason. > For selectable output color range: > Certain applications (typically graphics) usually rendered in full range > while some applications (typically video) have limited range content. Since > content can change dynamically, DRM driver does not have enough information > to choose correct quantization. Only DRM client can correctly select which > quantization to set (to preserve artist's intent). Now this is an interesting topic for me. As far as I know, there is no window system protocol to tell the display server whether the application provided content is using full or limited range. This means that the display server cannot tell DRM about full vs. limited range either. It also means that when not fullscreen, the display server cannot show the limited range video content correctly, because it would have to be converted to full-range (or vice versa). But why would an application produce limited range pixels anyway? Is it common that hardware video decoders are unable to produce full-range pixels? I am asking, because I have a request to add limited vs. full range information to Wayland. What about video sinks, including monitors? Are there devices that accept limited-range only, full-range only, or switchable? Why not just always use full-range everywhere? Or if a sink supports only limited-range, have the display chip automatically convert from full-range, so that software doesn't have to convert in software. If you actually have a DRM KMS property for the range, does it mean that: - the sink is configured to accept that range, and the pixels in the framebuffer need to comply, or - the display chip converts to that range while framebuffer remains in full-range? If we look at I915 driver's "Broadcast RGB" property, it seems to say to me that the framebuffer is always primarily assumed to be in full-range, and the conversion to limited-range happens in the scanout circuitry. So that property would not help with video content that is already in limited-range. To recap, there are two orthogonal things: application content or framebuffer range, and video sink / monitor range. The display server between the two, at last if it is a Wayland compositor, would be able to convert as necessary. > For how to use selectable output encoding with Weston: > I was thinking that DRM should have separate property to list the encodings > supported by sink and Weston will present this list to its client. Your Not client. A configuration tool perhaps, but not generically to all Wayland clients, not as a directly settable knob at least. > idea to validate encodings using TEST_ONLY commit and present a list of > timings along with encodings supported by particular timing seems better. > Instead of validating all possible encodings, does it make sense to > validate only those supported by sink? Irrespective of this we would Yes, having a list of what the sink actually supports would be nice. As for Wayland clients, there is an extension brewing at https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/8 that would allow suggesting the optimal encoding (pixel format and modifier really) in flight. That said, we are talking about the two different things here: framebuffer format vs. encoding on the wire. Whether making them match has benefits is another matter. > anyway need some mechanism which will allow user to select particular > encoding for a particular mode. I was thinking to allow this using new DRM > property "Encoding". Do you have anything better in mind? I think that is a reasonable and useful goal and idea. Just remember to document it when proposing, even if it seems obvious. The details on how to formulate that into UAPI is up for debate. As said, changing KMS properties after they have been exposed to userspace won't really work from either kernel or userspace point of view. So you'd probably need to expose one blob type property listing the encodings that may work as an array, and another property for setting the one to use. IN_FORMATS property is somewhat similar, although more complicated because it is the combination of format and modifier. > (Since I am using my Gmail Id, I feel I should mention that I work at > Nvidia) Nice to know the source of interest. :-) Thanks, pq > > Thanks, > -Yogish > > On Thu, May 28, 2020 at 6:18 PM Pekka
[PATCH v1 1/6] dt-bindings: panel: add Seiko 70WVW2T 7" panel
Add compatible for Seiko Instruments 7" TFT LCD. This panel is a dumb panel that matches the panel-simple binding. Signed-off-by: Sam Ravnborg Cc: Søren Andersen Cc: Thierry Reding Cc: Sam Ravnborg --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index d6cca1479633..60cc093fbd75 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -239,6 +239,8 @@ properties: - sharp,ls020b1dd01d # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel - shelly,sca07010-bfn-lnn +# Seiko Instruments Inc. 7.0" WVGA (800x480) TFT with Touch-Panel + - sii,70wvw2t # Starry KR070PE2T 7" WVGA TFT LCD panel - starry,kr070pe2t # Starry 12.2" (1920x1200 pixels) TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 5/6] dt-bindings: panel: add LOGIC Technologies panels
Add support for the following panels from LOGIC Technologies, Inc: - LTTD800480070-L2RT - LTTD800480070-L6WH-RT The LTTD800480 L2RT is discontinued, but it may be used in existing products. Both panels are dumb panels that matches the panel-simple binding. Signed-off-by: Sam Ravnborg Cc: Søren Andersen Cc: Thierry Reding Cc: Sam Ravnborg --- .../devicetree/bindings/display/panel/panel-simple.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 6fe0ac86696d..a4910d4af96b 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -183,6 +183,10 @@ properties: - logictechno,lt161010-2nhr # Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod. - logictechno,lt170410-2whc +# LOGIC Technologies Inc. LTTD800480070-L2RT 7" (800x480) TFT LCD panel + - logictechno,lttd800480070-l2rt +# LOGIC Technologies Inc. LTTD800480070-L6WH-RT 7" (800x480) TFT LCD panel + - logictechno,lttd800480070-l6wh-rt # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel - mitsubishi,aa070mc01-ca1 # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 2/6] drm: panel-simple: add Seiko 70WVW2T 7" simple panel
The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
Tested on a proprietary product.
Signed-off-by: Sam Ravnborg
Cc: Søren Andersen
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index b067f66cea0e..8624bb80108c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3194,6 +3194,31 @@ static const struct panel_desc shelly_sca07010_bfn_lnn =
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode sii_70wvw2t_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 256,
+ .hsync_end = 800 + 256 + 0,
+ .htotal = 800 + 256 + 0 + 0,
+ .vdisplay = 480,
+ .vsync_start = 480 + 0,
+ .vsync_end = 480 + 0 + 0,
+ .vtotal = 480 + 0 + 0 + 45,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc sii_70wvw2t = {
+ .modes = _70wvw2t_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode starry_kr070pe2t_mode = {
.clock = 33000,
.hdisplay = 800,
@@ -3877,6 +3902,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "shelly,sca07010-bfn-lnn",
.data = _sca07010_bfn_lnn,
+ }, {
+ .compatible = "sii,70wvw2t",
+ .data = _70wvw2t,
}, {
.compatible = "starry,kr070pe2t",
.data = _kr070pe2t,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 4/6] drm: panel-simple: add Hitachi 3.5" QVGA panel
This panel is used on evaluation boards for Atmel at91sam9261 and
at91sam6263.
Signed-off-by: Sam Ravnborg
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 8624bb80108c..25c96639631f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1813,6 +1813,32 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode hitachi_tx09d71vm1cca_mode = {
+ .clock = 4965000,
+ .hdisplay = 240,
+ .hsync_start = 240 + 0,
+ .hsync_end = 240 + 0 + 5,
+ .htotal = 240 + 0 + 5 + 1,
+ .vdisplay = 320,
+ .vsync_start = 320 + 0,
+ .vsync_end = 320 + 0 + 1,
+ .vtotal = 320 + 0 + 1 + 1,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc hitachi_tx09d71vm1cca = {
+ .modes = _tx09d71vm1cca_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 54,
+ .height = 72,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode hitachi_tx23d38vm0caa_mode = {
.clock = 3,
.hdisplay = 800,
@@ -3737,6 +3763,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "hannstar,hsd100pxn1",
.data = _hsd100pxn1,
+ }, {
+ .compatible = "hit,tx09d71vm1cca",
+ .data = _tx09d71vm1cca,
}, {
.compatible = "hit,tx23d38vm0caa",
.data = _tx23d38vm0caa
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/6] drm: add a few simple panels
Push a few patches that has been sitting in my tree for far too long time. Adds a few more panels to panel-simple, including documentation of the compatible. I have added the last few people that added new panels to panel-simple to the cc list, in the hope to speed up the review process a little. Sam Sam Ravnborg (6): dt-bindings: panel: add Seiko 70WVW2T 7" panel drm: panel-simple: add Seiko 70WVW2T 7" simple panel dt-bindings: panel: add Hitachi 3,5" QVGA panel drm: panel-simple: add Hitachi 3.5" QVGA panel dt-bindings: panel: add LOGIC Technologies panels drm: panel-simple: add LOGIC Technologies panels .../bindings/display/panel/panel-simple.yaml | 8 ++ drivers/gpu/drm/panel/panel-simple.c | 127 + 2 files changed, 135 insertions(+) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 6/6] drm: panel-simple: add LOGIC Technologies panels
Add support for the following panels from LOGIC Technologies, Inc:
- LTTD800480070-L2RT
- LTTD800480070-L6WH-RT
The LTTD800480 L2RT is discontinued, but it may be used
by existing products.
Signed-off-by: Søren Andersen
Signed-off-by: Sam Ravnborg
Cc: Søren Andersen
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 70
1 file changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 25c96639631f..70d54164b1ae 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2428,6 +2428,70 @@ static const struct panel_desc logictechno_lt170410_2whc
= {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode logictechno_lttd800480070_l2rt_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 112,
+ .hsync_end = 800 + 112 + 3,
+ .htotal = 800 + 112 + 3 + 85,
+ .vdisplay = 480,
+ .vsync_start = 480 + 38,
+ .vsync_end = 480 + 38 + 3,
+ .vtotal = 480 + 38 + 3 + 29,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc logictechno_lttd800480070_l2rt = {
+ .modes = _lttd800480070_l2rt_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 45,
+ .enable = 100,
+ .disable = 100,
+ .unprepare = 45
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
+static const struct drm_display_mode logictechno_lttd800480070_l6wh_rt_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 154,
+ .hsync_end = 800 + 154 + 3,
+ .htotal = 800 + 154 + 3 + 43,
+ .vdisplay = 480,
+ .vsync_start = 480 + 47,
+ .vsync_end = 480 + 47 + 3,
+ .vtotal = 480 + 47 + 3 + 20,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc logictechno_lttd800480070_l6wh_rt = {
+ .modes = _lttd800480070_l6wh_rt_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 45,
+ .enable = 100,
+ .disable = 100,
+ .unprepare = 45
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -3841,6 +3905,12 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "logictechno,lt170410-2whc",
.data = _lt170410_2whc,
+ }, {
+ .compatible = "logictechno,lttd800480070-l2rt",
+ .data = _lttd800480070_l2rt,
+ }, {
+ .compatible = "logictechno,lttd800480070-l6wh-rt",
+ .data = _lttd800480070_l6wh_rt,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/6] dt-bindings: panel: add Hitachi 3,5" QVGA panel
This panel is used on evaluation boards for Atmel at91sam9261 and at91sam6263. The panel is named: TX09D71VM1CCA The panel is a dumb panel that matches the panel-simple binding Signed-off-by: Sam Ravnborg Cc: Thierry Reding Cc: Sam Ravnborg --- .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 60cc093fbd75..6fe0ac86696d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -133,6 +133,8 @@ properties: - hannstar,hsd070pww1 # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel - hannstar,hsd100pxn1 +# Hitachi Ltd. Corporation 3,5" QVGA (240x320) TFT LCD panel + - hit,tx09d71vm1cca # Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel - hit,tx23d38vm0caa # InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
Cc: Rob, devicetree ML
On 29.05.2020 18:31, Sylwester Nawrocki wrote:
> Add documentation for new optional properties in the exynos bus nodes:
> samsung,interconnect-parent, #interconnect-cells.
> These properties allow to specify the SoC interconnect structure which
> then allows the interconnect consumer devices to request specific
> bandwidth requirements.
>
> Signed-off-by: Artur Świgoń
> Signed-off-by: Sylwester Nawrocki
> ---
> Changes for v5:
> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
> ---
> Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index e71f752..e0d2daa 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -51,6 +51,11 @@ Optional properties only for parent bus device:
> - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count against total cycle count.
>
> +Optional properties for interconnect functionality (QoS frequency
> constraints):
> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
> + passive devices should point to same node as the exynos,parent-bus
> property.
> +- #interconnect-cells: should be 0
> +
> Detailed correlation between sub-blocks and power line according to Exynos
> SoC:
> - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC
> @@ -185,8 +190,9 @@ Example1:
> --
>
> Example2 :
> - The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> - is listed below:
> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi is
> + listed below. An interconnect path "bus_lcd0 -- bus_leftbus -- bus_dmc"
> + is defined for demonstration purposes.
>
> bus_dmc: bus_dmc {
> compatible = "samsung,exynos-bus";
> @@ -376,12 +382,15 @@ Example2 :
> _dmc {
> devfreq-events = <_dmc0_3>, <_dmc1_3>;
> vdd-supply = <_reg>; /* VDD_MIF */
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> _leftbus {
> devfreq-events = <_leftbus_3>, <_rightbus_3>;
> vdd-supply = <_reg>;
> + samsung,interconnect-parent = <_dmc>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> @@ -392,6 +401,8 @@ Example2 :
>
> _lcd0 {
> devfreq = <_leftbus>;
> + samsung,interconnect-parent = <_leftbus>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> --
> 2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v5 0/6] Exynos: Simple QoS for exynos-bus using interconnect
Cc: Rob, devicetree ML On 29.05.2020 18:31, Sylwester Nawrocki wrote: > This patchset adds interconnect API support for the Exynos SoC "samsung, > exynos-bus" compatible devices, which already have their corresponding > exynos-bus driver in the devfreq subsystem. Complementing the devfreq driver > with an interconnect functionality allows to ensure the QoS requirements > of devices accessing the system memory (e.g. video processing devices) > are fulfilled and to avoid issues like the one discussed in thread [1]. > > This patch series depends on 3 patches from Artur for the interconnect API > [2], which introduce following changes: > > - exporting of_icc_get_from_provider() to avoid hard coding every graph >edge in the DT or driver source, > - relaxing the requirement on #interconnect-cells, so there is no need >to provide dummy node IDs in the DT, > - adding new field in struct icc_provider to explicitly allow configuring >node pairs from two different providers. > > This series adds implementation of interconnect provider per each "samsung, > exynos-bus" compatible DT node, with one interconnect node per provider. > The interconnect code which was previously added as a part of the devfreq > driver has been converted to a separate platform driver. In the devfreq > a corresponding virtual child platform device is registered. Integration > of devfreq and interconnect frameworks is achieved through the PM QoS API. > > A sample interconnect consumer for exynos-mixer is added in patches 5/6, > 6/6, it is currently added only for exynos4412 and allows to address the > mixer DMA underrun error issues [1]. > > The series has been tested on Odroid U3 board. It is based on icc-next > branch with devfreq-next branch merged and patches [2] applied. > > -- > Regards, > Sylwester > > -- > Changes since v3 [3] (v4 skipped to align with patchset [1]), detailed > changes are listed at each patch: > - conversion to a separate interconnect (platform) driver, > - an update of the DT binding documenting new optional properties: >#interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus" >nodes, > - new DT properties added to the SoC, rather than to the board specific >files. > > Changes since v2 [5]: > - Use icc_std_aggregate(). > - Implement a different modification of apply_constraints() in >drivers/interconnect/core.c (patch 03). > - Use 'exynos,interconnect-parent-node' in the DT instead of >'devfreq'/'parent', depending on the bus. > - Rebase on DT patches that deprecate the 'devfreq' DT property. > - Improve error handling, including freeing generated IDs on failure. > - Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent(). > > Changes since v1 [4]: > - Rebase on coupled regulators patches. > - Use dev_pm_qos_*() API instead of overriding frequency in >exynos_bus_target(). > - Use IDR for node ID allocation. > - Reverse order of multiplication and division in >mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow. > > > References: > [1] https://patchwork.kernel.org/patch/10861757/ (original issue) > [2] https://www.spinics.net/lists/linux-samsung-soc/msg70014.html > [3] > https://lore.kernel.org/linux-pm/20191220115653.6487-1-a.swi...@samsung.com > [4] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC) > [5] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC) > > > Artur Świgoń (1): > ARM: dts: exynos: Add interconnects to Exynos4412 mixer > > Marek Szyprowski (1): > drm: exynos: mixer: Add interconnect support > > Sylwester Nawrocki (4): > dt-bindings: exynos-bus: Add documentation for interconnect properties > interconnect: Add generic interconnect driver for Exynos SoCs > PM / devfreq: exynos-bus: Add registration of interconnect child > device > ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes > > .../devicetree/bindings/devfreq/exynos-bus.txt | 15 +- > arch/arm/boot/dts/exynos4412.dtsi | 6 + > drivers/devfreq/exynos-bus.c | 17 ++ > drivers/gpu/drm/exynos/exynos_mixer.c | 73 +++- > drivers/interconnect/Kconfig | 1 + > drivers/interconnect/Makefile | 1 + > drivers/interconnect/exynos/Kconfig| 6 + > drivers/interconnect/exynos/Makefile | 4 + > drivers/interconnect/exynos/exynos.c | 185 > + > 9 files changed, 301 insertions(+), 7 deletions(-) > create mode 100644 drivers/interconnect/exynos/Kconfig > create mode 100644 drivers/interconnect/exynos/Makefile > create mode 100644 drivers/interconnect/exynos/exynos.c ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: Properly propagate return value in drm_iommu_attach_device()
20. 5. 22. 오후 3:03에 Marek Szyprowski 이(가) 쓴 글:
> Propagate the proper error codes from the called functions instead of
> unconditionally returning 0.
>
Picked it up.
Thanks,
Inki Dae
> Reported-by: kbuild test robot
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_dma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dma.c
> b/drivers/gpu/drm/exynos/exynos_drm_dma.c
> index d3fe6c1e6688..5887f7f52f96 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dma.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dma.c
> @@ -44,7 +44,7 @@ static int drm_iommu_attach_device(struct drm_device
> *drm_dev,
> struct device *subdrv_dev, void **dma_priv)
> {
> struct exynos_drm_private *priv = drm_dev->dev_private;
> - int ret;
> + int ret = 0;
>
> if (get_dma_ops(priv->dma_dev) != get_dma_ops(subdrv_dev)) {
> DRM_DEV_ERROR(subdrv_dev, "Device %s lacks support for IOMMU\n",
> @@ -69,7 +69,7 @@ static int drm_iommu_attach_device(struct drm_device
> *drm_dev,
> ret = iommu_attach_device(priv->mapping, subdrv_dev);
> }
>
> - return 0;
> + return ret;
> }
>
> /*
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm/exynos: Remove dev_err() on platform_get_irq() failure
20. 5. 21. 오후 11:22에 Tamseel Shams 이(가) 쓴 글:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.
Picked it up.
Thanks,
Inki Dae
>
> Signed-off-by: Tamseel Shams
> ---
> - Changes since v2:
> * Addressed Inki Dae comments
>
> drivers/gpu/drm/exynos/exynos_drm_g2d.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index fcee33a43aca..03be31427181 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -1498,7 +1498,6 @@ static int g2d_probe(struct platform_device *pdev)
>
> g2d->irq = platform_get_irq(pdev, 0);
> if (g2d->irq < 0) {
> - dev_err(dev, "failed to get irq\n");
> ret = g2d->irq;
> goto err_put_clk;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] nouveau-fixes 5.8
Just two fixes here, one for HDMI2 modesetting failures, another for a race with the audio driver. Thanks, Ben. The following changes since commit dc455f4c888365595c0a13da445e092422d55b8d: drm/nouveau/dispnv50: fix runtime pm imbalance on error (2020-05-22 11:13:53 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.8 for you to fetch changes up to 0ad679d157aa69ddf0ee46b564c9fbb646cf6d4e: drm/nouveau/kms/gt215-: fix race with audio driver runpm (2020-06-01 17:28:42 +1000) Ben Skeggs (2): drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection drm/nouveau/kms/gt215-: fix race with audio driver runpm drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- drivers/gpu/drm/nouveau/nouveau_encoder.h| 1 + drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 4 ++-- 3 files changed, 6 insertions(+), 3 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/13] backlight: remove the unused backlight_bl driver
The backlight_bl driver required initialization using
struct generic_bl_info. As there are no more references
to this struct there is no users left.
So it is safe to delete the driver.
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/Kconfig | 8 --
drivers/video/backlight/Makefile | 1 -
drivers/video/backlight/generic_bl.c | 110 ---
include/linux/backlight.h| 9 ---
4 files changed, 128 deletions(-)
delete mode 100644 drivers/video/backlight/generic_bl.c
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 7d22d7377606..14abfeee8868 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -173,14 +173,6 @@ config BACKLIGHT_EP93XX
To compile this driver as a module, choose M here: the module will
be called ep93xx_bl.
-config BACKLIGHT_GENERIC
- tristate "Generic (aka Sharp Corgi) Backlight Driver"
- default y
- help
- Say y to enable the generic platform backlight driver previously
- known as the Corgi backlight driver. If you have a Sharp Zaurus
- SL-C7xx, SL-Cxx00 or SL-6000x say y.
-
config BACKLIGHT_IPAQ_MICRO
tristate "iPAQ microcontroller backlight driver"
depends on MFD_IPAQ_MICRO
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 0c1a1524627a..9b998cfdc56d 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -31,7 +31,6 @@ obj-$(CONFIG_BACKLIGHT_CLASS_DEVICE) += backlight.o
obj-$(CONFIG_BACKLIGHT_DA903X) += da903x_bl.o
obj-$(CONFIG_BACKLIGHT_DA9052) += da9052_bl.o
obj-$(CONFIG_BACKLIGHT_EP93XX) += ep93xx_bl.o
-obj-$(CONFIG_BACKLIGHT_GENERIC)+= generic_bl.o
obj-$(CONFIG_BACKLIGHT_GPIO) += gpio_backlight.o
obj-$(CONFIG_BACKLIGHT_HP680) += hp680_bl.o
obj-$(CONFIG_BACKLIGHT_HP700) += jornada720_bl.o
diff --git a/drivers/video/backlight/generic_bl.c
b/drivers/video/backlight/generic_bl.c
deleted file mode 100644
index 8fe63dbc8590..
--- a/drivers/video/backlight/generic_bl.c
+++ /dev/null
@@ -1,110 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Generic Backlight Driver
- *
- * Copyright (c) 2004-2008 Richard Purdie
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static int genericbl_intensity;
-static struct backlight_device *generic_backlight_device;
-static struct generic_bl_info *bl_machinfo;
-
-static int genericbl_send_intensity(struct backlight_device *bd)
-{
- int intensity = bd->props.brightness;
-
- if (bd->props.power != FB_BLANK_UNBLANK)
- intensity = 0;
- if (bd->props.state & BL_CORE_FBBLANK)
- intensity = 0;
- if (bd->props.state & BL_CORE_SUSPENDED)
- intensity = 0;
-
- bl_machinfo->set_bl_intensity(intensity);
-
- genericbl_intensity = intensity;
-
- if (bl_machinfo->kick_battery)
- bl_machinfo->kick_battery();
-
- return 0;
-}
-
-static int genericbl_get_intensity(struct backlight_device *bd)
-{
- return genericbl_intensity;
-}
-
-static const struct backlight_ops genericbl_ops = {
- .options = BL_CORE_SUSPENDRESUME,
- .get_brightness = genericbl_get_intensity,
- .update_status = genericbl_send_intensity,
-};
-
-static int genericbl_probe(struct platform_device *pdev)
-{
- struct backlight_properties props;
- struct generic_bl_info *machinfo = dev_get_platdata(>dev);
- const char *name = "generic-bl";
- struct backlight_device *bd;
-
- bl_machinfo = machinfo;
- if (!machinfo->limit_mask)
- machinfo->limit_mask = -1;
-
- if (machinfo->name)
- name = machinfo->name;
-
- memset(, 0, sizeof(struct backlight_properties));
- props.type = BACKLIGHT_RAW;
- props.max_brightness = machinfo->max_intensity;
- bd = devm_backlight_device_register(>dev, name, >dev,
- NULL, _ops, );
- if (IS_ERR(bd))
- return PTR_ERR(bd);
-
- platform_set_drvdata(pdev, bd);
-
- bd->props.power = FB_BLANK_UNBLANK;
- bd->props.brightness = machinfo->default_intensity;
- backlight_update_status(bd);
-
- generic_backlight_device = bd;
-
- dev_info(>dev, "Generic Backlight Driver Initialized.\n");
- return 0;
-}
-
-static int genericbl_remove(struct platform_device *pdev)
-{
- struct backlight_device *bd = platform_get_drvdata(pdev);
-
- bd->props.power = 0;
- bd->props.brightness = 0;
- backlight_update_status(bd);
-
- dev_info(>dev, "Generic Backlight Driver Unloaded\n");
- return 0;
-}
-
-static struct platform_driver genericbl_driver = {
- .probe =
[PATCH v3 10/13] backlight: add overview and update existing doc
Add overview chapter to backlight.c.
Update existing kernel-doc to follow a more consistent
style and drop kernel-doc for deprecated functions.
v2:
- Sevaral editorial corrections that makes reading
much easier (Daniel)
- Spelling fixes (Daniel)
- updated intro chapter with a little more info
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 131 +++-
1 file changed, 90 insertions(+), 41 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 17f04cff50ab..06bcddd76a7e 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -22,6 +22,46 @@
#include
#endif
+/**
+ * DOC: overview
+ *
+ * The backlight core supports implementing backlight drivers.
+ *
+ * A backlight driver registers a driver using
+ * devm_backlight_device_register(). The properties of the backlight
+ * driver such as type and max_brightness must be specified.
+ * When the core detect changes in for example brightness or power state
+ * the update_status() operation is called. The backlight driver shall
+ * implement this operation and use it to adjust backlight.
+ *
+ * Several sysfs attributes are provided by the backlight core::
+ *
+ * - brightness R/W, set the requested brightness level
+ * - actual_brighness RO, the brightness level used by the HW
+ * - max_brightness RO, the maximum brightness level supported
+ *
+ * See Documentation/ABI/stable/sysfs-class-backlight for the full list.
+ *
+ * The backlight can be adjusted using the sysfs interface, and
+ * the backlight driver may also support adjusting backlight using
+ * a hot-key or some other platfrom or firmware specific way.
+ *
+ * The driver shall implement the get_brightness() operation if
+ * the HW do not support all the levels that can be specified in
+ * brightness, thus providing user-space access to the actual level
+ * via the actual_brightness attribute.
+ * When the backlight changes this is reported to user-space using
+ * an uevent connected to the actual_brightness attribute.
+ * When brightness is set by platform specific means, for example
+ * a hot-key to adjust backlight, the driver must notify the backlight
+ * core that brightness has changed using backlight_force_update().
+ *
+ * The backlight driver core receives notifications from fbdev and
+ * if the event is FB_EVENT_BLANK and if the value of blank, from the
+ * FBIOBLANK ioclt, results in a change in the backlight state the
+ * update_status() operation is called.
+ */
+
static struct list_head backlight_dev_list;
static struct mutex backlight_dev_list_mutex;
static struct blocking_notifier_head backlight_notifier;
@@ -40,9 +80,17 @@ static const char *const backlight_scale_types[] = {
#if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE) && \
defined(CONFIG_BACKLIGHT_CLASS_DEVICE_MODULE))
-/* This callback gets called when something important happens inside a
- * framebuffer driver. We're looking if that important event is blanking,
- * and if it is and necessary, we're switching backlight power as well ...
+/*
+ * fb_notifier_callback
+ *
+ * This callback gets called when something important happens inside a
+ * framebuffer driver. The backlight core only cares about FB_BLANK_UNBLANK
+ * which is reported to the driver using backlight_update_status()
+ * as a state change.
+ *
+ * There may be several fbdev's connected to the backlight device,
+ * in which case they are kept track of. A state change is only reported
+ * if there is a change in backlight for the specified fbdev.
*/
static int fb_notifier_callback(struct notifier_block *self,
unsigned long event, void *data)
@@ -318,12 +366,15 @@ static struct attribute *bl_device_attrs[] = {
ATTRIBUTE_GROUPS(bl_device);
/**
- * backlight_force_update - tell the backlight subsystem that hardware state
- * has changed
+ * backlight_force_update - force an update due to a hardware change
* @bd: the backlight device to update
+ * @reason: the method used for the backlight update
*
* Updates the internal state of the backlight in response to a hardware event,
- * and generate a uevent to notify userspace
+ * and generates an uevent to notify userspace. A backlight driver shall call
+ * backlight_force_update() when the backlight is changed using, for example,
+ * a hot-key. The updated brightness is read using get_brightness() and the
+ * brightness value is reported using an uevent.
*/
void backlight_force_update(struct backlight_device *bd,
enum backlight_update_reason reason)
@@ -336,19 +387,7 @@ void backlight_force_update(struct backlight_device *bd,
}
EXPORT_SYMBOL(backlight_force_update);
-/**
- * backlight_device_register - create and register a new object of
- * backlight_device class.
- * @name: the name of the
[PATCH v3 11/13] backlight: wire up kernel-doc documentation
Include backlight so the documentation is now generated with make htmldocs and friends. Signed-off-by: Sam Ravnborg Reviewed-by: Daniel Thompson Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: Jonathan Corbet --- Documentation/gpu/backlight.rst | 12 Documentation/gpu/index.rst | 1 + 2 files changed, 13 insertions(+) create mode 100644 Documentation/gpu/backlight.rst diff --git a/Documentation/gpu/backlight.rst b/Documentation/gpu/backlight.rst new file mode 100644 index ..9ebfc9d0aced --- /dev/null +++ b/Documentation/gpu/backlight.rst @@ -0,0 +1,12 @@ += +Backlight support += + +.. kernel-doc:: drivers/video/backlight/backlight.c + :doc: overview + +.. kernel-doc:: include/linux/backlight.h + :internal: + +.. kernel-doc:: drivers/video/backlight/backlight.c + :export: diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 1fcf8e851e15..c9a51e3bfb5a 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -12,6 +12,7 @@ Linux GPU Driver Developer's Guide drm-uapi drm-client drivers + backlight vga-switcheroo vgaarbiter todo -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/13] backlight: drop extern from prototypes
No need to put "extern" in front of prototypes. While touching the prototypes adjust indent to follow the kernel style. Signed-off-by: Sam Ravnborg Reviewed-by: Daniel Thompson Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han --- include/linux/backlight.h | 35 +++ 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/include/linux/backlight.h b/include/linux/backlight.h index 6bd981a600ef..25a3aac89618 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -417,22 +417,25 @@ static inline bool backlight_is_blank(struct backlight_device *bd) 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); -extern struct backlight_device *devm_backlight_device_register( - struct device *dev, const char *name, struct device *parent, - void *devdata, const struct backlight_ops *ops, - const struct backlight_properties *props); -extern void backlight_device_unregister(struct backlight_device *bd); -extern void devm_backlight_device_unregister(struct device *dev, - struct backlight_device *bd); -extern void backlight_force_update(struct backlight_device *bd, - enum backlight_update_reason reason); -extern int backlight_register_notifier(struct notifier_block *nb); -extern int backlight_unregister_notifier(struct notifier_block *nb); -extern struct backlight_device *backlight_device_get_by_type(enum backlight_type type); -extern int backlight_device_set_brightness(struct backlight_device *bd, unsigned long brightness); +struct backlight_device * +backlight_device_register(const char *name, struct device *dev, void *devdata, + const struct backlight_ops *ops, + const struct backlight_properties *props); +struct backlight_device * +devm_backlight_device_register(struct device *dev, const char *name, + struct device *parent, void *devdata, + const struct backlight_ops *ops, + const struct backlight_properties *props); +void backlight_device_unregister(struct backlight_device *bd); +void devm_backlight_device_unregister(struct device *dev, + struct backlight_device *bd); +void backlight_force_update(struct backlight_device *bd, + enum backlight_update_reason reason); +int backlight_register_notifier(struct notifier_block *nb); +int backlight_unregister_notifier(struct notifier_block *nb); +struct backlight_device *backlight_device_get_by_type(enum backlight_type type); +int backlight_device_set_brightness(struct backlight_device *bd, + unsigned long brightness); #define to_backlight_device(obj) container_of(obj, struct backlight_device, dev) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/13] backlight: improve backlight_ops documentation
Improve the documentation for backlight_ops and
adapt it to kernel-doc style.
v2:
- Add intro for each field (Daniel)
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 59 +++
1 file changed, 53 insertions(+), 6 deletions(-)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index a0a083b35c47..b6c1ab6c922a 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -55,19 +55,66 @@ enum backlight_scale {
struct backlight_device;
struct fb_info;
+/**
+ * struct backlight_ops - backlight operations
+ *
+ * The backlight operations are specifed when the backlight device is
registered.
+ */
struct backlight_ops {
+ /**
+* @options: Configure how operations are called from the core.
+*
+* The options parameter is used to adjust the behaviour of the core.
+* Set BL_CORE_SUSPENDRESUME to get the update_status() operation called
+* upon suspend and resume.
+*/
unsigned int options;
#define BL_CORE_SUSPENDRESUME (1 << 0)
- /* Notify the backlight driver some property has changed */
+ /**
+* @update_status: Operation called when properties have changed.
+*
+* Notify the backlight driver some property has changed.
+* The update_status operation is protected by the update_lock.
+*
+* The backlight driver is expected to use backlight_is_blank()
+* to check if the display is blanked and set brightness accordingly.
+* update_status() is called when any of the properties has changed.
+*
+* RETURNS:
+*
+* 0 on sucees, negative error code if any failure occured.
+*/
int (*update_status)(struct backlight_device *);
- /* Return the current backlight brightness (accounting for power,
- fb_blank etc.) */
+
+ /**
+* @get_brightness: Return the current backlight brightness.
+*
+* The driver may implement this as a readback from the HW.
+* This operation is optional and if not present then the current
+* brightness property value is used.
+*
+* RETURNS:
+*
+* A brightness value which is 0 or a positive numer.
+* On failure a negative error code is returned.
+*/
int (*get_brightness)(struct backlight_device *);
- /* Check if given framebuffer device is the one bound to this backlight;
- return 0 if not, !=0 if it is. If NULL, backlight always matches the
fb. */
- int (*check_fb)(struct backlight_device *, struct fb_info *);
+
+ /**
+* @check_fb: Check the framebuffer device.
+*
+* Check if given framebuffer device is the one bound to this backlight.
+* This operation is optional and if not implemented it is assumed that
the
+* fbdev is always the one bound to the backlight.
+*
+* RETURNS:
+*
+* If info is NULL or the info matches the fbdev bound to the backlight
return true.
+* If info does not match the fbdev bound to the backlight return false.
+*/
+ int (*check_fb)(struct backlight_device *bd, struct fb_info *info);
};
/* This structure defines all the properties of a backlight */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/16] backlight updates
v3: - Dropped video patch that was reviewd and thus applied - Updated kernel-doc so all fields now have a short intro - Improved readability in a lot of places, thanks to review feedback from Daniel - thanks! - Added better intro to backlight - Added acks Several other smaller changes documented in the patches. I left out patches to make functions static as there are dependencies to drm-misc-next for these. When this is landed I have a pile of follow-up patches waiting, mostly introducing backlight_is_blank() all over. v2: - Dropped drm patches that was reviewed and thus applied (Thanks Tomi) - Updated backligth_is_blank() based on Daniel's feedback - Dropped EXPORT_SYMBOL that was no longer relevant - Reordered patches, so patches with no external dependencies comes first - Updated the description that follows. This following series touches a lot of backlight things. Starts with a small refactoring in backligth.c to remove some indents. This increases the readability and no functional changes. Then a new helper backlight_is_blank() is added. This helper will simplify the implementation of update_status() in almost all backlight drivers. Then while surfing the code I missed some documentation. So I got a bit carried away and updated the documentation for the backlight core and added it to kernel-doc. The documentation express my current understanding. Everything from spelling errors to outright wrong content shall be anticipated - so please review! We are all best helped if the documentation is correct and up-to-date and it is readable. In this process I identified that the backlight_bl driver was no longer in use - so drop it. Everything builds, but so far no run-time testing. Sam Sam Ravnborg (13): backlight: refactor fb_notifier_callback() backlight: add backlight_is_blank() backlight: improve backlight_ops documentation backlight: improve backlight_properties documentation backlight: improve backlight_device documentation backlight: document inline functions in backlight.h backlight: document enums in backlight.h backlight: remove the unused backlight_bl driver backlight: drop extern from prototypes backlight: add overview and update existing doc backlight: wire up kernel-doc documentation backlight: as3711_bl: introduce backlight_is_blank() backlight: use backlight_is_blank() in all backlight drivers Documentation/gpu/backlight.rst | 12 + Documentation/gpu/index.rst | 1 + drivers/video/backlight/88pm860x_bl.c| 8 +- drivers/video/backlight/Kconfig | 8 - drivers/video/backlight/Makefile | 1 - drivers/video/backlight/adp5520_bl.c | 5 +- drivers/video/backlight/adp8860_bl.c | 5 +- drivers/video/backlight/adp8870_bl.c | 5 +- drivers/video/backlight/as3711_bl.c | 8 +- drivers/video/backlight/backlight.c | 174 +- drivers/video/backlight/bd6107.c | 4 +- drivers/video/backlight/corgi_lcd.c | 5 +- drivers/video/backlight/cr_bllcd.c | 22 +- drivers/video/backlight/da903x_bl.c | 8 +- drivers/video/backlight/ep93xx_bl.c | 3 +- drivers/video/backlight/generic_bl.c | 110 - drivers/video/backlight/gpio_backlight.c | 4 +- drivers/video/backlight/hp680_bl.c | 4 +- drivers/video/backlight/jornada720_bl.c | 2 +- drivers/video/backlight/kb3886_bl.c | 4 +- drivers/video/backlight/led_bl.c | 4 +- drivers/video/backlight/lm3533_bl.c | 4 +- drivers/video/backlight/locomolcd.c | 4 +- drivers/video/backlight/lv5207lp.c | 4 +- drivers/video/backlight/max8925_bl.c | 8 +- drivers/video/backlight/pwm_bl.c | 4 +- drivers/video/backlight/qcom-wled.c | 4 +- drivers/video/backlight/tps65217_bl.c| 4 +- drivers/video/backlight/wm831x_bl.c | 8 +- include/linux/backlight.h| 374 +-- 30 files changed, 465 insertions(+), 346 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 05/13] backlight: improve backlight_device documentation
Improve the documentation for backlight_device and
adapt it to kernel-doc style.
v2:
- Add short intro to all fields (Daniel)
- Updated description of update_lock (Daniel)
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 72 ++-
1 file changed, 49 insertions(+), 23 deletions(-)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 69a20da03035..cae1af95dd9d 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -14,21 +14,6 @@
#include
#include
-/* Notes on locking:
- *
- * backlight_device->ops_lock is an internal backlight lock protecting the
- * ops pointer and no code outside the core should need to touch it.
- *
- * Access to update_status() is serialised by the update_lock mutex since
- * most drivers seem to need this and historically get it wrong.
- *
- * Most drivers don't need locking on their get_brightness() method.
- * If yours does, you need to implement it in the driver. You can use the
- * update_lock mutex if appropriate.
- *
- * Any other use of the locks below is probably wrong.
- */
-
enum backlight_update_reason {
BACKLIGHT_UPDATE_HOTKEY,
BACKLIGHT_UPDATE_SYSFS,
@@ -215,30 +200,71 @@ struct backlight_properties {
enum backlight_scale scale;
};
+/**
+ * struct backlight_device - backlight device data
+ *
+ * This structure holds all data required by a backlight device.
+ */
struct backlight_device {
- /* Backlight properties */
+ /**
+* @props: Backlight properties
+*/
struct backlight_properties props;
- /* Serialise access to update_status method */
+ /**
+* @update_lock: The lock used when calling the update_status()
operation.
+*
+* update_lock is an internal backlight lock that serialise access
+* to the update_status() operation. The backlight core holds the
update_lock
+* when calling the update_status() operation. The update_lock shall not
+* be used by backlight drivers.
+*/
struct mutex update_lock;
- /* This protects the 'ops' field. If 'ops' is NULL, the driver that
- registered this device has been unloaded, and if class_get_devdata()
- points to something in the body of that driver, it is also invalid.
*/
+ /**
+* @ops_lock: The lock used around everything related to backlight_ops.
+*
+* ops_lock is an internal backlight lock that protects the ops pointer
+* and is used around all accesses to ops and when the operations are
+* invoked. The ops_lock shall not be used by backlight drivers.
+*/
struct mutex ops_lock;
+
+ /**
+* @ops: Pointer to the backlight operations.
+*
+* If ops is NULL, the driver that registered this device has been
unloaded,
+* and if class_get_devdata() points to something in the body of that
driver,
+* it is also invalid.
+*/
const struct backlight_ops *ops;
- /* The framebuffer notifier block */
+ /**
+* @fb_notif: The framebuffer notifier block
+*/
struct notifier_block fb_notif;
- /* list entry of all registered backlight devices */
+ /**
+* @entry: List entry of all registered backlight devices
+*/
struct list_head entry;
+ /**
+* @dev: Parent device.
+*/
struct device dev;
- /* Multiple framebuffers may share one backlight device */
+ /**
+* @fb_bl_on: The state of individual fbdev's.
+*
+* Multiple fbdev's may share one backlight device. The fb_bl_on
+* records the state of the individual fbdev.
+*/
bool fb_bl_on[FB_MAX];
+ /**
+* @use_count: The number of uses of fb_bl_on.
+*/
int use_count;
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/13] backlight: as3711_bl: introduce backlight_is_blank()
Replaces the open-coded checks of the state, with the
backlight_is_blank() helper. This increases readability
of the code and aling the functionality across the drivers.
Futhermore drop the debug prints in update_status().
If we need debug printing then we can add it to the backlight core.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Emil Velikov
---
drivers/video/backlight/as3711_bl.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/video/backlight/as3711_bl.c
b/drivers/video/backlight/as3711_bl.c
index 33f0f0f2e8b3..cc5628beaffd 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -107,13 +107,7 @@ static int as3711_bl_update_status(struct backlight_device
*bl)
int brightness = bl->props.brightness;
int ret = 0;
- dev_dbg(>dev, "%s(): brightness %u, pwr %x, blank %x, state %x\n",
- __func__, bl->props.brightness, bl->props.power,
- bl->props.fb_blank, bl->props.state);
-
- if (bl->props.power != FB_BLANK_UNBLANK ||
- bl->props.fb_blank != FB_BLANK_UNBLANK ||
- bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ if (backlight_is_blank(bl))
brightness = 0;
if (data->type == AS3711_BL_SU1) {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/13] backlight: document inline functions in backlight.h
Add documentation for the inline functions in backlight.h
v2:
- Fix spelling (Daniel)
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index cae1af95dd9d..f99ca19cc3ec 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -268,6 +268,10 @@ struct backlight_device {
int use_count;
};
+/**
+ * backlight_update_status - force an update of the backlight device status
+ * @bd: the backlight device
+ */
static inline int backlight_update_status(struct backlight_device *bd)
{
int ret = -ENOENT;
@@ -360,6 +364,18 @@ extern int backlight_device_set_brightness(struct
backlight_device *bd, unsigned
#define to_backlight_device(obj) container_of(obj, struct backlight_device,
dev)
+/**
+ * bl_get_data - access devdata
+ * @bl_dev: pointer to backlight device
+ *
+ * When a backlight device is registered the driver has the possibility
+ * to supply a void * devdata. bl_get_data() return a pointer to the
+ * devdata.
+ *
+ * RETURNS:
+ *
+ * pointer to devdata stored while registering the backlight device.
+ */
static inline void * bl_get_data(struct backlight_device *bl_dev)
{
return dev_get_drvdata(_dev->dev);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/13] backlight: refactor fb_notifier_callback()
Increase readability of fb_notifier_callback() by removing
a few indent levels.
No functional change.
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 43 +++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index cac3e35d7630..17f04cff50ab 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -58,28 +58,29 @@ static int fb_notifier_callback(struct notifier_block *self,
bd = container_of(self, struct backlight_device, fb_notif);
mutex_lock(>ops_lock);
- if (bd->ops)
- if (!bd->ops->check_fb ||
- bd->ops->check_fb(bd, evdata->info)) {
- fb_blank = *(int *)evdata->data;
- if (fb_blank == FB_BLANK_UNBLANK &&
- !bd->fb_bl_on[node]) {
- bd->fb_bl_on[node] = true;
- if (!bd->use_count++) {
- bd->props.state &= ~BL_CORE_FBBLANK;
- bd->props.fb_blank = FB_BLANK_UNBLANK;
- backlight_update_status(bd);
- }
- } else if (fb_blank != FB_BLANK_UNBLANK &&
- bd->fb_bl_on[node]) {
- bd->fb_bl_on[node] = false;
- if (!(--bd->use_count)) {
- bd->props.state |= BL_CORE_FBBLANK;
- bd->props.fb_blank = fb_blank;
- backlight_update_status(bd);
- }
- }
+
+ if (!bd->ops)
+ goto out;
+ if (bd->ops->check_fb && !bd->ops->check_fb(bd, evdata->info))
+ goto out;
+
+ fb_blank = *(int *)evdata->data;
+ if (fb_blank == FB_BLANK_UNBLANK && !bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = true;
+ if (!bd->use_count++) {
+ bd->props.state &= ~BL_CORE_FBBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ backlight_update_status(bd);
+ }
+ } else if (fb_blank != FB_BLANK_UNBLANK && bd->fb_bl_on[node]) {
+ bd->fb_bl_on[node] = false;
+ if (!(--bd->use_count)) {
+ bd->props.state |= BL_CORE_FBBLANK;
+ bd->props.fb_blank = fb_blank;
+ backlight_update_status(bd);
}
+ }
+out:
mutex_unlock(>ops_lock);
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/13] backlight: use backlight_is_blank() in all backlight drivers
Replaces the open-coded checks of the state etc.,
with the backlight_is_blank() helper.
This increases readability of the code and align
the functionality across the drivers.
v3:
- Dropped as3711_bl, it will be modified in another patch
v2:
- Fixed so changelog is readable
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Michael Hennerich
Cc: Support Opensource
Cc: Thierry Reding
Cc: "Uwe Kleine-König"
Cc: Andy Gross
Cc: Bjorn Andersson
Cc: linux-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: patc...@opensource.cirrus.com
---
drivers/video/backlight/88pm860x_bl.c| 8 +---
drivers/video/backlight/adp5520_bl.c | 5 +
drivers/video/backlight/adp8860_bl.c | 5 +
drivers/video/backlight/adp8870_bl.c | 5 +
drivers/video/backlight/bd6107.c | 4 +---
drivers/video/backlight/corgi_lcd.c | 5 +
drivers/video/backlight/cr_bllcd.c | 22 +++---
drivers/video/backlight/da903x_bl.c | 8 +---
drivers/video/backlight/ep93xx_bl.c | 3 +--
drivers/video/backlight/gpio_backlight.c | 4 +---
drivers/video/backlight/hp680_bl.c | 4 +---
drivers/video/backlight/jornada720_bl.c | 2 +-
drivers/video/backlight/kb3886_bl.c | 4 +---
drivers/video/backlight/led_bl.c | 4 +---
drivers/video/backlight/lm3533_bl.c | 4 +---
drivers/video/backlight/locomolcd.c | 4 +---
drivers/video/backlight/lv5207lp.c | 4 +---
drivers/video/backlight/max8925_bl.c | 8 +---
drivers/video/backlight/pwm_bl.c | 4 +---
drivers/video/backlight/qcom-wled.c | 4 +---
drivers/video/backlight/tps65217_bl.c| 4 +---
drivers/video/backlight/wm831x_bl.c | 8 +---
22 files changed, 28 insertions(+), 95 deletions(-)
diff --git a/drivers/video/backlight/88pm860x_bl.c
b/drivers/video/backlight/88pm860x_bl.c
index 20d96a5ac384..162c83ab0f5a 100644
--- a/drivers/video/backlight/88pm860x_bl.c
+++ b/drivers/video/backlight/88pm860x_bl.c
@@ -123,13 +123,7 @@ 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)
+ if (backlight_is_blank(bl))
brightness = 0;
return pm860x_backlight_set(bl, brightness);
diff --git a/drivers/video/backlight/adp5520_bl.c
b/drivers/video/backlight/adp5520_bl.c
index 0f63f76723a5..d817b0d95c9d 100644
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -67,10 +67,7 @@ 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)
+ if (backlight_is_blank(bl))
brightness = 0;
return adp5520_bl_set(bl, brightness);
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index 19968104fc47..a0ce2a3701fa 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -363,10 +363,7 @@ 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)
+ if (backlight_is_blank(bl))
brightness = 0;
return adp8860_bl_set(bl, brightness);
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 4c0032010cfe..ae4269fdb189 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -401,10 +401,7 @@ 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)
+ if (backlight_is_blank(bl))
brightness = 0;
return adp8870_bl_set(bl, brightness);
diff --git a/drivers/video/backlight/bd6107.c b/drivers/video/backlight/bd6107.c
index d5d5fb457e78..f6a5c1dba3bc 100644
--- a/drivers/video/backlight/bd6107.c
+++ b/drivers/video/backlight/bd6107.c
@@ -84,9 +84,7 @@ static int bd6107_backlight_update_status(struct
backlight_device *backlight)
struct bd6107 *bd = bl_get_data(backlight);
int brightness = backlight->props.brightness;
- if (backlight->props.power != FB_BLANK_UNBLANK ||
- backlight->props.fb_blank != FB_BLANK_UNBLANK ||
- backlight->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ if
[PATCH v3 02/13] backlight: add backlight_is_blank()
The backlight support has two properties that express the state:
- power
- state
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.
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
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 c7d6b2e8c3b5..a0a083b35c47 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(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
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/13] backlight: document enums in backlight.h
Add kernel-doc documentation for the backlight enums
v2:
- Add intro to each enum member (Daniel)
Except backlight type as line lenght was too long.
The generated HTML is the same.
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 74 ++-
1 file changed, 73 insertions(+), 1 deletion(-)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index f99ca19cc3ec..c1c7b1666a9b 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -14,26 +14,98 @@
#include
#include
+/**
+ * enum backlight_update_reason - what method was used to update backlight
+ *
+ * A driver indicates the method (reason) used for updating the backlight
+ * when calling backlight_force_update().
+ */
enum backlight_update_reason {
+ /**
+* @BACKLIGHT_UPDATE_HOTKEY: The backlight was updated using a hot-key.
+*/
BACKLIGHT_UPDATE_HOTKEY,
+
+ /**
+* @BACKLIGHT_UPDATE_SYSFS: The backlight was updated using sysfs.
+*/
BACKLIGHT_UPDATE_SYSFS,
};
+/**
+ * enum backlight_type - the type of backlight control
+ *
+ * The type of interface used to control the backlight.
+ */
enum backlight_type {
+ /**
+* @BACKLIGHT_RAW:
+*
+* The backlight is controlled using hardware registers.
+*/
BACKLIGHT_RAW = 1,
+
+ /**
+* @BACKLIGHT_PLATFORM:
+*
+* The backlight is controlled using a platform-specific interface.
+*/
BACKLIGHT_PLATFORM,
+
+ /**
+* @BACKLIGHT_FIRMWARE:
+*
+* The backlight is controlled using a standard firmware interface.
+*/
BACKLIGHT_FIRMWARE,
+
+ /**
+* @BACKLIGHT_TYPE_MAX: Number of entries.
+*/
BACKLIGHT_TYPE_MAX,
};
+/**
+ * enum backlight_notification - the type of notification
+ *
+ * The notifications that is used for notification sent to the receiver
+ * that registered notifications using backlight_register_notifier().
+ */
enum backlight_notification {
+ /**
+* @BACKLIGHT_REGISTERED: The backlight device is registered.
+*/
BACKLIGHT_REGISTERED,
+
+ /**
+* @BACKLIGHT_UNREGISTERED: The backlight revice is unregistered.
+*/
BACKLIGHT_UNREGISTERED,
};
+/** enum backlight_scale - the type of scale used for brightness values
+ *
+ * The type of scale used for brightness values.
+ */
enum backlight_scale {
+ /**
+* @BACKLIGHT_SCALE_UNKNOWN: The scale is unknown.
+*/
BACKLIGHT_SCALE_UNKNOWN = 0,
+
+ /**
+* @BACKLIGHT_SCALE_LINEAR: The scale is linear.
+*
+* The linear scale will increase brightness the same for each step.
+*/
BACKLIGHT_SCALE_LINEAR,
+
+ /**
+* @BACKLIGHT_SCALE_NON_LINEAR: The scale is not linear.
+*
+* This is often used when the brightness values tries to adjust to
+* the relative perception of the eye demanding a non-linear scale.
+*/
BACKLIGHT_SCALE_NON_LINEAR,
};
@@ -149,7 +221,7 @@ struct backlight_properties {
/**
* @fb_blank: The power state from the FBIOBLANK ioclt.
*
-* When the FBIOBLANK ioctl is called fb_blank is set to the
+* When the FBIOBLANK ioctl is called @fb_blank is set to the
* blank parameter and the update_status() operation is called.
*
* When the backlight device is enabled @fb_blank is set
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/13] backlight: improve backlight_properties documentation
Improve the documentation for backlight_properties and
adapt it to kernel-doc style.
v2:
- Added into for each field (Daniel)
- Re-written some parts to explain what to do, rather
than what not to do.
Partly based on suggestions from the review (Daniel)
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 96 ++-
1 file changed, 85 insertions(+), 11 deletions(-)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index b6c1ab6c922a..69a20da03035 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -117,28 +117,102 @@ struct backlight_ops {
int (*check_fb)(struct backlight_device *bd, struct fb_info *info);
};
-/* This structure defines all the properties of a backlight */
+/**
+ * struct backlight_properties - backlight properties
+ *
+ * This structure defines all the properties of a backlight.
+ */
struct backlight_properties {
- /* Current User requested brightness (0 - max_brightness) */
+ /**
+* @brightness: The current brightness requested by the user.
+*
+* The backlight core makes sure the range is (0 to max_brightness)
+* when the brightness is set via the sysfs attribute:
+* /sys/class/backlight//brightness.
+*
+* This value can be set in the backlight_properties passed
+* to devm_backlight_device_register() to set a default brightness
+* value.
+*/
int brightness;
- /* Maximal value for brightness (read-only) */
+
+ /**
+* @max_brightness: The maximum brightness value.
+*
+* This value must be set in the backlight_properties passed to
+* devm_backlight_device_register() and shall not be modified by the
+* driver after registration.
+*/
int max_brightness;
- /* Current FB Power mode (0: full on, 1..3: power saving
- modes; 4: full off), see FB_BLANK_XXX */
+
+ /**
+* @power: The current power mode.
+*
+* User space can configure the power mode using the sysfs
+* attribute: /sys/class/backlight//bl_power
+* When the power property is updated update_status() is called.
+*
+* The possible values are: (0: full on, 1 to 3: power saving
+* modes; 4: full off), see FB_BLANK_XXX.
+*
+* When the backlight device is enabled @power is set
+* to FB_BLANK_UNBLANK. When the backlight device is disabled
+* @power is set to FB_BLANK_POWERDOWN.
+*/
int power;
- /* FB Blanking active? (values as for power) */
- /* Due to be removed, please use (state & BL_CORE_FBBLANK) */
+
+ /**
+* @fb_blank: The power state from the FBIOBLANK ioclt.
+*
+* When the FBIOBLANK ioctl is called fb_blank is set to the
+* blank parameter and the update_status() operation is called.
+*
+* When the backlight device is enabled @fb_blank is set
+* to FB_BLANK_UNBLANK. When the backlight device is disabled
+* @fb_blank is set to FB_BLANK_POWERDOWN.
+*
+* Backlight drivers should avoid using this property. It has been
+* replaced by state & BL_CORE_FBLANK (although most drivers should
+* use backlight_is_blank() as the preferred means to get the blank
+* state).
+*
+* fb_blank is deprecated and will be removed.
+*/
int fb_blank;
- /* Backlight type */
+
+ /**
+* @type: The type of backlight supported.
+*
+* The backlight type allows userspace to make appropriate
+* policy desicions based on the backlight type.
+*
+* This value must be set in the backlight_properties
+* passed to devm_backlight_device_register().
+*/
enum backlight_type type;
- /* Flags used to signal drivers of state changes */
+
+ /**
+* @state: The state of the backlight core.
+*
+* The state is a bitmask. BL_CORE_FBBLANK is set when the display
+* is expected to be blank. BL_CORE_SUSPENDED is set when the
+* driver is suspended.
+*
+* backlight drivers are excpected to use backlight_is_blank()
+* in their update_status() operation rather than reading the
+* state property.
+*
+* The state is maintained by the core and drivers may not modify it.
+*/
unsigned int state;
- /* Type of the brightness scale (linear, non-linear, ...) */
- enum backlight_scale scale;
#define BL_CORE_SUSPENDED (1 << 0)/* backlight is suspended */
#define BL_CORE_FBBLANK(1 << 1)/* backlight is under
an fb blank event */
+ /**
+* @scale: The type of the brightness scale.
+*/
+ enum backlight_scale scale;
};
[PATCH 7/7] dt-bindings: display: Document Cadence MHDP HDMI/DP bindings
From: Sandor Yu
Document the bindings used for the Cadence MHDP HDMI/DP bridge.
Signed-off-by: Sandor Yu
---
.../bindings/display/bridge/cdns,mhdp.yaml| 46 +++
.../devicetree/bindings/display/imx/mhdp.yaml | 59 +++
2 files changed, 105 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
create mode 100644 Documentation/devicetree/bindings/display/imx/mhdp.yaml
diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
new file mode 100644
index ..aa23feba744a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause))
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/cdns,mhdp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MHDP TX Encoder
+
+maintainers:
+ - Sandor Yu
+
+description: |
+ Cadence MHDP Controller supports one or more of the protocols,
+ such as HDMI and DisplayPort.
+ Each protocol requires a different FW binaries.
+
+ This document defines device tree properties for the Cadence MHDP Encoder
+ (CDNS MHDP TX). It doesn't constitue a device tree binding
+ specification by itself but is meant to be referenced by platform-specific
+ device tree bindings.
+
+ When referenced from platform device tree bindings the properties defined in
+ this document are defined as follows. The platform device tree bindings are
+ responsible for defining whether each property is required or optional.
+
+properties:
+ reg:
+maxItems: 1
+description: Memory mapped base address and length of the MHDP TX
registers.
+
+ interrupts:
+maxItems: 2
+
+ interrupt-names:
+- const: plug_in
+ description: Hotplug detect interrupter for cable plugin event.
+- const: plug_out
+ description: Hotplug detect interrupter for cable plugout event.
+
+ port:
+type: object
+description: |
+ The connectivity of the MHDP TX with the rest of the system is
+ expressed in using ports as specified in the device graph bindings
defined
+ in Documentation/devicetree/bindings/graph.txt. The numbering of the
ports
+ is platform-specific.
diff --git a/Documentation/devicetree/bindings/display/imx/mhdp.yaml
b/Documentation/devicetree/bindings/display/imx/mhdp.yaml
new file mode 100644
index ..17850cfd1cb1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/imx/mhdp.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/mhdp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Cadence MHDP Encoder
+
+maintainers:
+ - Sandor Yu
+
+description: |
+ The MHDP transmitter is a Cadence HD Display TX controller IP
+ with a companion PHY IP.
+ The MHDP supports one or more of the protocols,
+ such as HDMI(1.4 & 2.0), DisplayPort(1.2).
+ switching between the two modes (HDMI and DisplayPort)
+ requires reloading the appropriate FW
+
+ These DT bindings follow the Cadence MHDP TX bindings defined in
+ Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml with the
+ following device-specific properties.
+
+Properties:
+ compatible:
+enum:
+ - nxp,imx8mq-cdns-hdmi
+ - nxp,imx8mq-cdns-dp
+
+ reg: See cdns,mhdp.yaml.
+
+ interrupts: See cdns,mhdp.yaml.
+
+ interrupt-names: See cdns,mhdp.yaml.
+
+ ports: See cdns,mhdp.yaml.
+
+Required:
+ - compatible
+ - reg
+ - interrupts
+ - interrupt-names
+ - ports
+
+Example:
+ - |
+mhdp: mhdp@32c0 {
+ compatible = "nxp,imx8mq-cdns-hdmi";
+ reg = <0x32c0 0x10>;
+ interrupts = ,
+ ;
+ interrupt-names = "plug_in", "plug_out";
+
+ ports {
+mhdp_in: endpoint {
+ remote-endpoint = <_out>;
+};
+ };
+};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm: imx: mhdp: initial support for i.MX8MQ MHDP Displayport
From: Sandor Yu
Initial support for i.MX8MQ MHDP Displayport.
Add MHDP DP PHY configutation.
The features are same as MHDP DP bridge driver.
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/imx/Kconfig | 1 +
drivers/gpu/drm/imx/Makefile| 1 +
drivers/gpu/drm/imx/mhdp/Kconfig| 8 +
drivers/gpu/drm/imx/mhdp/Makefile | 4 +
drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c | 390
drivers/gpu/drm/imx/mhdp/cdns-mhdp-imxdrv.c | 130 +++
drivers/gpu/drm/imx/mhdp/cdns-mhdp-phy.h| 146
7 files changed, 680 insertions(+)
create mode 100644 drivers/gpu/drm/imx/mhdp/Kconfig
create mode 100644 drivers/gpu/drm/imx/mhdp/Makefile
create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c
create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-imxdrv.c
create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-phy.h
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index 6231048aa5aa..4af2f575f04b 100644
--- a/drivers/gpu/drm/imx/Kconfig
+++ b/drivers/gpu/drm/imx/Kconfig
@@ -41,3 +41,4 @@ config DRM_IMX_HDMI
Choose this if you want to use HDMI on i.MX6.
source "drivers/gpu/drm/imx/dcss/Kconfig"
+source "drivers/gpu/drm/imx/mhdp/Kconfig"
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index b644deffe948..0b46c46b19a8 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
obj-$(CONFIG_DRM_IMX_HDMI) += dw_hdmi-imx.o
obj-$(CONFIG_DRM_IMX_DCSS) += dcss/
+obj-$(CONFIG_DRM_IMX_CDNS_MHDP) += mhdp/
diff --git a/drivers/gpu/drm/imx/mhdp/Kconfig b/drivers/gpu/drm/imx/mhdp/Kconfig
new file mode 100644
index ..c9e07a3bf3df
--- /dev/null
+++ b/drivers/gpu/drm/imx/mhdp/Kconfig
@@ -0,0 +1,8 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+config DRM_IMX_CDNS_MHDP
+ tristate "NXP i.MX MX8 DRM DP"
+ select DRM_CDNS_MHDP
+ select DRM_CDNS_DP
+ help
+ Choose this if you want to use Displayport on i.MX8.
diff --git a/drivers/gpu/drm/imx/mhdp/Makefile
b/drivers/gpu/drm/imx/mhdp/Makefile
new file mode 100644
index ..4383e689445a
--- /dev/null
+++ b/drivers/gpu/drm/imx/mhdp/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+cdns_mhdp_imx-objs := cdns-mhdp-imxdrv.o cdns-mhdp-dp-phy.o
+obj-$(CONFIG_DRM_IMX_CDNS_MHDP) += cdns_mhdp_imx.o
diff --git a/drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c
b/drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c
new file mode 100644
index ..bb694301984d
--- /dev/null
+++ b/drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c
@@ -0,0 +1,390 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence Display Port Interface (DP) PHY driver
+ *
+ * Copyright (C) 2019-2020 NXP Semiconductor, Inc.
+ */
+#include
+#include
+#include
+#include
+#include "cdns-mhdp-phy.h"
+
+enum dp_link_rate {
+ RATE_1_6 = 162000,
+ RATE_2_1 = 216000,
+ RATE_2_4 = 243000,
+ RATE_2_7 = 27,
+ RATE_3_2 = 324000,
+ RATE_4_3 = 432000,
+ RATE_5_4 = 54,
+ RATE_8_1 = 81,
+};
+
+struct phy_pll_reg {
+ u16 val[7];
+ u32 addr;
+};
+
+static const struct phy_pll_reg phy_pll_27m_cfg[] = {
+ /* 1.622.162.432.7 3.244.325.4 register
address */
+ {{ 0x010E, 0x010E, 0x010E, 0x010E, 0x010E, 0x010E, 0x010E },
CMN_PLL0_VCOCAL_INIT_TMR },
+ {{ 0x001B, 0x001B, 0x001B, 0x001B, 0x001B, 0x001B, 0x001B },
CMN_PLL0_VCOCAL_ITER_TMR },
+ {{ 0x30B9, 0x3087, 0x3096, 0x30B4, 0x30B9, 0x3087, 0x30B4 },
CMN_PLL0_VCOCAL_START },
+ {{ 0x0077, 0x009F, 0x00B3, 0x00C7, 0x0077, 0x009F, 0x00C7 },
CMN_PLL0_INTDIV },
+ {{ 0xF9DA, 0xF7CD, 0xF6C7, 0xF5C1, 0xF9DA, 0xF7CD, 0xF5C1 },
CMN_PLL0_FRACDIV },
+ {{ 0x001E, 0x0028, 0x002D, 0x0032, 0x001E, 0x0028, 0x0032 },
CMN_PLL0_HIGH_THR },
+ {{ 0x0020, 0x0020, 0x0020, 0x0020, 0x0020, 0x0020, 0x0020 },
CMN_PLL0_DSM_DIAG },
+ {{ 0x, 0x1000, 0x1000, 0x1000, 0x, 0x1000, 0x1000 },
CMN_PLLSM0_USER_DEF_CTRL },
+ {{ 0x, 0x, 0x, 0x, 0x, 0x, 0x },
CMN_DIAG_PLL0_OVRD },
+ {{ 0x, 0x, 0x, 0x, 0x, 0x, 0x },
CMN_DIAG_PLL0_FBH_OVRD },
+ {{ 0x, 0x, 0x, 0x, 0x, 0x, 0x },
CMN_DIAG_PLL0_FBL_OVRD },
+ {{ 0x0006, 0x0007, 0x0007, 0x0007, 0x0006, 0x0007, 0x0007 },
CMN_DIAG_PLL0_V2I_TUNE },
+ {{ 0x0043, 0x0043, 0x0043, 0x0042, 0x0043, 0x0043, 0x0042 },
CMN_DIAG_PLL0_CP_TUNE },
+ {{ 0x0008, 0x0008, 0x0008, 0x0008, 0x0008, 0x0008, 0x0008 },
CMN_DIAG_PLL0_LF_PROG },
+ {{ 0x0100, 0x0001, 0x0001, 0x0001, 0x0100, 0x0001, 0x0001 },
CMN_DIAG_PLL0_PTATIS_TUNE1 },
+ {{ 0x0007, 0x0001, 0x0001, 0x0001, 0x0007, 0x0001, 0x0001 },
CMN_DIAG_PLL0_PTATIS_TUNE2 },
+ {{ 0x0020, 0x0020, 0x0020, 0x0020, 0x0020, 0x0020, 0x0020 },
CMN_DIAG_PLL0_TEST_MODE},
+ {{
[PATCH 0/7] Initial support for Cadence MHDP(HDMI/DP)
From: Sandor Yu The patch set initial support for Cadence MHDP(HDMI/DP) drm bridge driver and iMX8MQ HDMI/DP. The first patch drm/rockchip: prepare common code for cdns and rk dpi/dp driver is from the link https://patchwork.kernel.org/patch/10788309/ that still in reviewing. Files in drm/bridge/cadence compose with serveral parties, drm bridge driver, Audio and API functions. -cdns-dp-core.c: Displayport bridge driver -cdns-hdmi-core.c: HDMI bridge driver -cdns-mhdp-audio.c: DP/HDMI Audio -cdns-mhdp-common.c: MHDP common API functions -cdns-mhdp-dp.c: MHDP DP API functions -cdns-mhdp-hdmi.c: MHDP HDMI API functions Sandor Yu (7): drm/rockchip: prepare common code for cdns and rk dpi/dp driver drm: bridge: cadence: Create cadence fold drm: bridge: cadence: initial support for MHDP DP bridge driver drm: imx: mhdp: initial support for i.MX8MQ MHDP Displayport drm: bridge: cadence: Initial support for MHDP HDMI bridge driver drm: imx: mhdp: Initial support for i.MX8MQ MHDP HDMI dt-bindings: display: Document Cadence MHDP HDMI/DP bindings .../bindings/display/bridge/cdns,mhdp.yaml| 46 + .../devicetree/bindings/display/imx/mhdp.yaml | 59 ++ drivers/gpu/drm/bridge/Kconfig| 2 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/cadence/Kconfig| 15 + drivers/gpu/drm/bridge/cadence/Makefile | 5 + drivers/gpu/drm/bridge/cadence/cdns-dp-core.c | 530 ++ .../gpu/drm/bridge/cadence/cdns-hdmi-core.c | 600 +++ .../gpu/drm/bridge/cadence/cdns-mhdp-audio.c | 298 ++ .../gpu/drm/bridge/cadence/cdns-mhdp-common.c | 682 + .../gpu/drm/bridge/cadence/cdns-mhdp-common.h | 40 + drivers/gpu/drm/bridge/cadence/cdns-mhdp-dp.c | 206 .../gpu/drm/bridge/cadence/cdns-mhdp-hdmi.c | 330 ++ drivers/gpu/drm/imx/Kconfig | 1 + drivers/gpu/drm/imx/Makefile | 1 + drivers/gpu/drm/imx/mhdp/Kconfig | 9 + drivers/gpu/drm/imx/mhdp/Makefile | 4 + drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c | 390 +++ drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c | 588 +++ drivers/gpu/drm/imx/mhdp/cdns-mhdp-imxdrv.c | 142 +++ drivers/gpu/drm/imx/mhdp/cdns-mhdp-phy.h | 148 +++ drivers/gpu/drm/rockchip/Kconfig | 1 + drivers/gpu/drm/rockchip/Makefile | 2 +- drivers/gpu/drm/rockchip/cdn-dp-core.c| 247 ++--- drivers/gpu/drm/rockchip/cdn-dp-core.h| 44 +- drivers/gpu/drm/rockchip/cdn-dp-reg.c | 960 -- .../drm/bridge/cdns-mhdp.h| 257 - 27 files changed, 4464 insertions(+), 1144 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/cdns,mhdp.yaml create mode 100644 Documentation/devicetree/bindings/display/imx/mhdp.yaml create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dp-core.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-audio.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-common.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-common.h create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-dp.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-hdmi.c create mode 100644 drivers/gpu/drm/imx/mhdp/Kconfig create mode 100644 drivers/gpu/drm/imx/mhdp/Makefile create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-dp-phy.c create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-imxdrv.c create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-phy.h delete mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c rename drivers/gpu/drm/rockchip/cdn-dp-reg.h => include/drm/bridge/cdns-mhdp.h (64%) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm: bridge: cadence: initial support for MHDP DP bridge driver
From: Sandor Yu
This adds initial support for MHDP DP bridge driver.
Basic DP functions are supported, that include:
-Video mode set on-the-fly
-Cable hotplug detect
-MAX support resolution to 3096x2160@60fps
-Support DP audio
-EDID read via AUX
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/bridge/cadence/Kconfig| 4 +
drivers/gpu/drm/bridge/cadence/Makefile | 1 +
drivers/gpu/drm/bridge/cadence/cdns-dp-core.c | 530 ++
.../gpu/drm/bridge/cadence/cdns-mhdp-audio.c | 100
.../gpu/drm/bridge/cadence/cdns-mhdp-common.c | 42 +-
.../gpu/drm/bridge/cadence/cdns-mhdp-common.h | 3 +
drivers/gpu/drm/bridge/cadence/cdns-mhdp-dp.c | 34 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 7 +-
include/drm/bridge/cdns-mhdp.h| 52 +-
9 files changed, 740 insertions(+), 33 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dp-core.c
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index 48c1b0f77dc6..b7b8d30b18b6 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -5,3 +5,7 @@ config DRM_CDNS_MHDP
depends on OF
help
Support Cadence MHDP API library.
+
+config DRM_CDNS_DP
+ tristate "Cadence DP DRM driver"
+ depends on DRM_CDNS_MHDP
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index ddb2ba4fb852..cb3c88311a64 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0-only
cdns_mhdp_drmcore-y := cdns-mhdp-common.o cdns-mhdp-audio.o cdns-mhdp-dp.o
+cdns_mhdp_drmcore-$(CONFIG_DRM_CDNS_DP) += cdns-dp-core.o
obj-$(CONFIG_DRM_CDNS_MHDP)+= cdns_mhdp_drmcore.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dp-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-dp-core.c
new file mode 100644
index ..b2fe8fdc64ed
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dp-core.c
@@ -0,0 +1,530 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence Display Port Interface (DP) driver
+ *
+ * Copyright (C) 2019-2020 NXP Semiconductor, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cdns-mhdp-common.h"
+
+/*
+ * This function only implements native DPDC reads and writes
+ */
+static ssize_t dp_aux_transfer(struct drm_dp_aux *aux,
+ struct drm_dp_aux_msg *msg)
+{
+ struct cdns_mhdp_device *mhdp = dev_get_drvdata(aux->dev);
+ bool native = msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATIVE_READ);
+ int ret;
+
+ /* Ignore address only message */
+ if ((msg->size == 0) || (msg->buffer == NULL)) {
+ msg->reply = native ?
+ DP_AUX_NATIVE_REPLY_ACK : DP_AUX_I2C_REPLY_ACK;
+ return msg->size;
+ }
+
+ if (!native) {
+ dev_err(mhdp->dev, "%s: only native messages supported\n",
__func__);
+ return -EINVAL;
+ }
+
+ /* msg sanity check */
+ if (msg->size > DP_AUX_MAX_PAYLOAD_BYTES) {
+ dev_err(mhdp->dev, "%s: invalid msg: size(%zu), request(%x)\n",
+ __func__, msg->size, (unsigned
int)msg->request);
+ return -EINVAL;
+ }
+
+ if (msg->request == DP_AUX_NATIVE_WRITE) {
+ const u8 *buf = msg->buffer;
+ int i;
+ for (i = 0; i < msg->size; ++i) {
+ ret = cdns_mhdp_dpcd_write(mhdp,
+ msg->address + i, buf[i]);
+ if (!ret)
+ continue;
+
+ DRM_DEV_ERROR(mhdp->dev, "Failed to write DPCD\n");
+
+ return ret;
+ }
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ return msg->size;
+ }
+
+ if (msg->request == DP_AUX_NATIVE_READ) {
+ ret = cdns_mhdp_dpcd_read(mhdp, msg->address, msg->buffer,
msg->size);
+ if (ret < 0)
+ return -EIO;
+ msg->reply = DP_AUX_NATIVE_REPLY_ACK;
+ return msg->size;
+ }
+ return 0;
+}
+
+static int dp_aux_init(struct cdns_mhdp_device *mhdp,
+ struct device *dev)
+{
+ int ret;
+
+ mhdp->dp.aux.name = "imx_dp_aux";
+ mhdp->dp.aux.dev = dev;
+ mhdp->dp.aux.transfer = dp_aux_transfer;
+
+ ret = drm_dp_aux_register(>dp.aux);
+
+ return ret;
+}
+
+static int dp_aux_destroy(struct cdns_mhdp_device *mhdp)
+{
+ drm_dp_aux_unregister(>dp.aux);
+ return 0;
+}
+
+static void dp_pixel_clk_reset(struct cdns_mhdp_device *mhdp)
+{
+ u32 val;
+
+ /* reset pixel clk */
+
[PATCH 2/7] drm: bridge: cadence: Create cadence fold
From: Sandor Yu
Create new directory drm/bridge/cadence.
Cadence MHDP DP and HDMI bridge dirver will added later.
drm/rockchip/cdn-dp-reg.c will separate to three files.
- cdns-mhdp-common.c: Provide basic MHDP register read/write via mailbox.
public firmware load, event, edid and HPD functions that will be
refered in MHDP DP and HDMI drivers.
- cdns-hdp-audio.c: MHDP Audio specific functions
- cdns-mhdp-dp.c: MHDP DP specific functions, DPCD and link traning
functions.
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/bridge/Kconfig| 2 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/cadence/Kconfig| 7 +
drivers/gpu/drm/bridge/cadence/Makefile | 3 +
.../gpu/drm/bridge/cadence/cdns-mhdp-audio.c | 198 +
.../cadence/cdns-mhdp-common.c} | 418 --
.../gpu/drm/bridge/cadence/cdns-mhdp-common.h | 23 +
drivers/gpu/drm/bridge/cadence/cdns-mhdp-dp.c | 174
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/rockchip/Makefile | 2 +-
drivers/gpu/drm/rockchip/cdn-dp-core.c| 2 +-
drivers/gpu/drm/rockchip/cdn-dp-core.h| 2 +-
.../drm/bridge/cdns-mhdp.h| 9 +-
13 files changed, 494 insertions(+), 348 deletions(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/Kconfig
create mode 100644 drivers/gpu/drm/bridge/cadence/Makefile
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-audio.c
rename drivers/gpu/drm/{rockchip/cdn-dp-reg.c =>
bridge/cadence/cdns-mhdp-common.c} (64%)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-common.h
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-dp.c
rename drivers/gpu/drm/rockchip/cdn-dp-reg.h => include/drm/bridge/cdns-mhdp.h
(98%)
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index aaed2347ace9..c764150fb228 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -184,6 +184,8 @@ source "drivers/gpu/drm/bridge/analogix/Kconfig"
source "drivers/gpu/drm/bridge/adv7511/Kconfig"
+source "drivers/gpu/drm/bridge/cadence/Kconfig"
+
source "drivers/gpu/drm/bridge/synopsys/Kconfig"
endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 6fb062b5b0f0..5d61c1d43b67 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -20,4 +20,5 @@ obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
obj-$(CONFIG_DRM_TI_TPD12S015) += ti-tpd12s015.o
obj-y += analogix/
+obj-y += cadence/
obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
new file mode 100644
index ..48c1b0f77dc6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -0,0 +1,7 @@
+config DRM_CDNS_MHDP
+ tristate "Cadence MHDP COMMON API driver"
+ select DRM_KMS_HELPER
+ select DRM_PANEL_BRIDGE
+ depends on OF
+ help
+ Support Cadence MHDP API library.
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
new file mode 100644
index ..ddb2ba4fb852
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+cdns_mhdp_drmcore-y := cdns-mhdp-common.o cdns-mhdp-audio.o cdns-mhdp-dp.o
+obj-$(CONFIG_DRM_CDNS_MHDP)+= cdns_mhdp_drmcore.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-audio.c
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-audio.c
new file mode 100644
index ..8f51de0672ab
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-audio.c
@@ -0,0 +1,198 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author: Chris Zhong
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cdns-mhdp-common.h"
+
+#define CDNS_DP_SPDIF_CLK 2
+
+int cdns_mhdp_audio_stop(struct cdns_mhdp_device *mhdp, struct audio_info
*audio)
+{
+ int ret;
+
+ ret = cdns_mhdp_reg_write(mhdp, AUDIO_PACK_CONTROL, 0);
+ if (ret) {
+ DRM_DEV_ERROR(mhdp->dev, "audio stop failed: %d\n", ret);
+ return ret;
+ }
+
+ cdns_mhdp_bus_write(0, mhdp, SPDIF_CTRL_ADDR);
+
+ /* clearn the audio config and reset */
+ cdns_mhdp_bus_write(0, mhdp, AUDIO_SRC_CNTL);
+ cdns_mhdp_bus_write(0, mhdp, AUDIO_SRC_CNFG);
+ cdns_mhdp_bus_write(AUDIO_SW_RST, mhdp, AUDIO_SRC_CNTL);
+ cdns_mhdp_bus_write(0, mhdp, AUDIO_SRC_CNTL);
+
+ /* reset smpl2pckt component */
+ cdns_mhdp_bus_write(0, mhdp, SMPL2PKT_CNTL);
+ cdns_mhdp_bus_write(AUDIO_SW_RST, mhdp, SMPL2PKT_CNTL);
+ cdns_mhdp_bus_write(0, mhdp, SMPL2PKT_CNTL);
+
+ /* reset FIFO */
+ cdns_mhdp_bus_write(AUDIO_SW_RST, mhdp, FIFO_CNTL);
+ cdns_mhdp_bus_write(0, mhdp, FIFO_CNTL);
+
+
[PATCH 6/7] drm: imx: mhdp: Initial support for i.MX8MQ MHDP HDMI
From: Sandor Yu
Add initial support for i.MX8MQ MHDP HDMI.
Add MHDP HDMI PHY configuration.
The features are same as mhdp hdmi bridge driver.
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/imx/mhdp/Kconfig | 5 +-
drivers/gpu/drm/imx/mhdp/Makefile | 2 +-
drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c | 588 ++
drivers/gpu/drm/imx/mhdp/cdns-mhdp-imxdrv.c | 12 +
drivers/gpu/drm/imx/mhdp/cdns-mhdp-phy.h | 2 +
5 files changed, 606 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c
diff --git a/drivers/gpu/drm/imx/mhdp/Kconfig b/drivers/gpu/drm/imx/mhdp/Kconfig
index c9e07a3bf3df..fc0cf708b900 100644
--- a/drivers/gpu/drm/imx/mhdp/Kconfig
+++ b/drivers/gpu/drm/imx/mhdp/Kconfig
@@ -1,8 +1,9 @@
# SPDX-License-Identifier: GPL-2.0-only
config DRM_IMX_CDNS_MHDP
- tristate "NXP i.MX MX8 DRM DP"
+ tristate "NXP i.MX MX8 DRM DP/HDMI"
select DRM_CDNS_MHDP
select DRM_CDNS_DP
+ select DRM_CDNS_HDMI
help
- Choose this if you want to use Displayport on i.MX8.
+ Choose this if you want to use Displayport/HDMI on i.MX8.
diff --git a/drivers/gpu/drm/imx/mhdp/Makefile
b/drivers/gpu/drm/imx/mhdp/Makefile
index 4383e689445a..ca51a2a9641c 100644
--- a/drivers/gpu/drm/imx/mhdp/Makefile
+++ b/drivers/gpu/drm/imx/mhdp/Makefile
@@ -1,4 +1,4 @@
# SPDX-License-Identifier: GPL-2.0
-cdns_mhdp_imx-objs := cdns-mhdp-imxdrv.o cdns-mhdp-dp-phy.o
+cdns_mhdp_imx-objs := cdns-mhdp-imxdrv.o cdns-mhdp-dp-phy.o
cdns-mhdp-hdmi-phy.o
obj-$(CONFIG_DRM_IMX_CDNS_MHDP) += cdns_mhdp_imx.o
diff --git a/drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c
b/drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c
new file mode 100644
index ..54b01e13a2b6
--- /dev/null
+++ b/drivers/gpu/drm/imx/mhdp/cdns-mhdp-hdmi-phy.c
@@ -0,0 +1,588 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence High-Definition Multimedia Interface (HDMI) PHY driver
+ *
+ * Copyright (C) 2019-2020 NXP Semiconductor, Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include "cdns-mhdp-phy.h"
+
+/* HDMI TX clock control settings */
+struct hdmi_ctrl {
+ u32 pixel_clk_freq_min;
+ u32 pixel_clk_freq_max;
+ u32 feedback_factor;
+ u32 data_range_kbps_min;
+ u32 data_range_kbps_max;
+ u32 cmnda_pll0_ip_div;
+ u32 cmn_ref_clk_dig_div;
+ u32 ref_clk_divider_scaler;
+ u32 pll_fb_div_total;
+ u32 cmnda_pll0_fb_div_low;
+ u32 cmnda_pll0_fb_div_high;
+ u32 pixel_div_total;
+ u32 cmnda_pll0_pxdiv_low;
+ u32 cmnda_pll0_pxdiv_high;
+ u32 vco_freq_min;
+ u32 vco_freq_max;
+ u32 vco_ring_select;
+ u32 cmnda_hs_clk_0_sel;
+ u32 cmnda_hs_clk_1_sel;
+ u32 hsclk_div_at_xcvr;
+ u32 hsclk_div_tx_sub_rate;
+ u32 cmnda_pll0_hs_sym_div_sel;
+ u32 cmnda_pll0_clk_freq_min;
+ u32 cmnda_pll0_clk_freq_max;
+};
+
+/* HDMI TX clock control settings, pixel clock is output */
+static const struct hdmi_ctrl imx8mq_ctrl_table[] = {
+/*Minclk Maxclk Fdbak DR_min DR_max ip_d dig DSTotl */
+{ 27000, 27000, 1000, 27, 27, 0x03, 0x1, 0x1, 240, 0x0BC, 0x030,
80, 0x026, 0x026, 216, 216, 0, 2, 2, 2, 4, 0x3, 27000, 27000},
+{ 27000, 27000, 1250, 337500, 337500, 0x03, 0x1, 0x1, 300, 0x0EC, 0x03C,
100, 0x030, 0x030, 270, 270, 0, 2, 2, 2, 4, 0x3, 33750, 33750},
+{ 27000, 27000, 1500, 405000, 405000, 0x03, 0x1, 0x1, 360, 0x11C, 0x048,
120, 0x03A, 0x03A, 324, 324, 0, 2, 2, 2, 4, 0x3, 40500, 40500},
+{ 27000, 27000, 2000, 54, 54, 0x03, 0x1, 0x1, 240, 0x0BC, 0x030,
80, 0x026, 0x026, 216, 216, 0, 2, 2, 2, 4, 0x2, 54000, 54000},
+{ 54000, 54000, 1000, 54, 54, 0x03, 0x1, 0x1, 480, 0x17C, 0x060,
80, 0x026, 0x026, 432, 432, 1, 2, 2, 2, 4, 0x3, 54000, 54000},
+{ 54000, 54000, 1250, 675000, 675000, 0x04, 0x1, 0x1, 400, 0x13C, 0x050,
50, 0x017, 0x017, 270, 270, 0, 1, 1, 2, 4, 0x2, 67500, 67500},
+{ 54000, 54000, 1500, 81, 81, 0x04, 0x1, 0x1, 480, 0x17C, 0x060,
60, 0x01C, 0x01C, 324, 324, 0, 2, 2, 2, 2, 0x2, 81000, 81000},
+{ 54000, 54000, 2000, 108, 108, 0x03, 0x1, 0x1, 240, 0x0BC, 0x030,
40, 0x012, 0x012, 216, 216, 0, 2, 2, 2, 1, 0x1, 108000, 108000},
+{ 74250, 74250, 1000, 742500, 742500, 0x03, 0x1, 0x1, 660, 0x20C, 0x084,
80, 0x026, 0x026, 594, 594, 1, 2, 2, 2, 4, 0x3, 74250, 74250},
+{ 74250, 74250, 1250, 928125, 928125, 0x04, 0x1, 0x1, 550, 0x1B4, 0x06E,
50, 0x017, 0x017, 3712500, 3712500, 1, 1, 1, 2, 4, 0x2, 92812, 92812},
+{ 74250, 74250, 1500, 1113750, 1113750, 0x04, 0x1, 0x1, 660, 0x20C, 0x084,
60, 0x01C, 0x01C, 4455000, 4455000, 1, 2, 2, 2, 2, 0x2, 111375, 111375},
+{ 74250, 74250, 2000, 1485000, 1485000, 0x03, 0x1, 0x1, 330, 0x104, 0x042,
40,
[PATCH 5/7] drm: bridge: cadence: Initial support for MHDP HDMI bridge driver
From: Sandor Yu
This adds initial support for cadence MHDP HDMI bridge driver.
Basic HDMI functions are supported, that include:
-Video mode set on-the-fly
-Cable hotplug detect
-MAX support resolution to 3096x2160@60fps
-HDMI audio
-AV infoframe
-EDID read
-SCDC read
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/bridge/cadence/Kconfig| 4 +
drivers/gpu/drm/bridge/cadence/Makefile | 3 +-
.../gpu/drm/bridge/cadence/cdns-hdmi-core.c | 600 ++
.../gpu/drm/bridge/cadence/cdns-mhdp-common.h | 14 +
.../gpu/drm/bridge/cadence/cdns-mhdp-hdmi.c | 330 ++
include/drm/bridge/cdns-mhdp.h| 69 ++
6 files changed, 1019 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-hdmi.c
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
b/drivers/gpu/drm/bridge/cadence/Kconfig
index b7b8d30b18b6..9bc098302837 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -9,3 +9,7 @@ config DRM_CDNS_MHDP
config DRM_CDNS_DP
tristate "Cadence DP DRM driver"
depends on DRM_CDNS_MHDP
+
+config DRM_CDNS_HDMI
+ tristate "Cadence HDMI DRM driver"
+ depends on DRM_CDNS_MHDP
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile
b/drivers/gpu/drm/bridge/cadence/Makefile
index cb3c88311a64..1d60166c2bf5 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0-only
-cdns_mhdp_drmcore-y := cdns-mhdp-common.o cdns-mhdp-audio.o cdns-mhdp-dp.o
+cdns_mhdp_drmcore-y := cdns-mhdp-common.o cdns-mhdp-audio.o cdns-mhdp-dp.o
cdns-mhdp-hdmi.o
cdns_mhdp_drmcore-$(CONFIG_DRM_CDNS_DP) += cdns-dp-core.o
+cdns_mhdp_drmcore-$(CONFIG_DRM_CDNS_HDMI) += cdns-hdmi-core.o
obj-$(CONFIG_DRM_CDNS_MHDP)+= cdns_mhdp_drmcore.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
b/drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
new file mode 100644
index ..5775ed21b734
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cadence/cdns-hdmi-core.c
@@ -0,0 +1,600 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Cadence High-Definition Multimedia Interface (HDMI) driver
+ *
+ * Copyright (C) 2019-2020 NXP Semiconductor, Inc.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "cdns-mhdp-common.h"
+
+static void hdmi_sink_config(struct cdns_mhdp_device *mhdp)
+{
+ struct drm_scdc *scdc = >connector.base.display_info.hdmi.scdc;
+ u8 buff = 0;
+
+ /* Default work in HDMI1.4 */
+ mhdp->hdmi.hdmi_type = MODE_HDMI_1_4;
+
+ /* check sink support SCDC or not */
+ if (scdc->supported != true) {
+ DRM_INFO("Sink Not Support SCDC\n");
+ return;
+ }
+
+ if (mhdp->hdmi.char_rate > 34) {
+ /*
+* TMDS Character Rate above 340MHz should working in HDMI2.0
+* Enable scrambling and TMDS_Bit_Clock_Ratio
+*/
+ buff = SCDC_TMDS_BIT_CLOCK_RATIO_BY_40 | SCDC_SCRAMBLING_ENABLE;
+ mhdp->hdmi.hdmi_type = MODE_HDMI_2_0;
+ } else if (scdc->scrambling.low_rates) {
+ /*
+* Enable scrambling and HDMI2.0 when scrambling capability of
sink
+* be indicated in the HF-VSDB LTE_340Mcsc_scramble bit
+*/
+ buff = SCDC_SCRAMBLING_ENABLE;
+ mhdp->hdmi.hdmi_type = MODE_HDMI_2_0;
+ }
+
+ /* TMDS config */
+ cdns_hdmi_scdc_write(mhdp, SCDC_TMDS_CONFIG, buff);
+}
+
+static void hdmi_lanes_config(struct cdns_mhdp_device *mhdp)
+{
+ u32 lane_mapping = mhdp->plat_data->lane_mapping;
+ /* Line swaping */
+ cdns_mhdp_reg_write(mhdp, LANES_CONFIG, 0x0040 | lane_mapping);
+}
+
+static int hdmi_avi_info_set(struct cdns_mhdp_device *mhdp,
+struct drm_display_mode *mode)
+{
+ struct hdmi_avi_infoframe frame;
+ int format = mhdp->video_info.color_fmt;
+ struct drm_connector_state *conn_state = mhdp->connector.base.state;
+ struct drm_display_mode *adj_mode;
+ enum hdmi_quantization_range qr;
+ u8 buf[32];
+ int ret;
+
+ /* Initialise info frame from DRM mode */
+ drm_hdmi_avi_infoframe_from_display_mode(,
+ >connector.base, mode);
+
+ switch (format) {
+ case YCBCR_4_4_4:
+ frame.colorspace = HDMI_COLORSPACE_YUV444;
+ break;
+ case YCBCR_4_2_2:
+ frame.colorspace = HDMI_COLORSPACE_YUV422;
+ break;
+ case YCBCR_4_2_0:
+ frame.colorspace = HDMI_COLORSPACE_YUV420;
+ break;
+
[PATCH 1/7] drm/rockchip: prepare common code for cdns and rk dpi/dp driver
From: Sandor Yu
- Extracted common fields from cdn_dp_device to a new cdns_mhdp_device
structure which will be used by two separate drivers later on.
- Moved some datatypes (audio_format, audio_info, vic_pxl_encoding_format,
video_info) from cdn-dp-core.c to cdn-dp-reg.h.
- Changed prefixes from cdn_dp to cdns_mhdp
cdn -> cdns to match the other Cadence's drivers
dp -> mhdp to distinguish it from a "just a DP" as the IP underneath
this registers map can be a HDMI (which is internally different,
but the interface for commands, events is pretty much the same).
- Modified cdn-dp-core.c to use the new driver structure and new function
names.
- writel and readl are replaced by cdns_mhdp_bus_write and
cdns_mhdp_bus_read.
Signed-off-by: Damian Kos
Signed-off-by: Sandor Yu
---
drivers/gpu/drm/rockchip/cdn-dp-core.c | 240 ++--
drivers/gpu/drm/rockchip/cdn-dp-core.h | 44 +--
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 488 +
drivers/gpu/drm/rockchip/cdn-dp-reg.h | 133 +--
4 files changed, 483 insertions(+), 422 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index eed594bd38d3..b6aa21779608 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -26,7 +26,7 @@
#include "rockchip_drm_vop.h"
#define connector_to_dp(c) \
- container_of(c, struct cdn_dp_device, connector)
+ container_of(c, struct cdn_dp_device, mhdp.connector.base)
#define encoder_to_dp(c) \
container_of(c, struct cdn_dp_device, encoder)
@@ -61,17 +61,18 @@ MODULE_DEVICE_TABLE(of, cdn_dp_dt_ids);
static int cdn_dp_grf_write(struct cdn_dp_device *dp,
unsigned int reg, unsigned int val)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
ret = clk_prepare_enable(dp->grf_clk);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Failed to prepare_enable grf clock\n");
+ DRM_DEV_ERROR(dev, "Failed to prepare_enable grf clock\n");
return ret;
}
ret = regmap_write(dp->grf, reg, val);
if (ret) {
- DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
+ DRM_DEV_ERROR(dev, "Could not write to GRF: %d\n", ret);
return ret;
}
@@ -82,24 +83,25 @@ static int cdn_dp_grf_write(struct cdn_dp_device *dp,
static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
int ret;
unsigned long rate;
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable dp pclk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable dp pclk %d\n", ret);
goto err_pclk;
}
ret = clk_prepare_enable(dp->core_clk);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot enable core_clk %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot enable core_clk %d\n", ret);
goto err_core_clk;
}
- ret = pm_runtime_get_sync(dp->dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0) {
- DRM_DEV_ERROR(dp->dev, "cannot get pm runtime %d\n", ret);
+ DRM_DEV_ERROR(dev, "cannot get pm runtime %d\n", ret);
goto err_pm_runtime_get;
}
@@ -112,18 +114,18 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
rate = clk_get_rate(dp->core_clk);
if (!rate) {
- DRM_DEV_ERROR(dp->dev, "get clk rate failed\n");
+ DRM_DEV_ERROR(dev, "get clk rate failed\n");
ret = -EINVAL;
goto err_set_rate;
}
- cdn_dp_set_fw_clk(dp, rate);
- cdn_dp_clock_reset(dp);
+ cdns_mhdp_set_fw_clk(>mhdp, rate);
+ cdns_mhdp_clock_reset(>mhdp);
return 0;
err_set_rate:
- pm_runtime_put(dp->dev);
+ pm_runtime_put(dev);
err_pm_runtime_get:
clk_disable_unprepare(dp->core_clk);
err_core_clk:
@@ -134,7 +136,7 @@ static int cdn_dp_clk_enable(struct cdn_dp_device *dp)
static void cdn_dp_clk_disable(struct cdn_dp_device *dp)
{
- pm_runtime_put_sync(dp->dev);
+ pm_runtime_put_sync(dp->mhdp.dev);
clk_disable_unprepare(dp->pclk);
clk_disable_unprepare(dp->core_clk);
}
@@ -167,7 +169,7 @@ static int cdn_dp_get_sink_count(struct cdn_dp_device *dp,
u8 *sink_count)
u8 value;
*sink_count = 0;
- ret = cdn_dp_dpcd_read(dp, DP_SINK_COUNT, , 1);
+ ret = drm_dp_dpcd_read(>mhdp.dp.aux, DP_SINK_COUNT, , 1);
if (ret)
return ret;
@@ -191,12 +193,13 @@ static struct cdn_dp_port *cdn_dp_connected_port(struct
cdn_dp_device *dp)
static bool cdn_dp_check_sink_connection(struct cdn_dp_device *dp)
{
+ struct device *dev = dp->mhdp.dev;
unsigned long timeout =
