Re: Panic booting qemu-system-sparc64 with bochs_drm
On 03/07/2020 22:57, Mark Cave-Ayland wrote:
> Hi all,
>
> I've been receiving reports that newer sparc64 kernels have started to panic
> on boot
> under qemu-system-sparc64 with bochs_drm enabled which I was able to confirm
> locally
> building git master:
>
>
> [9.007161] [drm] Found bochs VGA, ID 0xb0c5.
> [9.007840] [drm] Framebuffer size 16384 kB @ 0x1ff2200, mmio @
> 0x1ff2300.
> [9.012567] [TTM] Zone kernel: Available graphics memory: 51496 KiB
> [9.013551] [TTM] Initializing pool allocator
> [9.032757] [drm] Found EDID data blob.
> [9.061904] [drm] Initialized bochs-drm 1.0.0 20130925 for :01:02.0 on
> minor 0
> [9.336819] Unable to handle kernel paging request at virtual address
> 01ff221d
> [9.337177] tsk->{mm,active_mm}->context =
> [9.337283] tsk->{mm,active_mm}->pgd = f8402000
> [9.337372] \|/ \|/
> [9.337372] "@'/ .. \`@"
> [9.337372] /_| \__/ |_\
> [9.337372] \__U_/
> [9.337468] kworker/0:0(5): Oops [#1]
> [9.339359] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc3+ #55
> [9.341360] Workqueue: events drm_fb_helper_dirty_work
> [9.341775] TSTATE: 80001605 TPC: 0077441c TNPC:
> 00774420
> Y: Not tainted
> [9.341894] TPC:
> [9.342015] g0: g1: g2:
> g3:
> f800043d2c00
> [9.342094] g4: f8000410eac0 g5: f800064cc000 g6: f80004124000
> g7:
> 0010
> [9.342173] o0: 01ff221d o1: 00010022 o2:
> o3:
> 01fe21fb
> [9.342254] o4: 01ff221d o5: sp: f800041273d1
> ret_pc:
> 00805b18
> [9.342325] RPC:
> [9.342591] l0: f80007819cc0 l1: f800043df8cc l2: 01356200
> l3:
> f800064cc000
> [9.342670] l4: f80004004200 l5: l6: 0025
> l7:
> f80004002500
> [9.342750] i0: f800043df8d0 i1: f800040106b0 i2: 0020
> i3:
> f800043e5500
> [9.342829] i4: 01d1 i5: 00010022 i6: f80004127491
> i7:
> 00481fec
> [9.342960] I7:
> [9.343308] Call Trace:
> [9.344077] [<00481fec>] process_one_work+0x18c/0x540
> [9.344267] [<004824c4>] worker_thread+0x124/0x580
> [9.344310] [<00489758>] kthread+0xf8/0x120
> [9.344357] [<004060a4>] ret_from_fork+0x1c/0x2c
> [9.344714] [<>] 0x0
>
>
> The error "Unable to handle kernel paging request at virtual address
> 01ff221d" is caused by trying to access the framebuffer using a
> virtual
> address, rather than using IO accessors which access the framebuffer
> correctly using
> SPARC ASI_PHYS (physical) loads and stores. In some ways this is similar to
> the bug I
> reported a couple of years back at
> https://lists.freedesktop.org/archives/dri-devel/2017-June/145793.html which
> was
> fixed with
> https://lists.freedesktop.org/archives/dri-devel/2017-July/145935.html.
>
> According to git bisect the regression is introduced by the following commit:
>
> $ git bisect bad
> 7a0483ac4ffca4998945c159b28afdde8353cc84 is the first bad commit
> commit 7a0483ac4ffca4998945c159b28afdde8353cc84
> Author: Gerd Hoffmann
> Date: Fri Jan 11 06:37:50 2019 +0100
>
> drm/bochs: switch to generic drm fbdev emulation
>
> Signed-off-by: Gerd Hoffmann
> Acked-by: Daniel Vetter
> Link:
> http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kra...@redhat.com
>
> :04 04 1917943277034f620af03ac1a2fa5db48b7b224c
> 6d7a3c316a68efbffd398d6c2b7eebefb47bc92d M drivers
>
>
> The commit following this one at
> https://patchwork.freedesktop.org/patch/276488/?series=54269=4 removes
> bochsfb_ops and the cfb helpers which was the original fix introduced by my
> second
> patch above, so I'm unsure how to approach fixing this with the switch to
> drm_fbdev_generic_setup().
>
> Can anyone point me in the right direction?
Just following up from the original thread on debian-sparc, Sam asked about
providing
some instructions to allow others to reproduce the error which are included
below:
1) Building QEMU
I'm currently using QEMU git master configured just to build
qemu-system-sparc64 as
follows:
./configure --target-list=sparc64-softmmu
make && make install
(Note: the latest release QEMU 5.0 has a regression in OpenBIOS which prevents
-kernel from working correctly. If you install QEMU 5.0 from a package then you
can
grab the updated openbios-sparc64 directly from git at
https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios;h=a835f94751ef7d2e2648ce7c79eac1d6fea9b83c;hb=5f42c3375d45108cf14f50ac8ba57c2865e75e9c
to replace the installed one)
2) Build the kernel
This was done using Debian Buster on amd64 and its pre-packaged sparc64
cross-compilers.
[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 Alexander Kernozhitsky (sh200...@mail.ru) changed: What|Removed |Added CC||sh200...@mail.ru --- Comment #29 from Alexander Kernozhitsky (sh200...@mail.ru) --- I encountered this bug today. When running specific graphical applications, the machine hangs, and the kernel logs say about simd exception. It started to occur after the upgrade to 5.7.6 kernel. I tried to apply the patch mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=207979, and the patch resolves the issue for me. Using AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx. -- 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
Panic booting qemu-system-sparc64 with bochs_drm
Hi all,
I've been receiving reports that newer sparc64 kernels have started to panic on
boot
under qemu-system-sparc64 with bochs_drm enabled which I was able to confirm
locally
building git master:
[9.007161] [drm] Found bochs VGA, ID 0xb0c5.
[9.007840] [drm] Framebuffer size 16384 kB @ 0x1ff2200, mmio @
0x1ff2300.
[9.012567] [TTM] Zone kernel: Available graphics memory: 51496 KiB
[9.013551] [TTM] Initializing pool allocator
[9.032757] [drm] Found EDID data blob.
[9.061904] [drm] Initialized bochs-drm 1.0.0 20130925 for :01:02.0 on
minor 0
[9.336819] Unable to handle kernel paging request at virtual address
01ff221d
[9.337177] tsk->{mm,active_mm}->context =
[9.337283] tsk->{mm,active_mm}->pgd = f8402000
[9.337372] \|/ \|/
[9.337372] "@'/ .. \`@"
[9.337372] /_| \__/ |_\
[9.337372] \__U_/
[9.337468] kworker/0:0(5): Oops [#1]
[9.339359] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.8.0-rc3+ #55
[9.341360] Workqueue: events drm_fb_helper_dirty_work
[9.341775] TSTATE: 80001605 TPC: 0077441c TNPC:
00774420
Y: Not tainted
[9.341894] TPC:
[9.342015] g0: g1: g2:
g3:
f800043d2c00
[9.342094] g4: f8000410eac0 g5: f800064cc000 g6: f80004124000
g7:
0010
[9.342173] o0: 01ff221d o1: 00010022 o2:
o3:
01fe21fb
[9.342254] o4: 01ff221d o5: sp: f800041273d1
ret_pc:
00805b18
[9.342325] RPC:
[9.342591] l0: f80007819cc0 l1: f800043df8cc l2: 01356200
l3:
f800064cc000
[9.342670] l4: f80004004200 l5: l6: 0025
l7:
f80004002500
[9.342750] i0: f800043df8d0 i1: f800040106b0 i2: 0020
i3:
f800043e5500
[9.342829] i4: 01d1 i5: 00010022 i6: f80004127491
i7:
00481fec
[9.342960] I7:
[9.343308] Call Trace:
[9.344077] [<00481fec>] process_one_work+0x18c/0x540
[9.344267] [<004824c4>] worker_thread+0x124/0x580
[9.344310] [<00489758>] kthread+0xf8/0x120
[9.344357] [<004060a4>] ret_from_fork+0x1c/0x2c
[9.344714] [<>] 0x0
The error "Unable to handle kernel paging request at virtual address
01ff221d" is caused by trying to access the framebuffer using a virtual
address, rather than using IO accessors which access the framebuffer correctly
using
SPARC ASI_PHYS (physical) loads and stores. In some ways this is similar to the
bug I
reported a couple of years back at
https://lists.freedesktop.org/archives/dri-devel/2017-June/145793.html which was
fixed with
https://lists.freedesktop.org/archives/dri-devel/2017-July/145935.html.
According to git bisect the regression is introduced by the following commit:
$ git bisect bad
7a0483ac4ffca4998945c159b28afdde8353cc84 is the first bad commit
commit 7a0483ac4ffca4998945c159b28afdde8353cc84
Author: Gerd Hoffmann
Date: Fri Jan 11 06:37:50 2019 +0100
drm/bochs: switch to generic drm fbdev emulation
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
Link:
http://patchwork.freedesktop.org/patch/msgid/20190111053752.4004-15-kra...@redhat.com
:04 04 1917943277034f620af03ac1a2fa5db48b7b224c
6d7a3c316a68efbffd398d6c2b7eebefb47bc92d M drivers
The commit following this one at
https://patchwork.freedesktop.org/patch/276488/?series=54269=4 removes
bochsfb_ops and the cfb helpers which was the original fix introduced by my
second
patch above, so I'm unsure how to approach fixing this with the switch to
drm_fbdev_generic_setup().
Can anyone point me in the right direction?
Many thanks,
Mark.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.8-rc4
The pull request you sent on Fri, 3 Jul 2020 11:46:34 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-07-03 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/1d42871465291c3f117ea3c9fbce8d4a603c303b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx
Hi Tomi.
On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:
> On 30/06/2020 21:26, Adam Ford wrote:
> > The drm/omap driver was fixed to correct an issue where using a
> > divider of 32 breaks the DSS despite the TRM stating 32 is a valid
> > number. Through experimentation, it appears that 31 works, and
> > it is consistent with the value used by the drm/omap driver.
> >
> > This patch fixes the divider for fbdev driver instead of the drm.
> >
> > Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
> >
> > Cc: #4.9+
> > Signed-off-by: Adam Ford
> > ---
> > Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
> >
> > The DRM version of this same fix is:
> > e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
> >
> >
> > diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > index 7252d22dd117..bfc5c4c5a26a 100644
> > --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > @@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats = {
> > };
> > static const struct dss_features omap3630_dss_feats = {
> > - .fck_div_max= 32,
> > + .fck_div_max= 31,
> > .dss_fck_multiplier = 1,
> > .parent_clk_name= "dpll4_ck",
> > .dpi_select_source = _dpi_select_source_omap2_omap3,
> >
>
> Reviewed-by: Tomi Valkeinen
Will you apply to drm-misc?
Note following output from "dim fixes":
$ dim fixes f76ee892a99e
Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: Tomi Valkeinen
Cc: Dave Airlie
Cc: Rob Clark
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Bartlomiej Zolnierkiewicz
Cc: Jason Yan
Cc: "Andrew F. Davis"
Cc: YueHaibing
Cc: # v4.5+
Here it says the fix is valid from v4.5 onwards.
Sam
>
> Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 14/21] drm/bridge: megachips: get drm_device from bridge
Fix so drm_device is read from the bridge. This is a preparation for the connector being optional. Signed-off-by: Sam Ravnborg Cc: Peter Senna Tschudin Cc: Martin Donnelly Cc: Martyn Welch Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Jernej Skrabec --- drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c index 258e0525cdcc..cf1dfbc88acf 100644 --- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c +++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c @@ -226,8 +226,8 @@ static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void *dev_id) STDP4028_DPTX_IRQ_STS_REG, STDP4028_DPTX_IRQ_CLEAR); - if (ge_b850v3_lvds_ptr->connector.dev) - drm_kms_helper_hotplug_event(ge_b850v3_lvds_ptr->connector.dev); + if (ge_b850v3_lvds_ptr->bridge.dev) + drm_kms_helper_hotplug_event(ge_b850v3_lvds_ptr->bridge.dev); return IRQ_HANDLED; } -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/21] drm/bridge: ti-tpd12s015: make connector creation optional
The ti-tpd12s015 do not create any connector, so ignore the flags argument, just pass it on to the next bridge in the chain. Signed-off-by: Sam Ravnborg Cc: Andrzej Hajda Cc: Neil Armstrong Cc: Laurent Pinchart Cc: Jonas Karlman Cc: Jernej Skrabec --- drivers/gpu/drm/bridge/ti-tpd12s015.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c b/drivers/gpu/drm/bridge/ti-tpd12s015.c index 514cbf0eac75..4f1666422ab2 100644 --- a/drivers/gpu/drm/bridge/ti-tpd12s015.c +++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c @@ -43,9 +43,6 @@ static int tpd12s015_attach(struct drm_bridge *bridge, struct tpd12s015_device *tpd = to_tpd12s015(bridge); int ret; - if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) - return -EINVAL; - ret = drm_bridge_attach(bridge->encoder, tpd->next_bridge, bridge, flags); if (ret < 0) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 13/21] drm/bridge: megachips: add helper to create connector
Factor out connector creation to a small helper function.
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../bridge/megachips-stdp-ge-b850v3-fw.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index 6200f12a37e6..258e0525cdcc 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -191,6 +191,32 @@ static const struct drm_connector_funcs
ge_b850v3_lvds_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
+static int ge_b850v3_lvds_create_connector(struct drm_bridge *bridge)
+{
+ struct drm_connector *connector = _b850v3_lvds_ptr->connector;
+ int ret;
+
+ if (!bridge->encoder) {
+ DRM_ERROR("Parent encoder object not found");
+ return -ENODEV;
+ }
+
+ connector->polled = DRM_CONNECTOR_POLL_HPD;
+
+ drm_connector_helper_add(connector,
+_b850v3_lvds_connector_helper_funcs);
+
+ ret = drm_connector_init(bridge->dev, connector,
+_b850v3_lvds_connector_funcs,
+DRM_MODE_CONNECTOR_DisplayPort);
+ if (ret) {
+ DRM_ERROR("Failed to initialize connector with drm\n");
+ return ret;
+ }
+
+ return drm_connector_attach_encoder(connector, bridge->encoder);
+}
+
static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void *dev_id)
{
struct i2c_client *stdp4028_i2c
@@ -209,7 +235,6 @@ static irqreturn_t ge_b850v3_lvds_irq_handler(int irq, void
*dev_id)
static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
- struct drm_connector *connector = _b850v3_lvds_ptr->connector;
struct i2c_client *stdp4028_i2c
= ge_b850v3_lvds_ptr->stdp4028_i2c;
int ret;
@@ -219,25 +244,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
return -EINVAL;
}
- if (!bridge->encoder) {
- DRM_ERROR("Parent encoder object not found");
- return -ENODEV;
- }
-
- connector->polled = DRM_CONNECTOR_POLL_HPD;
-
- drm_connector_helper_add(connector,
-_b850v3_lvds_connector_helper_funcs);
-
- ret = drm_connector_init(bridge->dev, connector,
-_b850v3_lvds_connector_funcs,
-DRM_MODE_CONNECTOR_DisplayPort);
- if (ret) {
- DRM_ERROR("Failed to initialize connector with drm\n");
- return ret;
- }
-
- ret = drm_connector_attach_encoder(connector, bridge->encoder);
+ ret = ge_b850v3_lvds_create_connector(bridge);
if (ret)
return ret;
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/21] drm/bridge: tc358764: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
The bridge panel will use the connector type reported by the panel,
where the connector for this driver hardcode DRM_MODE_CONNECTOR_LVDS.
v2:
- Use PTR_ERR_OR_ZERO() (kbuild test robot)
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: kbuild test robot
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358764.c | 57 ---
1 file changed, 14 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index a277739fab58..e1f052a4f53b 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -156,7 +156,7 @@ struct tc358764 {
struct drm_connector connector;
struct regulator_bulk_data supplies[ARRAY_SIZE(tc358764_supplies)];
struct gpio_desc *gpio_reset;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
int error;
};
@@ -282,7 +282,7 @@ static int tc358764_get_modes(struct drm_connector
*connector)
{
struct tc358764 *ctx = connector_to_tc358764(connector);
- return drm_panel_get_modes(ctx->panel, connector);
+ return drm_bridge_get_modes(ctx->panel_bridge, connector);
}
static const
@@ -298,23 +298,11 @@ static const struct drm_connector_funcs
tc358764_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static void tc358764_disable(struct drm_bridge *bridge)
-{
- struct tc358764 *ctx = bridge_to_tc358764(bridge);
- int ret = drm_panel_disable(bridge_to_tc358764(bridge)->panel);
-
- if (ret < 0)
- dev_err(ctx->dev, "error disabling panel (%d)\n", ret);
-}
-
static void tc358764_post_disable(struct drm_bridge *bridge)
{
struct tc358764 *ctx = bridge_to_tc358764(bridge);
int ret;
- ret = drm_panel_unprepare(ctx->panel);
- if (ret < 0)
- dev_err(ctx->dev, "error unpreparing panel (%d)\n", ret);
tc358764_reset(ctx);
usleep_range(1, 15000);
ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
@@ -335,18 +323,6 @@ static void tc358764_pre_enable(struct drm_bridge *bridge)
ret = tc358764_init(ctx);
if (ret < 0)
dev_err(ctx->dev, "error initializing bridge (%d)\n", ret);
- ret = drm_panel_prepare(ctx->panel);
- if (ret < 0)
- dev_err(ctx->dev, "error preparing panel (%d)\n", ret);
-}
-
-static void tc358764_enable(struct drm_bridge *bridge)
-{
- struct tc358764 *ctx = bridge_to_tc358764(bridge);
- int ret = drm_panel_enable(ctx->panel);
-
- if (ret < 0)
- dev_err(ctx->dev, "error enabling panel (%d)\n", ret);
}
static int tc358764_attach(struct drm_bridge *bridge,
@@ -356,6 +332,11 @@ static int tc358764_attach(struct drm_bridge *bridge,
struct drm_device *drm = bridge->dev;
int ret;
+ ret = drm_bridge_attach(bridge->encoder, ctx->panel_bridge,
+ bridge, flags);
+ if (ret < 0)
+ return ret;
+
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
DRM_ERROR("Fix bridge driver to make connector optional!");
return -EINVAL;
@@ -373,32 +354,21 @@ static int tc358764_attach(struct drm_bridge *bridge,
drm_connector_helper_add(>connector,
_connector_helper_funcs);
drm_connector_attach_encoder(>connector, bridge->encoder);
- drm_panel_attach(ctx->panel, >connector);
ctx->connector.funcs->reset(>connector);
return 0;
}
-static void tc358764_detach(struct drm_bridge *bridge)
-{
- struct tc358764 *ctx = bridge_to_tc358764(bridge);
-
- drm_panel_detach(ctx->panel);
- ctx->panel = NULL;
-}
-
static const struct drm_bridge_funcs tc358764_bridge_funcs = {
- .disable = tc358764_disable,
.post_disable = tc358764_post_disable,
- .enable = tc358764_enable,
.pre_enable = tc358764_pre_enable,
.attach = tc358764_attach,
- .detach = tc358764_detach,
};
static int tc358764_parse_dt(struct tc358764 *ctx)
{
struct device *dev = ctx->dev;
+ struct drm_panel *panel;
int ret;
ctx->gpio_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
@@ -407,12 +377,13 @@ static int tc358764_parse_dt(struct tc358764 *ctx)
return PTR_ERR(ctx->gpio_reset);
}
- ret = drm_of_find_panel_or_bridge(ctx->dev->of_node, 1, 0, >panel,
- NULL);
- if (ret && ret != -EPROBE_DEFER)
- dev_err(dev, "cannot find panel (%d)\n", ret);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0, , NULL);
+ if (ret)
+
[PATCH v3 19/21] drm/bridge: nxp-ptn3460: add get_modes bridge operation
Add the get_modes() bridge operation to prepare for
use as a chained bridge.
Add helper function that is also used by the connector.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 52 ++--
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 0bd9f0e451b3..e253c185f94c 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -154,17 +154,13 @@ static void ptn3460_disable(struct drm_bridge *bridge)
gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
}
-static int ptn3460_get_modes(struct drm_connector *connector)
+static struct edid *ptn3460_get_edid(struct drm_bridge *bridge,
+struct drm_connector *connector)
{
- struct ptn3460_bridge *ptn_bridge;
- u8 *edid;
- int ret, num_modes = 0;
+ struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
bool power_off;
-
- ptn_bridge = connector_to_ptn3460(connector);
-
- if (ptn_bridge->edid)
- return drm_add_edid_modes(connector, ptn_bridge->edid);
+ u8 *edid;
+ int ret;
power_off = !ptn_bridge->enabled;
ptn3460_pre_enable(_bridge->bridge);
@@ -172,30 +168,46 @@ static int ptn3460_get_modes(struct drm_connector
*connector)
edid = kmalloc(EDID_LENGTH, GFP_KERNEL);
if (!edid) {
DRM_ERROR("Failed to allocate EDID\n");
- return 0;
+ return NULL;
}
ret = ptn3460_read_bytes(ptn_bridge, PTN3460_EDID_ADDR, edid,
- EDID_LENGTH);
+EDID_LENGTH);
if (ret) {
kfree(edid);
- goto out;
+ return NULL;
}
+ if (power_off)
+ ptn3460_disable(_bridge->bridge);
+
+ kfree(ptn_bridge->edid);
ptn_bridge->edid = (struct edid *)edid;
- drm_connector_update_edid_property(connector, ptn_bridge->edid);
- num_modes = drm_add_edid_modes(connector, ptn_bridge->edid);
+ return ptn_bridge->edid;
+}
-out:
- if (power_off)
- ptn3460_disable(_bridge->bridge);
+static int ptn3460_connector_get_modes(struct drm_connector *connector)
+{
+ struct ptn3460_bridge *ptn_bridge;
+ struct edid *edid;
+
+ ptn_bridge = connector_to_ptn3460(connector);
+
+ if (ptn_bridge->edid)
+ return drm_add_edid_modes(connector, ptn_bridge->edid);
+
+ edid = ptn3460_get_edid(_bridge->bridge, connector);
+ if (!edid)
+ return 0;
+
+ drm_connector_update_edid_property(connector, edid);
- return num_modes;
+ return drm_add_edid_modes(connector, edid);
}
static const struct drm_connector_helper_funcs ptn3460_connector_helper_funcs
= {
- .get_modes = ptn3460_get_modes,
+ .get_modes = ptn3460_connector_get_modes,
};
static const struct drm_connector_funcs ptn3460_connector_funcs = {
@@ -249,6 +261,7 @@ static const struct drm_bridge_funcs ptn3460_bridge_funcs =
{
.pre_enable = ptn3460_pre_enable,
.disable = ptn3460_disable,
.attach = ptn3460_bridge_attach,
+ .get_edid = ptn3460_get_edid,
};
static int ptn3460_probe(struct i2c_client *client,
@@ -304,6 +317,7 @@ static int ptn3460_probe(struct i2c_client *client,
}
ptn_bridge->bridge.funcs = _bridge_funcs;
+ ptn_bridge->bridge.ops = DRM_BRIDGE_OP_EDID;
ptn_bridge->bridge.of_node = dev->of_node;
drm_bridge_add(_bridge->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 16/21] drm/bridge: megachips: add get_edid bridge operation
To prepare for a chained bridge setup add support for the
get_edid bridge operation.
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../bridge/megachips-stdp-ge-b850v3-fw.c | 26 +--
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index 78a9afe8f063..5f06e18f0a61 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -131,21 +131,29 @@ static u8 *stdp2690_get_edid(struct i2c_client *client)
return NULL;
}
-static int ge_b850v3_lvds_get_modes(struct drm_connector *connector)
+static struct edid *ge_b850v3_lvds_get_edid(
+ struct drm_bridge *bridge, struct drm_connector *connector)
{
struct i2c_client *client;
- int num_modes = 0;
client = ge_b850v3_lvds_ptr->stdp2690_i2c;
kfree(ge_b850v3_lvds_ptr->edid);
ge_b850v3_lvds_ptr->edid = (struct edid *)stdp2690_get_edid(client);
- if (ge_b850v3_lvds_ptr->edid) {
- drm_connector_update_edid_property(connector,
- ge_b850v3_lvds_ptr->edid);
- num_modes = drm_add_edid_modes(connector,
- ge_b850v3_lvds_ptr->edid);
+ return ge_b850v3_lvds_ptr->edid;
+}
+
+static int ge_b850v3_lvds_get_modes(struct drm_connector *connector)
+{
+ struct edid *edid;
+ int num_modes = 0;
+
+ edid = ge_b850v3_lvds_get_edid(_b850v3_lvds_ptr->bridge, connector);
+
+ if (edid) {
+ drm_connector_update_edid_property(connector, edid);
+ num_modes = drm_add_edid_modes(connector, edid);
}
return num_modes;
@@ -270,6 +278,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
.attach = ge_b850v3_lvds_attach,
.detect = ge_b850v3_lvds_bridge_detect,
+ .get_edid = ge_b850v3_lvds_get_edid,
};
static int ge_b850v3_lvds_init(struct device *dev)
@@ -324,7 +333,8 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
*stdp4028_i2c,
/* drm bridge initialization */
ge_b850v3_lvds_ptr->bridge.funcs = _b850v3_lvds_funcs;
- ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT;
+ ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT |
+DRM_BRIDGE_OP_EDID;
ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
drm_bridge_add(_b850v3_lvds_ptr->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/21] drm/bridge: tc358767: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
The bridge driver assume the panel is optional.
The relevant tests are migrated over to check for the
pnale bridge to keep the same functionality.
Note: the bridge panel will use the connector type from the panel.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 57 +++
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index c2777b226c75..08d483664258 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -244,8 +244,8 @@ struct tc_data {
struct drm_dp_aux aux;
struct drm_bridge bridge;
+ struct drm_bridge *panel_bridge;
struct drm_connectorconnector;
- struct drm_panel*panel;
/* link settings */
struct tc_edp_link link;
@@ -1236,13 +1236,6 @@ static int tc_stream_disable(struct tc_data *tc)
return 0;
}
-static void tc_bridge_pre_enable(struct drm_bridge *bridge)
-{
- struct tc_data *tc = bridge_to_tc(bridge);
-
- drm_panel_prepare(tc->panel);
-}
-
static void tc_bridge_enable(struct drm_bridge *bridge)
{
struct tc_data *tc = bridge_to_tc(bridge);
@@ -1266,8 +1259,6 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
tc_main_link_disable(tc);
return;
}
-
- drm_panel_enable(tc->panel);
}
static void tc_bridge_disable(struct drm_bridge *bridge)
@@ -1275,8 +1266,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
struct tc_data *tc = bridge_to_tc(bridge);
int ret;
- drm_panel_disable(tc->panel);
-
ret = tc_stream_disable(tc);
if (ret < 0)
dev_err(tc->dev, "main link stream stop error: %d\n", ret);
@@ -1286,13 +1275,6 @@ static void tc_bridge_disable(struct drm_bridge *bridge)
dev_err(tc->dev, "main link disable error: %d\n", ret);
}
-static void tc_bridge_post_disable(struct drm_bridge *bridge)
-{
- struct tc_data *tc = bridge_to_tc(bridge);
-
- drm_panel_unprepare(tc->panel);
-}
-
static bool tc_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adj)
@@ -1348,9 +1330,11 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return 0;
}
- count = drm_panel_get_modes(tc->panel, connector);
- if (count > 0)
- return count;
+ if (tc->panel_bridge) {
+ count = drm_bridge_get_modes(tc->panel_bridge, connector);
+ if (count > 0)
+ return count;
+ }
edid = drm_get_edid(connector, >aux.ddc);
@@ -1378,7 +1362,7 @@ static enum drm_connector_status
tc_connector_detect(struct drm_connector *conne
int ret;
if (tc->hpd_pin < 0) {
- if (tc->panel)
+ if (tc->panel_bridge)
return connector_status_connected;
else
return connector_status_unknown;
@@ -1413,6 +1397,13 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
struct drm_device *drm = bridge->dev;
int ret;
+ if (tc->panel_bridge) {
+ ret = drm_bridge_attach(tc->bridge.encoder, tc->panel_bridge,
+ >bridge, flags);
+ if (ret < 0)
+ return ret;
+ }
+
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
DRM_ERROR("Fix bridge driver to make connector optional!");
return -EINVAL;
@@ -1421,7 +1412,7 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
/* Create DP/eDP connector */
drm_connector_helper_add(>connector, _connector_helper_funcs);
ret = drm_connector_init(drm, >connector, _connector_funcs,
-tc->panel ? DRM_MODE_CONNECTOR_eDP :
+tc->panel_bridge ? DRM_MODE_CONNECTOR_eDP :
DRM_MODE_CONNECTOR_DisplayPort);
if (ret)
return ret;
@@ -1435,9 +1426,6 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
DRM_CONNECTOR_POLL_DISCONNECT;
}
- if (tc->panel)
- drm_panel_attach(tc->panel, >connector);
-
drm_display_info_set_bus_formats(>connector.display_info,
_format, 1);
tc->connector.display_info.bus_flags =
@@ -1453,10 +1441,8 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.attach =
[PATCH v3 05/21] drm/bridge: tc358764: make connector creation optional
Make the connector creation optional to enable usage of the
tc358764 bridge with the DRM bridge connector helper.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358764.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index e1f052a4f53b..4477224e5079 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -337,10 +337,8 @@ static int tc358764_attach(struct drm_bridge *bridge,
if (ret < 0)
return ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
ctx->connector.polled = DRM_CONNECTOR_POLL_HPD;
ret = drm_connector_init(drm, >connector,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 20/21] drm/bridge: nxp-ptn3460: make connector creation optional
Make the connector creation optional to enable usage of the
nxp-ptn3460 bridge with the DRM bridge connector helper.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index e253c185f94c..6a65657087f9 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -229,10 +229,8 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
if (ret < 0)
return ret;
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
if (!bridge->encoder) {
DRM_ERROR("Parent encoder object not found");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/21] drm/panel: panel-simple: add default connector_type
All panels shall report a connector type. panel-simple has a lot of panels with no connector_type, and for these fall back to DPI as the default. Signed-off-by: Sam Ravnborg Cc: Thierry Reding Cc: Sam Ravnborg --- drivers/gpu/drm/panel/panel-simple.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 7b5d212215e0..b3ec965721b0 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -500,6 +500,7 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) struct panel_simple *panel; struct display_timing dt; struct device_node *ddc; + int connector_type; int err; panel = devm_kzalloc(dev, sizeof(*panel), GFP_KERNEL); @@ -566,8 +567,13 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc) desc->bpc != 8); } - drm_panel_init(>base, dev, _simple_funcs, - desc->connector_type); + /* Default DRM_MODE_CONNECTOR_DPI if no connector_type is set */ + if (desc->connector_type != 0) + connector_type = desc->connector_type; + else + connector_type = DRM_MODE_CONNECTOR_DPI; + + drm_panel_init(>base, dev, _simple_funcs, connector_type); err = drm_panel_of_backlight(>base); if (err) -- 2.25.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 21/21] drm/bridge: ti-sn65dsi86: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
Note: the bridge panel will use the connector type from the panel.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index 0f75bb2d7f56..ecf0693e3018 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -144,7 +144,7 @@ struct ti_sn_bridge {
struct device_node *host_node;
struct mipi_dsi_device *dsi;
struct clk *refclk;
- struct drm_panel*panel;
+ struct drm_bridge *panel_bridge;
struct gpio_desc*enable_gpio;
struct regulator_bulk_data supplies[SN_REGULATOR_SUPPLY_NUM];
int dp_lanes;
@@ -263,7 +263,7 @@ static int ti_sn_bridge_connector_get_modes(struct
drm_connector *connector)
{
struct ti_sn_bridge *pdata = connector_to_ti_sn_bridge(connector);
- return drm_panel_get_modes(pdata->panel, connector);
+ return drm_bridge_get_modes(pdata->panel_bridge, connector);
}
static enum drm_mode_status
@@ -395,9 +395,8 @@ static int ti_sn_bridge_attach(struct drm_bridge *bridge,
pdata->dsi = dsi;
/* attach panel to bridge */
- drm_panel_attach(pdata->panel, >connector);
-
- return 0;
+ return drm_bridge_attach(bridge->encoder, pdata->panel_bridge,
+bridge, flags);
err_dsi_attach:
mipi_dsi_device_unregister(dsi);
@@ -410,16 +409,12 @@ static void ti_sn_bridge_disable(struct drm_bridge
*bridge)
{
struct ti_sn_bridge *pdata = bridge_to_ti_sn_bridge(bridge);
- drm_panel_disable(pdata->panel);
-
/* disable video stream */
regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, VSTREAM_ENABLE, 0);
/* semi auto link training mode OFF */
regmap_write(pdata->regmap, SN_ML_TX_MODE_REG, 0);
/* disable DP PLL */
regmap_write(pdata->regmap, SN_PLL_ENABLE_REG, 0);
-
- drm_panel_unprepare(pdata->panel);
}
static u32 ti_sn_bridge_get_dsi_freq(struct ti_sn_bridge *pdata)
@@ -780,8 +775,6 @@ static void ti_sn_bridge_enable(struct drm_bridge *bridge)
/* enable video stream */
regmap_update_bits(pdata->regmap, SN_ENH_FRAME_REG, VSTREAM_ENABLE,
VSTREAM_ENABLE);
-
- drm_panel_enable(pdata->panel);
}
static void ti_sn_bridge_pre_enable(struct drm_bridge *bridge)
@@ -811,8 +804,6 @@ static void ti_sn_bridge_pre_enable(struct drm_bridge
*bridge)
*/
regmap_update_bits(pdata->regmap, SN_HPD_DISABLE_REG, HPD_DISABLE,
HPD_DISABLE);
-
- drm_panel_prepare(pdata->panel);
}
static void ti_sn_bridge_post_disable(struct drm_bridge *bridge)
@@ -1163,6 +1154,8 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct ti_sn_bridge *pdata;
+ struct drm_bridge *bridge;
+ struct drm_panel *panel;
int ret;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
@@ -1185,12 +1178,18 @@ static int ti_sn_bridge_probe(struct i2c_client *client,
pdata->dev = >dev;
ret = drm_of_find_panel_or_bridge(pdata->dev->of_node, 1, 0,
- >panel, NULL);
+ , NULL);
if (ret) {
DRM_ERROR("could not find any panel node\n");
return ret;
}
+ bridge = devm_drm_panel_bridge_add(pdata->dev, panel);
+ if (IS_ERR(bridge))
+ return PTR_ERR(bridge);
+
+ pdata->panel_bridge = bridge;
+
dev_set_drvdata(>dev, pdata);
pdata->enable_gpio = devm_gpiod_get(pdata->dev, "enable",
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/21] drm/bridge: parade-ps8622: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
Note: the bridge panel will use the connector type from the panel.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/parade-ps8622.c | 46 --
1 file changed, 13 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index d789ea2a7fb9..6ab6f60b9091 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -45,7 +45,7 @@ struct ps8622_bridge {
struct drm_connector connector;
struct i2c_client *client;
struct drm_bridge bridge;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
struct regulator *v12;
struct backlight_device *bl;
@@ -365,11 +365,6 @@ static void ps8622_pre_enable(struct drm_bridge *bridge)
DRM_ERROR("fails to enable ps8622->v12");
}
- if (drm_panel_prepare(ps8622->panel)) {
- DRM_ERROR("failed to prepare panel\n");
- return;
- }
-
gpiod_set_value(ps8622->gpio_slp, 1);
/*
@@ -399,24 +394,8 @@ static void ps8622_pre_enable(struct drm_bridge *bridge)
ps8622->enabled = true;
}
-static void ps8622_enable(struct drm_bridge *bridge)
-{
- struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
-
- if (drm_panel_enable(ps8622->panel)) {
- DRM_ERROR("failed to enable panel\n");
- return;
- }
-}
-
static void ps8622_disable(struct drm_bridge *bridge)
{
- struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
-
- if (drm_panel_disable(ps8622->panel)) {
- DRM_ERROR("failed to disable panel\n");
- return;
- }
msleep(PS8622_PWMO_END_T12_MS);
}
@@ -436,11 +415,6 @@ static void ps8622_post_disable(struct drm_bridge *bridge)
*/
gpiod_set_value(ps8622->gpio_slp, 0);
- if (drm_panel_unprepare(ps8622->panel)) {
- DRM_ERROR("failed to unprepare panel\n");
- return;
- }
-
if (ps8622->v12)
regulator_disable(ps8622->v12);
@@ -461,7 +435,7 @@ static int ps8622_get_modes(struct drm_connector *connector)
ps8622 = connector_to_ps8622(connector);
- return drm_panel_get_modes(ps8622->panel, connector);
+ return drm_bridge_get_modes(ps8622->panel_bridge, connector);
}
static const struct drm_connector_helper_funcs ps8622_connector_helper_funcs =
{
@@ -482,6 +456,9 @@ static int ps8622_attach(struct drm_bridge *bridge,
struct ps8622_bridge *ps8622 = bridge_to_ps8622(bridge);
int ret;
+ ret = drm_bridge_attach(ps8622->bridge.encoder, ps8622->panel_bridge,
+ >bridge, flags);
+
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
DRM_ERROR("Fix bridge driver to make connector optional!");
return -EINVAL;
@@ -505,9 +482,6 @@ static int ps8622_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(>connector,
bridge->encoder);
- if (ps8622->panel)
- drm_panel_attach(ps8622->panel, >connector);
-
drm_helper_hpd_irq_event(ps8622->connector.dev);
return ret;
@@ -515,7 +489,6 @@ static int ps8622_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ps8622_bridge_funcs = {
.pre_enable = ps8622_pre_enable,
- .enable = ps8622_enable,
.disable = ps8622_disable,
.post_disable = ps8622_post_disable,
.attach = ps8622_attach,
@@ -533,16 +506,23 @@ static int ps8622_probe(struct i2c_client *client,
{
struct device *dev = >dev;
struct ps8622_bridge *ps8622;
+ struct drm_bridge *pbridge;
+ struct drm_panel *panel;
int ret;
ps8622 = devm_kzalloc(dev, sizeof(*ps8622), GFP_KERNEL);
if (!ps8622)
return -ENOMEM;
- ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, >panel,
NULL);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, , NULL);
if (ret)
return ret;
+ pbridge = devm_drm_panel_bridge_add(dev, panel);
+ if (IS_ERR(pbridge))
+ return PTR_ERR(pbridge);
+
+ ps8622->panel_bridge = pbridge;
ps8622->client = client;
ps8622->v12 = devm_regulator_get(dev, "vdd12");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/21] drm/bridge: tc358764: drop drm_connector_(un)register
Drop drm_connector handling that is not needed:
- drm_dev_register() in the display controller driver takes
care of registering connectors.
So the call to drm_connector_register() call is not needed in the bridge
driver.
- Use of drm_connector_unregister() is only required for drivers that
explicit have called drm_dev_register.
- The reference counting using drm_connector_put() is likewise not needed.
Signed-off-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358764.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358764.c
b/drivers/gpu/drm/bridge/tc358764.c
index 5ac1430fab04..a277739fab58 100644
--- a/drivers/gpu/drm/bridge/tc358764.c
+++ b/drivers/gpu/drm/bridge/tc358764.c
@@ -375,7 +375,6 @@ static int tc358764_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(>connector, bridge->encoder);
drm_panel_attach(ctx->panel, >connector);
ctx->connector.funcs->reset(>connector);
- drm_connector_register(>connector);
return 0;
}
@@ -384,10 +383,8 @@ static void tc358764_detach(struct drm_bridge *bridge)
{
struct tc358764 *ctx = bridge_to_tc358764(bridge);
- drm_connector_unregister(>connector);
drm_panel_detach(ctx->panel);
ctx->panel = NULL;
- drm_connector_put(>connector);
}
static const struct drm_bridge_funcs tc358764_bridge_funcs = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/21] drm/bridge: support chained bridges + panel updates
This patch-set aims to make connector creation optional and prepare the bridge drivers for use in a chained setup. The objective is that all bridge drivers shall support a chained setup connector creation is moved to the display drivers. This is just one step on this path. Third iteration of this patchset covers several drivers, and a few panel adjustments. The general approach for the bridge drivers: - Introduce drm_panel_brigde - Introduce bridge operations - Make connector creation optional v3: - Rebase on top of drm-misc-next - Address kbuild test robot feedback v2: - Updated bus_flags for boe,hv070wsa-100 - Collected r-b, but did not apply patches yet - On the panel side the panel-simple driver gained a default connector type for all the dumb panels that do not include so in their description. With this change panels always provide a connector type, and we have the potential to drop most uses of devm_drm_panel_bridge_add_typed(). - Added conversion of a few more bridge drivers Patches can build but no run-time testing. So both test and review feedback appreciated! Sam Sam Ravnborg (21): drm/panel: add connector type to boe,hv070wsa-100 panel drm/panel: panel-simple: add default connector_type drm/bridge: tc358764: drop drm_connector_(un)register drm/bridge: tc358764: add drm_panel_bridge support drm/bridge: tc358764: make connector creation optional drm/bridge: tc358767: add drm_panel_bridge support drm/bridge: tc358767: add detect bridge operation drm/bridge: tc358767: add get_edid bride operation drm/bridge: tc358767: make connector creation optional drm/bridge: ti-tpd12s015: make connector creation optional drm/bridge: parade-ps8622: add drm_panel_bridge support drm/bridge: parade-ps8622: make connector creation optional drm/bridge: megachips: add helper to create connector drm/bridge: megachips: get drm_device from bridge drm/bridge: megachips: enable detect bridge operation drm/bridge: megachips: add get_edid bridge operation drm/bridge: megachips: make connector creation optional drm/bridge: nxp-ptn3460: add drm_panel_bridge support drm/bridge: nxp-ptn3460: add get_modes bridge operation drm/bridge: nxp-ptn3460: make connector creation optional drm/bridge: ti-sn65dsi86: add drm_panel_bridge support .../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 92 +++--- drivers/gpu/drm/bridge/nxp-ptn3460.c | 107 + drivers/gpu/drm/bridge/parade-ps8622.c | 54 +++ drivers/gpu/drm/bridge/tc358764.c | 66 +++-- drivers/gpu/drm/bridge/tc358767.c | 98 +++ drivers/gpu/drm/bridge/ti-sn65dsi86.c | 27 +++--- drivers/gpu/drm/bridge/ti-tpd12s015.c | 3 - drivers/gpu/drm/panel/panel-simple.c | 13 ++- 8 files changed, 216 insertions(+), 244 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/21] drm/bridge: parade-ps8622: make connector creation optional
Make the connector creation optional to enable usage of the
parade-ps8622 bridge with the DRM bridge connector helper.
This change moves drm_helper_hpd_irq_event() call in the attach
function up before the connector creation.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/parade-ps8622.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/bridge/parade-ps8622.c
b/drivers/gpu/drm/bridge/parade-ps8622.c
index 6ab6f60b9091..54aa5270d2c9 100644
--- a/drivers/gpu/drm/bridge/parade-ps8622.c
+++ b/drivers/gpu/drm/bridge/parade-ps8622.c
@@ -459,10 +459,8 @@ static int ps8622_attach(struct drm_bridge *bridge,
ret = drm_bridge_attach(ps8622->bridge.encoder, ps8622->panel_bridge,
>bridge, flags);
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
if (!bridge->encoder) {
DRM_ERROR("Parent encoder object not found");
@@ -482,7 +480,7 @@ static int ps8622_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(>connector,
bridge->encoder);
- drm_helper_hpd_irq_event(ps8622->connector.dev);
+ drm_helper_hpd_irq_event(ps8622->bridge.dev);
return ret;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 08/21] drm/bridge: tc358767: add get_edid bride operation
Prepare for chained bridge with the addition of
get_edid support.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 85973ae728db..fb9d57967b2c 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1317,6 +1317,20 @@ static void tc_bridge_mode_set(struct drm_bridge *bridge,
tc->mode = *mode;
}
+static struct edid *tc_get_edid(struct drm_bridge *bridge,
+ struct drm_connector *connector)
+{
+ struct tc_data *tc = bridge_to_tc(bridge);
+ struct edid *edid;
+
+ edid = drm_get_edid(connector, >aux.ddc);
+
+ kfree(tc->edid);
+ tc->edid = edid;
+
+ return edid;
+}
+
static int tc_connector_get_modes(struct drm_connector *connector)
{
struct tc_data *tc = connector_to_tc(connector);
@@ -1336,12 +1350,7 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return count;
}
- edid = drm_get_edid(connector, >aux.ddc);
-
- kfree(tc->edid);
- tc->edid = edid;
- if (!edid)
- return 0;
+ edid = tc_get_edid(>bridge, connector);
drm_connector_update_edid_property(connector, edid);
count = drm_add_edid_modes(connector, edid);
@@ -1452,6 +1461,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.disable = tc_bridge_disable,
.mode_fixup = tc_bridge_mode_fixup,
.detect = tc_bridge_detect,
+ .get_edid = tc_get_edid,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
@@ -1685,7 +1695,7 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return ret;
tc->bridge.funcs = _bridge_funcs;
- tc->bridge.ops = DRM_BRIDGE_OP_DETECT;
+ tc->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID;
tc->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 01/21] drm/panel: add connector type to boe, hv070wsa-100 panel
The boe,hv070wsa-100 panel is a LVDS panel.
Fix connector type to reflect this.
With this change users of this panel do not have to specify the
connector type.
v3:
- Drop PIXDATA bus_flag, not relevant
v2:
- Add .bus_format (Laurent)
- Add .bus_flags
Signed-off-by: Sam Ravnborg
Cc: Laurent Pinchart
Cc: Thierry Reding
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 4f0ec5e5b0aa..7b5d212215e0 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1188,6 +1188,9 @@ static const struct panel_desc boe_hv070wsa = {
.width = 154,
.height = 90,
},
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
};
static const struct drm_display_mode boe_nv101wxmn51_modes[] = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/21] drm/bridge: tc358767: make connector creation optional
Display drivers are in the new model expected to create
the connector using drm_bridge_connector_init().
Allow users of this bridge driver to support the new
model by introducing support for optional connector creation.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index fb9d57967b2c..2eb00d39f619 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1421,8 +1421,7 @@ static int tc_bridge_attach(struct drm_bridge *bridge,
}
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
+ return 0;
}
/* Create DP/eDP connector */
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/21] drm/bridge: tc358767: add detect bridge operation
Prepare the bridge driver for chained operation by adding
support for the detect operation.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/tc358767.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridge/tc358767.c
index 08d483664258..85973ae728db 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1353,10 +1353,9 @@ static const struct drm_connector_helper_funcs
tc_connector_helper_funcs = {
.get_modes = tc_connector_get_modes,
};
-static enum drm_connector_status tc_connector_detect(struct drm_connector
*connector,
-bool force)
+static enum drm_connector_status tc_bridge_detect(struct drm_bridge *bridge)
{
- struct tc_data *tc = connector_to_tc(connector);
+ struct tc_data *tc = bridge_to_tc(bridge);
bool conn;
u32 val;
int ret;
@@ -1380,6 +1379,14 @@ static enum drm_connector_status
tc_connector_detect(struct drm_connector *conne
return connector_status_disconnected;
}
+static enum drm_connector_status
+tc_connector_detect(struct drm_connector *connector, bool force)
+{
+ struct tc_data *tc = connector_to_tc(connector);
+
+ return tc_bridge_detect(>bridge);
+}
+
static const struct drm_connector_funcs tc_connector_funcs = {
.detect = tc_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -1444,6 +1451,7 @@ static const struct drm_bridge_funcs tc_bridge_funcs = {
.enable = tc_bridge_enable,
.disable = tc_bridge_disable,
.mode_fixup = tc_bridge_mode_fixup,
+ .detect = tc_bridge_detect,
};
static bool tc_readable_reg(struct device *dev, unsigned int reg)
@@ -1677,6 +1685,8 @@ static int tc_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return ret;
tc->bridge.funcs = _bridge_funcs;
+ tc->bridge.ops = DRM_BRIDGE_OP_DETECT;
+
tc->bridge.of_node = dev->of_node;
drm_bridge_add(>bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 15/21] drm/bridge: megachips: enable detect bridge operation
To prepare for use in a chained bridge setup enable the
detect operation.
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index cf1dfbc88acf..78a9afe8f063 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -163,8 +163,8 @@ drm_connector_helper_funcs
ge_b850v3_lvds_connector_helper_funcs = {
.mode_valid = ge_b850v3_lvds_mode_valid,
};
-static enum drm_connector_status ge_b850v3_lvds_detect(
- struct drm_connector *connector, bool force)
+static enum drm_connector_status ge_b850v3_lvds_bridge_detect(
+ struct drm_bridge *bridge)
{
struct i2c_client *stdp4028_i2c =
ge_b850v3_lvds_ptr->stdp4028_i2c;
@@ -182,6 +182,12 @@ static enum drm_connector_status ge_b850v3_lvds_detect(
return connector_status_unknown;
}
+static enum drm_connector_status ge_b850v3_lvds_detect(
+ struct drm_connector *connector, bool force)
+{
+ return ge_b850v3_lvds_bridge_detect(_b850v3_lvds_ptr->bridge);
+}
+
static const struct drm_connector_funcs ge_b850v3_lvds_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = ge_b850v3_lvds_detect,
@@ -263,6 +269,7 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
.attach = ge_b850v3_lvds_attach,
+ .detect = ge_b850v3_lvds_bridge_detect,
};
static int ge_b850v3_lvds_init(struct device *dev)
@@ -317,6 +324,7 @@ static int stdp4028_ge_b850v3_fw_probe(struct i2c_client
*stdp4028_i2c,
/* drm bridge initialization */
ge_b850v3_lvds_ptr->bridge.funcs = _b850v3_lvds_funcs;
+ ge_b850v3_lvds_ptr->bridge.ops = DRM_BRIDGE_OP_DETECT;
ge_b850v3_lvds_ptr->bridge.of_node = dev->of_node;
drm_bridge_add(_b850v3_lvds_ptr->bridge);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 18/21] drm/bridge: nxp-ptn3460: add drm_panel_bridge support
Prepare the bridge driver for use in a chained setup by
replacing direct use of drm_panel with drm_panel_bridge support.
Note: the bridge panel will use the connector type from the panel.
Signed-off-by: Sam Ravnborg
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
drivers/gpu/drm/bridge/nxp-ptn3460.c | 51
1 file changed, 14 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index 438e566ce0a4..0bd9f0e451b3 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -30,7 +30,7 @@ struct ptn3460_bridge {
struct i2c_client *client;
struct drm_bridge bridge;
struct edid *edid;
- struct drm_panel *panel;
+ struct drm_bridge *panel_bridge;
struct gpio_desc *gpio_pd_n;
struct gpio_desc *gpio_rst_n;
u32 edid_emulation;
@@ -127,11 +127,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
usleep_range(10, 20);
gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
- if (drm_panel_prepare(ptn_bridge->panel)) {
- DRM_ERROR("failed to prepare panel\n");
- return;
- }
-
/*
* There's a bug in the PTN chip where it falsely asserts hotplug before
* it is fully functional. We're forced to wait for the maximum start up
@@ -146,16 +141,6 @@ static void ptn3460_pre_enable(struct drm_bridge *bridge)
ptn_bridge->enabled = true;
}
-static void ptn3460_enable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- if (drm_panel_enable(ptn_bridge->panel)) {
- DRM_ERROR("failed to enable panel\n");
- return;
- }
-}
-
static void ptn3460_disable(struct drm_bridge *bridge)
{
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
@@ -165,25 +150,10 @@ static void ptn3460_disable(struct drm_bridge *bridge)
ptn_bridge->enabled = false;
- if (drm_panel_disable(ptn_bridge->panel)) {
- DRM_ERROR("failed to disable panel\n");
- return;
- }
-
gpiod_set_value(ptn_bridge->gpio_rst_n, 1);
gpiod_set_value(ptn_bridge->gpio_pd_n, 0);
}
-static void ptn3460_post_disable(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- if (drm_panel_unprepare(ptn_bridge->panel)) {
- DRM_ERROR("failed to unprepare panel\n");
- return;
- }
-}
-
static int ptn3460_get_modes(struct drm_connector *connector)
{
struct ptn3460_bridge *ptn_bridge;
@@ -242,6 +212,11 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
int ret;
+ ret = drm_bridge_attach(bridge->encoder, ptn_bridge->panel_bridge,
+ bridge, flags);
+ if (ret < 0)
+ return ret;
+
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
DRM_ERROR("Fix bridge driver to make connector optional!");
return -EINVAL;
@@ -265,9 +240,6 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
drm_connector_attach_encoder(_bridge->connector,
bridge->encoder);
- if (ptn_bridge->panel)
- drm_panel_attach(ptn_bridge->panel, _bridge->connector);
-
drm_helper_hpd_irq_event(ptn_bridge->connector.dev);
return ret;
@@ -275,9 +247,7 @@ static int ptn3460_bridge_attach(struct drm_bridge *bridge,
static const struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
- .enable = ptn3460_enable,
.disable = ptn3460_disable,
- .post_disable = ptn3460_post_disable,
.attach = ptn3460_bridge_attach,
};
@@ -286,6 +256,8 @@ static int ptn3460_probe(struct i2c_client *client,
{
struct device *dev = >dev;
struct ptn3460_bridge *ptn_bridge;
+ struct drm_bridge *pbridge;
+ struct drm_panel *panel;
int ret;
ptn_bridge = devm_kzalloc(dev, sizeof(*ptn_bridge), GFP_KERNEL);
@@ -293,10 +265,15 @@ static int ptn3460_probe(struct i2c_client *client,
return -ENOMEM;
}
- ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0,
_bridge->panel, NULL);
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 0, 0, , NULL);
if (ret)
return ret;
+ pbridge = devm_drm_panel_bridge_add(dev, panel);
+ if (IS_ERR(pbridge))
+ return PTR_ERR(pbridge);
+
+ ptn_bridge->panel_bridge = pbridge;
ptn_bridge->client = client;
ptn_bridge->gpio_pd_n = devm_gpiod_get(>dev, "powerdown",
--
2.25.1
___
dri-devel
[PATCH v3 17/21] drm/bridge: megachips: make connector creation optional
Make the connector creation optional to enable usage of the
megachips-stdp-ge-b850v3-fw bridge with the DRM bridge connector helper.
Signed-off-by: Sam Ravnborg
Cc: Peter Senna Tschudin
Cc: Martin Donnelly
Cc: Martyn Welch
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
---
.../drm/bridge/megachips-stdp-ge-b850v3-fw.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
index 5f06e18f0a61..991417ab35b6 100644
--- a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
+++ b/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
@@ -251,16 +251,6 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
{
struct i2c_client *stdp4028_i2c
= ge_b850v3_lvds_ptr->stdp4028_i2c;
- int ret;
-
- if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
- DRM_ERROR("Fix bridge driver to make connector optional!");
- return -EINVAL;
- }
-
- ret = ge_b850v3_lvds_create_connector(bridge);
- if (ret)
- return ret;
/* Configures the bridge to re-enable interrupts after each ack. */
i2c_smbus_write_word_data(stdp4028_i2c,
@@ -272,7 +262,10 @@ static int ge_b850v3_lvds_attach(struct drm_bridge *bridge,
STDP4028_DPTX_IRQ_EN_REG,
STDP4028_DPTX_IRQ_CONFIG);
- return 0;
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return 0;
+
+ return ge_b850v3_lvds_create_connector(bridge);
}
static const struct drm_bridge_funcs ge_b850v3_lvds_funcs = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/20] 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 Reviewed-by: Emil Velikov 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 8f2005a6f8a9..c6ac4cbb9ddb 100644 --- a/include/linux/backlight.h +++ b/include/linux/backlight.h @@ -417,23 +417,26 @@ static inline bool backlight_is_blank(const 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); +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_name(const char *name); -extern int backlight_device_set_brightness(struct backlight_device *bd, unsigned long brightness); +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 v4 08/20] 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
Reviewed-by: Emil Velikov
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 = {
-
[PATCH v4 06/20] 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
Reviewed-by: Emil Velikov
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 7654fe5f1589..7d6cb61e10f5 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;
@@ -361,6 +365,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 v4 16/20] backlight: jornada720_bl: introduce backlight_is_blank()
Use the backlight_is_blank() helper to simplify the code a bit.
This add support for fb_blank as a side-effect.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/jornada720_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/jornada720_bl.c
b/drivers/video/backlight/jornada720_bl.c
index f0385f9cf9da..996f7ba3b373 100644
--- a/drivers/video/backlight/jornada720_bl.c
+++ b/drivers/video/backlight/jornada720_bl.c
@@ -54,7 +54,7 @@ static int jornada_bl_update_status(struct backlight_device
*bd)
jornada_ssp_start();
/* If backlight is off then really turn it off */
- if ((bd->props.power != FB_BLANK_UNBLANK) || (bd->props.fb_blank !=
FB_BLANK_UNBLANK)) {
+ if (backlight_is_blank(bd)) {
ret = jornada_ssp_byte(BRIGHTNESSOFF);
if (ret != TXDUMMY) {
dev_info(>dev, "brightness off timeout\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 15/20] backlight: gpio_backlight: simplify update_status()
Introduce the use of backlight_get_brightness() to simplify
the update_status() operation.
With the simpler implementation drop the gpio_backlight_get_next_brightness()
helper as it was now a one-liner.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/gpio_backlight.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/video/backlight/gpio_backlight.c
b/drivers/video/backlight/gpio_backlight.c
index 75409ddfba3e..6f78d928f054 100644
--- a/drivers/video/backlight/gpio_backlight.c
+++ b/drivers/video/backlight/gpio_backlight.c
@@ -21,24 +21,11 @@ struct gpio_backlight {
struct gpio_desc *gpiod;
};
-static int gpio_backlight_get_next_brightness(struct backlight_device *bl)
-{
- int brightness = bl->props.brightness;
-
- if (bl->props.power != FB_BLANK_UNBLANK ||
- bl->props.fb_blank != FB_BLANK_UNBLANK ||
- bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
- brightness = 0;
-
- return brightness;
-}
-
static int gpio_backlight_update_status(struct backlight_device *bl)
{
struct gpio_backlight *gbl = bl_get_data(bl);
- int brightness = gpio_backlight_get_next_brightness(bl);
- gpiod_set_value_cansleep(gbl->gpiod, brightness);
+ gpiod_set_value_cansleep(gbl->gpiod, backlight_get_brightness(bl));
return 0;
}
@@ -108,7 +95,7 @@ static int gpio_backlight_probe(struct platform_device *pdev)
bl->props.brightness = 1;
- init_brightness = gpio_backlight_get_next_brightness(bl);
+ init_brightness = backlight_get_brightness(bl);
ret = gpiod_direction_output(gbl->gpiod, init_brightness);
if (ret) {
dev_err(dev, "failed to set initial brightness\n");
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 19/20] backlight: make of_find_backlight static
There are no external users of of_find_backlight,
as they have all changed to use the managed version.
Make of_find_backlight static to prevent new external users.
v3:
- Move doc for devm_of_find_backlight out of this patch
v2:
- Editorial corrections (Daniel)
- Returns => RETURNS (Daniel)
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 18 +-
include/linux/backlight.h | 6 --
2 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 099023771ab1..06f4da3c58e1 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -672,22 +672,7 @@ struct backlight_device *of_find_backlight_by_node(struct
device_node *node)
EXPORT_SYMBOL(of_find_backlight_by_node);
#endif
-/**
- * of_find_backlight - Get backlight device
- * @dev: Device
- *
- * This function looks for a property named 'backlight' on the DT node
- * connected to @dev and looks up the backlight device.
- *
- * Call backlight_put() to drop the reference on the backlight device.
- *
- * Returns:
- * A pointer to the backlight device if found.
- * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
- * device is found.
- * NULL if there's no backlight property.
- */
-struct backlight_device *of_find_backlight(struct device *dev)
+static struct backlight_device *of_find_backlight(struct device *dev)
{
struct backlight_device *bd = NULL;
struct device_node *np;
@@ -713,7 +698,6 @@ struct backlight_device *of_find_backlight(struct device
*dev)
return bd;
}
-EXPORT_SYMBOL(of_find_backlight);
static void devm_backlight_release(void *data)
{
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index f3b484c99789..8b43fd90d84a 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -477,14 +477,8 @@ of_find_backlight_by_node(struct device_node *node)
#endif
#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
-struct backlight_device *of_find_backlight(struct device *dev);
struct backlight_device *devm_of_find_backlight(struct device *dev);
#else
-static inline struct backlight_device *of_find_backlight(struct device *dev)
-{
- return NULL;
-}
-
static inline struct backlight_device *
devm_of_find_backlight(struct device *dev)
{
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/20] 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.
v4:
- Include updated devm_of_find_backlight doc
(was accidently included in a later patch)
v3:
- Updated a few editorial details (Daniel)
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
Reviewed-by: Daniel Thompson
Reviewed-by: Emil Velikov
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 143 +++-
1 file changed, 100 insertions(+), 43 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 7e249aa90b0e..db8717581ec5 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -22,6 +22,47 @@
#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 must 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 +81,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 +367,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 +388,7 @@ void
[PATCH v4 20/20] backlight: make of_find_backlight_by_node() static
There are no external users of of_find_backlight_by_node().
Make it static so we keep it that way.
v2:
- drop EXPORT of of_find_backlight_by_node
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 23 +--
include/linux/backlight.h | 10 --
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 06f4da3c58e1..ff84e6607486 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -649,19 +649,9 @@ static int of_parent_match(struct device *dev, const void
*data)
return dev->parent && dev->parent->of_node == data;
}
-/**
- * of_find_backlight_by_node() - find backlight device by device-tree node
- * @node: device-tree node of the backlight device
- *
- * Returns a pointer to the backlight device corresponding to the given DT
- * node or NULL if no such backlight device exists or if the device hasn't
- * been probed yet.
- *
- * This function obtains a reference on the backlight device and it is the
- * caller's responsibility to drop the reference by calling put_device() on
- * the backlight device's .dev field.
- */
-struct backlight_device *of_find_backlight_by_node(struct device_node *node)
+/* Find backlight device by device-tree node */
+static struct backlight_device *
+of_find_backlight_by_node(struct device_node *node)
{
struct device *dev;
@@ -669,7 +659,12 @@ struct backlight_device *of_find_backlight_by_node(struct
device_node *node)
return dev ? to_backlight_device(dev) : NULL;
}
-EXPORT_SYMBOL(of_find_backlight_by_node);
+#else
+static struct backlight_device *
+of_find_backlight_by_node(struct device_node *node)
+{
+ return NULL;
+}
#endif
static struct backlight_device *of_find_backlight(struct device *dev)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 8b43fd90d84a..fa443899b4ee 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -466,16 +466,6 @@ static inline void * bl_get_data(struct backlight_device
*bl_dev)
return dev_get_drvdata(_dev->dev);
}
-#ifdef CONFIG_OF
-struct backlight_device *of_find_backlight_by_node(struct device_node *node);
-#else
-static inline struct backlight_device *
-of_find_backlight_by_node(struct device_node *node)
-{
- return NULL;
-}
-#endif
-
#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
struct backlight_device *devm_of_find_backlight(struct device *dev);
#else
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 17/20] backlight: use backligt_get_brightness()
Introduce the backlight_get_brightness() helper in all
video/backlight/* drivers.
This simplifies the code and align the implementation of the
update_status() operation across the different backlight drivers.
Some of the drivers gains a little extra functionality by the change
as they now respect the fb_blank() ioctl.
Signed-off-by: Sam Ravnborg
---
drivers/video/backlight/88pm860x_bl.c | 13 +
drivers/video/backlight/adp5520_bl.c | 10 +-
drivers/video/backlight/adp8860_bl.c | 10 +-
drivers/video/backlight/adp8870_bl.c | 10 +-
drivers/video/backlight/bd6107.c | 7 +--
drivers/video/backlight/corgi_lcd.c | 8 +---
drivers/video/backlight/da903x_bl.c | 13 +
drivers/video/backlight/ep93xx_bl.c | 8 +---
drivers/video/backlight/hp680_bl.c| 6 +-
drivers/video/backlight/kb3886_bl.c | 6 +-
drivers/video/backlight/led_bl.c | 7 +--
drivers/video/backlight/lm3533_bl.c | 8 +---
drivers/video/backlight/locomolcd.c | 6 +-
drivers/video/backlight/lv5207lp.c| 7 +--
drivers/video/backlight/max8925_bl.c | 13 +
drivers/video/backlight/pwm_bl.c | 7 +--
drivers/video/backlight/qcom-wled.c | 7 +--
drivers/video/backlight/tps65217_bl.c | 10 +-
drivers/video/backlight/wm831x_bl.c | 13 +
19 files changed, 19 insertions(+), 150 deletions(-)
diff --git a/drivers/video/backlight/88pm860x_bl.c
b/drivers/video/backlight/88pm860x_bl.c
index 20d96a5ac384..25e409bbb1a2 100644
--- a/drivers/video/backlight/88pm860x_bl.c
+++ b/drivers/video/backlight/88pm860x_bl.c
@@ -121,18 +121,7 @@ static int pm860x_backlight_set(struct backlight_device
*bl, int brightness)
static int pm860x_backlight_update_status(struct backlight_device *bl)
{
- int brightness = bl->props.brightness;
-
- if (bl->props.power != FB_BLANK_UNBLANK)
- brightness = 0;
-
- if (bl->props.fb_blank != FB_BLANK_UNBLANK)
- brightness = 0;
-
- if (bl->props.state & BL_CORE_SUSPENDED)
- brightness = 0;
-
- return pm860x_backlight_set(bl, brightness);
+ return pm860x_backlight_set(bl, backlight_get_brightness(bl));
}
static int pm860x_backlight_get_brightness(struct backlight_device *bl)
diff --git a/drivers/video/backlight/adp5520_bl.c
b/drivers/video/backlight/adp5520_bl.c
index 0f63f76723a5..686988c3df3a 100644
--- a/drivers/video/backlight/adp5520_bl.c
+++ b/drivers/video/backlight/adp5520_bl.c
@@ -65,15 +65,7 @@ static int adp5520_bl_set(struct backlight_device *bl, int
brightness)
static int adp5520_bl_update_status(struct backlight_device *bl)
{
- int brightness = bl->props.brightness;
-
- if (bl->props.power != FB_BLANK_UNBLANK)
- brightness = 0;
-
- if (bl->props.fb_blank != FB_BLANK_UNBLANK)
- brightness = 0;
-
- return adp5520_bl_set(bl, brightness);
+ return adp5520_bl_set(bl, backlight_get_brightness(bl));
}
static int adp5520_bl_get_brightness(struct backlight_device *bl)
diff --git a/drivers/video/backlight/adp8860_bl.c
b/drivers/video/backlight/adp8860_bl.c
index 19968104fc47..ddc7f5f0401f 100644
--- a/drivers/video/backlight/adp8860_bl.c
+++ b/drivers/video/backlight/adp8860_bl.c
@@ -361,15 +361,7 @@ static int adp8860_bl_set(struct backlight_device *bl, int
brightness)
static int adp8860_bl_update_status(struct backlight_device *bl)
{
- int brightness = bl->props.brightness;
-
- if (bl->props.power != FB_BLANK_UNBLANK)
- brightness = 0;
-
- if (bl->props.fb_blank != FB_BLANK_UNBLANK)
- brightness = 0;
-
- return adp8860_bl_set(bl, brightness);
+ return adp8860_bl_set(bl, backlight_get_brightness(bl));
}
static int adp8860_bl_get_brightness(struct backlight_device *bl)
diff --git a/drivers/video/backlight/adp8870_bl.c
b/drivers/video/backlight/adp8870_bl.c
index 4c0032010cfe..8b5213a39527 100644
--- a/drivers/video/backlight/adp8870_bl.c
+++ b/drivers/video/backlight/adp8870_bl.c
@@ -399,15 +399,7 @@ static int adp8870_bl_set(struct backlight_device *bl, int
brightness)
static int adp8870_bl_update_status(struct backlight_device *bl)
{
- int brightness = bl->props.brightness;
-
- if (bl->props.power != FB_BLANK_UNBLANK)
- brightness = 0;
-
- if (bl->props.fb_blank != FB_BLANK_UNBLANK)
- brightness = 0;
-
- return adp8870_bl_set(bl, brightness);
+ return adp8870_bl_set(bl, backlight_get_brightness(bl));
}
static int adp8870_bl_get_brightness(struct backlight_device *bl)
diff --git a/drivers/video/backlight/bd6107.c b/drivers/video/backlight/bd6107.c
index d5d5fb457e78..515184fbe33a 100644
--- a/drivers/video/backlight/bd6107.c
+++ b/drivers/video/backlight/bd6107.c
@@ -82,12 +82,7 @@ static int bd6107_write(struct bd6107 *bd, u8 reg, u8 data)
static int
[PATCH v4 07/20] 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
Reviewed-by: Emil Velikov
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 72 +++
1 file changed, 72 insertions(+)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 7d6cb61e10f5..0f425b32e6be 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,
};
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 11/20] 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 Reviewed-by: Emil Velikov 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 v4 12/20] backlight: introduce backlight_get_brightness()
Based on an idea from Emil Velikov
add a helper that checks backlight_is_blank() and return 0 as brightness
if display is blank or the property value if not.
This allows us to simplify the update_status() implementation
in most of the backlight drivers.
Signed-off-by: Sam Ravnborg
Cc: Emil Velikov
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 c6ac4cbb9ddb..38db67588b16 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -417,6 +417,25 @@ static inline bool backlight_is_blank(const struct
backlight_device *bd)
bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
}
+/**
+ * backlight_get_brightness - Returns the current brightness value
+ * @bd: the backlight device
+ *
+ * Returns the current brightness value, taking in consideration the current
+ * state. If backlight_is_blank() returns true then return 0 as brightness
+ * otherwise return the current brightness property value.
+ *
+ * Backlight drivers are expected to use this function in their update_status()
+ * operation to get the brightness value.
+ */
+static inline int backlight_get_brightness(const struct backlight_device *bd)
+{
+ if (backlight_is_blank(bd))
+ return 0;
+ else
+ return bd->props.brightness;
+}
+
struct backlight_device *
backlight_device_register(const char *name, struct device *dev, void *devdata,
const struct backlight_ops *ops,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 14/20] backlight: cr_bllcd: introduce backlight_is_blank()
The cr_bllcd uses the FB_BLANK states as brightness.
This results in brightness value equals 0 that turn on
the display and 4 that turn off the display.
Simplify the logic but keep current behaviour
as userspace may expect brightness set to 0 to turn on the display.
Signed-off-by: Sam Ravnborg
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/cr_bllcd.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/video/backlight/cr_bllcd.c
b/drivers/video/backlight/cr_bllcd.c
index 4624b7b7c6a6..edca5fee9689 100644
--- a/drivers/video/backlight/cr_bllcd.c
+++ b/drivers/video/backlight/cr_bllcd.c
@@ -63,22 +63,16 @@ static int cr_backlight_set_intensity(struct
backlight_device *bd)
u32 addr = gpio_bar + CRVML_PANEL_PORT;
u32 cur = inl(addr);
- if (bd->props.power == FB_BLANK_UNBLANK)
- intensity = FB_BLANK_UNBLANK;
- if (bd->props.fb_blank == FB_BLANK_UNBLANK)
- intensity = FB_BLANK_UNBLANK;
- if (bd->props.power == FB_BLANK_POWERDOWN)
- intensity = FB_BLANK_POWERDOWN;
- if (bd->props.fb_blank == FB_BLANK_POWERDOWN)
+ if (backlight_is_blank(bd))
intensity = FB_BLANK_POWERDOWN;
- if (intensity == FB_BLANK_UNBLANK) { /* FULL ON */
+ if (intensity != FB_BLANK_POWERDOWN) { /* FULL ON */
cur &= ~CRVML_BACKLIGHT_OFF;
outl(cur, addr);
- } else if (intensity == FB_BLANK_POWERDOWN) { /* OFF */
+ } else { /* OFF */
cur |= CRVML_BACKLIGHT_OFF;
outl(cur, addr);
- } /* anything else, don't bother */
+ }
return 0;
}
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 13/20] backlight: as3711_bl: simplify update_status
Replaces the open-coded checks of the state, with the
backlight_get_brightness() helper. This increases readability
of the code and align 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.
v2:
- Use backlight_get_brightness()
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 | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/video/backlight/as3711_bl.c
b/drivers/video/backlight/as3711_bl.c
index 33f0f0f2e8b3..3b60019cdc2b 100644
--- a/drivers/video/backlight/as3711_bl.c
+++ b/drivers/video/backlight/as3711_bl.c
@@ -104,17 +104,10 @@ static int as3711_bl_update_status(struct
backlight_device *bl)
struct as3711_bl_data *data = bl_get_data(bl);
struct as3711_bl_supply *supply = to_supply(data);
struct as3711 *as3711 = supply->as3711;
- int brightness = bl->props.brightness;
+ int 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))
- brightness = 0;
+ brightness = backlight_get_brightness(bl);
if (data->type == AS3711_BL_SU1) {
ret = as3711_set_brightness_v(as3711, brightness,
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 18/20] backlight: drop backlight_put()
There are no external users of backlight_put().
Drop it and open code the two users in backlight.c.
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
drivers/video/backlight/backlight.c | 7 +--
include/linux/backlight.h | 10 --
2 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index db8717581ec5..099023771ab1 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -717,7 +717,10 @@ EXPORT_SYMBOL(of_find_backlight);
static void devm_backlight_release(void *data)
{
- backlight_put(data);
+ struct backlight_device *bd = data;
+
+ if (bd)
+ put_device(>dev);
}
/**
@@ -745,7 +748,7 @@ struct backlight_device *devm_of_find_backlight(struct
device *dev)
return bd;
ret = devm_add_action(dev, devm_backlight_release, bd);
if (ret) {
- backlight_put(bd);
+ put_device(>dev);
return ERR_PTR(ret);
}
return bd;
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 38db67588b16..f3b484c99789 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -388,16 +388,6 @@ static inline int backlight_disable(struct
backlight_device *bd)
return backlight_update_status(bd);
}
-/**
- * backlight_put - Drop backlight reference
- * @bd: the backlight device to put
- */
-static inline void backlight_put(struct backlight_device *bd)
-{
- if (bd)
- put_device(>dev);
-}
-
/**
* backlight_is_blank - Return true if display is expected to be blank
* @bd: the backlight device
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 02/20] 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.
v4:
- struct backlight_device * is now const
v3:
- Clarified that the fb_blank support in
backlight_is_blank() may result in functionality
changes for the users (Emil)
v2:
- Added fb_blank condition (Daniel)
Signed-off-by: Sam Ravnborg
Reviewed-by: Daniel Thompson
Reviewed-by: Peter Ujfalusi
Reviewed-by: Emil Velikov
Cc: Emil Velikov
Cc: Daniel Vetter
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
---
include/linux/backlight.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index 56e4580d4f55..56e51ebab740 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -175,6 +175,25 @@ static inline void backlight_put(struct backlight_device
*bd)
put_device(>dev);
}
+/**
+ * backlight_is_blank - Return true if display is expected to be blank
+ * @bd: the backlight device
+ *
+ * Display is expected to be blank if any of these is true::
+ *
+ * 1) if power in not UNBLANK
+ * 2) if fb_blank is not UNBLANK
+ * 3) if state indicate BLANK or SUSPENDED
+ *
+ * Returns true if display is expected to be blank, false otherwise.
+ */
+static inline bool backlight_is_blank(const struct backlight_device *bd)
+{
+ return bd->props.power != FB_BLANK_UNBLANK ||
+ bd->props.fb_blank != FB_BLANK_UNBLANK ||
+ bd->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK);
+}
+
extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 05/20] backlight: improve backlight_device documentation
Improve the documentation for backlight_device and
adapt it to kernel-doc style.
The updated documentation is more strict on how locking is used.
With the update neither update_lock nor ops_lock may be used
outside the backlight core.
This restriction was introduced to keep the locking simple
by keeping it in the core.
It was verified that this documents the current state by renaming
update_lock => bl_update_lock and ops_lock => bl_ops_lock.
The rename did not reveal any uses outside the backlight core.
The rename is NOT part of this patch.
v3:
- Update changelog to explain locking details (Daniel)
v2:
- Add short intro to all fields (Daniel)
- Updated description of update_lock (Daniel)
Signed-off-by: Sam Ravnborg
Reviewed-by: Emil Velikov
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 10518b00b059..7654fe5f1589 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 v4 03/20] 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
Reviewed-by: Emil Velikov
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 56e51ebab740..dfb43ee02ea0 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 v4 0/20] backlight: backlight updates
Long overdue follow-up. v3 submission here: https://lore.kernel.org/dri-devel/20200601065207.492614-1-...@ravnborg.org/ v4: - Introduced backlight_get_brightness based on feedback from Emil. - Properly described the rationale behind more restrictive locking use I checked that locking was not used outside backlight core by renaming the lock fields. As it is not used seems OK to restrict use to the core. - Introducing backlight_get_brightness invalidated some patches and I did a bit finer split to ease review. - Added acks - A few small adjustments documented in the individual patches 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. 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 (20): 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: introduce backlight_get_brightness() backlight: as3711_bl: simplify update_status backlight: cr_bllcd: introduce backlight_is_blank() backlight: gpio_backlight: simplify update_status() backlight: jornada720_bl: introduce backlight_is_blank() backlight: use backligt_get_brightness() backlight: drop backlight_put() backlight: make of_find_backlight static backlight: make of_find_backlight_by_node() static Documentation/gpu/backlight.rst | 12 + Documentation/gpu/index.rst | 1 + drivers/video/backlight/88pm860x_bl.c| 13 +- drivers/video/backlight/Kconfig | 8 - drivers/video/backlight/Makefile | 1 - drivers/video/backlight/adp5520_bl.c | 10 +- drivers/video/backlight/adp8860_bl.c | 10 +- drivers/video/backlight/adp8870_bl.c | 10 +- drivers/video/backlight/as3711_bl.c | 11 +- drivers/video/backlight/backlight.c | 234 ++ drivers/video/backlight/bd6107.c | 7 +- drivers/video/backlight/corgi_lcd.c | 8 +- drivers/video/backlight/cr_bllcd.c | 14 +- drivers/video/backlight/da903x_bl.c | 13 +- drivers/video/backlight/ep93xx_bl.c | 8 +- drivers/video/backlight/generic_bl.c | 110 - drivers/video/backlight/gpio_backlight.c | 17 +- drivers/video/backlight/hp680_bl.c | 6 +- drivers/video/backlight/jornada720_bl.c | 2 +- drivers/video/backlight/kb3886_bl.c | 6 +- drivers/video/backlight/led_bl.c | 7 +- drivers/video/backlight/lm3533_bl.c | 8 +- drivers/video/backlight/locomolcd.c | 6 +- drivers/video/backlight/lv5207lp.c | 7 +- drivers/video/backlight/max8925_bl.c | 13 +- drivers/video/backlight/pwm_bl.c | 7 +- drivers/video/backlight/qcom-wled.c | 7 +- drivers/video/backlight/tps65217_bl.c| 10 +- drivers/video/backlight/wm831x_bl.c | 13 +- include/linux/backlight.h| 409 --- 30 files changed, 503 insertions(+), 485 deletions(-)
[PATCH v4 01/20] 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
Reviewed-by: Emil Velikov
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 92d80aa0c0ef..7e249aa90b0e 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 v4 04/20] backlight: improve backlight_properties documentation
Improve the documentation for backlight_properties and
adapt it to kernel-doc style.
v3:
- Added missing '@' in kernel-doc
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
Reviewed-by: Emil Velikov
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 dfb43ee02ea0..10518b00b059 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 */
+ /**
+*
Re: [RFC PATCH 0/4] DSI/DBI and TinyDRM driver
Hi Noralf/Paul.
Trying to stir up this discussion again.
On Sun, Jun 14, 2020 at 06:36:22PM +0200, Noralf Trønnes wrote:
>
>
> Den 07.06.2020 15.38, skrev Paul Cercueil:
> > Hi,
> >
> > Here's a follow-up on the previous discussion about the current state of
> > DSI/DBI panel drivers, TinyDRM, and the need of a cleanup.
> >
> > This patchset introduces the following:
> > * It slightly tweaks the MIPI DSI code so that it supports MIPI DBI over
> > various buses. This patch has been tested with a non-upstream DRM
> > panel driver for a ILI9331 DBI/8080 panel, written with the DSI
> > framework (and doesn't include ), and non-upstream
> > DSI/DBI host driver for the Ingenic SoCs.
> >
> > * A SPI DBI host driver, using the current MIPI DSI framework. It allows
> > MIPI DSI/DBI drivers to be written with the DSI framework, even if
> > they are connected over SPI, instead of registering as SPI device
> > drivers. Since most of these panels can be connected over various
> > buses, it permits to reuse the same driver independently of the bus
> > used.
> >
> > * A TinyDRM driver for DSI/DBI panels, once again independent of the bus
> > used; the only dependency (currently) being that the panel must
> > understand DCS commands.
> >
> > * A DRM panel driver to test the stack. This driver controls Ilitek
> > ILI9341 based DBI panels, like the Adafruit YX240QV29-T 320x240 2.4"
> > TFT LCD panel. This panel was converted from
> > drivers/gpu/drm/tiny/ili9341.c.
> >
> > I would like to emphasize that while it has been compile-tested, I did
> > not test it with real hardware since I do not have any DBI panel
> > connected over SPI. I did runtime-test the code, just without any panel
> > connected.
> >
> > Another thing to note, is that it does not break Device Tree ABI. The
> > display node stays the same:
> >
> > display@0 {
> > compatible = "adafruit,yx240qv29", "ilitek,ili9341";
> > reg = <0>;
> > spi-max-frequency = <3200>;
> > dc-gpios = < 9 GPIO_ACTIVE_HIGH>;
> > reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
> > rotation = <270>;
> > backlight = <>;
> > };
> >
> > The reason it works, is that the "adafruit,yx240qv29" device is probed
> > on the SPI bus, so it will match with the SPI/DBI host driver. This will
> > in turn register the very same node with the DSI bus, and the ILI9341
> > DRM panel driver will probe. The driver will detect that no controller
> > is linked to the panel, and eventually register the DBI/DSI TinyDRM
> > driver.
> >
> > I can't stress it enough that this is a RFC, so it still has very rough
> > edges.
> >
>
> I don't know bridge and dsi drivers so I can't comment on that, but one
> thing I didn't like is that the DT compatible string has to be added to
> 2 different modules.
>
> As an example, a MI0283QT panel (ILI9341) supports these interface options:
>
> 1. SPI
>Panel setup/control and framebuffer upload over SPI
>
> 2. SPI + DPI
>Panel setup/control over SPI, framebuffer scanout over DPI
>
> 3. Parallel bus
>Panel setup/control and framebuffer upload over parallel bus
To continue the configurations we should support:
- Panels where the chip can be configured to SPI, SPI+DPI, Parallel bus
(as detailed by Noralf above)
- Panels that supports only 6800 or 8080 - connected via GPIO pins or
memory mapped (maybe behind some special IP to support this)
Command set is often special.
We will see a number of chips with many different types of displays.
So the drivers should be chip specific with configuration depending on
the connected display.
What I hope we can find a solution for is a single file/driver that can
support all the relevant interface types for a chip.
So we would end up with a single file that included the necessary
support for ili9341 in all interface configurations with the necessary
support for the relevant displays.
I do not know how far we are from this as I have not dived into the
details of any of the proposals.
>
> My suggestion is to have one panel driver module that can support all of
> these like this:
So I think we agree here.
>
> For 1. and 2. a SPI driver is registered and if I understand your
> example correctly of_graph_get_port_by_id() can be used during probe to
> distinguish between the 2 options and register a full DRM driver for 1.
> and add a DRM panel for 2.
>
> For 3. a DSI driver is registered (adapted for DBI use like you're
> suggesting).
>
> Note that the interface part of the controller initialization will
> differ between these, the panel side init will be the same I assume.
Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Convert register accessors to FIELD_*
On Fri, Jul 3, 2020 at 6:57 AM Maxime Ripard wrote: > > The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic > already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to > use the FIELD_* macros. > > Signed-off-by: Maxime Ripard > --- Reviewed-by: Eric Anholt ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/msm: Quiet error during failure in optional resource mappings.
Hi Eric,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.8-rc3
next-20200703]
[cannot apply to drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Eric-Anholt/drm-msm-Garbage-collect-unused-resource-_len-fields/20200630-022449
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: arm64-randconfig-r031-20200703 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
ca464639a1c9dd3944eb055ffd2796e8c2e7639f)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/msm/msm_drv.c:123:15: warning: no previous prototype for
>> function '_msm_ioremap' [-Wmissing-prototypes]
void __iomem *_msm_ioremap(struct platform_device *pdev, const char *name,
^
drivers/gpu/drm/msm/msm_drv.c:123:1: note: declare 'static' if the function
is not intended to be used outside of this translation unit
void __iomem *_msm_ioremap(struct platform_device *pdev, const char *name,
^
static
1 warning generated.
vim +/_msm_ioremap +123 drivers/gpu/drm/msm/msm_drv.c
122
> 123 void __iomem *_msm_ioremap(struct platform_device *pdev, const char
> *name,
124 const char *dbgname, bool quiet)
125 {
126 struct resource *res;
127 unsigned long size;
128 void __iomem *ptr;
129
130 if (name)
131 res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
132 else
133 res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
134
135 if (!res) {
136 if (!quiet)
137 DRM_DEV_ERROR(>dev, "failed to get memory
resource: %s\n", name);
138 return ERR_PTR(-EINVAL);
139 }
140
141 size = resource_size(res);
142
143 ptr = devm_ioremap(>dev, res->start, size);
144 if (!ptr) {
145 if (!quiet)
146 DRM_DEV_ERROR(>dev, "failed to ioremap:
%s\n", name);
147 return ERR_PTR(-ENOMEM);
148 }
149
150 if (reglog)
151 printk(KERN_DEBUG "IO:region %s %p %08lx\n", dbgname,
ptr, size);
152
153 return ptr;
154 }
155
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)
On Fri, Jul 3, 2020 at 7:53 AM Sai Prakash Ranjan wrote: > > Hi Will, > > On 2020-07-03 19:07, Will Deacon wrote: > > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: > >> diff --git a/drivers/gpu/drm/msm/msm_iommu.c > >> b/drivers/gpu/drm/msm/msm_iommu.c > >> index f455c597f76d..bd1d58229cc2 100644 > >> --- a/drivers/gpu/drm/msm/msm_iommu.c > >> +++ b/drivers/gpu/drm/msm/msm_iommu.c > >> @@ -218,6 +218,9 @@ static int msm_iommu_map(struct msm_mmu *mmu, > >> uint64_t iova, > >> iova |= GENMASK_ULL(63, 49); > >> > >> > >> +if (mmu->features & MMU_FEATURE_USE_SYSTEM_CACHE) > >> +prot |= IOMMU_SYS_CACHE_ONLY; > > > > Given that I think this is the only user of IOMMU_SYS_CACHE_ONLY, then > > it > > looks like it should actually be a property on the domain because we > > never > > need to configure it on a per-mapping basis within a domain, and > > therefore > > it shouldn't be exposed by the IOMMU API as a prot flag. > > > > Do you agree? > > > > GPU being the only user is for now, but there are other clients which > can use this. > Plus how do we set the memory attributes if we do not expose this as > prot flag? It does appear that the downstream kgsl driver sets this for basically all mappings.. well there is some conditional stuff around DOMAIN_ATTR_USE_LLC_NWA but it seems based on the property of the domain. (Jordan may know more about what that is about.) But looks like there are a lot of different paths into iommu_map in kgsl so I might have missed something. Assuming there isn't some case where we specifically don't want to use the system cache for some mapping, I think it could be a domain attribute that sets an io_pgtable_cfg::quirks flag BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DSI probe/bind ordering in vc4
On 30.06.2020 15:27, Maxime Ripard wrote: Hi, I've tried to bring-up the DSI controller on the RaspberryPi4, and I've just encountered something that could make it troublesome to support. For context, the RaspberryPi has an official panel that uses a DSI->DPI bridge, a DPI panel, a touchscreen and a small micro-controller. That microcontroller controls the power management on the screen, so communicating with it is very much needed, and it's done through an i2c bus. To reflect that, the entire panel has been described in the Device Tree as an I2C device (since that's how you would control it), together with an OF-Graph endpoint linking that i2c device to the DSI controller[1]. That deviates a bit from the generic DSI binding though[2], since it requires that the panel should be a subnode of the DSI controller (which also makes sense since DCS commands is usually how you would control that device). This is where the trouble begins. Since the two devices are on entirely different buses, there's basically no guarantee on the probe order. The driver has tried to address this by using the OF-Graph and the component framework. Indeed, the DSI driver (component-based) will register a MIPI-DSI host in its probe, and call component_add[3]. If component_add fails, it will remove the DSI host and return the error code. It makes sense. The panel on the other hand will probe, and look for a DSI host through the OF-Graph [4]. If it isn't there, it will return EPROBE_DEFER, hoping that it will be available at some point. It also makes complete sense. Where the issue lies is that component_add has two very different behaviours here that will create the bug that we see on the RPi4: - If there's still components to probe, component_add will simply return 0 [5][6] - And if we're the last component to probe, component_add will then run all the bind callbacks and return the result on error of the master bind callback[7]. That master bind will usually have component_bind_all that will return the result of the bind callback of each component. Now, on the RPi4, the last component to probe is the DSI controller since it relies on a power-domain exposed by the firmware driver, so the driver core will defer its probe function until the power-domain is there [8]. We're thus pretty much guaranteed to fall in the second case above and run through all the bind callbacks. The DSI bind callback however will try to find and attach its panel, and return EPROBE_DEFER if it doesn't find it[9]. That error will then be propagated to the return code of component_bind_all, then to the master bind callback, and finally will be the return code of component_add. And since component_add is failing, we remove the DSI host. Since the DSI host isn't there, on the next occasion the i2c panel driver will not probe either, and we enter a loop that cannot really be broken, since one depends on the other. This was working on the RPi3 because the DSI is not the last driver to probe: indeed the v3d is depending on the same power domain[10][11] and is further down the list of components to add in the driver [12], so we're always in the first component_add case for DSI above, the DSI host sticks around, and the i2c driver can probe. I'm not entirely sure how we can fix that though. I guess the real flaw here is the assumption that component_add will not fail if one of the bind fails, which isn't true, but we can't really ignore those errors either since it might be something else than DSI that returns that error. One way to work around it is to make the mailbox, firmware and power domain drivers probe earlier by tweaking the initcalls at which they register, but it's not really fixing anything and compiling them as module would make it broken again. Forgive me - I have not read whole post, but I hope you have a problem already solved. As I understand you have: 1. Componentized DSI-host. 2. Some sink laying on DSI bus. General rule I promote: "do not expose functionality, until you have all dependencies", in this case it would be "do not call component_add until you know sink(your dependency) is ready". Already tested solution (to be checked in drivers): 1. In DSI-host you register dsi bus in probe, but do not call component_add. 2. In DSI-host callback informing about DSI device registration you get the sink and since you have all resources then you call component_add. I hope it will be helpful. Regards Andrzej Maxime 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/display/dsi-controller.yaml 3: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/vc4/vc4_dsi.c#n1661 4:
Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)
On Fri, Jul 03, 2020 at 08:23:07PM +0530, Sai Prakash Ranjan wrote: > On 2020-07-03 19:07, Will Deacon wrote: > > On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: > > > diff --git a/drivers/gpu/drm/msm/msm_iommu.c > > > b/drivers/gpu/drm/msm/msm_iommu.c > > > index f455c597f76d..bd1d58229cc2 100644 > > > --- a/drivers/gpu/drm/msm/msm_iommu.c > > > +++ b/drivers/gpu/drm/msm/msm_iommu.c > > > @@ -218,6 +218,9 @@ static int msm_iommu_map(struct msm_mmu *mmu, > > > uint64_t iova, > > > iova |= GENMASK_ULL(63, 49); > > > > > > > > > + if (mmu->features & MMU_FEATURE_USE_SYSTEM_CACHE) > > > + prot |= IOMMU_SYS_CACHE_ONLY; > > > > Given that I think this is the only user of IOMMU_SYS_CACHE_ONLY, then > > it > > looks like it should actually be a property on the domain because we > > never > > need to configure it on a per-mapping basis within a domain, and > > therefore > > it shouldn't be exposed by the IOMMU API as a prot flag. > > > > Do you agree? > > > > GPU being the only user is for now, but there are other clients which can > use this. > Plus how do we set the memory attributes if we do not expose this as prot > flag? I just don't understand the need for it to be per-map operation. Put another way, if we extended the domain attribute to apply to cacheable mappings on the domain and not just the table walk, what would break? Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] display/drm/bridge: TC358775 DSI/LVDS driver
Hi Vinay. On Thu, Jul 02, 2020 at 06:06:34PM +0530, Vinay Simha BN wrote: > This driver is tested with two panels individually with Apq8016-IFC6309 board > https://www.inforcecomputing.com/products/single-board-computers-sbc/qualcomm-snapdragon-410-inforce-6309-micro-sbc > > 1. 1366x768@60 auo,b101xtn01 data-mapping = "jeida-24" > 2. 800x480@60 innolux,at070tn92 data-mapping = "vesa-24" > > Signed-off-by: Vinay Simha BN > > --- > v1: > Initial version > > v2: > * Andrzej Hajda review comments incorporated > SPDX identifier > development debug removed > alphabetic order headers > u32 instead of unit32_t > magic numbers to macros for CLRSI and mux registers > ignored return value > > * Laurent Pinchart review comments incorporated > mdelay to usleep_range > bus_formats added > > v3: > * Andrzej Hajda review comments incorporated > drm_connector_status removed > u32 rev removed and local variabl is used > regulator enable disable with proper orders and delays > as per the spec > devm_drm_panel_bridge_add method used instead of panel > description modified > dual port implemented > > v4: > * Sam Ravnborg review comments incorporated > panel->connector_type removed > > * Reported-by: kernel test robot > parse_dt to static function > removed the if (endpoint), since data-lanes has to be > present for dsi dts ports > > v5: > ~vsdelay dynamic value set based on the > calculation of dsi speed, output speed, blanking > > v6: > * Sam Ravnborg review comments incorporated > help modified > display_timings naming local variables > check for bus_formats unsupported > error handling enpoint data-lanes There are some details that I missed in last review - see below. Trivial stuff only, I do not have knowledge to review all of the driver properly. Sam > --- > drivers/gpu/drm/bridge/Kconfig| 10 + > drivers/gpu/drm/bridge/Makefile | 1 + > drivers/gpu/drm/bridge/tc358775.c | 766 ++ > 3 files changed, 777 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/tc358775.c > > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index 43271c21d3fc..99abda4459ab 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -181,6 +181,16 @@ config DRM_TOSHIBA_TC358768 > help > Toshiba TC358768AXBG/TC358778XBG DSI bridge chip driver. > > +config DRM_TOSHIBA_TC358775 > +tristate "Toshiba TC358775 DSI/LVDS bridge" > +depends on OF > +select DRM_KMS_HELPER > +select REGMAP_I2C > +select DRM_PANEL > + select DRM_MIPI_DSI > +help > + Toshiba TC358775 DSI/LVDS bridge chip driver. Use one tab for indent, not spaces. Help text needs to have an indent of one tab + two spaces. > + > config DRM_TI_TFP410 > tristate "TI TFP410 DVI/HDMI bridge" > depends on OF > diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile > index d63d4b7e4347..23c770b3bfe4 100644 > --- a/drivers/gpu/drm/bridge/Makefile > +++ b/drivers/gpu/drm/bridge/Makefile > @@ -15,6 +15,7 @@ obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o > obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o > obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o > obj-$(CONFIG_DRM_TOSHIBA_TC358768) += tc358768.o > +obj-$(CONFIG_DRM_TOSHIBA_TC358775) += tc358775.o > obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/ > obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o > obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o > diff --git a/drivers/gpu/drm/bridge/tc358775.c > b/drivers/gpu/drm/bridge/tc358775.c > new file mode 100644 > index ..88a05b9645e8 > --- /dev/null > +++ b/drivers/gpu/drm/bridge/tc358775.c > @@ -0,0 +1,766 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * tc358775 DSI to LVDS bridge driver > + * > + * Copyright (C) 2020 SMART Wireless Computing > + * Author: Vinay Simha BN > + * > + */ > +/* #define DEBUG */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define FLD_MASK(start, end)(((1 << ((start) - (end) + 1)) - 1) << (end)) > +#define FLD_VAL(val, start, end) (((val) << (end)) & FLD_MASK(start, end)) I did no dechiper the above, but it looks like an opencoded variant of GENMASK() If it is so, then consider using GENMASK() as this is the official way to do it. (linux/bits.h) (Yes, I know FLD_* is used on other bridge drivers). > + > +/* Registers */ > + > +/* DSI D-PHY Layer Registers */ > +#define D0W_DPHYCONTTX 0x0004 /* Data Lane 0 DPHY Tx Control */ > +#define CLW_DPHYCONTRX 0x0020 /* Clock Lane DPHY Rx Control */ > +#define D0W_DPHYCONTRX 0x0024 /* Data Lane 0 DPHY Rx Control */ > +#define D1W_DPHYCONTRX 0x0028 /* Data Lane 1 DPHY Rx Control */ > +#define D2W_DPHYCONTRX 0x002C /* Data Lane 2 DPHY Rx
Re: [PATCH v6 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
Hi Vinay.
On Thu, Jul 02, 2020 at 06:06:33PM +0530, Vinay Simha BN wrote:
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
> Initial version wast .txt file
>
> v2:
> From txt to yaml file format
>
> v3:
> * Andrzej Hajda review comments incorporated
> dual port lvds implemented
>
> * Laurent Pinchart review comments incorporated
> dsi lanes property removed and it is dynamically
> picked from the dsi ports
> VESA/JEIDA format picked from panel-lvds dts
>
> v4:
> * Sam Ravnborg review comments incorporated
> }' is indented properly in examples data-lanes
> description for single-link and dual-link lvds
> ---
> .../display/bridge/toshiba,tc358775.yaml | 215 ++
> 1 file changed, 215 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> new file mode 100644
> index ..9ddd63bee403
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> @@ -0,0 +1,215 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
One detail that I missed - any specific reason this is not (GPL-2.0-only OR
BSD-2-Clause)
This is the preferred license for new bindings - as checkpatch also
tells you.
Sam
> +---
> +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba TC358775 DSI to LVDS bridge bindings
> +
> +maintainers:
> + - Vinay Simha BN
> +
> +description: |
> + This binding supports DSI to LVDS bridge TC358775
> +
> + MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane.
> + Video frame size:
> + Up to 1600x1200 24-bit/pixel resolution for single-link LVDS display panel
> + limited by 135 MHz LVDS speed
> + Up to WUXGA (1920x1200 24-bit pixels) resolution for dual-link LVDS display
> + panel, limited by 270 MHz LVDS speed.
> +
> +properties:
> + compatible:
> +const: toshiba,tc358775
> +
> + reg:
> +maxItems: 1
> +description: i2c address of the bridge, 0x0f
> +
> + vdd-supply:
> +maxItems: 1
> +description: 1.2V LVDS Power Supply
> +
> + vddio-supply:
> +maxItems: 1
> +description: 1.8V IO Power Supply
> +
> + stby-gpios:
> +maxItems: 1
> +description: Standby pin, Low active
> +
> + reset-gpios:
> +maxItems: 1
> +description: Hardware reset, Low active
> +
> + ports:
> +type: object
> +description:
> + A node containing input and output port nodes with endpoint definitions
> + as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + DSI Input. The remote endpoint phandle should be a
> + reference to a valid mipi_dsi_host device node.
> +
> + port@1:
> +type: object
> +description: |
> + Video port for LVDS output (panel or connector).
> +
> + port@2:
> +type: object
> +description: |
> + Video port for Dual link LVDS output (panel or connector).
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - vdd-supply
> + - vddio-supply
> + - stby-gpios
> + - reset-gpios
> + - ports
> +
> +examples:
> + - |
> +#include
> +
> +/* For single-link LVDS display panel */
> +
> +i2c@78b8000 {
> +/* On High speed expansion */
> +label = "HS-I2C2";
> +reg = <0x078b8000 0x500>;
> +clock-frequency = <40>; /* fastmode operation */
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +tc_bridge: bridge@f {
> +compatible = "toshiba,tc358775";
> +reg = <0x0f>;
> +
> +vdd-supply = <_l2>;
> +vddio-supply = <_l6>;
> +
> +stby-gpios = < 99 GPIO_ACTIVE_LOW>;
> +reset-gpios = < 72 GPIO_ACTIVE_LOW>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +d2l_in_test: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +lvds_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};
> +};
> +
> +dsi@1a98000 {
> +reg = <0x1a98000 0x25c>;
> +reg-names = "dsi_ctrl";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
Re: [Intel-gfx] [PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
On 2020-07-03 at 16:48:27 +0530, Anshuman Gupta wrote:
> On 2020-06-23 at 21:29:07 +0530, Sean Paul wrote:
> > From: Sean Paul
> >
> > Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> > MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> > support is the same as the DP case, so we'll re-use those callbacks
> >
> > Cc: Juston Li
> > Signed-off-by: Sean Paul
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
> > #v1
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
> > #v2
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
> > #v3
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
> > #v4
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
> > #v5
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
> > #v6
> >
> > Changes in v2:
> > -Toggle HDCP from encoder disable/enable
> > -Don't disable HDCP on MST connector destroy, leave that for encoder
> > disable, just ensure the check_work routine isn't running any longer
> > Changes in v3:
> > -Place the shim in the new intel_dp_hdcp.c file (Ville)
> > Changes in v4:
> > -Actually use the mst shim for mst connections (Juston)
> > -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
> > Changes in v5:
> > -Add sleep on disable signalling to match hdmi delay
> > Changes in v6:
> > -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
> > don't have hardware to test it
> > Changes in v7:
> > -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
> > ---
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
> > drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
> > 3 files changed, 84 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > index 43446a6cae8d..3f67bd27fc3c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> > @@ -7,10 +7,12 @@
> > */
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > #include "intel_display_types.h"
> > +#include "intel_ddi.h"
> > #include "intel_dp.h"
> > #include "intel_hdcp.h"
> >
> > @@ -618,6 +620,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim
> > = {
> > .protocol = HDCP_PROTOCOL_DP,
> > };
> >
> > +static int
> > +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> > *intel_dig_port,
> > + enum transcoder cpu_transcoder,
> > + bool enable)
> > +{
> > + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> > + int ret;
> > +
> > + if (!enable)
> > + usleep_range(6, 60); /* Bspec says >= 6us */
> > +
> > + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base,
> > + cpu_transcoder, enable);
> > + if (ret)
> > + drm_dbg_kms(>drm, "%s HDCP signalling failed (%d)\n",
> > + enable ? "Enable" : "Disable", ret);
> > + return ret;
> > +}
> > +
> > +static
> > +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port
> > *intel_dig_port,
> > + struct intel_connector *connector)
> > +{
> > + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> > + struct intel_dp *intel_dp = _dig_port->dp;
> > + struct drm_dp_query_stream_enc_status_ack_reply reply;
> > + int ret;
> > +
> > + if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
> > + return false;
> > +
> > + ret = drm_dp_send_query_stream_enc_status(_dp->mst_mgr,
> > + connector->port, );
> > + if (ret) {
> > + drm_dbg_kms(>drm,
> > + "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> > + connector->base.base.id, connector->base.name, ret);
> > + return false;
> > + }
> > +
> > + return reply.auth_completed && reply.encryption_enabled;
> > +}
> > +
> > +static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> > + .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> > + .read_bksv = intel_dp_hdcp_read_bksv,
> > + .read_bstatus = intel_dp_hdcp_read_bstatus,
> > + .repeater_present = intel_dp_hdcp_repeater_present,
> > + .read_ri_prime = intel_dp_hdcp_read_ri_prime,
> > + .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
> > + .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
> > + .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
> > + .toggle_signalling =
Re: [PATCH v6 1/2] dt-binding: Add DSI/LVDS TC358775 bridge bindings
Hi Vinay.
On Thu, Jul 02, 2020 at 06:06:33PM +0530, Vinay Simha BN wrote:
> Signed-off-by: Vinay Simha BN
>
> ---
> v1:
> Initial version wast .txt file
>
> v2:
> From txt to yaml file format
>
> v3:
> * Andrzej Hajda review comments incorporated
> dual port lvds implemented
>
> * Laurent Pinchart review comments incorporated
> dsi lanes property removed and it is dynamically
> picked from the dsi ports
> VESA/JEIDA format picked from panel-lvds dts
>
> v4:
> * Sam Ravnborg review comments incorporated
> }' is indented properly in examples data-lanes
> description for single-link and dual-link lvds
If you add a proper changelog then this patch is:
Reviewed-by: Sam Ravnborg
Sam
> ---
> .../display/bridge/toshiba,tc358775.yaml | 215 ++
> 1 file changed, 215 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> new file mode 100644
> index ..9ddd63bee403
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
> @@ -0,0 +1,215 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358775.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Toshiba TC358775 DSI to LVDS bridge bindings
> +
> +maintainers:
> + - Vinay Simha BN
> +
> +description: |
> + This binding supports DSI to LVDS bridge TC358775
> +
> + MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane.
> + Video frame size:
> + Up to 1600x1200 24-bit/pixel resolution for single-link LVDS display panel
> + limited by 135 MHz LVDS speed
> + Up to WUXGA (1920x1200 24-bit pixels) resolution for dual-link LVDS display
> + panel, limited by 270 MHz LVDS speed.
> +
> +properties:
> + compatible:
> +const: toshiba,tc358775
> +
> + reg:
> +maxItems: 1
> +description: i2c address of the bridge, 0x0f
> +
> + vdd-supply:
> +maxItems: 1
> +description: 1.2V LVDS Power Supply
> +
> + vddio-supply:
> +maxItems: 1
> +description: 1.8V IO Power Supply
> +
> + stby-gpios:
> +maxItems: 1
> +description: Standby pin, Low active
> +
> + reset-gpios:
> +maxItems: 1
> +description: Hardware reset, Low active
> +
> + ports:
> +type: object
> +description:
> + A node containing input and output port nodes with endpoint definitions
> + as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +properties:
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> + port@0:
> +type: object
> +description: |
> + DSI Input. The remote endpoint phandle should be a
> + reference to a valid mipi_dsi_host device node.
> +
> + port@1:
> +type: object
> +description: |
> + Video port for LVDS output (panel or connector).
> +
> + port@2:
> +type: object
> +description: |
> + Video port for Dual link LVDS output (panel or connector).
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - vdd-supply
> + - vddio-supply
> + - stby-gpios
> + - reset-gpios
> + - ports
> +
> +examples:
> + - |
> +#include
> +
> +/* For single-link LVDS display panel */
> +
> +i2c@78b8000 {
> +/* On High speed expansion */
> +label = "HS-I2C2";
> +reg = <0x078b8000 0x500>;
> +clock-frequency = <40>; /* fastmode operation */
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +tc_bridge: bridge@f {
> +compatible = "toshiba,tc358775";
> +reg = <0x0f>;
> +
> +vdd-supply = <_l2>;
> +vddio-supply = <_l6>;
> +
> +stby-gpios = < 99 GPIO_ACTIVE_LOW>;
> +reset-gpios = < 72 GPIO_ACTIVE_LOW>;
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +d2l_in_test: endpoint {
> +remote-endpoint = <_out>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +lvds_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};
> +};
> +
> +dsi@1a98000 {
> +reg = <0x1a98000 0x25c>;
> +reg-names = "dsi_ctrl";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +port@1 {
> +reg = <1>;
> +dsi0_out: endpoint {
> +
Re: [PATCH] drm/dbi: Fix SPI Type 1 (9-bit) transfer
On Fri, Jul 03, 2020 at 04:13:41PM +0200, Paul Cercueil wrote:
> The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit
> data, the 9th (MSB) bit being the data/command bit. In order to do that,
> it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if
> the byte corresponds to data, clears it otherwise. The 7 MSB are
> padding. The array of now 16-bit values is then passed to the SPI core
> for transfer.
>
> This function was broken since its introduction, as the length of the
> SPI transfer was set to the payload size before its conversion, but the
> payload doubled in size due to the 8-bit -> 16-bit conversion.
>
> Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
> Cc: # 4.10
"dim fixes 02dd95fe3169" provides the following output:
Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
Cc: Noralf Trønnes
Cc: Thierry Reding
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: "Noralf Trønnes"
Cc: Sam Ravnborg
Cc: David Lechner
Cc: Hans de Goede
Cc: Eric Anholt
Cc: dri-devel@lists.freedesktop.org
Cc: # v4.11+
I assume the "Cc: # 4.11+" is more correct?
Sam
> Signed-off-by: Paul Cercueil
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index bb27c82757f1..bf7888ad9ad4 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -923,7 +923,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi,
> int dc,
> }
> }
>
> - tr.len = chunk;
> + tr.len = chunk * 2;
> len -= chunk;
>
> ret = spi_sync(spi, );
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dbi: Fix SPI Type 1 (9-bit) transfer
On Fri, Jul 03, 2020 at 04:13:41PM +0200, Paul Cercueil wrote:
> The function mipi_dbi_spi1_transfer() will transfer its payload as 9-bit
> data, the 9th (MSB) bit being the data/command bit. In order to do that,
> it unpacks the 8-bit values into 16-bit values, then sets the 9th bit if
> the byte corresponds to data, clears it otherwise. The 7 MSB are
> padding. The array of now 16-bit values is then passed to the SPI core
> for transfer.
>
> This function was broken since its introduction, as the length of the
> SPI transfer was set to the payload size before its conversion, but the
> payload doubled in size due to the 8-bit -> 16-bit conversion.
>
> Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support")
> Cc: # 4.10
> Signed-off-by: Paul Cercueil
As discussed on irc this looks correct to me too.
Reviewed-by: Sam Ravnborg
I will apply later, but let's wait and see if Noralf or others
have any feedback first.
Sam
> ---
> drivers/gpu/drm/drm_mipi_dbi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index bb27c82757f1..bf7888ad9ad4 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -923,7 +923,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi,
> int dc,
> }
> }
>
> - tr.len = chunk;
> + tr.len = chunk * 2;
> len -= chunk;
>
> ret = spi_sync(spi, );
> --
> 2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi, On 7/3/20 2:58 PM, Daniel Vetter wrote: On Fri, Jul 3, 2020 at 12:55 PM Hans de Goede wrote: Hi, On 7/1/20 4:10 PM, Thomas Zimmermann wrote: Hi Daniel, thanks for reviewing most of the patchset. Am 30.06.20 um 11:06 schrieb Daniel Vetter: On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede wrote: Hi, On 6/25/20 2:00 PM, Thomas Zimmermann wrote: This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. Cool, thank you for doing this, this is a very welcome change, but ... (see below). So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go around and break userspace. OTOH this does seem like an userspace issue and not something which we can (or should try to) fix in the kernel. I guess the solution will have to be to have this default to N for now in Kconfig and clearly mention in the Kconfig help text that this needs a fixed Xorg modesetting driver before it can be enabled. Any chance you have time to work on fixing the Xorg modesetting driver so that this will just work with the standard Xorg autoconfiguration stuff? Hm, why do we even have both platform and pci drivers visible at the same time? I thought the point of this is that simplekms is built-in, then initrd loads the real drm driver, and by the time Xorg is running, simplekms should be long gone. Maybe a few more details of what's going wrong and why to help unconfuse me? I tested simplekms with PCI graphics cards. Xorg does it's own scanning of the busses. It supports a platform bus, where it finds the simple-framebuffer device that is driven by simplekms. Xorg also scans the PCI bus, where is finds the native PCI device; usually driven by the native driver. It's the same hardware, but on different busses. For each device, Xorg tries to configure a screen, the Xorg modeset driver tried to open the DRM device file and acquire DRM master status on it. This works for the first screen, but DRM master status can only be acquired once, so it fails for the second screen. Xorg then aborts and asks for manual configuration of the display device. This can be solved by setting the platform device's bus id in the xorg.conf device section. It just doesn't happen automatically. I found it hard to find a solution to this. Weston just opens a DRM device file and uses whatever it gets. Ideally, Xorg would do the same. That whole bus-scanning exercise gives it a wrong idea on which graphics devices are available. One idea for a fix is to compare the device I/O-memory ranges and filter out duplicates on the Xorg modeset driver. I don't know how reliable this works in practice or if their are false positives. I think that this should work nicely, although I wonder how Xorg will get the memory-range for the simplefb platform device, it looks like it will need to parse /dev/iomem for this, or we need to add a new sysfs attr to the simplefb device for this. Adding the new sysfs attr has the added bonus that we
Re: [PATCHv3 7/7] drm/msm/a6xx: Add support for using system cache(LLC)
On Mon, Jun 29, 2020 at 09:22:50PM +0530, Sai Prakash Ranjan wrote: > diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c > index f455c597f76d..bd1d58229cc2 100644 > --- a/drivers/gpu/drm/msm/msm_iommu.c > +++ b/drivers/gpu/drm/msm/msm_iommu.c > @@ -218,6 +218,9 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t > iova, > iova |= GENMASK_ULL(63, 49); > > > + if (mmu->features & MMU_FEATURE_USE_SYSTEM_CACHE) > + prot |= IOMMU_SYS_CACHE_ONLY; Given that I think this is the only user of IOMMU_SYS_CACHE_ONLY, then it looks like it should actually be a property on the domain because we never need to configure it on a per-mapping basis within a domain, and therefore it shouldn't be exposed by the IOMMU API as a prot flag. Do you agree? Will ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
Am 03.07.20 um 15:14 schrieb Jason Gunthorpe: On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote: So maybe I'm just totally confused about the rdma model. I thought: - you bind a pile of memory for various transactions, that might happen whenever. Kernel driver doesn't have much if any insight into when memory isn't needed anymore. I think in the rdma world that's called registering memory, but not sure. Sure, but once registered the memory is able to be used at any moment with no visibilty from the kernel. Unlike GPU the transactions that trigger memory access do not go through the kernel - so there is no ability to interrupt a command flow and fiddle with mappings. This is the same for GPUs with user space queues as well. But we can still say for a process if that this process is using a DMA-buf which is moved out and so can't run any more unless the DMA-buf is accessible again. In other words you somehow need to make sure that the hardware is not accessing a piece of memory any more when you want to move it. Christian. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: gma500: Convert to GPIO descriptors
Finalize he conversion of GMA500 to use only GPIO descriptors.
The GPIO look-up-table is associated with the device directly
in the GMA500 Medfield chip driver since no explicit platform
type device (such as in x86/platform/intel-mid) exists: the
GMA500 probes directly from the PCI device. Apparently GPIOs
128 and 34 are used on all of these so just go ahead and
register those for resetting the DSI pipes.
Acked-by: Patrik Jakobsson
Signed-off-by: Linus Walleij
---
ChangeLog v2->v3:
- Actually commit the last comment fix.
---
drivers/gpu/drm/gma500/mdfld_device.c | 20 +
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 2 +-
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 51 ---
drivers/gpu/drm/gma500/mdfld_dsi_output.h | 2 +-
drivers/gpu/drm/gma500/mdfld_output.h | 2 +-
drivers/gpu/drm/gma500/psb_intel_drv.h| 1 -
6 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_device.c
b/drivers/gpu/drm/gma500/mdfld_device.c
index b718efccdcf2..be9cf6b1e3b3 100644
--- a/drivers/gpu/drm/gma500/mdfld_device.c
+++ b/drivers/gpu/drm/gma500/mdfld_device.c
@@ -6,6 +6,7 @@
**/
#include
+#include
#include
@@ -505,12 +506,31 @@ static const struct psb_offset mdfld_regmap[3] = {
},
};
+/*
+ * The GPIO lines for resetting DSI pipe 0 and 2 are available in the
+ * PCI device :00:0c.0 on the Medfield.
+ */
+static struct gpiod_lookup_table mdfld_dsi_pipe_gpio_table = {
+ .table = {
+ GPIO_LOOKUP(":00:0c.0", 128, "dsi-pipe0-reset",
+ GPIO_ACTIVE_HIGH),
+ GPIO_LOOKUP(":00:0c.0", 34, "dsi-pipe2-reset",
+ GPIO_ACTIVE_HIGH),
+ { },
+ },
+};
+
static int mdfld_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
if (pci_enable_msi(dev->pdev))
dev_warn(dev->dev, "Enabling MSI failed!\n");
dev_priv->regmap = mdfld_regmap;
+
+ /* Associate the GPIO lines with the DRM device */
+ mdfld_dsi_pipe_gpio_table.dev_id = dev_name(dev->dev);
+ gpiod_add_lookup_table(_dsi_pipe_gpio_table);
+
return mid_chip_setup(dev);
}
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
index c976a9dd9240..ae1223f631a7 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
@@ -955,7 +955,7 @@ struct mdfld_dsi_encoder *mdfld_dsi_dpi_init(struct
drm_device *dev,
/* panel hard-reset */
if (p_funcs->reset) {
- ret = p_funcs->reset(pipe);
+ ret = p_funcs->reset(dev, pipe);
if (ret) {
DRM_ERROR("Panel %d hard-reset failed\n", pipe);
return NULL;
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index f350ac1ead18..6473290126f2 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -432,42 +433,42 @@ static int mdfld_dsi_get_default_config(struct drm_device
*dev,
return 0;
}
-int mdfld_dsi_panel_reset(int pipe)
+int mdfld_dsi_panel_reset(struct drm_device *ddev, int pipe)
{
- unsigned gpio;
- int ret = 0;
-
+ struct device *dev = ddev->dev;
+ struct gpio_desc *gpiod;
+
+ /*
+* Raise the GPIO reset line for the corresponding pipe to HIGH,
+* this is probably because it is active low so this takes the
+* respective pipe out of reset. (We have no code to put it back
+* into reset in this driver.)
+*/
switch (pipe) {
case 0:
- gpio = 128;
+ gpiod = gpiod_get(dev, "dsi-pipe0-reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(gpiod))
+ return PTR_ERR(gpiod);
break;
case 2:
- gpio = 34;
+ gpiod = gpiod_get(dev, "dsi-pipe2-reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(gpiod))
+ return PTR_ERR(gpiod);
break;
default:
- DRM_ERROR("Invalid output\n");
+ DRM_DEV_ERROR(dev, "Invalid output pipe\n");
return -EINVAL;
}
+ gpiod_put(gpiod);
- ret = gpio_request(gpio, "gfx");
- if (ret) {
- DRM_ERROR("gpio_rqueset failed\n");
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 1);
- if (ret) {
- DRM_ERROR("gpio_direction_output failed\n");
- goto gpio_error;
- }
+ /* Flush posted writes on the device */
+ gpiod = gpiod_get(dev, "dsi-pipe0-reset",
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
On Fri, Jul 3, 2020 at 12:55 PM Hans de Goede wrote: > > Hi, > > On 7/1/20 4:10 PM, Thomas Zimmermann wrote: > > Hi Daniel, > > > > thanks for reviewing most of the patchset. > > > > Am 30.06.20 um 11:06 schrieb Daniel Vetter: > >> On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede wrote: > >>> > >>> Hi, > >>> > >>> On 6/25/20 2:00 PM, Thomas Zimmermann wrote: > This patchset adds support for simple-framebuffer platform devices and > a handover mechanism for native drivers to take-over control of the > hardware. > > The new driver, called simplekms, binds to a simple-frambuffer platform > device. The kernel's boot code creates such devices for firmware-provided > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot > loader sets up the framebuffers. Description via device tree is also an > option. > > Simplekms is small enough to be linked into the kernel. The driver's main > purpose is to provide graphical output during the early phases of the > boot > process, before the native DRM drivers are available. Native drivers are > typically loaded from an initrd ram disk. Occationally simplekms can also > serve as interim solution on graphics hardware without native DRM driver. > >>> > >>> Cool, thank you for doing this, this is a very welcome change, > >>> but ... (see below). > >>> > So far distributions rely on fbdev drivers, such as efifb, vesafb or > simplefb, for early-boot graphical output. However fbdev is deprecated > and > the drivers do not provide DRM interfaces for modern userspace. > > Patches 1 and 2 prepare the DRM format helpers for simplekms. > > Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During > pageflips, SHMEM buffers are copied into the framebuffer memory, similar > to cirrus or mgag200. The code in patches 6 and 7 handles clocks and > regulators. It's based on the simplefb drivers, but has been modified for > DRM. > > Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's > framebuffer's I/O-memory range and provides a callback function to be > removed by a native driver. The native driver will remove simplekms > before > taking over the hardware. The removal is integrated into existing > helpers, > so drivers use it automatically. > > I tested simplekms with x86 EFI and VESA framebuffers, which both work > reliably. The fbdev console and Weston work automatically. Xorg requires > manual configuration of the device. Xorgs current modesetting driver does > not work with both, platform and PCI device, for the same physical > hardware. Once configured, X11 works. > >>> > >>> Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go > >>> around and break userspace. OTOH this does seem like an userspace issue > >>> and not something which we can (or should try to) fix in the kernel. > >>> > >>> I guess the solution will have to be to have this default to N for now > >>> in Kconfig and clearly mention in the Kconfig help text that this needs > >>> a fixed Xorg modesetting driver before it can be enabled. > >>> > >>> Any chance you have time to work on fixing the Xorg modesetting driver > >>> so that this will just work with the standard Xorg autoconfiguration > >>> stuff? > >> > >> Hm, why do we even have both platform and pci drivers visible at the > >> same time? I thought the point of this is that simplekms is built-in, > >> then initrd loads the real drm driver, and by the time Xorg is > >> running, simplekms should be long gone. > >> > >> Maybe a few more details of what's going wrong and why to help unconfuse > >> me? > > > > I tested simplekms with PCI graphics cards. > > > > Xorg does it's own scanning of the busses. It supports a platform bus, > > where it finds the simple-framebuffer device that is driven by > > simplekms. Xorg also scans the PCI bus, where is finds the native PCI > > device; usually driven by the native driver. It's the same hardware, but > > on different busses. > > > > For each device, Xorg tries to configure a screen, the Xorg modeset > > driver tried to open the DRM device file and acquire DRM master status > > on it. This works for the first screen, but DRM master status can only > > be acquired once, so it fails for the second screen. Xorg then aborts > > and asks for manual configuration of the display device. > > > > This can be solved by setting the platform device's bus id in the > > xorg.conf device section. It just doesn't happen automatically. > > > > I found it hard to find a solution to this. Weston just opens a DRM > > device file and uses whatever it gets. Ideally, Xorg would do the same. > > That whole bus-scanning exercise gives it a wrong idea on which graphics > > devices are available.
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Fri, Jul 3, 2020 at 2:03 PM Jason Gunthorpe wrote: > > On Thu, Jul 02, 2020 at 08:15:40PM +0200, Daniel Vetter wrote: > > > > > 3. rdma driver worker gets busy to restart rx: > > > > > 1. lock all dma-buf that are currently in use (dma_resv_lock). > > > > > thanks to ww_mutex deadlock avoidance this is possible > > > > Why all? Why not just lock the one that was invalidated to restore the > > > > mappings? That is some artifact of the GPU approach? > > > > > > No, but you must make sure that mapping one doesn't invalidate others you > > > need. > > > > > > Otherwise you can end up in a nice live lock :) > > > > Also if you don't have pagefaults, but have to track busy memory at a > > context level, you do need to grab all locks of all buffers you need, or > > you'd race. There's nothing stopping a concurrent ->notify_move on some > > other buffer you'll need otherwise, and if you try to be clever and roll > > you're own locking, you'll anger lockdep - you're own lock will have to be > > on both sides of ww_mutex or it wont work, and that deadlocks. > > So you are worried about atomically building some multi buffer > transaction? I don't think this applies to RDMA which isn't going to > be transcational here.. So maybe I'm just totally confused about the rdma model. I thought: - you bind a pile of memory for various transactions, that might happen whenever. Kernel driver doesn't have much if any insight into when memory isn't needed anymore. I think in the rdma world that's called registering memory, but not sure. - for hw with hw faults you can pull in the memory when it's needed, and if concurrently another cpu is taking away pages and invalidating rdma hw mappings, then that's no problem. So far so good, 0 need for atomic transactions anything. But the answer I gave here is for when you don't have per-page hw faulting on the rdma nic, but something that works at a much larger level. For a gpu it would be a compute context, no idea what the equivalent for rdma is. This could go up to and including the entire nic stalling all rx with link level back pressure, but not necessarily. Once you go above a single page, or well, at least a single dma-buf object, you need some way to know when you have all buffers and memory mappings present again, because you can't restart with only partial memory. Now if the rdma memory programming is more like traditional networking, where you have a single rx or tx buffer, then yeah you don't need fancy multi-buffer locking. Like I said I have no idea how many of the buffers you need to restart the rdma stuff for hw which doesn't have per-page hw faulting. > > > > And why is this done with work queues and locking instead of a > > > > callback saying the buffer is valid again? > > > > > > You can do this as well, but a work queue is usually easier to handle > > > than a > > > notification in an interrupt context of a foreign driver. > > > > Yeah you can just install a dma_fence callback but > > - that's hardirq context > > - if you don't have per-page hw faults you need the multi-lock ww_mutex > > dance anyway to avoid races. > > It is still best to avoid the per-page faults and preload the new > mapping once it is ready. Sure, but I think that's entirely orthogonal. Also even if you don't need the multi-buffer dance (either because hw faults, or because the rdma rx/tx can be stopped at least at a per-buffer level through some other means) then you still need the dma_resv_lock to serialize with the exporter. So needs a sleeping context either way. Hence some worker is needed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v7 08/17] drm/i915: Clean up intel_hdcp_disable
On 2020-06-23 at 21:28:58 +0530, Sean Paul wrote:
> From: Sean Paul
>
> Add an out label and un-indent hdcp disable in preparation for
> hdcp_mutex. No functional changes
LGTM
Reviewed-by: Anshuman Gupta
>
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-9-s...@poorly.run
> #v6
>
> Changes in v7:
> -Split into separate patch (Ramalingam)
> ---
> drivers/gpu/drm/i915/display/intel_hdcp.c | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 62cab3aea745..16bf0fbe5f17 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -2113,16 +2113,17 @@ int intel_hdcp_disable(struct intel_connector
> *connector)
>
> mutex_lock(>mutex);
>
> - if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> - intel_hdcp_update_value(connector,
> - DRM_MODE_CONTENT_PROTECTION_UNDESIRED,
> - false);
> - if (hdcp->hdcp2_encrypted)
> - ret = _intel_hdcp2_disable(connector);
> - else if (hdcp->hdcp_encrypted)
> - ret = _intel_hdcp_disable(connector);
> - }
> + if (hdcp->value == DRM_MODE_CONTENT_PROTECTION_UNDESIRED)
> + goto out;
>
> + intel_hdcp_update_value(connector,
> + DRM_MODE_CONTENT_PROTECTION_UNDESIRED, false);
> + if (hdcp->hdcp2_encrypted)
> + ret = _intel_hdcp2_disable(connector);
> + else if (hdcp->hdcp_encrypted)
> + ret = _intel_hdcp_disable(connector);
> +
> +out:
> mutex_unlock(>mutex);
> cancel_delayed_work_sync(>check_work);
> return ret;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi Am 03.07.20 um 12:55 schrieb Hans de Goede: > Hi, > > On 7/1/20 4:10 PM, Thomas Zimmermann wrote: >> Hi Daniel, >> >> thanks for reviewing most of the patchset. >> >> Am 30.06.20 um 11:06 schrieb Daniel Vetter: >>> On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede >>> wrote: Hi, On 6/25/20 2:00 PM, Thomas Zimmermann wrote: > This patchset adds support for simple-framebuffer platform devices and > a handover mechanism for native drivers to take-over control of the > hardware. > > The new driver, called simplekms, binds to a simple-frambuffer > platform > device. The kernel's boot code creates such devices for > firmware-provided > framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or > boot > loader sets up the framebuffers. Description via device tree is > also an > option. > > Simplekms is small enough to be linked into the kernel. The > driver's main > purpose is to provide graphical output during the early phases of > the boot > process, before the native DRM drivers are available. Native > drivers are > typically loaded from an initrd ram disk. Occationally simplekms > can also > serve as interim solution on graphics hardware without native DRM > driver. Cool, thank you for doing this, this is a very welcome change, but ... (see below). > So far distributions rely on fbdev drivers, such as efifb, vesafb or > simplefb, for early-boot graphical output. However fbdev is > deprecated and > the drivers do not provide DRM interfaces for modern userspace. > > Patches 1 and 2 prepare the DRM format helpers for simplekms. > > Patches 3 to 7 add the simplekms driver. It's build on simple DRM > helpers > and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. > During > pageflips, SHMEM buffers are copied into the framebuffer memory, > similar > to cirrus or mgag200. The code in patches 6 and 7 handles clocks and > regulators. It's based on the simplefb drivers, but has been > modified for > DRM. > > Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's > framebuffer's I/O-memory range and provides a callback function to be > removed by a native driver. The native driver will remove simplekms > before > taking over the hardware. The removal is integrated into existing > helpers, > so drivers use it automatically. > > I tested simplekms with x86 EFI and VESA framebuffers, which both work > reliably. The fbdev console and Weston work automatically. Xorg > requires > manual configuration of the device. Xorgs current modesetting > driver does > not work with both, platform and PCI device, for the same physical > hardware. Once configured, X11 works. Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go around and break userspace. OTOH this does seem like an userspace issue and not something which we can (or should try to) fix in the kernel. I guess the solution will have to be to have this default to N for now in Kconfig and clearly mention in the Kconfig help text that this needs a fixed Xorg modesetting driver before it can be enabled. Any chance you have time to work on fixing the Xorg modesetting driver so that this will just work with the standard Xorg autoconfiguration stuff? >>> >>> Hm, why do we even have both platform and pci drivers visible at the >>> same time? I thought the point of this is that simplekms is built-in, >>> then initrd loads the real drm driver, and by the time Xorg is >>> running, simplekms should be long gone. >>> >>> Maybe a few more details of what's going wrong and why to help >>> unconfuse me? >> >> I tested simplekms with PCI graphics cards. >> >> Xorg does it's own scanning of the busses. It supports a platform bus, >> where it finds the simple-framebuffer device that is driven by >> simplekms. Xorg also scans the PCI bus, where is finds the native PCI >> device; usually driven by the native driver. It's the same hardware, but >> on different busses. >> >> For each device, Xorg tries to configure a screen, the Xorg modeset >> driver tried to open the DRM device file and acquire DRM master status >> on it. This works for the first screen, but DRM master status can only >> be acquired once, so it fails for the second screen. Xorg then aborts >> and asks for manual configuration of the display device. >> >> This can be solved by setting the platform device's bus id in the >> xorg.conf device section. It just doesn't happen automatically. >> >> I found it hard to find a solution to this. Weston just opens a DRM >> device file and uses whatever it gets. Ideally, Xorg would do the same. >> That whole bus-scanning exercise gives it a wrong idea on which graphics >> devices are available. >> >> One idea for a
Re: [Intel-gfx] [PATCH v7 17/17] drm/i915: Add HDCP 1.4 support for MST connectors
On 2020-06-23 at 21:29:07 +0530, Sean Paul wrote:
> From: Sean Paul
>
> Now that all the groundwork has been laid, we can turn on HDCP 1.4 over
> MST. Everything except for toggling the HDCP signalling and HDCP 2.2
> support is the same as the DP case, so we'll re-use those callbacks
>
> Cc: Juston Li
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191203173638.94919-12-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20191212190230.188505-13-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200117193103.156821-13-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-15-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-17-s...@poorly.run
> #v5
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-17-s...@poorly.run
> #v6
>
> Changes in v2:
> -Toggle HDCP from encoder disable/enable
> -Don't disable HDCP on MST connector destroy, leave that for encoder
> disable, just ensure the check_work routine isn't running any longer
> Changes in v3:
> -Place the shim in the new intel_dp_hdcp.c file (Ville)
> Changes in v4:
> -Actually use the mst shim for mst connections (Juston)
> -Use QUERY_STREAM_ENC_STATUS MST message to verify channel is encrypted
> Changes in v5:
> -Add sleep on disable signalling to match hdmi delay
> Changes in v6:
> -Disable HDCP over MST on GEN12+ since I'm unsure how it should work and I
> don't have hardware to test it
> Changes in v7:
> -Remove hdcp2 shims for MST in favor of skipping hdcp2 init (Ramalingam)
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 66 +++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 18 ++
> drivers/gpu/drm/i915/display/intel_hdcp.c| 2 +-
> 3 files changed, 84 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 43446a6cae8d..3f67bd27fc3c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -7,10 +7,12 @@
> */
>
> #include
> +#include
> #include
> #include
>
> #include "intel_display_types.h"
> +#include "intel_ddi.h"
> #include "intel_dp.h"
> #include "intel_hdcp.h"
>
> @@ -618,6 +620,65 @@ static const struct intel_hdcp_shim intel_dp_hdcp_shim =
> {
> .protocol = HDCP_PROTOCOL_DP,
> };
>
> +static int
> +intel_dp_mst_hdcp_toggle_signalling(struct intel_digital_port
> *intel_dig_port,
> + enum transcoder cpu_transcoder,
> + bool enable)
> +{
> + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> + int ret;
> +
> + if (!enable)
> + usleep_range(6, 60); /* Bspec says >= 6us */
> +
> + ret = intel_ddi_toggle_hdcp_signalling(_dig_port->base,
> +cpu_transcoder, enable);
> + if (ret)
> + drm_dbg_kms(>drm, "%s HDCP signalling failed (%d)\n",
> + enable ? "Enable" : "Disable", ret);
> + return ret;
> +}
> +
> +static
> +bool intel_dp_mst_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *connector)
> +{
> + struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> + struct intel_dp *intel_dp = _dig_port->dp;
> + struct drm_dp_query_stream_enc_status_ack_reply reply;
> + int ret;
> +
> + if (!intel_dp_hdcp_check_link(intel_dig_port, connector))
> + return false;
> +
> + ret = drm_dp_send_query_stream_enc_status(_dp->mst_mgr,
> + connector->port, );
> + if (ret) {
> + drm_dbg_kms(>drm,
> + "[CONNECTOR:%d:%s] failed QSES ret=%d\n",
> + connector->base.base.id, connector->base.name, ret);
> + return false;
> + }
> +
> + return reply.auth_completed && reply.encryption_enabled;
> +}
> +
> +static const struct intel_hdcp_shim intel_dp_mst_hdcp_shim = {
> + .write_an_aksv = intel_dp_hdcp_write_an_aksv,
> + .read_bksv = intel_dp_hdcp_read_bksv,
> + .read_bstatus = intel_dp_hdcp_read_bstatus,
> + .repeater_present = intel_dp_hdcp_repeater_present,
> + .read_ri_prime = intel_dp_hdcp_read_ri_prime,
> + .read_ksv_ready = intel_dp_hdcp_read_ksv_ready,
> + .read_ksv_fifo = intel_dp_hdcp_read_ksv_fifo,
> + .read_v_prime_part = intel_dp_hdcp_read_v_prime_part,
> + .toggle_signalling = intel_dp_mst_hdcp_toggle_signalling,
> + .check_link = intel_dp_mst_hdcp_check_link,
> + .hdcp_capable = intel_dp_hdcp_capable,
> +
> + .protocol = HDCP_PROTOCOL_DP,
> +};
> +
> int intel_dp_init_hdcp(struct intel_digital_port *intel_dig_port,
>
Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx
On 30/06/2020 21:26, Adam Ford wrote:
The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
number. Through experimentation, it appears that 31 works, and
it is consistent with the value used by the drm/omap driver.
This patch fixes the divider for fbdev driver instead of the drm.
Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: #4.9+
Signed-off-by: Adam Ford
---
Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
The DRM version of this same fix is:
e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 7252d22dd117..bfc5c4c5a26a 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -833,7 +833,7 @@ static const struct dss_features omap34xx_dss_feats = {
};
static const struct dss_features omap3630_dss_feats = {
- .fck_div_max= 32,
+ .fck_div_max= 31,
.dss_fck_multiplier = 1,
.parent_clk_name= "dpll4_ck",
.dpi_select_source = _dpi_select_source_omap2_omap3,
Reviewed-by: Tomi Valkeinen
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 12/14] drm/ast: Replace struct ast_crtc with struct drm_crtc
Hi Thomas. On Fri, Jul 03, 2020 at 08:51:31AM +0200, Thomas Zimmermann wrote: > Hi Sam > > Am 03.07.20 um 08:38 schrieb Sam Ravnborg: > > Hi Thomas. > > > > Just browsing code.. > > > > On Thu, Jul 02, 2020 at 01:50:27PM +0200, Thomas Zimmermann wrote: > >> Struct ast_crtc has been cleaned up and it's now a wrapper around the > >> DRM CRTC structure struct drm_crtc. This patch converts the driver to > >> struct drm_crtc and removes struct ast_crtc. > >> > >> Signed-off-by: Thomas Zimmermann > > > > Why is it we cannot embed struct drm_crtc? > > I want to do that in a later patchset. The conversion to managed code is > fairly large, so thought it might be better to do it in several rounds. Understood, and several rounds are good. > > This patchset is only for modesetting. I have another patchset that > converts the memory management to managed interfaces. After that the > final patchset will address device structures. Embedding everything CRTC > and other structures in struct ast_private would be part of this. > > If you prefer a longer patchset that does everything, let me know. > > > And I also failed to see where is is de-allocated - but surely I miss > > something obvious here. > > It's freed in ast_crtc_destroy(). Ohh, one of the places that worked/works because struct crtc was/is the first member. I get it now, thanks for the explanation. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 208179] [amdgpu] black screen after exiting X
https://bugzilla.kernel.org/show_bug.cgi?id=208179 Shlomo (shl...@fastmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #5 from Shlomo (shl...@fastmail.com) --- Fixed in Arch linux 5.7.7-arch1-1. Thank you. -- You are receiving this mail because: You are on the CC list for the bug. You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi, On 7/1/20 4:10 PM, Thomas Zimmermann wrote: Hi Daniel, thanks for reviewing most of the patchset. Am 30.06.20 um 11:06 schrieb Daniel Vetter: On Mon, Jun 29, 2020 at 11:39 AM Hans de Goede wrote: Hi, On 6/25/20 2:00 PM, Thomas Zimmermann wrote: This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. Cool, thank you for doing this, this is a very welcome change, but ... (see below). So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go around and break userspace. OTOH this does seem like an userspace issue and not something which we can (or should try to) fix in the kernel. I guess the solution will have to be to have this default to N for now in Kconfig and clearly mention in the Kconfig help text that this needs a fixed Xorg modesetting driver before it can be enabled. Any chance you have time to work on fixing the Xorg modesetting driver so that this will just work with the standard Xorg autoconfiguration stuff? Hm, why do we even have both platform and pci drivers visible at the same time? I thought the point of this is that simplekms is built-in, then initrd loads the real drm driver, and by the time Xorg is running, simplekms should be long gone. Maybe a few more details of what's going wrong and why to help unconfuse me? I tested simplekms with PCI graphics cards. Xorg does it's own scanning of the busses. It supports a platform bus, where it finds the simple-framebuffer device that is driven by simplekms. Xorg also scans the PCI bus, where is finds the native PCI device; usually driven by the native driver. It's the same hardware, but on different busses. For each device, Xorg tries to configure a screen, the Xorg modeset driver tried to open the DRM device file and acquire DRM master status on it. This works for the first screen, but DRM master status can only be acquired once, so it fails for the second screen. Xorg then aborts and asks for manual configuration of the display device. This can be solved by setting the platform device's bus id in the xorg.conf device section. It just doesn't happen automatically. I found it hard to find a solution to this. Weston just opens a DRM device file and uses whatever it gets. Ideally, Xorg would do the same. That whole bus-scanning exercise gives it a wrong idea on which graphics devices are available. One idea for a fix is to compare the device I/O-memory ranges and filter out duplicates on the Xorg modeset driver. I don't know how reliable this works in practice or if their are false positives. I think that this should work nicely, although I wonder how Xorg will get the memory-range for the simplefb platform device, it looks like it will need to parse /dev/iomem for this, or we need to add a new sysfs attr to the simplefb device for this. Adding the new sysfs attr has the added bonus that we only enable the duplicate based resource check for simplefb devices. Hmm, I think we can actually fix
Re: [RFC][PATCH 0/9] drm: Support simple-framebuffer devices and firmware fbs
Hi, On 7/1/20 3:48 PM, Thomas Zimmermann wrote: Hi Hans Am 29.06.20 um 11:38 schrieb Hans de Goede: Hi, On 6/25/20 2:00 PM, Thomas Zimmermann wrote: This patchset adds support for simple-framebuffer platform devices and a handover mechanism for native drivers to take-over control of the hardware. The new driver, called simplekms, binds to a simple-frambuffer platform device. The kernel's boot code creates such devices for firmware-provided framebuffers, such as EFI-GOP or VESA. Typically the BIOS, UEFI or boot loader sets up the framebuffers. Description via device tree is also an option. Simplekms is small enough to be linked into the kernel. The driver's main purpose is to provide graphical output during the early phases of the boot process, before the native DRM drivers are available. Native drivers are typically loaded from an initrd ram disk. Occationally simplekms can also serve as interim solution on graphics hardware without native DRM driver. Cool, thank you for doing this, this is a very welcome change, but ... (see below). So far distributions rely on fbdev drivers, such as efifb, vesafb or simplefb, for early-boot graphical output. However fbdev is deprecated and the drivers do not provide DRM interfaces for modern userspace. Patches 1 and 2 prepare the DRM format helpers for simplekms. Patches 3 to 7 add the simplekms driver. It's build on simple DRM helpers and SHMEM. It supports 16-bit, 24-bit and 32-bit RGB framebuffers. During pageflips, SHMEM buffers are copied into the framebuffer memory, similar to cirrus or mgag200. The code in patches 6 and 7 handles clocks and regulators. It's based on the simplefb drivers, but has been modified for DRM. Patches 8 and 9 add a hand-over mechanism. Simplekms acquires it's framebuffer's I/O-memory range and provides a callback function to be removed by a native driver. The native driver will remove simplekms before taking over the hardware. The removal is integrated into existing helpers, so drivers use it automatically. I tested simplekms with x86 EFI and VESA framebuffers, which both work reliably. The fbdev console and Weston work automatically. Xorg requires manual configuration of the device. Xorgs current modesetting driver does not work with both, platform and PCI device, for the same physical hardware. Once configured, X11 works. Ugh, Xorg not working OOTB is a bit of a showstopper, we cannot just go around and break userspace. OTOH this does seem like an userspace issue and not something which we can (or should try to) fix in the kernel. Xorg is an important use case, but simplekms does not "break userspace." If you're not using simplekms, nothing changes; if simplekms is replaced by the native driver, nothing changes. Simplekms works with Xorg of the device is auto-configured. Xorg is not able to auto-configure simplekms devices ATM. As I already mentioned in my replay to Daniel: If there is no native driver, or the native driver fails to load (e.g. nvidia binary driver dkms build fails with a nwer kernel) then having simplekms enables changes the user, experience from Xorg on fbdev, slow but usable to search for a solution to no GUI. I agree that we cannot solve this on the kernel side, but it is a real problem which we need to keep in mind. I guess the solution will have to be to have this default to N for now in Kconfig and clearly mention in the Kconfig help text that this needs a fixed Xorg modesetting driver before it can be enabled. Sure, but simplekms is just a driver. Shouldn't it default to N anyway? I guess so. Any chance you have time to work on fixing the Xorg modesetting driver so that this will just work with the standard Xorg autoconfiguration stuff? I'll do if somehow possible. See my reply to Daniel for a description of the problem. Great. One cosmetical issue is that simplekms's device file is card0 and the native driver's device file is card1. After simplekms has been kicked out, only card1 is left. This does not seem to be a practical problem however. TODO/IDEAS: * provide deferred takeover I assume you mean akin to CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ? I don't think you need to do anything for that, as long as you just leave the fb contents intact until requested to change it. Great. If it's that easy; even better. Right now with flickerfree boot we have fbcon on top of efifb and efifb does not do anything special wrt CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER ATM it does draw/restore the ACPI BGRT logo since since some firmwares don't draw that themselves, but that is not necessary in most cases and other then that all the deferred takeover magic is in the fbcon code, it does not bind to the fbdev (and thus does not draw to it) until the first time the kernel tries to output text to the console, together with the "quiet" kernel commandline argument that ensures that the fb is kept unmodified until e.g. a panic happens. With simplekms we would replace "fbcon
Re: [Intel-gfx] [PATCH v7 13/17] drm/i915: Plumb port through hdcp init
On 2020-06-23 at 21:29:03 +0530, Sean Paul wrote:
> From: Sean Paul
>
> This patch plumbs port through hdcp init instead of relying on
> intel_attached_encoder() to return a non-NULL encoder which won't work
> for MST connectors.
Looks good to me,
Reviewed-by: Anshuman Gupta
>
> Cc: Ville Syrjälä
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-13-s...@poorly.run
> #v5
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-13-s...@poorly.run
> #v6
>
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.c| 11 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.h| 2 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c| 2 +-
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 0e06a1066d61..e26a45f880cb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -630,7 +630,8 @@ int intel_dp_init_hdcp(struct intel_digital_port
> *intel_dig_port,
> return 0;
>
> if (!intel_dp_is_edp(intel_dp))
> - return intel_hdcp_init(intel_connector, _dp_hdcp_shim);
> + return intel_hdcp_init(intel_connector, port,
> +_dp_hdcp_shim);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index 5679877c6b4c..d79d4142aea7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -1955,6 +1955,7 @@ static enum mei_fw_tc intel_get_mei_fw_tc(enum
> transcoder cpu_transcoder)
> }
>
> static int initialize_hdcp_port_data(struct intel_connector *connector,
> + enum port port,
>const struct intel_hdcp_shim *shim)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -1962,8 +1963,7 @@ static int initialize_hdcp_port_data(struct
> intel_connector *connector,
> struct hdcp_port_data *data = >port_data;
>
> if (INTEL_GEN(dev_priv) < 12)
> - data->fw_ddi =
> -
> intel_get_mei_fw_ddi_index(intel_attached_encoder(connector)->port);
> + data->fw_ddi = intel_get_mei_fw_ddi_index(port);
> else
> /*
>* As per ME FW API expectation, for GEN 12+, fw_ddi is filled
> @@ -2033,14 +2033,14 @@ void intel_hdcp_component_init(struct
> drm_i915_private *dev_priv)
> }
> }
>
> -static void intel_hdcp2_init(struct intel_connector *connector,
> +static void intel_hdcp2_init(struct intel_connector *connector, enum port
> port,
>const struct intel_hdcp_shim *shim)
> {
> struct drm_i915_private *i915 = to_i915(connector->base.dev);
> struct intel_hdcp *hdcp = >hdcp;
> int ret;
>
> - ret = initialize_hdcp_port_data(connector, shim);
> + ret = initialize_hdcp_port_data(connector, port, shim);
> if (ret) {
> drm_dbg_kms(>drm, "Mei hdcp data init failed\n");
> return;
> @@ -2050,6 +2050,7 @@ static void intel_hdcp2_init(struct intel_connector
> *connector,
> }
>
> int intel_hdcp_init(struct intel_connector *connector,
> + enum port port,
> const struct intel_hdcp_shim *shim)
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> @@ -2060,7 +2061,7 @@ int intel_hdcp_init(struct intel_connector *connector,
> return -EINVAL;
>
> if (is_hdcp2_supported(dev_priv))
> - intel_hdcp2_init(connector, shim);
> + intel_hdcp2_init(connector, port, shim);
>
> ret =
> drm_connector_attach_content_protection_property(>base,
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.h
> b/drivers/gpu/drm/i915/display/intel_hdcp.h
> index 86bbaec120cc..1bbf5b67ed0a 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> @@ -22,7 +22,7 @@ enum transcoder;
> void intel_hdcp_atomic_check(struct drm_connector *connector,
>struct drm_connector_state *old_state,
>struct drm_connector_state *new_state);
> -int intel_hdcp_init(struct intel_connector *connector,
> +int intel_hdcp_init(struct intel_connector *connector, enum port port,
> const struct intel_hdcp_shim *hdcp_shim);
> int intel_hdcp_enable(struct intel_connector *connector,
> enum transcoder cpu_transcoder, u8 content_type);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index
Re: [Intel-gfx] [PATCH v7 14/17] drm/i915: Add connector to hdcp_shim->check_link()
On 2020-06-23 at 21:29:04 +0530, Sean Paul wrote:
> From: Sean Paul
>
> Currently we derive the connector from digital port in check_link(). For
> MST, this isn't sufficient since the digital port passed into the
> function can have multiple connectors downstream. This patch adds
> connector to the check_link() arguments so we have it when we need it.
>
> Signed-off-by: Sean Paul
Looks good to me, this require a rebase on latest drm-tip
Reviewed-by: Anshuman Gupta
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-13-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-14-s...@poorly.run
> #v5
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-14-s...@poorly.run
> #v6
>
> Changes in v4:
> -Added to the set
> Changes in v5:
> -None
> Changes in v6:
> -None
> Changes in v7:
> -None
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 3 ++-
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 5 ++---
> 4 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 811085ef3fba..94211b8fc159 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -318,7 +318,8 @@ struct intel_hdcp_shim {
>bool enable);
>
> /* Ensures the link is still protected */
> - bool (*check_link)(struct intel_digital_port *intel_dig_port);
> + bool (*check_link)(struct intel_digital_port *intel_dig_port,
> +struct intel_connector *connector);
>
> /* Detects panel's hdcp capability. This is optional for HDMI. */
> int (*hdcp_capable)(struct intel_digital_port *intel_dig_port,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index e26a45f880cb..43446a6cae8d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -223,7 +223,8 @@ int intel_dp_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,
> }
>
> static
> -bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port)
> +bool intel_dp_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *connector)
> {
> struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> ssize_t ret;
> diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_hdcp.c
> index d79d4142aea7..6bd0e4616ee1 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> @@ -953,7 +953,7 @@ static int intel_hdcp_check_link(struct intel_connector
> *connector)
> goto out;
> }
>
> - if (hdcp->shim->check_link(intel_dig_port)) {
> + if (hdcp->shim->check_link(intel_dig_port, connector)) {
> if (hdcp->value != DRM_MODE_CONTENT_PROTECTION_UNDESIRED) {
> intel_hdcp_update_value(connector,
> DRM_MODE_CONTENT_PROTECTION_ENABLED, true);
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index ca71ee3dd1c7..b12f1af0611d 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1546,11 +1546,10 @@ int intel_hdmi_hdcp_toggle_signalling(struct
> intel_digital_port *intel_dig_port,
> }
>
> static
> -bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port)
> +bool intel_hdmi_hdcp_check_link(struct intel_digital_port *intel_dig_port,
> + struct intel_connector *connector)
> {
> struct drm_i915_private *i915 = to_i915(intel_dig_port->base.base.dev);
> - struct intel_connector *connector =
> - intel_dig_port->hdmi.attached_connector;
> enum port port = intel_dig_port->base.port;
> enum transcoder cpu_transcoder = connector->hdcp.cpu_transcoder;
> int ret;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: auo,b116xw03: fix flash backlight when power on
Delay the backlight on to make sure the video stable.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3ad828eaefe1..18f34f286d3d 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -734,6 +734,9 @@ static const struct panel_desc auo_b116xw03 = {
.width = 256,
.height = 144,
},
+ .delay = {
+ .enable = 400,
+ },
};
static const struct drm_display_mode auo_b133xtn01_mode = {
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
Thanks for the update!
The driver should also disallow importing a AMLOGIC_FBC_LAYOUT_SCATTER
DMA-BUF from another device, but I guess this is clear enough ("not
transferrable between Amlogic SoCs").
>From a user-space PoV:
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 204609] amdgpu: powerplay failed send message
https://bugzilla.kernel.org/show_bug.cgi?id=204609 --- Comment #8 from Mikhail Tuchkov (tuchkov.mikh...@gmail.com) --- Created attachment 290075 --> https://bugzilla.kernel.org/attachment.cgi?id=290075=edit dmesg -- 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 204609] amdgpu: powerplay failed send message
https://bugzilla.kernel.org/show_bug.cgi?id=204609 Mikhail Tuchkov (tuchkov.mikh...@gmail.com) changed: What|Removed |Added CC||tuchkov.mikh...@gmail.com --- Comment #7 from Mikhail Tuchkov (tuchkov.mikh...@gmail.com) --- Same hardware: Sapphire RX 5700 and X570 and similar issues with GPU. Attaching dmesg output -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers
Hi Niklas,
On 02/07/2020 23:51, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Mon, May 25, 2020 at 01:31:43PM +0300, Sakari Ailus wrote:
>> On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
>>> Bayer formats are used with cameras and contain green, red and blue
>>> components, with alternating lines of red and green, and blue and green
>>> pixels in different orders. For each block of 2x2 pixels there is one
>>> pixel with a red filter, two with a green filter, and one with a blue
>>> filter. The filters can be arranged in different patterns.
>>>
>>> Add DRM fourcc formats to describe the most common Bayer formats. Also
>>> add a modifiers to describe the custom packing layouts used by the Intel
>>> IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
>>> specification.
>>>
>>> Signed-off-by: Niklas Söderlund
>>> ---
>>> * Changes since v1
>>> - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
>>> - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
>>> - Add diagrams for all Bayer formats memory layout.
>>> - Update documentation.
>>> ---
>>> include/uapi/drm/drm_fourcc.h | 205 ++
>>> 1 file changed, 205 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
>>> index 8bc0b31597d80737..d07dd24b49bde6c1 100644
>>> --- a/include/uapi/drm/drm_fourcc.h
>>> +++ b/include/uapi/drm/drm_fourcc.h
>>> @@ -285,6 +285,73 @@ extern "C" {
>>> #define DRM_FORMAT_YUV444 fourcc_code('Y', 'U', '2', '4') /*
>>> non-subsampled Cb (1) and Cr (2) planes */
>>> #define DRM_FORMAT_YVU444 fourcc_code('Y', 'V', '2', '4') /*
>>> non-subsampled Cr (1) and Cb (2) planes */
>>>
>>> +/*
>>> + * Bayer formats
>>> + *
>>> + * Bayer formats contain green, red and blue components, with alternating
>>> lines
>>> + * of red and green, and blue and green pixels in different orders. For
>>> each
>>> + * block of 2x2 pixels there is one pixel with a red filter, two with a
>>> green
>>> + * filter, and one with a blue filter. The filters can be arranged in
>>> different
>>> + * patterns.
>>> + *
>>> + * For example, RGGB:
>>> + * row0: RGRGRGRG...
>>> + * row1: GBGBGBGB...
>>> + * row2: RGRGRGRG...
>>> + * row3: GBGBGBGB...
>>> + * ...
>>> + *
>>> + * Vendors have different methods to pack the pixel samples. For this
>>> reason the
>>> + * fourcc only describes pixel sample size and the filter pattern for each
>>> block
>>> + * of 2x2 pixels. A modifier is needed to describe the memory layout.
>>> + *
>>> + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR
>>> may
>>> + * be used to describe a layout where all samples are placed consecutively
>>> in
>>> + * memory. If the sample does not fit inside a single byte each sample is
>>> stored
>>> + * in the minimum number of bytes required. Any unused bits in each sample
>>> are
>>> + * defined as padding bits and set to zero.
>>> + *
>>> + * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
>>> + *
>>> + * 0 row 0 (RGRG)
>>> 31
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | r0 r0 r0 r0 r0 r0 r0 r0 | 0 0 0 0 0 0 r0 r0 | g0 g0 g0 g0 g0
>>> g0 g0 g0 | 0 0 0 0 0 0 g0 g0 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | r1 r1 r1 r1 r1 r1 r1 r1 | 0 0 0 0 0 0 r1 r1 | g1 g1 g1 g1 g1
>>> g1 g1 g1 | 0 0 0 0 0 0 g1 g1 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + *
>>> + * 0 row 1 (GBGB)
>>> 31
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | g0 g0 g0 g0 g0 g0 g0 g0 | 0 0 0 0 0 0 g0 g0 | b0 b0 b0 b0 b0
>>> b0 b0 b0 | 0 0 0 0 0 0 b0 b0 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + * | g1 g1 g1 g1 g1 g1 g1 g1 | 0 0 0 0 0 0 g1 g1 | b1 b1 b1 b1 b1
>>> b1 b1 b1 | 0 0 0 0 0 0 b1 b1 |
>>> + * + - - - - - - - - + - - - - - - - - + - - - - -
>>> - - - + - - - - - - - - +
>>> + */
>>> +
>>> +/* 8-bits Bayer formats */
>>> +#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
>>> +#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
>>> +#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
>>> +#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
>>> +
>>> +/* 10-bit Bayer formats */
>>> +#define DRM_FORMAT_BAYER_RGGB10fourcc_code('R', 'G', '1', '0')
>>>
Re: [PATCH v9 0/6] drm/meson: add support for Amlogic Video FBC
On 03/07/2020 10:07, Neil Armstrong wrote: > Amlogic uses a proprietary lossless image compression protocol and format > for their hardware video codec accelerators, either video decoders or > video input encoders. > > It considerably reduces memory bandwidth while writing and reading > frames in memory. > > The underlying storage is considered to be 3 components, 8bit or 10-bit > per component, YCbCr 420, single plane : > - DRM_FORMAT_YUV420_8BIT > - DRM_FORMAT_YUV420_10BIT > > This modifier will be notably added to DMA-BUF frames imported from the V4L2 > Amlogic VDEC decoder. > > At least two layout are supported : > - Basic: composed of a body and a header > - Scatter: the buffer is filled with a IOMMU scatter table referring > to the encoder current memory layout. This mode if more efficient in terms > of memory allocation but frames are not dumpable and only valid during until > the buffer is freed and back in control of the encoder > > At least two options are supported : > - Memory saving: when the pixel bpp is 8b, the size of the superblock can > be reduced, thus saving memory. > > This serie adds the missing register, updated the FBC decoder registers > content to be committed by the crtc code. > > The Amlogic FBC has been tested with compressed content from the Amlogic > HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit > (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit > (Scatter on G12A/SM1, default on GXL). > > It's expected to work as-is on GXM and G12B SoCs. > > Changes since v8 at [8]: > - added clarification of scatter mmap behavior as suggested by daniel > - added ack and review tags > > Changes since v7 at [7]: > - rebased on drm-misc-next > - removed spurious DEBUG in drivers/gpu/drm/meson/meson_overlay.c > > Changes since v6 at [6]: > - rebased on drm-misc-next (after drm-misc-next-2020-05-14) > - updated patch 1 commit log for completion > > Changes since v5 at [5]: > - merged all fourcc patches in 1 > - fixed fourcc definition to have only a single DRM_MOD_ > - fixed 2 checkpatch issues > > Changes since v4 at [4]: > - added layout and options mask > - cosmetic changes in fourcc.h > - fixed mod check using the masks > - fixed plane apply using the masks > > Changes since v3 at [3]: > - added dropped fourcc patch for scatter > - fixed build of last patch > > Changes since v2 at [2]: > - Added "BASIC" layout and moved the SCATTER mode as layout, making > BASIC and SCATTER layout exclusives > - Moved the Memory Saving at bit 8 for options fields > - Split fourcc and overlay patch to introduce basic, mem saving and then > scatter in separate patches > - Added comment about "transferability" of the buffers > > Changes since v1 at [1]: > - s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h > > [1] https://patchwork.freedesktop.org/series/73722/#rev1 > [2] https://patchwork.freedesktop.org/series/73722/#rev2 > [3] https://patchwork.freedesktop.org/series/73722/#rev3 > [4] https://patchwork.freedesktop.org/series/73722/#rev4 > [5] https://patchwork.freedesktop.org/series/73722/#rev5 > [6] https://patchwork.freedesktop.org/series/73722/#rev6 > [7] https://patchwork.freedesktop.org/series/73722/#rev7 > [7] https://patchwork.freedesktop.org/series/73722/#rev8 > > Neil Armstrong (6): > drm/fourcc: Add modifier definitions for describing Amlogic Video > Framebuffer Compression > drm/meson: add Amlogic Video FBC registers > drm/meson: overlay: setup overlay for Amlogic FBC > drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode > drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory > layout > drm/meson: crtc: handle commit of Amlogic FBC frames > > drivers/gpu/drm/meson/meson_crtc.c | 118 +++--- > drivers/gpu/drm/meson/meson_drv.h | 16 ++ > drivers/gpu/drm/meson/meson_overlay.c | 289 +++- > drivers/gpu/drm/meson/meson_registers.h | 22 ++ > include/uapi/drm/drm_fourcc.h | 81 +++ > 5 files changed, 488 insertions(+), 38 deletions(-) > Applied to drm-misc-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 12/13] arm64: dts: sun50i-a64-pinephone: Enable LCD support on PinePhone
On Wed, Jul 01, 2020 at 06:29:27PM +0200, Ondrej Jirman wrote:
> From: Icenowy Zheng
>
> PinePhone uses PWM backlight and a XBD599 LCD panel over DSI for
> display.
>
> Backlight levels curve was optimized by Martijn Braam using a
> lux meter.
>
> Add its device nodes.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Martijn Braam
> Signed-off-by: Ondrej Jirman
> Acked-by: Linus Walleij
> ---
> .../allwinner/sun50i-a64-pinephone-1.1.dts| 19 ++
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 35 +++
> 2 files changed, 54 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> index 06a775c41664..3e99a87e9ce5 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.1.dts
> @@ -9,3 +9,22 @@ / {
> model = "Pine64 PinePhone Braveheart (1.1)";
> compatible = "pine64,pinephone-1.1", "allwinner,sun50i-a64";
> };
> +
> + {
> + power-supply = <_ldo_io0>;
> + /*
> + * PWM backlight circuit on this PinePhone revision was changed since
> + * 1.0, and the lowest PWM duty cycle that doesn't lead to backlight
> + * being off is around 20%. Duty cycle for the lowest brightness level
> + * also varries quite a bit between individual boards, so the lowest
> + * value here was chosen as a safe default.
> + */
> + brightness-levels = <
> + 774 793 814 842
> + 882 935 1003 1088
> + 1192 1316 1462 1633
> + 1830 2054 2309 2596
> + 2916 3271 3664 4096>;
> + num-interpolated-steps = <50>;
> + default-brightness-level = <400>;
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> index cefda145c3c9..85a7aa5efd32 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
> @@ -16,6 +16,13 @@ aliases {
> serial0 =
> };
>
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <_pwm 0 5 PWM_POLARITY_INVERTED>;
> + enable-gpios = < 7 10 GPIO_ACTIVE_HIGH>; /* PH10 */
> + /* Backlight configuration differs per PinePhone revision. */
> + };
> +
> chosen {
> stdout-path = "serial0:115200n8";
> };
> @@ -84,6 +91,30 @@ {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + vcc-dsi-supply = <_dldo1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
If you're about to send a new version, you can remove #address-cells and
#size-cells too, they're already set in the DTSI.
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fbdev: da8xx-fb: go to proper label on error handling paths in probe
fb_probe() can successfully allocate a new frame buffer, but then fail
to perform some operations with regulator. In these cases fb_probe()
goes to label err_pm_runtime_disable where the frame buffer is not
released. The patch makes fb_probe() to go to label err_release_fb on
corresponding error handling paths.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov
---
drivers/video/fbdev/da8xx-fb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/da8xx-fb.c b/drivers/video/fbdev/da8xx-fb.c
index 73c3c4c8cc12..e38c0e3f9c61 100644
--- a/drivers/video/fbdev/da8xx-fb.c
+++ b/drivers/video/fbdev/da8xx-fb.c
@@ -1402,14 +1402,14 @@ static int fb_probe(struct platform_device *device)
if (IS_ERR(par->lcd_supply)) {
if (PTR_ERR(par->lcd_supply) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
- goto err_pm_runtime_disable;
+ goto err_release_fb;
}
par->lcd_supply = NULL;
} else {
ret = regulator_enable(par->lcd_supply);
if (ret)
- goto err_pm_runtime_disable;
+ goto err_release_fb;
}
fb_videomode_to_var(_fb_var, lcdc_info);
--
2.16.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: fix wrong return value in dpu_encoder_init()
On 2020/7/2 22:04, Markus Elfring wrote: A positive value ENOMEM is returned here. I thinr this is a typo error. It is necessary to return a negative error value. I imagine that a small adjustment could be nice for this change description. How do you think about to follow progress for the integration of a previous patch like “[RESEND] drm/msm/dpu: fix error return code in dpu_encoder_init”? https://lore.kernel.org/dri-devel/20200618062803.152097-1-chentao...@huawei.com/ https://lore.kernel.org/patchwork/patch/1257957/ https://lkml.org/lkml/2020/6/18/46 Regards, Markus This is the same fix, please ignore this patch. Thanks, Tianjia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml
On Thu, Jul 02, 2020 at 02:51:43PM -0600, Rob Herring wrote: > On Wed, 01 Jul 2020 18:29:17 +0200, Ondrej Jirman wrote: > > Convert Rocktech MIPI DSI panel driver from txt to yaml bindings. > > > > Signed-off-by: Ondrej Jirman > > --- > > .../display/panel/rocktech,jh057n00900.txt| 23 --- > > .../display/panel/rocktech,jh057n00900.yaml | 66 +++ > > 2 files changed, 66 insertions(+), 23 deletions(-) > > delete mode 100644 > > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt > > create mode 100644 > > Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml > > > > > My bot found errors running 'make dt_binding_check' on your patch: > > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of the > regexes: 'pinctrl-[0-9]+' > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: 'vcc-supply' is a required property > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: 'iovcc-supply' is a required property > /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml: > panel@0: 'reset-gpios' is a required property Paths look bogus It should be .../rocktech,jh057n00900.yaml: ... regards, o. > > See https://patchwork.ozlabs.org/patch/1320690 > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure dt-schema is up to date: > > pip3 install git+https://github.com/devicetree-org/dt-schema.git@master > --upgrade > > Please check and re-submit. > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset
On Wed, Jul 01, 2020 at 05:21:38PM -0400, Jim Quinlan wrote: > The new field 'dma_range_map' in struct device is used to facilitate the > use of single or multiple offsets between mapping regions of cpu addrs and > dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only > capable of holding a single uniform offset and had no region bounds > checking. > > The function of_dma_get_range() has been modified so that it takes a single > argument -- the device node -- and returns a map, NULL, or an error code. > The map is an array that holds the information regarding the DMA regions. > Each range entry contains the address offset, the cpu_start address, the > dma_start address, and the size of the region. > > of_dma_configure() is the typical manner to set range offsets but there are > a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel > driver code. These cases now invoke the function > dma_attach_offset_range(dev, cpu_addr, dma_addr, size). ... > + if (dev && dev->dma_range_map) > + pfn -= (unsigned long)PFN_DOWN(dma_offset_from_phys_addr(dev, > PFN_PHYS(pfn))); Instead of casting use PHYS_PFN() and it will be consistent with latter in the same line. > + if (dev && dev->dma_range_map) > + pfn += (unsigned long)PFN_DOWN(dma_offset_from_dma_addr(dev, > addr)); Ditto. ... > + dev_err(dev, "set dma_offset%08llx%s\n", > KEYSTONE_HIGH_PHYS_START > + - KEYSTONE_LOW_PHYS_START, ret ? " failed" : ""); Please, avoid such indentation. Better split it to the three lines, argument per line (expect dev which will go on the first one). This applies to all similar places. ... > unsigned long pfn = (dma_handle >> PAGE_SHIFT); PHYS_PFN() / PFN_DOWN() ? > + if (!WARN_ON(!dev) && dev->dma_range_map) > + pfn += (unsigned long)PFN_DOWN(dma_offset_from_dma_addr(dev, > dma_handle)); PHYS_PFN() ? ... > + r = kcalloc(num_ranges + 1, sizeof(struct bus_dma_region), GFP_KERNEL); sizeof(*r) ? > + if (!r) > + return ERR_PTR(-ENOMEM); ... > + ret = IS_ERR(map) ? PTR_ERR(map) : 0; PTR_ERR_OR_ZERO() ... > + /* We want the offset map to be device-managed, so alloc & copy > */ > + dev->dma_range_map = devm_kcalloc(dev, num_ranges + 1, > sizeof(*r), > + GFP_KERNEL); The question is how many times per device lifetime this can be called? ... > + if (!dev->dma_range_map) > + return -ENOMEM; > + memcpy((void *)dev->dma_range_map, map, sizeof(*r) * num_ranges > + 1); If it's continuous, perhaps kmemdup() ? ... > + rc = IS_ERR(map) ? PTR_ERR(map) : 0; PTR_ERR_OR_ZERO() ... > + = dma_offset_from_phys_addr(dev, > PFN_PHYS(mem->pfn_base)); > + > + return (dma_addr_t)PFN_PHYS(mem->pfn_base) - dma_offset; Looking at this more, I think you need to introduce in the same header (pfn.h) something like: #define PFN_DMA_ADDR() #define DMA_ADDR_PFN() -- With Best Regards, Andy Shevchenko ___ 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
Hi Sylwester,
On 7/2/20 15:01, Sylwester Nawrocki wrote:
> Hi Georgi,
>
> On 01.07.2020 14:50, Georgi Djakov wrote:
>> Thanks for the patch and apologies for the delayed reply.
>
> Thanks, no problem. It's actually just in time as I put that patchset
> aside for a while and was just about to post an update.
>
>> On 5/29/20 19:31, 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
>
>>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>>> +{
>>> + struct of_phandle_args args;
>>> + int num, ret;
>>> +
>>> + num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
>>> + "#interconnect-cells");
>>> + if (num != 1)
>>> + return NULL; /* parent nodes are optional */
>>> +
>>> + ret = of_parse_phandle_with_args(np, "samsung,interconnect-parent",
>>> + "#interconnect-cells", 0, );
>>> + if (ret < 0)
>>> + return ERR_PTR(ret);
>>> +
>>> + of_node_put(args.np);
>>> +
>>> + return of_icc_get_from_provider();
>>> +}
>>> +
>>> +
>>
>> Nit: multiple blank lines
>
> Fixed.
>
>> [..]
>>> +static struct icc_node *exynos_generic_icc_xlate(struct of_phandle_args
>>> *spec,
>>> +void *data)
>>> +{
>>> + struct exynos_icc_priv *priv = data;
>>> +
>>> + if (spec->np != priv->dev->parent->of_node)
>>> + return ERR_PTR(-EINVAL);
>>> +
>>> + return priv->node;
>>> +}
>>> +
>>> +static int exynos_generic_icc_remove(struct platform_device *pdev)
>>> +{
>>> + struct exynos_icc_priv *priv = platform_get_drvdata(pdev);
>>> + struct icc_node *parent_node, *node = priv->node;
>>> +
>>> + parent_node = exynos_icc_get_parent(priv->dev->parent->of_node);
>>> + if (parent_node && !IS_ERR(parent_node))
>>
>> Nit: !IS_ERR_OR_NULL?
>
> It was left on purpose that way but I changed it now to IS_ERR_OR_NULL.
Well, i have no strong opinion on that, it's up to you.
>>> + icc_link_destroy(node, parent_node);
>>> +
>>> + icc_nodes_remove(>provider);
>>> + icc_provider_del(>provider);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int exynos_generic_icc_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *bus_dev = pdev->dev.parent;
>>> + struct exynos_icc_priv *priv;
>>> + struct icc_provider *provider;
>>> + struct icc_node *icc_node, *icc_parent_node;
>>> + int ret;
>>> +
>>> + priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>>> + if (!priv)
>>> + return -ENOMEM;
>>> +
>>> + priv->dev = >dev;
>>> + platform_set_drvdata(pdev, priv);
>>> +
>>> + provider = >provider;
>>> +
>>> + provider->set = exynos_generic_icc_set;
>>> + provider->aggregate = icc_std_aggregate;
>>> + provider->xlate = exynos_generic_icc_xlate;
>>> + provider->dev = bus_dev;
>>> + provider->inter_set = true;
>>> + provider->data = priv;
>>> +
>>> + ret = icc_provider_add(provider);
>>
>> Nit: Maybe it would be better to move this after the node is created. The
>> idea is to create the nodes first and add the provider when the topology is
>> populated. It's fine either way here, but i am planning to change this in
>> some of the existing provider drivers.
>
> OK, it makes the clean up path a bit less straightforward. And still we need
> to register the provider before calling icc_node_add().
> I made a change as below.
>
> --8<--
> @@ -124,14 +123,14 @@ static int exynos_generic_icc_probe(struct
> platform_device *pdev)
> provider->inter_set = true;
> provider->data = priv;
>
> + icc_node = icc_node_create(pdev->id);
> + if (IS_ERR(icc_node))
> + return PTR_ERR(icc_node);
> +
> ret = icc_provider_add(provider);
> - if (ret < 0)
> + if (ret < 0) {
> + icc_node_destroy(icc_node->id);
> return ret;
>
答复: [PATCH v2] drm/hisilicon: Use drmm_kzalloc() instead of devm_kzalloc()
Hi:
I am sorry for misunderstood you suggests. I will send v3 to fixed this.
Best
-邮件原件-
发件人: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
发送时间: 2020年7月2日 15:20
收件人: tiantao (H) ; Chenfeng (puck)
; airl...@linux.ie; dan...@ffwll.ch;
kra...@redhat.com; alexander.deuc...@amd.com; t...@linutronix.de;
dri-devel@lists.freedesktop.org; xinliang@linaro.org;
linux-ker...@vger.kernel.org
抄送: Linuxarm
主题: Re: [PATCH v2] drm/hisilicon: Use drmm_kzalloc() instead of devm_kzalloc()
Hi
Am 02.07.20 um 09:06 schrieb Tian Tao:
> using the new API drmm_kzalloc() instead of devm_kzalloc()
>
> v2:
> keep the DRM include statements sorted alphabetically.
>
> Signed-off-by: Tian Tao
> Reviewed-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 18
> +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index a6fd0c2..b557728 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -11,18 +11,18 @@
> * Jianhua Li
> */
>
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> #include
> #include
> -#include
> -
> -#include
> #include
> -#include
> -#include
> #include
> -#include
> -#include
> -#include
> +#include
Ok, that's a bit too much. :D
First of all, it's still not alphabetically. Second, linux headers go first,
then drm headers follow. It should look like
#include
#include
#include
#include
#include
#include
with each block sorted alphabetically.
If you include drm_managed.h right before drm_print.h, it should be fine
already.
Best regards
Thomas
>
> #include "hibmc_drm_drv.h"
> #include "hibmc_drm_regs.h"
> @@ -267,7 +267,7 @@ static int hibmc_load(struct drm_device *dev)
> struct hibmc_drm_private *priv;
> int ret;
>
> - priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
> + priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv) {
> DRM_ERROR("no memory to allocate for hibmc_drm_private\n");
> return -ENOMEM;
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
Hi Sylwester, On 7/3/20 1:37 AM, Sylwester Nawrocki wrote: > Add documentation for new optional properties in the exynos bus nodes: > samsung,interconnect-parent, #interconnect-cells, bus-width. > 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 v6: > - added dts example of bus hierarchy definition and the interconnect >consumer, > - added new bus-width property. > > Changes for v5: > - exynos,interconnect-parent-node renamed to samsung,interconnect-parent > --- > .../devicetree/bindings/devfreq/exynos-bus.txt | 68 > +- > 1 file changed, 66 insertions(+), 2 deletions(-) Acked-by: Chanwoo Choi (snip) -- Best Regards, Chanwoo Choi Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm : Insert blank lines after declarations.
Resolve checkpatch issues for missing blank lines after declarations.
Issues found in multiple files with checkpatch.pl.
Signed-off-by: Suraj Upadhyay
---
Contributor comments : Hii developers, I am a new contributor to linux
kernel. This email is over 600 lines however the changes are very small.
Please, tell me if I should send the changes in a patchset.
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_uapi.c | 7 +++
drivers/gpu/drm/drm_bufs.c| 6 ++
drivers/gpu/drm/drm_connector.c | 2 ++
drivers/gpu/drm/drm_crtc.c| 1 +
drivers/gpu/drm/drm_crtc_helper.c | 3 +++
drivers/gpu/drm/drm_dp_helper.c | 1 +
drivers/gpu/drm/drm_dp_mst_topology.c | 20
drivers/gpu/drm/drm_edid.c| 17 +
drivers/gpu/drm/drm_file.c| 2 ++
drivers/gpu/drm/drm_framebuffer.c | 1 +
drivers/gpu/drm/drm_ioc32.c | 2 ++
drivers/gpu/drm/drm_lease.c | 4
drivers/gpu/drm/drm_lock.c| 1 +
drivers/gpu/drm/drm_mode_config.c | 1 +
drivers/gpu/drm/drm_pci.c | 1 +
drivers/gpu/drm/drm_plane.c | 1 +
drivers/gpu/drm/drm_prime.c | 1 +
drivers/gpu/drm/drm_syncobj.c | 1 +
drivers/gpu/drm/drm_vblank.c | 1 +
20 files changed, 74 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 965173fd0ac2..58527f151984 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -575,6 +575,7 @@ static int drm_atomic_plane_check(const struct
drm_plane_state *old_plane_state,
fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
+
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] invalid pixel format %s,
modifier 0x%llx\n",
plane->base.id, plane->name,
drm_get_format_name(fb->format->format,
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index a1e5e262bae2..25c269bc4681 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -522,6 +522,7 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
if (property == config->prop_fb_id) {
struct drm_framebuffer *fb;
+
fb = drm_framebuffer_lookup(dev, file_priv, val);
drm_atomic_set_fb_for_plane(state, fb);
if (fb)
@@ -539,6 +540,7 @@ static int drm_atomic_plane_set_property(struct drm_plane
*plane,
} else if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+
if (val && !crtc)
return -EACCES;
return drm_atomic_set_crtc_for_plane(state, crtc);
@@ -681,6 +683,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
if (property == config->prop_crtc_id) {
struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
+
if (val && !crtc)
return -EACCES;
return drm_atomic_set_crtc_for_connector(state, crtc);
@@ -754,6 +757,7 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb;
int ret;
+
fb = drm_framebuffer_lookup(dev, file_priv, val);
ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
if (fb)
@@ -861,6 +865,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
switch (obj->type) {
case DRM_MODE_OBJECT_CONNECTOR: {
struct drm_connector *connector = obj_to_connector(obj);
+
WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
ret = drm_atomic_connector_get_property(connector,
connector->state, property, val);
@@ -868,6 +873,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
}
case DRM_MODE_OBJECT_CRTC: {
struct drm_crtc *crtc = obj_to_crtc(obj);
+
WARN_ON(!drm_modeset_is_locked(>mutex));
ret = drm_atomic_crtc_get_property(crtc,
crtc->state, property, val);
@@ -875,6 +881,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
}
case DRM_MODE_OBJECT_PLANE: {
struct drm_plane *plane = obj_to_plane(obj);
+
WARN_ON(!drm_modeset_is_locked(>mutex));
ret = drm_atomic_plane_get_property(plane,
plane->state, property, val);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index ef26ac57f039..a0735fbc144b 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++
[PATCH v3] drm/hisilicon: Code refactoring for hibmc_drv_vdac
code refactoring for hibmc_drv_vdac.c, no actual function changes.
v2:
remove the debug message.
v3:
embedding connector and encoder in struct hibmc_drm_private.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 52 +---
2 files changed, 13 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
index 50a0c1f..6097687 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
@@ -29,6 +29,8 @@ struct hibmc_drm_private {
/* drm */
struct drm_device *dev;
+ struct drm_encoder encoder;
+ struct drm_connector connector;
bool mode_config_initialized;
};
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
index 678ac2e..2ca69c3 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
@@ -52,32 +52,6 @@ static const struct drm_connector_funcs
hibmc_connector_funcs = {
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
-static struct drm_connector *
-hibmc_connector_init(struct hibmc_drm_private *priv)
-{
- struct drm_device *dev = priv->dev;
- struct drm_connector *connector;
- int ret;
-
- connector = devm_kzalloc(dev->dev, sizeof(*connector), GFP_KERNEL);
- if (!connector) {
- DRM_ERROR("failed to alloc memory when init connector\n");
- return ERR_PTR(-ENOMEM);
- }
-
- ret = drm_connector_init(dev, connector,
-_connector_funcs,
-DRM_MODE_CONNECTOR_VGA);
- if (ret) {
- DRM_ERROR("failed to init connector: %d\n", ret);
- return ERR_PTR(ret);
- }
- drm_connector_helper_add(connector,
-_connector_helper_funcs);
-
- return connector;
-}
-
static void hibmc_encoder_mode_set(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adj_mode)
@@ -105,23 +79,10 @@ static const struct drm_encoder_funcs hibmc_encoder_funcs
= {
int hibmc_vdac_init(struct hibmc_drm_private *priv)
{
struct drm_device *dev = priv->dev;
- struct drm_encoder *encoder;
- struct drm_connector *connector;
+ struct drm_encoder *encoder = >encoder;
+ struct drm_connector *connector = >connector;
int ret;
- connector = hibmc_connector_init(priv);
- if (IS_ERR(connector)) {
- DRM_ERROR("failed to create connector: %ld\n",
- PTR_ERR(connector));
- return PTR_ERR(connector);
- }
-
- encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL);
- if (!encoder) {
- DRM_ERROR("failed to alloc memory when init encoder\n");
- return -ENOMEM;
- }
-
encoder->possible_crtcs = 0x1;
ret = drm_encoder_init(dev, encoder, _encoder_funcs,
DRM_MODE_ENCODER_DAC, NULL);
@@ -131,6 +92,15 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
}
drm_encoder_helper_add(encoder, _encoder_helper_funcs);
+
+ ret = drm_connector_init(dev, connector, _connector_funcs,
+DRM_MODE_CONNECTOR_VGA);
+ if (ret) {
+ DRM_ERROR("failed to init connector: %d\n", ret);
+ return ret;
+ }
+ drm_connector_helper_add(connector, _connector_helper_funcs);
+
drm_connector_attach_encoder(connector, encoder);
return 0;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Tue, Jun 30, 2020 at 08:08:46PM +, Xiong, Jianxin wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, June 30, 2020 12:17 PM > > To: Xiong, Jianxin > > Cc: linux-r...@vger.kernel.org; Doug Ledford ; Sumit > > Semwal ; Leon Romanovsky > > ; Vetter, Daniel ; Christian > > Koenig ; dri- > > de...@lists.freedesktop.org > > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support > > > > > > > > > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote: > > > > > > > Heterogeneous Memory Management (HMM) utilizes > > > > > > > mmu_interval_notifier and ZONE_DEVICE to support shared > > > > > > > virtual address space and page migration between system memory > > > > > > > and device memory. HMM doesn't support pinning device memory > > > > > > > because pages located on device must be able to migrate to > > > > > > > system memory when accessed by CPU. Peer-to-peer access is > > > > > > > possible if the peer can handle page fault. For RDMA, that means > > > > > > > the NIC must support on-demand paging. > > > > > > > > > > > > peer-peer access is currently not possible with hmm_range_fault(). > > > > > > > > > > Currently hmm_range_fault() always sets the cpu access flag and > > > > > device private pages are migrated to the system RAM in the fault > > > > > handler. > > > > > However, it's possible to have a modified code flow to keep the > > > > > device private page info for use with peer to peer access. > > > > > > > > Sort of, but only within the same device, RDMA or anything else generic > > > > can't reach inside a DEVICE_PRIVATE and extract anything > > useful. > > > > > > But pfn is supposed to be all that is needed. > > > > Needed for what? The PFN of the DEVICE_PRIVATE pages is useless for > > anything. > > Hmm. I thought the pfn corresponds to the address in the BAR range. I could be > wrong here. No, DEVICE_PRIVATE is a dummy pfn to empty address space. Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: repair runtime power management
On 7/2/20 12:07 PM, Philippe CORNU wrote:
Hi,
[...]
Thank for your patch. Pm_runtime_put_sync is also done into function
ltdc_crtc_mode_fixup.
To avoid several call of Pm_runtime_put_sync, it could be better to check
pm_runtime activity:
+ int ret;
DRM_DEBUG_DRIVER("\n");
+ if (!pm_runtime_active(ddev->dev)) {
+ ret = pm_runtime_get_sync(ddev->dev);
+ if (ret) {
+ DRM_ERROR("Failed to enable crtc, cannot get sync\n");
+ return;
+ }
+ }
+
>>>
>>> Where should this go ? And wouldn't that only hide nastier PM imbalance
>>> issues ?
>> Hi Marek,
>> I tested the patch & it generate an error when I try wake up / sleep
>> the board STM32MP1 DK2 with weston application.
>> It need an additional patch
>> drm-stm-ltdc-remove-call-of-pm-runtime-functions.
>>
>> Thanks for the patch.
>>
>> Tested-by: Yannick Fertre
>>
>
> Hi Marek,
> before merging the 2 patches, I would like to be sure that Yannick's
> patch does not "break" your use case (Qt I think)?
> May I ask you please to give it a try?
> Note: If you think there is no need to do extra checks, simply tell me
> of course
It's fine, thanks !
--
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Thu, Jul 02, 2020 at 03:10:00PM +0200, Daniel Vetter wrote: > On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote: > > On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote: > > > > >> All you need is the ability to stop wait for ongoing accesses to end > > > > >> and > > > > >> make sure that new ones grab a new mapping. > > > > > Swap and flush isn't a general HW ability either.. > > > > > > > > > > I'm unclear how this could be useful, it is guarenteed to corrupt > > > > > in-progress writes? > > > > > > > > > > Did you mean pause, swap and resume? That's ODP. > > > > > > > > Yes, something like this. And good to know, never heard of ODP. > > > > > > Hm I thought ODP was full hw page faults at an individual page > > > level, > > > > Yes > > > > > and this stop is for the entire nic. Under the hood both apply > > > back-pressure on the network if a transmission can't be received, > > > but > > > > NIC's don't do stop and resume, blocking the Rx pipe is very > > problematic and performance destroying. > > > > The strategy for something like ODP is more complex, and so far no NIC > > has deployed it at any granularity larger than per-page. > > > > > So since Jason really doesn't like dma_fence much I think for rdma > > > synchronous it is. And it shouldn't really matter, since waiting for a > > > small transaction to complete at rdma wire speed isn't really that > > > long an operation. > > > > Even if DMA fence were to somehow be involved, how would it look? > > Well above you're saying it would be performance destroying, but let's > pretend that's not a problem :-) Also, I have no clue about rdma, so this > is really just the flow we have on the gpu side. I see, no, this is not workable, the command flow in RDMA is not at all like GPU - what you are a proposing is a global 'stop the whole chip' Tx and Rx flows for an undetermined time. Not feasible What we can do is use ODP techniques and pause only the MR attached to the DMA buf with the process you outline below. This is not so hard to implement. > 3. rdma driver worker gets busy to restart rx: > 1. lock all dma-buf that are currently in use (dma_resv_lock). > thanks to ww_mutex deadlock avoidance this is possible Why all? Why not just lock the one that was invalidated to restore the mappings? That is some artifact of the GPU approach? And why is this done with work queues and locking instead of a callback saying the buffer is valid again? Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/hisilicon: Use drmm_kzalloc() instead of devm_kzalloc()
using the new API drmm_kzalloc() instead of devm_kzalloc()
v3:
still fixed include statements sorted alphabetically.
v2:
keep the DRM include statements sorted alphabetically.
Signed-off-by: Tian Tao
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index a6fd0c2..249c298 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -267,7 +268,7 @@ static int hibmc_load(struct drm_device *dev)
struct hibmc_drm_private *priv;
int ret;
- priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
+ priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv) {
DRM_ERROR("no memory to allocate for hibmc_drm_private\n");
return -ENOMEM;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/hisilicon: Fixed the warning: Assignment of 0/1 to bool variable
fixed the following warning:
hibmc_drm_drv.c:296:1-18:WARNING: Assignment of 0/1 to bool variable.
hibmc_drm_drv.c:301:2-19: WARNING: Assignment of 0/1 to bool variable.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index 249c298..2fc0c97 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -294,12 +294,12 @@ static int hibmc_load(struct drm_device *dev)
goto err;
}
- priv->msi_enabled = 0;
+ priv->msi_enabled = false;
ret = pci_enable_msi(dev->pdev);
if (ret) {
DRM_WARN("enabling MSI failed: %d\n", ret);
} else {
- priv->msi_enabled = 1;
+ priv->msi_enabled = true;
ret = drm_irq_install(dev, dev->pdev->irq);
if (ret)
DRM_WARN("install irq failed: %d\n", ret);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 28/37] memory: tegra: Register as interconnect provider
Hi Dmitry,
On 7/2/20 02:36, Dmitry Osipenko wrote:
> 01.07.2020 20:12, Georgi Djakov пишет:
>> Hi Dmitry,
>>
>> Thank you for updating the patches!
>
> Hello, Georgi!
>
> Thank you for the review!
>
>> On 6/9/20 16:13, Dmitry Osipenko wrote:
>>> Now memory controller is a memory interconnection provider. This allows us
>>> to use interconnect API in order to change memory configuration.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/memory/tegra/Kconfig | 1 +
>>> drivers/memory/tegra/mc.c| 114 +++
>>> drivers/memory/tegra/mc.h| 8 +++
>>> include/soc/tegra/mc.h | 3 +
>>> 4 files changed, 126 insertions(+)
>>>
>>> diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
>>> index 5bf75b316a2f..7055fdef2c32 100644
>>> --- a/drivers/memory/tegra/Kconfig
>>> +++ b/drivers/memory/tegra/Kconfig
>>> @@ -3,6 +3,7 @@ config TEGRA_MC
>>> bool "NVIDIA Tegra Memory Controller support"
>>> default y
>>> depends on ARCH_TEGRA
>>> + select INTERCONNECT
>>> help
>>> This driver supports the Memory Controller (MC) hardware found on
>>> NVIDIA Tegra SoCs.
>>> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
>>> index 772aa021b5f6..7ef7ac9e103e 100644
>>> --- a/drivers/memory/tegra/mc.c
>>> +++ b/drivers/memory/tegra/mc.c
>>> @@ -594,6 +594,118 @@ static __maybe_unused irqreturn_t tegra20_mc_irq(int
>>> irq, void *data)
>>> return IRQ_HANDLED;
>>> }
>>>
>>> +static int tegra_mc_icc_set(struct icc_node *src, struct icc_node *dst)
>>> +{
>>> + return 0;
>>> +}
>>> +
>>> +static int tegra_mc_icc_aggregate(struct icc_node *node,
>>> + u32 tag, u32 avg_bw, u32 peak_bw,
>>> + u32 *agg_avg, u32 *agg_peak)
>>> +{
>>> + *agg_avg = min((u64)avg_bw + (*agg_avg), (u64)U32_MAX);
>>> + *agg_peak = max(*agg_peak, peak_bw);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +/*
>>> + * Memory Controller (MC) has few Memory Clients that are issuing memory
>>> + * bandwidth allocation requests to the MC interconnect provider. The MC
>>> + * provider aggregates the requests and then sends the aggregated request
>>> + * up to the External Memory Controller (EMC) interconnect provider which
>>> + * re-configures hardware interface to External Memory (EMEM) in accordance
>>> + * to the required bandwidth. Each MC interconnect node represents an
>>> + * individual Memory Client.
>>> + *
>>> + * Memory interconnect topology:
>>> + *
>>> + * ++
>>> + * ++||
>>> + * | TEXSRD +--->+|
>>> + * ++||
>>> + * ||+-++--+
>>> + *...| MC +--->+ EMC +--->+ EMEM |
>>> + * ||+-++--+
>>> + * ++||
>>> + * | DISP.. +--->+|
>>> + * ++||
>>> + * ++
>>> + */
>>> +static int tegra_mc_interconnect_setup(struct tegra_mc *mc)
>>> +{
>>> + struct icc_onecell_data *data;
>>> + struct icc_node *node;
>>> + unsigned int num_nodes;
>>> + unsigned int i;
>>> + int err;
>>> +
>>> + /* older device-trees don't have interconnect properties */
>>> + if (!of_find_property(mc->dev->of_node, "#interconnect-cells", NULL))
>>> + return 0;
>>> +
>>> + num_nodes = mc->soc->num_clients;
>>> +
>>> + data = devm_kzalloc(mc->dev, struct_size(data, nodes, num_nodes),
>>> + GFP_KERNEL);
>>> + if (!data)
>>> + return -ENOMEM;
>>> +
>>> + mc->provider.dev = mc->dev;
>>> + mc->provider.set = tegra_mc_icc_set;
>>
>> Hmm, maybe the core should not require a set() implementation and we can
>> just make it optional instead. Then the dummy function would not be needed.
>
> Eventually this dummy function might become populated with a memory
> latency allowness programming. I could add a comment into that function
> in the next version, saying that it's to-be-done for now.
Ah ok! Sounds good, thanks for clarifying!
>>> + mc->provider.data = data;
>>> + mc->provider.xlate = of_icc_xlate_onecell;
>>> + mc->provider.aggregate = tegra_mc_icc_aggregate;
>>> +
>>> + err = icc_provider_add(>provider);
>>> + if (err)
>>> + goto err_msg;
>>
>> Nit: I am planning to re-organize some of the existing drivers to call
>> icc_provider_add() after the topology is populated. Could you please move
>> this after the nodes are created and linked.
>
> Are you planning to remove the provider's list-head initialization from
> the icc_provider_add() [1] and move it to the individual provider
> drivers, correct?
Yes, that would be the first step, but i need to post some patches first,
so let's keep it as-is for now. Sorry for the confusion.
Thanks,
Georgi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm/dpu: fix wrong return value in dpu_encoder_init()
> A positive value ENOMEM is returned here. I thinr this is a typo error. > It is necessary to return a negative error value. I imagine that a small adjustment could be nice for this change description. How do you think about to follow progress for the integration of a previous patch like “[RESEND] drm/msm/dpu: fix error return code in dpu_encoder_init”? https://lore.kernel.org/dri-devel/20200618062803.152097-1-chentao...@huawei.com/ https://lore.kernel.org/patchwork/patch/1257957/ https://lkml.org/lkml/2020/6/18/46 Regards, Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH net-next] ksz884x: mark pcidev_suspend() as __maybe_unused
On Thu, Jul 2, 2020 at 2:38 PM Wei Yongjun wrote:
>
> In certain configurations without power management support, gcc report
> the following warning:
>
> drivers/net/ethernet/micrel/ksz884x.c:7182:12: warning:
> 'pcidev_suspend' defined but not used [-Wunused-function]
> 7182 | static int pcidev_suspend(struct device *dev_d)
> |^~
>
> Mark pcidev_suspend() as __maybe_unused to make it clear.
>
> Fixes: 64120615d140 ("ksz884x: use generic power management")
> Reported-by: Hulk Robot
> Signed-off-by: Wei Yongjun
> ---
> drivers/net/ethernet/micrel/ksz884x.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/micrel/ksz884x.c
> b/drivers/net/ethernet/micrel/ksz884x.c
> index 24901342ecc0..2ce7304d3753 100644
> --- a/drivers/net/ethernet/micrel/ksz884x.c
> +++ b/drivers/net/ethernet/micrel/ksz884x.c
> @@ -7179,7 +7179,7 @@ static int __maybe_unused pcidev_resume(struct device
> *dev_d)
> return 0;
> }
>
> -static int pcidev_suspend(struct device *dev_d)
> +static int __maybe_unused pcidev_suspend(struct device *dev_d)
> {
> int i;
> struct platform_info *info = dev_get_drvdata(dev_d);
>
This is a necessary fix. Thanks !
--Vaibhav Gupta
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
