Re: [linux-sunxi] Re: [PATCH v2 11/27] drm/sun4i: tcon: Add support for tcon-top gate
On Thu, Jun 21, 2018 at 3:37 AM, Jernej Škrabec wrote:
> Dne sobota, 16. junij 2018 ob 07:48:38 CEST je Chen-Yu Tsai napisal(a):
>> On Sat, Jun 16, 2018 at 1:33 AM, Jernej Škrabec
> wrote:
>> > Dne petek, 15. junij 2018 ob 19:13:17 CEST je Chen-Yu Tsai napisal(a):
>> >> On Sat, Jun 16, 2018 at 12:41 AM, Jernej Škrabec
>> >>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > Dne petek, 15. junij 2018 ob 10:31:10 CEST je Maxime Ripard napisal(a):
>> >> >> Hi,
>> >> >>
>> >> >> On Tue, Jun 12, 2018 at 10:00:20PM +0200, Jernej Skrabec wrote:
>> >> >> > TV TCONs connected to TCON TOP have to enable additional gate in
>> >> >> > order
>> >> >> > to work.
>> >> >> >
>> >> >> > Add support for such TCONs.
>> >> >> >
>> >> >> > Signed-off-by: Jernej Skrabec
>> >> >> > ---
>> >> >> >
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 11 +++
>> >> >> > drivers/gpu/drm/sun4i/sun4i_tcon.h | 4
>> >> >> > 2 files changed, 15 insertions(+)
>> >> >> >
>> >> >> > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index
>> >> >> > 08747fc3ee71..0afb5a94a414
>> >> >> > 100644
>> >> >> > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
>> >> >> > @@ -688,6 +688,16 @@ static int sun4i_tcon_init_clocks(struct device
>> >> >> > *dev,
>> >> >> >
>> >> >> > dev_err(dev, "Couldn't get the TCON bus clock\n");
>> >> >> > return PTR_ERR(tcon->clk);
>> >> >> >
>> >> >> > }
>> >> >> >
>> >> >> > +
>> >> >> > + if (tcon->quirks->has_tcon_top_gate) {
>> >> >> > + tcon->top_clk = devm_clk_get(dev, "tcon-top");
>> >> >> > + if (IS_ERR(tcon->top_clk)) {
>> >> >> > + dev_err(dev, "Couldn't get the TCON TOP bus
>> >> >> > clock\n");
>> >> >> > + return PTR_ERR(tcon->top_clk);
>> >> >> > + }
>> >> >> > + clk_prepare_enable(tcon->top_clk);
>> >> >> > + }
>> >> >> > +
>> >> >>
>> >> >> Is it required for the TCON itself to operate, or does the TCON
>> >> >> requires the TCON TOP, which in turn requires that clock to be
>> >> >> functional?
>> >> >>
>> >> >> I find it quite odd to have a clock that isn't meant for a particular
>> >> >> device to actually be wired to another device. I'm not saying this
>> >> >> isn't the case, but it would be a first.
>> >> >
>> >> > Documentation doesn't say much about that gate. I did few tests and
>> >> > TCON
>> >> > registers can be read and written even if TCON TOP TV TCON gate is
>> >> > disabled. However, there is no image, as expected.
>> >>
>> >> The R40 manual does include it in the diagram, on page 504. There's also
>> >> a
>> >> mux to select whether the clock comes directly from the CCU or the TV
>> >> encoder (a feedback mode?). I assume this is the gate you are referring
>> >> to
>> >> here, in which case it is not a bus clock, but rather the TCON module or
>> >> channel clock, strangely routed.
>> >>
>> >> > More interestingly, I enabled test pattern directly in TCON to
>> >> > eliminate
>> >> > influence of the mixer. As soon as I disabled that gate, test pattern
>> >> > on
>> >> > HDMI screen was gone, which suggest that this gate influences something
>> >> > inside TCON.
>> >> >
>> >> > Another test I did was that I moved enable/disable gate code to
>> >> > sun4i_tcon_channel_set_status() and it worked just as well.
>> >> >
>> >> > I'll ask AW engineer what that gate actually does, but from what I saw,
>> >> > I
>> >> > would say that most appropriate location to enable/disable TCON TOP TV
>> >> > TCON
>> >> > gate is TCON driver. Alternatively, TCON TOP driver could check if any
>> >> > TV
>> >> > TCON is in use and enable appropriate gate. However, that doesn't sound
>> >> > right to me for some reason.
>> >>
>> >> If what I said above it true, then yes, the appropriate location to
>> >> enable
>> >> it is the TCON driver, but moreover, the representation of the clock tree
>> >> should be fixed such that the TCON takes the clock from the TCON TOP as
>> >> its
>> >> channel/ module clock instead. That way you don't need this patch, but
>> >> you'd add another for all the clock routing.
>> >
>> > Can you be more specific? I not sure what you mean here.
>>
>> For clock related properties in the device tree:
>>
>> _top {
>> clocks = < CLK_BUS_TCON_TOP>,
>> < CLK_TCON_TV0>,
>> <>,
>> < CLK_TCON_TV1>,
>> <>;
>> clock-names = "bus", "tcon-tv0", "tve0", "tcon-tv1", "tve1";
>> clock-output-names = "tcon-top-tv0", "tcon-top-tv1";
>> };
>>
>> _tv0 {
>> clocks = < CLK_BUS_TCON_TV0>, <_top 0>'
>> clock-names = "ahb", "tcon-ch1";
>> };
>>
>> A diagram would look like:
>>| This part is TCON TOP |
>>
>>v v
>> CCU CLK_TCON_TV0 --|\ |
>>
>>| mux gate |-- TCON_TV0
>>
>> TVE0 --|/ |
>>
>> And
[PULL] drm-misc-next
Hi Dave, our first pull for 4.19, over 90 patches here, probably the most important ones are for the writeback connector support. Then we have a bunch of fixes to drivers, some interesting core cleanups and new panel drivers. This contains a backmerge of drm-next due to conflicts in drm_atomic.c Please pull, Gustavo drm-misc-next-2018-06-20-1: drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) The following changes since commit daf0678c2036c918f01e4aa6035629d2debc2f30: Merge branch 'drm-next-4.18' of git://people.freedesktop.org/~agd5f/linux into drm-next (2018-06-15 11:32:29 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-06-20-1 for you to fetch changes up to f55786faa156370374c358d186eabf2f6e32e93f: drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build (2018-06-20 17:48:24 +0100) drm-misc-next for 4.19: UAPI Changes: - Add writeback connector (Brian Starkey/Liviu Dudau) - Add "content type" property to HDMI connectors (Stanislav Lisovskiy) Cross-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) Driver Changes: - Fixes for the otm8009a panel driver (Philippe Cornu) - Add Innolux TV123WAM panel driver support (Sandeep Panda) - Move GEM BO to drm_framebuffer in few drivers (Daniel Stone) - i915 pinning improvements (Chris Wilson) - Stop consulting plane->fb/crtc in a few drivers (Ville Syrjälä) Alexandru Gheorghe (1): drm/atomic: Set current atomic state in drm_private_state Arnd Bergmann (1): drm/sun4i: mark PM functions as __maybe_unused Brian Starkey (2): drm: Add writeback connector type drm: writeback: Add out-fences for writeback connectors Chris Wilson (5): drm/mm: Reject over-sized allocation requests early drm/mm: Add a search-by-address variant to only inspect a single hole drm/i915: Limit searching for PIN_HIGH drm/i915: Pin the ring high drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build Christian König (2): dma_buf: remove device parameter from attach callback v2 dma-buf: remove kmap_atomic interface Colin Ian King (1): drm/xen-front: fix spelling mistake: "conector" -> "connector" Dan Carpenter (1): drm/v3d: Checking for NULL vs IS_ERR() Daniel Stone (14): drm/cirrus: Place GEM BOs in drm_framebuffer drm/cirrus: cirrus_framebuffer -> drm_framebuffer drm/virtio: Place GEM BOs in drm_framebuffer drm/armada: Move GEM BO to drm_framebuffer drm/gma500: Move GEM BO to drm_framebuffer drm/msm: Move GEM BOs to drm_framebuffer drm/mtk: Remove impossible internal error drm/mtk: Move GEM BO to drm_framebuffer drm/mtk: mtk_drm_fb -> drm_framebuffer drm/rockchip: Place GEM BOs in drm_framebuffer drm/rockchip: rockchip_drm_fb -> drm_framebuffer drm/omap: Move GEM BO to drm_framebuffer drm/omap: Move buffer pitch/offset to drm_framebuffer drm/gma500: Fix Medfield for drm_framebuffer move Daniel Vetter (3): drm/fb-helper: Fix typo on kerneldoc drm/gem-fb-helper: Always do implicit sync drm/vc4: Always obey implicit sync Dave Stevenson (1): drm/vc4: Add support for SAND modifier. Eric Anholt (2): drm: Trust format_mod_supported() when it OKs a plane modifier. drm/vc4: Add missing formats to vc4_format_mod_supported(). Gerd Hoffmann (1): dma-buf: make map_atomic and map function pointers optional Gustavo Padovan (1): Merge drm-upstream/drm-next into drm-misc-next Haneen Mohammed (1): drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers Heiko Stuebner (1): drm/rockchip: vop: split out core clock enablement into separate functions Inki Dae (1): drm/bridge: sil_sii8620: do not have a dependency of RC_CORE Julia Lawall (1): drm/rockchip: lvds: add missing of_node_put Jyri Sarha (2): drm/panel: Remove drm_panel_detach() calls from all panel drivers drm/panel: Add device_link from panel
[PATCH] drm/v3d: Define the fourcc modifier for the Broadcom UIF format.
This will be used by Mesa, and potentially other drivers in the
future, to describe tiled buffers.
Signed-off-by: Eric Anholt
---
include/uapi/drm/drm_fourcc.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 64bf67abff7e..d5e52350a3aa 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -464,6 +464,27 @@ extern "C" {
#define DRM_FORMAT_MOD_BROADCOM_SAND256 \
DRM_FORMAT_MOD_BROADCOM_SAND256_COL_HEIGHT(0)
+/* Broadcom UIF format
+ *
+ * This is the common format for the current Broadcom multimedia
+ * blocks, including V3D 3.x and newer, newer video codecs, and
+ * displays.
+ *
+ * The image consists of utiles (64b blocks), UIF blocks (2x2 utiles),
+ * and macroblocks (4x4 UIF blocks). Those 4x4 UIF block groups are
+ * stored in columns, with padding between the columns to ensure that
+ * moving from one column to the next doesn't hit the same SDRAM page
+ * bank.
+ *
+ * To calculate the padding, it is assumed that each hardware block
+ * and the software driving it knows the platform's SDRAM page size,
+ * number of banks, and XOR address, and that it's identical between
+ * all blocks using the format. This tiling modifier will use XOR as
+ * necessary to reduce the padding. If a hardware block can't do XOR,
+ * the assumption is that a no-XOR tiling modifier will be created.
+ */
+#define DRM_FORMAT_MOD_BROADCOM_UIF fourcc_mod_code(BROADCOM, 6)
+
#if defined(__cplusplus)
}
#endif
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] intel: Introducing Amber Lake platform
On Wed, Jun 20, 2018 at 04:31:15PM -0700, Rodrigo Vivi wrote:
> On Tue, Jun 19, 2018 at 04:45:21PM -0700, José Roberto de Souza wrote:
> > Amber Lake uses the same gen graphics as Kaby Lake, including a id
> > that were previously marked as reserved on Kaby Lake, but that now is
> > moved to AML page.
> >
> > So, let's just move it to AML macro that will feed into KBL macro
> > just to keep it better organized to make easier future code review
> > but it will be handled as a KBL.
> >
> > This is a copy of merged i915's
> > commit e364672477a1 ("drm/i915/aml: Introducing Amber Lake platform")
> >
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
>
> Reviewed-by: Rodrigo Vivi
>
> I just didn't push yet because I haven't migrated my system to
> new gitlab yet. And I wasn't able to login.
> I hope that someone else can push these 2 patches for now.
> I will try to get my gitlab account working later anyways...
nevermind. the reset pswd email finally arrived on my inbox
so gitlab up and running
patches pushed, thanks.
>
> Thanks,
> Rodrigo.
>
> > ---
> > intel/intel_chipset.h | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> > index 44e65f9e..583d6447 100644
> > --- a/intel/intel_chipset.h
> > +++ b/intel/intel_chipset.h
> > @@ -201,7 +201,6 @@
> > #define PCI_CHIP_KABYLAKE_ULX_GT1_50x5915
> > #define PCI_CHIP_KABYLAKE_ULX_GT1 0x590E
> > #define PCI_CHIP_KABYLAKE_ULX_GT2_00x591E
> > -#define PCI_CHIP_KABYLAKE_ULX_GT2_10x591C
> > #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
> > #define PCI_CHIP_KABYLAKE_M_GT20x5917
> > #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
> > @@ -213,6 +212,9 @@
> > #define PCI_CHIP_KABYLAKE_SRV_GT1 0x590A
> > #define PCI_CHIP_KABYLAKE_WKS_GT2 0x591D
> >
> > +#define PCI_CHIP_AMBERLAKE_ULX_GT2_1 0x591C
> > +#define PCI_CHIP_AMBERLAKE_ULX_GT2_2 0x87C0
> > +
> > #define PCI_CHIP_BROXTON_0 0x0A84
> > #define PCI_CHIP_BROXTON_1 0x1A84
> > #define PCI_CHIP_BROXTON_2 0x5A84
> > @@ -468,12 +470,13 @@
> > #define IS_KBL_GT2(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT2 || \
> > (devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \
> > (devid) == PCI_CHIP_KABYLAKE_ULX_GT2_0 || \
> > -(devid) == PCI_CHIP_KABYLAKE_ULX_GT2_1 || \
> > (devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \
> > (devid) == PCI_CHIP_KABYLAKE_M_GT2 || \
> > (devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \
> > (devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \
> > -(devid) == PCI_CHIP_KABYLAKE_WKS_GT2)
> > +(devid) == PCI_CHIP_KABYLAKE_WKS_GT2 || \
> > +(devid) == PCI_CHIP_AMBERLAKE_ULX_GT2_1
> > || \
> > +(devid) == PCI_CHIP_AMBERLAKE_ULX_GT2_2)
> >
> > #define IS_KBL_GT3(devid) ((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \
> > (devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] intel: Introducing Amber Lake platform
On Tue, Jun 19, 2018 at 04:45:21PM -0700, José Roberto de Souza wrote:
> Amber Lake uses the same gen graphics as Kaby Lake, including a id
> that were previously marked as reserved on Kaby Lake, but that now is
> moved to AML page.
>
> So, let's just move it to AML macro that will feed into KBL macro
> just to keep it better organized to make easier future code review
> but it will be handled as a KBL.
>
> This is a copy of merged i915's
> commit e364672477a1 ("drm/i915/aml: Introducing Amber Lake platform")
>
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
Reviewed-by: Rodrigo Vivi
I just didn't push yet because I haven't migrated my system to
new gitlab yet. And I wasn't able to login.
I hope that someone else can push these 2 patches for now.
I will try to get my gitlab account working later anyways...
Thanks,
Rodrigo.
> ---
> intel/intel_chipset.h | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 44e65f9e..583d6447 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -201,7 +201,6 @@
> #define PCI_CHIP_KABYLAKE_ULX_GT1_5 0x5915
> #define PCI_CHIP_KABYLAKE_ULX_GT10x590E
> #define PCI_CHIP_KABYLAKE_ULX_GT2_0 0x591E
> -#define PCI_CHIP_KABYLAKE_ULX_GT2_1 0x591C
> #define PCI_CHIP_KABYLAKE_DT_GT2 0x5912
> #define PCI_CHIP_KABYLAKE_M_GT2 0x5917
> #define PCI_CHIP_KABYLAKE_DT_GT1 0x5902
> @@ -213,6 +212,9 @@
> #define PCI_CHIP_KABYLAKE_SRV_GT10x590A
> #define PCI_CHIP_KABYLAKE_WKS_GT20x591D
>
> +#define PCI_CHIP_AMBERLAKE_ULX_GT2_1 0x591C
> +#define PCI_CHIP_AMBERLAKE_ULX_GT2_2 0x87C0
> +
> #define PCI_CHIP_BROXTON_0 0x0A84
> #define PCI_CHIP_BROXTON_1 0x1A84
> #define PCI_CHIP_BROXTON_2 0x5A84
> @@ -468,12 +470,13 @@
> #define IS_KBL_GT2(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT2 || \
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT2F || \
>(devid) == PCI_CHIP_KABYLAKE_ULX_GT2_0 || \
> - (devid) == PCI_CHIP_KABYLAKE_ULX_GT2_1 || \
>(devid) == PCI_CHIP_KABYLAKE_DT_GT2|| \
>(devid) == PCI_CHIP_KABYLAKE_M_GT2 || \
>(devid) == PCI_CHIP_KABYLAKE_HALO_GT2 || \
>(devid) == PCI_CHIP_KABYLAKE_SRV_GT2 || \
> - (devid) == PCI_CHIP_KABYLAKE_WKS_GT2)
> + (devid) == PCI_CHIP_KABYLAKE_WKS_GT2 || \
> + (devid) == PCI_CHIP_AMBERLAKE_ULX_GT2_1
> || \
> + (devid) == PCI_CHIP_AMBERLAKE_ULX_GT2_2)
>
> #define IS_KBL_GT3(devid)((devid) == PCI_CHIP_KABYLAKE_ULT_GT3_0 || \
>(devid) == PCI_CHIP_KABYLAKE_ULT_GT3_1 || \
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/2] intel: Introducing Whiskey Lake platform
On Tue, Jun 19, 2018 at 04:45:20PM -0700, José Roberto de Souza wrote:
> Whiskey Lake uses the same gen graphics as Coffe Lake, including some
> ids that were previously marked as reserved on Coffe Lake, but that
> now are moved to WHL page.
>
> So, let's just move them to WHL macros that will feed into CFL macro
> just to keep it better organized to make easier future code review
> but it will be handled as a CFL.
>
> This is a copy of merged i915's
> commit b9be78531d27 ("drm/i915/whl: Introducing Whiskey Lake platform")
>
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
Reviewed-by: Rodrigo Vivi
> ---
> intel/intel_chipset.h | 33 +
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
> index 32b2c48f..44e65f9e 100644
> --- a/intel/intel_chipset.h
> +++ b/intel/intel_chipset.h
> @@ -231,16 +231,17 @@
> #define PCI_CHIP_COFFEELAKE_S_GT2_4 0x3E9A
> #define PCI_CHIP_COFFEELAKE_H_GT2_1 0x3E9B
> #define PCI_CHIP_COFFEELAKE_H_GT2_2 0x3E94
> -#define PCI_CHIP_COFFEELAKE_U_GT1_1 0x3EA1
> -#define PCI_CHIP_COFFEELAKE_U_GT1_2 0x3EA4
> -#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA0
> -#define PCI_CHIP_COFFEELAKE_U_GT2_2 0x3EA3
> -#define PCI_CHIP_COFFEELAKE_U_GT2_3 0x3EA9
> -#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA2
> -#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA5
> -#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA6
> -#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA7
> -#define PCI_CHIP_COFFEELAKE_U_GT3_5 0x3EA8
> +#define PCI_CHIP_COFFEELAKE_U_GT2_1 0x3EA9
> +#define PCI_CHIP_COFFEELAKE_U_GT3_1 0x3EA5
> +#define PCI_CHIP_COFFEELAKE_U_GT3_2 0x3EA6
> +#define PCI_CHIP_COFFEELAKE_U_GT3_3 0x3EA7
> +#define PCI_CHIP_COFFEELAKE_U_GT3_4 0x3EA8
> +
> +#define PCI_CHIP_WHISKEYLAKE_U_GT1_1 0x3EA1
> +#define PCI_CHIP_WHISKEYLAKE_U_GT2_1 0x3EA0
> +#define PCI_CHIP_WHISKEYLAKE_U_GT3_1 0x3EA2
> +#define PCI_CHIP_WHISKEYLAKE_U_GT3_2 0x3EA3
> +#define PCI_CHIP_WHISKEYLAKE_U_GT3_3 0x3EA4
>
> #define PCI_CHIP_CANNONLAKE_00x5A51
> #define PCI_CHIP_CANNONLAKE_10x5A59
> @@ -510,16 +511,16 @@
> #define IS_CFL_H(devid) ((devid) == PCI_CHIP_COFFEELAKE_H_GT2_1 || \
> (devid) == PCI_CHIP_COFFEELAKE_H_GT2_2)
>
> -#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT1_1 || \
> - (devid) == PCI_CHIP_COFFEELAKE_U_GT1_2 || \
> - (devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \
> - (devid) == PCI_CHIP_COFFEELAKE_U_GT2_2 || \
> - (devid) == PCI_CHIP_COFFEELAKE_U_GT2_3 || \
> +#define IS_CFL_U(devid) ((devid) == PCI_CHIP_COFFEELAKE_U_GT2_1 || \
> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_1 || \
> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_2 || \
> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_3 || \
> (devid) == PCI_CHIP_COFFEELAKE_U_GT3_4 || \
> - (devid) == PCI_CHIP_COFFEELAKE_U_GT3_5)
> + (devid) == PCI_CHIP_WHISKEYLAKE_U_GT1_1 || \
> + (devid) == PCI_CHIP_WHISKEYLAKE_U_GT2_1 || \
> + (devid) == PCI_CHIP_WHISKEYLAKE_U_GT3_1 || \
> + (devid) == PCI_CHIP_WHISKEYLAKE_U_GT3_2 || \
> + (devid) == PCI_CHIP_WHISKEYLAKE_U_GT3_3)
>
> #define IS_COFFEELAKE(devid) (IS_CFL_S(devid) || \
> IS_CFL_H(devid) || \
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #34 from Ben Crocker --- Things start to go haywire at 246.305790, which appears to be the first time the do-loop in amdgpu_vm_bo_update_mapping executes more than once. The value of max_entries is obviously absurd; a little later, the value of start (0x104000) is consistent with the first trip through the loop, but the value of last (0xe5fff) looks wrong, starting with the fact that it is LESS than start. [ 246.305139] [drm] amdgpu_vm_bo_split_mapping nodes->size=512 pfn=0 max_entries=8192 [ 246.305230] [drm] amdgpu_vm_bo_split_mapping: addr=0x1e200 vram_base_offset=0x0 [ 246.305322] [drm] amdgpu_vm_bo_split_mapping: start=0x102000 last=0x103fff [ 246.305400] [drm] amdgpu_vm_bo_update_mapping l.1304: ndw=64 ncmds=9 fragment_size=9 [ 246.305474] [drm] amdgpu_vm_bo_update_mapping l.1310: resulting ndw=334 [ 246.305533] [drm] amdgpu_vm_bo_update_mapping calls amdgpu_job_alloc_with_ib(..., ndw*4 = 1336 (0538)) [ 246.305630] [drm] amdgpu_job_alloc_with_ib calls amdgpu_ib_get(..., size=1336 (0538)) [ 246.305704] [drm] amdgpu_ib_get calls amdgpu_sa_bo_new(..., size=1336 (0538), align=256 Things go haywire: [ 246.305790] [drm] amdgpu_vm_bo_split_mapping nodes->size=512 pfn=8192 max_entries=18446744073709428736 [ 246.305878] [drm] amdgpu_vm_bo_split_mapping: addr=0x1e200 vram_base_offset=0x0 [ 246.305970] [drm] amdgpu_vm_bo_split_mapping: start=0x104000 last=0xe5fff [ 246.306029] [drm] amdgpu_vm_bo_update_mapping l.1304: ndw=64 ncmds=4194185 fragment_size=9 [ 246.306111] [drm] amdgpu_vm_bo_update_mapping l.1310: resulting ndw=41942094 [ 246.306197] [drm] amdgpu_vm_bo_update_mapping calls amdgpu_job_alloc_with_ib(..., ndw*4 = 167768376 (09FFF138)) [ 246.306322] [drm] amdgpu_job_alloc_with_ib calls amdgpu_ib_get(..., size=167768376 (09fff138)) [ 246.306429] [drm] amdgpu_ib_get calls amdgpu_sa_bo_new(..., size=167768376 (09fff138), align=256 [ 246.306571] WARNING: CPU: 67 PID: 21839 at amdgpu_sa_bo_new+0x628/0x6b0 [amdgpu] [ 246.306645] Modules linked in: binfmt_misc ext4 crc16 mbcache jbd2 fscrypto evdev snd_usb_audio amdgpu snd_usbmidi_lib snd_rawmidi snd_seq_device ghash_generic gf128mul ecb xts ctr snd_hda_codec_hdmi chash ast gpu_sched cbc ttm snd_hda_intel vmx_crypto snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_pcm snd_timer ofpart drm_panel_orientation_quirks syscopyarea snd sysfillrect ipmi_powernv sysimgblt fb_sys_fops ipmi_devintf i2c_algo_bit sg powernv_flash soundcore mtd ipmi_msghandler opal_prd at24 sunrpc ecryptfs ip_tables x_tables autofs4 zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx hid_generic usbhid hid xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear sd_mod md_mod ses -- 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 5/7] vulkan: add VK_EXT_display_control [v5]
Jason Ekstrand writes: > That seems good to me. Unless, of course, DPMS is something we expect to > change over time somehow. Then again, we don't handle that at all right > now so meh. Let's go with what you wrote above for now. It's not even the dpms value, it's the dpms property itself, which DRM never changes. > They shouldn't be and that's why I'm a fan of making them asserts which get > compiled out instead of actual checks. Also, I find this pseudo reference > counting to be somewhat confusing and adding asserts informs the reader of > the assumptions made. Ok, I've added this. > What test suite? Honestly, I know of no code anywhere that actually uses > this API for anything other than VR headsets. > > I guess it's kind-of a question of how much effort we want to put into > this. One option would be to add VK_KHR_display support to vkcube and make > it automatically show up on all your displays using hotplug events. > > If we're going to not care, returning VK_ERROR_FEATURE_NOT_PRESENT is > probably the best thing to do since at least the app has feedback. Not caring seems best to me -- the Vulkan display API isn't capable of supporting a "real" window system; for that, you'd really want to use DRM directly and create some way to share that with Vulkan like the extension I wrote to pass the DRM master FD into the driver at init time. > Awesome. I think we're really close on this one. I'll send out the current series and you can see if you like it. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/7] anv: add VK_EXT_display_control to anv driver [v2]
Jason Ekstrand writes: > I believe that the WSI common code should be capable of fishing the > instance allocator out of the wsi_display so we need only pass the > allocator argument unmodified through to the core WSI code. Make sense? Thanks, I think I've sorted it out. I've pushed an updated series with this change. > Yeah, Vulkan allocator fishing is weird. Allowing custom allocators is one of the bad parts of the Vulkan spec; it will "never" get used, and the chances of it working correctly in any driver are pretty small. But, we do what we can to implement it. -- -keith signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105244] NULL dereference during startup of Cape Verde with AMDGPU and GPU passthrough
https://bugs.freedesktop.org/show_bug.cgi?id=105244 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 102666] amdgpu_vm_bo_invalidate NULL reference in amd-staging-drm-next
https://bugs.freedesktop.org/show_bug.cgi?id=102666 Bas Nieuwenhuizen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Bas Nieuwenhuizen --- I haven't had this in a long while, seems to be fixed for a while. -- 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 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #33 from Ben Crocker --- Created attachment 140253 --> https://bugs.freedesktop.org/attachment.cgi?id=140253=edit Refining the amdgpu_vm.c:amdgpu_vm_bo_split_mapping further Print max_entries in both decimal and hex. -- 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 5/7] vulkan: add VK_EXT_display_control [v5]
On Tue, Jun 19, 2018 at 9:44 PM, Keith Packard wrote:
> Jason Ekstrand writes:
>
>
> >> + if (!prop)
> >> + continue;
> >> + if (prop->flags & DRM_MODE_PROP_ENUM) {
> >> + if (!strcmp(prop->name, "DPMS"))
> >> +connector->dpms_property = drm_connector->props[p];
> >>
> >
> > break?
>
> Not break; I need to free the property. However, an early exit from the
> loop seems reasonable. How about:
>
>for (int p = 0; connector->dpms_property == 0 && p <
> drm_connector->count_props; p++) {
>
> This skips the whole sequence if the property has already been found, or
> stops as soon as it has.
>
That seems good to me. Unless, of course, DPMS is something we expect to
change over time somehow. Then again, we don't handle that at all right
now so meh. Let's go with what you wrote above for now.
> >> +static bool
> >> +wsi_display_fence_wait(struct wsi_fence *fence_wsi,
> >> + bool absolute,
> >> + uint64_t timeout)
> >>
> >
> > Would it make more sense for this function to return a VkResult? Then
> you
> > could tell the difference between success, timeout, and some other
> > failure. I guess the only other thing to return would be
> > VK_ERROR_DEVICE_LOST which seems pretty harsh but, then again,
> > pthread_timed_wait just failed so that's also really bad.
>
> That's a good idea. The boolean return is pretty ambiguous. I copied
> that from the radv internal fence API, which could also benefit from
> this change. I've changed the API and adjusted the anv and radv code to
> match. It reads a lot better now.
>
Cool.
> >> + if (!absolute)
> >> + timeout = wsi_rel_to_abs_time(timeout);
> >>
> >
> > Are relative times really useful? I suspect it doesn't save you more
> than
> > a couple of lines and it makes the interface weird.
>
> No. Relative timeouts aren't actually used anywhere either. I've removed
> them.
>
Sounds good.
> I did catch a mistake in the anv driver looking at this -- the !waitAll
> code wasn't bothering to check the fences if the time had already
> passed, so an application polling would never catch the fences being
> ready. I've changed the while (current_time < timeout) {} to a do {}
> while (current_time < timeout) loop.
>
Yeah, that was going to be a problem for someone if they ever decided to
busy-loop in the app. :-)
> >> +static void
> >> +wsi_display_fence_destroy(struct wsi_fence *fence_wsi)
> >> +{
> >> + struct wsi_display_fence *fence = (struct wsi_display_fence *)
> >> fence_wsi;
> >> +
> >>
> >
> > An assert(!fence->destroyed) in here might be useful to guard against
> > double-frees.
>
> Sure. I was under the impression that application bugs weren't supposed
> to be rigorously checked in the implementation though? When should I be
> checking API usage issues?
>
They shouldn't be and that's why I'm a fan of making them asserts which get
compiled out instead of actual checks. Also, I find this pseudo reference
counting to be somewhat confusing and adding asserts informs the reader of
the assumptions made.
> >> + if (!ret)
> >> + return VK_SUCCESS;
> >> +
> >> + if (errno != ENOMEM) {
> >> + wsi_display_debug("queue vblank event %lu failed\n",
> >> fence->sequence);
> >> + struct timespec delay = {
> >> +.tv_sec = 0,
> >> +.tv_nsec = 1ull,
> >> + };
> >> + nanosleep(, NULL);
> >> + return VK_ERROR_OUT_OF_HOST_MEMORY;
> >>
> >
> > Why are we sleeping for 0.1s before we return? That seems fishy.
>
> Yeah, the kernel API is not great. There's a finite queue which can be
> consumed with both flip events and vblank wait events. If that fills,
> we'll get an error back. The only way to empty it is to have some events
> get delivered, and those will only get delivered after a vblank happens.
>
> It's an application bug that triggers this -- requesting too many vblank
> events. Throttling the application so it doesn't just spin makes it
> possible to stop it.
>
> >> + pthread_mutex_lock(>wait_mutex);
> >> + ret = wsi_display_wait_for_event(wsi, wsi_rel_to_abs_time(
> >> 1ull));
> >>
> >
> > What's with the magic number?
>
> 0.1s -- a value which is longer than any display time, but short enough
> to catch things like DPMS off or VT switch without unduly delaying the
> application.
>
> >> +VkResult
> >> +wsi_register_device_event(VkDevice device,
> >> + struct wsi_device *wsi_device,
> >> + const VkDeviceEventInfoEXT
> *device_event_info,
> >> + const VkAllocationCallbacks *allocator,
> >> + struct wsi_fence **fence_p)
> >> +{
> >> + return VK_ERROR_FEATURE_NOT_PRESENT;
> >>
> >
> > I don't think we're allowed to just not implemnet this. At the very
> least,
> > we should accept the event and never trigger it. Better would be to
> > actually wire up hotplug detection. I
[Bug 106258] AMD Xorg start failes with non-4K page sizes
https://bugs.freedesktop.org/show_bug.cgi?id=106258 --- Comment #32 from fox...@ruin.net --- Created attachment 140252 --> https://bugs.freedesktop.org/attachment.cgi?id=140252=edit amdgpu dmesg output Crash is at 246.306571 -- 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] staging: android: ion: fix ion_dma_buf_attach signatur
Hi Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.18-rc1 next-20180620]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/staging-android-ion-fix-ion_dma_buf_attach-signatur/20180621-044136
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=xtensa
All errors (new ones prefixed by >>):
>> drivers/staging/android/ion/ion.c:374:12: error: initialization of 'int
>> (*)(struct dma_buf *, struct device *, struct dma_buf_attachment *)' from
>> incompatible pointer type 'int (*)(struct dma_buf *, struct
>> dma_buf_attachment *)' [-Werror=incompatible-pointer-types]
.attach = ion_dma_buf_attach,
^~
drivers/staging/android/ion/ion.c:374:12: note: (near initialization for
'dma_buf_ops.attach')
cc1: some warnings being treated as errors
vim +374 drivers/staging/android/ion/ion.c
b892bf75 Rebecca Schultz Zavin 2013-12-13 368
2328ed66 Bhumika Goyal 2016-10-15 369 static const struct dma_buf_ops
dma_buf_ops = {
b892bf75 Rebecca Schultz Zavin 2013-12-13 370 .map_dma_buf =
ion_map_dma_buf,
b892bf75 Rebecca Schultz Zavin 2013-12-13 371 .unmap_dma_buf =
ion_unmap_dma_buf,
b892bf75 Rebecca Schultz Zavin 2013-12-13 372 .mmap = ion_mmap,
b892bf75 Rebecca Schultz Zavin 2013-12-13 373 .release =
ion_dma_buf_release,
2a55e7b5 Laura Abbott 2017-04-03 @374 .attach =
ion_dma_buf_attach,
2a55e7b5 Laura Abbott 2017-04-03 375 .detach =
ion_dma_buf_detatch,
0f34faf8 Rebecca Schultz Zavin 2013-12-13 376 .begin_cpu_access =
ion_dma_buf_begin_cpu_access,
0f34faf8 Rebecca Schultz Zavin 2013-12-13 377 .end_cpu_access =
ion_dma_buf_end_cpu_access,
f9b67f00 Logan Gunthorpe 2017-04-19 378 .map_atomic =
ion_dma_buf_kmap,
f9b67f00 Logan Gunthorpe 2017-04-19 379 .unmap_atomic =
ion_dma_buf_kunmap,
f9b67f00 Logan Gunthorpe 2017-04-19 380 .map = ion_dma_buf_kmap,
f9b67f00 Logan Gunthorpe 2017-04-19 381 .unmap =
ion_dma_buf_kunmap,
c30707be Rebecca Schultz Zavin 2013-12-13 382 };
c30707be Rebecca Schultz Zavin 2013-12-13 383
:: The code at line 374 was first introduced by commit
:: 2a55e7b5e5446c970e00be1bca8536f4a58bf21c staging: android: ion: Call
dma_map_sg for syncing and mapping
:: TO: Laura Abbott
:: CC: Greg Kroah-Hartman
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #22 from SET --- Created attachment 140251 --> https://bugs.freedesktop.org/attachment.cgi?id=140251=edit Bisection results -- 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #21 from SET --- After applying the patch, bisection move on reasonably. See the attached file bisect.log. -- 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 199653] [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)
https://bugzilla.kernel.org/show_bug.cgi?id=199653 --- Comment #7 from James Le Cuirot (ch...@gentoo.org) --- I had high hopes for 4.18-rc1 but alas it froze after a few hours. :( I know having the latest firmware is important so I have that too. These OpenSUSE packages (some unofficial) are installed: kernel-default-4.18.rc1-1.1.gfa9e020 kernel-firmware-20180606-35.1 libdrm2-2.4.99~git20180511-lp150.1.1 Mesa-18.2.0~git20180619-lp150.16.1 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: android: ion: fix ion_dma_buf_attach signatur
Missing 'e' on "signatur". This fixes the build presumably? My guess is that kbuild caught the warning? On Wed, Jun 20, 2018 at 08:52:19PM +0200, Christian König wrote: > Fixup for "dma_buf: remove device parameter from attach callback v2". > I don't think we've applied this? Can't you just resend the original? > I missed this driver, sorry for the noise. Patch is not even compile > tested. > Please put that sort of information under the --- cut off because it doesn't really belong in the final git log. > Signed-off-by: Christian König > --- ^^^ regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 18/27] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
On Tue, Jun 12, 2018 at 10:00:27PM +0200, Jernej Skrabec wrote: > A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL > clock parents. It is compatible to other HDMI PHYs, like that found in > R40. > > Signed-off-by: Jernej Skrabec > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/27] dt-bindings: display: sun4i-drm: Add R40 mixer compatibles
On Tue, Jun 12, 2018 at 10:00:25PM +0200, Jernej Skrabec wrote: > R40 DE2 mixers are similar to those found in A83T, except it needs > different clock settings. > > Add a compatibles for them. > > Signed-off-by: Jernej Skrabec > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++ > 1 file changed, 2 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 10/27] dt-bindings: display: sun4i-drm: Add R40 TV TCON description
On Tue, Jun 12, 2018 at 10:00:19PM +0200, Jernej Skrabec wrote: > TCON description is expanded with R40 TV TCON compatibles. TV TCONs, > which are connected to TCON TOP muxes, such as those on R40 SoC, also > needs additional clock gate to be specified. > > Signed-off-by: Jernej Skrabec > --- > .../devicetree/bindings/display/sunxi/sun4i-drm.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: mark expected switch fall-through
On Wed, Jun 20, 2018 at 08:31:00AM -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Addresses-Coverity-ID: 1470102 ("Missing break in switch")
Any other advantage besides coverity?
Can't we address it by marking as "Intentional" on the tool?
I'm afraid there will be so many more places to add fallthrough
marks
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 132fe63..6a40a77 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2566,6 +2566,7 @@ int icl_calc_dp_combo_pll_link(struct drm_i915_private
> *dev_priv,
> switch (index) {
> default:
> MISSING_CASE(index);
> + /* fall through */
> case 0:
> link_clock = 54;
> break;
> --
> 2.7.4
>
> ___
> 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: [PATCH V3 3/7] backlight: qcom-wled: Add new properties for PMI8998
On Tue, Jun 19, 2018 at 04:43:38PM +0530, Kiran Gunda wrote:
> Update the bindings with the new properties used for
> PMI8998.
>
> Signed-off-by: Kiran Gunda
> ---
> .../bindings/leds/backlight/qcom-wled.txt | 84
> --
> 1 file changed, 77 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> index 14f28f2..503ce87 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> @@ -48,11 +48,15 @@ platforms. The PMIC is connected to the host processor
> via SPMI bus.
> - qcom,current-limit
> Usage:optional
> Value type:
> - Definition: mA; per-string current limit
> - value: For pm8941: from 0 to 25 with 5 mA step
> - Default 20 mA.
> - For pmi8998: from 0 to 30 with 5 mA step
> - Default 25 mA.
> + Definition: mA; per-string current limit; value from 0 to 25 with
> + 1 mA step. Default 20 mA.
> + This property is supported only for pm8941.
> +
> +- qcom,current-limit-microamp
> + Usage:optional
> + Value type:
> + Definition: uA; per-string current limit; value from 0 to 3 with
> + 2500 uA step. Default 25000 uA.
This doesn't really seem worth adding just to add '-microamp'.
> - qcom,current-boost-limit
> Usage:optional
> @@ -79,12 +83,61 @@ platforms. The PMIC is connected to the host processor
> via SPMI bus.
> 27, 29, 32, 35. default: 29V
> This property is supported only for PM8941.
>
> +- qcom,ovp-millivolt
Is this the same as qcom,ovp? If so, same comment.
> + Usage:optional
> + Value type:
> + Definition: mV; Over-voltage protection limit;
> + For pmi8998: one of 18100, 19600, 29600, 31100
> + Default: 29600 mV
> + If this property is not specified for PM8941, it
> + falls back to "qcom,ovp" property.
> +
> - qcom,num-strings
> Usage:optional
> Value type:
> Definition: #; number of led strings attached;
> - value from 1 to 3. default: 2
> - This property is supported only for PM8941.
> + value: For PM8941 from 1 to 3. default: 2
> + For PMI8998 from 1 to 4. default: 4
> +
> +- interrupts
> + Usage:optional
> + Value type:
> + Definition: Interrupts associated with WLED. This should be
> + "short" and "ovp" interrupts. Interrupts can be
> + specified as per the encoding listed under
> + Documentation/devicetree/bindings/spmi/
> + qcom,spmi-pmic-arb.txt.
> +
> +- interrupt-names
> + Usage:optional
> + Value type:
> + Definition: Interrupt names associated with the interrupts.
> + Must be "short" and "ovp". The short circuit detection
> + is not supported for PM8941.
> +
> +- qcom,enabled-strings
> + Usage:optional
> + Value tyoe:
> + Definition: Array of the WLED strings numbered from 0 to 3. Each
> + string of leds are operated individually. Specify the
> + list of strings used by the device. Any combination of
> + led strings can be used.
> + for pm8941: Default values are [00 01].
> + for pmi8998: Default values are [00 01 02 03].
u32 or u8 because dts syntax for 8-bit array is [].
> +
> +- qcom,external-pfet
> + Usage:optional
> + Value type:
> + Definition: Specify if external PFET control for short circuit
> + protection is used. This property is supported only
> + for PMI8998.
> +
> +- qcom,auto-string-detection
> + Usage:optional
> + Value type:
> + Definition: Enables auto-detection of the WLED string configuration.
> + This feature is not supported for PM8941.
> +
>
> Example:
>
> @@ -99,4 +152,21 @@ pm8941-wled@d800 {
> qcom,switching-freq = <1600>;
> qcom,ovp = <29>;
> qcom,num-strings = <2>;
> + qcom,enabled-strings = <0x00 0x01>;
> +};
> +
> +pmi8998-wled@d800 {
led-controller {
And needs a unit-address.
> + compatible = "qcom,pmi8998-wled";
> + reg = <0xd800 0xd900>;
> + label = "backlight";
> +
> + interrupts = <3 0xd8 2 IRQ_TYPE_EDGE_RISING>,
> + <3 0xd8 1 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "short", "ovp";
> + qcom,current-limit-microamp = <25000>;
> + qcom,current-boost-limit = <805>;
> +
[pull] amdgpu drm-fixes-4.18
Hi Dave, A few fixes for amdgpu for 4.18, nothing major. Most going to stable. The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40: Linux 4.18-rc1 (2018-06-17 08:04:49 +0900) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.18 for you to fetch changes up to 7303b39e46b2f523334591f05fd9566cf929eb26: drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurate (2018-06-19 13:51:45 -0500) Harry Wentland (1): drm/amdgpu: Don't default to DC support for Kaveri and older James Zhu (1): drm/amdgpu:All UVD instances share one idle_work handle Michel Dänzer (4): drm/amdgpu: Use kvmalloc_array for allocating VRAM manager nodes array drm/amdgpu: Update pin_size values before unpinning BO drm/amdgpu: Refactor amdgpu_vram_mgr_bo_invisible_size helper drm/amdgpu: Make amdgpu_vram_mgr_bo_invisible_size always accurate Rajan Vaja (1): drm/amd/pp: Fix uninitialized variable drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 24 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h| 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c| 14 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.h| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 39 -- .../gpu/drm/amd/powerplay/hwmgr/vega10_powertune.c | 2 +- 7 files changed, 65 insertions(+), 27 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us
On Wed, Jun 20, 2018 at 02:25:43PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Currently for the psr_table->tp2_tp3_wakeup_time case 3 there appears
> to be a copy-paste error from the previous switch statement where
> dev_priv->vbt.psr.tp1_wakeup_time_us is being assigned and I believe
> it should be dev_priv->vbt.psr.tp2_tp3_wakeup_time_us that should be
> assigned instead.
>
> Detected by CoverityScan, CID#1470105 ("Copy-paste error")
>
> Fixes: 77312ae8f071 ("drm/i915/psr: vbt change for psr")
> Signed-off-by: Colin Ian King
Reviewed-by: Rodrigo Vivi
pushing to dinq now. thanks for the patch.
> ---
> drivers/gpu/drm/i915/intel_bios.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 03f04b472394..e0a14be1080a 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -740,7 +740,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
> bdb_header *bdb)
> dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
> break;
> case 3:
> - dev_priv->vbt.psr.tp1_wakeup_time_us = 0;
> + dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
> break;
> default:
> DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
> outside range[0-3], defaulting to max value 2500us\n",
> --
> 2.17.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] staging: android: ion: fix ion_dma_buf_attach signatur
Fixup for "dma_buf: remove device parameter from attach callback v2".
I missed this driver, sorry for the noise. Patch is not even compile
tested.
Signed-off-by: Christian König
---
drivers/staging/android/ion/ion.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index a5220445b5e8..3d4d35558937 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -201,7 +201,7 @@ struct ion_dma_buf_attachment {
struct list_head list;
};
-static int ion_dma_buf_attach(struct dma_buf *dmabuf, struct device *dev,
+static int ion_dma_buf_attach(struct dma_buf *dmabuf,
struct dma_buf_attachment *attachment)
{
struct ion_dma_buf_attachment *a;
@@ -219,7 +219,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf,
struct device *dev,
}
a->table = table;
- a->dev = dev;
+ a->dev = attachment->dev;
INIT_LIST_HEAD(>list);
attachment->priv = a;
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 2/7] backlight: qcom-wled: restructure the qcom-wled bindings
On Tue, Jun 19, 2018 at 04:43:37PM +0530, Kiran Gunda wrote: > Restructure the qcom-wled bindings for the better readability. > > Signed-off-by: Kiran Gunda > --- > .../bindings/leds/backlight/qcom-wled.txt | 110 > - > 1 file changed, 85 insertions(+), 25 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 1/7] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c
On Tue, Jun 19, 2018 at 04:43:36PM +0530, Kiran Gunda wrote:
> pm8941-wled.c driver is supporting the WLED peripheral
> on pm8941. Rename it to qcom-wled.c so that it can support
> WLED on multiple PMICs.
>
> Signed-off-by: Kiran Gunda
> ---
> .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 +-
Acked-by: Rob Herring
> drivers/video/backlight/Kconfig | 8
>
> drivers/video/backlight/Makefile | 2 +-
> drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0
> 4 files changed, 6 insertions(+), 6 deletions(-)
> rename Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt =>
> qcom-wled.txt} (95%)
> rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 6/9] dt-bindings: tc358754: add DT bindings
On Tue, Jun 19, 2018 at 10:19:27AM +0200, Maciej Purski wrote: > From: Andrzej Hajda > > The patch adds bindings to Toshiba DSI/LVDS bridge TC358764. > Bindings describe power supplies, reset gpio and video interfaces. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > .../bindings/display/bridge/toshiba,tc358764.txt | 35 > ++ > 1 file changed, 35 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/toshiba,tc358764.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/9] dt-bindings: display: add DT bindings for BOE HV070WSA-100 panel
On Tue, Jun 19, 2018 at 10:19:25AM +0200, Maciej Purski wrote: > From: Andrzej Hajda > > The patch adds bindings to BOE HV070-WSA WSVGA panel. > Bindings are compatible with simple panel bindings. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Maciej Purski > --- > .../bindings/display/panel/boe,hv070wsa-100.txt| 28 > ++ > 1 file changed, 28 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > new file mode 100644 > index 000..9e8eea8 > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/panel/boe,hv070wsa-100.txt > @@ -0,0 +1,28 @@ > +BOE HV070WSA-100 7.01" WSVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "boe,hv070wsa-100" > +- power-supply: regulator to provide the VCC supply voltage (3.3 volts) > +- enable-gpio: GPIO pin to enable and disable panel (active high) enable-gpios With that, Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/vkms: Add plane helper struct
This patch adds the struct drm_plane_helper_funcs and the required atomic
hooks.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_plane.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index 2c25b1d6ab5b..f7f63143f6d0 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -19,6 +19,22 @@ static const struct drm_plane_funcs vkms_plane_funcs = {
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
+static int vkms_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ return 0;
+}
+
+static void vkms_primary_plane_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+}
+
+static const struct drm_plane_helper_funcs vkms_primary_helper_funcs = {
+ .atomic_check = vkms_plane_atomic_check,
+ .atomic_update = vkms_primary_plane_update,
+};
+
struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev)
{
struct drm_device *dev = >drm;
@@ -42,5 +58,7 @@ struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev)
return ERR_PTR(ret);
}
+ drm_plane_helper_add(plane, _primary_helper_funcs);
+
return plane;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] drm/vkms: Add atomic helpers functions
This patch adds the struct drm_crtc_helper_funcs with simple
atomic_check and atomic_enable functions.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_crtc.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c
index bf76cd39ece7..84cc05506b09 100644
--- a/drivers/gpu/drm/vkms/vkms_crtc.c
+++ b/drivers/gpu/drm/vkms/vkms_crtc.c
@@ -19,6 +19,22 @@ static const struct drm_crtc_funcs vkms_crtc_funcs = {
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
+static int vkms_crtc_atomic_check(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+ return 0;
+}
+
+static void vkms_crtc_atomic_enable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_state)
+{
+}
+
+static const struct drm_crtc_helper_funcs vkms_crtc_helper_funcs = {
+ .atomic_check = vkms_crtc_atomic_check,
+ .atomic_enable = vkms_crtc_atomic_enable,
+};
+
int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor)
{
@@ -31,5 +47,7 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
return ret;
}
+ drm_crtc_helper_add(crtc, _crtc_helper_funcs);
+
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/vkms: Add connectors helpers
This patch adds the struct drm_connector_helper_funcs with some
necessary hooks. Additionally, it also adds some missing hooks at
drm_connector_funcs.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_drv.c| 6 --
drivers/gpu/drm/vkms/vkms_drv.h| 9 +
drivers/gpu/drm/vkms/vkms_output.c | 27 +++
3 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index cc046fff985c..fe93f8c17997 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -19,12 +19,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-#define XRES_MIN32
-#define YRES_MIN32
-
-#define XRES_MAX 8192
-#define YRES_MAX 8192
-
static struct vkms_device *vkms_device;
static const struct file_operations vkms_driver_fops = {
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 54bb3dd2b2c1..76f1720f81a5 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -6,6 +6,15 @@
#include
#include
+#define XRES_MIN32
+#define YRES_MIN32
+
+#define XRES_DEF 1024
+#define YRES_DEF 768
+
+#define XRES_MAX 8192
+#define YRES_MAX 8192
+
static const u32 vkms_formats[] = {
DRM_FORMAT_XRGB,
};
diff --git a/drivers/gpu/drm/vkms/vkms_output.c
b/drivers/gpu/drm/vkms/vkms_output.c
index 48143eac3c12..fef3b1c1b054 100644
--- a/drivers/gpu/drm/vkms/vkms_output.c
+++ b/drivers/gpu/drm/vkms/vkms_output.c
@@ -8,6 +8,7 @@
#include "vkms_drv.h"
#include
+#include
static void vkms_connector_destroy(struct drm_connector *connector)
{
@@ -18,12 +19,36 @@ static void vkms_connector_destroy(struct drm_connector
*connector)
static const struct drm_connector_funcs vkms_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = vkms_connector_destroy,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
static const struct drm_encoder_funcs vkms_encoder_funcs = {
.destroy = drm_encoder_cleanup,
};
+static int vkms_conn_get_modes(struct drm_connector *connector)
+{
+ int count;
+
+ count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
+ drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
+
+ return count;
+}
+
+static int vkms_conn_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ return MODE_OK;
+}
+
+static const struct drm_connector_helper_funcs vkms_conn_helper_funcs = {
+ .get_modes= vkms_conn_get_modes,
+ .mode_valid = vkms_conn_mode_valid,
+};
+
int vkms_output_init(struct vkms_device *vkmsdev)
{
struct vkms_output *output = >output;
@@ -49,6 +74,8 @@ int vkms_output_init(struct vkms_device *vkmsdev)
goto err_connector;
}
+ drm_connector_helper_add(connector, _conn_helper_funcs);
+
ret = drm_connector_register(connector);
if (ret) {
DRM_ERROR("Failed to register connector\n");
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] drm/vkms: Updates to meet basic kms_flip requirements
Currently, we are trying to make VKMS pass in the kms_flip test (IGT). As a result, we made a series of small changes in the module with the goal to meet some of the necessary steps required by kms_flip. This patchset comprises all the simple modifications used until now to make the kms_flip partially works. It is important to highlight, that VKMS still not pass in the kms_flip, but I send these modifications with the intention to avoid rework. Rodrigo Siqueira (4): drm/vkms: Add helper for framebuffer create drm/vkms: Add atomic helpers functions drm/vkms: Add connectors helpers drm/vkms: Add plane helper struct drivers/gpu/drm/vkms/vkms_crtc.c | 18 ++ drivers/gpu/drm/vkms/vkms_drv.c| 9 +++-- drivers/gpu/drm/vkms/vkms_drv.h| 9 + drivers/gpu/drm/vkms/vkms_output.c | 27 +++ drivers/gpu/drm/vkms/vkms_plane.c | 18 ++ 5 files changed, 75 insertions(+), 6 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/vkms: Add helper for framebuffer create
This patch adds the basic hook required to create framebuffer which is
necessary for providing some of the vkms features.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/vkms_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 638bab9083b5..cc046fff985c 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include "vkms_drv.h"
#define DRIVER_NAME"vkms"
@@ -68,6 +70,7 @@ static struct drm_driver vkms_driver = {
};
static const struct drm_mode_config_funcs vkms_mode_funcs = {
+ .fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vkms: Add dumb operations
VKMS currently does not handle dumb data, and as a consequence, it does
not provide mechanisms for handling gem. This commit adds the necessary
support for gem object/handler and the dumb functions.
Signed-off-by: Rodrigo Siqueira
---
drivers/gpu/drm/vkms/Makefile | 2 +-
drivers/gpu/drm/vkms/vkms_drv.c | 9 ++
drivers/gpu/drm/vkms/vkms_drv.h | 21
drivers/gpu/drm/vkms/vkms_gem.c | 168
4 files changed, 199 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_gem.c
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 3f774a6a9c58..986297da51bf 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -1,3 +1,3 @@
-vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o
+vkms-y := vkms_drv.o vkms_plane.o vkms_output.o vkms_crtc.o vkms_gem.o
obj-$(CONFIG_DRM_VKMS) += vkms.o
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 740a4cbfed91..638bab9083b5 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -37,6 +37,12 @@ static const struct file_operations vkms_driver_fops = {
.release= drm_release,
};
+static const struct vm_operations_struct vkms_gem_vm_ops = {
+ .fault = vkms_gem_fault,
+ .open = drm_gem_vm_open,
+ .close = drm_gem_vm_close,
+};
+
static void vkms_release(struct drm_device *dev)
{
struct vkms_device *vkms = container_of(dev, struct vkms_device, drm);
@@ -50,6 +56,9 @@ static struct drm_driver vkms_driver = {
.driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
.release= vkms_release,
.fops = _driver_fops,
+ .dumb_create= vkms_dumb_create,
+ .dumb_map_offset= vkms_dumb_map,
+ .gem_vm_ops = _gem_vm_ops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index b0f9d2e61a42..54bb3dd2b2c1 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -3,6 +3,7 @@
#include
#include
+#include
#include
static const u32 vkms_formats[] = {
@@ -21,6 +22,12 @@ struct vkms_device {
struct vkms_output output;
};
+struct vkms_gem_object {
+ struct drm_gem_object gem;
+ struct mutex pages_lock; /* Page lock used in page fault handler */
+ struct page **pages;
+};
+
int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor);
@@ -28,4 +35,18 @@ int vkms_output_init(struct vkms_device *vkmsdev);
struct drm_plane *vkms_plane_init(struct vkms_device *vkmsdev);
+/* Gem stuff */
+struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
+ struct drm_file *file,
+ u32 *handle,
+ u64 size);
+
+int vkms_gem_fault(struct vm_fault *vmf);
+
+int vkms_dumb_create(struct drm_file *file, struct drm_device *dev,
+struct drm_mode_create_dumb *args);
+
+int vkms_dumb_map(struct drm_file *file, struct drm_device *dev,
+ u32 handle, u64 *offset);
+
#endif /* _VKMS_DRV_H_ */
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
new file mode 100644
index ..9f820f56b9e0
--- /dev/null
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+
+#include "vkms_drv.h"
+
+static struct vkms_gem_object *__vkms_gem_create(struct drm_device *dev,
+u64 size)
+{
+ struct vkms_gem_object *obj;
+ int ret;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ size = roundup(size, PAGE_SIZE);
+ ret = drm_gem_object_init(dev, >gem, size);
+ if (ret) {
+ kfree(obj);
+ return ERR_PTR(ret);
+ }
+
+ mutex_init(>pages_lock);
+
+ return obj;
+}
+
+int vkms_gem_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct vkms_gem_object *obj = vma->vm_private_data;
+ unsigned long vaddr = vmf->address;
+ pgoff_t page_offset;
+ loff_t num_pages;
+ int ret;
+
+ page_offset = (vaddr - vma->vm_start) >> PAGE_SHIFT;
+ num_pages = DIV_ROUND_UP(obj->gem.size, PAGE_SIZE);
+
+ if (page_offset > num_pages)
+ return VM_FAULT_SIGBUS;
+
+ ret = -ENOENT;
+
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #20 from Alex Deucher --- It's a bug in new gcc. You can apply this patch as a workaround: https://github.com/torvalds/linux/commit/854e55ad289efe7991f0ada85d5846f5afb9#diff-0b8e91d818ef68ac30763b79d9fabbad -- 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 105339] Deadlock inside glClientWaitSync [Regresion bc65dcab3bc48673ff6180afb036561a4b8b1119]
https://bugs.freedesktop.org/show_bug.cgi?id=105339 Marek Olšák changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Marek Olšák --- I think this one is fixed by: commit 7083ac7290a0c37a45494437a45441112f3cc36c Author: Marek Olšák Date: Tue Apr 24 17:01:35 2018 -0400 util/u_queue: fix a deadlock in util_queue_finish Cc: 18.0 18.1 Reviewed-by: Nicolai Hähnle Feel free to reopen if you encounter the issue again. -- 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 6/7] anv: add VK_EXT_display_control to anv driver [v2]
On Tue, Jun 19, 2018 at 10:31 PM, Keith Packard wrote: > Jason Ekstrand writes: > > >> + if (allocator) > >> + alloc = allocator; > >> + else > >> + alloc = >instance->alloc; > >> > > > > This is what vk_alloc2 is for. :-) > ... > > And vk_free2 > ... > > This isn't needed if you're using vk_alloc2 > > Yeah, but I need to pass the allocator down to the wsi common code, and > that doesn't have any way to touch the device driver allocator > pointer. I bet I'm just missing something here. Help? > I believe that the WSI common code should be capable of fishing the instance allocator out of the wsi_display so we need only pass the allocator argument unmodified through to the core WSI code. Make sense? Yeah, Vulkan allocator fishing is weird. --Jason ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #19 from SET --- It's the same error for every commit I had to skip : ../lib/str_error_r.c:25:3: error: passing argument 1 to restrict-qualified parameter aliases with argument 5 [-Werror=restrict] snprintf(buf, buflen, "INTERNAL ERROR: strerror_r(%d, %p, %zd)=%d", errnum, buf, buflen, err); ^~~~ cc1 : all warnings are treated as errors (this line is translated by me) -- 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: [DPU PATCH 2/5] drm/msm/dpu: enable cursor plane for primary crtc
On Wed, Jun 20, 2018 at 12:29 PM, wrote:
> On 2018-06-20 19:18, Rob Clark wrote:
>>
>> On Wed, Jun 20, 2018 at 8:50 AM, Sravanthi Kollukuduru
>> wrote:
>>>
>>> Reserve one DMA pipe as cursor plane and also, update crtc
>>> support of cursor in crtc_init.
>>
>>
>> hmm, mdp5 in 820 had real cursor planes in hw, did these go away? If
>> so I guess DMA plane is best candidate for cursor..
>
> Hi Rob,
> Yes, the hw cursor support is not present on sdm845.
> The ozone compositor expects cursor planes to be present otherwise cursor is
> not rendered on screen.
> So, we are planning to use one of the DMA pipe for cursor plane.
ok, makes sense
BR,
-R
> Thanks,
> Rajesh
>
>>
>> BR,
>> -R
>>
>>>
>>> Signed-off-by: Sravanthi Kollukuduru
>>> ---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 ++--
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 +-
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53
>>> +++---
>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 7 +++-
>>> 4 files changed, 34 insertions(+), 36 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> index f0aafec..56f6576 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
>>> @@ -2027,7 +2027,8 @@ static int _dpu_crtc_init_events(struct dpu_crtc
>>> *dpu_crtc)
>>> }
>>>
>>> /* initialize crtc */
>>> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
>>> *plane)
>>> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
>>> *plane,
>>> + struct drm_plane
>>> *cursor_plane)
>>> {
>>> struct drm_crtc *crtc = NULL;
>>> struct dpu_crtc *dpu_crtc = NULL;
>>> @@ -2061,8 +2062,8 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
>>> *dev, struct drm_plane *plane)
>>> dpu_crtc_frame_event_work);
>>> }
>>>
>>> - drm_crtc_init_with_planes(dev, crtc, plane, NULL,
>>> _crtc_funcs,
>>> - NULL);
>>> + drm_crtc_init_with_planes(dev, crtc, plane,
>>> + cursor_plane, _crtc_funcs, NULL);
>>>
>>> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>>> plane->crtc = crtc;
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> index 50c3d4b..b44750d 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
>>> @@ -366,7 +366,8 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
>>> * @plane: base plane
>>> * @Return: new crtc object or error
>>> */
>>> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
>>> *plane);
>>> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
>>> *plane,
>>> + struct drm_plane *cursor_plane);
>>>
>>> /**
>>> * dpu_crtc_cancel_pending_flip - complete flip for clients on lastclose
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> index f0c2881..c0b8116 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> @@ -29,6 +29,9 @@
>>> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
>>> BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>>>
>>> +#define DMA_CURSOR_SDM845_MASK \
>>> + (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
>>> +
>>> #define MIXER_SDM845_MASK \
>>> (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
>>>
>>> @@ -169,45 +172,35 @@
>>> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 =
>>> _DMA_SBLK("10");
>>> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 =
>>> _DMA_SBLK("11");
>>>
>>> -#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
>>> - { \
>>> - .name = _name, .id = _id, \
>>> - .base = _base, .len = 0x1c8, \
>>> - .features = VIG_SDM845_MASK, \
>>> - .sblk = &_sblk, \
>>> - .xin_id = _xinid, \
>>> - .type = SSPP_TYPE_VIG, \
>>> - .clk_ctrl = _clkctrl \
>>> - }
>>> -
>>> -#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
>>> +#define SSPP_BLK(_name, _id, _base, _features, \
>>> + _sblk, _xinid, _type, _clkctrl) \
>>> { \
>>> .name = _name, .id = _id, \
>>> .base = _base, .len = 0x1c8, \
>>> - .features = DMA_SDM845_MASK, \
>>> + .features = _features, \
>>> .sblk = &_sblk, \
>>> .xin_id = _xinid, \
>>> - .type = SSPP_TYPE_DMA, \
>>> + .type = _type, \
>>> .clk_ctrl = _clkctrl \
>>> }
>>>
>>> static struct dpu_sspp_cfg sdm845_sspp[] = {
>>> - SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
>>> - sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
>>> - SSPP_VIG_BLK("sspp_1",
Re: [PATCH] drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build
Quoting Koenig, Christian (2018-06-20 17:28:33)
>
>
> Am 20.06.2018 18:22 schrieb Chris Wilson :
>
> Fix i915's CI build after the removal of the dmabuf->kmap interface that
> left the mock routines intact.
>
> In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
> drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
> ‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function]
> static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned
> long page_num, void *addr)
> drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error:
> ‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function]
> static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned
> long page_num)
>
> Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
> Signed-off-by: Chris Wilson
>
>
> Reviewed-by: Christian König
>
> And sorry for the noise,
No worries, pushed to drm-misc-next, and so this never happened.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106979] Cannot suspend system with Radeon RX550 [1002:699f] , kernel 4.17.0-0.rc7.git2.2.fc29
https://bugs.freedesktop.org/show_bug.cgi?id=106979 Michel Dänzer changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Michel Dänzer --- Should be fixed by commit bc13f2f88eae63af943ab967cb14bb602f8f2eeb "drm/amd/display: Update color props when modeset is required". -- 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: [DPU PATCH 2/5] drm/msm/dpu: enable cursor plane for primary crtc
On 2018-06-20 19:18, Rob Clark wrote:
On Wed, Jun 20, 2018 at 8:50 AM, Sravanthi Kollukuduru
wrote:
Reserve one DMA pipe as cursor plane and also, update crtc
support of cursor in crtc_init.
hmm, mdp5 in 820 had real cursor planes in hw, did these go away? If
so I guess DMA plane is best candidate for cursor..
Hi Rob,
Yes, the hw cursor support is not present on sdm845.
The ozone compositor expects cursor planes to be present otherwise
cursor is not rendered on screen.
So, we are planning to use one of the DMA pipe for cursor plane.
Thanks,
Rajesh
BR,
-R
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53
+++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 7 +++-
4 files changed, 34 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f0aafec..56f6576 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2027,7 +2027,8 @@ static int _dpu_crtc_init_events(struct dpu_crtc
*dpu_crtc)
}
/* initialize crtc */
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct
drm_plane *plane)
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct
drm_plane *plane,
+ struct drm_plane
*cursor_plane)
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
@@ -2061,8 +2062,8 @@ struct drm_crtc *dpu_crtc_init(struct drm_device
*dev, struct drm_plane *plane)
dpu_crtc_frame_event_work);
}
- drm_crtc_init_with_planes(dev, crtc, plane, NULL,
_crtc_funcs,
- NULL);
+ drm_crtc_init_with_planes(dev, crtc, plane,
+ cursor_plane, _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
plane->crtc = crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 50c3d4b..b44750d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -366,7 +366,8 @@ void dpu_crtc_complete_commit(struct drm_crtc
*crtc,
* @plane: base plane
* @Return: new crtc object or error
*/
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct
drm_plane *plane);
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct
drm_plane *plane,
+ struct drm_plane *cursor_plane);
/**
* dpu_crtc_cancel_pending_flip - complete flip for clients on
lastclose
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index f0c2881..c0b8116 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -29,6 +29,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define DMA_CURSOR_SDM845_MASK \
+ (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
+
#define MIXER_SDM845_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
@@ -169,45 +172,35 @@
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 =
_DMA_SBLK("10");
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 =
_DMA_SBLK("11");
-#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
- { \
- .name = _name, .id = _id, \
- .base = _base, .len = 0x1c8, \
- .features = VIG_SDM845_MASK, \
- .sblk = &_sblk, \
- .xin_id = _xinid, \
- .type = SSPP_TYPE_VIG, \
- .clk_ctrl = _clkctrl \
- }
-
-#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
+#define SSPP_BLK(_name, _id, _base, _features, \
+ _sblk, _xinid, _type, _clkctrl) \
{ \
.name = _name, .id = _id, \
.base = _base, .len = 0x1c8, \
- .features = DMA_SDM845_MASK, \
+ .features = _features, \
.sblk = &_sblk, \
.xin_id = _xinid, \
- .type = SSPP_TYPE_DMA, \
+ .type = _type, \
.clk_ctrl = _clkctrl \
}
static struct dpu_sspp_cfg sdm845_sspp[] = {
- SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
- sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
- SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
- sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
- SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
- sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
- SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
- sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
- SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
- sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
- SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
- sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
-
Re: [PATCH] drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build
Am 20.06.2018 18:22 schrieb Chris Wilson :
Fix i915's CI build after the removal of the dmabuf->kmap interface that
left the mock routines intact.
In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function]
static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error:
‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function]
static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Chris Wilson
Reviewed-by: Christian König
And sorry for the noise,
Christian.
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
---
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
index f81fda8ea45e..ca682caf1062 100644
--- a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
@@ -94,18 +94,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
}
-static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kmap_atomic(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- kunmap_atomic(addr);
-}
-
static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
{
struct mock_dmabuf *mock = to_mock(dma_buf);
--
2.18.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/selftests: Remove unused dmabuf->kmap routines, fix the build
Fix i915's CI build after the removal of the dmabuf->kmap interface that
left the mock routines intact.
In file included from drivers/gpu/drm/i915/i915_gem_dmabuf.c:335:0:
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:104:13: error:
‘mock_dmabuf_kunmap_atomic’ defined but not used [-Werror=unused-function]
static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
drivers/gpu/drm/i915/selftests/mock_dmabuf.c:97:14: error:
‘mock_dmabuf_kmap_atomic’ defined but not used [-Werror=unused-function]
static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
Fixes: f664a5269542 ("dma-buf: remove kmap_atomic interface")
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
---
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
index f81fda8ea45e..ca682caf1062 100644
--- a/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/selftests/mock_dmabuf.c
@@ -94,18 +94,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
}
-static void *mock_dmabuf_kmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kmap_atomic(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap_atomic(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- kunmap_atomic(addr);
-}
-
static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
{
struct mock_dmabuf *mock = to_mock(dma_buf);
--
2.18.0.rc2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106979] Cannot suspend system with Radeon RX550 [1002:699f] , kernel 4.17.0-0.rc7.git2.2.fc29
https://bugs.freedesktop.org/show_bug.cgi?id=106979 --- Comment #1 from Adam Williamson --- Just noticed that kernel is a few weeks old, will re-test with 4.17 final and 4.18 RC shortly. -- 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 106979] Cannot suspend system with Radeon RX550 [1002:699f] , kernel 4.17.0-0.rc7.git2.2.fc29
https://bugs.freedesktop.org/show_bug.cgi?id=106979 Bug ID: 106979 Summary: Cannot suspend system with Radeon RX550 [1002:699f] , kernel 4.17.0-0.rc7.git2.2.fc29 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: ad...@happyassassin.net Yesterday I bought a Radeon RX550 adapter (PCI ID 1002:699f) to replace a dying GeForce for my desktop. It worked OK all day, but when I tried to suspend the system at the end of the day, it failed - the system was left running but unresponsive and had to be reset. Looking at the logs of the boot which ended with the failed suspend attempt, I see this: Jun 19 23:00:06 adam.happyassassin.net NetworkManager[1317]: [1529474406.7296] manager: sleep: sleep requested (sleeping: no enabled: yes) Jun 19 23:00:06 adam.happyassassin.net NetworkManager[1317]: [1529474406.7300] manager: NetworkManager state is now ASLEEP Jun 19 23:00:06 adam.happyassassin.net gnome-shell[1729]: Screen lock is locked down, not locking Jun 19 23:00:06 adam.happyassassin.net gnome-shell[1729]: Failed to set power save mode for output DP-1: Permission denied Jun 19 23:00:06 adam.happyassassin.net gnome-shell[1729]: Failed to set power save mode for output DVI-D-1: Permission denied Jun 19 23:00:07 adam.happyassassin.net kernel: [ cut here ] Jun 19 23:00:07 adam.happyassassin.net kernel: kernel BUG at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4708! ...and that's all - the trace I'd expect to follow the 'kernel BUG' line does not appear. This is on Fedora Rawhide with kernel 4.17.0-0.rc7.git2.2.fc29.x86_64 . The desktop is GNOME on Wayland, and I have two displays attached to the adapter, one via DVI and one via DisplayPort. -- 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 v11 1/5] dt-bindings: media: extend interface documentation for DSI and DP
On Fri, Jun 15, 2018 at 12:13:39PM +0530, Sandeep Panda wrote: > Properties like data-lanes, clock-noncontinuous and lane-polarities > are applicable to DSI and DisplayPort interface also. So update the > documentation to mention the same. > > Signed-off-by: Sandeep Panda > --- > Documentation/devicetree/bindings/media/video-interfaces.txt | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
Den 20.06.2018 15.52, skrev Noralf Trønnes:
Den 20.06.2018 11.34, skrev Daniel Vetter:
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote:
This patchset adds generic fbdev emulation for drivers that supports
GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.
Notable changes since version 1:
- Rework client unregister code. I've used reference counting to manage
the fact that both the client itself and the driver through
drm_dev_unregister() can release the client. The client is now
released
using drm_client_put() instead of drm_client_free().
I started reviewing the reworked client register/unregister stuff,
and it
looks good, except this kref stuff here for clients. I don't understand
why you need this - as long as removal from dev->clientlist is properly
protected by the mutex, I don't see how both the client and the
device can
release the client at the same time. Of course this means that both the
device-trigger unregister and the client-triggered unregister must first
grab the mutex, remove the client from the list, and only if that was
done
succesfully, clean up the client. If the client is already removed from
the list (i.e. list_empty() is true) then you need to bail out to avoid
double-freeing.
I just suck at this :/
Use case:
Unloading client module at the same time as the device is unplugged.
The client module calls drm_client_release():
void drm_client_release(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
mutex_lock(>clientlist_mutex);
list_del(>list);
drm_client_close(client);
mutex_unlock(>clientlist_mutex);
drm_dev_put(dev);
}
drm_device_unregister() calls drm_client_dev_unregister():
void drm_client_dev_unregister(struct drm_device *dev)
{
struct drm_client_dev *client;
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (client->funcs && client->funcs->unregister)
client->funcs->unregister(client);
else
drm_client_release(client);
}
mutex_unlock(>clientlist_mutex);
}
How do I do this without deadlocking and without operating on a
drm_client_dev structure that has been freed in the other codepath?
There's one more quirk that I forgot:
If fbdev can't release the client on .unregister due to open fd's, the
list entry should be removed but releasing resources is deferred to
the last fd being closed.
Noralf.
Noralf.
I don't think there's a need to use a kref here. And kref has the tricky
issue that you tempt everyone into constructing references loops between
drm_device and drm_client (which require lots of jumping through
hoops in
your v1 to make sure you can break those reference loops).
- fbdev: Use a shadow buffer for framebuffers that have a dirty
callback. This makes the fbdev client truly generic and useable
for all
drivers. There's a blitting penalty, but this is generic
emulation after
all. The reason for needing a shadow buffer is that deferred I/O
only
works with kmalloc/vmalloc buffers and not with shmem buffers
(page->lru/mapping).
Yeah I think that's the only feasible option. Everyone who cares more
about fbdev performance can keep their driver-specific code. And for
other
drm_client users this shouldn't be a problem, since they know how to use
dirty and flipping between multiple buffers to drive kms as it was
designed. The issue really only exists for fbdev's assumption of a
direct
mmap of a dumb framebuffer, encoded into the uapi.
- Let tinydrm use the full fbdev client
\o/
Cheers, Daniel
Noralf.
Changes since version 1:
- Make it possible to embed struct drm_client_dev and drop the private
pointer
- Use kref reference counting to control client release since both the
client and the driver can release.
- Add comment about using dma-buf as a possibility with some rework
- Move buffer NULL check to drm_client_framebuffer_delete()
- Move client name to struct drm_client_dev
- Move up drm_dev_get/put calls to make them more visible
- Move drm_client_dev.list definition to later patch that makes use
of it
- Embed drm_client at the beginning of drm_fb_helper to avoid a fragile
transitional kfree hack in drm_client_release()
- Set owner in drm_fbdev_fb_ops
- Add kerneldoc to drm_fb_helper_generic_probe()
- Remove unused functions
- Change name drm_client_funcs.lastclose -> .restore
- Change name drm_client_funcs.remove -> .unregister
- Rework unregister code
- tinydrm: Use drm_fbdev_generic_setup() and remove
drm_fb_cma_fbdev_init_with_funcs()
David Herrmann (1):
drm: provide management functions for drm_file
Noralf Trønnes (11):
drm/file: Don't set master on in-kernel clients
drm: Make ioctls available for in-kernel clients
drm: Begin an API for in-kernel clients
drm/fb-helper: Add generic fbdev emulation .fb_probe function
drm/pl111: Set
Re: [PATCH v4 04/26] docs: fix broken references with multiple hints
On Fri, Jun 15, 2018 at 01:30:32PM -0300, Mauro Carvalho Chehab wrote: > The script: > ./scripts/documentation-file-ref-check --fix > > Gives multiple hints for broken references on some files. > Manually use the one that applies for some files. > > Acked-by: Steven Rostedt (VMware) > Signed-off-by: Mauro Carvalho Chehab > --- > Documentation/ABI/obsolete/sysfs-gpio | 2 +- > .../devicetree/bindings/display/bridge/tda998x.txt| 2 +- Acked-by: Rob Herring > Documentation/trace/events.rst| 2 +- > Documentation/trace/tracepoint-analysis.rst | 2 +- > Documentation/translations/zh_CN/SubmittingDrivers| 2 +- > Documentation/translations/zh_CN/gpio.txt | 4 ++-- > MAINTAINERS | 2 +- > drivers/hid/usbhid/Kconfig| 2 +- > drivers/input/Kconfig | 4 ++-- > drivers/input/joystick/Kconfig| 4 ++-- > drivers/input/joystick/iforce/Kconfig | 4 ++-- > drivers/input/serio/Kconfig | 4 ++-- > drivers/staging/fsl-mc/bus/dpio/dpio-driver.txt | 2 +- > drivers/video/fbdev/skeletonfb.c | 8 > include/linux/tracepoint.h| 2 +- > security/device_cgroup.c | 2 +- > 16 files changed, 24 insertions(+), 24 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11 3/5] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings
On Fri, Jun 15, 2018 at 12:13:41PM +0530, Sandeep Panda wrote: > Document the bindings used for the sn65dsi86 DSI to eDP bridge. > > Changes in v1: > - Rephrase the dt-binding descriptions to be more inline with existing >bindings (Andrzej Hajda). > - Add missing dt-binding that are parsed by corresponding driver >(Andrzej Hajda). > > Changes in v2: > - Remove edp panel specific dt-binding entries. Only keep bridge >specific entries (Sean Paul). > - Remove custom-modes dt entry since its usage is removed from driver also > (Sean Paul). > - Remove is-pluggable dt entry since this will not be needed anymore (Sean > Paul). > > Changes in v3: > - Remove irq-gpio dt entry and instead populate is an interrupt >property (Rob Herring). > > Changes in v4: > - Add link to bridge chip datasheet (Stephen Boyd) > - Add vpll and vcc regulator supply bindings (Stephen Boyd) > - Add ref clk optional dt binding (Stephen Boyd) > - Add gpio-controller optional dt binding (Stephen Boyd) > > Changes in v5: > - Use clock property to specify the input refclk (Stephen Boyd). > - Update gpio cell and pwm cell numbers (Stephen Boyd). > > Changes in v6: > - Add property to mention the lane mapping scheme and polarity inversion >(Stephen Boyd). > > Changes in v7: > - Detail description of lane mapping scheme dt property (Andrzej >Hajda/ Rob Herring). > - Removed HDP gpio binding, since the bridge uses IRQ signal to >determine HPD, and IRQ property is already documented in binding. > > Changes in v8: > - Removed unnecessary explanation of lane mapping and polarity dt >property, since these are already explained in media/video-interface >dt binidng (Rob Herring). > > Changes in v9: > - Avoid putting re-definition of lane mapping and polarity dt binding >(Rob Herring). > > Signed-off-by: Sandeep Panda > --- > .../bindings/display/bridge/ti,sn65dsi86.txt | 87 > ++ > 1 file changed, 87 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #18 from Michel Dänzer --- What's the compile error you're getting with the current commit? -- 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: fix pci_dev root device is NULL without check.
On Wed, Jun 20, 2018 at 4:39 AM, Maarten Lankhorst wrote: > Op 19-06-18 om 09:47 schreef Caicai: >> on my laptop with ATI Radeon R7 350 graphics card,I found root was >> NULL,we should check >> the device before get/set pcie speed cap mask. Here is my messages. >> [8.996093] [drm] radeon kernel modesetting enabled. >> [8.996093] [drm] initializing kernel modesetting (OLAND >> 0x1002:0x6610 0x174B:0xA00B). >> [8.996093] [drm] register mmio base: 0x1000 >> [8.996093] [drm] register mmio size: 262144 >> [9.121093] ATOM BIOS: C55001 >> [9.121093] [drm] GPU not posted. posting now... >> [9.125000] radeon 0001:20:00.0: VRAM: 2048M 0x - >> 0x7FFF (2048M used) >> [9.125000] radeon 0001:20:00.0: GTT: 2048M 0x8000 - >> 0x >> [9.125000] [drm] Detected VRAM RAM=2048M, BAR=256M >> [9.125000] [drm] RAM width 128bits DDR >> [9.125000] [drm] radeon: 2048M of VRAM memory ready >> [9.125000] [drm] radeon: 2048M of GTT memory ready. >> [9.125000] [drm] Loading oland Microcode >> [9.128906] [drm] Internal thermal controller with fan control >> [9.128906] Unable to handle kernel paging request at virtual address >> 003c >> [9.128906] CPU 3 systemd-udevd(148): Oops 0 >> [9.128906] pc = [] ra = [] ps >> = Not tainted >> [9.128906] pc is at drm_pcie_get_speed_cap_mask+0x3c/0x12c >> [9.128906] ra is at si_dpm_init+0x64/0x1398 [radeon] >> [9.128906] v0 = ffea t0 = fc07fcc3a400 t1 = >> 1106 >> [9.128906] t2 = 1166 t3 = t4 = >> fc018eafc000 >> [9.128906] t5 = ff80 t6 = 003f t7 = >> fc07f6a9 >> [9.128906] s0 = fc07f6a9390c s1 = s2 = >> fc07f59119b0 >> [9.128906] s3 = 0001 s4 = fff4 s5 = >> fc07f591 >> [9.128906] s6 = >> [9.128906] a0 = fc07f706c800 a1 = fc07f6a9390c a2 = >> fffc >> [9.128906] a3 = 815fb510 a4 = 815fb4c8 a5 = >> >> [9.128906] t8 = 007f t9 = 80d86c14 t10= >> 0001 >> [9.128906] t11= 03c0 pv = 80e637e8 at = >> >> [9.128906] gp = 815e9230 sp = fc07f6a93868 >> [9.128906] Disabling lock debugging due to kernel taint >> [9.128906] Trace: >> [9.128906] [] drm_dev_register+0xb0/0x138 >> [9.128906] [] drm_get_pci_dev+0x120/0x208 >> [9.128906] [] local_pci_probe+0x38/0x8c >> [9.128906] [] pci_device_probe+0x170/0x1d0 >> [9.128906] [] driver_probe_device+0x168/0x2fc >> [9.128906] [] __driver_attach+0x94/0xe8 >> [9.128906] [] bus_for_each_dev+0x94/0xd4 >> [9.128906] [] __driver_attach+0x0/0xe8 >> [9.128906] [] driver_attach+0x2c/0x40 >> [9.128906] [] bus_add_driver+0x140/0x2d4 >> [9.128906] [] driver_register+0x100/0x180 >> [9.128906] [] __pci_register_driver+0x48/0x5c >> [9.128906] [] drm_pci_init+0x7c/0x168 >> [9.128906] [] do_one_initcall+0x188/0x25c >> [9.128906] [] do_init_module+0x8c/0x2c8 >> [9.128906] [] kmem_cache_alloc+0x1f8/0x22c >> [9.128906] [] do_init_module+0x40/0x2c8 >> [9.128906] [] load_module+0x1ea8/0x263c >> [9.128906] [] unknown_module_param_cb+0x0/0xc8 >> [9.128906] [] SYSC_finit_module+0x94/0xb4 >> [9.128906] [] module_notes_read+0x0/0x4c >> [9.128906] [] entSys+0xa0/0xc0 > Grepping on entSys the only mention is on alpha. > > Is dev->pdev->bus->parent NULL by any chance? >> [9.128906] Code: 8c300188 c020003b 8c210010 f85f1106 f87f1166 >> 8d410038 <842a003c> 40220502 >> [9.128906] systemd-udevd[136]: worker [148] terminated by signal 11 >> (Segmentation fault) >> >> Signed-off-by: Caicai >> --- >> drivers/gpu/drm/drm_pci.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c >> index 4db9c515b74f..3d1cd760b79c 100644 >> --- a/drivers/gpu/drm/drm_pci.c >> +++ b/drivers/gpu/drm/drm_pci.c >> @@ -332,10 +332,12 @@ int drm_pcie_get_speed_cap_mask(struct drm_device >> *dev, u32 *mask) >> u32 lnkcap, lnkcap2; >> >> *mask = 0; >> - if (!dev->pdev) >> + if (!dev->pdev || !dev->pdev->bus) >> return -EINVAL; > I think we can assume our device is on a bus. >> root = dev->pdev->bus->self; >> + if (!root) >> + return -EINVAL; > I'm not a PCI expert, but seems like a bad design to say none of the speeds > are supported just because we lack a bridge. > > btw, drm_pcie_get_max_link_width is similarly affected. Is the VM
Re: [PATCH 2/5] dma-buf: remove kmap_atomic interface
Am 20.06.2018 um 16:04 schrieb Christian König: Am 20.06.2018 um 14:52 schrieb Daniel Vetter: On Wed, Jun 20, 2018 at 2:46 PM, Christian König wrote: [SNIP] Go ahead, that's the point of commit rights. dim might complain if you cherry picked them and didn't pick them up using dim apply though ... I've fixed up the Link tags, but when I try "dim push-branch drm-misc-next" I only get the error message "error: dst ref refs/heads/drm-misc-next receives from more than one src." Any idea what is going wrong here? Sounds like multiple upstreams for your local drm-misc-next branch, and git then can't decide which one to pick. If you delete the branch and create it using dim checkout drm-misc-next this shouldn't happen. We're trying to fit into existing check-outs and branches, but if you set things up slightly different than dim would have you're off script and there's limited support for that. Alternative check out your .git/config and remove the other upstreams. Or attach your git config if this isn't the issue (I'm just doing some guessing here). I've tried to delete my drm-misc-next branch and recreate it, but that doesn't seem to help. Attached is my .git/config, but at least on first glance it looks ok as well. Any ideas? Ok that seems to be a bug in dim. "bash -x dim push drm-misc-next" looks like it tries to push the branch drm-misc-next twice to the drm-misc remote: git push drm-misc drm-misc-next drm-misc-next When I try that manually I get the same result, but "git push drm-misc drm-misc-next" just seemed to work fine. Let's hope that I haven't messed things up totally on the server now. Christian. Thanks, Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106363] Powerplay support for SI asics
https://bugs.freedesktop.org/show_bug.cgi?id=106363 --- Comment #5 from Alex Deucher --- (In reply to Gregor Münch from comment #4) > (In reply to Alex Deucher from comment #3) > > dpm is enabled by default on SI parts so setting dpm=1 doesn't change > > anything. > > This depends if you use amdgpu instead of radeon on SI. In that case > amdgpu.dpm seems to be disabled. nope. dpm is enabled by default on both radeon and amdgpu. > I tried to enable DPMS and read through a bunch of tutorials configuring > Xorg but nothing did work. DPMS is not related to dpm at all. > Then I stumbled about a newsentry on phoronix mentioned this patch: > https://lists.freedesktop.org/archives/amd-gfx/2018-May/022771.html > There you change the behavior for CIK parts to use PP by default. The logic > of this patch changes amdgpu.dpm=-1 (auto) to switch from whatever to > Powerplay. This change applies to CIK only not SI. > > > I started my Kernel with amdgpu.dpm=1 and everything suddenly worked like > magic. > > Since I dont what Powerplay actually does in the Linux world and a quick > google search came up with nothing and modinfo amdgpu just reveils > dpm:DPM support (1 = enable, 0 = disable, -1 = auto) (int) > but nothing about Powerplay I was really under the impression that DPM also > enables Powerplay. > Im sorry for the confusion. dpm and powerplay are just two sw implementations of the same hardware functionality. CIK and VI share the same SMU IP so they can share most of the power code. SI uses an old SMU block and can't share the code so it still uses the dpm implementation originally ported from radeon. -- 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 2/5] dma-buf: remove kmap_atomic interface
Am 20.06.2018 um 14:52 schrieb Daniel Vetter: On Wed, Jun 20, 2018 at 2:46 PM, Christian König wrote: [SNIP] Go ahead, that's the point of commit rights. dim might complain if you cherry picked them and didn't pick them up using dim apply though ... I've fixed up the Link tags, but when I try "dim push-branch drm-misc-next" I only get the error message "error: dst ref refs/heads/drm-misc-next receives from more than one src." Any idea what is going wrong here? Sounds like multiple upstreams for your local drm-misc-next branch, and git then can't decide which one to pick. If you delete the branch and create it using dim checkout drm-misc-next this shouldn't happen. We're trying to fit into existing check-outs and branches, but if you set things up slightly different than dim would have you're off script and there's limited support for that. Alternative check out your .git/config and remove the other upstreams. Or attach your git config if this isn't the issue (I'm just doing some guessing here). I've tried to delete my drm-misc-next branch and recreate it, but that doesn't seem to help. Attached is my .git/config, but at least on first glance it looks ok as well. Any ideas? Thanks, Christian. -Daniel [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [remote "drm-tip"] url = ssh://git.freedesktop.org/git/drm-tip fetch = +refs/heads/*:refs/remotes/drm-tip/* [branch "maintainer-tools"] remote = drm-tip merge = refs/heads/maintainer-tools [branch "rerere-cache"] remote = drm-tip merge = refs/heads/rerere-cache [branch "drm-tip"] remote = drm-tip merge = refs/heads/drm-tip [remote "airlied"] url = git://people.freedesktop.org/~airlied/linux fetch = +refs/heads/*:refs/remotes/airlied/* [remote "sound"] url = git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git fetch = +refs/heads/*:refs/remotes/sound/* [remote "drm-intel"] url = ssh://git.freedesktop.org/git/drm/drm-intel fetch = +refs/heads/*:refs/remotes/drm-intel/* [remote "drm-amd"] url = ssh://git.freedesktop.org/git/drm/drm-amd fetch = +refs/heads/*:refs/remotes/drm-amd/* [remote "drm"] url = ssh://git.freedesktop.org/git/drm/drm fetch = +refs/heads/*:refs/remotes/drm/* [remote "drm-misc"] url = ssh://git.freedesktop.org/git/drm/drm-misc fetch = +refs/heads/*:refs/remotes/drm-misc/* [remote "baker"] url = ssh://baker.local/usr/src/linux fetch = +refs/heads/*:refs/remotes/baker/* [branch "drm-misc-next"] remote = drm-misc merge = refs/heads/drm-misc-next ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
Den 20.06.2018 11.34, skrev Daniel Vetter:
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote:
This patchset adds generic fbdev emulation for drivers that supports GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.
Notable changes since version 1:
- Rework client unregister code. I've used reference counting to manage
the fact that both the client itself and the driver through
drm_dev_unregister() can release the client. The client is now released
using drm_client_put() instead of drm_client_free().
I started reviewing the reworked client register/unregister stuff, and it
looks good, except this kref stuff here for clients. I don't understand
why you need this - as long as removal from dev->clientlist is properly
protected by the mutex, I don't see how both the client and the device can
release the client at the same time. Of course this means that both the
device-trigger unregister and the client-triggered unregister must first
grab the mutex, remove the client from the list, and only if that was done
succesfully, clean up the client. If the client is already removed from
the list (i.e. list_empty() is true) then you need to bail out to avoid
double-freeing.
I just suck at this :/
Use case:
Unloading client module at the same time as the device is unplugged.
The client module calls drm_client_release():
void drm_client_release(struct drm_client_dev *client)
{
struct drm_device *dev = client->dev;
mutex_lock(>clientlist_mutex);
list_del(>list);
drm_client_close(client);
mutex_unlock(>clientlist_mutex);
drm_dev_put(dev);
}
drm_device_unregister() calls drm_client_dev_unregister():
void drm_client_dev_unregister(struct drm_device *dev)
{
struct drm_client_dev *client;
mutex_lock(>clientlist_mutex);
list_for_each_entry(client, >clientlist, list) {
if (client->funcs && client->funcs->unregister)
client->funcs->unregister(client);
else
drm_client_release(client);
}
mutex_unlock(>clientlist_mutex);
}
How do I do this without deadlocking and without operating on a
drm_client_dev structure that has been freed in the other codepath?
Noralf.
I don't think there's a need to use a kref here. And kref has the tricky
issue that you tempt everyone into constructing references loops between
drm_device and drm_client (which require lots of jumping through hoops in
your v1 to make sure you can break those reference loops).
- fbdev: Use a shadow buffer for framebuffers that have a dirty
callback. This makes the fbdev client truly generic and useable for all
drivers. There's a blitting penalty, but this is generic emulation after
all. The reason for needing a shadow buffer is that deferred I/O only
works with kmalloc/vmalloc buffers and not with shmem buffers
(page->lru/mapping).
Yeah I think that's the only feasible option. Everyone who cares more
about fbdev performance can keep their driver-specific code. And for other
drm_client users this shouldn't be a problem, since they know how to use
dirty and flipping between multiple buffers to drive kms as it was
designed. The issue really only exists for fbdev's assumption of a direct
mmap of a dumb framebuffer, encoded into the uapi.
- Let tinydrm use the full fbdev client
\o/
Cheers, Daniel
Noralf.
Changes since version 1:
- Make it possible to embed struct drm_client_dev and drop the private
pointer
- Use kref reference counting to control client release since both the
client and the driver can release.
- Add comment about using dma-buf as a possibility with some rework
- Move buffer NULL check to drm_client_framebuffer_delete()
- Move client name to struct drm_client_dev
- Move up drm_dev_get/put calls to make them more visible
- Move drm_client_dev.list definition to later patch that makes use of it
- Embed drm_client at the beginning of drm_fb_helper to avoid a fragile
transitional kfree hack in drm_client_release()
- Set owner in drm_fbdev_fb_ops
- Add kerneldoc to drm_fb_helper_generic_probe()
- Remove unused functions
- Change name drm_client_funcs.lastclose -> .restore
- Change name drm_client_funcs.remove -> .unregister
- Rework unregister code
- tinydrm: Use drm_fbdev_generic_setup() and remove
drm_fb_cma_fbdev_init_with_funcs()
David Herrmann (1):
drm: provide management functions for drm_file
Noralf Trønnes (11):
drm/file: Don't set master on in-kernel clients
drm: Make ioctls available for in-kernel clients
drm: Begin an API for in-kernel clients
drm/fb-helper: Add generic fbdev emulation .fb_probe function
drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
drm/cma-helper: Use the generic fbdev emulation
drm/client: Add client callbacks
drm/debugfs: Add internal client debugfs file
drm/fb-helper: Finish the generic fbdev emulation
drm/tinydrm: Use drm_fbdev_generic_setup()
Re: [DPU PATCH 2/5] drm/msm/dpu: enable cursor plane for primary crtc
On Wed, Jun 20, 2018 at 8:50 AM, Sravanthi Kollukuduru
wrote:
> Reserve one DMA pipe as cursor plane and also, update crtc
> support of cursor in crtc_init.
hmm, mdp5 in 820 had real cursor planes in hw, did these go away? If
so I guess DMA plane is best candidate for cursor..
BR,
-R
>
> Signed-off-by: Sravanthi Kollukuduru
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 ++--
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53
> +++---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 7 +++-
> 4 files changed, 34 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index f0aafec..56f6576 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -2027,7 +2027,8 @@ static int _dpu_crtc_init_events(struct dpu_crtc
> *dpu_crtc)
> }
>
> /* initialize crtc */
> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane)
> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> + struct drm_plane
> *cursor_plane)
> {
> struct drm_crtc *crtc = NULL;
> struct dpu_crtc *dpu_crtc = NULL;
> @@ -2061,8 +2062,8 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
> struct drm_plane *plane)
> dpu_crtc_frame_event_work);
> }
>
> - drm_crtc_init_with_planes(dev, crtc, plane, NULL, _crtc_funcs,
> - NULL);
> + drm_crtc_init_with_planes(dev, crtc, plane,
> + cursor_plane, _crtc_funcs, NULL);
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> plane->crtc = crtc;
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> index 50c3d4b..b44750d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
> @@ -366,7 +366,8 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
> * @plane: base plane
> * @Return: new crtc object or error
> */
> -struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane);
> +struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
> *plane,
> + struct drm_plane *cursor_plane);
>
> /**
> * dpu_crtc_cancel_pending_flip - complete flip for clients on lastclose
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index f0c2881..c0b8116 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -29,6 +29,9 @@
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>
> +#define DMA_CURSOR_SDM845_MASK \
> + (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
> +
> #define MIXER_SDM845_MASK \
> (BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
>
> @@ -169,45 +172,35 @@
> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10");
> static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11");
>
> -#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
> - { \
> - .name = _name, .id = _id, \
> - .base = _base, .len = 0x1c8, \
> - .features = VIG_SDM845_MASK, \
> - .sblk = &_sblk, \
> - .xin_id = _xinid, \
> - .type = SSPP_TYPE_VIG, \
> - .clk_ctrl = _clkctrl \
> - }
> -
> -#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
> +#define SSPP_BLK(_name, _id, _base, _features, \
> + _sblk, _xinid, _type, _clkctrl) \
> { \
> .name = _name, .id = _id, \
> .base = _base, .len = 0x1c8, \
> - .features = DMA_SDM845_MASK, \
> + .features = _features, \
> .sblk = &_sblk, \
> .xin_id = _xinid, \
> - .type = SSPP_TYPE_DMA, \
> + .type = _type, \
> .clk_ctrl = _clkctrl \
> }
>
> static struct dpu_sspp_cfg sdm845_sspp[] = {
> - SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
> - sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
> - SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
> - sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
> - SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
> - sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
> - SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
> - sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
> - SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
> - sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
> - SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
> - sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
> - SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
> - sdm845_dma_sblk_2,
[PATCH][next] drm/i915/psr: fix copy-paste error with setting of tp2_wakeup_time_us
From: Colin Ian King
Currently for the psr_table->tp2_tp3_wakeup_time case 3 there appears
to be a copy-paste error from the previous switch statement where
dev_priv->vbt.psr.tp1_wakeup_time_us is being assigned and I believe
it should be dev_priv->vbt.psr.tp2_tp3_wakeup_time_us that should be
assigned instead.
Detected by CoverityScan, CID#1470105 ("Copy-paste error")
Fixes: 77312ae8f071 ("drm/i915/psr: vbt change for psr")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/intel_bios.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 03f04b472394..e0a14be1080a 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -740,7 +740,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
break;
case 3:
- dev_priv->vbt.psr.tp1_wakeup_time_us = 0;
+ dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
break;
default:
DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
outside range[0-3], defaulting to max value 2500us\n",
--
2.17.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: Fix comparison operator for buffer size
Here we are checking for the buffer length, not an offset for writing
to, so using > is correct. The current code incorrectly rejects a
command buffer ending at the memory buffer's end.
Signed-off-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 776c1513e582..a2bd5876c633 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -398,7 +398,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
* unaligned offset is malformed and cause commands stream
* corruption on the buffer address relocation.
*/
- if (offset & 3 || offset >= obj->gem.size) {
+ if (offset & 3 || offset > obj->gem.size) {
err = -EINVAL;
goto fail;
}
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/5] dma-buf: remove kmap_atomic interface
On Wed, Jun 20, 2018 at 2:46 PM, Christian König
wrote:
> Am 19.06.2018 um 17:35 schrieb Daniel Vetter:
>>
>> On Tue, Jun 19, 2018 at 4:47 PM, Christian König
>> wrote:
>>>
>>> Am 18.06.2018 um 10:18 schrieb Daniel Vetter:
On Fri, Jun 01, 2018 at 02:00:17PM +0200, Christian König wrote:
>
> Neither used nor correctly implemented anywhere. Just completely remove
> the interface.
>
> Signed-off-by: Christian König
I wonder whether we can nuke the normal kmap stuff too ... everyone
seems
to want/use the vmap stuff for kernel-internal mapping needs.
Anyway, this looks good.
>
> ---
>drivers/dma-buf/dma-buf.c | 44
> --
>drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -
>drivers/gpu/drm/armada/armada_gem.c| 2 -
>drivers/gpu/drm/drm_prime.c| 26
> -
>drivers/gpu/drm/i915/i915_gem_dmabuf.c | 11 --
>drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 2 -
>drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 -
>drivers/gpu/drm/tegra/gem.c| 14 ---
>drivers/gpu/drm/udl/udl_dmabuf.c | 17 -
>drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 13 ---
>.../media/common/videobuf2/videobuf2-dma-contig.c | 1 -
>drivers/media/common/videobuf2/videobuf2-dma-sg.c | 1 -
>drivers/media/common/videobuf2/videobuf2-vmalloc.c | 1 -
>drivers/staging/android/ion/ion.c | 2 -
>drivers/tee/tee_shm.c | 6 ---
>include/drm/drm_prime.h| 4 --
>include/linux/dma-buf.h| 4 --
>17 files changed, 152 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index e99a8d19991b..e4c657d9fad7 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct
> dma_buf_export_info *exp_info)
>|| !exp_info->ops->map_dma_buf
>|| !exp_info->ops->unmap_dma_buf
>|| !exp_info->ops->release
> - || !exp_info->ops->map_atomic
>|| !exp_info->ops->map
>|| !exp_info->ops->mmap)) {
> return ERR_PTR(-EINVAL);
> @@ -687,14 +686,6 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
> * void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
> * void dma_buf_kunmap(struct dma_buf \*, unsigned long, void
> \*);
> *
> - * There are also atomic variants of these interfaces. Like for kmap
> they
> - * facilitate non-blocking fast-paths. Neither the importer nor the
> exporter
> - * (in the callback) is allowed to block when using these.
> - *
> - * Interfaces::
> - * void \*dma_buf_kmap_atomic(struct dma_buf \*, unsigned long);
> - * void dma_buf_kunmap_atomic(struct dma_buf \*, unsigned long,
> void \*);
> - *
> * For importers all the restrictions of using kmap apply, like
> the
> limited
> * supply of kmap_atomic slots. Hence an importer shall only hold
> onto at
> * max 2 atomic dma_buf kmaps at the same time (in any given
> process
> context).
This is also about atomic kmap ...
And the subsequent language around "Note that these calls need to always
succeed." is also not true, might be good to update that stating that
kmap
is optional (like we say already for vmap).
With those docs nits addressed:
Reviewed-by: Daniel Vetter
>>>
>>>
>>> I've fixed up patch #1 and #2 and added your Reviewed-by tag.
>>>
>>> Since I finally had time to install dim do you have any objections that I
>>> now run "dim push drm-misc-next" with those two applied?
>>
>> Go ahead, that's the point of commit rights. dim might complain if you
>> cherry picked them and didn't pick them up using dim apply though ...
>
>
> I've fixed up the Link tags, but when I try "dim push-branch drm-misc-next"
> I only get the error message "error: dst ref refs/heads/drm-misc-next
> receives from more than one src."
>
> Any idea what is going wrong here?
Sounds like multiple upstreams for your local drm-misc-next branch,
and git then can't decide which one to pick. If you delete the branch
and create it using dim checkout drm-misc-next this shouldn't happen.
We're trying to fit into existing check-outs and branches, but if you
set things up slightly different than dim would have you're off script
and there's limited support for that.
Alternative check out your
[DPU PATCH 5/5] drm/msm/dpu: dynamic assignment of hw pipe to plane
Currently, there exists a static binding of hw pipe to
plane. This restricts wide plane support where plane width
exceeds the pipe's maximum width.
To enable such use cases, the hw pipes are dynamically
(re)allocated to a plane during atomic check based on the
plane capabilities.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 45 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 670 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 4 +-
3 files changed, 414 insertions(+), 305 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 56f6576..afb8c79 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -175,7 +175,8 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
struct dpu_rect plane_crtc_roi;
u32 flush_mask;
- uint32_t stage_idx, lm_idx;
+ uint32_t stage_idx = 0, lm_idx;
+ int i;
int zpos_cnt[DPU_STAGE_MAX + 1] = { 0 };
bool bg_alpha_enable = false;
@@ -204,11 +205,11 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
dpu_plane_get_ctl_flush(plane, ctl, _mask);
- DPU_DEBUG("crtc %d stage:%d - plane %d sspp %d fb %d\n",
- crtc->base.id,
- pstate->stage,
- plane->base.id,
- dpu_plane_pipe(plane) - SSPP_VIG0,
+ DPU_DEBUG("crtc %d stage%d: plane%d ssppmode%d[%d %d] fb%d\n",
+ crtc->base.id, pstate->stage,
+ plane->base.id, pstate->num_pipes,
+ dpu_plane_pipe(pstate->pipe_hw[0]) - SSPP_VIG0,
+ dpu_plane_pipe(pstate->pipe_hw[1]) - SSPP_VIG0,
state->fb ? state->fb->base.id : -1);
format = to_dpu_format(msm_framebuffer_format(pstate->base.fb));
@@ -221,19 +222,25 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
bg_alpha_enable = true;
DPU_EVT32(DRMID(crtc), DRMID(plane),
- state->fb ? state->fb->base.id : -1,
- state->src_x >> 16, state->src_y >> 16,
- state->src_w >> 16, state->src_h >> 16,
- state->crtc_x, state->crtc_y,
- state->crtc_w, state->crtc_h);
-
- stage_idx = zpos_cnt[pstate->stage]++;
- stage_cfg->stage[pstate->stage][stage_idx] =
- dpu_plane_pipe(plane);
-
- DPU_EVT32(DRMID(crtc), DRMID(plane), stage_idx,
- dpu_plane_pipe(plane) - SSPP_VIG0, pstate->stage,
- format->base.pixel_format, fb ? fb->modifier : 0);
+ state->fb ? state->fb->base.id : -1,
+ state->src_x >> 16, state->src_y >> 16,
+ state->src_w >> 16, state->src_h >> 16,
+ state->crtc_x, state->crtc_y,
+ state->crtc_w, state->crtc_h);
+
+ for (i = 0; i < pstate->num_pipes; i++) {
+ stage_idx = zpos_cnt[pstate->stage]++;
+ if (stage_idx >= PIPES_PER_STAGE)
+ break;
+
+ stage_cfg->stage[pstate->stage][stage_idx] =
+ dpu_plane_pipe(pstate->pipe_hw[i]);
+
+ DPU_EVT32(DRMID(crtc), DRMID(plane), stage_idx,
+ dpu_plane_pipe(pstate->pipe_hw[i]) - SSPP_VIG0,
+ pstate->stage, format->base.pixel_format,
+ fb ? fb->modifier : 0);
+ }
/* blend config update */
for (lm_idx = 0; lm_idx < cstate->num_mixers; lm_idx++) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index be40a2c..2c6960e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -81,40 +81,26 @@ enum dpu_plane_qos {
/*
* struct dpu_plane - local dpu plane structure
- * @aspace: address space pointer
* @csc_ptr: Points to dpu_csc_cfg structure to use for current
- * @catalog: Points to dpu catalog structure
- * @revalidate: force revalidation of all the plane properties
*/
struct dpu_plane {
struct drm_plane base;
struct mutex lock;
- enum dpu_sspp pipe;
- uint32_t features; /* capabilities from catalog */
uint32_t nformats;
uint32_t formats[64];
- struct dpu_hw_pipe *pipe_hw;
- struct dpu_hw_pipe_cfg pipe_cfg;
- struct dpu_hw_pipe_qos_cfg pipe_qos_cfg;
uint32_t color_fill;
[DPU PATCH 3/5] drm/msm/dpu: remove static binding of hw pipe to plane
Expose all planes with superset of formats and with no
hw pipe static binding. Accordingly, remove checks from
atomic_check reflecting the decoupling.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 26 +---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 50 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 17 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 158 -
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 5 +-
5 files changed, 56 insertions(+), 200 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index c0b8116..c2a7c64 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -44,13 +44,6 @@
#define DEFAULT_DPU_LINE_WIDTH 2048
#define DEFAULT_DPU_OUTPUT_LINE_WIDTH 2560
-#define MAX_HORZ_DECIMATION4
-#define MAX_VERT_DECIMATION4
-
-#define MAX_UPSCALE_RATIO 20
-#define MAX_DOWNSCALE_RATIO4
-#define SSPP_UNITY_SCALE 1
-
#define STRCAT(X, Y) (X Y)
/*
@@ -58,9 +51,12 @@
*/
/* DPU top level caps */
static const struct dpu_caps sdm845_dpu_caps = {
+ .max_sspp_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
+ .max_sspp_pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
.max_mixer_width = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
.max_mixer_blendstages = 0xb,
.qseed_type = DPU_SSPP_SCALER_QSEED3,
+ .csc_type = DPU_SSPP_CSC_10BIT,
.ubwc_version = DPU_HW_UBWC_VER_20,
.has_src_split = true,
.has_dim_layer = true,
@@ -128,19 +124,8 @@
* SSPP sub blocks config
*/
-/* SSPP common configuration */
-static const struct dpu_sspp_blks_common sdm845_sspp_common = {
- .maxlinewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
- .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
- .maxhdeciexp = MAX_HORZ_DECIMATION,
- .maxvdeciexp = MAX_VERT_DECIMATION,
-};
-
#define _VIG_SBLK(num) \
{ \
- .common = _sspp_common, \
- .maxdwnscale = MAX_DOWNSCALE_RATIO, \
- .maxupscale = MAX_UPSCALE_RATIO, \
.src_blk = {.name = STRCAT("sspp_src_", num), \
.id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
.scaler_blk = {.name = STRCAT("sspp_scaler", num), \
@@ -149,17 +134,12 @@
.csc_blk = {.name = STRCAT("sspp_csc", num), \
.id = DPU_SSPP_CSC_10BIT, \
.base = 0x1a00, .len = 0x100,}, \
- .format_list = plane_formats_yuv, \
}
#define _DMA_SBLK(num) \
{ \
- .common = _sspp_common, \
- .maxdwnscale = SSPP_UNITY_SCALE, \
- .maxupscale = SSPP_UNITY_SCALE, \
.src_blk = {.name = STRCAT("sspp_src_", num), \
.id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
- .format_list = plane_formats, \
}
static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 = _VIG_SBLK("0");
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 1b04448..68644db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -63,6 +63,10 @@
#define CRTC_DUAL_MIXERS 2
+#define MAX_UPSCALE_RATIO 20
+#define MAX_DOWNSCALE_RATIO4
+#define SSPP_UNITY_SCALE 1
+
#define MAX_XIN_COUNT 16
/**
@@ -290,19 +294,26 @@ struct dpu_qos_lut_tbl {
/**
* struct dpu_caps - define DPU capabilities
- * @max_mixer_widthmax layer mixer line width support.
- * @max_mixer_blendstages max layer mixer blend stages or
+ * @max_sspp_width max: pixelwidth supported by this pipe
+ * @max_sspp_pixel_ram_size: size of latency hiding and
+ * de-tiling buffer in bytes
+ * @max_mixer_width: max layer mixer line width support
+ * @max_mixer_blendstages: max layer mixer blend stages or
* supported z order
- * @qseed_type qseed2 or qseed3 support.
- * @ubwc_version UBWC feature version (0x0 for not supported)
- * @has_src_split source split feature status
- * @has_dim_layer dim layer feature status
- * @has_idle_pcindicate if idle power collapse feature is supported
+ * @qseed_type: qseed2 or qseed3 support
+ * @csc_type: csc or csc_10bit support
+ * @ubwc_version: UBWC feature version (0x0 for not supported)
+ * @has_src_split: source split feature status
+ * @has_dim_layer: dim layer feature status
+ * @has_idle_pc:indicate if idle power collapse feature is supported
*/
struct dpu_caps {
+ u32 max_sspp_width;
+ u32 max_sspp_pixel_ram_size;
u32 max_mixer_width;
u32 max_mixer_blendstages;
u32 qseed_type;
+ u32 csc_type;
u32
[DPU PATCH 4/5] drm/msm/dpu: introduce state based plane resource management
A plane can be attached to a maximum of two hw pipes
in case of wide resolution greater than pipe's max width limit.
This mapping of hw pipe(s) to plane and number of pipes will be
maintained in the plane state.
Resource manager (RM) will handle the SSPP blocks reservation
for a given plane.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 11 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 156 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 20
3 files changed, 172 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index e0688895..4eb929b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -25,6 +25,8 @@
#include "dpu_hw_mdss.h"
#include "dpu_hw_sspp.h"
+#define PLANE_DUAL_PIPES 2
+
/**
* struct dpu_plane_state: Define dpu extension of drm plane state object
* @base: base drm plane state object
@@ -36,6 +38,8 @@
* @multirect_index: index of the rectangle of SSPP
* @multirect_mode: parallel or time multiplex multirect mode
* @pending: whether the current update is still pending
+ * @num_pipes: number of pipes attached to plane
+ * @pipe_hw: array of pointers to hardware pipes reserved for plane
* @scaler3_cfg: configuration data for scaler3
* @pixel_ext: configuration data for pixel extensions
* @scaler_check_state: indicates status of user provided pixel extension data
@@ -48,6 +52,10 @@ struct dpu_plane_state {
enum dpu_stage stage;
bool pending;
+ /* HW pipe config */
+ u32 num_pipes;
+ struct dpu_hw_pipe *pipe_hw[PLANE_DUAL_PIPES];
+
/* scaler configuration */
struct dpu_hw_scaler3_cfg scaler3_cfg;
struct dpu_hw_pixel_ext pixel_ext;
@@ -58,6 +66,9 @@ struct dpu_plane_state {
#define to_dpu_plane_state(x) \
container_of(x, struct dpu_plane_state, base)
+/* get plane id from dpu plane state */
+#define get_plane_id(x) ((x->base.plane)->base.id)
+
/**
* dpu_plane_pipe - return sspp identifier for the given plane
* @plane: Pointer to DRM plane object
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 018d01a..5387600 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -14,6 +14,7 @@
#define pr_fmt(fmt)"[drm:%s] " fmt, __func__
#include "dpu_kms.h"
+#include "dpu_hw_sspp.h"
#include "dpu_hw_lm.h"
#include "dpu_hw_ctl.h"
#include "dpu_hw_cdm.h"
@@ -22,10 +23,13 @@
#include "dpu_encoder.h"
#include "dpu_rm.h"
+#define RESERVED_BY_OTHER(drm_map_id, drm_id) \
+ (drm_map_id && (drm_map_id != drm_id))
+
/**
* struct dpu_rm_hw_blk - hardware block tracking list member
* @type: Type of hardware block this structure tracks
- * @drm_id:DRM component ID associated with the HW block
+ * @rm_id: DRM component ID associated with the HW block
* @id:Hardware ID number, within it's own space, ie. LM_X
* @hw:Pointer to the hardware register access object for this
block
*/
@@ -157,7 +161,8 @@ static void _dpu_rm_hw_destroy(enum dpu_hw_blk_type type,
void *hw)
dpu_hw_intf_destroy(hw);
break;
case DPU_HW_BLK_SSPP:
- /* SSPPs are not managed by the resource manager */
+ dpu_hw_sspp_destroy(hw);
+ break;
case DPU_HW_BLK_TOP:
/* Top is a singleton, not managed in hw_blks list */
case DPU_HW_BLK_MAX:
@@ -229,7 +234,8 @@ static int _dpu_rm_hw_blk_create(
hw = dpu_hw_intf_init(id, mmio, cat);
break;
case DPU_HW_BLK_SSPP:
- /* SSPPs are not managed by the resource manager */
+ hw = dpu_hw_sspp_init(id, mmio, cat);
+ break;
case DPU_HW_BLK_TOP:
/* Top is a singleton, not managed in hw_blks list */
case DPU_HW_BLK_MAX:
@@ -281,6 +287,15 @@ int dpu_rm_init(struct dpu_rm *rm,
}
/* Interrogate HW catalog and create tracking items for hw blocks */
+ for (i = 0; i < cat->sspp_count; i++) {
+ rc = _dpu_rm_hw_blk_create(rm, cat, mmio, DPU_HW_BLK_SSPP,
+ cat->sspp[i].id, >sspp[i]);
+ if (rc) {
+ DPU_ERROR("failed: sspp hw not available\n");
+ goto fail;
+ }
+ }
+
for (i = 0; i < cat->mixer_count; i++) {
struct dpu_lm_cfg *lm = >mixer[i];
@@ -570,12 +585,10 @@ static int _dpu_rm_reserve_intf_related_hw(
}
static int _dpu_rm_release_hw_blk(
- struct dpu_rm *rm,
- struct dpu_crtc_state *state,
+ struct dpu_rm *rm, int drm_id,
enum dpu_hw_blk_type type)
{
struct dpu_rm_hw_iter iter;
- int
[DPU PATCH 1/5] drm/msm/dpu: remove smart dma support
Removing the smart dma feature implementation as it is
currently not enabled on dpu driver.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 51 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 25 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 19 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 76 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 4 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 159 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 56 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 26 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 265 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 38 +---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
11 files changed, 84 insertions(+), 637 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 6c78c11c3..f0aafec 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -230,12 +230,9 @@ static void _dpu_crtc_blend_setup_mixer(struct drm_crtc
*crtc,
stage_idx = zpos_cnt[pstate->stage]++;
stage_cfg->stage[pstate->stage][stage_idx] =
dpu_plane_pipe(plane);
- stage_cfg->multirect_index[pstate->stage][stage_idx] =
- pstate->multirect_index;
DPU_EVT32(DRMID(crtc), DRMID(plane), stage_idx,
dpu_plane_pipe(plane) - SSPP_VIG0, pstate->stage,
- pstate->multirect_index, pstate->multirect_mode,
format->base.pixel_format, fb ? fb->modifier : 0);
/* blend config update */
@@ -1334,14 +1331,13 @@ struct plane_state {
struct dpu_plane_state *dpu_pstate;
const struct drm_plane_state *drm_pstate;
int stage;
- u32 pipe_id;
};
static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_crtc_state *state)
{
struct dpu_crtc *dpu_crtc;
- struct plane_state pstates[DPU_STAGE_MAX * 4];
+ struct plane_state pstates[DPU_STAGE_MAX * 2];
struct dpu_crtc_state *cstate;
const struct drm_plane_state *pstate;
@@ -1351,10 +1347,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
struct dpu_private_state *dpu_priv_state;
int cnt = 0, rc = 0, mixer_width, i, z_pos;
-
- struct dpu_multirect_plane_states multirect_plane[DPU_STAGE_MAX * 2];
- int multirect_count = 0;
- const struct drm_plane_state *pipe_staged[SSPP_MAX];
int left_zpos_cnt = 0, right_zpos_cnt = 0;
if (!crtc) {
@@ -1378,8 +1370,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
if (state->active_changed)
state->mode_changed = true;
- memset(pipe_staged, 0, sizeof(pipe_staged));
-
mixer_width = dpu_crtc_get_mixer_width(dpu_crtc, cstate, mode);
_dpu_crtc_setup_lm_bounds(crtc, state);
@@ -1398,18 +1388,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
pstates[cnt].dpu_pstate = to_dpu_plane_state(pstate);
pstates[cnt].drm_pstate = pstate;
pstates[cnt].stage = pstate->normalized_zpos;
- pstates[cnt].pipe_id = dpu_plane_pipe(plane);
-
- if (pipe_staged[pstates[cnt].pipe_id]) {
- multirect_plane[multirect_count].r0 =
- pipe_staged[pstates[cnt].pipe_id];
- multirect_plane[multirect_count].r1 = pstate;
- multirect_count++;
-
- pipe_staged[pstates[cnt].pipe_id] = NULL;
- } else {
- pipe_staged[pstates[cnt].pipe_id] = pstate;
- }
cnt++;
@@ -1426,20 +1404,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
}
}
- for (i = 1; i < SSPP_MAX; i++) {
- if (pipe_staged[i]) {
- dpu_plane_clear_multirect(pipe_staged[i]);
-
- if (is_dpu_plane_virtual(pipe_staged[i]->plane)) {
- DPU_ERROR(
- "r1 only virt plane:%d not supported\n",
- pipe_staged[i]->plane->base.id);
- rc = -EINVAL;
- goto end;
- }
- }
- }
-
z_pos = -1;
for (i = 0; i < cnt; i++) {
/* reset counts at every new blend stage */
@@ -1478,17 +1442,6 @@ static int dpu_crtc_atomic_check(struct drm_crtc *crtc,
DPU_DEBUG("%s: zpos %d", dpu_crtc->name, z_pos);
}
- for (i = 0; i < multirect_count; i++) {
- if
[DPU PATCH 2/5] drm/msm/dpu: enable cursor plane for primary crtc
Reserve one DMA pipe as cursor plane and also, update crtc
support of cursor in crtc_init.
Signed-off-by: Sravanthi Kollukuduru
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 7 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 53 +++---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 7 +++-
4 files changed, 34 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f0aafec..56f6576 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -2027,7 +2027,8 @@ static int _dpu_crtc_init_events(struct dpu_crtc
*dpu_crtc)
}
/* initialize crtc */
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane)
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_plane *cursor_plane)
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
@@ -2061,8 +2062,8 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane)
dpu_crtc_frame_event_work);
}
- drm_crtc_init_with_planes(dev, crtc, plane, NULL, _crtc_funcs,
- NULL);
+ drm_crtc_init_with_planes(dev, crtc, plane,
+ cursor_plane, _crtc_funcs, NULL);
drm_crtc_helper_add(crtc, _crtc_helper_funcs);
plane->crtc = crtc;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
index 50c3d4b..b44750d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h
@@ -366,7 +366,8 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc,
* @plane: base plane
* @Return: new crtc object or error
*/
-struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane
*plane);
+struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
+ struct drm_plane *cursor_plane);
/**
* dpu_crtc_cancel_pending_flip - complete flip for clients on lastclose
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index f0c2881..c0b8116 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -29,6 +29,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
+#define DMA_CURSOR_SDM845_MASK \
+ (DMA_SDM845_MASK | BIT(DPU_SSPP_CURSOR))
+
#define MIXER_SDM845_MASK \
(BIT(DPU_MIXER_SOURCESPLIT) | BIT(DPU_DIM_LAYER))
@@ -169,45 +172,35 @@
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_2 = _DMA_SBLK("10");
static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = _DMA_SBLK("11");
-#define SSPP_VIG_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
- { \
- .name = _name, .id = _id, \
- .base = _base, .len = 0x1c8, \
- .features = VIG_SDM845_MASK, \
- .sblk = &_sblk, \
- .xin_id = _xinid, \
- .type = SSPP_TYPE_VIG, \
- .clk_ctrl = _clkctrl \
- }
-
-#define SSPP_DMA_BLK(_name, _id, _base, _sblk, _xinid, _clkctrl) \
+#define SSPP_BLK(_name, _id, _base, _features, \
+ _sblk, _xinid, _type, _clkctrl) \
{ \
.name = _name, .id = _id, \
.base = _base, .len = 0x1c8, \
- .features = DMA_SDM845_MASK, \
+ .features = _features, \
.sblk = &_sblk, \
.xin_id = _xinid, \
- .type = SSPP_TYPE_DMA, \
+ .type = _type, \
.clk_ctrl = _clkctrl \
}
static struct dpu_sspp_cfg sdm845_sspp[] = {
- SSPP_VIG_BLK("sspp_0", SSPP_VIG0, 0x4000,
- sdm845_vig_sblk_0, 0, DPU_CLK_CTRL_VIG0),
- SSPP_VIG_BLK("sspp_1", SSPP_VIG1, 0x6000,
- sdm845_vig_sblk_1, 4, DPU_CLK_CTRL_VIG1),
- SSPP_VIG_BLK("sspp_2", SSPP_VIG2, 0x8000,
- sdm845_vig_sblk_2, 8, DPU_CLK_CTRL_VIG2),
- SSPP_VIG_BLK("sspp_3", SSPP_VIG3, 0xa000,
- sdm845_vig_sblk_3, 12, DPU_CLK_CTRL_VIG3),
- SSPP_DMA_BLK("sspp_8", SSPP_DMA0, 0x24000,
- sdm845_dma_sblk_0, 1, DPU_CLK_CTRL_DMA0),
- SSPP_DMA_BLK("sspp_9", SSPP_DMA1, 0x26000,
- sdm845_dma_sblk_1, 5, DPU_CLK_CTRL_DMA1),
- SSPP_DMA_BLK("sspp_10", SSPP_DMA2, 0x28000,
- sdm845_dma_sblk_2, 9, DPU_CLK_CTRL_CURSOR0),
- SSPP_DMA_BLK("sspp_11", SSPP_DMA3, 0x2a000,
- sdm845_dma_sblk_3, 13, DPU_CLK_CTRL_CURSOR1),
+ SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_SDM845_MASK,
+ sdm845_vig_sblk_0, 0, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
+ SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_SDM845_MASK,
+ sdm845_vig_sblk_1, 4, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1),
+
[DPU PATCH 0/5] Introduce plane virtualization in DPU driver
Currently, each drm plane controls a single HW pipe. For all use cases where plane width exceeds the maximum pipe width, the DPU driver will require more than one HW pipe. This patchset enables virtualization of planes through the following changes: (1) Expose all the planes with the superset of formats and without any static binding of HW pipe during the initialization. (2) Introduce the state based plane resource management. (3) Dynamically assign a maximum of two pipes per plane based on plane capabilities in atomic check. This patchset is based on https://patchwork.kernel.org/patch/10471479/ Sravanthi Kollukuduru (5): drm/msm/dpu: remove smart dma support drm/msm/dpu: enable cursor plane for primary crtc drm/msm/dpu: remove static binding of hw pipe to plane drm/msm/dpu: introduce state based plane resource management drm/msm/dpu: dynamic assignment of hw pipe to plane drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 103 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h |3 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 104 +-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 69 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 76 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h |4 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 159 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h| 56 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 48 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 1063 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 58 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 156 +++- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 20 + drivers/gpu/drm/msm/msm_drv.h |2 +- 14 files changed, 744 insertions(+), 1177 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 7/9] drm/gem-fb-helper: Always do implicit sync
On Tue, Apr 24, 2018 at 02:04:10PM +0200, Daniel Vetter wrote: > On Fri, Apr 20, 2018 at 03:11:24PM -0700, Eric Anholt wrote: > > Daniel Vetter writes: > > > > > I've done a lot of history digging. The first signs of this > > > optimization was introduced in i915: > > > > I can't come up with any reason this would matter. I almost came up > > with "You're doing tearing X11 front buffer rendering, and you do a > > modeset using the same fb, and so you block that modeset behind your > > rendering." Except that: > > > > 1) who cares > > 2) this helper is only for dma-bufs, not normal X11 rendering > > 3) your X11 driver should be doing pageflipping to be tear-free anyway, > >let's just fix that[1]. > > > > Reviewed-by: Eric Anholt > > > > [1] This is not actually me volunteering myself or anyone else to go fix > > that. > > Ok, merged everything except the final three patches. I'll poke Rob for a > proper ack first before doing that. There's not much point in trying to > unify behaviour if there's still a driver doing things differently :-) > > Thanks very much for your review. Ok with the msm conversion to atomic commit helpers msm aligned to what we're doing here without my patch. I pulled in the remaining to for 4.19. -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: [PATCH 2/5] dma-buf: remove kmap_atomic interface
Am 19.06.2018 um 17:35 schrieb Daniel Vetter:
On Tue, Jun 19, 2018 at 4:47 PM, Christian König
wrote:
Am 18.06.2018 um 10:18 schrieb Daniel Vetter:
On Fri, Jun 01, 2018 at 02:00:17PM +0200, Christian König wrote:
Neither used nor correctly implemented anywhere. Just completely remove
the interface.
Signed-off-by: Christian König
I wonder whether we can nuke the normal kmap stuff too ... everyone seems
to want/use the vmap stuff for kernel-internal mapping needs.
Anyway, this looks good.
---
drivers/dma-buf/dma-buf.c | 44
--
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -
drivers/gpu/drm/armada/armada_gem.c| 2 -
drivers/gpu/drm/drm_prime.c| 26 -
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 11 --
drivers/gpu/drm/i915/selftests/mock_dmabuf.c | 2 -
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 2 -
drivers/gpu/drm/tegra/gem.c| 14 ---
drivers/gpu/drm/udl/udl_dmabuf.c | 17 -
drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 13 ---
.../media/common/videobuf2/videobuf2-dma-contig.c | 1 -
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 1 -
drivers/media/common/videobuf2/videobuf2-vmalloc.c | 1 -
drivers/staging/android/ion/ion.c | 2 -
drivers/tee/tee_shm.c | 6 ---
include/drm/drm_prime.h| 4 --
include/linux/dma-buf.h| 4 --
17 files changed, 152 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index e99a8d19991b..e4c657d9fad7 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,7 +405,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
|| !exp_info->ops->map_dma_buf
|| !exp_info->ops->unmap_dma_buf
|| !exp_info->ops->release
- || !exp_info->ops->map_atomic
|| !exp_info->ops->map
|| !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
@@ -687,14 +686,6 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
* void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
* void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
*
- * There are also atomic variants of these interfaces. Like for kmap
they
- * facilitate non-blocking fast-paths. Neither the importer nor the
exporter
- * (in the callback) is allowed to block when using these.
- *
- * Interfaces::
- * void \*dma_buf_kmap_atomic(struct dma_buf \*, unsigned long);
- * void dma_buf_kunmap_atomic(struct dma_buf \*, unsigned long,
void \*);
- *
* For importers all the restrictions of using kmap apply, like the
limited
* supply of kmap_atomic slots. Hence an importer shall only hold
onto at
* max 2 atomic dma_buf kmaps at the same time (in any given process
context).
This is also about atomic kmap ...
And the subsequent language around "Note that these calls need to always
succeed." is also not true, might be good to update that stating that kmap
is optional (like we say already for vmap).
With those docs nits addressed:
Reviewed-by: Daniel Vetter
I've fixed up patch #1 and #2 and added your Reviewed-by tag.
Since I finally had time to install dim do you have any objections that I
now run "dim push drm-misc-next" with those two applied?
Go ahead, that's the point of commit rights. dim might complain if you
cherry picked them and didn't pick them up using dim apply though ...
I've fixed up the Link tags, but when I try "dim push-branch
drm-misc-next" I only get the error message "error: dst ref
refs/heads/drm-misc-next receives from more than one src."
Any idea what is going wrong here?
Christian.
-Daniel
Regards,
Christian.
@@ -859,41 +850,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
}
EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
-/**
- * dma_buf_kmap_atomic - Map a page of the buffer object into kernel
address
- * space. The same restrictions as for kmap_atomic and friends apply.
- * @dmabuf:[in]buffer to map page from.
- * @page_num: [in]page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might
fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned long
page_num)
-{
- WARN_ON(!dmabuf);
-
- return dmabuf->ops->map_atomic(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
-
-/**
- * dma_buf_kunmap_atomic - Unmap a page obtained by dma_buf_kmap_atomic.
- * @dmabuf:[in]buffer to unmap page from.
- * @page_num: [in]page in PAGE_SIZE units to unmap.
- * @vaddr: [in]kernel space pointer
Re: [PATCH] drm/exynos: gsc: Get device id from OF alias
On 20.06.2018 13:53, Krzysztof Kozlowski wrote: > On 20 June 2018 at 13:38, Andrzej Hajda wrote: >> Hi Krzysztof, >> >> On 20.06.2018 12:40, Krzysztof Kozlowski wrote: >>> On 15 June 2018 at 14:26, Marek Szyprowski wrote: Platform devices instantiated from device-tree always have pdev->id set to -1, so use of_get_alias_id() helper to retrieve proper device id. Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c b/drivers/gpu/drm/exynos/exynos_drm_gsc.c index e99dd1e4ba65..a63287597985 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c @@ -1196,7 +1196,12 @@ static int gsc_probe(struct platform_device *pdev) struct exynos_drm_ipp_formats *formats; struct gsc_context *ctx; struct resource *res; - int ret, i; + int ret, i, id; + + ret = of_alias_get_id(pdev->dev.of_node, "gsc"); + if (ret < 0) + return ret; + id = ret; ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -1254,7 +1259,7 @@ static int gsc_probe(struct platform_device *pdev) } /* context initailization */ - ctx->id = pdev->id; + ctx->id = id; >>> Why do you need ctx->id at all? I see it is used only in dev_dbg and >>> dev_err messages but these should be easily identifiable by device >>> name+address. Maybe get rid of ctx->id entirely? >> I am working on patches adding framebuffer display pre-processing >> on-the-fly, they requires gscaler id to program sysreg registers. I hope >> to post it in near future. > OK, makes sense. Then I have a dependent comment - if alias id is used > by driver then probably it should be validated to prevent errors like > out-of-bounds access. DTB theoretically might come from out-of-tree or > from older version. Something like this was reported for our pinctrl > driver: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93b0beae721b3344923b4b8317e9d83b542f4ca6 > Probably the validation should come with your code, Andrzej. Not here. OK, I will add it in my patchset. Regards Andrzej > > Best regards, > Krzysztof > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #17 from SET --- This is where I'm up to : git bisect start # bad: [135c5504a600ff9b06e321694fbcac78a9530cd4] Merge tag 'drm-next-2018-06-06-1' of git://anongit.freedesktop.org/drm/drm git bisect bad 135c5504a600ff9b06e321694fbcac78a9530cd4 # good: [c76f0b2cc2f1be1a8a20f0fe2c0f30919bc559fb] Merge tag 'drm-amdkfd-next-2018-05-14' of git://people.freedesktop.org/~gabbayo/linux into drm-next git bisect good c76f0b2cc2f1be1a8a20f0fe2c0f30919bc559fb # good: [92400b8c8b42e53abb0fcb4ac75cb85d4177a891] Merge branch 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip git bisect good 92400b8c8b42e53abb0fcb4ac75cb85d4177a891 # good: [07c4dd3435aa387d3b58f4e941dc516513f14507] Merge tag 'usb-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb git bisect good 07c4dd3435aa387d3b58f4e941dc516513f14507 # bad: [cac18c82e0c5b39b69648942576dbd1d6f9d056e] drm/amdgpu: Specify vega20 uvd firmware git bisect bad cac18c82e0c5b39b69648942576dbd1d6f9d056e # bad: [cac18c82e0c5b39b69648942576dbd1d6f9d056e] drm/amdgpu: Specify vega20 uvd firmware git bisect bad cac18c82e0c5b39b69648942576dbd1d6f9d056e # bad: [cac18c82e0c5b39b69648942576dbd1d6f9d056e] drm/amdgpu: Specify vega20 uvd firmware git bisect bad cac18c82e0c5b39b69648942576dbd1d6f9d056e # bad: [cac18c82e0c5b39b69648942576dbd1d6f9d056e] drm/amdgpu: Specify vega20 uvd firmware git bisect bad cac18c82e0c5b39b69648942576dbd1d6f9d056e # skip: [7ab3fdde04218c4733e96712b651751c413d51c3] drm/amd/display: Update MST edid property every time git bisect skip 7ab3fdde04218c4733e96712b651751c413d51c3 # skip: [e930793280799e66c3197e2ee6e70b1129f8aa12] drm/amdgpu: add VEGAM pci ids git bisect skip e930793280799e66c3197e2ee6e70b1129f8aa12 # good: [53f071e19d566e7d0a4eada1bd8313a4cdb660a4] Merge drm/drm-next into drm-intel-next-queued git bisect good 53f071e19d566e7d0a4eada1bd8313a4cdb660a4 # good: [53f071e19d566e7d0a4eada1bd8313a4cdb660a4] Merge drm/drm-next into drm-intel-next-queued git bisect good 53f071e19d566e7d0a4eada1bd8313a4cdb660a4 # skip: [ba8f7ad0e5b25851299cd45a63b57d843e50b577] drm/amdgpu: add VEGAM UVD firmware support git bisect skip ba8f7ad0e5b25851299cd45a63b57d843e50b577 # skip: [d10fb4a6f382474025f326bf90ee3b64396486ea] drm/amd/pp: Change pstate_clk frequency unit to 10KHz on Rv git bisect skip d10fb4a6f382474025f326bf90ee3b64396486ea I'll keep trying, hoping it ends before it is fixed by some other changes. -- 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 v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
Best Regards,
Ramalingam C
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, June 20, 2018 5:14 PM
> To: C, Ramalingam
> Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Sean Paul ; Chris
> Wilson ; Nikula, Jani ;
> Winkler, Tomas ; Usyskin, Alexander
> ; Shankar, Uma ;
> Sharma, Shashank
> Subject: Re: [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
>
> On Wed, Jun 20, 2018 at 12:19 PM, Ramalingam C
> wrote:
> >
> >
> > On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
> >>
> >> On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
> >>>
> >>> Implements the DP adaptation specific HDCP2.2 functions.
> >>>
> >>> These functions perform the DPCD read and write for communicating
> >>> the
> >>> HDCP2.2 auth message back and forth.
> >>>
> >>> Note: Chris Wilson suggested alternate method for waiting for
> >>> CP_IRQ, than completions concept. WIP to understand and implement
> >>> that, if needed. Just to unblock the review of other changes, v2
> >>> still continues with completions.
> >>>
> >>> v2:
> >>>wait for cp_irq is merged with this patch. Rebased.
> >>> v3:
> >>>wait_queue is used for wait for cp_irq [Chris Wilson]
> >>> v4:
> >>>Style fixed.
> >>>%s/PARING/PAIRING
> >>>Few style fixes [Uma]
> >>>
> >>> Signed-off-by: Ramalingam C
> >>> ---
> >>> drivers/gpu/drm/i915/intel_dp.c | 358
> >>> ++
> >>> drivers/gpu/drm/i915/intel_drv.h | 7 +
> >>> drivers/gpu/drm/i915/intel_hdcp.c | 5 +
> >>> 3 files changed, 370 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >>> b/drivers/gpu/drm/i915/intel_dp.c index 528407d608c8..ee71a26ec23f
> >>> 100644
> >>> --- a/drivers/gpu/drm/i915/intel_dp.c
> >>> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >>> @@ -31,6 +31,7 @@
> >>> #include
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>> #include
> >>> #include @@ -5057,6 +5058,28 @@ void
> >>> intel_dp_encoder_suspend(struct intel_encoder
> >>> *intel_encoder)
> >>> pps_unlock(intel_dp);
> >>> }
> >>> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
> >>> +int timeout) {
> >>> + long ret;
> >>> +
> >>> + /* Reinit */
> >>> + atomic_set(>cp_irq_recved, 0);
> >>> +
> >>> +#define C (atomic_read(>cp_irq_recved) > 0)
> >>> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue,
> >>> +C,
> >>> +
> >>> msecs_to_jiffies(timeout));
> >>> +
> >>> + if (ret > 0) {
> >>> + atomic_set(>cp_irq_recved, 0);
> >>> + return 0;
> >>> + } else if (!ret) {
> >>> + return -ETIMEDOUT;
> >>> + }
> >>> + return (int)ret;
> >>> +}
> >>> +
> >>> +
> >>> static
> >>> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port
> >>> *intel_dig_port,
> >>> u8 *an) @@ -5275,6 +5298,335 @@ int
> >>> intel_dp_hdcp_capable(struct intel_digital_port *intel_dig_port,
> >>> return 0;
> >>> }
> >>> +static
> >>> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int
> >>> *offset)
> >>
> >> Ugh, this is annoying that we have to map things around like that.
> >> But looking at the numbers the standards really don't seem to match at all.
> >
> > Sorry i am not getting about not matching part.
> > You mean some offsets and timeouts are not matching with spec?
>
> match as in you can't just compute them using a base_offset + hdcp_msgid
> trick,
> you do have to use the lookup table. The numbers itself match the spec, it's
> just
> that the specs are all inconsistent with each another for no real good reason.
>
> >>
> >>
> >> Instead of open-coding this I suggested you use a table with a struct
> >> like:
> >>
> >> const static struct hdcp_dp {
> >> int hdcp_msg;
> >> int dpcd_offset;
> >> int timeout;
> >> /* whatever else you might need */ } hdcp_2_dp_table[] = {
> >> { HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
> >> ...
> >> };
> >>
> >> Then just search that table in the code instead of the huge switch
> >> table below.
> >
> > Suggesting this for cpu optimization or for coding style?
>
> Just coding style, having to check a table is easier than checking huge case
> statements. None of this code matters from a performance pov.
Sure Daniel. I will use array of struct here.
Thanks
-Ram
>
> >
> >
> >>
> >>> +{
> >>> + switch (byte) {
> >>> + case HDCP_2_2_AKE_INIT:
> >>> + *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
> >>> + break;
> >>> + case HDCP_2_2_AKE_SEND_CERT:
> >>> + *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
> >>> + break;
> >>> + case HDCP_2_2_AKE_NO_STORED_KM:
> >>> + *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
>
Re: [PATCH] drm/exynos: gsc: Get device id from OF alias
On 20 June 2018 at 13:38, Andrzej Hajda wrote: > Hi Krzysztof, > > On 20.06.2018 12:40, Krzysztof Kozlowski wrote: >> On 15 June 2018 at 14:26, Marek Szyprowski wrote: >>> Platform devices instantiated from device-tree always have pdev->id set to >>> -1, so use of_get_alias_id() helper to retrieve proper device id. >>> >>> Signed-off-by: Marek Szyprowski >>> --- >>> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 9 +++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c >>> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c >>> index e99dd1e4ba65..a63287597985 100644 >>> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c >>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c >>> @@ -1196,7 +1196,12 @@ static int gsc_probe(struct platform_device *pdev) >>> struct exynos_drm_ipp_formats *formats; >>> struct gsc_context *ctx; >>> struct resource *res; >>> - int ret, i; >>> + int ret, i, id; >>> + >>> + ret = of_alias_get_id(pdev->dev.of_node, "gsc"); >>> + if (ret < 0) >>> + return ret; >>> + id = ret; >>> >>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); >>> if (!ctx) >>> @@ -1254,7 +1259,7 @@ static int gsc_probe(struct platform_device *pdev) >>> } >>> >>> /* context initailization */ >>> - ctx->id = pdev->id; >>> + ctx->id = id; >> Why do you need ctx->id at all? I see it is used only in dev_dbg and >> dev_err messages but these should be easily identifiable by device >> name+address. Maybe get rid of ctx->id entirely? > > I am working on patches adding framebuffer display pre-processing > on-the-fly, they requires gscaler id to program sysreg registers. I hope > to post it in near future. OK, makes sense. Then I have a dependent comment - if alias id is used by driver then probably it should be validated to prevent errors like out-of-bounds access. DTB theoretically might come from out-of-tree or from older version. Something like this was reported for our pinctrl driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93b0beae721b3344923b4b8317e9d83b542f4ca6 Probably the validation should come with your code, Andrzej. Not here. Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
On Wed, Jun 20, 2018 at 12:19 PM, Ramalingam C wrote:
>
>
> On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
>>
>> On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
>>>
>>> Implements the DP adaptation specific HDCP2.2 functions.
>>>
>>> These functions perform the DPCD read and write for communicating the
>>> HDCP2.2 auth message back and forth.
>>>
>>> Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
>>> than completions concept. WIP to understand and implement that,
>>> if needed. Just to unblock the review of other changes, v2 still
>>> continues with completions.
>>>
>>> v2:
>>>wait for cp_irq is merged with this patch. Rebased.
>>> v3:
>>>wait_queue is used for wait for cp_irq [Chris Wilson]
>>> v4:
>>>Style fixed.
>>>%s/PARING/PAIRING
>>>Few style fixes [Uma]
>>>
>>> Signed-off-by: Ramalingam C
>>> ---
>>> drivers/gpu/drm/i915/intel_dp.c | 358
>>> ++
>>> drivers/gpu/drm/i915/intel_drv.h | 7 +
>>> drivers/gpu/drm/i915/intel_hdcp.c | 5 +
>>> 3 files changed, 370 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>>> b/drivers/gpu/drm/i915/intel_dp.c
>>> index 528407d608c8..ee71a26ec23f 100644
>>> --- a/drivers/gpu/drm/i915/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>>> @@ -31,6 +31,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -5057,6 +5058,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
>>> *intel_encoder)
>>> pps_unlock(intel_dp);
>>> }
>>> +static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
>>> +int timeout)
>>> +{
>>> + long ret;
>>> +
>>> + /* Reinit */
>>> + atomic_set(>cp_irq_recved, 0);
>>> +
>>> +#define C (atomic_read(>cp_irq_recved) > 0)
>>> + ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
>>> +
>>> msecs_to_jiffies(timeout));
>>> +
>>> + if (ret > 0) {
>>> + atomic_set(>cp_irq_recved, 0);
>>> + return 0;
>>> + } else if (!ret) {
>>> + return -ETIMEDOUT;
>>> + }
>>> + return (int)ret;
>>> +}
>>> +
>>> +
>>> static
>>> int intel_dp_hdcp_write_an_aksv(struct intel_digital_port
>>> *intel_dig_port,
>>> u8 *an)
>>> @@ -5275,6 +5298,335 @@ int intel_dp_hdcp_capable(struct
>>> intel_digital_port *intel_dig_port,
>>> return 0;
>>> }
>>> +static
>>> +int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int
>>> *offset)
>>
>> Ugh, this is annoying that we have to map things around like that. But
>> looking at the numbers the standards really don't seem to match at all.
>
> Sorry i am not getting about not matching part.
> You mean some offsets and timeouts are not matching with spec?
match as in you can't just compute them using a base_offset +
hdcp_msgid trick, you do have to use the lookup table. The numbers
itself match the spec, it's just that the specs are all inconsistent
with each another for no real good reason.
>>
>>
>> Instead of open-coding this I suggested you use a table with a struct
>> like:
>>
>> const static struct hdcp_dp {
>> int hdcp_msg;
>> int dpcd_offset;
>> int timeout;
>> /* whatever else you might need */
>> } hdcp_2_dp_table[] = {
>> { HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
>> ...
>> };
>>
>> Then just search that table in the code instead of the huge switch table
>> below.
>
> Suggesting this for cpu optimization or for coding style?
Just coding style, having to check a table is easier than checking
huge case statements. None of this code matters from a performance
pov.
>
>
>>
>>> +{
>>> + switch (byte) {
>>> + case HDCP_2_2_AKE_INIT:
>>> + *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_SEND_CERT:
>>> + *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_NO_STORED_KM:
>>> + *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_STORED_KM:
>>> + *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_SEND_HPRIME:
>>> + *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
>>> + break;
>>> + case HDCP_2_2_AKE_SEND_PAIRING_INFO:
>>> + *offset = DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET;
>>> + break;
>>> + case HDCP_2_2_LC_INIT:
>>> + *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
>>> + break;
>>> + case HDCP_2_2_LC_SEND_LPRIME:
>>> + *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
>>> + break;
>>> + case HDCP_2_2_SKE_SEND_EKS:
>>> + *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
>>> +
Re: [PATCH] drm/exynos: gsc: Get device id from OF alias
Hi Krzysztof, On 20.06.2018 12:40, Krzysztof Kozlowski wrote: > On 15 June 2018 at 14:26, Marek Szyprowski wrote: >> Platform devices instantiated from device-tree always have pdev->id set to >> -1, so use of_get_alias_id() helper to retrieve proper device id. >> >> Signed-off-by: Marek Szyprowski >> --- >> drivers/gpu/drm/exynos/exynos_drm_gsc.c | 9 +++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c >> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c >> index e99dd1e4ba65..a63287597985 100644 >> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c >> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c >> @@ -1196,7 +1196,12 @@ static int gsc_probe(struct platform_device *pdev) >> struct exynos_drm_ipp_formats *formats; >> struct gsc_context *ctx; >> struct resource *res; >> - int ret, i; >> + int ret, i, id; >> + >> + ret = of_alias_get_id(pdev->dev.of_node, "gsc"); >> + if (ret < 0) >> + return ret; >> + id = ret; >> >> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); >> if (!ctx) >> @@ -1254,7 +1259,7 @@ static int gsc_probe(struct platform_device *pdev) >> } >> >> /* context initailization */ >> - ctx->id = pdev->id; >> + ctx->id = id; > Why do you need ctx->id at all? I see it is used only in dev_dbg and > dev_err messages but these should be easily identifiable by device > name+address. Maybe get rid of ctx->id entirely? I am working on patches adding framebuffer display pre-processing on-the-fly, they requires gscaler id to program sysreg registers. I hope to post it in near future. Regards Andrzej > > Best regards, > Krzysztof > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195159] nouveau incorrect ACPI usgage results in ACPI Error : AE_AML_PACKAGE_LIMIT
https://bugzilla.kernel.org/show_bug.cgi?id=195159 --- Comment #9 from Urgau (lolo.branst...@numericable.fr) --- Any update ? The problem is still here with the kernel 4.17.x -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos: gsc: Get device id from OF alias
On 15 June 2018 at 14:26, Marek Szyprowski wrote: > Platform devices instantiated from device-tree always have pdev->id set to > -1, so use of_get_alias_id() helper to retrieve proper device id. > > Signed-off-by: Marek Szyprowski > --- > drivers/gpu/drm/exynos/exynos_drm_gsc.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c > b/drivers/gpu/drm/exynos/exynos_drm_gsc.c > index e99dd1e4ba65..a63287597985 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c > @@ -1196,7 +1196,12 @@ static int gsc_probe(struct platform_device *pdev) > struct exynos_drm_ipp_formats *formats; > struct gsc_context *ctx; > struct resource *res; > - int ret, i; > + int ret, i, id; > + > + ret = of_alias_get_id(pdev->dev.of_node, "gsc"); > + if (ret < 0) > + return ret; > + id = ret; > > ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL); > if (!ctx) > @@ -1254,7 +1259,7 @@ static int gsc_probe(struct platform_device *pdev) > } > > /* context initailization */ > - ctx->id = pdev->id; > + ctx->id = id; Why do you need ctx->id at all? I see it is used only in dev_dbg and dev_err messages but these should be easily identifiable by device name+address. Maybe get rid of ctx->id entirely? Best regards, Krzysztof ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 38/41] drm/i915: Implement the HDCP2.2 support for DP
On Thursday 31 May 2018 12:52 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:57PM +0530, Ramalingam C wrote:
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
than completions concept. WIP to understand and implement that,
if needed. Just to unblock the review of other changes, v2 still
continues with completions.
v2:
wait for cp_irq is merged with this patch. Rebased.
v3:
wait_queue is used for wait for cp_irq [Chris Wilson]
v4:
Style fixed.
%s/PARING/PAIRING
Few style fixes [Uma]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 358 ++
drivers/gpu/drm/i915/intel_drv.h | 7 +
drivers/gpu/drm/i915/intel_hdcp.c | 5 +
3 files changed, 370 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 528407d608c8..ee71a26ec23f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -5057,6 +5058,28 @@ void intel_dp_encoder_suspend(struct intel_encoder
*intel_encoder)
pps_unlock(intel_dp);
}
+static int intel_dp_hdcp_wait_for_cp_irq(struct intel_hdcp *hdcp,
+int timeout)
+{
+ long ret;
+
+ /* Reinit */
+ atomic_set(>cp_irq_recved, 0);
+
+#define C (atomic_read(>cp_irq_recved) > 0)
+ ret = wait_event_interruptible_timeout(hdcp->cp_irq_queue, C,
+ msecs_to_jiffies(timeout));
+
+ if (ret > 0) {
+ atomic_set(>cp_irq_recved, 0);
+ return 0;
+ } else if (!ret) {
+ return -ETIMEDOUT;
+ }
+ return (int)ret;
+}
+
+
static
int intel_dp_hdcp_write_an_aksv(struct intel_digital_port *intel_dig_port,
u8 *an)
@@ -5275,6 +5298,335 @@ int intel_dp_hdcp_capable(struct intel_digital_port
*intel_dig_port,
return 0;
}
+static
+int intel_dpcd_offset_for_hdcp2_msgid(uint8_t byte, unsigned int *offset)
Ugh, this is annoying that we have to map things around like that. But
looking at the numbers the standards really don't seem to match at all.
Sorry i am not getting about not matching part.
You mean some offsets and timeouts are not matching with spec?
Instead of open-coding this I suggested you use a table with a struct
like:
const static struct hdcp_dp {
int hdcp_msg;
int dpcd_offset;
int timeout;
/* whatever else you might need */
} hdcp_2_dp_table[] = {
{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, ... },
...
};
Then just search that table in the code instead of the huge switch table
below.
Suggesting this for cpu optimization or for coding style?
+{
+ switch (byte) {
+ case HDCP_2_2_AKE_INIT:
+ *offset = DP_HDCP_2_2_AKE_INIT_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_CERT:
+ *offset = DP_HDCP_2_2_AKE_SEND_CERT_OFFSET;
+ break;
+ case HDCP_2_2_AKE_NO_STORED_KM:
+ *offset = DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET;
+ break;
+ case HDCP_2_2_AKE_STORED_KM:
+ *offset = DP_HDCP_2_2_AKE_STORED_KM_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ *offset = DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET;
+ break;
+ case HDCP_2_2_AKE_SEND_PAIRING_INFO:
+ *offset = DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET;
+ break;
+ case HDCP_2_2_LC_INIT:
+ *offset = DP_HDCP_2_2_LC_INIT_OFFSET;
+ break;
+ case HDCP_2_2_LC_SEND_LPRIME:
+ *offset = DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET;
+ break;
+ case HDCP_2_2_SKE_SEND_EKS:
+ *offset = DP_HDCP_2_2_SKE_SEND_EKS_OFFSET;
+ break;
+ case HDCP_2_2_REP_SEND_RECVID_LIST:
+ *offset = DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET;
+ break;
+ case HDCP_2_2_REP_SEND_ACK:
+ *offset = DP_HDCP_2_2_REP_SEND_ACK_OFFSET;
+ break;
+ case HDCP_2_2_REP_STREAM_MANAGE:
+ *offset = DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET;
+ break;
+ case HDCP_2_2_REP_STREAM_READY:
+ *offset = DP_HDCP_2_2_REP_STREAM_READY_OFFSET;
+ break;
+ case HDCP_2_2_ERRATA_DP_STREAM_TYPE:
+ *offset = DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET;
+ break;
+ default:
+ DRM_ERROR("Unrecognized Msg ID\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static inline
+int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+
Re: [PATCH v4 39/41] drm/i915: Implement the HDCP2.2 support for HDMI
On Thursday 31 May 2018 12:54 PM, Daniel Vetter wrote:
On Mon, May 21, 2018 at 06:23:58PM +0530, Ramalingam C wrote:
Implements the HDMI adaptation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2:
Rebased.
v3:
No Changes.
v4:
No more special handling of Gmbus burst read for AKE_SEND_CERT.
Style fixed with few naming. [Uma]
%s/PARING/PAIRING
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 186 ++
1 file changed, 186 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a5cc73101acb..042205e57e42 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1106,6 +1107,186 @@ bool intel_hdmi_hdcp_check_link(struct
intel_digital_port *intel_dig_port)
return true;
}
+static
+int intel_hdmi_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_port,
+ uint8_t *rx_status)
+{
+ return intel_hdmi_hdcp_read(intel_dig_port,
+ HDCP_2_2_HDMI_REG_RXSTATUS_OFFSET,
+ rx_status,
+ HDCP_2_2_HDMI_RXSTATUS_LEN);
+}
+
+static inline
+int intel_hdmi_hdcp2_timeout_for_msg(uint8_t msg_id, bool is_paired)
So at a glance this is the same timeout stuff as for dp. I think this
should be moved out of the low-level callbacks into commont code. Maybe
wrap the low-level callbacks for read/write into small helper functions,
which then also do the timeout handling?
And I think the timeouts and availability checks should be done in the
hdcp flow directly, instead of far away from where the register read/write
is issue.
Since the msg availability detection is specific to the adaptation and
timeout
which also adaptation specific, is needed for msg availability detection.
So I feel it will look simple to keep them together in hdcp shim .
As you mentioned in the DP hdcp shim review, we could use the array of
struct holding timeout and offsets for a msg.
This will help to avoid the one of two switch cases used for mapping the
timeout and offsets with msg_id.
-Ram
Just to keep the entire register i/o closely together.
-Daniel
+{
+ int timeout;
+
+ switch (msg_id) {
+ case HDCP_2_2_AKE_SEND_CERT:
+ timeout = HDCP_2_2_CERT_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_HPRIME:
+ if (is_paired)
+ timeout = HDCP_2_2_HPRIME_PAIRED_TIMEOUT;
+ else
+ timeout = HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT;
+ break;
+ case HDCP_2_2_AKE_SEND_PAIRING_INFO:
+ timeout = HDCP_2_2_PAIRING_TIMEOUT;
+ break;
+ case HDCP_2_2_LC_SEND_LPRIME:
+ timeout = HDCP_2_2_HDMI_LPRIME_TIMEOUT;
+ break;
+ case HDCP_2_2_REP_SEND_RECVID_LIST:
+ timeout = HDCP_2_2_RECVID_LIST_TIMEOUT;
+ break;
+ case HDCP_2_2_REP_STREAM_READY:
+ timeout = HDCP_2_2_STREAM_READY_TIMEOUT;
+ break;
+ default:
+ timeout = -EINVAL;
+ DRM_ERROR("Unsupported msg_id: %d\n", (int)msg_id);
+ }
+
+ return timeout;
+}
+
+static inline
+int hdcp2_detect_msg_availability(struct intel_digital_port
*intel_digital_port,
+ uint8_t msg_id, bool *msg_ready,
+ ssize_t *msg_sz)
+{
+ uint8_t rx_status[HDCP_2_2_HDMI_RXSTATUS_LEN];
+ int ret;
+
+ ret = intel_hdmi_hdcp2_read_rx_status(intel_digital_port, rx_status);
+ if (ret < 0) {
+ DRM_DEBUG_KMS("rx_status read failed. Err %d\n", ret);
+ return ret;
+ }
+
+ *msg_sz = ((HDCP_2_2_HDMI_RXSTATUS_MSG_SZ_HI(rx_status[1]) << 8) |
+ rx_status[0]);
+
+ if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST)
+ *msg_ready = (HDCP_2_2_HDMI_RXSTATUS_READY(rx_status[1]) &&
+*msg_sz);
+ else
+ *msg_ready = *msg_sz;
+
+ return 0;
+}
+
+static ssize_t
+intel_hdmi_hdcp2_wait_for_msg(struct intel_digital_port *intel_dig_port,
+ uint8_t msg_id, bool paired)
+{
+ bool msg_ready = false;
+ int timeout, ret;
+ ssize_t msg_sz;
+
+ timeout = intel_hdmi_hdcp2_timeout_for_msg(msg_id, paired);
+ if (timeout < 0)
+ return timeout;
+
+ ret = __wait_for(ret = hdcp2_detect_msg_availability(intel_dig_port,
+msg_id, _ready, _sz),
+!ret && msg_ready && msg_sz, timeout * 1000,
+1000, 5 * 1000);
+ if (ret)
+ DRM_ERROR("msg_id: %d, ret:
Re: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Wed, Jun 20, 2018 at 11:33 AM, Russell King - ARM Linux wrote: > On Wed, Jun 20, 2018 at 11:17:50AM +0200, Daniel Vetter wrote: >> Yes -modesetting (or whichever other driver) would need to set up the >> properties correctly for Xvideo color keying. Since default assumption for >> all other (generic) compositors is that planes won't do any color keying >> in the boot-up state. > > Thanks, is that documented anywhere? With the standardization of properties I'm also trying to get these expectations better documented, e.g. https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#plane-composition-properties But I think we're not doing a good job yet documenting default expectations. But the above would be a good place to get that fixed - this patch here should do that, at least for color keying. -Daniel > > -- > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up > According to speedtest.net: 8.21Mbps down 510kbps up -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 00/12] drm: Add generic fbdev emulation
On Mon, Jun 18, 2018 at 04:17:27PM +0200, Noralf Trønnes wrote: > This patchset adds generic fbdev emulation for drivers that supports GEM > based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An > API is begun to support in-kernel clients in general. > > Notable changes since version 1: > > - Rework client unregister code. I've used reference counting to manage > the fact that both the client itself and the driver through > drm_dev_unregister() can release the client. The client is now released > using drm_client_put() instead of drm_client_free(). I started reviewing the reworked client register/unregister stuff, and it looks good, except this kref stuff here for clients. I don't understand why you need this - as long as removal from dev->clientlist is properly protected by the mutex, I don't see how both the client and the device can release the client at the same time. Of course this means that both the device-trigger unregister and the client-triggered unregister must first grab the mutex, remove the client from the list, and only if that was done succesfully, clean up the client. If the client is already removed from the list (i.e. list_empty() is true) then you need to bail out to avoid double-freeing. I don't think there's a need to use a kref here. And kref has the tricky issue that you tempt everyone into constructing references loops between drm_device and drm_client (which require lots of jumping through hoops in your v1 to make sure you can break those reference loops). > - fbdev: Use a shadow buffer for framebuffers that have a dirty > callback. This makes the fbdev client truly generic and useable for all > drivers. There's a blitting penalty, but this is generic emulation after > all. The reason for needing a shadow buffer is that deferred I/O only > works with kmalloc/vmalloc buffers and not with shmem buffers > (page->lru/mapping). Yeah I think that's the only feasible option. Everyone who cares more about fbdev performance can keep their driver-specific code. And for other drm_client users this shouldn't be a problem, since they know how to use dirty and flipping between multiple buffers to drive kms as it was designed. The issue really only exists for fbdev's assumption of a direct mmap of a dumb framebuffer, encoded into the uapi. > - Let tinydrm use the full fbdev client \o/ Cheers, Daniel > > Noralf. > > Changes since version 1: > - Make it possible to embed struct drm_client_dev and drop the private > pointer > - Use kref reference counting to control client release since both the > client and the driver can release. > - Add comment about using dma-buf as a possibility with some rework > - Move buffer NULL check to drm_client_framebuffer_delete() > - Move client name to struct drm_client_dev > - Move up drm_dev_get/put calls to make them more visible > - Move drm_client_dev.list definition to later patch that makes use of it > > - Embed drm_client at the beginning of drm_fb_helper to avoid a fragile > transitional kfree hack in drm_client_release() > - Set owner in drm_fbdev_fb_ops > - Add kerneldoc to drm_fb_helper_generic_probe() > > - Remove unused functions > - Change name drm_client_funcs.lastclose -> .restore > - Change name drm_client_funcs.remove -> .unregister > - Rework unregister code > > - tinydrm: Use drm_fbdev_generic_setup() and remove > drm_fb_cma_fbdev_init_with_funcs() > > David Herrmann (1): > drm: provide management functions for drm_file > > Noralf Trønnes (11): > drm/file: Don't set master on in-kernel clients > drm: Make ioctls available for in-kernel clients > drm: Begin an API for in-kernel clients > drm/fb-helper: Add generic fbdev emulation .fb_probe function > drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap > drm/cma-helper: Use the generic fbdev emulation > drm/client: Add client callbacks > drm/debugfs: Add internal client debugfs file > drm/fb-helper: Finish the generic fbdev emulation > drm/tinydrm: Use drm_fbdev_generic_setup() > drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs() > > Documentation/gpu/drm-client.rst| 12 + > Documentation/gpu/index.rst | 1 + > drivers/gpu/drm/Makefile| 2 +- > drivers/gpu/drm/drm_client.c| 435 > > drivers/gpu/drm/drm_crtc_internal.h | 19 +- > drivers/gpu/drm/drm_debugfs.c | 7 + > drivers/gpu/drm/drm_drv.c | 8 + > drivers/gpu/drm/drm_dumb_buffers.c | 33 ++- > drivers/gpu/drm/drm_fb_cma_helper.c | 380 +++- > drivers/gpu/drm/drm_fb_helper.c | 330 - > drivers/gpu/drm/drm_file.c | 304 ++- > drivers/gpu/drm/drm_framebuffer.c | 42 ++- > drivers/gpu/drm/drm_internal.h | 2 + > drivers/gpu/drm/drm_ioctl.c | 4 +- >
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #16 from Michel Dänzer --- (In reply to SET from comment #15) > After narrowing good and bad commits between june 4th and 6th, it started to > test commits in april, then december. That's normal, due to the non-linear Git history of the Linux kernel. > Some commits don't compile and must be skipped. This is going endless, can't > continue. It will finish eventually. Can you attach the current output of git bisect log and tell us the commit it wants to test next? -- 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 106363] Powerplay support for SI asics
https://bugs.freedesktop.org/show_bug.cgi?id=106363 --- Comment #4 from Gregor Münch --- (In reply to Alex Deucher from comment #3) > dpm is enabled by default on SI parts so setting dpm=1 doesn't change > anything. This depends if you use amdgpu instead of radeon on SI. In that case amdgpu.dpm seems to be disabled. I tried to enable DPMS and read through a bunch of tutorials configuring Xorg but nothing did work. Then I stumbled about a newsentry on phoronix mentioned this patch: https://lists.freedesktop.org/archives/amd-gfx/2018-May/022771.html There you change the behavior for CIK parts to use PP by default. The logic of this patch changes amdgpu.dpm=-1 (auto) to switch from whatever to Powerplay. I started my Kernel with amdgpu.dpm=1 and everything suddenly worked like magic. Since I dont what Powerplay actually does in the Linux world and a quick google search came up with nothing and modinfo amdgpu just reveils dpm:DPM support (1 = enable, 0 = disable, -1 = auto) (int) but nothing about Powerplay I was really under the impression that DPM also enables Powerplay. Im sorry for the confusion. -- 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] [PATCH v2 09/12] drm/debugfs: Add internal client debugfs file
On Mon, Jun 18, 2018 at 04:17:36PM +0200, Noralf Trønnes wrote:
> Print the names of the internal clients currently attached.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_client.c | 28
> drivers/gpu/drm/drm_debugfs.c | 7 +++
> include/drm/drm_client.h | 2 ++
> 3 files changed, 37 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index f1dc04d641cc..3ebb8fa34655 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -405,3 +405,31 @@ void drm_client_framebuffer_delete(struct
> drm_client_buffer *buffer)
> drm_client_buffer_delete(buffer);
> }
> EXPORT_SYMBOL(drm_client_framebuffer_delete);
> +
> +#ifdef CONFIG_DEBUG_FS
> +static int drm_client_debugfs_internal_clients(struct seq_file *m, void
> *data)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_printer p = drm_seq_file_printer(m);
> + struct drm_client_dev *client;
> +
> + mutex_lock(>clientlist_mutex);
> + list_for_each_entry(client, >clientlist, list)
> + drm_printf(, "%s\n", client->name);
> + mutex_unlock(>clientlist_mutex);
> +
> + return 0;
> +}
> +
> +static const struct drm_info_list drm_client_debugfs_list[] = {
> + { "internal_clients", drm_client_debugfs_internal_clients, 0 },
> +};
> +
> +int drm_client_debugfs_init(struct drm_minor *minor)
> +{
> + return drm_debugfs_create_files(drm_client_debugfs_list,
> + ARRAY_SIZE(drm_client_debugfs_list),
> + minor->debugfs_root, minor);
> +}
> +#endif
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index b2482818fee8..50a20bfc07ea 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -28,6 +28,7 @@
> #include
> #include
>
> +#include
> #include
> #include
> #include
> @@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> DRM_ERROR("Failed to create framebuffer debugfs
> file\n");
> return ret;
> }
> +
> + ret = drm_client_debugfs_init(minor);
> + if (ret) {
> + DRM_ERROR("Failed to create client debugfs file\n");
> + return ret;
> + }
> }
>
> if (dev->driver->debugfs_init) {
> diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
> index 80fe21c86f69..c3a87d6c30fc 100644
> --- a/include/drm/drm_client.h
> +++ b/include/drm/drm_client.h
> @@ -151,4 +151,6 @@ struct drm_client_buffer *
> drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32
> height, u32 format);
> void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
>
> +int drm_client_debugfs_init(struct drm_minor *minor);
> +
> #endif
> --
> 2.15.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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: [RFC PATCH v2 1/2] drm: Add generic colorkey properties
On Tue, Jun 19, 2018 at 06:40:12PM +0100, Russell King - ARM Linux wrote: > On Tue, May 29, 2018 at 10:11:03AM +0300, Ville Syrjälä wrote: > > On Tue, May 29, 2018 at 02:48:22AM +0300, Dmitry Osipenko wrote: > > > Though maybe "color components replacement" and "replacement with a > > > complete > > > transparency" could be factored out into a specific color keying modes. > > > > Yes. I've never seen those in any hardware. In fact I'm wondering where > > is the userspace for all these complex modes? Ie. should we even bother > > with them at this time? > > Such hardware does exist - here's what Armada 510 supports (and is > supported via armada-drm): > > Color Key Mode > 0 = Disable: Disable color key function. > 1 = EnableY: Video Y color key is enabled. > 2 = EnableU: Video U color key is enabled. > 3 = EnableRGB: Graphic RGB color key is enabled. > 4 = EnableV: Video V color key is enabled. > 5 = EnableR: Graphic R color key is enabled. > 6 = EnableG: Graphic G color key is enabled. > 7 = EnableB: Graphic B color key is enabled. > > The description of how the colour keying works isn't particularly good, > which is rather unfortunate, but basically, there's three 32-bit > registers named LCD_SPU_COLORKEY_Y, LCD_SPU_COLORKEY_U and > LCD_SPU_COLORKEY_V. > > When a graphic mode is selected, then: > LCD_SPU_COLORKEY_Y is the R or B component depending on the red/blue swap > LCD_SPU_COLORKEY_U is the G component > LCD_SPU_COLORKEY_V is the B or R component according to the swap > > 31:24 is the high bound for the component (inclusive) > 23:16 is the low bound for the component (inclusive) > 15:8 is the replacement value for the component > 7:0 is the alpha value - seems to only be for LCD_SPU_COLORKEY_Y and > ignored in the other registers when in RGB mode, but I've not > fully tested this. I suspect it's used with the single-channel > colour keying modes. > > The colour key stage provides an alpha value to the next stage - which > is alpha blending between the graphic (primary) plane and video > (overlay) plane. Zero gives overlay only, 255 gives graphic only. > > So, it's possible to use an 0x0101fe (RGB) colour key, and have it > appear as "black" on the screen if you disable the overlay plane, > rather than the unsightly bright blue. > > One point to make though is about what userspace expects _today_ from > overlay. VLC, for example, expects overlay to be colour keyed, so it > can display its full-screen controller when the user moves the mouse. > I don't believe it explicitly sets up colour keying, but just expects > it to be there and functional. It _is_ rather necessary when you > consider that overlay via the Xvideo extension is supposed to be > "drawn" into the specified drawable, which may be a mapped window > partially obscured by other mapped windows. > > Maybe if the kernel DRM components doesn't want to do that, it'd be > something that an Xorg DDX would have to default-enable to ensure > that existing applications and expected Xorg behaviour doesn't break. Yes -modesetting (or whichever other driver) would need to set up the properties correctly for Xvideo color keying. Since default assumption for all other (generic) compositors is that planes won't do any color keying in the boot-up state. -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: [PATCH 9/9] drm/msm: Always obey implicit fencing
On Thu, Apr 05, 2018 at 05:44:49PM +0200, Daniel Vetter wrote:
> Again same justification as for drm_gem_fb_prepare_fb().
>
> Definitely needs some testing because Rob doesn't remember why he did
> this, and Google/git.fd.o or anything also doesn't shed some light on
> it.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
Just rebased this and noticed it's supreseeded by Sean Paul's work. I'd
appreciate some more official msm group maintainership so I have more
people to nag, since this not going anywhere has held up the entire patch
series.
-Daniel
> ---
> drivers/gpu/drm/msm/msm_atomic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_atomic.c
> b/drivers/gpu/drm/msm/msm_atomic.c
> index bf5f8c39f34d..0dcdc922fc61 100644
> --- a/drivers/gpu/drm/msm/msm_atomic.c
> +++ b/drivers/gpu/drm/msm/msm_atomic.c
> @@ -201,7 +201,7 @@ int msm_atomic_commit(struct drm_device *dev,
>* Figure out what fence to wait for:
>*/
> for_each_oldnew_plane_in_state(state, plane, old_plane_state,
> new_plane_state, i) {
> - if ((new_plane_state->fb != old_plane_state->fb) &&
> new_plane_state->fb) {
> + if (new_plane_state->fb) {
> struct drm_gem_object *obj =
> msm_framebuffer_bo(new_plane_state->fb, 0);
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> struct dma_fence *fence =
> reservation_object_get_excl_rcu(msm_obj->resv);
> --
> 2.16.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/4] drm/tinydrm: new dirver for ILI9341 displays
On Tue, Jun 19, 2018 at 5:36 PM, Noralf Trønnes wrote: > > Den 05.06.2018 17.49, skrev Noralf Trønnes: >> >> (cc: drm-misc maintainers) >> >> >> Den 04.06.2018 03.21, skrev David Lechner: >>> >>> >>> >>> On 6/3/18 5:00 PM, Noralf Trønnes wrote: Den 25.05.2018 21.36, skrev David Lechner: > > This series adds a new tinydrm driver for the Ilitek ILI9341 controller > and > a 2.4" display panel that uses this controller. David, do you have commit rights now? >>> >>> >>> No. Opened a bug a while back to request access, but I guess the >>> right person didn't see it. >>> >>> https://bugs.freedesktop.org/show_bug.cgi?id=105166 >>> >> >> Could someone please look at this? >> > > David, let's not stall this, if you resend with fixed up commit message and > acks/rbs, I'll apply it. I acked and forwarded the account request, sorry for the delay. Next time around, poking maintainers on irc helps if this stuff is stuck. -Daniel > > Noralf. > > >> Noralf. >> Noralf. > A few things to note here: > * The datasheet for this display[1] doesn't have a vendor mentioned on > it >anywhere, so I have used "adafruit" as the vendor prefix. If someone > has a >better suggestion, please speak up. > * The MAINTAINERS patch for ili9225 is included so we don't end up with > a merge >conflict later on. > > v2 changes: > * change vendor prefix from "noname" to "adafruit" > * new patch for "adafruit" vendor prefix > * minor style changes > * drop regulator from driver (instead of adding to DT bindings) > > [1]: > https://cdn-learn.adafruit.com/assets/assets/000/046/879/original/SPEC-YX240QV29-T_Rev.A__1_.pdf > > > David Lechner (4): >MAINTAINERS: fix path to ilitek,ili9225 device tree bindings >dt-bindings: Add vendor prefix for Adafruit >dt-bindings: new binding for Ilitek ILI9341 display panels >drm/tinydrm: new driver for ILI9341 display panels > > .../bindings/display/ilitek,ili9341.txt | 27 ++ > .../devicetree/bindings/vendor-prefixes.txt | 1 + > MAINTAINERS | 8 +- > drivers/gpu/drm/tinydrm/Kconfig | 10 + > drivers/gpu/drm/tinydrm/Makefile | 1 + > drivers/gpu/drm/tinydrm/ili9341.c | 233 > ++ > 6 files changed, 279 insertions(+), 1 deletion(-) > create mode 100644 > Documentation/devicetree/bindings/display/ilitek,ili9341.txt > create mode 100644 drivers/gpu/drm/tinydrm/ili9341.c > >> >> ___ >> 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105166] account request for drm-misc
https://bugs.freedesktop.org/show_bug.cgi?id=105166 Daniel Vetter changed: What|Removed |Added Product|DRI |freedesktop.org Component|General |New Accounts Version|DRI git |unspecified Assignee|dri-devel@lists.freedesktop |sitewranglers@lists.freedes |.org|ktop.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
[Bug 105166] account request for drm-misc
https://bugs.freedesktop.org/show_bug.cgi?id=105166 --- Comment #2 from Daniel Vetter --- Acked from my side. See https://01.org/linuxgraphics/gfx-docs/maintainer-tools/getting-started.html for getting started once you have commit rights. -- 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 106747] [CI] igt@* - crash - An internal exception that should have been handled was not: UnicodeDecodeError
https://bugs.freedesktop.org/show_bug.cgi?id=106747 --- Comment #3 from Petri Latvala --- The UnicodeDecodeError is in the results.json file as is, so it's produced at test run time, not an visualization generation error. The test printed something that wasn't valid UTF-8, and piglit is assuming everything printed is text (a fair assumption, you can argue). With the new runner this shouldn't be an issue any more. If this isn't reproduceable again, I don't know what else can be done to investigate this. -- 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 v2 05/14] drm/sti: Try to fix up the tvout possible clones
2018-06-18 14:38 GMT+02:00 Ville Syrjala : > From: Ville Syrjälä > > The current possible_clones setup doesn't look sensible. I'm assuming > the 0 and 1 are supposed to refer to the indexes of the hdmi and hda > encoders? So it kinda looks like we want hda+hdmi cloning, but then > dvo also claims to be cloneable with hdmi, but hdmi won't recipricate. > > Benjamin tells me all encoders should be cloneable with each other, > so let's fix up the masks to indicate that. > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Signed-off-by: Ville Syrjälä Acked-by: Benjamin Gaignard Thanks > --- > drivers/gpu/drm/sti/sti_tvout.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c > index 7d495307fe79..8bca519b3bfe 100644 > --- a/drivers/gpu/drm/sti/sti_tvout.c > +++ b/drivers/gpu/drm/sti/sti_tvout.c > @@ -668,7 +668,6 @@ sti_tvout_create_dvo_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_LVDS, > @@ -721,7 +720,6 @@ static struct drm_encoder > *sti_tvout_create_hda_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 0; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_DAC, NULL); > @@ -770,7 +768,6 @@ static struct drm_encoder > *sti_tvout_create_hdmi_encoder(struct drm_device *dev, > drm_encoder = >encoder; > > drm_encoder->possible_crtcs = ENCODER_CRTC_MASK; > - drm_encoder->possible_clones = 1 << 1; > > drm_encoder_init(dev, drm_encoder, > _tvout_encoder_funcs, DRM_MODE_ENCODER_TMDS, > NULL); > @@ -786,6 +783,13 @@ static void sti_tvout_create_encoders(struct drm_device > *dev, > tvout->hdmi = sti_tvout_create_hdmi_encoder(dev, tvout); > tvout->hda = sti_tvout_create_hda_encoder(dev, tvout); > tvout->dvo = sti_tvout_create_dvo_encoder(dev, tvout); > + > + tvout->hdmi->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->hda->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > + tvout->dvo->possible_clones = drm_encoder_mask(tvout->hdmi) | > + drm_encoder_mask(tvout->hda) | drm_encoder_mask(tvout->dvo); > } > > static void sti_tvout_destroy_encoders(struct sti_tvout *tvout) > -- > 2.16.4 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #10 from Giorgio (giorgio.colacc...@gmail.com) --- Hi Elmar, sorry that I couldn't be of any help to you.I hope that the the next (kernel) incremental patches will fix the bug... -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix pci_dev root device is NULL without check.
Op 19-06-18 om 09:47 schreef Caicai: > on my laptop with ATI Radeon R7 350 graphics card,I found root was > NULL,we should check > the device before get/set pcie speed cap mask. Here is my messages. > [8.996093] [drm] radeon kernel modesetting enabled. > [8.996093] [drm] initializing kernel modesetting (OLAND 0x1002:0x6610 > 0x174B:0xA00B). > [8.996093] [drm] register mmio base: 0x1000 > [8.996093] [drm] register mmio size: 262144 > [9.121093] ATOM BIOS: C55001 > [9.121093] [drm] GPU not posted. posting now... > [9.125000] radeon 0001:20:00.0: VRAM: 2048M 0x - > 0x7FFF (2048M used) > [9.125000] radeon 0001:20:00.0: GTT: 2048M 0x8000 - > 0x > [9.125000] [drm] Detected VRAM RAM=2048M, BAR=256M > [9.125000] [drm] RAM width 128bits DDR > [9.125000] [drm] radeon: 2048M of VRAM memory ready > [9.125000] [drm] radeon: 2048M of GTT memory ready. > [9.125000] [drm] Loading oland Microcode > [9.128906] [drm] Internal thermal controller with fan control > [9.128906] Unable to handle kernel paging request at virtual address > 003c > [9.128906] CPU 3 systemd-udevd(148): Oops 0 > [9.128906] pc = [] ra = [] ps = > Not tainted > [9.128906] pc is at drm_pcie_get_speed_cap_mask+0x3c/0x12c > [9.128906] ra is at si_dpm_init+0x64/0x1398 [radeon] > [9.128906] v0 = ffea t0 = fc07fcc3a400 t1 = > 1106 > [9.128906] t2 = 1166 t3 = t4 = > fc018eafc000 > [9.128906] t5 = ff80 t6 = 003f t7 = > fc07f6a9 > [9.128906] s0 = fc07f6a9390c s1 = s2 = > fc07f59119b0 > [9.128906] s3 = 0001 s4 = fff4 s5 = > fc07f591 > [9.128906] s6 = > [9.128906] a0 = fc07f706c800 a1 = fc07f6a9390c a2 = > fffc > [9.128906] a3 = 815fb510 a4 = 815fb4c8 a5 = > > [9.128906] t8 = 007f t9 = 80d86c14 t10= > 0001 > [9.128906] t11= 03c0 pv = 80e637e8 at = > > [9.128906] gp = 815e9230 sp = fc07f6a93868 > [9.128906] Disabling lock debugging due to kernel taint > [9.128906] Trace: > [9.128906] [] drm_dev_register+0xb0/0x138 > [9.128906] [] drm_get_pci_dev+0x120/0x208 > [9.128906] [] local_pci_probe+0x38/0x8c > [9.128906] [] pci_device_probe+0x170/0x1d0 > [9.128906] [] driver_probe_device+0x168/0x2fc > [9.128906] [] __driver_attach+0x94/0xe8 > [9.128906] [] bus_for_each_dev+0x94/0xd4 > [9.128906] [] __driver_attach+0x0/0xe8 > [9.128906] [] driver_attach+0x2c/0x40 > [9.128906] [] bus_add_driver+0x140/0x2d4 > [9.128906] [] driver_register+0x100/0x180 > [9.128906] [] __pci_register_driver+0x48/0x5c > [9.128906] [] drm_pci_init+0x7c/0x168 > [9.128906] [] do_one_initcall+0x188/0x25c > [9.128906] [] do_init_module+0x8c/0x2c8 > [9.128906] [] kmem_cache_alloc+0x1f8/0x22c > [9.128906] [] do_init_module+0x40/0x2c8 > [9.128906] [] load_module+0x1ea8/0x263c > [9.128906] [] unknown_module_param_cb+0x0/0xc8 > [9.128906] [] SYSC_finit_module+0x94/0xb4 > [9.128906] [] module_notes_read+0x0/0x4c > [9.128906] [] entSys+0xa0/0xc0 Grepping on entSys the only mention is on alpha. Is dev->pdev->bus->parent NULL by any chance? > [9.128906] Code: 8c300188 c020003b 8c210010 f85f1106 f87f1166 > 8d410038 <842a003c> 40220502 > [9.128906] systemd-udevd[136]: worker [148] terminated by signal 11 > (Segmentation fault) > > Signed-off-by: Caicai > --- > drivers/gpu/drm/drm_pci.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c > index 4db9c515b74f..3d1cd760b79c 100644 > --- a/drivers/gpu/drm/drm_pci.c > +++ b/drivers/gpu/drm/drm_pci.c > @@ -332,10 +332,12 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, > u32 *mask) > u32 lnkcap, lnkcap2; > > *mask = 0; > - if (!dev->pdev) > + if (!dev->pdev || !dev->pdev->bus) > return -EINVAL; I think we can assume our device is on a bus. > root = dev->pdev->bus->self; > + if (!root) > + return -EINVAL; I'm not a PCI expert, but seems like a bad design to say none of the speeds are supported just because we lack a bridge. btw, drm_pcie_get_max_link_width is similarly affected. ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #15 from SET --- After narrowing good and bad commits between june 4th and 6th, it started to test commits in april, then december. Some commits don't compile and must be skipped. This is going endless, can't continue. -- 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 v7 12/29] drm/mediatek: Update the definition of connection from RDMA1 to DPI0
On Wed, 2018-06-20 at 16:19 +0800, Stu Hsieh wrote:
> This patch update the definition of connection from RDMA1 to DPI0.
> Change the term MOUT to SOUT.
>
> Because our HW datasheet use the term SOUT to match its function for RDMA.
> For consistency, changing the name from MOUT to SOUT is better.
>
Reviewed-by: CK Hu
> Signed-off-by: Stu Hsieh
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index 8bfc0debd2c2..977df8facb79 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -29,7 +29,7 @@
> #define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084
> #define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088
> #define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
> -#define DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN 0x0c8
> +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
> #define DISP_REG_CONFIG_MMSYS_CG_CON00x100
>
> #define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030
> @@ -80,7 +80,7 @@
> #define COLOR0_SEL_IN_OVL0 0x1
> #define OVL1_MOUT_EN_COLOR1 0x1
> #define GAMMA_MOUT_EN_RDMA1 0x1
> -#define RDMA1_MOUT_DPI0 0x2
> +#define RDMA1_SOUT_DPI0 0x2
> #define DPI0_SEL_IN_RDMA10x1
> #define COLOR1_SEL_IN_OVL1 0x1
>
> @@ -156,8 +156,8 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
> cur,
> *addr = DISP_REG_CONFIG_DISP_OD_MOUT_EN;
> value = OD1_MOUT_EN_RDMA1;
> } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI0) {
> - *addr = DISP_REG_CONFIG_DISP_RDMA1_MOUT_EN;
> - value = RDMA1_MOUT_DPI0;
> + *addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
> + value = RDMA1_SOUT_DPI0;
> } else {
> value = 0;
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 05/29] drm/mediatek: add ddp component PWM1
This patch add component PWM1 in mtk_ddp_matches
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 87acf6be87f6..a5c7ac2d162d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -232,6 +232,7 @@ static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, NULL },
[DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, NULL },
[DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
+ [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
[DDP_COMPONENT_RDMA0] = { MTK_DISP_RDMA, 0, NULL },
[DDP_COMPONENT_RDMA1] = { MTK_DISP_RDMA, 1, NULL },
[DDP_COMPONENT_RDMA2] = { MTK_DISP_RDMA, 2, NULL },
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 20/29] drm/mediatek: add connection from RDMA2 to DPI0
This patch add the connection from RDMA2 to DPI0
Signed-off-by: Stu Hsieh
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
index d0d5f337ce14..c88742a6c2b9 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
@@ -31,6 +31,7 @@
#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4
#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8
#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac
+#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8
#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4
#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8
#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100
@@ -91,7 +92,9 @@
#define RDMA1_SOUT_DSI10x1
#define RDMA1_SOUT_DSI20x4
#define RDMA1_SOUT_DSI30x5
+#define RDMA2_SOUT_DPI00x2
#define DPI0_SEL_IN_RDMA1 0x1
+#define DPI0_SEL_IN_RDMA2 0x3
#define DPI1_SEL_IN_RDMA1 (0x1 << 8)
#define DSI1_SEL_IN_RDMA1 0x1
#define DSI2_SEL_IN_RDMA1 (0x1 << 16)
@@ -193,6 +196,9 @@ static unsigned int mtk_ddp_mout_en(enum mtk_ddp_comp_id
cur,
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DPI1) {
*addr = DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN;
value = RDMA1_SOUT_DPI1;
+ } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
+ *addr = DISP_REG_CONFIG_DISP_RDMA2_SOUT;
+ value = RDMA2_SOUT_DPI0;
} else {
value = 0;
}
@@ -224,6 +230,9 @@ static unsigned int mtk_ddp_sel_in(enum mtk_ddp_comp_id cur,
} else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI3) {
*addr = DISP_REG_CONFIG_DSIO_SEL_IN;
value = DSI3_SEL_IN_RDMA1;
+ } else if (cur == DDP_COMPONENT_RDMA2 && next == DDP_COMPONENT_DPI0) {
+ *addr = DISP_REG_CONFIG_DPI_SEL_IN;
+ value = DPI0_SEL_IN_RDMA2;
} else if (cur == DDP_COMPONENT_OVL1 && next == DDP_COMPONENT_COLOR1) {
*addr = DISP_REG_CONFIG_DISP_COLOR1_SEL_IN;
value = COLOR1_SEL_IN_OVL1;
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v7 27/29] drm/mediatek: add DSI3 support for mutex
This patch add the DSI3 support for mutex Signed-off-by: Stu Hsieh Reviewed-by: CK Hu --- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c index a0b526b16da1..15e436d4e8a0 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c @@ -78,6 +78,7 @@ #define MUTEX_SOF_DPI0 3 #define MUTEX_SOF_DPI1 4 #define MUTEX_SOF_DSI2 5 +#define MUTEX_SOF_DSI3 6 #define OVL0_MOUT_EN_COLOR00x1 #define OD_MOUT_EN_RDMA0 0x1 @@ -387,6 +388,9 @@ void mtk_disp_mutex_add_comp(struct mtk_disp_mutex *mutex, case DDP_COMPONENT_DSI2: reg = MUTEX_SOF_DSI2; break; + case DDP_COMPONENT_DSI3: + reg = MUTEX_SOF_DSI3; + break; case DDP_COMPONENT_DPI0: reg = MUTEX_SOF_DPI0; break; @@ -425,6 +429,7 @@ void mtk_disp_mutex_remove_comp(struct mtk_disp_mutex *mutex, case DDP_COMPONENT_DSI0: case DDP_COMPONENT_DSI1: case DDP_COMPONENT_DSI2: + case DDP_COMPONENT_DSI3: case DDP_COMPONENT_DPI0: case DDP_COMPONENT_DPI1: writel_relaxed(MUTEX_SOF_SINGLE_MODE, -- 2.12.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
