* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Documentation/devicetree/bindings/net/phy.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8bf8fa..7f066b7c1e2c 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,11 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV register to
+ disable EEE modes. Example
+ * 0x4: disable EEE for 1000T,
+ * 0x6: disable EEE for 100TX and 1000T
+
Example:
ethernet-phy at 0 {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH net v2 3/3] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491d48a5..b34da077b2f8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -98,3 +98,18 @@
pinctrl-0 = <&i2c_a_pins>;
pinctrl-names = "default";
};
+
+ðmac {
+ phy-handle = <ð_phy0>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy at 0 {
+ reg = <0>;
+ eee-advert-disable = <0x4>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: da850-lcdk: fix mmc card detect polarity
From: Axel Haslam @ 2016-11-21 15:41 UTC (permalink / raw)
To: linux-arm-kernel
The polarity of the card detect pin is inverted.
Change it to reflect the right polarity for the board
which is ACTIVE_LOW.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..07bb40f4 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -122,7 +122,7 @@
bus-width = <4>;
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
- cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>;
+ cd-gpios = <&gpio 64 GPIO_ACTIVE_LOW>;
status = "okay";
};
--
2.9.3
^ permalink raw reply related
* Synopsys Ethernet QoS Driver
From: Lars Persson @ 2016-11-21 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b126021d-e902-7a53-4d7a-e73ea89a66cf@synopsys.com>
> 21 nov. 2016 kl. 16:06 skrev Joao Pinto <Joao.Pinto@synopsys.com>:
>
>> On 21-11-2016 14:25, Giuseppe CAVALLARO wrote:
>>> On 11/21/2016 2:28 PM, Lars Persson wrote:
>>>
>>>
>>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>>>>
>>>> Hello Joao
>>>>
>>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>>>>> Hello,
>>>>>
>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>>> single file
>>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
>>>>>>>> platform
>>>>>>>> related stuff.
>>>>>>>>
>>>>>>>> Our strategy would be:
>>>>>>>>
>>>>>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>>>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>>>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have
>>>>>>>> Ethernet QoS
>>>>>>>> related stuff to be reused by the platform / pci drivers
>>>>>>>> d) Add a set of features to the "core driver" that we have available
>>>>>>>> internally
>>>>>>>
>>>>>>> Note that there are actually two drivers in mainline for this hardware:
>>>>>>>
>>>>>>> drivers/net/ethernet/synopsis/
>>>>>>> drivers/net/ethernet/stmicro/stmmac/
>>>>>>
>>>>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>>>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>>>>> please refer this driver once before you start.
>>>>>>
>>>>>> You can start adding missing feature of 4.x in stmmac driver.
>>>>>
>>>>> Thanks you all for all the info.
>>>>> Well, I think we are in a good position to organize the ethernet drivers
>>>>> concerning Synopsys IPs.
>>>>>
>>>>> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
>>>>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>>>>> vendor using the same IP it should be able to reuse the commonn operations. But
>>>>> I would put that discussion for later :)
>>>>>
>>>>> For now I suggest that for we create ethernet/qos and create there a folder
>>>>> called dwc (designware controller) where all the synopsys qos IP specific code
>>>>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
>>>>> figure out a clean interface for "client drivers" like stmmac to interact with
>>>>> the new qos driver.
>>>>>
>>>>> What do you think about this approach?
>>>>
>>>> The stmmac drivers run since many years on several platforms
>>>> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
>>>> configurations starting from 3.1x to 3.7x databooks.
>>>>
>>>> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
>>>> are fully working.
>>>>
>>>> Also the stmmac has platform, device-tree and pcie supports and
>>>> a lot of maintained glue-logic files.
>>>>
>>>> It is fully documented inside the kernel tree.
>>>>
>>>> I am happy to have new enhancements from other developers.
>>>> So, on my side, if you want to spend your time on improving it on your
>>>> platforms please feel free to do it!
>>>>
>>>> Concerning the stmicro/stmmac naming, these come from a really old
>>>> story and have no issue to adopt new folder/file names.
>>>>
>>>> I am also open to merge fixes and changes from ethernet/synopsis.
>>>> I want to point you on some benchmarks made by Alex some months ago
>>>> (IIRC) that showed an stmmac winner (due to the several optimizations
>>>> analyzed and reviewed in this mailing list).
>>>>
>>>> Peppe
>>>>
>>>
>>> Hello Joao and others,
>>>
>
> Hi Lars,
>
>>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the
>>> most mature driver, the stmmac.
>>>
>>> I hope that the code can migrate into an ethernet/synopsys folder to keep the
>>> convention of naming the folder after the vendor. This makes it easy for
>>> others to find the driver.
>>>
>>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can
>>> then be implemented in the stmmac driver.
>
> So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys
> and try to improve the structure and add the missing QoS features to it?
Indeed this is what I prefer.
>
>>
>> Thanks Lars, I will be happy to support all you on this transition
>> and I agree on renaming all.
>>
>> peppe
>>
>>
>>> - Lars
>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>>>>
>>>>>>> The former only supports 4.x of the hardware.
>>>>>>>
>>>>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>>>>> with several features not present in the former (for example: TX/RX
>>>>>>> interrupt coalescing, EEE, PTP).
>>>>>>>
>>>>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>>>>> former rather than the latter?
>>>>>>
>>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* [RFC PATCH v2 4/8] arm64: compat: Add a 32-bit vDSO
From: Kevin Brodsky @ 2016-11-21 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161104200321.li3gzztg6p6xkwuh@localhost>
On 04/11/16 20:03, Catalin Marinas wrote:
> On Fri, Oct 28, 2016 at 11:20:07AM +0100, Kevin Brodsky wrote:
>> On 28/10/16 04:09, Jisheng Zhang wrote:
>>> On Thu, 27 Oct 2016 17:30:54 +0100 Kevin Brodsky wrote:
>>>> Provide the files necessary for building a compat (AArch32) vDSO in
>>>> kernel/vdso32.
>>>>
>>>> This is mostly an adaptation of the arm vDSO. The most significant
>>>> change in vgettimeofday.c is the use of the arm64 vdso_data struct,
>>>> allowing the vDSO data page to be shared between the 32 and 64-bit
>>>> vDSOs.
>>>>
>>>> In addition to the time functions, sigreturn trampolines are also
>>>> provided, aiming at replacing those in the vector page. To improve
>>>> debugging, CFI and unwinding directives are used, based on glibc's
>>>> implementation. Symbol offsets are made available to the kernel using
>>>> the same method as the 64-bit vDSO.
>>>>
>>>> There is unfortunately an important caveat to all this: we cannot get
>>>> away with hand-coding 32-bit instructions like in kernel/kuser32.S,
>>>> this time we really need a 32-bit compiler. The compat vDSO Makefile
>>>> relies on CROSS_COMPILE_ARM32 to provide a 32-bit compiler,
>>>> appropriate logic will be added to the arm64 Makefile later on to
>>>> ensure that an attempt to build the compat vDSO is made only if this
>>>> variable has been set properly.
>>>>
>>>> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
>>>> ---
>>>> arch/arm64/kernel/vdso32/Makefile | 121 +++++++++++++
>>>> arch/arm64/kernel/vdso32/sigreturn.S | 86 +++++++++
>>>> arch/arm64/kernel/vdso32/vdso.S | 32 ++++
>>>> arch/arm64/kernel/vdso32/vdso.lds.S | 98 +++++++++++
>>>> arch/arm64/kernel/vdso32/vgettimeofday.c | 294 +++++++++++++++++++++++++++++++
>>>> 5 files changed, 631 insertions(+)
>>>> create mode 100644 arch/arm64/kernel/vdso32/Makefile
>>>> create mode 100644 arch/arm64/kernel/vdso32/sigreturn.S
>>>> create mode 100644 arch/arm64/kernel/vdso32/vdso.S
>>>> create mode 100644 arch/arm64/kernel/vdso32/vdso.lds.S
>>>> create mode 100644 arch/arm64/kernel/vdso32/vgettimeofday.c
>>>>
>>>> diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
>>>> new file mode 100644
>>>> index 000000000000..38facc870f6e
>>>> --- /dev/null
>>>> +++ b/arch/arm64/kernel/vdso32/Makefile
>>>> @@ -0,0 +1,121 @@
>>>> +#
>>>> +# Building a vDSO image for AArch32.
>>>> +#
>>>> +# Author: Kevin Brodsky <kevin.brodsky@arm.com>
>>>> +# A mix between the arm64 and arm vDSO Makefiles.
>>>> +
>>>> +CC_ARM32 := $(CROSS_COMPILE_ARM32)gcc
>>>> +
>>>> +# Same as cc-ldoption, but using CC_ARM32 instead of CC
>>>> +cc32-ldoption = $(call try-run,\
>>>> + $(CC_ARM32) $(1) -nostdlib -x c /dev/null -o "$$TMP",$(1),$(2))
>>>> +
>>>> +# Borrow vdsomunge.c from the arm vDSO
>>>> +munge := arch/arm/vdso/vdsomunge
>>>> +hostprogs-y := $(srctree)/$(munge)
>>>> +
>>>> +c-obj-vdso := vgettimeofday.o
>>>> +asm-obj-vdso := sigreturn.o
>>>> +
>>>> +# Build rules
>>>> +targets := $(c-obj-vdso) $(asm-obj-vdso) vdso.so vdso.so.dbg vdso.so.raw
>>>> +c-obj-vdso := $(addprefix $(obj)/, $(c-obj-vdso))
>>>> +asm-obj-vdso := $(addprefix $(obj)/, $(asm-obj-vdso))
>>>> +obj-vdso := $(c-obj-vdso) $(asm-obj-vdso)
>>>> +
>>>> +ccflags-y := -fPIC -fno-common -fno-builtin -fno-stack-protector
>>>> +ccflags-y += -DDISABLE_BRANCH_PROFILING
>>>> +
>>>> +# Force -O2 to avoid libgcc dependencies
>>>> +VDSO_CFLAGS := -march=armv8-a -O2
>>> For completeness, bringing 32bit compiler need to check whether the 32bit
>>> toolchain support some options. IIRC, armv8-a support isn't enabled until
>>> gcc 4.8, so old toolchains such gcc-4.7 will complain:
>>> error: unrecognized argument in option ?-march=armv8-a?
>> That's a fair point. I guess -march=armv8-a is not strictly necessary and
>> the produced vDSO should be fine if arch/arm/vdso also compiles fine.
>> However we would still need to pass -march=armv7-a. I'm not sure what to do
>> between:
>> * Checking that the compiler supports -march=armv8-a when inspecting
>> CROSS_COMPILE_ARM32, and if it doesn't vdso32 will not be built.
>> * Checking whether -march=armv8-a is available here, and if it is not fall
>> back to -march=armv7-a.
> Does v8 vs v7 make any difference in the generated code? If not, we
> could just stick to armv7-a permanently.
I've just tried compiling with -march=armv7-a, and in fact it doesn't compile at all.
It turns out vgettimeofday.c uses smp_rmb(), which expands to dmb ishld on arm64, and
ishld doesn't exist in ARMv7. We could possibly work around that, but I think
requiring GCC 4.8 is reasonable.
Thanks,
Kevin
^ permalink raw reply
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Andrew Lunn @ 2016-11-21 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 21, 2016 at 04:35:23PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index bc1c3c8bf8fa..7f066b7c1e2c 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -35,6 +35,11 @@ Optional Properties:
> - broken-turn-around: If set, indicates the PHY device does not correctly
> release the turn around line low at the end of a MDIO transaction.
>
> +- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV register to
> + disable EEE modes. Example
> + * 0x4: disable EEE for 1000T,
> + * 0x6: disable EEE for 100TX and 1000T
> +
Hi Jerome
I like the direction this patchset is taking. But hex values are
pretty unfriendly. Please add a set of boolean properties, and do the
mapping to hex in the C code.
That would also make extending this API easier. e.g. say you have a
10Gbps PHY with EEE, and you need to disable it. This hex value
quickly gets ugly, eee-advert-disable-10000 is nice and simple.
Andrew
^ permalink raw reply
* [PATCH v5] arm64: dts: qcom: Add msm8916 CoreSight components
From: Georgi Djakov @ 2016-11-21 16:03 UTC (permalink / raw)
To: linux-arm-kernel
From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
Add initial set of CoreSight components found on Qualcomm msm8916 and
apq8016 based platforms, including the DragonBoard 410c board.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v4: (https://lkml.org/lkml/2016/11/17/533)
* Move everything into the SoC dtsi file as suggested by Stephen Boyd.
* Updated commit message.
* Got Ack from Mathieu.
Changes since v3: (https://lkml.org/lkml/2015/5/11/134)
* Include msm8916-coresight.dtsi into msm8916.dtsi
Changes since v2: (https://lkml.org/lkml/2015/4/29/242)
* Added "1x" to "qcom,coresight-replicator" compatible string, to match what
devicetree bindings documentations says.
arch/arm64/boot/dts/qcom/msm8916.dtsi | 241 ++++++++++++++++++++++++++++++++++
1 file changed, 241 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 4221b7d2c0ce..464f2740e512 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -14,6 +14,7 @@
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/qcom,gcc-msm8916.h>
#include <dt-bindings/reset/qcom,gcc-msm8916.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
/ {
model = "Qualcomm Technologies, Inc. MSM8916";
@@ -853,6 +854,246 @@
memory-region = <&mpss_mem>;
};
};
+
+ tpiu at 820000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0x820000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ port {
+ tpiu_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out1>;
+ };
+ };
+ };
+
+ funnel at 821000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x821000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Not described input ports:
+ * 0 - connected to Resource and Power Manger CPU ETM
+ * 1 - not-connected
+ * 2 - connected to Modem CPU ETM
+ * 3 - not-connected
+ * 5 - not-connected
+ * 6 - connected trought funnel to Wireless CPU ETM
+ * 7 - connected to STM component
+ */
+
+ port at 4 {
+ reg = <4>;
+ funnel0_in4: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel1_out>;
+ };
+ };
+ port at 8 {
+ reg = <0>;
+ funnel0_out: endpoint {
+ remote-endpoint = <&etf_in>;
+ };
+ };
+ };
+ };
+
+ replicator at 824000 {
+ compatible = "qcom,coresight-replicator1x", "arm,primecell";
+ reg = <0x824000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ replicator_out0: endpoint {
+ remote-endpoint = <&etr_in>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ replicator_out1: endpoint {
+ remote-endpoint = <&tpiu_in>;
+ };
+ };
+ port at 2 {
+ reg = <0>;
+ replicator_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&etf_out>;
+ };
+ };
+ };
+ };
+
+ etf at 825000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0x825000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ etf_out: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel0_out>;
+ };
+ };
+ port at 1 {
+ reg = <0>;
+ etf_in: endpoint {
+ remote-endpoint = <&replicator_in>;
+ };
+ };
+ };
+ };
+
+ etr at 826000 {
+ compatible = "arm,coresight-tmc", "arm,primecell";
+ reg = <0x826000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ port {
+ etr_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out0>;
+ };
+ };
+ };
+
+ funnel at 841000 { /* APSS funnel only 4 inputs are used */
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x841000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ funnel1_in0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ funnel1_in1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+ port at 2 {
+ reg = <2>;
+ funnel1_in2: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+ port at 3 {
+ reg = <3>;
+ funnel1_in3: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ port at 4 {
+ reg = <0>;
+ funnel1_out: endpoint {
+ remote-endpoint = <&funnel0_in4>;
+ };
+ };
+ };
+ };
+
+ etm at 85c000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85c000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU0>;
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint = <&funnel1_in0>;
+ };
+ };
+ };
+
+ etm at 85d000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85d000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU1>;
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint = <&funnel1_in1>;
+ };
+ };
+ };
+
+ etm at 85e000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85e000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU2>;
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint = <&funnel1_in2>;
+ };
+ };
+ };
+
+ etm at 85f000 {
+ compatible = "arm,coresight-etm4x", "arm,primecell";
+ reg = <0x85f000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>, <&rpmcc RPM_QDSS_A_CLK>;
+ clock-names = "apb_pclk", "atclk";
+
+ cpu = <&CPU3>;
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint = <&funnel1_in3>;
+ };
+ };
+ };
};
smd {
^ permalink raw reply related
* [PATCH v2] ARM: dts: qcom: Add apq8064 CoreSight components
From: Georgi Djakov @ 2016-11-21 16:04 UTC (permalink / raw)
To: linux-arm-kernel
From: "Ivan T. Ivanov" <ivan.ivanov@linaro.org>
Add initial set of CoreSight components found on Qualcomm apq8064 based
platforms, including the IFC6410 board.
Signed-off-by: Ivan T. Ivanov <ivan.ivanov@linaro.org>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
---
Changes since v1 (https://lkml.org/lkml/2016/11/17/474)
* Moved everything into the SoC dtsi file as suggested by Stephen Boyd.
* Updated commit message.
* Got Ack from Mathieu.
arch/arm/boot/dts/qcom-apq8064.dtsi | 191 +++++++++++++++++++++++++++++++++++-
1 file changed, 187 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 268bd470c865..2e8dd5d098f3 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/clock/qcom,gcc-msm8960.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include <dt-bindings/clock/qcom,mmcc-msm8960.h>
+#include <dt-bindings/clock/qcom,rpmcc.h>
#include <dt-bindings/soc/qcom,gsbi.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
@@ -27,7 +28,7 @@
#address-cells = <1>;
#size-cells = <0>;
- cpu at 0 {
+ CPU0: cpu at 0 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -38,7 +39,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 1 {
+ CPU1: cpu at 1 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -49,7 +50,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 2 {
+ CPU2: cpu at 2 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -60,7 +61,7 @@
cpu-idle-states = <&CPU_SPC>;
};
- cpu at 3 {
+ CPU3: cpu at 3 {
compatible = "qcom,krait";
enable-method = "qcom,kpss-acc-v1";
device_type = "cpu";
@@ -1416,6 +1417,187 @@
};
};
};
+
+ etb at 1a01000 {
+ compatible = "coresight-etb10", "arm,primecell";
+ reg = <0x1a01000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ port {
+ etb_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out0>;
+ };
+ };
+ };
+
+ tpiu at 1a03000 {
+ compatible = "arm,coresight-tpiu", "arm,primecell";
+ reg = <0x1a03000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ port {
+ tpiu_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&replicator_out1>;
+ };
+ };
+ };
+
+ replicator {
+ compatible = "arm,coresight-replicator";
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ replicator_out0: endpoint {
+ remote-endpoint = <&etb_in>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ replicator_out1: endpoint {
+ remote-endpoint = <&tpiu_in>;
+ };
+ };
+ port at 2 {
+ reg = <0>;
+ replicator_in: endpoint {
+ slave-mode;
+ remote-endpoint = <&funnel_out>;
+ };
+ };
+ };
+ };
+
+ funnel at 1a04000 {
+ compatible = "arm,coresight-funnel", "arm,primecell";
+ reg = <0x1a04000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /*
+ * Not described input ports:
+ * 2 - connected to STM component
+ * 3 - not-connected
+ * 6 - not-connected
+ * 7 - not-connected
+ */
+ port at 0 {
+ reg = <0>;
+ funnel_in0: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm0_out>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ funnel_in1: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm1_out>;
+ };
+ };
+ port at 4 {
+ reg = <4>;
+ funnel_in4: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm2_out>;
+ };
+ };
+ port at 5 {
+ reg = <5>;
+ funnel_in5: endpoint {
+ slave-mode;
+ remote-endpoint = <&etm3_out>;
+ };
+ };
+ port at 8 {
+ reg = <0>;
+ funnel_out: endpoint {
+ remote-endpoint = <&replicator_in>;
+ };
+ };
+ };
+ };
+
+ etm at 1a1c000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1c000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU0>;
+
+ port {
+ etm0_out: endpoint {
+ remote-endpoint = <&funnel_in0>;
+ };
+ };
+ };
+
+ etm at 1a1d000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1d000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU1>;
+
+ port {
+ etm1_out: endpoint {
+ remote-endpoint = <&funnel_in1>;
+ };
+ };
+ };
+
+ etm at 1a1e000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1e000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU2>;
+
+ port {
+ etm2_out: endpoint {
+ remote-endpoint = <&funnel_in4>;
+ };
+ };
+ };
+
+ etm at 1a1f000 {
+ compatible = "arm,coresight-etm3x", "arm,primecell";
+ reg = <0x1a1f000 0x1000>;
+
+ clocks = <&rpmcc RPM_QDSS_CLK>;
+ clock-names = "apb_pclk";
+
+ cpu = <&CPU3>;
+
+ port {
+ etm3_out: endpoint {
+ remote-endpoint = <&funnel_in5>;
+ };
+ };
+ };
};
};
#include "qcom-apq8064-pins.dtsi"
^ permalink raw reply related
* [PATCH 1/2] ARM: mm: fix set_memory_*() bounds checks
From: Russell King @ 2016-11-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
The set_memory_*() bounds checks are buggy on several fronts:
1. They fail to round the region size up if the passed address is not
page aligned.
2. The region check was incomplete, and didn't correspond with what
was being asked of apply_to_page_range()
So, rework change_memory_common() to fix these problems, adding an
"in_region()" helper to determine whether the start & size fit within
the provided region start and stop addresses.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/mm/pageattr.c | 26 +++++++++++++-------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
index d19b1ad29b07..db09f2e7efda 100644
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -34,28 +34,28 @@ static int change_page_range(pte_t *ptep, pgtable_t token, unsigned long addr,
return 0;
}
+static bool in_range(unsigned long start, unsigned long size,
+ unsigned long range_start, unsigned long range_end)
+{
+ return start >= range_start && start < range_end &&
+ size <= range_end - start;
+}
+
static int change_memory_common(unsigned long addr, int numpages,
pgprot_t set_mask, pgprot_t clear_mask)
{
- unsigned long start = addr;
- unsigned long size = PAGE_SIZE*numpages;
- unsigned long end = start + size;
+ unsigned long start = addr & PAGE_SIZE;
+ unsigned long end = PAGE_ALIGN(addr) + numpages * PAGE_SIZE;
+ unsigned long size = end - start;
int ret;
struct page_change_data data;
- if (!IS_ALIGNED(addr, PAGE_SIZE)) {
- start &= PAGE_MASK;
- end = start + size;
- WARN_ON_ONCE(1);
- }
+ WARN_ON_ONCE(start != addr);
- if (!numpages)
+ if (!size)
return 0;
- if (start < MODULES_VADDR || start >= MODULES_END)
- return -EINVAL;
-
- if (end < MODULES_VADDR || start >= MODULES_END)
+ if (!in_range(start, size, MODULES_VADDR, MODULES_END))
return -EINVAL;
data.set_mask = set_mask;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: mm: allow set_memory_*() to be used on the vmalloc region
From: Russell King @ 2016-11-21 16:08 UTC (permalink / raw)
To: linux-arm-kernel
We can allow modules to be loaded into the vmalloc region, where they
should also benefit from the same protections as those loaded into
the more efficient module region. Allow these functions to operate
there as well.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
arch/arm/mm/pageattr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
index db09f2e7efda..ad8032bfe734 100644
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -55,7 +55,8 @@ static int change_memory_common(unsigned long addr, int numpages,
if (!size)
return 0;
- if (!in_range(start, size, MODULES_VADDR, MODULES_END))
+ if (!in_range(start, size, MODULES_VADDR, MODULES_END) &&
+ !in_range(start, size, VMALLOC_START, VMALLOC_END))
return -EINVAL;
data.set_mask = set_mask;
--
2.7.4
^ permalink raw reply related
* Synopsys Ethernet QoS Driver
From: Joao Pinto @ 2016-11-21 16:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <A001080B-2DC8-48D9-BD82-8276A9B3BE3D@axis.com>
On 21-11-2016 15:43, Lars Persson wrote:
>
>
>> 21 nov. 2016 kl. 16:06 skrev Joao Pinto <Joao.Pinto@synopsys.com>:
>>
>>> On 21-11-2016 14:25, Giuseppe CAVALLARO wrote:
>>>> On 11/21/2016 2:28 PM, Lars Persson wrote:
>>>>
>>>>
>>>>> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>>>>>
>>>>> Hello Joao
>>>>>
>>>>>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>>>>>> Hello,
>>>>>>
>>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>>>> single file
>>>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
snip (...)
>>>>> The stmmac drivers run since many years on several platforms
>>>>> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
>>>>> configurations starting from 3.1x to 3.7x databooks.
>>>>>
>>>>> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
>>>>> are fully working.
>>>>>
>>>>> Also the stmmac has platform, device-tree and pcie supports and
>>>>> a lot of maintained glue-logic files.
>>>>>
>>>>> It is fully documented inside the kernel tree.
>>>>>
>>>>> I am happy to have new enhancements from other developers.
>>>>> So, on my side, if you want to spend your time on improving it on your
>>>>> platforms please feel free to do it!
>>>>>
>>>>> Concerning the stmicro/stmmac naming, these come from a really old
>>>>> story and have no issue to adopt new folder/file names.
>>>>>
>>>>> I am also open to merge fixes and changes from ethernet/synopsis.
>>>>> I want to point you on some benchmarks made by Alex some months ago
>>>>> (IIRC) that showed an stmmac winner (due to the several optimizations
>>>>> analyzed and reviewed in this mailing list).
>>>>>
>>>>> Peppe
>>>>>
>>>>
>>>> Hello Joao and others,
>>>>
>>
>> Hi Lars,
>>
>>>> As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the
>>>> most mature driver, the stmmac.
>>>>
>>>> I hope that the code can migrate into an ethernet/synopsys folder to keep the
>>>> convention of naming the folder after the vendor. This makes it easy for
>>>> others to find the driver.
>>>>
>>>> The dwc_eth_qos.c will eventually be removed and its DT binding interface can
>>>> then be implemented in the stmmac driver.
>>
>> So your ideia is to pick the ethernet/stmmac and rename it to ethernet/synopsys
>> and try to improve the structure and add the missing QoS features to it?
>
> Indeed this is what I prefer.
Ok, it makes sense.
Just for curiosity the target setup is the following:
https://www.youtube.com/watch?v=8V-LB5y2Cos
but instead of using internal drivers, we desire to use mainline drivers only.
Thanks!
>
>>
>>>
>>> Thanks Lars, I will be happy to support all you on this transition
>>> and I agree on renaming all.
>>>
>>> peppe
>>>
>>>
>>>> - Lars
>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>>>>>
>>>>>>>> The former only supports 4.x of the hardware.
>>>>>>>>
>>>>>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>>>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>>>>>> with several features not present in the former (for example: TX/RX
>>>>>>>> interrupt coalescing, EEE, PTP).
>>>>>>>>
>>>>>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>>>>>> former rather than the latter?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
^ permalink raw reply
* [PATCH 0/3] ARM: davinci: hawk: fix mmc gpio declaration
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
The hawk board does not have a write protect gpio, so remove
it form the platform data. Also the card detect gpio is declared
on the wrong pin. fix it.
After fixing the platform data bugs, change to use a gpio descriptor,
so we can take advantage of the drivers recent updates, and have card
detect irq instead of polling.
DEPENDENCIES:
MMC: davinci: fix card detect and write protect
https://lkml.org/lkml/2016/11/15/592
Axel Haslam (3):
ARM: davinci: hawk: fix mmc card detect gpio
ARM: davinci: hawk: remove mmc ro pin
ARM: davinci: hawk: use gpio descriptor for card detect
arch/arm/mach-davinci/board-omapl138-hawk.c | 44 ++++++++---------------------
1 file changed, 12 insertions(+), 32 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH 1/3] ARM: davinci: hawk: fix mmc card detect gpio
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121161541.27048-1-ahaslam@baylibre.com>
The card detect gpio on the hawk board is gpio4_0 and not gpio3_12
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a4e8726..c0c24ba9 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -25,7 +25,7 @@
#include <mach/mux.h>
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
-#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12)
+#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
@@ -119,7 +119,7 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
static const short hawk_mmcsd0_pins[] = {
DA850_MMCSD0_DAT_0, DA850_MMCSD0_DAT_1, DA850_MMCSD0_DAT_2,
DA850_MMCSD0_DAT_3, DA850_MMCSD0_CLK, DA850_MMCSD0_CMD,
- DA850_GPIO3_12, DA850_GPIO3_13,
+ DA850_GPIO4_0, DA850_GPIO3_13,
-1
};
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] ARM: davinci: hawk: remove mmc ro pin
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121161541.27048-1-ahaslam@baylibre.com>
The hawk board does not have a write protect pin to read the card
write protect status.
So remove un-needed platform data declaration for this gpio.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 19 +------------------
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index c0c24ba9..ddc312d 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -26,7 +26,6 @@
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
-#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
@@ -119,22 +118,16 @@ static struct edma_rsv_info *da850_edma_rsv[2] = {
static const short hawk_mmcsd0_pins[] = {
DA850_MMCSD0_DAT_0, DA850_MMCSD0_DAT_1, DA850_MMCSD0_DAT_2,
DA850_MMCSD0_DAT_3, DA850_MMCSD0_CLK, DA850_MMCSD0_CMD,
- DA850_GPIO4_0, DA850_GPIO3_13,
+ DA850_GPIO4_0,
-1
};
-static int da850_hawk_mmc_get_ro(int index)
-{
- return gpio_get_value(DA850_HAWK_MMCSD_WP_PIN);
-}
-
static int da850_hawk_mmc_get_cd(int index)
{
return !gpio_get_value(DA850_HAWK_MMCSD_CD_PIN);
}
static struct davinci_mmc_config da850_mmc_config = {
- .get_ro = da850_hawk_mmc_get_ro,
.get_cd = da850_hawk_mmc_get_cd,
.wires = 4,
.max_freq = 50000000,
@@ -159,14 +152,6 @@ static __init void omapl138_hawk_mmc_init(void)
return;
}
- ret = gpio_request_one(DA850_HAWK_MMCSD_WP_PIN,
- GPIOF_DIR_IN, "MMC WP");
- if (ret < 0) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_HAWK_MMCSD_WP_PIN);
- goto mmc_setup_wp_fail;
- }
-
ret = da8xx_register_mmcsd0(&da850_mmc_config);
if (ret) {
pr_warn("%s: MMC/SD0 registration failed: %d\n", __func__, ret);
@@ -176,8 +161,6 @@ static __init void omapl138_hawk_mmc_init(void)
return;
mmc_setup_mmcsd_fail:
- gpio_free(DA850_HAWK_MMCSD_WP_PIN);
-mmc_setup_wp_fail:
gpio_free(DA850_HAWK_MMCSD_CD_PIN);
}
--
2.9.3
^ permalink raw reply related
* [PATCH 3/3] ARM: davinci: hawk: use gpio descriptor for card detect
From: Axel Haslam @ 2016-11-21 16:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121161541.27048-1-ahaslam@baylibre.com>
Currently the mmc driver is polling the gpio to know if the
card was removed.
By using a gpio descriptor instead of the platform callbacks, the
driver will be able to register the gpio with the mmc core with API's
designed for this purpose.
This has the advantage that an irq will be registered,
and polling is no longer needed. Also, platform callbacks can be removed.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 25 +++++++++++--------------
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index ddc312d..8e4f2102 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -15,6 +15,7 @@
#include <linux/gpio.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/regulator/machine.h>
+#include <linux/gpio/machine.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -25,7 +26,6 @@
#include <mach/mux.h>
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
-#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
@@ -122,13 +122,16 @@ static const short hawk_mmcsd0_pins[] = {
-1
};
-static int da850_hawk_mmc_get_cd(int index)
-{
- return !gpio_get_value(DA850_HAWK_MMCSD_CD_PIN);
-}
+static struct gpiod_lookup_table mmc_gpios_table = {
+ .dev_id = "da830-mmc.0",
+ .table = {
+ /* gpio4_0: chip 2 contains gpio range 64-95 */
+ GPIO_LOOKUP("davinci_gpio.2", 0, "cd",
+ GPIO_ACTIVE_LOW),
+ },
+};
static struct davinci_mmc_config da850_mmc_config = {
- .get_cd = da850_hawk_mmc_get_cd,
.wires = 4,
.max_freq = 50000000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -144,13 +147,7 @@ static __init void omapl138_hawk_mmc_init(void)
return;
}
- ret = gpio_request_one(DA850_HAWK_MMCSD_CD_PIN,
- GPIOF_DIR_IN, "MMC CD");
- if (ret < 0) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_HAWK_MMCSD_CD_PIN);
- return;
- }
+ gpiod_add_lookup_table(&mmc_gpios_table);
ret = da8xx_register_mmcsd0(&da850_mmc_config);
if (ret) {
@@ -161,7 +158,7 @@ static __init void omapl138_hawk_mmc_init(void)
return;
mmc_setup_mmcsd_fail:
- gpio_free(DA850_HAWK_MMCSD_CD_PIN);
+ gpiod_remove_lookup_table(&mmc_gpios_table);
}
static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
--
2.9.3
^ permalink raw reply related
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Jerome Brunet @ 2016-11-21 16:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121160149.GF1922@lunn.ch>
On Mon, 2016-11-21 at 17:01 +0100, Andrew Lunn wrote:
> On Mon, Nov 21, 2016 at 04:35:23PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > ---
> > ?Documentation/devicetree/bindings/net/phy.txt | 5 +++++
> > ?1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/phy.txt
> > b/Documentation/devicetree/bindings/net/phy.txt
> > index bc1c3c8bf8fa..7f066b7c1e2c 100644
> > --- a/Documentation/devicetree/bindings/net/phy.txt
> > +++ b/Documentation/devicetree/bindings/net/phy.txt
> > @@ -35,6 +35,11 @@ Optional Properties:
> > ?- broken-turn-around: If set, indicates the PHY device does not
> > correctly
> > ???release the turn around line low at the end of a MDIO
> > transaction.
> > ?
> > +- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV
> > register to
> > +??disable EEE modes. Example
> > +????* 0x4: disable EEE for 1000T,
> > +????* 0x6: disable EEE for 100TX and 1000T
> > +
>
> Hi Jerome
>
> I like the direction this patchset is taking. But hex values are
> pretty unfriendly.
Agreed
> Please add a set of boolean properties, and do the
> mapping to hex in the C code.
>
> That would also make extending this API easier. e.g. say you have a
> 10Gbps PHY with EEE, and you need to disable it. This hex value
> quickly gets ugly, eee-advert-disable-10000 is nice and simple.
What I did not realize when doing this patch for the realtek driver is
that there is already 6 valid modes defined in the kernel
#define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
100TX EEE cap */
#define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
1000T EEE cap */
#define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
#define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
*/
#define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
*/
#define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
*/
I took care of only 2 in the case of realtek.c since it only support
MDIO_EEE_100TX and MDIO_EEE_1000T.
Defining a property for each is certainly doable but it does not look
very nice either. If it extends in the future, it will get even more
messier, especially if you want to disable everything.
What do you think about keeping a single mask value but use the define
above in the DT ? It would be more readable than hex and easy to
extend, don't you think ?
These defines are already part of the uapi so I guess we can use those
in the DT bindings ?
>
> Andrew
^ permalink raw reply
* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Olof Johansson @ 2016-11-21 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXAuDcbr84phfPRpqZYRzAZf2j4vsv+i_Frz0G8ksd_Vg@mail.gmail.com>
On Mon, Nov 21, 2016 at 1:31 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> Hi Olof,
>
> On Sat, Nov 19, 2016 at 2:28 AM, Olof Johansson <olof@lixom.net> wrote:
>> On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
>>> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>
>>> * Basic support for r8a7745 SoC
>>>
>>> ----------------------------------------------------------------
>>> Sergei Shtylyov (2):
>>> ARM: shmobile: r8a7745: basic SoC support
>>> ARM: shmobile: document SK-RZG1E board
>>
>> Hi,
>>
>> Is there a reason you're adding a config option per SoC?
>>
>> I think you'd be better off not adding these config options, and just adding
>> support for the SoCs through compatibles (and adding the drivers to defconfigs,
>> etc).
>
> Yes there is a reason: kernel size.
> The main offenders are the pinctrl tables, which add ca. 20-50 KiB per
> supported SoC.
So don't turn on that pinctrl driver unless you have that SoC?
> Note that RZ/A1 (r7s72100) is used on some boards with its internal RAM
> (10 MiB) only.
-Olof
^ permalink raw reply
* [GIT PULL 1/2] SoCFPGA DTS update for v4.10, part 3
From: Dinh Nguyen @ 2016-11-21 16:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Kevin, and Olof:
Please pull in this DTS update for v4.10.
Thanks,
Dinh
The following changes since commit d837a80d19505d74ee5941eebf9dd53fed6f36a6:
ARM: dts: socfpga: add nand controller nodes (2016-11-09 12:40:52 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_dts_for_v4.10_part_3
for you to fetch changes up to 7c38dc624bc49d83d84c185e2ca14adf352c5eaa:
ARM: dts: socfpga: fine-tune L2 cache configuration (2016-11-21 09:23:31 -0600)
----------------------------------------------------------------
SoCFPGA DTS update for v4.10, part 3
- Fine tune L2 cache configuration
----------------------------------------------------------------
Marek Vasut (1):
ARM: dts: socfpga: fine-tune L2 cache configuration
arch/arm/boot/dts/socfpga.dtsi | 5 +++++
1 file changed, 5 insertions(+)
^ permalink raw reply
* [GIT PULL 2/2] SoCFPGA update for v4.10
From: Dinh Nguyen @ 2016-11-21 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162309.5408-1-dinguyen@kernel.org>
Hi Arnd, Kevin, and Olof:
Please pull in this update for v4.10.
Thanks,
Dinh
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux.git tags/socfpga_updates_for_v4.10
for you to fetch changes up to ed72af3a8ccf9b29ccb575d39fb997e5f12b03f8:
ARM: socfpga: fix spelling mistake in error message (2016-11-15 08:52:17 -0600)
----------------------------------------------------------------
SoCFPGA update for v4.10
- Fixup spelling error
----------------------------------------------------------------
Colin King (1):
ARM: socfpga: fix spelling mistake in error message
arch/arm/mach-socfpga/l2_cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
^ permalink raw reply
* [PATCH v2 1/3] ARM: sunxi: add support for H2+ SoC
From: Icenowy Zheng @ 2016-11-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
Allwinner H2+ is a quad-core Cortex-A7 SoC.
It is very like H3, that they share the same SoC ID (0x1680), and H3
memory maps as well as drivers works well on the SoC.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/arm/sunxi/README | 4 ++++
Documentation/devicetree/bindings/arm/sunxi.txt | 1 +
arch/arm/mach-sunxi/sunxi.c | 1 +
3 files changed, 6 insertions(+)
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index cd02433..1fe4d99c 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -63,6 +63,10 @@ SunXi family
+ User Manual
http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf
+ - Allwinner H2+ (sun8i)
+ + No document available now, but is known to be working properly with
+ H3 drivers and memory map.
+
- Allwinner H3 (sun8i)
+ Datasheet
http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf
diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt
index 4d6467c..26b35a7 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.txt
+++ b/Documentation/devicetree/bindings/arm/sunxi.txt
@@ -13,6 +13,7 @@ using one of the following compatible strings:
allwinner,sun8i-a33
allwinner,sun8i-a83t
allwinner,sun8i-h3
+ allwinner,sun8i-h2plus
allwinner,sun9i-a80
allwinner,sun50i-a64
nextthing,gr8
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index 2e2bde2..3647ad7 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -63,6 +63,7 @@ static const char * const sun8i_board_dt_compat[] = {
"allwinner,sun8i-a23",
"allwinner,sun8i-a33",
"allwinner,sun8i-a83t",
+ "allwinner,sun8i-h2plus",
"allwinner,sun8i-h3",
NULL,
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Icenowy Zheng @ 2016-11-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162421.800-1-icenowy@aosc.xyz>
Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
Add a device tree file for it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Changes since v2:
- Use generic pinconf binding instead of legacy allwinner pinctrl binding.
- removed uart3, which is not accessible on Orange Pi Zero.
- Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
sun8i-h3.dtsi.
- Removed allwinner,sun8i-h3 compatible.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
2 files changed, 138 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 802a10d..51a1dd7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-a33-sinlinx-sina33.dtb \
sun8i-a83t-allwinner-h8homlet-v2.dtb \
sun8i-a83t-cubietruck-plus.dtb \
+ sun8i-h2plus-orangepi-zero.dtb \
sun8i-h3-bananapi-m2-plus.dtb \
sun8i-h3-nanopi-neo.dtb \
sun8i-h3-orangepi-2.dtb \
diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
new file mode 100644
index 0000000..b428e47
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
@@ -0,0 +1,137 @@
+/*
+ * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
+ *
+ * Based on sun8i-h3-orangepi-one.dts, which is:
+ * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
+ *
+ * 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 free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * 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 "sun8i-h3.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/pinctrl/sun4i-a10.h>
+
+/ {
+ model = "Xunlong Orange Pi Zero";
+ compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
+
+ pwr_led {
+ label = "orangepi:green:pwr";
+ gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ };
+
+ status_led {
+ label = "orangepi:red:status";
+ gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&mmc0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+ vmmc-supply = <®_vcc3v3>;
+ bus-width = <4>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
+ cd-inverted;
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
+
+&pio {
+ leds_opi0: led_pins at 0 {
+ pins = "PA17";
+ function = "gpio_out";
+ };
+};
+
+&r_pio {
+ leds_r_opi0: led_pins at 0 {
+ pins = "PL10";
+ function = "gpio_out";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "disabled";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins>;
+ status = "disabled";
+};
+
+&usbphy {
+ /* USB VBUS is always on */
+ status = "okay";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: sunxi: enable SDIO Wi-Fi on Orange Pi Zero
From: Icenowy Zheng @ 2016-11-21 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121162421.800-1-icenowy@aosc.xyz>
There's a Allwinner's XR819 SDIO Wi-Fi module soldered on the board of
Orange Pi Zero, which used a dedicated regulator to power.
Add the device tree node of the regulator, the enable gpio (with
mmc-pwrseq) and the sdio controller.
There's a out-of-tree driver tested to work with this device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
New patch in the patchset, since a out-of-tree working xradio driver is done.
If there is any problem in this patch, it can be omitted.
arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 42 ++++++++++++++++++++++++
1 file changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
index b428e47..39cac26 100644
--- a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
@@ -79,6 +79,24 @@
gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
};
};
+
+ reg_vcc_wifi: reg_vcc_wifi {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc_wifi_pin_opi0>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc-wifi";
+ enable-active-high;
+ gpio = <&pio 0 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_pwrseq_pin_opi0>;
+ reset-gpios = <&r_pio 0 7 GPIO_ACTIVE_LOW>;
+ };
};
&ehci1 {
@@ -95,6 +113,20 @@
status = "okay";
};
+&mmc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins_a>;
+ vmmc-supply = <®_vcc_wifi>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ bus-width = <4>;
+ non-removable;
+ status = "okay";
+};
+
+&mmc1_pins_a {
+ allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;
+};
+
&ohci1 {
status = "okay";
};
@@ -104,6 +136,11 @@
pins = "PA17";
function = "gpio_out";
};
+
+ vcc_wifi_pin_opi0: vcc_wifi_pin at 0 {
+ allwinner,pins = "PA20";
+ allwinner,function = "gpio_out";
+ };
};
&r_pio {
@@ -111,6 +148,11 @@
pins = "PL10";
function = "gpio_out";
};
+
+ wifi_pwrseq_pin_opi0: wifi_pwrseq_pin at 0 {
+ allwinner,pins = "PL7";
+ allwinner,function = "gpio_out";
+ };
};
&uart0 {
--
2.10.2
^ permalink raw reply related
* [GIT PULL] Second Round of Renesas ARM Based SoC Updates for v4.10
From: Geert Uytterhoeven @ 2016-11-21 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjk=KWifGT7sugpWVjNJSKhmgxg8gN9Cgi=emGrg66z0w@mail.gmail.com>
Hi Olof,
On Mon, Nov 21, 2016 at 5:19 PM, Olof Johansson <olof@lixom.net> wrote:
> On Mon, Nov 21, 2016 at 1:31 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> On Sat, Nov 19, 2016 at 2:28 AM, Olof Johansson <olof@lixom.net> wrote:
>>> On Thu, Nov 17, 2016 at 02:34:25PM +0100, Simon Horman wrote:
>>>> Please consider these second round of Renesas ARM based SoC updates for v4.10.
>>
>>>> * Basic support for r8a7745 SoC
>>>>
>>>> ----------------------------------------------------------------
>>>> Sergei Shtylyov (2):
>>>> ARM: shmobile: r8a7745: basic SoC support
>>>> ARM: shmobile: document SK-RZG1E board
>>>
>>> Is there a reason you're adding a config option per SoC?
>>>
>>> I think you'd be better off not adding these config options, and just adding
>>> support for the SoCs through compatibles (and adding the drivers to defconfigs,
>>> etc).
>>
>> Yes there is a reason: kernel size.
>> The main offenders are the pinctrl tables, which add ca. 20-50 KiB per
>> supported SoC.
>
> So don't turn on that pinctrl driver unless you have that SoC?
The enablement of the pinctrl driver (and the clock driver, FWIW) is controlled
by the SoC Kconfig symbol. If you want support for the SoC, you want the
pinctrl driver, too.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [linux-sunxi] Re: [PATCH] clk: sunxi-ng: sun6i-a31: Enable PLL-MIPI LDOs when ungating it
From: Icenowy Zheng @ 2016-11-21 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121130629.2qp6tvdd5slvl5m6@lukather>
21.11.2016, 21:06, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
> On Fri, Nov 18, 2016 at 03:15:57PM +0800, Chen-Yu Tsai wrote:
>> ?The PLL-MIPI clock is somewhat special as it has its own LDOs which
>> ?need to be turned on for this PLL to actually work and output a clock
>> ?signal.
>>
>> ?Add the 2 LDO enable bits to the gate bits. This fixes issues with
>> ?the TCON not sending vblank interrupts when the tcon and dot clock are
>> ?indirectly clocked from the PLL-MIPI clock.
>>
>> ?Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
>> ?Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> Applied, thanks!
> Maxime
Could you check my patch on A33 which fixes the same problem?
It has been ACKed by Chen-Yu.
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.10
From: Olof Johansson @ 2016-11-21 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121132712.43b5eld2qthi6664@lukather>
HI,
On Mon, Nov 21, 2016 at 5:27 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Olof,
>
> On Fri, Nov 18, 2016 at 04:23:16PM -0800, Olof Johansson wrote:
>> Hi,
>>
>> On Tue, Nov 15, 2016 at 09:41:22PM +0100, Maxime Ripard wrote:
>> > Hi Arnd, Olof,
>> >
>> > Here is our pull request for the next merge window.
>> >
>> > Thanks!
>> > Maxime
>> >
>> > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>> >
>> > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>> >
>> > are available in the git repository at:
>> >
>> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-4.10
>> >
>> > for you to fetch changes up to e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
>> >
>> > ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
>> >
>> > ----------------------------------------------------------------
>> > Allwinner DT additions for 4.10
>> >
>> > The usual bunch of DT additions, but most notably:
>> > - A31 DRM driver
>> > - A31 audio codec
>> > - WiFi for the A80-Based boards and the CHIP
>> > - Support for the NextThing Co CHIP Pro (the first board with NAND
>> > enabled)
>> > - New boards: NanoPi M1,
>> >
>> [...]
>>
>> > Maxime Ripard (16):
>> > ARM: sun5i: a13-olinuxino: Enable VGA bridge
>> > ARM: gr8: Add the UART3
>> > ARM: gr8: Fix typo in the i2s mclk pin group
>> > ARM: gr8: Add missing pwm channel 1 pin
>> > ARM: gr8: Add UART2 pins
>> > ARM: gr8: Add UART3 pins
>> > ARM: gr8: Add CHIP Pro support
>> > ARM: sun5i: chip: Enable Wi-Fi SDIO chip
>> > ARM: sun5i: Rename A10s pins
>> > ARM: sun5i: Add SPI2 pins
>> > ARM: sun5i: Add RGB 565 LCD pins
>> > ARM: sun5i: chip: Add optional buses
>> > ARM: gr8: evb: Enable SPDIF
>> > ARM: gr8: evb: Add i2s codec
>> > ARM: sun8i: sina33: Enable USB gadget
>> > ARM: sunxi: Add the missing clocks to the pinctrl nodes
>> >
>> [...]
>>
>> > arch/arm/boot/dts/Makefile | 1 +
>> > arch/arm/boot/dts/ntc-gr8-chip-pro.dts | 266 +++++++++++++++++++++
>> > arch/arm/boot/dts/ntc-gr8-evb.dts | 33 +++
>> > arch/arm/boot/dts/ntc-gr8.dtsi | 47 +++-
>> > arch/arm/boot/dts/sun4i-a10.dtsi | 3 +-
>>
>> NTC isn't the SoC manufacturer, and we try to keep the prefixes down to
>> manufacturer to keep the namespace a little more manageable, even if
>> we never got subdirectories setup as on arm64.
>>
>> I think this should probably be sun4i-a10-gr8 or sun4i-r8-gr8 as prefix?
>
> The users really expect a SoC from Nextthing, it's always been
> marketed that way, the marking on the SoC also says so, etc. The fact
> that it's been a design in cooperation with Allwinner, and that the
> design is based on some earlier family is an implementation detail,
> and I'd really like not for it to have the sun5i prefix, it's just
> confusing.
I don't care so much about what's printed on the top of the package, I
care a lot more about what's on the insides. We've got a long
tradition of not renaming things randomly when companies get acquired
or renames themselves, and I think that same spirit is applicable
here.
Calling it an SoC is inaccurate as well, it's really a
system-in-package. It's just a new way to integrate an SoC into a
module to build boards out of. Compare to Octavo OSD335x, for example.
System-in-package solutions are going to get more and more common, and
it's going to become really chaotic if we expect to use the prefix of
the company custom-ordering the package for each and every one of
them.
> And the ntc prefix has been asked for during the reviews...
Having a link to that requeset/email would be helpful if you try to
use it as an argument.
-Olof
^ 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