Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
Hi Maxime,
Some comments below...
On 3/19/19 10:57 PM, Maxime Ripard wrote:
> V4L2 uses different fourcc's than DRM, and has a different set of formats.
> For now, let's add the v4l2 fourcc's for the already existing formats.
>
> Signed-off-by: Maxime Ripard
> ---
> include/linux/image-formats.h | 9 +-
> lib/image-formats.c | 67 -
> 2 files changed, 76 insertions(+)
>
> diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
> index 53fd73a71b3d..fbc3a4501ebd 100644
> --- a/include/linux/image-formats.h
> +++ b/include/linux/image-formats.h
> @@ -26,6 +26,13 @@ struct image_format_info {
> };
>
> /**
> + * @v4l2_fmt:
> + *
> + * V4L2 4CC format identifier (V4L2_PIX_FMT_*)
> + */
> + u32 v4l2_fmt;
> +
> + /**
>* @depth:
>*
>* Color depth (number of bits per pixel excluding padding bits),
> @@ -222,6 +229,8 @@ image_format_info_is_yuv_sampling_444(const struct
> image_format_info *info)
>
> const struct image_format_info *__image_format_drm_lookup(u32 drm);
> const struct image_format_info *image_format_drm_lookup(u32 drm);
> +const struct image_format_info *__image_format_v4l2_lookup(u32 v4l2);
> +const struct image_format_info *image_format_v4l2_lookup(u32 v4l2);
> unsigned int image_format_plane_cpp(const struct image_format_info *format,
> int plane);
> unsigned int image_format_plane_width(int width,
> diff --git a/lib/image-formats.c b/lib/image-formats.c
> index 9b9a73220c5d..39f1d38ae861 100644
> --- a/lib/image-formats.c
> +++ b/lib/image-formats.c
> @@ -8,6 +8,7 @@
> static const struct image_format_info formats[] = {
> {
> .drm_fmt = DRM_FORMAT_C8,
> + .v4l2_fmt = V4L2_PIX_FMT_GREY,
> .depth = 8,
> .num_planes = 1,
> .cpp = { 1, 0, 0 },
> @@ -15,6 +16,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_RGB332,
> + .v4l2_fmt = V4L2_PIX_FMT_RGB332,
> .depth = 8,
> .num_planes = 1,
> .cpp = { 1, 0, 0 },
> @@ -29,6 +31,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_XRGB,
> + .v4l2_fmt = V4L2_PIX_FMT_XRGB444,
> .depth = 0,
> .num_planes = 1,
> .cpp = { 2, 0, 0 },
> @@ -57,6 +60,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_ARGB,
> + .v4l2_fmt = V4L2_PIX_FMT_ARGB444,
> .depth = 0,
> .num_planes = 1,
> .cpp = { 2, 0, 0 },
> @@ -89,6 +93,7 @@ static const struct image_format_info formats[] = {
> .has_alpha = true,
> }, {
> .drm_fmt = DRM_FORMAT_XRGB1555,
> + .v4l2_fmt = V4L2_PIX_FMT_XRGB555,
> .depth = 15,
> .num_planes = 1,
> .cpp = { 2, 0, 0 },
> @@ -117,6 +122,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_ARGB1555,
> + .v4l2_fmt = V4L2_PIX_FMT_ARGB555,
> .depth = 15,
> .num_planes = 1,
> .cpp = { 2, 0, 0 },
> @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
> .has_alpha = true,
> }, {
> .drm_fmt = DRM_FORMAT_RGB565,
> + .v4l2_fmt = V4L2_PIX_FMT_RGB565,
> .depth = 16,
> .num_planes = 1,
> .cpp = { 2, 0, 0 },
> @@ -163,6 +170,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_RGB888,
> + .v4l2_fmt = V4L2_PIX_FMT_RGB24,
The V4L2 pixelformats describe the order of the components in memory, and as
such are independent of the CPU endianness. How is that for the DRM formats?
Will the order of DRM_FORMAT_RGB888 in memory differ between little and big
endian systems?
Mind you, V4L2 drivers are frankly never tested on big endian systems and I
suspect many if not all will fail miserably on details like this.
> .depth = 24,
> .num_planes = 1,
> .cpp = { 3, 0, 0 },
> @@ -170,6 +178,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_BGR888,
> + .v4l2_fmt = V4L2_PIX_FMT_BGR24,
> .depth = 24,
> .num_planes = 1,
> .cpp = { 3, 0, 0 },
> @@ -177,6 +186,7 @@ static const struct image_format_info formats[] = {
> .vsub = 1,
> }, {
> .drm_fmt = DRM_FORMAT_XRGB,
> + .v4l2_fmt = V4L2_PIX_FMT
Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
On 4/11/19 9:12 AM, Hans Verkuil wrote:
> Hi Maxime,
>
> Some comments below...
>
> On 3/19/19 10:57 PM, Maxime Ripard wrote:
>> V4L2 uses different fourcc's than DRM, and has a different set of formats.
>> For now, let's add the v4l2 fourcc's for the already existing formats.
>>
>> Signed-off-by: Maxime Ripard
>> ---
>> include/linux/image-formats.h | 9 +-
>> lib/image-formats.c | 67 -
>> 2 files changed, 76 insertions(+)
>>
>> diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
>> index 53fd73a71b3d..fbc3a4501ebd 100644
>> --- a/include/linux/image-formats.h
>> +++ b/include/linux/image-formats.h
>> @@ -26,6 +26,13 @@ struct image_format_info {
>> };
>>
>> /**
>> + * @v4l2_fmt:
>> + *
>> + * V4L2 4CC format identifier (V4L2_PIX_FMT_*)
>> + */
>> +u32 v4l2_fmt;
>> +
>> +/**
>> * @depth:
>> *
>> * Color depth (number of bits per pixel excluding padding bits),
>> @@ -222,6 +229,8 @@ image_format_info_is_yuv_sampling_444(const struct
>> image_format_info *info)
>>
>> const struct image_format_info *__image_format_drm_lookup(u32 drm);
>> const struct image_format_info *image_format_drm_lookup(u32 drm);
>> +const struct image_format_info *__image_format_v4l2_lookup(u32 v4l2);
>> +const struct image_format_info *image_format_v4l2_lookup(u32 v4l2);
>> unsigned int image_format_plane_cpp(const struct image_format_info *format,
>> int plane);
>> unsigned int image_format_plane_width(int width,
>> diff --git a/lib/image-formats.c b/lib/image-formats.c
>> index 9b9a73220c5d..39f1d38ae861 100644
>> --- a/lib/image-formats.c
>> +++ b/lib/image-formats.c
>> @@ -8,6 +8,7 @@
>> static const struct image_format_info formats[] = {
>> {
>> .drm_fmt = DRM_FORMAT_C8,
>> +.v4l2_fmt = V4L2_PIX_FMT_GREY,
>> .depth = 8,
>> .num_planes = 1,
>> .cpp = { 1, 0, 0 },
>> @@ -15,6 +16,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_RGB332,
>> +.v4l2_fmt = V4L2_PIX_FMT_RGB332,
>> .depth = 8,
>> .num_planes = 1,
>> .cpp = { 1, 0, 0 },
>> @@ -29,6 +31,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_XRGB,
>> +.v4l2_fmt = V4L2_PIX_FMT_XRGB444,
>> .depth = 0,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -57,6 +60,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_ARGB,
>> +.v4l2_fmt = V4L2_PIX_FMT_ARGB444,
>> .depth = 0,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -89,6 +93,7 @@ static const struct image_format_info formats[] = {
>> .has_alpha = true,
>> }, {
>> .drm_fmt = DRM_FORMAT_XRGB1555,
>> +.v4l2_fmt = V4L2_PIX_FMT_XRGB555,
>> .depth = 15,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -117,6 +122,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_ARGB1555,
>> +.v4l2_fmt = V4L2_PIX_FMT_ARGB555,
>> .depth = 15,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
>> .has_alpha = true,
>> }, {
>> .drm_fmt = DRM_FORMAT_RGB565,
>> +.v4l2_fmt = V4L2_PIX_FMT_RGB565,
>> .depth = 16,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -163,6 +170,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_RGB888,
>> +.v4l2_fmt = V4L2_PIX_FMT_RGB24,
>
> The V4L2 pixelformats describe the order of the components in memory, and as
> such are independent of the CPU endianness. How is that for the DRM formats?
>
> Will the order of DRM_FORMAT_RGB888 in memory differ between little and big
> endian systems?
>
> Mind you, V4L2 drivers are frankly never tested on big endian systems and I
> suspect many if not all will fail miserably on details like this.
Never mind, I now see that there was a long discussion about this same topic.
Hans
>
>> .depth = 24,
>> .num_planes = 1,
>> .cpp = { 3, 0, 0 },
>> @@ -170,6 +178,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_BGR888,
>> +.v4l2_fmt = V4L2_PIX_FMT_BGR24,
>> .depth = 24,
>> .num_planes = 1,
>> .cpp = { 3, 0, 0 },
>
Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
On 4/1/19 4:44 PM, Maxime Ripard wrote: > Hi Nicolas, > > On Fri, Mar 22, 2019 at 03:55:19PM -0400, Nicolas Dufresne wrote: >> Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit : >>> V4L2 uses different fourcc's than DRM, and has a different set of formats. >>> For now, let's add the v4l2 fourcc's for the already existing formats. >> >> Hopefully I get the fixup right this time, see inline. > > Thanks a lot for that extensive review. > > About the single vs multi-planar issue, I'd be inclined with just > supporting single-planar formats for now, and extend it later to deal > with multiplanar formats. > > Would that work for everyone? I'd say that is the right approach. Regards, Hans > > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #10 from Allan Cairns --- Created attachment 143935 --> https://bugs.freedesktop.org/attachment.cgi?id=143935&action=edit AmigaOne DRM Issues Third time lucky? -- 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 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #11 from Allan Cairns --- Alex Hopefully these are what you are after. I was told to use less with dmseg so not sure if that caused the problem. Allan -- 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 3/8] dt-bindings: gpu: mali-midgard: Add h6 mali gpu compatible
On Thu, Apr 11, 2019 at 01:25:38AM +0200, Clément Péron wrote: > This add the H6 mali compatible in the dt-bindings to later support > specific implementation. > > Signed-off-by: Clément Péron > --- > .../devicetree/bindings/gpu/arm,mali-midgard.txt | 8 +++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > index 2e8bbce35695..9e71146b5c8a 100644 > --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt > @@ -15,6 +15,7 @@ Required properties: > + "arm,mali-t860" > + "arm,mali-t880" >* which must be preceded by one of the following vendor specifics: > ++ "allwinner,sun50i-h6-mali" > + "amlogic,meson-gxm-mali" > + "rockchip,rk3288-mali" > + "rockchip,rk3399-mali" > @@ -49,9 +50,14 @@ Vendor-specific bindings > > > The Mali GPU is integrated very differently from one SoC to > -another. In order to accomodate those differences, you have the option > +another. In order to accommodate those differences, you have the option > to specify one more vendor-specific compatible, among: > > +- "allwinner,sun50i-h6-mali" > + Required properties: > + - resets: Should contain phandle of : > ++ GPU reset line > + And clocks, I assume? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
On Thu, Apr 11, 2019 at 01:25:39AM +0200, Clément Péron wrote:
> Add the mali gpu node to the H6 device-tree.
>
> Signed-off-by: Clément Péron
> ---
> arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
> 1 file changed, 80 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> index e0dc4a05c1ba..152b2128aadf 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> @@ -17,6 +17,71 @@
> #address-cells = <1>;
> #size-cells = <1>;
>
> + gpu_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> +
> + opp@75600 {
> + opp-hz = /bits/ 64 <75600>;
> + opp-microvolt = <104>;
> + };
> + opp@62400 {
> + opp-hz = /bits/ 64 <62400>;
> + opp-microvolt = <95>;
> + };
> + opp@57600 {
> + opp-hz = /bits/ 64 <57600>;
> + opp-microvolt = <93>;
> + };
> + opp@54000 {
> + opp-hz = /bits/ 64 <54000>;
> + opp-microvolt = <91>;
> + };
> + opp@50400 {
> + opp-hz = /bits/ 64 <50400>;
> + opp-microvolt = <89>;
> + };
> + opp@45600 {
> + opp-hz = /bits/ 64 <45600>;
> + opp-microvolt = <87>;
> + };
> + opp@43200 {
> + opp-hz = /bits/ 64 <43200>;
> + opp-microvolt = <86>;
> + };
> + opp@42000 {
> + opp-hz = /bits/ 64 <42000>;
> + opp-microvolt = <85>;
> + };
> + opp@40800 {
> + opp-hz = /bits/ 64 <40800>;
> + opp-microvolt = <84>;
> + };
> + opp@38400 {
> + opp-hz = /bits/ 64 <38400>;
> + opp-microvolt = <83>;
> + };
> + opp@36000 {
> + opp-hz = /bits/ 64 <36000>;
> + opp-microvolt = <82>;
> + };
> + opp@33600 {
> + opp-hz = /bits/ 64 <33600>;
> + opp-microvolt = <81>;
> + };
> + opp@31200 {
> + opp-hz = /bits/ 64 <31200>;
> + opp-microvolt = <81>;
> + };
> + opp@26400 {
> + opp-hz = /bits/ 64 <26400>;
> + opp-microvolt = <81>;
> + };
> + opp@21600 {
> + opp-hz = /bits/ 64 <21600>;
> + opp-microvolt = <81>;
> + };
> + };
> +
How were those OPPs tested?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
On 3/22/19 8:55 PM, Nicolas Dufresne wrote:
> Le mardi 19 mars 2019 à 22:57 +0100, Maxime Ripard a écrit :
>> V4L2 uses different fourcc's than DRM, and has a different set of formats.
>> For now, let's add the v4l2 fourcc's for the already existing formats.
>
> Hopefully I get the fixup right this time, see inline.
>
>>
>> Signed-off-by: Maxime Ripard
>> ---
>> include/linux/image-formats.h | 9 +-
>> lib/image-formats.c | 67 -
>> 2 files changed, 76 insertions(+)
>>
>> diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
>> index 53fd73a71b3d..fbc3a4501ebd 100644
>> --- a/include/linux/image-formats.h
>> +++ b/include/linux/image-formats.h
>> @@ -26,6 +26,13 @@ struct image_format_info {
>> };
>>
>> /**
>> + * @v4l2_fmt:
>> + *
>> + * V4L2 4CC format identifier (V4L2_PIX_FMT_*)
>> + */
>> +u32 v4l2_fmt;
>> +
>> +/**
>> * @depth:
>> *
>> * Color depth (number of bits per pixel excluding padding bits),
>> @@ -222,6 +229,8 @@ image_format_info_is_yuv_sampling_444(const struct
>> image_format_info *info)
>>
>> const struct image_format_info *__image_format_drm_lookup(u32 drm);
>> const struct image_format_info *image_format_drm_lookup(u32 drm);
>> +const struct image_format_info *__image_format_v4l2_lookup(u32 v4l2);
>> +const struct image_format_info *image_format_v4l2_lookup(u32 v4l2);
>> unsigned int image_format_plane_cpp(const struct image_format_info *format,
>> int plane);
>> unsigned int image_format_plane_width(int width,
>> diff --git a/lib/image-formats.c b/lib/image-formats.c
>> index 9b9a73220c5d..39f1d38ae861 100644
>> --- a/lib/image-formats.c
>> +++ b/lib/image-formats.c
>> @@ -8,6 +8,7 @@
>> static const struct image_format_info formats[] = {
>> {
>> .drm_fmt = DRM_FORMAT_C8,
>> +.v4l2_fmt = V4L2_PIX_FMT_GREY,
>> .depth = 8,
>> .num_planes = 1,
>> .cpp = { 1, 0, 0 },
>> @@ -15,6 +16,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_RGB332,
>> +.v4l2_fmt = V4L2_PIX_FMT_RGB332,
>> .depth = 8,
>> .num_planes = 1,
>> .cpp = { 1, 0, 0 },
>> @@ -29,6 +31,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_XRGB,
>> +.v4l2_fmt = V4L2_PIX_FMT_XRGB444,
>
> Not completely sure, looks like in the V4L2 variant, the padding is on
> the 4 MSB of the second byte, which makes it incompatible. There is no
> other equivalent.
>
>> .depth = 0,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -57,6 +60,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_ARGB,
>> +.v4l2_fmt = V4L2_PIX_FMT_ARGB444,
>
> Similarly.
>
>> .depth = 0,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -89,6 +93,7 @@ static const struct image_format_info formats[] = {
>> .has_alpha = true,
>> }, {
>> .drm_fmt = DRM_FORMAT_XRGB1555,
>> +.v4l2_fmt = V4L2_PIX_FMT_XRGB555,
>
> Same swapping, can't find a match.
>
>> .depth = 15,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -117,6 +122,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_ARGB1555,
>> +.v4l2_fmt = V4L2_PIX_FMT_ARGB555,
>
> Same.
>
>> .depth = 15,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
>> .has_alpha = true,
>> }, {
>> .drm_fmt = DRM_FORMAT_RGB565,
>> +.v4l2_fmt = V4L2_PIX_FMT_RGB565,
>
> -> V4L2_PIX_FMT_RGB565X
>
> Was added later, as what you expect is not compatible.
All these 16-bit V4L2 pixelformats are ancient, but they are (to my knowledge)
correct w.r.t. the documented layout of the bits in memory. I.e., that's what
the hardware will give you.
I think if there is no equivalence between the drm and v4l2 fourcc's, then
you need two entries in this table, one for drm (v4l2_fmt == 0), one for v4l2
(drm_fmt == 0).
>
>> .depth = 16,
>> .num_planes = 1,
>> .cpp = { 2, 0, 0 },
>> @@ -163,6 +170,7 @@ static const struct image_format_info formats[] = {
>> .vsub = 1,
>> }, {
>> .drm_fmt = DRM_FORMAT_RGB888,
>> +.v4l2_fmt = V4L2_PIX_FMT_RGB24,
>
> -> V4L2_PIX_FMT_BGR24
>
>> .depth = 24,
>> .num_planes = 1,
>> .cpp = { 3, 0, 0 },
>> @@ -170,6 +178,7 @@ static const struct im
[Bug 110376] [CI][SHARDS] igt@kms_cursor_legacy@nonblocking-modeset-vs-cursor-atomic - dmesg-warn - *ERROR* Failed to enable hdcp (-110)
https://bugs.freedesktop.org/show_bug.cgi?id=110376
--- Comment #2 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- KBL: igt@kms_cursor_legacy@nonblocking-modeset-vs-cursor-atomic - dmesg-warn
- *ERROR* Failed to enable hdcp (-110) -}
{+ all machines: all tests - dmesg-warn - *ERROR* Failed to enable hdcp (-110)
+}
New failures caught by the filter:
*
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4939/shard-apl3/igt@vgem_s...@nohang.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4939/shard-kbl2/igt@kms_seque...@get-busy.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5899/shard-apl6/igt@kms_seque...@get-busy.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5899/shard-apl7/igt@kms_vbl...@pipe-c-query-forked.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5899/shard-kbl2/igt@kms_seque...@get-busy.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4940/shard-apl2/igt@kms_co...@pipe-b-degamma.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4941/shard-apl7/igt@kms_cursor_leg...@pipe-b-forked-bo.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4942/shard-apl6/igt@gem_tiled_bl...@interruptible.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5901/shard-apl3/igt@gem_mmap_...@forked-big-copy-odd.html
*
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5902/shard-apl6/igt@gem_mmap_...@forked-big-copy-odd.html
--
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 110376] [CI][SHARDS] igt@* - dmesg-warn - *ERROR* Failed to enable hdcp (-110)
https://bugs.freedesktop.org/show_bug.cgi?id=110376 Martin Peres changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |elong...@gmail.com |.org| Summary|[CI][SHARDS]|[CI][SHARDS] igt@* - |igt@kms_cursor_legacy@nonbl |dmesg-warn - *ERROR* Failed |ocking-modeset-vs-cursor-at |to enable hdcp (-110) |omic - dmesg-warn - *ERROR* | |Failed to enable hdcp | |(-110) | --- Comment #3 from Martin Peres --- GG, could you take a look at this? This should be a trivial patch but we need this fast as it causes a lot of noise in CI. -- 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] [v2 0/7] Add Multi Segment Gamma Support
>> >> >-Original Message- >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On >> >Behalf Of Ville Syrjälä >> >Sent: Monday, April 8, 2019 9:38 PM >> >To: Shankar, Uma >> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri- >> >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville >> >; Lankhorst, Maarten >> > >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support >> > >> >On Mon, Apr 08, 2019 at 03:59:51PM +, Shankar, Uma wrote: >> >> >> >> >> >> >-Original Message- >> >> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] >> >> >On Behalf Of Ville Syrjälä >> >> >Sent: Monday, April 8, 2019 9:15 PM >> >> >To: Shankar, Uma >> >> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; dri- >> >> >de...@lists.freedesktop.org; seanp...@chromium.org; Syrjala, Ville >> >> >; Lankhorst, Maarten >> >> > >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support >> >> > >> >> >On Mon, Apr 08, 2019 at 03:40:39PM +, Shankar, Uma wrote: >> >> >> >> >> >> >> >> >> >-Original Message- >> >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> >> >Sent: Monday, April 8, 2019 8:27 PM >> >> >> >To: Shankar, Uma >> >> >> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; >> >> >> >Syrjala, Ville ; Lankhorst, Maarten >> >> >> > >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma >> >> >> >Support >> >> >> > >> >> >> >On Mon, Apr 08, 2019 at 02:40:51PM +, Shankar, Uma wrote: >> >> >> >> >> >> >> >> >> >> >> >> >-Original Message- >> >> >> >> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >> >> >> >> >Sent: Monday, April 8, 2019 6:01 PM >> >> >> >> >To: Shankar, Uma >> >> >> >> >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; >> >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; >> >> >> >> >Syrjala, Ville ; Lankhorst, Maarten >> >> >> >> > >> >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma >> >> >> >> >Support >> >> >> >> > >> >> >> >> >On Mon, Apr 08, 2019 at 12:26:23PM +, Shankar, Uma wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >-Original Message- >> >> >> >> >> >From: dri-devel >> >> >> >> >> >[mailto:dri-devel-boun...@lists.freedesktop.org] >> >> >> >> >> >On Behalf Of Ville Syrjälä >> >> >> >> >> >Sent: Friday, April 5, 2019 9:42 PM >> >> >> >> >> >To: Shankar, Uma >> >> >> >> >> >Cc: dcasta...@chromium.org; >> >> >> >> >> >intel-...@lists.freedesktop.org; >> >> >> >> >> >dri- de...@lists.freedesktop.org; seanp...@chromium.org; >> >> >> >> >> >Syrjala, Ville ; Lankhorst, >> >> >> >> >> >Maarten >> >> >> >> >> >Subject: Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma >> >> >> >> >> >Support >> >> >> >> >> > >> >> >> >> >> >On Mon, Apr 01, 2019 at 11:00:04PM +0530, Uma Shankar wrote: >> >> >> >> >> >> This series adds support for programmable gamma modes >> >> >> >> >> >> and exposes a property interface for the same. Also >> >> >> >> >> >> added, support for multi segment gamma mode introduced >> >> >> >> >> >> in ICL+ >> >> >> >> >> >> >> >> >> >> >> >> It creates 2 property interfaces : >> >> >> >> >> >> 1. GAMMA_MODE_CAPS: This is immutable property and >> >> >> >> >> >> exposes the various gamma modes supported and the lut >> >> >> >> >> >> ranges. This is an enum property with element as blob >> >> >> >> >> >> id. Getting the blob id in userspace, user can get the >> >> >> >> >> >> mode supported and also the range of gamma mode >> >> >> >> >> >> supported with number of lut >> >coefficients. >> >> >> >> >> >> >> >> >> >> >> >> 2. GAMMA_MODE: This is for user to set the gamma mode >> >> >> >> >> >> and send the lut values for that particular mode. >> >> >> >> >> > >> >> >> >> >> >I think we should just go for the BLOB_ENUM prop type instead. >> >> >> >> >> >Then the possible values and the current value are all >> >> >> >> >> >part of the same >> >prop. >> >> >> >> >> >> >> >> >> >> Hi Ville, >> >> >> >> >> With the current approach, we have enum property with >> >> >> >> >> values as blob_ids (representing platform capabilities). >> >> >> >> >> This should not get modified and needs to be immutable. >> >> >> >> > >> >> >> >> >That's not quite what we want. We want to let the user >> >> >> >> >modify the current value so that they can actually select the gamma >mode. >> >> >> >> >Otherwise we need yet another prop for it, or we have to >> >> >> >> >deduce it from the LUT size (that apporach would actually >> >> >> >> >work for >> >> >> >> >i915 but may not work for other drivers/hardware). >> >> >> >> > >> >> >> >> >> >> >> >> >> >> Userspace can query the property and get the blob using the >> >> >> >> >> blob_ids. >> >> >> >> >> Thereby getting all the platform capabilities. >> >> >> >> >> >> >> >> >> >> Now to set the LUT values, he can use another blob >> >> >> >> >> property a
[PATCH 1/8] dt-bindings: gpu: mali-midgard: Add resets property
From: Neil Armstrong The Amlogic ARM Mali Midgard requires reset controls to power on and software reset the GPU, adds these as optional in the bindings. Signed-off-by: Neil Armstrong Reviewed-by: Rob Herring Signed-off-by: Kevin Hilman --- .../devicetree/bindings/gpu/arm,mali-midgard.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 18a2cde2e5f3..1b1a74129141 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -37,6 +37,20 @@ Optional properties: - operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt for details. +- resets : Phandle of the GPU reset line. + +Vendor-specific bindings + + +The Mali GPU is integrated very differently from one SoC to +another. In order to accomodate those differences, you have the option +to specify one more vendor-specific compatible, among: + +- "amlogic,meson-gxm-mali" + Required properties: + - resets : Should contain phandles of : ++ GPU reset line ++ GPU APB glue reset line Example for a Mali-T760: -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
On (04/10/19 13:17), Alastair D'Silva wrote: > With the wider display format, it can become hard to identify how many > bytes into the line you are looking at. > > The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to > print vertical lines to separate every N groups of bytes. > > eg. > buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX. > buf:0010: 0002| | What if the output had |-s in it? | -ss ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/8] Add Allwinner H6 Mali Midgard gpu node
Hi, The Allwinner H6 has a Mali-T720 MP2. The drivers are out-of-tree so this serie only introduce the dt-bindings. The first patch is from Neil Amstrong and has been already merged in linux-amlogic. It is required for this serie. The second patch is from Icenowy Zheng where I changed the order has required by Rob Herring. See: https://patchwork.kernel.org/patch/10699829/ The GPU opp table is taken from Jernej Škrabec's patch on LibreELEC.tv. Thanks, Clement Clément Péron (7): dt-bindings: gpu: add bus clock for Mali Midgard GPUs dt-bindings: gpu: mali-midgard: Add h6 mali gpu compatible arm64: dts: allwinner: Add ARM Mali GPU node for H6 arm64: dts: allwinner: Add mali GPU supply for Pine H64 arm64: dts: allwinner: Add mali GPU supply for Beelink GS1 arm64: dts: allwinner: Add mali GPU supply for OrangePi Boards arm64: dts: allwinner: Add mali GPU supply for OrangePi 3 Neil Armstrong (1): dt-bindings: gpu: mali-midgard: Add resets property .../bindings/gpu/arm,mali-midgard.txt | 26 ++ .../dts/allwinner/sun50i-h6-beelink-gs1.dts | 5 ++ .../dts/allwinner/sun50i-h6-orangepi-3.dts| 5 ++ .../dts/allwinner/sun50i-h6-orangepi.dtsi | 5 ++ .../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 5 ++ arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80 +++ 6 files changed, 126 insertions(+) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build
From: Wei Liu
Empirically, on stretch armhf:
drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init':
drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc'
from incompatible pointer type [-Werror=incompatible-pointer-types]
pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
^
etc.
This is blocking the upgrade of the Xen Project CI to Debian stretch
so disable it for now.
Signed-off-by: Wei Liu
CC: Julien Grall
CC: Stefano Stabellini
CC: Thierry Reding
CC: dri-devel@lists.freedesktop.org
---
ts-kernel-build | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index 21b8f78a..0bc443de 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -594,6 +594,9 @@ case ${XEN_TARGET_ARCH} in
*) ;;
esac
+# Disable components that don't build
+setopt CONFIG_TEGRA_HOST1X n
+
exit 0
END
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/8] dt-bindings: gpu: add bus clock for Mali Midgard GPUs
Some SoCs adds a bus clock gate to the Mali Midgard GPU. Add the binding for the bus clock. Signed-off-by: Icenowy Zheng Signed-off-by: Clément Péron --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 1b1a74129141..2e8bbce35695 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -31,6 +31,12 @@ Optional properties: - clocks : Phandle to clock for the Mali Midgard device. +- clock-names : Specify the names of the clocks specified in clocks + when multiple clocks are present. +* core: clock driving the GPU itself (When only one clock is present, + assume it's this clock.) +* bus: bus clock for the GPU + - mali-supply : Phandle to regulator for the Mali device. Refer to Documentation/devicetree/bindings/regulator/regulator.txt for details. -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC patch 15/41] drm: Remove the ULONG_MAX stack trace hackery
No architecture terminates the stack trace with ULONG_MAX anymore. Remove the cruft. Signed-off-by: Thomas Gleixner Cc: intel-...@lists.freedesktop.org Cc: Joonas Lahtinen Cc: Maarten Lankhorst Cc: dri-devel@lists.freedesktop.org Cc: David Airlie Cc: Jani Nikula Cc: Daniel Vetter Cc: Rodrigo Vivi --- drivers/gpu/drm/drm_mm.c|3 --- drivers/gpu/drm/i915/intel_runtime_pm.c |4 2 files changed, 7 deletions(-) --- a/drivers/gpu/drm/drm_mm.c +++ b/drivers/gpu/drm/drm_mm.c @@ -113,9 +113,6 @@ static noinline void save_stack(struct d }; save_stack_trace(&trace); - if (trace.nr_entries != 0 && - trace.entries[trace.nr_entries-1] == ULONG_MAX) - trace.nr_entries--; /* May be called under spinlock, so avoid sleeping */ node->stack = depot_save_stack(&trace, GFP_NOWAIT); --- a/drivers/gpu/drm/i915/intel_runtime_pm.c +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c @@ -67,10 +67,6 @@ static noinline depot_stack_handle_t __s }; save_stack_trace(&trace); - if (trace.nr_entries && - trace.entries[trace.nr_entries - 1] == ULONG_MAX) - trace.nr_entries--; - return depot_save_stack(&trace, GFP_NOWAIT | __GFP_NOWARN); } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
From: Alastair D'Silva > Sent: 10 April 2019 04:17 > With the wider display format, it can become hard to identify how many > bytes into the line you are looking at. > > The patch adds new flags to hex_dump_to_buffer() and print_hex_dump() to > print vertical lines to separate every N groups of bytes. > > eg. > buf:: 454d414e 43415053|4e495f45 00584544 NAMESPAC|E_INDEX. > buf:0010: 0002| | Ugg, that is just horrid. It is enough to add an extra space if you really need the columns to be more easily counted. I'm not even sure that is needed if you are printing 32bit words. OTOH 32bit words makes 64bit values really stupid on LE systems. Bytes with extra spaces every 4 bytes is the format I prefer even for long lines. Oh, and if you are using hexdump() a lot you want a version that never uses snprintf(). David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/5] Add supply property for DSI controller
Hi Yannick On 4/3/19 10:16 AM, Yannick Fertré wrote: The DSI controller needs a new property that powers its physical layer. Binding has been updated to documented this property. Device tree of stm32mp157c soc. Move reg18 & reg11 to stm32mp157c device tree file. Remove property phy-dsi-supply property to stm32mp157c-dk2.dts file. Yannick Fertré (5): ... ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c ARM: dts: stm32: move fixe regulators reg11 & reg18 ARM: dts: stm32: remove phy-dsi-supply property on stm32mp157c-dk2 board For ARM part: Another series is currently under review: "Add support for STM32MP1 power regulators" (https://lkml.org/lkml/2019/4/8/614). As soon I'll merge it I'll take your patches without patch "ARM: dts: stm32: move fixe regulators reg11 & reg18" as it will be no longer relevant. regards Alexandre .../devicetree/bindings/display/st,stm32-ltdc.txt| 3 +++ arch/arm/boot/dts/stm32mp157c-dk2.dts| 9 - arch/arm/boot/dts/stm32mp157c-ed1.dts| 16 arch/arm/boot/dts/stm32mp157c.dtsi | 17 + drivers/gpu/drm/stm/dw_mipi_dsi-stm.c| 20 5 files changed, 40 insertions(+), 25 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build
Julien Grall writes ("Re: [OSSTEST PATCH 21/62] ts-kernel-build: disable
host1x, which doesn't build"):
> Ian are we using a different config between Jessie and Stretch?
Not very [1], but we *are* using a different compiler (since we just
use the one from the distro).
[1] There are some changes to add some ThunderX drivers, in a patch
that you suggested :-):
+setopt CONFIG_PCI_HOST_THUNDER_PEM=y
+setopt CONFIG_PCI_HOST_THUNDER_ECAM=y
+setopt CONFIG_THUNDER_NIC_PF=m
+setopt CONFIG_THUNDER_NIC_VF=m
+setopt CONFIG_THUNDER_NIC_BGX=m
+setopt CONFIG_THUNDER_NIC_RGX=m
+setopt CONFIG_MDIO_THUNDER=m
+setopt CONFIG_I2C_THUNDERX=m
+setopt CONFIG_SPI_THUNDERX=m
I doubt these are related.
It's nice to know that it's fixed in 4.18. I don't know how
disruptive it would be to backport it. I could perhaps make the
config option to disable host1x conditional on the Linux kernel
version but it seems easier to just leave things as they are and take
the workaround out at some point in the distant future when all
kernels we care about have the fix.
Thanks all,
Ian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
On Wednesday, 10 April 2019 at 11:08, Hans de Goede wrote: > On 10-04-19 11:00, Patrik Jakobsson wrote: > > On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede wrote: > > > On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote: > > > > On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote: > > > > > On 09-04-19 14:05, Patrik Jakobsson wrote: [...] > > > > > > I'm not totally against this but not sure about the consequences. Is > > > > > > there perhaps a better dmi string to match against? > > > > > > > > > > No there are no better DMI strings to match against I'm afraid. > > > > > > > > I did load default settings in BIOS setup and there's no change in > > > > behaviour. LVDS gets detected as connected: > > > > $ cat /sys/class/drm/card0-LVDS-1/status > > > > connected > > > > > > > > Only VGA output is physically connected at the moment. > > > > > > To be clear what Dominik means here is that he has a VGA monitor > > > connected. There is no LVDS panel in this device at all. > > > > Thanks for testing. I dusted off my DN2800MT and tried turning LVDS > > on/off in the BIOS. With LVDS disabled gma500 reports it as connected. > > When LVDS is enabled in bios I instead get a connected eDP connector. > > I'm starting to think that broken VBT parsing might be the actual > > problem. > > Maybe, but I assume there are CedarView based laptops with LVDS panels > which works, so I suspect this might be more of a bug in your BIOS. > > So what is the next step in debugging this? To add a small twist, I got an updated BIOS from the vendor to fix another issue (https://bugzilla.kernel.org/show_bug.cgi?id=199117) and the DMI string has changed to: "CDV W Series 05", so Hans' patch no longer matches my machine. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: panel-simple: Add simple-panel driver.
On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
monitor via DP cable. The actual monitor is therefore not known in advance.
This means, we don't have any panel information besides the EDID
data from the device itself.
The functionality for a 'simple-panel' has been remove a couple
of years ago with 81cf32b. This patch brings this feature back.
Signed-off-by: Christoph Muellner
---
drivers/gpu/drm/panel/panel-simple.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 9e8218f6a3f2..1f69283f3e4b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
backlight_update_status(p->backlight);
}
- if (p->desc->delay.disable)
+ if (p->desc && p->desc->delay.disable)
msleep(p->desc->delay.disable);
p->enabled = false;
@@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel *panel)
regulator_disable(p->supply);
- if (p->desc->delay.unprepare)
+ if (p->desc && p->desc->delay.unprepare)
msleep(p->desc->delay.unprepare);
p->prepared = false;
@@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel *panel)
gpiod_set_value_cansleep(p->enable_gpio, 1);
- delay = p->desc->delay.prepare;
- if (p->no_hpd)
- delay += p->desc->delay.hpd_absent_delay;
- if (delay)
- msleep(delay);
+ if (p->desc) {
+ delay = p->desc->delay.prepare;
+ if (p->no_hpd)
+ delay += p->desc->delay.hpd_absent_delay;
+ if (delay)
+ msleep(delay);
+ }
p->prepared = true;
@@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
if (p->enabled)
return 0;
- if (p->desc->delay.enable)
+ if (p->desc && p->desc->delay.enable)
msleep(p->desc->delay.enable);
if (p->backlight) {
@@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel *panel,
struct panel_simple *p = to_panel_simple(panel);
unsigned int i;
+ if (!p->desc)
+ return 0;
+
if (p->desc->num_timings < num_timings)
num_timings = p->desc->num_timings;
@@ -2536,6 +2541,9 @@ static const struct panel_desc arm_rtsm = {
static const struct of_device_id platform_of_match[] = {
{
+ .compatible = "simple-panel",
+ .data = NULL,
+ }, {
.compatible = "ampire,am-480272h3tmqw-t01h",
.data = &ire_am_480272h3tmqw_t01h,
}, {
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be separated by lines '|'
> -Original Message- > From: David Laight > Sent: Wednesday, 10 April 2019 6:45 PM > To: 'Alastair D'Silva' ; alast...@d-silva.org > Cc: Jani Nikula ; Joonas Lahtinen > ; Rodrigo Vivi ; > David Airlie ; Daniel Vetter ; Karsten Keil > ; Jassi Brar ; Tom Lendacky > ; David S. Miller ; > Jose Abreu ; Kalle Valo > ; Stanislaw Gruszka ; > Benson Leung ; Enric Balletbo i Serra > ; James E.J. Bottomley > ; Martin K. Petersen ; > Greg Kroah-Hartman ; Alexander Viro > ; Petr Mladek ; Sergey > Senozhatsky ; Steven Rostedt > ; Andrew Morton ; > intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux- > ker...@vger.kernel.org; net...@vger.kernel.org; > ath...@lists.infradead.org; linux-wirel...@vger.kernel.org; linux- > s...@vger.kernel.org; linux-fb...@vger.kernel.org; > de...@driverdev.osuosl.org; linux-fsde...@vger.kernel.org > Subject: RE: [PATCH 4/4] lib/hexdump.c: Allow multiple groups to be > separated by lines '|' > > From: Alastair D'Silva > > Sent: 10 April 2019 04:17 > > With the wider display format, it can become hard to identify how many > > bytes into the line you are looking at. > > > > The patch adds new flags to hex_dump_to_buffer() and > print_hex_dump() > > to print vertical lines to separate every N groups of bytes. > > > > eg. > > buf:: 454d414e 43415053|4e495f45 00584544 > NAMESPAC|E_INDEX. > > buf:0010: 0002| | > > Ugg, that is just horrid. > It is enough to add an extra space if you really need the columns to be more > easily counted. > I did consider that, but it would be a more invasive change, as the buffer length required would differ based on the flags. > I'm not even sure that is needed if you are printing 32bit words. > OTOH 32bit words makes 64bit values really stupid on LE systems. > Bytes with extra spaces every 4 bytes is the format I prefer even for long > lines. > > Oh, and if you are using hexdump() a lot you want a version that never uses > snprintf(). > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, > MK1 1PT, UK Registration No: 1397386 (Wales) > > > --- > This email has been checked for viruses by AVG. > https://www.avg.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver
On 09/04/2019 17:15, Rob Herring wrote:
> On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso
> wrote:
>>
>> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>>>
>>> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
On 01/04/2019 08:47, Rob Herring wrote:
> This adds the initial driver for panfrost which supports Arm Mali
> Midgard and Bifrost family of GPUs. Currently, only the T860 and
> T760 Midgard GPUs have been tested.
>>>
>>> [...]
> +
> + if (status & JOB_INT_MASK_ERR(j)) {
> + job_write(pfdev, JS_COMMAND_NEXT(j),
> JS_COMMAND_NOP);
> + job_write(pfdev, JS_COMMAND(j),
> JS_COMMAND_HARD_STOP_0);
Hard-stopping an already completed job isn't likely to do very much :)
Also you are using the "_0" version which is only valid when "job chain
disambiguation" is present.
>>
>> Yeah, guess that can be removed.
>
> Steven, TBC, are you suggesting removing both lines or leaving
> JS_COMMAND_NOP? I don't think we can ever have a pending job at this
> point as there's no queuing. So the NOP probably isn't needed, but
> doesn't hurt to have it either.
Both lines are redundant and can be removed. But equally neither will
cause any problems.
Writing NOP into the next register is basically only needed if you know
there's a job there which you no longer want to execute.
kbase does this in certain situations. The main one is on a GPU without
command chain disambiguation if you want to kill a particular job
there's a potential race. For example:
* Submit job A, followed by job B to slot 0. Job A is currently
executing, job B is waiting in the _NEXT registers.
* Kernel decides it wants to kill job A (it's taking too long, or the
application has quit).
* Simply executing a JS_COMMAND_HARD_STOP is racy. If job A finishes
just before doing the register write, then it's actually job B that gets
killed (and it's not always safe to just re-execute a killed job).
* Instead write NOP to JS_COMMAND_NEXT, then check (again) whether the
job currently running is the one you want. When you then HARD_STOP you
either hit the correct job, or 'miss' and do nothing.
Job chain disambiguation solves this problem by allowing the kernel to
tag each job with a flag, the hard-stop can then be targetted at the job
with the correct flag. Writing NOP into JS_COMMAND_NEXT is also useful
if in the above situation you want to kill job B. In that case you can't
hard-stop it (it hasn't start), so you simply want to remove it from the
_NEXT registers.
I suspect in this case you should also be signalling the fence? At the
moment you rely on the GPU timeout recovering from the fault.
>>>
>>> I'll defer to Tomeu who wrote this (IIRC).
>>
>> Yes, that would be an improvement.
>
> Actually, I think that would break recovery because the job timeout
> will bail out if the done fence is signaled already. Perhaps we want
> to timeout immediately if that is possible with the scheduler.
Ideally you would signal the fence with an error code (which is
presumably what recovery does). There's no actual need to trigger a
timeout. I'm not sure quite how the DRM infrastructure handles this though.
Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver
On 08/04/2019 22:04, Rob Herring wrote:
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
>>
>> On 01/04/2019 08:47, Rob Herring wrote:
>>> This adds the initial driver for panfrost which supports Arm Mali
>>> Midgard and Bifrost family of GPUs. Currently, only the T860 and
>>> T760 Midgard GPUs have been tested.
>
> [...]
>
>>> + case 0xD3: return "TRANSTAB_BUS_FAULT_LEVEL3";
>>> + case 0xD4: return "TRANSTAB_BUS_FAULT_LEVEL4";
>>> + case 0xD8: return "ACCESS_FLAG";
>>> + }
>>> +
>>> + if (panfrost_has_hw_feature(pfdev, HW_FEATURE_AARCH64_MMU)) {
>>
>> There's not a great deal of point in this conditional - you won't get
>> the below exception codes from hardware which doesn't support it AARCH64
>> page tables.
>
> I wasn't sure if "UNKNOWN" types could happen or not.
>
>>
>>> + switch (exception_code) {
>>> + case 0xC9 ... 0xCF: return "PERMISSION_FAULT";
>>> + case 0xD9 ... 0xDF: return "ACCESS_FLAG";
>>> + case 0xE0 ... 0xE7: return "ADDRESS_SIZE_FAULT";
>>> + case 0xE8 ... 0xEF: return "MEMORY_ATTRIBUTES_FAULT";
>>> + }
>>> + }
>>> +
>>> + return "UNKNOWN";
>>> +}
>
>>> +static inline int panfrost_model_cmp(struct panfrost_device *pfdev, s32 id)
>>> +{
>>> + s32 match_id = pfdev->features.id;
>>> +
>>> + if (match_id & 0xf000)
>>> + match_id &= 0xf00f;
>>
>> I'm puzzled by this, and really not sure if it's going to work out
>> ignoring the ARCH_MINOR/ARCH_REV fields. But for now there's no real
>> Bifrost support.
>
> That seemed to be enough for kbase to select features/issues.
I can't deny that it seems to work for now, and indeed looking more
closely at kbase that does seem to be the effect of the current code.
>>> + switch (param->param) {
>>> + case DRM_PANFROST_PARAM_GPU_ID:
>>> + param->value = pfdev->features.id;
>>
>> This is unfortunate naming - this parameter is *not* the GPU_ID. It is
>> the top half of the GPU_ID which kbase calls the PRODUCT_ID.
>
> I can rename it.
It would help prevent confusion, thanks!
>> I'm also somewhat surprised that you don't need loads of other
>> properties from the GPU - in particular knowing the number of shader
>> cores is useful for allocating the right amount of memory for TLS (and
>> can't be obtained purely from the GPU_ID).
>
> We'll add them as userspace needs them.
Fair enough. I'm not sure how much you want to provide "forward
compatibility" by providing them early - the basic definitions are
already in kbase. I found it a bit surprising that some feature
registers are printed on probe, but not available to be queried.
>>> +static int
>>> +panfrost_lookup_bos(struct drm_device *dev,
>>> + struct drm_file *file_priv,
>>> + struct drm_panfrost_submit *args,
>>> + struct panfrost_job *job)
>>> +{
>>> + u32 *handles;
>>> + int ret = 0;
>>> +
>>> + job->bo_count = args->bo_handle_count;
>>> +
>>> + if (!job->bo_count)
>>> + return 0;
>>> +
>>> + job->bos = kvmalloc_array(job->bo_count,
>>> + sizeof(struct drm_gem_object *),
>>> + GFP_KERNEL | __GFP_ZERO);
>>> + if (!job->bos)
>>
>> If we return here then job->bo_count has been set, but job->bos is
>> invalid - this means that panfrost_job_cleanup() will then dereference
>> NULL. Although maybe this is better fixed in panfrost_job_cleanup().
>
> Good catch. The fence arrays have the same problem. As does V3D which we
> copied.
>
>>> + return -ENOMEM;
>>> +
>>> + job->implicit_fences = kvmalloc_array(job->bo_count,
>>> + sizeof(struct dma_fence *),
>>> + GFP_KERNEL | __GFP_ZERO);
>>> + if (!job->implicit_fences)
>>> + return -ENOMEM;
>
>>> +static irqreturn_t panfrost_gpu_irq_handler(int irq, void *data)
>>> +{
>>> + struct panfrost_device *pfdev = data;
>>> + u32 state = gpu_read(pfdev, GPU_INT_STAT);
>>> + u32 fault_status = gpu_read(pfdev, GPU_FAULT_STATUS);
>>> + u64 address;
>>> + bool done = false;
>>> +
>>> + if (!state)
>>> + return IRQ_NONE;
>>> +
>>> + if (state & GPU_IRQ_MASK_ERROR) {
>>> + address = (u64) gpu_read(pfdev, GPU_FAULT_ADDRESS_HI) << 32;
>>> + address |= gpu_read(pfdev, GPU_FAULT_ADDRESS_LO);
>>> +
>>> + dev_warn(pfdev->dev, "GPU Fault 0x%08x (%s) at 0x%016llx\n",
>>> + fault_status & 0xFF, panfrost_exception_name(pfdev,
>>> fault_status),
>>> + address);
>>> +
>>> + if (state & GPU_IRQ_MULTIPLE_FAULT)
>>> + dev_warn(pfdev->dev, "There were multiple GPU faults
>>> - some have not been reported\n");
>>> +
>>> + gpu_write(pfdev, GPU_INT_MASK, 0);
>>
>> Do you intend to mask off future GPU interrupts?
>
> Yes, maybe?
>
> If we fault here,
Re: [PATCH] drm/gma500: Add CedarView LVDS blacklist
On Wednesday, 10 April 2019 at 13:33, Patrik Jakobsson wrote: > On Wed, Apr 10, 2019 at 1:18 PM Dominik 'Rathann' Mierzejewski > wrote: > > > > On Wednesday, 10 April 2019 at 11:08, Hans de Goede wrote: > > > On 10-04-19 11:00, Patrik Jakobsson wrote: > > > > On Wed, Apr 10, 2019 at 9:27 AM Hans de Goede > > > > wrote: > > > > > On 09-04-19 21:31, Dominik 'Rathann' Mierzejewski wrote: > > > > > > On Tuesday, 09 April 2019 at 16:44, Hans de Goede wrote: > > > > > > > On 09-04-19 14:05, Patrik Jakobsson wrote: > > [...] > > > > > > > > I'm not totally against this but not sure about the > > > > > > > > consequences. Is > > > > > > > > there perhaps a better dmi string to match against? > > > > > > > > > > > > > > No there are no better DMI strings to match against I'm afraid. > > > > > > > > > > > > I did load default settings in BIOS setup and there's no change in > > > > > > behaviour. LVDS gets detected as connected: > > > > > > $ cat /sys/class/drm/card0-LVDS-1/status > > > > > > connected > > > > > > > > > > > > Only VGA output is physically connected at the moment. > > > > > > > > > > To be clear what Dominik means here is that he has a VGA monitor > > > > > connected. There is no LVDS panel in this device at all. > > > > > > > > Thanks for testing. I dusted off my DN2800MT and tried turning LVDS > > > > on/off in the BIOS. With LVDS disabled gma500 reports it as connected. > > > > When LVDS is enabled in bios I instead get a connected eDP connector. > > > > I'm starting to think that broken VBT parsing might be the actual > > > > problem. > > > > > > Maybe, but I assume there are CedarView based laptops with LVDS panels > > > which works, so I suspect this might be more of a bug in your BIOS. > > > > > > So what is the next step in debugging this? > > > > To add a small twist, I got an updated BIOS from the vendor to fix > > another issue (https://bugzilla.kernel.org/show_bug.cgi?id=199117) > > and the DMI string has changed to: "CDV W Series 05", so Hans' patch > > no longer matches my machine. > > Hi Dominik, > > Do you have any option to enable/disable LVDS in your BIOS. The BIOS > default might not be to disable LVDS since they apparently solved the > issue on the command line anyway. If there is an option to turn it off > but you still get the same problem, then it is possible that detection > of "LVDS disabled" in the driver might be bad. No, there's no option to enable/disable LVDS. The machine is a NAS box and doesn't have an LVDS physically. You can see the motherboard e.g. here: https://youtu.be/ZYNQvZNGLsE?t=855 . Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] dt-bindings: simple-panel: Set compatible string to "simple-panel".
The documentation for simple-panel lists "cptt,claa101wb01" as
compatible string. However, the kernel contains no driver, which
recognizes this string. Therefore this patch replaces the compatible
string with "simple-panel".
Signed-off-by: Christoph Muellner
---
Documentation/devicetree/bindings/display/panel/simple-panel.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
index b2b872c710f2..2000692ba44f 100644
--- a/Documentation/devicetree/bindings/display/panel/simple-panel.txt
+++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt
@@ -18,7 +18,7 @@ Optional properties:
Example:
panel: panel {
- compatible = "cptt,claa101wb01";
+ compatible = "simple-panel";
ddc-i2c-bus = <&panelddc>;
power-supply = <&vdd_pnl_reg>;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: panel-simple: Add simple-panel driver.
Hi Heiko,
> On 10.04.2019, at 16:50, Heiko Stübner wrote:
>
> Hi Christoph,
>
> Am Mittwoch, 10. April 2019, 16:10:44 CEST schrieb Christoph Muellner:
>> On our RK3399-Q7 EVK base board we have the option to connect an arbitrary
>> monitor via DP cable. The actual monitor is therefore not known in advance.
>> This means, we don't have any panel information besides the EDID
>> data from the device itself.
>
> Just so I understand correctly, you have a real dp-connector wired to
> the Analogix dp-controller, and therefore want to connect actual
> monitors to it.
>
> So the problem you're trying to work around is probably that the
> rockchip-driver of the analogix controller explictly expects a bridge
> to be present during probe, right?
>
> I think hacking up the panel-driver is not an ideal approach:
> (1) bridges/panels do expect to stay connected all the time
>and are meant for devices with actual hard-wired displays with specific
>power-sequence requirements
> (2) devicetree is expected to describe the real hardware, therefore the
>dt should not describe one thing while the actual hardware is really
>different
>
> So, I guess a more ideal approach could perhaps be to:
> (1) define a "dp-connector" devicetree binding, see
>Documentation/devicetree/bindings/display/connector/hdmi-connector.txt
>for a similar one
> (2) steal an idea from drivers/gpu/drm/mediatek/mtk_hdmi.c and check
>for that new compatible:
> if (!of_device_is_compatible(remote, "hdmi-connector")) {
> //move bridge handling here
> }
>
>and modify both the rockchip-part and the generic analogix bridge code
>to work with the connector declared instead of a panel?
Thank's for you input on this.
Modelling the connector instead of the panel is indeed a better approach,
since we can then also react to connect/disconnect events (after probe).
Thanks,
Christoph
>
>> The functionality for a 'simple-panel' has been remove a couple
>> of years ago with 81cf32b. This patch brings this feature back.
>>
>> Signed-off-by: Christoph Muellner
>> ---
>> drivers/gpu/drm/panel/panel-simple.c | 24
>> 1 file changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/panel/panel-simple.c
>> b/drivers/gpu/drm/panel/panel-simple.c
>> index 9e8218f6a3f2..1f69283f3e4b 100644
>> --- a/drivers/gpu/drm/panel/panel-simple.c
>> +++ b/drivers/gpu/drm/panel/panel-simple.c
>> @@ -176,7 +176,7 @@ static int panel_simple_disable(struct drm_panel *panel)
>> backlight_update_status(p->backlight);
>> }
>>
>> -if (p->desc->delay.disable)
>> +if (p->desc && p->desc->delay.disable)
>> msleep(p->desc->delay.disable);
>>
>> p->enabled = false;
>> @@ -195,7 +195,7 @@ static int panel_simple_unprepare(struct drm_panel
>> *panel)
>>
>> regulator_disable(p->supply);
>>
>> -if (p->desc->delay.unprepare)
>> +if (p->desc && p->desc->delay.unprepare)
>> msleep(p->desc->delay.unprepare);
>>
>> p->prepared = false;
>> @@ -220,11 +220,13 @@ static int panel_simple_prepare(struct drm_panel
>> *panel)
>>
>> gpiod_set_value_cansleep(p->enable_gpio, 1);
>>
>> -delay = p->desc->delay.prepare;
>> -if (p->no_hpd)
>> -delay += p->desc->delay.hpd_absent_delay;
>> -if (delay)
>> -msleep(delay);
>> +if (p->desc) {
>> +delay = p->desc->delay.prepare;
>> +if (p->no_hpd)
>> +delay += p->desc->delay.hpd_absent_delay;
>> +if (delay)
>> +msleep(delay);
>> +}
>>
>> p->prepared = true;
>>
>> @@ -238,7 +240,7 @@ static int panel_simple_enable(struct drm_panel *panel)
>> if (p->enabled)
>> return 0;
>>
>> -if (p->desc->delay.enable)
>> +if (p->desc && p->desc->delay.enable)
>> msleep(p->desc->delay.enable);
>>
>> if (p->backlight) {
>> @@ -280,6 +282,9 @@ static int panel_simple_get_timings(struct drm_panel
>> *panel,
>> struct panel_simple *p = to_panel_simple(panel);
>> unsigned int i;
>>
>> +if (!p->desc)
>> +return 0;
>> +
>> if (p->desc->num_timings < num_timings)
>> num_timings = p->desc->num_timings;
>>
>> @@ -2536,6 +2541,9 @@ static const struct panel_desc arm_rtsm = {
>>
>> static const struct of_device_id platform_of_match[] = {
>> {
>> +.compatible = "simple-panel",
>> +.data = NULL,
>> +}, {
>> .compatible = "ampire,am-480272h3tmqw-t01h",
>> .data = &ire_am_480272h3tmqw_t01h,
>> }, {
>>
>
>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/8] arm64: dts: allwinner: Add mali GPU supply for OrangePi Boards
Enable and add supply to the Mali GPU node on the
Orange Pi One Plus and Lite2 boards.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
index 62e27948a3fa..bd13297555ab 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
@@ -55,6 +55,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <®_dcdcc>;
+ status = "okay";
+};
+
&mmc0 {
vmmc-supply = <®_cldo1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/8] arm64: dts: allwinner: Add mali GPU supply for Beelink GS1
Enable and add supply to the Mali GPU node on the
Beelink GS1 board.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
index 0dc33c90dd60..21440d572f0a 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
@@ -70,6 +70,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <®_dcdcc>;
+ status = "okay";
+};
+
&hdmi {
status = "okay";
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/8] dt-bindings: gpu: mali-midgard: Add h6 mali gpu compatible
This add the H6 mali compatible in the dt-bindings to later support specific implementation. Signed-off-by: Clément Péron --- .../devicetree/bindings/gpu/arm,mali-midgard.txt | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 2e8bbce35695..9e71146b5c8a 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -15,6 +15,7 @@ Required properties: + "arm,mali-t860" + "arm,mali-t880" * which must be preceded by one of the following vendor specifics: ++ "allwinner,sun50i-h6-mali" + "amlogic,meson-gxm-mali" + "rockchip,rk3288-mali" + "rockchip,rk3399-mali" @@ -49,9 +50,14 @@ Vendor-specific bindings The Mali GPU is integrated very differently from one SoC to -another. In order to accomodate those differences, you have the option +another. In order to accommodate those differences, you have the option to specify one more vendor-specific compatible, among: +- "allwinner,sun50i-h6-mali" + Required properties: + - resets: Should contain phandle of : ++ GPU reset line + - "amlogic,meson-gxm-mali" Required properties: - resets : Should contain phandles of : -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
Add the mali gpu node to the H6 device-tree.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
1 file changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index e0dc4a05c1ba..152b2128aadf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -17,6 +17,71 @@
#address-cells = <1>;
#size-cells = <1>;
+ gpu_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+
+ opp@75600 {
+ opp-hz = /bits/ 64 <75600>;
+ opp-microvolt = <104>;
+ };
+ opp@62400 {
+ opp-hz = /bits/ 64 <62400>;
+ opp-microvolt = <95>;
+ };
+ opp@57600 {
+ opp-hz = /bits/ 64 <57600>;
+ opp-microvolt = <93>;
+ };
+ opp@54000 {
+ opp-hz = /bits/ 64 <54000>;
+ opp-microvolt = <91>;
+ };
+ opp@50400 {
+ opp-hz = /bits/ 64 <50400>;
+ opp-microvolt = <89>;
+ };
+ opp@45600 {
+ opp-hz = /bits/ 64 <45600>;
+ opp-microvolt = <87>;
+ };
+ opp@43200 {
+ opp-hz = /bits/ 64 <43200>;
+ opp-microvolt = <86>;
+ };
+ opp@42000 {
+ opp-hz = /bits/ 64 <42000>;
+ opp-microvolt = <85>;
+ };
+ opp@40800 {
+ opp-hz = /bits/ 64 <40800>;
+ opp-microvolt = <84>;
+ };
+ opp@38400 {
+ opp-hz = /bits/ 64 <38400>;
+ opp-microvolt = <83>;
+ };
+ opp@36000 {
+ opp-hz = /bits/ 64 <36000>;
+ opp-microvolt = <82>;
+ };
+ opp@33600 {
+ opp-hz = /bits/ 64 <33600>;
+ opp-microvolt = <81>;
+ };
+ opp@31200 {
+ opp-hz = /bits/ 64 <31200>;
+ opp-microvolt = <81>;
+ };
+ opp@26400 {
+ opp-hz = /bits/ 64 <26400>;
+ opp-microvolt = <81>;
+ };
+ opp@21600 {
+ opp-hz = /bits/ 64 <21600>;
+ opp-microvolt = <81>;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -157,6 +222,21 @@
allwinner,sram = <&ve_sram 1>;
};
+ gpu: gpu@180 {
+ compatible = "allwinner,sun50i-h6-mali",
+"arm,mali-t720";
+ reg = <0x0180 0x4000>;
+ interrupts = ,
+,
+;
+ interrupt-names = "job", "mmu", "gpu";
+ clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
+ clock-names = "core", "bus";
+ resets = <&ccu RST_BUS_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ status = "disabled";
+ };
+
syscon: syscon@300 {
compatible = "allwinner,sun50i-h6-system-control",
"allwinner,sun50i-a64-system-control";
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/8] arm64: dts: allwinner: Add mali GPU supply for Pine H64
Enable and add supply to the Mali GPU node on the
Pine H64 board.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index 4802902e128f..e16a8c6738f9 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -85,6 +85,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <®_dcdcc>;
+ status = "okay";
+};
+
&hdmi {
status = "okay";
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Don't disable interrupts independently of the lock
The locks (timeline->lock and rq->lock) need to be taken with disabled interrupts. This is done in __retire_engine_request() by disabling the interrupts independently of the locks itself. While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla it does not on RT. Also, it is not obvious if there is a special reason to why the interrupts are disabled independently of the lock. Enable/disable interrupts as part of the locking instruction. Signed-off-by: Sebastian Andrzej Siewior --- drivers/gpu/drm/i915/i915_request.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c index ca95ab2f4cfa3..8744d20ac1681 100644 --- a/drivers/gpu/drm/i915/i915_request.c +++ b/drivers/gpu/drm/i915/i915_request.c @@ -278,9 +278,7 @@ static void __retire_engine_request(struct intel_engine_cs *engine, GEM_BUG_ON(!i915_request_completed(rq)); - local_irq_disable(); - - spin_lock(&engine->timeline.lock); + spin_lock_irq(&engine->timeline.lock); GEM_BUG_ON(!list_is_first(&rq->link, &engine->timeline.requests)); list_del_init(&rq->link); spin_unlock(&engine->timeline.lock); @@ -294,9 +292,7 @@ static void __retire_engine_request(struct intel_engine_cs *engine, GEM_BUG_ON(!atomic_read(&rq->i915->gt_pm.rps.num_waiters)); atomic_dec(&rq->i915->gt_pm.rps.num_waiters); } - spin_unlock(&rq->lock); - - local_irq_enable(); + spin_unlock_irq(&rq->lock); /* * The backing object for the context is done after switching to the -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 8/8] arm64: dts: allwinner: Add mali GPU supply for OrangePi 3
Enable and add supply to the Mali GPU node on the
Orange Pi 3 board.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
index 17d496990108..d4c989cc92a7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts
@@ -58,6 +58,11 @@
status = "okay";
};
+&gpu {
+ mali-supply = <®_dcdcc>;
+ status = "okay";
+};
+
&mmc0 {
vmmc-supply = <®_cldo1>;
cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC patch 32/41] drm: Simplify stacktrace handling
Replace the indirection through struct stack_trace by using the storage
array based interfaces.
The original code in all printing functions is really wrong. It allocates a
storage array on stack which is unused because depot_fetch_stack() does not
store anything in it. It overwrites the entries pointer in the stack_trace
struct so it points to the depot storage.
Signed-off-by: Thomas Gleixner
Cc: intel-...@lists.freedesktop.org
Cc: Joonas Lahtinen
Cc: Maarten Lankhorst
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Rodrigo Vivi
---
drivers/gpu/drm/drm_mm.c| 22 +++---
drivers/gpu/drm/i915/i915_vma.c | 11 ---
drivers/gpu/drm/i915/intel_runtime_pm.c | 21 +++--
3 files changed, 18 insertions(+), 36 deletions(-)
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -106,22 +106,19 @@
static noinline void save_stack(struct drm_mm_node *node)
{
unsigned long entries[STACKDEPTH];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = STACKDEPTH,
- .skip = 1
- };
+ unsigned int n;
- save_stack_trace(&trace);
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
/* May be called under spinlock, so avoid sleeping */
- node->stack = depot_save_stack(&trace, GFP_NOWAIT);
+ node->stack = stack_depot_save(entries, n, GFP_NOWAIT);
}
static void show_leaks(struct drm_mm *mm)
{
struct drm_mm_node *node;
- unsigned long entries[STACKDEPTH];
+ unsigned long *entries;
+ unsigned int nent;
char *buf;
buf = kmalloc(BUFSZ, GFP_KERNEL);
@@ -129,19 +126,14 @@ static void show_leaks(struct drm_mm *mm
return;
list_for_each_entry(node, drm_mm_nodes(mm), node_list) {
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = STACKDEPTH
- };
-
if (!node->stack) {
DRM_ERROR("node [%08llx + %08llx]: unknown owner\n",
node->start, node->size);
continue;
}
- depot_fetch_stack(node->stack, &trace);
- snprint_stack_trace(buf, BUFSZ, &trace, 0);
+ nent = stack_depot_fetch(node->stack, &entries);
+ stack_trace_snprintf(buf, BUFSZ, entries, nent, 0);
DRM_ERROR("node [%08llx + %08llx]: inserted at\n%s",
node->start, node->size, buf);
}
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -36,11 +36,8 @@
static void vma_print_allocator(struct i915_vma *vma, const char *reason)
{
- unsigned long entries[12];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = ARRAY_SIZE(entries),
- };
+ unsigned long *entries;
+ unsigned int nent;
char buf[512];
if (!vma->node.stack) {
@@ -49,8 +46,8 @@ static void vma_print_allocator(struct i
return;
}
- depot_fetch_stack(vma->node.stack, &trace);
- snprint_stack_trace(buf, sizeof(buf), &trace, 0);
+ nent = stack_depot_fetch(vma->node.stack, &entries);
+ stack_trace_snprint(buf, sizeof(buf), entries, nent, 0);
DRM_DEBUG_DRIVER("vma.node [%08llx + %08llx] %s: inserted at %s\n",
vma->node.start, vma->node.size, reason, buf);
}
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -60,27 +60,20 @@
static noinline depot_stack_handle_t __save_depot_stack(void)
{
unsigned long entries[STACKDEPTH];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = ARRAY_SIZE(entries),
- .skip = 1,
- };
+ unsigned int n;
- save_stack_trace(&trace);
- return depot_save_stack(&trace, GFP_NOWAIT | __GFP_NOWARN);
+ n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
+ return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
}
static void __print_depot_stack(depot_stack_handle_t stack,
char *buf, int sz, int indent)
{
- unsigned long entries[STACKDEPTH];
- struct stack_trace trace = {
- .entries = entries,
- .max_entries = ARRAY_SIZE(entries),
- };
+ unsigned long *entries;
+ unsigned int nent;
- depot_fetch_stack(stack, &trace);
- snprint_stack_trace(buf, sz, &trace, indent);
+ nent = stack_depot_fetch(stack, &entries);
+ stack_trace_snprint(buf, sz, entries, nent, indent);
}
static void init_intel_runtime_pm_wakeref(struct drm_i915_private *i915)
___
dri-devel mailing list
dr
Re: [OSSTEST PATCH 21/62] ts-kernel-build: disable host1x, which doesn't build
Hi, On 10/04/2019 16:27, Thierry Reding wrote: On Wed, Apr 10, 2019 at 03:23:27PM +0100, Ian Jackson wrote: From: Wei Liu Empirically, on stretch armhf: drivers/gpu/host1x/cdma.c: In function `host1x_pushbuffer_init': drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of `dma_alloc_wc' from incompatible pointer type [-Werror=incompatible-pointer-types] pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys, ^ etc. This was fixed in v4.18 by this commit: commit 2f8a6da866eff746a9f8c7745790f3765baeb589 Author: Emil Goode Date: Wed May 16 12:22:04 2018 +0200 gpu: host1x: Fix compiler errors by converting to dma_addr_t The compiler is complaining with the following errors: drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type [-Werror=incompatible-pointer-types] drivers/gpu/host1x/cdma.c:113:48: error: passing argument 3 of ‘dma_alloc_wc’ from incompatible pointer type [-Werror=incompatible-pointer-types] The expected pointer type of the third argument to dma_alloc_wc() is dma_addr_t but phys_addr_t is passed. Change the phys member of struct push_buffer to be dma_addr_t so that we pass the correct type to dma_alloc_wc(). Also check pb->mapped for non-NULL in the destroy function as that is the right way of checking if dma_alloc_wc() was successful. Signed-off-by: Emil Goode Signed-off-by: Thierry Reding It should be fairly easy to backport this to older releases, though I'm not sure exactly what made this trigger. This wasn't causing any build errors for a very long time, since this type mismatch has existed ever since the driver was merged all the way back in v3.10. Likely no-one ever tried to build this module with CONFIG_XEN=y. Xen requires dma_addr_t to be 64-bit regardless the page-tables format selected (e.g short vs LPAE). AFAIK, this is the only case on Arm32 where phys_addr_t and dma_addr_t would mismatched. Ian are we using a different config between Jessie and Stretch? Cheers, -- Julien Grall ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
Hi,
On Thu, 11 Apr 2019 at 09:28, Maxime Ripard wrote:
>
> On Thu, Apr 11, 2019 at 01:25:39AM +0200, Clément Péron wrote:
> > Add the mali gpu node to the H6 device-tree.
> >
> > Signed-off-by: Clément Péron
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
> > 1 file changed, 80 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > index e0dc4a05c1ba..152b2128aadf 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > @@ -17,6 +17,71 @@
> > #address-cells = <1>;
> > #size-cells = <1>;
> >
> > + gpu_opp_table: opp_table1 {
> > + compatible = "operating-points-v2";
> > +
> > + opp@75600 {
> > + opp-hz = /bits/ 64 <75600>;
> > + opp-microvolt = <104>;
> > + };
> > + opp@62400 {
> > + opp-hz = /bits/ 64 <62400>;
> > + opp-microvolt = <95>;
> > + };
> > + opp@57600 {
> > + opp-hz = /bits/ 64 <57600>;
> > + opp-microvolt = <93>;
> > + };
> > + opp@54000 {
> > + opp-hz = /bits/ 64 <54000>;
> > + opp-microvolt = <91>;
> > + };
> > + opp@50400 {
> > + opp-hz = /bits/ 64 <50400>;
> > + opp-microvolt = <89>;
> > + };
> > + opp@45600 {
> > + opp-hz = /bits/ 64 <45600>;
> > + opp-microvolt = <87>;
> > + };
> > + opp@43200 {
> > + opp-hz = /bits/ 64 <43200>;
> > + opp-microvolt = <86>;
> > + };
> > + opp@42000 {
> > + opp-hz = /bits/ 64 <42000>;
> > + opp-microvolt = <85>;
> > + };
> > + opp@40800 {
> > + opp-hz = /bits/ 64 <40800>;
> > + opp-microvolt = <84>;
> > + };
> > + opp@38400 {
> > + opp-hz = /bits/ 64 <38400>;
> > + opp-microvolt = <83>;
> > + };
> > + opp@36000 {
> > + opp-hz = /bits/ 64 <36000>;
> > + opp-microvolt = <82>;
> > + };
> > + opp@33600 {
> > + opp-hz = /bits/ 64 <33600>;
> > + opp-microvolt = <81>;
> > + };
> > + opp@31200 {
> > + opp-hz = /bits/ 64 <31200>;
> > + opp-microvolt = <81>;
> > + };
> > + opp@26400 {
> > + opp-hz = /bits/ 64 <26400>;
> > + opp-microvolt = <81>;
> > + };
> > + opp@21600 {
> > + opp-hz = /bits/ 64 <21600>;
> > + opp-microvolt = <81>;
> > + };
> > + };
> > +
>
> How were those OPPs tested?
They are taken from the vendor device tree.
https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi#L2121
Clement
>
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: host1x: fix compile error when IOMMU API is not available
On Thu, Apr 11, 2019 at 09:23:13AM +0100, Ben Dooks wrote:
>
>
> On 2019-04-10 23:47, Stefan Agner wrote:
> > In case the IOMMU API is not available compiling host1x fails with
> > the following error:
> > In file included from drivers/gpu/host1x/hw/host1x06.c:27:
> > drivers/gpu/host1x/hw/channel_hw.c: In function
> > ‘host1x_channel_set_streamid’:
> > drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit
> > declaration of function
> > ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’?
> > [-Werror=implicit-function-declaration]
> > struct iommu_fwspec *spec =
> > dev_iommu_fwspec_get(channel->dev->parent);
> > ^~~~
> > iommu_fwspec_free
> >
> > Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
> > Signed-off-by: Stefan Agner
>
> would it be better to provide something like this i nthe header that
> defines dev_iommu_fwspec_get() to be:
>
> static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device *dev)
> { return NULL; }
>
> although returning an PTR_ERR would have been better.
I don't think there's really a large number of failures here. Either
your device has an IOMMU fwspec or it doesn't.
But yes, I think it'd be better to have the above static inline dummy in
iommu.h, but I'll apply this for now in the hopes of getting it in
before v5.1 final.
Thierry
>
> > ---
> > drivers/gpu/host1x/hw/channel_hw.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/host1x/hw/channel_hw.c
> > b/drivers/gpu/host1x/hw/channel_hw.c
> > index 27101c04a827..4030d64916f0 100644
> > --- a/drivers/gpu/host1x/hw/channel_hw.c
> > +++ b/drivers/gpu/host1x/hw/channel_hw.c
> > @@ -114,7 +114,7 @@ static inline void synchronize_syncpt_base(struct
> > host1x_job *job)
> >
> > static void host1x_channel_set_streamid(struct host1x_channel *channel)
> > {
> > -#if HOST1X_HW >= 6
> > +#if IS_ENABLED(CONFIG_IOMMU_API) && HOST1X_HW >= 6
> > struct iommu_fwspec *spec =
> > dev_iommu_fwspec_get(channel->dev->parent);
> > u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: fixing of DMA mapping sg segment warning
Fixing the DMA mapping sg segment warning, which shows "DMA-API: mapping
sg segment longer than device claims to support [len=921600] [max=65536]".
Fixed by setting the max segment size at Komeda driver.
This patch depends on:
- https://patchwork.freedesktop.org/series/54448/
- https://patchwork.freedesktop.org/series/54449/
- https://patchwork.freedesktop.org/series/54450/
- https://patchwork.freedesktop.org/series/58976/
Changes since v1:
- Adds member description
- Adds patch denpendency in the comment
Signed-off-by: Lowry Li (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 4
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 7f25e6a..b4902ae 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_DEBUG_FS
#include
#include
@@ -245,6 +246,9 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto err_cleanup;
}
+ dev->dma_parms = &mdev->dma_parms;
+ dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+
err = sysfs_create_group(&dev->kobj, &komeda_sysfs_attr_group);
if (err) {
DRM_ERROR("create sysfs group failed.\n");
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index 29e03c4..83ace71 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -149,6 +149,8 @@ struct komeda_dev {
struct device *dev;
/** @reg_base: the base address of komeda io space */
u32 __iomem *reg_base;
+ /** @dma_parms: the dma parameters of komeda */
+ struct device_dma_parameters dma_parms;
/** @chip: the basic chip information */
struct komeda_chip_info chip;
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/komeda: Creates plane alpha and blend mode properties
Creates plane alpha and blend mode properties attached to plane. This patch depends on: - https://patchwork.freedesktop.org/series/54448/ - https://patchwork.freedesktop.org/series/54449/ - https://patchwork.freedesktop.org/series/54450/ Changes since v1: - Adds patch denpendency in the comment Signed-off-by: Lowry Li (Arm Technology China) --- drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c index 68cd2c9e..aae5e80 100644 --- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c +++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c @@ -220,6 +220,17 @@ static int komeda_plane_add(struct komeda_kms_dev *kms, drm_plane_helper_add(plane, &komeda_plane_helper_funcs); + err = drm_plane_create_alpha_property(plane); + if (err) + goto cleanup; + + err = drm_plane_create_blend_mode_property(plane, + BIT(DRM_MODE_BLEND_PIXEL_NONE) | + BIT(DRM_MODE_BLEND_PREMULTI) | + BIT(DRM_MODE_BLEND_COVERAGE)); + if (err) + goto cleanup; + return 0; cleanup: komeda_plane_destroy(plane); -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] drm/tegra: Fixes for v5.1-rc5
Hi Dave, The following changes since commit 509869a2fec36ecb2b841180915995f41d5a0219: drm/tegra: vic: Fix implicit function declaration warning (2019-03-22 14:08:55 +0100) are available in the Git repository at: git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.1-rc5 for you to fetch changes up to e154592a1d25fa1f50ac1bd8d132d0e1103442ba: gpu: host1x: Fix compile error when IOMMU API is not available (2019-04-11 10:35:39 +0200) Thanks, Thierry drm/tegra: Fixes for v5.1-rc5 A single, one-line fix for a build error introduced in v5.1-rc1. Stefan Agner (1): gpu: host1x: Fix compile error when IOMMU API is not available drivers/gpu/host1x/hw/channel_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
On Thu, Apr 11, 2019 at 09:56:15AM +0200, Clément Péron wrote:
> Hi,
>
> On Thu, 11 Apr 2019 at 09:28, Maxime Ripard wrote:
> >
> > On Thu, Apr 11, 2019 at 01:25:39AM +0200, Clément Péron wrote:
> > > Add the mali gpu node to the H6 device-tree.
> > >
> > > Signed-off-by: Clément Péron
> > > ---
> > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 80
> > > 1 file changed, 80 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > index e0dc4a05c1ba..152b2128aadf 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > @@ -17,6 +17,71 @@
> > > #address-cells = <1>;
> > > #size-cells = <1>;
> > >
> > > + gpu_opp_table: opp_table1 {
> > > + compatible = "operating-points-v2";
> > > +
> > > + opp@75600 {
> > > + opp-hz = /bits/ 64 <75600>;
> > > + opp-microvolt = <104>;
> > > + };
> > > + opp@62400 {
> > > + opp-hz = /bits/ 64 <62400>;
> > > + opp-microvolt = <95>;
> > > + };
> > > + opp@57600 {
> > > + opp-hz = /bits/ 64 <57600>;
> > > + opp-microvolt = <93>;
> > > + };
> > > + opp@54000 {
> > > + opp-hz = /bits/ 64 <54000>;
> > > + opp-microvolt = <91>;
> > > + };
> > > + opp@50400 {
> > > + opp-hz = /bits/ 64 <50400>;
> > > + opp-microvolt = <89>;
> > > + };
> > > + opp@45600 {
> > > + opp-hz = /bits/ 64 <45600>;
> > > + opp-microvolt = <87>;
> > > + };
> > > + opp@43200 {
> > > + opp-hz = /bits/ 64 <43200>;
> > > + opp-microvolt = <86>;
> > > + };
> > > + opp@42000 {
> > > + opp-hz = /bits/ 64 <42000>;
> > > + opp-microvolt = <85>;
> > > + };
> > > + opp@40800 {
> > > + opp-hz = /bits/ 64 <40800>;
> > > + opp-microvolt = <84>;
> > > + };
> > > + opp@38400 {
> > > + opp-hz = /bits/ 64 <38400>;
> > > + opp-microvolt = <83>;
> > > + };
> > > + opp@36000 {
> > > + opp-hz = /bits/ 64 <36000>;
> > > + opp-microvolt = <82>;
> > > + };
> > > + opp@33600 {
> > > + opp-hz = /bits/ 64 <33600>;
> > > + opp-microvolt = <81>;
> > > + };
> > > + opp@31200 {
> > > + opp-hz = /bits/ 64 <31200>;
> > > + opp-microvolt = <81>;
> > > + };
> > > + opp@26400 {
> > > + opp-hz = /bits/ 64 <26400>;
> > > + opp-microvolt = <81>;
> > > + };
> > > + opp@21600 {
> > > + opp-hz = /bits/ 64 <21600>;
> > > + opp-microvolt = <81>;
> > > + };
> > > + };
> > > +
> >
> > How were those OPPs tested?
>
> They are taken from the vendor device tree.
> https://github.com/Allwinner-Homlet/H6-BSP4.9-linux/blob/master/arch/arm64/boot/dts/sunxi/sun50iw6p1.dtsi#L2121
Please remove them if you haven't tested them then.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 21/25] drm/mediatek: add support for mediatek SOC MT8183
Hi, Yongqiang:
On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 27 +-
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 12 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 130
> +++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++
> 6 files changed, 211 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c226284..ebadcfe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -328,7 +328,12 @@ static int mtk_disp_ovl_probe(struct platform_device
> *pdev)
> if (irq < 0)
> return irq;
>
> - comp_id = mtk_ddp_comp_get_id(dev->of_node, MTK_DISP_OVL);
> + priv->data = of_device_get_match_data(dev);
> +
> + comp_id = mtk_ddp_comp_get_id(dev->of_node,
> + priv->data->layer_nr == 4 ?
> + MTK_DISP_OVL :
> + MTK_DISP_OVL_2L);
This look like a general ovl_2l modification (not only for MT8183), so I
would like you move the general part to an independent patch.
> if (comp_id < 0) {
> dev_err(dev, "Failed to identify by alias: %d\n", comp_id);
> return comp_id;
> @@ -341,8 +346,6 @@ static int mtk_disp_ovl_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - priv->data = of_device_get_match_data(dev);
> -
> platform_set_drvdata(pdev, priv);
>
> ret = devm_request_irq(dev, irq, mtk_disp_ovl_irq_handler,
> @@ -380,11 +383,29 @@ static int mtk_disp_ovl_remove(struct platform_device
> *pdev)
> .fmt_rgb565_is_0 = true,
> };
>
> +static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 4,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> +static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> + .addr = DISP_REG_OVL_ADDR_MT8173,
> + .gmc_bits = 10,
> + .layer_nr = 2,
> + .fmt_rgb565_is_0 = true,
> +};
> +
> static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-ovl",
> .data = &mt2701_ovl_driver_data},
> { .compatible = "mediatek,mt8173-disp-ovl",
> .data = &mt8173_ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl",
> + .data = &mt8183_ovl_driver_data},
> + { .compatible = "mediatek,mt8183-disp-ovl-2l",
> + .data = &mt8183_ovl_2l_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_ovl_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index ead38ba..602f668 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -343,11 +343,23 @@ static int mtk_disp_rdma_remove(struct platform_device
> *pdev)
> .fifo_size = SZ_8K,
> };
>
> +static const struct mtk_disp_rdma_data mt8183_rdma_driver_data = {
> + .fifo_size = 5 * SZ_1K,
> +};
> +
> +static const struct mtk_disp_rdma_data mt8183_rdma1_driver_data = {
> + .fifo_size = SZ_2K,
> +};
> +
> static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {
> { .compatible = "mediatek,mt2701-disp-rdma",
> .data = &mt2701_rdma_driver_data},
> { .compatible = "mediatek,mt8173-disp-rdma",
> .data = &mt8173_rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma",
> + .data = &mt8183_rdma_driver_data},
> + { .compatible = "mediatek,mt8183-disp-rdma1",
> + .data = &mt8183_rdma1_driver_data},
> {},
> };
> MODULE_DEVICE_TABLE(of, mtk_disp_rdma_driver_dt_match);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> index ee395d3..3cb9569 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> @@ -11,6 +11,7 @@
> * GNU General Public License for more details.
> */
>
> +#include
> #include
> #include
> #include
> @@ -41,8 +42,36 @@
> #define DISP_REG_CONFIG_DSI_SEL 0x050
> #define DISP_REG_CONFIG_DPI_SEL 0x064
>
> +#define MT8183_DISP_OVL0_MOUT_EN 0xF00
> +#define OVL0_MOUT_EN_DISP_PATH0 BIT(0)
> +#define OVL0_MOUT_EN_OVL0_2L B
Re: [PATCH v2 09/25] drm/mediatek: add mmsys private data for ddp path config
Hi, Yongqiang:
On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add mmsys private data for ddp path config
> all these register offset and value will be different in future SOC
> add these define into mmsys private data
> u32 ovl0_mout_en;
> u32 rdma0_sout_sel_in;
> u32 rdma0_sout_color0;
> u32 rdma1_sout_sel_in;
> u32 rdma1_sout_dpi0;
> u32 rdma1_sout_dsi0;
> u32 dpi0_sel_in;
> u32 dpi0_sel_in_rdma1;
> u32 dsi0_sel_in;
> u32 dsi0_sel_in_rdma1;
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 103
> ++--
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 10
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 11
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 4 ++
> 5 files changed, 113 insertions(+), 19 deletions(-)
[snip]
>
> +const struct mtk_mmsys_reg_data *mtk_ddp_get_mmsys_data(enum mtk_mmsys_id id)
> +{
> + const struct mtk_mmsys_reg_data *data = NULL;
> +
> + switch (id) {
> + case MMSYS_MT2701:
> + data = &mt2701_mmsys_reg_data;
> + break;
> + case MMSYS_MT2712:
> + data = &mt8173_mmsys_reg_data;
> + break;
> + case MMSYS_MT8173:
> + data = &mt8173_mmsys_reg_data;
> + break;
> + default:
> + pr_info("mtk drm not support mmsys id %d\n",
> + id);
> + break;
> + }
> +
> + return data;
> +}
> +
> struct mtk_disp_mutex *mtk_disp_mutex_get(struct device *dev, unsigned int
> id)
> {
> struct mtk_ddp *ddp = dev_get_drvdata(dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> index f9a7991..ed2b702 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.h
> @@ -19,11 +19,21 @@
> struct regmap;
> struct device;
> struct mtk_disp_mutex;
> +struct mtk_mmsys_reg_data;
> +enum mtk_mmsys_id {
> + MMSYS_MT2701,
> + MMSYS_MT2712,
> + MMSYS_MT8173,
> + MMSYS_MAX,
> +};
>
> +const struct mtk_mmsys_reg_data *mtk_ddp_get_mmsys_data(enum mtk_mmsys_id
> id);
> void mtk_ddp_add_comp_to_path(void __iomem *config_regs,
> + const struct mtk_mmsys_reg_data *reg_data,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next);
> void mtk_ddp_remove_comp_from_path(void __iomem *config_regs,
> +const struct mtk_mmsys_reg_data *reg_data,
> enum mtk_ddp_comp_id cur,
> enum mtk_ddp_comp_id next);
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index cf59ea9..356853c 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -196,6 +196,7 @@ static int mtk_atomic_commit(struct drm_device *drm,
> .main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
> .ext_path = mt2701_mtk_ddp_ext,
> .ext_len = ARRAY_SIZE(mt2701_mtk_ddp_ext),
> + .mmsys_id = MMSYS_MT2701,
> .shadow_register = true,
> };
>
> @@ -206,6 +207,7 @@ static int mtk_atomic_commit(struct drm_device *drm,
> .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
> .third_path = mt2712_mtk_ddp_third,
> .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
> + .mmsys_id = MMSYS_MT2712,
> };
>
> static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> @@ -213,6 +215,7 @@ static int mtk_atomic_commit(struct drm_device *drm,
> .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> .ext_path = mt8173_mtk_ddp_ext,
> .ext_len = ARRAY_SIZE(mt8173_mtk_ddp_ext),
> + .mmsys_id = MMSYS_MT8173,
> };
>
> static int mtk_drm_kms_init(struct drm_device *drm)
> @@ -461,6 +464,14 @@ static int mtk_drm_probe(struct platform_device *pdev)
> INIT_WORK(&private->commit.work, mtk_atomic_work);
> private->data = of_device_get_match_data(dev);
>
> + private->reg_data = mtk_ddp_get_mmsys_data(private->data->mmsys_id);
Why do you create a function to select reg_data, I think you could just
add reg_data in struct mtk_mmsys_driver_data so you don't need a
function to select it.
Regards,
CK
> + if (IS_ERR(private->reg_data)) {
> + ret = PTR_ERR(private->config_regs);
> + pr_info("Failed to get mmsys register data: %d\n",
> + ret);
> + return ret;
> + }
> +
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> private->config_regs = devm_ioremap_resource(dev, mem);
> if (IS_ERR(private->config_regs)) {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
> index ecc00ca..11de7f8 100644
> --- a/drivers/gpu/drm/mediat
Re: [PATCH] gpu: host1x: fix compile error when IOMMU API is not available
On 11.4.2019 11.30, Thierry Reding wrote:
On Thu, Apr 11, 2019 at 09:23:13AM +0100, Ben Dooks wrote:
On 2019-04-10 23:47, Stefan Agner wrote:
In case the IOMMU API is not available compiling host1x fails with
the following error:
In file included from drivers/gpu/host1x/hw/host1x06.c:27:
drivers/gpu/host1x/hw/channel_hw.c: In function
‘host1x_channel_set_streamid’:
drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit
declaration of function
‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’?
[-Werror=implicit-function-declaration]
struct iommu_fwspec *spec =
dev_iommu_fwspec_get(channel->dev->parent);
^~~~
iommu_fwspec_free
Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
Signed-off-by: Stefan Agner
would it be better to provide something like this i nthe header that
defines dev_iommu_fwspec_get() to be:
static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device *dev)
{ return NULL; }
although returning an PTR_ERR would have been better.
I don't think there's really a large number of failures here. Either
your device has an IOMMU fwspec or it doesn't.
But yes, I think it'd be better to have the above static inline dummy in
iommu.h, but I'll apply this for now in the hopes of getting it in
before v5.1 final.
A similar patch was already sent before by someone. That one also
programs the bypass stream ID (0x7f) even if IOMMU is disabled. We
should pick that patch instead.
Thanks,
Mikko
Thierry >
---
drivers/gpu/host1x/hw/channel_hw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index 27101c04a827..4030d64916f0 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -114,7 +114,7 @@ static inline void synchronize_syncpt_base(struct
host1x_job *job)
static void host1x_channel_set_streamid(struct host1x_channel *channel)
{
-#if HOST1X_HW >= 6
+#if IS_ENABLED(CONFIG_IOMMU_API) && HOST1X_HW >= 6
struct iommu_fwspec *spec =
dev_iommu_fwspec_get(channel->dev->parent);
u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
___
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
[Bug 110229] Textures binded to framebuffer objects or images are not correctly updated.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 --- Comment #26 from Laurent --- Hi! Is still someone here ? I've found the function which doesn't work, it's glMemoryBarrier. glCheck(glMemoryBarrier( GL_SHADER_STORAGE_BARRIER_BIT )); It doesn't wait after the first shader have written all nodes to the SSBO before the second shader read it! This is why the per pixel linked list doesn't work. -- 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 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Laurent changed: What|Removed |Added Summary|Textures binded to |glMemoryBarrier doesn't |framebuffer objects or |work. |images are not correctly| |updated.| -- 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 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Laurent changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTOURBUG |--- -- 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 14/25] drm/medaitek: add layer_nr for ovl private data
Hi, Yongqiang:
On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add layer_nr for ovl private data
> ovl_2l almost same with with ovl hardware, except the
> layer number for ovl_2l is 2 and ovl is 4.
> this patch is a preparation for ovl-2l and
> ovl share the same driver.
Reviewed-by: CK Hu
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index afb313c..a0ab760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -60,6 +60,7 @@
> struct mtk_disp_ovl_data {
> unsigned int addr;
> unsigned int gmc_bits;
> + unsigned int layer_nr;
> bool fmt_rgb565_is_0;
> };
>
> @@ -137,7 +138,9 @@ static void mtk_ovl_config(struct mtk_ddp_comp *comp,
> unsigned int w,
>
> static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
> {
> - return 4;
> + struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
> +
> + return ovl->data->layer_nr;
> }
>
> static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
> @@ -342,12 +345,14 @@ static int mtk_disp_ovl_remove(struct platform_device
> *pdev)
> static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT2701,
> .gmc_bits = 8,
> + .layer_nr = 4,
> .fmt_rgb565_is_0 = false,
> };
>
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .addr = DISP_REG_OVL_ADDR_MT8173,
> .gmc_bits = 8,
> + .layer_nr = 4,
> .fmt_rgb565_is_0 = true,
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: host1x: fix compile error when IOMMU API is not available
On 11.04.2019 10:23, Ben Dooks wrote:
> On 2019-04-10 23:47, Stefan Agner wrote:
>> In case the IOMMU API is not available compiling host1x fails with
>> the following error:
>> In file included from drivers/gpu/host1x/hw/host1x06.c:27:
>> drivers/gpu/host1x/hw/channel_hw.c: In function
>> ‘host1x_channel_set_streamid’:
>> drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit
>> declaration of function
>> ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’?
>> [-Werror=implicit-function-declaration]
>> struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
>> ^~~~
>> iommu_fwspec_free
>>
>> Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
>> Signed-off-by: Stefan Agner
>
> would it be better to provide something like this i nthe header that
> defines dev_iommu_fwspec_get() to be:
>
> static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device
> *dev) { return NULL; }
>
> although returning an PTR_ERR would have been better.
>
The problem is that the code also accesses fields of struct iommu_fwspec
which are not defined in the !CONFIG_IOMMU_API case.
--
Stefan
>> ---
>> drivers/gpu/host1x/hw/channel_hw.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/host1x/hw/channel_hw.c
>> b/drivers/gpu/host1x/hw/channel_hw.c
>> index 27101c04a827..4030d64916f0 100644
>> --- a/drivers/gpu/host1x/hw/channel_hw.c
>> +++ b/drivers/gpu/host1x/hw/channel_hw.c
>> @@ -114,7 +114,7 @@ static inline void synchronize_syncpt_base(struct
>> host1x_job *job)
>>
>> static void host1x_channel_set_streamid(struct host1x_channel *channel)
>> {
>> -#if HOST1X_HW >= 6
>> +#if IS_ENABLED(CONFIG_IOMMU_API) && HOST1X_HW >= 6
>> struct iommu_fwspec *spec = dev_iommu_fwspec_get(channel->dev->parent);
>> u32 sid = spec ? spec->ids[0] & 0x : 0x7f;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/25] drm/mediatek: add function to background color input select for ovl/ovl_2l direct link
Hi, Yongqiang:
On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add function to background color input select for ovl/ovl_2l
> direct link
> for ovl/ovl_2l direct link usecase, we need set background color
> input select for these hardware.
> this is preparation patch for ovl/ovl_2l usecase
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index b76b663..20e8061 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -92,6 +92,9 @@ struct mtk_ddp_comp_funcs {
>struct mtk_plane_state *state);
> void (*gamma_set)(struct mtk_ddp_comp *comp,
> struct drm_crtc_state *state);
> +void (*bgclr_in_on)(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev);
> +void (*bgclr_in_off)(struct mtk_ddp_comp *comp);
> };
>
> struct mtk_ddp_comp {
> @@ -173,6 +176,19 @@ static inline void mtk_ddp_gamma_set(struct mtk_ddp_comp
> *comp,
> comp->funcs->gamma_set(comp, state);
> }
>
> +static inline void mtk_ddp_comp_bgclr_in_on(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev)
> +{
> +if (comp->funcs && comp->funcs->bgclr_in_on)
> +comp->funcs->bgclr_in_on(comp, prev);
> +}
> +
> +static inline void mtk_ddp_comp_bgclr_in_off(struct mtk_ddp_comp *comp)
> +{
> +if (comp->funcs && comp->funcs->bgclr_in_off)
> +comp->funcs->bgclr_in_off(comp);
I think you should use a 'tab' to replace 8 white space.
Regards,
CK
> +}
> +
> int mtk_ddp_comp_get_id(struct device_node *node,
> enum mtk_ddp_comp_type comp_type);
> int mtk_ddp_comp_init(struct device *dev, struct device_node *comp_node,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/25] drm/mediatek: add ddp write register common api
Hi, Yongqiang:
On Wed, 2019-03-27 at 14:19 +0800, yongqiang@mediatek.com wrote:
> From: Yongqiang Niu
>
> This patch add ddp write register common api
> this is preparation patch for ovl/ovl_2l direct link
> usecase.
> in that case, we need this funtion to set one bit of ovl_2l
> register
The reason is so strange. You could grep 'readl' in mediatek drm driver,
and you would find that many place need this function.
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 11 +++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 4
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index afd6ca2..72288b4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -84,6 +84,17 @@
> #define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) << 4)
> #define DITHER_ADD_RSHIFT_G(x) (((x) & 0x7) << 0)
>
> +void mtk_ddp_write_mask(unsigned int value,
> + struct mtk_ddp_comp *comp,
> + unsigned int offset,
> + unsigned int mask)
> +{
> + unsigned int tmp = readl(comp->regs + offset);
> +
> + tmp = (tmp & ~mask) | (value & mask);
Why not just place this calculation into writel()?
Regards,
CK
> + writel(tmp, comp->regs + offset);
> +}
> +
> void mtk_dither_set(struct mtk_ddp_comp *comp, unsigned int bpc,
> unsigned int CFG)
> {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 20e8061..ed715ff 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -198,5 +198,9 @@ int mtk_ddp_comp_init(struct device *dev, struct
> device_node *comp_node,
> void mtk_ddp_comp_unregister(struct drm_device *drm, struct mtk_ddp_comp
> *comp);
> void mtk_dither_set(struct mtk_ddp_comp *comp, unsigned int bpc,
> unsigned int CFG);
> +void mtk_ddp_write_mask(unsigned int value,
> + struct mtk_ddp_comp *comp,
> + unsigned int offset,
> + unsigned int mask);
>
> #endif /* MTK_DRM_DDP_COMP_H */
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102670] [CI] igt@kms_cursor_legacy@*flip-vs-cursor-* Failed assertion: get_vblank(display->drm_fd, pipe, 0) == *
https://bugs.freedesktop.org/show_bug.cgi?id=102670 Arek Hiler changed: What|Removed |Added i915 platform|BXT, GLK, HSW, I915G, KBL, |ALL |SKL, SNB| QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org CC||arkadiusz.hi...@intel.com Component|DRM/Intel |IGT --- Comment #17 from Arek Hiler --- The test seems to be very prone to race conditions and this may explain the sporadic failures we see (few instances every week, affects all the machines): 1. we try to figure out experimentally how many cursor updates we can squeeze between vblanks, by starting with a high number and lowering it until we fit. Our target is a quarter of that 2. we pin our process to a CPU and fork a busy loop with sched_yield(); 3. 150 loops of trying to squeeze target cursor updates within one vblank This doesn't take power and thermal budged into account and makes a lot of assumptions about process scheduling on a non-RTOS. User impact is low. We loose some coverage. Test needs to be reworked. Immediate steps: 1. log the delta between vblanks, so we can regain some coverage by having better filters 2. log our target 3. don't exit early, show how many iterations of the 150 had failed This is related and it makes sense to work on both together: https://bugs.freedesktop.org/show_bug.cgi?id=103355 -- 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 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Andre Klapper changed: What|Removed |Added Status|REOPENED|NEEDINFO --- Comment #27 from Andre Klapper --- Feel free to attach a minimal, self-contained test case that allows reproducing. Plus always include filenames and paths when posting random code lines. -- 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 108990] [CI][DRMTIP] igt@pm_rpm@basic-rte - incomplete
https://bugs.freedesktop.org/show_bug.cgi?id=108990 Martin Peres changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Martin Peres --- *** This bug has been marked as a duplicate of bug 108840 *** -- 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 108990] [CI][DRMTIP] igt@pm_rpm@basic-rte - incomplete
https://bugs.freedesktop.org/show_bug.cgi?id=108990 --- Comment #2 from CI Bug Log --- The CI Bug Log issue associated to this bug has been archived. New failures matching the above filters will not be associated to this bug anymore. -- 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 v3 04/11] pinctrl: sunxi: Support I/O bias voltage setting on H6
Hi,
On Thu, Apr 11, 2019 at 12:19:44PM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> H6 SoC has a "pio group withstand voltage mode" register (datasheet
> description), that needs to be used to select either 1.8V or 3.3V I/O mode,
> based on what voltage is powering the respective pin banks and is thus used
> for I/O signals.
>
> Add support for configuring this register according to the voltage of the
> pin bank regulator (if enabled).
>
> This is similar to the support for I/O bias voltage setting patch for A80
> and the same concerns apply. See:
>
> commit 402bfb3c1352 ("Support I/O bias voltage setting on A80")
>
> Signed-off-by: Ondrej Jirman
> ---
> drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c | 1 +
> drivers/pinctrl/sunxi/pinctrl-sunxi.c | 11 +++
> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 5 +
> 3 files changed, 17 insertions(+)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> index ef4268cc6227..3cc1121589c9 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c
> @@ -591,6 +591,7 @@ static const struct sunxi_pinctrl_desc h6_pinctrl_data = {
> .irq_banks = 4,
> .irq_bank_map = h6_irq_bank_map,
> .irq_read_needs_mux = true,
> + .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> };
>
> static int h6_pinctrl_probe(struct platform_device *pdev)
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> index 98c4de5f4019..0cbca30b75dc 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> @@ -614,6 +614,8 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct
> sunxi_pinctrl *pctl,
>unsigned pin,
>struct regulator *supply)
> {
> + unsigned short bank = pin / PINS_PER_BANK;
> + unsigned long flags;
> u32 val, reg;
> int uV;
>
> @@ -651,6 +653,15 @@ static int sunxi_pinctrl_set_io_bias_cfg(struct
> sunxi_pinctrl *pctl,
> reg &= ~IO_BIAS_MASK;
> writel(reg | val, pctl->membase + sunxi_grp_config_reg(pin));
> return 0;
> + case BIAS_VOLTAGE_PIO_POW_MODE_SEL:
> + val = uV <= 180 ? 1 : 0;
> +
> + raw_spin_lock_irqsave(&pctl->lock, flags);
> + reg = readl(pctl->membase + PIO_POW_MOD_SEL_REG);
> + reg &= ~(1 << bank);
> + writel(reg | val << bank, pctl->membase + PIO_POW_MOD_SEL_REG);
> + raw_spin_unlock_irqrestore(&pctl->lock, flags);
> + return 0;
> default:
> return -EINVAL;
> }
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> index 4bfc8a6d9dce..36186906f0a7 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.h
> @@ -95,11 +95,16 @@
> #define PINCTRL_SUN7I_A20BIT(7)
> #define PINCTRL_SUN8I_R40BIT(8)
>
> +#define PIO_POW_MOD_SEL_REG 0x340
> +
> enum sunxi_desc_bias_voltage {
> BIAS_VOLTAGE_NONE,
> /* Bias voltage configuration is done through
>* Pn_GRP_CONFIG registers, as seen on A80 SoC. */
> BIAS_VOLTAGE_GRP_CONFIG,
> + /* Bias voltage is set through PIO_POW_MOD_SEL_REG
> + * register, as seen on H6 SoC, for example. */
That's not the proper comment style.
Once fixed, this patch and the previous is
Acked-by: Maxime Ripard
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 07/11] drm: sun4i: Add support for enabling DDC I2C bus power to dw_hdmi glue
On Thu, Apr 11, 2019 at 12:19:47PM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> Orange Pi 3 board requires enabling DDC I2C bus via some GPIO connected
> transistors, before the bus can be used.
>
> Model this as a power supply for DDC bus on the HDMI connector connected
> to the output port (port 1) of the HDMI controller.
>
> Signed-off-by: Ondrej Jirman
> ---
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 60 ++-
> drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 2 +
> 2 files changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> index 39d8509d96a0..1b6ffba41177 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -98,6 +98,30 @@ static u32 sun8i_dw_hdmi_find_possible_crtcs(struct
> drm_device *drm,
> return crtcs;
> }
>
> +static int sun8i_dw_hdmi_find_connector_pdev(struct device *dev,
> + struct platform_device **pdev_out)
> +{
> + struct platform_device* pdev;
This doesn't respect the guidelines.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/8] dt-bindings: gpu: add bus clock for Mali Midgard GPUs
On Thu, Apr 11, 2019 at 12:57:14PM +0200, Clément Péron wrote: > Some SoCs adds a bus clock gate to the Mali Midgard GPU. > > Add the binding for the bus clock. > > Signed-off-by: Icenowy Zheng > Signed-off-by: Clément Péron I'm not quite sure what you did there. If Icenowy is the author and you're sending that commit on her behalf, then she should have the authorship of that commit. If you're the author of that commit, then we Icenowy's SoB is there? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/8] Add Allwinner H6 Mali Midgard GPU
On Thu, Apr 11, 2019 at 12:57:12PM +0200, Clément Péron wrote: > Hi, > > The Allwinner H6 has a Mali-T720 MP2. The drivers are > out-of-tree so this series only introduce the dt-bindings. > > The first patch is from Neil Amstrong and has been already > merged in linux-amlogic. It is required for this series. > > The second patch is from Icenowy Zheng where I changed the > order has required by Rob Herring. > See: https://patchwork.kernel.org/patch/10699829/ > > The GPU opp table was taken from Jernej Škrabec's patch > on LibreELEC.tv. One valuable information here would be which stack did you use, panfrost and mesa or the ARM stack? If so, with which driver and which blob? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] drm/vc4: Allow for more boot-time configuration
Hi, The proprietary stack for the RaspberryPi allows for a number of video parameters widely used by their users, but yet don't have any equivalents in the mainline kernel. Those options are detailed here: https://www.raspberrypi.org/documentation/configuration/config-txt/video.md While not all of them are desirable to have in the mainline kernel, some of them still have value, such as properties to initialise the overscan or rotation parameters. This series is an attempt to support those, and is based on a rewrite of the command line parser I did a couple of years ago that never reached upstream (due to a lack of time on my side). While this parser was initially made to deal with named modes (in order to support TV modes), it also allowed to extend it more easily, which is why it's resurrected. Let me know what you think, Maxime Changes from v1: - Dropped the patches to deal with EDID - Added the unit test as selftest - Rebased on next Maxime Ripard (5): drm/modes: Rewrite the command line parser drm/modes: Support modes names on the command line drm/modes: Allow to specify rotation and reflection on the commandline drm/modes: Parse overscan properties drm/selftests: Add command line parser selftests drivers/gpu/drm/drm_connector.c | 3 +- drivers/gpu/drm/drm_fb_helper.c | 55 +- drivers/gpu/drm/drm_modes.c | 441 +-- drivers/gpu/drm/selftests/Makefile | 2 +- drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 49 +- drivers/gpu/drm/selftests/test-drm_cmdline_parser.c | 843 +- include/drm/drm_connector.h | 3 +- 7 files changed, 1279 insertions(+), 117 deletions(-) create mode 100644 drivers/gpu/drm/selftests/drm_cmdline_selftests.h create mode 100644 drivers/gpu/drm/selftests/test-drm_cmdline_parser.c base-commit: 2f4c4d833153517c7791318f8608cf5c212cef68 -- git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/modes: Support modes names on the command line
From: Maxime Ripard
The drm subsystem also uses the video= kernel parameter, and in the
documentation refers to the fbdev documentation for that parameter.
However, that documentation also says that instead of giving the mode using
its resolution we can also give a name. However, DRM doesn't handle that
case at the moment. Even though in most case it shouldn't make any
difference, it might be useful for analog modes, where different standards
might have the same resolution, but still have a few different parameters
that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example).
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 3 +-
drivers/gpu/drm/drm_fb_helper.c | 4 +++-
drivers/gpu/drm/drm_modes.c | 49 +++---
include/drm/drm_connector.h | 1 +-
4 files changed, 41 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2355124849db..e33814f5940e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -139,8 +139,9 @@ static void drm_connector_get_cmdline_mode(struct
drm_connector *connector)
connector->force = mode->force;
}
- DRM_DEBUG_KMS("cmdline mode for connector %s %dx%d@%dHz%s%s%s\n",
+ DRM_DEBUG_KMS("cmdline mode for connector %s %s %dx%d@%dHz%s%s%s\n",
connector->name,
+ mode->name ? mode->name : "",
mode->xres, mode->yres,
mode->refresh_specified ? mode->refresh : 60,
mode->rb ? " reduced blanking" : "",
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d1ce7bd04cad..b3a5d79436ae 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2156,6 +2156,10 @@ struct drm_display_mode *drm_pick_cmdline_mode(struct
drm_fb_helper_connector *f
prefer_non_interlace = !cmdline_mode->interlace;
again:
list_for_each_entry(mode, &fb_helper_conn->connector->modes, head) {
+ /* Check (optional) mode name first */
+ if (!strcmp(mode->name, cmdline_mode->name))
+ return mode;
+
/* check width/height */
if (mode->hdisplay != cmdline_mode->xres ||
mode->vdisplay != cmdline_mode->yres)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index bbacb7743f3b..9613c1a28487 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1557,7 +1557,7 @@ bool drm_mode_parse_command_line_for_connector(const char
*mode_option,
struct drm_cmdline_mode *mode)
{
const char *name;
- bool parse_extras = false;
+ bool named_mode = false, parse_extras = false;
unsigned int bpp_off = 0, refresh_off = 0;
unsigned int mode_end = 0;
char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
@@ -1576,8 +1576,14 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
name = mode_option;
+ /*
+* If the first character is not a digit, then it means that
+* we have a named mode.
+*/
if (!isdigit(name[0]))
- return false;
+ named_mode = true;
+ else
+ named_mode = false;
/* Try to locate the bpp and refresh specifiers, if any */
bpp_ptr = strchr(name, '-');
@@ -1607,12 +1613,16 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
parse_extras = true;
}
- ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
- parse_extras,
- connector,
- mode);
- if (ret)
- return false;
+ if (named_mode) {
+ strncpy(mode->name, name, mode_end);
+ } else {
+ ret = drm_mode_parse_cmdline_res_mode(name, mode_end,
+ parse_extras,
+ connector,
+ mode);
+ if (ret)
+ return false;
+ }
mode->specified = true;
if (bpp_ptr) {
@@ -1640,14 +1650,23 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
extra_ptr = refresh_end_ptr;
if (extra_ptr) {
- int remaining = strlen(name) - (extra_ptr - name);
+ if (!named_mode) {
+ int len = strlen(name) - (extra_ptr - name);
- /*
-* We still have characters to process, while
-* we shouldn't have any
-*/
- if (remaining > 0)
- retu
[PATCH v2 3/5] drm/modes: Allow to specify rotation and reflection on the commandline
Rotations and reflections setup are needed in some scenarios to initialise
properly the initial framebuffer. Some drivers already had a bunch of
quirks to deal with this, such as either a private kernel command line
parameter (omapdss) or on the device tree (various panels).
In order to accomodate this, let's create a video mode parameter to deal
with the rotation and reflexion.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 4 +-
drivers/gpu/drm/drm_modes.c | 110 +++--
include/drm/drm_connector.h | 1 +-
3 files changed, 95 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index b3a5d79436ae..8781897559b2 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2521,6 +2521,7 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper
*fb_helper,
struct drm_connector *connector)
{
struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
+ struct drm_cmdline_mode *mode = &connector->cmdline_mode;
uint64_t valid_mask = 0;
int i, rotation;
@@ -2540,6 +2541,9 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper
*fb_helper,
rotation = DRM_MODE_ROTATE_0;
}
+ if (mode->rotation != DRM_MODE_ROTATE_0)
+ fb_crtc->rotation = mode->rotation;
+
/*
* TODO: support 90 / 270 degree hardware rotation,
* depending on the hardware this may require the framebuffer
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 9613c1a28487..ac8d70b92b62 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1531,6 +1531,71 @@ static int drm_mode_parse_cmdline_res_mode(const char
*str, unsigned int length,
return 0;
}
+static int drm_mode_parse_cmdline_options(char *str, size_t len,
+ struct drm_connector *connector,
+ struct drm_cmdline_mode *mode)
+{
+ unsigned int rotation = 0;
+ char *sep = str;
+
+ while ((sep = strchr(sep, ','))) {
+ char *delim, *option;
+
+ option = sep + 1;
+ delim = strchr(option, '=');
+ if (!delim) {
+ delim = strchr(option, ',');
+
+ if (!delim)
+ delim = str + len;
+ }
+
+ if (!strncmp(option, "rotate", delim - option)) {
+ const char *value = delim + 1;
+ unsigned int deg;
+
+ deg = simple_strtol(value, &sep, 10);
+
+ /* Make sure we have parsed something */
+ if (sep == value)
+ return -EINVAL;
+
+ switch (deg) {
+ case 0:
+ rotation |= DRM_MODE_ROTATE_0;
+ break;
+
+ case 90:
+ rotation |= DRM_MODE_ROTATE_90;
+ break;
+
+ case 180:
+ rotation |= DRM_MODE_ROTATE_180;
+ break;
+
+ case 270:
+ rotation |= DRM_MODE_ROTATE_270;
+ break;
+
+ default:
+ return -EINVAL;
+ }
+ } else if (!strncmp(option, "reflect_x", delim - option)) {
+ rotation |= DRM_MODE_REFLECT_X;
+ sep = delim;
+ } else if (!strncmp(option, "reflect_y", delim - option)) {
+ rotation |= DRM_MODE_REFLECT_Y;
+ sep = delim;
+ } else {
+ return -EINVAL;
+ }
+ }
+
+ mode->rotation = rotation;
+
+ return 0;
+}
+
/**
* drm_mode_parse_command_line_for_connector - parse command line modeline for
connector
* @mode_option: optional per connector mode option
@@ -1558,9 +1623,10 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
{
const char *name;
bool named_mode = false, parse_extras = false;
- unsigned int bpp_off = 0, refresh_off = 0;
+ unsigned int bpp_off = 0, refresh_off = 0, options_off = 0;
unsigned int mode_end = 0;
char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
+ char *options_ptr = NULL;
char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
int ret;
@@ -1601,13 +1667,18 @@ bool drm_mode_parse_command_line_for_connector(const
char *mode_option,
mode->refresh_specified = true;
}
+ /* Locate the start of named options */
+ options_ptr = strchr(name, '
[PATCH v2 4/5] drm/modes: Parse overscan properties
Properly configuring the overscan properties might be needed for the
initial setup of the framebuffer for display that still have overscan.
Let's allow for more properties on the kernel command line to setup each
margin.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 47 ++-
drivers/gpu/drm/drm_modes.c | 44 -
include/drm/drm_connector.h | 1 +-
3 files changed, 92 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8781897559b2..4e403fe1f451 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2567,6 +2567,51 @@ static void drm_setup_crtc_rotation(struct drm_fb_helper
*fb_helper,
fb_helper->sw_rotations |= DRM_MODE_ROTATE_0;
}
+static void drm_setup_connector_margins(struct drm_connector *connector)
+{
+ struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
+ struct drm_modeset_acquire_ctx ctx;
+ struct drm_atomic_state *state;
+ struct drm_device *dev = connector->dev;
+ int ret;
+
+ if (!drm_drv_uses_atomic_modeset(dev))
+ return;
+
+ drm_modeset_acquire_init(&ctx, 0);
+
+ state = drm_atomic_state_alloc(dev);
+ state->acquire_ctx = &ctx;
+
+retry:
+ drm_atomic_set_property(state, &connector->base,
+ dev->mode_config.tv_left_margin_property,
+ cmdline->overscan_left);
+
+ drm_atomic_set_property(state, &connector->base,
+ dev->mode_config.tv_right_margin_property,
+ cmdline->overscan_right);
+
+ drm_atomic_set_property(state, &connector->base,
+ dev->mode_config.tv_top_margin_property,
+ cmdline->overscan_top);
+
+ drm_atomic_set_property(state, &connector->base,
+ dev->mode_config.tv_bottom_margin_property,
+ cmdline->overscan_bottom);
+
+ ret = drm_atomic_commit(state);
+ if (ret == -EDEADLK) {
+ drm_atomic_state_clear(state);
+ drm_modeset_backoff(&ctx);
+ goto retry;
+ }
+
+ drm_atomic_state_put(state);
+ drm_modeset_drop_locks(&ctx);
+ drm_modeset_acquire_fini(&ctx);
+}
+
static void drm_setup_crtcs(struct drm_fb_helper *fb_helper,
u32 width, u32 height)
{
@@ -2680,6 +2725,8 @@ static void drm_setup_crtcs_fb(struct drm_fb_helper
*fb_helper)
struct drm_connector *connector =
fb_helper->connector_info[i]->connector;
+ drm_setup_connector_margins(connector);
+
/* use first connected connector for the physical dimensions */
if (connector->status == connector_status_connected) {
info->var.width = connector->display_info.width_mm;
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac8d70b92b62..493ba3ccde70 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1586,6 +1586,50 @@ static int drm_mode_parse_cmdline_options(char *str,
size_t len,
} else if (!strncmp(option, "reflect_y", delim - option)) {
rotation |= DRM_MODE_REFLECT_Y;
sep = delim;
+ } else if (!strncmp(option, "overscan_right", delim - option)) {
+ const char *value = delim + 1;
+ unsigned int margin;
+
+ margin = simple_strtol(value, &sep, 10);
+
+ /* Make sure we have parsed something */
+ if (sep == value)
+ return -EINVAL;
+
+ mode->overscan_right = margin;
+ } else if (!strncmp(option, "overscan_left", delim - option)) {
+ const char *value = delim + 1;
+ unsigned int margin;
+
+ margin = simple_strtol(value, &sep, 10);
+
+ /* Make sure we have parsed something */
+ if (sep == value)
+ return -EINVAL;
+
+ mode->overscan_left = margin;
+ } else if (!strncmp(option, "overscan_top", delim - option)) {
+ const char *value = delim + 1;
+ unsigned int margin;
+
+ margin = simple_strtol(value, &sep, 10);
+
+ /* Make sure we have parsed something */
+ if (sep == value)
+ return -EINVAL;
+
+ mode->overscan_top = margin;
+ } else if (!strncmp(option, "overscan_bottom", delim - option))
{
+ const char *value = delim + 1;
+
[PATCH v2 1/5] drm/modes: Rewrite the command line parser
From: Maxime Ripard
Rewrite the command line parser in order to get away from the state machine
parsing the video mode lines.
Hopefully, this will allow to extend it more easily to support named modes
and / or properties set directly on the command line.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 308 +++--
1 file changed, 193 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 56f92a0bba62..bbacb7743f3b 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -30,6 +30,7 @@
* authorization from the copyright holder(s) and author(s).
*/
+#include
#include
#include
#include
@@ -1405,6 +1406,131 @@ void drm_connector_list_update(struct drm_connector
*connector)
}
EXPORT_SYMBOL(drm_connector_list_update);
+static int drm_mode_parse_cmdline_bpp(const char *str, char **end_ptr,
+ struct drm_cmdline_mode *mode)
+{
+ if (str[0] != '-')
+ return -EINVAL;
+
+ mode->bpp = simple_strtol(str + 1, end_ptr, 10);
+ mode->bpp_specified = true;
+
+ return 0;
+}
+
+static int drm_mode_parse_cmdline_refresh(const char *str, char **end_ptr,
+ struct drm_cmdline_mode *mode)
+{
+ if (str[0] != '@')
+ return -EINVAL;
+
+ mode->refresh = simple_strtol(str + 1, end_ptr, 10);
+ mode->refresh_specified = true;
+
+ return 0;
+}
+
+static int drm_mode_parse_cmdline_extra(const char *str, int length,
+ struct drm_connector *connector,
+ struct drm_cmdline_mode *mode)
+{
+ int i;
+
+ for (i = 0; i < length; i++) {
+ switch (str[i]) {
+ case 'i':
+ mode->interlace = true;
+ break;
+ case 'm':
+ mode->margins = true;
+ break;
+ case 'D':
+ if (mode->force != DRM_FORCE_UNSPECIFIED)
+ return -EINVAL;
+
+ if ((connector->connector_type !=
DRM_MODE_CONNECTOR_DVII) &&
+ (connector->connector_type !=
DRM_MODE_CONNECTOR_HDMIB))
+ mode->force = DRM_FORCE_ON;
+ else
+ mode->force = DRM_FORCE_ON_DIGITAL;
+ break;
+ case 'd':
+ if (mode->force != DRM_FORCE_UNSPECIFIED)
+ return -EINVAL;
+
+ mode->force = DRM_FORCE_OFF;
+ break;
+ case 'e':
+ if (mode->force != DRM_FORCE_UNSPECIFIED)
+ return -EINVAL;
+
+ mode->force = DRM_FORCE_ON;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static int drm_mode_parse_cmdline_res_mode(const char *str, unsigned int
length,
+ bool extras,
+ struct drm_connector *connector,
+ struct drm_cmdline_mode *mode)
+{
+ bool rb = false, cvt = false;
+ int xres = 0, yres = 0;
+ int remaining, i;
+ char *end_ptr;
+
+ xres = simple_strtol(str, &end_ptr, 10);
+
+ if (end_ptr[0] != 'x')
+ return -EINVAL;
+ end_ptr++;
+
+ yres = simple_strtol(end_ptr, &end_ptr, 10);
+
+ remaining = length - (end_ptr - str);
+ if (remaining < 0)
+ return -EINVAL;
+
+ for (i = 0; i < remaining; i++) {
+ switch (end_ptr[i]) {
+ case 'M':
+ cvt = true;
+ break;
+ case 'R':
+ rb = true;
+ break;
+ default:
+ /*
+* Try to pass that to our extras parsing
+* function to handle the case where the
+* extras are directly after the resolution
+*/
+ if (extras) {
+ int ret = drm_mode_parse_cmdline_extra(end_ptr
+ i,
+ 1,
+
connector,
+ mode);
+ if (ret)
+ return ret;
+ } else {
+ return -EINVAL;
+ }
+ }
+ }
+
+ mode->xres = xres;
+ mode->
[PATCH v2 5/5] drm/selftests: Add command line parser selftests
The command line parser is pretty tough to get right and very error prone,
so let's add a selftest to try to catch any regression.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/selftests/Makefile | 2 +-
drivers/gpu/drm/selftests/drm_cmdline_selftests.h | 49 +-
drivers/gpu/drm/selftests/test-drm_cmdline_parser.c | 843 +-
3 files changed, 893 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/selftests/drm_cmdline_selftests.h
create mode 100644 drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
diff --git a/drivers/gpu/drm/selftests/Makefile
b/drivers/gpu/drm/selftests/Makefile
index 1bb73dc4c88c..971cfe17be68 100644
--- a/drivers/gpu/drm/selftests/Makefile
+++ b/drivers/gpu/drm/selftests/Makefile
@@ -1,5 +1,5 @@
test-drm_modeset-y := test-drm_modeset_common.o test-drm_plane_helper.o \
test-drm_format.o test-drm_framebuffer.o \
- test-drm_damage_helper.o
+ test-drm_damage_helper.o test-drm_cmdline_parser.o
obj-$(CONFIG_DRM_DEBUG_SELFTEST) += test-drm_mm.o test-drm_modeset.o
diff --git a/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
new file mode 100644
index ..86afe546fd0e
--- /dev/null
+++ b/drivers/gpu/drm/selftests/drm_cmdline_selftests.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* List each unit test as selftest(function)
+ *
+ * The name is used as both an enum and expanded as igt__name to create
+ * a module parameter. It must be unique and legal for a C identifier.
+ *
+ * Tests are executed in order by igt/drm_mm
+ */
+
+#define cmdline_test(test) selftest(test, test)
+
+cmdline_test(drm_cmdline_test_res)
+cmdline_test(drm_cmdline_test_res_vesa)
+cmdline_test(drm_cmdline_test_res_vesa_rblank)
+cmdline_test(drm_cmdline_test_res_rblank)
+cmdline_test(drm_cmdline_test_res_bpp)
+cmdline_test(drm_cmdline_test_res_refresh)
+cmdline_test(drm_cmdline_test_res_bpp_refresh)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_interlaced)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_margins)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_force_off)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_force_on_off)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_force_on)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_force_on_analog)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_force_on_digital)
+cmdline_test(drm_cmdline_test_res_bpp_refresh_interlaced_margins_force_on)
+cmdline_test(drm_cmdline_test_res_margins_force_on)
+cmdline_test(drm_cmdline_test_res_vesa_margins)
+cmdline_test(drm_cmdline_test_res_invalid_mode)
+cmdline_test(drm_cmdline_test_res_bpp_wrong_place_mode)
+cmdline_test(drm_cmdline_test_name)
+cmdline_test(drm_cmdline_test_name_bpp)
+cmdline_test(drm_cmdline_test_name_refresh)
+cmdline_test(drm_cmdline_test_name_bpp_refresh)
+cmdline_test(drm_cmdline_test_name_refresh_wrong_mode)
+cmdline_test(drm_cmdline_test_name_refresh_invalid_mode)
+cmdline_test(drm_cmdline_test_name_option)
+cmdline_test(drm_cmdline_test_name_bpp_option)
+cmdline_test(drm_cmdline_test_rotate_0)
+cmdline_test(drm_cmdline_test_rotate_90)
+cmdline_test(drm_cmdline_test_rotate_180)
+cmdline_test(drm_cmdline_test_rotate_270)
+cmdline_test(drm_cmdline_test_rotate_invalid_val)
+cmdline_test(drm_cmdline_test_rotate_truncated)
+cmdline_test(drm_cmdline_test_hmirror)
+cmdline_test(drm_cmdline_test_vmirror)
+cmdline_test(drm_cmdline_test_overscan_options)
+cmdline_test(drm_cmdline_test_multiple_options)
+cmdline_test(drm_cmdline_test_invalid_option)
diff --git a/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
new file mode 100644
index ..ae94b076acd4
--- /dev/null
+++ b/drivers/gpu/drm/selftests/test-drm_cmdline_parser.c
@@ -0,0 +1,843 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019 Bootlin
+ */
+
+#define pr_fmt(fmt) "drm_cmdline: " fmt
+
+#include
+#include
+
+#include
+#include
+
+#define TESTS "drm_cmdline_selftests.h"
+#include "drm_selftest.h"
+#include "test-drm_modeset_common.h"
+
+static int drm_cmdline_test_res(void *ignored)
+{
+ struct drm_connector connector = { 0 };
+ struct drm_cmdline_mode mode = { 0 };
+
+ FAIL_ON(!drm_mode_parse_command_line_for_connector("720x480",
+ &connector,
+ &mode));
+ FAIL_ON(!mode.specified);
+ FAIL_ON(mode.xres != 720);
+ FAIL_ON(mode.yres != 480);
+
+ FAIL_ON(mode.refresh_specified);
+
+ FAIL_ON(mode.bpp_specified);
+
+ FAIL_ON(mode.rb);
+ FAIL_ON(mode.cvt);
+ FAIL_ON(mode.interlace);
+ FAIL_ON(mode.margins);
+ FAIL_ON(mode.force != DRM_FORCE_UNSPECIFIED);
+
+ return 0;
+}
+
+static int drm_cmdline_test_res_vesa(void *ignored)
+{
+ struct drm_connector connector = { 0 };
+ stru
Re: [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format
On Mon, Apr 01, 2019 at 08:11:00PM +0100, Robin Murphy wrote:
> With the diff below squashed in to address my outstanding style nits,
>
> Acked-by: Robin Murphy
>
> I don't foresee any conflicting io-pgtable changes to prevent this going via
> DRM, but I'll leave the final say up to Joerg.
No objection from my side with merging this via DRM. With Robin's
concerns addressed:
Acked-by: Joerg Roedel
>
> Thanks,
> Robin.
>
> ->8-
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 98551d0cff59..55ed039da166 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -197,12 +197,13 @@ struct arm_lpae_io_pgtable {
>
> typedef u64 arm_lpae_iopte;
>
> -static inline bool iopte_leaf(arm_lpae_iopte pte, int l, enum
> io_pgtable_fmt fmt)
> +static inline bool iopte_leaf(arm_lpae_iopte pte, int lvl,
> + enum io_pgtable_fmt fmt)
> {
> - if ((l == (ARM_LPAE_MAX_LEVELS - 1)) && (fmt != ARM_MALI_LPAE))
> - return iopte_type(pte,l) == ARM_LPAE_PTE_TYPE_PAGE;
> + if (lvl == (ARM_LPAE_MAX_LEVELS - 1) && fmt != ARM_MALI_LPAE)
> + return iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_PAGE;
>
> - return iopte_type(pte,l) == ARM_LPAE_PTE_TYPE_BLOCK;
> + return iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_BLOCK;
> }
>
> static arm_lpae_iopte paddr_to_iopte(phys_addr_t paddr,
> @@ -310,13 +311,10 @@ static void __arm_lpae_init_pte(struct
> arm_lpae_io_pgtable *data,
> if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_NS)
> pte |= ARM_LPAE_PTE_NS;
>
> - if (lvl == ARM_LPAE_MAX_LEVELS - 1) {
> - if (data->iop.fmt == ARM_MALI_LPAE)
> - pte |= ARM_LPAE_PTE_TYPE_BLOCK;
> - else
> - pte |= ARM_LPAE_PTE_TYPE_PAGE;
> - } else
> + if (data->iop.fmt != ARM_MALI_LPAE && lvl != ARM_LPAE_MAX_LEVELS - 1)
> pte |= ARM_LPAE_PTE_TYPE_BLOCK;
> + else
> + pte |= ARM_LPAE_PTE_TYPE_PAGE;
>
> if (data->iop.fmt != ARM_MALI_LPAE)
> pte |= ARM_LPAE_PTE_AF;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Laurent changed: What|Removed |Added CC||laurentduroi...@gmail.com --- Comment #28 from Laurent --- Created attachment 143938 --> https://bugs.freedesktop.org/attachment.cgi?id=143938&action=edit The class which render stuff with the a per-pixel-linked-list Problem at line 201, glMemoryBarrier doesn't work, n is always equal to zero in the loop while in the second shader. -- 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 drm_fb_xrgb8888_to_rgb888_dstclip()
Den 11.04.2019 06.49, skrev Gerd Hoffmann:
> Oops, the __iomem annotation was added to the header file only.
> Add it to the implementation (and documentation) too.
>
> Fixes: 5c5373b51bec ("drm: switch drm_fb_xrgb_to_rgb888_dstclip to accept
> __iomem dst")
> Signed-off-by: Gerd Hoffmann
> ---
Reviewed-by: Noralf Trønnes
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 --- Comment #29 from Laurent --- Created attachment 143939 --> https://bugs.freedesktop.org/attachment.cgi?id=143939&action=edit The main function. -- 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 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 --- Comment #30 from Laurent --- What do you mean by a test case ? To make the source code easier to read, I put the source code into c++ class. But if you want to have a source code to produce an executable file, just ask. ;) But it'll take more time. The whole source code can be found here : https://github.com/LaurentDuroisin/ODFAEG -- 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 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #37 from Andrey Grodzovsky --- (In reply to mikhail.v.gavrilov from comment #36) > Created attachment 143928 [details] > Demonstration how message "drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to > initialize parser -125!" get a real pain Those messages are actually expected for this particular use case, i might consider switching them to info. I am working on completing review and pushing those patches into our upstream branch. Thanks for testing. -- 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 03/12] drm/i915/fbdev: Move intel_fb_initial_config() to fbdev helper
Den 07.04.2019 18.52, skrev Noralf Trønnes: > It is generic code and having it in the helper will let other drivers > benefit from it. > > One change was necessary assuming this to be true: > INTEL_INFO(dev_priv)->num_pipes == dev->mode_config.num_crtc > > Suggested-by: Daniel Vetter > Cc: Jani Nikula > Cc: Joonas Lahtinen > Cc: Rodrigo Vivi > Cc: intel-...@lists.freedesktop.org > Signed-off-by: Noralf Trønnes > Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/drm_fb_helper.c| 194 - > drivers/gpu/drm/i915/intel_fbdev.c | 218 - > include/drm/drm_fb_helper.h| 23 --- > 3 files changed, 190 insertions(+), 245 deletions(-) > Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tinydrm: Fix fbdev pixel format
Den 10.04.2019 15.03, skrev Neil Armstrong:
> On 10/04/2019 14:43, Noralf Trønnes wrote:
>> Due to copy/paste error, the fbdev format was changed to 32bpp = XRGB
>> which is an emulated format for the RGB565 drivers. Revert to to using the
>> fallback which is dev->mode_config.preferred_depth for the drivers that
>> set it or 32bpp for those that don't (repaper, st7586).
>>
>> Fixes: 3eba3922819f ("drm/tinydrm: Drop using tinydrm_device")
>> Signed-off-by: Noralf Trønnes
>> ---
>> drivers/gpu/drm/tinydrm/hx8357d.c | 2 +-
>> drivers/gpu/drm/tinydrm/ili9225.c | 2 +-
>> drivers/gpu/drm/tinydrm/ili9341.c | 2 +-
>> drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
>> drivers/gpu/drm/tinydrm/repaper.c | 2 +-
>> drivers/gpu/drm/tinydrm/st7586.c | 2 +-
>> drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
>> 7 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/tinydrm/hx8357d.c
>> b/drivers/gpu/drm/tinydrm/hx8357d.c
>> index fab961dded87..5773d0fb6ca1 100644
>> --- a/drivers/gpu/drm/tinydrm/hx8357d.c
>> +++ b/drivers/gpu/drm/tinydrm/hx8357d.c
>> @@ -267,7 +267,7 @@ static int hx8357d_probe(struct spi_device *spi)
>>
>> spi_set_drvdata(spi, drm);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
>> b/drivers/gpu/drm/tinydrm/ili9225.c
>> index e9116ef4b5bc..4b1a587c0134 100644
>> --- a/drivers/gpu/drm/tinydrm/ili9225.c
>> +++ b/drivers/gpu/drm/tinydrm/ili9225.c
>> @@ -433,7 +433,7 @@ static int ili9225_probe(struct spi_device *spi)
>>
>> spi_set_drvdata(spi, drm);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/tinydrm/ili9341.c
>> b/drivers/gpu/drm/tinydrm/ili9341.c
>> index d15f85e837ae..4ade9e4b924f 100644
>> --- a/drivers/gpu/drm/tinydrm/ili9341.c
>> +++ b/drivers/gpu/drm/tinydrm/ili9341.c
>> @@ -229,7 +229,7 @@ static int ili9341_probe(struct spi_device *spi)
>>
>> spi_set_drvdata(spi, drm);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
>> b/drivers/gpu/drm/tinydrm/mi0283qt.c
>> index c6dc31084a4e..8e169846fbd8 100644
>> --- a/drivers/gpu/drm/tinydrm/mi0283qt.c
>> +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
>> @@ -242,7 +242,7 @@ static int mi0283qt_probe(struct spi_device *spi)
>>
>> spi_set_drvdata(spi, drm);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/tinydrm/repaper.c
>> b/drivers/gpu/drm/tinydrm/repaper.c
>> index a29b8278324b..370629e2de94 100644
>> --- a/drivers/gpu/drm/tinydrm/repaper.c
>> +++ b/drivers/gpu/drm/tinydrm/repaper.c
>> @@ -1131,7 +1131,7 @@ static int repaper_probe(struct spi_device *spi)
>>
>> DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/tinydrm/st7586.c
>> b/drivers/gpu/drm/tinydrm/st7586.c
>> index 560d7ac0cadc..36bb16a15f7e 100644
>> --- a/drivers/gpu/drm/tinydrm/st7586.c
>> +++ b/drivers/gpu/drm/tinydrm/st7586.c
>> @@ -408,7 +408,7 @@ static int st7586_probe(struct spi_device *spi)
>> DRM_DEBUG_KMS("preferred_depth=%u, rotation = %u\n",
>>drm->mode_config.preferred_depth, rotation);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>> diff --git a/drivers/gpu/drm/tinydrm/st7735r.c
>> b/drivers/gpu/drm/tinydrm/st7735r.c
>> index 022e9849b95b..ce9109e613e0 100644
>> --- a/drivers/gpu/drm/tinydrm/st7735r.c
>> +++ b/drivers/gpu/drm/tinydrm/st7735r.c
>> @@ -207,7 +207,7 @@ static int st7735r_probe(struct spi_device *spi)
>>
>> spi_set_drvdata(spi, drm);
>>
>> -drm_fbdev_generic_setup(drm, 32);
>> +drm_fbdev_generic_setup(drm, 0);
>>
>> return 0;
>> }
>>
>
> Reviewed-by: Neil Armstrong
>
Thanks, applied.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 0/2] drm: Add detection of changing of edid on between suspend and resume
This patch series fix missed detection of changing of edid on between suspend and resume. First patch fixes drm_helper_hdp_irq_event() in order to fix a below use case. Following scenario requires detection of changing of edid. 1) plug display device to a connector 2) system suspend 3) unplug 1)'s display device and plug the other display device to a connector 4) system resume It adds edid check routine when a connector status still remains as "connector_status_connected". Second patch adds a missed update of edid property of drm connector on i915. v2: Add NULL check before comparing of EDIDs. v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan, Mika) v4: Rebased v5: Use a cached edid property blob data of connector instead of adding a new detected_edid variable. (Maarten) Add an using of reference count for getting a cached edid property blob data. (Maarten) Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate Testcase: igt/kms_chamelium/dp-edid-change-during-suspend v1, v2: https://patchwork.freedesktop.org/series/47680/ v3: https://patchwork.freedesktop.org/series/49298/ v4: https://patchwork.freedesktop.org/series/57397/ Gwan-gyeong Mun (2): drm: Add detection of changing of edid on between suspend and resume drm/i915: Add a missed update of edid property of drm connector drivers/gpu/drm/drm_probe_helper.c | 34 +- drivers/gpu/drm/i915/intel_dp.c| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 1 + 3 files changed, 35 insertions(+), 1 deletion(-) -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/2] drm: Add detection of changing of edid on between suspend and resume
The hotplug detection routine of drm_helper_hpd_irq_event() can detect
changing of status of connector, but it can not detect changing of edid.
Following scenario requires detection of changing of edid.
1) plug display device to a connector
2) system suspend
3) unplug 1)'s display device and plug the other display device to a
connector
4) system resume
It adds edid check routine when a connector status still remains as
"connector_status_connected".
v2: Add NULL check before comparing of EDIDs.
v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan, Mika)
v4: Rebased
v5: Use a cached edid property blob data of connector instead of adding
a new detected_edid variable. (Maarten)
Add an using of reference count for getting a cached edid property
blob data. (Maarten)
Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
Signed-off-by: Gwan-gyeong Mun
---
drivers/gpu/drm/drm_probe_helper.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 6fd08e04b323..27ad7f3dabb7 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -742,7 +742,16 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
* panels.
*
* This helper function is useful for drivers which can't or don't track
hotplug
- * interrupts for each connector.
+ * interrupts for each connector. And it also supports a detection of changing
+ * of edid on between suspend and resume when a connector status still remains
+ * as "connector_status_connected".
+ *
+ * Following scenario requires detection of changing of edid.
+ * 1) plug display device to a connector
+ * 2) system suspend
+ * 3) unplug 1)'s display device and plug the other display device to a
+ * connector
+ * 4) system resume
*
* Drivers which support hotplug interrupts for each connector individually and
* which have a more fine-grained detect logic should bypass this code and
@@ -760,6 +769,7 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
enum drm_connector_status old_status;
+ struct drm_property_blob *old_edid_blob_ptr;
bool changed = false;
if (!dev->mode_config.poll_enabled)
@@ -774,6 +784,11 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
old_status = connector->status;
+ if (connector->edid_blob_ptr)
+ old_edid_blob_ptr =
drm_property_blob_get(connector->edid_blob_ptr);
+ else
+ old_edid_blob_ptr = NULL;
+
connector->status = drm_helper_probe_detect(connector, NULL,
false);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to
%s\n",
connector->base.id,
@@ -782,6 +797,23 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
drm_get_connector_status_name(connector->status));
if (old_status != connector->status)
changed = true;
+
+ /* Check changing of edid when a connector status still remains
+* as "connector_status_connected".
+*/
+ if (old_edid_blob_ptr && connector->edid_blob_ptr &&
+ old_status == connector->status &&
+ old_status == connector_status_connected) {
+ if (memcmp(old_edid_blob_ptr->data,
+ connector->edid_blob_ptr->data,
+ old_edid_blob_ptr->length)) {
+ changed = true;
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] edid
updated\n",
+ connector->base.id,
+ connector->name);
+ }
+ }
+ drm_property_blob_put(old_edid_blob_ptr);
}
drm_connector_list_iter_end(&conn_iter);
mutex_unlock(&dev->mode_config.mutex);
--
2.21.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/2] drm/i915: Add a missed update of edid property of drm connector
After suspend/resume process, hotplug detection is handled by i915_hpd_poll_init_work() workqueue. While intel_hdmi_detect() or intel_dp_detect() are called, intel_hdmi_set_edid() or intel_dp_set_edid() only update an internal detect_edid variable of intel_connector. A missed update of edid property of drm_connector leads incorrect behavior of drm_helper_hpd_irq_event() on below testcases. It adds a missed update of edid property of drm connector and updates drm edid modes, while i915_hpd_poll_init_work() workqueue works. Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate Testcase: igt/kms_chamelium/dp-edid-change-during-suspend Signed-off-by: Gwan-gyeong Mun --- drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/i915/intel_hdmi.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index c4e36759a756..0301e58495b4 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5379,6 +5379,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp) intel_dp->has_audio = drm_detect_monitor_audio(edid); drm_dp_cec_set_edid(&intel_dp->aux, edid); + intel_connector_update_modes(&intel_connector->base, edid); } static void diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index e1005d7b75fd..b53360c4d0ef 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -2493,6 +2493,7 @@ intel_hdmi_set_edid(struct drm_connector *connector) } cec_notifier_set_phys_addr_from_edid(intel_hdmi->cec_notifier, edid); + intel_connector_update_modes(connector, edid); return connected; } -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 7/8] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2
On Wed, Apr 10, 2019 at 04:41:57PM -0700, Ira Weiny wrote:
> On Tue, Mar 26, 2019 at 12:47:46PM -0400, Jerome Glisse wrote:
> > From: Jérôme Glisse
> >
> > CPU page table update can happens for many reasons, not only as a result
> > of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
> > as a result of kernel activities (memory compression, reclaim, migration,
> > ...).
> >
> > Users of mmu notifier API track changes to the CPU page table and take
> > specific action for them. While current API only provide range of virtual
> > address affected by the change, not why the changes is happening
> >
> > This patch is just passing down the new informations by adding it to the
> > mmu_notifier_range structure.
> >
> > Changes since v1:
> > - Initialize flags field from mmu_notifier_range_init() arguments
> >
> > Signed-off-by: Jérôme Glisse
> > Cc: Andrew Morton
> > Cc: linux...@kvack.org
> > Cc: Christian König
> > Cc: Joonas Lahtinen
> > Cc: Jani Nikula
> > Cc: Rodrigo Vivi
> > Cc: Jan Kara
> > Cc: Andrea Arcangeli
> > Cc: Peter Xu
> > Cc: Felix Kuehling
> > Cc: Jason Gunthorpe
> > Cc: Ross Zwisler
> > Cc: Dan Williams
> > Cc: Paolo Bonzini
> > Cc: Radim Krčmář
> > Cc: Michal Hocko
> > Cc: Christian Koenig
> > Cc: Ralph Campbell
> > Cc: John Hubbard
> > Cc: k...@vger.kernel.org
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-r...@vger.kernel.org
> > Cc: Arnd Bergmann
> > ---
> > include/linux/mmu_notifier.h | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/mmu_notifier.h b/include/linux/mmu_notifier.h
> > index 62f94cd85455..0379956fff23 100644
> > --- a/include/linux/mmu_notifier.h
> > +++ b/include/linux/mmu_notifier.h
> > @@ -58,10 +58,12 @@ struct mmu_notifier_mm {
> > #define MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
> >
> > struct mmu_notifier_range {
> > + struct vm_area_struct *vma;
> > struct mm_struct *mm;
> > unsigned long start;
> > unsigned long end;
> > unsigned flags;
> > + enum mmu_notifier_event event;
> > };
> >
> > struct mmu_notifier_ops {
> > @@ -363,10 +365,12 @@ static inline void mmu_notifier_range_init(struct
> > mmu_notifier_range *range,
> >unsigned long start,
> >unsigned long end)
> > {
> > + range->vma = vma;
> > + range->event = event;
> > range->mm = mm;
> > range->start = start;
> > range->end = end;
> > - range->flags = 0;
> > + range->flags = flags;
>
> Which of the "user patch sets" uses the new flags?
>
> I'm not seeing that user yet. In general I don't see anything wrong with the
> series and I like the idea of telling drivers why the invalidate has fired.
>
> But is the flags a future feature?
>
I believe the link were in the cover:
https://lkml.org/lkml/2019/1/23/833
https://lkml.org/lkml/2019/1/23/834
https://lkml.org/lkml/2019/1/23/832
https://lkml.org/lkml/2019/1/23/831
I have more coming for HMM but i am waiting after 5.2 once amdgpu
HMM patch are merge upstream as it will change what is passed down
to driver and it would conflict with non merged HMM driver (like
amdgpu today).
Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #38 from Michel Dänzer --- (In reply to Andrey Grodzovsky from comment #37) > Those messages are actually expected for this particular use case, i might > consider switching them to info. I'd argue they should be debug, so they don't spam dmesg by default. -- 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 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #39 from mikhail.v.gavri...@gmail.com --- (In reply to Michel Dänzer from comment #38) > > I'd argue they should be debug, so they don't spam dmesg by default. Let this messages stay in kernel log (dmesg), but I don't want see they when I enter any command in terminal. They makes the process entering commands in terminal very annoying. -- 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 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229
--- Comment #31 from Laurent ---
Okey, I've found a temporary solution : putting instructions in the second
fragment shader to slow down the shader execution code and it works...
const std::string fragmentShader2 =
R"(
#version 140
#extension GL_ARB_shader_atomic_counters : require
#extension GL_ARB_shading_language_420pack : require
#extension GL_ARB_shader_image_load_store : require
#extension GL_ARB_shader_storage_buffer_object : require
#define MAX_FRAGMENTS 75
struct NodeType {
vec4 color;
float depth;
uint next;
};
layout(binding = 0, r32ui) coherent uniform uimage2D
headPointers;
layout(binding = 0, std430) coherent buffer linkedLists {
NodeType nodes[];
};
void main() {
NodeType frags[MAX_FRAGMENTS];
NodeType frags2[MAX_FRAGMENTS];
int count = 0;
uint n = imageLoad(headPointers, ivec2(gl_FragCoord.xy)).r;
while( n != 0u && count < MAX_FRAGMENTS) {
frags[count] = nodes[n];
frags2[count] = frags[count];
n = nodes[n].next;
imageStore(headPointers, ivec2(gl_FragCoord.xy),
uvec4(n, 0, 0, 0));
count++;
}
//merge sort
int i, j1, j2, k;
int a, b, c;
int step = 1;
NodeType leftArray[MAX_FRAGMENTS/2]; //for merge sort
while (step <= count)
{
i = 0;
while (i < count - step)
{
//merge(step, i, i + step, min(i + step + step,
count));
a = i;
b = i + step;
c = (i + step + step) >= count ? count : (i + step +
step);
for (k = 0; k < step; k++)
leftArray[k] = frags[a + k];
j1 = 0;
j2 = 0;
for (k = a; k < c; k++)
{
if (b + j1 >= c || (j2 < step &&
leftArray[j2].depth > frags[b + j1].depth))
frags[k] = leftArray[j2++];
else
frags[k] = frags[b + j1++];
}
i += 2 * step;
}
step *= 2;
}
vec4 color = vec4(0, 0, 0, 0);
for( int i = 0; i < count; i++ )
{
color = mix( color, frags[i].color, frags[i].color.a);
if (frags2[i].color.r > 1 || frags2[i].color.g > 1 ||
frags2[i].color.b > 1)
color = vec4(1, 1, 1, 1);
}
gl_FragColor = color;
})";
First I had to affect n whith nodes[n] instead of frags[count], I don't
understand why.
Secondly I have to make another array and adding a if in the last loop (for)
when I mix colors, otherwise, I have a black screen
--
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] video: amba-clcd: Decomission Versatile and Nomadik
On 03/20/2019 10:33 AM, Linus Walleij wrote: > These board families are now handled in the DRM subsystem > where we can have reusable panel drivers and some other > stuff. The PL111 there is now the driver used in the > defconfig for Versatile and Nomadik so no need to keep > this code around. > > There are a few minor machines in arch/arm/ such as > mach-netx still using the old driver, so we need to keep > the core fbdev driver around for some time. > > Cc: Russell King > Cc: Bartlomiej Zolnierkiewicz > Signed-off-by: Linus Walleij Patch queued for v5.2, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-misc-fixes
Hi Dave, Daniel, Here is a new drm-misc-fixes PR. thanks! maxime drm-misc-fixes-2019-04-11: - core: Make atomic_enable and disable optional for CRTC - dw-hdmi: Lower max frequency for the Allwinner H6, SCDC configuration improvements for older controller versions - omap: a fix for the CEC clock management policy The following changes since commit 9b39b013037fbfa8d4b999345d9e904d8a336fc2: drm/udl: add a release method and delay modeset teardown (2019-04-08 16:20:02 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2019-04-11 for you to fetch changes up to 1a07a94b47b1f528f39c3e6187b5eaf02efe44ea: drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind (2019-04-08 10:30:23 +0200) - core: Make atomic_enable and disable optional for CRTC - dw-hdmi: Lower max frequency for the Allwinner H6, SCDC configuration improvements for older controller versions - omap: a fix for the CEC clock management policy Jernej Skrabec (1): drm/sun4i: DW HDMI: Lower max. supported rate for H6 Matteo Croce (1): drm/omap: fix typo Maxime Ripard (1): Merge drm/drm-fixes into drm-misc-fixes Neil Armstrong (2): drm/bridge: dw-hdmi: disable SCDC configuration for invalid setups Revert "Documentation/gpu/meson: Remove link to meson_canvas.c" Ondrej Jirman (1): drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind Rodrigo Siqueira (1): drm/atomic-helper: Make atomic_enable/disable crtc callbacks optional Sean Paul (1): Documentation/gpu/meson: Remove link to meson_canvas.c Tony Lindgren (1): drm/omap: hdmi4_cec: Fix CEC clock handling for PM drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 34 +++ drivers/gpu/drm/drm_atomic_helper.c | 5 ++--- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 26 --- drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 2 +- drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 9 ++-- drivers/gpu/drm/sun4i/sun8i_tcon_top.c| 5 +++-- include/drm/drm_modeset_helper_vtables.h | 4 7 files changed, 66 insertions(+), 19 deletions(-) -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v6 7/8] mm/mmu_notifier: pass down vma and reasons why mmu notifier is happening v2
> On Wed, Apr 10, 2019 at 04:41:57PM -0700, Ira Weiny wrote:
> > On Tue, Mar 26, 2019 at 12:47:46PM -0400, Jerome Glisse wrote:
> > > From: Jérôme Glisse
> > >
> > > CPU page table update can happens for many reasons, not only as a
> > > result of a syscall (munmap(), mprotect(), mremap(), madvise(), ...)
> > > but also as a result of kernel activities (memory compression,
> > > reclaim, migration, ...).
> > >
> > > Users of mmu notifier API track changes to the CPU page table and
> > > take specific action for them. While current API only provide range
> > > of virtual address affected by the change, not why the changes is
> > > happening
> > >
> > > This patch is just passing down the new informations by adding it to
> > > the mmu_notifier_range structure.
> > >
> > > Changes since v1:
> > > - Initialize flags field from mmu_notifier_range_init()
> > > arguments
> > >
> > > Signed-off-by: Jérôme Glisse
> > > Cc: Andrew Morton
> > > Cc: linux...@kvack.org
> > > Cc: Christian König
> > > Cc: Joonas Lahtinen
> > > Cc: Jani Nikula
> > > Cc: Rodrigo Vivi
> > > Cc: Jan Kara
> > > Cc: Andrea Arcangeli
> > > Cc: Peter Xu
> > > Cc: Felix Kuehling
> > > Cc: Jason Gunthorpe
> > > Cc: Ross Zwisler
> > > Cc: Dan Williams
> > > Cc: Paolo Bonzini
> > > Cc: Radim Krčmář
> > > Cc: Michal Hocko
> > > Cc: Christian Koenig
> > > Cc: Ralph Campbell
> > > Cc: John Hubbard
> > > Cc: k...@vger.kernel.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-r...@vger.kernel.org
> > > Cc: Arnd Bergmann
> > > ---
> > > include/linux/mmu_notifier.h | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/mmu_notifier.h
> > > b/include/linux/mmu_notifier.h index 62f94cd85455..0379956fff23
> > > 100644
> > > --- a/include/linux/mmu_notifier.h
> > > +++ b/include/linux/mmu_notifier.h
> > > @@ -58,10 +58,12 @@ struct mmu_notifier_mm { #define
> > > MMU_NOTIFIER_RANGE_BLOCKABLE (1 << 0)
> > >
> > > struct mmu_notifier_range {
> > > + struct vm_area_struct *vma;
> > > struct mm_struct *mm;
> > > unsigned long start;
> > > unsigned long end;
> > > unsigned flags;
> > > + enum mmu_notifier_event event;
> > > };
> > >
> > > struct mmu_notifier_ops {
> > > @@ -363,10 +365,12 @@ static inline void
> mmu_notifier_range_init (struct mmu_notifier_range *range,
> > > unsigned long start,
> > > unsigned long end)
> > > {
> > > + range->vma = vma;
> > > + range->event = event;
> > > range->mm = mm;
> > > range->start = start;
> > > range->end = end;
> > > - range->flags = 0;
> > > + range->flags = flags;
> >
> > Which of the "user patch sets" uses the new flags?
> >
> > I'm not seeing that user yet. In general I don't see anything wrong
> > with the series and I like the idea of telling drivers why the invalidate
> > has
> fired.
> >
> > But is the flags a future feature?
> >
>
> I believe the link were in the cover:
>
> https://lkml.org/lkml/2019/1/23/833
> https://lkml.org/lkml/2019/1/23/834
> https://lkml.org/lkml/2019/1/23/832
> https://lkml.org/lkml/2019/1/23/831
>
> I have more coming for HMM but i am waiting after 5.2 once amdgpu HMM
> patch are merge upstream as it will change what is passed down to driver
> and it would conflict with non merged HMM driver (like amdgpu today).
>
Unfortunately this does not answer my question. Yes I saw the links to the
patches which use this in the header. Furthermore, I checked the links again,
I still do not see a use of range->flags nor a use of the new flags parameter
to mmu_notifier_range_init().
I still gave a reviewed by because I'm not saying it is wrong I'm just trying
to understand what use drivers have of this flag.
So again I'm curious what is the use case of these flags and the use case of
exposing it to the users of MMU notifiers?
Ira
> Cheers,
> Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110360] AMD system hits AMD-Vi: Completion-Wait loop timed out on Acer Squirtle_SR laptop
https://bugs.freedesktop.org/show_bug.cgi?id=110360 --- Comment #5 from Alex Deucher --- Please attach the output of lspci -vnn -- 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 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
On Thu, Apr 11, 2019 at 05:23:25PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 11. april 2019 ob 17:20:04 CEST je Clément Péron napisal(a):
> > Hi,
> >
> > On Thu, 11 Apr 2019 at 17:05, Jernej Škrabec
> wrote:
> > > Dne četrtek, 11. april 2019 ob 12:57:16 CEST je Clément Péron napisal(a):
> > > > Add the mali gpu node to the H6 device-tree.
> > > >
> > > > Signed-off-by: Clément Péron
> > > > ---
> > > >
> > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 ++
> > > > 1 file changed, 14 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
> > > > e0dc4a05c1ba..196753110434 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > @@ -157,6 +157,20 @@
> > > >
> > > > allwinner,sram = <&ve_sram 1>;
> > > >
> > > > };
> > > >
> > > > + gpu: gpu@180 {
> > > > + compatible = "allwinner,sun50i-h6-mali",
> > > > + "arm,mali-t720";
> > > > + reg = <0x0180 0x4000>;
> > > > + interrupts = > >
> > > IRQ_TYPE_LEVEL_HIGH>,
> > >
> > > > + > >
> > > IRQ_TYPE_LEVEL_HIGH>,
> > >
> > > > + > >
> > > IRQ_TYPE_LEVEL_HIGH>;
> > >
> > > > + interrupt-names = "job", "mmu", "gpu";
> > > > + clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
> > > > + clock-names = "core", "bus";
> > > > + resets = <&ccu RST_BUS_GPU>;
> > > > + status = "disabled";
> > >
> > > Usually self sufficient peripherals are enabled by default in DTSI.
> >
> > I follow the other Mali Midgard (rk3399, rk3288) syntax.
> > But I think you're right here, will go for an update I think.
>
> I quickly checked A64 and H5 DTSI and both have GPU enabled by default (status
> property is not set).
I asked myself the same question, but the H6 seems to have a supply
wired to the GPU, while the H3 and H5 do not. So I'm not sure we want
to enable it on all the boards, even though some might have left out
the GPU supply which will result in a non-working GPU (I assume?)
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Laurent changed: What|Removed |Added Status|NEEDINFO|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
Re: [PATCH] gpu: host1x: fix compile error when IOMMU API is not available
On Thu, Apr 11, 2019 at 02:31:48PM +0300, Dmitry Osipenko wrote:
> 11.04.2019 13:06, Mikko Perttunen пишет:
> > On 11.4.2019 11.30, Thierry Reding wrote:
> >> On Thu, Apr 11, 2019 at 09:23:13AM +0100, Ben Dooks wrote:
> >>>
> >>>
> >>> On 2019-04-10 23:47, Stefan Agner wrote:
> In case the IOMMU API is not available compiling host1x fails with
> the following error:
> In file included from drivers/gpu/host1x/hw/host1x06.c:27:
> drivers/gpu/host1x/hw/channel_hw.c: In function
> ‘host1x_channel_set_streamid’:
> drivers/gpu/host1x/hw/channel_hw.c:118:30: error: implicit
> declaration of function
> ‘dev_iommu_fwspec_get’; did you mean ‘iommu_fwspec_free’?
> [-Werror=implicit-function-declaration]
> struct iommu_fwspec *spec =
> dev_iommu_fwspec_get(channel->dev->parent);
> ^~~~
> iommu_fwspec_free
>
> Fixes: de5469c21ff9 ("gpu: host1x: Program the channel stream ID")
> Signed-off-by: Stefan Agner
> >>>
> >>> would it be better to provide something like this i nthe header that
> >>> defines dev_iommu_fwspec_get() to be:
> >>>
> >>> static inline struct iommu_fwspec *dev_iommu_fwspec_get(struct device
> >>> *dev)
> >>> { return NULL; }
> >>>
> >>> although returning an PTR_ERR would have been better.
> >>
> >> I don't think there's really a large number of failures here. Either
> >> your device has an IOMMU fwspec or it doesn't.
> >>
> >> But yes, I think it'd be better to have the above static inline dummy in
> >> iommu.h, but I'll apply this for now in the hopes of getting it in
> >> before v5.1 final.
> >
> > A similar patch was already sent before by someone. That one also programs
> > the bypass stream ID (0x7f) even if IOMMU is disabled. We should pick that
> > patch instead.
>
> For the record.. here is that patch
> https://patchwork.ozlabs.org/patch/1052364/
Ugh... too late. I'll apply Arnd's patch on top of this one.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110229] glMemoryBarrier doesn't work.
https://bugs.freedesktop.org/show_bug.cgi?id=110229 Andre Klapper changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #32 from Andre Klapper --- Closing as invalid as nothing was fixed in Mesa code and as this issue tracker is not a support desk to go through hundreds of lines of external random code. -- 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 -next] video: fbdev: remove set but not used variable 'size'
On 03/30/2019 03:26 AM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/video/fbdev/pvr2fb.c: In function 'pvr2fb_init':
> drivers/video/fbdev/pvr2fb.c:1074:6: warning:
> variable 'size' set but not used [-Wunused-but-set-variable]
>
> It's not used since commit 9cd1c6743454 ("pvr2fb: Fix oops when
> pseudo_palette is written")
>
> Signed-off-by: YueHaibing
Patch queued for v5.2 with minor change in the patch summary
("video: fbdev: pvr2fb: remove set but not used variable 'size'"),
thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
On Thu, Apr 11, 2019 at 05:42:56PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 11. april 2019 ob 17:27:52 CEST je Maxime Ripard napisal(a):
> > On Thu, Apr 11, 2019 at 05:23:25PM +0200, Jernej Škrabec wrote:
> > > Dne četrtek, 11. april 2019 ob 17:20:04 CEST je Clément Péron napisal(a):
> > > > Hi,
> > > >
> > > > On Thu, 11 Apr 2019 at 17:05, Jernej Škrabec
> > >
> > > wrote:
> > > > > Dne četrtek, 11. april 2019 ob 12:57:16 CEST je Clément Péron
> napisal(a):
> > > > > > Add the mali gpu node to the H6 device-tree.
> > > > > >
> > > > > > Signed-off-by: Clément Péron
> > > > > > ---
> > > > > >
> > > > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 ++
> > > > > > 1 file changed, 14 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
> > > > > > e0dc4a05c1ba..196753110434 100644
> > > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > > > @@ -157,6 +157,20 @@
> > > > > >
> > > > > > allwinner,sram = <&ve_sram 1>;
> > > > > >
> > > > > > };
> > > > > >
> > > > > > + gpu: gpu@180 {
> > > > > > + compatible = "allwinner,sun50i-h6-mali",
> > > > > > + "arm,mali-t720";
> > > > > > + reg = <0x0180 0x4000>;
> > > > > > + interrupts = > > > >
> > > > > IRQ_TYPE_LEVEL_HIGH>,
> > > > >
> > > > > > + > > > >
> > > > > IRQ_TYPE_LEVEL_HIGH>,
> > > > >
> > > > > > + > > > >
> > > > > IRQ_TYPE_LEVEL_HIGH>;
> > > > >
> > > > > > + interrupt-names = "job", "mmu", "gpu";
> > > > > > + clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
> > > > > > + clock-names = "core", "bus";
> > > > > > + resets = <&ccu RST_BUS_GPU>;
> > > > > > + status = "disabled";
> > > > >
> > > > > Usually self sufficient peripherals are enabled by default in DTSI.
> > > >
> > > > I follow the other Mali Midgard (rk3399, rk3288) syntax.
> > > > But I think you're right here, will go for an update I think.
> > >
> > > I quickly checked A64 and H5 DTSI and both have GPU enabled by default
> > > (status property is not set).
> >
> > I asked myself the same question, but the H6 seems to have a supply
> > wired to the GPU, while the H3 and H5 do not. So I'm not sure we want
> > to enable it on all the boards, even though some might have left out
> > the GPU supply which will result in a non-working GPU (I assume?)
>
> It's true that GPU doesn't work at all without power supply. Even worse, ARM
> kernel driver just hangs whole SoC if it tries to use unpowered GPU.
>
> I checked few datasheets and almost none of them have GPU power supply, except
> H5, where GPU is enabled by default in DTSI.
I guess we should fix that then.
> Yeah, I guess it's more safe to explicitly enable it in board DT.
It's also something we do for the CPU, even though the CPU should be
obviously be powered before starting Linux...
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support
Hi,
On Thu, Apr 11, 2019 at 09:38:06AM +0200, Hans Verkuil wrote:
> >> @@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
> >>.has_alpha = true,
> >>}, {
> >>.drm_fmt = DRM_FORMAT_RGB565,
> >> + .v4l2_fmt = V4L2_PIX_FMT_RGB565,
> >
> > -> V4L2_PIX_FMT_RGB565X
> >
> > Was added later, as what you expect is not compatible.
>
> All these 16-bit V4L2 pixelformats are ancient, but they are (to my knowledge)
> correct w.r.t. the documented layout of the bits in memory. I.e., that's what
> the hardware will give you.
>
> I think if there is no equivalence between the drm and v4l2 fourcc's, then
> you need two entries in this table, one for drm (v4l2_fmt == 0), one for v4l2
> (drm_fmt == 0).
Yeah, that was my plan. I'd definitely expect some formats in V4L2
while not supported by DRM, or the other way around.
> >> @@ -473,6 +496,7 @@ static const struct image_format_info formats[] = {
> >>.is_yuv = true,
> >>}, {
> >>.drm_fmt = DRM_FORMAT_NV24,
> >> + .v4l2_fmt = V4L2_PIX_FMT_NV24,
> >
> > For extra fun, the M variant has not been added yet.
>
> Note that it has been the practice in V4L2 to avoid adding pixelformats unless
> they are in use by a V4L2 driver. So that's why some combinations do not
> exist.
>
> If we are creating a common library then I think we should change that rule
> to: "unless they are in use by a DRM or V4L2 driver". And when new formats are
> added, and they exists already for DRM or V4L2, then we should use the same
> fourcc for the other subsystem.
>
> I.e. if pixelformat V4L2_PIX_FMT_FOO was already defined, then add a:
>
> #define DRM_FORMAT_FOO V4L2_PIX_FMT_FOO
>
> rather than creating a new fourcc.
That makes sense
> We could even start looking at redoing the whole scheme in a unified way, but
> that's something for the (far) future.
Yeah, my secret plan is to have eventually a single fourcc (or even
#define) for both DRM and v4l2 for any new format. But don't tell
anyone :)
> This is already a big step forward.
Great, I'll respin this then.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] drm: Add detection of changing of edid on between suspend and resume
On Thu, 2019-04-11 at 17:36 +0300, Gwan-gyeong Mun wrote:
> The hotplug detection routine of drm_helper_hpd_irq_event() can
> detect
> changing of status of connector, but it can not detect changing of
> edid.
>
> Following scenario requires detection of changing of edid.
>
> 1) plug display device to a connector
> 2) system suspend
> 3) unplug 1)'s display device and plug the other display device to a
> connector
> 4) system resume
>
> It adds edid check routine when a connector status still remains as
> "connector_status_connected".
>
> v2: Add NULL check before comparing of EDIDs.
> v3: Make it as part of existing drm_helper_hpd_irq_event() (Stan,
> Mika)
> v4: Rebased
> v5: Use a cached edid property blob data of connector instead of
> adding
> a new detected_edid variable. (Maarten)
> Add an using of reference count for getting a cached edid
> property
> blob data. (Maarten)
>
> Testcase: igt/kms_chamelium/hdmi-edid-change-during-hibernate
> Testcase: igt/kms_chamelium/hdmi-edid-change-during-suspend
> Testcase: igt/kms_chamelium/dp-edid-change-during-hibernate
> Testcase: igt/kms_chamelium/dp-edid-change-during-suspend
>
> Signed-off-by: Gwan-gyeong Mun
> ---
> drivers/gpu/drm/drm_probe_helper.c | 34
> +-
> 1 file changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 6fd08e04b323..27ad7f3dabb7 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -742,7 +742,16 @@ EXPORT_SYMBOL(drm_kms_helper_poll_fini);
> * panels.
> *
> * This helper function is useful for drivers which can't or don't
> track hotplug
> - * interrupts for each connector.
> + * interrupts for each connector. And it also supports a detection
> of changing
> + * of edid on between suspend and resume when a connector status
> still remains
> + * as "connector_status_connected".
> + *
> + * Following scenario requires detection of changing of edid.
> + * 1) plug display device to a connector
> + * 2) system suspend
> + * 3) unplug 1)'s display device and plug the other display device
> to a
> + * connector
> + * 4) system resume
> *
> * Drivers which support hotplug interrupts for each connector
> individually and
> * which have a more fine-grained detect logic should bypass this
> code and
> @@ -760,6 +769,7 @@ bool drm_helper_hpd_irq_event(struct drm_device
> *dev)
> struct drm_connector *connector;
> struct drm_connector_list_iter conn_iter;
> enum drm_connector_status old_status;
> + struct drm_property_blob *old_edid_blob_ptr;
> bool changed = false;
>
> if (!dev->mode_config.poll_enabled)
> @@ -774,6 +784,11 @@ bool drm_helper_hpd_irq_event(struct drm_device
> *dev)
>
> old_status = connector->status;
>
> + if (connector->edid_blob_ptr)
> + old_edid_blob_ptr =
> drm_property_blob_get(connector->edid_blob_ptr);
> + else
> + old_edid_blob_ptr = NULL;
> +
> connector->status = drm_helper_probe_detect(connector,
> NULL, false);
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s
> to %s\n",
> connector->base.id,
> @@ -782,6 +797,23 @@ bool drm_helper_hpd_irq_event(struct drm_device
> *dev)
> drm_get_connector_status_name(connector-
> >status));
> if (old_status != connector->status)
> changed = true;
> +
> + /* Check changing of edid when a connector status still
> remains
> + * as "connector_status_connected".
> + */
> + if (old_edid_blob_ptr && connector->edid_blob_ptr &&
I guess you don't need to check both old_edid_blob_ptr && connector-
>edid_blob_ptr here. Because if old_edid_blob_ptr is not NULL - it
means that connector->edid_blob_ptr was not NULL for sure. See the
condition you have added above.
I mean this one:
> + if (connector->edid_blob_ptr)
> + old_edid_blob_ptr =
> drm_property_blob_get(connector->edid_blob_ptr);
> + else
> + old_edid_blob_ptr = NULL;
So I would check only old_edid_blob_ptr for not being NULL here.
> + old_status == connector->status &&
> + old_status == connector_status_connected) {
> + if (memcmp(old_edid_blob_ptr->data,
> + connector->edid_blob_ptr->data,
> + old_edid_blob_ptr->length)) {
> + changed = true;
> + DRM_DEBUG_KMS("[CONNECTOR:%d:%s] edid
> updated\n",
> + connector->base.id,
> + connector->name);
> + }
> + }
> + drm_property_blob_put(old_edi
[PATCH 2/4] drm/sched: Keep s_fence->parent pointer
For later driver's reference to see if the fence is signaled.
v2: Move parent fence put to resubmit jobs.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 05a4540..89d1f1b 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -368,8 +368,6 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
if (s_job->s_fence->parent &&
dma_fence_remove_callback(s_job->s_fence->parent,
&s_job->cb)) {
- dma_fence_put(s_job->s_fence->parent);
- s_job->s_fence->parent = NULL;
atomic_dec(&sched->hw_rq_count);
} else {
/*
@@ -396,6 +394,14 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched,
struct drm_sched_job *bad)
sched->ops->free_job(s_job);
}
}
+
+ /*
+* Stop pending timer in flight as we rearm it in drm_sched_start. This
+* avoids the pending timeout work in progress to fire right away after
+* this TDR finished and before the newly restarted jobs had a
+* chance to complete.
+*/
+ cancel_delayed_work(&sched->work_tdr);
}
EXPORT_SYMBOL(drm_sched_stop);
@@ -467,6 +473,7 @@ void drm_sched_resubmit_jobs(struct drm_gpu_scheduler
*sched)
if (found_guilty && s_job->s_fence->scheduled.context ==
guilty_context)
dma_fence_set_error(&s_fence->finished, -ECANCELED);
+ dma_fence_put(s_job->s_fence->parent);
s_job->s_fence->parent = sched->ops->run_job(s_job);
atomic_inc(&sched->hw_rq_count);
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/amd/display: Restore deleted patch to resolve reset deadlock.
Patch '5edb0c9b Fix deadlock with display during hanged ring recovery'
was accidentaly removed during one of DALs code merges.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0648794..27e0383 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5138,14 +5138,21 @@ static void amdgpu_dm_commit_planes(struct
drm_atomic_state *state,
*/
abo = gem_to_amdgpu_bo(fb->obj[0]);
r = amdgpu_bo_reserve(abo, true);
- if (unlikely(r != 0)) {
+ if (unlikely(r != 0))
DRM_ERROR("failed to reserve buffer before flip\n");
- WARN_ON(1);
- }
- /* Wait for all fences on this FB */
- WARN_ON(reservation_object_wait_timeout_rcu(abo->tbo.resv,
true, false,
-
MAX_SCHEDULE_TIMEOUT) < 0);
+ /*
+* Wait for all fences on this FB. Do limited wait to avoid
+* deadlock during GPU reset when this fence will not signal
+* but we hold reservation lock for the BO.
+*/
+ r = reservation_object_wait_timeout_rcu(abo->tbo.resv,
+ true, false,
+ msecs_to_jiffies(5000));
+ if (unlikely(r == 0))
+ DRM_ERROR("Waiting for fences timed out.");
+
+
amdgpu_bo_get_tiling_flags(abo, &tiling_flags);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/scheduler: rework job destruction
From: Christian König
We now destroy finished jobs from the worker thread to make sure that
we never destroy a job currently in timeout processing.
By this we avoid holding lock around ring mirror list in drm_sched_stop
which should solve a deadlock reported by a user.
v2: Remove unused variable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109692
Signed-off-by: Christian König
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 ++--
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 4 -
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 9 +-
drivers/gpu/drm/scheduler/sched_main.c | 138 +
drivers/gpu/drm/v3d/v3d_sched.c| 9 +-
include/drm/gpu_scheduler.h| 6 +-
6 files changed, 108 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index fcb3d95..aabd043 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3339,15 +3339,23 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- drm_sched_stop(&ring->sched);
+ drm_sched_stop(&ring->sched, &job->base);
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
- if(job)
+ if(job) {
drm_sched_increase_karma(&job->base);
+ /*
+* Guilty job did complete and hence needs to be manually
removed
+* See drm_sched_stop doc.
+*/
+ if (list_empty(&job->base.node))
+ job->base.sched->ops->free_job(&job->base);
+ }
+
if (!amdgpu_sriov_vf(adev)) {
@@ -3487,8 +3495,7 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
*hive,
return r;
}
-static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
- struct amdgpu_job *job)
+static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
{
int i;
@@ -3628,7 +3635,7 @@ int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
/* Post ASIC reset for all devs .*/
list_for_each_entry(tmp_adev, device_list_handle, gmc.xgmi.head) {
- amdgpu_device_post_asic_reset(tmp_adev, tmp_adev == adev ? job
: NULL);
+ amdgpu_device_post_asic_reset(tmp_adev);
if (r) {
/* bad news, how to tell it to userspace ? */
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 3fbb485..8434715 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -135,13 +135,11 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
mmu_size + gpu->buffer.size;
/* Add in the active command buffers */
- spin_lock_irqsave(&gpu->sched.job_list_lock, flags);
list_for_each_entry(s_job, &gpu->sched.ring_mirror_list, node) {
submit = to_etnaviv_submit(s_job);
file_size += submit->cmdbuf.size;
n_obj++;
}
- spin_unlock_irqrestore(&gpu->sched.job_list_lock, flags);
/* Add in the active buffer objects */
list_for_each_entry(vram, &gpu->mmu->mappings, mmu_node) {
@@ -183,14 +181,12 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
gpu->buffer.size,
etnaviv_cmdbuf_get_va(&gpu->buffer));
- spin_lock_irqsave(&gpu->sched.job_list_lock, flags);
list_for_each_entry(s_job, &gpu->sched.ring_mirror_list, node) {
submit = to_etnaviv_submit(s_job);
etnaviv_core_dump_mem(&iter, ETDUMP_BUF_CMD,
submit->cmdbuf.vaddr, submit->cmdbuf.size,
etnaviv_cmdbuf_get_va(&submit->cmdbuf));
}
- spin_unlock_irqrestore(&gpu->sched.job_list_lock, flags);
/* Reserve space for the bomap */
if (n_bomap_pages) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 67ae266..8795c19 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,11 +109,18 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- drm_sched_stop(&gpu->sched);
+ drm_sched_stop(&gpu->sched, sched_job);
if(sched_job)
drm_sched_increase_karma(sched_job);
+ /*
+* Guilty job did complete and hence needs to be manually removed
+* See drm_sched_stop doc.
+*/
+ if (list_empty(&sched_job->node))
+
[PATCH 3/4] drm/amdgpu: Avoid HW reset if guilty job already signaled.
Also reject TDRs if another one already running.
v2:
Stop all schedulers across device and entire XGMI hive before
force signaling HW fences.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 125 -
1 file changed, 88 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index aabd043..ce9c494 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3327,7 +3327,8 @@ bool amdgpu_device_should_recover_gpu(struct
amdgpu_device *adev)
static int amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
struct amdgpu_job *job,
- bool *need_full_reset_arg)
+ bool *need_full_reset_arg,
+ bool job_signaled)
{
int i, r = 0;
bool need_full_reset = *need_full_reset_arg;
@@ -3339,8 +3340,6 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- drm_sched_stop(&ring->sched, &job->base);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3358,7 +3357,8 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
- if (!amdgpu_sriov_vf(adev)) {
+ /* Don't suspend on bare metal if we are not going to HW reset the ASIC
*/
+ if (!amdgpu_sriov_vf(adev) && !job_signaled) {
if (!need_full_reset)
need_full_reset =
amdgpu_device_ip_need_full_reset(adev);
@@ -3495,7 +3495,7 @@ static int amdgpu_do_asic_reset(struct amdgpu_hive_info
*hive,
return r;
}
-static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev)
+static void amdgpu_device_post_asic_reset(struct amdgpu_device *adev, bool
job_signaled)
{
int i;
@@ -3505,7 +3505,8 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev)
if (!ring || !ring->sched.thread)
continue;
- if (!adev->asic_reset_res)
+ /* No point to resubmit jobs if we didn't HW reset*/
+ if (!adev->asic_reset_res && !job_signaled)
drm_sched_resubmit_jobs(&ring->sched);
drm_sched_start(&ring->sched, !adev->asic_reset_res);
@@ -3518,14 +3519,21 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev)
adev->asic_reset_res = 0;
}
-static void amdgpu_device_lock_adev(struct amdgpu_device *adev)
+static bool amdgpu_device_lock_adev(struct amdgpu_device *adev, bool trylock)
{
- mutex_lock(&adev->lock_reset);
+ if (trylock) {
+ if (!mutex_trylock(&adev->lock_reset))
+ return false;
+ } else
+ mutex_lock(&adev->lock_reset);
+
atomic_inc(&adev->gpu_reset_counter);
adev->in_gpu_reset = 1;
/* Block kfd: SRIOV would do it separately */
if (!amdgpu_sriov_vf(adev))
amdgpu_amdkfd_pre_reset(adev);
+
+ return true;
}
static void amdgpu_device_unlock_adev(struct amdgpu_device *adev)
@@ -3553,38 +3561,43 @@ static void amdgpu_device_unlock_adev(struct
amdgpu_device *adev)
int amdgpu_device_gpu_recover(struct amdgpu_device *adev,
struct amdgpu_job *job)
{
- int r;
+ int r, i;
struct amdgpu_hive_info *hive = NULL;
- bool need_full_reset = false;
struct amdgpu_device *tmp_adev = NULL;
struct list_head device_list, *device_list_handle = NULL;
+ bool xgmi_topology_present, need_full_reset, job_signaled;
+ need_full_reset = job_signaled = false;
INIT_LIST_HEAD(&device_list);
dev_info(adev->dev, "GPU reset begin!\n");
+ hive = amdgpu_get_xgmi_hive(adev, 0);
+ xgmi_topology_present = hive && adev->gmc.xgmi.num_physical_nodes > 1;
+
/*
-* In case of XGMI hive disallow concurrent resets to be triggered
-* by different nodes. No point also since the one node already
executing
-* reset will also reset all the other nodes in the hive.
+* Here we trylock to avoid chain of resets executing from
+* either trigger by jobs on different adevs in XGMI hive or jobs on
+* different schedulers for same device while this tdr is running.
+* We always reset all schedulers for device and all devices for XGMI
+* hive so that should take care of them too.
*/
- hive = amdgpu_get_xgmi_hive(adev, 0);
- if (hive && adev->gmc.xgmi.num_physical_nodes > 1 &&
- !mutex_trylock(&hive->reset_lock))
+
+ if (xgmi_topology_present && !mut
[Bug 110405] No successful install of amdgpu 18.30 on Ubuntu 18.04.02 LTS
https://bugs.freedesktop.org/show_bug.cgi?id=110405 Bug ID: 110405 Summary: No successful install of amdgpu 18.30 on Ubuntu 18.04.02 LTS Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: arnonym12...@gmail.com Created attachment 143941 --> https://bugs.freedesktop.org/attachment.cgi?id=143941&action=edit Logs, as described in https://amdgpu-install.readthedocs.io/en/latest/install-bugrep.html Standard Gnome-session not starting, after login it goes directly back to login prompt. Ubuntu with wayland is working. Cinnamon is not working. After purge of amdgpu, everything is back to normal. -- 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 4/8] arm64: dts: allwinner: Add ARM Mali GPU node for H6
On Thu, Apr 11, 2019 at 10:27 AM Maxime Ripard
wrote:
>
> On Thu, Apr 11, 2019 at 05:23:25PM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 11. april 2019 ob 17:20:04 CEST je Clément Péron napisal(a):
> > > Hi,
> > >
> > > On Thu, 11 Apr 2019 at 17:05, Jernej Škrabec
> > wrote:
> > > > Dne četrtek, 11. april 2019 ob 12:57:16 CEST je Clément Péron
> > > > napisal(a):
> > > > > Add the mali gpu node to the H6 device-tree.
> > > > >
> > > > > Signed-off-by: Clément Péron
> > > > > ---
> > > > >
> > > > > arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 ++
> > > > > 1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index
> > > > > e0dc4a05c1ba..196753110434 100644
> > > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > > @@ -157,6 +157,20 @@
> > > > >
> > > > > allwinner,sram = <&ve_sram 1>;
> > > > >
> > > > > };
> > > > >
> > > > > + gpu: gpu@180 {
> > > > > + compatible = "allwinner,sun50i-h6-mali",
> > > > > + "arm,mali-t720";
> > > > > + reg = <0x0180 0x4000>;
> > > > > + interrupts = > > >
> > > > IRQ_TYPE_LEVEL_HIGH>,
> > > >
> > > > > + > > >
> > > > IRQ_TYPE_LEVEL_HIGH>,
> > > >
> > > > > + > > >
> > > > IRQ_TYPE_LEVEL_HIGH>;
> > > >
> > > > > + interrupt-names = "job", "mmu", "gpu";
> > > > > + clocks = <&ccu CLK_GPU>, <&ccu CLK_BUS_GPU>;
> > > > > + clock-names = "core", "bus";
> > > > > + resets = <&ccu RST_BUS_GPU>;
> > > > > + status = "disabled";
> > > >
> > > > Usually self sufficient peripherals are enabled by default in DTSI.
> > >
> > > I follow the other Mali Midgard (rk3399, rk3288) syntax.
> > > But I think you're right here, will go for an update I think.
> >
> > I quickly checked A64 and H5 DTSI and both have GPU enabled by default
> > (status
> > property is not set).
>
> I asked myself the same question, but the H6 seems to have a supply
> wired to the GPU, while the H3 and H5 do not. So I'm not sure we want
> to enable it on all the boards, even though some might have left out
> the GPU supply which will result in a non-working GPU (I assume?)
If the default state is enabled, then only devfreq will be disabled
for panfrost, but it should otherwise work. I guess we could be
smarter and just do frequency changes if all the OPP voltages are the
same.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
