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

2020-07-20 Thread Sidong Yang
On Wed, Jul 15, 2020 at 06:08:44PM +0200, Daniel Vetter wrote:
> On Wed, Jul 15, 2020 at 5:57 PM Melissa Wen  wrote:
> >
> > On 07/15, Sidong Yang wrote:
> > > On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > > > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen  
> > > > wrote:
> > > > >
> > > > > On 07/14, Daniel Vetter wrote:
> > > > > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > > > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On 07/13, Daniel Vetter wrote:
> > > > > > > > > On Fri, Jul 10, 2020 at 02:05:33PM -0300, Melissa Wen wrote:
> > > > > > > > > > On 07/02, Daniel Vetter wrote:
> > > > > > > > > > > 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?
> > > > > > > > > >
> > > > > > > > > > Hi Daniel and Sidong,
> > > > > > > > > >
> > > > > > > > > > I noticed a similar issue when running the IGT test 
> > > > > > > > > > kms_cursor_crc. For
> > > > > > > > > > example, a subtest that passes on the first run 
> > > > > > > > > > (alpha-opaque) fails on
> > > > > > > > > > the second due to a kind of busy waiting in subtest 
> > > > > > > > > > preparation (the
> > > > > > > > > > subtest fails before actually running).
> > > > > > > > > >
> > > > > > > > > > In addition, in the same test, the dpms subtest started to 
> > > > > > > > > > fail since
> > > > > > > > > > the commit that change from wait_for_vblanks to 
> > > > > > > > > > wait_for_flip_done. By
> > > > > > > > > > reverting this commit, the dpms subtest passes again and 
> > > > > > > > > > the sequential
> > > > > > > > > > subtests return to normal.
> > > > > > > > > >
> > > > > > > > > > I am trying to figure out what's missing from using 
> > > > > > > > > > flip_done op on
> > > > > > > > > > vkms, since I am also interested in solving this problem 
> > > > > > > > > > and I
> > > > > > > > > > understand that the change for flip_done has been discussed 
> > > > > > > > > > in the past.
> > > > > > > > > >
> > > > > > > > > > Do you have any idea?
> > > > > > > > >
> > > > > > > > > Uh, not at all. This is indeed rather surprising ...
> > > > > > > > >
> > > > > > > > > What exactly is the failure mode when running a test the 2nd 
> > > > > > > > > time? Full
> > > > > > > > > igt logs might give me an idea. But yeah this is kinda 
> > > > > > > > > surprising.
> > > > > > > >
> > > > > > > > Hi Daniel,
> > > > > > > >
> > > > > > > > This is the IGT log of the 2nd run of 
> > > > > > > > kms_cursor_crc/alpha-opaque:
> > > > > > > >
> > > > > > > > IGT-Version: 1.25-NO-GIT (x86_64) (Linux: 5.8.0-rc2-DRM+ x86_64)
> > > > > > > > Force option used: Using driver vkms
> > > > > > > > Starting subtest: pipe-A-cursor-alpha-opaque
> > > > > > > > Timed out: Opening crc fd, and poll for first CRC.
> > > > > > > > Subtest pipe-A-cursor-alpha-opaque failed.
> > > > > > > >  DEBUG 
> > > > > > > > 

Re: [PATCH 1/2] dt-bindings: display: panel: Add bindings for Tianma nt36672a panel

2020-07-20 Thread Rob Herring
On Thu, Jul 16, 2020 at 09:08:57PM +0530, Sumit Semwal wrote:
> The nt36672a panel from Tianma is a FHD+ panel with a resolution of 1080x2246
> and 6.18 inches size. It is found in some of the Poco F1 phones.
> 
> Signed-off-by: Sumit Semwal 
> ---
>  .../display/panel/tianma,nt36672a.yaml| 110 ++
>  1 file changed, 110 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml 
> b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> new file mode 100644
> index ..3c583ca926ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/tianma,nt36672a.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/tianma,nt36672a.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Tianma model NT36672A DSI Panel display driver
> +
> +maintainers:
> +  - Sumit Semwal 
> +
> +description: |
> +  The nt36672a panel from Tianma is a FHD+ LCD display panel with a 
> resolution
> +  of 1080x2246. It is a video mode DSI panel.
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +  compatible:
> +const: tianma,nt36672a
> +
> +  reg:
> +description: DSI virtual channel of the peripheral
> +
> +  reset-gpios:
> +description: phandle of gpio for reset line - This should be 8mA, gpio
> +  can be configured using mux, pinctrl, pinctrl-names (active high)
> +
> +  vddio-supply:
> +description: phandle of the regulator that provides the supply voltage
> +  Power IC supply
> +
> +  vddpos-supply:
> +description: phandle of the positive boost supply regulator
> +
> +  vddneg-supply:
> +description: phandle of the negative boost supply regulator
> +
> +  pinctrl-names:
> +description: Pinctrl for panel active and suspend
> +
> +  pinctrl-0:
> +description: Active pinctrls
> +
> +  pinctrl-1:
> +description: Suspend pinctrls

I think the pinctrl should go in the DSI controller node, not the 
display unless it is settings for 'reset-gpios'.

> +
> +  ports:
> +type: object
> +properties:
> +  port@0:
> +type: object
> +description: DSI input port driven by master DSI
> +properties:
> +  reg:
> +const: 0
> +
> +required:
> +  - reg

For a single port, you can do just 'port' (without ports node).

> +
> +required:
> +  - compatible
> +  - reg
> +  - vddi0-supply
> +  - vddpos-supply
> +  - vddneg-supply
> +  - reset-gpios
> +  - pinctrl-names
> +  - pinctrl-0
> +  - pinctrl-1
> +  - ports
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |+
> +#include 
> +dsi0 {

dsi {

> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  panel@0 {
> +compatible = "tianma,nt36672a";
> +reg = <0>;
> +vddi0-supply = <_l14a_1p88>;
> +vddpos-supply = <>;
> +vddneg-supply = <>;
> +
> +reset-gpios = < 6 GPIO_ACTIVE_HIGH>;
> +
> +pinctrl-names = "panel_active", "panel_suspend";
> +pinctrl-0 = <_dsi_active>;
> +pinctrl-1 = <_dsi_suspend>;
> +
> +ports {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +
> +  port@0 {
> +reg = <0>;
> +tianma_nt36672a_in_0: endpoint {
> +  remote-endpoint = <_out>;
> +};
> +  };
> +};
> +  };
> +};
> +
> +...
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets

2020-07-20 Thread Rob Clark
On Mon, Jul 20, 2020 at 4:32 PM Stephen Boyd  wrote:
>
> Quoting khs...@codeaurora.org (2020-07-20 15:48:13)
> > On 2020-07-20 13:18, Stephen Boyd wrote:
> > > Quoting Kuogee Hsieh (2020-07-07 11:41:25)
> > >>  drivers/gpu/drm/msm/dp/dp_power.c   |  32 +-
> > >>  drivers/gpu/drm/msm/dp/dp_power.h   |   1 +
> > >>  drivers/gpu/drm/msm/dp/dp_reg.h |   1 +
> > >>  17 files changed, 861 insertions(+), 424 deletions(-)
> > >
> > > It seems to spread various changes throughout the DP bits and only has
> > > a
> > > short description about what's changing. Given that the series above
> > > isn't merged it would be better to get rid of this change and make the
> > > changes in the patches that introduce these files.
> > >
> >
> > Yes, the base DP driver is not yet merged as its still in reviews and
> > has been for a while.
> > While it is being reviewed, different developers are working on
> > different aspects of DP such as base DP driver, DP compliance, audio etc
> > to keep things going in parallel.
> > To maintain the authorship of the different developers, we prefer having
> > them as separate changes and not merge them.
> > We can make all these changes as part of the same series if that shall
> > help to keep things together but would prefer the changes themselves to
> > be separate.
> > Please consider this and let us know if that works.
> >
>
> I'm not the maintainer here so it's not really up to me, but this is why
> we have the Co-developed-by tag, to show that multiple people worked on
> some patch. The patch is supposed to logically stand on its own
> regardless of how many people worked on it. Authorship is a single
> person but the Co-developed-by tag helps express that more than one
> person is the actual author of the patch. Can you use that tag instead
> and then squash this into the other DP patches?

The dpu mega-patches are hard enough to review already.. I'd really
appreciated it if the dpu dev's sort out some way to squash later
fixups into earlier patches

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


Re: [PATCH 3/5] dt-bindings: arm: sunxi: Add compatible for MSI Primo73 tablet

2020-07-20 Thread Rob Herring
On Tue, 14 Jul 2020 15:13:03 +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai 
> 
> Document board compatible name for MSI Primo73 tablet.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +
>  1 file changed, 5 insertions(+)
> 

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


Re: [PATCH 1/5] dt-bindings: display: panel-dpi: Add bits-per-color property

2020-07-20 Thread Rob Herring
On Tue, Jul 14, 2020 at 03:13:01PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai 
> 
> Some LCD panels do not support 24-bit true color, or 8bits per channel
> RGB. Many low end ones only support up to 6 bits per channel natively.

This should be implied by the panel's compatible property.

> Add a device tree property to describe the native bit depth of the
> panel. This is separate from the bus width or format of the connection
> to the display output.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../devicetree/bindings/display/panel/panel-dpi.yaml  | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> index 0cd74c8dab42..8eb013fb1969 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> @@ -26,6 +26,9 @@ properties:
>height-mm: true
>label: true
>panel-timing: true
> +  bits-per-color:
> +description:
> +  Shall contain an integer describing the number of bits per color.
>port: true
>power-supply: true
>reset-gpios: true
> @@ -42,6 +45,7 @@ examples:
>  panel {
>  compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
>  label = "osddisplay";
> +bits-per-color = <8>;
>  power-supply = <_supply>;
>  backlight = <>;
>  
> -- 
> 2.27.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-07-20 Thread Almahallawy, Khaled
On Mon, 2020-07-20 at 17:07 -0700, Manasi Navare wrote:
> On Mon, Jul 20, 2020 at 04:41:25PM -0700, Khaled Almahallawy wrote:
> > Add the missing CP2520 pattern 2 and 3 phy compliance patterns
> > 
> > Signed-off-by: Khaled Almahallawy 
> > ---
> >  drivers/gpu/drm/drm_dp_helper.c | 2 +-
> >  include/drm/drm_dp_helper.h | 4 +++-
> >  2 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > b/drivers/gpu/drm/drm_dp_helper.c
> > index a3c82e726057..d0fb78c6aca6 100644
> > --- a/drivers/gpu/drm/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > @@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct
> > drm_dp_aux *aux,
> > return err;
> >  
> > break;
> > -   case DP_PHY_TEST_PATTERN_CP2520:
> > +   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> > err = drm_dp_dpcd_read(aux,
> > DP_TEST_HBR2_SCRAMBLER_RESET,
> >>hbr2_reset,
> >sizeof(data->hbr2_reset));
> 
> Where do we read PAT2 and PAT3, I see you defined those newly and
> patch 2/2 has them
> in teh switch case but the drm_dp_get_phy_test_pattern function
> doesnt read them?
> 

Per my understanding from the specs, only HBR2 (CP2520 PAT1) requires
reading dpcd address 0024Ah to set HBR2_COMPLIANCT_SCRAMBLER_RESET.
TPS4 (CP2520 PAT3) doesn’t require that. 
I’m not sure about CP2520 PAT2 if it has use or not. In the test scope
we can select 6 patterns. PAT2 is not one of them. 

Thanks
~Khaled

> Manasi
> 
> > diff --git a/include/drm/drm_dp_helper.h
> > b/include/drm/drm_dp_helper.h
> > index e47dc22ebf50..65dd6cd71f1e 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -708,7 +708,9 @@
> >  # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
> >  # define DP_PHY_TEST_PATTERN_PRBS7  0x3
> >  # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
> > -# define DP_PHY_TEST_PATTERN_CP2520 0x5
> > +# define DP_PHY_TEST_PATTERN_CP2520_PAT1   0x5
> > +# define DP_PHY_TEST_PATTERN_CP2520_PAT2   0x6
> > +# define DP_PHY_TEST_PATTERN_CP2520_PAT3   0x7
> >  
> >  #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
> >  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
> > -- 
> > 2.17.1
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-07-20 Thread Almahallawy, Khaled
On Mon, 2020-07-20 at 17:11 -0700, Manasi Navare wrote:
> On Mon, Jul 20, 2020 at 04:41:26PM -0700, Khaled Almahallawy wrote:
> > Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source
> > tests.
> > 
> > Signed-off-by: Khaled Almahallawy 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 14 --
> >  drivers/gpu/drm/i915/i915_reg.h |  4 
> >  2 files changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index d6295eb20b63..effadc096740 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -5371,7 +5371,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> > _dp->compliance.test_data.phytest;
> > struct intel_crtc *crtc = to_intel_crtc(dig_port-
> > >base.base.crtc);
> > enum pipe pipe = crtc->pipe;
> > -   u32 pattern_val;
> > +   u32 pattern_val, dp_tp_ctl;
> >  
> > switch (data->phy_pattern) {
> > case DP_PHY_TEST_PATTERN_NONE:
> > @@ -5411,7 +5411,7 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> >DDI_DP_COMP_CTL_CUSTOM80);
> > break;
> > -   case DP_PHY_TEST_PATTERN_CP2520:
> > +   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
> > /*
> >  * FIXME: Ideally pattern should come from DPCD 0x24A.
> > As
> >  * current firmware of DPR-100 could not set it, so
> > hardcoding
> > @@ -5423,6 +5423,16 @@ static void
> > intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> >DDI_DP_COMP_CTL_ENABLE |
> > DDI_DP_COMP_CTL_HBR2 |
> >pattern_val);
> > break;
> > +   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> > +   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> > +   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> > 0x0);
> > +   dp_tp_ctl = intel_de_read(dev_priv,
> > TGL_DP_TP_CTL(pipe));
> > +   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> > +   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TS4a;
> > +   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> > +   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> > +   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe),
> > dp_tp_ctl);
> > +   break;
> > default:
> > WARN(1, "Invalid Phy Test Pattern\n");
> > }
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index a0d31f3bf634..a4607bd1ac26 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -9982,6 +9982,10 @@ enum skl_power_gate {
> >  #define  DP_TP_CTL_MODE_SST(0 << 27)
> >  #define  DP_TP_CTL_MODE_MST(1 << 27)
> >  #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
> > +#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
> > +#define  DP_TP_CTL_TRAIN_PAT4_SEL_TS4a (0 << 19)
> > +#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
> > +#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
> 
> The bspec calls them Training Pattern 4a/b/c, why is it _TS4a. TP4b,
> TP4c?
> We shd make it uniform, all TP4a/b/c perhaps?

Apology,will fix to TP4a/b/c then

> 
> Manasi
> 
> >  #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
> >  #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
> >  #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
> > -- 
> > 2.17.1
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-07-20 Thread Manasi Navare
On Mon, Jul 20, 2020 at 04:41:26PM -0700, Khaled Almahallawy wrote:
> Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
> 
> Signed-off-by: Khaled Almahallawy 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 14 --
>  drivers/gpu/drm/i915/i915_reg.h |  4 
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d6295eb20b63..effadc096740 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5371,7 +5371,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
> *intel_dp)
>   _dp->compliance.test_data.phytest;
>   struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
>   enum pipe pipe = crtc->pipe;
> - u32 pattern_val;
> + u32 pattern_val, dp_tp_ctl;
>  
>   switch (data->phy_pattern) {
>   case DP_PHY_TEST_PATTERN_NONE:
> @@ -5411,7 +5411,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
> *intel_dp)
>  DDI_DP_COMP_CTL_ENABLE |
>  DDI_DP_COMP_CTL_CUSTOM80);
>   break;
> - case DP_PHY_TEST_PATTERN_CP2520:
> + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
>   /*
>* FIXME: Ideally pattern should come from DPCD 0x24A. As
>* current firmware of DPR-100 could not set it, so hardcoding
> @@ -5423,6 +5423,16 @@ static void intel_dp_phy_pattern_update(struct 
> intel_dp *intel_dp)
>  DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
>  pattern_val);
>   break;
> + case DP_PHY_TEST_PATTERN_CP2520_PAT3:
> + DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
> + dp_tp_ctl = intel_de_read(dev_priv, 
> TGL_DP_TP_CTL(pipe));
> + dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
> + dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TS4a;
> + dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
> + dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
> + intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
> dp_tp_ctl);
> + break;
>   default:
>   WARN(1, "Invalid Phy Test Pattern\n");
>   }
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a0d31f3bf634..a4607bd1ac26 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9982,6 +9982,10 @@ enum skl_power_gate {
>  #define  DP_TP_CTL_MODE_SST  (0 << 27)
>  #define  DP_TP_CTL_MODE_MST  (1 << 27)
>  #define  DP_TP_CTL_FORCE_ACT (1 << 25)
> +#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK   (3 << 19)
> +#define  DP_TP_CTL_TRAIN_PAT4_SEL_TS4a   (0 << 19)
> +#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b   (1 << 19)
> +#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c   (2 << 19)

The bspec calls them Training Pattern 4a/b/c, why is it _TS4a. TP4b, TP4c?
We shd make it uniform, all TP4a/b/c perhaps?

Manasi

>  #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE (1 << 18)
>  #define  DP_TP_CTL_FDI_AUTOTRAIN (1 << 15)
>  #define  DP_TP_CTL_LINK_TRAIN_MASK   (7 << 8)
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-07-20 Thread Manasi Navare
On Mon, Jul 20, 2020 at 04:41:25PM -0700, Khaled Almahallawy wrote:
> Add the missing CP2520 pattern 2 and 3 phy compliance patterns
> 
> Signed-off-by: Khaled Almahallawy 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>  include/drm/drm_dp_helper.h | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index a3c82e726057..d0fb78c6aca6 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
>   return err;
>  
>   break;
> - case DP_PHY_TEST_PATTERN_CP2520:
> + case DP_PHY_TEST_PATTERN_CP2520_PAT1:
>   err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
>  >hbr2_reset,
>  sizeof(data->hbr2_reset));

Where do we read PAT2 and PAT3, I see you defined those newly and patch 2/2 has 
them
in teh switch case but the drm_dp_get_phy_test_pattern function doesnt read 
them?

Manasi

> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index e47dc22ebf50..65dd6cd71f1e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -708,7 +708,9 @@
>  # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
>  # define DP_PHY_TEST_PATTERN_PRBS7  0x3
>  # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
> -# define DP_PHY_TEST_PATTERN_CP2520 0x5
> +# define DP_PHY_TEST_PATTERN_CP2520_PAT1 0x5
> +# define DP_PHY_TEST_PATTERN_CP2520_PAT2 0x6
> +# define DP_PHY_TEST_PATTERN_CP2520_PAT3 0x7
>  
>  #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
>  #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
> -- 
> 2.17.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3

2020-07-20 Thread Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns

Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 include/drm/drm_dp_helper.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index a3c82e726057..d0fb78c6aca6 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -1583,7 +1583,7 @@ int drm_dp_get_phy_test_pattern(struct drm_dp_aux *aux,
return err;
 
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
err = drm_dp_dpcd_read(aux, DP_TEST_HBR2_SCRAMBLER_RESET,
   >hbr2_reset,
   sizeof(data->hbr2_reset));
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e47dc22ebf50..65dd6cd71f1e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -708,7 +708,9 @@
 # define DP_PHY_TEST_PATTERN_ERROR_COUNT0x2
 # define DP_PHY_TEST_PATTERN_PRBS7  0x3
 # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM   0x4
-# define DP_PHY_TEST_PATTERN_CP2520 0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT1   0x5
+# define DP_PHY_TEST_PATTERN_CP2520_PAT2   0x6
+# define DP_PHY_TEST_PATTERN_CP2520_PAT3   0x7
 
 #define DP_TEST_HBR2_SCRAMBLER_RESET0x24A
 #define DP_TEST_80BIT_CUSTOM_PATTERN_7_00x250
-- 
2.17.1

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


[PATCH 2/2] drm/i915/dp: TPS4 PHY test pattern compliance support

2020-07-20 Thread Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.

Signed-off-by: Khaled Almahallawy 
---
 drivers/gpu/drm/i915/display/intel_dp.c | 14 --
 drivers/gpu/drm/i915/i915_reg.h |  4 
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
b/drivers/gpu/drm/i915/display/intel_dp.c
index d6295eb20b63..effadc096740 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5371,7 +5371,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
enum pipe pipe = crtc->pipe;
-   u32 pattern_val;
+   u32 pattern_val, dp_tp_ctl;
 
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
@@ -5411,7 +5411,7 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE |
   DDI_DP_COMP_CTL_CUSTOM80);
break;
-   case DP_PHY_TEST_PATTERN_CP2520:
+   case DP_PHY_TEST_PATTERN_CP2520_PAT1:
/*
 * FIXME: Ideally pattern should come from DPCD 0x24A. As
 * current firmware of DPR-100 could not set it, so hardcoding
@@ -5423,6 +5423,16 @@ static void intel_dp_phy_pattern_update(struct intel_dp 
*intel_dp)
   DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
   pattern_val);
break;
+   case DP_PHY_TEST_PATTERN_CP2520_PAT3:
+   DRM_DEBUG_KMS("Set TPS4 Phy Test Pattern\n");
+   intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
+   dp_tp_ctl = intel_de_read(dev_priv, 
TGL_DP_TP_CTL(pipe));
+   dp_tp_ctl &= ~DP_TP_CTL_TRAIN_PAT4_SEL_MASK;
+   dp_tp_ctl |= DP_TP_CTL_TRAIN_PAT4_SEL_TS4a;
+   dp_tp_ctl &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT4;
+   intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), 
dp_tp_ctl);
+   break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a0d31f3bf634..a4607bd1ac26 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9982,6 +9982,10 @@ enum skl_power_gate {
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_MASK (3 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TS4a (0 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4b (1 << 19)
+#define  DP_TP_CTL_TRAIN_PAT4_SEL_TP4c (2 << 19)
 #define  DP_TP_CTL_ENHANCED_FRAME_ENABLE   (1 << 18)
 #define  DP_TP_CTL_FDI_AUTOTRAIN   (1 << 15)
 #define  DP_TP_CTL_LINK_TRAIN_MASK (7 << 8)
-- 
2.17.1

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


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

2020-07-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=207901

--- Comment #25 from Lyude Paul (ly...@redhat.com) ---
Hi! could you please retry this with a kernel from drm-tip? I don't see any
DisplayPort/DP MST debugging output there, so I'm guessing you either forgot to
add drm.debug=0x116 or your kernel (which appears to be based off the ubuntu
kernel) is too old to support that. As well, I can see a couple of other bugs
from nouveau in that log which have already been fixed in more recent kernels.

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


[PATCH AUTOSEL 5.4 22/34] drm/amdgpu: fix preemption unit test

2020-07-20 Thread Sasha Levin
From: Jack Xiao 

[ Upstream commit d845a2051b6b673fab4229b920ea04c7c4352b51 ]

Remove signaled jobs from job list and ensure the
job was indeed preempted.

Signed-off-by: Jack Xiao 
Reviewed-by: Hawking Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 1e25ca34d876c..700e26b69abca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -990,27 +990,37 @@ static void amdgpu_ib_preempt_job_recovery(struct 
drm_gpu_scheduler *sched)
 static void amdgpu_ib_preempt_mark_partial_job(struct amdgpu_ring *ring)
 {
struct amdgpu_job *job;
-   struct drm_sched_job *s_job;
+   struct drm_sched_job *s_job, *tmp;
uint32_t preempt_seq;
struct dma_fence *fence, **ptr;
struct amdgpu_fence_driver *drv = >fence_drv;
struct drm_gpu_scheduler *sched = >sched;
+   bool preempted = true;
 
if (ring->funcs->type != AMDGPU_RING_TYPE_GFX)
return;
 
preempt_seq = le32_to_cpu(*(drv->cpu_addr + 2));
-   if (preempt_seq <= atomic_read(>last_seq))
-   return;
+   if (preempt_seq <= atomic_read(>last_seq)) {
+   preempted = false;
+   goto no_preempt;
+   }
 
preempt_seq &= drv->num_fences_mask;
ptr = >fences[preempt_seq];
fence = rcu_dereference_protected(*ptr, 1);
 
+no_preempt:
spin_lock(>job_list_lock);
-   list_for_each_entry(s_job, >ring_mirror_list, node) {
+   list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
+   if (dma_fence_is_signaled(_job->s_fence->finished)) {
+   /* remove job from ring_mirror_list */
+   list_del_init(_job->node);
+   sched->ops->free_job(s_job);
+   continue;
+   }
job = to_amdgpu_job(s_job);
-   if (job->fence == fence)
+   if (preempted && job->fence == fence)
/* mark the job as preempted */
job->preemption_status |= AMDGPU_IB_PREEMPTED;
}
-- 
2.25.1

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


[PATCH AUTOSEL 5.4 21/34] drm/amdgpu/gfx10: fix race condition for kiq

2020-07-20 Thread Sasha Levin
From: Jack Xiao 

[ Upstream commit 7d65a577bb58d4f27a3398a4c0cb0b00ab7d0511 ]

During preemption test for gfx10, it uses kiq to trigger
gfx preemption, which would result in race condition
with flushing TLB for kiq.

Signed-off-by: Jack Xiao 
Reviewed-by: Hawking Zhang 
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 6f118292e40fb..64d96eb0a2337 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4683,12 +4683,17 @@ static int gfx_v10_0_ring_preempt_ib(struct amdgpu_ring 
*ring)
struct amdgpu_device *adev = ring->adev;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *kiq_ring = >ring;
+   unsigned long flags;
 
if (!kiq->pmf || !kiq->pmf->kiq_unmap_queues)
return -EINVAL;
 
-   if (amdgpu_ring_alloc(kiq_ring, kiq->pmf->unmap_queues_size))
+   spin_lock_irqsave(>ring_lock, flags);
+
+   if (amdgpu_ring_alloc(kiq_ring, kiq->pmf->unmap_queues_size)) {
+   spin_unlock_irqrestore(>ring_lock, flags);
return -ENOMEM;
+   }
 
/* assert preemption condition */
amdgpu_ring_set_preempt_cond_exec(ring, false);
@@ -4699,6 +4704,8 @@ static int gfx_v10_0_ring_preempt_ib(struct amdgpu_ring 
*ring)
   ++ring->trail_seq);
amdgpu_ring_commit(kiq_ring);
 
+   spin_unlock_irqrestore(>ring_lock, flags);
+
/* poll the trailing fence */
for (i = 0; i < adev->usec_timeout; i++) {
if (ring->trail_seq ==
-- 
2.25.1

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


[PATCH AUTOSEL 5.7 26/40] drm/amdgpu/gfx10: fix race condition for kiq

2020-07-20 Thread Sasha Levin
From: Jack Xiao 

[ Upstream commit 7d65a577bb58d4f27a3398a4c0cb0b00ab7d0511 ]

During preemption test for gfx10, it uses kiq to trigger
gfx preemption, which would result in race condition
with flushing TLB for kiq.

Signed-off-by: Jack Xiao 
Reviewed-by: Hawking Zhang 
Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 0e0daf0021b60..ff94f756978d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -4746,12 +4746,17 @@ static int gfx_v10_0_ring_preempt_ib(struct amdgpu_ring 
*ring)
struct amdgpu_device *adev = ring->adev;
struct amdgpu_kiq *kiq = >gfx.kiq;
struct amdgpu_ring *kiq_ring = >ring;
+   unsigned long flags;
 
if (!kiq->pmf || !kiq->pmf->kiq_unmap_queues)
return -EINVAL;
 
-   if (amdgpu_ring_alloc(kiq_ring, kiq->pmf->unmap_queues_size))
+   spin_lock_irqsave(>ring_lock, flags);
+
+   if (amdgpu_ring_alloc(kiq_ring, kiq->pmf->unmap_queues_size)) {
+   spin_unlock_irqrestore(>ring_lock, flags);
return -ENOMEM;
+   }
 
/* assert preemption condition */
amdgpu_ring_set_preempt_cond_exec(ring, false);
@@ -4762,6 +4767,8 @@ static int gfx_v10_0_ring_preempt_ib(struct amdgpu_ring 
*ring)
   ++ring->trail_seq);
amdgpu_ring_commit(kiq_ring);
 
+   spin_unlock_irqrestore(>ring_lock, flags);
+
/* poll the trailing fence */
for (i = 0; i < adev->usec_timeout; i++) {
if (ring->trail_seq ==
-- 
2.25.1

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


[PATCH AUTOSEL 5.7 27/40] drm/amdgpu: fix preemption unit test

2020-07-20 Thread Sasha Levin
From: Jack Xiao 

[ Upstream commit d845a2051b6b673fab4229b920ea04c7c4352b51 ]

Remove signaled jobs from job list and ensure the
job was indeed preempted.

Signed-off-by: Jack Xiao 
Reviewed-by: Hawking Zhang 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 20 +++-
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index c0f9a651dc067..92b18c4760e55 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1156,27 +1156,37 @@ static void amdgpu_ib_preempt_job_recovery(struct 
drm_gpu_scheduler *sched)
 static void amdgpu_ib_preempt_mark_partial_job(struct amdgpu_ring *ring)
 {
struct amdgpu_job *job;
-   struct drm_sched_job *s_job;
+   struct drm_sched_job *s_job, *tmp;
uint32_t preempt_seq;
struct dma_fence *fence, **ptr;
struct amdgpu_fence_driver *drv = >fence_drv;
struct drm_gpu_scheduler *sched = >sched;
+   bool preempted = true;
 
if (ring->funcs->type != AMDGPU_RING_TYPE_GFX)
return;
 
preempt_seq = le32_to_cpu(*(drv->cpu_addr + 2));
-   if (preempt_seq <= atomic_read(>last_seq))
-   return;
+   if (preempt_seq <= atomic_read(>last_seq)) {
+   preempted = false;
+   goto no_preempt;
+   }
 
preempt_seq &= drv->num_fences_mask;
ptr = >fences[preempt_seq];
fence = rcu_dereference_protected(*ptr, 1);
 
+no_preempt:
spin_lock(>job_list_lock);
-   list_for_each_entry(s_job, >ring_mirror_list, node) {
+   list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
+   if (dma_fence_is_signaled(_job->s_fence->finished)) {
+   /* remove job from ring_mirror_list */
+   list_del_init(_job->node);
+   sched->ops->free_job(s_job);
+   continue;
+   }
job = to_amdgpu_job(s_job);
-   if (job->fence == fence)
+   if (preempted && job->fence == fence)
/* mark the job as preempted */
job->preemption_status |= AMDGPU_IB_PREEMPTED;
}
-- 
2.25.1

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


[PATCH] drm/nouveau/kms/nv50-: Fix CRC-related compile errors with debugfs disabled

2020-07-20 Thread Lyude Paul
Looks like I made the mistake of forgetting to check whether or not this
would build without CONFIG_DEBUG_FS, as the Kbuild bot reported some
issues building with tegra_defconfig:

In file included from drivers/gpu/drm/nouveau/nouveau_display.c:47:
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_head_crc_late_register’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:47: error: parameter name
omitted
  106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {}
  |   ^~
./drivers/gpu/drm/nouveau/dispnv50/crc.h:106:54: warning: no return
statement in function returning non-void [-Wreturn-type]
  106 | static inline int nv50_head_crc_late_register(struct nv50_head *) {}
  |  ^
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_handle_vblank’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:57: warning: ‘return’ with
a value, in function returning void [-Wreturn-type]
  108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; }
  | ^
./drivers/gpu/drm/nouveau/dispnv50/crc.h:108:1: note: declared here
  108 | nv50_crc_handle_vblank(struct nv50_head *head) { return 0; }
  | ^~
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_atomic_check’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:23: error: parameter name
omitted
  111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *,
  |   ^~
./drivers/gpu/drm/nouveau/dispnv50/crc.h:111:43: error: parameter name
omitted
  111 | nv50_crc_atomic_check(struct nv50_head *, struct nv50_head_atom *,
  |   ^~~
./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:9: error: parameter name
omitted
  112 | struct nv50_head_atom *) {}
  | ^~~
./drivers/gpu/drm/nouveau/dispnv50/crc.h:112:16: warning: no return
statement in function returning non-void [-Wreturn-type]
  112 | struct nv50_head_atom *) {}
  |^~
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_atomic_stop_reporting’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:114:32: error: parameter name
omitted
  114 | nv50_crc_atomic_stop_reporting(struct drm_atomic_state *) {}
  |^
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_atomic_prepare_notifier_contexts’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:116:43: error: parameter name
omitted
  116 | nv50_crc_atomic_prepare_notifier_contexts(struct drm_atomic_state *) {}
  |   ^
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_atomic_start_reporting’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:118:33: error: parameter name
omitted
  118 | nv50_crc_atomic_start_reporting(struct drm_atomic_state *) {}
  | ^
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_atomic_set’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:21: error: parameter name
omitted
  120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {}
  | ^~
./drivers/gpu/drm/nouveau/dispnv50/crc.h:120:41: error: parameter name
omitted
  120 | nv50_crc_atomic_set(struct nv50_head *, struct nv50_head_atom *) {}
  | ^~~
./drivers/gpu/drm/nouveau/dispnv50/crc.h: In function
‘nv50_crc_atomic_clr’:
./drivers/gpu/drm/nouveau/dispnv50/crc.h:122:21: error: parameter name
omitted
  122 | nv50_crc_atomic_clr(struct nv50_head *) {}
  | ^~
drivers/gpu/drm/nouveau/nouveau_display.c: In function
‘nouveau_framebuffer_new’:
drivers/gpu/drm/nouveau/nouveau_display.c:286:15: warning: variable
‘width’ set but not used [-Wunused-but-set-variable]
  286 |  unsigned int width, height, i;
  |   ^

So, fix the inline function declarations we use in
drm/drivers/gpu/drm/nouveau/dispnv50/crc.h when CONFIG_DEBUG_FS is
enabled.

Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support")
Reported-by: kernel test robot 
Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/dispnv50/crc.h | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/crc.h 
b/drivers/gpu/drm/nouveau/dispnv50/crc.h
index 4bc59e7793151..92df084492a8c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/crc.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/crc.h
@@ -106,26 +106,27 @@ struct nv50_crc_atom {};
 #define nv50_crc_set_source NULL
 
 static inline void nv50_crc_init(struct drm_device *dev) {}
-static inline int nv50_head_crc_late_register(struct 

[PATCH 1/2 v1] dt-bindings: backlight: Add Kinetic KTD253 bindings

2020-07-20 Thread Linus Walleij
This adds device tree bindings for the Kinetic KTD253
white LED backlight driver.

Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
 .../leds/backlight/kinetic,ktd253.yaml| 48 +++
 1 file changed, 48 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml

diff --git 
a/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml 
b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
new file mode 100644
index ..610bf9a0e270
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/kinetic,ktd253.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Kinetic Technologies KTD253 one-wire backlight
+
+maintainers:
+  - Linus Walleij 
+
+description: |
+  The Kinetic Technologies KTD253 is a white LED backlight that is
+  controlled by a single GPIO line. If you just turn on the backlight
+  it goes to maximum backlight then you can set the level of backlight
+  using pulses on the enable wire.
+
+properties:
+  compatible:
+const: kinetic,ktd253
+
+  gpios:
+description: GPIO to use to enable/disable and dim the backlight.
+maxItems: 1
+
+  default-brightness:
+description: Default brightness level on boot. 0 is off.
+minimum: 0
+maximum: 255
+
+  max-brightness:
+description: Maximum brightness that is allowed during runtime.
+minimum: 0
+maximum: 255
+
+required:
+  - compatible
+  - gpios
+
+examples:
+  - |
+#include 
+backlight {
+compatible = "kinetic,ktd253";
+gpios = < 5 GPIO_ACTIVE_HIGH>;
+default-on;
+default-brightness = <160>;
+};
-- 
2.26.2

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


[PATCH 2/2 v1] backlight: Add Kinetic KTD253 backlight driver

2020-07-20 Thread Linus Walleij
The Kinetic KTD253 backlight driver is controlled with a
single GPIO line, but still supports a range of brightness
settings by sending fast pulses on the line.

This is based off the source code release for the Samsung
GT-S7710 mobile phone.

Signed-off-by: Linus Walleij 
---
 MAINTAINERS|   6 +
 drivers/video/backlight/Kconfig|   8 +
 drivers/video/backlight/Makefile   |   1 +
 drivers/video/backlight/ktd253-backlight.c | 254 +
 4 files changed, 269 insertions(+)
 create mode 100644 drivers/video/backlight/ktd253-backlight.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b4a43a9e7fbc..ea6fcc5bb79e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9610,6 +9610,12 @@ F:   Documentation/admin-guide/auxdisplay/ks0108.rst
 F: drivers/auxdisplay/ks0108.c
 F: include/linux/ks0108.h
 
+KTD253 BACKLIGHT DRIVER
+M: Linus Walleij 
+S: Maintained
+F: Documentation/devicetree/bindings/leds/backlight/kinetic,ktd253.yaml
+F: drivers/video/backlight/ktd253-backlight.c
+
 L3MDEV
 M: David Ahern 
 L: net...@vger.kernel.org
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 7d22d7377606..6a74c60707b4 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -190,6 +190,14 @@ config BACKLIGHT_IPAQ_MICRO
  computers. Say yes if you have one of the h3100/h3600/h3700
  machines.
 
+config BACKLIGHT_KTD253
+   tristate "Backlight Driver for Kinetic KTD253"
+   depends on GPIOLIB || COMPILE_TEST
+   help
+ Say y to enabled the backlight driver for the Kinetic KTD253
+ which is a 1-wire GPIO-controlled backlight found in some mobile
+ phones.
+
 config BACKLIGHT_LM3533
tristate "Backlight Driver for LM3533"
depends on MFD_LM3533
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 0c1a1524627a..d50cd12574ae 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_GPIO)  += gpio_backlight.o
 obj-$(CONFIG_BACKLIGHT_HP680)  += hp680_bl.o
 obj-$(CONFIG_BACKLIGHT_HP700)  += jornada720_bl.o
 obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO) += ipaq_micro_bl.o
+obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
 obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/ktd253-backlight.c 
b/drivers/video/backlight/ktd253-backlight.c
new file mode 100644
index ..d460d1fef329
--- /dev/null
+++ b/drivers/video/backlight/ktd253-backlight.c
@@ -0,0 +1,254 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Backlight driver for the Kinetic KTD253
+ * Based on code and know-how from the Samsung GT-S7710
+ * Gareth Phillips 
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Current ratio is n/32 from 1/32 to 32/32 */
+#define KTD253_MIN_RATIO 1
+#define KTD253_MAX_RATIO 32
+#define KTD253_DEFAULT_RATIO 13
+
+/* With the table we use this is 24/32 current ratio actually */
+#define KTD253_MAX_BRIGHTNESS 255
+#define KTD253_DEFAULT_BRIGHTNESS 160
+
+#define KTD253_T_LOW_NS (200 + 10) /* Additional 10ns as safety factor */
+#define KTD253_T_HIGH_NS (200 + 10) /* Additional 10ns as safety factor */
+#define KTD253_T_OFF_MS 3
+
+struct ktd253_backlight {
+   struct device *dev;
+   struct gpio_desc *gpiod;
+   u16 ratio;
+   unsigned int brightness;
+};
+
+/*
+ * The following table is used to convert brightness level to the LED
+ * Current Ratio expressed as (full current) /(n * 32).
+ * i.e. 1 = 1/32 full current. Zero indicates LED is powered off.
+ * The table is intended to allow the brightness level to be "tuned"
+ * to compensate for non-linearity of brightness relative to current.
+ */
+static const u16 ktd253_brightness_to_current_ratio[] = {
+   0,  /* (0/32) KTD253_BACKLIGHT_OFF */
+   39, /* (1/32) KTD253_MIN_RATIO */
+   58, /* (2/32) */
+   67, /* (3/32) */
+   76, /* (4/32) */
+   85, /* (5/32) */
+   94, /* (6/32) */
+   104,/* (7/32) */
+   113,/* (8/32) */
+   122,/* (9/32) */
+   131,/* (10/32) */
+   145,/* (11/32) */
+   159,/* (12/32) */
+   169,/* (13/32) */
+   179,/* (14/32) */
+   189,/* (15/32) */
+   196,/* (16/32) */
+   203,/* (17/32) */
+   210,/* (18/32) */
+   217,/* (19/32) */
+   224,/* (20/32) */
+   231,/* (21/32) */
+   238,/* (22/32) */
+   245,/* (23/32) */
+   255,/* (24/32) */
+   300,/* (25/32) */
+   300,/* (26/32) */
+   300,/* (27/32) */
+   300,  

Re: [PATCH] drm: panel: simple: Delay HPD checking on boe_nv133fhm_n61 for 15 ms

2020-07-20 Thread Doug Anderson
Hi,


On Thu, Jul 16, 2020 at 1:21 PM Douglas Anderson  wrote:
>
> On boe_nv133fhm_n62 (and presumably on boe_nv133fhm_n61) a scope shows
> a small spike on the HPD line right when you power the panel on.  The
> picture looks something like this:
>
>  +--
>  |
>  |
>  |
> Power ---+
>+---
>|
>   ++   |
>  ++|   |
> HPD -+ +---+
>
> So right when power is applied there's a little bump in HPD and then
> there's small spike right before it goes low.  The total time of the
> little bump plus the spike was measured on one panel as being 8 ms
> long.  The total time for the HPD to go high on the same panel was
> 51.2 ms, though the datasheet only promises it is < 200 ms.
>
> When asked about this glitch, BOE indicated that it was expected and
> persisted until the TCON has been initialized.
>
> If this was a real hotpluggable DP panel then this wouldn't matter a
> whole lot.  We'd debounce the HPD signal for a really long time and so
> the little blip wouldn't hurt.  However, this is not a hotpluggable DP
> panel and the the debouncing logic isn't needed and just shows down
> the time needed to get the display working.  This is why the code in
> panel_simple_prepare() doesn't do debouncing and just waits for HPD to
> go high once.  Unfortunately if we get unlucky and happen to poll the
> HPD line right at the spike we can try talking to the panel before
> it's ready.
>
> Let's handle this situation by putting in a 15 ms prepare delay and
> decreasing the "hpd absent delay" by 15 ms.  That means:
> * If you don't have HPD hooked up at all you've still got the
>   hardcoded 200 ms delay.
> * If you've got HPD hooked up you will always wait at least 15 ms
>   before checking HPD.  The only case where this could be bad is if
>   the panel is sharing a voltage rail with something else in the
>   system and was already turned on long before the panel came up.  In
>   such a case we'll be delaying 15 ms for no reason, but it's not a
>   huge delay and I don't see any other good solution to handle that
>   case.
>
> Even though the delay was measured as 8 ms, 15 ms was chosen to give a
> bit of margin.
>
> Signed-off-by: Douglas Anderson 
> ---
> I don't actually have a device in front of me that is exhibiting these
> problems.  I believe that it is only some devices and some of the
> time.  Still, this patch seems safe and seems likely to fix the issue
> given the scope shots.

Just to follow-up, I just heard that someone who had a panel
exhibiting this problem tried my patch and it fixed it for them.  :-)
So this is not such a shot in the dark anymore.

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


[Bug 208589] amdgpu screen corruption with DRI_PRIME on external monitor at resolution 2560x1440 and more then 60hz

2020-07-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208589

--- Comment #3 from d...@rodler-keller.de ---
"echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level"

hm fixes the screen coruption

-- 
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 8/8] drm/mgag200: Add support for G200 desktop cards

2020-07-20 Thread Sam Ravnborg
On Mon, Jul 20, 2020 at 03:18:56PM -0400, Lyude Paul wrote:
> On Mon, 2020-07-20 at 09:04 +0200, Thomas Zimmermann wrote:
> > Hi
> > 
> > Am 17.07.20 um 00:43 schrieb Lyude Paul:
> > > On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
> > > > This patch adds support for G200 desktop cards. We can reuse the whole
> > > > memory and modesetting code. A few PCI and DAC register values have to
> > > > be updated accordingly.
> > > > 
> > > > The most significant change is in the PLL setup. The get the clock
> > > > limits
> > > > and reference clocks, parses the device's BIOS. With no BIOS found, safe
> > > > defaults are being used.
> > > > 
> > > > Signed-off-by: Thomas Zimmermann 
> > > > Co-developed-by: Egbert Eich 
> > > > Signed-off-by: Egbert Eich 
> > > > Co-developed-by: Takashi Iwai 
> > > > Signed-off-by: Takashi Iwai 
> > > > ---
> > > >  MAINTAINERS|   2 +-
> > > >  drivers/gpu/drm/mgag200/Kconfig|  12 +--
> > > >  drivers/gpu/drm/mgag200/mgag200_drv.c  | 125 -
> > > >  drivers/gpu/drm/mgag200/mgag200_drv.h  |  10 ++
> > > >  drivers/gpu/drm/mgag200/mgag200_mode.c |  80 
> > > >  5 files changed, 220 insertions(+), 9 deletions(-)
> > > > 
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 415954a98934..4c6f96e2b79b 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -5406,7 +5406,7 @@ S:Orphan / Obsolete
> > > >  F: drivers/gpu/drm/mga/
> > > >  F: include/uapi/drm/mga_drm.h
> > > >  
> > > > -DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS
> > > > +DRM DRIVER FOR MGA G200 GRAPHICS CHIPS
> > > >  M: Dave Airlie 
> > > >  S: Odd Fixes
> > > >  F: drivers/gpu/drm/mgag200/
> > > > diff --git a/drivers/gpu/drm/mgag200/Kconfig
> > > > b/drivers/gpu/drm/mgag200/Kconfig
> > > > index 93be766715c9..eec59658a938 100644
> > > > --- a/drivers/gpu/drm/mgag200/Kconfig
> > > > +++ b/drivers/gpu/drm/mgag200/Kconfig
> > > > @@ -1,13 +1,11 @@
> > > >  # SPDX-License-Identifier: GPL-2.0-only
> > > >  config DRM_MGAG200
> > > > -   tristate "Kernel modesetting driver for MGA G200 server engines"
> > > > +   tristate "Matrox G200"
> > > > depends on DRM && PCI && MMU
> > > > select DRM_GEM_SHMEM_HELPER
> > > > select DRM_KMS_HELPER
> > > > help
> > > > -This is a KMS driver for the MGA G200 server chips, it
> > > > -does not support the original MGA G200 or any of the desktop
> > > > -chips. It requires 0.3.0 of the modesetting userspace driver,
> > > > -and a version of mga driver that will fail on KMS enabled
> > > > -devices.
> > > > -
> > > > +This is a KMS driver for Matrox G200 chips. It supports the 
> > > > original
> > > > +MGA G200 desktop chips and the server variants. It requires 
> > > > 0.3.0
> > > > +of the modesetting userspace driver, and a version of mga 
> > > > driver
> > > > +that will fail on KMS enabled devices.
> > > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > > b/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > > index f7652e16365c..419817d6e2cd 100644
> > > > --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > > @@ -64,6 +64,14 @@ static int mgag200_regs_init(struct mga_device *mdev)
> > > > u8 crtcext3;
> > > >  
> > > > switch (mdev->type) {
> > > > +   case G200_PCI:
> > > > +   case G200_AGP:
> > > > +   if (mgag200_has_sgram(mdev))
> > > > +   option = 0x4049cd21;
> > > > +   else
> > > > +   option = 0x40499121;
> > > > +   option2 = 0x8000;
> > > > +   break;
> > > > case G200_SE_A:
> > > > case G200_SE_B:
> > > > if (mgag200_has_sgram(mdev))
> > > > @@ -115,6 +123,117 @@ static int mgag200_regs_init(struct mga_device
> > > > *mdev)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static void mgag200_g200_interpret_bios(struct mga_device *mdev,
> > > > +   unsigned char __iomem *bios,
> > > > +   size_t size)
> > > > +{
> > > > +   static const unsigned int expected_length[6] = {
> > > > +   0, 64, 64, 64, 128, 128
> > > > +   };
> > > > +
> > > > +   struct drm_device *dev = >base;
> > > > +   unsigned char __iomem *pins;
> > > 
> > > huh, never realized you could write directly to unsigned char __iomem
> > > pointers!
> > 
> > I took the patch as-is, but this probably wouldn't work on all
> > architectures.
> 
> Something occurred to me just now - do we actually care? I don't think I've
> ever seen mgag200 on anything other then x86_64 systems

For starters to silence the sparse warnings.
Also other parts of the driver uses the io{read,write} functions
so to be consistent this code shoudl also do it.
And to avoid having bad 

Re: [PATCH] video: fbdev: pvr2fb: initialize variables

2020-07-20 Thread Arnd Bergmann
On Mon, Jul 20, 2020 at 9:19 PM  wrote:
>
> From: Tom Rix 
>
> clang static analysis reports this repesentative error
>
> pvr2fb.c:1049:2: warning: 1st function call argument
>   is an uninitialized value [core.CallAndMessage]
> if (*cable_arg)
> ^~~
>
> Problem is that cable_arg depends on the input loop to
> set the cable_arg[0].  If it does not, then some random
> value from the stack is used.
>
> A similar problem exists for output_arg.
>
> So initialize cable_arg and output_arg.

Adding a zero-initialization is almost never the correct way to
deal with these warnings, so one has to be careful doing this.

I checked this file, and your patch is absolutely correct here. ;-)

> Signed-off-by: Tom Rix 

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


[PATCH] video: fbdev: pvr2fb: initialize variables

2020-07-20 Thread trix
From: Tom Rix 

clang static analysis reports this repesentative error

pvr2fb.c:1049:2: warning: 1st function call argument
  is an uninitialized value [core.CallAndMessage]
if (*cable_arg)
^~~

Problem is that cable_arg depends on the input loop to
set the cable_arg[0].  If it does not, then some random
value from the stack is used.

A similar problem exists for output_arg.

So initialize cable_arg and output_arg.

Signed-off-by: Tom Rix 
---
 drivers/video/fbdev/pvr2fb.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
index 2d9f69b93392..f4add36cb5f4 100644
--- a/drivers/video/fbdev/pvr2fb.c
+++ b/drivers/video/fbdev/pvr2fb.c
@@ -1028,6 +1028,8 @@ static int __init pvr2fb_setup(char *options)
if (!options || !*options)
return 0;
 
+   cable_arg[0] = output_arg[0] = 0;
+
while ((this_opt = strsep(, ","))) {
if (!*this_opt)
continue;
-- 
2.18.1

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


Re: [PATCH 8/8] drm/mgag200: Add support for G200 desktop cards

2020-07-20 Thread Lyude Paul
On Mon, 2020-07-20 at 09:04 +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 17.07.20 um 00:43 schrieb Lyude Paul:
> > On Wed, 2020-07-15 at 16:59 +0200, Thomas Zimmermann wrote:
> > > This patch adds support for G200 desktop cards. We can reuse the whole
> > > memory and modesetting code. A few PCI and DAC register values have to
> > > be updated accordingly.
> > > 
> > > The most significant change is in the PLL setup. The get the clock
> > > limits
> > > and reference clocks, parses the device's BIOS. With no BIOS found, safe
> > > defaults are being used.
> > > 
> > > Signed-off-by: Thomas Zimmermann 
> > > Co-developed-by: Egbert Eich 
> > > Signed-off-by: Egbert Eich 
> > > Co-developed-by: Takashi Iwai 
> > > Signed-off-by: Takashi Iwai 
> > > ---
> > >  MAINTAINERS|   2 +-
> > >  drivers/gpu/drm/mgag200/Kconfig|  12 +--
> > >  drivers/gpu/drm/mgag200/mgag200_drv.c  | 125 -
> > >  drivers/gpu/drm/mgag200/mgag200_drv.h  |  10 ++
> > >  drivers/gpu/drm/mgag200/mgag200_mode.c |  80 
> > >  5 files changed, 220 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 415954a98934..4c6f96e2b79b 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -5406,7 +5406,7 @@ S:  Orphan / Obsolete
> > >  F:   drivers/gpu/drm/mga/
> > >  F:   include/uapi/drm/mga_drm.h
> > >  
> > > -DRM DRIVER FOR MGA G200 SERVER GRAPHICS CHIPS
> > > +DRM DRIVER FOR MGA G200 GRAPHICS CHIPS
> > >  M:   Dave Airlie 
> > >  S:   Odd Fixes
> > >  F:   drivers/gpu/drm/mgag200/
> > > diff --git a/drivers/gpu/drm/mgag200/Kconfig
> > > b/drivers/gpu/drm/mgag200/Kconfig
> > > index 93be766715c9..eec59658a938 100644
> > > --- a/drivers/gpu/drm/mgag200/Kconfig
> > > +++ b/drivers/gpu/drm/mgag200/Kconfig
> > > @@ -1,13 +1,11 @@
> > >  # SPDX-License-Identifier: GPL-2.0-only
> > >  config DRM_MGAG200
> > > - tristate "Kernel modesetting driver for MGA G200 server engines"
> > > + tristate "Matrox G200"
> > >   depends on DRM && PCI && MMU
> > >   select DRM_GEM_SHMEM_HELPER
> > >   select DRM_KMS_HELPER
> > >   help
> > > -  This is a KMS driver for the MGA G200 server chips, it
> > > -  does not support the original MGA G200 or any of the desktop
> > > -  chips. It requires 0.3.0 of the modesetting userspace driver,
> > > -  and a version of mga driver that will fail on KMS enabled
> > > -  devices.
> > > -
> > > +  This is a KMS driver for Matrox G200 chips. It supports the original
> > > +  MGA G200 desktop chips and the server variants. It requires 0.3.0
> > > +  of the modesetting userspace driver, and a version of mga driver
> > > +  that will fail on KMS enabled devices.
> > > diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > b/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > index f7652e16365c..419817d6e2cd 100644
> > > --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> > > @@ -64,6 +64,14 @@ static int mgag200_regs_init(struct mga_device *mdev)
> > >   u8 crtcext3;
> > >  
> > >   switch (mdev->type) {
> > > + case G200_PCI:
> > > + case G200_AGP:
> > > + if (mgag200_has_sgram(mdev))
> > > + option = 0x4049cd21;
> > > + else
> > > + option = 0x40499121;
> > > + option2 = 0x8000;
> > > + break;
> > >   case G200_SE_A:
> > >   case G200_SE_B:
> > >   if (mgag200_has_sgram(mdev))
> > > @@ -115,6 +123,117 @@ static int mgag200_regs_init(struct mga_device
> > > *mdev)
> > >   return 0;
> > >  }
> > >  
> > > +static void mgag200_g200_interpret_bios(struct mga_device *mdev,
> > > + unsigned char __iomem *bios,
> > > + size_t size)
> > > +{
> > > + static const unsigned int expected_length[6] = {
> > > + 0, 64, 64, 64, 128, 128
> > > + };
> > > +
> > > + struct drm_device *dev = >base;
> > > + unsigned char __iomem *pins;
> > 
> > huh, never realized you could write directly to unsigned char __iomem
> > pointers!
> 
> I took the patch as-is, but this probably wouldn't work on all
> architectures.

Something occurred to me just now - do we actually care? I don't think I've
ever seen mgag200 on anything other then x86_64 systems

> 
> > > + unsigned int pins_len, version;
> > > + int offset;
> > > + int tmp;
> > > +
> > > + if (size < MGA_BIOS_OFFSET + 1)
> > > + return;
> > > +
> > > + if (bios[45] != 'M' || bios[46] != 'A' || bios[47] != 'T' ||
> > > + bios[48] != 'R' || bios[49] != 'O' || bios[50] != 'X')
> > > + return;
> > > +
> > > + offset = (bios[MGA_BIOS_OFFSET + 1] << 8) | bios[MGA_BIOS_OFFSET];
> > > +
> > > + if (offset + 5 > size)
> > > + return;
> > > +
> > > + pins = bios + offset;
> > > + if (pins[0] == 0x2e && pins[1] == 0x41) {
> > > + version = pins[5];
> > > + pins_len = pins[2];
> > > + } else {
> > > + version = 1;
> > > + pins_len = 

Re: [PATCH v6 4/4] dt-bindings: display: imx: add bindings for DCSS

2020-07-20 Thread Rob Herring
On Mon, Jul 20, 2020 at 10:55 AM Laurentiu Palcu
 wrote:
>
> Hi Rob,
>
> On Mon, Jul 20, 2020 at 10:49:27AM -0600, Rob Herring wrote:
> > On Fri, 17 Jul 2020 17:41:29 +0300, Laurentiu Palcu wrote:
> > > From: Laurentiu Palcu 
> > >
> > > Add bindings for iMX8MQ Display Controller Subsystem.
> > >
> > > Signed-off-by: Laurentiu Palcu 
> > > ---
> > >  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
> > >  1 file changed, 104 insertions(+)
> > >  create mode 100644 
> > > Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > >
> >
> >
> > Please add Acked-by/Reviewed-by tags when posting new versions. However,
> > there's no need to repost patches *only* to add the tags. The upstream
> > maintainer will do that for acks received on the version they apply.
> >
> > If a tag was not added on purpose, please state why and what changed.
>
> Well, I kind of did exactly that... in the cover letter. I stated
> clearly why this patch needs another look... :/

Put information closest to where it applies which is this patch. I
don't read cover letters typically.

R-by still stands.

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


[PATCH 2/5] drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_on()

2020-07-20 Thread Lyude Paul
This is only called from:
* Atomic modesetting hooks
* Module probing routines
* Legacy modesetting hooks

All of which have IRQs enabled, so we can also get rid of
irqsave/restore here to make the IRQ context of this function more
obvious.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 6af78aecea9d4..9891e82939e35 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1428,12 +1428,11 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
unsigned int pipe = drm_crtc_index(crtc);
struct drm_vblank_crtc *vblank = >vblank[pipe];
-   unsigned long irqflags;
 
if (drm_WARN_ON(dev, pipe >= dev->num_crtcs))
return;
 
-   spin_lock_irqsave(>vbl_lock, irqflags);
+   spin_lock_irq(>vbl_lock);
drm_dbg_vbl(dev, "crtc %d, vblank enabled %d, inmodeset %d\n",
pipe, vblank->enabled, vblank->inmodeset);
 
@@ -1451,7 +1450,7 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
 */
if (atomic_read(>refcount) != 0 || drm_vblank_offdelay == 0)
drm_WARN_ON(dev, drm_vblank_enable(dev, pipe));
-   spin_unlock_irqrestore(>vbl_lock, irqflags);
+   spin_unlock_irq(>vbl_lock);
 }
 EXPORT_SYMBOL(drm_crtc_vblank_on);
 
-- 
2.26.2

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


[PATCH 4/5] drm/vblank: Use spin_(un)lock_irq() in drm_queue_vblank_event()

2020-07-20 Thread Lyude Paul
This one's easy - we're already calling kzalloc() in this function, so
we must already be guaranteed to have IRQs enabled when calling this.
So, use the plain _irq() variants of spin_(un)lock() to make this more
obvious.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 51f2e988205e7..64610070ba473 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1611,7 +1611,6 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
struct drm_vblank_crtc *vblank = >vblank[pipe];
struct drm_pending_vblank_event *e;
ktime_t now;
-   unsigned long flags;
u64 seq;
int ret;
 
@@ -1633,7 +1632,7 @@ static int drm_queue_vblank_event(struct drm_device *dev, 
unsigned int pipe,
e->event.vbl.crtc_id = crtc->base.id;
}
 
-   spin_lock_irqsave(>event_lock, flags);
+   spin_lock_irq(>event_lock);
 
/*
 * drm_crtc_vblank_off() might have been called after we called
@@ -1670,12 +1669,12 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, unsigned int pipe,
vblwait->reply.sequence = req_seq;
}
 
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock_irq(>event_lock);
 
return 0;
 
 err_unlock:
-   spin_unlock_irqrestore(>event_lock, flags);
+   spin_unlock_irq(>event_lock);
kfree(e);
 err_put:
drm_vblank_put(dev, pipe);
-- 
2.26.2

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


[PATCH 5/5] drm/vblank: Use spin_(un)lock_irq() in drm_crtc_queue_sequence_ioctl()

2020-07-20 Thread Lyude Paul
This is an ioctl callback, so we're guaranteed to have IRQs enabled when
calling this function. Use the plain _irq() variants of spin_(un)lock()
to make this more obvious.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 64610070ba473..b18e1efbbae1a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -2066,7 +2066,6 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, 
void *data,
u64 seq;
u64 req_seq;
int ret;
-   unsigned long spin_flags;
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -2114,7 +2113,7 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, 
void *data,
e->event.base.length = sizeof(e->event.seq);
e->event.seq.user_data = queue_seq->user_data;
 
-   spin_lock_irqsave(>event_lock, spin_flags);
+   spin_lock_irq(>event_lock);
 
/*
 * drm_crtc_vblank_off() might have been called after we called
@@ -2145,11 +2144,11 @@ int drm_crtc_queue_sequence_ioctl(struct drm_device 
*dev, void *data,
queue_seq->sequence = req_seq;
}
 
-   spin_unlock_irqrestore(>event_lock, spin_flags);
+   spin_unlock_irq(>event_lock);
return 0;
 
 err_unlock:
-   spin_unlock_irqrestore(>event_lock, spin_flags);
+   spin_unlock_irq(>event_lock);
drm_crtc_vblank_put(crtc);
 err_free:
kfree(e);
-- 
2.26.2

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


[Bug 208589] amdgpu screen corruption with DRI_PRIME on external monitor at resolution 2560x1440 and more then 60hz

2020-07-20 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=208589

--- Comment #2 from d...@rodler-keller.de ---
no the screen corutpion still exists

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


[PATCH 3/5] drm/vblank: Use spin_(un)lock_irq() in drm_legacy_vblank_post_modeset()

2020-07-20 Thread Lyude Paul
This function is only ever called from ioctl context, so we're
guaranteed to have interrupts enabled. Stop using the irqsave/irqrestore
variants of spin_(un)lock_irq() to make this more obvious.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 9891e82939e35..51f2e988205e7 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1551,7 +1551,6 @@ static void drm_legacy_vblank_post_modeset(struct 
drm_device *dev,
   unsigned int pipe)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
-   unsigned long irqflags;
 
/* vblank is not initialized (IRQ not installed ?), or has been freed */
if (!drm_dev_has_vblank(dev))
@@ -1561,9 +1560,9 @@ static void drm_legacy_vblank_post_modeset(struct 
drm_device *dev,
return;
 
if (vblank->inmodeset) {
-   spin_lock_irqsave(>vbl_lock, irqflags);
+   spin_lock_irq(>vbl_lock);
drm_reset_vblank_timestamp(dev, pipe);
-   spin_unlock_irqrestore(>vbl_lock, irqflags);
+   spin_unlock_irq(>vbl_lock);
 
if (vblank->inmodeset & 0x2)
drm_vblank_put(dev, pipe);
-- 
2.26.2

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


[PATCH 0/5] drm/vblank: Cleanup spin_(un)lock_irqsave() calls

2020-07-20 Thread Lyude Paul
This is a follow-up series for finishing the work that we started here:

https://patchwork.freedesktop.org/patch/373107/?series=74805=8

tl;dr many of the drm_vblank functions only get called within
irq-enabled contexts, so we go through those and convert them over to
using spin_(un)lock_irq() to make this fact more obvious in case we need
to add more blocking calls to any of these functions in the future.

Lyude Paul (5):
  drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_reset()
  drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_on()
  drm/vblank: Use spin_(un)lock_irq() in
drm_legacy_vblank_post_modeset()
  drm/vblank: Use spin_(un)lock_irq() in drm_queue_vblank_event()
  drm/vblank: Use spin_(un)lock_irq() in drm_crtc_queue_sequence_ioctl()

 drivers/gpu/drm/drm_vblank.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

-- 
2.26.2

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


[PATCH 1/5] drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_reset()

2020-07-20 Thread Lyude Paul
All of the drivers in the kernel tree only call this from one of the
following contexts:

* drm_crtc_funcs->reset
* During initial module load

Since both of these contexts are guaranteed to have interrupts enabled
beforehand, there's no need to use the irqsave/irqrestore variants of
spin_(un)lock(). So, fix this to make the irq context of this function
more obvious.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_vblank.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index f402c75b9d343..6af78aecea9d4 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1363,11 +1363,10 @@ EXPORT_SYMBOL(drm_crtc_vblank_off);
 void drm_crtc_vblank_reset(struct drm_crtc *crtc)
 {
struct drm_device *dev = crtc->dev;
-   unsigned long irqflags;
unsigned int pipe = drm_crtc_index(crtc);
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
-   spin_lock_irqsave(>vbl_lock, irqflags);
+   spin_lock_irq(>vbl_lock);
/*
 * Prevent subsequent drm_vblank_get() from enabling the vblank
 * interrupt by bumping the refcount.
@@ -1376,7 +1375,7 @@ void drm_crtc_vblank_reset(struct drm_crtc *crtc)
atomic_inc(>refcount);
vblank->inmodeset = 1;
}
-   spin_unlock_irqrestore(>vbl_lock, irqflags);
+   spin_unlock_irq(>vbl_lock);
 
drm_WARN_ON(dev, !list_empty(>vblank_event_list));
drm_WARN_ON(dev, !list_empty(>pending_work));
-- 
2.26.2

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


[GIT PULL] etnaviv-next for 5.9

2020-07-20 Thread Lucas Stach
Hi Dave, Daniel,

please pull the following etnaviv updates for 5.9.

Nothing too exciting:
- a cleanup of our clock handling and improved error handling in this
area from Lubomir
- conversion to pin_user_pages for long page references from John
- fixed PM runtime API error handling from Navid

Regards,
Lucas

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/next

for you to fetch changes up to c5d5a32ead1e3a61a07a1e59eb52a53e4a6b2a7f:

  drm/etnaviv: fix ref count leak via pm_runtime_get_sync (2020-07-17 17:10:34 
+0200)


John Hubbard (1):
  drm/etnaviv: convert get_user_pages() --> pin_user_pages()

Lubomir Rintel (4):
  drm/etnaviv: Fix error path on failure to enable bus clk
  drm/etnaviv: Don't ignore errors on getting clocks
  drm/etnaviv: Make the "core" clock mandatory
  drm/etnaviv: Simplify clock enable/disable

Navid Emamdoost (1):
  drm/etnaviv: fix ref count leak via pm_runtime_get_sync

 drivers/gpu/drm/etnaviv/etnaviv_gem.c |  6 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 80 
+
 2 files changed, 40 insertions(+), 46 deletions(-)

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


Re: [PATCH v6 4/4] dt-bindings: display: imx: add bindings for DCSS

2020-07-20 Thread Laurentiu Palcu
Hi Rob,

On Mon, Jul 20, 2020 at 10:49:27AM -0600, Rob Herring wrote:
> On Fri, 17 Jul 2020 17:41:29 +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu 
> > 
> > Add bindings for iMX8MQ Display Controller Subsystem.
> > 
> > Signed-off-by: Laurentiu Palcu 
> > ---
> >  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
> >  1 file changed, 104 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> > 
> 
> 
> Please add Acked-by/Reviewed-by tags when posting new versions. However,
> there's no need to repost patches *only* to add the tags. The upstream
> maintainer will do that for acks received on the version they apply.
> 
> If a tag was not added on purpose, please state why and what changed.

Well, I kind of did exactly that... in the cover letter. I stated
clearly why this patch needs another look... :/

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


Re: [PATCH v6 4/4] dt-bindings: display: imx: add bindings for DCSS

2020-07-20 Thread Rob Herring
On Fri, 17 Jul 2020 17:41:29 +0300, Laurentiu Palcu wrote:
> From: Laurentiu Palcu 
> 
> Add bindings for iMX8MQ Display Controller Subsystem.
> 
> Signed-off-by: Laurentiu Palcu 
> ---
>  .../bindings/display/imx/nxp,imx8mq-dcss.yaml | 104 ++
>  1 file changed, 104 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/imx/nxp,imx8mq-dcss.yaml
> 


Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.

If a tag was not added on purpose, please state why and what changed.

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


Re: [PATCH v2] drm: pl111: Update documentation

2020-07-20 Thread Daniel Vetter
On Mon, Jul 20, 2020 at 03:03:27PM +0200, Linus Walleij wrote:
> Remove notes about migrating from the old driver which is
> retired as all users are now migrated.
> 
> Update the text to reflect that we support PL110 and PL111
> alike.
> 
> Drop the bullet on memory bandwidth scaling: this has been
> implemented.
> 
> Cc: Russell King 
> Signed-off-by: Linus Walleij 
> ---
> ChangeLog v1->v2:
> - Fix up the documentation rst link as well so we don't
>   get build failures in the documentation.

I'm always happy when people take care of the docs.

Acked-by: Daniel Vetter 
> ---
>  Documentation/gpu/pl111.rst   |  8 
>  drivers/gpu/drm/pl111/pl111_drv.c | 20 +---
>  2 files changed, 9 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/gpu/pl111.rst b/Documentation/gpu/pl111.rst
> index 9b03736d33dd..6d9a1b59a545 100644
> --- a/Documentation/gpu/pl111.rst
> +++ b/Documentation/gpu/pl111.rst
> @@ -1,6 +1,6 @@
> -==
> - drm/pl111 ARM PrimeCell PL111 CLCD Driver
> -==
> +
> + drm/pl111 ARM PrimeCell PL110 and PL111 CLCD Driver
> +
>  
>  .. kernel-doc:: drivers/gpu/drm/pl111/pl111_drv.c
> -   :doc: ARM PrimeCell PL111 CLCD Driver
> +   :doc: ARM PrimeCell PL110 and PL111 CLCD Driver
> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
> b/drivers/gpu/drm/pl111/pl111_drv.c
> index 96e58fda75d8..46b0d1c4a16c 100644
> --- a/drivers/gpu/drm/pl111/pl111_drv.c
> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
> @@ -10,18 +10,11 @@
>   */
>  
>  /**
> - * DOC: ARM PrimeCell PL111 CLCD Driver
> + * DOC: ARM PrimeCell PL110 and PL111 CLCD Driver
>   *
> - * The PL111 is a simple LCD controller that can support TFT and STN
> - * displays.  This driver exposes a standard KMS interface for them.
> - *
> - * This driver uses the same Device Tree binding as the fbdev CLCD
> - * driver.  While the fbdev driver supports panels that may be
> - * connected to the CLCD internally to the CLCD driver, in DRM the
> - * panels get split out to drivers/gpu/drm/panels/.  This means that,
> - * in converting from using fbdev to using DRM, you also need to write
> - * a panel driver (which may be as simple as an entry in
> - * panel-simple.c).
> + * The PL110/PL111 is a simple LCD controller that can support TFT
> + * and STN displays. This driver exposes a standard KMS interface
> + * for them.
>   *
>   * The driver currently doesn't expose the cursor.  The DRM API for
>   * cursors requires support for 64x64 ARGB cursor images, while
> @@ -29,16 +22,13 @@
>   * cursors.  While one could imagine trying to hack something together
>   * to look at the ARGB and program reasonable in monochrome, we
>   * just don't expose the cursor at all instead, and leave cursor
> - * support to the X11 software cursor layer.
> + * support to the application software cursor layer.
>   *
>   * TODO:
>   *
>   * - Fix race between setting plane base address and getting IRQ for
>   *   vsync firing the pageflip completion.
>   *
> - * - Use the "max-memory-bandwidth" DT property to filter the
> - *   supported formats.
> - *
>   * - Read back hardware state at boot to skip reprogramming the
>   *   hardware when doing a no-op modeset.
>   *
> -- 
> 2.26.2
> 
> ___
> 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


[PATCH v10 12/13] drm/msm/a6xx: Add support for per-instance pagetables

2020-07-20 Thread Jordan Crouse
Add support for using per-instance pagetables if all the dependencies are
available.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 53 +++
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |  1 +
 drivers/gpu/drm/msm/msm_ringbuffer.h  |  1 +
 3 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 5eabb0109577..57c6cdec7e9a 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -81,6 +81,41 @@ static void get_stats_counter(struct msm_ringbuffer *ring, 
u32 counter,
OUT_RING(ring, upper_32_bits(iova));
 }
 
+static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
+   struct msm_ringbuffer *ring, struct msm_file_private *ctx)
+{
+   phys_addr_t ttbr;
+   u32 asid;
+   u64 memptr = rbmemptr(ring, ttbr0);
+
+   if (ctx == a6xx_gpu->cur_ctx)
+   return;
+
+   if (msm_iommu_pagetable_params(ctx->aspace->mmu, , ))
+   return;
+
+   /* Execute the table update */
+   OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
+   OUT_RING(ring, CP_SMMU_TABLE_UPDATE_0_TTBR0_LO(lower_32_bits(ttbr)));
+   OUT_RING(ring,
+   CP_SMMU_TABLE_UPDATE_1_TTBR0_HI(upper_32_bits(ttbr)) |
+   CP_SMMU_TABLE_UPDATE_1_ASID(asid));
+   OUT_RING(ring, CP_SMMU_TABLE_UPDATE_2_CONTEXTIDR(0));
+   OUT_RING(ring, CP_SMMU_TABLE_UPDATE_3_CONTEXTBANK(0));
+
+   /*
+* Write the new TTBR0 to the memstore. This is good for debugging.
+*/
+   OUT_PKT7(ring, CP_MEM_WRITE, 4);
+   OUT_RING(ring, CP_MEM_WRITE_0_ADDR_LO(lower_32_bits(memptr)));
+   OUT_RING(ring, CP_MEM_WRITE_1_ADDR_HI(upper_32_bits(memptr)));
+   OUT_RING(ring, lower_32_bits(ttbr));
+   OUT_RING(ring, (asid << 16) | upper_32_bits(ttbr));
+
+
+   a6xx_gpu->cur_ctx = ctx;
+}
+
 static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
 {
unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
@@ -90,6 +125,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit)
struct msm_ringbuffer *ring = submit->ring;
unsigned int i;
 
+   a6xx_set_pagetable(a6xx_gpu, ring, submit->queue->ctx);
+
get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
rbmemptr_stats(ring, index, cpcycles_start));
 
@@ -696,6 +733,8 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
/* Always come up on rb 0 */
a6xx_gpu->cur_ring = gpu->rb[0];
 
+   a6xx_gpu->cur_ctx = NULL;
+
/* Enable the SQE_to start the CP engine */
gpu_write(gpu, REG_A6XX_CP_SQE_CNTL, 1);
 
@@ -1008,6 +1047,19 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
return (unsigned long)busy_time;
 }
 
+static struct msm_gem_address_space *
+a6xx_create_private_address_space(struct msm_gpu *gpu)
+{
+   struct msm_mmu *mmu;
+
+   mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
+   if (IS_ERR(mmu))
+   return msm_gem_address_space_get(gpu->aspace);
+
+   return msm_gem_address_space_create(mmu,
+   "gpu", 0x1ULL, 0x1ULL);
+}
+
 static const struct adreno_gpu_funcs funcs = {
.base = {
.get_param = adreno_get_param,
@@ -1031,6 +1083,7 @@ static const struct adreno_gpu_funcs funcs = {
.gpu_state_put = a6xx_gpu_state_put,
 #endif
.create_address_space = adreno_iommu_create_address_space,
+   .create_private_address_space = 
a6xx_create_private_address_space,
},
.get_timestamp = a6xx_get_timestamp,
 };
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
index 03ba60d5b07f..da22d7549d9b 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
@@ -19,6 +19,7 @@ struct a6xx_gpu {
uint64_t sqe_iova;
 
struct msm_ringbuffer *cur_ring;
+   struct msm_file_private *cur_ctx;
 
struct a6xx_gmu gmu;
 };
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h 
b/drivers/gpu/drm/msm/msm_ringbuffer.h
index 7764373d0ed2..0987d6bf848c 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.h
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
@@ -31,6 +31,7 @@ struct msm_rbmemptrs {
volatile uint32_t fence;
 
volatile struct msm_gpu_submit_stats stats[MSM_GPU_SUBMIT_STATS_COUNT];
+   volatile u64 ttbr0;
 };
 
 struct msm_ringbuffer {
-- 
2.25.1

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


[PATCH v10 00/13] iommu/arm-smmu: Add Adreno SMMU specific implementation

2020-07-20 Thread Jordan Crouse
(reworded the summary to reflect ongoing changes in the code)

This series adds an Adreno SMMU implementation to arm-smmu to allow GPU hardware
pagetable switching.

The Adreno GPU has built in capabilities to switch the TTBR0 pagetable during
runtime to allow each individual instance or application to have its own
pagetable.  In order to take advantage of the HW capabilities there are certain
requirements needed of the SMMU hardware.

This series adds support for an Adreno specific arm-smmu implementation. The new
implementation 1) ensures that the GPU domain is always assigned context bank 0,
2) enables split pagetable support (TTBR1) so that the instance specific
pagetable can be swapped while the global memory remains in place and 3) shares
the current pagetable configuration with the GPU driver to allow it to create
its own io-pgtable instances.

The series then adds the drm/msm code to enable these features. For targets that
support it allocate new pagetables using the io-pgtable configuration shared by
the arm-smmu driver and swap them in during runtime.

This version of the series merges the previous patchset(s) [1] and [2]
with the following improvements:

  - arm-smmu: add implementation hook to allocate context banks
  - arm-smmu: Match the GPU domain by stream ID instead of compatible string
  - arm-smmu: Make DOMAIN_ATTR_PGTABLE_CFG bi-directional. The leaf driver
queries the configuration to create a pagetable and then sends the newly
created configuration back to the smmu-driver to enable TTBR0
  - drm/msm: Add context reference counting for submissions
  - drm/msm: Use dummy functions to skip TLB operations on per-instance
pagetables

[1] https://lists.linuxfoundation.org/pipermail/iommu/2020-June/045653.html
[2] https://lists.linuxfoundation.org/pipermail/iommu/2020-June/045659.html


Jordan Crouse (13):
  iommu/arm-smmu: Pass io-pgtable config to implementation specific
function
  iommu/arm-smmu: Add support for split pagetables
  iommu/arm-smmu: Add implementation hooks to configure contexts
  iommu/arm-smmu-qcom: Add implementation for the adreno GPU SMMU
  iommu: Add a domain attribute to get/set a pagetable configuration
  iommu/arm-smmu-qcom: Get and set the pagetable config for split
pagetables
  dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU
  drm/msm: Add a context pointer to the submitqueue
  drm/msm: Set the global virtual address range from the IOMMU domain
  drm/msm: Add support to create a local pagetable
  drm/msm: Add support for private address space instances
  drm/msm/a6xx: Add support for per-instance pagetables
  arm: dts: qcom: sm845: Set the compatible string for the GPU SMMU

 .../devicetree/bindings/iommu/arm,smmu.yaml   |   4 +
 arch/arm64/boot/dts/qcom/sdm845.dtsi  |   2 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  12 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  58 -
 drivers/gpu/drm/msm/adreno/a6xx_gpu.h |   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  18 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |   3 +-
 drivers/gpu/drm/msm/msm_drv.c |  16 +-
 drivers/gpu/drm/msm/msm_drv.h |  13 ++
 drivers/gpu/drm/msm/msm_gem.h |   1 +
 drivers/gpu/drm/msm/msm_gem_submit.c  |   8 +-
 drivers/gpu/drm/msm/msm_gem_vma.c |   9 +
 drivers/gpu/drm/msm/msm_gpu.c |  26 ++-
 drivers/gpu/drm/msm/msm_gpu.h |  12 +-
 drivers/gpu/drm/msm/msm_gpummu.c  |   2 +-
 drivers/gpu/drm/msm/msm_iommu.c   | 198 +-
 drivers/gpu/drm/msm/msm_mmu.h |  16 +-
 drivers/gpu/drm/msm/msm_ringbuffer.h  |   1 +
 drivers/gpu/drm/msm/msm_submitqueue.c |   8 +-
 drivers/iommu/arm-smmu-impl.c |   6 +-
 drivers/iommu/arm-smmu-qcom.c | 130 +++-
 drivers/iommu/arm-smmu.c  | 108 +-
 drivers/iommu/arm-smmu.h  |  65 +-
 include/linux/iommu.h |   1 +
 24 files changed, 619 insertions(+), 99 deletions(-)

-- 
2.25.1

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


[PATCH v10 11/13] drm/msm: Add support for private address space instances

2020-07-20 Thread Jordan Crouse
Add support for allocating private address space instances. Targets that
support per-context pagetables should implement their own function to
allocate private address spaces.

The default will return a pointer to the global address space.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_drv.c | 13 +++--
 drivers/gpu/drm/msm/msm_drv.h |  5 +
 drivers/gpu/drm/msm/msm_gem_vma.c |  9 +
 drivers/gpu/drm/msm/msm_gpu.c | 17 +
 drivers/gpu/drm/msm/msm_gpu.h |  5 +
 5 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 556198d4ba5f..c0328abea52d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -603,7 +603,7 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
kref_init(>ref);
msm_submitqueue_init(dev, ctx);
 
-   ctx->aspace = priv->gpu ? priv->gpu->aspace : NULL;
+   ctx->aspace = msm_gpu_create_private_address_space(priv->gpu);
file->driver_priv = ctx;
 
return 0;
@@ -786,18 +786,19 @@ static int msm_ioctl_gem_cpu_fini(struct drm_device *dev, 
void *data,
 }
 
 static int msm_ioctl_gem_info_iova(struct drm_device *dev,
-   struct drm_gem_object *obj, uint64_t *iova)
+   struct drm_file *file, struct drm_gem_object *obj,
+   uint64_t *iova)
 {
-   struct msm_drm_private *priv = dev->dev_private;
+   struct msm_file_private *ctx = file->driver_priv;
 
-   if (!priv->gpu)
+   if (!ctx->aspace)
return -EINVAL;
 
/*
 * Don't pin the memory here - just get an address so that userspace can
 * be productive
 */
-   return msm_gem_get_iova(obj, priv->gpu->aspace, iova);
+   return msm_gem_get_iova(obj, ctx->aspace, iova);
 }
 
 static int msm_ioctl_gem_info(struct drm_device *dev, void *data,
@@ -836,7 +837,7 @@ static int msm_ioctl_gem_info(struct drm_device *dev, void 
*data,
args->value = msm_gem_mmap_offset(obj);
break;
case MSM_INFO_GET_IOVA:
-   ret = msm_ioctl_gem_info_iova(dev, obj, >value);
+   ret = msm_ioctl_gem_info_iova(dev, file, obj, >value);
break;
case MSM_INFO_SET_NAME:
/* length check should leave room for terminating null: */
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index ab5f77261816..df400f9ec38c 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -250,6 +250,10 @@ int msm_gem_map_vma(struct msm_gem_address_space *aspace,
 void msm_gem_close_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma);
 
+
+struct msm_gem_address_space *
+msm_gem_address_space_get(struct msm_gem_address_space *aspace);
+
 void msm_gem_address_space_put(struct msm_gem_address_space *aspace);
 
 struct msm_gem_address_space *
@@ -435,6 +439,7 @@ static inline void msm_file_private_destroy(struct kref 
*kref)
struct msm_file_private *ctx = container_of(kref,
struct msm_file_private, ref);
 
+   msm_gem_address_space_put(ctx->aspace);
kfree(ctx);
 }
 
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c 
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 5f6a11211b64..29cc1305cf37 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -27,6 +27,15 @@ void msm_gem_address_space_put(struct msm_gem_address_space 
*aspace)
kref_put(>kref, msm_gem_address_space_destroy);
 }
 
+struct msm_gem_address_space *
+msm_gem_address_space_get(struct msm_gem_address_space *aspace)
+{
+   if (!IS_ERR_OR_NULL(aspace))
+   kref_get(>kref);
+
+   return aspace;
+}
+
 /* Actually unmap memory for the vma */
 void msm_gem_purge_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index a1f3da6550e5..aabbd7908ee5 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -823,6 +823,23 @@ static int get_clocks(struct platform_device *pdev, struct 
msm_gpu *gpu)
return 0;
 }
 
+/* Return a new address space for a msm_drm_private instance */
+struct msm_gem_address_space *
+msm_gpu_create_private_address_space(struct msm_gpu *gpu)
+{
+   if (!gpu)
+   return NULL;
+
+   /*
+* If the target doesn't support private address spaces then return
+* the global one
+*/
+   if (!gpu->funcs->create_private_address_space)
+   return msm_gem_address_space_get(gpu->aspace);
+
+   return gpu->funcs->create_private_address_space(gpu);
+}
+
 int msm_gpu_init(struct drm_device *drm, struct platform_device *pdev,
struct msm_gpu *gpu, const struct msm_gpu_funcs *funcs,
const char *name, struct msm_gpu_config 

[PATCH v10 09/13] drm/msm: Set the global virtual address range from the IOMMU domain

2020-07-20 Thread Jordan Crouse
Use the aperture settings from the IOMMU domain to set up the virtual
address range for the GPU. This allows us to transparently deal with
IOMMU side features (like split pagetables).

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
 drivers/gpu/drm/msm/msm_iommu.c |  7 +++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b38a8126541a..f9e3badf2fca 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
struct iommu_domain *iommu = iommu_domain_alloc(_bus_type);
struct msm_mmu *mmu = msm_iommu_new(>dev, iommu);
struct msm_gem_address_space *aspace;
+   u64 start, size;
 
-   aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
-   0x - SZ_16M);
+   /*
+* Use the aperture start or SZ_16M, whichever is greater. This will
+* ensure that we align with the allocated pagetable range while still
+* allowing room in the lower 32 bits for GMEM and whatnot
+*/
+   start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
+   size = iommu->geometry.aperture_end - start + 1;
+
+   aspace = msm_gem_address_space_create(mmu, "gpu",
+   start & GENMASK(48, 0), size);
 
if (IS_ERR(aspace) && !IS_ERR(mmu))
mmu->funcs->destroy(mmu);
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 3a381a9674c9..1b6635504069 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
 
+   /* The arm-smmu driver expects the addresses to be sign extended */
+   if (iova & BIT_ULL(48))
+   iova |= GENMASK_ULL(63, 49);
+
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
WARN_ON(!ret);
 
@@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t 
iova, size_t len)
 {
struct msm_iommu *iommu = to_msm_iommu(mmu);
 
+   if (iova & BIT_ULL(48))
+   iova |= GENMASK_ULL(63, 49);
+
iommu_unmap(iommu->domain, iova, len);
 
return 0;
-- 
2.25.1

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


[PATCH v10 08/13] drm/msm: Add a context pointer to the submitqueue

2020-07-20 Thread Jordan Crouse
Each submitqueue is attached to a context. Add a pointer to the
context to the submitqueue at create time and refcount it so
that it stays around through the life of the queue.

GPU submissions can access the active context via the submitqueue
instead of requiring it to be passed around from function to
function.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 12 +---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  5 ++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  5 ++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 +--
 drivers/gpu/drm/msm/msm_drv.c   |  3 ++-
 drivers/gpu/drm/msm/msm_drv.h   |  8 
 drivers/gpu/drm/msm/msm_gem.h   |  1 +
 drivers/gpu/drm/msm/msm_gem_submit.c|  8 
 drivers/gpu/drm/msm/msm_gpu.c   |  9 -
 drivers/gpu/drm/msm/msm_gpu.h   |  7 +++
 drivers/gpu/drm/msm/msm_submitqueue.c   |  8 +++-
 11 files changed, 39 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 9e63a190642c..eff2439ea57b 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -43,8 +43,7 @@ static void a5xx_flush(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
 }
 
-static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit 
*submit,
-   struct msm_file_private *ctx)
+static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct msm_gem_submit 
*submit)
 {
struct msm_drm_private *priv = gpu->dev->dev_private;
struct msm_ringbuffer *ring = submit->ring;
@@ -57,7 +56,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct 
msm_gem_submit *submit
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
break;
case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
-   if (priv->lastctx == ctx)
+   if (priv->lastctx == submit->queue->ctx)
break;
/* fall-thru */
case MSM_SUBMIT_CMD_BUF:
@@ -103,8 +102,7 @@ static void a5xx_submit_in_rb(struct msm_gpu *gpu, struct 
msm_gem_submit *submit
msm_gpu_retire(gpu);
 }
 
-static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
-   struct msm_file_private *ctx)
+static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
@@ -114,7 +112,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 
if (IS_ENABLED(CONFIG_DRM_MSM_GPU_SUDO) && submit->in_rb) {
priv->lastctx = NULL;
-   a5xx_submit_in_rb(gpu, submit, ctx);
+   a5xx_submit_in_rb(gpu, submit);
return;
}
 
@@ -148,7 +146,7 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
break;
case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
-   if (priv->lastctx == ctx)
+   if (priv->lastctx == submit->queue->ctx)
break;
/* fall-thru */
case MSM_SUBMIT_CMD_BUF:
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c5a3e4d4c007..5eabb0109577 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -81,8 +81,7 @@ static void get_stats_counter(struct msm_ringbuffer *ring, 
u32 counter,
OUT_RING(ring, upper_32_bits(iova));
 }
 
-static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
-   struct msm_file_private *ctx)
+static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit)
 {
unsigned int index = submit->seqno % MSM_GPU_SUBMIT_STATS_COUNT;
struct msm_drm_private *priv = gpu->dev->dev_private;
@@ -115,7 +114,7 @@ static void a6xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
break;
case MSM_SUBMIT_CMD_CTX_RESTORE_BUF:
-   if (priv->lastctx == ctx)
+   if (priv->lastctx == submit->queue->ctx)
break;
/* fall-thru */
case MSM_SUBMIT_CMD_BUF:
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index e23641a5ec84..b38a8126541a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -457,8 +457,7 @@ void adreno_recover(struct msm_gpu *gpu)
}
 }
 
-void adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
-   struct msm_file_private 

[PATCH v10 10/13] drm/msm: Add support to create a local pagetable

2020-07-20 Thread Jordan Crouse
Add support to create a io-pgtable for use by targets that support
per-instance pagetables. In order to support per-instance pagetables the
GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
split pagetables enabled.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/msm_gpummu.c |   2 +-
 drivers/gpu/drm/msm/msm_iommu.c  | 191 ++-
 drivers/gpu/drm/msm/msm_mmu.h|  16 ++-
 3 files changed, 206 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpummu.c b/drivers/gpu/drm/msm/msm_gpummu.c
index 310a31b05faa..aab121f4beb7 100644
--- a/drivers/gpu/drm/msm/msm_gpummu.c
+++ b/drivers/gpu/drm/msm/msm_gpummu.c
@@ -102,7 +102,7 @@ struct msm_mmu *msm_gpummu_new(struct device *dev, struct 
msm_gpu *gpu)
}
 
gpummu->gpu = gpu;
-   msm_mmu_init(>base, dev, );
+   msm_mmu_init(>base, dev, , MSM_MMU_GPUMMU);
 
return >base;
 }
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 1b6635504069..8cf8c7f7a665 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -4,15 +4,202 @@
  * Author: Rob Clark 
  */
 
+#include 
 #include "msm_drv.h"
 #include "msm_mmu.h"
 
 struct msm_iommu {
struct msm_mmu base;
struct iommu_domain *domain;
+   atomic_t pagetables;
 };
+
 #define to_msm_iommu(x) container_of(x, struct msm_iommu, base)
 
+struct msm_iommu_pagetable {
+   struct msm_mmu base;
+   struct msm_mmu *parent;
+   struct io_pgtable_ops *pgtbl_ops;
+   phys_addr_t ttbr;
+   u32 asid;
+};
+static struct msm_iommu_pagetable *to_pagetable(struct msm_mmu *mmu)
+{
+   return container_of(mmu, struct msm_iommu_pagetable, base);
+}
+
+static int msm_iommu_pagetable_unmap(struct msm_mmu *mmu, u64 iova,
+   size_t size)
+{
+   struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
+   struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
+   size_t unmapped = 0;
+
+   /* Unmap the block one page at a time */
+   while (size) {
+   unmapped += ops->unmap(ops, iova, 4096, NULL);
+   iova += 4096;
+   size -= 4096;
+   }
+
+   iommu_flush_tlb_all(to_msm_iommu(pagetable->parent)->domain);
+
+   return (unmapped == size) ? 0 : -EINVAL;
+}
+
+static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 iova,
+   struct sg_table *sgt, size_t len, int prot)
+{
+   struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
+   struct io_pgtable_ops *ops = pagetable->pgtbl_ops;
+   struct scatterlist *sg;
+   size_t mapped = 0;
+   u64 addr = iova;
+   unsigned int i;
+
+   for_each_sg(sgt->sgl, sg, sgt->nents, i) {
+   size_t size = sg->length;
+   phys_addr_t phys = sg_phys(sg);
+
+   /* Map the block one page at a time */
+   while (size) {
+   if (ops->map(ops, addr, phys, 4096, prot)) {
+   msm_iommu_pagetable_unmap(mmu, iova, mapped);
+   return -EINVAL;
+   }
+
+   phys += 4096;
+   addr += 4096;
+   size -= 4096;
+   mapped += 4096;
+   }
+   }
+
+   return 0;
+}
+
+static void msm_iommu_pagetable_destroy(struct msm_mmu *mmu)
+{
+   struct msm_iommu_pagetable *pagetable = to_pagetable(mmu);
+   struct msm_iommu *iommu = to_msm_iommu(pagetable->parent);
+
+   /*
+* If this is the last attached pagetable for the parent,
+* disable TTBR0 in the arm-smmu driver
+*/
+   if (atomic_dec_return(>pagetables) == 0)
+   iommu_domain_set_attr(iommu->domain,
+   DOMAIN_ATTR_PGTABLE_CFG, NULL);
+
+   free_io_pgtable_ops(pagetable->pgtbl_ops);
+   kfree(pagetable);
+}
+
+int msm_iommu_pagetable_params(struct msm_mmu *mmu,
+   phys_addr_t *ttbr, int *asid)
+{
+   struct msm_iommu_pagetable *pagetable;
+
+   if (mmu->type != MSM_MMU_IOMMU_PAGETABLE)
+   return -EINVAL;
+
+   pagetable = to_pagetable(mmu);
+
+   if (ttbr)
+   *ttbr = pagetable->ttbr;
+
+   if (asid)
+   *asid = pagetable->asid;
+
+   return 0;
+}
+
+static const struct msm_mmu_funcs pagetable_funcs = {
+   .map = msm_iommu_pagetable_map,
+   .unmap = msm_iommu_pagetable_unmap,
+   .destroy = msm_iommu_pagetable_destroy,
+};
+
+static void msm_iommu_tlb_flush_all(void *cookie)
+{
+}
+
+static void msm_iommu_tlb_flush_walk(unsigned long iova, size_t size,
+   size_t granule, void *cookie)
+{
+}
+
+static void msm_iommu_tlb_add_page(struct iommu_iotlb_gather *gather,
+   unsigned long iova, size_t granule, void *cookie)
+{
+}
+
+static const struct iommu_flush_ops null_tlb_ops = {
+   .tlb_flush_all = 

[PATCH] drm/mxsfb: improve clk handling for axi clk

2020-07-20 Thread Uwe Kleine-König
Ignoring errors from devm_clk_get() is wrong. To handle not all platforms
having an axi clk use devm_clk_get_optional() instead and do proper error
handling.

Also the clk API handles NULL as a dummy clk (which is also returned by
devm_clk_get_optional() if there is no clk) so there is no need to check
for NULL before calling clk_prepare_enable() or its counter part.

Signed-off-by: Uwe Kleine-König 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index fb972dd4f642..6e185ba74b4b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -77,14 +77,12 @@ drm_pipe_to_mxsfb_drm_private(struct 
drm_simple_display_pipe *pipe)
 
 void mxsfb_enable_axi_clk(struct mxsfb_drm_private *mxsfb)
 {
-   if (mxsfb->clk_axi)
-   clk_prepare_enable(mxsfb->clk_axi);
+   clk_prepare_enable(mxsfb->clk_axi);
 }
 
 void mxsfb_disable_axi_clk(struct mxsfb_drm_private *mxsfb)
 {
-   if (mxsfb->clk_axi)
-   clk_disable_unprepare(mxsfb->clk_axi);
+   clk_disable_unprepare(mxsfb->clk_axi);
 }
 
 static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
@@ -214,9 +212,9 @@ static int mxsfb_load(struct drm_device *drm)
if (IS_ERR(mxsfb->clk))
return PTR_ERR(mxsfb->clk);
 
-   mxsfb->clk_axi = devm_clk_get(drm->dev, "axi");
+   mxsfb->clk_axi = devm_clk_get_optional(drm->dev, "axi");
if (IS_ERR(mxsfb->clk_axi))
-   mxsfb->clk_axi = NULL;
+   return PTR_ERR(mxsfb->clk_axi);
 
mxsfb->clk_disp_axi = devm_clk_get(drm->dev, "disp_axi");
if (IS_ERR(mxsfb->clk_disp_axi))
-- 
2.27.0

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


Re: [Freedreno] [PATCH] drm/msm/dpu: fix/enable 6bpc dither with split-lm

2020-07-20 Thread Rob Clark
On Mon, Jul 20, 2020 at 5:53 AM  wrote:
>
> On 2020-07-16 03:49, Rob Clark wrote:
> > From: Rob Clark 
> >
> > If split-lm is used (for ex, on sdm845), we can have multiple ping-
> > pongs, but only a single phys encoder.  We need to configure dithering
> > on each of them.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 22 ++-
> >  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   |  3 +--
> >  2 files changed, 13 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index 46df0ff75b85..9b98b63c77fb 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -212,14 +212,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
> >   15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
> >  };
> >
> > -static void _dpu_encoder_setup_dither(struct dpu_encoder_phys *phys)
> > +static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp,
> > unsigned bpc)
> >  {
> >   struct dpu_hw_dither_cfg dither_cfg = { 0 };
> >
> > - if (!phys->hw_pp || !phys->hw_pp->ops.setup_dither)
> > + if (!hw_pp->ops.setup_dither)
> >   return;
> >
> > - switch (phys->connector->display_info.bpc) {
> > + switch (bpc) {
> >   case 6:
> >   dither_cfg.c0_bitdepth = 6;
> >   dither_cfg.c1_bitdepth = 6;
> > @@ -228,14 +228,14 @@ static void _dpu_encoder_setup_dither(struct
> > dpu_encoder_phys *phys)
> >   dither_cfg.temporal_en = 0;
> >   break;
> >   default:
> > - phys->hw_pp->ops.setup_dither(phys->hw_pp, NULL);
> > + hw_pp->ops.setup_dither(hw_pp, NULL);
> >   return;
> >   }
> >
> >   memcpy(_cfg.matrix, dither_matrix,
> >   sizeof(u32) * DITHER_MATRIX_SZ);
> >
> > - phys->hw_pp->ops.setup_dither(phys->hw_pp, _cfg);
> > + hw_pp->ops.setup_dither(hw_pp, _cfg);
> >  }
> >
> >  void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys
> > *phys_enc,
> > @@ -1132,11 +1132,13 @@ static void
> > _dpu_encoder_virt_enable_helper(struct drm_encoder *drm_enc)
> >
> >   _dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
> >
> > - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
> > - for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> > - struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> > -
> > - _dpu_encoder_setup_dither(phys);
> > + if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI &&
> > + !WARN_ON(dpu_enc->num_phys_encs == 0)) {
> > + unsigned bpc = 
> > dpu_enc->phys_encs[0]->connector->display_info.bpc;
> > + for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
> > + if (!dpu_enc->hw_pp[i])
> > + continue;
> > + _dpu_encoder_setup_dither(dpu_enc->hw_pp[i], bpc);
> >   }
> >   }
> >  }
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > index 7411ab6bf6af..bea4ab5c58c5 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> > @@ -231,8 +231,7 @@ static void _setup_pingpong_ops(struct
> > dpu_hw_pingpong *c,
> >   c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
> >   c->ops.get_line_count = dpu_hw_pp_get_line_count;
> >
> > - if (test_bit(DPU_PINGPONG_DITHER, ) &&
> > - IS_SC7180_TARGET(c->hw.hwversion))
> > + if (test_bit(DPU_PINGPONG_DITHER, ))
> >   c->ops.setup_dither = dpu_hw_pp_setup_dither;
> >  };
>
> Change looks good to me

Does that count as a Reviewed-by?

BR,
-R

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


[GIT PULL] drm/imx: error path fixes and cleanups

2020-07-20 Thread Philipp Zabel
Hi Dave, Daniel,

The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:

  Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)

are available in the Git repository at:

  git://git.pengutronix.de/pza/linux tags/imx-drm-next-2020-07-20

for you to fetch changes up to 408a85e31e3e5127c91e082c3544082ef1ba48d3:

  drm/imx: imx-tve: Delete an error message in imx_tve_bind() (2020-07-20 
15:16:06 +0200)


drm/imx: error path fixes and cleanups

- Fix use after free issue in component bind error path by keeping
  memory allocated as long as the driver is bound. This will be replaced
  with drm managed memory in the next round.
- Fix bus_flags overriding logic in parallel-display.
- Disable regulator in imx-tve bind error path.
- Drop unnecessary best_encoder callback.
- Remove an unused enum in imx-ldb.
- Bail out early on missing panel or bridge in parallel-display to speed
  up -EPROBE_DEFER path.
- Disable both LDB channels in split mode.
- Restore RGB32, BGR32 format support.
- Fix tiled image conversion in case of out of order interrupts.
- Remove a superfluous error message in imx-tve.


Liu Ying (1):
  drm/imx: imx-ldb: Disable both channels for split mode in enc->disable()

Marco Felsch (4):
  drm/imx: tve: fix regulator_disable error path
  drm/imx: drop useless best_encoder callback
  drm/imx: imx-ldb: remove useless enum
  drm/imx: parallel-display: move panel/bridge detection to fail early

Marek Vasut (1):
  drm/imx: parallel-display: Adjust bus_flags handling

Markus Elfring (1):
  drm/imx: imx-tve: Delete an error message in imx_tve_bind()

Philipp Zabel (1):
  drm/imx: fix use after free

Steve Longerbeam (3):
  gpu: ipu-v3: Restore RGB32, BGR32
  gpu: ipu-v3: image-convert: Combine rotate/no-rotate irq handlers
  gpu: ipu-v3: image-convert: Wait for all EOFs before completing a tile

 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  15 ++--
 drivers/gpu/drm/imx/imx-drm-core.c |   3 +-
 drivers/gpu/drm/imx/imx-ldb.c  |  36 
 drivers/gpu/drm/imx/imx-tve.c  |  48 +--
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  21 +++--
 drivers/gpu/drm/imx/parallel-display.c |  38 -
 drivers/gpu/ipu-v3/ipu-common.c|   2 +
 drivers/gpu/ipu-v3/ipu-image-convert.c | 145 +
 8 files changed, 167 insertions(+), 141 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 0/6] Add support for GPU DDR BW scaling

2020-07-20 Thread Rob Clark
On Mon, Jul 20, 2020 at 3:01 AM Viresh Kumar  wrote:
>
> On 15-07-20, 08:36, Rob Clark wrote:
> > I can take the first two into msm-next, the 3rd will need to wait
> > until dev_pm_opp_set_bw() lands
>
> You can base that on a8351c12c6c7 in linux-next, I will make sure not to 
> rebase
> it anymore.
>

I can't really base on something newer than drm-next

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


[PATCH] drm/v3d: remove second free in v3d_submit_cl_ioctl

2020-07-20 Thread trix
From: Tom Rix 

clang static analysis reports this error

v3d_gem.c:573:4: warning: Attempt to free released
  memory [unix.Malloc]
kfree(bin);
^~

Problem is in the block of code

if (ret) {
kfree(bin);
v3d_job_put(>base);
kfree(bin);
return ret;
}

Obviously bin is freed twice.
So remove one.

Fixes: 0d352a3a8a1f ("drm/v3d: don't leak bin job if v3d_job_init fails.")
Fixes: 29cd13cfd762 ("drm/v3d: Fix memory leak in v3d_submit_cl_ioctl")

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/v3d/v3d_gem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 915f8bfdb58c..3cfbdb8e6a91 100644
--- a/drivers/gpu/drm/v3d/v3d_gem.c
+++ b/drivers/gpu/drm/v3d/v3d_gem.c
@@ -570,7 +570,6 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void *data,
if (ret) {
kfree(bin);
v3d_job_put(>base);
-   kfree(bin);
return ret;
}
 
-- 
2.18.1

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


Re: [PATCH] drm/imx: imx-tve: Delete an error message in imx_tve_bind()

2020-07-20 Thread Philipp Zabel
On Sun, 2020-04-05 at 11:16 +0200, Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sun, 5 Apr 2020 11:01:49 +0200
> 
> The function “platform_get_irq” can log an error already.
> Thus omit a redundant message for the exception handling in the
> calling function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Thank you, applied to imx-drm/next.

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


Re: [PATCH RESEND] drm/imx: imx-ldb: Disable both channels for split mode in enc->disable()

2020-07-20 Thread Philipp Zabel
On Thu, 2020-07-09 at 10:28 +0800, Liu Ying wrote:
> Both of the two LVDS channels should be disabled for split mode
> in the encoder's ->disable() callback, because they are enabled
> in the encoder's ->enable() callback.
> 
> Fixes: 6556f7f82b9c ("drm: imx: Move imx-drm driver out of staging")
> Cc: Philipp Zabel 
> Cc: Sascha Hauer 
> Cc: Pengutronix Kernel Team 
> Cc: NXP Linux Team 
> Cc: 
> Signed-off-by: Liu Ying 

Thank you, applied to imx-drm/next.

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


Re: [PATCH 1/2] drm/imx: fix use after free

2020-07-20 Thread Philipp Zabel
On Thu, 2020-06-11 at 14:43 +0200, Marco Felsch wrote:
> From: Philipp Zabel 
> 
> Component driver structures allocated with devm_kmalloc() in bind() are
> freed automatically after unbind(). Since the contained drm structures
> are accessed afterwards in drm_mode_config_cleanup(), move the
> allocation into probe() to extend the driver structure's lifetime to the
> lifetime of the device. This should eventually be changed to use drm
> resource managed allocations with lifetime of the drm device.
> 
> We also need to ensure that all componets are available during the
> unbind() so we need to call component_unbind_all() before we free
> non-devres resources like planes.
> 
> Note this patch fixes the the use after free bug but introduces a
> possible boot loop issue. The issue is triggered if the HDMI support is
> enabled and a component driver always return -EPROBE_DEFER, see
> discussion [1] for more details.
> 
> [1] https://lkml.org/lkml/2020/3/24/1467
> 
> Fixes: 17b5001b5143 ("imx-drm: convert to componentised device support")
> Signed-off-by: Philipp Zabel 
> [m.felsch@pengutronix: fix imx_tve_probe()]
> [m.felsch@pengutronix: resort component_unbind_all())
> [m.felsch@pengutronix: adapt commit message]
> Signed-off-by: Marco Felsch 

Thank you, applied to imx-drm/next.

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


[PATCH v2] drm: pl111: Update documentation

2020-07-20 Thread Linus Walleij
Remove notes about migrating from the old driver which is
retired as all users are now migrated.

Update the text to reflect that we support PL110 and PL111
alike.

Drop the bullet on memory bandwidth scaling: this has been
implemented.

Cc: Russell King 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Fix up the documentation rst link as well so we don't
  get build failures in the documentation.
---
 Documentation/gpu/pl111.rst   |  8 
 drivers/gpu/drm/pl111/pl111_drv.c | 20 +---
 2 files changed, 9 insertions(+), 19 deletions(-)

diff --git a/Documentation/gpu/pl111.rst b/Documentation/gpu/pl111.rst
index 9b03736d33dd..6d9a1b59a545 100644
--- a/Documentation/gpu/pl111.rst
+++ b/Documentation/gpu/pl111.rst
@@ -1,6 +1,6 @@
-==
- drm/pl111 ARM PrimeCell PL111 CLCD Driver
-==
+
+ drm/pl111 ARM PrimeCell PL110 and PL111 CLCD Driver
+
 
 .. kernel-doc:: drivers/gpu/drm/pl111/pl111_drv.c
-   :doc: ARM PrimeCell PL111 CLCD Driver
+   :doc: ARM PrimeCell PL110 and PL111 CLCD Driver
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 96e58fda75d8..46b0d1c4a16c 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -10,18 +10,11 @@
  */
 
 /**
- * DOC: ARM PrimeCell PL111 CLCD Driver
+ * DOC: ARM PrimeCell PL110 and PL111 CLCD Driver
  *
- * The PL111 is a simple LCD controller that can support TFT and STN
- * displays.  This driver exposes a standard KMS interface for them.
- *
- * This driver uses the same Device Tree binding as the fbdev CLCD
- * driver.  While the fbdev driver supports panels that may be
- * connected to the CLCD internally to the CLCD driver, in DRM the
- * panels get split out to drivers/gpu/drm/panels/.  This means that,
- * in converting from using fbdev to using DRM, you also need to write
- * a panel driver (which may be as simple as an entry in
- * panel-simple.c).
+ * The PL110/PL111 is a simple LCD controller that can support TFT
+ * and STN displays. This driver exposes a standard KMS interface
+ * for them.
  *
  * The driver currently doesn't expose the cursor.  The DRM API for
  * cursors requires support for 64x64 ARGB cursor images, while
@@ -29,16 +22,13 @@
  * cursors.  While one could imagine trying to hack something together
  * to look at the ARGB and program reasonable in monochrome, we
  * just don't expose the cursor at all instead, and leave cursor
- * support to the X11 software cursor layer.
+ * support to the application software cursor layer.
  *
  * TODO:
  *
  * - Fix race between setting plane base address and getting IRQ for
  *   vsync firing the pageflip completion.
  *
- * - Use the "max-memory-bandwidth" DT property to filter the
- *   supported formats.
- *
  * - Read back hardware state at boot to skip reprogramming the
  *   hardware when doing a no-op modeset.
  *
-- 
2.26.2

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


[PATCH] drm/bridge/adv7511: set the bridge type properly

2020-07-20 Thread Laurentiu Palcu
From: Laurentiu Palcu 

After the drm_bridge_connector_init() helper function has been added, the ADV
driver has been changed accordingly. However, the 'type' field of the bridge
structure was left unset, which makes the helper function always return -EINVAL.

Signed-off-by: Laurentiu Palcu 
---
Hi,

I've hit this while trying to use this helper in the new i.MX8MQ DCSS
driver, as suggested by Sam, and I wanted to test it with NWL MIPI_DSI and
ADV since support is already in mainline.

Thanks,
laurentiu


 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index f45cdca9cce5..a0d392c338da 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1283,6 +1283,7 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
adv7511->bridge.ops = DRM_BRIDGE_OP_DETECT | DRM_BRIDGE_OP_EDID
| DRM_BRIDGE_OP_HPD;
adv7511->bridge.of_node = dev->of_node;
+   adv7511->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
 
drm_bridge_add(>bridge);
 
-- 
2.23.0

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


[PATCH] drm/msm/dpu: dev_pm_opp_put_clkname() only when an opp_table exists

2020-07-20 Thread Rajendra Nayak
Its possible that dpu_bind() fails early enough before
dev_pm_opp_set_clkname() is called. In such cases, unconditionally
calling dev_pm_opp_put_clkname() in dpu_unbind() can result in
a crash. Put an additional check so that dev_pm_opp_put_clkname()
is called only when an opp_table exists.

Fixes: aa3950767d05 ("drm/msm/dpu: Use OPP API to set clk/perf state")
Signed-off-by: Rajendra Nayak 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index f2bbce4..843a1c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1079,7 +1079,8 @@ static void dpu_unbind(struct device *dev, struct device 
*master, void *data)
 
if (dpu_kms->has_opp_table)
dev_pm_opp_of_remove_table(dev);
-   dev_pm_opp_put_clkname(dpu_kms->opp_table);
+   if (dpu_kms->opp_table)
+   dev_pm_opp_put_clkname(dpu_kms->opp_table);
 }
 
 static const struct component_ops dpu_ops = {
-- 
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] drm/msm: dsi: dev_pm_opp_put_clkname() only when an opp_table exists

2020-07-20 Thread Rajendra Nayak
Its possible for msm_dsi_host_init() to fail early, before
dev_pm_opp_set_clkname() is called. In such cases, unconditionally
calling dev_pm_opp_put_clkname() in msm_dsi_host_destroy() results
in a crash. Put an additional check so that dev_pm_opp_put_clkname()
is called only when an opp_table exists.

Fixes: f99131fa7a23 ("drm/msm: dsi: Use OPP API to set clk/perf state")
Reported-by: Sai Prakash Ranjan 
Signed-off-by: Rajendra Nayak 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 0a14c4a..4f580f7 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1936,7 +1936,8 @@ void msm_dsi_host_destroy(struct mipi_dsi_host *host)
 
if (msm_host->has_opp_table)
dev_pm_opp_of_remove_table(_host->pdev->dev);
-   dev_pm_opp_put_clkname(msm_host->opp_table);
+   if (msm_host->opp_table)
+   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


Re: [PATCH v6 2/4] drm/imx: Add initial support for DCSS on iMX8MQ

2020-07-20 Thread Laurentiu Palcu
Hi Sam,

On Fri, Jul 17, 2020 at 09:48:49PM +0200, Sam Ravnborg wrote:
> Hi Laurentiu.
> 
> On Fri, Jul 17, 2020 at 05:41:27PM +0300, Laurentiu Palcu wrote:
> > From: Laurentiu Palcu 
> > 
> > This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
> > Some of its capabilities include:
> >  * 4K@60fps;
> >  * HDR10;
> >  * one graphics and 2 video pipelines;
> >  * on-the-fly decompression of compressed video and graphics;
> > 
> > The reference manual can be found here:
> > https://www.nxp.com/webapp/Download?colCode=IMX8MDQLQRM
> > 
> > The current patch adds only basic functionality: one primary plane for
> > graphics, linear, tiled and super-tiled buffers support (no graphics
> > decompression yet), no HDR10 and no video planes.
> > 
> > Video planes support and HDR10 will be added in subsequent patches once
> > per-plane de-gamma/CSC/gamma support is in.
> > 
> > Signed-off-by: Laurentiu Palcu 
> > Reviewed-by: Lucas Stach 
> > ---
> 
> 
> return drm_bridge_attach(encoder, bridge, NULL, 0);
> 
> 
> The above code-snippet tells that the display-driver rely on the bridge
> to create the connector.
> Could this by any chance be updated to the new way where the display
> driver creates the connector - and thus passing DRM_BRIDGE_ATTACH_NO_CONNECTOR
> as the flags argument?

OK, I can give this a shot and the changes will be part of a separate patch
within this patchset, if that's ok with you. No need to go through
and review the entire driver again for this...

Thanks,
laurentiu

> 
> What bridges would be relevant?
> To check that the reelvant bridges are already ported.
> 
>   Sam
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 5/5] drm/i915: Enable async flips in i915

2020-07-20 Thread Karthik B S
Enable asynchronous flips in i915 for gen9+ platforms.

v2: -Async flip enablement should be a stand alone patch (Paulo)

v3: -Move the patch to the end of the serires (Paulo)

v4: -Rebased.

v5: -Rebased.

Signed-off-by: Karthik B S 
Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 562e3173ef83..931b0fe6ee34 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17897,6 +17897,9 @@ static void intel_mode_config_init(struct 
drm_i915_private *i915)
 
mode_config->funcs = _mode_funcs;
 
+   if (INTEL_GEN(i915) >= 9)
+   mode_config->async_page_flip = true;
+
/*
 * Maximum framebuffer dimensions, chosen to match
 * the maximum render engine surface size on gen4+.
-- 
2.22.0

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


[PATCH v5 3/5] drm/i915: Add checks specific to async flips

2020-07-20 Thread Karthik B S
Support added only for async flips on primary plane.
If flip is requested on any other plane, reject it.

Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.

If any of these are modified, reject async flip.

v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)

v3: -Removed TODO as benchmarking tests have been run now.

v4: -Added more state checks for async flip (Ville)
-Moved intel_atomic_check_async to the end of intel_atomic_check
 as the plane checks needs to pass before this. (Ville)
-Removed crtc_state->enable_fbc check. (Ville)
-Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
 flip case as scanline counter is not reliable here.

v5: -Fix typo and other check patch errors seen in CI
 in 'intel_atomic_check_async' function.

Signed-off-by: Karthik B S 
Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/intel_display.c | 104 +++
 1 file changed, 104 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 4773f39e5924..562e3173ef83 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14835,6 +14835,102 @@ static bool intel_cpu_transcoders_need_modeset(struct 
intel_atomic_state *state,
return false;
 }
 
+static int intel_atomic_check_async(struct intel_atomic_state *state)
+{
+   struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+   struct intel_plane_state *new_plane_state, *old_plane_state;
+   struct intel_crtc *crtc;
+   struct intel_plane *intel_plane;
+   int i, n_planes = 0;
+
+   for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+   new_crtc_state, i) {
+   if (needs_modeset(new_crtc_state)) {
+   DRM_DEBUG_KMS("Modeset Required. Async flip not 
supported\n");
+   return -EINVAL;
+   }
+
+   if (!new_crtc_state->uapi.active) {
+   DRM_DEBUG_KMS("CRTC inactive\n");
+   return -EINVAL;
+   }
+   if (old_crtc_state->active_planes != 
new_crtc_state->active_planes) {
+   DRM_DEBUG_KMS("Active planes cannot be changed during 
async flip\n");
+   return -EINVAL;
+   }
+   }
+
+   for_each_oldnew_intel_plane_in_state(state, intel_plane, 
old_plane_state,
+new_plane_state, i) {
+   /*TODO: Async flip is only supported through the page flip IOCTL
+* as of now. So support currently added for primary plane only.
+* Support for other planes should be added when async flip is
+* enabled in the atomic IOCTL path.
+*/
+   if (intel_plane->id != PLANE_PRIMARY)
+   return -EINVAL;
+
+   if (old_plane_state->color_plane[0].x !=
+   new_plane_state->color_plane[0].x ||
+   old_plane_state->color_plane[0].y !=
+   new_plane_state->color_plane[0].y) {
+   DRM_DEBUG_KMS("Offsets cannot be changed in async 
flip\n");
+   return -EINVAL;
+   }
+
+   if (old_plane_state->uapi.fb->modifier !=
+   new_plane_state->uapi.fb->modifier) {
+   DRM_DEBUG_KMS("Framebuffer modifiers cannot be changed 
in async flip\n");
+   return -EINVAL;
+   }
+
+   if (old_plane_state->uapi.fb->format !=
+   new_plane_state->uapi.fb->format) {
+   DRM_DEBUG_KMS("Framebuffer format cannot be changed in 
async flip\n");
+   return -EINVAL;
+   }
+
+   if (intel_wm_need_update(old_plane_state, new_plane_state)) {
+   DRM_DEBUG_KMS("WM update not allowed in async flip\n");
+   return -EINVAL;
+   }
+
+   if (old_plane_state->uapi.alpha != new_plane_state->uapi.alpha) 
{
+   DRM_DEBUG_KMS("Alpha value cannot be changed in async 
flip\n");
+   return -EINVAL;
+   }
+
+   if (old_plane_state->uapi.pixel_blend_mode !=
+   new_plane_state->uapi.pixel_blend_mode) {
+   DRM_DEBUG_KMS("Pixel blend mode cannot be changed in 
async flip\n");
+   return -EINVAL;
+   }
+
+   if (old_plane_state->uapi.color_encoding != 
new_plane_state->uapi.color_encoding) {
+   DRM_DEBUG_KMS("Color encoding cannot be changed in 
async flip\n");
+   return -EINVAL;
+   }
+
+   if 

[PATCH v5 2/5] drm/i915: Add support for async flips in I915

2020-07-20 Thread Karthik B S
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.

v2: -Move the Async flip enablement to individual patch (Paulo)

v3: -Rebased.

v4: -Add separate plane hook for async flip case (Ville)

v5: -Rebased.

Signed-off-by: Karthik B S 
Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/intel_display.c |  6 +
 drivers/gpu/drm/i915/display/intel_sprite.c  | 25 
 drivers/gpu/drm/i915/i915_reg.h  |  1 +
 3 files changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index b8ff032195d9..4773f39e5924 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4766,6 +4766,12 @@ u32 skl_plane_ctl(const struct intel_crtc_state 
*crtc_state,
const struct drm_intel_sprite_colorkey *key = _state->ckey;
u32 plane_ctl;
 
+   /* During Async flip, no other updates are allowed */
+   if (crtc_state->uapi.async_flip) {
+   plane_ctl |= PLANE_CTL_ASYNC_FLIP;
+   return plane_ctl;
+   }
+
plane_ctl = PLANE_CTL_ENABLE;
 
if (INTEL_GEN(dev_priv) < 10 && !IS_GEMINILAKE(dev_priv)) {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index c26ca029fc0a..3747482e8fa3 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -603,6 +603,24 @@ icl_program_input_csc(struct intel_plane *plane,
  PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
 }
 
+static void
+skl_program_async_surface_address(struct drm_i915_private *dev_priv,
+ const struct intel_plane_state *plane_state,
+ enum pipe pipe, enum plane_id plane_id,
+ u32 surf_addr)
+{
+   unsigned long irqflags;
+   u32 plane_ctl = plane_state->ctl;
+
+   spin_lock_irqsave(_priv->uncore.lock, irqflags);
+
+   intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
+   intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ intel_plane_ggtt_offset(plane_state) + surf_addr);
+
+   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
+}
+
 static void
 skl_program_plane(struct intel_plane *plane,
  const struct intel_crtc_state *crtc_state,
@@ -631,6 +649,13 @@ skl_program_plane(struct intel_plane *plane,
u32 keymsk, keymax;
u32 plane_ctl = plane_state->ctl;
 
+   /* During Async flip, no other updates are allowed */
+   if (crtc_state->uapi.async_flip) {
+   skl_program_async_surface_address(dev_priv, plane_state,
+ pipe, plane_id, surf_addr);
+   return;
+   }
+
plane_ctl |= skl_plane_ctl_crtc(crtc_state);
 
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8cee06314d5d..19aad4199874 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6935,6 +6935,7 @@ enum {
 #define   PLANE_CTL_TILED_X(1 << 10)
 #define   PLANE_CTL_TILED_Y(4 << 10)
 #define   PLANE_CTL_TILED_YF   (5 << 10)
+#define   PLANE_CTL_ASYNC_FLIP (1 << 9)
 #define   PLANE_CTL_FLIP_HORIZONTAL(1 << 8)
 #define   PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
 #define   PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
-- 
2.22.0

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


[PATCH v5 4/5] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips

2020-07-20 Thread Karthik B S
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.

v2: -Moved the async check above vblank_get as it
 was causing issues for PSR.

v3: -No need to wait for vblank to pass, as this wait was causing a
 16ms delay once every few flips.

v4: -Rebased.

v5: -Rebased.

Signed-off-by: Karthik B S 
Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/intel_sprite.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c 
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 3747482e8fa3..1c03546a4d2a 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -93,6 +93,9 @@ void intel_pipe_update_start(const struct intel_crtc_state 
*new_crtc_state)
DEFINE_WAIT(wait);
u32 psr_status;
 
+   if (new_crtc_state->uapi.async_flip)
+   goto irq_disable;
+
vblank_start = adjusted_mode->crtc_vblank_start;
if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
vblank_start = DIV_ROUND_UP(vblank_start, 2);
@@ -206,7 +209,7 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
 * Would be slightly nice to just grab the vblank count and arm the
 * event outside of the critical section - the spinlock might spin for a
 * while ... */
-   if (new_crtc_state->uapi.event) {
+   if (new_crtc_state->uapi.event && !new_crtc_state->uapi.async_flip) {
drm_WARN_ON(_priv->drm,
drm_crtc_vblank_get(>base) != 0);
 
@@ -220,6 +223,9 @@ void intel_pipe_update_end(struct intel_crtc_state 
*new_crtc_state)
 
local_irq_enable();
 
+   if (new_crtc_state->uapi.async_flip)
+   return;
+
if (intel_vgpu_active(dev_priv))
return;
 
-- 
2.22.0

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


[PATCH v5 1/5] drm/i915: Add enable/disable flip done and flip done handler

2020-07-20 Thread Karthik B S
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.

Enable the flip done interrupt in IER.

Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt

Flip done handler is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
The interrupt is disabled after the event is sent.

v2: -Change function name from icl_* to skl_* (Paulo)
-Move flip handler to this patch (Paulo)
-Remove vblank_put() (Paulo)
-Enable flip done interrupt for gen9+ only (Paulo)
-Enable flip done interrupt in power_well_post_enable hook (Paulo)
-Removed the event check in flip done handler to handle async
 flips without pageflip events.

v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
-Make the pending vblank event NULL in the beginning of
 flip_done_handler to remove sporadic WARN_ON that is seen.

v4: -Calculate timestamps using flip done time stamp and current
 timestamp for async flips (Ville)

v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
 static.(Reported-by: kernel test robot )
-Fix the typo in commit message.

Signed-off-by: Karthik B S 
Signed-off-by: Vandita Kulkarni 
---
 drivers/gpu/drm/i915/display/intel_display.c | 10 +++
 drivers/gpu/drm/i915/i915_irq.c  | 83 ++--
 drivers/gpu/drm/i915/i915_irq.h  |  2 +
 drivers/gpu/drm/i915/i915_reg.h  |  4 +-
 4 files changed, 91 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index db2a5a1a9b35..b8ff032195d9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15562,6 +15562,13 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
 
intel_dbuf_pre_plane_update(state);
 
+   for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+   if (new_crtc_state->uapi.async_flip) {
+   skl_enable_flip_done(>base);
+   break;
+   }
+   }
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
 
@@ -15583,6 +15590,9 @@ static void intel_atomic_commit_tail(struct 
intel_atomic_state *state)
drm_atomic_helper_wait_for_flip_done(dev, >base);
 
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+   if (new_crtc_state->uapi.async_flip)
+   skl_disable_flip_done(>base);
+
if (new_crtc_state->hw.active &&
!needs_modeset(new_crtc_state) &&
!new_crtc_state->preload_luts &&
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1fa67700d8f4..95953b393941 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -697,14 +697,24 @@ u32 i915_get_vblank_counter(struct drm_crtc *crtc)
return (((high1 << 8) | low) + (pixel >= vbl_start)) & 0xff;
 }
 
+static u32 g4x_get_flip_counter(struct drm_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+   enum pipe pipe = to_intel_crtc(crtc)->pipe;
+
+   return I915_READ(PIPE_FLIPCOUNT_G4X(pipe));
+}
+
 u32 g4x_get_vblank_counter(struct drm_crtc *crtc)
 {
struct drm_i915_private *dev_priv = to_i915(crtc->dev);
enum pipe pipe = to_intel_crtc(crtc)->pipe;
 
+   if (crtc->state->async_flip)
+   return g4x_get_flip_counter(crtc);
+
return I915_READ(PIPE_FRMCOUNT_G4X(pipe));
 }
-
 /*
  * On certain encoders on certain platforms, pipe
  * scanline register will not work to get the scanline,
@@ -737,17 +747,24 @@ static u32 
__intel_get_crtc_scanline_from_timestamp(struct intel_crtc *crtc)
 * pipe frame time stamp. The time stamp value
 * is sampled at every start of vertical blank.
 */
-   scan_prev_time = intel_de_read_fw(dev_priv,
- PIPE_FRMTMSTMP(crtc->pipe));
-
+   if (!crtc->config->uapi.async_flip)
+   scan_prev_time = intel_de_read_fw(dev_priv,
+ 
PIPE_FRMTMSTMP(crtc->pipe));
+   else
+   scan_prev_time = intel_de_read_fw(dev_priv,
+ 
PIPE_FLIPTMSTMP(crtc->pipe));
/*
 * The TIMESTAMP_CTR register has the current
 * time stamp value.
 */
scan_curr_time = intel_de_read_fw(dev_priv, IVB_TIMESTAMP_CTR);
 
-   scan_post_time = intel_de_read_fw(dev_priv,
-   

[PATCH v5 0/5] Asynchronous flip implementation for i915

2020-07-20 Thread Karthik B S
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.

Asynchronous page flips will also boost the FPS of Mesa benchmarks.

v2: -Few patches have been squashed and patches have been shuffled as
 per the reviews on the previous version.

v3: -Few patches have been squashed and patches have been shuffled as
 per the reviews on the previous version.

v4: -Made changes to fix the sequence and time stamp issue as per the
 comments received on the previous version.
-Timestamps are calculated using the flip done time stamp and current
 timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used
 for timestamp calculations.
-Event is sent from the interrupt handler immediately using this
 updated timestamps and sequence.
-Added more state checks as async flip should only allow change in plane
 surface address and nothing else should be allowed to change.
-Added a separate plane hook for async flip.
-Need to find a way to reject fbc enabling if it comes as part of this
 flip as bspec states that changes to FBC are not allowed.

v5: -Fixed the Checkpatch and sparse warnings.

Karthik B S (5):
  drm/i915: Add enable/disable flip done and flip done handler
  drm/i915: Add support for async flips in I915
  drm/i915: Add checks specific to async flips
  drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
  drm/i915: Enable async flips in i915

 drivers/gpu/drm/i915/display/intel_display.c | 123 +++
 drivers/gpu/drm/i915/display/intel_sprite.c  |  33 -
 drivers/gpu/drm/i915/i915_irq.c  |  83 +++--
 drivers/gpu/drm/i915/i915_irq.h  |   2 +
 drivers/gpu/drm/i915/i915_reg.h  |   5 +-
 5 files changed, 237 insertions(+), 9 deletions(-)

-- 
2.22.0

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


[PATCH] drm: fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi

2020-07-20 Thread Xin Xiong
drm_dp_mst_allocate_vcpi() invokes
drm_dp_mst_topology_get_port_validated(), which increases the refcount
of the "port".

These reference counting issues take place in two exception handling
paths separately. Either when “slots” is less than 0 or when
drm_dp_init_vcpi() returns a negative value, the function forgets to
reduce the refcnt increased drm_dp_mst_topology_get_port_validated(),
which results in a refcount leak.

Fix these issues by pulling up the error handling when "slots" is less
than 0, and calling drm_dp_mst_topology_put_port() before termination
when drm_dp_init_vcpi() returns a negative value.

Signed-off-by: Xiyu Yang 
Signed-off-by: Xin Tan 
Signed-off-by: Xin Xiong 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1e26b89628f9..97b48b531ec6 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4261,11 +4261,11 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 {
int ret;
 
-   port = drm_dp_mst_topology_get_port_validated(mgr, port);
-   if (!port)
+   if (slots < 0)
return false;
 
-   if (slots < 0)
+   port = drm_dp_mst_topology_get_port_validated(mgr, port);
+   if (!port)
return false;
 
if (port->vcpi.vcpi > 0) {
@@ -4281,6 +4281,7 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
if (ret) {
DRM_DEBUG_KMS("failed to init vcpi slots=%d max=63 ret=%d\n",
  DIV_ROUND_UP(pbn, mgr->pbn_div), ret);
+   drm_dp_mst_topology_put_port(port);
goto out;
}
DRM_DEBUG_KMS("initing vcpi for pbn=%d slots=%d\n",
-- 
2.25.1

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


Re: [Linaro-mm-sig] [PATCH 1/2] dma-buf.rst: Document why indefinite fences are a bad idea

2020-07-20 Thread Intel

Hi,

On 7/9/20 2:33 PM, Daniel Vetter wrote:

Comes up every few years, gets somewhat tedious to discuss, let's
write this down once and for all.

What I'm not sure about is whether the text should be more explicit in
flat out mandating the amdkfd eviction fences for long running compute
workloads or workloads where userspace fencing is allowed.


Although (in my humble opinion) it might be possible to completely 
untangle kernel-introduced fences for resource management and dma-fences 
used for completion- and dependency tracking and lift a lot of 
restrictions for the dma-fences, including prohibiting infinite ones, I 
think this makes sense describing the current state.


Reviewed-by: Thomas Hellstrom 


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


Re: [PATCH 1/8] drm/ttm: remove TTM_MEMTYPE_FLAG_CMA

2020-07-20 Thread Christian König

Am 16.07.20 um 15:05 schrieb Thomas Zimmermann:

Hi,

this patchset could have benefited from a cover letter.


Yeah, I didn't thought it would result in such an extensive patch set.


Am 16.07.20 um 14:50 schrieb Christian König:

The original intention was to avoid CPU page table unmaps
when BOs move between the GTT and SYSTEM domain.

The problem is that this never correctly handled changes
in the caching attributes or backing pages.

Just drop this for now and simply unmap the CPU page
tables in all cases.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  4 +--
  drivers/gpu/drm/nouveau/nouveau_bo.c   |  3 +-
  drivers/gpu/drm/radeon/radeon_ttm.c|  2 +-
  drivers/gpu/drm/ttm/ttm_bo.c   | 34 --
  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c |  2 +-
  include/drm/ttm/ttm_bo_driver.h|  1 -
  6 files changed, 11 insertions(+), 35 deletions(-)

Why's CMA cleaned up in one patch and MAPPABLE in the other 7?


There is a chance that the CMA removal fixes some bugs and needs to be 
back-ported. But the other 7 are pure cleanup.



Wouldn't it have been better to kill both the flags from ttm in 2
patches, then have one patch per driver and finally remove both flags
from the ttm header?


That's what I did initially. Basically I found that the 
TTM_MEMTYPE_FLAG_CMA flag might be the root of some problems because of 
the problematic implementation.


While removing it I've found that the TTM_MEMTYPE_FLAG_MAPPABLE is 
completely unused in TTM as well, so I removed both at the same time.


But that turned out to break drivers because they use the 
TTM_MEMTYPE_FLAG_MAPPABLE flag for no good reason at all :)


Anyway, I want to keep the order now since it might be a good idea to 
back port the CMA flag removal (but I'm not 100% sure of that).


Thanks,
Christian.



Best regards
Thomas


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 9c0f12f74af9..44fa8bc49d18 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -93,7 +93,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man->func = _gtt_mgr_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
+   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
break;
case TTM_PL_VRAM:
/* "On-card" video ram */
@@ -108,7 +108,7 @@ static int amdgpu_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
case AMDGPU_PL_OA:
/* On-chip GDS memory*/
man->func = _bo_manager_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED | TTM_MEMTYPE_FLAG_CMA;
+   man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED;
man->default_caching = TTM_PL_FLAG_UNCACHED;
break;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a1037478fa3f..7883341f8c83 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -695,8 +695,7 @@ nouveau_bo_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
} else {
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE |
-TTM_MEMTYPE_FLAG_CMA;
+   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
}
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 73085523fad7..54af06df865b 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man->func = _bo_manager_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE | TTM_MEMTYPE_FLAG_CMA;
+   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
  #if IS_ENABLED(CONFIG_AGP)
if (rdev->flags & RADEON_IS_AGP) {
if (!rdev->ddev->agp) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 8b9e7f62bea7..0768a054a916 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -272,20 +272,15 @@ static int ttm_bo_handle_move_mem(struct 
ttm_buffer_object *bo,
  struct ttm_operation_ctx *ctx)
  {
struct ttm_bo_device *bdev = 

Re: [PATCH 2/8] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE

2020-07-20 Thread Christian König

Am 19.07.20 um 14:57 schrieb Chauhan, Madhav:

[AMD Public Use]

-Original Message-
From: Christian König 
Sent: Thursday, July 16, 2020 6:21 PM
To: dri-devel@lists.freedesktop.org
Cc: Chauhan, Madhav 
Subject: [PATCH 2/8] drm/radeon: stop using TTM_MEMTYPE_FLAG_MAPPABLE

The driver doesn't expose any not-mapable memory resources.

Looks like spell mistake in "mapable". Please check.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/radeon/radeon_ttm.c | 13 -
  1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 54af06df865b..b474781a0920 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -76,7 +76,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
switch (type) {
case TTM_PL_SYSTEM:
/* System memory */
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = 0;

adev memory was set to zero while allocated and adev->mman.bdev used to fetch 
different mman.
Do we need explicit initialization to '0'??


No, not really. But I wasn't sure if other drivers initialize their 
structures as well.


So I just kept it to be uniform across drivers to completely rework 
mem_type init at some point.


Regards,
Christian.



Regards,
Madhav

man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
break;
@@ -84,7 +84,7 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
man->func = _bo_manager_func;
man->available_caching = TTM_PL_MASK_CACHING;
man->default_caching = TTM_PL_FLAG_CACHED;
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = 0;
  #if IS_ENABLED(CONFIG_AGP)
if (rdev->flags & RADEON_IS_AGP) {
if (!rdev->ddev->agp) {
@@ -92,8 +92,6 @@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, 
uint32_t type,
  (unsigned)type);
return -EINVAL;
}
-   if (!rdev->ddev->agp->cant_use_aperture)
-   man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
man->available_caching = TTM_PL_FLAG_UNCACHED |
 TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC; @@ -103,8 +101,7 
@@ static int radeon_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
case TTM_PL_VRAM:
/* "On-card" video ram */
man->func = _bo_manager_func;
-   man->flags = TTM_MEMTYPE_FLAG_FIXED |
-TTM_MEMTYPE_FLAG_MAPPABLE;
+   man->flags = TTM_MEMTYPE_FLAG_FIXED;
man->available_caching = TTM_PL_FLAG_UNCACHED | TTM_PL_FLAG_WC;
man->default_caching = TTM_PL_FLAG_WC;
break;
@@ -394,7 +391,6 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
  
  static int radeon_ttm_io_mem_reserve(struct ttm_bo_device *bdev, struct ttm_mem_reg *mem)  {

-   struct ttm_mem_type_manager *man = >man[mem->mem_type];
struct radeon_device *rdev = radeon_get_rdev(bdev);
  
  	mem->bus.addr = NULL;

@@ -402,8 +398,7 @@ static int radeon_ttm_io_mem_reserve(struct ttm_bo_device 
*bdev, struct ttm_mem_
mem->bus.size = mem->num_pages << PAGE_SHIFT;
mem->bus.base = 0;
mem->bus.is_iomem = false;
-   if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE))
-   return -EINVAL;
+
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
/* system memory */
--
2.17.1


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


Re: [PATCH v5 0/19] backlight: backlight updates

2020-07-20 Thread Sam Ravnborg
Hi Lee.

On Mon, Jul 20, 2020 at 10:36:01AM +0100, Lee Jones wrote:
> On Sun, 19 Jul 2020, Sam Ravnborg wrote:
> 
> > Hi all.
> > 
> > Follow-up on v4 - with only a few changes listed below and
> > in the individual patches.
> > Thanks for all the reviews and the feedback on the patches!
> > 
> > I am planning a follow-up on this patchset to update the
> > backlight drivers all over to use backlight_get_brightness()
> > and backlight_is_blank() as appropriate.
> 
> [...]
> 
> > Sam Ravnborg (19):
> >   backlight: refactor fb_notifier_callback()
> >   backlight: add backlight_is_blank()
> >   backlight: improve backlight_ops documentation
> >   backlight: improve backlight_properties documentation
> >   backlight: improve backlight_device documentation
> >   backlight: document inline functions in backlight.h
> >   backlight: document enums in backlight.h
> >   backlight: remove the unused backlight_bl driver
> >   backlight: drop extern from prototypes
> >   backlight: add overview and update existing doc
> >   backlight: wire up kernel-doc documentation
> >   backlight: introduce backlight_get_brightness()
> >   backlight: as3711_bl: simplify update_status
> >   backlight: cr_bllcd: introduce gpio-backlight semantics
> >   backlight: gpio_backlight: simplify update_status()
> >   backlight: jornada720_bl: introduce backlight_is_blank()
> >   backlight: use backlight_get_brightness()
> >   backlight: drop backlight_put()
> >   backlight: make of_find_backlight static
> 
> All applied, but to be honest, that was quite painful.
That was not the intention :-(

> 
> A few notes for subsequent patches.
> 
>  - Enable spell-checkers in your editors
>- I fixed the issues up for you here - there were quite a few!
>  - Run ./checkpatch.pl before submitting - here's what I find useful
>* .git/hooks/post-commit: https://pastebin.ubuntu.com/p/WpPFd6M2rB/
>  - Please keep the in-patch changelog below the '---' line, so that it
>does not end up in the final commit log
>  - Cc: lines *above* the *-bys please
>  - Cc: lines dropped for any *-bys provided
>  - Lines wrapped ~72 chars (not 50)
>  - One whole empty line spacing between paragraphs
>  - Ensure you use the formatting expected of the subsystem - in the
>case of Backlight it's:
> 
>  : : Subject beginning with an upper-case char
> 
>A `git log --oneline -- subsystem` would give you a good idea of
>what's expected.

Thanks for the input - I will use these points as guideline for the next
batch of backlight patches.

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


Re: [PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops

2020-07-20 Thread Karol Herbst
On Mon, Jul 20, 2020 at 3:19 AM Alex Hung  wrote:
>
> On 2020-07-19 1:50 p.m., Karol Herbst wrote:
> > On Fri, Jul 17, 2020 at 9:52 PM Alex Hung  wrote:
> >>
> >> On 2020-07-17 1:05 p.m., Karol Herbst wrote:
> >>> It's hard to figure out what systems are actually affected and right now I
> >>> don't see a good way of removing those...
> >>>
> >>> But I'd like to see thos getting removed and drivers fixed instead (which
> >>> happened at least for nouveau).
> >>>
> >>> And as mentioned before, I prefer people working on fixing issues instead
> >>> of spending time to add firmware level workarounds which are hard to know
> >>> to which systems they apply to, hard to remove and basically a big huge
> >>> pain to work with.> In the end I have no idea how to even figure out what 
> >>> systems are affected
> >>> and which not by this, so I have no idea how to even verify we can safely
> >>> remove this (which just means those are impossible to remove unless we 
> >>> risk
> >>> breaking systems, which again makes those supper annoying to deal with).
> >>>
> >>> Also from the comments it's hard to get what those bits really do. Are 
> >>> they
> >>> just preventing runtime pm or do the devices are powered down when 
> >>> booting?
> >>> I am sure it's the former, still...
> >>>
> >>> Please, don't do this again.
> >>>
> >>> For now, those workaround prevent power savings on systems those 
> >>> workaround
> >>> applies to, which might be any so those should get removed asap and if
> >>> new issues arrise removing those please do a proper bug report and we can
> >>> look into it and come up with a proper fix (and keep this patch out until
> >>> we resolve all of those).
> >>>
> >>> Signed-off-by: Karol Herbst 
> >>> CC: Alex Hung 
> >>> CC: "Rafael J. Wysocki" 
> >>> CC: Len Brown 
> >>> CC: Lyude Paul 
> >>> CC: linux-ker...@vger.kernel.org
> >>> CC: dri-devel@lists.freedesktop.org
> >>> CC: nouv...@lists.freedesktop.org
> >>> ---
> >>>  drivers/acpi/osi.c | 24 
> >>>  1 file changed, 24 deletions(-)
> >>>
> >>> diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
> >>> index 9f68538091384..d4405e1ca9b97 100644
> >>> --- a/drivers/acpi/osi.c
> >>> +++ b/drivers/acpi/osi.c
> >>> @@ -44,30 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = 
> >>> {
> >>>   {"Processor Device", true},
> >>>   {"3.0 _SCP Extensions", true},
> >>>   {"Processor Aggregator Device", true},
> >>> - /*
> >>> -  * Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia 
> >>> graphics
> >>> -  * cards as RTD3 is not supported by drivers now.  Systems with 
> >>> NVidia
> >>> -  * cards will hang without RTD3 disabled.
> >>> -  *
> >>> -  * Once NVidia drivers officially support RTD3, this _OSI strings 
> >>> can
> >>> -  * be removed if both new and old graphics cards are supported.
> >>> -  */
> >>> - {"Linux-Dell-Video", true},
> >>> - /*
> >>> -  * Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's 
> >>> HDMI
> >>> -  * audio device which is turned off for power-saving in Windows OS.
> >>> -  * This power management feature observed on some Lenovo Thinkpad
> >>> -  * systems which will not be able to output audio via HDMI without
> >>> -  * a BIOS workaround.
> >>> -  */
> >>> - {"Linux-Lenovo-NV-HDMI-Audio", true},
> >>> - /*
> >>> -  * Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to
> >>> -  * output video directly to external monitors on HP Inc. mobile
> >>> -  * workstations as Nvidia and AMD VGA drivers provide limited
> >>> -  * hybrid graphics supports.
> >>> -  */
> >>> - {"Linux-HPI-Hybrid-Graphics", true},
> >>>  };
> >>>
> >>>  static u32 acpi_osi_handler(acpi_string interface, u32 supported)
> >>>
> >>
> >> The changes were discussed and tested a while ago, and no crashes were
> >> observed. Thanks for solving PM issues in nouveau.
> >>
> >> Acked-by: Alex Hung 
> >>
> >
> > By any chance, do you have a list of systems implementing those workarounds?
> >
>
> I don't keep a list but the workaround, in theory, should only apply to
> the systems with the specific nvidia hardware.
>
> I reminded OEMs and ODMs that these _OSI strings were temporary
> solutions, and highlighted we were going to remove them after our
> discussion last year. If they were paying attentions recent systems
> shouldn't have these _OSI strings.
>

Right.. but I am actually wondering because I never saw those strings
in the wild or not on the Dell and Lenovo systems I was testing on. So
I think we might want to ask the vendors themselves and verify on
those systems.

> --
> Cheers,
> Alex Hung
>

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


Re: [PATCH] drm/mxsfb: Make supported modifiers explicit

2020-07-20 Thread Guido Günther
Hi,
On Mon, Jul 20, 2020 at 11:03:04AM +0200, Stefan Agner wrote:
> On 2020-07-18 19:14, Guido Günther wrote:
> > Hi,
> > On Mon, Mar 23, 2020 at 04:51:05PM +0100, Lucas Stach wrote:
> >> Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
> >> > In contrast to other display controllers on imx like DCSS and ipuv3
> >> > lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
> >> > Since mesa might assume otherwise make it explicit that only
> >> > DRM_FORMAT_MOD_LINEAR is supported.
> >> >
> >> > Signed-off-by: Guido Günther 
> >>
> >> Reviewed-by: Lucas Stach 
> > 
> > Can i do anything to get this applied?
> > Cheers,
> >  -- Guido
> 
> Sorry about the delay, I was thinking to apply it with another patchset
> which is not ready though.
> 
> Pushed this patch to drm-misc-next just now.

Thanks!
 -- Guido

> 
> --
> Stefan
> 
> > 
> >>
> >> > ---
> >> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 9 +++--
> >> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
> >> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > index 762379530928..fc71e7a7a02e 100644
> >> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> >> > @@ -73,6 +73,11 @@ static const uint32_t mxsfb_formats[] = {
> >> >  DRM_FORMAT_RGB565
> >> >  };
> >> >
> >> > +static const uint64_t mxsfb_modifiers[] = {
> >> > +DRM_FORMAT_MOD_LINEAR,
> >> > +DRM_FORMAT_MOD_INVALID
> >> > +};
> >> > +
> >> >  static struct mxsfb_drm_private *
> >> >  drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
> >> >  {
> >> > @@ -334,8 +339,8 @@ static int mxsfb_load(struct drm_device *drm, 
> >> > unsigned long flags)
> >> >  }
> >> >
> >> >  ret = drm_simple_display_pipe_init(drm, >pipe, 
> >> > _funcs,
> >> > -mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL,
> >> > -mxsfb->connector);
> >> > +mxsfb_formats, ARRAY_SIZE(mxsfb_formats),
> >> > +mxsfb_modifiers, mxsfb->connector);
> >> >  if (ret < 0) {
> >> >  dev_err(drm->dev, "Cannot setup simple display pipe\n");
> >> >  goto err_vblank;
> >>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: SM750 : from which driver should I start to add a new transmitter ?

2020-07-20 Thread Sudip Mukherjee
HI Gilles, (Added fbdev and dri list)

On Mon, Jul 20, 2020 at 10:18 AM Gilles Buloz  wrote:
>
> Dear developers,
>
>
> My company is manufacturing M2 graphics modules based on SM750. and I need to 
> add support for an ANX9404 transmitter (for DP). I'm wondering which driver 
> you would recommend to start my development :
>
> - your SM750 framebuffer driver is available in the kernel under 
> drivers/staging/sm750fb/. It is clean and maintained.

Yes, and I know many companies who are using SM750 uses this driver,
but the fact remains that it can be removed from staging any time as
it can never migrate out of staging,

>
> - I'm currently using another driver from SiliconMotion I got through 
> Innodisk (another modules manufacturer) supporting SM750/SM768 and labelled 
> "SiliconMotion GPU DRM Driver". But the code is not very clean and produces 
> lots of warning when building, and seems no more maintained. I even don't 
> have the name nor the email of the developer. However it already works fine 
> with our current HDMI transmitter.
>
>
> Having a look to the sm750fb kernel driver, the TODO file says : "must be 
> ported to the atomic kms framework in the drm subsystem (which will give you 
> a basic fbdev driver for free)".

Yes.

>
> It seems my current driver is already of this kind (DRM driver using 
> modesetting Xorg module). I can send you the source code of this driver as it 
> is open source If you want to see which driver I mean.

Is it the same as the one I have at gitlab
(https://gitlab.com/sudipm/sm750/tree/sm750) ? If it is same then it
will not be accepted in drm subsystem as it needs to be cleaned and I
will need to add "atomic" to it. Well, atomic was the main blocker.
But, if the driver that you have has been already converted to be an
atomic driver then please send it to me and I can clean it up and
submit.



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


Re: [PATCH v5 0/19] backlight: backlight updates

2020-07-20 Thread Lee Jones
On Sun, 19 Jul 2020, Sam Ravnborg wrote:

> Hi all.
> 
> Follow-up on v4 - with only a few changes listed below and
> in the individual patches.
> Thanks for all the reviews and the feedback on the patches!
> 
> I am planning a follow-up on this patchset to update the
> backlight drivers all over to use backlight_get_brightness()
> and backlight_is_blank() as appropriate.

[...]

> Sam Ravnborg (19):
>   backlight: refactor fb_notifier_callback()
>   backlight: add backlight_is_blank()
>   backlight: improve backlight_ops documentation
>   backlight: improve backlight_properties documentation
>   backlight: improve backlight_device documentation
>   backlight: document inline functions in backlight.h
>   backlight: document enums in backlight.h
>   backlight: remove the unused backlight_bl driver
>   backlight: drop extern from prototypes
>   backlight: add overview and update existing doc
>   backlight: wire up kernel-doc documentation
>   backlight: introduce backlight_get_brightness()
>   backlight: as3711_bl: simplify update_status
>   backlight: cr_bllcd: introduce gpio-backlight semantics
>   backlight: gpio_backlight: simplify update_status()
>   backlight: jornada720_bl: introduce backlight_is_blank()
>   backlight: use backlight_get_brightness()
>   backlight: drop backlight_put()
>   backlight: make of_find_backlight static

All applied, but to be honest, that was quite painful.

A few notes for subsequent patches.

 - Enable spell-checkers in your editors
   - I fixed the issues up for you here - there were quite a few!
 - Run ./checkpatch.pl before submitting - here's what I find useful
   * .git/hooks/post-commit: https://pastebin.ubuntu.com/p/WpPFd6M2rB/
 - Please keep the in-patch changelog below the '---' line, so that it
   does not end up in the final commit log
 - Cc: lines *above* the *-bys please
 - Cc: lines dropped for any *-bys provided
 - Lines wrapped ~72 chars (not 50)
 - One whole empty line spacing between paragraphs
 - Ensure you use the formatting expected of the subsystem - in the
   case of Backlight it's:

 : : Subject beginning with an upper-case char

   A `git log --oneline -- subsystem` would give you a good idea of
   what's expected.

-- 
lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 14/19] backlight: cr_bllcd: introduce gpio-backlight semantics

2020-07-20 Thread Sam Ravnborg
On Mon, Jul 20, 2020 at 09:48:22AM +0100, Daniel Thompson wrote:
> On Sun, Jul 19, 2020 at 10:07:38AM +0200, Sam Ravnborg wrote:
> > cr_bllcd can turn backlight ON or OFF.
> > Fix semantitics so they equals what we know from gpio-backlight.
> > brightness == 0   => backlight off
> > brightness == 1   => backlight on
> > 
> > Use the backlight_get_brightness() helper to simplify the code.
> > 
> > v2:
> >   - reworked to introduce gpio-backlight semantics (Daniel)
> 
> Wasn't this added for v5? However, I spotted this change amoung the
> other patches so no worries...

I do not increment version for individual patches unless there are
changes. So this is the second version of this patch, but included in the
v5 submission.
But I can see how this can confuse the receiver.
I will consider to adapt to the practice to indicate version of submission
and not the individual patches.


> 
> 
> > Signed-off-by: Sam Ravnborg 
> > Cc: Lee Jones 
> > Cc: Daniel Thompson 
> > Cc: Jingoo Han 
> 
> Reviewed-by: Daniel Thompson 
Very much appreciated - thanks!

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


Re: [PATCH] drm/mxsfb: drop unused function parameter

2020-07-20 Thread Stefan Agner
On 2020-07-16 19:41, Uwe Kleine-König wrote:
> flags is unused since the driver was introduced in commit 45d59d704080
> ("drm: Add new driver for MXSFB controller").

Applied to drm-misc-next. Thanks.

--
Stefan

> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 497cf443a9af..fb972dd4f642 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -191,7 +191,7 @@ static struct drm_simple_display_pipe_funcs mxsfb_funcs = 
> {
>   .disable_vblank = mxsfb_pipe_disable_vblank,
>  };
>  
> -static int mxsfb_load(struct drm_device *drm, unsigned long flags)
> +static int mxsfb_load(struct drm_device *drm)
>  {
>   struct platform_device *pdev = to_platform_device(drm->dev);
>   struct mxsfb_drm_private *mxsfb;
> @@ -407,7 +407,7 @@ static int mxsfb_probe(struct platform_device *pdev)
>   if (IS_ERR(drm))
>   return PTR_ERR(drm);
>  
> - ret = mxsfb_load(drm, 0);
> + ret = mxsfb_load(drm);
>   if (ret)
>   goto err_free;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/mxsfb: Make supported modifiers explicit

2020-07-20 Thread Stefan Agner
On 2020-07-18 19:14, Guido Günther wrote:
> Hi,
> On Mon, Mar 23, 2020 at 04:51:05PM +0100, Lucas Stach wrote:
>> Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
>> > In contrast to other display controllers on imx like DCSS and ipuv3
>> > lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
>> > Since mesa might assume otherwise make it explicit that only
>> > DRM_FORMAT_MOD_LINEAR is supported.
>> >
>> > Signed-off-by: Guido Günther 
>>
>> Reviewed-by: Lucas Stach 
> 
> Can i do anything to get this applied?
> Cheers,
>  -- Guido

Sorry about the delay, I was thinking to apply it with another patchset
which is not ready though.

Pushed this patch to drm-misc-next just now.

--
Stefan

> 
>>
>> > ---
>> >  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 9 +++--
>> >  1 file changed, 7 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
>> > b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > index 762379530928..fc71e7a7a02e 100644
>> > --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
>> > @@ -73,6 +73,11 @@ static const uint32_t mxsfb_formats[] = {
>> >DRM_FORMAT_RGB565
>> >  };
>> >
>> > +static const uint64_t mxsfb_modifiers[] = {
>> > +  DRM_FORMAT_MOD_LINEAR,
>> > +  DRM_FORMAT_MOD_INVALID
>> > +};
>> > +
>> >  static struct mxsfb_drm_private *
>> >  drm_pipe_to_mxsfb_drm_private(struct drm_simple_display_pipe *pipe)
>> >  {
>> > @@ -334,8 +339,8 @@ static int mxsfb_load(struct drm_device *drm, unsigned 
>> > long flags)
>> >}
>> >
>> >ret = drm_simple_display_pipe_init(drm, >pipe, _funcs,
>> > -  mxsfb_formats, ARRAY_SIZE(mxsfb_formats), NULL,
>> > -  mxsfb->connector);
>> > +  mxsfb_formats, ARRAY_SIZE(mxsfb_formats),
>> > +  mxsfb_modifiers, mxsfb->connector);
>> >if (ret < 0) {
>> >dev_err(drm->dev, "Cannot setup simple display pipe\n");
>> >goto err_vblank;
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/mxsfb: miss err handle in probe

2020-07-20 Thread Stefan Agner
On 2020-06-11 14:23, Bernard Zhao wrote:
> There are three err return values in drm_fbdev_generic_setup.
> In mxsfb_probe we called this function, but didn`t handle the
> return value, this change is to add err handle, maybe make code
> a bit more readable.

This got recently changed, so I guess checking the return value isn't
required anymore:
https://patchwork.freedesktop.org/patch/msgid/20200408082641.590-11-tzimmerm...@suse.de

--
Stefan

> 
> Signed-off-by: Bernard Zhao 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 497cf443a9af..a45f3b85f725 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -415,7 +415,9 @@ static int mxsfb_probe(struct platform_device *pdev)
>   if (ret)
>   goto err_unload;
>  
> - drm_fbdev_generic_setup(drm, 32);
> + ret = drm_fbdev_generic_setup(drm, 32);
> + if (ret)
> + goto err_unload;
>  
>   return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 14/19] backlight: cr_bllcd: introduce gpio-backlight semantics

2020-07-20 Thread Daniel Thompson
On Sun, Jul 19, 2020 at 10:07:38AM +0200, Sam Ravnborg wrote:
> cr_bllcd can turn backlight ON or OFF.
> Fix semantitics so they equals what we know from gpio-backlight.
> brightness == 0   => backlight off
> brightness == 1   => backlight on
> 
> Use the backlight_get_brightness() helper to simplify the code.
> 
> v2:
>   - reworked to introduce gpio-backlight semantics (Daniel)

Wasn't this added for v5? However, I spotted this change amoung the
other patches so no worries...


> Signed-off-by: Sam Ravnborg 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 

Reviewed-by: Daniel Thompson 


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


Re: [bug report] drm/ingenic: Add support for the IPU

2020-07-20 Thread Daniel Vetter
On Mon, Jul 20, 2020 at 10:22:37AM +0300, dan.carpen...@oracle.com wrote:
> Hello Paul Cercueil,
> 
> The patch fc1acf317b01: "drm/ingenic: Add support for the IPU" from
> Jul 16, 2020, leads to the following static checker warning:
> 
>   drivers/gpu/drm/ingenic/ingenic-drm-drv.c:232 
> ingenic_drm_crtc_atomic_check()
>   error: potentially dereferencing uninitialized 'ipu_state'.
> 
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>197  static int ingenic_drm_crtc_atomic_check(struct drm_crtc *crtc,
>198   struct drm_crtc_state *state)
>199  {
>200  struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
>201  struct drm_plane_state *f1_state, *f0_state, *ipu_state;
>202  long rate;
>203  
>204  if (!drm_atomic_crtc_needs_modeset(state))
>205  return 0;
>206  
>207  if (state->mode.hdisplay > priv->soc_info->max_width ||
>208  state->mode.vdisplay > priv->soc_info->max_height)
>209  return -EINVAL;

Random entirely unrelated drive-through comment: These mode checks should
be in crtc_helper_funcs->mode_valid so that they're shared between the
atomic_check and output probe paths.

But preexisting issues, just something that would be nice to rectify.

Cheers, Daniel

>210  
>211  rate = clk_round_rate(priv->pix_clk,
>212state->adjusted_mode.clock * 1000);
>213  if (rate < 0)
>214  return rate;
>215  
>216  if (priv->soc_info->has_osd) {
>217  f1_state = drm_atomic_get_plane_state(state->state, 
> >f1);
>218  f0_state = drm_atomic_get_plane_state(state->state, 
> >f0);
>219  
>220  if (IS_ENABLED(CONFIG_DRM_INGENIC_IPU) && 
> priv->ipu_plane) {
> 
> Do we need to check both the CONFIG and the priv->ipu_plane or would it
> be sufficient to just check if (priv->ipu_plane) {?
> 
>221  ipu_state = 
> drm_atomic_get_plane_state(state->state, priv->ipu_plane);
>222  
>223  /* IPU and F1 planes cannot be enabled at the 
> same time. */
>224  if (f1_state->fb && ipu_state->fb) {
>225  dev_dbg(priv->dev, "Cannot enable 
> both F1 and IPU\n");
>226  return -EINVAL;
>227  }
>228  }
>229  
>230  /* If all the planes are disabled, we won't get a 
> VBLANK IRQ */
>231  priv->no_vblank = !f1_state->fb && !f0_state->fb &&
>232!(priv->ipu_plane && ipu_state->fb);
> ^^^
> Because here we're only checking "priv->ipu_plane".
> 
>233  }
>234  
>235  return 0;
>236  }
> 
> regards,
> dan carpenter
> ___
> 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 for v5.9] video: fbdev: Replace HTTP links with HTTPS ones

2020-07-20 Thread Daniel Vetter
On Sun, Jul 19, 2020 at 10:37:14PM +0200, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

Merged this and the drm patch from yours, thanks.

I tried also applying the drm/bridge one for dt files, but that doesn't
apply cleanly to drm-misc-next so no idea.
-Daniel

> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely
>  or at least not (just) HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  Documentation/fb/ep93xx-fb.rst| 2 +-
>  drivers/video/fbdev/Kconfig   | 8 
>  drivers/video/fbdev/core/fbmon.c  | 4 ++--
>  drivers/video/fbdev/ep93xx-fb.c   | 2 +-
>  drivers/video/fbdev/grvga.c   | 2 +-
>  drivers/video/fbdev/macfb.c   | 2 +-
>  drivers/video/fbdev/metronomefb.c | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/Kconfig  | 4 ++--
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi.h   | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c  | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h | 2 +-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h | 2 +-
>  drivers/video/fbdev/sa1100fb.c| 2 +-
>  14 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/fb/ep93xx-fb.rst b/Documentation/fb/ep93xx-fb.rst
> index 6f7767926d1a..1dd67f4688c7 100644
> --- a/Documentation/fb/ep93xx-fb.rst
> +++ b/Documentation/fb/ep93xx-fb.rst
> @@ -127,7 +127,7 @@ At least on the EP9315 there is a silicon bug which 
> causes bit 27 of
>  the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is
>  an unofficial errata for this bug at::
>  
> - http://marc.info/?l=linux-arm-kernel=110061245502000=2
> + https://marc.info/?l=linux-arm-kernel=110061245502000=2
>  
>  By default the EP93xx framebuffer driver checks if the allocated physical
>  address has bit 27 set. If it does, then the memory is freed and an
> diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> index 0f559aeaf469..f12e390941b8 100644
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -844,7 +844,7 @@ config FB_OPENCORES
> systems (e.g. Altera socfpga or Xilinx Zynq) on FPGAs.
>  
> The source code and specification for the core is available at
> -   
> +   
>  
>  config FB_S1D13XXX
>   tristate "Epson S1D13XXX framebuffer support"
> @@ -855,7 +855,7 @@ config FB_S1D13XXX
>   help
> Support for S1D13XXX framebuffer device family (currently only
> working with S1D13806). Product specs at
> -   
> +   
>  
>  config FB_ATMEL
>   tristate "AT91 LCD Controller support"
> @@ -1213,7 +1213,7 @@ config FB_RADEON
> don't need to choose this to run the Radeon in plain VGA mode.
>  
> There is a product page at
> -   http://products.amd.com/en-us/GraphicCardResult.aspx
> +   https://products.amd.com/en-us/GraphicCardResult.aspx
>  
>  config FB_RADEON_I2C
>   bool "DDC/I2C for ATI Radeon support"
> @@ -1381,7 +1381,7 @@ config FB_SIS
>   help
> This is the frame buffer device driver for the SiS 300, 315, 330
> and 340 series as well as XGI V3XT, V5, V8, Z7 graphics chipsets.
> -   Specs available at  and .
> +   Specs available at  and .
>  
> To compile this driver as a module, choose M here; the module
> will be called sisfb.
> diff --git a/drivers/video/fbdev/core/fbmon.c 
> 

Re: [PATCH v2] drm: core: Convert device logging to drm_* functions.

2020-07-20 Thread Daniel Vetter
On Sat, Jul 18, 2020 at 08:39:55PM +0530, Suraj Upadhyay wrote:
> Convert device logging with dev_* functions into drm_* functions.
> 
> The patch has been generated with the coccinelle script below.
> The script focuses on instances of dev_* functions where the drm device
> context is clearly visible in its arguments.
> 
> @@expression E1; expression list E2; @@
> -dev_warn(E1->dev, E2)
> +drm_warn(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_info(E1->dev, E2)
> +drm_info(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_err(E1->dev, E2)
> +drm_err(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_info_once(E1->dev, E2)
> +drm_info_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_notice_once(E1->dev, E2)
> +drm_notice_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_warn_once(E1->dev, E2)
> +drm_warn_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_err_once(E1->dev, E2)
> +drm_err_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_err_ratelimited(E1->dev, E2)
> +drm_err_ratelimited(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_dbg(E1->dev, E2)
> +drm_dbg(E1, E2)
> 
> Signed-off-by: Suraj Upadhyay 
> ---
> Changes:
>   v2: Fixed error in coccinelle script and diff,
>   i.e. removed the underscore.
>   drv_dbg_ -> drm_dbg

Applied to drm-misc-next, thanks for your patch. Will probably go to 5.10
because drm is already in feature freeze.
-Daniel

> 
>  drivers/gpu/drm/drm_edid.c   | 6 ++
>  drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
>  drivers/gpu/drm/drm_mipi_dbi.c   | 7 +++
>  3 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 52b357e75c3d..6840f0530a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1844,9 +1844,7 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
>   return;
>  
> - dev_warn(connector->dev->dev,
> -  "%s: EDID is invalid:\n",
> -  connector->name);
> + drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name);
>   for (i = 0; i < num_blocks; i++) {
>   u8 *block = edid + i * EDID_LENGTH;
>   char prefix[20];
> @@ -5298,7 +5296,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
> struct edid *edid)
>   }
>   if (!drm_edid_is_valid(edid)) {
>   clear_eld(connector);
> - dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
> + drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
>   return 0;
>   }
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 06a5b9ee1fe0..822edeadbab3 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -105,8 +105,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
> drm_device *drm,
>   cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
> GFP_KERNEL | __GFP_NOWARN);
>   if (!cma_obj->vaddr) {
> - dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
> - size);
> + drm_dbg(drm, "failed to allocate buffer with size %zu\n",
> +  size);
>   ret = -ENOMEM;
>   goto error;
>   }
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 0e55d8716e3d..a7a611894243 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -225,9 +225,8 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
> *fb,
>   drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
>   break;
>   default:
> - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> -  drm_get_format_name(fb->format->format,
> -  _name));
> + drm_err_once(fb->dev, "Format is not supported: %s\n",
> +  drm_get_format_name(fb->format->format, 
> _name));
>   return -EINVAL;
>   }
>  
> @@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
> struct drm_rect *rect)
>  width * height * 2);
>  err_msg:
>   if (ret)
> - dev_err_once(fb->dev->dev, "Failed to update display %d\n", 
> ret);
> + drm_err_once(fb->dev, "Failed to update display %d\n", ret);
>  
>   drm_dev_exit(idx);
>  }
> -- 
> 2.17.1
> 



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

Re: [PATCH v2 0/6] drm/ast: Managed MM

2020-07-20 Thread Thomas Zimmermann


Am 16.07.20 um 15:24 schrieb Sam Ravnborg:
> Hi Thomas.
> 
> On Thu, Jul 16, 2020 at 02:53:47PM +0200, Thomas Zimmermann wrote:
>> This is the second patchset for converting ast to managed DRM interfaces.
>> This one addresses memory management. There will be another, final round
>> of patches for converting DRM device structures as well.
>>
>> Patch #1 introduces managed initialization for VRAM MM. Other drivers
>> using the VRAM helpers should be converted to this at some point.
>>
>> Patches #2 to #4 do some preparation that make ast look slightly nicer.
>>
>> Patch #5 fixes a long-standing bug that I found as part of the rework.
>> Posting the GPU requires information about the installed DRAM. So the DRAM
>> detection has to run before the GPU-posting code. This got reversed by a
>> fix in v4.11. The patch restores the original correct order of these
>> operations. As the GPU is usually posted by the VGA BIOS, the problem might
>> not have shown up in practice.
>>
>> With all the cleanups in place, patch #6 switches memory management to
>> mnaged interfaces.
>>
>> Tested on AST2100 HW.
>>
>> v2:
>>  * reworked managed VRAM MM; new interface name, returns errno
>>code, improved documentation (Sam)
>>
>> Thomas Zimmermann (6):
>>   drm/vram-helper: Managed vram helpers
>>   drm/ast: Rename ast_ttm.c to ast_mm.c
>>   drm/ast: Use managed VRAM-helper initialization
>>   drm/ast: Move VRAM size detection to ast_mm.c
>>   drm/ast: Initialize DRAM type before posting GPU
>>   drm/ast: Use managed MM initialization
> 
> Series looks good now. All patches are:
> Reviewed-by: Sam Ravnborg 

Thanks, Sam. I added the patches to drm-misc-next

> 
> 
>   Sam
>>
>>  drivers/gpu/drm/ast/Makefile|  2 +-
>>  drivers/gpu/drm/ast/ast_drv.h   |  2 -
>>  drivers/gpu/drm/ast/ast_main.c  | 45 ++-
>>  drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} | 77 ++-
>>  drivers/gpu/drm/drm_gem_vram_helper.c   | 84 -
>>  include/drm/drm_gem_vram_helper.h   |  3 +
>>  6 files changed, 115 insertions(+), 98 deletions(-)
>>  rename drivers/gpu/drm/ast/{ast_ttm.c => ast_mm.c} (63%)
>>
>> --
>> 2.27.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 -next] drm/komeda: Convert to DEFINE_SHOW_ATTRIBUTE

2020-07-20 Thread miaoqinglang



在 2020/7/17 15:06, Daniel Vetter 写道:

On Fri, Jul 17, 2020 at 8:40 AM james qian wang (Arm Technology China)
 wrote:


On Thu, Jul 16, 2020 at 05:03:33PM +0800, Qinglang Miao wrote:

From: Liu Shixin 

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Liu Shixin 
---
  drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 0246b2e94..4a10e6b9e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -41,18 +41,7 @@ static int komeda_register_show(struct seq_file *sf, void *x)
   return 0;
  }

-static int komeda_register_open(struct inode *inode, struct file *filp)
-{
- return single_open(filp, komeda_register_show, inode->i_private);
-}
-
-static const struct file_operations komeda_register_fops = {
- .owner  = THIS_MODULE,
- .open   = komeda_register_open,
- .read_iter  = seq_read_iter,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(komeda_register);



Hi Shixin & Qinglang

Thanks for your patch.

Reviewed-by: James Qian Wang 

Since your patch is not for drm-misc-next, so seems better
to leave it to you to merge it. :)


I do think it's for drm-misc-next, what other tree would it be for?
Some people put -next in their patch tag to differentiate from -fixes,
so maintainers know what to do with the patch. It's also not part of a
series, hence I think this is on you to apply it.

>
Hi James & Daniel,

​Sorry I didn't make it clear in commit log, but it do based on linux-next.

​I think the reason why James think it's not for drm-misc-next
is conflicts exists when this patch being applied. There's conflicts 
because commit <4d4901c6d7> which switched over direct seq_read method 
calls to seq_read_iter should applied before this clean-up patch(linkage 
listed as below).


https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next/+/4d4901c6d748efab8aab6e7d2405dadaed0bea50

I can send a new patch based on mainline if needed.

​Thanks.

Qinglang

.

>

Cheers, Daniel



Thanks
James


  #ifdef CONFIG_DEBUG_FS
  static void komeda_debugfs_init(struct komeda_dev *mdev)
--
2.17.1

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






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


[PATCH 2/4] dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02

2020-07-20 Thread Icenowy Zheng
Feixin K101-IM2BYL02 is a drop-in replacement of K101-IM2BA02 panel
(which is already supported by panel-feixin-k101-im2ba02 driver) with
the same pinout. It utilizes an Ilitek ILI9881C controller chip, so its
compatible string should be added to ilitek,ili9881c file.

Add the compatible string for it.

Signed-off-by: Icenowy Zheng 
---
 .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml 
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
index a39332276bab2..c60b3bd74337e 100644
--- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml
@@ -14,6 +14,7 @@ properties:
 items:
   - enum:
 - bananapi,lhr050h41
+- feixin,k101-im2byl02
 
   - const: ilitek,ili9881c
 
-- 
2.27.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/ingenic: Silence uninitialized-variable warning

2020-07-20 Thread Paul Cercueil

Hi Sam,

Le dim. 19 juil. 2020 à 12:23, Sam Ravnborg  a 
écrit :

Hi Paul.

On Sun, Jul 19, 2020 at 11:38:34AM +0200, Paul Cercueil wrote:

 Silence compiler warning about used but uninitialized 'ipu_state'
 variable. In practice, the variable would never be used when
 uninitialized, but the compiler cannot know that 'priv->ipu_plane' 
will

 always be NULL if CONFIG_INGENIC_IPU is disabled.

 Silence the warning by initializing the value to NULL.

 Signed-off-by: Paul Cercueil 

Patch looks good. Had to dig into the code to understand the
change to the no_vblank flag.
So:
Reviewed-by: Sam Ravnborg 

I expect you to commit the patch.


Pushed, thanks.


Looking at the code I noticed that the return value of
drm_atomic_get_plane_state() is not checked.
Can you try to look into this.


Right. I'll fix it.

-Paul


Sam


 ---
  drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c

 index b6d946fbeaf5..ada990a7f911 100644
 --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
 +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
 @@ -198,7 +198,7 @@ static int ingenic_drm_crtc_atomic_check(struct 
drm_crtc *crtc,

 struct drm_crtc_state *state)
  {
struct ingenic_drm *priv = drm_crtc_get_priv(crtc);
 -  struct drm_plane_state *f1_state, *f0_state, *ipu_state;
 +  struct drm_plane_state *f1_state, *f0_state, *ipu_state = NULL;
long rate;

if (!drm_atomic_crtc_needs_modeset(state))
 @@ -229,7 +229,7 @@ static int ingenic_drm_crtc_atomic_check(struct 
drm_crtc *crtc,


/* If all the planes are disabled, we won't get a VBLANK IRQ */
priv->no_vblank = !f1_state->fb && !f0_state->fb &&
 -!(priv->ipu_plane && ipu_state->fb);
 +!(ipu_state && ipu_state->fb);
}

return 0;
 --
 2.27.0



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


[PATCH for v5.9] drm/tilcdc: Replace HTTP links with HTTPS ones

2020-07-20 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely
 or at least not (just) HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index aac617acb64f..8b2a71395647 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -46,7 +46,7 @@ Optional nodes:
 crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is
 for Blue[3-7]. For more details see section 3.1.1 in AM335x
 Silicon Errata:
-
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
+
https://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
 
 Example:
 
-- 
2.27.0

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


[PATCH] drm/i810: switch from 'pci_' to 'dma_' API

2020-07-20 Thread Christophe JAILLET
The wrappers in include/linux/pci-dma-compat.h should go away.

The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.

When memory is allocated in 'i810_dma_initialize()' GFP_KERNEL can be used
because its only caller, 'i810_dma_init()', already use it and no lock is
taken in the between.


@@
@@
-PCI_DMA_BIDIRECTIONAL
+DMA_BIDIRECTIONAL

@@
@@
-PCI_DMA_TODEVICE
+DMA_TO_DEVICE

@@
@@
-PCI_DMA_FROMDEVICE
+DMA_FROM_DEVICE

@@
@@
-PCI_DMA_NONE
+DMA_NONE

@@
expression e1, e2, e3;
@@
-pci_alloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)

@@
expression e1, e2, e3;
@@
-pci_zalloc_consistent(e1, e2, e3)
+dma_alloc_coherent(>dev, e2, e3, GFP_)

@@
expression e1, e2, e3, e4;
@@
-pci_free_consistent(e1, e2, e3, e4)
+dma_free_coherent(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_map_single(e1, e2, e3, e4)
+dma_map_single(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_single(e1, e2, e3, e4)
+dma_unmap_single(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4, e5;
@@
-pci_map_page(e1, e2, e3, e4, e5)
+dma_map_page(>dev, e2, e3, e4, e5)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_page(e1, e2, e3, e4)
+dma_unmap_page(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_map_sg(e1, e2, e3, e4)
+dma_map_sg(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_unmap_sg(e1, e2, e3, e4)
+dma_unmap_sg(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_cpu(e1, e2, e3, e4)
+dma_sync_single_for_cpu(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_single_for_device(e1, e2, e3, e4)
+dma_sync_single_for_device(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_cpu(e1, e2, e3, e4)
+dma_sync_sg_for_cpu(>dev, e2, e3, e4)

@@
expression e1, e2, e3, e4;
@@
-pci_dma_sync_sg_for_device(e1, e2, e3, e4)
+dma_sync_sg_for_device(>dev, e2, e3, e4)

@@
expression e1, e2;
@@
-pci_dma_mapping_error(e1, e2)
+dma_mapping_error(>dev, e2)

@@
expression e1, e2;
@@
-pci_set_dma_mask(e1, e2)
+dma_set_mask(>dev, e2)

@@
expression e1, e2;
@@
-pci_set_consistent_dma_mask(e1, e2)
+dma_set_coherent_mask(>dev, e2)

Signed-off-by: Christophe JAILLET 
---
If needed, see post from Christoph Hellwig on the kernel-janitors ML:
   https://marc.info/?l=kernel-janitors=158745678307186=4
---
 drivers/gpu/drm/i810/i810_dma.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i810/i810_dma.c b/drivers/gpu/drm/i810/i810_dma.c
index b88c3d5f92b4..303c2d483c6e 100644
--- a/drivers/gpu/drm/i810/i810_dma.c
+++ b/drivers/gpu/drm/i810/i810_dma.c
@@ -220,9 +220,9 @@ static int i810_dma_cleanup(struct drm_device *dev)
if (dev_priv->ring.virtual_start)
drm_legacy_ioremapfree(_priv->ring.map, dev);
if (dev_priv->hw_status_page) {
-   pci_free_consistent(dev->pdev, PAGE_SIZE,
-   dev_priv->hw_status_page,
-   dev_priv->dma_status_page);
+   dma_free_coherent(>pdev->dev, PAGE_SIZE,
+ dev_priv->hw_status_page,
+ dev_priv->dma_status_page);
}
kfree(dev->dev_private);
dev->dev_private = NULL;
@@ -398,8 +398,8 @@ static int i810_dma_initialize(struct drm_device *dev,
 
/* Program Hardware Status Page */
dev_priv->hw_status_page =
-   pci_zalloc_consistent(dev->pdev, PAGE_SIZE,
- _priv->dma_status_page);
+   dma_alloc_coherent(>pdev->dev, PAGE_SIZE,
+  _priv->dma_status_page, GFP_KERNEL);
if (!dev_priv->hw_status_page) {
dev->dev_private = (void *)dev_priv;
i810_dma_cleanup(dev);
-- 
2.25.1

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


[PATCH 1/4] drm/panel: ilitek-ili9881c: prepare for adding support for extra panels

2020-07-20 Thread Icenowy Zheng
There're more panels with ILI9881C controller than the Bananapi one
supported by this driver.

Extract the mode and init sequence part, to prepare the driver for
adding new panels.

Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 56 ---
 1 file changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 3ed8635a6fbdf..4f8e6865029f1 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -20,14 +21,6 @@
 
 #include 
 
-struct ili9881c {
-   struct drm_panelpanel;
-   struct mipi_dsi_device  *dsi;
-
-   struct regulator*power;
-   struct gpio_desc*reset;
-};
-
 enum ili9881c_op {
ILI9881C_SWITCH_PAGE,
ILI9881C_COMMAND,
@@ -45,6 +38,21 @@ struct ili9881c_instr {
} arg;
 };
 
+struct ili9881c_desc {
+   const struct ili9881c_instr *init;
+   const size_t init_length;
+   const struct drm_display_mode *mode;
+};
+
+struct ili9881c {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+   const struct ili9881c_desc  *desc;
+
+   struct regulator*power;
+   struct gpio_desc*reset;
+};
+
 #define ILI9881C_SWITCH_PAGE_INSTR(_page)  \
{   \
.op = ILI9881C_SWITCH_PAGE, \
@@ -64,7 +72,7 @@ struct ili9881c_instr {
},  \
}
 
-static const struct ili9881c_instr ili9881c_init[] = {
+static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_SWITCH_PAGE_INSTR(3),
ILI9881C_COMMAND_INSTR(0x01, 0x00),
ILI9881C_COMMAND_INSTR(0x02, 0x00),
@@ -311,8 +319,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
gpiod_set_value(ctx->reset, 0);
msleep(20);
 
-   for (i = 0; i < ARRAY_SIZE(ili9881c_init); i++) {
-   const struct ili9881c_instr *instr = _init[i];
+   for (i = 0; i < ctx->desc->init_length; i++) {
+   const struct ili9881c_instr *instr = >desc->init[i];
 
if (instr->op == ILI9881C_SWITCH_PAGE)
ret = ili9881c_switch_page(ctx, instr->arg.page);
@@ -368,7 +376,7 @@ static int ili9881c_unprepare(struct drm_panel *panel)
return 0;
 }
 
-static const struct drm_display_mode bananapi_default_mode = {
+static const struct drm_display_mode lhr050h41_default_mode = {
.clock  = 62000,
 
.hdisplay   = 720,
@@ -380,6 +388,9 @@ static const struct drm_display_mode bananapi_default_mode 
= {
.vsync_start= 1280 + 10,
.vsync_end  = 1280 + 10 + 10,
.vtotal = 1280 + 10 + 10 + 20,
+
+   .width_mm   = 62,
+   .height_mm  = 110,
 };
 
 static int ili9881c_get_modes(struct drm_panel *panel,
@@ -388,12 +399,12 @@ static int ili9881c_get_modes(struct drm_panel *panel,
struct ili9881c *ctx = panel_to_ili9881c(panel);
struct drm_display_mode *mode;
 
-   mode = drm_mode_duplicate(connector->dev, _default_mode);
+   mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
if (!mode) {
dev_err(>dsi->dev, "failed to add mode %ux%ux@%u\n",
-   bananapi_default_mode.hdisplay,
-   bananapi_default_mode.vdisplay,
-   drm_mode_vrefresh(_default_mode));
+   ctx->desc->mode->hdisplay,
+   ctx->desc->mode->vdisplay,
+   drm_mode_vrefresh(ctx->desc->mode));
return -ENOMEM;
}
 
@@ -402,8 +413,8 @@ static int ili9881c_get_modes(struct drm_panel *panel,
mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
 
-   connector->display_info.width_mm = 62;
-   connector->display_info.height_mm = 110;
+   connector->display_info.width_mm = mode->width_mm;
+   connector->display_info.height_mm = mode->height_mm;
 
return 1;
 }
@@ -426,6 +437,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dsi = dsi;
+   ctx->desc = of_device_get_match_data(>dev);
 
drm_panel_init(>panel, >dev, _funcs,
   DRM_MODE_CONNECTOR_DSI);
@@ -467,8 +479,14 @@ static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
return 0;
 }
 
+static const struct ili9881c_desc lhr050h41_desc = {
+   .init = lhr050h41_init,
+   .init_length = ARRAY_SIZE(lhr050h41_init),
+   .mode = _default_mode,
+};
+
 static const struct of_device_id ili9881c_of_match[] = {
-   { .compatible = "bananapi,lhr050h41" },
+   { .compatible 

[PATCH 0/5] drm: rockchip: various ports for older VOPs

2020-07-20 Thread Alex Bee
This series mainly ports existining functionality to older SoCs - most
importantly enables alpha blending for RK3036, RK3066, RK3126 and
RK3188.
Besides that, it also changes the window type from DRM_PLANE_TYPE_CURSOR
to DRM_PLANE_TYPE_OVERLAY for VOPs that have only one overlay window.

Alex Bee (5):
  drm: rockchip: add scaling for RK3036 win1
  drm: rockchip: add missing registers for RK3188
  drm: rockchip: add alpha support for RK3036, RK3066, RK3126 and RK3188
  drm: rockchip: set alpha_en to 0 if it is not used
  drm: rockchip: use overlay windows as such

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 43 ++---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.h |  1 +
 3 files changed, 39 insertions(+), 6 deletions(-)

-- 
2.17.1

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


[PATCH for v5.9] ARM: dts: mxs: Replace HTTP links with HTTPS ones

2020-07-20 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely
 or at least not (just) HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 arch/arm/boot/dts/imx23-pinfunc.h | 4 ++--
 arch/arm/boot/dts/imx28-pinfunc.h | 4 ++--
 arch/arm/boot/dts/imx53-tx53-x13x.dts | 4 ++--
 arch/arm/boot/dts/mxs-pinfunc.h   | 4 ++--
 include/video/imx-ipu-v3.h| 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm/boot/dts/imx23-pinfunc.h 
b/arch/arm/boot/dts/imx23-pinfunc.h
index 5c0f32ca3a93..f9d7eb6679de 100644
--- a/arch/arm/boot/dts/imx23-pinfunc.h
+++ b/arch/arm/boot/dts/imx23-pinfunc.h
@@ -7,8 +7,8 @@
  * License. You may obtain a copy of the GNU General Public License
  * Version 2 at the following locations:
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ * https://www.opensource.org/licenses/gpl-license.html
+ * https://www.gnu.org/copyleft/gpl.html
  */
 
 #ifndef __DT_BINDINGS_MX23_PINCTRL_H__
diff --git a/arch/arm/boot/dts/imx28-pinfunc.h 
b/arch/arm/boot/dts/imx28-pinfunc.h
index e11f69ba0fe4..ffd5412b70ae 100644
--- a/arch/arm/boot/dts/imx28-pinfunc.h
+++ b/arch/arm/boot/dts/imx28-pinfunc.h
@@ -7,8 +7,8 @@
  * License. You may obtain a copy of the GNU General Public License
  * Version 2 at the following locations:
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ * https://www.opensource.org/licenses/gpl-license.html
+ * https://www.gnu.org/copyleft/gpl.html
  */
 
 #ifndef __DT_BINDINGS_MX28_PINCTRL_H__
diff --git a/arch/arm/boot/dts/imx53-tx53-x13x.dts 
b/arch/arm/boot/dts/imx53-tx53-x13x.dts
index 6cdf2082c742..a34d98cf6ed4 100644
--- a/arch/arm/boot/dts/imx53-tx53-x13x.dts
+++ b/arch/arm/boot/dts/imx53-tx53-x13x.dts
@@ -41,8 +41,8 @@
  * License. You may obtain a copy of the GNU General Public License
  * Version 2 at the following locations:
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ * https://www.opensource.org/licenses/gpl-license.html
+ * https://www.gnu.org/copyleft/gpl.html
  */
 
 /dts-v1/;
diff --git a/arch/arm/boot/dts/mxs-pinfunc.h b/arch/arm/boot/dts/mxs-pinfunc.h
index c6da987b20cb..6766292eee30 100644
--- a/arch/arm/boot/dts/mxs-pinfunc.h
+++ b/arch/arm/boot/dts/mxs-pinfunc.h
@@ -7,8 +7,8 @@
  * License. You may obtain a copy of the GNU General Public License
  * Version 2 at the following locations:
  *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
+ * https://www.opensource.org/licenses/gpl-license.html
+ * https://www.gnu.org/copyleft/gpl.html
  */
 
 #ifndef __DT_BINDINGS_MXS_PINCTRL_H__
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 06b0b57e996c..749490e3c66e 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -5,8 +5,8 @@
  * Public License.  You may obtain a copy of the GNU Lesser General
  * Public License Version 2.1 or later at the following locations:
  *
- * http://www.opensource.org/licenses/lgpl-license.html
- * http://www.gnu.org/copyleft/lgpl.html
+ * https://www.opensource.org/licenses/lgpl-license.html
+ * https://www.gnu.org/copyleft/lgpl.html
  */
 
 #ifndef __DRM_IPU_H__
-- 
2.27.0

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


[PATCH 4/5] drm: rockchip: set alpha_en to 0 if it is not used

2020-07-20 Thread Alex Bee
alpha_en should be set to 0 if it is not used, i.e. to disable alpha
blending if it was enabled before and should be disabled now.

fixes: 2aae8ed1f390 ("drm/rockchip: Add per-pixel alpha support for the PX30 
VOP")

Signed-off-by: Alex Bee 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c80f7d9fd13f..0f23144491e4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1013,6 +1013,7 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, alpha_en, 1);
} else {
VOP_WIN_SET(vop, win, src_alpha_ctl, SRC_ALPHA_EN(0));
+   VOP_WIN_SET(vop, win, alpha_en, 0);
}
 
VOP_WIN_SET(vop, win, enable, 1);
-- 
2.17.1

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


[PATCH for v5.9] dt-bindings: drm/bridge: Replace HTTP links with HTTPS ones

2020-07-20 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely
 or at least not (just) HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 .../devicetree/bindings/display/bridge/ti,sn65dsi86.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
index 8ec4a7f2623a..4b4b08dadc9e 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -2,7 +2,7 @@ SN65DSI86 DSI to eDP bridge chip
 
 
 This is the binding for Texas Instruments SN65DSI86 bridge.
-http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
+https://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86=pdf
 
 Required properties:
 - compatible: Must be "ti,sn65dsi86"
-- 
2.27.0

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


Re: [PATCH] drm: core: Convert device logging to drm_* functions.

2020-07-20 Thread Suraj Upadhyay
On Sat, Jul 18, 2020 at 08:25:31PM +0530, Suraj Upadhyay wrote:
> Convert device logging with dev_* functions into drm_* functions.
> 
> The patch has been generated with the coccinelle script below.
> The script focuses on instances of dev_* functions where the drm device
> context is clearly visible in its arguments.
> 
> @@expression E1; expression list E2; @@
> -dev_warn(E1->dev, E2)
> +drm_warn(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_info(E1->dev, E2)
> +drm_info(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_err(E1->dev, E2)
> +drm_err(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_info_once(E1->dev, E2)
> +drm_info_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_notice_once(E1->dev, E2)
> +drm_notice_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_warn_once(E1->dev, E2)
> +drm_warn_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_err_once(E1->dev, E2)
> +drm_err_once(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_err_ratelimited(E1->dev, E2)
> +drm_err_ratelimited(E1, E2)
> 
> @@expression E1; expression list E2; @@
> -dev_dbg(E1->dev, E2)
> +drm_dbg_(E1, E2)

I just spotted this error.

> Signed-off-by: Suraj Upadhyay 
> ---
>  drivers/gpu/drm/drm_edid.c   | 6 ++
>  drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
>  drivers/gpu/drm/drm_mipi_dbi.c   | 7 +++
>  3 files changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 52b357e75c3d..6840f0530a38 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1844,9 +1844,7 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
>   return;
>  
> - dev_warn(connector->dev->dev,
> -  "%s: EDID is invalid:\n",
> -  connector->name);
> + drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name);
>   for (i = 0; i < num_blocks; i++) {
>   u8 *block = edid + i * EDID_LENGTH;
>   char prefix[20];
> @@ -5298,7 +5296,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
> struct edid *edid)
>   }
>   if (!drm_edid_is_valid(edid)) {
>   clear_eld(connector);
> - dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
> + drm_warn(connector->dev, "%s: EDID invalid.\n",
>connector->name);
>   return 0;
>   }
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 06a5b9ee1fe0..8d7408a78aee 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -105,8 +105,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
> drm_device *drm,
>   cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
> GFP_KERNEL | __GFP_NOWARN);
>   if (!cma_obj->vaddr) {
> - dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
> - size);
> + drm_dbg_(drm, "failed to allocate buffer with size %zu\n",
> +  size);

This is an error here.
drm_dbg_ isn't any function.

Resending this patch.

Thanks,

Suraj Upadhyay.

>   ret = -ENOMEM;
>   goto error;
>   }
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 0e55d8716e3d..a7a611894243 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -225,9 +225,8 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer 
> *fb,
>   drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
>   break;
>   default:
> - dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
> -  drm_get_format_name(fb->format->format,
> -  _name));
> + drm_err_once(fb->dev, "Format is not supported: %s\n",
> +  drm_get_format_name(fb->format->format, 
> _name));
>   return -EINVAL;
>   }
>  
> @@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
> struct drm_rect *rect)
>  width * height * 2);
>  err_msg:
>   if (ret)
> - dev_err_once(fb->dev->dev, "Failed to update display %d\n", 
> ret);
> + drm_err_once(fb->dev, "Failed to update display %d\n", ret);
>  
>   drm_dev_exit(idx);
>  }
> -- 
> 2.17.1
> 




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


Re: [PATCH v11 0/4] Panel rotation patches

2020-07-20 Thread Dmitry Osipenko
18.06.2020 02:18, Dmitry Osipenko пишет:
> Hello!
> 
> This series adds support for display panel's DT rotation property. It's a
> continuation of the work that was initially started by Derek Basehore for
> the panel driver that is used by some Mediatek device [1]. I picked up the
> Derek's patches and added my t-b and r-b tags to them, I also added
> rotation support to the panel-lvds and panel-simple drivers.
> 
> We need the rotation support for the Nexus 7 tablet device which is pending
> to become supported by upstream kernel, the device has display panel mounted
> upside-down and it uses panel-lvds [2].
> 
> [1] https://lkml.org/lkml/2020/3/5/1119
> [2] 
> https://patchwork.ozlabs.org/project/linux-tegra/patch/20200607154327.18589-3-dig...@gmail.com/
> 
> Changelog:
> 
> v11: - This series is factored out from this patchset [3] because these
>patches do not have hard dependency on the Tegra DRM patches and
>it should be nicer to review and apply the properly grouped patches.
> 
>  - Initially [3] only touched the panel-lvds driver and Emil Velikov
>suggested that it will be better to support more panels in the review
>comments to [3]. So I included the Derek's patch for the BOE panel
>and added rotation support to the panel-simple driver. I tested that
>panel-lvds and panel-simple work properly with the rotated panel using
>the Opentegra Xorg driver [4] and Wayland Weston [5].
> 
>  - The panel-lvds driver now prints a error message if rotation property
>fails to be parsed.
> 
> [3] https://lore.kernel.org/lkml/20200614200121.14147-1-dig...@gmail.com/
> [4] 
> https://github.com/grate-driver/xf86-video-opentegra/commit/28eb20a3959bbe5bc3a3b67e55977093fd5114ca
> [5] https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/315
> 
> Derek Basehore (2):
>   drm/panel: Add helper for reading DT rotation
>   drm/panel: Read panel orientation for BOE TV101WUM-NL6
> 
> Dmitry Osipenko (2):
>   drm/panel: lvds: Read panel orientation
>   drm/panel-simple: Read panel orientation
> 
>  drivers/gpu/drm/drm_panel.c   | 43 +++
>  .../gpu/drm/panel/panel-boe-tv101wum-nl6.c|  6 +++
>  drivers/gpu/drm/panel/panel-lvds.c| 10 +
>  drivers/gpu/drm/panel/panel-simple.c  | 11 +
>  include/drm/drm_panel.h   |  9 
>  5 files changed, 79 insertions(+)
> 

Hi! Does anyone have any comments to this patchset? Will be nice if it
could get into 5.9 :) Thanks in advance!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH for v5.9] drm: Replace HTTP links with HTTPS ones

2020-07-20 Thread Alexander A. Klimov
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely
 or at least not (just) HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.

 Sorry again to all maintainers who complained about subject lines.
 Now I realized that you want an actually perfect prefixes,
 not just subsystem ones.
 I tried my best...
 And yes, *I could* (at least half-)automate it.
 Impossible is nothing! :)


 Documentation/gpu/vgaarbiter.rst | 8 
 drivers/gpu/drm/drm_modes.c  | 2 +-
 include/uapi/drm/drm_mode.h  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst
index 0b41b051d021..339ed5fecd2e 100644
--- a/Documentation/gpu/vgaarbiter.rst
+++ b/Documentation/gpu/vgaarbiter.rst
@@ -185,7 +185,7 @@ enhancing the kernel code to adapt as a kernel module and 
also did the
 implementation of the user space side [3]. Now (2009) Tiago Vignatti and Dave
 Airlie finally put this work in shape and queued to Jesse Barnes' PCI tree.
 
-0) 
http://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347
-1) http://lists.freedesktop.org/archives/xorg/2005-March/006663.html
-2) http://lists.freedesktop.org/archives/xorg/2005-March/006745.html
-3) http://lists.freedesktop.org/archives/xorg/2007-October/029507.html
+0) 
https://cgit.freedesktop.org/xorg/xserver/commit/?id=4b42448a2388d40f257774fbffdccaea87bd0347
+1) https://lists.freedesktop.org/archives/xorg/2005-March/006663.html
+2) https://lists.freedesktop.org/archives/xorg/2005-March/006745.html
+3) https://lists.freedesktop.org/archives/xorg/2007-October/029507.html
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fec1c33b3045..f6f21a5507f4 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -548,7 +548,7 @@ EXPORT_SYMBOL(drm_gtf_mode_complex);
  * Generalized Timing Formula is derived from:
  *
  * GTF Spreadsheet by Andy Morrish (1/5/97)
- * available at http://www.vesa.org
+ * available at https://www.vesa.org
  *
  * And it is copied from the file of xserver/hw/xfree86/modes/xf86gtf.c.
  * What I have done is to translate it by using integer calculation.
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 735c8cfdaaa1..deea447e5f22 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -497,7 +497,7 @@ struct drm_mode_fb_cmd2 {
 * In case of planar formats, this ioctl allows up to 4
 * buffer objects with offsets and pitches per plane.
 * The pitch and offset order is dictated by the fourcc,
-* e.g. NV12 (http://fourcc.org/yuv.php#NV12) is described as:
+* e.g. NV12 (https://fourcc.org/yuv.php#NV12) is described as:
 *
 *   YUV 4:2:0 image with a plane of 8 bit Y samples
 *   followed by an interleaved U/V plane containing
-- 
2.27.0

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


Re: [PATCH] drm/msm/dpu: fix/enable 6bpc dither with split-lm

2020-07-20 Thread Steev Klimaszewski
Hi,

On 7/15/20 5:19 PM, Rob Clark wrote:
> From: Rob Clark 
>
> If split-lm is used (for ex, on sdm845), we can have multiple ping-
> pongs, but only a single phys encoder.  We need to configure dithering
> on each of them.
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 22 ++-
>  .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c   |  3 +--
>  2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 46df0ff75b85..9b98b63c77fb 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -212,14 +212,14 @@ static u32 dither_matrix[DITHER_MATRIX_SZ] = {
>   15, 7, 13, 5, 3, 11, 1, 9, 12, 4, 14, 6, 0, 8, 2, 10
>  };
>  
> -static void _dpu_encoder_setup_dither(struct dpu_encoder_phys *phys)
> +static void _dpu_encoder_setup_dither(struct dpu_hw_pingpong *hw_pp, 
> unsigned bpc)
>  {
>   struct dpu_hw_dither_cfg dither_cfg = { 0 };
>  
> - if (!phys->hw_pp || !phys->hw_pp->ops.setup_dither)
> + if (!hw_pp->ops.setup_dither)
>   return;
>  
> - switch (phys->connector->display_info.bpc) {
> + switch (bpc) {
>   case 6:
>   dither_cfg.c0_bitdepth = 6;
>   dither_cfg.c1_bitdepth = 6;
> @@ -228,14 +228,14 @@ static void _dpu_encoder_setup_dither(struct 
> dpu_encoder_phys *phys)
>   dither_cfg.temporal_en = 0;
>   break;
>   default:
> - phys->hw_pp->ops.setup_dither(phys->hw_pp, NULL);
> + hw_pp->ops.setup_dither(hw_pp, NULL);
>   return;
>   }
>  
>   memcpy(_cfg.matrix, dither_matrix,
>   sizeof(u32) * DITHER_MATRIX_SZ);
>  
> - phys->hw_pp->ops.setup_dither(phys->hw_pp, _cfg);
> + hw_pp->ops.setup_dither(hw_pp, _cfg);
>  }
>  
>  void dpu_encoder_helper_report_irq_timeout(struct dpu_encoder_phys *phys_enc,
> @@ -1132,11 +1132,13 @@ static void _dpu_encoder_virt_enable_helper(struct 
> drm_encoder *drm_enc)
>  
>   _dpu_encoder_update_vsync_source(dpu_enc, _enc->disp_info);
>  
> - if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {
> - for (i = 0; i < dpu_enc->num_phys_encs; i++) {
> - struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
> -
> - _dpu_encoder_setup_dither(phys);
> + if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI &&
> + !WARN_ON(dpu_enc->num_phys_encs == 0)) {
> + unsigned bpc = 
> dpu_enc->phys_encs[0]->connector->display_info.bpc;
> + for (i = 0; i < MAX_CHANNELS_PER_ENC; i++) {
> + if (!dpu_enc->hw_pp[i])
> + continue;
> + _dpu_encoder_setup_dither(dpu_enc->hw_pp[i], bpc);
>   }
>   }
>  }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> index 7411ab6bf6af..bea4ab5c58c5 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
> @@ -231,8 +231,7 @@ static void _setup_pingpong_ops(struct dpu_hw_pingpong *c,
>   c->ops.poll_timeout_wr_ptr = dpu_hw_pp_poll_timeout_wr_ptr;
>   c->ops.get_line_count = dpu_hw_pp_get_line_count;
>  
> - if (test_bit(DPU_PINGPONG_DITHER, ) &&
> - IS_SC7180_TARGET(c->hw.hwversion))
> + if (test_bit(DPU_PINGPONG_DITHER, ))
>   c->ops.setup_dither = dpu_hw_pp_setup_dither;
>  };

Sorry for taking so long to get around to testing this.  I was able to
today, and it does reduce the banding to be less noticeable.

Tested-by: Steev Klimaszewski 

Thanks!

-- steev

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


[PATCH] drm: core: Convert device logging to drm_* functions.

2020-07-20 Thread Suraj Upadhyay
Convert device logging with dev_* functions into drm_* functions.

The patch has been generated with the coccinelle script below.
The script focuses on instances of dev_* functions where the drm device
context is clearly visible in its arguments.

@@expression E1; expression list E2; @@
-dev_warn(E1->dev, E2)
+drm_warn(E1, E2)

@@expression E1; expression list E2; @@
-dev_info(E1->dev, E2)
+drm_info(E1, E2)

@@expression E1; expression list E2; @@
-dev_err(E1->dev, E2)
+drm_err(E1, E2)

@@expression E1; expression list E2; @@
-dev_info_once(E1->dev, E2)
+drm_info_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_notice_once(E1->dev, E2)
+drm_notice_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_warn_once(E1->dev, E2)
+drm_warn_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_err_once(E1->dev, E2)
+drm_err_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_err_ratelimited(E1->dev, E2)
+drm_err_ratelimited(E1, E2)

@@expression E1; expression list E2; @@
-dev_dbg(E1->dev, E2)
+drm_dbg_(E1, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/gpu/drm/drm_edid.c   | 6 ++
 drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
 drivers/gpu/drm/drm_mipi_dbi.c   | 7 +++
 3 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 52b357e75c3d..6840f0530a38 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1844,9 +1844,7 @@ static void connector_bad_edid(struct drm_connector 
*connector,
if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
return;
 
-   dev_warn(connector->dev->dev,
-"%s: EDID is invalid:\n",
-connector->name);
+   drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name);
for (i = 0; i < num_blocks; i++) {
u8 *block = edid + i * EDID_LENGTH;
char prefix[20];
@@ -5298,7 +5296,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
}
if (!drm_edid_is_valid(edid)) {
clear_eld(connector);
-   dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
+   drm_warn(connector->dev, "%s: EDID invalid.\n",
 connector->name);
return 0;
}
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 06a5b9ee1fe0..8d7408a78aee 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -105,8 +105,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
drm_device *drm,
cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
  GFP_KERNEL | __GFP_NOWARN);
if (!cma_obj->vaddr) {
-   dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
-   size);
+   drm_dbg_(drm, "failed to allocate buffer with size %zu\n",
+size);
ret = -ENOMEM;
goto error;
}
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 0e55d8716e3d..a7a611894243 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -225,9 +225,8 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
break;
default:
-   dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
-drm_get_format_name(fb->format->format,
-_name));
+   drm_err_once(fb->dev, "Format is not supported: %s\n",
+drm_get_format_name(fb->format->format, 
_name));
return -EINVAL;
}
 
@@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
struct drm_rect *rect)
   width * height * 2);
 err_msg:
if (ret)
-   dev_err_once(fb->dev->dev, "Failed to update display %d\n", 
ret);
+   drm_err_once(fb->dev, "Failed to update display %d\n", ret);
 
drm_dev_exit(idx);
 }
-- 
2.17.1



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


[PATCH 3/4] drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel

2020-07-20 Thread Icenowy Zheng
Feixin K101-IM2BYL02 is a new panel by Feixin designed as a replacement
to their K101-IM2BA02 panel. This panel utilizes the Ilitek ILI9881C
controller.

Add this panel's initialzation sequence and timing to ILI9881C driver.

Signed-off-by: Icenowy Zheng 
---
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 217 ++
 1 file changed, 217 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 4f8e6865029f1..638108c519f02 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -260,6 +260,199 @@ static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_COMMAND_INSTR(0xD3, 0x3F),
 };
 
+static const struct ili9881c_instr k101_im2byl02_init[] = {
+   ILI9881C_SWITCH_PAGE_INSTR(3),
+   ILI9881C_COMMAND_INSTR(0x01, 0x00),
+   ILI9881C_COMMAND_INSTR(0x02, 0x00),
+   ILI9881C_COMMAND_INSTR(0x03, 0x73),
+   ILI9881C_COMMAND_INSTR(0x04, 0x00),
+   ILI9881C_COMMAND_INSTR(0x05, 0x00),
+   ILI9881C_COMMAND_INSTR(0x06, 0x08),
+   ILI9881C_COMMAND_INSTR(0x07, 0x00),
+   ILI9881C_COMMAND_INSTR(0x08, 0x00),
+   ILI9881C_COMMAND_INSTR(0x09, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0A, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0B, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0C, 0x00),
+   ILI9881C_COMMAND_INSTR(0x0D, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0E, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0F, 0x00),
+   ILI9881C_COMMAND_INSTR(0x10, 0x00),
+   ILI9881C_COMMAND_INSTR(0x11, 0x00),
+   ILI9881C_COMMAND_INSTR(0x12, 0x00),
+   ILI9881C_COMMAND_INSTR(0x13, 0x00),
+   ILI9881C_COMMAND_INSTR(0x14, 0x00),
+   ILI9881C_COMMAND_INSTR(0x15, 0x00),
+   ILI9881C_COMMAND_INSTR(0x16, 0x00),
+   ILI9881C_COMMAND_INSTR(0x17, 0x00),
+   ILI9881C_COMMAND_INSTR(0x18, 0x00),
+   ILI9881C_COMMAND_INSTR(0x19, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1A, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1B, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1C, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1D, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1E, 0x40),
+   ILI9881C_COMMAND_INSTR(0x1F, 0xC0),
+   ILI9881C_COMMAND_INSTR(0x20, 0x06),
+   ILI9881C_COMMAND_INSTR(0x21, 0x01),
+   ILI9881C_COMMAND_INSTR(0x22, 0x06),
+   ILI9881C_COMMAND_INSTR(0x23, 0x01),
+   ILI9881C_COMMAND_INSTR(0x24, 0x88),
+   ILI9881C_COMMAND_INSTR(0x25, 0x88),
+   ILI9881C_COMMAND_INSTR(0x26, 0x00),
+   ILI9881C_COMMAND_INSTR(0x27, 0x00),
+   ILI9881C_COMMAND_INSTR(0x28, 0x3B),
+   ILI9881C_COMMAND_INSTR(0x29, 0x03),
+   ILI9881C_COMMAND_INSTR(0x2A, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2B, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2C, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2D, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2E, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2F, 0x00),
+   ILI9881C_COMMAND_INSTR(0x30, 0x00),
+   ILI9881C_COMMAND_INSTR(0x31, 0x00),
+   ILI9881C_COMMAND_INSTR(0x32, 0x00),
+   ILI9881C_COMMAND_INSTR(0x33, 0x00),
+   ILI9881C_COMMAND_INSTR(0x34, 0x00), /* GPWR1/2 non overlap time 2.62us 
*/
+   ILI9881C_COMMAND_INSTR(0x35, 0x00),
+   ILI9881C_COMMAND_INSTR(0x36, 0x00),
+   ILI9881C_COMMAND_INSTR(0x37, 0x00),
+   ILI9881C_COMMAND_INSTR(0x38, 0x00),
+   ILI9881C_COMMAND_INSTR(0x39, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3A, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3B, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3C, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3D, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3E, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3F, 0x00),
+   ILI9881C_COMMAND_INSTR(0x40, 0x00),
+   ILI9881C_COMMAND_INSTR(0x41, 0x00),
+   ILI9881C_COMMAND_INSTR(0x42, 0x00),
+   ILI9881C_COMMAND_INSTR(0x43, 0x00),
+   ILI9881C_COMMAND_INSTR(0x44, 0x00),
+   ILI9881C_COMMAND_INSTR(0x50, 0x01),
+   ILI9881C_COMMAND_INSTR(0x51, 0x23),
+   ILI9881C_COMMAND_INSTR(0x52, 0x45),
+   ILI9881C_COMMAND_INSTR(0x53, 0x67),
+   ILI9881C_COMMAND_INSTR(0x54, 0x89),
+   ILI9881C_COMMAND_INSTR(0x55, 0xAB),
+   ILI9881C_COMMAND_INSTR(0x56, 0x01),
+   ILI9881C_COMMAND_INSTR(0x57, 0x23),
+   ILI9881C_COMMAND_INSTR(0x58, 0x45),
+   ILI9881C_COMMAND_INSTR(0x59, 0x67),
+   ILI9881C_COMMAND_INSTR(0x5A, 0x89),
+   ILI9881C_COMMAND_INSTR(0x5B, 0xAB),
+   ILI9881C_COMMAND_INSTR(0x5C, 0xCD),
+   ILI9881C_COMMAND_INSTR(0x5D, 0xEF),
+   ILI9881C_COMMAND_INSTR(0x5E, 0x00),
+   ILI9881C_COMMAND_INSTR(0x5F, 0x01),
+   ILI9881C_COMMAND_INSTR(0x60, 0x01),
+   ILI9881C_COMMAND_INSTR(0x61, 0x06),
+   ILI9881C_COMMAND_INSTR(0x62, 0x06),
+   ILI9881C_COMMAND_INSTR(0x63, 0x07),
+   ILI9881C_COMMAND_INSTR(0x64, 0x07),
+   ILI9881C_COMMAND_INSTR(0x65, 0x00),
+   ILI9881C_COMMAND_INSTR(0x66, 0x00),
+   ILI9881C_COMMAND_INSTR(0x67, 0x02),
+   ILI9881C_COMMAND_INSTR(0x68, 0x02),
+   

[PATCH 0/4] Add support for Feixin K101-IM2BYL02 panel

2020-07-20 Thread Icenowy Zheng
The controller chip of Feixin K101-IM2BA02 is going to be discontinued,
so Feixin start to provide K101-IM2BYL02 panel as a replacement, which
utilizes Ilitek ILI9881C controller.

Add support for K101-IM2BYL02 panel.

By the way, is there a way that can try both kind of panels in the same
kernel/DTB combo? K101-IM2BYL02 has the same pinout with K101-IM2BA02,
and PineTab schedule to switch to it w/o modifying the mainboard.

Icenowy Zheng (4):
  drm/panel: ilitek-ili9881c: prepare for adding support for extra
panels
  dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02
  drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel
  [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel
for PineTab

 .../display/panel/ilitek,ili9881c.yaml|   1 +
 .../boot/dts/allwinner/sun50i-a64-pinetab.dts |  10 +
 drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 273 --
 3 files changed, 265 insertions(+), 19 deletions(-)

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


[PATCH 5/5] drm: rockchip: use overlay windows as such

2020-07-20 Thread Alex Bee
As stated in the comment for rk3288_vop_win_data windows
that are supposed to be an overlay window are missused as HWC windows
due to the missing implementation of that window type in VOP driver.

This is also true for RK3036, RK3126, RK3188 and RK3228 VOPs which
all have at least one dedicated HWC window (which are currently not
definded in the driver).
Since all of the mentioned VOPs have only one overlay window and all
of them support alpha blending now it should be used as such, since
this gives a much wider usage-perspective for them.

Signed-off-by: Alex Bee 
---
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index f2f9a9af39e3..756c580f206a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -131,7 +131,7 @@ static const struct vop_win_data rk3036_vop_win_data[] = {
{ .base = 0x00, .phy = _win0_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x00, .phy = _win1_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3036_vop_intrs[] = {
@@ -200,7 +200,7 @@ static const struct vop_win_data rk3126_vop_win_data[] = {
{ .base = 0x00, .phy = _win0_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x00, .phy = _win1_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3126_vop = {
@@ -543,7 +543,7 @@ static const struct vop_win_data rk3188_vop_win_data[] = {
{ .base = 0x00, .phy = _win0_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x00, .phy = _win1_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const int rk3188_vop_intrs[] = {
@@ -980,7 +980,7 @@ static const struct vop_win_data rk3228_vop_win_data[] = {
{ .base = 0x00, .phy = _win01_data,
  .type = DRM_PLANE_TYPE_PRIMARY },
{ .base = 0x40, .phy = _win01_data,
- .type = DRM_PLANE_TYPE_CURSOR },
+ .type = DRM_PLANE_TYPE_OVERLAY },
 };
 
 static const struct vop_data rk3228_vop = {
-- 
2.17.1

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


[PATCH v2] drm: core: Convert device logging to drm_* functions.

2020-07-20 Thread Suraj Upadhyay
Convert device logging with dev_* functions into drm_* functions.

The patch has been generated with the coccinelle script below.
The script focuses on instances of dev_* functions where the drm device
context is clearly visible in its arguments.

@@expression E1; expression list E2; @@
-dev_warn(E1->dev, E2)
+drm_warn(E1, E2)

@@expression E1; expression list E2; @@
-dev_info(E1->dev, E2)
+drm_info(E1, E2)

@@expression E1; expression list E2; @@
-dev_err(E1->dev, E2)
+drm_err(E1, E2)

@@expression E1; expression list E2; @@
-dev_info_once(E1->dev, E2)
+drm_info_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_notice_once(E1->dev, E2)
+drm_notice_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_warn_once(E1->dev, E2)
+drm_warn_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_err_once(E1->dev, E2)
+drm_err_once(E1, E2)

@@expression E1; expression list E2; @@
-dev_err_ratelimited(E1->dev, E2)
+drm_err_ratelimited(E1, E2)

@@expression E1; expression list E2; @@
-dev_dbg(E1->dev, E2)
+drm_dbg(E1, E2)

Signed-off-by: Suraj Upadhyay 
---
Changes:
v2: Fixed error in coccinelle script and diff,
i.e. removed the underscore.
drv_dbg_ -> drm_dbg

 drivers/gpu/drm/drm_edid.c   | 6 ++
 drivers/gpu/drm/drm_gem_cma_helper.c | 4 ++--
 drivers/gpu/drm/drm_mipi_dbi.c   | 7 +++
 3 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 52b357e75c3d..6840f0530a38 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1844,9 +1844,7 @@ static void connector_bad_edid(struct drm_connector 
*connector,
if (connector->bad_edid_counter++ && !drm_debug_enabled(DRM_UT_KMS))
return;
 
-   dev_warn(connector->dev->dev,
-"%s: EDID is invalid:\n",
-connector->name);
+   drm_warn(connector->dev, "%s: EDID is invalid:\n", connector->name);
for (i = 0; i < num_blocks; i++) {
u8 *block = edid + i * EDID_LENGTH;
char prefix[20];
@@ -5298,7 +5296,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
}
if (!drm_edid_is_valid(edid)) {
clear_eld(connector);
-   dev_warn(connector->dev->dev, "%s: EDID invalid.\n",
+   drm_warn(connector->dev, "%s: EDID invalid.\n",
 connector->name);
return 0;
}
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 06a5b9ee1fe0..822edeadbab3 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -105,8 +105,8 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct 
drm_device *drm,
cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
  GFP_KERNEL | __GFP_NOWARN);
if (!cma_obj->vaddr) {
-   dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
-   size);
+   drm_dbg(drm, "failed to allocate buffer with size %zu\n",
+size);
ret = -ENOMEM;
goto error;
}
diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 0e55d8716e3d..a7a611894243 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -225,9 +225,8 @@ int mipi_dbi_buf_copy(void *dst, struct drm_framebuffer *fb,
drm_fb_xrgb_to_rgb565(dst, src, fb, clip, swap);
break;
default:
-   dev_err_once(fb->dev->dev, "Format is not supported: %s\n",
-drm_get_format_name(fb->format->format,
-_name));
+   drm_err_once(fb->dev, "Format is not supported: %s\n",
+drm_get_format_name(fb->format->format, 
_name));
return -EINVAL;
}
 
@@ -295,7 +294,7 @@ static void mipi_dbi_fb_dirty(struct drm_framebuffer *fb, 
struct drm_rect *rect)
   width * height * 2);
 err_msg:
if (ret)
-   dev_err_once(fb->dev->dev, "Failed to update display %d\n", 
ret);
+   drm_err_once(fb->dev, "Failed to update display %d\n", ret);
 
drm_dev_exit(idx);
 }
-- 
2.17.1



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


Re: [PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops

2020-07-20 Thread Alex Hung
On 2020-07-19 1:50 p.m., Karol Herbst wrote:
> On Fri, Jul 17, 2020 at 9:52 PM Alex Hung  wrote:
>>
>> On 2020-07-17 1:05 p.m., Karol Herbst wrote:
>>> It's hard to figure out what systems are actually affected and right now I
>>> don't see a good way of removing those...
>>>
>>> But I'd like to see thos getting removed and drivers fixed instead (which
>>> happened at least for nouveau).
>>>
>>> And as mentioned before, I prefer people working on fixing issues instead
>>> of spending time to add firmware level workarounds which are hard to know
>>> to which systems they apply to, hard to remove and basically a big huge
>>> pain to work with.> In the end I have no idea how to even figure out what 
>>> systems are affected
>>> and which not by this, so I have no idea how to even verify we can safely
>>> remove this (which just means those are impossible to remove unless we risk
>>> breaking systems, which again makes those supper annoying to deal with).
>>>
>>> Also from the comments it's hard to get what those bits really do. Are they
>>> just preventing runtime pm or do the devices are powered down when booting?
>>> I am sure it's the former, still...
>>>
>>> Please, don't do this again.
>>>
>>> For now, those workaround prevent power savings on systems those workaround
>>> applies to, which might be any so those should get removed asap and if
>>> new issues arrise removing those please do a proper bug report and we can
>>> look into it and come up with a proper fix (and keep this patch out until
>>> we resolve all of those).
>>>
>>> Signed-off-by: Karol Herbst 
>>> CC: Alex Hung 
>>> CC: "Rafael J. Wysocki" 
>>> CC: Len Brown 
>>> CC: Lyude Paul 
>>> CC: linux-ker...@vger.kernel.org
>>> CC: dri-devel@lists.freedesktop.org
>>> CC: nouv...@lists.freedesktop.org
>>> ---
>>>  drivers/acpi/osi.c | 24 
>>>  1 file changed, 24 deletions(-)
>>>
>>> diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
>>> index 9f68538091384..d4405e1ca9b97 100644
>>> --- a/drivers/acpi/osi.c
>>> +++ b/drivers/acpi/osi.c
>>> @@ -44,30 +44,6 @@ osi_setup_entries[OSI_STRING_ENTRIES_MAX] __initdata = {
>>>   {"Processor Device", true},
>>>   {"3.0 _SCP Extensions", true},
>>>   {"Processor Aggregator Device", true},
>>> - /*
>>> -  * Linux-Dell-Video is used by BIOS to disable RTD3 for NVidia 
>>> graphics
>>> -  * cards as RTD3 is not supported by drivers now.  Systems with NVidia
>>> -  * cards will hang without RTD3 disabled.
>>> -  *
>>> -  * Once NVidia drivers officially support RTD3, this _OSI strings can
>>> -  * be removed if both new and old graphics cards are supported.
>>> -  */
>>> - {"Linux-Dell-Video", true},
>>> - /*
>>> -  * Linux-Lenovo-NV-HDMI-Audio is used by BIOS to power on NVidia's 
>>> HDMI
>>> -  * audio device which is turned off for power-saving in Windows OS.
>>> -  * This power management feature observed on some Lenovo Thinkpad
>>> -  * systems which will not be able to output audio via HDMI without
>>> -  * a BIOS workaround.
>>> -  */
>>> - {"Linux-Lenovo-NV-HDMI-Audio", true},
>>> - /*
>>> -  * Linux-HPI-Hybrid-Graphics is used by BIOS to enable dGPU to
>>> -  * output video directly to external monitors on HP Inc. mobile
>>> -  * workstations as Nvidia and AMD VGA drivers provide limited
>>> -  * hybrid graphics supports.
>>> -  */
>>> - {"Linux-HPI-Hybrid-Graphics", true},
>>>  };
>>>
>>>  static u32 acpi_osi_handler(acpi_string interface, u32 supported)
>>>
>>
>> The changes were discussed and tested a while ago, and no crashes were
>> observed. Thanks for solving PM issues in nouveau.
>>
>> Acked-by: Alex Hung 
>>
> 
> By any chance, do you have a list of systems implementing those workarounds?
> 

I don't keep a list but the workaround, in theory, should only apply to
the systems with the specific nvidia hardware.

I reminded OEMs and ODMs that these _OSI strings were temporary
solutions, and highlighted we were going to remove them after our
discussion last year. If they were paying attentions recent systems
shouldn't have these _OSI strings.

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


  1   2   >