Re: [PATCH V5 1/3] drm/panel: simple: Add Logic PD Type 28 display support
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
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
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 = &auo_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 = &auo_g104sn02, > + }, { > + .compatible = "auo,g121ean01.4", > + .data = &auo_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
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 = <&pio 1 7 0>; /* PB07 */ > +power-supply = <®>; > reset-gpios = <&r_pio 0 5 1>; /* PL05 */ > backlight = <&pwm_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 = <&backlight_lcd>; > - power-supply = <®_display>; > - > - port { > - lcd_panel_in: endpoint { > - remote-endpoint = <&lcd_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
[Bug 205649] Daisy Chain (MST) Session Crash after Screen Lock Resume
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
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
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
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
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 = <&vlcm_3v3>; > > > + no-hpd; > > > + > > > + ports { > > > + port { > > > + ivo_panel_in_edp: endpoint { > > > + remote-endpoint = > > > <&sn65dsi86_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 = <&sn65dsi86_out_ivo>; > }; > }; > }; > }; > > boe_panel { > compatible = "boe,nv133fhm-n61"; > panel-id = <0xc4>; > status = "disabled"; > > ports { > port { > boe_panel_in_edp: endpoint { > remote-endpoint = <&sn65dsi86_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 = <&dsi0_out>; > }; > }; > > port@1 { > reg = <1>; > > sn65dsi86_out_boe: endpoint@c4 { > remote-endpoint = <&boe_panel_in_edp>; > }; > > sn65dsi86_out_ivo: endpoint@c5 { > remote-endpoint = <&ivo_panel_in_edp>; > }; > }; > }; > }; > > With this, the "firmware" (DtbLoader, u-boot, etc
Re: [PATCH 1/4] dt-bindings: chosen: document panel-id binding
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 = <&vlcm_3v3>; > > + no-hpd; > > + > > + ports { > > + port { > > + ivo_panel_in_edp: endpoint { > > + remote-endpoint = > > <&sn65dsi86_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 = <&sn65dsi86_out_ivo>; }; }; }; }; boe_panel { compatible = "boe,nv133fhm-n61"; panel-id = <0xc4>; status = "disabled"; ports { port { boe_panel_in_edp: endpoint { remote-endpoint = <&sn65dsi86_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 = <&dsi0_out>; }; }; port@1 { reg = <1>; sn65dsi86_out_boe: endpoint@c4 { remote-endpoint = <&boe_panel_in_edp>; }; sn65dsi86_out_ivo: endpoint@c5 { remote-endpoint = <&ivo_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 (
Re: [PATCH 3/3] drm/panel: simple: Add support for the Frida FRD350H54004 panel
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 = &frida_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 = &evervision_vgg804821, > + }, { > + .compatible = "frida,frd350h54004", > + .data = &frida_frd350h54004, > }, { > .compatible = "foxlink,fl500wvr00-a0t", > .data = &foxlink_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
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.
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
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
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
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
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
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
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
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
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
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&action=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.
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
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
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
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
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
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 = <&emc &mc TEGRA194_MEMORY_CLIENT_EQOSR>, > <&mc TEGRA194_MEMORY_CLIENT_EQOSW &emc>; > 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
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[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(&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(&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(&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(&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(&port->aux); + drm_dp_mst_register_i2c_bus(&port->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
Re: [PATCH 0/2] drm/i915/vlv_dsi: Control panel and backlight enable GPIOs on BYT
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
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, > > > - &sun6i_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, &sun6i_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 = <&ccu CLK_BUS_MIPI_DSI>; >resets = <&ccu RST_BUS_MIPI_DSI>; > phys = <&dphy>; > 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
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 = <&src_pp1800_l8c>; + vdd3p3-supply = <&src_pp2800_l18a>; + + pinctrl-names = "default", "suspend"; + pinctrl-0 = <&disp_pins_default>; + pinctrl-1 = <&disp_pins_default>; + + reset-gpios = <&pm6150l_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 = <&dsi0_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
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
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[] = { &msm8998_dsi_cfg, &msm_dsi_6g_v2_host_ops}, {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_2_1, &sdm845_dsi_cfg, &msm_dsi_6g_v2_host_ops}, + {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V2_4_1, + &sc7180_dsi_cfg, &msm_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
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 = &client->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 = &client->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; + str
Re: [PATCH v2 14/14] auxdisplay: constify fb ops
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
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
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[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(&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(&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(&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(&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(&port->aux); + drm_dp_mst_register_i2c_bus(&port->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
Re: BUG: unable to handle kernel paging request in ion_heap_clear_pages
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 from
[PATCH v3 0/2] drm: bridge: adv7511: Add support For ADV7535
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
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 = <&pio 45 GPIO_ACTIVE_HIGH>; reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>; #address-cells = <1>; #size-cells = <0>; port@0 { reg = <0>; anx_1_in: endpoint { remote-endpoint = <&mipi_dsi>; }; }; port@2 { reg = <2>; anx_1_out: endpoint { remote-endpoint = <&panel_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 = <&pio 45 GPIO_ACTIVE_HIGH>; +reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>; +#address-cells = <1>; +#size-cells = <0>; + +port@0 { + reg = <0>; + anx_1_in: endpoint { +remote-endpoint = <&mipi_dsi>; + }; +}; + +port@2 { + reg = <2>; + anx_1_out: endpoint { +remote-endpoint = <&panel_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
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[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(&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(&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(&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(&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(&port->aux); >> +drm_dp_mst_register_i2c_bus(&port->aux); >> break; >> case DP_PEER_DEVICE_MST_BRANCHING:
Re: [PATCH] drm/amd/display: Reduce HDMI pixel encoding if max clock is exceeded
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
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
> 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
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