les changed, 51 insertions(+), 46 deletions(-)
through these changes:
Russell King (3):
drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and
hdmi_regenerate_cts()
drm: bridge/dw_hdmi: protect n/cts setting with a mutex
drm: bridge/dw_hdmi: adjust n/cts setting order
David,
Please incorporate the latest TDA998x I2C driver fixes, which can be
found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-fixes
with SHA1 4a6ca1a2c2530af4611024476ba7005bf0336dfe.
This fixes the double-checksumming of the AVI infoframe which was
resulting in the checksum
On Thu, Aug 06, 2015 at 04:16:20PM +0200, Daniel Vetter wrote:
> Hi Linus,
>
> On Wed, Aug 05, 2015 at 11:14:34PM +0100, Russell King wrote:
> > Please incorporate the latest TDA998x I2C driver fixes, which can be
> > found at:
>
> Let's try this again with f
, we need no pixel repetition.
In any case, pixel repetition appears broken in dw_hdmi.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge
As mentioned in the previous commit, the dw-hdmi driver does not support
pixel doubled modes at present; it does not configure the PLL correctly
for these modes. Therefore, filter out the double-clocked modes as we
presently are unable to support them.
Signed-off-by: Russell King
---
drivers
Use a function to convert the sync pin to a bit mask for the DI_GENERAL
register, and move this out of the interlace/non-interlace path to the
common path.
Signed-off-by: Russell King
---
drivers/gpu/ipu-v3/ipu-di.c | 50 +
1 file changed, 28
splay-mode.patch
IPU-fine-tuning-the-interlace-display-timing-for-CEA.patch
This produces a working interlace format output from the IPU.
Signed-off-by: Russell King
---
drivers/gpu/ipu-v3/ipu-dc.c | 18 ---
drivers/gpu/ipu-v3/ipu-di.c | 79 +
2
of proper pixel repetition support, which is not
trivial to add due to the tabular PLL parameterisation. Hence, we
filter out these modes in our mode_valid() method.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 26 +-
1 file changed, 21 insertions
ore verbose "hdmi->sink_is_hdmi" instead.
Use the generic drm_detect_hdmi_monitor() to detect a HDMI sink.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/
Only enable audio support if the sink supports audio in some form, as
defined via its EDID. We discover this capability using the generic
drm_detect_monitor_audio() function.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 12 +---
1 file changed, 9 insertions(+), 3
enable() step. This is duplicated work - we can avoid the
setup in mode_set() and just do it in the enable() stage. This
simplifies the code a little.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge
6 hardware.
Rename the function to dw_hdmi_phy_enable_powerdown() to reflect the
documentation, make it take a bool for the 'enable' argument, and invert
the value to be written.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 10 +-
1 file changed, 5 insert
, so disable them in this circumstance.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 51
1 file changed, 47 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index
of this change is that a sink deasserting the HPD
signal to cause a re-read of the EDID data will not cause the bridge
to immediately disable the video signal.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 124 ---
1 file changed, 102 insert
formats for 2 to 6 channels, which we convert to its hardware
format.
A more desirable solution would be to have this conversion in userspace,
but ALSA does not appear to allow such transformations outside of
libasound itself.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/Kconfig
: Russell King
---
drivers/gpu/drm/bridge/Kconfig | 1 +
drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c | 6 ++
drivers/gpu/drm/bridge/dw_hdmi-audio.h | 1 +
drivers/gpu/drm/bridge/dw_hdmi.c | 3 +++
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/Kconfig
status for the AV
receiver to recognise the stream, especially the sample rate bits.
"Not identified" does not work there.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi-ahb-audio.c | 59 +-
1 file changed, 57 insertions(+), 2 deletions(-)
di
With multichannel audio, we need to allow larger buffer sizes to avoid
XRUNs during playback. Push the buffer size up to 1024K, but as we
maintain two buffers, ensure that the vmalloc buffer does not exceed
the userspace buffer size.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge
There's no need to be recursive when computing the N value for the ACR
packet - we can instead calculate the multiplier prior to our switch()
based lookup, and multiply the N value appropriately afterwards.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c
1.001 => 25175
27.00 * 1.001 => 27027
74.25 / 1.001 => 74176
148.50 / 1.001 => 148352
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drive
.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 44
1 file changed, 18 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 5576cd7d7abb..60487bff48e3 100644
--- a/drivers/gpu
"ftdms" is not a fully accurate
value; it is rounded to a kHz value. This introduces an unnecessary
(and harmless) fractional value into the above equation for combinations
like 148.5MHz/1.001 for 44100Hz - we still calculate the correct CTS
value.
Signed-off-by: Russell King
--
through the codec dai name
"dw-hdmi-i2s-audio".
[Fixed IRQ name, MODULE_DESCRIPTION, MODULE_ALIAS in
dw-hdmi-i2s-audio.c, and platform device name in dw-hdmi.c --rmk]
Signed-off-by: Yakir Yang
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/Kconfig | 9 +
drive
ely fashion.
Signed-off-by: Russell King
---
drivers/gpu/drm/bridge/dw_hdmi.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 7b8a4e942a71..0ee188930d26 100644
--- a/driv
A future commit changes the way various vblank calls behave, which
causes drivers to break. Converting to use the drm_crtc_vblank_on/off
calls avoids this breakage.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions
.
However, if the original frame buffer is freed, then it will be leaked.
Fix this by ensuring that we take a reference on the incoming fb, but
rely on the queued work to drop that ref count.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_crtc.c | 13 +
1 file changed, 5
(-)
through these changes:
Russell King (3):
drm/armada: add IRQ support back
drm/armada: fix page_flip refcounting leak
drm/armada: convert to use vblank_on/off calls
Many thanks.
overlay on each LCD crt
- page flipping of the main scanout buffers
Included in this commit is the core driver with no output support; output
support is platform and encoder driver dependent.
Signed-off-by: Russell King
---
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm
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 resolutions.
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_510.c |1 +
drivers/gpu/drm/armada/armada_crtc.c | 244
Support importing certain dma_bufs back into gem - notably those which
are either contiguous or are our own exports which do not use
dma_map_sg().
Signed-off-by: Russell King
---
drivers/gpu/drm/armada/armada_drv.c |4 +-
drivers/gpu/drm/armada/armada_fb.c |6 +++
drivers/gpu/drm
On Thu, Aug 26, 2021 at 02:10:05PM +0200, Michael Walle wrote:
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(40);
> + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
Please use dma_coerce_mask_and_coherent() here instead.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/p
On Thu, Aug 26, 2021 at 02:10:06PM +0200, Michael Walle wrote:
> - pdev->dev.coherent_dma_mask = DMA_BIT_MASK(40);
> - pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> + /*
> + * PTA and MTLB can have 40 bit base addresses, but
> + * unfortunately, an entry in the MTLB can
On Sun, Oct 24, 2021 at 12:48:31AM +0800, jason-jh.lin wrote:
> Remove the error message when gce clk is defer.
>
> Signed-off-by: jason-jh.lin
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mail
be claimed, or (preferred) be claimed
when the master gets the bind call.
However, I think the i915 bits are more complex than that simple view,
so putting the component stuff inside its own devres group and closing
it at the end of try_to_bring_up_master() makes sense.
Acked-by: Russell King (Oracle)
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Thu, Oct 28, 2021 at 08:04:48PM -0500, Rob Herring wrote:
> On Thu, Oct 21, 2021 at 03:18:53PM +0200, Geert Uytterhoeven wrote:
> > +properties:
> > + port@0:
> > +type: object
> > +description: FIXME
>
> Looks like the input from the example
>
> > +
> > + port@1:
On Fri, Oct 29, 2021 at 10:28:22AM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> Thanks for your comments!
>
> No, you can still use port:
>
> +oneOf:
> + - required:
> + - port
> + - required:
> + - ports
>
> When using ports, no further requirements are set, but perhaps port@
On Fri, Oct 29, 2021 at 11:40:26AM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Fri, Oct 29, 2021 at 11:33 AM Russell King (Oracle)
> wrote:
> > On Fri, Oct 29, 2021 at 10:28:22AM +0200, Geert Uytterhoeven wrote:
> > > No, you can still use port:
> > &g
On Mon, Jun 06, 2022 at 06:14:36PM +0100, Mark Brown wrote:
> The tda9950 driver prints an error message if it is instantiated without
> an interrupt being available since the device is non-functional in that
> case. Unfortunately due to packaging of tda9950 with tda998x series devices
> the tda998
Hi,
On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote:
> diff --git a/arch/arm/mach-hpe/Makefile b/arch/arm/mach-hpe/Makefile
> new file mode 100644
> index ..8b0a91234df4
> --- /dev/null
> +++ b/arch/arm/mach-hpe/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_ARCH_HPE_GXP
On Fri, Feb 04, 2022 at 04:18:24AM -0800, Joe Perches wrote:
> On Fri, 2022-02-04 at 12:05 +0000, Russell King (Oracle) wrote:
> > On Wed, Feb 02, 2022 at 10:52:50AM -0600, nick.hawk...@hpe.com wrote:
> > > + if (readb_relaxed(timer->control) & MASK_TCS_TC) {
>
On Sat, May 28, 2022 at 11:08:48AM -0700, Linus Torvalds wrote:
> This smells like a compiler bug triggered by "there's a 16-bit member
> field in that gtf2 structure, and despite it being packed and aligned
> to 1, we somehow still align the size to 2".
It's an age old thing, it's no compiler bug
On Mon, May 30, 2022 at 12:33:17PM +0300, Jani Nikula wrote:
> On Mon, 30 May 2022, Jani Nikula wrote:
> > On Sat, 28 May 2022, Linus Torvalds wrote:
> >> On Sat, May 28, 2022 at 11:59 AM Arnd Bergmann wrote:
> >>>
> >>> It's CONFIG_ARM_AEABI, which is normally set everywhere. Without this
> >>>
On Mon, May 30, 2022 at 02:43:45PM +0200, Arnd Bergmann wrote:
> Overall I'm not that worried because the only machines running OABI
> kernels would be on really old hardware that runs a limited set of
> driver code.
... and from what I remember, none of them care about EDID anyway.
--
RMK's Pat
On Mon, May 30, 2022 at 03:35:28PM +0200, Arnd Bergmann wrote:
> The annotations for edid are completely correct and necessary. However
> other driver authors just slap __packed annotations on any structure
> even if the layout is not fixed at all like:
>
> struct my_driver_priv {
>struct
Hi,
I don't mean to discourge test systems, but looking at this, I just go
"meh" and delete it - it doesn't seem to contain obviously useful
information. One has to read every damn line to see if there's something
of relevence, which I for one am not going to do.
Is there some kind of improvement
On Mon, Nov 21, 2022 at 04:43:14PM +0100, Geert Uytterhoeven wrote:
> As ffs() returns one more than the index of the first bit set (zero
> means no bits set), the color key mode value is shifted one position too
> much.
>
> Fix this by using FIELD_GET() instead.
Reviewed-b
t; drivers/gpu/drm/i2c/tda998x_drv.c | 2 ++
> include/sound/hdmi-codec.h| 4
> sound/soc/codecs/hdmi-codec.c | 30 +-
> 3 files changed, 31 insertions(+), 5 deletions(-)
Looks sane.
Reviewed-by: Russell King (Oracle)
Thanks.
--
RMK'
On Wed, Jun 07, 2023 at 02:58:41PM +0200, Lucas Stach wrote:
> Module level clock gating and the pulse eater might interfere with
> the GPU reset, as they both have the potential to stop the clock
> and thus reset propagation to parts of the GPU.
>
> Signed-off-by: Lucas Stach
> ---
> I'm not awa
RM's fbdev helpers
> > are mere wrappers around the fbdev code.
> >
> > By using fbdev helpers directly within each DRM fbdev emulation,
> > we can eventually remove DRM's wrapper functions entirely.
> >
> > v2:
> > * use FB_IO_
On Mon, May 22, 2023 at 03:53:50PM +, Azeem Shaikh wrote:
> strlcpy() reads the entire source buffer first.
> This read may exceed the destination size limit.
> This is both inefficient and can lead to linear read
> overflows if a source string is not NUL-terminated [1].
> In an effort to remov
On Fri, Jul 07, 2023 at 11:52:23AM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The list of dependencies here is phrased as an opt-out, but this is missing
> a lot of architectures that don't actually support VGA consoles, and some
> of the entries are stale:
>
> - powerpc used to supp
On Wed, Jul 12, 2023 at 11:46:14AM +0200, Uwe Kleine-König wrote:
> Prepare dropping the alias "dev" for struct drm_crtc::drm_dev. "drm_dev"
> is the better name as "dev" is usually a struct device pointer.
>
> No semantic changes.
>
> Signed-off-
On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly pow
On Mon, Sep 04, 2023 at 09:36:10AM +0200, Maxime Ripard wrote:
> On Sun, Sep 03, 2023 at 04:53:42PM +0100, Russell King (Oracle) wrote:
> > On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> > > Based on grepping through the source code this driver appears to
On Fri, Sep 01, 2023 at 04:41:12PM -0700, Douglas Anderson wrote:
> Based on grepping through the source code this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown
> time. Among other things, this means that if a panel is in use that it
> won't be cleanly pow
On Wed, Sep 20, 2023 at 11:03:32AM -0700, Doug Anderson wrote:
> Maxime,
>
> On Wed, Sep 13, 2023 at 8:34 AM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Sep 5, 2023 at 7:23 AM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > &
On Thu, Mar 28, 2024 at 12:06:56PM +, Naveen Mamindlapalli wrote:
> > diff --git a/drivers/net/ethernet/ti/k3-cppi-desc-pool.c
> > b/drivers/net/ethernet/ti/k3-
> > cppi-desc-pool.c
> > index 05cc7aab1ec8..fe8203c05731 100644
> > --- a/drivers/net/ethernet/ti/k3-cppi-desc-pool.c
> > +++ b/driv
On Fri, Oct 04, 2024 at 12:12:36AM +0800, clingfei wrote:
> When register_framebuffer failed, it jumps out_fb_dealloc_cmap without
> calling unregister_framebuffer, which may cause potential memory leak.
This looks completely wrong. If register_framebuffer() fails, then the
work that register_fram
On Tue, Feb 18, 2025 at 03:23:29PM +0100, Thomas Zimmermann wrote:
> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and
> buffer size. No alignment required.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Russell King
armada_pitch() does have some special alignment
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's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Fri, Apr 22, 2016 at 12:03:54AM +0100, Emil Velikov wrote:
> Cc: Lucas Stach
> Cc: Russell King
Acked-by: Russell King
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
a
On Fri, Apr 22, 2016 at 12:03:55AM +0100, Emil Velikov wrote:
> Cc: Russell King
Acked-by: Russell King
Thanks.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Wed, Apr 27, 2016 at 02:39:21PM +0200, Lucas Stach wrote:
> +static int etnaviv_gem_userptr_mmap_obj(struct etnaviv_gem_object
> *etnaviv_obj,
> + struct vm_area_struct *vma)
> +{
> + return -EPERM;
> +}
EPERM The prot argument asks for PROT_EXEC but the mapped area bel
On Tue, Apr 26, 2016 at 07:29:44PM +0200, Daniel Vetter wrote:
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Russell King
Acked-by: Russell King
Thanks Daniel.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: cur
On Tue, Apr 26, 2016 at 07:29:49PM +0200, Daniel Vetter wrote:
> No dev->struct_mutex anywhere to be seen.
>
> Cc: Christian Gmeiner
> Cc: Russell King
Acked-by: Russell King
Thanks Daniel.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC b
On Wed, Apr 27, 2016 at 02:38:18PM +0200, Lucas Stach wrote:
> If the MMU map fails caused by an unaligned SG entry, the unmap path
> is called to undo all already setup SG mappings. When encountering the
> unaligned SG the unmap path hangs the kernel with a BUG(), while the
> error is recoverable
On Wed, Apr 27, 2016 at 02:39:20PM +0200, Lucas Stach wrote:
> This function will be changed to be called indirectly and this
> prototype change brings it in line with all the other indirect
> object calls.
Christian prefers passing around struct drm_gem_object rather than
the etnaviv_gem_object.
On Wed, Apr 27, 2016 at 10:45:54PM +0100, Emil Velikov wrote:
> On 27 April 2016 at 10:47, Russell King - ARM Linux
> wrote:
> > On Thu, Apr 21, 2016 at 09:17:13PM +0100, Emil Velikov wrote:
> >> Dave Airlie pointed out that "polluting" the headers in a manner as s
On Thu, Apr 28, 2016 at 04:04:58PM +0200, Lucas Stach wrote:
> The observation was that the common code in iommu_map() rightfully
> rejected to map things, as mapping something unaligned to the page size
> is totally bogus.
Shouldn't iommu_map() detect this?
/*
* both the virtual
On Fri, Jun 24, 2016 at 11:40:44AM +0900, Kuninori Morimoto wrote:
> +static int snd_dw_hdmi_probe(struct platform_device *pdev)
> +{
> + struct dw_hdmi_i2s_audio_data *audio = pdev->dev.platform_data;
> + struct platform_device_info pdevinfo;
> + struct hdmi_codec_pdata pdata;
> +
> +
On Tue, Aug 02, 2016 at 03:05:07PM +0300, Jyri Sarha wrote:
> @@ -787,19 +792,13 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_CTS);
>
> /* Write the channel status */
> - buf[0] = IEC958_AES0_CON_NOT_COPYRIGHT;
> - bu
On Tue, Jul 12, 2016 at 12:13:52PM +0200, Daniel Vetter wrote:
> Might be better to just do a request_firmware on driver load, and
> simply proceed if it's not there.
That is almost never a good idea - if the driver is built-in, then
the request_firmware call happens before the real rootfs is moun
On Thu, Aug 04, 2016 at 11:44:50AM +0100, Jose Abreu wrote:
> Currently ISCR and ACP packets are not being sent causing
> HDMI compliance tests like CTS 7-19 HDMI 1.4b to fail.
Hmm. Reading the HDMI specifications (v1.3, being the publically
available one), the specification does _not_ say that a
On Thu, Aug 04, 2016 at 11:44:51AM +0100, Jose Abreu wrote:
> When running HDMI compliance tests we noticed that sometimes
> the edid changes but the get_modes() function is not called
> so the edid is not updated. Moving the edid reading to the
> detect() callback ensures that the edid is correctl
On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote:
> + memcpy(audio.status, params->iec.status,
> +min(sizeof(audio.status), sizeof(params->iec.status)));
As mentioned in the other patch, the audio status does not directly
correspond with the AES bytes, so this ends up cau
On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote:
> Hi Russell,
>
> I am not sure if this is a bug in DRM or a bad implementation of
> dw-hdmi. I've seen at least two more drivers that do the edid
> reading at the .detect() callback: nouveau and gma500. This is
> noticeable if while sendi
On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote:
> Hmm, I am not debugging it right now but I remember that
> drm_fb_helper_probe_connector_modes() was not being called at the
> time I set the new EDID but only after I stopped sending video (I
> was using modetest).
Please investigate -
On Thu, Aug 04, 2016 at 06:13:18PM +0100, Jose Abreu wrote:
> Hi Russell,
>
> So, I didn't use framebuffer console but used X instead and it is
> working as it should. I think we can drop this patch. I am now
> making interoperability with DVI and I am facing the following
> scenario:
> - I st
On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote:
> On 08/04/16 17:07, Russell King - ARM Linux wrote:
> > On Tue, Aug 02, 2016 at 03:05:08PM +0300, Jyri Sarha wrote:
> >> + priv->audio_pdev = platform_device_register_data(
> >> + dev, HDMI_CODEC
On Fri, Aug 05, 2016 at 06:59:08PM +0100, Mark Brown wrote:
> On Fri, Aug 05, 2016 at 06:04:50PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote:
>
> > > We do have some stuff in there in order to handle MFDs - they&#
On Tue, Aug 02, 2016 at 03:05:07PM +0300, Jyri Sarha wrote:
> @@ -41,7 +41,7 @@ struct tda998x_priv {
> u8 vip_cntrl_0;
> u8 vip_cntrl_1;
> u8 vip_cntrl_2;
> - struct tda998x_encoder_params params;
> + struct tda998x_audio_params audio_params;
...
> @@ -820,7 +819,7 @@ sta
On Fri, Aug 05, 2016 at 05:59:59PM +0100, Mark Brown wrote:
> On Fri, Aug 05, 2016 at 05:48:45PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Aug 05, 2016 at 12:02:39PM +0300, Jyri Sarha wrote:
>
> > > That may be a problem. The ASoC card device tree binding current loo
On Tue, Aug 02, 2016 at 03:05:07PM +0300, Jyri Sarha wrote:
> @@ -787,19 +792,13 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> reg_clear(priv, REG_AIP_CNTRL_0, AIP_CNTRL_0_RST_CTS);
>
> /* Write the channel status */
> - buf[0] = IEC958_AES0_CON_NOT_COPYRIGHT;
> - bu
rkey wrote:
> > > > Hi Russell,
> > > >
> > > > On Mon, Jul 25, 2016 at 01:25:04PM +0100, Russell King - ARM Linux
> > > > wrote:
> > > > > On Mon, Jul 25, 2016 at 11:55:48AM +0100, Brian Starkey wrote:
> > > > > > The c
On Thu, Aug 11, 2016 at 03:54:03PM +0800, Mark Yao wrote:
> hdmi->disabled maybe not match to the real hardware status.
>
> ->dw_hdmi_bridge_enable()
> hdmi->disabled = false;
> -->dw_hdmi_update_power()
>if (hdmi->rxsense)
>force = DRM_FORCE_ON;
>else
>force = DRM_FORCE_
| 2 +-
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +--
For both of these,
Acked-by: Russell King
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
On Fri, Aug 12, 2016 at 05:53:17PM +0200, Hans Verkuil wrote:
> There are three possible 'states' of a CEC adapter w.r.t. logical addresses:
>
> 1) There is no physical address or no logical addresses have been set
> by the application (CEC_ADAP_S_LOG_ADDRS): in that case the device
> will not par
On Sat, Aug 13, 2016 at 11:11:54AM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 04, 2016 at 03:40:32PM +0800, Liu Ying wrote:
> > Use the drm_plane_helper_update/disable() and drm_helper_crtc_mode_set()
> > transitional atomic helpers. The crtc->mode_set_nofb callback is
This series adds CEC drivers for the dw-hdmi and TDA9950 devices.
dw-hdmi integrates a CEC engine in the same device as the video
and audio blocks, and so shares the IO space and IRQ with the
main video driver.
The TDA9950 is not only a separate CEC device in its own right,
but can also be found
On Fri, Aug 12, 2016 at 04:25:02PM +0200, Hans Verkuil wrote:
> On 08/12/2016 04:15 PM, Russell King wrote:
> >Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC
>
> That's Verkuil :-)
Oops, sorry about that.
> BTW, since cec is part of the media su
On Fri, Aug 12, 2016 at 04:38:04PM +0200, Hans Verkuil wrote:
> On 08/12/2016 04:15 PM, Russell King wrote:
> >Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
> >The TDA9950 contains a command processor which handles retransmissions
> >and the low lev
On Fri, Aug 12, 2016 at 05:16:41PM +0200, Hans Verkuil wrote:
> On 08/12/2016 04:38 PM, Hans Verkuil wrote:
> >On 08/12/2016 04:15 PM, Russell King wrote:
> >>Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
> >>The TDA9950 contains a comm
On Mon, Jul 04, 2016 at 03:40:32PM +0800, Liu Ying wrote:
> Use the drm_plane_helper_update/disable() and drm_helper_crtc_mode_set()
> transitional atomic helpers. The crtc->mode_set_nofb callback is added
> so that the primary plane is no longer tied to the CRTC. Check/update
> logics are separa
On Sat, Aug 13, 2016 at 11:45:31AM +0100, Russell King - ARM Linux wrote:
> On Sat, Aug 13, 2016 at 11:11:54AM +0100, Russell King - ARM Linux wrote:
> > On Mon, Jul 04, 2016 at 03:40:32PM +0800, Liu Ying wrote:
> > > Use the drm_plane_helper_update/disable() and drm_he
Okay, this is what I've ended up with - I'm not sure whether it's
correct or not, but this dirty patch allows the full series to be
applied and still have working userspace.
I still need to undo all the reverts I have touching imx-drm between
patch 10 of this set and 4.8-rc1...
diff --git a/drive
On Sat, Aug 13, 2016 at 03:09:10PM +0100, Russell King - ARM Linux wrote:
> Okay, this is what I've ended up with - I'm not sure whether it's
> correct or not, but this dirty patch allows the full series to be
> applied and still have working userspace.
>
> I still
On Wed, Aug 17, 2016 at 10:33:10AM +0100, Jose Abreu wrote:
> Hi Russell,
>
> When using driver dw-hdmi in any other colorspace than RGB the
> Y1, Y0 and YCC values are not correct. I confirmed in databook
> that these registers are being written to the wrong offset (per
> my databook they should
On Wed, Aug 17, 2016 at 12:37:27PM +0100, Jose Abreu wrote:
> Hi Russell,
>
>
> On 17-08-2016 12:21, Russell King - ARM Linux wrote:
> > On Wed, Aug 17, 2016 at 10:33:10AM +0100, Jose Abreu wrote:
> >> Hi Russell,
> >>
> >> When using driver dw-hdmi
put_device() coupled with
> of_find_i2c_adapter_by_node() was missing on error path of
> dw_hdmi_bind(), added i2c_put_adapter() there along with the change.
I *guess* this is the right thing, but it would be nice to see the
results with the patch applied in the commit description. Nevertheles
minha
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
Acked-by: Russell King
Thanks.
> ---
> drivers/gpu/drm/bridge/dw-hdmi.c | 7 ---
> 1 file changed, 4 insertions(+), 3
601 - 700 of 2033 matches
Mail list logo
