Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111

On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote: > Russell King - ARM Linux <li...@armlinux.org.uk> writes: > > > On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote: > >> v5: Move register definitions inside the driver directory, fix build > &g

Re: [PATCH v5] drm/pl111: Initial drm/kms driver for pl111

On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote: > v5: Move register definitions inside the driver directory, fix build > in COMPILE_TEST and !AMBA mode. Why is it necessary to move the register definitions there, when they're already available in linux/amba/clcd.h and are

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

On Mon, Apr 10, 2017 at 02:08:44PM +0200, Daniel Vetter wrote: > On Mon, Apr 10, 2017 at 12:35:43PM +0200, Neil Armstrong wrote: > > On 04/10/2017 12:08 PM, Russell King - ARM Linux wrote: > > > On Mon, Apr 10, 2017 at 10:49:18AM +0530, Archit Taneja wrote: > > >> H

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

On Mon, Apr 10, 2017 at 10:49:18AM +0530, Archit Taneja wrote: > Hi, > > On 04/07/2017 07:49 PM, Romain Perier wrote: > >This set of patches split the stream handling functions in two parts. It > >introduces new callbacks that are specific to each variant, one for I2S > >and one for AHB. > > >

Re: [PATCH 0/2] drm: dw-hdmi: various improvements

On Mon, Apr 10, 2017 at 12:35:43PM +0200, Neil Armstrong wrote: > Hi Russell, > > Cross tree with media has already been done on this cycle with the > dw-hdmi formats changes. > > Nevertheless, please push your updated dw-hdmi cec patchset for tests > and review based on the latest drm-misc-next

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

On Mon, Apr 03, 2017 at 11:31:34AM +0100, Liviu Dudau wrote: > On Fri, Mar 31, 2017 at 02:48:10PM +0100, Russell King - ARM Linux wrote: > > I sent a reminder on 20th February about it, and we discussed it, and I > > said at the time I did not have time to test your patch.

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote: > Comments are welcome. I'd like to get this in for the 4.12 kernel as > this is a missing piece needed to integrate CEC drivers. First two patches seem fine, and work with dw-hdmi. I'll hold dw-hdmi off until after 4.11 - I currently

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

On Fri, Mar 31, 2017 at 12:41:30PM +0100, Liviu Dudau wrote: > On Fri, Mar 31, 2017 at 11:27:51AM +0100, Russell King - ARM Linux wrote: > > On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote: > > > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wro

Re: [PATCHv6 01/10] media: add CEC notifier support

On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote: > +struct cec_notifier *cec_notifier_get(struct device *dev) > +{ > + struct cec_notifier *n; > + > + mutex_lock(_notifiers_lock); > + list_for_each_entry(n, _notifiers, head) { > + if (n->dev == dev) { > +

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

On Fri, Mar 31, 2017 at 11:23:45AM +0100, Liviu Dudau wrote: > On Fri, Mar 31, 2017 at 11:20:35AM +0100, Russell King - ARM Linux wrote: > > On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > > > Hi Russell, > > > > > > You were Cc-ed in

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote: > The calculation of the framebuffer's start address was wrongly using > the CRTC's x and y position rather than the one of the source > framebuffer. To fix that we need to update the plane_check code to > call

Re: [PATCHv6 00/10] video/exynos/sti/cec: add CEC notifier & use in drivers

On Fri, Mar 31, 2017 at 03:39:20PM +0100, Russell King - ARM Linux wrote: > On Fri, Mar 31, 2017 at 02:20:26PM +0200, Hans Verkuil wrote: > > Comments are welcome. I'd like to get this in for the 4.12 kernel as > > this is a missing piece needed to integrate CEC drivers. > &

Re: [PATCH v2] drm: hdlcd: Fix the calculation of the scanout start address

On Fri, Mar 31, 2017 at 02:18:31PM +0100, Liviu Dudau wrote: > On Fri, Mar 31, 2017 at 10:49:38AM +0100, Russell King - ARM Linux wrote: > > On Wed, Mar 08, 2017 at 04:30:25PM +, Liviu Dudau wrote: > > > The calculation of the framebuffer's start address was wrongly using

Re: [PATCHv6 01/10] media: add CEC notifier support

On Sat, Apr 01, 2017 at 11:22:03AM +0200, Hans Verkuil wrote: > On 31/03/17 22:46, Russell King - ARM Linux wrote: > > On Fri, Mar 31, 2017 at 02:20:27PM +0200, Hans Verkuil wrote: > >> +struct cec_notifier *cec_notifier_get(struct device *dev) > >> +{ >

Re: [PATCH 1/3] drm/arm: hdlcd: properly validate plane state

On Fri, Mar 31, 2017 at 11:18:50AM +0100, Liviu Dudau wrote: > Hi Russell, > > You were Cc-ed in a patch from March 8th that did all this: > > https://lists.freedesktop.org/archives/dri-devel/2017-March/135172.html I'm aware of that (you may notice that this was threaded to that patch.) > I

Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

On Fri, Mar 31, 2017 at 02:36:31PM +0100, Dan MacDonald wrote: > Hi all > > Up until now I've only ever used the most basic features of git, so > I've had to do some research into how to best/cleanly extract > Phillipps patches so that I can include his changes into an Arch > kernel PKGBUILD. >

Re: [PATCHv5 04/11] exynos_hdmi: add CEC notifier support

On Wed, Mar 29, 2017 at 04:15:36PM +0200, Hans Verkuil wrote: > + cec_notifier_set_phys_addr(hdata->notifier, > +cec_get_edid_phys_addr(edid)); This pattern causes problems - can we have the notifier taking the EDID please, and stubs in cec-notifier.h to stub

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote: > Hm, I certainly want it... but it would be unreasonable of me to expect > Eric to cold-code a big upfront design for systems he can't even test > this on. > > What I would request would rather be: please do not put in any >

Re: [PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane

On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index 34cb73d0db77..b54fd8cbd3a6 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++

Re: [PATCH v3 2/3] drm/pl111: Initial drm/kms driver for pl111

On Mon, Mar 20, 2017 at 04:36:14PM -0700, Eric Anholt wrote: > +static struct amba_driver pl111_amba_driver = { > + .drv = { > + .name = "clcd-pl11x", either: .name = "clcd-pl111", or: .name = "drm-clcd-pl111", otherwise the driver names will

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

On Sun, Mar 19, 2017 at 01:03:42PM -0700, Chris Healy wrote: > I don't have any input on this binary divider subject but I do want to > bring up some observations regarding Etnaviv GPU power management that > seems relevant. GPU cooling isn't really to do with GPU power management, it's more to

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

On Mon, Mar 20, 2017 at 10:19:35AM +0100, Lucas Stach wrote: > Yes, probably we want to have both at some point. The cooling-device > stuff is about throttling the GPU when the SoC reaches critical > temperatures. > > The devfreq governors are about providing exactly the right performance >

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > Add support for video hotplug detect and EDID/ELD notifiers, which is used > to convey information from video drivers to their CEC and audio counterparts. > > Based on an earlier

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

On Mon, Mar 20, 2017 at 02:26:16PM +, Russell King - ARM Linux wrote: > On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote: > > From: Hans Verkuil <hans.verk...@cisco.com> > > > > Add support for video hotplug detect and EDID/ELD notifiers, which is use

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

On Fri, Mar 17, 2017 at 03:58:27PM +0100, Lucas Stach wrote: > Am Freitag, den 17.03.2017, 14:42 + schrieb Russell King - ARM > Linux: > > On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote: > > > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabe

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote: > This is a modesetting driver for the pl111 CLCD display controller > found on various ARM platforms such as the Versatile Express. The > driver has only been tested on the bcm911360_entphn platform so far, > with PRIME-based buffer

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

On Fri, Mar 17, 2017 at 03:10:21PM +0100, Lucas Stach wrote: > Am Donnerstag, den 16.03.2017, 12:05 +0100 schrieb Philipp Zabel: > > Hi Gustavo, > > > > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote: > > [...] > > > I was thinking on some function that would iterate over all fences in

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

On Wed, Mar 15, 2017 at 02:03:09PM +0100, Lucas Stach wrote: > Am Sonntag, den 12.03.2017, 19:00 + schrieb Russell King: > > Each Vivante GPU contains a clock divider which can divide the GPU clock > > by 2^n, which can lower the power dissipation from the GPU. It has been > > suggested that

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

On Mon, Mar 13, 2017 at 12:55:58PM +, Jose Abreu wrote: > Hi, > > > On 13-03-2017 09:36, Russell King - ARM Linux wrote: > > On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote: > >> On 03/10/2017 10:35 AM, Romain Perier wrote: > >>> Curren

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

On Mon, Mar 13, 2017 at 10:27:08AM +0100, Neil Armstrong wrote: > On 03/10/2017 10:35 AM, Romain Perier wrote: > > Currently, the audio sampler clock is enabled from dw_hdmi_setup() at > > step E. and is kept enabled for later use. This clock should be enabled > > and disabled along with the

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

On Fri, Mar 10, 2017 at 11:21:53AM +0100, Romain Perier wrote: > Hello, > > Le 10/03/2017 à 10:46, Russell King - ARM Linux a écrit : > > On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote: > >> Currently, the audio sampler clock is enabled from dw_hdm

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

On Fri, Mar 10, 2017 at 11:58:19AM +0100, Romain Perier wrote: > Hello, > > Le 10/03/2017 à 11:27, Russell King - ARM Linux a écrit : > > I also would not think that it's platform specific - remember that > > this is Designware IP, and it's likely that other platforms with &g

Re: [PATCH] drm: dw_hdmi: Gate audio sampler clock from the enablement functions

On Fri, Mar 10, 2017 at 10:35:09AM +0100, Romain Perier wrote: > Currently, the audio sampler clock is enabled from dw_hdmi_setup() at > step E. and is kept enabled for later use. This clock should be enabled > and disabled along with the actual audio stream and not always on (that > is bad for

Re: [PATCH RESEND] drm: dw_hdmi: Don't rely on the status of the bridge for updating HPD

On Wed, Mar 08, 2017 at 09:15:24AM +0100, Romain Perier wrote: > - dw_hdmi_update_power() will be called. As hdmi->force will be equal to > DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. This > field has not been updated by the irq handler, so it will be false and > DRM_FORCE_ON

Re: [PATCH 2/3] drm/etnaviv: move fence allocation out of etnaviv_gpu_submit()

On Wed, Mar 08, 2017 at 11:42:17AM -0300, Gustavo Padovan wrote: > Hi Philipp, > > 2017-03-08 Philipp Zabel : > > > The next patch will need the dma_fence to create the sync_file in > > etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested. > > > >

Re: [PATCH 0/4] Fix DP busy wait and defer disabling overlay plane

On Mon, Mar 06, 2017 at 02:50:58PM +0100, Philipp Zabel wrote: > Sorry, I should have mentioned that this must be called from inside an > existing kernel git repository. The idea is that you don't have to clone > the whole kernel through our pipe, but can use the upstream repository, > which has a

Re: [PATCHv4 1/9] video: add hotplug detect notifier support

On Mon, Feb 27, 2017 at 06:21:05PM +0100, Hans Verkuil wrote: > On 02/27/2017 06:04 PM, Russell King - ARM Linux wrote: > > I'm afraid that I walked away from this after it became clear that there > > was little hope for any forward progress being made in a timely manner > >

Re: [PATCHv4 1/9] video: add hotplug detect notifier support

On Mon, Feb 27, 2017 at 05:08:41PM +0100, Daniel Vetter wrote: > On Mon, Feb 06, 2017 at 11:29:43AM +0100, Hans Verkuil wrote: > > From: Hans Verkuil > > > > Add support for video hotplug detect and EDID/ELD notifiers, which is used > > to convey information from video

Re: [BUG] hdlcd gets confused about base address

On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote: > Sorry, looks like this fell through the cracks of us trying to fix the > other issues you were seeing. I'm attaching a patch, please let me know > if this works for you. I don't have time to test right now, but it looks similar to

Re: [BUG] hdlcd gets confused about base address

On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote: > This stuff should be using the clipped coordinates, not the user > coordinates. And it doesn't look like this guy is even calling the > clip helper thing. > > malidp seems to be calling that thing, but it still doesn't > manage to

Re: [BUG] hdlcd gets confused about base address

On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote: > Something I also noticed is this: > > scanout_start = gem->paddr + plane->state->fb->offsets[0] + > plane->state->crtc_y * plane->state->fb->pitches[0] +

Re: [PATCH] drm: ensure atomic messages consistently include the name of the component

On Mon, Feb 13, 2017 at 02:37:31PM +0100, Maarten Lankhorst wrote: > All for it, looks sane. The last hunk fails to apply because it's based on > an older version of page_flip, but easy enough to fix. Yes, it's based on v4.10-rc7. Thanks. -- RMK's Patch system:

Re: imxdrm issue on Hummingboard with LVDS enabled

On Mon, Feb 13, 2017 at 09:17:49AM +0100, Thierry Reding wrote: > Of course, the above still requires that the core messages output the > name along with the ID. Thankfully, that's not a very big patch. I'll post it later today. -- RMK's Patch system:

Re: imxdrm issue on SABRE Lite

On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote: > On Sun, Feb 12, 2017 at 12:15:46AM +0000, Russell King - ARM Linux wrote: > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > b/drivers/gpu/drm/drm_atomic_helper.c > > index 21f992605541..46668d071d6a 100

Re: imxdrm issue on SABRE Lite

On Mon, Feb 13, 2017 at 08:55:53AM +, Chris Wilson wrote: > On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote: > > On Sun, Feb 12, 2017 at 12:15:46AM +, Russell King - ARM Linux wrote: > > > On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote

Re: imxdrm issue on Hummingboard with LVDS enabled

On Sun, Feb 12, 2017 at 01:18:54PM +, Russell King - ARM Linux wrote: > Hi, > > Here's another issue with imxdrm. I got this while trying to reproduce > Dan's problem by enabling the lvds output using the patch below > originally from Fabio, but updated a bit. This doesn't o

imxdrm issue on Hummingboard with LVDS enabled

Hi, Here's another issue with imxdrm. I got this while trying to reproduce Dan's problem by enabling the lvds output using the patch below originally from Fabio, but updated a bit. This doesn't occur if I leave LVDS disabled. The taint is due to the IMX capture modules from Steve, who chose to

Re: imxdrm issue on Hummingboard with LVDS enabled

On Sun, Feb 12, 2017 at 01:42:38PM +, Russell King - ARM Linux wrote: > On Sun, Feb 12, 2017 at 01:18:54PM +0000, Russell King - ARM Linux wrote: > > Hi, > > > > Here's another issue with imxdrm. I got this while trying to reproduce > > Dan's problem by ena

Re: imxdrm issue on SABRE Lite

On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote: > [ 43.997066] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* > [CRTC:24:crtc-0] flip_done timed out > [ 55.517063] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* > [CRTC:24:crtc-0] flip_done timed out This seems to lay

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

On Tue, Feb 07, 2017 at 12:42:15PM +0200, Laurent Pinchart wrote: > On an unrelated note, for security reasons we should try to make the driver > structure static, or at least move ops to a static structure. ITYM "const" not "static". "static" doesn't get you anything from a security point of

Re: [PATCH v3 06/23] drm: armada: use vblank hooks in struct drm_crtc_funcs

On Tue, Feb 07, 2017 at 05:16:18PM +0800, Shawn Guo wrote: > From: Shawn Guo > > The vblank hooks in struct drm_driver are deprecated and only meant for > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks > in struct drm_crtc_funcs should be used

Re: [PATCH v3 02/23] drm: remove drm_vblank_no_hw_counter assignment from driver code

On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote: For: > drivers/gpu/drm/armada/armada_drv.c | 1 - Acked-by: Russell King -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at

Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node

On Mon, Feb 06, 2017 at 05:55:33PM +, Liviu Dudau wrote: > OK, I will fix the driver if Rob's patch still requires it. I don't think you ever needed it. As Rob says, what you're testing won't ever change unless you're using overlays - it's certainly not dependent on the tda998x module being

Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node

On Mon, Feb 06, 2017 at 05:23:06PM +, Liviu Dudau wrote: > On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote: > > On Mon, Feb 06, 2017 at 10:29:33AM +, Liviu Dudau wrote: > > > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote: > > > > - /* add the remote encoder

Re: [PATCH 0/5] DRM OF graph clean-up

On Fri, Feb 03, 2017 at 09:36:30PM -0600, Rob Herring wrote: > The Armada and Rockchip drivers remain oddballs with their own graph > parsing. I can't see how the armada driver even can work. There's > nothing to instantiate the armada-drm device either in DT or the kernel. Correct, that's

Re: [PATCH 01/10] drm/etnaviv: add uapi for register read feature

On Mon, Jan 30, 2017 at 09:18:25PM +0100, Thierry Reding wrote: > On Fri, Dec 09, 2016 at 12:21:22PM +0100, Christian Gmeiner wrote: > > @@ -167,6 +174,9 @@ struct drm_etnaviv_gem_submit { > > __u64 bos;/* in, ptr to array of submit_bo's */ > > __u64 relocs; /* in, ptr

Re: [PATCH 09/10] drm/etnaviv: validate readback register address

On Mon, Jan 30, 2017 at 11:58:32AM +0100, Lucas Stach wrote: > Am Freitag, den 09.12.2016, 12:21 +0100 schrieb Christian Gmeiner: > > Reading some registers end in a system crash ala: > > > > Unhandled fault: external abort on non-linefetch (0x1028) at 0xfe641000 > > Internal error: : 1028

Re: [PATCH 08/10] drm/etnaviv: make it possible to reconfigure perf counter

On Mon, Jan 30, 2017 at 12:01:18PM +0100, Lucas Stach wrote: > Am Freitag, den 09.12.2016, 12:21 +0100 schrieb Christian Gmeiner: > > - if (r->flags) { > > - DRM_ERROR("readback flags not 0"); > > + if (r->flags > ETNA_READBACK_PERF) { > > +

[PATCH] drm: Remove the struct drm_device platformdev field

On Sun, Dec 18, 2016 at 12:39:16AM +0200, Laurent Pinchart wrote: > The field contains a pointer to the parent platform device of the DRM > device. As struct drm_device also contains a dev pointer to the struct > device embedded in the platform_device structure, the platformdev field > is

[PATCH] drm/armada: Fix compile fail

On Fri, Dec 30, 2016 at 05:33:38PM +0100, Daniel Vetter wrote: > I reported the include issue for tracepoints a while ago, but nothing > seems to have happened. Now it bit us, since the drm_mm_print > conversion was broken for armada. Fix them both. Nothing's happened because I haven't had an

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote: > Instead of spreading version-dependent PHY power handling code around, > group it in two functions to power the PHY on and off and use them > through the driver. > > Powering off the PHY at the beginning of the setup phase is

[PATCH] drm/etnaviv: don't invoke OOM killer from dump code

On Fri, Dec 02, 2016 at 11:44:54AM +0100, Lucas Stach wrote: > The dumper is only a debugging aid so we don't want to invoke the OOM > killer if buffer for the potentially large GPU state can't be vmalloced. > > Signed-off-by: Lucas Stach Acked-by: Russell King

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

On Fri, Dec 02, 2016 at 05:51:18PM +0200, Laurent Pinchart wrote: > Hi Russell, > > On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote: > > On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote: > > > From: Kieran Bingham <kieran.bingham+

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote: > DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that. > > Do you know why this function needs to write to the HDMI_FC_INVIDCONF > register four times in the normal case, and once only for IMX6DL ? (I don't have much

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote: > From: Kieran Bingham > > The dw-hdmi driver declares a dev_type to distinguish platform specific > changes. Replace this with a quirk field, so that the platform can > specify the

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote: > From: Kieran Bingham > > The current code hard codes the call of hdmi_phy_configure() to be 8bpp > and provides extraneous error checking to verify that this hardcoded > value is

TDA998x crash on HDLCD probe failure

On Thu, Nov 24, 2016 at 01:18:39PM +, Robin Murphy wrote: > Hi Liviu, Russell, > > I'd been meaning to try digging into this if it hadn't gone away since I > first noticed it, but I don't really have the time and it still happens > with 4.9-rc and today's -next. Representative splat below,

[PATCH] drm/atomic: Unconfuse the old_state mess in commmit_tail

On Tue, Nov 22, 2016 at 08:51:11AM +0900, Gustavo Padovan wrote: > 2016-11-21 Daniel Vetter : > > /** > > * drm_atomic_helper_commit_tail - commit atomic update to hardware > > - * @state: new modeset state to be committed > > + * @old_state: atomic state object with old state structures > >

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 06:23:24PM +, Liviu Dudau wrote: > On Mon, Nov 21, 2016 at 05:56:02PM +0000, Russell King - ARM Linux wrote: > > For me, the image shift was 100% reproducable. With the above patch > > and a call to drm_crtc_vblank_on() in the enable path, it seem

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 05:56:02PM +, Russell King - ARM Linux wrote: > For me, the image shift was 100% reproducable. With the above patch > and a call to drm_crtc_vblank_on() in the enable path, it seems to > behave correctly - I can alternately switch between 1920x1080 and &g

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 05:32:32PM +, Liviu Dudau wrote: > On Mon, Nov 21, 2016 at 02:03:49PM +0000, Russell King - ARM Linux wrote: > > On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote: > > > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wro

[PATCH] drm/atomic: Unconfuse the old_state mess in commmit_tail

On Mon, Nov 21, 2016 at 05:35:20PM +0100, Daniel Vetter wrote: > I totally butcherd the job on typing the kernel-doc for these, and no > one realized. Noticed by Russell. Maarten has a more complete approach > to this confusion, by making it more explicit what the new/old state > is, instead of

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 02:30:53PM +, Russell King - ARM Linux wrote: > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote: > > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote: > > > That is mostly due to the check in hdlcd_crtc_disabl

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 01:24:19PM +, Russell King - ARM Linux wrote: > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote: > > That is mostly due to the check in hdlcd_crtc_disable() which I should > > remove, I've added it because I was getting a ->disable() hook c

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 01:50:31PM +, Liviu Dudau wrote: > On Mon, Nov 21, 2016 at 01:24:19PM +0000, Russell King - ARM Linux wrote: > > On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote: > > > That is mostly due to the check in hdlcd_crtc_disable() which I should

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 12:56:53PM +, Liviu Dudau wrote: > That is mostly due to the check in hdlcd_crtc_disable() which I should > remove, I've added it because I was getting a ->disable() hook call > before any ->enable() was called at startup time. I need to revisit > this as I remember

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 11:32:12AM +, Liviu Dudau wrote: > On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote: > > I first noticed it when booting with the buggy I2C EDID reading, so > > DRM wasn't seeing a valid EDID. Then when Xorg started up and s

[BUG] hdlcd gets confused about base address

On Mon, Nov 21, 2016 at 11:06:04AM +, Liviu Dudau wrote: > On Fri, Nov 18, 2016 at 11:37:33PM +0000, Russell King - ARM Linux wrote: > > Hi, > > Hi Russell, > > > > > While testing HDMI with Xorg on the Juno board, I find that when Xorg > > starts up o

[BUG] hdlcd gets confused about base address

Hi, While testing HDMI with Xorg on the Juno board, I find that when Xorg starts up or shuts down, the display is shifted significantly to the right and wrapped in the active region. (No sync bars are visible.) The timings are correct, it behaves as if the start address has been shifted many

[PATCH RFC 01/12] drm/i2c: tda998x: avoid race in tda998x_encoder_mode_set()

On Tue, Nov 08, 2016 at 12:25:00PM +, Russell King wrote: > As priv->audio_params can now be changed at run time, we need to be more > careful about how we deal with a mode set. We must take the audio lock > while checking if there's a valid audio configuration. > > However, it's slightly

[PATCH] drm/i2c/tda998x: fix spelling mistake

On Mon, Nov 14, 2016 at 10:46:43PM +, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake "configutation" to "configuration" > in dev_err message > > Signed-off-by: Colin Ian King Applied, thanks. -- RMK's Patch system:

[PATCH 1/2] drm/i2c: tda998x: allow interrupt to be shared

On Thu, Nov 17, 2016 at 12:24:57PM +, Brian Starkey wrote: > I tested these two and the power-down one on mali-dp and hdlcd. The > output, hotplugging and EDID continued to work; so you can have my > tested-by and reviewed-by for all 3. Thanks! -- RMK's Patch system:

[PATCH 0/7] Armada DRM updates for 4.10

This series is for review only - I'll be submitting a pull request to David in due course. These patches are based on the TDA998x MALI patch, removing the drm_connector_register() call, and: * Add tracing support for overlay usage, so it's possible to use tracing to monitor how well we hit the

[GIT PULL] Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

- ARM Linux wrote: > I guess Dave must have missed this as I can't see it in drm-next, so > I'm resending the pull request. > > On Tue, Nov 08, 2016 at 10:59:43AM +0000, Russell King - ARM Linux wrote: > > On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote: > >

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

On Wed, Nov 16, 2016 at 12:23:50AM +0100, Pierre-Hugues Husson wrote: > Hi, > > > 2016-11-14 16:22 GMT+01:00 Hans Verkuil : > > From: Russell King > > > > We don't need the CEC engine register definitions, so let's remove them. > > > > Signed-off-by: Russell King

[GIT PULL] Re: [PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

I guess Dave must have missed this as I can't see it in drm-next, so I'm resending the pull request. On Tue, Nov 08, 2016 at 10:59:43AM +, Russell King - ARM Linux wrote: > On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote: > > Hm, I entirely missed that part of the

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

I can't comment on these, you've not included me in patch 1 nor the covering message. On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote: > From: Russell King > > We don't need the CEC engine register definitions, so let's remove them. > >

[PATCH RFC 00/12] tda998x updates

On Fri, Nov 11, 2016 at 05:10:09PM +0200, Jyri Sarha wrote: > On 11/08/16 14:24, Russell King - ARM Linux wrote: > > As no one responded to the previous round, I'm not spending soo much > > time writing up a description of these changes again. It's also been > > quite

[PATCH RFC 00/12] tda998x updates

On Wed, Nov 09, 2016 at 11:45:05AM +, Jon Medhurst (Tixy) wrote: > On Tue, 2016-11-08 at 18:24 +0000, Russell King - ARM Linux wrote: > > On Tue, Nov 08, 2016 at 05:20:36PM +, Jon Medhurst (Tixy) wrote: > > > On Tue, 2016-11-08 at 13:34 +0000, Russell King - ARM Linux wro

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 05:20:36PM +, Jon Medhurst (Tixy) wrote: > On Tue, 2016-11-08 at 13:34 +0000, Russell King - ARM Linux wrote: > > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > > > Unfortunately, my drm-tda998x-devel branch is sl

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 03:25:45PM +, Robin Murphy wrote: > On 08/11/16 13:34, Russell King - ARM Linux wrote: > > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > >> Unfortunately, my drm-tda998x-devel branch is slightly out of date with >

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > Unfortunately, my drm-tda998x-devel branch is slightly out of date with > these patches it's the original set of 10 patches. I've not pushed > these ones out to that branch yet, as I've three additional patches

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 01:19:51PM +, Robin Murphy wrote: > Hi Russell, > > On 08/11/16 12:24, Russell King - ARM Linux wrote: > > As no one responded to the previous round, I'm not spending soo much > > time writing up a description of these changes again. It's also

[PATCH RFC 00/12] tda998x updates

As no one responded to the previous round, I'm not spending soo much time writing up a description of these changes again. It's also been quite a long time, so I've forgotten all the details of the changes, so I'll do my best. Changes from the previous series include: - reorder the initial three

[PATCH v4] drm: bridge: add DesignWare HDMI I2S audio support

On Tue, Nov 08, 2016 at 01:00:57AM +, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > Current dw-hdmi is supporting sound via AHB bus, but it has > I2S audio feature too. This patch adds I2S audio support to dw-hdmi. > This HDMI I2S is supported by using ALSA SoC common HDMI

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote: > Hm, I entirely missed that part of the troubles. Anyway, if you all agree > on a patch I certainly won't block it, feel free to merge through suitable > trees (or I can smash it into drm-misc if that's wanted). I think those who are

[PATCH 0/5] drm/sun4i: Handle TV overscan

On Mon, Nov 07, 2016 at 04:09:09PM +0100, Maxime Ripard wrote: > Hi Russell, > > On Thu, Nov 03, 2016 at 09:54:45AM +, Russell King - ARM Linux wrote: > > > Yes. And that is an XBMC only solution, that doesn't work with the > > > fbdev emulation and is probably doin

[PATCH v3] drm: bridge: add DesignWare HDMI I2S audio support

On Mon, Nov 07, 2016 at 03:50:00AM +, Kuninori Morimoto wrote: > > Hi Russell > > > > + platform = platform_device_register_full(); > > > + if (IS_ERR_OR_NULL(platform)) > > > + return PTR_ERR(platform); > > > > This is wrong. If platform is NULL, PTR_ERR() will return zero, which

[PATCH 0/5] drm/sun4i: Handle TV overscan

On Thu, Nov 03, 2016 at 10:01:06AM +0100, Maxime Ripard wrote: > Hi Russell, > > On Mon, Oct 31, 2016 at 08:42:34AM +, Russell King - ARM Linux wrote: > > On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote: > > > The first one is that this oversca

[PATCH] drm/bridge: dw-hdmi: Set sink_is_hdmi and sink_has_audio in mode_set

On Wed, Nov 02, 2016 at 09:47:50PM +, James Le Cuirot wrote: > On Mon, 31 Oct 2016 16:37:36 + > Russell King - ARM Linux wrote: > > We also need to apply this to the ELD as well - and several other > > drivers are similarly buggy, and are going to need similar

<    1   2   3   4   5   6   7   8   9   10   >