Re: [PATCH V5 1/3] drm/panel: simple: Add Logic PD Type 28 display support

[Sam Ravnborg]

Hi Adam.

On Wed, Oct 16, 2019 at 08:51:45AM -0500, Adam Ford wrote:
> Previously, there was an omap panel-dpi driver that would
> read generic timings from the device tree and set the display
> timing accordingly.  This driver was removed so the screen
> no longer functions.  This patch modifies the panel-simple
> file to setup the timings to the same values previously used.
> 
> Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
> 
> Signed-off-by: Adam Ford 
> Reviewed-by: Sam Ravnborg 
> ---
> V5:  No Change
> V4:  No Change
> V3:  No Change
> V2:  No Change

Applied to drm-misc-next.
Sorry for the delay - has been absent for a while.

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

Re: [PATCH V5 2/3] dt-bindings: Add Logic PD Type 28 display panel

[Sam Ravnborg]

Hi Adam.
On Wed, Oct 16, 2019 at 08:51:46AM -0500, Adam Ford wrote:
> This patch adds documentation of device tree bindings for the WVGA panel
> Logic PD Type 28 display.
> 
> Signed-off-by: Adam Ford 
> ---
> V5:  Replace GPIO_ACTIVE_HIGH with 0 to fix make dt_binding_check -k
> V4:  Update per Rob H's suggestions and copy other panel yaml example from 
> 5.4-rc1
> V3:  Correct build errors from 'make dt_binding_check'
> V2:  Use YAML instead of TXT for binding
> 

Applied to drm-misc-next.
It was applied before the driver changes so we had bindings
for the driver changes when applied.

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

Re: [PATCHv1 1/2] drm/panel: simple: Add support for AUO G121EAN01.4 panel

[Sam Ravnborg]

Hi Sebastian.
On Thu, Nov 07, 2019 at 06:23:30PM +0100, Sebastian Reichel wrote:
> Add timings for the AUO G121EAN01.4 panel.
> 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 28fa6ba7b767..46ca59db6819 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -806,6 +806,29 @@ static const struct panel_desc auo_g104sn02 = {
>   },
>  };
>  
> +static const struct drm_display_mode auo_g121ean01_mode = {
> + .clock = 66700,
> + .hdisplay = 1280,
> + .hsync_start = 1280 + 58,
> + .hsync_end = 1280 + 58 + 8,
> + .htotal = 1280 + 58 + 8 + 70,
> + .vdisplay = 800,
> + .vsync_start = 800 + 6,
> + .vsync_end = 800 + 6 + 4,
> + .vtotal = 800 + 6 + 4 + 10,
> + .vrefresh = 60,
> +};
> +
> +static const struct panel_desc auo_g121ean01 = {
> + .modes = _g121ean01_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 261,
> + .height = 163,
> + },
> +};
> +
>  static const struct display_timing auo_g133han01_timings = {
>   .pixelclock = { 13400, 14120, 14900 },
>   .hactive = { 1920, 1920, 1920 },
> @@ -3114,6 +3137,9 @@ static const struct of_device_id platform_of_match[] = {
>   }, {
>   .compatible = "auo,g104sn02",
>   .data = _g104sn02,
> + }, {
> + .compatible = "auo,g121ean01.4",
> + .data = _g121ean01,

I did not find any binding document for this,
so I cannot apply.
If you need to create a new binding then please
use the meta-schema format (.yaml).

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

Re: [PATCH] dt-bindings: display: Convert a bunch of panels to DT schema

[Sam Ravnborg]

Hi Rob.

Thanks for doing this boring, trivial and tiresome task.

On Tue, Nov 19, 2019 at 05:13:09PM -0600, Rob Herring wrote:
> Convert all the 'simple' panels which either use the single
> 'power-supply' property or don't say and just reference
> simple-panel.txt. In the later case, bindings are clear as to which
> properties are required or unused.
> 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Thierry Reding 
> Cc: Sam Ravnborg 
> Signed-off-by: Rob Herring 

So Thierry and I ended up as Maintianes for them all.
I gues thats OK as we look after the panel stuff anyway.

> ---
> We could perhaps consolidate a bunch of these, but I have no idea how 
> accurate some of these are WRT what's required or not. Seems strange 
> that 'backlight' is optional unless the backlight is tied full on for 
> example. If that's the case, then should backlight ever be required?
I do not really follow you here.
Looking through the patch set things looks normal to me.

What do I miss here?


I did not find anything I consider bugs. It is mostly small
inconsistencies.

- Almost all new .yaml files ends with "..."
  Except one file: nec,nl12880b20-05.yaml


- When there is more than one compatible the extra compatible is specified
  in two ways:

  Like this with consts:
properties:
+  compatible:
+items:
+  - const: bananapi,lhr050h41
+  - const: ilitek,ili9881c
+

  Link this with enum:
+properties:
+  compatible:
+enum:
+  - urt,umsh-8596md-t
+  - urt,umsh-8596md-1t
+  - urt,umsh-8596md-7t
+  - urt,umsh-8596md-11t
+  - urt,umsh-8596md-19t
+  - urt,umsh-8596md-20t

- My OCD prefer only one method to list more than
  one compatible. Using "enum" syntax above seems to be the common
  case - and the simple syntax.

- In several cases the original binding provided an example
  which is now dropped. Is this on purpose?
  This is very simple examples - so I am happy to see them go.
  They really did not provide anything extra.
  I have mentioned it for some - but I stopped as I think
  they are left out on purpose.
  The changelog should mention this.

- There are some bindings that list a reg property.
  I have noted that their comment is not keept.

- It seems inconsistent what is listed as properties and mandatory.
  Most, but not all, include "enable-gpios: true" in properties.
  And the listed mandatory properties sometimes
  differ even when the description does not give a hint why.
  Maybe this was needed to verify existing bindings?

See a few comments in the following.

Sam


> diff --git 
> a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml 
> b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> index 47950fced28d..a5e6735fe34b 100644
> --- 
> a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> +++ 
> b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
> @@ -85,7 +85,7 @@ examples:
>  panel@0 {
>  compatible = "bananapi,lhr050h41", "ilitek,ili9881c";
>  reg = <0>;
> -power-gpios = < 1 7 0>; /* PB07 */
> +power-supply = <>;
>  reset-gpios = <_pio 0 5 1>; /* PL05 */
>  backlight = <_bl>;
>  };

This looks like an unrelated change - drop?


> diff --git 
> a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt 
> b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> deleted file mode 100644
> index 49e4105378f6..
> --- a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -AU Optronics Corporation 7.0" FHD (800 x 480) TFT LCD panel
> -
> -Required properties:
> -- compatible: should be "auo,g070vvn01"
> -- backlight: phandle of the backlight device attached to the panel
> -- power-supply: single regulator to provide the supply voltage
> -
> -Required nodes:
> -- port: Parallel port mapping to connect this display
> -
> -This panel needs single power supply voltage. Its backlight is conntrolled
> -via PWM signal.
This comment is lost. It does not provide much info so the value of the
comment is questionable.

> -
> -Example:
> -
> -
> -Example device-tree definition when connected to iMX6Q based board
> -
> - lcd_panel: lcd-panel {
> - compatible = "auo,g070vvn01";
> - backlight = <_lcd>;
> - power-supply = <_display>;
> -
> - port {
> - lcd_panel_in: endpoint {
> - remote-endpoint = <_display_out>;
> - };
> - };
> - };
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.yaml 
> b/Documentation/devicetree/bindings/display/panel/auo,g070vvn01.yaml
> new file mode 100644
> index ..6b2bbb2d4e2b
> --- /dev/null
> +++ 

[Bug 205649] Daisy Chain (MST) Session Crash after Screen Lock Resume

[bugzilla-daemon]

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

Michael Rauch (mich...@rauch.be) changed:

   What|Removed |Added

 Kernel Version|5.4 |5.3, 5.4

-- 
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 v7 17/24] mm/gup: track FOLL_PIN pages

[kbuild test robot]

Hi John,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.4]
[cannot apply to mmotm/master rdma/for-next linuxtv-media/master next-20191129]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/John-Hubbard/mm-gup-track-dma-pinned-pages-FOLL_PIN/20191122-092349
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
c74386d50fbaf4a54fd3fe560f1abc709c0cff4b
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh 

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

All errors (new ones prefixed by >>):

   mm/gup.c: In function 'pin_user_pages_remote':
>> mm/gup.c:2684:9: error: implicit declaration of function 
>> '__get_user_pages_remote'; did you mean 'get_user_pages_remote'? 
>> [-Werror=implicit-function-declaration]
 return __get_user_pages_remote(tsk, mm, start, nr_pages, gup_flags,
^~~
get_user_pages_remote
   cc1: some warnings being treated as errors

vim +2684 mm/gup.c

  2660  
  2661  /**
  2662   * pin_user_pages_remote() - pin pages of a remote process (task != 
current)
  2663   *
  2664   * Nearly the same as get_user_pages_remote(), except that FOLL_PIN is 
set. See
  2665   * get_user_pages_remote() for documentation on the function arguments, 
because
  2666   * the arguments here are identical.
  2667   *
  2668   * FOLL_PIN means that the pages must be released via 
unpin_user_page(). Please
  2669   * see Documentation/vm/pin_user_pages.rst for details.
  2670   *
  2671   * This is intended for Case 1 (DIO) in 
Documentation/vm/pin_user_pages.rst. It
  2672   * is NOT intended for Case 2 (RDMA: long-term pins).
  2673   */
  2674  long pin_user_pages_remote(struct task_struct *tsk, struct mm_struct 
*mm,
  2675 unsigned long start, unsigned long nr_pages,
  2676 unsigned int gup_flags, struct page **pages,
  2677 struct vm_area_struct **vmas, int *locked)
  2678  {
  2679  /* FOLL_GET and FOLL_PIN are mutually exclusive. */
  2680  if (WARN_ON_ONCE(gup_flags & FOLL_GET))
  2681  return -EINVAL;
  2682  
  2683  gup_flags |= FOLL_PIN;
> 2684  return __get_user_pages_remote(tsk, mm, start, nr_pages, 
> gup_flags,
  2685 pages, vmas, locked);
  2686  }
  2687  EXPORT_SYMBOL(pin_user_pages_remote);
  2688  

---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation


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

Re: [GIT PULL] Please pull hmm changes

[Linus Torvalds]

On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe  wrote:
>
> Here is this batch of hmm updates, I think we are nearing the end of this
> project for now, although I suspect there will be some more patches related to
> hmm_range_fault() in the next cycle.

I've ended up pulling this, but I'm not entirely happy with the code.
You've already seen the comments on it in the earlier replies.

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

Re: [git pull] mm + drm vmwgfx coherent

[pr-tracker-bot]

The pull request you sent on Fri, 29 Nov 2019 11:15:13 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-vmwgfx-coherent-2019-11-29

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d5bb349dbbe27537e90a03b9597deeb07723a86d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding

[Rob Clark]

On Sat, Nov 30, 2019 at 10:37 AM Rob Clark  wrote:
>
> On Mon, Jul 1, 2019 at 7:03 AM Rob Herring  wrote:
> >
> > On Sun, Jun 30, 2019 at 2:36 PM Rob Clark  wrote:
> > >
> > > From: Rob Clark 
> > >
> > > The panel-id property in chosen can be used to communicate which panel,
> > > of multiple possibilities, is installed.
> > >
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  Documentation/devicetree/bindings/chosen.txt | 69 
> > >  1 file changed, 69 insertions(+)
> >
> > I need to update this file to say it's moved to the schema repository...
> >
> > But I don't think that will matter...
> >
> > > diff --git a/Documentation/devicetree/bindings/chosen.txt 
> > > b/Documentation/devicetree/bindings/chosen.txt
> > > index 45e79172a646..d502e6489b8b 100644
> > > --- a/Documentation/devicetree/bindings/chosen.txt
> > > +++ b/Documentation/devicetree/bindings/chosen.txt
> > > @@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found.  
> > > However, the
> > >  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
> > >  should only use the "stdout-path" property.
> > >
> > > +panel-id
> > > +
> > > +
> > > +For devices that have multiple possible display panels (multi-sourcing 
> > > the
> > > +display panels is common on laptops, phones, tablets), this allows the
> > > +bootloader to communicate which panel is installed, e.g.
> >
> > How does the bootloader figure out which panel? Why can't the kernel
> > do the same thing?
> >
> > > +
> > > +/ {
> > > +   chosen {
> > > +   panel-id = <0xc4>;
> > > +   };
> > > +
> > > +   ivo_panel {
> > > +   compatible = "ivo,m133nwf4-r0";
> > > +   power-supply = <_3v3>;
> > > +   no-hpd;
> > > +
> > > +   ports {
> > > +   port {
> > > +   ivo_panel_in_edp: endpoint {
> > > +   remote-endpoint = 
> > > <_out_ivo>;
> > > +   };
> > > +   };
> > > +   };
> > > +   };
> > > +
> > > +   boe_panel {
> > > +   compatible = "boe,nv133fhm-n61";
> >
> > Both panels are going to probe. So the bootloader needs to disable the
> > not populated panel setting 'status' (or delete the node). If you do
> > that, do you even need 'panel-id'?
> >
>
> So, I'm finally having some time to revisit this proposal..  I have a
> few updates:
>
> + Updated DtbLoader.efi to read UEFIDisplayInfo and get the panel-id
>   so I can drop the efi/libstub patch[1]
> + I can drop drm_of_find_panel_id() and fold the logic to look at
>   /chosen/panel-id into drm_of_find_panel_or_bridge() so that each
>   driver or bridge doesn't need an update
>
> This doesn't realy solve the issue that both panels will probe.  On
> the other hand, I really don't want to make the DtbLoader know enough
> about the dt structure of each laptop to patch dt, since that is not
> going to be scalable at all.  (Likewise, there is some interest for
> devices that use u-boot to take the panel-id from a uboot env var and
> patch dt, but again knowing enough to intelligently patch the dt is
> not going to be feasible.)
>
> But, an alternate solution could be, instead of adding a 'panel-id'
> node in chosen, I could add it as an optional property in the panel
> node.  So taking my original example of the yoga c630 laptops, with
> the two possible panel id's 0xc4 and 0xc5:
>
> ivo_panel {
> compatible = "ivo,m133nwf4-r0";
> panel-id = <0xc4>;

correction, the ivo panel should have panel-id = <0xc5>

> status = "disabled";
>
> ports {
> port {
> ivo_panel_in_edp: endpoint {
> remote-endpoint = <_out_ivo>;
> };
> };
> };
> };
>
> boe_panel {
> compatible = "boe,nv133fhm-n61";
> panel-id = <0xc4>;
> status = "disabled";
>
> ports {
> port {
> boe_panel_in_edp: endpoint {
> remote-endpoint = <_out_boe>;
> };
> };
> };
> };
>
> sn65dsi86: bridge@2c {
> compatible = "ti,sn65dsi86";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> sn65dsi86_in_a: endpoint {
> remote-endpoint = <_out>;
> };
> };
>
> port@1 {
> reg = <1>;
>
> sn65dsi86_out_boe: endpoint@c4 {
> remote-endpoint = <_panel_in_edp>;
> };
>
> sn65dsi86_out_ivo: endpoint@c5 {
> remote-endpoint = <_panel_in_edp>;
> };
> };
> };
> };
>
> With this, the "firmware" (DtbLoader, u-boot, etc) could crawl the
> entire dt looking for a 

Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding

[Rob Clark]

On Mon, Jul 1, 2019 at 7:03 AM Rob Herring  wrote:
>
> On Sun, Jun 30, 2019 at 2:36 PM Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > The panel-id property in chosen can be used to communicate which panel,
> > of multiple possibilities, is installed.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  Documentation/devicetree/bindings/chosen.txt | 69 
> >  1 file changed, 69 insertions(+)
>
> I need to update this file to say it's moved to the schema repository...
>
> But I don't think that will matter...
>
> > diff --git a/Documentation/devicetree/bindings/chosen.txt 
> > b/Documentation/devicetree/bindings/chosen.txt
> > index 45e79172a646..d502e6489b8b 100644
> > --- a/Documentation/devicetree/bindings/chosen.txt
> > +++ b/Documentation/devicetree/bindings/chosen.txt
> > @@ -68,6 +68,75 @@ on PowerPC "stdout" if "stdout-path" is not found.  
> > However, the
> >  "linux,stdout-path" and "stdout" properties are deprecated. New platforms
> >  should only use the "stdout-path" property.
> >
> > +panel-id
> > +
> > +
> > +For devices that have multiple possible display panels (multi-sourcing the
> > +display panels is common on laptops, phones, tablets), this allows the
> > +bootloader to communicate which panel is installed, e.g.
>
> How does the bootloader figure out which panel? Why can't the kernel
> do the same thing?
>
> > +
> > +/ {
> > +   chosen {
> > +   panel-id = <0xc4>;
> > +   };
> > +
> > +   ivo_panel {
> > +   compatible = "ivo,m133nwf4-r0";
> > +   power-supply = <_3v3>;
> > +   no-hpd;
> > +
> > +   ports {
> > +   port {
> > +   ivo_panel_in_edp: endpoint {
> > +   remote-endpoint = 
> > <_out_ivo>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +
> > +   boe_panel {
> > +   compatible = "boe,nv133fhm-n61";
>
> Both panels are going to probe. So the bootloader needs to disable the
> not populated panel setting 'status' (or delete the node). If you do
> that, do you even need 'panel-id'?
>

So, I'm finally having some time to revisit this proposal..  I have a
few updates:

+ Updated DtbLoader.efi to read UEFIDisplayInfo and get the panel-id
  so I can drop the efi/libstub patch[1]
+ I can drop drm_of_find_panel_id() and fold the logic to look at
  /chosen/panel-id into drm_of_find_panel_or_bridge() so that each
  driver or bridge doesn't need an update

This doesn't realy solve the issue that both panels will probe.  On
the other hand, I really don't want to make the DtbLoader know enough
about the dt structure of each laptop to patch dt, since that is not
going to be scalable at all.  (Likewise, there is some interest for
devices that use u-boot to take the panel-id from a uboot env var and
patch dt, but again knowing enough to intelligently patch the dt is
not going to be feasible.)

But, an alternate solution could be, instead of adding a 'panel-id'
node in chosen, I could add it as an optional property in the panel
node.  So taking my original example of the yoga c630 laptops, with
the two possible panel id's 0xc4 and 0xc5:

ivo_panel {
compatible = "ivo,m133nwf4-r0";
panel-id = <0xc4>;
status = "disabled";

ports {
port {
ivo_panel_in_edp: endpoint {
remote-endpoint = <_out_ivo>;
};
};
};
};

boe_panel {
compatible = "boe,nv133fhm-n61";
panel-id = <0xc4>;
status = "disabled";

ports {
port {
boe_panel_in_edp: endpoint {
remote-endpoint = <_out_boe>;
};
};
};
};

sn65dsi86: bridge@2c {
compatible = "ti,sn65dsi86";

ports {
#address-cells = <1>;
#size-cells = <0>;

port@0 {
reg = <0>;
sn65dsi86_in_a: endpoint {
remote-endpoint = <_out>;
};
};

port@1 {
reg = <1>;

sn65dsi86_out_boe: endpoint@c4 {
remote-endpoint = <_panel_in_edp>;
};

sn65dsi86_out_ivo: endpoint@c5 {
remote-endpoint = <_panel_in_edp>;
};
};
};
};

With this, the "firmware" (DtbLoader, u-boot, etc) could crawl the
entire dt looking for a node with a panel-id that matches the one it's
looking for, and change that node's status to enabled.

The advantage would be that the other panel(s) that is not installed
will not be probed.  The downsides are that (1) the drm drivers would
have to loop over all the endpoints to find the active panel (some
drivers do this already, most do not), and (2) the property name
"panel-id" (or whatever we 

Re: [PATCH 3/3] drm/panel: simple: Add support for the Frida FRD350H54004 panel

[Sam Ravnborg]

Hi Paul.

I am not sure if I already wrote this...

On Wed, Nov 20, 2019 at 06:10:27PM +0100, Paul Cercueil wrote:
> The FRD350H54004 is a simple 3.5" 320x240 24-bit TFT panel, found for
> instance inside the Anbernic RG-350 handheld gaming console.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 29 
>  1 file changed, 29 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c 
> b/drivers/gpu/drm/panel/panel-simple.c
> index 28fa6ba7b767..8c03f7fe461c 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1378,6 +1378,32 @@ static const struct panel_desc evervision_vgg804821 = {
>   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>  };
>  
> +static const struct drm_display_mode frida_frd350h54004_mode = {
> + .clock = 6777,
> + .hdisplay = 320,
> + .hsync_start = 320 + 70,
> + .hsync_end = 320 + 70 + 50,
> + .htotal = 320 + 70 + 50 + 10,
> + .vdisplay = 240,
> + .vsync_start = 240 + 5,
> + .vsync_end = 240 + 5 + 1,
> + .vtotal = 240 + 5 + 1 + 5,
> + .vrefresh = 60,
> + .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC,
> +};
> +
> +static const struct panel_desc frida_frd350h54004 = {
> + .modes = _frd350h54004_mode,
> + .num_modes = 1,
> + .bpc = 8,
> + .size = {
> + .width = 77,
> + .height = 64,
> + },
> + .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_POSEDGE,
> +};
> +
>  static const struct drm_display_mode foxlink_fl500wvr00_a0t_mode = {
>   .clock = 32260,
>   .hdisplay = 800,

In alphabetic order. frida comes after foxlink.

> @@ -3186,6 +3212,9 @@ static const struct of_device_id platform_of_match[] = {
>   }, {
>   .compatible = "evervision,vgg804821",
>   .data = _vgg804821,
> + }, {
> + .compatible = "frida,frd350h54004",
> + .data = _frd350h54004,
>   }, {
>   .compatible = "foxlink,fl500wvr00-a0t",
>   .data = _fl500wvr00_a0t,
In alphabetic order. frida comes after foxlink.

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

Re: [PATCH 2/3] dt-bindings: panel: Document Frida FRD350H54004 LCD panel

[Sam Ravnborg]

Hi Paul.

On Wed, Nov 20, 2019 at 06:10:26PM +0100, Paul Cercueil wrote:
> Add bindings documentation for the Frida 3.5" (320x240 pixels) 24-bit
> TFT LCD panel.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  .../bindings/display/panel/frida,frd350h54004.txt| 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/frida,frd350h54004.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/frida,frd350h54004.txt 
> b/Documentation/devicetree/bindings/display/panel/frida,frd350h54004.txt
> new file mode 100644
> index ..8428f8b05b93
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/frida,frd350h54004.txt
> @@ -0,0 +1,12 @@
> +Frida 3.5" (320x240 pixels) 24-bit TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "frida,frd350h54004"
> +- power-supply: as specified in the base binding
> +
> +Optional properties:
> +- backlight: as specified in the base binding
> +- enable-gpios: as specified in the base binding
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.

New bindings in meta-schma (yaml) format only.
We are migrating away from the .txt based variants.

Rob has a mega patch so we will soon have a lot of examples to look at.

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

Re: [PATCH 1/3] dt-bindings: vendor-prefixes: Add Shenzhen Frida LCD Co., Ltd.

[Sam Ravnborg]

On Wed, Nov 20, 2019 at 06:10:25PM +0100, Paul Cercueil wrote:
> Add an entry for Shenzhen Frida LCD Co., Ltd.
> 
> Signed-off-by: Paul Cercueil 
Acked-by: Sam Ravnborg 


> ---
>  Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 967e78c5ec0a..9c6e1b42435b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -337,6 +337,8 @@ patternProperties:
>  description: Firefly
>"^focaltech,.*":
>  description: FocalTech Systems Co.,Ltd
> +  "^frida,.*":
> +description: Shenzhen Frida LCD Co., Ltd.
>"^friendlyarm,.*":
>  description: Guangzhou FriendlyARM Computer Tech Co., Ltd
>"^fsl,.*":
> -- 
> 2.24.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] drm/tidss: New driver for TI Keystone platform Display SubSystem

[Sam Ravnborg]

Hi Jyri

> I am not so sure if the DSS go-bit functionality (hw support to commit
> changes to display during next vertical blank) so widely used concept
> that it would make sense to make drm wide helpers to handle it.

The question was the other way around.
I was just wondering if there is some of the present helpers
that the driver can benefit from.
It is not that I found something - it was just a drive-by comment.

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

[Bug 204241] amdgpu fails to resume from suspend

[bugzilla-daemon]

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

--- Comment #39 from m...@cschwarz.com ---
(In reply to Alex Deucher from comment #33)
> (In reply to me from comment #32)
> > @Alex: Didn't have a crash with the old uvd6 patch (attachment 285473
> [details]
> > [details]) so far, but apparently I am just lucky.
> > 
> > Which patch (series?) should I test now?
> 
> Please try attachment 285507 [details].

Can confirm this patch works, 40 days uptime, _many_ suspend-resume cycles, no
problems.

-- 
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: [GIT PULL] Please pull hmm changes

[Linus Torvalds]

On Sat, Nov 30, 2019 at 10:03 AM Linus Torvalds
 wrote:
>
> I'll try to figure the code out, but my initial reaction was "yeah,
> not in my VM".

Why is it ok to sometimes do

WRITE_ONCE(mni->invalidate_seq, cur_seq);

(to pair with the unlocked READ_ONCE), and sometimes then do

mni->invalidate_seq = mmn_mm->invalidate_seq;

My initial guess was that latter is only done at initialization time,
but at least in one case it's done *after* the mni has been added to
the mmn_mm (oh, how I despise those names - I can only repeat: WTF?).

See __mmu_interval_notifier_insert() in the
mmn_mm->active_invalidate_ranges case.

I'm guessing that it doesn't matter, because when inserting the
notifier the sequence number is presumably not used until after the
insertion (and any use though mmn_mm is protected by the
mmn_mm->lock), but it still looks odd to me.

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

Re: [GIT PULL] Please pull hmm changes

[Linus Torvalds]

On Mon, Nov 25, 2019 at 12:42 PM Jason Gunthorpe  wrote:
>
> You will probably be most interested in the patch "mm/mmu_notifier: add an
> interval tree notifier".

I'm trying to read that patch, and I'm completely unable to by the
absolutely *horrid* variable names.

There are zero excuses for names like "mmn_mm". WTF?

I'll try to figure the code out, but my initial reaction was "yeah,
not in my VM".

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

Re: [git pull] mm + drm vmwgfx coherent

[Linus Torvalds]

On Thu, Nov 28, 2019 at 5:15 PM Dave Airlie  wrote:
>
> This is just a separated pull for the mm pagewalking + drm/vmwgfx work
> Thomas did and you were involved in, I've left it separate in case you
> don't feel as comfortable with it as the other stuff.

Thanks, pulled (and the delay wasn't because of me being nervous about
the code, it was just because of turkey and a day of rest afterwards).

And I appreciate the separation - not because I wasn't comfortable
with the final code, but simply because it's a rather different thing
than the usual drm code. Having that as a separate pull and not mixed
up with the regular driver updates is just how I prefer it.

Thanks,

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

[PATCH] drm/bridge: analogix-anx6345: Avoid duplicate -supply suffix

[Torsten Duwe]

of_get_regulator() will unconditionally add "-supply" to form the
property name. This is documented in commit 69511a452e6dc ("map consumer
regulator based on device tree").

Signed-off-by: Torsten Duwe 
---
IMHO that commit message should have ended up somewhere under Documentation/.

--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -712,14 +709,14 @@ static int anx6345_i2c_probe(struct i2c_client *client,
DRM_DEBUG("No panel found\n");
 
/* 1.2V digital core power regulator  */
-   anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12-supply");
+   anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
if (IS_ERR(anx6345->dvdd12)) {
DRM_ERROR("dvdd12-supply not found\n");
return PTR_ERR(anx6345->dvdd12);
}
 
/* 2.5V digital core power regulator  */
-   anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25-supply");
+   anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
if (IS_ERR(anx6345->dvdd25)) {
DRM_ERROR("dvdd25-supply not found\n");
return PTR_ERR(anx6345->dvdd25);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: analogix-anx78xx: Fix drm_dp_link helper removal

[Torsten Duwe]

drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by
and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0]
and the multiply+divide alltogether.

fixes: ff1e8fb68ea06027 ("analogix-anx78xx: Avoid drm_dp_link helpers")
Signed-off-by: Torsten Duwe 
---
Has anybody actually tested ff1e8fb68ea06027 ? I copied that code in good
faith for the anx6345 and changed a few other things simultaneously, and
spent some time wondering why the panel stayed dark.

---
diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
index 41867be03751..864423f59d66 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c
@@ -722,10 +722,9 @@ static int anx78xx_dp_link_training(struct anx78xx 
*anx78xx)
if (err)
return err;
 
-   dpcd[0] = drm_dp_max_link_rate(anx78xx->dpcd);
-   dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
err = regmap_write(anx78xx->map[I2C_IDX_TX_P0],
-  SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
+  SP_DP_MAIN_LINK_BW_SET_REG,
+  anx78xx->dpcd[DP_MAX_LINK_RATE]);
if (err)
return err;
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: analogix-anx6345: Fix drm_dp_link helper removal

[Torsten Duwe]

drm_dp_link_rate_to_bw_code and ...bw_code_to_link_rate simply divide by
and multiply with 27000, respectively. Avoid an overflow in the u8 dpcd[0]
and the multiply+divide alltogether.

fixes: e1cff82c1097bda2478 ("fix anx6345 compilation for v5.5")
Signed-off-by: Torsten Duwe 
---
Same as 78xx before. Code copied over in a rush, not realising
it was broken by itself.

--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -210,10 +210,9 @@ static int anx6345_dp_link_training(struct anx6345 
*anx6345)
if (err)
return err;
 
-   dpcd[0] = drm_dp_max_link_rate(anx6345->dpcd);
-   dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
err = regmap_write(anx6345->map[I2C_IDX_DPTX],
-  SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
+  SP_DP_MAIN_LINK_BW_SET_REG,
+  anx6345->dpcd[DP_MAX_LINK_RATE]);
if (err)
return err;
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 205649] Daisy Chain (MST) Session Crash after Screen Lock Resume

[bugzilla-daemon]

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

--- Comment #1 from Michael Rauch (mich...@rauch.be) ---
Created attachment 286131
  --> https://bugzilla.kernel.org/attachment.cgi?id=286131=edit
Error Messages with Kernel 5.3

Error Messages with Kernel 5.3.

Same behavior as Kernel 5.4, but with more messages in kernel.log.

-- 
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 v1 0/2] Add suppport for rm69299 Visionox panel driver and add devicetree bindings for visionox panel.

[Harigovindan P]

Current patchset adds support for rm69299 visionox panel driver used in MSM 
reference platforms.
The visionox panel driver supports a resolution of 1080x2248 with 4 lanes and 
supports only single DSI mode.

Current patchset is tested on actual panel.

Changes in v1:
-add devicetree bindings for visionox panel.
-Split out panel driver patch from dsi config changes(Rob Clark).
-Remove unrelated code(Stephen Boyd).
-Remove static arrays to make regulator setup
 open coded in probe(Stephen Boyd).
-Remove pre-assigning variables(Stephen Boyd).
-Inline panel_add function into probe(Stephen Boyd).
-Use mipi_dsi_dcs_write directly(Rob Clark).
-Remove qcom_rm69299_1080p_panel_magic_cmds array(Rob Clark).

Harigovindan P (2):
  dt-bindings: display: add sc7180 panel variant
  drm/panel: add support for rm69299 visionox panel driver

 .../bindings/display/visionox,rm69299.txt  |  68 
 drivers/gpu/drm/panel/Kconfig  |   9 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-visionox-rm69299.c | 412 +
 4 files changed, 490 insertions(+)
 create mode 100755 
Documentation/devicetree/bindings/display/visionox,rm69299.txt
 create mode 100755 drivers/gpu/drm/panel/panel-visionox-rm69299.c

-- 
2.7.4

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

[PATCH v3 1/2] dt-bindings: drm: bridge: adv7511: Add ADV7535 support

[Bogdan Togorean]

ADV7535 is a part compatible with ADV7533 but it supports 1080p@60hz and
v1p2 supply is fixed to 1.8V

Signed-off-by: Bogdan Togorean 
Reviewed-by: Laurent Pinchart 
---
 .../bindings/display/bridge/adi,adv7511.txt   | 23 ++-
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 2c887536258c..e8ddec5d9d91 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -1,10 +1,10 @@
-Analog Device ADV7511(W)/13/33 HDMI Encoders
+Analog Device ADV7511(W)/13/33/35 HDMI Encoders
 -
 
-The ADV7511, ADV7511W, ADV7513 and ADV7533 are HDMI audio and video 
transmitters
-compatible with HDMI 1.4 and DVI 1.0. They support color space conversion,
-S/PDIF, CEC and HDCP. ADV7533 supports the DSI interface for input pixels, 
while
-the others support RGB interface.
+The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
+transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
+conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for 
input
+pixels, while the others support RGB interface.
 
 Required properties:
 
@@ -13,6 +13,7 @@ Required properties:
"adi,adv7511w"
"adi,adv7513"
"adi,adv7533"
+   "adi,adv7535"
 
 - reg: I2C slave addresses
   The ADV7511 internal registers are split into four pages exposed through
@@ -52,14 +53,14 @@ The following input format properties are required except 
in "rgb 1x" and
 - bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
   needed only for ADV7511.
 
-The following properties are required for ADV7533:
+The following properties are required for ADV7533 and ADV7535:
 
 - adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
   be one of 1, 2, 3 or 4.
 - a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
 - v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
 - v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
-  either 1.2V or 1.8V.
+  either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
 
 Optional properties:
 
@@ -71,9 +72,9 @@ Optional properties:
 - adi,embedded-sync: The input uses synchronization signals embedded in the
   data stream (similar to BT.656). Defaults to separate H/V synchronization
   signals.
-- adi,disable-timing-generator: Only for ADV7533. Disables the internal timing
-  generator. The chip will rely on the sync signals in the DSI data lanes,
-  rather than generate its own timings for HDMI output.
+- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
+  internal timing generator. The chip will rely on the sync signals in the
+  DSI data lanes, rather than generate its own timings for HDMI output.
 - clocks: from common clock binding: reference to the CEC clock.
 - clock-names: from common clock binding: must be "cec".
 - reg-names : Names of maps with programmable addresses.
@@ -85,7 +86,7 @@ Required nodes:
 The ADV7511 has two video ports. Their connections are modelled using the OF
 graph bindings specified in Documentation/devicetree/bindings/graph.txt.
 
-- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533, the
+- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
   remote endpoint phandle should be a reference to a valid mipi_dsi_host device
   node.
 - Video port 1 for the HDMI output
-- 
2.23.0

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

Re: [PATCH v2] drm/panfrost: Document base field location constraint in panfrost_gem_object

[Alyssa Rosenzweig]

Reviewed-by: Alyssa Rosenzweig 

On Fri, Nov 29, 2019 at 02:56:14PM +0100, Boris Brezillon wrote:
> I've spent hours chasing a memory corruption that was caused by
> insertion of an extra field field before ->base. Let's document the
> fact that base has to be the first field in panfrost_gem_object.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Changes in v2:
> * Use the proper prefix in the subject line
> ---
>  drivers/gpu/drm/panfrost/panfrost_gem.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panfrost/panfrost_gem.h 
> b/drivers/gpu/drm/panfrost/panfrost_gem.h
> index b3517ff9630c..d480261fc177 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_gem.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_gem.h
> @@ -10,6 +10,10 @@
>  struct panfrost_mmu;
>  
>  struct panfrost_gem_object {
> + /*
> +  * Must be the first element because we're using some of the
> +  * drm_gem_shmem helpers.
> +  */
>   struct drm_gem_shmem_object base;
>   struct sg_table *sgts;
>  
> -- 
> 2.23.0
> 


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

[PATCH v3 2/2] drm: bridge: adv7511: Add support for ADV7535

[Bogdan Togorean]

ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
or 1.8V and is configurable in a register.

Signed-off-by: Bogdan Togorean 
---
 drivers/gpu/drm/bridge/adv7511/Kconfig   | 13 ++
 drivers/gpu/drm/bridge/adv7511/Makefile  |  3 +-
 drivers/gpu/drm/bridge/adv7511/adv7511.h | 44 +++-
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 35 ++--
 4 files changed, 32 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/Kconfig 
b/drivers/gpu/drm/bridge/adv7511/Kconfig
index 8a56ff81f4fb..47d4eb9e845d 100644
--- a/drivers/gpu/drm/bridge/adv7511/Kconfig
+++ b/drivers/gpu/drm/bridge/adv7511/Kconfig
@@ -4,8 +4,9 @@ config DRM_I2C_ADV7511
depends on OF
select DRM_KMS_HELPER
select REGMAP_I2C
+   select DRM_MIPI_DSI
help
- Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+ Support for the Analog Device ADV7511(W)/13/33/35 HDMI encoders.
 
 config DRM_I2C_ADV7511_AUDIO
bool "ADV7511 HDMI Audio driver"
@@ -15,16 +16,8 @@ config DRM_I2C_ADV7511_AUDIO
  Support the ADV7511 HDMI Audio interface. This is used in
  conjunction with the AV7511  HDMI driver.
 
-config DRM_I2C_ADV7533
-   bool "ADV7533 encoder"
-   depends on DRM_I2C_ADV7511
-   select DRM_MIPI_DSI
-   default y
-   help
- Support for the Analog Devices ADV7533 DSI to HDMI encoder.
-
 config DRM_I2C_ADV7511_CEC
-   bool "ADV7511/33 HDMI CEC driver"
+   bool "ADV7511/33/35 HDMI CEC driver"
depends on DRM_I2C_ADV7511
select CEC_CORE
default y
diff --git a/drivers/gpu/drm/bridge/adv7511/Makefile 
b/drivers/gpu/drm/bridge/adv7511/Makefile
index b46ebeb35fd4..d8ceb534b51f 100644
--- a/drivers/gpu/drm/bridge/adv7511/Makefile
+++ b/drivers/gpu/drm/bridge/adv7511/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-adv7511-y := adv7511_drv.o
+adv7511-y := adv7511_drv.o adv7533.o
 adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
 adv7511-$(CONFIG_DRM_I2C_ADV7511_CEC) += adv7511_cec.o
-adv7511-$(CONFIG_DRM_I2C_ADV7533) += adv7533.o
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 52b2adfdc877..ed9cfd944098 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -220,6 +220,10 @@
 
 #define ADV7533_REG_CEC_OFFSET 0x70
 
+#define ADV7533_REG_SUPPLY_SELECT  0xe4
+
+#define ADV7533_V1P2_ENABLEBIT(7)
+
 enum adv7511_input_clock {
ADV7511_INPUT_CLOCK_1X,
ADV7511_INPUT_CLOCK_2X,
@@ -320,6 +324,7 @@ struct adv7511_video_config {
 enum adv7511_type {
ADV7511,
ADV7533,
+   ADV7535,
 };
 
 #define ADV7511_MAX_ADDRS 3
@@ -393,7 +398,6 @@ static inline int adv7511_cec_init(struct device *dev, 
struct adv7511 *adv7511)
 }
 #endif
 
-#ifdef CONFIG_DRM_I2C_ADV7533
 void adv7533_dsi_power_on(struct adv7511 *adv);
 void adv7533_dsi_power_off(struct adv7511 *adv);
 void adv7533_mode_set(struct adv7511 *adv, const struct drm_display_mode 
*mode);
@@ -402,44 +406,6 @@ int adv7533_patch_cec_registers(struct adv7511 *adv);
 int adv7533_attach_dsi(struct adv7511 *adv);
 void adv7533_detach_dsi(struct adv7511 *adv);
 int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv);
-#else
-static inline void adv7533_dsi_power_on(struct adv7511 *adv)
-{
-}
-
-static inline void adv7533_dsi_power_off(struct adv7511 *adv)
-{
-}
-
-static inline void adv7533_mode_set(struct adv7511 *adv,
-   const struct drm_display_mode *mode)
-{
-}
-
-static inline int adv7533_patch_registers(struct adv7511 *adv)
-{
-   return -ENODEV;
-}
-
-static inline int adv7533_patch_cec_registers(struct adv7511 *adv)
-{
-   return -ENODEV;
-}
-
-static inline int adv7533_attach_dsi(struct adv7511 *adv)
-{
-   return -ENODEV;
-}
-
-static inline void adv7533_detach_dsi(struct adv7511 *adv)
-{
-}
-
-static inline int adv7533_parse_dt(struct device_node *np, struct adv7511 *adv)
-{
-   return -ENODEV;
-}
-#endif
 
 #ifdef CONFIG_DRM_I2C_ADV7511_AUDIO
 int adv7511_audio_init(struct device *dev, struct adv7511 *adv7511);
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 9e13e466e72c..35595472e771 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -367,7 +367,7 @@ static void adv7511_power_on(struct adv7511 *adv7511)
 */
regcache_sync(adv7511->regmap);
 
-   if (adv7511->type == ADV7533)
+   if (adv7511->type == ADV7533 || adv7511->type == ADV7535)
adv7533_dsi_power_on(adv7511);
adv7511->powered = true;
 }
@@ -387,7 +387,7 @@ static void __adv7511_power_off(struct adv7511 *adv7511)
 static 

Re: [PATCH 0/8] panfrost: Fixes for 5.4

[Alyssa Rosenzweig]

Series acked-by: Alyssa Rosenzweig 

On Fri, Nov 29, 2019 at 02:59:00PM +0100, Boris Brezillon wrote:
> Hello,
> 
> I've recently come to test a 5.4 kernel on a rk3288 platform (T760),
> and, as reported by many people on #panfrost, I've hit a page-fault
> storm when running various GL apps.
> 
> This series tries to address the problems I could spot during my debug
> session, with patch 7 being the most invasive change. I wish I
> could find an easier way to fix the "BO mapping teared down while GPU
> jobs referencing it are in-flight" problem, as I don't like tagging
> complex changes for stable, but this is the best I could come up with.
> 
> Let me know if you have better ideas.
> 
> Regards,
> 
> Boris
> 
> Boris Brezillon (8):
>   drm/panfrost: Make panfrost_job_run() return an ERR_PTR() instead of
> NULL
>   drm/panfrost: Fix a race in panfrost_ioctl_madvise()
>   drm/panfrost: Fix a BO leak in panfrost_ioctl_mmap_bo()
>   drm/panfrost: Fix a race in panfrost_gem_free_object()
>   drm/panfrost: Open/close the perfcnt BO
>   drm/panfrost: Make sure imported/exported BOs are never purged
>   drm/panfrost: Add the panfrost_gem_mapping concept
>   drm/panfrost: Make sure the shrinker does not reclaim referenced BOs
> 
>  drivers/gpu/drm/panfrost/panfrost_drv.c   | 132 +++--
>  drivers/gpu/drm/panfrost/panfrost_gem.c   | 184 +++---
>  drivers/gpu/drm/panfrost/panfrost_gem.h   |  51 -
>  .../gpu/drm/panfrost/panfrost_gem_shrinker.c  |   6 +-
>  drivers/gpu/drm/panfrost/panfrost_job.c   |  22 ++-
>  drivers/gpu/drm/panfrost/panfrost_job.h   |   1 +
>  drivers/gpu/drm/panfrost/panfrost_mmu.c   |  61 +++---
>  drivers/gpu/drm/panfrost/panfrost_mmu.h   |   6 +-
>  drivers/gpu/drm/panfrost/panfrost_perfcnt.c   |  49 +++--
>  drivers/gpu/drm/panfrost/panfrost_perfcnt.h   |   2 +-
>  10 files changed, 416 insertions(+), 98 deletions(-)
> 
> -- 
> 2.23.0
> 


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

Re: [PATCH v1 08/29] dt-bindings: interconnect: tegra: Add initial IDs

[Dmitry Osipenko]

25.11.2019 14:32, Thierry Reding пишет:
> On Thu, Nov 21, 2019 at 08:14:35PM +0300, Dmitry Osipenko wrote:
>> 19.11.2019 19:56, Dmitry Osipenko пишет:
>>> 19.11.2019 09:25, Thierry Reding пишет:
 On Mon, Nov 18, 2019 at 11:02:26PM +0300, Dmitry Osipenko wrote:
> Define interconnect IDs for memory controller (MC), external memory
> controller (EMC), external memory (EMEM) and memory clients of display
> controllers (DC).
>
> Signed-off-by: Dmitry Osipenko 
> ---
>  include/dt-bindings/interconnect/tegra-icc.h | 11 +++
>  1 file changed, 11 insertions(+)
>  create mode 100644 include/dt-bindings/interconnect/tegra-icc.h
>>>
>>>
>>> Hello Thierry,
>>>
 There was a bit of discussion regarding this for a recent patch that I
 was working on, see:

http://patchwork.ozlabs.org/project/linux-tegra/list/?series=140318
>>>
>>> Thank you very much for the link.
>>>
 I'd rather not use an additional set of definitions for this. The memory
 controller already has a set of native IDs for memory clients that I
 think we can reuse for this.
>>>
>>> I missed that it's fine to have multiple ICC connections defined
>>> per-path, at quick glance looks like indeed it should be fine to re-use
>>> MC IDs.
>>
>> Well, it is not quite correct to have multiple connections per-path.
>>
>> Please take look at interconnect's binding and core.c:
>>
>>   1. there should be one src->dst connection per-path
>>   2. each connection should comprise of one source and one destination nodes
>>
 I've only added these client IDs for Tegra194 because that's where we
 need it to actually describe a specific hardware quirk, but I can come
 up with the equivalent for older chips as well.
>>>
>>> Older Tegra SoCs have hardware units connected to MC through AHB bus,
>>> like USB for example. These units do not have MC client IDs and there is
>>> no MC ID defined for the AHB bus either, but probably it won't be a
>>> problem to define IDs for them if will be necessary.
>>>
>>
>> Since interconnect binding requires to define both source and
>> destination nodes for the path, then MC IDs are not enough in order to
>> define interconnect path because these IDs represent only the source
>> nodes. Destination node should be either EMC or EMEM.
> 
> This doesn't really map well to Tegra. The source of the path is always
> the device and the destination is always the memory controller. We also
> can have multiple paths between a device and the memory controller. The
> typical case is to have at least a read and a write path, but there are
> a number of devices that have multiple read and/or multiple write paths
> to the memory controller.
> 
> Or perhaps I'm looking at this the wrong way, and what we really ought
> to describe is the paths with MC sitting in the middle. So it'd be
> something like:
> 
>   MC ID --- source ---> MC --- destination ---> EMC

Yes, this should be correct.

> for write paths and:
> 
>   EMC --- source ---> MC --- destination ---> MC ID

Both write and read paths have the same direction in terms of
interconnect API. The source node requests bandwidth from the
destination node, where source is memory client and destination is EMC/EMEM.

> for read paths. I have no idea what would be a good connection ID for
> EMC, since I don't think MC really differentiates at that level. Perhaps
> #interconnect-cells = <0> for EMC would be appropriate.

It should be fine to define ICC ID for EMC that doesn't overlap with the
memory client IDs, say #1000.

> This would make the bindings look more like this, taking a random sample
> from the above series:
> 
>   ethernet@249 {
>   ...
>   interconnects = <  TEGRA194_MEMORY_CLIENT_EQOSR>,
>   < TEGRA194_MEMORY_CLIENT_EQOSW >;
>   interconnect-names = "dma-mem", "dma-mem";
>   ...
>   };
> 
> In words, the above would mean that for the ethernet device there is one
> path (a read slave interface) where data flows from the EMC through the
> MC to the device with memory client ID TEGRA194_MEMORY_CLIENT_EQOSR. The
> second path (a write slave interface) describes data flowing from the
> device (with memory client ID TEGRA194_MEMORY_CLIENT_EQOSW) through the
> MC and towards the EMC.
> 
> Irrespective of the above, I think we definitely need to keep separate
> IDs for read and write paths because each of them have separate controls
> for arbitration and latency allowance. So each of those may need to be
> separately configurable.
> 
> Does that make sense?

I'll try to update this series to use ICC-path per display plane and see
how it goes.

In general, looks like should be fine to have ICC paths defined per
memory client.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/dp_mst: Fix W=1 warnings

[Benjamin Gaignard]

Fix the warnings that show up with W=1.
They are all about unused but set variables.
If functions returns are not used anymore make them void.

Signed-off-by: Benjamin Gaignard 
---
CC: Jani Nikula 

changes in version 3:
- remove the hunk that may conflict with c485e2c97dae 
  ("drm/dp_mst: Refactor pdt setup/teardown, add more locking")

changes in version 2:
- fix indentations
- when possible change functions prototype to void

drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
 1 file changed, 31 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 1437bc46368b..d5cb5688b5dd 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -674,7 +674,6 @@ static bool drm_dp_sideband_msg_build(struct 
drm_dp_sideband_msg_rx *msg,
  u8 *replybuf, u8 replybuflen, bool hdr)
 {
int ret;
-   u8 crc4;
 
if (hdr) {
u8 hdrlen;
@@ -716,8 +715,6 @@ static bool drm_dp_sideband_msg_build(struct 
drm_dp_sideband_msg_rx *msg,
}
 
if (msg->curchunk_idx >= msg->curchunk_len) {
-   /* do CRC */
-   crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
/* copy chunk into bigger msg */
memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len - 
1);
msg->curlen += msg->curchunk_len - 1;
@@ -1014,7 +1011,7 @@ static bool drm_dp_sideband_parse_req(struct 
drm_dp_sideband_msg_rx *raw,
}
 }
 
-static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 port_num, 
u32 offset, u8 num_bytes, u8 *bytes)
+static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 port_num, 
u32 offset, u8 num_bytes, u8 *bytes)
 {
struct drm_dp_sideband_msg_req_body req;
 
@@ -1024,17 +1021,14 @@ static int build_dpcd_write(struct 
drm_dp_sideband_msg_tx *msg, u8 port_num, u32
req.u.dpcd_write.num_bytes = num_bytes;
req.u.dpcd_write.bytes = bytes;
drm_dp_encode_sideband_req(, msg);
-
-   return 0;
 }
 
-static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
+static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
 {
struct drm_dp_sideband_msg_req_body req;
 
req.req_type = DP_LINK_ADDRESS;
drm_dp_encode_sideband_req(, msg);
-   return 0;
 }
 
 static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, int 
port_num)
@@ -1048,7 +1042,7 @@ static int build_enum_path_resources(struct 
drm_dp_sideband_msg_tx *msg, int por
return 0;
 }
 
-static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
port_num,
+static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
port_num,
  u8 vcpi, uint16_t pbn,
  u8 number_sdp_streams,
  u8 *sdp_stream_sink)
@@ -1064,10 +1058,9 @@ static int build_allocate_payload(struct 
drm_dp_sideband_msg_tx *msg, int port_n
   number_sdp_streams);
drm_dp_encode_sideband_req(, msg);
msg->path_msg = true;
-   return 0;
 }
 
-static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
+static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
  int port_num, bool power_up)
 {
struct drm_dp_sideband_msg_req_body req;
@@ -1080,7 +1073,6 @@ static int build_power_updown_phy(struct 
drm_dp_sideband_msg_tx *msg,
req.u.port_num.port_number = port_num;
drm_dp_encode_sideband_req(, msg);
msg->path_msg = true;
-   return 0;
 }
 
 static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
@@ -1746,14 +1738,13 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port 
*port,
  */
 static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
 {
-   int ret;
u8 rad[6], lct;
bool send_link = false;
switch (port->pdt) {
case DP_PEER_DEVICE_DP_LEGACY_CONV:
case DP_PEER_DEVICE_SST_SINK:
/* add i2c over sideband */
-   ret = drm_dp_mst_register_i2c_bus(>aux);
+   drm_dp_mst_register_i2c_bus(>aux);
break;
case DP_PEER_DEVICE_MST_BRANCHING:
lct = drm_dp_calculate_rad(port, rad);
@@ -1823,25 +1814,20 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
 
 static void drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, u8 *guid)
 {
-   int ret;
-
memcpy(mstb->guid, guid, 16);
 
if (!drm_dp_validate_guid(mstb->mgr, mstb->guid)) {
if (mstb->port_parent) {
-   ret = drm_dp_send_dpcd_write(
-   mstb->mgr,
-   mstb->port_parent,
-   DP_GUID,
- 

Re: [PATCH 0/2] drm/i915/vlv_dsi: Control panel and backlight enable GPIOs on BYT

[Andy Shevchenko]

On Fri, Nov 29, 2019 at 07:58:34PM +0100, Hans de Goede wrote:
> Hi All,
> 
> On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
> do not control the LCD panel- and backlight-enable GPIOs. So far, when
> the VBT indicates we should use the SoC for backlight control, we have
> been relying on these GPIOs being configured as output and driven high by
> the Video BIOS (GOP) when it initializes the panel.
> 
> This does not work when the device is booted with a HDMI monitor connected
> as then the GOP will initialize the HDMI instead of the panel, leaving the
> panel black, even though the i915 driver tries to output an image to it.
> 
> Likewise on some device-models when the GOP does not initialize the DSI
> panel it also leaves the mux of the PWM0 pin in generic GPIO mode instead
> of muxing it to the PWM controller.
> 
> This series contains 2 patches which together fix this.
> 
> To avoid new errors in the intel-gfx CI (assuming there is atleast 1
> BYT device there with a DSI panel), we need both of these patches to
> be merged through the drm-intel tree.
> 
> Unfortunately there is some churn currently going on in the
> pinctrl-baytrail.c code, but not in the part of the file which this
> touches, so merging the pinctrl-baytrail.c changes through the
> drm-intel tree should not lead to conflicts later.
> 
> Andy, Mika, assuming you are happy with the changes, can I get your ack
> for merging the pinctrl-baytrail patch throught the drm-inteol tree?

I'm not okay with this. I will tell more next week how I see this to be
implemented in a better way.

Happy Black Friday! :-)

-- 
With Best Regards,
Andy Shevchenko


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

Re: [PATCH v11 4/7] drm/sun4i: dsi: Handle bus clock explicitly

[Maxime Ripard]

On Sat, Nov 23, 2019 at 01:20:21AM +0530, Jagan Teki wrote:
> > > Please have a look at this snippet, I have used your second
> > > suggestions. let me know if you have any comments?
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > index 8fa90cfc2ac8..91c95e56d870 100644
> > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > @@ -1109,24 +1109,36 @@ static int sun6i_dsi_probe(struct platform_device 
> > > *pdev)
> > >  return PTR_ERR(dsi->regulator);
> > >  }
> > >
> > > -dsi->regs = devm_regmap_init_mmio_clk(dev, "bus", base,
> > > -  _dsi_regmap_config);
> > > -if (IS_ERR(dsi->regs)) {
> > > -dev_err(dev, "Couldn't create the DSI encoder regmap\n");
> > > -return PTR_ERR(dsi->regs);
> > > -}
> > > -
> > >  dsi->reset = devm_reset_control_get_shared(dev, NULL);
> > >  if (IS_ERR(dsi->reset)) {
> > >  dev_err(dev, "Couldn't get our reset line\n");
> > >  return PTR_ERR(dsi->reset);
> > >  }
> > >
> > > +dsi->regs = regmap_init_mmio(dev, base, _dsi_regmap_config);
> >
> > You should use the devm variant here
>
> Sure.
>
> >
> > > +if (IS_ERR(dsi->regs)) {
> > > +dev_err(dev, "Couldn't init regmap\n");
> > > +return PTR_ERR(dsi->regs);
> > > +}
> > > +
> > > +dsi->bus_clk = devm_clk_get(dev, NULL);
> >
> > I guess you still need to pass 'bus' here?
>
> But the idea here is not to specify clock name explicitly to support
> A64. otherwise A64 would fail as we are not specifying the clock-names
> explicitly on dsi node.

Right. But you have no guarantee that the bus clock is going to be the
first one on the other SoCs either.

What about something like that instead:

char *clk_name = NULL;
if (dsi->has_mod_clk)
clk_name = "bus";

clk = devm_clk_get(dev, clk_name);
if (IS_ERR(clk))
return PTR_ERR(clk));

regmap_mmio_attach_clk(regmap, clk);

>
> dsi: dsi@1ca {
>compatible = "allwinner,sun50i-a64-mipi-dsi";
>reg = <0x01ca 0x1000>;
>interrupts = ;
>clocks = < CLK_BUS_MIPI_DSI>;
>resets = < RST_BUS_MIPI_DSI>;
>   phys = <>;
>   phy-names = "dphy";
> .
> };
>
> >
> > > +if (IS_ERR(dsi->bus_clk)) {
> > > +dev_err(dev, "Couldn't get the DSI bus clock\n");
> > > +ret = PTR_ERR(dsi->bus_clk);
> > > +goto err_regmap;
> > > +} else {
> > > +printk("Jagan.. Got the BUS clock\n");
> > > +ret = regmap_mmio_attach_clk(dsi->regs, dsi->bus_clk);
> > > +if (ret)
> > > +goto err_bus_clk;
> > > +}
> > > +
> > >  if (dsi->variant->has_mod_clk) {
> > >  dsi->mod_clk = devm_clk_get(dev, "mod");
> > >  if (IS_ERR(dsi->mod_clk)) {
> > >  dev_err(dev, "Couldn't get the DSI mod clock\n");
> > > -return PTR_ERR(dsi->mod_clk);
> > > +ret = PTR_ERR(dsi->mod_clk);
> > > +goto err_attach_clk;
> > >  }
> > >  }
> > >
> > > @@ -1167,6 +1179,14 @@ static int sun6i_dsi_probe(struct platform_device 
> > > *pdev)
> > >  err_unprotect_clk:
> > >  if (dsi->variant->has_mod_clk)
> > >  clk_rate_exclusive_put(dsi->mod_clk);
> > > +err_attach_clk:
> > > +if (!IS_ERR(dsi->bus_clk))
> > > +regmap_mmio_detach_clk(dsi->regs);
> > > +err_bus_clk:
> > > +if (!IS_ERR(dsi->bus_clk))
> > > +clk_put(dsi->bus_clk);
> > > +err_regmap:
> > > +regmap_exit(dsi->regs);
> > >  return ret;
> > >  }
> > >
> > > @@ -1181,6 +1201,13 @@ static int sun6i_dsi_remove(struct platform_device 
> > > *pdev)
> > >  if (dsi->variant->has_mod_clk)
> > >  clk_rate_exclusive_put(dsi->mod_clk);
> > >
> > > +if (!IS_ERR(dsi->bus_clk)) {
> > > +regmap_mmio_detach_clk(dsi->regs);
> > > +clk_put(dsi->bus_clk);
> >
> > This will trigger a warning, you put down the reference twice
>
> You mean regmap_mmio_detach_clk will put the clk?

No, devm_clk_get will.

Maxime


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

[PATCH v1 1/2] dt-bindings: display: add sc7180 panel variant

[Harigovindan P]

Add a compatible string to support sc7180 panel version.

Signed-off-by: Harigovindan P 
---
 .../bindings/display/visionox,rm69299.txt  | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100755 
Documentation/devicetree/bindings/display/visionox,rm69299.txt

diff --git a/Documentation/devicetree/bindings/display/visionox,rm69299.txt 
b/Documentation/devicetree/bindings/display/visionox,rm69299.txt
new file mode 100755
index 000..4622191
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/visionox,rm69299.txt
@@ -0,0 +1,68 @@
+Visionox model RM69299 DSI display driver
+
+The Visionox RM69299 is a generic display driver, currently only configured
+for use in the 1080p display on the Qualcomm SC7180 MTP board.
+
+Required properties:
+- compatible: should be "visionox,rm69299-1080p-display"
+- vdda-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply
+- vdd3p3-supply: phandle of the regulator that provides the supply voltage
+  Power IC supply
+- reset-gpios: phandle of gpio for reset line
+  This should be 8mA, gpio can be configured using mux, pinctrl, pinctrl-names
+  (active low)
+- mode-gpios: phandle of the gpio for choosing the mode of the display
+  for single DSI
+- ports: This device has one video port driven by one DSI. Their connections
+  are modeled using the OF graph bindings specified in
+  Documentation/devicetree/bindings/graph.txt.
+  - port@0: DSI input port driven by master DSI
+
+Example:
+
+   dsi@ae94000 {
+   panel@0 {
+   compatible = "visionox,rm69299-1080p-display";
+   reg = <0>;
+
+   vdda-supply = <_pp1800_l8c>;
+   vdd3p3-supply = <_pp2800_l18a>;
+
+   pinctrl-names = "default", "suspend";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_default>;
+
+   reset-gpios = <_gpios 3 0>;
+
+   display-timings {
+   timing0: timing-0 {
+   /* originally
+* 268316160 Mhz,
+* but value below fits
+* better w/ downstream
+*/
+   clock-frequency = <158695680>;
+   hactive = <1080>;
+   vactive = <2248>;
+   hfront-porch = <26>;
+   hback-porch = <36>;
+   hsync-len = <2>;
+   vfront-porch = <56>;
+   vback-porch = <4>;
+   vsync-len = <4>;
+   };
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   panel0_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+   };
-- 
2.7.4

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

[PATCH v1 2/2] drm/panel: add support for rm69299 visionox panel driver

[Harigovindan P]

Add support for Visionox panel driver.

Changes in v1:
-Split out panel driver patch from dsi config changes(Rob Clark).
-Remove unrelated code(Stephen Boyd).
-Remove static arrays to make regulator setup open coded
 in probe(Stephen Boyd).
-Remove pre-assigning variables(Stephen Boyd).
-Inline panel_add function into probe(Stephen Boyd).
-Use mipi_dsi_dcs_write directly(Rob Clark).
-Remove qcom_rm69299_1080p_panel_magic_cmds array(Rob Clark).

Signed-off-by: Harigovindan P 
---
 drivers/gpu/drm/panel/Kconfig  |   9 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-visionox-rm69299.c | 412 +
 3 files changed, 422 insertions(+)
 create mode 100755 drivers/gpu/drm/panel/panel-visionox-rm69299.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index f152bc4..c06c403 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -355,4 +355,13 @@ config DRM_PANEL_TRULY_NT35597_WQXGA
help
  Say Y here if you want to enable support for Truly NT35597 WQXGA Dual 
DSI
  Video Mode panel
+
+config DRM_PANEL_VISIONOX_RM69299
+   tristate "Visionox RM69299"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Visionox
+ RM69299  DSI Video Mode panel.
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index b6cd39f..6f1e4c6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += 
panel-tpo-td028ttec1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
 obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
 obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c 
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
new file mode 100755
index 000..da86714
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, The Linux Foundation. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct rm69299_config {
+   unsigned long width_mm;
+   unsigned long height_mm;
+   const char *panel_name;
+   u32 num_on_cmds;
+   const struct drm_display_mode *dm;
+};
+
+struct visionox_rm69299 {
+   struct device *dev;
+   struct drm_panel panel;
+
+   struct regulator_bulk_data supplies[2];
+
+   struct gpio_desc *reset_gpio;
+
+   struct backlight_device *backlight;
+
+   struct mipi_dsi_device *dsi;
+   const struct rm69299_config *config;
+   bool prepared;
+   bool enabled;
+};
+
+static inline struct visionox_rm69299 *panel_to_ctx(struct drm_panel *panel)
+{
+   return container_of(panel, struct visionox_rm69299, panel);
+}
+
+static int visionox_35597_power_on(struct visionox_rm69299 *ctx)
+{
+   int ret;
+
+   ret = regulator_set_load(ctx->supplies[0].consumer, 32000);
+   if (ret)
+   return ret;
+
+   ret = regulator_set_load(ctx->supplies[1].consumer, 13200);
+   if (ret)
+   return ret;
+
+   ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+   if (ret < 0)
+   return ret;
+
+   /*
+* Reset sequence of visionox panel requires the panel to be
+* out of reset for 10ms, followed by being held in reset
+* for 10ms and then out again
+*/
+   gpiod_set_value(ctx->reset_gpio, 1);
+   usleep_range(1, 2);
+   gpiod_set_value(ctx->reset_gpio, 0);
+   usleep_range(1, 2);
+   gpiod_set_value(ctx->reset_gpio, 1);
+   usleep_range(1, 2);
+
+   return 0;
+}
+
+static int visionox_rm69299_power_off(struct visionox_rm69299 *ctx)
+{
+   int ret;
+
+   gpiod_set_value(ctx->reset_gpio, 0);
+
+   ret = regulator_set_load(ctx->supplies[0].consumer, 80);
+
+   if (ret) {
+   DRM_DEV_ERROR(ctx->dev,
+   "regulator_set_load failed %d\n", ret);
+   return ret;
+   }
+
+   ret = regulator_set_load(ctx->supplies[1].consumer, 80);
+
+   if (ret) {
+   DRM_DEV_ERROR(ctx->dev,
+   "regulator_set_load failed %d\n", ret);
+   return ret;
+   }
+
+   ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
+   if (ret) {
+   DRM_DEV_ERROR(ctx->dev,
+   "regulator_bulk_disable failed %d\n", ret);
+   }
+   return ret;
+}
+
+static int visionox_rm69299_disable(struct drm_panel *panel)
+{
+  

[PATCH v1] drm/msm: add support for 2.4.1 DSI version for sc7180 soc

[Harigovindan P]

Changes in v1:
-Modify commit text to indicate DSI version and SOC detail(Jeffrey 
Hugo).
-Splitting visionox panel driver code out into a
 different patch(set), since panel drivers are merged into
 drm-next via a different tree(Rob Clark).

Signed-off-by: Harigovindan P 
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 21 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index b7b7c1a..7b967dd 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -133,6 +133,10 @@ static const char * const dsi_sdm845_bus_clk_names[] = {
"iface", "bus",
 };
 
+static const char * const dsi_sc7180_bus_clk_names[] = {
+   "iface", "bus",
+};
+
 static const struct msm_dsi_config sdm845_dsi_cfg = {
.io_offset = DSI_6G_REG_SHIFT,
.reg_cfg = {
@@ -147,6 +151,20 @@ static const struct msm_dsi_config sdm845_dsi_cfg = {
.num_dsi = 2,
 };
 
+static const struct msm_dsi_config sc7180_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 1,
+   .regs = {
+   {"vdda", 21800, 4 },/* 1.2 V */
+   },
+   },
+   .bus_clk_names = dsi_sc7180_bus_clk_names,
+   .num_bus_clks = ARRAY_SIZE(dsi_sc7180_bus_clk_names),
+   .io_start = { 0xae94000 },
+   .num_dsi = 1,
+};
+
 const static struct msm_dsi_host_cfg_ops msm_dsi_v2_host_ops = {
.link_clk_enable = dsi_link_clk_enable_v2,
.link_clk_disable = dsi_link_clk_disable_v2,
@@ -201,6 +219,9 @@ static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] 
= {
_dsi_cfg, _dsi_6g_v2_host_ops},
{MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1,
_dsi_cfg, _dsi_6g_v2_host_ops},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_4_1,
+   _dsi_cfg, _dsi_6g_v2_host_ops},
+
 };
 
 const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
index e2b7a7d..9919536 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.h
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -19,6 +19,7 @@
 #define MSM_DSI_6G_VER_MINOR_V1_4_10x10040001
 #define MSM_DSI_6G_VER_MINOR_V2_2_00x2000
 #define MSM_DSI_6G_VER_MINOR_V2_2_10x20020001
+#define MSM_DSI_6G_VER_MINOR_V2_4_10x20040001
 
 #define MSM_DSI_V2_VER_MINOR_8064  0x0
 
-- 
2.7.4

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

[PATCH v6 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

[Xin Ji]

The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI DSI/DPI to DisplayPort 1.3 4K.

The ANX7625 can support both USB Type-C PD feature and MIPI DSI/DPI
to DP feature. This driver only enabled MIPI DSI/DPI to DP feature.

Signed-off-by: Xin Ji 
---
 drivers/gpu/drm/bridge/Makefile   |2 +-
 drivers/gpu/drm/bridge/analogix/Kconfig   |6 +
 drivers/gpu/drm/bridge/analogix/Makefile  |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c | 2045 +
 drivers/gpu/drm/bridge/analogix/anx7625.h |  406 ++
 5 files changed, 2459 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 4934fcf..bcd388a 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -12,8 +12,8 @@ obj-$(CONFIG_DRM_SII9234) += sii9234.o
 obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358764) += tc358764.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
-obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
 obj-$(CONFIG_DRM_TI_SN65DSI86) += ti-sn65dsi86.o
 obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
+obj-y += analogix/
 obj-y += synopsys/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
index e930ff9..b2f127e 100644
--- a/drivers/gpu/drm/bridge/analogix/Kconfig
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -2,3 +2,9 @@
 config DRM_ANALOGIX_DP
tristate
depends on DRM
+
+config ANALOGIX_ANX7625
+   tristate "Analogix MIPI to DP interface support"
+   help
+   ANX7625 is an ultra-low power 4K mobile HD transmitter designed
+   for portable devices. It converts MIPI/DPI to DisplayPort1.3 4K.
diff --git a/drivers/gpu/drm/bridge/analogix/Makefile 
b/drivers/gpu/drm/bridge/analogix/Makefile
index fdbf3fd..8a52867 100644
--- a/drivers/gpu/drm/bridge/analogix/Makefile
+++ b/drivers/gpu/drm/bridge/analogix/Makefile
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
+obj-$(CONFIG_ANALOGIX_ANX7625) += anx7625.o
 analogix_dp-objs := analogix_dp_core.o analogix_dp_reg.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix_dp.o
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
new file mode 100644
index 000..737f4a3
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -0,0 +1,2045 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2016, Analogix Semiconductor. All rights reserved.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "anx7625.h"
+
+/*
+ * there is a sync issue while access I2C register between AP(CPU) and
+ * internal firmware(OCM), to avoid the race condition, AP should access
+ * the reserved slave address before slave address occurs changes.
+ */
+static int i2c_access_workaround(struct anx7625_data *ctx,
+struct i2c_client *client)
+{
+   u8 offset;
+   struct device *dev = >dev;
+   int ret;
+
+   if (client == ctx->last_client)
+   return 0;
+
+   ctx->last_client = client;
+
+   if (client == ctx->i2c.tcpc_client)
+   offset = RSVD_00_ADDR;
+   else if (client == ctx->i2c.tx_p0_client)
+   offset = RSVD_D1_ADDR;
+   else if (client == ctx->i2c.tx_p1_client)
+   offset = RSVD_60_ADDR;
+   else if (client == ctx->i2c.rx_p0_client)
+   offset = RSVD_39_ADDR;
+   else if (client == ctx->i2c.rx_p1_client)
+   offset = RSVD_7F_ADDR;
+   else
+   offset = RSVD_00_ADDR;
+
+   ret = i2c_smbus_write_byte_data(client, offset, 0x00);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev,
+ "failed to access i2c id=%x\n:%x",
+ client->addr, offset);
+
+   return ret;
+}
+
+static int anx7625_reg_read(struct anx7625_data *ctx,
+   struct i2c_client *client, u8 reg_addr)
+{
+   int ret;
+   struct device *dev = >dev;
+
+   i2c_access_workaround(ctx, client);
+
+   ret = i2c_smbus_read_byte_data(client, reg_addr);
+   if (ret < 0)
+   DRM_DEV_ERROR(dev, "read i2c failed id=%x:%x\n",
+ client->addr, reg_addr);
+
+   return ret;
+}
+
+static int anx7625_reg_block_read(struct anx7625_data *ctx,
+ struct i2c_client *client,
+ u8 reg_addr, u8 len, u8 *buf)
+{
+   int ret;
+   struct device *dev 

Re: [PATCH v2 14/14] auxdisplay: constify fb ops

[Miguel Ojeda]

On Fri, Nov 29, 2019 at 9:30 PM Daniel Vetter  wrote:
>
> Well we do have very small lcd display drivers in drm, and before that in
> fbdev. And you have a fbdev framebuffer driver in there, which looks a bit
> misplaced ...
>
> Afaiui you also have some even tinier lcd drivers where you don't address
> pixels, but just directly upload text, and those obviously don't fit into
> drm/fbdev world. But anything where you can address pixels very much does.
> -Daniel

The first driver in the category used fb.h. At the time (~13 years
ago) it was decided that the drivers should go into a different
category/folder instead and then the other were added.

In any case, I am removing the original ones since I cannot test them
anymore and there are likely no user. The only other fb user could be
relocated if Robin agrees.

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

BUG: unable to handle kernel paging request in ion_heap_clear_pages

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:419593da Add linux-next specific files for 20191129
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12bfd882e0
kernel config:  https://syzkaller.appspot.com/x/.config?x=7c04b0959e75c206
dashboard link: https://syzkaller.appspot.com/bug?extid=be6ccf3081ce8afd1b56
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+be6ccf3081ce8afd1...@syzkaller.appspotmail.com

BUG: unable to handle page fault for address: f52002e0
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 21ffee067 P4D 21ffee067 PUD aa11c067 PMD 0
Oops:  [#1] PREEMPT SMP KASAN
CPU: 0 PID: 3644 Comm: ion_system_heap Not tainted  
5.4.0-next-20191129-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline]
RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline]
RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192
Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e  
8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74  
ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80

RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212
RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229
RDX: 0001 RSI: b000 RDI: c9001700
RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600
R10: f52002e015ff R11: c9001700afff R12: f52002e0
R13: b000 R14:  R15: c9000c9f7d08
FS:  () GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: f52002e0 CR3: 778bd000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 memset+0x24/0x40 mm/kasan/common.c:107
 memset include/linux/string.h:410 [inline]
 ion_heap_clear_pages+0x49/0x70 drivers/staging/android/ion/ion_heap.c:106
 ion_heap_sglist_zero+0x245/0x270 drivers/staging/android/ion/ion_heap.c:130
 ion_heap_buffer_zero+0xf5/0x150 drivers/staging/android/ion/ion_heap.c:145
 ion_system_heap_free+0x1eb/0x250  
drivers/staging/android/ion/ion_system_heap.c:163

 ion_buffer_destroy+0x159/0x2d0 drivers/staging/android/ion/ion.c:93
 ion_heap_deferred_free+0x29d/0x630  
drivers/staging/android/ion/ion_heap.c:239

 kthread+0x361/0x430 kernel/kthread.c:255
 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Modules linked in:
CR2: f52002e0
---[ end trace ee5c63907f1d6f00 ]---
RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline]
RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline]
RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline]
RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline]
RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192
Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e  
8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74  
ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80

RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212
RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229
RDX: 0001 RSI: b000 RDI: c9001700
RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600
R10: f52002e015ff R11: c9001700afff R12: f52002e0
R13: b000 R14:  R15: c9000c9f7d08
FS:  () GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: f52002e0 CR3: 778bd000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/dp_mst: Fix W=1 warnings

[Benjamin Gaignard]

Fix the warnings that show up with W=1.
They are all about unused but set variables.
If functions returns are not used anymore make them void.

Signed-off-by: Benjamin Gaignard 
CC: Jani Nikula 
---
changes in version 2:
- fix indentations
- when possible change functions prototype to void

Note: this patch may conflict with c485e2c97dae ("drm/dp_mst: Refactor pdt
setup/teardown, add more locking") when it will hit drm-misc-next

 drivers/gpu/drm/drm_dp_mst_topology.c | 83 +--
 1 file changed, 31 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index b854a422a523..ff2d81db0778 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -672,7 +672,6 @@ static bool drm_dp_sideband_msg_build(struct 
drm_dp_sideband_msg_rx *msg,
  u8 *replybuf, u8 replybuflen, bool hdr)
 {
int ret;
-   u8 crc4;
 
if (hdr) {
u8 hdrlen;
@@ -714,8 +713,6 @@ static bool drm_dp_sideband_msg_build(struct 
drm_dp_sideband_msg_rx *msg,
}
 
if (msg->curchunk_idx >= msg->curchunk_len) {
-   /* do CRC */
-   crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
/* copy chunk into bigger msg */
memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len - 
1);
msg->curlen += msg->curchunk_len - 1;
@@ -1012,7 +1009,7 @@ static bool drm_dp_sideband_parse_req(struct 
drm_dp_sideband_msg_rx *raw,
}
 }
 
-static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 port_num, 
u32 offset, u8 num_bytes, u8 *bytes)
+static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 port_num, 
u32 offset, u8 num_bytes, u8 *bytes)
 {
struct drm_dp_sideband_msg_req_body req;
 
@@ -1022,17 +1019,14 @@ static int build_dpcd_write(struct 
drm_dp_sideband_msg_tx *msg, u8 port_num, u32
req.u.dpcd_write.num_bytes = num_bytes;
req.u.dpcd_write.bytes = bytes;
drm_dp_encode_sideband_req(, msg);
-
-   return 0;
 }
 
-static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
+static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
 {
struct drm_dp_sideband_msg_req_body req;
 
req.req_type = DP_LINK_ADDRESS;
drm_dp_encode_sideband_req(, msg);
-   return 0;
 }
 
 static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, int 
port_num)
@@ -1046,7 +1040,7 @@ static int build_enum_path_resources(struct 
drm_dp_sideband_msg_tx *msg, int por
return 0;
 }
 
-static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
port_num,
+static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
port_num,
  u8 vcpi, uint16_t pbn,
  u8 number_sdp_streams,
  u8 *sdp_stream_sink)
@@ -1062,10 +1056,9 @@ static int build_allocate_payload(struct 
drm_dp_sideband_msg_tx *msg, int port_n
   number_sdp_streams);
drm_dp_encode_sideband_req(, msg);
msg->path_msg = true;
-   return 0;
 }
 
-static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
+static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
  int port_num, bool power_up)
 {
struct drm_dp_sideband_msg_req_body req;
@@ -1078,7 +1071,6 @@ static int build_power_updown_phy(struct 
drm_dp_sideband_msg_tx *msg,
req.u.port_num.port_number = port_num;
drm_dp_encode_sideband_req(, msg);
msg->path_msg = true;
-   return 0;
 }
 
 static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr *mgr,
@@ -1744,14 +1736,13 @@ static u8 drm_dp_calculate_rad(struct drm_dp_mst_port 
*port,
  */
 static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
 {
-   int ret;
u8 rad[6], lct;
bool send_link = false;
switch (port->pdt) {
case DP_PEER_DEVICE_DP_LEGACY_CONV:
case DP_PEER_DEVICE_SST_SINK:
/* add i2c over sideband */
-   ret = drm_dp_mst_register_i2c_bus(>aux);
+   drm_dp_mst_register_i2c_bus(>aux);
break;
case DP_PEER_DEVICE_MST_BRANCHING:
lct = drm_dp_calculate_rad(port, rad);
@@ -1821,25 +1812,20 @@ ssize_t drm_dp_mst_dpcd_write(struct drm_dp_aux *aux,
 
 static void drm_dp_check_mstb_guid(struct drm_dp_mst_branch *mstb, u8 *guid)
 {
-   int ret;
-
memcpy(mstb->guid, guid, 16);
 
if (!drm_dp_validate_guid(mstb->mgr, mstb->guid)) {
if (mstb->port_parent) {
-   ret = drm_dp_send_dpcd_write(
-   mstb->mgr,
-   mstb->port_parent,
-   DP_GUID,
- 

Re: BUG: unable to handle kernel paging request in ion_heap_clear_pages

[Dmitry Vyukov]

On Sat, Nov 30, 2019 at 8:59 AM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:419593da Add linux-next specific files for 20191129
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12bfd882e0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=7c04b0959e75c206
> dashboard link: https://syzkaller.appspot.com/bug?extid=be6ccf3081ce8afd1b56
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+be6ccf3081ce8afd1...@syzkaller.appspotmail.com

+Daniel, kasan-dev
This is presumably from the new CONFIG_KASAN_VMALLOC and should be:
#syz fix: kasan: support vmalloc backing of vm_map_ram()


> BUG: unable to handle page fault for address: f52002e0
> #PF: supervisor read access in kernel mode
> #PF: error_code(0x) - not-present page
> PGD 21ffee067 P4D 21ffee067 PUD aa11c067 PMD 0
> Oops:  [#1] PREEMPT SMP KASAN
> CPU: 0 PID: 3644 Comm: ion_system_heap Not tainted
> 5.4.0-next-20191129-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline]
> RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline]
> RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline]
> RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline]
> RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192
> Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e
> 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74
> ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80
> RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212
> RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229
> RDX: 0001 RSI: b000 RDI: c9001700
> RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600
> R10: f52002e015ff R11: c9001700afff R12: f52002e0
> R13: b000 R14:  R15: c9000c9f7d08
> FS:  () GS:8880ae60() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: f52002e0 CR3: 778bd000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>   memset+0x24/0x40 mm/kasan/common.c:107
>   memset include/linux/string.h:410 [inline]
>   ion_heap_clear_pages+0x49/0x70 drivers/staging/android/ion/ion_heap.c:106
>   ion_heap_sglist_zero+0x245/0x270 drivers/staging/android/ion/ion_heap.c:130
>   ion_heap_buffer_zero+0xf5/0x150 drivers/staging/android/ion/ion_heap.c:145
>   ion_system_heap_free+0x1eb/0x250
> drivers/staging/android/ion/ion_system_heap.c:163
>   ion_buffer_destroy+0x159/0x2d0 drivers/staging/android/ion/ion.c:93
>   ion_heap_deferred_free+0x29d/0x630
> drivers/staging/android/ion/ion_heap.c:239
>   kthread+0x361/0x430 kernel/kthread.c:255
>   ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> Modules linked in:
> CR2: f52002e0
> ---[ end trace ee5c63907f1d6f00 ]---
> RIP: 0010:memory_is_nonzero mm/kasan/generic.c:121 [inline]
> RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:135 [inline]
> RIP: 0010:memory_is_poisoned mm/kasan/generic.c:166 [inline]
> RIP: 0010:check_memory_region_inline mm/kasan/generic.c:182 [inline]
> RIP: 0010:check_memory_region+0x9c/0x1a0 mm/kasan/generic.c:192
> Code: c9 4d 0f 49 c1 49 c1 f8 03 45 85 c0 0f 84 10 01 00 00 41 83 e8 01 4e
> 8d 44 c0 08 eb 0d 48 83 c0 08 4c 39 c0 0f 84 a7 00 00 00 <48> 83 38 00 74
> ed 4c 8d 40 08 eb 09 48 83 c0 01 49 39 c0 74 53 80
> RSP: 0018:c9000c9f7ab8 EFLAGS: 00010212
> RAX: f52002e0 RBX: f52002e01600 RCX: 85d5c229
> RDX: 0001 RSI: b000 RDI: c9001700
> RBP: c9000c9f7ad0 R08: f52002e01600 R09: 1600
> R10: f52002e015ff R11: c9001700afff R12: f52002e0
> R13: b000 R14:  R15: c9000c9f7d08
> FS:  () GS:8880ae60() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: f52002e0 CR3: 778bd000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "syzkaller-bugs" group.
> To unsubscribe 

[PATCH v3 0/2] drm: bridge: adv7511: Add support For ADV7535

[Bogdan Togorean]

This patch-set add support for ADV7535 part in ADV7511 driver.

ADV7535 and ADV7533 are pin to pin compatible parts but ADV7535
support TMDS clock upto 148.5Mhz and resolutions up to 1080p@60Hz.

---
Changes in v3:
 - remove CONFIG_DRM_I2C_ADV7533 from Kconfig. Now driver support
all chip versions
 - create macros for v1p2 config registers
 - remove dummy functions from header

Bogdan Togorean (2):
  dt-bindings: drm: bridge: adv7511: Add ADV7535 support
  drm: bridge: adv7511: Add support for ADV7535

 .../bindings/display/bridge/adi,adv7511.txt   | 23 +-
 drivers/gpu/drm/bridge/adv7511/Kconfig| 13 ++
 drivers/gpu/drm/bridge/adv7511/Makefile   |  3 +-
 drivers/gpu/drm/bridge/adv7511/adv7511.h  | 44 +++
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c  | 35 ++-
 5 files changed, 44 insertions(+), 74 deletions(-)

-- 
2.23.0

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

[PATCH v6 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding

[Xin Ji]

The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
for portable device. It converts MIPI to DisplayPort 1.3 4K.

You can add support to your board with binding.

Example:
anx7625_bridge: encoder@58 {
compatible = "analogix,anx7625";
reg = <0x58>;
status = "okay";
panel-flags = <1>;
enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
#address-cells = <1>;
#size-cells = <0>;

port@0 {
  reg = <0>;
  anx_1_in: endpoint {
remote-endpoint = <_dsi>;
  };
};

port@2 {
  reg = <2>;
  anx_1_out: endpoint {
remote-endpoint = <_in>;
  };
};
};

Signed-off-by: Xin Ji 
---
 .../bindings/display/bridge/anx7625.yaml   | 91 ++
 1 file changed, 91 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/anx7625.yaml

diff --git a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml 
b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
new file mode 100644
index 000..1149ebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
@@ -0,0 +1,91 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 Analogix Semiconductor, Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
+
+maintainers:
+  - Xin Ji 
+
+description: |
+  The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
+  designed for portable devices.
+
+properties:
+  "#address-cells": true
+  "#size-cells": true
+
+  compatible:
+items:
+  - const: analogix,anx7625
+
+  reg:
+maxItems: 1
+
+  panel-flags:
+description: indicate the panel is internal or external.
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  enable-gpios:
+description: used for power on chip control, POWER_EN pin D2.
+maxItems: 1
+
+  reset-gpios:
+description: used for reset chip control, RESET_N pin B7.
+maxItems: 1
+
+  port@0:
+type: object
+description:
+  A port node pointing to MIPI DSI host port node.
+
+  port@1:
+type: object
+description:
+  A port node pointing to MIPI DPI host port node.
+
+  port@2:
+type: object
+description:
+  A port node pointing to panel port node.
+
+required:
+  - "#address-cells"
+  - "#size-cells"
+  - compatible
+  - reg
+  - port@0
+  - port@2
+
+example:
+  - |
+anx7625_bridge: encoder@58 {
+compatible = "analogix,anx7625";
+reg = <0x58>;
+status = "okay";
+panel-flags = <1>;
+enable-gpios = < 45 GPIO_ACTIVE_HIGH>;
+reset-gpios = < 73 GPIO_ACTIVE_HIGH>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+  reg = <0>;
+  anx_1_in: endpoint {
+remote-endpoint = <_dsi>;
+  };
+};
+
+port@2 {
+  reg = <2>;
+  anx_1_out: endpoint {
+remote-endpoint = <_in>;
+  };
+};
+};
-- 
2.7.4

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

Re: [PATCH v2] drm/dp_mst: Fix W=1 warnings

[Benjamin GAIGNARD]

On 11/28/19 12:21 PM, Jani Nikula wrote:
> On Thu, 28 Nov 2019, Benjamin Gaignard  wrote:
>> Fix the warnings that show up with W=1.
>> They are all about unused but set variables.
>> If functions returns are not used anymore make them void.
>>
>> Signed-off-by: Benjamin Gaignard 
>> CC: Jani Nikula 
>> ---
>> changes in version 2:
>> - fix indentations
>> - when possible change functions prototype to void
>>
>> Note: this patch may conflict with c485e2c97dae ("drm/dp_mst: Refactor pdt
>> setup/teardown, add more locking") when it will hit drm-misc-next
> Well, why create an unnecessary conflict when the referenced commit also
> fixes the same warnings as a side-effect?

Because this commit is not merged (yet ?) in drm-misc-next which where I 
start.

Benjamin

> BR,
> Jani.
>
>
>>   drivers/gpu/drm/drm_dp_mst_topology.c | 83 
>> +--
>>   1 file changed, 31 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index b854a422a523..ff2d81db0778 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -672,7 +672,6 @@ static bool drm_dp_sideband_msg_build(struct 
>> drm_dp_sideband_msg_rx *msg,
>>u8 *replybuf, u8 replybuflen, bool hdr)
>>   {
>>  int ret;
>> -u8 crc4;
>>   
>>  if (hdr) {
>>  u8 hdrlen;
>> @@ -714,8 +713,6 @@ static bool drm_dp_sideband_msg_build(struct 
>> drm_dp_sideband_msg_rx *msg,
>>  }
>>   
>>  if (msg->curchunk_idx >= msg->curchunk_len) {
>> -/* do CRC */
>> -crc4 = drm_dp_msg_data_crc4(msg->chunk, msg->curchunk_len - 1);
>>  /* copy chunk into bigger msg */
>>  memcpy(>msg[msg->curlen], msg->chunk, msg->curchunk_len - 
>> 1);
>>  msg->curlen += msg->curchunk_len - 1;
>> @@ -1012,7 +1009,7 @@ static bool drm_dp_sideband_parse_req(struct 
>> drm_dp_sideband_msg_rx *raw,
>>  }
>>   }
>>   
>> -static int build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 
>> port_num, u32 offset, u8 num_bytes, u8 *bytes)
>> +static void build_dpcd_write(struct drm_dp_sideband_msg_tx *msg, u8 
>> port_num, u32 offset, u8 num_bytes, u8 *bytes)
>>   {
>>  struct drm_dp_sideband_msg_req_body req;
>>   
>> @@ -1022,17 +1019,14 @@ static int build_dpcd_write(struct 
>> drm_dp_sideband_msg_tx *msg, u8 port_num, u32
>>  req.u.dpcd_write.num_bytes = num_bytes;
>>  req.u.dpcd_write.bytes = bytes;
>>  drm_dp_encode_sideband_req(, msg);
>> -
>> -return 0;
>>   }
>>   
>> -static int build_link_address(struct drm_dp_sideband_msg_tx *msg)
>> +static void build_link_address(struct drm_dp_sideband_msg_tx *msg)
>>   {
>>  struct drm_dp_sideband_msg_req_body req;
>>   
>>  req.req_type = DP_LINK_ADDRESS;
>>  drm_dp_encode_sideband_req(, msg);
>> -return 0;
>>   }
>>   
>>   static int build_enum_path_resources(struct drm_dp_sideband_msg_tx *msg, 
>> int port_num)
>> @@ -1046,7 +1040,7 @@ static int build_enum_path_resources(struct 
>> drm_dp_sideband_msg_tx *msg, int por
>>  return 0;
>>   }
>>   
>> -static int build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
>> port_num,
>> +static void build_allocate_payload(struct drm_dp_sideband_msg_tx *msg, int 
>> port_num,
>>u8 vcpi, uint16_t pbn,
>>u8 number_sdp_streams,
>>u8 *sdp_stream_sink)
>> @@ -1062,10 +1056,9 @@ static int build_allocate_payload(struct 
>> drm_dp_sideband_msg_tx *msg, int port_n
>> number_sdp_streams);
>>  drm_dp_encode_sideband_req(, msg);
>>  msg->path_msg = true;
>> -return 0;
>>   }
>>   
>> -static int build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
>> +static void build_power_updown_phy(struct drm_dp_sideband_msg_tx *msg,
>>int port_num, bool power_up)
>>   {
>>  struct drm_dp_sideband_msg_req_body req;
>> @@ -1078,7 +1071,6 @@ static int build_power_updown_phy(struct 
>> drm_dp_sideband_msg_tx *msg,
>>  req.u.port_num.port_number = port_num;
>>  drm_dp_encode_sideband_req(, msg);
>>  msg->path_msg = true;
>> -return 0;
>>   }
>>   
>>   static int drm_dp_mst_assign_payload_id(struct drm_dp_mst_topology_mgr 
>> *mgr,
>> @@ -1744,14 +1736,13 @@ static u8 drm_dp_calculate_rad(struct 
>> drm_dp_mst_port *port,
>>*/
>>   static bool drm_dp_port_setup_pdt(struct drm_dp_mst_port *port)
>>   {
>> -int ret;
>>  u8 rad[6], lct;
>>  bool send_link = false;
>>  switch (port->pdt) {
>>  case DP_PEER_DEVICE_DP_LEGACY_CONV:
>>  case DP_PEER_DEVICE_SST_SINK:
>>  /* add i2c over sideband */
>> -ret = drm_dp_mst_register_i2c_bus(>aux);
>> +drm_dp_mst_register_i2c_bus(>aux);
>>  break;
>>  case DP_PEER_DEVICE_MST_BRANCHING:
>>  lct = 

Re: [PATCH] drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded

[Tom Anderson]

I just realized that at 4:2:2, the pixel clock isn't actually decreased to 3/4
of it's value at 4:4:4. I'll send a revised patch on Monday.

On Fri, Nov 22, 2019 at 09:29:00PM -0800, Thomas Anderson wrote:
> For high-res (8K) or HFR (4K120) displays, using uncompressed pixel
> formats like YCbCr444 would exceed the bandwidth of HDMI 2.0, so the
> "interesting" modes would be disabled, leaving only low-res or low
> framerate modes.
> 
> This change lowers the pixel encoding to 4:2:2 or 4:2:0 if the max TMDS
> clock is exceeded. Verified that 8K30 and 4K120 are now available and
> working with a Samsung Q900R over an HDMI 2.0b link from a Radeon 5700.
> 
> Signed-off-by: Thomas Anderson 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 ++-
>  1 file changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 4139f129eafb..a507a6f04c82 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3269,13 +3269,15 @@ static void reduce_mode_colour_depth(struct 
> dc_crtc_timing *timing_out)
>   timing_out->display_color_depth--;
>  }
>  
> -static void adjust_colour_depth_from_display_info(struct dc_crtc_timing 
> *timing_out,
> - const struct drm_display_info 
> *info)
> +static void adjust_timing_from_display_info(
> + struct dc_crtc_timing *timing_out,
> + const struct drm_display_info *info,
> + const struct drm_display_mode *mode_in)
>  {
>   int normalized_clk;
> - if (timing_out->display_color_depth <= COLOR_DEPTH_888)
> + if (timing_out->display_color_depth < COLOR_DEPTH_888)
>   return;
> - do {
> + while (timing_out->display_color_depth > COLOR_DEPTH_888) {
>   normalized_clk = timing_out->pix_clk_100hz / 10;
>   /* YCbCr 4:2:0 requires additional adjustment of 1/2 */
>   if (timing_out->pixel_encoding == PIXEL_ENCODING_YCBCR420)
> @@ -3297,9 +3299,23 @@ static void 
> adjust_colour_depth_from_display_info(struct dc_crtc_timing *timing_
>   if (normalized_clk <= info->max_tmds_clock)
>   return;
>   reduce_mode_colour_depth(timing_out);
> + }
>  
> - } while (timing_out->display_color_depth > COLOR_DEPTH_888);
> -
> + /* The color depth is 888 and cannot be reduced any further, but the
> +  * clock would still exceed the max tmds clock. Try reducing the pixel
> +  * encoding next.
> +  */
> + if (timing_out->pixel_encoding == PIXEL_ENCODING_RGB ||
> + timing_out->pixel_encoding == PIXEL_ENCODING_YCBCR444) {
> + /* YCBCR422 is always supported. */
> + timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422;
> + normalized_clk = (timing_out->pix_clk_100hz * 3) / 40;
> + if (normalized_clk <= info->max_tmds_clock)
> + return;
> + }
> + /* YCBCR420 may only be supported on specific modes. */
> + if (drm_mode_is_420_also(info, mode_in))
> + timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
>  }
>  
>  static void fill_stream_properties_from_drm_display_mode(
> @@ -3366,7 +3382,7 @@ static void 
> fill_stream_properties_from_drm_display_mode(
>   stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
>   stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
>   if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
> - adjust_colour_depth_from_display_info(timing_out, info);
> + adjust_timing_from_display_info(timing_out, info, mode_in);
>  }
>  
>  static void fill_audio_info(struct audio_info *audio_info,
> -- 
> 2.24.0.432.g9d3f5f5b63-goog
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 14/14] auxdisplay: constify fb ops

[Miguel Ojeda]

On Fri, Nov 29, 2019 at 4:24 PM Daniel Vetter  wrote:
>
> Oh, another display subsystem? Intriguing ...
>
> Reviewed-by: Daniel Vetter 

It is intended for displays that are not intended as the usual/main
display, e.g. very small LCDs :)

Reviewed-by: Miguel Ojeda 

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

Re: [PATCH 13/13] samples: vfio-mdev: constify fb ops

[Christophe de Dinechin]

> On 27 Nov 2019, at 17:32, Jani Nikula  wrote:
> 
> Now that the fbops member of struct fb_info is const, we can star making
s/star/start/

> the ops const as well.
> 
> Cc: Kirti Wankhede 
> Cc: k...@vger.kernel.org
> Signed-off-by: Jani Nikula 
> ---
> samples/vfio-mdev/mdpy-fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/samples/vfio-mdev/mdpy-fb.c b/samples/vfio-mdev/mdpy-fb.c
> index 2719bb259653..21dbf63d6e41 100644
> --- a/samples/vfio-mdev/mdpy-fb.c
> +++ b/samples/vfio-mdev/mdpy-fb.c
> @@ -86,7 +86,7 @@ static void mdpy_fb_destroy(struct fb_info *info)
>   iounmap(info->screen_base);
> }
> 
> -static struct fb_ops mdpy_fb_ops = {
> +static const struct fb_ops mdpy_fb_ops = {
>   .owner  = THIS_MODULE,
>   .fb_destroy = mdpy_fb_destroy,
>   .fb_setcolreg   = mdpy_fb_setcolreg,
> -- 
> 2.20.1
> 

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

[PATCH v6 0/2] Add initial support for slimport anx7625

[Xin Ji]

Hi all,

The following series add initial support for the Slimport ANX7625 transmitter, a
ultra-low power Full-HD 4K MIPI to DP transmitter designed for portable device.

This is the initial version, any mistakes, please let me know, I will fix it in
the next series.

Thanks,
Xin


Xin Ji (2):
  dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
  drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver

 .../bindings/display/bridge/anx7625.yaml   |   91 +
 drivers/gpu/drm/bridge/Makefile|2 +-
 drivers/gpu/drm/bridge/analogix/Kconfig|6 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 drivers/gpu/drm/bridge/analogix/anx7625.c  | 2045 
 drivers/gpu/drm/bridge/analogix/anx7625.h  |  406 
 6 files changed, 2550 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/anx7625.yaml
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.c
 create mode 100644 drivers/gpu/drm/bridge/analogix/anx7625.h

-- 
2.7.4

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