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 = 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)
+ obj-linear
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);
+ free = drm_mm_search_free(priv-linear
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
where
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
li...@arm.linux.org.uk wrote:
| Default Colorimetry
|
| ...
|
| 480p, 480i, 576p, 576i, 240p
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 Draked...@laptop.org wrote:
On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moinemoin...@free.fr
wrote:
- the phandles to the
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.
You'll see some evidence
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
counted
On Thu, Jul 25, 2013 at 02:21:59PM -0400, Rob Clark wrote:
On Thu, Jul 25, 2013 at 1:17 PM, tom.cook...@arm.com 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
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
drm/i2c: nxp-tda998x
On Tue, Aug 06, 2013 at 12:20:12AM +0200, Sebastian Hesselbarth wrote:
switch (mode) {
case DRM_MODE_DPMS_ON:
+ /* Write the default value MUX register */
+ reg_write(encoder, REG_MUX_VP_VIP_OUT, 0x24);
This looks like an old version of my patch. I ended
On Tue, Aug 06, 2013 at 12:20:11AM +0200, Sebastian Hesselbarth wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
TDA19988 devices need their RAM enabled in order to read EDID
information. Add support for this.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Tested
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 *= 1000;
+
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 - mode-hsync_start;
I
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 audio_clk_cfg;
+
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 sebastian.hesselba...@gmail.com
The plus point with this is that interlaced modes
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 EDID reading on TDA19988 devices
drm/i2c: tda998x: ensure VIP output
On Mon, Aug 19, 2013 at 09:23:17AM +1000, Dave Airlie wrote:
On Thu, Aug 15, 2013 at 5:43 AM, Sebastian Hesselbarth
sebastian.hesselba...@gmail.com wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
This patch adds tda998x specific parameters to allow it to be configured
for different
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 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
current driver to allow to configure VIP
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 li...@arm.linux.org.uk wrote:
AFAIK, the TI boards have no pin-swapped, nor has the Cubox (there is
no need to set the bit CFG_GRA_SWAPRB of the register
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 moin...@free.fr wrote:
On Wed, 21 Aug 2013 23:36:05 +0100
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
AFAIK, the TI boards have no pin-swapped, nor has the Cubox
On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
This patch adds tda998x specific parameters to allow it to be configured
for different boards using it. Also, this implements rudimentary audio
support for S/PDIF attached
This started out as a request to look at the DMA mask situation, and how
to solve the issues which we have on ARM - notably how the DMA mask
should be setup.
However, I started off reviewing how the dma_mask and coherent_dma_mask
was being used, and what I found was rather messy, and in some
On Fri, Sep 20, 2013 at 08:11:25AM -0500, Felipe Balbi wrote:
Hi,
On Fri, Sep 20, 2013 at 12:14:38AM +0100, Russell King wrote:
Use platform_device_register_full() for those drivers which can, to
avoid messing directly with DMA masks. This can only be done when
the driver does not need
On Fri, Sep 20, 2013 at 02:21:37AM +0100, Ben Hutchings wrote:
On Thu, 2013-09-19 at 22:25 +0100, Russell King wrote:
[...]
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask
On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
The DMA API requires drivers to call the appropriate dma_set_mask()
functions before doing any DMA mapping. Add this required call to
the AMBA PL08x driver
Ping?
On Mon, Sep 02, 2013 at 03:50:57PM +0100, Russell King - ARM Linux wrote:
On Wed, Aug 14, 2013 at 09:43:30PM +0200, Sebastian Hesselbarth wrote:
From: Russell King rmk+ker...@arm.linux.org.uk
This patch adds tda998x specific parameters to allow it to be configured
for different
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
register_platform_device_full() can setup the DMA mask provided the
appropriate member is set in struct platform_device_info. So lets
make that be the case
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
On Thu, 19 Sep 2013, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should
On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote:
Hi,
sorry for the lat response, as I've been traveling in the last weeks.
At Thu, 19 Sep 2013 22:53:02 +0100,
Russell King wrote:
This code sequence is unsafe in modules:
static u64 mask = DMA_BIT_MASK(something
On Thu, Sep 26, 2013 at 04:21:36PM +0530, Archit Taneja wrote:
Hi,
On Friday 20 September 2013 04:41 AM, Russell King wrote:
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
2013/9/19 Russell King - ARM Linux li...@arm.linux.org.uk:
This email is only being sent to the mailing lists in question, not to
anyone personally. The list of individuals is far to great to do that.
I'm hoping no mailing
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
li...@arm.linux.org.uk 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
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 12:09:22PM +0200, Jean-Francois Moine wrote:
On Mon, 7 Oct 2013 10:40:08 +0100
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
This patch adds ARGB hardware cursor support to the DRM driver for the
Marvell Armada SoCs. ARGB cursors are supported
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 li...@arm.linux.org.uk wrote:
On Mon, Oct 07, 2013 at 11:18:07AM +0200, Jean-Francois Moine wrote:
[snip]
It seems we are going backwards: as the Armada
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 li...@arm.linux.org.uk wrote:
Here is a small story about i2s/spdif: once, I set the tda998x to use
the spdif input, and at this time, I was using the dummy
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 li...@arm.linux.org.uk wrote:
However, what you're suggesting is dangerous. What do you do when you're
presented with a cursor which is 64x64 ? Do you
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.)
Rob has looked
On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
On Sun, Oct 6, 2013 at 6:08 PM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
+ /*
+* If we have an overlay plane associated with this CRTC, disable
+* it before the modeset to avoid its coordinates being
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
li...@arm.linux.org.uk wrote:
On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
probably this thread is applicable here too?
https://lkml.org/lkml/2013/9/12/417
On Fri, Oct 11, 2013 at 03:05:56PM +1000, Dave Airlie wrote:
From: Dave Airlie airl...@redhat.com
This will make the next patch to change how this works a lot cleaner.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/i915/i915_sysfs.c | 32
On Mon, Feb 06, 2017 at 05:55:33PM +, Liviu Dudau wrote:
> OK, I will fix the driver if Rob's patch still requires it.
I don't think you ever needed it. As Rob says, what you're testing
won't ever change unless you're using overlays - it's certainly not
dependent on the tda998x module being
rmada_debugfs.c still have reference to it.
>
> Signed-off-by: Shawn Guo <shawn@linaro.org>
> Cc: Russell King <li...@armlinux.org.uk>
Acked-by: Russell King <rmk+ker...@armlinux.org.uk>
Thanks.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband f
On Tue, Feb 07, 2017 at 05:16:14PM +0800, Shawn Guo wrote:
For:
> drivers/gpu/drm/armada/armada_drv.c | 1 -
Acked-by: Russell King <rmk+ker...@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line:
On Mon, Feb 06, 2017 at 05:23:06PM +, Liviu Dudau wrote:
> On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote:
> > On Mon, Feb 06, 2017 at 10:29:33AM +, Liviu Dudau wrote:
> > > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote:
> > > > - /* add the remote encoder
On Tue, Feb 07, 2017 at 12:42:15PM +0200, Laurent Pinchart wrote:
> On an unrelated note, for security reasons we should try to make the driver
> structure static, or at least move ops to a static structure.
ITYM "const" not "static".
"static" doesn't get you anything from a security point of
On Fri, Feb 03, 2017 at 09:36:30PM -0600, Rob Herring wrote:
> The Armada and Rockchip drivers remain oddballs with their own graph
> parsing. I can't see how the armada driver even can work. There's
> nothing to instantiate the armada-drm device either in DT or the kernel.
Correct, that's
On Mon, Jan 30, 2017 at 09:18:25PM +0100, Thierry Reding wrote:
> On Fri, Dec 09, 2016 at 12:21:22PM +0100, Christian Gmeiner wrote:
> > @@ -167,6 +174,9 @@ struct drm_etnaviv_gem_submit {
> > __u64 bos;/* in, ptr to array of submit_bo's */
> > __u64 relocs; /* in, ptr
On Mon, Jan 30, 2017 at 11:58:32AM +0100, Lucas Stach wrote:
> Am Freitag, den 09.12.2016, 12:21 +0100 schrieb Christian Gmeiner:
> > Reading some registers end in a system crash ala:
> >
> > Unhandled fault: external abort on non-linefetch (0x1028) at 0xfe641000
> > Internal error: : 1028
On Mon, Jan 30, 2017 at 12:01:18PM +0100, Lucas Stach wrote:
> Am Freitag, den 09.12.2016, 12:21 +0100 schrieb Christian Gmeiner:
> > - if (r->flags) {
> > - DRM_ERROR("readback flags not 0");
> > + if (r->flags > ETNA_READBACK_PERF) {
> > +
On Mon, Feb 20, 2017 at 05:53:31PM +, Liviu Dudau wrote:
> Sorry, looks like this fell through the cracks of us trying to fix the
> other issues you were seeing. I'm attaching a patch, please let me know
> if this works for you.
I don't have time to test right now, but it looks similar to
On Mon, Feb 20, 2017 at 08:05:58PM +0200, Ville Syrjälä wrote:
> This stuff should be using the clipped coordinates, not the user
> coordinates. And it doesn't look like this guy is even calling the
> clip helper thing.
>
> malidp seems to be calling that thing, but it still doesn't
> manage to
On Fri, Nov 18, 2016 at 11:37:33PM +, Russell King - ARM Linux wrote:
> Something I also noticed is this:
>
> scanout_start = gem->paddr + plane->state->fb->offsets[0] +
> plane->state->crtc_y * plane->state->fb->pitches[0] +
On Mon, Feb 13, 2017 at 02:37:31PM +0100, Maarten Lankhorst wrote:
> All for it, looks sane. The last hunk fails to apply because it's based on
> an older version of page_flip, but easy enough to fix.
Yes, it's based on v4.10-rc7.
Thanks.
--
RMK's Patch system:
On Sun, Feb 12, 2017 at 01:42:38PM +, Russell King - ARM Linux wrote:
> On Sun, Feb 12, 2017 at 01:18:54PM +0000, Russell King - ARM Linux wrote:
> > Hi,
> >
> > Here's another issue with imxdrm. I got this while trying to reproduce
> > Dan's problem by ena
On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote:
> [ 43.997066] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> [CRTC:24:crtc-0] flip_done timed out
> [ 55.517063] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
> [CRTC:24:crtc-0] flip_done timed out
This seems to lay
Hi,
Here's another issue with imxdrm. I got this while trying to reproduce
Dan's problem by enabling the lvds output using the patch below
originally from Fabio, but updated a bit. This doesn't occur if I leave
LVDS disabled.
The taint is due to the IMX capture modules from Steve, who chose to
On Sun, Feb 12, 2017 at 01:18:54PM +, Russell King - ARM Linux wrote:
> Hi,
>
> Here's another issue with imxdrm. I got this while trying to reproduce
> Dan's problem by enabling the lvds output using the patch below
> originally from Fabio, but updated a bit. This doesn't o
On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote:
> On Sun, Feb 12, 2017 at 12:15:46AM +0000, Russell King - ARM Linux wrote:
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 21f992605541..46668d071d6a 100
On Mon, Feb 13, 2017 at 08:55:53AM +, Chris Wilson wrote:
> On Mon, Feb 13, 2017 at 09:05:33AM +0100, Thierry Reding wrote:
> > On Sun, Feb 12, 2017 at 12:15:46AM +, Russell King - ARM Linux wrote:
> > > On Sat, Feb 11, 2017 at 09:09:34PM +, Dan MacDonald wrote
On Mon, Feb 13, 2017 at 09:17:49AM +0100, Thierry Reding wrote:
> Of course, the above still requires that the core messages output the
> name along with the ID.
Thankfully, that's not a very big patch. I'll post it later today.
--
RMK's Patch system:
On Thu, Oct 20, 2016 at 11:20:05AM +0300, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 10:35:21 Russell King - ARM Linux wrote:
> > Moreover, as I've already said, converting tda998x to a DRM bridge
> > will not get rid of the encoder/connector
On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
> 3) Rough conversion to bridge:
So I thought I might give this a try, and see what's needed to complete
the patch, but...
I thought we'd got past the dark ages of email clients screwing up
patches, but it seems not. This patch is
On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> <rmk+kernel at armlinux.org.uk> wrote:
> > Convert DT component matching to use component_match_add_release().
> >
> > Signed-off-by: Russell King
On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote:
>
>
> On 10/20/2016 02:45 PM, Russell King - ARM Linux wrote:
> >On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:
> >>
> >>
> >>On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
&
On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote:
>
>
> On 10/20/2016 01:50 PM, Laurent Pinchart wrote:
> >Hi Russell,
> >
> >On Wednesday 19 Oct 2016 10:35:21 Russell King - ARM Linux wrote:
> >>On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent
On Fri, Oct 21, 2016 at 09:04:39PM +0200, Jean-Francois Moine wrote:
> On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> (sorry, I lost your original mail)
> > >>> DRM bridges indeed don't create encoders. That task is left to the
> > >>> display
> > >>> driver. The
As part of the discussion about converting tda998x to a bridge, here's
some preparatory work for that, which includes a bunch of fixes. I'm
sending this out _early_ as I'm not going to be working on any kernel
stuff next week (it's likely I won't even be reading email.) So it may
be a little
On Wed, Oct 19, 2016 at 10:46:48AM +0100, Brian Starkey wrote:
> Hi Jyri,
>
> I believe this will break mali-dp and hdlcd, unless something changed
> while I wasn't looking. Please see this previous thread where I did
> the same thing and then had to have it reverted: [1]
>
> Before removing
On Thu, Oct 20, 2016 at 07:15:56PM -0400, Sean Paul wrote:
> On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote:
> >> On Wed, Oct 19, 2016 at 6:28 AM, Russell King
> >> <rmk
On Mon, Oct 24, 2016 at 10:39:27AM +0530, Archit Taneja wrote:
> Sorry about that. I'll post out a proper patch for this once we resolve
> the drm_bridge shortcomings you've mentioned. I can create one if you
> want to try it now.
As said elsewhere, I've been away, so I haven't had a chance to
On Mon, Oct 24, 2016 at 08:53:04AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 11:58:00AM +0530, Archit Taneja wrote:
> > On 10/22/2016 03:25 PM, Russell King - ARM Linux wrote:
> > > Looking at drm_bridge_disable() and drm_bridge_enable(), the control
&
On Mon, Oct 31, 2016 at 09:00:08AM +, Russell King - ARM Linux wrote:
> I need the patch against v4.8. I'm happy to pick it up and add it
> to my drm-tda998x-devel branch, which you can then merge into
> drm-misc if you wish.
... or if Brian wants to send a git pull requ
On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
> The first one is that this overscanning should be reported by the
> connector I guess? but this is really TV specific, so we need one way
> to let the user tell how the image is displayed on its side, and we
> cannot really
On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey
> wrote:
> >>
> >>> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> >>> b/drivers/gpu/drm/i2c/tda998x_drv.c
> >>> index f4315bc..6e6fca2 100644
> >>> ---
On Mon, Oct 24, 2016 at 04:27:45PM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 12:14:14PM +0200, Arnd Bergmann wrote:
> > On Saturday, October 22, 2016 5:14:42 PM CEST Baoyou Xie wrote:
> > > We get 1 warning when building kernel with W=1:
> > > drivers/gpu/drm/i2c/tda998x_drv.c:1292:5:
On Sun, Oct 30, 2016 at 01:56:25PM +, James Le Cuirot wrote:
> These were previously set in dw_hdmi_connector_get_modes but this
> isn't called when the EDID is overridden. This can be seen in
> drm_helper_probe_single_connector_modes. Using the
> drm_kms_helper.edid_firmware parameter
On Thu, Oct 27, 2016 at 12:17:24AM +0200, Maxime Ripard wrote:
> Hi Rob,
>
> On Wed, Oct 26, 2016 at 05:13:46PM -0500, Rob Herring wrote:
> > On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> > > Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> > > an enable
On Fri, Oct 28, 2016 at 01:22:21AM +, Kuninori Morimoto wrote:
> +static struct platform_driver snd_dw_hdmi_driver = {
> + .probe = snd_dw_hdmi_probe,
The driver must have a .remove function, because the platform device it
is binding against can appear and disappear.
--
RMK's Patch
On Tue, Oct 25, 2016 at 12:19:19PM +0200, Daniel Vetter wrote:
> On Tue, Oct 25, 2016 at 10:52:33AM +0100, Brian Starkey wrote:
> > Hi Daniel,
> >
> > On Mon, Oct 24, 2016 at 10:24:42PM +0200, Daniel Vetter wrote:
> > > On Mon, Oct 24, 2016 at 4:52 PM, Brian Starkey
> > > wrote:
> > > > >
> >
On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> >> Actually, could you please hold off picking this up? We need to make
&g
d
4.8-rc7 in (and fixed the multitude of conflicts), and manually made the
changes in your patch. Nothing seems to have broken, so I think we're
good.
Acked-by: Russell King <rmk+kernel at armlinux.org.uk>
Daniel, please take this change through the drm-misc tree as I'm unlikely
to have a branch wh
On Thu, Sep 22, 2016 at 11:39:18AM +0100, Brian Starkey wrote:
> Actually, could you please hold off picking this up? We need to make
> changes in mali-dp and hdlcd or this will mess up their registration.
> I will send those patches later today, but better if this all goes in
> together (whenever
On Thu, Sep 22, 2016 at 05:32:35AM -0700, Sean Paul wrote:
> On Thu, Sep 22, 2016 at 5:09 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Sep 22, 2016 at 04:22:40AM -0700, Sean Paul wrote:
> >> On Thu, Sep 22, 2016 at 3:51 AM, Russell King - ARM Linux
> >> wrot
On Thu, Sep 22, 2016 at 02:38:45PM +0100, Brian Starkey wrote:
> However, without patching all three drivers in the same commit, there
> would always be some breakage. HDLCD and Mali-DP call
> drm_dev_register() before binding the components - this was needed to
> work with tda998x, which needed
On Tue, Oct 18, 2016 at 10:29:33AM +0200, Maxime Ripard wrote:
> The Allwinner display engine doesn't have any kind of hardware help to deal
> with TV overscan.
I'm not sure I follow. My understanding (from reading the CEA specs)
is that TVs are expected to overscan the image, so the upper left,
On Wed, Oct 19, 2016 at 11:52:15AM +0300, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 09:16:30 Russell King - ARM Linux wrote:
> > On Wed, Oct 19, 2016 at 10:54:06AM +0300, Laurent Pinchart wrote:
> > > On Wednesday 19 Oct 2016 00:33:54 Jyri Sa
On Wed, Oct 19, 2016 at 10:54:06AM +0300, Laurent Pinchart wrote:
> Hi Jyri,
>
> Thank you for the patch.
>
> On Wednesday 19 Oct 2016 00:33:54 Jyri Sarha wrote:
> > Remove obsolete drm_connector_register() call from tda998x_bind(). All
> > connectors are registered when drm_dev_register() is
On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote:
> Hi Russell,
>
> On Wednesday 19 Oct 2016 10:11:22 Russell King - ARM Linux wrote:
> > In any case, I don't agree with converting it to a DRM bridge - that will
> > mean that we have to split the driver into t
On Fri, Sep 23, 2016 at 03:13:15PM +0200, Daniel Vetter wrote:
> Hm, maybe we should simply not call ->lastclose for kms drivers. That is
> kinda only a hack for ums/dri1 drivers.
Are you sure about that - isn't it needed so that the fbdev mode gets
restored when the last DRM user exits, so that
h 'static'.
>
> Signed-off-by: Baoyou Xie
Thanks. You can have an:
Acked-by: Russell King <rmk+kernel at armlinux.org.uk>
with one change to this patch:
> ---
> drivers/gpu/drm/armada/armada_gem.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git
On Sun, Sep 25, 2016 at 03:59:19PM +0800, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/gpu/drm/i2c/tda998x_drv.c:1292:5: warning: no previous prototype for
> 'tda998x_audio_digital_mute' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file
device *dev)
> return ret;
> }
>
> - priv->drm.platformdev = to_platform_device(dev);
> priv->drm.dev_private = priv;
>
> - platform_set_drvdata(priv->drm.platformdev, >drm);
> + dev_set_drvdata(dev, >drm);
>
>
On Fri, Dec 30, 2016 at 05:33:38PM +0100, Daniel Vetter wrote:
> I reported the include issue for tracepoints a while ago, but nothing
> seems to have happened. Now it bit us, since the drm_mm_print
> conversion was broken for armada. Fix them both.
Nothing's happened because I haven't had an
I'd be happy to see the
change go in if it means less work for others.
Hence, for patch 2 and 4,
Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps
701 - 800 of 2012 matches
Mail list logo
