* Re: [PATCH 1/2] usb: dwc2: add amcc,dwc-otg support
From: John Youn @ 2016-11-15 19:08 UTC (permalink / raw)
To: Christian Lamparter, John Youn
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
Mark Rutland, Rob Herring, Greg Kroah-Hartman, Felipe Balbi
In-Reply-To: <f9be1906-3d94-e9c6-841a-d7baa2572f75-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On 11/14/2016 3:00 PM, John Youn wrote:
> On 11/11/2016 3:12 PM, Christian Lamparter wrote:
>> On Friday, November 11, 2016 2:20:42 PM CET John Youn wrote:
>>> On 11/11/2016 2:05 PM, Christian Lamparter wrote:
>>>> On Friday, November 11, 2016 1:22:16 PM CET John Youn wrote:
>>>>> On 11/11/2016 12:59 PM, Christian Lamparter wrote:
>>>>>> This patch adds support for the "amcc,usb-otg" device
>>>>>> which is found in the PowerPC Canyonlands' dts.
>>>>>>
>>>>>> The device definition was added by:
>>>>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'
>>>>>> but without any driver support as the dwc2 driver wasn't
>>>>>> available at that time.
>>>>>>
>>>>>> Note: The system can't use the generic "snps,dwc2" compatible
>>>>>> because of the special ahbcfg configuration. The default
>>>>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>>>>> when the USB and SATA is used concurrently.
>>>>>
>>>>> I don't want to add any more of these param structures to the driver
>>>>> unless really necessary. We're trying to remove usage of them in favor
>>>>> of using auto-detected defaults and device properties to override
>>>>> them.
>>>> Ok, thanks. I think that would work. I've attached an updated patch.
>>>> Can it be applied/queued now? Or do you want me to resent it later?
>>>>
>>>>> The AHB Burst is actually one of the ones we were going to do next
>>>>> because our platform also doesn't work well with INCR4. In fact I'm
>>>>> thinking of making the default INCR.
>>>> Is that actually possible to change the default still? This would
>>>> require to re-evaluate all existing archs/platforms that use
>>>> "snps,dwc2" for INCR16 compatibility.
>>>
>>> INCR, not INCR16, but you're right, so we may not change it even
>>> though though INCR is usually the right choice over INCR4.
>> What about making a device-tree property?
>
> Yes, that's what I meant. I'll send a change for this shortly.
>
>>
>> Recommended properties:
>> - g-ahb-bursts : specifies the ahb bursts length, should be one of
>> "single", "INCRx", "INCR4", "INCR8", or "INCR16". If not specified
>> the safer but inefficient "INCR4" is used. The optimal setting is
>> "INCRx".
>>
>> Would this work? If so, I can make a patch over the weekend.
>>> Anyways, with the binding, can't you just set the compatible string to
>>> snps,dwc2?
>>
>> Ah, let me explain. I had a discussion with Mark Rutland and Rob Herring
>> a while back about device-tree bindings.
>>
>> They made it very clear to me, that they don't want any generic "catch all
>> compatible" strings:
>>
>> "Bindings should be for hardware (either specific device models, or for
>> classes), and not for Linux drivers. The latter is subject to arbitrary
>> changes while the former is not, as old hardware continues to exist and
>> does not change while drivers get completely reworked." [0]
>>
>> Furthermore, this is an existing binding in kernel's canyonlands.dts [1]
>> and this binding can't be easily changed. Rob Herring explained this in
>> the context of the "basic-mmio-gpio" patch [2] when I was editing the dts
>> to make them work with the changes I made:
>>
>> "You can't remove the old drivers as they are needed to work with
>> old dtbs, so there is no gain.
>>
>> You would need to match on existing compatibles such as
>> moxa,moxart-gpio and provide a match data struct that has all the info
>> you are adding here (e.g. data register offset). Then additionally you
>> could add "basic-mmio-gpio" (I would drop "basic" part) and the
>> additional data associated with it. But it has to be new properties,
>> not changing properties. Changing the reg values doesn't work."
>>
>> So, for this to work with the existing canyonlands.dts, I need to have
>> the "amcc,dwc-otg" compatible string.
>
> Ok, if that's the case. But still a bit confused as to what driver was
> working with it before since the binding was not defined for dwc2.
>
>>
>> Of course, it would be great to hear from Rob Herring and/or Mark Rutland
>> about this case.
>>
>> Regards,
>> Christian
>>
>> [0] <https://patchwork.kernel.org/patch/8976221/>
>> [1] <http://lxr.free-electrons.com/source/arch/powerpc/boot/dts/canyonlands.dts#L181>
>> [2] <http://www.spinics.net/lists/devicetree/msg124538.html>
>>
>>
>>>>
>>>> From what I can tell based would be:
>>>> bcm11351, bcm21664, bcm23550, exynos3250, stm32f429, rk3xxx,
>>>> stratix10, meson-gxbb, rt3050 and some Altera FPGAs.
>>>>
>>>>> If that's all you need then a devicetree binding should be enough
>>>>> right?
>>>> Yes. The device is working fine so far.
>>>>
>>>> Regards,
>>>> Christian
>>>>
>>>> ---
>>>> From 70dd4be016b89655a56bc8260f04683b50f07644 Mon Sep 17 00:00:00 2001
>>>> From: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> Date: Sun, 6 Nov 2016 00:39:24 +0100
>>>> Subject: [PATCH] usb: dwc2: add amcc,dwc-otg support
>>>>
>>>> This patch adds support for the "amcc,usb-otg" device
>>>> which is found in the PowerPC Canyonlands' dts.
>>>>
>>>> The device definition was added by:
>>>> commit c89b3458d8cc ("powerpc/44x: Add USB DWC DTS entry to Canyonlands board")'
>>>> but without any driver support as the dwc2 driver wasn't
>>>> available at that time.
>>>>
>>>> Note: The system can't use the generic "snps,dwc2" compatible
>>>> because of the special ahbcfg configuration. The default
>>>> GAHBCFG_HBSTLEN_INCR4 of snps,dwc2 can cause a system hang
>>>> when the USB and SATA is used concurrently.
>>>>
>>>> Cc: Felipe Balbi <felipe.balbi-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>>> Cc: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>>>> Signed-off-by: Christian Lamparter <chunkeey-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>> v1->v2:
>>>> - moved definitons to params.c
>>>> - removed dma_enable / host_dma parameter
>>>> - added dma_desc_fs_enable parameter
>>>> v2->v3:
>>>> - removed parameters
>>>>
>>>> Please queue this patch until GAHBCFG_HBSTLEN_INCR16 is the default
>>>> for ahbcfg.
>>>> ---
>>>> Documentation/devicetree/bindings/usb/dwc2.txt | 1 +
>>>> drivers/usb/dwc2/params.c | 1 +
>>>> 2 files changed, 2 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> index 10a2a4b..6ccfe85 100644
>>>> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>>>> @@ -12,6 +12,7 @@ Required properties:
>>>> - "lantiq,xrx200-usb": The DWC2 USB controller instance in Lantiq XRX SoCs;
>>>> - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs;
>>>> - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs;
>>>> + - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs;
>>>> - snps,dwc2: A generic DWC2 USB controller with default parameters.
>>>> - reg : Should contain 1 register range (address and length)
>>>> - interrupts : Should contain 1 interrupt
>>>> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
>>>> index 64d5c66..9506ab0 100644
>>>> --- a/drivers/usb/dwc2/params.c
>>>> +++ b/drivers/usb/dwc2/params.c
>>>> @@ -239,6 +239,7 @@ const struct of_device_id dwc2_of_match_table[] = {
>>>> { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
>>>> { .compatible = "amlogic,meson8b-usb", .data = ¶ms_amlogic },
>>>> { .compatible = "amlogic,meson-gxbb-usb", .data = ¶ms_amlogic },
>>>> + { .compatible = "amcc,dwc-otg", .data = NULL },
>>>> {},
>>>> };
>>>> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
>>>>
>
> For dwc2 part:
>
> Acked-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
>
Hi Felipe,
Can you drop this from your testing/next?
I meant for the 2nd version to be applied, without the params
structure.
I can send you a clean version to apply later today.
Regards,
John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V3 1/9] PM / OPP: Reword binding supporting multiple regulators per device
From: Stephen Boyd @ 2016-11-15 18:56 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rob Herring, Mark Brown, Rafael Wysocki, nm, Viresh Kumar,
linaro-kernel, linux-pm, linux-kernel, Vincent Guittot, d-gerlach,
devicetree
In-Reply-To: <20161115033151.GG4178@vireshk-i7>
On 11/15, Viresh Kumar wrote:
> On 14-11-16, 18:13, Stephen Boyd wrote:
> > On 11/14, Rob Herring wrote:
> > > On Fri, Nov 11, 2016 at 08:41:20AM +0530, Viresh Kumar wrote:
> > > > On 10-11-16, 14:51, Stephen Boyd wrote:
> > > > >
> > > > > No. The supply names (and also clock names/index) should be left
> > > > > up to the consumer of the OPP table. We don't want to encode any
> > > > > sort of details like this between the OPP table and the consumer
> > > > > of it in DT because then it seriously couples the OPP table to
> > > > > the consumer device. "The binding" in this case that needs to be
> > > > > updated is the consumer binding, to indicate that it correlated
> > > > > foo-supply and bar-supply to index 0 and 1 of the OPP table
> > > > > voltages.
> > > >
> > > > Are you saying that we shall have a property like this then?
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > > > index ee91cbdd95ee..733946df2fb8 100644
> > > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > > @@ -389,7 +389,10 @@ Example 4: Handling multiple regulators
> > > > compatible = "arm,cortex-a7";
> > > > ...
> > > >
> > > > - cpu-supply = <&cpu_supply0>, <&cpu_supply1>, <&cpu_supply2>;
> > > > + vcc0-supply = <&cpu_supply0>;
> > > > + vcc1-supply = <&cpu_supply1>;
> > > > + vcc2-supply = <&cpu_supply2>;
> > > > + opp-supply-names = "vcc0", "vcc1", "vcc2";
> > >
> > > Uh, no. You already have the names in the *-supply properties. Yes, they
> > > are a PIA to retrieve compared to a *-names property, but that is the
> > > nature of this style of binding.
>
> Its not just PIA, but impossible AFAICT.
>
> There are two important pieces of information we need for multiple
> regulator support:
> - Which regulator in the consumer node corresponds to which entry in
> the OPP table. As Mark mentioned earlier, DT should be able to get
> us this.
This is also possible from C code though. Or is there some case
where it isn't possible if we're sharing the same table with two
devices? I'm lost on when this would ever happen.
It feels like trying to keep the OPP table agnostic of the
consuming device and the device's binding is more trouble than
it's worth. Especially considering we have opp-shared and *-name
now.
> - The order in which the supplies need to be programmed. We have all
> agreed to do this in code instead of inferring it from DT and this
> patch series already does that.
Agreed. Encoding a sequence into DT doesn't sound very feasible.
How is this going to be handled though? I don't see any users of
the code we're reviewing here, so it's hard to grasp how things
will work. It would be really useful if we had some user of the
code included in the patch series to get the big picture.
>
> I want to solve the first problem here and I don't see how it can be
> solved using such entries:
>
> cpus {
> cpu@0 {
> compatible = "arm,cortex-a7";
> ...
>
> vcc0-supply = <&cpu_supply0>;
> vcc1-supply = <&cpu_supply1>;
> vcc2-supply = <&cpu_supply2>;
> operating-points-v2 = <&cpu0_opp_table>;
> };
> };
>
> cpu0_opp_table: opp_table0 {
> compatible = "operating-points-v2";
> opp-shared;
>
> opp@1000000000 {
> opp-hz = /bits/ 64 <1000000000>;
> opp-microvolt = <970000>, /* Supply 0 */
> <960000>, /* Supply 1 */
> <960000>; /* Supply 2 */
> };
> };
>
> The code can't figure out which of vcc0, vcc1, vcc2 is added first in
> the CPU node and so we need to get the order somehow. A separate
> binding as I mentioned earlier is a probably (ugly) solution.
>
> > I think the problem is that Viresh wants the binding to be "self
> > describing" so that the OPP can be used without a driver knowing
> > that a supply corresponds to a particular column in the voltage
> > table.
>
> Right, and that's what Mark suggested as well.
>
> > I don't understand that though. Can't we set the supply
> > names from C code somewhere based on the consumer of the OPPs?
>
> That's what this patch series is doing right now.
>
> So, are you saying that the way this patchset does it is fine with you
> ?
That's just to handle the ordering of operations? I need to take
a minute and understand what's changing. You may have spent
plenty of time developing/updating, but I haven't spent near
enough time understanding what's going on in these patches to
give a thorough review.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V2 1/2] pinctrl: tegra: Add DT binding for io pads control
From: Jon Hunter @ 2016-11-15 18:48 UTC (permalink / raw)
To: Laxman Dewangan, linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
swarren-3lzwWm7+Weoh9ZMKESR00Q,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w
Cc: gnurou-Re5JQEeQqe8AvxtiuMwx3w,
yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478696782-11657-2-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 09/11/16 13:06, Laxman Dewangan wrote:
> NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> low power state of some of its IO pads. The IO pads can work in
> the voltage of the 1.8V and 3.3V of IO voltage from IO power rail
> sources. When IO interfaces are not used then IO pads can be
> configure in low power state to reduce the power consumption from
> that IO pads.
>
> On Tegra124, the voltage level of IO power rail source is auto
> detected by hardware(SoC) and hence it is only require to configure
> in low power mode if IO pads are not used.
>
> On T210 onwards, the auto-detection of voltage level from IO power
> rail is removed from SoC and hence SW need to configure the PMC
> register explicitly to set proper voltage in IO pads based on
> IO rail power source voltage.
>
> Add DT binding document for detailing the DT properties for
> configuring IO pads voltage levels and its power state.
>
> Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> ---
> Changes from V1:
> The DT binding document is modified to explain the regulator handle
> for different IOs and how can it be passed from the DT.
> ---
> .../bindings/pinctrl/nvidia,tegra-io-pad.txt | 126 +++++++++++++++++++++
> 1 file changed, 126 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> new file mode 100644
> index 0000000..6ca961f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra-io-pad.txt
> @@ -0,0 +1,126 @@
> +NVIDIA Tegra PMC IO pad controller
> +
> +NVIDIA Tegra124 and later SoCs support the multi-voltage level and
> +low power state of some of its IO pads. When IO interface are not
> +used then IO pads can be configure in low power state to reduce
> +the power from that IO pads. The IO pads can work in the voltage
> +of the 1.8V and 3.3V of IO voltage from power rail sources.
The last sentence is a bit unclear and does not sound correct. I am not
sure if you are missing the word 'range' somewhere or if you are trying
to say it must be either 1.8V or 3.3V. Looks like you have the same
sentence on the changelog too.
Cheers
Jon
--
nvpublic
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 3/3] ASoC: atmel: tse850: add ASoC driver for the Axentia TSE-850
From: Peter Rosin @ 2016-11-15 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Nicolas Ferre, Jaroslav Kysela, Takashi Iwai, alsa-devel,
devicetree
In-Reply-To: <1479235095-13441-1-git-send-email-peda@axentia.se>
The TSE-850 is an FM Transmitter Station Equipment, designed to generate
baseband signals for FM, mainly the DARC subcarrier, but other signals
are also possible.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
MAINTAINERS | 1 +
sound/soc/atmel/Kconfig | 10 +
sound/soc/atmel/Makefile | 2 +
sound/soc/atmel/tse850-pcm5142.c | 472 +++++++++++++++++++++++++++++++++++++++
4 files changed, 485 insertions(+)
create mode 100644 sound/soc/atmel/tse850-pcm5142.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e6bf00e53bf3..59baed3fd0ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2323,6 +2323,7 @@ M: Peter Rosin <peda@axentia.se>
L: alsa-devel@alsa-project.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
+F: sound/soc/atmel/tse850-pcm5142.c
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 22aec9a1e9a4..4a56f3dfba51 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -78,4 +78,14 @@ config SND_ATMEL_SOC_PDMIC
help
Say Y if you want to add support for Atmel ASoC driver for boards using
PDMIC.
+
+config SND_ATMEL_SOC_TSE850_PCM5142
+ tristate "ASoC driver for the Axentia TSE-850"
+ depends on ARCH_AT91 && OF
+ depends on ATMEL_SSC && I2C
+ select SND_ATMEL_SOC_SSC_DMA
+ select SND_SOC_PCM512x_I2C
+ help
+ Say Y if you want to add support for the ASoC driver for the
+ Axentia TSE-850 with a PCM5142 codec.
endif
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index a2b127bd9c87..67e10cbd4ed7 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -13,9 +13,11 @@ snd-atmel-soc-wm8904-objs := atmel_wm8904.o
snd-soc-sam9x5-wm8731-objs := sam9x5_wm8731.o
snd-atmel-soc-classd-objs := atmel-classd.o
snd-atmel-soc-pdmic-objs := atmel-pdmic.o
+snd-atmel-soc-tse850-pcm5142-objs := tse850-pcm5142.o
obj-$(CONFIG_SND_AT91_SOC_SAM9G20_WM8731) += snd-soc-sam9g20-wm8731.o
obj-$(CONFIG_SND_ATMEL_SOC_WM8904) += snd-atmel-soc-wm8904.o
obj-$(CONFIG_SND_AT91_SOC_SAM9X5_WM8731) += snd-soc-sam9x5-wm8731.o
obj-$(CONFIG_SND_ATMEL_SOC_CLASSD) += snd-atmel-soc-classd.o
obj-$(CONFIG_SND_ATMEL_SOC_PDMIC) += snd-atmel-soc-pdmic.o
+obj-$(CONFIG_SND_ATMEL_SOC_TSE850_PCM5142) += snd-atmel-soc-tse850-pcm5142.o
diff --git a/sound/soc/atmel/tse850-pcm5142.c b/sound/soc/atmel/tse850-pcm5142.c
new file mode 100644
index 000000000000..ac6a814c8ecf
--- /dev/null
+++ b/sound/soc/atmel/tse850-pcm5142.c
@@ -0,0 +1,472 @@
+/*
+ * TSE-850 audio - ASoC driver for the Axentia TSE-850 with a PCM5142 codec
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * loop1 relays
+ * IN1 +---o +------------+ o---+ OUT1
+ * \ /
+ * + +
+ * | / |
+ * +--o +--. |
+ * | add | |
+ * | V |
+ * | .---. |
+ * DAC +----------->|Sum|---+
+ * | '---' |
+ * | |
+ * + +
+ *
+ * IN2 +---o--+------------+--o---+ OUT2
+ * loop2 relays
+ *
+ * The 'loop1' gpio pin controlls two relays, which are either in loop
+ * position, meaning that input and output are directly connected, or
+ * they are in mixer position, meaning that the signal is passed through
+ * the 'Sum' mixer. Similarly for 'loop2'.
+ *
+ * In the above, the 'loop1' relays are inactive, thus feeding IN1 to the
+ * mixer (if 'add' is active) and feeding the mixer output to OUT1. The
+ * 'loop2' relays are active, short-cutting the TSE-850 from channel 2.
+ * IN1, IN2, OUT1 and OUT2 are TSE-850 connectors and DAC is the PCB name
+ * of the (filtered) output from the PCM5142 codec.
+ */
+
+#include <linux/clk.h>
+#include <linux/gpio.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/regulator/consumer.h>
+
+#include <sound/soc.h>
+#include <sound/pcm_params.h>
+
+#include "atmel_ssc_dai.h"
+
+struct tse850_priv {
+ int ssc_id;
+
+ struct gpio_desc *add;
+ struct gpio_desc *loop1;
+ struct gpio_desc *loop2;
+
+ struct regulator *ana;
+
+ int add_cache;
+ int loop1_cache;
+ int loop2_cache;
+};
+
+static int tse850_get_mux1(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+
+ ucontrol->value.enumerated.item[0] = tse850->loop1_cache;
+
+ return 0;
+}
+
+static int tse850_put_mux1(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+ struct soc_enum *e = (struct soc_enum *)kctrl->private_value;
+ unsigned int val = ucontrol->value.enumerated.item[0];
+
+ if (val >= e->items)
+ return -EINVAL;
+
+ gpiod_set_value_cansleep(tse850->loop1, val);
+ tse850->loop1_cache = val;
+
+ return snd_soc_dapm_put_enum_double(kctrl, ucontrol);
+}
+
+static int tse850_get_mux2(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+
+ ucontrol->value.enumerated.item[0] = tse850->loop2_cache;
+
+ return 0;
+}
+
+static int tse850_put_mux2(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+ struct soc_enum *e = (struct soc_enum *)kctrl->private_value;
+ unsigned int val = ucontrol->value.enumerated.item[0];
+
+ if (val >= e->items)
+ return -EINVAL;
+
+ gpiod_set_value_cansleep(tse850->loop2, val);
+ tse850->loop2_cache = val;
+
+ return snd_soc_dapm_put_enum_double(kctrl, ucontrol);
+}
+
+int tse850_get_mix(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+
+ ucontrol->value.enumerated.item[0] = tse850->add_cache;
+
+ return 0;
+}
+
+int tse850_put_mix(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+ int connect = !!ucontrol->value.integer.value[0];
+
+ if (tse850->add_cache == connect)
+ return 0;
+
+ /*
+ * Hmmm, this gpiod_set_value_cansleep call should probably happen
+ * inside snd_soc_dapm_mixer_update_power in the loop.
+ */
+ gpiod_set_value_cansleep(tse850->add, connect);
+ tse850->add_cache = connect;
+
+ snd_soc_dapm_mixer_update_power(dapm, kctrl, connect, NULL);
+ return 1;
+}
+
+int tse850_get_ana(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+ int ret;
+
+ ret = regulator_get_voltage(tse850->ana);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * Map regulator output values like so:
+ * -11.5V to "Low" (enum 0)
+ * 11.5V-12.5V to "12V" (enum 1)
+ * 12.5V-13.5V to "13V" (enum 2)
+ * ...
+ * 18.5V-19.5V to "19V" (enum 8)
+ * 19.5V- to "20V" (enum 9)
+ */
+ if (ret < 11000000)
+ ret = 11000000;
+ else if (ret > 20000000)
+ ret = 20000000;
+ ret -= 11000000;
+ ret = (ret + 500000) / 1000000;
+
+ ucontrol->value.enumerated.item[0] = ret;
+
+ return 0;
+}
+
+int tse850_put_ana(struct snd_kcontrol *kctrl,
+ struct snd_ctl_elem_value *ucontrol)
+{
+ struct snd_soc_dapm_context *dapm = snd_soc_dapm_kcontrol_dapm(kctrl);
+ struct snd_soc_card *card = dapm->card;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+ struct soc_enum *e = (struct soc_enum *)kctrl->private_value;
+ unsigned int uV = ucontrol->value.enumerated.item[0];
+ int ret;
+
+ if (uV >= e->items)
+ return -EINVAL;
+
+ /*
+ * Map enum zero (Low) to 2 volts on the regulator, do this since
+ * the ana regulator is supplied by the system 12V voltage and
+ * requesting anything below the system voltage causes the system
+ * voltage to be passed through the regulator. Also, the ana
+ * regulator induces noise when requesting voltages near the
+ * system voltage. So, by mapping Low to 2V, that noise is
+ * eliminated when all that is needed is 12V (the system voltage).
+ */
+ if (uV)
+ uV = 11000000 + (1000000 * uV);
+ else
+ uV = 2000000;
+
+ ret = regulator_set_voltage(tse850->ana, uV, uV);
+ if (ret < 0)
+ return ret;
+
+ return snd_soc_dapm_put_enum_double(kctrl, ucontrol);
+}
+
+static const char * const mux_text[] = { "Mixer", "Loop" };
+
+static const struct soc_enum mux_enum =
+ SOC_ENUM_SINGLE(SND_SOC_NOPM, 0, 2, mux_text);
+
+static const struct snd_kcontrol_new mux1 =
+ SOC_DAPM_ENUM_EXT("MUX1", mux_enum, tse850_get_mux1, tse850_put_mux1);
+
+static const struct snd_kcontrol_new mux2 =
+ SOC_DAPM_ENUM_EXT("MUX2", mux_enum, tse850_get_mux2, tse850_put_mux2);
+
+#define TSE850_DAPM_SINGLE_EXT(xname, reg, shift, max, invert, xget, xput) \
+{ .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
+ .info = snd_soc_info_volsw, \
+ .get = xget, \
+ .put = xput, \
+ .private_value = SOC_SINGLE_VALUE(reg, shift, max, invert, 0) }
+
+static const struct snd_kcontrol_new mix[] = {
+ TSE850_DAPM_SINGLE_EXT("IN Switch", SND_SOC_NOPM, 0, 1, 0,
+ tse850_get_mix, tse850_put_mix),
+};
+
+static const char * const ana_text[] = {
+ "Low", "12V", "13V", "14V", "15V", "16V", "17V", "18V", "19V", "20V"
+};
+
+static const struct soc_enum ana_enum =
+ SOC_ENUM_SINGLE(SND_SOC_NOPM, 0, 9, ana_text);
+
+static const struct snd_kcontrol_new out =
+ SOC_DAPM_ENUM_EXT("ANA", ana_enum, tse850_get_ana, tse850_put_ana);
+
+static const struct snd_soc_dapm_widget tse850_dapm_widgets[] = {
+ SND_SOC_DAPM_LINE("OUT1", NULL),
+ SND_SOC_DAPM_LINE("OUT2", NULL),
+ SND_SOC_DAPM_LINE("IN1", NULL),
+ SND_SOC_DAPM_LINE("IN2", NULL),
+ SND_SOC_DAPM_INPUT("DAC"),
+ SND_SOC_DAPM_AIF_IN("AIFINL", "Playback", 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_AIF_IN("AIFINR", "Playback", 1, SND_SOC_NOPM, 0, 0),
+ SOC_MIXER_ARRAY("MIX", SND_SOC_NOPM, 0, 0, mix),
+ SND_SOC_DAPM_MUX("MUX1", SND_SOC_NOPM, 0, 0, &mux1),
+ SND_SOC_DAPM_MUX("MUX2", SND_SOC_NOPM, 0, 0, &mux2),
+ SND_SOC_DAPM_OUT_DRV("OUT", SND_SOC_NOPM, 0, 0, &out, 1),
+};
+
+/*
+ * These connections are not entirely correct, since both IN1 and IN2
+ * are always fed to MIX (if the "IN switch" is set so), i.e. without
+ * regard to the loop1 and loop2 relays that according to this only
+ * control MUX1 and MUX2 but in fact also control how the input signals
+ * are routed.
+ * But, 1) I don't know how to do it right, and 2) it doesn't seem to
+ * matter in practice since nothing is powered in those sections anyway.
+ */
+static const struct snd_soc_dapm_route tse850_intercon[] = {
+ { "OUT1", NULL, "MUX1" },
+ { "OUT2", NULL, "MUX2" },
+
+ { "MUX1", "Loop", "IN1" },
+ { "MUX1", "Mixer", "OUT" },
+
+ { "MUX2", "Loop", "IN2" },
+ { "MUX2", "Mixer", "OUT" },
+
+ { "OUT", NULL, "MIX" },
+
+ { "MIX", NULL, "DAC" },
+ { "MIX", "IN Switch", "IN1" },
+ { "MIX", "IN Switch", "IN2" },
+
+ /* connect board input to the codec left channel output pin */
+ { "DAC", NULL, "OUTL" },
+};
+
+static struct snd_soc_dai_link tse850_dailink = {
+ .name = "TSE-850",
+ .stream_name = "TSE-850-PCM",
+ .codec_dai_name = "pcm512x-hifi",
+ .dai_fmt = SND_SOC_DAIFMT_I2S
+ | SND_SOC_DAIFMT_NB_NF
+ | SND_SOC_DAIFMT_CBM_CFS,
+};
+
+static struct snd_soc_card tse850_card = {
+ .name = "TSE-850-ASoC",
+ .owner = THIS_MODULE,
+ .dai_link = &tse850_dailink,
+ .num_links = 1,
+ .dapm_widgets = tse850_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(tse850_dapm_widgets),
+ .dapm_routes = tse850_intercon,
+ .num_dapm_routes = ARRAY_SIZE(tse850_intercon),
+ .fully_routed = true,
+};
+
+static int tse850_dt_init(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *codec_np, *cpu_np;
+ struct snd_soc_card *card = &tse850_card;
+ struct snd_soc_dai_link *dailink = &tse850_dailink;
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+
+ if (!np) {
+ dev_err(&pdev->dev, "only device tree supported\n");
+ return -EINVAL;
+ }
+
+ cpu_np = of_parse_phandle(np, "axentia,ssc-controller", 0);
+ if (!cpu_np) {
+ dev_err(&pdev->dev, "failed to get dai and pcm info\n");
+ return -EINVAL;
+ }
+ dailink->cpu_of_node = cpu_np;
+ dailink->platform_of_node = cpu_np;
+ tse850->ssc_id = of_alias_get_id(cpu_np, "ssc");
+ of_node_put(cpu_np);
+
+ codec_np = of_parse_phandle(np, "axentia,audio-codec", 0);
+ if (!codec_np) {
+ dev_err(&pdev->dev, "failed to get codec info\n");
+ return -EINVAL;
+ }
+ dailink->codec_of_node = codec_np;
+ of_node_put(codec_np);
+
+ return 0;
+}
+
+static int tse850_probe(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = &tse850_card;
+ struct device *dev = card->dev = &pdev->dev;
+ struct tse850_priv *tse850;
+ int ret;
+
+ tse850 = devm_kzalloc(dev, sizeof(*tse850), GFP_KERNEL);
+ if (!tse850)
+ return -ENOMEM;
+
+ snd_soc_card_set_drvdata(card, tse850);
+
+ ret = tse850_dt_init(pdev);
+ if (ret) {
+ dev_err(dev, "failed to init dt info\n");
+ return ret;
+ }
+
+ tse850->add = devm_gpiod_get(dev, "axentia,add", GPIOD_OUT_HIGH);
+ if (IS_ERR(tse850->add)) {
+ if (PTR_ERR(tse850->add) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get 'add' gpio\n");
+ return PTR_ERR(tse850->add);
+ }
+ tse850->add_cache = 1;
+
+ tse850->loop1 = devm_gpiod_get(dev, "axentia,loop1", GPIOD_OUT_HIGH);
+ if (IS_ERR(tse850->loop1)) {
+ if (PTR_ERR(tse850->loop1) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get 'loop1' gpio\n");
+ return PTR_ERR(tse850->loop1);
+ }
+ tse850->loop1_cache = 1;
+
+ tse850->loop2 = devm_gpiod_get(dev, "axentia,loop2", GPIOD_OUT_HIGH);
+ if (IS_ERR(tse850->loop2)) {
+ if (PTR_ERR(tse850->loop2) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get 'loop2' gpio\n");
+ return PTR_ERR(tse850->loop2);
+ }
+ tse850->loop2_cache = 1;
+
+ tse850->ana = devm_regulator_get(dev, "axentia,ana");
+ if (IS_ERR(tse850->ana)) {
+ if (PTR_ERR(tse850->ana) != -EPROBE_DEFER)
+ dev_err(dev, "failed to get 'ana' regulator\n");
+ return PTR_ERR(tse850->ana);
+ }
+
+ ret = regulator_enable(tse850->ana);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable the 'ana' regulator\n");
+ return ret;
+ }
+
+ ret = atmel_ssc_set_audio(tse850->ssc_id);
+ if (ret != 0) {
+ dev_err(dev,
+ "failed to set SSC %d for audio\n", tse850->ssc_id);
+ goto err_disable_ana;
+ }
+
+ ret = snd_soc_register_card(card);
+ if (ret) {
+ dev_err(dev, "snd_soc_register_card failed\n");
+ goto err_put_audio;
+ }
+
+ return 0;
+
+err_put_audio:
+ atmel_ssc_put_audio(tse850->ssc_id);
+err_disable_ana:
+ regulator_disable(tse850->ana);
+ return ret;
+}
+
+static int tse850_remove(struct platform_device *pdev)
+{
+ struct snd_soc_card *card = platform_get_drvdata(pdev);
+ struct tse850_priv *tse850 = snd_soc_card_get_drvdata(card);
+
+ snd_soc_unregister_card(card);
+ atmel_ssc_put_audio(tse850->ssc_id);
+ regulator_disable(tse850->ana);
+
+ return 0;
+}
+
+static const struct of_device_id tse850_dt_ids[] = {
+ { .compatible = "axentia,tse850-pcm5142", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tse850_dt_ids);
+
+static struct platform_driver tse850_driver = {
+ .driver = {
+ .name = "axentia-tse850-pcm5142",
+ .of_match_table = of_match_ptr(tse850_dt_ids),
+ },
+ .probe = tse850_probe,
+ .remove = tse850_remove,
+};
+
+module_platform_driver(tse850_driver);
+
+/* Module information */
+MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
+MODULE_DESCRIPTION("ALSA SoC driver for TSE-850 with PCM5142 codec");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* [PATCH v4 2/3] ASoC: tse850: document axentia,tse850-pcm5142 bindings
From: Peter Rosin @ 2016-11-15 18:38 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Nicolas Ferre, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479235095-13441-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
The TSE-850 is an FM Transmitter Station Equipment, designed to generate
baseband signals for FM, mainly the DARC subcarrier, but other signals
are also possible.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
.../bindings/sound/axentia,tse850-pcm5142.txt | 88 ++++++++++++++++++++++
MAINTAINERS | 6 ++
2 files changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
new file mode 100644
index 000000000000..5b9b38f578bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
@@ -0,0 +1,88 @@
+Devicetree bindings for the Axentia TSE-850 audio complex
+
+Required properties:
+ - compatible: "axentia,tse850-pcm5142"
+ - axentia,ssc-controller: The phandle of the atmel SSC controller used as
+ cpu dai.
+ - axentia,audio-codec: The phandle of the PCM5142 codec.
+ - axentia,add-gpios: gpio specifier that controls the mixer.
+ - axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1.
+ - axentia,loop2-gpios: gpio specifier that controls loop relays on channel 2.
+ - axentia,ana-supply: Regulator that supplies the output amplifier. Must
+ support voltages in the 2V - 20V range, in 1V steps.
+
+The schematics explaining the gpios are as follows:
+
+ loop1 relays
+ IN1 +---o +------------+ o---+ OUT1
+ \ /
+ + +
+ | / |
+ +--o +--. |
+ | add | |
+ | V |
+ | .---. |
+ DAC +----------->|Sum|---+
+ | '---' |
+ | |
+ + +
+
+ IN2 +---o--+------------+--o---+ OUT2
+ loop2 relays
+
+The 'loop1' gpio pin controlls two relays, which are either in loop position,
+meaning that input and output are directly connected, or they are in mixer
+position, meaning that the signal is passed through the 'Sum' mixer. Similarly
+for 'loop2'.
+
+In the above, the 'loop1' relays are inactive, thus feeding IN1 to the mixer
+(if 'add' is active) and feeding the mixer output to OUT1. The 'loop2' relays
+are active, short-cutting the TSE-850 from channel 2. IN1, IN2, OUT1 and OUT2
+are TSE-850 connectors and DAC is the PCB name of the (filtered) output from
+the PCM5142 codec.
+
+Example:
+
+ &i2c {
+ codec: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+ };
+
+ ana: ana-reg {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,ssc-controller = <&ssc0>;
+ axentia,audio-codec = <&codec>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 851b89b9edcb..e6bf00e53bf3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2318,6 +2318,12 @@ F: include/uapi/linux/ax25.h
F: include/net/ax25.h
F: net/ax25/
+AXENTIA ASOC DRIVERS
+M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+L: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/sound/axentia,*
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab-JsYNTwtnfakRB7SZvlqPiA@public.gmane.org>
M: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/3] ASoC: atmel_ssc_dai: if not provided, default to sensible dividers
From: Peter Rosin @ 2016-11-15 18:38 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Nicolas Ferre, Jaroslav Kysela, Takashi Iwai, alsa-devel,
devicetree
In-Reply-To: <1479235095-13441-1-git-send-email-peda@axentia.se>
When this driver masters BCLK and/or LRCLK, and noone has stated
differently, assume that all the bits of a frame are used.
This relieves the cpu dai users from the duty to fill in the dividers for
the common case.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
sound/soc/atmel/atmel_ssc_dai.c | 83 +++++++++++++++++++++++++++++++++++++----
sound/soc/atmel/atmel_ssc_dai.h | 1 +
2 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c
index 16e459aedffe..a1e2c5682dcd 100644
--- a/sound/soc/atmel/atmel_ssc_dai.c
+++ b/sound/soc/atmel/atmel_ssc_dai.c
@@ -380,6 +380,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream,
ssc_writel(ssc_p->ssc->regs, CR, SSC_BIT(CR_SWRST));
/* Clear the SSC dividers */
ssc_p->cmr_div = ssc_p->tcmr_period = ssc_p->rcmr_period = 0;
+ ssc_p->forced_divider = 0;
}
spin_unlock_irq(&ssc_p->lock);
@@ -426,14 +427,17 @@ static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
else
if (div != ssc_p->cmr_div)
return -EBUSY;
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_CMR_DIV);
break;
case ATMEL_SSC_TCMR_PERIOD:
ssc_p->tcmr_period = div;
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_TCMR_PERIOD);
break;
case ATMEL_SSC_RCMR_PERIOD:
ssc_p->rcmr_period = div;
+ ssc_p->forced_divider |= BIT(ATMEL_SSC_RCMR_PERIOD);
break;
default:
@@ -443,6 +447,28 @@ static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai,
return 0;
}
+/* Is the cpu-dai master of the frame clock? */
+static int atmel_ssc_cfs(struct atmel_ssc_info *ssc_p)
+{
+ switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBM_CFS:
+ case SND_SOC_DAIFMT_CBS_CFS:
+ return 1;
+ }
+ return 0;
+}
+
+/* Is the cpu-dai master of the bit clock? */
+static int atmel_ssc_cbs(struct atmel_ssc_info *ssc_p)
+{
+ switch (ssc_p->daifmt & SND_SOC_DAIFMT_MASTER_MASK) {
+ case SND_SOC_DAIFMT_CBS_CFM:
+ case SND_SOC_DAIFMT_CBS_CFS:
+ return 1;
+ }
+ return 0;
+}
+
/*
* Configure the SSC.
*/
@@ -459,6 +485,9 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
u32 tfmr, rfmr, tcmr, rcmr;
int ret;
int fslen, fslen_ext;
+ u32 cmr_div;
+ u32 tcmr_period;
+ u32 rcmr_period;
/*
* Currently, there is only one set of dma params for
@@ -470,6 +499,46 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
else
dir = 1;
+ /*
+ * If the cpu dai should provide BCLK, but noone has provided the
+ * divider needed for that to work, fall back to something sensible.
+ */
+ cmr_div = ssc_p->cmr_div;
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_CMR_DIV)) &&
+ atmel_ssc_cbs(ssc_p)) {
+ int bclk_rate = snd_soc_params_to_bclk(params);
+
+ if (bclk_rate < 0) {
+ dev_err(dai->dev, "unable to calculate cmr_div: %d\n",
+ bclk_rate);
+ return bclk_rate;
+ }
+
+ cmr_div = DIV_ROUND_CLOSEST(ssc_p->mck_rate, 2 * bclk_rate);
+ }
+
+ /*
+ * If the cpu dai should provide LRCLK, but noone has provided the
+ * dividers needed for that to work, fall back to something sensible.
+ */
+ tcmr_period = ssc_p->tcmr_period;
+ rcmr_period = ssc_p->rcmr_period;
+ if (atmel_ssc_cfs(ssc_p)) {
+ int frame_size = snd_soc_params_to_frame_size(params);
+
+ if (frame_size < 0) {
+ dev_err(dai->dev,
+ "unable to calculate tx/rx cmr_period: %d\n",
+ frame_size);
+ return frame_size;
+ }
+
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_TCMR_PERIOD)))
+ tcmr_period = frame_size / 2 - 1;
+ if (!(ssc_p->forced_divider & BIT(ATMEL_SSC_RCMR_PERIOD)))
+ rcmr_period = frame_size / 2 - 1;
+ }
+
dma_params = ssc_p->dma_params[dir];
channels = params_channels(params);
@@ -524,7 +593,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
fslen_ext = (bits - 1) / 16;
fslen = (bits - 1) % 16;
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, START_DELAY)
| SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -540,7 +609,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, START_DELAY)
| SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -606,7 +675,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
fslen_ext = (bits - 1) / 16;
fslen = (bits - 1) % 16;
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, START_DELAY)
| SSC_BF(RCMR_START, SSC_START_FALLING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -623,7 +692,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, START_DELAY)
| SSC_BF(TCMR_START, SSC_START_FALLING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -650,7 +719,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
* MCK divider, and the BCLK signal is output
* on the SSC TK line.
*/
- rcmr = SSC_BF(RCMR_PERIOD, ssc_p->rcmr_period)
+ rcmr = SSC_BF(RCMR_PERIOD, rcmr_period)
| SSC_BF(RCMR_STTDLY, 1)
| SSC_BF(RCMR_START, SSC_START_RISING_RF)
| SSC_BF(RCMR_CKI, SSC_CKI_RISING)
@@ -665,7 +734,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
| SSC_BF(RFMR_LOOP, 0)
| SSC_BF(RFMR_DATLEN, (bits - 1));
- tcmr = SSC_BF(TCMR_PERIOD, ssc_p->tcmr_period)
+ tcmr = SSC_BF(TCMR_PERIOD, tcmr_period)
| SSC_BF(TCMR_STTDLY, 1)
| SSC_BF(TCMR_START, SSC_START_RISING_RF)
| SSC_BF(TCMR_CKI, SSC_CKI_FALLING)
@@ -760,7 +829,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream,
}
/* set SSC clock mode register */
- ssc_writel(ssc_p->ssc->regs, CMR, ssc_p->cmr_div);
+ ssc_writel(ssc_p->ssc->regs, CMR, cmr_div);
/* set receive clock mode and format */
ssc_writel(ssc_p->ssc->regs, RCMR, rcmr);
diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h
index 80b153857a88..75194f582131 100644
--- a/sound/soc/atmel/atmel_ssc_dai.h
+++ b/sound/soc/atmel/atmel_ssc_dai.h
@@ -113,6 +113,7 @@ struct atmel_ssc_info {
unsigned short cmr_div;
unsigned short tcmr_period;
unsigned short rcmr_period;
+ unsigned int forced_divider;
struct atmel_pcm_dma_params *dma_params[2];
struct atmel_ssc_state ssc_state;
unsigned long mck_rate;
--
2.1.4
^ permalink raw reply related
* [PATCH v4 0/3] ASoC driver for the TSE-850
From: Peter Rosin @ 2016-11-15 18:38 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
Nicolas Ferre, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi!
v3 -> v4 changes:
- changed heading of the devicetree bindings as requested by Rob
- add ack from Rob on patch 2/3
- rebased onto v4.9-rc5
v2 -> v3 changes:
- update the preparatory atmel_ssc_dai patch with error checking and
fallback handling of the CMR_DIV divider in addition to the new
fallback handling of TCMR_PERIOD/RCMR_PERIOD from v2.
v1 -> v2 changes:
- new subject for the bindings patch to make it easier to find
- move the driver to the sound/soc/atmel directory
- add cached values for add/loop1/loop2 to avoid gets from output gpios
- use _cansleep when updating gpios
- add comment on how the regulator voltage is mapped to the ana enum
- drop the .hw_params hook that did set the cpu dai divider and...
- ...add a preparatory patch that does this in the cpu dai driver instead
- drop .init and set the dapm routes directly in the card struct instead
The TSE-850 is an FM Transmitter Station Equipment, designed to generate
baseband signals for FM, mainly the DARC subcarrier, but other signals
are also possible.
This adds a driver for the "sound" bits of the device (quoted since it
is normally not used for normal sound output, but that works too of
course).
I have not provided a patch to add axentia as a devicetree vendor prefix,
since such a patch is already pending in an IIO series [1] that is on its
merry way into -next.
However, there are a couple of points that I'm not 100% satisfied with
for this driver.
First, I do not know how to describe the relays that control if the
IN1/IN2 signals are directly routed towards OUT1/OUT2 or if they are
routed to the "add" switch. The dapm routing treats this as if the
IN1/IN2 signals are always routed to both the "add" switch and to
the muxes feeding OUT1/OUT2. This is fine with me since nothing is
powered in those sections anyway, so what dapm thinks does not really
matter. But it is a wart all the same.
Second, there's my comment in tse850_put_mix() when the "add" switch
is updated. I believe this update should really happen as a side
effect of the call to snd_soc_dapm_mixer_update_power(), so that it
happens at the right point compared to other stuff that is powered.
But I do not know how to hook that up and instead I flip the switch
before the call since it doesn't really matter. I.e., any noise
resulting from this badness is negligeble in practice.
Cheers,
Peter
[1] http://lwn.net/Articles/705931
Peter Rosin (3):
ASoC: atmel_ssc_dai: if not provided, default to sensible dividers
ASoC: tse850: document axentia,tse850-pcm5142 bindings
ASoC: atmel: tse850: add ASoC driver for the Axentia TSE-850
.../bindings/sound/axentia,tse850-pcm5142.txt | 88 ++++
MAINTAINERS | 7 +
sound/soc/atmel/Kconfig | 10 +
sound/soc/atmel/Makefile | 2 +
sound/soc/atmel/atmel_ssc_dai.c | 83 +++-
sound/soc/atmel/atmel_ssc_dai.h | 1 +
sound/soc/atmel/tse850-pcm5142.c | 472 +++++++++++++++++++++
7 files changed, 656 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt
create mode 100644 sound/soc/atmel/tse850-pcm5142.c
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] ARM: zynq: Fix W=1 dtc 1.4 warnings
From: Michal Simek @ 2016-11-15 18:01 UTC (permalink / raw)
To: Julia Cartwright, Michal Simek
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
S?ren Brinkmann, devicetree-u79uwXL29TY76Z2rM5mHXA,
Steffen Trumtrar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Peter Crosthwaite, Rob Herring, Rob Herring, Mark Rutland,
Russell King
In-Reply-To: <20161115154608.GH30999-ew3lsbMjNqt5wtABiV/Xjqyly8cj88Ttqxv4g6HH51o@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 2037 bytes --]
Hi,
On 15.11.2016 16:46, Julia Cartwright wrote:
> On Tue, Nov 15, 2016 at 03:07:27PM +0100, Michal Simek wrote:
>> The patch removes these warnings reported by dtc 1.4:
>> Warning (unit_address_vs_reg): Node /pmu has a reg or ranges property,
>> but no unit name
>> Warning (unit_address_vs_reg): Node /fixedregulator@0 has a unit name,
>> but no reg property
>> Warning (unit_address_vs_reg): Node /memory has a reg or ranges
>> property, but no unit name
>>
>> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>
> Reviewed-by: Julia Cartwright <julia-acOepvfBmUk@public.gmane.org>
>>
>> ---
>>
>> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
>> arch/arm/boot/dts/zynq-parallella.dts | 2 +-
>> arch/arm/boot/dts/zynq-zc702.dts | 2 +-
>> arch/arm/boot/dts/zynq-zc706.dts | 2 +-
>> arch/arm/boot/dts/zynq-zed.dts | 2 +-
>> arch/arm/boot/dts/zynq-zybo.dts | 2 +-
>> 6 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
>> index f47a6c1cc752..402b5bbe3b5b 100644
>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>> @@ -42,14 +42,14 @@
>> };
>> };
>>
>> - pmu {
>> + pmu@f8891000 {
>> compatible = "arm,cortex-a9-pmu";
>> interrupts = <0 5 4>, <0 6 4>;
>> interrupt-parent = <&intc>;
>> reg = < 0xf8891000 0x1000 0xf8893000 0x1000 >;
>
> Style nit: we should drop the space before/after '<' and '>'; and,
> perhaps separate the entries to be a bit more readable:
>
> reg = <0xf8891000 0x1000>,
> <0xf8893000 0x1000>;
yes we can do it. Do you want to send separate patch for it?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 09/11] ARM: shmobile: document SK-RZG1M board
From: Simon Horman @ 2016-11-15 17:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3956722.6l6VXXKMOL-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Sat, Oct 29, 2016 at 01:23:59AM +0300, Sergei Shtylyov wrote:
> Document the SK-RZG1E device tree bindings, listing it as a supported board.
>
> This allows to use checkpatch.pl to validate .dts files referring to the
> SK-RZG1E board.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
I have queued this up after with s/SK-RZG1M/SK-RZG1E/
> ---
> Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> Index: renesas/Documentation/devicetree/bindings/arm/shmobile.txt
> ===================================================================
> --- renesas.orig/Documentation/devicetree/bindings/arm/shmobile.txt
> +++ renesas/Documentation/devicetree/bindings/arm/shmobile.txt
> @@ -77,6 +77,8 @@ Boards:
> compatible = "renesas,salvator-x", "renesas,r8a7796";
> - SILK (RTP0RC7794LCB00011S)
> compatible = "renesas,silk", "renesas,r8a7794"
> + - SK-RZG1E (YR8A77450S000BE)
> + compatible = "renesas,sk-rzg1e", "renesas,r8a7745"
> - SK-RZG1M (YR8A77430S000BE)
> compatible = "renesas,sk-rzg1m", "renesas,r8a7743"
> - Wheat
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 06/11] ARM: dts: r8a7745: add [H]SCIF{A|B} support
From: Simon Horman @ 2016-11-15 17:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <2366203.iKt2DUneo7-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Sat, Oct 29, 2016 at 01:19:40AM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIF{|A|B} ports in the R8A7745 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
I have queued this up after updating the indentation to use
tabs where possible.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/11] Add R8A7745/SK-RZG1E board support
From: Simon Horman @ 2016-11-15 17:55 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc, robh+dt, mark.rutland, devicetree, magnus.damm,
linux, linux-arm-kernel
In-Reply-To: <2368353.xfo5beGC5E@wasted.cogentembedded.com>
On Sat, Nov 05, 2016 at 12:42:33AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 11 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-201611104-v4.9-rc3' tag plus the R8A7743/SK-RZG1M patch series
> posted earlier. I'm adding the device tree support for the R8A7745-based
> SK-RZG1E board. The SoC is close to R8A7794 and the board seems identical to the
> R8A7794/SILK board. The device tree patches depend on the R8A7745 CPG/MSSR
> driver series in order to compile and work.
Thanks, I have queued this up.
^ permalink raw reply
* Re: [PATCH v6 3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
From: Simon Horman @ 2016-11-15 17:54 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <29562553.JmvzVUkhx3-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
On Mon, Oct 31, 2016 at 10:55:39PM +0300, Sergei Shtylyov wrote:
> Describe [H]SCIF{|A|B} ports in the R8A7743 device tree.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
I have queued this up after updating the indentation to use
tabs where possible.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 0/7] Add R8A7743/SK-RZG1M board support
From: Simon Horman @ 2016-11-15 17:54 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: linux-renesas-soc, robh+dt, mark.rutland, devicetree, magnus.damm,
linux, linux-arm-kernel
In-Reply-To: <1746536.qobnGdHRfV@wasted.cogentembedded.com>
On Mon, Oct 31, 2016 at 10:52:25PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 7 patches against Simon Horman's 'renesas.git' repo's
> 'renesas-devel-20161031-v4.9-rc3' tag. I'm adding the device tree support for
> the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
> seems identical to the R8A7791/Porter board. The device tree patches depend on
> the R8A7743 CPG/MSSR driver series in order to compile and work. Already merged
> patches from this series won't be re-posted.
>
> [1/7] ARM: dts: r8a7743: initial SoC device tree
> [2/7] ARM: dts: r8a7743: add SYS-DMAC support
> [3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
> [4/7] ARM: dts: r8a7743: add Ether support
> [5/7] ARM: dts: r8a7743: add IRQC support
> [6/7] ARM: dts: sk-rzg1m: initial device tree
> [7/7] ARM: dts: sk-rzg1m: add Ether support
Thanks, I have queued this up.
^ permalink raw reply
* Re: [PATCH v3 00/11] soc: renesas: Identify SoC and register with the SoC bus
From: Simon Horman @ 2016-11-15 17:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Magnus Damm, Arnd Bergmann, Rob Herring, Mark Rutland, Dirk Behme,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479148637-5399-1-git-send-email-geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
On Mon, Nov 14, 2016 at 07:37:06PM +0100, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> Some Renesas SoCs may exist in different revisions, providing slightly
> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
> (errate and quirks). This needs to be catered for by drivers and/or
> platform code. The recently proposed soc_device_match() API is a good
> fit to handle this.
>
> This patch series implements the core infrastructure to provide SoC and
> revision information through the SoC bus for Renesas ARM SoCs.
For the record I have queued this up.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/2] pinctrl: sunxi: Support the interrupt debouncing
From: Maxime Ripard @ 2016-11-15 17:50 UTC (permalink / raw)
To: Linus Walleij, Alexandre Courbot
Cc: linux-gpio, devicetree, Rob Herring, Chen-Yu Tsai
In-Reply-To: <cover.fa554eb1146d18ec75bf44863543fec4fa4fd3ae.1479156725.git-series.maxime.ripard@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 508 bytes --]
On Mon, Nov 14, 2016 at 09:53:02PM +0100, Maxime Ripard wrote:
> Hi,
>
> The Allwinner pin controllers can setup a different debouncing period based
> on two clocks and a prescaler.
>
> This debouncing is applied to the whole IRQ bank, which prevents us from
> using the per-pin property that is usually used.
>
> Let me know what you think,
> Maxime
Applied the second patch.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] ARM: dts: sun7i: BPI-M1+ USB support
From: Maxime Ripard @ 2016-11-15 17:42 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161115135106.438-1-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Tue, Nov 15, 2016 at 09:51:03PM +0800, Chen-Yu Tsai wrote:
> Hi Maxime,
>
> These are the remaining patches of my BPI-M1+ fixes series from July.
>
> Changes since v1:
>
> - Split out USB PHY enable patch.
>
> - Dropped custom OPP table. Tested the A20 default one with
> cpufreq-ljt-stress-test and it seemed stable.
>
> - Dropped voltage range for cpu supply regulator to normal 1.0V ~ 1.4V.
>
> - Dropped pinmux setting for OTG ID pin.
Applied all three, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers
From: Bartosz Golaszewski @ 2016-11-15 17:36 UTC (permalink / raw)
To: Jyri Sarha
Cc: linux-drm, linux-devicetree, David Airlie, daniel-/w4YWyX8dFk,
Tomi Valkeinen, Laurent Pinchart,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, Kevin Hilman, Benoit Cousson
In-Reply-To: <12cd62cc9ea0f79d0f399c76bfa715125a0816ce.1479142062.git.jsarha-l0cyMroinI0@public.gmane.org>
2016-11-14 17:54 GMT+01:00 Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>:
> Adds drm bride support for attaching drm bridge drivers to tilcdc. The
> decision whether a video port leads to an external encoder or bridge
> is made simply based on remote device's compatible string. The code
> has been tested with BeagleBone-Black with and without BeagleBone
> DVI-D Cape Rev A3 using ti-tfp410 driver.
>
> Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
> ---
Hi Jyri,
thanks a lot for doing this.
One issue I see with this patch is that tilcdc doesn't seem to support
deferred probe correctly (if modules are built-in). The following
happens on my setup:
The dump-vga-dac module is loaded first, but the i2c0 is not ready yet
- probe returns EPROBE_DEFER and it's propagated to tilcdc probe.
[drm] Initialized
dumb-vga-dac vga_bridge: Couldn't retrieve i2c bus
Then the i2c bus is initialized and dump-vga-dac probe succeeds, but
the second probe of tilcdc gives me:
[drm:drm_debugfs_init] *ERROR* Cannot create /sys/kernel/debug/dri/64
[drm:drm_minor_register] *ERROR* DRM: Failed to initialize
/sys/kernel/debug/dri.
tilcdc: probe of da8xx_lcdc.0 failed with error -1
I was able to work around this issue by loading modules in correct order.
I then tried testing the patch with a da850-lcdk, but I don't get
anything on the display (no signal), even though the LCDC seems to
work fine (modetest and dmesg messages work just like when using the
tilcdc panel). Also: I see the EDID info is correctly retrieved from
the display.
Could you take a look at my DT[1] and see if you find it correct?
Best regards,
Bartosz Golaszewski
[1] http://pastebin.com/dfUX7PyL
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/9] doc: DT: vidc: binding document for Qualcomm video driver
From: Stanimir Varbanov @ 2016-11-15 17:15 UTC (permalink / raw)
To: Rob Herring, Stanimir Varbanov
Cc: Mauro Carvalho Chehab, Hans Verkuil, Andy Gross, Bjorn Andersson,
Stephen Boyd, Srinivas Kandagatla, linux-media, linux-kernel,
linux-arm-msm, Mark Rutland, devicetree
In-Reply-To: <20161114170410.56izii5gcwpofvc4@rob-hp-laptop>
Hi Rob,
Thanks for the comments!
On 11/14/2016 07:04 PM, Rob Herring wrote:
> On Mon, Nov 07, 2016 at 07:33:55PM +0200, Stanimir Varbanov wrote:
>> Add binding document for Venus video encoder/decoder driver
>>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: devicetree@vger.kernel.org
>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>> ---
>> .../devicetree/bindings/media/qcom,venus.txt | 98 ++++++++++++++++++++++
>> 1 file changed, 98 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> new file mode 100644
>> index 000000000000..b2af347fbce4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
>> @@ -0,0 +1,98 @@
>> +* Qualcomm Venus video encode/decode accelerator
>> +
>> +- compatible:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Value should contain one of:
>> + - "qcom,venus-msm8916"
>> + - "qcom,venus-msm8996"
>
> The normal ordering is <vendor>,<soc>-<block>
OK.
>
>> +- reg:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Register ranges as listed in the reg-names property.
>> +- reg-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "venus" Venus register base
>> +- reg-names:
>
> I'd prefer these grouped as one entry for reg-names.
>
>> + Usage: optional for msm8996
>
> Why optional?
The Venus hw block can work without internal video memory in which case
just performance will be impacted.
>
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "vmem" Video memory register base
>> +- interrupts:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: Should contain interrupts as listed in the interrupt-names
>> + property.
>> +- interrupt-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "venus" Venus interrupt line
>> +- interrupt-names:
>> + Usage: optional for msm8996
>> + Value type: <stringlist>
>> + Definition: Should contain following entries:
>> + - "vmem" Video memory interrupt line
>> +- clocks:
>> + Usage: required
>> + Value type: <prop-encoded-array>
>> + Definition: A List of phandle and clock specifier pairs as listed
>> + in clock-names property.
>> +- clock-names:
>> + Usage: required
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "core" Core video accelerator clock
>> + - "iface" Video accelerator AHB clock
>> + - "bus" Video accelerator AXI clock
>> +- clock-names:
>> + Usage: required for msm8996
>
> Plus the 3 above?
Yes, 'required' without 'for xxx' means that the clocks are required for
all hw versions (SoCs) and msm8996 needs the extra clocks below.
>
>> + Value type: <stringlist>
>> + Definition: Should contain the following entries:
>> + - "subcore0" Subcore0 video accelerator clock
>> + - "subcore1" Subcore1 video accelerator clock
>> + - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
>> + - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
>> + - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
>> + - "mmagic_video_bus" MMAGIC video AXI clock
>> + - "video_mbus" Video MAXI clock
>> +- clock-names:
>> + Usage: optional for msm8996
>
> Clocks shouldn't be optional unless you failed to add in an initial
> binding.
These clocks are needed by video memory block which I noted as
'optional'. There is another way to model this video memory hw block
i.e. by a child node of the venus node. Is that sounds better?
<snip>
--
regards,
Stan
^ permalink raw reply
* Re: [PATCH 1/2] regulator: pwm: DT: Add ramp delay for exponential voltage transition
From: Laxman Dewangan @ 2016-11-15 17:13 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Brown, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Douglas Anderson, Aleksandr Frid
In-Reply-To: <CAL_Jsq+=oyRC7ZPcva_B6CB_vCquzpRw0UU=nfdjxEbzkKjiVw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tuesday 15 November 2016 07:57 PM, Rob Herring wrote:
> On Tue, Nov 15, 2016 at 5:42 AM, Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> On Monday 14 November 2016 09:18 PM, Rob Herring wrote:
>>> On Fri, Nov 04, 2016 at 11:07:54PM +0530, Laxman Dewangan wrote:
>>>>
>>>> regulator
>>>> +- pwm-regulator-voltage-ramp-time-us: Integer, voltage ramp time in
>>> This is a really long name. Drop the 'pwm-regulator-' part as it is
>>> redundant. The fact that it is PWM reg specific is captured as it is
>>> documented that way.
>>>
>> We already have the regulator-ramp-delay from the regulator core.
>> Just wanted to make this (pwm-regulator-voltage-ramp-time-us) for pwm
>> specific.
> Neither of these are very clear that one is linear and one is
> exponential. Maybe you should use the existing property to express the
> time and just add a boolean property like "voltage-ramp-exponential"?
OK, this can work.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/5] pinctrl: core: Use delayed work for hogs
From: Tony Lindgren @ 2016-11-15 17:08 UTC (permalink / raw)
To: Linus Walleij
Cc: Haojian Zhuang, Masahiro Yamada, Grygorii Strashko,
Nishanth Menon, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Linux-OMAP
In-Reply-To: <20161115154124.GI4082@atomide.com>
* Tony Lindgren <tony@atomide.com> [161115 07:42]:
> * Linus Walleij <linus.walleij@linaro.org> [161114 22:53]:
> > On Tue, Nov 15, 2016 at 1:47 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> > > 8< --------------------------------
> > > From tony Mon Sep 17 00:00:00 2001
> > > From: Tony Lindgren <tony@atomide.com>
> > > Date: Tue, 25 Oct 2016 08:33:35 -0700
> > > Subject: [PATCH] pinctrl: core: Use delayed work for hogs
> > >
> > > Having the pin control framework call pin controller functions
> > > before it's probe has finished is not nice as the pin controller
> > > device driver does not yet have struct pinctrl_dev handle.
> > >
> > > Let's fix this issue by adding deferred work for late init. This is
> > > needed to be able to add pinctrl generic helper functions that expect
> > > to know struct pinctrl_dev handle. Note that we now need to call
> > > create_pinctrl() directly as we don't want to add the pin controller
> > > to the list of controllers until the hogs are claimed. We also need
> > > to pass the pinctrl_dev to the device tree parser functions as they
> > > otherwise won't find the right controller at this point.
> > >
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> >
> > This looks a lot better!
> >
> > So if I understand correctly, we can guarantee that the delayed
> > work will not execute until the device driver probe() has finished,
> > and it *will* execute immediately after that?
> >
> > So:
> > - Device driver probes
> > - Delayed work is called
> > - Next initcall
> >
> > I'm not 100% familiar with how delayed work works... :/
>
> Yeah well the delayed work gets scheduled for next jiffy but may
> be pre-empted as it runs in process context.
>
> So in the worst case it could that we still may need to fix few
> drivers to support -EPROBE_DEFER. I wonder if we should check for
> hogs in probe already and only defer if hogs are defined?
Below is a version using delayed_work only if pinctrl_dt_has_hogs().
Not sure if testing only for pinctrl-0 is enough there though?
Regards,
Tony
8< --------------------------------
>From tony Mon Sep 17 00:00:00 2001
From: Tony Lindgren <tony@atomide.com>
Date: Tue, 25 Oct 2016 08:33:35 -0700
Subject: [PATCH] pinctrl: core: Use delayed work for hogs
Having the pin control framework call pin controller functions
before it's probe has finished is not nice as the pin controller
device driver does not yet have struct pinctrl_dev handle.
Let's fix this issue by adding deferred work for late init. This is
needed to be able to add pinctrl generic helper functions that expect
to know struct pinctrl_dev handle. Note that we now need to call
create_pinctrl() directly as we don't want to add the pin controller
to the list of controllers until the hogs are claimed. We also need
to pass the pinctrl_dev to the device tree parser functions as they
otherwise won't find the right controller at this point.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
drivers/pinctrl/core.c | 90 ++++++++++++++++++++++++++++----------------
drivers/pinctrl/core.h | 2 +
drivers/pinctrl/devicetree.c | 28 +++++++++++---
drivers/pinctrl/devicetree.h | 12 +++++-
4 files changed, 93 insertions(+), 39 deletions(-)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -720,7 +720,8 @@ static struct pinctrl_state *create_state(struct pinctrl *p,
return state;
}
-static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
+static int add_setting(struct pinctrl *p, struct pinctrl_dev *pctldev,
+ struct pinctrl_map const *map)
{
struct pinctrl_state *state;
struct pinctrl_setting *setting;
@@ -744,7 +745,11 @@ static int add_setting(struct pinctrl *p, struct pinctrl_map const *map)
setting->type = map->type;
- setting->pctldev = get_pinctrl_dev_from_devname(map->ctrl_dev_name);
+ if (pctldev)
+ setting->pctldev = pctldev;
+ else
+ setting->pctldev =
+ get_pinctrl_dev_from_devname(map->ctrl_dev_name);
if (setting->pctldev == NULL) {
kfree(setting);
/* Do not defer probing of hogs (circular loop) */
@@ -800,7 +805,8 @@ static struct pinctrl *find_pinctrl(struct device *dev)
static void pinctrl_free(struct pinctrl *p, bool inlist);
-static struct pinctrl *create_pinctrl(struct device *dev)
+static struct pinctrl *create_pinctrl(struct device *dev,
+ struct pinctrl_dev *pctldev)
{
struct pinctrl *p;
const char *devname;
@@ -823,7 +829,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
INIT_LIST_HEAD(&p->states);
INIT_LIST_HEAD(&p->dt_maps);
- ret = pinctrl_dt_to_map(p);
+ ret = pinctrl_dt_to_map(p, pctldev);
if (ret < 0) {
kfree(p);
return ERR_PTR(ret);
@@ -838,7 +844,7 @@ static struct pinctrl *create_pinctrl(struct device *dev)
if (strcmp(map->dev_name, devname))
continue;
- ret = add_setting(p, map);
+ ret = add_setting(p, pctldev, map);
/*
* At this point the adding of a setting may:
*
@@ -899,7 +905,7 @@ struct pinctrl *pinctrl_get(struct device *dev)
return p;
}
- return create_pinctrl(dev);
+ return create_pinctrl(dev, NULL);
}
EXPORT_SYMBOL_GPL(pinctrl_get);
@@ -1738,6 +1744,46 @@ static int pinctrl_check_ops(struct pinctrl_dev *pctldev)
}
/**
+ * pinctrl_late_init() - finish pin controller device registration
+ * @work: work struct
+ */
+static void pinctrl_late_init(struct work_struct *work)
+{
+ struct pinctrl_dev *pctldev;
+
+ pctldev = container_of(work, struct pinctrl_dev, late_init.work);
+
+ pctldev->p = create_pinctrl(pctldev->dev, pctldev);
+ if (!IS_ERR(pctldev->p)) {
+ kref_get(&pctldev->p->users);
+ pctldev->hog_default =
+ pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(pctldev->hog_default)) {
+ dev_dbg(pctldev->dev,
+ "failed to lookup the default state\n");
+ } else {
+ if (pinctrl_select_state(pctldev->p,
+ pctldev->hog_default))
+ dev_err(pctldev->dev,
+ "failed to select default state\n");
+ }
+
+ pctldev->hog_sleep =
+ pinctrl_lookup_state(pctldev->p,
+ PINCTRL_STATE_SLEEP);
+ if (IS_ERR(pctldev->hog_sleep))
+ dev_dbg(pctldev->dev,
+ "failed to lookup the sleep state\n");
+ }
+
+ mutex_lock(&pinctrldev_list_mutex);
+ list_add_tail(&pctldev->node, &pinctrldev_list);
+ mutex_unlock(&pinctrldev_list_mutex);
+
+ pinctrl_init_device_debugfs(pctldev);
+}
+
+/**
* pinctrl_register() - register a pin controller device
* @pctldesc: descriptor for this pin controller
* @dev: parent device for this pin controller
@@ -1766,6 +1812,7 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
pctldev->driver_data = driver_data;
INIT_RADIX_TREE(&pctldev->pin_desc_tree, GFP_KERNEL);
INIT_LIST_HEAD(&pctldev->gpio_ranges);
+ INIT_DELAYED_WORK(&pctldev->late_init, pinctrl_late_init);
pctldev->dev = dev;
mutex_init(&pctldev->mutex);
@@ -1800,32 +1847,10 @@ struct pinctrl_dev *pinctrl_register(struct pinctrl_desc *pctldesc,
goto out_err;
}
- mutex_lock(&pinctrldev_list_mutex);
- list_add_tail(&pctldev->node, &pinctrldev_list);
- mutex_unlock(&pinctrldev_list_mutex);
-
- pctldev->p = pinctrl_get(pctldev->dev);
-
- if (!IS_ERR(pctldev->p)) {
- pctldev->hog_default =
- pinctrl_lookup_state(pctldev->p, PINCTRL_STATE_DEFAULT);
- if (IS_ERR(pctldev->hog_default)) {
- dev_dbg(dev, "failed to lookup the default state\n");
- } else {
- if (pinctrl_select_state(pctldev->p,
- pctldev->hog_default))
- dev_err(dev,
- "failed to select default state\n");
- }
-
- pctldev->hog_sleep =
- pinctrl_lookup_state(pctldev->p,
- PINCTRL_STATE_SLEEP);
- if (IS_ERR(pctldev->hog_sleep))
- dev_dbg(dev, "failed to lookup the sleep state\n");
- }
-
- pinctrl_init_device_debugfs(pctldev);
+ if (pinctrl_dt_has_hogs(pctldev))
+ schedule_delayed_work(&pctldev->late_init, 0);
+ else
+ pinctrl_late_init(&pctldev->late_init.work);
return pctldev;
@@ -1848,6 +1873,7 @@ void pinctrl_unregister(struct pinctrl_dev *pctldev)
if (pctldev == NULL)
return;
+ cancel_delayed_work_sync(&pctldev->late_init);
mutex_lock(&pctldev->mutex);
pinctrl_remove_device_debugfs(pctldev);
mutex_unlock(&pctldev->mutex);
diff --git a/drivers/pinctrl/core.h b/drivers/pinctrl/core.h
--- a/drivers/pinctrl/core.h
+++ b/drivers/pinctrl/core.h
@@ -33,6 +33,7 @@ struct pinctrl_gpio_range;
* @p: result of pinctrl_get() for this device
* @hog_default: default state for pins hogged by this device
* @hog_sleep: sleep state for pins hogged by this device
+ * @late_init: delayed work for pin controller to finish registration
* @mutex: mutex taken on each pin controller specific action
* @device_root: debugfs root for this device
*/
@@ -47,6 +48,7 @@ struct pinctrl_dev {
struct pinctrl *p;
struct pinctrl_state *hog_default;
struct pinctrl_state *hog_sleep;
+ struct delayed_work late_init;
struct mutex mutex;
#ifdef CONFIG_DEBUG_FS
struct dentry *device_root;
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -100,11 +100,12 @@ struct pinctrl_dev *of_pinctrl_get(struct device_node *np)
return get_pinctrl_dev_from_of_node(np);
}
-static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
+static int dt_to_map_one_config(struct pinctrl *p,
+ struct pinctrl_dev *pctldev,
+ const char *statename,
struct device_node *np_config)
{
struct device_node *np_pctldev;
- struct pinctrl_dev *pctldev;
const struct pinctrl_ops *ops;
int ret;
struct pinctrl_map *map;
@@ -121,7 +122,8 @@ static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
/* OK let's just assume this will appear later then */
return -EPROBE_DEFER;
}
- pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
+ if (!pctldev)
+ pctldev = get_pinctrl_dev_from_of_node(np_pctldev);
if (pctldev)
break;
/* Do not defer probing of hogs (circular loop) */
@@ -166,7 +168,22 @@ static int dt_remember_dummy_state(struct pinctrl *p, const char *statename)
return dt_remember_or_free_map(p, statename, NULL, map, 1);
}
-int pinctrl_dt_to_map(struct pinctrl *p)
+bool pinctrl_dt_has_hogs(struct pinctrl_dev *pctldev)
+{
+ struct device_node *np;
+ struct property *prop;
+ int size;
+
+ np = pctldev->dev->of_node;
+ if (!np)
+ return false;
+
+ prop = of_find_property(np, "pinctrl-0", &size);
+
+ return prop ? true : false;
+}
+
+int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev)
{
struct device_node *np = p->dev->of_node;
int state, ret;
@@ -233,7 +250,8 @@ int pinctrl_dt_to_map(struct pinctrl *p)
}
/* Parse the node */
- ret = dt_to_map_one_config(p, statename, np_config);
+ ret = dt_to_map_one_config(p, pctldev, statename,
+ np_config);
of_node_put(np_config);
if (ret < 0)
goto err;
diff --git a/drivers/pinctrl/devicetree.h b/drivers/pinctrl/devicetree.h
--- a/drivers/pinctrl/devicetree.h
+++ b/drivers/pinctrl/devicetree.h
@@ -20,8 +20,10 @@ struct of_phandle_args;
#ifdef CONFIG_OF
+bool pinctrl_dt_has_hogs(struct pinctrl_dev *pctldev);
+
void pinctrl_dt_free_maps(struct pinctrl *p);
-int pinctrl_dt_to_map(struct pinctrl *p);
+int pinctrl_dt_to_map(struct pinctrl *p, struct pinctrl_dev *pctldev);
int pinctrl_count_index_with_args(const struct device_node *np,
const char *list_name);
@@ -32,7 +34,13 @@ int pinctrl_parse_index_with_args(const struct device_node *np,
#else
-static inline int pinctrl_dt_to_map(struct pinctrl *p)
+static inline bool pinctrl_dt_has_hogs(struct pinctrl_dev *pctldev)
+{
+ return false;
+}
+
+static inline int pinctrl_dt_to_map(struct pinctrl *p,
+ struct pinctrl_dev *pctldev)
{
return 0;
}
--
2.10.2
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Florian Fainelli @ 2016-11-15 17:03 UTC (permalink / raw)
To: Andrew Lunn, Jerome Brunet
Cc: netdev, devicetree, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <20161115163036.GB23231@lunn.ch>
On 11/15/2016 08:30 AM, Andrew Lunn wrote:
> On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
>> On some platforms, energy efficient ethernet with rtl8211 devices is
>> causing issue, like throughput drop or broken link.
>>
>> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
>> cause is not fully understood yet, disabling EEE advertisement prevent auto
>> negotiation from enabling EEE.
>>
>> This patch provides options to disable 1000T and 100TX EEE advertisement
>> individually for the realtek phys supporting this feature.
>
> Looking at the code, i don't see anything specific to RealTek
> here. This all seems generic. So should it be in phy.c and made a
> generic OF property which can be applied to any PHY which supports
> EEE.
Agreed. Just to be sure, Jerome, you did verify that with EEE no longer
advertised, ethtool --set-eee fails, right? The point is that you may be
able to disable EEE on boot, but if there is a way to re-enable it later
on, we would want to disable that too.
--
Florian
^ permalink raw reply
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-15 16:36 UTC (permalink / raw)
To: Rob Herring, Olof Johansson
Cc: Sudeep Holla, Neil Armstrong,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-amlogic
In-Reply-To: <4e31f1d9-61b9-53a9-bd0c-dd5e452faece@arm.com>
On 11/11/16 14:19, Sudeep Holla wrote:
>
>
> On 11/11/16 13:34, Rob Herring wrote:
>> On Fri, Nov 11, 2016 at 1:48 AM, Sudeep Holla <sudeep.holla@arm.com>
>> wrote:
[...]
>>>
>>> True and I agree, how about "arm,scpi-pre-1.0" instead ?
>>
>> That's still meaningless. Convince me that multiple implementations
>> are identical, then we can have a common property. For example, how
>> many releases did ARM make before 1.0.
>>
>
> None officially, so I tend to agree with you on this.
>
> But so far we have seen some commonality between Rockchip and Amlogic
> implementations, which in fact shares some commonality with early
> release of SCPI from ARM (there are based on the same SCP code base,
> which is closed source and released to partners only). ARM improved the
> specification and the code base before the official release but by then
> it was adopted(as usual we were late ;))
>
> IMO, it's might be useful to have more generic say "arm,scpi-pre-1.0"
> and platform specific "amlogic,meson-gxbb-scpi"
>
Rob and Olof, is it convincing enough reason to have generic compatible?
Or you prefer to drop it ?
I prefer to have "arm,scpi-pre-1.0". IMO it's useful, let me know. I
need to send PR as it's getting late now.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-15 16:30 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev, devicetree, Florian Fainelli, Carlo Caione, Kevin Hilman,
Giuseppe Cavallaro, Alexandre TORGUE, Martin Blumenstingl,
Andre Roth, Neil Armstrong, linux-amlogic, linux-arm-kernel,
linux-kernel
In-Reply-To: <1479220154-25851-2-git-send-email-jbrunet@baylibre.com>
On Tue, Nov 15, 2016 at 03:29:12PM +0100, Jerome Brunet wrote:
> On some platforms, energy efficient ethernet with rtl8211 devices is
> causing issue, like throughput drop or broken link.
>
> This was reported on the OdroidC2 (DWMAC + RTL8211F). While the issue root
> cause is not fully understood yet, disabling EEE advertisement prevent auto
> negotiation from enabling EEE.
>
> This patch provides options to disable 1000T and 100TX EEE advertisement
> individually for the realtek phys supporting this feature.
Looking at the code, i don't see anything specific to RealTek
here. This all seems generic. So should it be in phy.c and made a
generic OF property which can be applied to any PHY which supports
EEE.
Andrew
^ permalink raw reply
* Re: [PATCH v4 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Stanimir Varbanov @ 2016-11-15 16:30 UTC (permalink / raw)
To: Srinivas Kandagatla, linux-pci-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8d0e9b19-5d6f-8be5-84be-d102817a6b21-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/15/2016 06:10 PM, Srinivas Kandagatla wrote:
>
>
> On 15/11/16 15:08, Stanimir Varbanov wrote:
>>>> I don't like MSM8996_ prefix. Could you invent a macro which depending
>>>> >> on controller selects proper offset?
>>> >
>>> > maybe some like this ??
>>> >
>>> > #define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V2 0x1A8
>> No, I wanted to preserve the name of the register offset. By that way in
>> the next pcie controller version we do not need to have
>> PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT_V3.
>>
>> I was thinking for something like
>>
>> PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT(ver) \
>> ((ver) == VERSION_1 ? 0x178 : 0x1A8)
>>
>> But you will need to extend qcom_pcie_ops with new member to store the
>> version.
>>
>> It's up to you ... or we can fix it when new version of the controller
>> appear.
> TBH, I don't want to add this just for this one case, looks bit over do.
> So I skipped to using V2 Suffix.
> We can fix later if required.
OK, sounds good.
regards,
Stan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ata: xgene: Enable NCQ support for APM X-Gene SATA controller hardware v1.1
From: Tejun Heo @ 2016-11-15 16:21 UTC (permalink / raw)
To: Rameshwar Sahu
Cc: Olof Johansson, linux-scsi, linux-ide, Devicetree List, linux-arm,
Don Dutile, Jon Masters, patches
In-Reply-To: <CAFd313ycmpdp7wHCVRJrigJV31hLwBGOo=FNENwgFnNKyVkQBA@mail.gmail.com>
Hello, Rameshwar.
On Fri, Nov 11, 2016 at 01:36:28PM +0530, Rameshwar Sahu wrote:
> Hi Tejun,
>
> On Wed, Nov 9, 2016 at 10:15 PM, Tejun Heo <tj@kernel.org> wrote:
> > Hello,
> >
> > On Wed, Sep 14, 2016 at 04:15:00PM +0530, Rameshwar Sahu wrote:
> >> > @@ -821,8 +823,6 @@ static int xgene_ahci_probe(struct platform_device
> >> > *pdev)
> >> > dev_warn(&pdev->dev, "%s: Error reading
> >> > device info. Assume version1\n",
> >> > __func__);
> >> > version = XGENE_AHCI_V1;
> >> > - } else if (info->valid & ACPI_VALID_CID) {
> >> > - version = XGENE_AHCI_V2;
> >
> > Can you please explain this part a bit? Everything else looks good to
> > me.
>
> Here we should not assume XGENE_AHCI_V2 always in case of having valid
> _CID in ACPI table.
> I need to remove this assumption because V1_1 has also valid _CID for
> backward compatibly with v1.
Can you please repost with the above explanation added to the commit
message?
Thanks!
--
tejun
^ 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