On Mon, Jun 22, 2015 at 12:06:04PM +0200, Paul Bolle wrote:
> But I think there's no platform_device with a "dw-hdmi-i2s-audio" name.
> So I wonder whether this MODULE_ALIAS() is actually needed. What breaks
> if you leave it out?
+ } else if (hdmi_readb(hdmi, HDMI_CONFIG0_ID) &
On Tue, Jun 23, 2015 at 01:41:46PM -0300, Fabio Estevam wrote:
> Hi,
>
> On a imx6q-cubox-i running 4.1 kernel I am getting 1920x1080 HDMI
> resolution if I boot the board with the HDMI cable connected.
>
> If I boot it without the HDMI cable and then connect it afterwards,
> the resolution goes
On Tue, Jun 23, 2015 at 01:52:50PM -0300, Fabio Estevam wrote:
> On Tue, Jun 23, 2015 at 1:44 PM, Russell King - ARM Linux
> wrote:
>
> > If you have no connected connectors, then you get 1024x768:
> >
> > imx-drm display-subsystem: No connectors reported connected
On Tue, Jun 23, 2015 at 05:48:51PM -0300, Fabio Estevam wrote:
> On Tue, Jun 23, 2015 at 5:41 PM, Russell King - ARM Linux
> wrote:
>
> > I've just tried this (the HBi1 was booted previously with the HDMI socket
> > disconnected). Just now, I turned the TV o
On Fri, Jun 26, 2015 at 05:24:12PM +0300, Vladimir Zapolskiy wrote:
> Hello David,
>
> On 08.06.2015 17:17, Vladimir Zapolskiy wrote:
> > what would be the next action regarding these two patches? If review is
> > done, should they go to drm-dwhdmi-devel or drm-next ?
>
> ping.
I don't think it
On Thu, Feb 26, 2015 at 04:55:32PM +0200, Jyri Sarha wrote:
> + ret = component_bind_all(dev->dev, dev);
> + if (ret < 0) {
> + dev_err(dev->dev, "Binding subcomponents failed: %d\n", ret);
Do you need to print this? The component helper is already fairly
verbose about what
On Mon, Mar 02, 2015 at 02:28:40PM +0200, Tomi Valkeinen wrote:
> On 26/02/15 16:55, Jyri Sarha wrote:
> > Use new binding for the external tda19988 HDMI encoder.
> >
> > Signed-off-by: Jyri Sarha
> > ---
> > arch/arm/boot/dts/am335x-boneblack.dts | 20 +++-
> > 1 file changed,
On Mon, Mar 02, 2015 at 07:08:39PM +0200, Tomi Valkeinen wrote:
> On 02/03/15 18:06, Russell King - ARM Linux wrote:
>
> >> This is missing the output of tda998x. It should have two ports, input
> >> and output, output going to hdmi-connector.
> >
> &
On Wed, Feb 25, 2015 at 09:27:57AM -0800, Mike Turquette wrote:
> +static inline bool clk_is_match(struct clk *p, struct clk *q)
> +{
> + return p == q ? true : false;
When they created the C standard, they already taught the compiler that
p == q returns a true / false boolean value; there's
On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> Would it be Ok to add a check that master->ops->add_components is defined,
> before calling it in find_componets() (drivers/base/component.c:120) and
> return 0 if it is not?
No:
On Fri, Mar 06, 2015 at 12:21:42PM +0200, Jyri Sarha wrote:
> On 03/06/15 11:58, Russell King - ARM Linux wrote:
> >On Fri, Mar 06, 2015 at 10:33:27AM +0200, Jyri Sarha wrote:
> >>Would it be Ok to add a check that master->ops->add_components is defined,
> >>be
On Tue, Mar 10, 2015 at 12:21:21AM +0100, Heiko Stuebner wrote:
> At least the Rockchip variant of the dw_hdmi should control its supplying
> regulators. A cursory glance at the imx manual didn't any equivalent there,
> so I'm not sure if there are similar controllable regulators present.
>
>
On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> ARM randconfig build tests found a new error for configurations
> with COMMON_CLK disabled but HAS_CLK selected by the platform:
>
> ERROR: "clk_is_match" [sound/soc/fsl/snd-soc-fsl-spdif.ko] undefined!
>
> This moves the
On Wed, Mar 11, 2015 at 12:17:55PM +0100, Uwe Kleine-König wrote:
> Hey Russell,
>
> On Wed, Mar 11, 2015 at 10:22:09AM +, Russell King - ARM Linux wrote:
> > On Sun, Mar 08, 2015 at 10:05:29PM +0100, Arnd Bergmann wrote:
> > > ARM randconfig build tests found a new
people to review the code by seeing the driver as a
> > whole and is not intended for merging in this form.
> >
> > If you are interested in the history of individual commits:
> > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream
> >
> > Signe
the code by seeing the driver as a
> > whole and is not intended for merging in this form.
> >
> > If you are interested in the history of individual commits:
> > git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream
> >
> > Signed-off-by: Christian Gmeine
ng in this form.
>
> If you are interested in the history of individual commits:
> git://git.pengutronix.de/git/lst/linux.git etnaviv-for-upstream
>
> Signed-off-by: Christian Gmeiner
> Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk>
> Signed-off-by: Lucas Stac
On Wed, Sep 16, 2015 at 11:05:11AM -0400, Eric Anholt wrote:
> Lucas Stach writes:
>
> > From: Christian Gmeiner
>
> > +static bool etnaviv_validate_load_state(struct etnaviv_gpu *gpu, u32 *buf,
> > + unsigned int state, unsigned int num)
> > +{
> > + return true;
...
> > +}
>
> I was
On Wed, Sep 16, 2015 at 02:56:57PM -0700, Doug Anderson wrote:
> Yes, I'd expect 100kHz and 400kHz.
>
> I agree that 50ms is non-trivial, but it's also not something you're
> doing lots of. I'd expect that the EDID is read over this channel at
> cable plugin time and then not used much after
On Sat, Sep 19, 2015 at 10:54:51AM -0700, Mark Brown wrote:
> On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote:
> > +#define SPDIF_FORMATS (SNDRV_PCM_FMTBIT_S16_LE |
> > SNDRV_PCM_FMTBIT_S16_BE |\
> > +SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\
> > +
On Fri, Sep 18, 2015 at 02:06:39PM +0300, 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 bits already in audio stream configuration
> phase.
What is the reason
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
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
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(>struct_mutex)))
> + return -EDEADLK;
This actually needs dropping from the patch - and we'll rely on lockdep
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__);
> >+
> >+
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
Hi,
Here's my currently queued TDA998x development work for 4.4.
* Remove some useless NULL checks here variables can't be NULL.
* Return IRQ_HANDLED only if we handled the IRQ, otherwise return
IRQ_NONE. This avoids locking the system up if the IRQ gets stuck.
* Re-implement a previous patch
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
>
On Wed, May 27, 2015 at 12:43:08PM +0200, Daniel Vetter wrote:
> On Sat, May 09, 2015 at 11:26:57AM +0100, Russell King wrote:
> > Parse the ELD (EDID like data) stored from the HDMI driver to restrict
> > the sample rates and channels which are available to ALSA. This causes
>
On Wed, May 27, 2015 at 02:45:48PM +0200, Alexander Holler wrote:
> Hello,
>
> I've just build and booted the Etnaviv driver as module with Kernel 4.0.4.
You may wish to try using my patch set(s) at (url purposely obfuscated,
sorry):
http : // www . home . arm . linux . org . uk / ~rmk / cubox
On Wed, May 27, 2015 at 11:29:52PM +0200, Daniel Vetter wrote:
> The only issue that might be
> there with your sw approach is that a concurrent probe/hotplug in drm
> might free the edid and hence the eld, while the snd side is trying to
> copy that.
Talking only about the particular case of
On Wed, May 27, 2015 at 02:49:17PM +0200, Lucas Stach wrote:
> Hi Alexander,
>
> Am Mittwoch, den 27.05.2015, 14:45 +0200 schrieb Alexander Holler:
> > Hello,
> >
> > I've just build and booted the Etnaviv driver as module with Kernel 4.0.4.
> >
> > When I unload the driver with rmmod an oops
On Sat, May 30, 2015 at 05:37:57PM +0200, Mikko Rapeli wrote:
> Fixes userspace compilation error:
>
> drm/exynos_drm.h:30:2: error: unknown type name âuint64_tâ
>
> Signed-off-by: Mikko Rapeli
This is another thing which we need to address. We should not be using
unsigned int/unsigned
On Mon, Oct 19, 2015 at 04:07:47PM +0100, Liviu Dudau wrote:
> A lot of component based DRM drivers use a variant of the same code
> as the probe function. They bind the crtc ports in the first iteration
> and then scan through the child nodes and bind the encoders attached
> to the remote
On Mon, Nov 09, 2015 at 05:39:25PM +0800, Mark yao wrote:
> Hi Liviu
> Rockchip drm can't work with drm_of_component_probe function now,
>
> At drm_of_component_probe:
> component_match_add(dev, , compare_of, port);
> And original rockchip drm use:
>
On Mon, Nov 09, 2015 at 11:57:27AM +, Liviu Dudau wrote:
> Meanwhile, what is your suggestion regarding the patchset. I've seen David has
> sent Linus a pull request for 4.4-rc1 that includes it. Should we send a
> revert for rockchip commit and then patch later the function?
It definitely
g is_vmalloc_addr(). Unless callers have special reasons, we can
> replace this branch with kvfree(). Please check and reply if you found
> problems.
>
> Signed-off-by: Tetsuo Handa
> Acked-by: Michal Hocko
> Cc: Russell King # arm
Acked-by: Russell King <rmk+kernel at a
>
> Drop the now unused custom imx_drm_get_port_by_id function.
>
> Signed-off-by: Philipp Zabel
> Suggested-by: Russell King
Yay, many thanks for this, Philipp! For patches 3 and 4:
Acked-by: Russell King <rmk+kernel at arm.linux.org.uk>
(Please change to use rmk+kernel in b
On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> While going through the code testing I've noticed an unbalanced
> .unbind missing drm_connector_unregister()
That actually doesn't matter, as DRM automatically tears them down anyway,
so this isn't an urgent change. However, it's
On Mon, Nov 16, 2015 at 02:44:52PM +, 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 compare function to be used when encoders are added to the
> component
I've tweaked your patch to make the above (buggy) change a little clearer.
On Mon, Nov 16, 2015 at 02:44:53PM +, Liviu Dudau wrote:
> - for (i = 0;; i++) {
> - port = of_parse_phandle(np, "ports", i);
> - if (!port)
> - break;
> -
> -
they bother to reply if they have that kind of
additional work? Thanks.
On Mon, Nov 16, 2015 at 04:49:07PM +, Liviu Dudau wrote:
> On Mon, Nov 16, 2015 at 04:22:41PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Nov 16, 2015 at 02:44:52PM +, Liviu Dudau wrote:
> > > R
On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
> On 16 November 2015 at 17:22, Russell King - ARM Linux
> wrote:
> > Please sensibly wrap your messages. Your lines are longer than 80
> > characters which makes it exceedingly difficult for some people to reply
>
On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> An encoder is associated with a connector by the DRM core as a result of
> setting up a configuration. Drivers using the atomic or legacy helpers
> should never set up this link, even if it is a static
On Mon, Nov 16, 2015 at 05:48:32PM +, Daniel Stone wrote:
> On 16 November 2015 at 17:43, Russell King - ARM Linux
> wrote:
> > On Mon, Nov 16, 2015 at 05:32:05PM +, Daniel Stone wrote:
> >> On 16 November 2015 at 17:22, Russell King - ARM Linux
> >> wrot
On Mon, Nov 16, 2015 at 09:17:35PM +, Liviu Dudau wrote:
> On Mon, Nov 16, 2015 at 05:22:48PM +0000, Russell King - ARM Linux wrote:
> > Put those two sentences together and please think about it. If the
> > pointer type is unknown to component_match_add(), how could
On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> > On Wed, Nov 11, 2015 at 05:51:52PM +, Russell King - ARM Linux wrote:
> > > On Wed, Nov 11, 2015 at 03:34:32PM +, Liviu Dudau wrote:
> >
On Fri, Nov 20, 2015 at 04:44:55PM +, Liviu Dudau wrote:
> On Fri, Nov 20, 2015 at 04:32:59PM +0000, Russell King - ARM Linux wrote:
> > On Fri, Nov 20, 2015 at 02:24:04PM +, Liviu Dudau wrote:
> > > On Wed, Nov 11, 2015 at 05:57:18PM +, Liviu Dudau wrote:
> >
Greg,
These four patches update the component helper by:
* Removing the legacy matching code with the .add_components method
in the master's operation structure. Nothing in -rc1 appears to be
using the legacy functions or method, according to my git greps.
* A slight code reorganisation
On Mon, Nov 23, 2015 at 10:32:46AM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_gem.c
> b/drivers/gpu/drm/armada/armada_gem.c
> index e3a86b96af2a..a43690ab18b9 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -46,7
As of 3c3b177a9369 ("reservation: add suppport for read-only access
using rcu") linux/reservation.h uses lockdep macros:
+#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)
This results in build errors when lockdep is disabled as lockdep_is_held()
is only available when
On Wed, Sep 30, 2015 at 11:49:44AM +0100, Emil Velikov wrote:
> Hi Russell,
>
> On 29 September 2015 at 19:10, Russell King <rmk+kernel at arm.linux.org.uk>
> wrote:
> > Rather than using a spinlock, use xchg() to atomically update
> > dplane->old_fb. This al
On Tue, Jan 27, 2015 at 01:55:54PM +0530, Sumit Semwal wrote:
> +/*
> + * recalc_constraints - recalculates constraints for all attached devices;
> + * useful for detach() recalculation, and for dma_buf_recalc_constraints()
> + * helper.
> + * Returns recalculated constraints in recalc_cons, or
On Thu, Jan 29, 2015 at 09:00:11PM +0530, Sumit Semwal wrote:
> So, short answer is, it is left to the exporter to decide. The dma-buf
> framework should not even attempt to decide or enforce any of the
> above.
>
> At each dma_buf_attach(), there's a callback to the exporter, where
> the
On Thu, Jan 29, 2015 at 01:52:09PM -0500, Rob Clark wrote:
> Quite possibly for some of these edge some of cases, some of the
> dma-buf exporters are going to need to get more clever (ie. hand off
> different scatterlists to different clients). Although I think by far
> the two common cases will
On Thu, Jan 29, 2015 at 05:18:33PM -0500, Rob Clark wrote:
> On Thu, Jan 29, 2015 at 2:26 PM, Russell King - ARM Linux
> wrote:
> > Now, if we're going to do the "more clever" thing you mention above,
> > that rather negates the point of this two-part patch set, which
On Fri, Jan 30, 2015 at 10:37:19AM -0500, Rob Clark wrote:
> On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar
> wrote:
> I'll also need to update the new bridge in the msm edp code..
> although that isn't such a big deal if I knew how this was *supposed*
> to work.. since what is there now at least
On Fri, Jan 30, 2015 at 06:19:46AM -0500, Yakir Yang wrote:
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
It appears that the iMX6 version of the DW-HDMI IP does not have these
On Fri, Jan 30, 2015 at 06:25:30AM -0500, Yakir Yang wrote:
> For Designerware HDMI, the following write sequence is recommended:
> 1. aud_n3 (set bit ncts_atomic_write if desired)
> 2. aud_cts3 (set CTS_manual and CTS value if desired/enabled)
> 3. aud_cts2 (required in CTS_manual)
> 4. aud_cts1
On Fri, Jan 30, 2015 at 06:27:10AM -0500, Yakir Yang wrote:
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information of all the channel
> status bits in the IEC60958 frame.
>
> Signed-off-by: Yakir Yang
> ---
> Changes in v2:
> - Add audio sample
On Fri, Jan 30, 2015 at 06:28:00AM -0500, Yakir Yang wrote:
> diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c
> b/drivers/gpu/drm/bridge/dw_hdmi.c
> index 2ded957..13f26af 100644
> --- a/drivers/gpu/drm/bridge/dw_hdmi.c
> +++ b/drivers/gpu/drm/bridge/dw_hdmi.c
> @@ -1745,6 +1745,49 @@ void
On Fri, Jan 30, 2015 at 06:28:59AM -0500, Yakir Yang wrote:
> Signed-off-by: Yakir Yang
> ---
> Changes in v2:
> - Add suspend/resume support for dw_hdmi_rockchip driver
>
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git
On Fri, Jan 30, 2015 at 06:30:39AM -0500, Yakir Yang wrote:
> Add more n/cts values, in that case we can support audio for more
> display resolutions (128 * SampleRate = PixelClock * N / CTS).
Where do these come from? The iMX6 manuals give the set which are
already in the driver, and says that
On Sat, Jan 31, 2015 at 06:22:19AM -0500, Yang Kuankuan wrote:
>
> On 01/31/2015 06:08 AM, Russell King - ARM Linux wrote:
> >On Fri, Jan 30, 2015 at 06:27:10AM -0500, Yakir Yang wrote:
> >>When transmitting IEC60985 linear PCM audio, we configure the
> >>Aduio Sam
On Fri, Jan 30, 2015 at 06:31:33AM -0500, Yakir Yang wrote:
> If the monitor support audio, so we should support audio for it, even if
> the display resolution is No-CEA mode.
I can't find where it was documented at the moment, but I seem to remember
reading somewhere that the iMX6 SoC version of
On Fri, Jan 30, 2015 at 06:32:23AM -0500, Yakir Yang wrote:
> +static void hdmi_config_audio(struct dw_hdmi *hdmi,
> + struct hdmi_audio_fmt *aud_fmt)
> +{
> + if (aud_fmt)
> + hdmi->aud_fmt = *aud_fmt;
> +
> + hdmi_modb(hdmi,
On Fri, Jan 30, 2015 at 06:23:51AM -0500, Yakir Yang wrote:
> We found Designware hdmi driver only support audio clock config, we can not
> play sound through it.
> To add Designware HDMI Audio support, we make those patch set:
> 1): modify n/cts config order, according to dw_hdmi document.
>
On Fri, Jul 03, 2015 at 06:58:44PM +0900, Tomasz Figa wrote:
> On Fri, Jul 3, 2015 at 6:17 PM, Mark yao wrote:
> >> Aren't the scl_modes for CbCr planes always the same as for Y plane?
> >
> >
> > No, such as src(1920 x 1080) -> dst(1280x800), yuv format is NV12.
> > so Y plane horizontal and
On Wed, Jul 15, 2015 at 12:19:01PM +0200, Benjamin Gaignard wrote:
> The build order in Makefile hasn't been change so the bug doesn't occur...
>
> In addition of taking care of not changing build order in Makefile,
> I would like to understand what is the expected behavior of component
>
On Thu, Jul 16, 2015 at 06:16:58PM +0200, Jean-Francois Moine wrote:
> The file sound/core/pcm_drm_eld.c which was added by the commit
>
> 838d1631b766529213684f07dd71cdf2e92f0623
> ALSA: pcm: add DRM ELD helper
>
> lacks the function drm_eld_sad() which was defined by Russell's
On Sat, Jun 20, 2015 at 12:19:12AM +0800, Yakir Yang wrote:
> The exact relationship between the two clocks will be:
> 128 * SampleRate = TmdsClock * N / CTS.
> So this patch would generate the correct N/CTS values, add audio support
> for the below tmds clocks:
> 25.175MHz, 40MHz, 54MHz,
On Mon, Jun 01, 2015 at 10:20:10AM +0200, Christian König wrote:
> Using types that differs on 32-bit and 64-bit machines for a kernel
> interface is indeed a rather bad idea. This not only includes longs, but
> pointers as well.
[cut standard stdint.h types argument which we've heard before]
On Mon, Jun 01, 2015 at 11:08:21AM +0200, Christian König wrote:
> Yeah, completely agree with Linus on the visibility problem and that's
> exactly the reason why we don't include in the kernel header and
> expect userspace to define the ISO types somewhere.
>
> But using the types from
e of, and then I thought I'd wait
> > for the merge window to get over before beginning to discuss this
> > again.
> >
> > On 11 February 2015 at 21:53, Russell King - ARM Linux
> > wrote:
> >> On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote
On Fri, Jun 05, 2015 at 07:56:38PM +0100, Chris Wilson wrote:
> On Fri, Jun 05, 2015 at 07:47:22PM +0100, Russell King wrote:
> > Writing to a file is supposed to return the number of bytes written.
> > Returning zero unfortunately causes bash to constantly spin trying
> >
On Fri, Jun 05, 2015 at 02:16:40PM +0200, Heiko Stübner wrote:
> Hi Thierry
>
> Am Freitag, 5. Juni 2015, 13:02:01 schrieb Thierry Reding:
> > If this is specific to the Rockchip implementation, shouldn't this go
> > into Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt? It
> > could
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-01-27 09:25, Sumit Semwal wrote:
> >Add some helpers to share the constraints of devices while attaching
> >to the dmabuf buffer.
> >
> >At each attach, the constraints are calculated based on the following:
>
On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-02-11 12:12, Russell King - ARM Linux wrote:
> >Which is a damn good reason to NAK it - by that admission, it's a half-baked
> >idea.
> >
> >If all we want to know is whe
On Thu, Feb 12, 2015 at 01:24:05PM +0100, Sascha Hauer wrote:
> On Thu, Feb 12, 2015 at 06:39:45PM +0800, Liu Ying wrote:
> > On Thu, Feb 12, 2015 at 10:33:56AM +0100, Sascha Hauer wrote:
> > > On Thu, Feb 12, 2015 at 02:01:24PM +0800, Liu Ying wrote:
> > > > If no best divider is normally found,
On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
> I agree that it's a bit odd, but I think it has to be like this.
> Consider that you request a rate of 100Hz, but the clock can only
> produce 99.5Hz, so due to rounding clk_round_rate() returns 99Hz.
> Now when you request 99Hz from
On Fri, Feb 20, 2015 at 11:13:06AM -0800, Mike Turquette wrote:
> Quoting Russell King - ARM Linux (2015-02-16 03:27:24)
> > On Fri, Feb 13, 2015 at 07:57:13PM +0100, Sascha Hauer wrote:
> > > I agree that it's a bit odd, but I think it has to be like this.
> > > Consi
On Wed, Feb 25, 2015 at 10:53:30PM +0800, Shawn Guo wrote:
> On the first day back from Chinese new year holiday, I got a regression
> report from rmk, saying Ethernet stops working on HimmingBoard with
> v4.0-rc1.
>
> I read through the thread [1] and found a couple of i.MX audio drivers
> are
On Thu, Feb 26, 2015 at 09:52:02AM +0200, Laurent Pinchart wrote:
> Hi Russell,
>
> On Friday 16 January 2015 17:47:34 Russell King - ARM Linux wrote:
> > On Fri, Jan 16, 2015 at 06:37:43PM +0200, Laurent Pinchart wrote:
> > > Replace the internal EDID read implementat
On Tue, Jan 06, 2015 at 12:52:24PM +0100, Heiko Stübner wrote:
> +static void imx_hdmi_bridge_nope(struct drm_bridge *bridge)
"_nope" ? As in "No"? Or should this be "_nop" for no-operation ?
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Fri, Dec 05, 2014 at 02:25:50PM +0800, Andy Yan wrote:
> hdmi phy configuration is platform specific, which can be adusted
Minor typo: adjusted
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
and I've also tested it on a SolidRun
Hummingboard i2ex along with all my CEC and audio patches, where it
seems to be fine. So for the set:
Tested-by: Russell King <rmk+kernel at arm.linux.org.uk>
Apart from the two minor items I've pointed out in separate replies:
Acked-by: Russell King <rmk+
On Wed, Jan 07, 2015 at 03:10:47PM +, Andrew Jackson wrote:
> On 01/07/15 10:51, Jean-Francois Moine wrote:
> > diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
> > index 22c7ed6..24fc975 100644
> > --- a/drivers/gpu/drm/i2c/Kconfig
> > +++ b/drivers/gpu/drm/i2c/Kconfig
>
On Fri, Jan 09, 2015 at 12:24:12PM +0200, Jyri Sarha wrote:
> I think that would still fail if DRM and TDA998x is built in and SND_SOC is
> built as modules. A request_module() call before tda9998x_codec_register()
> should help.
That doesn't fix the problem. If the DRM driver is built in, but
On Fri, Jan 09, 2015 at 12:30:36PM +0100, Jean-Francois Moine wrote:
> In my original version, the audio-ports are a bitmap of the pins, the
> bit 0 being the WS used for I2S. A fully wired tda998x would have been
> as:
>
> audio-ports = <0x03>, <0x04>, <0x09>, <0x11>;
>
On Fri, Jan 09, 2015 at 12:45:31PM +0100, Jean-Francois Moine wrote:
> On Fri, 9 Jan 2015 11:19:35 +
> Russell King - ARM Linux wrote:
>
> > Would it be more sensible to make SND_SOC_TDA998X depend on
> > DRM_I2C_NXP_TDA998X instead, maybe with a 'default y' - whic
On Fri, Jan 09, 2015 at 01:54:01PM +0100, Jean-Francois Moine wrote:
> On Fri, 9 Jan 2015 11:45:29 +
> Russell King - ARM Linux wrote:
> > I think we need to understand exactly how the 998x map I2S inputs to the
> > HDMI channels to avoid making a mistake with the
On Fri, Jan 09, 2015 at 01:58:37PM +, Andrew Jackson wrote:
> On 01/09/15 13:07, Russell King - ARM Linux wrote:
> > On Fri, Jan 09, 2015 at 01:54:01PM +0100, Jean-Francois Moine wrote:
> >> On Fri, 9 Jan 2015 11:45:29 +
> >> Russell King - ARM Linux w
On Fri, Jan 02, 2015 at 09:55:02PM +0100, Rickard Strandqvist wrote:
> Removes some functions that are not used anywhere:
> armada_drm_encoder_mode_fixup() armada_drm_encoder_commit()
> armada_drm_encoder_prepare()
>
> This was partially found by using a static code analysis program called
>
On Wed, Jan 07, 2015 at 09:42:19AM +0100, Jean-Francois Moine wrote:
> The CEC registers of the TDA998x have no access by page,
> so, a 8 bits address is enough.
>
> Signed-off-by: Jean-Francois Moine
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Fri, Jan 09, 2015 at 06:38:57PM +0100, Jean-Francois Moine wrote:
> On Fri, 9 Jan 2015 14:57:41 +
> Russell King - ARM Linux wrote:
> > What we do know is that there is a fixed mapping between AP pins and I2S
> > channels (which are not PCM channels), but as you p
On Mon, Jan 12, 2015 at 10:25:28AM +0100, Philipp Zabel wrote:
> Jean-Francois' reply already reflects this, but the 'port' nodes should
> correspond to physical ports of the device if possible. If you can
> configure the device to have dedicated input pins for I2S, SPDIF0, and
> SPDIF1 at the
On Mon, Jan 12, 2015 at 02:59:57PM +0100, Philipp Zabel wrote:
> Am Montag, den 12.01.2015, 12:25 + schrieb Russell King - ARM Linux:
> > It's not quite that simple, because the SPDIF AP pins are multiplexed
> > with the I2S pins - and there is variation between chip models a
On Mon, Jan 12, 2015 at 06:13:41PM +0100, Jean-Francois Moine wrote:
> On Mon, 12 Jan 2015 14:04:56 +
> Russell King - ARM Linux wrote:
> > On Mon, Jan 12, 2015 at 02:59:57PM +0100, Philipp Zabel wrote:
> > > Note that of_graph_parse_endpoint interprets the port node
1501 - 1600 of 2012 matches
Mail list logo
