On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> - also calculate CTS
This is wrong...
> + /*
> + * HDMI 1.3a, 7.2.2 CTS parameter:
> + * (avg cts) = (fTMDS * N) / (128 * fS)
> + */
> + cts = n * mode->clock / p->audio_sample_rate;
> + cts *=
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
> + hs_pix_e = hs_pix_s + mode->hsync_end -
On Tue, Aug 06, 2013 at 12:20:15AM +0200, Sebastian Hesselbarth wrote:
> @@ -0,0 +1,23 @@
> +#ifndef __TDA998X_H__
> +#define __TDA998X_H__
> +
> +enum tda998x_audio_format {
> + AFMT_I2S,
> + AFMT_SPDIF,
> +};
> +
> +struct tda998x_encoder_params {
> + int audio_cfg;
> + int
On Tue, Aug 06, 2013 at 12:20:16AM +0200, Sebastian Hesselbarth wrote:
> This fixes the wrong sync generation and sync calculation of TDA998x
> for HS/VS-based sync detection.
>
> Signed-off-by: Sebastian Hesselbarth
The plus point with this is that interlaced modes (1080i) do work with
the
es for v2, too.
>
> I have not added Russell King's Tested-by, as I hope he will have a
> close look at what I changed after his review comments.
>
> Darren Etheridge (1):
> drm/tilcdc fixup mode to workaround sync for tda998x
>
> Russell King (5):
> drm/i2c: tda998x: fix
On Mon, Aug 19, 2013 at 09:23:17AM +1000, Dave Airlie wrote:
> On Thu, Aug 15, 2013 at 5:43 AM, Sebastian Hesselbarth
> wrote:
> > From: Russell King <rmk+kernel at arm.linux.org.uk>
> >
> > This patch adds tda998x specific parameters to allow it to be configured
On Wed, Aug 21, 2013 at 08:26:46PM +0200, Jean-Francois Moine wrote:
> On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
> > From: Russell King <rmk+kernel at arm.linux.org.uk>
> >
> > The video-input-port (VIP) is highly configurable. This prepares
On Wed, Aug 21, 2013 at 08:33:55PM +0200, Jean-Francois Moine wrote:
> On Wed Aug 14 12:43:30 PDT 2013, Sebastian Hesselbarth wrote:
> > +static void
> > +reg_write_range(struct drm_encoder *encoder, uint16_t reg, uint8_t *p, int
> > cnt)
> > +{
> > + struct i2c_client *client =
On Thu, Aug 22, 2013 at 08:53:13AM +0200, Jean-Francois Moine wrote:
> On Wed, 21 Aug 2013 23:36:05 +0100
> Russell King - ARM Linux wrote:
>
> > > AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is
> > > no need to set t
On Thu, Aug 22, 2013 at 07:33:43AM -0400, Rob Clark wrote:
> On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine
> wrote:
> > On Wed, 21 Aug 2013 23:36:05 +0100
> > Russell King - ARM Linux wrote:
> >
> >> > AFAIK, the TI boards have no "pin-swapped&quo
On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> Add DRM flags for the LCD display clock polarity so the pixelclk-active DT
> property can be properly handled by drivers using the DRM API.
I still say that not even this should be part of the DRM mode API to
userspace. The hint that
On Tue, Dec 03, 2013 at 07:44:52PM +0800, Shawn Guo wrote:
> On Mon, Dec 02, 2013 at 04:39:26PM +0100, Marek Vasut wrote:
> > Add DRM flags for the LCD display clock polarity so the pixelclk-active DT
> > property can be properly handled by drivers using the DRM API.
> >
> > Signed-off-by: Marek
Rob, David,
Here are four fixes for review for the Armada DRM driver.
drivers/gpu/drm/armada/armada_drm.h |1 +
drivers/gpu/drm/armada/armada_drv.c |7 ++-
drivers/gpu/drm/armada/armada_fbdev.c | 20 +++-
drivers/gpu/drm/armada/armada_gem.c |7 ---
4
On Thu, Feb 28, 2013 at 11:03:57PM +0100, Sylwester Nawrocki wrote:
> Please just use IS_ERR(), let's stop this IS_ERR_OR_NULL() insanity.
Yes, indeed.
On that topic (and off-topic for this thread, sorry) I've committed
a set of patches to remove most users of IS_ERR_OR_NULL() from arch/arm.
On Wed, Jan 23, 2013 at 07:24:33AM -0600, Rob Clark wrote:
> On Wed, Jan 23, 2013 at 3:42 AM, Jean-Francois Moine
> wrote:
> > Hi Rob,
> >
> > As I wanted to re-use your nxp-tda998x driver for the Marvell Dove SoC,
> > I had a look at your IT LCD driver. Comments below.
>
> Just fyi, you can
On Thu, Jan 31, 2013 at 08:23:53AM -0600, Rob Clark wrote:
> On Wed, Jan 30, 2013 at 8:23 PM, Sebastian Hesselbarth
> wrote:
> > On 01/29/2013 06:23 PM, Rob Clark wrote:
> >>
> >> Driver for the NXP TDA998X i2c hdmi encoder slave.
> >
> >
> > Rob,
> >
> > good to see a driver for TDA998x comming!
On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote:
> On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote:
> > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux
> > wrote:
> > > | Default Colorimetry
> > > |
> > > | ...
&g
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
>>> wrote:
>
- the phandles to the clocks does not
On Sat, Jul 13, 2013 at 08:25:15AM -0600, Daniel Drake wrote:
> I guess the IRE falls into the same category as the DCON - we won't
> implement it for now, but knowing where it might fit in is useful.
I don't see much need at the moment for IRE. IRE isn't going to be
useful for general graphics
On Sat, Jul 13, 2013 at 07:44:58PM +0200, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> When I designed the clk API, I arranged for things like clk_get() to
>> take a reference on the module if the clock was supplied by a module.
>
On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
> they're working on v4 with clock object reference counting. Presumably we
> need both clk_get() to be taking reference on the module and reference
>
On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
&
On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
> On Thu, Jul 25, 2013 at 1:17 PM, wrote:
> > Known issues:
> > * It uses KDS. We intend to switch to whatever implicit per-buffer
> >synchronisation mechanism gets merged, once something is merged.
> > * It abuses flags parameter
On Wed, Jul 31, 2013 at 10:21:20PM +0200, Sebastian Hesselbarth wrote:
> Should we prepare a new patch set comprising the following patches?
>
> Russell King:
> drm/i2c: nxp-tda998x: fix EDID reading on TDA19988 devices
> drm/i2c: nxp-tda998x: ensure VIP output mux is properly set
This is version 2 of my DRM driver. Changes since the previous version:
1. It's now called Armada not Dove, because the "LCD controllers" aka CRTCs
are found in Armada 16x as well as Armada 510 Dove. The Armada 16x is
preliminary work.
2. Cursor support is now a separate patch. I've
On Sun, Jun 09, 2013 at 08:06:12PM +0100, Russell King - ARM Linux wrote:
> This is version 2 of my DRM driver. Changes since the previous version:
Okay, patch 1 got removed from this set, so some people won't see it
(it shouldn't have been sent). Patch 2 is in moderation, which is
proba
On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> I'd like to see all the ARM based drivers based on CMA if it can meet
> their requirements
> and using close to standard GEM/dma-buf interfaces. Otherwise it'll be
> come an unmaintainable
> nightmare for everyone, but mostly for me.
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> <rmk+kernel at arm.linux.org.uk> wrote:
> > This patch adds support for the pair of LCD controllers on the Marvell
> > Armada 510 SoCs. This driver supports:
&
On Mon, Jun 10, 2013 at 03:59:34PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> wrote:
> > ARMADA_GEM_CREATE_PHYS is to deal with creating a gem buffer object for
> > a chunk of physical memory allocated by other means (e
On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream. I'd hate
> for it to have to live completely out of tree. I can think of a
> couple possibilities.
>
> 1) the best would be, if there was some way for the drm driver to know
>
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> <rmk+kernel at arm.linux.org.uk> wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc
On Mon, Jun 10, 2013 at 01:10:18PM +0200, Sebastian Hesselbarth wrote:
> On 06/09/13 21:29, Russell King wrote:
>> +/*
>> + * The spec is unclear about the polarities of the syncs.
>> + * We assume their non-inverted state is active high.
>> + */
>
On Tue, Jun 11, 2013 at 12:01:59AM +0200, Daniel Vetter wrote:
> On Mon, Jun 10, 2013 at 9:59 PM, Rob Clark wrote:
> > On Mon, Jun 10, 2013 at 1:06 PM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> >>
Okay, so the previous set didn't contain all the updates I wanted.
That's partly because of the timespan between making those changes
and re-posting the RFC.
This time, the "Add Armada DRM driver" commit contains all the
updates it should've had from last time!
However, I'm posting a slightly
On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> I guess in the short term, the best I can think is keep those phys
> ioctls as a small patch on top of the upstream driver. It is ok to
> leave place-holder ioctl #'s in the upstream driver so that the ioctl
> #'s don't shift when you
On Mon, Jun 10, 2013 at 07:17:22PM -0400, Rob Clark wrote:
> On Mon, Jun 10, 2013 at 6:56 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jun 10, 2013 at 06:49:06PM -0400, Rob Clark wrote:
> >> I guess in the short term, the best I can think is keep those phys
> &g
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
&g
On Tue, Jun 11, 2013 at 09:48:57AM +1000, Dave Airlie wrote:
> On Tue, Jun 11, 2013 at 9:36 AM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 11, 2013 at 09:24:16AM +1000, Dave Airlie wrote:
> >> I'd like to see all the ARM based drivers based on CMA if it can meet
&g
On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> wrote:
> > And having thought about this driver, DRM some more, I'm now of the
> > opinion that DRM is not suitable for driving hardware where the GPU
On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM Linux
> > wrote:
> > > And having thought about this driver, DRM some more, I'm
On Wed, Jun 12, 2013 at 06:05:12PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 05:49:14PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 12, 2013 at 09:56:22AM -0400, Rob Clark wrote:
> > > On Wed, Jun 12, 2013 at 9:48 AM, Russell King - ARM
And here's another one - look carefully at this path:
buf = dev->driver->gem_prime_export(dev, obj, flags);
if (IS_ERR(buf)) {
/* normally the created dma-buf takes ownership of the
ref,
* but if that fails then
And another issue...
What is drm_crtc_helper_set_mode() passed as the fb argument? Is it
the old fb, or the new fb?
bool drm_crtc_helper_set_mode(struct drm_crtc *crtc,
struct drm_display_mode *mode,
int x, int y,
On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> The deeper I look, the more bugs there seem to be in this DRM stuff,
> and I'm continuing to look because I'm chasing a framebuffer refcount
> bug.
So, this refcount bug - I think I've just found it. This is
On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > The deeper I look, the more bugs there seem to be in this DRM stuff,
> > and I'm continuing to look because I'm chasing a frame
On Thu, Jun 13, 2013 at 05:28:08PM +0900, Inki Dae wrote:
> This patch adds a buffer synchronization framework based on DMA BUF[1]
> and reservation[2] to use dma-buf resource, and based on ww-mutexes[3]
> for lock mechanism.
>
> The purpose of this framework is not only to couple cache
On Fri, Jun 14, 2013 at 03:53:41PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 12:50:16PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jun 13, 2013 at 12:19:03PM +0100, Russell King - ARM Linux wrote:
> > > The deeper I look, the more bugs there seem to be
On Fri, Jun 14, 2013 at 04:23:22PM +0200, Daniel Vetter wrote:
> On Thu, Jun 13, 2013 at 3:03 PM, Russell King - ARM Linux
> wrote:
> > There's a bigger issue here - if it's possible for
> > drm_crtc_helper_set_config()
> > to be called with set->fb set but set-&g
On Fri, Jun 14, 2013 at 09:50:22PM +0200, Daniel Vetter wrote:
> On Fri, Jun 14, 2013 at 4:42 PM, Russell King - ARM Linux
> wrote:
> > If you're happy with the patch I supplied, that's probably the minimal fix
> > which should go to stable kernels (I'm using 3.9 here)
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> It's just to implement a thin sync framework coupling cache operation. This
> approach is based on dma-buf for more generic implementation against android
> sync driver or KDS.
>
> The described steps may be summarized as:
> lock
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> 2013/6/17 Russell King - ARM Linux
> Exactly right. But that is not definitely my point. Could you please see
> the below simple example?:
> (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> sp
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple e
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> It seems like that all pages of the scatterlist should be mapped with
> DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> function call), and the pages should be unmapped from DMA again every
> time DMA operation
On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> So I'd like to ask for other DRM maintainers. How do you think about it? it
> seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
> Rob) and GEM CMA helper also have same issue Russell pointed out. I think
> not only
On Tue, Jun 18, 2013 at 06:04:44PM +0900, Inki Dae wrote:
>
>
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> > Sent: Tuesday, June 18, 2013 5:43 PM
> > To: Inki Dae
> > Cc: 'Maarten Lankhorst'; 'linux-f
On Tue, Jun 18, 2013 at 09:00:16AM +0200, Daniel Vetter wrote:
> On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> > What we need is something along the lines of:
> > (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> > or
> &g
On Thu, Jun 20, 2013 at 12:10:04AM +0900, Inki Dae wrote:
> On the other hand, the below shows how we could enhance the conventional
> way with my approach (just example):
>
> CPU -> DMA,
> ioctl(qbuf command) ioctl(streamon)
> |
i-devel-bounces+inki.dae=samsung.com at lists.freedesktop.org]
> > > On
> > > Behalf Of Russell King - ARM Linux
> > > Sent: Thursday, June 20, 2013 3:29 AM
> > > To: Inki Dae
> > > Cc: linux-fbdev; DRI mailing list; Kyungmin Park; m
On Thu, Jun 20, 2013 at 09:46:03PM +0200, Sebastian Hesselbarth wrote:
> + ref_pix = 3 + mode->hsync_start - mode->hdisplay;
> + de_pix_s = mode->htotal - mode->hdisplay;
> + de_pix_e = de_pix_s + mode->hdisplay;
> + hs_pix_s = mode->hsync_start - mode->hdisplay;
>
On Wed, Jun 26, 2013 at 06:42:50PM +0200, Jean-Francois Moine wrote:
> Do you know that there are 2 drm drivers for the Cubox? I posted mine
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> before Russell, but I got no return about it yet.
>
> As it uses the CMA
On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> Hi Russell,
>
> Thanks a lot for writing the Armada DRM driver.
>
> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
> aka PXA2128). After a bit of fighting, I have it running. Could you share your
> X
On Fri, Jun 28, 2013 at 01:54:21PM -0600, Daniel Drake wrote:
> On Wed, Jun 26, 2013 at 10:42 AM, Jean-Francois Moine
> wrote:
> > Do you know that there are 2 drm drivers for the Cubox? I posted mine
> > (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168732.html)
> > before
On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> Hi Russell,
>
> Thanks for pointing me to the most recent version of your driver.
> Can you comment on the below patch for improved clock handling?
Sure... lets add some background info first: the big problem here is the
completely
On Fri, Jun 28, 2013 at 10:18:48PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 28, 2013 at 04:11:32PM -0400, Daniel Drake wrote:
> > +int armada_drm_find_best_clock(struct armada_private *priv, long
> > needed_rate)
> > +{
> > + int i;
> > +
>
On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (MMP3
> aka PXA2128). After a bit of fighting, I have it running. Could you share your
> X driver, or your methodology for testing hardware cursors? I'd like to test
On Fri, Jun 28, 2013 at 03:36:37PM -0600, Daniel Drake wrote:
> On Fri, Jun 28, 2013 at 3:27 PM, Russell King - ARM Linux
> wrote:
> > On Tue, Jun 25, 2013 at 04:47:26PM -0400, Daniel Drake wrote:
> >> I have tested it on OLPC XO-1.75 (MMP2 aka Armada610) and OLPC XO-4 (
On Sat, Jun 29, 2013 at 05:58:26PM +0200, Sebastian Hesselbarth wrote:
> On 06/29/2013 05:06 PM, Daniel Drake wrote:
>> On Fri, Jun 28, 2013 at 3:18 PM, Russell King - ARM Linux
>> wrote:
>>> Sure... lets add some background info first: the big problem here is the
On Sat, Jun 29, 2013 at 09:06:47AM -0600, Daniel Drake wrote:
> MMP2 (Armada 610) and MMP3 (PXA2128, no Armada name) is even a bit
> more complex than that.
> On MMP2 the selectable clocks are written in bits 31:30 and are:
> 0 - AXI, 1 - LCD1, 2 - LCD2, 3 - HDMI
>
> On MMP3 the selectable clocks
Quite a number of things has changed since the last revision in the
core code - notably the move to use drm_plane for overlay, and the
limited and restricted use of dma_buf so that gem objects can be
passed to the GALCORE code and libbmm contiguous video frames can
be imported into DRM.
As I
On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > +static uint32_t armada_drm_crtc_calculate_csc(struct armada_crtc *dcrtc)
> > +{
> > + struct drm_display_mode *adj = >crtc.mode;
On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > + mutex_lock(>struct_mutex);
> > + free = drm_mm_search_free(>linear, size, align, 0);
> > + if (free)
On Sun, Jun 30, 2013 at 02:04:56PM +0100, Russell King - ARM Linux wrote:
> On Sun, Jun 30, 2013 at 02:37:41PM +0200, Daniel Vetter wrote:
> > On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote:
> > > + mutex_lock(>struct_mutex);
> > > + fre
Right, so, incrementally, the changes are (this may not entirely apply
to the version I've posted because I have several patches on top of
that.)
I've also added locking to the calls to drm_mm_dump_table() as otherwise
these walk those lists without holding any locks what so ever, which
could
On Mon, Jul 01, 2013 at 10:01:30AM +1000, Dave Airlie wrote:
> OMG I'm working in a subsystem where stuff is being developed, with only
> a few resources! I know my full time job isn't maintaining a 500,000
> line subsystem,
> and the sub maintainers and developers do a great job refactoring
>
On Tue, Aug 25, 2015 at 11:12:48AM +0200, Thierry Reding wrote:
> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
> > It goes beyond bindings IMO. The use of the component framework or not
> > has been at the whim of driver writers as well. It is either used or
> > private APIs are
On Tue, Aug 25, 2015 at 12:40:01PM +0200, Thierry Reding wrote:
> On Tue, Aug 25, 2015 at 10:29:39AM +0100, Russell King - ARM Linux wrote:
> > Now, what happens when some other DRM driver wants to use the tda998x
> > driver, and its bindings are not compatible with the co
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(>struct_mutex);
>
On Thu, Dec 03, 2015 at 10:40:45AM +, Liviu Dudau wrote:
> This series depends on Sudeep Holla's SCPI driver (now in mainline) and on
> the tda998x patches that have been queued on Russell's patch system here [1].
Now merged into my tree.
Can I ask a fairly obvious question...
>
On Fri, Dec 04, 2015 at 10:29:56AM -0600, Rob Herring wrote:
> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > +Vivante GPU core devices
> > +
> > +
> > +Required properties:
> > +- compatible: Should be "vivante,gc"
>
> This should at least have the specific
On Fri, Dec 04, 2015 at 05:41:45PM +0100, Lucas Stach wrote:
> Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > > +gpu-subsystem {
> > > + compatible = "fsl,imx-gpu-subsystem";
> > > + cores = <_2d>, <_3d>;
> > > +};
On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> Signed-off-by: Lucas Stach
Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
Although, I would like to be copied on patches, I don't think we
have a way to encode that information in MAINTAINERS.
> ---
>
On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
> wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach
> >
> > Acked-by: Russell Kin
On Fri, Dec 04, 2015 at 06:26:38PM +0100, Marc Kleine-Budde wrote:
> On 12/04/2015 06:07 PM, Russell King - ARM Linux wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach
> >
> > Acked-by: Russell King &
On Fri, Dec 04, 2015 at 11:33:22AM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach
> wrote:
> > I'm aware of that, but I don't see much value in kicking this discussion
> > around for every DRM driver submission. This is the binding that has
> > emerged from a lengthy
On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach
> wrote:
> > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> >> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach
> >> wrote:
> >> > Am Freitag, den 04.12.2015, 10:29 -0600
On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
> wrote:
> > Moreover, DRI3 is not yet available for Gallium, so if we're talking
> > about Xorg, then functional DRI2 is a requirement, and that _needs_
&g
On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote:
> Given that I think the current etnaviv is a sound architecture. And I'm
> not saying that because drm requires everything to be smashed into one
> driver, since that's simple not the case.
There's other reasons as well, mostly from
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
> I see where you are going here and I appreciate that this discussion
> isn't a exercise in bikeshed, but based on technical facts.
It would be nice (for the sake of this discussion not getting heated)
if Rob could show that he's been
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
> I already sketched up the alternative of having the master driver scan
> the DT for matching GPU nodes at probe time and binding them together
> into a single device. But given that we end up with one master device
> anyways, do you
On Sat, Dec 05, 2015 at 04:35:11PM +0100, Daniel Vetter wrote:
> In theory dma-buf could keep track of who's flushed a buffer already, but
> there's no implementation of that yet. And for a generic one we'd need to
> violate the current dma api abstractions. So yeah, perf is going to tank
> until
On Fri, Dec 04, 2015 at 03:00:04PM +0100, Lucas Stach wrote:
> This adds the device nodes for 2D, 3D and VG GPU cores.
>
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Lucas Stach
This should have been copied to the arm-soc people, as we'
Given the lack of interest in these patches, I've put these into my
"for-next" branch so that they can get some exposure in linux-next.
On Mon, Nov 23, 2015 at 04:02:11PM +0000, Russell King - ARM Linux wrote:
> Greg,
>
> These four patches update the component helper by:
>
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
On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote:
> I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if
> people would like these in now, also anything I've missed on the list.
I would definitely like to see etnaviv make it in for the next merge
window, but that depends
On Fri, Dec 11, 2015 at 05:15:40PM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 10:02:45AM +0000, Russell King - ARM Linux wrote:
> > On Fri, Dec 11, 2015 at 04:58:08PM +1000, Dave Airlie wrote:
> > > I've seen etnaviv, rockchip(?), vc4 gpu api, can I get plans for if
On Wed, Dec 23, 2015 at 06:20:33PM +0100, Jean-Francois Moine wrote:
> On Wed, 23 Dec 2015 10:05:34 +
> Liviu Dudau wrote:
>
> > > What was the reason to keep the "ports" node instead of the device?
> >
> > The function is an extract of common code sprinkled through a few DRM
> > drivers,
On Thu, Dec 24, 2015 at 09:15:28AM +0100, Jean-Francois Moine wrote:
> On Wed, 23 Dec 2015 18:59:48 +
> Russell King - ARM Linux wrote:
>
> > > > Have a look at my v2 where I've introduced two compare functions and
> > > > also
> > > > mod
On Thu, Dec 24, 2015 at 01:27:08PM +0100, Jean-Francois Moine wrote:
> On Thu, 24 Dec 2015 10:52:07 +
> Russell King - ARM Linux wrote:
> > However, when we come to the Linux implementation, things get sticky
> > because we need to select the correct platform de
On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote:
> Hi ykk,
>
> On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan wrote:
> >
> > On 01/31/2015 06:48 AM, Russell King - ARM Linux wrote:
> >>
> >>> +void hdmi_audio_clk_enable(struct dw_h
On Mon, Feb 02, 2015 at 07:32:05AM -0500, Yang Kuankuan wrote:
> On 02/02/2015 06:53 AM, Russell King - ARM Linux wrote:
> >On Mon, Feb 02, 2015 at 12:02:50PM +0800, Daniel Kurtz wrote:
> >>Hi ykk,
> >>
> >>On Sat, Jan 31, 2015 at 10:34 PM, Yang Kuankuan
&g
1301 - 1400 of 2012 matches
Mail list logo
