[PATCH 03/18] drm/etnaviv: only check if the cmdbuf is inside the linear window on MMUv1

On Mon, Aug 22, 2016 at 01:00:57PM +0200, Lucas Stach wrote: > There is no linear window on MMUv2 and the FE can access the full 4GB > address space either directly (as long as the MMU isn't configured) or > through the MMU, once it is up. > > Signed-off-by: Lucas Stach > --- >

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

On Tue, Aug 23, 2016 at 09:21:17AM +0200, Hans Verkuil wrote: > Hi Russell, > > On 08/12/2016 04:15 PM, Russell King wrote: > > Add a CEC driver for the dw-hdmi hardware using Hans Verkil's CEC > > implementation. > > > > Signed-off-by: Russell Ki

[PATCH] drm/etnaviv: Always init gpu->memory_base

On Fri, Aug 26, 2016 at 04:25:13PM +0200, Marek Vasut wrote: > The content of gpu->memory_base should point to start of RAM, not zero. > > Signed-off-by: Marek Vasut > Cc: Lucas Stach > Cc: Christian Gmeiner > Cc: Russell King <rmk+kernel at arm.linux.org.uk> >

[PATCH 1/2] net: fec: don't ack masked interrupt events

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

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

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

[PATCH RESEND] drm: bridge/dw-hdmi: Fix colorspace and scan information registers values

l King <rmk+kernel at armlinux.org.uk> That's "Russell King" please. -- 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.

[PATCH 1/2] drm/etnaviv: fail probe if core or bus clock are absent

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

[PATCH v6] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

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

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

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

[PATCH v2 0/3] drm/i2c: tda998x ASoC hdmi-codec support + BeagleBoneBlack audio support

On Tue, Aug 09, 2016 at 10:00:03PM +0300, Jyri Sarha wrote: > Changes since first version [1] of this series: > - "drm/i2c: tda998x: Improve tda998x_configure_audio() audio related pdata" > - Change audio in tda998x pdata to audio_params to match the naming in > private data struct > -

[PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code

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(>dev, cec->irq, > > + dw_hdmi_cec_hardirq, > > +

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

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

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

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 <kieran.bingham+

[PATCH 11/22] drm: bridge: dw-hdmi: Refactor hdmi_phy_configure resolution parameter

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

[PATCH 13/22] drm: bridge: dw-hdmi: Replace device type with platform quirks

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

[PATCH] drm/etnaviv: don't invoke OOM killer from dump code

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 <rmk+kernel at

[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

On Thu, Feb 18, 2016 at 04:18:23PM +0100, Jean-Francois Moine wrote: > On Thu, 18 Feb 2016 08:35:30 -0600 > Rob Herring wrote: > > > On Wed, Feb 17, 2016 at 04:49:05PM +0200, Jyri Sarha wrote: > > > From: Jean-Francois Moine > > > > > > Two kinds of ports may be declared in a DT graph of

[PATCH v2 1/2] drm: Improve drm_of_component_probe() to correctly handle ports and remote ports.

On Mon, Feb 22, 2016 at 11:51:47AM +, Liviu Dudau wrote: > On Fri, Nov 20, 2015 at 02:22:04PM +, Liviu Dudau wrote: > > Rockchip DRM driver cannot use the same compare_of() function to > > match ports and remote ports (aka encoders) as their OF sub-trees > > look different. Add a second

[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote: > On 02/18/16 16:35, Rob Herring wrote: > >This should be implied from the port unit address. In other words, > >port at 0 is defined to be the rgb port. Now, if this is one of several > >modes for the video port, then that is a different

[PATCH RFC v5 4/8] drm/i2c: tda998x: Add support of a DT graph of ports

On Fri, Feb 26, 2016 at 12:14:44PM +0200, Jyri Sarha wrote: > On 02/26/16 02:43, Russell King - ARM Linux wrote: > >On Thu, Feb 25, 2016 at 03:42:50PM +0200, Jyri Sarha wrote: > >>On 02/18/16 16:35, Rob Herring wrote: > >>>This should be implied from the por

[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()

anks. Acked-by: Russell King <rmk+kernel at arm.linux.org.uk> Lucas, I guess you'll be picking this patch up, or shall we ask David to take it directly? -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 40

[patch] drm/etnaviv: unlock on error in etnaviv_gem_get_iova()

On Mon, Jan 04, 2016 at 03:13:22PM +0100, Lucas Stach wrote: > Am Montag, den 04.01.2016, 13:54 + schrieb Russell King - ARM > Linux: > > On Mon, Jan 04, 2016 at 04:10:24PM +0300, Dan Carpenter wrote: > > > We have to drop a lock before returning -ENOMEM here. > > &

[PATCH 0/4] Component helper updates

On Mon, Dec 07, 2015 at 03:01:43PM +, Russell King - ARM Linux wrote: > 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. These have been in for-next, and no one's reported any issues.

[alsa-devel] [PATCH 0/9] dw-hdmi audio support

On Tue, Jan 05, 2016 at 04:40:54PM +0100, Jean-Michel Hautbois wrote: > Hi Russell, > > 2015-08-27 10:42 GMT+02:00 Philipp Zabel : > > > > Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM > > Linux: > > > Following on from the previous su

[PATCH RFC 2/2] drm: sunxi: Add a basic DRM driver for Allwinner DE2

Some comments from an ARM architecture point of view. I haven't reviewed it from a DRM point of view yet. On Tue, Jan 05, 2016 at 07:40:11PM +0100, Jean-Francois Moine wrote: > +struct tcon { > + u32 gctl; > +#define TCON_GCTL_TCON_En 0x8000 > + u32 gint0; > +#define

[PATCH 3/4] drm: bridge/dw-hdmi: detect initial connector state

On Fri, Jan 08, 2016 at 10:02:06AM +0100, Philipp Zabel wrote: > Allow userspace to read the initial connector state via sysfs without > having to issue a detect manually. There is no reason to keep the state > unknown during initialization. Can you describe how it can be unknown? I've always

[PATCH 4/4] drm: bridge/dw-hdmi: use rx sense for plug detection if hpd is unreliable

On Fri, Jan 08, 2016 at 10:02:07AM +0100, Philipp Zabel wrote: > Due to the voltage divider on the HPD line, the HDMI connector on > imx6q-sabrelite doesn't reliably detect connected DVI monitors. > This patch allows to use the RX_SENSE signals as a workaround when > enabled by a boolean device

[PATCH 07/22] drm/armada: Remove NULL open/pre/postclose hooks

On Mon, Jan 11, 2016 at 10:41:01PM +0100, Daniel Vetter wrote: > The compiler will do this, but the void hits when grepping all the > hooks for a subsystem wide audit are slightly annoying. So remove them > for next time around. I'll try to remember to queue this after -rc1, though a reminder

[PATCH 03/10] drm/armada: Drop fb gamma_set/get functions

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 >

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

On Fri, May 13, 2016 at 12:33:36PM +0200, Lothar Waßmann wrote: > I'm always very suspicious when seeing code moving of_node's from > one device to another or assigning of_node's to platform devices that > weren't instantiated via DT. It's completely wrong to add an of_node to a device on the

[PATCH 13/20] drm/bridge: Add RGB to VGA bridge support

On Thu, May 26, 2016 at 10:53:30AM +0200, Maxime Ripard wrote: > Hi Laurent, > > On Mon, May 16, 2016 at 04:24:15PM +0300, Laurent Pinchart wrote: > > Hi Maxime, > > > > Thank you for the patch. > > > > On Monday 16 May 2016 14:47:13 Maxime Ripard wrote: > > > +fallback: > > > + /* > > > + *

[PATCH v2 17/29] drm: bridge: dw-hdmi: Refactor PHY power handling

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

[PATCH] component: remove device from master match list on failed add

On Mon, Feb 15, 2016 at 04:36:55PM +, Daniel Stone wrote: > Russell, > > On 12 February 2016 at 00:57, Akshay Bhat wrote: > > Daniel Stone collabora.com> writes: > >> Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8 > >> Signed-off-by: Daniel Stone collabora.com> > > > > Tested-by: Akshay

[PATCH v2] drm: bridge/dw-hdmi: Add support for DWC Phy

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

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

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

[PATCH 1/2] drm/rockchip: dw_hdmi: Call drm_encoder_cleanup() in error path

;> 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

[PATCH] drm/etnaviv: move GPU linear window to end of DMA window

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

[PATCH] drm/etnaviv: move GPU linear window to end of DMA window

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

[PATCH] drm/fb_cma_helper: Implement fb_mmap callback

On Wed, Mar 16, 2016 at 04:28:25PM +0100, Daniel Vetter wrote: > On Wed, Mar 16, 2016 at 02:57:49PM +, Robin Murphy wrote: > > In the absence of an fb_mmap callback, the fbdev code falls back to a > > naive implementation which relies upon the DMA address being the same > > as the physical

Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

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

Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

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

[PATCH v8 1/6] ALSA: pcm: add IEC958 channel status helper for hw_params

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

[PATCH 03/10] drm/armada: Drop fb gamma_set/get functions

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

[PATCH RFC v2 04/12] drm/components: add generic vga encoder driver

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

[PATCH RFC 07/11] drm/edid: add function to help find SADs

On Wed, Apr 01, 2015 at 02:47:32PM +0300, Jani Nikula wrote: > On Mon, 30 Mar 2015, Russell King <rmk+kernel at arm.linux.org.uk> wrote: > > Add a function to find the start of the SADs in the ELD. This > > complements the helper to retrieve the SAD count. > > > >

[PATCH v4 3/7] drm/tilcdc: Add support for external tda998x encoder

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

[RFC v2 0/13] dw_hdmi cleanups, audio preparation, helpers and ahb audio support

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

[PATCH RFC 000/111] Etnaviv DRM driver

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

[PATCH RFC 087/111] staging: etnaviv: align command stream size to 64 bit

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

[PATCH RFC 090/111] staging: etnaviv: fix cache cleaning for uncached SHM buffers

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

[PATCH RFC 092/111] staging: etnaviv: convert to_etnaviv_bo() to real function

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

[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state

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

[PATCH RFC 087/111] staging: etnaviv: align command stream size to 64 bit

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

[PATCH RFC v2 10/13] sound/core: add DRM ELD helper

On Sun, Apr 05, 2015 at 05:57:09PM +0200, Takashi Iwai wrote: > > diff --git a/include/sound/pcm_drm_eld.h b/include/sound/pcm_drm_eld.h > > new file mode 100644 > > index ..93357b25d2e2 > > --- /dev/null > > +++ b/include/sound/pcm_drm_eld.h > > @@ -0,0 +1,6 @@ > > +#ifndef

[PATCH RFC v2 10/13] sound/core: add DRM ELD helper

On Sun, Apr 05, 2015 at 06:46:13PM +0200, Takashi Iwai wrote: > At Sun, 5 Apr 2015 17:20:34 +0100, > Russell King - ARM Linux wrote: > > Since (afaik) ALSA has a lack of support for dynamic reconfiguration > > according to the attached device changing, the best we can do without

[PATCH RFC 003/111] staging: etnaviv: add drm driver

On Tue, Apr 07, 2015 at 11:20:10AM +0200, Lucas Stach wrote: > Am Dienstag, den 07.04.2015, 11:04 +0200 schrieb Christian Gmeiner: > > What role does GPU power management plays here? For the context switching > > it could make sense. But for the 2d core the context is so small that > > it does not

[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state

On Tue, Apr 07, 2015 at 11:05:50AM +0200, Lucas Stach wrote: > A pipe is now simply a channel to a single GPU core. If a given core is > able to execute 2d, 3d or vg state is a matter of looking at the feature > bits for this pipe. Why would we need a full blown DRM device for that? > On i.MX6 you

[PATCH RFC 102/111] staging: etnaviv: separate GPU pipes from execution state

On Tue, Apr 07, 2015 at 06:59:59PM +0200, Christian Gmeiner wrote: > Hi Lucas. > > 2015-04-07 17:29 GMT+02:00 Lucas Stach : > > And I don't get why each core needs to have a single device node. IMHO > > this is purely an implementation decision weather to have one device > > node for all cores or

[PATCH 2/6] drm/cache: Implement drm_clflush_*() for ARM

On Thu, Apr 09, 2015 at 04:34:05PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Add implementations for drm_clflush_*() on ARM by borrowing code from > the DMA mapping API implementation. Unfortunately ARM doesn't export an > API to flush caches on a page by page basis, so this

[PATCH 5/6] drm/armada: gem: Use drm_clflush_*() functions

On Thu, Apr 09, 2015 at 04:34:08PM +0200, Thierry Reding wrote: > diff --git a/drivers/gpu/drm/armada/armada_gem.c > b/drivers/gpu/drm/armada/armada_gem.c > index 580e10acaa3a..c2d4414031ab 100644 > --- a/drivers/gpu/drm/armada/armada_gem.c > +++ b/drivers/gpu/drm/armada/armada_gem.c > @@ -453,19

[PATCH] drm/imx: remove drm_mode_connector_detach_encoder harder

On Sat, Mar 15, 2014 at 12:15:49PM +0100, Daniel Vetter wrote: > Since the last time I've looked more of this stuff sprouted up. Stomp > it down again. > > Repeating the original justification for ripping this all out: There's > absolutely no need to deteach connectors before cleaning them up at

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

On Tue, Mar 18, 2014 at 08:50:30AM +0100, Lothar Wa?mann wrote: > Hi, > > Laurent Pinchart wrote: > > Hi Lothar, > > > > On Monday 17 March 2014 16:14:36 Lothar Wa?mann wrote: > > > DE is not a clock signal, but an 'Enable' signal whose value (high or > > > low) defines the window in which the

[PATCH 07/12] drm: drm_display_mode: add signal polarity flags

On Tue, Mar 18, 2014 at 01:41:54PM +0100, Laurent Pinchart wrote: > Hi Lothar, > > That's not my point. I *know* that DE is a data gating signal with a polarity > already defined by the DRM_MODE_FLAG_POL_DE_(LOW|HIGH) flags. Like all other > signals it gets generated on a clock edge and is

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Wed, Mar 19, 2014 at 06:22:14PM +0100, Laurent Pinchart wrote: > Hi Russell, > > (CC'ing Philipp Zabel who might be able to provide feedback as a user of the > component framework) > > Could you please have a look at the questions below and provide an answer > when > you'll have time ? I'd

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

On Thu, Mar 20, 2014 at 01:32:24PM +0100, Sebastian Hesselbarth wrote: > On 03/20/2014 09:58 AM, Jean-Francois Moine wrote: >> The I2C address (reg) is required for the TDA998x driver to be loaded >> and initialized. >> >> Signed-off-by: Jean-Francois Moine >> --- >> This patch applies to

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

On Thu, Mar 20, 2014 at 02:01:56PM +0100, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 13:32:24 +0100 > Sebastian Hesselbarth wrote: > > > > + - reg: I2C address - must be <0x70> > > > > TDA9983b datasheet says: > > > > "Bits A0 and A1 of the I2C-bus device address are externally

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

On Thu, Mar 20, 2014 at 02:52:21PM +0100, Jean-Francois Moine wrote: > Thanks for the link. > > OK, then, as the linux tda998x driver handles only the tda 19988 and > 19989 chips, the HDMI I2C address is always 0x70. > > So, question: Russell and Sebastian, do you still want an other patch? > >

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

On Thu, Mar 20, 2014 at 03:59:35PM +0100, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 14:31:10 + > Russell King - ARM Linux wrote: > > > 1. change the DT compatible strings the driver has to accept both > >nxp,tda19988 and nxp,tda19989, and set t

[PATCH] ASoC: tda998x: Fix lack of required reg in DT documentation

On Thu, Mar 20, 2014 at 04:54:40PM +0100, Jean-Francois Moine wrote: > On Thu, 20 Mar 2014 15:19:34 + > Russell King - ARM Linux wrote: > > > I'm not saying that it has to match the physical device fitted - I'm > > merely suggesting not using nxp,tda1998x which co

[PATCH RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector

On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote: > The 'slave encoder' structure of the tda998x driver asks for glue > between the DRM driver and the encoder/connector structures. Given how close we are to the coming merge window, that the discussion about the of-graph

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote: > However, we (as in the V4L2 community, and me personally) would have > appreciated to be CC'ed on the proposal. As you might know we already had a > solution for this problem, albeit V4L2-specific, in drivers/media/v4l2- >

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

On Sun, Mar 23, 2014 at 07:12:05PM +0100, Sebastian Hesselbarth wrote: > On 03/23/2014 11:19 AM, Jean-Francois Moine wrote: >> On Fri, 21 Mar 2014 14:37:52 +0100 >> Sebastian Hesselbarth wrote: Required properties; - - compatible: must be "nxp,tda998x" + - compatible: may be

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote: > 2. You replace calls of component_add and component_del with calls > to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT, > _component_ops), > or interface_tracker_ifdown. > Thats all for components. How does the

[PATCH linux-next] DRM: Armada: update dma_buf_export use

macro "dma_buf_export" > > requires 5 arguments, but only 4 given > > > > Signed-off-by: Vincent Stehl? > > Cc: Russell King <rmk+kernel at arm.linux.org.uk> > > Cc: David Airlie > > Cc: Maarten Lankhorst > > Cc: Sumit Semwal > >

[PATCH 2/5] drm/armada: use shmem helpers if possible

On Sun, May 25, 2014 at 02:34:09PM +0200, David Herrmann wrote: > shmem_read_mapping_page() uses mapping_gfp_mask(mapping) as default gfp > mask. No reason to use shmem_read_mapping_page_gfp() directly if we want > the default behavior. > > Cc: Russell King <rmk+kernel a

[PATCH RFC 30/46] imx-drm: remove separate imx-fbdev

On Tue, Jan 07, 2014 at 02:49:50PM +0800, Shawn Guo wrote: > On Thu, Jan 02, 2014 at 09:28:19PM +0000, Russell King wrote: > > @@ -449,6 +458,24 @@ static int imx_drm_driver_load(struct drm_device *drm, > > unsigned long flags) > > } > > } >

[PATCH RFC 27/46] imx-drm: convert to componentised device support

On Tue, Jan 07, 2014 at 04:59:35PM +0800, Shawn Guo wrote: > On Thu, Jan 02, 2014 at 09:28:03PM +0000, Russell King wrote: > > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi > > b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi > > index e75e11b36dff..0e005f21d241 100644 > &

[PATCH RFC 27/46] imx-drm: convert to componentised device support

On Tue, Jan 07, 2014 at 05:29:55PM +0100, Philipp Zabel wrote: > Thanky you. This is what I came up with so far: > > From: Philipp Zabel > Subject: [PATCH 1/2] staging: imx-hdmi: use RX_SENSE0 for plug detection if > HPD is unreliable > > On some boards HPD might not reliably detect DVI

[PATCH RFC 24/46] imx-drm: provide common connector mode validation function

On Tue, Jan 07, 2014 at 02:38:05PM +0800, Shawn Guo wrote: > On Thu, Jan 02, 2014 at 09:27:48PM +0000, Russell King wrote: > > diff --git a/drivers/staging/imx-drm/imx-drm.h > > b/drivers/staging/imx-drm/imx-drm.h > > index 5649f180dc44..4eb594ce9cff 100644 > > --- a/

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Tue, Jan 07, 2014 at 03:18:21PM -0500, Sean Paul wrote: > On Thu, Jan 2, 2014 at 4:27 PM, Russell King > <rmk+kernel at arm.linux.org.uk> wrote: > > Subsystems such as ALSA, DRM and others require a single card-level > > device structure to represent a subsystem.

[PATCH RFC 27/46] imx-drm: convert to componentised device support

On Thu, Jan 09, 2014 at 11:25:38PM +0800, Shawn Guo wrote: > Yea, adding all four into imx-drm crtcs works for imx6q, but it doesn't > for imx6dl, because is unavailable for imx6dl at all. > > Here is how I get around it. Thanks, I've rolled your change into this commit now. -- FTTC broadband

[PATCH RFC 00/46] Preview of imx-drm cleanup series

On Tue, Jan 07, 2014 at 02:33:22PM +0800, Shawn Guo wrote: > On Thu, Jan 02, 2014 at 09:25:28PM +0000, Russell King - ARM Linux wrote: > > Here is my large patch series which cleans up imx-drm, and gets it ready > > to move out of drivers/staging. This is a preview only. > &g

[PATCH v2 24/28] drm/i2c: tda998x: adjust the audio CTS to the mode clock

On Thu, Jan 09, 2014 at 12:07:02PM +0100, Jean-Francois Moine wrote: > > Signed-off-by: Jean-Francois Moine > --- > drivers/gpu/drm/i2c/tda998x_drv.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c >

[RFC PATCH v2] staging: imx-hdmi: use rx sense status for plug detection if hpd is unreliable

On Fri, Jan 10, 2014 at 03:22:24PM +0100, Philipp Zabel wrote: > Due to the voltage divider on the HPD line, the HDMI connector on > imx6q-sabrelite doesn't reliably detect connected DVI monitors. > This patch allows to use the RX_SENSE0 signal as a workaround when > enabled by a boolean device

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Sat, Jan 11, 2014 at 12:31:19PM +0100, Robert Schwebel wrote: > On Fri, Jan 10, 2014 at 11:23:37PM +0000, Russell King - ARM Linux wrote: > > We do this in DT by providing a "superdevice" node which specifies > > the components, eg: > > > > imx-drm {

[PATCH v2 1/28] drm/i2c: tda998x: simplify the i2c read/write functions

On Thu, Jan 09, 2014 at 11:57:24AM +0100, Jean-Francois Moine wrote: > This patch simplifies the i2c read/write functions and permits them to > be easily called in more contexts. > > Signed-off-by: Jean-Francois Moine Nice cleanup. Acked-by: Russell King <rmk+kernel at arm.linux

[PATCH v2 3/28] drm/i2c: tda998x: code cleanup

r_send(client, buf, sizeof buf); total: 0 errors, 3 warnings, 49 lines checked Your patch has style problems, please review. Hence, it has only been tested. I'm not giving an acked-by until the above issues are addressed. Tested-by: Russell King <rmk+kernel at arm.linux.org.uk> > ---

[PATCH v2 5/28] drm/i2c: tda998x: don't freeze the system at audio startup time

On Thu, Jan 09, 2014 at 11:58:40AM +0100, Jean-Francois Moine wrote: > This patch prevents the system to be freezed at audio startup time, > replacing mdelay by msleep. > > Signed-off-by: Jean-Francois Moine Tested-by: Russell King <rmk+kernel at arm.linux.org.uk> Acked-by:

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

. Thanks, here it is. Only change from the previously posted one is a few checkpatch cleanups. 8<=== From: Russell King <rmk+ker...@arm.linux.org.uk> Cc: Greg Kroah-Hartman Subject: [PATCH] drivers/base: provide an infrastructure for componentised subsystems Subsystems such as ALSA, DR

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Thu, Jan 02, 2014 at 07:10:55PM -0800, Greg Kroah-Hartman wrote: > On Thu, Jan 02, 2014 at 09:27:58PM +0000, Russell King wrote: > > Subsystems such as ALSA, DRM and others require a single card-level > > device structure to represent a subsystem. However, firmware tends

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Fri, Jan 10, 2014 at 07:07:02AM -0800, Greg Kroah-Hartman wrote: > On Fri, Jan 10, 2014 at 02:54:44PM +0000, Russell King - ARM Linux wrote: > > Greg, > > > > Not sure if you saw the outcome to your comment above. My conclusion > > was: > > > > &quo

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Fri, Jan 10, 2014 at 07:35:30AM -0800, Greg Kroah-Hartman wrote: > On Fri, Jan 10, 2014 at 03:11:23PM +0000, Russell King - ARM Linux wrote: > > On Fri, Jan 10, 2014 at 07:07:02AM -0800, Greg Kroah-Hartman wrote: > > > On Fri, Jan 10, 2014 at 02:54:44PM +, Russell King

[PATCH v2 2/28] drm/i2c: tda998x: check more I/O errors

iption justifying this change for an acked-by. Tested-by: Russell King <rmk+kernel at arm.linux.org.uk> -- FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".

[PATCH v2 4/28] drm/i2c: tda998x: change probe message origin

On Thu, Jan 09, 2014 at 11:58:27AM +0100, Jean-Francois Moine wrote: > This patch gives a more precise information about the device getting the > TDA chip version. > > Signed-off-by: Jean-Francois Moine Acked-by: Russell King <rmk+kernel at arm.linux.org.uk> Tested-by: Russel

[PATCH v2 6/28] drm/i2c: tda998x: force the page register at startup time

On Thu, Jan 09, 2014 at 11:58:51AM +0100, Jean-Francois Moine wrote: > This patch forces the page register to be set on the first I/O operation. > > Signed-off-by: Jean-Francois Moine No visible negative side effects, and nothing obviously wrong. Tested-by: Russell King &l

[PATCH v2 7/28] drm/i2c: tda998x: set the video mode from the adjusted value

On Thu, Jan 09, 2014 at 11:59:03AM +0100, Jean-Francois Moine wrote: > This patch uses always the adjusted video mode instead of a mix of > original and adjusted mode. > > Signed-off-by: Jean-Francois Moine No visible side effects here, but rather than copying the "adjusted_mode" pointer to

[PATCH v2 8/28] drm/i2c: tda998x: use HDMI constants

On Thu, Jan 09, 2014 at 11:59:23AM +0100, Jean-Francois Moine wrote: > This patch replaces hard coded values by hdmi constants. > > Signed-off-by: Jean-Francois Moine Tested-by: Russell King <rmk+kernel at arm.linux.org.uk> Acked-by: Russell King <rmk+kernel at arm.linux.

[PATCH v2 16/28] drm/i2c: tda998x: change the video quantization

On Thu, Jan 09, 2014 at 12:05:00PM +0100, Jean-Francois Moine wrote: > This patch changes the video quantization to RGB/YUV. Strong NAK, this patch is definitely incorrect. The Cubox (which I assume is the platform you're generating these patches for) produces RGB at it's output, which are the

[PATCH v2 9/28] drm/i2c: tda998x: don't read write-only registers

On Thu, Jan 09, 2014 at 11:59:41AM +0100, Jean-Francois Moine wrote: > @@ -936,10 +926,22 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder, > /* must be last register set: */ > reg_clear(priv, REG_TBG_CNTRL_0, TBG_CNTRL_0_SYNC_ONCE); > > + /* > + * Always generate

[PATCH v2 12/28] drm/i2c: tda998x: add DT support

On Thu, Jan 09, 2014 at 12:03:24PM +0100, Jean-Francois Moine wrote: > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c > b/drivers/gpu/drm/i2c/tda998x_drv.c > index 2ba0355..b87802f 100644 > --- a/drivers/gpu/drm/i2c/tda998x_drv.c > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c > @@ -28,17 +28,22 @@ >

<    5   6   7   8   9   10   11   12   13   14   >