* [RFC PATCH 1/3] dt-bindings: Add ARM PSA FF binding for non-secure VM partitions
From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw)
To: Will Deacon, devicetree, linux-arm-kernel
Cc: Sudeep Holla, linux-kernel, Marc Zyngier
In-Reply-To: <20200601094512.50509-1-sudeep.holla@arm.com>
Add devicetree bindings for a Arm PSA FF-A compliant non-secure partition
at virtual interface(VMs).
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
.../devicetree/bindings/arm/arm,psa-ffa.txt | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
diff --git a/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
new file mode 100644
index 000000000000..ee543fb5b397
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
@@ -0,0 +1,47 @@
+Arm Platform Security Architecture(PSA) Firmware Framework(FF) for Armv8-A
+--------------------------------------------------------------------------
+
+This binding is intended to define the interface the firmware framework
+implementing the Non-secure partitions/endpoints(mostly VMs) as described
+in ARM document ARM DEN 0077A ("Arm Platform Security Architecture
+Firmware Framework for Arm v8-A") [0]
+
+In the case of a Non-secure virtual FF-A instance, the hypervisor
+(e.g. Linux KVM) can use this binding to create and launch VM partitions.
+
+The SMCCC conduit available in the VM partition itself is used and hence
+there is no explicit binding to specify the conduit used for PSA FFA
+interface.
+
+Required properties:
+
+- compatible : Should be one of:
+ "arm,psa-ffa"
+
+- One or more child nodes, each describing an PSA FFA partition using the
+ following required properties:
+
+ - compatible: Should be one of:
+ "arm,psa-ffa-partition"
+
+ - uuid : The 128-bit UUID [2] of the service implemented by this partition,
+ represented as a string.
+
+[0] https://developer.arm.com/docs/den0077/latest
+[1] https://tools.ietf.org/html/rfc4122
+
+Example:
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ firmware {
+ psa-ffa {
+ compatible = "arm,psa-ffa";
+
+ partition0: psa_ffa_partition {
+ compatible = "arm,psa-ffa-partition";
+ uuid = "12345678-9abc-def0-1234-56789abcdef0";
+ };
+ };
+ };
--
2.17.1
^ permalink raw reply related
* [RFC PATCH 0/3] firmware: Add support for PSA FF-A interface
From: Sudeep Holla @ 2020-06-01 9:45 UTC (permalink / raw)
To: Will Deacon, devicetree, linux-arm-kernel
Cc: Sudeep Holla, linux-kernel, Marc Zyngier
Hi All,
Sorry for posting in the middle of merge window and I must have done
this last week itself. This is not the driver I had thought about posting
last week. After I started cleaning up and looking at Will's KVM prototype[1]
for PSA FF-A (previously known as SPCI), I got more doubts on alignment
and dropped huge chunk of interface APIs in the driver in order to keep
it simple, and get aligned more with that prototype and avoid scanning
lots of code unnecessary.
Here are few things to clarify:
1. DT bindings
---------------
I was initially against adding bindings for Tx/Rx buffers for
partitions. As per the spec, an endpoint could allocate the
buffer pair and use the FFA_RXTX_MAP interface to map it with the
Hypervisor(KVM here). However looking at the prototype and also
I remember you mentioning that it is not possible to manage buffers
in that way. Please confirm if you plan to add the buffer details
fetcthing them through ioctls in KVM and adding them to VM DT nodes
in KVM userspace. I will update the bindings accordingly.
2. Driver
---------
a. Support for multiple partitions in a VM
------------------------------------------
I am not sure if there is need for supporting multiple partitions
within a VM. It should be possible to do so as I expect to create
device for each partition entry under arm-psa-ffa devicetree node.
However, I don't want to assume something that will never be a
usecase. However I don't think this will change must of the
abstraction as we need to keep the interface API implementation
separate to support different partitions on various platforms.
b. SMCCC interface
------------------
This is something I messed up completely while trying to add
support for SMCCC v1.2. It now supports x0-x17 as parameter
registers(input) and return registers(output). I started simple
with x0-x7 as both input and output as PSA FF-A needs that at
most. But extending to x0-x17 then became with messy in my
implementation. That's the reason I dropped it completely
here and thought of checking it first.
Do we need to extend the optimisations that were done to handle
ARCH_WORKAROUND_{1,2}. Or should be just use a version with x0-x7
as both input and ouput. Hyper-V guys need full x0-x17 support.
I need some guidance as what is the approach preferred ?
3. Partitions
-------------
I am not sure if we have a full define partition that we plan to
push upstream. Without one, we can have a sample/example partition
to test all the interface APIs, but is that fine with respect to
what we want upstream ? Any other thoughts that helps to test the
driver ?
Sorry for long email and too many questions, but I thought it is easier
this way to begin with than throwing huge code implementing loads of APIs
with no users(expect example partition) especially that I am posting this
during merge window.
Sudeep Holla (3):
dt-bindings: Add ARM PSA FF binding for non-secure VM partitions
firmware: Add support for PSA FF-A transport for VM partitions
firmware: Add example PSA FF-A non-secure VM partition
.../devicetree/bindings/arm/arm,psa-ffa.txt | 47 ++++
drivers/firmware/Kconfig | 1 +
drivers/firmware/Makefile | 1 +
drivers/firmware/arm_psa_ffa/Kconfig | 22 ++
drivers/firmware/arm_psa_ffa/Makefile | 3 +
drivers/firmware/arm_psa_ffa/driver.c | 250 ++++++++++++++++++
drivers/firmware/arm_psa_ffa/partition.c | 71 +++++
include/linux/arm_psa_ffa.h | 42 +++
8 files changed, 437 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/arm,psa-ffa.txt
create mode 100644 drivers/firmware/arm_psa_ffa/Kconfig
create mode 100644 drivers/firmware/arm_psa_ffa/Makefile
create mode 100644 drivers/firmware/arm_psa_ffa/driver.c
create mode 100644 drivers/firmware/arm_psa_ffa/partition.c
create mode 100644 include/linux/arm_psa_ffa.h
--
2.17.1
^ permalink raw reply
* RE: [PATCH V3 2/3] arm64: dts: imx8m: add mu node
From: Aisheng Dong @ 2020-06-01 9:44 UTC (permalink / raw)
To: Peng Fan, shawnguo@kernel.org, Fabio Estevam,
kernel@pengutronix.de, robh+dt@kernel.org, sboyd@kernel.org,
linux@rempel-privat.de, jaswinder.singh@linaro.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Leonard Crestez,
Daniel Baluta, l.stach@pengutronix.de, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <1590999602-29482-3-git-send-email-peng.fan@nxp.com>
> From: Peng Fan <peng.fan@nxp.com>
> Sent: Monday, June 1, 2020 4:20 PM
>
> Add mu node to let A53 could communicate with M Core.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Regards
Aisheng
^ permalink raw reply
* Re: [RFC PATCH v5 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
From: Sylwester Nawrocki @ 2020-06-01 9:40 UTC (permalink / raw)
To: Chanwoo Choi
Cc: Georgi Djakov, Chanwoo Choi, Krzysztof Kozlowski,
Artur Świgoń, MyungJoo Ham, inki.dae, Seung-Woo Kim,
Bartlomiej Zolnierkiewicz, Marek Szyprowski, linux-kernel,
linux-samsung-soc, dri-devel, linux-arm-kernel, Rob Herring,
devicetree
In-Reply-To: <CAGTfZH1yM0KRaEF5VTs2juTm+yrK9VqQZxWjdNf_ffjGHWPLsg@mail.gmail.com>
Hi Chanwoo,
On 31.05.2020 02:01, Chanwoo Choi wrote:
> On Sat, May 30, 2020 at 1:32 AM Sylwester Nawrocki
> <s.nawrocki@samsung.com> wrote:
>>
>> Add documentation for new optional properties in the exynos bus nodes:
>> samsung,interconnect-parent, #interconnect-cells.
>> These properties allow to specify the SoC interconnect structure which
>> then allows the interconnect consumer devices to request specific
>> bandwidth requirements.
>>
>> Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
>> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> ---
>> Changes for v5:
>> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
>> ---
>> Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +++++++++++++--
>> 1 file changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index e71f752..e0d2daa 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -51,6 +51,11 @@ Optional properties only for parent bus device:
>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count against total cycle count.
>>
>> +Optional properties for interconnect functionality (QoS frequency constraints):
>> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
>> + passive devices should point to same node as the exynos,parent-bus property.
>> +- #interconnect-cells: should be 0
>> +
>> Detailed correlation between sub-blocks and power line according to Exynos SoC:
>> - In case of Exynos3250, there are two power line as following:
>> VDD_MIF |--- DMC
>> @@ -185,8 +190,9 @@ Example1:
>> ----------------------------------------------------------
>>
>> Example2 :
>> - The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
>> - is listed below:
>> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi is
>> + listed below. An interconnect path "bus_lcd0 -- bus_leftbus -- bus_dmc"
>> + is defined for demonstration purposes.
>>
>> bus_dmc: bus_dmc {
>> compatible = "samsung,exynos-bus";
>> @@ -376,12 +382,15 @@ Example2 :
>> &bus_dmc {
>> devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
>> vdd-supply = <&buck1_reg>; /* VDD_MIF */
>> + #interconnect-cells = <0>;
>> status = "okay";
>> };
>>
>> &bus_leftbus {
>> devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
>> vdd-supply = <&buck3_reg>;
>> + samsung,interconnect-parent = <&bus_dmc>;
>> + #interconnect-cells = <0>;
>> status = "okay";
>> };
>>
>> @@ -392,6 +401,8 @@ Example2 :
>>
>> &bus_lcd0 {
>> devfreq = <&bus_leftbus>;
>> + samsung,interconnect-parent = <&bus_leftbus>;
>> + #interconnect-cells = <0>;
>> status = "okay";
>> };
>>
>> --
>> 2.7.4
>>
>
> If you add the usage example like the mixer device of patch5 to this
> dt-binding document,
> I think it is very beneficial and more helpful for user of
> exynos-bus/exynos-generic-icc.
>
> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Thanks for review. I will make sure the example includes a consumer
in next version. Will also mention ../interconnect/interconnect.txt
in description of the #interconnect-cells property.
--
Regards,
Sylwester
^ permalink raw reply
* Re: [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
From: Jacek Anaszewski @ 2020-06-01 9:34 UTC (permalink / raw)
To: Pavel Machek, Dan Murphy; +Cc: robh, devicetree, linux-leds, linux-kernel
In-Reply-To: <20200531190625.GA30537@duo.ucw.cz>
Hi Pavel and Dan,
On 5/31/20 9:06 PM, Pavel Machek wrote:
> Hi!
>
>>>> + There can only be one instance of the ti,led-bank
>>>> + property for each device node. This is a required node is the LED
>>>> + modules are to be backed.
>>> I don't understand the second sentence. Pretty sure it is not valid
>>> english.
>>
>>
>> If I make these changes is this still viable for 5.8 or would you then go
>> into 5.9?
>
> It really depends if we get -rc8 or not, and if you'll need to do any
> changes to C code or not...
I think that we need to simmer such a big extension of the LED
subsystem for a whole cycle in linux-next, especially taking into
account addition of new sysfs interface, that is bit quirky.
Effectively 5.8 seems to not have been viable since few weeks.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* Re: [RFC v1 2/3] drivers: nvmem: Add driver for QTI qfprom-efuse support
From: Srinivas Kandagatla @ 2020-06-01 9:24 UTC (permalink / raw)
To: Doug Anderson
Cc: Ravi Kumar Bokka (Temp), Rob Herring, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rajendra Nayak, Sai Prakash Ranjan, dhavalp, mturney, sparate,
c_rbokka, mkurumel
In-Reply-To: <CAD=FV=UCwUO5aKrUj7e+v6Bpkh_O+wuSXD5tJHdGOfaVTL0t1w@mail.gmail.com>
On 26/05/2020 23:31, Doug Anderson wrote:
> Hi,
>
> On Fri, May 22, 2020 at 4:18 AM Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>>
>> On 21/05/2020 22:28, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Thu, May 21, 2020 at 8:56 AM Srinivas Kandagatla
>>> <srinivas.kandagatla@linaro.org> wrote:
>>>>
>>>> On 21/05/2020 16:10, Doug Anderson wrote:
>>>>>> On 20/05/2020 23:48, Doug Anderson wrote:
>>>>>>>> Is this only applicable for corrected address space?
>>>>>>> I guess I was proposing a two dts-node / two drive approach here.
>>>>>>>
>>>>>>> dts node #1:just covers the memory range for accessing the FEC-corrected data
>>>>>>> driver #1: read-only and reads the FEC-corrected data
>>>>>>>
>>>>>>> dts node #2: covers the memory range that's_not_ the FEC-corrected
>>>>>>> memory range.
>>>>>>> driver #2: read-write. reading reads uncorrected data
>>>>>>>
>>>>>>> Does that seem sane?
>>>>>> I see your point but it does not make sense to have two node for same thing.
>>>>> OK, so that sounds as if we want to go with the proposal where we
>>>>> "deprecate the old driver and/or bindings and say that there really
>>>>> should just be one node and one driver".
>>>>>
>>>>> Would this be acceptable to you?
>>>>>
>>>>> 1. Officially mark the old bindings as deprecated.
>>>>
>>>> Possibly Yes for some reasons below!
>>>>
>>>>>
>>>>> 2. Leave the old driver there to support the old deprecated bindings,
>>>>> at least until everyone can be transferred over. There seem to be
>>>>> quite a few existing users of "qcom,qfprom" and we're supposed to make
>>>>> an attempt at keeping the old device trees working, at least for a
>>>>> little while. Once everyone is transferred over we could decide to
>>>>> delete the old driver.
>>>> we could consider "qcom,qfrom" to be only passing corrected address
>>>> space. Till we transition users to new bindings!
>>>>
>>>>>
>>>> Yes.
>>>>
>>>>> 3. We will have a totally new driver here.
>>>> No, we should still be using the same driver. But the exiting driver
>>>> seems to incorrect and is need of fixing.
>>>>
>>>> Having a look at the memory map for old SoCs like msm8996 and msm8916
>>>> shows that memory map that was passed to qfprom driver is corrected
>>>> address space. Writes will not obviously work!
>>>>
>>>> This should also be true with sdm845 or sc7180
>>>>
>>>> That needs to be fixed first!
>>>
>>> OK, so to summarize:
>>>
>>
>>> 1. We will have one driver: "drivers/nvmem/qfprom.c"
>>
>> Yes, we should one driver for this because we are dealing with exactly
>> same IP.
>>
>>>
>>> 2. If the driver detects that its reg is pointing to the corrected
>>> address space then it should operate in read-only mode. Maybe it can
>>> do this based on the compatible string being just "qcom,qfprom" or
>>> maybe it can do this based on the size of the "reg".
>>
>> I found out that there is a version register at offset of 0x6000 which
>> can give MAJOR, MINOR and STEP numbers.
>>
>> So we could still potentially continue using "qcom,qfprom"
>
> OK, sounds good. I think it's still good practice to include both the
> SoC specific and the generic. Even if the driver never does anything
> with the SoC-specific compatible string it doesn't hurt to have it
> there. Thus, we'd want:
>
> compatible = "qcom,msm8996-qfprom", "qcom,qfprom"
>
> The driver itself would never need to refer to the SoC-specific name
> but that does give us more flexibility.
>
>
>> The address space can be split into 3 resources, which is inline with
>> Specs as well
>>
>> 1. Raw address space ("raw")
>> 2. Configuration address space ("conf" or "core")
>> 3. Corrected address space ("corrected")
>
> Sure, this is OK with me then. Originally Ravi had 3 ranges but then
> he was (in the driver) treating it as one range. As long as the
> driver truly treats it as 3 ranges I have no problem doing it like
> this.
>
> In general, over the years, there has been a push to keep
> implementation details out of the dts and rely more on the "of_match"
> table to add SoC-specific details. This becomes really important when
> 1 year down the road you realize that you need one more random
> property or address range to fix some bug and then you need to figure
> out how to try to keep old "dts" files compatible. It's not a
> hard-and-fast rule, though.
Am not 100% sure if "qcom,fuse-blow-frequency" is something integration
specific or SoC Specific, My idea was that this will give more
flexibility in future. As adding new SoC Support does not need driver
changes.
Having said that, Am okay either way!
Incase we go compatible way, I would like to see compatible strings
having proper IP versions to have ip version rather than SoC names.
Having SoC names in compatible string means both driver and bindings
need update for every new SoC which can be overhead very soon!
Rob can help review once we have v2 bindings out!
>
>
>> Exiting qfprom entries or read-only qfprom will have "corrected"
>> address space which can be the only resource provided by device tree
>> entries.
>> Other two entries("raw" and "conf") are optional.
>>
>> qfprom: qfprom@780000 {
>> compatible = "qcom,qfprom";
>> reg = <0 0x00780000 0 0x8ff>,
>> <0 0x00782000 0 0x100>,
>> <0 0x00784000 0 0x8ff>;
>> reg-names = "raw", "conf", "corrected";
>>
>> vcc-supply = <&vreg_xyz>;
>>
>> clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>;
>> clock-names = "secclk";
>>
>> assigned-clocks = <&gcc GCC_SEC_CTRL_CLK_SRC>;
>> assigned-clock-rates = <19200000>;
>>
>> qcom,fuse-blow-frequency = <4800000>
>>
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> qusb2p_hstx_trim: hstx-trim-primary@25b {
>> reg = <0x25b 0x1>;
>> bits = <1 3>;
>> };
>> };
>>
>> Regarding clk rate setting, the default rate can be set using
>> assigned-clock-rates property, however the blow frequency can go as new
>> binding.
>> regarding voltage range for regulator, it should come as part of board
>> specific voltage regulator node. In worst case we can discuss on adding
>> new bindings for allowing specific range.
>
> I'd up to you (and Rob H, who probably will wait for the next rev of
> the binding before chiming in) but the "qcom,fuse-blow-frequency" is
> the type of property that feels better in the driver and achieved from
> the of_match table. Then you don't need to worry about adding it to
> the bindings. Voltage (if needed) would be similar, but I would hope
> we don't need it.
>
>
>> for Older SoCs: we still continue to use old style with just one
>> resource corresponding to corrected by default.
>>
>> qfprom: qfprom@784000 {
>> compatible = "qcom,qfprom";
>> reg = <0 0x00784000 0 0x8ff>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> qusb2p_hstx_trim: hstx-trim-primary@1eb {
>> reg = <0x1eb 0x1>;
>> bits = <1 4>;
>> };
>>
>> qusb2s_hstx_trim: hstx-trim-secondary@1eb {
>> reg = <0x1eb 0x2>;
>> bits = <6 4>;
>> };
>> };
>>
>>
>> I see the patch as adding write support to qfprom, rather than adding
>> new driver or new SoC support.
>>
>> This in summary should give us good direction for this patch!
>>
>> Correct me if I miss understood something here!
>
> Sounds sane to me.
Cool! lets see how v2 will endup like!
--srini
>
>
> -Doug
>
^ permalink raw reply
* Re: [Linux-stm32] [PATCH v8 08/10] drm: stm: dw-mipi-dsi: let the bridge handle the HW version check
From: Adrian Ratiu @ 2020-06-01 9:15 UTC (permalink / raw)
To: Philippe CORNU, Adrian Ratiu,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-rockchip@lists.infradead.org, Laurent Pinchart
Cc: Jernej Skrabec, Heiko Stuebner, Adrian Pop, Jonas Karlman,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Andrzej Hajda, linux-imx@nxp.com, kernel@collabora.com,
linux-stm32@st-md-mailman.stormreply.com, Arnaud Ferraris,
Yannick FERTRE, Benjamin GAIGNARD
In-Reply-To: <4acc09e8-0610-01f6-b18d-3ffc390c45a3@st.com>
On Fri, 29 May 2020, Philippe CORNU <philippe.cornu@st.com> wrote:
> Hi Adrian, and thank you very much for the patchset. Thank you
> also for having tested it on STM32F769 and STM32MP1. Sorry for
> the late response, Yannick and I will review it as soon as
> possible and we will keep you posted. Note: Do not hesitate to
> put us in copy for the next version (philippe.cornu@st.com,
> yannick.fertre@st.com) Regards, Philippe :-)
Hi Philippe,
Thank you very much for your previous and future STM testing,
really appreciate it! I've CC'd Yannick until now but I'll also CC
you sure :)
It's been over a month since I posted v8 and I was just gearing up
to address all feedback, rebase & retest to prepare v9 but I'll
wait a little longer, no problem, it's no rush.
Have an awesome day,
Adrian
>
>
> On 4/27/20 10:19 AM, Adrian Ratiu wrote:
>> The stm mipi-dsi platform driver added a version test in
>> commit fa6251a747b7 ("drm/stm: dsi: check hardware version")
>> so that HW revisions other than v1.3x get rejected. The rockchip
>> driver had no such check and just assumed register layouts are
>> v1.3x compatible.
>>
>> Having such tests was a good idea because only v130/v131 layouts
>> were supported at the time, however since adding multiple layout
>> support in the bridge, the version is automatically checked for
>> all drivers, compatible layouts get picked and unsupported HW is
>> automatically rejected by the bridge, so there's no use keeping
>> the test in the stm driver.
>>
>> The main reason prompting this change is that the stm driver
>> test immediately disabled the peripheral clock after reading
>> the version, making the bridge read version 0x0 immediately
>> after in its own probe(), so we move the clock disabling after
>> the bridge does the version test.
>>
>> Tested on STM32F769 and STM32MP1.
>>
>> Cc: linux-stm32@st-md-mailman.stormreply.com
>> Reported-by: Adrian Pop <pop.adrian61@gmail.com>
>> Tested-by: Adrian Pop <pop.adrian61@gmail.com>
>> Tested-by: Arnaud Ferraris <arnaud.ferraris@collabora.com>
>> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
>> ---
>> New in v6.
>> ---
>> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 12 +++---------
>> 1 file changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> index 2e1f2664495d0..7218e405d7e2b 100644
>> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
>> @@ -402,15 +402,6 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
>> goto err_dsi_probe;
>> }
>>
>> - dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
>> - clk_disable_unprepare(pclk);
>> -
>> - if (dsi->hw_version != HWVER_130 && dsi->hw_version != HWVER_131) {
>> - ret = -ENODEV;
>> - DRM_ERROR("bad dsi hardware version\n");
>> - goto err_dsi_probe;
>> - }
>> -
>> dw_mipi_dsi_stm_plat_data.base = dsi->base;
>> dw_mipi_dsi_stm_plat_data.priv_data = dsi;
>>
>> @@ -423,6 +414,9 @@ static int dw_mipi_dsi_stm_probe(struct platform_device *pdev)
>> goto err_dsi_probe;
>> }
>>
>> + dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
>> + clk_disable_unprepare(pclk);
>> +
>> return 0;
>>
>> err_dsi_probe:
>>
^ permalink raw reply
* Re: [PATCH v6 07/11] i2c: designware: Discard Cherry Trail model flag
From: Jarkko Nikula @ 2020-06-01 8:54 UTC (permalink / raw)
To: Andy Shevchenko, Serge Semin
Cc: Wolfram Sang, Mika Westerberg, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Rob Herring, linux-mips, devicetree,
linux-i2c, linux-kernel
In-Reply-To: <20200528100635.GH1634618@smile.fi.intel.com>
On 5/28/20 1:06 PM, Andy Shevchenko wrote:
> On Thu, May 28, 2020 at 12:33:17PM +0300, Serge Semin wrote:
>> A PM workaround activated by the flag MODEL_CHERRYTRAIL has been removed
>> since commit 9cbeeca05049 ("i2c: designware: Remove Cherry Trail PMIC I2C
>> bus pm_disabled workaround"), but the flag most likely by mistake has been
>> left in the Dw I2C drivers. Let's remove it. Since MODEL_MSCC_OCELOT is
>> the only model-flag left, redefine it to be 0x100 so setting a very first
>> bit in the MODEL_MASK bits range.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Conditionally, in case Wolfram and Jarkko are fine with shuffling model
> defines, which I consider an unneeded churn.
>
>> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
>> Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
I completely agree with Andy and more over, I didn't ack this version.
This was the version I acked:
https://www.spinics.net/lists/linux-i2c/msg45492.html
So in general please drop the received tags in case you decide to modify
patch since reviewers may not agree anymore with it.
That said, I'm fine with that minor code and commit log change. And
don't want to have yet another patchset version because it. Four
patchset versions during 2 days is a bit too much... Usual
recommendation is to wait for 1 week before posting a new version
especially if patchset is under active discussion.
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
^ permalink raw reply
* [PATCH v1 6/6] drm: panel-simple: add LOGIC Technologies panels
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
In-Reply-To: <20200601083309.712606-1-sam@ravnborg.org>
Add support for the following panels from LOGIC Technologies, Inc:
- LTTD800480070-L2RT
- LTTD800480070-L6WH-RT
The LTTD800480 L2RT is discontinued, but it may be used
by existing products.
Signed-off-by: Søren Andersen <san@skov.dk>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Søren Andersen <san@skov.dk>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
drivers/gpu/drm/panel/panel-simple.c | 70 ++++++++++++++++++++++++++++
1 file changed, 70 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 25c96639631f..70d54164b1ae 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2428,6 +2428,70 @@ static const struct panel_desc logictechno_lt170410_2whc = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode logictechno_lttd800480070_l2rt_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 112,
+ .hsync_end = 800 + 112 + 3,
+ .htotal = 800 + 112 + 3 + 85,
+ .vdisplay = 480,
+ .vsync_start = 480 + 38,
+ .vsync_end = 480 + 38 + 3,
+ .vtotal = 480 + 38 + 3 + 29,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc logictechno_lttd800480070_l2rt = {
+ .modes = &logictechno_lttd800480070_l2rt_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 45,
+ .enable = 100,
+ .disable = 100,
+ .unprepare = 45
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
+static const struct drm_display_mode logictechno_lttd800480070_l6wh_rt_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 154,
+ .hsync_end = 800 + 154 + 3,
+ .htotal = 800 + 154 + 3 + 43,
+ .vdisplay = 480,
+ .vsync_start = 480 + 47,
+ .vsync_end = 480 + 47 + 3,
+ .vtotal = 480 + 47 + 3 + 20,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc logictechno_lttd800480070_l6wh_rt = {
+ .modes = &logictechno_lttd800480070_l6wh_rt_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .prepare = 45,
+ .enable = 100,
+ .disable = 100,
+ .unprepare = 45
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -3841,6 +3905,12 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "logictechno,lt170410-2whc",
.data = &logictechno_lt170410_2whc,
+ }, {
+ .compatible = "logictechno,lttd800480070-l2rt",
+ .data = &logictechno_lttd800480070_l2rt,
+ }, {
+ .compatible = "logictechno,lttd800480070-l6wh-rt",
+ .data = &logictechno_lttd800480070_l6wh_rt,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = &mitsubishi_aa070mc01,
--
2.25.1
^ permalink raw reply related
* [PATCH v1 5/6] dt-bindings: panel: add LOGIC Technologies panels
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
In-Reply-To: <20200601083309.712606-1-sam@ravnborg.org>
Add support for the following panels from LOGIC Technologies, Inc:
- LTTD800480070-L2RT
- LTTD800480070-L6WH-RT
The LTTD800480 L2RT is discontinued, but it may be used in
existing products.
Both panels are dumb panels that matches the panel-simple binding.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Søren Andersen <san@skov.dk>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 6fe0ac86696d..a4910d4af96b 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -183,6 +183,10 @@ properties:
- logictechno,lt161010-2nhr
# Logic Technologies LT170410-2WHC 10.1" 1280x800 IPS TFT Cap Touch Mod.
- logictechno,lt170410-2whc
+ # LOGIC Technologies Inc. LTTD800480070-L2RT 7" (800x480) TFT LCD panel
+ - logictechno,lttd800480070-l2rt
+ # LOGIC Technologies Inc. LTTD800480070-L6WH-RT 7" (800x480) TFT LCD panel
+ - logictechno,lttd800480070-l6wh-rt
# Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel
- mitsubishi,aa070mc01-ca1
# NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel
--
2.25.1
^ permalink raw reply related
* [PATCH v1 2/6] drm: panel-simple: add Seiko 70WVW2T 7" simple panel
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
In-Reply-To: <20200601083309.712606-1-sam@ravnborg.org>
The Seiko 70WVW2T is a discontinued product, but may be used somewhere.
Tested on a proprietary product.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Søren Andersen <san@skov.dk>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index b067f66cea0e..8624bb80108c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3194,6 +3194,31 @@ static const struct panel_desc shelly_sca07010_bfn_lnn = {
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct drm_display_mode sii_70wvw2t_mode = {
+ .clock = 33000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 256,
+ .hsync_end = 800 + 256 + 0,
+ .htotal = 800 + 256 + 0 + 0,
+ .vdisplay = 480,
+ .vsync_start = 480 + 0,
+ .vsync_end = 480 + 0 + 0,
+ .vtotal = 480 + 0 + 0 + 45,
+ .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc sii_70wvw2t = {
+ .modes = &sii_70wvw2t_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode starry_kr070pe2t_mode = {
.clock = 33000,
.hdisplay = 800,
@@ -3877,6 +3902,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
+ }, {
+ .compatible = "sii,70wvw2t",
+ .data = &sii_70wvw2t,
}, {
.compatible = "starry,kr070pe2t",
.data = &starry_kr070pe2t,
--
2.25.1
^ permalink raw reply related
* [PATCH v1 0/6] drm: add a few simple panels
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
Push a few patches that has been sitting in my tree for
far too long time.
Adds a few more panels to panel-simple, including
documentation of the compatible.
I have added the last few people that added new
panels to panel-simple to the cc list,
in the hope to speed up the review process a little.
Sam
Sam Ravnborg (6):
dt-bindings: panel: add Seiko 70WVW2T 7" panel
drm: panel-simple: add Seiko 70WVW2T 7" simple panel
dt-bindings: panel: add Hitachi 3,5" QVGA panel
drm: panel-simple: add Hitachi 3.5" QVGA panel
dt-bindings: panel: add LOGIC Technologies panels
drm: panel-simple: add LOGIC Technologies panels
.../bindings/display/panel/panel-simple.yaml | 8 ++
drivers/gpu/drm/panel/panel-simple.c | 127 +++++++++++++++++++++
2 files changed, 135 insertions(+)
^ permalink raw reply
* [PATCH v1 4/6] drm: panel-simple: add Hitachi 3.5" QVGA panel
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
In-Reply-To: <20200601083309.712606-1-sam@ravnborg.org>
This panel is used on evaluation boards for Atmel at91sam9261 and
at91sam6263.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
drivers/gpu/drm/panel/panel-simple.c | 29 ++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 8624bb80108c..25c96639631f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1813,6 +1813,32 @@ static const struct panel_desc hannstar_hsd100pxn1 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode hitachi_tx09d71vm1cca_mode = {
+ .clock = 4965000,
+ .hdisplay = 240,
+ .hsync_start = 240 + 0,
+ .hsync_end = 240 + 0 + 5,
+ .htotal = 240 + 0 + 5 + 1,
+ .vdisplay = 320,
+ .vsync_start = 320 + 0,
+ .vsync_end = 320 + 0 + 1,
+ .vtotal = 320 + 0 + 1 + 1,
+ .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc hitachi_tx09d71vm1cca = {
+ .modes = &hitachi_tx09d71vm1cca_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 54,
+ .height = 72,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_NEGEDGE,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode hitachi_tx23d38vm0caa_mode = {
.clock = 33333,
.hdisplay = 800,
@@ -3737,6 +3763,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "hannstar,hsd100pxn1",
.data = &hannstar_hsd100pxn1,
+ }, {
+ .compatible = "hit,tx09d71vm1cca",
+ .data = &hitachi_tx09d71vm1cca,
}, {
.compatible = "hit,tx23d38vm0caa",
.data = &hitachi_tx23d38vm0caa
--
2.25.1
^ permalink raw reply related
* [PATCH v1 3/6] dt-bindings: panel: add Hitachi 3,5" QVGA panel
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
In-Reply-To: <20200601083309.712606-1-sam@ravnborg.org>
This panel is used on evaluation boards for Atmel at91sam9261 and
at91sam6263.
The panel is named: TX09D71VM1CCA
The panel is a dumb panel that matches the panel-simple binding
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 60cc093fbd75..6fe0ac86696d 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -133,6 +133,8 @@ properties:
- hannstar,hsd070pww1
# HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel
- hannstar,hsd100pxn1
+ # Hitachi Ltd. Corporation 3,5" QVGA (240x320) TFT LCD panel
+ - hit,tx09d71vm1cca
# Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel
- hit,tx23d38vm0caa
# InfoVision Optoelectronics M133NWF4 R0 13.3" FHD (1920x1080) TFT LCD panel
--
2.25.1
^ permalink raw reply related
* [PATCH v1 1/6] dt-bindings: panel: add Seiko 70WVW2T 7" panel
From: Sam Ravnborg @ 2020-06-01 8:33 UTC (permalink / raw)
To: dri-devel, devicetree
Cc: Sam Ravnborg, Søren Andersen, Thierry Reding,
Ville Syrjälä, Douglas Anderson, Bjorn Andersson,
Sebastian Reichel
In-Reply-To: <20200601083309.712606-1-sam@ravnborg.org>
Add compatible for Seiko Instruments 7" TFT LCD.
This panel is a dumb panel that matches the panel-simple binding.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Søren Andersen <san@skov.dk>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
.../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index d6cca1479633..60cc093fbd75 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -239,6 +239,8 @@ properties:
- sharp,ls020b1dd01d
# Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel
- shelly,sca07010-bfn-lnn
+ # Seiko Instruments Inc. 7.0" WVGA (800x480) TFT with Touch-Panel
+ - sii,70wvw2t
# Starry KR070PE2T 7" WVGA TFT LCD panel
- starry,kr070pe2t
# Starry 12.2" (1920x1200 pixels) TFT LCD panel
--
2.25.1
^ permalink raw reply related
* [PATCH V3 3/3] clk: imx8mp: add mu root clk
From: peng.fan @ 2020-06-01 8:20 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
In-Reply-To: <1590999602-29482-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add mu root clk for mu mailbox usage.
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/clk/imx/clk-imx8mp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index b4d9db9d5bf1..ca747712400f 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -680,6 +680,7 @@ static int imx8mp_clocks_probe(struct platform_device *pdev)
hws[IMX8MP_CLK_I2C2_ROOT] = imx_clk_hw_gate4("i2c2_root_clk", "i2c2", ccm_base + 0x4180, 0);
hws[IMX8MP_CLK_I2C3_ROOT] = imx_clk_hw_gate4("i2c3_root_clk", "i2c3", ccm_base + 0x4190, 0);
hws[IMX8MP_CLK_I2C4_ROOT] = imx_clk_hw_gate4("i2c4_root_clk", "i2c4", ccm_base + 0x41a0, 0);
+ hws[IMX8MP_CLK_MU_ROOT] = imx_clk_hw_gate4("mu_root_clk", "ipg_root", ccm_base + 0x4210, 0);
hws[IMX8MP_CLK_OCOTP_ROOT] = imx_clk_hw_gate4("ocotp_root_clk", "ipg_root", ccm_base + 0x4220, 0);
hws[IMX8MP_CLK_PCIE_ROOT] = imx_clk_hw_gate4("pcie_root_clk", "pcie_aux", ccm_base + 0x4250, 0);
hws[IMX8MP_CLK_PWM1_ROOT] = imx_clk_hw_gate4("pwm1_root_clk", "pwm1", ccm_base + 0x4280, 0);
--
2.16.4
^ permalink raw reply related
* [PATCH V3 2/3] arm64: dts: imx8m: add mu node
From: peng.fan @ 2020-06-01 8:20 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
In-Reply-To: <1590999602-29482-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add mu node to let A53 could communicate with M Core.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 ++++++++
4 files changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index aaf6e71101a1..d9e787ea246f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -775,6 +775,14 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MM_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b40000 {
compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 9a4b65a267d4..3dca1fb34ea3 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -675,6 +675,14 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MN_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b40000 {
compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc";
reg = <0x30b40000 0x10000>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 45e2c0a4e889..1bc14bb44d90 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -621,6 +621,14 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MP_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
i2c5: i2c@30ad0000 {
compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 978f8122c0d2..3e762919d61f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -959,6 +959,14 @@
status = "disabled";
};
+ mu: mailbox@30aa0000 {
+ compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
+ reg = <0x30aa0000 0x10000>;
+ interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk IMX8MQ_CLK_MU_ROOT>;
+ #mbox-cells = <2>;
+ };
+
usdhc1: mmc@30b40000 {
compatible = "fsl,imx8mq-usdhc",
"fsl,imx7d-usdhc";
--
2.16.4
^ permalink raw reply related
* [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: peng.fan @ 2020-06-01 8:20 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
In-Reply-To: <1590999602-29482-1-git-send-email-peng.fan@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
index 26b7a88c2fea..906377acf2cd 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
@@ -18,7 +18,8 @@ Messaging Unit Device Node:
Required properties:
-------------------
- compatible : should be "fsl,<chip>-mu", the supported chips include
- imx6sx, imx7s, imx8qxp, imx8qm.
+ imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
+ imx8mp.
The "fsl,imx6sx-mu" compatible is seen as generic and should
be included together with SoC specific compatible.
There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
--
2.16.4
^ permalink raw reply related
* [PATCH V3 0/3] imx8m: add mu support
From: peng.fan @ 2020-06-01 8:19 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux, jaswinder.singh
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
V3:
Add R-b tag
Remove undocumented property
V2:
Add dt-bindings
Merge dts changes into one patch, since all is to add mu node
Add mu dt bindings
Add mu node
Add i.MX8MP mu root clk
Peng Fan (3):
dt-bindings: mailbox: imx-mu: support i.MX8M
arm64: dts: imx8m: add mu node
clk: imx8mp: add mu root clk
Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 ++++++++
drivers/clk/imx/clk-imx8mp.c | 1 +
6 files changed, 35 insertions(+), 1 deletion(-)
--
2.16.4
^ permalink raw reply
* Re: [RFC PATCH v5 1/6] dt-bindings: exynos-bus: Add documentation for interconnect properties
From: Sylwester Nawrocki @ 2020-06-01 8:19 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: a.swigon, myungjoo.ham, inki.dae, sw0312.kim, b.zolnierkie,
m.szyprowski, linux-kernel, linux-samsung-soc, dri-devel,
linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200529163200.18031-2-s.nawrocki@samsung.com>
Cc: Rob, devicetree ML
On 29.05.2020 18:31, Sylwester Nawrocki wrote:
> Add documentation for new optional properties in the exynos bus nodes:
> samsung,interconnect-parent, #interconnect-cells.
> These properties allow to specify the SoC interconnect structure which
> then allows the interconnect consumer devices to request specific
> bandwidth requirements.
>
> Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
> ---
> Changes for v5:
> - exynos,interconnect-parent-node renamed to samsung,interconnect-parent
> ---
> Documentation/devicetree/bindings/devfreq/exynos-bus.txt | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index e71f752..e0d2daa 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -51,6 +51,11 @@ Optional properties only for parent bus device:
> - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count against total cycle count.
>
> +Optional properties for interconnect functionality (QoS frequency constraints):
> +- samsung,interconnect-parent: phandle to the parent interconnect node; for
> + passive devices should point to same node as the exynos,parent-bus property.
> +- #interconnect-cells: should be 0
> +
> Detailed correlation between sub-blocks and power line according to Exynos SoC:
> - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC
> @@ -185,8 +190,9 @@ Example1:
> ----------------------------------------------------------
>
> Example2 :
> - The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
> - is listed below:
> + The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi is
> + listed below. An interconnect path "bus_lcd0 -- bus_leftbus -- bus_dmc"
> + is defined for demonstration purposes.
>
> bus_dmc: bus_dmc {
> compatible = "samsung,exynos-bus";
> @@ -376,12 +382,15 @@ Example2 :
> &bus_dmc {
> devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> vdd-supply = <&buck1_reg>; /* VDD_MIF */
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> &bus_leftbus {
> devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> vdd-supply = <&buck3_reg>;
> + samsung,interconnect-parent = <&bus_dmc>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> @@ -392,6 +401,8 @@ Example2 :
>
> &bus_lcd0 {
> devfreq = <&bus_leftbus>;
> + samsung,interconnect-parent = <&bus_leftbus>;
> + #interconnect-cells = <0>;
> status = "okay";
> };
>
> --
> 2.7.4
^ permalink raw reply
* Re: [RFC PATCH v5 0/6] Exynos: Simple QoS for exynos-bus using interconnect
From: Sylwester Nawrocki @ 2020-06-01 8:17 UTC (permalink / raw)
To: georgi.djakov, cw00.choi, krzk
Cc: a.swigon, myungjoo.ham, inki.dae, sw0312.kim, b.zolnierkie,
m.szyprowski, linux-kernel, linux-samsung-soc, dri-devel,
linux-arm-kernel, Rob Herring, devicetree
In-Reply-To: <20200529163200.18031-1-s.nawrocki@samsung.com>
Cc: Rob, devicetree ML
On 29.05.2020 18:31, Sylwester Nawrocki wrote:
> This patchset adds interconnect API support for the Exynos SoC "samsung,
> exynos-bus" compatible devices, which already have their corresponding
> exynos-bus driver in the devfreq subsystem. Complementing the devfreq driver
> with an interconnect functionality allows to ensure the QoS requirements
> of devices accessing the system memory (e.g. video processing devices)
> are fulfilled and to avoid issues like the one discussed in thread [1].
>
> This patch series depends on 3 patches from Artur for the interconnect API
> [2], which introduce following changes:
>
> - exporting of_icc_get_from_provider() to avoid hard coding every graph
> edge in the DT or driver source,
> - relaxing the requirement on #interconnect-cells, so there is no need
> to provide dummy node IDs in the DT,
> - adding new field in struct icc_provider to explicitly allow configuring
> node pairs from two different providers.
>
> This series adds implementation of interconnect provider per each "samsung,
> exynos-bus" compatible DT node, with one interconnect node per provider.
> The interconnect code which was previously added as a part of the devfreq
> driver has been converted to a separate platform driver. In the devfreq
> a corresponding virtual child platform device is registered. Integration
> of devfreq and interconnect frameworks is achieved through the PM QoS API.
>
> A sample interconnect consumer for exynos-mixer is added in patches 5/6,
> 6/6, it is currently added only for exynos4412 and allows to address the
> mixer DMA underrun error issues [1].
>
> The series has been tested on Odroid U3 board. It is based on icc-next
> branch with devfreq-next branch merged and patches [2] applied.
>
> --
> Regards,
> Sylwester
>
> --
> Changes since v3 [3] (v4 skipped to align with patchset [1]), detailed
> changes are listed at each patch:
> - conversion to a separate interconnect (platform) driver,
> - an update of the DT binding documenting new optional properties:
> #interconnect-cells, samsung,interconnect-parent in "samsung,exynos-bus"
> nodes,
> - new DT properties added to the SoC, rather than to the board specific
> files.
>
> Changes since v2 [5]:
> - Use icc_std_aggregate().
> - Implement a different modification of apply_constraints() in
> drivers/interconnect/core.c (patch 03).
> - Use 'exynos,interconnect-parent-node' in the DT instead of
> 'devfreq'/'parent', depending on the bus.
> - Rebase on DT patches that deprecate the 'devfreq' DT property.
> - Improve error handling, including freeing generated IDs on failure.
> - Remove exynos_bus_icc_connect() and add exynos_bus_icc_get_parent().
>
> Changes since v1 [4]:
> - Rebase on coupled regulators patches.
> - Use dev_pm_qos_*() API instead of overriding frequency in
> exynos_bus_target().
> - Use IDR for node ID allocation.
> - Reverse order of multiplication and division in
> mixer_set_memory_bandwidth() (patch 07) to avoid integer overflow.
>
>
> References:
> [1] https://patchwork.kernel.org/patch/10861757/ (original issue)
> [2] https://www.spinics.net/lists/linux-samsung-soc/msg70014.html
> [3] https://lore.kernel.org/linux-pm/20191220115653.6487-1-a.swigon@samsung.com
> [4] https://patchwork.kernel.org/cover/11054417/ (v1 of this RFC)
> [5] https://patchwork.kernel.org/cover/11152595/ (v2 of this RFC)
>
>
> Artur Świgoń (1):
> ARM: dts: exynos: Add interconnects to Exynos4412 mixer
>
> Marek Szyprowski (1):
> drm: exynos: mixer: Add interconnect support
>
> Sylwester Nawrocki (4):
> dt-bindings: exynos-bus: Add documentation for interconnect properties
> interconnect: Add generic interconnect driver for Exynos SoCs
> PM / devfreq: exynos-bus: Add registration of interconnect child
> device
> ARM: dts: exynos: Add interconnect properties to Exynos4412 bus nodes
>
> .../devicetree/bindings/devfreq/exynos-bus.txt | 15 +-
> arch/arm/boot/dts/exynos4412.dtsi | 6 +
> drivers/devfreq/exynos-bus.c | 17 ++
> drivers/gpu/drm/exynos/exynos_mixer.c | 73 +++++++-
> drivers/interconnect/Kconfig | 1 +
> drivers/interconnect/Makefile | 1 +
> drivers/interconnect/exynos/Kconfig | 6 +
> drivers/interconnect/exynos/Makefile | 4 +
> drivers/interconnect/exynos/exynos.c | 185 +++++++++++++++++++++
> 9 files changed, 301 insertions(+), 7 deletions(-)
> create mode 100644 drivers/interconnect/exynos/Kconfig
> create mode 100644 drivers/interconnect/exynos/Makefile
> create mode 100644 drivers/interconnect/exynos/exynos.c
^ permalink raw reply
* [PATCH 2/2] dt-bindings: power: Convert imx gpcv2 to json-schema
From: Anson Huang @ 2020-06-01 8:06 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, ulf.hansson, sboyd,
krzk, p.zabel, andrew.smirnov, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1590998803-29191-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX GPCv2 binding to DT schema format using json-schema
Example is updated based on latest DT file and consumer's example is
removed since it is NOT that useful.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/power/fsl,imx-gpcv2.txt | 77 ---------------
.../devicetree/bindings/power/fsl,imx-gpcv2.yaml | 108 +++++++++++++++++++++
2 files changed, 108 insertions(+), 77 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
deleted file mode 100644
index 6164920..0000000
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
+++ /dev/null
@@ -1,77 +0,0 @@
-Freescale i.MX General Power Controller v2
-==========================================
-
-The i.MX7S/D General Power Control (GPC) block contains Power Gating
-Control (PGC) for various power domains.
-
-Required properties:
-
-- compatible: Should be one of:
- - "fsl,imx7d-gpc"
- - "fsl,imx8mq-gpc"
-
-- reg: should be register base and length as documented in the
- datasheet
-
-- interrupts: Should contain GPC interrupt request 1
-
-Power domains contained within GPC node are generic power domain
-providers, documented in
-Documentation/devicetree/bindings/power/power-domain.yaml, which are
-described as subnodes of the power gating controller 'pgc' node,
-which, in turn, is expected to contain the following:
-
-Required properties:
-
-- reg: Power domain index. Valid values are defined in
- include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and
- include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc
-
-- #power-domain-cells: Should be 0
-
-Optional properties:
-
-- power-supply: Power supply used to power the domain
-- clocks: a number of phandles to clocks that need to be enabled during
- domain power-up sequencing to ensure reset propagation into devices
- located inside this power domain
-
-Example:
-
- gpc: gpc@303a0000 {
- compatible = "fsl,imx7d-gpc";
- reg = <0x303a0000 0x1000>;
- interrupt-controller;
- interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
- #interrupt-cells = <3>;
- interrupt-parent = <&intc>;
-
- pgc {
- #address-cells = <1>;
- #size-cells = <0>;
-
- pgc_pcie_phy: power-domain@1 {
- #power-domain-cells = <0>;
-
- reg = <1>;
- power-supply = <®_1p0d>;
- };
- };
- };
-
-
-Specifying power domain for IP modules
-======================================
-
-IP cores belonging to a power domain should contain a 'power-domains'
-property that is a phandle for PGC node representing the domain.
-
-Example of a device that is part of the PCIE_PHY power domain:
-
- pcie: pcie@33800000 {
- reg = <0x33800000 0x4000>,
- <0x4ff00000 0x80000>;
- /* ... */
- power-domains = <&pgc_pcie_phy>;
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
new file mode 100644
index 0000000..bde09a0
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml
@@ -0,0 +1,108 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/fsl,imx-gpcv2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX General Power Controller v2
+
+maintainers:
+ - Andrey Smirnov <andrew.smirnov@gmail.com>
+
+description: |
+ The i.MX7S/D General Power Control (GPC) block contains Power Gating
+ Control (PGC) for various power domains.
+
+ Power domains contained within GPC node are generic power domain
+ providers, documented in
+ Documentation/devicetree/bindings/power/power-domain.yaml, which are
+ described as subnodes of the power gating controller 'pgc' node.
+
+ IP cores belonging to a power domain should contain a 'power-domains'
+ property that is a phandle for PGC node representing the domain.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx7d-gpc
+ - fsl,imx8mq-gpc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ pgc:
+ type: object
+ description: list of power domains provided by this controller.
+
+ patternProperties:
+ "power-domain@[0-9]$":
+ type: object
+ properties:
+
+ '#power-domain-cells':
+ const: 0
+
+ reg:
+ description: |
+ Power domain index. Valid values are defined in
+ include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and
+ include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc
+ maxItems: 1
+
+ clocks:
+ description: |
+ A number of phandles to clocks that need to be enabled during domain
+ power-up sequencing to ensure reset propagation into devices located
+ inside this power domain.
+ minItems: 1
+ maxItems: 5
+
+ power-supply: true
+
+ required:
+ - '#power-domain-cells'
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - pgc
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpc@303a0000 {
+ compatible = "fsl,imx7d-gpc";
+ reg = <0x303a0000 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+
+ pgc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pgc_mipi_phy: power-domain@0 {
+ #power-domain-cells = <0>;
+ reg = <0>;
+ power-supply = <®_1p0d>;
+ };
+
+ pgc_pcie_phy: power-domain@1 {
+ #power-domain-cells = <0>;
+ reg = <1>;
+ power-supply = <®_1p0d>;
+ };
+
+ pgc_hsic_phy: power-domain@2 {
+ #power-domain-cells = <0>;
+ reg = <2>;
+ power-supply = <®_1p2>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: power: Convert imx gpc to json-schema
From: Anson Huang @ 2020-06-01 8:06 UTC (permalink / raw)
To: robh+dt, shawnguo, s.hauer, kernel, festevam, ulf.hansson, sboyd,
krzk, p.zabel, andrew.smirnov, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Convert the i.MX GPC binding to DT schema format using json-schema
From latest reference manual, there is actually ONLY 1 interrupt for
GPC, so the additional GPC interrupt is removed.
Consumer's example is also removed since it is NOT that useful.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/power/fsl,imx-gpc.txt | 91 ---------------
.../devicetree/bindings/power/fsl,imx-gpc.yaml | 124 +++++++++++++++++++++
2 files changed, 124 insertions(+), 91 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
deleted file mode 100644
index f0f5553..0000000
--- a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
+++ /dev/null
@@ -1,91 +0,0 @@
-Freescale i.MX General Power Controller
-=======================================
-
-The i.MX6 General Power Control (GPC) block contains DVFS load tracking
-counters and Power Gating Control (PGC).
-
-Required properties:
-- compatible: Should be one of the following:
- - fsl,imx6q-gpc
- - fsl,imx6qp-gpc
- - fsl,imx6sl-gpc
- - fsl,imx6sx-gpc
-- reg: should be register base and length as documented in the
- datasheet
-- interrupts: Should contain one interrupt specifier for the GPC interrupt
-- clocks: Must contain an entry for each entry in clock-names.
- See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
-- clock-names: Must include the following entries:
- - ipg
-
-The power domains are generic power domain providers as documented in
-Documentation/devicetree/bindings/power/power-domain.yaml. They are described as
-subnodes of the power gating controller 'pgc' node of the GPC and should
-contain the following:
-
-Required properties:
-- reg: Must contain the DOMAIN_INDEX of this power domain
- The following DOMAIN_INDEX values are valid for i.MX6Q:
- ARM_DOMAIN 0
- PU_DOMAIN 1
- The following additional DOMAIN_INDEX value is valid for i.MX6SL:
- DISPLAY_DOMAIN 2
- The following additional DOMAIN_INDEX value is valid for i.MX6SX:
- PCI_DOMAIN 3
-
-- #power-domain-cells: Should be 0
-
-Optional properties:
-- clocks: a number of phandles to clocks that need to be enabled during domain
- power-up sequencing to ensure reset propagation into devices located inside
- this power domain
-- power-supply: a phandle to the regulator powering this domain
-
-Example:
-
- gpc: gpc@20dc000 {
- compatible = "fsl,imx6q-gpc";
- reg = <0x020dc000 0x4000>;
- interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>,
- <0 90 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX6QDL_CLK_IPG>;
- clock-names = "ipg";
-
- pgc {
- #address-cells = <1>;
- #size-cells = <0>;
-
- power-domain@0 {
- reg = <0>;
- #power-domain-cells = <0>;
- };
-
- pd_pu: power-domain@1 {
- reg = <1>;
- #power-domain-cells = <0>;
- power-supply = <®_pu>;
- clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>,
- <&clks IMX6QDL_CLK_GPU3D_SHADER>,
- <&clks IMX6QDL_CLK_GPU2D_CORE>,
- <&clks IMX6QDL_CLK_GPU2D_AXI>,
- <&clks IMX6QDL_CLK_OPENVG_AXI>,
- <&clks IMX6QDL_CLK_VPU_AXI>;
- };
- };
- };
-
-
-Specifying power domain for IP modules
-======================================
-
-IP cores belonging to a power domain should contain a 'power-domains' property
-that is a phandle pointing to the power domain the device belongs to.
-
-Example of a device that is part of the PU power domain:
-
- vpu: vpu@2040000 {
- reg = <0x02040000 0x3c000>;
- /* ... */
- power-domains = <&pd_pu>;
- /* ... */
- };
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
new file mode 100644
index 0000000..a055b3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/fsl,imx-gpc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX General Power Controller
+
+maintainers:
+ - Philipp Zabel <p.zabel@pengutronix.de>
+
+description: |
+ The i.MX6 General Power Control (GPC) block contains DVFS load tracking
+ counters and Power Gating Control (PGC).
+
+ The power domains are generic power domain providers as documented in
+ Documentation/devicetree/bindings/power/power-domain.yaml. They are
+ described as subnodes of the power gating controller 'pgc' node of the GPC.
+
+ IP cores belonging to a power domain should contain a 'power-domains'
+ property that is a phandle pointing to the power domain the device belongs
+ to.
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx6q-gpc
+ - fsl,imx6qp-gpc
+ - fsl,imx6sl-gpc
+ - fsl,imx6sx-gpc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ const: ipg
+
+ pgc:
+ type: object
+ description: list of power domains provided by this controller.
+
+ patternProperties:
+ "power-domain@[0-9]$":
+ type: object
+ properties:
+
+ '#power-domain-cells':
+ const: 0
+
+ reg:
+ description: |
+ The following DOMAIN_INDEX values are valid for i.MX6Q:
+ ARM_DOMAIN 0
+ PU_DOMAIN 1
+ The following additional DOMAIN_INDEX value is valid for i.MX6SL:
+ DISPLAY_DOMAIN 2
+ The following additional DOMAIN_INDEX value is valid for i.MX6SX:
+ PCI_DOMAIN 3
+ maxItems: 1
+
+ clocks:
+ description: |
+ A number of phandles to clocks that need to be enabled during domain
+ power-up sequencing to ensure reset propagation into devices located
+ inside this power domain.
+ minItems: 1
+ maxItems: 7
+
+ power-supply: true
+
+ required:
+ - '#power-domain-cells'
+ - reg
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - pgc
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ gpc@20dc000 {
+ compatible = "fsl,imx6q-gpc";
+ reg = <0x020dc000 0x4000>;
+ interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_IPG>;
+ clock-names = "ipg";
+
+ pgc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ power-domain@0 {
+ reg = <0>;
+ #power-domain-cells = <0>;
+ };
+
+ pd_pu: power-domain@1 {
+ reg = <1>;
+ #power-domain-cells = <0>;
+ power-supply = <®_pu>;
+ clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>,
+ <&clks IMX6QDL_CLK_GPU3D_SHADER>,
+ <&clks IMX6QDL_CLK_GPU2D_CORE>,
+ <&clks IMX6QDL_CLK_GPU2D_AXI>,
+ <&clks IMX6QDL_CLK_OPENVG_AXI>,
+ <&clks IMX6QDL_CLK_VPU_AXI>;
+ };
+ };
+ };
--
2.7.4
^ permalink raw reply related
* RE: [PATCH V2 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Anson Huang @ 2020-06-01 8:09 UTC (permalink / raw)
To: Aisheng Dong, Peng Fan, shawnguo@kernel.org, Fabio Estevam,
kernel@pengutronix.de, robh+dt@kernel.org, sboyd@kernel.org,
linux@rempel-privat.de, jaswinder.singh@linaro.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Leonard Crestez,
Daniel Baluta, l.stach@pengutronix.de, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <AM6PR04MB496668011F3AB2BEEEE6D1E1808A0@AM6PR04MB4966.eurprd04.prod.outlook.com>
> Subject: RE: [PATCH V2 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
>
> > From: Peng Fan <peng.fan@nxp.com>
> > Sent: Monday, June 1, 2020 11:43 AM
> >
> > Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
>
> BTW, Anson,
> will you continue to help convert MU binding into json schemas?
Ok.
^ permalink raw reply
* RE: [PATCH V2 2/3] arm64: dts: imx8m: add mu node
From: Peng Fan @ 2020-06-01 8:08 UTC (permalink / raw)
To: Aisheng Dong, shawnguo@kernel.org, Fabio Estevam,
kernel@pengutronix.de, robh+dt@kernel.org, sboyd@kernel.org,
linux@rempel-privat.de, jaswinder.singh@linaro.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Leonard Crestez,
Daniel Baluta, l.stach@pengutronix.de, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <AM6PR04MB496620ABEA09A0571B42A9B4808A0@AM6PR04MB4966.eurprd04.prod.outlook.com>
> Subject: RE: [PATCH V2 2/3] arm64: dts: imx8m: add mu node
>
> > From: Peng Fan <peng.fan@nxp.com>
> > Sent: Monday, June 1, 2020 11:43 AM
> >
> > Add mu node to let A53 could communicate with M Core.
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/imx8mm.dtsi | 9 +++++++++
> > arch/arm64/boot/dts/freescale/imx8mn.dtsi | 9 +++++++++
> > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 9 +++++++++
> > arch/arm64/boot/dts/freescale/imx8mq.dtsi | 9 +++++++++
> > 4 files changed, 36 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > index aaf6e71101a1..fc001fb971e9 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > @@ -775,6 +775,15 @@
> > status = "disabled";
> > };
> >
> > + mu: mailbox@30aa0000 {
> > + compatible = "fsl,imx8mm-mu", "fsl,imx6sx-mu";
> > + reg = <0x30aa0000 0x10000>;
> > + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MM_CLK_MU_ROOT>;
> > + clock-names = "mu";
>
> You missed my comments about this unneeded line in the last round of
> review.
> https://lore.kernel.org/patchwork/patch/1244752/
oops, will update in v3.
Thanks,
Peng.
>
> Regards
> Aisheng
>
> > + #mbox-cells = <2>;
> > + };
> > +
> > usdhc1: mmc@30b40000 {
> > compatible = "fsl,imx8mm-usdhc", "fsl,imx7d-usdhc";
> > reg = <0x30b40000 0x10000>;
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > index 9a4b65a267d4..c8290d21ccc9 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > @@ -675,6 +675,15 @@
> > status = "disabled";
> > };
> >
> > + mu: mailbox@30aa0000 {
> > + compatible = "fsl,imx8mn-mu", "fsl,imx6sx-mu";
> > + reg = <0x30aa0000 0x10000>;
> > + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MN_CLK_MU_ROOT>;
> > + clock-names = "mu";
> > + #mbox-cells = <2>;
> > + };
> > +
> > usdhc1: mmc@30b40000 {
> > compatible = "fsl,imx8mn-usdhc", "fsl,imx7d-usdhc";
> > reg = <0x30b40000 0x10000>;
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > index 45e2c0a4e889..b530804f763e 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -621,6 +621,15 @@
> > status = "disabled";
> > };
> >
> > + mu: mailbox@30aa0000 {
> > + compatible = "fsl,imx8mp-mu", "fsl,imx6sx-mu";
> > + reg = <0x30aa0000 0x10000>;
> > + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MP_CLK_MU_ROOT>;
> > + clock-names = "mu";
> > + #mbox-cells = <2>;
> > + };
> > +
> > i2c5: i2c@30ad0000 {
> > compatible = "fsl,imx8mp-i2c", "fsl,imx21-i2c";
> > #address-cells = <1>;
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > index 978f8122c0d2..66ba8da704f6 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
> > @@ -959,6 +959,15 @@
> > status = "disabled";
> > };
> >
> > + mu: mailbox@30aa0000 {
> > + compatible = "fsl,imx8mq-mu", "fsl,imx6sx-mu";
> > + reg = <0x30aa0000 0x10000>;
> > + interrupts = <GIC_SPI 88 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk IMX8MQ_CLK_MU_ROOT>;
> > + clock-names = "mu";
> > + #mbox-cells = <2>;
> > + };
> > +
> > usdhc1: mmc@30b40000 {
> > compatible = "fsl,imx8mq-usdhc",
> > "fsl,imx7d-usdhc";
> > --
> > 2.16.4
^ 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