Re: [PATCH 13/17] drm/sun4i: Add DE2 CSC library

[Jernej Škrabec]

Hi!

Dne torek, 28. november 2017 ob 21:55:50 CET je Maxime Ripard napisal(a):
> On Mon, Nov 27, 2017 at 09:57:46PM +0100, Jernej Skrabec wrote:
> > DE2 have many CSC units - channel input CSC, channel output CSC and
> > mixer output CSC and maybe more.
> > 
> > Fortunately, they have all same register layout, only base offsets
> > differs.
> > 
> > Add support only for channel output CSC for now.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  drivers/gpu/drm/sun4i/Makefile|  2 +-
> >  drivers/gpu/drm/sun4i/sun8i_csc.c | 90
> >  +++
> >  drivers/gpu/drm/sun4i/sun8i_csc.h | 36 
> >  3 files changed, 127 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c
> >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h
> > 
> > diff --git a/drivers/gpu/drm/sun4i/Makefile
> > b/drivers/gpu/drm/sun4i/Makefile index 70df480792f9..f82cc69ede72 100644
> > --- a/drivers/gpu/drm/sun4i/Makefile
> > +++ b/drivers/gpu/drm/sun4i/Makefile
> > @@ -9,7 +9,7 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
> > 
> >  sun4i-drm-hdmi-y   += sun4i_hdmi_i2c.o
> >  sun4i-drm-hdmi-y   += sun4i_hdmi_tmds_clk.o
> > 
> > -sun8i-mixer-y  += sun8i_mixer.o sun8i_layer.o 
> > sun8i_scaler.o
> > +sun8i-mixer-y  += sun8i_mixer.o sun8i_layer.o 
> > sun8i_scaler.o 
sun8i_csc.o
> 
> Please wrap that line.
> 
> >  sun4i-tcon-y   += sun4i_crtc.o
> >  sun4i-tcon-y   += sun4i_dotclock.o
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
> > b/drivers/gpu/drm/sun4i/sun8i_csc.c new file mode 100644
> > index ..d48c28f8d568
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
> > @@ -0,0 +1,90 @@
> > +/*
> > + * Copyright (C) Jernej Skrabec 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation; either version 2 of
> > + * the License, or (at your option) any later version.
> > + */
> > +
> > +#include "sun8i_csc.h"
> > +
> > +static const u32 ccsc_base[2][2] = {
> > +   {CCSC00_OFFSET, CCSC01_OFFSET},
> > +   {CCSC10_OFFSET, CCSC11_OFFSET},
> > +};
> > +
> > +/*
> > + * Factors are in two's complement format, 10 bits for fractinal part.
> > + * First tree values in each line are multiplication factor and last
> > + * value is constant, which is added at the end.
> > + */
> > +static const u32 yuv2rgb[] = {
> > +   0x04A8, 0x, 0x0662, 0xFFFC845A,
> > +   0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
> > +   0x04A8, 0x0813, 0x, 0xFFFBAC4A,
> > +};
> > +
> > +static const u32 yvu2rgb[] = {
> > +   0x04A8, 0x0662, 0x, 0xFFFC845A,
> > +   0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
> > +   0x04A8, 0x, 0x0813, 0xFFFBAC4A,
> > +};
> > +
> > +static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
> > +  enum sun8i_csc_mode mode)
> > +{
> > +   const u32 *table;
> > +   int i, data;
> > +
> > +   switch (mode) {
> > +   case SUN8I_CSC_MODE_YUV2RGB:
> > +   table = yuv2rgb;
> > +   break;
> > +   case SUN8I_CSC_MODE_YVU2RGB:
> > +   table = yvu2rgb;
> > +   break;
> > +   default:
> > +   WARN(1, "Wrong CSC mode specified.");
> 
> A hard warn is a bit overkill here. What about a dev_warn?

dev_warn requires device, which is not available here and seems a bit overkill 
to have it as parameter just to print warning. What about DRM_WARN()?

Best regards,
Jernej

> 
> Looks good otherwise.
> 
> Thanks!
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171128 16:17]:
> Hi Tony,
> 
> > Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
> > 
> > * H. Nikolaus Schaller  [171128 15:52]:
> >> We can remove the unnecessary "omapdss," prefix because
> >> the omapdrm driver takes care of it when matching with
> >> the driver table.
> > 
> > So is this needed as a fix or is this another clean-up?
> > 
> > So is this is really needed as a fix?
> 
> Hm. How do you differentiate between "fix" and "cleanup"?
> Maybe it is more a wording than a content issue...
> 
> For me it is a "fix" because it is semantically wrong to have
> a prefix where it is not needed. And "fixing" it changes the
> compiler output by 8 bytes.

How about let's call it a "typo fix" then? :)

> "Cleanup" would be for me removing whitespace or empty lines
> or typos in comments.
>
> > If this is just clean-up, again, please resend once the driver
> > changes have cleared.
> 
> There is no change to the pandora driver involved here. The Pandora
> panel driver is already correct. Just the DTS has some redundant
> content which should be removed.
> 
> So there is no dependency for this patch.

OK please resend separately after the driver changes have merged
then.

Regards,

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

Re: [PATCH] drm: fix amdkfd use-after-free GP fault

[Randy Dunlap]

On 11/13/2017 08:09 AM, Oded Gabbay wrote:
> On Sat, Nov 11, 2017 at 8:16 AM, Randy Dunlap  wrote:
>> From: Randy Dunlap 
>>
>> Fix GP fault caused by dev_info() reference to a struct device*
>> after the device has been freed (use after free).
>> kfd_chardev_exit() frees the device so 'kfd_device' should not
>> be used after calling kfd_chardev_exit().
>>
>> To reproduce, just load the module and then unload it.
>> Note that %RAX contains repeated 0x6b, which is use-after-free
>> poisoning.
>>
>> [  946.645809] calling  kfd_module_init+0x0/0x1000 [amdkfd] @ 5785
>> [  946.646025] CRAT table not found
>> [  946.646027] Finished initializing topology ret=0
>> [  946.646050] kfd kfd: Initialized module
>> [  946.646058] initcall kfd_module_init+0x0/0x1000 [amdkfd] returned 0 after 
>> 233 usecs
>> [  947.650189] general protection fault:  [#1] PREEMPT SMP
>> [  947.650192] Modules linked in: amdkfd(-) amd_iommu_v2 dw_hdmi cec rc_core 
>> mxm_wmi ttm dln2 gpio_max730x tps65218 lp3943 mcb crc4 fpga_mgr fpga_bridge 
>> fmc fuse ctr ccm af_packet nf_log_ipv6 xt_pkttype nf_log_ipv4 nf_log_common 
>> xt_LOG xt_limit ip6t_REJECT nf_reject_ipv6 xt_tcpudp nf_conntrack_ipv6 
>> nf_defrag_ipv6 ip6table_raw ipt_REJECT nf_reject_ipv4 iptable_raw xt_CT 
>> iptable_filter ip6table_mangle nf_conntrack_netbios_ns 
>> nf_conntrack_broadcast nf_conntrack_ipv4 nf_defrag_ipv4 ip_tables 
>> xt_conntrack nf_conntrack libcrc32c ip6table_filter ip6_tables x_tables 
>> coretemp hwmon intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel 
>> kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel 
>> pcbc aesni_intel uvcvideo videobuf2_vmalloc aes_x86_64 videobuf2_memops 
>> hid_generic videobuf2_v4l2
>> [  947.650224]  crypto_simd snd_hda_codec_hdmi videobuf2_core usbmouse 
>> videodev snd_hda_codec_realtek glue_helper usbhid media hid 
>> snd_hda_codec_generic snd_hda_intel arc4 snd_hda_codec cryptd iwldvm 
>> sdhci_pci snd_hda_core sdhci mmc_core mac80211 snd_hwdep iTCO_wdt snd_pcm 
>> iTCO_vendor_support xhci_pci intel_cstate xhci_hcd i915 snd_seq 
>> snd_seq_device ehci_pci snd_timer toshiba_acpi ehci_hcd snd usbcore iwlwifi 
>> sparse_keymap e1000e cfg80211 input_leds ptp wmi sr_mod intel_uncore mei_me 
>> lpc_ich led_class cdrom usb_common pps_core mei joydev intel_rapl_perf 
>> mousedev evdev industrialio toshiba_bluetooth shpchp mac_hid rfkill 
>> soundcore serio_raw pcspkr toshiba_haps battery video thermal ac button sg 
>> autofs4 [last unloaded: radeon]
>> [  947.650259] CPU: 3 PID: 5791 Comm: rmmod Not tainted 4.14.0-rc8 #4
>> [  947.650260] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version 
>> 4.10   01/08/2013
>> [  947.650262] task: 97144a3f2840 task.stack: a51e409c4000
>> [  947.650266] RIP: 0010:__dev_printk+0x29/0x90
>> [  947.650267] RSP: 0018:a51e409c7e48 EFLAGS: 00010202
>> [  947.650269] RAX: 6b6b6b6b6b6b6b6b RBX: 97a579c3 RCX: 
>> 000100140013
>> [  947.650270] RDX: a51e409c7e78 RSI: 97139e360558 RDI: 
>> 97a579c3
>> [  947.650271] RBP: a51e409c7e68 R08: 6b6b6b6b6b6b6b6b R09: 
>> a51e409c7e78
>> [  947.650272] R10: 9714465c44b8 R11: 9714465c55e8 R12: 
>> 7fff874111f7
>> [  947.650273] R13: 0800 R14: 006231c0 R15: 
>> 00623010
>> [  947.650275] FS:  7fe8a109d700() GS:97144fac() 
>> knlGS:
>> [  947.650276] CS:  0010 DS:  ES:  CR0: 80050033
>> [  947.650277] CR2: 0062cc88 CR3: 00013fd43005 CR4: 
>> 000606e0
>> [  947.650279] Call Trace:
>> [  947.650283]  ? kobject_cleanup+0x75/0x170
>> [  947.650284]  _dev_info+0x57/0x60
>> [  947.650288]  ? kfree+0xf5/0x140
>> [  947.650295]  kfd_module_exit+0x37/0x39 [amdkfd]
>> [  947.650299]  SyS_delete_module+0x14d/0x260
>> [  947.650302]  ? exit_to_usermode_loop+0x60/0x87
>> [  947.650305]  entry_SYSCALL_64_fastpath+0x1e/0xa9
>> [  947.650307] RIP: 0033:0x7fe8a0beff97
>> [  947.650308] RSP: 002b:7fff8740ffc8 EFLAGS: 0202 ORIG_RAX: 
>> 00b0
>> [  947.650310] RAX: ffda RBX: 0003 RCX: 
>> 7fe8a0beff97
>> [  947.650311] RDX: 7fe8a0c56920 RSI: 0800 RDI: 
>> 00623228
>> [  947.650312] RBP: 006231c0 R08: 7fe8a0ea3f20 R09: 
>> 7fff8740ef41
>> [  947.650313] R10: 2ef31b7d R11: 0202 R12: 
>> 7fff8740efc0
>> [  947.650314] R13:  R14: 006231c0 R15: 
>> 00623010
>> [  947.650316] Code: 00 00 55 49 89 d1 48 89 e5 53 48 89 fb 48 83 ec 18 48 
>> 85 f6 74 5f 4c 8b 46 50 4d 85 c0 74 2b 48 8b 86 88 00 00 00 48 85 c0 74 25 
>> <48> 8b 08 0f be 7b 01 48 c7 c2 96 0a aa 97 31 c0 83 ef 30 e8 7f
>> [  947.650339] RIP: __dev_printk+0x29/0x90 RSP: a51e409c7e48
>> [  947.650388] ---[ end trace c41965e147ae98ae ]---
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: Oded Gabbay 

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171128 15:52]:
> We can remove the unnecessary "omapdss," prefix because
> the omapdrm driver takes care of it when matching with
> the driver table.

So is this needed as a fix or is this another clean-up?

So is this is really needed as a fix?

If this is just clean-up, again, please resend once the driver
changes have cleared.

Regards,

Tony

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
> b/arch/arm/boot/dts/omap3-pandora-common.dtsi
> index 53e007abdc71..64d967ec8c58 100644
> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
> @@ -626,7 +626,7 @@
>  
>   lcd: lcd@1 {
>   reg = <1>;  /* CS1 */
> - compatible ="omapdss,tpo,td043mtea1";
> + compatible ="tpo,td043mtea1";
>   spi-max-frequency = <10>;
>   spi-cpol;
>   spi-cpha;
> -- 
> 2.12.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Hi Tony,

> Am 28.11.2017 um 16:10 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 15:04]:
>> Hi Tony,
>> 
>>> Am 28.11.2017 um 15:57 schrieb Tony Lindgren :
>>> 
>>> * H. Nikolaus Schaller  [171116 08:53]:
 Vendor string is "tpo" and not "toppoly".
 
 Signed-off-by: H. Nikolaus Schaller 
 ---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
 b/arch/arm/boot/dts/omap3-gta04.dtsi
 index 4504908c23fe..ec27ed67a22a 100644
 --- a/arch/arm/boot/dts/omap3-gta04.dtsi
 +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
 @@ -86,7 +86,7 @@
 
/* lcd panel */
lcd: td028ttec1@0 {
 -  compatible = "toppoly,td028ttec1";
 +  compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
>>> 
>>> Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
>>> like it can wait for v4.16 merge window.
>> 
>> Hm. Not really. It needs the panel driver to match. So either both or
>> none should be applied or it will break the panel from working.
>> 
>> I am just 1-2 hours away from submitting a -v3 (rebased and tested
>> on top of 4.15-rc1).
> 
> OK fine dropping both. Please update the description in both dts
> patches to make it clear they are needed as a fix. Preferrably
> with a proper fixes tag.

Well, it is not "needed" in a strong sense since current mainline
works. It is more a style and consistency fix to use "tpo," everywhere.

> 
> Having "We can remove the "omapdss," prefix" in the description sure
> does not sounds like it's needed as a fix :)

The description has been improved on -v3.

> 
> Sounds like maybe these two should be just a single patch for
> a proper fix?

Hm. I usually get the feedback to separate DT and driver fixes into
separate commits... Therefore I submit patch sets in the hope they
are not picked apart :)

As promised -v3 is following now.

BR,
Nikolaus

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

[PATCH] drm/tegra: gem: Use PTR_ERR_OR_ZERO()

[Vasyl Gomonovych]

Fix ptr_ret.cocci warnings:
drivers/gpu/drm/tegra/gem.c:420:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/gpu/drm/tegra/gem.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index ab1e53d434e8..a40148cd0957 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -417,10 +417,8 @@ int tegra_bo_dumb_create(struct drm_file *file, struct 
drm_device *drm,
 
bo = tegra_bo_create_with_handle(file, drm, args->size, 0,
 >handle);
-   if (IS_ERR(bo))
-   return PTR_ERR(bo);
 
-   return 0;
+   return PTR_ERR_OR_ZERO(bo);
 }
 
 static int tegra_bo_fault(struct vm_fault *vmf)
-- 
1.9.1

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

Re: [PATCH v3 3/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171128 15:52]:
> Official vendor string is now "tpo" and not "toppoly".
> 
> Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"

This is not a fix then, this is a clean up as you change the compatible
earlier. Please resend this separately once the driver changes have
been merged.

Regards,

Tony

> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..ec27ed67a22a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -86,7 +86,7 @@
>  
>   /* lcd panel */
>   lcd: td028ttec1@0 {
> - compatible = "toppoly,td028ttec1";
> + compatible = "tpo,td028ttec1";
>   reg = <0>;
>   spi-max-frequency = <10>;
>   spi-cpol;
> -- 
> 2.12.2
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] fbdev: au1200fb: delete duplicate header contents

[Rasmus Villemoes]

This file has been copy-pasted-pasted:

  ~/linux$ x=drivers/video/fbdev/au1200fb.h; diff -u <(head -n 286 $x; head -n 
286 $x) $x
  ~/linux$

Signed-off-by: Rasmus Villemoes 
---
 drivers/video/fbdev/au1200fb.h | 286 -
 1 file changed, 286 deletions(-)

diff --git a/drivers/video/fbdev/au1200fb.h b/drivers/video/fbdev/au1200fb.h
index e2672714d8d4..b34fff342a1a 100644
--- a/drivers/video/fbdev/au1200fb.h
+++ b/drivers/video/fbdev/au1200fb.h
@@ -284,289 +284,3 @@ struct au1200_lcd {
 
 //
 #endif /* _AU1200LCD_H */
-/*
- * BRIEF MODULE DESCRIPTION
- * Hardware definitions for the Au1200 LCD controller
- *
- * Copyright 2004 AMD
- * Author: AMD
- *
- *  This program is free software; you can redistribute it and/or 
modify it
- *  under  the terms of the GNU General  Public License as published 
by the
- *  Free Software Foundation;  either version 2 of the License, or (at your
- *  option) any later version.
- *
- *  THIS  SOFTWARE  IS PROVIDED  ``AS  IS'' AND   ANY  EXPRESS OR 
IMPLIED
- *  WARRANTIES,  INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED 
WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
- *  NO EVENT  SHALL   THE AUTHOR  BELIABLE FOR ANY   DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
- *  NOT LIMITED  TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; 
LOSS OF
- *  USE, DATA, OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
- *  ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR 
TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
- *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  You should have received a copy of the  GNU General Public License along
- *  with this program; if not, write  to the Free Software Foundation, Inc.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#ifndef _AU1200LCD_H
-#define _AU1200LCD_H
-
-//
-#define AU1200_LCD_ADDR0xB500
-
-#define uint8 unsigned char
-#define uint32 unsigned int
-
-struct au1200_lcd {
-   volatile uint32 reserved0;
-   volatile uint32 screen;
-   volatile uint32 backcolor;
-   volatile uint32 horztiming;
-   volatile uint32 verttiming;
-   volatile uint32 clkcontrol;
-   volatile uint32 pwmdiv;
-   volatile uint32 pwmhi;
-   volatile uint32 reserved1;
-   volatile uint32 winenable;
-   volatile uint32 colorkey;
-   volatile uint32 colorkeymsk;
-   struct
-   {
-   volatile uint32 cursorctrl;
-   volatile uint32 cursorpos;
-   volatile uint32 cursorcolor0;
-   volatile uint32 cursorcolor1;
-   volatile uint32 cursorcolor2;
-   uint32  cursorcolor3;
-   } hwc;
-   volatile uint32 intstatus;
-   volatile uint32 intenable;
-   volatile uint32 outmask;
-   volatile uint32 fifoctrl;
-   uint32  reserved2[(0x0100-0x0058)/4];
-   struct
-   {
-   volatile uint32 winctrl0;
-   volatile uint32 winctrl1;
-   volatile uint32 winctrl2;
-   volatile uint32 winbuf0;
-   volatile uint32 winbuf1;
-   volatile uint32 winbufctrl;
-   uint32  winreserved0;
-   uint32  winreserved1;
-   } window[4];
-
-   uint32  reserved3[(0x0400-0x0180)/4];
-
-   volatile uint32 palette[(0x0800-0x0400)/4];
-
-   volatile uint8  cursorpattern[256];
-};
-
-/* lcd_screen */
-#define LCD_SCREEN_SEN (1<<31)
-#define LCD_SCREEN_SX  (0x07FF<<19)
-#define LCD_SCREEN_SY  (0x07FF<< 8)
-#define LCD_SCREEN_SWP (1<<7)
-#define LCD_SCREEN_SWD (1<<6)
-#define LCD_SCREEN_PT  (7<<0)
-#define LCD_SCREEN_PT_TFT  (0<<0)
-#define LCD_SCREEN_SX_N(WIDTH) ((WIDTH-1)<<19)
-#define LCD_SCREEN_SY_N(HEIGHT)((HEIGHT-1)<<8)
-#define LCD_SCREEN_PT_CSTN (1<<0)
-#define LCD_SCREEN_PT_CDSTN(2<<0)
-#define LCD_SCREEN_PT_M8STN(3<<0)
-#define LCD_SCREEN_PT_M4STN(4<<0)
-
-/* lcd_backcolor */
-#define LCD_BACKCOLOR_SBGR (0xFF<<16)
-#define LCD_BACKCOLOR_SBGG (0xFF<<8)
-#define LCD_BACKCOLOR_SBGB (0xFF<<0)
-#define LCD_BACKCOLOR_SBGR_N(N)((N)<<16)
-#define LCD_BACKCOLOR_SBGG_N(N)((N)<<8)
-#define LCD_BACKCOLOR_SBGB_N(N)((N)<<0)
-
-/* lcd_winenable */
-#define LCD_WINENABLE_WEN3 (1<<3)
-#define LCD_WINENABLE_WEN2 (1<<2)
-#define LCD_WINENABLE_WEN1 (1<<1)
-#define LCD_WINENABLE_WEN0 (1<<0)
-
-/* lcd_colorkey */
-#define LCD_COLORKEY_CKR   (0xFF<<16)
-#define LCD_COLORKEY_CKG   (0xFF<<8)

Re: [PATCH v2 05/18] drm/sun4i: Force the mixer rate at 150MHz

[Jernej Škrabec]

Hi!

Dne torek, 28. november 2017 ob 09:58:26 CET je Maxime Ripard napisal(a):
> On Mon, Nov 27, 2017 at 05:07:04PM +0100, Jernej Škrabec wrote:
> > Hi Maxime,
> > 
> > Dne ponedeljek, 27. november 2017 ob 16:41:29 CET je Maxime Ripard 
napisal(a):
> > > It seems like the mixer can only run properly when clocked at 150MHz. In
> > > order to have something more robust than simply a fire-and-forget
> > > assigned-clocks-rate, let's put that in the code.
> > > 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > > 
> > >  drivers/gpu/drm/sun4i/sun8i_mixer.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index cb193c5f1686..c0cdccf772a2
> > > 100644
> > > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > @@ -315,6 +315,13 @@ static int sun8i_mixer_bind(struct device *dev,
> > > struct
> > > device *master, }
> > > 
> > >   clk_prepare_enable(mixer->mod_clk);
> > > 
> > > + /*
> > > +  * It seems that we need to enforce that rate for whatever
> > > +  * reason for the mixer to be functional. Make sure it's the
> > > +  * case.
> > > +  */
> > > + clk_set_rate(mixer->mod_clk, 15000);
> > > +
> > 
> > H3 mixer works at much higher rate and if we want to support tv out, it
> > must be dividable by 432 MHz, so either 432 MHz or maybe even 864 MHz.
> > 
> > We talked about that few months ago.
> > 
> > I guess this should be read from mixer configuration structure.
> 
> That works for me. Actually, I didn't need it at all for the LVDS
> output on the A83t, the default seems to work just fine. Do you know
> what it's related to? Maybe we can make that a bit more dynamic?

There doesn't seem to be any rule to determine which frequency is best, except 
on H3. Obviously, it must be high enough to process data for current 
resolution, which means 150 MHz should be just enough for 1920x1080@60Hz. I 
guess we should just check BSP configuration and use same rate since AW 
engineers may know something we don't.

Best regards,
Jernej

> 
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

Re: [PATCH v2 11/18] drm/sun4i: Add A83T support

[Jernej Škrabec]

Hi!

Dne torek, 28. november 2017 ob 23:00:14 CET je Maxime Ripard napisal(a):
> On Tue, Nov 28, 2017 at 04:48:55PM +0100, Jernej Škrabec wrote:
> > > On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
> > > > Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard
> > 
> > napisal(a):
> > > > > Add support for the A83T display pipeline.
> > > > > 
> > > > > Reviewed-by: Chen-Yu Tsai 
> > > > > Signed-off-by: Maxime Ripard 
> > > > > ---
> > > > > 
> > > > >  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3
> > > > >  +++
> > > > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 2
> > > > >  ++
> > > > >  drivers/gpu/drm/sun4i/sun4i_tcon.c| 5
> > > > >  +
> > > > >  drivers/gpu/drm/sun4i/sun8i_mixer.c   | 4
> > > > >  
> > > > >  4 files changed, 14 insertions(+)
> > > > > 
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > > index
> > > > > d4259a4f5171..d6b52e5c48c0 100644
> > > > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > > > 
> > > > > @@ -93,6 +93,7 @@ Required properties:
> > > > > * allwinner,sun6i-a31s-tcon
> > > > > * allwinner,sun7i-a20-tcon
> > > > > * allwinner,sun8i-a33-tcon
> > > > > 
> > > > > +   * allwinner,sun8i-a83t-tcon-lcd
> > > > > 
> > > > > * allwinner,sun8i-v3s-tcon
> > > > >   
> > > > >   - reg: base address and size of memory-mapped region
> > > > >   - interrupts: interrupt associated to this IP
> > > > > 
> > > > > @@ -224,6 +225,7 @@ supported.
> > > > > 
> > > > >  Required properties:
> > > > >- compatible: value must be one of:
> > > > > +* allwinner,sun8i-a83t-de2-mixer
> > > > 
> > > > What will be the name of the second mixer, once support for HDMI is
> > > > added?
> > > > Should we start directly with 0 and 1 postfix ?
> > > 
> > > What are the differences exactly without the two mixers?
> > 
> > Mixer properties:
> > - mixer index (0 or 1), important for determining CCSC base (see my
> > patches)
> Is that the only thing we need to determine?

For now, mixer index is important only for determining CCSC base in conjuction 
with VEP capability. Obviously, I can't exclude that there is some other case 
where that mixer index is needed.

Can't we just add reg property for that?

> 
> > - number of VI planes (usually 1)
> 
> Usually or always?

V3s mixer has 2 VI channels and others have 1.

(Channel is better term, since is used throughout BSP code)

> 
> > - number of UI planes (usually 1 or 3)
> 
> Same question.

For now, most SoCs (I didn't check all) have 3 UI channels on first mixer and 1 
UI channel on second mixer. Except V3s, which have only one mixer with 1 UI 
channel.

> 
> > - writeback support (yes/no)
> > - scale line buffer length (2048 or 4096)
> > - smart backligth support (yes/no)
> > 
> > channel properties (for both, VI and UI):
> > - scaler support (yes/no, usually yes)

Again, V3s is exception here. Scaler is not supported on UI channel, but other 
SoCs have scalers on all channels.

Disclaimer: I didn't check DE2 capabilities of all SoCs, only few populars.

Best regards,
Jernej

> > - overlay count (seems to be always 4)
> > - VEP support (yes/no)
> > 
> > Those are properties found in BSP de_feat.c, so I guess that's enough to
> > make any kind of decision in the code.
> > 
> > Usually, but we can't count on that, first mixer has 1 VI and 3 UI planes
> > and second mixer has 1 VI and 1 UI plane.
> 
> Right. So that would be easy to support using a property as well. The
> only difference would be the CSC base.
> 
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

Re: [RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

[Arnd Bergmann]

On Wed, Nov 29, 2017 at 6:05 AM, Archit Taneja  wrote:
> On 11/29/2017 03:02 AM, John Stultz wrote:
>> On Sun, Nov 26, 2017 at 4:56 AM, Archit Taneja  
>> wrote:
>>> Apart from this, we should also move adv7511_cec_init() up in the probe
>>> so that it's called before the drm_bridge is registered.
>>
>>
>> Hans has since reworked the patch w/ a new version. You might want to
>> check his patches and see if they fit what your imagining.
>
>
> Yes, I saw Hans's patch after I wrote to you. That patch looks perfect. I'll
> queue that to the drm-misc repo once it's rebased on 4.15-rc1.

It would be nice to get it merged into -rc2 if possible, as this currently
blocks all of the kselftest regression tracking that we're doing on Hikey,
since the arm64 defconfig fails to boot in both mainline and linux-next,
see https://bugs.linaro.org/show_bug.cgi?id=3345

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

[PATCH] drm/tegra: Use PTR_ERR_OR_ZERO()

[Vasyl Gomonovych]

Fix ptr_ret.cocci warnings:
drivers/gpu/drm/tegra/drm.c:597:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/gpu/drm/tegra/drm.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 52552b9b89ef..5718ca9a7943 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -594,10 +594,8 @@ static int tegra_gem_create(struct drm_device *drm, void 
*data,
 
bo = tegra_bo_create_with_handle(file, drm, args->size, args->flags,
 >handle);
-   if (IS_ERR(bo))
-   return PTR_ERR(bo);
 
-   return 0;
+   return PTR_ERR_OR_ZERO(bo);
 }
 
 static int tegra_gem_mmap(struct drm_device *drm, void *data,
-- 
1.9.1

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

[PATCH 3/6] drm/i2c: tda998x: fix error cleanup paths

[Russell King]

If tda998x_get_audio_ports() fails, and we requested the interrupt, we
fail to free the interrupt before returning failure.  Rework the failure
cleanup code and exit paths so that we always clean up properly after an
error, and always propagate the error code.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 4aeac2127974..661cb8915f2f 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1499,10 +1499,15 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
 
/* read version: */
rev_lo = reg_read(priv, REG_VERSION_LSB);
+   if (rev_lo < 0) {
+   dev_err(>dev, "failed to read version: %d\n", rev_lo);
+   return rev_lo;
+   }
+
rev_hi = reg_read(priv, REG_VERSION_MSB);
-   if (rev_lo < 0 || rev_hi < 0) {
-   ret = rev_lo < 0 ? rev_lo : rev_hi;
-   goto fail;
+   if (rev_hi < 0) {
+   dev_err(>dev, "failed to read version: %d\n", rev_hi);
+   return rev_hi;
}
 
priv->rev = rev_lo | rev_hi << 8;
@@ -1526,7 +1531,7 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
default:
dev_err(>dev, "found unsupported device: %04x\n",
priv->rev);
-   goto fail;
+   return -ENXIO;
}
 
/* after reset, enable DDC: */
@@ -1568,7 +1573,7 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
dev_err(>dev,
"failed to request IRQ#%u: %d\n",
client->irq, ret);
-   goto fail;
+   goto err_irq;
}
 
/* enable HPD irq */
@@ -1591,19 +1596,19 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
 
ret = tda998x_get_audio_ports(priv, np);
if (ret)
-   goto fail;
+   goto err_audio;
 
if (priv->audio_port[0].format != AFMT_UNUSED)
tda998x_audio_codec_init(priv, >dev);
 
return 0;
-fail:
-   /* if encoder_init fails, the encoder slave is never registered,
-* so cleanup here:
-*/
-   if (priv->cec)
-   i2c_unregister_device(priv->cec);
-   return -ENXIO;
+
+err_audio:
+   if (client->irq)
+   free_irq(client->irq, priv);
+err_irq:
+   i2c_unregister_device(priv->cec);
+   return ret;
 }
 
 static void tda998x_encoder_prepare(struct drm_encoder *encoder)
-- 
2.7.4

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

[PATCH 6/6] drm/i2c: tda998x: add CEC support

[Russell King]

The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
onto the same die.  Add support for the TDA9950 CEC engine to the
TDA998x driver.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/Kconfig   |   1 +
 drivers/gpu/drm/i2c/tda998x_drv.c | 209 +++---
 2 files changed, 196 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 3a232f5ff0a1..096d2139e733 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -22,6 +22,7 @@ config DRM_I2C_SIL164
 config DRM_I2C_NXP_TDA998X
tristate "NXP Semiconductors TDA998X HDMI encoder"
default m if DRM_TILCDC
+   select CEC_NOTIFIER
select SND_SOC_HDMI_CODEC if SND_SOC
help
  Support for NXP Semiconductors TDA998X HDMI encoders.
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index e294f5b50236..7fa48f43ea8c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -16,8 +16,10 @@
  */
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +31,8 @@
 #include 
 #include 
 
+#include 
+
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 
 struct tda998x_audio_port {
@@ -55,6 +59,7 @@ struct tda998x_priv {
struct platform_device *audio_pdev;
struct mutex audio_mutex;
 
+   struct mutex edid_mutex;
wait_queue_head_t wq_edid;
volatile int wq_edid_wait;
 
@@ -67,6 +72,9 @@ struct tda998x_priv {
struct drm_connector connector;
 
struct tda998x_audio_port audio_port[2];
+   struct tda9950_glue cec_glue;
+   struct gpio_desc *calib;
+   struct cec_notifier *cec_notify;
 };
 
 #define conn_to_tda998x_priv(x) \
@@ -345,6 +353,12 @@ struct tda998x_priv {
 #define REG_CEC_INTSTATUS0xee/* read */
 # define CEC_INTSTATUS_CEC   (1 << 0)
 # define CEC_INTSTATUS_HDMI  (1 << 1)
+#define REG_CEC_CAL_XOSC_CTRL10xf2
+# define CEC_CAL_XOSC_CTRL1_ENA_CALBIT(0)
+#define REG_CEC_DES_FREQ2 0xf5
+# define CEC_DES_FREQ2_DIS_AUTOCAL BIT(7)
+#define REG_CEC_CLK   0xf6
+# define CEC_CLK_FRO  0x11
 #define REG_CEC_FRO_IM_CLK_CTRL   0xfb/* read/write */
 # define CEC_FRO_IM_CLK_CTRL_GHOST_DIS (1 << 7)
 # define CEC_FRO_IM_CLK_CTRL_ENA_OTP   (1 << 6)
@@ -359,6 +373,7 @@ struct tda998x_priv {
 # define CEC_RXSHPDLEV_HPD(1 << 1)
 
 #define REG_CEC_ENAMODS   0xff/* read/write */
+# define CEC_ENAMODS_EN_CEC_CLK   (1 << 7)
 # define CEC_ENAMODS_DIS_FRO  (1 << 6)
 # define CEC_ENAMODS_DIS_CCLK (1 << 5)
 # define CEC_ENAMODS_EN_RXSENS(1 << 2)
@@ -417,6 +432,114 @@ cec_read(struct tda998x_priv *priv, u8 addr)
return val;
 }
 
+static void cec_enamods(struct tda998x_priv *priv, u8 mods, bool enable)
+{
+   int val = cec_read(priv, REG_CEC_ENAMODS);
+
+   if (val < 0)
+   return;
+
+   if (enable)
+   val |= mods;
+   else
+   val &= ~mods;
+
+   cec_write(priv, REG_CEC_ENAMODS, val);
+}
+
+static void tda998x_cec_set_calibration(struct tda998x_priv *priv, bool enable)
+{
+   if (enable) {
+   u8 val;
+
+   cec_write(priv, 0xf3, 0xc0);
+   cec_write(priv, 0xf4, 0xd4);
+
+   /* Enable automatic calibration mode */
+   val = cec_read(priv, REG_CEC_DES_FREQ2);
+   val &= ~CEC_DES_FREQ2_DIS_AUTOCAL;
+   cec_write(priv, REG_CEC_DES_FREQ2, val);
+
+   /* Enable free running oscillator */
+   cec_write(priv, REG_CEC_CLK, CEC_CLK_FRO);
+   cec_enamods(priv, CEC_ENAMODS_DIS_FRO, false);
+
+   cec_write(priv, REG_CEC_CAL_XOSC_CTRL1,
+ CEC_CAL_XOSC_CTRL1_ENA_CAL);
+   } else {
+   cec_write(priv, REG_CEC_CAL_XOSC_CTRL1, 0);
+   }
+}
+
+/*
+ * Calibration for the internal oscillator: we need to set calibration mode,
+ * and then pulse the IRQ line low for a 10ms ± 1% period.
+ */
+static void tda998x_cec_calibration(struct tda998x_priv *priv)
+{
+   struct gpio_desc *calib = priv->calib;
+
+   mutex_lock(>edid_mutex);
+   if (priv->hdmi->irq > 0)
+   disable_irq(priv->hdmi->irq);
+   gpiod_direction_output(calib, 1);
+   tda998x_cec_set_calibration(priv, true);
+
+   local_irq_disable();
+   gpiod_set_value(calib, 0);
+   mdelay(10);
+   gpiod_set_value(calib, 1);
+   local_irq_enable();
+
+   tda998x_cec_set_calibration(priv, false);
+   gpiod_direction_input(calib);
+   if (priv->hdmi->irq > 0)
+   enable_irq(priv->hdmi->irq);
+   mutex_unlock(>edid_mutex);
+}
+
+static int tda998x_cec_hook_init(void *data)
+{
+   struct tda998x_priv *priv = data;
+   struct gpio_desc *calib;
+
+   

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171128 15:04]:
> Hi Tony,
> 
> > Am 28.11.2017 um 15:57 schrieb Tony Lindgren :
> > 
> > * H. Nikolaus Schaller  [171116 08:53]:
> >> Vendor string is "tpo" and not "toppoly".
> >> 
> >> Signed-off-by: H. Nikolaus Schaller 
> >> ---
> >> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> >> b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> index 4504908c23fe..ec27ed67a22a 100644
> >> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> >> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> >> @@ -86,7 +86,7 @@
> >> 
> >>/* lcd panel */
> >>lcd: td028ttec1@0 {
> >> -  compatible = "toppoly,td028ttec1";
> >> +  compatible = "tpo,td028ttec1";
> >>reg = <0>;
> >>spi-max-frequency = <10>;
> >>spi-cpol;
> > 
> > Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
> > like it can wait for v4.16 merge window.
> 
> Hm. Not really. It needs the panel driver to match. So either both or
> none should be applied or it will break the panel from working.
> 
> I am just 1-2 hours away from submitting a -v3 (rebased and tested
> on top of 4.15-rc1).

OK fine dropping both. Please update the description in both dts
patches to make it clear they are needed as a fix. Preferrably
with a proper fixes tag.

Having "We can remove the "omapdss," prefix" in the description sure
does not sounds like it's needed as a fix :)

Sounds like maybe these two should be just a single patch for
a proper fix?

Regards,

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

Re: [PATCH v2 11/18] drm/sun4i: Add A83T support

[Jernej Škrabec]

Hi,

Dne torek, 28. november 2017 ob 10:02:23 CET je Maxime Ripard napisal(a):
> Hi,
> 
> On Mon, Nov 27, 2017 at 05:01:49PM +0100, Jernej Škrabec wrote:
> > Dne ponedeljek, 27. november 2017 ob 16:41:35 CET je Maxime Ripard 
napisal(a):
> > > Add support for the A83T display pipeline.
> > > 
> > > Reviewed-by: Chen-Yu Tsai 
> > > Signed-off-by: Maxime Ripard 
> > > ---
> > > 
> > >  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 3 +++
> > >  drivers/gpu/drm/sun4i/sun4i_drv.c | 2 ++
> > >  drivers/gpu/drm/sun4i/sun4i_tcon.c| 5 +
> > >  drivers/gpu/drm/sun4i/sun8i_mixer.c   | 4 
> > >  4 files changed, 14 insertions(+)
> > > 
> > > diff --git
> > > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index
> > > d4259a4f5171..d6b52e5c48c0 100644
> > > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > > 
> > > @@ -93,6 +93,7 @@ Required properties:
> > > * allwinner,sun6i-a31s-tcon
> > > * allwinner,sun7i-a20-tcon
> > > * allwinner,sun8i-a33-tcon
> > > 
> > > +   * allwinner,sun8i-a83t-tcon-lcd
> > > 
> > > * allwinner,sun8i-v3s-tcon
> > >   
> > >   - reg: base address and size of memory-mapped region
> > >   - interrupts: interrupt associated to this IP
> > > 
> > > @@ -224,6 +225,7 @@ supported.
> > > 
> > >  Required properties:
> > >- compatible: value must be one of:
> > > +* allwinner,sun8i-a83t-de2-mixer
> > 
> > What will be the name of the second mixer, once support for HDMI is added?
> > Should we start directly with 0 and 1 postfix ?
> 
> What are the differences exactly without the two mixers?

Mixer properties:
- mixer index (0 or 1), important for determining CCSC base (see my patches)
- number of VI planes (usually 1)
- number of UI planes (usually 1 or 3)
- writeback support (yes/no)
- scale line buffer length (2048 or 4096)
- smart backligth support (yes/no)

channel properties (for both, VI and UI):
- scaler support (yes/no, usually yes)
- overlay count (seems to be always 4)
- VEP support (yes/no)

Those are properties found in BSP de_feat.c, so I guess that's enough to make 
any kind of decision in the code.

Usually, but we can't count on that, first mixer has 1 VI and 3 UI planes and 
second mixer has 1 VI and 1 UI plane.

Best regards,
Jernej

> 
> I was hoping to be able to cover them all using properties, indices
> are usually pretty badly received in compatibles.
> 
> > >  static const struct of_device_id sun8i_mixer_of_table[] = {
> > >  
> > >   {
> > > 
> > > + .compatible = "allwinner,sun8i-a83t-de2-mixer",
> > > + .data = _v3s_mixer_cfg,
> > > + },
> > > + {
> > 
> > Maybe you want to squash 12 patch since this works only by luck.
> 
> Yeah, I totally meant to do that :)
> 
> Thanks!
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

Re: [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

[Boris Ostrovsky]

On 11/28/2017 04:12 AM, Christian König wrote:
>
>
> How about the attached patch? It limits the newly added MMIO space to
> the upper 256GB of the address space. That should still be enough for
> most devices, but we avoid both issues with Xen dom0 as most likely
> problems with memory hotplug as well.

It certainly makes the problem to be less likely so I guess we could do
this for now.

Thanks.
-boris

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

[PATCH v3 2/4] omapdrm: panel: td028ttec1: replace MODULE_ALIAS by MODULE_DEVICE_TABLE

[H. Nikolaus Schaller]

to make it easier to keep in sync with the OF device table.

Signed-off-by: H. Nikolaus Schaller 
---
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c  | 12 ++--
 .../video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 11 +--
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index a0dfa14f4fab..2721a86ac5e7 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -460,9 +460,19 @@ static const struct of_device_id td028ttec1_of_match[] = {
 
 MODULE_DEVICE_TABLE(of, td028ttec1_of_match);
 
+static const struct spi_device_id td028ttec1_ids[] = {
+   { "toppoly,td028ttec1", 0 },
+   { "tpo,td028ttec1", 0},
+   { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(spi, td028ttec1_ids);
+
+
 static struct spi_driver td028ttec1_spi_driver = {
.probe  = td028ttec1_panel_probe,
.remove = td028ttec1_panel_remove,
+   .id_table   = td028ttec1_ids,
 
.driver = {
.name   = "panel-tpo-td028ttec1",
@@ -473,8 +483,6 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:tpo,td028ttec1");
-MODULE_ALIAS("spi:toppoly,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 4aeb908f2d1e..f6da8755b859 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -463,9 +463,18 @@ static const struct of_device_id td028ttec1_of_match[] = {
 
 MODULE_DEVICE_TABLE(of, td028ttec1_of_match);
 
+static const struct spi_device_id td028ttec1_ids[] = {
+   { "toppoly,td028ttec1", 0 },
+   { "tpo,td028ttec1", 0},
+   { /* sentinel */ }
+};
+
+MODULE_DEVICE_TABLE(spi, td028ttec1_ids);
+
 static struct spi_driver td028ttec1_spi_driver = {
.probe  = td028ttec1_panel_probe,
.remove = td028ttec1_panel_remove,
+   .id_table   = td028ttec1_ids,
 
.driver = {
.name   = "panel-tpo-td028ttec1",
@@ -476,8 +485,6 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
-MODULE_ALIAS("spi:tpo,td028ttec1");
-MODULE_ALIAS("spi:toppoly,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
 MODULE_LICENSE("GPL");
-- 
2.12.2

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

[PATCH 1/6] drm/i2c: tda998x: move mutex/waitqueue/timer/work init early

[Russell King]

Move the mutex, waitqueue, timer and detect work initialisation early
in the driver's initialisation, rather than being after we've registered
the CEC device.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 127815253a84..7f4dbca7f7f4 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1476,7 +1476,11 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
u32 video;
int rev_lo, rev_hi, ret;
 
-   mutex_init(>audio_mutex); /* Protect access from audio thread */
+   mutex_init(>mutex);   /* protect the page access */
+   mutex_init(>audio_mutex); /* protect access from audio thread */
+   init_waitqueue_head(>edid_delay_waitq);
+   timer_setup(>edid_delay_timer, tda998x_edid_delay_done, 0);
+   INIT_WORK(>detect_work, tda998x_detect_work);
 
priv->vip_cntrl_0 = VIP_CNTRL_0_SWAP_A(2) | VIP_CNTRL_0_SWAP_B(3);
priv->vip_cntrl_1 = VIP_CNTRL_1_SWAP_C(0) | VIP_CNTRL_1_SWAP_D(1);
@@ -1490,11 +1494,6 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
if (!priv->cec)
return -ENODEV;
 
-   mutex_init(>mutex);   /* protect the page access */
-   init_waitqueue_head(>edid_delay_waitq);
-   timer_setup(>edid_delay_timer, tda998x_edid_delay_done, 0);
-   INIT_WORK(>detect_work, tda998x_detect_work);
-
/* wake up the device: */
cec_write(priv, REG_CEC_ENAMODS,
CEC_ENAMODS_EN_RXSENS | CEC_ENAMODS_EN_HDMI);
-- 
2.7.4

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

[PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

We can remove the unnecessary "omapdss," prefix because
the omapdrm driver takes care of it when matching with
the driver table.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
 
lcd: lcd@1 {
reg = <1>;  /* CS1 */
-   compatible ="omapdss,tpo,td043mtea1";
+   compatible ="tpo,td043mtea1";
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
-- 
2.12.2

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

Re: [PATCH 08/17] drm/sun4i: Add support for DE2 VI planes

[Jernej Škrabec]

Hi!

Dne torek, 28. november 2017 ob 22:00:01 CET je Maxime Ripard napisal(a):
> Hi,
> 
> On Mon, Nov 27, 2017 at 09:57:41PM +0100, Jernej Skrabec wrote:
> > This commit adds basic support for VI planes. They are meant for video
> > overlay and because of that they support YUV formats too. However, using
> > YUV planes is not straightforward, so only RGB support for now.
> > 
> > Signed-off-by: Jernej Skrabec 
> > ---
> > 
> >  drivers/gpu/drm/sun4i/sun8i_layer.c |  40 +++---
> >  drivers/gpu/drm/sun4i/sun8i_mixer.c | 144
> >  +--- drivers/gpu/drm/sun4i/sun8i_mixer.h
> >  |  38 --
> >  3 files changed, 196 insertions(+), 26 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_layer.c
> > b/drivers/gpu/drm/sun4i/sun8i_layer.c index 49ccdd0149bd..e1b6ad82145e
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_layer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_layer.c
> > @@ -47,13 +47,22 @@ static int sun8i_mixer_layer_atomic_check(struct
> > drm_plane *plane,> 
> > true, true);
> >  
> >  }
> > 
> > +static void sun8i_mixer_layer_enable(struct sun8i_layer *layer, bool
> > enable) +{
> > +   struct sun8i_mixer *mixer = layer->mixer;
> > +
> > +   if (layer->id < mixer->cfg->vi_num)
> > +   sun8i_mixer_vi_layer_enable(mixer, layer->id, enable);
> > +   else
> > +   sun8i_mixer_ui_layer_enable(mixer, layer->id, enable);
> > +}
> > +
> > 
> >  static void sun8i_mixer_layer_atomic_disable(struct drm_plane *plane,
> >  
> >struct drm_plane_state 
> > *old_state)
> >  
> >  {
> >  
> > struct sun8i_layer *layer = plane_to_sun8i_layer(plane);
> > 
> > -   struct sun8i_mixer *mixer = layer->mixer;
> > 
> > -   sun8i_mixer_layer_enable(mixer, layer->id, false);
> > +   sun8i_mixer_layer_enable(layer, false);
> > 
> >  }
> >  
> >  static void sun8i_mixer_layer_atomic_update(struct drm_plane *plane,
> > 
> > @@ -63,14 +72,21 @@ static void sun8i_mixer_layer_atomic_update(struct
> > drm_plane *plane,> 
> > struct sun8i_mixer *mixer = layer->mixer;
> > 
> > if (!plane->state->visible) {
> > 
> > -   sun8i_mixer_layer_enable(mixer, layer->id, false);
> > +   sun8i_mixer_layer_enable(layer, false);
> > 
> > return;
> > 
> > }
> > 
> > -   sun8i_mixer_update_layer_coord(mixer, layer->id, plane);
> > -   sun8i_mixer_update_layer_formats(mixer, layer->id, plane);
> > -   sun8i_mixer_update_layer_buffer(mixer, layer->id, plane);
> > -   sun8i_mixer_layer_enable(mixer, layer->id, true);
> > +   if (layer->id < mixer->cfg->vi_num) {
> > +   sun8i_mixer_update_vi_layer_coord(mixer, layer->id, plane);
> > +   sun8i_mixer_update_vi_layer_formats(mixer, layer->id, plane);
> > +   sun8i_mixer_update_vi_layer_buffer(mixer, layer->id, plane);
> > +   } else {
> > +   sun8i_mixer_update_ui_layer_coord(mixer, layer->id, plane);
> > +   sun8i_mixer_update_ui_layer_formats(mixer, layer->id, plane);
> > +   sun8i_mixer_update_ui_layer_buffer(mixer, layer->id, plane);
> > +   }
> > +
> > +   sun8i_mixer_layer_enable(layer, true);
> 
> So you can probably tell by the patches I had in my other serie, but
> we should really split the UI and VI support in two files, especially
> since it has pretty much no code path or data in common (if you
> combine this patch with the YUV support).

Yeah, that would probably be best. But how to split it? sun8i_layer.c seems to 
be pretty common apart from those calls. Or would you prefer sun8i_[ui|
vi]_layer.c anyway? But that would mean having two sun8i_layers_init() 
functions which doesn't fit well into current concept afaik.

How would you split sun8i_mixer.c ? Leave common code (HW initialization) in 
it and create two new files sun8i_[ui|vi]_channel.c ? Common code could be 
later extended with zpos adjusting code.

Best regards,
Jernej

> 
> Maxime
> 
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com


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

[PATCH 4/6] drm/i2c: tda998x: always disable and clear interrupts at probe

[Russell King]

Always disable and clear interrupts at probe time to ensure that the
TDA998x is in a sane state.  This ensures that the interrupt line,
which is also the CEC clock calibration signal, is always deasserted.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 661cb8915f2f..e294f5b50236 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1547,6 +1547,15 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
cec_write(priv, REG_CEC_FRO_IM_CLK_CTRL,
CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
 
+   /* ensure interrupts are disabled */
+   cec_write(priv, REG_CEC_RXSHPDINTENA, 0);
+
+   /* clear pending interrupts */
+   cec_read(priv, REG_CEC_RXSHPDINT);
+   reg_read(priv, REG_INT_FLAGS_0);
+   reg_read(priv, REG_INT_FLAGS_1);
+   reg_read(priv, REG_INT_FLAGS_2);
+
/* initialize the optional IRQ */
priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
if (!priv->cec)
@@ -1558,11 +1567,6 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
/* init read EDID waitqueue and HDP work */
init_waitqueue_head(>wq_edid);
 
-   /* clear pending interrupts */
-   reg_read(priv, REG_INT_FLAGS_0);
-   reg_read(priv, REG_INT_FLAGS_1);
-   reg_read(priv, REG_INT_FLAGS_2);
-
irq_flags =
irqd_get_trigger_type(irq_get_irq_data(client->irq));
irq_flags |= IRQF_SHARED | IRQF_ONESHOT;
-- 
2.7.4

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

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Thomas Voegtle]

On Tue, 28 Nov 2017, Daniel Vetter wrote:


On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:

Some drivers like i915 start with crtc's enabled, but with deferred
fbcon setup they were no longer disabled as part of fbdev setup.
Headless units could no longer enter pc3 state because the crtc was
still enabled.

Fix this by calling restore_fbdev_mode when we would have called
it otherwise once during initial fbdev setup.

Signed-off-by: Maarten Lankhorst 
Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")


Please use dim fixes to get a more complete Cc: list for regression fixes.


Cc:  # v4.14+
Reported-by: Thomas Voegtle 


Reviewed-by: Daniel Vetter 

But please confirm with the reporter that it indeed fixes the issue before
pushing.
-Daniel


I re-checked the latest version of the patch and it indeed fixes the 
problem.


Thanks,

   Thomas

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

[PATCH 0/6] TDA998x CEC support

[Russell King - ARM Linux]

Hi,

This patch series adds CEC support to the DRM TDA998x driver.  The
TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
address from the HDMI encoder.

Implementation of the CEC part is separate to allow independent CEC
implementations, or independent HDMI implementations (since the
TDA9950 may be a separate device.)

 drivers/gpu/drm/i2c/Kconfig   |   6 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 507 ++
 drivers/gpu/drm/i2c/tda998x_drv.c | 246 +++--
 include/linux/platform_data/tda9950.h |  16 ++
 5 files changed, 748 insertions(+), 28 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/17] drm/sun4i: Refactor DE2 code

[Jernej Škrabec]

Hi!

Dne torek, 28. november 2017 ob 16:54:42 CET je Maxime Ripard napisal(a):
> Hi,
> 
> On Mon, Nov 27, 2017 at 09:57:34PM +0100, Jernej Skrabec wrote:
> > Since the time initial DE2 driver was written, some knowledge was gained
> > what setting are really necessary and what most of the magic values
> > mean.
> > 
> > This commit renames some of the macro names to better fit the real
> > meaning, replace default values with self explaining macros where
> > possible and removes settings which are not really needed.
> > 
> > Signed-off-by: Jernej Skrabec 
> 
> While those changes are quite welcome, it should be split in a number
> of patches...

You're right, I went over the changes again and now I have 8 patches instead 
of one with much more explanation why each change is needed.

I'll send v2 as soon as I get some feedback on rest of the series.

Regards,
Jernej

> 
> > ---
> > 
> >  drivers/gpu/drm/sun4i/sun8i_mixer.c | 65
> >  +++--
> >  drivers/gpu/drm/sun4i/sun8i_mixer.h | 31 --
> >  2 files changed, 47 insertions(+), 49 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index cb193c5f1686..015943c0ed5a
> > 100644
> > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > @@ -44,7 +44,8 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer *mixer,
> > 
> > /* Currently the first UI channel is used */
> > int chan = mixer->cfg->vi_num;
> > 
> > -   DRM_DEBUG_DRIVER("Enabling layer %d in channel %d\n", layer, chan);
> > +   DRM_DEBUG_DRIVER("%sabling layer %d in channel %d\n",
> > +enable ? "En" : "Dis", layer, chan);
> > 
> > if (enable)
> > 
> > val = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN;
> > 
> > @@ -55,15 +56,14 @@ void sun8i_mixer_layer_enable(struct sun8i_mixer
> > *mixer,> 
> >SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> >SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
> > 
> > -   /* Set the alpha configuration */
> > -   regmap_update_bits(mixer->engine.regs,
> > -  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> > -  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_MASK,
> > -  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MODE_DEF);
> > +   if (enable)
> > +   val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan);
> > +   else
> > +   val = 0;
> > +
> > 
> > regmap_update_bits(mixer->engine.regs,
> > 
> > -  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> > -  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_MASK,
> > -  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_ALPHA_DEF);
> > +  SUN8I_MIXER_BLEND_PIPE_CTL,
> > +  SUN8I_MIXER_BLEND_PIPE_CTL_EN(chan), val);
> 
> ... For example, this part right here will remove the alpha setup
> part, without any justification in the commit log ...
> 
> >  }
> >  
> >  static int sun8i_mixer_drm_format_to_layer(struct drm_plane *plane,
> > 
> > @@ -71,15 +71,15 @@ static int sun8i_mixer_drm_format_to_layer(struct
> > drm_plane *plane,> 
> >  {
> >  
> > switch (format) {
> > 
> > case DRM_FORMAT_ARGB:
> > -   *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_ARGB;
> > +   *mode = SUN8I_MIXER_FBFMT_ARGB;
> > 
> > break;
> > 
> > case DRM_FORMAT_XRGB:
> > -   *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_XRGB;
> > +   *mode = SUN8I_MIXER_FBFMT_XRGB;
> > 
> > break;
> > 
> > case DRM_FORMAT_RGB888:
> > -   *mode = SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_RGB888;
> > +   *mode = SUN8I_MIXER_FBFMT_RGB888;
> > 
> > break;
> > 
> > default:
> > @@ -107,7 +107,7 @@ int sun8i_mixer_update_layer_coord(struct sun8i_mixer
> > *mixer,> 
> >   state->crtc_h));
> > 
> > DRM_DEBUG_DRIVER("Updating blender size\n");
> > regmap_write(mixer->engine.regs,
> > 
> > -SUN8I_MIXER_BLEND_ATTR_INSIZE(0),
> > +SUN8I_MIXER_BLEND_ATTR_INSIZE(chan),
> 
> I guess that one is fixing a bug too.
> 
> >  SUN8I_MIXER_SIZE(state->crtc_w,
> >  
> >   state->crtc_h));
> > 
> > regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_OUTSIZE,
> > 
> > @@ -173,6 +173,7 @@ int sun8i_mixer_update_layer_formats(struct
> > sun8i_mixer *mixer,> 
> > return ret;
> > 
> > }
> > 
> > +   val <<= SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_OFFSET;
> > 
> > regmap_update_bits(mixer->engine.regs,
> > 
> >SUN8I_MIXER_CHAN_UI_LAYER_ATTR(chan, layer),
> >SUN8I_MIXER_CHAN_UI_LAYER_ATTR_FBFMT_MASK, val);
> > 
> > 

[PATCH 2/6] drm/i2c: tda998x: move CEC device initialisation later

[Russell King]

We no longer use the CEC client to access the CEC part itself, so we can
move this later in the initialisation sequence.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 7f4dbca7f7f4..4aeac2127974 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1490,9 +1490,6 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
priv->cec_addr = 0x34 + (client->addr & 0x03);
priv->current_page = 0xff;
priv->hdmi = client;
-   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
-   if (!priv->cec)
-   return -ENODEV;
 
/* wake up the device: */
cec_write(priv, REG_CEC_ENAMODS,
@@ -1546,6 +1543,10 @@ static int tda998x_create(struct i2c_client *client, 
struct tda998x_priv *priv)
CEC_FRO_IM_CLK_CTRL_GHOST_DIS | 
CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
 
/* initialize the optional IRQ */
+   priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
+   if (!priv->cec)
+   return -ENODEV;
+
if (client->irq) {
unsigned long irq_flags;
 
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v6 0/7] drm/fbdev: Panel orientation connector property support

[Daniel Vetter]

On Tue, Nov 28, 2017 at 02:36:09PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 28-11-17 11:27, Daniel Vetter wrote:
> > On Sat, Nov 25, 2017 at 06:33:34PM +0100, Hans de Goede wrote:
> > > Hi All,
> > > 
> > > Here is v6 of my series to add a "panel orientation" property to
> > > the drm-connector for the LCD panel to let userspace know about LCD
> > > panels which are not mounted upright, as well as detecting upside-down
> > > panels without needing quirks (like we do for 90 degree rotated screens).
> > > 
> > > Bartlomiej, can we please have your Acked-by for merging patches 1,
> > > 6 and 7 through the drm tree?
> > > 
> > > New in v6:
> > > -Fix / reference kernel-doc comments
> > > -Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI
> > > -Move i915 dsi hardware rotation state read-out to intel_dsi_init()
> > > 
> > > New in v5:
> > > -Add kernel-doc comment documenting drm_get_panel_orientation_quirk()
> > > -drm_fb_helper: Only use hardware (crtc primary plane) rotation for
> > >   180 degrees for now as 9-/270 degrees rotation requires special handling
> > > 
> > > New in v4:
> > > -Fix drm_fb_helper code setting an invalid rotation value on the primary
> > >   plane of disabled/unused crtcs (caught by Fi.CI)
> > > 
> > > New in v3:
> > > -As requested by Daniel v3 moves the quirks over from the fbdev
> > >   subsys to the drm subsys. I've done this by simpy starting with a copy 
> > > of
> > >   the quirk table and eventually removing the fbdev version.
> > > 
> > > The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5
> > > are all drm patches and patches 6-7 are fbdev/fbcon patches again. As
> > > discussed previously the plan is to merge all 7 patches through the
> > > drm tree.
> > 
> > I think from the drm and i915 side of things this all looks ready (well
> > pls double-check that CI also approves before merging).
> 
> The CI says state is warning, see:
> https://patchwork.freedesktop.org/series/32447/
> and specifically:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7290/shards.html
> 
> Which I find hard to read as I see no tests going to orange, only
> 3 tests moving to red, which AFAICT is failed. Clicking on the tests
> link to get history all 3 tests seem to fail in the same way quite
> often (2 out of 3) or somewhat often (the last one). Also the failures
> seem unrelated to my changes
> 
> So how do I deal with this, resend v7 to get CI to run again and hope
> I get a success result for all tests this time ?

-rc1 set CI on fire, we had to entirely disable reporting shard results.

Note that in the mail report you get annotations of known bugs, and the
skip<->pass flip-floppers are fallout from CI being on fire.

So looks all good to go.
-Daniel


> 
> > Just needs an ack/review from Bart, and then it's probably simplest if you
> > merge it all through drm-misc - the i915 side is tiny.
> 
> Ok, I will wait for an Ack from Bart and then merge this through drm-misc,
> thank you for the review.
> 
> Regards,
> 
> Hans
> 

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

Re: [PATCH 0/6] TDA998x CEC support

[Daniel Stone]

Hi,

On 29 November 2017 at 10:02, Daniel Vetter  wrote:
> On Wed, Nov 29, 2017 at 08:57:36AM +0100, Hans Verkuil wrote:
>> BTW, I didn't see this patch series appear on dri-devel, even though it is
>> CC-ed there. Odd.
>
> Moderation queue doesn't get flushed all that regularly for
> non-subscribers.

It's certainly there:
https://lists.freedesktop.org/archives/dri-devel/2017-November/158978.html

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

Re: [PATCH v2 4/4] backlight: as3711_bl: fix device-tree node leaks

[Lee Jones]

On Mon, 20 Nov 2017, Johan Hovold wrote:

> Two framebuffer device-node names were looked up during probe, but were
> only used as flags to indicate the presence of two framebuffer device.
> 
> Drop the unused framebuffer name along with a likewise unused device
> pointer from the driver data, and update the platform data to pass in
> booleans instead of the framebuffer strings. This allows us do drop the
> node references acquired during probe, which would otherwise leak.
> 
> Note that there are no other in-kernel users of the modified
> platform-data fields.
> 
> Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
> Cc: Guennadi Liakhovetski 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/video/backlight/as3711_bl.c | 12 ++--
>  include/linux/mfd/as3711.h  |  4 ++--
>  2 files changed, 8 insertions(+), 8 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/4] backlight: tps65217_bl: fix device-tree node lookup

[Lee Jones]

On Mon, 20 Nov 2017, Johan Hovold wrote:

> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
> 
> This would only cause trouble if the child node is missing while there
> is an unrelated node named "backlight" elsewhere in the tree.
> 
> Fixes: eebfdc17cc6c ("backlight: Add TPS65217 WLED driver")
> Cc: stable  # 3.7
> Cc: Matthias Kaehlcke 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/video/backlight/tps65217_bl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [GIT PULL] exynos-drm-next

[Daniel Vetter]

On Tue, Nov 28, 2017 at 02:45:49PM +0100, Marek Szyprowski wrote:
> Hi Daniel,
> 
> On 2017-11-20 08:33, Daniel Vetter wrote:
> > On Wed, Nov 15, 2017 at 10:26:45AM +0900, Inki Dae wrote:
> > > 2017년 11월 14일 13:22에 Dave Airlie 이(가) 쓴 글:
> > > > On 26 October 2017 at 11:37, Inki Dae  wrote:
> > > > > Improving Exynos DRM HDMI and Mixer drivers and also adding
> > > > > HDMI audio support.
> > > > > 
> > > > > Please kindly let me know if there is any problem.
> > > > > 
> > > > > Ps. we are reviewing IPP v2 driver[1] which controls post 
> > > > > processor devices
> > > > > such as FIMC, GScaler and Rotator of Exynos SoC. So I plan to 
> > > > > request
> > > > > git pull one more time after review.
> > > > I dropped the ball a bit here, I do think the second pull with IPP is
> > > > probably a bit late,
> > > > I think I'd like more assurance that the UAPI for IPP is to be used in
> > > > some upstream
> > > > shipping project (forks of mpv not withstanding, unless this fork
> > > > ships in some distro
> > > > or product).
> > > I also commented same thing internally to author - Marek - of IPP v2 but 
> > > I thought existing one is really ugly thing so may be better to change it 
> > > as soon as possible before other users use this one.
> > > Anyway, we will merge user space for IPP v2 to libdrm first, and then 
> > > Linux platform. I hope IPPv2 would be merged as soon as possible in next 
> > > turn.
> > Beyond what Daniel said we unfortunately don't have time machines, so
> > fixing bad uapi isn't really possible. The problem is that even if you
> > create ippv2, then people can still use ippv1, and it needs to keep
> > working (almost) forever. So once a bad uapi is in, it's in, and there's
> > no good reason to add more uapi (since in 2 years you might again realize
> > it's not a good idea) to "fix" that. You can't fix bad uapi.
> > 
> > That's why we have all these rules to make sure as little bad uapi as
> > possible lands, since the cost is so bad.
> > 
> > So yeah unless you have new hw that needs it, or there's another clear
> > need (performance, features), you're stuck with ippv1. "It's cleaner" is
> > not a good reason to rev uapi, since our experience with all the uapi in
> > drm clearly shows we can't predict the future :-)
> 
> I generally agree that UAPI interface has to be stable and well designed.
> 
> There are however some 'features' IPPv1 uapi that really allows us to
> obsolete it:
> 
> 1. IPP API can be optional in Exynos DRM, so userspace should not rely that
> it is always available and should have a software fallback in case it is not
> available.
> 
> 2. The only mode which was initially semi-working was memory-to-memory. The
> remaining modes (lcd-writeback and output) were never operational (both in
> mainline and even vendor kernels).
> 
> 3. IPP mainline uapi compatibility for memory-to-memory got broken very
> early by commit 083500baefd5f4c215a5a93aef2492c1aa775828 ("drm: remove
> DRM_FORMAT_NV12MT", which removed the support for tiled formats, the main
> feature which made this api somehow useful on Exynos platforms (video codec
> that time produced only tiled frames, to implement xvideo or any other
> video overlay, one has to detile them for proper display).
> 
> 4. Broken drivers. Especially once support for IOMMU has been added, it
> revealed that drivers don't configure DMA operations properly and in many
> cases operate outside the provided buffers trashing memory around.
> 
> 5. Need for external patches. Although IPP uapi has been used in some
> vendor kernels, but in such cases there were additional patches applied
> (like reverting mentioned 083500baefd5 patch) what means that those
> userspace apps which might use it, still won't work with the mainline
> version.
> 
> Right, as you already said we don't have time machines, so we cannot change
> it, but IPP extension should never have been merged to mainline in that
> form.
> 
> We can however obsolete it now as it is really non-functional and frankly
> speaking dead-code. If you agree with the above than at least the first
> patch can be merged, which clearly marks that Exynos IPP is broken and
> ever really functional. I bet no one will complain. Then we can continue
> the discussion about IPPv2 uapi/patches.

Ok, if what's currently is upstream is indeed entirely non-functional then
I think we can make a case for ippv2. But imo we should then also first
rip out ippv1. Which given that it's optional, and apparently your
userspace can cope, should be doable without causing any big trouble.

But now that you explained why ippv1 is a hopeless patient that won't make
it, why is ippv2 better? Do we have solid testcases for this stuff now? Is
the userspace production quality or still kinda just a tech demo?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing 

Re: [PATCH v3 0/7] drm/bridge: tc358767: fixes and improvements

[Andrzej Hajda]

On 07.11.2017 17:56, Andrey Gusakov wrote:
> This set of patches fixes several issues that was found during testing
> tc358767 with desktop DisplayPort displays.
>
> Changes since v3
>   - added comment about removed VPCTRL0 write
>   - corrected comment in "filter out too high modes"
>   - added sing-off
> Changes since v2:
>   - fixed maximum pixelclock frequency
>   - copyright patch added
>
> Andrey Gusakov (7):
>   drm/bridge: tc358767: do no fail on hi-res displays
>   drm/bridge: tc358767: filter out too high modes
>   drm/bridge: tc358767: fix DP0_MISC register set
>   drm/bridge: tc358767: fix timing calculations
>   drm/bridge: tc358767: fix AUXDATAn registers access
>   drm/bridge: tc358767: fix 1-lane behavior
>   drm/bridge: tc358767: add copyright lines
>
>  drivers/gpu/drm/bridge/tc358767.c |   75 
> +
>  1 file changed, 42 insertions(+), 33 deletions(-)
>

Andrey,

Is it OK if I queue patches 1-6 to drm-misc-fixes, and 7 to drm-misc-next?

Or I can put them all to drm-misc-next.

Any preferences?


Regards

Andrzej


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

[PATCH] drm: hibmc: Initialize the hibmc_bo_driver.io_mem_pfn

[msrb]

From: Michal Srb 

The io_mem_pfn field was added in ea642c3216cb2a60d1c0e760ae47ee85c9c16447 and
is used unconditionally. Most drivers were updated to set it to the default
implementation ttm_bo_default_io_mem_pfn, but hibmc was not.

This fixes crash in ttm_bo_vm_fault when hibmc driver is used.

Signed-off-by: Michal Srb 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
index 3518167a7dc4..0b165ce4ee00 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
@@ -243,6 +243,7 @@ struct ttm_bo_driver hibmc_bo_driver = {
.verify_access  = hibmc_bo_verify_access,
.io_mem_reserve = _ttm_io_mem_reserve,
.io_mem_free= NULL,
+   .io_mem_pfn = ttm_bo_default_io_mem_pfn,
 };
 
 int hibmc_mm_init(struct hibmc_drm_private *hibmc)
-- 
2.13.6

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

Re: Hardware 3D acceleration doesn't work anymore with the latest git kernel

[Michel Dänzer]

On 2017-11-27 01:20 PM, Christian König wrote:
> Am 27.11.2017 um 13:02 schrieb Michel Dänzer:
>> [SNIP]
>> I thought I did above...
>>
>> Commit f7871fd19389c5f64f625a4389675d0740f0dfe4 made the radeon driver
>> rely on ttm_populate_and_map_pages, which is implemented as:
>>
>> static inline int ttm_populate_and_map_pages(struct device *dev,
>> struct ttm_dma_tt *tt)
>> {
>> return -ENOMEM;
>> }
>>
>> when neither CONFIG_SWIOTLB nor CONFIG_INTEL_IOMMU is enabled.
>> Previously, the driver worked fine without either of those enabled.
> Ah! Sorry my fault. It looks like I incorrectly explained to Tom how to
> handle the config options.
> 
> Please take a look at the attached patch, it should fix the issue (going
> to send that one out separately once more).

[...]

>   * Output the state of pools to debugfs file
>   */
>  int ttm_page_alloc_debugfs(struct seq_file *m, void *data);
>  
> -
>  #if defined(CONFIG_SWIOTLB) || defined(CONFIG_INTEL_IOMMU)
>  /**
>   * Initialize pool allocator.

I'd drop the removal of this line, but either way,

Reviewed-by: Michel Dänzer 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Heiko Stübner]

Am Mittwoch, 29. November 2017, 10:54:18 CET schrieb Daniel Vetter:
> On Tue, Nov 28, 2017 at 03:42:36PM -0800, Doug Anderson wrote:
> > Hi,
> > 
> > On Sun, Nov 26, 2017 at 6:22 PM, Sandy Huang  wrote:
> > > Hi Daniel,
> > > 
> > > I register the account and get the drm-misc commit rights now,
> > > thanks.
> > > 
> > > 在 2017/11/24 22:51, Daniel Vetter 写道:
> > >> On Fri, Nov 24, 2017 at 09:28:59AM +0100, Heiko Stuebner wrote:
> > >>> Hi Daniel,
> > >>> 
> > >>> [somehow my email address seems to have gotten lost, so
> > >>> only saw this by chance on the list itself now.
> > >>> I've also re-added Sandy to the recipients]
> > >>> 
> > >>> Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter:
> >  On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> > > For personal reasons, Mark Yao will leave rockchip,
> > > can not continue maintain drm/rockchip, Sandy Huang
> > > will take over the drm/rockchip.
> > > 
> > > Cc: Sandy Huang 
> > > Cc: Heiko Stuebner 
> > > 
> > > Signed-off-by: Mark Yao 
> >  
> >  Since rockchip is in drm-misc that means we need a new maintainer who
> >  also
> >  has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going
> >  to
> >  be
> >  the new maintainer we need to fix that.
> >  
> >  Also, Heiko, are you interested in becoming co-maintainer? With
> >  commit
> >  rights and all.
> > >>> 
> > >>> I always feel somewhat inadequate judging the fast-paced drm stuff, as
> > >>> in
> > >>> the past once I got my head wrapped around something, drm always
> > >>> somehow moved another mile already ;-) .
> > >>> 
> > >>> But somewhere I read that drm-pace for big changes is supposed to slow
> > >>> a
> > >>> bit now that atomic modesetting is done in a lot of places, so we
> > >>> could
> > >>> give
> > >>> co-maintainership for the Rockchip-drm a try - with Sandy wearing the
> > >>> actual hat for big changes though ;-) .
> > >> 
> > >> Yeah I think on the modeset side it calmed down a lot. We're still
> > >> fine-tuning the helper libraries as we're figuring out better ways to
> > >> write drivers. But right now I think a lot of the action is all in
> > >> details
> > >> not relevant for many drivers.
> > >> 
> > >> If Sandy's ok with that too pls request an fd.o account for drm-misc
> > >> and
> > >> set up the tooling per our quickstart guide:
> > >> 
> > >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html#quickst
> > >> art
> > >> 
> > >> Thanks, Daniel
> > 
> > I just got a bounced mail from Mark Yao's old email address and
> > noticed that linux-next still shows him as the maintainer.  It'd be
> > great if we could land the change to update the MAINTAINERS file.  :-P
> 
> Patch just needs an ack from Heiko or Sean and it's good for Sandy to push
> to drm-misc.

Ok then, for the maintainer patch
Acked-by: Heiko Stuebner 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

[Daniel Vetter]

On Tue, Nov 28, 2017 at 12:30:30PM +, Sudip Mukherjee wrote:
> On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote:
> > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 27, 2017 at 08:52:19PM +, Sudip Mukherjee wrote:
> > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it 
> > > > > > with
> > > > > > the same code. Extract common part from PCI drivers into separate
> > > > > > remove_conflicting_pci_framebuffers().
> > > > > > 
> > > > > > Signed-off-by: Michał Mirosław 
> > > > > 
> > > > > Since the only driver that seems to use this is the staging one, 
> > > > > which imo
> > > > > is a DOA project, not sure it's worth to bother with this here.
> > > > 
> > > > afaik, this device is used in production by few manufacturers and it is
> > > > usefull for them to have it in the tree and the only reason it is still
> > > > in staging is because Tomi announced he will not take any new drivers in
> > > > fbdev. And, so I have not taken the initiative to properly move it out
> > > > of staging. I think Bartlomiej will also not accept new drivers in 
> > > > fbdev.
> > > 
> > > Imo, if no one cares about porting it to kms (which will give you an fbdev
> > > driver for free), then we should throw it out. At least I thought staging
> > > was only for stuff that had a reasonable chance to get mainlined. Not as a
> > > dumping ground for drivers that people use, but don't bother to get ready
> > > for mainline.
> > > 
> > > Greg?
> > 
> > Yes, if no one is working to get it out of staging, that means no one
> > cares about it, and it needs to be removed from the tree.
> 
> Agreed. I was not working on getting it out of staging as there is no
> place for it to go.
> But, Teddy Wang told me that they have a working drm driver for it, but
> it is not atomic like Daniel was asking for. If it is ok, then I can send
> in a patch to remove the existing sm750 from staging and add the new sm750
> drm driver to staging. And after it is ready, we can go ahead with moving
> it out of staging to drm.

Please keep the todo item that it needs to be converted to atomic. And
tbh, it's probably faster if you just submit it to dri-devel, assuming you
have time to work on it. For small drivers we tend to be fairly quick in
getting them into good enough shape.

Staging is also a major pain for drm subsystem refactorings, I really,
really, really prefer we don't add more than the vbox pain we have
already.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] TDA998x CEC support

[Daniel Vetter]

On Wed, Nov 29, 2017 at 08:57:36AM +0100, Hans Verkuil wrote:
> On 11/29/2017 08:41 AM, Hans Verkuil wrote:
> > Hi Russell,
> > 
> > On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> >> Hi,
> >>
> >> This patch series adds CEC support to the DRM TDA998x driver.  The
> >> TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> >> address from the HDMI encoder.
> >>
> >> Implementation of the CEC part is separate to allow independent CEC
> >> implementations, or independent HDMI implementations (since the
> >> TDA9950 may be a separate device.)
> > 
> > Thank you for this patch series! I assume you are testing this with a
> > BeagleBone Black? If so, do you have a patch for the dts that hooks up the
> > interrupt? If possible, I'd like to test this with my BBB.
> 
> BTW, I didn't see this patch series appear on dri-devel, even though it is
> CC-ed there. Odd.

Moderation queue doesn't get flushed all that regularly for
non-subscribers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/atomic: make drm_atomic_helper_wait_for_vblanks more agressive

[Lucas Stach]

drm_atomic_helper_setup_commit expects that flipping of previous commits
has happened when it is called to set up a new commit. This can be violated
by commits where userspace doesn't get a flip completion event to
synchronize against i.e. legacy modesets and property changes.

The expectation is that those are done by blocking commits, which wait for
completion. Most drivers call drm_atomic_helper_wait_for_vblanks in the
commit_tail to ensure completion, but the wait for next vblank might not
actually happen if the commit didn't change any planes.

Make the wait more agressive by also waiting if no planes changed. This
is the minimal regression fix for the 4.15 kernel series. Long term
drivers should switch away from drm_atomic_helper_wait_for_vblanks and
use drm_atomic_helper_wait_for_flip_done instead.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/drm_atomic_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 71d712f1b56a..b16f1d69a0bb 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1225,7 +1225,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device *dev,
return;
 
for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
new_crtc_state, i) {
-   if (!new_crtc_state->active || !new_crtc_state->planes_changed)
+   if (!new_crtc_state->active)
continue;
 
ret = drm_crtc_vblank_get(crtc);
-- 
2.11.0

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

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103791

--- Comment #8 from denisgolo...@yandex.ru ---
Any news on that?
Should I report some more information/logs/etc?

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

Re: [PATCH v2 1/4] backlight: as3711_bl: fix device-tree node lookup

[Lee Jones]

On Mon, 20 Nov 2017, Johan Hovold wrote:

> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
> 
> To make things worse, the parent mfd node was also prematurely freed.
> 
> Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support")
> Cc: stable  # 3.10
> Cc: Guennadi Liakhovetski 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/video/backlight/as3711_bl.c | 33 +++--
>  1 file changed, 23 insertions(+), 10 deletions(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] backlight: max8925_bl: fix device-tree node lookup

[Lee Jones]

On Mon, 20 Nov 2017, Johan Hovold wrote:

> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
> 
> To make things worse, the parent mfd node was also prematurely freed,
> while the child backlight node was leaked.
> 
> Fixes: 47ec340cb8e2 ("mfd: max8925: Support dt for backlight")
> Cc: stable  # 3.9
> Cc: Qing Xu 
> Cc: Haojian Zhuang 
> Signed-off-by: Johan Hovold 
> ---
>  drivers/video/backlight/max8925_bl.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

[Daniel Vetter]

On Tue, Nov 28, 2017 at 03:42:36PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Sun, Nov 26, 2017 at 6:22 PM, Sandy Huang  wrote:
> > Hi Daniel,
> > I register the account and get the drm-misc commit rights now, thanks.
> >
> >
> > 在 2017/11/24 22:51, Daniel Vetter 写道:
> >>
> >> On Fri, Nov 24, 2017 at 09:28:59AM +0100, Heiko Stuebner wrote:
> >>>
> >>> Hi Daniel,
> >>>
> >>> [somehow my email address seems to have gotten lost, so
> >>> only saw this by chance on the list itself now.
> >>> I've also re-added Sandy to the recipients]
> >>>
> >>> Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter:
> 
>  On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:
> >
> > For personal reasons, Mark Yao will leave rockchip,
> > can not continue maintain drm/rockchip, Sandy Huang
> > will take over the drm/rockchip.
> >
> > Cc: Sandy Huang 
> > Cc: Heiko Stuebner 
> >
> > Signed-off-by: Mark Yao 
> 
> 
>  Since rockchip is in drm-misc that means we need a new maintainer who
>  also
>  has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to
>  be
>  the new maintainer we need to fix that.
> 
>  Also, Heiko, are you interested in becoming co-maintainer? With commit
>  rights and all.
> >>>
> >>>
> >>> I always feel somewhat inadequate judging the fast-paced drm stuff, as in
> >>> the past once I got my head wrapped around something, drm always
> >>> somehow moved another mile already ;-) .
> >>>
> >>> But somewhere I read that drm-pace for big changes is supposed to slow a
> >>> bit now that atomic modesetting is done in a lot of places, so we could
> >>> give
> >>> co-maintainership for the Rockchip-drm a try - with Sandy wearing the
> >>> actual hat for big changes though ;-) .
> >>
> >>
> >> Yeah I think on the modeset side it calmed down a lot. We're still
> >> fine-tuning the helper libraries as we're figuring out better ways to
> >> write drivers. But right now I think a lot of the action is all in details
> >> not relevant for many drivers.
> >>
> >> If Sandy's ok with that too pls request an fd.o account for drm-misc and
> >> set up the tooling per our quickstart guide:
> >>
> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html#quickstart
> >>
> >> Thanks, Daniel
> 
> I just got a bounced mail from Mark Yao's old email address and
> noticed that linux-next still shows him as the maintainer.  It'd be
> great if we could land the change to update the MAINTAINERS file.  :-P

Patch just needs an ack from Heiko or Sean and it's good for Sandy to push
to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103808] [radeonsi, bisected] World of Warcraft scribbling all over screen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103808

--- Comment #11 from bartos.p...@gmail.com ---
Confirming bug 103919 is also fixed.

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

Re: [Intel-gfx] [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

On 11/28/2017 10:30 AM, Ville Syrjälä wrote:
>> +dev_priv->bridge_dev =
>> +pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0));
> Maybe just pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) ?
> 
> I guess if we want to be pedantic we could go for:
> 
> bus = pci_find_host_bridge(pdev->bus)->bus;
> pci_get_slot(bus, PCI_DEVFN(0, 0))
> 
> but I think the GPU should always be on the root bus, so the simpler
> form should be fine.
> 

All three of these should be correct. 

I'll use pci_get_slot(pdev->bus, PCI_DEVFN(0, 0)) as you suggested.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: rcar-du: calculate DPLLCR to be more small jitter

[Kuninori Morimoto]

From: Kuninori Morimoto 

In general, PLL has VCO (= Voltage controlled oscillator),
one of the very important electronic feature called as "jitter"
is related to this VCO.
In academic generalism, VCO should be maximum to be more small jitter.
In high frequency clock, jitter will be large impact.
Thus, selecting Hi VCO is general theory.

   fin fvcofout  fclkout
in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> out
 +-> |  | |
 ||
 +-[1/N]<-+

fclkout = fvco / P / FDPLL -- (1)

In PD, it will loop until fin/M = fvco/P/N

fvco = fin * P *  N / M -- (2)

(1) + (2) indicates, fclkout = fin * N / M / FDPLL
In this device, N = (n + 1), M = (m + 1), P = 2, thus

fout = fin * (n + 1) / (m + 1) / FDPLL

This is the datasheet formula.
One note here is that it should be 2000 < fvco < 4096MHz
To be smaller jitter, fvco should be maximum,
in other words, N as large as possible, M as small as possible driver
should select. Here, basically M=1.
This patch do it.

Reported-by: HIROSHI INOSE 
Signed-off-by: Kuninori Morimoto 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 36 --
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index b492063..45540fe 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -125,8 +125,40 @@ static void rcar_du_dpll_divider(struct rcar_du_crtc 
*rcrtc,
unsigned int m;
unsigned int n;
 
-   for (n = 39; n < 120; n++) {
-   for (m = 0; m < 4; m++) {
+   /*
+*   fin fvcofout   fclkout
+* in --> [1/M] --> |PD| -> [LPF] -> [VCO] -> [1/P] -+-> [1/FDPLL] -> 
out
+*  +-> |  | |
+*  ||
+*  +-[1/N]<-+
+*
+*  fclkout = fvco / P / FDPLL -- (1)
+*
+* fin/M = fvco/P/N
+*
+*  fvco = fin * P *  N / M -- (2)
+*
+* (1) + (2) indicates
+*
+*  fclkout = fin * N / M / FDPLL
+*
+* NOTES
+*  N = (n + 1), M = (m + 1), P = 2
+*  2000 < fvco < 4096Mhz
+*  Basically M=1
+*
+* To be small jitter,
+* N : as large as possible
+* M : as small as possible
+*/
+   for (m = 0; m < 4; m++) {
+   for (n = 119; n > 40; n--) {
+   unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
+
+   if ((fvco < 2000) ||
+   (fvco > 409600ll))
+   continue;
+
for (fdpll = 1; fdpll < 32; fdpll++) {
unsigned long output;
 
-- 
1.9.1

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

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[H . Nikolaus Schaller]

Hi,

> Am 28.11.2017 um 17:18 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 16:17]:
>> Hi Tony,
>> 
>>> Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
>>> 
>>> * H. Nikolaus Schaller  [171128 15:52]:
 We can remove the unnecessary "omapdss," prefix because
 the omapdrm driver takes care of it when matching with
 the driver table.
>>> 
>>> So is this needed as a fix or is this another clean-up?
>>> 
>>> So is this is really needed as a fix?
>> 
>> Hm. How do you differentiate between "fix" and "cleanup"?
>> Maybe it is more a wording than a content issue...
>> 
>> For me it is a "fix" because it is semantically wrong to have
>> a prefix where it is not needed. And "fixing" it changes the
>> compiler output by 8 bytes.
> 
> How about let's call it a "typo fix" then? :)

Well, it is not really a typo.

> 
>> "Cleanup" would be for me removing whitespace or empty lines
>> or typos in comments.
>> 
>>> If this is just clean-up, again, please resend once the driver
>>> changes have cleared.
>> 
>> There is no change to the pandora driver involved here. The Pandora
>> panel driver is already correct. Just the DTS has some redundant
>> content which should be removed.
>> 
>> So there is no dependency for this patch.
> 
> OK please resend separately after the driver changes have merged
> then.

The Pandora driver does not need an update. Only the DTS.
So there is noting to merge or wait for.

Maybe the confusion comes that in both cases (GTA04 and OpenPandora)
there are changes to DTS.

But different ones.

GTA04: change vendor prefix to make it consistent
Pandora: remove redundant (unnecessary and potentially wrong) omapdss, prefix

In addition we have to modify the GTA04 panel to handle the correct
vendor prefix. The Pandora panel already uses the right one.

Anyways, I think it is now Tomi to decide about the panel driver
(vendor prefix) patch 1/4 and 2/4 first. Then we can sort out
the DTS changes (3/4 and 4/4).

BR and thanks,
Nikolaus

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

Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string

[H. Nikolaus Schaller]

Hi Tony,

> Am 28.11.2017 um 17:04 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 15:52]:
>> We can remove the unnecessary "omapdss," prefix because
>> the omapdrm driver takes care of it when matching with
>> the driver table.
> 
> So is this needed as a fix or is this another clean-up?
> 
> So is this is really needed as a fix?

Hm. How do you differentiate between "fix" and "cleanup"?
Maybe it is more a wording than a content issue...

For me it is a "fix" because it is semantically wrong to have
a prefix where it is not needed. And "fixing" it changes the
compiler output by 8 bytes.

"Cleanup" would be for me removing whitespace or empty lines
or typos in comments.

> 
> If this is just clean-up, again, please resend once the driver
> changes have cleared.

There is no change to the pandora driver involved here. The Pandora
panel driver is already correct. Just the DTS has some redundant
content which should be removed.

So there is no dependency for this patch.

BR,
Nikolaus

> 
> Regards,
> 
> Tony
> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi 
>> b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> index 53e007abdc71..64d967ec8c58 100644
>> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> @@ -626,7 +626,7 @@
>> 
>>  lcd: lcd@1 {
>>  reg = <1>;  /* CS1 */
>> -compatible ="omapdss,tpo,td043mtea1";
>> +compatible ="tpo,td043mtea1";
>>  spi-max-frequency = <10>;
>>  spi-cpol;
>>  spi-cpha;
>> -- 
>> 2.12.2
>> 

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

[PATCH v3 3/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Official vendor string is now "tpo" and not "toppoly".

Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
 
/* lcd panel */
lcd: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
-- 
2.12.2

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

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

> Am 28.11.2017 um 17:00 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171128 15:51]:
>>> Am 28.11.2017 um 16:10 schrieb Tony Lindgren :
>>> OK fine dropping both. Please update the description in both dts
>>> patches to make it clear they are needed as a fix. Preferrably
>>> with a proper fixes tag.
>> 
>> Well, it is not "needed" in a strong sense since current mainline
>> works. It is more a style and consistency fix to use "tpo," everywhere.
>> 
>>> 
>>> Having "We can remove the "omapdss," prefix" in the description sure
>>> does not sounds like it's needed as a fix :)
>> 
>> The description has been improved on -v3.
> 
> Thanks.
> 
>>> Sounds like maybe these two should be just a single patch for
>>> a proper fix?
>> 
>> Hm. I usually get the feedback to separate DT and driver fixes into
>> separate commits... Therefore I submit patch sets in the hope they
>> are not picked apart :)
> 
> See "both dts patches" part above. Yes the dts patches can and should
> be sent separately. In almost every case if the dts patches cannot be
> applied separately it means your driver changes are breaking things.

That is why the v3 driver now accepts both, the old and the new vendor
name. This means applying the driver alone is safe. Applying or not
applying DTS patch afterwards is also safe.

BR,
Nikolaus

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

Re: omapfb/dss: Delete an error message for a failed memory allocation in three functions

[Ladislav Michl]

On Tue, Nov 28, 2017 at 01:13:51PM +0100, SF Markus Elfring wrote:
> Additional improvement possibilities can be taken into account
> after corresponding software development discussions, can't they?

Sure, but that is in contrary to all you replies. I guess you are
familiar with Documentation/process/submitting-patches.rst chapter 8.
No matter that patch was generated or suggested by a tool, you sent
it and normal review procedure follows. And here you ignored _all_
suggestions and concentrate solely on improving Coccinelle scripts.

On kernel related lists suggestions to patch itself are discussed.
Whenever you take them into account while developing Coccinelle
is up to you (on the Cocci list).

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

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[H. Nikolaus Schaller]

Hi Tony,

> Am 28.11.2017 um 15:57 schrieb Tony Lindgren :
> 
> * H. Nikolaus Schaller  [171116 08:53]:
>> Vendor string is "tpo" and not "toppoly".
>> 
>> Signed-off-by: H. Nikolaus Schaller 
>> ---
>> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
>> b/arch/arm/boot/dts/omap3-gta04.dtsi
>> index 4504908c23fe..ec27ed67a22a 100644
>> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
>> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
>> @@ -86,7 +86,7 @@
>> 
>>  /* lcd panel */
>>  lcd: td028ttec1@0 {
>> -compatible = "toppoly,td028ttec1";
>> +compatible = "tpo,td028ttec1";
>>  reg = <0>;
>>  spi-max-frequency = <10>;
>>  spi-cpol;
> 
> Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
> like it can wait for v4.16 merge window.

Hm. Not really. It needs the panel driver to match. So either both or
none should be applied or it will break the panel from working.

I am just 1-2 hours away from submitting a -v3 (rebased and tested
on top of 4.15-rc1).

BR and thanks,
Nikolaus

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

[PATCH 5/6] drm/i2c: tda9950: add CEC driver

[Russell King]

Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device,
but is also integrated into HDMI transceivers such as the TDA9989 and
TDA19989.

The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol.  The driver just has to read and write
the messages, and handle error conditions.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/Kconfig   |   5 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 507 ++
 include/linux/platform_data/tda9950.h |  16 ++
 4 files changed, 529 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda9950.c
 create mode 100644 include/linux/platform_data/tda9950.h

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index a6c92beb410a..3a232f5ff0a1 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
help
  Support for NXP Semiconductors TDA998X HDMI encoders.
 
+config DRM_I2C_NXP_TDA9950
+   tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
+   select CEC_NOTIFIER
+   select CEC_CORE
+
 endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index b20100c18ffb..a962f6f08568 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
 
 tda998x-y := tda998x_drv.o
 obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
new file mode 100644
index ..6f7a37ddda05
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -0,0 +1,507 @@
+/*
+ *  TDA9950 Consumer Electronics Control driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * The NXP TDA9950 implements the HDMI Consumer Electronics Control
+ * interface.  The host interface is similar to a mailbox: the data
+ * registers starting at REG_CDR0 are written to send a command to the
+ * internal CPU, and replies are read from these registers.
+ *
+ * As the data registers represent a mailbox, they must be accessed
+ * as a single I2C transaction.  See the TDA9950 data sheet for details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   REG_CSR = 0x00,
+   CSR_BUSY = BIT(7),
+   CSR_INT  = BIT(6),
+   CSR_ERR  = BIT(5),
+
+   REG_CER = 0x01,
+
+   REG_CVR = 0x02,
+
+   REG_CCR = 0x03,
+   CCR_RESET = BIT(7),
+   CCR_ON= BIT(6),
+
+   REG_ACKH = 0x04,
+   REG_ACKL = 0x05,
+
+   REG_CCONR = 0x06,
+   CCONR_ENABLE_ERROR = BIT(4),
+   CCONR_RETRY_MASK = 7,
+
+   REG_CDR0 = 0x07,
+
+   CDR1_REQ = 0x00,
+   CDR1_CNF = 0x01,
+   CDR1_IND = 0x81,
+   CDR1_ERR = 0x82,
+   CDR1_IER = 0x83,
+
+   CDR2_CNF_SUCCESS= 0x00,
+   CDR2_CNF_OFF_STATE  = 0x80,
+   CDR2_CNF_BAD_REQ= 0x81,
+   CDR2_CNF_CEC_ACCESS = 0x82,
+   CDR2_CNF_ARB_ERROR  = 0x83,
+   CDR2_CNF_BAD_TIMING = 0x84,
+   CDR2_CNF_NACK_ADDR  = 0x85,
+   CDR2_CNF_NACK_DATA  = 0x86,
+};
+
+struct tda9950_priv {
+   struct i2c_client *client;
+   struct device *hdmi;
+   struct cec_adapter *adap;
+   struct tda9950_glue *glue;
+   u16 addresses;
+   struct cec_msg rx_msg;
+   struct cec_notifier *notify;
+   bool open;
+};
+
+static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg;
+   u8 buf[cnt + 1];
+   int ret;
+
+   buf[0] = addr;
+   memcpy(buf + 1, p, cnt);
+
+   msg.addr = client->addr;
+   msg.flags = 0;
+   msg.len = cnt + 1;
+   msg.buf = buf;
+
+   dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
+
+   ret = i2c_transfer(client->adapter, , 1);
+   if (ret < 0)
+   dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
addr);
+   return ret < 0 ? ret : 0;
+}
+
+static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
+{
+   tda9950_write_range(client, addr, , 1);
+}
+
+static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg[2];
+   int ret;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].len = 1;
+   msg[0].buf = 
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].len = cnt;
+   msg[1].buf = p;
+
+   ret = i2c_transfer(client->adapter, msg, 2);
+   if (ret < 0)
+   dev_err(>dev, "Error %d reading from cec:0x%x\n", ret, 
addr);
+
+   dev_dbg(>dev, "rd 0x%02x: %*ph\n", addr, cnt, p);
+
+   return ret;
+}
+
+static u8 

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171128 15:51]:
> > Am 28.11.2017 um 16:10 schrieb Tony Lindgren :
> > OK fine dropping both. Please update the description in both dts
> > patches to make it clear they are needed as a fix. Preferrably
> > with a proper fixes tag.
> 
> Well, it is not "needed" in a strong sense since current mainline
> works. It is more a style and consistency fix to use "tpo," everywhere.
> 
> > 
> > Having "We can remove the "omapdss," prefix" in the description sure
> > does not sounds like it's needed as a fix :)
> 
> The description has been improved on -v3.

Thanks.

> > Sounds like maybe these two should be just a single patch for
> > a proper fix?
> 
> Hm. I usually get the feedback to separate DT and driver fixes into
> separate commits... Therefore I submit patch sets in the hope they
> are not picked apart :)

See "both dts patches" part above. Yes the dts patches can and should
be sent separately. In almost every case if the dts patches cannot be
applied separately it means your driver changes are breaking things.

Regards,

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

[PATCH resend V3 24/29] backlight: deprecate pci_get_bus_and_slot()

[Sinan Kaya]

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.

Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().

Hard-coding the domain as 0.

Acked-by: Jingoo Han 
Acked-by: Daniel Thompson 
Signed-off-by: Sinan Kaya 
---
 drivers/video/backlight/apple_bl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/backlight/apple_bl.c 
b/drivers/video/backlight/apple_bl.c
index d843296..6a34ab9 100644
--- a/drivers/video/backlight/apple_bl.c
+++ b/drivers/video/backlight/apple_bl.c
@@ -143,7 +143,7 @@ static int apple_bl_add(struct acpi_device *dev)
struct pci_dev *host;
int intensity;
 
-   host = pci_get_bus_and_slot(0, 0);
+   host = pci_get_domain_bus_and_slot(0, 0, 0);
 
if (!host) {
pr_err("unable to find PCI host\n");
-- 
1.9.1

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

[PATCH v3 1/4] omapdrm: panel: fix compatible vendor string for td028ttec1

[H. Nikolaus Schaller]

The vendor name was "toppoly" but other panels and the vendor list
have defined it as "tpo". So let's fix it in driver and bindings.

We keep the old definition in parallel to stay compatible with
potential older DTB setup.

Signed-off-by: H. Nikolaus Schaller 
---
 .../display/panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}  | 4 ++--
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c   | 3 +++
 drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 3 +++
 3 files changed, 8 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt 
=> tpo,td028ttec1.txt} (84%)

diff --git 
a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt 
b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
similarity index 84%
rename from 
Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
rename to Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
index 7175dc3740ac..ed34253d9fb1 100644
--- a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt
+++ b/Documentation/devicetree/bindings/display/panel/tpo,td028ttec1.txt
@@ -2,7 +2,7 @@ Toppoly TD028TTEC1 Panel
 
 
 Required properties:
-- compatible: "toppoly,td028ttec1"
+- compatible: "tpo,td028ttec1"
 
 Optional properties:
 - label: a symbolic name for the panel
@@ -14,7 +14,7 @@ Example
 ---
 
 lcd-panel: td028ttec1@0 {
-   compatible = "toppoly,td028ttec1";
+   compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <10>;
spi-cpol;
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c 
b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
index 0a38a0e8c925..a0dfa14f4fab 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c
@@ -452,6 +452,8 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
+   { .compatible = "omapdss,tpo,td028ttec1", },
+   /* keep to not break older DTB */
{ .compatible = "omapdss,toppoly,td028ttec1", },
{},
 };
@@ -471,6 +473,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_ALIAS("spi:toppoly,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c 
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 57e9e146ff74..4aeb908f2d1e 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -455,6 +455,8 @@ static int td028ttec1_panel_remove(struct spi_device *spi)
 }
 
 static const struct of_device_id td028ttec1_of_match[] = {
+   { .compatible = "omapdss,tpo,td028ttec1", },
+   /* keep to not break older DTB */
{ .compatible = "omapdss,toppoly,td028ttec1", },
{},
 };
@@ -474,6 +476,7 @@ static struct spi_driver td028ttec1_spi_driver = {
 
 module_spi_driver(td028ttec1_spi_driver);
 
+MODULE_ALIAS("spi:tpo,td028ttec1");
 MODULE_ALIAS("spi:toppoly,td028ttec1");
 MODULE_AUTHOR("H. Nikolaus Schaller ");
 MODULE_DESCRIPTION("Toppoly TD028TTEC1 panel driver");
-- 
2.12.2

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

[PATCH v3 0/4] Fixes for omapdrm on OpenPandora and GTA04

[H. Nikolaus Schaller]

Changes V3:
* stay compatible with old DTB files which still use "toppoly" (suggested by 
Tomi Valkeinen)
* replaced MODULE_ALIAS entries by MODULE_DEVICE_TABLE (suggested by Andrew F. 
Davis)
* removed DSI VDDS patch as it has already been accepted

2017-11-16 09:50:22: Changes V2:
* replaced patch to fix DSI VDDS for OMAP3 by equivalent patch from Laurent 
Pinchart
* keep previous compatibility option in panel driver to handle older device 
tree binaries

2017-11-08 22:09:36:
This patch set fixes vendor names of the panels
and fixes a problem on omapdrm with enabling
VDD_DSI for OMAP3 which is needed for displaying
the Red and Green channel on OMAP3530 (Pandora).

H. Nikolaus Schaller (4):
  omapdrm: panel: fix compatible vendor string for td028ttec1
  omapdrm: panel: td028ttec1: replace MODULE_ALIAS by
MODULE_DEVICE_TABLE
  DTS: GTA04: fix panel compatibility string
  DTS: Pandora: fix panel compatibility string

 .../panel/{toppoly,td028ttec1.txt => tpo,td028ttec1.txt}|  4 ++--
 arch/arm/boot/dts/omap3-gta04.dtsi  |  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi |  2 +-
 drivers/gpu/drm/omapdrm/displays/panel-tpo-td028ttec1.c | 13 -
 .../fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c  | 12 +++-
 5 files changed, 27 insertions(+), 6 deletions(-)
 rename Documentation/devicetree/bindings/display/panel/{toppoly,td028ttec1.txt 
=> tpo,td028ttec1.txt} (84%)

-- 
2.12.2

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

Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string

[Tony Lindgren]

* H. Nikolaus Schaller  [171116 08:53]:
> Vendor string is "tpo" and not "toppoly".
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi 
> b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..ec27ed67a22a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -86,7 +86,7 @@
>  
>   /* lcd panel */
>   lcd: td028ttec1@0 {
> - compatible = "toppoly,td028ttec1";
> + compatible = "tpo,td028ttec1";
>   reg = <0>;
>   spi-max-frequency = <10>;
>   spi-cpol;

Applying into omap-for-v4.15/fixes thanks. The other dts patch seems
like it can wait for v4.16 merge window.

Regards,

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

[PATCH] drm/bridge/sii8620: start MHL transmission after HDMI signal detection

[Maciej Purski]

The vendor code waits for infoframe to detect video mode set by source.
We do not need to follow this pattern, because video mode information is
provided by drm core. As a result most of the infoframe handling
code can be removed.

Start transmission immediately after detecting stream on HDMI lines
in irq_scdt() function without waiting for infoframe interrupt.

Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 53 ++--
 1 file changed, 2 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 86789f8..e81c96a 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -1925,14 +1925,6 @@ static void sii8620_irq_edid(struct sii8620 *ctx)
ctx->mt_state = MT_STATE_DONE;
 }
 
-static void sii8620_scdt_high(struct sii8620 *ctx)
-{
-   sii8620_write_seq_static(ctx,
-   REG_INTR8_MASK, BIT_CEA_NEW_AVI | BIT_CEA_NEW_VSI,
-   REG_TPI_SC, BIT_TPI_SC_TPI_OUTPUT_MODE_0_HDMI,
-   );
-}
-
 static void sii8620_irq_scdt(struct sii8620 *ctx)
 {
u8 stat = sii8620_readb(ctx, REG_INTR5);
@@ -1940,53 +1932,13 @@ static void sii8620_irq_scdt(struct sii8620 *ctx)
if (stat & BIT_INTR_SCDT_CHANGE) {
u8 cstat = sii8620_readb(ctx, REG_TMDS_CSTAT_P3);
 
-   if (cstat & BIT_TMDS_CSTAT_P3_SCDT) {
-   if (ctx->sink_type == SINK_HDMI)
-   /* enable infoframe interrupt */
-   sii8620_scdt_high(ctx);
-   else
-   sii8620_start_video(ctx);
-   }
+   if (cstat & BIT_TMDS_CSTAT_P3_SCDT)
+   sii8620_start_video(ctx);
}
 
sii8620_write(ctx, REG_INTR5, stat);
 }
 
-static void sii8620_new_vsi(struct sii8620 *ctx)
-{
-   u8 vsif[11];
-
-   sii8620_write(ctx, REG_RX_HDMI_CTRL2,
- VAL_RX_HDMI_CTRL2_DEFVAL |
- BIT_RX_HDMI_CTRL2_VSI_MON_SEL_VSI);
-   sii8620_read_buf(ctx, REG_RX_HDMI_MON_PKT_HEADER1, vsif,
-ARRAY_SIZE(vsif));
-}
-
-static void sii8620_new_avi(struct sii8620 *ctx)
-{
-   sii8620_write(ctx, REG_RX_HDMI_CTRL2, VAL_RX_HDMI_CTRL2_DEFVAL);
-   sii8620_read_buf(ctx, REG_RX_HDMI_MON_PKT_HEADER1, ctx->avif,
-ARRAY_SIZE(ctx->avif));
-}
-
-static void sii8620_irq_infr(struct sii8620 *ctx)
-{
-   u8 stat = sii8620_readb(ctx, REG_INTR8)
-   & (BIT_CEA_NEW_VSI | BIT_CEA_NEW_AVI);
-
-   sii8620_write(ctx, REG_INTR8, stat);
-
-   if (stat & BIT_CEA_NEW_VSI)
-   sii8620_new_vsi(ctx);
-
-   if (stat & BIT_CEA_NEW_AVI)
-   sii8620_new_avi(ctx);
-
-   if (stat & (BIT_CEA_NEW_VSI | BIT_CEA_NEW_AVI))
-   sii8620_start_video(ctx);
-}
-
 static void sii8620_got_xdevcap(struct sii8620 *ctx, int ret)
 {
if (ret < 0)
@@ -2068,7 +2020,6 @@ static irqreturn_t sii8620_irq_thread(int irq, void *data)
{ BIT_FAST_INTR_STAT_EDID, sii8620_irq_edid },
{ BIT_FAST_INTR_STAT_DDC, sii8620_irq_ddc },
{ BIT_FAST_INTR_STAT_SCDT, sii8620_irq_scdt },
-   { BIT_FAST_INTR_STAT_INFR, sii8620_irq_infr },
};
struct sii8620 *ctx = data;
u8 stats[LEN_FAST_INTR_STAT];
-- 
2.7.4

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

[PATCH 3/5] drm/armada: fix UV swap code

[Russell King]

The UV swap code was not always programming things correctly when
the source origin box has been offset.  Fix this.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.h|  2 ++
 drivers/gpu/drm/armada/armada_overlay.c | 38 -
 2 files changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.h 
b/drivers/gpu/drm/armada/armada_crtc.h
index bab11f483575..bfd3514fbe9b 100644
--- a/drivers/gpu/drm/armada/armada_crtc.h
+++ b/drivers/gpu/drm/armada/armada_crtc.h
@@ -42,6 +42,8 @@ struct armada_plane_work {
 };
 
 struct armada_plane_state {
+   u16 src_x;
+   u16 src_y;
u32 src_hw;
u32 dst_hw;
u32 dst_yx;
diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index b411b608821a..aba947696178 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -99,6 +99,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 {
struct armada_ovl_plane *dplane = drm_to_armada_ovl_plane(plane);
struct armada_crtc *dcrtc = drm_to_armada_crtc(crtc);
+   const struct drm_format_info *format;
struct drm_rect src = {
.x1 = src_x,
.y1 = src_y,
@@ -117,7 +118,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
};
uint32_t val, ctrl0;
unsigned idx = 0;
-   bool visible;
+   bool visible, fb_changed;
int ret;
 
trace_armada_ovl_plane_update(plane, crtc, fb,
@@ -138,6 +139,18 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (!visible)
ctrl0 &= ~CFG_DMA_ENA;
 
+   /*
+* Shifting a YUV packed format image by one pixel causes the U/V
+* planes to swap.  Compensate for it by also toggling the UV swap.
+*/
+   format = fb->format;
+   if (format->num_planes == 1 && src.x1 >> 16 & (format->hsub - 1))
+   ctrl0 ^= CFG_DMA_MOD(CFG_SWAPUV);
+
+   fb_changed = plane->fb != fb ||
+dplane->base.state.src_x != src.x1 >> 16 ||
+dplane->base.state.src_y != src.y1 >> 16;
+
if (!dcrtc->plane) {
dcrtc->plane = plane;
armada_ovl_update_attr(>prop, dcrtc);
@@ -145,7 +158,7 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
 
/* FIXME: overlay on an interlaced display */
/* Just updating the position/size? */
-   if (plane->fb == fb && dplane->base.state.ctrl0 == ctrl0) {
+   if (!fb_changed && dplane->base.state.ctrl0 == ctrl0) {
val = (drm_rect_height() & 0x) |
  drm_rect_width() >> 16;
dplane->base.state.src_hw = val;
@@ -169,9 +182,8 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (armada_drm_plane_work_wait(>base, HZ / 25) == 0)
armada_drm_plane_work_cancel(dcrtc, >base);
 
-   if (plane->fb != fb) {
-   u32 addrs[3], pixel_format;
-   int num_planes, hsub;
+   if (fb_changed) {
+   u32 addrs[3];
 
/*
 * Take a reference on the new framebuffer - we want to
@@ -182,23 +194,11 @@ armada_ovl_plane_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
if (plane->fb)
armada_ovl_retire_fb(dplane, plane->fb);
 
-   src_y = src.y1 >> 16;
-   src_x = src.x1 >> 16;
+   dplane->base.state.src_y = src_y = src.y1 >> 16;
+   dplane->base.state.src_x = src_x = src.x1 >> 16;
 
armada_drm_plane_calc_addrs(addrs, fb, src_x, src_y);
 
-   pixel_format = fb->format->format;
-   hsub = drm_format_horz_chroma_subsampling(pixel_format);
-   num_planes = fb->format->num_planes;
-
-   /*
-* Annoyingly, shifting a YUYV-format image by one pixel
-* causes the U/V planes to toggle.  Toggle the UV swap.
-* (Unfortunately, this causes momentary colour flickering.)
-*/
-   if (src_x & (hsub - 1) && num_planes == 1)
-   ctrl0 ^= CFG_DMA_MOD(CFG_SWAPUV);
-
armada_reg_queue_set(dplane->vbl.regs, idx, addrs[0],
 LCD_SPU_DMA_START_ADDR_Y0);
armada_reg_queue_set(dplane->vbl.regs, idx, addrs[1],
-- 
2.7.4

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

Re: [PATCH 0/6] TDA998x CEC support

[Russell King - ARM Linux]

On Wed, Nov 29, 2017 at 09:11:43AM +, Russell King - ARM Linux wrote:
> On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
> > Hi Russell,
> > 
> > On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> > > Hi,
> > > 
> > > This patch series adds CEC support to the DRM TDA998x driver.  The
> > > TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> > > address from the HDMI encoder.
> > > 
> > > Implementation of the CEC part is separate to allow independent CEC
> > > implementations, or independent HDMI implementations (since the
> > > TDA9950 may be a separate device.)
> > 
> > Thank you for this patch series! I assume you are testing this with a
> > BeagleBone Black? If so, do you have a patch for the dts that hooks up the
> > interrupt? If possible, I'd like to test this with my BBB.
> 
> I don't, I test it on the SolidRun Dove Cubox.  I can't help with BBB.

It looks like I need to update the binding document - I'll send a patch
for that shortly.

The additional property that's required to have CEC functional is a
specification for calib-gpio, which must be the GPIO used for the
TDA998x interrupt - you'll have to work out which GPIO that is, that's
the bit I can't help with.

This GPIO is used to calibrate a free running oscillator within the
TDA998x used to clock the TDA9950 CEC block.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel

[Dmitry Osipenko]

On 29.11.2017 15:25, Mikko Perttunen wrote:
> On 29.11.2017 14:18, Dmitry Osipenko wrote:
>> On 29.11.2017 12:10, Mikko Perttunen wrote:
>>> On 12.11.2017 13:23, Dmitry Osipenko wrote:
 On 11.11.2017 00:15, Dmitry Osipenko wrote:
> On 07.11.2017 18:29, Dmitry Osipenko wrote:
>> On 07.11.2017 16:11, Mikko Perttunen wrote:
>>> On 05.11.2017 19:14, Dmitry Osipenko wrote:
 On 05.11.2017 14:01, Mikko Perttunen wrote:
> Add an option to host1x_channel_request to interruptibly wait for a
> free channel. This allows IOCTLs that acquire a channel to block
> the userspace.
>

 Wouldn't it be more optimal to request channel and block after job's
 pining,
 when all patching and checks are completed? Note that right now we have
 locking
 around submission in DRM, which I suppose should go away by making 
 locking
 fine
 grained.
>>>
>>> That would be possible, but I don't think it should matter much since
>>> contention
>>> here should not be the common case.
>>>

 Or maybe it would be more optimal to just iterate over channels, like I
 suggested before [0]?
>>>
>>> Somehow I hadn't noticed this before, but this would break the 
>>> invariant of
>>> having one client/class per channel.
>>>
>>
>> Yes, currently there is a weak relation of channel and clients device, 
>> but
>> seems
>> channels device is only used for printing dev_* messages and device 
>> could be
>> borrowed from the channels job. I don't see any real point of hardwiring
>> channel
>> to a specific device or client.
>
> Although, it won't work with syncpoint assignment to channel.

 On the other hand.. it should work if one syncpoint could be assigned to
 multiple channels, couldn't it?
>>>
>>> A syncpoint can only be mapped to a single channel, so unfortunately this 
>>> won't
>>> work.
>> Okay, in DRM we are requesting syncpoint on channels 'open' and syncpoint
>> assignment happens on jobs submission. So firstly submitted job will assign
>> syncpoint to the first channel and second job would re-assign syncpoint to a
>> second channel while first job is still in-progress, how is it going to work?
>>
> 
> When a context is created, it's assigned both a syncpoint and channel and this
> pair stays for as long as the context is alive (i.e. as long as there are 
> jobs),
> so even if the syncpoint is reassigned to a channel at every submit, it is
> always assigned to the same channel, so nothing breaks. Multiple contexts 
> cannot
> share syncpoints so things work out.
> 
> Obviously this is not ideal as we currently never unassign syncpoints but at
> least it is not broken.

Right, I forgot that you made tegra_drm_context_get_channel() to re-use
requested channel if there are pending jobs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel

[Mikko Perttunen]

On 12.11.2017 13:23, Dmitry Osipenko wrote:

On 11.11.2017 00:15, Dmitry Osipenko wrote:

On 07.11.2017 18:29, Dmitry Osipenko wrote:

On 07.11.2017 16:11, Mikko Perttunen wrote:

On 05.11.2017 19:14, Dmitry Osipenko wrote:

On 05.11.2017 14:01, Mikko Perttunen wrote:

Add an option to host1x_channel_request to interruptibly wait for a
free channel. This allows IOCTLs that acquire a channel to block
the userspace.



Wouldn't it be more optimal to request channel and block after job's pining,
when all patching and checks are completed? Note that right now we have locking
around submission in DRM, which I suppose should go away by making locking fine
grained.


That would be possible, but I don't think it should matter much since contention
here should not be the common case.



Or maybe it would be more optimal to just iterate over channels, like I
suggested before [0]?


Somehow I hadn't noticed this before, but this would break the invariant of
having one client/class per channel.



Yes, currently there is a weak relation of channel and clients device, but seems
channels device is only used for printing dev_* messages and device could be
borrowed from the channels job. I don't see any real point of hardwiring channel
to a specific device or client.


Although, it won't work with syncpoint assignment to channel.


On the other hand.. it should work if one syncpoint could be assigned to
multiple channels, couldn't it?


A syncpoint can only be mapped to a single channel, so unfortunately 
this won't work.


Mikko


--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

[PATCH 2/5] drm/armada: fix SRAM powerdown

[Russell King]

Avoid powering down the overlay SRAM banks when disabling the primary
plane, thereby masking any overlay video.  This feature is supposed to
allow us to cut the bandwidth required while displaying full-frame
overlay video.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 844d488b6654..8696e74d1a6e 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -744,15 +744,14 @@ void armada_drm_crtc_plane_disable(struct armada_crtc 
*dcrtc,
if (plane->fb)
drm_framebuffer_put(plane->fb);
 
-   /* Power down the Y/U/V FIFOs */
-   sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
-
/* Power down most RAMs and FIFOs if this is the primary plane */
if (plane->type == DRM_PLANE_TYPE_PRIMARY) {
-   sram_para1 |= CFG_PDWN256x32 | CFG_PDWN256x24 | CFG_PDWN256x8 |
- CFG_PDWN32x32 | CFG_PDWN64x66;
+   sram_para1 = CFG_PDWN256x32 | CFG_PDWN256x24 | CFG_PDWN256x8 |
+CFG_PDWN32x32 | CFG_PDWN64x66;
dma_ctrl0_mask = CFG_GRA_ENA;
} else {
+   /* Power down the Y/U/V FIFOs */
+   sram_para1 = CFG_PDWN16x66 | CFG_PDWN32x66;
dma_ctrl0_mask = CFG_DMA_ENA;
}
 
-- 
2.7.4

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

Re: [PATCH v2] MAINTAINERS: change maintainer for Rockchip drm drivers

[Sean Paul]

On Wed, Nov 29, 2017 at 09:24:42AM -0500, Sean Paul wrote:
> From: Mark Yao 
> 
> For personal reasons, Mark Yao will leave rockchip,
> can not continue maintain drm/rockchip, Sandy Huang
> and Heiko Stübner will take over drm/rockchip.
> 
> Cc: Sandy Huang 
> Cc: Heiko Stübner 
> 
> Signed-off-by: Mark Yao 
> Acked-by: Heiko Stuebner 
> [seanpaul added Heiko]
> Signed-off-by: Sean Paul 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/1510568131-28838-1-git-send-email-mark@rock-chips.com

Applied to drm-misc-next (with the correct Link)

Sean

> ---
> 
> Changed in v2:
> - Added Heiko as co-maintainer
> 
> 
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d4b63c7ffb0e..4f0756a4ff1a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -4625,7 +4625,8 @@ F:  
> Documentation/devicetree/bindings/display/bridge/renesas,dw-hdmi.txt
>  F:   Documentation/devicetree/bindings/display/renesas,du.txt
>  
>  DRM DRIVERS FOR ROCKCHIP
> -M:   Mark Yao 
> +M:   Sandy Huang 
> +M:   Heiko Stübner 
>  L:   dri-devel@lists.freedesktop.org
>  S:   Maintained
>  F:   drivers/gpu/drm/rockchip/
> -- 
> 2.15.0.417.g466bffb3ac-goog
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103968] No Hardware Acceleration with AMD RX 550

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103968

--- Comment #1 from Michel Dänzer  ---
Please provide the output of:

 dpkg -l | grep '^i.*mesa'

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

Re: [PATCH v6 2/2] staging: ion: create one device entry per heap

[Benjamin Gaignard]

2017-11-28 14:32 GMT+01:00 Greg KH :
> On Mon, Nov 06, 2017 at 04:59:45PM +0100, Benjamin Gaignard wrote:
>> Instead a getting only one common device "/dev/ion" for
>> all the heaps this patch allow to create one device
>> entry ("/dev/ionX") per heap.
>> Getting an entry per heap could allow to set security rules
>> per heap and global ones for all heaps.
>>
>> Allocation requests will be only allowed if the mask_id
>> match with device minor.
>> Query request could be done on any of the devices.
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  drivers/staging/android/TODO|  1 -
>>  drivers/staging/android/ion/Kconfig |  7 
>>  drivers/staging/android/ion/ion-ioctl.c | 18 --
>>  drivers/staging/android/ion/ion.c   | 62 
>> +
>>  drivers/staging/android/ion/ion.h   | 15 ++--
>>  5 files changed, 91 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO
>> index 687e0ea..8a11931 100644
>> --- a/drivers/staging/android/TODO
>> +++ b/drivers/staging/android/TODO
>> @@ -8,7 +8,6 @@ TODO:
>>  ion/
>>   - Add dt-bindings for remaining heaps (chunk and carveout heaps). This 
>> would
>> involve putting appropriate bindings in a memory node for Ion to find.
>> - - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0)
>>   - Better test framework (integration with VGEM was suggested)
>>
>>  Please send patches to Greg Kroah-Hartman  and Cc:
>> diff --git a/drivers/staging/android/ion/Kconfig 
>> b/drivers/staging/android/ion/Kconfig
>> index a517b2d..cb4666e 100644
>> --- a/drivers/staging/android/ion/Kconfig
>> +++ b/drivers/staging/android/ion/Kconfig
>> @@ -10,6 +10,13 @@ menuconfig ION
>> If you're not using Android its probably safe to
>> say N here.
>>
>> +config ION_LEGACY_DEVICE_API
>> + bool "Keep using Ion legacy misc device API"
>> + depends on ION
>
> You want to default to Y here, so when you do 'make oldconfig' nothing
> breaks, right?
>

I will add it.

>> + help
>> +   Choose this option to keep using Ion legacy misc device API
>> +   i.e. /dev/ion
>
> You need more text here to describe the trade offs.  Why would I not
> want to keep doing this?  What does turning this off get me?  What does
> keeping it on keep me from doing?
>
Does describe it like that sound better ?
"Choose this option to keep using ION legacy misc device API
  i.e. /dev/ion. If this option isn't selected you will only
  have per heap device node (i.e /dev/ionX) and allocating buffer
  from an unique device node won't be possible."


>> +
>>  config ION_SYSTEM_HEAP
>>   bool "Ion system heap"
>>   depends on ION
>> diff --git a/drivers/staging/android/ion/ion-ioctl.c 
>> b/drivers/staging/android/ion/ion-ioctl.c
>> index e26b786..bb5c77b 100644
>> --- a/drivers/staging/android/ion/ion-ioctl.c
>> +++ b/drivers/staging/android/ion/ion-ioctl.c
>> @@ -25,7 +25,8 @@ union ion_ioctl_arg {
>>   struct ion_heap_query query;
>>  };
>>
>> -static int validate_ioctl_arg(unsigned int cmd, union ion_ioctl_arg *arg)
>> +static int validate_ioctl_arg(struct file *filp,
>> +   unsigned int cmd, union ion_ioctl_arg *arg)
>>  {
>>   switch (cmd) {
>>   case ION_IOC_HEAP_QUERY:
>> @@ -34,6 +35,19 @@ static int validate_ioctl_arg(unsigned int cmd, union 
>> ion_ioctl_arg *arg)
>>   arg->query.reserved2 )
>>   return -EINVAL;
>>   break;
>> +
>> + case ION_IOC_ALLOC:
>> + {
>> + int mask = 1 << iminor(filp->f_inode);
>> +
>> +#ifdef CONFIG_ION_LEGACY_DEVICE_API
>> + if (imajor(filp->f_inode) == MISC_MAJOR)
>> + return 0;
>
> Why return 0?  Because it is already allocated?

No it is because in legacy mode all mask are valids so to keep legacy behavoir
it will not test if the requested heap  match with the device.

I will add a comment about that.

>
> Some comments here as to exactly what you are doing would be nice.
>
>> +#endif
>> + if (!(arg->allocation.heap_id_mask & mask))
>
> This doesn't allocate anthing, just check to see if it is?
>

No this function only check if ioctl args are correct.

>> + return -EINVAL;
>> + break;
>> + }
>>   default:
>>   break;
>>   }
>> @@ -69,7 +83,7 @@ long ion_ioctl(struct file *filp, unsigned int cmd, 
>> unsigned long arg)
>>   if (copy_from_user(, (void __user *)arg, _IOC_SIZE(cmd)))
>>   return -EFAULT;
>>
>> - ret = validate_ioctl_arg(cmd, );
>> + ret = validate_ioctl_arg(filp, cmd, );
>>   if (WARN_ON_ONCE(ret))
>>   return ret;
>>
>> diff --git a/drivers/staging/android/ion/ion.c 
>> b/drivers/staging/android/ion/ion.c
>> index fda9756..2c2568b 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ 

Re: [PATCH 0/6] TDA998x CEC support

[Hans Verkuil]

On 11/29/17 10:11, Russell King - ARM Linux wrote:
> On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
>> Hi Russell,
>>
>> On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
>>> Hi,
>>>
>>> This patch series adds CEC support to the DRM TDA998x driver.  The
>>> TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
>>> address from the HDMI encoder.
>>>
>>> Implementation of the CEC part is separate to allow independent CEC
>>> implementations, or independent HDMI implementations (since the
>>> TDA9950 may be a separate device.)
>>
>> Thank you for this patch series! I assume you are testing this with a
>> BeagleBone Black? If so, do you have a patch for the dts that hooks up the
>> interrupt? If possible, I'd like to test this with my BBB.
> 
> I don't, I test it on the SolidRun Dove Cubox.  I can't help with BBB.
> 

Can you post the dts tda snippet you use for the SolidRun Dove Cubox?
Or just mail the whole thing to me, or point to a git repo where you
have it.

I can use that as a starting point for adding CEC support to the BBB.

No hurry, I can't test with my BBB until Dec 11 at the earliest anyway.

Regards,

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

[Bug 103968] No Hardware Acceleration with AMD RX 550

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103968

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #135796|text/x-log  |text/plain
  mime type||

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

Re: [PATCH 0/6] TDA998x CEC support

[Russell King - ARM Linux]

On Wed, Nov 29, 2017 at 01:43:27PM +0100, Hans Verkuil wrote:
> On 11/29/17 10:11, Russell King - ARM Linux wrote:
> > On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
> >> Hi Russell,
> >>
> >> On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> >>> Hi,
> >>>
> >>> This patch series adds CEC support to the DRM TDA998x driver.  The
> >>> TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> >>> address from the HDMI encoder.
> >>>
> >>> Implementation of the CEC part is separate to allow independent CEC
> >>> implementations, or independent HDMI implementations (since the
> >>> TDA9950 may be a separate device.)
> >>
> >> Thank you for this patch series! I assume you are testing this with a
> >> BeagleBone Black? If so, do you have a patch for the dts that hooks up the
> >> interrupt? If possible, I'd like to test this with my BBB.
> > 
> > I don't, I test it on the SolidRun Dove Cubox.  I can't help with BBB.
> > 
> 
> Can you post the dts tda snippet you use for the SolidRun Dove Cubox?
> Or just mail the whole thing to me, or point to a git repo where you
> have it.
> 
> I can use that as a starting point for adding CEC support to the BBB.

There's two patches.  Here's the addition of tda998x to dove-cubox.dts:

+   tda998x: hdmi-encoder {
+   compatible = "nxp,tda998x";
+   reg = <0x70>;
+   video-ports = <0x234501>;
+   interrupts-extended = < 27 IRQ_TYPE_LEVEL_LOW>;
+
+   port {
+   tda998x_video: endpoint {
+   remote-endpoint = <_rgb>;
+   };
+   };
+   };

And then adding tda998x cec requires:

tda998x: hdmi-encoder {
compatible = "nxp,tda998x";
+   calib-gpio = < 27 0>;
reg = <0x70>;
video-ports = <0x234501>;
interrupts-extended = < 27 IRQ_TYPE_LEVEL_LOW>;

The problem that I see with BBB (I assume am335x-boneblack-common.dtsi)
is that the tda998x doesn't mention an interrupt - if the interrupt
isn't wired to a GPIO, you can't calibrate the TDA998x CEC FRO, and CEC
will not work.

The same problem appears on ARM's evaluation boards that use the TDA998x.
The chip is present but there's no indication whether the interrupt pin
is wired.

That means, despite having several platforms with a TDA998x present, the
only one I can test CEC with is the Dove Cubox.

(At the moment, I can't test CEC as a regular part of testing as I've
"lost" my TV to the living room for the rest of the family to use...
need to repair their normal TV...)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/10] drm/tegra: Deliver job completion callback to client

[Mikko Perttunen]

On 16.11.2017 18:40, Dmitry Osipenko wrote:

On 05.11.2017 14:01, Mikko Perttunen wrote:

To allow client drivers to free resources when jobs have completed,
deliver job completion callbacks to them. This requires adding
reference counting to context objects, as job completion can happen
after the userspace application has closed the context. As such,
also add kref-based refcounting for contexts.

Signed-off-by: Mikko Perttunen 
---
 drivers/gpu/drm/tegra/drm.c | 27 ---
 drivers/gpu/drm/tegra/drm.h |  4 
 2 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 2cdd054520bf..3e2a4a19412e 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -281,8 +281,11 @@ static int tegra_drm_open(struct drm_device *drm, struct 
drm_file *filp)
return 0;
 }

-static void tegra_drm_context_free(struct tegra_drm_context *context)
+static void tegra_drm_context_free(struct kref *ref)
 {
+   struct tegra_drm_context *context =
+   container_of(ref, struct tegra_drm_context, ref);
+
context->client->ops->close_channel(context);
kfree(context);
 }
@@ -379,6 +382,16 @@ static int host1x_waitchk_copy_from_user(struct 
host1x_waitchk *dest,
return 0;
 }

+static void tegra_drm_job_done(struct host1x_job *job)
+{
+   struct tegra_drm_context *context = job->callback_data;
+
+   if (context->client->ops->submit_done)
+   context->client->ops->submit_done(context);
+
+   kref_put(>ref, tegra_drm_context_free);
+}
+
 int tegra_drm_submit(struct tegra_drm_context *context,
 struct drm_tegra_submit *args, struct drm_device *drm,
 struct drm_file *file)
@@ -560,6 +573,9 @@ int tegra_drm_submit(struct tegra_drm_context *context,
job->syncpt_id = syncpt.id;
job->timeout = 1;

+   job->done = tegra_drm_job_done;
+   job->callback_data = context;
+
if (args->timeout && args->timeout < 1)
job->timeout = args->timeout;

@@ -567,8 +583,11 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (err)
goto fail;

+   kref_get(>ref);
+
err = host1x_job_submit(job);
if (err) {
+   kref_put(>ref, tegra_drm_context_free);
host1x_job_unpin(job);
goto fail;
}
@@ -717,6 +736,8 @@ static int tegra_open_channel(struct drm_device *drm, void 
*data,
if (err < 0)
kfree(context);

+   kref_init(>ref);
+
mutex_unlock(>lock);
return err;
 }
@@ -738,7 +759,7 @@ static int tegra_close_channel(struct drm_device *drm, void 
*data,
}

idr_remove(>contexts, context->id);
-   tegra_drm_context_free(context);
+   kref_put(>ref, tegra_drm_context_free);

 unlock:
mutex_unlock(>lock);
@@ -1026,7 +1047,7 @@ static int tegra_drm_context_cleanup(int id, void *p, 
void *data)
 {
struct tegra_drm_context *context = p;

-   tegra_drm_context_free(context);
+   kref_put(>ref, tegra_drm_context_free);



Probably won't hurt to add and use 
tegra_drm_context_get()/tegra_drm_context_put().



Yeah, maybe we have enough places where this is called for it to make sense.

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

[PATCH 1/5] drm/armada: fix leak of crtc structure

[Russell King]

Fix the leak of the CRTC structure in the failure paths of
armada_drm_crtc_create().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 2e065facdce7..844d488b6654 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1246,11 +1246,14 @@ static int armada_drm_crtc_create(struct drm_device 
*drm, struct device *dev,
dcrtc->crtc.port = port;
 
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
-   if (!primary)
+   if (!primary) {
+   kfree(dcrtc);
return -ENOMEM;
+   }
 
ret = armada_drm_plane_init(primary);
if (ret) {
+   kfree(dcrtc);
kfree(primary);
return ret;
}
@@ -1262,14 +1265,17 @@ static int armada_drm_crtc_create(struct drm_device 
*drm, struct device *dev,
   NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
+   kfree(dcrtc);
kfree(primary);
return ret;
}
 
ret = drm_crtc_init_with_planes(drm, >crtc, >base, NULL,
_crtc_funcs, NULL);
-   if (ret)
+   if (ret) {
+   kfree(dcrtc);
goto err_crtc_init;
+   }
 
drm_crtc_helper_add(>crtc, _crtc_helper_funcs);
 
-- 
2.7.4

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

Re: [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel

[Mikko Perttunen]

On 29.11.2017 14:18, Dmitry Osipenko wrote:

On 29.11.2017 12:10, Mikko Perttunen wrote:

On 12.11.2017 13:23, Dmitry Osipenko wrote:

On 11.11.2017 00:15, Dmitry Osipenko wrote:

On 07.11.2017 18:29, Dmitry Osipenko wrote:

On 07.11.2017 16:11, Mikko Perttunen wrote:

On 05.11.2017 19:14, Dmitry Osipenko wrote:

On 05.11.2017 14:01, Mikko Perttunen wrote:

Add an option to host1x_channel_request to interruptibly wait for a
free channel. This allows IOCTLs that acquire a channel to block
the userspace.



Wouldn't it be more optimal to request channel and block after job's pining,
when all patching and checks are completed? Note that right now we have
locking
around submission in DRM, which I suppose should go away by making locking
fine
grained.


That would be possible, but I don't think it should matter much since
contention
here should not be the common case.



Or maybe it would be more optimal to just iterate over channels, like I
suggested before [0]?


Somehow I hadn't noticed this before, but this would break the invariant of
having one client/class per channel.



Yes, currently there is a weak relation of channel and clients device, but
seems
channels device is only used for printing dev_* messages and device could be
borrowed from the channels job. I don't see any real point of hardwiring
channel
to a specific device or client.


Although, it won't work with syncpoint assignment to channel.


On the other hand.. it should work if one syncpoint could be assigned to
multiple channels, couldn't it?


A syncpoint can only be mapped to a single channel, so unfortunately this won't
work.

Okay, in DRM we are requesting syncpoint on channels 'open' and syncpoint
assignment happens on jobs submission. So firstly submitted job will assign
syncpoint to the first channel and second job would re-assign syncpoint to a
second channel while first job is still in-progress, how is it going to work?



When a context is created, it's assigned both a syncpoint and channel 
and this pair stays for as long as the context is alive (i.e. as long as 
there are jobs), so even if the syncpoint is reassigned to a channel at 
every submit, it is always assigned to the same channel, so nothing 
breaks. Multiple contexts cannot share syncpoints so things work out.


Obviously this is not ideal as we currently never unassign syncpoints 
but at least it is not broken.


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

[PATCH 4/5] drm/armada: improve efficiency of armada_drm_plane_calc_addrs()

[Russell King]

Lookup the drm_format_info structure once when computing all the
framebuffer plane addresses by using drm_format_info(), rather than
repetitive lookups via drm_format_plane_cpp().

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 8696e74d1a6e..7b80273a49bb 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -168,8 +168,9 @@ static void armada_drm_crtc_update(struct armada_crtc 
*dcrtc)
 void armada_drm_plane_calc_addrs(u32 *addrs, struct drm_framebuffer *fb,
int x, int y)
 {
+   const struct drm_format_info *format = fb->format;
+   unsigned int num_planes = format->num_planes;
u32 addr = drm_fb_obj(fb)->dev_addr;
-   int num_planes = fb->format->num_planes;
int i;
 
if (num_planes > 3)
@@ -177,7 +178,7 @@ void armada_drm_plane_calc_addrs(u32 *addrs, struct 
drm_framebuffer *fb,
 
for (i = 0; i < num_planes; i++)
addrs[i] = addr + fb->offsets[i] + y * fb->pitches[i] +
-x * fb->format->cpp[i];
+x * format->cpp[i];
for (; i < 3; i++)
addrs[i] = 0;
 }
-- 
2.7.4

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

[PATCH 5/5] drm/armada: fix YUV planar format framebuffer offsets

[Russell King]

We weren't correctly calculating the YUV planar offsets for subsampled
chroma planes correctly - fix up the coordinates for planes 1 and 2.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/armada/armada_crtc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 7b80273a49bb..c28c2c533994 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -176,7 +176,13 @@ void armada_drm_plane_calc_addrs(u32 *addrs, struct 
drm_framebuffer *fb,
if (num_planes > 3)
num_planes = 3;
 
-   for (i = 0; i < num_planes; i++)
+   addrs[0] = addr + fb->offsets[0] + y * fb->pitches[0] +
+  x * format->cpp[0];
+
+   y /= format->vsub;
+   x /= format->hsub;
+
+   for (i = 1; i < num_planes; i++)
addrs[i] = addr + fb->offsets[i] + y * fb->pitches[i] +
 x * format->cpp[i];
for (; i < 3; i++)
-- 
2.7.4

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

Re: [PATCH 10/10] gpu: host1x: Optionally block when acquiring channel

[Dmitry Osipenko]

On 29.11.2017 12:10, Mikko Perttunen wrote:
> On 12.11.2017 13:23, Dmitry Osipenko wrote:
>> On 11.11.2017 00:15, Dmitry Osipenko wrote:
>>> On 07.11.2017 18:29, Dmitry Osipenko wrote:
 On 07.11.2017 16:11, Mikko Perttunen wrote:
> On 05.11.2017 19:14, Dmitry Osipenko wrote:
>> On 05.11.2017 14:01, Mikko Perttunen wrote:
>>> Add an option to host1x_channel_request to interruptibly wait for a
>>> free channel. This allows IOCTLs that acquire a channel to block
>>> the userspace.
>>>
>>
>> Wouldn't it be more optimal to request channel and block after job's 
>> pining,
>> when all patching and checks are completed? Note that right now we have
>> locking
>> around submission in DRM, which I suppose should go away by making 
>> locking
>> fine
>> grained.
>
> That would be possible, but I don't think it should matter much since
> contention
> here should not be the common case.
>
>>
>> Or maybe it would be more optimal to just iterate over channels, like I
>> suggested before [0]?
>
> Somehow I hadn't noticed this before, but this would break the invariant 
> of
> having one client/class per channel.
>

 Yes, currently there is a weak relation of channel and clients device, but
 seems
 channels device is only used for printing dev_* messages and device could 
 be
 borrowed from the channels job. I don't see any real point of hardwiring
 channel
 to a specific device or client.
>>>
>>> Although, it won't work with syncpoint assignment to channel.
>>
>> On the other hand.. it should work if one syncpoint could be assigned to
>> multiple channels, couldn't it?
> 
> A syncpoint can only be mapped to a single channel, so unfortunately this 
> won't
> work.
Okay, in DRM we are requesting syncpoint on channels 'open' and syncpoint
assignment happens on jobs submission. So firstly submitted job will assign
syncpoint to the first channel and second job would re-assign syncpoint to a
second channel while first job is still in-progress, how is it going to work?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/5] Armada DRM fixes

[Russell King - ARM Linux]

Hi David,

This series fixes some issues in the Armada DRM driver:
- A memory leak while cleaning up in the CRTC initialisation path
- Avoid powering down YUV FIFOs when disabling the graphics plane
- Several fixes for the overlay plane positioning

I'll send a pull request for this as is normal for Armada stuff next week.

Thanks.

 drivers/gpu/drm/armada/armada_crtc.c| 32 ++-
 drivers/gpu/drm/armada/armada_crtc.h|  2 ++
 drivers/gpu/drm/armada/armada_overlay.c | 38 -
 3 files changed, 43 insertions(+), 29 deletions(-)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/6] TDA998x CEC support

[Russell King - ARM Linux]

On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
> Hi Russell,
> 
> On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> > Hi,
> > 
> > This patch series adds CEC support to the DRM TDA998x driver.  The
> > TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> > address from the HDMI encoder.
> > 
> > Implementation of the CEC part is separate to allow independent CEC
> > implementations, or independent HDMI implementations (since the
> > TDA9950 may be a separate device.)
> 
> Thank you for this patch series! I assume you are testing this with a
> BeagleBone Black? If so, do you have a patch for the dts that hooks up the
> interrupt? If possible, I'd like to test this with my BBB.

I don't, I test it on the SolidRun Dove Cubox.  I can't help with BBB.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/6] dt-bindings: tda998x: add the calibration gpio

[Russell King]

Add the optional calibration gpio for integrated TDA9950 CEC support.
This GPIO corresponds with the interrupt from the TDA998x, as the
calibration requires driving the interrupt pin low.

Signed-off-by: Russell King 
---
Sorry, this patch got forgotten, tacking it on the end of the series.

 Documentation/devicetree/bindings/display/bridge/tda998x.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt 
b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
index 24cc2466185a..ad6620560d63 100644
--- a/Documentation/devicetree/bindings/display/bridge/tda998x.txt
+++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt
@@ -27,6 +27,9 @@ Required properties;
in question is used. The implementation allows one or two DAIs. If two
DAIs are defined, they must be of different type.
 
+  - calib-gpio: calibration GPIO, which must correspond with the
+   gpio used for the TDA998x interrupt pin.
+
 [1] Documentation/sound/alsa/soc/DAI.txt
 [2] include/dt-bindings/display/tda998x.h
 
-- 
2.7.4

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

Re: [PATCH] drm/tegra: gem: Use PTR_ERR_OR_ZERO()

[Mikko Perttunen]

On 29.11.2017 00:18, Vasyl Gomonovych wrote:

Fix ptr_ret.cocci warnings:
drivers/gpu/drm/tegra/gem.c:420:1-3: WARNING: PTR_ERR_OR_ZERO can be used

Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR

Generated by: scripts/coccinelle/api/ptr_ret.cocci

Signed-off-by: Vasyl Gomonovych 
---
 drivers/gpu/drm/tegra/gem.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index ab1e53d434e8..a40148cd0957 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -417,10 +417,8 @@ int tegra_bo_dumb_create(struct drm_file *file, struct 
drm_device *drm,

bo = tegra_bo_create_with_handle(file, drm, args->size, 0,
 >handle);
-   if (IS_ERR(bo))
-   return PTR_ERR(bo);

-   return 0;
+   return PTR_ERR_OR_ZERO(bo);


This is semantically less clear - the current code clearly has error and 
success paths while the changed code doesn't. Same for the other patch.


Cheers,
Mikko


 }

 static int tegra_bo_fault(struct vm_fault *vmf)


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

Re: [PATCH] drm: hibmc: Initialize the hibmc_bo_driver.io_mem_pfn

[Sean Paul]

On Wed, Nov 29, 2017 at 12:33:24PM +0100, m...@suse.com wrote:
> From: Michal Srb 
> 
> The io_mem_pfn field was added in ea642c3216cb2a60d1c0e760ae47ee85c9c16447 and
> is used unconditionally. Most drivers were updated to set it to the default
> implementation ttm_bo_default_io_mem_pfn, but hibmc was not.
> 
> This fixes crash in ttm_bo_vm_fault when hibmc driver is used.

Instead of just doing the same cargo cult in this driver, lets just call the
default function when io_mem_pfn is NULL. Looks like 9 other drivers are
affected as well.

Sean

> 
> Signed-off-by: Michal Srb 
> ---
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c 
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> index 3518167a7dc4..0b165ce4ee00 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_ttm.c
> @@ -243,6 +243,7 @@ struct ttm_bo_driver hibmc_bo_driver = {
>   .verify_access  = hibmc_bo_verify_access,
>   .io_mem_reserve = _ttm_io_mem_reserve,
>   .io_mem_free= NULL,
> + .io_mem_pfn = ttm_bo_default_io_mem_pfn,
>  };
>  
>  int hibmc_mm_init(struct hibmc_drm_private *hibmc)
> -- 
> 2.13.6
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/bridge/sii8620: fix HDMI cable connection to dongle

[Maciej Purski]

MHL bridge is usually connected to TV via MHL dongle. Currently plugging
HDMI cable to dongle is handled improperly. This patch fixes it.

Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 49 
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index 35ccc90..857d2cb5 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -78,6 +78,7 @@ struct sii8620 {
u8 devcap[MHL_DCAP_SIZE];
u8 xdevcap[MHL_XDC_SIZE];
u8 avif[HDMI_INFOFRAME_SIZE(AVI)];
+   bool feature_complete;
struct edid *edid;
unsigned int gen2_write_burst:1;
enum sii8620_mt_state mt_state;
@@ -470,7 +471,7 @@ static void sii8620_update_array(u8 *dst, u8 *src, int 
count)
}
 }
 
-static void sii8620_sink_detected(struct sii8620 *ctx, int ret)
+static void sii8620_hpd_plugged(struct sii8620 *ctx)
 {
static const char * const sink_str[] = {
[SINK_NONE] = "NONE",
@@ -481,15 +482,13 @@ static void sii8620_sink_detected(struct sii8620 *ctx, 
int ret)
char sink_name[20];
struct device *dev = ctx->dev;
 
-   if (ret < 0)
-   return;
-
sii8620_fetch_edid(ctx);
if (!ctx->edid) {
dev_err(ctx->dev, "Cannot fetch EDID\n");
sii8620_mhl_disconnected(ctx);
return;
}
+   sii8620_set_upstream_edid(ctx);
 
if (drm_detect_hdmi_monitor(ctx->edid))
ctx->sink_type = SINK_HDMI;
@@ -502,15 +501,6 @@ static void sii8620_sink_detected(struct sii8620 *ctx, int 
ret)
 sink_str[ctx->sink_type], sink_name);
 }
 
-static void sii8620_edid_read(struct sii8620 *ctx, int ret)
-{
-   if (ret < 0)
-   return;
-
-   sii8620_set_upstream_edid(ctx);
-   sii8620_enable_hpd(ctx);
-}
-
 static void sii8620_mr_devcap(struct sii8620 *ctx)
 {
u8 dcap[MHL_DCAP_SIZE];
@@ -1490,6 +1480,15 @@ static void sii8620_set_mode(struct sii8620 *ctx, enum 
sii8620_mode mode)
);
 }
 
+static void sii8620_hpd_unplugged(struct sii8620 *ctx)
+{
+   sii8620_disable_hpd(ctx);
+   ctx->sink_type = SINK_NONE;
+   ctx->feature_complete = false;
+   kfree(ctx->edid);
+   ctx->edid = NULL;
+}
+
 static void sii8620_disconnect(struct sii8620 *ctx)
 {
sii8620_disable_gen2_write_burst(ctx);
@@ -1517,7 +1516,7 @@ static void sii8620_disconnect(struct sii8620 *ctx)
REG_MHL_DP_CTL6, 0x2A,
REG_MHL_DP_CTL7, 0x03
);
-   sii8620_disable_hpd(ctx);
+   sii8620_hpd_unplugged(ctx);
sii8620_write_seq_static(ctx,
REG_M3_CTRL, VAL_M3_CTRL_MHL3_VALUE,
REG_MHL_COC_CTL1, 0x07,
@@ -1566,9 +1565,6 @@ static void sii8620_disconnect(struct sii8620 *ctx)
memset(ctx->devcap, 0, sizeof(ctx->devcap));
memset(ctx->xdevcap, 0, sizeof(ctx->xdevcap));
ctx->cbus_status = 0;
-   ctx->sink_type = SINK_NONE;
-   kfree(ctx->edid);
-   ctx->edid = NULL;
sii8620_mt_cleanup(ctx);
 }
 
@@ -1661,7 +1657,6 @@ static void sii8620_status_changed_path(struct sii8620 
*ctx)
  | MHL_DST_LM_PATH_ENABLED);
if (!sii8620_is_mhl3(ctx))
sii8620_mt_read_devcap(ctx, false);
-   sii8620_mt_set_cont(ctx, sii8620_sink_detected);
} else {
sii8620_mt_write_stat(ctx, MHL_DST_REG(LINK_MODE),
  MHL_DST_LM_CLK_MODE_NORMAL);
@@ -1764,8 +1759,11 @@ static void sii8620_msc_mr_set_int(struct sii8620 *ctx)
}
if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_REQ)
sii8620_send_features(ctx);
-   if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_COMPLETE)
-   sii8620_edid_read(ctx, 0);
+   if (ints[MHL_INT_RCHANGE] & MHL_INT_RC_FEAT_COMPLETE) {
+   ctx->feature_complete = true;
+   if (ctx->edid)
+   sii8620_enable_hpd(ctx);
+   }
 }
 
 static struct sii8620_mt_msg *sii8620_msc_msg_first(struct sii8620 *ctx)
@@ -1840,6 +1838,13 @@ static void sii8620_irq_msc(struct sii8620 *ctx)
if (stat & BIT_CBUS_MSC_MR_WRITE_STAT)
sii8620_msc_mr_write_stat(ctx);
 
+   if (stat & BIT_CBUS_HPD_CHG) {
+   if (ctx->cbus_status & BIT_CBUS_STATUS_CBUS_HPD)
+   sii8620_hpd_plugged(ctx);
+   else
+   sii8620_hpd_unplugged(ctx);
+   }
+
if (stat & BIT_CBUS_MSC_MR_SET_INT)
sii8620_msc_mr_set_int(ctx);
 
@@ -1951,11 +1956,11 @@ static void sii8620_irq_ddc(struct sii8620 *ctx)
 
if (stat & BIT_DDC_CMD_DONE) {
sii8620_write(ctx, REG_INTR3_MASK, 0);
-   if (sii8620_is_mhl3(ctx))
+   if 

[PATCH 1/2] drm/bridge/sii8620: remove HSIC initialization

[Maciej Purski]

HSIC initialization was taken from the vendor code. HSIC in MHL circuit
is not connected, so it is not possible to test it. Tests prove that
without HSIC the device works well. Therefore it can be removed.

Signed-off-by: Maciej Purski 
---
 drivers/gpu/drm/bridge/sil-sii8620.c | 38 
 1 file changed, 38 deletions(-)

diff --git a/drivers/gpu/drm/bridge/sil-sii8620.c 
b/drivers/gpu/drm/bridge/sil-sii8620.c
index e81c96a..35ccc90 100644
--- a/drivers/gpu/drm/bridge/sil-sii8620.c
+++ b/drivers/gpu/drm/bridge/sil-sii8620.c
@@ -502,50 +502,12 @@ static void sii8620_sink_detected(struct sii8620 *ctx, 
int ret)
 sink_str[ctx->sink_type], sink_name);
 }
 
-static void sii8620_hsic_init(struct sii8620 *ctx)
-{
-   if (!sii8620_is_mhl3(ctx))
-   return;
-
-   sii8620_write(ctx, REG_FCGC,
-   BIT_FCGC_HSIC_HOSTMODE | BIT_FCGC_HSIC_ENABLE);
-   sii8620_setbits(ctx, REG_HRXCTRL3,
-   BIT_HRXCTRL3_HRX_STAY_RESET | BIT_HRXCTRL3_STATUS_EN, ~0);
-   sii8620_setbits(ctx, REG_TTXNUMB, MSK_TTXNUMB_TTX_NUMBPS, 4);
-   sii8620_setbits(ctx, REG_TRXCTRL, BIT_TRXCTRL_TRX_FROM_SE_COC, ~0);
-   sii8620_setbits(ctx, REG_HTXCTRL, BIT_HTXCTRL_HTX_DRVCONN1, 0);
-   sii8620_setbits(ctx, REG_KEEPER, MSK_KEEPER_MODE, VAL_KEEPER_MODE_HOST);
-   sii8620_write_seq_static(ctx,
-   REG_TDMLLCTL, 0,
-   REG_UTSRST, BIT_UTSRST_HRX_SRST | BIT_UTSRST_HTX_SRST |
-   BIT_UTSRST_KEEPER_SRST | BIT_UTSRST_FC_SRST,
-   REG_UTSRST, BIT_UTSRST_HRX_SRST | BIT_UTSRST_HTX_SRST,
-   REG_HRXINTL, 0xff,
-   REG_HRXINTH, 0xff,
-   REG_TTXINTL, 0xff,
-   REG_TTXINTH, 0xff,
-   REG_TRXINTL, 0xff,
-   REG_TRXINTH, 0xff,
-   REG_HTXINTL, 0xff,
-   REG_HTXINTH, 0xff,
-   REG_FCINTR0, 0xff,
-   REG_FCINTR1, 0xff,
-   REG_FCINTR2, 0xff,
-   REG_FCINTR3, 0xff,
-   REG_FCINTR4, 0xff,
-   REG_FCINTR5, 0xff,
-   REG_FCINTR6, 0xff,
-   REG_FCINTR7, 0xff
-   );
-}
-
 static void sii8620_edid_read(struct sii8620 *ctx, int ret)
 {
if (ret < 0)
return;
 
sii8620_set_upstream_edid(ctx);
-   sii8620_hsic_init(ctx);
sii8620_enable_hpd(ctx);
 }
 
-- 
2.7.4

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

[PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Michal Srb]

The io_mem_pfn field was added in commit 
ea642c3216cb2a60d1c0e760ae47ee85c9c16447
and is called unconditionally. However, not all drivers were updated to set it.

Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.

Signed-off-by: Michal Srb 
---
 drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index c8ebb757e36b..e25a99bc519d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (bo->mem.bus.is_iomem) {
/* Iomem should not be marked encrypted */
cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
-   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   if (bdev->driver->io_mem_pfn)
+   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   else
+   pfn = ttm_bo_default_io_mem_pfn(bo, 
page_offset);
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {
-- 
2.13.6

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

Re: [PATCH] drm/atomic: make drm_atomic_helper_wait_for_vblanks more agressive

[Maarten Lankhorst]

Op 29-11-17 om 12:04 schreef Lucas Stach:
> drm_atomic_helper_setup_commit expects that flipping of previous commits
> has happened when it is called to set up a new commit. This can be violated
> by commits where userspace doesn't get a flip completion event to
> synchronize against i.e. legacy modesets and property changes.
>
> The expectation is that those are done by blocking commits, which wait for
> completion. Most drivers call drm_atomic_helper_wait_for_vblanks in the
> commit_tail to ensure completion, but the wait for next vblank might not
> actually happen if the commit didn't change any planes.
>
> Make the wait more agressive by also waiting if no planes changed. This
> is the minimal regression fix for the 4.15 kernel series. Long term
> drivers should switch away from drm_atomic_helper_wait_for_vblanks and
> use drm_atomic_helper_wait_for_flip_done instead.
>
> Signed-off-by: Lucas Stach 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 71d712f1b56a..b16f1d69a0bb 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1225,7 +1225,7 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device 
> *dev,
>   return;
>  
>   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
> new_crtc_state, i) {
> - if (!new_crtc_state->active || !new_crtc_state->planes_changed)
> + if (!new_crtc_state->active)
>   continue;
>  
>   ret = drm_crtc_vblank_get(crtc);

Added a fixes tag because it likely started regressing with
commit de39bec1a0c4 ("drm/atomic: Remove waits in 
drm_atomic_helper_commit_cleanup_done, v2.")

Thanks for patch, pushed.

~Maarten

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

Re: [PATCH 0/6] TDA998x CEC support

[Hans Verkuil]

On 11/29/17 14:45, Russell King - ARM Linux wrote:
> On Wed, Nov 29, 2017 at 01:43:27PM +0100, Hans Verkuil wrote:
>> On 11/29/17 10:11, Russell King - ARM Linux wrote:
>>> On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
 Hi Russell,

 On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> Hi,
>
> This patch series adds CEC support to the DRM TDA998x driver.  The
> TDA998x family of devices integrate a TDA9950 CEC at a separate I2C
> address from the HDMI encoder.
>
> Implementation of the CEC part is separate to allow independent CEC
> implementations, or independent HDMI implementations (since the
> TDA9950 may be a separate device.)

 Thank you for this patch series! I assume you are testing this with a
 BeagleBone Black? If so, do you have a patch for the dts that hooks up the
 interrupt? If possible, I'd like to test this with my BBB.
>>>
>>> I don't, I test it on the SolidRun Dove Cubox.  I can't help with BBB.
>>>
>>
>> Can you post the dts tda snippet you use for the SolidRun Dove Cubox?
>> Or just mail the whole thing to me, or point to a git repo where you
>> have it.
>>
>> I can use that as a starting point for adding CEC support to the BBB.
> 
> There's two patches.  Here's the addition of tda998x to dove-cubox.dts:
> 
> +   tda998x: hdmi-encoder {
> +   compatible = "nxp,tda998x";
> +   reg = <0x70>;
> +   video-ports = <0x234501>;
> +   interrupts-extended = < 27 IRQ_TYPE_LEVEL_LOW>;
> +
> +   port {
> +   tda998x_video: endpoint {
> +   remote-endpoint = <_rgb>;
> +   };
> +   };
> +   };
> 
> And then adding tda998x cec requires:
> 
> tda998x: hdmi-encoder {
> compatible = "nxp,tda998x";
> +   calib-gpio = < 27 0>;
> reg = <0x70>;
> video-ports = <0x234501>;
> interrupts-extended = < 27 IRQ_TYPE_LEVEL_LOW>;
> 

Thank you!

> The problem that I see with BBB (I assume am335x-boneblack-common.dtsi)
> is that the tda998x doesn't mention an interrupt - if the interrupt
> isn't wired to a GPIO, you can't calibrate the TDA998x CEC FRO, and CEC
> will not work.

Looking at the BBB schematics it's wired up, so I should be able to get it to
work there. I'll try that once I have access to my BBB.

> The same problem appears on ARM's evaluation boards that use the TDA998x.
> The chip is present but there's no indication whether the interrupt pin
> is wired.
> 
> That means, despite having several platforms with a TDA998x present, the
> only one I can test CEC with is the Dove Cubox.
> 
> (At the moment, I can't test CEC as a regular part of testing as I've
> "lost" my TV to the living room for the rest of the family to use...
> need to repair their normal TV...)
> 

Regards,

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

Re: [PATCH] drm/fb_helper: Disable all crtc's when initial setup fails.

[Maarten Lankhorst]

Op 28-11-17 om 16:13 schreef Thomas Voegtle:
> On Tue, 28 Nov 2017, Daniel Vetter wrote:
>
>> On Tue, Nov 28, 2017 at 12:16:03PM +0100, Maarten Lankhorst wrote:
>>> Some drivers like i915 start with crtc's enabled, but with deferred
>>> fbcon setup they were no longer disabled as part of fbdev setup.
>>> Headless units could no longer enter pc3 state because the crtc was
>>> still enabled.
>>>
>>> Fix this by calling restore_fbdev_mode when we would have called
>>> it otherwise once during initial fbdev setup.
>>>
>>> Signed-off-by: Maarten Lankhorst 
>>> Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
>>
>> Please use dim fixes to get a more complete Cc: list for regression fixes.
>>
>>> Cc:  # v4.14+
>>> Reported-by: Thomas Voegtle 
>>
>> Reviewed-by: Daniel Vetter 
>>
>> But please confirm with the reporter that it indeed fixes the issue before
>> pushing.
>> -Daniel
>
> I re-checked the latest version of the patch and it indeed fixes the problem.
>
> Thanks,
>
>    Thomas
>
Pushed, thanks for the report. :)

~Maarten

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

Re: [PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Sean Paul]

On Wed, Nov 29, 2017 at 04:40:18PM +0100, Christian König wrote:
> Am 29.11.2017 um 16:36 schrieb Sean Paul:
> > On Wed, Nov 29, 2017 at 04:24:21PM +0100, Christian König wrote:
> > > Am 29.11.2017 um 16:20 schrieb Michal Srb:
> > > > The io_mem_pfn field was added in commit 
> > > > ea642c3216cb2a60d1c0e760ae47ee85c9c16447
> > > > and is called unconditionally. However, not all drivers were updated to 
> > > > set it.
> > > > 
> > > > Use the ttm_bo_default_io_mem_pfn function if a driver did not set its 
> > > > own.
> > > > 
> > > > Signed-off-by: Michal Srb 
> > > NAK, when we have drivers missing this we should set this in the driver 
> > > and
> > > not add the workaround here.
> > Why? What's the benefit in adding the same hook in 10 drivers (I was hoping
> > Michal would also remove the token .io_mem_pfn = ttm_bo_default_io_mem_pfn 
> > from
> > those as well)?
> 
> Not have this extra check in common TTM code? That is seriously bad coding
> style.
> 

[citation neeeded]

I'd argue it's bad form to require everyone add a copypasta hook to their driver
everytime an unrelated driver needs more control than the default gives :-)

I think your point would hold if we were talking about a couple of drivers, but
once you scale to 10+, it's no longer a trivial amount of code. If the null 
check
is too distracting, you could always pull it out into an inline.

Sean


> We have tons of fallbacks like this and I unfortunately even created new one
> without realizing that this is a problem.
> 
> But this really clutters the TTM code and makes it harder to understand.
> 
> Christian.
> 
> > 
> > Sean
> > 
> > > Which driver is missing this? I thought I fixed all of them.
> > > 
> > > Regards,
> > > Christian.
> > > 
> > > > ---
> > > >drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
> > > >1 file changed, 4 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c 
> > > > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > > index c8ebb757e36b..e25a99bc519d 100644
> > > > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > > > @@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> > > > if (bo->mem.bus.is_iomem) {
> > > > /* Iomem should not be marked encrypted */
> > > > cvma.vm_page_prot = 
> > > > pgprot_decrypted(cvma.vm_page_prot);
> > > > -   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
> > > > +   if (bdev->driver->io_mem_pfn)
> > > > +   pfn = bdev->driver->io_mem_pfn(bo, 
> > > > page_offset);
> > > > +   else
> > > > +   pfn = ttm_bo_default_io_mem_pfn(bo, 
> > > > page_offset);
> > > > } else {
> > > > page = ttm->pages[page_offset];
> > > > if (unlikely(!page && i == 0)) {
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 05/18] drm/sun4i: Force the mixer rate at 150MHz

[Maxime Ripard]

On Tue, Nov 28, 2017 at 10:56:31PM +0100, Jernej Škrabec wrote:
> Hi!
> 
> Dne torek, 28. november 2017 ob 09:58:26 CET je Maxime Ripard napisal(a):
> > On Mon, Nov 27, 2017 at 05:07:04PM +0100, Jernej Škrabec wrote:
> > > Hi Maxime,
> > > 
> > > Dne ponedeljek, 27. november 2017 ob 16:41:29 CET je Maxime Ripard 
> napisal(a):
> > > > It seems like the mixer can only run properly when clocked at 150MHz. In
> > > > order to have something more robust than simply a fire-and-forget
> > > > assigned-clocks-rate, let's put that in the code.
> > > > 
> > > > Signed-off-by: Maxime Ripard 
> > > > ---
> > > > 
> > > >  drivers/gpu/drm/sun4i/sun8i_mixer.c | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > > b/drivers/gpu/drm/sun4i/sun8i_mixer.c index cb193c5f1686..c0cdccf772a2
> > > > 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > > @@ -315,6 +315,13 @@ static int sun8i_mixer_bind(struct device *dev,
> > > > struct
> > > > device *master, }
> > > > 
> > > > clk_prepare_enable(mixer->mod_clk);
> > > > 
> > > > +   /*
> > > > +* It seems that we need to enforce that rate for whatever
> > > > +* reason for the mixer to be functional. Make sure it's the
> > > > +* case.
> > > > +*/
> > > > +   clk_set_rate(mixer->mod_clk, 15000);
> > > > +
> > > 
> > > H3 mixer works at much higher rate and if we want to support tv out, it
> > > must be dividable by 432 MHz, so either 432 MHz or maybe even 864 MHz.
> > > 
> > > We talked about that few months ago.
> > > 
> > > I guess this should be read from mixer configuration structure.
> > 
> > That works for me. Actually, I didn't need it at all for the LVDS
> > output on the A83t, the default seems to work just fine. Do you know
> > what it's related to? Maybe we can make that a bit more dynamic?
> 
> There doesn't seem to be any rule to determine which frequency is best, 
> except 
> on H3. Obviously, it must be high enough to process data for current 
> resolution, which means 150 MHz should be just enough for 1920x1080@60Hz. I 
> guess we should just check BSP configuration and use same rate since AW 
> engineers may know something we don't.

Yeah, that makes sense. And the fact that it's in the kernel allows us
to change for something smarter when we want (and if we need) to.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Christian König]

Am 29.11.2017 um 16:44 schrieb Sean Paul:

On Wed, Nov 29, 2017 at 04:40:18PM +0100, Christian König wrote:

Am 29.11.2017 um 16:36 schrieb Sean Paul:

On Wed, Nov 29, 2017 at 04:24:21PM +0100, Christian König wrote:

Am 29.11.2017 um 16:20 schrieb Michal Srb:

The io_mem_pfn field was added in commit 
ea642c3216cb2a60d1c0e760ae47ee85c9c16447
and is called unconditionally. However, not all drivers were updated to set it.

Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.

Signed-off-by: Michal Srb 

NAK, when we have drivers missing this we should set this in the driver and
not add the workaround here.

Why? What's the benefit in adding the same hook in 10 drivers (I was hoping
Michal would also remove the token .io_mem_pfn = ttm_bo_default_io_mem_pfn from
those as well)?

Not have this extra check in common TTM code? That is seriously bad coding
style.


[citation neeeded]

I'd argue it's bad form to require everyone add a copypasta hook to their driver
everytime an unrelated driver needs more control than the default gives :-)


Well that is another design problem of TTM that it works like a middle 
layer instead of a tool. But I'm seriously not going to fix this anytime 
soon.



I think your point would hold if we were talking about a couple of drivers, but
once you scale to 10+, it's no longer a trivial amount of code. If the null 
check
is too distracting, you could always pull it out into an inline.

Yeah, that is one possibility that would work for me as well.

TTM has patterns like the following:

First occasion:
if (a_is_available)
    do_a();
else
    do_b();

Same code a bit lower:
if (a_is_available)
    do_a()
/* Else is missing here */

I'm seriously favoring updating a dozen drivers just to avoid more of this.

If you want to fix that with adding wrapper functions to call the driver 
callback and give a consistent operation when the callback isn't 
available then I'm perfectly fine with that as well. Patches are always 
welcome.


Christian.



Sean



We have tons of fallbacks like this and I unfortunately even created new one
without realizing that this is a problem.

But this really clutters the TTM code and makes it harder to understand.

Christian.


Sean


Which driver is missing this? I thought I fixed all of them.

Regards,
Christian.


---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index c8ebb757e36b..e25a99bc519d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (bo->mem.bus.is_iomem) {
/* Iomem should not be marked encrypted */
cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
-   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   if (bdev->driver->io_mem_pfn)
+   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   else
+   pfn = ttm_bo_default_io_mem_pfn(bo, 
page_offset);
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {

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


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

Re: [PATCH] drm: hibmc: Initialize the hibmc_bo_driver.io_mem_pfn

[Michal Srb]

On středa 29. listopadu 2017 15:47:30 CET Sean Paul wrote:
> On Wed, Nov 29, 2017 at 12:33:24PM +0100, m...@suse.com wrote:
> > From: Michal Srb 
> > 
> > The io_mem_pfn field was added in ea642c3216cb2a60d1c0e760ae47ee85c9c16447
> > and is used unconditionally. Most drivers were updated to set it to the
> > default implementation ttm_bo_default_io_mem_pfn, but hibmc was not.
> > 
> > This fixes crash in ttm_bo_vm_fault when hibmc driver is used.
> 
> Instead of just doing the same cargo cult in this driver, lets just call the
> default function when io_mem_pfn is NULL. Looks like 9 other drivers are
> affected as well.

Ok, that makes sense.

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

Re: [PATCH v3 0/7] drm/bridge: tc358767: fixes and improvements

[Andrey Gusakov]

Andrzej,

Please queue 1-6 to -fixes, 7 to -next.

Andrey.

On Wed, Nov 29, 2017 at 2:03 PM, Andrzej Hajda  wrote:

> On 07.11.2017 17:56, Andrey Gusakov wrote:
> > This set of patches fixes several issues that was found during testing
> > tc358767 with desktop DisplayPort displays.
> >
> > Changes since v3
> >   - added comment about removed VPCTRL0 write
> >   - corrected comment in "filter out too high modes"
> >   - added sing-off
> > Changes since v2:
> >   - fixed maximum pixelclock frequency
> >   - copyright patch added
> >
> > Andrey Gusakov (7):
> >   drm/bridge: tc358767: do no fail on hi-res displays
> >   drm/bridge: tc358767: filter out too high modes
> >   drm/bridge: tc358767: fix DP0_MISC register set
> >   drm/bridge: tc358767: fix timing calculations
> >   drm/bridge: tc358767: fix AUXDATAn registers access
> >   drm/bridge: tc358767: fix 1-lane behavior
> >   drm/bridge: tc358767: add copyright lines
> >
> >  drivers/gpu/drm/bridge/tc358767.c |   75 +-
> ---
> >  1 file changed, 42 insertions(+), 33 deletions(-)
> >
>
> Andrey,
>
> Is it OK if I queue patches 1-6 to drm-misc-fixes, and 7 to drm-misc-next?
>
> Or I can put them all to drm-misc-next.
>
> Any preferences?
>
>
> Regards
>
> Andrzej
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Christian König]

Am 29.11.2017 um 16:20 schrieb Michal Srb:

The io_mem_pfn field was added in commit 
ea642c3216cb2a60d1c0e760ae47ee85c9c16447
and is called unconditionally. However, not all drivers were updated to set it.

Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.

Signed-off-by: Michal Srb 


NAK, when we have drivers missing this we should set this in the driver 
and not add the workaround here.


Which driver is missing this? I thought I fixed all of them.

Regards,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index c8ebb757e36b..e25a99bc519d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (bo->mem.bus.is_iomem) {
/* Iomem should not be marked encrypted */
cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
-   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   if (bdev->driver->io_mem_pfn)
+   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   else
+   pfn = ttm_bo_default_io_mem_pfn(bo, 
page_offset);
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {


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

Re: [PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Michal Srb]

On Wednesday 29th November 2017 16:24:21 CET Christian König  wrote:
> Am 29.11.2017 um 16:20 schrieb Michal Srb:
> > The io_mem_pfn field was added in commit
> > ea642c3216cb2a60d1c0e760ae47ee85c9c16447 and is called unconditionally.
> > However, not all drivers were updated to set it.
> > 
> > Use the ttm_bo_default_io_mem_pfn function if a driver did not set its
> > own.
> > 
> > Signed-off-by: Michal Srb 
> 
> NAK, when we have drivers missing this we should set this in the driver
> and not add the workaround here.
> 
> Which driver is missing this? I thought I fixed all of them.

The one where I ran into the problem is hibmc. I've sent patch fixing it, but 
reportedly there is more drivers with the same issue, so this fix was 
suggested instead:

On Wednesday 29th November 2017 15:47:30 CET Sean Paul wrote:
> Instead of just doing the same cargo cult in this driver, lets just call the
> default function when io_mem_pfn is NULL. Looks like 9 other drivers are
> affected as well.

> Sean

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

Re: [PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Sean Paul]

On Wed, Nov 29, 2017 at 04:24:21PM +0100, Christian König wrote:
> Am 29.11.2017 um 16:20 schrieb Michal Srb:
> > The io_mem_pfn field was added in commit 
> > ea642c3216cb2a60d1c0e760ae47ee85c9c16447
> > and is called unconditionally. However, not all drivers were updated to set 
> > it.
> > 
> > Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.
> > 
> > Signed-off-by: Michal Srb 
> 
> NAK, when we have drivers missing this we should set this in the driver and
> not add the workaround here.

Why? What's the benefit in adding the same hook in 10 drivers (I was hoping
Michal would also remove the token .io_mem_pfn = ttm_bo_default_io_mem_pfn from
those as well)?

Sean

> 
> Which driver is missing this? I thought I fixed all of them.
> 
> Regards,
> Christian.
> 
> > ---
> >   drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
> >   1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c 
> > b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > index c8ebb757e36b..e25a99bc519d 100644
> > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> > @@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
> > if (bo->mem.bus.is_iomem) {
> > /* Iomem should not be marked encrypted */
> > cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
> > -   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
> > +   if (bdev->driver->io_mem_pfn)
> > +   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
> > +   else
> > +   pfn = ttm_bo_default_io_mem_pfn(bo, 
> > page_offset);
> > } else {
> > page = ttm->pages[page_offset];
> > if (unlikely(!page && i == 0)) {
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ttm: Use ttm_bo_default_io_mem_pfn if io_mem_pfn is NULL

[Christian König]

Am 29.11.2017 um 16:36 schrieb Sean Paul:

On Wed, Nov 29, 2017 at 04:24:21PM +0100, Christian König wrote:

Am 29.11.2017 um 16:20 schrieb Michal Srb:

The io_mem_pfn field was added in commit 
ea642c3216cb2a60d1c0e760ae47ee85c9c16447
and is called unconditionally. However, not all drivers were updated to set it.

Use the ttm_bo_default_io_mem_pfn function if a driver did not set its own.

Signed-off-by: Michal Srb 

NAK, when we have drivers missing this we should set this in the driver and
not add the workaround here.

Why? What's the benefit in adding the same hook in 10 drivers (I was hoping
Michal would also remove the token .io_mem_pfn = ttm_bo_default_io_mem_pfn from
those as well)?


Not have this extra check in common TTM code? That is seriously bad 
coding style.


We have tons of fallbacks like this and I unfortunately even created new 
one without realizing that this is a problem.


But this really clutters the TTM code and makes it harder to understand.

Christian.



Sean


Which driver is missing this? I thought I fixed all of them.

Regards,
Christian.


---
   drivers/gpu/drm/ttm/ttm_bo_vm.c | 5 -
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index c8ebb757e36b..e25a99bc519d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -234,7 +234,10 @@ static int ttm_bo_vm_fault(struct vm_fault *vmf)
if (bo->mem.bus.is_iomem) {
/* Iomem should not be marked encrypted */
cvma.vm_page_prot = pgprot_decrypted(cvma.vm_page_prot);
-   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   if (bdev->driver->io_mem_pfn)
+   pfn = bdev->driver->io_mem_pfn(bo, page_offset);
+   else
+   pfn = ttm_bo_default_io_mem_pfn(bo, 
page_offset);
} else {
page = ttm->pages[page_offset];
if (unlikely(!page && i == 0)) {

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


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

Re: [PATCH 13/17] drm/sun4i: Add DE2 CSC library

[Maxime Ripard]

On Tue, Nov 28, 2017 at 10:43:39PM +0100, Jernej Škrabec wrote:
> Hi!
> 
> Dne torek, 28. november 2017 ob 21:55:50 CET je Maxime Ripard napisal(a):
> > On Mon, Nov 27, 2017 at 09:57:46PM +0100, Jernej Skrabec wrote:
> > > DE2 have many CSC units - channel input CSC, channel output CSC and
> > > mixer output CSC and maybe more.
> > > 
> > > Fortunately, they have all same register layout, only base offsets
> > > differs.
> > > 
> > > Add support only for channel output CSC for now.
> > > 
> > > Signed-off-by: Jernej Skrabec 
> > > ---
> > > 
> > >  drivers/gpu/drm/sun4i/Makefile|  2 +-
> > >  drivers/gpu/drm/sun4i/sun8i_csc.c | 90
> > >  +++
> > >  drivers/gpu/drm/sun4i/sun8i_csc.h | 36 
> > >  3 files changed, 127 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.c
> > >  create mode 100644 drivers/gpu/drm/sun4i/sun8i_csc.h
> > > 
> > > diff --git a/drivers/gpu/drm/sun4i/Makefile
> > > b/drivers/gpu/drm/sun4i/Makefile index 70df480792f9..f82cc69ede72 100644
> > > --- a/drivers/gpu/drm/sun4i/Makefile
> > > +++ b/drivers/gpu/drm/sun4i/Makefile
> > > @@ -9,7 +9,7 @@ sun4i-drm-hdmi-y  += sun4i_hdmi_enc.o
> > > 
> > >  sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
> > >  sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
> > > 
> > > -sun8i-mixer-y+= sun8i_mixer.o sun8i_layer.o 
> > > sun8i_scaler.o
> > > +sun8i-mixer-y+= sun8i_mixer.o sun8i_layer.o 
> > > sun8i_scaler.o 
> sun8i_csc.o
> > 
> > Please wrap that line.
> > 
> > >  sun4i-tcon-y += sun4i_crtc.o
> > >  sun4i-tcon-y += sun4i_dotclock.o
> > > 
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_csc.c
> > > b/drivers/gpu/drm/sun4i/sun8i_csc.c new file mode 100644
> > > index ..d48c28f8d568
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_csc.c
> > > @@ -0,0 +1,90 @@
> > > +/*
> > > + * Copyright (C) Jernej Skrabec 
> > > + *
> > > + * This program is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU General Public License as
> > > + * published by the Free Software Foundation; either version 2 of
> > > + * the License, or (at your option) any later version.
> > > + */
> > > +
> > > +#include "sun8i_csc.h"
> > > +
> > > +static const u32 ccsc_base[2][2] = {
> > > + {CCSC00_OFFSET, CCSC01_OFFSET},
> > > + {CCSC10_OFFSET, CCSC11_OFFSET},
> > > +};
> > > +
> > > +/*
> > > + * Factors are in two's complement format, 10 bits for fractinal part.
> > > + * First tree values in each line are multiplication factor and last
> > > + * value is constant, which is added at the end.
> > > + */
> > > +static const u32 yuv2rgb[] = {
> > > + 0x04A8, 0x, 0x0662, 0xFFFC845A,
> > > + 0x04A8, 0xFE6F, 0xFCBF, 0x00021DF4,
> > > + 0x04A8, 0x0813, 0x, 0xFFFBAC4A,
> > > +};
> > > +
> > > +static const u32 yvu2rgb[] = {
> > > + 0x04A8, 0x0662, 0x, 0xFFFC845A,
> > > + 0x04A8, 0xFCBF, 0xFE6F, 0x00021DF4,
> > > + 0x04A8, 0x, 0x0813, 0xFFFBAC4A,
> > > +};
> > > +
> > > +static void sun8i_csc_set_coefficients(struct regmap *map, u32 base,
> > > +enum sun8i_csc_mode mode)
> > > +{
> > > + const u32 *table;
> > > + int i, data;
> > > +
> > > + switch (mode) {
> > > + case SUN8I_CSC_MODE_YUV2RGB:
> > > + table = yuv2rgb;
> > > + break;
> > > + case SUN8I_CSC_MODE_YVU2RGB:
> > > + table = yvu2rgb;
> > > + break;
> > > + default:
> > > + WARN(1, "Wrong CSC mode specified.");
> > 
> > A hard warn is a bit overkill here. What about a dev_warn?
> 
> dev_warn requires device, which is not available here and seems a bit 
> overkill 
> to have it as parameter just to print warning. What about DRM_WARN()?

Anything that doesn't make it look like the world just blew up is fine
by me :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

Re: [PATCH 1/5] drm/armada: fix leak of crtc structure

[Sean Paul]

On Wed, Nov 29, 2017 at 11:45:43AM +, Russell King wrote:
> Fix the leak of the CRTC structure in the failure paths of
> armada_drm_crtc_create().
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/armada/armada_crtc.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
> b/drivers/gpu/drm/armada/armada_crtc.c
> index 2e065facdce7..844d488b6654 100644
> --- a/drivers/gpu/drm/armada/armada_crtc.c
> +++ b/drivers/gpu/drm/armada/armada_crtc.c
> @@ -1246,11 +1246,14 @@ static int armada_drm_crtc_create(struct drm_device 
> *drm, struct device *dev,
>   dcrtc->crtc.port = port;
>  
>   primary = kzalloc(sizeof(*primary), GFP_KERNEL);
> - if (!primary)
> + if (!primary) {
> + kfree(dcrtc);
>   return -ENOMEM;
> + }
>  
>   ret = armada_drm_plane_init(primary);
>   if (ret) {
> + kfree(dcrtc);
>   kfree(primary);
>   return ret;
>   }
> @@ -1262,14 +1265,17 @@ static int armada_drm_crtc_create(struct drm_device 
> *drm, struct device *dev,
>  NULL,
>  DRM_PLANE_TYPE_PRIMARY, NULL);
>   if (ret) {
> + kfree(dcrtc);
>   kfree(primary);
>   return ret;
>   }
>  
>   ret = drm_crtc_init_with_planes(drm, >crtc, >base, NULL,
>   _crtc_funcs, NULL);
> - if (ret)
> + if (ret) {
> + kfree(dcrtc);
>   goto err_crtc_init;

The mixed use of cleaning up at every exit and the lone label is a bit messy and
prone to bugs such as the one you're fixing. How about you label everything
and then just clean up once?

It also seems like you're missing cleanup if armada_overlay_plane_create()
fails?

Sean

> + }
>  
>   drm_crtc_helper_add(>crtc, _crtc_helper_funcs);
>  
> -- 
> 2.7.4
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103791

--- Comment #10 from Michel Dänzer  ---
BTW, the patch is completely untested; if it fails to compile, hopefully it
won't be hard to fix it up.

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

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

[Brian Norris]

On Tue, Nov 28, 2017 at 6:02 PM, Sean Paul  wrote:
> On Tue, Nov 28, 2017 at 02:55:41PM -0800, Brian Norris wrote:
>> On Tue, Nov 28, 2017 at 12:48:43PM -0800, Matthias Kaehlcke wrote:
>> > El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit:
>> >
>> > > Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
>> > > MIPI DSI host controller bridge.
>> > >
>> > > v2:
>> > >add err_pllref, remove unnecessary encoder.enable & disable
>> > >correct spelling mistakes
>> > > v3:
>> > >call dw_mipi_dsi_unbind() in dw_mipi_dsi_rockchip_unbind()
>> > >fix typo, use of_device_get_match_data(),
>> > >change some ‘bind()’ logic into 'probe()'
>> > >add 'dev_set_drvdata()'
>>
>> I believe the changelog normally goes below the "---", so it gets
>> dropped when a maintainer applies a final version.
>>
>
> We're kind of different in drm land. Some prefer to keep the changelog above 
> the
> fold and attribute the changes to reviewers so they get recognition for their
> efforts.

Ah, now I remember reading that somewhere. Seems nice, I suppose. (And
hey, git logs are cheap.) I guess my "I don't review DRM patches much"
status is showing :)

> At any rate, I'm just happy to see changelogs.

Yep :)

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

[Bug 103791] Tearing after screen wakeup/on

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=103791

--- Comment #9 from Michel Dänzer  ---
Created attachment 135808
  --> https://bugs.freedesktop.org/attachment.cgi?id=135808=edit
Add debugging output why the ioctls return -EINVAL

Sorry, been busy with other fires.

Please recompile the drm.ko module with this patch applied, reproduce the
result with the resulting binary and attach the dmesg output.

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