* Re: [PATCH v3 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Thomas Petazzoni @ 2016-11-18 13:35 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Andrew Lunn, Jason Cooper, devicetree, Rob Herring,
linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <8737ipat6u.fsf@free-electrons.com>
Hello,
On Fri, 18 Nov 2016 13:06:17 +0100, Gregory CLEMENT wrote:
> > But do we really want this comment above each node? Couldn't we instead
> > add this explanation in the mvebu-mbus.txt DT binding?
>
> We could but I fear that nobody will read it.
>
> Indeed if you know that in order to understand the unit address, you will
> have to have a look an the binding of the mvebu-mbus, then it means that
> you already are an expert and actually you barely need to read it!
Well, you anyway need to read the DT binding if you want to add more
nodes that use this magic MBUS_ID() thing, so I believe it makes sense
to have this comment in the binding documentation.
> In order to have less change we could at least put it near the MBUS_ID
> macro and if the mvebu-mbus.txt DT binding too.
Fine with that.
Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v3 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Thomas Petazzoni @ 2016-11-18 13:38 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: <877f81b013.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello,
On Fri, 18 Nov 2016 10:38:32 +0100, Gregory CLEMENT wrote:
> >> > unit address? It doesn't have a 'reg' property if I remember
> >> > correctly.
> >>
> >> But it has a range property.
> >
> > And? There are multiple ranges, and you randomly took the first one for
> > the unit address of the soc node?
>
> Not randomly I followed the same rules that for the regs mentioned in
> the ePAPR paragraph 2.2.1.1:
>
> "The unit-address should match the first address specified in the reg
> property of the node."
But it doesn't say anything about the ranges property. Isn't the dtc
warning in fact over-zealous? The ePAPR says that the unit address
should be the first address of the reg property, but doesn't say
anything about the ranges property.
What I dislike is that there absolutely nothing that forces the ranges
to be written in this order. In another board, it can be written in a
completely different order, which means that the unit address would be
different, which is really silly.
I continue to believe this rule doesn't make sense, and the soc node
shouldn't have a unit address. Maybe Rob or Mark (who is not in Cc, for
some reason?) should say a word about this?
Best regards,
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 V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-18 13:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Gabriele Paoloni, mark.rutland@arm.com, benh@kernel.crashing.org,
catalin.marinas@arm.com, liviu.dudau@arm.com, Linuxarm,
lorenzo.pieralisi@arm.com, xuwei (O), Jason Gunthorpe,
linux-serial@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, minyard@acm.org, will.deacon@arm.com,
John Garry, zourongrong@gmail.com
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F921283@lhreml507-mbx>
On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni wrote:
> > > > I think there is no need to change a) here, we have PCIBIOS_MIN_IO
> > > > today and even if we don't need it, there is no obvious downside.
> > > > I would also argue that we can ignore b) for the discussion of
> > > > the HiSilicon LPC driver, we just need to assign some range
> > > > of logical addresses to each domain.
> > > >
> > > > That means solving c) is the important problem here, and it
> > > > shouldn't be so hard. We can do this either with a single
> > > > special domain as in the v5 patch series, or by generalizing it
> > > > so that any I/O space mapping gets looked up through the device
> > > > pointer of the bus master.
> > >
> > > I am not very on the "generalized" multi-domain solution...
> > > Currently the IO accessors prototypes have an unsigned long addr
> > > as input parameter. If we live in a multi-domain IO system
> > > how can we distinguish inside the accessor which domain addr
> > > belongs to?
> >
> > The easiest change compared to the v5 code would be to walk
> > a linked list of 'struct extio_ops' structures rather than
> > assuming there is only ever one of them. I think one of the
> > earlier versions actually did this.
>
> Right but if my understanding is correct if we live in a multi-
> domain I/O space world when you have an input addr in the I/O
> accessors this addr can be duplicated (for example for the standard
> PCI IO domain and for our special LPC domain).
> So effectively even if you walk a linked list there is a problem
> of disambiguation...am I right?
No, unlike the PCI memory space, the PIO addresses are not
usually distinct, i.e. every PCI bus has its own 64K I/O
addresses starting at zero. We linearize them into the
Linux I/O space using the per-domain io_offset value.
For the ISA/LPC spaces there are only 4k of addresses, they
the bus addresses always overlap, but we can trivially
figure out the bus address from Linux I/O port number
by subtracting the start of the range.
> > Another option the IA64 approach mentioned in another subthread
> > today, looking up the operations based on an index from the
> > upper bits of the port number. If we do this, we probably
> > want to do that for all PIO access and replace the entire
> > virtual address remapping logic with that. I think Bjorn
> > in the past argued in favor of such an approach, while I
> > advocated the current scheme for simplicity based on how
> > every I/O space these days is just memory mapped (which now
> > turned out to be false, both on powerpc and arm64).
>
> This seems really complex...I am a bit worried that possibly
> we end up in having the maintainers saying that it is not worth
> to re-invent the world just for this special LPC device...
It would clearly be a rather invasive change, but the
end-result isn't necessarily more complex than what we
have today, as we'd kill off the crazy pci_pio_to_address()
and pci_address_to_pio() hacks in address translation.
> To be honest with you I would keep things simple for this
> LPC and introduce more complex reworks later if more devices
> need to be introduced.
>
> What if we stick on a single domain now where we introduce a
> reserved threshold for the IO space (say INDIRECT_MAX_IO).
I said having a single domain is fine, but I still don't
like the idea of reserving low port numbers for this hack,
it would mean that the numbers change for everyone else.
> We define INDIRECT_MAX_IO as 0 in "include/linux/extio.h" and
> we define INDIRECT_MAX_IO as 0x1000 in "arch/arm64/include/asm/io.h"
>
> So effectively this threshold can change according to the
> architecture and so far we only define it for ARM64 as we need
> it for ARM64...
I liked the idea of having it done in asm-generic/io.h (in an ifdef)
and lib/*.c under an as someone suggested earlier. There is nothing
ARM64 specific in the implementation.
Arnd
^ permalink raw reply
* Re: [RFT] ARM: dts: exynos: Fix invalid GIC interrupt flags in audio block of Exynos5410
From: Sylwester Nawrocki @ 2016-11-18 13:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Kukjin Kim, Javier Martinez Canillas,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <1479473964-9085-1-git-send-email-krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 11/18/2016 01:59 PM, Krzysztof Kozlowski wrote:
> Recently added audio block of Exynos5410 missed global fixup of GIC
> interrupt flags. Interrupt of type IRQ_TYPE_NONE is not allowed for GIC
> interrupts so use level high.
>
> Signed-off-by: Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Tested-by: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
--
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 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2016-11-18 13:48 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Russell King, Rob Herring, Peter Rosin,
linux-arm-kernel
Hi!
After finally having all essintial drivers upstreamed (the
last ones are currently in -next) I would like to have the
dts and the defconfig also upstreamed.
checkpatch complains about missing docs for some compatible
strings:
axentia,tse850v3 (v3 is the hw version that we currently use)
axentia,tse850 (in case we have future versions with commonality)
axentia,linea (the cpu module, reused in other products as well)
nxp,se97b (temp sensor in the below eeprom module)
nxp,24c02 (eeprom on the main board)
st,24c64 (eeprom on the cpu module)
I don't know where I should document those, or if it's even
needed? I get the feeling that the last three are not "my fault".
Anyway, please advice. Or, even better, apply as-is... :-)
Cheers,
Peter
Peter Rosin (2):
ARM: dts: add devicetree for the Axentia TSE-850
ARM: tse850_defconfig: add Axentia TSE-850
MAINTAINERS | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 52 +++++++
arch/arm/boot/dts/axentia-tse850-3.dts | 275 +++++++++++++++++++++++++++++++++
arch/arm/configs/tse850_defconfig | 223 ++++++++++++++++++++++++++
5 files changed, 558 insertions(+)
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
create mode 100644 arch/arm/configs/tse850_defconfig
--
2.1.4
^ permalink raw reply
* [PATCH 1/2] ARM: dts: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2016-11-18 13:48 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479476889-9789-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
MAINTAINERS | 6 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 52 +++++++
arch/arm/boot/dts/axentia-tse850-3.dts | 273 +++++++++++++++++++++++++++++++++
4 files changed, 332 insertions(+)
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 9fe1bc9b414f..7ecf50e5ab47 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2325,6 +2325,12 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/boot/dts/axentia-*
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab-JsYNTwtnfakRB7SZvlqPiA@public.gmane.org>
M: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..02cd9b4c55d3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ axentia-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/axentia-linea.dtsi b/arch/arm/boot/dts/axentia-linea.dtsi
new file mode 100644
index 000000000000..07359f9d7419
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-linea.dtsi
@@ -0,0 +1,52 @@
+/*
+ * axentia-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ * Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&main {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/axentia-tse850-3.dts b/arch/arm/boot/dts/axentia-tse850-3.dts
new file mode 100644
index 000000000000..2052a6f4bb31
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-tse850-3.dts
@@ -0,0 +1,273 @@
+/*
+ * axentia-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ * Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "axentia-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,tse850", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ };
+
+ ahb {
+ apb {
+ pinctrl@fffff200 {
+ board {
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOC 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog@fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ 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 = <&pcm5142>;
+
+ 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>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv@c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2@100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree@180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs@10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42@18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom@50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
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 2/2] ARM: tse850_defconfig: add Axentia TSE-850
From: Peter Rosin @ 2016-11-18 13:48 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479476889-9789-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
MAINTAINERS | 1 +
arch/arm/boot/dts/axentia-tse850-3.dts | 8 +-
arch/arm/configs/tse850_defconfig | 223 +++++++++++++++++++++++++++++++++
3 files changed, 229 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/configs/tse850_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ecf50e5ab47..883d46eb2a06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2330,6 +2330,7 @@ M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/axentia-*
+F: arch/arm/configs/tse850_defconfig
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab-JsYNTwtnfakRB7SZvlqPiA@public.gmane.org>
diff --git a/arch/arm/boot/dts/axentia-tse850-3.dts b/arch/arm/boot/dts/axentia-tse850-3.dts
index 2052a6f4bb31..517381f89c3d 100644
--- a/arch/arm/boot/dts/axentia-tse850-3.dts
+++ b/arch/arm/boot/dts/axentia-tse850-3.dts
@@ -22,10 +22,12 @@
ahb {
apb {
pinctrl@fffff200 {
- board {
- pinctrl_usba_vbus: usba_vbus {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
atmel,pins =
- <AT91_PIOC 31 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>;
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
};
};
};
diff --git a/arch/arm/configs/tse850_defconfig b/arch/arm/configs/tse850_defconfig
new file mode 100644
index 000000000000..f6076e7e1669
--- /dev/null
+++ b/arch/arm/configs/tse850_defconfig
@@ -0,0 +1,223 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_AT91=y
+CONFIG_SOC_SAMA5D3=y
+# CONFIG_CACHE_L2X0 is not set
+CONFIG_AEABI=y
+CONFIG_UACCESS_WITH_MEMCPY=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
+CONFIG_KEXEC=y
+CONFIG_VFP=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPGRE_DEMUX=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_UDP_DIAG=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+CONFIG_IPV6_SIT_6RD=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_SNMP=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_SET_RBTREE=y
+CONFIG_NFT_SET_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_HASH=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_ATMEL_TCLIB=y
+CONFIG_ATMEL_SSC=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+CONFIG_MACB=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_MICREL_PHY=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_LEGACY_PTY_COUNT=4
+CONFIG_SERIAL_ATMEL=y
+CONFIG_SERIAL_ATMEL_CONSOLE=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_AT91=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET=y
+CONFIG_SENSORS_JC42=y
+CONFIG_WATCHDOG=y
+CONFIG_AT91SAM9X_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_PCM_OSS=y
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_USB is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_ATMEL_SOC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
+# CONFIG_HID_GENERIC is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_STORAGE_REALTEK=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_ISD200=y
+CONFIG_USB_STORAGE_USBAT=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_STORAGE_ALAUDA=y
+CONFIG_USB_STORAGE_ONETOUCH=y
+CONFIG_USB_STORAGE_KARMA=y
+CONFIG_USB_STORAGE_CYPRESS_ATACB=y
+CONFIG_USB_STORAGE_ENE_UB6250=y
+CONFIG_USB_UAS=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_ATMEL_USBA=y
+CONFIG_USB_G_SERIAL=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AT91RM9200=y
+CONFIG_DMADEVICES=y
+CONFIG_AT_HDMAC=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_AT91_ADC=y
+CONFIG_ENVELOPE_DETECTOR=y
+CONFIG_DPOT_DAC=y
+CONFIG_MCP4531=y
+CONFIG_PWM=y
+CONFIG_PWM_ATMEL=y
+CONFIG_PWM_ATMEL_TCB=y
+CONFIG_EXT4_FS=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+CONFIG_STRIP_ASM_SYMS=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_SHA1=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEV_ATMEL_AES=y
+CONFIG_CRYPTO_DEV_ATMEL_TDES=y
+CONFIG_CRYPTO_DEV_ATMEL_SHA=y
--
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 v3] usb: dwc2: add amcc,dwc-otg support
From: Rob Herring @ 2016-11-18 13:49 UTC (permalink / raw)
To: John Youn
Cc: Felipe Balbi, Christian Lamparter, linux-kernel, devicetree,
linux-usb, linuxppc-dev, Mark Rutland, Greg Kroah-Hartman
In-Reply-To: <e2d277d12b82ea88e5092058e883f7cdecb5cec3.1479250846.git.johnyoun@synopsys.com>
On Tue, Nov 15, 2016 at 03:03:40PM -0800, John Youn wrote:
> From: Christian Lamparter <chunkeey@googlemail.com>
>
> 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.
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: John Youn <johnyoun@synopsys.com>
> ---
>
> Sorry, the previous one broke compilation. This fixes it.
>
> Regards,
> John
>
> v3 [johnyoun]:
> * Fixed compilation issue
>
> v2 [johnyoun]:
> * Removed params struct
> * Minor commit message formatting
>
> 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 ad8f7ff..6c7c2bce 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 513556a..a786256 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 },
'.data = NULL' is unnecessary.
With that fixed,
Acked-by: Rob Herring <robh@kernel.org>
> {},
> };
> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
> --
> 2.10.0
>
^ permalink raw reply
* Re: [PATCH v8 09/16] mmc: sdhci: Factor out sdhci_enable_clock
From: Adrian Hunter @ 2016-11-18 13:56 UTC (permalink / raw)
To: Ritesh Harjani, ulf.hansson, linux-mmc, sboyd, andy.gross
Cc: shawn.lin, devicetree, linux-clk, david.brown, linux-arm-msm,
georgi.djakov, alex.lemberg, mateusz.nowak, Yuliy.Izrailov,
asutoshd, david.griego, stummala, venkatg, rnayak, pramod.gurav,
jeremymc
In-Reply-To: <1479312052-22396-10-git-send-email-riteshh@codeaurora.org>
On 16/11/16 18:00, Ritesh Harjani wrote:
> Factor out sdhci_enable_clock from sdhci_set_clock
> and make it EXPORT_SYMBOL so that it can be called.
This seems fine apart from minor comments below.
>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> ---
> drivers/mmc/host/sdhci.c | 28 +++++++++++++++++-----------
> drivers/mmc/host/sdhci.h | 1 +
> 2 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index d08d507..8a89d89 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1344,20 +1344,10 @@ u16 sdhci_calc_clk(struct sdhci_host *host, unsigned int clock,
> }
> EXPORT_SYMBOL_GPL(sdhci_calc_clk);
>
> -void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
> +void sdhci_enable_clock(struct sdhci_host *host, unsigned short clk)
We write a u16 so let's make clk a u16 instead of unsigned short.
I would have called it sdhci_enable_clk() to go with sdhci_calc_clk() and
slightly different from sdhci_set_clock() which is a callback whereas the
other 2 are helpers.
> {
> - u16 clk;
> unsigned long timeout;
>
> - host->mmc->actual_clock = 0;
> -
> - sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> -
> - if (clock == 0)
> - return;
> -
> - clk = sdhci_calc_clk(host, clock, &host->mmc->actual_clock);
> -
> clk |= SDHCI_CLOCK_INT_EN;
> sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
>
> @@ -1378,6 +1368,22 @@ void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
> clk |= SDHCI_CLOCK_CARD_EN;
> sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
> }
> +EXPORT_SYMBOL_GPL(sdhci_enable_clock);
> +
> +void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + u16 clk;
> +
> + host->mmc->actual_clock = 0;
> +
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> + if (clock == 0)
> + return;
> +
> + clk = sdhci_calc_clk(host, clock, &host->mmc->actual_clock);
> + sdhci_enable_clock(host, clk);
> +}
> EXPORT_SYMBOL_GPL(sdhci_set_clock);
>
> static void sdhci_set_power_reg(struct sdhci_host *host, unsigned char mode,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 766df17..8e77a3b 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -681,6 +681,7 @@ static inline bool sdhci_sdio_irq_enabled(struct sdhci_host *host)
> u16 sdhci_calc_clk(struct sdhci_host *host, unsigned int clock,
> unsigned int *actual_clock);
> void sdhci_set_clock(struct sdhci_host *host, unsigned int clock);
> +void sdhci_enable_clock(struct sdhci_host *host, unsigned short clk);
> void sdhci_set_power(struct sdhci_host *host, unsigned char mode,
> unsigned short vdd);
> void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode,
>
^ permalink raw reply
* Re: [RFC 4/6] ARM: dts: dra7: add entry for bb2d module
From: Nishanth Menon @ 2016-11-18 13:56 UTC (permalink / raw)
To: Lucas Stach, Robert Nelson
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gowtham Tammana, Tomi Valkeinen, Tero Kristo
In-Reply-To: <1479466741.20533.5.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 11/18/2016 04:59 AM, Lucas Stach wrote:
> Am Donnerstag, den 17.11.2016, 20:44 -0600 schrieb Robert Nelson:
>> From: Gowtham Tammana <g-tammana-l0cyMroinI0@public.gmane.org>
>>
>> BB2D entry is added to the dts file. Crossbar index number is used
>> for interrupt mapping.
>>
>> Signed-off-by: Gowtham Tammana <g-tammana-l0cyMroinI0@public.gmane.org>
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
>> ---
>> arch/arm/boot/dts/dra7.dtsi | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index addb753..43488b6 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -959,6 +959,16 @@
>> ti,hwmods = "dmm";
>> };
>>
>> + bb2d: bb2d@59000000 {
>> + compatible = "ti,dra7-bb2d";
>> + reg = <0x59000000 0x0700>;
>> + interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
>> + ti,hwmods = "bb2d";
>> + clocks = <&dpll_core_h24x2_ck>;
>> + clock-names = "fclk";
>
> "fclk" is not an accepted clock name for the etnaviv driver. It supports
> up to 3 clocks: "bus", "core" and "shader". If there is only one clock
> required in your design it would probably be the "core" clock.
fclk is used as a standard for all hwmod (SoC level control library
that existed prior to ARM DT-fication, and now slowly being converted
to DT). I think the core and bus clock is the same here.. I wonder if
something duplicated like the following will fly?
clocks = <&dpll_core_h24x2_ck>, <&dpll_core_h24x2_ck> ;
clock-names = "fclk", "core";
It might have been better if hwmod clocks were'nt assumed from
clock-names.. instead it could have been something like:
ti,hwmod-fck-clk-names = "core";
ti,hwmod-ick-clk-names = "bus";
ti,hwmod-ock-clk-names = "shader";
clocks = <&dpll_core_h24x2_ck>, <&clk2>, <&clk3>;
clock-names = "core", "bus", "shader";
Tero: ?
--
Regards,
Nishanth Menon
--
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] soc/tegra: Implement Tegra186 PMC support
From: Thierry Reding @ 2016-11-18 14:00 UTC (permalink / raw)
To: Jon Hunter
Cc: Rob Herring, Mark Rutland, Stephen Warren, Alexandre Courbot,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e9a081f5-8e93-d3e8-a702-79903e5a6a78-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Fri, Nov 18, 2016 at 09:36:04AM +0000, Jon Hunter wrote:
>
> On 17/11/16 17:16, Thierry Reding wrote:
> > From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >
> > The power management controller on Tegra186 has changed in backwards-
> > incompatible ways with respect to earlier generations. This implements a
> > new driver that supports inversion of the PMU interrupt as well as the
> > "recovery", "bootloader" and "forced-recovery" reboot commands.
> >
> > Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > .../bindings/arm/tegra/nvidia,tegra186-pmc.txt | 34 +++++
> > drivers/soc/tegra/Makefile | 2 +-
> > drivers/soc/tegra/pmc-tegra186.c | 169 +++++++++++++++++++++
> > 3 files changed, 204 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
> > create mode 100644 drivers/soc/tegra/pmc-tegra186.c
>
> ...
>
> > diff --git a/drivers/soc/tegra/Makefile b/drivers/soc/tegra/Makefile
> > index ae857ff7d53d..9976a0de1927 100644
> > --- a/drivers/soc/tegra/Makefile
> > +++ b/drivers/soc/tegra/Makefile
> > @@ -1,4 +1,4 @@
> > obj-y += fuse/
> >
> > obj-y += common.o
> > -obj-y += pmc.o
> > +obj-y += pmc.o pmc-tegra186.o
>
> Do we want to enable this driver for all Tegra devices? Was not sure if
> this should be dependent on ARM64.
Yeah, I think adding an non-user-visible Kconfig symbol for this might
make sense. Then we can use Kconfig to encode the logic about where to
enable this and simply use the Kconfig symbol in the Makefile.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: add documentation for rk1108 cru
From: Rob Herring @ 2016-11-18 14:03 UTC (permalink / raw)
To: Shawn Lin
Cc: Heiko Stuebner, Stephen Boyd, devicetree, Andy Yan,
Michael Turquette, linux-clk, linux-rockchip
In-Reply-To: <1479286163-34789-1-git-send-email-shawn.lin@rock-chips.com>
On Wed, Nov 16, 2016 at 04:49:21PM +0800, Shawn Lin wrote:
> This adds the dt-binding documentation for the clock and reset unit
> found on Rockchip rk1108 SoCs.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> ---
>
> Changes in v3:
> - fix mismatch of external clk input name
> - add hdmiphy and usbphy clk input
>
> Changes in v2: None
>
> .../bindings/clock/rockchip,rk1108-cru.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
> new file mode 100644
> index 0000000..4da1261
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
> @@ -0,0 +1,59 @@
> +* Rockchip RK1108 Clock and Reset Unit
> +
> +The RK1108 clock controller generates and supplies clock to various
> +controllers within the SoC and also implements a reset controller for SoC
> +peripherals.
> +
> +Required Properties:
> +
> +- compatible: should be "rockchip,rk1108-cru"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- #clock-cells: should be 1.
> +- #reset-cells: should be 1.
> +
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> + If missing pll rates are not changeable, due to the missing pll lock status.
> +
> +Each clock is assigned an identifier and client nodes can use this identifier
> +to specify the clock which they consume. All available clocks are defined as
> +preprocessor macros in the dt-bindings/clock/rk1108-cru.h headers and can be
> +used in device tree sources. Similar macros exist for the reset sources in
> +these files.
> +
> +External clocks:
> +
> +There are several clocks that are generated outside the SoC. It is expected
> +that they are defined using standard clock bindings with following
> +clock-output-names:
This stilll doesn't seem right. These are inputs to the CRU or
completely separate? If inputs, then you need a 'clocks' property. If
completely separate, then they should be listed in their respective IP
block binding (e.g. the USB phy).
> + - "xin24m" - crystal input - required,
> + - "ext_vip" - external VIP clock - optional
> + - "ext_i2s" - external I2S clock - optional
> + - "ext_gmac" - external GMAC clock - optional
> + - "hdmiphy" - external clock input derived from HDMI PHY - optional
> + - "usbphy" - external clock input derived from USB PHY - optional
> +
> +Example: Clock controller node:
> +
> + cru: cru@20200000 {
> + compatible = "rockchip,rk1108-cru";
> + reg = <0x20200000 0x1000>;
> + rockchip,grf = <&grf>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> +Example: UART controller node that consumes the clock generated by the clock
> + controller:
> +
> + uart0: serial@10230000 {
> + compatible = "rockchip,rk1108-uart", "snps,dw-apb-uart";
> + reg = <0x10230000 0x100>;
> + interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&cru SCLK_UART0>;
> + };
> --
> 1.9.1
>
>
^ permalink raw reply
* [PATCH v2 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2016-11-18 14:08 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Russell King, Rob Herring, Peter Rosin,
linux-arm-kernel
Hi!
changes v1 -> v2
- squash the fixup into the correct patch, sorry for the noise.
After finally having all essintial drivers upstreamed (the
last ones are currently in -next) I would like to have the
dts and the defconfig also upstreamed.
checkpatch complains about missing docs for some compatible
strings:
axentia,tse850v3 (v3 is the hw version that we currently use)
axentia,tse850 (in case we have future versions with commonality)
axentia,linea (the cpu module, reused in other products as well)
nxp,se97b (temp sensor in the below eeprom module)
nxp,24c02 (eeprom on the main board)
st,24c64 (eeprom on the cpu module)
I don't know where I should document those, or if it's even
needed? I get the feeling that the last three are not "my fault".
Anyway, please advice. Or, even better, apply as-is... :-)
Cheers,
Peter
Peter Rosin (2):
ARM: dts: add devicetree for the Axentia TSE-850
ARM: tse850_defconfig: add Axentia TSE-850
MAINTAINERS | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 52 +++++++
arch/arm/boot/dts/axentia-tse850-3.dts | 275 +++++++++++++++++++++++++++++++++
arch/arm/configs/tse850_defconfig | 223 ++++++++++++++++++++++++++
5 files changed, 558 insertions(+)
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
create mode 100644 arch/arm/configs/tse850_defconfig
--
2.1.4
^ permalink raw reply
* [PATCH v2 1/2] ARM: dts: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2016-11-18 14:08 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Russell King, Rob Herring, Peter Rosin,
linux-arm-kernel
In-Reply-To: <1479478094-20288-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
MAINTAINERS | 6 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 52 +++++++
arch/arm/boot/dts/axentia-tse850-3.dts | 275 +++++++++++++++++++++++++++++++++
4 files changed, 334 insertions(+)
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 9fe1bc9b414f..7ecf50e5ab47 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2325,6 +2325,12 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda@axentia.se>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/boot/dts/axentia-*
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
M: Mauro Carvalho Chehab <mchehab@kernel.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd2619902..02cd9b4c55d3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ axentia-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/axentia-linea.dtsi b/arch/arm/boot/dts/axentia-linea.dtsi
new file mode 100644
index 000000000000..07359f9d7419
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-linea.dtsi
@@ -0,0 +1,52 @@
+/*
+ * axentia-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ * Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&main {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/axentia-tse850-3.dts b/arch/arm/boot/dts/axentia-tse850-3.dts
new file mode 100644
index 000000000000..517381f89c3d
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-tse850-3.dts
@@ -0,0 +1,275 @@
+/*
+ * axentia-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ * Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "axentia-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,tse850", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ };
+
+ ahb {
+ apb {
+ pinctrl@fffff200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog@fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ 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 = <&pcm5142>;
+
+ 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>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv@c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2@100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree@180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs@10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42@18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom@50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
2.1.4
^ permalink raw reply related
* [PATCH v2 2/2] ARM: tse850_defconfig: add Axentia TSE-850
From: Peter Rosin @ 2016-11-18 14:08 UTC (permalink / raw)
To: linux-kernel
Cc: Mark Rutland, devicetree, Russell King, Rob Herring, Peter Rosin,
linux-arm-kernel
In-Reply-To: <1479478094-20288-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
MAINTAINERS | 1 +
arch/arm/configs/tse850_defconfig | 223 ++++++++++++++++++++++++++++++++++++++
2 files changed, 224 insertions(+)
create mode 100644 arch/arm/configs/tse850_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ecf50e5ab47..883d46eb2a06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2330,6 +2330,7 @@ M: Peter Rosin <peda@axentia.se>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/axentia-*
+F: arch/arm/configs/tse850_defconfig
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/arch/arm/configs/tse850_defconfig b/arch/arm/configs/tse850_defconfig
new file mode 100644
index 000000000000..f6076e7e1669
--- /dev/null
+++ b/arch/arm/configs/tse850_defconfig
@@ -0,0 +1,223 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_AT91=y
+CONFIG_SOC_SAMA5D3=y
+# CONFIG_CACHE_L2X0 is not set
+CONFIG_AEABI=y
+CONFIG_UACCESS_WITH_MEMCPY=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
+CONFIG_KEXEC=y
+CONFIG_VFP=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPGRE_DEMUX=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_UDP_DIAG=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+CONFIG_IPV6_SIT_6RD=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_SNMP=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_SET_RBTREE=y
+CONFIG_NFT_SET_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_HASH=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_ATMEL_TCLIB=y
+CONFIG_ATMEL_SSC=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+CONFIG_MACB=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_MICREL_PHY=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_LEGACY_PTY_COUNT=4
+CONFIG_SERIAL_ATMEL=y
+CONFIG_SERIAL_ATMEL_CONSOLE=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_AT91=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET=y
+CONFIG_SENSORS_JC42=y
+CONFIG_WATCHDOG=y
+CONFIG_AT91SAM9X_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_PCM_OSS=y
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_USB is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_ATMEL_SOC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
+# CONFIG_HID_GENERIC is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_STORAGE_REALTEK=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_ISD200=y
+CONFIG_USB_STORAGE_USBAT=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_STORAGE_ALAUDA=y
+CONFIG_USB_STORAGE_ONETOUCH=y
+CONFIG_USB_STORAGE_KARMA=y
+CONFIG_USB_STORAGE_CYPRESS_ATACB=y
+CONFIG_USB_STORAGE_ENE_UB6250=y
+CONFIG_USB_UAS=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_ATMEL_USBA=y
+CONFIG_USB_G_SERIAL=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AT91RM9200=y
+CONFIG_DMADEVICES=y
+CONFIG_AT_HDMAC=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_AT91_ADC=y
+CONFIG_ENVELOPE_DETECTOR=y
+CONFIG_DPOT_DAC=y
+CONFIG_MCP4531=y
+CONFIG_PWM=y
+CONFIG_PWM_ATMEL=y
+CONFIG_PWM_ATMEL_TCB=y
+CONFIG_EXT4_FS=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+CONFIG_STRIP_ASM_SYMS=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_SHA1=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEV_ATMEL_AES=y
+CONFIG_CRYPTO_DEV_ATMEL_TDES=y
+CONFIG_CRYPTO_DEV_ATMEL_SHA=y
--
2.1.4
^ permalink raw reply related
* Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver
From: Rob Herring @ 2016-11-18 14:09 UTC (permalink / raw)
To: Ong, Hean Loong
Cc: Tomi Valkeinen, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479287278-5192-1-git-send-email-hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On Wed, Nov 16, 2016 at 05:07:58PM +0800, Ong, Hean Loong wrote:
> From: Ong Hean Loong <hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>
> This patch enables the display port IP driver for
> Intel Arria 10 SOCFPGA Golden Hardware
> Reference Design (GHRD).
>
> The driver requires enabling the options such as
> Coheherent Memory Allocation,
> Intel FPGA Frame Buffer, Frame Buffer Conasole
>
> Signed-off-by: Ong Hean Loong <hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
> .../devicetree/bindings/video/intelfpgavipfb.txt | 22 ++
bindings/display/
It is preferred that bindings are a separate patch.
> MAINTAINERS | 6 +
> drivers/video/fbdev/Kconfig | 15 +
> drivers/video/fbdev/Makefile | 1 +
> drivers/video/fbdev/intelfpgavipfb.c | 302 ++++++++++++++++++++
AIUI, we're not taking new FB drivers. This should be a DRM driver
instead.
> 5 files changed, 346 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/intelfpgavipfb.txt
> create mode 100644 drivers/video/fbdev/intelfpgavipfb.c
>
> diff --git a/Documentation/devicetree/bindings/video/intelfpgavipfb.txt b/Documentation/devicetree/bindings/video/intelfpgavipfb.txt
> new file mode 100644
> index 0000000..8928c99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/intelfpgavipfb.txt
> @@ -0,0 +1,22 @@
> +Intel FPGA Video and Image Processing(VIP) Frame Buffer bindings
> +
> +Required properties:
> +- compatible: "intel,vip-frame-buffer2"
Should be something like 'intel,arria10-vip'. Describe the h/w block,
frame-buffer is a Linux term.
> +- reg: Physical base address and length of the framebuffer controller's
> + registers.
> +- max-width: The width of the framebuffer in pixels.
> +- max-height: The height of the framebuffer in pixels.
> +- bits-per-color: only "8" is currently supported
These are not h/w properties.
> +- mem-word-width = the bus width of the avalon master port on the frame reader
Needs a vendor prefix.
> +
> +Example:
> +
> +alt_vip_vfr_0: vip@0xff260000 {
> + compatible = "intel,vip-frame-buffer2";
> + reg = <0xff260000 0x00000080>;
> + max-width = <1024>;
> + max-height = <768>;
> + bits-per-color = <8>;
> + mem-word-width = <128>;
> +};
> +
--
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 1/3] hwmon: ltc2990: refactor value conversion
From: Guenter Roeck @ 2016-11-18 14:09 UTC (permalink / raw)
To: Tom Levens
Cc: jdelvare, robh+dt, mark.rutland, linux-kernel, linux-hwmon,
devicetree
In-Reply-To: <alpine.LRH.2.20.1611171955330.14972@pcbe13573-vm.dyndns.cern.ch>
On 11/18/2016 12:18 AM, Tom Levens wrote:
> Hi Guenter,
>
> On Thu, 17 Nov 2016, Guenter Roeck wrote:
>
>> On 11/17/2016 08:23 AM, Tom Levens wrote:
>>> Hi Guenter,
>>>
>>> Thanks for taking the time to review the patch.
>>>
>>> On Thu, 17 Nov 2016, Guenter Roeck wrote:
>>>
>>> > Hi Tom,
>>> > > On 11/17/2016 04:10 AM, Tom Levens wrote:
>>> > > Conversion from raw values to signed integers has been refactored > > using
>>> > > the macros in bitops.h.
>>> > > > Please also mention that this fixes a bug in negative temperature > conversions.
>>>
>>> Yes, of course, I will include the information in v3.
>>>
>>> > > > Signed-off-by: Tom Levens <tom.levens@cern.ch>
>>> > > ---
>>> > > drivers/hwmon/ltc2990.c | 27 ++++++++++-----------------
>>> > > 1 files changed, 10 insertions(+), 17 deletions(-)
>>> > > > > diff --git a/drivers/hwmon/ltc2990.c b/drivers/hwmon/ltc2990.c
>>> > > index 8f8fe05..0ec4102 100644
>>> > > --- a/drivers/hwmon/ltc2990.c
>>> > > +++ b/drivers/hwmon/ltc2990.c
>>> > > @@ -9,8 +9,12 @@
>>> > > * This driver assumes the chip is wired as a dual current monitor, > > and
>>> > > * reports the voltage drop across two series resistors. It also > > reports
>>> > > * the chip's internal temperature and Vcc power supply voltage.
>>> > > + *
>>> > > + * Value conversion refactored
>>> > > + * by Tom Levens <tom.levens@cern.ch>
>>> > > Kind of unusual to do that for minor changes like this. Imagine if > everyone would do that.
>>> > The commit log is what gives you credit.
>>>
>>> Good point, thanks for the hint. I will remove it from v3.
>>>
>>> > > */
>>> > > > > +#include <linux/bitops.h>
>>> > > #include <linux/err.h>
>>> > > #include <linux/hwmon.h>
>>> > > #include <linux/hwmon-sysfs.h>
>>> > > @@ -34,19 +38,10 @@
>>> > > #define LTC2990_CONTROL_MODE_CURRENT 0x06
>>> > > #define LTC2990_CONTROL_MODE_VOLTAGE 0x07
>>> > > > > -/* convert raw register value to sign-extended integer in 16-bit > > range */
>>> > > -static int ltc2990_voltage_to_int(int raw)
>>> > > -{
>>> > > - if (raw & BIT(14))
>>> > > - return -(0x4000 - (raw & 0x3FFF)) << 2;
>>> > > - else
>>> > > - return (raw & 0x3FFF) << 2;
>>> > > -}
>>> > > -
>>> > > /* Return the converted value from the given register in uV or mC */
>>> > > -static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, int > > *result)
>>> > > +static int ltc2990_get_value(struct i2c_client *i2c, u8 reg, s32 > > *result)
>>> > > {
>>> > > - int val;
>>> > > + s32 val;
>>> > > Please just leave the variable type alone. it is also used for the > return value
>>> > from i2c_smbus_read_word_swapped(), which is an int, and changing it to > s32 doesn't really make the code better.
>>>
>>> According to i2c.h the return type for i2c_smbus_read_word_swapped() is
>>> s32, which is why I modified it here. But it could be changed back if you
>>> think it is better to leave it as an int.
>>>
>> Ah, ok. Good to know. Please leave it anyway, reason being that there is no real
>> reason to change it. Effectively those are just whitespace changes (unlike the rest,
>> which is part bug fix, part cleanup).
>>
>>> > Can you send me a register map for the chip ? I would like to write a > module test.
>>>
>>> Here is an example register dump:
>>
>> I meant the output of i2cdump (something like "i2cdump -y -f <bus> <i2c-address> w").
>>
>
> The register map wraps at 0x0F, so I only sent you the first 16 bytes. But the fully expanded form is:
>
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 10: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 20: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 30: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 40: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 50: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 60: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 70: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 80: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> 90: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> a0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> b0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> c0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> d0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> e0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
> f0: 00 00 00 00 01 90 07 d0 2c cd 7d 80 7c 29 20 00
Sorry, I wasn't clear. The chip uses 16-bit registers, so the
"w" in the command would be important to report the entire
register content, not just the first 8 bit of each register.
Thanks,
Guenter
>
> Cheers,
>
>> Thanks,
>> Guenter
>>
>>>
>>> 00 00 00 00
>>> 01 90 07 d0
>>> 2c cd 7d 80
>>> 7c 29 20 00
>>>
>>> The expected values in this case are:
>>>
>>> in0_input 5000
>>> in1_input 610
>>> in2_input 3500
>>> in3_input -195
>>> in4_input -299
>>> temp1_input 25000
>>> temp2_input 125000
>>> temp3_input -40000
>>> curr1_input 38840
>>> curr2_input -12428
>>>
>>> Testing with lltc,mode set to <5>, <6> and <7> should give you all
>>> measurements.
>>>
>>> > Thanks,
>>> > Guenter
>>>
>>> Cheers,
>>>
>>
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: add documentation for rk1108 cru
From: Heiko Stuebner @ 2016-11-18 14:10 UTC (permalink / raw)
To: Rob Herring
Cc: Shawn Lin, Stephen Boyd, devicetree-u79uwXL29TY76Z2rM5mHXA,
Andy Yan, Michael Turquette, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161118140313.5uz56im37nt6qv7x@rob-hp-laptop>
Am Freitag, 18. November 2016, 08:03:13 CET schrieb Rob Herring:
> On Wed, Nov 16, 2016 at 04:49:21PM +0800, Shawn Lin wrote:
> > This adds the dt-binding documentation for the clock and reset unit
> > found on Rockchip rk1108 SoCs.
> >
> > Signed-off-by: Shawn Lin <shawn.lin-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >
> > ---
> >
> > Changes in v3:
> > - fix mismatch of external clk input name
> > - add hdmiphy and usbphy clk input
> >
> > Changes in v2: None
> >
> > .../bindings/clock/rockchip,rk1108-cru.txt | 59
> > ++++++++++++++++++++++ 1 file changed, 59 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt>
> > diff --git
> > a/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
> > b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt new
> > file mode 100644
> > index 0000000..4da1261
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
> > @@ -0,0 +1,59 @@
> > +* Rockchip RK1108 Clock and Reset Unit
> > +
> > +The RK1108 clock controller generates and supplies clock to various
> > +controllers within the SoC and also implements a reset controller for SoC
> > +peripherals.
> > +
> > +Required Properties:
> > +
> > +- compatible: should be "rockchip,rk1108-cru"
> > +- reg: physical base address of the controller and length of memory
> > mapped
> > + region.
> > +- #clock-cells: should be 1.
> > +- #reset-cells: should be 1.
> > +
> > +Optional Properties:
> > +
> > +- rockchip,grf: phandle to the syscon managing the "general register
> > files" + If missing pll rates are not changeable, due to the missing pll
> > lock status. +
> > +Each clock is assigned an identifier and client nodes can use this
> > identifier +to specify the clock which they consume. All available clocks
> > are defined as +preprocessor macros in the dt-bindings/clock/rk1108-cru.h
> > headers and can be +used in device tree sources. Similar macros exist for
> > the reset sources in +these files.
> > +
> > +External clocks:
> > +
> > +There are several clocks that are generated outside the SoC. It is
> > expected +that they are defined using standard clock bindings with
> > following
> > +clock-output-names:
> This stilll doesn't seem right. These are inputs to the CRU or
> completely separate? If inputs, then you need a 'clocks' property. If
> completely separate, then they should be listed in their respective IP
> block binding (e.g. the USB phy).
The problem is still the same as always. These clocks may or may not be
present, a lot of them come from IP blocks that probe later than the clock
controller and create a circular dependency.
I.e. the usbphy IP block gets supplied with a clock from the CRU that it needs
to function at all, but also contains a PLL on that clock that gets fed back
into the CRU to supply other clocks. Same for the other external clocks.
So we cannot "get" (and verify) these clocks when the core clock init runs
Therefore we're relying on the ability of the clock-framework to complete the
clock-tree once these clocks become available (or drop them again, if they
disappear again)
Heiko
--
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] pwm: add pwm driver for HiSilicon BVT SOCs
From: Rob Herring @ 2016-11-18 14:10 UTC (permalink / raw)
To: Jian Yuan
Cc: thierry.reding, mark.rutland, linux-pwm, devicetree, linux-kernel,
xuejiancheng, kevin.lixu, jalen.hsu
In-Reply-To: <1479289833-232200-1-git-send-email-yuanjian12@hisilicon.com>
On Wed, Nov 16, 2016 at 05:50:33PM +0800, Jian Yuan wrote:
> From: yuanjian <yuanjian12@hisilicon.com>
>
> Add PWM driver for the PWM controller found on HiSilicon BVT SOCs, like Hi3519V100, Hi3516CV300, etc.
> The PWM controller is primarily in charge of controlling P-Iris lens.
>
> Reviewed-by: Jiancheng Xue <xuejiancheng@hisilicon.com>
> Signed-off-by: Jian Yuan <yuanjian12@hisilicon.com>
> ---
> Change Log:
> v5:
> remove the generic compatible string "hisilicon, hibvt-pwm".
> v4:
> Add #pwm-cells in the bindings document.
> v3:
> fixed issues pointed by thierry.
> Add PWM compatible string for Hi3519V100.
> Implement .apply() function which support atomic, instead of .enable()/.disable()/.config().
> v2:
> The number of PWMs is change to be probeable based on the compatible string.
>
> .../devicetree/bindings/pwm/pwm-hibvt.txt | 22 ++
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pwm/Kconfig | 9 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-hibvt.c | 269 +++++++++++++++++++++
> 4 files changed, 301 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-hibvt.txt
> create mode 100644 drivers/pwm/pwm-hibvt.c
^ permalink raw reply
* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: Rob Herring @ 2016-11-18 14:13 UTC (permalink / raw)
To: John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Christian Lamparter, Stefan Wahren
In-Reply-To: <7fa1c1c4d703c435d698cdf140c9d43163347f1d.1479339900.git.johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Wed, Nov 16, 2016 at 03:47:18PM -0800, John Youn wrote:
> Add the "snps,ahb-burst" binding and read it in.
>
> This property controls which burst type to perform on the AHB bus as a
> master in internal DMA mode. This overrides the legacy param value,
> which we need to keep around for now since several platforms use it.
>
> Some platforms may see better or worse performance based on this
> value. The HAPS platform is one example where all INCRx have worse
> performance than INCR.
>
> Other platforms (such as the Canyonlands board) report that the default
> value causes system hangs.
>
> Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> ---
> Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/usb/dwc2/core.h | 9 +++++
> drivers/usb/dwc2/params.c | 56 ++++++++++++++++++++++++++
> 3 files changed, 67 insertions(+)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 v8 10/16] mmc: sdhci-msm: Implement set_clock callback for sdhci-msm
From: Adrian Hunter @ 2016-11-18 14:14 UTC (permalink / raw)
To: Ritesh Harjani, ulf.hansson, linux-mmc, sboyd, andy.gross
Cc: shawn.lin, devicetree, linux-clk, david.brown, linux-arm-msm,
georgi.djakov, alex.lemberg, mateusz.nowak, Yuliy.Izrailov,
asutoshd, david.griego, stummala, venkatg, rnayak, pramod.gurav,
jeremymc
In-Reply-To: <1479312052-22396-11-git-send-email-riteshh@codeaurora.org>
On 16/11/16 18:00, Ritesh Harjani wrote:
> sdhci-msm controller may have different clk-rates for each
> bus speed mode. Thus implement set_clock callback for
> sdhci-msm driver.
>
> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Yes my Ack stands.
> ---
> drivers/mmc/host/sdhci-msm.c | 66 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 45ead68..6d02fc2 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -84,6 +84,7 @@ struct sdhci_msm_host {
> struct clk *pclk; /* SDHC peripheral bus clock */
> struct clk *bus_clk; /* SDHC bus voter clock */
> struct clk *xo_clk; /* TCXO clk needed for FLL feature of cm_dll*/
> + unsigned long clk_rate;
> struct mmc_host *mmc;
> bool use_14lpp_dll_reset;
> };
> @@ -571,6 +572,69 @@ static unsigned int sdhci_msm_get_min_clock(struct sdhci_host *host)
> return SDHCI_MSM_MIN_CLOCK;
> }
>
> +/**
> + * __sdhci_msm_set_clock - sdhci_msm clock control.
> + *
> + * Description:
> + * MSM controller does not use internal divider and
> + * instead directly control the GCC clock as per
> + * HW recommendation.
> + **/
> +void __sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + u16 clk;
> + /*
> + * Keep actual_clock as zero -
> + * - since there is no divider used so no need of having actual_clock.
> + * - MSM controller uses SDCLK for data timeout calculation. If
> + * actual_clock is zero, host->clock is taken for calculation.
> + */
> + host->mmc->actual_clock = 0;
> +
> + sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
> +
> + if (clock == 0)
> + return;
> +
> + /*
> + * MSM controller do not use clock divider.
> + * Thus read SDHCI_CLOCK_CONTROL and only enable
> + * clock with no divider value programmed.
> + */
> + clk = sdhci_readw(host, SDHCI_CLOCK_CONTROL);
> + sdhci_enable_clock(host, clk);
> +}
> +
> +/* sdhci_msm_set_clock - Called with (host->lock) spinlock held. */
> +static void sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + int rc;
> +
> + if (!clock) {
> + msm_host->clk_rate = clock;
> + goto out;
> + }
> +
> + spin_unlock_irq(&host->lock);
> +
> + rc = clk_set_rate(msm_host->clk, clock);
> + if (rc) {
> + pr_err("%s: Failed to set clock at rate %u\n",
> + mmc_hostname(host->mmc), clock);
> + goto out_lock;
> + }
> + msm_host->clk_rate = clock;
> + pr_debug("%s: Setting clock at rate %lu\n",
> + mmc_hostname(host->mmc), clk_get_rate(msm_host->clk));
> +
> +out_lock:
> + spin_lock_irq(&host->lock);
> +out:
> + __sdhci_msm_set_clock(host, clock);
> +}
> +
> static const struct of_device_id sdhci_msm_dt_match[] = {
> { .compatible = "qcom,sdhci-msm-v4" },
> {},
> @@ -581,7 +645,7 @@ static unsigned int sdhci_msm_get_min_clock(struct sdhci_host *host)
> static const struct sdhci_ops sdhci_msm_ops = {
> .platform_execute_tuning = sdhci_msm_execute_tuning,
> .reset = sdhci_reset,
> - .set_clock = sdhci_set_clock,
> + .set_clock = sdhci_msm_set_clock,
> .get_min_clock = sdhci_msm_get_min_clock,
> .get_max_clock = sdhci_msm_get_max_clock,
> .set_bus_width = sdhci_set_bus_width,
>
^ permalink raw reply
* Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver
From: One Thousand Gnomes @ 2016-11-18 14:15 UTC (permalink / raw)
To: Rob Herring
Cc: Ong, Hean Loong, Tomi Valkeinen, devicetree, linux-kernel,
linux-fbdev
In-Reply-To: <20161118140903.q33zx7bk5nergq45@rob-hp-laptop>
> AIUI, we're not taking new FB drivers. This should be a DRM driver
> instead.
Yes - clone one of the dumb DRM drivers, or if you've got any little bits
of acceleration (even rolling the display) then it's possibly worth
accelerating for text mode.
> > +- max-width: The width of the framebuffer in pixels.
> > +- max-height: The height of the framebuffer in pixels.
> > +- bits-per-color: only "8" is currently supported
>
> These are not h/w properties.
How are the max ones not hardware properties ?
Alan
^ permalink raw reply
* Re: [PATCH v2 2/4] usb: dwc2: Add binding for AHB burst
From: Rob Herring @ 2016-11-18 14:16 UTC (permalink / raw)
To: Stefan Wahren, John Youn
Cc: Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Christian Lamparter
In-Reply-To: <633e5a10-1ea0-48c7-a5b7-a5ff2625e759-eS4NqCHxEME@public.gmane.org>
On Thu, Nov 17, 2016 at 04:35:10PM +0100, Stefan Wahren wrote:
> Hi John,
>
> Am 17.11.2016 um 00:47 schrieb John Youn:
> > Add the "snps,ahb-burst" binding and read it in.
> >
> > This property controls which burst type to perform on the AHB bus as a
> > master in internal DMA mode. This overrides the legacy param value,
> > which we need to keep around for now since several platforms use it.
> >
> > Some platforms may see better or worse performance based on this
> > value. The HAPS platform is one example where all INCRx have worse
> > performance than INCR.
> >
> > Other platforms (such as the Canyonlands board) report that the default
> > value causes system hangs.
> >
> > Signed-off-by: John Youn <johnyoun-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
> > Cc: Christian Lamparter <chunkeey-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> > ---
> > Documentation/devicetree/bindings/usb/dwc2.txt | 2 +
> > drivers/usb/dwc2/core.h | 9 +++++
> > drivers/usb/dwc2/params.c | 56 ++++++++++++++++++++++++++
> > 3 files changed, 67 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
> > index 6c7c2bce..9e7b4b4 100644
> > --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> > +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
>
> according to Documentation/devicetree/bindings/submitting-patches.txt
> this change should be a separate patch.
>
> > @@ -26,6 +26,8 @@ Optional properties:
> > Refer to phy/phy-bindings.txt for generic phy consumer properties
> > - dr_mode: shall be one of "host", "peripheral" and "otg"
> > Refer to usb/generic.txt
> > +- snps,ahb-burst: specifies the ahb burst length. Valid arguments are:
> > + "SINGLE", "INCR", "INCR4", "INCR8", "INCR16". Defaults to "INCR4".
>
> This doesn't apply in case of the bcm2835. I would prefer this option is
> ignored in that case with a dev_warn("snps,ahb-burst is not supported on
> this platform").
Also, perhaps you should allow that the compatible string can define the
default.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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] hwmon: ltc2990: support all measurement modes
From: Guenter Roeck @ 2016-11-18 14:16 UTC (permalink / raw)
To: Tom Levens
Cc: Mike Looijmans, jdelvare@suse.com, robh+dt@kernel.org,
mark.rutland@arm.com, linux-kernel@vger.kernel.org,
linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <alpine.LRH.2.20.1611181316110.5613@pcbe13573-vm.dyndns.cern.ch>
On 11/18/2016 04:23 AM, Tom Levens wrote:
>
>
> On Fri, 18 Nov 2016, Guenter Roeck wrote:
>
>> On Thu, Nov 17, 2016 at 11:25:30PM +0000, Tom Levens wrote:
>>> On 17 Nov 2016, at 22:54, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On Thu, Nov 17, 2016 at 08:52:12PM +0100, Mike Looijmans wrote:
>>>>> On 17-11-2016 19:56, Guenter Roeck wrote:
>>>>>> On Thu, Nov 17, 2016 at 06:40:17PM +0100, Mike Looijmans wrote:
>>>>>>> On 17-11-16 17:56, Guenter Roeck wrote:
>>>>>>>> On 11/17/2016 04:10 AM, Tom Levens wrote:
>>>>>>>>> Updated version of the ltc2990 driver which supports all measurement
>>>>>>>>> modes available in the chip. The mode can be set through a devicetree
>>>>>>>>> attribute.
>>>>>>>>
>>>>>> [ ... ]
>>>>>>
>>>>>>>>>
>>>>>>>>> static int ltc2990_i2c_probe(struct i2c_client *i2c,
>>>>>>>>> const struct i2c_device_id *id)
>>>>>>>>> {
>>>>>>>>> int ret;
>>>>>>>>> struct device *hwmon_dev;
>>>>>>>>> + struct ltc2990_data *data;
>>>>>>>>> + struct device_node *of_node = i2c->dev.of_node;
>>>>>>>>>
>>>>>>>>> if (!i2c_check_functionality(i2c->adapter,
>>>>>>>>> I2C_FUNC_SMBUS_BYTE_DATA |
>>>>>>>>> I2C_FUNC_SMBUS_WORD_DATA))
>>>>>>>>> return -ENODEV;
>>>>>>>>>
>>>>>>>>> - /* Setup continuous mode, current monitor */
>>>>>>>>> + data = devm_kzalloc(&i2c->dev, sizeof(struct ltc2990_data),
>>>>>>>>> GFP_KERNEL);
>>>>>>>>> + if (unlikely(!data))
>>>>>>>>> + return -ENOMEM;
>>>>>>>>> + data->i2c = i2c;
>>>>>>>>> +
>>>>>>>>> + if (!of_node || of_property_read_u32(of_node, "lltc,mode",
>>>>>>>>> &data->mode))
>>>>>>>>> + data->mode = LTC2990_CONTROL_MODE_DEFAULT;
>>>>>>>>
>>>>>>>> Iam arguing with myself if we should still do this or if we should read
>>>>>>>> the mode
>>>>>>>> from the chip instead if it isn't provided (after all, it may have been
>>>>>>>> initialized
>>>>>>>> by the BIOS/ROMMON).
>>>>>>>
>>>>>>> I think the mode should be explicitly set, without default. There's no way
>>>>>>> to tell whether the BIOS or bootloader has really set it up or whether the
>>>>>>> chip is just reporting whatever it happened to default to. And given the
>>>>>>> chip's function, it's unlikely a bootloader would want to initialize it.
>>>>>>>
>>>>>> Unlikely but possible. Even if we all agree that the chip should be configured
>>>>>> by the driver, I don't like imposing that view on everyone else.
>>>>>>
>>>>>>> My advice would be to make it a required property. If not set, display an
>>>>>>> error and bail out.
>>>>>>>
>>>>>> It is not that easy, unfortunately. It also has to work on a non-devicetree
>>>>>> system. I would not object to making the property mandatory, but we would
>>>>>> still need to provide non-DT support.
>>>>>>
>>>>>> My "use case" for taking the current mode from the chip if not specified
>>>>>> is that it would enable me to run a module test with all modes. I consider
>>>>>> this extremely valuable.
>>>>>
>>>>> Good point.
>>>>>
>>>>> The chip defaults to measuring internal temperature only, and the mode
>>>>> defaults to "0".
>>>>>
>>>>> Choosing a mode that doesn't match the actual circuitry could be bad for the
>>>>> chip or the board (though unlikely, it'll probably just be useless) since it
>>>>> will actively drive some of the inputs in the temperature modes (which is
>>>>> default for V3/V4 pins).
>>>>>
>>>>> Instead of failing, one could choose to set the default mode to "7", which
>>>>> just measures the 4 voltages, which would be a harmless mode in all cases.
>>>>>
>>>>> As a way to let a bootloader set things up, I think it would be a good check
>>>>> to see if CONTROL register bits 4:3 are set. If "00", the chip is not
>>>>> acquiring data at all, and probably needs configuration still. In that case,
>>>>> the mode must be provided by the devicetree (or the default "7").
>>>>> If bits 4:3 are "11", it has already been set up to measure its inputs, and
>>>>> it's okay to continue doing just that and use the current value of 2:0
>>>>> register as default mode (if the devicetree didn't specify any mode at all).
>>>>>
>>>>
>>>> At first glance, agreed, though by default b[3:4] are 00, and only the
>>>> internal temperature is measured. Actually, the 5 mode bits are all
>>>> relevant to determine what is measured. Maybe it would be better to take
>>>> all 5 bits into account instead of blindly setting b[34]:=11 and a specific
>>>> setting of b[0:2]. Sure, that would make the mode table a bit larger,
>>>> but then ltc2990_attrs_ena[] could be made an u16 array, and a table size
>>>> of 64 bytes would not be that bad.
>>>
>>> I would tend to agree that it should be possible to configure all 5 mode
>>> bits through the devicetree. What I would propose is as follows.
>>>
>>> If a devicetree node exists, the mode parameter(s?) are required and the
>>> chip is initialised.
>>>
>>> If a devicetree node doesn't exist, it is assumed that the chip has
>>> already been configured (by the BIOS, etc). The mode is read from the
>>> chip to set the visibility of the sysfs attributes. In the worst case, where the
>>> chip has not been configured by another source, it would only be possible
>>> to measure the internal temperature -- but I think this is an acceptable
>>> limitation.
>>>
>> SGTM.
>>
>>> The only case that this does not cover is if the device tree node
>>> exists but the chip is expected to be configured by some other source.
>>> Maybe I am wrong, but I would not expect this to be a terribly common
>>> situation.
>>>
>>> What do you think?
>>>
>> I would not bother about this case. Just make the mode property mandatory.
>
> What do you think about making the devicetree property a list of two integers? Something like
>
> lltc,mode = <7 3>;
>
> which would set mode[2..0]=7 and mode[4..3]=3.
>
I would personally just use a single value for b[4..0]. But that is really up for bikeshedding
(eg should it be <7 3> or <3 7>. I'll leave that up to Rob to decide - he knows better than me
of what makes more sense from a DT perspective.
Guenter
^ permalink raw reply
* Re: [PATCH v8 05/16] dt-bindings: sdhci-msm: Add xo property
From: Rob Herring @ 2016-11-18 14:17 UTC (permalink / raw)
To: Ritesh Harjani
Cc: ulf.hansson-QSEj5FYQhm4dnm+yROfE0A,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
adrian.hunter-ral2JQCrhuEAvxtiuMwx3w,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ, andy.gross-QSEj5FYQhm4dnm+yROfE0A,
shawn.lin-TNX95d0MmH7DzftRWevZcw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
david.brown-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
alex.lemberg-XdAiOPVOjttBDgjK7y7TUQ,
mateusz.nowak-ral2JQCrhuEAvxtiuMwx3w,
Yuliy.Izrailov-XdAiOPVOjttBDgjK7y7TUQ,
asutoshd-sgV2jX0FEOL9JmXXK+q4OQ,
david.griego-QSEj5FYQhm4dnm+yROfE0A,
stummala-sgV2jX0FEOL9JmXXK+q4OQ, venkatg-sgV2jX0FEOL9JmXXK+q4OQ,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ,
pramod.gurav-QSEj5FYQhm4dnm+yROfE0A,
jeremymc-H+wXaHxf7aLQT0dZR+AlfA
In-Reply-To: <1479343623-31163-1-git-send-email-riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Nov 17, 2016 at 06:17:03AM +0530, Ritesh Harjani wrote:
> Add "xo" property which is tcxo clock.
Technically, xo is not a property, but a value.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Signed-off-by: Ritesh Harjani <riteshh-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/sdhci-msm.txt | 1 +
> 1 file changed, 1 insertion(+)
--
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
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