Re: [PULL] drm-intel-next
On Mon, 04 Feb 2019, Daniel Vetter wrote: > On Mon, Feb 04, 2019 at 10:47:36AM +0200, Joonas Lahtinen wrote: >> Quoting Dave Airlie (2019-02-04 07:02:07) >> > On Sat, 2 Feb 2019 at 18:29, Rodrigo Vivi wrote: >> > > >> > > Hi Dave and Daniel, >> > > >> > > Here goes another pull request for 5.1. >> > >> > dim complained: >> > >> > Chris committed this without an S-O-B, now because it's all Intel this >> > probably doesn't matter, so I'll pull it, put please try and let it >> > not happen again. >> >> It's a tooling issue. It even has the Link: tag, so it is applied with >> dim, which automatically should apply the S-o-b of committer. The issue >> should already have a fix. >> >> And we also concluded that as it's all Intel, it should be legally OK, >> and not worthy force pushing the history (as it was noticed rather >> late). >> >> But looks like the communication back to you fell short. Apologies for >> that. > > Hm yeah I thought Dave was on cc: but he wasn't. Some I was on cc: for > that thread though (no idea why that tbh). Also just noticed that we only > had the private subthread that Jani started, but never replied in public > (or to sfr or anyone). Sorry about that, the intention was to sort it out in private first, the follow-up failed. BR, Jani. > -Daniel > >> >> Regards, Joonas >> >> > Dave. >> > >> > commit 8e525cb4a622148fbe30134ee3a1a34ad839a43a >> > Author: Tvrtko Ursulin >> > Commit: Chris Wilson >> > >> > drm/i915/execlists: Move RPCS setup to context pin >> > >> > Configuring RPCS in context image just before pin is sufficient and >> > will >> > come extra handy in one of the following patches. >> > >> > v2: >> > * Split image setup a bit differently. (Chris Wilson) >> > >> > v3: >> > * Update context image after reset as well - otherwise the application >> >of pinned default state clears the RPCS. >> > >> > v4: >> > * Use local variable throughout the function. (Chris Wilson) >> > >> > Signed-off-by: Tvrtko Ursulin >> > Suggested-by: Chris Wilson >> > Cc: Chris Wilson >> > Reviewed-by: Chris Wilson >> > Reviewed-by: Joonas Lahtinen >> > Link: >> > https://patchwork.freedesktop.org/patch/msgid/20190125023005.1007-1-ch...@chris-wilson.co.uk >> > >> > > >> > > Maybe I will still send another next week. >> > > >> > > This pull also include a GVT one with: >> > > " >> > > Here is gvt-next stuff. This includes Coffeelake support for GVT, >> > > making kvmgt as self load module to have better dependence with >> > > vfio/mdev, with some const treatment and kernel type change. >> > > " >> > > >> > > And also it includes a drm change for constify drm_color_lut_check. >> > > >> > > Rest of details are on the tags below. >> > > >> > > drm-intel-next-2019-02-02: >> > > - Make background color and LUT more robust (Matt) >> > > - Icelake display fixes (Ville, Imre) >> > > - Workarounds fixes and reorg (Tvrtko, Talha) >> > > - Enable fastboot by default on VLV and CHV (Hans) >> > > - Add another PCI ID for Coffee Lake (Rodrigo) >> > > >> > > drm-intel-next-2019-01-29: >> > > - MOCS table rework for simplification and to add ICL (Lucas, Tomasz) >> > > - Move RPCS setup to context pin (Tvrtko) >> > > - Breadcrumb simplification and GPU Reset improvements (Chris) >> > > - Many fixes for TV modeset (Ville) >> > > - Clean up on atomic plane checks (Ville) >> > > - NV12 pich check fix (Raviraj) >> > > - Disable -Wuninitialized (Nathan) >> > > - Sanitize DPLL state for broken BIOSes on SNB (Ville) >> > > - Rework on vma locking and counting and introduce a concept of >> > > per-timeline >> > > HWSP (Chris) >> > > - Enable fastboot by default on Skylake and newer platforms (Hans) >> > > - Fix slk srckey mask bits (Ville) >> > > - Selftests fixes (Chris) >> > > - Execlists and preemption improvements and fixes (Chris) >> > > - drm consitify drm_color_lut_check (Ville) >> > > - Ice Lake clock fixes (Lucas) >> > > >> > > Thanks, >> > > Rodrigo. >> > > >> > > The following changes since commit >> > > 85baa5dbf79163026dcb78f742294c522e176432: >> > > >> > > drm/i915: Update DRIVER_DATE to 20190124 (2019-01-24 15:00:59 -0800) >> > > >> > > are available in the Git repository at: >> > > >> > > git://anongit.freedesktop.org/drm/drm-intel >> > > tags/drm-intel-next-2019-02-02 >> > > >> > > for you to fetch changes up to 46c0cd8c562bc3e4a99cbaa4ba0904b6871b7b4b: >> > > >> > > drm/i915: Update DRIVER_DATE to 20190202 (2019-02-02 00:14:28 -0800) >> > > >> > > >> > > - Make background color and LUT more robust (Matt) >> > > - Icelake display fixes (Ville, Imre) >> > > - Workarounds fixes and reorg (Tvrtko, Talha) >> > > - Enable fastboot by default on VLV and CHV (Hans) >> > > - Add another PCI ID for Coffee Lake (Rodrigo) >> > > >> > > >> > > Chris Wilson (27): >> > > drm/i915: Mea
Re: [PATCH 1/2] drm/omap: panel-tpo-td028ttec1: add backlight support
Hi,
On Mon, 4 Feb 2019 10:13:46 +0200
Tomi Valkeinen wrote:
> Hi,
>
> On 19/01/2019 20:21, Andreas Kemnade wrote:
> > This panel has a backlight, so fetch it from devicetree using the
> > as documented in panel-common.txt. It is implemented the same way as in
>
> Extra words above, or maybe some are missing...
>
oops,
This panel has a backlight, so fetch it from devicetree using the properties
as documented in panel-common.txt. It is implemented the same way as in
panel-dpi.c
> > panel-dpi.c
> > This ensures the backlight is also disabled when the display is
> > turned off like when doing xset dpms force off.
> >
> > Signed-off-by: Andreas Kemnade
> > ---
> > .../gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c| 18
> > +++---
> > 1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
> > b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
> > index 7ddc8c574a61..f326ba9dcf62 100644
> > --- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
> > +++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
> > @@ -35,6 +35,8 @@ struct panel_drv_data {
> >
> > struct videomode vm;
> >
> > + struct backlight_device *backlight;
> > +
> > struct spi_device *spi_dev;
> > };
> >
> > @@ -268,6 +270,8 @@ static int td028ttec1_panel_enable(struct
> > omap_dss_device *dssdev)
> >
> > r |= jbt_ret_write_0(ddata, JBT_REG_DISPLAY_ON);
> >
> > + backlight_enable(ddata->backlight);
> > +
> > dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
> >
> > transfer_err:
> > @@ -283,6 +287,8 @@ static void td028ttec1_panel_disable(struct
> > omap_dss_device *dssdev)
> > if (!omapdss_device_is_enabled(dssdev))
> > return;
> >
> > + backlight_disable(ddata->backlight);
> > +
> > dev_dbg(dssdev->dev, "td028ttec1_panel_disable()\n");
> >
> > jbt_ret_write_0(ddata, JBT_REG_DISPLAY_OFF);
> > @@ -321,6 +327,15 @@ static int td028ttec1_panel_probe(struct spi_device
> > *spi)
> >
> > dev_dbg(&spi->dev, "%s\n", __func__);
> >
> > + ddata = devm_kzalloc(&spi->dev, sizeof(*ddata), GFP_KERNEL);
> > + if (ddata == NULL)
> > + return -ENOMEM;
> > +
> > + ddata->backlight = devm_of_find_backlight(&spi->dev);
> > +
> > + if (IS_ERR(ddata->backlight))
> > + return PTR_ERR(ddata->backlight);
> > +
>
> Is there a reason for moving the ddata alloc here, instead of keeping it
> where it was?
>
Well, I was just unsure if the spi_setup needs to be undone on error, so I
moved things around. But the kzalloc() error check would face the same problem
and other error checks further on, too.
So I can rather keep it as is.
I will send a v2.
Regards,
Andreas
pgpLq6UsdbS9e.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 8:56 AM Thierry Reding wrote: > > I think it is perfectly fine to have a generic-ish fallback as long as > > it is just that, a fallback. If the panel has quirks, then you'd > > better make sure the firmware is stuffing in the right compatibles or > > that you can update the firmware. > > simple-panel would probably work if you stuck in some mostly compatible > string and provided a ddc-i2c-bus property in the device tree node. The > generic-ish fallback case could be implemented by providing a fallback > compatible string (we used to have "simple-panel", which I think would > still be adequate for this I suppose) and adding a dummy descriptor in > the driver, perhaps one with pre-defined delays that could be adjusted > to work for all cases, or they could just be 0. At least that way we'd > be explicitly documenting that we support this as a fallback. > > I'm not sure how you'd want to enforce that people provide the right > compatible strings that way. Currently there's no way to make your panel > work without adding a panel driver, so people are forced to write the > DT bindings and a driver, or add support to an existing one. If we open > this backdoor, I suspect many people will just take the easy route and > rely on the fallback. And then what do we do when we get bug reports > about panels not working, or requiring some quirks. How do we go and > find out what the right compatible strings are for each board, or how to > fix things for something we don't have access to. > > This all sounds like a Pandora's box to me. OK, just give me an option that will work on this platform with a single software image (keep in mind that u-boot aka "firmware" is part of this image) and that is acceptable for upstream and I'll try to implement it. > Thierry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding wrote: > > > > Pinebook used several 768p panels that have slightly different timings > > and recent batch uses 1080p panel. > > > > What panel descriptor should I use as fallback? > > You don't use panel descriptors as fallback. The simple-panel driver > will bind to a panel device and use the corresponding descriptor. If > your device tree contains the correct information, the descriptor is > correct for the panel you have. > > In other words you need to ensure that you have the correct panel in > device tree for the board that you're using. This is exactly the same > thing as for other devices. > > One way to to this is to have separate device trees for each variant > of the board that you want to support. Another variant may be to have > a common device tree and then have some early firmware update the DTB > with the correct panel information. That defeats the purpose of using eDP panels. Panel can identify itself and report what timings it supports. If we use separate DTBs then users will have to figure out what panel is installed in their hardware and use appropriate software image - that's something I'd like to avoid. I can add a descriptor for something like "pinebook eDP panel" if it works for you, but it won't have any display timings in it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard wrote:
>
> Hi,
>
> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb:
> > Validate the clock rate") prevents some panel and bridges from working with
> > sun4i driver.
> >
> > Unfortunately, dotclock frequency for some modes are not achievable on
> > sunxi hardware, and there's a slight deviation in rate returned by
> > clk_round_rate(), so they fail this check.
> >
> > Experiments show that panels and bridges work fine with this slight
> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel
> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just
> > fine.
> >
> > This patch adds a 1% tolerence to the dot clock check when bridge is
> > connected.
> >
> > Signed-off-by: Vasily Khoruzhick
>
> I'm not sure we want to make exceptions for all the hardware
> combination we face, but we should go for something more generic (and
> easier to maintain instead).
>
> IIRC, from the previous discussion, HDMI had a tolerancy requirement
> in the standard. Do you know if there's such a thing for eDP? That
> would solve the issue for all the eDP displays at once.
I don't have access to eDP standard - vesa.org says it's available to
members only.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/xen: Use drm_dev_unregister()
On 2/3/19 5:41 PM, Noralf Trønnes wrote: > drm_dev_unplug() has been stripped down and is going away. Open code its > 2 remaining function calls. > > Also remove the drm_dev_is_unplugged() check since this can't be true > before drm_dev_unregister() is called which happens after the check. > > Cc: Oleksandr Andrushchenko > Signed-off-by: Noralf Trønnes > --- > drivers/gpu/drm/xen/xen_drm_front.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/xen/xen_drm_front.c > b/drivers/gpu/drm/xen/xen_drm_front.c > index 3e78a832d7f9..5c5eb24c6342 100644 > --- a/drivers/gpu/drm/xen/xen_drm_front.c > +++ b/drivers/gpu/drm/xen/xen_drm_front.c > @@ -576,12 +576,9 @@ static void xen_drm_drv_fini(struct xen_drm_front_info > *front_info) > if (!dev) > return; > > - /* Nothing to do if device is already unplugged */ > - if (drm_dev_is_unplugged(dev)) > - return; xen_drm_drv_fini is called when the backend changes its state [1], so I just use the check above to prevent possible race conditions here, e.g. do not allow to run unregister code if it is already in progress So, I think we should keep this and probably just add a comment why it is here > - > drm_kms_helper_poll_fini(dev); > - drm_dev_unplug(dev); > + drm_dev_unregister(dev); > + drm_dev_put(dev); > > front_info->drm_info = NULL; > [1] https://elixir.bootlin.com/linux/v5.0-rc5/ident/displback_disconnect ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls
Hi, * Tomi Valkeinen [190204 09:57]: > On 31/01/2019 05:32, Tony Lindgren wrote: > > Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not > > paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves > > But it is paired with dsi_pll_uninit(). But we need to also call dss_pll_disable(). Now we're only calling dsi_pll_disable() and skipping dss_pll_disable(). > > the DSS clocks enabled when the display is blanked wasting about extra > > 5mW of power while idle. > > Which clocks? I think all the clocks are disabled. But if > disconnect_lanes == false, the regulator is left enabled. Without this patch I'm seeing DSS_CLKCTRL bit 10 OPTFCLKEN_SYS_CLK left enabled after blanking, also known as sys_clk in the dts. > If some clocks are left enabled, then that's a bug, but this didn't seem > to be the case after a brief review of the code. Yeah the code there currently is a bit confusing to follow. With the missing call to dss_pll_disable(), we never call clk_disable_unprepare(pll->clkin). > > Let's fix this by setting a dsi->disconnect_lanes flag and making > > the current dsi_pll_uninit() into dsi_pll_disable(). This way we can > > just call dss_pll_disable() from dsi_display_uninit_dsi() and the > > code becomes a bit easier to follow. > > It's been a long time since I worked on these DSI features, but: > - If the regulator is disabled, the DSI lanes are in undefined state > - If the DSI lanes are in undefined state, the panel often sees that as > errors (or, in theory, might even read it as some real event) in the DSI > lanes > - If the panel driver can handle lanes in undefined state, it can set > disconnect_lanes to true > - ULPS needs the lanes to be in defined state (high/low, I can't recall) Hmm OK. So after this patch we now have the following at dss and dsi levels: - dsi_pll_disable() calls regulator_disable(dsi->vdds_dsi_reg) if dsi->disconnect_lanes is set - dss_pll_disable() calls regulator_disable(pll->regulator) unconditionally At least I'm not seeing any issues with dss_pll_disable() call regulator_disable(pll->regulator) even without having dsi->disconnect_lanes set. Sebastian do you think this might be an issue on n950 for a blank/unblank cycle? N950 does have vdda_video-supply = <&vdac> configured which should be the pll->regulator I think. My guess is that the dsi lanes are fine with just the dsi->vdds_dsi_reg and do not need the pll->regulator :) This guess is based on the fact that the DSS components should be mostly independent modules on the DSS internal interconnect. > I can't remember the details, but I think there was a reason why the > panel-dsi-cm.c doesn't disconnect the lanes... I also faintly remember > that in Nokia we had some hacky code to change the pinmux to keep the > pins in defined states even if the regulator got disabled. But that was > never upstreamed. OK good to know. That can be done with pinctrl named states now. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote: > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex > TERES-I. > So what's the status here? I'm working on the Teres-I and I find myself recreating the chunks in this patchset almost verbatim (only DT so far), one by one, so there must be something right about them ;-) Whose turn is it? Torsten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/6] drm/drv: Remove drm_dev_unplug()
On 2/3/19 5:42 PM, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index e0941200edc6..87210d4a9e53 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -354,23 +354,6 @@ void drm_dev_exit(int idx)
> }
> EXPORT_SYMBOL(drm_dev_exit);
>
> -/**
> - * drm_dev_unplug - unplug a DRM device
> - * @dev: DRM device
> - *
> - * This unplugs a hotpluggable DRM device, which makes it inaccessible to
> - * userspace operations. Entry-points can use drm_dev_enter() and
> - * drm_dev_exit() to protect device resources in a race free manner. This
> - * essentially unregisters the device like drm_dev_unregister(), but can be
> - * called while there are still open users of @dev.
> - */
> -void drm_dev_unplug(struct drm_device *dev)
> -{
> - drm_dev_unregister(dev);
> - drm_dev_put(dev);
> -}
> -EXPORT_SYMBOL(drm_dev_unplug);
> -
> /*
>* DRM internal mount
>* We want to be able to allocate our own "struct address_space" to control
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index c50696c82a42..b8765a6fc092 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -730,7 +730,6 @@ void drm_dev_put(struct drm_device *dev);
> void drm_put_dev(struct drm_device *dev);
> bool drm_dev_enter(struct drm_device *dev, int *idx);
> void drm_dev_exit(int idx);
> -void drm_dev_unplug(struct drm_device *dev);
>
> /**
>* drm_dev_is_unplugged - is a DRM device unplugged
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/9] Analogix ANX6345 RGB-(e)DP bridge support
On Mon, Feb 4, 2019 at 4:22 AM Torsten Duwe wrote: > > On Thu, Oct 18, 2018 at 03:33:18PM +0800, Icenowy Zheng wrote: > > This patchset brings the support for Analogix ANX6345 RGB-(e)DP bridge, > > which is used by some Allwinner A64 laptops, such as Pinebook and Olimex > > TERES-I. > > > > So what's the status here? I'm working on the Teres-I and I find myself > recreating the chunks in this patchset almost verbatim (only DT so far), > one by one, so there must be something right about them ;-) > > Whose turn is it? I've sent v2 yesterday, however I tested it only on Pinebook. > > Torsten > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm/omap: panel-tpo-td028ttec1: add backlight support
This panel has a backlight, so add a property describing that and add the code to use that. This makes things like xset dpms force off also turn off the backlight, so we do not need to rely on additional userspace programs to do that. Andreas Kemnade (2): drm/omap: panel-tpo-td028ttec1: add backlight support dt-bindings: panel: td028ttec1: add backlight property .../devicetree/bindings/display/panel/tpo,td028ttec1.txt | 2 ++ drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c| 10 ++ 2 files changed, 12 insertions(+) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
>
> Maybe s/unplugged/unregistered/ ?
>
> I looked at drm_device->registered, but using that would mean that
> drm_dev_is_unplugged() would return before drm_device is registered.
> And given that its current purpose is to prevent race against connector
> registration, I stayed away from it.
>
> Noralf.
>
>
> drivers/gpu/drm/drm_drv.c | 27 +++
> include/drm/drm_drv.h | 10 --
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..e0941200edc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>*/
> void drm_dev_unplug(struct drm_device *dev)
> {
> - /*
> - * After synchronizing any critical read section is guaranteed to see
> - * the new value of ->unplugged, and any critical section which might
> - * still have seen the old value of ->unplugged is guaranteed to have
> - * finished.
> - */
> - dev->unplugged = true;
> - synchronize_srcu(&drm_unplug_srcu);
> -
> drm_dev_unregister(dev);
> drm_dev_put(dev);
> }
> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>* drm_dev_register() but does not deallocate the device. The caller must
> call
>* drm_dev_put() to drop their final reference.
>*
> - * A special form of unregistering for hotpluggable devices is
> drm_dev_unplug(),
> - * which can be called while there are still open users of @dev.
> + * This function can be called while there are still open users of @dev as
> long
> + * as the driver protects its device resources using drm_dev_enter() and
> + * drm_dev_exit().
>*
>* This should be called first in the device teardown code to make sure
> - * userspace can't access the device instance any more.
> + * userspace can't access the device instance any more. Drivers that support
> + * device unplug will probably want to call drm_atomic_helper_shutdown()
> first
> + * in order to disable the hardware on regular driver module unload.
>*/
> void drm_dev_unregister(struct drm_device *dev)
> {
> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
> if (drm_core_check_feature(dev, DRIVER_LEGACY))
> drm_lastclose(dev);
>
> + /*
> + * After synchronizing any critical read section is guaranteed to see
> + * the new value of ->unplugged, and any critical section which might
> + * still have seen the old value of ->unplugged is guaranteed to have
> + * finished.
> + */
> + dev->unplugged = true;
> + synchronize_srcu(&drm_unplug_srcu);
> +
> dev->registered = false;
>
> drm_client_dev_unregister(dev);
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index ca46a45a9cce..c50696c82a42 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
>* drm_dev_is_unplugged - is a DRM device unplugged
>* @dev: DRM device
>*
> - * This function can be called to check whether a hotpluggable is unplugged.
> - * Unplugging itself is singalled through drm_dev_unplug(). If a device is
> - * unplugged, these two functions guarantee that any store before calling
> - * drm_dev_unplug() is visible to callers of this function after it completes
> + * This function can be called to check whether @dev is unregistered. This
> can
> + * be used to detect that the underlying parent device is gone.
>*
> - * WARNING: This function fundamentally races against drm_dev_unplug(). It is
> - * recommended that drivers instead use the underlying drm_dev_enter() and
> + * WARNING: This function fundamentally races against drm_dev_unregister().
> It
> + * is recommended that drivers instead use the underlying drm_dev_enter() and
>* drm_dev_exit() function pairs.
>*/
> static inline bool drm_dev_is_unplugged(struct drm_device *dev)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/omap: panel-tpo-td028ttec1: add backlight support
This panel has a backlight, so fetch it from devicetree using the
corresponding property as documented in panel-common.txt. It is
implemented the same way as in panel-dpi.c
This ensures the backlight is also disabled when the display is
turned off like when doing xset dpms force off.
Signed-off-by: Andreas Kemnade
---
Changes in v2:
- do not reorder initialisation
- fix commit message
drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 7ddc8c574a61..1db8740f3c21 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -35,6 +35,8 @@ struct panel_drv_data {
struct videomode vm;
+ struct backlight_device *backlight;
+
struct spi_device *spi_dev;
};
@@ -268,6 +270,8 @@ static int td028ttec1_panel_enable(struct omap_dss_device
*dssdev)
r |= jbt_ret_write_0(ddata, JBT_REG_DISPLAY_ON);
+ backlight_enable(ddata->backlight);
+
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
transfer_err:
@@ -283,6 +287,8 @@ static void td028ttec1_panel_disable(struct omap_dss_device
*dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
+ backlight_disable(ddata->backlight);
+
dev_dbg(dssdev->dev, "td028ttec1_panel_disable()\n");
jbt_ret_write_0(ddata, JBT_REG_DISPLAY_OFF);
@@ -334,6 +340,10 @@ static int td028ttec1_panel_probe(struct spi_device *spi)
if (ddata == NULL)
return -ENOMEM;
+ ddata->backlight = devm_of_find_backlight(&spi->dev);
+ if (IS_ERR(ddata->backlight))
+ return PTR_ERR(ddata->backlight);
+
dev_set_drvdata(&spi->dev, ddata);
ddata->spi_dev = spi;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] fbdev: sm712fb: implement 2D acceleration w/ cleanups.
> Since you care about this driver, considered converting it to a drm > display driver? You can still have all the acceleration and stuff, the > fbdev compat mode in drm is rather flexible. > -Daniel Yes, I know fbdev is now in maintenance-only mode, reimplementing it on top of DRM is on my roadmap, including rewriting a saner version of the modesetting code. The current version is beyond repair. I'll start working on it once I managed to purchase the hardware for testing. But currently my objectively is to have something usable during the transitional period. The major user of the chipset was Yeeloong 8089D laptop - a choice for many non-x86 and MIPS hobbyists for experimentation. Getting the current version of the patch merged would solve the immediate usability issues, and then trying to get some platform drivers merged. And after completing the preliminary upstreaming process, since then, can start working on a DRM version of the driver, and possibly eventually remove the fbdev version of sm712fb entirely. The 2D acceleration implementation is strictly no more than 200 lines, the vast majority of the code insertions are comments and documentation changes ranting about the known issues of the driver/hardware, nothing non-trivial is added and I think the changeset is manageable and would not be a burden for the fbdev maintainers, and I can grarantee that I will not add any other new features to this driver. Cheers, Tom Li ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/9] phy: Add configuration interface for MIPI D-PHY devices
On 21/01/19 9:15 PM, Maxime Ripard wrote: > Hi, > > Here is a set of patches to allow the phy framework consumers to test and > apply runtime configurations. > > This is needed to support more phy classes that require tuning based on > parameters depending on the current use case of the device, in addition to > the power state management already provided by the current functions. > > A first test bed for that API are the MIPI D-PHY devices. There's a number > of solutions that have been used so far to support these phy, most of the > time being an ad-hoc driver in the consumer. > > That approach has a big shortcoming though, which is that this is quite > difficult to deal with consumers integrated with multiple variants of phy, > of multiple consumers integrated with the same phy. > > The latter case can be found in the Cadence DSI bridge, and the CSI > transceiver and receivers. All of them are integrated with the same phy, or > can be integrated with different phy, depending on the implementation. > > I've looked at all the MIPI DSI drivers I could find, and gathered all the > parameters I could find. The interface should be complete, and most of the > drivers can be converted in the future. The current set converts two of > them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > use them, and the Allwinner MIPI-DSI driver. Can the PHY changes go independently of the consumer drivers? or else I'll need ACKs from the GPU MAINTAINER. Thanks Kishon > > Let me know what you think, > Maxime > > Changes from v4: > - Removed regression on the variable calculation > - Fixed the wakeup unit > - Collected Sean Acked-by on the last patch > - Collected Sakari Reviewed-by on the first patch > > Changes from v3 > - Rebased on 5.0-rc1 > - Added the fixes suggested by Sakari > > Changes from v2: > - Rebased on next > - Changed the interface to accomodate for the new submodes > - Changed the timings units from nanoseconds to picoseconds > - Added minimum and maximum boundaries to the documentation > - Moved the clock enabling to phy_power_on in the Cadence DPHY driver > - Exported the phy_configure and phy_validate symbols > - Rework the phy pll divider computation in the cadence dphy driver > > Changes from v1: > - Rebased on top of 4.20-rc1 > - Removed the bus mode and timings parameters from the MIPI D-PHY > parameters, since that shouldn't have any impact on the PHY itself. > - Reworked the Cadence DSI and D-PHY drivers to take this into account. > - Remove the mode parameter from phy_configure > - Added phy_configure and phy_validate stubs > - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation > is not implemented > > Maxime Ripard (9): > phy: dphy: Remove unused header > phy: dphy: Change units of wakeup and init parameters > phy: dphy: Clarify lanes parameter documentation > sun6i: dsi: Convert to generic phy handling > phy: Move Allwinner A31 D-PHY driver to drivers/phy/ > drm/bridge: cdns: Separate DSI and D-PHY configuration > dt-bindings: phy: Move the Cadence D-PHY bindings > phy: Add Cadence D-PHY support > drm/bridge: cdns: Convert to phy framework > > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +- > Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +- > drivers/gpu/drm/bridge/Kconfig| 1 +- > drivers/gpu/drm/bridge/cdns-dsi.c | 538 +-- > drivers/gpu/drm/sun4i/Kconfig | 3 +- > drivers/gpu/drm/sun4i/Makefile| 5 +- > drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 292 + > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 31 +- > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h| 17 +- > drivers/phy/allwinner/Kconfig | 12 +- > drivers/phy/allwinner/Makefile| 1 +- > drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 - > drivers/phy/cadence/Kconfig | 13 +- > drivers/phy/cadence/Makefile | 1 +- > drivers/phy/cadence/cdns-dphy.c | 389 +- > drivers/phy/phy-core-mipi-dphy.c | 8 +- > include/linux/phy/phy-mipi-dphy.h | 13 +- > 17 files changed, 894 insertions(+), 789 deletions(-) > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt > delete mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c > create mode 100644 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c > create mode 100644 drivers/phy/cadence/cdns-dphy.c > > base-commit: bfeffd155283772bbe78c6a05dec7c0128ee500c > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.free
[PATCH v2 2/2] dt-bindings: panel: td028ttec1: add backlight property
This adds an additional backlight property as described
in panel-common.txt
Signed-off-by: Andreas Kemnade
---
Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
index ed34253d9fb1..898e06ecf4ef 100644
--- a/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
@@ -6,6 +6,7 @@ Required properties:
Optional properties:
- label: a symbolic name for the panel
+- backlight: phandle of the backlight device
Required nodes:
- Video port for DPI input
@@ -21,6 +22,7 @@ lcd-panel: td028ttec1@0 {
spi-cpha;
label = "lcd";
+ backlight = <&backlight>;
port {
lcd_in: endpoint {
remote-endpoint = <&dpi_out>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 12:23 PM Rob Herring wrote: > > simple-panel would probably work if you stuck in some mostly compatible > > string and provided a ddc-i2c-bus property in the device tree node. The > > generic-ish fallback case could be implemented by providing a fallback > > compatible string (we used to have "simple-panel", which I think would > > still be adequate for this I suppose) and adding a dummy descriptor in > > the driver, perhaps one with pre-defined delays that could be adjusted > > to work for all cases, or they could just be 0. At least that way we'd > > be explicitly documenting that we support this as a fallback. > > I'd like something more specific than 'simple-panel' that at least > implies it has EDID and whatever else we think it should imply. > > Looking into this a bit more, why don't we just do a connector here? > eDP has a standard connector (with power). It's just like other > connectors, but with power and no hotplug. If someone does their own > interface, then they should do their own connector or panel binding. Where do we put backlight in this case? > > I'm not sure how you'd want to enforce that people provide the right > > compatible strings that way. Currently there's no way to make your panel > > work without adding a panel driver, so people are forced to write the > > DT bindings and a driver, or add support to an existing one. If we open > > this backdoor, I suspect many people will just take the easy route and > > rely on the fallback. And then what do we do when we get bug reports > > about panels not working, or requiring some quirks. How do we go and > > find out what the right compatible strings are for each board, or how to > > fix things for something we don't have access to. > > We'll simply reject anything that should be implied by compatible. And > now we can enforce with schema that DTs aren't populated with > fallbacks alone. Of course, we can't make anyone pass all schema > checks before shipping a dtb. > > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
于 2019年2月5日 GMT+08:00 上午12:26:43, Vasily Khoruzhick 写到:
>On Mon, Feb 4, 2019 at 6:20 AM Maxime Ripard
> wrote:
>>
>> Hi,
>>
>> On Sun, Feb 03, 2019 at 10:54:55AM -0800, Vasily Khoruzhick wrote:
>> > Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i:
>rgb:
>> > Validate the clock rate") prevents some panel and bridges from
>working with
>> > sun4i driver.
>> >
>> > Unfortunately, dotclock frequency for some modes are not achievable
>on
>> > sunxi hardware, and there's a slight deviation in rate returned by
>> > clk_round_rate(), so they fail this check.
>> >
>> > Experiments show that panels and bridges work fine with this slight
>> > deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP
>panel
>> > requests 73 MHz, gets 72.296MHz instead (0.96% difference) and
>works just
>> > fine.
>> >
>> > This patch adds a 1% tolerence to the dot clock check when bridge
>is
>> > connected.
>> >
>> > Signed-off-by: Vasily Khoruzhick
>>
>> I'm not sure we want to make exceptions for all the hardware
>> combination we face, but we should go for something more generic (and
>> easier to maintain instead).
>>
>> IIRC, from the previous discussion, HDMI had a tolerancy requirement
>> in the standard. Do you know if there's such a thing for eDP? That
>> would solve the issue for all the eDP displays at once.
>
>I don't have access to eDP standard - vesa.org says it's available to
>members only.
Try out to grab an old version?
I remember 1.0 is open.
>
>> Maxime
>>
>> --
>> Maxime Ripard, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
>
>___
>linux-arm-kernel mailing list
>linux-arm-ker...@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
使用 K-9 Mail 发送自我的Android设备。
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote: > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > >> in the standard. Do you know if there's such a thing for eDP? That > >> would solve the issue for all the eDP displays at once. > > > >I don't have access to eDP standard - vesa.org says it's available to > >members only. > > Try out to grab an old version? > > I remember 1.0 is open. I can't find anything regarding dot clock tolerance in DisplayPort specification. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 4, 2019 at 8:39 AM Rob Herring wrote: > > On Mon, Feb 4, 2019 at 10:11 AM Vasily Khoruzhick wrote: > > > > On Mon, Feb 4, 2019 at 12:24 AM Thierry Reding > > wrote: > > > > > > > > Pinebook used several 768p panels that have slightly different timings > > > > and recent batch uses 1080p panel. > > > > > > > > What panel descriptor should I use as fallback? > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > will bind to a panel device and use the corresponding descriptor. If > > > your device tree contains the correct information, the descriptor is > > > correct for the panel you have. > > > > > > In other words you need to ensure that you have the correct panel in > > > device tree for the board that you're using. This is exactly the same > > > thing as for other devices. > > > > > > One way to to this is to have separate device trees for each variant > > > of the board that you want to support. Another variant may be to have > > > a common device tree and then have some early firmware update the DTB > > > with the correct panel information. > > > > That defeats the purpose of using eDP panels. Panel can identify > > itself and report what timings it supports. > > If you are confident that this works for all panels, then the firmware > can identify the right panel and update the DTB with the correct > information. If this doesn't work in the firmware, then it is not > going to work in the kernel either and you are SOL without specific > panel information in the DT. "firmware" is u-boot and on this platform it sits on the same physical media as OS (it's either microsd or eMMC). I guess u-boot can fill in timings for kernel, but I don't see much point in it. If u-boot can't read EDID then same is true for kernel. > > If we use separate DTBs then users will have to figure out what panel > > is installed in their hardware and use appropriate software image - > > that's something I'd like to avoid. > > I think Thierry meant either way this is a firmware problem. If you > have a SKU per device and panel type, then the firmware just picks a > dtb among a set. Unfortunately it's one SKU per multiple panels. > Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm: Fix drm_release() and device unplug
On 2/3/19 5:41 PM, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspace already holds a ref on drm_device through the drm_minor,
> it's not necessary to add extra ref counting based on no open file
> handles. Instead just drm_dev_put() unconditionally in drm_dev_unplug().
>
> We now has this:
s/has/have ?
> - Userpace holds a ref on drm_device as long as there's open fd(s)
> - The driver holds a ref on drm_device as long as it's bound to the
>struct device
>
> When both sides are done with drm_device, it is released.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/drm_drv.c | 6 +-
> drivers/gpu/drm/drm_file.c | 6 ++
> 2 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..05bbc2b622fc 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -376,11 +376,7 @@ void drm_dev_unplug(struct drm_device *dev)
> synchronize_srcu(&drm_unplug_srcu);
>
> drm_dev_unregister(dev);
> -
> - mutex_lock(&drm_global_mutex);
> - if (dev->open_count == 0)
> - drm_dev_put(dev);
> - mutex_unlock(&drm_global_mutex);
> + drm_dev_put(dev);
> }
> EXPORT_SYMBOL(drm_dev_unplug);
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 46f48f245eb5..3f20f598cd7c 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -479,11 +479,9 @@ int drm_release(struct inode *inode, struct file *filp)
>
> drm_file_free(file_priv);
>
> - if (!--dev->open_count) {
> + if (!--dev->open_count)
> drm_lastclose(dev);
> - if (drm_dev_is_unplugged(dev))
> - drm_put_dev(dev);
> - }
> +
> mutex_unlock(&drm_global_mutex);
>
> drm_minor_release(minor);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: do not return invalid pointers as a *dentry
On Mon, Feb 04, 2019 at 10:13:25AM -0800, Rodrigo Vivi wrote: > On Thu, Jan 31, 2019 at 07:17:02PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote: > > > On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote: > > > > When calling debugfs functions, they can now return error values if > > > > something went wrong. If that happens, return a NULL as a *dentry to > > > > the relay core instead of passing it an illegal pointer. > > > > > > > > The relay core should be able to handle an illegal pointer, but add this > > > > check to be safe. > > > > > > > > Cc: Jani Nikula > > > > Cc: Joonas Lahtinen > > > > Cc: Rodrigo Vivi > > > > Cc: David Airlie > > > > Cc: Daniel Vetter > > > > Cc: intel-...@lists.freedesktop.org > > > > Cc: dri-devel@lists.freedesktop.org > > > > Signed-off-by: Greg Kroah-Hartman > > > > --- > > > > drivers/gpu/drm/i915/intel_guc_log.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c > > > > b/drivers/gpu/drm/i915/intel_guc_log.c > > > > index d3ebdbc0182e..8bf03497dcd8 100644 > > > > --- a/drivers/gpu/drm/i915/intel_guc_log.c > > > > +++ b/drivers/gpu/drm/i915/intel_guc_log.c > > > > @@ -140,6 +140,9 @@ static struct dentry > > > > *create_buf_file_callback(const char *filename, > > > > > > > > buf_file = debugfs_create_file(filename, mode, > > > >parent, buf, > > > > &relay_file_operations); > > > > + if (IS_ERR(buf_file)) > > > > + return NULL; > > > > > > I still see a return NULL inside debugfs_create_file on master, > > > but probably you are ahead with some change that I didn't see yet right? > > > > Yes, this patch is in linux-next now and should go to Linus for > > 5.0-final: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=driver-core-linus&id=ff9fb72bc07705c00795ca48631f7fffe24d2c6b > > > > > I'm just wondering if it wouldn't be better for now to go with > > > > > > if (IS_ERR_OR_NULL(buf_file)) > > > > Not really, because the next line is: > > > > > > return buf_file; > > > > So it's the same thing :) > > > > > apparently we also need it on i915_debugfs.c i915_debugfs_register() > > > > I have a bunch of patches I'm working on to go through and fix up all of > > this (you shouldn't be checking the return value at all, unless you > > really want to use it as a "real" dentry and not just something that > > debugfs uses internally. > > > > But for now, you should be fine, that call will only fail if you are out > > of memory, or did something really wrong. > > Reviewed-by: Rodrigo Vivi > > do you wanna push this with your own stuff or do you want me to pick > up on drm-intel-next? Which ever is easiest for you works for me, just let me know. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/9] phy: Add configuration interface for MIPI D-PHY devices
On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote: > > > On 21/01/19 9:15 PM, Maxime Ripard wrote: > > Hi, > > > > Here is a set of patches to allow the phy framework consumers to test and > > apply runtime configurations. > > > > This is needed to support more phy classes that require tuning based on > > parameters depending on the current use case of the device, in addition to > > the power state management already provided by the current functions. > > > > A first test bed for that API are the MIPI D-PHY devices. There's a number > > of solutions that have been used so far to support these phy, most of the > > time being an ad-hoc driver in the consumer. > > > > That approach has a big shortcoming though, which is that this is quite > > difficult to deal with consumers integrated with multiple variants of phy, > > of multiple consumers integrated with the same phy. > > > > The latter case can be found in the Cadence DSI bridge, and the CSI > > transceiver and receivers. All of them are integrated with the same phy, or > > can be integrated with different phy, depending on the implementation. > > > > I've looked at all the MIPI DSI drivers I could find, and gathered all the > > parameters I could find. The interface should be complete, and most of the > > drivers can be converted in the future. The current set converts two of > > them: the above mentionned Cadence DSI driver so that the v4l2 drivers can > > use them, and the Allwinner MIPI-DSI driver. > > Can the PHY changes go independently of the consumer drivers? or else I'll > need > ACKs from the GPU MAINTAINER. Maxime is a gpu maintainer, so you're all good :-) -Daniel > > Thanks > Kishon > > > > > Let me know what you think, > > Maxime > > > > Changes from v4: > > - Removed regression on the variable calculation > > - Fixed the wakeup unit > > - Collected Sean Acked-by on the last patch > > - Collected Sakari Reviewed-by on the first patch > > > > Changes from v3 > > - Rebased on 5.0-rc1 > > - Added the fixes suggested by Sakari > > > > Changes from v2: > > - Rebased on next > > - Changed the interface to accomodate for the new submodes > > - Changed the timings units from nanoseconds to picoseconds > > - Added minimum and maximum boundaries to the documentation > > - Moved the clock enabling to phy_power_on in the Cadence DPHY driver > > - Exported the phy_configure and phy_validate symbols > > - Rework the phy pll divider computation in the cadence dphy driver > > > > Changes from v1: > > - Rebased on top of 4.20-rc1 > > - Removed the bus mode and timings parameters from the MIPI D-PHY > > parameters, since that shouldn't have any impact on the PHY itself. > > - Reworked the Cadence DSI and D-PHY drivers to take this into account. > > - Remove the mode parameter from phy_configure > > - Added phy_configure and phy_validate stubs > > - Return -EOPNOTSUPP in phy_configure and phy_validate when the operation > > is not implemented > > > > Maxime Ripard (9): > > phy: dphy: Remove unused header > > phy: dphy: Change units of wakeup and init parameters > > phy: dphy: Clarify lanes parameter documentation > > sun6i: dsi: Convert to generic phy handling > > phy: Move Allwinner A31 D-PHY driver to drivers/phy/ > > drm/bridge: cdns: Separate DSI and D-PHY configuration > > dt-bindings: phy: Move the Cadence D-PHY bindings > > phy: Add Cadence D-PHY support > > drm/bridge: cdns: Convert to phy framework > > > > Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt | 21 +- > > Documentation/devicetree/bindings/phy/cdns,dphy.txt | 20 +- > > drivers/gpu/drm/bridge/Kconfig| 1 +- > > drivers/gpu/drm/bridge/cdns-dsi.c | 538 +-- > > drivers/gpu/drm/sun4i/Kconfig | 3 +- > > drivers/gpu/drm/sun4i/Makefile| 5 +- > > drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 292 + > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c| 31 +- > > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h| 17 +- > > drivers/phy/allwinner/Kconfig | 12 +- > > drivers/phy/allwinner/Makefile| 1 +- > > drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 318 - > > drivers/phy/cadence/Kconfig | 13 +- > > drivers/phy/cadence/Makefile | 1 +- > > drivers/phy/cadence/cdns-dphy.c | 389 +- > > drivers/phy/phy-core-mipi-dphy.c | 8 +- > > include/linux/phy/phy-mipi-dphy.h | 13 +- > > 17 files changed, 894 insertions(+), 789 deletions(-) > > create mode 100644 Documentation/devicetree/bindings/phy/cdns,dphy.txt > > delete mode 100644 drivers
Re: [PATCH v10 38/40] drm/i915: Fix KBL HDCP2.2 encrypt status signalling
On Mon, Feb 04, 2019 at 09:02:35PM +0530, C, Ramalingam wrote:
> daniel,
>
> Could you please review this patch too.? Already Updated this as per your
> previous review comment.
Oops, missed this one somehow. Looks much cleaner now imo.
Reviewed-by: Daniel Vetter
>
> --Ram
>
> On 1/31/2019 12:29 PM, Ramalingam C wrote:
> > Implement the required WA sequence for KBL to fix the
> > incorrect positioning of the window of oppurtunity and enc_en
> > signalling.
> >
> > v2:
> >WA is moved into the toggle_signalling [Daniel]
> >
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/intel_hdmi.c | 42
> > +++
> > 1 file changed, 42 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 2c4bf6d0c39f..ae20288f7bbf 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1083,10 +1083,44 @@ int intel_hdmi_hdcp_read_v_prime_part(struct
> > intel_digital_port *intel_dig_port,
> > return ret;
> > }
> > +static int kbl_repositioning_enc_en_signal(struct intel_connector
> > *connector)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> > + struct drm_crtc *crtc = connector->base.state->crtc;
> > + struct intel_crtc *intel_crtc = container_of(crtc,
> > +struct intel_crtc, base);
> > + u32 scanline;
> > + int ret;
> > +
> > + for (;;) {
> > + scanline = I915_READ(PIPEDSL(intel_crtc->pipe));
> > + if (scanline > 100 && scanline < 200)
> > + break;
> > + usleep_range(25, 50);
> > + }
> > +
> > + ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base, false);
> > + if (ret) {
> > + DRM_ERROR("Disable HDCP signalling failed (%d)\n", ret);
> > + return ret;
> > + }
> > + ret = intel_ddi_toggle_hdcp_signalling(&intel_dig_port->base, true);
> > + if (ret) {
> > + DRM_ERROR("Enable HDCP signalling failed (%d)\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static
> > int intel_hdmi_hdcp_toggle_signalling(struct intel_digital_port
> > *intel_dig_port,
> > bool enable)
> > {
> > + struct intel_hdmi *hdmi = &intel_dig_port->hdmi;
> > + struct intel_connector *connector = hdmi->attached_connector;
> > + struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > int ret;
> > if (!enable)
> > @@ -1098,6 +1132,14 @@ int intel_hdmi_hdcp_toggle_signalling(struct
> > intel_digital_port *intel_dig_port,
> > enable ? "Enable" : "Disable", ret);
> > return ret;
> > }
> > +
> > + /*
> > +* WA: To fix incorrect positioning of the window of
> > +* opportunity and enc_en signalling in KABYLAKE.
> > +*/
> > + if (IS_KABYLAKE(dev_priv) && enable)
> > + return kbl_repositioning_enc_en_signal(connector);
> > +
> > return 0;
> > }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > wrote: > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick wrote: > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > define panel > > > > > > > > width/height or any modes/timings in dts. But this panel still > > > > > > > > may have > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > --- > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| 7 > > > > > > > > +++ > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > create mode 100644 > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > really are. > > > > > > > You're going to have to provide a compatible string for your > > > > > > > device that > > > > > > > is more specific than "panel-edp". You claim that you don't need > > > > > > > any > > > > > > > extra information that is panel specific, but you don't know that > > > > > > > now. > > > > > > > We have in the past thought that we didn't need things like > > > > > > > prepare > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific compatible > > > > > > > string > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > read all > > > > > > > the video timings from an EDID EEPROM, you can still provide a > > > > > > > mode in > > > > > > > the panel descriptor to serve as a fallback if for example the > > > > > > > EEPROM > > > > > > > is faulty on some device. > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > timings > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > > > will bind to a panel device and use the corresponding descriptor. If > > > > > your device tree contains the correct information, the descriptor is > > > > > correct for the panel you have. > > > > > > > > > > In other words you need to ensure that you have the correct panel in > > > > > device tree for the board that you're using. This is exactly the same > > > > > thing as for other devices. > > > > > > > > > > One way to to this is to have separate device trees for each variant > > > > > of the board that you want to support. Another variant may be to have > > > > > a common device tree and then have some early firmware update the DTB > > > > > with the correct panel information. > > > > > > > > This would defeat the point of edp, which is to standardize the mess of > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > tables/firmware for every board you ship. Also, we do have DP quirking > > > > infrastructure already (using the OUI), I think if there's something > > > > that > > > > doesn't work then we should quirk it there. > > > > > > The problem is that while the attempt may have been to standardize, it > > > failed. It doesn't take into account any of the details such as timing > > > between things like powering up the display and enabling the backlight > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > requirements because they are highly panel specific. > > > > Hm right, we get these from some firmware tables (and mix them with the > > spec one, since some of the firmware values are nonsense). I don't even > > know whether we can read the timings over dp aux somehow (you can power up > > the panel with some pessimistic values to figure those out, and you only > > need dp aux to work, which is much simpler than the entire panel). > > > > > > What does make sense though imo is if we try not to stuff the edp panel > > > > into panel-simple, because it's anything like a simple dumb panel. > > > > There's > > > > also some integration awkwardness since with this panel you need to do > > > > dp > > > > aux/i2c transactions to get at the information (edid alone isn't good > > > > enough for edp), and I'm not sure how exactly that's supposed to be > > > > instantiated. Maybe a special function to instantiate an edp panel, > > > > which > > > > takes both a DT node and the dp_aux controller would be much better, > > > >
Re: [PATCH] drm/cirrus: add plane setup
On Mon, Feb 04, 2019 at 12:01:31PM +0100, Gerd Hoffmann wrote:
> Commit "f4bd542bca drm/fb-helper: Scale back depth to supported maximum"
> uncovered a bug in the cirrus driver. It must create its own primary
> plane, using the correct format list, depending on the bpp module
> parameter, so it is consistent with mode_config->preferred_depth.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/cirrus/cirrus_mode.c | 67
> +++-
> 1 file changed, 66 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
> b/drivers/gpu/drm/cirrus/cirrus_mode.c
> index a830e70fc0..2e966a22c5 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_mode.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
> @@ -360,10 +360,67 @@ static const struct drm_crtc_helper_funcs
> cirrus_helper_funcs = {
> };
>
> /* CRTC setup */
> +static const uint32_t cirrus_formats_16[] = {
> + DRM_FORMAT_RGB565,
> +};
> +
> +static const uint32_t cirrus_formats_24[] = {
> + DRM_FORMAT_RGB888,
> +};
> +
> +static const uint32_t cirrus_formats_32[] = {
> + DRM_FORMAT_XRGB,
> + DRM_FORMAT_ARGB,
> +};
I'd include the lower-res formats too here, without those you limit
userspace that looks at this stuff to only these formats. Not that this is
really important for cirrus ... So 24bits would include 16, and 32 would
include 24 and 16. With that:
Reviewed-by: Daniel Vetter
> +
> +static struct drm_plane *cirrus_primary_plane(struct drm_device *dev)
> +{
> + const uint32_t *formats;
> + uint32_t nformats;
> + struct drm_plane *primary;
> + int ret;
> +
> + switch (cirrus_bpp) {
> + case 16:
> + formats = cirrus_formats_16;
> + nformats = ARRAY_SIZE(cirrus_formats_16);
> + break;
> + case 24:
> + formats = cirrus_formats_24;
> + nformats = ARRAY_SIZE(cirrus_formats_24);
> + break;
> + case 32:
> + formats = cirrus_formats_32;
> + nformats = ARRAY_SIZE(cirrus_formats_32);
> + break;
> + default:
> + return NULL;
> + }
> +
> + primary = kzalloc(sizeof(*primary), GFP_KERNEL);
> + if (primary == NULL) {
> + DRM_DEBUG_KMS("Failed to allocate primary plane\n");
> + return NULL;
> + }
> +
> + ret = drm_universal_plane_init(dev, primary, 0,
> +&drm_primary_helper_funcs,
> +formats, nformats,
> +NULL,
> +DRM_PLANE_TYPE_PRIMARY, NULL);
> + if (ret) {
> + kfree(primary);
> + primary = NULL;
> + }
> +
> + return primary;
> +}
> +
> static void cirrus_crtc_init(struct drm_device *dev)
> {
> struct cirrus_device *cdev = dev->dev_private;
> struct cirrus_crtc *cirrus_crtc;
> + struct drm_plane *primary;
>
> cirrus_crtc = kzalloc(sizeof(struct cirrus_crtc) +
> (CIRRUSFB_CONN_LIMIT * sizeof(struct
> drm_connector *)),
> @@ -372,7 +429,15 @@ static void cirrus_crtc_init(struct drm_device *dev)
> if (cirrus_crtc == NULL)
> return;
>
> - drm_crtc_init(dev, &cirrus_crtc->base, &cirrus_crtc_funcs);
> + primary = cirrus_primary_plane(dev);
> + if (primary == NULL) {
> + kfree(cirrus_crtc);
> + return;
> + }
> +
> + drm_crtc_init_with_planes(dev, &cirrus_crtc->base,
> + primary, NULL,
> + &cirrus_crtc_funcs, NULL);
>
> drm_mode_crtc_set_gamma_size(&cirrus_crtc->base, CIRRUS_LUT_SIZE);
> cdev->mode_info.crtc = cirrus_crtc;
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109548] Seeing visual corruption in totem after installing amdgpu 18.50 in Ubuntu 18.04.1
https://bugs.freedesktop.org/show_bug.cgi?id=109548 Michel Dänzer changed: What|Removed |Added Product|DRI |Mesa Component|DRM/AMDgpu |Mesa core Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact||mesa-dev@lists.freedesktop. ||org --- Comment #3 from Michel Dänzer --- Most of the time, if disabling allow_rgb10_configs works around an issue like this, it's a bug in the application or a higher level library above Mesa. However, some people are claiming this is a Mesa issue (something about not (correctly) supporting some VA-API functionality, resulting in the application using a pixel format that can't work). It most certainly isn't a kernel driver issue, so reassigning to Mesa for now. Please attach the output of vainfo when the problem occurs. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bochs: fix bochs_gem_prime_mmap
On Mon, Feb 04, 2019 at 07:38:58PM +0100, Gerd Hoffmann wrote:
> ttm_fbdev_mmap() just doesn't work. It appears to work fine, mmap()
> returns success, but any attempt to actually access the mapping causes a
> SIGBUS.
>
> We can just use drm_gem_prime_mmap() instead. Almost. We have to copy
> over the start offset from the ttm_buffer_object vm_node to the
> drm_gem_object vm_node so the offset math in drm_gem_prime_mmap() works
> correctly for us even though we use ttm to manage our objects.
>
> Signed-off-by: Gerd Hoffmann
Would be kinda neat if we could teach ttm to not have it's own vma node
...
Anyway, lgtm.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/bochs/bochs_mm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> b/drivers/gpu/drm/bochs/bochs_mm.c
> index 641a33f134..49463348a0 100644
> --- a/drivers/gpu/drm/bochs/bochs_mm.c
> +++ b/drivers/gpu/drm/bochs/bochs_mm.c
> @@ -442,5 +442,6 @@ int bochs_gem_prime_mmap(struct drm_gem_object *obj,
> {
> struct bochs_bo *bo = gem_to_bochs_bo(obj);
>
> - return ttm_fbdev_mmap(vma, &bo->bo);
> + bo->gem.vma_node.vm_node.start = bo->bo.vma_node.vm_node.start;
> + return drm_gem_prime_mmap(obj, vma);
> }
> --
> 2.9.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] fbdev: sm712fb: implement 2D acceleration w/ cleanups.
On Tue, Feb 05, 2019 at 06:06:50AM +0800, Tom Li wrote: > > Since you care about this driver, considered converting it to a drm > > display driver? You can still have all the acceleration and stuff, the > > fbdev compat mode in drm is rather flexible. > > -Daniel > > Yes, I know fbdev is now in maintenance-only mode, reimplementing it > on top of DRM is on my roadmap, including rewriting a saner version > of the modesetting code. The current version is beyond repair. I'll > start working on it once I managed to purchase the hardware for testing. > > But currently my objectively is to have something usable during the > transitional period. The major user of the chipset was Yeeloong 8089D > laptop - a choice for many non-x86 and MIPS hobbyists for experimentation. > Getting the current version of the patch merged would solve the immediate > usability issues, and then trying to get some platform drivers merged. > And after completing the preliminary upstreaming process, since then, > can start working on a DRM version of the driver, and possibly eventually > remove the fbdev version of sm712fb entirely. > > The 2D acceleration implementation is strictly no more than 200 lines, > the vast majority of the code insertions are comments and documentation > changes ranting about the known issues of the driver/hardware, nothing > non-trivial is added and I think the changeset is manageable and would > not be a burden for the fbdev maintainers, and I can grarantee that I will > not add any other new features to this driver. Awesome, and I think as a gradual plan this makes tons of sense. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: potential NULL dereference
The etnaviv_gem_prime_get_sg_table() is supposed to return error
pointers. Otherwise it can lead to a NULL dereference when it's called
from drm_gem_map_dma_buf().
Fixes: 5f4a4a73f437 ("drm/etnaviv: fix gem_prime_get_sg_table to return new SG
table")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 0566171f8df2..f21529e635e3 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -15,7 +15,7 @@ struct sg_table *etnaviv_gem_prime_get_sg_table(struct
drm_gem_object *obj)
int npages = obj->size >> PAGE_SHIFT;
if (WARN_ON(!etnaviv_obj->pages)) /* should have already pinned! */
- return NULL;
+ return ERR_PTR(-EINVAL);
return drm_prime_pages_to_sg(etnaviv_obj->pages, npages);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
>
>
> Den 04.02.2019 16.41, skrev Daniel Vetter:
> > On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> >> The only thing now that makes drm_dev_unplug() special is that it sets
> >> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> >> can remove drm_dev_unplug().
> >>
> >> Signed-off-by: Noralf Trønnes
> >> ---
>
> [...]
>
> >> drivers/gpu/drm/drm_drv.c | 27 +++
> >> include/drm/drm_drv.h | 10 --
> >> 2 files changed, 19 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >> index 05bbc2b622fc..e0941200edc6 100644
> >> --- a/drivers/gpu/drm/drm_drv.c
> >> +++ b/drivers/gpu/drm/drm_drv.c
> >> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
> >> */
> >> void drm_dev_unplug(struct drm_device *dev)
> >> {
> >> - /*
> >> - * After synchronizing any critical read section is guaranteed to see
> >> - * the new value of ->unplugged, and any critical section which might
> >> - * still have seen the old value of ->unplugged is guaranteed to have
> >> - * finished.
> >> - */
> >> - dev->unplugged = true;
> >> - synchronize_srcu(&drm_unplug_srcu);
> >> -
> >>drm_dev_unregister(dev);
> >>drm_dev_put(dev);
> >> }
> >> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
> >> * drm_dev_register() but does not deallocate the device. The caller must
> >> call
> >> * drm_dev_put() to drop their final reference.
> >> *
> >> - * A special form of unregistering for hotpluggable devices is
> >> drm_dev_unplug(),
> >> - * which can be called while there are still open users of @dev.
> >> + * This function can be called while there are still open users of @dev
> >> as long
> >> + * as the driver protects its device resources using drm_dev_enter() and
> >> + * drm_dev_exit().
> >> *
> >> * This should be called first in the device teardown code to make sure
> >> - * userspace can't access the device instance any more.
> >> + * userspace can't access the device instance any more. Drivers that
> >> support
> >> + * device unplug will probably want to call drm_atomic_helper_shutdown()
> >> first
> >
> > Read once more with a bit more coffee, spotted this:
> >
> > s/first/afterwards/ - shutting down the hw before we've taken it away from
> > userspace is kinda the wrong way round. It should be the inverse of driver
> > load, which is 1) allocate structures 2) prep hw 3) register driver with
> > the world (simplified ofc).
> >
>
> The problem is that drm_dev_unregister() sets the device as unplugged
> and if drm_atomic_helper_shutdown() is called afterwards it's not
> allowed to touch hardware.
>
> I know it's the wrong order, but the only way to do it in the right
> order is to have a separate function that sets unplugged:
>
> drm_dev_unregister();
> drm_atomic_helper_shutdown();
> drm_dev_set_unplugged();
Annoying ... but yeah calling _shutdown() before we stopped userspace is
also not going to work. Because userspace could quickly re-enable
something, and then the refcounts would be all wrong again and leaking
objects.
I get a bit the feeling we're over-optimizing here with trying to devm-ize
drm_dev_register. Just getting drm_device correctly devm-ized is a big
step forward already, and will open up a lot of TODO items across a lot of
drivers. E.g. we could add a drm_dev_kzalloc, for allocating all the drm_*
structs, which gets released together with drm_device. I think that's a
much clearer path forward, I think we all agree that getting the kfree out
of the driver codes is a good thing, and it would allow us to do this
correctly.
Then once we have that and rolled out to a few drivers we can reconsider
the entire unregister/shutdown gordian knot here. Atm I just have no idea
how to do this properly :-/
Thoughts, other ideas?
Cheers, Daniel
> Noralf.
>
> >> + * in order to disable the hardware on regular driver module unload.
> >> */
> >> void drm_dev_unregister(struct drm_device *dev)
> >> {
> >> @@ -845,6 +839,15 @@ void drm_dev_unregister(struct drm_device *dev)
> >>if (drm_core_check_feature(dev, DRIVER_LEGACY))
> >>drm_lastclose(dev);
> >>
> >> + /*
> >> + * After synchronizing any critical read section is guaranteed to see
> >> + * the new value of ->unplugged, and any critical section which might
> >> + * still have seen the old value of ->unplugged is guaranteed to have
> >> + * finished.
> >> + */
> >> + dev->unplugged = true;
> >> + synchronize_srcu(&drm_unplug_srcu);
> >> +
> >>dev->registered = false;
> >>
> >>drm_client_dev_unregister(dev);
> >> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> >> index ca46a45a9cce..c50696c82a42 100644
> >> --- a/include/drm/drm_drv.h
> >> +++ b/include/drm/drm_drv.h
> >> @@ -736,13 +736,11 @@ void drm_dev_unplug(struct drm_device *dev);
> >> * drm_de
Re: [PATCH 0/6] Add uAPI to support ICL VME hardware for new media-driver
Quoting Stéphane Marchesin (2019-02-05 06:16:48) > On Mon, Feb 4, 2019 at 1:07 AM Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 10:57:24AM +0200, Joonas Lahtinen wrote: > > > Quoting Joonas Lahtinen (2019-01-15 16:47:27) > > > > Hi all, > > > > > > > > I would like to have some Acked-by's from you, the distro media > > > > folks Cc'd here, to document your intent to start using Intel's > > > > new media driver[1]. So if you recognize yourself (or are otherwise > > > > interested), please read on. > > > > > > > > TL;DR Distro folks, please give your Acked-by on patch [5/6] > > > > > > A gentle reminder, I'm still looking to hear back from Stephane > > > and Dave. > > > > > > We'd like to have this included in the final 5.1 drm-intel-next > > > pull request this week. > > > > > > If there are no further comments by Wed, I will conclude that we > > > have reached a silent agreement, and merge this to give enough > > > time for Rodrigo to send the PR. > > > > Maybe should add that ubunut/suse folks seem ok. Also, it's for libva, in > > the past that's been very far down the list of contentious topics. Mostly > > positive meh seems plenty good enough feedback I think. > > FWIW I think the API changes are fine. Sure it feels a bit odd at > first, but there's no better alternative that I can see either. > > Acked-by: Stéphane Marchesin > Dave commented on IRC that he's fine with us proceeding to merge with these Acks in place. Thank you all for looking into the matter, this will now find its way into Kernel version 5.1. Regards, Joonas > > > -Daniel > > > > > > > > Regards, Joonas > > > > > > > I believe most are already aware of the situation that Intel > > > > is moving to the new codebase for libva backend to support new Intel > > > > integrated graphics devices. The existing intel-libva-driver will > > > > be continue to be be supported for pre-Icelake platforms ( > > > Icelake and further platforms will only be supported from the > > > > new codebase. > > > > > > > > There's the complication that some Icelake features of the new > > > > driver will require new kernel uAPIs to work... But the new driver > > > > has not yet been well-established in the community from perspective > > > > of fulfilling [2]. This is very much due to the demand being low > > > > as Icelake is not widely available yet. So it's bit of a chicken > > > > and egg problem as we have a new platform *and* a new codebase for > > > > it simultaneously. > > > > > > > > Ahead of that community adoption, to ensure that Icelake has good > > > > kernel support from day one, we'd like to merge kernel support for > > > > the parts that have functional effect (this series). This is to > > > > avoid the scenario where end users have to update their distro > > > > kernels, like happened with Skylake. > > > > > > > > So if I could get Acked-by's from distro folks on the patch [5/6] that > > > > adds the new uAPI. That would document their intent to become an active > > > > user of the media-driver[1]. If that happens in the next week or two, > > > > it would mean that Icelake hardware features would be supported in > > > > kernel version 5.1 fully from kernel driver point of view. > > > > > > > > The new uAPI is needed to make VME feature functionally work > > > > on Icelake. It's pretty much a simple enable/disable switch for > > > > hardware configuration that only includes hardware slices compatible > > > > with the VME workload. So it's currently limited to the required on/off > > > > choice to keep things straightforward. The uAPI can be extended in the > > > > future for possible performance gains for more fine-grained control. > > > > > > > > VME is shared function to handle motion estimation. One intended > > > > usercase is in Hierarchical Motion Estimation (HME) media kernel. It > > > > provides a bigger search range with reduced cost for the search. HME > > > > should improve the encode quality with scenarios where the video has > > > > a lot of motion in it. Carl (Cc'd) can provide more details if needed. > > > > > > > > The respective IGT tests are reviewed and can be found at: > > > > > > > > https://patchwork.freedesktop.org/series/49190/ > > > > > > > > The userspace changes are reviewed and rebased here: > > > > > > > > https://github.com/intel/media-driver/pull/271 > > > > https://github.com/intel/media-driver/pull/463 > > > > > > > > Best Regards, Joonas Lahtinen > > > > > > > > Cc: dri-devel@lists.freedesktop.org > > > > Cc: Timo Aaltonen > > > > Cc: Takashi Iwai > > > > Cc: Stephane Marchesin > > > > Cc: Dave Airlie > > > > Cc: Daniel Vetter > > > > > > > > PS. This series might result in some CI failures reported as it adds > > > > new uAPI > > > > and Patchwork / CI synchronization of tests and kernel is currently > > > > WIP. > > > > > > > > [1] https://github.com/intel/media-driver > > > > [2] > > > > https://01.org/linuxgraphics/gfx-docs/drm/gpu/drm-uapi.html#open-source-userspace-requiremen
Re: [PATCH] drm/dsc: Add kernel documentation for DRM DP DSC helpers
On Mon, Feb 04, 2019 at 03:40:22PM -0800, Manasi Navare wrote:
> This patch adds appropiate kernel documentation for DRM DP helpers
> used for enabling Display Stream compression functionality in
> drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> related structure definitions and helpers in drm_dsc.c and drm_dsc.h
> Also add links between the functions and structures in the documentation.
>
> Suggested-by: Daniel Vetter
> Suggested-by: Sean Paul
> Cc: Daniel Vetter
> Cc: Sean Paul
> Signed-off-by: Manasi Navare
Awesome, more docs!
> ---
> drivers/gpu/drm/drm_dp_helper.c | 42 +-
> drivers/gpu/drm/drm_dsc.c | 13 ++-
> include/drm/drm_dp_helper.h | 15 +++-
> include/drm/drm_dsc.h | 138 ++--
> 4 files changed, 142 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 54120b6319e7..e9e0233f5b2f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1360,7 +1360,20 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
> drm_dp_desc *desc,
> EXPORT_SYMBOL(drm_dp_read_desc);
>
> /**
> - * DRM DP Helpers for DSC
> + * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
> + * supported by the DSC sink.
> + * @dsc_dpcd: DSC capabilities from DPCD
> + * @is_edp: true if its eDP, false for DP
> + *
> + * Read the slice capabilities DPCD register from DSC sink to get
> + * the maximum slice count supported. This is used to populate
> + * the DSC parameters in the &struct drm_dsc_config by the driver.
> + * Driver creates an infoframe using these parameters to populate
> + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> + *
> + * Returns:
> + * Maximum slice count supported by DSC sink or 0 its invalid
> */
> u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> bool is_edp)
> @@ -1405,6 +1418,19 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
>
> +/**
> + * drm_dp_dsc_sink_line_buf_depth() - Get the line buffer depth in bits
> which is
> + * number of bits of precision within the decoder line buffer supported by
> + * the DSC sink. This is used to populate the DSC parameters in the
> + * &struct drm_dsc_config by the driver.
> + * Driver creates an infoframe using these parameters to populate
> + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
The entire above block ends up being used as the "one-line" summary, and
no description. I guess you wanted to split it up like the one above?
The description starts after the first empty newline, everything before
that is the summary.
> + * @dsc_dpcd: DSC capabilities from DPCD
> + *
> + * Returns:
> + * Line buffer depth supported by DSC panel or 0 its invalid
> + */
> u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> {
> u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
> DP_DSC_SUPPORT];
> @@ -1434,6 +1460,20 @@ u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
>
> +/**
> + * drm_dp_dsc_sink_supported_input_bpcs() - Get all the input bits per
> component
> + * values supported by the DSC sink. This is used to populate the DSC
> parameters
> + * in the &struct drm_dsc_config by the driver.
> + * Driver creates an infoframe using these parameters to populate
> + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> + * @dsc_dpcd: DSC capabilities from DPCD
> + * @dsc_bpc: An array to be filled by this helper with supported
> + * input bpcs.
> + *
> + * Returns:
> + * Number of input BPC values parsed from the DPCD
> + */
> int drm_dp_dsc_sink_supported_input_bpcs(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>u8 dsc_bpc[3])
> {
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index bc2b23adb072..0fd56fbdf9b4 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -17,6 +17,12 @@
> /**
> * DOC: dsc helpers
> *
> + * VESA specification for DP 1.4 adds a new feature called Display Stream
> + * Compression (DSC) used to compress the pixel bits before sending it on
> + * DP/eDP/MIPI DSI interface. DSC is required to be enabled so that the
> existing
> + * display interfaces can support high resolutions at higher frames rates
> uisng
> + * the maximum available link capacity of these interfaces.
> + *
> * These functions contain some common logic and helpers to deal with VESA
> * Display Stream C
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
Den 05.02.2019 10.11, skrev Daniel Vetter:
> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 04.02.2019 16.41, skrev Daniel Vetter:
>>> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
The only thing now that makes drm_dev_unplug() special is that it sets
drm_device->unplugged. Move this code to drm_dev_unregister() so that we
can remove drm_dev_unplug().
Signed-off-by: Noralf Trønnes
---
>>
>> [...]
>>
drivers/gpu/drm/drm_drv.c | 27 +++
include/drm/drm_drv.h | 10 --
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 05bbc2b622fc..e0941200edc6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
*/
void drm_dev_unplug(struct drm_device *dev)
{
- /*
- * After synchronizing any critical read section is guaranteed to see
- * the new value of ->unplugged, and any critical section which might
- * still have seen the old value of ->unplugged is guaranteed to have
- * finished.
- */
- dev->unplugged = true;
- synchronize_srcu(&drm_unplug_srcu);
-
drm_dev_unregister(dev);
drm_dev_put(dev);
}
@@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
* drm_dev_register() but does not deallocate the device. The caller must
call
* drm_dev_put() to drop their final reference.
*
- * A special form of unregistering for hotpluggable devices is
drm_dev_unplug(),
- * which can be called while there are still open users of @dev.
+ * This function can be called while there are still open users of @dev
as long
+ * as the driver protects its device resources using drm_dev_enter() and
+ * drm_dev_exit().
*
* This should be called first in the device teardown code to make sure
- * userspace can't access the device instance any more.
+ * userspace can't access the device instance any more. Drivers that
support
+ * device unplug will probably want to call drm_atomic_helper_shutdown()
first
>>>
>>> Read once more with a bit more coffee, spotted this:
>>>
>>> s/first/afterwards/ - shutting down the hw before we've taken it away from
>>> userspace is kinda the wrong way round. It should be the inverse of driver
>>> load, which is 1) allocate structures 2) prep hw 3) register driver with
>>> the world (simplified ofc).
>>>
>>
>> The problem is that drm_dev_unregister() sets the device as unplugged
>> and if drm_atomic_helper_shutdown() is called afterwards it's not
>> allowed to touch hardware.
>>
>> I know it's the wrong order, but the only way to do it in the right
>> order is to have a separate function that sets unplugged:
>>
>> drm_dev_unregister();
>> drm_atomic_helper_shutdown();
>> drm_dev_set_unplugged();
>
> Annoying ... but yeah calling _shutdown() before we stopped userspace is
> also not going to work. Because userspace could quickly re-enable
> something, and then the refcounts would be all wrong again and leaking
> objects.
>
What happens with a USB device that is unplugged with open userspace,
will that leak objects?
> I get a bit the feeling we're over-optimizing here with trying to devm-ize
> drm_dev_register. Just getting drm_device correctly devm-ized is a big
> step forward already, and will open up a lot of TODO items across a lot of
> drivers. E.g. we could add a drm_dev_kzalloc, for allocating all the drm_*
> structs, which gets released together with drm_device. I think that's a
> much clearer path forward, I think we all agree that getting the kfree out
> of the driver codes is a good thing, and it would allow us to do this
> correctly.
>
> Then once we have that and rolled out to a few drivers we can reconsider
> the entire unregister/shutdown gordian knot here. Atm I just have no idea
> how to do this properly :-/
>
> Thoughts, other ideas?
>
Yeah, I've come to the conclusion that devm_drm_dev_register() doesn't
make much sense if we need a driver remove callback anyways.
I think devm_drm_dev_init() makes sense because it yields a cleaner
probe() function. An additional benefit is that it requires a
drm_driver->release function which is a step in the right direction to
get the drm_device lifetime right.
Do we agree that a drm_dev_set_unplugged() function is necessary to get
the remove/disconnect order right?
What about drm_dev_unplug() maybe I should just leave it be?
- amd uses drm_driver->unload, so that one takes some work to get right
to support unplug. It doesn't check the unplugged state, so really
doesn't need drm_dev_unplug() I guess. Do they have cards that can be
hotplugged?
- udl uses drm_driver->unload, doesn't use drm_atomic_helper_shutdown().
It has only one drm
Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > wrote: > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > wrote: > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > > define panel > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > still may have > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > --- > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt| > > > > > > > > > 7 +++ > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > create mode 100644 > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > really are. > > > > > > > > You're going to have to provide a compatible string for your > > > > > > > > device that > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > need any > > > > > > > > extra information that is panel specific, but you don't know > > > > > > > > that now. > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > prepare > > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific compatible > > > > > > > > string > > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > > read all > > > > > > > > the video timings from an EDID EEPROM, you can still provide a > > > > > > > > mode in > > > > > > > > the panel descriptor to serve as a fallback if for example the > > > > > > > > EEPROM > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > > timings > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel driver > > > > > > will bind to a panel device and use the corresponding descriptor. If > > > > > > your device tree contains the correct information, the descriptor is > > > > > > correct for the panel you have. > > > > > > > > > > > > In other words you need to ensure that you have the correct panel in > > > > > > device tree for the board that you're using. This is exactly the > > > > > > same > > > > > > thing as for other devices. > > > > > > > > > > > > One way to to this is to have separate device trees for each variant > > > > > > of the board that you want to support. Another variant may be to > > > > > > have > > > > > > a common device tree and then have some early firmware update the > > > > > > DTB > > > > > > with the correct panel information. > > > > > > > > > > This would defeat the point of edp, which is to standardize the mess > > > > > of > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > tables/firmware for every board you ship. Also, we do have DP quirking > > > > > infrastructure already (using the OUI), I think if there's something > > > > > that > > > > > doesn't work then we should quirk it there. > > > > > > > > The problem is that while the attempt may have been to standardize, it > > > > failed. It doesn't take into account any of the details such as timing > > > > between things like powering up the display and enabling the backlight > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > requirements because they are highly panel specific. > > > > > > Hm right, we get these from some firmware tables (and mix them with the > > > spec one, since some of the firmware values are nonsense). I don't even > > > know whether we can read the timings over dp aux somehow (you can power up > > > the panel with some pessimistic values to figure those out, and you only > > > need dp aux to work, which is much simpler than the entire panel). > > > > > > > > What does make sense though imo is if we try not to stuff the edp > > > > > panel > > > > > into panel-simple, because it's anything like a simple dumb panel. > > > > > There's > > > > > also some integration awkwardness since with this panel you need to > > > > > do dp > > > >
[Bug 109550] [regression][amd tahiti xt][vm fault] Rise of the Tomb Raider hangs the system
https://bugs.freedesktop.org/show_bug.cgi?id=109550 Sylvain BERTRAND changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org QA Contact|mesa-dev@lists.freedesktop. | |org | -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] component: Add documentation
w/compOn Thu, Jan 31, 2019 at 3:46 PM Daniel Vetter
wrote:
>
> Someone owes me a beer ...
>
> While typing these I think doing an s/component_master/aggregate/
> would be useful:
> - it's shorter :-)
> - I think component/aggregate is much more meaningful naming than
> component/puppetmaster or something like that. At least to my
> English ear "aggregate" emphasizes much more the "assemble a pile of
> things into something bigger" aspect, and there's not really much
> of a control hierarchy between aggregate and constituing components.
>
> But that's way more than a quick doc typing exercise ...
>
> Thanks to Ram for commenting on an initial draft of these docs.
Look goods to me overall (even though I'm not super-familiar with the
component framework), but see below.
> Cc: "C, Ramalingam"
> Cc: Greg Kroah-Hartman
> Cc: Russell King
> Cc: Rafael J. Wysocki
> Cc: Jaroslav Kysela
> Cc: Takashi Iwai
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Daniel Vetter
> ---
> Documentation/driver-api/device_link.rst | 3 +
> Documentation/driver-api/index.rst | 1 +
> drivers/base/component.c | 107 ++-
> include/linux/component.h| 70 +++
> 4 files changed, 178 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/driver-api/device_link.rst
> b/Documentation/driver-api/device_link.rst
> index d6763272e747..2d5919b2b337 100644
> --- a/Documentation/driver-api/device_link.rst
> +++ b/Documentation/driver-api/device_link.rst
> @@ -1,6 +1,9 @@
> .. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain
> `
> .. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain
> `
>
> +
> +.. _device_link:
> +
>
> Device links
>
> diff --git a/Documentation/driver-api/index.rst
> b/Documentation/driver-api/index.rst
> index ab38ced66a44..c0b600ed9961 100644
> --- a/Documentation/driver-api/index.rst
> +++ b/Documentation/driver-api/index.rst
> @@ -22,6 +22,7 @@ available subsections can be seen below.
> device_connection
> dma-buf
> device_link
> + component
Do I think correctly that this doc is going to be generated
automatically from the kerneldoc comments in component.c?
> message-based
> sound
> frame-buffer
> diff --git a/drivers/base/component.c b/drivers/base/component.c
> index ddcea8739c12..e5b04bce8544 100644
> --- a/drivers/base/component.c
> +++ b/drivers/base/component.c
> @@ -16,6 +16,33 @@
> #include
> #include
>
> +/**
> + * DOC: overview
> + *
> + * The component frameworks allows drivers to collect a pile of sub-devices,
s/frameworks/framework/
> + * including their bound drivers, into an aggregate driver. Various subsystem
s/subsystem/subsystems/
> + * already provide functions to get hold of such components, e.g.
> + * of_clk_get_by_name(). Anytime there's such a subsystem specific way to
> find a
> + * a device the component framework should not be used.
I would use a positive statement here, like "The component framework
can be used when such a subsystem-specific way to find a device is not
available".
> The component framework
> + * fills the niche of aggregate drivers for specific hardware, where further
> + * standardization into a subsystem doesn't make sense.
I would say "would not be practical" instead of "doesn't make sense".
> The common example is
> + * when a logical device (e.g. a DRM display driver) is spread around the
> SoC on
> + * various component (scanout engines, blending blocks, transcoders for
> various
> + * outputs and so on).
> + *
> + * The component framework also doesn't solve runtime dependencies, e.g. for
> + * system suspend and resume operations. See also :ref:`device
> + * links`.
> + *
> + * Components are registered using component_add() and unregistered with
> + * component_del(), usually from the driver's probe and disconnect functions.
> + *
> + * Aggregate drivers first assemble a component match list of what they need
> + * using component_match_add(). This is then registered as an aggregate
> driver
> + * using component_master_add_with_match(), and unregistered using
> + * component_master_del().
> + */
> +
> struct component;
>
> struct component_match_array {
> @@ -301,10 +328,24 @@ static int component_match_realloc(struct device *dev,
> return 0;
> }
>
> -/*
> - * Add a component to be matched, with a release function.
> +/**
> + * component_match_add_release - add a compent match with release callback
s/compent/component/ ?
> + * @master: device with the aggregate driver
> + * @matchptr: pointer to the list of component matches
> + * @release: release function for @compare_data
> + * @compare: compare function to match against all components
> + * @compare_data: opaque pointer passed to the @compare function
> + *
> + * This adds a new component match to the list stored in @matchptr, which the
> + * @master aggregate driver needs to function. @
Re: [PATCH] drm/omap: dsi: Fix PM for display blank with paired dss_pll calls
On 04/02/2019 17:42, Tony Lindgren wrote: > Hi, > > * Tomi Valkeinen [190204 09:57]: >> On 31/01/2019 05:32, Tony Lindgren wrote: >>> Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not >>> paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves >> >> But it is paired with dsi_pll_uninit(). > > But we need to also call dss_pll_disable(). Now we're only calling > dsi_pll_disable() and skipping dss_pll_disable(). Ok, I see now. >>> the DSS clocks enabled when the display is blanked wasting about extra >>> 5mW of power while idle. >> >> Which clocks? I think all the clocks are disabled. But if >> disconnect_lanes == false, the regulator is left enabled. > > Without this patch I'm seeing DSS_CLKCTRL bit 10 OPTFCLKEN_SYS_CLK > left enabled after blanking, also known as sys_clk in the dts. Ok. That's the source clock for DSI PLL. >> If some clocks are left enabled, then that's a bug, but this didn't seem >> to be the case after a brief review of the code. > > Yeah the code there currently is a bit confusing to follow. Yep... So there's the DSI internal code which needs to deal with ulps and disconnect_lanes, and then the external interface to the DSI PLL (so that DPI can use DSI PLL) without ulps/disconnect. I think your patch breaks this latter one, as disconnect_lanes is zero in that case and would leave the regulator enabled. This would probably be visible on e.g. Pandaboard, which uses DSI PLLs for the TFP410 DVI output, if I recall right. And storing the 'disconnect_lanes' is a bit ugly, but I don't see right away how to avoid it... Maybe the field in dsi_data should be something like "keep_lanes_powered", and default value false. In dsi_display_uninit_dsi(), we could set keep_lanes_powered = !disconnect_lanes; and after dss_pll_disable() call, set keep_lanes_powered back to false to keep it in the default state. 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 v10 23/40] misc/mei/hdcp: Client driver for HDCP application
>
> ME FW is contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver needs to communicate to ME FW for each step of the
> HDCP2.2 authentication.
>
> ME FW prepare and HDCP2.2 authentication parameters and encrypt them as
> per spec. With such parameter Driver prepares HDCP2.2 auth messages and
> communicate with HDCP2.2 sink.
>
> Similarly HDCP2. sink's response is shared with ME FW for decrypt and
> verification.
>
> Once All the steps of HDCP2.2 authentications are complete on driver's request
> ME FW will configure the port as authenticated and supply the HDCP keys to
> the Gen HW for encryption.
>
> Only after this stage HDCP2.2 driver can start the HDCP2.2 encryption for a
> port.
>
> ME FW is interfaced to kernel through MEI Bus Driver. To obtain the
> HDCP2.2 services from the ME FW through MEI Bus driver MEI Client Driver is
> developed.
>
> v2:
> hdcp files are moved to drivers/misc/mei/hdcp/ [Tomas]
> v3:
> Squashed the Kbuild support [Tomas]
> UUID renamed and Module License is modified [Tomas]
> drv_data is set to null at remove [Tomas]
> v4:
> Module name is changed to "MEI HDCP"
> I915 Selects the MEI_HDCP
> v5:
> Remove redundant text from the License header
> Fix malformed licence
> Removed the drv_data resetting.
> v6:
> K-Doc addition. [Tomas]
>
> Signed-off-by: Ramalingam C
> Signed-off-by: Tomas Winkler
> ---
> drivers/misc/mei/Kconfig | 7 +
> drivers/misc/mei/Makefile| 2 ++
> drivers/misc/mei/hdcp/Makefile | 7 +
> drivers/misc/mei/hdcp/mei_hdcp.c | 65
>
> 4 files changed, 81 insertions(+)
> create mode 100644 drivers/misc/mei/hdcp/Makefile create mode 100644
> drivers/misc/mei/hdcp/mei_hdcp.c
>
> diff --git a/drivers/misc/mei/Kconfig b/drivers/misc/mei/Kconfig index
> c49e1d2269af..9c518b7f0011 100644
> --- a/drivers/misc/mei/Kconfig
> +++ b/drivers/misc/mei/Kconfig
> @@ -43,3 +43,10 @@ config INTEL_MEI_TXE
>
> Supported SoCs:
> Intel Bay Trail
> +
> +config INTEL_MEI_HDCP
> + tristate "Intel HDCP2.2 services of ME Interface"
> + select INTEL_MEI_ME
> + depends on DRM_I915
> + help
> + MEI Support for HDCP2.2 Services on Intel SoCs.
> diff --git a/drivers/misc/mei/Makefile b/drivers/misc/mei/Makefile index
> d9215fc4e499..8c2d9565a4cb 100644
> --- a/drivers/misc/mei/Makefile
> +++ b/drivers/misc/mei/Makefile
> @@ -24,3 +24,5 @@ mei-txe-objs += hw-txe.o
>
> mei-$(CONFIG_EVENT_TRACING) += mei-trace.o CFLAGS_mei-trace.o = -
> I$(src)
> +
> +obj-$(CONFIG_INTEL_MEI_HDCP) += hdcp/
> diff --git a/drivers/misc/mei/hdcp/Makefile b/drivers/misc/mei/hdcp/Makefile
> new file mode 100644 index ..b2de072aa0de
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# Copyright (c) 2017-2018, Intel Corporation.
> +#
> +# Makefile - HDCP client driver for Intel MEI Bus Driver.
> +
> +obj-$(CONFIG_INTEL_MEI_HDCP) += mei_hdcp.o
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> new file mode 100644
> index ..ca5010ad7dd7
> --- /dev/null
> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: (GPL-2.0+)
GPL-2.0 (drop +)
> +/*
> + * Copyright © 2017-2018 Intel Corporation
> + *
> + * Mei_hdcp.c: HDCP client driver for mei bus
> + *
> + * Authors:
> + * Ramalingam C */
> +
> +/**
> + * DOC: MEI_HDCP Client Driver
> + *
> + * This is a client driver to the mei_bus to make the HDCP2.2 services
> +of
> + * ME FW available for the interested consumers like I915.
> + *
> + * This module will act as a translation layer between HDCP protocol
> + * implementor(I915) and ME FW by translating HDCP2.2 authentication
> + * messages to ME FW command payloads and vice versa.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static int mei_hdcp_probe(struct mei_cl_device *cldev,
> + const struct mei_cl_device_id *id) {
> + int ret;
> +
> + ret = mei_cldev_enable(cldev);
> + if (ret < 0)
> + dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
> +
> + return ret;
> +}
> +
> +static int mei_hdcp_remove(struct mei_cl_device *cldev) {
> + return mei_cldev_disable(cldev);
> +}
> +
> +#define MEI_UUID_HDCPUUID_LE(0xB638AB7E, 0x94E2,
> 0x4EA2, 0xA5, \
> + 0x52, 0xD1, 0xC5, 0x4B, \
> + 0x62, 0x7F, 0x04)
Should be now moving to GUID_INIT from UUID_LE()
Thought it may be done later.
> +static struct mei_cl_device_id mei_hdcp_tbl[] = {
> + { .uuid = MEI_UUID_HDCP, .version = MEI_CL_VERSION_ANY },
> + { }
> +};
> +MODULE_DEVICE_TABLE(mei, mei_hdcp_tbl);
> +
> +static struct mei_cl_driver mei_hdcp_driver = {
> + .id_table = mei_hdcp_tbl,
> + .name = KBUILD_MODNAME,
> + .probe = mei_hdcp_probe,
> +
Re: [PATCH v2] i2c: of: Try to find an I2C adapter matching the parent
On Fri, Jan 25, 2019 at 02:11:42PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> If an I2C adapter doesn't match the provided device tree node, also try
> matching the parent's device tree node. This allows finding an adapter
> based on the device node of the parent device that was used to register
> it.
>
> This fixes a regression on Tegra124-based Chromebooks (Nyan) where the
> eDP controller registers an I2C adapter that is used to read to EDID.
> After commit 993a815dcbb2 ("dt-bindings: panel: Add missing .txt
> suffix") this stopped working because the I2C adapter could no longer
> be found. The approach in this patch fixes the regression without
> introducing the issues that the above commit solved.
>
> Fixes: 17ab7806de0c ("drm: don't link DP aux i2c adapter to the hardware
> device node")
> Signed-off-by: Thierry Reding
Removed the duplicated Tested-by and applied to for-next, thanks!
I applied to -next because I want this core change more regression
testing in next. If this goes good, I will do a cleanup series to not
use the of_node of the parent twice.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for HDCP2.2
>
> >-Original Message-
> >From: C, Ramalingam
> >Sent: Thursday, January 31, 2019 12:30 PM
> >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >daniel.vet...@ffwll.ch; Winkler, Tomas ;
> >Shankar, Uma
> >Cc: C, Ramalingam
> >Subject: [PATCH v10 24/40] misc/mei/hdcp: Define ME FW interface for
> >HDCP2.2
> >
> >Defines the HDCP specific ME FW interfaces such as Request CMDs,
> >payload structure for CMDs and their response status codes.
> >
> >This patch defines payload size(Excluding the Header)for each WIRED
> >HDCP2.2 CMDs.
> >
> >v2: Rebased.
> >v3:
> > Extra comments are removed.
> >v4:
> > %s/\/\*\*/\/\*
> >v5:
> > Extra lines are removed.
> >v6:
> > Remove redundant text from the License header
> > %s/LPRIME_HALF/V_PRIME_HALF
> > %s/uintxx_t/uxx
> >v7:
> > Extra taps removed.
> >
> >Signed-off-by: Ramalingam C
>
> Looks ok to me.
> Reviewed-by: Uma Shankar
Acked-by Tomas Winkler
>
> >---
> > drivers/misc/mei/hdcp/mei_hdcp.h | 366
> >+++
> > 1 file changed, 366 insertions(+)
> > create mode 100644 drivers/misc/mei/hdcp/mei_hdcp.h
> >
> >diff --git a/drivers/misc/mei/hdcp/mei_hdcp.h
> >b/drivers/misc/mei/hdcp/mei_hdcp.h
> >new file mode 100644
> >index ..582a7e27ae29
> >--- /dev/null
> >+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> >@@ -0,0 +1,366 @@
> >+/* SPDX-License-Identifier: (GPL-2.0+) */
> >+/*
> >+ * Copyright © 2017-2018 Intel Corporation
> >+ *
> >+ * Authors:
> >+ * Ramalingam C */
> >+
> >+#ifndef __MEI_HDCP_H__
> >+#define __MEI_HDCP_H__
> >+
> >+#include
> >+
> >+/* me_hdcp_status: Enumeration of all HDCP Status Codes */ enum
> >+me_hdcp_status {
> >+ME_HDCP_STATUS_SUCCESS = 0x,
> >+
> >+/* WiDi Generic Status Codes */
> >+ME_HDCP_STATUS_INTERNAL_ERROR = 0x1000,
> >+ME_HDCP_STATUS_UNKNOWN_ERROR= 0x1001,
> >+ME_HDCP_STATUS_INCORRECT_API_VERSION= 0x1002,
> >+ME_HDCP_STATUS_INVALID_FUNCTION = 0x1003,
> >+ME_HDCP_STATUS_INVALID_BUFFER_LENGTH= 0x1004,
> >+ME_HDCP_STATUS_INVALID_PARAMS = 0x1005,
> >+ME_HDCP_STATUS_AUTHENTICATION_FAILED= 0x1006,
> >+
> >+/* WiDi Status Codes */
> >+ME_HDCP_INVALID_SESSION_STATE = 0x6000,
> >+ME_HDCP_SRM_FRAGMENT_UNEXPECTED = 0x6001,
> >+ME_HDCP_SRM_INVALID_LENGTH = 0x6002,
> >+ME_HDCP_SRM_FRAGMENT_OFFSET_INVALID = 0x6003,
> >+ME_HDCP_SRM_VERIFICATION_FAILED = 0x6004,
> >+ME_HDCP_SRM_VERSION_TOO_OLD = 0x6005,
> >+ME_HDCP_RX_CERT_VERIFICATION_FAILED = 0x6006,
> >+ME_HDCP_RX_REVOKED = 0x6007,
> >+ME_HDCP_H_VERIFICATION_FAILED = 0x6008,
> >+ME_HDCP_REPEATER_CHECK_UNEXPECTED = 0x6009,
> >+ME_HDCP_TOPOLOGY_MAX_EXCEEDED = 0x600A,
> >+ME_HDCP_V_VERIFICATION_FAILED = 0x600B,
> >+ME_HDCP_L_VERIFICATION_FAILED = 0x600C,
> >+ME_HDCP_STREAM_KEY_ALLOC_FAILED = 0x600D,
> >+ME_HDCP_BASE_KEY_RESET_FAILED = 0x600E,
> >+ME_HDCP_NONCE_GENERATION_FAILED = 0x600F,
> >+ME_HDCP_STATUS_INVALID_E_KEY_STATE = 0x6010,
> >+ME_HDCP_STATUS_INVALID_CS_ICV = 0x6011,
> >+ME_HDCP_STATUS_INVALID_KB_KEY_STATE = 0x6012,
> >+ME_HDCP_STATUS_INVALID_PAVP_MODE_ICV= 0x6013,
> >+ME_HDCP_STATUS_INVALID_PAVP_MODE= 0x6014,
> >+ME_HDCP_STATUS_LC_MAX_ATTEMPTS = 0x6015,
> >+
> >+/* New status for HDCP 2.1 */
> >+ME_HDCP_STATUS_MISMATCH_IN_M= 0x6016,
> >+
> >+/* New status code for HDCP 2.2 Rx */
> >+ME_HDCP_STATUS_RX_PROV_NOT_ALLOWED = 0x6017,
> >+ME_HDCP_STATUS_RX_PROV_WRONG_SUBJECT= 0x6018,
> >+ME_HDCP_RX_NEEDS_PROVISIONING = 0x6019,
> >+ME_HDCP_BKSV_ICV_AUTH_FAILED= 0x6020,
> >+ME_HDCP_STATUS_INVALID_STREAM_ID= 0x6021,
> >+ME_HDCP_STATUS_CHAIN_NOT_INITIALIZED= 0x6022,
> >+ME_HDCP_FAIL_NOT_EXPECTED = 0x6023,
> >+ME_HDCP_FAIL_HDCP_OFF = 0x6024,
> >+ME_HDCP_FAIL_INVALID_PAVP_MEMORY_MODE = 0x6025,
> >+ME_HDCP_FAIL_AES_ECB_FAILURE= 0x6026,
> >+ME_HDCP_FEATURE_NOT_SUPPORTED = 0x6027,
> >+ME_HDCP_DMA_READ_ERROR = 0x6028,
> >+ME_HDCP_DMA_WRITE_ERROR = 0x6029,
> >+ME_HDCP_FAIL_INVALID_PACKET_SIZE= 0x6030,
> >+ME_HDCP_H264_PARSING_ERROR = 0x6031,
> >+ME_HDCP_HDCP2_ERRATA_VIDEO_VIOLATION= 0x6032,
> >+ME_HDCP_HDCP2_ERRATA_AUDIO_VIOLATION= 0x6033,
> >+ME_HDCP_TX_ACTIVE_ERROR = 0x6034,
> >+ME_HDCP_MODE_CHANGE_ERROR = 0x6035,
> >+ME_HDCP_STREAM_TYPE_ERROR = 0x6036,
> >+ME_HDCP_STREAM_MANAGE_NOT_POSSIBLE = 0x6037,
> >+
> >+ME_HDCP_STATUS_PORT_INVALID_COMMAND = 0x6038,
> >+ME_HDCP_STATUS_UNSUPPORTED_PROTOCOL = 0x6039,
RE: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
> >Request ME FW to start the HDCP2.2 session for an intel port.
> >Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
> to
> >ME FW.
> >
> >On Success, ME FW will start a HDCP2.2 session for the port and
> >provides the content for HDCP2.2 AKE_Init message.
> >
> >v2: Rebased.
> >v3:
> > cldev is add as a separate parameter [Tomas]
> > Redundant comment and typecast are removed [Tomas]
> >v4:
> > %zd is used for size [Alexander]
> > %s/return -1/return -EIO [Alexander]
> > Spellings in commit msg is fixed [Uma]
> >v5: Rebased.
> >v6:
> > Collected the rb-ed by.
> > Realigning the patches in the series.
> >v7:
> > Adjust to the new mei interface.
> > Fix for kdoc.
> >v8:
> > K-Doc Addition.
> > memcpy for const length.
> >
> >Signed-off-by: Ramalingam C
> >Reviewed-by: Uma Shankar
>
> Latest set look ok. You can keep the RB.
>
> >---
> > drivers/misc/mei/hdcp/mei_hdcp.c | 82
> >
> > drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
> > 2 files changed, 110 insertions(+)
> >
> >diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> >b/drivers/misc/mei/hdcp/mei_hdcp.c
> >index ca5010ad7dd7..534d29c8ee86 100644
> >--- a/drivers/misc/mei/hdcp/mei_hdcp.c
> >+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
> >@@ -23,6 +23,88 @@
> > #include
> > #include
> > #include
> >+#include
> >+#include
> >+#include
> >+
> >+#include "mei_hdcp.h"
> >+
> >+/**
> >+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session
> >+in ME FW
> >+ * @dev: device corresponding to the mei_cl_device
> >+ * @hdcp_data: Intel HW specific hdcp data
> >+ * @ake_data: AKE_Init msg output.
> >+ *
> >+ * Return: 0 on Success, <0 on Failure.
> >+ */
> >+static int
> >+mei_initiate_hdcp2_session(struct device *dev, struct hdcp_port_data *data,
> >+ struct hdcp2_ake_init *ake_data) {
Breaking naming conventions : all functions should be prefixed with mei_hdcp_
e.g. mei_hdcp_ initiate_session()
> >+struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
> >+struct wired_cmd_initiate_hdcp2_session_out
> >+session_init_out = { { 0 } };
> >+struct mei_cl_device *cldev;
> >+ssize_t byte;
> >+
> >+if (!dev || !data || !ake_data)
> >+return -EINVAL;
> >+
> >+cldev = to_mei_cl_device(dev);
> >+
> >+session_init_in.header.api_version = HDCP_API_VERSION;
> >+session_init_in.header.command_id =
> >WIRED_INITIATE_HDCP2_SESSION;
> >+session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
> >+session_init_in.header.buffer_len =
> >+
> > WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
> >+
> >+session_init_in.port.integrated_port_type = data->port_type;
> >+session_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data-
> >>port);
> >+session_init_in.protocol = data->protocol;
> >+
> >+byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
> >+ sizeof(session_init_in));
> >+if (byte < 0) {
> >+dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
> >+return byte;
> >+}
> >+
> >+byte = mei_cldev_recv(cldev, (u8 *)&session_init_out,
> >+ sizeof(session_init_out));
> >+if (byte < 0) {
> >+dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
> >+return byte;
> >+}
> >+
> >+if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
> >+dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
> >+WIRED_INITIATE_HDCP2_SESSION,
> >+session_init_out.header.status);
> >+return -EIO;
> >+}
> >+
> >+ake_data->msg_id = HDCP_2_2_AKE_INIT;
> >+ake_data->tx_caps = session_init_out.tx_caps;
> >+memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
> >+
> >+return 0;
> >+}
> >+
> >+static __attribute__((unused))
> >+struct i915_hdcp_component_ops mei_hdcp_ops = {
> >+.owner = THIS_MODULE,
> >+.initiate_hdcp2_session = mei_initiate_hdcp2_session,
> >+.verify_receiver_cert_prepare_km = NULL,
> >+.verify_hprime = NULL,
> >+.store_pairing_info = NULL,
> >+.initiate_locality_check = NULL,
> >+.verify_lprime = NULL,
> >+.get_session_key = NULL,
> >+.repeater_check_flow_prepare_ack = NULL,
> >+.verify_mprime = NULL,
> >+.enable_hdcp_authentication = NULL,
> >+.close_hdcp_session = NULL,
> >+};
> >
> > static int mei_hdcp_probe(struct mei_cl_device *cldev,
> > const struct mei_cl_device_id *id) diff --git
> >a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
> >index 582a7e27ae29..f831db3cbd54 100644
> >--- a/drivers/misc/mei/hdcp/mei_hdcp.h
> >+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
> >@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
> > struct hdcp_port_id port;
> > } __packed;
> >
> >+enum mei_hdcp_ddi {
> >+MEI_DDI_INVALID_
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #70 from jake.hed...@yahoo.com --- Ok, that seems to have stabilized my system. It at least withstood constant use for 4+ hours. I went idle, stressed it, idle again, and no crashes. My current setup is Buster and idle=nomwait. I am going to move to add idle=nomwait to my startup permanently for now and continue reading on the behavior so I can better troubleshoot moving ahead. From my cursory glance this seems to indicate it was a CPU issue rather than display problem. Is that way off base? Thank you for the suggestion, I will report back if issue reoccur. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109557] [CI][BAT] random tests - crash / warn - Received signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=109557 Martin Peres changed: What|Removed |Added Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org Priority|medium |highest QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Whiteboard||ReadyForDev Component|DRM/Intel |IGT -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109557] [CI][BAT] random tests - crash / warn - Received signal SIGSEGV.
https://bugs.freedesktop.org/show_bug.cgi?id=109557 Martin Peres changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |maxime.ripard@free-electron |.org|s.com -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 25/40] misc/mei/hdcp: Initiate Wired HDCP2.2 Tx Session
Thanks Tomas.
On 2/5/2019 6:39 PM, Winkler, Tomas wrote:
Request ME FW to start the HDCP2.2 session for an intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
to
ME FW.
On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.
v2: Rebased.
v3:
cldev is add as a separate parameter [Tomas]
Redundant comment and typecast are removed [Tomas]
v4:
%zd is used for size [Alexander]
%s/return -1/return -EIO [Alexander]
Spellings in commit msg is fixed [Uma]
v5: Rebased.
v6:
Collected the rb-ed by.
Realigning the patches in the series.
v7:
Adjust to the new mei interface.
Fix for kdoc.
v8:
K-Doc Addition.
memcpy for const length.
Signed-off-by: Ramalingam C
Reviewed-by: Uma Shankar
Latest set look ok. You can keep the RB.
---
drivers/misc/mei/hdcp/mei_hdcp.c | 82
drivers/misc/mei/hdcp/mei_hdcp.h | 28 ++
2 files changed, 110 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
b/drivers/misc/mei/hdcp/mei_hdcp.c
index ca5010ad7dd7..534d29c8ee86 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.c
+++ b/drivers/misc/mei/hdcp/mei_hdcp.c
@@ -23,6 +23,88 @@
#include
#include
#include
+#include
+#include
+#include
+
+#include "mei_hdcp.h"
+
+/**
+ * mei_initiate_hdcp2_session() - Initiate a Wired HDCP2.2 Tx Session
+in ME FW
+ * @dev: device corresponding to the mei_cl_device
+ * @hdcp_data: Intel HW specific hdcp data
+ * @ake_data: AKE_Init msg output.
+ *
+ * Return: 0 on Success, <0 on Failure.
+ */
+static int
+mei_initiate_hdcp2_session(struct device *dev, struct hdcp_port_data *data,
+ struct hdcp2_ake_init *ake_data) {
Breaking naming conventions : all functions should be prefixed with mei_hdcp_
e.g. mei_hdcp_ initiate_session()
I will rename all the function name similarly.
--Ram
+ struct wired_cmd_initiate_hdcp2_session_in session_init_in = { { 0 } };
+ struct wired_cmd_initiate_hdcp2_session_out
+ session_init_out = { { 0 } };
+ struct mei_cl_device *cldev;
+ ssize_t byte;
+
+ if (!dev || !data || !ake_data)
+ return -EINVAL;
+
+ cldev = to_mei_cl_device(dev);
+
+ session_init_in.header.api_version = HDCP_API_VERSION;
+ session_init_in.header.command_id =
WIRED_INITIATE_HDCP2_SESSION;
+ session_init_in.header.status = ME_HDCP_STATUS_SUCCESS;
+ session_init_in.header.buffer_len =
+
WIRED_CMD_BUF_LEN_INITIATE_HDCP2_SESSION_IN;
+
+ session_init_in.port.integrated_port_type = data->port_type;
+ session_init_in.port.physical_port = (u8)GET_MEI_DDI_INDEX(data-
port);
+ session_init_in.protocol = data->protocol;
+
+ byte = mei_cldev_send(cldev, (u8 *)&session_init_in,
+ sizeof(session_init_in));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_send failed. %zd\n", byte);
+ return byte;
+ }
+
+ byte = mei_cldev_recv(cldev, (u8 *)&session_init_out,
+ sizeof(session_init_out));
+ if (byte < 0) {
+ dev_dbg(dev, "mei_cldev_recv failed. %zd\n", byte);
+ return byte;
+ }
+
+ if (session_init_out.header.status != ME_HDCP_STATUS_SUCCESS) {
+ dev_dbg(dev, "ME cmd 0x%08X Failed. Status: 0x%X\n",
+ WIRED_INITIATE_HDCP2_SESSION,
+ session_init_out.header.status);
+ return -EIO;
+ }
+
+ ake_data->msg_id = HDCP_2_2_AKE_INIT;
+ ake_data->tx_caps = session_init_out.tx_caps;
+ memcpy(ake_data->r_tx, session_init_out.r_tx, HDCP_2_2_RTX_LEN);
+
+ return 0;
+}
+
+static __attribute__((unused))
+struct i915_hdcp_component_ops mei_hdcp_ops = {
+ .owner = THIS_MODULE,
+ .initiate_hdcp2_session = mei_initiate_hdcp2_session,
+ .verify_receiver_cert_prepare_km = NULL,
+ .verify_hprime = NULL,
+ .store_pairing_info = NULL,
+ .initiate_locality_check = NULL,
+ .verify_lprime = NULL,
+ .get_session_key = NULL,
+ .repeater_check_flow_prepare_ack = NULL,
+ .verify_mprime = NULL,
+ .enable_hdcp_authentication = NULL,
+ .close_hdcp_session = NULL,
+};
static int mei_hdcp_probe(struct mei_cl_device *cldev,
const struct mei_cl_device_id *id) diff --git
a/drivers/misc/mei/hdcp/mei_hdcp.h b/drivers/misc/mei/hdcp/mei_hdcp.h
index 582a7e27ae29..f831db3cbd54 100644
--- a/drivers/misc/mei/hdcp/mei_hdcp.h
+++ b/drivers/misc/mei/hdcp/mei_hdcp.h
@@ -363,4 +363,32 @@ struct wired_cmd_repeater_auth_stream_req_out {
struct hdcp_port_id port;
} __packed;
+enum mei_hdcp_ddi {
+ MEI_DDI_INVALID_PORT = 0x0,
+
+ MEI_DDI_B = 1,
+ MEI_DDI_C,
+ MEI_DDI_D,
+ MEI_DDI_E,
+ MEI_DDI_F,
+ MEI_DDI_A = 7,
+ MEI_DDI_RANGE_
RE: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and enable modeset
>-Original Message-
>From: Shankar, Uma
>Sent: Monday, February 4, 2019 10:49 PM
>To: Ville Syrjälä
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: RE: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property and
>enable modeset
>
>
>
>>-Original Message-
>>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>>Behalf Of Ville Syrjälä
>>Sent: Saturday, February 2, 2019 12:31 AM
>>To: Shankar, Uma
>>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville
>>; Lankhorst, Maarten
>>; dri- de...@lists.freedesktop.org
>>Subject: Re: [Intel-gfx] [v10 3/3] drm/i915: Attach colorspace property
>>and enable modeset
>>
>>On Wed, Jan 30, 2019 at 06:24:26PM +0530, Uma Shankar wrote:
>>> This patch attaches the colorspace connector property to the hdmi
>>> connector. Based on colorspace change, modeset will be triggered to
>>> switch to new colorspace.
>>>
>>> Based on colorspace property value create an infoframe with
>>> appropriate colorspace. This can be used to send an infoframe packet
>>> with proper colorspace value set which will help to enable wider
>>> color gamut like BT2020 on sink.
>>>
>>> This patch attaches and enables HDMI colorspace, DP will be taken
>>> care separately.
>>>
>>> v2: Merged the changes of creating infoframe as well to this patch as
>>> per Maarten's suggestion.
>>>
>>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>>> colorspaces as suggested by Ville and Maarten.
>>>
>>> v4: Addressed Chris and Ville's review comments, and created a common
>>> colorspace property for DP and HDMI, filtered the list based on the
>>> colorspaces supported by the respective protocol standard. Handle the
>>> default case properly.
>>>
>>> v5: Merged the DP handling along with platform colorspace handling as
>>> per Shashank's comments.
>>>
>>> v6: Reverted to old design of exposing all colorspaces to userspace
>>> as per Ville's review comment
>>>
>>> v7: Fixed a checkpatch complaint, Addressed Maarten' review comment,
>>> updated the RB from Maarten and Jani's ack.
>>>
>>> Signed-off-by: Uma Shankar
>>> Acked-by: Jani Nikula
>>> Reviewed-by: Maarten Lankhorst
>>> ---
>>> drivers/gpu/drm/i915/intel_atomic.c| 1 +
>>> drivers/gpu/drm/i915/intel_connector.c | 8
>>> drivers/gpu/drm/i915/intel_drv.h | 1 +
>>> drivers/gpu/drm/i915/intel_hdmi.c | 25 +
>>> 4 files changed, 35 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>>> b/drivers/gpu/drm/i915/intel_atomic.c
>>> index 16263ad..a4bb906 100644
>>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>>> @@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
>>drm_connector *conn,
>>> */
>>> if (new_conn_state->force_audio != old_conn_state->force_audio ||
>>> new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb
>>> ||
>>> + new_conn_state->base.colorspace !=
>>> +old_conn_state->base.colorspace ||
>>> new_conn_state->base.picture_aspect_ratio != old_conn_state-
>>>base.picture_aspect_ratio ||
>>> new_conn_state->base.content_type != old_conn_state-
>>>base.content_type ||
>>> new_conn_state->base.scaling_mode !=
>>> old_conn_state->base.scaling_mode)
>>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>>> b/drivers/gpu/drm/i915/intel_connector.c
>>> index ee16758..8352d0b 100644
>>> --- a/drivers/gpu/drm/i915/intel_connector.c
>>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>>> @@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector
>>*connector,
>>> connector->dev->mode_config.aspect_ratio_property,
>>> DRM_MODE_PICTURE_ASPECT_NONE);
>>> }
>>> +
>>> +void
>>> +intel_attach_colorspace_property(struct drm_connector *connector) {
>>> + if (!drm_mode_create_colorspace_property(connector))
>>> + drm_object_attach_property(&connector->base,
>>> + connector->colorspace_property, 0); }
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index 85b913e..5178a9a 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct
>>> drm_connector *connector, void
>>> intel_attach_force_audio_property(struct drm_connector *connector);
>>> void intel_attach_broadcast_rgb_property(struct drm_connector
>>> *connector); void intel_attach_aspect_ratio_property(struct
>>> drm_connector *connector);
>>> +void intel_attach_colorspace_property(struct drm_connector
>>> +*connector);
>>>
>>> /* intel_csr.c */
>>> void intel_csr_ucode_init(struct drm_i915_private *); diff --git
>>> a/drivers/gpu/drm/i915/intel_hdmi.c
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index 97a98e1..5c5009d 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> ++
Re: [PATCH 4/4] drm/panel: Add Rondo RB070D30 panel
Hi Sam, On Tue, Jan 29, 2019 at 04:48:33PM +0100, Sam Ravnborg wrote: > > > > + } > > > > + > > > > + drm_mode_set_name(mode); > > > > + > > > > + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED; > > > > + drm_mode_probed_add(connector, mode); > > > > + > > > > + panel->connector->display_info.bpc = 8; > > > > + panel->connector->display_info.width_mm = 154; > > > > + panel->connector->display_info.height_mm = 85; > > > See comment on height above. > > > Same goes for bpc > > > > Sorry, I'm not sure to follow you here. bpc and height are both set? > > I assumed that if we had specified height and width in display_mode > then we did not have to do it here. But I may be wrong. It looks like it's not done by the core, but panel-simple simply copies it, so I'll do it as well. Thanks for the suggestion! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v11 1/4] drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well defined in CEA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78 +++
include/drm/drm_connector.h | 50 +
3 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 9a1f41a..9b5d44f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8475396..4309873 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_SMPTE_170M, "SMPTE_170M" },
+ { DRM_MODE_COLORIMETRY_BT709, "BT709" },
+ /* Sta
[v11 2/4] drm: Add DP colorspace property
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Split the changes to have separate colorspace property for
DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v8: Addressed Ville's review comments and updated the colorspace
macro definitions.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_connector.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4309873..86b368bf 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
+ /* DP MSA Colorimetry */
+ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" },
+ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
+ { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
+ { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1614,6 +1632,14 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
{
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace", dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
+
+ if (!prop)
+ return -ENOMEM;
} else {
DRM_DEBUG_KMS("Colorspace property not supported\n");
return 0;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v11 3/4] drm: Add colorspace info to AVI Infoframe
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_edid.c | 28
include/drm/drm_edid.h | 6 ++
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 86b368bf..086085d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
/* Colorimetry based on IEC 61966-2-5 */
{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
+ { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
/* DP MSA Colorimetry */
{ DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" },
{ DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b190..1fc0978 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4925,6 +4925,34 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/**
+ * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
+ * colorspace information
+ * @frame: HDMI AVI infoframe
+ * @conn_state: connector state
+ */
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state)
+{
+ if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
+ /* Set No Data as default for HDMI */
+ frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA;
+ } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XVYCC_601) {
+ frame->colorimetry = conn_state->colorspace;
+ } else {
+ frame->colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ /*
+* Starting from extended list where COLORIMETRY_XV_YCC_601
+* is the first extended mode and its value is 0 as per HDMI
+* specification.
+* ToDO: Extend to support ACE formats defined in CTA 861.G
+*/
+ frame->extended_colorimetry = conn_state->colorspace -
+ DRM_MODE_COLORIMETRY_XVYCC_601;
+ }
+}
+
+/**
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
* @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8dc1a08..9d3b5b9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,6 +331,7 @@ struct cea_sad {
struct drm_encoder;
struct drm_connector;
+struct drm_connector_state;
struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
struct drm_connector *connector,
const struct drm_display_mode
*mode);
+
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state);
+
void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
struct drm_connector *connector,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v11 0/4] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Addressed Maarten' review comment, updated the RB from Maarten and Jani Nikula's ack. Also fixed sparse warnings and checkpatch complaints. v11: Addressed Ville's review comments. Modified MACRO names, added infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace macro definitions defined in CTA 861.G. Currently linux/hdmi lacks support for ACE formats, will be added as a separate series. Uma Shankar (4): drm: Add HDMI colorspace property drm: Add DP colorspace property drm: Add colorspace info to AVI Infoframe drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 104 + drivers/gpu/drm/drm_edid.c | 28 + drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 8 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 13 + include/drm/drm_connector.h| 50 include/drm/drm_edid.h | 6 ++ 9 files changed, 215 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v11 4/4] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed a checkpatch complaint, Addressed Maarten' review
comment, updated the RB from Maarten and Jani's ack.
v8: Moved colorspace AVI Infoframe programming to drm core and
removed from driver as per Ville's suggestion.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 13 +
4 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..a4bb906 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_colorspace_property(connector))
+ drm_object_attach_property(&connector->base,
+ connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 85b913e..5178a9a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1783,6 +1783,7 @@ int intel_connector_update_modes(struct drm_connector
*connector,
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 97a98e1..0b5e483 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ drm_hdmi_avi_infoframe_colorspace(&frame.avi, conn_state);
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
conn_state->connector,
adjusted_mode,
@@ -2143,10 +2145,21 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_digital_port *intel_dig_port =
+ hdmi_to_dig_port(intel_hdmi);
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+
+ /*
+
Re: [linux-sunxi] Re: [PATCH RESEND v2 06/12] drm/sun4i: rgb: Add 1% tolerance to dclk frequency check when bridge is connected
On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote: > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote: > > >> IIRC, from the previous discussion, HDMI had a tolerancy requirement > > >> in the standard. Do you know if there's such a thing for eDP? That > > >> would solve the issue for all the eDP displays at once. > > > > > >I don't have access to eDP standard - vesa.org says it's available to > > >members only. > > > > Try out to grab an old version? > > > > I remember 1.0 is open. > > I can't find anything regarding dot clock tolerance in DisplayPort > specification. I guess since the DP is a VESA spec, it's probably .5%, just like on the EDID (well, CVT). Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] component: Add documentation
On Tue, Feb 05, 2019 at 11:47:58AM +0100, Rafael J. Wysocki wrote:
> w/compOn Thu, Jan 31, 2019 at 3:46 PM Daniel Vetter
> wrote:
> >
> > Someone owes me a beer ...
> >
> > While typing these I think doing an s/component_master/aggregate/
> > would be useful:
> > - it's shorter :-)
> > - I think component/aggregate is much more meaningful naming than
> > component/puppetmaster or something like that. At least to my
> > English ear "aggregate" emphasizes much more the "assemble a pile of
> > things into something bigger" aspect, and there's not really much
> > of a control hierarchy between aggregate and constituing components.
> >
> > But that's way more than a quick doc typing exercise ...
> >
> > Thanks to Ram for commenting on an initial draft of these docs.
>
> Look goods to me overall (even though I'm not super-familiar with the
> component framework), but see below.
>
> > Cc: "C, Ramalingam"
> > Cc: Greg Kroah-Hartman
> > Cc: Russell King
> > Cc: Rafael J. Wysocki
> > Cc: Jaroslav Kysela
> > Cc: Takashi Iwai
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/driver-api/device_link.rst | 3 +
> > Documentation/driver-api/index.rst | 1 +
> > drivers/base/component.c | 107 ++-
> > include/linux/component.h| 70 +++
> > 4 files changed, 178 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/driver-api/device_link.rst
> > b/Documentation/driver-api/device_link.rst
> > index d6763272e747..2d5919b2b337 100644
> > --- a/Documentation/driver-api/device_link.rst
> > +++ b/Documentation/driver-api/device_link.rst
> > @@ -1,6 +1,9 @@
> > .. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain
> > `
> > .. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain
> > `
> >
> > +
> > +.. _device_link:
> > +
> >
> > Device links
> >
> > diff --git a/Documentation/driver-api/index.rst
> > b/Documentation/driver-api/index.rst
> > index ab38ced66a44..c0b600ed9961 100644
> > --- a/Documentation/driver-api/index.rst
> > +++ b/Documentation/driver-api/index.rst
> > @@ -22,6 +22,7 @@ available subsections can be seen below.
> > device_connection
> > dma-buf
> > device_link
> > + component
>
> Do I think correctly that this doc is going to be generated
> automatically from the kerneldoc comments in component.c?
No. I failed to git add component.rst, which has the necessary kernel-doc
directives to generate the documentation from the source code comments.
I've implemented all your other suggestions, thanks a lot for taking a
lot. Will send out v2 asap.
Thanks, Daniel
>
> > message-based
> > sound
> > frame-buffer
> > diff --git a/drivers/base/component.c b/drivers/base/component.c
> > index ddcea8739c12..e5b04bce8544 100644
> > --- a/drivers/base/component.c
> > +++ b/drivers/base/component.c
> > @@ -16,6 +16,33 @@
> > #include
> > #include
> >
> > +/**
> > + * DOC: overview
> > + *
> > + * The component frameworks allows drivers to collect a pile of
> > sub-devices,
>
> s/frameworks/framework/
>
> > + * including their bound drivers, into an aggregate driver. Various
> > subsystem
>
> s/subsystem/subsystems/
>
> > + * already provide functions to get hold of such components, e.g.
> > + * of_clk_get_by_name(). Anytime there's such a subsystem specific way to
> > find a
> > + * a device the component framework should not be used.
>
> I would use a positive statement here, like "The component framework
> can be used when such a subsystem-specific way to find a device is not
> available".
>
> > The component framework
> > + * fills the niche of aggregate drivers for specific hardware, where
> > further
> > + * standardization into a subsystem doesn't make sense.
>
> I would say "would not be practical" instead of "doesn't make sense".
>
> > The common example is
> > + * when a logical device (e.g. a DRM display driver) is spread around the
> > SoC on
> > + * various component (scanout engines, blending blocks, transcoders for
> > various
> > + * outputs and so on).
> > + *
> > + * The component framework also doesn't solve runtime dependencies, e.g.
> > for
> > + * system suspend and resume operations. See also :ref:`device
> > + * links`.
> > + *
> > + * Components are registered using component_add() and unregistered with
> > + * component_del(), usually from the driver's probe and disconnect
> > functions.
> > + *
> > + * Aggregate drivers first assemble a component match list of what they
> > need
> > + * using component_match_add(). This is then registered as an aggregate
> > driver
> > + * using component_master_add_with_match(), and unregistered using
> > + * component_master_del().
> > + */
> > +
> > struct component;
> >
> > struct component_match_array {
> > @@ -301,10 +328,24 @@ static int component_match_realloc(struct device *dev,
> >
[PATCH] component: Add documentation
Someone owes me a beer ...
While typing these I think doing an s/component_master/aggregate/
would be useful:
- it's shorter :-)
- I think component/aggregate is much more meaningful naming than
component/puppetmaster or something like that. At least to my
English ear "aggregate" emphasizes much more the "assemble a pile of
things into something bigger" aspect, and there's not really much
of a control hierarchy between aggregate and constituing components.
But that's way more than a quick doc typing exercise ...
Thanks to Ram for commenting on an initial draft of these docs.
v2: Review from Rafael:
- git add Documenation/driver-api/component.rst
- lots of polish to the wording + spelling fixes.
Cc: "C, Ramalingam"
Cc: Greg Kroah-Hartman
Cc: Russell King
Cc: Rafael J. Wysocki
Cc: Jaroslav Kysela
Cc: Takashi Iwai
Cc: Rodrigo Vivi
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 17
Documentation/driver-api/device_link.rst | 3 +
Documentation/driver-api/index.rst | 1 +
drivers/base/component.c | 107 ++-
include/linux/component.h| 70 +++
5 files changed, 195 insertions(+), 3 deletions(-)
create mode 100644 Documentation/driver-api/component.rst
diff --git a/Documentation/driver-api/component.rst
b/Documentation/driver-api/component.rst
new file mode 100644
index ..3407ff0424b9
--- /dev/null
+++ b/Documentation/driver-api/component.rst
@@ -0,0 +1,17 @@
+=
+Component Framework for Aggregate Drivers
+=
+
+.. kernel-doc:: drivers/base/component.c
+ :doc: overview
+
+
+API
+===
+
+.. kernel-doc:: include/linux/component.h
+ :internal:
+
+.. kernel-doc:: drivers/base/component.c
+ :export:
+
diff --git a/Documentation/driver-api/device_link.rst
b/Documentation/driver-api/device_link.rst
index d6763272e747..2d5919b2b337 100644
--- a/Documentation/driver-api/device_link.rst
+++ b/Documentation/driver-api/device_link.rst
@@ -1,6 +1,9 @@
.. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain
`
.. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain
`
+
+.. _device_link:
+
Device links
diff --git a/Documentation/driver-api/index.rst
b/Documentation/driver-api/index.rst
index ab38ced66a44..c0b600ed9961 100644
--- a/Documentation/driver-api/index.rst
+++ b/Documentation/driver-api/index.rst
@@ -22,6 +22,7 @@ available subsections can be seen below.
device_connection
dma-buf
device_link
+ component
message-based
sound
frame-buffer
diff --git a/drivers/base/component.c b/drivers/base/component.c
index ddcea8739c12..4851e1006f11 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -16,6 +16,33 @@
#include
#include
+/**
+ * DOC: overview
+ *
+ * The component framework allows drivers to collect a pile of sub-devices,
+ * including their bound drivers, into an aggregate driver. Various subsystems
+ * already provide functions to get hold of such components, e.g.
+ * of_clk_get_by_name(). The component framework can be used when such a
+ * subsystem-specific way to find a device is not available: The component
+ * framework fills the niche of aggregate drivers for specific hardware, where
+ * further standardization into a subsystem would not be practical. The common
+ * example is when a logical device (e.g. a DRM display driver) is spread
around
+ * the SoC on various component (scanout engines, blending blocks, transcoders
+ * for various outputs and so on).
+ *
+ * The component framework also doesn't solve runtime dependencies, e.g. for
+ * system suspend and resume operations. See also :ref:`device
+ * links`.
+ *
+ * Components are registered using component_add() and unregistered with
+ * component_del(), usually from the driver's probe and disconnect functions.
+ *
+ * Aggregate drivers first assemble a component match list of what they need
+ * using component_match_add(). This is then registered as an aggregate driver
+ * using component_master_add_with_match(), and unregistered using
+ * component_master_del().
+ */
+
struct component;
struct component_match_array {
@@ -301,10 +328,24 @@ static int component_match_realloc(struct device *dev,
return 0;
}
-/*
- * Add a component to be matched, with a release function.
+/**
+ * component_match_add_release - add a component match with release callback
+ * @master: device with the aggregate driver
+ * @matchptr: pointer to the list of component matches
+ * @release: release function for @compare_data
+ * @compare: compare function to match against all components
+ * @compare_data: opaque pointer passed to the @compare function
+ *
+ * This adds a new component match to the list stored in @matchptr, which the
+ * @master aggregate driver needs to function. @matchptr must be initialized to
+ * NU
Re: [Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
What I want to know is what is calling your machine ‘localhorst’? Sent from my iPhone > On Nov 20, 2018, at 9:15 AM, bugzilla-dae...@freedesktop.org wrote: > > Comment # 47 on bug 105733 from Allan > I have really bad news. > > I'm delaying a lot to answer because I literally sent for warranty or replaced > ALL of my components in the PC. > > The CPU (R7 1800X) was replaced from a batch 21 to a new by AMD itself batched > 35. > > But OK, let's talk about the amdgpu : > > (In reply to Andrey Grodzovsky from comment #25) > > (In reply to Allan from comment #12) > > Can you build latest kernel (4.18) and grab again latest firmware and try > > again ? > > Links to kernel and firmware: > > https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > > > > For reasons already explained here I couldn't either compile or test it > before, > so please don't be mad with me : > - Sold my old PC. > - My notebook was completely filled with files. > - Components on warranty. Testing everything else. > > So I managed to borrow a PC to test the video cards. I have tested only the > nvidia one to prove for AMD that the GPU is working and the pci-controller (a > guess of mine) of the CPU/chipset that is broken. Going to test the RX480 on > this PC as soon as possible. My warranties are expiring and I had to enumerate > priorities. > > I already said it here but, with the 1800X I couldn't even clone the git > repository (the checksum always fails, tried many times). > > Then I managed to free some space on my notebook and started to build > yesterday. > - Included amd-ucode firmware. > - Included polaris10 firmware (for RX480). > - Made some optimizations for ryzen as descbribed on the gentoo's dedicated > page. > > Compiled, version 4.20-rc1 as present in the branch. No errors reported. > > There are 2 main applications that are easier to test right now to find the > problems : > - Metro 2033 Redux through steam. > - Left for Dead 2 through steam. > > Started Metro 2033, worked for some minutes with no issue, but it was for some > reason without any sound. Closed. Turned off the HDMI audio on pavucontrol to > use only the default output. Restarted steam. > > Started Left for Dead 2 this time. Was able to change graphics settings to max > without AA and vsync. Played for 15 seconds and got a screen freeze. Waited > for > a script to record properly the logs and temps. Hard rebooted. This time even > my BIOS/EFI screen had a green background, but still operational. Everything > was green except the text. Rebooted again, got back to normal colors. > > And here are the logs : > > kern.log about Firefox usage : > > Nov 14 05:26:50 desk kernel: [ 324.714998] Chrome_~dThread[1788]: segfault > > at 0 ip 7fbfee5e3181 sp 7fbfec2d1ad0 error 6 in > > libxul.so[7fbfee5cf000+3a2c000] > > It points that the CPU stills with either a problematic microcode or is > defective. > > dmesg about amdgpu screen freeze : > > [ 3323.920795] amdgpu :09:00.0: GPU fault detected: 146 0x080c for > > process hl2_linux pid 14648 thread amdgpu_cs:0 pid 14653 > > [ 3323.920799] amdgpu :09:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > > 0x > > [ 3323.920801] amdgpu :09:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > > 0x0200800C > > [ 3323.920804] amdgpu :09:00.0: VM fault (0x0c, vmid 1, pasid 32774) at > > page 0, read from 'TC0' (0x54433000) (8) > > [ 3334.103233] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, > > signaled seq=274140, emitted seq=274142 > > [ 3334.103239] amdgpu :09:00.0: GPU reset begin! > > [ 3344.332607] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* > > [CRTC:46:crtc-0] hw_done or flip_done timed out > > [ 3504.834097] INFO: task kworker/u32:2:3872 blocked for more than 120 > > seconds. > > [ 3504.834103] Not tainted 4.20.0-rc1-amd #2 > > [ 3504.834105] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > > this message. > > [ 3504.834107] kworker/u32:2 D0 3872 2 0x8000 > > [ 3504.834123] Workqueue: events_unbound commit_work [drm_kms_helper] > > [ 3504.834126] Call Trace: > > [ 3504.834133] ? __schedule+0x2a0/0x880 > > [ 3504.834136] schedule+0x28/0x80 > > [ 3504.834139] schedule_timeout+0x25d/0x380 > > [ 3504.834217] ? dce110_timing_generator_get_position+0x5b/0x70 [amdgpu] > > [ 3504.834292] ? dce110_timing_generator_get_crtc_scanoutpos+0x70/0xb0 > > [amdgpu] > > [ 3504.834297] dma_fence_default_wait+0x23b/0x2a0 > > [ 3504.834301] ? dma_fence_release+0x90/0x90 > > [ 3504.834304] dma_fence_wait_timeout+0xdd/0x100 > > [ 3504.834308] reservation_object_wait_timeout_rcu+0x161/0x270 > > [ 3504.834387] amdgpu_dm_do_flip+0x112/0x370 [amdgpu] > > [ 3504.834468] amdgpu_dm_atomic_commit_tail+0x68b/0xcd0 [amdgpu] > > [ 3504.834472] ? __switch_to_asm+0x40/0x70 > > [ 3504.834475] ? wait_for_completion_timeout+0x3b/0x1a0 > > [ 3
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #71 from Garry Hurley Jr --- What I want to know is what is calling your machine ‘localhorst’? Sent from my iPhone > On Nov 20, 2018, at 9:15 AM, bugzilla-dae...@freedesktop.org wrote: > > Comment # 47 on bug 105733 from Allan > I have really bad news. > > I'm delaying a lot to answer because I literally sent for warranty or replaced > ALL of my components in the PC. > > The CPU (R7 1800X) was replaced from a batch 21 to a new by AMD itself batched > 35. > > But OK, let's talk about the amdgpu : > > (In reply to Andrey Grodzovsky from comment #25) > > (In reply to Allan from comment #12) > > Can you build latest kernel (4.18) and grab again latest firmware and try > > again ? > > Links to kernel and firmware: > > https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ > > > > For reasons already explained here I couldn't either compile or test it > before, > so please don't be mad with me : > - Sold my old PC. > - My notebook was completely filled with files. > - Components on warranty. Testing everything else. > > So I managed to borrow a PC to test the video cards. I have tested only the > nvidia one to prove for AMD that the GPU is working and the pci-controller (a > guess of mine) of the CPU/chipset that is broken. Going to test the RX480 on > this PC as soon as possible. My warranties are expiring and I had to enumerate > priorities. > > I already said it here but, with the 1800X I couldn't even clone the git > repository (the checksum always fails, tried many times). > > Then I managed to free some space on my notebook and started to build > yesterday. > - Included amd-ucode firmware. > - Included polaris10 firmware (for RX480). > - Made some optimizations for ryzen as descbribed on the gentoo's dedicated > page. > > Compiled, version 4.20-rc1 as present in the branch. No errors reported. > > There are 2 main applications that are easier to test right now to find the > problems : > - Metro 2033 Redux through steam. > - Left for Dead 2 through steam. > > Started Metro 2033, worked for some minutes with no issue, but it was for some > reason without any sound. Closed. Turned off the HDMI audio on pavucontrol to > use only the default output. Restarted steam. > > Started Left for Dead 2 this time. Was able to change graphics settings to max > without AA and vsync. Played for 15 seconds and got a screen freeze. Waited > for > a script to record properly the logs and temps. Hard rebooted. This time even > my BIOS/EFI screen had a green background, but still operational. Everything > was green except the text. Rebooted again, got back to normal colors. > > And here are the logs : > > kern.log about Firefox usage : > > Nov 14 05:26:50 desk kernel: [ 324.714998] Chrome_~dThread[1788]: segfault > > at 0 ip 7fbfee5e3181 sp 7fbfec2d1ad0 error 6 in > > libxul.so[7fbfee5cf000+3a2c000] > > It points that the CPU stills with either a problematic microcode or is > defective. > > dmesg about amdgpu screen freeze : > > [ 3323.920795] amdgpu :09:00.0: GPU fault detected: 146 0x080c for > > process hl2_linux pid 14648 thread amdgpu_cs:0 pid 14653 > > [ 3323.920799] amdgpu :09:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > > 0x > > [ 3323.920801] amdgpu :09:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > > 0x0200800C > > [ 3323.920804] amdgpu :09:00.0: VM fault (0x0c, vmid 1, pasid 32774) at > > page 0, read from 'TC0' (0x54433000) (8) > > [ 3334.103233] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, > > signaled seq=274140, emitted seq=274142 > > [ 3334.103239] amdgpu :09:00.0: GPU reset begin! > > [ 3344.332607] [drm:amdgpu_dm_atomic_check [amdgpu]] *ERROR* > > [CRTC:46:crtc-0] hw_done or flip_done timed out > > [ 3504.834097] INFO: task kworker/u32:2:3872 blocked for more than 120 > > seconds. > > [ 3504.834103] Not tainted 4.20.0-rc1-amd #2 > > [ 3504.834105] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > > this message. > > [ 3504.834107] kworker/u32:2 D0 3872 2 0x8000 > > [ 3504.834123] Workqueue: events_unbound commit_work [drm_kms_helper] > > [ 3504.834126] Call Trace: > > [ 3504.834133] ? __schedule+0x2a0/0x880 > > [ 3504.834136] schedule+0x28/0x80 > > [ 3504.834139] schedule_timeout+0x25d/0x380 > > [ 3504.834217] ? dce110_timing_generator_get_position+0x5b/0x70 [amdgpu] > > [ 3504.834292] ? dce110_timing_generator_get_crtc_scanoutpos+0x70/0xb0 > > [amdgpu] > > [ 3504.834297] dma_fence_default_wait+0x23b/0x2a0 > > [ 3504.834301] ? dma_fence_release+0x90/0x90 > > [ 3504.834304] dma_fence_wait_timeout+0xdd/0x100 > > [ 3504.834308] reservation_object_wait_timeout_rcu+0x161/0x270 > > [ 3504.834387] amdgpu_dm_do_flip+0x112/0x370 [amdgpu] > > [ 3504.834468] amdgpu_dm_atomic_commit_tail+0x68b/0xcd0 [amdgpu] > > [ 3504.834472] ?
Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
> Create a new connector property to program colorspace to sink
> devices. Modern sink devices support more than 1 type of
> colorspace like 601, 709, BT2020 etc. This helps to switch
> based on content type which is to be displayed. The decision
> lies with compositors as to in which scenarios, a particular
> colorspace will be picked.
>
> This will be helpful mostly to switch to higher gamut colorspaces
> like BT2020 when the media content is encoded as BT2020. Thereby
> giving a good visual experience to users.
>
> The expectation from userspace is that it should parse the EDID
> and get supported colorspaces. Use this property and switch to the
> one supported. Sink supported colorspaces should be retrieved by
> userspace from EDID and driver will not explicitly expose them.
>
> Basically the expectation from userspace is:
> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>colorspace
> - Set this new property to let the sink know what it
>converted the CRTC output to.
>
> v2: Addressed Maarten and Ville's review comments. Enhanced
> the colorspace enum to incorporate both HDMI and DP supported
> colorspaces. Also, added a default option for colorspace.
>
> v3: Removed Adobe references from enum definitions as per
> Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
> Default to an unset state where driver will assign the colorspace
> is not chosen by user, suggested by Ville and Maarten. Addressed
> other misc review comments from Maarten. Split the changes to
> have separate colorspace property for DP and HDMI.
>
> v4: Addressed Chris and Ville's review comments, and created a
> common colorspace property for DP and HDMI, filtered the list
> based on the colorspaces supported by the respective protocol
> standard.
>
> v5: Made the property creation helper accept enum list based on
> platform capabilties as suggested by Shashank. Consolidated HDMI
> and DP property creation in the common helper.
>
> v6: Addressed Shashank's review comments.
>
> v7: Added defines instead of enum in uapi as per Brian Starkey's
> suggestion in order to go with string matching at userspace. Updated
> the commit message to add more details as well kernel docs.
>
> v8: Addressed Maarten's review comments.
>
> v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> Stone's comments and moved to drm include file. Moved back to older
> design with exposing all HDMI colorspaces to userspace since infoframe
> capability is there even on legacy platforms, as per Ville's review
> comments.
>
> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>
> v11: Addressed Ville's review comments. Updated the Macro naming and
> added DCI-P3 colorspace as well defined in CEA 861.G spec.
>
> Signed-off-by: Uma Shankar
> Acked-by: Jani Nikula
> Reviewed-by: Shashank Sharma
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> drivers/gpu/drm/drm_connector.c | 78
> +++
> include/drm/drm_connector.h | 50 +
> 3 files changed, 132 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41a..9b5d44f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> return -EINVAL;
> }
> state->content_protection = val;
> + } else if (property == connector->colorspace_property) {
> + state->colorspace = val;
> } else if (property == config->writeback_fb_id_property) {
> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
> val);
> int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
> @@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
> *val = state->picture_aspect_ratio;
> } else if (property == config->content_type_property) {
> *val = state->content_type;
> + } else if (property == connector->colorspace_property) {
> + *val = state->colorspace;
> } else if (property == connector->scaling_mode_property) {
> *val = state->scaling_mode;
> } else if (property == connector->content_protection_property) {
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 8475396..4309873 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> };
> DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
>
> +static const struct drm_prop_enum_list hdmi_colorspaces[] = {
> + /* For Default case, driver will set the colors
Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
>
>
> Den 05.02.2019 10.11, skrev Daniel Vetter:
> > On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 04.02.2019 16.41, skrev Daniel Vetter:
> >>> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
> ---
> >>
> >> [...]
> >>
> drivers/gpu/drm/drm_drv.c | 27 +++
> include/drm/drm_drv.h | 10 --
> 2 files changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 05bbc2b622fc..e0941200edc6 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
> */
> void drm_dev_unplug(struct drm_device *dev)
> {
> -/*
> - * After synchronizing any critical read section is guaranteed
> to see
> - * the new value of ->unplugged, and any critical section which
> might
> - * still have seen the old value of ->unplugged is guaranteed
> to have
> - * finished.
> - */
> -dev->unplugged = true;
> -synchronize_srcu(&drm_unplug_srcu);
> -
> drm_dev_unregister(dev);
> drm_dev_put(dev);
> }
> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
> * drm_dev_register() but does not deallocate the device. The caller
> must call
> * drm_dev_put() to drop their final reference.
> *
> - * A special form of unregistering for hotpluggable devices is
> drm_dev_unplug(),
> - * which can be called while there are still open users of @dev.
> + * This function can be called while there are still open users of @dev
> as long
> + * as the driver protects its device resources using drm_dev_enter() and
> + * drm_dev_exit().
> *
> * This should be called first in the device teardown code to make sure
> - * userspace can't access the device instance any more.
> + * userspace can't access the device instance any more. Drivers that
> support
> + * device unplug will probably want to call
> drm_atomic_helper_shutdown() first
> >>>
> >>> Read once more with a bit more coffee, spotted this:
> >>>
> >>> s/first/afterwards/ - shutting down the hw before we've taken it away from
> >>> userspace is kinda the wrong way round. It should be the inverse of driver
> >>> load, which is 1) allocate structures 2) prep hw 3) register driver with
> >>> the world (simplified ofc).
> >>>
> >>
> >> The problem is that drm_dev_unregister() sets the device as unplugged
> >> and if drm_atomic_helper_shutdown() is called afterwards it's not
> >> allowed to touch hardware.
> >>
> >> I know it's the wrong order, but the only way to do it in the right
> >> order is to have a separate function that sets unplugged:
> >>
> >>drm_dev_unregister();
> >>drm_atomic_helper_shutdown();
> >>drm_dev_set_unplugged();
> >
> > Annoying ... but yeah calling _shutdown() before we stopped userspace is
> > also not going to work. Because userspace could quickly re-enable
> > something, and then the refcounts would be all wrong again and leaking
> > objects.
> >
>
> What happens with a USB device that is unplugged with open userspace,
> will that leak objects?
Maybe we've jumped to conclusions. drm_atomic_helper_shutdown() will run
as normal, the only thing that should be skipped is actually touching the
hw (as long as the driver doesn't protect too much with
drm_dev_enter/exit). So all the software updates (including refcounting
updates) will still be done. Ofc current udl is not yet atomic, so in
reality something else happens.
And we ofc still have the same issue that if you just unload the driver,
then the hw will stay on (which might really confuse the driver on next
load, when it assumes that it only gets loaded from cold boot where
everything is off - which usually is the case on an arm soc at least).
> > I get a bit the feeling we're over-optimizing here with trying to devm-ize
> > drm_dev_register. Just getting drm_device correctly devm-ized is a big
> > step forward already, and will open up a lot of TODO items across a lot of
> > drivers. E.g. we could add a drm_dev_kzalloc, for allocating all the drm_*
> > structs, which gets released together with drm_device. I think that's a
> > much clearer path forward, I think we all agree that getting the kfree out
> > of the driver codes is a good thing, and it would allow us to do this
> > correctly.
> >
> > Then once we have that and rolled out to a few drivers we can reconside
Re: [Intel-gfx] [v11 3/4] drm: Add colorspace info to AVI Infoframe
On Tue, Feb 05, 2019 at 09:33:36PM +0530, Uma Shankar wrote:
> This adds colorspace information to HDMI AVI infoframe.
> A helper function is added to program the same.
>
> v2: Moved this to drm core instead of i915 driver.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/drm_connector.c | 2 +-
> drivers/gpu/drm/drm_edid.c | 28
> include/drm/drm_edid.h | 6 ++
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 86b368bf..086085d 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct
> drm_display_info *info,
> { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
> /* Colorimetry based on IEC 61966-2-5 */
> { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
> - { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
> + { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
> /* DP MSA Colorimetry */
> { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" },
> { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 990b190..1fc0978 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4925,6 +4925,34 @@ static bool is_hdmi2_sink(struct drm_connector
> *connector)
> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>
> /**
> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
> + * colorspace information
> + * @frame: HDMI AVI infoframe
> + * @conn_state: connector state
> + */
> +void
> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
> + const struct drm_connector_state *conn_state)
> +{
> + if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
> + /* Set No Data as default for HDMI */
> + frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA;
> + } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XVYCC_601) {
> + frame->colorimetry = conn_state->colorspace;
> + } else {
> + frame->colorimetry = HDMI_COLORIMETRY_EXTENDED;
> + /*
> + * Starting from extended list where COLORIMETRY_XV_YCC_601
> + * is the first extended mode and its value is 0 as per HDMI
> + * specification.
> + * ToDO: Extend to support ACE formats defined in CTA 861.G
> + */
> + frame->extended_colorimetry = conn_state->colorspace -
> + DRM_MODE_COLORIMETRY_XVYCC_601;
IMO if you don't want to make the numbers based on the spec, then this
sould become a proper lookup table.
> + }
> +}
> +
> +/**
> * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
> *quantization range information
> * @frame: HDMI AVI infoframe
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 8dc1a08..9d3b5b9 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -331,6 +331,7 @@ struct cea_sad {
>
> struct drm_encoder;
> struct drm_connector;
> +struct drm_connector_state;
> struct drm_display_mode;
>
> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
> @@ -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
> drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
> *frame,
> struct drm_connector *connector,
> const struct drm_display_mode
> *mode);
> +
> +void
> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
> + const struct drm_connector_state *conn_state);
> +
> void
> drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> struct drm_connector *connector,
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND v2 08/12] dt-bindings: add binding for generic eDP panel
On Tue, Feb 05, 2019 at 11:24:19AM +0100, Thierry Reding wrote: > On Tue, Feb 05, 2019 at 09:57:37AM +0100, Daniel Vetter wrote: > > On Mon, Feb 04, 2019 at 05:22:58PM +0100, Thierry Reding wrote: > > > On Mon, Feb 04, 2019 at 04:59:09PM +0100, Daniel Vetter wrote: > > > > On Mon, Feb 04, 2019 at 12:22:18PM +0100, Thierry Reding wrote: > > > > > On Mon, Feb 04, 2019 at 10:40:12AM +0100, Daniel Vetter wrote: > > > > > > On Mon, Feb 04, 2019 at 09:23:59AM +0100, Thierry Reding wrote: > > > > > > > On Mon, Feb 04, 2019 at 12:13:55AM -0800, Vasily Khoruzhick wrote: > > > > > > > > On Sun, Feb 3, 2019 at 11:43 PM Thierry Reding > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sun, Feb 03, 2019 at 10:54:57AM -0800, Vasily Khoruzhick > > > > > > > > > wrote: > > > > > > > > > > eDP panels usually have EDID EEPROM, so there's no need to > > > > > > > > > > define panel > > > > > > > > > > width/height or any modes/timings in dts. But this panel > > > > > > > > > > still may have > > > > > > > > > > regulator and/or backlight. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Vasily Khoruzhick > > > > > > > > > > --- > > > > > > > > > > .../devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > | 7 +++ > > > > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > create mode 100644 > > > > > > > > > > Documentation/devicetree/bindings/display/panel/panel-edp.txt > > > > > > > > > > > > > > > > > > Please don't try to make panels look more generic than they > > > > > > > > > really are. > > > > > > > > > You're going to have to provide a compatible string for your > > > > > > > > > device that > > > > > > > > > is more specific than "panel-edp". You claim that you don't > > > > > > > > > need any > > > > > > > > > extra information that is panel specific, but you don't know > > > > > > > > > that now. > > > > > > > > > We have in the past thought that we didn't need things like > > > > > > > > > prepare > > > > > > > > > delay, but then we ran into situations where we did need them. > > > > > > > > > > > > > > > > > > Just do what everybody else does. Provide a specific > > > > > > > > > compatible string > > > > > > > > > and match on that in the panel-simple driver. Even if you can > > > > > > > > > read all > > > > > > > > > the video timings from an EDID EEPROM, you can still provide > > > > > > > > > a mode in > > > > > > > > > the panel descriptor to serve as a fallback if for example > > > > > > > > > the EEPROM > > > > > > > > > is faulty on some device. > > > > > > > > > > > > > > > > Pinebook used several 768p panels that have slightly different > > > > > > > > timings > > > > > > > > and recent batch uses 1080p panel. > > > > > > > > > > > > > > > > What panel descriptor should I use as fallback? > > > > > > > > > > > > > > You don't use panel descriptors as fallback. The simple-panel > > > > > > > driver > > > > > > > will bind to a panel device and use the corresponding descriptor. > > > > > > > If > > > > > > > your device tree contains the correct information, the descriptor > > > > > > > is > > > > > > > correct for the panel you have. > > > > > > > > > > > > > > In other words you need to ensure that you have the correct panel > > > > > > > in > > > > > > > device tree for the board that you're using. This is exactly the > > > > > > > same > > > > > > > thing as for other devices. > > > > > > > > > > > > > > One way to to this is to have separate device trees for each > > > > > > > variant > > > > > > > of the board that you want to support. Another variant may be to > > > > > > > have > > > > > > > a common device tree and then have some early firmware update the > > > > > > > DTB > > > > > > > with the correct panel information. > > > > > > > > > > > > This would defeat the point of edp, which is to standardize the > > > > > > mess of > > > > > > panels (at least somewhat) and avoid having to change the DT/ACPI > > > > > > tables/firmware for every board you ship. Also, we do have DP > > > > > > quirking > > > > > > infrastructure already (using the OUI), I think if there's > > > > > > something that > > > > > > doesn't work then we should quirk it there. > > > > > > > > > > The problem is that while the attempt may have been to standardize, it > > > > > failed. It doesn't take into account any of the details such as timing > > > > > between things like powering up the display and enabling the backlight > > > > > or similar. I don't know how you'd want to "quirk" those kinds of > > > > > requirements because they are highly panel specific. > > > > > > > > Hm right, we get these from some firmware tables (and mix them with the > > > > spec one, since some of the firmware values are nonsense). I don't even > > > > know whether we can read the timings over dp aux somehow (you can power > > > > up > > > > the panel with some pessimistic values to figure those out, and you only > > > > need dp aux to work, whic
[v12 0/4] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Addressed Maarten' review comment, updated the RB from Maarten and Jani Nikula's ack. Also fixed sparse warnings and checkpatch complaints. v11: Addressed Ville's review comments. Modified MACRO names, added infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace macro definitions defined in CTA 861.G. Currently linux/hdmi lacks support for ACE formats, will be added as a separate series. v12: Exported the helper API. Uma Shankar (4): drm: Add HDMI colorspace property drm: Add DP colorspace property drm: Add colorspace info to AVI Infoframe drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 104 + drivers/gpu/drm/drm_edid.c | 29 + drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 8 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 13 + include/drm/drm_connector.h| 50 include/drm/drm_edid.h | 6 ++ 9 files changed, 216 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v12 2/4] drm: Add DP colorspace property
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Split the changes to have separate colorspace property for
DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v8: Addressed Ville's review comments and updated the colorspace
macro definitions.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_connector.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 5c6f524..4f73591 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
+ /* DP MSA Colorimetry */
+ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" },
+ { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
+ { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
+ { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1614,6 +1632,14 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
{
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace", dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
+
+ if (!prop)
+ return -ENOMEM;
} else {
DRM_DEBUG_KMS("Colorspace property not supported\n");
return 0;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v12 3/4] drm: Add colorspace info to AVI Infoframe
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_edid.c | 29 +
include/drm/drm_edid.h | 6 ++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4f73591..b19e867 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
/* Colorimetry based on IEC 61966-2-5 */
{ DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
- { DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
+ { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
/* DP MSA Colorimetry */
{ DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" },
{ DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b190..6ef9f4c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4925,6 +4925,35 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/**
+ * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
+ * colorspace information
+ * @frame: HDMI AVI infoframe
+ * @conn_state: connector state
+ */
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state)
+{
+ if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
+ /* Set No Data as default for HDMI */
+ frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA;
+ } else if (conn_state->colorspace < DRM_MODE_COLORIMETRY_XVYCC_601) {
+ frame->colorimetry = conn_state->colorspace;
+ } else {
+ frame->colorimetry = HDMI_COLORIMETRY_EXTENDED;
+ /*
+* Starting from extended list where COLORIMETRY_XV_YCC_601
+* is the first extended mode and its value is 0 as per HDMI
+* specification.
+* ToDO: Extend to support ACE formats defined in CTA 861.G
+*/
+ frame->extended_colorimetry = conn_state->colorspace -
+ DRM_MODE_COLORIMETRY_XVYCC_601;
+ }
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
+
+/**
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
* @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8dc1a08..9d3b5b9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,6 +331,7 @@ struct cea_sad {
struct drm_encoder;
struct drm_connector;
+struct drm_connector_state;
struct drm_display_mode;
int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);
@@ -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector *connector,
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
struct drm_connector *connector,
const struct drm_display_mode
*mode);
+
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state);
+
void
drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
struct drm_connector *connector,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v12 1/4] drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well defined in CEA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78 +++
include/drm/drm_connector.h | 50 +
3 files changed, 132 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd40..4eb81f1 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd40eff..5c6f524 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_SMPTE_170M, "SMPTE_170M" },
+ { DRM_MODE_COLORIMETRY_BT709, "BT709" },
+ /* Sta
[v12 4/4] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed a checkpatch complaint, Addressed Maarten' review
comment, updated the RB from Maarten and Jani's ack.
v8: Moved colorspace AVI Infoframe programming to drm core and
removed from driver as per Ville's suggestion.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 13 +
4 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..a4bb906 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_colorspace_property(connector))
+ drm_object_attach_property(&connector->base,
+ connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 90ba543..ff0a24a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1785,6 +1785,7 @@ int intel_connector_update_modes(struct drm_connector
*connector,
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 97a98e1..0b5e483 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ drm_hdmi_avi_infoframe_colorspace(&frame.avi, conn_state);
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
conn_state->connector,
adjusted_mode,
@@ -2143,10 +2145,21 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_digital_port *intel_dig_port =
+ hdmi_to_dig_port(intel_hdmi);
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+
+ /*
+
Re: [PATCH 2/4] drm/sun4i: dsi: Change the start delay calculation
On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
>
> On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> wrote:
> >
> > The current calculation for the video start delay in the current DSI driver
> > is that it is the total vertical size, minus the backporch and sync length,
> > plus 1.
> >
> > However, the Allwinner code has it as the active vertical size, plus the
> > back porch and the sync length. This doesn't make any difference on the
> > only panel it has been tested with so far, since in that particular case
> > the front porch is equal to the sum of the back porch and sync length.
> >
> > This is not the case for all panels, obviously, so we need to fix it. Since
> > the Allwinner code has a bunch of extra code to deal with out of bounds
> > values, so let's add them as well.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > index 380fc527a707..e3e4ba90c059 100644
> > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > @@ -357,7 +357,12 @@ static void sun6i_dsi_inst_init(struct sun6i_dsi *dsi,
> > static u16 sun6i_dsi_get_video_start_delay(struct sun6i_dsi *dsi,
> >struct drm_display_mode *mode)
> > {
> > - return mode->vtotal - (mode->vsync_end - mode->vdisplay) + 1;
>
> According to the diagram in include/drm/drm_modes.h ,
> This is active region plus back porch plus 1, as
>
> sync_end - display = length of front porch and sync
>
> > + u16 delay = (mode->vsync_end + 1) % mode->vtotal;
>
> And this actually means
>
> (length of active region and front porch and sync pulse plus 1) %
> total length
>
> So I don't really understand what's happening here. And the modulus
> is unexplained.
Attempting to make sense of this. Allwinner's A64 BSP the following
which uses their definitions for y, vbp, vt:
s32 start_delay = panel->lcd_vt - panel->lcd_y -10;
u32 vfp = panel->lcd_vt - panel->lcd_y - panel->lcd_vbp;
u32 dsi_start_delay;
/* put start_delay to tcon. set ready sync early to dramfreq, so
set start_delay 1 */
start_delay = 1;
dsi_start_delay = panel->lcd_vt - vfp + start_delay;
if (dsi_start_delay > panel->lcd_vt)
dsi_start_delay -= panel->lcd_vt;
if (dsi_start_delay==0)
dsi_start_delay = 1;
This can be converted to
dsi_start_delay = max(1, (mode->vtotal - (mode->vtotal -
mode->vdisplay - (mode->vtotal - mode->vsync_start)) + 1) %
mode->vtotal)
and simplified to
dsi_start_delay = max(1, (mode->vtotal + mode->vdisplay -
mode->vsync_start) + 1) % mode->vtotal)
and reordered to the following
dsi_start_delay = max(1, (mode->vtotal - (mode->vsync_start -
mode->vdisplay) + 1) % mode->vtotal)
which means total length minus front porch, or length of active
portion plus back porch plus sync.
Based on your commit message, the last derivation is what you want.
ChenYu
> > +
> > + if (!delay)
> > + delay = 1;
>
> Same comment as Paul.
>
> ChenYu
>
> > +
> > + return delay;
> > }
> >
> > static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> > --
> > git-series 0.9.1
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] component: Add documentation
On Tue, Feb 05, 2019 at 05:21:07PM +0100, Daniel Vetter wrote: > Someone owes me a beer ... I find that deeply offensive - it is clearly directed at me personally as author of the component helper. There are double-standards in the kernel ecosystem with respect to documentation - there are entire subsystems way more complicated than the component *helper* which are lacking in documentation, and the subsystem authors response to requests to change that basically get ignored, or the response is "write the documentation yourself". Why does there seem to be one rule for me and one rule for everyone else? Please remove this line. > > While typing these I think doing an s/component_master/aggregate/ > would be useful: > - it's shorter :-) > - I think component/aggregate is much more meaningful naming than > component/puppetmaster or something like that. At least to my > English ear "aggregate" emphasizes much more the "assemble a pile of > things into something bigger" aspect, and there's not really much > of a control hierarchy between aggregate and constituing components. > > But that's way more than a quick doc typing exercise ... > > Thanks to Ram for commenting on an initial draft of these docs. > > v2: Review from Rafael: > - git add Documenation/driver-api/component.rst > - lots of polish to the wording + spelling fixes. > > Cc: "C, Ramalingam" > Cc: Greg Kroah-Hartman > Cc: Russell King > Cc: Rafael J. Wysocki > Cc: Jaroslav Kysela > Cc: Takashi Iwai > Cc: Rodrigo Vivi > Cc: Jani Nikula > Signed-off-by: Daniel Vetter > --- > Documentation/driver-api/component.rst | 17 > Documentation/driver-api/device_link.rst | 3 + > Documentation/driver-api/index.rst | 1 + > drivers/base/component.c | 107 ++- > include/linux/component.h| 70 +++ > 5 files changed, 195 insertions(+), 3 deletions(-) > create mode 100644 Documentation/driver-api/component.rst > > diff --git a/Documentation/driver-api/component.rst > b/Documentation/driver-api/component.rst > new file mode 100644 > index ..3407ff0424b9 > --- /dev/null > +++ b/Documentation/driver-api/component.rst > @@ -0,0 +1,17 @@ > += > +Component Framework for Aggregate Drivers > += > + > +.. kernel-doc:: drivers/base/component.c > + :doc: overview > + > + > +API > +=== > + > +.. kernel-doc:: include/linux/component.h > + :internal: > + > +.. kernel-doc:: drivers/base/component.c > + :export: > + > diff --git a/Documentation/driver-api/device_link.rst > b/Documentation/driver-api/device_link.rst > index d6763272e747..2d5919b2b337 100644 > --- a/Documentation/driver-api/device_link.rst > +++ b/Documentation/driver-api/device_link.rst > @@ -1,6 +1,9 @@ > .. |struct dev_pm_domain| replace:: :c:type:`struct dev_pm_domain > ` > .. |struct generic_pm_domain| replace:: :c:type:`struct generic_pm_domain > ` > > + > +.. _device_link: > + > > Device links > > diff --git a/Documentation/driver-api/index.rst > b/Documentation/driver-api/index.rst > index ab38ced66a44..c0b600ed9961 100644 > --- a/Documentation/driver-api/index.rst > +++ b/Documentation/driver-api/index.rst > @@ -22,6 +22,7 @@ available subsections can be seen below. > device_connection > dma-buf > device_link > + component > message-based > sound > frame-buffer > diff --git a/drivers/base/component.c b/drivers/base/component.c > index ddcea8739c12..4851e1006f11 100644 > --- a/drivers/base/component.c > +++ b/drivers/base/component.c > @@ -16,6 +16,33 @@ > #include > #include > > +/** > + * DOC: overview > + * > + * The component framework allows drivers to collect a pile of sub-devices, Helper. > + * including their bound drivers, into an aggregate driver. Various > subsystems > + * already provide functions to get hold of such components, e.g. > + * of_clk_get_by_name(). The component framework can be used when such a helper > + * subsystem-specific way to find a device is not available: The component > + * framework fills the niche of aggregate drivers for specific hardware, > where helper > + * further standardization into a subsystem would not be practical. The > common > + * example is when a logical device (e.g. a DRM display driver) is spread > around > + * the SoC on various component (scanout engines, blending blocks, > transcoders > + * for various outputs and so on). > + * > + * The component framework also doesn't solve runtime dependencies, e.g. for helper > + * system suspend and resume operations. See also :ref:`device > + * links`. > + * > + * Components are registered using component_add() and unregistered with > + * component_del(), usually from the driver's probe and disconnect functions. > + * > + * Aggregate drivers first assemble a component match list of what they need > + * using component_match_add
[Bug 109539] System freezing
https://bugs.freedesktop.org/show_bug.cgi?id=109539 --- Comment #6 from Nicholas Kazlauskas --- Do you still see the issue occur when amdgpu.dc=1 if you disable DP1.2 support in your monitor's OSD? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 5, 2019 10:02 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>
>On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
>> Create a new connector property to program colorspace to sink devices.
>> Modern sink devices support more than 1 type of colorspace like 601,
>> 709, BT2020 etc. This helps to switch based on content type which is
>> to be displayed. The decision lies with compositors as to in which
>> scenarios, a particular colorspace will be picked.
>>
>> This will be helpful mostly to switch to higher gamut colorspaces like
>> BT2020 when the media content is encoded as BT2020. Thereby giving a
>> good visual experience to users.
>>
>> The expectation from userspace is that it should parse the EDID and
>> get supported colorspaces. Use this property and switch to the one
>> supported. Sink supported colorspaces should be retrieved by userspace
>> from EDID and driver will not explicitly expose them.
>>
>> Basically the expectation from userspace is:
>> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>>colorspace
>> - Set this new property to let the sink know what it
>>converted the CRTC output to.
>>
>> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> colorspace enum to incorporate both HDMI and DP supported colorspaces.
>> Also, added a default option for colorspace.
>>
>> v3: Removed Adobe references from enum definitions as per Ville, Hans
>> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
>> state where driver will assign the colorspace is not chosen by user,
>> suggested by Ville and Maarten. Addressed other misc review comments
>> from Maarten. Split the changes to have separate colorspace property
>> for DP and HDMI.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard.
>>
>> v5: Made the property creation helper accept enum list based on
>> platform capabilties as suggested by Shashank. Consolidated HDMI and
>> DP property creation in the common helper.
>>
>> v6: Addressed Shashank's review comments.
>>
>> v7: Added defines instead of enum in uapi as per Brian Starkey's
>> suggestion in order to go with string matching at userspace. Updated
>> the commit message to add more details as well kernel docs.
>>
>> v8: Addressed Maarten's review comments.
>>
>> v9: Removed macro defines from uapi as per Brian Starkey and Daniel
>> Stone's comments and moved to drm include file. Moved back to older
>> design with exposing all HDMI colorspaces to userspace since infoframe
>> capability is there even on legacy platforms, as per Ville's review
>> comments.
>>
>> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>>
>> v11: Addressed Ville's review comments. Updated the Macro naming and
>> added DCI-P3 colorspace as well defined in CEA 861.G spec.
>>
>> Signed-off-by: Uma Shankar
>> Acked-by: Jani Nikula
>> Reviewed-by: Shashank Sharma
>> Reviewed-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> drivers/gpu/drm/drm_connector.c | 78
>+++
>> include/drm/drm_connector.h | 50 +
>> 3 files changed, 132 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 9a1f41a..9b5d44f 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> return -EINVAL;
>> }
>> state->content_protection = val;
>> +} else if (property == connector->colorspace_property) {
>> +state->colorspace = val;
>> } else if (property == config->writeback_fb_id_property) {
>> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>NULL, val);
>> int ret = drm_atomic_set_writeback_fb_for_connector(state,
>fb); @@
>> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
>drm_connector *connector,
>> *val = state->picture_aspect_ratio;
>> } else if (property == config->content_type_property) {
>> *val = state->content_type;
>> +} else if (property == connector->colorspace_property) {
>> +*val = state->colorspace;
>> } else if (property == connector->scaling_mode_property) {
>> *val = state->scaling_mode;
>> } else if (property == connector->content_protection_property) {
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 8475396..4309
RE: [Intel-gfx] [v11 3/4] drm: Add colorspace info to AVI Infoframe
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, February 5, 2019 10:03 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Syrjala,
>Ville
>; Lankhorst, Maarten
>Subject: Re: [Intel-gfx] [v11 3/4] drm: Add colorspace info to AVI Infoframe
>
>On Tue, Feb 05, 2019 at 09:33:36PM +0530, Uma Shankar wrote:
>> This adds colorspace information to HDMI AVI infoframe.
>> A helper function is added to program the same.
>>
>> v2: Moved this to drm core instead of i915 driver.
>>
>> Signed-off-by: Uma Shankar
>> ---
>> drivers/gpu/drm/drm_connector.c | 2 +-
>> drivers/gpu/drm/drm_edid.c | 28
>> include/drm/drm_edid.h | 6 ++
>> 3 files changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c index 86b368bf..086085d 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -862,7 +862,7 @@ int drm_display_info_set_bus_formats(struct
>drm_display_info *info,
>> { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
>> /* Colorimetry based on IEC 61966-2-5 */
>> { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
>> -{ DRM_MODE_COLORIMETRY_DCI_P3, "DCI-P3" },
>> +{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
>> /* DP MSA Colorimetry */
>> { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_601, "YCBCR_ITU_601" },
>> { DRM_MODE_DP_COLORIMETRY_YCBCR_ITU_709, "YCBCR_ITU_709" },
>diff
>> --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index
>> 990b190..1fc0978 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -4925,6 +4925,34 @@ static bool is_hdmi2_sink(struct drm_connector
>> *connector) EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>>
>> /**
>> + * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
>> + * colorspace information
>> + * @frame: HDMI AVI infoframe
>> + * @conn_state: connector state
>> + */
>> +void
>> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
>> + const struct drm_connector_state
>*conn_state) {
>> +if (conn_state->colorspace == DRM_MODE_COLORIMETRY_DEFAULT) {
>> +/* Set No Data as default for HDMI */
>> +frame->colorimetry = DRM_MODE_COLORIMETRY_NO_DATA;
>> +} else if (conn_state->colorspace <
>DRM_MODE_COLORIMETRY_XVYCC_601) {
>> +frame->colorimetry = conn_state->colorspace;
>> +} else {
>> +frame->colorimetry = HDMI_COLORIMETRY_EXTENDED;
>> +/*
>> + * Starting from extended list where COLORIMETRY_XV_YCC_601
>> + * is the first extended mode and its value is 0 as per HDMI
>> + * specification.
>> + * ToDO: Extend to support ACE formats defined in CTA 861.G
>> + */
>> +frame->extended_colorimetry = conn_state->colorspace -
>> +
> DRM_MODE_COLORIMETRY_XVYCC_601;
>
>IMO if you don't want to make the numbers based on the spec, then this sould
>become a proper lookup table.
Ok seems good, will define the values separately and use them here.
>> +}
>> +}
>> +
>> +/**
>> * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
>> *quantization range information
>> * @frame: HDMI AVI infoframe
>> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index
>> 8dc1a08..9d3b5b9 100644
>> --- a/include/drm/drm_edid.h
>> +++ b/include/drm/drm_edid.h
>> @@ -331,6 +331,7 @@ struct cea_sad {
>>
>> struct drm_encoder;
>> struct drm_connector;
>> +struct drm_connector_state;
>> struct drm_display_mode;
>>
>> int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads); @@
>> -358,6 +359,11 @@ int drm_av_sync_delay(struct drm_connector
>> *connector, drm_hdmi_vendor_infoframe_from_display_mode(struct
>hdmi_vendor_infoframe *frame,
>> struct drm_connector *connector,
>> const struct drm_display_mode
>*mode);
>> +
>> +void
>> +drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
>> + const struct drm_connector_state
>*conn_state);
>> +
>> void
>> drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
>> struct drm_connector *connector,
>> --
>> 1.9.1
>>
>> ___
>> Intel-gfx mailing list
>> intel-...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/dsc: Add kernel documentation for DRM DP DSC helpers
On Tue, Feb 05, 2019 at 10:55:12AM +0100, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 03:40:22PM -0800, Manasi Navare wrote:
> > This patch adds appropiate kernel documentation for DRM DP helpers
> > used for enabling Display Stream compression functionality in
> > drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> > related structure definitions and helpers in drm_dsc.c and drm_dsc.h
> > Also add links between the functions and structures in the documentation.
> >
> > Suggested-by: Daniel Vetter
> > Suggested-by: Sean Paul
> > Cc: Daniel Vetter
> > Cc: Sean Paul
> > Signed-off-by: Manasi Navare
>
> Awesome, more docs!
>
> > ---
> > drivers/gpu/drm/drm_dp_helper.c | 42 +-
> > drivers/gpu/drm/drm_dsc.c | 13 ++-
> > include/drm/drm_dp_helper.h | 15 +++-
> > include/drm/drm_dsc.h | 138 ++--
> > 4 files changed, 142 insertions(+), 66 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index 54120b6319e7..e9e0233f5b2f 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -1360,7 +1360,20 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
> > drm_dp_desc *desc,
> > EXPORT_SYMBOL(drm_dp_read_desc);
> >
> > /**
> > - * DRM DP Helpers for DSC
> > + * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
> > + * supported by the DSC sink.
> > + * @dsc_dpcd: DSC capabilities from DPCD
> > + * @is_edp: true if its eDP, false for DP
> > + *
> > + * Read the slice capabilities DPCD register from DSC sink to get
> > + * the maximum slice count supported. This is used to populate
> > + * the DSC parameters in the &struct drm_dsc_config by the driver.
> > + * Driver creates an infoframe using these parameters to populate
> > + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> > + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> > + *
> > + * Returns:
> > + * Maximum slice count supported by DSC sink or 0 its invalid
> > */
> > u8 drm_dp_dsc_sink_max_slice_count(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> >bool is_edp)
> > @@ -1405,6 +1418,19 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > }
> > EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
> >
> > +/**
> > + * drm_dp_dsc_sink_line_buf_depth() - Get the line buffer depth in bits
> > which is
> > + * number of bits of precision within the decoder line buffer supported by
> > + * the DSC sink. This is used to populate the DSC parameters in the
> > + * &struct drm_dsc_config by the driver.
> > + * Driver creates an infoframe using these parameters to populate
> > + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> > + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
>
> The entire above block ends up being used as the "one-line" summary, and
> no description. I guess you wanted to split it up like the one above?
>
> The description starts after the first empty newline, everything before
> that is the summary.
Yes I will split this as summary and description. I tested this in html docs
but my eyes failed to catch this. Thanks for pointing out.
>
> > + * @dsc_dpcd: DSC capabilities from DPCD
> > + *
> > + * Returns:
> > + * Line buffer depth supported by DSC panel or 0 its invalid
> > + */
> > u8 drm_dp_dsc_sink_line_buf_depth(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> > {
> > u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
> > DP_DSC_SUPPORT];
> > @@ -1434,6 +1460,20 @@ u8 drm_dp_dsc_sink_line_buf_depth(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> > }
> > EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
> >
> > +/**
> > + * drm_dp_dsc_sink_supported_input_bpcs() - Get all the input bits per
> > component
> > + * values supported by the DSC sink. This is used to populate the DSC
> > parameters
> > + * in the &struct drm_dsc_config by the driver.
> > + * Driver creates an infoframe using these parameters to populate
> > + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> > + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> > + * @dsc_dpcd: DSC capabilities from DPCD
> > + * @dsc_bpc: An array to be filled by this helper with supported
> > + * input bpcs.
> > + *
> > + * Returns:
> > + * Number of input BPC values parsed from the DPCD
> > + */
> > int drm_dp_dsc_sink_supported_input_bpcs(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> > u8 dsc_bpc[3])
> > {
> > diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> > index bc2b23adb072..0fd56fbdf9b4 100644
> > --- a/drivers/gpu/drm/drm_dsc.c
> > +++ b/drivers/gpu/drm/drm_dsc.c
> > @@ -17,6 +17,12 @@
> > /**
> > * DOC: dsc helpers
> > *
> > + * VESA specification for DP 1.4 adds a new feature called Disp
Re: [Intel-gfx] [PATCH] drm/i915: do not return invalid pointers as a *dentry
On Mon, Feb 04, 2019 at 08:37:01PM +0100, Greg Kroah-Hartman wrote: > On Mon, Feb 04, 2019 at 10:13:25AM -0800, Rodrigo Vivi wrote: > > On Thu, Jan 31, 2019 at 07:17:02PM +0100, Greg Kroah-Hartman wrote: > > > On Thu, Jan 31, 2019 at 09:59:26AM -0800, Rodrigo Vivi wrote: > > > > On Thu, Jan 31, 2019 at 02:15:07PM +0100, Greg Kroah-Hartman wrote: > > > > > When calling debugfs functions, they can now return error values if > > > > > something went wrong. If that happens, return a NULL as a *dentry to > > > > > the relay core instead of passing it an illegal pointer. > > > > > > > > > > The relay core should be able to handle an illegal pointer, but add > > > > > this > > > > > check to be safe. > > > > > > > > > > Cc: Jani Nikula > > > > > Cc: Joonas Lahtinen > > > > > Cc: Rodrigo Vivi > > > > > Cc: David Airlie > > > > > Cc: Daniel Vetter > > > > > Cc: intel-...@lists.freedesktop.org > > > > > Cc: dri-devel@lists.freedesktop.org > > > > > Signed-off-by: Greg Kroah-Hartman > > > > > --- > > > > > drivers/gpu/drm/i915/intel_guc_log.c | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_guc_log.c > > > > > b/drivers/gpu/drm/i915/intel_guc_log.c > > > > > index d3ebdbc0182e..8bf03497dcd8 100644 > > > > > --- a/drivers/gpu/drm/i915/intel_guc_log.c > > > > > +++ b/drivers/gpu/drm/i915/intel_guc_log.c > > > > > @@ -140,6 +140,9 @@ static struct dentry > > > > > *create_buf_file_callback(const char *filename, > > > > > > > > > > buf_file = debugfs_create_file(filename, mode, > > > > > parent, buf, > > > > > &relay_file_operations); > > > > > + if (IS_ERR(buf_file)) > > > > > + return NULL; > > > > > > > > I still see a return NULL inside debugfs_create_file on master, > > > > but probably you are ahead with some change that I didn't see yet right? > > > > > > Yes, this patch is in linux-next now and should go to Linus for > > > 5.0-final: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/commit/?h=driver-core-linus&id=ff9fb72bc07705c00795ca48631f7fffe24d2c6b > > > > > > > I'm just wondering if it wouldn't be better for now to go with > > > > > > > > if (IS_ERR_OR_NULL(buf_file)) > > > > > > Not really, because the next line is: > > > > > > > > return buf_file; > > > > > > So it's the same thing :) > > > > > > > apparently we also need it on i915_debugfs.c i915_debugfs_register() > > > > > > I have a bunch of patches I'm working on to go through and fix up all of > > > this (you shouldn't be checking the return value at all, unless you > > > really want to use it as a "real" dentry and not just something that > > > debugfs uses internally. > > > > > > But for now, you should be fine, that call will only fail if you are out > > > of memory, or did something really wrong. > > > > Reviewed-by: Rodrigo Vivi > > > > do you wanna push this with your own stuff or do you want me to pick > > up on drm-intel-next? > > Which ever is easiest for you works for me, just let me know. pushed to dinq... will be on 5.1 Thanks, Rodrigo. > > thanks, > > greg k-h > ___ > 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: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()
Den 05.02.2019 17.31, skrev Daniel Vetter:
> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 05.02.2019 10.11, skrev Daniel Vetter:
>>> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf Trønnes wrote:
Den 04.02.2019 16.41, skrev Daniel Vetter:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
>> The only thing now that makes drm_dev_unplug() special is that it sets
>> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
>> can remove drm_dev_unplug().
>>
>> Signed-off-by: Noralf Trønnes
>> ---
[...]
>> drivers/gpu/drm/drm_drv.c | 27 +++
>> include/drm/drm_drv.h | 10 --
>> 2 files changed, 19 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 05bbc2b622fc..e0941200edc6 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -366,15 +366,6 @@ EXPORT_SYMBOL(drm_dev_exit);
>> */
>> void drm_dev_unplug(struct drm_device *dev)
>> {
>> -/*
>> - * After synchronizing any critical read section is guaranteed
>> to see
>> - * the new value of ->unplugged, and any critical section which
>> might
>> - * still have seen the old value of ->unplugged is guaranteed
>> to have
>> - * finished.
>> - */
>> -dev->unplugged = true;
>> -synchronize_srcu(&drm_unplug_srcu);
>> -
>> drm_dev_unregister(dev);
>> drm_dev_put(dev);
>> }
>> @@ -832,11 +823,14 @@ EXPORT_SYMBOL(drm_dev_register);
>> * drm_dev_register() but does not deallocate the device. The caller
>> must call
>> * drm_dev_put() to drop their final reference.
>> *
>> - * A special form of unregistering for hotpluggable devices is
>> drm_dev_unplug(),
>> - * which can be called while there are still open users of @dev.
>> + * This function can be called while there are still open users of @dev
>> as long
>> + * as the driver protects its device resources using drm_dev_enter() and
>> + * drm_dev_exit().
>> *
>> * This should be called first in the device teardown code to make sure
>> - * userspace can't access the device instance any more.
>> + * userspace can't access the device instance any more. Drivers that
>> support
>> + * device unplug will probably want to call
>> drm_atomic_helper_shutdown() first
>
> Read once more with a bit more coffee, spotted this:
>
> s/first/afterwards/ - shutting down the hw before we've taken it away from
> userspace is kinda the wrong way round. It should be the inverse of driver
> load, which is 1) allocate structures 2) prep hw 3) register driver with
> the world (simplified ofc).
>
The problem is that drm_dev_unregister() sets the device as unplugged
and if drm_atomic_helper_shutdown() is called afterwards it's not
allowed to touch hardware.
I know it's the wrong order, but the only way to do it in the right
order is to have a separate function that sets unplugged:
drm_dev_unregister();
drm_atomic_helper_shutdown();
drm_dev_set_unplugged();
>>>
>>> Annoying ... but yeah calling _shutdown() before we stopped userspace is
>>> also not going to work. Because userspace could quickly re-enable
>>> something, and then the refcounts would be all wrong again and leaking
>>> objects.
>>>
>>
>> What happens with a USB device that is unplugged with open userspace,
>> will that leak objects?
>
> Maybe we've jumped to conclusions. drm_atomic_helper_shutdown() will run
> as normal, the only thing that should be skipped is actually touching the
> hw (as long as the driver doesn't protect too much with
> drm_dev_enter/exit). So all the software updates (including refcounting
> updates) will still be done. Ofc current udl is not yet atomic, so in
> reality something else happens.
>
> And we ofc still have the same issue that if you just unload the driver,
> then the hw will stay on (which might really confuse the driver on next
> load, when it assumes that it only gets loaded from cold boot where
> everything is off - which usually is the case on an arm soc at least).
>
>>> I get a bit the feeling we're over-optimizing here with trying to devm-ize
>>> drm_dev_register. Just getting drm_device correctly devm-ized is a big
>>> step forward already, and will open up a lot of TODO items across a lot of
>>> drivers. E.g. we could add a drm_dev_kzalloc, for allocating all the drm_*
>>> structs, which gets released together with drm_device. I think that's a
>>> much clearer path forward, I think we all agree that getting the kfree out
>>> of the driver codes is a good thing, and it would allow us to do this
>>> correctly.
>>>
>>
[Bug 202511] New: amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 Bug ID: 202511 Summary: amdgpu fails to load saying "Could not allocate 8192 bytes percpu data" Product: Drivers Version: 2.5 Kernel Version: 4.20.6 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mikealeone...@gmail.com Regression: No Created attachment 281007 --> https://bugzilla.kernel.org/attachment.cgi?id=281007&action=edit crashing dmesg Working on 4.17.19 (which is what I use) but any kernel 4.19* 4.20* I try has this issue. Built amdgpu as a module, when it tries to load it (or I try to modprobe it) I get [4.376629] amdgpu: Could not allocate 8192 bytes percpu data [4.377316] ath10k_pci :02:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a [4.382128] percpu: allocation failed, size=8192 align=4096 atomic=0, alloc from reserved chunk failed [4.382133] CPU: 1 PID: 2620 Comm: systemd-udevd Not tainted 4.20.6-gentoo #1 [4.382135] Hardware name: Acer Aspire A315-41/Metapod_RR, BIOS V1.11 10/30/2018 [4.382137] Call Trace: [4.382148] dump_stack+0x46/0x5b [4.382154] pcpu_alloc+0x56e/0x590 [4.382160] ? find_module_all+0x4c/0x80 [4.382165] load_module+0xb51/0x1e80 [4.382170] ? wait_woken+0x80/0x80 [4.382175] __se_sys_finit_module+0xe0/0xf0 [4.382180] do_syscall_64+0x4a/0x100 [4.382185] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [4.382189] RIP: 0033:0x7fb64cd77fb9 [4.382193] Code: 00 00 00 75 05 48 83 c4 18 c3 e8 42 a5 01 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 9f 4e 2c 00 f7 d8 64 89 01 48 [4.382196] RSP: 002b:7ffe5fe76eb8 EFLAGS: 0246 ORIG_RAX: 0139 [4.382200] RAX: ffda RBX: 5615a81b2c10 RCX: 7fb64cd77fb9 [4.382202] RDX: RSI: 7fb64dd3c1c5 RDI: 000f [4.382204] RBP: R08: R09: [4.382206] R10: 000f R11: 0246 R12: 5615a81d0290 [4.382209] R13: 7fb64dd3c1c5 R14: 0002 R15: 03938700 And it won't load. -- 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: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
On Tue, Feb 05, 2019 at 05:32:16PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, February 5, 2019 10:02 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> >Syrjala, Ville
> >; Lankhorst, Maarten
> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
> >
> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
> >> Create a new connector property to program colorspace to sink devices.
> >> Modern sink devices support more than 1 type of colorspace like 601,
> >> 709, BT2020 etc. This helps to switch based on content type which is
> >> to be displayed. The decision lies with compositors as to in which
> >> scenarios, a particular colorspace will be picked.
> >>
> >> This will be helpful mostly to switch to higher gamut colorspaces like
> >> BT2020 when the media content is encoded as BT2020. Thereby giving a
> >> good visual experience to users.
> >>
> >> The expectation from userspace is that it should parse the EDID and
> >> get supported colorspaces. Use this property and switch to the one
> >> supported. Sink supported colorspaces should be retrieved by userspace
> >> from EDID and driver will not explicitly expose them.
> >>
> >> Basically the expectation from userspace is:
> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
> >>colorspace
> >> - Set this new property to let the sink know what it
> >>converted the CRTC output to.
> >>
> >> v2: Addressed Maarten and Ville's review comments. Enhanced the
> >> colorspace enum to incorporate both HDMI and DP supported colorspaces.
> >> Also, added a default option for colorspace.
> >>
> >> v3: Removed Adobe references from enum definitions as per Ville, Hans
> >> Verkuil and Jonas Karlman suggestions. Changed Default to an unset
> >> state where driver will assign the colorspace is not chosen by user,
> >> suggested by Ville and Maarten. Addressed other misc review comments
> >> from Maarten. Split the changes to have separate colorspace property
> >> for DP and HDMI.
> >>
> >> v4: Addressed Chris and Ville's review comments, and created a common
> >> colorspace property for DP and HDMI, filtered the list based on the
> >> colorspaces supported by the respective protocol standard.
> >>
> >> v5: Made the property creation helper accept enum list based on
> >> platform capabilties as suggested by Shashank. Consolidated HDMI and
> >> DP property creation in the common helper.
> >>
> >> v6: Addressed Shashank's review comments.
> >>
> >> v7: Added defines instead of enum in uapi as per Brian Starkey's
> >> suggestion in order to go with string matching at userspace. Updated
> >> the commit message to add more details as well kernel docs.
> >>
> >> v8: Addressed Maarten's review comments.
> >>
> >> v9: Removed macro defines from uapi as per Brian Starkey and Daniel
> >> Stone's comments and moved to drm include file. Moved back to older
> >> design with exposing all HDMI colorspaces to userspace since infoframe
> >> capability is there even on legacy platforms, as per Ville's review
> >> comments.
> >>
> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
> >>
> >> v11: Addressed Ville's review comments. Updated the Macro naming and
> >> added DCI-P3 colorspace as well defined in CEA 861.G spec.
> >>
> >> Signed-off-by: Uma Shankar
> >> Acked-by: Jani Nikula
> >> Reviewed-by: Shashank Sharma
> >> Reviewed-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
> >> drivers/gpu/drm/drm_connector.c | 78
> >+++
> >> include/drm/drm_connector.h | 50 +
> >> 3 files changed, 132 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 9a1f41a..9b5d44f 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >>return -EINVAL;
> >>}
> >>state->content_protection = val;
> >> + } else if (property == connector->colorspace_property) {
> >> + state->colorspace = val;
> >>} else if (property == config->writeback_fb_id_property) {
> >>struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
> >NULL, val);
> >>int ret = drm_atomic_set_writeback_fb_for_connector(state,
> >fb); @@
> >> -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
> >drm_connector *connector,
> >>*val = state->picture_aspect_ratio;
> >>} else if (property == config->content_type_property) {
> >>*val = state->content_type;
> >> + } else if (property == connector->colorspace_property) {
> >> + *val = state->colorspace;
> >>} else if (property == connector
Re: [PATCH 3/4] drm/sun4i: dsi: Add burst support
On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
wrote:
>
> From: Konstantin Sudakov
>
> The current driver doesn't support the DSI burst operation mode.
>
> Let's add the needed quirks to make it work.
>
> Signed-off-by: Konstantin Sudakov
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 178 +++---
> 1 file changed, 136 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> index e3e4ba90c059..6840b3512a45 100644
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -23,7 +23,9 @@
> #include
> #include
>
> +#include "sun4i_crtc.h"
> #include "sun4i_drv.h"
> +#include "sun4i_tcon.h"
> #include "sun6i_mipi_dsi.h"
>
> #include
> @@ -32,6 +34,8 @@
> #define SUN6I_DSI_CTL_EN BIT(0)
>
> #define SUN6I_DSI_BASIC_CTL_REG0x00c
> +#define SUN6I_DSI_BASIC_CTL_TRAIL_INV(n) (((n) & 0xf) << 4)
> +#define SUN6I_DSI_BASIC_CTL_TRAIL_FILL BIT(3)
> #define SUN6I_DSI_BASIC_CTL_HBP_DISBIT(2)
> #define SUN6I_DSI_BASIC_CTL_HSA_HSE_DISBIT(1)
> #define SUN6I_DSI_BASIC_CTL_VIDEO_BURSTBIT(0)
> @@ -152,6 +156,8 @@
>
> #define SUN6I_DSI_CMD_TX_REG(n)(0x300 + (n) * 0x04)
>
> +#define SUN6I_DSI_SYNC_POINT 40
> +
> enum sun6i_dsi_start_inst {
> DSI_START_LPRX,
> DSI_START_LPTX,
> @@ -365,31 +371,101 @@ static u16 sun6i_dsi_get_video_start_delay(struct
> sun6i_dsi *dsi,
> return delay;
> }
>
> +static u16 sun6i_dsi_get_line_num(struct sun6i_dsi *dsi,
> + struct drm_display_mode *mode)
> +{
> + struct mipi_dsi_device *device = dsi->device;
> + unsigned Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
> +
> + return mode->htotal * Bpp / device->lanes;
> +}
> +
> +static u16 sun6i_dsi_get_drq_edge0(struct sun6i_dsi *dsi,
> + struct drm_display_mode *mode,
> + u16 line_num, u16 edge1)
> +{
> + u16 edge0 = edge1;
> +
> + edge0 += (mode->hdisplay + 40) * SUN6I_DSI_TCON_DIV / 8;
> +
> + if (edge0 > line_num)
> + return edge0 - line_num;
> +
> + return 1;
> +}
> +
> +static u16 sun6i_dsi_get_drq_edge1(struct sun6i_dsi *dsi,
> + struct drm_display_mode *mode,
> + u16 line_num)
> +{
> + struct mipi_dsi_device *device = dsi->device;
> + unsigned Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
> + unsigned hbp = mode->htotal - mode->hsync_end;
Allwinner's hbp is actually horizontal back porch plus sync pulse.
So this should be
hbp = mode->htotal - mode->hsync_start;
> + u16 edge1;
> +
> +
> + edge1 = SUN6I_DSI_SYNC_POINT;
> + edge1 += mode->hdisplay + hbp + 20;
> + edge1 = edge1 * Bpp / device->lanes;
Compared to the A64 BSP, this seems to be incorrect. The original code was
edge1 = sync_point +
(panel->lcd_x + panel->lcd_hbp + 20) *
dsi_pixel_bits[panel->lcd_dsi_format] /
(8 * panel->lcd_dsi_lane);
Note that sync_point is outside of the parentheses and should not be
multiplied and divided.
This would make sense if sync_point is a fixed delay that is needed
regardless of the timings.
> +
> + if (edge1 > line_num)
> + return line_num;
> +
> + return edge1;
> +}
> +
> static void sun6i_dsi_setup_burst(struct sun6i_dsi *dsi,
> struct drm_display_mode *mode)
> {
> struct mipi_dsi_device *device = dsi->device;
> - u32 val = 0;
> + u32 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> + u32 tcon0_drq = 0;
> +
> + if (device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) {
> + u16 line_num = sun6i_dsi_get_line_num(dsi, mode);
> + u16 edge0, edge1;
> +
> + edge1 = sun6i_dsi_get_drq_edge1(dsi, mode, line_num);
> + edge0 = sun6i_dsi_get_drq_edge0(dsi, mode, line_num, edge1);
>
> - if ((mode->hsync_end - mode->hdisplay) > 20) {
> + regmap_write(dsi->regs, SUN6I_DSI_BURST_DRQ_REG,
> +SUN6I_DSI_BURST_DRQ_EDGE0(edge0) |
> +SUN6I_DSI_BURST_DRQ_EDGE1(edge1));
> +
> + regmap_write(dsi->regs, SUN6I_DSI_BURST_LINE_REG,
> +SUN6I_DSI_BURST_LINE_NUM(line_num) |
> +
> SUN6I_DSI_BURST_LINE_SYNC_POINT(SUN6I_DSI_SYNC_POINT));
> +
> + tcon0_drq = SUN6I_DSI_TCON_DRQ_ENABLE_MODE;
> + } else if ((mode->hsync_end - mode->hdisplay) > 20) {
> /* Maagic */
> u16 drq = (mode->hsync_end - mode->hdisplay) - 20;
This and the above if clause should use hsync_start ins
Re: [PATCH] component: Add documentation
On Tue, Feb 05, 2019 at 04:49:02PM +, Russell King - ARM Linux admin wrote:
> On Tue, Feb 05, 2019 at 05:21:07PM +0100, Daniel Vetter wrote:
> > Someone owes me a beer ...
>
> I find that deeply offensive - it is clearly directed at me personally
> as author of the component helper.
>
> There are double-standards in the kernel ecosystem with respect to
> documentation - there are entire subsystems way more complicated than
> the component *helper* which are lacking in documentation, and the
> subsystem authors response to requests to change that basically get
> ignored, or the response is "write the documentation yourself".
>
> Why does there seem to be one rule for me and one rule for everyone
> else?
>
> Please remove this line.
Will do, but wasn't aimed at you at all, but at Greg for asking for the
documentation. But yeah that wasn't clear at all, my apologies.
Will apply all your suggestions except for the ones I'm commenting on here
in my reply.
[snip]
> > +/**
> > + * component_master_add_with_match - register an aggregate driver
> > + * @dev: device with the aggregate driver
> > + * @ops: callbacks for the aggregate driver
> > + * @match: component match list for the aggregate driver
> > + *
> > + * Registers a new aggregate driver consisting of the components added to
> > @match
> > + * by calling one of the component_match_add() functions. Once all
> > components in
>
> As there is a function called component_match_add(), this doesn't
> make too much sense as it directs people only to that function. It
> would be better to mention both here. (Have you checked how it comes
> out as a HTML document with the hyperlinks?)
component_match_add() creates a link to the kerneldoc for the
component_match_add. There I've added some text to point to all the other
variants of this family of functions. Same for all the other variants,
those should all have links to the others.
[snip]
> > +/**
> > + * struct component_master_ops - callback for the aggregate driver
> > + *
> > + * Aggregate drivers are registered with component_master_add_with_match()
> > and
> > + * unregistered with component_master_del().
> > + */
> > struct component_master_ops {
> > + /**
> > +* @bind:
> > +*
> > +* Called when all components or the aggregate driver, as specified in
> > +* the match list passed to component_master_add_with_match(), are
> > +* ready. Usually there are 3 steps to bind an aggregate driver:
> > +*
> > +* 1. Allocate a structure for the aggregate driver.
> > +*
> > +* 2. Bind all components to the aggregate driver by calling
> > +*component_bind_all() with the aggregate driver structure as opaque
> > +*pointer data.
>
> These two aren't part of the component helper specification, although
> nailing down what is passed per subsystem would be a good idea to allow
> components to be re-used within the subsystem. For DRM, it should be
> the struct drm_device.
Hm, great point. I have no idea where we should put it so people find
this. Definitely not here, since this isn't drivers/gpu. I think adding a
small section to the driver initialization docs we already have would make
sense.
I'll add another patch for that in this series, with this one here that
drm paragraph will even have somewhere meaningful to point to!
Thanks for your review.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, February 5, 2019 11:43 PM
>To: Shankar, Uma
>Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ;
>Lankhorst, Maarten ; dri-
>de...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>
>On Tue, Feb 05, 2019 at 05:32:16PM +, Shankar, Uma wrote:
>>
>>
>> >-Original Message-
>> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>> >Sent: Tuesday, February 5, 2019 10:02 PM
>> >To: Shankar, Uma
>> >Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> >Syrjala, Ville ; Lankhorst, Maarten
>> >
>> >Subject: Re: [Intel-gfx] [v11 1/4] drm: Add HDMI colorspace property
>> >
>> >On Tue, Feb 05, 2019 at 09:33:34PM +0530, Uma Shankar wrote:
>> >> Create a new connector property to program colorspace to sink devices.
>> >> Modern sink devices support more than 1 type of colorspace like
>> >> 601, 709, BT2020 etc. This helps to switch based on content type
>> >> which is to be displayed. The decision lies with compositors as to
>> >> in which scenarios, a particular colorspace will be picked.
>> >>
>> >> This will be helpful mostly to switch to higher gamut colorspaces
>> >> like
>> >> BT2020 when the media content is encoded as BT2020. Thereby giving
>> >> a good visual experience to users.
>> >>
>> >> The expectation from userspace is that it should parse the EDID and
>> >> get supported colorspaces. Use this property and switch to the one
>> >> supported. Sink supported colorspaces should be retrieved by
>> >> userspace from EDID and driver will not explicitly expose them.
>> >>
>> >> Basically the expectation from userspace is:
>> >> - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
>> >>colorspace
>> >> - Set this new property to let the sink know what it
>> >>converted the CRTC output to.
>> >>
>> >> v2: Addressed Maarten and Ville's review comments. Enhanced the
>> >> colorspace enum to incorporate both HDMI and DP supported colorspaces.
>> >> Also, added a default option for colorspace.
>> >>
>> >> v3: Removed Adobe references from enum definitions as per Ville,
>> >> Hans Verkuil and Jonas Karlman suggestions. Changed Default to an
>> >> unset state where driver will assign the colorspace is not chosen
>> >> by user, suggested by Ville and Maarten. Addressed other misc
>> >> review comments from Maarten. Split the changes to have separate
>> >> colorspace property for DP and HDMI.
>> >>
>> >> v4: Addressed Chris and Ville's review comments, and created a
>> >> common colorspace property for DP and HDMI, filtered the list based
>> >> on the colorspaces supported by the respective protocol standard.
>> >>
>> >> v5: Made the property creation helper accept enum list based on
>> >> platform capabilties as suggested by Shashank. Consolidated HDMI
>> >> and DP property creation in the common helper.
>> >>
>> >> v6: Addressed Shashank's review comments.
>> >>
>> >> v7: Added defines instead of enum in uapi as per Brian Starkey's
>> >> suggestion in order to go with string matching at userspace.
>> >> Updated the commit message to add more details as well kernel docs.
>> >>
>> >> v8: Addressed Maarten's review comments.
>> >>
>> >> v9: Removed macro defines from uapi as per Brian Starkey and Daniel
>> >> Stone's comments and moved to drm include file. Moved back to older
>> >> design with exposing all HDMI colorspaces to userspace since
>> >> infoframe capability is there even on legacy platforms, as per
>> >> Ville's review comments.
>> >>
>> >> v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
>> >>
>> >> v11: Addressed Ville's review comments. Updated the Macro naming
>> >> and added DCI-P3 colorspace as well defined in CEA 861.G spec.
>> >>
>> >> Signed-off-by: Uma Shankar
>> >> Acked-by: Jani Nikula
>> >> Reviewed-by: Shashank Sharma
>> >> Reviewed-by: Maarten Lankhorst
>> >> ---
>> >> drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
>> >> drivers/gpu/drm/drm_connector.c | 78
>> >+++
>> >> include/drm/drm_connector.h | 50 +
>> >> 3 files changed, 132 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> index 9a1f41a..9b5d44f 100644
>> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> >> @@ -746,6 +746,8 @@ static int
>> >> drm_atomic_connector_set_property(struct
>> >drm_connector *connector,
>> >> return -EINVAL;
>> >> }
>> >> state->content_protection = val;
>> >> + } else if (property == connector->colorspace_property) {
>> >> + state->colorspace = val;
>> >> } else if (property == config->writeback_fb_id_property) {
>> >> struct drm_framebuffer *fb = drm_framebuffer_lookup(dev,
>> >NULL, val);
>> >> int ret = dr
Re: [PATCH] drm/dsc: Add kernel documentation for DRM DP DSC helpers
On Mon, Feb 04, 2019 at 03:40:22PM -0800, Manasi Navare wrote:
> This patch adds appropiate kernel documentation for DRM DP helpers
> used for enabling Display Stream compression functionality in
> drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> related structure definitions and helpers in drm_dsc.c and drm_dsc.h
> Also add links between the functions and structures in the documentation.
>
> Suggested-by: Daniel Vetter
> Suggested-by: Sean Paul
> Cc: Daniel Vetter
> Cc: Sean Paul
> Signed-off-by: Manasi Navare
Build warnings are gone with this, so once Daniel's suggestions are
incorporated:
Acked-by: Sean Paul
> ---
> drivers/gpu/drm/drm_dp_helper.c | 42 +-
> drivers/gpu/drm/drm_dsc.c | 13 ++-
> include/drm/drm_dp_helper.h | 15 +++-
> include/drm/drm_dsc.h | 138 ++--
> 4 files changed, 142 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 54120b6319e7..e9e0233f5b2f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1360,7 +1360,20 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
> drm_dp_desc *desc,
> EXPORT_SYMBOL(drm_dp_read_desc);
>
> /**
> - * DRM DP Helpers for DSC
> + * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
> + * supported by the DSC sink.
> + * @dsc_dpcd: DSC capabilities from DPCD
> + * @is_edp: true if its eDP, false for DP
> + *
> + * Read the slice capabilities DPCD register from DSC sink to get
> + * the maximum slice count supported. This is used to populate
> + * the DSC parameters in the &struct drm_dsc_config by the driver.
> + * Driver creates an infoframe using these parameters to populate
> + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> + *
> + * Returns:
> + * Maximum slice count supported by DSC sink or 0 its invalid
> */
> u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> bool is_edp)
> @@ -1405,6 +1418,19 @@ u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_max_slice_count);
>
> +/**
> + * drm_dp_dsc_sink_line_buf_depth() - Get the line buffer depth in bits
> which is
> + * number of bits of precision within the decoder line buffer supported by
> + * the DSC sink. This is used to populate the DSC parameters in the
> + * &struct drm_dsc_config by the driver.
> + * Driver creates an infoframe using these parameters to populate
> + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> + * @dsc_dpcd: DSC capabilities from DPCD
> + *
> + * Returns:
> + * Line buffer depth supported by DSC panel or 0 its invalid
> + */
> u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> {
> u8 line_buf_depth = dsc_dpcd[DP_DSC_LINE_BUF_BIT_DEPTH -
> DP_DSC_SUPPORT];
> @@ -1434,6 +1460,20 @@ u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> }
> EXPORT_SYMBOL(drm_dp_dsc_sink_line_buf_depth);
>
> +/**
> + * drm_dp_dsc_sink_supported_input_bpcs() - Get all the input bits per
> component
> + * values supported by the DSC sink. This is used to populate the DSC
> parameters
> + * in the &struct drm_dsc_config by the driver.
> + * Driver creates an infoframe using these parameters to populate
> + * &struct drm_dsc_pps_infoframe. These are sent to the sink using DSC
> + * infoframe using the helper function drm_dsc_pps_infoframe_pack()
> + * @dsc_dpcd: DSC capabilities from DPCD
> + * @dsc_bpc: An array to be filled by this helper with supported
> + * input bpcs.
> + *
> + * Returns:
> + * Number of input BPC values parsed from the DPCD
> + */
> int drm_dp_dsc_sink_supported_input_bpcs(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>u8 dsc_bpc[3])
> {
> diff --git a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c
> index bc2b23adb072..0fd56fbdf9b4 100644
> --- a/drivers/gpu/drm/drm_dsc.c
> +++ b/drivers/gpu/drm/drm_dsc.c
> @@ -17,6 +17,12 @@
> /**
> * DOC: dsc helpers
> *
> + * VESA specification for DP 1.4 adds a new feature called Display Stream
> + * Compression (DSC) used to compress the pixel bits before sending it on
> + * DP/eDP/MIPI DSI interface. DSC is required to be enabled so that the
> existing
> + * display interfaces can support high resolutions at higher frames rates
> uisng
> + * the maximum available link capacity of these interfaces.
> + *
> * These functions contain some common logic and helpers to deal with VESA
> * Display Stream Compression standard required for DSC on Display Port/eDP
> or
> * MIPI display interfaces.
> @@ -26,6 +32,7 @@
> * drm_dsc_dp_pps_header_init() - Init
Re: [PATCH] drm/doc: Make igts for cross-driver stuff strongly suggested
On Mon, Jan 28, 2019 at 12:23 PM Daniel Vetter wrote: > > Compared to the RFC[1] no changes to the patch itself, but igt moved > forward a lot: > > - gitlab CI builds with: reduced configs/libraries, arm cross build > and a sysroot build (should address all the build/cross platform > concerns raised in the RFC discussions). > > - tests reorganized into subdirectories so that the i915-gem tests > don't clog the main/shared tests directory anymore > > - quite a few more non-intel people contributing/reviewing/committing > igt tests patches. > > I think this addresses all the concerns raised in the RFC discussions, > and assuming there's enough Acks and no new issues that pop up, we can > go ahead with this. > > v2: > - Use "should" (in the usual RFC sense) to make it clear that in the > end this is all up to reviewer's discretion, as usual (Jani). > - Also in the title s/mandatory/strongly suggested/ (me) > - Make it clear we're not going to block features if a testcase is not > feasible, given hw and state of igt, both having some good gaps in > what can be tested (Harry, Eric, Sean, ...). > > 1: https://patchwork.kernel.org/patch/10648851/ > Cc: Petri Latvala > Cc: Arkadiusz Hiler > Cc: Liviu Dudau > Cc: Sean Paul > Cc: Eric Anholt > Cc: Alex Deucher > Cc: Dave Airlie > Cc: Daniel Stone > Cc: "Wentland, Harry" > Cc: Brian Starkey > Reviewed-by: Eric Anholt (v1) > Acked-by: Petri Latvala > Acked-by: Arkadiusz Hiler > Acked-by: Sean Paul > Acked-by: "Wentland, Harry" > Signed-off-by: Daniel Vetter Acked-by: Alex Deucher > --- > Documentation/gpu/drm-uapi.rst | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index a752aa561ea4..c9fd23efd957 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -238,6 +238,14 @@ DRM specific patterns. Note that ENOTTY has the slightly > unintuitive meaning of > Testing and validation > == > > +Testing Requirements for userspace API > +-- > + > +New cross-driver userspace interface extensions, like new IOCTL, new KMS > +properties, new files in sysfs or anything else that constitutes an API > change > +should have driver-agnostic testcases in IGT for that feature, if such a test > +can be reasonably made using IGT for the target hardware. > + > Validating changes with IGT > --- > > -- > 2.20.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/msm: dpu: Don't set frame_busy_mask for async updates
On Wed, Jan 30, 2019 at 8:32 AM Sean Paul wrote: > > From: Sean Paul > > The frame_busy mask is used in frame_done event handling, which is not > invoked for async commits. So an async commit will leave the > frame_busy mask populated after it completes and future commits will start > with the busy mask incorrect. > > This showed up on disable after cursor move. I was hitting the "this should > not happen" comment in the frame event worker since frame_busy was set, > we queued the event, but there were no frames pending (since async > also doesn't set that). > > Signed-off-by: Sean Paul > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > index 36158b7d99cd..1a81c4daabc9 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c > @@ -1558,8 +1558,14 @@ static void _dpu_encoder_kickoff_phys(struct > dpu_encoder_virt *dpu_enc, > if (!ctl) > continue; > > - if (phys->split_role != ENC_ROLE_SLAVE) > + /* > +* This is cleared in frame_done worker, which isn't invoked > +* for async commits. So don't set this for async, since it'll > +* roll over to the next commit. > +*/ > + if (!async && phys->split_role != ENC_ROLE_SLAVE) > set_bit(i, dpu_enc->frame_busy_mask); > + > if (!phys->ops.needs_single_flush || > !phys->ops.needs_single_flush(phys)) > _dpu_encoder_trigger_flush(&dpu_enc->base, phys, 0x0, > -- > Sean Paul, Software Engineer, Google / Chromium OS > Reviewed-by: Fritz Koenig > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] drm/msm: dpu: Don't queue the frame_done watchdog for cursor
On Mon, Jan 28, 2019 at 12:43 PM Sean Paul wrote:
>
> From: Sean Paul
>
> In the case of an async/cursor update, we don't wait for the frame_done
> event, which means handle_frame_done is never called, and the frame_done
> watchdog isn't canceled. Currently, this results in a frame_done timeout
> every time the cursor moves without a synchronous frame following it up
> before the timeout expires. Since we don't wait for frame_done, and
> don't handle it, we shouldn't modify the watchdog.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 51e46b206c73e..05145cf9fb408 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -1794,7 +1794,6 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
> bool async)
> {
> struct dpu_encoder_virt *dpu_enc;
> struct dpu_encoder_phys *phys;
> - unsigned long timeout_ms;
> ktime_t wakeup_time;
> unsigned int i;
>
> @@ -1807,12 +1806,20 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
> bool async)
>
> trace_dpu_enc_kickoff(DRMID(drm_enc));
>
> - timeout_ms = DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES * 1000 /
> - drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
> + /*
> +* Asynchronous frames don't handle FRAME_DONE events. As such, they
> +* shouldn't enable the frame_done watchdog since it will always time
> +* out.
> +*/
> + if (!async) {
> + unsigned long timeout_ms;
> + timeout_ms = DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES * 1000 /
> +
> drm_mode_vrefresh(&drm_enc->crtc->state->adjusted_mode);
>
> - atomic_set(&dpu_enc->frame_done_timeout_ms, timeout_ms);
> - mod_timer(&dpu_enc->frame_done_timer,
> - jiffies + msecs_to_jiffies(timeout_ms));
> + atomic_set(&dpu_enc->frame_done_timeout_ms, timeout_ms);
> + mod_timer(&dpu_enc->frame_done_timer,
> + jiffies + msecs_to_jiffies(timeout_ms));
> + }
>
> /* All phys encs are ready to go, trigger the kickoff */
> _dpu_encoder_kickoff_phys(dpu_enc, async);
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
Reviewed-by: Fritz Koenig
> ___
> 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
[v13 4/4] drm/i915: Attach colorspace property and enable modeset
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.
This patch attaches and enables HDMI colorspace, DP will be
taken care separately.
v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.
v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed a checkpatch complaint, Addressed Maarten' review
comment, updated the RB from Maarten and Jani's ack.
v8: Moved colorspace AVI Infoframe programming to drm core and
removed from driver as per Ville's suggestion.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c| 1 +
drivers/gpu/drm/i915/intel_connector.c | 8
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdmi.c | 13 +
4 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..a4bb906 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct
drm_connector *conn,
*/
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
+ new_conn_state->base.colorspace != old_conn_state->base.colorspace
||
new_conn_state->base.picture_aspect_ratio !=
old_conn_state->base.picture_aspect_ratio ||
new_conn_state->base.content_type !=
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode !=
old_conn_state->base.scaling_mode)
diff --git a/drivers/gpu/drm/i915/intel_connector.c
b/drivers/gpu/drm/i915/intel_connector.c
index ee16758..8352d0b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -265,3 +265,11 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
}
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+ if (!drm_mode_create_colorspace_property(connector))
+ drm_object_attach_property(&connector->base,
+ connector->colorspace_property, 0);
+}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 90ba543..ff0a24a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1785,6 +1785,7 @@ int intel_connector_update_modes(struct drm_connector
*connector,
void intel_attach_force_audio_property(struct drm_connector *connector);
void intel_attach_broadcast_rgb_property(struct drm_connector *connector);
void intel_attach_aspect_ratio_property(struct drm_connector *connector);
+void intel_attach_colorspace_property(struct drm_connector *connector);
/* intel_csr.c */
void intel_csr_ucode_init(struct drm_i915_private *);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 97a98e1..0b5e483 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -498,6 +498,8 @@ static void intel_hdmi_set_avi_infoframe(struct
intel_encoder *encoder,
else
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
+ drm_hdmi_avi_infoframe_colorspace(&frame.avi, conn_state);
+
drm_hdmi_avi_infoframe_quant_range(&frame.avi,
conn_state->connector,
adjusted_mode,
@@ -2143,10 +2145,21 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
+ struct intel_digital_port *intel_dig_port =
+ hdmi_to_dig_port(intel_hdmi);
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
+
+ /*
+
[v13 0/4] Add Colorspace connector property interface
This patch series creates a new connector property to program colorspace to sink devices. Modern sink devices support more than 1 type of colorspace like 601, 709, BT2020 etc. This helps to switch based on content type which is to be displayed. The decision lies with compositors as to in which scenarios, a particular colorspace will be picked. This will be helpful mostly to switch to higher gamut colorspaces like BT2020 when the media content is encoded as BT2020. Thereby giving a good visual experience to users. The expectation from userspace is that it should parse the EDID and get supported colorspaces. Use this property and switch to the one supported. Sink supported colorspaces should be retrieved by userspace from EDID and driver will not explicitly expose them. Basically the expectation from userspace is: - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink colorspace - Set this new property to let the sink know what it converted the CRTC output to. - This property is just to inform sink what colorspace source is trying to drive. Have tested this using xrandr by using below command: xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb" v2: Addressed Ville and Maarten's review comments. Merged the 2nd and 3rd patch into one common logical patch. v3: Removed Adobe references from enum definitions as per Ville, Hans Verkuil and Jonas Karlman suggestions. Changed default to an unset state where driver will assign the colorspace when not chosen by user, suggested by Ville and Maarten. Addressed other misc review comments from Maarten. Split the changes to have separate colorspace property for DP and HDMI. v4: Addressed Chris and Ville's review comments, and created a common colorspace property for DP and HDMI, filtered the list v5: Modified the colorspace property creation helper to take platform specific enum list based on the capabilities of the platform as suggested by Shashank. With this there is no need for segregation between DP and HDMI. v6: Addressed Shashank's review comments. v7: Added defines instead of enum in uapi as per Brian Starkey's suggestion in order to go with string matching at userspace. Updated the kernel doc as well with more details. v8: Addressed Maarten's review comments. v9: Removed macro defines from uapi as per Brian Starkey and Daniel Stone's comments and moved to drm include file. Moved back to older design with exposing all HDMI colorspaces to userspace since infoframe capability is there even on legacy platforms, as per Ville's review comments. v10: Addressed Maarten' review comment, updated the RB from Maarten and Jani Nikula's ack. Also fixed sparse warnings and checkpatch complaints. v11: Addressed Ville's review comments. Modified MACRO names, added infoframe helper for colorspace to drm layer. Added DCI-P3 colorspace macro definitions defined in CTA 861.G. Currently linux/hdmi lacks support for ACE formats, will be added as a separate series. v12: Exported the helper API. v13: As per Ville's suggestion, added separate CTA 861.G spec defined HDMI specific macros. This is separate from user exposed enum values. Fixed some macro naming inconsistencies. Uma Shankar (4): drm: Add HDMI colorspace property drm: Add DP colorspace property drm: Add colorspace info to AVI Infoframe drm/i915: Attach colorspace property and enable modeset drivers/gpu/drm/drm_atomic_uapi.c | 4 ++ drivers/gpu/drm/drm_connector.c| 104 + drivers/gpu/drm/drm_edid.c | 57 ++ drivers/gpu/drm/i915/intel_atomic.c| 1 + drivers/gpu/drm/i915/intel_connector.c | 8 +++ drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 13 + include/drm/drm_connector.h| 69 ++ include/drm/drm_edid.h | 6 ++ 9 files changed, 263 insertions(+) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v13 2/4] drm: Add DP colorspace property
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Split the changes to have separate colorspace property for
DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Merged the DP handling along with platform colorspace
handling as per Shashank's comments.
v6: Reverted to old design of exposing all colorspaces to
userspace as per Ville's review comment
v7: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v8: Addressed Ville's review comments and updated the colorspace
macro definitions.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_connector.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2b5d468..d6ca3d9 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -853,6 +853,24 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
+ /* High Definition Colorimetry based on IEC 61966-2-4 */
+ { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
+ /* Colorimetry based on IEC 61966-2-5 */
+ { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
+ { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
+ /* DP MSA Colorimetry */
+ { DRM_MODE_DP_COLORIMETRY_BT601_YCC, "BT601_YCC" },
+ { DRM_MODE_DP_COLORIMETRY_BT709_YCC, "BT709_YCC" },
+ { DRM_MODE_DP_COLORIMETRY_SRGB, "sRGB" },
+ { DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT, "RGB Wide Gamut" },
+ { DRM_MODE_DP_COLORIMETRY_SCRGB, "scRGB" },
+};
+
/**
* DOC: standard connector properties
*
@@ -1614,6 +1632,14 @@ int drm_mode_create_colorspace_property(struct
drm_connector *connector)
ARRAY_SIZE(hdmi_colorspaces));
if (!prop)
return -ENOMEM;
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_eDP ||
+ connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
{
+ prop = drm_property_create_enum(dev, DRM_MODE_PROP_ENUM,
+ "Colorspace", dp_colorspaces,
+ ARRAY_SIZE(dp_colorspaces));
+
+ if (!prop)
+ return -ENOMEM;
} else {
DRM_DEBUG_KMS("Colorspace property not supported\n");
return 0;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[v13 1/4] drm: Add HDMI colorspace property
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
colorspace will be picked.
This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.
The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Sink supported colorspaces should be retrieved by
userspace from EDID and driver will not explicitly expose them.
Basically the expectation from userspace is:
- Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
colorspace
- Set this new property to let the sink know what it
converted the CRTC output to.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.
v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.
v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.
v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.
v6: Addressed Shashank's review comments.
v7: Added defines instead of enum in uapi as per Brian Starkey's
suggestion in order to go with string matching at userspace. Updated
the commit message to add more details as well kernel docs.
v8: Addressed Maarten's review comments.
v9: Removed macro defines from uapi as per Brian Starkey and Daniel
Stone's comments and moved to drm include file. Moved back to older
design with exposing all HDMI colorspaces to userspace since infoframe
capability is there even on legacy platforms, as per Ville's review
comments.
v10: Fixed sparse warnings, updated the RB from Maarten and Jani's ack.
v11: Addressed Ville's review comments. Updated the Macro naming and
added DCI-P3 colorspace as well, defined in CTA 861.G spec.
Signed-off-by: Uma Shankar
Acked-by: Jani Nikula
Reviewed-by: Shashank Sharma
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 ++
drivers/gpu/drm/drm_connector.c | 78 +++
include/drm/drm_connector.h | 49
3 files changed, 131 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0aabd40..4eb81f1 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == connector->colorspace_property) {
+ state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL,
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+ } else if (property == connector->colorspace_property) {
+ *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dd40eff..2b5d468 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,33 @@ int drm_display_info_set_bus_formats(struct
drm_display_info *info,
};
DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+ /* For Default case, driver will set the colorspace */
+ { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
+ /* Standard Definition Colorimetry based on CEA 861 */
+ { DRM_MODE_COLORIMETRY_SMPTE_170M, "SMPTE_170M" },
+ { DRM_MODE_COLORIMETRY_BT709, "BT709" },
+ /* Sta
[v13 3/4] drm: Add colorspace info to AVI Infoframe
This adds colorspace information to HDMI AVI infoframe.
A helper function is added to program the same.
v2: Moved this to drm core instead of i915 driver.
v3: Exported the helper function.
v4: Added separate HDMI specific macro as per CTA spec.
This is separate from user exposed enum values. This is
as per Ville's suggestion.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_edid.c | 57 +
include/drm/drm_connector.h | 20
include/drm/drm_edid.h | 6 +
3 files changed, 83 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 990b190..7062e37 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4925,6 +4925,63 @@ static bool is_hdmi2_sink(struct drm_connector
*connector)
EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
/**
+ * drm_hdmi_avi_infoframe_colorspace() - fill the HDMI AVI infoframe
+ * colorspace information
+ * @frame: HDMI AVI infoframe
+ * @conn_state: connector state
+ */
+void
+drm_hdmi_avi_infoframe_colorspace(struct hdmi_avi_infoframe *frame,
+ const struct drm_connector_state *conn_state)
+{
+ u32 colorimetry_val = conn_state->colorspace &
+ FULL_COLORIMETRY_MASK;
+
+ switch (colorimetry_val) {
+ case DRM_MODE_COLORIMETRY_NO_DATA:
+ colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
+ break;
+ case HDMI_COLORIMETRY_SMPTE_170M:
+ colorimetry_val = HDMI_COLORIMETRY_SMPTE_170M;
+ break;
+ case DRM_MODE_COLORIMETRY_BT709:
+ colorimetry_val = HDMI_COLORIMETRY_BT709;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_601:
+ colorimetry_val = HDMI_COLORIMETRY_XVYCC_601;
+ break;
+ case DRM_MODE_COLORIMETRY_XVYCC_709:
+ colorimetry_val = HDMI_COLORIMETRY_XVYCC_709;
+ break;
+ case DRM_MODE_COLORIMETRY_SYCC_601:
+ colorimetry_val = HDMI_COLORIMETRY_SYCC_601;
+ break;
+ case DRM_MODE_COLORIMETRY_OPYCC_601:
+ colorimetry_val = HDMI_COLORIMETRY_OPYCC_601;
+ break;
+ case DRM_MODE_COLORIMETRY_OPRGB:
+ colorimetry_val = HDMI_COLORIMETRY_OPRGB;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_RGB:
+ case DRM_MODE_COLORIMETRY_BT2020_YCC:
+ colorimetry_val = HDMI_COLORIMETRY_BT2020_RGB;
+ break;
+ case DRM_MODE_COLORIMETRY_BT2020_CYCC:
+ colorimetry_val = HDMI_COLORIMETRY_BT2020_CYCC;
+ break;
+ default:
+ /* ToDo: DCI-P3 will be handled as part of ACE enabling */
+ colorimetry_val = HDMI_COLORIMETRY_NO_DATA;
+ break;
+ }
+
+ frame->colorimetry = colorimetry_val & NORMAL_COLORIMETRY_MASK;
+ frame->extended_colorimetry = (colorimetry_val >> 2) &
+ EXTENDED_COLORIMETRY_MASK;
+}
+EXPORT_SYMBOL(drm_hdmi_avi_infoframe_colorspace);
+
+/**
* drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
*quantization range information
* @frame: HDMI AVI infoframe
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 37d4dda..7b8062c 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -288,6 +288,26 @@ enum drm_panel_orientation {
#define DRM_MODE_DP_COLORIMETRY_RGB_WIDE_GAMUT 16
#define DRM_MODE_DP_COLORIMETRY_SCRGB 17
+/* HDMI Colorspace Spec Definitions */
+#define FULL_COLORIMETRY_MASK 0x1FF
+#define NORMAL_COLORIMETRY_MASK0x3
+#define EXTENDED_COLORIMETRY_MASK 0x7
+#define EXTENDED_ACE_COLORIMETRY_MASK 0xF
+
+#define HDMI_COLORIMETRY_NO_DATA 0x0
+#define HDMI_COLORIMETRY_SMPTE_170M0x1
+#define HDMI_COLORIMETRY_BT709 0x2
+#define HDMI_COLORIMETRY_XVYCC_601 0x3
+#define HDMI_COLORIMETRY_XVYCC_709 0x7
+#define HDMI_COLORIMETRY_SYCC_601 0xB
+#define HDMI_COLORIMETRY_OPYCC_601 0xF
+#define HDMI_COLORIMETRY_OPRGB 0x13
+#define HDMI_COLORIMETRY_BT2020_CYCC 0x17
+#define HDMI_COLORIMETRY_BT2020_RGB0x1C
+#define HDMI_COLORIMETRY_BT2020_YCC0x1C
+#define HDMI_COLORIMETRY_DCI_P3_RGB_D650x1F
+#define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER0x3F
+
/**
* struct drm_display_info - runtime data about the connected sink
*
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 8dc1a08..9d3b5b9 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
Re: [PATCH 3/4] drm/msm: dpu: Untangle frame_done timeout units
On Mon, Jan 28, 2019 at 12:43 PM Sean Paul wrote:
>
> From: Sean Paul
>
> There exists a bunch of confusion as to what the actual units of
> frame_done is:
>
> - The definition states it's in # of frames
> - CRTC treats it like it's ms
> - frame_done_timeout comment thinks it's Hz, but it stores ms
> - frame_done timer is setup such that it _should_ be in frames, but the
> timeout is super long
>
> So this patch tries to interpret what the driver really wants. I've
> de-centralized the #define since the consumers are expecting different
> units.
>
> For crtc, we just use 60ms since that's what it was doing before.
> Perhaps we could get fancy and scale with vrefresh, but that's for
> another time.
>
> For encoder, fix the comments and rename frame_done_timeout so it's
> obvious what the units are. In practice, frame_done_timeout is really
> just checked against 0 || !0, which I guess is why the units being wrong
> didn't matter. I've also dropped the timeout from the previous 60 frames
> to 5. That seems like more than enough time to give up on a frame, and
> my guess is that no one intended for the timeout to _actually_ be 60
> frames.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 5 -
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 19 +++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 3 ---
> 3 files changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 4e4b64821c9e8..b0b394af2a7ef 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -46,6 +46,9 @@
> #define LEFT_MIXER 0
> #define RIGHT_MIXER 1
>
> +/* timeout in ms waiting for frame done */
> +#define DPU_CRTC_FRAME_DONE_TIMEOUT_MS 60
> +
> static struct dpu_kms *_dpu_crtc_get_kms(struct drm_crtc *crtc)
> {
> struct msm_drm_private *priv = crtc->dev->dev_private;
> @@ -683,7 +686,7 @@ static int _dpu_crtc_wait_for_frame_done(struct drm_crtc
> *crtc)
>
> DPU_ATRACE_BEGIN("frame done completion wait");
> ret = wait_for_completion_timeout(&dpu_crtc->frame_done_comp,
> - msecs_to_jiffies(DPU_FRAME_DONE_TIMEOUT));
> + msecs_to_jiffies(DPU_CRTC_FRAME_DONE_TIMEOUT_MS));
> if (!ret) {
> DRM_ERROR("frame done wait timed out, ret:%d\n", ret);
> rc = -ETIMEDOUT;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 83a4c47dbed2d..51e46b206c73e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -69,6 +69,9 @@
>
> #define MAX_VDISPLAY_SPLIT 1080
>
> +/* timeout in frames waiting for frame done */
> +#define DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES 5
> +
> /**
> * enum dpu_enc_rc_events - events for resource control state machine
> * @DPU_ENC_RC_EVENT_KICKOFF:
> @@ -158,7 +161,7 @@ enum dpu_enc_rc_states {
> * Bit0 = phys_encs[0] etc.
> * @crtc_frame_event_cb: callback handler for frame event
> * @crtc_frame_event_cb_data: callback handler private data
> - * @frame_done_timeout:frame done timeout in Hz
> + * @frame_done_timeout_ms: frame done timeout in ms
> * @frame_done_timer: watchdog timer for frame done event
> * @vsync_event_timer: vsync timer
> * @disp_info: local copy of msm_display_info struct
> @@ -196,7 +199,7 @@ struct dpu_encoder_virt {
> void (*crtc_frame_event_cb)(void *, u32 event);
> void *crtc_frame_event_cb_data;
>
> - atomic_t frame_done_timeout;
> + atomic_t frame_done_timeout_ms;
> struct timer_list frame_done_timer;
> struct timer_list vsync_event_timer;
>
> @@ -1184,7 +1187,7 @@ static void dpu_encoder_virt_disable(struct drm_encoder
> *drm_enc)
> }
>
> /* after phys waits for frame-done, should be no more frames pending
> */
> - if (atomic_xchg(&dpu_enc->frame_done_timeout, 0)) {
> + if (atomic_xchg(&dpu_enc->frame_done_timeout_ms, 0)) {
> DPU_ERROR("enc%d timeout pending\n", drm_enc->base.id);
> del_timer_sync(&dpu_enc->frame_done_timer);
> }
> @@ -1341,7 +1344,7 @@ static void dpu_encoder_frame_done_callback(
> }
>
> if (!dpu_enc->frame_busy_mask[0]) {
> - atomic_set(&dpu_enc->frame_done_timeout, 0);
> + atomic_set(&dpu_enc->frame_done_timeout_ms, 0);
> del_timer(&dpu_enc->frame_done_timer);
>
> dpu_encoder_resource_control(drm_enc,
> @@ -1804,10 +1807,10 @@ void dpu_encoder_kickoff(struct drm_encoder *drm_enc,
> bool async)
>
> trace_dpu_enc_kickoff(DRMID(drm_enc));
>
> - timeout_ms = DPU_FRAME_DONE_TIMEOUT * 1000 /
> + timeout
[Bug 109499] amdgpu 4k modes not working
https://bugs.freedesktop.org/show_bug.cgi?id=109499 --- Comment #4 from Nadal Gonzalo García Zavala --- I'm not sure, but is possible the issue were fixed between revisions 43 and 45 of ubuntu kernel 4.15. Before upgrading the kernel, we reached a solution: - Using EDID emulators, getting xrandr showing both DisplayPort outputting 4k - Dumping the EDID to a file - Quitting emulators, conecting DisplayPorts normally with EDID firmware forced to previously generated file. Will attach our working EDID file. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109499] amdgpu 4k modes not working
https://bugs.freedesktop.org/show_bug.cgi?id=109499 --- Comment #5 from Nadal Gonzalo García Zavala --- Created attachment 143308 --> https://bugs.freedesktop.org/attachment.cgi?id=143308&action=edit working_edid.bin -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu drm-fixes-5.0
Hi Dave, Daniel, Fixes for 5.0: - Fix missing freesync properties on eDP - Fix locking in pasid mgr - Fix clang warning in kfd - DC/powerplay fix - Fix reported rev ids on raven - Doorbell fix for vega20 The following changes since commit 6e11ea9de9576a644045ffdc2067c09bc2012eda: drm/amdgpu: Transfer fences to dmabuf importer (2019-01-30 12:52:44 -0500) are available in the Git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-5.0 for you to fetch changes up to 7fad8da1ae23171de0ea3cdb2c620f71eb2ab983: drm/amd/display: Attach VRR properties for eDP connectors (2019-02-05 18:10:28 -0500) Huang Rui (1): drm/amdgpu: fix the incorrect external id for raven series Jay Cornwall (1): drm/amdgpu: Implement doorbell self-ring for NBIO 7.4 Nathan Chancellor (1): drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpu Nicholas Kazlauskas (1): drm/amd/display: Attach VRR properties for eDP connectors Philip Yang (1): drm/amdgpu: use spin_lock_irqsave to protect vm_manager.pasid_idr Roman Li (1): drm/amd/display: Fix fclk idle state drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 5 +++-- drivers/gpu/drm/amd/amdgpu/nbio_v7_4.c| 13 + drivers/gpu/drm/amd/amdgpu/soc15.c| 6 -- drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- drivers/gpu/drm/amd/display/dc/dce/dce_clk_mgr.c | 10 +- 6 files changed, 32 insertions(+), 7 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109561] [regression, bisected] code re-factor causing games to stutter or lock-up system
https://bugs.freedesktop.org/show_bug.cgi?id=109561 Bug ID: 109561 Summary: [regression, bisected] code re-factor causing games to stutter or lock-up system Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: t_arc...@yahoo.com.au QA Contact: dri-devel@lists.freedesktop.org The following commit cause bad stuttering in the Batman Arkham City benchmark (note when testing this game is 32bit). It also causes No Mans Sky to freeze my system. Link to No Mans Sky api trace below. Needs the following environment variables set when running apitrace: force_glsl_extensions_warn=true allow_glsl_layout_qualifier_on_function_parameters=true https://drive.google.com/open?id=1xFl7Uzfr75aODC0ljP8hC5OYRxgtuCan commit e0f0d3675d462aad4ca30e4383a3530d46e6e85d Author: Nicolai Hähnle Date: Tue Sep 18 15:52:17 2018 +0200 radeonsi: factor si_query_buffer logic out of si_query_hw This is a move towards using composition instead of inheritance for different query types. This change weakens out-of-memory error reporting somewhat, though this should be acceptable since we didn't consistently report such errors in the first place. Reviewed-by: Marek Olšák -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/i915_pci.c
between commit:
fcd70cd36b9b ("drm: Split out drm_probe_helper.h")
from the drm tree and commit:
5f5c139d6900 ("drm/i915: Allocate active tracking nodes from a slabcache")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/i915_pci.c
index 5d05572c9ff4,36fa6f1905fc..
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@@ -26,8 -26,7 +26,9 @@@
#include
#include
+#include
+
+ #include "i915_active.h"
#include "i915_drv.h"
#include "i915_selftest.h"
pgpmFzmRf3OYm.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 --- Comment #1 from Michael A. Leonetti (mikealeone...@gmail.com) --- Created attachment 281011 --> https://bugzilla.kernel.org/attachment.cgi?id=281011&action=edit 4.17.19 working amdgpu dmesg For reference here is my dmesg from the 4.17.19 which will modprobe amdgpu. -- 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 202511] amdgpu fails to load saying "Could not allocate 8192 bytes percpu data"
https://bugzilla.kernel.org/show_bug.cgi?id=202511 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/3] drm/fourcc: Add 64 bpp half float formats
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.org/patch/10072545/
v2:
- Fixed cpp (Ville)
- Added detail pixel formatting (Ville)
- Ordered formats in header (Ville)
Cc: Tina Zhang
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.h | 11 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d90ee03..c866452 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -198,6 +198,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGBA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGRA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_XRGB16161616F, .depth = 48,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XBGR16161616F, .depth = 48,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_ARGB16161616F, .depth = 64,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR16161616F, .depth = 64,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGB888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGR888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_XRGB_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 93a341d..d323c73 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/3] drm/i915: Refactor icl_is_hdr_plane
Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser
---
drivers/gpu/drm/i915/intel_atomic.c | 4 +++-
drivers/gpu/drm/i915/intel_display.c | 5 +++--
drivers/gpu/drm/i915/intel_drv.h | 7 ---
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 16263ad..7f824fd 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -210,6 +210,7 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
int *scaler_id)
{
struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ struct intel_plane *intel_plane;
int j;
u32 mode;
@@ -232,10 +233,11 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
if (plane_state && plane_state->base.fb &&
plane_state->base.fb->format->is_yuv &&
plane_state->base.fb->format->num_planes > 1) {
+ intel_plane = to_intel_plane(plane_state->base.plane);
if (IS_GEN(dev_priv, 9) &&
!IS_GEMINILAKE(dev_priv)) {
mode = SKL_PS_SCALER_MODE_NV12;
- } else if
(icl_is_hdr_plane(to_intel_plane(plane_state->base.plane))) {
+ } else if (icl_is_hdr_plane(dev_priv, intel_plane->id)) {
/*
* On gen11+'s HDR planes we only use the scaler for
* scaling. They have a dedicated chroma upsampler, so
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d5ec92..2d9639d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3726,7 +3726,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
- if (fb->format->is_yuv && !icl_is_hdr_plane(plane)) {
+ if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
@@ -5052,13 +5052,14 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
{
struct intel_plane *intel_plane =
to_intel_plane(plane_state->base.plane);
+ struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
struct drm_framebuffer *fb = plane_state->base.fb;
int ret;
bool force_detach = !fb || !plane_state->base.visible;
bool need_scaler = false;
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
- if (!icl_is_hdr_plane(intel_plane) &&
+ if (!icl_is_hdr_plane(dev_priv, intel_plane->id) &&
fb && fb->format->format == DRM_FORMAT_NV12)
need_scaler = true;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 90ba543..154901f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2313,12 +2313,13 @@ static inline bool icl_is_nv12_y_plane(enum plane_id id)
return false;
}
-static inline bool icl_is_hdr_plane(struct intel_plane *plane)
+static inline bool icl_is_hdr_plane(struct drm_i915_private *dev_priv,
+ enum plane_id id)
{
- if (INTEL_GEN(to_i915(plane->base.dev)) < 11)
+ if (INTEL_GEN(dev_priv) < 11)
return false;
- return plane->id < PLANE_SPRITE2;
+ return id < PLANE_SPRITE2;
}
/* intel_tv.c */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index cd42e81..10b37e8 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -336,7 +336,7 @@ skl_program_scaler(struct intel_plane *plane,
/* TODO: handle sub-pixel coordinates */
if (plane_state->base.fb->format->format == DRM_FORMAT_NV12 &&
- !icl_is_hdr_plane(plane)) {
+ !icl_is_hdr_plane(dev_priv, plane->id)) {
y_hphase = skl_scaler_calc_phase(1, hscale, false);
y_vphase = skl_scaler_calc_phase(1, vscale, false);
@@ -511,7 +511,7 @@ skl_program_plane(struct intel_plane *plane,
I915_WRITE_FW(PLANE_AUX_DIST(pipe, plane_id),
(plane_state->color_plane[1].offset - surf_addr) |
aux_stride);
- if (icl_is_hdr_plane(plane)) {
+ if (icl_is_hdr_plane(de
[PATCH v3 3/3] drm/i915/icl: Implement half float formats
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use icl_is_hdr_plane too early
v3:
- Use refactored icl_is_hdr_plane (Ville)
- Use u32 instead of uint32_t (Ville)
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser
---
drivers/gpu/drm/i915/intel_display.c | 22
drivers/gpu/drm/i915/intel_sprite.c | 67
2 files changed, 83 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2d9639d..1124502 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2668,6 +2668,18 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_RGB565;
case PLANE_CTL_FORMAT_NV12:
return DRM_FORMAT_NV12;
+ case PLANE_CTL_FORMAT_XRGB_16161616F:
+ if (rgb_order) {
+ if (alpha)
+ return DRM_FORMAT_ABGR16161616F;
+ else
+ return DRM_FORMAT_XBGR16161616F;
+ } else {
+ if (alpha)
+ return DRM_FORMAT_ARGB16161616F;
+ else
+ return DRM_FORMAT_XRGB16161616F;
+ }
default:
case PLANE_CTL_FORMAT_XRGB_:
if (rgb_order) {
@@ -3566,6 +3578,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_VYUY;
case DRM_FORMAT_NV12:
return PLANE_CTL_FORMAT_NV12;
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ABGR16161616F:
+ return PLANE_CTL_FORMAT_XRGB_16161616F | PLANE_CTL_ORDER_RGBX;
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_ARGB16161616F:
+ return PLANE_CTL_FORMAT_XRGB_16161616F;
default:
MISSING_CASE(pixel_format);
}
@@ -5097,6 +5115,10 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_UYVY:
case DRM_FORMAT_VYUY:
case DRM_FORMAT_NV12:
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ABGR16161616F:
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_ARGB16161616F:
break;
default:
DRM_DEBUG_KMS("[PLANE:%d:%s] FB:%d unsupported scaling format
0x%x\n",
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 10b37e8..55ee677 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1450,8 +1450,6 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
/*
* 90/270 is not allowed with RGB64 16:16:16:16 and
* Indexed 8-bit. RGB 16-bit 5:6:5 is allowed gen11 onwards.
-* TBD: Add RGB64 case once its added in supported format
-* list.
*/
switch (fb->format->format) {
case DRM_FORMAT_RGB565:
@@ -1459,6 +1457,10 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
break;
/* fall through */
case DRM_FORMAT_C8:
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ARGB16161616F:
+ case DRM_FORMAT_ABGR16161616F:
DRM_DEBUG_KMS("Unsupported pixel format %s for
90/270!\n",
drm_get_format_name(fb->format->format,
&format_name));
@@ -1774,6 +1776,45 @@ static const u32 skl_planar_formats[] = {
DRM_FORMAT_NV12,
};
+static const u32 icl_hdr_plane_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_XRGB16161616F,
+ DRM_FORMAT_XBGR16161616F,
+ DRM_FORMAT_ARGB16161616F,
+ DRM_FORMAT_ABGR16161616F,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+};
+
+static const u32 icl_hdr_planar_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+
