* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Russell King - ARM Linux @ 2014-01-27 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127204441.GZ11841@sirena.org.uk>
On Mon, Jan 27, 2014 at 08:44:41PM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
>
> > + eld_ver = eld[0] >> 3;
> > + if (eld_ver != 2 && eld_ver != 31)
> > + return 0;
> > +
> > + mnl = eld[4] & 0x1f;
> > + if (mnl > 16)
> > + return 0;
> > +
> > + sad_count = eld[5] >> 4;
> > + sad = eld + 20 + mnl;
>
> Can this parsing code be factored out - it (or large parts of it) should
> be usable by other HDMI devices shouldn't it?
Yes, preferably as a generic ALSA helper rather than an ASoC helper -
I don't see any need for this to be ASoC specific (I have a pure ALSA
driver which has very similar code in it.)
--
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".
^ permalink raw reply
* [PATCH RFC v3 4/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Mark Brown @ 2014-01-27 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86fcca2ecf302a695e7fd8199a1d635a67bbfcc8.1390836773.git.jsarha@ti.com>
On Mon, Jan 27, 2014 at 05:37:53PM +0200, Jyri Sarha wrote:
> Add machine driver support for BeagleBone-Black and other boards with
> tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
> port in I2S mode. McASP produces the bit clock for the i2s bus from
> the masted clock by a simple divider and the available sample rates
I have to say I agree with Lars' comments about where the code to set
the constraints is here - I don't doubt that these limitations are valid
but it would be better to factor them into the relevant chip drivers so
that other systems with similar limitations can be handled correctly
too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/9e5ad4e2/attachment.sig>
^ permalink raw reply
* [PATCH RFC v3 3/8] ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
From: Mark Brown @ 2014-01-27 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27d041ee149081cd9b401939d4382e73fba5e7a5.1390836773.git.jsarha@ti.com>
On Mon, Jan 27, 2014 at 05:37:52PM +0200, Jyri Sarha wrote:
> Make BCLK divider setting implicite in hw_params call if McASP device
> is the bit clock master on the audio serial bus.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/264185d7/attachment.sig>
^ permalink raw reply
* [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Russell King - ARM Linux @ 2014-01-27 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127204302.GY11841@sirena.org.uk>
On Mon, Jan 27, 2014 at 08:43:02PM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
>
> > + - compatible: must be "nxp,tda998x-codec".
> > + - audio-ports: one or two values.
> > + The first value defines the I2S input port.
> > + The second one, if present, defines the S/PDIF input port.
>
> I take it these are port numbers on the device and it's not possible to
> do something like having multiple I2S ports?
You can feed it with multiple synchronised I2S streams for the additional
channels.
--
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".
^ permalink raw reply
* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-01-27 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d99e90932aad1a644fa32ff22fd2cb56b830341b.1390813481.git.moinejf@free.fr>
On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
> + eld_ver = eld[0] >> 3;
> + if (eld_ver != 2 && eld_ver != 31)
> + return 0;
> +
> + mnl = eld[4] & 0x1f;
> + if (mnl > 16)
> + return 0;
> +
> + sad_count = eld[5] >> 4;
> + sad = eld + 20 + mnl;
Can this parsing code be factored out - it (or large parts of it) should
be usable by other HDMI devices shouldn't it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/2ec34ffc/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] clk: shmobile rcar-gen2 fixes
From: Mike Turquette @ 2014-01-27 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2118020.lZAv6IL4Xy@avalon>
Quoting Laurent Pinchart (2014-01-21 05:00:28)
> Hi Mike,
>
> On Wednesday 08 January 2014 00:06:39 Laurent Pinchart wrote:
> > On Tuesday 07 January 2014 17:59:01 Geert Uytterhoeven wrote:
> > > On Tue, Jan 7, 2014 at 5:47 PM, Laurent Pinchart wrote:
> > > > Geert, could you please verify that the series fixes your QSPI clock
> > > > issues with the Koelsch board ?
> > > >
> > > > Laurent Pinchart (2):
> > > > clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
> > > > clk: shmobile: rcar-gen2: Fix qspi divisor
> > >
> > > Thanks, both:
> > >
> > > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thank you.
> >
> > Mike, could you please pick those patches up for v3.14 ?
>
> Ping ?
Hi Laurent,
I'll send these as part of my fixes tag, probably next week.
Regards,
Mike
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Mark Brown @ 2014-01-27 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22fafd7e11771ffc25c84ff609d18039f07b7295.1390813481.git.moinejf@free.fr>
On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
> + - compatible: must be "nxp,tda998x-codec".
> + - audio-ports: one or two values.
> + The first value defines the I2S input port.
> + The second one, if present, defines the S/PDIF input port.
I take it these are port numbers on the device and it's not possible to
do something like having multiple I2S ports?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/d73158a4/attachment.sig>
^ permalink raw reply
* [PATCH 2/4] ASoC: tda998x: add a codec driver for TDA998x
From: Mark Brown @ 2014-01-27 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a62784e8778d06512d49a24dcf59ff9e45839902.1390813481.git.moinejf@free.fr>
On Sun, Jan 26, 2014 at 07:45:36PM +0100, Jean-Francois Moine wrote:
> select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
> select SND_SOC_TAS5086 if I2C
> + select SND_SOC_TDA998X if I2C
> +config SND_SOC_TDA998X
> + tristate
> + depends on OF
> + default y if DRM_I2C_NXP_TDA998X=y
> + default m if DRM_I2C_NXP_TDA998X=m
> +
These two things don't seem to agree with each other, and I expect this
breaks the build for ALL_CODECS.
> +static void tda_get_encoder(struct tda_priv *priv)
> +{
> + struct snd_soc_codec *codec = priv->codec;
> + struct device_node *np;
> + struct i2c_client *i2c_client;
> + static const struct of_device_id tda_dt[] = {
> + { .compatible = "nxp,tda998x" },
> + { },
> + };
> +
> + /* search the tda998x device */
> + np = of_find_matching_node_and_match(NULL, tda_dt, NULL);
> + if (!np || !of_device_is_available(np)) {
> + dev_err(codec->dev, "No tda998x in DT\n");
> + return;
> + }
> + i2c_client = of_find_i2c_device_by_node(np);
> + of_node_put(np);
> + if (!i2c_client) {
> + dev_err(codec->dev, "no tda998x i2c client\n");
> + return;
> + }
> + if (!i2c_get_clientdata(i2c_client)) {
> + dev_err(codec->dev, "tda998x not initialized\n");
> + return;
> + }
> +
> + priv->i2c_client = i2c_client;
> +}
The normal way of doing this would be to make the device a MFD - that
way the frameworks make sure probe ordering and so on are sorted out.
Other than that this looks basically OK, a few small comments below.
> + /* give the audio input type and ports to the HDMI encoder */
> + format = start ? priv->dai_id : 0;
It's not clear to me what the above is doing (I think I know but it
requires thinking about rather than being clear).
> +static const struct snd_soc_dai_driver tda998x_dai[] = {
> + {
> + .name = "i2s-hifi",
Coding style, indents are tabs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/f42da9a3/attachment-0001.sig>
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Russell King - ARM Linux @ 2014-01-27 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390854331.23180.22.camel@localhost.localdomain>
On Mon, Jan 27, 2014 at 09:25:31PM +0100, Yann Droneaud wrote:
> ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
> the infamous dma_mask pointer. So perhaps my solution is better.
>
> This solution (adding dma_mask in pdev_archdata) is already in use in
> powerpc architecture. See arch/powerpc/kernel/setup-common.c
>
> The advantage of this solution is that it makes a dma_mask placeholder
> available to statically allocated platform_device struct, while mine
> only address the problem for platform_device struct allocated with
> platform_device_alloc().
As I've already said in this thread, the basic problem comes from DT's
platform device creation. It's the responsibility of the device creator
to set the dma_mask pointer appropriately, and DT doesn't do that. So,
DT needs to be fixed rather than everyone introducing their own
workarounds for this.
> I'm also considering using dma_set_mask_and_coherent() in
> platform_device_register_full() and drivers using
> platform_device_alloc().
As the one who introduced dma_set_mask_and_coherent, consider this a
strong NAK on that. The reason is dma_set_mask_and_coherent() is
for drivers to set their requirements, not for the bus requirements
to be set in the first place.
It also means that drivers which need no DMA support are subjected to
DMA restrictions (in that dma_set_mask_and_coherent can error out if
the platform can't support the DMA mask.)
--
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".
^ permalink raw reply
* [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
From: Kevin Hilman @ 2014-01-27 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123184951.GJ7993@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Kevin Hilman <khilman@linaro.org> [140123 09:55]:
>> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>>
>> > On 01/20/2014 10:06 PM, Nishanth Menon wrote:
>> >> Move all OMAP4 PM errata initializations to centralized location in
>> >> omap4_pm_init_early. This allows for users to utilize the erratas
>> >> in various submodules as needed.
>> >>
>> > Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> >
>> > This patch fixes build failure caused by patch
>> > https://patchwork.kernel.org/patch/3084521/
>> > in case if SMP is not enabled.
>>
>> So does that mean that that patch can now be applied as is?
>>
>> We could sure use that fix (or equivalent) for CPUidle breakage on 4460.
>
> Yeah, seems OK to me, feel free to apply it directly:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
OK, I've picked up both $SUBJECT patch and the one from the above
patchworks link and will queue them up for v3.14-rc (and have added your
Ack to both.)
Thanks,
Kevin
^ permalink raw reply
* [PATCH] clk: sunxi: fix overflow when setting up divided factors
From: Mike Turquette @ 2014-01-27 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390613561-28636-1-git-send-email-emilio@elopez.com.ar>
Quoting Emilio L?pez (2014-01-24 17:32:41)
> Currently, we are allocating space for two pointers, when we actually
> may need to store three of them (two divisors plus the original clock).
> Fix this, and change sizeof(type) to sizeof(*var) to keep checkpatch.pl
> happy.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
> ---
>
> Hi Mike,
>
> Is there any chance you can include this oneliner on your second part of
> the pull request to Linus?
Done.
Regards,
Mike
>
> Cheers,
>
> Emilio
>
> drivers/clk/sunxi/clk-sunxi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 659e4ea..abb6c5a 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -875,7 +875,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
> if (!clk_data)
> return;
>
> - clks = kzalloc(SUNXI_DIVS_MAX_QTY * sizeof(struct clk *), GFP_KERNEL);
> + clks = kzalloc((SUNXI_DIVS_MAX_QTY+1) * sizeof(*clks), GFP_KERNEL);
> if (!clks)
> goto free_clkdata;
>
> --
> 1.8.5.3
>
^ permalink raw reply
* [PATCH v2 1/7] cpufreq: cpufreq-cpu0: allow optional safe voltage during frequency transitions
From: Mike Turquette @ 2014-01-27 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390047057-2239-2-git-send-email-thomas.ab@samsung.com>
Quoting Thomas Abraham (2014-01-18 04:10:51)
> From: Thomas Abraham <thomas.ab@samsung.com>
>
> On some platforms such as the Samsung Exynos, changing the frequency
> of the CPU clock requires changing the frequency of the PLL that is
> supplying the CPU clock. To change the frequency of the PLL, the CPU
> clock is temporarily reparented to another parent clock.
>
> The clock frequency of this temporary parent clock could be much higher
> than the clock frequency of the PLL at the time of reparenting. Due
> to the temporary increase in the CPU clock speed, the CPU (and any other
> components in the CPU clock domain such as dividers, mux, etc.) have to
> to be operated at a higher voltage level, called the safe voltage level.
> This patch adds optional support to temporarily switch to a safe voltage
> level during CPU frequency transitions.
>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
I'm not a fan of this change. This corner case should be abstracted away
somehow. I had talked to Chander Kayshap previously about handling
voltage changes in clock notifier callbacks, which then renders any
voltage change as a trivial part of the clock rate transition. That
means that this "safe voltage" thing could be handled automagically
without any additional code in the CPUfreq driver.
There are two nice ways to do this with the clock framework. First is
explicit re-parenting with voltage scaling done in the clock rate-change
notifiers:
clk_set_parent(cpu_clk, temp_parent);
/* implicit voltage scaling to "safe voltage" happens above */
clk_set_rate(pll, some_rate);
clk_set_parent(cpu_clk, pll);
/* implicit voltage scaling to nominal OPP voltage happens above */
The above sequence would require a separate exnyos CPUfreq driver, due
to the added clk_set_parent logic.
The second way to do this is to abstract the clk re-muxing logic out
into the clk driver, which would allow cpufreq-cpu0 to be used for the
exynos chips.
I'm more a fan of explicitly listing the Exact Steps for the cpu opp
transition in a separate exynos-specific CPUfreq driver, but that's
probably an unpopular view.
Regards,
Mike
> ---
> .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 7 ++++
> drivers/cpufreq/cpufreq-cpu0.c | 37 +++++++++++++++++--
> 2 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> index f055515..37453ab 100644
> --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
> @@ -19,6 +19,12 @@ Optional properties:
> - cooling-min-level:
> - cooling-max-level:
> Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
> +- safe-opp: Certain platforms require that during a opp transition,
> + a system should not go below a particular opp level. For such systems,
> + this property specifies the minimum opp to be maintained during the
> + opp transitions. The safe-opp value is a tuple with first element
> + representing the safe frequency and the second element representing the
> + safe voltage.
>
> Examples:
>
> @@ -36,6 +42,7 @@ cpus {
> 396000 950000
> 198000 850000
> >;
> + safe-opp = <396000 950000>
> clock-latency = <61036>; /* two CLK32 periods */
> #cooling-cells = <2>;
> cooling-min-level = <0>;
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index 0c12ffc..075d3d1 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++ b/drivers/cpufreq/cpufreq-cpu0.c
> @@ -27,6 +27,8 @@
>
> static unsigned int transition_latency;
> static unsigned int voltage_tolerance; /* in percentage */
> +static unsigned long safe_frequency;
> +static unsigned long safe_voltage;
>
> static struct device *cpu_dev;
> static struct clk *cpu_clk;
> @@ -64,17 +66,30 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
> volt_old = regulator_get_voltage(cpu_reg);
> }
>
> - pr_debug("%u MHz, %ld mV --> %u MHz, %ld mV\n",
> + pr_debug("\n\n%u MHz, %ld mV --> %u MHz, %ld mV\n",
> old_freq / 1000, volt_old ? volt_old / 1000 : -1,
> new_freq / 1000, volt ? volt / 1000 : -1);
>
> /* scaling up? scale voltage before frequency */
> - if (!IS_ERR(cpu_reg) && new_freq > old_freq) {
> + if (!IS_ERR(cpu_reg) && new_freq > old_freq &&
> + new_freq >= safe_frequency) {
> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> if (ret) {
> pr_err("failed to scale voltage up: %d\n", ret);
> return ret;
> }
> + } else if (!IS_ERR(cpu_reg) && old_freq < safe_frequency) {
> + /*
> + * the scaled up voltage level for the new_freq is lower
> + * than the safe voltage level. so set safe_voltage
> + * as the intermediate voltage level and revert it
> + * back after the frequency has been changed.
> + */
> + ret = regulator_set_voltage_tol(cpu_reg, safe_voltage, tol);
> + if (ret) {
> + pr_err("failed to set safe voltage: %d\n", ret);
> + return ret;
> + }
> }
>
> ret = clk_set_rate(cpu_clk, freq_exact);
> @@ -86,7 +101,8 @@ static int cpu0_set_target(struct cpufreq_policy *policy, unsigned int index)
> }
>
> /* scaling down? scale voltage after frequency */
> - if (!IS_ERR(cpu_reg) && new_freq < old_freq) {
> + if (!IS_ERR(cpu_reg) &&
> + (new_freq < old_freq || new_freq < safe_frequency)) {
> ret = regulator_set_voltage_tol(cpu_reg, volt, tol);
> if (ret) {
> pr_err("failed to scale voltage down: %d\n", ret);
> @@ -116,6 +132,8 @@ static struct cpufreq_driver cpu0_cpufreq_driver = {
>
> static int cpu0_cpufreq_probe(struct platform_device *pdev)
> {
> + const struct property *prop;
> + struct dev_pm_opp *opp;
> struct device_node *np;
> int ret;
>
> @@ -165,13 +183,24 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
> goto out_put_node;
> }
>
> + prop = of_find_property(np, "safe-opp", NULL);
> + if (prop) {
> + if (prop->value && (prop->length / sizeof(u32)) == 2) {
> + const __be32 *val;
> + val = prop->value;
> + safe_frequency = be32_to_cpup(val++);
> + safe_voltage = be32_to_cpup(val);
> + } else {
> + pr_err("invalid safe-opp level specified\n");
> + }
> + }
> +
> of_property_read_u32(np, "voltage-tolerance", &voltage_tolerance);
>
> if (of_property_read_u32(np, "clock-latency", &transition_latency))
> transition_latency = CPUFREQ_ETERNAL;
>
> if (!IS_ERR(cpu_reg)) {
> - struct dev_pm_opp *opp;
> unsigned long min_uV, max_uV;
> int i;
>
> --
> 1.6.6.rc2
>
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Yann Droneaud @ 2014-01-27 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127181836.GH26766@pengutronix.de>
Hi,
Le lundi 27 janvier 2014 ? 19:18 +0100, Uwe Kleine-K?nig a ?crit :
> On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
> > The dma_mask for a device structure is a pointer. This pointer
> > needs to be set up before the dma mask can actually be set. Most
> > frameworks in the kernel take care of setting this up properly but
> > platform devices that don't follow a regular bus structure may not
> > ever have this set. As a result, checks such as dma_capable will
> > always return false on a raw platform device and dma_set_mask will
> > always return -EIO. Fix this by adding a dma_mask in the
> > platform_device archdata and setting it to be the dma_mask. Devices
> > used in other frameworks can change this as needed.
> >
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Suggested-by: Kumar Gala <galak@codeaurora.org>
> > Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
> Hello,
>
> there is another non-platform dependant approach available, that might
> be worth to evaluate:
>
> http://mid.gmane.org/1390817152-30898-1-git-send-email-ydroneaud at opteya.com
>
ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
the infamous dma_mask pointer. So perhaps my solution is better.
This solution (adding dma_mask in pdev_archdata) is already in use in
powerpc architecture. See arch/powerpc/kernel/setup-common.c
The advantage of this solution is that it makes a dma_mask placeholder
available to statically allocated platform_device struct, while mine
only address the problem for platform_device struct allocated with
platform_device_alloc().
A possible drawback of adding dma_mask in pdev_archdata and setting the
pointer in arch_setup_pdev_archdata() may be that a dma_mask setup prior
calling platform_device_register() got overwritten.
For example at91rm9200_usbh_device in
arch/arm/mach-at91/at91rm9200_devices.c (it's the first occurence
returned by cscope).
So I guess there's not yet a perfect solution (add dma_mask to struct
platform_device instead of hidding it either in struct pdev_archdata or
struct platform_object ?).
BTW, I've started to convert some drivers just to try my first option.
I'm also considering using dma_set_mask_and_coherent() in
platform_device_register_full() and drivers using
platform_device_alloc(). But I'm not sure about it : will it break
something with the additionals check on the mask, just as the failure
reported in the message ("dma_set_mask will always return -EIO.") ?
[1]
http://lkml.kernel.org/r/20140124154002.GF31570 at twins.programming.kicks-ass.net
Regards.
--
Yann Droneaud
OPTEYA
^ permalink raw reply
* [PATCH v4 15/24] drm/i2c: tda998x: use irq for connection status and EDID read
From: Russell King - ARM Linux @ 2014-01-27 20:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181438.1353afc7@armhf>
On Sat, Jan 25, 2014 at 06:14:38PM +0100, Jean-Francois Moine wrote:
> This patch adds the optional treatment of the tda998x IRQ.
>
> The interrupt function is used to know the display connection status
> without polling and to speedup reading the EDID.
>
> The IRQ number is defined in the i2c client either by platform data or
> in the DT.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
I don't see where you free the interrupt in this - you used to, but it
appears that hunk got dropped?
--
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".
^ permalink raw reply
* [PATCH v4 24/24] drm/i2c: tda998x: adjust the audio clock divider for S/PDIF
From: Russell King - ARM Linux @ 2014-01-27 20:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181436.5c443251@armhf>
On Sat, Jan 25, 2014 at 06:14:36PM +0100, Jean-Francois Moine wrote:
> According to some tests on the Cubox (Marvell Armada 510 + TDA19988),
> the S/PDIF input asks for a greater audio clock divider.
>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c
> index b4827c0..e4dfcb4 100644
> --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> @@ -679,10 +679,14 @@ tda998x_configure_audio(struct tda998x_priv *priv,
> * There is no detailed info in the datasheet, so we just
> * assume 100MHz requires larger divider.
> */
> + adiv = AUDIO_DIV_SERCLK_8;
> if (mode->clock > 100000)
> - adiv = AUDIO_DIV_SERCLK_16;
> - else
> - adiv = AUDIO_DIV_SERCLK_8;
> + adiv++; /* AUDIO_DIV_SERCLK_8 */
> +
> + /* S/PDIF asks for a larger divider */
> + if (p->audio_format == AFMT_SPDIF)
> + adiv++; /* AUDIO_DIV_SERCLK_16 or _32 */
I'm not sure these comments are quite right... You start off with
adiv at AUDIO_DIV_SERCLK_8, and then you increment it, but the
comment says it's AUDIO_DIV_SERCLK_8 ? Shouldn't it become
AUDIO_DIV_SERCLK_16 ?
Please review the above change yourself. :)
--
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".
^ permalink raw reply
* [PATCH v4 12/24] drm/i2c: tda998x: check the CEC device creation
From: Russell King - ARM Linux @ 2014-01-27 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181443.7981862e@armhf>
On Sat, Jan 25, 2014 at 06:14:43PM +0100, Jean-Francois Moine wrote:
> This patch checks if the CEC device is well created at intialization
> time.
>
> Tested-by: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
Acked-by: Russell King <rmk+kernel@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".
^ permalink raw reply
* [PATCH v4 07/24] drm/i2c: tda998x: set the video mode from the adjusted value
From: Russell King - ARM Linux @ 2014-01-27 19:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140125181443.5c079d76@armhf>
On Sat, Jan 25, 2014 at 06:14:43PM +0100, Jean-Francois Moine wrote:
> @@ -896,9 +897,9 @@ tda998x_encoder_mode_set(struct drm_encoder *encoder,
> * TDA19988 requires high-active sync at input stage,
> * so invert low-active sync provided by master encoder here
> */
> - if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NHSYNC)
> reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_H_TGL);
> - if (mode->flags & DRM_MODE_FLAG_NVSYNC)
> + if (adj_mode->flags & DRM_MODE_FLAG_NVSYNC)
> reg_set(priv, REG_VIP_CNTRL_3, VIP_CNTRL_3_V_TGL);
>
> /*
It looks like this comment from Darren has not been addressed (or
commented on). Can you discuss this with Darren and come to some sort
of solution please, otherwise applying this patch set is going to cause
a regression. Thanks.
=8<
Using the adj_mode->flags breaks a workaround I had done on BeagleBone Black
(tilcdc + tda998x) to resolve an issue with out of spec syncs from the
tlcdc. I invert the HSYNC in adj_mode->flags but don't want the tda998x to
really know that I am doing that so I use adj_mode in the tilcdc driver, and
mode here in the tda998x driver. The theory being adj_mode contains whatever
workarounds I need to do for the driving device and mode has the pristine
values that I want to send to the monitor. I would need to look if there is a
different way to solve this as I am guessing you are actually using adj_mode in
the manner it was intended.
Otherwise this patch series is working on BeagleBone Black - I have only tried
video so far (not audio).
Darren
=8<
--
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".
^ permalink raw reply
* [PATCH] clk: Export more clk-provider functions
From: Mike Turquette @ 2014-01-27 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390016837-24837-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-17 19:47:17)
> Allow drivers to be compiled as modules by exporting more clock
> provider functions.
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
I've taken this into part 2 of my pull request for 3.14.
Regards,
Mike
> ---
> drivers/clk/clk.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 0b27b543dacf..2e83cf643db0 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -547,16 +547,19 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
> {
> return !clk ? NULL : clk->hw;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_hw);
>
> u8 __clk_get_num_parents(struct clk *clk)
> {
> return !clk ? 0 : clk->num_parents;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_num_parents);
>
> struct clk *__clk_get_parent(struct clk *clk)
> {
> return !clk ? NULL : clk->parent;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_parent);
>
> struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
> {
> @@ -570,6 +573,7 @@ struct clk *clk_get_parent_by_index(struct clk *clk, u8 index)
> else
> return clk->parents[index];
> }
> +EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
>
> unsigned int __clk_get_enable_count(struct clk *clk)
> {
> @@ -601,6 +605,7 @@ unsigned long __clk_get_rate(struct clk *clk)
> out:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_rate);
>
> unsigned long __clk_get_flags(struct clk *clk)
> {
> @@ -649,6 +654,7 @@ bool __clk_is_enabled(struct clk *clk)
> out:
> return !!ret;
> }
> +EXPORT_SYMBOL_GPL(__clk_is_enabled);
>
> static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
> {
> @@ -740,6 +746,7 @@ out:
>
> return best;
> }
> +EXPORT_SYMBOL_GPL(__clk_mux_determine_rate);
>
> /*** clk api ***/
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Lars-Peter Clausen @ 2014-01-27 19:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E6B613.9050400@ti.com>
On 01/27/2014 08:40 PM, Jyri Sarha wrote:
> On 01/27/2014 06:32 PM, Lars-Peter Clausen wrote:
>> On 01/27/2014 05:17 PM, Jyri Sarha wrote:
>>> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>>>> Hi,
>>>>
>>>> I think you should try to get this in sync with the work Jean-Francois is
>>>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>>>> definitely the right approach, compared to the rather 'interesting'
>>>> constraints stuff you do in patch 4.
>>>>
>>>
>>> Oh, Jean-Francois's patches are now out. I'll take those into use, but I am
>>> afraid it still does not save me from the constraint stuff.
>>>
>>> The most complex piece of code comes from limited sample-rate availability,
>>> which is coming Beaglebone-Black desing (available i2s master clock), not
>>> from the HDMI encoder itself. It does not help with the stereo only
>>> limitation either, because it comes from the one wire only audio data
>>> connection on BBB.
>>>
>>> Support for S16_LE could maybe be added if the tda998x specific codec would
>>> fiddle with CTS_N predivider-setting (K select) according to the used sample
>>> width. But it appears Cobox plays all the sample formats fine without this
>>> change, so the question is if playing around with CTS_N predivider would
>>> break already working support there (something to be tested).
>>
>> The ASoC core will set the constraints for the audio format/rate to the
>> intersection of what is supported by the CODEC and the CPU DAI. So if the
>> limitation comes from the CPU DAI the constraints should be applied there
>> and not in the machine driver. Similar if the tda998x only supports 32 bit
>> samples it should advertise this and the compound card will only support 32
>> bit samples.
>>
>
> Yes. I know. But these limitations come from the run time setup of the audio
> serial bus and those details are not available to the cpu dai at the register
> time.
>
> If more of the McASP configuration data would be moved to DT, instead of giving
> it in set_sysclk, set_fmt, etc. calls it would be possible for the driver code
> produce more accurate constraints at register time. However that would change
> McASP driver a lot and would possibly break some of the legacy support.
There is nothing wrong with setting the constraints based on the parameters
passed to set_sysclk or set_fmt, etc. In fact this is something that is often
done by drivers.
- Lars
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E68A00.5030207@metafoo.de>
On 01/27/2014 06:32 PM, Lars-Peter Clausen wrote:
> On 01/27/2014 05:17 PM, Jyri Sarha wrote:
>> On 01/27/2014 05:51 PM, Lars-Peter Clausen wrote:
>>> Hi,
>>>
>>> I think you should try to get this in sync with the work Jean-Francois is
>>> currently doing[1]. Having the HDMI transmitter register a CODEC device is
>>> definitely the right approach, compared to the rather 'interesting'
>>> constraints stuff you do in patch 4.
>>>
>>
>> Oh, Jean-Francois's patches are now out. I'll take those into use, but I am
>> afraid it still does not save me from the constraint stuff.
>>
>> The most complex piece of code comes from limited sample-rate availability,
>> which is coming Beaglebone-Black desing (available i2s master clock), not
>> from the HDMI encoder itself. It does not help with the stereo only
>> limitation either, because it comes from the one wire only audio data
>> connection on BBB.
>>
>> Support for S16_LE could maybe be added if the tda998x specific codec would
>> fiddle with CTS_N predivider-setting (K select) according to the used sample
>> width. But it appears Cobox plays all the sample formats fine without this
>> change, so the question is if playing around with CTS_N predivider would
>> break already working support there (something to be tested).
>
> The ASoC core will set the constraints for the audio format/rate to the
> intersection of what is supported by the CODEC and the CPU DAI. So if the
> limitation comes from the CPU DAI the constraints should be applied there
> and not in the machine driver. Similar if the tda998x only supports 32 bit
> samples it should advertise this and the compound card will only support 32
> bit samples.
>
Yes. I know. But these limitations come from the run time setup of the
audio serial bus and those details are not available to the cpu dai at
the register time.
If more of the McASP configuration data would be moved to DT, instead of
giving it in set_sysclk, set_fmt, etc. calls it would be possible for
the driver code produce more accurate constraints at register time.
However that would change McASP driver a lot and would possibly break
some of the legacy support.
Best regards,
Jyri
^ permalink raw reply
* [GIT PULL] ARM: mvebu: fixes for v3.13.x/v3.14-rc1
From: Jason Cooper @ 2014-01-27 19:34 UTC (permalink / raw)
To: linux-arm-kernel
Kevin,
Here's the pull we discussed earlier. Sorry my "send pull requests"
cron job failed me.
As usual, been in -next (a little long this time ;-) ), incremental from
tags/mvebu-fixes-3.13 to tags/mvebu-fixes-3.13-2 in the mvebu/fixes
branch.
thx,
Jason.
The following changes since commit f8b94beb7e6a374cb0de531b72377c49857b35ca:
i2c: mv64xxx: Document the newly introduced Armada XP A0 compatible (2014-01-14 02:09:17 +0000)
are available in the git repository at:
git://git.infradead.org/linux-mvebu.git tags/mvebu-fixes-3.13-2
for you to fetch changes up to 19e61d41404fe4094c2d54943dbf883d9bbca864:
ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP) (2014-01-21 00:55:47 +0000)
----------------------------------------------------------------
mvebu fixes for v3.13 (incremental #2)
- allow building and booting DT and non-DT plat-orion SoCs
- catch proper return value for kirkwood_pm_init()
- properly check return of of_iomap to solve boot hangs (mirabox, others)
- remove a compile warning on Armada 370 with non-SMP.
----------------------------------------------------------------
Arnaud Ebalard (1):
ARM: mvebu: fix compilation warning on Armada 370 (i.e. non-SMP)
Ezequiel Garcia (1):
ARM: kirkwood: kirkwood_pm_init() should return void
Gregory CLEMENT (1):
ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed
Sebastian Hesselbarth (1):
ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER
arch/arm/mach-kirkwood/pm.c | 4 ++--
arch/arm/mach-mvebu/mvebu-soc-id.c | 2 +-
arch/arm/plat-orion/irq.c | 47 +++++++++++++++++++++++++++++++++++++
drivers/irqchip/irq-armada-370-xp.c | 4 ++--
4 files changed, 52 insertions(+), 5 deletions(-)
^ permalink raw reply
* [alsa-devel] [PATCH RFC v3 0/8] Beaglebone-Black HDMI audio
From: Jyri Sarha @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127190641.273890c6@armhf>
On 01/27/2014 08:06 PM, Jean-Francois Moine wrote:
> On Mon, 27 Jan 2014 18:17:54 +0200
> Jyri Sarha <jsarha@ti.com> wrote:
>
>> Support for S16_LE could maybe be added if the tda998x specific codec
>> would fiddle with CTS_N predivider-setting (K select) according to the
>> used sample width. But it appears Cobox plays all the sample formats
>> fine without this change, so the question is if playing around with
>> CTS_N predivider would break already working support there (something to
>> be tested).
>
> Jyri,
>
> Setting
>
> cts_n = CTS_N_M(3) | CTS_N_K(1);
>
> instead of K(3) in the I2S sequence of tda998x_configure_audio() in the
> tda998x driver works fine for me with S16_LE and S24_LE.
>
> Does this solve your problem?
>
With that setting S16_LE works, but S32_LE does not. S24_LE does not
really work at all on BBB, or it works but because the 8 most
significant bits are zero the audio output is attenuated by 48 dB.
On the other hand S24_3LE does work, but then the problem is the clock
rate support. On BBB the McASP IP is the bit clock master and provides
the bit clock by simple divider from 24.576MHz oscillator. With 24 bit
samples neither 44100 or 48000Hz sample rate can be supported (on the
other hand 32kHz could be supported 24576000 % (24*2*32000) = 0).
The BBB HW price has squeezed so low that it can only implement the most
basic use cases.
I would suggest to leave the CTS_N_K to the current setting (3), unless
we can change the CTS_N_K on the fly according to the used sample format.
Best regards,
Jyri
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Russell King - ARM Linux @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390845177-2626-1-git-send-email-lauraa@codeaurora.org>
On Mon, Jan 27, 2014 at 09:52:57AM -0800, Laura Abbott wrote:
> The dma_mask for a device structure is a pointer. This pointer
> needs to be set up before the dma mask can actually be set. Most
> frameworks in the kernel take care of setting this up properly but
> platform devices that don't follow a regular bus structure may not
> ever have this set. As a result, checks such as dma_capable will
> always return false on a raw platform device and dma_set_mask will
> always return -EIO. Fix this by adding a dma_mask in the
> platform_device archdata and setting it to be the dma_mask. Devices
> used in other frameworks can change this as needed.
You shouldn't need to do this. I went through a lot of the drivers we
currently have, fixing them up in various manners. The basic rules
for this stuff are:
- It is the responsibility of the code creating the device to set a
reasonable default for the dma mask according to the bus and whether
DMA is supportable.
- It is the responsibility of the driver _always_ to make a call to
dma_set_mask() and/or dma_set_coherent_mask() according to the
driver's needs if the driver is going to be using DMA.
As a work-around for the buggy situation we have in the kernel with DT,
various buggy workarounds have been incorporated into drivers which
involve writing directly to the DMA masks, and other such games. None
of that is necessary when the dma_coerce_*() functions are used - but
these are a stop-gap until the DT code gets fixed.
The real answer here is to make DT conform to the first point above
and not add yet another different hack to the kernel.
--
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".
^ permalink raw reply
* [PATCH v2 3/3] Binding: atmel-wm8904: add option to choose clock
From: Mark Brown @ 2014-01-27 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390805726-1841-4-git-send-email-voice.shen@atmel.com>
On Mon, Jan 27, 2014 at 02:55:26PM +0800, Bo Shen wrote:
> diff --git a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> index 8bbe50c..2d86e2b 100644
> --- a/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> +++ b/Documentation/devicetree/bindings/sound/atmel-wm8904.txt
> @@ -33,6 +33,12 @@ Required properties:
>
> Optional properties:
> - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
> + - atmel,clk-from-rk-pin: bool property.
> + - When SSC works in slave mode, according to the hardware design, the
> + clock can get from TK pin, and also can get from RK pin. So, add
> + this parameter to choose where the clock from.
> + - By default the clock is from TK pin, if the clock from RK pin, this
> + property is needed.
Can this be made a property of the SSC device so that it's available for
all cards using it rather than just this one? That would also address
the issue with the way the configuration is passed to the controller
that Lars-Peter identified.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/89853ba3/attachment.sig>
^ permalink raw reply
* [PATCH] dt-bindings: qcom: Fix warning with duplicate dt define
From: Mike Turquette @ 2014-01-27 19:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390007119-4544-1-git-send-email-sboyd@codeaurora.org>
Quoting Stephen Boyd (2014-01-17 17:05:19)
> arch/arm/boot/dts/include/dt-bindings/clock/qcom,mmcc-msm8974.h:60:0:
> warning: "RBCPR_CLK_SRC" redefined
>
> Rename this to MMSS_RBCPR_CLK_SRC to avoid conflicts with the
> RBCPR clock in the gcc header.
>
> Reported-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Thanks for the fix. I've pulled this into part 2 of my pull request.
Regards,
Mike
> ---
> include/dt-bindings/clock/qcom,mmcc-msm8974.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/dt-bindings/clock/qcom,mmcc-msm8974.h b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> index 04d318d1187a..032ed87ef0f3 100644
> --- a/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> +++ b/include/dt-bindings/clock/qcom,mmcc-msm8974.h
> @@ -57,7 +57,7 @@
> #define EXTPCLK_CLK_SRC 40
> #define HDMI_CLK_SRC 41
> #define VSYNC_CLK_SRC 42
> -#define RBCPR_CLK_SRC 43
> +#define MMSS_RBCPR_CLK_SRC 43
> #define CAMSS_CCI_CCI_AHB_CLK 44
> #define CAMSS_CCI_CCI_CLK 45
> #define CAMSS_CSI0_AHB_CLK 46
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox