* Waiting For Your Urgent Replay.........
From: Mr.Mohamed Akram @ 2017-12-16 9:25 UTC (permalink / raw)
My Dear,
How are you together with your family? I hope all is well. Considering
the fact, I did not know you in person or even have seen you before
but due to the true revelation that I should share this lucrative
opportunity with you, I have no choice other than to contact you. So,
kindly consider this message essential and confidential.
first and foremost I have to introduce myself to you I am Mr.Akram
Mohamed, from Burkina Faso in west Africa, the Audit and Account
Manager BANK OF AFRICA (BOA) in Ouagadougou Burkina Faso west Africa.
I had the intent to contact you over transfer of fund worth the sum of
Six million two hundred thousand u.s dollars. (Us$6.2m) for the
betterment of our life, I agree that 40% of the total amount will be
for you and 60% for me.
I need your urgent response on assurance of trust that you will not
deny my share when once the fund is transfer to your personal bank
account.
Your urgently responses is needed through this email
address:mrakram.mo01-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org reply with your information as I stated
it bellow once I receive your information I will give you more details
as application and how you will apply to our bank on how to transfer
the fund into your bank account.
(1) Full names:
(2) private phone number:
(3) occupation:
Make sure you keep this transaction as top secret and make it
confidential till we receive the fund into your bank account that you
will provide to our bank. Don't disclose it to anybody, because the
secret of this transaction is as well as the success of it.
I look forward to hear from you call me immediately as soon as you
receive this message or email me urgent.
In sincerity,
Mr.Akram Mohamed
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH for v4.15] dt-bindings/media/cec-gpio.txt: mention the CEC/HPD max voltages
From: Hans Verkuil @ 2017-12-16 10:44 UTC (permalink / raw)
To: Linux Media Mailing List, linux-devicetree
Mention the maximum voltages of the CEC and HPD lines. Since in the example
these lines are connected to a Raspberry Pi and the Rpi GPIO lines are 3.3V
it is a good idea to warn against directly connecting the HPD to the Raspberry
Pi's GPIO line.
Signed-off-by: Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>
---
diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt b/Documentation/devicetree/bindings/media/cec-gpio.txt
index 46a0bac8b3b9..b36490aba7eb 100644
--- a/Documentation/devicetree/bindings/media/cec-gpio.txt
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -4,6 +4,10 @@ The HDMI CEC GPIO module supports CEC implementations where the CEC line
is hooked up to a pull-up GPIO line and - optionally - the HPD line is
hooked up to another GPIO line.
+Please note: the maximum voltage for the CEC line is 3.63V, for the HPD
+line it is 5.3V. So you may need some sort of level conversion circuitry
+when connecting them to a GPIO line.
+
Required properties:
- compatible: value must be "cec-gpio".
- cec-gpios: gpio that the CEC line is connected to. The line should be
@@ -21,7 +25,7 @@ the following property is optional:
Example for the Raspberry Pi 3 where the CEC line is connected to
pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
-connected to pin 11 aka BCM17:
+connected to pin 11 aka BCM17 (some level shifter is needed for this!):
#include <dt-bindings/gpio/gpio.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 related
* Re: [PATCH v2 3/4] dt-bindings: opp: Introduce ti-opp-supply bindings
From: Rafael J. Wysocki @ 2017-12-16 10:52 UTC (permalink / raw)
To: Dave Gerlach
Cc: Viresh Kumar, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Linux OMAP Mailing List, Linux PM,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Tony Lindgren,
Nishanth Menon
In-Reply-To: <CAJZ5v0iaYAodhiQm3=7OMhtqP3JXoX_RTrYMRDxVwO=3hTL7Bg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Fri, Dec 15, 2017 at 3:29 PM, Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 15, 2017 at 5:25 AM, Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> wrote:
>> Document the devicetree bindings that describe Texas Instruments
>> opp-supply which allow a platform to describe multiple regulators and
>> additional information, such as registers containing data needed to
>> program aforementioned regulators.
>>
>> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
>
> I need an ACK from Rob on this one.
Actually, how this (and the next patch) is related to the [1-2/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
* Re: [PATCH v3 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel RAYNAL @ 2017-12-16 12:50 UTC (permalink / raw)
To: Rob Herring
Cc: Gregory CLEMENT, Baruch Siach, Mark Rutland, Andrew Lunn,
Jason Cooper, Nadav Haklai, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Catalin Marinas, Antoine Tenart, Will Deacon, David Sniatkiwicz,
Eduardo Valentin, devicetree-u79uwXL29TY76Z2rM5mHXA, Zhang Rui,
Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sebastian Hesselbarth
In-Reply-To: <20171215232854.n23biqelqoqjsevm@rob-hp-laptop>
Hello Rob,
On Fri, 15 Dec 2017 17:28:54 -0600
Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Fri, Dec 15, 2017 at 11:52:30AM +0100, Miquel RAYNAL wrote:
> > Hello Baruch and Gregory,
> >
> > On Fri, 15 Dec 2017 09:44:19 +0100
> > Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> >
> > > Hi Miquel,
> > >
> > > On ven., déc. 15 2017, Miquel RAYNAL
> > > <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > >
> > > > Hello Baruch,
> > > >
> > > > On Fri, 15 Dec 2017 10:27:59 +0200
> > > > Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> > > >
> > > >> Hi Miquel
> > > >>
> > > >> On Thu, Dec 14, 2017 at 11:30:01AM +0100, Miquel Raynal
> > > >> wrote:
> > > >> > +- marvell,thermal-zone-name: The name to identify the
> > > >> > thermal zone
> > > >> > + within the sysfs, useful when
> > > >> > multiple
> > > >> > + thermal zones are registered
> > > >> > (AP, CPx...).
> > > >>
> > > >> I don't think that would be acceptable. DT is about describing
> > > >> the hardware. sysfs is a Linux implementation detail which is
> > > >> not tied to any specific hardware. If this is accepted, the
> > > >> property should be named 'linux,thermal-zone-name'.
> > > >
> > > > You are right the sysfs mention should not appear in the
> > > > description.
> >
> > Actually, you are right for all of it, this property should not
> > exist, sorry for my too quick answer.
> >
> > > >
> > > > Otherwise for the naming I'm not sure "linux," is a valid
> > > > prefix in that case.
> >
> > Thank you both for your explanations, I was also wrong about the
> > prefix.
> > >
> > > Actually the choice between linux or marvell make me realize that
> > > there is something wrong. Having a name associated to a device is
> > > something pretty usual with the device tree, however it is as the
> > > class device level, such as clock-names, line-name, or
> > > regulator-name. So in my opinion if we want to support naming from
> > > device tree it would be done for all the thermal device not just
> > > for the Marvell one.
> > >
> > > However I don't think we need it. For example for the clocks we
> > > created the name dynamically using of the base address of the
> > > register to keep them unique.
> >
> > I was convinced that dev_name's would be the same but after trying
> > it on a 8040-DB, using dev_name(&pdev->dev) gives:
> >
> > f06f808c.thermal
> > f2400078.thermal
> > f4400078.thermal
> >
> > which I found meaningful enough.
> >
> > I will drop the property and use dev_name instead. I still need your
> > help to solve one problem though: how to make the distinction
> > between using "armada_thermal" (the previous name) and dev_name() ?
> > If I don't it kind of breaks userspace, doesn't it ?
>
> No. The /sys/devices/... or /sys/bus/platform/... paths and names are
> not guaranteed to be stable. These changed for every platform
> converted to DT for example. Userspace should be accessing things
> through /sys/class/... (or deal with changes).
Ok, thanks for the explanation.
I will sent a v4 early next week about all the changes requested.
Thank you all for reviewing.
Miquèl
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] drm/panel: Add support for AUO G104SN02 V2 panel
From: Christoph Fritz @ 2017-12-16 13:13 UTC (permalink / raw)
To: Rob Herring, Thierry Reding, David Airlie, Mark Rutland
Cc: Stefan Riedmüller,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20171215230754.cnepbs34t5gp2rsf@rob-hp-laptop>
This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM
simple panel driver.
Signed-off-by: Christoph Fritz <chf.fritz-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Signed-off-by: Stefan Riedmueller <s.riedmueller-guT5V/WYfQezQB+pC5nmwQ@public.gmane.org>
---
Changes since v1:
- be explicit as to which properties apply
- adapt indenting
.../bindings/display/panel/auo,g104sn02.txt | 12 ++++++++++
drivers/gpu/drm/panel/panel-simple.c | 26 ++++++++++++++++++++++
2 files changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt
diff --git a/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt b/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt
new file mode 100644
index 0000000..85626ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/auo,g104sn02.txt
@@ -0,0 +1,12 @@
+AU Optronics Corporation 10.4" (800x600) color TFT LCD panel
+
+Required properties:
+- compatible: should be "auo,g104sn02"
+- power-supply: as specified in the base binding
+
+Optional properties:
+- backlight: as specified in the base binding
+- enable-gpios: as specified in the base binding
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b7c4709..8599905 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -581,6 +581,29 @@ static const struct panel_desc auo_b133htn01 = {
},
};
+static const struct drm_display_mode auo_g104sn02_mode = {
+ .clock = 40000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 40,
+ .hsync_end = 800 + 40 + 216,
+ .htotal = 800 + 40 + 216 + 128,
+ .vdisplay = 600,
+ .vsync_start = 600 + 10,
+ .vsync_end = 600 + 10 + 35,
+ .vtotal = 600 + 10 + 35 + 2,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc auo_g104sn02 = {
+ .modes = &auo_g104sn02_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 211,
+ .height = 158,
+ },
+};
+
static const struct display_timing auo_g133han01_timings = {
.pixelclock = { 134000000, 141200000, 149000000 },
.hactive = { 1920, 1920, 1920 },
@@ -1993,6 +2016,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "auo,b133xtn01",
.data = &auo_b133xtn01,
}, {
+ .compatible = "auo,g104sn02",
+ .data = &auo_g104sn02,
+ }, {
.compatible = "auo,g133han01",
.data = &auo_g133han01,
}, {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 00/20] Add Hummingboard 2 support
From: Fabio Estevam @ 2017-12-16 13:58 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Fabio Estevam, Sascha Hauer, Shawn Guo,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
Rob Herring
In-Reply-To: <20171211165631.GW10595-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On Mon, Dec 11, 2017 at 2:56 PM, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> Hi,
>
> This series adds the long awaited Hummingboard 2 support to the
> mainline kernel.
>
> While I could squash the patch set down, I've not done this because
> this is the result of several different people over the course of
> the last couple of years, and I believe it's not right to lose the
> detail of their contributions.
>
> This builds upon the previous set of changes for the Hummingboard,
> which re-organised the way we deal with the uSOM and baseboards.
For the 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 5/9] ARM: dts: imx7-colibri: specify cpu-supply
From: Fabio Estevam @ 2017-12-16 13:59 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-5-stefan-XLVq0VzYD2Y@public.gmane.org>
Hi Stefan,
On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> Specify CPU supply using the "cpu-supply" property instead of
> the invalid "arm-supply" property.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
> ---
> arch/arm/boot/dts/imx7-colibri.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/imx7-colibri.dtsi b/arch/arm/boot/dts/imx7-colibri.dtsi
> index f61041af026a..6498c1136ef1 100644
> --- a/arch/arm/boot/dts/imx7-colibri.dtsi
> +++ b/arch/arm/boot/dts/imx7-colibri.dtsi
> @@ -86,7 +86,7 @@
> };
>
> &cpu0 {
> - arm-supply = <®_DCDC2>;
> + cpu-supply = <®_DCDC2>;
Good catch. I need to apply this same fix for some other imx7 board dts:
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 1/9] ARM: dts: imx7-colibri: move and rename USB Host power regulator
From: Fabio Estevam @ 2017-12-16 14:00 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-1-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:29 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> The Colibri default which enables USB Host power is not necessarily
> tied to the OTG2 controller, some carrier board use the pin to
> control USB power for both controllers. Hence name the pinctrl
> group more generic.
>
> Also move the regulator to the generic eval-v3 device tree since
> the regulator is always on the carrier board. In the Colibri iMX7S
> case the regulator is just not used. This allows to reuse the
> regulator in a upcoming SKU Colibri iMX7D 1GB with eMMC.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
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 2/9] ARM: dts: imx7-colibri: make sure multiplexed pins are not active
From: Fabio Estevam @ 2017-12-16 14:01 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-2-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:29 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> The Colibri pins PWM<A> and <D> are multiplexed on the module, make
> sure the secondary SoC pin is not active.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
I haven't really understood the commit message, but this is probably
because I don't have access to the schematics.
Anyway:
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 3/9] ARM: dts: imx7-colibri: mux pull-ups where appropriate
From: Fabio Estevam @ 2017-12-16 14:02 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-3-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:29 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> Use pull-ups instead of pull-downs for the pins which are already
> pulled-up externally.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
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 4/9] ARM: dts: imx7-colibri: use NAND_CE1 as GPIO
From: Fabio Estevam @ 2017-12-16 14:02 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-4-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> All Colibri iMX7 SKUs use either single-die NAND or eMMC, hence
> NAND_CE1 is not used on the module and can be used as a GPIO by
> carrier boards.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
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 6/9] ARM: dts: imx7-colibri: specify usdhc1 supplies
From: Fabio Estevam @ 2017-12-16 14:03 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Fabio Estevam, Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel
In-Reply-To: <20171206153005.6144-6-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> The usdhc1 controller instance is used to provide the default
> SD/MMC capabilities of the Colibri standard. The IO pins are
> supplied to the SoC on the module whereas the SD-card is powered
> by the Carrier Board supply.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
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 7/9] ARM: dts: imx7-colibri: specify backlight GPIO
From: Fabio Estevam @ 2017-12-16 14:03 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-7-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> The Colibri standard defines SODIMM 71 as backlight enable
> GPIO. Assign the GPIO to the backlight node in the module
> level device tree.
>
> Signed-off-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org>
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 8/9] ARM: dts: imx7-colibri: add MCP2515 CAN controller
From: Fabio Estevam @ 2017-12-16 14:05 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-8-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> +&ecspi3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs>;
> + num-cs = <1>;
num-cs can be dropped.
--
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 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Fabio Estevam @ 2017-12-16 14:09 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, linux-kernel, Rob Herring,
Fabio Estevam, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171206153005.6144-9-stefan-XLVq0VzYD2Y@public.gmane.org>
On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
> diff --git a/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
> new file mode 100644
> index 000000000000..5d5bb4c2843f
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
> @@ -0,0 +1,55 @@
> +/*
> + * Copyright 2017 Toradex AG
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
Patch looks good.
Just a comment: people have been starting to use SPDX license identifiers.
This would really make all this huge license text much shorter :-)
--
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 9/9] ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support
From: Philippe Ombredanne @ 2017-12-16 14:18 UTC (permalink / raw)
To: Stefan Agner
Cc: Shawn Guo, Sascha Hauer, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel, Rob Herring, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Fabio Estevam
In-Reply-To: <CAOMZO5Dv5dRbbHeqMtitXaHjJbMF4nGQWg0dpyHu0hh+2TaxGA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Dear Stefan,
On Sat, Dec 16, 2017 at 3:09 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Dec 6, 2017 at 1:30 PM, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> wrote:
>
>> diff --git a/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
>> new file mode 100644
>> index 000000000000..5d5bb4c2843f
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx7d-colibri-emmc-eval-v3.dts
>> @@ -0,0 +1,55 @@
>> +/*
>> + * Copyright 2017 Toradex AG
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * version 2 as published by the Free Software Foundation.
>> + *
>> + * This file is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>
> Patch looks good.
>
> Just a comment: people have been starting to use SPDX license identifiers.
>
> This would really make all this huge license text much shorter :-)
Oh yes, please! Every time there are more than three lines of legalese
in a kernel source code file, a kitten dies somewhere. That's sad. We
all love kitten, right? See also Thomas doc patches for details [1]
though he forgot to mention this cat fact.
[1] https://lkml.org/lkml/2017/12/4/934
--
Cordially
Philippe Ombredanne
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Heiko Stuebner @ 2017-12-16 15:52 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
balbi-DgEjT+Ai2ygdnm+yROfE0A
Cc: william.wu-TNX95d0MmH7DzftRWevZcw, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-usb-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171204094041.25439-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Hi Greg, Felipe,
Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
> From: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>
> Adds the device tree bindings description for RK3328 and
> compatible USB DWC3 controller.
>
> Signed-off-by: William Wu <william.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
do you want to pick this patch with only the small dt-binding
change or Ack it for me to pick up together with the actual
devicetree changes in the other patches?
Thanks
Heiko
> ---
> changes in v2:
> - add Rob's Ack
>
> Ideally usb maintainers would pick up this patch to the binding
> document and I'll take the devicetree changes after that.
>
> But if so desired, I can also pick up the binding change myself
> but would need an Ack for that.
>
> Documentation/devicetree/bindings/usb/rockchip,dwc3.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> index 50a31536e975..2c3f6a467fda 100644
> --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.txt
> @@ -1,7 +1,9 @@
> Rockchip SuperSpeed DWC3 USB SoC controller
>
> Required properties:
> -- compatible: should contain "rockchip,rk3399-dwc3" for rk3399 SoC
> +- compatible: should be one of the following:
> + - "rockchip,rk3399-dwc3": for rk3399 SoC
> + - "rockchip,rk3328-dwc3", "rockchip,rk3399-dwc3": for rk3328 SoC
> - clocks: A list of phandle + clock-specifier pairs for the
> clocks listed in clock-names
> - clock-names: Should contain the following:
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 10/12] dt-bindings: sdhci-omap: Add K2G specific binding
From: Rob Herring @ 2017-12-16 16:49 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Ulf Hansson, Tony Lindgren, Adrian Hunter, Mark Rutland,
Russell King, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
nsekhar-l0cyMroinI0
In-Reply-To: <20171214130941.26666-11-kishon-l0cyMroinI0@public.gmane.org>
On Thu, Dec 14, 2017 at 06:39:39PM +0530, Kishon Vijay Abraham I wrote:
> Add binding for the TI's sdhci-omap controller present in K2G.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> ---
> Documentation/devicetree/bindings/mmc/sdhci-omap.txt | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@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 4/5] arm64: dts: rockchip: add pd_usb3 power-domain node for rk3399.
From: Heiko Stuebner @ 2017-12-16 16:55 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Rob Herring, dianders-hpIqsD4AKlfQT0dZR+AlfA,
groeck-F7+t8E8rja9g9hUCZPvPmw, briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215110005.7564-4-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Am Freitag, 15. Dezember 2017, 12:00:04 CET schrieb Enric Balletbo i Serra:
> Add the usb3 power-domain, its qos area and assign it to the usb device
> node.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
applied for 4.16
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] arm64: dts: rockchip: add the aclk_usb3 clocks for USB3.
From: Heiko Stuebner @ 2017-12-16 17:00 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Rob Herring, dianders-hpIqsD4AKlfQT0dZR+AlfA,
groeck-F7+t8E8rja9g9hUCZPvPmw, briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215110005.7564-2-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Am Freitag, 15. Dezember 2017, 12:00:02 CET schrieb Enric Balletbo i Serra:
> The aclk_usb3 must be enabled to support USB3 for rk3399.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
applied for 4.16
--
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 5/5] arm64: dts: rockchip: add reset property for dwc3 controllers on rk3399.
From: Heiko Stuebner @ 2017-12-16 17:01 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Rob Herring, dianders-hpIqsD4AKlfQT0dZR+AlfA,
groeck-F7+t8E8rja9g9hUCZPvPmw, briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215110005.7564-5-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Am Freitag, 15. Dezember 2017, 12:00:05 CET schrieb Enric Balletbo i Serra:
> After commit '06c47e6286d usb: dwc3: of-simple: Add support to get resets
> for the device' you can add the reset property to the dwc3 node, the reset
> is required for the controller to work properly, otherwise bind / unbind
> stress testing of the USB controller on rk3399 we'd often end up with lots
> of failures that looked like this:
>
> phy phy-ff800000.phy.9: phy poweron failed --> -110
> dwc3 fe900000.dwc3: failed to initialize core
> dwc3: probe of fe900000.dwc3 failed with error -110
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
applied for 4.16
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 3/5] arm64: dts: rockchip: add usb3-phy otg-port support for rk3399.
From: Heiko Stuebner @ 2017-12-16 17:06 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Rob Herring, dianders-hpIqsD4AKlfQT0dZR+AlfA,
groeck-F7+t8E8rja9g9hUCZPvPmw, briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215110005.7564-3-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Am Freitag, 15. Dezember 2017, 12:00:03 CET schrieb Enric Balletbo i Serra:
> Add the usb3 phyter for the USB3.0 OTG controller.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
applied for 4.16
--
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 1/5] arm64: dts: rockchip: add extcon nodes and enable tcphy.
From: Heiko Stuebner @ 2017-12-16 17:08 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Rob Herring, dianders-hpIqsD4AKlfQT0dZR+AlfA,
groeck-F7+t8E8rja9g9hUCZPvPmw, briannorris-hpIqsD4AKlfQT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171215110005.7564-1-enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Am Freitag, 15. Dezember 2017, 12:00:01 CET schrieb Enric Balletbo i Serra:
> Enable tcphy and create the cros-ec's extcon node for the USB Type-C port.
>
> Signed-off-by: Enric Balletbo i Serra <enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
applied for 4.16
Thanks
Heiko
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: Support Mali450 on rk3328
From: Heiko Stuebner @ 2017-12-16 17:17 UTC (permalink / raw)
To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171209000738.32187-1-heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Am Samstag, 9. Dezember 2017, 01:07:35 CET schrieb Heiko Stuebner:
> Pretty standard setup. Tested with the kmscube demo running
> using the lima kernel and gallium driver.
>
>
> Heiko Stuebner (3):
> dt-bindings: gpu: mali-utgard: add rockchip,rk3328-mali compatible
> arm64: dts: rockchip: add rk3328 mali gpu node
> arm64: dts: rockchip: enable gpu on rk3328-rock64
applied for 4.16 with Robs review and following his suggestion
of making the gpu simply always-on and thus droppping patch 3.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/7] dt-bindings: i3c: Document core bindings
From: Rob Herring @ 2017-12-16 17:20 UTC (permalink / raw)
To: Boris Brezillon
Cc: Wolfram Sang, linux-i2c, Jonathan Corbet, linux-doc,
Greg Kroah-Hartman, Arnd Bergmann, Przemyslaw Sroka,
Arkadiusz Golec, Alan Douglas, Bartosz Folta, Damian Kos,
Alicja Jurasik-Urbaniak, Cyprian Wronka, Suresh Punnoose,
Thomas Petazzoni, Nishanth Menon, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, devicetree
In-Reply-To: <20171214151610.19153-6-boris.brezillon@free-electrons.com>
On Thu, Dec 14, 2017 at 04:16:08PM +0100, Boris Brezillon wrote:
> A new I3C subsystem has been added and a generic description has been
> created to represent the I3C bus and the devices connected on it.
>
> Document this generic representation.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Changes in v2:
> - Define how to describe I3C devices in the DT and when it should be
> used. Note that the parsing of I3C devices is not yet implemented in
> the framework. Will be added when someone really needs it.
> ---
> Documentation/devicetree/bindings/i3c/i3c.txt | 128 ++++++++++++++++++++++++++
> 1 file changed, 128 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i3c/i3c.txt
>
> diff --git a/Documentation/devicetree/bindings/i3c/i3c.txt b/Documentation/devicetree/bindings/i3c/i3c.txt
> new file mode 100644
> index 000000000000..79a214dee025
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i3c/i3c.txt
> @@ -0,0 +1,128 @@
> +Generic device tree bindings for I3C busses
> +===========================================
> +
> +This document describes generic bindings that should be used to describe I3C
> +busses in a device tree.
> +
> +Required properties
> +-------------------
> +
> +- #address-cells - should be <1>. Read more about addresses below.
> +- #size-cells - should be <0>.
> +- compatible - name of I3C bus controller following generic names
> + recommended practice.
generic names isn't anything recommended.
One problem we have with i2c buses is we can't identify them in the DT
other than with a list of all controller's compatible strings. We can
fix this by defining the controller node name. So please define the node
name to be "i3c-controller". That's more inline with other node names
than i3c-master that you used below.
> +
> +For other required properties e.g. to describe register sets,
> +clocks, etc. check the binding documentation of the specific driver.
> +
> +Optional properties
> +-------------------
> +
> +These properties may not be supported by all I3C master drivers. Each I3C
> +master bindings should specify which of them are supported.
> +
> +- i3c-scl-frequency: frequency (in Hz) of the SCL signal used for I3C
> + transfers. When undefined the core set it to 12.5MHz.
> +
> +- i2c-scl-frequency: frequency (in Hz) of the SCL signal used for I2C
> + transfers. When undefined, the core looks at LVR values
> + of I2C devices described in the device tree to determine
> + the maximum I2C frequency.
Add '-hz' suffix. You could drop 'frequency' as that would be implied by
Hz.
> +
> +I2C devices
> +===========
> +
> +Each I2C device connected to the bus should be described in a subnode with
> +the following properties:
> +
> +All properties described in Documentation/devicetree/bindings/i2c/i2c.txt are
> +valid here.
> +
> +New required properties:
> +------------------------
> +- i3c-lvr: 32 bits integer property (only the lowest 8 bits are meaningful)
> + describing device capabilities as described in the I3C
> + specification.
> +
> + bit[31:8]: unused
> + bit[7:5]: I2C device index. Possible values
> + * 0: I2C device has a 50 ns spike filter
> + * 1: I2C device does not have a 50 ns spike filter but supports high
> + frequency on SCL
> + * 2: I2C device does not have a 50 ns spike filter and is not
> + tolerant to high frequencies
> + * 3-7: reserved
> +
> + bit[4]: tell whether the device operates in FM or FM+ mode
> + * 0: FM+ mode
> + * 1: FM mode
> +
> + bit[3:0]: device type
> + * 0-15: reserved
> +
> +I3C devices
> +===========
> +
> +All I3C devices are supposed to support DAA (Dynamic Address Assignment), and
> +are thus discoverable. So, by default, I3C devices do not have to be described
> +in the device tree.
> +This being said, one might want to attach extra resources to these devices,
> +and those resources may have to be described in the device tree, which in turn
> +means we have to describe I3C devices.
> +
> +Another use case for describing an I3C device in the device tree is when this
> +I3C device has a static address and we want to assign it a specific dynamic
> +address before the DAA takes place (so that other devices on the bus can't
> +take this dynamic address).
> +
> +Required properties
> +-------------------
> +- i3c-pid: PID (Provisional ID). 64-bit property which is used to match a
> + device discovered during DAA with its device tree definition. The
> + PID is supposed to be unique on a given bus, which guarantees a 1:1
> + match. This property becomes optional if a reg property is defined,
> + meaning that the device has a static address.
What determines this number?
> +
> +Optional properties
> +-------------------
> +- reg: static address. Only valid is the device has a static address.
> +- i3c-dynamic-address: dynamic address to be assigned to this device. This
> + property depends on the reg property.
Perhaps "assigned-address" property would be appropriate. I'm not all
that familiar with it though.
> +
> +Example:
> +
> + i3c-master@0d040000 {
Drop leading 0.
> + compatible = "cdns,i3c-master";
> + clocks = <&coreclock>, <&i3csysclock>;
> + clock-names = "pclk", "sysclk";
> + interrupts = <3 0>;
> + reg = <0x0d040000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + status = "okay";
> + i2c-scl-frequency = <100000>;
> +
> + /* I2C device. */
> + nunchuk: nunchuk@52 {
> + compatible = "nintendo,nunchuk";
> + reg = <0x52>;
> + i3c-lvr = <0x10>;
> + };
> +
> + /* I3C device with a static address. */
> + thermal_sensor: sensor@68 {
> + reg = <0x68>;
> + i3c-dynamic-address = <0xa>;
> + };
> +
> + /*
> + * I3C device without a static address but requiring resources
> + * described in the DT.
> + */
> + sensor2 {
It's not great that we can't follow using generic node names. Maybe the
PID can be used as the address? In USB for example, we use hub ports for
DT addresses rather than USB addresses since those are dynamic.
> + i3c-pid = /bits/ 64 <0x39200144004>;
> + clocks = <&clock_provider 0>;
> + };
> + };
> +
> --
> 2.11.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox