* Re: [PATCH 08/13] dt-bindings: mips: Add bindings for Microsemi SoCs
From: Florian Fainelli @ 2017-11-28 19:14 UTC (permalink / raw)
To: Alexandre Belloni, Ralf Baechle
Cc: linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128152643.20463-9-alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On 11/28/2017 07:26 AM, Alexandre Belloni wrote:
> Add bindings for Microsemi SoCs. Currently only Ocelot is supported.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Documentation/devicetree/bindings/mips/mscc.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mips/mscc.txt
>
> diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
> new file mode 100644
> index 000000000000..2c52e76b7142
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mips/mscc.txt
> @@ -0,0 +1,6 @@
> +* Microsemi MIPS CPUs
> +
> +Required properties:
> +- compatible: "brcm,ocelot"
You probably intended to use mscc,ocelot here, right?
--
Florian
--
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 4/4] DTS: Pandora: fix panel compatibility string
From: H. Nikolaus Schaller @ 2017-11-28 18:32 UTC (permalink / raw)
To: Tony Lindgren, Tomi Valkeinen
Cc: Mark Rutland, DTML, linux-fbdev,
Discussions about the Letux Kernel, Bartlomiej Zolnierkiewicz,
David Airlie, dri-devel, Russell King, Rob Herring,
Linux Kernel Mailing List, Julia Lawall, Thierry Reding,
Sean Paul, Laurent Pinchart, Benoît Cousson, kernel,
linux-omap, Linux ARM
In-Reply-To: <20171128161834.GE28152@atomide.com>
Hi,
> Am 28.11.2017 um 17:18 schrieb Tony Lindgren <tony@atomide.com>:
>
> * H. Nikolaus Schaller <hns@goldelico.com> [171128 16:17]:
>> Hi Tony,
>>
>>> Am 28.11.2017 um 17:04 schrieb Tony Lindgren <tony@atomide.com>:
>>>
>>> * H. Nikolaus Schaller <hns@goldelico.com> [171128 15:52]:
>>>> We can remove the unnecessary "omapdss," prefix because
>>>> the omapdrm driver takes care of it when matching with
>>>> the driver table.
>>>
>>> So is this needed as a fix or is this another clean-up?
>>>
>>> So is this is really needed as a fix?
>>
>> Hm. How do you differentiate between "fix" and "cleanup"?
>> Maybe it is more a wording than a content issue...
>>
>> For me it is a "fix" because it is semantically wrong to have
>> a prefix where it is not needed. And "fixing" it changes the
>> compiler output by 8 bytes.
>
> How about let's call it a "typo fix" then? :)
Well, it is not really a typo.
>
>> "Cleanup" would be for me removing whitespace or empty lines
>> or typos in comments.
>>
>>> If this is just clean-up, again, please resend once the driver
>>> changes have cleared.
>>
>> There is no change to the pandora driver involved here. The Pandora
>> panel driver is already correct. Just the DTS has some redundant
>> content which should be removed.
>>
>> So there is no dependency for this patch.
>
> OK please resend separately after the driver changes have merged
> then.
The Pandora driver does not need an update. Only the DTS.
So there is noting to merge or wait for.
Maybe the confusion comes that in both cases (GTA04 and OpenPandora)
there are changes to DTS.
But different ones.
GTA04: change vendor prefix to make it consistent
Pandora: remove redundant (unnecessary and potentially wrong) omapdss, prefix
In addition we have to modify the GTA04 panel to handle the correct
vendor prefix. The Pandora panel already uses the right one.
Anyways, I think it is now Tomi to decide about the panel driver
(vendor prefix) patch 1/4 and 2/4 first. Then we can sort out
the DTS changes (3/4 and 4/4).
BR and thanks,
Nikolaus
^ permalink raw reply
* Re: [PATCH v4] ARM: dts: imx6qdl-nitrogen6x: Add SPI NOR partitions
From: Fabio Estevam @ 2017-11-28 18:14 UTC (permalink / raw)
To: Otavio Salvador
Cc: linux-arm-kernel@lists.infradead.org, Mark Rutland,
devicetree@vger.kernel.org, linux-kernel, Russell King,
Gary Bisson, Rob Herring, Sascha Hauer, Fabio Estevam, Shawn Guo
In-Reply-To: <20171128174924.5149-1-otavio@ossystems.com.br>
On Tue, Nov 28, 2017 at 3:49 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> This adds the partitions definition for the SPI NOR to provide
> backward compatibility with the documented[1] layout used with
> Boundary Devices BSP.
>
> 1. https://boundarydevices.com/boot-flash-access-linux/
>
> It exports to Linux:
>
> mtd0: bootloader
> mtd1: env
> mtd2: splash
>
> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
* [PATCH v4] ARM: dts: imx6qdl-nitrogen6x: Add SPI NOR partitions
From: Otavio Salvador @ 2017-11-28 17:49 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Gary Bisson, Otavio Salvador, Fabio Estevam,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Russell King, Shawn Guo
This adds the partitions definition for the SPI NOR to provide
backward compatibility with the documented[1] layout used with
Boundary Devices BSP.
1. https://boundarydevices.com/boot-flash-access-linux/
It exports to Linux:
mtd0: bootloader
mtd1: env
mtd2: splash
Signed-off-by: Otavio Salvador <otavio-fKevB0iiKLMBZ+LybsDmbA@public.gmane.org>
---
Changes in v4:
- drop lock flag
Changes in v3:
- use lock instead of read-only (Gary Bisson)
Changes in v2:
- rework labels (Fabio Estevam)
- add read-only flags (Fabio Estevam)
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
index 4bdf29169d2a..919b6b7619a4 100644
--- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
@@ -276,6 +276,23 @@
compatible = "sst,sst25vf016b", "jedec,spi-nor";
spi-max-frequency = <20000000>;
reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0x0 0xc0000>;
+ };
+
+ partition@c0000 {
+ label = "env";
+ reg = <0xc0000 0x2000>;
+ };
+
+ partition@c2000 {
+ label = "splash";
+ reg = <0xc2000 0x13e000>;
+ };
};
};
--
2.15.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 v3] ARM: dts: imx6qdl-nitrogen6x: Add SPI NOR partitions
From: Otavio Salvador @ 2017-11-28 17:37 UTC (permalink / raw)
To: Fabio Estevam
Cc: Otavio Salvador, Mark Rutland, devicetree@vger.kernel.org,
linux-kernel, Russell King, Gary Bisson, Rob Herring,
Sascha Hauer, Fabio Estevam, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAOMZO5Dtf6mjWt1wg_5NDUNAe4XZ3jvxu0KC2CaUo0wE7gjaRQ@mail.gmail.com>
Hello Fabio,
On Mon, Nov 27, 2017 at 2:17 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Mon, Nov 27, 2017 at 11:31 AM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> This adds the partitions definition for the SPI NOR to provide
>> backward compatibility with the documented[1] layout used with
>> Boundary Devices BSP.
>>
>> 1. https://boundarydevices.com/boot-flash-access-linux/
>>
>> It exports to Linux:
>>
>> mtd0: bootloader
>> mtd1: env
>> mtd2: splash
>>
>> Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>
> Has this been tested? I mean, have you tested the locking mechanism is
> really working in this SPI NOR flash?
Yes, we tested it here using Linux 4.14 but didn't notice this SPI NOR
does not support the lock.
> As far as I can see the SPI locking mechanism does not need device
> tree properties.
Humm it is confusing, at least for me that am not used to the this. In
any case, I think for now it is better to include the partitions
without read-only and lock as it is convenient to have access to it
from Linux so we adhere the same partition layout used in Boundary's
Linux fork.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
^ permalink raw reply
* Re: [PATCH v3 1/2] dt: bindings: lm3692x: Add bindings for lm3692x LED driver
From: Dan Murphy @ 2017-11-28 17:27 UTC (permalink / raw)
To: Pavel Machek
Cc: Jingoo Han, 'Jacek Anaszewski', robh+dt, mark.rutland,
rpurdie, devicetree, linux-kernel, linux-leds,
'Lee Jones', 'Daniel Thompson'
In-Reply-To: <20171117235811.GA26296@amd>
Pavel
On 11/17/2017 05:58 PM, Pavel Machek wrote:
> Hi!
>
>>>> Well.. if it can control other LEDs than just backlight, I believe it
>>>> can stay in the LED subsystem.
>>>
>>> I also agree with your opinion.
>>
>> I will make the necessary changes for v4.
>
> I'm not sure if you need to make any changes. Just add default trigger
> to the dts and you should be done.
>
Sorry what I meant was changes for the additional v3 comments.
Dan
>> Just a heads up I won't be posting v4 until after the US holiday so you
>> don't think I abandoned everything.
>
> :-)
> Pavel
>
--
------------------
Dan Murphy
^ permalink raw reply
* Re: [PATCH 01/10] genirq: Export irq_set_msi_desc()
From: Manikanta Maddireddy @ 2017-11-28 17:19 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner
Cc: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm
In-Reply-To: <be79bf6f-b24a-6292-5eb1-3bcf97890421@arm.com>
On 28-Nov-17 3:30 PM, Marc Zyngier wrote:
> On 25/11/17 19:41, Manikanta Maddireddy wrote:
>>
>>
>> On 25-Nov-17 5:25 AM, Thomas Gleixner wrote:
>>> On Fri, 24 Nov 2017, Manikanta Maddireddy wrote:
>>>
>>> Please CC the proper mailing list for irq related changes.
>>>
>>>> PCI bus support MSI interrupts, allow PCI host driver to set MSI descriptor
>>>> data for an irq.
>>>
>>> This is not really an explanation why this export is needed.
>>>
>>> Thanks,
>>>
>>> tglx
>>>
>> Updated the commit log with why Tegra PCIe driver is using this function in V2.
>> Please review.
>
> Well, to review it, I would like to be on Cc.
>
> My current position on this is that if you need to export this function,
> then you're using a deprecated API, and you should instead consider
> moving to the generic MSI model, which doesn't need any of this.
>
> I've done that a distant past, but never actually published the patch
> (not tested it):
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/commit/?h=irq/kill-msi-controller&id=83b3602fcee7972b9d549ed729b56ec28de16081
>
> But without seeing the patches, I may be barking up the wrong tree...
>
> Thanks,
>
> M.
>
Hi Mark,
I will drop this change from this series and will take up generic MSI work in the next series of changes for pci-tegra driver.
Even without this change, pci-tegra driver will work fine as a builtin module. So other changes can still be reviewed and
can be considered as initial step for adding LKM support for pci-tegra.
Thanks,
Manikanta
^ permalink raw reply
* [PATCH v1] usb: xhci: allow imod-interval to be configurable
From: Adam Wallis @ 2017-11-28 17:11 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Greg Kroah-Hartman, Rob Herring, Mathias Nyman,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Mark Rutland, Matthias Brugger,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
chunfeng.yun-NuS5LvNUpcJWk0Htik3J/w
Cc: timur-sgV2jX0FEOL9JmXXK+q4OQ
The xHCI driver currently has the IMOD set to 160, which
translates to an IMOD interval of 40,000ns (160 * 250)ns
Commit 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller")
introduced a QUIRK for the MTK platform to adjust this interval to 20,
which translates to an IMOD interval of 5,000ns (20 * 250)ns. This is
due to the fact that the MTK controller IMOD interval is 8 times
as much as defined in xHCI spec.
Instead of adding more quirk bits for additional platforms, this patch
introduces the ability for vendors to set the IMOD_INTERVAL as is
optimal for their platform. By using device_property_read_u32() on
"imod-interval", the IMOD INTERVAL can be specified in nano seconds. If
no interval is specified, the default of 40,000ns (IMOD=160) will be
used.
No bounds checking has been implemented due to the fact that a vendor
may have violated the spec and would need to specify a value outside of
the max 8,000 IRQs/second limit specified in the xHCI spec.
Backwards compatibility is maintained for MTK_HOSTS through the quirk
bit, however, imod_interval should be pushed into device tree at a
future point and this quirk should be removed from xhci_plat_probe
Signed-off-by: Adam Wallis <awallis-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
---
Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
drivers/usb/host/xhci-plat.c | 15 +++++++++++++++
drivers/usb/host/xhci.c | 7 ++-----
drivers/usb/host/xhci.h | 2 ++
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index ae6e484..3998459 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -29,6 +29,7 @@ Optional properties:
- usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
- usb3-lpm-capable: determines if platform is USB3 LPM capable
- quirk-broken-port-ped: set if the controller has broken port disable mechanism
+ - imod-interval: IMOD_INTERVAL in nano-seconds. Default is 40000
Example:
usb@f0931000 {
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 09f164f..f7730c8 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -23,6 +23,7 @@
#include "xhci-plat.h"
#include "xhci-mvebu.h"
#include "xhci-rcar.h"
+#include "xhci-mtk.h"
static struct hc_driver __read_mostly xhci_plat_hc_driver;
@@ -269,6 +270,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (device_property_read_bool(&pdev->dev, "quirk-broken-port-ped"))
xhci->quirks |= XHCI_BROKEN_PORT_PED;
+ /* imod interval in nanoseconds */
+ if (device_property_read_u32(sysdev,
+ "imod-interval", &xhci->imod_interval))
+ xhci->imod_interval = 40000;
+ else if (xhci->quirks & XHCI_MTK_HOST)
+ /*
+ * The increment interval is 8 times as much as that defined in
+ * the xHCI spec on MTK's controller. This is added to provide
+ * backwards compatibility, however, this should be pushed into
+ * the device tree files at some point in the future and
+ * removed from xhci_plat_probe
+ */
+ xhci->imod_interval = 5000;
+
hcd->usb_phy = devm_usb_get_phy_by_phandle(sysdev, "usb-phy", 0);
if (IS_ERR(hcd->usb_phy)) {
ret = PTR_ERR(hcd->usb_phy);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2424d30..6a09311 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -586,11 +586,8 @@ int xhci_run(struct usb_hcd *hcd)
"// Set the interrupt modulation register");
temp = readl(&xhci->ir_set->irq_control);
temp &= ~ER_IRQ_INTERVAL_MASK;
- /*
- * the increment interval is 8 times as much as that defined
- * in xHCI spec on MTK's controller
- */
- temp |= (u32) ((xhci->quirks & XHCI_MTK_HOST) ? 20 : 160);
+ temp |= (u16) (xhci->imod_interval / 250);
+
writel(temp, &xhci->ir_set->irq_control);
/* Set the HCD state before we enable the irqs */
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 99a014a..2a4177b 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1717,6 +1717,8 @@ struct xhci_hcd {
u8 max_interrupters;
u8 max_ports;
u8 isoc_threshold;
+ /* imod_interval in ns (I * 250ns) */
+ u32 imod_interval;
int event_ring_max;
/* 4KB min, 128MB max */
int page_size;
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
From: Ulf Hansson @ 2017-11-28 16:38 UTC (permalink / raw)
To: Viresh Kumar
Cc: Stephen Boyd, Rob Herring, Kevin Hilman, Viresh Kumar,
Nishanth Menon, Rafael Wysocki,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Vincent Guittot,
Rajendra Nayak, Sudeep Holla,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171102090033.GZ4240@vireshk-i7>
On 2 November 2017 at 10:00, Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 02-11-17, 00:15, Stephen Boyd wrote:
>> Sorry I'm not following. We're going to need to have platform
>> specific code that understands platform specific bindings that
>> aren't shoved into the generic OPP bindings.
>
> At least I am not targeting any platform specific binding right now.
> The way I see this to work is:
>
> - We will reuse earlier bindings and allow opp-hz and opp-microvolt to
> contain special values (this patch).
> - Platform specific DT entries will put corner numbers in opp-hz (or
> opp-microvolt) fields.
> - Some platform specific driver (in OPP or genpd) will be used to
> convert OPP into a performance state (corner) value. Now that can
> simply read opp-hz (or opp-microvolt) and return its value.
Since the "operating-points-v2" phandle(s) belongs in the power-domain
controller device node, which anyway is being parsed by the genpd SoC
specific driver, I assume it makes sense to start the initialization
from there. Unless there is something that prevents that, of course.
Then whatever library/helper functions we need for parse and create
the OPP tables, can be provided to the OPP framework and the OPP OF
library.
> - OPP core will request for a performance state (code is already
> merged for that).
>
> And so there is no platform specific binding here. Do you want to do
> this differently ?
This makes sense to me!
Also, the SoC (QCOM) specific genpd driver is free to use the
terminology "corner values", when it translates opp-hz|microvolt into
such values.
Kind regards
Uffe
--
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/3] dt-bindings: spicc: update compatible string for the Meson-AXG
From: Rob Herring @ 2017-11-28 16:38 UTC (permalink / raw)
To: Yixun Lan
Cc: Kevin Hilman, devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
linux-spi-u79uwXL29TY76Z2rM5mHXA, Neil Armstrong, Jerome Brunet,
Mark Rutland, Carlo Caione, Sunny Luo,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128132926.19051-2-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On Tue, Nov 28, 2017 at 09:29:24PM +0800, Yixun Lan wrote:
> From: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> Update the compatbile string to support Meson-AXG SoCs.
>
> Signed-off-by: Sunny Luo <sunny.luo-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> ---
> Documentation/devicetree/bindings/spi/spi-meson.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 00/16] SolidRun Hummingboard DT updates
From: Fabio Estevam @ 2017-11-28 16:31 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Shawn Guo, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jon Nettleton,
Rob Herring, Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20171128150045.GV31757-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On Tue, Nov 28, 2017 at 1:00 PM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> Hi Shawn,
>
> This series updates the SolidRun Hummingboard platforms to:
> (a) make the DT more reflective of the schematics
> (b) re-organise how we deal with the differences between various board
> versions in preparation for the new 1.5 SOM.
>
> The idea with (b) is that we add the support for the board + usom
> combination by including the appropriate dtsi files.
>
> For example, in mainline at the moment, we support two variants of the
> Hummingboards - both with Broadcom Wi-Fi and without eMMC. Going
> forward, when a 1.5 SOM is fitted (which modern Hummingboards will all
> have) the boards will have TI Wi-Fi and potentially eMMC on the usom.
>
> This series adds the dtsi files for the new SOM and dts files for the
> platform variants (v1.5 SOM without eMMC, v1.5 SOM with eMMC.) It's
> unfortunate that the w/o eMMC variant can't detect the lack of eMMC,
> running the eMMC version without eMMC on the boards results in an
> almost constant stream of kernel messages.
>
> Feedback from the previous posting has been addressed, and additional
> changes adding the v1.5 SOM board level files added through discussion
> with Jon.
Looks good, thanks.
For the whole series:
Reviewed-by: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/3] clk: meson-axg: add clock controller drivers
From: Rob Herring @ 2017-11-28 16:30 UTC (permalink / raw)
To: Yixun Lan
Cc: Neil Armstrong, Jerome Brunet, Kevin Hilman, Mark Rutland,
Michael Turquette, Stephen Boyd, Carlo Caione, Qiufang Dai,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128125330.363-3-yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
On Tue, Nov 28, 2017 at 08:53:29PM +0800, Yixun Lan wrote:
> From: Qiufang Dai <qiufang.dai-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
>
> Add clock controller drivers for Amlogic Meson-AXG SoC.
>
> Signed-off-by: Qiufang Dai <qiufang.dai-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Yixun Lan <yixun.lan-LpR1jeaWuhtBDgjK7y7TUQ@public.gmane.org>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> drivers/clk/meson/Kconfig | 8 +
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/axg.c | 948 +++++++++++++++++++++++++++++++++++
> drivers/clk/meson/axg.h | 126 +++++
> include/dt-bindings/clock/axg-clkc.h | 72 +++
This belongs in the binding patch.
Otherwise,
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> 6 files changed, 1156 insertions(+)
> create mode 100644 drivers/clk/meson/axg.c
> create mode 100644 drivers/clk/meson/axg.h
> create mode 100644 include/dt-bindings/clock/axg-clkc.h
--
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 01/13] dt-bindings: Add vendor prefix for Microsemi Corporation
From: Alexandre Belloni @ 2017-11-28 16:22 UTC (permalink / raw)
To: James Hogan
Cc: Ralf Baechle, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128161014.GG27409-4bYivNCBEGSP4qXr0kR+DFHK5/nzsB32@public.gmane.org>
On 28/11/2017 at 16:10:14 +0000, James Hogan wrote:
> On Tue, Nov 28, 2017 at 04:26:31PM +0100, Alexandre Belloni wrote:
> > Microsemi Corporation provides semiconductor and system solutions for
> > aerospace & defense, communications, data center and industrial markets.
> >
> > Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > ---
> > Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>
> Nit: Usually the Cc list goes before the --- line so that it is included
> in the git history (i.e. these people had the opportunity to comment).
>
Ok, it depends on the maintainer, some people prefer leaving that out of commit log.
I'm fine with adding those back in.
> Cheers
> James
>
> >
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 0994bdd82cd3..7b880084fd37 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -219,6 +219,7 @@ motorola Motorola, Inc.
> > moxa Moxa Inc.
> > mpl MPL AG
> > mqmaker mqmaker Inc.
> > +mscc Microsemi Corporation
> > msi Micro-Star International Co. Ltd.
> > mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
> > multi-inno Multi-Inno Technology Co.,Ltd
> > --
> > 2.15.0
> >
> >
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
From: Tony Lindgren @ 2017-11-28 16:18 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, Julia Lawall,
Sean Paul, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf
In-Reply-To: <ADAFBBA4-6AC4-4EC4-AB0E-98B59718E12E-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
* H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [171128 16:17]:
> Hi Tony,
>
> > Am 28.11.2017 um 17:04 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> >
> > * H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [171128 15:52]:
> >> We can remove the unnecessary "omapdss," prefix because
> >> the omapdrm driver takes care of it when matching with
> >> the driver table.
> >
> > So is this needed as a fix or is this another clean-up?
> >
> > So is this is really needed as a fix?
>
> Hm. How do you differentiate between "fix" and "cleanup"?
> Maybe it is more a wording than a content issue...
>
> For me it is a "fix" because it is semantically wrong to have
> a prefix where it is not needed. And "fixing" it changes the
> compiler output by 8 bytes.
How about let's call it a "typo fix" then? :)
> "Cleanup" would be for me removing whitespace or empty lines
> or typos in comments.
>
> > If this is just clean-up, again, please resend once the driver
> > changes have cleared.
>
> There is no change to the pandora driver involved here. The Pandora
> panel driver is already correct. Just the DTS has some redundant
> content which should be removed.
>
> So there is no dependency for this patch.
OK please resend separately after the driver changes have merged
then.
Regards,
Tony
--
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: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values
From: Ulf Hansson @ 2017-11-28 16:14 UTC (permalink / raw)
To: Viresh Kumar
Cc: Kevin Hilman, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rafael Wysocki, linux-pm@vger.kernel.org, Vincent Guittot,
Rob Herring, Rajendra Nayak, Sudeep Holla,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <23ba51eaa6b52117458165dccc00a95cf8e86e1d.1509453284.git.viresh.kumar@linaro.org>
On 31 October 2017 at 13:47, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On some platforms the exact frequency or voltage may be hidden from the
> OS by the firmware. Allow such configurations to pass magic values in
> the "opp-hz" or the "opp-microvolt" properties, which should be
> interpreted in a platform dependent way.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
This seems like a reasonable extension to me!
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 203e09fe7698..9c5056fb120f 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -166,6 +166,12 @@ properties.
> "power-domains" property. Also, either all or none of the OPP nodes in an OPP
> table should have it set.
>
> +
> +On some platforms the exact frequency or voltage may be hidden from the OS by
> +the firmware and the "opp-hz" or the "opp-microvolt" properties may contain
> +magic values that represent the frequency or voltage in a firmware dependent
> +way, for example an index of an array in the firmware.
> +
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>
> / {
> --
> 2.15.0.rc1.236.g92ea95045093
>
^ permalink raw reply
* Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
From: H. Nikolaus Schaller @ 2017-11-28 16:14 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Rutland, devicetree, linux-fbdev, letux-kernel,
Bartlomiej Zolnierkiewicz, David Airlie, Tomi Valkeinen,
dri-devel, Russell King, Rob Herring, linux-kernel, Julia Lawall,
Thierry Reding, Sean Paul, Laurent Pinchart, Benoît Cousson,
kernel, linux-omap, linux-arm-kernel
In-Reply-To: <20171128160437.GD28152@atomide.com>
Hi Tony,
> Am 28.11.2017 um 17:04 schrieb Tony Lindgren <tony@atomide.com>:
>
> * H. Nikolaus Schaller <hns@goldelico.com> [171128 15:52]:
>> We can remove the unnecessary "omapdss," prefix because
>> the omapdrm driver takes care of it when matching with
>> the driver table.
>
> So is this needed as a fix or is this another clean-up?
>
> So is this is really needed as a fix?
Hm. How do you differentiate between "fix" and "cleanup"?
Maybe it is more a wording than a content issue...
For me it is a "fix" because it is semantically wrong to have
a prefix where it is not needed. And "fixing" it changes the
compiler output by 8 bytes.
"Cleanup" would be for me removing whitespace or empty lines
or typos in comments.
>
> If this is just clean-up, again, please resend once the driver
> changes have cleared.
There is no change to the pandora driver involved here. The Pandora
panel driver is already correct. Just the DTS has some redundant
content which should be removed.
So there is no dependency for this patch.
BR,
Nikolaus
>
> Regards,
>
> Tony
>
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> index 53e007abdc71..64d967ec8c58 100644
>> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
>> @@ -626,7 +626,7 @@
>>
>> lcd: lcd@1 {
>> reg = <1>; /* CS1 */
>> - compatible = "omapdss,tpo,td043mtea1";
>> + compatible = "tpo,td043mtea1";
>> spi-max-frequency = <100000>;
>> spi-cpol;
>> spi-cpha;
>> --
>> 2.12.2
>>
^ permalink raw reply
* Re: [PATCH 01/13] dt-bindings: Add vendor prefix for Microsemi Corporation
From: James Hogan @ 2017-11-28 16:10 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Ralf Baechle, linux-mips-6z/3iImG2C8G8FEW9MqTrA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171128152643.20463-2-alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
On Tue, Nov 28, 2017 at 04:26:31PM +0100, Alexandre Belloni wrote:
> Microsemi Corporation provides semiconductor and system solutions for
> aerospace & defense, communications, data center and industrial markets.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Nit: Usually the Cc list goes before the --- line so that it is included
in the git history (i.e. these people had the opportunity to comment).
Cheers
James
>
>
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 0994bdd82cd3..7b880084fd37 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -219,6 +219,7 @@ motorola Motorola, Inc.
> moxa Moxa Inc.
> mpl MPL AG
> mqmaker mqmaker Inc.
> +mscc Microsemi Corporation
> msi Micro-Star International Co. Ltd.
> mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.)
> multi-inno Multi-Inno Technology Co.,Ltd
> --
> 2.15.0
>
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
From: H. Nikolaus Schaller @ 2017-11-28 16:04 UTC (permalink / raw)
To: Tony Lindgren
Cc: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, Julia Lawall,
Sean Paul, dri-devel, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-fbdev, letux-kernel, kernel
In-Reply-To: <20171128160057.GB28152@atomide.com>
> Am 28.11.2017 um 17:00 schrieb Tony Lindgren <tony@atomide.com>:
>
> * H. Nikolaus Schaller <hns@goldelico.com> [171128 15:51]:
>>> Am 28.11.2017 um 16:10 schrieb Tony Lindgren <tony@atomide.com>:
>>> OK fine dropping both. Please update the description in both dts
>>> patches to make it clear they are needed as a fix. Preferrably
>>> with a proper fixes tag.
>>
>> Well, it is not "needed" in a strong sense since current mainline&stable
>> works. It is more a style and consistency fix to use "tpo," everywhere.
>>
>>>
>>> Having "We can remove the "omapdss," prefix" in the description sure
>>> does not sounds like it's needed as a fix :)
>>
>> The description has been improved on -v3.
>
> Thanks.
>
>>> Sounds like maybe these two should be just a single patch for
>>> a proper fix?
>>
>> Hm. I usually get the feedback to separate DT and driver fixes into
>> separate commits... Therefore I submit patch sets in the hope they
>> are not picked apart :)
>
> See "both dts patches" part above. Yes the dts patches can and should
> be sent separately. In almost every case if the dts patches cannot be
> applied separately it means your driver changes are breaking things.
That is why the v3 driver now accepts both, the old and the new vendor
name. This means applying the driver alone is safe. Applying or not
applying DTS patch afterwards is also safe.
BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
From: Tony Lindgren @ 2017-11-28 16:04 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, Julia Lawall,
Sean Paul, dri-devel, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-fbdev, letux-kernel, kernel
In-Reply-To: <b6001c7b7fb98e7a3ad4c712084fea9dae9e6b27.1511884135.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [171128 15:52]:
> We can remove the unnecessary "omapdss," prefix because
> the omapdrm driver takes care of it when matching with
> the driver table.
So is this needed as a fix or is this another clean-up?
So is this is really needed as a fix?
If this is just clean-up, again, please resend once the driver
changes have cleared.
Regards,
Tony
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
> index 53e007abdc71..64d967ec8c58 100644
> --- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
> +++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
> @@ -626,7 +626,7 @@
>
> lcd: lcd@1 {
> reg = <1>; /* CS1 */
> - compatible = "omapdss,tpo,td043mtea1";
> + compatible = "tpo,td043mtea1";
> spi-max-frequency = <100000>;
> spi-cpol;
> spi-cpha;
> --
> 2.12.2
>
^ permalink raw reply
* Re: [PATCH v3 3/4] DTS: GTA04: fix panel compatibility string
From: Tony Lindgren @ 2017-11-28 16:02 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, Julia Lawall,
Sean Paul, dri-devel, devicetree, linux-kernel, linux-omap,
linux-arm-kernel, linux-fbdev, letux-kernel, kernel
In-Reply-To: <5f68789942fb8063ba5a98f5dd7989a05f94c0d6.1511884135.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [171128 15:52]:
> Official vendor string is now "tpo" and not "toppoly".
>
> Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
This is not a fix then, this is a clean up as you change the compatible
earlier. Please resend this separately once the driver changes have
been merged.
Regards,
Tony
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
> arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
> index 4504908c23fe..ec27ed67a22a 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dtsi
> +++ b/arch/arm/boot/dts/omap3-gta04.dtsi
> @@ -86,7 +86,7 @@
>
> /* lcd panel */
> lcd: td028ttec1@0 {
> - compatible = "toppoly,td028ttec1";
> + compatible = "tpo,td028ttec1";
> reg = <0>;
> spi-max-frequency = <100000>;
> spi-cpol;
> --
> 2.12.2
>
^ permalink raw reply
* Re: [PATCH v2 2/4] DTS: GTA04: fix panel compatibility string
From: Tony Lindgren @ 2017-11-28 16:00 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, Julia Lawall,
Sean Paul, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
letux-kernel-S0jZdbWzriLCfDggNXIi3w,
kernel-Jl6IXVxNIMRxAtABVqVhTwC/G2K4zDHf
In-Reply-To: <F14B3797-8154-4958-82AB-8E39C75BB97B-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
* H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [171128 15:51]:
> > Am 28.11.2017 um 16:10 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> > OK fine dropping both. Please update the description in both dts
> > patches to make it clear they are needed as a fix. Preferrably
> > with a proper fixes tag.
>
> Well, it is not "needed" in a strong sense since current mainline&stable
> works. It is more a style and consistency fix to use "tpo," everywhere.
>
> >
> > Having "We can remove the "omapdss," prefix" in the description sure
> > does not sounds like it's needed as a fix :)
>
> The description has been improved on -v3.
Thanks.
> > Sounds like maybe these two should be just a single patch for
> > a proper fix?
>
> Hm. I usually get the feedback to separate DT and driver fixes into
> separate commits... Therefore I submit patch sets in the hope they
> are not picked apart :)
See "both dts patches" part above. Yes the dts patches can and should
be sent separately. In almost every case if the dts patches cannot be
applied separately it means your driver changes are breaking things.
Regards,
Tony
--
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 0/5] PCI: Add support to the Cadence PCIe controller
From: Lorenzo Pieralisi @ 2017-11-28 15:50 UTC (permalink / raw)
To: Cyrille Pitchen
Cc: bhelgaas, kishon, linux-pci, adouglas, stelford, dgary, kgopi,
eandrews, thomas.petazzoni, sureshp, nsekhar, linux-kernel, robh,
devicetree
In-Reply-To: <cover.1511439189.git.cyrille.pitchen@free-electrons.com>
On Thu, Nov 23, 2017 at 04:01:45PM +0100, Cyrille Pitchen wrote:
> Hi all,
>
> this series of patches adds support to the Cadence PCIe controller.
> It was tested on a ARM64 platform emulated by a Palladium running both
> linux-next (next-20171123) and pci-next kernels.
>
> The host mode was tested with some PCIe devices connected to the Palladium
> through a speed-bridge. Some of those devices were a USB host controller
> and a SATA controller. The PCIe host controller was also tested with a
> second controller configured in endpoint mode and connected back to back
> to the first controller.
>
> The EndPoint Controller (EPC) driver of this series was tested with the
> pci-epf-test.c EndPoint Function (EPF) driver and the pcitest userspace
> program.
>
> For linux-next, I applied this series on top of Kishon's patch
> ("PCI: endpoint: Use EPC's device in dma_alloc_coherent/dma_free_coherent")
> otherwise dma_alloc_coherent() fails when called by pci_epf_alloc_space().
>
> Also, I patched drivers/Makefile rather than drivers/pci/Makefile to make
> the drivers/pci/cadence/pcie-cadence-ep.o linked after
> drivers/pci/endpoint/*.o objects, otherwise the built-in pci-cadence-ep
> driver would be probed before the PCI endpoint framework would have been
> initialized, which results in a kernel crash.
Nice :( - isn't there a way to improve this (ie probe deferral or
registering the EPF bus earlier) ?
> I guess this is the reason why the "pci/dwc" line was also put in
> drivers/Makefile, right after the "pci/endpoint" line.
Or probably the other way around - see commit 5e8cb4033807
@Kishon, thoughts ?
Thanks,
Lorenzo
> Best regards,
>
> Cyrille
>
> Cyrille Pitchen (4):
> PCI: Add vendor ID for Cadence
> PCI: cadence: Add host driver for Cadence PCIe controller
> dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe endpoint
> controller
> PCI: cadence: add EndPoint Controller driver for Cadence PCIe
> controller
>
> Scott Telford (1):
> dt-bindings: PCI: cadence: Add DT bindings for Cadence PCIe host
> controller
>
> .../devicetree/bindings/pci/cdns,cdns-pcie-ep.txt | 20 +
> .../bindings/pci/cdns,cdns-pcie-host.txt | 54 ++
> drivers/Makefile | 1 +
> drivers/pci/Kconfig | 1 +
> drivers/pci/cadence/Kconfig | 33 ++
> drivers/pci/cadence/Makefile | 3 +
> drivers/pci/cadence/pcie-cadence-ep.c | 553 +++++++++++++++++++++
> drivers/pci/cadence/pcie-cadence-host.c | 425 ++++++++++++++++
> drivers/pci/cadence/pcie-cadence.c | 110 ++++
> drivers/pci/cadence/pcie-cadence.h | 325 ++++++++++++
> include/linux/pci_ids.h | 2 +
> 11 files changed, 1527 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/cdns,cdns-pcie-ep.txt
> create mode 100644 Documentation/devicetree/bindings/pci/cdns,cdns-pcie-host.txt
> create mode 100644 drivers/pci/cadence/Kconfig
> create mode 100644 drivers/pci/cadence/Makefile
> create mode 100644 drivers/pci/cadence/pcie-cadence-ep.c
> create mode 100644 drivers/pci/cadence/pcie-cadence-host.c
> create mode 100644 drivers/pci/cadence/pcie-cadence.c
> create mode 100644 drivers/pci/cadence/pcie-cadence.h
>
> --
> 2.11.0
>
^ permalink raw reply
* Re: [RFC V7 1/2] OPP: Allow OPP table to be used for power-domains
From: Ulf Hansson @ 2017-11-28 15:50 UTC (permalink / raw)
To: Viresh Kumar
Cc: Kevin Hilman, Viresh Kumar, Nishanth Menon, Stephen Boyd,
Rafael J. Wysocki, linux-pm@vger.kernel.org, Vincent Guittot,
Rob Herring, Rajendra Nayak, Sudeep Holla,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <2b244ea0a09deaf50237fb8b7578273a8284499e.1509453284.git.viresh.kumar@linaro.org>
On 31 October 2017 at 13:47, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> Power-domains can also have their active states and this patch enhances
> the OPP binding to define those.
>
> The power domains can use the OPP bindings mostly as is. Though there
> are some changes required to support special cases:
>
> - Allow "operating-points-v2" to contain multiple phandles for power
> domain providers providing multiple domains.
>
> - A new property "power-domain-opp" is added for devices to specify the
> minimum required OPP of the master domain for the functioning of the
> device. We can add this property directly to device's node if the
> device has a fixed minimum OPP requirement from the master power
Please avoid the terminology "master power domain", it's confusing.
Instead use only "power domain". This applies to a couple of more
places of $subject patch, please fix those as well.
> domain. Or we can add this property to each OPP node of the device, if
> different OPP nodes have different minimum OPP requirement from the
> master power domain.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 12 +++++
> .../devicetree/bindings/power/power_domain.txt | 62 ++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index 9d733af26be7..203e09fe7698 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -45,6 +45,11 @@ Devices supporting OPPs must set their "operating-points-v2" property with
> phandle to a OPP table in their DT node. The OPP core will use this phandle to
> find the operating points for the device.
>
> +This can contain more than one phandle for power domain providers that provide
> +multiple power domains. That is, one phandle for each power domain. If only one
> +phandle is available, then the same OPP table will be used for all power domains
> +provided by the power domain provider.
> +
> If required, this can be extended for SoC vendor specific bindings. Such bindings
> should be documented as Documentation/devicetree/bindings/power/<vendor>-opp.txt
> and should have a compatible description like: "operating-points-v2-<vendor>".
> @@ -154,6 +159,13 @@ properties.
>
> - status: Marks the node enabled/disabled.
>
> +- power-domain-opp: This contains phandle to one of the OPP nodes of the master
> + power domain. This specifies the minimum required OPP of the master domain for
> + the functioning of the device in this OPP (where this property is present).
> + This property can only be set for a device if the device node contains the
> + "power-domains" property. Also, either all or none of the OPP nodes in an OPP
> + table should have it set.
> +
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>
> / {
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index 14bd9e945ff6..0d8608f2d133 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -40,6 +40,12 @@ phandle arguments (so called PM domain specifiers) of length specified by the
> domain's idle states. In the absence of this property, the domain would be
> considered as capable of being powered-on or powered-off.
>
> +- operating-points-v2 : Phandles to the OPP tables of power domains provided by
> + a power domain provider. If the provider provides a single power domain only
> + or all the power domains provided by the provider have identical OPP tables,
> + then this shall contain a single phandle. Refer to ../opp/opp.txt for more
> + information.
> +
> Example:
>
> power: power-controller@12340000 {
> @@ -120,4 +126,60 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> +Optional properties:
> +- power-domain-opp: This contains phandle to one of the OPP nodes of the master
> + power domain. This specifies the minimum required OPP of the master domain for
> + the functioning of the device. This property can only be set for a device, if
> + the device node contains the "power-domains" property.
> +
> +Example:
> +- OPP table for domain provider that provides two domains.
> +
> + domain0_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + domain0_opp_0: opp-1000000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <975000 970000 985000>;
> + };
> + domain0_opp_1: opp-1100000000 {
> + opp-hz = /bits/ 64 <1100000000>;
> + opp-microvolt = <1000000 980000 1010000>;
> + };
> + };
> +
> + domain1_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> +
> + domain1_opp_0: opp-1200000000 {
> + opp-hz = /bits/ 64 <1200000000>;
> + opp-microvolt = <975000 970000 985000>;
> + };
> + domain1_opp_1: opp-1300000000 {
> + opp-hz = /bits/ 64 <1300000000>;
> + opp-microvolt = <1000000 980000 1010000>;
> + };
> + };
> +
> + parent: power-controller@12340000 {
> + compatible = "foo,power-controller";
> + reg = <0x12340000 0x1000>;
> + #power-domain-cells = <1>;
> + operating-points-v2 = <&domain0_opp_table>, <&domain1_opp_table>;
> + };
> +
> + leaky-device0@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&parent 0>;
> + power-domain-opp = <&domain0_opp_0>;
> + };
> +
> + leaky-device1@12350000 {
> + compatible = "foo,i-leak-current";
> + reg = <0x12350000 0x1000>;
> + power-domains = <&parent 1>;
> + power-domain-opp = <&domain1_opp_1>;
> + };
> +
> [1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
> --
Besides the minor nitpick(s), this looks good to me. Feel free to add:
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
^ permalink raw reply
* [PATCH v3 4/4] DTS: Pandora: fix panel compatibility string
From: H. Nikolaus Schaller @ 2017-11-28 15:48 UTC (permalink / raw)
To: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, H. Nikolaus Schaller,
Julia Lawall, Sean Paul
Cc: dri-devel, devicetree, linux-kernel, linux-omap, linux-arm-kernel,
linux-fbdev, letux-kernel, kernel
In-Reply-To: <cover.1511884135.git.hns@goldelico.com>
We can remove the unnecessary "omapdss," prefix because
the omapdrm driver takes care of it when matching with
the driver table.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi b/arch/arm/boot/dts/omap3-pandora-common.dtsi
index 53e007abdc71..64d967ec8c58 100644
--- a/arch/arm/boot/dts/omap3-pandora-common.dtsi
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -626,7 +626,7 @@
lcd: lcd@1 {
reg = <1>; /* CS1 */
- compatible = "omapdss,tpo,td043mtea1";
+ compatible = "tpo,td043mtea1";
spi-max-frequency = <100000>;
spi-cpol;
spi-cpha;
--
2.12.2
^ permalink raw reply related
* [PATCH v3 3/4] DTS: GTA04: fix panel compatibility string
From: H. Nikolaus Schaller @ 2017-11-28 15:48 UTC (permalink / raw)
To: Thierry Reding, David Airlie, Rob Herring, Mark Rutland,
Benoît Cousson, Tony Lindgren, Russell King, Tomi Valkeinen,
Bartlomiej Zolnierkiewicz, Laurent Pinchart, H. Nikolaus Schaller,
Julia Lawall, Sean Paul
Cc: dri-devel, devicetree, linux-kernel, linux-omap, linux-arm-kernel,
linux-fbdev, letux-kernel, kernel
In-Reply-To: <cover.1511884135.git.hns@goldelico.com>
Official vendor string is now "tpo" and not "toppoly".
Requires patch "omapdrm: panel: fix compatible vendor string for td028ttec1"
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
arch/arm/boot/dts/omap3-gta04.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-gta04.dtsi b/arch/arm/boot/dts/omap3-gta04.dtsi
index 4504908c23fe..ec27ed67a22a 100644
--- a/arch/arm/boot/dts/omap3-gta04.dtsi
+++ b/arch/arm/boot/dts/omap3-gta04.dtsi
@@ -86,7 +86,7 @@
/* lcd panel */
lcd: td028ttec1@0 {
- compatible = "toppoly,td028ttec1";
+ compatible = "tpo,td028ttec1";
reg = <0>;
spi-max-frequency = <100000>;
spi-cpol;
--
2.12.2
^ permalink raw reply related
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