ries which is part of the component
helper updates (which I'm the author and maintainer of).
Then someone came up with an alternative way of some of part of it.
You can't merge the above DRM part, because that means you also need to
merge patch 1, which is core component stuff.
--
Russell
On Wed, Jun 22, 2016 at 10:23:36AM +0200, Daniel Vetter wrote:
> On Wed, Jun 22, 2016 at 09:21:11AM +0100, Russell King wrote:
> > On Wed, Jun 22, 2016 at 09:31:18AM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 22, 2016 at 3:47 AM, Stephen Rothwell
> >
be claimed, or (preferred) be claimed
when the master gets the bind call.
However, I think the i915 bits are more complex than that simple view,
so putting the component stuff inside its own devres group and closing
it at the end of try_to_bring_up_master() makes sense.
Acked-by: Russell King (Oracle)
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
RM's fbdev helpers
> > are mere wrappers around the fbdev code.
> >
> > By using fbdev helpers directly within each DRM fbdev emulation,
> > we can eventually remove DRM's wrapper functions entirely.
> >
> > v2:
> > * use FB_IO_
Hi,
I have a HP Pavilion 15" laptop that occasionally misbehaves after a
resume from suspend mode. The problem is obvious when the screen
updates e.g. after moving the mouse and the window focus changing, or
when a terminal scrolls, I get a ficker of random short horizontal
white lines over the to
On Mon, Nov 07, 2022 at 09:29:33AM +, Saarinen, Jani wrote:
> Hi Russell,
> Can you make new gitlab:
> https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs ?
Hi,
Unfortunately, I can't get any more information, and trying to get a
photo of the problem is utterly impossibl
i_infoframe_from_display_mode(&frame.avi,
> + &priv->connector, mode);
> frame.avi.quantization_range = HDMI_QUANTIZATION_RANGE_FULL;
>
> tda998x_write_if(priv, DIP_IF_FLAGS_IF2, REG_IF2_HB0, &frame);
For this,
Acked-by: Russell King
Thanks.
--
RMK
On Mon, Nov 23, 2015 at 10:32:46AM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_gem.c
> b/drivers/gpu/drm/armada/armada_gem.c
> index e3a86b96af2a..a43690ab18b9 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -46,7 +46
On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote:
> @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc
> *crtc, int x, int y)
> if (!dcrtc->variant->has_spu_adv_reg)
> return -EFAULT;
>
> - mutex_lock(&dev->struct_mutex);
> dcrt
On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
> > On 8 December 2015 at 08:49, Daniel Vetter wrote:
> > > In my quest to remove all the drm_encoder_helper_funcs->save/restore
> > > hooks I somehow missed that this dri
On Tue, Apr 26, 2016 at 07:29:44PM +0200, Daniel Vetter wrote:
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Russell King
Acked-by: Russell King
Thanks Daniel.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: cur
On Tue, Apr 26, 2016 at 07:29:49PM +0200, Daniel Vetter wrote:
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Christian Gmeiner
> Cc: Russell King
Acked-by: Russell King
Thanks Daniel.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC b
On Wed, Mar 30, 2016 at 11:51:18AM +0200, Daniel Vetter wrote:
> The fb helper private gamma_set/get functions are only required when
> the driver supports paletted 8bit mode with fbdev. Armada uses 32bpp
> unconditionally, so this is just dead code. It also doesn't do
> anything really. Let's just
On Wed, Mar 30, 2016 at 01:19:21PM +0200, Daniel Vetter wrote:
> On Wed, Mar 30, 2016 at 1:09 PM, Russell King - ARM Linux
> wrote:
> > On Wed, Mar 30, 2016 at 11:51:18AM +0200, Daniel Vetter wrote:
> >> The fb helper private gamma_set/get functions are only required when
>
In passing, while reading the Intel DDX driver code, I've noticed
that the Intel driver contains code which assumes that the master and
render devices are related by minor device number, eg:
/* Are we a render-node ourselves? */
if (is_render_node(fd, &master))
retu
On Mon, Jan 11, 2016 at 10:41:01PM +0100, Daniel Vetter wrote:
> The compiler will do this, but the void hits when grepping all the
> hooks for a subsystem wide audit are slightly annoying. So remove them
> for next time around.
I'll try to remember to queue this after -rc1, though a reminder
afte
On Tue, Jan 26, 2016 at 02:42:16PM +0100, Maarten Lankhorst wrote:
> Commit ce657b1cddf1f88c56 ("component: add support for releasing match
> data") causes a general protection fault when unloading snd-hda-intel
> with the i915 module loaded on a recent skylake machine.
I'm no good at interpreting
On Tue, Jan 26, 2016 at 03:28:34PM +0100, Maarten Lankhorst wrote:
> Something similar to a segfault. It's trying to call 0x6b6b6b6b6b which
> is POISON_FREE.
>
> mc appears to be freed already, so calling mc->release would jump to
> invalid data.
It seems that my devm foo wasn't quite up to scra
those NULL checks is safe.
In any case,
Acked-by: Russell King
Thanks.
--
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
_
On Fri, Oct 20, 2017 at 01:02:03AM +0200, Noralf Trønnes wrote:
> This driver can use drm_fb_helper_lastclose() as its .lastclose callback.
> It can also use drm_fb_helper_output_poll_changed() as its
> .output_poll_changed callback.
>
> Cc: Russell King
Acked-by: Russel
;
> Signed-off-by: Tvrtko Ursulin
Acked-by: Russell King
Thanks.
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/armada/armada_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/armad
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
> +++ b/drivers/gpu/drm/armada/armada_overlay.
On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote:
> Hi Russel
>
> On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
> >> Does that -1 ever make sense? We don't
On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote:
> Does that -1 ever make sense? We don't support mode-object-hotplugging
> so all "drm_crtc" objects are known at initialization time. I'd rather
> put a BUG() here than a silent -1. This also makes drm_crtc_mask()
> redundant.
I disa
On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote:
> On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote:
> > Both i915 and Armada had the exact same implementation. For an upcoming
> > patch, I'd like to call this function from two different source files in
> > i915, and havin
initely a good thing. For Armada:
Acked-by: Russell King
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
ht
On Tue, Jan 27, 2015 at 09:31:26AM +0100, Thomas Hellstrom wrote:
> On 01/27/2015 09:15 AM, Thierry Reding wrote:
> > Are you referring to the 4 GiB - 1 comment? The point I was trying to
> > make is not that the granularity of the IOVA space needs to be 1 byte
> > but rather that using an unsigned
.
I suspect this should go through the same tree that David's work is,
otherwise we end up with random dependencies between trees. With the
bug fix separated out:
Acked-by: Russell King
--
FTTC broadband for 0.8mile line: currently at 10
On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote:
> On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda wrote:
> > But this is an issue closely connected with component framework.
> > Component framework separates master component probe and drm device
> > initialization. As a result PM ops
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
> Add a structure for the parameters of dma_buf_attach, this makes it much
> easier
> to add new parameters later on.
I don't understand this reasoning. What are the "new parameters" that
are being proposed, and why do we need to p
> - Remove redundant "This" from kerneldoc (also in the previous patch)
> - Streamline the logic in find_component() a bit.
>
> Signed-off-by: Daniel Vetter (v1 code)
> Signed-off-by: Ramalingam C (v1 commit message)
> Cc: Ramalingam C
> Cc: Greg Kroah-Hartman
On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> > It's a dummy anyway.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Russell King
>
> I merged the entire series except this o
On Tue, Apr 21, 2020 at 03:49:19AM +0100, Al Viro wrote:
> The only source I'd been able to find speeks of >= 60 cycles
> (and possibly much more) for non-pipelined coprocessor instructions;
> the list of such does contain loads and stores to a bunch of registers.
> However, the register in q
mann
Acked-by: Russell King
Thanks.
> ---
> drivers/gpu/drm/armada/armada_drv.c | 3 ---
> drivers/gpu/drm/armada/armada_gem.c | 12 +++-
> drivers/gpu/drm/armada/armada_gem.h | 2 --
> 3 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/
On Fri, Feb 21, 2020 at 10:02:46PM +0100, Daniel Vetter wrote:
> These are the leftover drivers that didn't have a ->release hook that
> needed to be updated.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atana
35 matches
Mail list logo
