On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> The GPU may still keep its state when in suspend, which breaks the
> assumption that the hardware is in a clean state before the init
> routine runs. Make sure to reset the GPU when coming back from
> suspend, so this assumption is vali
On Mon, Aug 22, 2016 at 02:15:25PM +0200, Lucas Stach wrote:
> Am Montag, den 22.08.2016, 12:20 +0100 schrieb Russell King - ARM Linux:
> > On Mon, Aug 22, 2016 at 01:00:55PM +0200, Lucas Stach wrote:
> > > The GPU may still keep its state when in suspend, which breaks the
>
On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote:
> There is no linear window on MMUv2 and the FE can access the full 4GB
> address space either directly (as long as the MMU isn't configured) or
> through the MMU, once it is up.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/e
On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
> Hi Russell,
>
> On 08/12/2016 04:15 PM, Russell King wrote:
> > Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
> > implementation.
> >
> > Signed-off-by: Russell King
>
On Tue, Dec 18, 2018 at 01:53:34AM +0530, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder
> Tested-by: Heiko Stuebner
> Acked-by: Heiko Stuebner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 19
On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux
> wrote:
> > This looks like a change in behaviour.
> >
> > If user_count is zero, and offset is zero, then we pass into
> > vm_insert_ran
On Tue, Dec 18, 2018 at 06:24:29PM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 6:03 PM Russell King - ARM Linux
> wrote:
> >
> > On Tue, Dec 18, 2018 at 05:36:04PM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 3:27 PM Russell King - ARM Linux
On Wed, Dec 19, 2018 at 09:01:09AM +0530, Souptick Joarder wrote:
> On Tue, Dec 18, 2018 at 6:31 PM Russell King - ARM Linux
> wrote:
> >
> > On Tue, Dec 18, 2018 at 06:24:29PM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 6:03 PM Russell Ki
On Wed, Dec 19, 2018 at 05:16:09PM +0530, Souptick Joarder wrote:
> On Wed, Dec 19, 2018 at 3:02 PM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Dec 19, 2018 at 09:01:09AM +0530, Souptick Joarder wrote:
> > > On Tue, Dec 18, 2018 at 6:31 PM Russell Ki
Having discussed with Matthew offlist, I think we've come to the
following conclusion - there's a number of drivers that buggily
ignore vm_pgoff.
So, what I proposed is:
static int __vm_insert_range(struct vm_struct *vma, struct page *pages,
size_t num, unsigned long
On Thu, Jan 03, 2019 at 10:47:27AM +0100, Lubomir Rintel wrote:
> Hello,
>
> lately I've been trying to make the Himax HX8837 chip that drives the OLPC
> LCD display work with Armada DRM driver. I've been advised to create a
> bridge driver and not an encoder driver since the silicon is separate f
On Tue, Dec 18, 2018 at 04:37:38PM +0100, Lubomir Rintel wrote:
> This makes it possible to choose a different pixel format for the
> endpoint. Modelled after what other LCD controllers use, including
> marvell,pxa2xx-lcdc and atmel,hlcdc-display-controller and perhaps more.
>
> Signed-off-by: Lub
On Thu, Jan 03, 2019 at 02:20:00PM +0100, Lubomir Rintel wrote:
> On Thu, 2019-01-03 at 13:15 +0000, Russell King - ARM Linux wrote:
> > On Tue, Dec 18, 2018 at 04:37:38PM +0100, Lubomir Rintel wrote:
> > > This makes it possible to choose a different pixel format for the
> &
On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote:
> On Thu, Jan 03, 2019 at 01:11:47PM +0000, Russell King - ARM Linux wrote:
> > This is the long-standing problem with the conflict between bridge
> > support and component support, and I'm not sure that there is r
On Mon, Jan 07, 2019 at 10:55:15PM +0100, Daniel Vetter wrote:
> On Mon, Jan 7, 2019 at 5:13 PM Russell King - ARM Linux
> wrote:
> >
> > On Mon, Jan 07, 2019 at 11:45:32AM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 03, 2019 at 01:11:47PM +, Russell King - ARM L
On Tue, Jan 08, 2019 at 09:35:21AM +0100, Andrzej Hajda wrote:
> On 07.01.2019 22:56, Daniel Vetter wrote:
> > If you call drm_dev_register before you have all the components
> > assembled (i.e. anywhere else than in master bind) that sounds like a
> > driver bug.
>
>
> This is how components wor
On Tue, Jan 08, 2019 at 10:22:06AM +0100, Andrzej Hajda wrote:
> What part of drm core disallows it? As I remember discussions about
> drm_bridge design there were voices that they should be
> hot(un)pluggable, and they are IMO, of course if they are not active.
Even if they are not active, once t
On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> Issues with device links have nothing to do with hotplugging, they are
> generic - lifetime of the objects (drm_bridge, drm_panel) is just
> slightly different of lifetime of device links, and this is racy even if
> you do not want ho
On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda wrote:
> >> Issues with device links have nothing to do with hotplugging, they are
> >>
On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote:
> On 08.01.2019 14:21, Russell King - ARM Linux wrote:
> > On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda wrote:
> >> On 08.01.2019 12:38, Russell King - ARM Linux wrote:
> >>> On Tue, Jan 08, 201
On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda wrote:
> >
> > +CC: Rafael J. Wysocki
> >
> > On 08.01.2019 16:07, Russell King - ARM Linux wrote:
> > > On Tue, Jan 08, 2019 at 03:33:54PM +
On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter wrote:
> >
> > On Wed, Jan 9, 2019 at 10:31 AM Russell King - ARM Linux
> > wrote:
> > > On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysock
On Fri, Jan 11, 2019 at 03:36:28PM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux
> wrote:
> >
> > On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote:
> > > On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter wrote:
On Fri, Jan 11, 2019 at 10:55:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 11, 2019 at 04:41:21PM +0100, Noralf Trønnes wrote:
> > Den 17.12.2018 20.43, skrev Daniel Vetter:
> > > Doesn't do anything for atomic drivers.
> > >
> > > Signed-off-
On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> The Allwinner display engine doesn't have any kind of hardware help to deal
> with TV overscan.
I'm not sure I follow. My understanding (from reading the CEA specs)
is that TVs are expected to overscan the image, so the upper left,
On Wed, Oct 19, 2016 at 11:52:15AM +0300, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 09:16:30 Russell King - ARM Linux wrote:
> > On Wed, Oct 19, 2016 at 10:54:06AM +0300, Laurent Pinchart wrote:
> > > On Wednesday 19 Oct 2016 00:33:54 Jyri Sa
On Wed, Oct 19, 2016 at 10:54:06AM +0300, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Wednesday 19 Oct 2016 00:33:54 Jyri Sarha wrote:
> > Remove obsolete drm_connector_register() call from tda998x_bind(). All
> > connectors are registered when drm_dev_register() is cal
On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote:
> > In any case, I don't agree with converting it to a DRM bridge - that will
> > mean that we have to split the driver i
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 th
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.
>
>
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 hav
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 u
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)
> >> +{
>
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.
&g
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 drm_plane_helper_check_stat
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 a pa
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(&cec_notifiers_lock);
> + list_for_each_entry(n, &cec_notifiers, head) {
> + if (n->dev == dev) {
>
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
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
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. Ville c
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
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.
> >
> >Th
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
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 required
On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote:
> Russell King - ARM Linux writes:
>
> > 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
On Tue, Apr 11, 2017 at 02:00:21PM -0700, Eric Anholt wrote:
> Russell King - ARM Linux writes:
>
> > On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote:
> >> Russell King - ARM Linux writes:
> >>
> >> > On Mon, Apr 10, 2017 at 06:18:01PM
On Wed, Apr 12, 2017 at 09:40:38AM +0200, Linus Walleij wrote:
> On Wed, Apr 12, 2017 at 12:13 AM, Eric Anholt wrote:
> > Oh, one last thing I think we need to figure out: I'm using TIM2_CLKSEL,
> > which seems to be necessary on this platform. My understanding is that
> > this means that the pix
On Thu, Apr 20, 2017 at 10:25:01AM +0200, Arnd Bergmann wrote:
> On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen wrote:
> > I think we have a "policy" on Tegra that the DMA API will never allocate
> > using the IOMMU (Thierry can elaborate on this), which is why I wrote the
> > code with that ass
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 [#1
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) {
> > + D
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 t
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 sitti
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 p
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 l
>
> Signed-off-by: Shawn Guo
> Cc: Russell King
Acked-by: Russell King
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
__
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 9.6Mbps down 400kbps up
a
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 vi
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
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 t
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
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
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:
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
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: http://www.armlinux.org.uk/developer/patche
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: http://www.armlinux.org.uk/develo
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] +
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 what
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 pr
eo drivers to their CEC and audio
> > counterparts.
> >
> > Based on an earlier version from Russell King:
> >
> > https://patchwork.kernel.org/patch/9277043/
> >
> > The hpd_notifier is a reference counted object containing the HPD/EDID/ELD
> >
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
>
On Sun, Oct 30, 2016 at 04:38:42PM +0100, Christophe JAILLET wrote:
> 'dma_buf_map_attachment()' can not return NULL, so there is no need to
> check for it.
>
> Also add a space in order to improve layout.
Thanks, applied.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTT
On Sat, Oct 22, 2016 at 05:03:58PM +0800, Baoyou Xie wrote:
> We get 2 warnings when building kernel with W=1:
> drivers/gpu/drm/armada/armada_gem.c:215:27: warning: no previous prototype
> for 'armada_gem_alloc_object' [-Wmissing-prototypes]
> drivers/gpu/drm/armada/armada_gem.c:423:1: warning: n
On Tue, Nov 01, 2016 at 12:36:29AM +, Kuninori Morimoto wrote:
>
> Hi Russell again
>
> > > > +static struct platform_driver snd_dw_hdmi_driver = {
> > > > + .probe = snd_dw_hdmi_probe,
> > >
> > > The driver must have a .remove function, because the platform device it
> > > is bindin
On Mon, Oct 24, 2016 at 06:34:42PM +0300, Jyri Sarha wrote:
> This series depends on tda998x dropping the drm_connector_register().
> Please keep me in loop so that I know when it gets merged so that I
> know when it is safe send a pull request for these.
This suggests that you think that delaying
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 fix
On Wed, Nov 02, 2016 at 01:18:35AM +, Kuninori Morimoto wrote:
> + platform = platform_device_register_full(&pdevinfo);
> + if (IS_ERR_OR_NULL(platform))
> + return PTR_ERR(platform);
This is wrong. If platform is NULL, PTR_ERR() will return zero, which
will be interpreted
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 overscanning s
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
On Mon, Nov 07, 2016 at 03:50:00AM +, Kuninori Morimoto wrote:
>
> Hi Russell
>
> > > + platform = platform_device_register_full(&pdevinfo);
> > > + if (IS_ERR_OR_NULL(platform))
> > > + return PTR_ERR(platform);
> >
> > This is wrong. If platform is NULL, PTR_ERR() will return zero
s -
maybe adding the write/read ops to struct dw_hdmi_audio_data would be
a better thing to do, which would then allow the AHB audio to drop
the .base argument in the future.
I'm not that bothered about this though. So...
Acked-by: Russell King
Thanks.
--
RMK's Patch system: http:/
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 add
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 slightl
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
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
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&#x
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
> >
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 +, Russell King - ARM Linux wro
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
>
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.
>
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:
> > Hm, I entirely missed that p
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.
> >
> > Signe
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
Okay, I've queued this into my own for-next branch, along with the now
reviewed and tested set of tda998x patches that I sent out for comment
and testing.
I'm still hopeful that Dave's going to pull the initial patch at some
point... please?
On Tue, Nov 15, 2016 at 09:46:31AM +000
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: http://www.armlinux.org.uk/developer/patche
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: http://www.armlinux.org.
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.
>
>
repeated disable/enable cycles do not make the issue re-appear.
So, I patched the HDLCD to do this, and testing it with Xorg after
several repetitions seems to work.
Signed-off-by: Russell King
---
What I think is going on is that the FIFO or address generator for
reading data from the AXI bus is not
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
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
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
> > *
701 - 800 of 2033 matches
Mail list logo
