Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Joao Pinto @ 2017-01-17 11:23 UTC (permalink / raw)
  To: Lukasz Majewski, Joao Pinto
  Cc: Kishon Vijay Abraham I, jingoohan1@gmail.com, Bjorn Helgaas,
	Rob Herring, Mark Rutland, linux-omap, linux-pci, devicetree,
	linux-kernel
In-Reply-To: <4b18d08a-c2cc-3c32-35ed-8f4a759ef235@synopsys.com>

Às 10:43 AM de 1/17/2017, Joao Pinto escreveu:
> 
> Hi Lukasz,
> 
> Às 9:44 PM de 1/16/2017, Lukasz Majewski escreveu:
>> Hi Joao,
>>
>>>
>>> Hi,
>>>
>>> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>>> + Joao, Jingoo
>>>>
>>>> Hi,
>>>>
>>>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
>>>>> Hi Kishon,
>>>>>
>>>>>> Hi Łukasz,
>>>>>>
>>>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>>>>>> Hi Kishon,
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>>>>>
>>>>>>>>> This patch changes the speed explicitly on dra7 based devices
>>>>>>>>> when proper device tree attribute is defined for the PCIe
>>>>>>>>> controller.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>>>>>
>>>>>>>> Bjorn has already queued a patch to do the same thing
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e= 
>>>>>>>
>>>>>>> It seems like Bjorn only modifies CAP registers.
>>>>>>
>>>>>> The patch also modifies the LNKCTL2 register.
>>>>>>>
>>>>>>> He also needs to change register with 0x080C offset to actually
>>>>>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>>>>>
>>>>>> This bit is used to initiate speed change (after the link is
>>>>>> initialized in GEN1). Resetting the bit (like what you have done
>>>>>> here) prevents speed change.
>>>>>
>>>>> This is strange, but e2e advised me to do things as I did in the
>>>>> patch to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
>>>>>
>>>>> Link:
>>>>> [1]
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e= 
>>>>>
>>>>> Both patches modify 0x5180 007C register to set GEN1 capability
>>>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
>>>>>
>>>>> The problem is with second register (in your patch):
>>>>>
>>>>> From SPRUHZ6G TRM:
>>>>>
>>>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
>>>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>>>>>   description in TRM
>>>>>
>>>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
>>>>> default /reset value.
>>>>
>>>> The default value is 0x2 (or else none of the cards would have
>>>> enumerated in GEN2)
>>>>>
>>>>>
>>>>> Could you clarify which way to _force_ PCIe GEN1 operation is
>>>>> correct? Mine shows differences in lspci output (as posted in [1]).
>>>>
>>>> You'll see the difference even with the patch in Bjorn's tree ;-)
>>>>
>>>> I think these are 2 different approaches to keep the link at GEN1.
>>>> Joao or Jingoo, do you have any suggestion here?
>>>
>>> I studied the Databook,
>>
>> Could you reveal which databook do you have in mind? Is that the TRM for
>> AM5728?
> 
> I checked the Designware PCIe Databook, since it is based on this IP.
> 
>>
>>> and both approaches seem to be right,
>>> dependently of the Core configuration and setup.
>>>
>>> The standard manual speed change sequence is:
>>> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
>>
>> Do you mean TRGT_LINK_SPEED @ 0x5180 00A0 ?
> 
> Correct.
> 
>>
>>> b) Clear "Directed Speed Change"
>>
>> CFG_DIRECTED_SPEED_CHANGE @ 0x5180 080C 
> 
> Correct.
> 
>>
>>> c) Set "Directed Speed Change"
>>>
>>> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is the
>>> default value), it will execute LTSSM to initiate speed change to
>>> Gen2 or Gen3, after link is started in Gen1, and then the bit is
>>> automatically cleared.
>>
>> Ok, so with default settings (after reset) we do have Gen1 speed link
>> and when we enable LTSSM (with LTSSM_EN bit setting) we negotiate to
>> Gen2/Gen3.
> 
> Yes, that's the expected behavior. I submited this direct question to R&D and
> will have your doubt answered soon.

According to R&D if you set "Target Link Speed" to Gen1 before setting LTSSM_EN
bit, the controller should stay in GEN1.

> 
>>
>>>
>>> Lukasz is reseting this bit, in order to avoid the LTSSM to be
>>> executed, which is correct. 
>>
>> So with CFG_DIRECTED_SPEED_CHANGE = 0, when I start LTSSM (with
>> LTSSM_EN) the state machine returns immediately and leaves link in the
>> Gen1?
>>
>> The pci-dra7 driver always sets LTSSM_EN bit to start link negotiation.
>>
>>> There is another way to prevent this
>>> automatic speed change, which is to set GEN1 speed before link up
>>> which might be difficult in some setups, so Kishon's also right.
>>>
>>> In my opinion Lukasz approach would be the one that might be more
>>> universal and more "secure".
>>
>> The robustness is the key here since there are some devices, which on
>> particular HW must only work with Gen1 speed. When we start LTSSM state
>> machine and hence start negotiation to Gen2, not always the result of
>> LTSSM is correct and device is properly recognized.
>>
>>>
>>> Joao
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of
>>>>>> hacking the IP register.
>>>>>
>>>>> From the original patch description:
>>>>>
>>>>> "Add support to force Root Complex to work in GEN1 mode if so
>>>>> desired, but don't force GEN1 mode on any board just yet."
>>>>>
>>>>> Are there any (floating around) patches allowing forcing GEN1
>>>>> operation on any board (I would like to reuse/port them to my
>>>>> current solution)?
>>>>
>>>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt
>>>> with the patch in Bjorn's tree.
>>>>
>>>> Thanks
>>>> Kishon
>>>>
>>>
>>
>> Best regards,
>>
>> Lukasz Majewski
>>
>> --
>>
>> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
>> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
>>
> 

^ permalink raw reply

* [PATCH] arm64: dts: marvell: Add DT for MACCHIATOBin board
From: Russell King @ 2017-01-17 11:17 UTC (permalink / raw)
  To: Gregory Clement
  Cc: Rabeeh Khoury, Jon Nettleton, Rob Herring, Mark Rutland,
	Catalin Marinas, Will Deacon, Jason Cooper, Andrew Lunn,
	Sebastian Hesselbarth, devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r

Add a cut-down version of the DTS file for the community board
MACCHIATOBin from SolidRun based on Marvell Armada 8040 SoC to suit
the current mainlined Armada 8040 state.

This brings support for mainly SATA, SPI flash and UART.  The USB
descriptions are included but are not tested in this form due to the
lack of mainline GPIO.

Signed-off-by: Konstantin Porotchkin <kostap-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Acked-by: Rabeeh Khoury <rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org>
Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
---
This is derived from a version from Marvell, but severly cut down,
cleaned up, re-organised and added to to suit mainline kernels.  The
only common parts are the header comment, top level model and compatible
strings, the rest has been changed by me in some way.

I'm planning to submit further patches as the mainline Armada 8k support
moves forward.

This is submitted with Rabeeh's confirmation and ack that he (as Solid
Run's CTO) is happy for this to be upstreamed.

Note - the license text is rather "interesting" but matches that which
is already on other ARM64 Marvell-based platforms.  I suspect someone at
Free Electrons needs to talk to Marvell to correct the "library" thing,
and clear up the "GPLv2" vs "GPLv2+" confusion in there.

 arch/arm64/boot/dts/marvell/Makefile              |   1 +
 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts | 138 ++++++++++++++++++++++
 2 files changed, 139 insertions(+)
 create mode 100644 arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts

diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
index 1690883b931a..3e6ce6c15a74 100644
--- a/arch/arm64/boot/dts/marvell/Makefile
+++ b/arch/arm64/boot/dts/marvell/Makefile
@@ -7,6 +7,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-3720-espressobin.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-7040-db.dtb
 dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-db.dtb
+dtb-$(CONFIG_ARCH_MVEBU) += armada-8040-mcbin.dtb
 
 always		:= $(dtb-y)
 subdir-y	:= $(dts-dirs)
diff --git a/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
new file mode 100644
index 000000000000..b7298429ffa1
--- /dev/null
+++ b/arch/arm64/boot/dts/marvell/armada-8040-mcbin.dts
@@ -0,0 +1,138 @@
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPLv2 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 library 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 library 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.
+ */
+
+/*
+ * Device Tree file for MACCHIATOBin Armada 8040 community board platform
+ */
+
+#include "armada-8040.dtsi"
+
+/ {
+	model = "Marvell 8040 MACHIATOBin";
+	compatible = "marvell,armada8040-mcbin", "marvell,armada8040",
+			"marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+	memory@00000000 {
+		device_type = "memory";
+		reg = <0x0 0x0 0x0 0x80000000>;
+	};
+
+	/* Regulator labels correspond with schematics */
+	v_3_3: regulator-3-3v {
+		compatible = "regulator-fixed";
+		regulator-name = "v_3_3";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		regulator-always-on;
+		status = "okay";
+	};
+
+	v_vddo_h: regulator-1-8v {
+		compatible = "regulator-fixed";
+		regulator-name = "v_vddo_h";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		regulator-always-on;
+		status = "okay";
+	};
+
+	v_5v0_usb3_hst_vbus: regulator-usb3-vbus0 {
+		compatible = "regulator-fixed";
+		regulator-name = "v_5v0_usb3_hst_vbus";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		/* actually GPIO controlled, but 8k has no GPIO support yet */
+		regulator-always-on;
+		status = "okay";
+	};
+
+	usb3h0_phy: usb3_phy0 {
+		compatible = "usb-nop-xceiv";
+		vcc-supply = <&v_5v0_usb3_hst_vbus>;
+	};
+};
+
+&uart0 {
+	status = "okay";
+};
+
+&cpm_i2c0 {
+	clock-frequency = <100000>;
+	status = "okay";
+};
+
+&cpm_sata0 {
+	/* CPM Lane 0 - U29 */
+	status = "okay";
+};
+
+&cpm_usb3_0 {
+	/* J38? - USB2.0 only */
+	status = "okay";
+};
+
+&cpm_usb3_1 {
+	/* J38? - USB2.0 only */
+	status = "okay";
+};
+
+&cps_sata0 {
+	/* CPS Lane 1 - U32 */
+	/* CPS Lane 3 - U31 */
+	status = "okay";
+};
+
+&cps_spi1 {
+	status = "okay";
+
+	spi-flash@0 {
+		compatible = "st,w25q32";
+		spi-max-frequency = <50000000>;
+		reg = <0>;
+	};
+};
+
+&cps_usb3_0 {
+	/* CPS Lane 2 - CON7 */
+	usb-phy = <&usb3h0_phy>;
+	status = "okay";
+};
-- 
2.7.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 v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Mark Rutland @ 2017-01-17 11:13 UTC (permalink / raw)
  To: AKASHI Takahiro, catalin.marinas, will.deacon, robh+dt,
	james.morse, geoff, bauerman, dyoung, kexec, linux-arm-kernel,
	devicetree
In-Reply-To: <20170116082505.GL20972@linaro.org>

On Mon, Jan 16, 2017 at 05:25:07PM +0900, AKASHI Takahiro wrote:
> On Fri, Jan 13, 2017 at 11:17:56AM +0000, Mark Rutland wrote:
> > On Fri, Jan 13, 2017 at 06:13:49PM +0900, AKASHI Takahiro wrote:
> > > On Thu, Jan 12, 2017 at 03:39:45PM +0000, Mark Rutland wrote:

> > > > arm64 we should either ensure that /proc/iomem is consistently usable
> > > > (and have userspace consistently use it), or we should expose a new file
> > > > specifically to expose this information.
> > > 
> > > The thing that I had in my mind when adding this property is that
> > > /proc/iomem would be obsolete in the future, then we should have
> > > an alternative in hand.
> > 
> > Ok.
> > 
> > My disagreement is with using the DT as a channel to convey information
> > from the kernel to userspace.
> > 
> > I'm more than happy for a new file or other mechanism to express this
> > information. For example, we could add
> > /sys/kernel/kexec_crash_{base,size} or similar.
> 
> It may make sense because /sys/kernel/kexec_crash_size already exists,
> so why not kexec_crash_base?
> My concern, however, is that this kind of interface might prevent us from
> allowing multiple regions to be reserved for crash dump kernel in the future.
> (There is an assumption that we have only one region at least on arm64 though.)

Ok.

If we need to handle that, we should also update the description of
linux,usable-memory-range to allow multiple entries (and probably
s/range/ranges).

Thanks,
Mark.

^ permalink raw reply

* RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Jerry Huang @ 2017-01-17 11:08 UTC (permalink / raw)
  To: Felipe Balbi, Rob Herring
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	catalin.marinas@arm.com, linux-usb@vger.kernel.org,
	will.deacon@arm.com, linux@armlinux.org.uk,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <8737gikls0.fsf@linux.intel.com>


> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@kernel.org]
> Sent: Tuesday, January 17, 2017 6:45 PM
> To: Jerry Huang <jerry.huang@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: mark.rutland@arm.com; catalin.marinas@arm.com;
> will.deacon@arm.com; linux@armlinux.org.uk; devicetree@vger.kernel.org;
> linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
> type-adjustment" for INCR burst type
> 
> 
> Hi,
> 
> Jerry Huang <jerry.huang@nxp.com> writes:
> 
> <snip>
> 
> >> >> So, I think we still need two vaue to specify INCRBrstEna and
> >> >> INCRx burst type.
> >> > Hi, Balbi,
> >> > It seems there is no feedback for my comment, so these patches can
> >> > be
> >> accepted?
> >>
> >> probably not, we need to really understand what information we need
> >> so it can be described properly. The last thing we want is
> >> unnecessary DT properties.
> >>
> >> It seems to me that we can extrapolate INCRBrstEna based on which
> >> burst modes are enabled. If only 0 is passed, then that bit should be
> >> 1, if 0 and any other size is passed, then that bit should be 0, no?
> > Hi, Balbi,
> > Below is the definition for this property,
> > snps,incr-burst-type-adjustment = <x>, <y>
> > x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
> >     0 - INCRX burst mode (not enable INCRBrstEna)
> >     1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> > y: the burst length
> >
> > 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> > it) , we select one of
> > INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> > value through "y")to set the fix burst length controller supported.
> >
> > For example:
> >
> > 	snps,incr-burst-type-adjustment = <0>, <16>
> >
> > driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> > Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
> >
> > 2> if x = 1: means INCRBrstEna enabled, we select one of
> > INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> > through "y") to set the burst length, and controller will use any
> > length less than or equal to that we selected.
> >
> > For example:
> >
> > 	snps,incr-burst-type-adjustment = <1>, <32>
> >
> > driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> > Enabled), controller will use any burst length less than (such as 4,
> > 8, 16 byte) or equal to 32 byte to transfer data.
> >
> > Therefore, I think this two fileds are needed. Do you think about it?
> 
> no, I don't think two values are needed, because first value can be
> extrapolated from the second. Something like this:
> 
> 	snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;
> 
> This is basically telling us that we can support anything in this list. So
> INCRBrstEna should be set to 1.
> 
> If DT, on the other hand, says:
> 
> 	snps,incr-burst-type-adjustment = <32>;
> 
> this means that we can only support INCR32, so INCRBrstEna should be
> cleared to 0.
Got it, I will try this mode.
Thanks a lot, Balbi,

^ permalink raw reply

* [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs
From: Uwe Kleine-König @ 2017-01-17 11:03 UTC (permalink / raw)
  To: Masahiko Iwamoto, Jagan Teki, Marek Vasut, Cyrille Pitchen
  Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	kernel-bIcnvbaLZ9MEGnE8C9+IrQ, Rafał Miłecki,
	Geert Uytterhoeven, Mark Rutland,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <480df61d-c949-b3b0-61a4-d9db17f09e7d-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>

The MR25 family doesn't support JEDEC, so they need explicit mentioning
in the list of supported spi IDs. This makes it possible to add these
using for example:

	compatible = "everspin,mr25h40";

There was already an entry for mr25h256. Move that one out of the "keep
for compatibility" section and put in a new group for Everspin MRAMs.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
Changes since (implicit) v1:

 - use Kib instead of kib

Changes since v2:

 - update dt docs
 - handle already existing mr25h256 in m25p_ids[]

Thanks to Cyrille for catching these.

 Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
 drivers/mtd/devices/m25p80.c                            | 6 +++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
index 2c91c03e7eb0..3e920ec5c4d3 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
@@ -14,6 +14,8 @@ Required properties:
                  at25df641
                  at26df081a
                  mr25h256
+                 mr25h10
+                 mr25h40
                  mx25l4005a
                  mx25l1606e
                  mx25l6405d
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 9cf7fcd28034..0e2d3a64651a 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -288,7 +288,6 @@ static const struct spi_device_id m25p_ids[] = {
 	 * should be kept for backward compatibility.
 	 */
 	{"at25df321a"},	{"at25df641"},	{"at26df081a"},
-	{"mr25h256"},
 	{"mx25l4005a"},	{"mx25l1606e"},	{"mx25l6405d"},	{"mx25l12805d"},
 	{"mx25l25635e"},{"mx66l51235l"},
 	{"n25q064"},	{"n25q128a11"},	{"n25q128a13"},	{"n25q512a"},
@@ -305,6 +304,11 @@ static const struct spi_device_id m25p_ids[] = {
 	{"m25p40-nonjedec"},	{"m25p80-nonjedec"},	{"m25p16-nonjedec"},
 	{"m25p32-nonjedec"},	{"m25p64-nonjedec"},	{"m25p128-nonjedec"},
 
+	/* Everspin MRAMs (non-JEDEC) */
+	{ "mr25h256" }, /* 256 Kib, 40 MHz */
+	{ "mr25h10" },  /*   1 Mib, 40 MHz */
+	{ "mr25h40" },  /*   4 Mib, 40 MHz */
+
 	{ },
 };
 MODULE_DEVICE_TABLE(spi, m25p_ids);
-- 
2.11.0

--
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 v2 11/11] drm/rockchip/dsi: fix insufficient bandwidth of some panel
From: John Keeping @ 2017-01-17 10:54 UTC (permalink / raw)
  To: Chris Zhong
  Cc: dianders-F7+t8E8rja9g9hUCZPvPmw, tfiga-F7+t8E8rja9g9hUCZPvPmw,
	heiko-4mtYJXux2i+zQB+pC5nmwQ, yzq-TNX95d0MmH7DzftRWevZcw,
	mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, galak-sgV2jX0FEOL9JmXXK+q4OQ,
	pawel.moll-5wv7dgnIgG8, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
	David Airlie, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
	linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Yao
In-Reply-To: <587DE489.2010004-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

On Tue, 17 Jan 2017 17:31:53 +0800, Chris Zhong wrote:

> On 01/16/2017 08:44 PM, John Keeping wrote:
> > On Mon, 16 Jan 2017 18:08:31 +0800, Chris Zhong wrote:
> >  
> >> Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
> >> for some panel, it will cause the screen display is not normal, so
> >> increases the badnwidth to 1 / 0.8.
> >>
> >> Signed-off-by: Chris Zhong <zyw-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> >>
> >> ---
> >>
> >>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 4 ++--
> >>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> index 9dfa73d..5a973fe 100644
> >> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> @@ -501,8 +501,8 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi)
> >>   
> >>   	mpclk = DIV_ROUND_UP(dsi->mode->clock, MSEC_PER_SEC);
> >>   	if (mpclk) {
> >> -		/* take 1 / 0.9, since mbps must big than bandwidth of RGB */
> >> -		tmp = mpclk * (bpp / dsi->lanes) * 10 / 9;
> >> +		/* take 1 / 0.8, since mbps must big than bandwidth of RGB */
> >> +		tmp = mpclk * (bpp / dsi->lanes) * 10 / 8;  
> > This and patch 9 are just hacking around the underlying problem in order
> > to make particular panels work.  I'm pretty sure the actual issue is the
> > use of hardcoded values when configuring the PHY, since the PHY
> > parameters are specified in clock cycles but the MIPI spec requires
> > absolute time durations.
> >
> > I posted a series addressing this a while ago, although I screwed up
> > sending it so some patches were included twice and since no one
> > expressed any interest I didn't post a cleaned up version.
> >
> > The relevant patch is here:
> >
> > https://patchwork.kernel.org/patch/9340193/  
> 
> Thanks very much, your patches are very useful for me. It looks your 
> method is correct.
> And I am very confused why Mark Yao and me did not receive your patches 
> before,
> although we have subscribed the <linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>.
> 
> In addition, could you tell me which device ware you testing with these 
> mipi patches.
> I going to test them these day.

I'm using RK3288 and I tested my patches with three different MIPI
displays, two of which require commands to be sent in order to set up
the panel.

Thanks for testing the patches.


John
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* Re: [PATCH 1/5] ARM: OMAP2+: omap_hwmod: Add support for earlycon
From: Mark Rutland @ 2017-01-17 10:47 UTC (permalink / raw)
  To: Lokesh Vutla
  Cc: Tony Lindgren, Linux OMAP Mailing List, Device Tree Mailing List,
	Rob Herring, Tero Kristo, Sekhar Nori, Vignesh R, Nishanth Menon
In-Reply-To: <20170117040336.21700-2-lokeshvutla-l0cyMroinI0@public.gmane.org>

On Tue, Jan 17, 2017 at 09:33:32AM +0530, Lokesh Vutla wrote:
> Hwmod core tries to reset and idles each IP that is registered with hwmod.
> In case of earlycon, that specific uart IP cannot be reset or keep it in
> idle state else earlycon hangs once hwmod resets that uart IP. So add support
> to not reset uart that is being used as earlycon only if CONFIG_SERIAL_EARLYCON
> is enabled.

> +	np = of_find_node_by_path("/chosen");
> +	if (!np)
> +		np = of_find_node_by_path("/chosen@0");

I think you can drop the second case here. There shouldn't be an "@0" on
a chosen node; core code handles that only to cater for some legacy
(PPC?) DTBs, and I don't beleive it's necessary for OMAP.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Felipe Balbi @ 2017-01-17 10:45 UTC (permalink / raw)
  To: Jerry Huang, Rob Herring
  Cc: mark.rutland@arm.com, catalin.marinas@arm.com,
	will.deacon@arm.com, linux@armlinux.org.uk,
	devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <DB5PR0401MB1813548526D3C8D34B9CCE52FE7C0@DB5PR0401MB1813.eurprd04.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]


Hi,

Jerry Huang <jerry.huang@nxp.com> writes:

<snip>

>> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
>> >> burst type.
>> > Hi, Balbi,
>> > It seems there is no feedback for my comment, so these patches can be
>> accepted?
>> 
>> probably not, we need to really understand what information we need so it
>> can be described properly. The last thing we want is unnecessary DT
>> properties.
>> 
>> It seems to me that we can extrapolate INCRBrstEna based on which burst
>> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
>> other size is passed, then that bit should be 0, no?
> Hi, Balbi,
> Below is the definition for this property,
> snps,incr-burst-type-adjustment = <x>, <y>
> x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
>     0 - INCRX burst mode (not enable INCRBrstEna)
>     1 - INCR (undefined length) burst mode (enable INCRBrstEna)
> y: the burst length
>
> 1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear
> it) , we select one of
> INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this
> value through "y")to set the fix burst length controller supported.
>
> For example:
>
> 	snps,incr-burst-type-adjustment = <0>, <16>
>
> driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type
> Enabled), controller will use INCR16 (with 16 bytes) to transfer data.
>
> 2> if x = 1: means INCRBrstEna enabled, we select one of
> INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value
> through "y") to set the burst length, and controller will use any
> length less than or equal to that we selected.
>
> For example:
>
> 	snps,incr-burst-type-adjustment = <1>, <32>
>
> driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type
> Enabled), controller will use any burst length less than (such as 4,
> 8, 16 byte) or equal to 32 byte to transfer data.
>
> Therefore, I think this two fileds are needed. Do you think about it?

no, I don't think two values are needed, because first value can be
extrapolated from the second. Something like this:

	snps,incr-burst-type-adjustment = <4>, <8>, <16>, <32>;

This is basically telling us that we can support anything in this
list. So INCRBrstEna should be set to 1.

If DT, on the other hand, says:

	snps,incr-burst-type-adjustment = <32>;

this means that we can only support INCR32, so INCRBrstEna should be
cleared to 0.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

^ permalink raw reply

* Re: [PATCH] rtc: stm32: fix comparison warnings
From: Alexandre Belloni @ 2017-01-17 10:43 UTC (permalink / raw)
  To: Amelie Delaunay
  Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
	Alexandre Torgue, Russell King, rtc-linux, devicetree,
	linux-arm-kernel, linux-kernel, Gabriel Fernandez
In-Reply-To: <1484561333-12087-1-git-send-email-amelie.delaunay@st.com>

On 16/01/2017 at 11:08:53 +0100, Amelie Delaunay wrote :
> This patches fixes comparison between signed and unsigned values as it
> could produce an incorrect result when the signed value is converted to
> unsigned:
> 
> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_valid_alrm':
> drivers/rtc/rtc-stm32.c:404:21: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
>   if ((((tm->tm_year > cur_year) &&
> ...
> 
> It also fixes comparison always true or false due to the fact that unsigned
> value is compared against zero with >= or <:
> 
> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_init':
> drivers/rtc/rtc-stm32.c:514:35: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
>   for (pred_a = pred_a_max; pred_a >= 0; pred_a-- ) {
> 
> drivers/rtc/rtc-stm32.c:530:44: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
>      (rate - ((pred_a + 1) * (pred_s + 1)) < 0) ?
> 
> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
>  drivers/rtc/rtc-stm32.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

^ permalink raw reply

* Re: [PATCH] rtc: stm32: use 0 instead of ~PWR_CR_DBP in regmap_update_bits
From: Alexandre Belloni @ 2017-01-17 10:43 UTC (permalink / raw)
  To: Amelie Delaunay
  Cc: Alessandro Zummo, Rob Herring, Mark Rutland, Maxime Coquelin,
	Alexandre Torgue, Russell King, rtc-linux-/JYPxA39Uh5TLH3MbocFFw,
	devicetree-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gabriel Fernandez
In-Reply-To: <1484557058-21601-1-git-send-email-amelie.delaunay-qxv4g6HH51o@public.gmane.org>

On 16/01/2017 at 09:57:38 +0100, Amelie Delaunay wrote :
> Using the ~ operator on a BIT() constant results in a large 'unsigned long'
> constant that won't fit into an 'unsigned int' function argument on 64-bit
> architectures, resulting in a harmless build warning in x86 allmodconfig:
> 
> drivers/rtc/rtc-stm32.c: In function 'stm32_rtc_probe':
> drivers/rtc/rtc-stm32.c:651:51: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
>   regmap_update_bits(rtc->dbp, PWR_CR, PWR_CR_DBP, ~PWR_CR_DBP);
> 
> As PWR_CR_DBP mask prevents other bits to be cleared, replace all
> ~PWR_CR_DBP by 0.
> 
> Fixes: 4e64350f42e2 ("rtc: add STM32 RTC driver")
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Signed-off-by: Amelie Delaunay <amelie.delaunay-qxv4g6HH51o@public.gmane.org>
> ---
Applied, thanks.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply

* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Joao Pinto @ 2017-01-17 10:43 UTC (permalink / raw)
  To: Lukasz Majewski, Joao Pinto
  Cc: Kishon Vijay Abraham I, jingoohan1@gmail.com, Bjorn Helgaas,
	Rob Herring, Mark Rutland, linux-omap, linux-pci, devicetree,
	linux-kernel
In-Reply-To: <20170116224437.67b5a0c5@jawa>


Hi Lukasz,

Às 9:44 PM de 1/16/2017, Lukasz Majewski escreveu:
> Hi Joao,
> 
>>
>> Hi,
>>
>> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>> + Joao, Jingoo
>>>
>>> Hi,
>>>
>>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
>>>> Hi Kishon,
>>>>
>>>>> Hi Łukasz,
>>>>>
>>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>>>>> Hi Kishon,
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>>>>
>>>>>>>> This patch changes the speed explicitly on dra7 based devices
>>>>>>>> when proper device tree attribute is defined for the PCIe
>>>>>>>> controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>>>>
>>>>>>> Bjorn has already queued a patch to do the same thing
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e= 
>>>>>>
>>>>>> It seems like Bjorn only modifies CAP registers.
>>>>>
>>>>> The patch also modifies the LNKCTL2 register.
>>>>>>
>>>>>> He also needs to change register with 0x080C offset to actually
>>>>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>>>>
>>>>> This bit is used to initiate speed change (after the link is
>>>>> initialized in GEN1). Resetting the bit (like what you have done
>>>>> here) prevents speed change.
>>>>
>>>> This is strange, but e2e advised me to do things as I did in the
>>>> patch to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
>>>>
>>>> Link:
>>>> [1]
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e= 
>>>>
>>>> Both patches modify 0x5180 007C register to set GEN1 capability
>>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
>>>>
>>>> The problem is with second register (in your patch):
>>>>
>>>> From SPRUHZ6G TRM:
>>>>
>>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
>>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>>>>   description in TRM
>>>>
>>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
>>>> default /reset value.
>>>
>>> The default value is 0x2 (or else none of the cards would have
>>> enumerated in GEN2)
>>>>
>>>>
>>>> Could you clarify which way to _force_ PCIe GEN1 operation is
>>>> correct? Mine shows differences in lspci output (as posted in [1]).
>>>
>>> You'll see the difference even with the patch in Bjorn's tree ;-)
>>>
>>> I think these are 2 different approaches to keep the link at GEN1.
>>> Joao or Jingoo, do you have any suggestion here?
>>
>> I studied the Databook,
> 
> Could you reveal which databook do you have in mind? Is that the TRM for
> AM5728?

I checked the Designware PCIe Databook, since it is based on this IP.

> 
>> and both approaches seem to be right,
>> dependently of the Core configuration and setup.
>>
>> The standard manual speed change sequence is:
>> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
> 
> Do you mean TRGT_LINK_SPEED @ 0x5180 00A0 ?

Correct.

> 
>> b) Clear "Directed Speed Change"
> 
> CFG_DIRECTED_SPEED_CHANGE @ 0x5180 080C 

Correct.

> 
>> c) Set "Directed Speed Change"
>>
>> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is the
>> default value), it will execute LTSSM to initiate speed change to
>> Gen2 or Gen3, after link is started in Gen1, and then the bit is
>> automatically cleared.
> 
> Ok, so with default settings (after reset) we do have Gen1 speed link
> and when we enable LTSSM (with LTSSM_EN bit setting) we negotiate to
> Gen2/Gen3.

Yes, that's the expected behavior. I submited this direct question to R&D and
will have your doubt answered soon.

> 
>>
>> Lukasz is reseting this bit, in order to avoid the LTSSM to be
>> executed, which is correct. 
> 
> So with CFG_DIRECTED_SPEED_CHANGE = 0, when I start LTSSM (with
> LTSSM_EN) the state machine returns immediately and leaves link in the
> Gen1?
> 
> The pci-dra7 driver always sets LTSSM_EN bit to start link negotiation.
> 
>> There is another way to prevent this
>> automatic speed change, which is to set GEN1 speed before link up
>> which might be difficult in some setups, so Kishon's also right.
>>
>> In my opinion Lukasz approach would be the one that might be more
>> universal and more "secure".
> 
> The robustness is the key here since there are some devices, which on
> particular HW must only work with Gen1 speed. When we start LTSSM state
> machine and hence start negotiation to Gen2, not always the result of
> LTSSM is correct and device is properly recognized.
> 
>>
>> Joao
>>
>>
>>>
>>>>
>>>>>
>>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of
>>>>> hacking the IP register.
>>>>
>>>> From the original patch description:
>>>>
>>>> "Add support to force Root Complex to work in GEN1 mode if so
>>>> desired, but don't force GEN1 mode on any board just yet."
>>>>
>>>> Are there any (floating around) patches allowing forcing GEN1
>>>> operation on any board (I would like to reuse/port them to my
>>>> current solution)?
>>>
>>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt
>>> with the patch in Bjorn's tree.
>>>
>>> Thanks
>>> Kishon
>>>
>>
> 
> Best regards,
> 
> Lukasz Majewski
> 
> --
> 
> DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> 

^ permalink raw reply

* RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-type-adjustment" for INCR burst type
From: Jerry Huang @ 2017-01-17 10:37 UTC (permalink / raw)
  To: Felipe Balbi, Rob Herring
  Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	catalin.marinas@arm.com, linux-usb@vger.kernel.org,
	will.deacon@arm.com, linux@armlinux.org.uk,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
In-Reply-To: <87tw8zo0c0.fsf@linux.intel.com>



> -----Original Message-----
> From: Felipe Balbi [mailto:balbi@kernel.org]
> Sent: Monday, January 16, 2017 4:50 PM
> To: Jerry Huang <jerry.huang@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: mark.rutland@arm.com; catalin.marinas@arm.com;
> will.deacon@arm.com; linux@armlinux.org.uk; devicetree@vger.kernel.org;
> linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: RE: [PATCH v3 2/3] USB3/DWC3: Add property "snps, incr-burst-
> type-adjustment" for INCR burst type
> 
> 
> Hi,
> 
> Jerry Huang <jerry.huang@nxp.com> writes:
> >> > On Thu, Dec 22, 2016 at 8:52 PM, Jerry Huang <jerry.huang@nxp.com>
> >> wrote:
> >> > > Hi, Rob,
> >> > >> -----Original Message-----
> >> > >> From: Rob Herring [mailto:robh@kernel.org]
> >> > >> Sent: Friday, December 23, 2016 2:45 AM
> >> > >> To: Jerry Huang <jerry.huang@nxp.com>
> >> > >> Cc: balbi@kernel.org; mark.rutland@arm.com;
> >> > >> catalin.marinas@arm.com; will.deacon@arm.com;
> >> > >> linux@armlinux.org.uk; devicetree@vger.kernel.org;
> >> > >> linux-usb@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> > >> linux-arm- kernel@lists.infradead.org
> >> > >> Subject: Re: [PATCH v3 2/3] USB3/DWC3: Add property "snps,
> >> > >> incr-burst- type-adjustment" for INCR burst type
> >> > >>
> >> > >> On Mon, Dec 19, 2016 at 05:25:53PM +0800, Changming Huang wrote:
> >> > >> > New property "snps,incr-burst-type-adjustment = <x>, <y>" for
> >> > >> > USB3.0
> >> > >> DWC3.
> >> > >> > Field "x": 1/0 - undefined length INCR burst type enable or
> >> > >> > not; Field
> >> > >> > "y": INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 burst
> >> type.
> >> > >> >
> >> > >> > While enabling undefined length INCR burst type and INCR16
> >> > >> > burst type, get better write performance on NXP Layerscape
> platform:
> >> > >> > around 3% improvement (from 364MB/s to 375MB/s).
> >> > >> >
> >> > >> > Signed-off-by: Changming Huang <jerry.huang@nxp.com>
> >> > >> > ---
> >> > >> > Changes in v3:
> >> > >> >   - add new property for INCR burst in usb node.
> >> > >> >
> >> > >> >  Documentation/devicetree/bindings/usb/dwc3.txt |    5 +++++
> >> > >> >  arch/arm/boot/dts/ls1021a.dtsi                 |    1 +
> >> > >> >  arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi |    3 +++
> >> > >> >  arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi |    2 ++
> >> > >> >  4 files changed, 11 insertions(+)
> >> > >> >
> >> > >> > diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > index e3e6983..8c405a3 100644
> >> > >> > --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> >> > >> > @@ -55,6 +55,10 @@ Optional properties:
> >> > >> >     fladj_30mhz_sdbnd signal is invalid or incorrect.
> >> > >> >
> >> > >> >   - <DEPRECATED> tx-fifo-resize: determines if the FIFO *has*
> >> > >> > to be
> >> > >> reallocated.
> >> > >> > + - snps,incr-burst-type-adjustment: Value for INCR burst type
> >> > >> > + of
> >> > >> GSBUSCFG0
> >> > >> > +   register, undefined length INCR burst type enable and INCRx
> type.
> >> > >> > +   First field is for undefined length INCR burst type enable or not.
> >> > >> > +   Second field is for largest INCRx type enabled.
> >> > >>
> >> > >> Why do you need the first field? Is the 2nd field used if the 1st is 0?
> >> > >> If not, then just use the presence of the property to enable or not.
> >> > > The first field is one switch.
> >> > > When it is 1, means undefined length INCR burst type enabled, we
> >> > > can use
> >> > any length less than or equal to the largest-enabled burst length
> >> > of INCR4/8/16/32/64/128/256.
> >> > > When it is zero, means INCRx burst mode enabled, we can use one
> >> > > fixed
> >> > burst length of 1/4/8/16/32/64/128/256 byte.
> >> > > So, the 2nd field is used if the 1st is 0, we need to select one
> >> > > largest burst
> >> > length the USB controller can support.
> >> > > If we don't want to change the value of this register (use the
> >> > > default value),
> >> > we don't need to add this property to usb node.
> >> >
> >> > Just make this a single value with 0 meaning INCR and 4/8/16/etc
> >> > being
> >> INCRx.
> >> Maybe, I didn't describe it clearly.
> >> According to DWC3 spec, the value "0" of field INCRBrstEna means
> >> INCRx burst mode, 1 means INCR burst mode.
> >> Regardless of the value of INCRBrstEna [bit0], we need to modify the
> >> other field bit[1,2,3,4,5,6,7] to one INCR burst type  for the platform
> supported.
> >> Ad you mentioned, if we just use a single value with 0 meaning INCR
> >> and 4/8/16/etc being INCRx.
> >> I understand totally that when it is none-zero, we can use it for
> >> INCR burst mode.
> >> Then, when it is 0, how to select the INCRx value?
> >>
> >> So, I think we still need two vaue to specify INCRBrstEna and INCRx
> >> burst type.
> > Hi, Balbi,
> > It seems there is no feedback for my comment, so these patches can be
> accepted?
> 
> probably not, we need to really understand what information we need so it
> can be described properly. The last thing we want is unnecessary DT
> properties.
> 
> It seems to me that we can extrapolate INCRBrstEna based on which burst
> modes are enabled. If only 0 is passed, then that bit should be 1, if 0 and any
> other size is passed, then that bit should be 0, no?
Hi, Balbi,
Below is the definition for this property,
snps,incr-burst-type-adjustment = <x>, <y>
x: Undefined Length INCR Burst Type Enable (INCRBrstEna)
    0 - INCRX burst mode (not enable INCRBrstEna)
    1 - INCR (undefined length) burst mode (enable INCRBrstEna)
y: the burst length

1> if x = 0: means INCRBrstEna not enabled, set bit0 to zero (or clear it) , we select one of INCR1/INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value through "y")to set the fix burst length controller supported.
For example:
snps,incr-burst-type-adjustment = <0>, <16>
driver will set bit0 to zero and set bit3 to 1 (INCR16 Burst Type Enabled), controller will use INCR16 (with 16 bytes) to transfer data.

2> if x = 1: means INCRBrstEna enabled, we select one of INCR4/INCR8/INCR16/INCR32/INCR64/INCR128/INCR256 (pass this value through "y") to set the burst length, and controller will use any length less than or equal to that we selected.
For example:
snps,incr-burst-type-adjustment = <1>, <32>
driver will set bit0 to 1 and set bit4 to 1 (INCR32 Burst Type Enabled), controller will use any burst length less than (such as 4, 8, 16 byte) or equal to 32 byte to transfer data.

Therefore, I think this two fileds are needed. Do you think about it?

^ permalink raw reply

* [PATCH 2/2] arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
From: Pankaj Dubey @ 2017-01-17 10:32 UTC (permalink / raw)
  To: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, kgene-DgEjT+Ai2ygdnm+yROfE0A,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, sanath-Sze3O3UU22JBDgjK7y7TUQ,
	javier-JPH+aEBZ4P+UEJcrhfAQsw,
	gautamvivek1987-Re5JQEeQqe8AvxtiuMwx3w, Pankaj Dubey
In-Reply-To: <1484649143-19423-1-git-send-email-pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Adding fixed voltage regulators for Vbus and Vbus-boost required
by USB 3.0 DRD controller on Exynos7-espresso board.

Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Vivek Gautam <gautamvivek1987-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 44 +++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 9cf73cf..68f3a51 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -33,6 +33,29 @@
 		device_type = "memory";
 		reg = <0x0 0x40000000 0x0 0xC0000000>;
 	};
+
+	usb30_vbus_reg: regulator-usb30 {
+		compatible = "regulator-fixed";
+		regulator-name = "VBUS_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gph1 1 0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb30_vbus_en>;
+		enable-active-high;
+	};
+
+	usb3drd_boost_5v: regulator-usb3drd-boost {
+		compatible = "regulator-fixed";
+		regulator-name = "VUSB_VBUS_5V";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		gpio = <&gpf4 1 0>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb3drd_boost_en>;
+		enable-active-high;
+	};
+
 };
 
 &fin_pll {
@@ -366,3 +389,24 @@
 	vqmmc-supply = <&ldo2_reg>;
 	disable-wp;
 };
+
+&usbdrd_phy {
+	vbus-supply = <&usb30_vbus_reg>;
+	vbus-boost-supply = <&usb3drd_boost_5v>;
+};
+
+&pinctrl_bus1 {
+	usb30_vbus_en: usb30-vbus-en {
+		samsung,pins = "gph1-1";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <0>;
+	};
+
+	usb3drd_boost_en: usb3drd-boost-en {
+		samsung,pins = "gpf4-1";
+		samsung,pin-function = <1>;
+		samsung,pin-pud = <0>;
+		samsung,pin-drv = <0>;
+	};
+};
-- 
2.7.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 1/2] arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
From: Pankaj Dubey @ 2017-01-17 10:32 UTC (permalink / raw)
  To: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	devicetree-u79uwXL29TY76Z2rM5mHXA
  Cc: krzk-DgEjT+Ai2ygdnm+yROfE0A, kgene-DgEjT+Ai2ygdnm+yROfE0A,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, sanath-Sze3O3UU22JBDgjK7y7TUQ,
	javier-JPH+aEBZ4P+UEJcrhfAQsw,
	gautamvivek1987-Re5JQEeQqe8AvxtiuMwx3w, Pankaj Dubey
In-Reply-To: <1484649143-19423-1-git-send-email-pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Add USB 3.0 DRD controller device node, with its clock
and phy information to enable the same on Exynos7.

Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Vivek Gautam <gautamvivek1987-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi | 34 +++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 9080a11..a2d8d11 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -603,6 +603,40 @@
 				#include "exynos7-trip-points.dtsi"
 			};
 		};
+
+		usbdrd_phy: phy@15500000 {
+			compatible = "samsung,exynos7-usbdrd-phy";
+			reg = <0x15500000 0x100>;
+			clocks = <&clock_fsys0 ACLK_USBDRD300>,
+			       <&clock_fsys0 OSCCLK_PHY_CLKOUT_USB30_PHY>,
+			       <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PIPE_PCLK_USER>,
+			       <&clock_fsys0 PHYCLK_USBDRD300_UDRD30_PHYCLK_USER>,
+			       <&clock_fsys0 SCLK_USBDRD300_REFCLK>;
+			clock-names = "phy", "ref", "phy_pipe",
+				"phy_utmi", "itp";
+			samsung,pmu-syscon = <&pmu_system_controller>;
+			#phy-cells = <1>;
+		};
+
+		usbdrd3: usb@15400000 {
+			compatible = "samsung,exynos7-dwusb3";
+			clocks = <&clock_fsys0 ACLK_USBDRD300>,
+			       <&clock_fsys0 SCLK_USBDRD300_SUSPENDCLK>,
+			       <&clock_fsys0 ACLK_AXIUS_USBDRD30X_FSYS0X>;
+			clock-names = "usbdrd30", "usbdrd30_susp_clk",
+				"usbdrd30_axius_clk";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges;
+
+			dwc3 {
+				compatible = "snps,dwc3";
+				reg = <0x15400000 0x10000>;
+				interrupts = <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+				phys = <&usbdrd_phy 0>, <&usbdrd_phy 1>;
+				phy-names = "usb2-phy", "usb3-phy";
+			};
+		};
 	};
 };
 
-- 
2.7.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 0/2] Add USB DRD 3.0 device node for Exynos7
From: Pankaj Dubey @ 2017-01-17 10:32 UTC (permalink / raw)
  To: linux-samsung-soc, linux-arm-kernel, devicetree
  Cc: krzk, kgene, robh+dt, sanath, javier, gautamvivek1987,
	Pankaj Dubey
In-Reply-To: <CGME20170117102937epcas5p1f49119a781097709b6bd6d29730c0c0f@epcas5p1.samsung.com>

This patch series adds USB 3.0 DRD device node for Exynos7 and 
required Vbus and Vbus-boost support for espresso dev boards.
These patches are part of patch series [1] earlier submitted by Vivek

[1]: https://lkml.org/lkml/2014/11/21/247

While other patches in these series got merged, DTS related change were
left. I have prepared and tested these patches on top of krzk/for-next.


Pankaj Dubey (2):
  arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
  arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost

 arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 44 +++++++++++++++++++++++++
 arch/arm64/boot/dts/exynos/exynos7.dtsi         | 34 +++++++++++++++++++
 2 files changed, 78 insertions(+)

-- 
2.7.4

^ permalink raw reply

* Re: [PATCH v2] mtd: spi-nor: add dt support for Everspin MRAMs
From: Cyrille Pitchen @ 2017-01-17 10:32 UTC (permalink / raw)
  To: Uwe Kleine-König, Masahiko Iwamoto, Jagan Teki, Marek Vasut
  Cc: Mark Rutland, devicetree, Rafał Miłecki,
	Geert Uytterhoeven, kernel, linux-mtd
In-Reply-To: <aa0fc197-c320-6d1c-a892-6e272e16366a@atmel.com>

Le 17/01/2017 à 10:48, Cyrille Pitchen a écrit :
> Hi,
> 
> Le 16/01/2017 à 22:00, Uwe Kleine-König a écrit :
>> The MR25 family doesn't support JEDEC, so they need explicit mentioning
>> in the list of supported spi IDs. This makes it possible to add these
>> using for example:
>>
>> 	compatible = "everspin,mr25h40";
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>> Changes since (implicit) v1:
>>  - use Kib instead of kib
>>
>>  drivers/mtd/devices/m25p80.c | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index 9cf7fcd28034..aa50bd96de3a 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -305,6 +305,11 @@ static const struct spi_device_id m25p_ids[] = {
>>  	{"m25p40-nonjedec"},	{"m25p80-nonjedec"},	{"m25p16-nonjedec"},
>>  	{"m25p32-nonjedec"},	{"m25p64-nonjedec"},	{"m25p128-nonjedec"},
>>  
>> +	/* Everspin MRAMs */
>> +	{ "mr25h256" }, /* 256 Kib, 40 MHz */
> 
> There is already a "mr25h256" entry in the m25p_ids[] array.
> It's a good idea to regroup everspin memories but it might be better to
> reuse the existing entry.
> 
> The previous entry is between "at25df321a", ... and "mx25l4005a" so it
> doesn't appear in your patch.
> 
>> +	{ "mr25h10" },  /*   1 Mib, 40 MHz */
>> +	{ "mr25h40" },  /*   4 Mib, 40 MHz */
>> +

Also if you add new entries, I think you should update the "Supported chip
names" section in Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt:

"mr25h256" is already there.

Best regards,

Cyrille


>>  	{ },
>>  };
>>  MODULE_DEVICE_TABLE(spi, m25p_ids);
>>
> 


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply

* Re: [PATCH v2 2/2] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-17 10:28 UTC (permalink / raw)
  To: Jonathan Cameron
  Cc: knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
	pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA, ktsai-GubuWUlQtMwciDkP5Hr2oA,
	wsa-z923LK4zBo2bacvFa/9K2g, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
	pawel.moll-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
	ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
	galak-sgV2jX0FEOL9JmXXK+q4OQ, trivial-DgEjT+Ai2ygdnm+yROfE0A,
	mranostay-Re5JQEeQqe8AvxtiuMwx3w,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d05cce62-4362-b249-f49f-58eed2316ddb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>

Hi Jonathan,

[...]

> >> For the range, it's an interesting one.  Again the term range could
> >> mean too many things within the wider ABI. We need to make it more
> >> specific.
> >>
> >> Actually reading the datasheet, I think this is fundamentally about the
> >> maximum sampling frequency rather than directly about the range.
> >> The only reason you'd reduce the range is to speed that up. It doesn't
> >> improve the resolution, the device simply answers quicker.
> >>
> >> So I'd support this as sampling_frequency.  You could then use
> >> the the iio_info_mask_*_available and relevant callback to provide
> >> info on what it then restricts the possible output values to
> >> (rather than controlling it directly).
> >>
> > 
> > By changing the range one cannot influence the sampling frequency directly. I
> > have seen on the oszilloscope that the telegrams arrive almost at the same time
> > with different settings of range and the same gain.
> > 
> > Only if the gain is also adjusted the sensor works faster and a higher frequency
> > can be used. But the gain is also used to adjust the sensitivity of the sensor. 
> That's rather weird and not what the datasheet suggests. Ah well.
> > 
> > What about calling it "sensor_domain" or "sensor_max_range"?
> hmm. Not sure - propose that with appropriate Docs and we can think more on it.
> > 
> > 

I made a mistake in the earlier mentioned measurement which i have to correct:

The telegrams arrive faster with a smaller range and the same gain. 

But we cannot use the sensor at a higher frequency if we are not adjusting the
gain of the sensor as well. This is because of echos of the former cycle which
are still around. And this setting of the gain depends on the surrounding where
the sensor is used. So in the driver we cannot estimate it.

Therefore i'll send out the next version with the attribute name
"sensor_max_range" together with documentation as proposal.

Andreas

-- 

^ permalink raw reply

* Re: [PATCH 1/2] dt-bindings: gpu: Add Mali Utgard bindings
From: Neil Armstrong @ 2017-01-17 10:22 UTC (permalink / raw)
  To: Maxime Ripard, Krzysztof Kozlowski
  Cc: Mark Rutland, devicetree, Heiko Stuebner, Boris Brezillon,
	Kevin Hilman, Linus Walleij, Javier Martinez Canillas,
	Chen-Yu Tsai, Rob Herring, Alexandre Belloni, Kukjin Kim,
	Matthias Brugger, Thomas Petazzoni, Carlo Caione,
	Antoine Ténart, linux-arm-kernel
In-Reply-To: <20170117093813.mxp2hgoxbgske6ru@lukather>


[-- Attachment #1.1.1: Type: text/plain, Size: 1441 bytes --]

On 01/17/2017 10:38 AM, Maxime Ripard wrote:
> Hi,
> 
> On Mon, Jan 16, 2017 at 08:49:06PM +0200, Krzysztof Kozlowski wrote:
>> On Mon, Jan 16, 2017 at 02:24:23PM +0100, Maxime Ripard wrote:
>>> The ARM Mali Utgard GPU family is embedded into a number of SoCs from
>>> Allwinner, Amlogic, Mediatek or Rockchip.
>>>
>>> Add a binding for the GPU of that family.
>>>
>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>> ---
>>>  .../devicetree/bindings/gpu/arm,mali-utgard.txt    | 76 ++++++++++++++++++++++
>>>  1 file changed, 76 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
>>
>> Do you have a driver in kernel which will implement these bindings?
> 
> No, but we have bindings for out-of-tree drivers already.
> 
>> Defining them for out-of-tree driver does not bring any benefits
>> (3rd party driver will not respect them anyway).
> 
> You could see it the other way around too. The out-of-tree drivers
> don't respect it at the moment because there's no binding to respect.
> 
> And at least for us, we definitely plan on doing that.
> 
> Maxime

Hi Maxime, Krzysztof,

We hope this will be accepted so it will solve the same issue we have on Amlogic SoCs
and all the other mali powered SoCs.

Having mainline bindings will forcre out-of-tree driver to respect those bindings
and remove a dts out-of-tree patch aswell.

Neil


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH] pcie: ti: Provide patch to force GEN1 PCIe operation
From: Joao Pinto @ 2017-01-17 10:19 UTC (permalink / raw)
  To: Kishon Vijay Abraham I, Joao Pinto, Lukasz Majewski,
	jingoohan1@gmail.com
  Cc: Bjorn Helgaas, Rob Herring, Mark Rutland, linux-omap, linux-pci,
	devicetree, linux-kernel
In-Reply-To: <587DAD37.5030201@ti.com>


Hi,

Às 5:35 AM de 1/17/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
> 
> On Monday 16 January 2017 10:31 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> Às 10:13 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>> + Joao, Jingoo
>>>
>>> Hi,
>>>
>>> On Monday 16 January 2017 03:01 PM, Lukasz Majewski wrote:
>>>> Hi Kishon,
>>>>
>>>>> Hi Łukasz,
>>>>>
>>>>> On Monday 16 January 2017 12:19 PM, Lukasz Majewski wrote:
>>>>>> Hi Kishon,
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Sunday 15 January 2017 06:49 PM, Lukasz Majewski wrote:
>>>>>>>> Some devices (due to e.g. bad PCIe signal integrity) require to
>>>>>>>> run with forced GEN1 speed on PCIe bus.
>>>>>>>>
>>>>>>>> This patch changes the speed explicitly on dra7 based devices when
>>>>>>>> proper device tree attribute is defined for the PCIe controller.
>>>>>>>>
>>>>>>>> Signed-off-by: Lukasz Majewski <lukma@denx.de>
>>>>>>>
>>>>>>> Bjorn has already queued a patch to do the same thing
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.kernel.org_cgit_linux_kernel_git_helgaas_pci.git_log_-3Fh-3Dpci_host-2Ddra7xx&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=E8zk1CbKxGH-f3fw_WpXxFU-A8BLkgA8NusCaxk1SvA&e= 
>>>>>>
>>>>>> It seems like Bjorn only modifies CAP registers.
>>>>>
>>>>> The patch also modifies the LNKCTL2 register.
>>>>>>
>>>>>> He also needs to change register with 0x080C offset to actually
>>>>>> ( PCIECTRL_PL_WIDTH_SPEED_CTL )
>>>>>
>>>>> This bit is used to initiate speed change (after the link is
>>>>> initialized in GEN1). Resetting the bit (like what you have done
>>>>> here) prevents speed change.
>>>>
>>>> This is strange, but e2e advised me to do things as I did in the patch
>>>> to _force_ GEN1 operation on PCIe2 port [1] (AM5728)
>>>>
>>>> Link:
>>>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__e2e.ti.com_support_arm_sitara-5Farm_f_791_t_566421&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=zD82T5n4WcL7Ga-NSY2NI7KE75xQ99hN-mW2yX46wQk&s=uXLwglyRYqKpwp1JSxkOWmKpQ2wjfhgofpm8DCfquNw&e= 
>>>>
>>>> Both patches modify 0x5180 007C register to set GEN1 capability
>>>> (PCI_EXP_LNKCAP_SLS_2_5GB)
>>>>
>>>> The problem is with second register (in your patch):
>>>>
>>>> From SPRUHZ6G TRM:
>>>>
>>>> PCIECTRL_EP_DBICS_LNK_CAS_2 (0x5180 00A0)
>>>> - TRGT_LINK_SPEED (Reset 0x1) - "Target Link Speed" - no more
>>>>   description in TRM
>>>>
>>>> It is set to PCI_EXP_LNKCAP_SLS_2_5GB = 0x1, which is the same as
>>>> default /reset value.
>>>
>>> The default value is 0x2 (or else none of the cards would have enumerated in GEN2)
>>>>
>>>>
>>>> Could you clarify which way to _force_ PCIe GEN1 operation is correct?
>>>> Mine shows differences in lspci output (as posted in [1]).
>>>
>>> You'll see the difference even with the patch in Bjorn's tree ;-)
>>>
>>> I think these are 2 different approaches to keep the link at GEN1. Joao or
>>> Jingoo, do you have any suggestion here?
>>
>> I studied the Databook, and both approaches seem to be right, dependently of the
>> Core configuration and setup.
>>
>> The standard manual speed change sequence is:
>> a) Write to PCIE_CAP_TARGET_LINK_SPEED (indicating desired speed)
>> b) Clear "Directed Speed Change"
>> c) Set "Directed Speed Change"
>>
>> If "Directed Speed Change" is set (DEFAULT_GEN2_SPEED_CHANGE is the default
>> value), it will execute LTSSM to initiate speed change to Gen2 or Gen3, after
>> link is started in Gen1, and then the bit is automatically cleared.
>>
>> Lukasz is reseting this bit, in order to avoid the LTSSM to be executed, which
>> is correct. There is another way to prevent this automatic speed change, which
>> is to set GEN1 speed before link up which might be difficult in some setups, so
>> Kishon's also right.
> 
> Just for my understanding, why do you think this will be difficult in some setups?

It depends on the way some PCI Cores are configured.

>>
>> In my opinion Lukasz approach would be the one that might be more universal and
>> more "secure".
> 
> IMHO setting link control in the standard PCIe header space should be more
> universal. I'm not sure about the secure part though.

When I said secure, I misleaded you, sorry. I meant more robust.

> 
> Thanks
> Kishon
>>
>> Joao
>>
>>
>>>
>>>>
>>>>>
>>>>> IMO the better way is to set the LNKCTL2 to GEN1 instead of hacking
>>>>> the IP register.
>>>>
>>>> From the original patch description:
>>>>
>>>> "Add support to force Root Complex to work in GEN1 mode if so desired,
>>>> but don't force GEN1 mode on any board just yet."
>>>>
>>>> Are there any (floating around) patches allowing forcing GEN1 operation
>>>> on any board (I would like to reuse/port them to my current solution)?
>>>
>>> For setting to GEN1 mode, "max-link-speed" should be set to 1 in dt with the
>>> patch in Bjorn's tree.
>>>
>>> Thanks
>>> Kishon
>>>
>>

^ permalink raw reply

* Re: [PATCH v5 4/5] dt: bindings: i2c-mux-pca954x: Add documentation for nxp,irq-mask-enable
From: Peter Rosin @ 2017-01-17 10:14 UTC (permalink / raw)
  To: Phil Reid, wsa-z923LK4zBo2bacvFa/9K2g,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <96f3cc0e-9c73-4af4-f072-5a1aeceb67af-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>

On 2017-01-17 10:43, Peter Rosin wrote:
> On 2017-01-17 10:28, Phil Reid wrote:
>> On 17/01/2017 16:57, Peter Rosin wrote:
>>> On 2017-01-17 09:00, Phil Reid wrote:
>>>> Unfortunately some hardware device will assert their irq line immediately
>>>> on power on and provide no mechanism to mask the irq. As the i2c muxes
>>>> provide no method to mask irq line this provides a work around by keeping
>>>> the parent irq masked until enough device drivers have loaded to service
>>>> all pending interrupts.
>>>>
>>>> For example the the ltc1760 assert its SMBALERT irq immediately on power
>>>> on. With two ltc1760 attached to bus 0 & 1 on a pca954x mux when the first
>>>> device is registered irq are enabled and fire continuously as the second
>>>> device driver has not yet loaded. Setting this parameter to <1 1> will
>>>> delay the irq being enabled until both devices are ready.
>>>
>> G'day Peter,
>>
>>
>>> Hang on, does this suggestion I made make any sense at all? Maybe it does,
>>> but does the pca954x driver even get notified of any but the first irq client
>>> that unmasks interrupts on a mux segment? How can it count the number of
>>> active irq clients if not?
>>
>> Good question.
>>
>> So what I did to test is setup my 2 ltc1760s to use the same irq on the pca954x.
>> Using the latest patch series.
>>
>> Adding a log message into the irq_unmask function got the following.
>> 	dev_err(&data->client->dev, "irq_unmask %d %x %d", pos, data->irq_mask, data->irq_enabled);
>>
>> dmesg | grep irq_unmask
>> [    4.392098] pca954x 4-0070: irq_unmask 0 1 1
>>
>>
>> But Looks like both got registered ok to the same irq.
>> cat /proc/interrupts
>> 161:          0          0  i2c-mux-pca954x   0 Level     15-000a, 16-000a
>>
>> So from this testing, it doesn't look like it gets called multiple times.
> 
> As I suspected, thanks for verifying!
> 
>> So back to the bitmask for the dt do you think.
> 
> Looking at kernel/irq/chip.c:irq_enable (and struct irq_chip docs), I get the
> feeling that if you provide the irq_enable operation (and maybe irq_disable too?),
> that might get us more info?

No, I no longer think that. I think we need to get at the irq descriptor "depth".
But that feels like poking at the wrong level. Crap.

And to answer the question if I think we should go back to a dt bitmask, then
no I do not think that. The array describes what we want to do, it's the linux
implementation that gives us difficulties. Agreed?

>> I think the interrupt enablelogic is correct now.
>>
>>>
>>> I'm truly sorry for the trouble I'm causing by not just saying how it should
>>> be done from the start, but I feel like I've been thrown in at the deep end
>>> when it comes to interrupt controllers...
>>
>> No problem. I'm learning a couple things as we go.
>> Should help me out on other drivers :)
> 
> Yes, I'm also picking up a few bits here and there...
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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] reset: uniphier: add compatible string for LD11 SD-reset block
From: Philipp Zabel @ 2017-01-17 10:07 UTC (permalink / raw)
  To: Masahiro Yamada
  Cc: Mark Rutland, devicetree, Rob Herring, linux-kernel,
	linux-arm-kernel
In-Reply-To: <1484420686-28911-1-git-send-email-yamada.masahiro@socionext.com>

On Sun, 2017-01-15 at 04:04 +0900, Masahiro Yamada wrote:
> The LD11 SoC is equipped with not only MIO-reset but also SD-reset
> for controlling RST_n pin of the eMMC device.
> 
> Update the binding document and remove unneeded "." from each line
> in itemization.
> 
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Applied, thank you.

regards
Philipp

> ---
> 
>  .../devicetree/bindings/reset/uniphier-reset.txt   | 47 +++++++++++-----------
>  drivers/reset/reset-uniphier.c                     |  4 ++
>  2 files changed, 28 insertions(+), 23 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> index 5020524..83ab0f5 100644
> --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt
> @@ -6,14 +6,14 @@ System reset
>  
>  Required properties:
>  - compatible: should be one of the following:
> -    "socionext,uniphier-sld3-reset" - for sLD3 SoC.
> -    "socionext,uniphier-ld4-reset"  - for LD4 SoC.
> -    "socionext,uniphier-pro4-reset" - for Pro4 SoC.
> -    "socionext,uniphier-sld8-reset" - for sLD8 SoC.
> -    "socionext,uniphier-pro5-reset" - for Pro5 SoC.
> -    "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC.
> -    "socionext,uniphier-ld11-reset" - for LD11 SoC.
> -    "socionext,uniphier-ld20-reset" - for LD20 SoC.
> +    "socionext,uniphier-sld3-reset" - for sLD3 SoC
> +    "socionext,uniphier-ld4-reset"  - for LD4 SoC
> +    "socionext,uniphier-pro4-reset" - for Pro4 SoC
> +    "socionext,uniphier-sld8-reset" - for sLD8 SoC
> +    "socionext,uniphier-pro5-reset" - for Pro5 SoC
> +    "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC
> +    "socionext,uniphier-ld11-reset" - for LD11 SoC
> +    "socionext,uniphier-ld20-reset" - for LD20 SoC
>  - #reset-cells: should be 1.
>  
>  Example:
> @@ -37,14 +37,15 @@ Media I/O (MIO) reset, SD reset
>  
>  Required properties:
>  - compatible: should be one of the following:
> -    "socionext,uniphier-sld3-mio-reset" - for sLD3 SoC.
> -    "socionext,uniphier-ld4-mio-reset"  - for LD4 SoC.
> -    "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC.
> -    "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC.
> -    "socionext,uniphier-pro5-sd-reset"  - for Pro5 SoC.
> -    "socionext,uniphier-pxs2-sd-reset"  - for PXs2/LD6b SoC.
> -    "socionext,uniphier-ld11-mio-reset" - for LD11 SoC.
> -    "socionext,uniphier-ld20-sd-reset"  - for LD20 SoC.
> +    "socionext,uniphier-sld3-mio-reset" - for sLD3 SoC
> +    "socionext,uniphier-ld4-mio-reset"  - for LD4 SoC
> +    "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC
> +    "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC
> +    "socionext,uniphier-pro5-sd-reset"  - for Pro5 SoC
> +    "socionext,uniphier-pxs2-sd-reset"  - for PXs2/LD6b SoC
> +    "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO)
> +    "socionext,uniphier-ld11-sd-reset"  - for LD11 SoC (SD)
> +    "socionext,uniphier-ld20-sd-reset"  - for LD20 SoC
>  - #reset-cells: should be 1.
>  
>  Example:
> @@ -68,13 +69,13 @@ Peripheral reset
>  
>  Required properties:
>  - compatible: should be one of the following:
> -    "socionext,uniphier-ld4-peri-reset"  - for LD4 SoC.
> -    "socionext,uniphier-pro4-peri-reset" - for Pro4 SoC.
> -    "socionext,uniphier-sld8-peri-reset" - for sLD8 SoC.
> -    "socionext,uniphier-pro5-peri-reset" - for Pro5 SoC.
> -    "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC.
> -    "socionext,uniphier-ld11-peri-reset" - for LD11 SoC.
> -    "socionext,uniphier-ld20-peri-reset" - for LD20 SoC.
> +    "socionext,uniphier-ld4-peri-reset"  - for LD4 SoC
> +    "socionext,uniphier-pro4-peri-reset" - for Pro4 SoC
> +    "socionext,uniphier-sld8-peri-reset" - for sLD8 SoC
> +    "socionext,uniphier-pro5-peri-reset" - for Pro5 SoC
> +    "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC
> +    "socionext,uniphier-ld11-peri-reset" - for LD11 SoC
> +    "socionext,uniphier-ld20-peri-reset" - for LD20 SoC
>  - #reset-cells: should be 1.
>  
>  Example:
> diff --git a/drivers/reset/reset-uniphier.c b/drivers/reset/reset-uniphier.c
> index 968c3ae..9c11be3 100644
> --- a/drivers/reset/reset-uniphier.c
> +++ b/drivers/reset/reset-uniphier.c
> @@ -390,6 +390,10 @@ static const struct of_device_id uniphier_reset_match[] = {
>  		.data = uniphier_sld3_mio_reset_data,
>  	},
>  	{
> +		.compatible = "socionext,uniphier-ld11-sd-reset",
> +		.data = uniphier_pro5_sd_reset_data,
> +	},
> +	{
>  		.compatible = "socionext,uniphier-ld20-sd-reset",
>  		.data = uniphier_pro5_sd_reset_data,
>  	},

^ permalink raw reply

* Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Geert Uytterhoeven @ 2017-01-17 10:00 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: Chris Brandt, Simon Horman, Magnus Damm, Rob Herring,
	Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux-Renesas, Wolfram Sang
In-Reply-To: <20170117095702.GA1930@katana>

Hi Wolfram,

On Tue, Jan 17, 2017 at 10:57 AM, Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org> wrote:
>> If we handle them as one, won't we miss card detect events due to the
>> card detect clock being disabled while SDHI is idle?
>
> You mean this?
>
> 1208         /*
> 1209          * While using internal tmio hardware logic for card detection, we need
> 1210          * to ensure it stays powered for it to work.
> 1211          */
> 1212         if (_host->native_hotplug)
> 1213                 pm_runtime_get_noresume(&pdev->dev);

OK. So that will keep the core module clock running.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.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
--
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] ARM: dts: r7s72100: fix sdhi clock define
From: Wolfram Sang @ 2017-01-17  9:57 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Chris Brandt, Simon Horman, Magnus Damm, Rob Herring,
	Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Linux-Renesas, Wolfram Sang
In-Reply-To: <CAMuHMdViHu7i_Lqk80toWrW=KsR49hodGnTd-Cpq35ts9gNgyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]


> If we handle them as one, won't we miss card detect events due to the
> card detect clock being disabled while SDHI is idle?

You mean this?

1208         /*
1209          * While using internal tmio hardware logic for card detection, we need
1210          * to ensure it stays powered for it to work.
1211          */
1212         if (_host->native_hotplug)
1213                 pm_runtime_get_noresume(&pdev->dev);



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply

* Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define
From: Geert Uytterhoeven @ 2017-01-17  9:52 UTC (permalink / raw)
  To: Wolfram Sang
  Cc: Chris Brandt, Simon Horman, Magnus Damm, Rob Herring,
	Mark Rutland, devicetree@vger.kernel.org, Linux-Renesas,
	Wolfram Sang
In-Reply-To: <20170117094529.GC1487@katana>

Hi Wolfram,

On Tue, Jan 17, 2017 at 10:45 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>> I have no idea if the SDHI driver disables the module clock when it is
>> idle, but shouldn't the card detect clock be running all the time when the
>> driver is bound to the device?
>
> Yes, it should. And for all instances with just one clock, this means
> this main clock must be running. So, en-/disable functions are all about
> suspend/resume and bind/unbind. (Huh, looks like the unbind part is
> missing, though. Need to look closer).
>
> My take is: either we implement the power saving and handle the cd clock
> seperately. Or we ignore the power saving for now and handle both clocks
> as virtually one, i.e. en-/disable them at the same time.
>
> Doesn't make sense?

If we handle them as one, won't we miss card detect events due to the
card detect clock being disabled while SDHI is idle?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH v2] mtd: spi-nor: add dt support for Everspin MRAMs
From: Cyrille Pitchen @ 2017-01-17  9:48 UTC (permalink / raw)
  To: Uwe Kleine-König, Masahiko Iwamoto, Jagan Teki, Marek Vasut
  Cc: Mark Rutland, devicetree, Rafał Miłecki,
	Geert Uytterhoeven, kernel, linux-mtd
In-Reply-To: <20170116210039.25267-1-u.kleine-koenig@pengutronix.de>

Hi,

Le 16/01/2017 à 22:00, Uwe Kleine-König a écrit :
> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> in the list of supported spi IDs. This makes it possible to add these
> using for example:
> 
> 	compatible = "everspin,mr25h40";
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Changes since (implicit) v1:
>  - use Kib instead of kib
> 
>  drivers/mtd/devices/m25p80.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 9cf7fcd28034..aa50bd96de3a 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -305,6 +305,11 @@ static const struct spi_device_id m25p_ids[] = {
>  	{"m25p40-nonjedec"},	{"m25p80-nonjedec"},	{"m25p16-nonjedec"},
>  	{"m25p32-nonjedec"},	{"m25p64-nonjedec"},	{"m25p128-nonjedec"},
>  
> +	/* Everspin MRAMs */
> +	{ "mr25h256" }, /* 256 Kib, 40 MHz */

There is already a "mr25h256" entry in the m25p_ids[] array.
It's a good idea to regroup everspin memories but it might be better to
reuse the existing entry.

The previous entry is between "at25df321a", ... and "mx25l4005a" so it
doesn't appear in your patch.

> +	{ "mr25h10" },  /*   1 Mib, 40 MHz */
> +	{ "mr25h40" },  /*   4 Mib, 40 MHz */
> +
>  	{ },
>  };
>  MODULE_DEVICE_TABLE(spi, m25p_ids);
> 


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox