On Fri, Aug 26, 2016 at 05:53:38PM +0200, Lucas Stach wrote:
> Sorry, please ignore the FEC patches. Those are test patches still
> residing in my to-send folder. Sorry for the noise.
This patch actually looks correct: you are indeed correct that the
driver can end up with a packet sitting waiting
On Fri, Aug 26, 2016 at 05:49:54PM +0200, Lucas Stach wrote:
> The devicetree documentation states that those are required properties,
> so the driver should refuse to probe if those are absent to be
> consistent. This will also allow to drop some error checking from the
> clock enable/disable path
On Mon, Aug 29, 2016 at 10:17:04AM +0100, Jose Abreu wrote:
> Colorspace and scan information values were being written in wrong
> offsets. This patch corrects this and writes the values at the
> offsets specified in the databook.
>
> Signed-off-by: Jose Abreu
> Acked-by: Russel King
That's "Ru
On Mon, Aug 29, 2016 at 12:47:20PM +0200, Lucas Stach wrote:
> Core, bus and shader are all module input clocks. If the SoC integration
> provides the same clock for all inputs, the DT should reflect this by
> supplying the same clock for all 3 inputs.
You're making an assertion that we don't know
On Mon, Aug 29, 2016 at 05:41:10PM +0100, Emil Velikov wrote:
> Hi all,
>
> On 24 August 2016 at 06:46, Vladimir Zapolskiy
> wrote:
>
> > MODULE_AUTHOR("Sascha Hauer ");
> > MODULE_AUTHOR("Andy Yan ");
> > MODULE_AUTHOR("Yakir Yang ");
> > +MODULE_AUTHOR("Vladimir Zapolskiy ");
> Don't meant
On Tue, Aug 23, 2016 at 10:05:45AM +0200, Hans Verkuil wrote:
>
>
> On 08/23/16 09:59, Russell King - ARM Linux wrote:
> > On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote:
> >> Hi Russell,
> >>
> >> On 08/12/2016 04:15 PM, Russell King wro
private data struct
> - Skip IEC958_AES2 byte when writing status bytes to registers
> - Turn AFMT-macros to enum
> - include linux/hdmi.h in drm/i2c/tda998x.h
> - "drm/i2c: tda998x: Register ASoC hdmi-codec and add audio DT binding"
> - Fix macronaming naming in dt-bindi
On Tue, Aug 23, 2016 at 10:03:03AM +0200, Hans Verkuil wrote:
> Hi Russell,
>
> On 08/12/16 16:15, Russell King wrote:
> > + ret = devm_request_threaded_irq(&pdev->dev, cec->irq,
> > + dw_hdmi_cec_hardirq,
> > + dw_hdmi_cec_thre
On Fri, Dec 02, 2016 at 01:43:28AM +0200, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The dw-hdmi driver declares a dev_type to distinguish platform specific
> changes. Replace this with a quirk field, so that the platform can
> specify the required quirks for the driver, rather than the d
On Fri, Dec 02, 2016 at 05:51:18PM +0200, Laurent Pinchart wrote:
> Hi Russell,
>
> On Friday 02 Dec 2016 14:18:08 Russell King - ARM Linux wrote:
> > On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> > > From: Kieran Bingham
> > >
> > &g
On Fri, Dec 02, 2016 at 01:43:26AM +0200, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The current code hard codes the call of hdmi_phy_configure() to be 8bpp
> and provides extraneous error checking to verify that this hardcoded
> value is correct.
>
> Simplify the passing of the data by
On Fri, Dec 02, 2016 at 05:43:43PM +0200, Laurent Pinchart wrote:
> DW_HDMI_QUIRK_FC_INVIDCONF is indeed a bad name, I'll fix that.
>
> Do you know why this function needs to write to the HDMI_FC_INVIDCONF
> register four times in the normal case, and once only for IMX6DL ?
(I don't have much ti
On Fri, Dec 02, 2016 at 11:44:54AM +0100, Lucas Stach wrote:
> The dumper is only a debugging aid so we don't want to invoke the OOM
> killer if buffer for the potentially large GPU state can't be vmalloced.
>
> Signed-off-by: Lucas Stach
Acked-by: Russell King
Thanks.
--
RMK's Patch system:
On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
> Struct mutex is here because this code is from the V3D series, with the
> in-kernel BO cache ripped out (it turns out that the CMA allocator is
> slow, and you can't just userspace cache since we have to do allocations
> within the kern
On Mon, May 18, 2015 at 03:32:21PM +0300, Vladimir Zapolskiy wrote:
> +/* HDMI_IH_I2CM_STAT0 and HDMI_IH_MUTE_I2CM_STAT0 register bits */
> +#define HDMI_IH_I2CM_STAT0_ERROR BIT(0)
> +#define HDMI_IH_I2CM_STAT0_DONE BIT(1)
> +
> +/* HDMI_I2CM_OPERATION register bits
On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
> +static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> +{
> + struct hdmi_codec_priv *hcp = s
On Fri, Aug 14, 2015 at 12:30:44PM +0300, Jyri Sarha wrote:
> +static int tda998x_write_aif(struct tda998x_priv *priv,
> + struct hdmi_audio_infoframe *cea)
> +{
> + uint8_t buf[HDMI_INFOFRAME_SIZE(AUDIO)];
> + int len;
> +
> + len = hdmi_audio_infoframe_pack(ce
On Wed, Aug 12, 2015 at 05:00:34PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Non-legacy drivers should only use this API to allow per-CRTC data to be
> eventually moved into struct drm_crtc.
>
> Cc: Russell King
> Signed-off-by: Thierry Reding
What I don't like about the new API
On Tue, Aug 18, 2015 at 10:26:32AM +0200, Hans Verkuil wrote:
> + /* Part 2: Initialize and register the character device */
> + cdev_init(&cecdev->cdev, &cec_devnode_fops);
> + cecdev->cdev.owner = owner;
> +
> + ret = cdev_add(&cecdev->cdev, MKDEV(MAJOR(cec_dev_t), cecdev->minor),
On Mon, Aug 10, 2015 at 02:21:36PM +0200, Thierry Reding wrote:
> On Sat, Aug 08, 2015 at 05:02:51PM +0100, Russell King - ARM Linux wrote:
> > This sub-series is a mixture of development:
> >
> > * Removing the incorrect pixel repetition configuration code
> > * Pre
On Thu, Aug 27, 2015 at 10:39:12AM +0200, Philipp Zabel wrote:
> Hi Russell,
>
> Am Samstag, den 08.08.2015, 17:03 +0100 schrieb Russell King:
> > The support for interlaced video modes seems to be broken; we don't use
> > anything other than the vtotal/htotal from the timing information to
> > de
On Tue, Aug 25, 2015 at 04:21:51PM +0200, Thierry Reding wrote:
> You cited code from dw_hdmi.c earlier, it looks like it might be correct
> even though it doesn't cite a reference for why this was done. Perhaps
> someone on this thread, or someone involved with dw_hdmi can answer
> where that code
On Sun, Aug 23, 2015 at 06:23:14PM -0500, Rob Herring wrote:
> On Wed, Aug 19, 2015 at 9:50 AM, Yakir Yang wrote:
> > + -analogix,color-depth:
> > + number of bits per colour component.
> > + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
>
> This s
On Tue, Aug 25, 2015 at 11:12:48AM +0200, Thierry Reding wrote:
> On Mon, Aug 24, 2015 at 09:48:27AM -0500, Rob Herring wrote:
> > It goes beyond bindings IMO. The use of the component framework or not
> > has been at the whim of driver writers as well. It is either used or
> > private APIs are cre
On Tue, Aug 25, 2015 at 12:40:01PM +0200, Thierry Reding wrote:
> On Tue, Aug 25, 2015 at 10:29:39AM +0100, Russell King - ARM Linux wrote:
> > Now, what happens when some other DRM driver wants to use the tda998x
> > driver, and its bindings are not compatible with the co
On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote:
> @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc
> *crtc, int x, int y)
> if (!dcrtc->variant->has_spu_adv_reg)
> return -EFAULT;
>
> - mutex_lock(&dev->struct_mutex);
> dcrt
On Thu, Dec 03, 2015 at 10:40:45AM +, Liviu Dudau wrote:
> This series depends on Sudeep Holla's SCPI driver (now in mainline) and on
> the tda998x patches that have been queued on Russell's patch system here [1].
Now merged into my tree.
Can I ask a fairly obvious question...
> drivers/gpu
On Fri, Dec 04, 2015 at 10:29:56AM -0600, Rob Herring wrote:
> On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > +Vivante GPU core devices
> > +
> > +
> > +Required properties:
> > +- compatible: Should be "vivante,gc"
>
> This should at least have the specific c
On Fri, Dec 04, 2015 at 05:41:45PM +0100, Lucas Stach wrote:
> Am Freitag, den 04.12.2015, 10:29 -0600 schrieb Rob Herring:
> > On Fri, Dec 04, 2015 at 02:59:54PM +0100, Lucas Stach wrote:
> > > +gpu-subsystem {
> > > + compatible = "fsl,imx-gpu-subsystem";
> > > + cores = <&gpu_2d>, <&gpu_3d>;
> >
tih4xx.txt
>
> +DRM DRIVERS FOR VIVANTE GPU IP
> +M: Lucas Stach
> +L: dri-devel at lists.freedesktop.org
> +S: Maintained
> +F: drivers/gpu/drm/etnaviv
> +F: Documentation/devicetree/bindings/display/etnaviv
> +
> DSBR100 USB FM RADIO DRIVER
> M
On Fri, Dec 04, 2015 at 12:08:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
> wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach
> >
> > Acked-by: Russell King
>
On Fri, Dec 04, 2015 at 06:26:38PM +0100, Marc Kleine-Budde wrote:
> On 12/04/2015 06:07 PM, Russell King - ARM Linux wrote:
> > On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
> >> Signed-off-by: Lucas Stach
> >
> > Acked-by: Russell King
> &g
On Fri, Dec 04, 2015 at 11:33:22AM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach
> wrote:
> > I'm aware of that, but I don't see much value in kicking this discussion
> > around for every DRM driver submission. This is the binding that has
> > emerged from a lengthy dis
On Fri, Dec 04, 2015 at 02:19:42PM -0600, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 11:56 AM, Lucas Stach
> wrote:
> > Am Freitag, den 04.12.2015, 11:33 -0600 schrieb Rob Herring:
> >> On Fri, Dec 4, 2015 at 10:41 AM, Lucas Stach
> >> wrote:
> >> > Am Freitag, den 04.12.2015, 10:29 -0600 schr
On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
> wrote:
> > Moreover, DRI3 is not yet available for Gallium, so if we're talking
> > about Xorg, then functional DRI2 is a requirement, and that _need
On Sat, Dec 05, 2015 at 11:12:08AM +0100, Daniel Vetter wrote:
> Given that I think the current etnaviv is a sound architecture. And I'm
> not saying that because drm requires everything to be smashed into one
> driver, since that's simple not the case.
There's other reasons as well, mostly from t
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
> I see where you are going here and I appreciate that this discussion
> isn't a exercise in bikeshed, but based on technical facts.
It would be nice (for the sake of this discussion not getting heated)
if Rob could show that he's been r
On Sat, Dec 05, 2015 at 12:26:19PM +0100, Lucas Stach wrote:
> I already sketched up the alternative of having the master driver scan
> the DT for matching GPU nodes at probe time and binding them together
> into a single device. But given that we end up with one master device
> anyways, do you rea
On Sat, Dec 05, 2015 at 04:35:11PM +0100, Daniel Vetter wrote:
> In theory dma-buf could keep track of who's flushed a buffer already, but
> there's no implementation of that yet. And for a generic one we'd need to
> violate the current dma api abstractions. So yeah, perf is going to tank
> until t
On Fri, Dec 04, 2015 at 03:00:04PM +0100, Lucas Stach wrote:
> This adds the device nodes for 2D, 3D and VG GPU cores.
>
> Signed-off-by: Russell King
> Signed-off-by: Lucas Stach
This should have been copied to the arm-soc people, as we'll need their
acks to keep this part of the series, or it
Given the lack of interest in these patches, I've put these into my
"for-next" branch so that they can get some exposure in linux-next.
On Mon, Nov 23, 2015 at 04:02:11PM +, Russell King - ARM Linux wrote:
> Greg,
>
> These four patches update the component helper by:
On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote:
> On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote:
> > On 8 December 2015 at 08:49, Daniel Vetter
> > wrote:
> > > In my quest to remove all the drm_encoder_helper_funcs->save/restore
> > > hooks I somehow missed that thi
On Tue, Dec 20, 2016 at 03:33:48AM +0200, Laurent Pinchart wrote:
> Instead of spreading version-dependent PHY power handling code around,
> group it in two functions to power the PHY on and off and use them
> through the driver.
>
> Powering off the PHY at the beginning of the setup phase is curr
could just be to
> revert the original match-array commit (and the subsequent two fixups)
> until you can work out a fix.
I assume you haven't checked before sending out reminder emails...
it's in -rc4, and it's been in linux-next since last Thursday.
--
RMK's Patch syst
On Thu, Oct 30, 2014 at 11:01:02AM +0100, Andrzej Hajda wrote:
> On 10/29/2014 10:14 AM, Thierry Reding wrote:
> > On Wed, Oct 29, 2014 at 09:57:02AM +0100, Daniel Vetter wrote:
> >> I think we nee try_get_module for the code and kref on the actual data
> >> structures.
> >
> > Agreed, that should
Greg,
Here's two oops fixes for imx-drm, which I've had queued up for a number
of months now. Shawn posted different fixes for the same oops recently
as well.
drivers/staging/imx-drm/imx-ldb.c | 3 +++
drivers/staging/imx-drm/ipuv3-plane.c | 3 ++-
2 files changed, 5 insertions(+), 1 deleti
On Wed, Apr 01, 2015 at 12:09:38PM +0200, Heiko Stuebner wrote:
> This adds a driver for generic vga encoders like the Analog Devices adv7123
> and similar ics. These chips do not have any special configuration options
> except a powersafe gpio.
>
> An exception is added for the rcar-du driver whi
sing isn't something limited to DRM - and let's face it,
one of the biggest consumers of graphics on Linux is Android, which I'm
told is pretty much wedded to the fbdev API.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
On Wed, Apr 01, 2015 at 11:49:27AM +0300, Jyri Sarha wrote:
> Add support for an external compontised DRM encoder. The external
> encoder can be connected to tilcdc trough device tree graph binding.
> The binding document for tilcdc has been updated. The current
> implementation supports only tda99
I'm sending this series for comments, and to allow people to update
their code bases (for those who are using my AHB audio driver on
iMX6). This is really several series, and I'm not expecting this
to be ready for the upcoming merge window. That said, if anyone
wants to say that they're happy wit
On Thu, Apr 02, 2015 at 05:29:02PM +0200, Lucas Stach wrote:
> Hey all,
>
> this is the Etnaviv DRM driver for Vivante embedded GPUs. It is heavily
> influenced by the MSM driver, as can be clearly seen with the first commits.
You should be copying Greg KH for staging too.
--
FTTC broadband for
On Thu, Apr 02, 2015 at 05:30:29PM +0200, Lucas Stach wrote:
> It is legal for the userspace to pass in a command stream of a size
> aligned to 32 bit, if that is where the last user command ends. The
> kernel then needs to insert a LINK command at the end of the stream,
> which needs to be aligned
On Thu, Apr 02, 2015 at 05:30:32PM +0200, Lucas Stach wrote:
> The intention clearly was to do the same thing for WC and UC buffers,
> not for cached ones.
Err, from one of my previous commits:
staging: etnaviv: fix DMA API usage
We test for write-combine and non-cacheable mappings befor
On Thu, Apr 02, 2015 at 05:30:34PM +0200, Lucas Stach wrote:
> This provides a bit more type safety.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/staging/etnaviv/etnaviv_gem.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/etnaviv/etnaviv_gem.h
On Thu, Apr 02, 2015 at 05:30:44PM +0200, Lucas Stach wrote:
> While this isn't the case on i.MX6 a single GPU pipe can have
> multiple rendering backend states, which can be selected by the
> pipe switch command, so there is no strict mapping between the
> user "pipes" and the PIPE_2D/PIPE_3D exec
On Thu, Apr 02, 2015 at 06:29:24PM +0200, Lucas Stach wrote:
> The start of the commands must always be 64bit aligned, it's the same
> for all pipes. The size can be dword aligned if the last command in the
> stream is something like SET_STATE with a length of 2. In that case one
> needs to insert
On Mon, Sep 21, 2015 at 11:51:06AM +0200, Thierry Reding wrote:
> On Wed, Sep 16, 2015 at 01:41:38PM -0700, Douglas Anderson wrote:
> > There's a member in 'struct dw_hdmi' called cable_plugin. It's never
> > set to anything anywhere so thus is always false. There's a bit of code
> > checking it,
On Thu, Sep 24, 2015 at 06:35:31PM +0200, Thierry Reding wrote:
> This continues the pattern started in commit cc1ef118fc09 ("drm/irq:
> Make pipe unsigned and name consistent"). This is applied to the public
> APIs and driver callbacks, so pretty much all drivers need to be updated
> to match the
On Fri, Sep 25, 2015 at 01:57:15PM +0200, Lucas Stach wrote:
> There is no point in keeping backwards compatibility to older
> kernel versions in a driver destined to mainline.
You are correct, however the repository I keep is always based on the
previous non-rc kernel release, and I want it to wo
On Fri, Sep 25, 2015 at 01:57:24PM +0200, Lucas Stach wrote:
> + /* We must never runtime-PM resume holding struct_mutex */
> + if (drm && WARN_ON_ONCE(mutex_is_locked(&drm->struct_mutex)))
> + return -EDEADLK;
This actually needs dropping from the patch - and we'll rely on loc
On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> few questions/remarks
> BR,
> Arnaud
>
> >+static void hdmi_codec_abort(struct device *dev)
> >+{
> >+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> >+
> >+dev_dbg(dev, "%s()\n", __func__);
> >+
> >+mutex_lock(&
On Tue, Sep 29, 2015 at 01:07:25PM +0200, Thierry Reding wrote:
> On Fri, Sep 25, 2015 at 10:29:51AM +0200, Philipp Zabel wrote:
> > Am Montag, den 21.09.2015, 15:15 +0100 schrieb Russell King - ARM Linux:
> > > On Mon, Sep 21, 2015 at 11:51:06AM +0200, Thierry Reding wrote:
>
Here are my queued changes for the Armada DRM driver, for the upcoming
4.4 merge window.
These changes are about updating the driver to some of the more recent
DRM APIs, and removing the non-component support now that has
stabilised. This results in all of armada_output and armada_slave
being rem
ious patch "Fix EDID read timeout on HDMI connect"
to be much more reliable: an attempt to read the EDID may come in
while we're delaying the HPD detect event, violating the critical
pause.
* Use Linux types rather than C99 types.
* Handle all outstanding interrupts, r
On Tue, Apr 19, 2016 at 01:34:23PM -0500, Dennis Gilmore wrote:
> Hi All,
>
> on all of my i.MX6 systems imx-ipuv3-crtc ius not getting automatically
> loaded. Everything is built as a module
>
> CONFIG_DRM_IMX=m
> CONFIG_DRM_IMX_FB_HELPER=m
> CONFIG_DRM_IMX_HDMI=m
> CONFIG_DRM_IMX_IPUV3=m
> CO
On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joarder wrote:
> > These are the approaches which could have been taken to handle
> > this scenario -
> >
> > * Replace vm_insert_page with vmf_insert_page and then write few
> >
On Thu, Oct 04, 2018 at 05:45:13PM +0530, Souptick Joarder wrote:
> On Thu, Oct 4, 2018 at 3:45 AM Russell King - ARM Linux
> wrote:
> >
> > On Wed, Oct 03, 2018 at 01:00:03PM -0700, Matthew Wilcox wrote:
> > > On Thu, Oct 04, 2018 at 12:28:54AM +0530, Souptick Joard
On Tue, Oct 09, 2018 at 01:56:04PM -0400, Ilia Mirkin wrote:
> On Tue, Oct 9, 2018 at 1:40 PM Laurent Pinchart
> wrote:
> > commit 9c305eb442f3b371fc722ade827bbf673514123e
> > Author: Neil Armstrong
> > Date: Fri Feb 23 12:44:37 2018 +0100
> >
> > drm: bridge: dw-hdmi: Fix overflow workarou
On Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote:
> In situations where a component fails to bind, a previously
> successfully bound component might already registered itself
> with the DRM framework (e.g. an encoder). When the master
> component then calls drm_mode_config_cleanup, we e
On Wed, Oct 10, 2018 at 01:02:16PM +0200, Stefan Agner wrote:
> [adding Lucas]
>
> On 10.10.2018 12:38, Russell King - ARM Linux wrote:
> > On Tue, Oct 09, 2018 at 11:30:49PM +0200, Stefan Agner wrote:
> >> In situations where a component fails to bind, a previously
On Wed, Oct 24, 2018 at 07:35:46AM +, Corentin Labbe wrote:
> This patchset adds a new set of functions which are open-coded in lot of
> place.
> Basicly the pattern is always the same, "read, modify a bit, write"
> some driver and the powerpc arch already have thoses pattern them as
> functio
On Thu, Oct 25, 2018 at 12:17:11PM -0400, thesve...@gmail.com wrote:
> From: Sven Van Asbroeck
>
> We used an oscilloscope to observe the actual polarity of the
> DI's pixel clock, and saw the following:
>
> DI_GENERAL bit 17 is SET:
> pixel data is stable on the pixel clock's FALLING edge
On Fri, May 18, 2018 at 11:01:55AM -0700, Kees Cook wrote:
> On Tue, Apr 10, 2018 at 6:03 PM, Laura Abbott wrote:
> > There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> > turn on -Wvla. The vla in reg_write_range is based on the length of data
> > passed. The one use of a
On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
> On 24/04/18 13:14, Peter Rosin wrote:
> > On 2018-04-24 10:08, Russell King - ARM Linux wrote:
> >> On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> >>> On 2018-04-23 18:08, Russell King -
On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> On 2018-04-23 18:08, Russell King - ARM Linux wrote:
> > On Mon, Apr 23, 2018 at 09:23:00AM +0200, Peter Rosin wrote:
> >> static int tda998x_remove(struct i2c_client *client)
> >> {
> >> - comp
On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote:
> On 24/04/18 20:06, Russell King - ARM Linux wrote:
> > On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
> >> On 24/04/18 13:14, Peter Rosin wrote:
> >>> On 2018-04-24 10:08, Russell King - ARM L
On Tue, Apr 24, 2018 at 11:29:42AM +0200, Hans Verkuil wrote:
> On 04/09/18 14:15, Russell King - ARM Linux wrote:
> > Hi,
> >
> > This patch series adds CEC support to the DRM TDA998x driver. The
> > TDA998x family of devices integrate a TDA9950 CEC at a separate I2
On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote:
> [discussion about this patch, which should have been cced to the iommu
> and linux-arm-kernel lists, but wasn't:
> https://www.spinics.net/lists/dri-devel/msg173630.html]
>
> On Wed, Apr 25, 2018 at 09:41
On Wed, Apr 25, 2018 at 12:10:51PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The ARM_DMA_USE_IOMMU Kconfig option has side-effects that drivers can
> not opt into but have to explicitly opt out of. This can lead to subtle
> bugs that are difficult to track down and not immediately o
On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
> > - dma api hides the cache flushing requirements from us. GPUs love
> > non-snooped access, and worse give userspace control over that. We want
> > a strict sep
On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
> On arm that doesn't work. The iommu api seems like a good fit, except
> the dma-api tends to get in the way a bit (drm/msm apparently has
> similar problems like tegra), and if you need contiguous memory
> dma_alloc_coherent is the on
(While there's a rain shower...)
On Thu, Apr 26, 2018 at 02:09:42AM -0700, Christoph Hellwig wrote:
> synopsis:
>
> drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c:pdevinfo.dma_mask
> = DMA_BIT_MASK(32);
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: pdevinfo.dma_mask =
On Thu, May 10, 2018 at 08:34:48PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler in
> struct vm_operations_struct. For now, this is just
> documenting that the function returns a VM_FAULT
> value rather than an errno. Once all instances are
> converted, vm_fault_
On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
> Hi Russell,
>
> On 30 March 2018 at 15:11, Daniel Stone wrote:
> > Since drm_framebuffer can now store GEM objects directly, place them
> > there rather than in our own subclass. As this makes the framebuffer
> > create_handle and de
On Mon, Nov 12, 2018 at 04:50:37PM +, Peter Rosin wrote:
> On 2018-08-02 08:06, Peter Rosin wrote:
> > On 2018-08-01 11:35, Russell King - ARM Linux wrote:
> >> On Wed, Aug 01, 2018 at 11:01:12AM +0200, Peter Rosin wrote:
> >>> I don't think it's a prob
On Tue, Nov 13, 2018 at 01:28:40PM +, Peter Rosin wrote:
> Hi!
>
> I'm wondering about some programming details regarding the TDA998x
> driver...
>
> The bindings documentation [1] state that one should fill in the
> desired register content of the AP_ENA register. However, I cannot
> find an
On Tue, Nov 13, 2018 at 06:12:37PM +, Peter Rosin wrote:
> On 2018-11-13 18:24, Russell King - ARM Linux wrote:
> > On Tue, Nov 13, 2018 at 01:28:40PM +, Peter Rosin wrote:
> >> Hi!
> >>
> >> I'm wondering about some programming details regarding
On Tue, Nov 13, 2018 at 08:58:15PM +, Peter Rosin wrote:
> On 2018-11-13 20:09, Russell King - ARM Linux wrote:
> > On Tue, Nov 13, 2018 at 06:12:37PM +, Peter Rosin wrote:
> >> On 2018-11-13 18:24, Russell King - ARM Linux wrote:
> >>> On Tue, Nov 13, 2018 at
On Thu, Nov 15, 2018 at 10:30:34AM +0100, LABBE Corentin wrote:
> On Wed, Oct 24, 2018 at 09:57:00AM +0100, Russell King - ARM Linux wrote:
> > On Wed, Oct 24, 2018 at 07:35:46AM +, Corentin Labbe wrote:
> > > This patchset adds a new set of functions which are open-coded in
On Mon, Nov 19, 2018 at 09:19:34AM +0100, Maxime Ripard wrote:
> Hi,
>
> On Fri, Nov 16, 2018 at 07:18:29PM +0200, Priit Laes wrote:
> > From: Priit Laes
> >
> > Even though HDMI connector features hotplug detect pin (HPD), there are
> > devices that which do not support it.
>
> Which devices?
On Wed, Aug 08, 2018 at 03:09:30PM -0400, Sean Paul wrote:
> > -static const struct drm_encoder_helper_funcs tda998x_encoder_helper_funcs
> > = {
> > - .dpms = tda998x_encoder_dpms,
> > - .prepare = tda998x_encoder_prepare,
> > - .commit = tda998x_encoder_commit,
> > - .mode_set = tda998x_
On Tue, Aug 07, 2018 at 08:22:01PM +0300, Dmitry Osipenko wrote:
> + * Glossary:
> + *
> + * Destination plane:
> + * Plane to which color keying properties are applied, this planes takes
> + * the effect of color keying operation. The effect is determined by a
> + * given color keying mode.
On Fri, Aug 10, 2018 at 01:02:29PM -0400, Sean Paul wrote:
> On Fri, Aug 10, 2018 at 05:50:37PM +0100, Russell King - ARM Linux wrote:
> > Almost none of my DRM specific patches on dri-devel this time around
> > received any feedback what so ever, even after myself and David chas
On Fri, Aug 10, 2018 at 12:11:05PM -0400, Sean Paul wrote:
> On Wed, Aug 08, 2018 at 11:15:47PM +0100, Russell King - ARM Linux wrote:
> > In any case, bridges are buggy with unbinding/rebinding as I've pointed
> > out several times in the past, but TDA998x used with Armada a
On Tue, Aug 14, 2018 at 12:42:42PM +0200, Daniel Vetter wrote:
> Given your past track record of handling other contributors I think it's
> entirely understandably that people do not choose to collaborate with you
> voluntarily. Fixing that is entirely up to you though.
I do not work piecemeal. I
Hi Andrzej,
On Mon, Aug 27, 2018 at 06:15:59PM +0200, Andrzej Hajda wrote:
> On 30.07.2018 18:42, Russell King wrote:
> > static void tda998x_destroy(struct tda998x_priv *priv)
> > {
> > + drm_bridge_remove(&priv->bridge);
> > +
> > /* disable all IRQs and free the IRQ handler */
> > c
On Tue, Aug 28, 2018 at 03:25:55PM +0200, Linus Walleij wrote:
> On Tue, Aug 28, 2018 at 11:21 AM Christoph Hellwig wrote:
>
> > > + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > > + if (!dev->dev.dma_mask)
> > > + dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
> >
> >
On Tue, Aug 28, 2018 at 07:49:28PM +0200, Peter Rosin wrote:
> On 2018-07-06 14:43, Russell King - ARM Linux wrote:
> > On Fri, Jul 06, 2018 at 11:03:46AM +0100, Russell King - ARM Linux wrote:
> >> On Wed, Apr 25, 2018 at 11:01:15PM +0300, Jyri Sarha wrote:
> >>>
On Wed, Aug 29, 2018 at 07:55:21AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 28, 2018 at 03:14:14PM +0100, Russell King - ARM Linux wrote:
> > But yes, the fundamental fact is that AMBA devices don't have any
> > care about the differences between coherent and
On Thu, Aug 30, 2018 at 10:45:11AM +0200, Linus Walleij wrote:
> On Thu, Aug 30, 2018 at 10:40 AM Russell King - ARM Linux
> wrote:
>
> > Well, as I've no idea what the issue is here, I can't do anything or
> > make any suggestions. I wasn't copied o
501 - 600 of 1611 matches
Mail list logo
