* Re: [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Thomas Petazzoni @ 2016-11-10 10:15 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87wpgbekwg.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Thu, 10 Nov 2016 10:36:47 +0100, Gregory CLEMENT wrote:
> >> - bootrom {
> >> + bootrom@0 {
> >> compatible = "marvell,bootrom";
> >> reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
> >
> > I am still not sure whether this "0" unit address is correct compared
> > to the reg property being passed.
>
> I chose to use the adress register inside the window memory.
Which I think is bogus, as my example below highlighted.
> > A good example of why I'm worried is the sa-sram case:
> >
> > + crypto_sram0: sa-sram0@0 {
> > compatible = "mmio-sram";
> > reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
> >
> > + crypto_sram1: sa-sram1@0 {
> > compatible = "mmio-sram";
> > reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
> >
> > The node names should be just "sram" without a number. Indeed for UARTs
> > for example, you use uart@XYZ, uart@ABC and not uart0@XYZ and
> > uart1@ABC. But then, if you do that, with your scheme, you end up with
> > both nodes named sa-sram@0.
> >
> > Which clearly shows that the way you set this unit-address is not
> > correct: those two devices are mapped at completely different
> > locations, but you end up with an identical unit address.
> >
> > I have no idea what is the rule for setting the unit address in this
> > case, but I'm pretty sure the rule you've chosen is not good.
>
> I don't know if there is an existing rules for this case. But I see your
> concern. What I propose then is to expose the memory windows ID by
> adding the target and the attributes like this:
>
> crypto_sram0: sa-sram@09_09_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>
>
> crypto_sram1: sa-sram@09_05_0 {
> compatible = "mmio-sram";
> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
I have no idea if 09_05_0 is considered a valid unit address. Indeed
the _ character in an address looks a bit weird.
I guess we need guidance from the DT binding maintainers on this, since
it's really a matter of interpreting what "unit address" means in
relation to the value of the "reg" property.
Rob, Mark?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:19 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <3693445.TSdZGaiT9S@wuerfel>
Hi Arnd,
Thanks for your comments!
On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> v2:
>> - Drop SoC families and family names; use fixed "Renesas" instead,
>
> I think I'd rather have seen the family names left in there, but it's
> not important, so up to you.
They're not useful for matching, as family names may change anytime, and don't
always say much about the hardware capabilities.
E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
SuperH.
At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> available, else fall back to hardcoded addresses for compatibility
>> with existing DTBs,
>
> I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> binding for these, among other things.
I understand you've received them in the mean time?
> It does seem wrong to have a device node for a specific register though.
> Shouldn't the node be for the block of registers that these are inside
> of?
On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
we further don't touch at all.
On R-Car Gen2, it's not documented, but does exist.
BTW, see why I'd prefer not to have it in DT at all, and go for KISS in code
we can change at any time? To avoid mistakes we have to keep on supporting
forever.
>> - Don't register the SoC bus if the chip ID register is missing,
>
> Why? My objection was to hardcoding the register, not to registering
> the device? I think I'd rather see the device registered with an
> empty revision string.
If there's no chip ID register, there's no reason to use soc_device_match(),
as we can always look at a compatible value. All SoCs listed in this driver
have a chip ID register.
if you want me to register the soc_bus for those SoCs regardless, I want to
re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
registers ;-)
>> +#define CCCR 0xe600101c /* Common Chip Code Register */
>> +#define PRR 0xff000044 /* Product Register */
>> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
>> +
>> +static const struct of_device_id renesas_socs[] __initconst = {
>> +#ifdef CONFIG_ARCH_R8A73A4
>> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
>> +#endif
>> +#ifdef CONFIG_ARCH_R8A7740
>> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
>> +#endif
>
> My preference here would be to list the register address only for
> SoCs that are known to need them, while also having .dtb files that
> don't have the nodes.
Even if drivers don't have to handle differences, there's been a long
outstanding request to print SoC revision information during bootup
(E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
>> +static int __init renesas_soc_init(void)
>> +{
>> + struct soc_device_attribute *soc_dev_attr;
>> + const struct of_device_id *match;
>> + void __iomem *chipid = NULL;
>> + struct soc_device *soc_dev;
>> + struct device_node *np;
>> + unsigned int product;
>> +
>> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + of_node_put(np);
>> +
>> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> + if (!np)
>> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> + if (np) {
>> + chipid = of_iomap(np, 0);
>> + of_node_put(np);
>> + } else if (match->data) {
>> + chipid = ioremap((uintptr_t)match->data, 4);
>> + }
>> + if (!chipid)
>>
>
> Here, I'd turn the order around and look for the DT nodes of the
> devices first. Only if they are not found, look at the compatible
> string of the root node. No need to search for a node though,
> you know which one it is when you look for a compatible =
> "renesas,r8a73a4".
"renesas,r8a73a4" is the root node, not the device, so it does not have the
"reg" property for reading the chip ID?
There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
Hence I always need to look at the root nodes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [RESEND PATCH] regulator: pwm: fix syntax errors in the examples
From: Peter Rosin @ 2016-11-10 10:25 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Liam Girdwood, Mark Brown, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
While at it, clean up some other things as well.
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
.../devicetree/bindings/regulator/pwm-regulator.txt | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
index 3aeba9f86ed8..6d98fbaeb506 100644
--- a/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pwm-regulator.txt
@@ -55,11 +55,11 @@ Optional properties:
- enable-gpios: GPIO to use to enable/disable the regulator
Any property defined as part of the core regulator binding can also be used.
-(See: ../regulator/regulator.txt)
+(See: regulator.txt)
Continuous Voltage With Enable GPIO Example:
- pwm_regulator {
- compatible = "pwm-regulator;
+ pwm-regulator {
+ compatible = "pwm-regulator";
pwms = <&pwm1 0 8448 0>;
enable-gpios = <&gpio0 23 GPIO_ACTIVE_HIGH>;
regulator-min-microvolt = <1016000>;
@@ -71,12 +71,12 @@ Continuous Voltage With Enable GPIO Example:
* Inverted PWM logic, and the duty cycle range is limited
* to 30%-70%.
*/
- pwm-dutycycle-range <700 300>; /* */
+ pwm-dutycycle-range <700 300>;
};
Voltage Table Example:
- pwm_regulator {
- compatible = "pwm-regulator;
+ pwm-regulator {
+ compatible = "pwm-regulator";
pwms = <&pwm1 0 8448 0>;
regulator-min-microvolt = <1016000>;
regulator-max-microvolt = <1114000>;
--
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
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Sudeep Holla @ 2016-11-10 10:26 UTC (permalink / raw)
To: Rob Herring
Cc: Sudeep Holla, Neil Armstrong, Olof Johansson,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161110012249.ed56ik6kdffoikym@rob-hp-laptop>
On 10/11/16 01:22, Rob Herring wrote:
> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>> This patch adds specific compatible to support legacy SCPI protocol.
>>
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> index d1882c4540d0..ebd03fc93135 100644
>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power operations.
>>
>> Required properties:
>>
>> -- compatible : should be "arm,scpi"
>> +- compatible : should be
>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or above
>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>
> I'd prefer that we explicitly enumerate the old versions. Are there
> many?
>
I understand your concern, but this legacy SCPI protocol was not
officially released. It was just WIP which vendors picked up from very
early releases. Since they are not numbered, it's hard to have specific
compatibles with different versions until v1.0. That's one of the reason
to retain platform specific compatible so that we can add any quirks
based on them if needed.
I will probably add these information in the commit log so that it's
clear why we can't do version based compatible.
--
Regards,
Sudeep
--
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 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-10 10:34 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Vineet Gupta
In-Reply-To: <DB6PR0501MB25184EFB9A5CFD3AA41CFDC1AAA60@DB6PR0501MB2518.eurprd05.prod.outlook.com>
On 08/11/2016 09:30, Noam Camus wrote:
>> From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
>> Sent: Tuesday, November 1, 2016 10:02 PM
> ...
>> Assuming cpu0 and cpu1 are sibling, does
>
>> taskset 0x1 time sleep 2 & taskset 0x2 time sleep 3
>
> I will use 16,17 instead of 0,1
>> give a correct result without a dmesg log ?
> [root@192.168.8.2 /]$ [root@192.168.8.2 /]$ taskset 65536 time sleep 2 & taskset 131072 time sleep 3
Thanks for providing the numbers.
So there is no weird messages in dmesg ?
> real 0m 2.54s
> user 0m 0.04s
> sys 0m 0.14s
> real 0m 3.47s
> user 0m 0.00s
> sys 0m 0.15s
> [1]+ Done taskset 65536 time sleep 2
>
> Seem OK to me.
I'm not sure of that.
2.54 instead of 2
3.47 instead of 3
0.02 time drift could be acceptable but 0.54 or 0.47 is too much.
And 0.15 in sys also a big number AFAICT.
Is the system in NO_HZ ?
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [PATCH 04/14] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-10 10:43 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161110111506.02842cbd-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Thomas,
On jeu., nov. 10 2016, Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
[...]
>> > A good example of why I'm worried is the sa-sram case:
>> >
>> > + crypto_sram0: sa-sram0@0 {
>> > compatible = "mmio-sram";
>> > reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>> >
>> > + crypto_sram1: sa-sram1@0 {
>> > compatible = "mmio-sram";
>> > reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>> >
>> > The node names should be just "sram" without a number. Indeed for UARTs
>> > for example, you use uart@XYZ, uart@ABC and not uart0@XYZ and
>> > uart1@ABC. But then, if you do that, with your scheme, you end up with
>> > both nodes named sa-sram@0.
>> >
>> > Which clearly shows that the way you set this unit-address is not
>> > correct: those two devices are mapped at completely different
>> > locations, but you end up with an identical unit address.
>> >
>> > I have no idea what is the rule for setting the unit address in this
>> > case, but I'm pretty sure the rule you've chosen is not good.
>>
>> I don't know if there is an existing rules for this case. But I see your
>> concern. What I propose then is to expose the memory windows ID by
>> adding the target and the attributes like this:
>>
>> crypto_sram0: sa-sram@09_09_0 {
>> compatible = "mmio-sram";
>> reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
>>
>>
>> crypto_sram1: sa-sram@09_05_0 {
>> compatible = "mmio-sram";
>> reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
>
> I have no idea if 09_05_0 is considered a valid unit address. Indeed
> the _ character in an address looks a bit weird.
>
> I guess we need guidance from the DT binding maintainers on this, since
> it's really a matter of interpreting what "unit address" means in
> relation to the value of the "reg" property.
So I looked for in the reference: Power_ePAPR_APPROVED_v1.0, and in
paragraph "2.2.1.1 Node Name Requirements" we have:
"The unit-address component of the name is specific to the bus type on
which the node sits. It consists of one or more ASCII characters from
the set of characters in Table 2-1. The fundamental requirement is that
at any level of the device tree the unit-address be unique in order to
differentiate nodes with the same name at the same level in the
tree. The binding for a particular bus may specify additional, more
specific requirements for the format of a unit-address."
In Table 2-1 we have the following characters:
0-9
a-z
A-z
,
.
_
+
-
So the underscore is valid. And by adding information about the memory
windows we match the fundamental requirement :"at any level of the
device tree the unit-address be unique".
Gregory
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-10 10:56 UTC (permalink / raw)
To: Ulf Hansson
Cc: linuxppc-dev@lists.ozlabs.org, Mark Rutland,
devicetree@vger.kernel.org, Dirk Behme, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Rob Herring, Linux-Renesas,
linux-samsung-soc@vger.kernel.org, Simon Horman, Yangbo Lu,
Pankaj Dubey, linux-arm-kernel@lists.infradead.org, Arnd Bergmann
In-Reply-To: <CAMuHMdWox5ksj1xhJ6_n0wNA9j6veX0AzAE0V9Gs26Kvw5C_sw@mail.gmail.com>
On Thu, Nov 10, 2016 at 10:22 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
Tested by kbuild test robot:
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
soc-device-match
da65a1589dacc7ec44ea0557a14d70a39d991f32 base: soc: Provide a
dummy implementation of soc_device_match()
elapsed time: 101m
configs tested: 85
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus
From: Ulf Hansson @ 2016-11-10 10:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@lists.ozlabs.org, Mark Rutland,
devicetree@vger.kernel.org, Dirk Behme, Greg Kroah-Hartman,
linux-kernel@vger.kernel.org, Rob Herring, Linux-Renesas,
linux-samsung-soc@vger.kernel.org, Simon Horman, Yangbo Lu,
Pankaj Dubey, linux-arm-kernel@lists.infradead.org, Arnd Bergmann
In-Reply-To: <CAMuHMdWox5ksj1xhJ6_n0wNA9j6veX0AzAE0V9Gs26Kvw5C_sw@mail.gmail.com>
On 10 November 2016 at 10:22, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Ulf,
>
> On Wed, Nov 9, 2016 at 10:12 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wednesday, November 9, 2016 6:19:06 PM CET Geert Uytterhoeven wrote:
>>> On Wed, Nov 9, 2016 at 5:56 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>> > On Wednesday, November 9, 2016 2:34:33 PM CET Geert Uytterhoeven wrote:
>>> >> > And Samsung.
>>> >> > Shall I create the immutable branch now?
>>> >>
>>> >> Arnd: are you happy with the new patches and changes?
>>> >
>>> > I still had some comments for patch 7, but that shouldn't stop
>>> > you from creating a branch for the first three so everyone can
>>> > build on top of that.
>>>
>>> Thanks!
>>>
>>> What about patch [4/7]?
>>> Haven't you received it? Your address was in the To-line for all 7 patches.
>>
>> Ok, I see it now, looks good. That should be included as well then.
>
> Thanks, I've created the branch/tag :
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> branch soc-device-match
> signed tag soc-device-match-tag1
>
> In the mean time, Ulf has applied the first two patches to mmc/next, on top
> of lots of MMC work :-(
No worries! :-)
>
> Ulf, as this is not only a dependency for Freescale/NXP (for sdhci-of-esdhc),
> but also for Samsung and Renesas, would it still be possible to replace these
> two commits
>
> 8b82c17a8ae533d6 base: soc: introduce soc_device_match() interface
> 6fa350172b098f0f base: soc: Check for NULL SoC device attributes
>
> by a merge of soc-device-match-tag1?
Yes, I will take care of it during the day.
Kind regards
Uffe
^ permalink raw reply
* Re: [PATCH v16 0/5] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2016-11-10 11:15 UTC (permalink / raw)
To: Rob Herring, Jassi Brar, Matthias Brugger
Cc: Daniel Kurtz, Sascha Hauer, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, Sascha Hauer,
Philipp Zabel, Nicolas Boichat, CK HU, cawa cheng, Bibby Hsieh,
YT Shen, Daoyuan Huang, Damon Chu, Josh-YC Liu, Glory Hung,
Jiaguang Zhang, Dennis-YC Hsieh
In-Reply-To: <1477999698-6288-1-git-send-email-hs.liao-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Tue, 2016-11-01 at 19:28 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.9-rc1.
>
> Changes since v15:
> - separate "suspend and resume" patch from "save energy" patch
> - don't stop running tasks in cmdq_suspend()
> (i.e. leave no running tasks guarantee to clients)
>
> Best regards,
> HS Liao
>
> HS Liao (5):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> CMDQ: Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> CMDQ: suspend and resume
> CMDQ: save energy
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 ++
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq-mailbox.c | 632 +++++++++++++++++++++
> drivers/soc/mediatek/Kconfig | 11 +
> drivers/soc/mediatek/Makefile | 1 +
> drivers/soc/mediatek/mtk-cmdq-helper.c | 310 ++++++++++
> include/linux/mailbox/mtk-cmdq-mailbox.h | 67 +++
> include/linux/soc/mediatek/mtk-cmdq.h | 182 ++++++
> 10 files changed, 1268 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq-mailbox.c
> create mode 100644 drivers/soc/mediatek/mtk-cmdq-helper.c
> create mode 100644 include/linux/mailbox/mtk-cmdq-mailbox.h
> create mode 100644 include/linux/soc/mediatek/mtk-cmdq.h
>
Hi Jassi, Matthias,
Sorry to disturb you.
Do you have any further comment on CMDQ v16?
Thanks.
HS
--
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 V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: Mark Rutland @ 2016-11-10 11:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: zhichang.yuan, catalin.marinas, will.deacon, robh+dt, bhelgaas,
olof, arnd, linux-arm-kernel, lorenzo.pieralisi, linux-kernel,
linuxarm, devicetree, linux-pci, linux-serial, minyard,
liviu.dudau, zourongrong, john.garry, gabriele.paoloni,
zhichang.yuan02, kantyzc, xuwei5, marc.zyngier
In-Reply-To: <1478647002.7430.69.camel@kernel.crashing.org>
On Wed, Nov 09, 2016 at 10:16:42AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
> > On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
> > >
> > > For arm64, there is no I/O space as other architectural platforms, such as
> > > X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
> > > such as Hip06, when accessing some legacy ISA devices connected to LPC, those
> > > known port addresses are used to control the corresponding target devices, for
> > > example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
> > > normal MMIO mode in using.
> >
> > This has nothing to do with arm64. Hardware with this kind of indirect
> > bus access could be integrated with a variety of CPU architectures. It
> > simply hasn't been, yet.
>
> On some ppc's we also use similar indirect access methods for IOs. We
> have a generic infrastructure for re-routing some memory or IO regions
> to hooks.
>
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
Just to check, do you hook that in your inb/outb/etc?
Generally, it would seem nicer if we could have higher-level
isa_{inb,outb,whatever} accessors that we could hook separately from
other IO.
We don't necessarily have to move all ISA drivers over to that if we had
a separate symbol for that interface.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-11-10 11:37 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdX+T=Y--F6KXZwFmZwWFdfP5mL5Tar-wKwRM2p6Hh2-sg@mail.gmail.com>
On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> Hi Arnd,
>
> Thanks for your comments!
>
> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> v2:
> >> - Drop SoC families and family names; use fixed "Renesas" instead,
> >
> > I think I'd rather have seen the family names left in there, but it's
> > not important, so up to you.
>
> They're not useful for matching, as family names may change anytime, and don't
> always say much about the hardware capabilities.
> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
> SuperH.
>
> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
I think the marketing names are much more useful for humans looking
at the sysfs files than the kernel doing matching on, but both use
cases are important.
> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> available, else fall back to hardcoded addresses for compatibility
> >> with existing DTBs,
> >
> > I only see patches 2, 3, 5, and 7 in my inbox, so I'm lacking the DT
> > binding for these, among other things.
>
> I understand you've received them in the mean time?
Yes, I found them in my inbox later, not sure why I didn't see them
at first.
> > It does seem wrong to have a device node for a specific register though.
> > Shouldn't the node be for the block of registers that these are inside
> > of?
>
> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
It just seems odd to have it at address 0xff000044 when all the other
devices are at page-aligned addresses. Do you mean that accessing
0xff000040 or 0xff000048 will result in a bus-level exception for a
missing register and just 0xff000044 is actually valid for access,
or is it just the only thing that is documented?
> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> we further don't touch at all.
> On R-Car Gen2, it's not documented, but does exist.
This is where the family names would come in handy ;-) I now have
no idea which chip(s) you are referring to.
If you know the name of the register block, just put it into DT with
that name. The driver can trivially add the right offset.
> >> - Don't register the SoC bus if the chip ID register is missing,
> >
> > Why? My objection was to hardcoding the register, not to registering
> > the device? I think I'd rather see the device registered with an
> > empty revision string.
>
> If there's no chip ID register, there's no reason to use soc_device_match(),
> as we can always look at a compatible value. All SoCs listed in this driver
> have a chip ID register.
But you may still have user space tools looking into sysfs, e.g. to
figure out how to install a kernel that the boot loader can find,
or which hardware specific distro packages to install.
> if you want me to register the soc_bus for those SoCs regardless, I want to
> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
> registers ;-)
Right. Just don't encode too much knowledge about the SoCs into the
driver, so we are prepared for adding new ones: We should still look
for the registers in DT on all chips.
> >> +#define CCCR 0xe600101c /* Common Chip Code Register */
> >> +#define PRR 0xff000044 /* Product Register */
> >> +#define PRR3 0xfff00044 /* Product Register on R-Car Gen3 */
> >> +
> >> +static const struct of_device_id renesas_socs[] __initconst = {
> >> +#ifdef CONFIG_ARCH_R8A73A4
> >> + { .compatible = "renesas,r8a73a4", .data = (void *)PRR, },
> >> +#endif
> >> +#ifdef CONFIG_ARCH_R8A7740
> >> + { .compatible = "renesas,r8a7740", .data = (void *)CCCR, },
> >> +#endif
> >
> > My preference here would be to list the register address only for
> > SoCs that are known to need them, while also having .dtb files that
> > don't have the nodes.
>
> Even if drivers don't have to handle differences, there's been a long
> outstanding request to print SoC revision information during bootup
> (E.g. "Does it still work on ES1.0?"). Hence that covers all SoCs.
Ok, fair enough.
> >> +static int __init renesas_soc_init(void)
> >> +{
> >> + struct soc_device_attribute *soc_dev_attr;
> >> + const struct of_device_id *match;
> >> + void __iomem *chipid = NULL;
> >> + struct soc_device *soc_dev;
> >> + struct device_node *np;
> >> + unsigned int product;
> >> +
> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
> >> + if (!np)
> >> + return -ENODEV;
> >> +
> >> + of_node_put(np);
> >> +
> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
> >> + if (!np)
> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
> >> + if (np) {
> >> + chipid = of_iomap(np, 0);
> >> + of_node_put(np);
> >> + } else if (match->data) {
> >> + chipid = ioremap((uintptr_t)match->data, 4);
> >> + }
> >> + if (!chipid)
> >>
> >
> > Here, I'd turn the order around and look for the DT nodes of the
> > devices first. Only if they are not found, look at the compatible
> > string of the root node. No need to search for a node though,
> > you know which one it is when you look for a compatible =
> > "renesas,r8a73a4".
>
> "renesas,r8a73a4" is the root node, not the device, so it does not have the
> "reg" property for reading the chip ID?
I mean replace of_find_matching_node_and_match() with
of_match_node(renesas_socs, of_root).
It does the same thing, just more efficiently.
> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> Hence I always need to look at the root nodes.
Not sure what that would protect you from. Could you have a renesas,cccr
Arnd
^ permalink raw reply
* Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
From: Ziji Hu @ 2016-11-10 11:44 UTC (permalink / raw)
To: Rob Herring, Gregory CLEMENT
Cc: Hilbert Zhang, Andrew Lunn, Ulf Hansson, Romain Perier,
Liuliu Zhao, Peng Zhu, linux-kernel, Nadav Haklai, Jack(SH) Zhu,
Victor Gu, Doug Jones, Jisheng Zhang, Yehuda Yitschak,
Marcin Wojtas, Xueping Liu, Shiwu Zhang, Yu Cao,
Sebastian Hesselbarth, devicetree, Jason Cooper, Hanna Hawa,
Kostya Porotchkin, Ryan Gao, Wei(SOCP) Liu, linux-arm-kernel
In-Reply-To: <20161109182426.vfrpb4i2mfatdzz3@rob-hp-laptop>
Hi Rob,
On 2016/11/10 2:24, Rob Herring wrote:
> On Mon, Oct 31, 2016 at 12:09:54PM +0100, Gregory CLEMENT wrote:
>> From: Ziji Hu <huziji@marvell.com>
>>
>> Marvell Xenon SDHC can support eMMC/SD/SDIO.
>> Add Xenon-specific properties.
>> Also add properties for Xenon PHY setting.
>>
>> Signed-off-by: Hu Ziji <huziji@marvell.com>
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
>> ---
>> Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 161 +++++++-
>> MAINTAINERS | 1 +-
>> 2 files changed, 162 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>> new file mode 100644
>> index 000000000000..0d2d139494d3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>> @@ -0,0 +1,161 @@
>> +Marvell's Xenon SDHCI Controller device tree bindings
>> +This file documents differences between the core mmc properties
>> +described by mmc.txt and the properties used by the Xenon implementation.
>> +
>> +A single Xenon IP can support multiple slots.
>> +Each slot acts as an independent SDHC. It owns independent resources, such
>> +as register sets clock and PHY.
>> +Each slot should have an independent device tree node.
>> +
>> +Required Properties:
>> +- compatible: should be one of the following
>> + - "marvell,armada-3700-sdhci": For controllers on Armada-3700 SOC.
>> + Must provide a second register area and marvell,pad-type.
>> + - "marvell,xenon-sdhci": For controllers on all the SOCs, other than
>> + Armada-3700.
>
> Need SoC specific compatible strings.
>
Xenon SDHC is a common IP for all Marvell SOCs.
It is difficult to use a single SOC specific compatible to represent Xenon SDHC.
There will be so many SOC compatible strings in list if each specific SOC owns a compatible.
Actually only few SOCs require special properties.
Any suggestion please?
>> +
>> +- clocks:
>> + Array of clocks required for SDHCI.
>> + Requires at least one for Xenon IP core.
>> + Some SOCs require additional clock for AXI bus.
>> +
>> +- clock-names:
>> + Array of names corresponding to clocks property.
>> + The input clock for Xenon IP core should be named as "core".
>> + The optional AXI clock should be named as "axi".
>
> When is AXI clock optional? This should be required for ?? compatible
> strings.
>
It is required on some SOCs.
I will double check if a suitable compatible string can be determined for those SOCs.
>> +
>> +- reg:
>> + * For "marvell,xenon-sdhci", one register area for Xenon IP.
>> +
>> + * For "marvell,armada-3700-sdhci", two register areas.
>> + The first one for Xenon IP register. The second one for the Armada 3700 SOC
>> + PHY PAD Voltage Control register.
>> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
>> + in below.
>> + Please also check property marvell,pad-type in below.
>> +
>> +Optional Properties:
>> +- marvell,xenon-slotno:
>
> Multiple slots should be represented as child nodes IMO. I think some
> other bindings already do this.
>
All the slots are entirely independent.
I prefer to consider it as multiple independent SDHCs placed in a single IP, instead of that a IP contains multiple child slots.
It is unlike the implementation which put multiple slots behind PCIe EP interface. sdhci-pci.c will handle each slot init one by one.
If Xenon SDHC slots are represented as child nodes, there should also be a main entry in Xenon driver to init each child node one by one.
In my very own opinion, it is inconvenient and unnecessary.
>> + Indicate the corresponding bit index of current Xenon SDHC slot in
>> + SDHC System Operation Control Register Bit[7:0].
>> + Set/clear the corresponding bit to enable/disable current Xenon SDHC
>> + slot.
>> + If this property is not provided, Xenon IP should contain only one
>> + slot.
>> +
>> +- marvell,xenon-phy-type:
>> + Xenon support mutilple types of PHYs.
>> + To select eMMC 5.1 PHY, set:
>> + marvell,xenon-phy-type = "emmc 5.1 phy"
>> + eMMC 5.1 PHY is the default choice if this property is not provided.
>> + To select eMMC 5.0 PHY, set:
>> + marvell,xenon-phy-type = "emmc 5.0 phy"
>> + To select SDH PHY, set:
>> + marvell,xenon-phy-type = "sdh phy"
>> + Please note that eMMC PHY is a general PHY for eMMC/SD/SDIO, other than for
>> + eMMC only.
>
> Does this vary per instance on a single SoC? If not, then an SoC
> specific compatible should determine this.
>
> Also, the " phy" part is redundant.
>
Yes. Some SOCs might have multiple Xenon PHY types.
This property is only the name/type of PHY. It doesn't stand for the entire SDHC property.
"emmc 5.1 PHY" doesn't mean that this Xenon SDHC only support eMMC 5.1.
Xenon SDHC with "sdh PHY" can also support eMMC.
>> +
>> +- marvell,xenon-phy-znr:
>> + Set PHY ZNR value.
>> + Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
>> + valid range = [0:0x1F].
>> + ZNR is set as 0xF by default if this property is not provided.
>> +
>> +- marvell,xenon-phy-zpr:
>> + Set PHY ZPR value.
>> + Only available for eMMC PHY 5.1 and eMMC PHY 5.0.
>> + valid range = [0:0x1F].
>> + ZPR is set as 0xF by default if this property is not provided.
>> +
>> +- marvell,xenon-phy-nr-success-tun:
>> + Set the number of required consecutive successful sampling points used to
>> + identify a valid sampling window, in tuning process.
>> + Valid range = [1:7]. Set as 0x4 by default if this property is not provided.
>> +
>> +- marvell,xenon-phy-tun-step-divider:
>> + Set the divider for calculating TUN_STEP.
>> + Set as 64 by default if this property is not provided.
>> +
>> +- marvell,xenon-phy-slow-mode:
>> + Force PHY into slow mode.
>> + Only available when bus frequency lower than 50MHz in SDR mde.
>> + Disabled by default. Please do not enable it unless it is necessary.
>> +
>> +- marvell,xenon-mask-conflict-err:
>> + Mask Conflict Error alert on some SOC. Disabled by default.
>> +
>> +- marvell,xenon-tun-count:
>> + Xenon SDHC SOC usually doesn't provide re-tuning counter in
>> + Capabilities Register 3 Bit[11:8].
>> + This property provides the re-tuning counter.
>> + If this property is not set, default re-tuning counter will
>> + be set as 0x9 in driver.
>> +
>> +- marvell,pad-type:
>> + Type of Armada 3700 SOC PHY PAD Voltiage Controller register.
>> + Only valid when "marvell,armada-3700-sdhci" is selected.
>> + Two types: "sd" and "fixed-1-8v".
>> + If "sd" is slected, SOC PHY PAD is set as 3.3V at the beginning and is
>> + switched to 1.8V when SD in UHS-I.
>> + If "fixed-1-8v" is slected, SOC PHY PAD is fixed 1.8V, such as for eMMC.
>> + Please follow the examples with compatible "marvell,armada-3700-sdhci"
>> + in below.
>> +
>> +Example:
>> +- For eMMC slot:
>> +
>> + sdhci@aa0000 {
>> + compatible = "marvell,xenon-sdhci";
>> + reg = <0xaa0000 0x1000>;
>> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
>> + clocks = <&emmc_clk>, <&axi_clock>;
>> + clock-names = "core", "axi";
>> + bus-width = <8>;
>> + marvell,xenon-emmc;
>
> Not documented. If we need to specify the type of slot/card, then we
> need to come up with a standard property. This was either already done
> or attempted IIRC.
Sorry to lost this property in above.
I will add it in above.
Thank you.
Best regards,
Hu Ziji
>
>> + marvell,xenon-slotno = <0>;
>> + marvell,xenon-phy-type = "emmc 5.1 phy";
>> + marvell,xenon-tun-count = <11>;
>> + };
>> +
>> +- For SD/SDIO slot:
>> +
>> + sdhci@ab0000 {
>> + compatible = "marvell,xenon-sdhci";
>> + reg = <0xab0000 0x1000>;
>> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
>> + vqmmc-supply = <&sd_regulator>;
>> + clocks = <&sdclk>;
>> + clock-names = "core";
>> + bus-width = <4>;
>> + marvell,xenon-tun-count = <9>;
>> + };
>> +
>> +- For eMMC slot with compatible "marvell,armada-3700-sdhci":
>> +
>> + sdhci@aa0000 {
>> + compatible = "marvell,armada-3700-sdhci";
>> + reg = <0xaa0000 0x1000>,
>> + <phy_addr 0x4>;
>> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>
>> + clocks = <&emmcclk>;
>> + clock-names = "core";
>> + bus-width = <8>;
>> + marvell,xenon-emmc;
>> +
>> + marvell,pad-type = "fixed-1-8v";
>> + };
>> +
>> +- For SD/SDIO slot with compatible "marvell,armada-3700-sdhci":
>> +
>> + sdhci@ab0000 {
>> + compatible = "marvell,armada-3700-sdhci";
>> + reg = <0xab0000 0x1000>,
>> + <phy_addr 0x4>;
>> + interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>
>> + vqmmc-supply = <&sd_regulator>;
>> + clocks = <&sdclk>;
>> + clock-names = "core";
>> + bus-width = <4>;
>> +
>> + marvell,pad-type = "sd";
>> + };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 1a5c4c30ea24..850a0afb0c8d 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -7608,6 +7608,7 @@ MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
>> M: Ziji Hu <huziji@marvell.com>
>> L: linux-mmc@vger.kernel.org
>> S: Supported
>> +F: Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
>>
>> MATROX FRAMEBUFFER DRIVER
>> L: linux-fbdev@vger.kernel.org
>> --
>> git-series 0.8.10
^ permalink raw reply
* [PATCH] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Sanchayan Maity @ 2016-11-10 11:45 UTC (permalink / raw)
To: shawnguo
Cc: stefan, linux-arm-kernel, devicetree, linux-kernel,
Sanchayan Maity
Enable DMA for DSPI2 and DSPI3 on Vybrid.
---
arch/arm/boot/dts/vfxxx.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 000550f..e9d2847 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -573,6 +573,9 @@
clocks = <&clks VF610_CLK_DSPI2>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 10>,
+ <&edma1 0 11>;
+ dma-names = "rx", "tx";
status = "disabled";
};
@@ -585,6 +588,9 @@
clocks = <&clks VF610_CLK_DSPI3>;
clock-names = "dspi";
spi-num-chipselects = <2>;
+ dmas = <&edma1 0 12>,
+ <&edma1 0 13>;
+ dma-names = "rx", "tx";
status = "disabled";
};
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v3 00/10] Add DT support for ohci-da8xx
From: Greg KH @ 2016-11-10 12:02 UTC (permalink / raw)
To: Axel Haslam
Cc: Alan Stern, Sekhar Nori, Kevin Hilman, David Lechner, robh+dt,
devicetree, linux-usb, linux-kernel, linux-arm-kernel
In-Reply-To: <CAKXjFTN04Wz5jsaHsyvDD7G8QqXQvCE4D-YbHtGT=jUqELiS_w@mail.gmail.com>
On Tue, Nov 08, 2016 at 05:37:41PM +0100, Axel Haslam wrote:
> Hi,
>
> On Mon, Nov 7, 2016 at 9:39 PM, Axel Haslam <ahaslam@baylibre.com> wrote:
> > The purpose of this patch series is to add DT support for the davinci
> > ohci driver.
> >
>
> To make it easier to review. I will split the arch/arm and driver
> patches into separate series.
I don't think it's easier, as now I have no idea what order, or what
tree it should go through :(
I'm guessing not mine, so all are now deleted from my patch queue...
greg k-h
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-10 12:11 UTC (permalink / raw)
To: Joel Holdsworth, Moritz Fischer
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Clifford Wolf
In-Reply-To: <d3af549a-0f68-7511-ad38-b9ec8aab62ca-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 11/09/2016 07:54 PM, Joel Holdsworth wrote:
> On 09/11/16 11:39, Marek Vasut wrote:
>> On 11/09/2016 07:37 PM, Joel Holdsworth wrote:
>>> On 09/11/16 05:01, Marek Vasut wrote:
>>>> On 11/08/2016 06:30 PM, Joel Holdsworth wrote:
>>>>>>>> On the whole, I don't think the zero-length transfers are too
>>>>>>>> egregiously bad, and all the alternatives seem worse to me.
>>>>>>>
>>>>>>> So why not turn the CS line into GPIO and just toggle the GPIO?
>>>>>>
>>>>>> Does that work with *all* SPI controllers?
>>>>>>
>>>>>
>>>>> It does not - no. See my other email.
>>>>
>>>> And is that line an actual CS of that lattice chip or a generic input
>>>> which almost works like CS?
>>>>
>>>
>>> I mean a generic output vs. a special CS output built into the SPI
>>> master of the application processor. Take a look at how spi_set_cs(..)
>>> works:
>>
>> No. I am asking whether the signal which is INPUT on the iCE40 side is
>> really a chipselect signal for the SPI bus OR something which mostly
>> behaves/looks like a chipselect but is not really a chipselect.
>
> Oh I see. The SS_B line is the SPI SlaveSelect for the configuration port.
>
> This is the text from the datasheet:
>
> "SPI Slave Select. Active Low. Includes an internal weak pull-up
> resistor to VCC_SPI during configuration. During configuration, the
> logic level sampled on this pin deter-mines the configuration mode used
> by the iCE40 device. An input when sampled at the start of
> configuration. An input when in SPI Peripheral configuration mode
> (SPI_SS_B = Low). An output when in Master SPI Flash configuration mode."
>
> So yes - it is a "real" SPI chip-select line.
OK, thanks for checking.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-10 12:15 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen
In-Reply-To: <ad052b0f-0ece-4241-3e06-87905a9cf2c7@ti.com>
Hi Jyri,
On Thursday 10 Nov 2016 11:16:53 Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
> > On Wednesday 02 Nov 2016 18:32:16 Jyri Sarha wrote:
> >> Add very basic ti-ftp410 HDMI transmitter driver. The only feature
> >> separating this from a completely dummy bridge is the DDC i2c
> >> support. However, other HW specific features may be added later when
> >> needed. For instance there is a set of registers behind i2c if it is
> >> connected. The implementations is tested against my new tilcdc bridge
> >> support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
> >> document is also added.
> >>
> >> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> >> ---
> >>
> >> .../bindings/display/bridge/ti,tfp410.txt | 30 ++++
> >> drivers/gpu/drm/bridge/Kconfig | 7 +
> >> drivers/gpu/drm/bridge/Makefile | 1 +
> >> drivers/gpu/drm/bridge/ti-tfp410.c | 199 +++++++++++++++
> >> 4 files changed, 237 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file
> >> mode 100644
> >> index 0000000..dc93713
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> >> @@ -0,0 +1,30 @@
> >> +TFP410 HDMI/DVI bridge bindings
> >
> > I'd name the document "TI TFP410 DVI Transmitter". DVI bridge doesn't tell
> > whether the device is a receiver or transmitter.
> >
> >> +Required properties:
> >> + - compatible: "ti,tfp410"
> >
> > The device is an I2C slave, it should have a reg property. Given that the
> > chip can be used without being controlled through I2C, the reg property
> > should be optional. You should document this clearly, and explain how the
> > DT node can be instantiated as a child of an I2C controller when the I2C
> > interface is used, or in other parts of the device tree otherwise.
> >
> >> +Optional properties:
> >> + - ddc-i2c: phandle of an I2C controller used for DDC EDID probing
> >
> > The TFP410 doesn't handle DDC, this property should be part of the
> > connector node.
> >
> >> +Optional subnodes:
> >> + - video input: this subnode can contain a video input port node
> >> + to connect the bridge to a display controller output (See this
> >> + documentation [1]).
> >
> > You also need an output port for the DVI output. Those two ports should be
> > required, not optional.
>
> Ok. So I need another device node. Should I create some specific
> compatible string for connectors behind tfp410, or a generic DVI/HDMI
> connector with optional ddc-i2c phandle?
The generic DVI/HDMI connector bindings should work fine.
> The implementation side is not so critical, because it more easily
> changed, but should I create an independent generic platform-device
> driver for such DVI/HDMI connector or just implement the connector side
> within tfp410 driver?
Longer term I'd like to go for connector drivers, but it might take a bit of
infrastructure work. If you can give it a try it would be great ! Otherwise
I'm fine with handling that in the tfp410 driver for now.
> >> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> >> +
> >> +Example:
> >> + hdmi-bridge {
> >> + compatible = "ti,tfp410";
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port@0 {
> >> + reg = <0>;
> >> + bridge_in: endpoint {
> >> + remote-endpoint = <&dc_out>;
> >> + };
> >> + };
> >> + };
> >> + };
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Tomi Valkeinen @ 2016-11-10 12:16 UTC (permalink / raw)
To: Jyri Sarha, Laurent Pinchart
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski
In-Reply-To: <ad052b0f-0ece-4241-3e06-87905a9cf2c7@ti.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 3032 bytes --]
On 10/11/16 11:16, Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
>> Hi Jyri,
>>
>> Thank you for the patch.
>>
>> On Wednesday 02 Nov 2016 18:32:16 Jyri Sarha wrote:
>>> Add very basic ti-ftp410 HDMI transmitter driver. The only feature
>>> separating this from a completely dummy bridge is the DDC i2c
>>> support. However, other HW specific features may be added later when
>>> needed. For instance there is a set of registers behind i2c if it is
>>> connected. The implementations is tested against my new tilcdc bridge
>>> support and works with BeagleBone DVI-D Cape Rev A3. A DT binding
>>> document is also added.
>>>
>>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>>> ---
>>> .../bindings/display/bridge/ti,tfp410.txt | 30 ++++
>>> drivers/gpu/drm/bridge/Kconfig | 7 +
>>> drivers/gpu/drm/bridge/Makefile | 1 +
>>> drivers/gpu/drm/bridge/ti-tfp410.c | 199 ++++++++++++++++++
>>> 4 files changed, 237 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt create mode
>>> 100644 drivers/gpu/drm/bridge/ti-tfp410.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>>> b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt new file
>>> mode 100644
>>> index 0000000..dc93713
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
>>> @@ -0,0 +1,30 @@
>>> +TFP410 HDMI/DVI bridge bindings
>>
>> I'd name the document "TI TFP410 DVI Transmitter". DVI bridge doesn't tell
>> whether the device is a receiver or transmitter.
>>
>>> +Required properties:
>>> + - compatible: "ti,tfp410"
>>
>> The device is an I2C slave, it should have a reg property. Given that the chip
>> can be used without being controlled through I2C, the reg property should be
>> optional. You should document this clearly, and explain how the DT node can be
>> instantiated as a child of an I2C controller when the I2C interface is used,
>> or in other parts of the device tree otherwise.
>>
>>> +Optional properties:
>>> + - ddc-i2c: phandle of an I2C controller used for DDC EDID probing
>>
>> The TFP410 doesn't handle DDC, this property should be part of the connector
>> node.
>>
>>> +Optional subnodes:
>>> + - video input: this subnode can contain a video input port node
>>> + to connect the bridge to a display controller output (See this
>>> + documentation [1]).
>>
>> You also need an output port for the DVI output. Those two ports should be
>> required, not optional.
>>
>
> Ok. So I need another device node. Should I create some specific
> compatible string for connectors behind tfp410, or a generic DVI/HDMI
> connector with optional ddc-i2c phandle?
omapdrm uses connector nodes. See, for example, pandaboard's dts files.
It has TFP410 and a connector node. With omap specific drivers, for now,
but that's another matter.
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: zhichang.yuan @ 2016-11-10 12:36 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, Gabriele Paoloni, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org,
kantyzc@163.com, linux-serial@vger.kernel.org, catalin.mar
In-Reply-To: <17821285.aIcTyCGn5n@wuerfel>
Hi, Arnd,
On 2016/11/10 17:12, Arnd Bergmann wrote:
> On Thursday, November 10, 2016 2:40:26 PM CET zhichang.yuan wrote:
>> On 2016/11/10 5:34, Arnd Bergmann wrote:
>>> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
>>>>> On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
>>>>>> + /*
>>>>>> + * The first PCIBIOS_MIN_IO is reserved specifically for
>>>>> indirectIO.
>>>>>> + * It will separate indirectIO range from pci host bridge to
>>>>>> + * avoid the possible PIO conflict.
>>>>>> + * Set the indirectIO range directly here.
>>>>>> + */
>>>>>> + lpcdev->io_ops.start = 0;
>>>>>> + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
>>>>>> + lpcdev->io_ops.devpara = lpcdev;
>>>>>> + lpcdev->io_ops.pfin = hisilpc_comm_in;
>>>>>> + lpcdev->io_ops.pfout = hisilpc_comm_out;
>>>>>> + lpcdev->io_ops.pfins = hisilpc_comm_ins;
>>>>>> + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
>>>>>
>>>>> I have to look at patch 2 in more detail again, after missing a few
>>>>> review
>>>>> rounds. I'm still a bit skeptical about hardcoding a logical I/O port
>>>>> range here, and would hope that we can just go through the same
>>>>> assignment of logical port ranges that we have for PCI buses,
>>>>> decoupling
>>>>> the bus addresses from the linux-internal ones.
>>>>
>>>> The point here is that we want to avoid any conflict/overlap between
>>>> the LPC I/O space and the PCI I/O space. With the assignment above
>>>> we make sure that LPC never interfere with PCI I/O space.
>>>
>>> But we already abstract the PCI I/O space using dynamic registration.
>>> There is no need to hardcode the logical address for ISA, though
>>> I think we can hardcode the bus address to start at zero here.
>>
>> Do you means that we can pick up the maximal I/O address from all children's
>> device resources??
>
> The driver should not look at the resources of its children, just
> register a range of addresses dynamically, as I suggested in an
> earlier review.
>
Sorry! I can't catch your idea yet:(
When to register the I/O range? Is it done just after the successfully
of_translate_address() during the children scanning?
If yes, when a child is scanning, there is no range data in arm64_extio_ops. The
addr_is_indirect_io() calling in of_get_isa_indirect_io() don't need. All we can
check is just whether the address to be translated is IO and is under a parent
device which has no 'ranges' property.
>
> Your current version has
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr, value, sizeof(type)); \
>
> Instead, just subtract the start of the range from the logical
> port number to transform it back into a bus-local port number:
>
> if (arm64_extio_ops->pfout) \
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,\
> addr - arm64_extio_ops->start, value, sizeof(type)); \
>
I think there is some information needed sync.
In the old patch-set, we don't bypass the pci_address_to_pio() after
successfully of_translate_address(). In this way, we don't need to reserve any
PIO space for our LPC since the logical port are from the same mapping
algorithm. Based on this way, the port number in the device resource is logical
one, then we need to subtract the start of the resource to get back the
bus-local port.
>From V3, we don't apply the mapping based on pci_address_to_pio(), the
of_translate_address() return the bus-local port directly and store into
relevant device resource. So, in the current arm64_extio_ops->pfout(), the
reverse translation don't need anymore. The input "addr" is bus-local port now.
Thanks,
Zhichang
> We know that the ISA/LPC bus can only have up to 65536 ports,
> so you can register all of those, or possibly limit it further to
> 1024 or 4096 ports, whichever matches the bus implementation.
>
> Arnd
>
> .
>
^ permalink raw reply
* Re: [PATCH v6] clk: renesas: cpg-mssr: add R8A7743 support
From: Geert Uytterhoeven @ 2016-11-10 12:52 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Michael Turquette, linux-clk, Stephen Boyd, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org, Linux-Renesas,
Simon Horman
In-Reply-To: <2376126.1sNxSm4GUB@wasted.cogentembedded.com>
Hi Sergei,
On Tue, Nov 8, 2016 at 10:21 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add RZ/G1M (R8A7743) Clock Pulse Generator / Module Standby and Software
> Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
> (and RZ/G) code.
>
> Based on the proof-of-concept R8A7791 CPG/MSSR patch by Geert Uytterhoeven
> <geert+renesas@glider.be>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> This patch is against the 'clk-next' branch of CLK group's 'linux.git' repo.
> It depends on the common R-Car gen2 (and RZ/G) support just posted.
>
> Changes in version 6:
> - passed the PLL0 divisor to rcar_gen2_cpg_init();
> - undid the version 5 changes.
Thanks!
Will queue with the following trivial changes:
- pass cpg_mode to rcar_gen2_cpg_init(),
- sort clock names in DT bindings,
- reformat tables for easier comparison with other clock drivers.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4] clk: renesas: cpg-mssr: add R8A7745 support
From: Geert Uytterhoeven @ 2016-11-10 12:53 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Michael Turquette, linux-clk, Stephen Boyd, Rob Herring,
Mark Rutland, devicetree@vger.kernel.org, Linux-Renesas,
Simon Horman
In-Reply-To: <4179265.sjm4z2joGl@wasted.cogentembedded.com>
On Tue, Nov 8, 2016 at 10:25 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add RZ/G1E (R8A7745) Clock Pulse Generator / Module Standby and Software
> Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
> (and RZ/G) code.
>
> Based on the proof-of-concept R8A7791 CPG/MSSR patch by Geert Uytterhoeven
> <geert+renesas@glider.be>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> ---
> This patch is against the 'clk-next' branch of CLK group's 'linux.git' repo
> plus the R8A7743 clock driver patch. It depends on the common R-Car gen2 (and
> RZ/G) support just posted.
>
> Changes in version 4:
> - changed the Z2 clock's divisor to 1;
> - passed the PLL0 divisor to rcar_gen2_cpg_init();
> - renamed the ACP clock to CPEX;
> - removed the thermal module clock.
Thanks!
Will queue with the following trivial changes:
- pass cpg_mode to rcar_gen2_cpg_init(),
- sort clock names in DT bindings,
- reformat tables for easier comparison with other clock drivers.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* RE: [PATCH v2 3/3] clocksource: Add clockevent support to NPS400 driver
From: Noam Camus @ 2016-11-10 13:00 UTC (permalink / raw)
To: Daniel Lezcano
Cc: robh+dt@kernel.org, mark.rutland@arm.com, tglx@linutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Vineet Gupta
In-Reply-To: <1850b6f7-3901-1065-5f35-d738f76fb218@linaro.org>
>From: Daniel Lezcano [mailto:daniel.lezcano@linaro.org]
>Sent: Thursday, November 10, 2016 12:34 PM
>>> give a correct result without a dmesg log ?
>> [root@192.168.8.2 /]$ [root@192.168.8.2 /]$ taskset 65536 time sleep 2
>> & taskset 131072 time sleep 3
>Thanks for providing the numbers.
>So there is no weird messages in dmesg ?
Yes, no weird messages, all seem normal.
>> real 0m 2.54s
>> user 0m 0.04s
>> sys 0m 0.14s
>> real 0m 3.47s
>> user 0m 0.00s
>> sys 0m 0.15s
>> [1]+ Done taskset 65536 time sleep 2
>>
>> Seem OK to me.
>I'm not sure of that.
>2.54 instead of 2
>3.47 instead of 3
>0.02 time drift could be acceptable but 0.54 or 0.47 is too much.
>And 0.15 in sys also a big number AFAICT.
>Is the system in NO_HZ ?
We are handling system with NOHZ_FULL
This was run under simulation and result are reasonable (indeed not perfect) AFAICT.
-Noam
^ permalink raw reply
* [RFC] Documentation: media, leds: move IR LED remote controllers from media to LED
From: Andi Shyti @ 2016-11-10 13:26 UTC (permalink / raw)
To: Rob Herring, Jacek Anaszewski, Mauro Carvalho Chehab
Cc: linux-leds, linux-media, devicetree, Andi Shyti
Hi,
this is purely a request for comments after a discussion had with
Rob and Jacek [*] about where to place the ir leds binding. Rob wants
the binding to be under led, while Jacek wants it in media...
"Ubi maior minor cessat": it goes to LED and they can be organized
in a subdirectory.
Standing to Rob "Bindings are grouped by types of h/w and IR LEDs
are a type of LED": all remote controllers have an IR LED as core
device, even though the framework is under drivers/media/rc/, thus
they naturally belong to the LED binding group.
Please, let me know if this is the right approach.
Thanks,
Andi
[*] https://lkml.org/lkml/2016/9/12/380
https://lkml.org/lkml/2016/11/9/622
---
.../devicetree/bindings/{media => leds/ir-leds}/gpio-ir-receiver.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/hix5hd2-ir.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/img-ir-rev1.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/meson-ir.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/nokia,n900-ir | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/st-rc.txt | 0
Documentation/devicetree/bindings/{media => leds/ir-leds}/sunxi-ir.txt | 0
7 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/gpio-ir-receiver.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/hix5hd2-ir.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/img-ir-rev1.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/meson-ir.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/nokia,n900-ir (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/st-rc.txt (100%)
rename Documentation/devicetree/bindings/{media => leds/ir-leds}/sunxi-ir.txt (100%)
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/leds/ir-leds/gpio-ir-receiver.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/gpio-ir-receiver.txt
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/leds/ir-leds/hix5hd2-ir.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/hix5hd2-ir.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt b/Documentation/devicetree/bindings/leds/ir-leds/img-ir-rev1.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/img-ir-rev1.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/img-ir-rev1.txt
diff --git a/Documentation/devicetree/bindings/media/meson-ir.txt b/Documentation/devicetree/bindings/leds/ir-leds/meson-ir.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/meson-ir.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/meson-ir.txt
diff --git a/Documentation/devicetree/bindings/media/nokia,n900-ir b/Documentation/devicetree/bindings/leds/ir-leds/nokia,n900-ir
similarity index 100%
rename from Documentation/devicetree/bindings/media/nokia,n900-ir
rename to Documentation/devicetree/bindings/leds/ir-leds/nokia,n900-ir
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt b/Documentation/devicetree/bindings/leds/ir-leds/st-rc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/st-rc.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/st-rc.txt
diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/leds/ir-leds/sunxi-ir.txt
similarity index 100%
rename from Documentation/devicetree/bindings/media/sunxi-ir.txt
rename to Documentation/devicetree/bindings/leds/ir-leds/sunxi-ir.txt
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/2] devicetree: Add vendor prefix for CZ.NIC
From: Uwe Kleine-König @ 2016-11-10 13:57 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Martin Strbačka, Tomas Hlavacek, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index f0a48ea78659..ae9fce9fed03 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -67,6 +67,7 @@ creative Creative Technology Ltd
crystalfontz Crystalfontz America, Inc.
cubietech Cubietech, Ltd.
cypress Cypress Semiconductor Corporation
+cznic CZ.NIC, z.s.p.o.
dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
delta Delta Electronics, Inc.
--
2.10.2
--
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 v2 2/2] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-10 13:57 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: Martin Strbačka, Tomas Hlavacek, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161110135721.13098-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
This machine is an open hardware router by cz.nic driven by a
Marvell Armada 385.
Signed-off-by: Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
---
Compared to the (implict) v1, the following was changed:
- disable rtc
- change compatible to cznic,turris-omnia
The following components are working:
- WAN port
- eMMC
- UART0
- USB
- mSATA
Wireless fails to probe, didn't debug this up to now.
I already see the DSA devices (with an additional change not included here),
but sending and receiving doesn't work yet.
SFP is missing as I cannot test it. UART1 is untested, but I'd be
surprised if it didn't work.
IMHO it makes sense to add the current state and fix the remaining stuff
incrementally.
Best regards
Uwe
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/armada-385-turris-omnia.dts | 257 ++++++++++++++++++++++++++
2 files changed, 258 insertions(+)
create mode 100644 arch/arm/boot/dts/armada-385-turris-omnia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..f1d3b9ff257e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -920,6 +920,7 @@ dtb-$(CONFIG_MACH_ARMADA_38X) += \
armada-385-db-ap.dtb \
armada-385-linksys-caiman.dtb \
armada-385-linksys-cobra.dtb \
+ armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
armada-388-db.dtb \
armada-388-gp.dtb \
diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
new file mode 100644
index 000000000000..28e45d816120
--- /dev/null
+++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
@@ -0,0 +1,257 @@
+/*
+ * Device Tree file for the Turris Omnia
+ * Schematic available at https://www.turris.cz/doc/_media/rtrom01-schema.pdf
+ *
+ * Copyright (C) 2016 Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include "armada-385.dtsi"
+
+/ {
+ model = "Turris Omnia";
+ compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
+
+ chosen {
+ stdout-path = &uart0;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00000000 0x40000000>; /* 1024 MB */
+ };
+
+ soc {
+ ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
+ MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000>;
+
+ internal-regs {
+
+ /* USB part of the eSATA/USB 2.0 port */
+ usb@58000 {
+ status = "okay";
+ };
+
+ rtc@a3800 {
+ /*
+ * There are several errata for this device
+ * still unimplemented. Without some love it only reports
+ * 2016-12-19 22:00:24. So disable for now.
+ */
+ status = "disabled";
+ };
+
+ sata@a8000 {
+ status = "okay";
+ };
+
+ sdhci@d8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhci_pins>;
+ status = "okay";
+
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ };
+
+ usb3@f0000 {
+ status = "okay";
+ };
+
+ usb3@f8000 {
+ status = "okay";
+ };
+ };
+
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ /* Port 0, Lane 0 */
+ status = "okay";
+ };
+
+ pcie@2,0 {
+ /* Port 2, Lane 0 */
+ status = "okay";
+ };
+
+ pcie@3,0 {
+ /* Port 3, Lane 0 */
+ status = "okay";
+ };
+ };
+ };
+};
+
+ð0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge0_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+ð1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&ge1_rgmii_pins>;
+ status = "okay";
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+};
+
+/* WAN port */
+ð2 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy = <&phy1>;
+};
+
+&i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+
+ i2cmux@70 {
+ compatible = "nxp,pca9547";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x70>;
+ status = "okay";
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+
+ /* STM32F0 at address 0x2a */
+ /* leds device at address 0x2b */
+
+ eeprom@54 {
+ /* holds configuration about RAM, evaluated by bootloader */
+ compatible = "at,24c64";
+ reg = <0x54>;
+ };
+ };
+
+ i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ /* ATSHA204A at address 0x64 */
+ };
+
+ i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ /* exposed on pin header */
+ };
+ };
+};
+
+&mdio {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ status = "okay";
+
+ phy1: phy@1 {
+ status = "okay";
+ compatible = "ethernet-phy-id0141.0DD1", "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+
+ /* There is a Switch (MV88E7176) at address 0x10 */
+};
+
+&pinctrl {
+ spi0cs1_pins: spi0-pins-0cs1 {
+ marvell,pins = "mpp26";
+ marvell,function = "spi0";
+ };
+};
+
+&spi0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_pins &spi0cs1_pins>;
+ status = "okay";
+
+ spi-nor@0 {
+ compatible = "spansion,s25fl164k", "jedec,spi-nor";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0>;
+ spi-max-frequency = <40000000>;
+
+ partition@0 {
+ reg = <0x0 0x00100000>;
+ label = "U-Boot";
+ };
+
+ partition@1 {
+ reg = <0x00100000 0x00700000>;
+ label = "Rescue system";
+ };
+ };
+
+ /* @1 is on pin header */
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+};
--
2.10.2
--
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
* Re: [PATCH v5 6/8] Documentation: bindings: add compatible specific to legacy SCPI protocol
From: Rob Herring @ 2016-11-10 14:12 UTC (permalink / raw)
To: Sudeep Holla
Cc: Neil Armstrong, Olof Johansson,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-amlogic
In-Reply-To: <14e563ae-36c5-4bf9-0d51-3b07830de3db@arm.com>
On Thu, Nov 10, 2016 at 4:26 AM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 10/11/16 01:22, Rob Herring wrote:
>>
>> On Wed, Nov 02, 2016 at 10:52:09PM -0600, Sudeep Holla wrote:
>>>
>>> This patch adds specific compatible to support legacy SCPI protocol.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>> Documentation/devicetree/bindings/arm/arm,scpi.txt | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> index d1882c4540d0..ebd03fc93135 100644
>>> --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
>>> @@ -7,7 +7,9 @@ by Linux to initiate various system control and power
>>> operations.
>>>
>>> Required properties:
>>>
>>> -- compatible : should be "arm,scpi"
>>> +- compatible : should be
>>> + * "arm,scpi" : For implementations complying to SCPI v1.0 or
>>> above
>>> + * "arm,legacy-scpi" : For implementations complying pre SCPI v1.0
>>
>>
>> I'd prefer that we explicitly enumerate the old versions. Are there
>> many?
>>
>
> I understand your concern, but this legacy SCPI protocol was not
> officially released. It was just WIP which vendors picked up from very
> early releases. Since they are not numbered, it's hard to have specific
> compatibles with different versions until v1.0. That's one of the reason
> to retain platform specific compatible so that we can add any quirks
> based on them if needed.
>
> I will probably add these information in the commit log so that it's
> clear why we can't do version based compatible.
This is exactly my point. By enumerate, I meant having platform
specific compatibles. Having "arm,legacy-scpi" is pointless because
who knows what version they followed and they may all be different.
Rob
^ 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