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 is
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:li...@arm.linux.org.uk]
> > Sent: Tuesday, June 18, 2013 5:43 PM
> > To: Inki Dae
> > Cc: 'Maarten Lankhorst'
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)
> |
o:dri-devel-bounces+inki.dae=samsung@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; myungjoo.ham; YoungJun
> > > Cho; linux-me
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
On Tue, Jun 25, 2013 at 11:23:21AM +0200, Daniel Vetter wrote:
> Just a quick question on your assertion that we need all four
> functions: Since we already have begin/end_cpu_access functions
> (intention here was to allow the dma_buf exporter to ensure the memory
> is pinned, e.g. for swapable ge
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 driver
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.h
&priv->linear);
> err_buf:
> @@ -193,6 +210,7 @@ static int armada_drm_unload(struct drm_device *dev)
> drm_irq_uninstall(dev);
> drm_mode_config_cleanup(dev);
> drm_mm_takedown(&priv->linear);
> + release_clocks(priv);
> dev->dev_private = NUL
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 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 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
hough I have the 16x specs, I don't have hardware for it, and I
haven't spent that long digging in to it.
> So, could we just specify per-CRTC clock preference in platform data,
> DT, or something like that? e.g. we could just specify which SCLK bits
> to set and clear, and whi
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 thoug
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 = &dcrtc->crtc.mode;
> > + uint32_t val = 0;
> >
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(&dev->struct_mutex);
> > + free = drm_mm_search_free(&priv->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(&dev->struct_mutex);
> > > +
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 mean
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
> wher
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
> > > |
> > > | ...
> &
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 tel
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 r
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
> coun
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
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 o
On Tue, Nov 30, 2010 at 04:21:47PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 November 2010, Linus Walleij wrote:
> > 2010/11/26 Arnd Bergmann :
> >
> > > * When you say that the devices are static, I hope you do not mean
> > > static in the C language sense. We used to allow devices to be
> > >
On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> On Tue, Nov 30, 2010 at 06:40:49PM +, Russell King - ARM Linux wrote:
> > There's lots of static devices, not only platform devices, in the ARM
> > tree. It's going to be a hell of a lot of work to fix this al
On Tue, Nov 30, 2010 at 03:05:33PM -0800, Greg KH wrote:
> On Tue, Nov 30, 2010 at 10:05:50PM +, Russell King - ARM Linux wrote:
> > On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> > > On Tue, Nov 30, 2010 at 06:40:49PM +, Russell King - ARM Linux wrote:
>
On Wed, Dec 01, 2010 at 01:53:39PM +0100, Peter Stuge wrote:
> Russell King - ARM Linux wrote:
> > I feel it would be better to allow the current situation to continue.
>
> I think this misses the point, and is somewhat redundant; I think
> everyone knows that it is easie
On Tue, Aug 07, 2012 at 06:04:30PM +0530, Leela Krishna Amudala wrote:
> arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159
>
> drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
> drivers/video/s3c-fb.c |2 +-
> .../plat/reg
At the moment, there is an inconsistency in the way modes are named.
Modes with timings parsed from the EDID information will call
drm_mode_set_name(), which will name the mode using this form:
x
eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive
mode.
However, timings
Hi,
While looking at the kernel DRM code, I've noticed that in many places
we kmalloc() memory to store the raw EDID information, whether it be
from a DDC adapter, or loaded from firmware.
Nowhere can I find where this memory is freed. It seems in several
places that we assign it into connector-
While reading through the Intel driver code, I spotted this in
I830SetPortAttributeOverlay:
} else if (attribute == xvPipe) {
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
if ((value < -1) || (value > xf86_config->num_crtc))
at lists.ozlabs.org
> CC: devicetree-discuss at lists.ozlabs.org
> CC: Richard Henderson
> CC: Ivan Kokshaysky
> CC: Matt Turner
> CC: linux-alpha at vger.kernel.org
> CC: Thomas Gleixner
> CC: Ingo Molnar
> CC: "H. Peter Anvin"
> CC: x86 at kernel.org
>
On Tue, Nov 08, 2011 at 06:42:27PM +0100, Daniel Vetter wrote:
> Actually I think the importer should get a _mapped_ scatterlist when it
> calls get_scatterlist. The simple reason is that for strange stuff like
> memory remapped into e.g. omaps TILER doesn't have any sensible notion of
> an address
On Tue, Nov 30, 2010 at 04:21:47PM +0100, Arnd Bergmann wrote:
> On Tuesday 30 November 2010, Linus Walleij wrote:
> > 2010/11/26 Arnd Bergmann :
> >
> > > * When you say that the devices are static, I hope you do not mean
> > > static in the C language sense. We used to allow devices to be
> > >
On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> On Tue, Nov 30, 2010 at 06:40:49PM +, Russell King - ARM Linux wrote:
> > There's lots of static devices, not only platform devices, in the ARM
> > tree. It's going to be a hell of a lot of work to fix this al
On Tue, Nov 30, 2010 at 03:05:33PM -0800, Greg KH wrote:
> On Tue, Nov 30, 2010 at 10:05:50PM +, Russell King - ARM Linux wrote:
> > On Tue, Nov 30, 2010 at 10:48:34AM -0800, Greg KH wrote:
> > > On Tue, Nov 30, 2010 at 06:40:49PM +, Russell King - ARM Linux wrote:
>
On Sat, Oct 05, 2013 at 08:45:50PM -0400, Rob Clark wrote:
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
>
> v1: original
> v2: pass correct size to check_uaccess, and better handling of narrowing
>
On Sun, Oct 06, 2013 at 10:09:34AM -0400, Rob Clark wrote:
> On Sun, Oct 6, 2013 at 4:53 AM, Russell King - ARM Linux
> wrote:
> > On Sat, Oct 05, 2013 at 08:45:50PM -0400, Rob Clark wrote:
> >> A new atomic modeset/pageflip ioctl being developed in DRM requires
> >>
The Armada DRM drivers again, along with the TDA998x HDMI output support,
and an illustration to show how to add Armada 610 support (and others.)
Rob has looked at this a couple of times since its last posting, and
has provided additional useful feedback which has been incorporated.
I believe all
On Mon, Oct 07, 2013 at 11:01:41AM +0200, Jean-Francois Moine wrote:
> On Sun, 06 Oct 2013 23:09:56 +0100
> Russell King wrote:
>
> > This patch adds ARGB hardware cursor support to the DRM driver for the
> > Marvell Armada SoCs. ARGB cursors are supported at either 32x64 or
> > 64x32 resolution
On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
> On Sun, 06 Oct 2013 23:11:56 +0100
> Russell King wrote:
>
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/armada/Kconfig |9 +++
> > drivers/gpu/drm/armada/armada_drv.c | 42
> > +
On Mon, Oct 07, 2013 at 12:09:22PM +0200, Jean-Francois Moine wrote:
> On Mon, 7 Oct 2013 10:40:08 +0100
> Russell King - ARM Linux wrote:
>
> > > > This patch adds ARGB hardware cursor support to the DRM driver for the
> > > > Marvell Armada SoCs. ARGB cursors
On Mon, Oct 07, 2013 at 12:48:20PM +0200, Jean-Francois Moine wrote:
> On Mon, 7 Oct 2013 10:44:04 +0100
> Russell King - ARM Linux wrote:
>
> > On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
> [snip]
> > > It seems we are going backwards:
On Mon, Oct 07, 2013 at 02:03:27PM +0200, Jean-Francois Moine wrote:
> On Mon, 7 Oct 2013 12:09:02 +0100
> Russell King - ARM Linux wrote:
>
> > > Here is a small story about i2s/spdif: once, I set the tda998x to use
> > > the spdif input, and at this time,
On Mon, Oct 07, 2013 at 03:29:15PM +0300, Siarhei Siamashka wrote:
> On Mon, 7 Oct 2013 11:32:50 +0100
> Russell King - ARM Linux wrote:
> > However, what you're suggesting is dangerous. What do you do when you're
> > presented with a cursor which is 64x64 ? Do you:
e are kernel bugs or security issues. Instead, I will just upgrade
> my system from my distributor (Debian), and, in the packages, there
> will be a generic mvebu kernel as there is already one for Marvell
> Armada 370/xp, Freescale iMX5x/iMX6 (linux-image-3.10-3-armmp).
> But, for that
On Mon, Oct 07, 2013 at 11:47:55PM +0200, Sebastian Hesselbarth wrote:
> On 10/07/2013 12:07 AM, Russell King - ARM Linux wrote:
>> The Armada DRM drivers again, along with the TDA998x HDMI output support,
>> and an illustration to show how to add Armada 610 support (and others.
On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
> On Sun, Oct 6, 2013 at 6:08 PM, Russell King
> wrote:
> > + /*
> > +* If we have an overlay plane associated with this CRTC, disable
> > +* it before the modeset to avoid its coordinates being outside
> > +*
On Thu, Oct 10, 2013 at 06:23:26PM -0400, Rob Clark wrote:
> On Thu, Oct 10, 2013 at 5:59 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
> >> probably this thread is applicable here too?
> >>
> >&
On Fri, Oct 11, 2013 at 03:05:56PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This will make the next patch to change how this works a lot cleaner.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 32 +---
> 1 file changed, 17 insert
On Wed, Dec 01, 2010 at 01:53:39PM +0100, Peter Stuge wrote:
> Russell King - ARM Linux wrote:
> > I feel it would be better to allow the current situation to continue.
>
> I think this misses the point, and is somewhat redundant; I think
> everyone knows that it is easie
On Fri, Jun 27, 2014 at 05:19:23PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> There's no need for this to be modifiable. Make it const so that it can
> be put into the .rodata section.
>
> Reviewed-by: Daniel Vetter
> Signed-off-by: Thierry Reding
Definitely a good thing. For Ar
On Wed, Mar 05, 2014 at 10:20:52AM +0100, Philipp Zabel wrote:
> +struct imx_drm_component {
> + struct device_node *of_node;
> + struct list_head list;
> +};
> +
The only thing this structure appears to be doing is ensuring that a
single component doesn't get added twice - is that correct
On Wed, Mar 05, 2014 at 10:20:57AM +0100, Philipp Zabel wrote:
> This patch fixes the TV Encoder DDC I2C bus property to use the common
> 'ddc-i2c-bus' property name instead of 'ddc'.
Looking at both hdmi and tve, the ddc part is very similar. The difference
is how the probe is handled:
imx-hdmi
On Thu, Mar 06, 2014 at 02:54:40PM +0100, Philipp Zabel wrote:
> @@ -566,9 +566,18 @@ static int imx_ldb_bind(struct device *dev, struct
> device *master, void *data)
> return -EINVAL;
> }
>
> - panel_node = of_parse_phandle(child, "fsl,panel", 0);
On Thu, Mar 06, 2014 at 02:54:39PM +0100, Philipp Zabel wrote:
> This patch allows to optionally attach the lvds-channel to a panel
> supported by a drm_panel driver instead of supplying the modes via
> device tree.
Hmm, I think something may be missing in this patch... you're introducing
calls in
On Wed, Mar 05, 2014 at 10:20:51AM +0100, Philipp Zabel wrote:
> Hi,
>
> this latest version of the imx-drm DT binding patches applies
> on top of staging-next and also depends on the OF graph binding
> patchset that moves the v4l2_of helpers to drivers/of.
> Currently, the two patchsets are also
On Fri, Mar 07, 2014 at 07:57:51PM +0100, Philipp Zabel wrote:
> [Added Shawn to Cc:]
>
> On Fri, Mar 7, 2014 at 7:28 PM, Greg Kroah-Hartman
> wrote:
> > On Fri, Mar 07, 2014 at 05:56:12PM +, Russell King - ARM Linux wrote:
> >> On Wed, Mar 05, 2014 at 10:20:51AM
efore cleaning them up at
> driver unload time. And since drm doesn't support hotplugging kms
> objects at all it's positively dangerous to attempt this at runtime.
> Luckily imx only detachs at driver cleanup time and hence we can
> savely remove this.
Are you looking
On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Wa?mann wrote:
> Hi,
>
> Laurent Pinchart wrote:
> > Hi Lothar,
> >
> > On Monday 17 March 2014 16:14:36 Lothar Wa?mann wrote:
> > > DE is not a clock signal, but an 'Enable' signal whose value (high or
> > > low) defines the window in which the pi
On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote:
> Hi Lothar,
>
> That's not my point. I *know* that DE is a data gating signal with a polarity
> already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other
> signals it gets generated on a clock edge and is sampl
On Wed, Mar 19, 2014 at 06:22:14PM +0100, Laurent Pinchart wrote:
> Hi Russell,
>
> (CC'ing Philipp Zabel who might be able to provide feedback as a user of the
> component framework)
>
> Could you please have a look at the questions below and provide an answer
> when
> you'll have time ? I'd
On Thu, Mar 20, 2014 at 01:32:24PM +0100, Sebastian Hesselbarth wrote:
> On 03/20/2014 09:58 AM, Jean-Francois Moine wrote:
>> The I2C address (reg) is required for the TDA998x driver to be loaded
>> and initialized.
>>
>> Signed-off-by: Jean-Francois Moine
>> -
On Thu, Mar 20, 2014 at 02:01:56PM +0100, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 13:32:24 +0100
> Sebastian Hesselbarth wrote:
>
> > > + - reg: I2C address - must be <0x70>
> >
> > TDA9983b datasheet says:
> >
> > "Bits A0 and A1 of the I2C-bus device address are externally selecte
On Thu, Mar 20, 2014 at 02:52:21PM +0100, Jean-Francois Moine wrote:
> Thanks for the link.
>
> OK, then, as the linux tda998x driver handles only the tda 19988 and
> 19989 chips, the HDMI I2C address is always 0x70.
>
> So, question: Russell and Sebastian, do you still w
On Thu, Mar 20, 2014 at 03:59:35PM +0100, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 14:31:10 +
> Russell King - ARM Linux wrote:
>
> > 1. change the DT compatible strings the driver has to accept both
> >nxp,tda19988 and nxp,tda19989, and set the appropriate
On Thu, Mar 20, 2014 at 04:54:40PM +0100, Jean-Francois Moine wrote:
> On Thu, 20 Mar 2014 15:19:34 +
> Russell King - ARM Linux wrote:
>
> > I'm not saying that it has to match the physical device fitted - I'm
> > merely suggesting not using nxp,tda1998
On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote:
> The 'slave encoder' structure of the tda998x driver asks for glue
> between the DRM driver and the encoder/connector structures.
Given how close we are to the coming merge window, that the discussion
about the of-graph bindings
On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote:
> However, we (as in the V4L2 community, and me personally) would have
> appreciated to be CC'ed on the proposal. As you might know we already had a
> solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
> core/v
ot;nxp,tda998x"
>>>> + - compatible: may be "nxp,tda9989", "nxp,tda19988" or "nxp,tda19989"
>>>
>>> There is a "DT is ABI" policy and although there is no mainline Linux
>>> user of current compatible, the correct way
On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote:
> 2. You replace calls of component_add and component_del with calls
> to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT,
> &specific_component_ops),
> or interface_tracker_ifdown.
> Thats all for components.
How does t
On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
> +#if defined(CONFIG_OF)
> +static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
> + struct display_entity_interface_params *params)
> +{
> + int r = params->p.tft_parallel.r_bits;
> + int g = params->
On Thu, Apr 18, 2013 at 06:33:21PM +0100, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them, together with the
> Common Display Framework.
>
> The DT provides information about the hardware configuration
> and limitations (eg. the
instance name to be defined by type.
>
> Signed-off-by: Inki Dae
> ---
> include/linux/module.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 46f1ea0..ac5d79f 100644
> --- a/include/linux/module.
On Wed, Apr 23, 2014 at 05:04:46PM +0200, Andrzej Hajda wrote:
> On 04/22/2014 01:51 PM, Russell King - ARM Linux wrote:
> > Yes, I know that you're desperate to play that down, but you can't get
>
> Not true. I only try to find the best solution and the approach with
&
On Wed, Apr 23, 2014 at 05:43:28PM +0100, Russell King - ARM Linux wrote:
> So, maybe you would like to finally address *my* point about TDA998x
> and your solution in a way that provides a satisfactory answer. *Show*
> how it can be done, or *outline* how it can be done.
Let me be a
On Thu, Apr 24, 2014 at 02:00:49PM -0700, Tim Harvey wrote:
> I'm still seeing issues with HDMI detect on powerup, at least on my
> Gateworks Ventana boards (which have no voltage devider or anything
> else on the HPD line to the IMX6 other than a TVS). I'm currently
> using your latest imx-drm-sta
On Thu, Apr 24, 2014 at 03:57:27PM -0700, Tim Harvey wrote:
> On Thu, Apr 24, 2014 at 3:07 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 24, 2014 at 02:00:49PM -0700, Tim Harvey wrote:
> >> I'm still seeing issues with HDMI detect on powerup, at least on my
>
On Fri, Apr 25, 2014 at 04:36:01PM +0200, Andrzej Hajda wrote:
> On 04/23/2014 07:13 PM, Russell King - ARM Linux wrote:
> > Let me be absolutely clear *why* I'm very interested in this - and that
> > is because I'm presently converting TDA998x and Armada DRM to use the
&
helper users are properly
converted.
drivers/base/component.c | 248 ++---
drivers/gpu/drm/msm/msm_drv.c | 81 +--
drivers/staging/imx-drm/imx-drm-core.c | 57 +---
include/linux/component.h | 8 +-
4 files changed, 206
On Sun, Apr 27, 2014 at 02:51:30PM +0200, Daniel Vetter wrote:
> On Sun, Apr 27, 2014 at 1:00 AM, Russell King - ARM Linux
> wrote:
> > A while back, Laurent raised some comments about the component helper,
> > which this patch set starts to address.
> >
> > The f
On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote:
> The main problem with component framework is that componentization
> significantly changes every driver and changes it in a way which is not
> compatible with traditional drivers, so devices which are intended to
> work with dif
On Mon, Aug 18, 2014 at 02:25:34PM +0800, Shawn Guo wrote:
> On Fri, Jul 25, 2014 at 02:20:40PM +0800, Shawn Guo wrote:
> > HDMI currently stops working after a system suspend/resume cycle. The
> > cause is that the mode setting states in hardware gets lost and isn't
> > restored across the suspen
On Tue, Aug 19, 2014 at 04:16:41AM -0500, Greg KH wrote:
> On Tue, Aug 19, 2014 at 09:08:08AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Aug 18, 2014 at 02:25:34PM +0800, Shawn Guo wrote:
> > > On Fri, Jul 25, 2014 at 02:20:40PM +0800, Shawn Guo wrote:
> > > >
On Thu, Jul 03, 2014 at 12:26:39AM +0900, Inki Dae wrote:
> 2014-07-01 23:22 GMT+09:00 Russell King - ARM Linux arm.linux.org.uk>:
> > On Thu, Jun 26, 2014 at 03:46:01PM +0100, Russell King - ARM Linux wrote:
> >> On Thu, Jun 26, 2014 at 02:34:17PM +0200, Philipp Zabel wro
On Sat, Nov 29, 2014 at 09:12:51AM +0100, Jean-Francois Moine wrote:
> 1)
> The HDMI registers of the tda998x chips are accessed by pages.
> As these HDMI registers may be accessed from different tasks
> (video, irq/workqueue, and soon audio), the page register setting
> must be protected.
>
> 2)
On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> +int imx_hdmi_bind(struct device *dev, struct device *master,
> + void *data, struct drm_encoder *encoder,
> + const struct imx_hdmi_plat_data *plat_data)
> {
> struct platform_device *pdev = to_platform_
On Wed, Dec 03, 2014 at 11:32:12PM +0800, Andy Yan wrote:
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 884923f..26162ef 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -3,3 +3,8 @@ config DRM_PTN3460
> depends
On Thu, Dec 04, 2014 at 12:04:37AM +0800, Andy Yan wrote:
> Hi Russell:
>
> On 2014å¹´12æ03æ¥ 23:38, Russell King - ARM Linux wrote:
> >On Wed, Dec 03, 2014 at 11:29:26PM +0800, Andy Yan wrote:
> >>+int imx_hdmi_bind(struct device *dev, struct device *master,
>
On Wed, Dec 03, 2014 at 05:20:15PM +0100, Philipp Zabel wrote:
> Hi Andy,
>
> It would be better if the bind function would not have to care about
> platform resources, that should be handled in the probe function. I had
> a patch to move them:
>
> http://lists.freedesktop.org/archives/dri-devel/
801 - 900 of 1611 matches
Mail list logo
