On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:
> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem. I think the fact is, there is no data.
> Someone prove me wrong. Someo
On Thu, Oct 08, 2015 at 12:12:40PM -0400, Alex Deucher wrote:
> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
> provides the platform DMA component to ALSA core.
Overall my main comment on a lot of this code is that it feels like we
have created a lot of infrastructure tha
On Thu, Oct 08, 2015 at 12:12:39PM -0400, Alex Deucher wrote:
> +config DRM_AMD_ACP
> + bool "Enable ACP IP support"
> + default y
> + depends on MFD_CORE
> + help
> + Choose this option to enable ACP IP support for AMD SOCs.
Why does this depend on rather than select
On Thu, Oct 08, 2015 at 12:12:36PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> Added a qurik to assign different base addresses for different
> dwc controllers present on platform for playback and capture.
I don't understand what the above means, sorry. Normally the addr
On Thu, Oct 08, 2015 at 12:12:35PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> Some platforms (Ex: AMD CZ) can have separate dwc controllers with
> different base address for playback and capture. This patch adds
> necessary changes to support it. Platforms which make use
On Thu, Oct 08, 2015 at 12:12:34PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> DW i2s controller's master/slave config can be read from a
> read-only register. Machine driver can try to set a master/slave
> format on cpu-dai using 'set_fmt' of dai ops. A check is added to
On Tue, Oct 20, 2015 at 10:19:38AM +1000, Dave Airlie wrote:
> On 20 October 2015 at 10:14, Mark Brown wrote:
> > Please don't send content free pings and please allow a reasonable time
> > for review. People get busy, go on holiday, attend conferences and so
> >
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:
> Something like this. I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should that
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > mor
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> > To be clear, I was saying that this series should NOT affect total
> > boot times much.
> I'm confused. If I understood correctly, improving boot time was
> the key justification for ac
On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:
> > https://lkml.org/lkml/2015/6/17/311
> But what Rafael is proposi
On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> Furthermore, that applies only to devices that use synchronous suspend.
> Async suspend is becoming common, and there the only restrictions are
> parent-child relations plus whatever explicit requirements that drivers
> impose by ca
On Mon, Oct 19, 2015 at 11:11:19AM -0400, Alex Deucher wrote:
> Ping? Anyone had a chance to look over this latest revision? I think
> we've addressed all the outstanding comments.
Please don't send content free pings and please allow a reasonable time
for review. People get busy, go on holida
On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > > But the point I'm making is that we are working towards *fixing* that,
> > > and *not* using DT-specific code in places where we should be us
On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:
> > Generic subsystem code -> DT
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > Do you mean firmware rather than bus here? I think that's the confusion
> > I have...
> Certainly, if it literally is adding of_* calls then
On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> > > I can't see adding calls like this all over the tree just to sol
On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of makin
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.
This isn't bus specific, I'm not sure what makes you say that
On Fri, Oct 16, 2015 at 03:51:40PM +0200, Arnaud Pouliquen wrote:
> - Does trigger is needed when CPU-DAI is master on bus?
> Otherwise how to inform HDMI that I2S bus is no more clocked? I'm not
> sure that mute is sufficient for all hardwares... For instance for my
> hardware CTS parameter is ha
On Fri, Oct 16, 2015 at 02:37:17PM +0100, Russell King - ARM Linux wrote:
> If all the effort that's been put into discussion was put into sorting
> out a solution, maybe we'd be a little further forward than we are now.
> I've sent one proposal which uses a notifier to inform audio and CEC
> dri
On Fri, Oct 16, 2015 at 02:31:43PM +0200, Lars-Peter Clausen wrote:
> On 10/16/2015 01:50 PM, Jyri Sarha wrote:
> > My conclusion from the Lars-Peter's latest mail [2] related to the
> > subject is that the wind is currently blowing slightly in favour of my
> > version of the hdmi codec [3], or at
On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next
In don't think that's the URL you intended to use (also everything looks
word wrapped here)?
-- next part --
A non-text attach
On Tue, Oct 06, 2015 at 06:44:34PM +0300, Jyri Sarha wrote:
> On 10/06/15 12:23, Arnaud Pouliquen wrote:
> >In a first step, before going deep in discussion on the approach, it
> >should be interesting to have maintainers feedback, to be sure that my
> >approach could make sense from DRM and ALSA
On Fri, Sep 25, 2015 at 05:48:23PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> Vendor specific quirk was added to:
> 1. Support AMD platform which has two dwc controllers with different
>base address for playback and capture. Also, I2S_COMP_PARAM_*
>registers offse
On Fri, Sep 25, 2015 at 05:48:22PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> dw i2s controller can work in slave mode, codec being master.
> dw i2s is made to support master/slave operation, by reading dwc
> register.
I'll apply this but can you please send a followup i
On Mon, Sep 21, 2015 at 04:41:20PM +0300, Jyri Sarha wrote:
> On 09/21/15 12:31, Russell King - ARM Linux wrote:
> >The device may accept 32 bit I2S, but it would have to be truncated to
> >24 bit before transmitting it to the sink. This should be mentioned
> >somewhere.
> There is ".sig_bits =
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 |\
> + SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_
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.
>
> Signed-off-by: J
On Tue, Aug 25, 2015 at 03:26:54PM +0530, maruthi srinivas wrote:
> On Tue, Aug 25, 2015 at 11:36 AM, Mark Brown wrote:
> > Please explain this in more detail, shared register ranges are very
> > common and are the sort of things MFDs are supposed to help with.
> In our ca
On Sat, Aug 08, 2015 at 04:35:41PM +0100, Russell King - ARM Linux wrote:
> On Sat, Jun 20, 2015 at 12:28:15AM +0800, Yakir Yang wrote:
> > Add ALSA based HDMI I2S audio driver for dw_hdmi. Sound card
> > driver could connect to this codec through the codec dai name
> > "dw-hdmi-i2s-audio".
> I'm
On Mon, Aug 24, 2015 at 04:08:31PM -0400, Alex Deucher wrote:
> On Fri, Aug 21, 2015 at 12:17 PM, Mark Brown wrote:
> > What I'm looking for is actual code sharing where we use the same code
> > for the I2S controller block or a clear and documented understanding of
> >
On Fri, Aug 21, 2015 at 05:21:07PM +0530, maruthi srinivas wrote:
> On Fri, Aug 21, 2015 at 4:48 AM, Mark Brown wrote:
> > We already have a driver for the DesignWare I2S controller. To repeat
> > the concern I raised in a slightly different bit of the code last time:
> >
On Thu, Aug 20, 2015 at 07:50:34PM -0400, Alex Deucher wrote:
> On Thu, Aug 20, 2015 at 7:45 PM, Mark Brown wrote:
> > This is not a DRM driver, it is an ASoC driver, and like I say DRM is a
> > bit special. I do note that AMD has contributed at least its CCP and
> > cpufre
On Thu, Aug 20, 2015 at 07:11:22PM -0400, Alex Deucher wrote:
> On Thu, Aug 20, 2015 at 6:31 PM, Mark Brown wrote:
> > DRM is a special case here since there has always been work to share
> > bits of the code with other operating systems, the licensing for DRM is
> > ve
On Thu, Aug 20, 2015 at 05:36:34PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
> provides the DMA and CPU DAI components to ALSA core.
This is flagged as patch 3/3 but appears to be sent as a single pat
On Thu, Aug 20, 2015 at 05:30:27PM -0400, Alex Deucher wrote:
> On Thu, Aug 20, 2015 at 5:13 PM, Mark Brown wrote:
> >> v4: squash in naming fixes
> > To repeat what I said last time:
> > | Please follow the patch submission process in SubmittingPatches: put any
> &g
On Thu, Aug 20, 2015 at 04:09:21PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
> provides the DMA and CPU DAI components to ALSA core.
>
> v2: squash in Kconfig fix
> v3: squash additional commits, conv
On Mon, Aug 17, 2015 at 10:00:07AM +0300, Jyri Sarha wrote:
> On 08/14/15 19:10, Mark Brown wrote:
> Don't you mean "omap-hdmi-audio", that is implemented in
> sound/soc/omap/omap-hdmi-audio.c ?
> That driver is bit different. It implements ASoC card and uses gener
On Mon, Aug 17, 2015 at 10:07:55AM +0300, Jyri Sarha wrote:
> On 08/14/15 19:18, Mark Brown wrote:
> >On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
> >>+ /* Called when ASoC starts an audio stream setup. The call
> >>+* provides an audio abort call
On Tue, May 26, 2015 at 09:59:07PM +0300, Jyri Sarha wrote:
> +
> + mutex_lock(&hcp->current_stream_lock);
> + if (hcp->current_stream && hcp->current_stream->runtime &&
> + snd_pcm_running(hcp->current_stream)) {
> + dev_info(dev, "HDMI audio playback aborted\n");
Doe
On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote:
> +struct hdmi_codec_ops {
> + /* For runtime clock configuration from ASoC machine driver.
> + * A direct forward from set_sysclk in struct snd_soc_dai_ops.
> + * Optional */
> + int (*set_clk)(struct device *dev, int c
On Fri, Aug 14, 2015 at 12:30:40PM +0300, Jyri Sarha wrote:
> The hdmi stub codec has not been used since refactoring of OMAP HDMI
> audio support.
grep tells me that the OMAP HDMI4 and HDMI5 drivers are still
registering this device in -next...
-- next part --
A non-text
On Mon, Aug 10, 2015 at 05:49:41PM +0100, Russell King - ARM Linux wrote:
> I'm not sure what the right solution is here: modifying every audio
> player out there to make HDMI work sanely is crazy. Having alsalib
> automatically generate the correct AES channel status bytes for
> linear audio for
On Fri, Aug 07, 2015 at 04:03:08PM -0400, Felix Kuehling wrote:
> 1. GPU driver gets initialized, detects a GPU with audio co-processor (ACP)
> 2. GPU driver registers mfd_cell for the ACP device using
> mfd_add_hotplug_devices
> * It's not really hot-plug, but the mem_base, irq_base,
On Fri, Aug 07, 2015 at 12:16:03PM -0400, Felix Kuehling wrote:
> Hi,
>
> To elaborate more on Alex's explanation ...
Please don't top post, reply in line deleting any unneeded context so
people have context for what's being discussed.
> Therefore we created this "virtual" GNB bus that allows us
On Fri, Aug 07, 2015 at 10:17:36AM -0400, Alex Deucher wrote:
> On Fri, Aug 7, 2015 at 6:25 AM, Mark Brown wrote:
> > Looking at the code I'm not seeing too much bus specific except for the
> > above which looks like the sort of device we usually represent as a MFD
> &g
On Thu, Aug 06, 2015 at 10:25:02AM -0400, Alex Deucher wrote:
> From: Chunming Zhou
>
> This is used by the incoming ACP driver. The DMA
> engine for the i2s audio codec is part of the GPU.
>
> This exposes an amd gnb bus for the i2s codec to
> hang off of.
Could you be more specific about wha
On Thu, Aug 06, 2015 at 10:25:12AM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> Added runtime PM functionality to AMD I2S driver. This uses
> functionality from ACP IP methods.
Just add this (and the previous patch) in the driver. The patches are
so tiny it's not adding m
On Thu, Aug 06, 2015 at 10:25:11AM -0400, Alex Deucher wrote:
> +static int acp_pcm_suspend(struct device *dev)
> +{
> + return 0;
> +}
You should never need to add empty functions like this.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Typ
On Thu, Aug 06, 2015 at 10:25:10AM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> ACP IP block consists of dedicated DMA and I2S blocks. The PCM driver
> provides the DMA and CPU DAI components to ALSA core. Machine driver
> provides the audio functionality together with the
On Fri, Jul 17, 2015 at 01:41:16AM +0200, Rafael J. Wysocki wrote:
> On Thu, Jul 16, 2015 at 10:23 PM, Mark Brown wrote:
> > On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
> > I have to say I'm still not 100% clear that special casing platform
> > device
On Tue, Jul 14, 2015 at 02:47:04PM +0200, Tomeu Vizoso wrote:
> On 14 July 2015 at 13:07, Mark Brown wrote:
> > I'm not sure how I can be clearer here... you're replacing something
> > that is currently pure data with open coding in each device. That seems
> > li
On Wed, Jul 01, 2015 at 11:41:04AM +0200, Tomeu Vizoso wrote:
> So others can find out what depends on regulators, as specified
> in bindings/regulator/regulator.txt.
Reviewed-by: Mark Brown
from a regulator point of view.
-- next part --
A non-text attachme
On Thu, Jul 16, 2015 at 04:36:22PM +0100, Nariman Poushin wrote:
> +
> + if (regs[i].delay_us)
> + udelay(regs[i].delay_us);
This is a bit funky. While Takashi is correct that we could be running
in a spinlock equally this will mean that we could e
On Thu, Jul 16, 2015 at 04:45:25PM +0100, Nariman Poushin wrote:
> I will resend with a cover letter explaining the change from the previous
> patch set if that is the right thing to do.
No, that's fine. If you want to fix something like that just reply to
the cover letter with the extra informa
On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
> Delay matches of platform devices until late_initcall, when we are sure
> that all built-in drivers have been registered already. This is needed
> to prevent deferred probes because of some dependencies' drivers not
> having registere
On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote:
Please submit patches in the format covered in SubmittingPatches,
version information goes inside the [].
> Add support for writing sequences of registers / patches with specified
> delays (in microseconds). Logically separates the
On Tue, Jul 14, 2015 at 09:34:22AM +0200, Tomeu Vizoso wrote:
> On 13 July 2015 at 17:42, Mark Brown wrote:
> > No, I'm looking at how we already have all the "did all my dependencies
> > appear" logic in the core based on data provided by the drivers.
> Sorr
On Mon, Jul 13, 2015 at 02:10:45PM +0200, Tomeu Vizoso wrote:
> On 1 July 2015 at 19:38, Mark Brown wrote:
> > On Wed, Jul 01, 2015 at 11:41:06AM +0200, Tomeu Vizoso wrote:
> >> +static void tegra_max98090_get_dependencies(struct fwn
On Wed, Jul 01, 2015 at 11:41:06AM +0200, Tomeu Vizoso wrote:
> +static void tegra_max98090_get_dependencies(struct fwnode_handle *fwnode,
> + struct list_head *deps)
> +{
> + add_dependency(fwnode, "nvidia,i2s-controller", deps);
> + add_dependency(
On Tue, May 26, 2015 at 09:59:06PM +0300, Jyri Sarha wrote:
> -#ifdef CONFIG_OF
> -static const struct of_device_id hdmi_audio_codec_ids[] = {
> - { .compatible = "linux,hdmi-audio", },
> - { }
> -};
> -MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids);
> -#endif
There is actually a binding d
On Tue, May 26, 2015 at 09:59:05PM +0300, Jyri Sarha wrote:
> If an ASoC component device does not have a device tree node, use its
> parent's node instead, when looking for a matching DAI based on a
> device tree reference.
Applied, thanks.
-- next part --
A non-text attac
On Wed, May 27, 2015 at 12:43:08PM +0200, Daniel Vetter wrote:
> Just curious questions really, I probably don't understand what's exactly
> going on. But I do think that we need a more formal way for drm/snd to
> talk to each another (i915 is growing quite a few hairy things in that
> area outsid
On Sat, May 09, 2015 at 11:26:47AM +0100, Russell King wrote:
> Add a helper to create the IEC958 channel status from an ALSA
> snd_pcm_runtime structure, taking account of the sample rate and
> sample size.
This also looks good to me from an interface point of view:
Reviwed-by: M
On Sat, May 09, 2015 at 11:26:42AM +0100, Russell King wrote:
> Add a helper for the EDID like data structure, which is typically passed
> from a HDMI adapter to its associated audio driver. This informs the
> audio driver of the capabilities of the attached HDMI sink.
As far as I can tell people
On Sun, May 10, 2015 at 08:33:20PM +0100, Russell King - ARM Linux wrote:
> My personal view is that where we're dealing with PCM audio, the driver
> needs to set these bits correctly as there is nothing in userspace to
> do this. This provides an identical interface between each audio device
> w
On Sun, Apr 05, 2015 at 05:57:09PM +0200, Takashi Iwai wrote:
> At Thu, 02 Apr 2015 10:22:06 +0100,
> Russell King wrote:
> > +config SND_PCM_ELD
> > + bool
> I don't mind much adding this one, but a new Kconfig is always a
> question. I'd like to hear other's opinion, too.
One point in favou
On Wed, Apr 08, 2015 at 07:05:56PM +0800, Caesar Wang wrote:
> To fix pop noise when shutdown,the pop noise during shutdown
> is the pmic cutoff power of codec without any notice.
Applied, thanks.
Please do make an effort to only send patches to relevant people -
sending people patches that are
On Wed, Apr 08, 2015 at 04:52:08PM +0800, Caesar Wang wrote:
> +static void max98090_i2c_shutdown(struct i2c_client *i2c)
> +{
> + struct max98090_priv *max98090 = dev_get_drvdata(&i2c->dev);
> +
> + dev_info(&i2c->dev, "shut down device\n");
Remove this, it's adding noise.
> +
> + /
On Wed, Apr 08, 2015 at 04:52:07PM +0800, Caesar Wang wrote:
>
> Tested on veyron devices,play music then shutdown device,here carefully
> to speaker or headphone.
>
>
>
> Caesar Wang (1):
> ASoC: max98090: add shutdown callback for max98090
Don't send cover letters for single patches, if th
On Fri, Mar 27, 2015 at 09:16:17AM +0800, yakir wrote:
> On 2015å¹´03æ27æ¥ 02:16, Mark Brown wrote:
> >>+free_cpu_of_node:
> >>+ hdmi_audio_dai.cpu_of_node = NULL;
> >>+ hdmi_audio_dai.platform_of_node = NULL;
> >>+free_priv_data:
>
On Sat, Feb 28, 2015 at 10:04:30PM -0500, Yakir Yang wrote:
> + ret = snd_soc_dai_set_fmt(cpu_dai, dai_fmt);
> + if (ret < 0) {
> + dev_err(cpu_dai->dev, "failed to set cpu_dai fmt.\n");
> + return ret;
> + }
You've already set this in the dai_link, no need to
On Sat, Feb 28, 2015 at 09:59:20PM -0500, Yakir Yang wrote:
> codec driver creat an standard alsa device, than config audio
> and report jack status through some callback interfaces that
> dw_hdmi driver support.
Looking at this it's not althogether clear to me how specific this is to
the Designw
On Tue, Mar 10, 2015 at 12:22:06AM +0100, Heiko Stuebner wrote:
> When {devm_}regulator_get returns -EPROBE_DEFER the driver in question will
> try probing again at a later time. So don't spam the log with failure messages
> as this is an expected result of probe ordering.
> -
On Wed, Feb 25, 2015 at 10:53:36PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
A
On Wed, Feb 25, 2015 at 10:53:38PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
A
On Wed, Feb 25, 2015 at 10:53:37PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
A
On Thu, Feb 26, 2015 at 10:20:00AM +0800, Shawn Guo wrote:
> Sorry that I did not make it clear in the cover-letter. But the first
> patch introduces a helper function clk_is_match(), on which all the
> other patches in the series depend. That said, the patch series should
> probably be handled
On Wed, Feb 25, 2015 at 10:53:37PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Applied, thanks.
-
On Wed, Feb 25, 2015 at 10:53:38PM +0800, Shawn Guo wrote:
> Since commit 035a61c314eb ("clk: Make clk API return per-user struct clk
> instances"), clk API users can no longer check if two struct clk
> pointers are pointing to the same hardware clock, i.e. struct clk_hw, by
Applied, thanks.
-
On Tue, Jan 20, 2015 at 08:16:25PM +0100, Jean-Francois Moine wrote:
> To create simple cards, the syntax of the simple-card does not follow
> the common binding of the device graphs
> (Documentation/devicetree/bindings/graph.txt).
Please be more specific, I really can't tell what this is supposed
On Wed, Jan 14, 2015 at 11:46:58AM +0100, Philipp Zabel wrote:
> So the question is mostly whether four I2S data pins with a single
> shared WS/SCK input should be called "four I2S ports with shared clocks"
> or "one I2S port with up to four data lanes". I'd lean towards the
> latter.
Yes, this i
On Fri, Jan 09, 2015 at 05:39:08PM +, Andrew Jackson wrote:
> In the light of our discussions elsewhere [1], shouldn't this
> be constrained by the number of hardware channels that the TDA998x
> supports too? That is, the maximum number of channels should
> be the lesser of sd[SAD_MX_CHAN_I]
On Thu, Jan 08, 2015 at 04:53:04PM +0200, Jyri Sarha wrote:
> BTW, the HDMI codec is now completely unused, since my OMAP4+ HDMI audio
> patches were merged (it uses dummy codec) and my BBB HDMI audio patches were
> never merged.
Might those BBB ones turn up sometime?
-- next part ---
On Thu, Jan 08, 2015 at 05:42:57PM +0100, Jean-Francois Moine wrote:
> Examples:
> - for the Cubox:
> audio-inputs = "i2s", "spdif";
> - for some other board with I2S on the pins 3 and 4 only:
> audio-inputs = "none", "none", "i2s", "i2s";
> - for a fully wired TDA9983B (no driver
On Wed, Jan 07, 2015 at 03:10:47PM +, Andrew Jackson wrote:
> On 01/07/15 10:51, Jean-Francois Moine wrote:
> > This patch adds a CODEC to the NXP TDA998x HDMI transmitter.
> >
> > The CODEC handles both I2S and S/PDIF inputs.
Please delete unneeded context from your messages, it makes it muc
On Wed, Jan 07, 2015 at 05:18:20PM +, Andrew Jackson wrote:
> I understand your difficulty! I was just wanting something to clarify the
> meaning of the value without reference to the driver source.
> You could add something like this to your existing explanation: "The value
> describes whi
On Mon, Dec 29, 2014 at 07:37:21PM +0200, Jyri Sarha wrote:
> On 12/29/2014 06:52 PM, Mark Brown wrote:
> >So, I'm not seeing *any* interest here from any other HDMI users. This
> >is a continuing theme with HDMI patches and is really very concerning,
> >everyone appe
On Thu, Oct 23, 2014 at 09:09:35AM +0200, Jean-Francois Moine wrote:
> +struct hdmi_data {
> + int (*get_audio)(struct device *dev,
> + int *max_channels,
> + int *rate_mask,
> + int *fmt);
> + void (*audio_switch)(struct devic
On Thu, Oct 23, 2014 at 10:32:49AM +0200, Jean-Francois Moine wrote:
> The NXP TDA998x HDMI transmitter may transmit audio to the HDMI link
> from 2 different sources, I2S and S/PDIF.
So, I'm not seeing *any* interest here from any other HDMI users. This
is a continuing theme with HDMI patches an
On Mon, Dec 15, 2014 at 09:10:26PM +0800, Kuankuan.Yang wrote:
> Hi Mark & Russell:
Please don't top post, that way people have some context for what you're
saying - look at how people normally format their mails on thelist.
> In that way, dt will only need compatible for creating sound device. i
On Sat, Dec 13, 2014 at 12:12:19AM +0100, AH wrote:
> Mark Brown wrote on 12.12.2014 17:36:
> >On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote:
> >>+ kfree(ptask);
> >>+
> >>+ if (empty)
> >>+ br
t; ERROR: "sti_layer_to_str" [drivers/gpu/drm/sti/sti_hqvdp.ko] undefined!
Today's ARM allmodconfig failed to build in -next due to the ST DRM
drivers, they build several modules which reference each other but
several of the symbols are not exported, leading to build failures.
Fix thi
On Mon, Dec 15, 2014 at 10:40:29AM +, Russell King - ARM Linux wrote:
> Including details like this (because ASoC needs a separate DT node) is
> the wrong approach.
And indeed there should be no Linux-internal reason for that - we should
be able to use whatever DT node makes sense, if there's
On Mon, Dec 15, 2014 at 08:08:21AM +, Build bot for Mark Brown wrote:
> arm-allmodconfig
> ERROR: "sti_hqvdp_create" [drivers/gpu/drm/sti/sticompositor.ko] undefined!
> ERROR: "sti_drm_plane_init" [drivers/gpu/drm/sti/sti_hqvdp.ko] undefined!
> ERROR: &qu
On Mon, Dec 15, 2014 at 09:28:41AM +0100, Andrzej Hajda wrote:
> On 12/12/2014 05:52 PM, Mark Brown wrote:
> > On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote:
> > I don't know about anyone else but I'm having a hard time reading the
> > restrack name,
On Wed, Dec 10, 2014 at 04:48:20PM +0100, Andrzej Hajda wrote:
> restrack framework allows tracking presence of resources with dynamic life
> time. Typical example of such resources are all resources provided by device
I don't know about anyone else but I'm having a hard time reading the
restrack
On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote:
> track is a generic framework for safe tracking presence of any kernel objects
> having an id. There are no special requirements about type of object or its
> id. Id shall be unique.
This is pretty confusing, when it talks about "kern
On Wed, Dec 10, 2014 at 04:48:22PM +0100, Andrzej Hajda wrote:
> Regulators supports various methods of lookup.
> The patch adds restrack support only to DT based regulators.
Why, what does this mean and how might one use it? I've not looked at
the code since I don't know what it's supposed to ac
601 - 700 of 816 matches
Mail list logo
