On Thu, Jul 20, 2017 at 03:19:10PM +0100, Liviu Dudau wrote:
> On Thu, Jul 20, 2017 at 02:08:29PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote:
> > > On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux wrote
On Thu, Jul 20, 2017 at 01:54:04PM +0100, Liviu Dudau wrote:
> On Thu, Jul 20, 2017 at 12:44:49PM +0100, Russell King - ARM Linux wrote:
> > Actually, scrub that idea - drm_helper_probe_single_connector_modes()
> > calls drm_edid_to_eld() for these cases anyway,
On Mon, Jul 24, 2017 at 02:16:40PM +0200, Hans Verkuil wrote:
> Hi Russell,
>
> On 07/17/2017 02:23 PM, Hans Verkuil wrote:
> >On 17/07/17 14:05, Russell King - ARM Linux wrote:
> >>On Mon, Jul 17, 2017 at 01:39:48PM +0200, Hans Verkuil wrote:
> >>>On 17/0
On Mon, Jul 24, 2017 at 02:07:17PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 24, 2017 at 02:16:40PM +0200, Hans Verkuil wrote:
> > Just to make sure you aren't waiting for me to do anything: as far as I can
> > tell
> > the Kconfig above will ensure the right
On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote:
> Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd to
> initialise without an interrupt present.
>
> Signed-off-by: Russell King
This isn't fully functional on ARM MPS platforms yet, but at least
gets us further. With
On Fri, Jul 28, 2017 at 04:23:11PM +0100, Liviu Dudau wrote:
> On Wed, Jul 26, 2017 at 11:27:48AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jul 26, 2017 at 11:05:39AM +0100, Russell King wrote:
> > > Some ARM platforms do not wire the HDLCD interrupt. Allow hdlcd t
Hi,
This series adds dw-hdmi CEC support. This is done in four stages:
1. Add cec-notifier support
2. Fix up the clkdis register support, as this register contains a
clock disable bit for the CEC module.
3. Add the driver.
4. Remove definitions that are not required from dw-hdmi.h
The CEC dr
On Wed, Aug 02, 2017 at 04:14:34PM +0300, Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 02 Aug 2017 08:47:23 Hans Verkuil wrote:
> > On 08/02/2017 12:32 AM, Laurent Pinchart wrote:
> > >> +
> > >> +cec_register_cec_notifier(cec->adap, cec->notify);
> > >> +
> > >> +return 0;
On Wed, Aug 02, 2017 at 04:17:15PM +0200, Hans Verkuil wrote:
> Yes, you should. Well spotted, I missed that one.
Great, another respin. I give up.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
accordin
On Wed, Aug 02, 2017 at 05:22:54PM +0300, Laurent Pinchart wrote:
> Then it should be even simpler. Instead of creating a separate platform
> device
> for the DW HDMI CEC, we can just call the DW HDMI CEC driver init/cleanup
> functions directly when the IP core implements CEC. When it doesn't,
On Thu, Nov 09, 2017 at 02:12:45PM +0200, Jani Nikula wrote:
> And as I said elsewhere in the thread, Russell's patch may be relevant
> for current Linus' master and stable. We just need to reconciliate how
> the two things should work together in drm-next and v4.15 and on.
Exactly, the patch is i
On Thu, Nov 09, 2017 at 05:01:35PM +0200, Jani Nikula wrote:
> On Thu, 09 Nov 2017, Luís Mendes wrote:
> > Hi Jani,
> >
> > I tried:
> > git clone git://people.freedesktop.org/~airlied/linux -b drm-next
> > --depth=1 --single-branch
> >
> >
On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
> > Parsing the EDID for HDMI and audio information in the get_modes()
> > callback is incorrect - this only parses the EDID read from the
> > connector, not any override o
(since the
TDA9950 may be a separate device.)
drivers/gpu/drm/i2c/Kconfig | 6 +
drivers/gpu/drm/i2c/Makefile | 1 +
drivers/gpu/drm/i2c/tda9950.c | 507 ++
drivers/gpu/drm/i2c/tda998x_drv.c | 246 +++--
include/linux
On Wed, Nov 29, 2017 at 09:11:43AM +, Russell King - ARM Linux wrote:
> On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
> > Hi Russell,
> >
> > On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> > > Hi,
> > >
> > > This
On Wed, Nov 29, 2017 at 01:43:27PM +0100, Hans Verkuil wrote:
> On 11/29/17 10:11, Russell King - ARM Linux wrote:
> > On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
> >> Hi Russell,
> >>
> >> On 11/29/2017 12:17 AM, Russell King - ARM Linux wro
On Wed, Nov 29, 2017 at 08:41:45AM +0100, Hans Verkuil wrote:
> Hi Russell,
>
> On 11/29/2017 12:17 AM, Russell King - ARM Linux wrote:
> > Hi,
> >
> > This patch series adds CEC support to the DRM TDA998x driver. The
> > TDA998x family of devices integrat
Hi David,
This series fixes some issues in the Armada DRM driver:
- A memory leak while cleaning up in the CRTC initialisation path
- Avoid powering down YUV FIFOs when disabling the graphics plane
- Several fixes for the overlay plane positioning
I'll send a pull request for this as is normal fo
On Wed, Nov 29, 2017 at 09:53:42AM -0500, Sean Paul wrote:
> On Wed, Nov 29, 2017 at 11:45:43AM +, Russell King wrote:
> > Fix the leak of the CRTC structure in the failure paths of
> > armada_drm_crtc_create().
> >
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/armada/armada_cr
On Wed, Nov 29, 2017 at 03:03:09PM -0500, Sean Paul wrote:
> On Wed, Nov 29, 2017 at 07:16:43PM +, Russell King - ARM Linux wrote:
> > On Wed, Nov 29, 2017 at 09:53:42AM -0500, Sean Paul wrote:
> > > On Wed, Nov 29, 2017 at 11:45:43AM +, Russell King wrote:
> > >
On Fri, Dec 01, 2017 at 05:38:51PM +0100, Philipp Zabel wrote:
> On Fri, 2017-12-01 at 11:36 +0100, Lucas Stach wrote:
> > All code paths which populate userptr BOs are fine with the get_pages
> > function taking the mmap_sem lock. This allows to get rid of the pretty
> > involved architecture with
On Fri, Dec 01, 2017 at 11:36:06AM +0100, Lucas Stach wrote:
> There is no need to synchronize with oustanding retire jobs if the object
> has gone idle. Retire jobs only ever change the object state from active to
> idle, not the other way around.
>
> The IOVA put race is uncritical, as the GEM_W
+
drivers/gpu/drm/i2c/tda998x_drv.c | 246 --
include/linux/platform_data/tda9950.h | 16 +
6 files changed, 751 insertions(+), 28 deletions(-)
v2: updated DT property.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadban
Hi David,
This series builds upon the set of fixes previously submitted to move
Armada DRM closer to atomic modeset. We're nowhere near yet, but this
series helps to get us closer by unifying some of the differences
between the primary and overlay planes.
New features added allows userspace to d
Hi David,
This series fixes some issues in the Armada DRM driver:
- A memory leak while cleaning up in the CRTC initialisation path
- Avoid powering down YUV FIFOs when disabling the graphics plane
- Several fixes for the overlay plane positioning
Minor updates for the comments from Sean Paul, an
On Wed, Dec 06, 2017 at 02:50:44PM +0100, Hans Verkuil wrote:
> Hi Russell,
>
> Thanks for this patch series!
>
> On 12/06/17 13:35, Russell King wrote:
> > The TDA998x is a HDMI transmitter with a TDA9950 CEC engine integrated
> > onto the same die. Add support for the TDA9950 CEC engine to the
On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
> On 12/06/17 13:35, Russell King wrote:
> > We no longer use the CEC client to access the CEC part itself, so we can
> > move this later in the initialisation sequence.
> >
> > Signed-off-by: Russell King
> > ---
> > drivers/gpu/drm/
On Mon, Dec 11, 2017 at 09:54:02PM +0100, Daniel Vetter wrote:
> On Fri, Dec 08, 2017 at 12:31:08PM +, Russell King wrote:
> > Add the defacto-standard "iturbt_709" property to the overlay plane to
> > control the YUV to RGB colorspace conversion. This is mutually
> > exclusive with the CSC_YU
On Wed, Dec 06, 2017 at 03:11:43PM +0100, Hans Verkuil wrote:
> Hi Russell,
>
> Some small comments below:
>
> On 12/06/17 13:35, Russell King wrote:
> > + /*
> > +* This should never happen: the data sheet says that there will
> > +* always be a valid message if the interrupt line is a
On Tue, Dec 12, 2017 at 03:37:21PM +0100, Hans Verkuil wrote:
> Hi Russell,
>
> On 08/12/17 12:59, Russell King - ARM Linux wrote:
> > On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
> >> On 12/06/17 13:35, Russell King wrote:
> >>> We no longer
On Wed, Dec 13, 2017 at 03:41:49PM +, Daniel Stone wrote:
> Hi Russell,
>
> On 8 December 2017 at 12:31, Russell King wrote:
> > Add the defacto-standard "iturbt_709" property to the overlay plane to
> > control the YUV to RGB colorspace conversion. This is mutually
> > exclusive with the CS
pport. Some video players use the Xv property when
> > available.
> >
> > https://cgit.freedesktop.org/xorg/driver/xf86-video-nv/tree/src/nv_video.c#n128
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/dispnv04/overlay.c?h=v4.15-rc
On Tue, Jun 28, 2016 at 04:44:12PM +0100, Jose Abreu wrote:
> This patch adds support for the Synopsys HDMI TX Phy in
> bridge dw-hdmi.
>
> The init flow is the same as the Rockchip Phy so we
> only need to add one define and one if statement.
>
> Also, the audio infoframe was fixed to sampling f
On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
> > The drm_encoder_cleanup() was missing both from the error path of
> > dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was
> > enabled and we ended up d
;> Hi,
> > >>
> > >> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao
> wrote:
> > >> > On 2016å¹´03æ05æ¥ 20:39, Russell King - ARM Linux wrote:
> > >> >> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
> > >&g
On Mon, Feb 29, 2016 at 05:20:16PM +0100, Lucas Stach wrote:
> If the end of the system DMA window is farther away from the start of
> physical RAM than the size of the GPU linear window, move the linear
> window so that it ends at the same address than the system DMA window.
>
> This allows to ma
On Mon, Mar 14, 2016 at 04:02:35PM +0100, Lucas Stach wrote:
> I guess not using the offset on MC10 will also allow you to enable TS on
> those parts? In that case we might advertise this with a patchlevel
> change of the API.
I don't think we need that - it isn't an API change as such. What
we c
creating a
> minimal fake drm file_priv for the fbdev emulation (and treat it more like
> any other kms client), but I think that's way too much work when this
> simple patch here gets the job done.
I think first, a different question needs to be answered:
include/uapi/
On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> In this case, someone else may send an email again like you "who is going to
> merge?"
> That would be why we need a maintainer.
>
> drm panel is already managed well by Thierry Reding without such confusion.
You don't need a maintaine
On Wed, Mar 23, 2016 at 08:54:15AM +0900, Inki Dae wrote:
>
Please wrap your long lines.
>
> 2016ë
03ì 23ì¼ 08:39ì Russell King - ARM Linux ì´(ê°) ì´ ê¸:
> > On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
> >> In this case, someone else may send
On Tue, Mar 29, 2016 at 10:54:08AM +0200, Takashi Iwai wrote:
> On Thu, 17 Mar 2016 13:22:29 +0100,
> Jyri Sarha wrote:
> >
> > Add IEC958 channel status helper that gets the audio properties from
> > snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to
> > produce the channel status bi
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
>
On Mon, Nov 19, 2012 at 04:32:36PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 15, 2012 at 02:39:41PM +, Arnd Bergmann wrote:
> > On Thursday 15 November 2012, Rob Clark wrote:
> > > > I still haven't heard a conclusive argument why we need to use
> > > > get_user()
> > > > rather than copy_from
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 re-use
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!
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))
On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> From: Rob Clark
>
> A new atomic modeset/pageflip ioctl being developed in DRM requires
> get_user() to work for 64bit types (in addition to just put_user()).
NAK.
(I did write a better email explaining all the ins and outs of why thi
On Mon, Nov 12, 2012 at 01:58:32PM -0600, Rob Clark wrote:
> On Mon, Nov 12, 2012 at 1:27 PM, Russell King - ARM Linux
> wrote:
> > On Fri, Nov 09, 2012 at 03:17:33PM -0600, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> A new atomic modeset/pagefli
On Mon, Nov 12, 2012 at 05:33:41PM -0600, Rob Clark wrote:
> I'm sort of thinking maybe we want to change 'switch (sizeof(*(__p)))'
> with 'switch (sizeof(typeof(x)))' in case someone ignores the compiler
> warning when they try something like:
Definitely not. Ttype of access is controlled by the
On Mon, Nov 12, 2012 at 06:31:50PM -0600, Rob Clark wrote:
> right, that is what I was worried about.. but what about something
> along the lines of:
>
> case 8: { \
> if (sizeof(x) < 8)
On Tue, Nov 13, 2012 at 09:11:09AM +, Arnd Bergmann wrote:
> On Tuesday 13 November 2012, Rob Clark wrote:
> > right, that is what I was worried about.. but what about something
> > along the lines of:
> >
> > case 8: { \
> >
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
uxppc-...@lists.ozlabs.org
> CC: devicetree-disc...@lists.ozlabs.org
> CC: Richard Henderson
> CC: Ivan Kokshaysky
> CC: Matt Turner
> CC: linux-al...@vger.kernel.org
> CC: Thomas Gleixner
> CC: Ingo Molnar
> CC: "H. Peter Anvin"
> CC: x...@kernel.org
> CC: Tony
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
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.
Thes
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.
What follows is my DRM driver for Dove, which I've been working on with
the Solid-run Cubox, which only offers HDMI output via the TDA19988
chip.
Not everything is finished off perfectly in this driver; there's quite
a number of ragged edges (particularly with page flipping, which is
completely un
On Fri, May 17, 2013 at 08:38:03AM +0200, Jean-Francois Moine wrote:
> The signals SIGALRM (most often) and SIGPOLL (sometimes) may be raised
> after irq or some parameter change and this aborts the i2c exchanges.
>
> The problem is solved by masking these signals.
NAK. The real problem is in th
On Fri, May 17, 2013 at 01:33:45PM +0200, Jean-Francois Moine wrote:
> Hi Russell,
>
> I quickly compared your dove drm driver and ours (Sebastian and me):
I already said - I don't support DT. I don't run any DT based ARM
devices, so I have no experience with DT. What I care more about
is a wor
On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> On Fri, 17 May 2013 13:01:15 +0100
> Russell King - ARM Linux wrote:
> > > - CMA helper
> > >
> > > You don't use DRM_KMS_CMA_HELPER and DRM_GEM_CMA_HELPER which would
> > >
On Fri, May 17, 2013 at 07:00:29PM +0100, Russell King - ARM Linux wrote:
> On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> > Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> > transparency (64x64) or full ARGB (64x32 or 32x64). I
On Sat, May 18, 2013 at 09:30:09PM +0200, Sebastian Hesselbarth wrote:
> The device for tda998x yes, but not the driver. Anyway, Russel decided
> to have tda998x probed by his drm_driver.
For the simple reason that _that_ is how DRM slave encoders work.
Sometimes, reading the code of the subsystem
On Sat, May 18, 2013 at 07:45:02PM +0200, Jean-Francois Moine wrote:
> It seems we are moving backwards:
> - what about the display controller?
> - how do you clone the lcd 0 output to the port B?
> - what occurs when the si5351 and the tda998x are modules?
I've no idea why you keep bringing that
On Fri, May 17, 2013 at 07:40:23PM +0200, Jean-Francois Moine wrote:
> Maybe I did not explain correctly: the colored cursor maybe RGB888 +
> transparency (64x64) or full ARGB (64x32 or 32x64). I coded the first
> case. And, yes, I better like a hardware cursor: it asks for less
> computation, and
On Sat, May 18, 2013 at 08:56:59AM +0200, Jean-Francois Moine wrote:
> On Thu, 16 May 2013 20:26:18 +0100
> Russell King wrote:
>
> > When switching between various drivers for this device, it's possible
> > that some critical registers are left containing values which affect
> > the device opera
On Fri, May 17, 2013 at 01:33:45PM +0200, Jean-Francois Moine wrote:
> I quickly compared your dove drm driver and ours (Sebastian and me):
>
> - CMA helper
>
> You don't use DRM_KMS_CMA_HELPER and DRM_GEM_CMA_HELPER which would
> simplify some code.
Looking at the CMA helper code in DRM, it
So, while tinkering with my Dove DRM driver, I tripped over a BUG_ON()
in drm_mm_hole_node_start(), which was called from drm_mm_dump_table():
int drm_mm_dump_table(struct seq_file *m, struct drm_mm *mm)
{
struct drm_mm_node *entry;
unsigned long total_used = 0, total_free = 0, tot
On Sun, May 19, 2013 at 06:49:22PM +0200, Sebastian Hesselbarth wrote:
> This adds an irq handler for HPD to the tda998x slave encoder driver
> to trigger HPD change instead of polling. The gpio connected to int
> pin of tda998x is passed through platform_data of the i2c client. As
> HPD will ultim
On Sat, May 18, 2013 at 09:18:46PM +0200, Jean-Francois Moine wrote:
> The general hardware code of both drivers is close enough for merging
> may be done starting from anyone. But the general layout is not:
>
> - my driver is DT driven and has one card with 2 CTRC's and 2 connectors.
>
> - Russe
On Mon, May 20, 2013 at 09:36:02AM -0400, Alex Deucher wrote:
> You can tell the xserver what size cursor you support when you call
> xf86_cursors_init() in the ddx. Just expose a 32x64 or 64x32 ARGB
> cursor. Most apps don't use a 64x64 cursor anyway. I've used
> hardware with non-64x64 cursors
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 trie
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
YNC at line 542-547, pixel 2448.
> > + * Note: Vsync front porch remains constant!
> > + *
> > + * if (odd_frame) {
> > + * vtotal = mode->crtc_vtotal + 1;
> > + * vbackporch = mode->crtc_vsync_start - mode->crtc_vdisplay + 1;
> > + * vhorizpos = mode-&g
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 (eg, the Vmet
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
> t
On Mon, Jun 10, 2013 at 11:57:32AM -0400, Rob Clark wrote:
> On Sun, Jun 9, 2013 at 3:29 PM, Russell King
> wrote:
> > +/* The mode_config.mutex will be held for this call */
> > +static int armada_drm_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
> > y,
> > + struct drm_framebuffer
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.
>> + */
>
> nit: "We confirmed their non-inv
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 dif
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 re
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.
I
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
> >&
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 me
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 me
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
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&#x
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 drop
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
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 chasi
gt; 4. Now CPU or DMA can access all dmabufs locked in step 3.
>
> 5. Unlock all dmabufs added in a sync object after DMA or CPU access
> to these dmabufs is completed:
> dmabuf_sync_unlock(sync);
>
> And call the following functions to release all resource
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
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
701 - 800 of 1611 matches
Mail list logo
