date:20200702

Hi Tomasz,

On Fri, Jun 19, 2020 at 01:06:55PM +, Tomasz Figa wrote:
> On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> > Bayer formats are used with cameras and contain green, red and blue
> > components, with alternating lines of red and green, and blue and green
> > pixels in different orders. For each block of 2x2 pixels there is one
> > pixel with a red filter, two with a green filter, and one with a blue
> > filter. The filters can be arranged in different patterns.
> > 
> > Add DRM fourcc formats to describe the most common Bayer formats. Also
> > add a modifiers to describe the custom packing layouts used by the Intel
> > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> > specification.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> > * Changes since v1
> > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> > - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> > - Add diagrams for all Bayer formats memory layout.
> > - Update documentation.
> > ---
> >  include/uapi/drm/drm_fourcc.h | 205 ++
> >  1 file changed, 205 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d80737..d07dd24b49bde6c1 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -285,6 +285,73 @@ extern "C" {
> >  #define DRM_FORMAT_YUV444  fourcc_code('Y', 'U', '2', '4') /* 
> > non-subsampled Cb (1) and Cr (2) planes */
> >  #define DRM_FORMAT_YVU444  fourcc_code('Y', 'V', '2', '4') /* 
> > non-subsampled Cr (1) and Cb (2) planes */
> >  
> > +/*
> > + * Bayer formats
> > + *
> > + * Bayer formats contain green, red and blue components, with alternating 
> > lines
> > + * of red and green, and blue and green pixels in different orders. For 
> > each
> > + * block of 2x2 pixels there is one pixel with a red filter, two with a 
> > green
> > + * filter, and one with a blue filter. The filters can be arranged in 
> > different
> > + * patterns.
> > + *
> > + * For example, RGGB:
> > + * row0: RGRGRGRG...
> > + * row1: GBGBGBGB...
> > + * row2: RGRGRGRG...
> > + * row3: GBGBGBGB...
> > + * ...
> > + *
> 
> I wonder if we're operating on the right level of abstraction within this
> proposal.
> 
> The sensor itself transfers only sequential pixels, as read
> out from its matrix. Whether a given pixel corresponds to a red, green
> or blue color filter actually depends on the filter layer, which could
> actually vary between integrations of the same sensor. (See Fujifilm
> X-Trans, which uses regular Sony sensors with their own filter pattern
> [1].)
> 
> Moreover, the sensor resolution is specified as the number of pixels
> horizontally and the number of lines horizontally, without considering
> the color pattern.
> 
> If we consider that, wouldn't the data stream coming from the sensor be
> essentially DRM_FORMAT_R8/R10/R12/etc.?
> 
> Then, on top of that, we would have the packing, which I believe is
> defined well in this document +/- being entangled with the Bayer
> pattern.
> 
> What do you think?
> 
> [1] https://en.wikipedia.org/wiki/Fujifilm_X-Trans_sensor

I think using DRM_FORMAT_R8/R10/R12/... is a good idea. Packing would
indeed be a modifier, and maybe the CFA could even be expressed
separately from the DRM format (4CC + modifier), through a libcamera
property.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [libcamera-devel] [PATCH v2] drm/fourcc: Add bayer formats and modifiers

Hi Emil,

On Thu, May 28, 2020 at 04:36:59PM +0100, Emil Velikov wrote:
> On Fri, 22 May 2020 at 07:56, Niklas Söderlund wrote:
> >
> > Bayer formats are used with cameras and contain green, red and blue
> > components, with alternating lines of red and green, and blue and green
> > pixels in different orders. For each block of 2x2 pixels there is one
> > pixel with a red filter, two with a green filter, and one with a blue
> > filter. The filters can be arranged in different patterns.
> >
> > Add DRM fourcc formats to describe the most common Bayer formats. Also
> > add a modifiers to describe the custom packing layouts used by the Intel
> > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> > specification.
> >
> > Signed-off-by: Niklas Söderlund 
> > ---
> > * Changes since v1
> > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> > - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> > - Add diagrams for all Bayer formats memory layout.
> > - Update documentation.
> > ---
> >  include/uapi/drm/drm_fourcc.h | 205 ++
> >  1 file changed, 205 insertions(+)
>
> Where is the user for these new formats - be that kernel or userspace?
> Did you forget to update the __drm_format_info() in
> drivers/gpu/drm/drm_fourcc.c?

The userspace user is here: https://git.linuxtv.org/libcamera.git/tree/

The formats are not used in the DRM subsystem, so I don't think there's
a need to update __drm_format_info().

libcamera is standardizing on using DRM 4CCs to ease interoperability
with display. We thus need to be able to express camera-specific formats
with DRM 4CCs, even if they're not used on the display side. The
alternative would be to have custom 4CCs for those formats, but we would
then end up risking a 4CC namespace clash.

-- 
Regards,

Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/fourcc: Add bayer formats and modifiers

Hi Sakari,

On Mon, May 25, 2020 at 01:31:43PM +0300, Sakari Ailus wrote:
> On Fri, May 22, 2020 at 01:52:01AM +0200, Niklas Söderlund wrote:
> > Bayer formats are used with cameras and contain green, red and blue
> > components, with alternating lines of red and green, and blue and green
> > pixels in different orders. For each block of 2x2 pixels there is one
> > pixel with a red filter, two with a green filter, and one with a blue
> > filter. The filters can be arranged in different patterns.
> > 
> > Add DRM fourcc formats to describe the most common Bayer formats. Also
> > add a modifiers to describe the custom packing layouts used by the Intel
> > IPU3 and in the MIPI (Mobile Industry Processor Interface) CSI-2
> > specification.
> > 
> > Signed-off-by: Niklas Söderlund 
> > ---
> > * Changes since v1
> > - Rename the defines from DRM_FORMAT_SRGGB8 to DRM_FORMAT_BAYER_RGGB8.
> > - Update the fourcc codes passed to fourcc_code() to avoid a conflict.
> > - Add diagrams for all Bayer formats memory layout.
> > - Update documentation.
> > ---
> >  include/uapi/drm/drm_fourcc.h | 205 ++
> >  1 file changed, 205 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index 8bc0b31597d80737..d07dd24b49bde6c1 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -285,6 +285,73 @@ extern "C" {
> >  #define DRM_FORMAT_YUV444  fourcc_code('Y', 'U', '2', '4') /* 
> > non-subsampled Cb (1) and Cr (2) planes */
> >  #define DRM_FORMAT_YVU444  fourcc_code('Y', 'V', '2', '4') /* 
> > non-subsampled Cr (1) and Cb (2) planes */
> >  
> > +/*
> > + * Bayer formats
> > + *
> > + * Bayer formats contain green, red and blue components, with alternating 
> > lines
> > + * of red and green, and blue and green pixels in different orders. For 
> > each
> > + * block of 2x2 pixels there is one pixel with a red filter, two with a 
> > green
> > + * filter, and one with a blue filter. The filters can be arranged in 
> > different
> > + * patterns.
> > + *
> > + * For example, RGGB:
> > + * row0: RGRGRGRG...
> > + * row1: GBGBGBGB...
> > + * row2: RGRGRGRG...
> > + * row3: GBGBGBGB...
> > + * ...
> > + *
> > + * Vendors have different methods to pack the pixel samples. For this 
> > reason the
> > + * fourcc only describes pixel sample size and the filter pattern for each 
> > block
> > + * of 2x2 pixels. A modifier is needed to describe the memory layout.
> > + *
> > + * In addition to vendor modifiers for memory layout DRM_FORMAT_MOD_LINEAR 
> > may
> > + * be used to describe a layout where all samples are placed consecutively 
> > in
> > + * memory. If the sample does not fit inside a single byte each sample is 
> > stored
> > + * in the minimum number of bytes required. Any unused bits in each sample 
> > are
> > + * defined as padding bits and set to zero.
> > + *
> > + * For example, DRM_FORMAT_BAYER_RGGB10 with DRM_FORMAT_MOD_LINEAR:
> > + *
> > + *  0  row 0 (RGRG)
> > 31
> > + *  +  -  -  -  -  -  -  -  - +  -  -  -  -  -  -  -  - +  -  -  -  -  -  
> > -  -  - +  -  -  -  -  -  -  -  - +
> > + *  | r0 r0 r0 r0 r0 r0 r0 r0 |  0  0  0  0  0  0 r0 r0 | g0 g0 g0 g0 g0 
> > g0 g0 g0 |  0  0  0  0  0  0 g0 g0 |
> > + *  +  -  -  -  -  -  -  -  - +  -  -  -  -  -  -  -  - +  -  -  -  -  -  
> > -  -  - +  -  -  -  -  -  -  -  - +
> > + *  | r1 r1 r1 r1 r1 r1 r1 r1 |  0  0  0  0  0  0 r1 r1 | g1 g1 g1 g1 g1 
> > g1 g1 g1 |  0  0  0  0  0  0 g1 g1 |
> > + *  +  -  -  -  -  -  -  -  - +  -  -  -  -  -  -  -  - +  -  -  -  -  -  
> > -  -  - +  -  -  -  -  -  -  -  - +
> > + *
> > + *  0  row 1 (GBGB)
> > 31
> > + *  +  -  -  -  -  -  -  -  - +  -  -  -  -  -  -  -  - +  -  -  -  -  -  
> > -  -  - +  -  -  -  -  -  -  -  - +
> > + *  | g0 g0 g0 g0 g0 g0 g0 g0 |  0  0  0  0  0  0 g0 g0 | b0 b0 b0 b0 b0 
> > b0 b0 b0 |  0  0  0  0  0  0 b0 b0 |
> > + *  +  -  -  -  -  -  -  -  - +  -  -  -  -  -  -  -  - +  -  -  -  -  -  
> > -  -  - +  -  -  -  -  -  -  -  - +
> > + *  | g1 g1 g1 g1 g1 g1 g1 g1 |  0  0  0  0  0  0 g1 g1 | b1 b1 b1 b1 b1 
> > b1 b1 b1 |  0  0  0  0  0  0 b1 b1 |
> > + *  +  -  -  -  -  -  -  -  - +  -  -  -  -  -  -  -  - +  -  -  -  -  -  
> > -  -  - +  -  -  -  -  -  -  -  - +
> > + */
> > +
> > +/* 8-bits Bayer formats */
> > +#define DRM_FORMAT_BAYER_RGGB8 fourcc_code('R', 'G', 'G', 'B')
> > +#define DRM_FORMAT_BAYER_GRBG8 fourcc_code('G', 'R', 'B', 'G')
> > +#define DRM_FORMAT_BAYER_GBRG8 fourcc_code('G', 'B', 'R', 'G')
> > +#define DRM_FORMAT_BAYER_BGGR8 fourcc_code('B', 'G', 'G', 'R')
> > +
> > +/* 10-bit Bayer formats */
> > +#define DRM_FORMAT_BAYER_RGGB10fourcc_code('R', 'G', '1', '0')
> > +#define DRM_FORMAT_BAYER_GRBG10fourcc_code('G', 'R',

Re: [PATCH net-next] ksz884x: mark pcidev_suspend() as __maybe_unused

2020-07-02 Thread David Miller

From: Wei Yongjun 
Date: Thu, 2 Jul 2020 17:18:10 +0800

> In certain configurations without power management support, gcc report
> the following warning:
> 
> drivers/net/ethernet/micrel/ksz884x.c:7182:12: warning:
>  'pcidev_suspend' defined but not used [-Wunused-function]
>  7182 | static int pcidev_suspend(struct device *dev_d)
>   |^~
> 
> Mark pcidev_suspend() as __maybe_unused to make it clear.
> 
> Fixes: 64120615d140 ("ksz884x: use generic power management")
> Reported-by: Hulk Robot 
> Signed-off-by: Wei Yongjun 

Applied.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for 5.8-rc1

2020-07-02 Thread James Jones


On 7/2/20 1:22 AM, Daniel Stone wrote:

Hi,

On Wed, 1 Jul 2020 at 20:45, James Jones  wrote:

OK, I think I see what's going on.  In the Xorg modesetting driver, the
logic is basically:

if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
} else {
drmModeAddFB(...);
}


I read this thread expecting to explain the correct behaviour we
implement in Weston and how modesetting needs to be fixed, but ...
that seems OK to me? As long as `gbm_has_modifiers` is a proxy for 'we
used gbm_(bo|surface)_create_with_modifiers to allocate the buffer'.


Yes, the hazards of reporting findings before verifying.  I now see 
modesetting does query the DRM-KMS modifiers and attempt to allocate 
with them if it found any.  However, I still see a lot of ways things 
can go wrong, but I'm not going to share my speculation again until I've 
actually verified it, which is taking a frustratingly long time.  The 
modesetting driver is not my friend right now.



There's no attempt to verify the DRM-KMS device supports the modifier,
but then, why would there be?  GBM presumably chose a supported modifier
at buffer creation time, and we don't know which plane the FB is going
to be used with yet.  GBM doesn't actually ask the kernel which
modifiers it supports here either though.


Right, it doesn't ask, because userspace tells it which modifiers to
use. The correct behaviour is to take the list from the KMS
`IN_FORMATS` property and then pass that to
`gbm_(bo|surface)_create_with_modifiers`; GBM must then select from
that list and only that list. If that call does not succeed and Xorg
falls back to `gbm_surface_create`, then it must not call
`gbm_bo_get_modifier` - so that would be a modesetting bug. If that
call does succeed and `gbm_bo_get_modifier` subsequently reports a
modifier which was not in the list, that's a Mesa driver bug.


It just goes into Mesa via
DRI and reports the modifier (unpatched) Mesa chose on its own.  Mesa
just hard-codes the modifiers in its driver backends since its thinking
in terms of a device's 3D engine, not display.  In theory, Mesa's DRI
drivers could query KMS for supported modifiers if allocating from GBM
using the non-modifiers path and the SCANOUT flag is set (perhaps some
drivers do this or its equivalent?  Haven't checked.), but that seems
pretty gnarly and doesn't fix the modifier-based GBM allocation path
AFAIK.  Bit of a mess.


Two options for GBM users:
* call gbm_*_create_with_modifiers, it succeeds, call
gbm_bo_get_modifier, pass modifier into AddFB
* call gbm_*_create (without modifiers), it succeeds, do not call
gbm_bo_get_modifier, do not pass a modifier into AddFB

Anything else is a bug in the user. Note that falling back from 1 to 2
is fine: if `gbm_*_create_with_modifiers()` fails, you can fall back
to the non-modifier path, provided you don't later try to get a
modifier back out.


For a quick userspace fix that could probably be pushed out everywhere
(Only affects Xorg server 1.20+ AFAIK), just retrying
drmModeAddFB2WithModifiers() without the DRM_MODE_FB_MODIFIERS flag on
failure should be sufficient.


This would break other drivers.


I think this could be done in a way that wouldn't, though it wouldn't be 
quite as simple.  Let's see what the true root cause is first though.



Still need to verify as I'm having
trouble wrangling my Xorg build at the moment and I'm pressed for time.
A more complete fix would be quite involved, as modesetting isn't really
properly plumbed to validate GBM's modifiers against KMS planes, and it
doesn't seem like GBM/Mesa/DRI should be responsible for this as noted
above given the general modifier workflow/design.

Most importantly, options I've considered for fixing from the kernel side:

-Accept "legacy" modifiers in nouveau in addition to the new modifiers,
though avoid reporting them to userspace as supported to avoid further
proliferation.  This is pretty straightforward.  I'll need to modify
both the AddFB2 handler (nouveau_validate_decode_mod) and the mode set
plane validation logic (nv50_plane_format_mod_supported), but it should
end up just being a few lines of code.


I do think that they should also be reported to userspace if they are
accepted. Other users can and do look at the modifier list to see if
the buffer is acceptable for a given plane, so the consistency is good
here. Of course, in Mesa you would want to prioritise the new
modifiers over the legacy ones, and not allocate or return the legacy
ones unless that was all you were asked for. This would involve
tracking the used modifier explicitly through Mesa, rather than
throwing it away at alloc time and then later divining it from the
tiling mode.


Reporting them as supported is equivalent to reporting support for a 
memory layout the chips don't actually support (It corresponds to a 
valid layout on Tegra chips, but not on discrete NV chips).  This is 
what the new modifiers are trying to avoid

Re: [PATCH v7 02/13] dt-bindings: panel: Convert rocktech, jh057n00900 to yaml

2020-07-02 Thread Rob Herring

On Wed, 01 Jul 2020 18:29:17 +0200, Ondrej Jirman wrote:
> Convert Rocktech MIPI DSI panel driver from txt to yaml bindings.
> 
> Signed-off-by: Ondrej Jirman 
> ---
>  .../display/panel/rocktech,jh057n00900.txt| 23 ---
>  .../display/panel/rocktech,jh057n00900.yaml   | 66 +++
>  2 files changed, 66 insertions(+), 23 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/rocktech,jh057n00900.yaml
> 


My bot found errors running 'make dt_binding_check' on your patch:

/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
 panel@0: '#address-cells', '#size-cells', 'port@0' do not match any of the 
regexes: 'pinctrl-[0-9]+'
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
 panel@0: 'vcc-supply' is a required property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
 panel@0: 'iovcc-supply' is a required property
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/nwl-dsi.example.dt.yaml:
 panel@0: 'reset-gpios' is a required property


See https://patchwork.ozlabs.org/patch/1320690

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index

2020-07-02 Thread Souza, Jose

On Thu, 2020-07-02 at 17:40 +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2020 at 11:42:36PM +, Souza, Jose wrote:
> > On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> > > for iterating through multiple ext blocks of the same type by
> > > passing the starting ext block index to drm_find_edid_extension(). Well
> > > also have drm_find_edid_extension() update the index to point to the
> > > next ext block on success. Thus we should be able to call
> > > drm_find_edid_extension() in loop.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/drm_edid.c | 30 +-
> > >  1 file changed, 21 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index d8372d63851b..f2531d51dfa2 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector, 
> > > struct edid *edid,
> > >  /*
> > >   * Search EDID for CEA extension block.
> > >   */
> > > -static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
> > > +static u8 *drm_find_edid_extension(const struct edid *edid,
> > > +int ext_id, int *ext_index)
> > >  {
> > >   u8 *edid_ext = NULL;
> > >   int i;
> > > @@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct 
> > > edid *edid, int ext_id)
> > >   return NULL;
> > >  
> > >   /* Find CEA extension */
> > > - for (i = 0; i < edid->extensions; i++) {
> > > + for (i = *ext_index; i < edid->extensions; i++) {
> > >   edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> > >   if (edid_ext[0] == ext_id)
> > >   break;
> > >   }
> > >  
> > > - if (i == edid->extensions)
> > > + if (i >= edid->extensions)
> > >   return NULL;
> > >  
> > > + *ext_index = i + 1;
> > > +
> > >   return edid_ext;
> > >  }
> > >  
> > 
> > I would add something like drm_find_edid_n_extension() with the 
> > implementation above and then implement drm_find_edid_extension() calling
> > drm_find_edid_n_extension() but it is just one caller that is not using 
> > ext_index so LGTM.
> > 
> > >  
> > >  static u8 *drm_find_displayid_extension(const struct edid *edid,
> > > - int *length, int *idx)
> > > + int *length, int *idx,
> > > + int *ext_index)
> > >  {
> > > - u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
> > > + u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> > >   struct displayid_hdr *base;
> > >   int ret;
> > >  
> > > @@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct 
> > > edid *edid)
> > >   struct displayid_block *block;
> > >   u8 *cea;
> > >   u8 *displayid;
> > > + int ext_index;
> > >  
> > >   /* Look for a top level CEA extension block */
> > > - cea = drm_find_edid_extension(edid, CEA_EXT);
> > > + ext_index = 0;
> > 
> > In 2 places ext_index is initialized in the variable declaration and in 2 
> > other places is not, all of it could be done in the declaration
> 
> No, in this case we need to reset it back to 0 when the start looking
> for the DispID ext block (as opposed to the CEA ext block). So I figured
> it's cleaner if both initialize it to 0 the same way. All the other
> places need just the one initialization.
> 
> Eventually I think I'd like some kind of for_each_ext_block() to make
> this stuff less crap...

Okay makes sense.

Reviewed-by: José Roberto de Souza 

> 
> > or if you
> > really want to leave the context close to the users, initialize it in the 
> > "for (;;)" in the next patch.
> > 
> > With the change above:
> > 
> > Reviewed-by: José Roberto de Souza 
> > 
> > > + cea = drm_find_edid_extension(edid, CEA_EXT, _index);
> > >   if (cea)
> > >   return cea;
> > >  
> > >   /* CEA blocks can also be found embedded in a DisplayID block */
> > > - displayid = drm_find_displayid_extension(edid, , );
> > > + ext_index = 0;
> > > + displayid = drm_find_displayid_extension(edid, , ,
> > > +  _index);
> > >   if (!displayid)
> > >   return NULL;
> > >  
> > > @@ -5195,8 +5203,10 @@ static int add_displayid_detailed_modes(struct 
> > > drm_connector *connector,
> > >   int length, idx;
> > >   struct displayid_block *block;
> > >   int num_modes = 0;
> > > + int ext_index = 0;
> > >  
> > > - displayid = drm_find_displayid_extension(edid, , );
> > > + displayid = drm_find_displayid_extension(edid, , ,
> > > +  _index);
> > >   if (!displayid)
> > >   return 0;
> > >  
> > > @@ -5870,11 +5880,13 @@ void drm_update_tile_info(struct drm_connector 
> > > *connector,
> > > const struct edid *edid)
> > >

[Bug 207901] Nouveau: In a 4 monitor setup, 1-2 displays remains black after boot

https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #22 from Lyude Paul (ly...@redhat.com) ---
Hi! Sorry this took me a little bit to reply to. So-it looks like we did indeed
fix the i2c timeout issue that I was seeing on your board, so the next
suspicious thing in your log seems to be the fact one of your DP ports (DP-7 in
particular) appears to think it's being continuously hotplugged:

[   90.996867] nouveau :01:00.0: DRM: unplugged DP-7
[   91.191704] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   91.191711] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS
clock 30 kHz
[   91.297638] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries,
giving up. First error: -110
[   91.297642] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
[CONNECTOR:73:DP-4] status updated from connected to connected
[   91.493173] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   91.493179] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS
clock 30 kHz
[   91.599120] [drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries,
giving up. First error: -110
[   91.599123] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
[CONNECTOR:76:DP-5] status updated from connected to connected
[   91.599335] nouveau :01:00.0: DRM: display: 4x54 dpcd 0x12
[   91.599336] nouveau :01:00.0: DRM: encoder: 4x81
[   91.599336] nouveau :01:00.0: DRM: maximum: 4x54
[   91.605980] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   91.605986] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS
clock 0 kHz
[   91.606300] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
[CONNECTOR:79:DP-6] status updated from connected to connected
[   91.606518] nouveau :01:00.0: DRM: display: 4x54 dpcd 0x12
[   91.606519] nouveau :01:00.0: DRM: encoder: 4x81
[   91.606519] nouveau :01:00.0: DRM: maximum: 4x54
[   91.613389] [drm:drm_add_display_info [drm]] non_desktop set to 0
[   91.613394] [drm:drm_add_display_info [drm]] HDMI: DVI dual 0, max TMDS
clock 0 kHz
[   91.613722] [drm:drm_helper_hpd_irq_event [drm_kms_helper]]
[CONNECTOR:82:DP-7] status updated from connected to connected
[   91.614016] nouveau :01:00.0: DRM: plugged DP-7

What kind of setup do you have your monitors hooked up through? Are they on any
laptop docks/standalone MST hubs, do they go through any video adaptors, what
models/brands and what kind of connectors do they use, etc.

As well, do you think you can grab another log from your system but using:

log_buf_len=50M drm.debug=0x116 nouveau.debug=disp=trace

(include the full log from your boot if you can and don't trim it, since it's
likely going to be a big log)

I have a feeling one of your MST devices is doing some weird out-of-spec
behavior that we might need to teach nouveau to handle

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 0/6] drm/meson: add support for Amlogic Video FBC

2020-07-02 Thread Kevin Hilman

Neil Armstrong  writes:

> Amlogic uses a proprietary lossless image compression protocol and format
> for their hardware video codec accelerators, either video decoders or
> video input encoders.
>
> It considerably reduces memory bandwidth while writing and reading
> frames in memory.
>
> The underlying storage is considered to be 3 components, 8bit or 10-bit
> per component, YCbCr 420, single plane :
> - DRM_FORMAT_YUV420_8BIT
> - DRM_FORMAT_YUV420_10BIT
>
> This modifier will be notably added to DMA-BUF frames imported from the V4L2
> Amlogic VDEC decoder.
>
> At least two layout are supported :
> - Basic: composed of a body and a header
> - Scatter: the buffer is filled with a IOMMU scatter table referring
>   to the encoder current memory layout. This mode if more efficient in terms
>   of memory allocation but frames are not dumpable and only valid during until
>   the buffer is freed and back in control of the encoder
>
> At least two options are supported :
> - Memory saving: when the pixel bpp is 8b, the size of the superblock can
>   be reduced, thus saving memory.
>
> This serie adds the missing register, updated the FBC decoder registers
> content to be committed by the crtc code.
>
> The Amlogic FBC has been tested with compressed content from the Amlogic
> HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit
> (Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit
> (Scatter on G12A/SM1, default on GXL).
>
> It's expected to work as-is on GXM and G12B SoCs.

Reviewed-by: Kevin Hilman 

Kevin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-next

2020-07-02 Thread Jani Nikula


Hi Dave & Daniel -

Here's the first batch of i915 features for v5.9.


BR,
Jani.


drm-intel-next-2020-07-02:
drm/i915 features for v5.9

Highlights:
- Rocket Lake (RKL) platform enabling (Matt Roper, Lucas, José, Aditya)

Gem/GT:
- Numerous selftest fixes and improvements (Chris)
- TGL, RKL, EHL workaround updates (Matts Atwood and Roper, Clint, Swathi 
Dhanavanthri, Chris)
- Retry faulthandlers on ENOSPC to avoid oomkiller (Chris)
- Numerous refactorings and cleanups (Chris)
- Several GT fixes around init/suspend/resume/shutdown (Chris)
- Whitelist CTX_TIMESTAMP register on non-RCS (Chris)
- Track if an engine requires forcewake w/a (Chris)
- Locking improvements (Chris)
- Timeslicing improvements (Chris)
- Add a safety submission flush in the heartbeat (Chris)
- Flush gen3 relocs harder (Chris)
- Discard a misplaced GGTT vma (Chris)
- Reduce relocation paths to async GPU relocations only (Chris)
- It's all build up with no pay off (Chris' own words...)

Display:
- A plethora of DP MST fixes (Imre)
- Implement proper dbuf global state (Ville)
- Consider dbuf bandwidth when calculating CDCLK (Stan)
- FBC fixes and refactoring (Ville)
- PSR fixes and improvements (José, Gwan-gyeong)
- Cursor size fixes (Ville)
- Overlay color and gamma fixes (Ville)
- Fix and improve FSB and HRAWCLK read out (Ville)
- Pre allocate and late cleanup of DSB cmd buffer (Animesh)
- Stop using mode->private_flags (Ville)
- Add plane color encoding support for YCBCR_BT2020 (Kishore Kadiyala)
- Update TGL Type-C DP and DKL HBR and HBR+ vswing tables (José)
- Fix DSI connector init error path (Vivek)
- A plethora of DP vswing/preemph fixes and refactoring (Ville)
- Fix TGL DKL vswing sequence selection (Vandita)
- Fix ICL hotplug interrupt disabling after storm detection (Imre)
- Retry HDCP link integrity check on failure (Oliver Barta)
- Fix TBT DPLL fractional divider (Imre)
- Fix ICL+ HBR3 source rate (Matt Atwood)
- Fix gen2 spurious underruns (Ville)
- Fix potential NULL dereference, some spelling fixes (Colin Ian King)
- Fix NULL dereference on encoder state probe (Chris)

Other:
- Backmerge to get mmap locking API (Jani)
- Distinguish Comet Lake from Coffee Lake (Chris)
- Various compiler warning fixes (Arnd Bergmann, Nathan Chancellor)
- WARN* conversions to drm_WARN* (Pankaj)
- Switch to device specific parameters with debugfs access (Jani)
- Fix agp/intel error path leak (Qiushi Wu)
- Forcewake power optimization (Chris)
- Irq handler optimization (Chris)

BR,
Jani.

The following changes since commit 0a19b068acc47d05212f03e494381926dc0381e2:

  Merge tag 'drm-misc-next-2020-06-19' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-06-24 15:45:51 
+1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2020-07-02

for you to fetch changes up to d524b87f77364db096855d7eb714ffacec974ddf:

  drm/i915: Update DRIVER_DATE to 20200702 (2020-07-02 21:25:28 +0300)


drm/i915 features for v5.9

Highlights:
- Rocket Lake (RKL) platform enabling (Matt Roper, Lucas, José, Aditya)

Gem/GT:
- Numerous selftest fixes and improvements (Chris)
- TGL, RKL, EHL workaround updates (Matts Atwood and Roper, Clint, Swathi 
Dhanavanthri, Chris)
- Retry faulthandlers on ENOSPC to avoid oomkiller (Chris)
- Numerous refactorings and cleanups (Chris)
- Several GT fixes around init/suspend/resume/shutdown (Chris)
- Whitelist CTX_TIMESTAMP register on non-RCS (Chris)
- Track if an engine requires forcewake w/a (Chris)
- Locking improvements (Chris)
- Timeslicing improvements (Chris)
- Add a safety submission flush in the heartbeat (Chris)
- Flush gen3 relocs harder (Chris)
- Discard a misplaced GGTT vma (Chris)
- Reduce relocation paths to async GPU relocations only (Chris)
- It's all build up with no pay off (Chris' own words...)

Display:
- A plethora of DP MST fixes (Imre)
- Implement proper dbuf global state (Ville)
- Consider dbuf bandwidth when calculating CDCLK (Stan)
- FBC fixes and refactoring (Ville)
- PSR fixes and improvements (José, Gwan-gyeong)
- Cursor size fixes (Ville)
- Overlay color and gamma fixes (Ville)
- Fix and improve FSB and HRAWCLK read out (Ville)
- Pre allocate and late cleanup of DSB cmd buffer (Animesh)
- Stop using mode->private_flags (Ville)
- Add plane color encoding support for YCBCR_BT2020 (Kishore Kadiyala)
- Update TGL Type-C DP and DKL HBR and HBR+ vswing tables (José)
- Fix DSI connector init error path (Vivek)
- A plethora of DP vswing/preemph fixes and refactoring (Ville)
- Fix TGL DKL vswing sequence selection (Vandita)
- Fix ICL hotplug interrupt disabling after storm detection (Imre)
- Retry HDCP link integrity check on failure (Oliver Barta)
- Fix TBT DPLL fractional divider (Imre)
- Fix ICL+ HBR3 source rate (Matt Atwood)
- Fix gen2 spurious underruns (Ville)
- Fix potential NULL dereference, some spelling fixes (Colin Ian King)
- Fix NULL dereference

Re: [PATCH 2/8] drm/amdgpu: Use __drm_atomic_helper_crtc_reset

On Fri, Jun 12, 2020 at 01:41:17PM -0400, Alex Deucher wrote:
> On Fri, Jun 12, 2020 at 1:24 PM Harry Wentland  wrote:
> >
> > On 2020-06-12 12:00 p.m., Daniel Vetter wrote:
> > > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > > which means vblank state isn't ill-defined and fail-y at driver load
> > > before the first modeset on each crtc.
> > >
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Alex Deucher 
> > > Cc: Nicholas Kazlauskas 
> > > Cc: Harry Wentland 
> > > Cc: Rodrigo Siqueira 
> > > Cc: Bhawanpreet Lakha 
> > > Cc: Roman Li 
> > > Cc: Mikita Lipski 
> > > Cc: Stylon Wang 
> >
> > Reviewed-by: Harry Wentland 
> >
> 
> Daniel, do you want to take the whole series, or should I pull this in
> through my tree?  Either way works for me.  Thanks for the patch!

Merged the entire series through drm-misc-next now.
-Daniel

> 
> Alex
> 
> > Harry
> >
> > > ---
> > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 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 68a73065b516..36d605a6eb16 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > @@ -4594,9 +4594,7 @@ static void dm_crtc_reset_state(struct drm_crtc 
> > > *crtc)
> > >   if (WARN_ON(!state))
> > >   return;
> > >
> > > - crtc->state = >base;
> > > - crtc->state->crtc = crtc;
> > > -
> > > + __drm_atomic_helper_crtc_reset(crtc, >base);
> > >  }
> > >
> > >  static struct drm_crtc_state *
> > >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support

On Thu, Jul 02, 2020 at 04:50:32PM +0200, Christian König wrote:
> Am 02.07.20 um 15:29 schrieb Jason Gunthorpe:
> > On Thu, Jul 02, 2020 at 03:10:00PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:
> > > > On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:
> > > > > > > > All you need is the ability to stop wait for ongoing accesses 
> > > > > > > > to end and
> > > > > > > > make sure that new ones grab a new mapping.
> > > > > > > Swap and flush isn't a general HW ability either..
> > > > > > > 
> > > > > > > I'm unclear how this could be useful, it is guarenteed to corrupt
> > > > > > > in-progress writes?
> > > > > > > 
> > > > > > > Did you mean pause, swap and resume? That's ODP.
> > > > > > Yes, something like this. And good to know, never heard of ODP.
> > > > > Hm I thought ODP was full hw page faults at an individual page
> > > > > level,
> > > > Yes
> > > > 
> > > > > and this stop is for the entire nic. Under the hood both apply
> > > > > back-pressure on the network if a transmission can't be received,
> > > > > but
> > > > NIC's don't do stop and resume, blocking the Rx pipe is very
> > > > problematic and performance destroying.
> > > > 
> > > > The strategy for something like ODP is more complex, and so far no NIC
> > > > has deployed it at any granularity larger than per-page.
> > > > 
> > > > > So since Jason really doesn't like dma_fence much I think for rdma
> > > > > synchronous it is. And it shouldn't really matter, since waiting for a
> > > > > small transaction to complete at rdma wire speed isn't really that
> > > > > long an operation.
> > > > Even if DMA fence were to somehow be involved, how would it look?
> > > Well above you're saying it would be performance destroying, but let's
> > > pretend that's not a problem :-) Also, I have no clue about rdma, so this
> > > is really just the flow we have on the gpu side.
> > I see, no, this is not workable, the command flow in RDMA is not at
> > all like GPU - what you are a proposing is a global 'stop the whole
> > chip' Tx and Rx flows for an undetermined time. Not feasible

Yeah, I said I have no clue about rdma :-)

> > What we can do is use ODP techniques and pause only the MR attached to
> > the DMA buf with the process you outline below. This is not so hard to
> > implement.
> 
> Well it boils down to only two requirements:
> 
> 1. You can stop accessing the memory or addresses exported by the DMA-buf.
> 
> 2. Before the next access you need to acquire a new mapping.
> 
> How you do this is perfectly up to you. E.g. you can stop everything, just
> prevent access to this DMA-buf, or just pause the users of this DMA-buf

Yeah in a gpu we also don't stop the entire world, only the context that
needs the buffer. If there's other stuff to run, we do keep running that.
Usually the reason for a buffer move is that we do actually have other
stuff that needs to be run, and which needs more vram for itself, so we
might have to throw out a few buffers from vram that can also be placed in
system memory.

Note that a modern gpu has multiple engines and most have or are gaining
hw scheduling of some sort, so there's a pile of concurrent gpu context
execution going on at any moment. The days where we just push gpu work
into a fifo are (mostly) long gone.

> > > 3. rdma driver worker gets busy to restart rx:
> > >   1. lock all dma-buf that are currently in use (dma_resv_lock).
> > >   thanks to ww_mutex deadlock avoidance this is possible
> > Why all? Why not just lock the one that was invalidated to restore the
> > mappings? That is some artifact of the GPU approach?
> 
> No, but you must make sure that mapping one doesn't invalidate others you
> need.
> 
> Otherwise you can end up in a nice live lock :)

Also if you don't have pagefaults, but have to track busy memory at a
context level, you do need to grab all locks of all buffers you need, or
you'd race. There's nothing stopping a concurrent ->notify_move on some
other buffer you'll need otherwise, and if you try to be clever and roll
you're own locking, you'll anger lockdep - you're own lock will have to be
on both sides of ww_mutex or it wont work, and that deadlocks.

So ww_mutex multi-lock dance or bust.

> > And why is this done with work queues and locking instead of a
> > callback saying the buffer is valid again?
> 
> You can do this as well, but a work queue is usually easier to handle than a
> notification in an interrupt context of a foreign driver.

Yeah you can just install a dma_fence callback but
- that's hardirq context
- if you don't have per-page hw faults you need the multi-lock ww_mutex
  dance anyway to avoid races.

On top of that the exporter has no idea whether the importer still really
needs the mapping, or whether it was just kept around opportunistically.
pte setup isn't free, so by default gpus keep everything mapped. At least
for the classic gl/vk execution model, compute like rocm/amdkfd is

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

On Thu, Jul 02, 2020 at 05:11:25PM +0200, Neil Armstrong wrote:
> Hi,
> 
> On 02/07/2020 16:15, Daniel Vetter wrote:
> > On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong  
> > wrote:
> >>
> >> On 02/07/2020 15:18, Daniel Vetter wrote:
> >>> On Thu, Jul 02, 2020 at 09:23:11AM +, Simon Ser wrote:
>  On Thursday, July 2, 2020 9:47 AM, Neil Armstrong 
>   wrote:
> 
> > Finally is also adds the Scatter Memory layout, meaning the header 
> > contains IOMMU
> > references to the compressed frames content to optimize memory access
> > and layout.
> >
> > In this mode, only the header memory address is needed, thus the content
> > memory organization is tied to the current producer execution and cannot
> > be saved/dumped neither transferrable between Amlogic SoCs supporting 
> > this
> > modifier.
> 
>  Still not sure how to handle this one, since this breaks fundamental
>  assumptions about modifiers.
> >>>
> >>> I wonder whether we should require special allocations for these, and then
> >>> just outright reject mmap on these buffers. mmap on dma-buf isn't a
> >>> required feature.
> >>
> >> Yes, it's the plan to reject mmap on these buffers, but it can't be 
> >> explained
> >> in the modifiers description and it's a requirement of the producer, not 
> >> the
> >> consumer.
> > 
> > Hm I think worth to add that as a note to the modifier. Just to make
> > sure. And avoids questions like the one from Simon.
> 
> Something like:
> 
>  /*
>   * Amlogic FBC Scatter Memory layout
>   *
>   * Indicates the header contains IOMMU references to the compressed
>   * frames content to optimize memory access and layout.
>   *
>   * In this mode, only the header memory address is needed, thus the
>   * content memory organization is tied to the current producer
>   * execution and cannot be saved/dumped neither transferrable between
>   * Amlogic SoCs supporting this modifier.
> + *
> + * Due to the nature of the layout, these buffers are not expected to
> + * be accessible by the user-space clients but only accessible by the
> + * hardware producers and consumers.
> + *
> + * The user-space clients should expect a failure while trying to mmap
> + * the DMA-BUF handle returned by the producer.
>   */

lgtm, Acked-by: Daniel Vetter 
> 
> Thanks,
> Neil
> 
> > -Daniel
> > 
> >>
> >>>
> >>> That would make sure that userspace cannot look at them.
> >>>
> >>> Also I'm kinda suspecting that there's not unlimited amounts of this magic
> >>> invisible storage available anyway.
> >>> -Daniel
> >>>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> > 
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm : Insert blank lines after declarations.

On Thu, Jul 02, 2020 at 06:53:32PM +0530, Suraj Upadhyay wrote:
> Resolve checkpatch issues for missing blank lines after declarations.
> Issues found in multiple files with checkpatch.pl.
> 
> Signed-off-by: Suraj Upadhyay 
> ---
> Contributor comments : Hii developers, I am a new contributor to linux
> kernel. This email is over 600 lines however the changes are very small.
> Please, tell me if I should send the changes in a patchset.

Generally it's better to split up patches a bit, this way if there's a
conflict due to ongoing other work all the other pieces can be merged
already.

Anyway it looks like you're extremely lucky, no conflicts even for such a
big patch that applies to tons of files. So I went ahead and applied it to
drm-misc-next.

Cheers, Daniel

> 
>  drivers/gpu/drm/drm_atomic.c  |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  7 +++
>  drivers/gpu/drm/drm_bufs.c|  6 ++
>  drivers/gpu/drm/drm_connector.c   |  2 ++
>  drivers/gpu/drm/drm_crtc.c|  1 +
>  drivers/gpu/drm/drm_crtc_helper.c |  3 +++
>  drivers/gpu/drm/drm_dp_helper.c   |  1 +
>  drivers/gpu/drm/drm_dp_mst_topology.c | 20 
>  drivers/gpu/drm/drm_edid.c| 17 +
>  drivers/gpu/drm/drm_file.c|  2 ++
>  drivers/gpu/drm/drm_framebuffer.c |  1 +
>  drivers/gpu/drm/drm_ioc32.c   |  2 ++
>  drivers/gpu/drm/drm_lease.c   |  4 
>  drivers/gpu/drm/drm_lock.c|  1 +
>  drivers/gpu/drm/drm_mode_config.c |  1 +
>  drivers/gpu/drm/drm_pci.c |  1 +
>  drivers/gpu/drm/drm_plane.c   |  1 +
>  drivers/gpu/drm/drm_prime.c   |  1 +
>  drivers/gpu/drm/drm_syncobj.c |  1 +
>  drivers/gpu/drm/drm_vblank.c  |  1 +
>  20 files changed, 74 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 965173fd0ac2..58527f151984 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -575,6 +575,7 @@ static int drm_atomic_plane_check(const struct 
> drm_plane_state *old_plane_state,
>  fb->modifier);
>   if (ret) {
>   struct drm_format_name_buf format_name;
> +
>   DRM_DEBUG_ATOMIC("[PLANE:%d:%s] invalid pixel format %s, 
> modifier 0x%llx\n",
>plane->base.id, plane->name,
>drm_get_format_name(fb->format->format,
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index a1e5e262bae2..25c269bc4681 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -522,6 +522,7 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>  
>   if (property == config->prop_fb_id) {
>   struct drm_framebuffer *fb;
> +
>   fb = drm_framebuffer_lookup(dev, file_priv, val);
>   drm_atomic_set_fb_for_plane(state, fb);
>   if (fb)
> @@ -539,6 +540,7 @@ static int drm_atomic_plane_set_property(struct drm_plane 
> *plane,
>  
>   } else if (property == config->prop_crtc_id) {
>   struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
> +
>   if (val && !crtc)
>   return -EACCES;
>   return drm_atomic_set_crtc_for_plane(state, crtc);
> @@ -681,6 +683,7 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>  
>   if (property == config->prop_crtc_id) {
>   struct drm_crtc *crtc = drm_crtc_find(dev, file_priv, val);
> +
>   if (val && !crtc)
>   return -EACCES;
>   return drm_atomic_set_crtc_for_connector(state, crtc);
> @@ -754,6 +757,7 @@ static int drm_atomic_connector_set_property(struct 
> drm_connector *connector,
>   } else if (property == config->writeback_fb_id_property) {
>   struct drm_framebuffer *fb;
>   int ret;
> +
>   fb = drm_framebuffer_lookup(dev, file_priv, val);
>   ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
>   if (fb)
> @@ -861,6 +865,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
>   switch (obj->type) {
>   case DRM_MODE_OBJECT_CONNECTOR: {
>   struct drm_connector *connector = obj_to_connector(obj);
> +
>   
> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>   ret = drm_atomic_connector_get_property(connector,
>   connector->state, property, val);
> @@ -868,6 +873,7 @@ int drm_atomic_get_property(struct drm_mode_object *obj,
>   }
>   case DRM_MODE_OBJECT_CRTC: {
>   struct drm_crtc *crtc = obj_to_crtc(obj);
> +
>   WARN_ON(!drm_modeset_is_locked(>mutex));
>   ret = drm_atomic_crtc_get_property(crtc,
>   crtc->state,

[PATCH RFC v6 3/6] PM / devfreq: exynos-bus: Add registration of interconnect child device

This patch adds registration of a child platform device for the exynos
interconnect driver. It is assumed that the interconnect provider will
only be needed when #interconnect-cells property is present in the bus
DT node, hence the child device will be created only when such a property
is present.

Signed-off-by: Sylwester Nawrocki 
Acked-by: Chanwoo Choi 
---
Changes for v6:
 - none.

Changes for v5:
 - new patch.
---
 drivers/devfreq/exynos-bus.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
index 8fa8eb5..856e37d 100644
--- a/drivers/devfreq/exynos-bus.c
+++ b/drivers/devfreq/exynos-bus.c
@@ -24,6 +24,7 @@

 struct exynos_bus {
struct device *dev;
+   struct platform_device *icc_pdev;

struct devfreq *devfreq;
struct devfreq_event_dev **edev;
@@ -156,6 +157,8 @@ static void exynos_bus_exit(struct device *dev)
if (ret < 0)
dev_warn(dev, "failed to disable the devfreq-event devices\n");

+   platform_device_unregister(bus->icc_pdev);
+
dev_pm_opp_of_remove_table(dev);
clk_disable_unprepare(bus->clk);
if (bus->opp_table) {
@@ -168,6 +171,8 @@ static void exynos_bus_passive_exit(struct device *dev)
 {
struct exynos_bus *bus = dev_get_drvdata(dev);

+   platform_device_unregister(bus->icc_pdev);
+
dev_pm_opp_of_remove_table(dev);
clk_disable_unprepare(bus->clk);
 }
@@ -431,6 +436,18 @@ static int exynos_bus_probe(struct platform_device *pdev)
if (ret < 0)
goto err;

+   /* Create child platform device for the interconnect provider */
+   if (of_get_property(dev->of_node, "#interconnect-cells", NULL)) {
+   bus->icc_pdev = platform_device_register_data(
+   dev, "exynos-generic-icc",
+   PLATFORM_DEVID_AUTO, NULL, 0);
+
+   if (IS_ERR(bus->icc_pdev)) {
+   ret = PTR_ERR(bus->icc_pdev);
+   goto err;
+   }
+   }
+
max_state = bus->devfreq->profile->max_state;
min_freq = (bus->devfreq->profile->freq_table[0] / 1000);
max_freq = (bus->devfreq->profile->freq_table[max_state - 1] / 1000);
--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC v6 6/6] drm: exynos: mixer: Add interconnect support

This patch adds interconnect support to exynos-mixer. The mixer works
the same as before when CONFIG_INTERCONNECT is 'n'.

For proper operation of the video mixer block we need to ensure the
interconnect busses like DMC or LEFTBUS provide enough bandwidth so
as to avoid DMA buffer underruns in the mixer block. I.e we need to
prevent those busses from operating in low perfomance OPPs when
the mixer is running.
In this patch the bus bandwidth request is done through the interconnect
API, the bandwidth value is calculated from selected DRM mode, i.e.
video plane width, height, refresh rate and pixel format.

The bandwidth setting is synchronized with VSYNC when we are switching
to lower bandwidth. This is required to ensure enough bandwidth for
the device since new settings are normally being applied in the hardware
synchronously with VSYNC.

Co-developed-by: Artur Świgoń 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Sylwester Nawrocki 
---
Changes for v6:
 - the icc_set_bw() call is now only done when calculated value for
   a crtc changes, this avoids unnecessary calls per each video frame
 - added synchronization of the interconnect bandwidth setting with
   the mixer VSYNC in order to avoid buffer underflow when we lower
   the interconnect bandwidth when the hardware still operates with
   previous mode settings that require higher bandwidth. This fixed
   IOMMU faults observed e.g. during switching from two planes to
   a single plane operation.

Changes for v5:
 - renamed soc_path variable to icc_path
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 150 --
 1 file changed, 142 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c7e2e2e..f7babf8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -73,6 +74,7 @@ enum mixer_flag_bits {
MXR_BIT_INTERLACE,
MXR_BIT_VP_ENABLED,
MXR_BIT_HAS_SCLK,
+   MXR_BIT_REQUEST_BW,
 };
 
 static const uint32_t mixer_formats[] = {
@@ -99,6 +101,13 @@ struct mixer_context {
struct exynos_drm_plane planes[MIXER_WIN_NR];
unsigned long   flags;
 
+   struct icc_path *icc_path;
+   /* memory bandwidth on the interconnect bus in B/s */
+   unsigned long   icc_bandwidth;
+   /* mutex protecting @icc_bandwidth and serializing access to @icc_path 
*/
+   struct mutexicc_lock;
+   struct work_struct  work;
+
int irq;
void __iomem*mixer_regs;
void __iomem*vp_regs;
@@ -754,6 +763,9 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)
val |= MXR_INT_CLEAR_VSYNC;
val &= ~MXR_INT_STATUS_VSYNC;
 
+   if (test_and_clear_bit(MXR_BIT_REQUEST_BW, >flags))
+   schedule_work(>work);
+
/* interlace scan need to check shadow register */
if (test_bit(MXR_BIT_INTERLACE, >flags)
&& !mixer_is_synced(ctx))
@@ -934,6 +946,78 @@ static void mixer_disable_vblank(struct exynos_drm_crtc 
*crtc)
mixer_reg_writemask(mixer_ctx, MXR_INT_EN, 0, MXR_INT_EN_VSYNC);
 }
 
+/**
+ * mixer_get_memory_bandwidth - calculate memory bandwidth for current crtc 
mode
+ * @crtc: a crtc with DRM mode to calculate the bandwidth for
+ *
+ * Return: memory bandwidth in B/s
+ *
+ * This function returns memory bandwidth calculated as a sum of amount of data
+ * per second for each plane. The calculation is based on maximum possible 
pixel
+ * resolution for a plane so as to avoid different bandwidth request per each
+ * video frame. The formula used for calculation for each plane is:
+ *
+ * bw = width * height * frame_rate / interlace / (hor_subs * vert_subs)
+ *
+ * where:
+ *  - width, height - (DRM mode) video frame width and height in pixels,
+ *  - frame_rate - DRM mode frame refresh rate,
+ *  - interlace: 1 - in case of progressive and 2 in case of interlaced video,
+ *  - hor_subs, vert_subs - accordingly horizontal and vertical pixel
+ *subsampling for a plane.
+ */
+static unsigned int mixer_get_memory_bandwidth(struct exynos_drm_crtc *crtc)
+{
+   struct drm_display_mode *mode = >base.state->adjusted_mode;
+   struct mixer_context *ctx = crtc->ctx;
+   unsigned long bw, bandwidth = 0;
+   int i, j, sub;
+
+   for (i = 0; i < MIXER_WIN_NR; i++) {
+   struct drm_plane *plane = >planes[i].base;
+   const struct drm_format_info *format;
+
+   if (plane->state && plane->state->crtc && plane->state->fb) {
+   format = plane->state->fb->format;
+   bw = mode->hdisplay * mode->vdisplay *
+   drm_mode_vrefresh(mode);
+

[PATCH RFC v6 2/6] interconnect: Add generic interconnect driver for Exynos SoCs

This patch adds a generic interconnect driver for Exynos SoCs in order
to provide interconnect functionality for each "samsung,exynos-bus"
compatible device.

The SoC topology is a graph (or more specifically, a tree) and its
edges are specified using the 'samsung,interconnect-parent' in the
DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
propagated to ensure that the parent is probed before its children.

Each bus is now an interconnect provider and an interconnect node as
well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
registers itself as a node. Node IDs are not hardcoded but rather
assigned dynamically at runtime. This approach allows for using this
driver with various Exynos SoCs.

Frequencies requested via the interconnect API for a given node are
propagated to devfreq using dev_pm_qos_update_request(). Please note
that it is not an error when CONFIG_INTERCONNECT is 'n', in which
case all interconnect API functions are no-op.

The bus-width DT property is to determine the interconnect data
width and traslate requested bandwidth to clock frequency for each
bus.

Signed-off-by: Artur Świgoń 
Signed-off-by: Sylwester Nawrocki 
---
Changes for v6:
 - corrected of_node dereferencing in exynos_icc_get_parent()
   function,
 - corrected initialization of icc_node->name so as to avoid
   direct of_node->name dereferencing,
 - added parsing of bus-width DT property,
 - use IS_ERR_OR_NULL in exynos_icc_genberic_remove().

Changes for v5:
 - adjust to renamed exynos,interconnect-parent-node property,
 - use automatically generated platform device id as the interconect
   node id instead of a now unavailable devfreq->id field,
 - add icc_ prefix to some variables to make the code more self-commenting,
 - use icc_nodes_remove() instead of icc_node_del() + icc_node_destroy(),
 - adjust to exynos,interconnect-parent-node property rename to
   samsung,interconnect-parent,
 - converted to a separate platform driver in drivers/interconnect.
---
 drivers/interconnect/Kconfig |   1 +
 drivers/interconnect/Makefile|   1 +
 drivers/interconnect/exynos/Kconfig  |   6 ++
 drivers/interconnect/exynos/Makefile |   4 +
 drivers/interconnect/exynos/exynos.c | 192 +++
 5 files changed, 204 insertions(+)
 create mode 100644 drivers/interconnect/exynos/Kconfig
 create mode 100644 drivers/interconnect/exynos/Makefile
 create mode 100644 drivers/interconnect/exynos/exynos.c

diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
index 5b7204e..eca6eda 100644
--- a/drivers/interconnect/Kconfig
+++ b/drivers/interconnect/Kconfig
@@ -11,6 +11,7 @@ menuconfig INTERCONNECT
 
 if INTERCONNECT
 
+source "drivers/interconnect/exynos/Kconfig"
 source "drivers/interconnect/imx/Kconfig"
 source "drivers/interconnect/qcom/Kconfig"
 
diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
index 4825c28..2ba1de6 100644
--- a/drivers/interconnect/Makefile
+++ b/drivers/interconnect/Makefile
@@ -4,5 +4,6 @@ CFLAGS_core.o   := -I$(src)
 icc-core-objs  := core.o
 
 obj-$(CONFIG_INTERCONNECT) += icc-core.o
+obj-$(CONFIG_INTERCONNECT_EXYNOS)  += exynos/
 obj-$(CONFIG_INTERCONNECT_IMX) += imx/
 obj-$(CONFIG_INTERCONNECT_QCOM)+= qcom/
diff --git a/drivers/interconnect/exynos/Kconfig 
b/drivers/interconnect/exynos/Kconfig
new file mode 100644
index 000..e51e52e
--- /dev/null
+++ b/drivers/interconnect/exynos/Kconfig
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config INTERCONNECT_EXYNOS
+   tristate "Exynos generic interconnect driver"
+   depends on ARCH_EXYNOS || COMPILE_TEST
+   help
+ Generic interconnect driver for Exynos SoCs.
diff --git a/drivers/interconnect/exynos/Makefile 
b/drivers/interconnect/exynos/Makefile
new file mode 100644
index 000..e19d1df
--- /dev/null
+++ b/drivers/interconnect/exynos/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+exynos-interconnect-objs   := exynos.o
+
+obj-$(CONFIG_INTERCONNECT_EXYNOS)  += exynos-interconnect.o
diff --git a/drivers/interconnect/exynos/exynos.c 
b/drivers/interconnect/exynos/exynos.c
new file mode 100644
index 000..6c47a62
--- /dev/null
+++ b/drivers/interconnect/exynos/exynos.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Exynos generic interconnect provider driver
+ *
+ * Copyright (c) 2020 Samsung Electronics Co., Ltd.
+ *
+ * Authors: Artur Świgoń 
+ *  Sylwester Nawrocki 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EXYNOS_ICC_DEFAULT_BUS_WIDTH   8
+
+struct exynos_icc_priv {
+   struct device *dev;
+
+   /* One interconnect node per provider */
+   struct icc_provider provider;
+   struct icc_node *node;
+
+   struct dev_pm_qos_request qos_req;
+   u32 bus_width;
+};
+
+static struct icc_node

[PATCH RFC v6 5/6] ARM: dts: exynos: Add interconnects to Exynos4412 mixer

From: Artur Świgoń 

This patch adds an 'interconnects' property to Exynos4412 DTS in order to
declare the interconnect path used by the mixer. Please note that the
'interconnect-names' property is not needed when there is only one path in
'interconnects', in which case calling of_icc_get() with a NULL name simply
returns the right path.

Signed-off-by: Artur Świgoń 
Reviewed-by: Chanwoo Choi 
---
Changes for v5, v6:
 - none.
---
 arch/arm/boot/dts/exynos4412.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index 24529d4..e0be193 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -777,6 +777,7 @@
clock-names = "mixer", "hdmi", "sclk_hdmi", "vp";
clocks = < CLK_MIXER>, < CLK_HDMI>,
 < CLK_SCLK_HDMI>, < CLK_VP>;
+   interconnects = <_display _dmc>;
 };

  {
--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC v6 4/6] ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes

This patch adds the following properties for Exynos4412 interconnect
bus nodes:
 - samsung,interconnect-parent: to declare connections between
   nodes in order to guarantee PM QoS requirements between nodes,
 - #interconnect-cells: required by the interconnect framework,
 - bus-width: the bus width in bits, required to properly derive
   minimum bus clock frequency from requested bandwidth for each
   bus.

Note that #interconnect-cells is always zero and node IDs are not
hardcoded anywhere.

Signed-off-by: Artur Świgoń 
Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Chanwoo Choi 
---
Changes for v6:
 - added bus-width property in bus_dmc node.

Changes for v5:
 - adjust to renamed exynos,interconnect-parent-node property,
 - add properties in common exynos4412.dtsi file rather than
   in Odroid specific odroid4412-odroid-common.dtsi.
---
 arch/arm/boot/dts/exynos4412.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412.dtsi 
b/arch/arm/boot/dts/exynos4412.dtsi
index 4886894..24529d4 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -381,6 +381,8 @@
clocks = < CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <_dmc_opp_table>;
+   bus-width = <4>;
+   #interconnect-cells = <0>;
status = "disabled";
};

@@ -450,6 +452,8 @@
clocks = < CLK_DIV_GDL>;
clock-names = "bus";
operating-points-v2 = <_leftbus_opp_table>;
+   samsung,interconnect-parent = <_dmc>;
+   #interconnect-cells = <0>;
status = "disabled";
};

@@ -466,6 +470,8 @@
clocks = < CLK_ACLK160>;
clock-names = "bus";
operating-points-v2 = <_display_opp_table>;
+   samsung,interconnect-parent = <_leftbus>;
+   #interconnect-cells = <0>;
status = "disabled";
};

--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC v6 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties

Add documentation for new optional properties in the exynos bus nodes:
samsung,interconnect-parent, #interconnect-cells, bus-width.
These properties allow to specify the SoC interconnect structure which
then allows the interconnect consumer devices to request specific
bandwidth requirements.

Signed-off-by: Artur Świgoń 
Signed-off-by: Sylwester Nawrocki 
---
Changes for v6:
 - added dts example of bus hierarchy definition and the interconnect
   consumer,
 - added new bus-width property.

Changes for v5:
 - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
---
 .../devicetree/bindings/devfreq/exynos-bus.txt | 68 +-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt 
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
index e71f752..4035e3e 100644
--- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -51,6 +51,13 @@ Optional properties only for parent bus device:
 - exynos,saturation-ratio: the percentage value which is used to calibrate
the performance count against total cycle count.
 
+Optional properties for interconnect functionality (QoS frequency constraints):
+- samsung,interconnect-parent: phandle to the parent interconnect node; for
+  passive devices should point to same node as the exynos,parent-bus property.
+- #interconnect-cells: should be 0.
+- bus-width: the interconnect bus width in bits, default value is 8 when this
+  property is missing.
+
 Detailed correlation between sub-blocks and power line according to Exynos SoC:
 - In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC
@@ -135,7 +142,7 @@ Detailed correlation between sub-blocks and power line 
according to Exynos SoC:
|--- PERIC (Fixed clock rate)
|--- FSYS  (Fixed clock rate)
 
-Example1:
+Example 1:
Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
power line (regulator). The MIF (Memory Interface) AXI bus is used to
transfer data between DRAM and CPU and uses the VDD_MIF regulator.
@@ -184,7 +191,7 @@ Example1:
|L5   |20 |20  |40 |30 |   ||100 |
--
 
-Example2 :
+Example 2:
The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
is listed below:
 
@@ -419,3 +426,60 @@ Example2 :
devfreq = <_leftbus>;
status = "okay";
};
+
+Example 3:
+   An interconnect path "bus_display -- bus_leftbus -- bus_dmc" on
+   Exynos4412 SoC with video mixer as an interconnect consumer device.
+
+   soc {
+   bus_dmc: bus_dmc {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_DMC>;
+   clock-names = "bus";
+   operating-points-v2 = <_dmc_opp_table>;
+   bus-width = <4>;
+   #interconnect-cells = <0>;
+   status = "disabled";
+   };
+
+   bus_leftbus: bus_leftbus {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_DIV_GDL>;
+   clock-names = "bus";
+   operating-points-v2 = <_leftbus_opp_table>;
+   samsung,interconnect-parent = <_dmc>;
+   #interconnect-cells = <0>;
+   status = "disabled";
+   };
+
+   bus_display: bus_display {
+   compatible = "samsung,exynos-bus";
+   clocks = < CLK_ACLK160>;
+   clock-names = "bus";
+   operating-points-v2 = <_display_opp_table>;
+   samsung,interconnect-parent = <_leftbus>;
+   #interconnect-cells = <0>;
+   status = "disabled";
+   };
+
+   bus_dmc_opp_table: opp_table1 {
+   compatible = "operating-points-v2";
+   /* ... */
+   }
+
+   bus_leftbus_opp_table: opp_table3 {
+   compatible = "operating-points-v2";
+   /* ... */
+   };
+
+   bus_display_opp_table: opp_table4 {
+   compatible = "operating-points-v2";
+   /* .. */
+   };
+
+{
+   compatible = "samsung,exynos4212-mixer";
+   interconnects = <_display _dmc>;
+   /* ... */
+   };
+   };
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH RFC v6 0/6] Exynos: Simple QoS for exynos-bus using interconnect

This patchset adds interconnect API support for the Exynos SoC "samsung,
exynos-bus" compatible devices, which already have their corresponding
exynos-bus driver in the devfreq subsystem.  Complementing the devfreq
driver with an interconnect functionality allows to ensure the QoS
requirements of devices accessing the system memory (e.g. video processing
devices) are fulfilled and aallows to avoid issues like the one discussed
in thread [1].

This patch series adds implementation of the interconnect provider per each
"samsung,exynos-bus" compatible DT node, with one interconnect node per
provider.  The interconnect code which was previously added as a part of
the devfreq driver has been converted to a separate platform driver.
In the devfreq a corresponding virtual child platform device is registered.
Integration of devfreq and interconnect frameworks is achieved through
the PM QoS API.

A sample interconnect consumer for exynos-mixer is added in patches 5/6,
6/6, it is currently added only for exynos4412 and allows to address the
mixer DMA underrun error issues [1].

Main changes since v5 [3] is an addition of "bus-width: DT property, which
specifies data width of the interconnect bus (patches 1...2/6 and addition
of synchronization of the interconnect bandwidth setting with VSYNC
(patch 6/6).

The series has been tested on Odroid U3 board. It is based on icc-next
branch, which already includes required patches [2]:
 26c205e interconnect: Allow inter-provider pairs to be configured
 0db4ee05 interconnect: Relax requirement in of_icc_get_from_provider()
 6998a7c interconnect: Export of_icc_get_from_provider()

--
Regards,
Sylwester


Changes since v3 [4] (v4 skipped to align with patchset [1]), detailed
changes are listed in each patch:
 - conversion to a separate interconnect (platform) driver,
 - an update of the DT binding documenting new optional properties:
   #interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus"
   nodes,
 - new DT properties added to the SoC, rather than to the board specific
   files.

Changes since v2 [5]:
 - Use icc_std_aggregate().
 - Implement a different modification of apply_constraints() in
   drivers/interconnect/core.c (patch 03).
 - Use 'exynos,interconnect-parent-node' in the DT instead of
   'devfreq'/'parent', depending on the bus.
 - Rebase on DT patches that deprecate the 'devfreq' DT property.
 - Improve error handling, including freeing generated IDs on failure.
 - Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent().

Changes since v1 [6]:
 - Rebase on coupled regulators patches.
 - Use dev_pm_qos_*() API instead of overriding frequency in
   exynos_bus_target().
 - Use IDR for node ID allocation.
 - Reverse order of multiplication and division in
   mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow.


References:
[1] https://patchwork.kernel.org/patch/10861757/ (original issue)
[2] https://www.spinics.net/lists/linux-samsung-soc/msg70014.html
[3] https://www.spinics.net/lists/arm-kernel/msg810722.html
[4] https://lore.kernel.org/linux-pm/20191220115653.6487-1-a.swi...@samsung.com
[5] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
[6] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC)


Artur Świgoń (1):
  ARM: dts: exynos: Add interconnects to Exynos4412 mixer

Sylwester Nawrocki (5):
  dt-bindings: exynos-bus: Add documentation for interconnect properties
  interconnect: Add generic interconnect driver for Exynos SoCs
  PM / devfreq: exynos-bus: Add registration of interconnect child
device
  ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
  drm: exynos: mixer: Add interconnect support

 .../devicetree/bindings/devfreq/exynos-bus.txt |  68 +++-
 arch/arm/boot/dts/exynos4412.dtsi  |   7 +
 drivers/devfreq/exynos-bus.c   |  17 ++
 drivers/gpu/drm/exynos/exynos_mixer.c  | 150 +++-
 drivers/interconnect/Kconfig   |   1 +
 drivers/interconnect/Makefile  |   1 +
 drivers/interconnect/exynos/Kconfig|   6 +
 drivers/interconnect/exynos/Makefile   |   4 +
 drivers/interconnect/exynos/exynos.c   | 192 +
 9 files changed, 436 insertions(+), 10 deletions(-)
 create mode 100644 drivers/interconnect/exynos/Kconfig
 create mode 100644 drivers/interconnect/exynos/Makefile
 create mode 100644 drivers/interconnect/exynos/exynos.c

--
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 2/2] display/drm/bridge: TC358775 DSI/LVDS driver

2020-07-02 Thread kernel test robot

Hi Vinay,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc3 next-20200702]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Vinay-Simha-BN/dt-binding-Add-DSI-LVDS-TC358775-bridge-bindings/20200702-203915
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
cd77006e01b3198c75fb7819b3d0ff89709539bb
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/bridge/tc358775.c:527:1: warning: no previous prototype for 
>> 'tc_mode_valid' [-Wmissing-prototypes]
 527 | tc_mode_valid(struct drm_bridge *bridge,
 | ^
   drivers/gpu/drm/bridge/tc358775.c:662:16: error: initialization of 'enum 
drm_mode_status (*)(struct drm_bridge *, const struct drm_display_mode *)' from 
incompatible pointer type 'enum drm_mode_status (*)(struct drm_bridge *, const 
struct drm_display_info *, const struct drm_display_mode *)' 
[-Werror=incompatible-pointer-types]
 662 |  .mode_valid = tc_mode_valid,
 |^
   drivers/gpu/drm/bridge/tc358775.c:662:16: note: (near initialization for 
'tc_bridge_funcs.mode_valid')
   cc1: some warnings being treated as errors

vim +/tc_mode_valid +527 drivers/gpu/drm/bridge/tc358775.c

   525  
   526  enum drm_mode_status
 > 527  tc_mode_valid(struct drm_bridge *bridge,
   528const struct drm_display_info *info,
   529const struct drm_display_mode *mode)
   530  {
   531  struct tc_data *tc = bridge_to_tc(bridge);
   532  
   533  /*
   534   * Maximum pixel clock speed 135MHz for single-link
   535   * 270MHz for dual-link
   536   */
   537  if ((mode->clock > 135000 && tc->dual_link) ||
   538  (mode->clock > 27 && tc->dual_link))
   539  return MODE_CLOCK_HIGH;
   540  
   541  return MODE_OK;
   542  }
   543  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

Hi,

On 02/07/2020 16:15, Daniel Vetter wrote:
> On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong  wrote:
>>
>> On 02/07/2020 15:18, Daniel Vetter wrote:
>>> On Thu, Jul 02, 2020 at 09:23:11AM +, Simon Ser wrote:
 On Thursday, July 2, 2020 9:47 AM, Neil Armstrong 
  wrote:

> Finally is also adds the Scatter Memory layout, meaning the header 
> contains IOMMU
> references to the compressed frames content to optimize memory access
> and layout.
>
> In this mode, only the header memory address is needed, thus the content
> memory organization is tied to the current producer execution and cannot
> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> modifier.

 Still not sure how to handle this one, since this breaks fundamental
 assumptions about modifiers.
>>>
>>> I wonder whether we should require special allocations for these, and then
>>> just outright reject mmap on these buffers. mmap on dma-buf isn't a
>>> required feature.
>>
>> Yes, it's the plan to reject mmap on these buffers, but it can't be explained
>> in the modifiers description and it's a requirement of the producer, not the
>> consumer.
> 
> Hm I think worth to add that as a note to the modifier. Just to make
> sure. And avoids questions like the one from Simon.

Something like:

 /*
  * Amlogic FBC Scatter Memory layout
  *
  * Indicates the header contains IOMMU references to the compressed
  * frames content to optimize memory access and layout.
  *
  * In this mode, only the header memory address is needed, thus the
  * content memory organization is tied to the current producer
  * execution and cannot be saved/dumped neither transferrable between
  * Amlogic SoCs supporting this modifier.
+ *
+ * Due to the nature of the layout, these buffers are not expected to
+ * be accessible by the user-space clients but only accessible by the
+ * hardware producers and consumers.
+ *
+ * The user-space clients should expect a failure while trying to mmap
+ * the DMA-BUF handle returned by the producer.
  */

Thanks,
Neil

> -Daniel
> 
>>
>>>
>>> That would make sure that userspace cannot look at them.
>>>
>>> Also I'm kinda suspecting that there's not unlimited amounts of this magic
>>> invisible storage available anyway.
>>> -Daniel
>>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support

2020-07-02 Thread Christian König


Am 02.07.20 um 15:29 schrieb Jason Gunthorpe:

On Thu, Jul 02, 2020 at 03:10:00PM +0200, Daniel Vetter wrote:

On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:

On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:

All you need is the ability to stop wait for ongoing accesses to end and
make sure that new ones grab a new mapping.

Swap and flush isn't a general HW ability either..

I'm unclear how this could be useful, it is guarenteed to corrupt
in-progress writes?

Did you mean pause, swap and resume? That's ODP.

Yes, something like this. And good to know, never heard of ODP.

Hm I thought ODP was full hw page faults at an individual page
level,

Yes


and this stop is for the entire nic. Under the hood both apply
back-pressure on the network if a transmission can't be received,
but

NIC's don't do stop and resume, blocking the Rx pipe is very
problematic and performance destroying.

The strategy for something like ODP is more complex, and so far no NIC
has deployed it at any granularity larger than per-page.


So since Jason really doesn't like dma_fence much I think for rdma
synchronous it is. And it shouldn't really matter, since waiting for a
small transaction to complete at rdma wire speed isn't really that
long an operation.

Even if DMA fence were to somehow be involved, how would it look?

Well above you're saying it would be performance destroying, but let's
pretend that's not a problem :-) Also, I have no clue about rdma, so this
is really just the flow we have on the gpu side.

I see, no, this is not workable, the command flow in RDMA is not at
all like GPU - what you are a proposing is a global 'stop the whole
chip' Tx and Rx flows for an undetermined time. Not feasible

What we can do is use ODP techniques and pause only the MR attached to
the DMA buf with the process you outline below. This is not so hard to
implement.


Well it boils down to only two requirements:

1. You can stop accessing the memory or addresses exported by the DMA-buf.

2. Before the next access you need to acquire a new mapping.

How you do this is perfectly up to you. E.g. you can stop everything, 
just prevent access to this DMA-buf, or just pause the users of this 
DMA-buf





3. rdma driver worker gets busy to restart rx:
1. lock all dma-buf that are currently in use (dma_resv_lock).
thanks to ww_mutex deadlock avoidance this is possible

Why all? Why not just lock the one that was invalidated to restore the
mappings? That is some artifact of the GPU approach?


No, but you must make sure that mapping one doesn't invalidate others 
you need.


Otherwise you can end up in a nice live lock :)


And why is this done with work queues and locking instead of a
callback saying the buffer is valid again?


You can do this as well, but a work queue is usually easier to handle 
than a notification in an interrupt context of a foreign driver.


Regards,
Christian.



Jason


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v7 15/17] drm/mst: Add support for QUERY_STREAM_ENCRYPTION_STATUS MST sideband message

2020-07-02 Thread Anshuman Gupta

On 2020-06-30 at 12:48:34 -0400, Sean Paul wrote:
> On Tue, Jun 30, 2020 at 10:21 AM Anshuman Gupta
>  wrote:
> >
> > On 2020-06-23 at 21:29:05 +0530, Sean Paul wrote:
> > Hi Sean,
> > I am new to DP MST stuff, I am looking to DP MST spec DP v1.2a.
> > I have looked the entire series, i will take up this opportunity to review
> > the series from HDCP over DP MST POV.
> > I think theoretically this series should work or Gen12 as well, as DP MST 
> > streams
> > are getting encrypted by QUERY_STREAM_ENCRYPTION_STATUS reply tranaction msg
> > (generating Stream State Signature L’).
> > I will test this on Gen12 H/W with DP MST support and will provide my 
> > inputs.
> >
> > Meanwhile while going through DP MST v1.2a specs(Page 262) came to know 
> > about
> > a DP irq vector LINK_SERVICE_IRQ_VECTOR_ESI0 (02005h),
> > Bit 2 : STREAM_STATUS_CHANGED.
> > When this bit set to ‘1’ indicates the source must re-check the Stream 
> > Status
> > with the QUERY_STREAM_ENCRYPTION_STATUS message.
> > Currently i feel this irq support is missing, do we require to support
> > above IRQ vector for DP MST stream encryption.
> >
> 
> Hi Anshuman,
> Thank you for your comments.
> 
> QUERY_STREAM_ENCRYPTION_STATUS is not necessary for HDCP 1.x, I added
> this as a safety check to ensure that the streams were being
> encrypted. As such, the existing integrity checks in place for DP are
> sufficient to satisfy spec. When HDCP 2.2 support is added for MST,
> handling QSES will need to be addressed to meet spec. Note also that
> we're not validating the QSES signature for the same reason.
Thanks sean for the explanation,
overall patch looks good to me but i have couple of doubt see below.
> 
> Sean
> 
> 
> > Thanks,
> > Anshuman Gupta.
> >
> > > From: Sean Paul 
> > >
> > > Used to query whether an MST stream is encrypted or not.
> > >
> > > Signed-off-by: Sean Paul 
> > >
> > > Link: 
> > > https://patchwork.freedesktop.org/patch/msgid/20200218220242.107265-14-s...@poorly.run
> > >  #v4
> > > Link: 
> > > https://patchwork.freedesktop.org/patch/msgid/20200305201236.152307-15-s...@poorly.run
> > >  #v5
> > > Link: 
> > > https://patchwork.freedesktop.org/patch/msgid/20200429195502.39919-15-s...@poorly.run
> > >  #v6
> > >
> > > Changes in v4:
> > > -Added to the set
> > > Changes in v5:
> > > -None
> > > Changes in v6:
> > > -Use FIELD_PREP to generate request buffer bitfields (Lyude)
> > > -Add mst selftest and dump/decode_sideband_req for QSES (Lyude)
> > > Changes in v7:
> > > -None
> > > ---
> > >  drivers/gpu/drm/drm_dp_mst_topology.c | 142 ++
> > >  .../drm/selftests/test-drm_dp_mst_helper.c|  17 +++
> > >  include/drm/drm_dp_helper.h   |   3 +
> > >  include/drm/drm_dp_mst_helper.h   |  44 ++
> > >  4 files changed, 206 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > index b2f5a84b4cfb..fc68478eaeb4 100644
> > > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > @@ -20,11 +20,13 @@
> > >   * OF THIS SOFTWARE.
> > >   */
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -419,6 +421,22 @@ drm_dp_encode_sideband_req(const struct 
> > > drm_dp_sideband_msg_req_body *req,
> > >   memcpy([idx], req->u.i2c_write.bytes, 
> > > req->u.i2c_write.num_bytes);
> > >   idx += req->u.i2c_write.num_bytes;
> > >   break;
> > > + case DP_QUERY_STREAM_ENC_STATUS: {
> > > + const struct drm_dp_query_stream_enc_status *msg;
> > > +
> > > + msg = >u.enc_status;
> > > + buf[idx] = msg->stream_id;
> > > + idx++;
> > > + memcpy([idx], msg->client_id, sizeof(msg->client_id));
> > > + idx += sizeof(msg->client_id);
> > > + buf[idx] = 0;
> > > + buf[idx] |= FIELD_PREP(GENMASK(1, 0), msg->stream_event);
> > > + buf[idx] |= msg->valid_stream_event ? BIT(2) : 0;
> > > + buf[idx] |= FIELD_PREP(GENMASK(4, 3), msg->stream_behavior);
> > > + buf[idx] |= msg->valid_stream_behavior ? BIT(5) : 0;
> > > + idx++;
> > > + }
> > > + break;
> > >   }
> > >   raw->cur_len = idx;
> > >  }
> > > @@ -547,6 +565,20 @@ drm_dp_decode_sideband_req(const struct 
> > > drm_dp_sideband_msg_tx *raw,
> > >   return -ENOMEM;
> > >   }
> > >   break;
> > > + case DP_QUERY_STREAM_ENC_STATUS:
> > > + req->u.enc_status.stream_id = buf[idx++];
> > > + for (i = 0; i < sizeof(req->u.enc_status.client_id); i++)
> > > + req->u.enc_status.client_id[i] = buf[idx++];
> > > +
> > > + req->u.enc_status.stream_event = FIELD_GET(GENMASK(1, 0),
> > > +

Re: [Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index

2020-07-02 Thread Ville Syrjälä

On Tue, Jun 30, 2020 at 11:42:36PM +, Souza, Jose wrote:
> On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> > for iterating through multiple ext blocks of the same type by
> > passing the starting ext block index to drm_find_edid_extension(). Well
> > also have drm_find_edid_extension() update the index to point to the
> > next ext block on success. Thus we should be able to call
> > drm_find_edid_extension() in loop.
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 30 +-
> >  1 file changed, 21 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index d8372d63851b..f2531d51dfa2 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3188,7 +3188,8 @@ add_detailed_modes(struct drm_connector *connector, 
> > struct edid *edid,
> >  /*
> >   * Search EDID for CEA extension block.
> >   */
> > -static u8 *drm_find_edid_extension(const struct edid *edid, int ext_id)
> > +static u8 *drm_find_edid_extension(const struct edid *edid,
> > +  int ext_id, int *ext_index)
> >  {
> > u8 *edid_ext = NULL;
> > int i;
> > @@ -3198,23 +3199,26 @@ static u8 *drm_find_edid_extension(const struct 
> > edid *edid, int ext_id)
> > return NULL;
> >  
> > /* Find CEA extension */
> > -   for (i = 0; i < edid->extensions; i++) {
> > +   for (i = *ext_index; i < edid->extensions; i++) {
> > edid_ext = (u8 *)edid + EDID_LENGTH * (i + 1);
> > if (edid_ext[0] == ext_id)
> > break;
> > }
> >  
> > -   if (i == edid->extensions)
> > +   if (i >= edid->extensions)
> > return NULL;
> >  
> > +   *ext_index = i + 1;
> > +
> > return edid_ext;
> >  }
> >  
> 
> I would add something like drm_find_edid_n_extension() with the 
> implementation above and then implement drm_find_edid_extension() calling
> drm_find_edid_n_extension() but it is just one caller that is not using 
> ext_index so LGTM.
> 
> >  
> >  static u8 *drm_find_displayid_extension(const struct edid *edid,
> > -   int *length, int *idx)
> > +   int *length, int *idx,
> > +   int *ext_index)
> >  {
> > -   u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT);
> > +   u8 *displayid = drm_find_edid_extension(edid, DISPLAYID_EXT, ext_index);
> > struct displayid_hdr *base;
> > int ret;
> >  
> > @@ -3241,14 +3245,18 @@ static u8 *drm_find_cea_extension(const struct edid 
> > *edid)
> > struct displayid_block *block;
> > u8 *cea;
> > u8 *displayid;
> > +   int ext_index;
> >  
> > /* Look for a top level CEA extension block */
> > -   cea = drm_find_edid_extension(edid, CEA_EXT);
> > +   ext_index = 0;
> 
> In 2 places ext_index is initialized in the variable declaration and in 2 
> other places is not, all of it could be done in the declaration

No, in this case we need to reset it back to 0 when the start looking
for the DispID ext block (as opposed to the CEA ext block). So I figured
it's cleaner if both initialize it to 0 the same way. All the other
places need just the one initialization.

Eventually I think I'd like some kind of for_each_ext_block() to make
this stuff less crap...

> or if you
> really want to leave the context close to the users, initialize it in the 
> "for (;;)" in the next patch.
> 
> With the change above:
> 
> Reviewed-by: José Roberto de Souza 
> 
> > +   cea = drm_find_edid_extension(edid, CEA_EXT, _index);
> > if (cea)
> > return cea;
> >  
> > /* CEA blocks can also be found embedded in a DisplayID block */
> > -   displayid = drm_find_displayid_extension(edid, , );
> > +   ext_index = 0;
> > +   displayid = drm_find_displayid_extension(edid, , ,
> > +_index);
> > if (!displayid)
> > return NULL;
> >  
> > @@ -5195,8 +5203,10 @@ static int add_displayid_detailed_modes(struct 
> > drm_connector *connector,
> > int length, idx;
> > struct displayid_block *block;
> > int num_modes = 0;
> > +   int ext_index = 0;
> >  
> > -   displayid = drm_find_displayid_extension(edid, , );
> > +   displayid = drm_find_displayid_extension(edid, , ,
> > +_index);
> > if (!displayid)
> > return 0;
> >  
> > @@ -5870,11 +5880,13 @@ void drm_update_tile_info(struct drm_connector 
> > *connector,
> >   const struct edid *edid)
> >  {
> > const void *displayid = NULL;
> > +   int ext_index = 0;
> > int length, idx;
> > int ret;
> >  
> > connector->has_tile = false;
> > -   displayid = drm_find_displayid_extension(edid, , );
> > +   displayid = drm_find_displayid_extension(edid,

Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs

On 02.07.2020 14:33, Georgi Djakov wrote:
> On 7/2/20 15:01, Sylwester Nawrocki wrote:
>> On 01.07.2020 14:50, Georgi Djakov wrote:
>>> On 5/29/20 19:31, Sylwester Nawrocki wrote:

 +static int exynos_generic_icc_remove(struct platform_device *pdev)
 +{
 +  struct exynos_icc_priv *priv = platform_get_drvdata(pdev);
 +  struct icc_node *parent_node, *node = priv->node;
 +
 +  parent_node = exynos_icc_get_parent(priv->dev->parent->of_node);
 +  if (parent_node && !IS_ERR(parent_node))
>>>
>>> Nit: !IS_ERR_OR_NULL?
>>
>> It was left on purpose that way but I changed it now to IS_ERR_OR_NULL.
> 
> Well, i have no strong opinion on that, it's up to you.

I will leave it as you suggested, otherwise we are likely to see
"clean up" patches sooner or later.
 
 +  icc_link_destroy(node, parent_node);
 +
 +  icc_nodes_remove(>provider);
 +  icc_provider_del(>provider);
 +
 +  return 0;
 +}
 +
 +static int exynos_generic_icc_probe(struct platform_device *pdev)
 +{
 +  struct device *bus_dev = pdev->dev.parent;
 +  struct exynos_icc_priv *priv;
 +  struct icc_provider *provider;
 +  struct icc_node *icc_node, *icc_parent_node;
 +  int ret;
 +
 +  priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
 +  if (!priv)
 +  return -ENOMEM;
 +
 +  priv->dev = >dev;
 +  platform_set_drvdata(pdev, priv);
 +
 +  provider = >provider;
 +
 +  provider->set = exynos_generic_icc_set;
 +  provider->aggregate = icc_std_aggregate;
 +  provider->xlate = exynos_generic_icc_xlate;
 +  provider->dev = bus_dev;
 +  provider->inter_set = true;
 +  provider->data = priv;
 +
 +  ret = icc_provider_add(provider);
>>>
>>> Nit: Maybe it would be better to move this after the node is created. The
>>> idea is to create the nodes first and add the provider when the topology is
>>> populated. It's fine either way here, but i am planning to change this in
>>> some of the existing provider drivers.
>>
>> OK, it makes the clean up path a bit less straightforward. And still we need 
>> to register the provider before calling icc_node_add().
>> I made a change as below.
>>
>> --8<--
>> @@ -124,14 +123,14 @@ static int exynos_generic_icc_probe(struct 
>> platform_device *pdev)
>>  provider->inter_set = true;
>>  provider->data = priv;
>>  
>> +icc_node = icc_node_create(pdev->id);
>> +if (IS_ERR(icc_node))
>> +return PTR_ERR(icc_node);
>> +
>>  ret = icc_provider_add(provider);
>> -if (ret < 0)
>> +if (ret < 0) {
>> +icc_node_destroy(icc_node->id);
>>  return ret;
>> -
>> -icc_node = icc_node_create(pdev->id);
>> -if (IS_ERR(icc_node)) {
>> -ret = PTR_ERR(icc_node);
>> -goto err_prov_del;
>>  }
>>  
>>  priv->node = icc_node;
>> @@ -171,9 +170,7 @@ static int exynos_generic_icc_probe(struct 
>> platform_device *pdev)
>>  icc_link_destroy(icc_node, icc_parent_node);
>>  err_node_del:
>>  icc_nodes_remove(provider);
>> -err_prov_del:
>>  icc_provider_del(provider);
>> -
>>  return ret;
>>  }
>> --8<--
> 
> Actually i need to post some patches first, so maybe keep it as is for now and
> we will update it afterwards. Sorry for the confusion.

OK, anyway this helped me to remove a memory leak, which was there since
icc_nodes_remove() was used before a call to icc_node_add() in order 
to free the node allocated with icc_node_create(), instead of 
icc_node_destroy().

>>> All looks good to me, but it seems that the patch-set is not on
>>> Rob's radar currently, so please re-send and CC the DT mailing list.
>>
>> Thanks, indeed I missed some mailing list when posting. I will make sure
>> Rob and DT ML list is on Cc, especially that I have added new "bus-width" 
>> property in v6.
> 
> Ok, good. I have been thinking about bus-width and we might want to make it
> even a generic DT property if there are multiple platforms which want to
> use it - maybe if the bus-width is the same across the whole interconnect
> provider. But as most of the existing drivers have different bus-widths, i
> haven't done it yet, but let's see and start a discussion.

I see, it sounds good to me. Having an array property to allow specifying
bus width for each node is probably not so good idea.

-- 
Regards,
Sylwester
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/bridge: adv7511: Fix cec clock EPROBE_DEFER handling

2020-07-02 Thread Andrzej Hajda



On 14.05.2020 13:30, Vincent Whitchurch wrote:
> If adv7511's devm_clk_get() for the cec clock returns -EPROBE_DEFER, we
> end up in an infinite probe loop.  This happens:
>
>   (1) adv7511's probe is called.
>
>   (2) adv7511's probe adds some secondary i2c devices which bind to the
>   dummy driver and thus call driver_deferred_probe_trigger() and
>   increment deferred_trigger_count (see driver_bound()).
>
>   (3) adv7511's probe returns -EPROBE_DEFER, and since the
>   deferred_trigger_count has changed during the probe call,
>   driver_deferred_probe_trigger() is called immediately (see
>   really_probe()) and adv7511's probe is scheduled.
>
>   (4) Goto step 1.
>
> [   61.972915] really_probe: bus: 'i2c': really_probe: probing driver adv7511 
> with device 0-0039
> [   61.992734] really_probe: bus: 'i2c': really_probe: probing driver dummy 
> with device 0-003f
> [   61.993343] driver_bound: driver: 'dummy': driver_bound: bound to device 
> '0-003f'
> [   61.993626] really_probe: bus: 'i2c': really_probe: bound device 0-003f to 
> driver dummy
> [   61.995604] really_probe: bus: 'i2c': really_probe: probing driver dummy 
> with device 0-0038
> [   61.996381] driver_bound: driver: 'dummy': driver_bound: bound to device 
> '0-0038'
> [   61.996663] really_probe: bus: 'i2c': really_probe: bound device 0-0038 to 
> driver dummy
> [   61.998651] really_probe: bus: 'i2c': really_probe: probing driver dummy 
> with device 0-003c
> [   61.999222] driver_bound: driver: 'dummy': driver_bound: bound to device 
> '0-003c'
> [   61.999496] really_probe: bus: 'i2c': really_probe: bound device 0-003c to 
> driver dummy
> [   62.010050] really_probe: i2c 0-0039: Driver adv7511 requests probe 
> deferral
> [   62.011380] really_probe: bus: 'platform': really_probe: probing driver 
> pwm-clock with device clock-cec
> [   62.012812] really_probe: platform clock-cec: Driver pwm-clock requests 
> probe deferral
> [   62.024679] really_probe: bus: 'i2c': really_probe: probing driver adv7511 
> with device 0-0039
>
> Fix this by calling devm_clk_get() before registering the secondary
> devices.
>
> Signed-off-by: Vincent Whitchurch 
> ---
> v3: Make adv7511_cec_init() return void.
> v2: Add devm_clk_put() in error path.
>
>   drivers/gpu/drm/bridge/adv7511/adv7511.h |  5 ++-
>   drivers/gpu/drm/bridge/adv7511/adv7511_cec.c | 34 
>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 ++---
>   3 files changed, 25 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> index a9bb734366ae..05a66149b186 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
> @@ -380,17 +380,16 @@ struct adv7511 {
>   };
>   
>   #ifdef CONFIG_DRM_I2C_ADV7511_CEC
> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
> +void adv7511_cec_init(struct device *dev, struct adv7511 *adv7511);
>   void adv7511_cec_irq_process(struct adv7511 *adv7511, unsigned int irq1);
>   #else
> -static inline int adv7511_cec_init(struct device *dev, struct adv7511 
> *adv7511)
> +static inline void adv7511_cec_init(struct device *dev, struct adv7511 
> *adv7511)
>   {
>   unsigned int offset = adv7511->type == ADV7533 ?
>   ADV7533_REG_CEC_OFFSET : 0;
>   
>   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
>ADV7511_CEC_CTRL_POWER_DOWN);
> - return 0;
>   }
>   #endif
>   
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> index a20a45c0b353..ee0ed4fb67c1 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> @@ -286,28 +286,17 @@ static const struct cec_adap_ops adv7511_cec_adap_ops = 
> {
>   .adap_transmit = adv7511_cec_adap_transmit,
>   };
>   
> -static int adv7511_cec_parse_dt(struct device *dev, struct adv7511 *adv7511)
> -{
> - adv7511->cec_clk = devm_clk_get(dev, "cec");
> - if (IS_ERR(adv7511->cec_clk)) {
> - int ret = PTR_ERR(adv7511->cec_clk);
> -
> - adv7511->cec_clk = NULL;
> - return ret;
> - }
> - clk_prepare_enable(adv7511->cec_clk);
> - adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
> - return 0;
> -}
> -
> -int adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
> +void adv7511_cec_init(struct device *dev, struct adv7511 *adv7511)
>   {
>   unsigned int offset = adv7511->type == ADV7533 ?
>   ADV7533_REG_CEC_OFFSET : 0;
> - int ret = adv7511_cec_parse_dt(dev, adv7511);
> + int ret;
>   
> - if (ret)
> - goto err_cec_parse_dt;
> + if (!adv7511->cec_clk)
> + goto err_cec_no_clock;
> +
> + clk_prepare_enable(adv7511->cec_clk);
> + adv7511->cec_clk_freq = clk_get_rate(adv7511->cec_clk);
>   
>

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

On Thu, Jul 2, 2020 at 3:34 PM Neil Armstrong  wrote:
>
> On 02/07/2020 15:18, Daniel Vetter wrote:
> > On Thu, Jul 02, 2020 at 09:23:11AM +, Simon Ser wrote:
> >> On Thursday, July 2, 2020 9:47 AM, Neil Armstrong 
> >>  wrote:
> >>
> >>> Finally is also adds the Scatter Memory layout, meaning the header 
> >>> contains IOMMU
> >>> references to the compressed frames content to optimize memory access
> >>> and layout.
> >>>
> >>> In this mode, only the header memory address is needed, thus the content
> >>> memory organization is tied to the current producer execution and cannot
> >>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> >>> modifier.
> >>
> >> Still not sure how to handle this one, since this breaks fundamental
> >> assumptions about modifiers.
> >
> > I wonder whether we should require special allocations for these, and then
> > just outright reject mmap on these buffers. mmap on dma-buf isn't a
> > required feature.
>
> Yes, it's the plan to reject mmap on these buffers, but it can't be explained
> in the modifiers description and it's a requirement of the producer, not the
> consumer.

Hm I think worth to add that as a note to the modifier. Just to make
sure. And avoids questions like the one from Simon.
-Daniel

>
> >
> > That would make sure that userspace cannot look at them.
> >
> > Also I'm kinda suspecting that there's not unlimited amounts of this magic
> > invisible storage available anyway.
> > -Daniel
> >
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/hisilicon: Use drmm_kzalloc() instead of devm_kzalloc()

Hi Daniel

Am 02.07.20 um 15:16 schrieb Daniel Vetter:
> On Thu, Jul 02, 2020 at 09:21:54AM +0800, Tian Tao wrote:
>> using the new API drmm_kzalloc() instead of devm_kzalloc()
>>
>> Signed-off-by: Tian Tao 
>> ---
>>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index a6fd0c2..2f20704 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -23,6 +23,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "hibmc_drm_drv.h"
>>  #include "hibmc_drm_regs.h"
>> @@ -267,7 +268,7 @@ static int hibmc_load(struct drm_device *dev)
>>  struct hibmc_drm_private *priv;
>>  int ret;
>>  
>> -priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
>> +priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> 
> Hm would be nice if hisilicon could entirely switch over to embedding, and
> stop using the driver private pointer. Quite a bit more work though. As-is
> this change here isn't really brining you closer to that, pretty much all
> the lifetime bugs around hotunload are still there.

Well, it's a first step. The follow-up patch for embedding connector and
encoder removes more instances of devm_kzalloc().

Although I have to say, I'd rather review a longer patch series that
fully addresses the problem, instead the current one-by-one approach.

Best regards
Thomas

> -Daniel
> 
>>  if (!priv) {
>>  DRM_ERROR("no memory to allocate for hibmc_drm_private\n");
>>  return -ENOMEM;
>> -- 
>> 2.7.4
>>
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 2/5] driver core: add deferring probe reason to devices_deferred property

2020-07-02 Thread Andrzej Hajda

/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is dev_err_probe function introduced
recently, ie. if dev_err_probe will be called with -EPROBE_DEFER instead of
printk the message will be attached to a deferred device and printed when user
reads devices_deferred property.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Mark Brown 
Reviewed-by: Javier Martinez Canillas 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Rafael J. Wysocki 
---
v8:
- improved commit message
---
 drivers/base/base.h |  3 +++
 drivers/base/core.c |  8 ++--
 drivers/base/dd.c   | 23 ++-
 3 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..6954fccab3d7 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -93,6 +93,7 @@ struct device_private {
struct klist_node knode_class;
struct list_head deferred_probe;
struct device_driver *async_driver;
+   char *deferred_probe_reason;
struct device *device;
u8 dead:1;
 };
@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct device 
*dev,
 extern void driver_detach(struct device_driver *drv);
 extern int driver_probe_device(struct device_driver *drv, struct device *dev);
 extern void driver_deferred_probe_del(struct device *dev);
+extern void device_set_deferred_probe_reson(const struct device *dev,
+   struct va_format *vaf);
 static inline int driver_match_device(struct device_driver *drv,
  struct device *dev)
 {
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3a827c82933f..fee047f03681 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
  * This helper implements common pattern present in probe functions for error
  * checking: print debug or error message depending if the error value is
  * -EPROBE_DEFER and propagate error upwards.
+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
+ * checked later by reading devices_deferred debugfs attribute.
  * It replaces code sequence:
  * if (err != -EPROBE_DEFER)
  * dev_err(dev, ...);
@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err, 
const char *fmt, ...)
vaf.fmt = fmt;
vaf.va = 
 
-   if (err != -EPROBE_DEFER)
+   if (err != -EPROBE_DEFER) {
dev_err(dev, "error %d: %pV", err, );
-   else
+   } else {
+   device_set_deferred_probe_reson(dev, );
dev_dbg(dev, "error %d: %pV", err, );
+   }
 
va_end(args);
 
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..dd5683b61f74 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "base.h"
 #include "power/power.h"
@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
if (!list_empty(>p->deferred_probe)) {
dev_dbg(dev, "Removed from deferred list\n");
list_del_init(>p->deferred_probe);
+   kfree(dev->p->deferred_probe_reason);
+   dev->p->deferred_probe_reason = NULL;
}
mutex_unlock(_probe_mutex);
 }
@@ -211,6 +214,23 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
 }
 
+/**
+ * device_set_deferred_probe_reson() - Set defer probe reason message for 
device
+ * @dev: the pointer to the struct device
+ * @vaf: the pointer to va_format structure with message
+ */
+void device_set_deferred_probe_reson(const struct device *dev, struct 
va_format *vaf)
+{
+   const char *drv = dev_driver_string(dev);
+
+   mutex_lock(_probe_mutex);
+
+   kfree(dev->p->deferred_probe_reason);
+   dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv, 
vaf);
+
+   mutex_unlock(_probe_mutex);
+}
+
 /*
  * deferred_devs_show() - Show the devices in the deferred probe pending list.
  */
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, void 
*data)
mutex_lock(_probe_mutex);
 
list_for_each_entry(curr, _probe_pending_list, deferred_probe)
-   seq_printf(s, "%s\n", dev_name(curr->device));
+   seq_printf(s, "%s\t%s", dev_name(curr->device),
+  curr->device->p->deferred_probe_reason ?: "\n");
 
mutex_unlock(_probe_mutex);
 
-- 
2.17.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

On 02/07/2020 15:18, Daniel Vetter wrote:
> On Thu, Jul 02, 2020 at 09:23:11AM +, Simon Ser wrote:
>> On Thursday, July 2, 2020 9:47 AM, Neil Armstrong  
>> wrote:
>>
>>> Finally is also adds the Scatter Memory layout, meaning the header contains 
>>> IOMMU
>>> references to the compressed frames content to optimize memory access
>>> and layout.
>>>
>>> In this mode, only the header memory address is needed, thus the content
>>> memory organization is tied to the current producer execution and cannot
>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
>>> modifier.
>>
>> Still not sure how to handle this one, since this breaks fundamental
>> assumptions about modifiers.
> 
> I wonder whether we should require special allocations for these, and then
> just outright reject mmap on these buffers. mmap on dma-buf isn't a
> required feature.

Yes, it's the plan to reject mmap on these buffers, but it can't be explained
in the modifiers description and it's a requirement of the producer, not the
consumer.

> 
> That would make sure that userspace cannot look at them.
> 
> Also I'm kinda suspecting that there's not unlimited amounts of this magic
> invisible storage available anyway.
> -Daniel
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

On Thu, Jul 02, 2020 at 09:23:11AM +, Simon Ser wrote:
> On Thursday, July 2, 2020 9:47 AM, Neil Armstrong  
> wrote:
> 
> > Finally is also adds the Scatter Memory layout, meaning the header contains 
> > IOMMU
> > references to the compressed frames content to optimize memory access
> > and layout.
> >
> > In this mode, only the header memory address is needed, thus the content
> > memory organization is tied to the current producer execution and cannot
> > be saved/dumped neither transferrable between Amlogic SoCs supporting this
> > modifier.
> 
> Still not sure how to handle this one, since this breaks fundamental
> assumptions about modifiers.

I wonder whether we should require special allocations for these, and then
just outright reject mmap on these buffers. mmap on dma-buf isn't a
required feature.

That would make sure that userspace cannot look at them.

Also I'm kinda suspecting that there's not unlimited amounts of this magic
invisible storage available anyway.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/hisilicon: Use drmm_kzalloc() instead of devm_kzalloc()

On Thu, Jul 02, 2020 at 09:21:54AM +0800, Tian Tao wrote:
> using the new API drmm_kzalloc() instead of devm_kzalloc()
> 
> Signed-off-by: Tian Tao 
> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index a6fd0c2..2f20704 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "hibmc_drm_drv.h"
>  #include "hibmc_drm_regs.h"
> @@ -267,7 +268,7 @@ static int hibmc_load(struct drm_device *dev)
>   struct hibmc_drm_private *priv;
>   int ret;
>  
> - priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
> + priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);

Hm would be nice if hisilicon could entirely switch over to embedding, and
stop using the driver private pointer. Quite a bit more work though. As-is
this change here isn't really brining you closer to that, pretty much all
the lifetime bugs around hotunload are still there.
-Daniel

>   if (!priv) {
>   DRM_ERROR("no memory to allocate for hibmc_drm_private\n");
>   return -ENOMEM;
> -- 
> 2.7.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vkms: add wait_for_vblanks in atomic_commit_tail

On Wed, Jul 01, 2020 at 03:31:34PM +, Sidong Yang wrote:
> there is an error when igt test is run continuously. vkms_atomic_commit_tail()
> need to call drm_atomic_helper_wait_for_vblanks() for give up ownership of
> vblank events. without this code, next atomic commit will not enable vblank
> and raise timeout error.
> 
> Signed-off-by: Sidong Yang 
> ---
>  drivers/gpu/drm/vkms/vkms_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
> index 1e8b2169d834..10b9be67a068 100644
> --- a/drivers/gpu/drm/vkms/vkms_drv.c
> +++ b/drivers/gpu/drm/vkms/vkms_drv.c
> @@ -93,6 +93,8 @@ static void vkms_atomic_commit_tail(struct drm_atomic_state 
> *old_state)
>   flush_work(_state->composer_work);
>   }
>  
> + drm_atomic_helper_wait_for_vblanks(dev, old_state);

Uh, we have a wait_for_flip_done right above, which should be doing
exactly the same, but more precisely: Instead of just waiting for any
vblank to happen, we wait for exactly the vblank corresponding to this
atomic commit. So no races possible. If this is papering over some issue,
then I think more debugging is needed.

What exactly is going wrong here for you?
-Daniel

> +
>   drm_atomic_helper_cleanup_planes(dev, old_state);
>  }
>  
> -- 
> 2.17.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support

On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:
> > > >> All you need is the ability to stop wait for ongoing accesses to end 
> > > >> and
> > > >> make sure that new ones grab a new mapping.
> > > > Swap and flush isn't a general HW ability either..
> > > >
> > > > I'm unclear how this could be useful, it is guarenteed to corrupt
> > > > in-progress writes?
> > > >
> > > > Did you mean pause, swap and resume? That's ODP.
> > >
> > > Yes, something like this. And good to know, never heard of ODP.
> > 
> > Hm I thought ODP was full hw page faults at an individual page
> > level,
> 
> Yes
> 
> > and this stop is for the entire nic. Under the hood both apply
> > back-pressure on the network if a transmission can't be received,
> > but
> 
> NIC's don't do stop and resume, blocking the Rx pipe is very
> problematic and performance destroying.
> 
> The strategy for something like ODP is more complex, and so far no NIC
> has deployed it at any granularity larger than per-page.
> 
> > So since Jason really doesn't like dma_fence much I think for rdma
> > synchronous it is. And it shouldn't really matter, since waiting for a
> > small transaction to complete at rdma wire speed isn't really that
> > long an operation. 
> 
> Even if DMA fence were to somehow be involved, how would it look?

Well above you're saying it would be performance destroying, but let's
pretend that's not a problem :-) Also, I have no clue about rdma, so this
is really just the flow we have on the gpu side.

0. rdma driver maintains a list of all dma-buf that it has mapped
somewhere and is currently using for transactions

1. rdma driver gets a dma_buf->notify_move callback on one of these
buffers. To handle that it:
1. stops hw access somehow at the rx
2. flushes caches and whatever else is needed
3. moves the unmapped buffer on a special list or marks it in some
different way as unavailable
4. launch the kthread/work_struct to fix everything back up

2. dma-buf export (gpu driver) can now issue the commands to move the
buffer around

3. rdma driver worker gets busy to restart rx:
1. lock all dma-buf that are currently in use (dma_resv_lock).
thanks to ww_mutex deadlock avoidance this is possible
2. for any buffers which have been marked as unavailable in 1.3
grab a new mapping (which might now be in system memory, or again
peer2peer but different address)
3. restart hw and rx
4. unlock all dma-buf locks (dma_resv_unlock)

There is a minor problem because step 2 only queues up the entire buffer
moves behind a pile of dma_fence, and atm we haven't made it absolutely
clear who's responsible for waiting for those to complete. For gpu drivers
it's the importer since gpu drivers don't have big qualms about
dma_fences, so 3.2. would perhaps also include a dma_fence_wait to make
sure the buffer move has actually completed.

Above flow is more or less exactly what happens for gpu workloads where we
can preempt running computations. Instead of stopping rx we preempt the
compute job and remove it from the scheduler queues, and instead of
restarting rx we just put the compute job back onto the scheduler queue as
eligible for gpu time. Otherwise it's exactly the same stuff.

Of course if you only have a single compute job and too many such
interruptions, then performance is going to tank. Don't do that, instead
make sure you have enough vram or system memory or whatever :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/2] dma-buf: fix dma-fence-chain out of order test

2020-07-02 Thread Christian König

Am 25.06.20 um 15:59 schrieb Daniel Vetter:

On Thu, Jun 25, 2020 at 3:23 PM Lionel Landwerlin
wrote:

On 25/06/2020 16:18, Chris Wilson wrote:

Quoting Lionel Landwerlin (2020-06-25 13:34:43)

There was probably a misunderstand on how the dma-fence-chain is
supposed to work or what dma_fence_chain_find_seqno() is supposed to
return.

dma_fence_chain_find_seqno() is here to give us the fence to wait upon
for a particular point in the timeline. The timeline progresses only
when all the points prior to a given number have completed.

Hmm, the question was what point is it supposed to wait for.

For the simple chain of [1, 3], does 1 being signaled imply that all
points up to 3 are signaled, or does 3 not being signaled imply that all
points after 1 are not. If that's mentioned already somewhere, my bad.
If not, could you put the answer somewhere.
-Chris

In [1, 3], if 1 is signaled, the timeline value is 1. And find_seqno(2)
should return NULL.

In the out_of_order selftest the chain was [1, 2, 3], 2 was signaled and
the test was expecting no fence to be returned by find_seqno(2).

But we still have to wait on 1 to complete before find_seqno(2) can
return NULL (as in you don't have to wait on anything).

Hope that answer the question.

I asked Christian to document why timeline works like this, but I
can't find it in the kerneldoc right now. If it's missing I think we
should fix that and add the explanation, iirc it was around gpu reset
creating too much havoc otherwise.

I do remember that I wrote a patch to improve the kerneldoc for timeline
semaphores, but then somebody else came along with an even better
description.

Unfortunately it looks like neither was ever merged.

Need to dig through my mails,
Christian.

-Daniel

-Lionel

___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fintel-gfxdata=02%7C01%7Cchristian.koenig%40amd.com%7Cfd87640cd9bd422971bf08d8191004d2%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637286903879074805sdata=M3WGWbuyQKZeGC0J3wEKtgQ1oKYo6GOAMvKU2mU3r%2FM%3Dreserved=0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: repair runtime power management

2020-07-02 Thread Philippe CORNU



On 2/29/20 11:16 PM, Marek Vasut wrote:
> Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to
> match pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise
> the LTDC might suspend via runtime PM, disable clock, and then fail
> to resume later on.
> 
> The test which triggers it is roughly -- run qt5 application which
> uses eglfs platform and etnaviv, stop the application, sleep for 15
> minutes, run the application again. This leads to a timeout waiting
> for vsync, because the LTDC has suspended, but did not resume.
> 
> Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management")
> Signed-off-by: Marek Vasut 
> Cc: Yannick Fertré 
> Cc: Philippe Cornu 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Maxime Coquelin 
> Cc: Alexandre Torgue 
> To: dri-devel@lists.freedesktop.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Cc: linux-arm-ker...@lists.infradead.org
> ---
> [ cut here ]
> WARNING: CPU: 0 PID: 297 at drivers/gpu/drm/drm_atomic_helper.c:1494 
> drm_atomic_helper_wait_for_vblanks+0x1dc/0x200
> [CRTC:35:crtc-0] vblank wait timed out
> Modules linked in:
> CPU: 0 PID: 297 Comm: QSGRenderThread Not tainted 
> 5.6.0-rc3-next-20200228-00010-g318bf0fc08ef #2
> Hardware name: STM32 (Device Tree Support)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb4/0xd0)
> [] (dump_stack) from [] (__warn+0xd4/0xf0)
> [] (__warn) from [] (warn_slowpath_fmt+0x78/0xa8)
> [] (warn_slowpath_fmt) from [] 
> (drm_atomic_helper_wait_for_vblanks+0x1dc/0x200)
> [] (drm_atomic_helper_wait_for_vblanks) from [] 
> (drm_atomic_helper_commit_tail+0
> x50/0x60)
> [] (drm_atomic_helper_commit_tail) from [] 
> (commit_tail+0x12c/0x13c)
> [] (commit_tail) from [] 
> (drm_atomic_helper_commit+0xf4/0x100)
> [] (drm_atomic_helper_commit) from [] 
> (drm_atomic_helper_set_config+0x58/0x6c)
> [] (drm_atomic_helper_set_config) from [] 
> (drm_mode_setcrtc+0x450/0x550)
> [] (drm_mode_setcrtc) from [] (drm_ioctl_kernel+0x90/0xe8)
> [] (drm_ioctl_kernel) from [] (drm_ioctl+0x2e4/0x32c)
> [] (drm_ioctl) from [] (vfs_ioctl+0x20/0x38)
> [] (vfs_ioctl) from [] (ksys_ioctl+0xbc/0x7b0)
> [] (ksys_ioctl) from [] (ret_fast_syscall+0x0/0x54)
> Exception stack(0xee8f3fa8 to 0xee8f3ff0)
> 3fa0:   0005 adcbeb18 0005 c06864a2 adcbeb18 0001
> 3fc0: 0005 adcbeb18 c06864a2 0036 0029 0023 0023 0007
> 3fe0: b113b098 adcbeafc b1125413 b6155cf8
> ---[ end trace 2ad5ba954ceb767a ]---
> ---
>   drivers/gpu/drm/stm/ltdc.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 99bf93e8b36f..301de0498078 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -425,9 +425,12 @@ static void ltdc_crtc_atomic_enable(struct drm_crtc 
> *crtc,
>   struct drm_crtc_state *old_state)
>   {
>   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> + struct drm_device *ddev = crtc->dev;
>   
>   DRM_DEBUG_DRIVER("\n");
>   
> + pm_runtime_get_sync(ddev->dev);
> +
>   /* Sets the background color value */
>   reg_write(ldev->regs, LTDC_BCCR, BCCR_BCBLACK);
>   
> 
Hi Marek,
Many thanks for your patch,
Acked-by: Philippe Cornu 
Tested-by: Yannick Fertre 


Hi Benjamin,
Could you please apply "drm/stm: ltdc: remove call of pm-runtime 
functions" **before** this one. Thank you.

Philippe :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: ltdc: remove call of pm-runtime functions

2020-07-02 Thread Philippe CORNU




On 7/1/20 2:04 PM, Yannick Fertre wrote:
> It is not necessary to suspend or stop the ltdc clocks
> to modify the pixel clock.
> 
> Signed-off-by: Yannick Fertre 
> ---
>   drivers/gpu/drm/stm/ltdc.c | 16 
>   1 file changed, 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 3f590d916e91..6e28f707092f 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -506,15 +506,7 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
>struct drm_display_mode *adjusted_mode)
>   {
>   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
> - struct drm_device *ddev = crtc->dev;
>   int rate = mode->clock * 1000;
> - bool runtime_active;
> - int ret;
> -
> - runtime_active = pm_runtime_active(ddev->dev);
> -
> - if (runtime_active)
> - pm_runtime_put_sync(ddev->dev);
>   
>   if (clk_set_rate(ldev->pixel_clk, rate) < 0) {
>   DRM_ERROR("Cannot set rate (%dHz) for pixel clk\n", rate);
> @@ -523,14 +515,6 @@ static bool ltdc_crtc_mode_fixup(struct drm_crtc *crtc,
>   
>   adjusted_mode->clock = clk_get_rate(ldev->pixel_clk) / 1000;
>   
> - if (runtime_active) {
> - ret = pm_runtime_get_sync(ddev->dev);
> - if (ret) {
> - DRM_ERROR("Failed to fixup mode, cannot get sync\n");
> - return false;
> - }
> - }
> -
>   DRM_DEBUG_DRIVER("requested clock %dkHz, adjusted clock %dkHz\n",
>mode->clock, adjusted_mode->clock);
>   
> 
Hi Yannick,
Many thanks for your patch,
Acked-by: Philippe Cornu 
Philippe :-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC] Host1x/TegraDRM UAPI (sync points)

2020-07-02 Thread Mikko Perttunen


On 7/1/20 3:22 AM, Dmitry Osipenko wrote:

30.06.2020 13:26, Mikko Perttunen пишет:

On 6/29/20 10:42 PM, Dmitry Osipenko wrote:


Secondly, I suppose neither GPU, nor DLA could wait on a host1x sync
point, correct? Or are they integrated with Host1x HW?



They can access syncpoints directly. (That's what I alluded to in the
"Introduction to the hardware" section :) all those things have hardware
access to syncpoints)


Should we CC all the Nouveau developers then, or is it a bit too early? :)


I think we have a few other issues still to resolve before that :)





.. rest ..



Let me try to summarize once more for my own understanding:

* When submitting a job, you would allocate new syncpoints for the job


- Yes


* After submitting the job, those syncpoints are not usable anymore


- Yes

Although, thinking a bit more about it, this needs to be relaxed.

It should be a userspace agreement/policy how to utilize sync points.

For example, if we know that userspace will have multiple application
instances all using Tegra DRM UAPI, like a mesa or VDPAU drivers, then
this userspace should consider to return sync points into the pool for
sharing them with others. While something like an Opentegra Xorg driver,
which usually has a single instance, could keep sync points pre-allocated.

The job's sync point counter will be reset to 0 by the kernel driver
during of the submission process for each job, so we won't have the sync
point recovery problem.


* Postfences of that job would keep references to those syncpoints so
they aren't freed and cleared before the fences have been released


- No

I suggested that fence shouldn't refcount the sync point and *only* have
a reference to it, this reference will be invalidated once fence is
signaled by sync point reaching the threshold or once sync point is
released.

The sync point will have a reference to every active fence (waiting for
the signal) that is using this sync point until the threshold is reached.

So fence could detach itself from the sync point + sync point could
detach all the fences from itself.

There will be more about this below, please see example with a dead
process in the end of this email.


* Once postfences have been released, syncpoints would be returned to
the pool and reset to zero


- No

I'm suggesting that sync point should be returned to the pool once its
usage refcount reaches 0. This means that both userspace that created
this sync point + the executed job will both keep the sync point alive
until it is closed by userspace + job is completed.


The advantage of this would be that at any point in time, there would be
a 1:1 correspondence between allocated syncpoints and jobs; so you could
  shuffle the jobs around channels or reorder them.


- Yes


Please correct if I got that wrong :)

---

I have two concerns:

* A lot of churn on syncpoints - any time you submit a job you might not
get a syncpoint for an indefinite time. If we allocate syncpoints
up-front at least you know beforehand, and then you have the syncpoint
as long as you need it.


If you'll have a lot of active application instances all allocating sync
points, then inevitably the sync points pool will be exhausted.

But my proposal doesn't differ from yours in this regards, correct?

And maybe there is a nice solution, please see more below!


* Plumbing the dma-fence/sync_file everywhere, and keeping it alive
until waits on it have completed, is more work than just having the
ID/threshold. This is probably mainly a problem for downstream, where
updating code for this would be difficult. I know that's not a proper
argument but I hope we can reach something that works for both worlds.


You could have ID/threshold! :)

But, you can't use the *job's* ID/threshold because you won't know them
until kernel driver scheduler will *complete(!)* the job's execution!
The job may be re-pushed multiple times by the scheduler to recovered
channel if a previous jobs hang!

Now, you could allocate *two* sync points:

   1. For the job itself (job's sync point).

   2. For the userspace to wait (user's sync point).

The job will have to increment both these sync points (example of
multiple sync points usage) and you know the user's sync point ID/threshold!

If job times out, you *could* increment the user's sync point on CPU
from userspace!

The counter of the user's sync point won't be touched by the kernel
driver if job hangs!


Ok, so we would have two kinds of syncpoints for the job; one for kernel 
job tracking; and one that userspace can manipulate as it wants to.


Could we handle the job tracking syncpoint completely inside the kernel, 
i.e. allocate it in kernel during job submission, and add an increment 
for it at the end of the job (with condition OP_DONE)? For MLOCKing, the 
kernel already needs to insert a SYNCPT_INCR(OP_DONE) + WAIT + 
MLOCK_RELEASE sequence at the end of each job.





Here's a proposal in between:

* Keep syncpoint allocation and submission in jobs

Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs

Hi Georgi,

On 01.07.2020 14:50, Georgi Djakov wrote:
> Thanks for the patch and apologies for the delayed reply.

Thanks, no problem. It's actually just in time as I put that patchset
aside for a while and was just about to post an update.
 
> On 5/29/20 19:31, Sylwester Nawrocki wrote:
>> This patch adds a generic interconnect driver for Exynos SoCs in order
>> to provide interconnect functionality for each "samsung,exynos-bus"
>> compatible device.
>>
>> The SoC topology is a graph (or more specifically, a tree) and its
>> edges are specified using the 'samsung,interconnect-parent' in the
>> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
>> propagated to ensure that the parent is probed before its children.
>>
>> Each bus is now an interconnect provider and an interconnect node as
>> well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
>> registers itself as a node. Node IDs are not hardcoded but rather
>> assigned dynamically at runtime. This approach allows for using this
>> driver with various Exynos SoCs.
>>
>> Frequencies requested via the interconnect API for a given node are
>> propagated to devfreq using dev_pm_qos_update_request(). Please note
>> that it is not an error when CONFIG_INTERCONNECT is 'n', in which
>> case all interconnect API functions are no-op.
>>
>> Signed-off-by: Artur Świgoń 
>> Signed-off-by: Sylwester Nawrocki 

>> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
>> +{
>> +struct of_phandle_args args;
>> +int num, ret;
>> +
>> +num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
>> +"#interconnect-cells");
>> +if (num != 1)
>> +return NULL; /* parent nodes are optional */
>> +
>> +ret = of_parse_phandle_with_args(np, "samsung,interconnect-parent",
>> +"#interconnect-cells", 0, );
>> +if (ret < 0)
>> +return ERR_PTR(ret);
>> +
>> +of_node_put(args.np);
>> +
>> +return of_icc_get_from_provider();
>> +}
>> +
>> +
> 
> Nit: multiple blank lines

Fixed.

> [..]
>> +static struct icc_node *exynos_generic_icc_xlate(struct of_phandle_args 
>> *spec,
>> + void *data)
>> +{
>> +struct exynos_icc_priv *priv = data;
>> +
>> +if (spec->np != priv->dev->parent->of_node)
>> +return ERR_PTR(-EINVAL);
>> +
>> +return priv->node;
>> +}
>> +
>> +static int exynos_generic_icc_remove(struct platform_device *pdev)
>> +{
>> +struct exynos_icc_priv *priv = platform_get_drvdata(pdev);
>> +struct icc_node *parent_node, *node = priv->node;
>> +
>> +parent_node = exynos_icc_get_parent(priv->dev->parent->of_node);
>> +if (parent_node && !IS_ERR(parent_node))
> 
> Nit: !IS_ERR_OR_NULL?

It was left on purpose that way but I changed it now to IS_ERR_OR_NULL.

>> +icc_link_destroy(node, parent_node);
>> +
>> +icc_nodes_remove(>provider);
>> +icc_provider_del(>provider);
>> +
>> +return 0;
>> +}
>> +
>> +static int exynos_generic_icc_probe(struct platform_device *pdev)
>> +{
>> +struct device *bus_dev = pdev->dev.parent;
>> +struct exynos_icc_priv *priv;
>> +struct icc_provider *provider;
>> +struct icc_node *icc_node, *icc_parent_node;
>> +int ret;
>> +
>> +priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
>> +if (!priv)
>> +return -ENOMEM;
>> +
>> +priv->dev = >dev;
>> +platform_set_drvdata(pdev, priv);
>> +
>> +provider = >provider;
>> +
>> +provider->set = exynos_generic_icc_set;
>> +provider->aggregate = icc_std_aggregate;
>> +provider->xlate = exynos_generic_icc_xlate;
>> +provider->dev = bus_dev;
>> +provider->inter_set = true;
>> +provider->data = priv;
>> +
>> +ret = icc_provider_add(provider);
> 
> Nit: Maybe it would be better to move this after the node is created. The
> idea is to create the nodes first and add the provider when the topology is
> populated. It's fine either way here, but i am planning to change this in
> some of the existing provider drivers.

OK, it makes the clean up path a bit less straightforward. And still we need 
to register the provider before calling icc_node_add().
I made a change as below.

--8<--
@@ -124,14 +123,14 @@ static int exynos_generic_icc_probe(struct 
platform_device *pdev)
provider->inter_set = true;
provider->data = priv;
 
+   icc_node = icc_node_create(pdev->id);
+   if (IS_ERR(icc_node))
+   return PTR_ERR(icc_node);
+
ret = icc_provider_add(provider);
-   if (ret < 0)
+   if (ret < 0) {
+   icc_node_destroy(icc_node->id);
return ret;
-
-   icc_node = icc_node_create(pdev->id);
-   if (IS_ERR(icc_node)) {
-   ret = PTR_ERR(icc_node);
-   goto err_prov_del;
}
 
priv->node = icc_node;
@@ -171,9 +170,7 @@

[PATCH v2 04/14] drm/ast: Update cursor image and checksum from same function

Cursor image and checksum go hand in hand. Update both in the same
place. The helper cannot fail, so remove the return type.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 24 +---
 1 file changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 8f94d4712f66..7474baddf048 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -84,7 +84,7 @@ void ast_cursor_fini(struct ast_private *ast)
}
 }
 
-static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
+static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int 
height)
 {
union {
u32 ul;
@@ -96,7 +96,8 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int 
height)
} data16;
u32 csum = 0;
s32 alpha_dst_delta, last_alpha_dst_delta;
-   u8 *srcxor, *dstxor;
+   u8 __iomem *dstxor;
+   const u8 *srcxor;
int i, j;
u32 per_pixel_copy, two_pixel_copy;
 
@@ -137,16 +138,6 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width, 
int height)
}
dstxor += last_alpha_dst_delta;
}
-   return csum;
-}
-
-static int ast_cursor_update(void *dst, void *src, unsigned int width,
-unsigned int height)
-{
-   u32 csum;
-
-   /* do data transfer to cursor cache */
-   csum = copy_cursor_image(src, dst, width, height);
 
/* write checksum + signature */
dst += AST_HWC_SIZE;
@@ -155,8 +146,6 @@ static int ast_cursor_update(void *dst, void *src, unsigned 
int width,
writel(height, dst + AST_HWC_SIGNATURE_SizeY);
writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTX);
writel(0, dst + AST_HWC_SIGNATURE_HOTSPOTY);
-
-   return 0;
 }
 
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
@@ -188,9 +177,8 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
goto err_drm_gem_vram_vunmap_src;
}
 
-   ret = ast_cursor_update(dst, src, fb->width, fb->height);
-   if (ret)
-   goto err_drm_gem_vram_vunmap_dst;
+   /* do data transfer to cursor BO */
+   update_cursor_image(dst, src, fb->width, fb->height);
 
/*
 * Always unmap buffers here. Destination buffers are
@@ -203,8 +191,6 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
 
return 0;
 
-err_drm_gem_vram_vunmap_dst:
-   drm_gem_vram_vunmap(ast->cursor.gbo[ast->cursor.next_index], dst);
 err_drm_gem_vram_vunmap_src:
drm_gem_vram_vunmap(gbo, src);
 err_drm_gem_vram_unpin:
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 12/14] drm/ast: Replace struct ast_crtc with struct drm_crtc

Struct ast_crtc has been cleaned up and it's now a wrapper around the
DRM CRTC structure struct drm_crtc. This patch converts the driver to
struct drm_crtc and removes struct ast_crtc.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  |  5 -
 drivers/gpu/drm/ast/ast_mode.c | 11 ++-
 2 files changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index ea4de3dce2c4..77226e2fd7c0 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -238,11 +238,6 @@ struct ast_connector {
struct ast_i2c_chan *i2c;
 };
 
-struct ast_crtc {
-   struct drm_crtc base;
-};
-
-#define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
 #define to_ast_connector(x) container_of(x, struct ast_connector, base)
 
 struct ast_vbios_stdtable {
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 89d9ee0a9e81..43c9686ba0f7 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -881,21 +881,22 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
 static int ast_crtc_init(struct drm_device *dev)
 {
struct ast_private *ast = to_ast_private(dev);
-   struct ast_crtc *crtc;
+   struct drm_crtc *crtc;
int ret;
 
-   crtc = kzalloc(sizeof(struct ast_crtc), GFP_KERNEL);
+   crtc = kzalloc(sizeof(*crtc), GFP_KERNEL);
if (!crtc)
return -ENOMEM;
 
-   ret = drm_crtc_init_with_planes(dev, >base, >primary_plane,
+   ret = drm_crtc_init_with_planes(dev, crtc, >primary_plane,
>cursor_plane, _crtc_funcs,
NULL);
if (ret)
goto err_kfree;
 
-   drm_mode_crtc_set_gamma_size(>base, 256);
-   drm_crtc_helper_add(>base, _crtc_helper_funcs);
+   drm_mode_crtc_set_gamma_size(crtc, 256);
+   drm_crtc_helper_add(crtc, _crtc_helper_funcs);
+
return 0;
 
 err_kfree:
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 10/14] drm/ast: Managed cursor release

Register a release function to finalize cursors. The _fini() function
gets un-exported from the source file.

The function ast_mode_fini() is now empty and will be removed by a
later patch.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 38 ++--
 drivers/gpu/drm/ast/ast_drv.h|  1 -
 drivers/gpu/drm/ast/ast_mode.c   |  3 ---
 3 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 35680402e410..acf0d23514e8 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -28,9 +28,30 @@
  */
 
 #include 
+#include 
 
 #include "ast_drv.h"
 
+static void ast_cursor_fini(struct ast_private *ast)
+{
+   size_t i;
+   struct drm_gem_vram_object *gbo;
+
+   for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+   gbo = ast->cursor.gbo[i];
+   drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
+   drm_gem_vram_unpin(gbo);
+   drm_gem_vram_put(gbo);
+   }
+}
+
+static void ast_cursor_release(struct drm_device *dev, void *ptr)
+{
+   struct ast_private *ast = dev->dev_private;
+
+   ast_cursor_fini(ast);
+}
+
 /*
  * Allocate cursor BOs and pins them at the end of VRAM.
  */
@@ -68,7 +89,7 @@ int ast_cursor_init(struct ast_private *ast)
ast->cursor.vaddr[i] = vaddr;
}
 
-   return 0;
+   return drmm_add_action_or_reset(dev, ast_cursor_release, NULL);
 
 err_drm_gem_vram_put:
while (i) {
@@ -77,25 +98,10 @@ int ast_cursor_init(struct ast_private *ast)
drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
-   ast->cursor.gbo[i] = NULL;
-   ast->cursor.vaddr[i] = NULL;
}
return ret;
 }
 
-void ast_cursor_fini(struct ast_private *ast)
-{
-   size_t i;
-   struct drm_gem_vram_object *gbo;
-
-   for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
-   gbo = ast->cursor.gbo[i];
-   drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
-   drm_gem_vram_unpin(gbo);
-   drm_gem_vram_put(gbo);
-   }
-}
-
 static void update_cursor_image(u8 __iomem *dst, const u8 *src, int width, int 
height)
 {
union {
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index f465e0c0984b..ea4de3dce2c4 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -317,7 +317,6 @@ void ast_release_firmware(struct drm_device *dev);
 
 /* ast_cursor.c */
 int ast_cursor_init(struct ast_private *ast);
-void ast_cursor_fini(struct ast_private *ast);
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
 void ast_cursor_page_flip(struct ast_private *ast);
 void ast_cursor_show(struct ast_private *ast, int x, int y,
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 8fdc46401814..4724a38c001a 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1108,9 +1108,6 @@ int ast_mode_init(struct drm_device *dev)
 
 void ast_mode_fini(struct drm_device *dev)
 {
-   struct ast_private *ast = to_ast_private(dev);
-
-   ast_cursor_fini(ast);
 }
 
 static int get_clock(void *i2c_priv)
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 08/14] drm/ast: Add helper to hide cursor

As the inverse to ast_cursor_show(), ast_cursor_hide() disables the
HW cursor.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 5 +
 drivers/gpu/drm/ast/ast_drv.h| 1 +
 drivers/gpu/drm/ast/ast_mode.c   | 2 +-
 3 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 8f8fdc831830..5421241015d6 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -284,3 +284,8 @@ int ast_cursor_show(struct ast_private *ast, int x, int y,
 
return 0;
 }
+
+void ast_cursor_hide(struct ast_private *ast)
+{
+   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, 0x00);
+}
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index b00091798ef5..92af0637ac48 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -321,5 +321,6 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb);
 void ast_cursor_page_flip(struct ast_private *ast);
 int ast_cursor_show(struct ast_private *ast, int x, int y,
unsigned int offset_x, unsigned int offset_y);
+void ast_cursor_hide(struct ast_private *ast);
 
 #endif
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 5c41a91f5630..8fdc46401814 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -683,7 +683,7 @@ ast_cursor_plane_helper_atomic_disable(struct drm_plane 
*plane,
 {
struct ast_private *ast = to_ast_private(plane->dev);
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, 0x00);
+   ast_cursor_hide(ast);
 }
 
 static const struct drm_plane_helper_funcs ast_cursor_plane_helper_funcs = {
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 00/14] drm/ast: Managed modesetting

This is the first patchset to convert ast to use managed interfaces. These
patches address modesetting. I expect that there will be at least one more
set of patches for memory management and one for device structures.

Patches 1 to 11 tackle HW cursor handling. The overall point is to get
cursor support out of the plane functions and put the code into helpers.
There are quite a few improvements that make cursors easier and faster to
use. Patch 10 converts cursors to managed release.

With cursors out of the way, modesetting initialization is much more
simple. Patches 12 to 14 put all related code next to each other and
switch to managed initialization.

The patchset was tested on AST2100 hardware.

v2:
* use to_ast_private() instead of
  struct drm_device.dev_private (Sam)

Thomas Zimmermann (14):
  drm/ast: Move cursor functions to ast_cursor.c
  drm/ast: Pass struct ast_private instance to cursor init/fini
functions
  drm/ast: Move cursor fb pinning and mapping into helper
  drm/ast: Update cursor image and checksum from same function
  drm/ast: Move cursor pageflip into helper
  drm/ast: Replace ast_cursor_move() with ast_cursor_show()
  drm/ast: Don't enable HW cursors twice during atomic update
  drm/ast: Add helper to hide cursor
  drm/ast: Keep cursor HW BOs mapped
  drm/ast: Managed cursor release
  drm/ast: Init cursors before creating modesetting structures
  drm/ast: Replace struct ast_crtc with struct drm_crtc
  drm/ast: Use managed mode-config init
  drm/ast: Initialize mode setting in ast_mode_config_init()

 drivers/gpu/drm/ast/Makefile |   3 +-
 drivers/gpu/drm/ast/ast_cursor.c | 289 +++
 drivers/gpu/drm/ast/ast_drv.h|  19 +-
 drivers/gpu/drm/ast/ast_main.c   |  35 +---
 drivers/gpu/drm/ast/ast_mode.c   | 322 ++-
 5 files changed, 359 insertions(+), 309 deletions(-)
 create mode 100644 drivers/gpu/drm/ast/ast_cursor.c

--
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 13/14] drm/ast: Use managed mode-config init

Using drmm_mode_config_init() sets up managed release of modesetting
resources. The existing modesetting's finalizer is empty, so remove it.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  | 1 -
 drivers/gpu/drm/ast/ast_main.c | 6 +++---
 drivers/gpu/drm/ast/ast_mode.c | 4 
 3 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 77226e2fd7c0..ad1d0b14ef12 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -287,7 +287,6 @@ struct ast_crtc_state {
 #define to_ast_crtc_state(state) container_of(state, struct ast_crtc_state, 
base)
 
 extern int ast_mode_init(struct drm_device *dev);
-extern void ast_mode_fini(struct drm_device *dev);
 
 #define AST_MM_ALIGN_SHIFT 4
 #define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 2eab19a9056f..2642e6d0152b 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -473,7 +473,9 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
if (ret)
goto out_free;
 
-   drm_mode_config_init(dev);
+   ret = drmm_mode_config_init(dev);
+   if (ret)
+   goto out_free;
 
dev->mode_config.funcs = (void *)_mode_funcs;
dev->mode_config.min_width = 0;
@@ -516,8 +518,6 @@ void ast_driver_unload(struct drm_device *dev)
 
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
-   ast_mode_fini(dev);
-   drm_mode_config_cleanup(dev);
 
ast_mm_fini(ast);
kfree(ast);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 43c9686ba0f7..33b4b6f3e394 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1110,10 +1110,6 @@ int ast_mode_init(struct drm_device *dev)
return 0;
 }
 
-void ast_mode_fini(struct drm_device *dev)
-{
-}
-
 static int get_clock(void *i2c_priv)
 {
struct ast_i2c_chan *i2c = i2c_priv;
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 14/14] drm/ast: Initialize mode setting in ast_mode_config_init()

There's modesetting init code in ast_main.c. Move it to ast_mode.c and
merge it with the modesetting init code in ast_mode_init(). The result
is ast_mode_config_init(), which initalizes the whole modesetting.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.h  |  2 +-
 drivers/gpu/drm/ast/ast_main.c | 35 +
 drivers/gpu/drm/ast/ast_mode.c | 41 --
 3 files changed, 41 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index ad1d0b14ef12..c8c442e9efdc 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -286,7 +286,7 @@ struct ast_crtc_state {
 
 #define to_ast_crtc_state(state) container_of(state, struct ast_crtc_state, 
base)
 
-extern int ast_mode_init(struct drm_device *dev);
+int ast_mode_config_init(struct ast_private *ast);
 
 #define AST_MM_ALIGN_SHIFT 4
 #define AST_MM_ALIGN_MASK ((1 << AST_MM_ALIGN_SHIFT) - 1)
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 2642e6d0152b..860a43a64b31 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "ast_drv.h"
@@ -379,13 +378,6 @@ static int ast_get_dram_info(struct drm_device *dev)
return 0;
 }
 
-static const struct drm_mode_config_funcs ast_mode_funcs = {
-   .fb_create = drm_gem_fb_create,
-   .mode_valid = drm_vram_helper_mode_valid,
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
-};
-
 static u32 ast_get_vram_info(struct drm_device *dev)
 {
struct ast_private *ast = to_ast_private(dev);
@@ -473,35 +465,10 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
if (ret)
goto out_free;
 
-   ret = drmm_mode_config_init(dev);
-   if (ret)
-   goto out_free;
-
-   dev->mode_config.funcs = (void *)_mode_funcs;
-   dev->mode_config.min_width = 0;
-   dev->mode_config.min_height = 0;
-   dev->mode_config.preferred_depth = 24;
-   dev->mode_config.prefer_shadow = 1;
-   dev->mode_config.fb_base = pci_resource_start(ast->dev->pdev, 0);
-
-   if (ast->chip == AST2100 ||
-   ast->chip == AST2200 ||
-   ast->chip == AST2300 ||
-   ast->chip == AST2400 ||
-   ast->chip == AST2500) {
-   dev->mode_config.max_width = 1920;
-   dev->mode_config.max_height = 2048;
-   } else {
-   dev->mode_config.max_width = 1600;
-   dev->mode_config.max_height = 1200;
-   }
-
-   ret = ast_mode_init(dev);
+   ret = ast_mode_config_init(ast);
if (ret)
goto out_free;
 
-   drm_mode_config_reset(dev);
-
return 0;
 out_free:
kfree(ast);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 33b4b6f3e394..154cd877d9d1 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1069,15 +1070,49 @@ static int ast_connector_init(struct drm_device *dev)
return 0;
 }
 
-int ast_mode_init(struct drm_device *dev)
+/*
+ * Mode config
+ */
+
+static const struct drm_mode_config_funcs ast_mode_config_funcs = {
+   .fb_create = drm_gem_fb_create,
+   .mode_valid = drm_vram_helper_mode_valid,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+int ast_mode_config_init(struct ast_private *ast)
 {
-   struct ast_private *ast = to_ast_private(dev);
+   struct drm_device *dev = ast->dev;
int ret;
 
ret = ast_cursor_init(ast);
if (ret)
return ret;
 
+   ret = drmm_mode_config_init(dev);
+   if (ret)
+   return ret;
+
+   dev->mode_config.funcs = _mode_config_funcs;
+   dev->mode_config.min_width = 0;
+   dev->mode_config.min_height = 0;
+   dev->mode_config.preferred_depth = 24;
+   dev->mode_config.prefer_shadow = 1;
+   dev->mode_config.fb_base = pci_resource_start(ast->dev->pdev, 0);
+
+   if (ast->chip == AST2100 ||
+   ast->chip == AST2200 ||
+   ast->chip == AST2300 ||
+   ast->chip == AST2400 ||
+   ast->chip == AST2500) {
+   dev->mode_config.max_width = 1920;
+   dev->mode_config.max_height = 2048;
+   } else {
+   dev->mode_config.max_width = 1600;
+   dev->mode_config.max_height = 1200;
+   }
+
memset(>primary_plane, 0, sizeof(ast->primary_plane));
ret = drm_universal_plane_init(dev, >primary_plane, 0x01,
   _primary_plane_funcs,
@@ -1107,6 +1142,8 @@ int ast_mode_init(struct drm_device *dev)
ast_encoder_init(dev);

[PATCH v2 11/14] drm/ast: Init cursors before creating modesetting structures

The cursor helpers reserve buffer objects in VRAM and update their
content. So although tied to modesetting, cursor helpers are more
of a memory manager. The modesetting's cursor plane requires this
functionality, so initialize cursors before modesetting.

While at it, also add an error check for ast_cursor_init().

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_mode.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 4724a38c001a..89d9ee0a9e81 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1073,6 +1073,10 @@ int ast_mode_init(struct drm_device *dev)
struct ast_private *ast = to_ast_private(dev);
int ret;
 
+   ret = ast_cursor_init(ast);
+   if (ret)
+   return ret;
+
memset(>primary_plane, 0, sizeof(ast->primary_plane));
ret = drm_universal_plane_init(dev, >primary_plane, 0x01,
   _primary_plane_funcs,
@@ -1098,7 +1102,6 @@ int ast_mode_init(struct drm_device *dev)
drm_plane_helper_add(>cursor_plane,
 _cursor_plane_helper_funcs);
 
-   ast_cursor_init(ast);
ast_crtc_init(dev);
ast_encoder_init(dev);
ast_connector_init(dev);
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 09/14] drm/ast: Keep cursor HW BOs mapped

Updating the image in a cursor's HW BO requires a mapping of the BO's
buffer in the kernel's address space. Cursor image updates can happen
frequently and create CPU overhead.

As cursor HW BOs are small and never move, they are now map exactly
once during the initialization and the mapping is used throughout the
driver's lifetime.

This change also removes a possible source of failures from
ast_cursor_show(). As the helper does not establish mappings, it cannot
fail. As a result, the cursor plane's atomic-update helper does not
call any failable interfaces. All failures are detected before trying
to update the cursor plane.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 44 +---
 drivers/gpu/drm/ast/ast_drv.h|  5 ++--
 2 files changed, 21 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 5421241015d6..35680402e410 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -39,6 +39,7 @@ int ast_cursor_init(struct ast_private *ast)
struct drm_device *dev = ast->dev;
size_t size, i;
struct drm_gem_vram_object *gbo;
+   void __iomem *vaddr;
int ret;
 
size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
@@ -55,8 +56,16 @@ int ast_cursor_init(struct ast_private *ast)
drm_gem_vram_put(gbo);
goto err_drm_gem_vram_put;
}
+   vaddr = drm_gem_vram_vmap(gbo);
+   if (IS_ERR(vaddr)) {
+   ret = PTR_ERR(vaddr);
+   drm_gem_vram_unpin(gbo);
+   drm_gem_vram_put(gbo);
+   goto err_drm_gem_vram_put;
+   }
 
ast->cursor.gbo[i] = gbo;
+   ast->cursor.vaddr[i] = vaddr;
}
 
return 0;
@@ -65,9 +74,11 @@ int ast_cursor_init(struct ast_private *ast)
while (i) {
--i;
gbo = ast->cursor.gbo[i];
+   drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
ast->cursor.gbo[i] = NULL;
+   ast->cursor.vaddr[i] = NULL;
}
return ret;
 }
@@ -79,6 +90,7 @@ void ast_cursor_fini(struct ast_private *ast)
 
for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
gbo = ast->cursor.gbo[i];
+   drm_gem_vram_vunmap(gbo, ast->cursor.vaddr[i]);
drm_gem_vram_unpin(gbo);
drm_gem_vram_put(gbo);
}
@@ -154,7 +166,7 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
struct drm_gem_vram_object *gbo;
int ret;
void *src;
-   void *dst;
+   void __iomem *dst;
 
if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
@@ -171,28 +183,16 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
goto err_drm_gem_vram_unpin;
}
 
-   dst = drm_gem_vram_vmap(ast->cursor.gbo[ast->cursor.next_index]);
-   if (IS_ERR(dst)) {
-   ret = PTR_ERR(dst);
-   goto err_drm_gem_vram_vunmap_src;
-   }
+   dst = ast->cursor.vaddr[ast->cursor.next_index];
 
/* do data transfer to cursor BO */
update_cursor_image(dst, src, fb->width, fb->height);
 
-   /*
-* Always unmap buffers here. Destination buffers are
-* perma-pinned while the driver is active. We're only
-* changing ref-counters here.
-*/
-   drm_gem_vram_vunmap(ast->cursor.gbo[ast->cursor.next_index], dst);
drm_gem_vram_vunmap(gbo, src);
drm_gem_vram_unpin(gbo);
 
return 0;
 
-err_drm_gem_vram_vunmap_src:
-   drm_gem_vram_vunmap(gbo, src);
 err_drm_gem_vram_unpin:
drm_gem_vram_unpin(gbo);
return ret;
@@ -243,18 +243,14 @@ static void ast_cursor_set_location(struct ast_private 
*ast, u16 x, u16 y,
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
 }
 
-int ast_cursor_show(struct ast_private *ast, int x, int y,
-   unsigned int offset_x, unsigned int offset_y)
+void ast_cursor_show(struct ast_private *ast, int x, int y,
+unsigned int offset_x, unsigned int offset_y)
 {
-   struct drm_gem_vram_object *gbo;
u8 x_offset, y_offset;
-   u8 *dst, *sig;
+   u8 __iomem *dst, __iomem *sig;
u8 jreg;
 
-   gbo = ast->cursor.gbo[ast->cursor.next_index];
-   dst = drm_gem_vram_vmap(gbo);
-   if (IS_ERR(dst))
-   return PTR_ERR(dst);
+   dst = ast->cursor.vaddr[ast->cursor.next_index];
 
sig = dst + AST_HWC_SIZE;
writel(x, sig + AST_HWC_SIGNATURE_X);
@@ -279,10 +275,6 @@ int ast_cursor_show(struct ast_private *ast, int x, int y,
jreg

[PATCH v2 07/14] drm/ast: Don't enable HW cursors twice during atomic update

The ast_cursor_show() helper enables the cursor to be displayed. No need
to repeat that operation in the plane's atomic-update function.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_mode.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index b452f9e28d7c..5c41a91f5630 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -664,7 +664,6 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane 
*plane,
struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = plane->dev->dev_private;
unsigned int offset_x, offset_y;
-   u8 jreg;
 
offset_x = AST_MAX_HWC_WIDTH - fb->width;
offset_y = AST_MAX_HWC_WIDTH - fb->height;
@@ -676,11 +675,6 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane 
*plane,
 
ast_cursor_show(ast, state->crtc_x, state->crtc_y,
offset_x, offset_y);
-
-   jreg = 0x2;
-   /* enable ARGB cursor */
-   jreg |= 1;
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xcb, 0xfc, jreg);
 }
 
 static void
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 02/14] drm/ast: Pass struct ast_private instance to cursor init/fini functions

Removes some typecasting.

v2:
* use to_ast_private() instead of struct drm_device.dev_private

Signed-off-by: Thomas Zimmermann 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/ast/ast_cursor.c | 7 +++
 drivers/gpu/drm/ast/ast_drv.h| 4 ++--
 drivers/gpu/drm/ast/ast_mode.c   | 6 --
 3 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 53bb6eebc7cd..1d4f51a7fe22 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -34,9 +34,9 @@
 /*
  * Allocate cursor BOs and pins them at the end of VRAM.
  */
-int ast_cursor_init(struct drm_device *dev)
+int ast_cursor_init(struct ast_private *ast)
 {
-   struct ast_private *ast = to_ast_private(dev);
+   struct drm_device *dev = ast->dev;
size_t size, i;
struct drm_gem_vram_object *gbo;
int ret;
@@ -72,9 +72,8 @@ int ast_cursor_init(struct drm_device *dev)
return ret;
 }
 
-void ast_cursor_fini(struct drm_device *dev)
+void ast_cursor_fini(struct ast_private *ast)
 {
-   struct ast_private *ast = to_ast_private(dev);
size_t i;
struct drm_gem_vram_object *gbo;
 
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 245ed2e2d775..f7b120f862a8 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -316,8 +316,8 @@ void ast_init_3rdtx(struct drm_device *dev);
 void ast_release_firmware(struct drm_device *dev);
 
 /* ast_cursor.c */
-int ast_cursor_init(struct drm_device *dev);
-void ast_cursor_fini(struct drm_device *dev);
+int ast_cursor_init(struct ast_private *ast);
+void ast_cursor_fini(struct ast_private *ast);
 int ast_cursor_update(void *dst, void *src, unsigned int width,
  unsigned int height);
 void ast_cursor_set_base(struct ast_private *ast, u64 address);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index c8399699d773..e69965f5636d 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1149,7 +1149,7 @@ int ast_mode_init(struct drm_device *dev)
drm_plane_helper_add(>cursor_plane,
 _cursor_plane_helper_funcs);
 
-   ast_cursor_init(dev);
+   ast_cursor_init(ast);
ast_crtc_init(dev);
ast_encoder_init(dev);
ast_connector_init(dev);
@@ -1159,7 +1159,9 @@ int ast_mode_init(struct drm_device *dev)
 
 void ast_mode_fini(struct drm_device *dev)
 {
-   ast_cursor_fini(dev);
+   struct ast_private *ast = to_ast_private(dev);
+
+   ast_cursor_fini(ast);
 }
 
 static int get_clock(void *i2c_priv)
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 05/14] drm/ast: Move cursor pageflip into helper

The new helper ast_cursor_page_flip() switches the cursor's front and
back BOs. This simplifies the cursor plane's update helper.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 20 +++-
 drivers/gpu/drm/ast/ast_drv.h|  2 +-
 drivers/gpu/drm/ast/ast_mode.c   | 12 +---
 3 files changed, 21 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 7474baddf048..815d95b2f392 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -198,7 +198,7 @@ int ast_cursor_blit(struct ast_private *ast, struct 
drm_framebuffer *fb)
return ret;
 }
 
-void ast_cursor_set_base(struct ast_private *ast, u64 address)
+static void ast_cursor_set_base(struct ast_private *ast, u64 address)
 {
u8 addr0 = (address >> 3) & 0xff;
u8 addr1 = (address >> 11) & 0xff;
@@ -209,6 +209,24 @@ void ast_cursor_set_base(struct ast_private *ast, u64 
address)
ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xca, addr2);
 }
 
+void ast_cursor_page_flip(struct ast_private *ast)
+{
+   struct drm_device *dev = ast->dev;
+   struct drm_gem_vram_object *gbo;
+   s64 off;
+
+   gbo = ast->cursor.gbo[ast->cursor.next_index];
+
+   off = drm_gem_vram_offset(gbo);
+   if (drm_WARN_ON_ONCE(dev, off < 0))
+   return; /* Bug: we didn't pin the cursor HW BO to VRAM. */
+
+   ast_cursor_set_base(ast, off);
+
+   ++ast->cursor.next_index;
+   ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
+}
+
 int ast_cursor_move(struct drm_crtc *crtc, int x, int y)
 {
struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 9bc1bb76ec91..e973c1ab96cb 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -319,7 +319,7 @@ void ast_release_firmware(struct drm_device *dev);
 int ast_cursor_init(struct ast_private *ast);
 void ast_cursor_fini(struct ast_private *ast);
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
-void ast_cursor_set_base(struct ast_private *ast, u64 address);
+void ast_cursor_page_flip(struct ast_private *ast);
 int ast_cursor_move(struct drm_crtc *crtc, int x, int y);
 
 #endif
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 701211050832..32365f16c78c 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -660,14 +660,11 @@ static void
 ast_cursor_plane_helper_atomic_update(struct drm_plane *plane,
  struct drm_plane_state *old_state)
 {
-   struct drm_device *dev = plane->dev;
struct drm_plane_state *state = plane->state;
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
struct ast_private *ast = to_ast_private(plane->dev);
struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
-   struct drm_gem_vram_object *gbo;
-   s64 off;
u8 jreg;
 
ast_crtc->offset_x = AST_MAX_HWC_WIDTH - fb->width;
@@ -675,14 +672,7 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane 
*plane,
 
if (state->fb != old_state->fb) {
/* A new cursor image was installed. */
-   gbo = ast->cursor.gbo[ast->cursor.next_index];
-   off = drm_gem_vram_offset(gbo);
-   if (drm_WARN_ON_ONCE(dev, off < 0))
-   return; /* Bug: we didn't pin cursor HW BO to VRAM. */
-   ast_cursor_set_base(ast, off);
-
-   ++ast->cursor.next_index;
-   ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
+   ast_cursor_page_flip(ast);
}
 
ast_cursor_move(crtc, state->crtc_x, state->crtc_y);
-- 
2.27.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 01/14] drm/ast: Move cursor functions to ast_cursor.c

The cursor manipulation functions are unrelated to modesetting. Move
them into their own file.

Signed-off-by: Thomas Zimmermann 
Acked-by: Sam Ravnborg 
---
 drivers/gpu/drm/ast/Makefile |   3 +-
 drivers/gpu/drm/ast/ast_cursor.c | 218 +++
 drivers/gpu/drm/ast/ast_drv.h|   9 ++
 drivers/gpu/drm/ast/ast_mode.c   | 195 ---
 4 files changed, 229 insertions(+), 196 deletions(-)
 create mode 100644 drivers/gpu/drm/ast/ast_cursor.c

diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
index 561f7c4199e4..6a5b3b247316 100644
--- a/drivers/gpu/drm/ast/Makefile
+++ b/drivers/gpu/drm/ast/Makefile
@@ -3,6 +3,7 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-ast-y := ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o ast_dp501.o
+ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o \
+ast_dp501.o
 
 obj-$(CONFIG_DRM_AST) := ast.o
diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
new file mode 100644
index ..53bb6eebc7cd
--- /dev/null
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -0,0 +1,218 @@
+/*
+ * Copyright 2012 Red Hat Inc.
+ * Parts based on xf86-video-ast
+ * Copyright (c) 2005 ASPEED Technology Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ */
+/*
+ * Authors: Dave Airlie 
+ */
+
+#include 
+
+#include "ast_drv.h"
+
+/*
+ * Allocate cursor BOs and pins them at the end of VRAM.
+ */
+int ast_cursor_init(struct drm_device *dev)
+{
+   struct ast_private *ast = to_ast_private(dev);
+   size_t size, i;
+   struct drm_gem_vram_object *gbo;
+   int ret;
+
+   size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
+
+   for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+   gbo = drm_gem_vram_create(dev, size, 0);
+   if (IS_ERR(gbo)) {
+   ret = PTR_ERR(gbo);
+   goto err_drm_gem_vram_put;
+   }
+   ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
+   DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
+   if (ret) {
+   drm_gem_vram_put(gbo);
+   goto err_drm_gem_vram_put;
+   }
+
+   ast->cursor.gbo[i] = gbo;
+   }
+
+   return 0;
+
+err_drm_gem_vram_put:
+   while (i) {
+   --i;
+   gbo = ast->cursor.gbo[i];
+   drm_gem_vram_unpin(gbo);
+   drm_gem_vram_put(gbo);
+   ast->cursor.gbo[i] = NULL;
+   }
+   return ret;
+}
+
+void ast_cursor_fini(struct drm_device *dev)
+{
+   struct ast_private *ast = to_ast_private(dev);
+   size_t i;
+   struct drm_gem_vram_object *gbo;
+
+   for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
+   gbo = ast->cursor.gbo[i];
+   drm_gem_vram_unpin(gbo);
+   drm_gem_vram_put(gbo);
+   }
+}
+
+static u32 copy_cursor_image(u8 *src, u8 *dst, int width, int height)
+{
+   union {
+   u32 ul;
+   u8 b[4];
+   } srcdata32[2], data32;
+   union {
+   u16 us;
+   u8 b[2];
+   } data16;
+   u32 csum = 0;
+   s32 alpha_dst_delta, last_alpha_dst_delta;
+   u8 *srcxor, *dstxor;
+   int i, j;
+   u32 per_pixel_copy, two_pixel_copy;
+
+   alpha_dst_delta = AST_MAX_HWC_WIDTH << 1;
+   last_alpha_dst_delta = alpha_dst_delta - (width << 1);
+
+   srcxor = src;
+   dstxor = (u8 *)dst + last_alpha_dst_delta + (AST_MAX_HWC_HEIGHT - 
height) * alpha_dst_delta;
+   per_pixel_copy = width & 1;
+   two_pixel_copy = width >> 1;
+
+   for (j = 0; j < height; j++) {
+   for (i = 0; i <

[PATCH v2 06/14] drm/ast: Replace ast_cursor_move() with ast_cursor_show()

Having a cursor move function is misleading, as it actually enables the
cursor's image for displaying. So rename it to ast_cursor_show(). It's
semantics is to show a cursor at the specified location on the screen.
The displayed cursor is always the image in the cursor front BO.

This change also simplifies struct ast_crtc to being a mere wrapper around
around struct drm_crtc. It will be removed by a later patch.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 42 
 drivers/gpu/drm/ast/ast_drv.h|  4 +--
 drivers/gpu/drm/ast/ast_mode.c   | 12 -
 3 files changed, 35 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 815d95b2f392..8f8fdc831830 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -227,12 +227,27 @@ void ast_cursor_page_flip(struct ast_private *ast)
ast->cursor.next_index %= ARRAY_SIZE(ast->cursor.gbo);
 }
 
-int ast_cursor_move(struct drm_crtc *crtc, int x, int y)
+static void ast_cursor_set_location(struct ast_private *ast, u16 x, u16 y,
+   u8 x_offset, u8 y_offset)
+{
+   u8 x0 = (x & 0x00ff);
+   u8 x1 = (x & 0x0f00) >> 8;
+   u8 y0 = (y & 0x00ff);
+   u8 y1 = (y & 0x0700) >> 8;
+
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc2, x_offset);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc3, y_offset);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc4, x0);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc5, x1);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc6, y0);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, y1);
+}
+
+int ast_cursor_show(struct ast_private *ast, int x, int y,
+   unsigned int offset_x, unsigned int offset_y)
 {
-   struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
-   struct ast_private *ast = to_ast_private(crtc->dev);
struct drm_gem_vram_object *gbo;
-   int x_offset, y_offset;
+   u8 x_offset, y_offset;
u8 *dst, *sig;
u8 jreg;
 
@@ -245,23 +260,20 @@ int ast_cursor_move(struct drm_crtc *crtc, int x, int y)
writel(x, sig + AST_HWC_SIGNATURE_X);
writel(y, sig + AST_HWC_SIGNATURE_Y);
 
-   x_offset = ast_crtc->offset_x;
-   y_offset = ast_crtc->offset_y;
if (x < 0) {
-   x_offset = (-x) + ast_crtc->offset_x;
+   x_offset = (-x) + offset_x;
x = 0;
+   } else {
+   x_offset = offset_x;
}
-
if (y < 0) {
-   y_offset = (-y) + ast_crtc->offset_y;
+   y_offset = (-y) + offset_y;
y = 0;
+   } else {
+   y_offset = offset_y;
}
-   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc2, x_offset);
-   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc3, y_offset);
-   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc4, (x & 0xff));
-   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc5, ((x >> 8) & 0x0f));
-   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc6, (y & 0xff));
-   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xc7, ((y >> 8) & 0x07));
+
+   ast_cursor_set_location(ast, x, y, x_offset, y_offset);
 
/* dummy write to fire HWC */
jreg = 0x02 |
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index e973c1ab96cb..b00091798ef5 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -239,7 +239,6 @@ struct ast_connector {
 
 struct ast_crtc {
struct drm_crtc base;
-   u8 offset_x, offset_y;
 };
 
 #define to_ast_crtc(x) container_of(x, struct ast_crtc, base)
@@ -320,6 +319,7 @@ int ast_cursor_init(struct ast_private *ast);
 void ast_cursor_fini(struct ast_private *ast);
 int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
 void ast_cursor_page_flip(struct ast_private *ast);
-int ast_cursor_move(struct drm_crtc *crtc, int x, int y);
+int ast_cursor_show(struct ast_private *ast, int x, int y,
+   unsigned int offset_x, unsigned int offset_y);
 
 #endif
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 32365f16c78c..b452f9e28d7c 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -661,21 +661,21 @@ ast_cursor_plane_helper_atomic_update(struct drm_plane 
*plane,
  struct drm_plane_state *old_state)
 {
struct drm_plane_state *state = plane->state;
-   struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
-   struct ast_private *ast = to_ast_private(plane->dev);
-   struct ast_crtc *ast_crtc = to_ast_crtc(crtc);
+   struct ast_private *ast = plane->dev->dev_private;
+   unsigned int offset_x, offset_y;
u8 jreg;
 
-   ast_crtc->offset_x = AST_MAX_HWC_WIDTH - fb->width;
-   ast_crtc->offset_y = AST_MAX_HWC_WIDTH - fb->height;

[PATCH v2 03/14] drm/ast: Move cursor fb pinning and mapping into helper

The new helper ast_cursor_blit() updates a cursor's backbuffer HW
BO from a framebuffer structure. The cursor plane's prepare_fb()
function now uses the new interface.

Pinning and mapping of BOs is done automatically by the helper. This
includes the source BO, which was not pinned by the original code in
prepare_fb().

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_cursor.c | 57 ++--
 drivers/gpu/drm/ast/ast_drv.h|  3 +-
 drivers/gpu/drm/ast/ast_mode.c   | 41 ++-
 3 files changed, 59 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_cursor.c b/drivers/gpu/drm/ast/ast_cursor.c
index 1d4f51a7fe22..8f94d4712f66 100644
--- a/drivers/gpu/drm/ast/ast_cursor.c
+++ b/drivers/gpu/drm/ast/ast_cursor.c
@@ -140,8 +140,8 @@ static u32 copy_cursor_image(u8 *src, u8 *dst, int width, 
int height)
return csum;
 }
 
-int ast_cursor_update(void *dst, void *src, unsigned int width,
- unsigned int height)
+static int ast_cursor_update(void *dst, void *src, unsigned int width,
+unsigned int height)
 {
u32 csum;
 
@@ -159,6 +159,59 @@ int ast_cursor_update(void *dst, void *src, unsigned int 
width,
return 0;
 }
 
+int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb)
+{
+   struct drm_device *dev = ast->dev;
+   struct drm_gem_vram_object *gbo;
+   int ret;
+   void *src;
+   void *dst;
+
+   if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
+   drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
+   return -EINVAL;
+
+   gbo = drm_gem_vram_of_gem(fb->obj[0]);
+
+   ret = drm_gem_vram_pin(gbo, 0);
+   if (ret)
+   return ret;
+   src = drm_gem_vram_vmap(gbo);
+   if (IS_ERR(src)) {
+   ret = PTR_ERR(src);
+   goto err_drm_gem_vram_unpin;
+   }
+
+   dst = drm_gem_vram_vmap(ast->cursor.gbo[ast->cursor.next_index]);
+   if (IS_ERR(dst)) {
+   ret = PTR_ERR(dst);
+   goto err_drm_gem_vram_vunmap_src;
+   }
+
+   ret = ast_cursor_update(dst, src, fb->width, fb->height);
+   if (ret)
+   goto err_drm_gem_vram_vunmap_dst;
+
+   /*
+* Always unmap buffers here. Destination buffers are
+* perma-pinned while the driver is active. We're only
+* changing ref-counters here.
+*/
+   drm_gem_vram_vunmap(ast->cursor.gbo[ast->cursor.next_index], dst);
+   drm_gem_vram_vunmap(gbo, src);
+   drm_gem_vram_unpin(gbo);
+
+   return 0;
+
+err_drm_gem_vram_vunmap_dst:
+   drm_gem_vram_vunmap(ast->cursor.gbo[ast->cursor.next_index], dst);
+err_drm_gem_vram_vunmap_src:
+   drm_gem_vram_vunmap(gbo, src);
+err_drm_gem_vram_unpin:
+   drm_gem_vram_unpin(gbo);
+   return ret;
+}
+
 void ast_cursor_set_base(struct ast_private *ast, u64 address)
 {
u8 addr0 = (address >> 3) & 0xff;
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index f7b120f862a8..9bc1bb76ec91 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -318,8 +318,7 @@ void ast_release_firmware(struct drm_device *dev);
 /* ast_cursor.c */
 int ast_cursor_init(struct ast_private *ast);
 void ast_cursor_fini(struct ast_private *ast);
-int ast_cursor_update(void *dst, void *src, unsigned int width,
- unsigned int height);
+int ast_cursor_blit(struct ast_private *ast, struct drm_framebuffer *fb);
 void ast_cursor_set_base(struct ast_private *ast, u64 address);
 int ast_cursor_move(struct drm_crtc *crtc, int x, int y);
 
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e69965f5636d..701211050832 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -611,56 +611,21 @@ static int
 ast_cursor_plane_helper_prepare_fb(struct drm_plane *plane,
   struct drm_plane_state *new_state)
 {
-   struct drm_device *dev = plane->dev;
struct drm_framebuffer *fb = new_state->fb;
struct drm_crtc *crtc = new_state->crtc;
-   struct drm_gem_vram_object *gbo;
struct ast_private *ast;
int ret;
-   void *src, *dst;
 
if (!crtc || !fb)
return 0;
 
-   if (drm_WARN_ON_ONCE(dev, fb->width > AST_MAX_HWC_WIDTH) ||
-   drm_WARN_ON_ONCE(dev, fb->height > AST_MAX_HWC_HEIGHT))
-   return -EINVAL; /* BUG: didn't test in atomic_check() */
-
-   ast = to_ast_private(dev);
-
-   gbo = drm_gem_vram_of_gem(fb->obj[0]);
-   src = drm_gem_vram_vmap(gbo);
-   if (IS_ERR(src)) {
-   ret = PTR_ERR(src);
-   goto err_drm_gem_vram_unpin;
-   }
-
-   dst = drm_gem_vram_vmap(ast->cursor.gbo[ast->cursor.next_index]);
-   if (IS_ERR(dst)) {
-   ret = PTR_ERR(dst);
-   goto

Re: [PATCH 01/14] drm/ast: Move cursor functions to ast_cursor.c

Hi Sam

Am 24.06.20 um 08:24 schrieb Thomas Zimmermann:
> Hi Sam
> 
> Am 23.06.20 um 18:55 schrieb Sam Ravnborg:
>> Hi Thomas.
>>
>> On Tue, Jun 23, 2020 at 10:18:48AM +0200, Thomas Zimmermann wrote:
>>> The cursor manipulation functions are unrelated to modesetting. Move
>>> them into their own file.
>>>
>>> Signed-off-by: Thomas Zimmermann 
>>> ---
>>>  drivers/gpu/drm/ast/Makefile |   3 +-
>>>  drivers/gpu/drm/ast/ast_cursor.c | 218 +++
>>>  drivers/gpu/drm/ast/ast_drv.h|   9 ++
>>>  drivers/gpu/drm/ast/ast_mode.c   | 195 ---
>>>  4 files changed, 229 insertions(+), 196 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/ast/ast_cursor.c
>>>
>>> diff --git a/drivers/gpu/drm/ast/Makefile b/drivers/gpu/drm/ast/Makefile
>>> index 561f7c4199e4..6a5b3b247316 100644
>>> --- a/drivers/gpu/drm/ast/Makefile
>>> +++ b/drivers/gpu/drm/ast/Makefile
>>> @@ -3,6 +3,7 @@
>>>  # Makefile for the drm device driver.  This driver provides support for the
>>>  # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>>>  
>>> -ast-y := ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o ast_dp501.o
>>> +ast-y := ast_cursor.o ast_drv.o ast_main.o ast_mode.o ast_ttm.o ast_post.o 
>>> \
>>> +ast_dp501.o
>>>  
>>>  obj-$(CONFIG_DRM_AST) := ast.o
>>> diff --git a/drivers/gpu/drm/ast/ast_cursor.c 
>>> b/drivers/gpu/drm/ast/ast_cursor.c
>>> new file mode 100644
>>> index ..53bb6eebc7cd
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/ast/ast_cursor.c
>>> @@ -0,0 +1,218 @@
>>> +/*
>>> + * Copyright 2012 Red Hat Inc.
>>> + * Parts based on xf86-video-ast
>>> + * Copyright (c) 2005 ASPEED Technology Inc.
>>> + *
>>> + * Permission is hereby granted, free of charge, to any person obtaining a
>>> + * copy of this software and associated documentation files (the
>>> + * "Software"), to deal in the Software without restriction, including
>>> + * without limitation the rights to use, copy, modify, merge, publish,
>>> + * distribute, sub license, and/or sell copies of the Software, and to
>>> + * permit persons to whom the Software is furnished to do so, subject to
>>> + * the following conditions:
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>>> OR
>>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>>> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
>>> + * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY 
>>> CLAIM,
>>> + * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
>>> + * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR 
>>> THE
>>> + * USE OR OTHER DEALINGS IN THE SOFTWARE.
>>> + *
>>> + * The above copyright notice and this permission notice (including the
>>> + * next paragraph) shall be included in all copies or substantial portions
>>> + * of the Software.
>>
>> SPDX for new files?
>> I guess this boilerplate was copied from the old file.
> 
> Yes, I copied the license text from the old file. I wasn't sure if I can
> just add the SPDX tag. If that's not a problem, I'll add it in the next
> iteration.

I found that it's the MIT license, but not quite. Paragraphs are in
different order and some words are spelled differently. I don't know
what the legal implications are, so I don't want to put the SPDX tag
onto it. It might be better addressed in a separate patchset.

Best regards
Thomas

> 
> Best regards
> Thomas
> 
>>
>> Acked-by: Sam Ravnborg 
>>
>>> + */
>>> +/*
>>> + * Authors: Dave Airlie 
>>> + */
>>> +
>>> +#include 
>>> +
>>> +#include "ast_drv.h"
>>> +
>>> +/*
>>> + * Allocate cursor BOs and pins them at the end of VRAM.
>>> + */
>>> +int ast_cursor_init(struct drm_device *dev)
>>> +{
>>> +   struct ast_private *ast = to_ast_private(dev);
>>> +   size_t size, i;
>>> +   struct drm_gem_vram_object *gbo;
>>> +   int ret;
>>> +
>>> +   size = roundup(AST_HWC_SIZE + AST_HWC_SIGNATURE_SIZE, PAGE_SIZE);
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(ast->cursor.gbo); ++i) {
>>> +   gbo = drm_gem_vram_create(dev, size, 0);
>>> +   if (IS_ERR(gbo)) {
>>> +   ret = PTR_ERR(gbo);
>>> +   goto err_drm_gem_vram_put;
>>> +   }
>>> +   ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM |
>>> +   DRM_GEM_VRAM_PL_FLAG_TOPDOWN);
>>> +   if (ret) {
>>> +   drm_gem_vram_put(gbo);
>>> +   goto err_drm_gem_vram_put;
>>> +   }
>>> +
>>> +   ast->cursor.gbo[i] = gbo;
>>> +   }
>>> +
>>> +   return 0;
>>> +
>>> +err_drm_gem_vram_put:
>>> +   while (i) {
>>> +   --i;
>>> +   gbo = ast->cursor.gbo[i];
>>> +   drm_gem_vram_unpin(gbo);
>>> +   drm_gem_vram_put(gbo);
>>> +   ast->cursor.gbo[i] = NULL;
>>> +   }
>>> +   return ret;
>>> +}
>>> +
>>> +void ast_cursor_fini(struct drm_device *dev)
>>> +{
>>> +

Re: [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset

On Thu, Jul 2, 2020 at 1:27 PM Laurent Pinchart
 wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> > Only when vblanks are supported ofc.
> >
> > Some drivers do this already, but most unfortunately missed it. This
> > opens up bugs after driver load, before the crtc is enabled for the
> > first time. syzbot spotted this when loading vkms as a secondary
> > output. Given how many drivers are buggy it's best to solve this once
> > and for all in shared helper code.
> >
> > Aside from moving the few existing calls to drm_crtc_vblank_reset into
> > helpers (i915 doesn't use helpers, so keeps its own) I think the
> > regression risk is minimal: atomic helpers already rely on drivers
> > calling drm_crtc_vblank_on/off correctly in their hooks when they
> > support vblanks. And driver that's failing to handle vblanks after
> > this is missing those calls already, and vblanks could only work by
> > accident when enabling a CRTC for the first time right after boot.
> >
> > Big thanks to Tetsuo for helping track down what's going wrong here.
> >
> > There's only a few drivers which already had the necessary call and
> > needed some updating:
> > - komeda, atmel and tidss also needed to be changed to call
> >   __drm_atomic_helper_crtc_reset() intead of open coding it
> > - tegra and msm even had it in the same place already, just code
> >   motion, and malidp already uses __drm_atomic_helper_crtc_reset().
>
> Should you mention rcar-du and omapdrm here ?

Uh yes need to mention them too here, and how exactly they're a bit
different. Will shuffle that from the v4: block below when applying.

> > Only call left is in i915, which doesn't use drm_mode_config_reset,
> > but has its own fastboot infrastructure. So that's the only case where
> > we actually want this in the driver still.
> >
> > I've also reviewed all other drivers which set up vblank support with
> > drm_vblank_init. After the previous patch fixing mxsfb all atomic
> > drivers do call drm_crtc_vblank_on/off as they should, the remaining
> > drivers are either legacy kms or legacy dri1 drivers, so not affected
> > by this change to atomic helpers.
> >
> > v2: Use the drm_dev_has_vblank() helper.
> >
> > v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> > instead of drm_crtc_vblank_reset. Adjust them too.
> >
> > v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> > and hence would actually be broken by this patch now. So fix them up
> > by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
> >
> > Cc: Laurent Pinchart 
> > Reviewed-by: Boris Brezillon 
> > Acked-by: Liviu Dudau 
> > Acked-by: Thierry Reding 
> > Link: 
> > https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> > Reported-by: Tetsuo Handa 
> > Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> > Cc: Tetsuo Handa 
> > Cc: "James (Qian) Wang" 
> > Cc: Liviu Dudau 
> > Cc: Mihail Atanassov 
> > Cc: Brian Starkey 
> > Cc: Sam Ravnborg 
> > Cc: Boris Brezillon 
> > Cc: Nicolas Ferre 
> > Cc: Alexandre Belloni 
> > Cc: Ludovic Desroches 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Cc: Thierry Reding 
> > Cc: Jonathan Hunter 
> > Cc: Jyri Sarha 
> > Cc: Tomi Valkeinen 
> > Cc: Rob Clark 
> > Cc: Sean Paul 
> > Cc: Brian Masney 
> > Cc: Emil Velikov 
> > Cc: zhengbin 
> > Cc: Thomas Gleixner 
> > Cc: linux-te...@vger.kernel.org
> > Cc: Kieran Bingham 
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
> >  drivers/gpu/drm/arm/malidp_drv.c | 1 -
> >  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 7 ++-
> >  drivers/gpu/drm/drm_atomic_state_helper.c| 4 
> >  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
> >  drivers/gpu/drm/omapdrm/omap_crtc.c  | 8 +---
> >  drivers/gpu/drm/omapdrm/omap_drv.c   | 4 
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c   | 6 +-
> >  drivers/gpu/drm/tegra/dc.c   | 1 -
> >  drivers/gpu/drm/tidss/tidss_crtc.c   | 3 +--
> >  drivers/gpu/drm/tidss/tidss_kms.c| 4 
> >  11 files changed, 15 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > index 56bd938961ee..f33418d6e1a0 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
> >   crtc->state = NULL;
> >
> >   state = kzalloc(sizeof(*state), GFP_KERNEL);
> > - if (state) {
> > - crtc->state = >base;
> > -

Re: [PATCH 1/8] drm/atomic-helper: reset vblank on crtc reset

Hi Daniel,

Thank you for the patch.

On Fri, Jun 12, 2020 at 06:00:49PM +0200, Daniel Vetter wrote:
> Only when vblanks are supported ofc.
> 
> Some drivers do this already, but most unfortunately missed it. This
> opens up bugs after driver load, before the crtc is enabled for the
> first time. syzbot spotted this when loading vkms as a secondary
> output. Given how many drivers are buggy it's best to solve this once
> and for all in shared helper code.
> 
> Aside from moving the few existing calls to drm_crtc_vblank_reset into
> helpers (i915 doesn't use helpers, so keeps its own) I think the
> regression risk is minimal: atomic helpers already rely on drivers
> calling drm_crtc_vblank_on/off correctly in their hooks when they
> support vblanks. And driver that's failing to handle vblanks after
> this is missing those calls already, and vblanks could only work by
> accident when enabling a CRTC for the first time right after boot.
> 
> Big thanks to Tetsuo for helping track down what's going wrong here.
> 
> There's only a few drivers which already had the necessary call and
> needed some updating:
> - komeda, atmel and tidss also needed to be changed to call
>   __drm_atomic_helper_crtc_reset() intead of open coding it
> - tegra and msm even had it in the same place already, just code
>   motion, and malidp already uses __drm_atomic_helper_crtc_reset().

Should you mention rcar-du and omapdrm here ?

> Only call left is in i915, which doesn't use drm_mode_config_reset,
> but has its own fastboot infrastructure. So that's the only case where
> we actually want this in the driver still.
> 
> I've also reviewed all other drivers which set up vblank support with
> drm_vblank_init. After the previous patch fixing mxsfb all atomic
> drivers do call drm_crtc_vblank_on/off as they should, the remaining
> drivers are either legacy kms or legacy dri1 drivers, so not affected
> by this change to atomic helpers.
> 
> v2: Use the drm_dev_has_vblank() helper.
> 
> v3: Laurent pointed out that omap and rcar-du used drm_crtc_vblank_off
> instead of drm_crtc_vblank_reset. Adjust them too.
> 
> v4: Laurent noticed that rcar-du and omap open-code their crtc reset
> and hence would actually be broken by this patch now. So fix them up
> by reusing the helpers, which brings the drm_crtc_vblank_reset() back.
> 
> Cc: Laurent Pinchart 
> Reviewed-by: Boris Brezillon 
> Acked-by: Liviu Dudau 
> Acked-by: Thierry Reding 
> Link: 
> https://syzkaller.appspot.com/bug?id=0ba17d70d062b2595e1f061231474800f076c7cb
> Reported-by: Tetsuo Handa 
> Reported-by: syzbot+0871b14ca2e2fb64f...@syzkaller.appspotmail.com
> Cc: Tetsuo Handa 
> Cc: "James (Qian) Wang" 
> Cc: Liviu Dudau 
> Cc: Mihail Atanassov 
> Cc: Brian Starkey 
> Cc: Sam Ravnborg 
> Cc: Boris Brezillon 
> Cc: Nicolas Ferre 
> Cc: Alexandre Belloni 
> Cc: Ludovic Desroches 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Thierry Reding 
> Cc: Jonathan Hunter 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Cc: Rob Clark 
> Cc: Sean Paul 
> Cc: Brian Masney 
> Cc: Emil Velikov 
> Cc: zhengbin 
> Cc: Thomas Gleixner 
> Cc: linux-te...@vger.kernel.org
> Cc: Kieran Bingham 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 7 ++-
>  drivers/gpu/drm/arm/malidp_drv.c | 1 -
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   | 7 ++-
>  drivers/gpu/drm/drm_atomic_state_helper.c| 4 
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c| 2 --
>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 8 +---
>  drivers/gpu/drm/omapdrm/omap_drv.c   | 4 
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c   | 6 +-
>  drivers/gpu/drm/tegra/dc.c   | 1 -
>  drivers/gpu/drm/tidss/tidss_crtc.c   | 3 +--
>  drivers/gpu/drm/tidss/tidss_kms.c| 4 
>  11 files changed, 15 insertions(+), 32 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 56bd938961ee..f33418d6e1a0 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -492,10 +492,8 @@ static void komeda_crtc_reset(struct drm_crtc *crtc)
>   crtc->state = NULL;
>  
>   state = kzalloc(sizeof(*state), GFP_KERNEL);
> - if (state) {
> - crtc->state = >base;
> - crtc->state->crtc = crtc;
> - }
> + if (state)
> + __drm_atomic_helper_crtc_reset(crtc, >base);
>  }
>  
>  static struct drm_crtc_state *
> @@ -616,7 +614,6 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>   return err;
>  
>   drm_crtc_helper_add(crtc, _crtc_helper_funcs);
> - drm_crtc_vblank_reset(crtc);
>  
>   crtc->port = kcrtc->master->of_output_port;

[PATCH v6 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset

2020-07-02 Thread Jim Quinlan

The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs.  It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.

The function of_dma_get_range() has been modified so that it takes a single
argument -- the device node -- and returns a map, NULL, or an error code.
The map is an array that holds the information regarding the DMA regions.
Each range entry contains the address offset, the cpu_start address, the
dma_start address, and the size of the region.

of_dma_configure() is the typical manner to set range offsets but there are
a number of ad hoc assignments to "dev->dma_pfn_offset" in the kernel
driver code.  These cases now invoke the function
dma_attach_offset_range(dev, cpu_addr, dma_addr, size).

Signed-off-by: Jim Quinlan 
---
 arch/arm/include/asm/dma-mapping.h|  9 +-
 arch/arm/mach-keystone/keystone.c | 17 ++--
 arch/sh/drivers/pci/pcie-sh7786.c |  9 +-
 arch/sh/kernel/dma-coherent.c | 14 +--
 arch/x86/pci/sta2x11-fixup.c  |  7 +-
 drivers/acpi/arm64/iort.c |  5 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c |  7 +-
 drivers/iommu/io-pgtable-arm.c|  2 +-
 .../platform/sunxi/sun4i-csi/sun4i_csi.c  |  6 +-
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  |  5 +-
 drivers/of/address.c  | 95 ++-
 drivers/of/device.c   | 50 ++
 drivers/of/of_private.h   |  9 +-
 drivers/of/unittest.c | 35 +--
 drivers/remoteproc/remoteproc_core.c  |  2 +-
 .../staging/media/sunxi/cedrus/cedrus_hw.c|  8 +-
 drivers/usb/core/message.c|  4 +-
 drivers/usb/core/usb.c|  2 +-
 include/linux/device.h|  4 +-
 include/linux/dma-direct.h| 10 +-
 include/linux/dma-mapping.h   | 37 
 kernel/dma/coherent.c | 11 ++-
 kernel/dma/mapping.c  | 53 +++
 23 files changed, 279 insertions(+), 122 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..b6796383f205 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,9 @@ static inline const struct dma_map_ops 
*get_arch_dma_ops(struct bus_type *bus)
 #ifndef __arch_pfn_to_dma
 static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
 {
-   if (dev)
-   pfn -= dev->dma_pfn_offset;
+   if (dev && dev->dma_range_map)
+   pfn -= (unsigned long)PFN_DOWN(dma_offset_from_phys_addr(dev, 
PFN_PHYS(pfn)));
+
return (dma_addr_t)__pfn_to_bus(pfn);
 }
 
@@ -44,8 +45,8 @@ static inline unsigned long dma_to_pfn(struct device *dev, 
dma_addr_t addr)
 {
unsigned long pfn = __bus_to_pfn(addr);
 
-   if (dev)
-   pfn += dev->dma_pfn_offset;
+   if (dev && dev->dma_range_map)
+   pfn += (unsigned long)PFN_DOWN(dma_offset_from_dma_addr(dev, 
addr));
 
return pfn;
 }
diff --git a/arch/arm/mach-keystone/keystone.c 
b/arch/arm/mach-keystone/keystone.c
index 638808c4e122..a499ece6f054 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -8,6 +8,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -24,8 +25,6 @@
 
 #include "keystone.h"
 
-static unsigned long keystone_dma_pfn_offset __read_mostly;
-
 static int keystone_platform_notifier(struct notifier_block *nb,
  unsigned long event, void *data)
 {
@@ -38,9 +37,12 @@ static int keystone_platform_notifier(struct notifier_block 
*nb,
return NOTIFY_BAD;
 
if (!dev->of_node) {
-   dev->dma_pfn_offset = keystone_dma_pfn_offset;
-   dev_err(dev, "set dma_pfn_offset%08lx\n",
-   dev->dma_pfn_offset);
+   int ret = dma_attach_offset_range(dev, KEYSTONE_HIGH_PHYS_START,
+ KEYSTONE_LOW_PHYS_START,
+ KEYSTONE_HIGH_PHYS_SIZE);
+   dev_err(dev, "set dma_offset%08llx%s\n", 
KEYSTONE_HIGH_PHYS_START
+   - KEYSTONE_LOW_PHYS_START, ret ? " failed" : "");
+
}
return NOTIFY_OK;
 }
@@ -51,11 +53,8 @@ static struct notifier_block platform_nb = {
 
 static void __init keystone_init(void)
 {
-   if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START) {
-   keystone_dma_pfn_offset = PFN_DOWN(KEYSTONE_HIGH_PHYS_START -
-  KEYSTONE_LOW_PHYS_START);
+   if (PHYS_OFFSET >= KEYSTONE_HIGH_PHYS_START)

Re: [PATCH v6 1/4] driver core: add device probe log helper

2020-07-02 Thread Grygorii Strashko





On 26/06/2020 13:01, Andrzej Hajda wrote:

During probe every time driver gets resource it should usually check for
error printk some message if it is not -EPROBE_DEFER and return the error.
This pattern is simple but requires adding few lines after any resource
acquisition code, as a result it is often omitted or implemented only
partially.
dev_err_probe helps to replace such code sequences with simple call,
so code:
if (err != -EPROBE_DEFER)
dev_err(dev, ...);
return err;
becomes:
return probe_err(dev, err, ...);

Signed-off-by: Andrzej Hajda 
---
  drivers/base/core.c| 42 ++
  include/linux/device.h |  3 +++
  2 files changed, 45 insertions(+)



Basic version of the helper looks very good to me, thank you.
Reviewed-by: Grygorii Strashko 


diff --git a/drivers/base/core.c b/drivers/base/core.c
index 67d39a90b45c..3a827c82933f 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3953,6 +3953,48 @@ define_dev_printk_level(_dev_info, KERN_INFO);
  
  #endif
  
+/**

+ * dev_err_probe - probe error check and log helper
+ * @dev: the pointer to the struct device
+ * @err: error value to test
+ * @fmt: printf-style format string
+ * @...: arguments as specified in the format string
+ *
+ * This helper implements common pattern present in probe functions for error
+ * checking: print debug or error message depending if the error value is
+ * -EPROBE_DEFER and propagate error upwards.
+ * It replaces code sequence:
+ * if (err != -EPROBE_DEFER)
+ * dev_err(dev, ...);
+ * else
+ * dev_dbg(dev, ...);
+ * return err;
+ * with
+ * return dev_err_probe(dev, err, ...);
+ *
+ * Returns @err.
+ *
+ */
+int dev_err_probe(const struct device *dev, int err, const char *fmt, ...)
+{
+   struct va_format vaf;
+   va_list args;
+
+   va_start(args, fmt);
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   if (err != -EPROBE_DEFER)
+   dev_err(dev, "error %d: %pV", err, );
+   else
+   dev_dbg(dev, "error %d: %pV", err, );
+
+   va_end(args);
+
+   return err;
+}
+EXPORT_SYMBOL_GPL(dev_err_probe);
+
  static inline bool fwnode_is_primary(struct fwnode_handle *fwnode)
  {
return fwnode && !IS_ERR(fwnode->secondary);
diff --git a/include/linux/device.h b/include/linux/device.h
index 15460a5ac024..6b2272ae9af8 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -964,6 +964,9 @@ void device_link_remove(void *consumer, struct device 
*supplier);
  void device_links_supplier_sync_state_pause(void);
  void device_links_supplier_sync_state_resume(void);
  
+extern __printf(3, 4)

+int dev_err_probe(const struct device *dev, int err, const char *fmt, ...);
+
  /* Create alias, so I can be autoloaded. */
  #define MODULE_ALIAS_CHARDEV(major,minor) \
MODULE_ALIAS("char-major-" __stringify(major) "-" __stringify(minor))



--
Best regards,
grygorii
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 00/12] PCI: brcmstb: enable PCIe for STB chips

2020-07-02 Thread Jim Quinlan

Patchset Summary:
  Enhance a PCIe host controller driver.  Because of its unusual design
  we are foced to change dev->dma_pfn_offset into a more general role
  allowing multiple offsets.  See the 'v1' notes below for more info.

v6:
  Commit "device core: Introduce DMA range map":
  -- of_dma_get_range() now takes a single argument and returns either
 NULL, a valid map, or an ERR_PTR. (Robin)
  -- offsets are no longer a PFN value but an actual address. (Robin)
  -- the bus_dma_region struct stores the range size instead of
 the cpu_end and pci_end values. (Robin)
  -- devices that were setting a single offset with no boundaries
 have been modified to have boundaries; in a few places
 where this informatino was unavilable a /* FIXME: ... */
 comment was added. (Robin)
  -- dma_attach_offset_range() can be called when an offset
 map already exists; if it's range is already present
 nothing is done and success is returned. (Robin)
  All commits:
  -- Man name/style/corrections/etc changed (Bjorn)
  -- rebase to Torvalds master

v5:
  Commit "device core: Introduce multiple dma pfn offsets"
  -- in of/address.c: "map_size = 0" => "*map_size = 0"
  -- use kcalloc instead of kzalloc (AndyS)
  -- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0"
  Commit "PCI: brcmstb: Set internal memory viewport sizes"
  -- now gives error on missing dma-ranges property.
  Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
  -- removed "Allof:" from brcm,scb-sizes definition (RobH)
  All Commits:
  -- indentation style, use max chars 100 (AndyS)
  -- rebased to torvalds master

v4:
  Commit "device core: Introduce multiple dma pfn offsets"
  -- of_dma_get_range() does not take a dev param but instead
 takes two "out" params: map and map_size.  We do this so
 that the code that parses dma-ranges is separate from
 the code that modifies 'dev'.   (Nicolas)
  -- the separate case of having a single pfn offset has
 been removed and is now processed by going through the
 map array. (Nicolas)
  -- move attach_uniform_dma_pfn_offset() from of/address.c to
 dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas)
  -- devm_kcalloc => devm_kzalloc (DanC)
  -- add/fix assignment to dev->dma_pfn_offset_map for func
 attach_uniform_dma_pfn_offset() (DanC, Nicolas)
  -- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas)
  -- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/
  -- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/
  -- More use of PFN_{PHYS,DOWN,UP}. (AndyS)
  Commit "of: Include a dev param in of_dma_get_range()"
  -- this commit was sqaushed with "device core: Introduce ..."

v3:
  Commit "device core: Introduce multiple dma pfn offsets"
  Commit "arm: dma-mapping: Invoke dma offset func if needed"
  -- The above two commits have been squashed.  More importantly,
 the code has been modified so that the functionality for
 multiple pfn offsets subsumes the use of dev->dma_pfn_offset.
 In fact, dma_pfn_offset is removed and supplanted by
 dma_pfn_offset_map, which is a pointer to an array.  The
 more common case of a uniform offset is now handled as
 a map with a single entry, while cases requiring multiple
 pfn offsets use a map with multiple entries.  Code paths
 that used to do this:

 dev->dma_pfn_offset = mydrivers_pfn_offset;

 have been changed to do this:

 attach_uniform_dma_pfn_offset(dev, pfn_offset);

  Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips"
  -- Add if/then clause for required props: resets, reset-names (RobH)
  -- Change compatible list from const to enum (RobH)
  -- Change list of u32-tuples to u64 (RobH)

  Commit "of: Include a dev param in of_dma_get_range()"
  -- modify of/unittests.c to add NULL param in of_dma_get_range() call.

  Commit "device core: Add ability to handle multiple dma offsets"
  -- align comment in device.h (AndyS).
  -- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct
 dma_pfn_offset_region (AndyS).

v2:
Commit: "device core: Add ability to handle multiple dma offsets"
  o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
  o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
  o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
  o dev->dma_pfn_map => dev->dma_pfn_offset_map
  o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
  o In device.h: s/const void */const struct dma_pfn_offset_region */
  o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
  o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
  o Merged two of the DMA commits into one (Christoph).

Commit "arm: dma-mapping: Invoke dma offset func if needed":
  o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET

Other commits'

[PATCH v2 4/4] arm64: dts: sc7180: Add DSI and MDP OPP tables and power-domains

Add the OPP tables for DSI and MDP based on the perf state/clk
requirements, and add the power-domains property to specify the
scalable power domain.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Matthias Kaehlcke 
---
 arch/arm64/boot/dts/qcom/sc7180.dtsi | 49 
 1 file changed, 49 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi 
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index ad57df2..3430c33f 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -2482,6 +2482,8 @@
   <1920>,
   <1920>,
   <1920>;
+   operating-points-v2 = <_opp_table>;
+   power-domains = < SC7180_CX>;
 
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
@@ -2499,6 +2501,31 @@
};
};
};
+
+   mdp_opp_table: mdp-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-2 {
+   opp-hz = /bits/ 64 <2>;
+   required-opps = 
<_opp_low_svs>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = 
<_opp_svs>;
+   };
+
+   opp-34500 {
+   opp-hz = /bits/ 64 <34500>;
+   required-opps = 
<_opp_svs_l1>;
+   };
+
+   opp-46000 {
+   opp-hz = /bits/ 64 <46000>;
+   required-opps = 
<_opp_nom>;
+   };
+   };
+
};
 
dsi0: dsi@ae94000 {
@@ -2522,6 +2549,9 @@
  "iface",
  "bus";
 
+   operating-points-v2 = <_opp_table>;
+   power-domains = < SC7180_CX>;
+
phys = <_phy>;
phy-names = "dsi";
 
@@ -2547,6 +2577,25 @@
};
};
};
+
+   dsi_opp_table: dsi-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-18750 {
+   opp-hz = /bits/ 64 <18750>;
+   required-opps = 
<_opp_low_svs>;
+   };
+
+   opp-3 {
+   opp-hz = /bits/ 64 <3>;
+   required-opps = 
<_opp_svs>;
+   };
+
+   opp-35800 {
+   opp-hz = /bits/ 64 <35800>;
+   required-opps = 
<_opp_svs_l1>;
+   };
+   };
};
 
dsi_phy: dsi-phy@ae94400 {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/4] DVFS support for dpu and dsi

Changes in v2
- Patch 2: Dropped dsi_link_clk_set_rate_6g_v2 and dsi_link_clk_disable_6g_v2 
as suggested by Matthias

These patches add DVFS support for DPU and DSI.

These patches have no other dependency. Patch 1 and 2 will need to be merged in
via the MSM DRM tree.

DT patches will need to land via the msm tree.

Rajendra Nayak (4):
  drm/msm/dpu: Use OPP API to set clk/perf state
  drm/msm: dsi: Use OPP API to set clk/perf state
  arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains
  arm64: dts: sc7180: Add DSI and MDP OPP tables and power-domains

 arch/arm64/boot/dts/qcom/sc7180.dtsi  | 49 ++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 59 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  3 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 26 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  4 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 26 +++-
 6 files changed, 163 insertions(+), 4 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/4] drm/msm/dpu: Use OPP API to set clk/perf state

On some qualcomm platforms DPU needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Rob Clark 
Reviewed-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c |  3 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 26 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  4 
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 7c230f7..b36919d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -218,7 +219,7 @@ static int _dpu_core_perf_set_core_clk_rate(struct dpu_kms 
*kms, u64 rate)
rate = core_clk->max_rate;
 
core_clk->rate = rate;
-   return msm_dss_clk_set_rate(core_clk, 1);
+   return dev_pm_opp_set_rate(>pdev->dev, core_clk->rate);
 }
 
 static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms *kms)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index b8615d4..0bc8ec4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1025,11 +1026,23 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
if (!dpu_kms)
return -ENOMEM;
 
+   dpu_kms->opp_table = dev_pm_opp_set_clkname(dev, "core");
+   if (IS_ERR(dpu_kms->opp_table))
+   return PTR_ERR(dpu_kms->opp_table);
+   /* OPP table is optional */
+   ret = dev_pm_opp_of_add_table(dev);
+   if (!ret) {
+   dpu_kms->has_opp_table = true;
+   } else if (ret != -ENODEV) {
+   dev_err(dev, "invalid OPP table in device tree\n");
+   return ret;
+   }
+
mp = _kms->mp;
ret = msm_dss_parse_clock(pdev, mp);
if (ret) {
DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
-   return ret;
+   goto err;
}
 
platform_set_drvdata(pdev, dpu_kms);
@@ -1043,6 +1056,11 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
 
priv->kms = _kms->base;
return ret;
+err:
+   if (dpu_kms->has_opp_table)
+   dev_pm_opp_of_remove_table(dev);
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
+   return ret;
 }
 
 static void dpu_unbind(struct device *dev, struct device *master, void *data)
@@ -1057,6 +1075,10 @@ static void dpu_unbind(struct device *dev, struct device 
*master, void *data)
 
if (dpu_kms->rpm_enabled)
pm_runtime_disable(>dev);
+
+   if (dpu_kms->has_opp_table)
+   dev_pm_opp_of_remove_table(dev);
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
 }
 
 static const struct component_ops dpu_ops = {
@@ -1082,6 +1104,8 @@ static int __maybe_unused dpu_runtime_suspend(struct 
device *dev)
struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
struct dss_module_power *mp = _kms->mp;
 
+   /* Drop the performance state vote */
+   dev_pm_opp_set_rate(dev, 0);
rc = msm_dss_enable_clk(mp->clk_config, mp->num_clk, false);
if (rc)
DPU_ERROR("clock disable failed rc:%d\n", rc);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index a3b122b..7400cd7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -128,6 +128,10 @@ struct dpu_kms {
 
struct platform_device *pdev;
bool rpm_enabled;
+
+   struct opp_table *opp_table;
+   bool has_opp_table;
+
struct dss_module_power mp;
 
/* reference count bandwidth requests, so we know when we can
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/4] drm/msm: dsi: Use OPP API to set clk/perf state

On SDM845 and SC7180 DSI needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

dev_pm_opp_set_rate() is designed to be equivalent to clk_set_rate()
for devices without an OPP table, hence the change works fine
on devices/platforms which only need to set a clock rate.

Signed-off-by: Rajendra Nayak 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..09e16b8 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,9 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
 
+   struct opp_table *opp_table;
+   bool has_opp_table;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -512,9 +516,10 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
DBG("Set clk rates: pclk=%d, byteclk=%d",
msm_host->mode->clock, msm_host->byte_clk_rate);
 
-   ret = clk_set_rate(msm_host->byte_clk, msm_host->byte_clk_rate);
+   ret = dev_pm_opp_set_rate(_host->pdev->dev,
+ msm_host->byte_clk_rate);
if (ret) {
-   pr_err("%s: Failed to set rate byte clk, %d\n", __func__, ret);
+   pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
return ret;
}
 
@@ -658,6 +663,8 @@ int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host)
 
 void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
 {
+   /* Drop the performance state vote */
+   dev_pm_opp_set_rate(_host->pdev->dev, 0);
clk_disable_unprepare(msm_host->esc_clk);
clk_disable_unprepare(msm_host->pixel_clk);
if (msm_host->byte_intf_clk)
@@ -1879,6 +1886,18 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
goto fail;
}
 
+   msm_host->opp_table = dev_pm_opp_set_clkname(>dev, "byte");
+   if (IS_ERR(msm_host->opp_table))
+   return PTR_ERR(msm_host->opp_table);
+   /* OPP table is optional */
+   ret = dev_pm_opp_of_add_table(>dev);
+   if (!ret) {
+   msm_host->has_opp_table = true;
+   } else if (ret != -ENODEV) {
+   dev_err(>dev, "invalid OPP table in device tree\n");
+   return ret;
+   }
+
init_completion(_host->dma_comp);
init_completion(_host->video_comp);
mutex_init(_host->dev_mutex);
@@ -1914,6 +1933,9 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
mutex_destroy(_host->cmd_mutex);
mutex_destroy(_host->dev_mutex);
 
+   if (msm_host->has_opp_table)
+   dev_pm_opp_of_remove_table(_host->pdev->dev);
+   dev_pm_opp_put_clkname(msm_host->opp_table);
pm_runtime_disable(_host->pdev->dev);
 }
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 3/4] arm64: dts: sdm845: Add DSI and MDP OPP tables and power-domains

Add the OPP tables for DSI and MDP based on the perf state/clk
requirements, and add the power-domains property to specify the
scalable power domain.

Signed-off-by: Rajendra Nayak 
Reviewed-by: Matthias Kaehlcke 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 59 
 1 file changed, 59 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 8eb5a31..b6afeb2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3296,6 +3296,35 @@
#power-domain-cells = <1>;
};
 
+   dsi_opp_table: dsi-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-1920 {
+   opp-hz = /bits/ 64 <1920>;
+   required-opps = <_opp_min_svs>;
+   };
+
+   opp-18000 {
+   opp-hz = /bits/ 64 <18000>;
+   required-opps = <_opp_low_svs>;
+   };
+
+   opp-27500 {
+   opp-hz = /bits/ 64 <27500>;
+   required-opps = <_opp_svs>;
+   };
+
+   opp-32858 {
+   opp-hz = /bits/ 64 <32858>;
+   required-opps = <_opp_svs_l1>;
+   };
+
+   opp-35800 {
+   opp-hz = /bits/ 64 <35800>;
+   required-opps = <_opp_nom>;
+   };
+   };
+
mdss: mdss@ae0 {
compatible = "qcom,sdm845-mdss";
reg = <0 0x0ae0 0 0x1000>;
@@ -3340,6 +3369,8 @@
  < 
DISP_CC_MDSS_VSYNC_CLK>;
assigned-clock-rates = <3>,
   <1920>;
+   operating-points-v2 = <_opp_table>;
+   power-domains = < SDM845_CX>;
 
interrupt-parent = <>;
interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
@@ -3364,6 +3395,30 @@
};
};
};
+
+   mdp_opp_table: mdp-opp-table {
+   compatible = "operating-points-v2";
+
+   opp-1920 {
+   opp-hz = /bits/ 64 <1920>;
+   required-opps = 
<_opp_min_svs>;
+   };
+
+   opp-171428571 {
+   opp-hz = /bits/ 64 <171428571>;
+   required-opps = 
<_opp_low_svs>;
+   };
+
+   opp-34400 {
+   opp-hz = /bits/ 64 <34400>;
+   required-opps = 
<_opp_svs_l1>;
+   };
+
+   opp-43000 {
+   opp-hz = /bits/ 64 <43000>;
+   required-opps = 
<_opp_nom>;
+   };
+   };
};
 
dsi0: dsi@ae94000 {
@@ -3386,6 +3441,8 @@
  "core",
  "iface",
  "bus";
+   operating-points-v2 = <_opp_table>;
+   power-domains = < SDM845_CX>;
 
phys = <_phy>;
phy-names = "dsi";
@@ -3450,6 +3507,8 @@
  "core",
  "iface",
  "bus";
+   operating-points-v2 = <_opp_table>;
+   power-domains = < SDM845_CX>;
 
phys = <_phy>;
phy-names = "dsi";
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 208413] amdgpu driver crash

https://bugzilla.kernel.org/show_bug.cgi?id=208413

--- Comment #1 from ghutzr...@gmail.com ---
Created attachment 290065
  --> https://bugzilla.kernel.org/attachment.cgi?id=290065=edit
other dmesg from hang

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 208413] New: amdgpu driver crash

https://bugzilla.kernel.org/show_bug.cgi?id=208413

Bug ID: 208413
   Summary: amdgpu driver crash
   Product: Drivers
   Version: 2.5
Kernel Version: 5.8
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: ghutzr...@gmail.com
Regression: No

Created attachment 290063
  --> https://bugzilla.kernel.org/attachment.cgi?id=290063=edit
dmesg from hang

Linux freezes after a while of desktop usage with Gnome 3 on wayland. The CPU
is a Ryzen 4700u without a dedicated GPU.

The freezes occurred on kernel 5.7 as well.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/59] Add support for Keem Bay DRM driver

Hi,

On 30/06/2020 23:27, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
> 
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC. The SOC's display pipeline is as follows
> 
> +--++-++---+
> |LCD controller| -> |Mipi DSI | -> |Mipi to HDMI Converter |
> +--++-++---+
> 
> LCD controller and Mipi DSI transmitter are part of the SOC and 
> mipi to HDMI converter is ADV7535 for KMB EVM board.
> 
> The DRM driver is a basic KMS atomic modesetting display driver and
> has no 2D or 3D graphics.It calls into the ADV bridge driver at 
> the connector level.
> 
> Only 1080p resolution and single plane is supported at this time.
> The usecase is for debugging video and camera outputs.
> 
> Since we are just starting the upstream process, the KMB EVM board is not in
> mainline and so Device tree changes are missing.

A proper Yaml bindings file is then necessary even if the platform is not
mainline.

Neil

> 
> Anitha Chrisanthus (52):
>   drm/kmb: Add support for KeemBay Display
>   drm/kmb: Added id to kmb_plane
>   drm/kmb: Set correct values in the LAYERn_CFG register
>   drm/kmb: Use biwise operators for register definitions
>   drm/kmb: Updated kmb_plane_atomic_check
>   drm/kmb: Initial check-in for Mipi DSI
>   drm/kmb: Set OUT_FORMAT_CFG register
>   drm/kmb: Added mipi_dsi_host initialization
>   drm/kmb: Part 1 of Mipi Tx Initialization
>   drm/kmb: Part 2 of Mipi Tx Initialization
>   drm/kmb: Use correct mmio offset from data book
>   drm/kmb: Part3 of Mipi Tx initialization
>   drm/kmb: Part4 of Mipi Tx Initialization
>   drm/kmb: Correct address offsets for mipi registers
>   drm/kmb: Part5 of Mipi Tx Intitialization
>   drm/kmb: Part6 of Mipi Tx Initialization
>   drm/kmb: Part7 of Mipi Tx Initialization
>   drm/kmb: Part8 of Mipi Tx Initialization
>   drm/kmb: Added ioremap/iounmap for register access
>   drm/kmb: Register IRQ for LCD
>   drm/kmb: IRQ handlers for LCD and mipi dsi
>   drm/kmb: Set hardcoded values to LCD_VSYNC_START
>   drm/kmb: Additional register programming to update_plane
>   drm/kmb: Add ADV7535 bridge
>   drm/kmb: Display clock enable/disable
>   drm/kmb: rebase to newer kernel version
>   drm/kmb: minor name change to match device tree
>   drm/kmb: Changed MMIO size
>   drm/kmb: Defer Probe
>   drm/kmb: call bridge init in the very beginning
>   drm/kmb: Enable MSS_CAM_CLK_CTRL for LCD and MIPI
>   drm/kmb: Set MSS_CAM_RSTN_CTRL along with enable
>   drm/kmb: Mipi DPHY initialization changes
>   drm/kmb: Fixed driver unload
>   drm/kmb: Added LCD_TEST config
>   drm/kmb: Changes for LCD to Mipi
>   drm/kmb: Update LCD programming to match MIPI
>   drm/kmb: Changed name of driver to kmb-drm
>   drm/kmb: Mipi settings from input timings
>   drm/kmb: Enable LCD interrupts
>   drm/kmb: Enable LCD interrupts during modeset
>   drm/kmb: Don’t inadvertantly disable LCD controller
>   drm/kmb: SWAP R and B LCD Layer order
>   drm/kmb: Disable ping pong mode
>   drm/kmb: Do the layer initializations only once
>   drm/kmb: disable the LCD layer in EOF irq handler
>   drm/kmb: Initialize uninitialized variables
>   drm/kmb: Added useful messages in LCD ISR
>   kmb/drm: Prune unsupported modes
>   drm/kmb: workaround for dma undeflow issue
>   drm/kmb: Get System Clock from SCMI
>   drm/kmb: work around for planar formats
> 
> Edmund Dea (7):
>   drm/kmb: Cleanup probe functions
>   drm/kmb: Revert dsi_host back to a static variable
>   drm/kmb: Initialize clocks for clk_msscam, clk_mipi_ecfg, &
> clk_mipi_cfg.
>   drm/kmb: Remove declaration of irq_lcd/irq_mipi
>   drm/kmb: Enable MIPI TX HS Test Pattern Generation
>   drm/kmb: Write to LCD_LAYERn_CFG only once
>   drm/kmb: Cleaned up code
> 
>  drivers/gpu/drm/Kconfig |2 +
>  drivers/gpu/drm/Makefile|1 +
>  drivers/gpu/drm/kmb/Kconfig |   12 +
>  drivers/gpu/drm/kmb/Makefile|2 +
>  drivers/gpu/drm/kmb/kmb_crtc.c  |  243 +
>  drivers/gpu/drm/kmb/kmb_crtc.h  |   61 ++
>  drivers/gpu/drm/kmb/kmb_drv.c   |  828 +
>  drivers/gpu/drm/kmb/kmb_drv.h   |  196 
>  drivers/gpu/drm/kmb/kmb_dsi.c   | 1950 
> +++
>  drivers/gpu/drm/kmb/kmb_dsi.h   |  390 
>  drivers/gpu/drm/kmb/kmb_plane.c |  538 +++
>  drivers/gpu/drm/kmb/kmb_plane.h |  142 +++
>  drivers/gpu/drm/kmb/kmb_regs.h  |  758 +++
>  13 files changed, 5123 insertions(+)
>  create mode 100644 drivers/gpu/drm/kmb/Kconfig
>  create mode 100644 drivers/gpu/drm/kmb/Makefile
>  create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.c
>  create mode 100644 drivers/gpu/drm/kmb/kmb_crtc.h
>  create mode 100644 drivers/gpu/drm/kmb/kmb_drv.c
>  create mode 100644 drivers/gpu/drm/kmb/kmb_drv.h
>  create mode 100644 drivers/gpu/drm/kmb/kmb_dsi.c
>

[Bug 208411] New: GPU reset end with ret = -110

https://bugzilla.kernel.org/show_bug.cgi?id=208411

Bug ID: 208411
   Summary: GPU reset end with ret = -110
   Product: Drivers
   Version: 2.5
Kernel Version: Mainline 5.7.6
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: phil2...@gmail.com
Regression: No

[ 1922.162071] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[ 1927.068795] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout,
signaled seq=13670, emitted seq=13672
[ 1927.068928] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process  pid 0 thread  pid 0
[ 1927.068934] amdgpu :03:00.0: GPU reset begin!
[ 1927.084510] [drm] [Link 0] WARNING MOD_HDCP_STATUS_DISPLAY_NOT_FOUND IN
STATE HDCP_UNINITIALIZED STAY COUNT 0
[ 1927.225062] amdgpu :03:00.0: GPU reset succeeded, trying to resume
[ 1927.225189] [drm] PCIE GART of 1024M enabled (table at 0x00F40090).
[ 1927.225215] [drm] VRAM is lost due to GPU reset!
[ 1927.225367] [drm] PSP is resuming...
[ 1927.225371] sos fw version = 0x110043.
[ 1927.245401] [drm] reserve 0x40 from 0xf41f80 for PSP TMR
[ 1927.545277] SMU is resuming...
[ 1927.545337] SMU is resumed successfully!
[ 1927.730819] [drm] kiq ring mec 2 pipe 1 q 0
[ 1927.877005] amdgpu :03:00.0: [drm:amdgpu_ring_test_helper [amdgpu]]
*ERROR* ring sdma0 test failed (-110)
[ 1927.877071] [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of
IP block  failed -110
[ 1927.877127] amdgpu :03:00.0: GPU reset(1) failed
[ 1927.877143] amdgpu :03:00.0: GPU reset end with ret = -110

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/hisilicon: Code refactoring for hibmc_drv_vdac

Thanks!

Am 02.07.20 um 10:54 schrieb Tian Tao:
> code refactoring for hibmc_drv_vdac.c, no actual function changes.
> 
> v2:
> remove the debug message.
> 
> v3:
> embedding connector and encoder in struct hibmc_drm_private.
> 
> Signed-off-by: Tian Tao 

Reviewed-by: Thomas Zimmermann 

Maybe others want to comment on the patch, so I'll give it a few more
days before I add it to drm-misc-next. Don't hesitate to ping me if I
forget about it.

Best regards
Thomas

> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  2 +
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 52 
> +---
>  2 files changed, 13 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> index 50a0c1f..6097687 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
> @@ -29,6 +29,8 @@ struct hibmc_drm_private {
>  
>   /* drm */
>   struct drm_device  *dev;
> + struct drm_encoder encoder;
> + struct drm_connector connector;
>   bool mode_config_initialized;
>  };
>  
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> index 678ac2e..2ca69c3 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
> @@ -52,32 +52,6 @@ static const struct drm_connector_funcs 
> hibmc_connector_funcs = {
>   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>  };
>  
> -static struct drm_connector *
> -hibmc_connector_init(struct hibmc_drm_private *priv)
> -{
> - struct drm_device *dev = priv->dev;
> - struct drm_connector *connector;
> - int ret;
> -
> - connector = devm_kzalloc(dev->dev, sizeof(*connector), GFP_KERNEL);
> - if (!connector) {
> - DRM_ERROR("failed to alloc memory when init connector\n");
> - return ERR_PTR(-ENOMEM);
> - }
> -
> - ret = drm_connector_init(dev, connector,
> -  _connector_funcs,
> -  DRM_MODE_CONNECTOR_VGA);
> - if (ret) {
> - DRM_ERROR("failed to init connector: %d\n", ret);
> - return ERR_PTR(ret);
> - }
> - drm_connector_helper_add(connector,
> -  _connector_helper_funcs);
> -
> - return connector;
> -}
> -
>  static void hibmc_encoder_mode_set(struct drm_encoder *encoder,
>  struct drm_display_mode *mode,
>  struct drm_display_mode *adj_mode)
> @@ -105,23 +79,10 @@ static const struct drm_encoder_funcs 
> hibmc_encoder_funcs = {
>  int hibmc_vdac_init(struct hibmc_drm_private *priv)
>  {
>   struct drm_device *dev = priv->dev;
> - struct drm_encoder *encoder;
> - struct drm_connector *connector;
> + struct drm_encoder *encoder = >encoder;
> + struct drm_connector *connector = >connector;
>   int ret;
>  
> - connector = hibmc_connector_init(priv);
> - if (IS_ERR(connector)) {
> - DRM_ERROR("failed to create connector: %ld\n",
> -   PTR_ERR(connector));
> - return PTR_ERR(connector);
> - }
> -
> - encoder = devm_kzalloc(dev->dev, sizeof(*encoder), GFP_KERNEL);
> - if (!encoder) {
> - DRM_ERROR("failed to alloc memory when init encoder\n");
> - return -ENOMEM;
> - }
> -
>   encoder->possible_crtcs = 0x1;
>   ret = drm_encoder_init(dev, encoder, _encoder_funcs,
>  DRM_MODE_ENCODER_DAC, NULL);
> @@ -131,6 +92,15 @@ int hibmc_vdac_init(struct hibmc_drm_private *priv)
>   }
>  
>   drm_encoder_helper_add(encoder, _encoder_helper_funcs);
> +
> + ret = drm_connector_init(dev, connector, _connector_funcs,
> +  DRM_MODE_CONNECTOR_VGA);
> + if (ret) {
> + DRM_ERROR("failed to init connector: %d\n", ret);
> + return ret;
> + }
> + drm_connector_helper_add(connector, _connector_helper_funcs);
> +
>   drm_connector_attach_encoder(connector, encoder);
>  
>   return 0;
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/8] drm/imx: Use __drm_atomic_helper_crtc_reset

2020-07-02 Thread Philipp Zabel

On Thu, 2020-07-02 at 11:41 +0200, Daniel Vetter wrote:
> On Wed, Jun 24, 2020 at 9:25 AM Daniel Vetter  wrote:
> > On Fri, Jun 12, 2020 at 06:00:51PM +0200, Daniel Vetter wrote:
> > > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > > which means vblank state isn't ill-defined and fail-y at driver load
> > > before the first modeset on each crtc.
> > > 
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Philipp Zabel 
> > > Cc: Shawn Guo 
> > > Cc: Sascha Hauer 
> > > Cc: Pengutronix Kernel Team 
> > > Cc: Fabio Estevam 
> > > Cc: NXP Linux Team 
> > > Cc: linux-arm-ker...@lists.infradead.org
> > 
> > Ping for some ack/review on this pls.
> 
> Still looking for an ack here so I can land this entire pile.
> -Daniel

Acked-by: Philipp Zabel 

regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: repair runtime power management

2020-07-02 Thread Philippe CORNU



On 7/1/20 2:14 PM, Yannick FERTRE wrote:
> 
> 
> On 3/9/20 12:57 PM, Marek Vasut wrote:
>> On 3/9/20 11:35 AM, Yannick FERTRE wrote:
>>> Hello Marek,
>>
>> Hi,
>>
>> (please stop top-posting)
>>
>>> Thank for your patch. Pm_runtime_put_sync is also done into function 
>>> ltdc_crtc_mode_fixup.
>>> To avoid several call of Pm_runtime_put_sync, it could be better to check 
>>> pm_runtime activity:
>>>
>>> +   int ret;
>>>
>>> DRM_DEBUG_DRIVER("\n");
>>>
>>> +   if (!pm_runtime_active(ddev->dev)) {
>>> +   ret = pm_runtime_get_sync(ddev->dev);
>>> +   if (ret) {
>>> +   DRM_ERROR("Failed to enable crtc, cannot get sync\n");
>>> +   return;
>>> +   }
>>> +   }
>>> +
>>
>> Where should this go ? And wouldn't that only hide nastier PM imbalance
>> issues ?
> Hi Marek,
> I tested the patch &  it generate an error when I try wake up / sleep
> the board STM32MP1 DK2 with weston application.
> It need an additional patch
> drm-stm-ltdc-remove-call-of-pm-runtime-functions.
> 
> Thanks for the patch.
> 
> Tested-by: Yannick Fertre 
> 

Hi Marek,
before merging the 2 patches, I would like to be sure that Yannick's 
patch does not "break" your use case (Qt I think)?
May I ask you please to give it a try?
Note: If you think there is no need to do extra checks, simply tell me 
of course
Philippe :-)

> 
>>
>>>Best regards
>>>
>>> Yannick Fertré
>>>
>>>
>>> -Original Message-
>>> From: Marek Vasut 
>>> Sent: samedi 29 février 2020 23:17
>>> To: dri-devel@lists.freedesktop.org
>>> Cc: Marek Vasut ; Yannick FERTRE ; 
>>> Philippe CORNU ; Benjamin Gaignard 
>>> ; Vincent ABRIOU ; 
>>> Maxime Coquelin ; Alexandre TORGUE 
>>> ; linux-st...@st-md-mailman.stormreply.com; 
>>> linux-arm-ker...@lists.infradead.org
>>> Subject: [PATCH] drm/stm: repair runtime power management
>>>
>>> Add missing pm_runtime_get_sync() into ltdc_crtc_atomic_enable() to match 
>>> pm_runtime_put_sync() in ltdc_crtc_atomic_disable(), otherwise the LTDC 
>>> might suspend via runtime PM, disable clock, and then fail to resume later 
>>> on.
>>>
>>> The test which triggers it is roughly -- run qt5 application which uses 
>>> eglfs platform and etnaviv, stop the application, sleep for 15 minutes, run 
>>> the application again. This leads to a timeout waiting for vsync, because 
>>> the LTDC has suspended, but did not resume.
>>>
>>> Fixes: 35ab6cfbf211 ("drm/stm: support runtime power management")
>>> Signed-off-by: Marek Vasut 
>>> Cc: Yannick Fertré 
>>> Cc: Philippe Cornu 
>>> Cc: Benjamin Gaignard 
>>> Cc: Vincent Abriou 
>>> Cc: Maxime Coquelin 
>>> Cc: Alexandre Torgue 
>>> To: dri-devel@lists.freedesktop.org
>>> Cc: linux-st...@st-md-mailman.stormreply.com
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> ---
>>> [ cut here ]
>>> WARNING: CPU: 0 PID: 297 at drivers/gpu/drm/drm_atomic_helper.c:1494 
>>> drm_atomic_helper_wait_for_vblanks+0x1dc/0x200
>>> [CRTC:35:crtc-0] vblank wait timed out
>>> Modules linked in:
>>> CPU: 0 PID: 297 Comm: QSGRenderThread Not tainted 
>>> 5.6.0-rc3-next-20200228-00010-g318bf0fc08ef #2 Hardware name: STM32 (Device 
>>> Tree Support) [] (unwind_backtrace) from [] 
>>> (show_stack+0x10/0x14) [] (show_stack) from [] 
>>> (dump_stack+0xb4/0xd0) [] (dump_stack) from [] 
>>> (__warn+0xd4/0xf0) [] (__warn) from [] 
>>> (warn_slowpath_fmt+0x78/0xa8) [] (warn_slowpath_fmt) from 
>>> [] (drm_atomic_helper_wait_for_vblanks+0x1dc/0x200)
>>> [] (drm_atomic_helper_wait_for_vblanks) from [] 
>>> (drm_atomic_helper_commit_tail+0
>>> x50/0x60)
>>> [] (drm_atomic_helper_commit_tail) from [] 
>>> (commit_tail+0x12c/0x13c) [] (commit_tail) from [] 
>>> (drm_atomic_helper_commit+0xf4/0x100)
>>> [] (drm_atomic_helper_commit) from [] 
>>> (drm_atomic_helper_set_config+0x58/0x6c)
>>> [] (drm_atomic_helper_set_config) from [] 
>>> (drm_mode_setcrtc+0x450/0x550) [] (drm_mode_setcrtc) from 
>>> [] (drm_ioctl_kernel+0x90/0xe8) [] (drm_ioctl_kernel) 
>>> from [] (drm_ioctl+0x2e4/0x32c) [] (drm_ioctl) from 
>>> [] (vfs_ioctl+0x20/0x38) [] (vfs_ioctl) from 
>>> [] (ksys_ioctl+0xbc/0x7b0) [] (ksys_ioctl) from 
>>> [] (ret_fast_syscall+0x0/0x54) Exception stack(0xee8f3fa8 to 
>>> 0xee8f3ff0)
>>> 3fa0:   0005 adcbeb18 0005 c06864a2 adcbeb18 
>>> 0001
>>> 3fc0: 0005 adcbeb18 c06864a2 0036 0029 0023 0023 
>>> 0007
>>> 3fe0: b113b098 adcbeafc b1125413 b6155cf8 ---[ end trace 2ad5ba954ceb767a 
>>> ]---
>>> ---
>>>drivers/gpu/drm/stm/ltdc.c | 3 +++
>>>1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 
>>> 99bf93e8b36f..301de0498078 100644
>>> --- a/drivers/gpu/drm/stm/ltdc.c
>>> +++ b/drivers/gpu/drm/stm/ltdc.c
>>> @@ -425,9 +425,12 @@ static void ltdc_crtc_atomic_enable(struct drm_crtc 
>>> *crtc,
>>> struct drm_crtc_state *old_state)  {
>>> struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>>>

Re: [PATCH 3/8] drm/imx: Use __drm_atomic_helper_crtc_reset

On Wed, Jun 24, 2020 at 9:25 AM Daniel Vetter  wrote:
>
> On Fri, Jun 12, 2020 at 06:00:51PM +0200, Daniel Vetter wrote:
> > Now also comes with the added benefit of doing a drm_crtc_vblank_off(),
> > which means vblank state isn't ill-defined and fail-y at driver load
> > before the first modeset on each crtc.
> >
> > Signed-off-by: Daniel Vetter 
> > Cc: Philipp Zabel 
> > Cc: Shawn Guo 
> > Cc: Sascha Hauer 
> > Cc: Pengutronix Kernel Team 
> > Cc: Fabio Estevam 
> > Cc: NXP Linux Team 
> > Cc: linux-arm-ker...@lists.infradead.org
>
> Ping for some ack/review on this pls.

Still looking for an ack here so I can land this entire pile.
-Daniel

>
> Thanks, Daniel
>
> > ---
> >  drivers/gpu/drm/imx/ipuv3-crtc.c | 21 -
> >  1 file changed, 8 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c 
> > b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > index 63c0284f8b3c..02c2f848f2d1 100644
> > --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> > +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> > @@ -109,20 +109,15 @@ static void imx_drm_crtc_reset(struct drm_crtc *crtc)
> >  {
> >   struct imx_crtc_state *state;
> >
> > - if (crtc->state) {
> > - if (crtc->state->mode_blob)
> > - drm_property_blob_put(crtc->state->mode_blob);
> > -
> > - state = to_imx_crtc_state(crtc->state);
> > - memset(state, 0, sizeof(*state));
> > - } else {
> > - state = kzalloc(sizeof(*state), GFP_KERNEL);
> > - if (!state)
> > - return;
> > - crtc->state = >base;
> > - }
> > + if (crtc->state)
> > + __drm_atomic_helper_crtc_destroy_state(crtc->state);
> >
> > - state->base.crtc = crtc;
> > + kfree(to_imx_crtc_state(crtc->state));
> > + crtc->state = NULL;
> > +
> > + state = kzalloc(sizeof(*state), GFP_KERNEL);
> > + if (state)
> > + __drm_atomic_helper_crtc_reset(crtc, >base);
> >  }
> >
> >  static struct drm_crtc_state *imx_drm_crtc_duplicate_state(struct drm_crtc 
> > *crtc)
> > --
> > 2.26.2
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

2020-07-02 Thread Simon Ser

On Thursday, July 2, 2020 9:47 AM, Neil Armstrong  
wrote:

> Finally is also adds the Scatter Memory layout, meaning the header contains 
> IOMMU
> references to the compressed frames content to optimize memory access
> and layout.
>
> In this mode, only the header memory address is needed, thus the content
> memory organization is tied to the current producer execution and cannot
> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> modifier.

Still not sure how to handle this one, since this breaks fundamental
assumptions about modifiers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/4] drm/msm: dsi: Use OPP API to set clk/perf state




On 7/1/2020 9:57 PM, Matthias Kaehlcke wrote:

On Tue, Jun 30, 2020 at 05:26:14PM +0530, Rajendra Nayak wrote:

On SDM845 DSI needs to express a perforamnce state


nit: performance


requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.

Signed-off-by: Rajendra Nayak 
---
  drivers/gpu/drm/msm/dsi/dsi.h  |  2 ++
  drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  4 +--
  drivers/gpu/drm/msm/dsi/dsi_host.c | 58 ++
  3 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 4de771d..ba7583c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -180,10 +180,12 @@ int msm_dsi_runtime_suspend(struct device *dev);
  int msm_dsi_runtime_resume(struct device *dev);
  int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host);
  int dsi_link_clk_set_rate_v2(struct msm_dsi_host *msm_host);
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host);
  int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host);
  int dsi_link_clk_enable_v2(struct msm_dsi_host *msm_host);
  void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host);
  void dsi_link_clk_disable_v2(struct msm_dsi_host *msm_host);
+void dsi_link_clk_disable_6g_v2(struct msm_dsi_host *msm_host);
  int dsi_tx_buf_alloc_6g(struct msm_dsi_host *msm_host, int size);
  int dsi_tx_buf_alloc_v2(struct msm_dsi_host *msm_host, int size);
  void *dsi_tx_buf_get_6g(struct msm_dsi_host *msm_host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 813d69d..773c4fe 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -210,9 +210,9 @@ static const struct msm_dsi_host_cfg_ops 
msm_dsi_6g_host_ops = {
  };
  
  static const struct msm_dsi_host_cfg_ops msm_dsi_6g_v2_host_ops = {

-   .link_clk_set_rate = dsi_link_clk_set_rate_6g,
+   .link_clk_set_rate = dsi_link_clk_set_rate_6g_v2,
.link_clk_enable = dsi_link_clk_enable_6g,
-   .link_clk_disable = dsi_link_clk_disable_6g,
+   .link_clk_disable = dsi_link_clk_disable_6g_v2,
.clk_init_ver = dsi_clk_init_6g_v2,
.tx_buf_alloc = dsi_tx_buf_alloc_6g,
.tx_buf_get = dsi_tx_buf_get_6g,
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 11ae5b8..890531c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -14,6 +14,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -111,6 +112,9 @@ struct msm_dsi_host {
struct clk *pixel_clk_src;
struct clk *byte_intf_clk;
  
+	struct opp_table *opp_table;

+   bool has_opp_table;
+
u32 byte_clk_rate;
u32 pixel_clk_rate;
u32 esc_clk_rate;
@@ -537,6 +541,38 @@ int dsi_link_clk_set_rate_6g(struct msm_dsi_host *msm_host)
return 0;
  }
  
+int dsi_link_clk_set_rate_6g_v2(struct msm_dsi_host *msm_host)

+{
+   int ret;
+   struct device *dev = _host->pdev->dev;
+
+   DBG("Set clk rates: pclk=%d, byteclk=%d",
+   msm_host->mode->clock, msm_host->byte_clk_rate);
+
+   ret = dev_pm_opp_set_rate(dev, msm_host->byte_clk_rate);
+   if (ret) {
+   pr_err("%s: dev_pm_opp_set_rate failed %d\n", __func__, ret);
+   return ret;
+   }
+
+   ret = clk_set_rate(msm_host->pixel_clk, msm_host->pixel_clk_rate);
+   if (ret) {
+   pr_err("%s: Failed to set rate pixel clk, %d\n", __func__, ret);
+   return ret;
+   }
+
+   if (msm_host->byte_intf_clk) {
+   ret = clk_set_rate(msm_host->byte_intf_clk,
+  msm_host->byte_clk_rate / 2);
+   if (ret) {
+   pr_err("%s: Failed to set rate byte intf clk, %d\n",
+  __func__, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}


xThis function is essentially the same as dsi_link_clk_set_rate_6g(),
except for the use of dev_pm_opp_set_rate() instead of clk_set_rate().

IIUC dev_pm_opp_set_rate() just calls clk_set_rate() if the device has
no OPP table. If that's correct you could just call dev_pm_opp_set_rate()
in dsi_link_clk_set_rate_6g().

/*
* For IO devices which require an OPP on some platforms/SoCs
* while just needing to scale the clock on some others
* we look for empty OPP tables with just a clock handle and
* scale only the clk. This makes dev_pm_opp_set_rate()
* equivalent to a clk_set_rate()
*/
if (!_get_opp_count(opp_table)) {
ret = _generic_set_opp_clk_only(dev, clk, freq);
goto put_opp_table;
}


ah, thats right, I think I had this code from before that support got
added to

Re: [PATCH RESEND v1] drm/meson: viu: fix setting the OSD burst length in VIU_OSD1_FIFO_CTRL_STAT

On 20/06/2020 17:57, Martin Blumenstingl wrote:
> The burst length is configured in VIU_OSD1_FIFO_CTRL_STAT[31] and
> VIU_OSD1_FIFO_CTRL_STAT[11:10]. The public S905D3 datasheet describes
> this as:
> - 0x0 = up to 24 per burst
> - 0x1 = up to 32 per burst
> - 0x2 = up to 48 per burst
> - 0x3 = up to 64 per burst
> - 0x4 = up to 96 per burst
> - 0x5 = up to 128 per burst
> 
> The lower two bits map to VIU_OSD1_FIFO_CTRL_STAT[11:10] while the upper
> bit maps to VIU_OSD1_FIFO_CTRL_STAT[31].
> 
> Replace meson_viu_osd_burst_length_reg() with pre-defined macros which
> set these values. meson_viu_osd_burst_length_reg() always returned 0
> (for the two used values: 32 and 64 at least) and thus incorrectly set
> the burst size to 24.
> 
> Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic 
> constants")
> Signed-off-by: Martin Blumenstingl 

Reviewed-by: Neil Armstrong 

I also got an off-list:

Tested-by: Christian Hewitt 

Applying to drm-misc-fixes

Thanks,
Neil

> ---
> re-send of v1 [0] with no changes as I still noticed that this is
> sitting in my tree and I wasn't asked to change anything in v1.
> 
> 
> [0] https://patchwork.kernel.org/patch/11510045/
> 
> 
>  drivers/gpu/drm/meson/meson_registers.h |  6 ++
>  drivers/gpu/drm/meson/meson_viu.c   | 11 ++-
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/meson/meson_registers.h 
> b/drivers/gpu/drm/meson/meson_registers.h
> index 8ea00546cd4e..049c4bfe2a3a 100644
> --- a/drivers/gpu/drm/meson/meson_registers.h
> +++ b/drivers/gpu/drm/meson/meson_registers.h
> @@ -261,6 +261,12 @@
>  #define VIU_OSD_FIFO_DEPTH_VAL(val)  ((val & 0x7f) << 12)
>  #define VIU_OSD_WORDS_PER_BURST(words)   (((words & 0x4) >> 1) << 22)
>  #define VIU_OSD_FIFO_LIMITS(size)((size & 0xf) << 24)
> +#define VIU_OSD_BURST_LENGTH_24  (0x0 << 31 | 0x0 << 10)
> +#define VIU_OSD_BURST_LENGTH_32  (0x0 << 31 | 0x1 << 10)
> +#define VIU_OSD_BURST_LENGTH_48  (0x0 << 31 | 0x2 << 10)
> +#define VIU_OSD_BURST_LENGTH_64  (0x0 << 31 | 0x3 << 10)
> +#define VIU_OSD_BURST_LENGTH_96  (0x1 << 31 | 0x0 << 10)
> +#define VIU_OSD_BURST_LENGTH_128 (0x1 << 31 | 0x1 << 10)
>  
>  #define VD1_IF0_GEN_REG 0x1a50
>  #define VD1_IF0_CANVAS0 0x1a51
> diff --git a/drivers/gpu/drm/meson/meson_viu.c 
> b/drivers/gpu/drm/meson/meson_viu.c
> index 304f8ff1339c..aede0c67a57f 100644
> --- a/drivers/gpu/drm/meson/meson_viu.c
> +++ b/drivers/gpu/drm/meson/meson_viu.c
> @@ -411,13 +411,6 @@ void meson_viu_gxm_disable_osd1_afbc(struct meson_drm 
> *priv)
>   priv->io_base + _REG(VIU_MISC_CTRL1));
>  }
>  
> -static inline uint32_t meson_viu_osd_burst_length_reg(uint32_t length)
> -{
> - uint32_t val = (((length & 0x80) % 24) / 12);
> -
> - return (((val & 0x3) << 10) | (((val & 0x4) >> 2) << 31));
> -}
> -
>  void meson_viu_init(struct meson_drm *priv)
>  {
>   uint32_t reg;
> @@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv)
>   VIU_OSD_FIFO_LIMITS(2);  /* fifo_lim: 2*16=32 */
>  
>   if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> - reg |= meson_viu_osd_burst_length_reg(32);
> + reg |= VIU_OSD_BURST_LENGTH_32;
>   else
> - reg |= meson_viu_osd_burst_length_reg(64);
> + reg |= VIU_OSD_BURST_LENGTH_64;
>  
>   writel_relaxed(reg, priv->io_base + _REG(VIU_OSD1_FIFO_CTRL_STAT));
>   writel_relaxed(reg, priv->io_base + _REG(VIU_OSD2_FIFO_CTRL_STAT));
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"

2020-07-02 Thread Christian König


Am 02.07.20 um 10:26 schrieb Lionel Landwerlin:

On 25/06/2020 15:43, Christian König wrote:

Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:

This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.

This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point in the timeline.

In a timeline, a particular value is reached when all the points up to
and including that value have signaled.

Signed-off-by: Lionel Landwerlin 


Reviewed-by: Christian König 



Now that you are a maintainer, feel free to merge this and the test 
changes.


Sure, I will pick that up later today :)

Christian.




Thanks,


-Lionel





---
  drivers/dma-buf/dma-fence-chain.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c

index c435bbba851c..3d123502ff12 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence 
**pfence, uint64_t seqno)

  return -EINVAL;
    dma_fence_chain_for_each(*pfence, >base) {
-    if ((*pfence)->seqno < seqno) { /* already signaled */
-    dma_fence_put(*pfence);
-    *pfence = NULL;
-    break;
-    }
-
  if ((*pfence)->context != chain->base.context ||
  to_dma_fence_chain(*pfence)->prev_seqno < seqno)
  break;
@@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
   * @chain: the chain node to initialize
   * @prev: the previous fence
   * @fence: the current fence
- * @seqno: the sequence number (syncpt) of the fence within the chain
   *
   * Initialize a new chain node and either start a new chain or add 
the node to

   * the existing chain of the previous fence.






___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/hisilicon: Use drmm_kzalloc() instead of devm_kzalloc()

Thanks! Applied to drm-misc-next

Best regards
Thomas

Am 02.07.20 um 09:49 schrieb Tian Tao:
> using the new API drmm_kzalloc() instead of devm_kzalloc()
> 
> v3:
> still fixed include statements sorted alphabetically.
> 
> v2:
> keep the DRM include statements sorted alphabetically.
> 
> Signed-off-by: Tian Tao 
> Reviewed-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index a6fd0c2..249c298 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -267,7 +268,7 @@ static int hibmc_load(struct drm_device *dev)
>   struct hibmc_drm_private *priv;
>   int ret;
>  
> - priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
> + priv = drmm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>   if (!priv) {
>   DRM_ERROR("no memory to allocate for hibmc_drm_private\n");
>   return -ENOMEM;
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] Revert "dma-buf: Report signaled links inside dma-fence-chain"

2020-07-02 Thread Lionel Landwerlin


On 25/06/2020 15:43, Christian König wrote:

Am 25.06.20 um 14:34 schrieb Lionel Landwerlin:

This reverts commit 5de376bb434f80a13138f0ebedc8351ab73d8b0d.

This change breaks synchronization of a timeline.
dma_fence_chain_find_seqno() might be a bit of a confusing name but
this function is not trying to find a particular seqno, is supposed to
give a fence to wait on for a particular point in the timeline.

In a timeline, a particular value is reached when all the points up to
and including that value have signaled.

Signed-off-by: Lionel Landwerlin 


Reviewed-by: Christian König 



Now that you are a maintainer, feel free to merge this and the test changes.


Thanks,


-Lionel





---
  drivers/dma-buf/dma-fence-chain.c | 7 ---
  1 file changed, 7 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c

index c435bbba851c..3d123502ff12 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -99,12 +99,6 @@ int dma_fence_chain_find_seqno(struct dma_fence 
**pfence, uint64_t seqno)

  return -EINVAL;
    dma_fence_chain_for_each(*pfence, >base) {
-    if ((*pfence)->seqno < seqno) { /* already signaled */
-    dma_fence_put(*pfence);
-    *pfence = NULL;
-    break;
-    }
-
  if ((*pfence)->context != chain->base.context ||
  to_dma_fence_chain(*pfence)->prev_seqno < seqno)
  break;
@@ -228,7 +222,6 @@ EXPORT_SYMBOL(dma_fence_chain_ops);
   * @chain: the chain node to initialize
   * @prev: the previous fence
   * @fence: the current fence
- * @seqno: the sequence number (syncpt) of the fence within the chain
   *
   * Initialize a new chain node and either start a new chain or add 
the node to

   * the existing chain of the previous fence.




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for 5.8-rc1

2020-07-02 Thread Daniel Stone

Hi,

On Wed, 1 Jul 2020 at 20:45, James Jones  wrote:
> OK, I think I see what's going on.  In the Xorg modesetting driver, the
> logic is basically:
>
> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
>drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
> } else {
>drmModeAddFB(...);
> }

I read this thread expecting to explain the correct behaviour we
implement in Weston and how modesetting needs to be fixed, but ...
that seems OK to me? As long as `gbm_has_modifiers` is a proxy for 'we
used gbm_(bo|surface)_create_with_modifiers to allocate the buffer'.

> There's no attempt to verify the DRM-KMS device supports the modifier,
> but then, why would there be?  GBM presumably chose a supported modifier
> at buffer creation time, and we don't know which plane the FB is going
> to be used with yet.  GBM doesn't actually ask the kernel which
> modifiers it supports here either though.

Right, it doesn't ask, because userspace tells it which modifiers to
use. The correct behaviour is to take the list from the KMS
`IN_FORMATS` property and then pass that to
`gbm_(bo|surface)_create_with_modifiers`; GBM must then select from
that list and only that list. If that call does not succeed and Xorg
falls back to `gbm_surface_create`, then it must not call
`gbm_bo_get_modifier` - so that would be a modesetting bug. If that
call does succeed and `gbm_bo_get_modifier` subsequently reports a
modifier which was not in the list, that's a Mesa driver bug.

> It just goes into Mesa via
> DRI and reports the modifier (unpatched) Mesa chose on its own.  Mesa
> just hard-codes the modifiers in its driver backends since its thinking
> in terms of a device's 3D engine, not display.  In theory, Mesa's DRI
> drivers could query KMS for supported modifiers if allocating from GBM
> using the non-modifiers path and the SCANOUT flag is set (perhaps some
> drivers do this or its equivalent?  Haven't checked.), but that seems
> pretty gnarly and doesn't fix the modifier-based GBM allocation path
> AFAIK.  Bit of a mess.

Two options for GBM users:
* call gbm_*_create_with_modifiers, it succeeds, call
gbm_bo_get_modifier, pass modifier into AddFB
* call gbm_*_create (without modifiers), it succeeds, do not call
gbm_bo_get_modifier, do not pass a modifier into AddFB

Anything else is a bug in the user. Note that falling back from 1 to 2
is fine: if `gbm_*_create_with_modifiers()` fails, you can fall back
to the non-modifier path, provided you don't later try to get a
modifier back out.

> For a quick userspace fix that could probably be pushed out everywhere
> (Only affects Xorg server 1.20+ AFAIK), just retrying
> drmModeAddFB2WithModifiers() without the DRM_MODE_FB_MODIFIERS flag on
> failure should be sufficient.

This would break other drivers.

> Still need to verify as I'm having
> trouble wrangling my Xorg build at the moment and I'm pressed for time.
> A more complete fix would be quite involved, as modesetting isn't really
> properly plumbed to validate GBM's modifiers against KMS planes, and it
> doesn't seem like GBM/Mesa/DRI should be responsible for this as noted
> above given the general modifier workflow/design.
>
> Most importantly, options I've considered for fixing from the kernel side:
>
> -Accept "legacy" modifiers in nouveau in addition to the new modifiers,
> though avoid reporting them to userspace as supported to avoid further
> proliferation.  This is pretty straightforward.  I'll need to modify
> both the AddFB2 handler (nouveau_validate_decode_mod) and the mode set
> plane validation logic (nv50_plane_format_mod_supported), but it should
> end up just being a few lines of code.

I do think that they should also be reported to userspace if they are
accepted. Other users can and do look at the modifier list to see if
the buffer is acceptable for a given plane, so the consistency is good
here. Of course, in Mesa you would want to prioritise the new
modifiers over the legacy ones, and not allocate or return the legacy
ones unless that was all you were asked for. This would involve
tracking the used modifier explicitly through Mesa, rather than
throwing it away at alloc time and then later divining it from the
tiling mode.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/16] backlight updates

2020-07-02 Thread Sam Ravnborg

Hi Emil.

Long overdue feedback, I did not find time to go back to this patch-set
until now.

On Tue, Jun 02, 2020 at 03:04:39PM +0100, Emil Velikov wrote:
> Hi Sam,
> 
> On Mon, 1 Jun 2020 at 07:52, Sam Ravnborg  wrote:
> >
> > v3:
> >  - Dropped video patch that was reviewd and thus applied
> >  - Updated kernel-doc so all fields now have a short intro
> >  - Improved readability in a lot of places, thanks to review
> >feedback from Daniel - thanks!
> >  - Added better intro to backlight
> >  - Added acks
> >
> >Several other smaller changes documented in the
> >patches.
> >I left out patches to make functions static as
> >there are dependencies to drm-misc-next for these.
> >When this is landed I have a pile of follow-up patches waiting,
> >mostly introducing backlight_is_blank() all over.
> >
> What happened with my suggestion to use backlight_is_blank() in fbdev
> core itself?
Following your suggestion I implemented:

+static inline int backlight_get_brightness(struct backlight_device *bd)
+{
+   if (backlight_is_blank(bd))
+   return 0;
+   else
+   return bd->props.brightness;
+}

This results in code like this:

static int adp8870_bl_update_status(struct backlight_device *bl)
{
return adp8870_bl_set(bl, backlight_get_brightness(bl));
}

Compare that with the original code:
static int adp8870_bl_update_status(struct backlight_device *bl)
{
int brightness = bl->props.brightness;

if (bl->props.power != FB_BLANK_UNBLANK)
brightness = 0;

if (bl->props.fb_blank != FB_BLANK_UNBLANK)
brightness = 0;

return adp8870_bl_set(bl, brightness);
}

Much nicer!

The old code reads the brightness property direct.
I prefer the small helper so we do not hardcode too much of the
internals in the drivers.
Also the above is simpler than trying to maintain the correct value in
props.brightness all the time. And can be introduced gradually.

I will rework the series to use this helper.
I will also fix so I can use a const backlight_device *.

Thanks for the suggestion.

Sam


> It effectively makes 13/13 and the above mentioned follow-up series obsolete.
> 
> That said, series look spot on. With the documentation fixed (pointer
> by Daniel) patches 1-12 are:
> Reviewed-by: Emil Velikov 
> 
> -Emil
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for 5.8-rc1

2020-07-02 Thread Pekka Paalanen

On Wed, 1 Jul 2020 12:45:48 -0700
James Jones  wrote:

> OK, I think I see what's going on.  In the Xorg modesetting driver, the 
> logic is basically:
> 
> if (gbm_has_modifiers && DRM_CAP_ADDFB2_MODIFIERS != 0) {
>drmModeAddFB2WithModifiers(..., gbm_bo_get_modifier(bo->gbm));
> } else {
>drmModeAddFB(...);
> }
> 
> There's no attempt to verify the DRM-KMS device supports the modifier, 
> but then, why would there be?  GBM presumably chose a supported modifier 
> at buffer creation time, and we don't know which plane the FB is going 
> to be used with yet.  GBM doesn't actually ask the kernel which 
> modifiers it supports here either though.  It just goes into Mesa via 
> DRI and reports the modifier (unpatched) Mesa chose on its own.  Mesa 
> just hard-codes the modifiers in its driver backends since its thinking 
> in terms of a device's 3D engine, not display.  In theory, Mesa's DRI 
> drivers could query KMS for supported modifiers if allocating from GBM 
> using the non-modifiers path and the SCANOUT flag is set (perhaps some 
> drivers do this or its equivalent?  Haven't checked.), but that seems 
> pretty gnarly and doesn't fix the modifier-based GBM allocation path 
> AFAIK.  Bit of a mess.

Hi,

the way I believe it is supposed to work is that modesetting DDX first
asks KMS what modifiers it supports, and then passes that list to GBM
when it is attempting to create a gbm_bo or a gbm_surface. If
modesetting does not do that and still uses modifiers API for creating
bos or surfaces, modesetting is broken I believe.

gbm_bo_create_with_modifiers()
gbm_surface_create_with_modifiers()

Of course, this doesn't affect the need of a kernel workaround.

How is modesetting creating the bo or surface currently?

Why would the KMS driver starting to support modifiers API suddenly
make the buffers fail, does it change how the buffers get allocated in
modesetting as well?

Or maybe you're talking about something else than what I assumed, I'm
not really up-to-date here.

Thanks,
pq

pgpggF86EMpP7.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-fixes

Hi Dave and Daniel,

here's the PR for the current drm-misc-fixes.

Best regards
Thomas

drm-misc-fixes-2020-07-02:
 * dma-buf: fix a use-after-free bug

 * sun4i: remove HPD polling
The following changes since commit dc5bdb68b5b369d5bc7d1de96fa64cc1737a6320:

  drm/fb-helper: Fix vt restore (2020-06-24 21:34:11 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2020-07-02

for you to fetch changes up to bda8eaa6dee7525f4dac950810a85a88bf6c2ba0:

  drm: sun4i: hdmi: Remove extra HPD polling (2020-06-30 10:01:48 +0200)


 * dma-buf: fix a use-after-free bug

 * sun4i: remove HPD polling


Chen-Yu Tsai (1):
  drm: sun4i: hdmi: Remove extra HPD polling

Sumit Semwal (1):
  dma-buf: Move dma_buf_release() from fops to dentry_ops

 drivers/dma-buf/dma-buf.c  | 54 --
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |  5 ++--
 2 files changed, 27 insertions(+), 32 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 6/6] drm/meson: crtc: handle commit of Amlogic FBC frames

Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.

Tested-by: Kevin Hilman 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_crtc.c | 118 +
 1 file changed, 88 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c 
b/drivers/gpu/drm/meson/meson_crtc.c
index e66b6271ff58..2854272dc2d9 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -291,6 +291,10 @@ static void meson_crtc_enable_vd1(struct meson_drm *priv)
VPP_VD1_PREBLEND | VPP_VD1_POSTBLEND |
VPP_COLOR_MNG_ENABLE,
priv->io_base + _REG(VPP_MISC));
+
+   writel_bits_relaxed(VIU_CTRL0_AFBC_TO_VD1,
+   priv->viu.vd1_afbc ? VIU_CTRL0_AFBC_TO_VD1 : 0,
+   priv->io_base + _REG(VIU_MISC_CTRL0));
 }
 
 static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
@@ -300,6 +304,10 @@ static void meson_g12a_crtc_enable_vd1(struct meson_drm 
*priv)
   VD_BLEND_POSTBLD_SRC_VD1 |
   VD_BLEND_POSTBLD_PREMULT_EN,
   priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+
+   writel_relaxed(priv->viu.vd1_afbc ?
+  (VD1_AXI_SEL_AFBC | AFBC_VD1_SEL) : 0,
+  priv->io_base + _REG(VD1_AFBCD0_MISC_CTRL));
 }
 
 void meson_crtc_irq(struct meson_drm *priv)
@@ -383,36 +391,86 @@ void meson_crtc_irq(struct meson_drm *priv)
/* Update the VD1 registers */
if (priv->viu.vd1_enabled && priv->viu.vd1_commit) {
 
-   switch (priv->viu.vd1_planes) {
-   case 3:
-   meson_canvas_config(priv->canvas,
-   priv->canvas_id_vd1_2,
-   priv->viu.vd1_addr2,
-   priv->viu.vd1_stride2,
-   priv->viu.vd1_height2,
-   MESON_CANVAS_WRAP_NONE,
-   MESON_CANVAS_BLKMODE_LINEAR,
-   MESON_CANVAS_ENDIAN_SWAP64);
-   /* fallthrough */
-   case 2:
-   meson_canvas_config(priv->canvas,
-   priv->canvas_id_vd1_1,
-   priv->viu.vd1_addr1,
-   priv->viu.vd1_stride1,
-   priv->viu.vd1_height1,
-   MESON_CANVAS_WRAP_NONE,
-   MESON_CANVAS_BLKMODE_LINEAR,
-   MESON_CANVAS_ENDIAN_SWAP64);
-   /* fallthrough */
-   case 1:
-   meson_canvas_config(priv->canvas,
-   priv->canvas_id_vd1_0,
-   priv->viu.vd1_addr0,
-   priv->viu.vd1_stride0,
-   priv->viu.vd1_height0,
-   MESON_CANVAS_WRAP_NONE,
-   MESON_CANVAS_BLKMODE_LINEAR,
-   MESON_CANVAS_ENDIAN_SWAP64);
+   if (priv->viu.vd1_afbc) {
+   writel_relaxed(priv->viu.vd1_afbc_head_addr,
+  priv->io_base +
+  _REG(AFBC_HEAD_BADDR));
+   writel_relaxed(priv->viu.vd1_afbc_body_addr,
+  priv->io_base +
+  _REG(AFBC_BODY_BADDR));
+   writel_relaxed(priv->viu.vd1_afbc_en,
+  priv->io_base +
+  _REG(AFBC_ENABLE));
+   writel_relaxed(priv->viu.vd1_afbc_mode,
+  priv->io_base +
+  _REG(AFBC_MODE));
+   writel_relaxed(priv->viu.vd1_afbc_size_in,
+  priv->io_base +
+  _REG(AFBC_SIZE_IN));
+   writel_relaxed(priv->viu.vd1_afbc_dec_def_color,
+  priv->io_base +
+  _REG(AFBC_DEC_DEF_COLOR));
+   writel_relaxed(priv->viu.vd1_afbc_conv_ctrl,
+  priv->io_base +
+  _REG(AFBC_CONV_CTRL));
+   writel_relaxed(priv->viu.vd1_afbc_size_out,
+  priv->io_base +
+

[PATCH v8 5/6] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout

Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.

Tested-by: Kevin Hilman 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_overlay.c | 53 ++-
 1 file changed, 35 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index 1566a887d482..1f7b2055e012 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -490,6 +490,10 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
AMLOGIC_FBC_OPTION_MEM_SAVING))
priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
 
+   if ((fb->modifier & __fourcc_mod_amlogic_layout_mask) ==
+   AMLOGIC_FBC_LAYOUT_SCATTER)
+   priv->viu.vd1_afbc_mode |= AFBC_SCATTER_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
 
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -675,23 +679,32 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
}
 
if (priv->viu.vd1_afbc) {
-   /* Default mode is 4k per superblock */
-   unsigned long block_size = 4096;
-   unsigned long body_size;
-
-   /* 8bit mem saving mode is 3072bytes per superblock */
-   if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
-   block_size = 3072;
-
-   body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
-   (ALIGN(priv->viu.vd1_height0, 32) / 32) *
-   block_size;
-
-   priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
-
-   /* Header is after body content */
-   priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
-   body_size) >> 4;
+   if (priv->viu.vd1_afbc_mode & AFBC_SCATTER_MODE) {
+   /*
+* In Scatter mode, the header contains the physical
+* body content layout, thus the body content
+* size isn't needed.
+*/
+   priv->viu.vd1_afbc_head_addr = priv->viu.vd1_addr0 >> 4;
+   priv->viu.vd1_afbc_body_addr = 0;
+   } else {
+   /* Default mode is 4k per superblock */
+   unsigned long block_size = 4096;
+   unsigned long body_size;
+
+   /* 8bit mem saving mode is 3072bytes per superblock */
+   if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+   block_size = 3072;
+
+   body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+   (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+   block_size;
+
+   priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+   /* Header is after body content */
+   priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+   body_size) >> 4;
+   }
}
 
priv->viu.vd1_enabled = true;
@@ -754,7 +767,8 @@ static bool meson_overlay_format_mod_supported(struct 
drm_plane *plane,
return false;
}
 
-   if (layout != AMLOGIC_FBC_LAYOUT_BASIC) {
+   if (layout != AMLOGIC_FBC_LAYOUT_BASIC &&
+   layout != AMLOGIC_FBC_LAYOUT_SCATTER) {
DRM_DEBUG_KMS("%llx invalid layout %x\n",
  modifier, layout);
return false;
@@ -800,8 +814,11 @@ static const uint32_t supported_drm_formats[] = {
 };
 
 static const uint64_t format_modifiers[] = {
+   DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_SCATTER,
+  AMLOGIC_FBC_OPTION_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC,
   AMLOGIC_FBC_OPTION_MEM_SAVING),
+   DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_SCATTER, 0),
DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC, 0),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 2/6] drm/meson: add Amlogic Video FBC registers

Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing
register.

Tested-by: Kevin Hilman 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_registers.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_registers.h 
b/drivers/gpu/drm/meson/meson_registers.h
index 8ea00546cd4e..08631fdfe4b9 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -144,10 +144,15 @@
 #defineVIU_SW_RESET_OSD1   BIT(0)
 #define VIU_MISC_CTRL0 0x1a06
 #defineVIU_CTRL0_VD1_AFBC_MASK 0x17
+#defineVIU_CTRL0_AFBC_TO_VD1   BIT(20)
 #define VIU_MISC_CTRL1 0x1a07
 #defineMALI_AFBC_MISC  GENMASK(15, 8)
 #define D2D3_INTF_LENGTH 0x1a08
 #define D2D3_INTF_CTRL0 0x1a09
+#define VD1_AFBCD0_MISC_CTRL 0x1a0a
+#defineVD1_AXI_SEL_AFBC(1 << 12)
+#defineAFBC_VD1_SEL(1 << 10)
+#define VD2_AFBCD1_MISC_CTRL 0x1a0b
 #define VIU_OSD1_CTRL_STAT 0x1a10
 #defineVIU_OSD1_OSD_BLK_ENABLE BIT(0)
 #defineVIU_OSD1_OSD_MEM_MODE_LINEARBIT(2)
@@ -365,6 +370,23 @@
 #define VIU_OSD1_OETF_LUT_ADDR_PORT 0x1add
 #define VIU_OSD1_OETF_LUT_DATA_PORT 0x1ade
 #define AFBC_ENABLE 0x1ae0
+#define AFBC_MODE 0x1ae1
+#define AFBC_SIZE_IN 0x1ae2
+#define AFBC_DEC_DEF_COLOR 0x1ae3
+#define AFBC_CONV_CTRL 0x1ae4
+#define AFBC_LBUF_DEPTH 0x1ae5
+#define AFBC_HEAD_BADDR 0x1ae6
+#define AFBC_BODY_BADDR 0x1ae7
+#define AFBC_SIZE_OUT 0x1ae8
+#define AFBC_OUT_YSCOPE 0x1ae9
+#define AFBC_STAT 0x1aea
+#define AFBC_VD_CFMT_CTRL 0x1aeb
+#define AFBC_VD_CFMT_W 0x1aec
+#define AFBC_MIF_HOR_SCOPE 0x1aed
+#define AFBC_MIF_VER_SCOPE 0x1aee
+#define AFBC_PIXEL_HOR_SCOPE 0x1aef
+#define AFBC_PIXEL_VER_SCOPE 0x1af0
+#define AFBC_VD_CFMT_H 0x1af1
 
 /* vpp */
 #define VPP_DUMMY_DATA 0x1d00
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 4/6] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode

Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.

Tested-by: Kevin Hilman 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_overlay.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index 293f606ba164..1566a887d482 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -486,6 +486,10 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
  AFBC_HOLD_LINE_NUM(8) |
  AFBC_BURST_LEN(2);
 
+   if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC(0,
+   AMLOGIC_FBC_OPTION_MEM_SAVING))
+   priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+
priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
 
priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -671,12 +675,17 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
}
 
if (priv->viu.vd1_afbc) {
+   /* Default mode is 4k per superblock */
+   unsigned long block_size = 4096;
unsigned long body_size;
 
-   /* Default mode is 4k per superblock */
+   /* 8bit mem saving mode is 3072bytes per superblock */
+   if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+   block_size = 3072;
+
body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
(ALIGN(priv->viu.vd1_height0, 32) / 32) *
-   4096;
+   block_size;
 
priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
 
@@ -734,6 +743,9 @@ static bool meson_overlay_format_mod_supported(struct 
drm_plane *plane,
unsigned int layout = modifier &
DRM_FORMAT_MOD_AMLOGIC_FBC(
__fourcc_mod_amlogic_layout_mask, 0);
+   unsigned int options =
+   (modifier >> __fourcc_mod_amlogic_options_shift) &
+   __fourcc_mod_amlogic_options_mask;
 
if (format != DRM_FORMAT_YUV420_8BIT &&
format != DRM_FORMAT_YUV420_10BIT) {
@@ -748,6 +760,13 @@ static bool meson_overlay_format_mod_supported(struct 
drm_plane *plane,
return false;
}
 
+   if (options &&
+   options != AMLOGIC_FBC_OPTION_MEM_SAVING) {
+   DRM_DEBUG_KMS("%llx invalid layout %x\n",
+ modifier, layout);
+   return false;
+   }
+
return true;
}
 
@@ -781,6 +800,8 @@ static const uint32_t supported_drm_formats[] = {
 };
 
 static const uint64_t format_modifiers[] = {
+   DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC,
+  AMLOGIC_FBC_OPTION_MEM_SAVING),
DRM_FORMAT_MOD_AMLOGIC_FBC(AMLOGIC_FBC_LAYOUT_BASIC, 0),
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID,
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 3/6] drm/meson: overlay: setup overlay for Amlogic FBC

Setup the Amlogic FBC decoder for the VD1 video overlay plane.

The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.

This adds support for the basic layout, and needs to calculate the content
body size since the header is allocated after.

Tested-by: Kevin Hilman 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/meson/meson_drv.h |  16 ++
 drivers/gpu/drm/meson/meson_overlay.c | 251 +-
 2 files changed, 259 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.h 
b/drivers/gpu/drm/meson/meson_drv.h
index 5b23704a80d6..177dac3ca3be 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -86,6 +86,7 @@ struct meson_drm {
 
bool vd1_enabled;
bool vd1_commit;
+   bool vd1_afbc;
unsigned int vd1_planes;
uint32_t vd1_if0_gen_reg;
uint32_t vd1_if0_luma_x0;
@@ -111,6 +112,21 @@ struct meson_drm {
uint32_t vd1_height0;
uint32_t vd1_height1;
uint32_t vd1_height2;
+   uint32_t vd1_afbc_mode;
+   uint32_t vd1_afbc_en;
+   uint32_t vd1_afbc_head_addr;
+   uint32_t vd1_afbc_body_addr;
+   uint32_t vd1_afbc_conv_ctrl;
+   uint32_t vd1_afbc_dec_def_color;
+   uint32_t vd1_afbc_vd_cfmt_ctrl;
+   uint32_t vd1_afbc_vd_cfmt_w;
+   uint32_t vd1_afbc_vd_cfmt_h;
+   uint32_t vd1_afbc_mif_hor_scope;
+   uint32_t vd1_afbc_mif_ver_scope;
+   uint32_t vd1_afbc_size_out;
+   uint32_t vd1_afbc_pixel_hor_scope;
+   uint32_t vd1_afbc_pixel_ver_scope;
+   uint32_t vd1_afbc_size_in;
uint32_t vpp_pic_in_height;
uint32_t vpp_postblend_vd1_h_start_end;
uint32_t vpp_postblend_vd1_v_start_end;
diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index 2468b0212d52..293f606ba164 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -76,6 +76,84 @@
 #define VD_REGION24_START(value)   FIELD_PREP(GENMASK(11, 0), value)
 #define VD_REGION13_END(value) FIELD_PREP(GENMASK(27, 16), value)
 
+/* AFBC_ENABLE */
+#define AFBC_DEC_ENABLEBIT(8)
+#define AFBC_FRM_START BIT(0)
+
+/* AFBC_MODE */
+#define AFBC_HORZ_SKIP_UV(value)   FIELD_PREP(GENMASK(1, 0), value)
+#define AFBC_VERT_SKIP_UV(value)   FIELD_PREP(GENMASK(3, 2), value)
+#define AFBC_HORZ_SKIP_Y(value)FIELD_PREP(GENMASK(5, 4), value)
+#define AFBC_VERT_SKIP_Y(value)FIELD_PREP(GENMASK(7, 6), value)
+#define AFBC_COMPBITS_YUV(value)   FIELD_PREP(GENMASK(13, 8), value)
+#define AFBC_COMPBITS_8BIT 0
+#define AFBC_COMPBITS_10BIT(2 | (2 << 2) | (2 << 4))
+#define AFBC_BURST_LEN(value)  FIELD_PREP(GENMASK(15, 14), value)
+#define AFBC_HOLD_LINE_NUM(value)  FIELD_PREP(GENMASK(22, 16), value)
+#define AFBC_MIF_URGENT(value) FIELD_PREP(GENMASK(25, 24), value)
+#define AFBC_REV_MODE(value)   FIELD_PREP(GENMASK(27, 26), value)
+#define AFBC_BLK_MEM_MODE  BIT(28)
+#define AFBC_SCATTER_MODE  BIT(29)
+#define AFBC_SOFT_RESETBIT(31)
+
+/* AFBC_SIZE_IN */
+#define AFBC_HSIZE_IN(value)   FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_IN(value)   FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_DEC_DEF_COLOR */
+#define AFBC_DEF_COLOR_Y(value)FIELD_PREP(GENMASK(29, 20), 
value)
+#define AFBC_DEF_COLOR_U(value)FIELD_PREP(GENMASK(19, 10), 
value)
+#define AFBC_DEF_COLOR_V(value)FIELD_PREP(GENMASK(9, 0), value)
+
+/* AFBC_CONV_CTRL */
+#define AFBC_CONV_LBUF_LEN(value)  FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_LBUF_DEPTH */
+#define AFBC_DEC_LBUF_DEPTH(value) FIELD_PREP(GENMASK(27, 16), value)
+#define AFBC_MIF_LBUF_DEPTH(value) FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_OUT_XSCOPE/AFBC_SIZE_OUT */
+#define AFBC_HSIZE_OUT(value)  FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_OUT(value)  FIELD_PREP(GENMASK(12, 0), value)
+#define AFBC_OUT_HORZ_BGN(value)   FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_HORZ_END(value)   FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_OUT_YSCOPE */
+#define AFBC_OUT_VERT_BGN(value)   FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_VERT_END(value)   FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_VD_CFMT_CTRL */
+#define AFBC_HORZ_RPT_PIXEL0   BIT(23)
+#define AFBC_HORZ_Y_C_RATIO(value) FIELD_PREP(GENMASK(22, 21), value)
+#define AFBC_HORZ_FMT_EN   BIT(20)
+#define AFBC_VERT_RPT_LINE0BIT(16)
+#define

[PATCH v8 0/6] drm/meson: add support for Amlogic Video FBC

Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.

It considerably reduces memory bandwidth while writing and reading
frames in memory.

The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT

This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.

At least two layout are supported :
- Basic: composed of a body and a header
- Scatter: the buffer is filled with a IOMMU scatter table referring
  to the encoder current memory layout. This mode if more efficient in terms
  of memory allocation but frames are not dumpable and only valid during until
  the buffer is freed and back in control of the encoder

At least two options are supported :
- Memory saving: when the pixel bpp is 8b, the size of the superblock can
  be reduced, thus saving memory.

This serie adds the missing register, updated the FBC decoder registers
content to be committed by the crtc code.

The Amlogic FBC has been tested with compressed content from the Amlogic
HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit
(Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit
(Scatter on G12A/SM1, default on GXL).

It's expected to work as-is on GXM and G12B SoCs.

Changes since v7 at [7]:
- rebased on drm-misc-next
- removed spurious DEBUG in drivers/gpu/drm/meson/meson_overlay.c

Changes since v6 at [6]:
- rebased on drm-misc-next (after drm-misc-next-2020-05-14)
- updated patch 1 commit log for completion

Changes since v5 at [5]:
- merged all fourcc patches in 1
- fixed fourcc definition to have only a single DRM_MOD_
- fixed 2 checkpatch issues

Changes since v4 at [4]:
- added layout and options mask
- cosmetic changes in fourcc.h
- fixed mod check using the masks
- fixed plane apply using the masks

Changes since v3 at [3]:
- added dropped fourcc patch for scatter
- fixed build of last patch

Changes since v2 at [2]:
- Added "BASIC" layout and moved the SCATTER mode as layout, making
  BASIC and SCATTER layout exclusives
- Moved the Memory Saving at bit 8 for options fields
- Split fourcc and overlay patch to introduce basic, mem saving and then
  scatter in separate patches
- Added comment about "transferability" of the buffers

Changes since v1 at [1]:
- s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h

[1] https://patchwork.freedesktop.org/series/73722/#rev1
[2] https://patchwork.freedesktop.org/series/73722/#rev2
[3] https://patchwork.freedesktop.org/series/73722/#rev3
[4] https://patchwork.freedesktop.org/series/73722/#rev4
[5] https://patchwork.freedesktop.org/series/73722/#rev5
[6] https://patchwork.freedesktop.org/series/73722/#rev6
[7] https://patchwork.freedesktop.org/series/73722/#rev7

Neil Armstrong (6):
  drm/fourcc: Add modifier definitions for describing Amlogic Video
Framebuffer Compression
  drm/meson: add Amlogic Video FBC registers
  drm/meson: overlay: setup overlay for Amlogic FBC
  drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
  drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory
layout
  drm/meson: crtc: handle commit of Amlogic FBC frames

 drivers/gpu/drm/meson/meson_crtc.c  | 118 +++---
 drivers/gpu/drm/meson/meson_drv.h   |  16 ++
 drivers/gpu/drm/meson/meson_overlay.c   | 289 +++-
 drivers/gpu/drm/meson/meson_registers.h |  22 ++
 include/uapi/drm/drm_fourcc.h   |  74 ++
 5 files changed, 481 insertions(+), 38 deletions(-)

-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v8 1/6] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression

Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.

It considerably reduces memory bandwidth while writing and reading
frames in memory.

The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT

This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.

This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
  superblock in default mode.
- a 32 bytes per 128x64 header block

This layout is tranferrable between Amlogic SoCs supporting this modifier.

The Memory Saving option exist changing the layout superblock size to save 
memory when
using 8bit components pixels size.

Finally is also adds the Scatter Memory layout, meaning the header contains 
IOMMU
references to the compressed frames content to optimize memory access
and layout.

In this mode, only the header memory address is needed, thus the content
memory organization is tied to the current producer execution and cannot
be saved/dumped neither transferrable between Amlogic SoCs supporting this
modifier.

Tested-by: Kevin Hilman 
Signed-off-by: Neil Armstrong 
---
 include/uapi/drm/drm_fourcc.h | 74 +++
 1 file changed, 74 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 993c1b342315..54e8935f0e4a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -331,6 +331,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
 #define DRM_FORMAT_MOD_VENDOR_ARM 0x08
 #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
 
 /* add more to the end as needed */
 
@@ -950,6 +951,79 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64 modifier)
  */
 #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
 
+/*
+ * Amlogic Video Framebuffer Compression modifiers
+ *
+ * Amlogic uses a proprietary lossless image compression protocol and format
+ * for their hardware video codec accelerators, either video decoders or
+ * video input encoders.
+ *
+ * It considerably reduces memory bandwidth while writing and reading
+ * frames in memory.
+ *
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
+ * per component YCbCr 420, single plane :
+ * - DRM_FORMAT_YUV420_8BIT
+ * - DRM_FORMAT_YUV420_10BIT
+ *
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
+ * defines the options changing the layout.
+ *
+ * Not all combinations are valid, and different SoCs may support different
+ * combinations of layout and options.
+ */
+#define __fourcc_mod_amlogic_layout_mask 0xf
+#define __fourcc_mod_amlogic_options_shift 8
+#define __fourcc_mod_amlogic_options_mask 0xf
+
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__layout, __options) \
+   fourcc_mod_code(AMLOGIC, \
+   ((__layout) & __fourcc_mod_amlogic_layout_mask) | \
+   ((__options) & __fourcc_mod_amlogic_options_mask \
+<< __fourcc_mod_amlogic_options_shift))
+
+/* Amlogic FBC Layouts */
+
+/*
+ * Amlogic FBC Basic Layout
+ *
+ * The basic layout is composed of:
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
+ *   superblock in default mode.
+ * - a 32 bytes per 128x64 header block
+ *
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
+ */
+#define AMLOGIC_FBC_LAYOUT_BASIC   (1ULL)
+
+/*
+ * Amlogic FBC Scatter Memory layout
+ *
+ * Indicates the header contains IOMMU references to the compressed
+ * frames content to optimize memory access and layout.
+ *
+ * In this mode, only the header memory address is needed, thus the
+ * content memory organization is tied to the current producer
+ * execution and cannot be saved/dumped neither transferrable between
+ * Amlogic SoCs supporting this modifier.
+ */
+#define AMLOGIC_FBC_LAYOUT_SCATTER (2ULL)
+
+/* Amlogic FBC Layout Options Bit Mask */
+
+/*
+ * Amlogic FBC Memory Saving mode
+ *
+ * Indicates the storage is packed when pixel size is multiple of word
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
+ * memory.
+ *
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
+ * the scatter layout.
+ */
+#define AMLOGIC_FBC_OPTION_MEM_SAVING  (1ULL << 0)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.22.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for 5.8-rc1